--verbosity=4 breaks build?

  • Open
  • quality assurance status badge
Details
2 participants
  • Martin Castillo
  • Ludovic Courtès
Owner
unassigned
Submitted by
Martin Castillo
Severity
normal
Merged with
M
M
Martin Castillo wrote on 2 Apr 2018 17:12
(address . bug-guix@gnu.org)
03246993-5134-5605-08f7-5fcea91e5c64@uni-bremen.de
Hi,

I found this while trying to test offloading.
The both attached logs are the results of

guix build grep --no-substitutes -M 1 --verbosity=3 2>buildsuc
guix build grep --no-substitutes -M 1 --verbosity=4 2>builderr
# I aborted the first after a few seconds

The command was executed on guixsd with guix 0.14.0.3450-be5ed.
Using -M 0 it tells me to increase -M or enabled distributed builds,
even though guix offload test succeds. The offload machine is a
raspberry pi. Is guix able to crosscompile when offloading on other
architectures?

Martin
--
GPG: 7FDE 7190 2F73 2C50 236E 403D CC13 48F1 E644 08EC
Attachment: builderr
Attachment: buildsuc
Attachment: signature.asc
L
L
Ludovic Courtès wrote on 2 Apr 2018 23:48
(name . Martin Castillo)(address . castilma@uni-bremen.de)(address . 31023@debbugs.gnu.org)
87y3i5e0vg.fsf@gnu.org
Hello Martin,

As a foreword, note that ‘--verbosity’ is almost useless, even to Guix
developers. I think we should hide it under a weird name, maybe
‘--daemon-debug’?

Martin Castillo <castilma@uni-bremen.de> skribis:

Toggle quote (7 lines)
> I found this while trying to test offloading.
> The both attached logs are the results of
>
> guix build grep --no-substitutes -M 1 --verbosity=3 2>buildsuc
> guix build grep --no-substitutes -M 1 --verbosity=4 2>builderr
> # I aborted the first after a few seconds

I don’t see anything fishy in ‘builderr’. What makes you think it
failed?

Toggle quote (6 lines)
> The command was executed on guixsd with guix 0.14.0.3450-be5ed.
> Using -M 0 it tells me to increase -M or enabled distributed builds,
> even though guix offload test succeds. The offload machine is a
> raspberry pi. Is guix able to crosscompile when offloading on other
> architectures?

Your Raspberry will handle the build if and only if you’re requesting an
armhf-linux build. That is, if your machine is an x86_64 box, you’ll
want to type:

guix build grep -s armhf-linux

in which case the build will go to the Raspberry.

Note that this is *not* cross-compilation. It’s simply native
compilation offloaded to a separate machine.

For cross-compilation, see ‘--target’:


HTH,
Ludo’.
L
L
Ludovic Courtès wrote on 6 Apr 2018 15:12
(name . Martin Castillo)(address . castilma@uni-bremen.de)(address . 31023@debbugs.gnu.org)
871sfs1ns5.fsf@gnu.org
Hello,

Martin Castillo <castilma@uni-bremen.de> skribis:

Toggle quote (3 lines)
> guix build grep --no-substitutes -M 1 --verbosity=4 2>builderr
> # I aborted the first after a few seconds

You’re right about --verbosity=4 interrupting builds, I get:

Toggle snippet (25 lines)
$ guix build --verbosity=4 vim --no-substitutes
[…]
| | building path(s) `/gnu/store/i9smsibsawg6y7bby25iha3q1dkaq7w7-vim-8.0.1428'
| | | found build user `guixbuilder01'
| | | found build user `guixbuilder02'
| | | found build user `guixbuilder03'
| | | found build user `guixbuilder04'
| | | found build user `guixbuilder05'
| | | found build user `guixbuilder06'
| | | found build user `guixbuilder07'
| | | found build user `guixbuilder08'
| | | found build user `guixbuilder09'
| | | found build user `guixbuilder10'
| | | trying user `guixbuilder01'
| | | killing all processes running under uid `30001'
| | | setting up chroot environment in `/gnu/store/ld1kzfb1jyh0jw6yxhprcd3zvj57c986-vim-8.0.1428.drv.chroot'
| | | executing builder `/gnu/store/z2i9srf64afxina1g2bd7k7y8cjqsxrr-guile-2.2.3/bin/guile'
| killing all processes running under uid `30001'
| recursively deleting path `/tmp/guix-build-vim-8.0.1428.drv-0'
| recursively deleting path `/gnu/store/ld1kzfb1jyh0jw6yxhprcd3zvj57c986-vim-8.0.1428.drv.chroot'
| lock released on `/gnu/store/i9smsibsawg6y7bby25iha3q1dkaq7w7-vim-8.0.1428.lock'
| building of `/gnu/store/ld1kzfb1jyh0jw6yxhprcd3zvj57c986-vim-8.0.1428.drv': goal destroyed
guix build: error: build failed: | | | bind mounting `/dev/full' to `/gnu/store/ld1kzfb1jyh0jw6yxhprcd3zvj57c986-vim-8.0.1428.drv.chroot/dev/full'

IOW, the debugging message is interpreted as an error message.

Indeed, if we strace it, we see:

Toggle snippet (17 lines)
read(13, "gmlo\0\0\0\0", 8) = 8
read(13, "_\0\0\0\0\0\0\0", 8) = 8
read(13, "| building of `/gnu/store/ld1kzfb1jyh0jw6yxhprcd3zvj57c986-vim-8.0.1428.drv': goal destroyed\n", 95) = 95
read(13, "\0", 1) = 1
write(2, "| building of `/gnu/store/ld1kzfb1jyh0jw6yxhprcd3zvj57c986-vim-8.0.1428.drv': goal destroyed\n", 95) = 95
read(13, "ptxc\0\0\0\0", 8) = 8
read(13, "w\0\0\0\0\0\0\0", 8) = 8
read(13, "| | | bind mounting `/dev/full' to `/gnu/store/ld1kzfb1jyh0jw6yxhprcd3zvj57c986-vim-8.0.1428.drv.chr--8<---------------cut here---------------end--------------->8---

Normal messages arrive with the “gmlo” prefix, but the “bind mounting”
message arrives with the “ptxc” prefix, which (guix store) interprets as
‘%stderr-error’ and raises an exception right away.

Not sure why we get that “ptxc” prefix.

Ludo’.
M
M
Martin Castillo wrote on 6 Apr 2018 17:32
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 31023@debbugs.gnu.org)
78e7ef4b-63d3-8071-8bcc-c7161e14c267@uni-bremen.de
Hi,

On 02.04.2018 23:48, Ludovic Courtès wrote:
Toggle quote (6 lines)
> Hello Martin,
>
> As a foreword, note that ‘--verbosity’ is almost useless, even to Guix
> developers. I think we should hide it under a weird name, maybe
> ‘--daemon-debug’?

Ok.

Toggle quote (4 lines)
>
> Your Raspberry will handle the build if and only if you’re requesting an
> armhf-linux build.

I'd like to be able to offload any build to other machines/the pi. What
is the reason for only offloading builds that will be native builds on
the offloading machine?

Martin

--
GPG: 7FDE 7190 2F73 2C50 236E 403D CC13 48F1 E644 08EC
L
L
Ludovic Courtès wrote on 11 Nov 2018 18:11
control message for bug #31023
(address . control@debbugs.gnu.org)
87efbrr137.fsf@gnu.org
merge 31023 33343
?
Your comment

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 31023
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