IRC channel logs

<phant0mas>civodul: there's something strange going on here, after using the right libpthread I can't seem to be able to reproduce the bug I had with the hooks

<civodul>well, good news :-)

<phant0mas>could it be that the previous error was because of using the wrong libpthread version?

<phant0mas>and I spent so much time searching the source of a non existent problem...I am gonna start knocking my head to the wall :P

<phant0mas>ok I will solve the libihash issue, and move full speed to finish packaging it

<bavier>well, I'm pretty sure I've got this lapack rpath issue figured out, but I've unfortunately got the mods mixed in with several other packages that I was working on in maths.scm, so I have to sort those out before I can push anything

<bavier>I might come back to that in a few hours.

<civodul>use magit!

<zacts>lo

<zacts>did you guys update the openssl heartbleed vulnerability?

<davexunit>yes

<zacts>nice

*davexunit pushed the man-db patches to master

<zerwas>\\o/

<davexunit>after much technical difficulty on my end, I can finally push to the repo. :)

<davexunit>gah, I have a notmuch package soooo close to working, but a test times out :(

<zacts>so how will guix play with gnunet?

<davexunit>I have no idea :)

<zerwas>By the way, GNUnet 0.10.1 is out :)

<zacts>oh cool! \\o/

<zacts>lo

<civodul>Hello Guix!

<phant0mas>hello civodul

<phant0mas>I am sending you the whole glibc patch till now so you can take a look on it

<phant0mas>it's not finished yet, but I want somebody else to try it and tell me if he will get the same rror

<civodul>ok

<phant0mas>civodul: by mistake I sent the patch only to you

<phant0mas>I will resend it to the list

<civodul>np

<phant0mas>civodul: in your nix package you had libstore and libshouldbeinlibc as a build target for hurd-minimal as well

<phant0mas>why did you do that?

<civodul>i think there are comments in there no?

<civodul>i can't really look into it right now

<civodul>but i'll get back to you eventually

<phant0mas>yep they are

<phant0mas>I will use the latest version of the hurd libs from the git repo and try again

<phant0mas>take your time, I am going to a lesson now

<sriharsha>civodul, gnunet-0.10.1 tests are failing

<sriharsha>is 0.6 going to be release this week?

<sriharsha>*released

<civodul>sriharsha: sometime this afternoon!

<civodul>so np, we can upgrade GNUnet later

<civodul>you should tweak grothoff into testing with "guix build gnunet --with-source=..."

<civodul>this is terrible, i keep hunting after MiBs on my hard disk

<civodul>i'll have to do something about it

<lliI1>civodul: how does 'guix build' "add" a tarball to the store? it seems it uses 'build-derivations', but I'm not entirely sure.

<civodul>lliI1: right, tarball downloads are normal derivations, so building them actually downloads the tarball and adds it to the store

<lliI1>but how does 'guix build' distinguish between simply adding a tarball to the store versus using the build system?

<lliI1>For instance, I'd like to prefetch wget. I could get a corresponding derivation like so: ,use (guix packages) (gnu packages wget) (guix store) (define s (open-connection)) (package-derivation s wget). What should I do to add the tarball to the store?

<lliI1>As I said, it's not clear how 'guix build' knows when it have to return the location of a tarball instead of building a derivation.

<lliI1>(Perhaps the use of "build" in the forementioned is ambiguous.)

<civodul>lliI1: you'd have to use the 'package-source-derivation' procedure

<civodul>and then build that derivation

<civodul>but at any rate, if you build wget, its tarball will also be added to the store

<civodul>because wget's derivation depends on its source derivation

<civodul>so when you ask to build the former, you also build the latter

<lliI1>"source derivation" =? "tarball"

<civodul>yes, the "source derivation" is the derivation that builds the tarball

<civodul>in practice it's not necessarily a tarball, hence the distinction

<lliI1>civodul: Sorry, I still don't understand how to get a '.tar.gz' file instead of '.drv'. (for-each (lambda (x) (display (derivation-input-path x)) (newline)) (derivation-inputs (package-derivation s wget))) prints a list of '.drv' files. I tried to pass one of the '.drv' locations to 'package-source-derivation' but got the same location back.

<civodul>a .drv is a low-level representation of the build process

<civodul>there's one for everything that is "built", including tarballs

<civodul>at the command line, you can use "guix build -S foo" to get foo's tarball

<lliI1>Yes, but I'd like to know how to do it from the REPL.

<civodul>at the API level, you can use (build-derivations s (list (package-source-derivation s foo)))

<lliI1>Ah, okay.

<civodul>i take it as a hint that the manual could use help ;-)

<lliI1>Just to clarify, does 'derivation-inputs' contain all the inputs required to build a package?

<lliI1>I doubt I could improve the relevant sections of the manual.

<civodul>lliI1: 'derivation-inputs' contains everything, whereas 'package-inputs' only contains "explicit" inputs (and not GCC, libc, etc.)

<bavier>civodul: thanks for the magit suggestion. that's a useful piece of software

<civodul>yes, it's really neat

<civodul>well for emacs users at least ;-)

<davexunit>magit has completely changed the way I use git.

<civodul>same for me

<lliI1>civodul: will you release 0.6 tonight?

<civodul>lliI1: actually 0.6 is out, but no one knows :-)

<civodul>i'm finishing the VM image that goes with it

<civodul>it's been more trouble that i expected

<lliI1>civodul: Have you seen my message regarding Python testsuite failure? Will you release regardless?

<lliI1>My machine is currently running the tests and should finish soon.

<civodul>who are you?

<civodul>the failure on mips?

<lliI1>Yes, but nevermind the above.

<lliI1>I've just noticed that Python tests succeeded.

<civodul>i've seen the subject but that's it

<civodul>ah ok

<lliI1>Currently it's builing libevent.

<lliI1>building*

<davexunit>civodul: oh boy, a VM image :)

<civodul>don't hold your breath, it's still pretty basic ;-)

*davexunit breathes

<lliI1>civodul: Sometimes Guile silently exits when I ran 'build-derivations'. How can I force it to provide more information?

<lliI1>run*

<davexunit>civodul: I was trying to package sudo recently and having some troubles, and mark told me about issues with setuid in guix. what are your thoughts on getting tools like sudo working on guix?

<lliI1>civodul: You imply that (build-derivations s (list (package-source-derivation s foo))) corresponds to 'guix build -S foo', but the latter returns the location of a tarball while the former returns a boolean. How can I get the location?

<civodul>lliI1: derivation->output-path

<civodul>davexunit: with wrappers as in NixOS

<civodul>we can discuss this on the list if you want

<davexunit>civodul: sure, I'll write to the list about it.

<civodul>thanks

<lliI1>civodul: I've tried 'derivation->output-path' on a bunch of packages, I always get something like "/gnu/store/<hash>-package-name-version". I want to see the same but with something like ".tar.gz".

<civodul>lliI1: try (package-source-derivation s foo)

<civodul>that'll print #<derivation ...foo.tar.gz.drv => ...foo.tar.gz>

<lliI1>civodul: What's "foo" in your example?

<civodul>a package

<lliI1>I get 'match-error' for something like (package-source-derivation s shishi).

<civodul>oh right, sorry

<civodul>should be (package-source-derivation s (package-source shishi))

<civodul>the docstring hints at it, but yeah, it's not very intuitive

<lliI1>Yay, (derivation->output-path (package-source-derivation s (package-source shishi))) does the job.

<lliI1>Thanks.

<civodul>np

<lliI1>However, 'ls <the output of the above command>' returns "no such file or directory." Should I build it in order to add to the store?

<lliI1>There's also 'add-to-store', can I use it?

<civodul>yes, it's not in the store until it's built

<civodul>derivation->output-path just tells the file name under which the result will be available

<lliI1>Yeah, I gathered.

<civodul>i think i gave examples of these things in my talks

<civodul>but maybe not with enough details

<lliI1>Perhaps, but I can't remember the details anyway.

<lliI1>civodul: Awesome, (build-derivations s (list (package-source-derivation s (package-source wget)))) works. Thank you so much.

<civodul>well, fortunately :-)

<lliI1>Haha!

<civodul>Guix 0.6 is out!

<zerwas>Yay, great!

<davexunit>awesome!

<bavier>\\o/

<phant0mas>awesome :-D

<drewc>w00t!

<civodul>e-Champagne everyone!

<davexunit>./pre-inst-env guix drink

<davexunit>unbalance some parens.

<civodul>:-)

<lli1I>civodul: There's a neat function that I could use, that is, 'derivation-prerequisites-to-build'. However, its result contains both .drv derivation-inputs and .tar.xz.drv ones. Is it possible to filter out the former?

<civodul>lli1I: not really

<lli1I>Oh.

<civodul>at the derivation level, there's no notion of source vs. package

<civodul>that's why i suggested starting at the package level

<civodul>but in derivation, you could have a heuristic to filter based on the file name

<lli1I>civodul: You mean by hardcoding the archive formats?

<civodul>yes

<lli1I>Ugh.

<civodul>not very elegant

<lli1I>Not elegant at all.

<civodul>not very elegant at all

<civodul>:-)