IRC channel logs


back to list of logs

<civodul>mark_weaver: ?!
<civodul>this is terrible
<Sleep_Walker>why it is so slow?
<civodul>no idea, it shouldn't be this slow
<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>i must be missing something
<civodul>for now, zzz
<mark_weaver>good night!
<phant0mas>good morning Guix
<Sleep_Walker>yay, new fixed curl builds and works!
<kmicu>Is everything ok with that site?
<kmicu>It looks like that for
<civodul>Hi Guix!
<civodul>we have a hydra outage (ENOSPC)
<civodul>working on it, but that machine is still as slow as it's always been...
<atheia>Hey civodul, ta for info
<atheia>I've finally made the plunge: running guixsd on my primary laptop.
<atheia>Pretty exciting :-)
<Sleep_Walker>welcome to the club!
<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>and I haven't updated system for some time already
<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>guile was killed by OOM killer
<Sleep_Walker>guix was building curl
<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)
<atheia>Ah, super. Thanks :-)
<civodul>Sleep_Walker: is it reproducible?
<Sleep_Walker>civodul: I haven't figured trigger conditions
<Sleep_Walker>I can't say now
<Sleep_Walker>but it happened to me ~3 times
<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>I'll definitely keep it in mind for future occurences
<Sleep_Walker>OK, by looking at the traces my guess is it is unrelated to guix
<civodul>would be nice :-)
<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 :(
<Sleep_Walker>and yes - it seems that now I can reproduce it :(
<Sleep_Walker>how can I enable tracing?
<civodul>Sleep_Walker: how is it reproduced?
<Sleep_Walker>guix package -i vlc
<Sleep_Walker>in my case
<Sleep_Walker>don't tell me it is reproducible for you as well
<civodul>could you check in 'top' or something which process is eating memory?
<civodul>it works fine here
<civodul>i think i've see davexunit at :-)
<davexunit>civodul: yup, I'm there
<davexunit>the blue striped shirt dude in the back next to John
<civodul>right, that's what i thought :-)
<mark_weaver>davexunit: is there a larger version of that image available?
<Sleep_Walker>something like:
<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>sorry, when it occurs, it simply make system unusable
<Sleep_Walker>maybe there should be memory limit set for guix-daemon its children
<davexunit>mark_weaver: surely.
<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>not at the moment.
<davexunit>our streams are working well today at LP.
<davexunit>for those interested:
<davexunit>the web UI works best in chromium, firefox has some bugs that make the streaming experience less than ideal
<davexunit>see for all the raw streams
<Sleep_Walker>best experience I have on Firefox on Cyanogenmod :)
<civodul>davexunit: is Mako Hill's talk over?
<davexunit>civodul: yes
<civodul>uh, indeed
<civodul>"open source" in room 123 ;-)
<davexunit>I'm live in room 141
<davexunit>might as well broadcast this over the break
<davexunit>ah it broke
<davexunit>it's the guix home page
<Sleep_Walker>moment of glory is gone :b
<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
<Sleep_Walker>davexunit: kudos for explanation skills ;)
<Sleep_Walker>maybe show output of ldd
*Sleep_Walker waves ;b
*civodul watches room141.ogv, but visibly too late to see davexunit
<davexunit>heh yeah
<davexunit>that was awhile ago
<davexunit>I just hopped on, threw up on the desktop feed, and talked to someone about guix on air :)
<civodul>heheh, fun :-)
<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)
<Sleep_Walker>in description
<civodul>Sleep_Walker: oh sure, it was a mistake from me
<mark_weaver>hmm, qt-5.4.1 failed to build on my i686 GuixSD box
<mark_weaver>from current master
<mark_weaver>I see that hydra also failed to build it <> but I can't view the log from the web interface because it is too large (!)
<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>there were actually a few new failures in that evaluation:
<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>14 commits
<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>["rock your emacs" on TV:]
<Sleep_Walker>enable ccache for that
<Sleep_Walker>it speeds up bisecting _a lot_
<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 :-)
<civodul>hmm the stream has disappeared
<Sleep_Walker>other rooms than 123 are usually unstable :(
<Sleep_Walker>but it is really interesting to see more idealistic/philosophical/concptual talks and less technical talks for change
<davexunit>civodul: sorry that the stream is broken
<davexunit>it's totally borked now
<davexunit>the speaker had a special setup
<davexunit>and it ended up breaking everything for us
<civodul>heh ok
<civodul>maybe we can watch the video later
<davexunit>it's totally broken
<civodul>bah, ok :-/
<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
<Sleep_Walker>what is the use case?
<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
<Sleep_Walker>it sounds like more complicated request :)
<Sleep_Walker>--update-with-deps openssl --skip calibre,qt
<Sleep_Walker>that would be nice
<Sleep_Walker>it reminds me CUDF capabilities
<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
<mark_weaver>but for a developer that's a common case
<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>I don't know exactly, but it can't be good
<mark_weaver>but in general, I want to upgrade as much as I can
*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: heh :)
<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>I guess I'll leave that for another day
<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: we plan to use gnunet
<mark_weaver>Sleep_Walker: see the thread "Guix + GNUnet at GSoC?" on guix-devel
<Sleep_Walker>I know about gnunet
<Sleep_Walker>but I have never made it do anything
<Sleep_Walker>so I don't know it's features
<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>almost certainly...
<Sleep_Walker>I guess that is corrupted
<Sleep_Walker>I always get the same error
<Sleep_Walker>can someone wipe this one?
<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
<mark_weaver>Sleep_Walker: okay, I think I cleared it
<civodul>mark_weaver: yes it seems related, but OTOH, you're using the "old" substitute-binary anyway (on GuixSD)
<civodul>so this must be a client-side issue
<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>when i do a "guix pull" i get these errors:
<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
<abnegate>and "ERROR: download failed "" 404 "Not Found""
<civodul>abnegate: the "ACL for archive imports seems to be uninitialized" message means that you haven't authorized the public key for
<mark_weaver>civodul: reverting f2226640587, f401b1e99, and 41c45e7863 on the client side fixes the problem.
*civodul looks
<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
<civodul>ooh, i think i understand
<civodul>and that's only as root, right?
<mark_weaver>well, I've only tried as root and mhw
<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>whereas for root, its name is kept
<civodul>and since it's default value is empty, bam
<civodul>ok i'll fix it
<abnegate>when i do a "guix pull" without authorizing the public key for, 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>so i could decide if it was worth it
<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