IRC channel logs
2014-02-09.log
back to list of logs
<rgc>hi. is every package supposed to be referenced in gnu-system.am? or there are just the packages that are in the GUIX distro? <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). <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. <rgc>hey guys, a little question: is every package supposed to be referenced in gnu-system.am? or there should be just the packages that are supposed to be in the GUIX distro? <mark_weaver>every file in gnu/packages/*.scm (not every package) should be there. also all patches. <rgc>I thought gnu-system.am 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 gnu-system.am <mark_weaver>no, it has nothing to do with any ISO. but yeah, it'll work without it, but being in gnu-system.am 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. <civodul>mark_weaver: i tend to get the Emacs packages from elsewhere actually :-) <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. <mark_weaver>do you think openssl can be upgraded in master, or should it go into core-updates instead? <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. <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 <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. <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 <mark_weaver>ah, yes, I see. makes sense. there are more important things to do :) <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? <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>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/... <civodul>otherwise, it may be easier to turn on debugging in union.scm <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>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>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. <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>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>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. <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>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>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>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>(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? <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. <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>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! <jmd>When downloading from hydra, there needs to be some sort of confidence indicator. <Steap_>civodul: having any trouble with it ? <Steap_>civodul: yeah, seems like they're moving to systemd <Steap_>or not, because they have a weird voting system <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 <civodul>because you never know what code you'll end up running <Steap_>you'd rather add an absolute path to the directory ? <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>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 <Steap_>How do I get the version of a package while writing code in #:phases ? <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>and help so we can all switch to GNU :-) <Steap_>civodul: I run Sid, I never "upgrade" to a newer version :) <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>that's a noticeable downgrade from my home-built system that uses dejavu. <civodul>now we'll need GNU themes for GRUB, SLiM, and all that *civodul gets 500 "blocked for one hour" <rgc>yup, the same here, but wget does it fine :/ <civodul>rgc: can you email bug-guix@gnu.org with that? <civodul>wget does "Connection: Keep-Alive" whereas Guile does "Connection: close" <civodul>rgc: the problem is the missing 'User-Agent' field <rgc>ooh, just sent the mail