IRC channel logs


back to list of 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>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>will guix use dmd, or systemd?
<zacts>(hopefully not the latter)
<atheia>g'morning all.
<civodul>Hello Guix!
<phant0mas>hello civodul
<davexunit>hey #guix
<davexunit>has anyone here heard of gitian?
<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:
<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>Target: x86_64-unknown-linux-gnu
<phant0mas>shouldn't it normally refer to /gnu/store/nkrr16lw55p75483z2an0c67nnqdm4l5-binutils-cross-i686-pc-gnu-2.23.2
<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.
<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
<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?
<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>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>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