bug#74941: Acknowledgement (Guix Pull Failure: Git SSL Error, Directory Cleanup Error, and Software Heritage API Timeout)

[outlook user]

@@ +70,32 @@
1009:8  9 (call-with-temporary-directory _)
1330:8 15 (call-with-build-handler # …)
1353:3 16 (_)
1685:16  0 (raise-exception _ #:continuable? _)
1685:16  1 (raise-exception _ #:continuable? _)
1752:10 19 (with-exception-handler _ _ #:unwind? _ # _)
262:4  2 (tls-wrap # "archive.software…" …)
271:22  4 (call "https://archive.softwareheritage.org/api/1/vaul…"; …)
422:18 12 (latest-channel-instance # …)
433:2 10 (_ git-error #< code: -1 message: "failed to…>)
435:10  8 (_ "/tmp/guix-directory.UzAWep")
482:29  3 (http-request "https://archive.softwareheritage.org/ap…"; …)
559:23 13 (latest-channel-instances # …)
561:29 11 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _ …)
689:37 18 (thunk)
722:18  5 (loop _)
739:8  7 (call-with-temporary-directory _)
752:5  6 (_ "/tmp/guix-directory.Qy8Dq0")
839:4 17 (call-with-status-report _ _)
874:26 14 (_)
Backtrace:
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In guix/channels.scm:
In guix/git.scm:
In guix/scripts/pull.scm:
In guix/status.scm:
In guix/store.scm:
In guix/swh.scm:
In guix/utils.scm:
In ice-9/boot-9.scm:
In web/client.scm:
Throw to key `gnutls-error' with args `(# handshake)'.


De : GNU bug Tracking System 
Envoyé : mercredi 18 décembre 2024 11:35
À : outlook user 
Objet : bug#74941: Acknowledgement (Guix Pull Failure: Git SSL Error, Directory 
Cleanup Error, and Software Heritage API Timeout)
 
Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@gnu.org

If you wish to submit further information on this problem, please
send it to 74...@debbugs.gnu.org.

Please do not send mail to help-debb...@gnu.org unless you wish
to report a problem with the Bug-tracking system.

--
74941: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74941
GNU Bug Tracking System
Contact help-debb...@gnu.org with problems

bug#74952: [PATCH] guix-install.sh: Use "command -v nologin" instead of "which nologin".

[Leo Famulari]

On Wed, Dec 18, 2024 at 09:35:27PM +0100, Simon Josefsson via Bug reports for 
GNU Guix wrote:
> Hi!
> 
> In a small container image, I do not have the 'which' tool installed.  I
> believe 'command -v' is always available since it is /bin/sh standard.
> How about changing the idiom for user/group additions from 'which' to
> 'command -v'?  See attached patch.

Agreed, I don't think we need to require `which` here.

It can also be removed from REQUIRE in 'etc/guix-install.sh'.

bug#74912: Shepherd: Growing number of user shepherds when relogging

[Ludovic Courtès]

Hello,

Jake  skribis:

> I think I'm experiencing a bug in Shepherd since version 1.0.
> Whenever I log out and log back in again, my user shepherd from the
> previous login session is still present, and a new user shepherd spawns for
> the current login session.
> So relogging N times results in N+1 user shepherds.

I have a user shepherd via Guix Home and I experience the same problem
(though because I rarely log out it’s not really annoying :-)).

I suspect the problem has to do with how Guix Home determines whether or
not it should launch shepherd, but I haven’t checked yet.

Thanks for reporting the issue,
Ludo’.

bug#74949: guix describe crash if HOME is unset OR /etc/passwd is missing

[Simon Josefsson via Bug reports for GNU Guix]

Hi

I get the backtrace below.  Setting either HOME to something, or adding
an entry to /etc/passwd for the running user, silences this.

I don't think it should fail like this, should it?

Is a reasonable behaviour to assume HOME means "/" when unset?

How to handle missing /etc/passwd entries probably depends on what the
code wants to use it for.

/Simon

jas@kaka:~/src/guix-container$ podman run --entrypoint /bin/sh -it 
registry.gitlab.com/debdistutils/guix/container:latest
sh-5.1# guix describe
Backtrace:
In ice-9/boot-9.scm:
   222:29 19 (map1 _)
   222:29 18 (map1 _)
   222:29 17 (map1 _)
   222:29 16 (map1 _)
   222:29 15 (map1 _)
   222:29 14 (map1 _)
   222:29 13 (map1 _)
   222:29 12 (map1 (((guix packages)) ((guix profiles)) ((guix #)) ?))
   222:17 11 (map1 (((guix profiles)) ((guix derivations)) ((# #)) ?))
  3327:17 10 (resolve-interface (guix profiles) #:select _ #:hide _ # ?)
In ice-9/threads.scm:
390:8  9 (_ _)
In ice-9/boot-9.scm:
  3253:13  8 (_)
In ice-9/threads.scm:
390:8  7 (_ _)
In ice-9/boot-9.scm:
  3544:20  6 (_)
   2836:4  5 (save-module-excursion #)
  3564:26  4 (_)
In unknown file:
   3 (primitive-load-path "guix/profiles" #)
In guix/profiles.scm:
  2388:23  2 (_)
In guix/utils.scm:
  1071:48  1 (xdg-directory _ "/.config" #:ensure? _)
In unknown file:
   0 (getpw 0)

ERROR: In procedure getpw:
In procedure getpw: entry not found
sh-5.1# export HOME=/
sh-5.1# guix describe
  guix 790c9ff
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 790c9ffe596e3deabf175e030adee5fb706aa981
sh-5.1# exit
jas@kaka:~/src/guix-container$ podman run --entrypoint /bin/sh -it 
registry.gitlab.com/debdistutils/guix/container:latest
sh-5.1# guix describe
Backtrace:
In ice-9/boot-9.scm:
   222:29 19 (map1 _)
   222:29 18 (map1 _)
   222:29 17 (map1 _)
   222:29 16 (map1 _)
   222:29 15 (map1 _)
   222:29 14 (map1 _)
   222:29 13 (map1 _)
   222:29 12 (map1 (((guix packages)) ((guix profiles)) ((guix #)) ?))
   222:17 11 (map1 (((guix profiles)) ((guix derivations)) ((# #)) ?))
  3327:17 10 (resolve-interface (guix profiles) #:select _ #:hide _ # ?)
In ice-9/threads.scm:
390:8  9 (_ _)
In ice-9/boot-9.scm:
  3253:13  8 (_)
In ice-9/threads.scm:
390:8  7 (_ _)
In ice-9/boot-9.scm:
  3544:20  6 (_)
   2836:4  5 (save-module-excursion #)
  3564:26  4 (_)
In unknown file:
   3 (primitive-load-path "guix/profiles" #)
In guix/profiles.scm:
  2388:23  2 (_)
In guix/utils.scm:
  1071:48  1 (xdg-directory _ "/.config" #:ensure? _)
In unknown file:
   0 (getpw 0)

ERROR: In procedure getpw:
In procedure getpw: entry not found
sh-5.1# echo 'root:x:0:0:root:/root:/bin/bash' > /etc/passwd
sh-5.1# guix describe
  guix 790c9ff
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 790c9ffe596e3deabf175e030adee5fb706aa981
sh-5.1# 


signature.asc
Description: PGP signature

bug#74912: Shepherd: Growing number of user shepherds when relogging

[Tomas Volf]

Ludovic Courtès  writes:

> Hello,
>
> Jake  skribis:
>
>> I think I'm experiencing a bug in Shepherd since version 1.0.
>> Whenever I log out and log back in again, my user shepherd from the
>> previous login session is still present, and a new user shepherd spawns for
>> the current login session.
>> So relogging N times results in N+1 user shepherds.
>
> I have a user shepherd via Guix Home and I experience the same problem
> (though because I rarely log out it’s not really annoying :-)).
>
> I suspect the problem has to do with how Guix Home determines whether or
> not it should launch shepherd, but I haven’t checked yet.

When you have another login session active when you log out and in
again, new shepherd is *not* spawned.  I am guessing here but probably
last log out causes XDG_RUNTIME_DIR to be removed (by elogind in my
case), so on log in there is no /run/user/$UID/on-first-login-executed,
so it runs again and starts the shepherd.

But even if that would be solved, since the runtime directory was nuked,
there is no shepherd socket around anymore, so the (still running)
shepherd from previous login session cannot be contacted by herd.

Of the top of my head I can think of two possible solutions:

1. Stop the shepherd on log out.  So as we have on-first-login, we would
have on-last-logout.  I have no idea how to implement that.  Maybe we
could use ~/.bash_logout?  Or some PAM thing?

2. Shepherd could shutdown gracefully when the control socket is deleted
from the file system.  It is arguable how useful running shepherd is
without the socket anyway.

Any other ideas?

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.


signature.asc
Description: PGP signature

bug#74948: guix pack docker environment variable setting

[Simon Josefsson via Bug reports for GNU Guix]

Hi

I believe the guix-pack docker format allows setting environment
variables in the resulting image, is that right?

I can't find any way to set them using the `guix pack` tool, am I
missing it?

Would a new `guix pack --setenv HOME=/` parameter be useful?

Such a parameter could be docker-specific and documented in
--help-docker-format.  If other formats support setting environment
variables too, it could instead be a normal `guix pack` parameter.
Maybe AppImage support setting environment variables too?

Thanks,
/Simon


signature.asc
Description: PGP signature

bug#74877: Close the issue.

[Adam]

It seems to be working for me now.

bug#74942: Computing the guix self derivations can require builds

[Christopher Baines]

I wasn't aware of a issue for this, so I'm creating one. I did send some
patches in an attempt to fix this to #61363.

The derivations used by guix pull, guix time-machine and other
operations work differently to package derivations. I might have
understood exactly how in the past, but unfortunately I've forgotten the
details. I think the rough summary is that in contrast to packages, you
can't view the guix self derivations grafting as a transformation on the
built outputs, but rather that transformation is somehow muddled up with
computing the derivations.

As noted in #61363, the data service is affected by this since it relies
on computing derivations being inexpensive to do, and having to
potentially perform many builds for some arbitrary architecture when
attempting to compute derivations can be very expensive. Note that since
the bad behaviour here is dependent on grafts, this only happens when
packages involved in the guix self derivations have replacements.

I think there's probably other implications of this as well, substitute
servers don't store grafted outputs generally, although I think the use
of grafting here probably means that they are storing and providing
substitutes for grafted outputs.

However this is fixed, I think you'd need to end up with two
properties. Computing the derivations doesn't require performing builds,
and grafting is a transformation on the outputs of those computed
derivations.


signature.asc
Description: PGP signature

bug#74941: Guix Pull Failure: Git SSL Error, Directory Cleanup Error, and Software Heritage API Timeout

[outlook user]

```
$ guix pull --channels=$PATH/channels.scm
_rmtree_safe_fd(dirfd, fullname, onerror)
_rmtree_safe_fd(fd, path, onerror)
_shutil.rmtree(name, onerror=onerror)
do = self.iter(retry_state=retry_state)
During handling of the above exception, another exception occurred:
File "/opt/swh/.local/lib/python3.10/site-packages/swh/core/api/__init__.py", 
line 196, in meth_
File "/opt/swh/.local/lib/python3.10/site-packages/swh/core/api/__init__.py", 
line 356, in _post
File "/opt/swh/.local/lib/python3.10/site-packages/swh/core/api/__init__.py", 
line 433, in raise_for_status
File "/opt/swh/.local/lib/python3.10/site-packages/swh/core/api/__init__.py", 
line 443, in _decode_response
File "/opt/swh/.local/lib/python3.10/site-packages/swh/storage/api/client.py", 
line 45, in raise_for_status
File 
"/opt/swh/.local/lib/python3.10/site-packages/swh/storage/proxies/retry.py", 
line 81, in newf
File "/opt/swh/.local/lib/python3.10/site-packages/swh/vault/cookers/base.py", 
line 135, in cook
File 
"/opt/swh/.local/lib/python3.10/site-packages/swh/vault/cookers/git_bare.py", 
line 155, in prepare_bundle
File 
"/opt/swh/.local/lib/python3.10/site-packages/swh/vault/cookers/git_bare.py", 
line 168, in prepare_bundle
File 
"/opt/swh/.local/lib/python3.10/site-packages/swh/vault/cookers/git_bare.py", 
line 418, in load_objects
File 
"/opt/swh/.local/lib/python3.10/site-packages/swh/vault/cookers/git_bare.py", 
line 647, in load_directories
File "/opt/swh/.local/lib/python3.10/site-packages/tenacity/__init__.py", line 
185, in reraise
File "/opt/swh/.local/lib/python3.10/site-packages/tenacity/__init__.py", line 
336, in wrapped_f
File "/opt/swh/.local/lib/python3.10/site-packages/tenacity/__init__.py", line 
376, in iter
File "/opt/swh/.local/lib/python3.10/site-packages/tenacity/__init__.py", line 
418, in exc_check
File "/opt/swh/.local/lib/python3.10/site-packages/tenacity/__init__.py", line 
475, in __call__
File "/opt/swh/.local/lib/python3.10/site-packages/tenacity/__init__.py", line 
478, in __call__
File "/usr/local/lib/python3.10/concurrent/futures/_base.py", line 403, in 
__get_result
File "/usr/local/lib/python3.10/concurrent/futures/_base.py", line 451, in 
result
File "/usr/local/lib/python3.10/shutil.py", line 658, in _rmtree_safe_fd
File "/usr/local/lib/python3.10/shutil.py", line 662, in _rmtree_safe_fd
File "/usr/local/lib/python3.10/shutil.py", line 664, in _rmtree_safe_fd
File "/usr/local/lib/python3.10/shutil.py", line 725, in rmtree
File "/usr/local/lib/python3.10/tempfile.py", line 864, in _rmtree
File "/usr/local/lib/python3.10/tempfile.py", line 878, in __exit__
File "/usr/local/lib/python3.10/tempfile.py", line 882, in cleanup
guix pull: erreur : Erreur Git : SSL error: error:0A000119:SSL 
routines::decryption failed or bad record mac
guix pull: erreur : Erreur Git : SSL error: syscall failure: Connexion 
ré-initialisée par le correspondant
Mise à jour du canal « $CANAL » depuis le dépôt Git « https://$PATH.git »...
onerror(os.rmdir, fullname, sys.exc_info())
os.rmdir(entry.name, dir_fd=topfd)
OSError: [Errno 39] Directory not empty: 'c7'
Over $NUMBER remaining
raise exception from None
raise retry_exc.reraise()
raise self._exception
raise self.last_attempt.result()
raw_manifests = self.storage.directory_get_raw_manifest(obj_ids)
réception des objets  $NUMBER% ▕█▍  ▏
result = action(retry_state)
result = fn(*args, **kwargs)
return copy(f, *args, **kw)
return getattr(storage, attribute_name)(*args, **kwargs)
return self.__get_result()
return self._decode_response(response)
return self._post(meth._endpoint_path, post_data)
self._rmtree(self.name, ignore_errors=self._ignore_cleanup_errors)
self.cleanup()
self.load_directories(directory_ids)
self.load_objects()
self.prepare_bundle()
self.raise_for_status(response)
super().raise_for_status(response)
SWH vault: failure: Internal Server Error. This incident will be reported.
SWH vault: Processing...
SWH vault: Processing... $NUMBER objects processed
SWH vault: requested bundle cooking, waiting for completion...
SWH vault: retrying...
SWH: found revision $HASH with directory at 
'https://archive.softwareheritage.org/api/1/directory/$HASH2/'
swh.core.api.RemoteException: 
The full error was:
Traceback (most recent call last):
with tempfile.TemporaryDirectory(prefix="swh-vault-gitbare-") as workdir:
```

bug#70581: PHP, glibc, and CVE-2024-2961

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> * gnu/packages/base.scm (%glibc-patches): New variable.
> (glibc) [source]: Use it.
> [properties]: Mark CVE-2024-2961 as hidden (resolved).
> [replacement]: Add field to graft with...
> (glibc/fixed): ... this new package.
>
> Fixes: 
> Change-Id: I6dd70b0e157283925824348f180c466c2f6387c9

I’m late to the party, apologies! (I was Cc’d, despite being on
‘core-packages’, weird.)

> +  (patches (map search-patch
> +(fold (cut delete <...>)
> +  %glibc-patches
> +  '("glibc-2.39-git-updates.patch"

Or: (delete "glibc-2.39-git-updates.patch" (search-patches %glibc-patches)).

Thank you!

Ludo’.

bug#74943: sshd: no hostkeys available -- exiting

[Christopher Baines]

I'm having trouble with ssh after reconfiguring, in /var/log/messages I
see an error regarding hostkeys. The files seem to be there though, I've
tried regenerating the keys but that made no difference.


signature.asc
Description: PGP signature

bug#70581: PHP, glibc, and CVE-2024-2961

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

[...]

>> +  (patches (map search-patch
>> +(fold (cut delete <...>)
>> +  %glibc-patches
>> +  '("glibc-2.39-git-updates.patch"
>
> Or: (delete "glibc-2.39-git-updates.patch" (search-patches %glibc-patches)).

It doesn't seem to work the way you'd intuitively expect, because
search-patches is syntax, and %glibc-patches is a list.  So you at least
need the map and search-patch procedure:

--8<---cut here---start->8---
(delete "glibc-2.39-git-updates.patch" (map search-patch %glibc-patches)).
--8<---cut here---end--->8---

And then the delete has no effect because 'search-path' returns absolute
paths, so the patch to delete is now something like
'/home/maxim/src/guix/gnu/packages/patches/glibc-2.39-git-updates.patch',
for example.

-- 
Thanks,
Maxim

bug#74832: guix copy incorrectly assumes port is 22

[Maxim Cournoyer]

Hi Tomas,

Tomas Volf <~@wolfsden.cz> writes:

> After update to guile-ssh 0.18.0, options passed to the `make-session'
> procedure now take precedence over the configuration file.  In few places we
> however had code like `(or port 22)' leading to (in absence of alternative
> port being specified) always using port 22, ignoring the configuration file.
>
> Due to that for example following command fails:
>
> guix copy hello --to=name
>
> Name is reachable, but ssh server listens on port .  That is correctly
> configured in ~/.ssh/config, and the invocation used to succeed until the
> upgrade.

That is curious, because I had reported the exact same problem 6 years
ago (!) in bug#33266 (now merged with this one), with a similar
solution:

--8<---cut here---start->8---
Subject: [PATCH] Revert "copy: Default to port 22."

This reverts commit cc1dfc202f2fefb6c2eb9467d1fc90a9154550c9.  Specifying a
default port had the undesirable effect of disregarding a port specification
for a given host in the ~/.ssh/config that would otherwise have been honored
at the time `open-ssh-session' calls the `session-parse-config!' method.

In any case, `make-session' will default the port value of the created session
to 22 if left unspecified.
--8<---cut here---end--->8---

But, Ludovic had mentioned that without it,

--8<---cut here---start->8---
[...] "%p" would be "0" when using "ProxyCommand" in ~/.ssh/config.
--8<---cut here---end--->8---

So it'd perhaps regress in another way; I want to retry the test I had
done then but I need to setup at least a VM with SSH to test.  If you
can beat me to that, all the better :-).

-- 
Thanks,
Maxim

bug#74952: [PATCH] guix-install.sh: Use "command -v nologin" instead of "which nologin".

[Simon Josefsson via Bug reports for GNU Guix]

Hi!

In a small container image, I do not have the 'which' tool installed.  I
believe 'command -v' is always available since it is /bin/sh standard.
How about changing the idiom for user/group additions from 'which' to
'command -v'?  See attached patch.

/Simon
From 2bc261126a84a4a9a33acea9f107ad4bdef929d0 Mon Sep 17 00:00:00 2001
From: Simon Josefsson 
Date: Wed, 18 Dec 2024 21:30:10 +0100
Subject: [PATCH] guix-install.sh: Use "command -v nologin" instead of "which
 nologin".

* doc/guix.texi (Build Environment Setup): Change.
* etc/guix-install.sh (sys_create_build_user): Likewise.
* gnu/machine/digital-ocean.scm (guix-infect): Update.
---
 doc/guix.texi | 6 +++---
 etc/guix-install.sh   | 4 ++--
 gnu/machine/digital-ocean.scm | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index f7b7569887..46ceb71cde 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -944,9 +944,9 @@ Bash syntax and the @code{shadow} commands):
 # groupadd --system guixbuild
 # for i in $(seq -w 1 10);
   do
-useradd -g guixbuild -G guixbuild   \
--d /var/empty -s $(which nologin)   \
--c "Guix build user $i" --system\
+useradd -g guixbuild -G guixbuild  \
+-d /var/empty -s $(command -v nologin) \
+-c "Guix build user $i" --system   \
 guixbuilder$i;
   done
 @end example
diff --git a/etc/guix-install.sh b/etc/guix-install.sh
index f07b2741bb..44b3e62ed2 100755
--- a/etc/guix-install.sh
+++ b/etc/guix-install.sh
@@ -435,12 +435,12 @@ sys_create_build_user()
 if id "guixbuilder${i}" &>/dev/null; then
 _msg "${INF}user is already in the system, reset"
 usermod -g guixbuild -G guixbuild${KVMGROUP} \
--d /var/empty -s "$(which nologin)" \
+-d /var/empty -s "$(command -v nologin)" \
 -c "Guix build user $i" \
 "guixbuilder${i}";
 else
 useradd -g guixbuild -G guixbuild${KVMGROUP} \
--d /var/empty -s "$(which nologin)" \
+-d /var/empty -s "$(command -v nologin)" \
 -c "Guix build user $i" --system\
 "guixbuilder${i}";
 _msg "${PAS}user added "
diff --git a/gnu/machine/digital-ocean.scm b/gnu/machine/digital-ocean.scm
index d0f0bbe4cb..5fa679ab8c 100644
--- a/gnu/machine/digital-ocean.scm
+++ b/gnu/machine/digital-ocean.scm
@@ -260,7 +260,7 @@ (define os
 groupadd --system guixbuild
 for i in `seq -w 1 10`; do
useradd -g guixbuild -G guixbuild \
-   -d /var/empty -s `which nologin`  \
+   -d /var/empty -s `command -v nologin`  \
-c \"Guix build user $i\" --system  \
guixbuilder$i;
 done;
-- 
2.46.0



signature.asc
Description: PGP signature

bug#60608: keras is broken –> package bazel?

[Sharlatan Hellseher]

Hi,

I'm in a limbo to upgrade https://github.com/spf13/afero, which requires
go-google-golang-org-api, which relays on auto-generated code in
https://github.com/googleapis/go-genproto which was built from
https://github.com/googleapis/googleapis/ with Bazel, which we don't
have in Guix (yet?)

Any plan to have Bazel in main Guix git repository or it's not
compatibly license wise?

--
Oleg


signature.asc
Description: PGP signature

bug#73979: validate-runpath phases fails when binaries linked to package's own libraries

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> There's a common pattern in packages where the validate-runpath phases
>> fail, which is when a binary is linked to libraries provided by the same
>> package.  In this case, our ld-wrapper script appears to not bake the
>> required runpath, which then fails the validate-runpath phase.
>>
>> When this happens, the common workaround is adding link directives such
>> as (string-append "-Wl,-rpath=" #$output "/lib/subdir") to LDFLAGS (see
>> for example the 'dmraid' package definition).
>
> I believe this is the exception, not the rule, and I see that as a bug
> in the build system of those packages.  (As a counterexample, any
> package built with Automake/Libtool is fine.)

Interesting.  I had not considered that point of view (that the build
system/usage of it could be at cause) enough; I think you are right.

[...]

>> One idea could be to allow creating rpaths to %BUILD-DIRECTORY prefixed
>> libraries, and have these entries refined in a phase that would run
>> after the package is installed, before the validate-runpath phase runs.
>> It could be called e.g. 'sanitize-runpath' and proceed along those
>> lines:
>>
>> Scan for RUNPATH entries being prefixed by %BUILD-DIRECTORY; attempt to
>> have them rewritten to libraries (.so) found under the package's own
>> libdir library prefix (at any depth), including a potential "lib"
>> output.  In case it couldn't, it would error.
>>
>> Does that sound feasible?
>
> It might be feasible, but I think it’s the wrong approach.  The problem
> here is in the build system itself; Guix is “not at fault”, so to speak.
>
> Nevertheless, from a practical viewpoint, whether or not Guix is at
> fault is largely irrelevant.  So the question becomes: how widespread is
> this issue?  If it’s widespread, can it be solved at a (guix
> build-system …) level?  (For instance, I think ‘cmake-build-system’ and
> ‘meson-build-system’ do the right things in that regard.)

I think CMake nowadays doesn't relink but uses some ELF-patching code to
patch the installed binaries in place (which is faster than relinking);
that would mean our ld-wrapper doesn't get involved in these case and we
depend on RPATH being enabled in the CMake build system, which it
normally is unless the package set CMAKE_SKIP_RPATH to false.  I guess
Meson is also patching binaries for speed.

> If it’s a per-package issue, which seems to be the case given what you
> describe, then I would fix it locally in this package, for instance by
> passing ‘-Wl,-rpath=$ORIGIN/../lib’ or whatever is convenient.

There doesn't seem to be so many occurrences; grepping for
'-Wl,-rpath.*output' I find 73 problematic packages.  I've found one
place where this happens is for Cythonized shared objects; this produced
shared objects linked to a library of the build directory, and is not
concerned with installing so nothing rewrites the runpath entries to
their correct installed location.  One such example is openpmix; the
issue was dismissed as "we expect people to set LD_LIBRARY_PATH" [0].

[0]  https://github.com/openpmix/openpmix/issues/3457

Anyway, sorry for the wall of text.  Closing!

-- 
Thanks,
Maxim