bug#71238: Installer image consistently fails to run system init due to TLS error

[Richard Sent]

Richard Sent  writes:

> What the heck is going on here? Those two images are wildly different
> and are downloading wildly different sets of substitutes.

Bad news. I connected my device to a different network with just an
ordinary consumer router and the installation succeeded (using the guix
00384aed media). Ordinary my devices are behind a opnsense router with a
/very/ lightly-customized firewall. To me, this means there are three
possibilities, none of which is particularly comforting:

1. There was a transient network issue for ~3 hours when I attempted to
install Guix ~4 times using different installation media that caused a
specific TLS handshake to fail.

2. A specific TLS handshake Guix undertakes during the installation
process fails to pass one of the built-in firewall rules shipped with
opnsense.

3. Some other odd aspect of my network messes things up for a specific
TLS handshake.

My money is on 2 given how this is a seemingly common issue on
enterprise networks [1] and the rules I have added seem irrelevant. (I'd
rather not talk openly about my firewall rules in an archived public
forum, but can discuss off-list). However, there is another comment in
that thread that says IT didn't notice any firewall blocking.

>> Sometimes, usually when I'm on an enterprise network like my
>> university's of library's wifi, the `guix substitute` process dies
>> with a "TLS error in procedure 'write_to_session_record_port': Error
>> in the push function" error message. My connection is rock-solid
>> otherwise, and sometimes it doesn't happen at all.
> I get the same error on guix pull almost always when I am on my
> enterprise network. Re-running guix pull a second time also almost
> always then runs fine. I checked with our IT: nothing suspicious on
> the network, i.e. no firewall blocking.

Running Guix pull to work around the problem is great.. unless
you're trying to install Guix via the guided installer! :) In my case it
also wasn't guix pull that was failing.

I want to emphasize that the error occured in the same phase of the
installer every time, it was not the first handshake, no other machine
has ever had this issue, and the installer was (3/4 times) on a commit
that should include the fix described in [1].

I'm happy to assist with debugging this, although I'm not some TLS
networking genius so trying to solve it outright is probably beyond me.
I'd also LOVE to hear if other people using a largely stock opnsense or
other firewall software encountered this issue, particularly with the
installation media.

At some point I'll attempt to gradually "de-enterprise" parts of my
network and see exactly when (if ever) the problem is resolved. Due to
the nature of the problem, reliably reproducing it in the future will be
a challenge.

CC'ing people involved in [1] because this is just so weird and I don't
want it to be consigned to the dustbins of history. I don't think we
heard anyone with the issue explicitly say the fix resolved or at least
mitigated the problem.

[1]: https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00150.html

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

bug#71238: Installer image consistently fails to run system init due to TLS error

[Richard Sent]

> Curiously this does NOT occur the first time substitutes are fetched. I
> observed it occur three times when substitutes were fetched after Ruby
> was substituted. I don't mean to say that Ruby is the problem (that'd be
> crazy), just that the TLS error occurs at the same stage in the
> installation every time. NOT randomly.
>
> I've never encountered this error before on any other Guix machine on my
> network. The installation machine was using a wired connection.

I have now tried the v1.4.0 installer and get a failure at (seemingly)
the same point in the install, although the actual error is different.
See installer-dump-22e789d5.

What the heck is going on here? Those two images are wildly different
and are downloading wildly different sets of substitutes.

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

bug#71238: Installer image consistently fails to run system init due to TLS error

[Richard Sent]

Hi Guix!

The dump was uploaded as installer-dump-2e7b5f8f. Here's the installer's
error message:

--8<---cut here---start->8---
May 27 22:15:49 localhost installer[708]: substitute: ^[[Kupdating substitutes 
from 'https://bordeaux.guix.gnu.org'...   0.0%guix substitute: error: TLS error 
in procedure 'write_to_session_record_port': Error in the push function. 
May 27 22:15:49 localhost installer[708]: guix system: ^[[1;31merror: 
^[[0m`/gnu/store/rdjjpch9m9xv4rdhhr6sv044qd322pj8-guix-command substitute' died 
unexpectedly 
--8<---cut here---end--->8---

A Guix system installation generated via the following method
consistently fails to install due to a TLS error when updating
substitutes.

--8<---cut here---start->8---
gibraltar :( guix$ guix time-machine -q -- describe
  guix 00384ae
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 00384aedbc6a371aaf90ca344a446952fdd5a6b3
gibraltar :) guix$ guix time-machine -q -- system image --image-type=iso9660 -e 
'(@ (gnu system install) installation-os)'
guix system: warning: Consider running 'guix pull' followed by
'guix system reconfigure' to get up-to-date packages and security updates.

Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Computing Guix derivation for 'x86_64-linux'... \
/gnu/store/x9a2nflpnfpr8i3n1759hw7wg2qv5mm8-image.iso
--8<---cut here---end--->8---

Curiously this does NOT occur the first time substitutes are fetched. I
observed it occur three times when substitutes were fetched after Ruby
was substituted. I don't mean to say that Ruby is the problem (that'd be
crazy), just that the TLS error occurs at the same stage in the
installation every time. NOT randomly.

I've never encountered this error before on any other Guix machine on my
network. The installation machine was using a wired connection.

Possibly related: [1], [2], [3], [4]

Notably [3] claims to have a fix that was merged into Guix, but 00384ae
is after said fix was merged (and yes, $ guix describe on the installer
image does report 00384ae)

[1]: https://issues.guix.gnu.org/66786
[2]: https://issues.guix.gnu.org/48903
[3]: https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00150.html
[4]: https://issues.guix.gnu.org/70244

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

bug#70480: Guix bios installation: Grub error: unknown filesystem

[Lars-Dominik Braun]

Hi,

>Installing for i386-pc platform.
>/gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install: 
> error: unknown filesystem.

this should be fixed by 71210, which I just merged.

Lars

bug#70062: issue with openldap managed users on HPC

[Ludovic Courtès]

Hi Davide,

Sorry for the delay; it looks like your bug report fell through the
cracks.

Davide Corrado  skribis:

> hello, I installed guix in a HPC environment and everything works as expected 
> if I use guix as a local user. I got this issue when I try to run it as an 
> openldap/sssd-managed user.
>
> example:
> [
> root@frontend ~]# id konrad
> uid=1(konrad) gid=1(hpc-users) groups=1(hpc-users)
>
> [root@frontend ~]# getent passwd -s sss
> konrad:*:1:1:Davide Corrado:/home/konrad:/bin/bash
>
> [root@frontend ~]# su - konrad
> Last login: Thu Mar 28 11:04:07 CET 2024 on pts/0
> [konrad@frontend ~]$ id
> uid=1(konrad) gid=1(hpc-users) groups=1(hpc-users)
> [konrad@frontend ~]$ guix install hello
> user with UID 1 not found

I think this message shows the core of the problem.

Is nscd running on this machine, as per
?

It has to be installed and running so that Guix-installed programs can
access the user account database etc.

A simple way to check whether this is working is by running the ‘id’
program of the ‘coreutils’ package provided by Guix, like so:

  guix shell coreutils -- id

HTH!

Ludo’.

bug#71226: ‘guix shell -C’ doesn’t work on Ubuntu 24.04

[Ludovic Courtès]

On Ubuntu 24.04, ‘guix shell -C’ has its child process (in a separate
mount namespace) fail to mount a tmpfs:

--8<---cut here---start->8---
294642 clone(child_stack=NULL, 
flags=CLONE_NEWNS|CLONE_NEWCGROUP|CLONE_NEWUTS|CLONE_NEWIPC|CLONE_NEWUSER|CLONE_NEWPID|CLONE_NEWNET|SIGCHLD)
 = 294653
294642 close(15)= 0
294642 getuid() = 1000
294642 getgid() = 1000
294653 close(16)= 0
294642 openat(AT_FDCWD, "/proc/294653/setgroups", O_WRONLY|O_CREAT|O_TRUNC, 
0666 
294653 read(15,  
294642 <... openat resumed>)= 6
294642 newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) 
= 0
294642 lseek(6, 0, SEEK_CUR)= 0
294642 write(6, "deny", 4)  = 4
294642 close(6) = 0
294642 openat(AT_FDCWD, "/proc/294653/uid_map", O_WRONLY|O_CREAT|O_TRUNC, 0666) 
= 6
294642 newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) 
= 0
294642 lseek(6, 0, SEEK_CUR)= 0
294642 write(6, "1000 1000 1", 11)  = 11
294642 close(6) = 0
294642 openat(AT_FDCWD, "/proc/294653/gid_map", O_WRONLY|O_CREAT|O_TRUNC, 0666) 
= 6
294642 newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) 
= 0
294642 lseek(6, 0, SEEK_CUR)= 0
294642 write(6, "1000 1000 1", 11)  = 11
294642 close(6) = 0
294642 write(16, "ready", 5)= 5
294653 <... read resumed>"r", 1)= 1
294642 write(16, "\n", 1)   = 1
294653 read(15, "e", 1) = 1
294642 read(16,  
294653 read(15, "a", 1) = 1
294653 read(15, "d", 1) = 1
294653 read(15, "y", 1) = 1
294653 read(15, "\n", 1)= 1
294653 mount("none", "/tmp/guix-directory.3DaoGp", "tmpfs", 0, NULL) = -1 
EACCES (Permission denied)
294653 write(15, "(", 1)= 1
294642 <... read resumed>"(", 1)= 1
294653 write(15, "system-error", 12 
--8<---cut here---end--->8---

(It used to work on Ubuntu 22.)

Ludo’.

bug#71218: OpenMW Crashes on Open (Segfault)

[Dylan Connell]

Hi there!

I've been having an issue with OpenMW 0.48.0 on Guix commit
898b5f30f3d485d48275c920da172863da9524c6, where the game will crash shortly
after opening. I'm using a Lenovo t450s with Linux Kernel, and a copy of
Morrowind obtained from a disc. I've attached the crash log to this
message.
*** Fatal Error ***
Address not mapped to object (signal 11)
Address: (nil)

System: Linux DMC-L1 6.6.17 #1 SMP PREEMPT_DYNAMIC 1 x86_64

Executing: gdb --quiet --batch --command=/tmp/gdb-respfile-Mpd0VC
[New LWP 19904]
[New LWP 19905]
[New LWP 19908]
[New LWP 19909]
[New LWP 19910]
[New LWP 19924]
[New LWP 19925]
[New LWP 19926]
[New LWP 19927]
[New LWP 19928]
[New LWP 19955]
[New LWP 19956]
[New LWP 19957]
[New LWP 19958]
[New LWP 19959]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libthread_db.so.1".
0x7fd84708616a in __futex_abstimed_wait_common () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6

* Loaded Libraries
FromTo  Syms Read   Shared Object Library
0x7fd84d90b0b0  0x7fd84d938536  Yes (*) /gnu/store/vc7s2z80cycl6dkas2zqb4y5ymvgk144-openscenegraph-3.6-3.68c5c57/lib/libosgParticle.so.162
0x7fd84d80dbe0  0x7fd84d89dd93  Yes (*) /gnu/store/vc7s2z80cycl6dkas2zqb4y5ymvgk144-openscenegraph-3.6-3.68c5c57/lib/libosgViewer.so.162
0x7fd84d720150  0x7fd84d756f53  Yes (*) /gnu/store/vc7s2z80cycl6dkas2zqb4y5ymvgk144-openscenegraph-3.6-3.68c5c57/lib/libosgGA.so.162
0x7fd84d635aa0  0x7fd84d68fdd7  Yes (*) /gnu/store/vc7s2z80cycl6dkas2zqb4y5ymvgk144-openscenegraph-3.6-3.68c5c57/lib/libosgShadow.so.162
0x7fd84d503680  0x7fd84d5c57d8  Yes (*) /gnu/store/vc7s2z80cycl6dkas2zqb4y5ymvgk144-openscenegraph-3.6-3.68c5c57/lib/libosgDB.so.162
0x7fd84d2bd160  0x7fd84d3e0fa8  Yes (*) /gnu/store/vc7s2z80cycl6dkas2zqb4y5ymvgk144-openscenegraph-3.6-3.68c5c57/lib/libosgUtil.so.162
0x7fd84cf17ab0  0x7fd84d11e3ac  Yes (*) /gnu/store/vc7s2z80cycl6dkas2zqb4y5ymvgk144-openscenegraph-3.6-3.68c5c57/lib/libosg.so.162
0x7fd84d488040  0x7fd84d488101  Yes (*) /gnu/store/mqmww92jyx8xyqccn79rk1i3z0jp40kd-boost-1.80.0/lib/libboost_system.so.1.80.0
0x7fd84d46a9e0  0x7fd84d47e551  Yes (*) /gnu/store/mqmww92jyx8xyqccn79rk1i3z0jp40kd-boost-1.80.0/lib/libboost_filesystem.so.1.80.0
0x7fd84cda5ae0  0x7fd84cded2a5  Yes (*) /gnu/store/mqmww92jyx8xyqccn79rk1i3z0jp40kd-boost-1.80.0/lib/libboost_program_options.so.1.80.0
0x7fd84cc51bf0  0x7fd84cccefff  Yes (*) /gnu/store/sdnhqc1v25b36j2sf56day78cgraf5ki-openal-1.22.2/lib/libopenal.so.1
0x7fd84b873620  0x7fd84c20d598  Yes (*) /gnu/store/mf3lc24kv3lpxw49n0pvjiwmdypzslbl-ffmpeg-6.1.1/lib/libavcodec.so.60
0x7fd84b43f030  0x7fd84b5cb02c  Yes (*) /gnu/store/mf3lc24kv3lpxw49n0pvjiwmdypzslbl-ffmpeg-6.1.1/lib/libavformat.so.60
0x7fd84a217760  0x7fd84a2bacec  Yes (*) /gnu/store/mf3lc24kv3lpxw49n0pvjiwmdypzslbl-ffmpeg-6.1.1/lib/libavutil.so.58
0x7fd84cbae2e0  0x7fd84cc23d5b  Yes (*) /gnu/store/mf3lc24kv3lpxw49n0pvjiwmdypzslbl-ffmpeg-6.1.1/lib/libswscale.so.7
0x7fd84d1e3320  0x7fd84d1f6e3c  Yes (*) /gnu/store/mf3lc24kv3lpxw49n0pvjiwmdypzslbl-ffmpeg-6.1.1/lib/libswresample.so.4
0x7fd849e7ad70  0x7fd849fd67bb  Yes (*) /gnu/store/mm4xs6zvakzahvmd9n45839hy7zk29jd-mygui-gl-3.4.2/lib/libMyGUIEngine.so.3.4.2
0x7fd849a34d20  0x7fd849b8fbde  Yes (*) /gnu/store/fq939shv5sfn7aav6np4gnf1yzizfjqa-sdl2-2.30.1/lib/libSDL2-2.0.so.0
0x7fd84b77c9b0  0x7fd84b7ca9b7  Yes (*) /gnu/store/vc7s2z80cycl6dkas2zqb4y5ymvgk144-openscenegraph-3.6-3.68c5c57/lib/libosgAnimation.so.162
0x7fd84cb596c0  0x7fd84cb96e58  Yes (*) /gnu/store/vc7s2z80cycl6dkas2zqb4y5ymvgk144-openscenegraph-3.6-3.68c5c57/lib/libosgText.so.162
0x7fd84d457510  0x7fd84d458e08  Yes (*) /gnu/store/vc7s2z80cycl6dkas2zqb4y5ymvgk144-openscenegraph-3.6-3.68c5c57/lib/libOpenThreads.so.21
0x7fd84d1d05f0  0x7fd84d1d7528  Yes (*) /gnu/store/mqmww92jyx8xyqccn79rk1i3z0jp40kd-boost-1.80.0/lib/libboost_iostreams.so.1.80.0
0x7fd84b6bbf80  0x7fd84b6fb8ae  Yes (*) /gnu/store/9i3zzv8kmv2rkkiyn70lp594fz637vna-mesa-24.0.4/lib/libGL.so.1
0x7fd84b37dc70  0x7fd84b3e3113  Yes (*) /gnu/store/cvx5k3wsy0iczzc1pk0fid9lfg48kyml-luajit-2.1.0-beta3-0.6c4826f/lib/libluajit-5.1.so.2
0x7fd84cb082b0  0x7fd84cb329f7  Yes (*) /gnu/store/4qz7f96zffx9z3fn2ym4dd1g4c8lwmlj-lz4-1.9.3/lib/liblz4.so.1
0x7fd84caf62c0  0x7fd84caffc36  Yes (*) /gnu/store/44sqzvy9lvs8a5my3i4s5swaqpicn1az-recastnavigation-1.6.0/lib/libDebugUtils.so.1
0x7fd84cadf520  0x7fd84caeda82  Yes (*) /gnu/store/44sqzvy9lvs8a5my3i4s5swaqpicn1az-recastnavigation-1.6.0/lib/libDetour.so.1
0x7fd84b682290  0x7fd84b6984da  Yes (*) 

bug#62890: StumpWM fails to start - Read only file system

[Richard Sent]

Richard Sent  writes:

> Packages that depend on say, A:lib graft their own copies of A:lib that
> is distinct from grafting A:out and A:lib together. This behavior
> confuses asdf-build-system and leads to breakage.

I should rephase this. asdf-build-system is doing its job just fine. I
don't think it's the build-system that's broken. It's that splitting
outputs like this simply leads to incompatibility with asdf itself.

That being said, I've never actually /used/ asdf. I welcome thoughts
from my betters! :)

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

bug#47115: Another occurence in the wild

[Richard Sent]

Hi Guix!

I believe I found another instance of this bug coming back to haunt
unfortunate, wayward souls. (including me! ).

https://issues.guix.gnu.org/62890

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.

bug#62890: Likely cause found, excess library grafting

[Richard Sent]

Hi Guix!

Once again I sunk more time into this issue when I should have been
sleeping. Here's what I found:

Building a grafted stumpwm directly creates one stumpwm:lib output.
Building it /indirectly/ as a dependency of, say, sbcl-stumpwm-cpu,
creates another, distinct stumpwm:lib output. This difference in
stumpwm:lib outputs is reflected in 50-stumpwm.conf being incoherent.

Packages that depend on say, A:lib graft their own copies of A:lib that
is distinct from grafting A:out and A:lib together. This behavior
confuses asdf-build-system and leads to breakage.

Here's a link to an issue discussing excess library grafts:
https://issues.guix.gnu.org/47115#23

The simplest way to resolve this I feel is to either:

1. Remove stumpwm:lib entirely and just have stumpwm:out
   1. Realistically is anyone out there using stumpwm:lib but NOT
   stumpwm:out? What would the point of that be?
2. Add stumpwm as an input to to any package that just uses stumpwm:lib.

Between the two, I strongly prefer 1.

Below is a bunch of debug output to show how I reached the conclusion
that I did.

--8<---cut here---start->8---
richard@gibraltar ~/code/cloned/guix [env]$ ./pre-inst-env guix build stumpwm 
--check
The following graft will be made:
/gnu/store/bsxspzrhfwsl4qp0n01mgcaqcp1934dj-stumpwm-22.11.drv
applying 9 grafts for stumpwm-22.11 ...
grafting '/gnu/store/j73w1n1sf3gqgx8qx3cx9csbrndddq0b-stumpwm-22.11-lib' -> 
'/gnu/store/r4sc5ylh2g30zgr10q35phd80cb3llqy-stumpwm-22.11-lib'...
grafting '/gnu/store/2rd3r0m8q11icwhhbwfl20ali3w5mwf4-stumpwm-22.11' -> 
'/gnu/store/azj1nchh8b9h9bssyzs15qbpd9p1zf7h-stumpwm-22.11'...
successfully built /gnu/store/bsxspzrhfwsl4qp0n01mgcaqcp1934dj-stumpwm-22.11.drv
successfully built /gnu/store/bsxspzrhfwsl4qp0n01mgcaqcp1934dj-stumpwm-22.11.drv
successfully built /gnu/store/bsxspzrhfwsl4qp0n01mgcaqcp1934dj-stumpwm-22.11.drv
/gnu/store/r4sc5ylh2g30zgr10q35phd80cb3llqy-stumpwm-22.11-lib
/gnu/store/azj1nchh8b9h9bssyzs15qbpd9p1zf7h-stumpwm-22.11

# ^ here 50-stumpwm.conf refers to r4sc5ylh..., as it should
# whereas
# below 50-stumpwm.conf refers to y8fd8yirq. Notice how stumpwm is
# grafted differently

richard@gibraltar ~/code/cloned/guix [env]$ ./pre-inst-env guix build 
sbcl-stumpwm-cpu
The following grafts will be made:
/gnu/store/w8fbnjz3a8rzigldazhqn75v1ncrwnmr-sbcl-stumpwm-cpu-0.0.1-5.4613a95.drv
/gnu/store/w5027r2xlf88pfafw9dsx38cya01la83-stumpwm-22.11.drv
applying 5 grafts for stumpwm-22.11 ...
grafting '/gnu/store/j73w1n1sf3gqgx8qx3cx9csbrndddq0b-stumpwm-22.11-lib' -> 
'/gnu/store/y8fd8yirq8n87sl7pv2wliwihrrbv820-stumpwm-22.11-lib'...
successfully built /gnu/store/w5027r2xlf88pfafw9dsx38cya01la83-stumpwm-22.11.drv
applying 2 grafts for sbcl-stumpwm-cpu-0.0.1-5.4613a95 ...
grafting 
'/gnu/store/r3l0dxxlcdh73092q9fmjj629klayxhq-sbcl-stumpwm-cpu-0.0.1-5.4613a95' 
-> 
'/gnu/store/nvp9y9qgpv4w22dqbjmdyc0l41gymims-sbcl-stumpwm-cpu-0.0.1-5.4613a95'...
successfully built 
/gnu/store/w8fbnjz3a8rzigldazhqn75v1ncrwnmr-sbcl-stumpwm-cpu-0.0.1-5.4613a95.drv
/gnu/store/nvp9y9qgpv4w22dqbjmdyc0l41gymims-sbcl-stumpwm-cpu-0.0.1-5.4613a95
--8<---cut here---end--->8---

Now that there are two distinct derivations for two distinct stumpwm:lib
outputs, we can look at the builders.

--8<---cut here---start->8---
;; guix build stumpwm, stumpwm graft builder
(begin (use-modules (guix build graft) (guix build utils) (ice-9 match))
   (define %outputs (list (cons "lib" ((@ (guile) getenv) "lib")) (cons 
"out" ((@ (guile) getenv) "out"
   (begin (setenv "GUIX_LOCPATH" 
"/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-2.35/lib/locale")
  (setlocale LC_ALL "en_US.utf8"))
   (let* ((old-outputs (quote (("lib" . 
"/gnu/store/j73w1n1sf3gqgx8qx3cx9csbrndddq0b-stumpwm-22.11-lib")
   ("out" . 
"/gnu/store/2rd3r0m8q11icwhhbwfl20ali3w5mwf4-stumpwm-22.11"
  (mapping (append (quote 
(("/gnu/store/hqxzgbbbnxl8l9q8bcsvzvmyw1mjws4r-zstd-1.5.2-lib" . 
"/gnu/store/x35wy730jwwmwwypvzy2nmqvcb3hc3ba-zstd-1.5.2-lib")
   
("/gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib" . 
"/gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib")
   
("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35" . 
"/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35")
   
("/gnu/store/hbzlh3zjss4w80jscwfkivpyqc2sqbm3-sbcl-alexandria-1.4-0.009b7e5" . 
"/gnu/store/p8iagp15zzj5ivh3j8443jjpq6wmmzpw-sbcl-alexandria-1.4-0.009b7e5")
   
("/gnu/store/jd34ay8cyyl2dag62n94m15gg1b4s1sw-sbcl-2.4.0" . 
"/gnu/store/vj5jdgz6dajq25f6arjw976h6awwblgh-sbcl-2.4.0")
   
("/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16" . 

bug#70349: Clang fails to communicate RUNPATH?

[Liliana Marie Prikler]

Hi Ludo,

Am Samstag, dem 25.05.2024 um 11:26 +0200 schrieb Ludovic Courtès:
> Could this be an issue specific to ‘meson-build-system’?
> 
> For instance, this works fine (both mpfr and mpc use
> ‘gnu-build-system’):
> 
>   guix build mpc --with-c-toolchain=mpfr=clang-toolchain
> 
> If we add this to the example you posted:
> 
>    (arguments
>     (list #:phases #~(modify-phases %standard-phases
>    (add-after 'unpack 'debug-ld-wrapper
>  (lambda _
>    (setenv "GUIX_LD_WRAPPER_DEBUG"
> "yes"))
> 
> … we see:
> 
> --8<---cut here---start->8---
> ld-wrapper: library search path:
> ("/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.."
> "/gnu/store/inpy5mz35fwvclynpag5gsp6d1hflfsz-meson-1.1.0/lib"
> "/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib"
> "/gnu/store/j8wlfmlmfvpbza6is9wv9xsd8psrxn00-bzip2-1.0.8/lib"
> "/gnu/store/gr0sy0m1mv36qv54idm6cn10l3mngshq-file-5.44/lib"
> "/gnu/store/hc05d76f1j3iz3v2bs5jz4fpljl1r4dj-gawk-5.2.1/lib"
> "/gnu/store/6k1yys9wqrfn4y41ic1win8gpnimncwj-xz-5.2.8/lib"
> "/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-
> 2.35/lib" "/gnu/store/0irvg0gvvfwagdjckigvr4g8xap94y1j-clang-
> toolchain-18.1.5/lib")
> ld-wrapper: libraries linked:
> ("/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-
> 9.1.0/lib/libfmt.so" "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-
> gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-
> gnu/11.3.0/../../../libstdc++.so"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libm.so"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libgcc_s.so"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libgcc_s.so")
> ld-wrapper: invoking `/gnu/store/zh4x65snfis7svs6906gj1z8i7dx2j3m-
> binutils-2.38/bin/ld' with ("--eh-frame-hdr" "-m" "elf_x86_64" "-pie"
> "-dynamic-linker" "//gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-
> glibc-2.35/lib/ld-linux-x86-64.so.2" "-o" "hello"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/Scrt1.o"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/crti.o"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/crtbeginS.o" "-
> L/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0" "-
> L/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "-
> L/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.." "-
> L/gnu/store/inpy5mz35fwvclynpag5gsp6d1hflfsz-meson-1.1.0/lib" "-
> L/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib" "-
> L/gnu/store/j8wlfmlmfvpbza6is9wv9xsd8psrxn00-bzip2-1.0.8/lib" "-
> L/gnu/store/gr0sy0m1mv36qv54idm6cn10l3mngshq-file-5.44/lib" "-
> L/gnu/store/hc05d76f1j3iz3v2bs5jz4fpljl1r4dj-gawk-5.2.1/lib" "-
> L/gnu/store/6k1yys9wqrfn4y41ic1win8gpnimncwj-xz-5.2.8/lib" "-
> L/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-
> 2.35/lib" "-L/gnu/store/0irvg0gvvfwagdjckigvr4g8xap94y1j-clang-
> toolchain-18.1.5/lib" "hello.p/hello.cpp.o" "--as-needed" "--no-
> undefined" "-rpath=/gnu/store/g9wxj9a27jhnxa40zafh0ff33dd8906y-why-
> hello-0/lib" "-rpath" "/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-
> fmt-9.1.0/lib" "-rpath-link"
> "/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib" "--start-
> group" "/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-
> 9.1.0/lib/libfmt.so" "--end-group" "-lstdc++" "-lm" "-lgcc_s" "-lgcc"
> "-lc" "-lgcc_s" "-lgcc" "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-
> gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/crtendS.o"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/crtn.o"
> "-rpath" "/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib"
> "-rpath" "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.." "-rpath"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "-rpath"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.." "-rpath"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "-rpath"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../..")
> 
> […]
> 
> starting phase `shrink-runpath'
> /gnu/store/g9wxj9a27jhnxa40zafh0ff33dd8906y-why-hello-0/bin/hello:
> stripping RUNPATH to ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-
> glibc-2.35/lib") (removed
> 

bug#64734: Recursive hackage import fails

[Saku Laesvuori via Bug reports for GNU Guix]

close 64734
thanks


signature.asc
Description: PGP signature

bug#64734: Recursive hackage import fails

[Saku Laesvuori via Bug reports for GNU Guix]

> Hi,
> 
> > $ guix import hackage linear-generics --recursive
> 
> have you ever figured out what caused this?

Yes, I fixed it in https://issues.guix.gnu.org/67564 so this issue can
now be closed.

- Saku


signature.asc
Description: PGP signature