IRC channel logs
2015-03-22.log
back to list of logs
<civodul>./pre-inst-env guile --no-auto-compile --fresh-auto-compile -l build-aux/hydra/gnu-system.scm -c "(hydra-jobs (open-connection) '())" runs in 15s on my laptop <civodul>working on it, but that machine is still as slow as it's always been... <atheia>I've finally made the plunge: running guixsd on my primary laptop. <atheia>Though I am encountering one or two strange issues: <atheia>1) After rebooting and using the system for a while, I noticed that root's PATH has not been augmented by current-system and its .guix-profile. <atheia>This was fixed after adding exporting the PATH as appropriate. <atheia>2) Whenever I try to execute commands for Guix as root I get a substitute error: <atheia>guix/scripts/substitute-binary.scm:634:2: Throw to key `match-error' with args `("match" "no matching pattern" ())'. <atheia>Looking at the code, it seems to suggest an issue whereby the substitutes url is not defined within daemon-options. <atheia>I was wondering whether these were issues that others have experienced or whether they are somehow due to my specific use-case? <Sleep_Walker>I created guix wrapper script to use Guix from GIT repository instead <Sleep_Walker>I had some problems with PATH - does sourcing /etc/profile fixes things for you? <atheia>Aha, yes indeed, that fixes the root path issue (issue 1). <atheia>It unfortunately does not fix issue number 2. <atheia>So I guess the issue is caused by /etc/profile not being installed in root's home directory at install time or some such… ? <atheia>(this is issue 1, the /etc/profile issue). <Sleep_Walker>I can't say how to fix it properly but you can live with ~/.bash_profile sourcing /etc/profile <atheia>indeed, that's my conclusion too. Cheers. <civodul>atheia: yay, congrats for running GuixSD! <civodul>atheia: the 'match-error' may be fixed by upgrading to commit f22266 <civodul>re issue #1, normally user accounts get a ~/.bash_profile that sources /etc/profile <atheia>civodul, I'll try the match-error fix. The automatic .bash_profile creation, should that also work for root? <Sleep_Walker>that is not some resource hungry package - I'm afraid there is bug causing that <civodul>atheia: re .bash_profile, yes, but this was not the case yet in 0.8.1 (see commit 45c5b47b) <Sleep_Walker>and when the problem is triggered, HDD starts to spin and everything is not responsive to anything less than sysrq <Sleep_Walker>hm, maybe I have somewhere logs from sysrq t from previous attacks <Sleep_Walker>OK, by looking at the traces my guess is it is unrelated to guix <Sleep_Walker>my guess is it is caused by Intel Graphic card kernel driver <Sleep_Walker>ok, no, graphic cards are just first to suffer from memory stress :( <civodul>could you check in 'top' or something which process is eating memory? <davexunit>the blue striped shirt dude in the back next to John <mark_weaver>davexunit: is there a larger version of that image available? <Sleep_Walker>[62488.647174] Out of memory: Kill process 14667 (guix) score 314 or sacrifice child <Sleep_Walker>[62488.647176] Killed process 14667 (guix) total-vm:2655036kB, anon-rss:1208920kB, file-rss:0kB <Sleep_Walker>maybe there should be memory limit set for guix-daemon its children <davexunit>but need to find it. our crappy blog software never gives the option for a larger image. <mark_weaver>davexunit: it's not important, just curious if you had it handy <davexunit>the web UI works best in chromium, firefox has some bugs that make the streaming experience less than ideal <civodul>davexunit: is Mako Hill's talk over? <davexunit>paron_remote and friends are in front of the camera <Sleep_Walker>you could paint huge GuixSD logo there, no one can stop you now *civodul watches room141.ogv, but visibly too late to see davexunit <Sleep_Walker>civodul: ad your comment - the package is really called 'the silver searcher', not 'the silver search' - I'll use original name even though you recommended the other (my assumption is typo or mistake on your side) <civodul>Sleep_Walker: oh sure, it was a mistake from me <mark_weaver>it says "This build log is too big to display (71436894 bytes)." <mark_weaver>for times like this, I wish I had a way to say "upgrade all packages except calibre" <mark_weaver>while trying to compile obj/src/core/QtWebEngineCore.gl_surface_qt.o, I get this: <mark_weaver>/gnu/store/qw2cxiz75yja6r7isrqrqrm7hsm258qs-mesa-10.4.0/include/GL/glext.h:468:19: error: conflicting declaration ‘typedef ptrdiff_t GLsizeiptr’ <mark_weaver>/tmp/nix-build-qt-5.4.1.drv-0/qt-everywhere-opensource-src-5.4.1/qtwebengine/src/3rdparty/chromium/gpu/command_buffer/common/gles2_cmd_format.h:48:26: error: ‘GLsizeiptr’ has a previous declaration as ‘typedef khronos_ssize_t GLsizeiptr’ <civodul>mark_weaver: may be related to the recent Mesa changes? <mark_weaver>that does seem to be the most likely cause, but I'm not sure how it would cause this <mark_weaver>the last successful build was in 5a74d2, and the first failure in c90a50 <mark_weaver>so I guess it should have built properly in 87bafa0 as well, which was the previous evaluation <civodul>perhaps that can be bisected if that doesn't imply new rebuilds <mark_weaver>it takes my machine a long time to build qt-5, and of course the failure happens very close to the end of the build <mark_weaver>though for the moment I just need to rid my machine of the security-flawed openssl, which is taking far too long for my taste :-( <civodul>mark_weaver: right, but if the old qt-5 is already in store or substitutable, that's OK <civodul>of course you wouldn't want to rebuild it 5 times locally :-) <Sleep_Walker>but it is really interesting to see more idealistic/philosophical/concptual talks and less technical talks for change <mark_weaver>sorry I didn't have time to get my system set up for backup video recording <mark_weaver>bah, how to update everything except one package? important missing feature <mark_weaver>I want to update my system to get the openssl security fix, but I don't want to lose calibre which depends on qt which won't build currently <mark_weaver>well, in general it's good to update everything together. I don't want to limit it to only things that use openssl <mark_weaver>having a mixture of old and new libraries in particular may cause problems <mark_weaver>suppose I have libA and libB which both depend on libC <mark_weaver>now suppose I update libA which was built against libC-2.0, but keep the older libB which was built against libC-1.0 <mark_weaver>then if I try to link a program with both libA and libB, it will try to link in two versions of libC, which can't work. <mark_weaver>of course this only happens when I build software manually using libraries in my profile <Sleep_Walker>hm, linker will fail because it can't decide which symbol it should use? <Sleep_Walker>(we should add part of the hash into symbol name as versioning :) *mark_weaver looks into implemented a --do-no-upgrade option <mark_weaver>actually, I've also noticed that if you ask to --remove packages and --upgrade others, the upgrade will render the --remove useless, so there are already problems there <mark_weaver>okay --do-not-upgrade is pretty easy to implement at least <civodul>mark_weaver: i was thinking of --exclude=REGEXP (or --do-not-upgrade=REGEXP) <civodul>the obvious example being, ahem, --exclude=texlive <mark_weaver>civodul: I have a preliminary --do-not-upgrade= option implemented, enough for now to do the job I needed :) <civodul>i've been willing to have this for the last full-profile upgrades that i did <mark_weaver>making it automatically exclude packages that the user asked to remove is slightly less obvious, because of the way 'options->remove' and 'options->installable' are separated. <mark_weaver>well, how to match the manifest patterns from 'options->remove' against the existing manifest entries. that's mainly what I don't know. <mark_weaver>hmm, now to debug the 'guix system reconfigure' bug I'm hitting <mark_weaver>civodul: the debugging code that you suggested adding to substitute-binary is in the store <mark_weaver>I guess I should ask dmd to stop guix-daemon and run it from the git checkout <civodul>mark_weaver: yes i do that when i need to debug/test stuff <mark_weaver>good, guix-daemon from git shows the same failure mode. now to instrument <mark_weaver>civodul: I added the 'pk' that you suggested, and the output showed: ;;; (surls "") <mark_weaver>it printed that within a second of launching the "guix system reconfigure" command, and then failed many seconds later <Sleep_Walker>btw. I know that is probably against all your security and philosophy, but with the status if hydra I'd love to see distributing stores with some other segmentated protocol like bit torrent or something <mark_weaver>Sleep_Walker: see the thread "Guix + GNUnet at GSoC?" on guix-devel <mark_weaver>civodul: the same failure happens when I run "pre-inst-env guix package -i" as root. so the problem seems to be that running these commands as 'root' fails, but running them as my normal user works. <mark_weaver>civodul: I added another 'pk' around (find-daemon-option "substitute-urls") in substitute-binary.scm, but I never see the output from that. I guess that the output is being redirected somewhere I can't see. <mark_weaver>but my current hypothesis is that (find-daemon-option "substitute-urls") is returning () when I run it as root <mark_weaver>well, I think that must be the case, based on the error message <mark_weaver>civodul: I think this is probably related to f222664 or 41c45e7 <mark_weaver>hmm, that's probably fallout from the ENOSPC on hydra <mark_weaver>I'm not sure how to selectively remove items from nginx's cache <civodul>mark_weaver: yes it seems related, but OTOH, you're using the "old" substitute-binary anyway (on GuixSD) <mark_weaver>well, I finally got my system updated, by using 'guix build' from my normal user account to download the substitutes needed for 'guix system reconfigure'. <abnegate>eventually it seems to start working, but then i get errors like "ERROR: Bad uri header component: /gnu/ftp/gnu/guile/guile-2.0.11.tar.xz <civodul>abnegate: the "ACL for archive imports seems to be uninitialized" message means that you haven't authorized the public key for hydra.gnu.org <mark_weaver>civodul: reverting f2226640587, f401b1e99, and 41c45e7863 on the client side fixes the problem. <mark_weaver>basically, any command at all that would download substitutes fails when I run it as root. <mark_weaver>and specifically, the problem is that (find-daemon-option "substitute-urls") returns (), which the match in substitute-binary.scm cannot cope with <mark_weaver>in both cases, running with pre-inst-env from my git checkout <civodul>for non-root clients, the client-provided "substitute-urls" value is considered untrusted <civodul>and so it is passed as "untrusted-substitute-urls" to 'guix substitute-binary' <civodul>and since it's default value is empty, bam <abnegate>when i do a "guix pull" without authorizing the public key for hydra.gnu.org, how much disk space can i expect /gnu/store to use up in building and saving all this stuff? <abnegate>it would be nice if it could give you an estimate of how much disk space it was going to use before starting <abnegate>without that i just have to hope i don't run out of disk space before it's done <civodul>abnegate: when building things locally, it's hard to estimate the disk space that will be used <civodul>it's of course much easier when downloading pre-built binaries <civodul>as is the case once you've registered the key <civodul>but yeah, i can understand the frustration 