<Apteryx>If you use Gnus I can share a useful splitting rules snippet.
<laertus>when i tried to follow civodul's instructions above to clone https://gitlab.com/guile-git/guile-git.git then checkout the commit that i found the hash of in "guix edit guile-git", then "rm -fr .git" in that directory and then do a "guix download file:///that/directory"
<Apteryx>Tough luck. I think I'd just use a guix checkout, build it locally, pull from that, and then go on with life.
<Apteryx>It'll have the interesting side effect of having you setup what you'd need to contribute a package or any change to Guix anyway, which comes handy when we find a problem we want to fix ourselves.
<laertus>ok, so you're recommending i just build myself a new version of guix?
<Apteryx>unless someone else knows better, that'd be my suggestion, yes.
<laertus>Apteryx: the "Building from Git" section of the reference manual says "run ./configure as usual. Make sure to pass --localstatedir=directory where directory is the localstatedir value used by your current installation" and points me to "The Store" section of the manual for more info
<laertus>that section says "This database resides in localstatedir/guix/db, where localstatedir is the state directory specified via --localstatedir at configure time, usually /var"
<laertus>how do i know what -localstatedir was at configure time?
<laertus>when doing a "guix environment guix" i got a "warning: collision encountered: /gnu/store/ri56wnmzkgzrajdyl5ydc55lrwy1164k-ld-wrapper-0/bin/ld /gnu/store/zq65kpvwwxgc3qqbf9apic8gyss2l0zq-binutils-2.27/bin/ld"
<laertus>ok, i'll alter my startup scripts to just use .zprofile
<lfam>I didn't grok the difference between login and interactive shells until I started using `guix environment`. But the point is that environment variables should only be exported in login shells ~/.zprofile. Otherwise it's impossible for applications to launch new interactive shells (~/.zshrc) cleanly
<Apteryx>laertus: it seems your version of guix won't allow you to move further. Maybe you could try a 'guix pack' of guix itself? I you don't mind putting the trust in one of us, we could provide such an archive to be unpacked in your store... and then you could use that to bootstrap a recent guix.
<alezost>mm__: this version should be enough; I see "whereis" also shows some other "guild"; run "guild" to check it comes from Guile
<Apteryx>laertus: but if you could fetch the fixed-content (source) substitute you need for guile-git, that'd be ideal as you wouldn't need trusting more than that substitute.
<laertus>and can i then install the pack directly from my filesystem?
<Apteryx>laertus: I'm pretty sure what unpack does is decompress & untar the archive to you store. So you could list the contents of the pack archive, install those to your store, and then inspect them before running that specific guix (it won't override your guix), you'll have to run it with teh full path /gnu/store/...-guix-from-guix-pack/bin/guix or similar.
<laertus>after the make of guix is done, do i just do a "make install" and then a "guix pull"?
<ng0>hey, could anyone test my theory that getmail ~somehow~ broke in the last 3 days due to some package in its graph? I get errors with getmal 5.1 and 5.2 (5.2 is not in tree, been kinda busy fixing stuff)
<ng0>gotta go, I'll check back at around 0600 if there was a reply, otherwise I'll send a bug report
<civodul>rekado: berlin doesn't seem accessible over http