gnulib-tool.py: Don't default to 'build-aux' for --auxdir.

Hi Bruno, On 4/1/24 3:11 PM, Bruno Haible wrote: > The problem happens here: > > # Update configuration dictionary. > self.config.update(self.cache) # HERE the value is set to > 'autotools' > for key in config.keys(): > value = config[key

gnulib-tool.py: Use a standard Python program directory structure

Here is a patch that makes gnulib-tool.py use the standard Python program directory structure: - a single .py file in the parent directory, - any number of .py files in a subdirectory. With this, no PYTHONPATH override is needed any more, and the import-related error markers in Eclipse are gon

gnulib-tool.py: Simplify imports

In Eclipse, I am seeing error markers for imports, hinting that not following the recommended Python program structure not only forces us to set PYTHONPATH, but also causes trouble in IDEs. While attempting to fix this, I encountered two problem with imports: - The classes.py file makes the impor

Re: packages tests

On 4/1/24 3:11 PM, Bruno Haible wrote: > I also tried a few packages. Depending on the package, I use > - $ gnulib-tool --update > if the package has a gnulib-cache.m4 under version control, > - $ ./autogen.sh > if such a file exists > - $ ./bootstrap --no-git --gnulib-srcdir=$GNUL

Re: packages tests

Hi Collin, > I think now the correct step is for me to build various GNU packages > from user.txt. With luck I won't run into issues, but who knows. I'll > keep notes of which ones I tried and update after a bit. I also tried a few packages. Depending on the package, I use - $ gnulib-tool --upd

Re: autoreconf --force seemingly does not forcibly update everything

Guillem Jover writes: > But if as a downstream distribution I explicitly request everything to > be considered obsolete via --force, then I really do want to get whatever > is in the system instead of in the upstream package. Because then I > can fix things centrally in a distribution dependency

Re: autoreconf --force seemingly does not forcibly update everything

Nick Bowler wrote: > If I distribute a release package, what I have tested is exactly what is > in that package. If you start replacing different versions of m4 macros, > or use some distribution-patched autoconf/automake/libtool or whatever, > then this you have invalidated any and all release te

Re: autoreconf --force seemingly does not forcibly update everything

On 2024-04-01 16:43, Guillem Jover wrote: > But if as a downstream distribution I explicitly request everything > to be considered obsolete via --force, then I really do want to get > whatever is in the system instead of in the upstream package. If I distribute a release package, what I have teste

Re: gnulib-tool.py: Fix --extract-tests-module with a test module.

Hi Bruno, On 4/1/24 6:25 AM, Bruno Haible wrote: > I see: getTestsModule() tries to construct the GLModule object and prints > a warning if there is a problem, while exists(...) is silent. Exactly. > Hooray!! All tests pass!! Now we just have to keep it that way. :) I think now the correct ste

Re: autoreconf --force seemingly does not forcibly update everything

Hi! [ See also my other reply to Eric. ] On Mon, 2024-04-01 at 20:29:59 +0200, Bruno Haible wrote: > Guillem Jover wrote in > : > > > While analyzing the recent xz backdoor hook into the build system [A], > > > I noticed that

Re: autoreconf --force seemingly does not forcibly update everything

Eric Blake writes: > Widening the audience to include bug-gnulib, which is the upstream > source of "# build-to-host.m4 serial 3" which was bypassed by the > malicious "# build-to-host.m4 serial 30". > > On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jover wrote: >> Hi! >> >> While analyzing

Re: autoreconf --force seemingly does not forcibly update everything

Hi! On Mon, 2024-04-01 at 12:43:02 -0500, Eric Blake wrote: > Widening the audience to include bug-gnulib, which is the upstream > source of "# build-to-host.m4 serial 3" which was bypassed by the > malicious "# build-to-host.m4 serial 30". > > On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jo

Re: autoreconf --force seemingly does not forcibly update everything

Jeffrey Walton wrote: > Please forgive my ignorance... If you bump the authentic version of > the m4 file to version 31, will the issue mostly clear itself? If we bump gnulib's build-to-host.m4 to 'serial 31', this will override the one from xz-5.6.x in *some* situations. In other situations, it w

Re: autoreconf --force seemingly does not forcibly update everything

On Mon, Apr 1, 2024 at 2:31 PM Bruno Haible wrote: > > Thanks for the forward, Eric. > > Guillem Jover wrote in > : > > > Hi! > > > > > > While analyzing the recent xz backdoor hook into the build system [A], > > > I noticed th

Re: autoreconf --force seemingly does not forcibly update everything

Thanks for the forward, Eric. Guillem Jover wrote in : > > Hi! > > > > While analyzing the recent xz backdoor hook into the build system [A], > > I noticed that one of the aspects why the hook worked was because it > > seems l

Re: autoreconf --force seemingly does not forcibly update everything

Widening the audience to include bug-gnulib, which is the upstream source of "# build-to-host.m4 serial 3" which was bypassed by the malicious "# build-to-host.m4 serial 30". On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jover wrote: > Hi! > > While analyzing the recent xz backdoor hook into

Re: gnulib-tool.py: Fix --extract-tests-module with a test module.

Collin Funk wrote: > These two patches fix the last remaining test failures in the > gnulib-tool test suite. Thanks a lot! Both patches applied. > The only other place this is used is > GLModuleTable.transitive_closure() and it doesn't seem like this > change breaks anything there. Good. > Afte

Re: gnulib-tool.py: Use case-sensitive sorting for files.

Collin Funk wrote: > This patch fixes this issue. > > I was a bit suspicious of this sorted() call previously, but left it > because I had no proof it was incorrect. > > diff --git a/pygnulib/GLImport.py b/pygnulib/GLImport.py > index 294a8df979..0adfd8a73c 100644 > --- a/pygnulib/GLImport.py > +

Re: m4/getcwd-path-max.m4 hangs with busybox + btrfs

Paul Eggert wrote: > That being said, does the attached patch (which I have neither tested or > installed) fix the problem for you? The patch looks good, and since the report hints that the machine was becoming gradually unresponsive, it might very well help to stop before the machine is complete

gnulib-tool.py: Fix --extract-tests-module with a test module.

These two patches fix the last remaining test failures in the gnulib-tool test suite. The first patch addresses this: $ env GNULIB_TOOL_IMPL=py ./test-extract-tests-module-3.sh cmp: EOF on ./test-extract-tests-module-3.output which is empty --- ./test-extract-tests-module-3.output2024-03