Re: GNU Emacs and the translation domain "gnulib"

2024-12-13 Thread Jim Meyering
On Wed, Dec 11, 2024 at 8:05 AM Bruno Haible via Gnulib discussion list wrote: > Paul Eggert wrote: > > Although Emacs uses some Gnulib modules, it doesn't use translations or > > the gettext function so it won't use the "gnulib" translation domain. > > Also, Emacs developers prefer using less Gnu

Re: reproducible tar archives

2024-12-13 Thread Paul Eggert
On 12/13/24 13:35, Paul Eggert wrote: Only question I have is where to find a V7-only tar implementation and how it behaves when seeing a ustar archive. SunOS4? AIX 3? You could always go back to 7th edition UNIX source code Seriously, though, if a platform is no longer supported by its o

Re: [PATCH] crc: Add PCLMUL implementation

2024-12-13 Thread Jim Meyering
That's not the way it usually works. Typically, the author and/or person most familiar with the code is listed as the Maintainer. If you don't want to list yourself and no one else steps up, just mark it as "all". On Fri, Dec 13, 2024 at 10:52 AM Sam Russell wrote: > > Jim, would you be willing t

Re: reproducible tar archives

2024-12-13 Thread Paul Eggert
On 12/13/24 01:05, Simon Josefsson wrote: What is not clear to me is how older implementations handle seeing a --format=posix aka (?) PAX format archive, and which these implementations are. Solaris 10 /usr/bin/tar will read a PAX format archive as if it contained additional files, whose names

Re: [PATCH] crc: Add PCLMUL implementation

2024-12-13 Thread Sam Russell
Sounds good, thanks for explaining. I'll get going on the autoconf stuff then. On Fri, Dec 13, 2024, 20:03 Jim Meyering wrote: > That's not the way it usually works. > Typically, the author and/or person most familiar with the code is > listed as the Maintainer. > If you don't want to list yours

Re: [PATCH] crc: Add PCLMUL implementation

2024-12-13 Thread Sam Russell
Jim, would you be willing to be the maintainer for this in gnulib? If so then I can fix the autoconf this week and get it ready to go On Fri, Dec 13, 2024, 19:29 Jim Meyering wrote: > As soon as this is added to gnulib, I'll be happy to prepare for a new > gzip release that includes it. > > On F

Re: [PATCH] crc: Add PCLMUL implementation

2024-12-13 Thread Jim Meyering
As soon as this is added to gnulib, I'll be happy to prepare for a new gzip release that includes it. On Fri, Dec 13, 2024 at 9:45 AM Sam Russell wrote: > > I should also add that I'm planning long term to try and get the major open > source tools (e.g. gzip) using the most efficient algorithms

Re: [PATCH] crc: Add PCLMUL implementation

2024-12-13 Thread Sam Russell
I should also add that I'm planning long term to try and get the major open source tools (e.g. gzip) using the most efficient algorithms for CRC32, so there will be more patches coming in future to match the ones I've submitted to coreutils. Are there any volunteers to be maintainer for these? On

Re: [PATCH] crc: Add PCLMUL implementation

2024-12-13 Thread Sam Russell
> I'd prefer of the crc PCLMUL feature is "opt-in" from a package > maintainer point of view. fine by me, this just requires a change to the build script then? the binding in crc.c has #ifdefs around it already > So this would be removed. ok, so we just need crc pclmul to be explicitly flagged o

Re: [PATCH] crc: Add PCLMUL implementation

2024-12-13 Thread Simon Josefsson via Gnulib discussion list
Thanks for continuing work on this! I'd like to focus on a meta issue first. I'd prefer of the crc PCLMUL feature is "opt-in" from a package maintainer point of view. Do you see any problem with that? What I'm after is that people who import the 'crc' module now don't automatically get the CRC

Re: [PATCH] crc: Add PCLMUL implementation

2024-12-13 Thread Bruno Haible via Gnulib discussion list
Simon, Sam Russell wrote: > 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? This module is in your responsibility, Simon. What's your take on Sam's current patch? [1] Bruno [1] https://lists.gnu.org/archive/html/bug-

Re: reproducible tar archives

2024-12-13 Thread Bruno Haible via Gnulib discussion list
Simon Josefsson wrote: > Possibly automake can move > from v7 to ustar. Adding this to gnulib now allows us to gain > experience with it. I have already experience with it: Since 2018, all tarballs of GNU gettext were made with --format=ustar. I have tested them on all possible platforms, from HP

Re: reproducible tar archives

2024-12-13 Thread Simon Josefsson via Gnulib discussion list
Janneke Nieuwenhuizen writes: > 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 This has been the main inspiration and reference for me

Re: reproducible tar archives

2024-12-13 Thread Simon Josefsson via Gnulib discussion list
Paul Eggert writes: > 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. > > Th