I can confirm that the patch resolves the particular failing test.
However I overlooked that there are other failing tests:
FAIL: tests/chgrp/default-no-deref.sh
FAIL: tests/chgrp/no-x.sh
FAIL: tests/chgrp/posix-H.sh
FAIL: tests/chgrp/recurse.sh
FAIL: tests/chgrp/basic.sh
Here is an example of the failures:
+ require_membership_in_two_groups_
+ test 0 = 0
+ groups='30000 65534'
+ case "$groups" in
+ require_local_dir_
+ require_mount_list_
+ local 'mount_list_fail=cannot read table of mounted file systems'
+ df --local
+ grep -F 'cannot read table of mounted file systems'
+ is_local_dir_ .
+ test 1 = 1
+ df --local .
+ set _ 30000 65534
+ shift
+ g2=65534
+ mkdir d
+ touch f
+ ln -s ../f d/s
++ stat --printf=%g f
+ g_init=30000
+ chgrp -R 65534 d
chgrp: changing group of 'd/s': Invalid argument
chgrp: changing group of 'd': Invalid argument
+ fail=1
++ stat --printf=%g f
+ test 30000 = 30000
+ Exit 1
+ set +e
+ exit 1
+ exit 1
+ remove_tmp_
+ __st=1
+ cleanup_
+ :
+ test '' = yes
+ cd /tmp/guix-build-coreutils-9.1.drv-0/coreutils-9.1
+ chmod -R u+rwx
/tmp/guix-build-coreutils-9.1.drv-0/coreutils-9.1/gt-default-no-deref.sh.AEHe
+ rm -rf
/tmp/guix-build-coreutils-9.1.drv-0/coreutils-9.1/gt-default-no-deref.sh.AEHe
+ exit 1
FAIL tests/chgrp/default-no-deref.sh (exit status: 1)
I think this happens if the user running guix-daemon has supplementary
groups. These are not mapped via /proc/gid_map in the build container
and therefore are reported as the overflow gid (65534) by getgroups.
The test cases assume that they can change ownership to this additional
group but that is not permitted on the overflow gid.
I think supplementary groups should be dropped in the user namespace for
the build container to make the behavior reproducible. Unfortunately
this may be impossible if the parent namespace has set
/proc/[...]/setgroups to "deny".
Best,
keinflue
On 17.04.2025 18:51, Ludovic Courtès wrote:
keinflue <keinf...@posteo.net> writes:
Here are excerpts from the build log:
Thanks.
Unfortunately I made a mistake and accidentally lost the container in
which I tried this, so I can not verify right now whether the patch
actually resolves the issue.
It might take me a day or two to restore it.
No worries, I’ll wait for your feedback.
This happened either during or shortly after bootstrap builds, so I
don't know whether this was the final coreutils package or one from
commencement.scm.
OK.
If you have a setup for full rebuilds (no substitutes) running in a
container, I’m curious to learn more about it!
Ludo’.
