Looks like I had some typos in the command.
sbcl --non-interactive --eval "(require :asdf)" --eval
"(asdf:load-system:common-lisp-jupyter)"
--eval "(clj:install :use-implementation t :prefix\"bla\" :system t)"
-Tarn Burton
Hello Ludo,
> Does /etc/guix/signing-key.{pub,sec} exist on both machines?
> You can generate it with ‘guix archive’ (info "(guix) Invoking guix
> archive").
Yes, the files are generated by
#+begin_example
sudo guix archieve --generate-key
#+end_example
/etc/guix/signing-key.pub
Hello again,
Earlier, I wrote:
> Are you able to test this patch? One way to do so is to clone the
> master branch of our git repository, apply this patch to the Guix git
> checkout and build it, and then run that modified copy of Guix (without
> installing it) to build icecat.
On second thought
Hi Ignacio,
Ignacio Coterillo writes:
> [Summary]
> - The icecat package doesn't correctly set the LD_LIBRARY_PATH
> variable during the wrap-program build stage to include mit-krb5 libraries
> so kerberos authentication fails as the libraries are not found at runtime:
Thanks for this report.
Build log attached. Using guix commit
154a4e046281c28e39b5016e965d3d937a2ea4a1.
Best,
Jack
z54ykmcn0krv6vx3bc403f1fiinh6c-at-spi2-core-2.34.0.drv.bz2
Description: Binary data
The commit d613c1771a1986d3c0f1e034155fde41f32f9b8e seems to break tests/guix-
environment.sh test for Guix 1.3.0 on Guile 2.2.7.
The line which causes the test to fail is:
(when (zero? (modulo (round (* 100. (/ transferred size))) 10))
When Guile 2.2.7 runs this line, it fails with the error:
Hi Madhavan,
Madhavan Krishnan skribis:
> Hi there, I am trying to follow this instruction [[info:guix#Daemon
> Offload Setup][guix#Daemon Offload Setup]] with guix
> 6086e6ed1a038793e358becddded50d97593f691 on the host and build machine
> to set up a offload build machine, and I end up with the
Hi,
Mathieu Othacehe skribis:
>> Possible improvements are:
>>
>> 1. gracefully handling this error;
>> 2. filtering out read-only storage devices from the menu.
>>
>> Thoughts?
>
> Thanks to David's help[1], I realized that the non-filtering of the
> installation device was causing some of
