IRC channel logs

2014-04-05.log

back to list of logs

<phant0mas>good morning guix
<civodul>Hello Guix!
<phant0mas>hello civodul
<phant0mas>Did you check the build.log I sent? :-)
<civodul>not yet, sorry!
<civodul>will do, really
<phant0mas>I know you are busy, so take your time :-)
<davexunit>I'm so glad that the FOSDEM talk is finally available!
<mark_weaver>If people haven't already seen it, I _highly_ recommend watching Jacob Appelbaum's keynote at 30c3, entitled "To Protect and Infect Part 2".
<alirio>'nix' was removed from many paths, I wonder why e.g. '/tmp/nix-build-python-3.3.3.drv-0' still exists
<civodul>we'll take care of that one later ;-)
<civodul>it's not really a user-visible thing, so it's not very important
<phant0mas>civodul: ok I added the rules in Makerules file and it seems to work :-D
<civodul>good!
<civodul>let youpi & co. know
<phant0mas>ok
<phant0mas>now some problems arised while it builds libpthread with some implicit declaration of functions
<phant0mas>I am looking into that
<civodul>phant0mas: the non-technical mission of your GSoC (and beyond) will be to get tschwinge & Roland involved :-)
<phant0mas>understood
<civodul>ofc this is much harder than the technical part ;-)
<phant0mas>is sending ghost to haunt them a viable option ? or it will be too extreme?:P
<phant0mas>I am just kidding :P
<civodul>heheh
<davexunit>so I'm installing guix on a new computer, and I'm running into an issue that I think I had when I installed it on my laptop.
<davexunit>I get the daemon running, and then when I run "guix package -i guile" I get a match-error exception.
<davexunit> http://paste.lisp.org/display/141928
<davexunit>seems I had something wrong with my submodule
<davexunit>is there any documentation on how to modify your environment variables so that you are using guix packages entirely?
<mark_weaver>davexunit: we could use more docs on this. I had to figure it out on my own.
<davexunit>mark_weaver: was it a matter of just changing the right environment variables?
<mark_weaver>fwiw, here's my .bash_profile : http://paste.lisp.org/+31IH
<davexunit>mark_weaver: thanks.
<mark_weaver>on my system, I'm using a patch to enable the system-wide trust store for gnutls. without it, some more things will have to be configured, such as a suitable .wgetrc to tell it where to find the certs.
<davexunit>oh, I see.
<mark_weaver>there might be other things too. basically, every client that uses gnutls needs its own configuration of how to find the trust store.
<davexunit>okay, well this should be enough to get me started. thanks.
<mark_weaver>np!
<davexunit>time to try it out.
<civodul>mark_weaver: normally "guix package --search-paths" gives almost everything, no?
<mark_weaver>"almost" being the key word :)
<civodul>:-)
<civodul>as far as search paths are concerned, only $PATH is missing
<civodul>then of course, there's $ASPELL_CONF, $SSL_*
<mark_weaver>and GIT_SSL_CAINFO and .wgetrc and perhaps others if you're not using my patch to enable the gnutls system trust store.
<mark_weaver>(generally everything that uses gnutls has its own configuration that needs to be fixed)
<mark_weaver>TZ and TZDIR, not sure if those are mentioned.
<mark_weaver>SHELL and maybe PAGER
<mark_weaver>the other big set of gotchas for the unseasoned guix user is the ordering relationships between packages to make sure you get the right versions of things.
<mark_weaver>ld-wrapper after binutils, bash after glibc, and I prefer coreutils after procps and inetutils after net-tools and poppler after xpdf.
<mark_weaver>so right now I have to manage that manually.
<mark_weaver>whenever I install or upgrade any of those packages the need to be before another one, I have to make sure to install the later one again.
<civodul>ah right
<civodul>ok, lemme do that gcc-toolchain package that i promised months ago
<civodul>:-)
<civodul>but yeah, there's a lot of room for improvements
<mark_weaver>yeah, that's fine, a lot of this is on my TODO list, and I'll get around to them eventually, if no one else does them first :)
<mark_weaver>also, I've found that the upgrade command is mostly useless to me as-is.
<mark_weaver>the problem is that I have some older versions of packages installed, and upgrade would get rid of them. for example, I have old texinfo, old (and new) gnupg, and sometimes old gcc.
<civodul>right, i see
<mark_weaver>we need a way to specify that I want texinfo 4, and both gnupg-2.0.x and gnupg-1.4.x, and upgrade should honor those.
<civodul>yes, perhaps a per-package "upgrade path" specification
<civodul>needs some thought
<mark_weaver>btw, gcc 4.8.2 has some problems on MIPS, such that it cannot be used to compile kernels.
<civodul>argh :-/
<mark_weaver>I seem not to have stumbed upon problems with any other packages.
<mark_weaver>(so far)
<mst>btw, the more I mess about with the stuff I've been poking at the more I'm happy with it being external
<mst>but
<mst>I have a more refined, and probably more useful, question about direction
<mark_weaver>just in case you were thinking about getting rid of gcc 4.7.3 anytime soon :)
<mst>a lot of what interests me about guix is the potential to use it as a better nix, rather than a better nixos - i.e. to use it to drive local software installation within the context of a host operating system for situations where I want an island of sanity separate to the contents of /usr/*
<mst>is that going to be a first class use case or are you regarding that as primarily a way to bootstrap into a complete guix-the-OS installation?
<civodul>mst: more the latter, for me
<civodul>but the former is already supported, and should remain so
<mst>right. basically, I'm trying to work out whether I should be trying to use guix for that or whether the features/patches I'm liable to want will end up being more hassle than they're worth to you, in which case I should go back to looking at nix
<mst>this is genuinely not a complaint. I just don't want to end up being 'the guy who does something weird and actually we mostly wish he would just go away' :)
<mark_weaver>mst: what set of host operating systems are you interested in using guix for?
<mst>for the immediate future, if I can just get it to work on assorted linuxes I'll be pretty happy - my long term personal goals involve running on *BSD, Solaris derivatives and win32 but I really don't expect guix to handle all of those
<mark_weaver>well, guix should be portable to GNU/Linux systems, at least.
<davexunit>is there a operating-system defined in the guix repo? I'm looking for a good list of packages that I should have installed as base.
<davexunit>I grepped and found only the code to define an operating-system.
<civodul>mst: but not that Guix will be restricted to GNU/Linux (and perhaps GNU/{Hurd,kFreeBSD}), whereas Nix tries to do everything
<civodul>*note
<civodul>davexunit: there's one in the manual, and i'll add one so it can be built on Hydra
<civodul>and read :-)
<davexunit>civodul: oh, the manual. okay! thanks.
<mark_weaver>davexunit: fwiw, here's the list of packages in my profile: http://paste.lisp.org/+31II
<mst>civodul: yeah, on considered thought I *would* be one of 'those' users. as such, I have a new plan: hang around anyway, share and steal ideas, and stop stressing about whether I'll ever be a user :)
<davexunit>mark_weaver: thanks.
<mark_weaver>davexunit: btw, I wanted to mention a few gotchas for now: the order in which you install packages is important in a few cases, because there are conflicts between packages (two packages try to different versions of the same file).
<mst>especially since if all the mainstream distros try and ram systemd down my throat I'm going to end up being a FreeBSD user primarily instead in a couple years
<davexunit>I installed ncurses yet I still can't "clear" at the terminal. :(
<davexunit>it can't find the ncurses library when I try.
<mark_weaver>davexunit: for now, when running "guix package -i", the packages named later in the list take priority over the earlier ones.
<mark_weaver>the following orderings are important: (binutils ld-wrapper) (glibc bash), and the following ones are less important, but I prefer them: (net-tools inetutils) (procps coreutils) (xpdf poppler)
<mark_weaver>(x y) means that y should take priority over x, which means that they should be listed in order (x y) in the "guix package -i" line.
<mark_weaver>and if you ever reinstall or upgrade x, make sure to add 'y' after it in the '
<mark_weaver>"guix package -i" command.
<mark_weaver>obviously this is all very crude right now, and these things need to be fixed.
<mark_weaver>(union needs to be smarter)
<mark_weaver>davexunit: indeed, 'clear' is broken for me too.
<mark_weaver>the ncurses package needs to be fixed. there's a missing rpath.
<mark_weaver>davexunit: could you send mail to bug-guix@gnu.org about the ncurses problem?
<davexunit>mark_weaver: thanks for the info.
<civodul>ah yes, and 'reset' too
<civodul>i noticed it some time ago and then forgot
<civodul>so bug-guix is the right thing
<mark_weaver>davexunit: btw, that list of packages I sent you is ordered such that you can do "guix package -i $(cat PKG_LIST)". I actually keep that list in a file and run that command periodically to upgrade.
<mark_weaver>(that's my upgrade command, for now :)
<mark_weaver>emacs comes last because I want its share/info/dir file to take precedence over the others, until union can make a proper merged dir file.
<davexunit>mark_weaver: thanks for the advice. I have to leave the house now so I'll be reading that over later.
<mark_weaver>okay, ttyl!
<alirio>mark_weaver: I have a script that summons the daemon, "guix package -i"... and kill the daemon, among other things, that's my upgrade command
<mark_weaver>heh :)
<mark_weaver>I leave the daemon running always.
<mark_weaver>mst: btw, although Debian will make systemd the default init system for jessie, they will surely be supporting other init systems for a long while.
<alirio>mark_weaver: so you manually restart it when the submodule is upgraded...
<mark_weaver>yes
<mark_weaver>mst: the fact that they have official Hurd and kFreeBSD ports, and that several very prominent debian devs (and about half of the technical committee) is concerned about systemd will ensure that they'll support other init daemons for the foreseeable future.
<mst>right, but systemd's intertwingling with DBus and udev means that in the long run it's going to get increasingly hard to avoid
<mark_weaver>I haven't heard about dbus being increasingly dependent on systemd. any link for that?
<mark_weaver>but even if that's true, it is things higher up in the stack that depend on dbus. I don't see how switching to freebsd would help that.
<mark_weaver>to avoid dbus, you have to avoid the desktop stuff built on top of it, and you could do that on a debian system as well.
<mst>it's the systemd developers who're trying to get dbus into the kernel
<mst>it's more that systemd makes you dependent on dbus for the preferred ways of doing some things
<mst>I can see all this stuff being almost reasonable on a desktop, but on a server it reminds me of Windows NT moving the display server into the kernel for performance
<mark_weaver>I've heard of moves to support dbus directly in linux (the kernel), but that has always sounded like an optional thing. the userland library isn't going anywhere.
<mark_weaver>I don't understand "it's more that systemd makes you dependent on dbus for the preferred ways of doing some things". what do you mean?
<mst>right. but dbus was designed for desktop purposes
<mst>I don't want a thing designed for desktop purposes to be a key part of my init system
<mark_weaver>so don't use systemd.
<mark_weaver>that doesn't require switching to freebsd
<mark_weaver>well, whatever. do what you like :)
<mst>RHEL is moving to systemd, so's ubuntu; debian instends to make systemd the default, which means that most likely the sysvinit support will eventually bitrot
<mst>once that happens, I'll need a new OS of *some* sort, be it a linux distro or something else
<mark_weaver>the hurd and kfreebsd ports of debian will keep them from bitrotting.
<mark_weaver>not to mention all the debian users and devs who strongly dislike systemd.
<mark_weaver>all it takes is enough users choosing to run sysvinit and reporting bugs.
<mst>there were plenty of people who disliked udev and /run, and those didn't seem to be enough
<mark_weaver>what's wrong with udev?
<mst>so, I hope you're right, but I'm not sure that previous events are entirely in favour of that outcome
<mst>my opinion of udev is completely irrelevant to the point I was making
<mark_weaver>If you want to be counted in the users who hate GNU, copyleft, and especialy GPLv3, to the point of using very old versions of GNU software (such as gdb), then I guess FreeBSD would be a good match for you. Whether that's the case is up to you.
<mst>the GNU project was, so far as I was aware, created to enable the creation of free unix-like operating systems. I don't find a giant monolithic bag of tentacles replacing the init system to be particularly unix-like; the question is how far the people who hate unix will manage to hijack the linux distros.
<mark_weaver>well, GNU Guix is not going to use systemd, and generally you will find agreement around here on that point.
<mark_weaver>however, the primary purpose of the GNU project is to provide freedom to computer users.
<mark_weaver>and copyleft is a very important part of that.
<mark_weaver>I don't know what your opinions are about copyleft and GPLv3, but IMO that's the most important discriminator between FreeBSD and GNU/Linux systems.
<mark_weaver>if you agree that copyleft is a good idea, but don't like systemd, then it probably makes more sense to support non-systemd in the GNU/Linux environment, IMO.
<mst>given you suggested that simply using FreeBSD would categorize me as a user who hates GNU and copyleft, I'm afraid your thought process is sufficiently alien to me that I don't feel we can have a productive discussion about the political side of such decisions
<mark_weaver>okay, that was crudely stated, and overly simplistic.
<mark_weaver>anyway, we might as well drop it.
<mst>it smelled like a reflexive statement from a point of deep emotional involvement with the political side of things; I appreciate the things such passion can achieve but I also like to be aware of when it's likely to result in a conversation that gains nobody anything
<mst>I'm not even saying I'd necessarily end up disagreeing with you, just that we probably wouldn't manage to work out if we actually disagreed or not
<mst>and that, yeah, my real point here was "I hope systemd dies in a fire" and that part we seem to mostly agree on :)
<jmd>I haven't played with guix for a while. Having done a pull and make check I get 6 failures.
<jmd>Also I note that make check does not seem to respect TESTSUITEFLAGS
<mark_weaver>jmd: if you're using git, then after "git pull" you should do (cd nix; ./sync-with-upstream) and then rerun "autoreconf -vfi" and then configure and make.
<mark_weaver>(hopefully the submodule was updated automatically)
<mark_weaver>also, I seem to recall that at some point (when we switched to /gnu/store and LOCALSTATEDIR/guix as the defaults?) that you have to remove the 'test-tmp' directory.
<mark_weaver>since it's been a while, you might have to do that.
<mark_weaver>note that since the default store and statedir directories have changed, unless you override those, you'll essentially be starting from a clean slate.
<mark_weaver>and you'll have to manually remove the .guix-profile symlink in order for guix package to install the new one.
<jmd>All expect the removal of test-tmp should be done by bootstrap.
<jmd>So I'll try that.
<mark_weaver>I don't think bootstrap runs configure for you.
<jmd>Ah no that too.
<jmd>but it does do the synx-with-upstream and autoreconf I think.
<mark_weaver>and I'm not sure what "git submodule init" will do if it's already been init'd.
<alirio>it will not remove the .guix-profile symlink too
<jmd>git submodules are an abomination which should just go away.
<alirio>jmd: so how should nix-upstream be updated?
<jmd>alirio: What we do in the pspp project is simply to have a script which does (cd <repo>; git checkout <hash>)
<alirio>civodul: what do you think about removing the submodule?
<jmd>Anyway, after doing all that, I still get the same failures.
<jmd>Also the tests seem to be taking far longer than I seem to remember.
<mark_weaver>the first time you build after removing "test-tmp" (or starting with a fresh build), one of the tests takes a long time because it's essentially bootsrapping an internal test store and compiling a couple of packages.
<mark_weaver>jmd: do you have /dev/kvm ?
<jmd>no
<mark_weaver>it now needs to exist.
<jmd>touch /dev/kvm ?
<alirio>mark_weaver: civodul fixed that in nix, it works here without /dev/kvm
<mark_weaver>oh, right.
<mark_weaver>nevermind.
<mark_weaver>jmd: well, we'll need details I suppose :)
<jmd>What details do you need?
<jmd>Like I said, TESTSUITEFLAGS seems to be not honoured, so details are hard to see :/
<mark_weaver>well, look in the relevant *.log files for the tests that fail for clues. maybe you can figure out what's wrong, else tell us more.
<mark_weaver>I didn't know about TESTSUITEFLAGS, and am generally weak in my knowledge of build systems, so you'll have to ask civodul about that.
<jmd>ahh. ok.
<jmd>The first failure is derivations.log
<jmd>The suspicious looking line is
<jmd> actual-error: (system-error "lstat" "~A: ~S" ("File name too long" "/usr/share/guile/2.0/language/tree-il/./././././.
<jmd>... with the "././" repeated a zillion times.
<mark_weaver>interesting
<mark_weaver>what's the corresponding "test-name" ?
<jmd>FAIL: tests/derivations.scm
<jmd>
<jmd>I think.
<mark_weaver>no, I mean in the derivations.log, look for the first line that starts with " test-name:" above the one you showed us.
<jmd> test-name: "add-to-store, recursive"
<civodul>hey jmd, welcome back :-)
<jmd>Hi ludo
<civodul>jmd: what do $GUILE_LOAD_PATH look like?
<civodul>does it have ., or is it the empty string?
<jmd>unset at the moment.
<mark_weaver>what version of guile are you using?
<jmd>guile (GNU Guile) 2.0.5-deb+1-3
<jmd>
<civodul>and what does (search-path %load-path "language/tree-il/spec.scm") return?
<jmd>$1 = "/usr/share/guile/2.0/language/tree-il/spec.scm"
<civodul>and when guile runs from within ./test-env?
<mark_weaver>'directory-contents' seems like the likely culprit to me.
<jmd>civodul: Exactly the same.
<civodul>ooh, mark_weaver must be right
<civodul>jmd: at the REPL, could you try the 'directory-contents' procedure from tests/derivations.scm?
<civodul>you need to (use-modules (rnrs io ports)(ice-9 ftw)) before
<jmd>I'm not sure how to do all that.
<jmd>How do I load tests/derivations.scm without running it?
<mark_weaver>well, you can just copy that procedure into another file, or paste it directly into the REPL.
<mark_weaver>(after the 'use-modules' form that civodul pasted)
<mark_weaver>and then do (directory-contents "/usr/share/guile/2.0/language/tree-il")
<jmd> In procedure #<procedure 9b391e0 at <current input>:6:26 (path stat result)>:
<jmd><unnamed port>:6:26: In procedure module-lookup: Unbound variable: alist-cons
<mark_weaver>oops, you need (use-modules (srfi srfi-1)) also
<jmd>ok. Now I get a HUGE list of numbers
<jmd>Looks like it might be the ascii encoding of what I posted before.
<mark_weaver>so it didn't give a 'system-error' like when it was run in the test suite?
<jmd>I can't be sure. It gives so much output, it has exceeded the terminal's scroll buffer.
<mark_weaver>better to run (define foo (directory-contents "/usr/share/guile/2.0/language/tree-il"))
<mark_weaver>I actually happen to have a bare debian wheezy install here on the x60 that I haven't even compiled guile for yet, so I'l try to reproduce this.
<mark_weaver>civodul: I notice that the srfi-37.scm in guix is slightly different than the one in guile. is this a bug fix or an extension to srfi-37?
<mark_weaver>jmd: I can reproduce the same test failure on this debian wheezy box, using the guile from wheezy.
<mark_weaver>hmm. the output of 'pk' from within these test files seem to go nowhere I can fine.
<mark_weaver>*find
<mark_weaver>civodul: actually, the problem happens in 'add-to-store'
<civodul>mark_weaver: it's a snapshot of srfi-37.scm from Guile
<civodul>mark_weaver: so what's wrong in add-to-store?
<mark_weaver>civodul: well, that's where the lstat of /usr/share/guile/2.0/language/tree-il/././././././././././. ... is happening.
<mark_weaver>civodul: regarding srfi-37.scm, do a diff between the one in current guile-2.0 and the one in guix.
<mark_weaver>I wonder if they should be synced up.
<mark_weaver>(not sure which direction to go)
<civodul>i see no differences
<mark_weaver>civodul: oh, sorry, I was looking at srfi-37.scm from an older version of guile.
<civodul>np!
<civodul>if you can reproduce the bug with 2.0.5, i'm all ears
<civodul>for now, zZz
<civodul>:-)
<mark_weaver>okay, good night!
<zacts>lo