tcsh 6.20.00 testsuite: 68 failed

  • Done
  • quality assurance status badge
Details
2 participants
  • Drashne
  • Ludovic Courtès
Owner
unassigned
Submitted by
Drashne
Severity
normal
D
D
Drashne wrote on 26 Sep 2017 16:18
(name . bug-guix@gnu.org)(address . bug-guix@gnu.org)
MN8joxcHd67Pcyhs4Es-SizL4wmgxgoPZw1k1SEMBATTW2wUYj4ImHmlWg5frlR9cfBO7Vw5mWHyhIemFJ-M5ctJ2ZJ54IU7ylMo7P4Db8M=@protonmail.com
After installing guix-binary-0.13.0.x86_64-linux.tar.xz (on Gentoo amd64 kernel 4.12.12-gentoo) and running "guix package -i glibc-locales", installation of tcsh-6.20.00 failed because of a failed test: "68: nice FAILED (commands.at:896)"

A log of the compile is attached to this email.
Attachment: file
Attachment: guix-package-i-glibc-locales--fail-on-tcsh--2017-09-26.txt
L
L
Ludovic Courtès wrote on 28 Sep 2017 16:17
(name . Drashne)(address . drashne@protonmail.com)(address . 28610@debbugs.gnu.org)
87mv5erjp8.fsf@gnu.org
Hello,

Drashne <drashne@protonmail.com> skribis:

Toggle quote (5 lines)
> After installing guix-binary-0.13.0.x86_64-linux.tar.xz (on Gentoo amd64 kernel 4.12.12-gentoo) and running "guix package -i glibc-locales", installation of tcsh-6.20.00 failed because of a failed test: "68: nice FAILED (commands.at:896)"
>
> A log of the compile is attached to this email.
> % guix package -i glibc-locales --no-substitutes

You could run this command with an additional “--keep-failed” flag, and
then, retrieve and post the ‘testsuite.log’ file from
/tmp/guix-build-tcsh-6.20.00.drv-0?

That should allow us to see more precisely why this test is failing.

Thanks for your report,
Ludo’.
D
D
Drashne wrote on 29 Sep 2017 04:27
(name . ludo@gnu.org)(address . ludo@gnu.org)(name . 28610@debbugs.gnu.org)(address . 28610@debbugs.gnu.org)
uWUqgw2ftEGB2mH2i6hW5izv2W__D1fhNur0tG3Af2M8f28C3-G4SxmdSb-hhsj6inmXft8MfmsdbUs92bGotO9VKNwx6nKf003bL1x28YY=@protonmail.com
Hello Ludo',

Thank you for looking in to this.

The 'testsuite.log' file you requested is attached.

I noticed that in the "Detailed failed tests" section, it has:

68. commands.at:893: testing nice ...
./commands.at:896: tcsh -f -c 'nice set var=1; echo $?var'
--- /dev/null 2017-09-22 17:50:11.102758003 +0000
+++ /tmp/guix-build-tcsh-6.20.00.drv-0/tcsh-6.20.00/testsuite.dir/at-groups/68/stderr 2017-09-29 01:59:18.591958887 +0000
@@ -0,0 +1 @@
+setpriority: Permission denied.
68. commands.at:893: 68. nice (commands.at:893): FAILED (commands.at:896)

So at first glance the failure appears to be caused by "setpriority: Permission denied"

I'm not sure why there'd be a permissions problem. I have the guix-daemon running as root, with the following arguments:

/root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild --no-substitutes

I thought maybe it's the guixbuilder user that's having permissions problems, so I tried running the failing test myself as the guixbuilder01 user:

> sudo -u guixbuilder01 /gnu/store/nrrwyb21bn8cdc0k6pis3ggs2vayibin-bash-4.4.12/bin/bash
bash-4.4$ cd /var/tmp/guix/guix-build-tcsh-6.20.00.drv-0/tcsh-6.20.00
bash-4.4$ . ../environment-variables
bash-4.4$ ./tcsh -f -c 'nice set var=1; echo $?var'
0

So the test appears to work when I run it manually, but fails when it's run as part of the build process under guix-daemon.

Also, please note that /var/tmp/guix is my guix build directory, which I've set for guix-daemon via the TMPDIR environment variable. I have a zram filesystem mounted on /var/tmp/guix as ext4, but I've tried the same "guix package -i glibc-locales" without the zramfs, on my root xfs filesystem and it didn't make any difference.

Toggle quote (25 lines)
> -------- Original Message --------
> Subject: Re: bug#28610: tcsh 6.20.00 testsuite: 68 failed
> Local Time: September 28, 2017 7:17 AM
> UTC Time: September 28, 2017 2:17 PM
> From: ludo@gnu.org
> To: Drashne <drashne@protonmail.com>
> 28610@debbugs.gnu.org
>
> Hello,
>
> Drashne <drashne@protonmail.com> skribis:
>
>> After installing guix-binary-0.13.0.x86_64-linux.tar.xz (on Gentoo amd64 kernel 4.12.12-gentoo) and running "guix package -i glibc-locales", installation of tcsh-6.20.00 failed because of a failed test: "68: nice FAILED (commands.at:896)"
>>
>> A log of the compile is attached to this email.
>> % guix package -i glibc-locales --no-substitutes
>
> You could run this command with an additional “--keep-failed” flag, and
> then, retrieve and post the ‘testsuite.log’ file from
> /tmp/guix-build-tcsh-6.20.00.drv-0?
>
> That should allow us to see more precisely why this test is failing.
>
> Thanks for your report,
> Ludo’.
Attachment: file
Attachment: testsuite.log
L
L
Ludovic Courtès wrote on 29 Sep 2017 09:55
(name . Drashne)(address . drashne@protonmail.com)(name . 28610@debbugs.gnu.org)(address . 28610@debbugs.gnu.org)
87y3oyuefv.fsf@gnu.org
Hello,

Drashne <drashne@protonmail.com> skribis:

Toggle quote (16 lines)
> Thank you for looking in to this.
>
> The 'testsuite.log' file you requested is attached.
>
> I noticed that in the "Detailed failed tests" section, it has:
>
> 68. commands.at:893: testing nice ...
> ./commands.at:896: tcsh -f -c 'nice set var=1; echo $?var'
> --- /dev/null 2017-09-22 17:50:11.102758003 +0000
> +++ /tmp/guix-build-tcsh-6.20.00.drv-0/tcsh-6.20.00/testsuite.dir/at-groups/68/stderr 2017-09-29 01:59:18.591958887 +0000
> @@ -0,0 +1 @@
> +setpriority: Permission denied.
> 68. commands.at:893: 68. nice (commands.at:893): FAILED (commands.at:896)
>
> So at first glance the failure appears to be caused by "setpriority: Permission denied"

Per setpriority(2), the only was this can happen is if we’re trying to
set a nice value lower than the current one:

EACCES The caller attempted to set a lower nice value (i.e., a higher process priority), but did not have
the required privilege (on Linux: did not have the CAP_SYS_NICE capability).

Could it be that you’re running the daemon with “nice guix-daemon …” or
something like that?

Thanks,
Ludo’.
D
D
Drashne wrote on 29 Sep 2017 19:22
(name . ludo@gnu.org)(address . ludo@gnu.org)(name . 28610\@debbugs.gnu.org)(address . 28610@debbugs.gnu.org)
qf4BXZQBPRXNft3iLkodLCY9-beCgHy5rDKAH2KAsgCLyvCXp685YSVwL4LLdi6yoaM7EtNqKAaRbwtppStmTJBOvDK-MICv0FUagz71HXw=@protonmail.com
Toggle quote (5 lines)
> Ludo wrote:
>
> Could it be that you’re running the daemon with “nice guix-daemon …” or
> something like that?

You're right!

I had set up my guix-daemon startup script to start it as "/usr/bin/nice /usr/bin/ionice -c3 /root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild --no-substitutes" but when troubleshooting this I blindly looked right through the "/usr/bin/nice /usr/bin/ionice -c3" part and just focused on the guix-daemon and its arguments.

After noticing this, I tried running guix-daemon without nicing or ionicing it, and rerunning "guix package -i glibc-locales" which now successfully built and tested tcsh, and is currently continuing to build other packages necessary for the installation of glibc-locales.

Thank you so much for your help.
Attachment: file
L
L
Ludovic Courtès wrote on 1 Oct 2017 23:58
(name . Drashne)(address . drashne@protonmail.com)(name . 28610@debbugs.gnu.org)(address . 28610@debbugs.gnu.org)
87vajypm39.fsf@gnu.org
Hello Drashne,

Drashne <drashne@protonmail.com> skribis:

Toggle quote (4 lines)
> I had set up my guix-daemon startup script to start it as "/usr/bin/nice /usr/bin/ionice -c3 /root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild --no-substitutes" but when troubleshooting this I blindly looked right through the "/usr/bin/nice /usr/bin/ionice -c3" part and just focused on the guix-daemon and its arguments.
>
> After noticing this, I tried running guix-daemon without nicing or ionicing it, and rerunning "guix package -i glibc-locales" which now successfully built and tested tcsh, and is currently continuing to build other packages necessary for the installation of glibc-locales.

Great, thanks for testing!

It’s one of these rare cases where details about the host system leak
into the build environment, and picky test suites immediately notice.

Ludo’.
L
L
Ludovic Courtès wrote on 1 Oct 2017 23:58
control message for bug #28610
(address . control@debbugs.gnu.org)
87tvzipm2r.fsf@gnu.org
tags 28610 notabug
close 28610
?
Your comment

This issue is archived.

To comment on this conversation send an email to 28610@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 28610
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch