<NiAsterisk>lfam: actually in the last 9(? or more) years and 12 flats I had 3 bad ones, the one where the storm ruined the bed (all other furniture and electronic survived) was not the worst. the current one where I live for some years now is okay. the landlords suck with management of their files and do funny shit with money, but we have civil rights organzations dealing with that. other than that they are okay. well <NiAsterisk>"okay": this house is very old, early 1900s, and last year the basement partially flooded. 4 private phonecalls and 1 organizations letter were needed to convince them that they need to fix this, 8 or 9 weeks iirc.. <lfam>See, I would just not pay for that <lfam>I had a similar situation so I didn't pay rent for 7 months, and then I moved. <lfam>I had to fix the roof myself <NiAsterisk>not paying is an option here if it's worse enough. the degree of worse is defined by a number of factors and it's (sadly) okay here. <dannym>for anyone who might be wondering how to make Gnome not clobber the keyboard layout which you manually set by xkbcomp, patch libxklavier to never reactivate its layout in "xklavier_config_xkb.c" - which it would do in "xkl_config_*get*_keyboard". ... argh <paroneayea>should I configure cups through its own interface <detrout>Though it'd be nice if I had python 3.5 instead of 3.4 <detrout>Is there a way to specify a dependency version range for a packages inputs? <zacts>mark_weaver: is gnuplot free software? <zacts>I don't see it in directory.fsf.org <zacts>but it is included in guix, just fwiw <mark_weaver>zacts: it is free software, although not actually a GNU project (despite its name) and has a rather annoying license as I recall. <Jookia>mark_weaver: FWIW I might end up doing some GNUnet + Guix work if nobody else is taking it up (after of course I get GuixSD to run on my Novena :P) <Jookia>mark_weaver: Another thing of note is Parabola folks are close to getting GRUB to work on the Beaglebone, so I'll probably take another shot at it soon with a newer GRUB <lfam>I'm trying GNOME, but while trying to log in I get the "sad computer" icon and the "Something has gone wrong" error message. <lfam>Are there missing packages? <rekado>sneek: later tell civodul I once played around with d3. Would you like to have the "guix graph" command be enhanced to optionally output JavaScript code that could be used with d3? Even if we don't have d3.js packaged for Guix yet? <iyzsong>lfam: to see what goes wrong, you can try 'gnome-session --debug' in ~/.xsession <lfam>izysong: It prints some warnings about not having hardware or software 3d acceleration, and then it prints: <lfam># this script should be run in the background, except for the window <lfam># manager, which should be last. <lfam>xterm -geometry 80x24+1+345 -sb & <lfam>xclock -update 1 -geometry 100x100+822+1 & <lfam>xman -geometry 100x100+932+232 & <lfam>xterm -geometry 80x24+1+1 -sb -T Vaxb -e telnet vaxb & <lfam>xsetroot -solid lightskyblue4 & <lfam>No, it doesn't print that <lfam>(gnome-session-quit:650): WARNING **: Failed to call ogout: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files <lfam>And at the beginning, it prints: ...-gnome-session-3.18.1.2/bin/.gnome-session.real: line 3: gsettings: command not found ***nckx is now known as nckx|offline
<efraim>mark_weaver: does that fix gtk-doc? <mark_weaver>at some point, we should add gtk-doc to the inputs of packages that could use it, but that's probably for the next core-updates cycle. <efraim>gtk "only" has ~200 dependant packages <mark_weaver>we don't have enough build farm capacity to keep up as it is. in cases where we can easily avoid ~1000 extra rebuilds, we should <xd1le>mark_weaver: yes gnuplot's license is actually gpl incompatible, strangely enough <iyzsong>any one try guix on android phone? I copy the bash-static, and it works... <daviid>ACTION has a 'secret' Guile-Vigra binding project waiting... <daviid>wingo: I lost the email but a guix developer wrote to the vigra mailing list yesterday or so, and the answer was: ... get the latest 'to be released' branch and see if it fixes, the yes it fixed it. but then they did speak about another not guix related bug, which seems to have pending resolution soon... et voilà <davexunit>pizzaiolo: nice. glad that Debian is nice and fixed the issue when they found it. <davexunit>in general I am seeing a very vocal anti-GPL sentiment about this whole situation; <pizzaiolo>I'd like to believe it's only a loud minority <davexunit>yeah, I don't how big the precentage is, but they certainly are loud. <davexunit>which is interesting considering how they argue that the pro-GPL people are so loud. <rain1>when you say anti-GPL is it like, "BSD is better down with GPL"? <davexunit>because it's incompatible with certain other free licenses. <rain1>i never understood why these people want to hide their source code so much <davexunit>it's not necessarily about that. it's that you cannot use GPL code in a project that wants to distribute under a different license. <pizzaiolo>basically GPL can be a hassle for developers <pizzaiolo>so they're thinking about their own convenience ***mog_ is now known as mog
***kelsoo2 is now known as kelsoo
***the_ktosiek is now known as ktosiek
<ajgrf>does the guix command line tool have any way to delete old generations of the *system* profile? i couldn't find any friendly way of doing it so i just manually deleted the gc roots with `rm` <mark_weaver>ajgrf: not yet. just delete the links in /var/guix/profiles and then rerun 'guix system reconfigure' <ajgrf>mark_weaver: thanks. is there any reason it isn't implemented yet? if not, i might try to throw a patch together this weekend <NiAsterisk>did I read the commit list right, mediagoblin is now in guix? <davexunit>NiAsterisk: there's a wip-mediagoblin branch <NiAsterisk>ah, wip. okay, didn't read the branch, i just saw the mediagoblin package in the scm list <detrout>In inputs why do you need to list both the name and derivation? and does an input name string need to match something? <detrout>Shouldn't a deriviation have a name? <bavier>detrout: you list a "label" and a package variable. <bavier>the label must not necessarily match the package variable name <detrout>In the case of wanting to use my own modified version of a package it's pretty clear the derivation should point to my modified package name <detrout>Ah I found one ("element-tree" ,python2-element-tree <detrout>so the label is more documentation for the user <bavier>and is used in things like (assoc-ref outputs "foo") <detrout>Ah I found 7.6.2 Package Naming which explains the difference <detrout>though that doesn't explain the inputs ***kelsoo1 is now known as kelsoo