IRC channel logs
2015-07-15.log
back to list of 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>shouldn't the GET request be prefixed with "/nar"? <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>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>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. <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) <mark_weaver>(package->derivation (@@ (gnu packages commencement) gnu-make-boot0)) <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> <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>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")]) <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>rekado: what is the output of: sha256sum /gnu/store/nzv2wz6m799daxsb8989v2bcg1156nyd-guile-2.0.9.tar.xz <rekado>037b103522a2d0d7d69c7ffd8de683dfe5bb4b59c1fafd70b4ffd397fd2f57f0 <mark_weaver>and what is the output, on your laptop, of: sha256sum /gnu/store/98xcn26354r70nyamkgywqzjxvw3qikx-guile-2.0.9.tar.xz <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>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>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>my colleague must have done this. <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. <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>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. <rekado>I'll go write an email now: "do not touch my stuff while I'm gone"... :) <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>guix system: error: build failed: path `/gnu/store/hill6gywff6p2c3h1zbc7h5xj0cr4yn2-grub.cfg' is not valid <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? :-) <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. <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>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>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>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>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>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>Description=Guix daemon builds packges, installs them, and runs garbage collection. <efraim>ExecStart=/root/.guix-profile/bin/guix-daemon --build-users-group=guix-builder <efraim>wait, i should read to the end before i reply, ~50 minutes too late <civodul>i've committed it locally, will push shortly <Steap>ACTION might add gnu/packages/openstack.scm tonight :) <civodul>sounds like quite an achievement no? <Steap>but I can use guix-tox to run tests for one of the CLI clients <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>(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>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>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>it's not that important, just an interesting anecdote. <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>I'm currently running the GC on hydra, and have the evaluator turned off until it's done. <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>(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) <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." <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 <mark_weaver>make sure to include the exact command that you typed, and the full error message (and any other relevant context) <tyrion-mx>mark_weaver, should I include the full output on the mail or put it on paste.debian ? <mark_weaver>bug reports should be self contained, and not refer to paste sites <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 <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. <mark_weaver>(while my computer test-builds icecat 31.8.0 with hardware accel and webgl re-enabled) <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. <alezost>Steap: apparently not, look for example at 'net-base' or 'perl-sql-abstract' <Steap>alezost: oh, we should improve "guix lint" then :p <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: I also set maxconcurrent to 8 for i686 and x86_64 <Steap>Can one write "* gnu/packages/foo.scm (python{,2}-{pkg1,pkg2}): New variables." in the commit log ? <civodul>it's useful to have variable names spelled out, when searching through the log