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

Paul Eggert writes: > On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote: >> Is bootstrap intended to be reliable from within a tarball? I thought >> the bootstrap script was not included in tarballs because it wasn't >> designed to be ran that way, and the way it is designed

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

Nick Bowler wrote: > Not including the scripts used to build configure in a source tarball > is a mistake, particularly for a GPL-licensed package. The configure > script itself is clearly object code, and the GPL defines corresponding > source to include any "scripts to control [its

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

On 2024-04-10 16:36, Simon Josefsson wrote: > Is bootstrap intended to be reliable from within a tarball? I thought > the bootstrap script was not included in tarballs because it wasn't > designed to be ran that way, and the way it is designed may not give > expected results. Has this changed,

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

On Wed, Apr 10, 2024 at 5:44 PM Paul Eggert wrote: > > On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote: > > Is bootstrap intended to be reliable from within a tarball? I thought > > the bootstrap script was not included in tarballs because it wasn't > > designed to be ran that

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

On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote: Is bootstrap intended to be reliable from within a tarball? I thought the bootstrap script was not included in tarballs because it wasn't designed to be ran that way, and the way it is designed may not give expected results.

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

Bruno Haible writes: > Bernhard Voelker wrote: >> > Last month, I spent 2 days on prerelease testing of coreutils. If, after >> > downloading the carefully prepared tarball from ftp.gnu.org, the first >> > thing a distro does is to throw away the *.m4 files and regenerate the >> > configure

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

On 4/10/24 4:22 PM, Bruno Haible wrote: Sure, if downstream applies a patch that modifies bootstrap.conf, they need to rerun 'bootstrap'. That goes without saying. I hope downstream then also runs "make check". Sure, full automated QA is in action on all supported platforms. Have a nice day,

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

Bernhard Voelker wrote: > > Last month, I spent 2 days on prerelease testing of coreutils. If, after > > downloading the carefully prepared tarball from ftp.gnu.org, the first > > thing a distro does is to throw away the *.m4 files and regenerate the > > configure script with their own one, >

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

On 4/1/24 11:54 PM, Bruno Haible wrote: > Last month, I spent 2 days on prerelease testing of coreutils. If, after > downloading the carefully prepared tarball from ftp.gnu.org, the first > thing a distro does is to throw away the *.m4 files and regenerate the > configure script with their own

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

On 2024-04-09 18:06, Sam James wrote: > Nick poses that a specific combination of tools is what is tested and > anything else invalidates it. But how does this work when building on > a system that was never tested on, or with different flags, or a > different toolchain? > > It's reasonable to say

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

Sam James replied to Bruno Haible who cited Nick Bowler: > >> 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, > >>

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

Bruno Haible writes: > 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

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

Guillem Jover wrote: > > It may be unexpected to you, but it is very much intended. > > The only unexpected part (which I perhaps failed to convey) was that > it is being taken into account with --force. This is documented in https://www.gnu.org/software/automake/manual/html_node/Serials.html

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

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

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

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

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

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

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