IRC channel logs


back to list of logs

<zacts>^^ guix v0.4 build failure on debian 7.2
<zacts>I guess I need a newer autoconf
<jxself>Debian? Of course. This is probably appropriate -
<jxself>It's important to be able to laugh at yourself...
<zacts>so I needed to apt-get install autopoint
<zacts>I didn't need a newer version of autoconf
<zacts>I only needed a newer version of automake
<wewttff>zacts: couldn't you just install autopoint?
<zacts>so apt-get <guix dependencies> <automake>
<zacts>wewttff: yep
<zacts>that's what I did
<wewttff>ah, ok.
<zacts>that is just for the bootstrap, now for ./configure
<zacts>ok I'm getting pkg.m4 errors
<zacts>I don't know how to install a newer pkg.m4
<zacts>I know how to specify export ACLOCAL_PATH=/usr/local/share/aclocal-1.14/
<zacts>but pkg.m4 isn't installing into that directory..
*zacts searches the web
<zacts>ok, I've got the pkg.m4 thing fixed (I had to ./bootstrap again).
<zacts>now it's not finding my debian guile
<civodul>hey there!
<civodul>gzg: thanks for the new version of the patch
<civodul>we're almost there, but some of the comments i made were not taken into account, and you didn't answer my questions
<civodul>could you check the message and reply to it?
<civodul>sorry for being picky!
<jmd>Anyone else seeing this failure building pixman:
<jmd>/nix/store/97vnvqq5daji73b71v4cnmyaa7r3hzk2-bash-4.2/bin/bash: line 5: 4781 Floating point exception(core dumped) ${dir}$tst
<jmd>FAIL: combiner-test
<jmd>If I recent a package to a newer version in the .scm file, I have to update the sha256 too.
<jmd>What's the recommended procedure for getting the right sha ?
<viric>curl URL | sha256sum
<viric>or if upstream provides some already... pick it
<jmd>Unfortunately upstream provides only sha1
<viric>then set sha1, not sha256
<viric>(in nix it works. I guess in guix too)
<viric>it supports multiple cryptohash
<viric>Or, download it, check the sha1, and then calculate the sha256
<jmd>So why do all the guix sources use sha256 (and in base32) ?
<jmd>At least all that I have seen.
<viric>same number of characters as sha1 but sfaer
<viric>this way was trendy in nix.
<jmd>But if the upstream has only provided sha1, then just blindly downloading, and pasting the sha256 is not safer at all.
<jmd>The person who downloaded it might have been man-in-the-middled.
<jmd>Hmm its rather inconsistent that there is a base32 but no base16
<viric>I said "check the sha1, then calculate the sha256"
<viric>but well, without signatures, the mitm can be for both the upstream hash and tarball
<jmd>I still don't see how converting to sha256 is safer if you have already relied upon sha1
<jmd>suppose the mitm has crafted a special version which has the same sha1, then if I calculate the sha256 and propogate that, I'm giving a false impression of extra security.
<viric>if only you have the mitm, others using guix will find that out
<viric>so you think that propagating the sha1 is safer? :)
<jmd>No. But then when somebody sees sha1, they at least know there is only a modicum of safety.
<viric>but if you weren't mitm, you are making things safer for others
<viric>than without sha256
<viric>and if you were, others may find it out quickly
<jmd>Anyway I dunno what the upstream was thinking here. They publish a sha1 and pgp sign that.
<viric>you can write a comment over the sha256 on your source for that
<jmd>why didn't they simply pgp sign the sha1
<viric>has anyone ever faked sha1 test already?
<jmd>I read somewhere that it has been done.
<civodul>jmd: the pixman failure appears to happen on i686 yes :-/
<civodul>not sure whty
<civodul>jmd: to get the sha256, use 'guix download':
<jmd>civodul: Thanks for the confirmation.
<jmd>I changed it to version 0.32.4 and it works fine for me.
<jmd>I'm just rather uncomfortable with blindly cut and pasting the sha256 like that, for reasons I've just discussed with viric.
<civodul>jmd: great, feel free to post the patch that upgrades pixman, if that solves the problem
<civodul>regarding pasting the sha256, you do that only after checking that the package with that hash is genuine
<civodul>often there's an OpenPGP sig to verifyt
<civodul>sometimes there's just a hash
<jmd>That's the problem.
<jmd>I can download the package, and check that its genuine.
<jmd>But how do I know that the package which guix downloads is the same as the one I downloaded?
<jmd>So far as I can tell guix doesn't keep the original tarball.
<civodul>recipes include a hash, and Guix makes sure the tarballs have that hash
<jmd>I've just started a guix package --install
<jmd>and instead of downloading xorg.server it is building it.
<jmd>I expected the substituter to download it from hydra
<jmd>Oh maybe that's because I patched pixman ?
<mark_weaver>jmd: there is a lot of software whose upstream doesn't provide digital signatures at all.
<mark_weaver>some important software, in fact.
<mark_weaver>still, I think there is a tremendous benefit to us providing secure hashes, even in those cases.
<mark_weaver>it ensures that everyone is getting the same source tarball
<mark_weaver>and thus if some of them look at the source code, or observe the behavior of the package, their observations will be valid for all the other people using guix.
<mark_weaver>it also means that mitm attacks are much more likely to be detected by someone, unless *everyone* is affected by the same mitm.
<mark_weaver>already, we've detected a few cases where upstream changed a tarball without incrementing the version number.
<mark_weaver>however, having said all this, I do agree that we need to convince upstreams to keep better security habits, and to sign everything with a key that is at least somewhat connected to a well-established web-of-trust.
<civodul>jmd: probably because you modified pixman, yes
<jmd>Achhh! This pangox vs. gtkglext business is an abomination.
<jmd>Is it possible to specify a git revision as a download source ?
<civodul>in general we avoid packaging unreleased software
<civodul>and there's currently no way to specify a git repo + rev
<civodul>hmm mit-krb5 fails because of a test that hangs:
<jmd>civodul: I see that too.
<jmd>100% CPU
<jmd>Is there any way to avoid the zillions of lines like:
<jmd>downgrading to read lock on `/usr/local/var/nix/temproots/7484'
<jmd>acquiring write lock on `/usr/local/var/nix/temproots/7484'
<jmd>What does this mean:
<jmd>guix build: error: build failed: derivation `/nix/store/0hm3an385mmaxplkn3x7h59ayd4vx0w8-2.90.8.tar.bz2.drv' has incorrect output `/nix/store/1v671k6rpy96a6zq42b4mi6s3nhr7ar8-2.90.8.tar.bz2', should be `/nix/store/5xq51x6sym0952s63pi98h7ni01bm3f4-2.90.8.tar.bz2'
<jmd>How does it know that the one thing ought to be the other ?
<mark_weaver>jmd: why is there no package name in there?
<jmd>It doesn't make any difference if I put one in.
<mark_weaver>I've never seen that error message, but my first guess would be that the hash of the .tar.bz2 file didn't match what was listed in the package definition.
<jmd>That was my first idea.
<jmd>But is seems to occur before even the package is downloaded
<mark_weaver>can you show me the package definition?
<mark_weaver>you need to put the expected hash of the source tarball on line 11
<mark_weaver>use "guix hash <filename>" to compute the hash string that it will expect.
<jmd>I know that. But this is a different issue.
<jmd>The file isn't even getting downloaded.
<mark_weaver>I don't know that it will even try to download the file with an empty hash string.
<jmd>So Catch 22
<jmd>I can't download it, until I know the hash. And a I can't know the hash until I download it.
<mark_weaver>you can use "guix download <url>", or wget for that matter.
<jmd>Oh ok.
<jmd> seems to be unresponsive
<jmd>or very slow.
<jmd>In xorg.scm I see this comment:
<jmd>;; non-free license
<jmd>;; (define-public xf86-video-dummy
<jmd>I cannot see any license notice in the source for that package.
<jmd>So I presume it is under the same licence as everything else on
<civodul>jmd: i think the "downgrading read lock" stuff is when you run the daemon with --debug, or the clients with something equivalent
<civodul>you don't see them by default
<civodul>jmd: for xf86-video-dummy, you'd have to check with Andreas, who took care of that
<civodul>no license notice means non-free by default
<davexunit>hey civodul, working on the SDL thing. so the idea was that we would explicitly link against libxext.
<davexunit>I can't quite remember the configure variable for that
<davexunit>"LDFLAGS=-lXext" I think
<civodul>davexunit: yes, LDFLAGS=-lXext
<zacts>(when you aren't busy, I don't want to interrupt) what counter arguments do you guys have for: ?
<jxself>"Never mind that this breaks the FHS"
<jxself>The FHS is mostly there for compatibility with proprietary programs anyway, right?
<civodul>well yeah
<jxself>And standards are there to serve us, not the other way around, so only adopt it if it makes sense.
<civodul>those who insist on it are often interested in proprietary programs
<civodul>zacts: i think there have already been rebutals by the Nix folks back then
<civodul>but anyway, look at the docs, and judge by yourself ;-)
<zacts>just curious.. I'm still totally interested in guix
<civodul>sorry, i didn't mean to sound harsh or anything
<zacts>and once I finish my final paper for school, I hope to install it and port chibi (scheme)
<zacts>eek! it is an indefinite pronoun I think..
<zacts>I hope to install guix and port chibi (scheme).
<civodul>heh cool
<civodul>for myself i found the initial papers by Eelco Dolstra very demonstrative and compelling
<davexunit>I pulled master. so much downloading going on from the core updates merge.
<zacts>oh neat!
<davexunit>hopefully will be done soon, I want to build sdl!
<civodul>yeah, it's too slow
<davexunit>I already have SDL installed in debian, aside from uninstalling it, how can be I certain that I am using guix's copy of SDL and not debian's?
<davexunit>s/can be/can I be/
<zacts>my guix build on debian 7.2 totally failed for me last night
<zacts>I'm now trying parabola/arch
<civodul>zacts: please report any problems you have; it could be an actual bug, as incredible as it may seem ;-)
<civodul>davexunit: check with ldd, check the value of $LD_LIBRARY_PATH, etc.
<civodul>you can also attach gdb to the running process and it will list the shared libraries that are loaded
<civodul>or use pldd, even