IRC channel logs

<rekado>strace on the daemon doesn't show me that it's even trying to perform a lookup.

<rekado>ah, it actually does make a lookup, but it results in 404.

<rekado>the first request it makes is this:

<rekado>21333 write(12, "GET /zrf3ws388d5vqvq1hfmbp15spn2pynrx.narinfo HTTP/1.1\\r\\nHost: hydra.gnu.org\\r\\n\\r\\nGET /zqjxmpxblg83dnbqx799p3id2ic5ki2p.narinfo HTTP/1.1\\r\\nHost: hydra.gnu.org\\r\\n\\r\\nGET /zn19xfykz77rynpzqzy0v6vas4lrray1.narinfo HTTP/1.1\\r\\nHost: hydra.gnu.org\\r\\n\\r\\nGET /zkf959yggi62p7zjlis3lvq24cbpmmx0.narinfo HTTP/1.1\\r\\nHost: hydra.gnu.org\\r\\n\\r\\nGET /zincza7sa81dqbiqz7m2klwakzg9fzf3.narinfo HTTP/1.1\\r\\nHost:

<rekado>hydra.gnu.org\\r\\n\\r\\nGET /zhxdvsrw1pv6yk0l5pybxjdbmhd30xvw.narinfo HTTP/1.1\\r\\nHost: hydra.gnu.org\\r\\n\\r\\nGET /zb08av89ks4md7ra37sk4xhwvr478ddk."..., 23384)

<rekado>and to those, hydra says: "does not exist".

<rekado>any ideas?

<rekado>shouldn't the GET request be prefixed with "/nar"?

<paroneayea>"/narf"

<paroneayea>(ignore me)

<mark_weaver>rekado: everything you've said is consistent with the idea that you are generating different derivations (with different hashes) than anything that hydra has built

<mark_weaver>rekado: if you look at the "details" tab of a build page on hydra, it will show the derivation store path and the output store paths

<mark_weaver>see if those correspond to the derivations that your 'guix' says it wants to build.

<mark_weaver>(if the hashes are the same or different)

<mark_weaver>rekado: it would be interesting to see how early in the bootstrap the hashes diverge

<rekado>mark_weaver: you are right. The derivation of R to be built is /gnu/store/fjg28h003n90z4qf083iaby63bxw7aqz-r-3.2.1.drv, not the one from hydra.

<rekado>The same is probably true for all others, except netbpm.

<rekado>interestingly, it wants to build autoconf-wrapper.

<rekado>the derivation name differs also from what is shown here: http://hydra.gnu.org/job/gnu/master/autoconf-wrapper-2.69.x86_64-linux

<rekado>but that last changed in March 2014.

<rekado>I'm cloning the git repo afresh and try working from there.

<mark_weaver>rekado: I'd be curious to see at what point in the bootstrap the derivation hashes change.

<rekado>how can I figure this out?

<mark_weaver>you could find out by entering the store monad REPL (see section 4.5 of the manual) and running 'package->derivation' on various packages in (gnu packages bootstrap) and (gnu packages commencement)

<rekado>ok

<mark_weaver>so, for starters, from ./pre-inst-env guile

<mark_weaver>,use (guix monad-repl)

<mark_weaver>,enter-store-monad

<mark_weaver>(package->derivation (@@ (gnu packages commencement) gnu-make-boot0))

<mark_weaver>oh, also ,use (guix packages)

<mark_weaver>on my GuixSD x86_64 system, close to master, I get this:

<mark_weaver>#<derivation /gnu/store/r28jj7ga56pp8qj22x3a6hwr8q2a9gym-make-boot0-4.1.drv => /gnu/store/qrp8vdzh0jqmplkp8q4j3dl2hgvnlh78-make-boot0-4.1 /gnu/store/k5mmysm981zdi0504lrkn3na5lpz50kh-make-boot0-4.1-debug 3db28c0>

<mark_weaver>are the hashes the same for you?

<rekado>#<derivation /gnu/store/y40v4nrgy6cr9bia9cc4hx4qj89ahxkg-make-boot0-4.1.drv => /gnu/store/v4cv8nqlidgky14h86fqi1kcbma821kz-make-boot0-4.1 /gnu/store/z1w6zrvqicyl2m3kr5xp5yw5q8876jn0-make-boot0-4.1-debug 3b55410>

<mark_weaver>(package->derivation (@@ (gnu packages bootstrap) %bootstrap-guile)

<mark_weaver>I get: #<derivation /gnu/store/dhmrgxvvaz14dircvp2m2s8kf7i0307l-guile-bootstrap-2.0.drv => /gnu/store/cyppdaliwllm1mzgka3cxwxnddk7j2cl-guile-bootstrap-2.0 2f872d0>

<rekado>#<derivation /gnu/store/71jbgv73izq5fx2r1kppdp6skq561143-guile-bootstrap-2.0.drv => /gnu/store/3wicp16d74i8csxylr2d7hj15ihv77kl-guile-bootstrap-2.0 3874140>

<rekado>(I wonder how this could get so messed up, two days after I started my vacation.)

<mark_weaver>rekado: can you paste the contents of the .drv file?

<mark_weaver>yes, I'm also curious.

<mark_weaver>you can paste it right here.

<mark_weaver>I get: Derive([("out","/gnu/store/cyppdaliwllm1mzgka3cxwxnddk7j2cl-guile-bootstrap-2.0","","")],[],["/gnu/store/gvwf71vddp8c1d7ydqg02p43mgdjrx6s-bash","/gnu/store/s6ir76g27cb7qi707m1vpl9qd712w7pk-build-bootstrap-guile.sh"],"x86_64-linux","/gnu/store/gvwf71vddp8c1d7ydqg02p43mgdjrx6s-bash",["/gnu/store/s6ir76g27cb7qi707m1vpl9qd712w7pk-build-bootstrap-guile.sh"],[("out","/gnu/store/cyppdaliwllm1mzgka3cxwxnddk7j2cl-guile-bootstrap-2.0")])

<rekado>Derive([("out","/gnu/store/3wicp16d74i8csxylr2d7hj15ihv77kl-guile-bootstrap-2.0","","")],[],["/gnu/store/gvwf71vddp8c1d7ydqg02p43mgdjrx6s-bash","/gnu/store/hw8bl0pcccyam76cmvmw3nhb9rz91cs4-build-bootstrap-guile.sh"],"x86_64-linux","/gnu/store/gvwf71vddp8c1d7ydqg02p43mgdjrx6s-bash",["/gnu/store/hw8bl0pcccyam76cmvmw3nhb9rz91cs4-build-bootstrap-guile.sh"],[("out","/gnu/store/3wicp16d74i8csxylr2d7hj15ihv77kl-guile-bootstrap-2.0")])

<rekado>bash is the same.

<mark_weaver>it's "build-bootstrap-guile.sh" is the one that's different

<mark_weaver>rekado: can you paste the contents of that .sh file to a paste site?

<rekado>the guile tarball hash in there differs from what I have on my laptop

<rekado>on my laptop its /gnu/store/98xcn26354r70nyamkgywqzjxvw3qikx-guile-2.0.9.tar.xz

<rekado>but there it is /gnu/store/nzv2wz6m799daxsb8989v2bcg1156nyd-guile-2.0.9.tar.xz

<mark_weaver>here's mine: http://paste.lisp.org/+38ZD

<mark_weaver>your laptop agrees with my laptop

<rekado>I annotated the paste: http://paste.lisp.org/display/151609#1

<mark_weaver>rekado: what is the output of: sha256sum /gnu/store/nzv2wz6m799daxsb8989v2bcg1156nyd-guile-2.0.9.tar.xz

<mark_weaver>?

<rekado>037b103522a2d0d7d69c7ffd8de683dfe5bb4b59c1fafd70b4ffd397fd2f57f0

<mark_weaver>and what is the output, on your laptop, of: sha256sum /gnu/store/98xcn26354r70nyamkgywqzjxvw3qikx-guile-2.0.9.tar.xz

<rekado>it's the same.

<rekado>037b103522a2d0d7d69c7ffd8de683dfe5bb4b59c1fafd70b4ffd397fd2f57f0

<mark_weaver>rekado: what are the permission bits on those two files?

<rekado>hmm: -r-xr-xr-x on guix-builder, -r--r--r-- on my laptop

<mark_weaver>I think that's the problem.

<rekado>how can this be?

<mark_weaver>in your git checkout, run chmod 644 gnu/packages/bootstrap/x86_64-linux/guile-2.0.9.tar.xz

<rekado>(I'll be really angry if someone changed permissions there.)

<mark_weaver>rekado: presumably because the mode of the file is part of what contributes to the hash of the file when added to the store, which makes sense.

<mark_weaver>at least some of the mode.

<mark_weaver>the write bits are ignored and just turned off in the store

<mark_weaver>but the executable bit at least is semantically relevant.

<mark_weaver>civodul would know the details, or I could dig into the daemon source to find it.

<rekado>no, that's okay.

<rekado>my colleague must have done this.

<mark_weaver>did removing the execute bit fix the problem?

<mark_weaver>my guess is that you don't even have to run "make".

<rekado>I haven't yet as I'm still comparing bits.

<rekado>that's the only file that has changed.

<rekado>also the group ownership was changed.

<mark_weaver>that's probably unimportant, but very curious

<rekado>I saw that permissions in the git checkout were changed, but git diff showed me.

<rekado>it did *not* show me that the bootstrap binaries were changed.

<mark_weaver>well, that particular file is not in the git repo

<mark_weaver>it's downloaded by a rule in the makefile

<rekado>ah, makes sense.

<mark_weaver>and btw, notably: the sha256sum is verified after it is downloaded, but if the file is already there in your source directory, it is *not* checked.

<rekado>trying to build R again, now that the bootstrap tarball's permissions have been reset.

<mark_weaver>so, for example, if at some point in the future we update the bootstrap guile, you'll need to explicitly remove the file from your source directory in order to have 'make' get the new one.

<mark_weaver>(I filed a bug about it: http://bugs.gnu.org/17150 )

<rekado>yes! It's fixed!

<rekado>mark_weaver: thank you so much!

<mark_weaver>well, that's a relief :)

<mark_weaver>you're welcome!

<rekado>I'll go write an email now: "do not touch my stuff while I'm gone"... :)

<mark_weaver>:)

<rekado>Would it be a bad idea to rename the python-2.7.6 package from "python" to "python2"?

<rekado>We already have separate "python2-whatever" for Python 2 modules.

<rekado>Installing "python" and "python-2.7.6" in the same profile and then updating all packages results in these two packages to be upgraded to just "python".

<rekado>I think that in the case of Python these two packages should not be considered merely different versions of the same thing, because they are incompatible.

<tyrion-webchat>Hello

<tyrion-webchat>exact same problem as yesterday, after a fresh install of guix

<tyrion-webchat>guix system: error: build failed: path `/gnu/store/hill6gywff6p2c3h1zbc7h5xj0cr4yn2-grub.cfg' is not valid

<rekado>Iceweasel violates privacy: https://lists.debian.org/debian-devel/2015/07/msg00226.html I have to check whether Icecat exhibits the same behaviour.

<civodul>Hello Guix!

<rekado>tcpdump on GuixSD says this (running as root): "tcpdump: live packet capture not supported on this system"

<civodul>rekado: i've seen this before, i don't know why this happens

<rekado>at first I thought it's because I need to enable promiscuous mode, but even after "ip link set enp0s25 promisc on" I get the same error.

<civodul>i wonder if we're missing a kernel module or something

<civodul>does an web search provide useful clues? :-)

<serhart>join #hurd

<serhart>doh

<rekado>I guess this is related to libpcap rather than tcpdump itself.

<rekado>so, this is in fact an error message from libpcap when the NULL device is used.

<rekado>s/device/interface/

<civodul>does it mean that libpcap fails to list interfaces?

<rekado>the linux interface should be used instead.

<civodul>"interface" in the sense of "back-end", right?

<rekado>yes

<rekado>the code in pcap-null.c is just a dummy backend.

<rekado>with stubs for pcap_create_interface and pcap_platform_finddevs

<rekado>I'll try to build it locally and see what the configure steps tell me.

<rekado>It builds only few backends: null, usb-linux, can-linux, netfilter-linux, common. Not sure yet how a module is selected at runtime.

<civodul>hmm ok

<civodul>does anyone have that guix-daemon.service file for systemd?

<civodul>someone posted it here a while back but i can no longer find it

<rekado>I did.

<rekado>let me check

<rekado>civodul: http://paste.lisp.org/display/151628

<rekado>that's the one we use.

<civodul>great, thanks rekado!

<civodul>can i add it to the repo?

<rekado>sure.

<rekado>pcap-linux is not built at all. Only netfilter-linux exists. Since iptables also doesn't work for me out of the box, I think I need to load some kernel modules to make netfilter and thus tcpdump work.

<civodul>and "pcap-linux" is another backend that does not rely on netfilter?

<rekado>it seems so.

<rekado>pcap-linux.c: Packet capture interface to the Linux kernel

<rekado>could be that this is just for older kernels, though.

<civodul>Nixpkgs builds with "--with-pcap=linux"

<rekado>civodul: passing "--with-pcap=linux" to libpcap causes pcap-linux.c to be compiled --- and with it tcpdump actually works!

<civodul>excellent!

<civodul>they could have called it "--enable-usable-libpcap" or something :-)

<civodul>mark_weaver: the "build tarballs deterministically" thing is a great idea, thanks!

<efraim>civodul: cat /etc/systemd/system/guix-daemon.service

<efraim>[Unit]

<efraim>Description=Guix daemon builds packges, installs them, and runs garbage collection.

<efraim>[Service]

<efraim>ExecStart=/root/.guix-profile/bin/guix-daemon --build-users-group=guix-builder

<efraim>[Install]

<efraim>WantedBy=multi-user.target

<efraim>wait, i should read to the end before i reply, ~50 minutes too late

<civodul>well, thanks anyway efraim ;-)

<civodul>i've committed it locally, will push shortly

<Steap>ACTION might add gnu/packages/openstack.scm tonight :)

<civodul>yay!

<civodul>sounds like quite an achievement no?

<Steap>well

<Steap>not all OpenStack :D

<Steap>but I can use guix-tox to run tests for one of the CLI clients

<civodul>well yeah i guess so, but still :-)

<Steap>which is nice

<civodul>indeed

<alezost>description of 'rdiff-backup' (and <http://www.nongnu.org/rdiff-backup/>) contains the word "sensical". Should it be "sensible" instead?

<cehteh>is rdiff backup useable meanwhile? i used it some years ago and it was a pita :D

<cehteh>(depending on bleeding edge python versions, not backwards compatible after upgrades, didnt worked with hosts which had another version installed, etc)

<cehteh>what one doesnt expect is that his backups are invalidated after an upgrade

<civodul>alezost: it's nonsensical!

<civodul>:-)

<civodul>(but yeah, "sensible" makes more sense)

<alezost>oh! "nonsensical" didn't come to my mind :-)

<mark_weaver>civodul: fyi, rekado experienced a surprising issue that took a while to debug. Apparently one of his coworkers had added the execute bit to gnu/packages/bootstrap/x86_64-linux/guile-2.0.9.tar.xz, and this had the effect of changing the hashes on all his builds.

<civodul>yes, that's expected

<civodul>but i understand it can be tricky to find out!

<mark_weaver>yes, of course, it makes sense in retrospect, it's just a non-obvious gotchs

<mark_weaver>*gotcha

<mark_weaver>that file is problematic in particular since it's not managed by git, and so "git describe --dirty" doesn't notice if it's out of sync.

<civodul>well in 'raw-build' in bootstrap.scm, we should probably use #f for the #:recursive? parameter

<civodul>that would avoid this particular problem

<mark_weaver>oh, the recursive flag also controls whether the execute bit is preserved?

<mark_weaver>well, we don't have to talk about this now...

<mark_weaver>it's not that important, just an interesting anecdote.

<civodul>yeah

<civodul>BTW, we should start building core-updates soon

<civodul>what's the status regarding --build?

<mark_weaver>it all looks good so far. I've built 'hello' on my x86_64 laptop with current core-updates.

<mark_weaver>and also built hello on armhf.

<mark_weaver>I'm currently running the GC on hydra, and have the evaluator turned off until it's done.

<mark_weaver>but yes, I agree we should build out core-updates.

<mark_weaver>I see a test failure in python-3: ERROR: test_write_filtered_python_package (test.test_zipfile.PyZipFileTests)

<mark_weaver>ValueError: ZIP does not support timestamps before 1980

<mark_weaver>I guess that's related to zeroing the timestamps in the source tarball

<mark_weaver>civodul: it occurs to me that if we fixed hydra's handling of -C in the presence of deduplication, then we could get a much faster removal of .links/* almost for free

<mark_weaver>the idea would be to check the number of hard links on each file as it's removed from the store.

<mark_weaver>and only when the link count goes to 2 is the file really going to be deleted. only then should its size be included in the accounting of how much has been freed, and in that case the .links/* file can be removed immediately.

<mark_weaver>however, it's probably not entirely airtight, so it would be good to have an option to run a full pass over .links/* looking for links to remove.

<mark_weaver>thoughts?

<mark_weaver>s/goes to 2/was 2 before removal/

<mark_weaver>(the current code includes a comment admitting that there's a race condition, so it's not quite right either. I wonder if that could be fixed properly)

<tyrion-mx>Hi

<mark_weaver>civodul: I recently fixed WebGL in our IceCat, which made davexunit happy (he had been missing it). Now I see that Rubén explicitly "Disabled hardware acceleration and WebGL" in the latest release of IceCat. http://git.savannah.gnu.org/cgit/gnuzilla.git/commit/?id=2d86679d403e25d512409eb707ee08c62d96fe75

<mark_weaver>civodul: any thoughts on this?

<mark_weaver>I asked him why on bug-gnuzilla, and his response was "Hardware acceleration seems to cause glitches in several platforms, and WebGL can be used for fingerprinting and other attacks."

<mark_weaver>tyrion-mx: hi!

<tyrion-mx>mark_weaver, hey :) I had the exact same error after reinstalling anyway ..

<mark_weaver>tyrion-mx: can you email bug-guix@gnu.org with the details?

<tyrion-mx>the only strange thing that happened is that I forgot to use sudo on the guix system init command, so it failed at the end, but then running it again with sudo failed with the same grub error

<tyrion-mx>ok

<mark_weaver>tyrion-mx: you passed --no-grub, right?

<tyrion-mx>yes

<mark_weaver>make sure to include the exact command that you typed, and the full error message (and any other relevant context)

<mark_weaver>and your OS config as well

<mark_weaver>thanks

<tyrion-mx>by os config, you mean the config.scm file?

<mark_weaver>right

<tyrion-mx>mark_weaver, should I include the full output on the mail or put it on paste.debian ?

<tyrion-mx>(it not long)

<tyrion-mx>it's*

<mark_weaver>bug reports should be self contained, and not refer to paste sites

<mark_weaver>ditto for emails to our lists, in general.

<civodul>mark_weaver: i would reenable WebGL unless we have evidence that it causes troubles; re fingerprinting, it's just one of the many many ways to do that anyway

<mark_weaver>civodul: right, that was my feeling as well. I see that users could re-enable it from the "about:config" page.

<mark_weaver>so then the question is whether we should keep it enabled by default, which was the case in 31.7.0 and still is in firefox

<mark_weaver>I would invite anyone interested in this to engage in the conversation on bug-gnuzilla@gnu.org

<mark_weaver>a.k.a. gmane.comp.gnu.gnuzilla

<tyrion-mx>mark_weaver, before I send the mail would you check out my config.scm? https://paste.debian.net/282645/

<tyrion-mx>maybe I did some stupid things here

<tyrion-mx>(I hope not)

<mark_weaver>tyrion-mx: sorry, too busy right now

<tyrion-mx>ok

<civodul>mark_weaver: re python-3, do you think you could look into skipping this test maybe?

<civodul>mark_weaver: re GC, i think that's doable yes, we need to dive a bit into the GC code

<mark_weaver>civodul: I already fixed the python problem in a different way.

<civodul>oh excellent :-)

<mark_weaver>(after unpacking, I set all the times to 1980)

<mark_weaver>ACTION goes afk

<mark_weaver>(while my computer test-builds icecat 31.8.0 with hardware accel and webgl re-enabled)

<civodul>ok

<alezost>I see that some descriptions do not end with period, should the periods be added? (I'm going to make a big "clean up descriptions" patch)

<Steap>alezost: doesn't "guix lint" warn about that ?

<mark_weaver>civodul: fyi, I asked hydra to build all of core-updates, having now merged master and added a few other updates.

<mark_weaver>(the GC is done)

<alezost>Steap: apparently not, look for example at 'net-base' or 'perl-sql-abstract'

<Steap>alezost: oh, we should improve "guix lint" then :p

<alezost>Steap: it's up to you :-)

<civodul>mark_weaver: yay, thanks!

<civodul>mark_weaver: i've plugged in the new build machine \\o/

<civodul>i guess we need to pay attention in case something goes wrong

<mark_weaver>civodul: woohoo!

<mark_weaver>civodul: you didn't add sjd to the list at the end

<mark_weaver>I'll add it

<mark_weaver>civodul: hmm, no sjd-i686 ?

<mark_weaver>I added sjd-i686 and put them both in the list

<civodul>mark_weaver: good catches, thanks!

<civodul>what was i thinking of?

<mark_weaver>civodul: I also set maxconcurrent to 8 for i686 and x86_64

<mark_weaver>I'm not sure if those are the best values or not.

<Steap>Can one write "* gnu/packages/foo.scm (python{,2}-{pkg1,pkg2}): New variables." in the commit log ?

<mark_weaver>civodul: http://hydra.gnu.org/build/583857 has been offload to sjd

<mark_weaver>*offloaded

<mark_weaver>gotta go afk, baby not happy

<daviid>off topic: how do I upload a latest release to savannah, i.e. http://download.savannah.gnu.org/releases/g-wrap/ ?

<civodul>mark_weaver: cool!

<civodul>Steap: rather not, sorry ;-)

<Steap>civodul: :(

<civodul>it's useful to have variable names spelled out, when searching through the log

<civodul>daviid: https://savannah.gnu.org/maintenance/DownloadArea/

<daviid>civodul: thanks!

<civodul>yw!

IRC channel logs

2015-07-15.log