IRC channel logs


back to list of logs

<jxself>steap: What? Since when is Firefox free? Did Mozilla change their position to allow all four freedoms in full?
<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>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)))))
<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>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>I don't understand why in (string-append "CHOST=" (list ,@(%current-target-system)) " ")
<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>(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>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.
<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>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 ;-)
<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>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
<civodul>these warnings don't matter
<civodul>so it succeeds?
<civodul>what's wrong exactly?
<civodul>what does file .../ report?
<jmd>See the end of my post.
<jmd>ohn@jocasta:/Scratch/john/guix$ file /nix/store/6f4f9aj6l4kg6x377xlk03zd4smy7hsf-zlib-1.2.7/lib/
<jmd>/nix/store/6f4f9aj6l4kg6x377xlk03zd4smy7hsf-zlib-1.2.7/lib/ ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
<civodul>aah, ok
<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"
<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? ...)
<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>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.