IRC channel logs


back to list of logs

***drewc1 is now known as drewc
<bavier>I have a package that has a "--with-debugging" option which then includes a bunch of run-time checks, but I'd also like to provide a build with that option turned off. Would I need to define another guix package, or could I somehow make use of the "out" and "dbg" outputs?
<jmd>My guix database is completely messed up. How do I clean it and start over?
<bavier>jmd: the database is in ${localstatedir}
<bavier>I think if you delete that you can "start fresh"
<bavier>that directory also contains users profiles some other things though; it might not be necessary to delete everything in it
<jmd>Too late!
<bavier>jmd: sorry! :/
<jmd>Achh haven't the hydra problems been fixed yet?
<bavier>I haven't been able to get substitutes for some time now
<civodul>hey there
<civodul>bavier: congrats on OpenMPI
<civodul>a big one, i guess
<civodul>bavier: BTW, we generally avoid the phrase "open source", as you may know ;-)
<civodul>so i think the synopsis & description should just s/open source//g
<civodul>(we could use "free", but since every package is free, it doesn't convey anything)
<bavier>civodul: for sure
<bavier>I'll make that change
<civodul>cool, thanks :-)
<bavier>thanks for the catch :)
<bavier>btw, what do you think about the "-openmpi" suffix I used for the new petsc packages? I wanted to allow users the choice of whether to incur a dependency on mpi or not.
<civodul>that makes sense to me
<civodul>though i'm not a petsc user
<jmd>civodul: When will hydra be reliable again?
<civodul>it's not so bad i think, but yeah, there's a bug hiding in "guix offload" :-/
<civodul>i wanted to let it rest for a while
<civodul>i had spent too much energy in it at some point
<civodul>but yeah, i should get ready to dive into it again real soon now
<civodul>jmd: what problems did you have, though?
<civodul>currently for master it's very green:
<jmd>I just always get 'not responding' errors and have build everything locally.
<bavier>looking through some of the failure logs, I notice that my derivation hashes done't match up with hydra's in many cases. Is that to be expected?
<civodul>jmd: but you're using Guile 2.0.5?
<civodul>bavier: the hashes in the file name?
<civodul>of the hashes of the contents?
<bavier>civodul: e.g. looking at the perl-tk failure log, I see hydra using /gnu/store/mbwqk...-perl-5.16.1/bin/perl, but when I build perl-tk (which incidentally doesn't fail) I see /gnu/store/24zq-perl-5.16.1/bin/perl being used.
<civodul>bavier: the output file name (not the .drv!) depends only on the inputs
<civodul>that includes the system type
<civodul>thus, on x86_64-linux machines, the output file name at a given point in git history is fixed
<civodul>on x86_64 with current git, Perl is /gnu/store/24zqczrfsvz4y70byvlbiqsc7f8y2f17-perl-5.16.1
<civodul>on i686, it is /gnu/store/mbwqklzinpzcr7rvphd34ic7v9161fgz-perl-5.16.1
<bavier>ah, I see, that's what I expected, I just forgot about the system type
<bavier>I guess now is that time to start playing with cross-compilation in guix!
<civodul>is it? :-)
<bavier>at one point I had dreamt about porting guix to the ben nanonote
<civodul>aah, fun
<civodul>viric did something like that with Nix
<bavier>oh? cool
*civodul is trying to get something that boots, does all the proper file system mounts, fsck, etc.
<civodul>debugging that is a bit painful