IRC channel logs
2013-11-12.log
back to list of logs
<zacts>ok, I want to work on guix again. I really have had to pick and choose projects to work on while in college. *gzg needs to continue packaging and submitting some of his stuff, to the mailing-list, soon. <gzg>He's edging back to that mental-state, where that feels do-able again... <gzg>zacts: My case is for/in-regards to different things, but yeah -- adapting to school and the greater/better need for time-management can be rough. <zacts>was the port to MIPS a massive undertaking? <gzg>zacts: Not the one to ask and I forgot who was working on it, but it seemed to of got done in a little under a months time (judging by me lurking here and there), if that's at-all telling. <zacts>that sounds promising in terms of having the ability to port guix to other platforms in the future <zacts>I've been waiting for a distro that can be completely self hosting and can build itself entirely from source, or binaries at any time. similar to the BSDs. <zacts>guix seems promising in this regard <zacts>and as a great package management system <gzg>zacts: I mean there was an incomplete there prior, but I'm not sure how much, or any of it was used to make current. <zacts>in fact it seems even more powerful and flexible than what the BSDs offer <zacts>I really like guix so far, you can expect to see my contributions over the next 6months - 1 year <zacts>I'm starting by learning (scheme) <mark_weaver>even though it's mostly pointless until GCC 4.8 is made the default compiler, I have the 3A bootstrapping core-updates with the new bootstrap tarballs. It built GCC 4.7.3 in 7.5 hours, compared with 20.3 hours on the 2F machine. <civodul>mark_weaver: re bootstrapping core-updates, good news <civodul>i have a stash with a tool to help do the re-bootstrap <civodul>i wanted to finish that before pushing the new bootstrap tarballs <civodul>the idea is you would type "guix build --rebootstrap foo", and that builds foo with the new bootstrap tarballs <civodul>as if you had modified bootstrap.scm <mark_weaver>I'd think that the GCC 4.8 update should be done at the same time as we switch to the new bootstrap tarballs, since each one will require a full rebuild. <mark_weaver>did you see my messages yesterday about the problem I ran into switching core-updates back to GCC 4.8? <civodul>it's actually a bug fix compared to 4.7 <civodul>so the snippet about MPFR in base.scm needs to be removed <civodul>i'll actually remove it when i build with the new bootstrap tarballs <mark_weaver>I'd like to start re-bootstrapping core-updates on MIPS as soon as reasonably possible. <mark_weaver>(since it takes rather longer to accomplish than on intel) <mark_weaver>now that I see what needs to be done, I could do it myself if you like. <civodul>i can send you the stash i have for MPFR if you want? <civodul>the thing is we need to make sure we push when it actually builds ;-) <civodul>and then we can do --system=i686-linux on an x86_64 box <mark_weaver>I don't have the hashes for the intel bootstrap tarballs though. <mark_weaver>are the i686 bootstrap tarballs cross-built, or natively built? <civodul>mark_weaver: natively, but possibly on an x86_64 machine with 32-bit personality <mark_weaver>that's fine. I just wanted to make sure they won't have the same problems I had using cross-built mips tarballs. <mark_weaver>civodul: can you put the new bootstrap tarballs on alpha.gnu.org? I won't be able to test x86_64 properly without them. <civodul>arf, not right now, but tonight is OK <civodul>perhaps you can modify bootstrap.scm to use local copies in the meantime? <mark_weaver>well, I have bootstrap tarballs that I built, but they won't be the same as yours, which will mean another wasted bootstrap. <mark_weaver>well, if it weren't for you, we wouldn't even have the bottle :) <zacts>what is planned for 0.5 release? <zacts>oh nvmnd. I can just look at git log I guess <mark_weaver>'core-updates' is the relevant branch. it will become 0.5 <civodul>gzg: how's your slim package BTW? :-) <jmd>Where is the chroot jail where packages are built? <mark_weaver>that chroot contains bind mounts of other needed /nix/store/* directories, as well as /tmp/nix-build-* which contains the actual build directory. <mark_weaver>it's all done within a private namespace, so actually I think those bind mounts aren't even visible outside of the private namespace. <jmd>I cant see any directory matching /nix/store/*chroot <mark_weaver>the relevant code is in guix/nix/libstore/build.cc. See DerivationGoal::startBuilder. <mark_weaver>the chroot only exists while a package is being built <mark_weaver>I'm currently building coreutils, and I see /nix/store/*-coreutils-8.21.drv.chroot <jmd>But I passed the -K option. That should preserv it should it not? <mark_weaver>it preserves the build directory, but not the chroot. <jmd>Hmm. Is there a way of achieving that? <mark_weaver>the mount points in the chroot are private to the namespace doing the build, so it would not be entirely trivial. I'm sorry, but how to do this is beyond my current knowledge. <jmd>How do people normally go about debugging build build problems then? <mark_weaver>fwiw, I agree that it would be good to provide tools to make debugging of builds easier. I'm just not sure how best to go about it. <jmd>I'm in the middle of a build right now. And I see that the chroot has no /bin <jmd>where are the utilities kept? <mark_weaver>anything that the build needs has to be listed as an input, which will be in /nix/store/*, and then you need to arrange so that the build uses only those things. <mark_weaver>(though there are some inputs included by default in all builds, without special reference) <mark_weaver>the standard build process sets several environment variables such as PATH, CPATH, LIBRARY_PATH, etc, which handles most cases. <mark_weaver>and there are also build passes included by default that go around looking for shebangs that need to be patched (e.g. #!/bin/sh -> #!/nix/store/*/bin/sh <mark_weaver>a proper GNU build system should just work, but in practice many build systems don't handle this robustly, so sometimes things have to get fixed up in other ways. <jmd>Where is the list of inputs. <mark_weaver>please read that document, and then we can talk more. <mark_weaver>the list of _implicit_ inputs for packages using the 'gnu-build-system' is in '%final-inputs', at the end of gnu/packages/base.scm <mark_weaver>(tar, gzip, bzip2, xz, diffutils, patch, coreutils, sed, grep, findutils, gawk, make, bash, ld-wrapper, binutils, gcc, libc) <mark_weaver>anything else needs to be listed explicitly in your package definition. <jmd>My chroot is missing the /etc/fonts directory. This surprises me, because both fontconfig and gs-fonts are inputs. <mark_weaver>all inputs are in /nix/store. there's nothing outside of that, (except /proc /sys /dev /tmp) <mark_weaver>I don't know the details of how fonts are searched, but you need to have it look in /nix/store/*/share/fonts. <mark_weaver>please understand that the special features that guix provides (e.g. robustness, rollbacks, multiple versions of the same package that don't interfere), require that packages refer directly to their dependencies in /nix/store/*. <mark_weaver>if they use anything in the standard places, then they are no longer built on top of an immutable base, but rather on something that might get upgraded later and thus broken. <mark_weaver>when you actually use these things as a user, the fonts will be in ~/.guix-profile/share/fonts/, with all font packages merged together there. <mark_weaver>and presumably some environment variable will point to that. <mark_weaver>but during package builds, you don't have anything like that. instead, environment variables are set to search in the relevant inputs. <mark_weaver>for example, whereas as a user, you have a merged ~/.guix-profile/bin, during a build you have nothing like that. instead PATH is set to contain /nix/store/*/bin for all the relevant inputs. ditto for CPATH, LIBRARY_PATH, and PKG_CONFIG_PATH too I think. <jmd>Then I suspect the FONTCONFIG_FILE environment variable has not been set when it ought to have been. <jmd>Where should it be set? <mark_weaver>jmd: a_e knows more about guix packaging than I do, maybe he can help. <mark_weaver>however, I suspect that 'native-search-paths' might be what you're looking for. (e.g. search for 'native-search-paths' in gnu/packages/gcc.scm) <mark_weaver>a_e: jmd is having a problem with a build recipe where something during the build needs access to fonts, and it can't find them. it's looking in places like /etc for fonts, which of course won't work. <jmd>(Well that is my current hypothesis) <mark_weaver>jmd: you mentioned FONTCONFIG_FILE, but is there anything like a PATH-type variable, such that it could accept multiple directories separated by colons? <a_e>Well, I know, it is the recips for pspp ;-) <jmd>Apparently there is FONTCONFIG_PATH but I don't know how it should be used :( <mark_weaver>my guess is that you want to add a 'native-search-paths' field to your package, to set FONTCONFIG_PATH appropriately. <a_e>In the case of fontconfig, there is /nix/store/...-fontconfig-2.10.93/etc/fonts/fonts.conf . <a_e><dir>~/.guix-profile/share/fonts</dir> <a_e>(which refers to fonts installed in the user profile) <a_e><dir>/nix/store/af3rhphh0jn1482mfpi6650ffbgsy2r8-gs-fonts-8.11/share/fonts</dir> <a_e>(so that anything using fontconfig should find the gsfonts). <mark_weaver>maybe FONTCONFIG_FILE should just be set to /nix/store/*-gs-fonts-8.11/share/fonts <mark_weaver>sorry, I meant to write: maybe FONTCONFIG_FILE should just be set to /nix/store/*-fontconfig-*/etc/fonts/fonts.conf <a_e>At least in the user profile, fontconfig seems to work without setting FONTCONFIG_FILE. <jmd>How can I set FC_DEBUG during the pspp build ? <a_e>(setenv "FC_DEBUG" "value") <a_e>by adding a phase before build. <a_e>Inside the package definition of pspp in maths.scm. I am looking for an example. <a_e>pulseaudio in pulseaudio.scm is a good example. <a_e>You need to add something like <a_e>#:phases (alist-cons-before 'build 'envvar (lambda _ (setenv "FC_DEBUG" "value")) %standard-phases) <a_e>inside the (arguments `( list <a_e>The name 'envvar is arbitrary. <a_e>The command replaces the #:phases argument by a copy of %standard-phases, in which the new phase 'envvar (given by the lambda function; _ means it ignores all potential arguments) is added before the 'build. <jmd>That Scheme fragment should be backquoted? <a_e>The back-quote should be before the parenthesis following (argument, which starts a literal list. <a_e>You can more or less copy-paste from pulseaudio. <jmd>That's what I thought. <jmd>Something wierd is happening now: <jmd>guix build: error: pspp: unknown package <a_e>My impression is that fontconfig automatically looks for fonts.conf in its installation path. <a_e>When I do "fc-list", the output starts with <a_e>Fontconfig warning: "/nix/store/b0wvgh01y0fn7z3s7jxr53q8nqkd5hbp-fontconfig-2.10.93/etc/fonts/conf.d/50-user.conf", line 14: reading configurations from ~/.fonts.conf is deprecated. <a_e>jmd: Did you do one of "make install; guix build ..." or "./pre-inst-env guix build ..."? <jmd> ./pre-inst-env guix build pspp -K <a_e>Or did "make" print an error? If the package is not compiled correctly, it is not find. <a_e>Just "touch" the file and try another "make". <jmd>Oh I forgot to make. <a_e>Away from keyboards for a while; good luck! <jmd>That line seems to break things... <jmd>gnu/packages/maths.scm:111:2: source expression failed to match any pattern in form (package (name "pspp") ... *civodul is uploading the x86_64 bootstrap tarballs <civodul>mark_weaver: x86_64 bootstrap binaries available at alpha.gnu.org! <viric>civodul: filegive can work with ngrok too <viric>without signing in, for http tunnels. With free sign in, you get raw tcp tunnels. <a_e>jmd: I just mailed you a file that compiles. <jmd>I'll look at it tomorrow. I must go to bed soon. <a_e>Very well! If you wish to set FONTCONFIG_FILE, that should go in a separate line. Just to try it out, you make use an absolute path. If this solves the problem, we can automatically have it filled in depending on the input fontconfig. <jmd>Based on some experiments I've been doing in the last hour, I think we may have been following a red herring. But I'll investigate further tomorrow using your patched file. <a_e>I am eating my own dog food. It is difficult to get used to! <a_e>GNU LibreJS makes lots of web sites unusable in icecat. <a_e>I just discovered you can add a whitelist of sites where you wish to enable potentially non-free javascript. <a_e>It blocks javascript it considers non-free. How this is determined, I did not investigate. <civodul>a_e: i think it uses license headers in the js files <civodul>which are missing most of the time :-/ <civodul>mark_weaver: so hopefully this'll build fine, with the MPFR patch <mark_weaver>I tried bootstrap again on MIPS, but gcc-cross-boot0 still fails. <a_e>My substitute-binary also dies unexpectedly and randomly. <mark_weaver>in the gcc subdir, I see very close together, a command to build 'build/genhooks', and another command that tries to run it a few lines later. <mark_weaver>the line that tries to run it gives an error, that build/genhooks doesn't exist. <mark_weaver>but 'build/genhooks' *does* exist in the failed build directory. <civodul>a_e: Guile 2.0.5? could be the n-par-map patch that does this :-/ <a_e>civodul: Yes, 2.0.5. <civodul>ok; i fear a silly old bug in that area <Steap>a_e: Browsing the Web without Javascript is quite impossible these days :/ <a_e>Steap: With only free javascript, it also does not work. <a_e>For instance, zimbra (which I think is free) does not work with LibreJS. <Steap>I think non-free JS is "less bad" <Steap>because JS can't access stuff on your drive etc. <Steap>still, it sucks that your computer sort of executes non-free code <civodul>mark_weaver: that's with the 4.8.2 bootstrap tarball? <mark_weaver>civodul: oh, hmm. i guess it's not a parallel build problem. even though the file is there, when I try to run it, it gives the same error. <mark_weaver>this is bootstrapping from the 4.8.2 bootstrap tarball, and with core-updates moved back to 4.8. <civodul>mark_weaver: by same error, you mean "build/genhooks: No such file or directory"? <civodul>presumably that means the ld-linux.so link is wrong <mark_weaver>I should mention that I modified your patch snippet a bit. I didn't keep the (substitute* "gcc/system.h" (("<cstring>") "<string.h>")) <civodul>mark_weaver: so, there's a problem for you to solve :-) <civodul>basically, the LIB_SPEC isn't patch as we want <civodul>so if you look at "gcc -dumpspecs" for 4.8 in master, you'll see it lacks the -rpath thing <civodul>that's because the patching in gcc.scm no longer works <civodul>for instance, instead of "^linux(64|-elf)?\\\\.h$", we need to look for gnu-user{,64}.h IIRC <jmd`>a_e: Yes. I am now suspecting the papersize rather than the fontsize. I'll investigate further tomorrow. Thanks for your help. <Steap>a_e: I think you wanted to answer to the list <Steap>I'll take a look at your issue <Steap>I'm pretty sure a Python script is trying to compile some stuff <a_e>Steap: Yes, I did. I have forwarded it. <a_e>And I pushed icecat into master. <Steap>maybe we should patch subprocess <a_e>If you find a solution, you can push it then. <Steap>Because I've had to do such things in other packages <a_e>But subprocess is part of python itself, no? What is there to patch? <Steap>Well, I think it can find some pieces of software because it needs to use /nix/store/... <Steap>I'd have to take a look at the patches I've written for other packages <a_e>There is a new python version 2.7.6. Maybe we should switch to it. <Steap>yeah, would not fix the issue, though :/ <Steap>Hopefully in a few years we'll just have Python 3.x <a_e>hydra.gnu.org does not work in icecat, even after allowing all non-free javascript! *jxself notes that the JavaScript is free <Steap>isn't icecat just Firefox rebranded ? <Steap>and with all the non-free stuff removed <jxself>Just not marked as such. Non-free JavaScript != free JavaScript missing the proper identifiers <a_e>jxself: Okay, agreed. <a_e>Qt 4.8.5 currently triggers an internal compiler error on hydra. It compiled without problem on my machine! <mark_weaver>civodul: the substitute* rules look right to me, but they don't seem to be doing anything at all. *jxself opens Internet Explorer to visit hyrda.gnu.org ;) <civodul>mark_weaver: exactly, that's the problem <viric>a_e: can be a lack of ram. oomk <mark_weaver>for mips, the relevant file for GLIBC_DYNAMIC_LINKER is in /tmp/nix-build-gcc-cross-boot0-4.8.2.drv-0/gcc-4.8.2/gcc/config/mips/linux64.h <mark_weaver>and the substitute* command that's already there looks like it should work, but it doesn't.. <a_e>viric: I also checked the disk space; this should ne okay. <mark_weaver>hmm, is it looking in the build directory and not in the source dir? <civodul>mark_weaver: so what's the ELF interp of build/genhooks? <mark_weaver>looking at the file directly, I think it's /nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.18/lib/ld.so.1 <viric>readelf -a FILE | grep interp <a_e>a_e: As for RAM, I have 8GB, hydra has 2GB. So maybe. But 2GB is still a lot. Except that hydra also uses much of it. <viric>a_e: most gcc internal errors I found were lack of ram <mark_weaver>civodul: do you think the 'substitute*' might be looking in the build directory instead of the source directory? <mark_weaver>I searched /tmp/nix-build-*/gcc-4.8.2/gcc/config/ for "nix/store", and didn't find anything outside of shebangs. <civodul>mark_weaver: that must be the case, yet it's worked for ages <mark_weaver>and in the build log, it doesn't print anything within the pre-configure phase. <mark_weaver>(it says that it's starting the phase, and that the phase succeeded, but nothing else) <civodul>oh there's a (when libc at the beginning, so it's normal that it doesn't have any effect for gcc-cross-boot0 <civodul>mark_weaver: see the LDFLAGS_FOR_TARGET? i think we need the same, but LDFLAGS, in the (not libc) case <civodul>so we can build things natively like genhooks, yet use the right ld.so <a_e>viric: Memory might be a problem since hydra builds up to four packages in parallel. <mark_weaver>hmm. I think I'd best leave this work to you. I need to start looking at the bug that is causing tupi grief on guile. I promised him a fix by Nov 17 <mark_weaver>civodul: I'll send you the patches I've been working from. <mark_weaver>civodul: I pushed it to savannah, on branch 'wip-loongson-gcc-4.8' <mark_weaver>the reason it has 'loongson' in the name is because I haven't yet updated the hashes for the new x86_64 bootstrap tarballs, and yet I got rid of the pattern matching stuff, so it will currently work only on mips. <mark_weaver>(it always looks in <arch>/20131110/* with the new version numbers) <civodul>mark_weaver: i'm reusing the string-replace-substring you posted on guile-user a while back