IRC channel logs
2017-10-09.log
back to list of logs
<adfeno>#guix: Has someone found some issues while building webkitgtk-2.18.0? <laertus>wow.. i finally managed to complete a "guix pull" <laertus>couldn't have done it without the help of lots of people here and on the mailing list <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>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 <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 <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 <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>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>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>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 <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>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 <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? <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>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>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? <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>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 <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 <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>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>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. <laertus>that's true, but i had plenty of ram <laertus>about 4 or 5 years old, i think.. maybe a bit more <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>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! <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/ld-linux-x86-64.so.2. What are my options here? <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 <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>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>can you run "guix gc -d /gnu/store/r4scrqkcci0rvc7sqs5zq77cnlpixqdi-nettle-2.7.1.drv" <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" <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>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 <thomassgn>that's what I've been more and more afraid of. <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 <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>also, 'files' must be a relative file name <civodul>so it checks whether PROFILE/etc exists, not whether /etc exists <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>nope, it was added to guix, so I'm trying to get it to build on aarch64 <efraim>I'm pretty sure about my changes, but i need more swap apparently <apteryx[m]>efraim: why goes building materialsngodb require such a gigantic amount of memory? <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") <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? <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>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>then it’s easy: update your Guix source tree to the latest version. <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 <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>okey, so i just entered the new environment <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 <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 <kristofer>ha I'm waiting on a guix pull to build for like 90 minutes now <Apteryx>jherrlin: only if you are very patient ;) <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 <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>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 <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>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 <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>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 <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 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 <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 <Apteryx>aren't fixed content store items addressed by their content hash? If not, why? <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>but it's not only that website of course. <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. <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>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 <IpswichTriptych>hey, guix! i'm really excited to announce i have my ssh server running on GuixSD! <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. <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. <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>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>esp. Syncthing was quite often requested <lfam>Yeah, and then once people are actually using and looking at the code, there will be more help towards improvements :) <mb[m]2>Anyone know what's up with the Hydra queue? :) <civodul>mb[m]2: i had stopped the "queue runner" to let the evaluation complete <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'. <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>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? <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. <civodul>otherwise the fonts are somewhere in /gnu/store/*kbd-* <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 <lfam>I certainly feel that way <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. 