bug#75902: guile-gnutls does not set up search paths for the certificates

Hi, Tomas Volf <~@wolfsden.cz> skribis: >> GnuTLS (and thus Guile-GnuTLS) does not honor an environment variable. >> Instead it’s up to applications to set up their certificate search path. >> >> See for example the discussion at . > > Thank you for the link. H

bug#75902: guile-gnutls does not set up search paths for the certificates

Ludovic Courtès writes: > Hi, > > Tomas Volf <~@wolfsden.cz> skribis: > >> We can see the difference boils down to different search paths: >> >> $ guix shell -CN guile guile-gnutls nss-certs --search-paths >> export >> PATH="/gnu/store/gg2qyb

bug#75902: guile-gnutls does not set up search paths for the certificates

Hi, Tomas Volf <~@wolfsden.cz> skribis: > We can see the difference boils down to different search paths: > > $ guix shell -CN guile guile-gnutls nss-certs --search-paths > export > PATH="/gnu/store/gg2qybb41rpcl0fs4ay98s2q3m2mcbyz-profile/bin${PATH:+:}$PATH" &g

bug#75902: guile-gnutls does not set up search paths for the certificates

---start->8--- $ guix shell -CN guile guile-gnutls nss-certs curl -- guile -c '((@ (web client) http-get) "https://gnu.org";)' --8<---cut here---end--->8--- We can see the difference boils down to different search pat

bug#71326: ld-wrapper does not handle all possibilities to specify libraries and their search paths

Hi! Beside using an absolute path, the ld of Binutils has eight ways¹ to pass a library like libfoo.so via options: -lfoo -l foo -library=foo --library=foo -l:libfoo.so -l :libfoo.so -library=:libfoo.so --library=:libfoo.so The ld-wrapper however only supports one of these possibilities, which

bug#68912: Guix-home search paths shadow .config/guix/current

Am Samstag, dem 03.02.2024 um 13:12 + schrieb Christina O'Donnell: > This leads to unexpected results if you have Guix inside your home > package list. (Which you might desire if you wanted to use Guix in a > home container.) The wisdom "One does not simply 'guix install guix'" has been passe

bug#68912: Guix-home search paths shadow .config/guix/current

Hi, On my machine the order of search paths are: $ echo $PATH | tr : '\n' /home/cdo/.guix-home/profile/bin /home/cdo/.guix-home/profile/sbin /run/setuid-programs /home/cdo/.config/guix/current/bin /home/cdo/.guix-profile/bin /run/current-system/profile/bin /run/current-system/profile

bug#20255: 'search-paths' should respect both user and system profile.

Maxim Cournoyer writes: > Hi, > > 宋文武 writes: > >> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge >> search-paths from multiple profiles by `guix package --search-paths`, in >> ~/.bashrc and ~/.zprofile (skeletons, so existed

bug#20255: [PATCH 1/4] home: shells: Merge search-paths of multiple profiles.

From: 宋文武 This is a followup to 40310efde9b4a4f2cf98081d6cd10f843685ebb6. * gnu/home/services.scm (environment-variables->setup-environment-script): Merge search-paths from multiple profiles via "guix package". * gnu/home/services/shells.scm (zsh-file-zprofile, add-bash-configura

bug#20255: 'search-paths' should respect both user and system profile.

Josselin Poiret writes: > Hi Maxim, > > Maxim Cournoyer writes: > >> Just to make sure, remove what exactly? > > Remove the bit in /etc/profile that loads the user's profile, if it is > indeed supposed to be loaded by the user's own ~/.zprofile or > ~/.bash_profile. Remove will break existed sy

bug#20255: 'search-paths' should respect both user and system profile.

Hi Maxim, Maxim Cournoyer writes: > Just to make sure, remove what exactly? Remove the bit in /etc/profile that loads the user's profile, if it is indeed supposed to be loaded by the user's own ~/.zprofile or ~/.bash_profile. At least, I don't know if there is a general agreement on what shoul

bug#20255: 'search-paths' should respect both user and system profile.

Hi, Josselin Poiret writes: > Hi, > > 宋文武 via Bug reports for GNU Guix writes: > >> Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge >> search-paths from multiple profiles by `guix package --search-paths`, in >> ~/.bashrc and ~/.zprofile

bug#20255: 'search-paths' should respect both user and system profile.

Hi, 宋文武 via Bug reports for GNU Guix writes: > Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge > search-paths from multiple profiles by `guix package --search-paths`, in > ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual > update). >

bug#20255: 'search-paths' should respect both user and system profile.

Hi, 宋文武 writes: > Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge > search-paths from multiple profiles by `guix package --search-paths`, in > ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual > update). > > > Close now! Cool,

bug#20255: 'search-paths' should respect both user and system profile.

Hello, commit 40310efde9b4a4f2cf98081d6cd10f843685ebb6 fix this by merge search-paths from multiple profiles by `guix package --search-paths`, in ~/.bashrc and ~/.zprofile (skeletons, so existed systems need manual update). Close now!

bug#22138: Search paths of dependencies are not honored

Hi, On second thought, honouring search paths of dependencies (filtered by looking at the references?) would solve much more problems than it could create -- a theoretical ‘problem’ is that more environment variables than strictly needed might be defined (see e.g. the wrap-program example) but it

bug#22138: Should search paths of dependencies be honored automatically?

(first section) > As of 0.9.0+, only the search paths of packages explicitly in the > profile are shown by ‘--search-paths’ and similar. This is a problem > for libraries that have associated environment variables. > > For instance, if one installs an application linked against

bug#20255: 'search-paths' should respect both user and system profile.

The default would be to load both combine the environment variables of > the system and user profiles using 'guix package --search-paths', but a > user could opt-out of that by providing an empty file, or customize the > list of profiles the way they'd like. > > Would that be an acceptable solution from your point of view? Sure! Any solution that I can configure for my needs is good for me, thank you! -- Alex

bug#20255: 'search-paths' should respect both user and system profile.

Am Montag, den 28.06.2021, 00:35 -0400 schrieb Maxim Cournoyer: > Hi Leo, > > [...] > > > I think there is a solution, that works not only for the case of > > disabling this unwanted feature, but also to add in support for > > multiple profiles, i.e. if the user has more than just their .guix- >

bug#20255: 'search-paths' should respect both user and system profile.

wanting to run a command in /etc/profile). >> While I share the sentiment that /etc/profile would better be 'inert' or >> static, it seems we haven't been able to come up with a better solution >> than calling 'guix package --search-paths'. Like Ludovi

bug#20255: 'search-paths' should respect both user and system profile.

Hi Leo, [...] > I think there is a solution, that works not only for the case of > disabling this unwanted feature, but also to add in support for > multiple profiles, i.e. if the user has more than just their .guix- > profile to load. > > If we made this feature opt-in in that a user would first

bug#20255: 'search-paths' should respect both user and system profile.

While I share the sentiment that /etc/profile would better be 'inert' or > static, it seems we haven't been able to come up with a better solution > than calling 'guix package --search-paths'. Like Ludovic, I also don't > find the idea of allowing users to override

bug#20255: 'search-paths' should respect both user and system profile.

old; the last activity seems back on 2015, November. So let > > > resume. > > > > > > The issue is, e.g.: > > > - perl installed into the system profile > > > - perl-xml-parser installed into an user profile > > > Then "guix package --search-path

bug#20255: 'search-paths' should respect both user and system profile.

ed into the system profile >> - perl-xml-parser installed into an user profile >> Then "guix package --search-paths" does not set correctly XML::Parser. >> >> >> Fixes had been pushed: dedb17a and b2a7223 and cc3de1d. >> >> The final fix is still

bug#44662: Lua search paths

On Fri, 26 Mar 2021 10:28:03 +0100 zimoun wrote: > Hi, > > On Sun, 15 Nov 2020 at 19:24, raingloom wrote: > > I have a very WIP branch adding search paths to Lua. > > https://git.sr.ht/~raingloom/guix-source/tree/raingloom/lua > > > > The problem is that

bug#44662: Lua search paths

Hi, On Sun, 15 Nov 2020 at 19:24, raingloom wrote: > I have a very WIP branch adding search paths to Lua. > https://git.sr.ht/~raingloom/guix-source/tree/raingloom/lua > > The problem is that Lua uses a different path format compared to most > packages. Instead of a list of direc

bug#20255: «the Oldest» [PATCH] 'search-paths' should respect both user and system profiles

gt; - perl installed into the system profile > - perl-xml-parser installed into an user profile > Then "guix package --search-paths" does not set correctly XML::Parser. > > Fixes had been pushed: dedb17a and b2a7223 and cc3de1d. > > The final fix is still missing. Beca

bug#44662: Lua search paths

I have a very WIP branch adding search paths to Lua. https://git.sr.ht/~raingloom/guix-source/tree/raingloom/lua The problem is that Lua uses a different path format compared to most packages. Instead of a list of directories, it is a list of path patterns, each potentially containing a question

bug#20255: (old)bug#20255: 'search-paths' should respect both user and system profiles

o an user profile > Then "guix package --search-paths" does not set correctly XML::Parser. > > > Fixes had been pushed: dedb17a and b2a7223 and cc3de1d. > > The final fix is still missing. Because it is a controversial patch > [2] :-) i.e., running 'guix' in

bug#20255: (old)bug#20255: 'search-paths' should respect both user and system profiles

Dear, What is the status of the bug#20255 [1]? It is old; the last activity seems back on 2015, November. So let resume. The issue is, e.g.: - perl installed into the system profile - perl-xml-parser installed into an user profile Then "guix package --search-paths" does not set cor

bug#22138: Search paths of dependencies are not honored

See https://issues.guix.gnu.org/issue/22138 I'm not sure what the implications would be. Your results look good and I think it's close enough to what we need. Now, to get SSL_CERT_DIR to be defined, we simply need a ssl cert dir to be present in the profile, which is what users expect. I would

bug#22138: Search paths of dependencies are not honored

Ludovic Courtès skribis: > The attached procedure computes the search paths of a package based on > its run-time dependencies. ‘profile-derivation’ could use this to > compute its ‘etc/profile’ file and its ‘manifest’ file. One difficulty with this approach is that search paths are cu

bug#22138: Search paths of dependencies are not honored

rom: Julien Lepiller >> Date: Thu, 1 Aug 2019 22:09:38 +0200 >> Subject: [PATCH] guix: Recursively honor search paths of dependencies. >> >> * guix/packages.scm (all-transitive-inputs) >> (package-all-transitive-inputs) >> (package-all-transitive-native-search-

bug#22138: Search paths of dependencies are not honored

8b393bcdd5 Mon Sep 17 00:00:00 >2001 >> From: Julien Lepiller >> Date: Thu, 1 Aug 2019 22:09:38 +0200 >> Subject: [PATCH] guix: Recursively honor search paths of >dependencies. >> >> * guix/packages.scm (all-transitive-inputs) >> (package-all-transit

bug#22138: Search paths of dependencies are not honored

2:09:38 +0200 > Subject: [PATCH] guix: Recursively honor search paths of dependencies. > > * guix/packages.scm (all-transitive-inputs) > (package-all-transitive-inputs) > (package-all-transitive-native-search-paths): New procedures. > * guix/profiles.scm (package->manifest-entry)

bug#22138: Search paths of dependencies are not honored

Hi, I've been looking at our current code and would like to propose the attached patch for that issue. >From cfd2c229087166ab4cc0a9e2bdb72c8b393bcdd5 Mon Sep 17 00:00:00 2001 From: Julien Lepiller Date: Thu, 1 Aug 2019 22:09:38 +0200 Subject: [PATCH] guix: Recursively honor search

bug#25422: [PATCH 0/2] Support single-entry search paths

l...@gnu.org (Ludovic Courtès) skribis: > Ricardo Wurmus skribis: > >> Ludovic Courtès writes: >> >>> Hi! >>> >>> These patches for ‘core-updates’ add support for “single-entry” search >>> paths like ‘GIT_SSL_CAINFO’. This is achieved by

bug#25422: [PATCH 0/2] Support single-entry search paths

Ricardo Wurmus skribis: > Ludovic Courtès writes: > >> Hi! >> >> These patches for ‘core-updates’ add support for “single-entry” search >> paths like ‘GIT_SSL_CAINFO’. This is achieved by setting ‘separator’ to >> #f in the search path spec. >> >>

bug#25422: [PATCH 0/2] Support single-entry search paths

Ludovic Courtès writes: > Hi! > > These patches for ‘core-updates’ add support for “single-entry” search > paths like ‘GIT_SSL_CAINFO’. This is achieved by setting ‘separator’ to > #f in the search path spec. > > Feedback welcome! This looks good and will be useful for t

bug#25422: [PATCH 2/2] search-paths: Allow specs with #f as their separator.

This adds support for single-entry search paths. Fixes <http://bugs.gnu.org/25422>. Reported by Leo Famulari . * guix/search-paths.scm ()[separator]: Document as string or #f. * guix/search-paths.scm (evaluate-search-paths): Add case for SEPARATOR as #f. (environment-variable-definition):

bug#25422: [PATCH 0/2] Support single-entry search paths

Hi! These patches for ‘core-updates’ add support for “single-entry” search paths like ‘GIT_SSL_CAINFO’. This is achieved by setting ‘separator’ to #f in the search path spec. Feedback welcome! Ludo’. Ludovic Courtès (2): guix package: Honor the order of profiles when -p appears multiple

bug#25425: lua does not set search paths

The lua interpreter packages do not set native search paths, so they cannot find lua modules. $ guix environment --ad-hoc lua lua-lpeg $ lua > require('lpeg') … ERROR … However: $ guix environment --ad-hoc lua lua-lpeg $ export LUA_PATH="$GUIX_ENVIRONMENT/s

bug#22073: Fwd: search-paths and propagated inputs

Fixed in ccda8f7, thanks! Ludo’.

bug#22073: Fwd: search-paths and propagated inputs

On Sun, Dec 20, 2015 at 1:56 PM, Ludovic Courtès wrote: >> To get all the required search paths recursively we should replace the >> last 'manifest-entry' slot with a call to a function like this: > > Right. > > Here’s a variant of what you propose. With that,

bug#22073: Fwd: search-paths and propagated inputs

Thanks for the heads-up, and sorry for the delay! Federico Beffa skribis: > Looking at my manifest file I see that, e.g., the entry for > 'python-matplotlib' lists all recursively propagated > dependencies. Differently from this the 'search-paths' entry only lists

bug#22073: Fwd: search-paths and propagated inputs

Any feedback on this? Thanks, Fede

bug#22138: Search paths of dependencies are not honored

As of 0.9.0+, only the search paths of packages explicitly in the profile are shown by ‘--search-paths’ and similar. This is a problem for libraries that have associated environment variables. For instance, if one installs an application linked against OpenSSL, they will not know about

bug#22073: Fwd: search-paths and propagated inputs

Looking at my manifest file I see that, e.g., the entry for 'python-matplotlib' lists all recursively propagated dependencies. Differently from this the 'search-paths' entry only lists the entries defined in the package (in this case none), neglecting the search paths in th

bug#22073: Fwd: search-paths and propagated inputs

Federico Beffa writes: > Federico Beffa writes: > >> Hi, >> >> the package 'gobject-introspection' declares a >> search-path-specification for the variable GI_TYPELIB_PATH and >> 'matplotlib' uses and propagates said package. I have &

bug#20255: 'search-paths' should respect both user and system profile.

time guix package -p /run/current-system/profile \ >>>> -p ~/.guix-profile --search-paths >>> >>> real0m2.634s >>> user0m0.568s >>> sys 0m0.080s >> >> Could you measure again after cc3de1d? >

bug#20255: 'search-paths' should respect both user and system profile.

Ludovic Courtès (2015-11-24 20:22 +0300) wrote: > Alex Kost skribis: > >> Ludovic Courtès (2015-11-21 23:10 +0300) wrote: > > [...] > >>> Really? Can you show the output of: >>> >>> time guix package -p /run/current-system/profile \ >>&

bug#20255: 'search-paths' should respect both user and system profile.

Alex Kost skribis: > Ludovic Courtès (2015-11-21 23:10 +0300) wrote: [...] >> Really? Can you show the output of: >> >> time guix package -p /run/current-system/profile \ >> -p ~/.guix-profile --search-paths > > real 0m2.634s > user

bug#20255: 'search-paths' should respect both user and system profile.

n such >>> 'profile-file' is specified, it will be used instead of the default one >>> (of course, it should be mentioned in the manual that it's only for >>> those users who are sure what they do). >> >> I think we could make an /etc/profile-servi

bug#20255: 'search-paths' should respect both user and system profile.

ld be mentioned in the manual that it's only for >> those users who are sure what they do). > > I think we could make an /etc/profile-service that receives snippets > meant to be glued together into the final /etc/profile. Users could > specify the top or bottom of the fi

bug#20255: 'search-paths' should respect both user and system profile.

ve several user profiles, it does nothing useful for me, only wastes > the time. I think this is fine. ~/.guix-profile is treated specially in many ways. I think users do not expect other profiles to be magically taken into account. > OK, for the bug at hand, invoking "guix package -

bug#20255: 'search-paths' should respect both user and system profile.

f: >>> >>> time guix package -p /run/current-system/profile \ >>> -p ~/.guix-profile --search-paths >> >> real 0m2.634s >> user 0m0.568s >> sys 0m0.080s > > Ouch, that’s a problem. This suggests that this is 2 seconds of I/O

bug#20255: 'search-paths' should respect both user and system profile.

rd to avoid resorting to >> invoking a program, but ultimately no other solution came out. > > I don't need a solution for this bug, I just want to have an option to > avoid invoking "guix package --search-paths" in my "/etc/profile". Are you denying that this is a b

bug#20255: 'search-paths' should respect both user and system profile.

; -# Load the system profile's settings. >>>>> +if [ -x /run/current-system/profile/bin/guix ] >>>>> +then >>>>> + # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing >>>>> from the >>>>> +

bug#20255: 'search-paths' should respect both user and system profile.

profile/bin/guix ] >>>> +then >>>> + # Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from >>>> the >>>> + # profiles' individual 'etc/profile'. Thus, combine both profiles when >>>>

bug#20255: 'search-paths' should respect both user and system profile.

# Crucial variables such as 'MANPATH' or 'INFOPATH' may be missing from >>> the >>> + # profiles' individual 'etc/profile'. Thus, combine both profiles when >>> + # computing the search paths. >>> + # >>> + #

bug#20255: 'search-paths' should respect both user and system profile.

missing from >> the >> + # profiles' individual 'etc/profile'. Thus, combine both profiles when >> + # computing the search paths. >> + # >> + # This may take a few hundred milliseconds, but it's OK because this is >> + # performed fo

bug#20255: 'search-paths' should respect both user and system profile.

individual 'etc/profile'. Thus, combine both profiles when > + # computing the search paths. > + # > + # This may take a few hundred milliseconds, but it's OK because this is > + # performed for log-in shells only. > + eval `/run/current-sys

bug#20255: 'search-paths' should respect both user and system profile.

l...@gnu.org (Ludovic Courtès) skribis: > 宋文武 skribis: > >>> [...] >>>> >>>> The idea to generate profile from search-paths is not new, >>>> I heard it from you IIRC. >>>> I think it's the time to do it. >>> >>

bug#20255: 'search-paths' should respect both user and system profile.

Some progress has been made: fc2d233 allows search paths for multiple profiles to be combined. So I think I will eventually (‘guix-devel’ needs to be updated first) change /etc/profile to do: eval `guix package -p /run/current-system/profile \ -p $HOME/.guix-profile --search-paths

bug#20255: 'search-paths' should respect both user and system profile.

in another.) This part is not addressed yet, and it turns out to be more common than I initially thought: consider for instance MANPATH (with man-db installed in the system profile and man pages in the user’s profile.) Unfortunately the etc/profile files are not going to allow us to solve that. ‘guix package --search-paths’ could do the actual combination, though. Thanks, Ludo’.

bug#20255: 'search-paths' should respect both user and system profile.

宋文武 skribis: > How about using a shell variable as input for the location: > (replace /gnu/store/xxx with $GUIX_PROFILE) > > # etc/profile > export PATH=$GUIX_PROFILE/bin:$PATH > export MANPATH=$GUIX_PROFILE/share/man:$MANPATH > ... > > Then when 'source' it, we pass the location: > (we d

bug#20255: 'search-paths' should respect both user and system profile.

on’ what the user-visible name of > the profile is going to be. Attached is a very rough patch to do that. > This is not so nice because all user interfaces will now have to pass > that #:target parameter or etc/profile will be “wrong.” > > Another option would be to simply run: > >

bug#20255: 'search-paths' should respect both user and system profile.

ve to tell ‘profile-generation’ what the user-visible name of the profile is going to be. Attached is a very rough patch to do that. This is not so nice because all user interfaces will now have to pass that #:target parameter or etc/profile will be “wrong.” Another option would be to simply ru

bug#20255: 'search-paths' should respect both user and system profile.

宋文武 skribis: >> [...] >>> >>> The idea to generate profile from search-paths is not new, >>> I heard it from you IIRC. >>> I think it's the time to do it. >> >> Agreed, the plan makes sense and I think we have all the bits. >> &

bug#20255: 'search-paths' should respect both user and system profile.

宋文武 writes: >> [...] >>> >>> The idea to generate profile from search-paths is not new, >>> I heard it from you IIRC. >>> I think it's the time to do it. >> >> Agreed, the plan makes sense and I think we have all the bits. >> &

bug#20255: 'search-paths' should respect both user and system profile.

> [...] >> >> The idea to generate profile from search-paths is not new, >> I heard it from you IIRC. >> I think it's the time to do it. > > Agreed, the plan makes sense and I think we have all the bits. > > A related question is whether to encode

bug#20255: 'search-paths' should respect both user and system profile.

宋文武 skribis: > As 'guix package' is for only one profile, that's fine. > Since we can get search-paths from system profile using: > guix package -p /run/current-system/profile --search-paths Right. > I think the missing is to check whether we are under GuixSD, >

bug#20255: 'search-paths' should respect both user and system profile.

Ludovic Courtès writes: > 宋文武 skribis: > >> Currently, search-paths built only from packages in user's profile. >> As reported by Andy Wingo in #guix, when I have: >> perl installed into system profile >> perl-xml-parser installed into user profile >>

bug#20255: 'search-paths' should respect both user and system profile.

宋文武 skribis: > Currently, search-paths built only from packages in user's profile. > As reported by Andy Wingo in #guix, when I have: > perl installed into system profile > perl-xml-parser installed into user profile > > guix package --search-paths won't give

bug#20255: 'search-paths' should respect both user and system profile.

Currently, search-paths built only from packages in user's profile. As reported by Andy Wingo in #guix, when I have: perl installed into system profile perl-xml-parser installed into user profile guix package --search-paths won't give a hint about PERL5LIB, so it's very likel

Re: Search paths

l...@gnu.org (Ludovic Courtès) skribis: > Commit a18eda2 in ‘core-updates’ adds the ‘native-search-paths’ field > for packages, and honor it. The next commit gives an example of how to > use it. With commit 5924080, ‘guix package --install’ reports environment variables that needs to b

Search paths

Hey, hey! Commit a18eda2 in ‘core-updates’ adds the ‘native-search-paths’ field for packages, and honor it. The next commit gives an example of how to use it. As discussed before, this mechanism allows the declaration of a package’s search path environment variables. Examples follow. GCC has