Hi!
The substitute served at
https://mirror.hydra.gnu.org/guix/nar/gzip/6lcsaddzj6q3facaidajc6ws0yp0m3dq-mpfr-3.1.5
appears to be corrupted:
Downloading
https://mirror.hydra.gnu.org/guix/nar/gzip/6lcsaddzj6q3facaidajc6ws0yp0m3dq-mpfr-3.1.5
(1.6MiB installed)...
mpfr-3.1.5
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> BTW, what timestamps to we put on the modified files? We want that to
>> be deterministic so we cannot use the build time. We cannot use a date
>> in the future, either. We cannot use Jan. 1 1970 either because that
>> means
l...@gnu.org (Ludovic Courtès) writes:
> BTW, what timestamps to we put on the modified files? We want that to
> be deterministic so we cannot use the build time. We cannot use a date
> in the future, either. We cannot use Jan. 1 1970 either because that
> means that modified files may now be o
I guess I can do: find -name '*.go' --delete
On May 3, 2017 12:05:04 PM PDT, Efraim Flashner wrote:
>On Wed, May 03, 2017 at 11:59:16AM -0700, Maxim Cournoyer wrote:
>> After doing 'guix pull' to get latest master branch, `guix
>environment
>> guix' fails while compiling the new sources:
>>
>> Backtrace:
>> In ice-9/r4rs.scm:
>> 39: 19 [c
Indeed.
On 03/05/17 20:59, Maxim Cournoyer wrote:
> After doing 'guix pull' to get latest master branch, `guix environment
> guix' fails while compiling the new sources: [...]
Reverting dcb95c1fc936d74dfdf84b7e59eff66cb99c5a63 seems to fix it.
Kind regards,
T G-R
signature.asc
Description: O
On Wed, May 03, 2017 at 11:59:16AM -0700, Maxim Cournoyer wrote:
> After doing 'guix pull' to get latest master branch, `guix environment
> guix' fails while compiling the new sources:
>
> Backtrace:
> In ice-9/r4rs.scm:
> 39: 19 [call-with-values #
> ...]
> In ice-9/eval.scm:
> 411: 18 [eval
This bug still exists if one installs Scribus through Guix in a foreign
system distribution. Even though I still have both LD_LIBRARY_PATH and
PYTHONPATH variables unset and I don't have Python installed through
Guix.
However, today I decided to test with:
$ guix environment --ad-hoc scribus pyth
After doing 'guix pull' to get latest master branch, `guix environment
guix' fails while compiling the new sources:
Backtrace:
In ice-9/r4rs.scm:
39: 19 [call-with-values # ...]
In ice-9/eval.scm:
411: 18 [eval # #]
411: 17 [eval # #]
In srfi/srfi-1.scm:
573: 16 [map # (# # # # ...)]
In ice-9
Jelle Licht skribis:
> I had some problems getting current ansible package to work. It seems that
> the bin/ansible script which is created as part of the python-build-system
> via a call to `wrap-program' interferes with certain expectations ansible
> has regarding how it and its subcommands are
Hello,
Mark H Weaver skribis:
> Actually, IIUC, the build slaves are _already_ compressing everything,
> and they always have. They compress the build outputs for transmission
> back to the master machine. In the current framework, the master
> machine immediately decompresses them upon receip
Clément Lassieur skribis:
> Ludovic Courtès writes:
>
>> Clément Lassieur skribis:
>>
>>> I tried to patch 'patch-and-repack', but it triggers a full
>>> rebuild... WDYT?
>>
>> Right, it’s expected to trigger a full rebuild, so this should be fixed
>> in ‘core-updates’.
>
> Yes, but is there a
Reviving an old thread...
Tobias Geerinckx-Rice writes:
>> IMO, the best solution is to *never* generate nars on Hydra in response
>> to client requests, but rather to have the build slaves pack and
>> compress the nars, copy them to Hydra, and then serve them as static
>> files using nginx.
>
>
13 matches
Mail list logo
