[lmi] 'bullseye' vs. 'bookworm' build logs

[Greg Chicares]

Should we run 'autoupdate' for wx and for xmlsoft.org libraries?
Do we care if the 'mt' utility is no longer available?
Is it important that building libtiff fails to find libjpeg?
Does it matter if MinGW-w64-gcc emits some diagnostics for 'tif_print.c'?
If the answers are all "no", then the rest of this email can be ignored.

I'm working with two chroots:
  'bookworm': an experimental new chroot that I'm testing
     rebuilt yesterday thus:
       $ cd /opt/lmi/src/lmi
       $ ./install_msw.sh > /srv/cache_for_lmi/logs/lmi-$(date -u 
+%Y%m%dT%H%MZ%) 2>&1
  'bullseye': my current production chroot, with an updated wx submodule
     regenerated ab ovo:
       # rm -rf /srv/chroot/lmi_bookworm_4                      
       # ./lmi_setup_00.sh 2>&1 |less -S                        
and comparing the logs with this marvelous command that you helped
me develop years ago (thanks again):
  git diff --no-index --color=always --color-moved=plain \
  /opt/lmi/logs/log-old   /opt/lmi/logs/log-new \
  |sed -e's/^.\[3[12]m/&ZZZ/' |less -RS
so quoted lines below that begin
  ZZZ-  are for 'bookworm'
  ZZZ+  are for 'bullseye'
Let me note some differences here.

(1) wx submodule version [resolved--feel free to skip]

In both cases, 'install_msw.sh' is run (either called directly, or
via 'lmi_setup_42.sh'), and it does this:
  # Get any new submodules that may have been added, even if nested.
  git submodule update "$coefficiency" --recursive --init
so I anticipated that both rebuilds would use the latest wx submodule.
For reference, updating the wx submodule shows this in git-log:
  -Subproject commit c9486f9cebb2843fdd3cb3e6433045644c456e38
  +Subproject commit efd7bf881e9b5fceca6ceaf1edba072a56de971b
To my initial surprise, the brand-new chroot seems to have the old submodule:

ZZZ-+ git clone --jobs=32 --recurse-submodules 
git://git.savannah.nongnu.org/lmi.git
ZZZ-Cloning into 'lmi'...
[...omitting XML2, xmlwrapp, and wxpdfdoc lines...]
ZZZ-Submodule 'third_party/wx' (https://github.com/let-me-illustrate/wx.git) 
registered for path 'third_party/wx'
ZZZ-Cloning into '/opt/lmi/src/lmi/third_party/wx'...
ZZZ-Submodule path 'third_party/wx': checked out 
'c9486f9cebb2843fdd3cb3e6433045644c456e38'

IOW, I was expecting efd7b instead of c9486 there. But I can
explain that: I haven't yet pushed your
  Update wxWidgets submodule to fix gcc11 -Wshadow warnings
to origin.

(2) anomaly in schroot mount table [feel free to skip]

ZZZ-/dev/sdb5 on /srv/cache_for_lmi type ext4 (rw,relatime,errors=remount-ro)
ZZZ+/dev/sdb5 on /cache_for_lmi type ext4 (rw,relatime,errors=remount-ro)

That's weird: the older chroot mounts
          /cache_for_lmi
where
      /srv/cache_for_lmi
is wanted instead. This seems to be an 'schroot' anomaly. Both chroots
use the same '/etc/schroot/lmi_profile/fstab', which includes:

  # <file system>        <mount point>           <type>  <options>  <dump>  
<pass>
  /srv/cache_for_lmi      /srv/cache_for_lmi      none    rw,bind    0       0

Comparing the configurations thus:
  meld /etc/schroot/chroot.d/{bullseye0.conf,lmi_bookworm_4.conf}
shows no difference that could explain it. I haven't observed any
problem that this might have caused, but it's good to get it on
the written record. No action required for now.

(3) libxml2 autotools

ZZZ-+ cd /opt/lmi/src/lmi/third_party/libxml2
ZZZ-+ NOCONFIGURE=1 ./autogen.sh
[...]
ZZZ-configure.ac:474: warning: The macro `AC_HEADER_STDC' is obsolete.
ZZZ-configure.ac:474: You should run autoupdate.

Should we run 'autoupdate', or is it okay to ignore this?

ZZZ-checking for gcc option to enable C11 features... none needed
ZZZ+checking for gcc option to accept ISO C89... none needed

The 'bookworm' chroot checks for a less ancient C dialect than
'bullseye', although they're using the same libxml submodule.
Is this a real concern? Could a more modern autotools package
in 'bookworm' explain the difference?

ZZZ-checking for mt... no
ZZZ+checking for mt... mt

Here, it looks like 'bookworm' has lost what I think is a utility
for reading magnetic tapes. I guess I'll ignore it as long as no
error occurs downstream.

 Validating the HTML Web pages
ZZZ+make[1]: [Makefile:737: API.html] Error 1 (ignored)

One less error message with 'bookworm'. Good.

(4) wx autotools: tiff no longer finds libjpeg

 === configuring in src/tiff [...]
ZZZ-checking for jpeg_read_scanlines in -ljpeg... yes
ZZZ-checking jpeglib.h usability... yes
ZZZ-checking jpeglib.h presence... yes
ZZZ-checking for jpeglib.h... yes
ZZZ+checking for jpeg_read_scanlines in -ljpeg... no
ZZZ+checking jpeglib.h usability... no
ZZZ+checking jpeglib.h presence... no
ZZZ+checking for jpeglib.h... no

I'm not sure tiff is relevant.

(5) wx autotools: "You should run autoupdate"

ZZZ-autoreconf: Entering directory '.'
ZZZ+autoreconf: Entering directory `.'
 autoreconf: configure.ac: not using Gettext
 autoreconf: running: aclocal -I admin/m4
 autoreconf: configure.ac: tracing
 autoreconf: configure.ac: not running libtoolize: --install not given
ZZZ-autoreconf: configure.ac: not using Intltool
ZZZ-autoreconf: configure.ac: not using Gtkdoc
 autoreconf: running: /usr/bin/autoconf
ZZZ-configure.ac:21: warning: The macro `AC_HELP_STRING' is obsolete.
ZZZ-configure.ac:21: You should run autoupdate.

The 'bookworm' chroot ("ZZZ-") is the one that reports this.
Should we run 'autoupdate'?

(6) a few warnings in the wx build: msw only, not linux

ZZZ+/opt/lmi/src/lmi/third_party/wx/src/tiff/libtiff/tif_print.c:100:21: 
warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 3 
has type ‘long long unsigned int’ [-Wformat=]

I've omitted several other warnings in 'tif_print.c'; I'm guessing
that none of them affects lmi.