<lfam>It looks like Debian's solution was to upgrade graphite2 to 1.3.6, so I think we must be okay since you did the same.
<mark_weaver>lfam: yes, I looked at that and it seems that updating to 1.3.6 is enough. debian didn't apply any security patches to 1.3.6, anyway.
<lfam>Okay, just wanted to communicate my uncertainty. One can never be too sure about these things!
<mark_weaver>lfam: nonetheless, thanks for bringing it to my attention and for all the help with security updates. it is a great relief
<lfam>You're quite welcome! I'm more than happy to apply the updates I feel comfortable applying. I'm glad that you seem to handle the more "thorny" updates like icecat; I wouldn't be sure where to start...
<lfam>And I'm also glad that efraim and others do security updates too
<iyzsong>Jookia: that's strange, thunar linked with the wrong gdk-pixbuf, and will use the right one when I remove the gdk-pixbuf from libnotify's inputs or delete libnotify.la. (so the libtool really does something)
<Jookia>iyzsong: Oh I see, GNOME isn't updated to link to the svg pixbuf. Perhaps it'd be better to rename gdk-pixbuf+svg to gdk-pixbuf and the old gdk-pixbuf to gdk-pixbuf-simple ?
<iyzsong>I don't think that's the problem, packages using gtk+ does have the right one in their's inputs, but it will link to the old one sometimes..
<Jookia>Perhaps GTK can't handle two gdk-pixbuf packages at the same time?
<Jookia>I wonder how they'd select the right gdk-pixbuf to link to if two dependencies use different gdk-pixbuf propagated inputs?
<iyzsong>in case of thunar, the old gdk-pixbuf is not in inputs at all, but it get it from libnotify.la.
<Jookia>I also changed gdk-pixbuf+svg to be gdk-pixbuf on my machine so all my packages get it by default, but it's not ideal since only GTK should need SVG support for icons. Guix should really shine with having multiple package versions, and it's sad this isn't the case. :(
<taylan>I see. will just have to wait a while then :)
<lfam>taylan: My nmap package doesn't have a working ndiff. I think I need to set the PYTHONPATH to point to the libraries in nmap's store directory
<lfam>I think it would be easily accomplished if I could apply some phases of the python-build-system. Is that possible?
<lfam>Or maybe it would be enough to just make a wrapper that points to ../lib/python2.7 or something like that. I wonder if the PYTHONPATH needs anything else?
<lfam>I bet if I solved this it would be easy to also build zenmap
<Jookia>Thanks Numix for not shipping source tarball releases
<Jookia>I wonder whether I should even build a theme from source- it compiles Sass to CSS, is that a binary?
<taylan>lfam: I messed around a lot and couldn't find a way to make the python modules work with zenmap. I think we need to apply a hack that I've seen in one other python package, let me try to find it again...
<lfam>taylan: It looks like you made ndiff work. At least for my basic test case
<Jookia>iyzsong: I'll probably push out a few grafts for people to test without losing substitutes, but the whole gdk-pixbuf thing still needs to be solved, whether by fixing libtool packaging behaviour or replacing gdk-pixbuf with the one most applications should use.
<iyzsong>yes, I think I'll leave it for next release.. with update to pixman, cairo, gtk+, etc.
<Jookia>Ah, so you'd go for the replacing-gdk-pixbuf solution?
<civodul>yeah we need your input on this, iyzsong :-)
<iyzsong>wingo: cool! I think the doc of services functions should be updated to the same as info.
<wingo>is the info node right or does it need a new top-level node?
<wingo>also i tried it of course :) and i have the suspend loop problem everyone else has -- when you shut the lid, it suspends, great. but when you open, it comes back to life only for an instant and then re-suspends. i guess some sort of inhibit / elogind issue
<iyzsong>ok, if it's not usb disk, maybe sdcard? but, which system is it, if you use the guixsd-usb-install image, 'cow-store' should be there.
<NiAsterisk>slightly OT, but I try to figure out why my 9cell battery does not last 4 hours or more, and I don't fully understnad the following in Overview of powertop: 100.0% Device Audio codec hwC0D0: Conexant
<NiAsterisk>but i don't think this is important, I see many options which can be tuned and are on "bad" currently
<civodul>good news: master had not been built for a couple of days on hydra(!) but it's now catching up
<roelj>civodul: Is that why there are/were no substitutes available for the latest git checkouts?
<civodul>rekado: what's the status of the icedtea-8 patch?
<mark_weaver>civodul: fyi, I'd like to push the linux-libre-4.5 update to master, and then redirect hydra to build it ASAP, if that's okay with you. I'm running it now. I kept linux-libre-4.4 as well, since it's an LTS kernel.
<mark_weaver>unfortunately, the 4.4 kernel needs to be rebuilt, because its config file name changed from linux-libre-<arch>.conf to linux-libre-4.4-<arch>.conf
<mark_weaver>to prevent this issue in the future, I changed things so that the major+minor version number is *always* in the config file names, and not just for the older kernels.
<roelj>rekado: No.. I don't even see which packages will be built.. Each package consists of multiple source files, that all get compiled in a separate compile process (gcc)..
<NiAsterisk>well anyhow it keeps track of times. could be useful later, that's all.
<roelj>I added a license to my guix. Then pointed ~/config/guix/latest to the git checkout. Then recompiling a java package (that used to take about a minute) turns out to take more than 4 hours (and counting), because it seems almost everything is being recompiled.
<davexunit>basic criteria: decentralized (i.e. nothing like Chef server), "stateless" (i.e. no state file like NixOps), light on workstation resources (don't build systems on the workstation, offload to cluster, use substitutes to optimize)
***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | videos at https://gnu.org/s/guix/help/#talks | 0.9.1 is in the works | https://libreplanet.org/wiki/Group:Guix/GSoC-2016 | paste to http://paste.lisp.org | channel logged: <https://gnunet.org/bot/log/guix>.'
<jesaispas>" Support for the Logical Volume Manager (LVM) is missing. " does it mean that we can't use LVM even if it's for a data partition?
<rekado>jesaispas: I'm using LVM for my home partition.
<NiAsterisk>hm. did I comment on the server thread and mention that OVH is too much of an insecurity for me and that my only server related thing will be introducing GuixSD to IN-Berlin once we/I could use it on production servers and get it on my own server there?
<suitsmeveryfine>no matter how I write "linux-libre-xxx" I get this error: "ERROR: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): "linux-libre-4.4.5" (or "linux-libre.4.4", etc.)