[PATCH] atexit: document z/OS bug

* doc/posix-functions/atexit.texi: Mention z/OS issue raised by Sachin . --- ChangeLog | 6 ++ doc/posix-functions/atexit.texi | 8 2 files changed, 14 insertions(+) diff --git a/ChangeLog b/ChangeLog index 47b518100f..0298812ea2 1006

Re: reproducible tar archives

Simon Josefsson via Gnulib discussion list writes: > We have code to make release tar archives reproducible: Nice! We finally had an effort this year to make the Guix source tarball reproducible --8<---cut here---start->8--- ba52975ea9 Revert "maint: Generate

Re: reproducible tar archives

On 12/12/24 15:07, Simon Josefsson via Gnulib discussion list wrote: mm, it seems --format=posix is actually a bit misleading: it seems that if no features from --format=posix is necessary (like sub-second timestamps) then it will be the same as ustar format. That's what pax (posix) format is.

Re: [PATCH] crc: Add PCLMUL implementation

Hi guys, Just bumping this, is this a change we would like to include? Are there any issues with the patch that you'd like me to fix? Cheers Sam On Tue, Nov 26, 2024, 23:01 Sam Russell wrote: > > It's your choice: 3 compilation units for x86_64, or 1 compilation unit > > for x86_64, or no ext

Re: reproducible tar archives

Bruno Haible writes: > Simon Josefsson wrote: >> 1) Some of the suggested flags probably requires a newer GNU tar. ... >> running 'make distcheck' on old >> systems is useful for ironing out platform-dependent problems. > > I always run > - 'make distcheck' only on my development machine, >

Re: reproducible tar archives

Simon Josefsson wrote: > 1) Some of the suggested flags probably requires a newer GNU tar. ... > running 'make distcheck' on old > systems is useful for ironing out platform-dependent problems. I always run - 'make distcheck' only on my development machine, - 'make check' on various platforms

Re: publish PGP-signed git bundles of gnulib?

Bruno Haible via Gnulib discussion list writes: > Regarding the location of that manual section, I suggest you make it a > new section in chapter 21 "Release Management Files". (It would be > misplaced in chapter 1, 2, or 3, in my opinion.) Thanks, I'll propose a patch eventually. I'm not sure

Re: OpenPGP keys

Bruno Haible via Gnulib discussion list writes: > Simon Josefsson wrote: >> > I see. Indeed, if many developers would share their PGP key through >> > Savannah, the GNU keyring, GitHub, GitLab, their own home page, etc., it >> > would become harder for an attacker to introduce a spoofed one in al

Re: publish PGP-signed git bundles of gnulib?

Hi Simon, > > stable-202407 is meant to be maintained until 2025-06-30. For one year. > > > > The bundle would then include a branch whose maintenance just ended > > (stable-202401) and one whose maintenance is ongoing. > > I think we need to include all branches forever in the Git bundle, since

Re: OpenPGP keys

Simon Josefsson wrote: > > I see. Indeed, if many developers would share their PGP key through > > Savannah, the GNU keyring, GitHub, GitLab, their own home page, etc., it > > would become harder for an attacker to introduce a spoofed one in all of > > these > > places. OTOH, since these are not r

Re: publish PGP-signed git bundles of gnulib?

Bruno Haible via Gnulib discussion list writes: > Simon Josefsson wrote: >> Timing wise >> maybe it make sense to push out a "snapshot" Git bundle right before you >> branch off stable-202501? The Git bundle would then include master up >> to that point, and the earlier stable-* branches. > > Ye

Re: OpenPGP keys

Bruno Haible via Gnulib discussion list writes: >> x) I got your PGP key a couple of years ago and still have it locally >> ... >> x) It is better to get the PGP key from multiple places, which is one >> reason the announcements mention a couple of ways, since it is harder to >> pollute all of th

Re: OpenPGP keys at GNU

Bruno Haible via Gnulib discussion list writes: > Simon Josefsson wrote: >> > This is consistent with the following observation: When I download your >> > PGP key from https://savannah.gnu.org/users/jas, I see that it has only >> > self-signatures. >> >> Savannah admins made a decision to "minim

reproducible tar archives

Hi We have code to make release tar archives reproducible: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=top/GNUmakefile;hb=5b92dd0a45c8d27f13a21076b57095ea5e220870#l28 https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=top/maint.mk;h=b2baa02edff3c7cf591caf5fd24a9b7c6717122a

bcp47: Silence a gcc 14 -Wanalyzer-infinite-loop warning

With gcc 14 (Ubuntu 24.04) I see a compilation warning: bcp47.c:379:12: warning: infinite loop [CWE-835] [-Wanalyzer-infinite-loop] At first glance, indeed, it looks like a human mistake. So, let me clarify the code, both for the human reader and for GCC, by verifying an invariant. 2024-12-12