IRC channel logs

<zacts> http://nopaste.info/03a51a2296.html

<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 - http://dpaste.com/1480960/

<jxself>It's important to be able to laugh at yourself...

<zacts>yeah

<zacts>ok

<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>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

<zacts>darn

<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>

<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>safer?

<viric>this way was trendy in nix.

<viric>:)

<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': http://www.gnu.org/software/guix/manual/guix.html#Invoking-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: http://hydra.gnu.org/build/28786

<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>

<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>??

<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?

<jmd> http://pastebin.ca/2478813

<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>hydra.gnu.org 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>

<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 x.org

<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>LD_PATH="something"

<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: http://lists.debian.org/debian-devel/2008/12/msg01027.html ?

<jxself>"Never mind that this breaks the FHS"

<jxself>Meh.

<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>exactly

<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>coolio

<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

IRC channel logs

2013-11-24.log