IRC channel logs
2016-07-29.log
back to list of logs
<sapientech>lfam got setenv working nicely, however the build isn't seeing this variable. i am thinking i may have set the value wrong <sapientech>okay cool figured it out, just need to grab them from inputs :) <davexunit>sapientech: a build should *NEVER* reference a user profile <davexunit>builds are performed in an isolated environment. <sapientech>davexunit: yeah i figured that out pretty fast after, i thought that maybe $HOME/.guix-profile... was some kind of abstraction, but realized how to reference the inputs when changing env <ng0>I worked on the gnupg,libgcrypt and libgpg-error last night. what's the easiest way now to make the commits compatible to core-updates-next? rebase on core-updates, next rebase on -next? <civodul>ng0: don't bother, i think they'll apply on any of the active branches <ng0>should i just sent the patches again then? <civodul>we'll take care of it when core-updates is merged, which should be Real Soon Now <ng0>but gnupg needed a change. i applied that <ng0>okay, I've just sent the new gnupg patch <fps>hmm, is it normal that this just sits here for over an hour? <fps>fps@guix ~/guix-0.10$ ./pre-inst-env guix build gfortran <fps>The following derivation will be built: <fps> /gnu/store/vwbalbxydqc6k3a6diypxh0krpayp63f-gfortran-5.3.0.drv <civodul>fps: an hour without a single message? definitely a bug <fps>civodul: ok. i'll see if it's stil there in HEAD <fps>seems to depend on the package choice gfortran in guix-0.10.. <civodul>it would be awesome if you could gather more details as to what's hanging where <fps>trying verbosity options of guix build <civodul>for instance, stracing 'guix' or 'guix-daemon' <fps>seems pre-inst-env doesn't let me have strace ;) <fps>fps@guix ~/guix-0.10$ ./pre-inst-env guix strace build --verbosity=3 gfortran <fps>guix: strace: command not found <fps>ah, no, i;m stupid :) <civodul>rather: ./pre-inst-env strace guix build gfortran <fps>somethign else is fishy on my box.. <fps>guix-daemon eating 50% cpu on 4 cores.. hmm hmm <fps>i'll stop these and try to attach to guix-daemon <fps>cpu load goes away if i stop them.. <fps>hmmm readString(Source &). I wonder what a Source is <fps>hmm, probably just waiting on an fd it seems <fps>[those bts were from when i redid the build gfortran] <fps>somethign something about assembling an error message. weird :) <fps>how to reproduce (maybe): get an 8 core vm with 14G RAM and do this in 6 tmux terminals: for n in `./pre-inst-env guix package -A | cut -f1 | sort -R`; do echo ::::::::::::::::; echo "$n"; echo :::::::::::::; ./pre-inst-env guix build --fallback "$n" || true; done <fps>let it run for 4 days ;) <civodul>fps: ok, so something's going on in the substitute process itself <civodul>could you find the 'guix substitute' process (a child of guix-daemon) and "strace -p PID"? <fps>root 12342 0.0 0.2 161076 35376 ? Sl 12:05 0:00 /gnu/store/hyk2i7b8mwbrbiyqk5sgrfgds9zvcrn5-guile-2.0.11/bin/guile --no-auto-compile /gnu/store/04q37mcyxybzbc46j9c6pa3g8553sbgz-guix-0.10.0-0.97c8/bin/.guix-real substitute --query <fps>civodul: oh, can i attach to them with strace? <civodul>yes, "strace -p PID" as i wrote above <fps>oh, missed that.. on it <civodul>you might want to check 'netstat' too, because it's mostly likely a connection issue <fps>two.. (as there are two guix build gfortran running) <fps>dunno what to look for with netstat <fps>that sounds promising ;) <civodul>what does "/var/guix/substitute/cache/s3o7shxygzvof4rs6c3ed5hfifavpy43khzg5fyjdmrnlfk3b7va/xbynzpzqmlayr9v0lp0nccxys5in64zc" contain? <civodul>does "guix build gfortran --no-grafts -n" exhibit the same problem? <fps>fps@guix ~/guix-0.10$ ./pre-inst-env guix build gfortran --no-grafts -n <fps>The following derivation would be built: <fps> /gnu/store/vwbalbxydqc6k3a6diypxh0krpayp63f-gfortran-5.3.0.drv <fps>fps@guix ~/guix-0.10$ <fps>--dry-run doesn't seem to anyways: <fps>fps@guix ~/guix-0.10$ ./pre-inst-env guix build gfortran -n <fps>The following derivation would be built: <fps> /gnu/store/vwbalbxydqc6k3a6diypxh0krpayp63f-gfortran-5.3.0.drv <fps>fps@guix ~/guix-0.10$ <fps>this hangs like without --no-grafts: fps@guix ~/guix-0.10$ ./pre-inst-env guix build gfortran --no-grafts <fps>sadly i gotta go run some errands now. bbiab.. <civodul>at worst i suppose "rm -rf /var/guix/substitute/cache" solves the thing, but i'm not sure what's going on <jlicht>anyone now of any graph querying tools? <jlicht>bonus points if it can be used with guile :-) <jlicht>bavier: in this case, dependency graphs <bavier>but there's aren't many algorithms built around it, yet <jlicht>it actually seems nice and easy to grok, although the lack of a higher-level abstraction for querying might be a problem <civodul>jlicht: what kind of queries/algorithms do you have in mind? <jlicht>civodul: something SPARQL-like would be amazing <jlicht>sneek: later tell civodul: something SPARQL-like would be amazing, althoug for my use-case, I could make it work with simple filters and maps <lfam>I only linked it in case we could glean some insight about how to proceed :) <davexunit>ACTION is in dependency hell on an ubuntu machine <davexunit>messing with apt pinning and priorities to try to tame the beast. the worst. <adfeno>I just faced such thing with Tahoe-LAFS, and was about to ask how I, a non-programmer, help Tahoe-LAFS get ported/packaged to Guix/GuixSD? <davexunit>... and I can't just use guix because I'm trying to write instructions for all of my coworkers to use to switch from mysql to mariadb. <adfeno>I mean, I'm learning Guile, but I don't know how to make build reproducible yet. <bavier>adfeno: build reproducibility is not a hard requirement for Guix packaging <lfam>adfeno: Reproducible builds are very desirable, but we do accept packages that don't build reproducibly. Sometimes, the only way to make something build reproducibly is for the upstream developers to do so some work <lfam>I've never tried building Tahoe-LAFS, but I would start by simply adapting the package definition of `hello` to instead try to build Tahoe-LAFS. <adfeno>I tried visiting reproducible builds site, but I got lost in the beginning of requirements <lfam>Yeah, I wouldn't start with that <ng0>remind me, why did we not merge my --with-gnunet= assoc-ref of gnunet input thing into gnunet-gtk? <ng0>or was this still open, and something else was dropped? i know with gnurl the patch was obsolete <ng0>I will just fix it, the old discussion is too long ago to make any use of it other than the side discussions about description etc which i fixed upstream <adfeno>I'm trying to run GNUNet, but when doing the "-importer.sh" that was installed from Guix (I'm using Trisquel), the process seems to make the terminal busy, and even make it impossible to press Ctrl +D or +C. I was able to send TERM signal to it, but the "making terminal busy"-part was scary. <ng0>yeah it's not perfect neither here nor on gentoo. i spent a while on gentoo efforts and I am now picking up guix gnunet again <ng0>ideally you just use the system service. but people are welcome to fix my openrc script and make it generic enough to put it upstream. gnunet guix service is part of the bigger roadmap i do this for. <adfeno>No worries... I might try resuming my attempt to set-up GNUnet later. <adfeno>Trisquel is using a mix of "init" with systemd. <ng0>also you want to use HEAD instead of 0.10.1 for optimal gnunet-fs experience.. well not head at the moment because of the work towards 0.10.2 which is currently happening, but head at... one moment <adfeno>(actually, it has only one single part of systemd, if I recall correctly). <ng0>37273, which is what i am packaging now <ng0>i masked 0.10.1 and 9999 today for gentoo in our overlay, because this incompability of gnunet-fs leads to so many wrong assumptions. <ng0>what is the "-importer.sh" ? <ng0>i'm fixing a few things in gnunet.scm in the next days. If you want to you can pick my email address from the git logs and send me a bug report, it is not obvious if it is guix or gnunet. for guix you could file the bug report yourself, for gnunet it would require signup at mantis or just directly at the gnunet-devel mailinglist. i can proxy to both. there's no current thread on it on guix-devel list.or just <ng0>post to one of the guix lists with more, i will figure out what to do <ng0>i know certain restrictions apply and that the way we install gnunet is not how it should be run. we have no users for it, the service will fix this. <mark_weaver>it failed to build on both armhf and mips64el, due to another compiler warning turned error that is unrelated to my patch :-( <mark_weaver>and I'm not sure why this warning turned error doesn't happen on the intel architectures. <lfam>Thanks for the link. I was about to start clicking furiously at my web browser <mark_weaver>I just merged into core-updates, and started hydra evaluations on both master and core-updates, only to discover that we'll have to add another patch :-( <lfam>I guess that the libgd developers don't test on anything besides x86_64 <ng0>how do I get @PYTHON@ into PATH for a package which requires it during configure,build,etc with the gnu-build-system? <lfam>I can send them a message detailing our findings <ng0>i could substitute.. <ng0>but there must be something else? <bavier>ng0: won't configure handle that itself? <lfam>ng0: You mean, how do you put the `python` executable itself onto $PATH? <ng0>patch-shebang: ./src/integration-tests/test_integration_disconnect.py.in: warning: no binary for interpreter `@PYTHON@' found in $PATH <lfam>I would grep in gnu/packages for something like 'setenv "PATH"' <ng0>this error is new to me <lfam>You should find some examples of adding things to $PATH <bavier>ng0: that looks like a file that configure will substitute @PYTHON@ with, when it finds a python during configuration <ng0>i do set this in a lter phase.. <ng0>so i already know hot to setenv etc <ng0>okay, i'll look there <adfeno>How do I get the package definition from a specific package, say "hello"? <lfam>adfeno: I'm not much of an Emacs user, so I don't know the full details. But, `guix edit hello` should open the package definition in Emacs, if it is available. Also, you can do `guix package --show=hello`, and it will tell you the name of the file where the package definition is found. <lfam>You will want to clone our Git repo if you want to make changes <adfeno>Indeed... I think I'll try contributing. <lfam>adfeno: That's great news! Please ask for help if you get stuck <mark_weaver>ng0: that warning from patch-shebang should be harmless. that's a file that should have its shebang substituted by ./configure. <ng0>okay, seems like i can not easily figure it out myself. my solution would be to patch it. because this gets fixed, but @PYTHON@ doesn't: patch-shebang: ./src/consensus/consensus-simulation.py: changing `/usr/bin/python' to `/gnu/store/jd5qm8r971dyh4h7dnfc07kmpfifspsb-python-2.7.10/bin/python' <ng0>where patch means substitute <ng0>i added a phase after unpack to add the python "/bin" to path.. nothing <mark_weaver>ng0: look in the output of 'configure' for messages about python <ng0>this is before configure <sapientech>hi all, with large pkgs, like icecat, im getting a "no more diskspace error" I know that i have the space, however <ng0>the problem appears in the patch-shebang-phase <mark_weaver>I'm telling you that ./configure is the thing that should be fixing that up <ng0>oh, the file configure <mark_weaver>ng0: and that the warning from patch-shebang can be safely ignored <lfam>sapientech: The default location for package building is /tmp. Is your /tmp small? <lfam>sapientech: If so, you can set $TMPDIR in the environment where you launch the guix-daemon <ng0>then it fails because of another thing i need to fix, i changed the package definition. <mark_weaver>ng0: ./configure should create test_integration_disconnect.py based on test_integration_disconnect.py.in but with the @PYTHON@ substituted for the right python executable. if it fails to do that, that's another problem. <mark_weaver>sapientech: some distros make /tmp a ramdisk. maybe yours does. <sapientech>lfam, mark_weaver it is indeed a tmpfs, 4G enough for all packages in guix? <lfam>sapientech: Sadly, it's not enough <mark_weaver>sapientech: I suggest that you set TMPDIR=/var/tmp in the environment where guix-daemon is run <lfam>Ah, we are talking about the TMPDIR :) <ng0>8GB. i never had to use more than 8 when building. <lfam>I think 8 GB will be safe <sapientech>lfam: cool guys thanks, mark_weaver whats the idea behind changing TMPDIR? <mark_weaver>sapientech: I've read that using a ramdisk for /tmp is an outdated practice, no longer needed (since many years) for good performance <davexunit>I just use disk for /tmp and avoid using precious RAM for it <ng0>when the holy trinity libreoffice/firefox/chrome figures out a way to use even more resources, it will be 8+ <mark_weaver>sapientech: $TMPDIR is where the builds are performed. <ng0>the trinity of bloat :) <lfam>I've found that, on spinning disks, the guix-daemon can increase my load severely. I put up with it, but if I had 8 GB of free RAM I would try to use it <lfam>We should contact the EOMA68 developer to let him know that GuixSD doesn't yet run on ARM. I don't want his time to be wasted <bavier>lfam: thanks, I was thinking the same thing <bavier>I'm invested, but there's still more work to be done on our end <bavier>but still, starting a conversation with Luke is nice <lfam>Yeah, I think it's a great project and it would be awesome for GuixSD to run on it. But their resources are limited and they need to focus on what works now <lfam>I'm guessing that user lkcl on #arm-netbook is Luke <bavier>lfam: I think so, that's Luke reddit handle too <mark_weaver>ACTION pushed 'wip-gd-fix' branch, and asked hydra to build it, to see if that fixes the builds on all arches <lfam>bavier: I sent lkcl a message on #arm-netbook. If he doesn't acknowledge it in a little while, I <lfam>I'll send it to their ML <mark_weaver>I pushed the test patch to master instead of wip-gd-fix. and now I'm having trouble connecting to savannah's ssh port to revert it. <lfam>mark_weaver: I can't reach it either <mark_weaver>lfam: I have to go afk for a while. can you revert my "gnu: gd: Add fix for gd2_read test" commit ce290354ec4e97003be5f56042e55b36831818c1 asap? <lfam>mark_weaver: Yes, as soon as I can connect <mark_weaver>just tried to push 'wip-gd-fix', and got this: remote: fatal: bad object 0000000000000000000000000000000000000000" :-( <lfam>Huh... I wonder if that's related to the new Git hook intended to require signed commits <lfam>sneek: later tell civodul: Do you think that this error message when pushing a new branch to Savannah is related to the new signed-commit hook? "remote: fatal: bad object 0000000000000000000000000000000000000000". Mark got that message a few minutes ago, after some brief downtime <lfam>sneek: Your botsnack was delicious. I promise to give you one tomorrow <ng0>hm... bootstrap script executes autoreconf and others. Now this gives me Can't exec "autopoint": No such file or directory at /gnu/store/51s6w6jw83rmdfyqhwmxrvv5qbzypz9b-autoconf-2.69/share/autoconf/Autom4te/FileUtils.pm line 345. but autoconf is in the native-inputs <bavier>ng0: autopoint is from gettext I think <ng0>then i should add it back <ng0>i commented it because of this: guix build: error: gnu/packages/gnunet.scm:342:4: package `gnunet-svn-0.10.1-1.svn37273' has an invalid input: ("gettext" #<procedure gettext (_ #:optional _ _)>) <ng0>i should sort my checkouts.. i'm sure i already solved this in the last months <bavier>ng0: the gettext package variable is named "gnu-gettext" to differentiate it from the "gettext" procedure <bavier>np, I've hit the same enough times before <ng0>i'm sure i solved this earlier already <Sleep_Walker>*** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.19 but the autoconf macros are from gettext version 0.18 <sapientech>darn, the log got cleared, but i had a "BFF/heap" error when installing emacs... <mark_weaver>sapientech: what log got cleared? can you paste the entire error somewhere? <sapientech>mark_weaver: yeah i'll have to recompile it till it gets the error which will be ~1hr <sapientech>it also said exec-shield may be at fault, but i don't have it enabled... <mark_weaver>sapientech: builds logs are in /var/guix/drvs. try: ls -ltr /var/guix/drvs/*/* | tail