Re: Regarding implementing sof-firmware in GUIX.

[Mathieu Othacehe]

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, contains all DSP
code and tables. On PCI devices, the firmware can only be signed by an
Intel production key which prevents community users from installing
their own firmware. Notable exceptions include Google Chromebooks and
Up2/Up-Extreme boards, where the community key is used.
--8<---cut here---end--->8---

I'm not sure what's the point of letting users build their firmware if
it cannot be loaded. Looks like multiple projects are in fact packaging
the signed sof firmware, which is non-free[2].

Thanks,

Mathieu

[1]: 
https://thesofproject.github.io/latest/getting_started/intel_debug/introduction.html
[2]: https://packages.debian.org/search?keywords=firmware-sof-signed

Re: Guix on a cloud VM

[Mathieu Othacehe]

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
> restoring from this image using their "clone" feature though. The
> machine boots up fine but the result seems to be a read-only Guix where
> /etc/fstab shows an iso9660 filesystem.

Yeah, the read-only partition is imposed by Guix itself. The 
record has a "volatile-root?" field that defaults to true. This means
that an overlayfs backed with a tmpfs partition is created for the ROOT
partition. You can have a look to the "mount-root-file-system" procedure
of the (gnu build linux-boot) module.

I don't think that iso9660 is the appropriate format for what you are
trying to achieve anyway, as you probably want changes to the image to
be made persistent.

> Backing up a little for context, I've tried qcow2 format which is lovely
> and small, but fails to boot on my hosting service with "No bootable
> devices".

Oh, too bad. You could maybe contact Binary Lane support to find out
why? Have you tried to boot your qcow2 image on your machine with QEMU?
The command line would look like the one presented here:
https://guix.gnu.org/manual/en/html_node/Installing-Guix-in-a-VM.html.

> I've also tried efi-raw which boots and runs smoothly, but fails to
> resize later on my hosting service. (Resize is required because
> otherwise I literally have to generate and upload a 20GB image.) I
> suspect (but don't know for sure) that this is related to the additional
> 40M EFI partition created in the image before the root EXT4 partition.
> The images provided by my hosting service only have a single EXT4
> partition eg. Debian 10.
>
> Do you know if it's possible to get `guix system image` to skip the EFI
> partition when creating an efi-raw image?

No it is not possible currently, due to how Grub is installed on Guix
System images. However, you should be able to resize your partition
manually using fdisk and resize2fs, see below :).

> Does the process in your blog post work for you if you go straight to
> QCOW2 with `--image-type=QCOW2` rather than converting the efi-raw to
> qcow2?

Yes, the --image-type=qcow2 option was introduced after the blog post
writing, it should be equivalent.

> Are you able to later resize the storage via your DigitalOcean control
> panel? This operation is failing for me currently.

I had a root partition smaller than the disk size, and managed to resize
it following those instructions:
https://askubuntu.com/questions/24027/how-can-i-resize-an-ext-root-partition-at-runtime.

Be sure that you answer "N" to that question:

--8<---cut here---start->8---
Do you want to remove the signature? [Y]es/[N]o: N
--8<---cut here---end--->8---

Thanks,

Mathieu

Re: help with use of %current-target-system parameter and gexps

[Mathieu Othacehe]

Hello Thiago,

> +;; LuaJIT is not ported to powerpc64le* yet.
> +(if (string-prefix? "powerpc64le"
> +(or (%current-target-system)
> +(%current-system)))
> +(substitute* fmtutilcnf
> +  (((string-append "^(luajittex|luajithbtex|mfluajit)") 
> m)
> +   (string-append "#! " m
>  ;; Register SHARE as TEXMFROOT in texmf.cnf.
>  (substitute* texmfcnf
>(("TEXMFROOT = \\$SELFAUTOPARENT")
>

The issue here is that the %current-target-system and %current-system
are not defined at build time. You need to force their evaluation by
using "unquote", this way:

--8<---cut here---start->8---
(arguments
 `(#:phases
   ...
   (if (string-prefix? "powerpc64le"
  ,(or (%current-target-system)
   (%current-system)))
  ...)))
--8<---cut here---end--->8---
>
> +#~(let-system (system target)
> +;; LuaJIT is not ported to powerpc64le* yet.

Here also you need to unquote this part, using "ungexp":

--8<---cut here---start->8---
   #$(let-system (system target)
  ...
--8<---cut here---end--->8---

Thanks,

Mathieu

Re: partition table on guix system

[Mathieu Othacehe]

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 to 
> start again from the beginning (language choice). I had the same problem with 
> the official 1.3 installation image.
>
> Besides, I have three things to share (either with the 1.2, 1.3 or the one 
> tested today). I hesitated to do three separate emails, but I may have 
> misunderstood something about the installation process and don't want to 
> pollute the guix email.

No that's a legitimate bug report! Could you please send a mail to
bug-g...@gnu.org about that one, so that it is easier for us to track
it?

> A. About the time zone configuration: when you start the installation process 
> from a reboot, you have to select the city with the arrows (and not by typing 
> the first letter of the city: example Europe/Zurich) but when you interrupt 
> an installation and start again from the beginning (=
> the choice of the installation language), when you get to the choice of the 
> time zone, you can type in the first letter of the city and the installer 
> selects directly the city that starts with this letter. It is not a problem 
> concerning the choice of the time zone but rather that the process
> of resuming the installation from the language does probably not completely 
> start from the beginning (?). I just wanted to point it out.

That's strange, letter based selection is supposed to be active from the
start, I'll check why.

> B. I would find it very useful if the installer offered to set up a print 
> cups service when selecting services. Editing the /etc/config.scm file to set 
> up cups is the first thing I do after any installation. 

It has been reported here: https://issues.guix.gnu.org/38161. We should
definitely add it.

> C. About the choice of the keyboard layout "fr_CH.utf8": strangely (i.e. 
> contrary to debian installer for example), you have to choose "German 
> (Switzerland)" first and then the variant "French (Switzerland)". It is not 
> intuitive to choose a "French (Switzerland)" keyboard in the
> "German (Switzerland)" category. The debian installer proposes directly the 
> keyboard "fr_CH.utf8" when you choose the regional settings Switzerland / 
> French. 

We are following the structure dictated by the xkeyboard-layout package,
I don't remember exactly how the Debian installer deals with it, but
I'll check it.

Thanks for your help,

Mathieu

Re: partition table on guix system

[Mathieu Othacehe]

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 image:
https://ci.guix.gnu.org/download/357.

Thanks for your patience,

Mathieu

Re: partition table on guix system

[Mathieu Othacehe]

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
installation image: https://ci.guix.gnu.org/download/331.

Thanks,

Mathieu

Re: partition table on guix system

[Mathieu Othacehe]

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 crash.

You can then send it with scp to another machine of your local network
running an SSH server, or use a flash drive for instance.

If you manage to fetch the error message, sending a bug report at
bug-g...@gnu.org would be great.

Thanks for your help,

Mathieu

Re: GNU Guix 1.3.0 released

[Mathieu Othacehe]

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
>> services along bug fixes--see below for a list of changes.

Congrats! It's amazing to see how much has been achieved in six
months. Special thanks to Ludo and Maxim for your dedication and hard
work that made this release possible :).

Mathieu

Re: local cuirass

[Mathieu Othacehe]

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: https://git.savannah.gnu.org/cgit/guix/maintenance.git/.

Thanks,

Mathieu

Re: [Guix System] Can't run VM script because of KVM kernel module permission

[Mathieu Othacehe]

> 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

Re: [Guix System] Can't run VM script because of KVM kernel module permission

[Mathieu Othacehe]

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

Re: Single-board-computer approach: don't make an installer, make the install?

[Mathieu Othacehe]

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

Re: Single-board-computer approach: don't make an installer, make the install?

[Mathieu Othacehe]

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 command line
patches are pushed[1] and the relevant Guix documentation is written?

Thanks,

Mathieu

[1]:
https://issues.guix.gnu.org/45986
https://issues.guix.gnu.org/46017

Re: [PATCH] * doc/guix-cookbook.texi (Guix System Image API): new section

[Mathieu Othacehe]

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 
> specific platforms.

Customizing disk images to target specific platforms, maybe?

> +@itemize @bullet
> +@item
> +- @file{gnu/system/images/hurd.scm}

You can remove the dash here.

> +@example
> +guix system disk-image my-os.scm
> +@end example

I have a pending patchset renaming "disk-image" command to "image". We
will need to update it accordingly.

Otherwise, it looks nice to me, but I may be biased here. It would be
nice if someone else could have a look.

Thanks,

Mathieu

Re: Single-board-computer approach: don't make an installer, make the install?

[Mathieu Othacehe]

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
> reproduced with permission."

Thanks! I would happily review it :).

There's for sure some work left on that topic. I'd like to:

* Rename "disk-image" command to "image".
* Add "docker" as a new image type.
* Find a better way to enforce system/target constraints, as discussed
here[1].

Mathieu

[1]: https://issues.guix.gnu.org/45020

Re: Single-board-computer approach: don't make an installer, make the install?

[Mathieu Othacehe]

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 disk-images for Pine64,
Danny has done the same for Novena and there are a few people trying to
do so for their Pinebook-pro.

Thanks,

Mathieu

[1]: https://othacehe.org/the-guix-system-image-api.html
[2]: https://archive.fosdem.org/2020/schedule/event/ggaaattyp/

Re: Running graphical install inside existing Guix System

[Mathieu Othacehe]

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 installer relies on some services such as kmscon to change
the keyboard layout and connman to connect to the internet for
instance. If we were to add a "guix install" command, then we would need
to make sure that we run in the same environment as the one described in
"gnu/system/install.scm". I agree that it would be an interesting
feature for your use-case or to perform some quick tests on the
installer.

In the meantime, you can start a VM running the installer and using your
target drive but that wouldn't be a much better solution than rebooting
on a flash drive I guess.

Thanks,

Mathieu

Re: Who has had success installing a Guix system on arm?

[Mathieu Othacehe]

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 working can boot from an internal (emmc) or external
>   (microsd) drive, which one did you get working?
> -> Would you mind sharing the operating-system definition that was successful?

The situation is slowly improving. Since recently, you should be able to
build a barebones image for pine64 lts this way:

--8<---cut here---start->8---
guix system disk-image -t pine64-raw os.scm
--8<---cut here---end--->8---

with os.scm that looks like:

--8<---cut here---start->8---
(use-modules (gnu system images pine64))

pine64-barebones-os
--8<---cut here---end--->8---

Note that this very image is also build by the CI and available here:

https://ci.guix.gnu.org/search/latest/image?query=spec:guix-master+status:success+system:x86_64-linux+pine64

You should be able to flash this image on a microsd and directly boot
from it.

I will try to improve the documentation accordingly, but until then you
can also read this:

https://othacehe.org/the-guix-system-image-api.html.

Thanks,

Mathieu

Re: Configuration for Cuirass

[Mathieu Othacehe]

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"))
   (#:package-path-inputs . ("divoplade-site"))
   (#:proc-input . "guix")
   (#:proc-file . "build-aux/cuirass/gnu-system.scm")
   (#:proc . cuirass-jobs)
   (#:proc-args (subset "pomdappi" "update-gandi" "index-page" 
"orange-livebox-ipv4"))
   (#:inputs . (((#:name . "divoplade-site")
 (#:url . "file:///home/mathieu/tmp/divoplade-site/")
 (#:load-path . ".")
 (#:branch . "master")
 (#:no-compile? . #t))
((#:name . "guix")
 (#:url . "git://git.savannah.gnu.org/guix.git")
 (#:load-path . ".")
 (#:branch . "master")
 (#:no-compile? . #t
   (#:build-outputs . (
--8<---cut here---end--->8---

by running Cuirass with the following command:

--8<---cut here---start->8---
./pre-inst-env cuirass -S ~/tmp/test.scm -D test.db
--8<---cut here---end--->8---

directly from a Cuirass checkout. It works fine here, not sure what's
wrong with the service.

Mathieu

Re: Configuration for Cuirass

[Mathieu Othacehe]

> 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 here---start->8---
‘package_path_inputs’
 This field holds a list of input names whose load path is prepended
 to ‘GUIX_PACKAGE_PATH’ when evaluating ‘proc_file’.
--8<---cut here---end--->8---

Mathieu

Re: Configuration for Cuirass

[Mathieu Othacehe]

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 "x86_64-linux"
--8<---cut here---end--->8---

gives several errors:

--8<---cut here---start->8---
evaluating for 'x86_64-linux' (heap size: 43.0 MiB)...
guix repl: warning: failed to load '(gen-hall)':
no code for module (gen-hall)
hint: File `pomdappi//gen-hall.scm' should probably start with:

 (define-module (gen-hall))

guix repl: warning: failed to load '(guix divoplade services pomdappi)':
no code for module (divoplade packages pomdappi)
pomdappi//guix/divoplade/services/pomdappi.scm:1:0: warning: module name 
(divoplade services pomdappi) does not match file name 
'guix/divoplade/services/pomdappi.scm'
hint: File `pomdappi//guix/divoplade/services/pomdappi.scm' should probably 
start with:

 (define-module (guix divoplade services pomdappi))

;;; note: source file pomdappi/guix.scm
;;;   newer than compiled 
/gnu/store/j447qlziqmkmlq50kxsrcww2nhhkj1vv-guix-module-union/lib/guile/3.0/site-ccache/guix.go
;;; note: source file pomdappi/guix.scm
;;;   newer than compiled 
/home/mathieu/.guix-profile//lib/guile/3.0/site-ccache/guix.go
guix repl: warning: failed to load '(pomdappi access-token)':
In procedure dynamic-link: file: "libpomdappi", message: "file not found"
guix repl: warning: failed to load '(pomdappi authorization)':
no code for module (turtle tordf)
guix repl: warning: failed to load '(pomdappi client)':
no code for module (rdf rdf)
guix repl: warning: failed to load '(tests access-token)': No such file or 
directory
guix repl: warning: failed to load '(tests cache)': No such file or directory
guix repl: warning: failed to load '(tests client-manifest)': No such file or 
directory
guix repl: warning: failed to load '(tests dpop)': No such file or directory
guix repl: warning: failed to load '(tests flow)': No such file or directory
 Starting test JKT
error: make-rsa-public-key: unbound variable
hint: Did you forget a `use-modules' form?

error: make-rsa-public-key: unbound variable
hint: Did you forget a `use-modules' form?

guix repl: warning: failed to load '(tests jws)': No such file or directory
guix repl: warning: failed to load '(tests jwt)': No such file or directory
guix repl: warning: failed to load '(tests refresh)': No such file or directory
guix repl: error: pomdappi: unknown package
--8<---cut here---end--->8---

Cuirass evaluation is probably broken because of those errors.

Mathieu

Re: Configuration for Cuirass

[Mathieu Othacehe]

Hello,

> See https://ci.divoplade.fr/eval/1/log/raw

Sadly the log isn't helpful, could you share your specification?

Thanks,

Mathieu

Re: Configuration for Cuirass

[Mathieu Othacehe]

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 mirror to see if it helps.

Mathieu

Re: Configuration for Cuirass

[Mathieu Othacehe]

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 my-packages
  '((#:name . "my-packages")
(#:load-path-inputs . ("guix"))
(#:package-path-inputs . ())
(#:proc-input . "guix")
(#:proc-file . "build-aux/cuirass/gnu-system.scm")
(#:proc . cuirass-jobs)
(#:proc-args (subset "pomdappi")) ;name of the packages you want to build
(#:inputs . (((#:name . "pomdappi")
  (#:url . "https://framagit.org/divoplade/pomdappi-ci.git;)
  (#:load-path . ".")
  (#:branch . "master")
  (#:no-compile? . #t))
 ((#:name . "guix")
  (#:url . "git://git.savannah.gnu.org/guix.git")
  (#:load-path . ".")
  (#:branch . "master")
  (#:no-compile? . #t
(#:build-outputs . (
(list my-packages)
--8<---cut here---end--->8---

If you want to use a fixed guix input, you can use the #:commit key.

Thanks,

Mathieu

Re: guix system disk-image failure aarch64 -> armhf

[Mathieu Othacehe]

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 variable

Oh not good!

Did you use a specific operating system file? Or the raw bare-bones.tmpl
as hardcoded in the snippet I sent?

Thanks,

Mathieu

Re: guix system disk-image failure aarch64 -> armhf

[Mathieu Othacehe]

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 here---end--->8---

Thanks,

Mathieu

Re: guix system disk-image failure aarch64 -> armhf

[Mathieu Othacehe]

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 anyone know what is happening?

The default Guix System disk image is an x86 compatible disk-image with
an EFI partition so that it can be booted on UEFI compatible
systems. That's why you see occurrences of "grub" and "efi".

That does not really explain the error though, but that's another
issue. The pending patch here[1], will hopefully help users specify
their target image. It means that you should be able to write:

--8<---cut here---start->8---
guix system disk-image -t novena config.scm
--8<---cut here---end--->8---

or,

--8<---cut here---start->8---
guix system disk-image -t raw-image config.scm
--8<---cut here---end--->8---

Until then, running something like:

--8<---cut here---start->8---
(use-modules (gnu)
 (gnu image)
 (gnu system image)
 (guix))

(define my-os
  (primitive-load "/home/mathieu/guix/gnu/system/examples/bare-bones.tmpl"))

(define my-image
  (image
   (format 'disk-image)
   (partitions (list root-partition))
   (operating-system my-os)))

(run-with-store (open-connection)
  (mlet* %store-monad
  ((drv (lower-object (system-image my-image "armhf-linux")))
   (build   (built-derivations (list drv
(return #t)))
--8<---cut here---end--->8---

should get you closer.

Thanks,

Mathieu

[1]: https://issues.guix.gnu.org/42634

Re: Git clients struggle with Guix

[Mathieu Othacehe]

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 this issue?

Thanks,

Mathieu

Re: BPF in linux-libre

[Mathieu Othacehe]

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"
> + #:configuration-file kernel-config
> + #:extra-options
> + (append %bpf-extra-linux-options
> + %default-extra-linux-options)))
> +

What would be the drawbacks of enabling BPF in the default linux-libre
kernel?

Thanks,

Mathieu

Re: BPF in linux-libre

[Mathieu Othacehe]

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
> +   (origin
> + (method git-fetch)
> + (uri (git-reference
> +   (url "https://github.com/libbpf/libbpf;)
> +   (commit commit)))

(commit (string-append "v" version)) should work fine.

> + ("pkg-config" ,pkg-config)

This should be a native-input, don't forget to run the linter :)

> +  (string-append "PREFIX=''")
> +  (string-append "DESTDIR=" (assoc-ref %outputs "out"))
> +  (string-append
> +   "CC=" (assoc-ref %build-inputs "gcc") "/bin/gcc"))

This will put libraries in "lib64" directory which is not desired. You
can set LIBDIR to "/lib" to avoid that.

> +   (chdir "src")

I'm not sure this is needed.

> +   #t)
> +  (home-page "https://github.com/libbpf/libbpf;)
> +  (synopsis "BPF CO-RE (Compile Once – Run Everywhere)")
> +  (description
> +   "Libbpf supports building BPF CO-RE-enabled applications, which, in
> +contrast to BCC, do not require Clang/LLVM runtime being deployed to target
> +servers and does not rely on kernel-devel headers being available.")

"kernel-devel" is more Debian specific I think. I'm also not sure that
the "Clang deploying" things applied well to Guix.

Thanks,

Mathieu

Re: BPF in linux-libre

[Mathieu Othacehe]

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 command line
>
> I added zlib to the inputs of bpftrace but still the same error.  Are
> there any CMake experts out there that can tell if there is a flag or
> option to use here? Is this an upstream issue?

By default, a dynamic version of bpftrace is built. However, as we do
not provide a libbpf.so, it falls back on libbpf.a.

There's a comment in FindLibBfd.cmake which says:

--8<---cut here---start->8---
# libbfd.a is not statically linked with libiberty.a or libz.a so we must 
manually
# do it. Furthermore, libbfd uses some libc symbols that we must manually
# link against if we're not using static libc (which includes such symbols).
--8<---cut here---end--->8---

So when STATIC_LINKING is ON, they add "libz" to the required
libraries. It would be preferable to avoid building a static bpftrace,
so I tried to provide a dynamic version of libbpf.

There's still a failure at validate-runpath phase that need to be
fixed, not sure why.

Thanks,

Mathieu


diff
Description: Binary data

Re: BPF in linux-libre

[Mathieu Othacehe]

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)
>   ^
>   BPF_PROG_TYPE_XDP
>
> The bcc github releases seem to indicate that bcc supports kernels up to
> 5.6.

Yes the issue here is that linux-libre-headers is in fact
linux-libre-headers-5.4.20 which is too old.

I tried to add linux-libre-headers-5.7 to the inputs. Even though it
comes first in CPLUS_INCLUDE_PATH, GCC is picking the old headers.

I'll have another look later.

Thanks,

Mathieu

Re: BPF in linux-libre

[Mathieu Othacehe]

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 "bpftrace" I guess.

Thanks,

Mathieu

[1]: https://github.com/iovisor/bcc/blob/master/INSTALL.md

Re: Guix closure size of a system?

[Mathieu Othacehe]

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

Re: Has anyone ever used kmscon successfully

[Mathieu Othacehe]

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 hosted at
https://github.com/Aetf/kmscon, which contains a few fixes and
improvements.

>
> Works like a charm.

Good to know :)

Mathieu

Re: Has anyone ever used kmscon successfully

[Mathieu Othacehe]

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 implies that there's already a kmscon service in
%desktop-services, which is not the case. Plus 'kmscon is not a proper
service type.

You might prefer to write something like (not tested):

--8<---cut here---start->8---
(cons* (service kmscon-service-type
  (kmscon-configuration
(virtual-terminal "tty8")))
%desktop-services)
--8<---cut here---end--->8---

Mathieu

Re: about -lcurses

[Mathieu Othacehe]

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 makefile).

Mathieu

Re: about -lcurses

[Mathieu Othacehe]

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 by -lncurses, this way:

--8<---cut here---start->8---
#:phases
  (modify-phases %standard-phases
(delete 'configure)
(add-before 'build 'curses
   (lambda _
 (substitute* "src/makefile"
   (("lcurses") "lncurses"))
 #t)))
--8<---cut here---end--->8---

You also have a small mistake here

>   #:make-flags (list (string-append "prefix=" (assoc-ref
 ^
prefix should be upper case.

Then, you should be able to build your package ;)

Mathieu

Re: Understanding Cuirass

[Mathieu Othacehe]

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 list often called ARGUMENTS. The association list will
be the concatenation of #:proc-args and another association list
describing the sources that have been checked out by Cuirass, under
the form:

(INPUT-NAME (('file-name . "/gnu/store/path-of-the-checkouted-input")
 ('revision  . "git-sha1-of-the-checkouted-input")
 ('load-path . INPUT-LOAD-PATH)
 ('no-compile? . INPUT-NO-COMPILE?)))

The role of #:proc is to return a list of 'jobs', which are mainly
derivations that have to be build.

They have to be under the following format:

(list (lambda ()
 ((#:job-name . "NAME-OF-THE-JOB")
  (#:derivation . "/gnu/store/derivation-to-build.drv")))
   ...)

> * What is the format of #:proc-args? Must this be an assoc-list or can
> it be just anything?

No I think it has to be an assoc-list otherwise, the procedure
FORMAT-CHECKOUTS of cuirass/bin/evaluate.in won't be happy.

Have a look to the HYDRA-JOBS procedure in
guix/build-aux/hydra/gnu-system.scm. It is wrapped by the CUIRASS-JOBS
procedure and passed as #:proc in
guix-maintenance/hydra/modules/sysadmin/services.scm (configuration of
Cuirass for the Berlin server).

HYDRA-JOBS will look for the following keys in ARGUMENTS:
* SUBSET ("core", "hello", (list of packages), (list of manifests)).
* SYSTEM ("x86_64-linux", "i686-linux", ...)

So, if we take the exemple of HYDRA-JOBS called with SUBSET to "hello"
and SYSTEM to "x86_64-linux", its role will be to return a list
containing exactly one job, giving the derivation of the "hello"
package for x86_64-linux, that has to be build.

> * How is that used? Is it always the second parameter to the proc?

See above.

> * And is the first one always a reference to the store?

Yes.

> In earlier examples like [0], the #:proc-file (then called #:file)
> could be a plain file lying around. Now it looks like it must be
> relative to one of its inputs, which is referenced by #:proc-input. Is
> this right? Is the old variant still possible?

Yes it is right. #:proc-file should be the path of the file containing
#:proc in the specified #:proc-input.

No, you cannot use #:file anymore.

>
> What forms can the inputs have? The documentation says it must always
> be git (either git:// or smart HTTPS). In examples/random.scm I saw
> also the form "file://", but when I tried it I got some error message
> (can't remember which one exactly). Is this allowed?

The #:url field of an input will be passed to the
LATEST-REPOSITORY-COMMIT of (guix git), using the CLONE procedure of
Guile-Git and the GIT-CLONE function of libgit2 in-fine.

I'm not sure what are the exact protocols supported by GIT-CLONE, you'll
have to inspect the libgit2 library. Maybe trying something like:

,use (guix git)
,use (guix store)
(latest-repository-commit (open-connection) "file://path-to-git-repo"
#:cache-directory "/tmp")

to see if it works!

Don't hesitate if you have other questions.

Mathieu

Re: python-minimal compilation is breaking

[Mathieu Othacehe]

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 to
core-updates if merged.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33186#26

Thanks,

Mathieu

Le mar. 6 nov. 2018 11:30, Eric Bavier  a
écrit :

> On Thu, 1 Nov 2018 05:18:00 +0100 (CET)
>  wrote:
>
> > Hello, Guix Help!
> > This is not working on Lenovo G50-30 everytime (already 3 times)
> >
> > # guix system reconfigure /etc/config.scm --substitute-urls=
> https://berlin.guixsd.org 
> > building
> /gnu/store/6c4g38n9fhvnlk2vasn34mdd6nvpgx8m-python-minimal-3.6.5.drv...
> > -Killed
> >
> > While it is working:
> >
> > $ free -m
> >   totalusedfree  shared  buff/cache
> available
> > Mem:   1882 777 322  72
> 7821031
> > Swap:  2168 1432024
> >
> >
> > I think it lacks resources: cpu 2.1GHz, RAM 2 Gb. When it crashes PC
> stops on 15-20 seconds, mouse does not move, and then process is killed.
> > What to try?
> >
>
> I submitted this patch that I created while struggling with the same
> package: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33284
>
> Perhaps it might help you too?
>
> `~Eric
>

Re: bug#31159: #31159: Reverse order for old grub.cfg entries

[Mathieu Othacehe]

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 => most recent configuration).

Thanks,

Mathieu

Mark H Weaver writes:

> reopen 31159
> tags 31159 - fixed
> thanks
>
> Hi Clément,
>
> According to our bug tracking system, you added the "fixed" tag to bug
> 31159 and closed it.  I think this must have been a mistake.  Did you
> intend to close a different bug?  This bug has to do with the fact that
> the order of old grub.cfg entries should arguably be reversed.
>
>Mark
>
>
> Vagrant Cascadian  writes:
>
>> On 2018-05-31, GNU bug Tracking System wrote:
>>> This is an automatic notification regarding your bug report
>>> #31159: Reverse order for old grub.cfg entries,
>>> which was filed against the guix package.
>>>
>>> Thank you for your report, which has now been closed.
>>> You can view the full report at
>>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=31159
>>
>> I don't see that the proposed patch was applied to any of the guix
>> branches I'm aware of. Has it been merged and just not yet been pushed?
>> Does it need to go to guix-patches instead of guix-bugs?
>>
>> Thanks!
>>
>> live well,
>>   vagrant

Building guix-modular with cuirass

[Mathieu Othacehe]

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))
 (build (primitive-load (string-append source 
"/build-aux/build-self.scm")))
 (res (lambda ()
`((#:job-name . ,(string-append "guix-" revision "-job"))
  (#:derivation . ,(derivation-file-name
(run-with-store store
  (build source
 #:version revision
 #:guile-version "2.2"
(format (current-error-port) "-> ~a|~a~%" arguments (res))
res))
--8<---cut here---end--->8---

This is directly inspired by what I found in build-aux/ directory. While
everything seems great (thanks Ludo for this new feature :p), my other
machines do not use derivations builded by cuirass when running 'guix
pull'.

However, on the machine running cuirass, I have no build error an when
running 'guix pull', nothing is builded and everything works fine.

Any idea how to debug this issue ?

Thanks,

Mathieu

Re: Graphical installer branch

[Mathieu Othacehe]

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. Can you try to "make
clean" before building the disk-image?

Mathieu

Re: successful installation, but problems updating

[Mathieu Othacehe]

> 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

Re: Unable to get (menu-entries (...)) to work properly

[Mathieu Othacehe]

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 "/dev/sda")
(timeout 1)
(menu-entries
 (list (menu-entry
(label "test")
(initrd "/boot/inittest")
(linux "/boot/vmtest"))
--8<---cut here---end--->8---

Mathieu