IRC channel logs


back to list of logs

<adfeno>Hi all! :)
<adfeno>#guix: Has someone found some issues while building webkitgtk-2.18.0?
<laertus>wow.. i finally managed to complete a "guix pull"
<laertus>only took 2 weeks
<laertus>couldn't have done it without the help of lots of people here and on the mailing list
<laertus>thank you!
<laertus>question: when "guix pull" finally finished, it told me "updated GNU Guix successfully deployed under `/home/me/.config/guix/latest'"
<laertus>how do i use this information? do i need to know this for anything?
<laertus>i thought everything was linked in to ~/.guix-profile
<laertus>what's ~/.config/guix/latest for, vs ~/.guix-profile ?
<adfeno>laertus: After doing guix pull, do: guix package -u
<adfeno>Actually, if you're running as root, first do: guix package -u guix; then: guix package -u
<laertus>i didn't run "guix pull" as root
<laertus>and, it's not entirely accurate that i ran a mere "guix pull", what i did was compile guix from git source and then did a "./pre-inst-env guix pull"
<adfeno>Which one are you attempting to do: (a) install Guix; (b) develop Guix.
<laertus>well... mostly just install... however, i do want to modify guix in one way: i want to turn off all the tests it does when it builds packages
<laertus>they take way, way, waaaaay too long
<laertus>first i wanted to get the base guix system up and running, though
<laertus>so i think i did that, minus the package updates you recommend
<adfeno>I wonder if there is a special need for disabling the per-package tests?
<laertus>i want to disable them across the board.. i really don't have a need for them
<laertus>but i can foresee circumstances where for testing's sake, someone may want to test a specific package they're having problems with
<laertus>that someone may even be me someday :)
<adfeno>I mean, under a normal Guix install, there would be no need to do "./pre-inst-env guix pull".
<laertus>i was having lots of issues with a normal guix pull
<laertus>that's why i eventually compiled it from source
<laertus>also, i kind of wanted the latest.. and i didn't want to use substitutes
<adfeno>Oh... OK ;)
<laertus>anyway.. it's done.. so i think i'll just try to update the packages, as you say
<laertus>i'm just not clear if i need to do it as root or not
<adfeno>Hm... I guess not...
<laertus>do i still need to do the "guix package -u guix" first?
<adfeno>I'll also check the info page on how to use Guix with pre-inst-env
<adfeno>Hm... I guess we both must wait for someone more knowledgeable on pre-inst-env.
<laertus>from what i understood when i compiled guix from git source it already installed in to my store
<laertus>so i didn't really need to do a "./pre-inst-env guix pull" and could have just done a "guix pull" from then on
<laertus>(though i'm not 100% sure on that)
<adfeno>In a normal use case, "guix pull" would be "get the recipes for things".
<laertus>well, that definitely didn't happen for me
<laertus>it built the guix environment first.. which took about 2 weeks on my old, slow laptop
<adfeno>and "guix package -u" would be "upgrade the things I have installed based on the recipes my user has downloaded".
<laertus>also, i'm using --no-substitutes
<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>but any flavour of "guix pull" would
<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>(i'm on gentoo, btw)
<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>ah, i see
<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>well, one of the reasons i was trying to use the guix from git source was because the 0.13.0 guix pull wasn't working
<laertus>so i'm not sure if could
<Apteryx>laertus: no need to mess with your $PATH, there's already a bunch of wrapper scripts that do the magic for you when you retarget the ~/.config/guix/latest.
<Apteryx>It's still mysterious to me, but it works.
<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...
<Apteryx>It should take less than 15 minutes.
<laertus>looking forward to that
<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 guess i'm confused..
<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
<adfeno>... when you leave it, the env is gone.
<laertus>adfeno: you're not saying those 2 weeks worth of package builds under that environment are just going to disappear when i exit that shell?
<adfeno>Not exactly, the things might still be there...
<adfeno>.... the environment variables however, may get lost.
<laertus>so if they'll still be there... where exactly will they be?
<laertus>and why can't root just use them?
<adfeno>laertus: Perhaps one can do: "./pre-inst-env echo" just to get the environment back.
<laertus>i haven't really modified the environment
<laertus>won't i get the same one next time i run guix environment?
<adfeno>I was reading the pre-inst-env script, and it does seem to give you the same environment variables, so it seems to be more simple to get the environment back. :)
<laertus>so i still wonder where the stuff i pulled from the pre-inst-env went, and why root can't just use it
<laertus>the last step of my "./pre-inst-env guix pull" was "copying and compiling to '/gnu/store/98h0ib3397bc1gm1k1gpw12xg3lz38vb-guix-latest' with Guile 2.2.2..."
<laertus>and now when i'm doing "guix pull" with the old 0.13.0 guix as root it's "copying and compiling to '/gnu/store/f45mr3qc8kpw5ngnbzxsv9dkql9dayg6-guix-latest' with Guile 2.2.2..."
<laertus>why didn't it just use the guix-latest that the pre-inst-env installed?
<adfeno>Because it doesn't know about it?
<laertus>but it can see there is a "guix-latest"
<laertus>it says it's latest right in the name! :)
<laertus>anyway, shouldn't it just generate the same hash and look up guix-latest by that?
<adfeno>Hm... I just found something that might be helpful...
<adfeno>(assume "guix pull" in that message means "./pre-inst-env guix pull")
<laertus>ah, iteresting
<laertus>so what that seems to be doing is linking root's guix to the guix built from source
<adfeno>However, I wonder if there is a "$HOME/.config/guix/latest"
<laertus>but Apteryx was saying earlier that he doesn't advise that root use the guix built from source, and it's better that root sticks to the 0.13.0 guix
<laertus>otherwise i might have problems
<adfeno>laertus: Apteryx is right.
<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>... ... just read Apteryx's message ;)
<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?
<adfeno>laertus: This is a bit more technical, but might explain why:
<laertus>thanks... reading it...
<laertus>that's a very interesting post, and it does help me to further understand how guix works
<laertus>but i'm still not clear on why root would be downloading and compiling his own guix-latest when there's already one available
<laertus>presumably the hashes for the build should be exactly the same, no?
<laertus>and if they're the same, it should match the guix-latest already in the store
<laertus>but for some reason they're not the same
<adfeno>You see, GNU Guix is just a tiny thing that tells the *user's* GNU Guile to "run" the whole operation.
<adfeno>Sorry, I meant "guix" command, not "GNU Guix".
<laertus>yep, i see that, and i understand how the underlying code that does its thing will differ per user (if there are in fact relevant differences)
<laertus>but guix-latest is the latest guix, as far as i understand it... and like Highlander, there should be only one ;)
<laertus>(unless, of course, something upstream changed in between "guix pull" invocations... i'm presuming it didn't)
<adfeno>laertus: Well, I take that one should presume that. commits tend to come fast :)
<laertus>hmm... ok, so maybe that accounts for the different hashes
<mb[m]2>laertus: unfortunately the builds done by `guix pull` are not currently substitutable, since they do not store which git commit it was built from. There's a TODO in there somewhere..
<laertus>in that case, if i run another "guix pull" from my non-root user's guix environment, it should pull in yet another new guix-latest
<laertus>mb[m]2: ah, very interesting
<laertus>but i'm not using substitutes anyway
<laertus>but i guess they'd still need a way to recognize the commit, and they can't
<laertus>("they" meaning "it" -- guix)
<mb[m]2>Yes indeed. More accurately, the outputs generated by `guix pull` are not "fixed" to the git commit; the hash is only based on current time or thereabouts.
<laertus>ok.. now it's all starting to make sense
<laertus>would the final build artifacts be bit-identical?
<mb[m]2>They should with the latest Guile.
<laertus>i'm wondering if guix could just hash every guix-latest in the store
<laertus>oh, actually, that would be useless without having already built its own to compare
<mb[m]2>You can check that with `guix build --check guix`, which will also compile packages for an earlier snapshot.
<mb[m]2>You may also need to pass `--no-grafts`.
<laertus>that would only work for comparing an existing guix in my store to another existing guix in my store, right?
<mb[m]2>It will build twice if you don't already have it.
<adfeno>Hm... on an related topic, but out of guix pull, I just found a bug while building webkitgtk 2.18.0. I'll report it.
<mb[m]2>Or actually, in that case you'd have to use `--rounds`.
<laertus>so does this mean that every time i "guix pull" it's going to build a new guix-latest?
<laertus>it's definitely not taking 15 minutes on my system
<laertus>more like 2 hours just to build guix-latest
<laertus>i think my old laptop might be too weak for guix --no-substitutes
<laertus>i thought it had what it takes, having constantly compiled gentoo... but now i'm not so sure
<laertus>not only would i need at least 2 hours just to build guix-latest every guix pull, but i would have to guix pull twice (once for root and once for non-root)
<adfeno>guix pull has no substitutes, when pulling, guix-latest is compiled anyways.
<laertus>so i'd be spending a total of 4 hours compiling just guix-latest
<laertus>which is pretty crazy
<mb[m]2>You could manually update the ~/.config/guix/latest symlink to that of a known-good build.
<adfeno>what might have substitutes are the other operations, but not "guix pull".
<laertus>but the thing is i don't want to use substitutes
<laertus>i just don't trust them, mainly
<laertus>also, i'd like to have things optimized for my system... something all the more important because it's old and slow
<mb[m]2>Guix requires a lot more compiling that Gentoo, I would recommend offloading builds to a more powerful server.
<mb[m]2>And CPU optimizations are disabled for the most part.
<laertus>i would take you up on that recommendation if i had a more powerful server :)
<mb[m]2>To enable it you could add `-march=native` somewhere in gnu-build-system.
<laertus>i have a lot more optimizations that i use on gentoo, actually
<laertus>but -march=native would be a start
<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>ACTION nods
<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.
<laertus>that's true, but i had plenty of ram
<Apteryx>OK. Interesting. What CPU is that?
<laertus>AMD E1-1500
<laertus>about 4 or 5 years old, i think.. maybe a bit more
<Apteryx>OK! Mine is from 2011, eh!
<laertus>i got mine in 2013.. but i think it's older
<laertus>anyway... there might be other performance issues with my laptop that are causing this
<laertus>i've long suspected that.. but i haven't been able to track them down
<Apteryx>I'm using an SSD; don't see why it would make that much of a difference for compiling guix
<laertus>i have the guix build directory on a zramfs volume
<laertus>so it's in memory
<laertus>anyway, until/if i find and fix the performance issues on my current laptop or get a new, much more powerful one, i don't think my machine as it is can handle compiling guix
<laertus>my only other option is to switch to substitutes, but i'm not ready to do that
<laertus>ok, well, i think it's time to say until next time to guix...
<laertus>thank you all so much for your help!
<laertus>i'll be back... someday..
<efraim>Mongodb ran OOM again on aarch64, 4 GB RAM 10 GB swap
<reepca>hm, program I want to run has a hardcoded reference to /lib64/ What are my options here?
<rekado>reepca: patchelf
<rekado>reepca: and then you will need LD_PRELOAD or LD_LIBRARY_PATH to satisfy library dependencies
<rekado>patchelf can be used to replace the linker with the one from our glibc package
<reepca>good stuff.
<thomassgn>Here are two problems I've been having for a while, not sure if they're related, but might be:
<civodul>thomassgn: weird, what does that .drv file look like?
<thomassgn>the first one I don't understand much of: I can't guix pull because I'm missing guile-git - but guix won't install it because guile-git is installed :P
<thomassgn>civodul: look like? with cat you mean?
<thomassgn>the nettle drv is empty: ls -l /gnu/store/r4scrqkcci0rvc7sqs5zq77cnlpixqdi-nettle-2.7.1.drv gives '-r--r--r-- 2 root root 0 Jan 1 1970 /gnu/store/r4scrqkcci0rvc7sqs5zq77cnlpixqdi-nettle-2.7.1.drv'
<civodul>so it's corrupt
<thomassgn>cat outputs nothing and returns 0
<civodul>can you run "guix gc -d /gnu/store/r4scrqkcci0rvc7sqs5zq77cnlpixqdi-nettle-2.7.1.drv"
<thomassgn>but it is also live, so I can't gc
<thomassgn>guix gc: error: build failed: cannot delete path `/gnu/store/r4scrqkcci0rvc7sqs5zq77cnlpixqdi-nettle-2.7.1.drv' since it is still alive
<civodul>then you may have to do "sudo guix gc --verify=contents,repair"
<civodul>did your hard disk fail somehow?
<thomassgn>I had this yesterday evening with some others also (first libev) so I ran the command you just put (gc verify=contents,repair) and many of the paths were "modified but unable to repair"
<thomassgn>I haven't noticed it.
<thomassgn>civodul: I have to admit I run a nonfree linux 4.9 kernel for intels wifi. Maybe the new kernel is problematic. I also sometimes abort updates, it was no problem on gentoo :P
<civodul>aborting updates definitely works, that's one of the selling points, no? :-)
<civodul>so really, there's some low-level file system or disk corruption going on
<civodul>can you run "guix gc" alone?
<thomassgn>that's what I've been more and more afraid of.
<civodul>it might remove some of the garbage
<thomassgn>not sure if it changes anything, but I just ran it first as user, then as root. it removed quite a few paths, even though I ran gc -d as both yesterday...
<thomassgn>hmm, now it started working, maybe... I'll report back soon :)
<efraim>Does mongodb build on 32 bit systems?
<efraim>If it doesn't then we can use the system wiredtiger
<thomassgn>well, Same error, but took a while; maybe because gc removed some temporary store paths used for building guile-git...
<thomassgn>I should probably check for SSD errors or something. Learn new things everyday :P
<thomassgn>ah, latest errors:
<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
<civodul>roelj: does answer your question?
<civodul>also, 'files' must be a relative file name
<civodul>so it checks whether PROFILE/etc exists, not whether /etc exists
<civodul>ACTION has to go
<efraim>i do not envy Debian, looks like they're maintaining Qt 5.7 for stable
<amz3>efraim: you are building mongodb?
<efraim>it should still be building, I haven't checked in about an hour
<amz3>efraim: are you using mongodb in production? honest question
<efraim> 'No space left on device'
<amz3>oh :(
<efraim>nope, it was added to guix, so I'm trying to get it to build on aarch64
<amz3>ah ok
<efraim>I'm pretty sure about my changes, but i need more swap apparently
<kristofer>hello guix!
<mekeor>hi kristofer :)
<apteryx[m]>efraim: why goes building materialsngodb require such a gigantic amount of memory?
<apteryx[m]>building mongodb
<efraim>i think it uses a fair amount per core, and my aarch64 board effectively has 6 cores
<kristofer>I'm trying to build a vm image and (operating-system (kernel-arguments ("console=ttyS0,...")) gives me a wrong type to apply error. Perhaps I have the wrong declaration?
<efraim>(kernel-arguments '("console..."))
<efraim>its a list, so '("item1" "item2")
<kristofer>aha needs a quote. thanks efraim
<efraim>sometimes its the simple things :)
<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?
<sneek>Got it.
<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>It's getting fancy... I intend to reuse the knowledge I'm finding here to add the "debug" outputs as was discussed long ago.
<Apteryx>rekado: oops, remove the line "(define (fetch-package-source))" from my pasted version. This is WIP.
<jherrlin>Hey, i reported a bug yesterday and got a response in bug-guix list. I would like to try to apply the patch we got in the response.
<jherrlin>But I dont know how, guess this is a general overview on how to do it?
<rekado>jherrlin: you need to have the Guix sources for that.
<rekado>do you have them?
<rekado>then it’s easy: update your Guix source tree to the latest version.
<jherrlin>thats done
<rekado>to apply the patch you may want to save it to a file
<rekado>dependent on whether it’s a git formatted patch or just a diff, the instructions differ
<rekado>if it’s a git formatted patch you can run “git am /path/to/the/patch” from within the source directory
<rekado>if it’s just a diff then you’d need to do something like “patch -p1 < /path/to/patch” from the source directory
<jherrlin>My guess is thats a git based diff as it contains FROM data
<rekado>then “git am” on the file should work
<jherrlin>nice, will do that
<rekado>once it’s been applied you need to run “make”
<rekado>it’s best to do this in an environment that contains all dependencies, e.g. one created by “guix environment guix”.
<rekado>when it’s done building you can use that modified version of guix with “./pre-inst-env guix”
<rekado>the “pre-inst-env” script is generated at configure time and will ensure that Guix uses the modules from the local source directory
<jherrlin>rekado: the patch is applied
<jherrlin>okey, so i just entered the new environment
<jherrlin>*~/git/guix [env]$ *?
<jherrlin>so i am in the repo root and trying to run make, but i get *make: *** No targets specified and no makefile found. Stop.*
<roptat>jherrlin: ./bootstrap && ./configure --sysconfdir=/etc --localstatedir=/var
<roptat>and then make
<jherrlin>roptat: nice, thanks!
<rekado>you need to run the bootstrap script only to create the configure script.
<rekado>and you need the configure script only rarely after bigger updates
<rekado>in the future “make clean-go && make” would be sufficient
<jherrlin>What do you think about the build time? Intel NUC i5 with 16GB ram
<rekado>that’s more than I have
<kristofer>ha I'm waiting on a guix pull to build for like 90 minutes now
<kristofer>it's a vm though with 2GB ram
<jherrlin>kristofer: wow, thats some time
<jherrlin>make is now done
<jherrlin>is it time to run tests?
<Apteryx>jherrlin: only if you are very patient ;)
<jherrlin>okey, not today ;)
<jherrlin>whats my next step here. I am inside the virtual environment, can i test the build from here?
<roptat>jherrlin: yes, since you're working on my vpn patch, you can build your system configuration and test it with guix system vm <path-to-your-config.scm>
<jherrlin>okey, nice! thanks for the patch roptat !
<roptat>actually guix system build <config.scm> would be enough to check that the patch works
<jherrlin>roptat: okey, thanks!
<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.
<efraim>add --check
<efraim>and you shouldn't need '--no-grafts' for the source
<Apteryx>this will rebuild the whole thing though. I'd like just verify that the source hash is OK
<Apteryx>maybe I could use 'guix-download' and the URI of the package
<efraim>'--source --no-substitutes --check' will force redownloading of the source, and patching it if necessary
<Apteryx>OK, will try this. Thanks :)
<efraim>its also what I use after updating perl and python packages, to make sure the uri line doesn't need to be adjusted
<Apteryx>It seems guix build ... | less doesn't cooperate well.
<Apteryx>not just less, it seems the output of guix build cannot be piped to any other tool.
<jherrlin>okey, so my *guix system vm config.scm* failed
<jherrlin>but *guix system build conig.scm* succeeded
<jherrlin>could i somehow test this on my live system?
<Apteryx>nevermind, it works after redirecting stderr into stdout with 2>&1
<kristofer>jherrlin: you posted that guix system vm didn't succeed. I typically will guix system vm-image config.scm --image-size=10G and boot that up in a qemu
<jherrlin>kristofer: thanks! will read that when i am back home.
<jherrlin>but one question around this
<jherrlin>when I have bootstraped, I enter a new environment. Where am i then? Some container/vm?
<kristofer>jherrlin: looking at your paste I'd guess you're in a guile repl
<jherrlin>or is it something similiar (in my head) to pythons virtualenv?
<jherrlin>hmm, i guess i could just look in the bootstrap script
<jherrlin>kristofer: yeah, i ended up there :)
<Apteryx>efraim: it doesn't seem to fail for libgit (guix build --source --no-substitutes --check libgit2) although I don't see a commit that would have fixed the hash.
<Apteryx>It's not redownloading the source actually, that's why.
<Apteryx>It just unpacking the archive I already have in the store.
<kristofer>Apteryx: -- it looks like you might try the --repair switch
<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>OK, so I'm doing things correctly, then
<Apteryx>kristofer: interesting! I'll try it, thanks.
<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
<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
<bavier>(and authorize the signing key)
<IpswichTriptych>I'm planning to have this computer connected to the internet 24/7, but bavier , would that require a static IP?
<bavier>IpswichTriptych: either than of dynamic dns
<IpswichTriptych>bavier: OK
<Apteryx>aren't fixed content store items addressed by their content hash? If not, why?
<Apteryx>for example, "guix download" prints the registered store item as "/gnu/store/5d0wz8mk2kfw1qc90w5swswa9p35kgib-v0.26.0.tar.gz", but the archive hash as "1b3figbhp5l83vd37vq6j2narrq4yl9pfw6mw0px0dzb1hz3jqka".
<bavier>Apteryx: I believe the store hash is based on the derivation, not the archive itself
<bavier>Apteryx: which accounts for the possibility of patches or snippets
<Apteryx>bavier: I see. Thanks for explaining.
<lfam>Any GNOME / Nautilus users willing to evaluate the latest iteration of CVE-2017-14606 (.desktop file attacks):
<lfam>Apparently new attack vectors have been discovered (see the bugzilla page)
<mekeor>hello guix. after upgrading all my packages lately, some fonts in icecat look aweful. i think they aren't antialiased. is this a known issue with Guix? what am i doing wrong? how to fix?
<mekeor>here's a screenshot:
<mekeor>but it's not only that website of course.
<mekeor>mekeor: this is probably due to bug
<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.
<Apteryx>(I installed devavu sans fonts)
<rekado>mekeor: have you run “fc-cache -f” to update the cache?
<bavier>efraim: do you have a local branch for aarch64 support work?
<efraim>bavier: I do most of it against master
<efraim>i have a mongodb patch I haven't pushed yet, and I do have a patch for my WIP for java
<bavier>efraim: does 'make check' run clean for you?
<efraim>not often
<bavier>just thought I'd ask, thanks
<efraim>i actually don't remember the last time I ran it, but it fails horribly on an sd card
<bavier>ok, I think I just have a few things related to (guix build syscalls) failing
<lfam>bavier: Are you working on bare metal? I'm curious what machine you're using for aarch64
<bavier>lfam: yes, a thunderx2 machine
<lfam>Nice :)
<IpswichTriptych>hey, guix! i'm really excited to announce i have my ssh server running on GuixSD!
<lfam>Hooray IpswichTriptych
<Apteryx>IpswichTriptych: way to go!
<IpswichTriptych>thanks for your support!
<rekado>I have a question to my fellow StumpWM users:
<rekado>after you’ve disconnected from an external monitor or projector — how do you make StumpWM refresh its idea of the available screen size?
<rekado>the easiest way for me is usually to connect to the external monitor or projector again, and then to run lxrandr to change the monitor settings.
<ecraven>rekado: restart-hard ;) though that's a bit drastic
<rekado>without being connected to an external monitor I cannot reset the settings.
<ecraven>as in <prefix>-: restart-hard RET
<lfam>I'm curious, do we have a policy about adding new package modules with many packages? Can the module be added in a single commit, or should I add one package at a time?
<rekado>lfam: I usually add the module with a single package first.
<rekado>then add one package per commit
<lfam>Okay, I know what I'm doing for the next couple hours ;)
<lfam>I would have done it that way from the start but I inherited this code, and it came as one commit
<lfam>I'm going to push the go-build-system / Syncthing stuff today. Further improvments will come later
<civodul>lfam: sounds good!
<civodul>apologies for not commenting on that earlier
<lfam>No worries, looks like the mailing list has been super busy
<lfam>Do you want me to wait for your comments before pushing?
<civodul>no, you've already waited long enough i guess ;-)
<lfam>I'd say that we've *all* waited long enough ;)
<civodul>right :-)
<civodul>esp. Syncthing was quite often requested
<civodul>you'll make a lot of people happy!
<lfam>Yeah, and then once people are actually using and looking at the code, there will be more help towards improvements :)
<civodul>definitely :-)
<mb[m]2>Anyone know what's up with the Hydra queue? :)
<civodul>mb[m]2: ahem, oops!
<civodul>mb[m]2: i had stopped the "queue runner" to let the evaluation complete
<civodul>then i did not restart it
<civodul>however there's currently another evaluation running
<civodul>should i let it complete, or should i restart the queue runner?
<mb[m]2>Good question. Will the evaluation fail for sure if the runner is started?
<mb[m]2>If we pause another day, we may have to do another merge-and-eval due to the high churn on 'master'.
<civodul>well, we should merge sometime
<mb[m]2>I started the latest evaluation solely to get the mesa fix for armhf, and had hoped to merge once i686 and x86_64 had enough substitutes.
<civodul>i've restarted the queue runner
<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]>for GuixSD, sorry.
<mb[m]2>Yes, the x86 packages should be ready tomorrow if the queue runs at a normal pace.
<civodul>TaoHansen[m]: i think 'setfont' is supposed to work
<civodul>are you sure the font name you used is correct?
<TaoHansen[m]>civodul: i need to know where the fonts are stored first
<civodul>TaoHansen[m]: i don't think so; "setfont -C /dev/tty1 LatGrkCyr-8x16" should work
<TaoHansen[m]>civodul: ah, i was hoping to be able to look through the directory so i can see which one will be big enough for this 4k screen.
<TaoHansen[m]>i'll try yours, maybe it's large enough?
<civodul>you can try :-)
<civodul>otherwise the fonts are somewhere in /gnu/store/*kbd-*
<TaoHansen[m]>civodul: thanks. :-)
<civodul>it would be interesting to plot the patch review delay as a function of the submission's time
<lfam>Do you have a hypothesis, civodul?
<lfam>Like, if reviewers are around when the patch is sent, it's likely to be handled immediately?
<lfam>I think it probably has some effect
<lfam>Old patches are harder to review anyways
<lfam>They may not apply, and the submitter may also have reduced enthusiasm for discussion
<civodul>they're not inherently "harder", but people feel less incentive to review or comment
<civodul>they're at the bottom of the list
<civodul>where no one scrolls :-)
<lfam>I certainly feel that way
<civodul>ACTION -> zZz
<civodul>good night/day!
<lfam>Good night!
<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.