<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" <laertus>i got: "guix download: error: build failed: regular file expected" ***Piece_Maker is now known as Acou_Bass
<Apteryx>laertus: there's a section in the manual where it is explained how to get the hash of a git checkout <laertus>i'm just having a problem with the "guix download" command <laertus>i was able to do the git checkout of the right hash just fine <Apteryx>hm, what are you trying to achieve with the "guix download" command? <laertus>and civodul said: "the repo has changed URLs, it's now at guile-git/guile-git" <laertus>"so either you enable substitutes temporarily while you run "guix build -S guile-git"" <laertus>"or you clone the repo and then "guix download" from the local checkout" <laertus>per his instructions, which i mentioned earlier <Apteryx>I'm not sure if guix download can work on directories. The doc doesn't mention it. <Apteryx>do you have a copy of guix? You could simply fix the package uri, run ./pre-inst-env guix pull to make sure it works, and then send the patch! <laertus>well, i can run "guix pull", so i presume i do have guix on my system <Apteryx>guix pulls gives you a read-only guix copy in the /gnu/store <laertus>this was the first "guix pull" that i've done <Apteryx>it's nice as a user and prevents breaking it, but when we want to fix a package we need a local guix checkout. <Apteryx>Let's see if there's a substitute available. <laertus>i've been wanting to avoid substitutes <laertus>that's why i've been running guix with --no-substitutes and finding all these lovely errors :) <Apteryx>OK. No problem then. There are many ways to get passed that problem. I have another idea. <Apteryx>Hm. The package is already fixed in Guix since the 1st of July. <Apteryx>0.13.0 was released end of May, so that explains why you don't have that. <Apteryx>and it seems you now need guile-git to update using guix pull, hmm. <Apteryx>I also get: guix download: error: build failed: regular file expected when trying to add a directory. <Apteryx>I think it only works with files. So you need another way. <laertus>and i expect i can't just tar/gz up that directory and give it to guix download that way? <Apteryx>I think you need to get it to the store in the exact form it would have been if it would have been fetched from git. <Apteryx>I'm looking at my guile-git entries under /gnu/store <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. <Apteryx>Have a look at the "Contributing" chapter of the manual. It covers the basics. <laertus>i presume the procedure there will also integrate the newly built guix in to /gnu/store somehow, so it's part of my guix install? <Apteryx>laertus: guix pull always end putting something in your store, no matter what guix was used to run it. <Apteryx>and it will cause your ~/.config/guix/latest symlink to point to that item in the store. <Apteryx>happy_gnu[m]: indeed, doesn't seem to be packaged. <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>should i just try --localstatedir=/var ? <Apteryx>I agree this part is a bit hard to follow... <Apteryx>It's worded that way because it could differ depending on your distribution (if you were using a foreign distribution instead of GuixSD). On GuixSD, it's /var <laertus>it'd be nice if it said something to the effect of "if you're using the guix binary that you did not build yourself and you're not on GuixSD, then just use --localstatedir=/var" <Apteryx>laertus: maybe send this suggestion to guix-users or guix-devel! <efraim>python-pandas, python-cffi and ruby-concurrent are on my hit list, they don't like building on aarch64 <efraim>configure: error: The current version of Virtuoso Open Source Edition (Column Store) can only be build on 64bit platforms <Sleep_Walker>is it possible to send patches as e-mails directly from magit? <rekado>Sleep_Walker: afaik it is a planned feature. <rekado>you can format a patch with magit, however, so it shouldn’t be too hard to write some glue to take that patch file and run git send-email on it. <rekado>In the future we should upgrade scipy together with numpy whenever possible <rekado>the scipy developers don’t seem to fix bugs in older versions when building with slightly more recent versions of numpy <civodul>rekado: someone upgraded numpy recently no? <rekado>civodul: on Sept 26 numpy was upgraded to 1.13.1. <rekado>that seems to have broken a couple of packages. <rekado>for cuirass I’d like to have a way to display build failures that are important to me. <civodul>rekado: BTW, we need to reconfigure berlin with the latest maintenance.git <civodul>apparently nginx lacks the thing that redirects /api URLs <civodul>you could "herd stop nginx" just before <civodul>wigust: i just saw your subscription request to guix-sysadmin <civodul>are you sure you want to subscribe? [ ] OK [ ] Cancel <civodul>(you're welcome to help on that front obviously, just checking) <wigust>civodul: Hello! [x] OK :-) Yes, I'm interested in. <rekado>civodul: berlin has been reconfigured <efraim>for our next core-update cycle do we want to upgrade our default gcc to gcc-6? <rekado>civodul: thank you for the weak-table patches! <rekado>hmm, all packages using the numpy setuptools extensions fail <rekado>the error is always that some gcc or g++ command fails with error 127 <efraim>Out of memory? Or is that error 4 <rekado>the upgrade changed numpy/distutils/unixccopmiler.py <rekado>it passes -MMD and -MF to the compiler and a “.d” file <rekado>hmm, that stuff works outside of the build container <rekado>civodul: I reconfigured berlin (with cuirass and nginx stopped), but /build and /api don’t seem to behave correctly <rekado>ah, had to remove /var/run/cuirass/cuirass.db <rekado>setting the SHELL environment variable fixes everything <rekado>so… guess we’ll have to fix this in numpy <civodul>rekado: i must have messed up with the nginx config, dunno <efraim>i finally realized that gcc-boot0's native-arguments uses alist-remove until its down to an empty list <efraim>the only thing I can think that might be missing with Apteryx's patch is removing the duplicate man pages from custom-gcc, and that's fine <rekado>something’s really wrong with pandas <rekado>30 test failures and 2247 errors :( <efraim>is it related to the cython update? <civodul>rekado: trying to be reassuring, but 2K failures is often easier to debug than a single test failure :-) <rekado>I have an idea about the 2k failures, but the 30 other failures look bad <rekado>and it’s annoying that I need to recompile numpy and scipy each time I update a package that might fix things <rekado>ACTION feels that a lot is broken right now :( <rekado>the scipy tests take several hours and use a lot of RAM <rekado>maybe we should switch to the “fast” test set instead of “full”. <rekado>ACTION tries to build python-pandas again… <civodul>rekado: yeah i also have that feeling of brokenness <civodul>what keeps me awake at night are the two compiler/libguile bugs: the one you reported, and the weak-table thing <rekado>about guix pull: can we revert to using a single guile process for the compilation of each file? <rekado>it’s going to be slower, but I think that’s better than the current situation where we have a pretty narrow range of machines where it actually works <civodul>could you try reverting f07041f7d25badb7d74b8fad6ee446a12af04f63 and see how that performs? <rekado>ACTION still hasn’t succeeded in upgrading guix on the big 1.5TB RAM server <rekado>civodul: okay, I’ll give that a try tonight on my i686 with 1GB RAM. <dustyweb>civodul: kind of a cool aside, I am in a room with Mark Miller of capabilities / erights! <dustyweb>and he is going to be talking about capabilities things <dustyweb>actually this is more #guile appropriate :) <civodul>dustyweb: ooh, i'm a big fan of Mark Miller's work <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>"warning: arbitrarily choosing /gnu/store/ri56wnmzkgzrajdyl5ydc55lrwy1164k-ld-wrapper-0/bin/ld" <rekado>laertus: these are benign warnings. <rekado>it means that two packages both provide a file of the same name <rekado>Guix just picks the first, because in a single profile you can’t have two files of the same name. <rekado>the ld-wrapper’s ld happens to be the better choice here <rekado>I’m now running “guix pull” after reverting f07041f7d25badb7d74b8fad6ee446a12af04f63 <laertus>the next step is to "Run ./bootstrap to generate the build system infrastructure using Autoconf and Automake." <laertus>i presume they mean the "./bootstrap" from the guix git source code <laertus>but there's no link to it on that page <bavier>laertus: have you clone the git repo? <laertus>bavier: i haven't because i don't know where it is.. there's no link to it on that "Building from Git" reference manual page <bavier>laertus: sorry, I misunderstood what link you were asking about <jonsger>laertus: yes, there is room for improvement in that part of the documentation :) <bavier>rekado: is reverting that commit meant as a workaround for the guile memory problem? <lfam>laertus, jonsger: The latest revision of the manual (in Git) includes instructions about where to get the source code <laertus>lfam: that's only helpful if you know where to clone the git repo from ;) <lfam>The web-based manual is kept synchronized with the latest release... I know, it's annoying to not have the latest copy online. <rekado>bavier: yes. I’d like to be able to run “guix pull” again on systems with very large and very little memory <lfam>Now you can do `make doc/guix.html` and browse the latest revision of the manual locally :) <lfam>Also, on GuixSD, `info guix` should show you the manual revision corresponding to `guix --version` <jonsger>lfam: okay :) thats annoying, we should maybe offer both. the stable and the recent version <lfam>I agree, it would be an improvement <lfam>Although... it would cause a different sort of confusion. The situation will never be perfect :) <rekado>well, we could name it differently <rekado>but wasn’t the problem that gnu.org uses CVS and thus makes it harder for us to just publish an up-to-date version of the manual? <lfam>I actually don't know how the manual is deployed <laertus>when doing a "./configure --localstatedir=/var" i got a configure error: "No Guile development packages were found." <lfam>Although I think the default manual should correspond to the latest release, we should be pushing "bug fixes" to it <lfam>laertus: Are you building Guix from the v0.13.0 release tag, or the latest revision? <rekado>lfam: according to the release documentation it’s generated with gnulib’s gendocs, and then manually deployed to the website <lfam>laertus: Okay, I would start debugging by making sure you are still in the `guix environment guix` (and I recommend adding --pure to that command), and inspecting the result of `env` <laertus>when i do an "env | grep GUIX" i see "GUIX_ENVIRONMENT=/gnu/store/jqs80jq4j9z06p2vb9f7djv9k7jmc3d4-profile" <lfam>Right, that's what `guix environment` does: changes the environment variables <lfam>Go into that profile directory and see if Guile is in there <laertus> /gnu/store/jqs80jq4j9z06p2vb9f7djv9k7jmc3d4-profile/bin/guile -> /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guile <lfam>I *think* the relevant variable is LIBRARY_PATH, which should point to /gnu/store/...-profile/lib <laertus>LIBRARY_PATH=/gnu/store/jqs80jq4j9z06p2vb9f7djv9k7jmc3d4-profile/lib <lfam>Right, check if it contains libguile :) <lfam>If it does, I would re-try configuring, but with the --pure argument to `guix environment guix` <laertus> /gnu/store/jqs80jq4j9z06p2vb9f7djv9k7jmc3d4-profile/lib/libguile-2.2.so.1.2.0 -> /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/lib/libguile-2.2.so.1.2.0 <lfam>Try `guix environment --help` :) <lfam>The point is that, without it, there's a chance that extraneous environment variables will effect the build in unexpected ways <laertus>ok, it's failing with the same error even with --pure <lfam>Can you put the full output of configuring on paste.lisp.org? <laertus>dos it have to be that pastebin, or can i use another? <lfam>You can use another if you prefer <lfam>Some of them are not accessible for some Guix developers, but I should be able to view any of them <laertus>i think i put the --pure flag in the wrong place <laertus>i did a "guix environment guix --pure" <laertus>wheni should have done "guix environment --pure guix" <lfam>I don't think that flag is positional, but you might as well <laertus>actually, i'm pretty sure "guix environment guix --pure" did change my environment, because stuff started to break and i had to fix it <lfam>It shouldn't affect anything outside of the session in the terminal where you run it <laertus>but, yeah, i just tried it with "guix environment --pure guix" and got the same error <lfam>Can you also paste the result of `env` in the environment? <laertus>it didn't affect anything in the shell that i ran it in, but it did affect the new shell it put me in to <laertus>it definitely still has a ton of my local enviornment vars there <laertus>no matter where i put the --pure flag <lfam>If you're using Bash, I assume your ~/.bashrc is exporting environment variables, which is incorrect. That should only be done in ~/.bash_profile. <lfam>Okay, then ~/.zshrc vs ~/.zprofile <laertus>yeah, i have a lot of stuff in .bashrc <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 <lfam>Cool, you're ahead of the game <laertus>and this is going to be inconvenient for me in the long run, because i frequently alter my .zshrc and don't want to have to log out and log back in to get the new changes <laertus>i'll just get guix working first, if i can <lfam>You can use `zsh -l` to launch a new login shell immediately <laertus>yeah, but then i'll have to do that for every new shell <laertus>anyway, i think for just this guix build i can try moving my .zshrc aside and see what happens <laertus>hmm.. "configure: error: Guile-Git is missing; please install it." <laertus>the whole reason i was trying to build guix from source is because "guix pull" was failing for me when it got to guile-git <laertus>and i couldn't figure out a way to get it except from substitutes, and i don't want to use substitutes <laertus>but since guix from git seems to depend on guile-git, i don't know what to do <lfam>The issue with guile-git is that the upstream source URL was changed and there is no redirection from the old URL <laertus>civodul advised me: "so either you enable substitutes temporarily while you run "guix build -S guile-git" <laertus>"or you clone the repo and then "guix download" from the local checkout" <lfam>I saw in the logs that you learned you can't `guix download` a directory <lfam>I would use our substitute. The SHA256 hash verification is a strong guarantee that it's identical to what you'd get if the old guile-git site was still online <lfam>Maybe there's a workaround to be found, but I haven't thought of one yet <laertus>could i alter the guix build scripts to just use my regular system git? <lfam>Perhaps? This is uncharted territory :) <laertus>i'm not sure if i'm ready to go there, though... <laertus>i'm going to peek in the build scripts... <laertus>oh, btw, i don't need to do a "./bootstrap" every time i get a new shell with "guix environment guix --pure" do i? <rekado>bootstrap generates the “configure” script from “configure.ac” <rekado>unless you change “configure.ac” you have no reason to run “bootstrap” again. <laertus>i'd have to at least reimplement the various guix-git calls that the guix source uses to instead use my system git <laertus>or change all those calls to use the system git directly <laertus>so how would i use that substitute just for guile-git? ***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<laertus>i think "guix environment guix --pure" should be able to start at least zsh with the -f flag to bypass the user's init files <laertus>if it does that, there should be no need for me to mess with my .zshrc just to satisfy guix <laertus>there's probably a corresponding bash flag as well <laertus>hmm... or maybe not... i think i need to test this more <laertus>ok, looks like the magic invocation for a zsh that doesn't contain my environment vars or source my zsh init files is: "env -i zsh -f" <laertus>it's be nice if "guix environment guix --pure" did that <laertus>actually... it looks like i can just run: "env -i /usr/local/bin/guix environment guix --pure" <lfam>laertus: "so how would i use that substitute just for guile-git?" <lfam>You'd only need to enable substitutes when doing `guix build --source guile-git` <laertus>it won't use substitutes for any dependencies of guile-git? <lfam>Assuming you're running the guix-dameon with --no-substitutes, no <laertus>so i'd do "guix build --substitutes guile-git" ? <lfam>No, something like `guix build --source --substitute-urls=https://mirror.hydra.gnu.org guile-git`. I don't know whether or not the daemon will respect --substitute-urls if it's launched with --no-substitutes <lfam>This will only use a substitute for the source code of guile-git. You'll still build guile-git locally <lfam>Okay laertus, I recommend restarting the guix-daemon without --no-substitutes and trying again <rekado>laertus: have you tried just installing guile-git without guix? <laertus>though i've tried so many things by now... i'm starting to get a little muddled.. but i'm pretty sure i haven't <mm__>im trying to compile guix on trisquel 7, and i get this error: "configure: error: 'guild' binary not found; please check your guile-2.x installation." but when i have guild installed <mm__>"whereis guild" output:"guild: /usr/bin/guild /usr/bin/X11/guild" <laertus>lfam: even when i start guix-daemon without --no-substitutes i still get the same error <lfam>mm__: I'm not sure. If nobody has any advice here, I recommend emailing your question to <help-guix@gnu.org> <mm__>ok, maybe i will try to write email, but first i will try on some newest system <Apteryx>laertus: arg, I see that my suggestion to use the latest guix from git was misguided... Sorry! <mm__>alezost, "guile (GNU Guile) 2.0.9" <laertus>alezost: good call... it looks like it's using my system guile, which is 1.8.8 <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. <mm__>alezost, "guild (GNU Guile) 2.0.9" <laertus>Apteryx: how would i do that? (fixed-content) <alezost>mm__: sorry, I don't know why you get that configure error then :-( <laertus>or i guess i could just wait until a new version of guix comes out <laertus>which has the right guix-guile repo location in it <Apteryx>laertus: I'm trying to find a mail civodul wrote about downloading substitutes straight from a substitute server (via http) <Apteryx>It's mentioned in the 'guix publish' node of the manual. <Apteryx>It returns: Resource not found: /file/1rdw2svz4pyislan7q67mnk70c13sczm-guile-git-0.0-2.06f9fc3-checkout <Apteryx>oh, I got the URI wrong. Let me try again. <thomassgn>anyone using console or emacs mail clients? How do you configure like fetchmail or similar? <thomassgn>Or, I guess, how do you get mail from the server AND send it out again? <Apteryx>You can probably get the core (imap fetch & smtp) configured with less than 10 lines of config. <laertus>and i use notmuch for mail, but i'm thinking of giving gnus a try <thomassgn>cool. Apteryx Ye, I assumed it would be short. But I often struggle with email conf. once it is more than what you have in thunderbird and similar <civodul>Apteryx: /file URLs only work for regular files, not for directories <Apteryx>thunderbird has lots of knobs to tweak as well ;) <Apteryx>civodul: I see! Seems we have one case of guix 0.13.0 not being able to upgrade to latest using guix pull because of guile-git (laertus). <laertus>i can't build guix from git source either <Apteryx>laertus: would you like to try a guix pack of guix itself? That'd be easier than a reinstall and would get you going *now* with latest guix. <Apteryx>Seems we've exhausted the other possible workarounds. <laertus>Apteryx: is there any way to verify that i'm getting an untampered package? <Apteryx>I guess you could do 'guix gc --references /gnu/store/hash-guix-latest/' on the guix that was unpacked in your store, and then compare with what's in hydra (on the build farms)... <Apteryx>or better, run 'guix build --check' on the dependencies to make sure you can reproduce them (with the latest guix). <laertus>no chance that something naughty might have been done by the package before i check? <Apteryx>guix derivations are not content addressed, so I don't think you could ensure that it wasn't tempered with. Someone correct me if I'm wrong! <laertus>could i just look it over visually myself before i applied it? <Apteryx>I guess you could diff the components of the pack (after extracting them somewhere) against derivations with the same hashes downloaded from the store. <Apteryx>s/from the store/from one of the substitute servers/ <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. <lfam>I recommend trying again. It's possible that when you tried it, our caching server did not have what you were requesting, but it does now <laertus>ah, but i was using --no-substitutes <laertus>actually, i did try without the --no-substitutes once too <lfam>I had suggested you use a substitute just for the source code of guile-git, and you said it didn't work. But perhaps we misunderstood each other <laertus>i was just getting confused with all the different things i tried.. mostly i did use --no-substitutes, but once i had tried without --no-substitutes, just for the "build --source guile-git --subsitute-urls=https://mirror.hydra.gnu.org" <lfam>What is `guix --version`? <laertus>but "which guix" reports "/usr/local/bin/guix" which is symlinked to /var/guix/profiles/per-user/root/guix-profile/bin/guix <laertus>and that's symlinked to /gnu/store/vir3lrwqy50pr8fkaf3m091dgbrja2n6-guix-0.13.0/bin/guix <laertus>the sha256 of that is f27b607de96c1e09c32659c724b5d9627432ea1e6ff6488c1e0f3a780517ce81 <lfam>laertus: From your earlier paste: substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized, <lfam>You haven't authorized our substitute signing key, so you can't use substitutes even if you want to <lfam>You can authorize them, get the guile-git source code substitute, and then erase /etc/guix/acl to de-authorize the key <laertus>where is /etc/guix/acl located on a non-GuixSD install? <lfam>I use Guix on Debian and it's at /etc/guix/acl <lfam>Did you authorize the key yet? <lfam>The directory will be created when you authorize the key <laertus>ok, it did create /etc/guix as you said <laertus>ok, let me try the guix build again... <laertus>"@ substituter-succeeded /gnu/store/1rdw2svz4pyislan7q67mnk70c13sczm-guile-git-0.0-2.06f9fc3-checkout" "/gnu/store/1rdw2svz4pyislan7q67mnk70c13sczm-guile-git-0.0-2.06f9fc3-checkout" <laertus>so should i just try a "guix pull" now? or should i try to continue building guix from git source instead? <lfam>Remember to deauthorize the key before going further, if you don't want to use more substitutes <laertus>i tried continuing the guix source build, but "./configure --localstatedir=/var" is still complaining that "Guile-Git is missing; please install it." <lfam>Now you need to build guile-git. `guix build guile-git` <lfam>Or, something like that. I don't remember if you are using `guix environment` anymore :p <laertus>for the attempt at building guix from git source i was under an "env -i guix environment guix --pure" <laertus>but i have another shell which is just a regular shell, and that's where i just ran the "guix build guile-git" <laertus>i'm not sure if it's best to always interact with guix under a "env -i guix environment guix --pure" just so my regular environment vars don't mess with it <laertus>hmm... i'm getting a ton of errors like "ERROR: failed to create path for auto-compiled file "/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild"" <lfam>laertus: Those are harmless, they are really just warnings. <lfam>It's a side-effect of the transition from Guile 2.0 to Guile 2.2. Once your full Guix installation is upgraded to use Guile 2.2, these messages will go away <laertus>alright, well, i got "@ build-succeeded /gnu/store/qiy2gcrwmfbi73g2c0nl1ibdvbkw5w1k-guile-git-0.0-2.06f9fc3.drv -" "/gnu/store/fs6ism783xcjhsg13s13zkdz7c4cp75d-guile-git-0.0-2.06f9fc3" <laertus>but i get the same complaint from "./configure --localstatedir=/var" in guix git source: "Guile-Git is missing; please install it." <lfam>I'd try something like this: `guix environment --pure guix --ad-hoc guile-git` <laertus>i'm glad you know what you're doing... because with your help i'd be totally lost :) <lfam>I only sort of know what I'm doing ;) <laertus>ok, that looks better.. configure is getting a lot further now <lfam>I have to admit, this guile-git / gitlab issue has been pretty annoying. And your preference to not use substitutes makes these problems more prominent. <lfam>We'd prefer if this stuff was easier, of course <laertus>someone has to test the --no-substitutes option, right? :) <civodul>as discussed before, the source could be retrieved by temporarily enabling substitutes and running "guix build -S guile-git" <laertus>it's funny.. i guess i must be the sole person using --no-substitutes <civodul>laertus: at least build farms are not using substitutes, and there are users as well <laertus>i wonder how the build farms worked? <civodul>but the thing is, they may have fetched that guile-git checkout before <laertus>i guess it might be a good idea to periodically have automated fetches of all the dependencies <laertus>or you could just wait for me to find them... eventually... <laertus>my guix make is chugging along now... <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 <civodul>hmm where was the guile-git issue discussed on the list? <bavier>civodul: it was discussed on irc earlier <bavier>idk if it was taken to the list yet <bavier>the README mentions guile-gnutls as optional, but configure will not continue without them <civodul>oh right, guix.texi is up-to-date, but README probably not