IRC channel logs

2013-12-14.log

back to list of logs

<zacts>hi guix hackers
<jmd>How can I force a rebuild of a package?
<sdfsdfsf>jmd: you could try to gc it. not sure if it's the right way.
<jmd>ok I'll try that.
<sdfsdfsf>be careful with gc, though.
<jmd>What is the easiest way to create a file in the pre-build stage?
<roelj>I think guix is crashing my X server. Every time I do guix package -i <some package>, I get logged out of GNOME and land on the login screen.
<roelj>I'm not running the X server provided by Guix, just using the Debian version.
<roelj>Ah, this seems to happen when I start the guix-daemon with "guix-daemon --build-users-group=guix-builder". Starting it as "guix-daemon" works, but shows a warning about running i as root.
<mark_weaver>roelj: that's very strange. can you look for hints in your X server logs?
<mark_weaver>After getting logged out, your ~/.xsession-errors might also have some clues.
<roelj>mark_weaver: I'm trying to find it :)
<roelj>Nothing relevant, only a lot of gnome-shell "Clutter-CRITICAL" errors.
<mark_weaver>iirc, ~/.xsession-errors gets cleared every time to log into to X, so you'd need to check it from a text terminal after getting logged out.
<mark_weaver>and did you check the X server logs /var/log/Xorg.0.log{,.old} ?
<mark_weaver>are you on a memory-constrained system? might it be an out-of-memory error?
*mark_weaver grasps at straws
<roelj>I checked /var/log/Xorg.0.log (not the older ones). I'll move the Xorg logs somewhere else, and trigger the crash, so I have a log with only the crash-related information.
<roelj>Not really a memory-constrained system (8G available, ~500M used)
<mark_weaver>that's more than enough. maybe there's something in daemon.log, kern.log, or syslog
<mark_weaver>you might also try logging into X with a much simpler X session, to see if that makes a difference. is it something in GNOME that's crashing, or X itself?
<mark_weaver>(I built everything in Guix on a system with 1G of RAM)
<mark_weaver>is /tmp a separate filesystem? how big is it?
<mark_weaver>is there space in the root filesystem for lots of stuff in /nix ?
<roelj>I actually suspect it's a GNOME thing.. But I don't have anything else installed atm.
<roelj>My filesystem setup is : / = 20G /home = 59G, swap = 1G
<mark_weaver>that should be fine.
<roelj>Ok, the packages I wanted to install seem to be installed now, I'll probably get disconnected when X crashes, but I'll be right back.
<mark_weaver>well, this is very strange. I've never heard any reports anything like this.
<mark_weaver>oky
<roelj>That's funny.. It seems to go fine now..
<mark_weaver>strange.
<roelj>Nothing in the logs either
<roelj>I knew Guix is magical software :)
<mark_weaver>that's not the kind of magic we want to be associated with :)
<mark_weaver>well, please let us know if it happens again.
<roelj>I do have something else now, I installed powertop, brasero and gnome-icon-theme using "guix package -i powertop" and in another terminal "guix package -i brasero" at the same time.
<roelj>The installation went fine, only I don't see them in ~/.guix-profile/bin/
<roelj>"guix package --list-installed" displays them.
<roelj>Ah. powertop is in ~/.guix-profile/sbin
<roelj>And brasero is not in the list, hmm.
<roelj>Nevermind
<roelj>I just crashed again. However, nothing in ~/.xession-errors:0. And only standard X configuration debugging info in /var/log/Xorg.1.log
<mark_weaver>bummer
<jmd>mark_weaver: +1
<mark_weaver>hi civodul!
<civodul>hey hey, hello Guix!
<mark_weaver>guix seems to be crashing roelj's GNOME session somehow. any ideas?
<jmd>Hello cloudiv
<mark_weaver>roelj: I don't think you can safely run parallel "guix package -i ..." commands simultaneously by the same user, at least not if they are operating on the same profile.
<mark_weaver>well, it's safe in the sense that nothing terrible will happen, but it won't do what you expect.
<mark_weaver>or at least that's my guess.
<civodul>mark_weaver: could it be an OOM?
<mark_weaver>transactions on your profile are atomic in the sense that any changes (installs+removes+upgrades) are done by making a fresh new profile (symlink tree) with the new set of installed packages, and then the ~/.guix-profile symlink is changed to point to the new profile.
<mark_weaver>civodul: no, we pretty much ruled that out. he has 8G of memory and ~500M used.
<civodul>ok
<civodul>does dmesg show something?
<mark_weaver>roelj?
<mark_weaver>but if you run multiple "guix package" commands on the same profile simultaneously, then it's likely that they will both build new profiles based on the same starting set of packages, and thus one of the installs will effectively be lost.
<roelj>mark_weaver: Sorry, I was away for a moment.
<mark_weaver>civodul: should we have some kind of per-profile locking to prevent this kind of lossage?
<roelj>Ok, I won't do parallel installs anymore.
<mark_weaver>I confess, it seems to call into question our claims of transactional semantics.
<mark_weaver>(or at least could be interpreted that way by reasonable people)
<roelj>dmesg has a guix-related error: [10251.566560] guix[22845]: segfault at 30c ip 00007fe395228264 sp 00007fe391735830 error 6 in libguile-2.0.so.22.7.0[7fe39514f000+157000]
<roelj>Well, if I understand correctly, one of the packages (probably the first one that was installed) will get lost because the newer transaction doesn't know it was installed..
<mark_weaver>what version of guile is it? what platform?
<roelj>"guile --version" displays: guile (GNU Guile) 2.0.9-deb+1-1
<roelj>I'm on a amd64 (x86_84) platform
<roelj>width Debian Wheezy/Sid
<mark_weaver>what version of libgc?
<roelj>Is that the same as libgcc?
<mark_weaver>no. let me find out the debian package name to be sure.
<mark_weaver>libgc-dev and libgc1c2
<mark_weaver>(it's the Boehm GC garbage collector)
<roelj>libgc-dev: 7.2d-5, libgc1c2: 7.2d-5
<mark_weaver>okay, that's good.
<roelj>Is there some way I can get a backtrace?
<roelj>That might make it easier to figure out what's wrong
<roelj>I could also try to get a clean copy of Guix and see whether that has solved the issue.
<mark_weaver>backtraces are normally printed, but if your X terminal goes away you won't see it of course.
<mark_weaver>maybe you should run guix within screen.
<mark_weaver>so if you X session crashes, it will merely detach the screen session and you can reattach. (are you familiar with GNU screen?)
<mark_weaver>maybe run the guix daemon within screen also.
<jmd>Or from within emacs...
<mark_weaver>that won't help
<mark_weaver>if you run emacs within X, and the X session dies, emacs will die, no?
<jmd>Well, yes. I meant emacs not within X.
<mark_weaver>well, if you're going to run it outside of X, then what help is emacs here?
<mark_weaver>(I run most everything within emacs myself, but my X session is stable)
<jmd>I hadn't followed the conversation from the start - just a suggestion - sorry for the noise.
<mark_weaver>np :)
<roelj>I'll run guix in a non-graphical TTY
<mark_weaver>okay
<mark_weaver>maybe arrange for a way to make a copy of the output, and to save output that scrolls off, somehow.
<mark_weaver>(Emacs and Screen can do that, as can 'script')
<mark_weaver>roelj: here's a crazy theory: are you sure that the UIDs you assigned to the 'guix-builder' users are unique, and don't collide with any existing user ids?
<mark_weaver>(there might be some cleanup when a build is started and/or finished that kills all the processes by that build user)
<mark_weaver>roelj: also, you didn't add yourself to the 'guix-builder' group, did you?
<mark_weaver>because I guess that 'guix-daemon' picks any user from the build-users-group that's not currently doing a build, and then probably at some point kills all the processes owned by that user.
<civodul>mark_weaver: yes we could have profile locking
<civodul>that didn't seem very useful, but why not
<mark_weaver>well, roelj tried running '
<civodul>roelj: is there some OOM message reported by 'dmesg', or in /var/log/messages or similar?
<civodul>i can't think of any other way it could interfere
<mark_weaver>"guix package -i" in two terminals simultaneously.
<mark_weaver>civodul: if someone decided to add themselves to the 'guix-builder' group, what would happen?
<mark_weaver>I can easily imagine someone doing that, just for the heck of it.
<civodul>well, that use could be chosen by the daemon
<civodul>but no, we won't attempt to protect against that
<civodul>:-)
<mark_weaver>does the daemon kill all processes owned by the build user at any point?
<civodul>i think so, yes
<mark_weaver>okay, so that could explain what roelj is seeing.
<mark_weaver>if he did that.
<civodul>oh
<civodul>roelj: what does "getent group guix-builder" report?
<mark_weaver>I haven't gotten an answer from him yet; I think he's playing with guix in a text terminal now, where he probably can't see any of this.
<civodul>heh :-)
<roelj>civodul: guix-builder:x:1003:roel
<mark_weaver>ah, that's it!
<mark_weaver>roelj: remove yourself from the 'guix-builder' group.
<mark_weaver>roelj: here's what happened: the guix-daemon chose 'roel' as the build user for one of its build processes, and then at some point (probably after the build) killed off all processes owned by 'roel' to clean up.
<mark_weaver>well, that's my theory anyway.
<mark_weaver>we should probably put a warning about this in the manual.
<roelj>Ah, that would indeed explain what happens.
<civodul>yes, mark_weaver is right
<civodul>roelj: 'guix-builder' should be populated as noted in http://www.gnu.org/software/guix/manual/guix.html#Setting-Up-the-Daemon
<civodul>so first, remove yourself from the group
<civodul>and then, you can run the commands noted above
<civodul>mark_weaver: congrats for good guess! :-)
<mark_weaver>glad to help :)
<roelj>I removed myself from the group. I am installing icecat, and I started it when I was still in the guix-builder group. Will it still kill all processes owned by me?
<mark_weaver>roelj: no, it should be fine.
<roelj>great.
<mark_weaver>when you log in, it initializes the set of groups you're in from the database, so you still have rights to the group, but the guix-daemon shouldn't see that at this point, so it won't pick you again.
<roelj>Thanks a lot! I find it really cool how you (civodul and mark_weaver) have figured out what the problem could be.
<roelj>Is there some way to fix my parallel installs, or should I just remove the generations that were created and "forgotten"?
<roelj>and install them again one by one (not that much work :))
<mark_weaver>you don't have to install them one by one. it's faster to do multiple installs in a single command "guix package" command.
<civodul>each "guix package" invocation is a transaction
<civodul>so if you install 5 packages with a single "guix package" invocation, --roll-back would roll back all 5 installations
<mark_weaver>we can't do parallel installs to the same profile. probably the best we could hope for is a locking mechanism that makes you wait until one command finishes before starting the next one.
<civodul>yeah
<roelj>Ok, so installing multiple packages in one go would be done by this command: "guix package -i evince powertop gnome-icon-theme" ?
<civodul>but really, it seems like a weird use case to me
<civodul>roelj: currently you have to repeat -i for each package
<mark_weaver>for now, you need to put a '-i' before each one.
<roelj>ah ok
<mark_weaver>but I have a patch to fix that, soon to be merged I think.
<civodul>so "guix package -i evince -i powertop -i gnome-icon-theme"
<roelj>oh, are you using getopt to process them?
<civodul>mark_weaver: great idea that you had, BTW
<mark_weaver>we're using a scheme library, SRFI 37.
<mark_weaver>civodul: thanks. I can't remember why I thought SRFI 37 wasn't powerful enough to do it.
<mark_weaver>but when I looked into it, I realized it was.
<civodul>yeah, i didn't know about multiple-value support
<mark_weaver>oh, you mean support for multiple seeds in the fold?
<civodul>yes
<mark_weaver>obviously it could have been done even with only one seed, but it wouldn't have been as nice.
<civodul>yeah
<mark_weaver>I'm tempted to make the arguments to install/remove/upgrade optional, so that you can say "guix package --install a b c"
<mark_weaver>although that would also allow zero arguments after -i or --install, which isn't great.
<mark_weaver>WDYT?
<mark_weaver>I suppose it would be possible to tell SRFI-37 that the argument to install/remove/upgrade is optional, but then arrange by other means to verify that at least one argument is provided, although that would get a bit messy.
<mark_weaver>s/would/might/
<mark_weaver>OTOH, if we're allowing any number of arguments, maybe allowing zero is sensible.
<civodul>hmm
<civodul>yeah
<civodul>yeah, it's just a matter of changing the 'optional?' bit to #t, i guess
<civodul>but we need to check that everything still works fine after that :-)
<mark_weaver>we could also tell SRFI-37 that install/remove/upgrade don't accept arguments. this would prohibit the --install=... syntax in favor of --install ...
<mark_weaver>in some ways, I think that might be the cleanest outcome, but it depends on how much you care about preserving backward compatibility with the --install=... syntax.
<mark_weaver>if we make it optional, then we have to check whether the arg is #f. not a big deal, but one additional complication.
<civodul>still i think i'd prefer preserving backward compatibility
<mark_weaver>okay, I'll update the patch.
<civodul>also because it's more consistent to support --install=foo
<mark_weaver>I'm having trouble figuring out how to summarize this syntax in the docs.
<mark_weaver>(and in the --help)
<mark_weaver>any suggestions?
<civodul>mark_weaver: i would just add examples
<mark_weaver>okay
<mark_weaver>civodul: texinfo question: when I write "For example, to remove lua and install guile and guile-cairo", should add any markup to those package names, or capitalize them?
<mark_weaver>(I marked up the actual command with @example)
<mark_weaver>well, I'll just post what I've done, and it can go through another round of review if desired...
<civodul>mark_weaver: you could use @code{lua}, @code{guile}, etc.
<civodul>or Lua, Guile, etc.
<civodul>but i'd prefer @code{lua} in that case
<mark_weaver>okay, thanks
<mark_weaver>is my example in poor taste? :)
<civodul>ah no, i like it :-)
<mark_weaver>:)
<civodul>i had a one of that kind in the ELS paper ;-)
<mark_weaver>if we had a PHP package, I would have removed that one, but I don't.
<civodul>heheh
<Steap>hahhaah
<Steap>I'd package systemd just to be able to remove it in the doc.
<mark_weaver>hehe
<mark_weaver>hmm. the way things are currently implemented, "guix package --upgrade gcc" will upgrade all packages, because from SRFI 37's perspective, --upgrade doesn't have an argument.
<mark_weaver>(two 'upgrade items will be added to the alist, one with #f and one with "gcc")
<mark_weaver>I guess I can fix that by removing any (upgrade #f) elements when I add the (upgrade gcc)
<mark_weaver>okay, fixed.
<roelj>So, Guix separates packages per user. How can the linux-libre package be used?
<roelj>Should I manually update my /boot/grub/grub.cfg file to boot the kernel from /nix/store or /home/roel/.guix-profile/?
<mark_weaver>definitely don't boot from the .guix-profile symlink. booting directly from /nix/store would be fine, or make a symlink from somewhere to it. I'm not sure what the recommended practice is at this point.
<mark_weaver>I guess you'll need a symlink from /lib/modules/* as well
<a_e>Hello!
<a_e>civodul: Did you not enable https downloads some time ago?
<a_e>I am working on pysqlite, which was hosted on google code; the http download redirects to https, and it finishes before the end with
<a_e> https://pypi.python.org/.../pysqlite-2.6.3.tar.gz 85.8% of 74.6 KiBERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum The TLS connection was non-properly terminated.> fill_session_record_port_input)'.
<civodul>oh, a_e stumbled upon that bug, i guess
<civodul>roelj: ultimately you'd "instantiate" a system configuration, which specifies a kernel, initrd, etc.: http://www.gnu.org/software/guix/manual/guix.html#System-Configuration
<roelj>That looks pretty cool.
<a_e>civodul: It is a known bug? I have vague memories of such errors being reported.
<mark_weaver>there are multiple problems with the pypi.python.org web site. the http URL redirects to https, where there is an invalid certificate (domain name doesn't match the cert).
<mark_weaver>maybe there's also a problem with not closing the TCP connection cleanly, I don't remember.
<mark_weaver>they ought to fix their site.
<civodul>hey a_e
<a_e>Amazin, the certificate is for *.a.ssl.fastly.net instead of pypi.python.org.
<a_e>Why does my icecat not complain?
<civodul>a_e: it looks like http://bugs.gnu.org/14884
<a_e>Indeed! Here, however, we cannot use http, as it is redirected.
<civodul>argh
<civodul>the short-term "solution" is to find a mirror :-/
<a_e>I do not see any exception for this bad certificate. Very strange!
<a_e>We used the google code mirror, but that went down.
<a_e>Currently, hydra is a mirror.
<mark_weaver>that doesn't help us (sane people) who turn off substitutes.
<mark_weaver>going afk for a bit...
<a_e>And it will not help whenever the file is to be updated. (Well, one can probably manually do a wget and guix download file:... on hydra, but this is really not what we want).
<civodul>yeah
*civodul goes afk
<civodul>good night/day!