Adding gnulib. On Sun, Apr 20, 2025 at 02:25:39AM +0200, Santiago Vila wrote: > Hello. I tested the new snapshot and found the following issues: > > * It still does not allow to run autoreconf. > > configure.ac:36: warning: The macro 'AC_HELP_STRING' is obsolete. > configure.ac:36: You should run autoupdate. > ./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from... > m4/threadlib.m4:36: gl_THREADLIB_EARLY_BODY is expanded from... > m4/threadlib.m4:29: gl_THREADLIB_EARLY is expanded from... > m4/gnulib-comp.m4:34: M4_EARLY is expanded from... > configure.ac:36: the top level ...
This seems to be a weakness in the bootstrap project; I'm not sure I know how to fix it, but hope Gary can take a look. > > Note: This is just FYI but it's not really a big problem for Debian > or for me. I can stop using autoreconf for m4 just fine. Are you running just 'autoreconf', or 'autoreconf -fi'? > > Many people in Debian recommend using autoreconf, but I really dislike it. > I don't want to replace you as m4 authors. I just want to package it > for Debian, i.e. create a modified source package which may be built > on any Debian system. Knowing that skipping autoreconf avoids the problem is useful; although I'll still see if we can find a fix before actually cutting 1.4.20. > > > * This version still fails the tests on Debian unstable for i386, > I think that glibc may have something to do with that: > > ../build-aux/test-driver: line 119: 18250 Aborted (core > dumped) "$@" >> "$log_file" 2>&1 > FAIL: test-frexp-nolibm > Bruno, have you seen this one yet? It looks to be something gnulib should address. > > * Finally, regarding the reproducibility issue, I will drop the current > patch after checking that the package seems to be reproducible without > it at least when I disable autoreconf. > > I fully agree with what was said here some days ago: Whoever makes > the package not to be reproducible becomes responsible to make > it reproducible again, and the current patch was maybe only > useful when using autoreconf, which I will be happy to disable > for as long as it's useful to do so. > > > So, the only showstopper from all the above for me is the build > failure (because of the tests) for i386 on a system with a > recent glibc. I'd love to see a snapshot fixing that before > the final release. > > Thanks a lot. Thank you for the speedy testing and feedback. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
