IRC channel logs

<jxself>steap: What? Since when is Firefox free? Did Mozilla change their position to allow all four freedoms in full? http://jxself.org/mozilla_trademark.shtml

<Steap>jxself: s/Firefox/IceWeasel

<viric>Steap: dom quichot :)

<viric>(this one)

<jmd>Where is the root where packages are built ?

<mark_weaver>a directory is made in /nix/store/*.chroot

<mark_weaver>the build directory in /tmp/ is bind-mounted there, along with the inputs

<mark_weaver>the bind mounts are private to the namespace, so might not be visible from other processes.

<mark_weaver>(I've never really learned the details of namespaces in linux)

<jmd>And that /nix/store/* should persist after failure if I gave the -K flag ?

<mark_weaver>no

<jmd>Bummer!

<mark_weaver>only the build directory in /tmp is preserved.

<jmd>next question: Which is the current directory during builds?

<mark_weaver>normally it is the toplevel directory of the unpacked tarball, which is also the build directory.

<mark_weaver>i.e. the directory that contains 'configure' for packages that use the GNU build system.

<jmd>Thats the /tmp directory isn't it?

<mark_weaver>yes, but from within the chroot the pathname is different of course

<jmd>of course.

<jmd>What am I doing wrong here:

<jmd> (let ((out (assoc-ref outputs "out")))

<jmd> (zero? (system

<jmd> (string-append

<jmd> ;; The normal `--host=' option isn't recognised either.

<jmd> ;; Instead, it relies upon a CHOST variable.

<jmd> ,@(if (%current-target-system)

<jmd> (string-append "CHOST=" (%current-target-system) " ")

<jmd> "")

<jmd> "./configure --prefix=" out)))))

<jmd>

<civodul>howdy!

<jmd>Ho

<mark_weaver>jmd: it looks to me like the ",@(" should be just ",("

<mark_weaver>when you use ",@", the resulting expression should evaluate to a list, and that list is spliced into the place where ,@ is found.

<mark_weaver>s/resulting/following/

<jmd>ok.

<mark_weaver>so you need to use "," instead, in which case the following expression evaluates to any datum that is then put in place of the ",<expr>"

*civodul adds (gnu system)

<jmd>But its evaluated at a later phase isn't it?

<mark_weaver>expressions following , or ,@ are evaluated when the containing `(...) expression is evaluated.

<civodul>i'm planning for a release on Wed. morning

<mark_weaver>sounds good

<jmd>I don't understand then why (%current-target-system) evaluates to #f when not in ,@

<civodul>jmd: (%current-target-system) is #f unless we're cross-compiling

<civodul>conversely, (%current-system) is never #f

<jmd>I'm cross-compiling, but it is still #f

<jmd>unless I put it in ,@

<civodul>when cross-compiling, Guix starts by evaluating _native_ package definitions

<civodul>so it's normal that you get (%current-target-system) = #f for those

<civodul>are you sure you want to cross-compile?

<jmd>Yes. I am sure.

<civodul>what target triplet?

<civodul>mips64el-linux-gnu is our favorite :-)

<jmd>Yes that is what I am testing with.

<civodul>ah, good

<civodul>so what are you cross-compiling?

<jmd>zlib

<civodul>ok

<jmd>I don't understand why in (string-append "CHOST=" (list ,@(%current-target-system)) " ")

<jmd>

<jmd>it is evaluated as expected, but without the ,@ it evaluates to #f

<civodul>could you paste the whole thing, so i can see the context?

<civodul>ouch "make assert-binaries-available" currently fails

<civodul>grrr

<jmd> http://pastebin.ca/2495222

<civodul>(note that zlib must not be changed in 'master')

<jmd>How so?

<civodul>what are you trying to achieve?

<jmd>I want to cross compile zlib

<civodul>so just type: guix build --target=mips64el-linux-gnu zlib -n

<civodul>though apparently something doesn't cross-build currently

<jmd>That will not work.

<civodul>but the thing is: recipes do not need to be changed

<civodul>how will it not work?

<jmd>Because zlib needs to be configured with CHOST=xxxx ./configure

<jmd>It doesn't work the normal way.

<jmd>zlib's configure is home grown; not from autoconf and works quite different.

<civodul>oh?

<civodul>but i think it used to work fine, hmm

*civodul restarts hydra

<jmd>I cannot imagine how.

<jmd>Perhaps you only thought it did. If you do pass zlibs configure a --host= then it gets ignored.

<jmd>So you will end up with a successfull native build.

<jmd>guix probably won't know the difference.

<jmd>until you try to use it as the input to something else.

<jmd>... which is how I found out.

<civodul>hmm, ok

<civodul>well at least we can cross-build "bootstrap-tarballs", which includes gcc, binutils, etc.

<civodul>see http://hydra.gnu.org/job/gnu/master/mips64el-linux-gnuabi64.bootstrap-tarballs-0.x86_64-linux

<jmd>They don't depend on zlib do they?

<civodul>i thought gcc did

<civodul>yeah, normally it does

<civodul>could you post the initial build log (failing)?

<jmd>Of course, if a zlib targetted at mips has already been built natively, then it'll get picked up by the substiturer and used.

<jmd>How do I clear a derivation from the store?

<a_e>guix gc -d /nix/store/...

<a_e>By the way, we got past the 600 package barrier!

<civodul>yay!

<civodul>e-Champagne everyone!

<civodul>a_e has been adding all of CPAN so we reach that barrier ;-)

<a_e>Yes, it was my secret ambition to be the one adding the 600th package ;-)

<civodul>:-)

<a_e>Adding CPAN has a zen like quality. After a while, one gets the hang of it.

<a_e>It is quite well organised.

<jmd>civodul: http://pastebin.ca/2495230

<jmd>Note all the warnings in the strip phase.

<jmd>Although the build succeeds, it builds the wrong thing.

<jmd>That's when I was trying to fix the recipie

<jmd>s/when/why

<civodul>these warnings don't matter

<civodul>so it succeeds?

<civodul>what's wrong exactly?

<civodul>what does file .../libz.so report?

<jmd>See the end of my post.

<jmd>ohn@jocasta:/Scratch/john/guix$ file /nix/store/6f4f9aj6l4kg6x377xlk03zd4smy7hsf-zlib-1.2.7/lib/libz.so.1.2.7

<jmd>/nix/store/6f4f9aj6l4kg6x377xlk03zd4smy7hsf-zlib-1.2.7/lib/libz.so.1.2.7: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

<civodul>aah, ok

<civodul>blech

<civodul>and so setting $CHOST is the thing?

<jmd>That works for me when I compile zlib manually.

<jmd>But it must be "CHOST=triplet ./compile"

<civodul>ok

<jmd>"CHOST=triplet ./configure"

<civodul>so back to your original paste...

<civodul>keep using 'system*' instead of using 'system'

<jmd>"./configure CHOST=triplet" wont work.

<civodul>and just add a line before it, like this:

<civodul>,@(if (%current-target-system) `((setenv "CHOST" ,(%current-target-system))) '())

<civodul>this is convoluted, just so we don't need to rebuild anything in 'master'

<jmd>Sorry. Where should that fragment go? before (system* or before (zero?

<jmd>Or perhaps it needs a (begin ...) ?

<a_e>civodul: Concerning 0.5, gdb, glib and libtasn1 need an upgrade. Are these okay?

<a_e>And binutils.

<a_e>Looking at hydra, I am actually not sure the bison update was a good idea.

<a_e>But maybe it is just hydra that posed problems.

<civodul>a_e: binutils is not OK (→ core-updates), but the others are

<civodul>it's better to delay GLib too

<civodul>the Bison update should be OK by tomorrow evening

<mark_weaver>jmd: that fragment goes before (zero? ...)

<civodul>hopefully

<a_e>How about delaying 0.5 then? Should we not ship all of the hottest new gnu?

<a_e>Quite a few packages failed after the bison update, but I think it is more a reflection of problems with hydra.

<a_e>Once the builds catch up, I will restart some of the failed ones.

<civodul>how did they fail?

<civodul>i think we should not delay 0.5 further

<a_e>Some of them with failed checks. Which is suspicious.

<a_e>Some are "aborted; hydra failure".

<a_e>We will have to see once hydra has caught up.

<civodul>hmm

<civodul>could you check those that have already failed?

<civodul>to see if it's serious or not

<jmd>civodul: That fragment seems to fix the problem.

<jmd>You want me to post a patch, or will you fix it?

<civodul>jmd: yes, please post it

<jmd>ok. It'll have to wait till tommorow. I'm going to bed now.

<civodul>make sure to follow our style for the ChangeLog entry, formatting, etc.

<civodul>ok!

IRC channel logs

2013-12-09.log