<rekado>it's too bad I cannot yet use GuixSD on this workstation in the office.
<rekado>I still have problems with Emacs claiming my user has no home directory.
<taylan>am I doing it right by doing 'guix package -p /var/run/current-system/profile -i glibc-locales', then 'ln -s profile/lib/locale/2.22 /var/run/current-system/locale'? or is there a way that won't need me to update the symlink later?
<taylan>I set GUIX_LOCPATH in my ~/.profile, but that doesn't affect the substituter processes AFAIUI
<rekado>civodul: a Guix bug (or maybe a bug in my Emacs configuration exposed by Guix). When I use the Guix-built Emacs (or Guile Emacs) on this Fedora workstation I get an error on the attempt to load my configuration.
<civodul>rekado: you need to launch the daemon in an environment with GUIX_LOCPATH set appropriately
<toothbrush0>I'm feeling a bit stupid again. My Guix setup was working, but i've just done a `git pull` and now, `./pre-inst-env guix` throws ERROR: In procedure dynamic-link: file: "/gnu/store/zs4jj3h2ndqn5xrng2qsnddl1zils2pc-libgcrypt-1.6.3/lib/libgcrypt", message: "file not found"
<davexunit>that package object specifies the version, the source code, and its dependencies
<effa>As far as I know NIX did manage the versions of individual packages. However, I believe that recently they stopped doing that because most packages are upward compatible, but the Cabal still sets upper version limits.
<taylan>I indeed ran the gc, after temporarily running the daemon with only the build-user-group flag, to make sure nothing unused remains in the store after the core-updates update. and I also did 'guix package -u' with root after pulling master (after the core-updates merge).
<mark_weaver>civodul: so if you run "make install", does the installed (guix config) still contain the absolute path? will it be registered as a GC root in that case?
<taylan>ah, I should perhaps run 'make install' every once in a while? while I use run both 'guix-daemon' and 'guix' from guix profiles, there is also stuff in /var/guix/... after all. (I'm a bit confused, hope that makes sense.) I think I first got the /var/guix from the "drop-in binaries" for other systems a while back.
<civodul>mark_weaver: no, it's not registered as a GC root
<taylan>(i.e. I run ~/.guix-profile/bin/guix-daemon as root, and ~/.guix-profile/bin/guix as any user, so I usually assume 'make install' isn't necessary, although $XDG_CONFIG_HOME/guix/latest points to the git repo.)
<civodul>hopefully that bzip2 is in a profile, so somehow uncollectable
<toothbrush0>is there a way to hide the "note: source file .. newer than ...go" messages?
<mark_weaver>civodul: but then what happens when the profile is updated? if the reference stored in (guix config) is an absolute filename instead of /home/FOO/.guix-profile/bin/bzip2, there will be trouble, no?
<mark_weaver>on GuixSD systems, it's in /run/current-system (without the "/var" prefix). on non-GuixSD, normally you wouldn't have that directory at all, except perhaps to work around the locale issues, but then it wouldn't belong in /var/run
<taylan>I had one to make substitutor processes see locales, before we got GUIX_LOCPATH
<mark_weaver>ah, maybe /var/run and /run are the same directory (due to a symlink)
<taylan>when I run 'guix gc -R' for the /gnu/store/...-guix-... which all my users' ~/.guix-profile/bin/guix[-daemon] point to, I get /gnu/store/yq9vkx7f4zw17gs6b09bg4arcgmmjgxn-bzip2-1.0.6. this exists (is different from the one that's looked for).
<taylan>this /gnu/store/...guix... doesn't contain any file with the wrong reference, only the reference to the existing bzip2, in its .../share/guile/site/2.0/guix/config.(scm|go). I'm guessing that some old 'config.go' somewhere takes precedence over the config.go there.
<taylan>which is perhaps unsurprising since the config.go there is from 1970 :-)
<taylan>could it be that config.go didn't use to be in older guix packages, only config.scm, so now I have a config.go in my $XDG_CACHE_HOME which shouldn't be there? yup, I have a config.go for some old /gnu/sture/...guix... there!
<taylan>I also remember getting auto-compile messages for config.scm in the past, so I guess that's indeed the issue here. I wonder if this affects all guix users, guix-without-GuixSD users, or just me for some reason.
<taylan>mark_weaver: civodul: the issue is fixed after removing $XDG_CACHE_HOME/.../config.go
<mark_weaver>so, suppose you start with a profile that contains only "coreutils", and then concurrently run "guix package -i emacs" and "guix package -i bash" simultaneously.
<mark_weaver>then there will be two profiles built, one that contains coreutils and emacs, and another that contains coreutils and bash.
<mark_weaver>the new profiles are installed atomically, but the one that's finishes last will "win".
<taylan>I'm trying to find the config.go that gets loaded by running the daemon with strace, but I guess it's a subprocess that reads the config.go. gotta go AFK for an hour or so now, will continue debugging later.
<lfam>Trying to corral the bash headers is driving me crazy
<lfam>Can someone take a look at bash.scm and help me to alter the install-headers-phase to copy the files from the bash-4.3 tarball's include/ directory into the /gnu/store/...-bash-4.3.39-include/include/bash directory?
<lfam>The bash tarball has a bunch of headers at the top of the source tree, plus a few directories with more headers. The desired action is to copy all the top-level headers into the top-level of the store directory, and to copy the header-directories whole into the store directory. Except for one header-directory (include/) -- the files in this one should be copied into the top-level of the store directory.
<lfam>I wonder if this is really "right" but it's what Debian does and it's what recutils expects