Hello Tobias,
> * gnu/packages/firmware.scm (sof): New public variable.
Thanks for the package definition. Last time I checked, some devices
required signed firmware:
--8<---cut here---start->8---
The firmware file, /lib/firmware/intel/sof/sof-tgl.ri,
Hello Ben,
> Thanks for your help on the Guix IRC yesterday! I'm still struggling
> with getting the VM running as I'd like. I tried the ISO format as you
> suggested, but my hosting service (Binary Lane) seems to treat this
> somewhat-specially as a read-only format. I can "trick" it into
>
Hello Thiago,
> +;; LuaJIT is not ported to powerpc64le* yet.
> +(if (string-prefix? "powerpc64le"
> +(or (%current-target-system)
> +(%current-system)))
> +
Hey,
> Everything works perfectly! (notice: I only tried until the installer
> generated the /etc/config.scm file).
Glad to hear that :).
> 2. I found a problem: if, during the manual partitioning, you delete a free
> space (by mistake), the installation crashes (see picture) and you have
Hey,
> Both tests fail with the strange message that the installer cannot access the
> sdb2 partition where the guix installer is (see picture 3)
Oh, I see. It should now be fixed with:
e12be802e02b3345a753e7ec1287852a7337a0a5.
It would be great if you could test this new installation
Hello,
> please find attached a picture of my screen of the error page.
Great, thanks. This looks very much like this issue:
https://issues.guix.gnu.org/44872 and could be fixed by
154a4e046281c28e39b5016e965d3d937a2ea4a1.
Would it be possible for you to try to reproduce the issue with this
Hello Christophe,
This is most likely yet another installer partitioning issue. Do you
think you could send us a copy of the error page? You can do it by
taking a picture of your screen, or better, by accessing the
"/tmp/last-installer-error" file that should contain the backtrace after
the
Hey,
>> This release corresponds to 8,300 commits over almost 6 months by 212
>> people. Support for the POWER9 platform is now offered as technological
>> preview. This release adds new features, refines the user experience
>> and improves performance. It also includes many new packages and
Hello Vincent,
> when connecting to "https://$IP:8081/;, I get:
>
> SSL_ERROR_RX_RECORD_TOO_LONG
I think you should try "$IP:8081" instead. The Cuirass web server is not
configured to handle HTTPS. You would need to setup an Nginx reverse
proxy as here:
> Now the VM is running.
> Sorry for bothering you with this.
No worries, in fact I was thinking yesterday about adding the user by
default to the "kvm" group when running the installer, to prevent this
kind of issues.
Mathieu
Hello Jérémy,
> $ /gnu/store/dxrwz82s34zi33n9h9cpn8sqw5pv4qyz-run-vm.sh
> Could not access KVM kernel module: Permission denied
> qemu-system-x86_64: failed to initialize kvm: Permission denied
Are you part of the "kvm" group yourself?
Mathieu
Hey Joshua,
> I believe that these issues have been closed. I suppose we could write
> a blog post, if you believe that would be worth while.
Yes they were indeed. It would be nice but it's not on my list right
now. I you feel like writing it, I would happily review it :).
Thanks,
Mathieu
Hello,
> Now that we've got this bit included in the cookbook, would you be in
> favor of also turning it into a guix blog post? I'd be happy to submit
> a patch.
I think that the cookbook is a nice achievement for now. Maybe we could
postpone the guix blog article until the pending image
Hello,
Thanks for this contribution! You should submit patches to
"guix-patc...@gnu.org" instead of this mailing list.
There's also a small issue with the commit message which is placed as
title of this email.
> +* Guix System Image API::Customizing the disk-image to target
>
Hello,
> This is really well written. May I edit this article and reproduce it
> for the guix blog and perhaps the guix manual? If ludo's ok with me
> putting it on the blog, then I intend to end the blog post with "This
> article first appeared in this personal blog (link here) and is
>
Hello Christopher,
> I haven't tried it yet but can't think of a good reason it wouldn't
> work. Has anyone tried that?
Sure, I would advise you to read this[1], which is a sort of follow-up
of this article. You can also listen that talk[2].
I have been successfully producing ready to use
Hello Ben,
> I realise there's lower-level tools like "guix system init" you could use if
> you were happy to partition and format the new drive manually, but it would be
> such a great user experience to leverage the existing graphical installer from
> withing Guix System.
The graphical
Hello Jesse,
> -> Which board did you get working with guix system (banana pi m2u, novena,
> beaglebone black, pine64-plus, etc.)?
> -> Did you build natively or cross-build from a different system?
> -> What version of guix did you use? (what did guix describe say?)
> -> If the board you got
Hello,
> I was missing that, thank you. Unfortunately, it did not change the
> error.
That's unfortunate. I tried the following specification:
--8<---cut here---start->8---
(list '((#:name . "my-packages"
(#:load-path-inputs . ("guix"))
> If I clone it and run your commands I do not get an error (I edited the
> notes about source file newer than compiled):
You also need to add "divoplade-site" to "#:package-path-inputs" in the
specifications.
See the following snippet from Cuirass info page:
--8<---cut
Running this:
--8<---cut here---start->8---
mathieu@cervin:~/tmp$ GUIX_PACKAGE_PATH=pomdappi/ guix repl
scheme@(guix-user)> ,use (gnu) (guix store) (gnu ci)
scheme@(guix-user)> (define s (hydra-jobs (open-connection) '((subset
"pomdappi") (systems
Hello,
> See https://ci.divoplade.fr/eval/1/log/raw
Sadly the log isn't helpful, could you share your specification?
Thanks,
Mathieu
Hello,
> My log file alternates between "building 0 derivations" and "failed to
> connect to git.savannah.gnu.org: Connection timed out".
The first message is probably a consequence of the second. Make sure
that nss-certs is available in the root profile.
You can also try to setup a Guix
Hello divoplade,
> How should I do it?
Writing the appropriate specification is quite tricky and I plan to
write a shepherd service to make it easier. In the meantime, something
like that should get you closer:
--8<---cut here---start->8---
(define
Hello Andreas,
> In unknown file:
>1 (primitive-load-path "gnu/system/pam" #)
> In /run/current-system/profile/share/guile/site/3.0/gnu/system/pam.scm:
> 303:2 0 (_)
>
> /run/current-system/profile/share/guile/site/3.0/gnu/system/pam.scm:303:2:
> error: service-type: unbound
Sorry, this:
> ((drv (lower-object (system-image my-image "armhf-linux")))
should instead be:
--8<---cut here---start->8---
((drv (lower-object (system-image my-image) "armhf-linux"))
--8<---cut
Hello Andreas,
> The appearance of "efi" and "grub" is suspicious.
>
> I do have this in my config:
> (bootloader (bootloader-configuration
>(bootloader u-boot-novena-bootloader)
>(target "/dev/mmcblk0")))
> So there is no trace of grub or efi in it. Does
Hello,
> Any tips on how to deal with this? I haven't got a clue about why it
> does this stuff.
I've experienced this behavior when there are some edited .po files. I
usually run "git checkout -- *.po" to get rid of them. You could maybe
share the output of "git status" when you are having
Hey,
> +(define-public linux-libre-with-bpf
> + (make-linux-libre* linux-libre-5.4-version
> + linux-libre-5.4-source
> + '("x86_64-linux" "i686-linux" "armhf-linux"
> "aarch64-linux" "riscv64-linux")
> + #:extra-version "bpf"
> +
Hello John,
Thanks for this serie, a few remarks below.
> +(define-public libbpf
> + (let* ((commit "6a1615c263b679c17ecb292fa897f159e826dc10"))
Why using a specific commit?
> +(package
> + (name "libbpf")
> + (version "0.0.8")
The "0.0.9" is out there :)
> + (source
>
Hello John,
> ld:
> /gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libbfd.a(compress.o):
> undefined reference to symbol 'inflateEnd'
> ld:
> /gnu/store/80y2wbx9lrhvwp41nnyjjsb4g9ff8avn-clang-toolchain-9.0.1/lib/libz.so.1:
> error adding symbols: DSO missing from
Hello John,
> /tmp/guix-build-bcc-0.14.0.drv-0/source/src/cc/libbpf.c:694:58: error:
> ‘BPF_PROG_TYPE_EXT’ undeclared (first use in this function); did you mean
> ‘BPF_PROG_TYPE_XDP’?
>if (prog_type != BPF_PROG_TYPE_TRACING && prog_type != BPF_PROG_TYPE_EXT)
>
Hello John,
> I was in the mood to try some of these new bpf tools. Does the linux libre
> kernel support it?
Yes it should support it, plus according to this[1], we have the right
Kernel configuration (except maybe for CONFIG_BPF_JIT).
Now, it's just a matter of packaging "bcc" and
Hello Pierre,
> Is there a way to calculate the closure size of a system (as generated
> by guix system reconfigure config.scm)?
Yes, you can pass '-d' to 'guix system' to get the matching
derivation. Then you can pass this derivation to 'guix size'.
Mathieu
Hello John,
> I have a lot to learn about services! Seems nice so far. Do you know if
> there will be any more development on kmscon or is it only in maintenance?
The original author David Herrmann seems to have stop kmscon
developments in 2014. Guix now uses the forked kmscon package
Hi John,
I built the new GuixSD installer upon kmscon. It works pretty well and
is a good alternative to raw linux VT's in my opinion.
> (modify-services
> %desktop-services
> ('kmscon c => (kmscon-configuration (virtual-terminal
> "tty8"))
modify-services
Hi Pierre,
This might not be correct, depending on which Make and the Makefile.
> Lowercase "prefix" is actually the right directory variable for GNU Make.
> See the "(make) Directory Variables" info page.
>
In that precise case, without an upper case PREFIX, it won't build (check
the root
Hi Guy,
Your package is almost working, the important thing was to specified
"ncurses" as an input like you did.
> on debian it works because -lcurses is a symlink to -lncurses(if i am
> not wrong)
Yes, I guess they are doing some kind of symlinking. To make it work,
you can replace -lcurses
Hi Björn,
The Cuirass documentation should still be improved, so I understand your
questions. Here are some answers, feel free to improve the manual
afterwards :)
> * What should the procedure #:proc return?
The procedure #:proc takes exactly two arguments, the guix store and
an association
Hi,
I ran into the same problem on a very powerful machine. In my case the
congestion test was the problem. It finished by eating all of my 128Gb of
RAM.
This problem is known and fixed upstream by disabling the test. I submitted
a patch to disable it on our 3.6.5 version, but it will have to go
Hello,
I tought this one was pushed and told Clément it was ok to push, my
mistake! I just pushed it, so I close the ticket now.
To people used to select bootloader entries with shortcuts, be aware
that at next reconfigure, the entries will be reversed on all
bootloaders (top of the list =>
Hi Guix,
I setup my own cuirass server to build guix-modular, here's how:
--8<---cut here---start->8---
(define (build-guix-modular store arguments)
(let* ((source (assq-ref arguments 'file-name))
(revision (assq-ref arguments 'revision))
Hi,
> The error message refers to some bare-bones template which Mathieu changed
> recently - but I merged it to wip-installer-2 some days ago. Also, it works
> for me.
>
> Are you sure you don't have uncommitted changes in your working copy?
I just built successfully wip-installer-2 branch.
> ERROR: In procedure %resolve-variable:
> ERROR: Unbound variable: %intel-compatible-systems
My bad, this has been fixed by Efraim in
d8f075c3a3daba93ff4420bbe0b1833712aaa0e9.
You may want to guix pull again !
Sorry,
Mathieu
Hi,
> I think `menu-entries' should be a list. Try
>
> (menu-entries (list (menu-entry [...])))
Thomas is right, I just tried it with the following configuration and it
works for me :
--8<---cut here---start->8---
(bootloader (grub-configuration (device
45 matches
Mail list logo
