‐‐‐ Original Message ‐‐‐
On Sunday, April 7, 2019 6:28 PM, Ludovic Courtès wrote:
> Could check whether it systematically fails to build?
>
> Thank you,
> Ludo’.
I've tried it a few times, it always gives the same result. The --rounds thing
stops after the first failed build, so maybe I'
merge 35181 34157
thanks
I looked more closely at the 'mozjs-60' failures, and I'm convinced that
it's an instance of the same problem that's currently affecting these
large font builds.
Mozjs-60 was pushed to the master branch on 2019-01-18. It has _never_
successfully built on x86_64 or i686,
On Mon, 8 Apr 2019 12:54:14 +0200
Danny Milosavljevic wrote:
> The reason for the error Luther encountered is because something is
> up with the gdm service.
>
> And that's because of
>
> (extend params (compose extensions)))
>
> And I guess the extension/composition mech
Hi Ludovic,
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>> The source checkout currently being transferred for build 3432472
>> (/gnu/store/…-font-google-material-design-icons-3.0.1-checkout) is 176
>> megabytes uncompressed, as measured by "du -s --si", which is not
>> precisely same as
Hi,
Mark H Weaver skribis:
> Hydra's latest attempt to evaluate 'master' failed. Here's the tail of
> the evaluation log:
>
> building path(s) `/gnu/store/103icyz4q7crjxbh71k3vbill3kzjm9n-profile'
> Backtrace:
>7 (apply-smob/1 #)
> In ice-9/boot-9.scm:
> 705:2 6 (call-with-prom
Danny Milosavljevic skribis:
> On Sat, 06 Apr 2019 20:44:45 +
> zna...@disroot.org wrote:
>
>> This is not a bug, but your config is wrong here:
>>
>> (file-systems
>>(cons
>> (file-system (device "my-root")
>> (mount-point "/")
>> (type "ext4")
>>
Please find attached a patch for handling #f file-name.
Alex
>From e6f7d9c4dbbf89284455d6a05488ab952d5374a4 Mon Sep 17 00:00:00 2001
From: Alex Sassmannshausen
Date: Mon, 8 Apr 2019 15:18:23 +0100
Subject: [PATCH] utils: Handle #f file-name.
* guix/utils.scm (current-source-directory): Change di
Hello,
re: /guix/utils.scm:748:
When file-name is #f (e.g. in a geiser repl), the procedure's match
fails. `assq' returns ('filename . #f). This is handled in the match
bodies cond clause, but excluded as possibility by the encapsulating
match clause.
Alex
On Sat, 06 Apr 2019 20:44:45 +
zna...@disroot.org wrote:
> This is not a bug, but your config is wrong here:
>
> (file-systems
>(cons
> (file-system (device "my-root")
>(mount-point "/")
>(type "ext4")
>(title 'label))
> %base-file
Hello,
iyzs...@member.fsf.org (宋文武) skribis:
> Yes, I have the 'rm /run/user/1000/shepherd/socket' workaround in my session
> script too...
I never had to do that because /run is wiped at boot time, like Danny
wrote.
> According to 'man 2 bind', the socket pathname should be deleted when no
> l
Hello,
"Thomas Schmitt" skribis:
> The fact that the VM always sees the expected size but the host sees varying
> sizes supports the suspicion that at the end of the VM its i/o buffers or
> virtual disk are not always properly flushed to the i/o system of the host.
> The varying success smells l
Hi Mark,
Mark H Weaver skribis:
> The source checkout currently being transferred for build 3432472
> (/gnu/store/…-font-google-material-design-icons-3.0.1-checkout) is 176
> megabytes uncompressed, as measured by "du -s --si", which is not
> precisely same as NAR size, but hopefully close enoug
Hydra's latest attempt to evaluate 'master' failed. Here's the tail of
the evaluation log:
--8<---cut here---start->8---
building path(s) `/gnu/store/103icyz4q7crjxbh71k3vbill3kzjm9n-profile'
Backtrace:
7 (apply-smob/1 #)
In ice-9/boot-9.scm:
705
The same jobs that are consistently getting stuck offloading to
hydra.gnunet.org (Hydra's only functional x86 build slave at present)
built successfully on armhf, with build times of 1-2 hours.
With only one x86 build slave and all armhf build slaves on the same
network and running the same ancien
14 matches
Mail list logo
