IRC channel logs

<spacebat>I haven't been able to install anything with guix, each time it follows dependencies until it fails to find the gc tarball on boehm's website

<spacebat>perhaps I should be using guix from git instead of the 0.5 tarball

*ggrant` wonders how far 1.0 is away. We are nearing that 3-4 month point. :^P

<civodul>spacebat: yes, probably

<civodul>or run "guix pull"

<civodul>actually, you can also manually get the tarball with "guix download"

<civodul>and that will allow it to continue

<spacebat>guix pull gives: ERROR: In procedure put-bytevector: Wrong type argument in position 2 (expecting bytevector): #f

<spacebat>I think the 0.5 tarball is broken, or the setup instructions are, or the diagnostics are

<spacebat>I'll try again from git

<zacts>lo

<mark_weaver>greetings!

<zacts>what can I do to help with the 0.6 release, in terms of importing packages?

<mark_weaver>write recipes for packages you want that are missing :)

<zacts>ah simple I guess. :p

<zacts>lo

<zacts>will guix use dmd, or systemd?

<zacts>(hopefully not the latter)

<mark_weaver>dmd

<zacts>ok

<atheia>g'morning all.

<civodul>Hello Guix!

<phant0mas>hello civodul

<davexunit>hey #guix

<davexunit>has anyone here heard of gitian? https://gitian.org/

<davexunit>"Gitian is a secure source-control oriented software distribution method."

<davexunit>"Gitian uses a deterministic build process to allow multiple builders to create identical binaries."

<viric>sometimes, deterministic = completely unflexible

<mark_weaver>viric: huh? what do you mean?

<davexunit>jacob appelbaum (and the rest of the tor project) are using gitian for deterministic builds. he talked about it briefly in this speech: http://media.libreplanet.org/u/zakkai/m/free-software-for-freedom-surveillance-and-you/

<davexunit>so I wanted to make sure that the guix community was aware of the tool, in case we could use it or learn from it.

<viric>mark_weaver: I mean that it's easy to claim determinism, once you reduce flexibility or comfort. For example: install ubuntu, build X. Every time you do these two steps, the build will match.

<mark_weaver>actually, that's not true.

<viric>I agree, but did you understand me a bit more? :)

<mark_weaver>but indeed, any deterministic build process that starts with downloading many megabytes of binaries is not very helpful.

<phant0mas>for some reason while I target i686 I get this in the config.log

<phant0mas>COLLECT_LTO_WRAPPER=/gnu/store/z8qifq9172ad17a7mxg9w8jq51axwwqr-gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper

<phant0mas>Target: x86_64-unknown-linux-gnu

<phant0mas>shouldn't it normally refer to /gnu/store/nkrr16lw55p75483z2an0c67nnqdm4l5-binutils-cross-i686-pc-gnu-2.23.2

<phant0mas>?

<bavier>I can't build python-3.3.3 on my machine

<bavier>I'm getting, fairly deterministically, an "OSError: out of pty devices" when running the tests

<bavier>looks like hydra is doing ok with python...

<civodul>mark_weaver: has the daemon's --no-substitutes ever worked for you?

<civodul>it seems it's always overridden by the client's settings

<civodul>which enables it by default

<mark_weaver>civodul: :-(

<civodul>is that a "no"? :-)

<mark_weaver>I guess I don't know. it's possible that I simply never got any substitutes because there are none available for mips.

<civodul>yes, indeed

<mark_weaver>but I guess I've been leaving myself open to attack by the NSA this whole time :-(

<mark_weaver>(or anyone else who could intercept the connections)

<mark_weaver>well, if things get fixed now, I'll be glad of that at least.

<civodul>yeah

<mark_weaver>civodul: one thing though: I've also built things on my x86_64 machine, and I don't recall it ever telling me that was downloading substitutes.

<mark_weaver>but it's possible I simply wasn't paying enough attention.

<civodul>actually i think it was a false alarm

<civodul>i'm touching these things right now in my tree

<civodul>and apparently i'm doing it wrong

<mark_weaver>thanks for looking into this.

<phant0mas>it hasn't downloaded any substitutes here either, on my x86_64 machine

<civodul>phant0mas: you've been running guix-daemon --no-substitutes

<civodul>?

<phant0mas>yes

<civodul>ok

<phant0mas>I have a question, sending it to the list with some logs

<dfsdfds>civodul: A couple of days ago on mips64el, the substituter tried to download binaries while I was running the daemon with --no-substitutes. Adding --no-substitutes to guix package fixed the problem as far as I can tell. I was too busy when that happened, so I forgot to report it.

<dfsdfds>civodul: Unrelated: I'm trying to understand when source tarballs get downloaded. Does it happen before the build process starts (in a batch), or does it happen on demand (download, configure, make, install)?

<civodul>dfsdfds: about --no-substitutes: did you have Nix installed? i think that could happen if you had Nix installed, with Guix after commit 89faa5c

<dfsdfds>I'm thinking of an option that would change the download process, but I'm not yet convinced that it's a good idea.

<civodul>dfsdfds: re tarballs: downloads are just normal derivations

<civodul>so they get downloaded when they're needed

<civodul>change the download process?

<dfsdfds>Yeah, I think it may be a good idea to download everything before building stuff. Some people travel frequently, so they aren't always connected to the network.

<civodul>one could easily write a download-tarballs procedure

<civodul>just iterate over the package

<dfsdfds>Would you accept such a patch?

<civodul>*packages

<dfsdfds>civodul: wrt to --no-substitutes: Nix isn't installed on my system. However, I git clone'd it into nix-upstream before running ./bootstrap because ./bootstrap failed to do so for some reason (again, I was too busy to debug the issue).

<civodul>i think the problem is that it would be a very specific use case

<civodul>for instance, how do you choose what to download?

<civodul>and one can basically run "guix build -S emacs foo bar baz"

<civodul>which does exactly that

<civodul>dfsdfds: do report any such issues, even if the report is rough on the edges :-)

<dfsdfds>civodul: Well, I would definitely use it. I'm on a slow machine and don't have network access at work. So I'd prefer to fetch everything at home, go to work, and continue building there.

<civodul>it's better to have reports, otherwise we/i don't realize

<dfsdfds>That's why I'm reporting it right now.

<civodul>did you try "guix build -S"?

<civodul>i actually do that before i take the train and have hack time, like when going to FOSDEM :-)

<dfsdfds>civodul: I used it in the past, but it's not automatic (can't find a better word) enough.

<dfsdfds>civodul: I simply want to run guix package --install={foo,bar,baz}, then pm-hibernate at some point, and be sure that if foo, bar, baz were downloaded, the build process would resume.

<civodul>ok, i see

<civodul>it's not possible to do it this way currently

<civodul>what would be possible is something like "guix prefetch foo bar baz"

<civodul>which would be like "guix build -S foo bar baz" plus "-S all the prerequisites"

<dfsdfds>So, would we need to write a separate script from scratch? Is it that bad?

<dfsdfds>Can't the existing code be modified?

<civodul>well, it's the daemon that schedules derivations

<civodul>and it doesn't care if it's a download or not

<civodul>(doesn't even know)

<civodul>so it could be tweaked specifically for this use case

<civodul>but i'm not convinced it's a good idea

<dfsdfds>Ugh.

<dfsdfds>Why aren't you convinced?

<civodul>because that'd be a hack

<civodul>anyway, these are just random thoughts

<civodul>perhaps you could start a thread on the list?

<civodul>now i'm trying to remain focused on 0.6ish things

<civodul>(speaking of which, i'm happy with substitute signature checks!)

<dfsdfds>Okay, will do if I have something concrete. Just to clarify, the only way to achieve this is to patch the daemon itself, right?

<dfsdfds>civodul: WRT to the release, what are the remaining bits? Can I help somehow?

<phant0mas>civodul: did you have any look on my mail?

<civodul>dfsdfds: if you want it to be magic, probably

<civodul>but you should really post your idea, with example use cases

<civodul>wrt. the release, mostly mark_weaver's union.scm and the substituter/signature stuff

<civodul>i'll be looking at the latter

<dfsdfds>civodul: I've just realized that it may be better to have a separate script for that that you could pipe to guix package. After all you want to make sure that you actaully downloaded the needed sources before you leave.

<dfsdfds>s/that/so/

<dfsdfds>Okay, I'll post the idea.

<dfsdfds>civodul: Perhaps it's already solved by the -S option. Could you demonstrate how you usually use it?

<civodul>phant0mas: i guess no

*civodul doesn't scale so well :-)

<civodul>dfsdfds: typically before taking the train, i'd do a bunch of "guix build" and "guix build -S" to have enough stuff in the store

<phant0mas>civodul: take your time, I am looking into it so maybe I will find what's wrong

IRC channel logs

2014-03-27.log