<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>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)
<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>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 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>... 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>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.