bug#66866: Grafting breaks cross-compilation

[Ludovic Courtès]

Hi,

dan  skribis:

> I spent some time digging into the rabbit hole.  After changing 
> the lower function of the copy-build-system to look more like the 
> lower function of the gnu-build-system, I'm able to cross compile 
> alsa-lib without the --no-grafts flag.  The changes I made are 
> like:
>
> diff --git a/guix/build-system/copy.scm 
> b/guix/build-system/copy.scm
> index d58931b33c..74304b4bfb 100644
> --- a/guix/build-system/copy.scm
> +++ b/guix/build-system/copy.scm
> @@ -66,13 +66,13 @@ (define* (lower name
>(bag
>  (name name)
>  (system system)
> -(host-inputs `(,@(if source
> +(build-inputs `(,@(if source
>   `(("source" ,source))
>   '())
> -   ,@inputs
> +   ,@native-inputs
> ;; Keep the standard inputs of 
> 'gnu-build-system'.
> ,@(standard-packages)))
> -(build-inputs native-inputs)
> +(host-inputs inputs)
>  (outputs outputs)
>  (build copy-build)
>  (arguments (strip-keyword-arguments private-keywords 
>  arguments
>
> Can we put everything inside build-inputs?  From my understanding, 
> copy-build-system shouldn't care about cross-compilation at all.

Intuitively, if ‘copy-build-system’ is about copying
architecture-independent files, then it should do the same thing whether
or not we are cross-compiling.

However, users can and do add phases whose result is
architecture-dependent.  Small sample:

  • ‘desec-certbot-hook’ captures a reference to curl, so it would get
the wrong one when cross-compiling if we assumed build-inputs =
host-inputs.

  • ‘chez-scheme-for-racket-bootstrap-bootfiles’ builds stuff when
cross-compiling.  Philip, could you explain the intent and what you
expect here?

So it would seem we can’t just assume everything is a native input like
https://issues.guix.gnu.org/70492 does.

Now, as David and you found out, the use of inputs in
build-system/copy.scm:lower is bogus.  It seems that it can be fixed by
following the intended definition of build/host inputs, as David
suggested:

diff --git a/guix/build-system/copy.scm b/guix/build-system/copy.scm
index d58931b33c2..cf0214320bf 100644
--- a/guix/build-system/copy.scm
+++ b/guix/build-system/copy.scm
@@ -66,13 +66,13 @@ (define* (lower name
   (bag
 (name name)
 (system system)
-(host-inputs `(,@(if source
+(build-inputs `(,@(if source
  `(("source" ,source))
  '())
-   ,@inputs
-   ;; Keep the standard inputs of 'gnu-build-system'.
-   ,@(standard-packages)))
-(build-inputs native-inputs)
+,@native-inputs
+;; Keep the standard inputs of 'gnu-build-system'.
+,@(standard-packages)))
+(host-inputs inputs)
 (outputs outputs)
 (build copy-build)
 (arguments (strip-keyword-arguments private-keywords arguments

But wait! That’s all theoretical because the bag always has (target #f)
and ‘copy-build’ bundles build and host inputs together, as if doing a
native build.

So it seems like https://issues.guix.gnu.org/70492 (putting everything
in ‘build-inputs’) is OK, after all.

But still, there seem to be some expectation that ‘copy-build-system’
can support cross-compilation for real, so maybe we should add a
‘copy-cross-build’ procedure in addition to the patch above.

Thoughts?

Ludo’.

bug#70704: make maintainer-clean deletes VC'd file doc/he-config-bare-bones.scm

[Richard Sent]

Hi Guix!

Running '$ make maintainer-clean' in the guix repo deletes the
version-controlled file doc/he-config-bare-bones.scm.

Documentation for the maintainer-clean target states:

> Delete almost everything that can be reconstructed with this Makefile.

Either this file is constructed by the Makefile and shouldn't be version
controlled, or it isn't constructed by the Makefile and shouldn't be
deleted. (99% odds it's the latter.)

I bet it just needs to be added to EXTRA_DIST in doc/local.mk, but I
don't fully understand the doc subdirectory or what the effects of that
might be.

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

bug#70663: nss@3.99 is really hard to build

[Christopher Baines]

Maxim Cournoyer  writes:

> Hi Chris,
>
> Christopher Baines  writes:
>
>> nss@3.99 is really hard to build, it's so hard and so important that
>> data.guix.gnu.org is still after two days trying to process [1]. I say
>> so important because you have to build nss@3.99 to compute the channel
>> instance derivations for Guix.
>
> I agree that the nss test suite takes a ridiculous amount of time to run
> (multiple hours on a fast machine IIRC).  Are we missing a '--fast' test
> flag or something to make it run in a more reasonable amount of time?

I did read some of the all.sh script used for the tests and there is
some environment variables you can set here:

  https://github.com/nss-dev/nss/blob/master/tests/all.sh#L70-L82

It seems like there are 4 "cycles", maybe we could just run the standard
cycle or at least check how long they each take.


signature.asc
Description: PGP signature

bug#70663: nss@3.99 is really hard to build

[Maxim Cournoyer]

Hi Chris,

Christopher Baines  writes:

> nss@3.99 is really hard to build, it's so hard and so important that
> data.guix.gnu.org is still after two days trying to process [1]. I say
> so important because you have to build nss@3.99 to compute the channel
> instance derivations for Guix.

I agree that the nss test suite takes a ridiculous amount of time to run
(multiple hours on a fast machine IIRC).  Are we missing a '--fast' test
flag or something to make it run in a more reasonable amount of time?

-- 
Thanks,
Maxim

bug#70681: "guix pull" fails on Trisquel

[Maxim Cournoyer]

Hi Caleb,

Caleb Herbert  writes:

> Hi Guix,
>
> Should the docs recommend against using packaged versions of Guix on
> foreign distros?
>
> I installed Guix with the Trisquel package.  When I ran "guix pull",
> it failed and told me to post the output here.  I've attached the
> transcript of my terminal session with "guix pull" on Trisquel.
>
> I tried doing "apt purge guix" and installing Guix using the installer
> script, but the script "detected" an already-existing Guix
> installation.   I guess "apt purge" didn't really "purge" enough.
>
> I'm now unable to install Guix in a way that will let me pull.

A workaround would look like:

# rm -rf /var/guix /gnu

Then try the guix-install script again.  There's also an undocumented
variable to "overwrite" the current installation; consult the script if
you want to use that.

-- 
Thanks,
Maxim

bug#59361: linux-libre 6 breaks OpenGL on nouveau driver for nvidia 8800 GTS 640 Mo card

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Hi,
>
> When booting my Guix System with linux-libre 6.0.8, nouveau silently
> fails to render OpenGL.  It includes symptoms such as:
>
> 1. Getting stuck on the GDM screen, which makes use of OpenGL
> 2. Not being able to use Qt5 or Qt6 applications, which renders via
> OpenGL.
> 3. the 'glxgears' program from mesa-utils displays frozen gears (not
> turning)
>
> My graphic card is an old nvidia 8800 GTS with 640 MiB of video RAM.
>
> Workaround: Adding the '(kernel linux-libre-5.15)' to my OS definition
> fixes it.

I tried using linux-libre 6.8.8 today (Guix commit
df3d30819e650a490ef39dd6692740bb13263c75), which has Mesa 24.0.4, and
can no longer reproduce the problem described above.

I'm thus happily closing this!

-- 
Thanks,
Maxim

bug#70698: python-pivy build fails (freecad dependency)

[Buttons Presser]

Forgot to add the guix version for this issue:

guix describe ->

  guix 7d4ae2f
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 7d4ae2fca723114fb1df56de33b82177fbc4d0a6

bug#70698: python-pivy build fails (freecad dependency)

[Buttons Presser via Bug reports for GNU Guix]

Dear guix community,

My local python-pivy build fails and there is no longer a working substitute 
available.

The build log is attached 
(q806khpbab7n9nk9i6ynbfhm85gd48-python-pivy-0.6.5.drv.gz).

I suspect that python-pivy stoped building after recent patches to coin3d - 
https://issues.guix.gnu.org/70305

Looks like this is an issue with paths in the python-pivy install scripts 
(build phase: python setup.py). Specifically in its swig command which probably 
misses some paths to soqt and coin3D.

I was trying to fix and upgrade the python-pivy before because the current 
version  is 0.6.5 is old and some features of freecad was not working properly 
- https://issues.guix.gnu.org/70258. I guess there should be a patch to the 
python-pivy cmake config that can fix the paths to soqt and coin3D but I am not 
familiar with cmake and thus far did not find a solution.

Kind regards,
BP



q806khpbab7n9nk9i6ynbfhm85gd48-python-pivy-0.6.5.drv.gz
Description: Binary data

bug#70689: guix search doesn't weigh word matches higher than subword matches

[bokr]

On +2024-04-30 22:18:03 -0400, Richard Sent wrote:
> Hi Guix!
> 
> When running guix search, relevance in synopsis and description fields
> are computed strictly by the number of matches, both as a word and as a
> subword. Ideally, if a search string matches an isolated word in a
> search, that result should be considered more relevant than simply
> matching a subword, even multiple times.
> 
> To illustrate, imagine trying to find what package provides the `rsh`
> binary and running running `$ guix search rsh`. This binary is part of
> `inetutils` and the description field contains:
> 
> > Inetutils is a collection of common network programs, such as an ftp
> > client and server, a telnet client and server, an rsh client and
> > server, and hostname.
> 
> Most likely, this is what the user is interested in. However, inetutils
> does not show up until roughly the ~75th result with a relevance of 2
> (the lowest possible relevance).
> 
> Almost every search result beforehand contains the string "rsh" as a
> component of another word, such as "marshaling", "powershell", and
> "hershey". However, these match multiple times and are weighted
> significantly higher.
> 
> Ideally, guix search should rate inetutils higher because the string
> "rsh" occurs as its own word, not as a component of another, unrelated
> word. (Very, very people would search "rsh" looking for matches with
> "hershey", even if "hershey" occurs multiple times.)
> 
> Another example of where this can happen is with "dig", part of the bind
> package. Searching for "dig" returns garbage because "dig" is a common
> subword. Bind is scored with a relevance of 2, even though bind's
> description emphasises that dig is part of it.
> 
> This would improve the experience when searching with strings that
> commonly occur as subwords.
> 
> Since this change can't occur in a vacuum, care should be taken not to
> reduce the effectiveness of other reasonably forseeable search queries.
> 
> -- 
> Take it easy,
> Richard Sent
> Making my computer weirder one commit at a time.
> 
> 
> 

I like your proposal :)

I'm wondering how [1] compares in what it does for your use(ful) case.
(I am not familiar with Hyper Estraier beyond being prompted for gnu.org 
searching)

[1] 

--
Regards,
Bengt Richter

bug#70668: Error running guix-build

[Javier Vaquero Martínez]

I tried again today and I got this error, I hope this is the “COMPLETE 
output”.


|indexando objetos 82% 
▕█▍ 
▏^ Verificando canal 'guix', revisiones de 9edb3f6 a 7d4ae2f (57 nuevas 
revisiones)... Construyendo a partir de este canal: guix 
https://git.savannah.gnu.org/git/guix.git 7d4ae2f substitute: updating 
substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: 
updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% 
construyendo 
/gnu/store/qbdh7y6398198q695wbb39fvaq1jg4yk-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% guile-gnutls-4.0.0 123KiB 16.6MiB/s 
00:00 ▕██▏ 100.0% guile-lzma-0.1.1 52KiB 75.5MiB/s 00:00 
▕██▏ 100.0% guix-daemon-1.4.0-18.4c94b9e 262KiB 3.3MiB/s 
00:00 ▕██▏ 100.0% libdaemon-0.14 31KiB 192KiB/s 00:00 
▕██▏ 100.0% libevent-2.1.12 304KiB 127KiB/s 00:02 
▕██▏ 100.0% libgit2-1.7.2 667KiB 2.1MiB/s 00:00 
▕██▏ 100.0% avahi-0.8 348KiB 1.7MiB/s 00:00 
▕██▏ 100.0% guile-git-0.6.0 558KiB 1.14GiB/s 00:00 
▕██▏ 100.0% guile-avahi-0.4.1 61KiB 113.6MiB/s 00:00 
▕██▏ 100.0% libssh-0.10.6 248KiB 362.2MiB/s 00:00 
▕██▏ 100.0% nspr-4.35 255KiB 364.5MiB/s 00:00 
▕██▏ 100.0% guile-ssh-0.16.4 253KiB 359.2MiB/s 00:00 
▕██▏ 100.0% nss-3.99.0 2.5MiB 1.90GiB/s 00:00 
▕██▏ 100.0% guile-ssh-0.16.4-debug 261KiB 548.7MiB/s 
00:00 ▕██▏ 100.0% nss-3.99.0-bin 6.3MiB 1.3MiB/s 00:05 
▕██▏ 100.0% substitute: updating substitutes from 
'https://ci.guix.gnu.org'... 100.0% perl-text-wrapi18n-0.06 5KiB 
6.7MiB/s 00:00 ▕██▏ 100.0% perl-gettext-1.07 9KiB 
20.3MiB/s 00:00 ▕██▏ 100.0% perl-pod-parser-1.65 75KiB 
161.1MiB/s 00:00 ▕██▏ 100.0% perl-sgmls-1.1 30KiB 
47.2MiB/s 00:00 ▕██▏ 100.0% perl-syntax-keyword-try-0.28 
30KiB 65.8MiB/s 00:00 ▕██▏ 100.0% perl-term-readkey-2.38 
18KiB 41.2MiB/s 00:00 ▕██▏ 100.0% 
perl-unicode-linebreak-2019.001 102KiB 210.7MiB/s 00:00 
▕██▏ 100.0% perl-xs-parse-keyword-0.06 32KiB 68.6MiB/s 
00:00 ▕██▏ 100.0% perl-yaml-tiny-1.73 26KiB 58.2MiB/s 
00:00 ▕██▏ 100.0% po4a-0.69 2.0MiB 1.42GiB/s 00:00 
▕█▉ ▏ 77.3% po4a-0.69 2.0MiB 1.6MiB/s 00:01 
▕██▏ 100.0% substitute: updating substitutes from 
'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes 
from 'https://bordeaux.guix.gnu.org'... 100.0% The following derivations 
will be built: /gnu/store/3brbjcixl2301svf1nbrii7g2l5simsg-profile.drv 
/gnu/store/adgwjzmzn4vrrasg2wkkwc4015v9sn0q-guix-7d4ae2fca.drv 
/gnu/store/45zdnymwblyy96xjxx8vn66pp3g6kzpy-guix-manual.drv 
/gnu/store/fac7lbvv3vvckrbg89j33fi68mjkdrm4-guix-daemon.drv 
/gnu/store/mgr95jy5c0836wh2bn5k7ky2x54dqp2c-guix-command.drv 
/gnu/store/6pn8bgj7bnd0abbmdj2nw6nbdzxli2va-guix-module-union.drv 
/gnu/store/pslvbxg7li63hg756ld48428dv57b6s2-guix-7d4ae2fca-modules.drv 
/gnu/store/65q571jybj3b4swrip3xa6yp8cj5pfmz-guix-system-modules.drv 
/gnu/store/07ydxwmfwnyimjb975758fsbhxqz705g-guix-system.drv 
/gnu/store/186hzha1ryzmmm44w14qwylg3j3dlssj-guix-core-source.drv 
/gnu/store/2f0z0x4nqpwgwmrk5qs7ka0p3y2a2gny-config.scm.drv 
/gnu/store/7aipivqdfc1vjkl57iqrqijrnm84q6za-guix-packages.drv 
/gnu/store/yppyh6vkkyyb5rw1nf6chldy0ghyhrvx-guix-extra.drv 
/gnu/store/zd6p7ji2givw0riyfbz0cgz5k58gvhzi-guix-packages-base.drv 
/gnu/store/794jap8cxm794zrrsm57wlviar2ii4ng-guix-home-modules.drv 
/gnu/store/x4842h2wmh0s80nr7aj600as1rm0yxip-guix-home.drv 
/gnu/store/99sv8804ryjr3kvc0ci9xfj93x5xr3p3-guix-core-modules.drv 
/gnu/store/a4z23ss5ss68c53kl234w3jpi39m5gxc-guix-cli-core-modules.drv 
/gnu/store/ga4phpgik33kz2kz9mbz409k2g8ydk0y-guix-cli-core.drv 
/gnu/store/cb35ipxwi8sy4syn5hlkb9ka96g911ly-guix-extra-modules.drv 
/gnu/store/ihf8c969ljm3vpk288kgs0a8fqr38kn8-guix-system-tests-modules.drv 
/gnu/store/ygj7jyqfd8q6kn9rhcvyw14vc0lhy6qr-guix-system-tests.drv 
/gnu/store/mqjsk1r86jss0pb7zl3a50asp6p7hnls-guix-cli.drv 
/gnu/store/inws8xpm6xdridl5wpbwyr9caa2m80gr-guix-cli-modules.drv 
/gnu/store/la9sqimciqxyy8na371cpkx74dggy4ch-guix-packages-modules.drv 
/gnu/store/vv5gsmwsg53bwfa36vykg3bshrwafpfc-guix-config-modules.drv 
/gnu/store/i9dsxx8w7r9zbz39gkz97ga2g0yskhj2-guix-config.drv 
/gnu/store/k9x10rcsfk08dkw1n1l88sr2zqwdq7gh-guix-config-source.drv 
/gnu/store/4m3w64f68p6kg0jr7y6xqzfzggf7lgmq-config.scm.drv 
/gnu/store/wpplnihcpn9fx6a3npv38zzy42vgb449-guix-packages-base-modules.drv 
/gnu/store/j4rnf4vsgazc0wh55z9lzkqif2qxjnij-guix-misc.drv 
/gnu/store/4yh9936v1qmpn0hr6ahi3rklr005li4l-profile.drv 

bug#70588: hash mismatch error and stop fallback

[Ludovic Courtès]

Hi,

Simon Tournier  skribis:

> Other said, hash mismatch should be raised and obviously the content
> must be discarded; then the hash mismatch should be considered as “not
> found” so let try the next strategy for downloading the content.

Agreed.  I merged it with .

Thanks,
Ludo’.

bug#70663: nss@3.99 is really hard to build

[Christopher Baines]

Christopher Baines  writes:

> nss@3.99 is really hard to build, it's so hard and so important that
> data.guix.gnu.org is still after two days trying to process [1]. I say
> so important because you have to build nss@3.99 to compute the channel
> instance derivations for Guix.
>
> 1: https://data.guix.gnu.org/revision/72308f262c910977e40c2c9f350dc563c0a8437a
>
> Looking at the next revision which has been processed [2], it's been
> built on riscv64-linux as the testsuite is disabled, and it has also
> built on aarch64-linux, but there's no successful build for any other
> architecture.
>
> 2: 
> https://data.guix.gnu.org/revision/9f183c3627a006e8fd3bb9708448bc05a6204e6d/package/nss/3.99.0?locale=en_US.UTF-8
>
> I think there's two issues here, was this spotted before merging, and
> what if anything can be done about this now. Where there's not a
> substitute available for nss@3.99, this will affect guix pull/guix
> time-machine, e.g.
>
>   → guix time-machine --commit=72308f262c910977e40c2c9f350dc563c0a8437a -- 
> describe
>   Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
>   substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
>   substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
>   substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 
> 100.0%
>nss-3.99.tar.xz  55.2MiB   
>   13.7MiB/s 00:04 
> ▕██▏ 100.0%
>   building /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv...

Looking at the build failures for x86_64-linux, it seems that there's
just one test failure. There's a threshold of less than 5 seconds, and
it takes 5 to 7 seconds to complete. This probably isn't helped by using
faketime.

Here's an upstream bug [3] where they raised the threshold a bit, but
this isn't enough for our use case.

3: https://bugzilla.mozilla.org/show_bug.cgi?id=1835357

I've sent a patch here which increases the threshold by a lot:

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


signature.asc
Description: PGP signature

bug#25235: [Maxim Cournoyer] bug#25235: [PATCH v3 1/1] build-system/pyproject: Do not wrap native-inputs.

[Nicolas Graves via Bug reports for GNU Guix]

Hi Lars, Ricardo,

I'm advancing with my patch series, which I can submit soon. I was
curious about why this 25235 patch isn't in python-team branch yet since
it's also a very welcome change to the pyproject-build-system.

Cheers,

Nicolas

 Start of forwarded message 
Subject: bug#25235: [PATCH v3 1/1] build-system/pyproject: Do not wrap
 native-inputs.
To: 25...@debbugs.gnu.org
Cc: arunis...@systemreboot.net, Maxim Cournoyer ,
 l...@gnu.org, Lars-Dominik Braun , efr...@flashner.co.il,
 rek...@elephly.net, jgart , mar...@gnu.org
From: Maxim Cournoyer 
Date: Mon, 23 Jan 2023 08:34:33 -0500

Fixes .

* guix/build/pyproject-build-system.scm (wrap) [native-inputs]: New argument.
Filter out native inputs from the values in GUIX_PYTHONPATH.

---

Changes in v3:
- Rebase

Changes in v2:
- Add missing copyright line
- Rework wrap phase to avoid removing inputs found in both native-inputs and 
inputs
- Enclose wrap computations in an 'unless' form and streamline

 guix/build/pyproject-build-system.scm | 39 ---
 1 file changed, 24 insertions(+), 15 deletions(-)

diff --git a/guix/build/pyproject-build-system.scm 
b/guix/build/pyproject-build-system.scm
index a66c1fb34a..9da86bfc54 100644
--- a/guix/build/pyproject-build-system.scm
+++ b/guix/build/pyproject-build-system.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2021 Lars-Dominik Braun 
 ;;; Copyright © 2022 Marius Bakke 
+;;; Copyright © 2023 Maxim Cournoyer 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -445,7 +446,7 @@ (define* (add-install-to-pythonpath #:key native-inputs 
outputs
   "A phase that just wraps the 'add-installed-pythonpath' procedure."
   (add-installed-pythonpath native-inputs outputs))
 
-(define* (wrap #:key inputs outputs #:allow-other-keys)
+(define* (wrap #:key native-inputs inputs outputs #:allow-other-keys)
   (define (list-of-files dir)
 (find-files dir (lambda (file stat)
   (and (eq? 'regular (stat:type stat))
@@ -458,20 +459,28 @@ (define bindirs
  (string-append dir "/sbin"
 outputs))
 
-  ;; Do not require "guile" to be present in the package inputs
-  ;; even when there is nothing to wrap.
-  ;; Also, calculate (guile) only once to prevent some I/O.
-  (define %guile (delay (search-input-file inputs "bin/guile")))
-  (define (guile) (force %guile))
-
-  (let* ((var `("GUIX_PYTHONPATH" prefix
-,(search-path-as-string->list
-  (or (getenv "GUIX_PYTHONPATH") "")
-(for-each (lambda (dir)
-(let ((files (list-of-files dir)))
-  (for-each (cut wrap-script <> #:guile (guile) var)
-files)))
-  bindirs)))
+  (unless (null? bindirs)
+(let* ((guile (search-input-file inputs "bin/guile"))
+   (native-input-dirs (match native-inputs
+(((_ . dir) ...)
+ dir)))
+   (input-dirs (match inputs
+ (((_ . dir) ...)
+  dir)))
+   (build-inputs (lset-difference string=? native-input-dirs
+  input-dirs))
+   ;; A build input is an input listed in native-inputs and NOT in
+   ;; inputs.
+   (build-input? (lambda (x)
+   (any (cut string-prefix? <> x) build-inputs)))
+   (var `("GUIX_PYTHONPATH" prefix
+  ,(remove build-input? (search-path-as-string->list
+ (or (getenv "GUIX_PYTHONPATH") 
""))
+  (for-each (lambda (dir)
+  (let ((files (list-of-files dir)))
+(for-each (cut wrap-script <> #:guile guile var)
+  files)))
+bindirs
 
 (define* (rename-pth-file #:key name native-inputs outputs #:allow-other-keys
   #:rest args)
-- 
2.39.1




 End of forwarded message 

-- 
Best regards,
Nicolas Graves