IRC channel logs

<davexunit>I have returned.

<davexunit>hydra is sooo much more responsive now.

<davexunit>the web interface, anyway.

<jxself>Oh yes. It does seem to be.

<jxself>Must be the added memory. Thanks, nully.

<davexunit>so, I have figured out how to build all the derivation inputs of a package, but not the package itself.

<davexunit>now, to figure out how to build an environment from that.

*davexunit can't figure out how to acquire the environment variables that the nix daemon sets when building

<davexunit>derivation-builder-environment-vars doesn't yield the same things that are set in the build environment. :(

<tadni_>Is hydra down?

<davexunit>nope

<tadni_>davexunit: My new guix install on my other fedora install is pulling everything from source automatically.

<davexunit>I'm guessing you've already made sure that hydra's pubkey has been authorized?

<tadni_>davexunit: Do you need to do this now, even on a non GNU Distro install?

*tadni_ doesn't even have a guix in his /gnu/store currently.

<davexunit>you always need to authorize hydra

<tadni_>davexunit: I'm not needed to before, and I had subsitutes enabled.

<tadni_>And I've had guix on like 5 host machines.

<davexunit>hmm

<davexunit>well, I can pull substitutes from hydra without issue

<davexunit>so not sure what is going on

<tadni_>Hrm, well I guess I need to figure this out by this Friday -- or I guess I won't be doing guix hackathon this year... seeing my workstation now doesn't build the latest guix either.

<davexunit>try using guix archive --authorize

<davexunit>guix archive --authorize hydra.gnu.org.pub

<davexunit>from the root of the guix source tree

<davexunit>the standalone guix installation might automatically authorize hydra, I remember it not doing that, but it could very well have been changed.

<tadni_>Shouldn't it be "guix archive --authorize < hydra.gnu.org.pub?

<davexunit>heh, yeah

<davexunit>good eye

<tadni_>"guix archive: error: s-expression does not denote a public key"

<tadni_>Hrm, the file is empty... hydra.gnu.org.pub.

<tadni_>Weird.

<davexunit>shouldn't be.

*tadni_ it recloning.

<tadni_>is*

<tadni_>davexunit: Weird, must have changed in the past 3 months at some point.

<tadni_>Thanks though!

*tadni_ is hopefully doing atleast clisp at the hackathon, maybe stumpwm.

<davexunit>yw

<davexunit>okay, so the set-paths phase of the gnu build system is what is setting the env vars I was wondering about.

<davexunit>but since I'm not running the builder and not assuming that the package is using the gnu build system, I'm not sure what I can do with that information.

<Tsyesika>hmm i can't do a guix pull it errors saying "guix pull: error: symlink: No sch file or directory"

<Tsyesika>i'm passing the verbose flag and it's not giving me anything more useful (such as which file)

<alezost>Tsyesika: do you have ~/.config directory?

<alezost>Tsyesika: if no, create it and try again

*Tsyesika attemps :P

<Tsyesika>seems to be working

<davexunit>morning guix!

<Tsyesika>afternoon davexunit

<davexunit>making a bit of progress on guix environment.

<Tsyesika>:)

<Tsyesika>i'm doing a guix pull

<davexunit>in doing so, I realized that nix shell is more composable than I thought.

<Tsyesika>seems to be working

<davexunit>by default, it spawns a new $SHELL, but you can instead use the --command flag to run a different program in the environment. so, guix environment doesn't seem to one-up nix shell after all.

<Tsyesika>hopefully by tonight i'll have something packaged X

<Tsyesika>* xD

<davexunit>yay!

<Tsyesika>yay guix pull finished succesfully

<davexunit>yay again!

*Tsyesika is doing a guix system reconfigure

<davexunit>did you guix package -i guix ?

<davexunit>so meta

<Tsyesika>no :P

<Tsyesika>hm i wonder why it's downloading qemu

<davexunit>we have some weird dependency there still.

<davexunit>from when guix could only be used as a VM

<davexunit>don't know the details of it.

<davexunit>hmm why is guix downloading the source code to things like gcc when I'm building the input derivations of a package?

<davexunit>it should just substitute the binary...

<davexunit>wow, exporting a function from (guix build utils) causes rebuilds of all packages! gah!

<davexunit>I understand why, now. different build code changes the hashes.

<davexunit>took me awhile to realize it.

<davexunit>has a mostly working 'guix environment' script

<davexunit>hmmm how to get the native search paths from a derivation...

<davexunit>from what I can tell, there's no reliable way to pull the necessary search paths out of a derivation

<davexunit>they are part of the builder script, which could be any scheme code.

<davexunit>and I'm unable to obtain all of the packages necessary for a build because of implicit inputs.

<davexunit>if I could only get complete set of inputs for any package, I could simply iterate over their native search paths.

<davexunit>or get a full set of search paths from a derivation...

<davexunit>from what I've read of the nix-shell source, they assume that a phase called 'setup' exists and run it in the new shell.

<davexunit>I think they can just do that because the phases are bash functions.

<davexunit>in guix, there need not even be phases, the trivial build system doesn't have any. there's just a builder script.

<davexunit>I guess I could avoid all of this pain if implicit inputs could be queried somehow. Although, implict inputs aren't constant for a build system. the python build system could use any version of python. This is a tough problem...

<usrnix>Is there a typical package template file for making packages with guix?

<davexunit>no, not really.

<davexunit>just look at the packages in gnu/packages/*.scm for examples

<usrnix>Is the copyright at the top of the scm files of the people who edit the file or of the guix project? different packages have different lists

<davexunit>the people who have contributed to that file

<usrnix>Oh, that might get long :P

<usrnix>How do I base32 something?

<jxself>guix hash /path/to/thing

<usrnix>I guess I should install guix then

<usrnix>Where can I get the public key for the guix package?

<mark_weaver>it might be in the GNU keyring at http://ftp.gnu.org/gnu/gnu-keyring.gpg

<mark_weaver>or use "gpg --recv-keys" to fetch it from a keyserver

<usrnix>mark_weaver: That worked thanks - wow 374 keys

<philed>What's the general recommended way with things like Ruby and Ocaml libraries? Just use things like opam/rubygems, or package them in guix?

<davexunit>philed: package them in guix.

<philed>davexunit: Cool.

<Tsyesika>I'm back!

<Tsyesika>ugh it's still compiling

<Tsyesika>xD

<jxself>It may takes days.

<jxself>Weeks even. Maybe months.

<jxself>Or possibly years.

*jxself makes an evil laugh

<jxself>:)

<Tsyesika>:P

<davexunit>I made what I thought was a trivial change to guix's source code earlier today and it triggered a rebuild of all packages :x

<Tsyesika>i'm sure rebuilding my entire gentoo install didn't take this long

<philed>How long now?

<davexunit>guix probably has more overhead, but also could be some unoptimized bits.

<davexunit>heh, looks like nix will be upgrading from perl https://github.com/NixOS/nix/issues/341

<davexunit>everything will be c++, though.

<jxself>Why C++?

<jxself>Perl's awesome, right? :)

<davexunit>jxself: a lot of nix is already written in c++

<davexunit>the nix daemon, the part that guix uses, is c++

<jxself>The bug should be to go in the other direction. :)

<davexunit>I *hate* perl.

<davexunit>c++, though static, is an upgrade in my mind.

<jxself>Sshhh... :)

<davexunit>it at least makes things consistent. I've been reading the nix-build perl source code whilst I've failed to implement 'guix environment'.

<jxself>Ohhh... I know: COBOL. :)

<jxself>'tis perfect. :)

*jxself gives up trolling davexunit

<davexunit>:P

<Tsyesika>it must be installing every package there is or something

<Tsyesika>it shouldn't take this long

<mark_weaver>davexunit: some of the files in guix/build/* are essentially implicit inputs to every build by default.

<davexunit>mark_weaver: yes, I learned that the hard way. ;)

<mark_weaver>heh, well, just revert the change and you should be all set again...

<davexunit>yup. that's what I did once I figured out what the culprit was.

<civodul>see the story about "code strata" under "G-Expressions" :-)

<civodul>davexunit: thanks for the detailed analysis for 'guix environment', BTW

<davexunit>civodul: thanks for responding so quickly. :)

<civodul>i think that should work, but i sympathize with all the headaches you've endured

<davexunit>I'm unsure if your suggestion will solve the problem completely, because from what I can tell, I will still be missing out on the search path specifications of implict inputs.

<davexunit>for example, python is an implicit input to the python build system, and it has the PYTHON_PATH search path.

*civodul scratches his head

<davexunit>yeah, it's perplexing.

<davexunit>here I was thinking it would be easy when I started. :P

<civodul>me too :-)

<civodul>so each build system augment the search path specs, indeed

<civodul>so these would be missing

<davexunit>yup

<civodul>"implicit inputs" are really a double-edged sword

<davexunit>I was thinking that maybe a build system should expose it's implicit inputs, but the implicit inputs can vary by package and by the type of build being performed.

<civodul>yeah

<davexunit>I guess that I will give nix a +1 for how trivial it was for them to add nix-shell.

<davexunit> https://github.com/NixOS/nix/commit/7f38087f35e6f74a73bfdb28da8acd8930565d51

<civodul>yes, but OTOH --search-paths is basically impossible to get

<civodul>search paths are not declarative in Nix

<davexunit>that's true

<civodul>anyway, that doesn't help us here :-)

<civodul>actually, would it be a problem to expose the implicit inputs of build systems?

<civodul>after all, python.scm explicitly refers to 'standard-search-paths'

<davexunit>they vary depending on the build being performed. the python build system may use any python package as implicit.

<civodul>oh but there's #:implicit-inputs and #:python, right

<civodul>grr

<davexunit>but yeah, ideally we'd be able to use the high-level package inputs.

<davexunit>we don't really know what the implicit inputs are until the derivation is made, and you have to inspect the builder source to figure it out.

<davexunit>and you can't go from derivation->package reliably.

<civodul>hmm

<civodul>of course there are hacks that could be done to get the result in most cases

<davexunit>yes, I've thought of some.

<civodul>but the design issue is still there

<davexunit>but the "edge" cases aren't all that edgy.

<civodul>heh

<civodul>i'll think some more but i can't think of any good solution so far

<davexunit>and yeah, the hack would just cover up the issue most of the time and then really screw someone over eventually.

<civodul>yeah :-/

<davexunit>okay. I'll think too, but I've exhausted all of my ideas.

<civodul>okay, sorry i don't have better news

<civodul>gtg

<davexunit>that's alright. see ya!

<davexunit>it will be solved eventually.

<Tekk_>is the download link for stable broken?

<jxself>Huh? 0.7 still exists: http://alpha.gnu.org/gnu/guix/

<Tekk_>oh, alpha?

*Tekk_ was looking on ftp

<zacts>Tekk_: guix is interesting isn't it :-)

<Tekk_>zacts: I have no idea

<Tekk_>I'm building a slackbuild of it now

<zacts>oh interesting, there is a slackbuild, or you are making a slackbuild for it?

<Tekk_>mkslack works on it

<zacts>Tekk_: I'm going to try out Sabotage Linux today

<zacts>oh nice

<zacts>I think it would be nice to allow for guix to build with the musl-clib as a user option

<mattl>does anyone have a Guix build I could easily run a VM, that's essentially ready to go? I think that might be an interesting next step, to allow the world to see a LiveCD or similar that boots up and lets you start installing things.

IRC channel logs

2014-09-21.log