IRC channel logs


back to list of logs

<rigelk>mark_weaver: still here ?
<rigelk>ok, great :) i was wondering if typing `guix package -i package` implied the building of the package itself if no binary existed, and if it was the same for the dependancies.
<mark_weaver>yes, it should build package and all dependencies that aren't already in your store, before installing it in your default profile (~/.guix-profile)
<rigelk>i'm trying to install the binary toolchain (i stopped compiling ; it took too long for a first try), so i guess it's not what i should type.
<mark_weaver>the server that hosts the binaries was down for maintenance last I heard. I don't see how you can get around that.
<rigelk>oh, damn, i recall you told me already about it.
<mark_weaver>sorry, bad timing for you, I guess. hopefully it will be back up soon.
<rigelk>anyway, i have to sleep and i can let the computer compile while sleeping ;)
<mark_weaver>that's what I do :)
<mark_weaver>(and leave it going in the background while doing other things)
<rigelk>I can only do the former ; I have an atom proc after all :/
<mark_weaver>I have a YeeLoong with the Loongson 2F processor, so I can sympathize. I don't know how they compare, but in my case it takes multiple days to do a full bootstrap from source.
<rigelk>btw, are there guys working on the signature of packages within guix (what you told me a few hours ago) ? This issue interests me.
<mark_weaver>yes, some of the features are already there, and the missing bits are being worked on. there's been some discussion in guix-devel about it.
<rigelk>Multiple days ? :x Wow, not long ago i thought compiling libreoffice would be the longest thing...
<rigelk>ok, glad to hear that :) if you need any help, just ask.
<Guest47636>good morning guix
<phant0mas>mark_weaver: I went to sleep yesterday
<phant0mas>good morning
<phant0mas>mark_weaver: anything on my yesterday question? :-)
<mark_weaver>phant0mas: three possible suggestions: (1) the option may not be needed, because of the CPATH environment variable which will already be set; (2) you could patch the configure script to allow the two headers directories to be specified separately (I'd guess it is just used to make a -I option; (3) you could add a phase before configure that copies the includes from both dirs into one dir.
<rigelk>hi #guix :)
<ph4n70m4s>mark_weaver: it seems you were right, I didn't even need to pass the flag, it seems it found both headers
<ph4n70m4s>hi rigelk
<ph4n70m4s>but I am getting an error perl not found from mig, I am starting to think I forgot something there...
<rigelk>simple questions : first, as i read the manual i find it very disturbing not to have a reminder of package definition in the "packaging guidelines" section ; may i add some ?
<rigelk>second, there are small doc files at the root of the guix folder, and i can't find their source ; it would be usefull to edit them as well (redundancy of info can be useful ;)
<ph4n70m4s>it seems I just had to put as an input to glibc perl
<ph4n70m4s>../sysdeps/mach/hurd/mig-reply.c:29: Error: incorrect register `%rax' used with `l' suffix
<ph4n70m4s>now let's see what that is
<mark_weaver>perl should probably be a native-input
<mark_weaver>(not a normal input)
<mark_weaver>rigelk: suggested patches for the manual are welcome
<mark_weaver>regarding the small doc files at the root: can you name them specifically? if you mean files like HACKING, README, and INSTALL, they are not generated. just edit them directly.
<mark_weaver>HACKING is in org-mode, so it is displayed somewhat cleverly in emacs by default. you can run M-x fundamental-mode to see what the raw file looks like.
<ph4n70m4s>mark_weaver: I placed it in native inputs, should have said that
<mark_weaver>ah, good!
<rigelk>thx for the info, mark_weaver, that's exactly what I needed :)
<rigelk>should dev always be done through a git checkout ?
<mark_weaver>I think so, yes
<rigelk>curiosity : does it make sense to package a lot of software at this stage of early dev of guix ?
<davexunit>rigelk: yes!
<davexunit>the more software there is packaged, the more attractive guix becomes.
<rigelk>ok, great :)
<rigelk>could someone please explain what a propagated-input is ?
<rigelk>something optional ?
<davexunit>a propagated input is an additional package that gets installed along with the package
<davexunit>so if package 'foo' had a runtime dependency on 'bar', you would make 'bar' a propagated input.
<rigelk>what's the difference with inputs, then ?
<rigelk>you mean a dependency of a dependency ?
<davexunit>inputs are build-time dependencies
<davexunit>they don't get propagated to the user's machine
<davexunit>but they are needed for building.
<rigelk>oh, i see. I thought the purpose of native-inputs :x So what about native-inputs ?
<rigelk>i thought it was*
<mark_weaver>davexunit: your description of propagated-input is not quite right.
<mark_weaver>normally, runtime dependencies don't need to be propagated-inputs
<mark_weaver>normally they can be just normal inputs.
<mark_weaver>also, you're wrong about inputs being build-time dependencies.
<davexunit>mark_weaver: wow. I have a major misunderstanding of things.
<davexunit>rigelk: sorry for telling you things that were totally wrong!
<mark_weaver>native-inputs are dependencies that need to be _run_ at build-time, so if you're cross-compiling, they need to be able to run on the build machine, not the target machine.
<mark_weaver>inputs are dependencies that need to be run/accessed at runtime, so when cross-compiling they are meant to run on the target machine.
<mark_weaver>propagated-inputs are like inputs, except that when you install a package into your profile, the propagated inputs are also installed in your profile.
<mark_weaver>this is not usually needed for runtime dependencies, because in most cases the built package includes hardcoded paths directly to the inputs.
<davexunit>oh I see.
<davexunit>now, when is the right time to propagate?
<mark_weaver>however, sometimes that's not enough, for example when a C header file from one package includes headers from another package.
<mark_weaver>in that case, when a user is building things outside of guix, things should work even if the only place their compiler is looking for header files is in ~/.guix-profile/include/
<mark_weaver>so for example the header files for gpgme include gpg-error.h, which is in a different package "gpg-error".
<mark_weaver>so gpgme makes gpg-error a propagated input.
*mark_weaver goes afk for a while
<davexunit>mark_weaver: thanks for the explanation.
<rigelk>wow. i was just about to send a patch with wrong things, then ^^
<davexunit>rigelk: sorry!
<davexunit>I really thought I sort-of understood things!
<rigelk>well, i'm a parsec behind both of you, so it doesn't matter ;)
<rigelk>davexunit: do you mind explaining me how one posts a patch to the mailing list ?
<rigelk>with 'git send-email', it seems ?
<davexunit>rigelk: you could do that, though I do it a bit differently.
<davexunit>did you already use git format-patch ?
<davexunit>maybe I should use git send-email, but I just write an email to with the subject line: [PATCH] - <commit message goes here>
<davexunit>in the email body I briefly describe the patch and then add the patch as an inline attachment to the email
<rigelk>Hum okay :) I'll do that for now, as I don't have much time. 'gotta harass mark_weaver again :p
<rigelk>Thx davexunit :)
<davexunit>you're welcome, rigelk.
<davexunit>sorry about the misinformation earlier.
<rigelk>no problem, really.
<mark_weaver>fwiw, I do the same thing davexunit does.
<mark_weaver>the important thing is that we have the output of 'git format-patch'.
<mark_weaver>which makes it very easy for us to add it to the repo.
<rigelk>sure, i got that.
<mark_weaver>davexunit: no worries, I appreciate you taking the time to help answer questions :)
<rigelk>guys, do you know when hydra will be back on ?
<civodul>sriharsha: i'm still getting occasional network failures when talking to
<civodul>despite the hard limit on the number of simultaneous SSH connections, etc.
<mark_weaver>hi civodul!
<civodul>hey, mark_weaver
<mark_weaver>rigelk is eager to try out guix, but is thwarted by the lack of binary substitutes (and a slow machine). is there a solution for him?
<mark_weaver>(he started to bootstrap from source, but got impatient on his atom processor :)
<rigelk>yeah, it's been 21h compiling already :s
<civodul>actually i'm planning to restart Hydra today, in the hope we won't have to many networking issues with the build machine
<rigelk>mark_weaver: I might as well work on the gnunet guix extension, if it's to have an alternative :)
<rigelk>civodul: what composes hydra ?
<mark_weaver>this is probably better discussed on the list
<mark_weaver>, that is.
<mark_weaver>it's not a quick answer, and the answer should be available for all to see
<rigelk>I know ; I've already documented myself actually, I just need to get in touch with the gsoc student already engaged with the subject.
<civodul>rigelk: i don't think there's a GSoC candidate on that topic
<rigelk>civodul: i will apply, certainly. Should i get in touch with someone in particular, then ? I mean, before posting to the mailing-list.
<civodul>rigelk: no, please post to the list first
<civodul>send us your thoughts, etc.
<rigelk>sure. I've juste sent a patch for the doc for now ^^'
<Steap>I guess that /etc/services thing will not get merged in Python :)
<civodul>Steap: /etc/services is not the problem per se; the problem is assuming in the test suite the availability of a given service
<Steap>civodul: I see no way of fixing that properly
<civodul>the argument should be along the lines of: you can't assume service "http" (say) to be available on the machine; thus, any missing-service error must be handled gracefully
<civodul>in Guile test cases are marked as "unresolved" in such cases
<Steap>civodul: how are they supposed to test getservbyname then ?
<ph4n70m4s>civodul: going well with the glibc packaging for hurd
<ph4n70m4s>I am getting an error about a incorect register, but I have to talk about it with the hurd guys
<ph4n70m4s>btw patches won't work with git fetch, so I applied a patch the old way
<ph4n70m4s>after getting some advice from mark_weaver
<ph4n70m4s>also I will have to make a package of libpthread in order to compile together with glibc as an addon
<ph4n70m4s>we only need to download it inside the building folder of glibc and then we configure though it
<ph4n70m4s>we configure it through the glibc building process
<mark_weaver>civodul: ph4n70m4s reports that 'patches' doesn't work in a 'git-fetch' origin.
<mark_weaver>ph4n70m4s: he also found that he had to replace the default 'unpack' phase, apparently because it tried to unpack a non-existent tarball.
<mark_weaver>civodul: ^
<mark_weaver>ph4n70m4s: you can use an 'origin' form as an input.
<mark_weaver>I don't know if that's helpful here or not.
<ph4n70m4s>Can I use origin as an input? Great :-) !!
<mark_weaver>if it just needs to be unpacked in a subdir, that might be best.
<ph4n70m4s>that's exactly what we need
<mark_weaver>so then (assoc-ref inputs "foo") will give you the name of the downloaded file (tarball?)
<mark_weaver>and you could add a phase that untars it in the correct place.
<mark_weaver>ph4n70m4s: for example, the 'net-tools' package in linux.scm has an origin as an input, though in that case it's a patch.
<ph4n70m4s>libpthread will need git fetch as well
<mark_weaver>hmm, I don't know what (assoc-ref inputs "foo") will point to when the "foo" input is from git-fetch.
<mark_weaver>maybe a directory?
<ph4n70m4s>yes it will point to a directory
<ph4n70m4s>named git-checkout or something, I think
<mark_weaver>ah, probably a directory in the store.
<mark_weaver>so you can't modify anything in that dir.
<mark_weaver>(these are educated guesses; I'm not sure)
<mark_weaver>so you either build in a separate build dir, in which case a symlink to it is probably okay, or copy it.
<mark_weaver>if the primary source code you're building is from git-fetch, then I'd guess it should be sufficient to just create a build dir, chdir to it, and then run the configure script in the (immutable) source dir in the store.
<mark_weaver>I guess the default 'unpack' and 'configure' phases could check to see if the source is a directory, and if so, do the right thing.
<civodul>mark_weaver: i think 'patches' works on git-fetch origins, but only in core-updates (commit 3ca00bb51e3ff906a700b6925e0ce81558c8c469)
<civodul>ph4n70m4s: ↑
<mark_weaver>civodul: ah, okay. it can't be easily fixed in master? (without rebuilding everything)
<ph4n70m4s>should I change branch and work on that one?
<mark_weaver>I don't think so.
<mark_weaver>but when core-updates is merged, we can simplify things a bit.
<mark_weaver>(in your recipes)
<civodul>mark_weaver: no
<civodul>but we should merge core-updates soon
<civodul>and that raises the question of Guile 2.0.10 :-)
<Steap>civodul: when are we going to merge core-updates ?
<mark_weaver>I think the hope is to release 2.0.10 before that happens.
<mark_weaver>Guile 2.0.10, that is.
<civodul>we'll see