bug#63551: (no subject)

[Denis 'GNUtoo' Carikli]

Hi,

Guix now has cpp-mustanche 5.0 so I think we can close that bug.

Denis.


pgpwNDA_3cqCb.pgp
Description: OpenPGP digital signature

bug#66986: ifdtool: Firmwares with missing source code present in source code

[Denis 'GNUtoo' Carikli]

Hi,

I found the following firmwares with missing source code inside ifdtool
source code:
src/vendorcode/amd/agesa/f12/Proc/GNB/Nb/Family/LN/F12NbSmuFirmware.h
src/vendorcode/amd/agesa/f14/Proc/GNB/Nb/Family/0x14/F14NbSmuFirmware.h

If there is a mechanism to produce modified source code releases, the
easiest way to deal with that is just to delete these files as they are
not used by ifdtool.

Denis.


pgpB041ZSbcqW.pgp
Description: OpenPGP digital signature

bug#66866: aarch64 system cross compilation + pinebook pro image broken?

[Denis 'GNUtoo' Carikli]

Hi,

With:
> $ guix describe
> Generation 311nov. 01 2023 00:03:34   (current)
>   guix 938a47c
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 938a47c86d7bea785f33f42834c5c1f3dfa594b0

And the following minimalist system configuration:
> ;;; Copyright © 2023 Denis 'GNUtoo' Carikli. SPDX-License-Identifier:
> GPL-3.0+ (use-modules (gnu bootloader) 
>(gnu bootloader u-boot)
>(gnu system file-systems)
>(gnu packages linux)
>(guix gexp))
> (operating-system
>   (host-name "g")
>   (bootloader (bootloader-configuration
>   (bootloader u-boot-rockpro64-rk3399-bootloader)
>   (targets '("/dev/mmcblk2"
>   (kernel linux-libre-arm64-generic)
>   (file-systems (cons (file-system (mount-point "/")
>(device "/dev/vda1")
>(type "ext4"))
>%base-file-systems)))

that I built with:
> guix system build --target=aarch64-linux-gnu noconfig.scm

I end up with:
> [...]
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... Invalid configuration
> `aarch64-linux-gnu': machine `aarch64' not recognized configure:
> error:
> /gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash
> ./config.sub aarch64-linux-gnu failed error: in phase 'configure':
> uncaught exception: srfi-34 # "/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash"
> arguments: ("./configure" "CC_FOR_BUILD=gcc"
> "CONFIG_SHELL=/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash"
> "SHELL=/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash"
> "--prefix=/gnu/store/mn43k8aldd7h9jcx8q5ryij29kdqriz0-gawk-mesboot-3.1.8"
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu"
> "--host=aarch64-linux-gnu" "ac_cv_func_connect=no") exit-status: 1
> term-signal: #f stop-signal: #f] 1700400> phase `configure' failed
> after 115.3 seconds command
> "/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash"
> "./configure" "CC_FOR_BUILD=gcc"
> "CONFIG_SHELL=/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash"
> "SHELL=/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash"
> "--prefix=/gnu/store/mn43k8aldd7h9jcx8q5ryij29kdqriz0-gawk-mesboot-3.1.8"
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu"
> "--host=aarch64-linux-gnu" "ac_cv_func_connect=no" failed with status
> 1 builder for
> `/gnu/store/9xwp6pi7ssi9jhhj50dd1apryidcz2hk-gawk-mesboot-3.1.8.drv'
> failed with exit code 1 build of
> /gnu/store/9xwp6pi7ssi9jhhj50dd1apryidcz2hk-gawk-mesboot-3.1.8.drv
> failed View build log at
> '/var/log/guix/drvs/9x/wp6pi7ssi9jhhj50dd1apryidcz2hk-gawk-mesboot-3.1.8.drv.gz'.
> cannot build derivation
> `/gnu/store/jgd1kl2zavkxsvxa875r8lpndq292vgb-glibc-2.35.drv': 1
> dependencies couldn't be built guix system: error: build of
> `/gnu/store/jgd1kl2zavkxsvxa875r8lpndq292vgb-glibc-2.35.drv' failed

I've tried to bisect that with:
$ guix time-machine --commit= -- \
  system build--target=aarch64-linux-gnu noconfig.scm 
but strangely I failed to find some working commit, so I end up not
being able to bisect.

As I understand the Pinebook pro image is also cross compiled, so
normally that should fail in the same way. But here something is
really strange as well:
- The CI says everything is ok here:
  https://ci.guix.gnu.org/build/2279759/details
- The download image doesn't exist but return '{"error":"Could not find
  the requested build product."}' instead.

That correspond to the commit e6af40d7b46b5c9e397a38c62c885fb42ccd9d26 .

So if I use:
> ;; Adapted from Guix manual, GFDL 1.3 (+?)
> (use-modules (gnu system images pine64))
> (operating-system (inherit pine64-barebones-os))

with:
$ guix time-machine \
  --commit=e6af40d7b46b5c9e397a38c62c885fb42ccd9d26 \
  -- \
  system build --target=aarch64-linux-gnu pine64.scm 

I still end up with:
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... Invalid configuration
> `aarch64-linux-gnu': machine `aarch64' not recognized configure:
> error:
> /gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash
> ./config.sub aarch64-linux-gnu failed error: in phase 'configure':
> uncaught exception: srfi-34 # "/gnu/store/rb75igdc6daly1mz2ivz7rs8hd85imdz-gash-boot-0.3.0/bin/bash"
> arguments: ("./configure" "CC

bug#60558: (no subject)

[Denis 'GNUtoo' Carikli]

Hi,

When testing again with x86_64 Guix and Parabola it works fine now.

Denis.


pgpnRjdwFIn_d.pgp
Description: OpenPGP digital signature

bug#66140: ghc-memory not maintained anymore

[Denis 'GNUtoo' Carikli]

Hi,

The ghc-memory package uses the https://github.com/vincenthz/hs-memory
git repository.

Days ago[1] that repository was "archived" / made read-only, so is is
not maintained anymore.

The bad news is that ghc-memory package is used directly or indirectly
by about 1400 packages.

It only happened days ago and that other GNU/Linux distributions and
many upstream projects are affected as well but I'm unsure if they know
about this issue yet, so there is still a lot of unknown.

As a side note it might be interesting to try to see if it's easy or not
to detect cases like that with guix lint, as github might have some API
that enable to detect if a project is archived or not. Though I've no
idea how much work or maintenance something like that would require.

If something like that is ever made, it would also probably only
work for packages that don't have bundled dependencies.

References:
---
[1]Probably around the 20th september[2].
[2]https://github.com/vincenthz/hs-memory/pull/98#event-10418690170

Denis.


pgpP40iIy7vt9.pgp
Description: OpenPGP digital signature

bug#64966: Rockpro64 SBC not booting anymore after "gnu: shepherd@0.10: Use guile-fibers 1.3.1."

[Denis 'GNUtoo' Carikli]

Hi again,

For some reasons I didn't receive your last mail.

In the machine definition I have (system "aarch64-linux"). I've now
also added -s aarch64-linux as well just to be safe.

As for the patch, it is now in Guix (4dd33fc628 gnu: shepherd: Switch
back to Fibers 1.1 on Arm machines.), and after bisecting the kernel
issue I had (I sent a bug report for that), I simply modified the system
definition to use linux-libre-lts instead.

I used this guix revision:
> $ guix describe
> Generation 71 Sep 13 2023 16:03:04(current)
>   guix 4f933f9
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 4f933f977dd8aa61ca3e50b194d3b56e298a3e30

And it booted fine. Thanks a lot.

Denis.


pgpDbFmKY_RwC.pgp
Description: OpenPGP digital signature

bug#65917: aarch64 system broken since "gnu: linux-libre: Update to 6.4.8."

[Denis 'GNUtoo' Carikli]

Hi,

When doing a guix-deploy on aarch64 with the following command in a
checked out guix git repository with the following command:
> guix time-machine --commit=$(git rev-parse HEAD) -- deploy -L
> rockpro64/ rockpro64/rockpro64.scm

I've got the following build failure:
>   LD [M]  net/openvswitch/openvswitch.ko
>   LD [M]  net/openvswitch/vport-vxlan.ko
>   LD [M]  net/openvswitch/vport-geneve.ko
>   LD [M]  net/openvswitch/vport-gre.ko
>   LD [M]  net/vmw_vsock/vsock.ko
>   LD [M]  net/vmw_vsock/vsock_diag.ko
>   LD [M]  net/vmw_vsock/vmw_vsock_vmci_transport.ko
>   LD [M]  net/vmw_vsock/vmw_vsock_virtio_transport.ko
>   LD [M]  net/vmw_vsock/vmw_vsock_virtio_transport_common.ko
>   LD [M]  net/vmw_vsock/hv_sock.ko
>   LD [M]  net/vmw_vsock/vsock_loopback.ko
>   LD [M]  net/nsh/nsh.ko
>   LD [M]  net/qrtr/qrtr.ko
>   LD [M]  net/qrtr/qrtr-smd.ko
>   LD [M]  net/qrtr/qrtr-tun.ko
>   LD [M]  net/qrtr/qrtr-mhi.ko
> error: in phase 'build': uncaught exception:
> %exception #< program: "make" arguments: ("-j" "6")
> exit-status: 2 term-signal: #f stop-signal: #f> phase `build' failed
> after 16208.5 seconds command "make" "-j" "6" failed with status 2
> builder for
> `/gnu/store/f678azkxiyxv5vm5yacr7pp6c4rhsnaw-linux-libre-6.4.8.drv'
> failed with exit code 1 cannot build derivation
> `/gnu/store/rqdmzzgcydvy485hp3fib2s6pz6ib5pk-linux-modules.drv': 1
> dependencies couldn't be built cannot build derivation
> `/gnu/store/fznw4yyx5s4wdi950hmdw78lyz0chlgr-parameters.drv': 1
> dependencies couldn't be built cannot build derivation
> `/gnu/store/dw3z33as5s7jhppha2bgi3kiab26pix0-profile.drv': 1
> dependencies couldn't be built cannot build derivation
> `/gnu/store/y385isj6ha1dpzcxnws1vq4b9wf3bpcr-system.drv': 1
> dependencies couldn't be built cannot build derivation
> `/gnu/store/791hw1spny38mlhiknf77ihikk2km9zz-switch-to-system.scm.drv':
> 1 dependencies couldn't be built cannot build derivation
> `/gnu/store/3hvlqvfd9x7mylkrr8wsiw4vwpja60hk-remote-exp.scm.drv': 1
> dependencies couldn't be built guix deploy: error: build of
> `/gnu/store/3hvlqvfd9x7mylkrr8wsiw4vwpja60hk-remote-exp.scm.drv'
> failed

So I've bisected and the bisect found this commit:
> bff1f2d4d07e934ea296f9c724b5337996a27c44 is the first bad commit
> commit bff1f2d4d07e934ea296f9c724b5337996a27c44
> Author: Leo Famulari 
> Date:   Tue Aug 8 10:37:16 2023 -0400
> 
> gnu: linux-libre: Update to 6.4.8.
> 
> * gnu/packages/linux.scm (linux-libre-version,
> linux-libre-gnu-revision, linux-libre-pristine-source,
> linux-libre-source, linux-libre, linux-libre-with-bpf): Update to
> linux-libre 6.4.
> 
>  gnu/packages/linux.scm | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Denis.
;;; Copyright © Guix documentation authors
;;; Copyright © 2022 Denis 'GNUtoo' Carikli 
;;; This file is not part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(use-modules (gnu)
 (gnu machine)
 (gnu machine ssh))
(list (machine
   (operating-system
	(@ (rockpro64-system) rockpro64-operating-system))
   (environment managed-host-environment-type)
   (configuration
	(machine-ssh-configuration
	 (authorize? #t)
	 (build-locally? #f)
	 (host-key
	  (string-append
	   "ssh-ed25519"
	   " "
	   "C3NzaC1lZDI1NTE5IJXJagiYEGOgmij79pO0E5UqjnStKBB8T1H5S/eFYk5S"))
 (host-name "192.168.10.35")
 (identity "./id_ed25519")
	 (port 222)
 (system "aarch64-linux")
 (user "root")
;; Based on gnu/system/examples/beaglebone-black.scm in Guix source code
;;
;; This file is not part of GNU Guix.
;;
;; GNU Guix is free software; you can redistribute it and/or modify it
;; under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 3 of the License, or (at
;; your option) any later version.
;;
;; GNU Guix is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more 

bug#64569: [bug #64569] Document how GNU Boot deblobs coreboot

[Denis 'GNUtoo' Carikli]

Hi,

> It would be good that our documentation explains how GNU Boot deblobs
> coreboot for each board and how users can remove new blobs if they
> found some (it would help people to create patches for us, knowing
> where blobs are identified)
Having blob specific documentation not in the code would probably
increase maintenance cost if we want to keep it in sync with the code.

Another way to do that would be to do like with u-boot-libre which is:
- to document what is being removed directly in the source code 
- to have only one source file that generates various released files
- to make it as easy as possible to reuse the source or various
  released files like the script that does the deblobing, tarballs, etc.
- If time permits to do releases of that in two different ways:
  - One as part of GNU Boot releases: we need to provide the deblobbed
Coreboot source code we use as part of GNU Boot releases.
  - One separate that will look more like linux-libre that will not
patch Coreboot at all, but only deblob it and produce releases
matching Coreboot releases.

As for having multiple outputs:
- I've not looked in details but for instance Guix doesn't seem to
  use linux-libre tarballs and instead it seems to produce its own
  source files by running the deblobing scripts.
- Other distributions use linux-libre tarballs (like Parabola).

So if the goal is to make it easily reusable having multiple outputs
make it way easier.

A way to do it would be to unify the blob list files like that:
$ cat ./resources/coreboot/default/blobs.list \
  ./resources/coreboot/fam15h_rdimm/blobs.list \
  ./resources/coreboot/fam15h_udimm/blobs.list | sort -u

And then at least to add support for comments in this file list, and
find where to put that file (which is not as easy as it seems).

The advantage is that it would then be easy to do and easy to maintain.

As for moving the file, you might need commits like this one which is
in GNUtoo/various-fixes branch:
> d73e45aa build: options: only show executables scripts

I'm not sure if it's sufficient but we can probably hack our way around
somehow by not listing resources/deblob for instance if we move it
there.

Denis.


pgphoEGaKspd0.pgp
Description: OpenPGP digital signature

bug#64966: Rockpro64 SBC not booting anymore after "gnu: shepherd@0.10: Use guile-fibers 1.3.1."

[Denis 'GNUtoo' Carikli]

On Mon, 21 Aug 2023 17:00:26 +0200
Ludovic Courtès  wrote:

> Hi Denis,
Hi,

[...]
> How about this patch:

I've some issue testing the patch. With guix
1c916c167b7eb1f2f8af2cf621aa1512b00b1033 ("gnu: Add thunarx-python.")
I've the following:
>   LD [M]  net/nsh/nsh.ko
>   LD [M]  net/qrtr/qrtr.ko
>   LD [M]  net/qrtr/qrtr-smd.ko
>   LD [M]  net/qrtr/qrtr-tun.ko
>   LD [M]  net/qrtr/qrtr-mhi.ko
> error: in phase 'build': uncaught exception:
> %exception #< program: "make" arguments: ("-j" "6")
> exit-status: 2 term-signal: #f stop-signal: #f> phase `build' failed
> after 15717.1 seconds command "make" "-j" "6" failed with status 2
> builder for
> `/gnu/store/969v8chaxmh1b6abr202y2myl0npb6zh-linux-libre-6.4.11.drv'
> failed with exit code 1 cannot build derivation
> `/gnu/store/lky0cr3p0y9lgzarcnrl2aq4y4389ygq-linux-modules.drv': 1
> dependencies couldn't be built building path(s)
> `/gnu/store/n2jk40lhr395jnpi5nr6dhdc536ngrsd-mcron-job' cannot build
> derivation
> `/gnu/store/6f0x8bkmalkrx3n24f9jfvxpd6cvs7sk-parameters.drv': 1
> dependencies couldn't be built cannot build derivation
> `/gnu/store/m5j1961vjyrk1s48i864lcp0h4a0v2sk-profile.drv': 1
> dependencies couldn't be built building path(s)
> `/gnu/store/bhyhl6gw0gkawykb6k0ziyim0wpfnbk6-module-import-compiled'
> cannot build derivation
> `/gnu/store/m7mw72finn57b0j5f66x4dcwgm22k2xj-system.drv': 1
> dependencies couldn't be built cannot build derivation
> `/gnu/store/gbwsrrvlfw2v3cdgxnmi31bz38x5xhgc-switch-to-system.scm.drv':
> 1 dependencies couldn't be built cannot build derivation
> `/gnu/store/ynn503gdm4r6azqa8wa0sjakshx0pcgz-remote-exp.scm.drv': 1
> dependencies couldn't be built guix deploy: error: build of
> `/gnu/store/ynn503gdm4r6azqa8wa0sjakshx0pcgz-remote-exp.scm.drv'
> failed

And here I tried without the patch, in a guix checkout built with make
and with the following command: './pre-inst-env guix deploy -L
rockpro64/ rockpro64/rockpro64.scm'.

I'm unsure of what is wrong with the kernel build, but since it's not
downloading substitutes for it, the issue is probably more general.

Denis.


pgpnih5XG_rO2.pgp
Description: OpenPGP digital signature

bug#64981: GTK4 applications broken (missing libGLESv2)

[Denis 'GNUtoo' Carikli]

rce/src/dispatch_common.c:722
> #6  epoxy_gles2_dlsym (name=0x745a536b  
> "glGetString")
> at ../source/src/dispatch_common.c:717
> #7  epoxy_get_bootstrap_proc_address (name=0x745a536b 
>  "glGetString")
> at ../source/src/dispatch_common.c:835
> #8  0x74534303 in gl_single_resolver 
> (provider=provider@entry=PROVIDER_always_present, 
> entrypoint_offset=, entrypoint_offset@entry=25867) at 
> src/gl_generated_dispatch.c:75810
> #9  0x7454485f in epoxy_glGetString_resolver () at 
> src/gl_generated_dispatch.c:89821
> #10 epoxy_glGetString_global_rewrite_ptr (name=7938) at 
> src/gl_generated_dispatch.c:50154
> #11 0x74590cd5 in epoxy_internal_gl_version 
> (version_string=version_string@entry=7938, 
> error_version=error_version@entry=0, factor=factor@entry=10) at 
> ../source/src/dispatch_common.c:397
> #12 0x74591091 in epoxy_gl_version () at 
> ../source/src/dispatch_common.c:437
> #13 0x75480bb5 in gdk_gl_context_check_extensions (context=0xd065e0)
> at ../gtk-4.8.1/gdk/gdkglcontext.c:1498
> #14 gdk_gl_context_make_current (context=0xd065e0) at 
> ../gtk-4.8.1/gdk/gdkglcontext.c:1605
> #15 0x754afd18 in gsk_gl_renderer_realize (error=0x7fffa978, 
> surface=, 
> renderer=0xc68200) at ../gtk-4.8.1/gsk/gl/gskglrenderer.c:123
> #16 gsk_gl_renderer_realize (renderer=0xc68200, surface=, 
> error=0x7fffa978)
> at ../gtk-4.8.1/gsk/gl/gskglrenderer.c:86
> #17 0x75498fa7 in gsk_renderer_realize 
> (renderer=renderer@entry=0xc68200, 
> surface=surface@entry=0xb8c0b0, error=error@entry=0x7fffa978) at 
> ../gtk-4.8.1/gsk/gskrenderer.c:309
> #18 0x75499786 in gsk_renderer_new_for_surface 
> (surface=surface@entry=0xb8c0b0)
> at ../gtk-4.8.1/gsk/gskrenderer.c:649
> #19 0x75322ad8 in gtk_window_realize (widget=0x95c2f0) at 
> ../gtk-4.8.1/gtk/gtkwindow.c:4294
> #20 0x74ba64ef in g_closure_invoke ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #21 0x74bb7f6d in ?? ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #22 0x74bbe689 in g_signal_emit_valist ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #23 0x74bbebb2 in g_signal_emit ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #24 0x75315931 in gtk_widget_realize (widget=0x95c2f0) at 
> ../gtk-4.8.1/gtk/gtkwidget.c:3412
> #25 0x75327a72 in gtk_window_show (widget=0x95c2f0) at 
> ../gtk-4.8.1/gtk/gtkwindow.c:3818
> #26 0x74ba6719 in ?? ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #27 0x74bbea16 in g_signal_emit_valist ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #28 0x74bbebb2 in g_signal_emit ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #29 0x7530acf1 in gtk_widget_show (widget=0x95c2f0) at 
> ../gtk-4.8.1/gtk/gtkwidget.c:2692
> #30 0x7532559c in gtk_window_present_with_time (window= out>, timestamp=0)
> at ../gtk-4.8.1/gtk/gtkwindow.c:5237
> #31 0x74ba64ef in g_closure_invoke ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #32 0x74bb8306 in ?? ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #33 0x74bbe689 in g_signal_emit_valist ()
>    from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #34 0x74bbebb2 in g_signal_emit ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgobject-2.0.so.0
> #35 0x74cd6328 in ?? ()
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgio-2.0.so.0
> #36 0x74cd647e in g_application_run ()
> --Type  for more, q to quit, c to continue without paging--
>from 
> /gnu/store/nb40pwd37v6i1g4b1fq4l6q4h9px3asr-glib-2.72.3/lib/libgio-2.0.so.0
> #37 0x0042ef77 in main ()

So for some reasons it fails in libepoxy.

So I tried to reproduce the issue:
> $ cat dlopen-test.c
> /*
>  * Copyright © 2023 Denis 'GNUtoo' Carikli 
>  *
>  * This program is free software: you can redistribute it and/or
> modify
>  * it under the terms of the GNU General Public License as published
> by
>  * the Free Software Foundation, either version 3 of the License, or
>  * (at your option) any later version.
>  *
>  * This program is distributed in the 

bug#64966: Rockpro64 SBC not booting anymore after "gnu: shepherd@0.10: Use guile-fibers 1.3.1."

[Denis 'GNUtoo' Carikli]

Hi,

With the commit right before c219c22cbd[1], my rockpro64 (ARM 64bit
SBC) boots fine and I get a login prompt both on the attached display
and serial port.

With c219c22cbd[1] instead it blocks here (see the attached boot.log
file for the full boot log):
> [   33.762050] avdd: disabling

I've attached the system.scm file I used for the test. It's being
reused by a machine configuration in another file (rockpro64.scm) and
I deploys the configuration with:
> guix time-machine --commit=$(GUIX_COMMIT) -- deploy -L . rockpro64.scm

References:
---
[1] commit c219c22cbdb62ba52b50ec8fb12bebce0b1dd459
gnu: shepherd@0.10: Use guile-fibers 1.3.1.
* gnu/packages/admin.scm (shepherd-0.10)[native-inputs, inputs]:
  Replace GUILE-FIBERS-1.1 with GUILE-FIBERS-1.3.

Denis.
;; Based on gnu/system/examples/beaglebone-black.scm in Guix source code
;;
;; This file is not part of GNU Guix.
;;
;; GNU Guix is free software; you can redistribute it and/or modify it
;; under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 3 of the License, or (at
;; your option) any later version.
;;
;; GNU Guix is distributed in the hope that it will be useful, but
;; WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with GNU Guix.  If not, see .

(define-module (system)
  #:use-module (gnu)
  #:use-module (gnu bootloader u-boot)
  #:use-module (gnu services networking)
  #:use-module (gnu services ssh)
  #:use-module (guix packages)
  #:export (rockpro64-operating-system))

(define-public linux-libre-6.3.5-pristine-source
  (let ((version "6.3.5")
(hash (base32 "0pl2zypsmrnna69850jadccffxwg9xdfkldg0sv8m44b7n64gkgm")))
   ((@@ (gnu packages linux)make-linux-libre-source) version
((@@ (gnu packages linux)%upstream-linux-source) version hash)
(@@ (gnu packages linux)deblob-scripts-6.3

(define-public linux-libre-6.3.5-source
  ((@@ (gnu packages linux)source-with-patches)
   linux-libre-6.3.5-pristine-source
   (list (@@ (gnu packages linux)%boot-logo-patch)
 (@@ (gnu packages linux)%linux-libre-arm-export-__sync_icache_dcache-patch

(define* (rockpro64-kernel-config arch #:key variant)
  (local-file "kernel.config"))

(define-public linux-libre-rockpro64
  ((@@ (gnu packages linux) make-linux-libre*)
  "6.3.5"
  "gnu"
  linux-libre-6.3.5-source
  '("x86_64-linux" "i686-linux" "armhf-linux"
"aarch64-linux" "powerpc64le-linux" "riscv64-linux")
  #:configuration-file rockpro64-kernel-config
  #:extra-version "rockpro64"))

(define rockpro64-operating-system
  (operating-system
   (host-name "rockpro64")
   (timezone "Europe/Paris")
   (bootloader (bootloader-configuration
(bootloader u-boot-rockpro64-rk3399-bootloader)
(targets '("/dev/mmcblk2"

   (kernel linux-libre-rockpro64)
   (initrd-modules
(append
 (list
  "dw_mmc-rockchip";; For uSD boot  ;; CONFIG_MMC_DW_ROCKCHIP
  "dwc3"   ;; For USB boot  ;; CONFIG_USB_DWC3
  "dwc3_of_simple" ;; For USB boot  ;; CONFIG_USB_DWC3_OF_SIMPLE
  "ehci_platform"  ;; For USB boot  ;; CONFIG_USB_EHCI_HCD_PLATFORM
  "fixed"  ;; For USB boot  ;; CONFIG_REGULATOR_FIXED_VOLTAGE
  "i2c_rk3x"   ;; For uSD boot  ;; CONFIG_I2C_RK3X
  "ohci_platform"  ;; For USB boot  ;; CONFIG_USB_OHCI_HCD_PLATFORM
  "phy_rockchip_emmc"  ;; For eMMC boot ;; CONFIG_PHY_ROCKCHIP_EMMC
  "phy_rockchip_inno_usb2" ;; For USB boot  ;; CONFIG_PHY_ROCKCHIP_INNO_USB2
  "phy_rockchip_usb"   ;; For USB boot  ;; CONFIG_PHY_ROCKCHIP_USB
  "pl330"  ;; For uSD boot  ;; CONFIG_USB_SERIAL_PL2303
  "rk808"  ;; For uSD boot  ;; CONFIG_MFD_RK808
  "rk808_regulator";; For uSD boot  ;; CONFIG_REGULATOR_RK808
  "sd_mod" ;; For USB boot  ;; CONFIG_BLK_DEV_SD
  "sdhci_of_arasan";; For eMMC boot ;; CONFIG_MMC_SDHCI_OF_ARASAN
  "uas";; For USB boot  ;; CONFIG_USB_UAS
  "usb_storage";; For USB boot  ;; CONFIG_USB_STORAGE
  "xhci_plat_hcd") ;; For USB boot  ;; CONFIG_USB_XHCI_PLATFORM
  %base-initrd-modules))
   ;; rootdelay=5 is needed for booting USB boot
   (kernel-arguments (append '("loglevel=8" "rootdelay=5")))
   (file-systems (append (list (file-system
(mount-point "/")
(device "/dev/mmcblk2p2")
(type "ext4"))) %base-file-systems))
   (services
(append
 (list
  (service
   agetty-service-type
   (agetty-configuration 

bug#63551: cpp-mustache-4.1 build fails

[Denis 'GNUtoo' Carikli]

On Wed, 17 May 2023 12:44:58 +0200
Giovanni Biscuolo  wrote:
> Since commit 4ed8c0b is setting version to 5.0.0 and that version
> works (does it?), I'd go for an "update to 5.0.0" patch
It at least builds fine.

Thanks a lot for the advises.

Denis.


pgp1KzGnhigyb.pgp
Description: OpenPGP digital signature

bug#62784: drascula, lure, lure-de, lure-es, lure-fr, lure-it, sky: non-commercial license

[Denis 'GNUtoo' Carikli]

Hi,

I also forgot the following games (same license clause):
queen, queen-de, queen-fr, queen-it.

Denis.


pgpmIFPgb3_Hg.pgp
Description: OpenPGP digital signature

bug#62784: drascula, lure, lure-de, lure-es, lure-fr, lure-it, sky: non-commercial license

[Denis 'GNUtoo' Carikli]

Hi,

The license of all these packages have that inside:
> 3) You may not charge a fee for the game itself. This includes
> reselling the game as an individual item.

And the FSDG has that:
> Non-functional Data
> ---
> Data that isn't functional, that doesn't do a practical job, is more
> of an adornment to the system's software than a part of it. Thus, we
> don't insist on the free license criteria for non-functional data. It
> can be included in a free system distribution as long as its license
> gives you permission to copy and redistribute, both for commercial
> and non-commercial purposes. For example, some game engines released
> under the GNU GPL have accompanying game information—a fictional
> world map, game graphics, and so on—released under such a
> verbatim-distribution license. This kind of data can be part of a
> free system distribution, even though its license does not qualify as
> free, because it is non-functional.

So unfortunately here we need to remove these games.

Denis.


pgpJgnL0wTaRG.pgp
Description: OpenPGP digital signature

bug#61628: Graphical installer: network check not working if date is wrong

[Denis 'GNUtoo' Carikli]

Hi,

With an old date, the network isn't detected in the graphical installer.

I'm unsure if it's related to bug 35630[1] or not though.

Running date by hand to set an approximate date and retrying to detect
the network makes it work.

References:
---
[1]https://issues.guix.gnu.org/35630

Denis.


pgpsTIYJucFWX.pgp
Description: OpenPGP digital signature

bug#61455: i686: go-gopkg-in-yaml-v3 build failed.

[Denis 'GNUtoo' Carikli]

Hi,

go-gopkg-in-yaml-v3 is a dependency of docker and it fails to build on
i686. 

Here's my guix revision:
> $ guix describe
> Generation 60 Feb 10 2023 01:09:07(current)
>   guix 07f19ef
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 07f19ef04b5a8f4d7a12a8940333e67db8da81c0

I've also attached the build log.

Denis.


0pancy0jamx6y3nb16pr2lw3qw4s8s-go-gopkg-in-yaml-v3-3.drv.gz
Description: application/gzip


pgpK4TbDKPptB.pgp
Description: OpenPGP digital signature

bug#51505: Request for official docker image on dockerhub

[Denis 'GNUtoo' Carikli]

Hi,

If the idea is to be able to use a Guix docker image, as I understand
dockerhub is not strictly required.

For instance Fedora has its own docker registry[1] that works out of
the box with docker pull. More generally to download an image one can
just run: 'docker pull /'. As I understand that
is usable in Dockerimages in the same way.

If I understood well, your issue is to integrate Guix docker images in
test environments that require you to use only a Dockerfile.

For publishing Guix docker images, Guix has several options that are not
mutually exclusive:
- It could use dockerhub. Note that the dockerhub registry/repository
  itself is not FSDG compliant as it contains nonfree software like
  Windows images.
- Guix could setup its own docker registry. There is a work in progress
  patch for the docker registry (bug #60770) that works but it still
  needs to un-vendor the dependencies. We also need to look how to use
  it to deploy public registries (I've only tested it on localhost so
  far, so without certificates and authentication). Also nobody
  reviewed that patch yet and there seems to be a huge backlog with
  patches review.
- Someone could setup a general FSDG compliant registry for various
  docker images, and Guix could add official images there.
- Someone could also do some research to see if it's possible to
  host images on a simple web server and make docker think it's a
  registry. If that works, it could integrate well with
  guix.gnu.org/en/download and guix.gnu.org/en/download/latest and the
  Guix release infrastructure. Though one issue here is that docker
  somehow expects yaml files on directory paths.

If Guix uses a third party registry, the third party will not have the
same policies and priorities than Guix. And in practice the third party
will be able to modify the images, as it hosts images that lack
signatures, and as far as I know there is also no way to automatically
verify some signatures before running the images.

PureOS also uses dockerhub, and as far as I know their docker images
are FSDG compliant. So if you need FSDG compliant images you could use
that and download and run Guix there.

Parabola and Trisquel also have what is needed to make docker images
but the images are not published anywhere as far as I know, so other
FSDG compliant distributions didn't really solve the issue either.

Alternatively Guix could just publish additional docker images in
guix.gnu.org/en/download and guix.gnu.org/en/download/latest but here I
guess that this doesn't work for your test environment.

As for the Debian images you mentioned they are somehow semi-official
according to Debian. Maybe it's because they are made by some Debian
maintainers and are not part of the regular Debian release process.

Personally I'd like to be able to use docker and more specifically
Dockerfiles in an FSDG compliant and trustworthy way, so I've started
looking a bit into it, for all FSDG compliant distributions in
general[2], but we have no drop-in solution that integrate well with
distributions release processes yet.

Also note that I'm new to docker so I might have missed some stuff, and
I'm also not a Guix maintainer so I can't take decisions for the Guix
project.

References:
---
[1]https://registry.fedoraproject.org It is probably not FSDG compliant.
[2]https://libreplanet.org/wiki/Group:Software/research/ExternalRepositories/DockerRegistries

Denis.


pgpRURJvqemS_.pgp
Description: OpenPGP digital signature

bug#61206: fakeroot 1.30.1 doesn't build from x86_64 doing qemu-binfmt for armhf-linux breaking build of arm-related images

[Denis 'GNUtoo' Carikli]

Hi,

I've the same issue when building for i686 from an x86_64 computer with
the following commands:
> guix build -s i686-linux fakeroot

The log is in zdjf6dkagsmlrrimm6nsz8p3xkxpx3-fakeroot-1.30.1.drv.gz
(attached).

And:
> guix build --target=i686-linux-gnu fakeroot
The log is in yscc2h0g7n3jbjz163g2p2layhm5wm-fakeroot-1.30.1.drv.gz
(attached).

For some reasons fakeroot is also pulled with:
> guix system image \
> <-s i686-linux|--target=i686-linux-gnu> \
> -t raw-with-offset system.scm

On x86 raw-with-offset is used for computers with BIOS interfaces.

Denis.


zdjf6dkagsmlrrimm6nsz8p3xkxpx3-fakeroot-1.30.1.drv.gz
Description: application/gzip


yscc2h0g7n3jbjz163g2p2layhm5wm-fakeroot-1.30.1.drv.gz
Description: application/gzip


pgpnu3woz50iP.pgp
Description: OpenPGP digital signature

bug#60558: Libvirt LXC not working?

[Denis 'GNUtoo' Carikli]

Hi,

I've tried to run a Parabola installation inside libvirt LXC (inside a
guix system intallation) and it gives me the following error:
> Unable to complete install: 'internal error: guest failed to start: Failure 
> in libvirt_lxc startup: Unable to create directory /sys/fs/cgroup/unified: No 
> such file or directory
> '
> 
> Traceback (most recent call last):
>   File 
> "/gnu/store/mazwqywghxp2gib7bia3n482sky9q14w-virt-manager-4.1.0/share/virt-manager/virtManager/asyncjob.py",
>  line 72, in cb_wrapper
> callback(asyncjob, *args, **kwargs)
>   File 
> "/gnu/store/mazwqywghxp2gib7bia3n482sky9q14w-virt-manager-4.1.0/share/virt-manager/virtManager/createvm.py",
>  line 2008, in _do_async_install
> installer.start_install(guest, meter=meter)
>   File 
> "/gnu/store/mazwqywghxp2gib7bia3n482sky9q14w-virt-manager-4.1.0/share/virt-manager/virtinst/install/installer.py",
>  line 695, in start_install
> domain = self._create_guest(
>   File 
> "/gnu/store/mazwqywghxp2gib7bia3n482sky9q14w-virt-manager-4.1.0/share/virt-manager/virtinst/install/installer.py",
>  line 637, in _create_guest
> domain = self.conn.createXML(initial_xml or final_xml, 0)
>   File 
> "/gnu/store/sv6lwcmy8529zvdafag0xyv4svw5mz5y-python-libvirt-8.6.0/lib/python3.9/site-packages/libvirt.py",
>  line 4442, in createXML
> raise libvirtError('virDomainCreateXML() failed')
> libvirt.libvirtError: internal error: guest failed to start: Failure in 
> libvirt_lxc startup: Unable to create directory /sys/fs/cgroup/unified: No 
> such file or directory

Is it already fixed in libvirt master branch? Or is it a new bug?

Also is there any existing workarounds?

Denis.


pgpAyDSq14Lbw.pgp
Description: OpenPGP digital signature

bug#60109: gnome-boxes and distributions

[Denis 'GNUtoo' Carikli]

On Fri, 16 Dec 2022 15:39:58 +0100
Denis 'GNUtoo' Carikli  wrote:

> Hi,
> 
> Here are some more information:
> 
> The Parabola's patch fox fixing that is probably this one:
> https://git.parabola.nu/abslibre.git/tree/libre/libosinfo/libre.patch
> This is because libosinfo is in the dependencies of gnome-boxes. I
> didn't check beyound that.
I've looked in more details and it seems that the information is not in
libosinfo but in osinfo-db.

Apparently Parabola also patches virt-manager[1] probably to remove the
mention of non-FSDG distributions, so I'm not sure why Parabola didn't
patch osinfo-db directly instead.

Maybe it's to minimize the amount of rebuilds or something like that
(Parabola reuses packages from Arch Linux and removes/replace the ones
that are not FSDG compliant).

References:
---
[1]https://git.parabola.nu/abslibre.git/tree/libre/virt-manager/libre.patch

Denis.


pgpXpDWLdv42N.pgp
Description: OpenPGP digital signature

bug#60290: Manual: Is guix-patc...@debbugs.gnu.org valid?

[Denis 'GNUtoo' Carikli]

Hi,

If I send patches to guix-patc...@gnu.org, everything works as
intended. However if I send them to guix-patc...@debbugs.gnu.org, I can
wait days and I get no confirmation at all.

This second address was found in the following command inside the Guix
devel manual:
> $ git send-email outgoing/-cover-letter.patch -a \
> --to=guix-patc...@debbugs.gnu.org \
> [...]

It's in the "Multiple Patches" subsection of the "Sending a patch
Serie" section of "Submitting Patches".

Denis.


pgpSyqLmI0ya0.pgp
Description: OpenPGP digital signature

bug#60287: arm-linux-gnueabihf: system image: kernel module not found "ahci"

[Denis 'GNUtoo' Carikli]

Hi,

I've been trying to build a system image with the following command:
> $ guix system image --target=arm-linux-gnueabihf -t raw-with-offset \
> minimal.scm

And the following minimal.scm:
> (use-modules (gnu)
>  (gnu bootloader u-boot))
> (use-service-modules networking ssh)
> (use-package-modules bootloaders screen ssh)
> 
> (operating-system
>   (host-name "qemu-arm")
>   (timezone "Europe/Paris")
>   (locale "en_US.utf8")
>   (bootloader (bootloader-configuration
> (bootloader (bootloader (inherit u-boot-bootloader)
> (installer #~(const #t))
>   (kernel-arguments '("console=ttyS0,115200"))
>   (file-systems (cons (file-system
> (device (file-system-label "my-root"))
> (mount-point "/")
> (needed-for-boot? #t)
> (type "ext4")) %base-file-systems))
>   (users (cons (user-account
>  (name "gnutoo")
>  (group "users")
>  (supplementary-groups '("wheel" "audio" "video")))
>%base-user-accounts))
>   (packages (append (list screen) %base-packages))
>   (services
>(append (list (agetty-service (agetty-configuration (extra-options '("-L"))
>(baud-rate "115200")
>(term "xterm-256color")
>(tty "ttyS0"
>%base-services)))

And it gives me that error:
$ zcat qsh8mas9r3fsmd7q1rn8idaj8ja57n-linux-modules.drv.gz | sed 's#^#> #'
> Backtrace:
>5 (primitive-load "/gnu/store/p3anj14w2svvcrchshnfkxap6j3?")
> In ice-9/eval.scm:
> 619:8  4 (_ #f)
>626:19  3 (_ #)
>293:34  2 (_ #(# #))
> In srfi/srfi-1.scm:
>586:17  1 (map1 ("ahci" "usb-storage" "uas" "usbhid" "hid-gene?" ?))
> In gnu/build/linux-modules.scm:
> 269:5  0 (_)
> 
> gnu/build/linux-modules.scm:269:5: kernel module not found "ahci" 
> "/gnu/store/0v0b3vb7wgavq9s4yck6hpqjm981ixg3-linux-libre-6.0.15/lib/modules"

It worked long time ago (probably around the time where Guix 1.3 was
released), 
so some regression probably happened somewhere.

Denis.


pgpjwHqTR39Xa.pgp
Description: OpenPGP digital signature

bug#43685: xonotic player ID and starts reporting are broken

[Denis 'GNUtoo' Carikli]

Hi,

As I understand the statistics should also be opt-in to be compliant
with the FSDG and GDPR, and currently they will be opt-out when they
start working.

If you run Xonotic for the first time, after agreeing to the services
TOS, that basically tell you that TOS apply to stats.xonotic.org and to
the xonotic-forum, you are asked if you want to "Allow player
statistics to use your nickname at stats.xonotic.org?".

It also tells you that "Player statistics are enabled by default, you
can change this in the Profile menu". And so even if you select "no" or
"undecided", you are tracked.

Parabola also has a similar issue: https://labs.parabola.nu/issues/3402
though I've not checked if statistics collection work there.

So maybe we could:
(1) Somehow find a way to make statistics work again
(2) Disable statistics by default
(3) Change the text telling users that statistics can be enabled in the
profile menu.

This looks relatively easy to do but it might not work for
translations. So maybe we could do that and try to upstream a patch for
it? Or do people have another idea.

Also should I open a separate bug for that issue because while it
touches the exact same functionality and that both probably need to be
tackled together technically speaking it's a separate issue?

Denis.


pgpdIVK6D4MER.pgp
Description: OpenPGP digital signature

bug#60109: gnome-boxes and distributions

[Denis 'GNUtoo' Carikli]

Hi,

Here are some more information:

The Parabola's patch fox fixing that is probably this one:
https://git.parabola.nu/abslibre.git/tree/libre/libosinfo/libre.patch
This is because libosinfo is in the dependencies of gnome-boxes. I
didn't check beyound that.

To reproduce the bug one need to lauch gnome-box (probably with
virtualization services enabled).

Once installed and launched (and the first information wizard skipped)
we can click on the top-left "+" button.

We then have the choice between "Create virtual machine from file" and
"Download an operating system". 

It also shows "Featured Downloads" with distributions under it like Red
Hat entreprise Linux 9 Unknown x86_64, Fedora Workstation 36 x86_64
(live), etc and all these are known to contain nonfree firmwares. I'm
not sure if it shows this "Featured Downloads" all the time though.

If we click on Download an operating system, then we have a list of
distributions like Ubuntu, openSUSE etc which again are known to
include nonfree firmwares in their installers.

If we go down and click on the 3 vertical dot buttons, we then have a
more complete list which also includes FSDG compliant distributions
such as (complete list):
- PureOS x86_64 (Live) from Purism, SPC
- Guix latest x86_64 from Guix contributors
- PureOS 10 KDE x86_64 (Live) from Purism, SPC
- PureOS 10 GNOME x86_64 (Live) from Purism, SPC
- Trisquel 9 Sugar Toast x86_64 (live) from The Trisquel project
- Trisquel 9 x86_64 (live) from The Trisquel project
- Triskel 9 x86_64 (live) from The Trisquel project
- Trisquel 9 Mini x86_64 (live) from The Trisquel project
- Guix 1.3 x86_64 from Guix contributors
- Guix 1.3 i686 from Guix contributors
- Hypertalking 03 x86_64 (Live) from the Hyperbola project
- Hyperbola 03 x86_64 (Live) from the Hyperbola project

Then there are some distributions where I'm not completely sure of the
status:
- freenix x86_64 (DVD)(Live) from the Freenix project
  Here this is a distribution that applied for FSDG compliance but it
  was stuck in review for some reasons (probably either people waiting
  on each other, or the lack of time to review it properly from at
  least one of the sides)
- Debian: As far as I understand they include the nonfree firmwares by
  default nowadays in some situations, so it's probably easier to filter
  them out than check each installer / image for nonfree firmwares.
- Freedos: if I recall well that came with nonfree software but there
  is an ongoing effort to remove it, I just don't know the status. It
  probably still depend on nonfree compilers (under the openwatcom
  license) though so it probably has nonfree dependencies.

And as far as I know all the other either have at least nonfree
firmwares inside.

Denis.


pgpU9jKBP6REu.pgp
Description: OpenPGP digital signature

bug#60109: gnome-boxes and distributions

[Denis 'GNUtoo' Carikli]

Hi,

I've installed gnome-boxes and I found out that it proposes to download
and run many distribution installers.

As it contains many non-FSDG compliant distributions, many of these
distributions probably contain nonfree firmwares at least.

Not all distributions are problematic though, as it contain some FSDG
compliant distributions.

Denis.


pgpPPabvl5yni.pgp
Description: OpenPGP digital signature

bug#17152: GNU Guix backend for PackageKit / Gnome-Software

[Denis 'GNUtoo' Carikli]

Hi,

How does it work when Nix is installed on top of another distribution?
Is there something to handle that in packagekit? 

Or with distributions like Ubuntu that also use snap, it is is handled
transparently somehow? Or do users have to choose which package manager
to use?

I wonder that because I'd be interested in somehow supporting the
package manager of a foreign distribution (Parabola) to have an unified
configuration that can work also when guix / guix home is used on top
of another distribution[1].

[1] There are various advantages of using the distribution package
manager instead of guix home in that case, like having the packages
installed system wide for instance, or having the packages take
less space.

Denis.

bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC

[Denis 'GNUtoo' Carikli]

Hi,

I've found an idea: guix pull can pull to a precise commit:
>   --commit=COMMITdownload the specified "guix" channel COMMIT

So maybe it works with a commit close to Guix 1.3. If that's the case
we can probably bisect it to the commit that broke your guix pull.

Denis.


pgp57F6DHZXlH.pgp
Description: OpenPGP digital signature

bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC

[Denis 'GNUtoo' Carikli]

I've tried to cross compile an image but I end up with this build
failure:
> $ zcat
> /var/log/guix/drvs/fl/nrxka21fgd5hpbchzp3fyv01xyrs2v-linux-modules.drv.gz
> Backtrace: 5 (primitive-load
> "/gnu/store/lm7mjsdx6p16pbavv80hpf561df?") In ice-9/eval.scm:
> 619:8  4 (_ #f)
>626:19  3 (_ #)
>293:34  2 (_ #(# #))
> In srfi/srfi-1.scm:
>586:17  1 (map1 ("ahci" "usb-storage" "uas" "usbhid" "hid-gene?"
> ?)) In gnu/build/linux-modules.scm:
> 257:5  0 (_)
> 
> gnu/build/linux-modules.scm:257:5: kernel module not found "ahci"
> "/gnu/store/is9dg680cwlzhj6k6j0vxz86zwkqvx5m-linux-libre-6.0.8/lib/modules"

Though I don't know if it is related or not to your issue.

Denis.


pgp79tcJHK07q.pgp
Description: OpenPGP digital signature

bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC

[Denis 'GNUtoo' Carikli]

On Sun, 13 Nov 2022 11:48:18 +0100
Tanguy LE CARROUR  wrote:

> Hi Denis,
> 
> Thanks for your answer.
> 
> Strange thing, though… I didn't received your answer!?
> I came across it by chance while checking
> [bug-guix](https://lists.gnu.org/archive/html/bug-guix).
> 
> > Sat, 12 Nov 2022 16:40:20 +0100
> > Does it also fails with 'guix pull -M 1 -c 1' ?
[...]
> I'll try on a brand new SD card, because the one I used is a bit old.
> 
> Any other ideas about what might have gone wrong?
The command I gave sometimes works on 32bit machines with a low
amount of RAM, so it was worth trying.

Unfortunately here I'm out of ideas, other people with more experience
in Guix might know better.

Also note that I also do have an A20-OlinuXino-LIME2-eMMC, so I might
be able to run tests too if they are fast to do. Maybe I should try to
cross compile a rootfs and see if it boots.

Long time ago it booted if I recall well, and then it stopped working
but I didn't take the time to track the regression down or to try again.

Denis.


pgpLCzVzyqHrs.pgp
Description: OpenPGP digital signature

bug#59196: guix pull fails on A20-OlinuXino-LIME2-eMMC

[Denis 'GNUtoo' Carikli]

Hi,

Does it also fails with 'guix pull -M 1 -c 1' ?

Denis.


pgpuM7NXz38z1.pgp
Description: OpenPGP digital signature

bug#58783: Strange booting/reproducibility issue

[Denis 'GNUtoo' Carikli]

Hi,

On an i686 computer[1], I've a Guix installation on an HDD, and if I do
> guix pull -M 1 -c 1
and that I then do
> sudo -E guix system reconfigure -M 1 -c 1 system.scm

I get the following boot failure[2]:
> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for
> main thread GC Warning: Couldn't read /proc/stat
> Welcome, this is GNU's early boot Guile.
> Use 'gnu.repl' for an initrd REPL.
> 
> loading kernel modules...
> Enter passphrase for /dev/sda2: 
> /dev/mapper/cryptroot: recovering journal
> /dev/mapper/cryptroot: clean, 702176/9773056 files, 8418369/39071232
> blocks ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure mkdir: File exists
> 
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to
> continue. GNU Guile 3.0.7
> Copyright (C) 1995-2021 Free Software Foundation, Inc.
> 
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
> 
> Enter `,help' for help.
> scheme@(guile-user)> 

If I use the same system.scm (attached) and that I produce an image
with the build_init.sh script (attached) which setups an encrypted
partition and uses guix system init, and that I then copy the resulting
image to an USB drive with ddrescue, It then boots fine.

Since the system ends up not booting anymore when I try to guix pull
and guix system reconfigure the system on the HDD, to boot I simply
select a known booting old revision in the grub menu, so I can easily
test things.

Though I'm not sure where to look. Is there anything I can do to get
more contexts or logs? Should I try loglevel=8 ?

References:
---
[1] The computer is a Thinkpad X60 with only an external display running
Coreboot with SeaBIOS.
[2] The boot log was captured by adding console=ttyS0,115200 to the
command line arguments in grub and by capturing the messages
through a serial port.

Denis.


build_init.sh
Description: application/shellscript
;; Copyright (C) 2022 Denis 'GNUtoo' Carikli 
;;
;; This program is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

(use-modules
  (gnu)
  (gnu packages admin)
  (gnu packages emacs)
  (gnu packages gnome)
  (gnu packages ntp)
  (gnu packages screen)
  (gnu packages vim))
(use-package-modules version-control xdisorg)
(use-service-modules desktop networking sddm ssh xorg)

(operating-system
  (locale "en_US.utf8")
  (timezone "Europe/Paris")
  (keyboard-layout
(keyboard-layout "us" "altgr-intl"))
  (host-name "x60-base")
  (users (cons* (user-account
  (name "gnutoo")
  (comment "GNUtoo")
  (group "users")
  (home-directory "/home/gnutoo")
  (supplementary-groups
'("wheel" "netdev" "audio" "video")))
%base-user-accounts))
  (packages
(append
  (list (specification->package "nss-certs")
emacs
git
gvfs
htop
ntp
redshift-wayland
screen
vim)
  %base-packages))
  (services
(append
 (list
  (elogind-service)
  (service openssh-service-type
	   (openssh-configuration
		(permit-root-login #t)
		(password-authentication? #f)
		(challenge-response-authentication? #f)
(use-pam? #f)
		;; (authorized-keys
		;; `(("root", (local-file "gnutoo.pub"))
))
(service tor-service-type)
;; (service dhcp-client-service-type)
(service xfce-desktop-service-type)
(set-xorg-configuration
 (xorg-configuration
  (keyboard-layout keyboard-layout))
 sddm-service-type))
  %base-services))
  (bootloader
(bootloader-configuration
  (bootloader grub-bootloader)
  (targets '("/dev/sda"))
  (terminal-outputs '(console))
  (keyboard-layout keyboard-layout)))
  (mapped-devices
(list (mapped-device
(source
  (uuid "12345678-abcd-1234-1234-1234567899ab"))
(target "cryptroot")
(type luks-device

bug#58366: Guix build fails on i686

[Denis 'GNUtoo' Carikli]

Hi,

After a guix pull it now builds fine again. I've tested it with guix
build -s i686-linux on x86_64 and guix build guix on i686.

So the bug can now be closed.

Denis.


pgp68OhkUF2Pp.pgp
Description: OpenPGP digital signature

bug#58147: FAAC considered nonfree by Debian and Parabola

[Denis 'GNUtoo' Carikli]

Hi,

The faac package is considered nonfree in Debian[1] and also in
Parabola because according to the Parabola blacklist faac "is a GPL'ed
package, but has non free code that can't be distributed under the
GPL"[2].

The path chosen by Parabola (and probably most other FSDG compliant or
100% free distributions) was to make the packages not depend on
faac. 

A quick search in the Parabola packages list[3] can show some of the
packages having been (re)built without faac support[4].

Reference:
--
[1]https://packages.debian.org/bullseye/faac
[2]https://git.parabola.nu/blacklist.git/tree/blacklist.txt#n104
[3]https://www.parabola.nu/packages/?sort==x86_64=Libre=faac==
[4]Parabola uses most Arch Linux packages as-is, and it excludes
   problematic packages and/or replaces problematic packages. This is
   why some of the replacement packages mention "without nonfree faac".

Denis.


pgpi1hojgpgd6.pgp
Description: OpenPGP digital signature

bug#56900: phoronix-test-suite downloads nonfree software (+ question on collaboration with Parabola on this package)

[Denis 'GNUtoo' Carikli]

On Tue, 02 Aug 2022 22:28:56 -0400
Maxim Cournoyer  wrote:

> Hi Denis,
Hi,

> Would you like to try preparing a snippet patch turning the above
> 'Free' into 'Proprietary' or the likes so that the Python script can
> remove them?  Otherwise I can look into it.
Since you wrote the python script you might be way faster if you do it.

By the way I've found new issues: 
- phoronix-test-suite test system/gnupg => This downloads
  linux-4.3.tar.gz, so it has the same issue.
- phoronix-test-suite test pts/gnupg => This downloads
  ubuntu-20.04-desktop-amd64.iso so it has the same issue because
  ubuntu-20.04-desktop-amd64.iso probably contains nonfree firmwares.

Denis.


pgpDMkZLVUMRN.pgp
Description: OpenPGP digital signature

bug#56900: phoronix-test-suite downloads nonfree software (+ question on collaboration with Parabola on this package)

[Denis 'GNUtoo' Carikli]

Hi,

Thanks a lot for working on having a recent FSDG compliant versions of
phoronix-test-suite.

I've found a minor issue with phoronix-test-suite and I've a couple of
questions to help synchronize between Parabola and Guix to prevent
accidental installation of nonfree software.

Nonfree software downloaded by phoronix-test-suite:
---
According to Debian, Linux has the following nonfree files:
> Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt
> arch/powerpc/platforms/8xx/micropatch.c
> drivers/media/usb/dvb-usb/af9005-script.h drivers/media/i2c/vs6624.c
> drivers/net/appletalk/cops*
> drivers/video/fbdev/nvidia
> drivers/video/fbdev/riva

The GNU project also mention that ("nonfree blobs are shipped with
Linux, the kernel") in the list of distros that are not FSDG
compliant[1].

When running 'phoronix-test-suite test build-linux-kernel' (and
selecting Yes(Y) to install the test), phoronix-test-suite downloads
a tarball of Linux.

So I assume that the tarball downloaded also have nonfree software like
arch/powerpc/platforms/8xx/micropatch.c. So we also need to filter-out
two tests (to keep being FSDG compliant):
> pts/build-linux-kernel
> pts/unpack-linux

As I understand, the other build should be fine.

Question on the package description and collaborating with Parabola:

If I run 'phoronix-test-suite list' on a fresh Guix installation, it
lists nonfree software like BioShock Infinite, Hitman, which are games
that have not been released under free licenses (according to
Wikipedia).

I've installed Guix on a separate computer just for that (as it would
be negligence from my part to risk running nonfree software like that on
computers that are either hold keys to sign releases or build releases).

And there it seems that it runs hoses tests (I need to do that in a
terminal in a graphical interface like sway for instance) but I'm unsure
if it actually downloaded nonfree software or not as the tests seem to
fail and I didn't find the games being downloaded (but I only looked
rapidly).

If it didn't download any nonfree games, we could update the package
description to explain how this FSDG compliance is done to not make
users afraid and prevent invalid bug reports.

I also saw there is a python script[2] that somehow is supposed to take
care of FSDG compliance. How does it work in practice?

I'm also asking because I've also added phoronix-test-suite to Parabola
long time ago with a very different patch, and if for some reasons both
patches are incompatible, I don't want to end up in a situation where
users running Guix on top of Parabola would end up accidentally
installing nonfree software.

If that's the case it would be easier to fix the issue in Parabola
(just by updating phoronix-test-suite and taking care of informing the
users to delete their old ~/.phoronix-test-suite/) but I also need to
understand how the python script works first.

Once these questions are sorted out I'll try to install Parabola
instead of Guix on that test laptop, import my existing
~/.phoronix-test-suite/, install Guix on top, and install
phoronix-test-suite through Guix to see if the nonfree tests somehow
run something.

And I'll then report the result of test here and I'll then probably end
up updating in Parabola (and reusing your patch).

References:
---
[1]https://www.gnu.org/distros/common-distros.html
[2]gnu/packages/patches/phoronix-test-suite-fsdg.patch

Denis.


pgpODVyIlZJH1.pgp
Description: OpenPGP digital signature

bug#56223: h-client not running with a host distribution

[Denis 'GNUtoo' Carikli]

Hi,

After having done a 'guix pull', I added h-client to a system image made
with guix system image, and when running that image I could launch
h-client with any of the following command lines:
$ h-client
$ sudo -E h-client

However with Parabola i686 (also after having done a 'guix pull',
h-client doesn't work anymore, and it gives the following error:
> Traceback (most recent call last):
>   File 
> "/gnu/store/vbw6w6527y2xmxnyb4v4s9hp5ydk7i1d-h-client-0.0a0-1.e6c78b1/bin/.h-client-real",
>  line 33, in 
> sys.exit(load_entry_point('hclient==0.0a0.dev0', 'console_scripts', 
> 'h-client')())
>   File 
> "/gnu/store/vbw6w6527y2xmxnyb4v4s9hp5ydk7i1d-h-client-0.0a0-1.e6c78b1/bin/.h-client-real",
>  line 25, in importlib_load_entry_point
> return next(matches).load()
>   File 
> "/gnu/store/x5qnvlqgcb73nksrzavpq8pg9xgrfwqv-python-3.9.9/lib/python3.9/importlib/metadata.py",
>  line 77, in load
> module = import_module(match.group('module'))
>   File 
> "/gnu/store/x5qnvlqgcb73nksrzavpq8pg9xgrfwqv-python-3.9.9/lib/python3.9/importlib/__init__.py",
>  line 127, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1030, in _gcd_import
>   File "", line 1007, in _find_and_load
>   File "", line 986, in _find_and_load_unlocked
>   File "", line 680, in _load_unlocked
>   File "", line 850, in exec_module
>   File "", line 228, in _call_with_frames_removed
>   File 
> "/gnu/store/vbw6w6527y2xmxnyb4v4s9hp5ydk7i1d-h-client-0.0a0-1.e6c78b1/lib/python3.9/site-packages/hclient/gtkclient.py",
>  line 20, in 
> gi.require_version('GdkPixbuf', '2.0')
>   File 
> "/gnu/store/8yca9x2l0k0m5726m2hs2mpdma14h5yr-python-pygobject-3.40.1/lib/python3.9/site-packages/gi/__init__.py",
>  line 126, in require_version
> raise ValueError('Namespace %s not available' % namespace)
> ValueError: Namespace GdkPixbuf not available

I vaguely remember that I could launch it on top of Parabola before, so
it seems to be related to recent updates to the h-client packages
(through before sending data didn't always work due to a bug in the
server that is now fixed).

PS: I've added Maxim in To as pers is the last person who worked on
improving the h-client package, so maybe pers has more knowledge
than me on that.

Denis.


pgpYYJRYbTZBN.pgp
Description: OpenPGP digital signature

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

On Mon, 23 May 2022 21:08:20 +0200
Denis 'GNUtoo' Carikli  wrote:
> I'll now try with the current HEAD to see if that's somehow fixed.

I've a similar failure with HEAD:
> \ 'check' phasebuilder for 
> `/gnu/store/m1iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv' 
> failed with exit code 1
> build of 
> /gnu/store/m1iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv failed
> View build log at 
> '/var/log/guix/drvs/m1/iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv.bz2'.
> cannot build derivation
> `/gnu/store/i6zxh4qblndfaqgz62fcm2s983pqj3ak-ruby-rubocop-1.10.0.drv':
> 1 dependencies couldn't be built

Denis.


pgpebABNWPhzO.pgp
Description: OpenPGP digital signature

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

Maybe an issue is that I've 2 cores on i686 while I've 4 on armv7h.

Or Maybe I didn't see what was there before (I use screen so it's not
convenient to copy-paste the output). Now I have:
> $ guix pull --commit=f0e9048e98f0789aa98de88984f4ee0fc9687f52 -M 1 -c 1
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from this channel:
>   guix  https://git.savannah.gnu.org/git/guix.git   f0e9048
> building 
> /gnu/store/m1iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv...
> - 'check' phasebuilder for 
> `/gnu/store/m1iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv' 
> failed with exit code 1
> build of 
> /gnu/store/m1iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv failed
> View build log at 
> '/var/log/guix/drvs/m1/iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv.bz2'.
> cannot build derivation 
> `/gnu/store/i6zxh4qblndfaqgz62fcm2s983pqj3ak-ruby-rubocop-1.10.0.drv': 1 
> dependencies couldn't be built
> Backtrace:
> building /gnu/store/abh2450yi3ndn66qwxlg3dpbc1j5r8g1-ruby-webmock-2.3.2.drv...
> cannot build derivation 
> `/gnu/store/pncfvxcp7irzsffydwj9f4h3i55xly11-ruby-byebug-11.1.3.drv': 1 
> dependencies couldn't be built
> building /gnu/store/8q33lywpkbx5l94hwf4k4mj6sn9zsqa2-yelp-xsl-41.0.drv...
> cannot build derivation 
> `/gnu/store/p11fi1gs5pvl8zbiqrwd5kx35x36jsk9-texlive-hyphen-afrikaans-59745.drv':
>  1 dependencies couldn't be built
> [...]
> cannot build derivation 
> `/gnu/store/76mv7y286isjcprbf4xjna9j2mhmpvky-texlive-hyphen-uppersorbian-59745.drv':
>  1 dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/m1g219klrksbrmi1x68a5n9a7aj36d9p-texlive-hyphen-welsh-59745.drv': 
> 1 dependencies couldn't be built
> cannot build derivation 
> `/gnu/store/n5bvrf8b42cdap7abggspy96wpg22ab4-texlive-amsmath-59745.drv': 1 
> dependencies couldn't be built
>   13 (primitive-load 
> "/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation")
> In ice-9/eval.scm:
> 155:9 12 (_ _)
> 159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) 
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
> In ice-9/boot-9.scm:
> 152:2 10 (with-fluid* _ _ _)
> 152:2  9 (with-fluid* _ _ _)
> In ./guix/store.scm:
>   2155:24  8 (run-with-store # _ 
> #:guile-for-build _ #:system _ #:target _)
>1983:8  7 (_ _)
> In ./guix/gexp.scm:
>300:22  6 (_ _)
>1181:2  5 (_ _)
>1047:2  4 (_ _)
> 893:4  3 (_ _)
> In ./guix/store.scm:
>   2040:12  2 (_ #)
>1391:5  1 (map/accumulate-builds # 
> # ?)
>   1406:15  0 (_ # _ _)
> 
> ./guix/store.scm:1406:15: ERROR:
>   1. :
>   message: "build of 
> `/gnu/store/n5bvrf8b42cdap7abggspy96wpg22ab4-texlive-amsmath-59745.drv' 
> failed"
>   status: 100
> guix pull: error: You found a bug: the program 
> '/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "f0e9048e98f0789aa98de88984f4ee0fc9687f52"; system: "armhf-linux";
> host version: "1.3.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

And here's the log:
> $ bzcat  
> /var/log/guix/drvs/m1/iyn6y1s3ajl6v0lv5658zq2cngdpq3-ruby-stackprof-0.2.17.drv.bz2
> starting phase `set-SOURCE-DATE-EPOCH'
> phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
> starting phase `set-paths'
> environment variable `PATH' set to 
> `/gnu/store/laxk3l38cx1ighbbmhjyqi0dnqg48ps8-ruby-2.7.4/bin:/gnu/store/yg3ggbyci3c5mqmraaqhfj9vini43r4d-ruby-rake-compiler-1.1.1/bin:/gnu/store/8gnahljsd06hax5vwh5kmk751jcjjzwy-tar-1.34/bin:/gnu/store/g4fr5clvd6sb735x92dbf068jl9z0959-gzip-1.10/bin:/gnu/store/sg7xawwdh23vxb6jqbnc6sckdnx00ldg-bzip2-1.0.8/bin:/gnu/store/pps1pijrj4jcp23k658ymhisdwf58bva-xz-5.2.5/bin:/gnu/store/l8az077ik67pz29nhhjai5ra5vlrcwz4-file-5.39/bin:/gnu/store/fncbwpmpkx5walrm3bnx586wj4kppkzr-diffutils-3.8/bin:/gnu/store/408wpqw5kx0v4p304vi6g86d1a95ynyy-patch-2.7.6/bin:/gnu/store/c7md7zma2706lzn96zrnzx70pq7m2b2k-findutils-4.8.0/bin:/gnu/store/ik5jr3x2s6vr7d77lmrrc2i03mfnr3hn-gawk-5.1.0/bin:/gnu/store/8iy4h07y9rcnr0i1a17r14fl5frx283s-sed-4.8/bin:/gnu/store/14w43053md7pprc76z33rdxjwc8vnkxd-grep-3.6/bin:/gnu/store/32fqqi7hkbx22jh917mf5g7phin5r16y-coreutils-8.32/bin:/gnu/store/0nz9kdv53yf2f87bgxa6wv8fcsrsp7gi-make-4.3/bin:/gnu/store/97xwzdsw9p6019dbml5mzf781c7avfkq-bash-minimal-5.1.8/bin:/gnu/store/95fsg9yv455ybq10qs409g6wffmqpn44-ld-wrapper-0/bin:/gnu/store/aaawb28w66dpmypf7qfndp8wmgrx7d0j-binutils-2.37/bin:/gnu/store/j1qipvd6087zklgxm0b3dphsagq4s5sa-gcc-10.3.0/bin:/gnu/store/nm8h8f988c2wvjk31lg1ww5zr65cd05c-glibc-2.33/bin:/gnu/store/nm8h8f988c2wvjk31lg1ww5zr65cd05c-glibc-2.33/sbin'
> environment variable `GEM_PATH' set to 
> `/gnu/store/laxk3l38cx1ighbbmhjyqi0dnqg48ps8-ruby-2.7.4/lib/ruby/vendor_ruby:/gnu/store/mdwww2mdf58x84z7gxwhjz1p7l8dbjki-ruby-mocha-1.13.0/lib/ruby/vendor_ruby:/gnu/store/yg3ggbyci3c5mqmraaqhfj9vini43r4d-ruby-rake-compiler-1.1.1/lib/ruby/vendor_ruby'
> environment variable 

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

On Mon, 23 May 2022 16:10:04 +0200
Maxime Devos  wrote:

> Denis 'GNUtoo' Carikli schreef op ma 23-05-2022 om 15:40 [+0200]:
> > Hi,
> > 
> > I've now made some free space. So we have:
> > - 1GiB of RAM and 16GiB of swap:
> >   > # cat /proc/swaps 
> >   >
> > FilenameType
> > Size Used   Priority
> >   > /dev/mmcblk0p1 
> > partition   1677721216384   -2
> 
> Could you check if it OOMs (with "sudo dmesg")?
> There were some problems in the past (maybe present too?) on i?86 with
> too much memory usage,
I've looked rapidly and I didn't see any OOMs. I've now used dmesg -c
and I'll launch the following command:
> guix pull --commit=f0e9048e98f0789aa98de88984f4ee0fc9687f52 -M 1 -c 1

And I'll see if it fails in the same way.

I also use a custom kernel and while I'm confident that the code
modifications have no impact here, I'm unsure if there are compilation
options related to OOM messages or not.

And here I probably lack some knowledge but I was under the impression
that swap was handled transparently by the kernel (through page tables,
virtual memory, and so on), so applications should not notice the
difference apart from the huge performance drop.

Though one issue could be that maybe for some reason the process wants
to use more than 3GiB of memory and at least i686 processes are limited
to 4GiB if you use an x86_64 kernel and about 3GiB if you use an i686
kernel. So maybe it's somehow similar for armv7h?

I also use Guix on an i686 installation of Parabola on my x86 laptop,
and I had issues with that in the past but recently I didn't notice
issues so at least if they are still there they are less frequent.

Maybe the difference is that on this ARM computer, I installed Guix
1.3.0 recently, and I didn't manage to do a guix pull that work yet, so
there is more diff between the current state (1.3.0) and where it wants
to go (close to HEAD on the master branch).

As of why a bigger diff would increase the probability of it failing
I've no idea.

What I could do could be to try to reproduce on an i686 Parabola VM,
this way it would be easier for people to reproduce. Though it's not
possible yet to pacstrap Parabola installations from Guix (I've some
WIP code for that but I need to fix bugs in it before being able to
send it).

Denis.


pgpc3vu3k6ufN.pgp
Description: OpenPGP digital signature

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

Hi,

I've now made some free space. So we have:
- 1GiB of RAM and 16GiB of swap:
  > # cat /proc/swaps 
  > FilenameTypeSizeUsed
Priority
  > /dev/mmcblk0p1  partition   1677721216384   
-2

- About 6GiB of free space on / and about 30GiB of free space on /gnu:
> # df -h 
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/root   9.5G  2.8G  6.7G  30% /
> devtmpfs403M 0  403M   0% /dev
> tmpfs   500M 0  500M   0% /dev/shm
> tmpfs   200M  2.1M  198M   2% /run
> tmpfs   500M 0  500M   0% /tmp
> /dev/mmcblk2p3   16M  5.5M  9.9M  36% /efs
> /dev/mmcblk0p2   42G  3.8G   36G  10% /gnu

And in my case the TMPDIR is in /gnu/tmp so it should have plenty of
space. From /etc/systemd/system/guix-daemon.service:
> Environment=GUIX_LOCPATH='/var/guix/profiles/per-user/root/guix-profile/lib/locale'
>  LC_ALL=en_US.utf8 TMPDIR=/gnu/tmp

So space should not be an issue anymore.

But with (I've fixed the commit to enable to retry with the same
commit):
> do guix pull --commit=f0e9048e98f0789aa98de88984f4ee0fc9687f52

I get the following error:
> Backtrace:
>   13 (primitive-load 
> "/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation")
> In ice-9/eval.scm:
> 155:9 12 (_ _)
> 159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) 
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))s
> In ice-9/boot-9.scm:
> 152:2 10 (with-fluid* _ _ _)
> 152:2  9 (with-fluid* _ _ _)
> In ./guix/store.scm:
>   2155:24  8 (run-with-store # _ 
> #:guile-for-build _ #:system _ #:target _)
>1983:8  7 (_ _)
> In ./guix/gexp.scm:
>300:22  6 (_ _)
>1181:2  5 (_ _)
>1047:2  4 (_ _)
> 893:4  3 (_ _)
> In ./guix/store.scm:
>   2040:12  2 (_ #)
>1391:5  1 (map/accumulate-builds # 
> # ?)
>   1406:15  0 (_ # _ _)
> 
> ./guix/store.scm:1406:15: ERROR:
>   1. :
>   message: "some substitutes for the outputs of derivation 
> `/gnu/store/rrxr8v48zvzd73qg6f8wkn5zwbnglg5w-tar-1.34.drv' failed (usually 
> happens due to networking issues); try `--fallback' to build derivation from 
> source "
>   status: 1
> guix pull: error: You found a bug: the program 
> '/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "f0e9048e98f0789aa98de88984f4ee0fc9687f52"; system: "armhf-linux";
> host version: "1.3.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

And retrying right after gives a similar error:
> Backtrace:
>   13 (primitive-load 
> "/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation")
> In ice-9/eval.scm:
> 155:9 12 (_ _)
> 159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) 
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
> In ice-9/boot-9.scm:
> 152:2 10 (with-fluid* _ _ _)
> 152:2  9 (with-fluid* _ _ _)
> In ./guix/store.scm:
>   2155:24  8 (run-with-store # _ 
> #:guile-for-build _ #:system _ #:target _)
>1983:8  7 (_ _)
> In ./guix/gexp.scm:
>300:22  6 (_ _)
>1181:2  5 (_ _)
>1047:2  4 (_ _)
> 893:4  3 (_ _)
> In ./guix/store.scm:
>   2040:12  2 (_ #)
>1391:5  1 (map/accumulate-builds # 
> # ?)
>   1406:15  0 (_ # _ _)
> 
> ./guix/store.scm:1406:15: ERROR:
>   1. :
>   message: "some substitutes for the outputs of derivation 
> `/gnu/store/rrxr8v48zvzd73qg6f8wkn5zwbnglg5w-tar-1.34.drv' fai
> led (usually happens due to networking issues); try `--fallback' to build 
> derivation from source "
>   status: 1
> guix pull: error: You found a bug: the program 
> '/gnu/store/hv9q35aibf5v5ggw3hh0xwy5qzyjbh1c-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "f0e9048e98f0789aa98de88984f4ee0fc9687f52"; system: "armhf-linux";
> host version: "1.3.0"; pull-version: 1).
> Please report the COMPLETE output above by email to .

I'll try to see if guix pull also works on another ARM device (TBS
2910 with An I.MX6Q and 2GiB of RAM).

If that works I'll simply do a guix pack with -RR of valgrind and gdb
and install that in a directory that is not /gnu. So that would enable
me to keep that Guix installation and wait for help to debug that
issue.

If that doesn't work I'll unfortunately have to uninstall Guix on that
GT-I9300 variant of the Galaxy SIII and instead cross compile a guix
pack with valgrind and gdb on an x86 computer without -RR (-R and -RR
aren't supported in cross compilation).

This is because I also need to continue working on making the modem
work as part of my work on Replicant 11 (I use GNU/Linux here as they
share part of the stack and GNU/Linux is easier to work with) and I
can't delay that work forever in the hope of solving a Guix bug, and
here I've no idea of the cause and so I would need some help, and if
I keep delaying that work too much I will be in big trouble as NLnet
is running out of funds in the fund that funds this work.

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

Hi,

Now it fails with the following error:

> substitute: updating substitutes from 'https://ci.guix.gnu.org'...
> 0.0%
>  /Backtrace:
>   
>   \
>  16 (primitive-load
> "/gnu/store/v1ag4yp033kib2cf3ggcgqiyygk47n89-compute-guix-derivation")
> In ice-9/eval.scm: 155:9 15 (_ _) 159:9 14 (_
> #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?)
> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) In ice-9/boot-9.scm: 152:2 13
> (with-fluid* _ _ _) 152:2 12 (with-fluid* _ _ _) In ./guix/store.scm:
> 2129:24 11 (run-with-store # _
> #:guile-for-build _ #:system _ #:target _) 1966:8 10 (_ _) In
> ./guix/gexp.scm: 300:22  9 (_ _) 1181:2  8 (_ _)
>1047:2  7 (_ _)
> 893:4  6 (_ _)
> In ./guix/store.scm:
>   2014:12  5 (_ #)
>   1410:13  4 (map/accumulate-builds # b21572d0> # ?) 1406:5  3
> b21572d0> (map/accumulate-builds #
> b21572d0> # ?)
>   1421:15  2 (_ # _ _)
>733:11  1 (process-stderr # _)
> In ./guix/serialization.scm:
>  80:6  0 (read-int #)
> 
> ./guix/serialization.scm:80:6: In procedure read-int:
> ERROR:
>   1. :
>   file: #f
>   port: #
> guix pull: error: You found a bug: the program
> '/gnu/store/v1ag4yp033kib2cf3ggcgqiyygk47n89-compute-guix-derivation'
> failed to compute the derivation for Guix (version:
> "edf86bacf294fea4decabeda77dd1cae9308b28e"; system: "armhf-linux";
> host version: "1.3.0"; pull-version: 1). Please report the COMPLETE
> output above by email to .

I've been trying again and again a lot of times for more than 1 month,
and I still can't update Guix.

I've also made sure that /gnu/tmp has space and I added a big swap
(16GiB):
> $ cat /etc/systemd/system/guix-daemon.service
> # This is a "service unit file" for the systemd init system to launch
> # 'guix-daemon'.  Drop it in /etc/systemd/system or similar to have
> # 'guix-daemon' automatically started.
> 
> [Unit]
> Description=Build daemon for GNU Guix
> 
> [Service]
> ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon
> --build-users-group=guixbuild
> Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale'
> LC_ALL=en_US.utf8 TMPDIR=/gnu/tmp RemainAfterExit=yes
> StandardOutput=syslog StandardError=syslog
> 
> # See
> .
> # Some package builds (for example, go@1.8.1) may require even more
> than # 1024 tasks. TasksMax=8192
> 
> [Install]
> WantedBy=multi-user.target
> $ df -h  
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/root   9.5G  7.2G  2.3G  77% /
> devtmpfs403M 0  403M   0% /dev
> tmpfs   500M 0  500M   0% /dev/shm
> tmpfs   200M  2.1M  198M   2% /run
> tmpfs   500M 0  500M   0% /tmp
> /dev/mmcblk2p3   16M  5.5M  9.9M  36% /efs
> /dev/mmcblk0p2   42G   24K   40G   1% /gnu/tmp
> $ cat /proc/swaps 
> Filename  Type
> Size  UsedPriority /dev/mmcblk0p1
>partition  1677721276544
>   -2

The issue is that in addition to the Guix issue I've a network
connection that is not very reliable (I need to unplug and re-plug the
USB cable from time to time) so that makes it impossible to have a
brute-force approach where it would try for months to do a guix pull
through various ways (guix pull, guix pull -M 1 -c 1, etc).

Still I also tried an automatic script but because of the network issue
I had to re-launch it each time the connection broke during fetch.

The issue is that at some point this brings rage because I 
think that it will work as it starts doing things (fetching, building
etc) so I try again and again and again and wait for it to finish, and
spend a lot of time trying again and for more than 1 month and it
didn't work yet:
> $ guix pull -l
> guix pull: error: profile
> '/var/guix/profiles/per-user/replicant/current-guix' does not exist

If I run that command as root instead we have:
> # guix pull -l
> Generation 1  mars 30 2022 13:38:03   (current)
but the manual doesn't tell to run guix pull as root.

And the issue is that the log I pasted above doesn't tell me much so 
I've no idea of what could be the issue.

Could it be that the amount of free space on / is too small?

I've also looked if there was some minimal device requirements to run
Guix on top of an existing distribution (here Parabola ARM) but I
found none.

And I also need Guix to work on that device to do builds of a library 
to continue working on that library. 

The issue is that guix pack -R 
or -RR doesn't work for cross compilation so if I install a pack it
will probably conflict with the store.

What could be the issue here?

In the meantime I'll try again with 'guix pull -M 1 -c 1
--commit=69ec5baaf7aa6ed3ce5ecaad9bb66d122f91c3ec' as root to see if
that works better.

But the issue is that I keep trying things and at the end nothing gives
me a clue or workarounds that 

bug#54728: [PATCH v2 2/2] gnu: valgrind: fix ld.so symbols not found

[Denis 'GNUtoo' Carikli]

Hi,

Did you manage to receive the patches, or were they lost somehow[1]?

At least I see them on https://issues.guix.gnu.org/54728 .

References:
---
[1]Personally for some reason I didn't receive a copy of the patches I
   sent through git-send-email in my mail.

Denis.


pgpqXvrYb7K8Z.pgp
Description: OpenPGP digital signature

bug#54728: [PATCH v2 2/2] gnu: valgrind: fix ld.so symbols not found

[Denis 'GNUtoo' Carikli]

For some reasons I didn't receive a copy of the cover letter patch I
sent with git-send-email yet, so I can't reply to the cover letter, so
I'm replying to the patch instead.

In any case the patches and the cover letter are in the bug[1] report
and so as promised here's the libsamsung-ipc.scm I used for the tests.

References:
---
[1]https://issues.guix.gnu.org/54728#8

Denis.
;;; Copyright © 2022 Denis Carikli 
;;;
;;; This file is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; This file is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License.
;;; If not, see .
;;;
;;; This file is meant to test valgrind support in Guix.
;;;
;;; The libsamsung-ipc library is not ready to be packaged in general
;;; purpose distributions as right now as it requires either a vendor
;;; kernel or the compbinaison of a recent upstream kernel with on top
;;; work in progress out of tree modem drivers, out of tree
;;; libsamsung-ipc code to support theses drivers and kernel patches
;;; to support the nonfree bootloader of the Galaxy SIII
;;; (GT-I9300). Beside the library, the tools are of very limited use
;;; beside testing or reverse engineering.

(use-modules
 (ice-9 popen)
 (ice-9 rdelim)
 (sxml ssax input-parse)
 ((guix licenses) #:prefix license:)
 (guix build-system android-ndk)
 (guix build-system gnu)
 (guix gexp)
 (guix git-download)
 (guix packages)
 (gnu packages android)
 (gnu packages autotools)
 (gnu packages curl)
 (gnu packages disk)
 (gnu packages linux)
 (gnu packages llvm)
 (gnu packages pkg-config)
 (gnu packages python)
 (gnu packages python-xyz)
 (gnu packages tls)
 (gnu packages valgrind))

(define-public libsamsung-ipc
  (package
(name "libsamsung-ipc")
;; we use a work in progress version that has support for --with-valgrind-tests
(version (git-version "0.0" "HEAD" "92de58c3ecd3f6a40323161dd28f2c9ad075ca62"))
(source
 (origin
   (method git-fetch)
   (uri
(git-reference
 (url "https://git.replicant.us/replicant-next/hardware_replicant_libsamsung-ipc;)
 (commit "92de58c3ecd3f6a40323161dd28f2c9ad075ca62")))
   (sha256
(base32 "0glm8hvb46iq1dhhbhymckxi6lcxn5k30lywcppbs7s8r4bnkwvy"))
   (file-name (git-file-name name version
(build-system gnu-build-system)
(native-inputs
 (list
  autoconf
  automake
  curl
  ddrescue
  libtool
  pkg-config
  python
  python-sh
  valgrind/interactive))
(inputs
 (list openssl))
(arguments
 `(#:phases
   (modify-phases %standard-phases
 (add-before 'build 'patch-python
   (lambda _
 (substitute* (find-files "." ".*\\.py$")
   (("/usr/bin/env python") (which "python3")))
   #t)))
   #:tests? #t
   #:configure-flags
   (list "--enable-debug"
 "--enable-valgrind-tests")))
(synopsis "libsamsung-ipc is a free software implementation of the Samsung IPC modem protocol")
(description
 "libsamsung-ipc is a free software implementation of the Samsung IPC modem protocol,
found in many Samsung smartphones and tablets.")
(home-page "https://www.replicant.us;)
(license license:gpl2+)))

(list libsamsung-ipc)


pgpWV5_azJOUh.pgp
Description: OpenPGP digital signature

bug#54728: [PATCH v2 1/2] gnu: valgrind: impots: sort imports alphabetically

[Denis 'GNUtoo' Carikli]

* gnu/packages/valgrind.scm: sort imports alphabetically

Signed-off-by: Denis 'GNUtoo' Carikli 
---
 gnu/packages/valgrind.scm | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/valgrind.scm b/gnu/packages/valgrind.scm
index 1cdc0f3b71..6648f17dfa 100644
--- a/gnu/packages/valgrind.scm
+++ b/gnu/packages/valgrind.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2016, 2020, 2022 Efraim Flashner 
 ;;; Copyright © 2018 Tobias Geerinckx-Rice 
 ;;; Copyright © 2020 Marius Bakke 
+;;; Copyright © 2022 Denis Carikli 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -22,13 +23,13 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (gnu packages valgrind)
-  #:use-module (guix packages)
-  #:use-module (guix download)
   #:use-module (guix build-system gnu)
+  #:use-module (guix download)
   #:use-module (guix licenses)
+  #:use-module (guix packages)
+  #:use-module (gnu packages)
   #:use-module (gnu packages gdb)
-  #:use-module (gnu packages perl)
-  #:use-module (gnu packages))
+  #:use-module (gnu packages perl))
 
 (define-public valgrind
   (package
-- 
2.35.1

bug#54728: [PATCH 2/2] gnu: valgrind: fix ld.so symbols not found

[Denis 'GNUtoo' Carikli]

Hi,

I've now managed to make a proper patch. I've used 'v2' for more
clarity.

I'll send the files used to test them in a subsequent mails.

As for the tests, I've done them in Guix system, once installed
valgrind works fine:
> $ make check
> valgrind -v --leak-check=full ./main
> ==20324== Memcheck, a memory error detector
> ==20324== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==20324== Using Valgrind-3.18.1-42b08ed5bd-20211015 and LibVEX; rerun with -h 
> for copyright info
> ==20324== Command: ./main
> ==20324== 
> --20324-- Valgrind options:
> --20324---v
> --20324----leak-check=full
> --20324-- Contents of /proc/version:
> --20324--   Linux version 5.16.20-gnu (guix@guix) (gcc (GCC) 10.3.0, GNU ld 
> (GNU Binutils) 2.37) #1 SMP PREEMPT 1
> --20324-- 
> --20324-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3
> --20324-- Page sizes: currently 4096, max supported 4096
> --20324-- Valgrind library directory: 
> /gnu/store/gkrqxqxs20mzxwxqpasy1q3w7a1v42w6-valgrind-3.18.1/libexec/valgrind
> --20324-- Reading syms from 
> /gnu/store/0iapawfss4xnxls622g23qpk4mwb9ihp-glibc-2.33/lib/ld-2.33.so
> --20324--   Considering 
> /gnu/store/wznq4d1i3znqjhcribfr2m9ljyyrsdyd-glibc-2.33-debug/lib/debug/gnu/store/0iapawfss4xnxls622g23qpk4mwb9ihp-glibc-2.33/lib/ld-2.33.so.debug
>  ..
> --20324--   .. CRC is valid
> --20324-- Reading syms from /home/gnutoo/work/projects/guix/valgrind-test/main
> --20324-- Reading syms from 
> /gnu/store/gkrqxqxs20mzxwxqpasy1q3w7a1v42w6-valgrind-3.18.1/libexec/valgrind/memcheck-x86-linux
> --20324--object doesn't have a symbol table
> --20324--object doesn't have a dynamic symbol table
> --20324-- Scheduler: using generic scheduler lock implementation.
> --20324-- Reading suppressions file: 
> /gnu/store/gkrqxqxs20mzxwxqpasy1q3w7a1v42w6-valgrind-3.18.1/libexec/valgrind/default.supp
> ==20324== embedded gdbserver: reading from 
> /tmp/vgdb-pipe-from-vgdb-to-20324-by-gnutoo-on-???
> ==20324== embedded gdbserver: writing to   
> /tmp/vgdb-pipe-to-vgdb-from-20324-by-gnutoo-on-???
> ==20324== embedded gdbserver: shared mem   
> /tmp/vgdb-pipe-shared-mem-vgdb-20324-by-gnutoo-on-???
> ==20324== 
> ==20324== TO CONTROL THIS PROCESS USING vgdb (which you probably
> ==20324== don't want to do, unless you know exactly what you're doing,
> ==20324== or are doing some strange experiment):
> ==20324==   
> /gnu/store/gkrqxqxs20mzxwxqpasy1q3w7a1v42w6-valgrind-3.18.1/libexec/valgrind/../../bin/vgdb
>  --pid=20324 ...command...
> ==20324== 
> ==20324== TO DEBUG THIS PROCESS USING GDB: start GDB like this
> ==20324==   /path/to/gdb ./main
> ==20324== and then give GDB the following command
> ==20324==   target remote | 
> /gnu/store/gkrqxqxs20mzxwxqpasy1q3w7a1v42w6-valgrind-3.18.1/libexec/valgrind/../../bin/vgdb
>  --pid=20324
> ==20324== --pid is optional if only one valgrind process is running
> ==20324== 
> --20324-- REDIR: 0x4021570 (ld-linux.so.2:strlen) redirected to 0x580a1f4a 
> (???)
> --20324-- REDIR: 0x40212d0 (ld-linux.so.2:index) redirected to 0x580a1f25 
> (???)
> --20324-- Reading syms from 
> /gnu/store/gkrqxqxs20mzxwxqpasy1q3w7a1v42w6-valgrind-3.18.1/libexec/valgrind/vgpreload_core-x86-linux.so
> --20324--object doesn't have a symbol table
> --20324-- Reading syms from 
> /gnu/store/gkrqxqxs20mzxwxqpasy1q3w7a1v42w6-valgrind-3.18.1/libexec/valgrind/vgpreload_memcheck-x86-linux.so
> --20324--object doesn't have a symbol table
> ==20324== WARNING: new redirection conflicts with existing -- ignoring it
> --20324-- old: 0x04021570 (strlen  ) R-> (.0) 0x580a1f4a 
> ???
> --20324-- new: 0x04021570 (strlen  ) R-> (2007.0) 0x04043ca0 
> strlen
> --20324-- Reading syms from 
> /gnu/store/r7n4snily34ld9nm4crzc0z65jr2y26c-gcc-10.3.0-lib/lib/libgcc_s.so.1
> --20324--object doesn't have a symbol table
> --20324-- Reading syms from 
> /gnu/store/0iapawfss4xnxls622g23qpk4mwb9ihp-glibc-2.33/lib/libc-2.33.so
> --20324--   Considering 
> /gnu/store/wznq4d1i3znqjhcribfr2m9ljyyrsdyd-glibc-2.33-debug/lib/debug/gnu/store/0iapawfss4xnxls622g23qpk4mwb9ihp-glibc-2.33/lib/libc-2.33.so.debug
>  ..
> --20324--   .. CRC is valid
> ==20324== WARNING: new redirection conflicts with existing -- ignoring it
> --20324-- old: 0x040f08c0 (memalign) R-> (1011.0) 0x04043084 
> memalign
> --20324-- new: 0x040f08c0 (memalign) R-> (1017.0) 0x0404303d 
> aligned_alloc
> ==20324== WARNING: new redirection conflicts with existing -- ignoring it
> --20324-- old: 0x040f08c0 (memalign) R-> (1011.0) 0x04043084 
> memalign
> --20324-- new: 0x040f08c0 (memalign) R-> (1017.0) 0x04042ff6 
> aligned_alloc
> ==20324== WARNING: new redirection conflicts with existing -- ignoring it
> --20324-- old: 0x040f08c0 (memalign) R-> (1011.0) 0x04043084 
> memalign
> --20324-- new: 0x040f08c0 (memalign) R-> (1017.0) 0x0404303d 
> aligned_alloc
> ==20324== 

bug#54728: [PATCH v2 2/2] gnu: valgrind: fix ld.so symbols not found

[Denis 'GNUtoo' Carikli]

* gnu/packages/valgrind.scm (valgrind/interactive)[native-inputs]:
  Add libc:debug
  [arguments]: Add patch-default-debuginfo-path phase
  [source]: Add patch.
  (valgrind-3.18)[source]: Add patch.

* gnu/packages/commencement.scm (glibc-final): Export variable.

Signed-off-by: Denis 'GNUtoo' Carikli 
---
 gnu/local.mk  |   3 +-
 gnu/packages/commencement.scm |   2 +-
 .../valgrind-fix-default-debuginfo-path.patch | 100 ++
 gnu/packages/valgrind.scm |  67 +++-
 4 files changed, 168 insertions(+), 4 deletions(-)
 create mode 100644 
gnu/packages/patches/valgrind-fix-default-debuginfo-path.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 9bad87710c..c28efcab32 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1919,7 +1919,8 @@ dist_patch_DATA = 
\
   %D%/packages/patches/util-linux-tests.patch  \
   %D%/packages/patches/util-linux-CVE-2021-3995.patch  \
   %D%/packages/patches/util-linux-CVE-2021-3996.patch  \
-  %D%/packages/patches/valgrind-enable-arm.patch   \
+  %D%/packages/patches/valgrind-enable-arm.patch   \
+  %D%/packages/patches/valgrind-fix-default-debuginfo-path.patch   \
   %D%/packages/patches/vboot-utils-fix-format-load-address.patch   \
   %D%/packages/patches/vboot-utils-fix-tests-show-contents.patch   \
   %D%/packages/patches/vboot-utils-skip-test-workbuf.patch \
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 1fed8bcd6e..769139e779 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3381,7 +3381,7 @@ (define gettext-boot0
 (("^PROGRAMS =.*$")
  "PROGRAMS =\n")
 
-(define glibc-final
+(define-public glibc-final
   ;; The final glibc, which embeds the statically-linked Bash built above.
   ;; Use 'package/inherit' so we get the 'replacement' of 'glibc', if any.
   (package/inherit
diff --git a/gnu/packages/patches/valgrind-fix-default-debuginfo-path.patch 
b/gnu/packages/patches/valgrind-fix-default-debuginfo-path.patch
new file mode 100644
index 00..f78dec02dc
--- /dev/null
+++ b/gnu/packages/patches/valgrind-fix-default-debuginfo-path.patch
@@ -0,0 +1,100 @@
+From a7f17b57a94e9cde6d7fa96ac86be5c4fc4f9211 Mon Sep 17 00:00:00 2001
+From: Denis 'GNUtoo' Carikli 
+Date: Sun, 24 Apr 2022 22:20:50 +0200
+Subject: [PATCH] valgrind: fix default debuginfo path
+
+Description: Workaround for missing symbol in Guix's ld.so. The
+ correct fix (not stripping all the ld.so symbols) will be done in the
+ next Guix release as it requires to recompile a lot of packages.
+
+Forwarded: not-needed
+Bug-Guix: https://issues.guix.gnu.org/54728
+Author: Denis 'GNUtoo' Carikli 
+---
+ coregrind/m_debuginfo/readelf.c | 11 ++-
+ docs/xml/manual-core-adv.xml|  4 ++--
+ docs/xml/manual-core.xml|  2 +-
+ 3 files changed, 9 insertions(+), 8 deletions(-)
+
+diff --git a/coregrind/m_debuginfo/readelf.c b/coregrind/m_debuginfo/readelf.c
+index c586e3f33..947fcc500 100644
+--- a/coregrind/m_debuginfo/readelf.c
 b/coregrind/m_debuginfo/readelf.c
+@@ -1509,9 +1509,9 @@ DiImage* find_debug_file( struct _DebugInfo* di,
+ 
+if (buildid != NULL) {
+   debugpath = ML_(dinfo_zalloc)("di.fdf.1",
+-VG_(strlen)(buildid) + 33);
++VG_(strlen)(buildid) + 
DEBUGPATH_EXTRA_BYTES_1);
+ 
+-  VG_(sprintf)(debugpath, "/usr/lib/debug/.build-id/%c%c/%s.debug",
++  VG_(sprintf)(debugpath, 
"DEFAULT_DEBUGINFO_PATH/.build-id/%c%c/%s.debug",
+buildid[0], buildid[1], buildid + 2);
+ 
+   dimg = open_debug_file(debugpath, buildid, 0, rel_ok, NULL);
+@@ -1536,7 +1536,8 @@ DiImage* find_debug_file( struct _DebugInfo* di,
+ 
+   debugpath = ML_(dinfo_zalloc)(
+  "di.fdf.3",
+- VG_(strlen)(objdir) + VG_(strlen)(debugname) + 64
++ VG_(strlen)(objdir) + VG_(strlen)(debugname)
++ + VG_(strlen)("DEFAULT_DEBUGINFO_PATH/") + 1
+  + (extrapath ? VG_(strlen)(extrapath) : 0)
+  + (serverpath ? VG_(strlen)(serverpath) : 0));
+ 
+@@ -1561,7 +1562,7 @@ DiImage* find_debug_file( struct _DebugInfo* di,
+ 
+   TRY_OBJDIR_USRMERGE_OBJDIR("%s/%s");
+   TRY_OBJDIR_USRMERGE_OBJDIR("%s/.debug/%s");
+-  TRY_OBJDIR_USRMERGE_OBJDIR("/usr/lib/debug%s/%s");
++  TRY_OBJDIR_USRMERGE_OBJDIR("DEFAULT_DEBUGINFO_PATH%s/%s");
+ 
+   if (extrapath) {
+  TRY_OBJDIR("%s%s/%s", extrapath, objdir, debugname);
+@@ -1631,7 +1632,7 @@ DiImage* find_debug_file_ad_hoc( const DebugInfo* di,
+ 
+debugpath = ML_(dinfo_zalloc)(
+   &quo

bug#54728: [PATCH 2/2] gnu: valgrind: fix ld.so symbols not found

[Denis 'GNUtoo' Carikli]

On Fri, 15 Apr 2022 18:21:33 +0200
Ludovic Courtès  wrote:
> Hello!
Hi,

[...]
> I find this patch-as-code snippet rather difficult to follow; it might
> also break easily if minor things change in those C files.
> 
> How about making it an actual patch?  In the patch, you’d have
> placeholders for the store file names, like @LIBC_DEBUG_DIRECTORY@;
> the phase would replace those placeholders with ‘substitute*’.
Thanks, I've done that and now the code is much easier to read.

> Rather: ("libc:debug" ,(canonical-package glibc) "debug").
The issue with that is that importing "gnu packages commencement" fails
with the following error:
> $ ./pre-inst-env guix build hello
> error: tcc: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: googletest: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: bzip2: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: binutils: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: gcc-4.9: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: xz: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: gnu-make: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: binutils: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: perl: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> error: coreutils: unbound variable
> hint: Did you forget a `use-modules' form?
> 
> Throw to key `unbound-variable' with args `("resolve-interface" "no
> binding `~A' in module ~A" (python (gnu packages python)) #f)'.
> Backtrace: In guix/store.scm:
>658:37 19 (thunk)
>1320:8 18 (call-with-build-handler #
> ?) In guix/scripts/build.scm:
> 499:2 17 (_)
> In srfi/srfi-1.scm:
>673:15 16 (append-map _ _ . _)
>586:17 15 (map1 ((argument . "hello") (build-mode . 0) (# . #t) ?))
> In guix/scripts/build.scm:
>519:31 14 (_ _)
> In gnu/packages.scm:
> 480:2 13 (%find-package "hello" "hello" #f)
> 365:6 12 (find-best-packages-by-name _ _)
>295:56 11 (_ "hello" _)
> In unknown file:
>   10 (force # gnu/packages.sc?>) In gnu/packages.scm:
>242:33  9 (fold-packages #
> ?) In guix/discovery.scm:
>159:11  8 (all-modules _ #:warn _)
> In srfi/srfi-1.scm:
>460:18  7 (fold #
> ?) In guix/discovery.scm:
>149:19  6 (_ _ ())
> 116:5  5 (scheme-modules _ _ #:warn _)
> In srfi/srfi-1.scm:
>691:23  4 (filter-map # .
> #) In guix/discovery.scm:
>124:24  3 (_ . _)
> In guix/ui.scm:
> 319:2  2 (report-unbound-variable-error _ #:frame _)
> In ice-9/boot-9.scm:
>   1685:16  1 (raise-exception _ #:continuable? _)
>   1685:16  0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Throw to key `match-error' with args `("match" "no matching pattern"
> (unbound-variable "resolve-interface" "no binding `~A' in module ~A"
> (python (gnu packages python)) #f))'.
So I need to not import gnu packages commencement globally.

I can also do something like that instead: 
> ("glibc:debug"
> ,((@@ (gnu packages commencement) canonical-package)
>(@@ (gnu packages commencement) glibc)) "debug")

Which form is the best?

Beside the glibc:debug input, the new patch is ready to be sent. I also
successfully managed to run tests that use valgrind transparently (by
using valgrind/interactive in the native inputs).

Denis.


pgpBDGn9Fa900.pgp
Description: OpenPGP digital signature

bug#54728: [PATCH 2/2] gnu: valgrind: fix ld.so symbols not found

[Denis 'GNUtoo' Carikli]

* gnu/packages/valgrind.scm (valgrind/interactive)[native-inputs]:
  Add libc:debug
  [arguments]: Add patch-default-debuginfo-path phase
* gnu/packages/commencement.scm (glibc-final): Export variable.

Signed-off-by: Denis 'GNUtoo' Carikli 
---
 gnu/packages/commencement.scm |  2 +-
 gnu/packages/valgrind.scm | 66 +++
 2 files changed, 61 insertions(+), 7 deletions(-)

diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index e8b47fbeab..c2de02411c 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3381,7 +3381,7 @@ (define gettext-boot0
 (("^PROGRAMS =.*$")
  "PROGRAMS =\n")
 
-(define glibc-final
+(define-public glibc-final
   ;; The final glibc, which embeds the statically-linked Bash built above.
   ;; Use 'package/inherit' so we get the 'replacement' of 'glibc', if any.
   (package/inherit
diff --git a/gnu/packages/valgrind.scm b/gnu/packages/valgrind.scm
index 6648f17dfa..a09721071d 100644
--- a/gnu/packages/valgrind.scm
+++ b/gnu/packages/valgrind.scm
@@ -25,8 +25,10 @@
 (define-module (gnu packages valgrind)
   #:use-module (guix build-system gnu)
   #:use-module (guix download)
+  #:use-module (guix gexp)
   #:use-module (guix licenses)
   #:use-module (guix packages)
+  #:use-module (guix utils)
   #:use-module (gnu packages)
   #:use-module (gnu packages gdb)
   #:use-module (gnu packages perl))
@@ -91,12 +93,64 @@ (define-public valgrind
 (properties '((hidden? . #t)
 
 (define-public valgrind/interactive
-  (package/inherit
-   valgrind
-   (inputs
-;; GDB is needed to provide a sane default for `--db-command'.
-`(("gdb" ,gdb)))
-   (properties '(
+  (package/inherit valgrind
+(inputs
+ ;; GDB is needed to provide a sane default for `--db-command'.
+ `(("gdb" ,gdb)
+   ("libc:debug" ,(@@ (gnu packages commencement) glibc-final) "debug")))
+(arguments
+ (substitute-keyword-arguments (package-arguments valgrind)
+   ((#:phases those-phases #~%standard-phases)
+#~(let* ((those-phases #$those-phases)
+ (unpack (assoc-ref those-phases 'unpack)))
+(modify-phases those-phases
+  (add-before 'build 'patch-default-debuginfo-path
+(lambda _
+  ;; This helps Valgrind find the debug symbols of ld.so.
+  ;; Without it, Valgrind does not work in a Guix shell
+  ;; container and cannot be used as-is during packages tests
+  ;; phases
+  (substitute* '
+("coregrind/m_debuginfo/readelf.c"
+  "docs/xml/manual-core-adv.xml"
+  "docs/xml/manual-core.xml")
+(("/usr/lib/debug")
+ (string-append
+   (assoc-ref %build-inputs "libc:debug")
+   "/lib/debug")))
+  ;; We also need to account for the bigger path in
+  ;; the malloc-ed variables
+  (substitute* '
+("coregrind/m_debuginfo/readelf.c")
+(("VG_\\(strlen\\)\\(buildid\\) \\+ 33")
+  (string-append
+"VG_(strlen)(buildid) + "
+(number->string
+ (+ (string-length
+(string-append
+  (assoc-ref %build-inputs "libc:debug")
+  "/lib/debug"))
+(string-length "/.build-id//.debug")
+1)
+  (substitute* '
+("coregrind/m_debuginfo/readelf.c")
+((string-append
+  "VG_\\(strlen\\)\\(objdir\\) \\+ "
+  "VG_\\(strlen\\)\\(debugname\\) \\+ 64")
+ (string-append
+  "VG_(strlen)(objdir) + VG_(strlen)(debugname) + "
+  (number->string
+(+ (string-length
+(string-append
+ (assoc-ref
+  %build-inputs
+  "libc:debug")
+ "/lib/debug"))
+   (string-length
+"/usr/lib/debug")
+   1)
+  #t)))
+(properties '(
 
 (define-public valgrind-3.18
   (package
-- 
2.35.1

bug#54728: [PATCH 1/2] gnu: valgrind: impots: sort imports alphabetically

[Denis 'GNUtoo' Carikli]

* gnu/packages/valgrind.scm: sort imports alphabetically

Signed-off-by: Denis 'GNUtoo' Carikli 
---
 gnu/packages/valgrind.scm | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/valgrind.scm b/gnu/packages/valgrind.scm
index 1cdc0f3b71..6648f17dfa 100644
--- a/gnu/packages/valgrind.scm
+++ b/gnu/packages/valgrind.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2016, 2020, 2022 Efraim Flashner 
 ;;; Copyright © 2018 Tobias Geerinckx-Rice 
 ;;; Copyright © 2020 Marius Bakke 
+;;; Copyright © 2022 Denis Carikli 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -22,13 +23,13 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (gnu packages valgrind)
-  #:use-module (guix packages)
-  #:use-module (guix download)
   #:use-module (guix build-system gnu)
+  #:use-module (guix download)
   #:use-module (guix licenses)
+  #:use-module (guix packages)
+  #:use-module (gnu packages)
   #:use-module (gnu packages gdb)
-  #:use-module (gnu packages perl)
-  #:use-module (gnu packages))
+  #:use-module (gnu packages perl))
 
 (define-public valgrind
   (package
-- 
2.35.1

bug#54728: Valgrind not working out of the box due to stripped ld.so

[Denis 'GNUtoo' Carikli]

On Thu, 07 Apr 2022 18:40:08 +0200
Ludovic Courtès  wrote:

> Hi,
Hi,

> Unfortunately, until that branch is merge (most likely a few months
> from now), we’ll have to use the workaround you mentioned.
> 
> Alternatively, maybe we could temporarily patch the ‘valgrind’ package
> such that it has ‘--extra-debuginfo-path=…’ by default.  Would you
> like to give it a try?
That is a good idea. As I need it anyway[1], I've actually worked on
doing that through patching Valgrind source code to use better defaults
than /usr/lib/debug but there is a couple of things I'm unsure with my
patch:
- First it works fine in 'guix shell -C' but it still fails
  in packages. Maybe I didn't patch the right Valgrind?

- Then for some reasons guix style messes up the whitespaces with the
  following command:
  $ ./pre-inst-env guix style -e \
'(@@ (gnu packages valgrind) valgrind/interactive)';
  So I did the style by hand instead, so it might contain mistakes.

- And finally I'm not comfortable enough with Valgrind or how it's been
  used in Guix. As I understand from the comment in the first Valgrind
  being defined in valgrind.scm, it seems to be depended on by a lot of
  packages. In addition I've not looked why there is a
  valgrind/interactive or how it works yet, so someone would need to
  double check my patch carefuly.

I've attached a libsamsung-ipc.scm file as I used that for testing my
patch (in addition of just running Valgrind in a Guix shell container
and while building this package it fails.

I'll send the patch as a response to this mail.

References:
---
[1] At the end of the day I need it to work in both standalone mode and
also in package builds as I use a guix.scm to run various
compilation and runtime for libsamsung-ipc before pushing patches
to the main branch.

Denis.
;;; Copyright © 2022 Denis Carikli 
;;;
;;; This file is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; This file is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License.
;;; If not, see .
;;;
;;; This file is meant to test valgrind support in Guix.
;;;
;;; The libsamsung-ipc library is not ready to be packaged in general
;;; purpose distributions as right now as it requires either a vendor
;;; kernel or the compbinaison of a recent upstream kernel with on top
;;; work in progress out of tree modem drivers, out of tree
;;; libsamsung-ipc code to support theses drivers and kernel patches
;;; to support the nonfree bootloader of the Galaxy SIII
;;; (GT-I9300). Beside the library, the tools are of very limited use
;;; beside testing or reverse engineering.

(use-modules
 (ice-9 popen)
 (ice-9 rdelim)
 (sxml ssax input-parse)
 ((guix licenses) #:prefix license:)
 (guix build-system android-ndk)
 (guix build-system gnu)
 (guix gexp)
 (guix git-download)
 (guix packages)
 (gnu packages android)
 (gnu packages autotools)
 (gnu packages commencement)
 (gnu packages curl)
 (gnu packages disk)
 (gnu packages linux)
 (gnu packages llvm)
 (gnu packages pkg-config)
 (gnu packages python)
 (gnu packages python-xyz)
 (gnu packages tls)
 (gnu packages valgrind))

(define-public libsamsung-ipc
  (package
(name "libsamsung-ipc")
;; we use a work in progress version that has support for --with-valgrind-tests
(version (git-version "0.0" "HEAD" "4d3062db15783c188d6952f7b9b794b65cd93f66"))
(source
 (origin
   (method git-fetch)
   (uri
(git-reference
 (url "https://git.replicant.us/replicant-next/hardware_replicant_libsamsung-ipc;)
 (commit "4d3062db15783c188d6952f7b9b794b65cd93f66")))
   (sha256
(base32 "1jzv9z5rkgcx394akf2svja586z54vhd46pvdmzm3ilmspnvjcdx"))
   (file-name (git-file-name name version
(build-system gnu-build-system)
(native-inputs
 `(("autoreconf" ,autoconf)
   ("aclocal" ,automake)
   ("libcurl" ,curl)
   ("ddrescue", ddrescue)
   ;; ("libc:debug", (@@ (gnu packages commencement) glibc-final) "debug")
   ("libtool" ,libtool)
   ("pkgconfig" ,pkg-config)
   ("python" ,python)
   ("python-sh" ,python-sh)
   ("valgrind" ,valgrind)))
(inputs
 `(("openssl" ,openssl)))
(arguments
 `(#:phases
   (modify-phases %standard-phases
 (add-before 'build 'patch-python
   (lambda _
 (substitute* (find-files "." ".*\\.py$")
   (("/usr/bin/env python") (which "python3")))
   #t))
 (add-after 'patch-python 'fix-valgrind
   (lambda _
 (substitute* 

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

Hi,

I forgot to mention that it happened right after the installation of
Guix on top of Parabola with the guix installer script.

(I didn't manage to do a guix pull before).

I'll keep retrying from time to time and report if it's fixed.

Denis.


pgpRdLh5okXYA.pgp
Description: OpenPGP digital signature

bug#54728: Valgrind not working out of the box due to stripped ld.so

[Denis 'GNUtoo' Carikli]

Hi,

The fact that Valgrind doesn't work out of the box seems to already be
known[1] but I didn't find any bugreports on it.

The workaround[1] mentioned is extremely useful but it's far from ideal.

For instance if you have a software that uses Valgrind in its tests
(for instance in 'make check') you end up having to add something like
that in the native-inputs to refer to the right glibc debug symbols
directory:
> ("libc:debug", (@@ (gnu packages commencement) glibc-final) "debug")

In my case I'm using guix and a guix.scm for testing the build of a
library I maintain and I also wanted to automatically check for memory
safety.

I was helped a lot on #guix to solve the issue I had, and during that
mjw suggested to fix the root issue by keeping "the .symtab in ld.so"
without the full debug info (to save space) and if I understood right
mjw is a valgrind contributor.

According to mjw that could be done with strip -g or strip -d or -strip
-S.

Reference:
--
[1]https://lists.gnu.org/archive/html/help-guix/2022-03/msg00036.html

Denis.


pgplWYWF0KJLq.pgp
Description: OpenPGP digital signature

bug#54651: Guix pull failing on ARM 32bit with "Please report the COMPLETE output above by email"

[Denis 'GNUtoo' Carikli]

Hi,

Here's the failing command output:
# guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to dda555f (17,297 new 
commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   dda555f
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building 
/gnu/store/k5ayqyakr8hi4lqs2vsprflbdn7iikyg-compute-guix-derivation.drv...
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%   

/substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building 
/gnu/store/rffgxc50vcqd5f05yyc9sp2cqcf6mfhg-linux-libre-headers-5.10.35.drv...
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
| 'unpack' phaseguix pull: error: You found a bug: the program 
'/gnu/store/8yz64sjw2fpamsrs5j91d3svqdyn6rsq-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"dda555feadf4fce11e792555258f1c9a52f19466"; system: "armhf-linux";
host version: "1.3.0"; pull-version: 1).
Please report the COMPLETE output above by email to .

The device is a Galaxy SIII (GT-I9300) running Parabola with the
Replicant 11 kernel. It has a 32bit ARM CPU.

Denis.


pgpt_WnmfSaI9.pgp
Description: OpenPGP digital signature

bug#42379: uninstaller

[Denis 'GNUtoo' Carikli]

Hi,

There are valid use cases for uninstalling Guix: 
- On a Trisquel VM I use Guix to add matterbridge to it with guix pack.
  Once the tarball is done with guix pack I remove Guix and install the
  pack to limit the attack surface. To do the updates I install Guix
  back and re-do a tarball.
- On some machines I sometimes need Guix but when I don't need it
  anymore I tend to remove it not to have to maintain too much software
  (having to run guix pull when you don't use Guix is probably not a
  good idea).

So I use a standalone script I did for that, but the patch in this bug
report is more complete than my script, so I should probably find the
time to pick up that work.

Denis.


pgpYCk_1bnzPS.pgp
Description: OpenPGP digital signature

bug#53462: Guile 2.0.14: check fails on i686

[Denis 'GNUtoo' Carikli]

Hi,

With Guix system i686, at the following commit:
> cadcbbaf65 gnu: r-bigmelon: Add r-knitr.
guile 2.0.14 fails tests.

I've attached the log.

I'm unsure what to do here as it's Guile 2.0.14 and on Guile website I
only see Guile 3.0.7 and guile 2.2.7[1], and Guile 2.0.14 s from
2017[2].

References:
---
[1]https://www.gnu.org/software/guile/download
[2]https://ftp.gnu.org/gnu/guile

Denis.


jzprbg6cz1pdn48x8cwhm62rajsv74-guile-2.0.14.drv.bz2
Description: application/bzip


pgpHLRZLIgsj7.pgp
Description: OpenPGP digital signature

bug#52727: When logged as user, GUILE_LOAD_COMPILED_PATH points to the system cache instead of the user cache

[Denis 'GNUtoo' Carikli]

On Wed, 22 Dec 2021 11:29:29 +0100
Maxime Devos  wrote:

> Liliana Marie Prikler schreef op wo 22-12-2021 om 08:57 [+0100]:
> > For the record, guile has been a part of the system profile since
> > %base-packages were first defined, so if your load paths break,
> > there is probably a larger issue at hand.  In this particular case,
> > your local guix profile ought to shadow anything that's in
> > /run/current- system, so I don't really get how the ABI match is
> > triggered.  Perhaps you might want to debug that in a REPL.  
> 
> Maybe the system guix has a package module that does not exist in the
> user guix, so guix tries to load the system package module instead of
> the non-existing user package module?
In my system.scm (I attached it) I do have a package (fdm-git) that
doesn't exist elsewhere (because I need a patch that is upstream but
not in an fdm release yet).

Right now I can't test without fdm-git because when doing guix
system reconfigure, it tries to build guix but its tests fails. I'll
bugreport about that.

Denis.
;; Copyright (C) 2021 Denis 'GNUtoo' Carikli 
;;
;; This program is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;;
;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.
;;
;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

(use-modules
 (gnu)
 (gnu system mapped-devices)
 (gnu system nss)
 (guix build-system gnu)
 (guix git-download)
 ((guix licenses) #:prefix license:)
 (guix packages))
(use-package-modules
 admin
 android
 audio
 autotools
 base
 bash
 bison
 bootloaders
 certs
 commencement
 compression
 cryptsetup
 databases
 disk
 display-managers
 emacs
 emacs-xyz
 file
 flashing-tools
 freedesktop
 gnome
 gnupg
 linux
 mail
 mpd
 networking
 ncurses
 package-management
 patchutils
 pulseaudio
 python
 rsync
 screen
 ssh
 terminals
 tls
 tor
 version-control
 video
 vim
 virtualization
 web
 web-browsers
 wm
 xdisorg
 xfce
 xorg)
(use-service-modules
 databases
 desktop
 mail
 networking
 sound
 virtualization
 xorg)

(define-public fdm-git
  (package
(name "fdm-git")
(version "2.0+25")
(source
 (origin
   (method git-fetch)
   (uri (git-reference
 (url "https://github.com/nicm/fdm;)
 (commit "c245d210a5b0049f48c78e40af44d2889ecf217f")))
   (file-name (git-file-name name version))
   (sha256
(base32 "06al4rs11c859zwfqknicn31nz66w1g73bsb61463dk12q06pwy7"
(build-system gnu-build-system)
(inputs
 `(("tdb" ,tdb)
   ("openssl" ,openssl)
   ("zlib" ,zlib)))
(native-inputs
 `(("autoconf" ,autoconf)
   ("automake" ,automake)
   ("bison-3.6" ,bison-3.6)))
(home-page "https://github.com/nicm/fdm;)
(synopsis "Mail Retrieval Agent (MRA) and Mail Delivery Agent (MDA)")
(description "fdm is a program designed to fetch mail from POP3
or IMAP servers, or receive local mail from stdin, and
deliver it in various ways.")
(license
 ;; Why point to a source file?  Well, all the individual files have a
 ;; copy of this license in their headers, but there's no seprate file
 ;; with that information.
 (license:non-copyleft
  "https://github.com/nicm/fdm/blob/master/command.c;

(define %lvm-vg
  (list
   (mapped-device
(source (uuid "fd8d9fd8-56a5-4c61-9f6e-35371ff964f0"))
(target "internal-cleartext")
(type luks-device-mapping))
   (mapped-device
(source "primary_laptop")
(targets (list "primary_laptop-guix32"))
(type lvm-device-mapping
(define %guix32-rootfs
  (file-system
   (device "/dev/mapper/primary_laptop-guix32")
   (mount-point "/")
   (type "ext4")
   (dependencies %lvm-vg)))
(define %parabola32-rootfs
  (file-system
   (mount-point "/srv/distros/parabola32")
   (device "/dev/mapper/primary_laptop-parabola32")
   (type "ext4")
   (dependencies %lvm-vg)
   (create-mount-point? #t)
   (mount-may-fail? #t)))

(define (parabola32-bind-mount path)
  (file-system
   (mount-point path)
   (device (string-append "/srv/distros/parabola32" path))
   (type "none")
   (dependencies (list %parabola32-rootfs))
   (flags '(bind-mount))
   (create-mount-point? #t)
   (mount-may-fail? #t)))

(operating-system
 (host-name "primary_laptop")
 (timez

bug#52727: When logged as user, GUILE_LOAD_COMPILED_PATH points to the system cache instead of the user cache

[Denis 'GNUtoo' Carikli]

chat, I'm supposed to be able
to not keep my user profile and my guix system in sync.

Would the solution to that be to correctly export
GUILE_LOAD_COMPILED_PATH in  ~/.guix-profile/etc/profile like it is
done in the patch I attached (with an extra small modification in the
commit message to mention the bug report)?

Other commits fixing bugs in that same profile mentioned bug reports,
so I assume that it's simplier to discuss the bug in a bug report
than directly sending a patch to fix the issue.

Note that I also didn't test the patch yet but I did test that export
command.

Denis.
From 579e613da312f288aa9b9aebd264794bb9586625 Mon Sep 17 00:00:00 2001
From: Denis 'GNUtoo' Carikli 
Date: Wed, 22 Dec 2021 00:45:28 +0100
Subject: [PATCH] gnu: system: $GUIX_PROFILE/etc/profile: Fix
 GUILE_LOAD_COMPILED_PATH

* gnu/system.scm (operating-system-etc-service)[profile]: export
  GUILE_LOAD_COMPILED_PATH

Signed-off-by: Denis 'GNUtoo' Carikli 
---
 gnu/system.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/system.scm b/gnu/system.scm
index 088c62ddde..4dbdf1928e 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -987,6 +987,8 @@ (define* (operating-system-etc-service os)
 # Allow GStreamer-based applications to find plugins.
 export GST_PLUGIN_PATH=\"$HOME/.guix-profile/lib/gstreamer-1.0\"
 
+export GUILE_LOAD_COMPILED_PATH=\"$HOME/.config/guix/current/lib/guile/3.0/site-ccache:$HOME/.config/guix/current/share/guile/site/3.0\"
+
 if [ -n \"$BASH_VERSION\" -a -f /etc/bashrc ]
 then
   # Load Bash-specific initialization code.
-- 
2.34.0



pgp_t66UONIKE.pgp
Description: OpenPGP digital signature

bug#36786: Warn of AMD GPUs unusable with Guix System

[Denis 'GNUtoo' Carikli]

Would it be better to find a way to fix these issue rather than warn
people about it? They look realatively easy to fix.

For the Radeon / AMDGPU drivers to work, you need:
- A patch need to be upstreamed in linux-libre for the GPU family to
  make the driver load. That patch needs to be tested on real hardware.
- Potentially some configuration for Xorg for recent cards to account
  for the lack of hardware 2D acceleration. Without it we could have
  something like that (from Parabola):
  '/usr/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol:
  exaGetPixmapDriverPrivate'

The Libreplanet wiki[1] has all the information about that. If each
person with an unsupported GPU and a bit of skills (it requires to
compile linux-libre) and a bit of time (it should not take that long,
it'll probably be something between less than 1 hour to 1 day), or that
we try to help people with these GPU doing that, we could fix it for
good.

I already did it for all the AMD GPUs I had access to, but despite the
fact that it's really a low hanging fruit, only 1 person that needed a
lot of help tried to follow these tutorials (though I didn't manage to
find the time it required to help that person until the end).

All the information about was added in the libreplanet wiki[1] as it is
relevant to most GNU/Linux FSDG compliant distributions and the problem
is not specific to a given distribution.

References:
---
[1]https://libreplanet.org/wiki/Group:Hardware/research/gpu/radeon

Denis.


pgpFAeO4xsKBW.pgp
Description: OpenPGP digital signature

bug#51352: Matterbridge contained a lot of vendored code

[Denis 'GNUtoo' Carikli]

Hi,

When I sent the patch adding matterbridge to Guix, I only notified that
I didn't know if it contained vendored code or not at the last moment
(after the patch was sent, during the discussion about it, and before
it was merged).

The issue is that I didn't know go at all and more specifically I didn't
know its the compilation system worked. So I managed to create a
package for matterbridge by looking at how it was done for other go
packages.

After learning more about how go compilation worked, I found out that
matterbridge contained a lot of vendored code.

And Guix explicitly wants to avoid bundles code. In the "16.6 Submitting
Patches" section of the manual[1], we have:
> 6. Make sure the package does not use bundled copies of software
> already available as separate packages.
And here while most dependencies are not already packaged, some are,
and I guess that I should read between the lines and conclude that all
the matterbridge dependencies should rather be packaged.

So the question is what should we do about that. 

As I understand with the go build system, or you vendor all
dependencies, or you vendor none, and I've not yet managed to find a
way to workaround that yet in Guix (to do a progressive unvendoring).

So instead I've started working on unvendoring matterbridge[2]
completely, but if we go this route, there are more than 500
dependencies.

To do that I first used the following command:
guix import go -r github.com/42wim/matterbridge

I then started looking at each package definition that Guix didn't
manage to detect the license of, and I read the licenses to find if
they were free software. All the licenses I read were FSDG compliant.
Usually they had some extra text indicating the provenance of the code
or they would have multiple free software licenses.

Then I started adding packages for the dependencies that guix import go
didn't manage to find.

Theses are repositories that are being forked from the official ones
for a reason or another.

I've not finished that yet, but I still think it was a good idea to
open a bug report as I've now more understanding of the problem.

Given the huge amount of dependencies I was wondering what was the best
approach here:
- Would it makes sense to remove matterbridge from Guix, or should we
  fix it instead?
- If we fix it by packaging each dependencies, would it be ok if that
  is done step by step, like if dependencies are packaged and patches
  for them are sent, without necessarily a way to seriously test if
  the packaged dependency work until they are used by other software
  (like matterbridge)?

Also when I'll manage to update matterbridge[3] how should we deal with
such amount of packages? Would I need to send one (generated) patch for
the upgrade of each package?

I also guess that sticking as much as possible to what Guix import go
generates would help in situations like that as it would make the
maintenance faster.

References:
---
[1]https://guix.gnu.org/manual/en/guix.html#Submitting-Patches
[2]https://git.replicant.us/contrib/GNUtoo/infrastructure/guix/log/?h=matterbridge-unvendor
[3]Right now there is a compilation issue that I didn't manage to fix,
  even with help from #guix).

Denis.


pgpKwoSUj7Kgr.pgp
Description: OpenPGP digital signature

bug#51259: Cannot build Guix from source (error messages about the translations)

[Denis 'GNUtoo' Carikli]

On Wed, 20 Oct 2021 11:52:54 -0400
Julien Lepiller  wrote:

> You might be running with modified files, or the container is doing
> something unexpected. Can you try again from a clean checkout, or
> after cleaning with "git clean -fdx"? This should put the repo back
> to the last commit, and remove any additional files, as if you just
> pulled it.
I tried many things (including git clean -dfx) and at the end I don't
know exactly what made it compile but it works now and I suspect that
it's either removing GUIX_PACKAGE_PATH or using guix pull && guix
package -u that fixed it for me.

Denis.


pgpVJG1pmJWPj.pgp
Description: OpenPGP digital signature

bug#51259: Cannot build Guix from source (error messages about the translations)

[Denis 'GNUtoo' Carikli]

Hi,

I'm on i686, and I've tried all the approaches mentioned:
- export LC_ALL=en_US.utf8
- rm doc/contributing.*.texi
- the patch in doc/local.mk

on top of the following commit:
19d3cfec72 gnu: python-arrow: Move python-pytz to native-inputs.

I tried building Guix with both:
- guix environment guix -C guix
- guix environment --pure guix

And for building I use
export LC_ALL=en_US.utf8
rm -f doc/contributing.*.texi && \
./bootstrap && \
./configure --localstatedir=/var && \
make clean && \
make -j2

And that gives the following compilation error (with guix environment
guix -C guix):
> ). Please consider running po4a-updatepo to refresh it.
> sed -i "s|guix\.info|$(basename "doc/guix.zh_CN.texi" | sed 
> 's|texi$|info|')|" "doc/guix.zh_CN.texi.tmp"
>   POXREF doc/guix.zh_CN.texi
> translated 914 cross-references in 'doc/guix.sk.texi.tmp'
> mv "doc/guix.sk.texi.tmp" "doc/guix.sk.texi"
> translated 914 cross-references in 'doc/guix.zh_CN.texi.tmp'
> mv "doc/guix.zh_CN.texi.tmp" "doc/guix.zh_CN.texi"
> make  all-recursive
> make[1]: Entering directory '/home/gnutoo/work/projects/guix/guix'
> Making all in po/guix
> make[2]: Entering directory '/home/gnutoo/work/projects/guix/guix/po/guix'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory '/home/gnutoo/work/projects/guix/guix/po/guix'
> Making all in po/packages
> make[2]: Entering directory '/home/gnutoo/work/projects/guix/guix/po/packages'
> make[2]: Nothing to be done for 'all'.
> make[2]: Leaving directory '/home/gnutoo/work/projects/guix/guix/po/packages'
> make[2]: Entering directory '/home/gnutoo/work/projects/guix/guix'
>   MAKEINFO doc/guix-cookbook.ko.info
>   MAKEINFO doc/guix-cookbook.zh_Hans.info
> ./doc/guix-cookbook.zh_Hans.texi:2892: @node `' previously defined
> ./doc/guix-cookbook.zh_Hans.texi:1385: here is the previous definition as 
> @node
> ./doc/guix-cookbook.zh_Hans.texi:1385: warning: node next `' in 
> menu `Acknowledgments' and in sectioning `Advanced package management' differ
> ./doc/guix-cookbook.zh_Hans.texi:1385: warning: node prev `' in 
> menu `Advanced package management' and in sectioning `??' differ
> ./doc/guix-cookbook.zh_Hans.texi:2483: warning: node next `Advanced package 
> management' in menu `' and in sectioning `' differ
> ./doc/guix-cookbook.zh_Hans.texi:2902: warning: node `' is up for `Guix 
> environment via direnv' in sectioning but not in menu
> ./doc/guix-cookbook.zh_Hans.texi:2892: node `' lacks menu item for `Guix 
> environment via direnv' despite being its Up target
> ./doc/guix-cookbook.zh_Hans.texi:3014: warning: node prev `Acknowledgments' 
> in menu `' and in sectioning `' differ
> make[2]: *** [Makefile:5627: doc/guix-cookbook.zh_Hans.info] Error 1
> make[2]: *** Waiting for unfinished jobs
> Use of uninitialized value in hash element at 
> /gnu/store/0n07srrsfkh6mpzq9m78p18674bci39r-texinfo-6.7/share/texinfo/Texinfo/Structuring.pm
>  line 639.
> ./doc/guix-cookbook.ko.texi:565: @node `??' previously defined
> ./doc/guix-cookbook.ko.texi:319: here is the previous definition as @node
> ./doc/guix-cookbook.ko.texi:781: @node `? ??' previously defined
> ./doc/guix-cookbook.ko.texi:333: here is the previous definition as @node
> ./doc/guix-cookbook.ko.texi:1332: @node `?? ??' previously defined
> ./doc/guix-cookbook.ko.texi:579: here is the previous definition as @node
> ./doc/guix-cookbook.ko.texi:1368: @node `??' previously defined
> ./doc/guix-cookbook.ko.texi:319: here is the previous definition as @node
> ./doc/guix-cookbook.ko.texi:1387: @node `? ??' previously defined
> ./doc/guix-cookbook.ko.texi:333: here is the previous definition as @node
> ./doc/guix-cookbook.ko.texi:2895: @node `?? ??' previously defined
> ./doc/guix-cookbook.ko.texi:579: here is the previous definition as @node
> ./doc/guix-cookbook.ko.texi:3048: @node `?? ??' previously defined
> ./doc/guix-cookbook.ko.texi:579: here is the previous definition as @node
> ./doc/guix-cookbook.ko.texi:319: warning: node next `??' in menu 
> `? ??' and in sectioning `' differ
> ./doc/guix-cookbook.ko.texi:333: warning: node `? ? ??' 
> is next for `? ??' in menu but not in sectioning
> ./doc/guix-cookbook.ko.texi:333: warning: node `??' is prev for 
> `? ??' in menu but not in sectioning
> ./doc/guix-cookbook.ko.texi:579: warning: node next `?? ??' in menu 
> `? ???' and in sectioning `@samp{GUIX_PACKAGE_PATH}' differ
> ./doc/guix-cookbook.ko.texi:579: warning: node `GNU ?? ?? ?' 
> is prev for `?? ??' in menu but not in sectioning
> ./doc/guix-cookbook.ko.texi:579: warning: node up `?? ??' in menu 
> `Top' and in sectioning `' differ
> ./doc/guix-cookbook.ko.texi:579: warning: for `?? ??', up in menu 
> `Top' and up `' don't match
> ./doc/guix-cookbook.ko.texi:1417: warning: node 

bug#49801: Guix time machine provenance/manifest reproducibility issue?

[Denis 'GNUtoo' Carikli]

On Thu, 2 Sep 2021 10:10:22 +0200
zimoun  wrote:

> Hi Denis,
> 
> Thanks for the investigation and the attempt.
> 
> Well, I miss if it works or not...
It doesn't work.

The issue was that if you build a tarball with guix pack, without guix
time-machine, you can't reproduce it with guix-time-machine.

Between the two tarballs, everything is the same but the provenance
file.

So here the idea is to make sure that the provenance file is the same
between tarballs made with and without guix time-machine.

Here I get a diff between tarballs made with and without guix
time-machine, with or without your patch, so the patch doesn't fix it
yet for guix master of yesterday.

Between when I reported the bug and the test I did yesterday, the HEAD
of guix master changed though.

Denis.


pgpPsadSi1YWS.pgp
Description: OpenPGP digital signature

bug#49801: Guix time machine provenance/manifest reproducibility issue?

[Denis 'GNUtoo' Carikli]

Hi again.

With and without this patch:
> diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
> index fb8ce50fa7..af1cf77f07 100644
> --- a/guix/scripts/pull.scm
> +++ b/guix/scripts/pull.scm
> @@ -739,7 +739,7 @@ Use '~/.config/guix/channels.scm' instead."))
>   (cons (match ref
>   (('commit . commit)
>(channel (inherit guix)
> -   (url url) (commit commit) (branch
> #f)))
> +   (url url) (commit commit)))
>   (('branch . branch)
>(channel (inherit guix)
> (url url) (commit #f) (branch
> branch)))

on top of 95c29d2746943733cbe8df7013854d45bb0df413 ("gnu: electron-cash:
Update to 4.2.5." which is today's master HEAD), I get the same diff
with and without time-machine.

I made and used this Makefile to build two hello tarball in both cases:
> COMMIT ?= 95c29d2746943733cbe8df7013854d45bb0df413
> 
> all: \
>   hello-guix-$(COMMIT).tar.xz \
>   hello-time-machine-$(COMMIT).tar.xz \
> 
> hello-guix-$(COMMIT).tar.xz:
>   install -m 644 \
>   `../pre-inst-env \
>   guix pack \
>   --compression=xz --save-provenance hello` \
>   $@
> 
> hello-time-machine-$(COMMIT).tar.xz:
>   install -m 644 \
>   `../pre-inst-env guix time-machine \
>   --branch=master \
>   --commit=$(COMMIT) \
>   -- \
>   pack --compression=xz --save-provenance hello` \
>   $@

And once the file named manifest is extracted from both tarballs I get
this diff (with and without your slightly modified patch):
> --- 
> ./hello-guix-95c29d2746943733cbe8df7013854d45bb0df413/gnu/store/lw9x5aimyqcq5iazj786fv7q5l3h0syk-profile/manifest
>  1970-01-01 01:00:01.0 +0100
> +++ 
> ./hello-time-machine-95c29d2746943733cbe8df7013854d45bb0df413/gnu/store/30pf6ppiqpjsjaaiw35kc5lp6dcixpf1-profile/manifest
>  1970-01-01 01:00:01.0 +0100
> @@ -12,4 +12,19 @@
>"/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10"
>(propagated-inputs ())
>(search-paths ())
> -  (properties)
> +  (properties
> +(provenance
> +  (repository
> +(version 0)
> +(url "https://git.savannah.gnu.org/git/guix.git;)
> +(branch #f)
> +(commit
> +  "95c29d2746943733cbe8df7013854d45bb0df413")
> +(name guix)
> +(introduction
> +  (channel-introduction
> +(version 0)
> +(commit
> +  "9edb3f66fd807b096b48283debdcddccfea34bad")
> +(signer
> +  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 
> 54FA"))

PS: In the diff at the top there is a slight difference with the patch
that you suggested: I only removed (branch #f) so I end up with one
more parenthesis at the end.

Denis.


pgpPU_mqcEWxR.pgp
Description: OpenPGP digital signature

bug#49913: python-networkx test failing

[Denis 'GNUtoo' Carikli]

On Sun, 8 Aug 2021 13:54:10 +0300
Efraim Flashner  wrote:

> On Sat, Aug 07, 2021 at 07:03:11PM +0200, Maxime Devos wrote:
> > Hi,
> > 
> > > > networkx/algorithms/shortest_paths/tests/test_weighted.py:29:
> > > > AssertionError === 1 failed, 3517 passed, 182 skipped
> > > > in 246.61s (0:04:06)  command "pytest" "-vv"
> > > > "--pyargs" "networkx" failed with status 1
> > > 
> > > I've the following setup:
> > > 
> > > Host distribution: Parabola i686 with an x86_64 kernel
> > > (linux-libre-64) Guix: Guix i686
> > 
> > I can reproduce on i686 (--system=i686-linux) but not x86_64.
> > The test failure appears to be determenistic but
> > architecture-dependent.
> > 
> 
> Can you `guix pull` and test it again? I just updated it to 2.6.2 and
> building with --system=i686-linux didn't show me any test errors.
I tried to build fdroidserver again after doing 'guix pull' and this
time it worked fine.

Thanks a lot.

Denis.


pgpTiVjl9HbUL.pgp
Description: OpenPGP digital signature

bug#49913: python-networkx test failing

[Denis 'GNUtoo' Carikli]

Hi, 

when trying to install fdroidserver, I have the following build failure
in the tests with python-networkx:
> building
> /gnu/store/64a09gnkl01k6vcwrn1cvv1v8nm88xhb-python-networkx-2.5.1.drv...
> 100% 'check'
> [###]builder
> for
> `/gnu/store/64a09gnkl01k6vcwrn1cvv1v8nm88xhb-python-networkx-2.5.1.drv'
> failed with exit code 1 build of
> /gnu/store/64a09gnkl01k6vcwrn1cvv1v8nm88xhb-python-networkx-2.5.1.drv
> failed View build log at
> '/var/log/guix/drvs/64/a09gnkl01k6vcwrn1cvv1v8nm88xhb-python-networkx-2.5.1.drv.bz2'.
[...]
> networkx/utils/tests/test_random_sequence.py::test_random_weighted_choice 
> PASSED [ 99%]
> networkx/utils/tests/test_rcm.py::test_reverse_cuthill_mckee PASSED  [ 
> 99%]
> networkx/utils/tests/test_rcm.py::test_rcm_alternate_heuristic PASSED[ 
> 99%]
> networkx/utils/tests/test_unionfind.py::test_unionfind PASSED[ 
> 99%]
> networkx/utils/tests/test_unionfind.py::test_subtree_union PASSED[ 
> 99%]
> networkx/utils/tests/test_unionfind.py::test_unionfind_weights PASSED[ 
> 99%]
> networkx/utils/tests/test_unionfind.py::test_empty_union PASSED  
> [100%]
> 
> === FAILURES 
> ===
>  TestWeightedPath.test_weight_functions 
> 
> 
> self = 
>  object at 0xb4a304c0>
> 
> def test_weight_functions(self):
> def heuristic(*z):
> return hash(z)
> 
> def getpath(pred, v, s):
> return [v] if v == s else getpath(pred, pred[v], s) + [v]
> 
> def goldberg_radzik(g, s, t, weight="weight"):
> pred, dist = nx.goldberg_radzik(g, s, weight=weight)
> dist = dist[t]
> return dist, getpath(pred, t, s)
> 
> def astar(g, s, t, weight="weight"):
> path = nx.astar_path(g, s, t, heuristic, weight=weight)
> dist = nx.astar_path_length(g, s, t, heuristic, weight=weight)
> return dist, path
> 
> def vlp(G, s, t, l, F, w):
> res = F(G, s, t, weight=w)
> validate_length_path(G, s, t, l, *res, weight=w)
> 
> G = self.cycle
> s = 6
> t = 4
> path = [6] + list(range(t + 1))
> 
> def weight(u, v, _):
> return 1 + v ** 2
> 
> length = sum(weight(u, v, None) for u, v in pairwise(path))
> vlp(G, s, t, length, nx.bidirectional_dijkstra, weight)
> vlp(G, s, t, length, nx.single_source_dijkstra, weight)
> vlp(G, s, t, length, nx.single_source_bellman_ford, weight)
> vlp(G, s, t, length, goldberg_radzik, weight)
> >   vlp(G, s, t, length, astar, weight)
> 
> networkx/algorithms/shortest_paths/tests/test_weighted.py:233: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> networkx/algorithms/shortest_paths/tests/test_weighted.py:218: in vlp
> validate_length_path(G, s, t, l, *res, weight=w)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> 
> G = , s = 6, t = 4
> soln_len = 35, length = 43, path = [6, 5, 4]
> weight = .weight at 
> 0xb4a2f538>
> 
> def validate_length_path(G, s, t, soln_len, length, path, 
> weight="weight"):
> >   assert soln_len == length
> E   assert 35 == 43
> E -35
> E +43
> 
> networkx/algorithms/shortest_paths/tests/test_weighted.py:29: AssertionError
> === 1 failed, 3517 passed, 182 skipped in 246.61s (0:04:06) 
> 
> command "pytest" "-vv" "--pyargs" "networkx" failed with status 1

I've the following setup:

Host distribution: Parabola i686 with an x86_64 kernel (linux-libre-64)
Guix: Guix i686

Do I need to give more information?

Denis.


pgp29O2ISiGpc.pgp
Description: OpenPGP digital signature

bug#49801: Guix time machine provenance/manifest reproducibility issue?

[Denis 'GNUtoo' Carikli]

Hi,

I've been trying to reproduce a tarball
(sz1lkq3ryr5iv6amy6f3d2pziks27g28-tarball-pack.tar.xz) that I generated
with guix pack on guix master the 28 January 2021.

To build it, in January, I used the following commands:
> guix pull
> guix pack \
> --compression=xz \
> --save-provenance \
> -RR \
> --symlink=/usr/local/bin/repo=bin/repo \
> --symlink=/usr/local/bin/repo-env.sh=etc/profile \
> git-repo le-certs nss-certs git python-certifi

That tarball is publicly available in the Replicant ftp server[1].

The extracted provenance file (named manifest) has the following
content:
> ;; This file was automatically generated and is for internal use only.
> ;; It cannot be passed to the '--manifest' option.
> 
> (manifest
>   (version 3)
>   (packages
> (("git-repo"
>   "2.4.1"
>   "out"
>   "/gnu/store/d4frkcdq15a7gyfjdggwg44ryi46fa2d-git-repo-2.4.1R"
>   (propagated-inputs ())
>   (search-paths ())
>   (properties
> (provenance
>   (repository
> (version 0)
> (url "https://git.savannah.gnu.org/git/guix.git;)
> (branch "master")
> (commit
>   "f9bd4621dd92a9415276706b476b9bd2973411fa")
> (introduction
>   (channel-introduction
> (version 0)
> (commit
>   "9edb3f66fd807b096b48283debdcddccfea34bad")
> (signer
>   "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A
> 54FA"))) ("le-certs"
>   "0"
>   "out"
>   "/gnu/store/x004p4hnyy0ickg2f5msvrpszhy9hzpl-le-certs-0R"
>   (propagated-inputs ())
>   (search-paths ())
>   (properties
> (provenance
>   (repository
> (version 0)
> (url "https://git.savannah.gnu.org/git/guix.git;)
> (branch "master")
> (commit
>   "f9bd4621dd92a9415276706b476b9bd2973411fa")
> (introduction
>   (channel-introduction
> (version 0)
> (commit
>   "9edb3f66fd807b096b48283debdcddccfea34bad")
> (signer
>   "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A
> 54FA"))) ("nss-certs"
>   "3.57"
>   "out"
>   "/gnu/store/shc8qpw1y2k7q668rx4gl6aff0wp1n6v-nss-certs-3.57R"
>   (propagated-inputs ())
>   (search-paths ())
>   (properties
> (provenance
>   (repository
> (version 0)
> (url "https://git.savannah.gnu.org/git/guix.git;)
> (branch "master")
> (commit
>   "f9bd4621dd92a9415276706b476b9bd2973411fa")
> (introduction
>   (channel-introduction
> (version 0)
> (commit
>   "9edb3f66fd807b096b48283debdcddccfea34bad")
> (signer
>   "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A
> 54FA"))) ("git"
>   "2.30.0"
>   "out"
>   "/gnu/store/378nlw54nxy991jcilnnbrxasnfvv9wl-git-2.30.0R"
>   (propagated-inputs ())
>   (search-paths
> (("GIT_SSL_CAINFO"
>   ("etc/ssl/certs/ca-certificates.crt")
>   #f
>   regular
>   #f)
>  ("GIT_EXEC_PATH"
>   ("libexec/git-core")
>   #f
>   directory
>   #f)))
>   (properties
> (provenance
>   (repository
> (version 0)
> (url "https://git.savannah.gnu.org/git/guix.git;)
> (branch "master")
> (commit
>   "f9bd4621dd92a9415276706b476b9bd2973411fa")
> (introduction
>   (channel-introduction
> (version 0)
> (commit
>   "9edb3f66fd807b096b48283debdcddccfea34bad")
> (signer
>   "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A
> 54FA"))) ("python-certifi"
>   "2020.11.8"
>   "out"
>   "/gnu/store/hmp6ab9kw1z3hjns9h1fm3afsq4g6j7x-python-certifi-2020.11.8R"
>   (propagated-inputs ())
>   (search-paths ())
>   (properties
> (provenance
>   (repository
> (version 0)
> (url "https://git.savannah.gnu.org/git/guix.git;)
> (branch "master")
> (commit
>   "f9bd4621dd92a9415276706b476b9bd2973411fa")
> (introduction
>   (channel-introduction
> (version 0)
> (commit
>   "9edb3f66fd807b096b48283debdcddccfea34bad")
> (signer
>   "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A
> 54FA"))


So I tried to reproduce it with the following command:
> guix time-machine \
>   --commit=f9bd4621dd92a9415276706b476b9bd2973411fa -- \
>   pack \
>   --compression=xz \
>   --save-provenance \
>   -RR \
>   

bug#45517: Failed boot on arm32 with u-boot due to missing requirements with the distro boot protocol

[Denis 'GNUtoo' Carikli]

On Wed, 30 Dec 2020 15:35:48 +0100
Mathieu Othacehe  wrote:
> The default image type creates an EFI partition which is not desirable
> here. You should try again running this instead:
> 
> --8<---cut here---start->8---
> guix system disk-image -t arm32-raw lime2.scm
> --8<---cut here---end--->8---
Thanks a lot, that works fine.

Sorry for the noise.

Denis.


pgpC_Ykug6oYl.pgp
Description: OpenPGP digital signature

bug#45519: MLO failed to load u-boot.img on beaglebone black(AM335x)

[Denis 'GNUtoo' Carikli]

Hi,

I've generated an image for the beaglebone black with this
(beaglebone-black.scm) file:
> ;; Based on Guix's beaglebone-black.tmpl
> (use-modules (gnu) (gnu bootloader u-boot))
> (use-service-modules networking ssh)
> (use-package-modules bootloaders screen ssh)
> (operating-system
>   (host-name "beaglebone_black")
>   (timezone "Europe/Paris")
>   (locale "en_US.utf8")
>   ;; We use a microSD
>   (bootloader (bootloader-configuration
>(bootloader u-boot-beaglebone-black-bootloader)
>(target "/dev/mmcblk0")))
>   (kernel-arguments (append '("console=ttyO0,115200"
> "ignore_loglevel")))
>   ;; This module is required to mount the SD card.
>   (initrd-modules (cons "omap_hsmmc" %base-initrd-modules))
>   (file-systems (cons (file-system
> (device (file-system-label "my-root"))
> (mount-point "/")
> (type "ext4"))
>   %base-file-systems))
>   (packages %base-packages)
>   (services (append (list
>  (agetty-service
>   (agetty-configuration
>(extra-options '("-L"))
>(baud-rate "115200")
>(term "vt100")
>(tty "ttyO0"
> %base-services)))

I then built it with:
> cp `guix system disk-image --target=arm-linux-gnueabihf \
> beaglebone-black.scm` guix.img

And at boot, it seems that MLO can't load u-boot.img:
> U-Boot SPL 2020.10 (Jan 01 1970 - 00:00:01 +)
> Trying to boot from MMC1
>
> U-Boot SPL 2020.10 (Jan 01 1970 - 00:00:01 +)
> Trying to boot from MMC1
> 
> U-Boot SPL 2020.10 (Jan 01 1970 - 00:00:01 +)
> Trying to boot from MMC1
I don't know why there is a loop here. I didn't check if the watchdog
was disabled in MLO or not.

In gnu/bootloader/u-boot.scm in guix source code, we have:
> (define install-beaglebone-black-u-boot
>   ;; 
> http://wiki.beyondlogic.org/index.php?title=BeagleBoneBlack_Upgrading_uBoot
>   ;; This first stage bootloader called MLO (U-Boot SPL) is expected at
>   ;; 0x2 by BBB ROM code. The second stage bootloader will be loaded by
>   ;; the MLO and is expected at 0x6.  Write both first stage ("MLO") and
>   ;; second stage ("u-boot.img") images, read in BOOTLOADER directory, to the
>   ;; specified DEVICE.
>   #~(lambda (bootloader root-index image)
>   (let ((mlo (string-append bootloader "/libexec/MLO"))
> (u-boot (string-append bootloader "/libexec/u-boot.img")))
> (write-file-on-device mlo (* 256 512)
>   image (* 256 512))
> (write-file-on-device u-boot (* 1024 512)
>   image (* 768 512)

0x6 is at 384k. It's defined by
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR which defaults to 0x300.

Here u-boot.img[1] is 600K, so if we add 600k and 384k we're still
within the 1M alignment space before the first partition:
> Device Boot Start End Sectors  Size Id Type
> guix.img12048   83967   81920   40M ef EFI (FAT-12/16/32)
> guix.img2   83968 3287855 3203888  1.5G 83 Linux

So we can rule out space issues.

Another possibility is that it tries to boot on the filesystem instead
of block offset. I've already tried to upstream a patch for that in
u-boot (that I attached here) but it was refused because it had some
side effects:

On Mon, 20 Jan 2020 13:17:01 +0530
Lokesh Vutla wrote:
> > With this change, and CONFIG_SPL_RAW_IMAGE_SUPPORT disabled,
> > raw MMC boot will be tried first, and if it fails, it FS will
> > be tried.  
> This means that if FS boot is required then SPL_RAW_IMAGE_SUPPORT
> should be disabled. So with this patch applied, the default
> omap3_defconfig will fail to boot with FS mode. It is difficult to
> support this unless ROM passes some information on the bootmode.

We are using this patch in Parabola. I'll try to test it too in Guix
though I can often take quite some time to manage to test things with
Guix when patching Guix itself.

References:
---
[1]/gnu/store/83rpk8q9bww0phl6z6zgpf06qhqs8cw6-u-boot-am335x-boneblack-2020.10/libexec/u-boot.img

Denis.
From a49275a3cc03970939585610ebcf3b3d7e547037 Mon Sep 17 00:00:00 2001
From: Denis 'GNUtoo' Carikli 
Date: Sat, 9 Nov 2019 18:53:40 +0100
Subject: [PATCH] omap34xx: SPL: enable MMC raw boot with u-boot.img

The following commit enabled raw SPL booting:
  22d90d560a omap3: Use raw SPL by default for mmc1
but it was reverted by the following commit:
  821c89d38c Revert "omap3: Use raw S

bug#45519: MLO failed to load u-boot.img on beaglebone black(AM335x)

[Denis 'GNUtoo' Carikli]

On Tue, 29 Dec 2020 05:33:55 +0100
Denis 'GNUtoo' Carikli  wrote:

In addition I forgot that the patch I talked about was for omap3 and
not for AM335x.

Denis.


pgpf5IWLeeep6.pgp
Description: OpenPGP digital signature

bug#45517: Failed boot on arm32 with u-boot due to missing requirements with the distro boot protocol

[Denis 'GNUtoo' Carikli]

Hi,

I've generated an image for the Lime2 with this (lime2.scm) file:
> ;; Based on Guix's beaglebone-black.tmpl
> (use-modules (gnu) (gnu bootloader u-boot))
> (use-package-modules bootloaders)
> (operating-system
>   (host-name "lime2")
>   (timezone "Europe/Paris")
>   (locale "en_US.utf8")
>   ;; We use a microSD
>   (bootloader (bootloader-configuration
>(bootloader u-boot-a20-olinuxino-lime2-bootloader)
>(target "/dev/mmcblk0")))
>   (kernel-arguments '("console=ttyS0,115200" "ignore_loglevel"))
>   ;; This module is required to mount the SD card.
>   (initrd-modules (cons "sunxi-mmc" %base-initrd-modules))
>   (file-systems (cons (file-system
> (device (file-system-label "my-root"))
> (mount-point "/")
> (needed-for-boot? #t)
> (type "ext4"))
>   %base-file-systems))
>   (packages %base-packages)
>   (services (append (list
>  (agetty-service
>   (agetty-configuration
>(extra-options '("-L"))
>(baud-rate "115200")
>(term "xterm-256color")
>(tty "ttyS0"
> %base-services)))

I then built it with:
> cp `guix system disk-image --target=arm-linux-gnueabihf lime2.scm` \
> guix.img

However when booting the image, u-boot doesn't find
/boot/extlinux/extlinux.conf.

However running the following command in u-boot makes the board boot:
> sysboot mmc 0:2 any $scriptaddr /boot/extlinux/extlinux.conf

When we look at the resulting image with fdisk -l we have:
> Device Boot Start End Sectors  Size Id Type
> guix.img12048   83967   81920   40M ef EFI (FAT-12/16/32)
> guix.img2   83968 3301783 3217816  1.5G 83 Linux

The second partition (which has /boot/extlinux/extlinux.conf) doesn't
have the boot flag.

Adding the boot flag with the following command results in a booting
image:
> sfdisk guix.img -A 2

This is because the distro boot protocol (documented in
doc/README.distro in u-boot source code[1]) expects the partition that
holds the extlinux.conf config file to be "explicitly marked bootable".
else "U-Boot falls back to searching the first valid partition of a
disk for boot configuration files."

So we either need to remove the first partition or to mark the second
partition as bootable or both.

I've tried looking in the partitioning code to understand how flags are
set but I'm a complete newbie in scheme so I failed. Being able to set
the bootable flag could probably help in some situations where a first
partition has to be used for some reasons.

In addition, the first partition it only contains the
/EFI/BOOT/BOOTIA32.EFI file which is of the following type:
> PE32 executable (EFI application) Intel 80386 (stripped to external
> PDB), for MS Windows
So it could also be removed and/or replaced with ARM code.

References:
---
[1]https://gitlab.denx.de/u-boot/u-boot/-/raw/master/doc/README.distro

Denis.


pgp29tQzEnK7K.pgp
Description: OpenPGP digital signature

bug#45519: MLO failed to load u-boot.img on beaglebone black(AM335x)

[Denis 'GNUtoo' Carikli]

On Tue, 29 Dec 2020 04:47:25 +0100
Denis 'GNUtoo' Carikli  wrote:
> > "/libexec/MLO")) (u-boot (string-append bootloader
> > "/libexec/u-boot.img"))) (write-file-on-device mlo (* 256 512)
> >   image (* 256 512))
> > (write-file-on-device u-boot (* 1024 512)
> >   image (* 768 512)
Ah my bad, theses are in bytes (write-file-on-device uses seek which
looks like lseek). 

So if u-boot.img is 600k, that's over the 512k.

MLO[1] is about 108k (108740 bytes), so that's under 128KiB.

So we could move u-boot.img at 256KiB instead of 384KiB.

This way we'll still have some margin for MLO but and increase the
space for u-boot.img to 768k.

References:
---
[1]/gnu/store/83rpk8q9bww0phl6z6zgpf06qhqs8cw6-u-boot-am335x-boneblack-2020.10/libexec/MLO

Denis.


pgpDzuj21JyyO.pgp
Description: OpenPGP digital signature

bug#42964: Potential FSDG issue with debootstrap scripts

[Denis 'GNUtoo' Carikli]

Hi,

I found a potential issue with the debootstrap package and the Guix
blog.

The Free System Distribution Guidelines states that:
> A free system distribution must not steer users towards obtaining any
> nonfree information for practical use, or encourage them to do so.
> The system should have no repositories for nonfree software and no
> specific recipes for installation of particular nonfree programs. Nor
> should the distribution refer to third-party repositories that are
> not committed to only including free software; even if they only have
> free software today, that may not be true tomorrow. Programs in the
> system should not suggest installing nonfree plugins, documentation,
> and so on.

However after instalation, the debootstrap package contains scripts for
installing many distributions, and most of them are either not FSDG
compliant or have nonfree software in them.

I assume that the Ubuntu repositories are "third-party repositories that
are not committed to only including free software", and they are used
in the debootstrap scripts to install Ubuntu.

After installation I got the following scripts in
~/.guix_profile/share/debootstrap/scripts/:
- aequorea
- amber
- artful
- ascii
- bartholomea
- beowulf
- bionic
- bookworm
- breezy
- bullseye
- buster
- ceres
- chromodoris
- cosmic
- dapper
- dasyatis
- debian-common
- disco
- edgy
- eoan
- etch
- etch-m68k
- feisty
- focal
- gutsy
- hardy
- hoary
- hoary.buildd
- intrepid
- jaunty
- jessie
- jessie-kfreebsd
- kali
- kali-dev
- kali-last-snapshot
- kali-rolling
- karmic
- lenny
- lucid
- maverick
- natty
- oldoldstable
- oldstable
- oneiric
- potato
- precise
- quantal
- raring
- sarge
- sarge.buildd
- sarge.fakechroot
- saucy
- sid
- squeeze
- stable
- stretch
- testing
- trusty
- unstable
- utopic
- vivid
- warty
- warty.buildd
- wheezy
- wily
- woody
- woody.buildd
- xenial
- yakkety
- zesty

The scripts are named after distribution codenames. So here you can see
some ubuntu code names like trusty, xenial, etc (ubuntu contains nonfree
software), or some debian code names like stretch.

Not all scripts are problematic, as amber is the codename of the
main PureOS repository[2].

To fix that, Parabola patches debootstrap to remove the problematic
scripts[3] and also adds support for many FSDG distributions along the
way. It also has a modified manual[4] with examples for Trisquel
instead of Debian.

Something similar could probably be done in debian.scm[5].

In addition the Guix blog post about "Running a Ganeti cluster on
Guix"[6] should probably be reviewed as it contains code to install
Debian buster.

As I understand, Debian may not contain nonfree software but it is not
FSDG compliant, so it could be a good idea to use an FSDG compliant
distributions instead to avoid any issues. In addition if the buster
script is removed, then the code on the blog post won't work anymore.

References:
---
[1]https://www.gnu.org/distros/free-system-distribution-guidelines.html
[2]https://libreplanet.org/wiki/Group:Hardware/FSDG_distributions/PureOS
[3]https://git.parabola.nu/abslibre.git/tree/libre/debootstrap/PKGBUILD#n50
[4]https://git.parabola.nu/abslibre.git/tree/libre/debootstrap/debootstrap.8
[5]https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/debian.scm#n121
[6]https://guix.gnu.org/en/blog/2020/running-a-ganeti-cluster-on-guix/

Denis.


pgpWes7tM7pFC.pgp
Description: OpenPGP digital signature

bug#40626: Poor performance on low-end ARMv7 devices

[Denis 'GNUtoo' Carikli]

On Mon, 13 Jul 2020 15:34:15 +0200
Ludovic Courtès  wrote:

> Hi,
> 
> Denis 'GNUtoo' Carikli  skribis:
> 
> > Many ARM Single Board Computers are commonly used with microSD for
> > storage, and some microSD cards are extremely slow (and sometimes
> > unreliable when they are old).
> >
> > Could the performance issues be related to storage device I/Os?
> 
> It could be the reason; it’s definitely the case on the board I was
> using here.
> 
> Still I wonder what could be done on our side to improve on this.
I guessed that was the intent.

A way to deal with that could be to validate if it's actually the case,
for instance by installing an SSD, and doing performance comparison
with the time command.

Then if it helps a lot, we probably need to trace the filesystem access
and optimize it somehow. Maybe that can be done with BPF or gprof, but
I never looked into obtimizing I/O performances, so I'm unsure if
that's the right approach. Guile may have profiling tools too.

As for benchmarking the CPU, I've patched phoronix-test-suite in a very
quick and dirty way in Parabola, so we could at least have some
benchmarks. For now we only have "compilation" benchmarks with source
code that should be FSDG compliant.

With it I've found that the compilation performances can vary a lot
between different ARM and x86 boards:
- An I.MX6 Quad with 2G of RAM is about 4.5x faster than the AM335x of a
  Beaglebone Green with 512M of RAM.
- A Lime2 A20 is about 1.7x faster than the Beaglebone Green and 2.5x
  slower than the board with the I.MX6 Quad.
- My smartphone (Galaxy SIII GT-I9300) is about 2x faster than my server
  (PC Engines APU1) for compilation.

Denis.


pgpZXLpncBaQd.pgp
Description: OpenPGP digital signature

bug#40626: Poor performance on low-end ARMv7 devices

[Denis 'GNUtoo' Carikli]

Hi,

Many ARM Single Board Computers are commonly used with microSD for
storage, and some microSD cards are extremely slow (and sometimes
unreliable when they are old).

Could the performance issues be related to storage device I/Os?

Denis.


pgpevYyzP4lp9.pgp
Description: OpenPGP digital signature

bug#42161: Confusing '' error message

[Denis 'GNUtoo' Carikli]

On Thu, 02 Jul 2020 09:48:26 +0200
Ludovic Courtès  wrote:

> Hello,
Hi,

> If you’re having troubles building your system, I’d try building with
> ‘-v3’ (verbose mode) for example, or ‘--on-error=debug’ if the problem
> is in your ‘system.scm’ file.

Here's with -v3
> # guix system -v3 --no-bootloader init system.scm /srv/distros/guix/
> guile: warning: failed to install locale
> Backtrace:
>1 (primitive-load "/root/.config/guix/current/bin/guix")
> In guix/ui.scm:
>   1949:12  0 (run-guix-command _ . _)
> 
> guix/ui.scm:1949:12: In procedure run-guix-command:
> In procedure struct-vtable: Wrong type argument in position 1
> (expecting struct): #f

And with -v3 and --on-error=debug:
> # guix system  --on-error=debug -v3 --no-bootloader init system.scm
> /srv/distros/guix/ guile: warning: failed to install locale
> Backtrace:
>1 (primitive-load "/root/.config/guix/current/bin/guix")
> In guix/ui.scm:
>   1949:12  0 (run-guix-command _ . _)
> 
> guix/ui.scm:1949:12: In procedure run-guix-command:
> In procedure struct-vtable: Wrong type argument in position 1
> (expecting struct): #f

In both cases it doesn't point to my system.scm, so I'm trying to start
suspecting that the issue is somewhere else. Though you need to keep in
mind that I just read the Scheme crashcourse from the GuiX cookbook
days ago, so I'm really far from being fluent in Scheme.

> > so I'm probably doing something wrong here as I'm probably not
> > supposed to abuse guix system init to create chroots for lxc.
> 
> I’m not familiar with lxc, but it looks like it should work.
In a nutshell I'm trying to install GuiX:
- without a bootloader
- in a directory that isn't the root of a filesystem

I've tried also on /mnt which is backed by a partition:
> /dev/sdb4 on /mnt type ext4 (rw,relatime)

And again I've the same error:
> guix system  --on-error=debug -v3 --no-bootloader init system.scm
> /mnt/ guile: warning: failed to install locale
> Backtrace:
>1 (primitive-load "/root/.config/guix/current/bin/guix")
> In guix/ui.scm:
>   1949:12  0 (run-guix-command _ . _)
> 
> guix/ui.scm:1949:12: In procedure run-guix-command:
> In procedure struct-vtable: Wrong type argument in position 1
> (expecting struct): #f

Is that part of my system.scm really correct:
> (file-systems %base-file-systems)

I hope that I'm not polluting bugreports for issues that I'm responsible
of, but I don't have enough knowledge to know that in advance, and I
was advised to bugreport on #guix IRC channel.

Denis.


pgpqtjh9851hN.pgp
Description: OpenPGP digital signature

bug#42161: Confusing '' error message

[Denis 'GNUtoo' Carikli]

Hi,

When doing guix system system.scm /path/to/empty/directory, I have the
following error message:

> # guix system --verbosity=99 --debug=99 --no-bootloader  init
> system.scm /srv/distros/guix/ guile: warning: failed to install locale
> acquiring global GC lock `/var/guix/gc.lock'
> acquiring read lock on `/var/guix/temproots/14408'
> acquiring write lock on `/var/guix/temproots/14408'
[...]
> acquiring write lock on `/var/guix/temproots/14408'
> downgrading to read lock on `/var/guix/temproots/14408'
> Backtrace:
>1 (primitive-load "/root/.config/guix/current/bin/guix")
> In guix/ui.scm:
>   1949:12  0 (run-guix-command _ . _)
> 
> guix/ui.scm:1949:12: In procedure run-guix-command:
> In procedure struct-vtable: Wrong type argument in position 1
> (expecting struct): #f

so I'm probably doing something wrong here as I'm probably not supposed
to abuse guix system init to create chroots for lxc.

However the issue is that there is no clear error message nor backtrace
telling me what exactly is wrong here. I don't even have a line in my
file that tells me what line is wrong.

I've attached the system.scm used for reference.

Denis.
(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules irc screen ssh tor)

(operating-system
 (host-name "test")
 (timezone "Europe/Paris")
 (locale "en_US.utf8")

 (bootloader (bootloader-configuration
	  (bootloader grub-bootloader)
	  (target "/dev/sdX")))
 (file-systems %base-file-systems)

 (users (cons (user-account
	   (name "irssi")
	   (group "users")
	   (home-directory "/home/irssi"))
	  %base-user-accounts))

 (packages (cons* irssi openssh screen tor %base-packages ))
 (services (cons* (service dhcp-client-service-type)
  (service openssh-service-type
   (openssh-configuration
			(port-number 222)
			(permit-root-login #t)
			; No passwords logins
			(password-authentication? #f)
			(challenge-response-authentication? #f)
			(use-pam? #f)
			)
			   )
; (service tor-service)
; (service tor-hidden-service ((222 "127.0.0.1:222")) )
		  %base-services)))


pgpz4nuKw3zMl.pgp
Description: OpenPGP digital signature