Hello,
Maxim Cournoyer writes:
> CC: Mark H Weaver, one of the Icecat maintainer.
>
> Hello,
>
> The problem is that local-file doesn't work in Geiser. This breaks
> working at the REPL:
>
> Enter `,help' for help.
> scheme@(guile-user)> ,m (gnu packages linux)
> While executing meta-command:
>
On 2020-10-23, Mathieu Othacehe wrote:
>>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>>> ERROR:
>>> 1. &i/o-filename: "/dev/disk/by-id/mmc-SDU64_0xbaf3002e"
>>
>> Thanks for testing. This is probably a regression in
>> "write-file-on-device" that fails to open this kind of files. I'
Dear,
Let’s describe the use case. Consider that:
guix time-machine -C channels -- install foo
is provided in some documentation, say scientific paper. Where the
channels.scm file is completly described:
--8<---cut here---start->8---
(list (channel
Maxim Cournoyer skribis:
> Lars-Dominik Braun writes:
>
>> Hi Maxim,
>>
>>> Judging from the above, it seems this issue has been resolved.
>> grafting is still a performance issue imo. Compare for example:
>>
>> $ time guix environment --ad-hoc --search-paths r-learnr
>> guix environment --ad-h
Dear guix,
I have configured the guix daemon to use 1 core by default, so that
unattended upgrades and CI jobs will not fill my system memory and
crush my computer.
However, I noticed that in a precise time frame of compiling icecat,
the number of cores were not respected and all my cores were co
If it can be fixed, I can run my packaged Emacs environment on my Android phone.
I executed this command on my x86_64-linux:
guix pack -s aarch64-linux -RR busybox
but it fail:
The following derivation will be built:
/gnu/store/aax96hkd865z2932xlbfrhqrd7zwcyra-proot-static-5.1.0.drv
building
On 2020-10-23, Mathieu Othacehe wrote:
>> I don't quite understand why that would be the issue here; guix system
>> reconfigure works fine when /dev/mmcblkN is specified target in the
>> system config.scm, just not when the target is /dev/disk/by-id/...
>
> I don't think it works fine with /dev/mmc
Hi Maxim,
Maxim Cournoyer skribis:
> The original problem was about the updated Guix package containing a
> faulty hash (due to being computed from a uncontrolled checkout that
> could be dirty). The other concern about preventing the use of a not
> yet published commit was added based on earli
Hi,
Lars-Dominik Braun skribis:
> grafting is still a performance issue imo. Compare for example:
Agreed. The fix in 58bb833365db4e8934a386497d5b00a063cfd27d is
incomplete: we’re still potentially doing things several times.
> $ time guix environment --ad-hoc --search-paths r-learnr
> guix e
Hi Maxim,
> Judging from the above, it seems this issue has been resolved.
grafting is still a performance issue imo. Compare for example:
$ time guix environment --ad-hoc --search-paths r-learnr
guix environment --ad-hoc --search-paths r-learnr 5,90s user 0,09s system 210%
cpu 2,844 total
$ t
Hello Lars,
Lars-Dominik Braun writes:
> Hi Maxim,
>
>> Judging from the above, it seems this issue has been resolved.
> grafting is still a performance issue imo. Compare for example:
>
> $ time guix environment --ad-hoc --search-paths r-learnr
> guix environment --ad-hoc --search-paths r-lear
Good afternoon fearless hacker!
Mathieu Othacehe skribis:
>> ‘process-build-log’ in Cuirass uses ‘read-line/non-blocking’ to read a
>> line from the log port of ‘build-derivations&’. If that really is
>> non-blocking (and I think it is), then we should be fine?
>>
>> We should attach GDB to Cui
Hi,
On Fri, 23 Oct 2020 at 12:05, Ludovic Courtès wrote:
> I think you’re mistaken: :-)
Indeed! Thank you for the explanation.
The manual says (emphasis by me):
References are a subset of the inputs of the derivation; this
subset is AUTOMATICALLY COMPUTED by the build daemon
Hi,
zimoun skribis:
> The command “guix graph postgresql -t bag | dot -Tpdf > /tmp/psql.pdf”
> shows that this ’ld-wrapper-0“ comes from ‘util-linux’. Therefore, is
> it affordable to remove this dependency?
I think you’re mistaken: :-)
--8<---cut here---start
Hello,
>> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>> ERROR:
>> 1. &i/o-filename: "/dev/disk/by-id/mmc-SDU64_0xbaf3002e"
>
> Thanks for testing. This is probably a regression in
> "write-file-on-device" that fails to open this kind of files. I'll try
> to reproduce it locally.
T
Hello,
> I don't quite understand why that would be the issue here; guix system
> reconfigure works fine when /dev/mmcblkN is specified target in the
> system config.scm, just not when the target is /dev/disk/by-id/...
I don't think it works fine with /dev/mmcblkN. I think the bootloader
config
16 matches
Mail list logo
