IRC channel logs


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>is ~/.guix-profile/include/SDL2/ correct here?
<sapientech>okay cool figured it out, just need to grab them from inputs :)
<davexunit>sapientech: a build should *NEVER* reference a user profile
<davexunit>it won't work, for one thing
<davexunit>but it's also nonreproducible
<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
<civodul>Hello Guix!
<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
<civodul>no, that's fine
<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
<fps>substitute: updating list of substitutes from ''... 100.0%
<fps>substitute: updating list of substitutes from ''... 100.0%
<fps>reproducable, too..
<civodul>fps: an hour without a single message? definitely a bug
<civodul>in case you had a doubt ;-)
<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>i don't see why it would hang
<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'
<civodul>these are not very useful here
<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>it sits there now:
<fps>and here for HEAD:
<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>one sits here:
<fps>and three here:
<fps>and one here:
<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 ;)
<fps>some more strace:
<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>civodul: sure
<fps>one of these?
<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>these look like:
<civodul>fps: and what does strace show?
<fps>civodul: oh, can i attach to them with strace?
<fps>let's ee
<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>one seems to be looping like this:
<fps>two.. (as there are two guix build gfortran running)
<fps>here's the other one..
<fps>dunno what to look for with netstat
<civodul>fps: oh!
<fps>that sounds promising ;)
<civodul>what does "/var/guix/substitute/cache/s3o7shxygzvof4rs6c3ed5hfifavpy43khzg5fyjdmrnlfk3b7va/xbynzpzqmlayr9v0lp0nccxys5in64zc" contain?
<fps>(narinfo (version 2) (cache-uri "") (date 1469788448) (ttl 10800) (value #f))
<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>no :)
<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>hmm ok
<civodul>at worst i suppose "rm -rf /var/guix/substitute/cache" solves the thing, but i'm not sure what's going on
<jlicht>o/ guix
<bavier>hi jlicht
<jlicht>anyone now of any graph querying tools?
<jlicht>bonus points if it can be used with guile :-)
<bavier>jlicht: what kind of graphs?
<bavier>there's (guix graph) ;)
<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?
<civodul>we should really extend this module
<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
<sneek>Got it.
<lfam>Go packaging discussion:
<davexunit>oh boy
<lfam>Easy now ;)
<davexunit>not sure I want to open...
<davexunit>need to focus on work.
<lfam>I only linked it in case we could glean some insight about how to proceed :)
<davexunit>abandon all hope
<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.
<lfam>I'm so sorry
<adfeno>davexunit: Oh...
<adfeno>That's bad...
<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
<adfeno>Oh GNUnet user???
<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 "" 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>this I mean
<ng0>what is the "" ?
<adfeno>"" command.
<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.
<lfam>We must remember to upgrade to the new nettle when it is released. It will contain changes to reduce side-channel vulnerabilities in RSA and DSA:
<mark_weaver>bah, this gd-2.2.3 is a nightmare :-(
<mark_weaver>it failed to build on both armhf and mips64el, due to another compiler warning turned error that is unrelated to my patch :-(
<lfam>Hm :(
<mark_weaver>and I'm not sure why this warning turned error doesn't happen on the intel architectures.
<mark_weaver>same thing on mips
<lfam>Thanks for the link. I was about to start clicking furiously at my web browser
<mark_weaver>I'll fix it. it's just a pain
<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
<mark_weaver>yeah, probably so
<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/ 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..
<bavier>i.e. the '.in' file suffix
<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
<adfeno>lfam: Thankyou very much! :)
<mark_weaver>ng0: that warning from patch-shebang should be harmless. that's a file that should have its shebang substituted by ./configure.
<mark_weaver>hopefully ./configure will do the right thing.
<mark_weaver>it might "just work"
<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/ 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
<mark_weaver>ng0: what 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.
<ng0>okay, thanks
<mark_weaver>ng0: ./configure should create based on 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?
<sapientech>parabola btw
<mark_weaver>some packages need more than that, I think.
<davexunit> sapientech: 4GiB is pretty small.
<lfam>sapientech: Sadly, it's not enough
<sapientech>thats fine, whats a good size you guys reckon?
<davexunit>I use 128GiB or more
<lfam>For the $TMPDIR?
<mark_weaver>sapientech: I suggest that you set TMPDIR=/var/tmp in the environment where guix-daemon is run
<davexunit>lfam: for /gnu/store
<lfam>Ah, we are talking about the TMPDIR :)
<davexunit>but I also would never use tmpfs for /tmp
<ng0>8GB. i never had to use more than 8 when building.
<sapientech>whew :)
<mark_weaver>davexunit: we're talking about /tmp
<lfam>I think 8 GB will be safe
<davexunit>8GiB sounds OK
<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
<sapientech>and to be clear, ramdisk = tmpfs?
<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.
<mark_weaver>sapientech: yes, tmpfs == ramdisk
<sapientech>ng0: lol
<ng0>the trinity of bloat :)
<mark_weaver>don't forget Qt
<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>Or, buy an SSD
<bavier>who here suggested GuixSD for the EOMA68?
<lfam>That's optimistic :)
<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
<lfam>I'll do it
<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
<bavier>lfam: cool, thanks
<mark_weaver>gah, this is a comedy of errors :-(
<lfam>Oh no :(
<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.
<mark_weaver>can anyone else reach savannah right now?
<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>thank you!
<mark_weaver>lfam: nevermind, just did the revert successfully
<lfam>Okay, a short outage
<mark_weaver>just tried to push 'wip-gd-fix', and got this: remote: fatal: bad object 0000000000000000000000000000000000000000" :-(
<mark_weaver>and yet somehow it seemed to work anyway. hmm
<mark_weaver>okay, hydra is evaluating it now.
<mark_weaver>ACTION goes afk
<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
<davexunit>this site butchers the rendering of my readme markdown file, but:
<davexunit>a GNU Guix Chef cookbook. flee in horror!
<lfam>Wow, you ain't kidding
<davexunit>lfam: yeah, it doesn't render inline html
<davexunit>and I needed a table ;)
<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/ 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 that
<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
<ng0>ooh.. thanks
<bavier>np, I've hit the same enough times before
<ng0>crash and learn :)
<ng0>yay, it works
<ng0>i'm sure i solved this earlier already
<Sleep_Walker>*** error: gettext infrastructure mismatch: using a from gettext version 0.19 but the autoconf macros are from gettext version 0.18
<Sleep_Walker>time to update po/guix
<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?
<mark_weaver>I don't recognize the string "BFF/heap"
<sapientech>mark_weaver: yeah i'll have to recompile it till it gets the error which will be ~1hr
<sapientech>would the log be saved somewhere?
<sapientech>(screen buffer erased the stdout)
<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