<tadni`>Anyways, hopefully this turns out to be a non-issue in even the shortrun. My deemed assignment from Ludo, I more or less resigned from the other day -- but I am officially now, because I have finals week starting tomorrow.
<tadni`>But depending on what RMS says in the forseeable future, I can see this topic coming up in relative mass -- without any of my involment whatsoever.
<mark_weaver>the packages names are only used for purposes of the UI, e.g. "guix package", "guix build", etc. for purposes of dependency evaluation, etc, the package objects themselves (bound by variable names) are used.
<Sleep_Walker>so I can't have two packages as dependency candidates unless I do some extra care
<mark_weaver>I'm not sure what you mean by "dependency candidates"
<mark_weaver>in the 'inputs' field, in an entry like ("gnupg" ,gnupg), the string "gnupg" there is only used to reference the input from within the build phases, e.g. (assoc-ref inputs "gnupg"). the ,gnupg is what actually refers to the package object that will be used as an input, and that's a scheme variable reference.
<Sleep_Walker>in RPM I can define some symbols like notification-daemon
<Sleep_Walker>then, some packages can require notification-daemon without really caring, which one it will be
<mark_weaver>in guix, every build input is precisely specified. not only what package and what version of that package, but also the precise inputs used to produce those inputs, the compiler used, all the way back to the bootstrap. it's needed to achieve our goal of purely functional, reproducable builds.
<mark_weaver>however, what you *can* do is to create a function that maps package objects to other package objects.
<mark_weaver>so then, instead of (define foo (package ...)), you can do (define (foo qt) (package ...)) and then 'qt' can be used as an input to the package object, but here 'qt' refers to the local argument passed to 'foo'.
<mark_weaver>'cross-gcc-arguments' takes 'target' and 'libc' as arguments, where 'target' is a string and 'libc' is a package.
<mark_weaver>sorry, 'cross-gcc' is a better example. that actually returns a package :)
<mark_weaver>and for an example of these being used, see 'ath9k-htc-firmware' in gnu/packages/firmware.scm. one of the inputs is ("cross-binutils" ,(cross-binutils "xtensa-elf"))
<Sleep_Walker>mark_weaver: thanks, I understand the reasoning, but I'm not sure if it doesn't bring complications with maintainability of package definitions
<mark_weaver>Sleep_Walker: well, agreed. I recommend asking civodul about this later, as he likely has a better answer for you.
<Sleep_Walker>interesting POV, I have to dig into those definitions and think about that
<mark_weaver>Sleep_Walker: out of curiosity, what package and input did you want to allow multiple candidates for?
<mark_weaver>another example worth looking at is 'emacs' vs 'emacs-no-x-toolkit' in emacs.scm
<mark_weaver>although in that case, it is done by having 'emacs-no-x-toolkit' inherit the 'emacs' package and make some changes to it. in practice, that's usually how we handle multiple variants (or versions) of a package.
<tadni`>Oh man, a "GNU Carol".* That punny greeting must have made no sense, this morning...
<nkar>sneek: later tell civodul ocaml's testsuite passes in /tmp. any idea why it timeouts while building as usual? do I need to increase the time before the exception is raised or something?
<Sleep_Walker>mark_weaver: good morning, sorry, I somehow fall asleep :) but I have logs so not a single line was wasted, thanks again for your time
<Sleep_Walker>I'm not currently interested in other than understanding Guix' specifics
<Sleep_Walker>but I have for example one Qt application with sources long time gone which runs only with some (old enough) versions of Qt, but I don't want to force other application to use old version as well
<rekado_>I installed guix-0.8 from the tarball, followed the instructions on setting up the guix-daemon and tried installing powertop as my first package.
<rekado_>now I get this error: guix package: error: build failed: failed to set up the build environment for `/gnu/store/vbcm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv'
<rekado_>BTW: it seems that the manual doesn't mention the initial setup required for per-user profiles. I mkdir -p /usr/local/var/guix/profiles/per-user/rekado only after an error message prompted me to do so.
<rekado_>I also had to chgrp /gnu/store after creating the guix-builder accounts; this was not mentioned in the manual, but an error message told me that this was required.
<iyzsong>ah, yes, I remembered have to create the per-user dir too.
<rekado_>building path(s) `/gnu/store/c5cs53y3j5vkvvshxn9x0ms9dgjm5vhf-guile-bootstrap-2.0' killing process 10189 guix pull: error: build failed: failed to set up the build environment for `/gnu/store/vbcm1mibrsc2j4fnyhskdbwzshs07fs6-guile-bootstrap-2.0.drv'
<rekado_>I get this after a long list of derivations
<rekado_>Also, for every guix command I run I see this:
<tadni`>But with a stable release, we would have to have several different versions/releases in the long term.
<davexunit>I don't know if the system configuration will need to know such details
<davexunit>you would just install that system using a long-term-support version of guix and that would be that.
<tadni`>davexunit: Would it update each release, automatically? Like say we have a 2016 release of stable, when the 2017 version comes along does the whole system update -- or do you have to manually specify such a thing?
<davexunit>I imagine that you would just guix pull and run the package updater.
<davexunit>--update? I don't have a guix system in front of me to check
<tadni`>I'd like (package-repo 'stable_2015) or whatever in your config.scm, just for the fact that if you run Guix pull and leave your computer, you don't accidently end up with the latest version, if you explicitly wanted such a thing. It's not a huge deal, since we can rollback, put it's still a decent visual que. :^P
<tadni`>Maybe people won't check there config.scm, so that's cemented in their heads though.
<davexunit>keep in mind that each user can use a different version of guix :)
<tadni`>davexunit: I mean, sans the (operating-system) s-exp, is there anything config.scm does that an underpriveleged user could not?
<tadni`>We could specify at least what packages each user has in their profile.
<tadni`>I guess we could declare a specific user module, just for a config.scm that is relevant to non-root users.
<davexunit>user profiles are currently completely separate.
<davexunit>I sort of want a way to specify what each user should have in their profile. that way I could create a machine with a user dedicated to running a web server or something, and the packages are only installed for that user.
<tadni`>davexunit: Is this what I am suggesting? To write a "guix user reconfigure ~/.config.scm" that one could specify certain packages in a regular user profile and two, run local services.
<tadni`>It's great to see such efforts are being done by our spiritual predecessor and minor, technical predecessor.
<tadni`>This class of OSes configuration, really is something neat and something I haven't seen in mass outside of GNU Distro and NixOS.
<iyzsong>Guix is like as OS framework for me, with many things to be discover :)
<tadni`>I haven't played with NixOS enough to know if there are like tools on that side of things, but the fact that one can produce customs usb images and potentinally even *.iso in the future due to the efforts of zdavis, really does place GNU Distro more into a distribution Platform -- than a formal distribution for me.
<Tsutsukakushi>like if i want to compile two programs that depend on x will x be compiled twice or just for the first programs, assuming they don't need any special flags for x or they require the exact same flags
<civodul>no you're right, there's a problem with how the version number is determined
<nkar>civodul: it seems sneek didn't send you my question: ocaml's testsuite passes in /tmp. any idea why it timeouts while building as usual? do I need to increase the time before the exception is raised or something?
<civodul>nkar: no, we'd need to look at the faulty test to see if it's doing i/o, networking, or whatnot
<civodul>it could be anything, but we might have clues by looking at the test