IRC channel logs

<sprang>hmmm, how do I get "guix system reconfigure" to update my kernel?

<mark_weaver>sprang: when you run "guix pull", it only updates guix for that one user account (by setting the ~/.config/guix/latest symlink)

<mark_weaver>so when you run "guix system reconfigure" as root, it's not including those updates

<mark_weaver>you can either run 'guix pull' as root as well, or make ~root/.config/guix/latest a symlink to ~/.config/guix/latest to make sure that root always uses the same version of guix as your normal user account

<mark_weaver>another option, which I use, is to make both of those a symlink to my guix git checkout.

<sprang>I'm doing the latter (symlink to my git checkout)

<sprang>I'll have to investigate in a bit, stepping afk for the moment

<iyzsong>mark_weaver: hi, I fix the gdk-pixbuf by merge the 'arguments' fields, and do update for poppler, harfbuzz, graphite2. should I create a branch and what name :-?

<mark_weaver>iyzsong: bah, did I create a duplicate arguments field? :-(

<mark_weaver>ACTION looks

<iyzsong>yeah, how about update fontconfig too

<mark_weaver>damn!

<mark_weaver>bah

<mark_weaver>fontconfig entails a very large rebuild, even larger than the entire 'security-updates' branch I just built out.

<mark_weaver>I was planning to save that for the next core-updates cycle

<mark_weaver>I'm surprised there was not more breakage from this mistake.

<mark_weaver>we really need compile-time errors on duplicate fields. this is not the first time I've been bitten by this.

<iyzsong>i think it just cancel the x11 support for gdk-pixbuf, which only used by sawfish

<xentrac>did harfbuzz have yet another security hole?

<mark_weaver>if any of those are security updates, then of course it is a higher priority

<mark_weaver>if sawfish is the only thing that broke, maybe it's not worth another rebuild before core-updates.

<iyzsong>I don't find security fixes in it.

<mark_weaver>(which we should do soon anyway)

<mark_weaver>if needed, we could fix sawfish in the meantime by making a separate "gdk-pixbuf-with-x11" package just for sawfish.

<mark_weaver>and then clean it up on the next core-updates cycle

<mark_weaver>what do you think?

<mark_weaver>according to "guix refresh -l", gdk-pixbuf requires 222 * 3 = 666 rebuilds, whereas fontconfig requires 478 * 3 = 1434 rebuilds

<mark_weaver>and those are underestimates, because "guix refresh -l" doesn't know about the implicit inputs from glib-or-gtk-build-system

<iyzsong>It doesn't feel good, but ok ;-

<iyzsong>should I update the gdk-pixbuf and sawfish?

<mark_weaver>iyzsong: I guess it's okay, but should be done in a separate branch and jobset.

<mark_weaver>the branch could be called something like 'gdk-pixbuf-fix'

<mark_weaver>if you want to update some other things that depend on gdk-pixbuf (and thus would need to be rebuilt anyway), that's fine too.

<iyzsong>ok

<mark_weaver>iyzsong: thanks, and sorry for the mistake :-(

<iyzsong>wait, update gdk-pixbuf, or add a new with x11 support?

<mark_weaver>well, there are two options: add a new one with x11 support, and that could go directly into 'master'.

<mark_weaver>or, just fix 'gdk-pixbuf' properly, and that would be in a separate branch.

<iyzsong>fine, I'd go for fix :-)

<mark_weaver>okay

<mark_weaver>thanks!

<mark_weaver>let me know when the branch is ready, and I'll create the jobset on hydra

<lfam>Is there a way to make `guix package --show` list the argument's outputs?

<mark_weaver>lfam: hmm, I think that's an oversight that it fails to show that.

<mark_weaver>lfam: "guix package -A'

<mark_weaver>lfam: "guix package -A" shows the outputs

<iyzsong>mark_weaver: done in new branch 'gdk-pixbuf-fix'. I think the other updates are fontconfig releated, will be go next 'core-updates' :-)

<mark_weaver>iyzsong: thanks, I'll create the jobset now.

<lfam>Yeah, I found -A in the docs. But --show is where they will be "discoverable".

<lfam>For example, I didn't realize that git had multiple outputs and that was why I didn't have git-send-email.

<mark_weaver>lfam: I certainly agree that --show should include the outputs.

<mark_weaver>ACTION looks

<mark_weaver>lfam: http://paste.lisp.org/+3AUX.

<mark_weaver>lfam: http://paste.lisp.org/+3AUX

<mark_weaver>I'll post it to the ML for review, in case Ludovic wants to do it a bit differently

<lfam>Nice, I think it will help new users find their way around.

<anthk_>hello, I see I have both wx-2.8 and 3.0 in guix repos. How do I install the 2.8 version?

<mark_weaver>anthk_: "guix package -i wx-2.8" or just "guix package -i wx-2"

<mark_weaver>however, beware that "guix package -u" will update it to 3.0

<mark_weaver>unfortunately, there is no record kept that you wanted 2.8 specifically

<mark_weaver>to avoid problems like this, I recommend specifying your user package manifest in a file and using "guix package --manifest=FILE"

<mark_weaver>that is a superior method

<mark_weaver>(thanks to davexunit for that :)

<davexunit>:)

<anthk_>thanks

<anthk_>wx should have 2 different package names, 3.0 functions do not always work with 2.8 :|

<davexunit>that's why we have the version string

<mark_weaver>anthk_: apart from the inadequacy of "guix package -u", guix generally treats wx-2.8 and wx-3.0 as separate packages.

<mark_weaver>so IMO it would be an ugly hack to include the version number in the package name

<mark_weaver>it would be better to just improve "guix package -u"

<anthk_>mark_weaver: you are right

<sprang>I'm getting the following error when trying to "system reconfigure": http://paste.lisp.org/+3AW1

IRC channel logs

2015-08-22.log