bug#20050: ghostscript: Dangling .so references
Fixed in 1d386b2. Ludo’.
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, > and then merge those 2 search-paths object in scheme level > to get a full search-paths. > > Or better to generate a 'profile' script for each manifest, and then > merged in shell level, so it can work out-of-the-box. How about: > - /etc/profile: > # configuration for the whole system goes here. > # shouldn't refer profile paths. > export LANG=en_US.utf8 > export SSL_CERT_DIR=/etc/ssl/certs > export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules > [...] > > source /run/current-system/profile/etc/profile > > if [ -f $HOME/.guix-profile/etc/profile ]; then > source $HOME/.guix-profile/etc/profile > fi > > # honor setuid-programs > export PATH=/run/setuid-programs:$PATH > > - /run/current-system/profile/etc/profile: > export > PATH=/run/current-system/profile/bin:/run/current-system/profile/sbin:$PATH > export MANPATH=/run/current-system/profile/share/man:$PATH > [...] > > - ~/.guix-profile/etc/profile: > export PATH=~/.guix-profile/bin:~/.guix-profile/sbin:$PATH > [...] > > 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 search path environment variables into the manifest (currently they are “guessed” by looking at same-named packages; see (guix build package).) I think that would probably simplify things and make it easier to share this environment variable code. Thoughts? Thanks, Ludo’.
bug#20037: problem still persist
Tomáš Čech skribis: > I'm afraid I can reproduce it. It’s a different problem this time. :-) > --%%--- [...] > (packages > (append >(list > ;; absolutely necessary > emacs lvm2 mc bash texinfo (Unrelated, but I personally find it more convenient to have only core packages in the global profile, and then have the rest in user profiles.) [...] > (services > (append >(list > (lsh-service #:port-number 22 #:root-login? #t #:initialize? #t) > (slim-service) > (wicd-service) > (avahi-service) > (dbus-service (list avahi wicd)) > (mingetty-service "ttyS0")) [...] >?: 0 [symlink "/gnu/store/z95z25d73kjza99s3w95lrdsiqlcdv0a-login" ...] > > ERROR: In procedure symlink: > ERROR: In procedure symlink: File exists The culprit is the ‘mingetty-service’ call above: since it uses a #:motd different from that used in the other ‘mingetty-service’ calls in %base-services, the thing tries to create a different pam.d/login file for it, but that fails because there’s already a pam.d/login file. The workaround is to write: (mingetty-service "ttyS0" #:motd (text-file "motd" " This is the GNU operating system, welcome!\n\n")) Since this is the same motd as the other mingetty services, everything is fine. This is of course unsatisfactory. The more general issue is that service procedures need to be able to share state/configuration info, which I hope we can fix soon. Thanks, Ludo’.
bug#20261: (mount-points) returns bogus values within the build environment
Andy Wingo reported running into the same problem on Linux-4.0-rc6. Mark
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 search path environment > variables into the manifest (currently they are “guessed” by looking at > same-named packages; see (guix build package).) I think that would > probably simplify things and make it easier to share this environment > variable code. > > Thoughts? I see, currently search-paths depends on the packages recipes. If we update the related scheme code, then search-paths got updated, even we didn't touch packages in profile at all. It's a little confusing. So I think we should encode the search-paths for each package in manifest. > Thanks, > Ludo’.
