<laertus>hmm... looks like "which guix" reports /usr/local/bin/guix which is a symlink to /var/guix/profiles/per-user/root/guix-profile/bin/guix which is still pointing to /gnu/store/vir3lrwqy50pr8fkaf3m091dgbrja2n6-guix-0.13.0/bin/guix
<Apteryx>laertus: simply running "make" doesn't install guix to your store.
<Apteryx>as for being root vs user for running "guix pull"; the one rule is that 'guix pull' updates the guix for the current user's profile. So each user can have a different guix version running. If you are running a foreign distro instead of GuixSD, the mean to update the guix-daemon is to "run guix pull && guix update -u ." as *root*. If you were using GuixSD you'd simply "guix system reconfigure
<Apteryx>/path/to/yourconfig.scm", and this would take care of updating the guix-daemon and other system components.
<laertus>so since i did the "./pre-inst-env guix pull" as my non-root user, am i going to have to re-do it as root?
<laertus>and how can i install the guix i built from source in to my store?
<laertus>i'd like to use it from now on instead of the 0.13.0 guix
<Apteryx>laertus: hmm, I'm not sure if you can install that exact version to the store, but you can retarget ~/.config/guix/latest --> ~/src/guix or wherever you are keeping the built from source guix copy.
<laertus>i'm also going to have to change my $PATH to use it too, right?
<laertus>because right now it's picking up /usr/local/bin/guix which is a symlink to /var/guix/profiles/per-user/root/guix-profile/bin/guix and that points to /gnu/store/vir3lrwqy50pr8fkaf3m091dgbrja2n6-guix-0.13.0/bin/guix
<Apteryx>But on a foreign distro I would advise you stick to the usual "guix pull". Back when I was using Guix with Ubuntu I couldn't find a way to run off the guix-daemon built from sources.
<Apteryx>So at least for the root user I highly recommend sticking to vanilla "guix pull"
<laertus>is there a way i could verify that once i point ~/.config/guix/latest to the right place it is in fact using the guix i compiled from source?
<Apteryx>laertus: from 0.13.0 to current it's going to require some pain as you found out if you don't want to use the substitutes, but after you're there if you keep doing it regularly things should go more smoothly.
<laertus>whether i can do it regularly will depend on how long it takes
<laertus>if every guix pull takes 2 weeks... i don't know...
<laertus>is it going to matter that i mix guix versions... with root using 0.13.0 and my non-root user using guix from git source?
<laertus>also, i'm having a hard time following why guix builds stuff... like right now i just tried a "guix pull" as root, with the old 0.13.0 guix, and one of the things it's doing is /gnu/store/f45mr3qc8kpw5ngnbzxsv9dkql9dayg6-guix-latest
<laertus>but since i already did a "./pre-inst-env guix pull" with my guix built from source, shouldn't it already have everything pulled in?
<laertus>and for root it'd be just a matter of linking it in to root's profile?
<laertus>i think i'm going to go read the guix paper and the docs
<Apteryx>as I said, each user can have a different guix version. All guix pull does is fetch the lastest guix from the master git branch of the repo, built this, copy it to the store and update $USER/.config/guix/latest --> /gnu/store/that-fresh-guix-copy
<adfeno>Remember that pre-inst-env puts you into a place where you are somewhat like into another session shell
<laertus>so the symlinking that's advised in that mailing list post probably is not appropriate for me
<adfeno>the reason pre-inst-env exists is to *develop*/test Guix internals.
<laertus>i understand.. that's why i was asking earlier how to just install the guix i built from source in to my store
<laertus>but Apteryx advised i just keep it where it is and symlink my ~/.config/guix/latest to it
<adfeno>Indeed, it's not for us right now, if we are no longer be using "./pre-inst-env guix pull"
<adfeno>laertus: Assuming that the Guix source repository is where the .scm and .go files are (which should have used and generated by "./pre-inst-env guix pull" to update the list of recipes), then we can do:
<Apteryx>laertus: the reason I advise against root + symlink to guix checkout is that from my experience, the guix-daemon won't be working or updated that way.
<adfeno>laertus: Basically, what you win in short-term by not having to "guix pull" twice, you loose in long-term by being unable to work or update guix-daemon.
<laertus>Apteryx: maybe you could shed some light on why a "guix pull" as root with guix 0.13.0 is trying to install /gnu/store/f45mr3qc8kpw5ngnbzxsv9dkql9dayg6-guix-latest after a guix pull under pre-inst-env of a guix built from source already installed /gnu/store/98h0ib3397bc1gm1k1gpw12xg3lz38vb-guix-latest
<laertus>why can't root just use the guix-latest that's already there?
<laertus>as long as i could find some way to enable that globally, that would nice
<mb[m]2>Then you would not be able to use substitutes anyway.
<laertus>unfortunately, i have had to use substitutes for libgit2 recently.. and for guix-git
<laertus>as i seem to recall both having hash mismatch issues
<laertus>i guess if that ever happened again and i was using optimizations i'd be stuck, as i couldn't use substitutes to fix my system
<laertus>then there's the test issue... where guix by default runs all the tests of the packages it builds.. and automake's own tests of itself take 4 hours on my system
<mb[m]2>At least for libgit2, you would only need a copy of the original tarball. `guix download` would do the job.
<laertus>except that the tarball hashes don't match
<mb[m]2>I suppose you could also hack gnu-build-system to set '#:tests? #f'.
<laertus>there's a bug and big discussion on the mailing list about that
<laertus>i'm sure it'll be fixed in time.. but something else might require the use of subsitutes in the future
<laertus>yeah, i was planning to hack guix to disable tests globally
<mb[m]2>I meant you could use `guix download` on a known-good copy instead of fetching a substitute.
<laertus>maybe.. i know guix download was considered earlier
<laertus>but wasn't working on directory trees, which was what we got from a git checkout
<laertus>for some reason just a guix download of the tarball wasn't enough.. probably because of the hash mismatch
<laertus>anyway... i think i might have to postpone my adventures in guix until i get a much faster machine
<laertus>if there's a lot more compilation on guix than gentoo... well, one of my main reasons for trying to to guix (apart from loving scheme and wanting reproduceable builds, etc) was try to find a way to compile a lot less than gentoo
<laertus>(without going to just downloading binaries)
<mb[m]2>It works pretty well when you have multiple machines, but for a single laptop running without substitutes is not going to be easy :/
<laertus>not just a single laptop, but an old, slow laptop
<laertus>where i'm doing a lot of other stuff besides
<laertus>i think i bit off more than my laptop can chew
<Apteryx>laertus: Are you sure when you did guix pull that it took 2 hours building guix alone? If it was building new or updated dependencies of Guix that might explain it. On my 2011 laptop it takes about 15 minutes on 2 cores. I'll time it next time.
<Apteryx>oh, maybe you were swapping? How much ram do you have in there?
<laertus>Apteryx: i am sure.. and i don't have swap
<laertus>i'm pretty sure it wasn't building guix from absolute scratch.. because that takes much longer
<Apteryx>even without swap (I don't use it) it somehow slows to a crawl and manages to use the disk when the RAM fills up.
<roelj>So, why do some search paths end up in 'guix package --search-paths', and some don't? I added (native-search-paths (list (search-path-specification (variable "TEST_ME") (files '("/etc"))))) to a package defition, but TEST_ME is not set on 'guix environment' and not displayed in 'guix package --search-paths'.
<efraim>trying again for mongodb with 20GB of swap, maybe this time it'll build
<efraim>I finally learned about % moving between opening and closing brackets/parenthesis/etc in vim, definately helps with I forget to close a parenthesis
<roelj>sneek: later tell civodul Bug #22138 does not solve my problem. I notice that when I change the value of 'files to "lib", then it works. Does it do file checking somehow? If so, where does it do that?
<Apteryx>efraim: OK! Have you tried the --cores argument to limit it?
<Apteryx>efraim: I personally don't want to touch lisp without paredit in Emacs ;)
<Apteryx>OK, I'm trying to automate a script that will fetch all the potentially problematic github packages (I already have a list of those) and list the ones whose hash now fail. What Guix procedure should I use here. Right now I'm thinking "guix-build" with the --source and --no-substitutes options.
<Apteryx>Maybe I could simply build the file-like part of it (the origin record of a package definition)?
<rekado>Apteryx: have you tried the github-package? predicate?
<Apteryx>I haven't. But that part is solved already :)
<Apteryx>any way to force redownloading the source of a package without using substitutes? I tried (guix-build "--source" "--no-grafts" "--no-substitutes" "libgit2") but if it's already been cached in my store it won't redownload again.
<kristofer>disclaimer: not a pro guixer.. just a curious amateur schemer
<IpswichTriptych>Should I always run $ guix pull only as root if I'm on a one-person desktop? I successfully completed a $ guix pull as my primary user (which I was very excited about since I'm on a slow, resource-constrained laptop and have been having troubles doing so), and then when I went to do $ guix system reconfigure as root, it said guix pull had never been run :/
<kristofer>IpswichTriptych: you really only need to run guix pull as root if you're going to guix reconfigure
<kristofer>I wouldn't really install any packages as root.. I would put those packages in the operating-system declaration of the system configuration
<IpswichTriptych>By adding (service guix-publish-service-type) to my configuration file, will my derivations be available to other users with similar hardware? It would make me feel better to know that I was helping other users.
<Apteryx>kristofer: it seems in my case (archive is valid and in the store), it won't help since it doesn't redownload it in that case.
<Apteryx>I'm trying to get into the "wrong hash upstream" scenario even though I already have a valid substitute installed in my store. Tricky so far. I think I have to go manual route and use guix download
<kristofer>IpswichTriptych: I doubt it works that way. I think it is for situations where you would run a private package substitute server
<IpswichTriptych>Meaning I'd have to privately share them, they wouldn't get automatically included in mirror.hydra.gnu.org?
<kristofer>right. it all comes down to trust I'd guess. kind of what Apteryx is trying to figure out I think
<bavier>IpswichTriptych: if the machine running the guix publish service is accessible over the internet, others would just need to add it to their substitute urls
<mekeor>i like fonts, so i had installed all available font packages… it wasn't a good idea.
<buenouanq>I did that and it didn't cause any problems for me...
<Apteryx>I had atrocious fonts rendering some time ago. I don't recall exactly how I fixed it, but I have a fontconfig file for turning the antialias on and I think I told Icecat to use my "system fonts" instead of whatever the pages request, and default to DejaVu Sans Size 16.
<civodul>and yes, when there are enough intel substitutes, you can merge IMO
<civodul>i suppose most of the missing binaries are ARM, right?
<TaoHansen[m]>the console fonts on the live disk are tiny. i'm trying to change the font with `setfont` but the directory where fonts are stored must be non-standard. where are fonts on the usb image located?
<TaoHansen[m]>people on Arch Linux sources were suggesting setting the console font to ter-132n but Guix's font-terminus doesn't even include this Terminus variant. looks like it's time to SSH into this machine and finish the install from my othe r machine.