IRC channel logs

<bavier>I just did a `git pull` for guix, and am now getting an error from substitute-binary. It looks like its wanting to update a bunch of the core packages

<bavier>substitute-binary: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS

<civodul>bavier: yes, with the core-updates rebuild it wants to upgrade everything

<civodul>the warning above is suspicious though

<civodul>is it actually doing its work, in the end?

<bavier>guix build very quickly eats up all 4G of my ram, then dies

<civodul>irk!

<civodul>what version of Guile is it?

<bavier>guile (GNU Guile) 2.0.5-deb+1-1

<civodul>ok

<civodul>in substitute-binary.scm, there are two occurrences of n-par-map

<civodul>could you replace them with just par-map?

<civodul>and remove the %lookup-threads argument

<bavier>sure, I'll try that

<civodul>great, thanks

<civodul>we had a report before that could be related: https://lists.gnu.org/archive/html/guix-devel/2013-11/msg00042.html

<mark_weaver>civodul: upgrading to mit-krb5-1.11.4 seems not to have helped. it's been stuck in the same place for a little over 6 minutes now.

<civodul>we're unlucky

<civodul>:-)

<mark_weaver>when building the test program (which gets stuck), ld prints: "ld: warning: libkrb5support.so.0, needed by ../libdb.so, not found (try using -rpath or -rpath-link)"

<mark_weaver>although I guess that's not relevant. LD_LIBRARY_PATH gets set before running the test program.

<civodul>yeah

<civodul> http://krbdev.mit.edu/rt/Ticket/History.html?id=7651

<mark_weaver>apparently, most of the bug fixes since at least march are applied only to the master branch, and not to the 1.11.x branch.

<mark_weaver>(the bug I fixed in mit-krb5 with a patch for guix had been fixed in their repo in march, but not applied to the 1.11.x. branch until I reported having problems)

<mark_weaver>well, after 18 minutes, it's still stuck on that test, so I guess it's safe to assume the problem still exists in 1.11.4

<bavier>civodule: the switch to par-map seems to fix substitute-binary on my end

<bavier>*civodul

<civodul>bavier: good, thanks for testing!

<civodul>i guess we'll need a quirk for 2.0.5

<bavier>np

<bavier>we might also consider building bdw-gc with CFLAGS+="-DLARGE_CONFIG"

<civodul>well, it doesn't normally need that much memory

<civodul>and it clearly shouldn't

<civodul>mark_weaver: stuck in mpool_look, apparently

<bavier>no, it shouldn't for guix, but I've done some large data processing in guile, and have had to recompile bdw-gc to get things through

<civodul>ah, ok

<civodul>i don't know what tradeoffs are involved, actually

<bavier>I'm not sure either

<civodul>we should check that

<civodul>for now we could have a variant of libgc that does that

<civodul>'night/day people!

<mark_weaver>g'night civodul!

<jxself>Good time period....

<mark_weaver>bavier: would you like to find out why -DLARGE_CONFIG is not the default?

<bavier>mark_weaver: sure

<mark_weaver>thanks :)

<civodul>Hello Guix!

<jmd`>Using "guix package --list-*" is it possible to get the description/synopsis of the package - not just its name?

<civodul>jmd`: that's possible using "guix package --search"

<civodul>currently --list-* only display 4 columns

<jmd`>If I do "guix package --install=foo" where foo is some package which depends on a zillion other packges, what happens if there is a failure at some point? Is it possible to continue the transaction from some checkpoint, or will I have to start over?

<civodul>arf, too late

<TaylanUB>What was the answer ? I'll need to know it in the future. :P

<civodul>the answer was "yes"

<civodul>:-)

<civodul>rather "no"

<civodul>ok

<civodul>the transaction is canceled, but you don't have to start over again

<civodul>that is, things that had been built/downloaded are still there

<civodul>so "foo" is not installed, but next time you run "guix package -i foo" you just have to build/download what hadn't already been built/downloaded

<TaylanUB>Well that's sensible. Thanks.

<civodul>you're welcome :-)

<klrr_>hey, is there any real difference between nix and guix besides using different langauges (guix uses scheme and nix uses its own DSL)?

<klrr_>nice logo btw :)

<jxself>Guix is better 'cause it's GNU.

<jxself>That automatically makes it better even if were identical. ;)

<klrr_>so, it's simply a re-implementation for the sake of being written by GNU? why not fork then?

<jxself>Nah, I'm just talking. civodul is the better person to talk of it.

<klrr_>also: how is the distribution going? i remember there waas a little qemu image back when this started

<klrr_>aa okey

<klrr_>out of curiosity, davexunit are uyou the author of guile-2d?

<mark_weaver>klrr_: yes, davexunit is the author of guile-2d

<klrr_>oo cool, saw it some time back, the scene abstraction seems intersting

<davexunit>klrr_: hey, yeah as mark_weaver said, I am that guy. the scene abstraction is neat but needs some serious work.

<klrr_>davexunit: someday i would like to do something similar but in haskell, but currently i got two projects i gotta finish

<davexunit>I want to take a thing or two from haskell's game libraries if I can.

<klrr_>what is that?

<davexunit>klrr_: less imperative, more functional

<klrr_>okey, not anything in particular?

<davexunit>still figuring it out.

<klrr_>okey

<civodul>klrr_: the technical differences and motivations are descirbed in http://arxiv.org/abs/1305.4584

<civodul>and in README (shorter ;-))

<klrr_>thanks!

<klrr_>what Shell will Guix distribution use (just wonder since "and promotes Scheme as

<klrr_>a replacement for Bash in build scripts."

<klrr_>)

<mark_weaver>klrr_: I don't understand your question. Can you be more precise? Guix will support whatever free shells are packaged for it.

<klrr_>mark_weaver: the 'Guix distribution' , that is the bootable OS that was released as a demo early on iirc, will it use Scheme repl as a shell , just thought there was a chance of that since you promote build scripts to be in scheme. it might be just me who missunderstood the linked paper above, ive heard people use scheme repl as shell so i personally did not find question too bizzare (although i know many probably think, using something else than bourne shell? :P

<mark_weaver>each user of Guix can use whichever shell they like, just like they can decide whether to use emacs or vim or something else :)

<mark_weaver>but fwiw, I have no immediate plans to move away from bash for my ordinary commands, and as far as I know civodul uses bash also.

<mark_weaver>a guile-based shell sounds like a nice idea in principle, but so far it hasn't been realized afaik.

<mark_weaver>however, I think it's safe to say that most (all?) of us here to do _not_ advocate the use of the shell for writing programs, including build scripts.

<civodul>klrr_: yeah internally the distro may use different tools (package manager, init system, etc.), but the rest is meant to be familiar to GNU/Linux users

<jmd>Where are the list of licenses? and how can I add a new one?

<klrr_>nodnod

<klrr_>make sense

<davexunit>jmd: http://git.savannah.gnu.org/cgit/guix.git/tree/guix/licenses.scm

<jmd>It should be possible to use the license list to detect license conflicts. Has anyone thought of that?

*civodul found a "fix" for mit-krb5, muahaha

<a_e>civodul: What about mit-krb5?

<civodul>a_e: i just pushed the "fix" :-)

<civodul>one of the tests would enter an infinite loop, since we switched to GCC 4.8

<a_e>What a fix. You can be proud of yourself...

<civodul>yup :-P

<jmd>Have you alerted upstream?