IRC channel logs


back to list of logs

<rgc>hi. is every package supposed to be referenced in or there are just the packages that are in the GUIX distro?
<mark_weaver>greetings, civodul!
<mark_weaver>I've made a big step. I've switched to running my X session (all programs within) with a Guix-only environment (e.g. only ~/.guix-profile/bin in my PATH).
<mark_weaver>it's working nicely so far!
<civodul>i'm still missing some programs i occasionally use, like GIMP
<civodul>but most of what i use daily comes from Guix
<mark_weaver>it involved a downgrade of openssh (surprising to me). I'm currently building openssl-1.0.1f and openssh-6.5p1 as Guix packages. will post soon.
<civodul>i'm struggling with SLiM/Xorg at the moment
<zerwas>count me in as soon as we have LyX, Pidgin, chromium, Calibre, smplayer, deadbeef, ... :D
<mark_weaver>The immediate things I notice missing are bitlbee (and libotr), lynx, gnupg-1 (used by Gnus last I knew), paredit, magit, emacs-w3m and emacs-wget. for now I just hand-copied the emacs things from my old setup, and am using the old bitlbee as an exception.
<mark_weaver>anyway, I'll contribute packages for these after 2.0.10 is out.
<mark_weaver>gdb-7.7 fails to build on MIPS. 7.6.2 worked.
<rgc>hey guys, a little question: is every package supposed to be referenced in or there should be just the packages that are supposed to be in the GUIX distro?
<mark_weaver>what's the difference?
<mark_weaver>every file in gnu/packages/*.scm (not every package) should be there. also all patches.
<rgc>I thought contained the set of packages that would be installed when creating the .iso, or whatever. I might be totally wrong though :). on the other side, I just added a file in gnu/packages/ and I can build and install it without being in the
<mark_weaver>no, it has nothing to do with any ISO. but yeah, it'll work without it, but being in means that "make" will compile the associated file.
<mark_weaver>and that "make install" will install it (perhaps more importantly)
<rgc>aha, ok, now I get it. thanks!
<mark_weaver>if it's not installed, then someone who runs "make install" and then tries to install your package from the installed copy of guix will fail.
<mark_weaver>rgc: glad to help :)
<civodul>mark_weaver: i tend to get the Emacs packages from elsewhere actually :-)
<civodul>but i need bitlbee too, indeed
<mark_weaver>if you do it before I do, a warning: bitlbee needs libotr, but last I checked needs an old version: libotr-3.*, whereas there's also a newer (and API incompatible) libotr-4.*
<mark_weaver>but maybe the situation has changed since the last time I looked.
<mark_weaver>civodul: do you use elpo/marmalade or something like that?
<mark_weaver>or is it elpa? I've never used those things, so I'm fuzzy on them.
<mark_weaver>I worry about the security. I suspect they're not authenticated well, if at all.
<civodul>ELPA yes
<mark_weaver>do you think openssl can be upgraded in master, or should it go into core-updates instead?
<civodul>i think it's OK for master
<civodul>probably a lot of rebuild, but that happens :-)
<mark_weaver>the new openssh has support for Bernstein's Curve25519, which seems to be popular these days among people who worry about the NSA. there's a new diffie hellman exchange based on it that gets used by default if both client and server support it, a new public key type based on it, and a new private key format based on it as well.
<civodul>i think gcrypt 1.6 brought that too
<mark_weaver>I know that the Gnunet people seem to like Curve25519 as well.
<jmd>How do I create a package with multiple outputs?
<jmd>More specifically, how do I control what goes into which output?
<civodul>jmd: there's a bit of info in "Packages with Multiple Outputs"
<civodul>basically, there are several "known" output names
<civodul>known to gnu-build-system, that is
<jmd>I read that.
<jmd>It only says how to install them.
<civodul>so if you look at gnu-build-system.scm, in 'configure', it recognizes "lib", "debug", "doc", etc.
<civodul>which means, if a package declares an output called "lib", gnu-build-system.scm automatically invokes ./configure with --libdir=$lib/lib
<civodul>but you can just as well add your own #:configure-flags that do what you want
<civodul>an example of that is glib, in glib.scm
<jmd>Yes I'm looking at that now.
<jmd>So if I was to declare ab output call "foo" it would call --foodir=$foo/foo ?
<mark_weaver>speaking of multiple outputs, I was thinking: how about unifying the gcc packages into one packages with multiple outputs? or maybe two: one with just c/c++ and one for everything else?
<mark_weaver>it seems to me that there's a huge amount of wasted build effort, building so many variants.
<mark_weaver>those who use substitutes shouldn't be affected, and those who do build would prefer fewer copies of gcc to build, I would think. they take an enormous amount of time for me to build on the 2F.
<mark_weaver>well, I don't care that much, just an idea :)
<civodul>jmd: yes but $foo is (assoc-ref %outputs "foo") in code
<civodul>mark_weaver: yes, but that seems difficult to do
<civodul>because you'd have to move the run-time support libs in the right place
<civodul>so change their RPATH, etc.
<mark_weaver>ah, yes, I see. makes sense. there are more important things to do :)
<civodul>yes, another good reason ;-)
<mark_weaver>I wish I knew why I can't upgrade my readline. union.scm tries to open a directory and perform 'get-bytevector-n!' on it, for some reason.
<civodul>when doing "guix package -u readline"?
<mark_weaver>speaking of which, what happens if I build guile from two libraries in Guix that are themselves linked with different copies of libc?
<civodul>roughly, it doesn't work :-)
<mark_weaver>civodul: yeah. same thing happens with -i, unsurprisingly. I tried it twice: same result.
<civodul>can you try to reproduce it on a small profile?
<civodul>upgrading readline works for me
<civodul>maybe it's something else in your profile
<mark_weaver>I'm not sure how to do that. from the backtrace, it vaguely looks as though it's trying to include two copies of readline in the same profile, or something.
<mark_weaver>I don't know how to add anything old to a new profile. is there a way?
<mark_weaver>(I actually wish there was, because I want the old gdb that I built once, since the new one fails to build)
<civodul>guix package -p foo -i /nix/store/...
<mark_weaver>ah, thanks!
<civodul>otherwise, it may be easier to turn on debugging in union.scm
<mark_weaver>okay, I'll poke at it. thanks for the ideas.
<civodul>mark_weaver: in profiles.scm, just comment out #:log-port, and try again the faulty command
<civodul>you'll see what file/dir it chokes on
<mark_weaver>well, I can see from the backtrace that it's choking on /nix/store/y9q8dwgs8lxww2khkk1hfji1jihkfcz3-ncurses-5.9/lib/terminfo
<mark_weaver>I sent an email to guix-devel about it a few hours ago.
<mark_weaver>it calls 'call-with-input-file' on "/nix/store/y9q8dwgs8lxww2khkk1hfji1jihkfcz3-ncurses-5.9/lib/terminfo" and tries to do 'get-bytevector-n!' on it.
<mark_weaver>interestingly, the next call up the trace, immediately above [call-with-input-file "/nix/store/y9q8dwgs8lxww2khkk1hfji1jihkfcz3-ncurses-5.9/lib/terminfo" ...], is [call-with-input-file "/nix/store/25mp69n6i16b308sbyh42ic3qzld46li-ncurses-5.9/lib/terminfo" ...]
<mark_weaver>(same package, two different hashes)
<mark_weaver>terminfo is a symlink, btw.
<mark_weaver>civodul: can you deduce from the above what's going on?
<mark_weaver>seems very fishy to me. looks like it's trying to include two copies of 'readline' in the same profile, and then it doesn't know how to handle unifying two symlinks to directories properly.
<mark_weaver>or something like that.
<mark_weaver>hmm, I wonder if a propagated-input is causing the old readline to be included?
<jmd>So far as I can tell, adding an output foo, achives nothing. Except that after the package is succcessfully built, the build says "failed to produce output path: /nix/store/....-foo" and then fails.
<mark_weaver>jmd: well, you have to arrange for the directory to be created and for things to be copied there. that would normally be handled by adding a directory specification to ./configure, which would normally cause those things to be done.
<jmd>But configure is written by upstream. Are you suggesting that I patch it?
<mark_weaver>is there not already an option to configure to specify the output directories you need, such that the different outputs will be put into different directories?
<mark_weaver>jmd: let me ask a different question: did you make any arrangement for new files to be placed in the new output directory?
<jmd>The answer to the second question is "no"
<mark_weaver>it needn't be done by configure. you could make a new phase, I suppose.
<mark_weaver>jmd: well, then :)
<mark_weaver>how did you expect it to work?
<mark_weaver>or is it one of the standard outputs?
<jmd>Well that was why I came here to ask - how is it supposed to work?
<mark_weaver>if there are multiple outputs, then there are multiple output directories in /nix/store/
<mark_weaver>in the one-output case, --prefix=/nix/store/* is passed to configure.
<mark_weaver>in the case of many of the standard outputs, they are handled by passing something things like --bindir=/nix/store/* to configure.
<jmd>ok. I need to experiment further.
<mark_weaver>and then there's nothing else to do. configure arranges for those directories to be created and the appropriate things copied there.
<mark_weaver>if you can't do it that way, then I guess you need to do something else. maybe patch something, or add a new phase, or something.
<mark_weaver>all the users in guix-builder have perms to create directories in /nix/store/
<jmd>ok. Thanks.
<jmd>maybe I can do something like make -C install DESTDIR=/nix/store/....
<mark_weaver>I think that's not right. I think both DESTDIR and PREFIX will be concatenated together. also, won't that mean that everything goes into DESTDIR, e.g. just one output?
<jmd>(incidently, I think the gnu-build-system doesn't set DESTDIR but relies upon the default, which I have noticed causes a number of install conflicts)
<mark_weaver>it uses --prefix
<mark_weaver>not DESTDIR
<mark_weaver>jmd: out of curiosity, what is the nature of the split that you're trying to accomplish? what different outputs?
<jmd>It should set DESTDIR, even if just to "/"
<jmd>I'm trying to get postgres to put its client progs in separate outputs.
<mark_weaver>is it not safe to rely on DESTDIR=/ as the default?
<jmd>... or at least one for server and one for clients.
<jmd>mark_weaver: Many packages' install targets behave different if DESTDIR is ""
<mark_weaver>well, I claim ignorance on this subject, you'll have to take it up with civodul :)
<mark_weaver>if the upstream build system doesn't support the split, it will be a pain. the thing is, you have to arrange for all the hardcoded paths to be correct. the rpaths to the library have to point to the /nix/store/* where the libraries are located. anything that invokes the client programs needs to hardcode the /nix/store/* with the client programs.
<jmd>Most distributions (eg Debian), set DESTDIR=/something when building their packages. Thus, the pacakges know not to emit things which are going to conflict.
<mark_weaver>it may be that it's just not worth it.
<mark_weaver>jmd: okay. would you like to post to guix-devel about it?
<mark_weaver>you might want to include some examples of such packages.
<mark_weaver>Debian works differently. they generally set --prefix=/usr and use DESTDIR to copy the things to a staging area that gets archived.
<mark_weaver>it's important to understand the difference between --prefix and DESTDIR. --prefix is where things will be located when the final package is installed. DESTDIR (with PREFIX added) is where to copy things right now during "make install", even though they won't be there when the programs are run.
<mark_weaver>because of the way Guix works, we don't need DESTDIR, because PREFIX is already unique.
<jmd>You are half right.
<mark_weaver>what am I wrong about?
<jmd>Because of the chroot, we don't "need" DESTDIR. But if we don't have it, packages assume that we are installing in a live system.
<jmd>That is why (I think) I see lots of conflicts when doing guix package -i
<mark_weaver>well, I'm not sure why it matters though. in a sense, the chroot is a live system, albeit cut off from the network. all of the things it's supposed to need are there; it's being installed in it's final location, etc.
<jmd>The problem arises when two package ship the same file.
<mark_weaver>I don't see how this could have any affect on the number of conflicts.
<mark_weaver>s/a/s/ :)
<mark_weaver>jmd: well, it's not going to see the other package that ships the same file in any case.
<jmd>The install target refrains from shiping it if DESTDIR != ""
<mark_weaver>can you give a concrete example?
<mark_weaver>(I'm not saying you're incorrect, I just want to understand better)
<mark_weaver>what's an example of something is installed if DESTDIR == "", and not installed if DESTDIR == "/", and that we don't want it to install?
<mark_weaver>s/is/that is/
<jmd>ok. Most gnome applications have something similar to this in their makefile
<jmd>I think they put the condition in after Debian complained that ALL gnome applications shipped the same file.
<jmd>I think there is a similar issue with the info top level node.
<mark_weaver>jmd: okay, that's very helpful, thanks! can you post to guix-devel, and include these examples?
<mark_weaver>indeed, things like the icon cache, and the info dir, should be created when a profile is built, I think.
<mark_weaver>that's a whole subsystem that needs to be created: custom union handlers.
<mark_weaver>font cache too.
<jmd>(at work this week, I found that a system which was supposed to be setting an environment variable to "foo" was in fact setting it to " foo ")
<jmd>nobody had noticed for years because everyone writes naive shell scripts.
<mark_weaver>I'm confused. was anything trying to use this environment variable? how did that work?
<mark_weaver>oh, nevermind.
<mark_weaver>I was thinking that the variable name had a space.
<jmd>No the value.
<mark_weaver>right. I'm underslept, sorry :-/
<mark_weaver>yeah, I find the shell's handling of meta-characters intolerable. When I write a shell script, I try to make it robust, and sometimes I just can't figure out how to do it.
<mark_weaver>sometimes, there really is no way to do it, because of the way the interfaces have been specified.
<jmd>mark_weaver: I think the only way is IFS=\\0 while read -d '' ; ... ; done
<jmd>Or something similar.
<mark_weaver>jmd: right, but if you need to pass things to an existing script that doesn't do that, there might be no way.
<jmd>Yeah. If a script it poorly written, you are stuffed!
<mark_weaver>fyi, looks like Debian will be using systemd as the default init system in jessie.
<davexunit>seems to be what's happening.
<jmd>When downloading from hydra, there needs to be some sort of confidence indicator.
<Steap_>civodul: having any trouble with it ?
<civodul>heh :-)
<civodul>it's not #debian here ;-)
<Steap_>civodul: yeah, seems like they're moving to systemd
<Steap_>or not, because they have a weird voting system
<civodul>Condorcet, right?
<Steap_>well, it's both weird and clever
<Steap_>The problem is, by the time systemd lands in Sid, the GNU system won't be ready
<Steap_>which means I might have to move to NetBSD.
<Steap_>or just not give a shit about using that Poettering crap
<Steap_>Funny, I need to add '.' to a python package so that the tests work
<Steap_>while '.' is always supposed to be in the python path
<civodul>'.' in the search path is a Bad Idea
<Steap_>why is that ?
<civodul>because you never know what code you'll end up running
<Steap_>you'd rather add an absolute path to the directory ?
<davexunit>hey #guix, just saw this on
<davexunit>I believe joeyh is a debian developer and the author of git-annex among other things.
<davexunit>and he claims that nix is "about 15 years behind state of the art on security"
<davexunit>at the end of the post he asks if Guix is any better in this regard.
<civodul>i think Guix is 7.5 years ahead the state of the art, yeah
<civodul>"the FSF's fork"
<civodul>davexunit: so we verify sources by SHA256 (and so does Nix these days)
<civodul>regarding signatures, that's something we're working on (well, Nikita), with help from the Nix folks for the Hydra side of things
<civodul>to put it differently, these are known issues being worked on
<davexunit>civodul: thanks
<civodul>davexunit: see for instance
<davexunit>thank you.
<civodul>you're welcome :-)
<civodul>(sorry for overreacting)
<davexunit>I was just curious about it.
<Steap_>How do I get the version of a package while writing code in #:phases ?
<Steap_>",version" it seems
<civodul>you could do ,version
<Steap_>Scheme's magic.
<civodul>"unquote version"
<mark_weaver>Steap_: I get the strong impression that sysvinit will still be supported on Debian, in jessie at least. I think this vote was just about the _default_ init system for jessie.
<Steap_>mark_weaver: yeah, which means I may have to configure stuff to avoid systemd
<civodul>or just don't upgrade
<civodul>and help so we can all switch to GNU :-)
<Steap_>civodul: I run Sid, I never "upgrade" to a newer version :)
<mark_weaver>civodul: indeed, that's the best solution :)
<mark_weaver>Steap_: based on my understanding of Debian (which I've mostly run on all my computers in the last 15 years), I expect you won't have to do anything.
<mark_weaver>it'll just stay on sysvinit for you.
<mark_weaver>dejavu is really a lot better than vera.
<mark_weaver>that's a noticeable downgrade from my home-built system that uses dejavu.
<mark_weaver>(I'll take care of it at some point :)
<Steap_>mark_weaver: that'd be nice!
<civodul>damn, just got an annoying SLiM bug
<civodul>now we'll need GNU themes for GRUB, SLiM, and all that
<rgc>mm.... can someone try ./pre-inst-env scripts/guix download , I get an error, but wget doenloads it correctly... maybe the server expects some header or something that 'guix download' is not sending, but first I'd like to reproduce it somewhere else
*civodul gets 500 "blocked for one hour"
<rgc>yup, the same here, but wget does it fine :/
<civodul>but wget succeeds, indeed
*rgc rolls sleeves
<civodul>rgc: can you email with that?
<civodul>so we keep track of it
<rgc>any signup needed?
<civodul>rgc: no, it's wide open :-)
<civodul>wget does "Connection: Keep-Alive" whereas Guile does "Connection: close"
<civodul>could be the reason
<civodul>rgc: the problem is the missing 'User-Agent' field
<civodul>i'll push a patch
<rgc>ooh, just sent the mail