bug#66647: Installation of RPMs produced by ‘guix pack’ is super slow

[Simon Tournier]

Hi,

On Sun, 22 Oct 2023 at 21:35, Maxim Cournoyer  wrote:

> --8<---cut here---start->8---

[...]

> [user@fedora Downloads]$ sudo time rpm -i 
> 7m01b0308z5y2pmyn8ywzdj914dxawsl-gmsh-rpm-pack.rpm
> 17.26user 10.19system 0:42.31elapsed 64%CPU (0avgtext+0avgdata 
> 24468maxresident)k
> 1481136inputs+2177344outputs (19major+6242minor)pagefaults 0swaps
>
> [user@fedora Downloads]$ rpm --version
> RPM version 4.18.0
> --8<---cut here---end--->8---

These days I am doing some experiments with CentOS7 (rpm 4.11.8), so I
have a virtualbox VM around.  Attached the view I get using the pack
generated with,

guix pack -f rpm -S /opt/bin=bin -R gmsh

then copied with ’scp’.  Well, I do not have GUI but gmsh seems working.

For me, ’rpm -i’ needs less than 10 seconds.  It installs 88 items if I
read correctly.

Hope that helps,
simon

bug#65225: [bug#66640] [PATCH 0/2] Build profile hooks for the right system

[Simon Tournier]

Hi Ludo,

A naive question about the default value.


On Thu, 19 Oct 2023 at 16:48, Ludovic Courtès  wrote:

>   packages: Add ‘system’ parameter for ‘set-guile-for-build’.

The change reads,

--8<---cut here---start->8---
+(define* (set-guile-for-build guile #:optional system)
[...]
+(let ((guile (package-derivation store guile
+ (or system (%current-system)
--8<---cut here---end--->8---

>   profiles: Hooks honor the #:system parameter of ‘profile-derivation’.

The change reads for all hooks,

--8<---cut here---start->8---
+  (define* (efi-bootloader-profile-hook manifest #:optional system)
[...]
 (gexp->derivation "efi-bootloader-profile"
   build
+  #:system system
--8<---cut here---end--->8---

Do I understand correctly when I consider that
’(efi-bootloader-profile-hook manifest)’ pass #false as ’system’ and
then it is ’set-guile-for-build’ that sets ’(%current-system)’?

Somehow, my question is about the readability of default values.

Why not,

#:system (or system (%current-system))

for all the hooks?


Cheers,
simon

bug#65720: [PATCH] git: Shell out to ‘git gc’ when necessary.

[Simon Tournier]

Hi Ludo,

On Fri, 20 Oct 2023 at 18:15, Ludovic Courtès  wrote:

> * guix/git.scm (packs-in-git-repository, maybe-run-git-gc): New
> procedures.
> (update-cached-checkout): Use it.
> ---
>  guix/git.scm | 39 ---
>  1 file changed, 36 insertions(+), 3 deletions(-)

LGTM.  Just two colors for the bikeshed. :-)


> +  (when (> (packs-in-git-repository directory) 25)

Why 25?  And not 10 or 50 or 100?


>  (define* (update-cached-checkout url
>   #:key
>   (ref '())
> @@ -515,6 +545,9 @@ (define* (update-cached-checkout url
> seconds seconds
> nanoseconds nanoseconds
>  
> +   ;; Run 'git gc' if needed.
> +   (maybe-run-git-gc cache-directory)

Why not trigger it by “guix gc”?

Well, I expect “guix gc” to take some time and I choose when.  However,
I want “guix pull” or “guix time-machine” to be as fast as possible and
here some extra time is added, and I cannot control exactly when.

Cheers,
simon

bug#65225: ‘guix shell --system=ALIEN’ builds for both systems

[Simon Tournier]

Hi Maxim,

On Fri, 20 Oct 2023 at 18:46, Maxim Cournoyer  wrote:

> I see the cover letter, but not the patches :-).  Where did they go?

They are in #66640 [1].  The cover letter had been CC:
65...@debbugs.gnu.org, I guess.

1: https://issues.guix.gnu.org/issue/66640

Cheers,
simon

bug#65225: ‘guix shell --system=ALIEN’ builds for both systems

[Maxim Cournoyer]

Hi Simon,

Simon Tournier  writes:

> Hi Maxim,
>
> On Fri, 20 Oct 2023 at 18:46, Maxim Cournoyer  
> wrote:
>
>> I see the cover letter, but not the patches :-).  Where did they go?
>
> They are in #66640 [1].  The cover letter had been CC:
> 65...@debbugs.gnu.org, I guess.

Thanks!

-- 
Maxim

bug#66647: Installation of RPMs produced by ‘guix pack’ is super slow

[Maxim Cournoyer]

tags 66647 + moreinfo unreproducible
thanks

Hi,

Simon Tournier  writes:

> Hi,
>
> On Sun, 22 Oct 2023 at 21:35, Maxim Cournoyer  
> wrote:
>
>> --8<---cut here---start->8---
>
> [...]
>
>> [user@fedora Downloads]$ sudo time rpm -i 
>> 7m01b0308z5y2pmyn8ywzdj914dxawsl-gmsh-rpm-pack.rpm
>> 17.26user 10.19system 0:42.31elapsed 64%CPU (0avgtext+0avgdata 
>> 24468maxresident)k
>> 1481136inputs+2177344outputs (19major+6242minor)pagefaults 0swaps
>>
>> [user@fedora Downloads]$ rpm --version
>> RPM version 4.18.0
>> --8<---cut here---end--->8---
>
> These days I am doing some experiments with CentOS7 (rpm 4.11.8), so I
> have a virtualbox VM around.  Attached the view I get using the pack
> generated with,
>
> guix pack -f rpm -S /opt/bin=bin -R gmsh
>
> then copied with ’scp’.  Well, I do not have GUI but gmsh seems working.
>
> For me, ’rpm -i’ needs less than 10 seconds.  It installs 88 items if I
> read correctly.

Yeah, a ~600 MiB closure is by no means specially large, should it
shouldn't take 45 minutes unless the IO in the VM is pathologically
slow, or if the old RPM version was struggling with something in our
custom-generated RPMs.  You example shows this is not the case, so I'll
close this with 'moreinfo' and 'unreproducible' tags.

Ludo: feel free to reopen if you can gather more details that would
point at our RPMs being faulty.

-- 
Thanks,
Maxim

bug#66703: Broken link to Debbugs User Guide

[Greg Hogan]

The page 
https://guix.gnu.org/devel/manual/en/html_node/Debbugs-User-Interfaces.html
has a broken link "Debbugs User Guide" to the page
https://guix.gnu.org/devel/manual/en/debbugs-ug/index.html#Top.

bug#66705: ‘guix shell -CW’ provides a Guix command without extra channels

[Ludovic Courtès]

‘guix shell -CW’ dismisses extra channels available in the original
Guix, as illustrated by this example:

--8<---cut here---start->8---
$ guix time-machine -C <(echo '(cons (channel (name (quote guix-hpc)) (url 
"https://gitlab.inria.fr/guix-hpc/guix-hpc.git";)) %default-channels)') -- shell 
-CW coreutils -- guix describe
  guix cbd20d6
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: cbd20d627497053871db863970c07d93c7081786

$ guix time-machine -C <(echo '(cons (channel (name (quote guix-hpc)) (url 
"https://gitlab.inria.fr/guix-hpc/guix-hpc.git";)) %default-channels)') -- 
describe
  guix cbd20d6
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: cbd20d627497053871db863970c07d93c7081786
  guix-hpc 887d76a
repository URL: https://gitlab.inria.fr/guix-hpc/guix-hpc.git
branch: master
commit: 887d76a8e1d0f35d615c613b28b9b871f39a997e
--8<---cut here---end--->8---

This is due to the fact that ‘-W’ (‘--nesting’) is implemented by adding
the outer ‘guix’ to the container’s profile, without also adding its
companion profile entries (those that provide channels).

Ludo’.

bug#66610: Acknowledgement (potrace, po4a; guix bug, complete console output)

[Olav Smorholm]

On Sat, Oct 21, 2023 at 08:52:13PM +0200, Olav Smorholm wrote:
>

And call it, or view is it as you may; no trivial task to determine if
the guix binary bug and crash was useful or not.

But in the process, while for other things after; starting to study
dmesg. Bluez and related things that awaken bluetooth kernel subsystems
is less of an aesthetic problem.

I react somewhat on PF_ALG especially, weird segfault that calls itself
xsltproc, and that there even exist segfaults and protection faults as
if checking for a kernel that is newer than minix era is
necessary. As false positives and negatives for intent to hide even the
oldest and most deprecated "hello world" crud.

bug#66705: ‘guix shell -CW’ provides a Guix command without extra channels

[Ludovic Courtès]

Ludovic Courtès  skribis:

> This is due to the fact that ‘-W’ (‘--nesting’) is implemented by adding
> the outer ‘guix’ to the container’s profile, without also adding its
> companion profile entries (those that provide channels).

Actually, the original profile, which contains ‘guix’ and its channels,
*is* available in the environment:

--8<---cut here---start->8---
$ guix time-machine -C <(echo '(cons (channel (name (quote guix-hpc)) (url 
"https://gitlab.inria.fr/guix-hpc/guix-hpc.git";)) %default-channels)') -- shell 
-CW coreutils 
[env]$ readlink -f $(type -P guix)
/gnu/store/42731vcvzl6nrwa584mziwhpvp4xs72r-guix-command
[env]$ type -P guix
/gnu/store/ca142m4lm0grxmsjqrcqpfl5qb5i1rka-profile/bin/guix
[env]$ readlink $(type -P guix)
/gnu/store/j5g09kjd7pv1b6919vbsnjs160xfw9md-profile/bin/guix
[env]$ /gnu/store/j5g09kjd7pv1b6919vbsnjs160xfw9md-profile/bin/guix describe
  guix cbd20d6
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 
]8;;https://git.savannah.gnu.org/cgit/guix.git/commit/?id=cbd20d627497053871db863970c07d93c7081786\cbd20d627497053871db863970c07d93c7081786]8;;\
  guix-hpc 887d76a
repository URL: https://gitlab.inria.fr/guix-hpc/guix-hpc.git
branch: master
commit: 
]8;;https://gitlab.inria.fr/guix-hpc/guix-hpc/commit/887d76a8e1d0f35d615c613b28b9b871f39a997e\887d76a8e1d0f35d615c613b28b9b871f39a997e]8;;\
--8<---cut here---end--->8---

The problem is the extra profile layer that confuses
‘current-channel-entries’ in (guix describe).

Ludo’.

bug#66610: Acknowledgement (potrace, po4a; guix bug, complete console output)

[Olav Smorholm]

On Mon, Oct 23, 2023 at 06:48:26PM +0200, Olav Smorholm wrote:
> On Sat, Oct 21, 2023 at 08:52:13PM +0200, Olav Smorholm wrote:
> >
> 
> And call it, or view is it as you may; no trivial task to determine if
> the guix binary bug and crash was useful or not.
> 
> But in the process, while for other things after; starting to study
> dmesg. Bluez and related things that awaken bluetooth kernel subsystems
> is less of an aesthetic problem.
> 
> I react somewhat on PF_ALG especially, weird segfault that calls itself
> xsltproc, and that there even exist segfaults and protection faults as
> if checking for a kernel that is newer than minix era is
> necessary. As false positives and negatives for intent to hide even the
> oldest and most deprecated "hello world" crud.

I'm sure interesting talks can be had:

[73428.629504] ptrace attach of 
"/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
--filter-group=touchpad --xml-output=junit-touchpad-XX.xml"[417] was 
attempted by 
"/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
--filter-group=touchpad --xml-output=junit-touchpad-XX.xml"[419]
[73428.640092] ptrace attach of 
"/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
--filter-group=touchpad-tap --xml-output=junit-touchpad-tap-XX.xml"[420] 
was attempted by 
"/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
--filter-group=touchpad-tap --xml-output=junit-touchpad-tap-XX.xml"[422]
[75861.720983] traps: bonobo-activati[4394] trap int3 ip:77bf39cf 
sp:7fffbd80 error:0 in libglib-2.0.so.0.7200.3[77bb7000+88000]
[77216.387681] Bluetooth: Core ver 2.22
[77216.387730] NET: Registered PF_BLUETOOTH protocol family
[77216.387732] Bluetooth: HCI device and connection manager initialized
[77216.387739] Bluetooth: HCI socket layer initialized
[77216.387742] Bluetooth: L2CAP socket layer initialized
[77216.387748] Bluetooth: SCO socket layer initialized
[77917.396492] python[11571]: segfault at 0 ip 775198c0 sp 
7fffb2c8 error 4 in _testcapi.so[77519000+6000] likely on CPU 10 
(core 4, socket 0)
[77917.396513] Code: 00 48 83 00 01 c3 0f 1f 40 00 48 89 d0 48 85 d2 74 08 48 
83 00 01 c3 0f 1f 00 48 8b 05 11 a7 00 00 48 83 00 01 c3 0f 1f 40 00 <8b> 04 25 
00 00 00 00 0f 0b 0f 1f 80 00 00 00 00 48 83 ec 08 48 8b
[77971.483788] python[19206]: segfault at 0 ip 775198c0 sp 
7fffb2c8 error 4 in _testcapi.so[77519000+6000] likely on CPU 10 
(core 4, socket 0)

bug#66027: Add a feature to automatically close specified bug reports upon committing.

[Simon Tournier]

Hi Maxim,

If I read correctly, this series had been merged with:

fb3707762d * etc: teams: Parse 'From' commit more leniently.
f44fa21c3e * gnu: patman: Apply patch for new Change-Id setting.
8005e09b26 * build: Add a commit-msg hook that embeds Change-Id in commit 
messages.

Right?

Mark the submission as done?  Or maybe is it a way for testing the
feature?  ;-)

Cheers,
simon

bug#65665: package-mapping with #:deep? #t doesn't get all the implicit inputs

[Simon Tournier]

Hi,

On Sat, 21 Oct 2023 at 17:22, Ulf Herrman  wrote:

>> I don’t know, should we start by having a proper bug report for this and
>> study how this happen?

[...]

>> Again I’m sorry if I’m slow to understand, but I’d like to make sure we
>> have a good understanding of the problem before we start discussing
>> solutions.
>
> Okay, I suppose I should have given a concrete example of the behavior.
> The qgit example can fill that role:
>
> $ cat $(./pre-inst-env guix build qgit -n --derivations --no-grafts 
> --with-latest=qtbase)

If I might, Guix revision a25a492f2b, my understanding is,

$ ./pre-inst-env guix build qgit -n --with-latest=qtbase
/gnu/store/gx5d03as0k1w6jv0pssi6j69n8glf6w5-qgit-2.10.drv
/gnu/store/h02aizdjy4p10n4gmcy0y35x14lmjx3n-qtbase-6.6.0.drv

Then the builder of the derivation
/gnu/store/gx5d03as0k1w6jv0pssi6j69n8glf6w5-qgit-2.10.drv reads,

--8<---cut here---start->8---
(begin
  (use-modules
   (guix build qt-build-system)
   (guix build utils))
  (qt-build #:source 
"/gnu/store/a57n7wy8mdi7l52pr4zg07132blgj5xp-qgit-2.10-checkout" #:system 
"x86_64-linux" #:outputs
(list
 (cons "out"
   ((@
 (guile)
 getenv)
"out")))
#:inputs
(quote
 (("source" . 
"/gnu/store/a57n7wy8mdi7l52pr4zg07132blgj5xp-qgit-2.10-checkout")
  ("cmake" . 
"/gnu/store/ygab8v4ci9iklaykapq52bfsshpvi8pw-cmake-minimal-3.24.2")
  ("qtbase" . 
"/gnu/store/khlz8afih21pd0szn5x1ck6bp6w320cz-qtbase-6.6.0")
[...]
#:qtbase 
"/gnu/store/h8z3xhpb8m1ih2k45935kqx0wya5w7vq-qtbase-5.15.10"
--8<---cut here---end--->8---

Therefore, the transformation does not rewrite #:qtbase.  And note that
qtbase-5.15.10 is not listed as #:inputs.

Without the transformations, it reads,

--8<---cut here---start->8---
(begin
  (use-modules
   (guix build qt-build-system)
   (guix build utils))
  (qt-build #:source 
"/gnu/store/a57n7wy8mdi7l52pr4zg07132blgj5xp-qgit-2.10-checkout" #:system 
"x86_64-linux" #:outputs
(list
 (cons "out"
   ((@
 (guile)
 getenv)
"out")))
#:inputs
(quote
 (("source" . 
"/gnu/store/a57n7wy8mdi7l52pr4zg07132blgj5xp-qgit-2.10-checkout")
  ("cmake" . 
"/gnu/store/ygab8v4ci9iklaykapq52bfsshpvi8pw-cmake-minimal-3.24.2")
  ("qtbase" . 
"/gnu/store/h8z3xhpb8m1ih2k45935kqx0wya5w7vq-qtbase-5.15.10")
[...]
#:qtbase 
"/gnu/store/h8z3xhpb8m1ih2k45935kqx0wya5w7vq-qtbase-5.15.10"
--8<---cut here---end--->8---

Cheers,
simon

bug#66653: Should 'guix pack', 'install', ... accept '-f'?

[Simon Tournier]

Hi,

On Fri, 20 Oct 2023 at 18:18, Tobias Geerinckx-Rice via Bug reports for GNU 
Guix  wrote:

> I feel like that everything that could build a package should accept
> the 'standard build options' like -f.
>
> Does anyone have arguments against it?

No arguments against it. :-)

Cheers,
simon

bug#66610: Acknowledgement (potrace, po4a; guix bug, complete console output)

[Olav Smorholm]

On Mon, Oct 23, 2023 at 07:03:40PM +0200, Olav Smorholm wrote:
> On Mon, Oct 23, 2023 at 06:48:26PM +0200, Olav Smorholm wrote:
> > On Sat, Oct 21, 2023 at 08:52:13PM +0200, Olav Smorholm wrote:
> > >
> > 
> > And call it, or view is it as you may; no trivial task to determine if
> > the guix binary bug and crash was useful or not.
> > 
> > But in the process, while for other things after; starting to study
> > dmesg. Bluez and related things that awaken bluetooth kernel subsystems
> > is less of an aesthetic problem.
> > 
> > I react somewhat on PF_ALG especially, weird segfault that calls itself
> > xsltproc, and that there even exist segfaults and protection faults as
> > if checking for a kernel that is newer than minix era is
> > necessary. As false positives and negatives for intent to hide even the
> > oldest and most deprecated "hello world" crud.
> 
> I'm sure interesting talks can be had:
> 
> [73428.629504] ptrace attach of 
> "/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
> --filter-group=touchpad --xml-output=junit-touchpad-XX.xml"[417] was 
> attempted by 
> "/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
> --filter-group=touchpad --xml-output=junit-touchpad-XX.xml"[419]
> [73428.640092] ptrace attach of 
> "/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
> --filter-group=touchpad-tap --xml-output=junit-touchpad-tap-XX.xml"[420] 
> was attempted by 
> "/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
> --filter-group=touchpad-tap --xml-output=junit-touchpad-tap-XX.xml"[422]
> [75861.720983] traps: bonobo-activati[4394] trap int3 ip:77bf39cf 
> sp:7fffbd80 error:0 in libglib-2.0.so.0.7200.3[77bb7000+88000]
> [77216.387681] Bluetooth: Core ver 2.22
> [77216.387730] NET: Registered PF_BLUETOOTH protocol family
> [77216.387732] Bluetooth: HCI device and connection manager initialized
> [77216.387739] Bluetooth: HCI socket layer initialized
> [77216.387742] Bluetooth: L2CAP socket layer initialized
> [77216.387748] Bluetooth: SCO socket layer initialized
> [77917.396492] python[11571]: segfault at 0 ip 775198c0 sp 
> 7fffb2c8 error 4 in _testcapi.so[77519000+6000] likely on CPU 10 
> (core 4, socket 0)
> [77917.396513] Code: 00 48 83 00 01 c3 0f 1f 40 00 48 89 d0 48 85 d2 74 08 48 
> 83 00 01 c3 0f 1f 00 48 8b 05 11 a7 00 00 48 83 00 01 c3 0f 1f 40 00 <8b> 04 
> 25 00 00 00 00 0f 0b 0f 1f 80 00 00 00 00 48 83 ec 08 48 8b
> [77971.483788] python[19206]: segfault at 0 ip 775198c0 sp 
> 7fffb2c8 error 4 in _testcapi.so[77519000+6000] likely on CPU 10 
> (core 4, socket 0)
> 

Not sure if I have point, it's an argument at least.
That the guix binary is a bit of target for the classical problems
involved. And who knowns, maybe one can find a K&R "hello world" string
in a binary as the best and worst of it.

But this is inherently ugly, to see the measures and crud involved, with
awareness of developers that it touch upon sensitive subsystems.
And may very well make it more accessible for study, publications and
discussions if just shafted and most likely fale positives with academic
print og preprint review.

bug#66610: Acknowledgement (potrace, po4a; guix bug, complete console output)

[Olav Smorholm]

On Mon, Oct 23, 2023 at 07:42:02PM +0200, Olav Smorholm wrote:
> On Mon, Oct 23, 2023 at 07:03:40PM +0200, Olav Smorholm wrote:
> > On Mon, Oct 23, 2023 at 06:48:26PM +0200, Olav Smorholm wrote:
> > > On Sat, Oct 21, 2023 at 08:52:13PM +0200, Olav Smorholm wrote:
> > > >
> > > 
> > > And call it, or view is it as you may; no trivial task to determine if
> > > the guix binary bug and crash was useful or not.
> > > 
> > > But in the process, while for other things after; starting to study
> > > dmesg. Bluez and related things that awaken bluetooth kernel subsystems
> > > is less of an aesthetic problem.
> > > 
> > > I react somewhat on PF_ALG especially, weird segfault that calls itself
> > > xsltproc, and that there even exist segfaults and protection faults as
> > > if checking for a kernel that is newer than minix era is
> > > necessary. As false positives and negatives for intent to hide even the
> > > oldest and most deprecated "hello world" crud.
> > 
> > I'm sure interesting talks can be had:
> > 
> > [73428.629504] ptrace attach of 
> > "/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
> > --filter-group=touchpad --xml-output=junit-touchpad-XX.xml"[417] was 
> > attempted by 
> > "/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
> > --filter-group=touchpad --xml-output=junit-touchpad-XX.xml"[419]
> > [73428.640092] ptrace attach of 
> > "/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
> > --filter-group=touchpad-tap 
> > --xml-output=junit-touchpad-tap-XX.xml"[420] was attempted by 
> > "/tmp/guix-build-libinput-minimal-1.22.1.drv-0/build/libinput-test-suite 
> > --filter-group=touchpad-tap --xml-output=junit-touchpad-tap-XX.xml"[422]
> > [75861.720983] traps: bonobo-activati[4394] trap int3 ip:77bf39cf 
> > sp:7fffbd80 error:0 in libglib-2.0.so.0.7200.3[77bb7000+88000]
> > [77216.387681] Bluetooth: Core ver 2.22
> > [77216.387730] NET: Registered PF_BLUETOOTH protocol family
> > [77216.387732] Bluetooth: HCI device and connection manager initialized
> > [77216.387739] Bluetooth: HCI socket layer initialized
> > [77216.387742] Bluetooth: L2CAP socket layer initialized
> > [77216.387748] Bluetooth: SCO socket layer initialized
> > [77917.396492] python[11571]: segfault at 0 ip 775198c0 sp 
> > 7fffb2c8 error 4 in _testcapi.so[77519000+6000] likely on CPU 
> > 10 (core 4, socket 0)
> > [77917.396513] Code: 00 48 83 00 01 c3 0f 1f 40 00 48 89 d0 48 85 d2 74 08 
> > 48 83 00 01 c3 0f 1f 00 48 8b 05 11 a7 00 00 48 83 00 01 c3 0f 1f 40 00 
> > <8b> 04 25 00 00 00 00 0f 0b 0f 1f 80 00 00 00 00 48 83 ec 08 48 8b
> > [77971.483788] python[19206]: segfault at 0 ip 775198c0 sp 
> > 7fffb2c8 error 4 in _testcapi.so[77519000+6000] likely on CPU 
> > 10 (core 4, socket 0)
> > 
> 
> Not sure if I have point, it's an argument at least.
> That the guix binary is a bit of target for the classical problems
> involved. And who knowns, maybe one can find a K&R "hello world" string
> in a binary as the best and worst of it.
> 
> But this is inherently ugly, to see the measures and crud involved, with
> awareness of developers that it touch upon sensitive subsystems.
> And may very well make it more accessible for study, publications and
> discussions if just shafted and most likely fale positives with academic
> print og preprint review.
> 

[148083.51] Code: Unable to access opcode bytes at 0xffd6.
[148083.518475] test_regression[21751]: segfault at 0 ip  sp 
7fffb998 error 14 in test_regression[40+11000] likely on CPU 11 
(core 5, socket 0)
[148083.518484] Code: Unable to access opcode bytes at 0xffd6.
[148083.519137] test_regression[21752]: segfault at 0 ip  sp 
7fffb998 error 14 in test_regression[40+11000] likely on CPU 11 
(core 5, socket 0)

224051.720066] traps: recentmanager[889] trap int3 ip:77ee5787 
sp:7fff5a40 error:0 in libglib-2.0.so.0.7200.3[77ea7000+88000]

[224450.718378] i915 :83:00.0: [drm] *ERROR* Atomic update failure on pipe 
B (start=174286 end=174287) time 130 us, min 1073, max 1079, scanline start 
1071, end 1072
[243753.929744] i915 :83:00.0: [drm] *ERROR* Atomic update failure on pipe 
B (start=1332500 end=1332501) time 155 us, min 1073, max 1079, scanline start 
1072, end 1073

The latter of which is icecat i believe.

I at the very least understanding things like CPU pipelines and vector
machines and how they differ. Which can be stated in short terms as
modern CPU's are vector machines inherently. You translate your
instructions into simpler operations that can run faster in the central
logic, or you a fast internal part with several units that translate
onto it and are willing to brute force a soltion if need be.

bug#66705: ‘guix shell -CW’ provides a Guix command without extra channels

[Simon Tournier]

Hi,

On Mon, 23 Oct 2023 at 18:52, Ludovic Courtès  wrote:

> Actually, the original profile, which contains ‘guix’ and its channels,
> *is* available in the environment:
>
> --8<---cut here---start->8---
> $ guix time-machine -C <(echo '(cons (channel (name (quote guix-hpc)) (url 
> "https://gitlab.inria.fr/guix-hpc/guix-hpc.git";)) %default-channels)') -- 
> shell -CW coreutils 
> [env]$ readlink -f $(type -P guix)
> /gnu/store/42731vcvzl6nrwa584mziwhpvp4xs72r-guix-command
> [env]$ type -P guix
> /gnu/store/ca142m4lm0grxmsjqrcqpfl5qb5i1rka-profile/bin/guix
> [env]$ readlink $(type -P guix)
> /gnu/store/j5g09kjd7pv1b6919vbsnjs160xfw9md-profile/bin/guix
> [env]$ /gnu/store/j5g09kjd7pv1b6919vbsnjs160xfw9md-profile/bin/guix describe
>   guix cbd20d6
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 
> ]8;;https://git.savannah.gnu.org/cgit/guix.git/commit/?id=cbd20d627497053871db863970c07d93c7081786\cbd20d627497053871db863970c07d93c7081786]8;;\
>   guix-hpc 887d76a
> repository URL: https://gitlab.inria.fr/guix-hpc/guix-hpc.git
> branch: master
> commit: 
> ]8;;https://gitlab.inria.fr/guix-hpc/guix-hpc/commit/887d76a8e1d0f35d615c613b28b9b871f39a997e\887d76a8e1d0f35d615c613b28b9b871f39a997e]8;;\
> --8<---cut here---end--->8---
>
> The problem is the extra profile layer that confuses
> ‘current-channel-entries’ in (guix describe).

Oh.  Naive remarks.  The ’guix’ in the manifest points to the correct
one with both channels.

--8<---cut here---start->8---
$ guix time-machine -C <(echo '(cons (channel (name (quote guix-hpc)) (url 
"https://gitlab.inria.fr/guix-hpc/guix-hpc.git";)) %default-channels)') -- shell 
-CW coreutils
[env]$ cat $GUIX_ENVIRONMENT/manifest
;; This file was automatically generated and is for internal use only.
;; It cannot be passed to the '--manifest' option.
;; Run 'guix package --export-manifest' if you want to export a file
;; suitable for '--manifest'.

(manifest
  (version 4)
  (packages
(("coreutils"
  "9.1"
  "out"
  "/gnu/store/d4rqw481nwvrzs09nd8ad647nczgm9k1-coreutils-9.1")
 ("guix"
  "cbd20d627497053871db863970c07d93c7081786"
  "out"
  "/gnu/store/vrmfn5142771vzma3nzivb8j3zx9780v-profile"
  (search-paths
(("GUIX_EXTENSIONS_PATH"
  ("share/guix/extensions")
  ":"
  directory
  #f)
 ("SSL_CERT_DIR"
  ("etc/ssl/certs")
  #f
  directory
  #f)))

[env]$ /gnu/store/vrmfn5142771vzma3nzivb8j3zx9780v-profile/bin/guix describe
  guix cbd20d6
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 
]8;;https://git.savannah.gnu.org/cgit/guix.git/commit/?id=cbd20d627497053871db863970c07d93c7081786\cbd20d627497053871db863970c07d93c7081786]8;;\
  guix-hpc ef21e73
repository URL: https://gitlab.inria.fr/guix-hpc/guix-hpc.git
branch: master
commit: 
]8;;https://gitlab.inria.fr/guix-hpc/guix-hpc/commit/ef21e73d09e792c3ed18b2483a6290b8309bd929\ef21e73d09e792c3ed18b2483a6290b8309bd929]8;;\
--8<---cut here---end--->8---

Well, what appears to me weird is that the ’guix’ I type is incorrect
but points to a correct one.

--8<---cut here---start->8---
[env]$ ls -l $(type -P guix)
lrwxrwxrwx 1 65534 overflow 60 Jan  1  1970 
/gnu/store/519kyqhl1n5r6cj0jbpkc77v4mnf6ip9-profile/bin/guix -> 
/gnu/store/vrmfn5142771vzma3nzivb8j3zx9780v-profile/bin/guix

[env]$ /gnu/store/519kyqhl1n5r6cj0jbpkc77v4mnf6ip9-profile/bin/guix describe
  guix cbd20d6
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 
]8;;https://git.savannah.gnu.org/cgit/guix.git/commit/?id=cbd20d627497053871db863970c07d93c7081786\cbd20d627497053871db863970c07d93c7081786]8;;\

[env]$ /gnu/store/vrmfn5142771vzma3nzivb8j3zx9780v-profile/bin/guix describe
  guix cbd20d6
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 
]8;;https://git.savannah.gnu.org/cgit/guix.git/commit/?id=cbd20d627497053871db863970c07d93c7081786\cbd20d627497053871db863970c07d93c7081786]8;;\
  guix-hpc ef21e73
repository URL: https://gitlab.inria.fr/guix-hpc/guix-hpc.git
branch: master
commit: 
]8;;https://gitlab.inria.fr/guix-hpc/guix-hpc/commit/ef21e73d09e792c3ed18b2483a6290b8309bd929\ef21e73d09e792c3ed18b2483a6290b8309bd929]8;;\
--8<---cut here---end--->8---

Well, another way to express,

This is due to the fact that ‘-W’ (‘--nesting’) is implemented by adding
the outer ‘guix’ to the container’s profile, without also adding its
companion profile entries (those that provide channels).

is to note that the manifest file is incorrect and does not contain the
outer manifest file, right?

--8<---cut here-

bug#65225: [bug#66640] [PATCH 0/2] Build profile hooks for the right system

[Ludovic Courtès]

Simon Tournier  skribis:

> Do I understand correctly when I consider that
> ’(efi-bootloader-profile-hook manifest)’ pass #false as ’system’ and
> then it is ’set-guile-for-build’ that sets ’(%current-system)’?

Yes.

> Somehow, my question is about the readability of default values.
>
> Why not,
>
> #:system (or system (%current-system))
>
> for all the hooks?

Because that value would be captured at call time rather than at
monadic-bind time.  See Josselin’s excellent explanation of this trap:

  https://issues.guix.gnu.org/65225#4-lineno34

HTH!

Ludo’.

bug#66684: [shepherd] Altering system time renders herd unresponsive

[Ludovic Courtès]

Hi Vladilen,

Vladilen Kozin  skribis:

> My server would consistently run with system time 1h ahead of actual.
> Both `date` and `hwclock` would show the same time off by 1hr, while
> BIOS showed me correct time. I'm not sure why, but some services won't
> run if time difference is e.g. over 15min or smth, so.
>
> $ sudo date -s '-1 hour'
>
> fixes time but causes `herd` to become unresponsive as in you type a
> command, any command and stare at tty stuck. Also ssh'ing into the
> system becomes impossible.

Thanks for your report.  This issue comes from Fibers 1.3.1:

  https://github.com/wingo/fibers/issues/89

There’s currently no bug-fix in sight though.

Ludo’.

bug#66027: Add a feature to automatically close specified bug reports upon committing.

[Maxim Cournoyer]

Hi,

Simon Tournier  writes:

> Hi Maxim,
>
> If I read correctly, this series had been merged with:
>
> fb3707762d * etc: teams: Parse 'From' commit more leniently.
> f44fa21c3e * gnu: patman: Apply patch for new Change-Id setting.
> 8005e09b26 * build: Add a commit-msg hook that embeds Change-Id in commit 
> messages.
>
> Right?
>
> Mark the submission as done?  Or maybe is it a way for testing the
> feature?  ;-)

It's only partially implementing the fix as mentioned in fb3707762d; the
missing bit is making use of the newly introduced Change-Id in mumi or a
script to determine if a series was fully merged, and close it if so.

So it should remain open until then :-).

-- 
Thanks,
Maxim

bug#66692: [cuirass] Spurious failed builds following patching u-boot sources

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> The build failures are not captured in the logs, which appear truncated,
> e.g. from  (log empty --
> builder: sjd-p9, worker N38vG7OW) 

On sjd-p9, I get:

--8<---cut here---start->8---
root@sjd-p9:~# journalctl -u cuirass-remote-worker.service |grep -C2 
s167lh0w0azfxx83ri8k0mn2gj57i5rl
Oct 23 00:06:21 sjd-p9 cuirass[531]: N38vG7OW: derivation 
/gnu/store/kcv6hfqz94f1vdw24viw7d9ih6v9zi1j-libkmahjongg-23.04.3.drv build 
succeeded.
Oct 23 00:06:21 sjd-p9 cuirass[531]: N38vG7OW: request work.
Oct 23 00:06:21 sjd-p9 cuirass[531]: N38vG7OW: building derivation 
`/gnu/store/s167lh0w0azfxx83ri8k0mn2gj57i5rl-u-boot-rpi-4-32b-2023.07.02.drv' 
(system: powerpc64le-linux)
Oct 23 00:06:32 sjd-p9 cuirass[531]: C2q41fts: ping tcp://10.0.0.1:.
Oct 23 00:06:32 sjd-p9 cuirass[531]: BrnR2Sju: ping tcp://10.0.0.1:.
--
Oct 23 00:34:16 sjd-p9 cuirass[531]: vA6cYbb5: request work.
Oct 23 00:34:16 sjd-p9 cuirass[531]: vA6cYbb5: building derivation 
`/gnu/store/lj4h1g1zq235l6i8mjh88s1ylvj7ksxd-u-boot-pine64-plus-2023.07.02.drv' 
(system: powerpc64le-linux)
Oct 23 00:34:29 sjd-p9 cuirass[531]: N38vG7OW: derivation 
/gnu/store/s167lh0w0azfxx83ri8k0mn2gj57i5rl-u-boot-rpi-4-32b-2023.07.02.drv 
build failed.
Oct 23 00:34:29 sjd-p9 cuirass[531]: N38vG7OW: request work.
Oct 23 00:34:29 sjd-p9 cuirass[531]: N38vG7OW: building derivation 
`/gnu/store/dy8g5pi1gv8dza1av9957ic6zzj4l88j-u-boot-tools-2023.07.02.drv' 
(system: powerpc64le-linux)
root@sjd-p9:~# guix build --log-file 
/gnu/store/s167lh0w0azfxx83ri8k0mn2gj57i5rl-u-boot-rpi-4-32b-2023.07.02.drv
https://ci.guix.gnu.org/log/0yzfwl2b017gsnf60wvr7dnn2g26wrj7-u-boot-rpi-4-32b-2023.07.02
--8<---cut here---end--->8---

So it looks as though the build was attempted and failed, but there’s no
local build log in /var/log/guix/drvs, meaning that, most likely, no
build process was even started.

The log of guix-daemon provide few hints:

--8<---cut here---start->8---
root@sjd-p9:~# journalctl -u guix-daemon |grep 'Oct 23 00:'

[...]

Oct 23 00:06:21 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:06:21 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:06:55 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:07:51 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:16:25 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:17:15 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:33:42 sjd-p9 guix-daemon[2097426]: SIGPOLL
Oct 23 00:33:42 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:33:49 sjd-p9 guix-daemon[2097426]: unexpected build daemon error: 
interrupted by the user
Oct 23 00:34:16 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:34:16 sjd-p9 guix-daemon[1990649]: SIGPOLL
Oct 23 00:34:23 sjd-p9 guix-daemon[1990649]: unexpected build daemon error: 
interrupted by the user
Oct 23 00:34:29 sjd-p9 guix-daemon[2052532]: SIGPOLL
Oct 23 00:34:29 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:34:30 sjd-p9 guix-daemon[2052532]: unexpected build daemon error: 
interrupted by the user
Oct 23 00:34:38 sjd-p9 guix-daemon[1996946]: SIGPOLL
Oct 23 00:34:38 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:34:38 sjd-p9 guix-daemon[1996946]: unexpected build daemon error: 
interrupted by the user
Oct 23 00:34:45 sjd-p9 guix-daemon[2248556]: SIGPOLL
Oct 23 00:34:45 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:34:45 sjd-p9 guix-daemon[2248556]: unexpected build daemon error: 
interrupted by the user
Oct 23 00:35:33 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
Oct 23 00:36:46 sjd-p9 guix-daemon[534]: accepted connection from pid 531, user 
root
--8<---cut here---end--->8---

One possibility would have been that ‘guix gc’ was running, preventing
the build process from starting (“big GC lock” taken); however, if this
were the case, we’d see a connection from a different process in the
guix-daemon log.

> or from  (builder:
> hydra-guix-107, worker 4CWieLpQ) which ends with:

Here we get:

--8<---cut here---start->8---
root@hydra-guix-107 ~# grep -C2 jy463789qf42dn4zk5i5jzry2lf82ypy 
/var/log/cuirass-remote-worker.log
2023-10-23 00:17:34 vDKeRcHy: no available build.
2023-10-23 00:17:46 4CWieLpQ: request work.
2023-10-23 00:17:46 4CWieLpQ: building derivation 
`/gnu/store/jy463789qf42dn4zk5i5jzry2lf82ypy-u-boot-cubietruck-2023.07.02.drv' 
(system: x86_64-linux)
2023-10-23 00:18:03 zARGXQMa: request work.
2023-10-23 00:18:03 zARGXQMa: no availab

bug#66692: [cuirass] Spurious failed builds following patching u-boot sources

[Ludovic Courtès]

Ludovic Courtès  skribis:

> /var/log/cuirass-remote-server.log:
>
> 2023-10-23 00:26:06 0 items queued for eventual download
> 2023-10-23 00:26:55 period update: 0 resumable, 0 failed builds.
> 2023-10-23 00:26:58 error: failed to start worker/database proxy: Invalid 
> argument

EINVAL here most likely comes from replying to a sender with invalid ID,
due to ZMQ_ROUTER_MANDATORY, exactly what Cuirass commit
40f70d28aed55c404cca6a0760860fb4942e6bee fixed and aimed to catch.

Ludo’.

bug#66691: GnuTLS 3.8.1 fails to (cross-)build for GNU/Hurd

[Ludovic Courtès]

Ludovic Courtès  skribis:

> The recently-committed GnuTLS 3.8.1 fails to (cross-)build for GNU/Hurd:

Fixed in a1ac534f8a509bc7ddf11bcd5987fa65adf8c9ca.

bug#65720: [PATCH] git: Shell out to ‘git gc’ when necessary.

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

>Why not trigger it by “guix gc”?

Unless there's a new option I missed, guix gc doesn't handle this.

>Well, I expect “guix gc” to take some time and I choose when.  However,
>I want “guix pull” or “guix time-machine” to be as fast as possible

I don't think that things should be pushed into guix gc merely because they are 
slow.

This is not a great post (I'd look at the git code if I were at a computer) but 
I remember git printing something like 'optimising repository in the 
background'.  Maybe something similar would be appropriate here, to better hide 
such housekeeping from the user.


Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#66692: [cuirass] Spurious failed builds following patching u-boot sources

[Maxim Cournoyer]

Hi Ludovic!

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>> /var/log/cuirass-remote-server.log:
>>
>> 2023-10-23 00:26:06 0 items queued for eventual download
>> 2023-10-23 00:26:55 period update: 0 resumable, 0 failed builds.
>> 2023-10-23 00:26:58 error: failed to start worker/database proxy: Invalid 
>> argument
>
> EINVAL here most likely comes from replying to a sender with invalid ID,
> due to ZMQ_ROUTER_MANDATORY, exactly what Cuirass commit
> 40f70d28aed55c404cca6a0760860fb4942e6bee fixed and aimed to catch.

Thanks for picking up the investigation.  Does that mean that the above
fix was partial and that there likely is a use after free somewhere
else?

It's good at least that this ZMQ_ROUTER_MANDATORY option catches that.

(Also, these scary Btrfs errors are a reminder that the file system got
corrupted at some point and should be recreated at some point -- I hope
they are not related to the problem at hand but we should keep an eye on
things).

-- 
Thanks,
Maxim

bug#66703: Broken link to Debbugs User Guide

[Maxim Cournoyer]

Hi Greg,

Greg Hogan  writes:

> The page 
> https://guix.gnu.org/devel/manual/en/html_node/Debbugs-User-Interfaces.html
> has a broken link "Debbugs User Guide" to the page
> https://guix.gnu.org/devel/manual/en/debbugs-ug/index.html#Top.

There doesn't seem to be an online HTML version of this manual, so the
bug doesn't appear actionable.

It works when using 'info', provided the 'emacs-debbugs' package is
installed.

-- 
Thanks,
Maxim

bug#65858: mumi crashes

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Hi Arun,
>
> Arun Isaac  writes:
>
>> Hi Maxim,
>>
>> I have made a number of changes to mumi and reconfigured berlin with the
>> latest mumi. Here is a quick summary of the main changes to mumi.
>>
>> - We now log the complete URI and the response code for every request to
>>   mumi.
>> - We now handle HEAD requests correctly. This should eliminate some of
>>   the crashes we saw in the mumi log.
>
> Thanks!  Let's keep an eye on things.

Here's a fresh crash (on berlin):

--8<---cut here---start->8---
2023-10-24 06:22:58 GET 
/graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065806%29%20%7B%0A%20%20%20%
20open%0A%20%20%7D%0A%7D%0A&variables=%7B%7D 200
2023-10-24 06:22:58 GET /issue/29433/attachment/1/ 200
2023-10-24 06:22:58 GET 
/graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065853%29%20%7B%0A%20%20%20%
20open%0A%20%20%7D%0A%7D%0A&variables=%7B%7D 200
2023-10-24 06:22:58 GET 
/graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065869%29%20%7B%0A%20%20%20%
20open%0A%20%20%7D%0A%7D%0A&variables=%7B%7D 200
2023-10-24 06:23:15 GET Uncaught exception in task:
2023-10-24 06:23:15 In procedure port-auxiliary-write-buffer: Wrong type 
argument in position 1 (expecting
 open port): #
2023-10-24 06:23:15 In fibers.scm:
2023-10-24 06:23:15 172:8  6 (_)
2023-10-24 06:23:15 In ice-9/boot-9.scm:
2023-10-24 06:23:15   1752:10  5 (with-exception-handler _ _ #:unwind? _ # _)
2023-10-24 06:23:15 In fibers/web/server.scm:
2023-10-24 06:23:15214:25  4 (_)
2023-10-24 06:23:15 In ice-9/suspendable-ports.scm:
2023-10-24 06:23:15  83:4  3 (write-bytes # 
#vu8(47 42 …) …)
2023-10-24 06:23:15 In unknown file:
2023-10-24 06:23:152 (port-write # 
#vu8(47 42 # …) …)
2023-10-24 06:23:15 In ice-9/boot-9.scm:
2023-10-24 06:23:15   1685:16  1 (raise-exception _ #:continuable? _)
2023-10-24 06:23:15   1685:16  0 (raise-exception _ #:continuable? _)
2023-10-24 06:23:15 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
2023-10-24 06:23:15 In procedure fport_write: Broken pipe
--8<---cut here---end--->8---

-- 
Thanks,
Maxim