<mark_weaver>you need to set the environment variables as "guix package" should have suggested after you installed gcc-toolchain, etc, notably LIBRARY_PATH, CPATH, PKG_CONFIG_PATH, ACLOCAL_PATH, PATH, etc..
<mark_weaver>if you're going to be building software manually, you need to ensure that 'configure' will not pick up stuff from Debian.
<mark_weaver>that means that when configuring and building the software, PATH should not include /bin or /usr/bin
<abnegate>so i wouldn't use "guix build foo" to build from "foo.scm" definition?
<mark_weaver>no, the argument to 'guix build' is not the scm module/filename.
<mark_weaver>'guix build' loads all files in gnu/packages/*.scm (and also all *.scm files within the directory tree rooted in GUIX_PACKAGE_PATH) and scans those modules for variables bound to package objects.
<mark_weaver>abnegate: that could be true, I don't claim to be a git expert
<mark_weaver>my personal method is to use 'git-new-workdir' (a script in the contrib directory of the git source code but not normally installed) to create multiple working directories that share a single local git repository.
<mark_weaver>so I have multiple working directories on different branches, and among them are 'guix-master' which is upstream master and then 'guix' which is my own private branch.
<mark_weaver>so I "git pull" from 'guix-master' and then "guix rebase master" from my private branch in 'guix'
<mark_weaver>I prefer to keep my local changes in the form of patches based on current upstream master
<mark_weaver>this allows me to have my own private branch but also make changes to upstream master and push them to our git repo.
<mark_weaver>abnegate: one last note: in order for the 'guix' from git to take over from your current setup, you must ensure that --localstatedir (specified to ./configure) is the same as for the guix system you're currently using.
<mark_weaver>otherwise it won't be able to find the 'sqlite' database and other things that you have in place now.
<rekado>using a shared /gnu/store for lots of users I encountered a recurring annoyance.
<rekado>Often when I update guix to get the latest packages I see that minor changes make me install a new version of python and numpy in particular.
<rekado>Since the version number hasn't changed but only the hash (as inputs have likely changed) I'd very much like to replace the previously installed versions in the store with the new ones for *all* users.
<rekado>I don't really want to have to upgrade each profile. I want to avoid actually upgrading to any newer versions. Just want to have everyone use the latest "incarnation" of the version they have installed. Then I could also purge the older incarnations from the store to save space.
<rekado>Is there a safe way to "upgrade" a profile's packages without upgrading the versions?
<abnegate>davexunit: isn't there some way configure could be a little smarter about this and tell me in advance i need something that i don't have installed before my make begins?
<rekado>civodul: say I install scipy for a user on Monday. On Tuesday there is an update to the inputs of Python. On Wednesday I update Guix to get my latest bioinfo tools. Then I install scipy for another user.
<civodul>abnegate: ./configure doesn't warn you about missing graphviz because it's not needed when building from a tarball, as davexunit wrote
<rekado>This happened often enough in the past. I'm *again* downloading (or trying to download) texlive because numpy needs to be built from scratch for some reason (even though I installed it before for some other user).
<rekado>re ~/.config/guix/latest symlinks: I don't know what this means -- I'm usually running make install as root to upgrade guix globally on the server.
<civodul>rekado: you should write somewhere about your experience with Guix-on-cluster
<rekado>I'm planning to do that tonight, actually.
<civodul>rekado: last time i ran "make install" was months ago
<civodul>the normal way is just "guix pull", which works per-user
<civodul>maybe that partly explains the pain you've endured?
<civodul>i mean, if a user install numpy, then days later installs texlive, presumably the texlive is already in store
<civodul>unless they run 'guix pull' in the meantime
<civodul>or the admin did 'make install' in the meantime
<rekado>but I'd still have the same problem if I installed numpy for another user if guix had been updated since the last installation of numpy for another user.
<rekado>I didn't have much of a problem with individual user profiles yet (e.g. installing texlive into a profile that already has numpy installed), because we're only just begun making people use Guix software profiles.
<civodul>well, each user could be running a different revision of guix, presumably leading to different variants of numpy
<civodul>syncing the ~/.config/guix/latest links could mitigate that
<rekado>with "make install" isn't guix the same for everyone? I haven't used "guix pull" even once in this environment.
<Kolt>bavier: I compiled guix successfully (instead of downloading from my distro's available options), created the build user, and such. When I tried to test install guile, the computer ran out of memory and I had to turn it off. After booting up again, I find that I can't use the socket anymore, there's just no way.
<bavier>Kolt: you may have had substitutes disabled, in which case you would have been building all packages on your machine.
<bavier>the socket you can't use; are you referring to the guix-daemon socket?