IRC channel 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 ?

<rigelk>yes.

<davexunit>okay

<davexunit>maybe I should use git send-email, but I just write an email to guix-devel@gnu.org 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 :)

<davexunit>:0

<davexunit>:)*

<rigelk>guys, do you know when hydra will be back on ?

<civodul>howdy!

<civodul>sriharsha: i'm still getting occasional network failures when talking to hydra.gnunet.org

<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>guix-devel@gnu.org, that is.

<mark_weaver>it's not a quick answer, and the answer should be available for all to see

<civodul>yes

<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> http://bugs.python.org/issue20868

<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

<ph4n70m4s>ok

<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)

<ph4n70m4s>ok

<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>yeah

<civodul>we'll see

IRC channel logs

2014-03-09.log