IRC channel logs


back to list of 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?
<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>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
<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 <
<davexunit>heh, yeah
<davexunit>good eye
<tadni_>"guix archive: error: s-expression does not denote a public key"
<tadni_>Hrm, the file is empty...
<davexunit>shouldn't be.
*tadni_ it recloning.
<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>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>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
<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
<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
<jxself>It may takes days.
<jxself>Weeks even. Maybe months.
<jxself>Or possibly years.
*jxself makes an evil laugh
<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
<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
<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
<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.
<davexunit>I guess that I will give nix a +1 for how trivial it was for them to add nix-shell.
<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
<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>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>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
<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:
<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.