IRC channel logs

<civodul>bavier: i just let your messages to guix-devel go through

<civodul>something's broken with the moderation these days

<civodul>normally it just takes a few hours and i don't have to do anything

<Steap>How does one install the debug packages ?

<Steap>I'd need to run gdb on a program installed through guix

<civodul>Steap: http://www.gnu.org/software/guix/manual/guix.html#Installing-Debugging-Files

<civodul>but that package has to have a "debug" output

<civodul>which is not the case by default

<Steap>oh

<Steap>erf

<mark_weaver>is there a way to unpack the source tree with all the relevant patches and substitutions, such that it matches what was compiled?

<mark_weaver>(for purposes of debugging)

<civodul>mark_weaver: for patches yes, that was the purpose of the recent change

<civodul>for substitutions, no

<civodul>discussion at https://lists.gnu.org/archive/html/guix-devel/2013-09/msg00137.html

<mark_weaver>civodul: thanks!

<mark_weaver>one more question: after I finish building new bootstrap tarballs, what is the right way to start a rebuild based on the new tarballs? will it happen automatically?

<bavier>ugh, so sorry about the spam on guix-devel

<Steap>bavier: took a quick look, you got the Copyright line wrong :)

<mark_weaver>or do I need to erase /nix/store and the DB and start from scratch?

<zacts>lo

<civodul>Steap: yeah, just replied to that one

<civodul>mark_weaver: it will happen automatically

<civodul>unless they are bit-for-bit identical, of course

<bavier>Steap: ouch, ok, I'll look at it

<mark_weaver>how does that work? every time I builds something it tries to fetch bootstrap tarballs from the server?

<civodul>bavier: i fixed it before pushing

<mark_weaver>well, I guess the binaries in gnu/packages/bootstrap/*/ will be different, so I guess that's enough.

<civodul>mark_weaver: no; bootstrap.scm tells where the bootstrap tarballs are, and what their hash is

<civodul>yes, exactly

<mark_weaver>okay

<mark_weaver>so I guess I could keep a 'guix' build directory around with the old bootstrap tarballs, while waiting for the new one to build.

<mark_weaver>one thing I don't understand though: how can we upgrade the x86_64 bootstrap tarballs without making breaking guix 0.4 ?

<mark_weaver>s/making breaking/breaking/

<mark_weaver>I guess we could change from http://alpha.gnu.org/gnu/guix/bootstrap to another directory name.

<civodul>it's in a subdir already :-)

<civodul>so we'd keep x86_64-linux/20130105, and add x86_64-linux/20131011

*civodul -> zZz

<mark_weaver>ah, okay. sorry for the bandwidth.

<mark_weaver>good night!

<civodul>good night/day!

<gzg>On my Debian Stable box, will I be missing anything big -- if I don't go Guile 2.0.9, in terms of Guix's feature-set?

<gzg>Can I get something I build via the pre-inst-env in my actual guix profile?

<gzg>Guix pull still isn't working on my install and the git repo might be more ideal anyway, until a solid live-image is released, :^P

<gzg>civodul: o/

<civodul>oh, faster than me

<civodul>Hello Guix!

<civodul>:-)

<davexunit>good morning

<gzg>civodul: You actually caught me right before I was about to take a nap -- fyi though, later I plan on posting about kbd.scm to the guix-devel list... since the other didn't ever get to bug-guix. :^P

<civodul>gzg: it did!

<civodul>i just replied, even :-)

<civodul>dunno why it took so long

<civodul>it's only the first post that takes time normally

<civodul> http://bugs.gnu.org/15608

<gzg>civodul: Cool, thanks; I'll look more into it when I'm a bit more awake. :^)

<civodul>:-)

<gzg>Okay, I'll be back later today/tonight. Peace people o/; AFK.

<civodul>peace

<a_e>Hello!

<civodul>hey, a_e

<a_e>civodul: Hydra has more problems...

<a_e>hydra-evaluator was not running, so I started it.

<civodul>i can't believe it

<civodul>:-)

<a_e>Now, there are evaluation errors again.

<civodul>what makes you think it wasn't running?

<a_e>ps -ef|grep hydra-e did not find anything.

<a_e>In glib, there is a test "network-address" that fails now.

<civodul>mark_weaver reported it before

<civodul>does it fail on hydra?

<a_e>Yes, in i686 and x86_64. It does not fail on my own machine, though.

<civodul>hmm, works for me too

<a_e>Could there be a problem with outgoing network traffic?

<a_e>The "evaluation error" message is related to not being able to update the git repository, I think.

<civodul>a_e: yes, but it's gone now

<civodul>i restart it

<civodul>*restarted

<Steap>a_e: took a look at evince, it segfaults/sigtraps on my machine

<Steap>I've been debugging this a bit, will write an email about that tonight

<a_e>Now there is a very strange error on the harfbuzz build.

<a_e>Steap: Good!

<Steap>but yeah, it's too bad that after packaging all these GNOME packages, we can't use applications, that's a bit frustratring

<civodul>oh, we have GNU Make 4 with Guile support in core-updates :-)

<Steap>(I got the same kind of errors with eog)

<civodul>actually pavucontrol and geeqie work fine :-)

<Steap>what are these ? :p

<civodul>how come you can live without it?

<civodul>:-)

*civodul goes afk

<zacts>lo

<mark_weaver>hi zacts!

<mark_weaver>how goes the hack?

<civodul>mark_weaver: did you find out anything more about GLib's 'network-address' test failure?

<mark_weaver>I didn't investigate any further, since reporting some partial findings here on #guix.

<mark_weaver>I switched gears and started building native bootstrap tarballs.

<civodul>ok

<civodul>i'll see what i can do

<civodul>it's failing on hydra now

<mark_weaver>*nod* I saw you mentioning that earlier.

<mark_weaver>going afk for a while. good luck!

<civodul>thanks :-)

<civodul>GCC 4.8.2! IceCat 24.0!

<civodul>weee!

<mark_weaver>gmp 5.1.3. apparently 5.1.2 generates "garbage" results with low probability :)

<mark_weaver>but I guess that's for core updates only :)

<mark_weaver>it's great that icecat has finally been updated, though.

<zacts>mark_weaver: hey, I'm about to re-checkout my git tree now

<ArneBab_>USE flags for functional package management: like having a list of globally set keyword arguments. If a package has that keyword argument, it gets set to the global value.

<ArneBab_>Also with peo-package set args.

<ArneBab_>I do not have time to discuss this, but I had to et it out of my mind - and the best way to do that is to pass it on to people to whom it can be useful

<ArneBab_>per-package

<ArneBab_>cu

<alip2890>I made a few changes on a separate branch and didn't pull master since then. how is the usual procedure? pulling into master, merging the branch, and then formatting the patch?

<Steap>alip2890: I usually git checkout master && git pull origin master && git checkout mybranch && git rebase master && git format-patch

<mark_weaver>from your branch, you can just do: git merge origin/master

<a_e>Rather: Pulling in master, and do a "git rebase master" in your new branch.

<a_e>"rebase" puts your own commits on top of those found in master.

<a_e>I think "merge" created a new commit with the merge.

<mark_weaver>that's true. rebase has some advantages.

<mark_weaver>there are use cases for both approaches.

<a_e>Yes. But in my own branches there are usually just a few commits (like one for a new package) that I wish to put on top of master.

<mark_weaver>I don't think that switching back and forth between the branches is optimal, though.

<a_e>We merge between core-updates and master, which looks reasonable.

<mark_weaver>I think perhaps "git rebase origin/master" is a simpler and more efficient way to do what a_e is talking about.

<mark_weaver>it's possible that a "git fetch" might be needed somewhere, I'm not sure.

<a_e>mark_weaver: Probably so. I suppose one could also work more on branches without checking them out.

<mark_weaver>I use the "git-new-workdir" script (which comes with git) extensively, which allows me to have multiple working directories, each on a different branch, but sharing the same underlying git repo.

<zacts> http://paste.lisp.org/display/139472

<zacts>make failure with the latest git pull

<mark_weaver>For my guile repo, I have a whole bunch of working directories created that way: guile-stable-2.0, guile-master, guile-my-foo-branch, etc..

<a_e>There has been a commit today that forces you to do a "make clean; make".

<zacts>ah ok

<a_e>mark_weaver: Sounds interesting!

<a_e>So this means you do not need to stash all these changes to different working directories?

<mark_weaver>right. the big win is that it minimizes the amount of needless rebuilding.

<a_e>Neat!

<mark_weaver>I can have my private branch in one workdir, and then if I realize I want to make a change to stable-2.0, I can do that in a separate directory without disturbing my private work-in-progress.

<Steap>a_e: having to run "make clean" is a bit annoying :/

<mark_weaver>a_e: the git-new-workdir script is in git-*/contrib/workdir/

<mark_weaver>(in the git source code)

<zacts>I need to really learn git

<Steap>zacts: I told myself that once, I still don't get it.

<zacts>I have those advanced git o'reilly videos

<zacts>I should watch them

<zacts>a_e: after make clean ; make I'm still getting the same error

<zacts>web/http.scm

<zacts>Bad Date header:

<mark_weaver>zacts: what version of guile do you have?

<mark_weaver>(the guile outside of guix, that is)

<zacts>2.0.9

<mark_weaver>hmm

<mark_weaver>I can reproduce that 'parse-date' from (web http) does not like the string "Sun, 13 Jan 2013 23:27:39 UTC"

<zacts>I wonder if you can git bisect this bug

<mark_weaver>are you behind a web proxy?

<zacts>mark_weaver: I may be, I'm on my college's wifi.

<zacts>is there a command I can issue to find out?

<mark_weaver>alpha.gnu.org does *not* send UTC in the date header. instead, it sends: Date: Wed, 16 Oct 2013 18:53:31 GMT

<mark_weaver>I think that there's some web proxy between you and alpha.gnu.org that's changing the headers

<zacts>weird

<mark_weaver>zacts: try this: wget -S http://alpha.gnu.org/gnu/guix/bootstrap/i686-linux/20130105/guile-2.0.7.tar.xz

<mark_weaver>and tell me what it prints as the Date header.

<zacts>Date: Wed, 16 Oct 2013 18:55:41 GMT

<mark_weaver>hmm..

<mark_weaver>do you have the 'http_proxy' environment variable set?

<zacts>nope

<mark_weaver>well, that's bizarre. I don't know where the UTC came from.

<mark_weaver>I wonder if it's in violation of the relevant RFCs, or if we need to improve our http date header parser.

<mark_weaver>well, I just checked RFC 2616, and indeed "UTC" is a violation of that RFC. it must either be "GMT" or a 4-digit number.

<mark_weaver>zacts: maybe try again? perhaps it was some kind of fluke?

<zacts>ok

<zacts>I'm doing: git checkout master; git branch zacts; git checkout zacts; ./bootstrap; ./configure; make.

<zacts>let's see if it works

<zacts>I'm still getting the same error

<zacts>let me try v0.4 of guix

<zacts>if that works, then maybe I can bisect it.

<zacts>otherwise I guess I could ssh forward my connection through my box at home

<zacts>which for sure is not behind a proxy

<mark_weaver>zacts: in the 'wget' output, I should have asked you to look at the "Last-Modified" header. what do you see there?

<mark_weaver>I see "Last-Modified: Sun, 13 Jan 2013 23:27:39 GMT", which is identical to the string in your error message, except with "UTC" instead of "GMT".

<zacts> Last-Modified: Sun, 13 Jan 2013 23:27:39 UTC

<mark_weaver>ah, so I guess you must be behind a proxy that's violating RFC 2616 :-(

<mark_weaver>blech

<mark_weaver>it's not going to help to try a different version of guix.

<zacts>yeah I've realized that

<zacts>all I need to do is figure out how to forward my web traffic through ssh

<zacts>I forgot how to do it, it's been so long

<mark_weaver>you'd have to set up a proxy server on home box.

<mark_weaver>for now, it might be easier to just modify Guile's web/http.scm to accept UTC.

<zacts>mark_weaver: I don't think I have to set up a proxy server on my home box

<zacts>I can just use plain ssh

<mark_weaver>I don't see how that's going to work.

<mark_weaver>but if you get it working, let me know how you did it.

<zacts>sure, ok

<zacts>just a sec

<mark_weaver>when I need to do this, I set up an ssh tunnel to 'polipo', a lightweight proxy, on my server.

<mark_weaver>and then set 'http_proxy' to point to localhost:PORTNUM

<mark_weaver>keep in mind that it won't be enough to hack the download for this one file. the guix downloader is unlikely to work at all from behind that broken proxy server.

<alip2890>aah, I can see Torvalds laughing at the horizon, for he invented a real git

<zacts>ssh -D

<mark_weaver>ah, I didn't know about ssh -D. However, I don't think that SOCKS is supported by guile's web client. I think it only supports standard http proxy servers.

<mark_weaver>(I actually implemented the proxy support in guile)

<mark_weaver>yeah, SOCKS is not supported by guile/guix.

<zacts>what ports?

<mark_weaver>actually, iirc, I think I didn't add proxy support to guile until after 2.0.9 was released.

<zacts>mark_weaver: what ports would guile use for proxy?

<mark_weaver>but maybe guix monkey patched it in.

<mark_weaver>recent guile looks at the 'http_proxy' environment variable.

<mark_weaver>which should be a URL like http://localhost:2222/

<zacts>ah let me try that

<mark_weaver>zacts: sorry, I can see that support for HTTP proxies wasn't added until after 2.0.9 was released, and it's not in guix either.

<mark_weaver>zacts: well, here's your best shot for now: you can manually download the files that guix needs, and then insert them into the store using: guix download file:PATHNAME

<mark_weaver>what a pain.

<civodul>agreed

<civodul>not sure if we could have a quick workaround for Guile <= 2.0.9

<mark_weaver>civodul: I'm not sure if you read the beginning of this discussion, but zacts' college has a transparent web proxy that munges the "Last-Modified" headers to end with "UTC" instead of "GMT", in violation of RFC 2616.

<mark_weaver>and Guile doesn't accept it.

<mark_weaver>I'm tempted to make guile's web client permissive in this case, and accept "UTC".

<mark_weaver>but of course that won't help zacts until guile 2.0.10 is released.

<mark_weaver>(and added to Guix)

<mark_weaver>civodul: how do you think we should handle this?

<zacts>there are also openssh virtual private networks

<zacts>but I don't want to fiddle with it right now. just a sec. I may have some internet on my cellphone.

<zacts>brb

<civodul>mark_weaver: ah yes, i'd make Guile's client more permissive

<civodul>a_e, mark_weaver: i just emailed my findings about GLib's test failure

<zacts>unfortunately, I don't have internet on my phone right now

<zacts>it sucks to have to work around bugs

<mark_weaver>civodul: ah, good. thanks for including your test code; it's quite useful for teaching us how to debug similar problems :)

<civodul>well i was pretty clueless, so i used brute force :-)

<civodul>i'm testing a patch now

<mark_weaver>I'm surprised that the build environment doesn't have 'lo'. in fact, I thought I remember seeing in the strace output that is *does* have 'lo

<civodul>ah right

<civodul>well it doesn't have it here

<civodul>i wouldn't be surprised if this changes between kernel versions...

<mark_weaver>civodul: nix/libstore/build.cc line 2075 tries to set up "lo".

<mark_weaver>I think the bug is elsewhere.

<mark_weaver>IMO, the build environment *should* have lo, for testing purposes.

<civodul>yes

<civodul>which bug is elsewhere?

<civodul>that if_indextoname succeeds clearly leads to the assertion failure in network-address.c

<civodul>s/succeeds/*never* succeeds/

<mark_weaver>if_indextoname should return "lo".

<mark_weaver>or at least I strongly suspect that it should. I'd like to know why it doesn't.

<mark_weaver>maybe there's something wrong in build.cc, such that "lo" is not getting set up properly. or perhaps it's a kernel bug.

<mark_weaver>of course, I'm not necessarily opposed to working around the problem for now by disabling the test, but I suspect the real problem is either in build.cc or the kernel.

<zacts>well I guess I will work on guix when I get home. for now I'm going to do the little schemer

<zacts>let's see if I can complete the whole book today

<civodul>mark_weaver: or could it be that it has a weird index?

<mark_weaver>that's a great book!

<civodul>i just tried for indices < 10

<zacts>mark_weaver: I own all three books

<zacts>but I've never read them yet

<zacts>*but I haven't read them yet

<mark_weaver>all three are excellent

<zacts>have you read the third one?

<mark_weaver>the third one is quite different from the other two. it's not so much about "normal" scheme programming, but about a logic programming system called "mini kanren" that can be very easily built on top of scheme.

<civodul>it rocks

<zacts>oh cool, yeah it looks really interesting. I can't wait to finish them. how long did it take you to finish all three?

<civodul>i'm a bit frustrated because i never found an occasion to use minikanren in the real world

<mark_weaver>I don't do much logic programming, I confess, but when I do, I want to use kanren for it.

<mark_weaver>I don't remember, it was so long ago. and I was probably doing many other things is parallel with working through them.

<mark_weaver>s/is/in/

<zacts>ah ok

<a_e>civodul: How could it be build.cc if the tests succeed on pur own machines and not hydra? The kernel sounds more likely then.

<zacts>well, ttyl - /me has some reading to do

<zacts>and mind pretzels to navigate through

<mark_weaver>a_e: it fails on my machine too :)

<a_e>mark_weaver: But your machine is weird ;-)

<mark_weaver>hehe

<a_e>Logically, it needs to be something that varies across machines, and build.cc does not.

<mark_weaver>well, it's possible that build.cc uses an unreliable method to set up "lo".

<mark_weaver>(I'm not saying that's likely)

<mark_weaver>I have to go afk for a bit. ttyl!

<civodul>blech, that glib thing is tiring

IRC channel logs

2013-10-16.log