bug#70410: Fwd: [PATCH] gotools: Workaround non-reproduceability of automake

2024-04-17 Thread Eric Gallager via Bug reports for Automake
Makefile.am in question is from the gotools subdirectory of GCC: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gotools/Makefile.am;h=80b21847117fb1b685a677725826f4caba4e759e;hb=HEAD Note that the original reporter, Jakub Jelinek, has said that this might potentially be due to the use of an old

bug#70410: Fwd: [PATCH] gotools: Workaround non-reproduceability of automake

2024-04-15 Thread Eric Gallager via Bug reports for Automake
GCC developers have recently found a source of non-determinism in automake; this is bad for reproducible builds: -- Forwarded message - From: Jakub Jelinek Date: Mon, Apr 15, 2024 at 8:43 AM Subject: [PATCH] gotools: Workaround non-reproduceability of automake To: Ian Lance

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

2024-04-01 Thread Eric Gallager
On Tue, Apr 2, 2024 at 12:04 AM Jacob Bachmeyer wrote: > > Russ Allbery wrote: > > [...] > > > > There is extensive ongoing discussion of this on debian-devel. There's no > > real consensus in that discussion, but I think one useful principle that's > > emerged that doesn't disrupt the world

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

2024-04-01 Thread Eric Gallager
On Mon, Apr 1, 2024 at 2:26 PM Zack Weinberg wrote: > > On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote: > > "Zack Weinberg" writes: > >> It might indeed be worth thinking about ways to minimize the > >> difference between the tarball "make dist" produces and the tarball > >> "git archive"

Should the GNU Coding Standards make a recommendation about aclocal's `--install` flag? (was: "Re: GNU Coding Standards, automake, and the recent xz-utils backdoor")

2024-04-01 Thread Eric Gallager
On Sun, Mar 31, 2024 at 6:19 PM Peter Johansson wrote: > > > On 1/4/24 06:00, Eric Gallager wrote: > > So, `aclocal` has a flag to control this behavior: specifically, its > `--install` flag. Right now I don't see `aclocal` mentioned in the GNU > Coding Standards at all. S

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

2024-03-31 Thread Eric Gallager
On Sun, Mar 31, 2024 at 3:54 PM Russ Allbery wrote: > > Eric Gallager writes: > > > Well, other people besides the maintainers can also run `make dist` and > > `make distcheck`. My idea was to get end-users in the habit of running > > `make distcheck` themsel

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

2024-03-31 Thread Eric Gallager
On Sun, Mar 31, 2024 at 3:20 AM Jacob Bachmeyer wrote: > > dherr...@tentpost.com wrote: > > On 2024-03-30 18:25, Bruno Haible wrote: > >> Eric Gallager wrote: > >>> > >>> Hm, so should automake's `distcheck` target be updated to perform > >

Re: GNU Coding Standards, automake, and the recent xz-utils backdoor

2024-03-30 Thread Eric Gallager
On Sat, Mar 30, 2024 at 5:41 PM Bruno Haible wrote: > > Eric Gallager wrote: > > Recommending the `distcheck` target to a wider variety of users would > > help more projects catch mismatches between things a distribution > > tarball is supposed to contain, and things

GNU Coding Standards, automake, and the recent xz-utils backdoor

2024-03-30 Thread Eric Gallager
and things that it isn't. This would be a win for security and could help make it easier to catch future possible bad actors trying to pull a similar trick. What do people think? Eric Gallager

bug#66679: automake: error: undefined condition 'TRUE' for 'info_TEXINFOS'

2023-10-22 Thread Eric Gallager
On Sun, Oct 22, 2023 at 5:28 PM Karl Berry wrote: > > automake: Please contact . > at /opt/local/share/automake-1.16/Automake/Channels.pm line 655. > Automake::Channels::msg("automake", "", "undefined condition > > Thanks for the report. I (or someone else ... Bogdan?) will look

bug#66679: automake: error: undefined condition 'TRUE' for 'info_TEXINFOS'

2023-10-22 Thread Eric Gallager
In my attached `Makefile.am`, I have been trying to modify it so that it only rebuilds the documentation when explicitly asked to. Otherwise, the distributed copy should just get used instead. However, my modifications have led to the following error: doc/Makefile.am:23: warning: user target

bug#47848: aclocal fails with "error: too many loops"

2021-05-09 Thread Eric Gallager via Bug reports for Automake
On Sun, May 9, 2021 at 9:28 PM Karl Berry wrote: > > Ei Eric, > > Automake::ChannelDefs::prog_error("too many loops") called at > /opt/local/bin/aclocal line 1187 > > I've never seen that error before. The comment in aclocal where the > check is done says: > > # We may have to rerun

bug#47848: aclocal fails with "error: too many loops"

2021-04-17 Thread Eric Gallager via Bug reports for Automake
ere, that is what I am doing. I am using automake 1.16.3 as installed by MacPorts. Any idea what's going on? Thanks, Eric Gallager