IRC channel logs

<bavier`>has anyone else used the scons package to successfully build another package?

<rekado_>has the guix web interface shown in Ludo's talk already been released?

<davexunit>did anyone ever end up looking into the issues around packages that have a string in the 'source' field?

<davexunit>in which the string means "the source code lives in this directory"

<davexunit>it would be particularly useful for developing new software. developers could keep a 'package.scm' file in the root of their source tree, and that package could be passed to 'guix build' and produce a working build

<iyzsong>davexunit: yes, that's a feature I miss, btw rekado_ asked whether guix-web released or not.

<davexunit>guix-web has not released.

<davexunit>I think it might be close, but we'll have to think about how we integrate it into core.

<davexunit>it needs a few more features. right now you can only install one package at a time.

<davexunit>user authentication would also be nice.

<rekado_>what do you mean with "user authentication"?

<davexunit>rekado_: so that the server is only accessible to those with the right credentials

<davexunit>and a single guix web server could serve all the users on the system

<rekado_>davexunit: do you have the code available in some public repository?

<davexunit>rekado_: https://gitorious.org/guix-web/guix-web

<rekado_>thanks!

<davexunit>civodul owes me a patch to fix package installation

<davexunit>;)

<davexunit>so that's broken right now, but you can browse the package list.

<rekado_>I think something like guix-web might be very useful for my deployment of Guix, where the store is shared by many machines and only one server has write access.

<davexunit>I need to get 'guix web' and 'guix publish' in shape to get upstream.

<Sleep_Walker>is there a way how to check build logs or at least package status on hydra?

<davexunit>Sleep_Walker: yes

<davexunit>if you find the derivation, you can get a log of build process

<davexunit>I see mark post links to them here sometimes

<Sleep_Walker>OK, hydra shows something through web interface

<mark_weaver>Sleep_Walker: start at http://hydra.gnu.org/project/gnu and follow links from there.

<mark_weaver>If you're looking for build logs for a particular package, you could go straight to a link of the form: http://hydra.gnu.org/job/gnu/master/cairo-1.12.18.i686-linux

<Sleep_Walker>I pushed the enlightenment.scm to git and I wanted to verify it works on hydra as well

<mark_weaver> http://hydra.gnu.org/job/gnu/<jobset>/<package-name>-<version>.<system>

<Sleep_Walker>thanks, that will work

<Sleep_Walker>and how often it is synced with GIT repo?

<mark_weaver>multiple times per day

<mark_weaver>ideally within a couple of hours, but hydra is so overloaded that sometimes it takes longer

<Sleep_Walker>aha!

<Sleep_Walker>ok

<Sleep_Walker>thanks

<mark_weaver>(the issue is how long it takes to produce a new _evaluation_ which involving compiling all the *.scm files, producing all the derivations, seeing which ones are new, etc)

<mark_weaver>that process takes on the order of 2 minutes on Ludovic's laptop, but it takes Hydra over an hour, for various reasons related to the VM it's on.

<Sleep_Walker>wow

<Sleep_Walker>that is huge slowdown

<mark_weaver>yep

<mark_weaver>building a new box for it and getting it set up is on my TODO list, but I'm currently overloaded as well :-/

<rekado_>davexunit: when Ludo demonstrated guix web during his talk and he installed a package, which profile was the package installed to? How does guix web know what profile to install software to?

<davexunit>rekado_: it uses the default profile

<davexunit>it's not sophisticated

<Sleep_Walker>I don't expect any issues (I verified it many times) but last time missed something anyway, so I want to verify it on hydra as well

<Sleep_Walker>I'll check tomorrow

<rekado_>must it run on localhost? Or could it run on a remote system?

<rekado_>(maybe I should just read the code)

<Sleep_Walker>I still have here partially working connman and I'd like to boot guix once again :b

<rekado_>I think we should split the JRE from the JDK. The output of Icedtea6 is 3+GB and I don't think most of the stuff is necessary for all applications.

<davexunit>that's probably a good idea

<rekado_>I'm not at all familiar with Java unfortunately(?), so it'll take me some time to figure out how to split it.

<rekado_>at the very least I could move the docs (242MB) to a separate output.

<rekado_>it looks like j2re-image/, j2sdk-image/, and j2sdk-server-image/ are different "distributions" of some superset.

<rekado_>j2sdk

<rekado_>oops

<rekado_>j2sdk-server-image and j2sdk-image are virtually identical, except for samples and demos.

<rekado_>I'll move the j2sdk-image to a "jdk" output; j2re-image to a "jre" output.

<rekado_>Hmm, these two outputs would "overlap".

<rekado_>both j2re-image and j2sdk-image come with bin/, lib/, and man/.

<rekado_>bin/ contains "java", for example, in both directories.

<rekado_>it seems that they are not meant to be installed at the same time.

<rekado_>must an output named "out" exist? For Java "out" doesn't really make sense. I wanted to use "jre", "jdk", and "doc", but it seems I must have an output with the name "out" as well.

<rekado_>I suppose I could drop the "jre" output and use "out" for that instead.

<rekado_>that's the minimal binary output of this package.

<mark_weaver>rekado_: can you help me find the source code in Fedora that creates the system-wide trust store of CA certificates?

<mark_weaver>I'm not getting the answers I need from Debian's 'ca-certificates' package.

<mark_weaver>it seems to me that the list of certificates to trust in Debian is always inherited from the system the package is built on, so it's just getting propagated from each generation to the next :-(

<Sleep_Walker>mark_weaver: I haven't run make before commit, only `guix package -i', sorry again :(

<Sleep_Walker>and yes, I will do next time

<mark_weaver>Sleep_Walker: okay, thanks!

<mark_weaver>I can make guesses about how to interpret the metadata in the NSS certificate list, but it would be good to see what has been done before, and I generally trust the Fedora folks to have done their homework.

<mark_weaver>rekado_: nevermind, I found it.

<mark_weaver>wow, I'm a *lot* more impressed with Fedora's handling of certificates than Debian's.

<bavier`>strange, it seems that our scons doesn't actually execute recipes when in the build root...

<mark_weaver>I'm beginning to think I should have been running Fedora instead of Debian all these years.

<mark_weaver>(before Guix arrived, of course :)

<bavier`>davexunit: I like you gitify phase hack

<bavier`>*your

<bavier`>rekado_: We have one package that successfully uses pygtk

<bavier`>I wonder what's different between it and solfege

<bavier`>I'm probably late to that discussion..

<icarious>can anyone tell me if the build system of GUIX is similar to Gentoo's USE Flags? Like if I want to build a package with certain features and skipping the extra bloat?

<bavier`>icarious: Guix does not have anything specifically like Gentoo's USE flags

<bavier`>but package recipes may be extended and/or modified to fit your needs

<mark_weaver>icarious: there are ways to easily maintain your own arbitrary modifications to Guix by keeping a private branch of our git repo and periodically rebasing your changes on our upstream (or merging upstream into your branch).

<mark_weaver>I've been doing this for a long time.

<icarious>I understand

<davexunit>bavier`: heh, thanks. it solves a big problem for ruby packages! still one giant problem remaining, though.

<davexunit>circular dependencies!

<rekado>davexunit: wicd uses pygtk, but it also uses the python-build-system, whereas solfege does not.

<rekado>with wrapping I already made solfege work ... or rather fail in the same way that it does on Fedora.

<civodul>python-build-system has this extra phase that does wrap-program so that programs have a correct PYTHONPATH

<rekado>it fails trying to display an svg. Unfortunately, adding librsvg to the inputs didn't help.

IRC channel logs

2015-03-03.log