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: [sr #111044] autoconf should assert existence of all subsidiary tools at startup

Hi - On Mon, Apr 01, 2024 at 05:10:17PM -0400, Paul Eggert wrote: > [...] > Not sure I'd go that far. The > [https://www.gnu.org/prep/standards/html_node/Utilities-in-Makefiles.html GNU > Coding Standards for utilities in makefiles] lists the following as usable > without further ado: > > awk cat

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

[sr #111044] autoconf should assert existence of all subsidiary tools at startup

Follow-up Comment #3, sr #111044 (group autoconf): [comment #2 comment #2:] > neither `diff` nor `awk` (and arguably not even `sed`) should be an implicit dependency. Not sure I'd go that far. The [https://www.gnu.org/prep/standards/html_node/Utilities-in-Makefiles.html GNU Coding Standards for u

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

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

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

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

[sr #111044] autoconf should assert existence of all subsidiary tools at startup

Update of sr #111044 (group autoconf): Priority: 5 - Unprioritized => 2 - Eventually Severity: 3 - Normal => 2 - Minor Status:None => Need Info ___

[sr #111044] autoconf should assert existence of all subsidiary tools at startup

Follow-up Comment #1, sr #111044 (group autoconf): To elaborate on that, people may use the output of such tools to enable or disable certain compiler features. An example of such a case was found when building OpenVPN [0]. This was also reported in 2008 [1]. [0] https://twitter.com/disconnect3d

[sr #111044] autoconf should assert existence of all subsidiary tools at startup

URL: Summary: autoconf should assert existence of all subsidiary tools at startup Group: Autoconf Submitter: None Submitted: Mon 01 Apr 2024 03:10:23 PM UTC Priority: 5 -