Re: RFC: git-commit based mtime-reproducible tarballs

Vivien Kraus writes: > However, there are situations in which you only have access to a > shallow clone of the git repository (for instance, Gitlab CI). I am not > sure how this solution would work in that case. Indeed, good point. I think 'make dist' should continue to work in shallow clones,

Re: Improve support for ACLs in coreutils (ls & chmod) following the Solaris way

Pádraig Brady wrote: > So as we see there are lots of "additional attributes" > with dedicated programs to manipulate them. > What's the big advantage of merging with ls and chmod, > over the current situation of separate utilities? In [1] I'm arguing: * A feature that has impact on security, a

Re: Improve support for ACLs in coreutils (ls & chmod) following the Solaris way

On 16/01/2023 15:03, Ondrej Valousek wrote: Hi, As per our conversation with Bruno I was thinking if it would make a sense to extend support of ACLs in gnulib/coreutils, mainly covering "ls" (1st stage) and "chmod" (2nd stage) with the goal to have the ACLs better understandable for end users

Re: Improve support for ACLs in coreutils (ls & chmod) following the Solaris way

Ondrej Valousek wrote: > Is this something I would find support in both coreutils and Gnulib? Regarding Gnulib: Yes, for code that has its proper place in Gnulib, you have my support. Bruno

Re: [PATCH] better explain functions [q]set-acl.c

Hi Ondrej, > Improve comments for both functions > > --- > lib/qset-acl.c | 16 +--- > lib/set-acl.c | 13 +++-- > 2 files changed, 16 insertions(+), 13 deletions(-) I wanted to apply this patch in your name, but it fails: error: corrupt patch at line 31 Evidently the patc

Re: [PATCH v2] Define alignof_slot using _Alignof when using C11 or newer

Paul Eggert wrote: > The basic idea is to prefer C23 semantics in apps and the rest of Gnulib > by using the new alignasof module, whereas the existing stdalign module > is now for C11/C17 compatibility and is now deprecated. On Android (and probably some other platforms) I now see a compilation

Improve support for ACLs in coreutils (ls & chmod) following the Solaris way

Hi, As per our conversation with Bruno I was thinking if it would make a sense to extend support of ACLs in gnulib/coreutils, mainly covering "ls" (1st stage) and "chmod" (2nd stage) with the goal to have the ACLs better understandable for end users. For "ls" we would: - Introduce a new fla

Android and the C locale

Android < 5.0 had only dummy locales. Starting with Android 5.0 (according to the Android libc's git history), they have locales. But there are two problems: 1) The default locale (i.e. the locale in use when setlocale was not called) is the "C.UTF-8" locale, not the "C" locale. Test case: =

[PATCH] better explain functions [q]set-acl.c

Improve comments for both functions --- lib/qset-acl.c | 16 +--- lib/set-acl.c | 13 +++-- 2 files changed, 16 insertions(+), 13 deletions(-) diff --git a/lib/qset-acl.c b/lib/qset-acl.c index c3442d060f..0ae026f031 100644 --- a/lib/qset-acl.c +++ b/lib/qset-acl.c @@ -27,13

Re: [PATCH] better explain functions [q]set-acl.c

Hi Ondrej, > Improve comments for both functions Did you see the feedback that I gave in https://lists.gnu.org/archive/html/bug-gnulib/2023-01/msg00063.html ? Bruno

[PATCH] better explain functions [q]set-acl.c

Improve comments for both functions --- lib/qset-acl.c | 16 +--- lib/set-acl.c | 13 +++-- 2 files changed, 16 insertions(+), 13 deletions(-) diff --git a/lib/qset-acl.c b/lib/qset-acl.c index c3442d060f..0ae026f031 100644 --- a/lib/qset-acl.c +++ b/lib/qset-acl.c @@ -27,13

Re: [PATCH] Use ‘head -n1’ rather than ‘head -1’

> POSIX no longer requires support for ‘head -1’. Thanks. I'm adding a ChangeLog entry for this change: 2023-01-16 Paul Eggert sigpipe tests: Modernize use of 'head'. POSIX no longer requires support for ‘head -1’. * tests/test-sigpipe.sh: Use ‘head -n1’ rather than ‘

Re: RFC: git-commit based mtime-reproducible tarballs

Vivien Kraus wrote: > However, there are situations in which you only have access to a > shallow clone of the git repository (for instance, Gitlab CI). I am not > sure how this solution would work in that case. The shallow clone is an optimization, that was based on the assumption that the CI does

Re: RFC: git-commit based mtime-reproducible tarballs

Hello, Le dimanche 15 janvier 2023 à 08:03 -0800, Paul Eggert a écrit : > For TZDB, where users have long wanted reproducibility, I use > something > like this in a Makefile recipe for each source file $$file: > >   time=`git log -1 --format='tformat:%ct' $$file` && >   t

[PATCH] Use ‘head -n1’ rather than ‘head -1’

POSIX no longer requires support for ‘head -1’. --- lib/git-merge-changelog.c | 4 ++-- tests/test-sigpipe.c | 2 +- tests/test-sigpipe.sh | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/lib/git-merge-changelog.c b/lib/git-merge-changelog.c index 679c4aac1a..570

Re: RFC: git-commit based mtime-reproducible tarballs

On Mon, Jan 16, 2023, 12:41 AM Simon Josefsson via Gnulib discussion list < bug-gnulib@gnu.org> wrote: > Bruno Haible writes: > > > Paul Eggert wrote: > >> some users want to "trust but verify" and a reproducible > >> tarball is easier to audit than a non-reproducible one, so for these > >> users

Re: RFC: git-commit based mtime-reproducible tarballs

Bruno Haible writes: > Paul Eggert wrote: >> some users want to "trust but verify" and a reproducible >> tarball is easier to audit than a non-reproducible one, so for these >> users it can be a win to omit the irrelevant data from the tarball. > > Reproducibility can be implemented in differen

Re: RFC: git-commit based mtime-reproducible tarballs

Hi Bruno, > Hi Simon, > >> > This attempts to make >> > reproducible tarballs by sorting the files and passing the >> > "--mtime=" option to tar. ... >> Having the same mtime on all files in a tarball > > First question: What is the point of doing that? Good question, I don't know the motiv