IRC channel logs

2015-02-04.log

back to list of logs

<mark_weaver>well, it doesn't _have_ to, but it should go there.
<rigelk>I understand
<rigelk>though there are two dbus : dbus and dbus-glib
<mark_weaver>well, dbus is the one you need to solve the problem above
<mark_weaver>it may be that you'll need dbus-glib as well, but let's not add it until we know it's needed
<rigelk>sure. It’s just that I have seen glib in the requirements stated in the python-dbus doc
<mark_weaver>yes, based on looking at the debian package, I see that you'll need both
<rigelk>hehe good. at least we don’t need to write another package desc ;)
<mark_weaver>hehe :)
<mark_weaver>debian renamed it python-dbus also, I see
<rigelk>o/ compiling with success
<mark_weaver>sweet!
*rigelk double checks
<mark_weaver>run "guix lint python-dbus"
<mark_weaver>well, only after it builds successfuly
<mark_weaver>*successfully
<rigelk>lint requires… guess what ? -> gnutls, which I, ehm, haven’t yet setup properly ^^'
<mark_weaver>oh, bummer
<mark_weaver>well, it's not important
<rigelk>^^'
<mark_weaver>after you think it's all set, can you paste the final version somewhere?
<mark_weaver>I'll be your linter today :)
*mark_weaver wants to resume work on wicd
<rigelk>thanks mark_weaver :)
<mark_weaver>np! :)
<rigelk>do you want the standalone version or the one embedded in python.scm ?
<mark_weaver>rigelk: do you know how to use git?
<rigelk>I do
<rigelk>even if I lack experience
<mark_weaver>excellent! how about move it to python.scm, get it working, produce what you think is a proper commit, and show me the output of "git format-patch -1"
<rigelk>sure.
<mark_weaver>oh, and also we should make a python 2 version
<rigelk>’seen that #:use-module (gun packages) appears twice
<mark_weaver>although 'package-with-python2' won't work here, unfortunately.
<rigelk>should i delete one entry ?
<mark_weaver>in what file?
<rigelk>python.scm
<mark_weaver>I don't see that.
<rigelk>oh.
<mark_weaver>I think maybe you are misread (guix packages) as (gnu packages)
<rigelk>oh. makes sense.
<mark_weaver>hmm, maybe we should generalize 'package-with-python2' to work with packages using the gnu-build-system. right now it only works with packages using the python-build-system.
<mark_weaver>but that will be a separate commit
<mark_weaver>rigelk: don't worry about the python2 variant for now.
<mark_weaver>because I'll need your 'python-dbus' package to test the changes to 'package-with-python2', and you'll need those changes to make 'python2-dbus' nicely.
<mark_weaver>and actually, it may require some list discussion too.
<rigelk>which commit guidelines should i follow ?
<rigelk>dumb question, gnu standards
<mark_weaver>rigelk: look at the commit logs for examples
<rigelk>did it ^^
<rigelk>what should i do with the resulting patch ?
<Sleep_Walker>it seems that gnutls depends on zlib according to pkg-config, but this dependency is missing in Guix package definition
<Sleep_Walker>should I add it as propagated-input?
<mark_weaver>Sleep_Walker: let me take a look, but if so it should go in the wip-gnutls branch
<Sleep_Walker>mark_weaver: thanks
<mark_weaver>rigelk: for now, can you paste it somewhere?
<rigelk>mark_weaver, here you are : http://paste.lisp.org/+34CE
*mark_weaver looks
<mark_weaver>rigelk: there's an extra close parenthesis at the end of the #:use-modules line. does this actually compile?
<rigelk>arg, an artifact.
<mark_weaver>a few more comments before you commit --amend:
<mark_weaver>try to keep lines < 80 columns
<mark_weaver>try putting the arguments to 'string-append' below it, so the arguments are all lined up with "string-append"
<mark_weaver>if it's still too long, try putting the 'origin' on the next line instead of to the right of 'source'.
<mark_weaver>(and reindent as appropriate)
<mark_weaver>for synopsis, how about 'Python bindings for D-Bus"
<mark_weaver>and description, hmm..
<rigelk>seems better to me, yes
<rigelk>desc is just what python-dbus devs tell on their website
<mark_weaver>I don't think it should start with "A module that".
<mark_weaver>in description, it's okay to start with the package name
<rigelk>result : « python-dbus provides bindings for libdbus, the reference implementation of D-Bus. »
<mark_weaver>okay
<rigelk>to reduce the number of columns, I but the actual desc under the description attribute
<rigelk>I put*
<mark_weaver>yes, that's a good idea. and also, it's okay to put newlines in that string literal.
<mark_weaver>don't indent the following line(s) though.
<mark_weaver>it should be wrapped to < 80 columns.
<mark_weaver>in emacs, M-q within the string literal does the right thing.
<rigelk>i did it on desc and string-append
<mark_weaver>can you show me the new version>
<mark_weaver>?
<rigelk>here you are http://paste.lisp.org/+34CF
<mark_weaver>rigelk: the description looks good, but the string-append is not indented right
<rigelk>string-append below uri ?
<mark_weaver>put the first argument to 'string-append' directly below the 'string-append'.
<rigelk>oh okay
<mark_weaver>and then put the other two arguments next to each other on the line after that.
<mark_weaver>indented, all lined up
<mark_weaver>so "version" should be lined up with the first argument (string literal)
<rigelk> http://paste.lisp.org/+34CF/1
<mark_weaver>perfect!
<rigelk>:-)
*mark_weaver goes afk for a bit, but will be back soon
<rigelk>mark_weaver, I’ll go to sleep for now
<rigelk>thanks a lot for your help !
<mark_weaver>rigelk: okay, thanks for working on it!
<mark_weaver>sleep well :)
<rigelk>mail w/patch sent to your commit adress, mark_weaver. i’ll come back tomorrow for wicd ;)
<rigelk>thanks ! see ya #guix
<jgrant>rigelk: o/
<kete>A couple of us are getting kernel panics after installing 0.8.1.
<mark_weaver>details<?
<kete> https://pumpdog.me/zykotick9/image/FG_r6bp9Qvm-pu50ndCpcw
<mark_weaver>so this is within qemu?
<kete>Mine is bare metal.
<mark_weaver>and you're getting the same backtrace?
<kete>I'll make sure it's the same
<kete>mark_weaver, yes, same Call Trace
<mark_weaver>can you email bug-guix@gnu.org about it?
<mark_weaver>please include your os-config file
<kete>with the picture?
<mark_weaver>yes
<kete>ok
<mark_weaver>so the installer booted, but then after installing the system, the first boot failed?
<mark_weaver>is that right?
<mark_weaver>well, make sure to mention things like that in the bug report
<kete>yes, an error also flashes in between "loading grub" and seeing grub
<mark_weaver>civodul is the best person to talk to about this, but it's the middle of the night for him.
*mark_weaver has wicd partially working
<mark_weaver>well, it's working, but due to some dbus problem, you have to run the gui interface as root to configure it.
<Sleep_Walker>dr-xr-xr-x 2 root root 4096 1. led 1970 /gnu/store/j0i583qxfcyy14xyibvy19811s8im837-dbus-1.8.12/etc/dbus-1/system.d
<Sleep_Walker>somehow strange permissions
<Sleep_Walker>hopefully last step for connman
<Sleep_Walker>aha
<Sleep_Walker>so it should be stored in /gnu/store/...-connman-1.28/etc/dbus-1/system.d instead
<phant0mas>good morning guys
<phant0mas>DusXMT did you run on this? http://paste.lisp.org/display/145608/raw
<Sleep_Walker>hurd? nice
<mark_weaver>okay, and now I have a 'wicd-service' that works fairly well :)
<Sleep_Walker>yay, connman compiled
<Sleep_Walker>add `guix pull' - does that use executable guix command from the system or does it provide some own?
<Sleep_Walker>I started to have guix schizophreny on my system where ~user/.config/guix and ~root/.config/guix were from different times
<Sleep_Walker>maybe I should start to work directly on GIT tree
<mark_weaver>I always run guix out of the git tree.
<mark_weaver>in fact, I made ~/bin/guix a little shell script that just does this:
<mark_weaver>exec /home/mhw/guix/pre-inst-env guix "$@"
<mark_weaver>anyway, I sent patches for wicd and wicd-service to guix-devel, and now must sleep.. good night!
*mark_weaver ---> zzzz
<Sleep_Walker>mark_weaver: good night
<andreoss`>how to change the temporary directory from /tmp to /var/tmp?
<andreoss`>i have /tmp as tmpfs and it has no enough space to build gcc
<Sleep_Walker>hm, I can't find it either in ./configure, either as parameter to guix-daemon
<Sleep_Walker>it seems it could respect TMPDIR environment variable
<Sleep_Walker>andreoss`: could you confirm?
<Sleep_Walker>export TMPDIR=/var/tmp ; guix-daemon <your_parameters>
<andreoss`>Sleep_Walker: confirmed
<andreoss`>thanks
<Sleep_Walker>andreoss`: you're welcome
<Sleep_Walker>andreoss`: could you please file a bug and request documentation improvement?
<Sleep_Walker>so it doesn't get lost
<andreoss`>Sleep_Walker: you mean emailing bug-guix?
<Sleep_Walker>andreoss`: exactly
<davexunit>morning #guix
<davexunit>there's a typo in our docs due to the renaming of the usb install images to remove 'gsd'
<davexunit>shall we just let that be fixed upon the next release?
<davexunit>or should it be tweaked in the html docs now, and also fixed in the texinfo source?
<mark_weaver>davexunit: where is gsd still used?
<davexunit>mark_weaver: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19766
<davexunit>there's a link to the usb install image
<davexunit> https://www.gnu.org/software/guix/manual/html_node/System-Installation.html
<davexunit>actually, I am somewhat mistaken. the usb images still have 'gsd' in them on alpha.gnu.org
<mark_weaver>davexunit: yeah, the bug report refers to a different issue
<davexunit>ohhhh I see what's going on now.
<mark_weaver>heh :)
<davexunit>they didn't substitute 'system'
<davexunit>for their arch
<mark_weaver>yeah, but I can sympathize with their position, and it's not the first time it's been reportd.
<mark_weaver>when it's converted to HTML, it makes it a real link.
<davexunit>yeah
<mark_weaver>IMO, I think we should abandon this clever way to save a few characters and make three real links.
<mark_weaver>s/three/two/
<mark_weaver>WDYT?
<mark_weaver>we should run it by ludo though..
<rigelk>hello #guix
<mark_weaver>hi rigelk!
<davexunit>mark_weaver: agreed.
<rigelk>mark_weaver, i’ve just seen the update. nice work on wicd :)
<mark_weaver>rigelk: thanks for your help with it!
<mark_weaver>wicd was *much* more difficult to package than I would have guessed.
<rigelk>looking at the timestamp of your patchh, indeed ^^
<davexunit>you could say that it was "wicd difficult".
<mark_weaver>and I must say, having now looked at its internals, I'm eager to see a cleaner one packaged.
<rigelk>mark_weaver, another network connection manager was suggested yesterday but i don’t remember which
<davexunit>it sounds like some gnarly code
<rigelk>ah, found it : https://01.org/connman
<mark_weaver>yeah, connman might be a good option
<mark_weaver>nice domain name!
<rigelk>i’m adding it to my work stack.
<davexunit>it's actively developed, at lest.
<davexunit>least*
<rigelk>i’m having trouble with bash in the following build : http://paste.lisp.org/+34CU always the configure phase which i don’t understand how to do :x
<mark_weaver>rigelk: that configure script doesn't comply with the gnu build system spec, so you'll have to replace the 'configure phase
<rigelk>han. how did you know ?
<rigelk>btw, is there a package i can take as an example on how to do such a configure phase replacement ?
<mark_weaver>rigelk: 'cmatrix' in games.scm
<rigelk>seems appropriated mark_weaver, thanks
<mark_weaver>np!
<bavier`>is it necessary to claim copyright on a file for a single-line change?
<mark_weaver>bavier`: we should probably ensure that at least someone has a 2015 copyright on it
<mark_weaver>but it doesn't have to be you
<mark_weaver>though maybe I'm bring overly pedantic
<mark_weaver>but for extremely trivial changes, sometimes I don't bother updating the copyright
<bavier`>mark_weaver: ok, I'll add a claim. it'd be a core-update, so I'll mail it to the list too.
<civodul>Hello Guix!
<rigelk>hi civodul !
<bavier`>hello!
<jgrant>Howdy. o/
<andreoss`>is there a way to suppress make output with guix?
<civodul>andreoss`: you mean in the Guix build tree?
<andreoss`>civodul: i want to see output of guix, but not of configure scripts and make
<civodul>when running 'guix build' and such?
<andreoss`>yes
<civodul>good question
<civodul>maybe --verbosity=0
<andreoss`>thanks. i will try it when gcc is done
<civodul>hmm actually no
<civodul>but that would be trivial to implement
<civodul>andreoss`: could you mail your request to bug-guix@gnu.org?
<andreoss`>civodul: done
<Sleep_Walker>productive day :)
<mark_weaver>hi civodul!
<iMn00b>live CD ?
<iMn00b>congrats
<jgrant>iMn00b: Hm?
<jgrant>We have an installer image, I wouldn't really call that a LiveCd unless I've missed some news.
<iMn00b>I did not congrats for live cd
<iMn00b>it was fr the add in the list of FSF-endorsed distros
<iMn00b>does anyone have a link to FOSDEM video ?
<iMn00b>Emacs of the distro ?
<jgrant>iMn00b: It probably didn't get recorded, from what I've heard -- sadly.
<iMn00b>wtf?
<iMn00b>no fsf lovers with a HD Cam ?
<jgrant>If it did, FOSDEM takes so long to upload videos it'll likely be another 3 months or-so before it's actually up.
<iMn00b>or cellphone with HD recording ?
<iMn00b>ok
<iMn00b>I get it
<jgrant>To my understanding, they way they tried to capture the talk (some new method that also was using this new way of streaming on their end) did not go well.
<jgrant>The first 4 hours of talks (maybe more, but after Ludo's talk time I gave up) didn't even have any streaming in-general.
<jgrant>So generally, I nor do I think civodul knows if was recorded at all.
<iMn00b>FOSDEM is a flop
<iMn00b>i hate it
<iMn00b>i love CCC congress
<iMn00b>they record so fine
<iMn00b>and so does Defcon
<iMn00b>bruces video are amazing
<iMn00b>like Bruce Lee
<mark_weaver>iMn00b: I'm sure there were plenty of people with phones who could have recorded it, but maybe they assumed it was already covered.
<mark_weaver>sadly, it seems that the person who probably looked quite obviously to have it covered, didn't :-(
<davexunit>conference recording is difficult.
<iMn00b>it is very easy
<iMn00b>use a HD phone
<mark_weaver>I dunno, I'm pretty unhappy about it
<davexunit>it sucks for sure.
<davexunit>it seems like they had a very sophisticated setup that just flopped.
<iMn00b>mark_weaver, ok, you could have recorded
<iMn00b>you were there right
<davexunit>no
<mark_weaver>I wasn't there
<iMn00b>lol
<civodul>yeah, that sucks
<mark_weaver>wrong continent
<iMn00b>I wasn't either
<iMn00b>I like CCC
<iMn00b>they are professionals
<civodul>then there are like 30+ tracks in parallel, so if something goes wrong, you're screwed
<iMn00b>Germans rock!
<mark_weaver>they could have arranged things in such a way that network failures didn't lose the actual recording.
<davexunit>speaking of, currently discussing with the FSF sysadmins now about recording/streaming for LP2015.
<iMn00b>so they lost the records ?
<iMn00b>lol
<davexunit>we want to avoid this exact scenario.
<iMn00b>davexunit, oh it should be HD and fully quality
<iMn00b>LP sucks too
<iMn00b>poor quality cam
<davexunit>if the stream fails, oh well, but we must save a high quality recording on disk.
<civodul>davexunit: i think in past years they just recorded things locally, which was safe
<civodul>this time they had a server both for streaming and recording
<civodul>which is obviously risky
<civodul>you should avoid that for LP :-)
<davexunit>iMn00b: we're probably the only organization that records conference talks with 100% free software, so we run into some unique problems.
<davexunit>problems that we're trying to solve for this year.
<civodul>for GHMs it was only free software too
<civodul>but i don't know much about all this
<davexunit>oh good :)
<iMn00b>davexunit, ah! that sucks! what you should do is, ask a person to record it and then convert it to free formats, officially claim not to have recorded anything
<davexunit>...
<davexunit>no.
<iMn00b>then it is going to be pathetic quality video again
<iMn00b>try CCC's management team
<iMn00b>they love FSF people
<iMn00b>unless FOSDEM
<iMn00b>and DEFCON
<iMn00b>unlike*
<davexunit>I don't care for your tone.
<iMn00b>Ok then you would end up more or less like FOSDEM
<iMn00b>trust me
<mark_weaver>davexunit +1
<mark_weaver>iMn00b: we are dedicated to using only free software on this channel.
<mark_weaver>and it can do this job. the FOSDEM problems were not inherent to free software
<mark_weaver>the system was just not properly designed to cope with network failures
<davexunit>LP2014 streaming was a failure. we intend to not repeat the mistakes made last year. we'll see how we do.
<iMn00b>ok
<iMn00b>hope you guys do my plan as your backup plan
<iMn00b>get few college kids
<iMn00b>ask them to record it for you
<iMn00b>release as free format if it fails
<iMn00b>distribute free beer and t-shirts
<iMn00b>they would make the best thing ever
<mark_weaver>davexunit: will there be multiple talks going on at once?
<mark_weaver>how many different rooms?
<davexunit>mark_weaver: yes
<davexunit>3 rooms.
<mark_weaver>will MIT techs be handling the audio feed?
<mark_weaver>(is it at MIT?)
<davexunit>yes, it's at MIT.
<davexunit>no, they will not be handling the feed.
<davexunit>at least I don't think so.
<davexunit>due to costs.
<mark_weaver>well, at GNU 30, MIT provided the mics and PA, and provided a feed to FSF people who did the recording/streaming.
<davexunit>I could be missing something. I'm not the mastermind behind the setup, and I don't know exactly what was done at GNU30 and LP2014.
<mark_weaver>at the time, they had a very bad USB-audio adapter. I managed to salvage the audio in time for RMS's talk by borrowing a better one from WMBR
<mark_weaver>hopefully they will have 3 of those good ones.
<davexunit>I'll bring it up.
<davexunit>my focus is mainly going to be on the web aspect, naturally.
<davexunit>so the A/V hardware is a little beyond me.
<mark_weaver>I have a fair amount of experience with audio, because of my long experience at WMBR (MIT's all-volunteer radio station)
<andreoss`>i'm always wondering if they're using free software for video/audio editing of this talks
<davexunit>mark_weaver: it's a good station :)
<andreoss`>s/free software/only free software/
<mark_weaver>andreoss`: for LibrePlanet, they definitely are
<mark_weaver>davexunit: you should come visit sometime!
<mark_weaver>I could give you a little tour of the station
<davexunit>mark_weaver: yeah? that would be fun!
<davexunit>I would gladly take you up on that offer once travelling becomes a bit easier around here :)
<mark_weaver>heh :)
<davexunit>1 1/2 hour commutes from somverille to downtown boston aren't fun.
<mark_weaver>davexunit: it might be good to have a redundant setup, with a second computer/camera (recording only) in each room.
<davexunit>I concur, if we have the means to do so.
<mark_weaver>I might be able to act as one of those redundant backups, on either my Libreboot X60 or my X200.
<davexunit>nully ^ :)
<mark_weaver>however, I would prefer to not have to pay for admittance. I don't have much money, because I choose to work on GNU instead of paid jobs.
<davexunit>volunteers do not need to pay.
<davexunit>that would be a real crappy deal. :)
<mark_weaver>cool :)
<mark_weaver>I could probably borrow WMBR's nice USB-audio adapter, and I have a USB camera that's fairly decent.
<mark_weaver>good enough for backup purposes anyway.
<mark_weaver>it's just a matter of getting the software in Guix needed to do a nice capture.
<mark_weaver>a fully preemptible kernel config would be one part of that
<mark_weaver>and then probably spiffing up our vlc package
<mark_weaver>well, it might already be good enough, dunno. would have to test
<davexunit>ooh a guix powered recording setup. yes!!
<jxself>mark_weaver: So you need an RT kernel then?
<rigelk>does anyone know what such an error means ? gnu/stubs-32.h : No such file or directory -> http://sprunge.us/KRMc
<jxself>That'd mean 3.4 since I think it's the current stable one.
<jxself>Ah, seems there are some for 3.14 too. Good.
<bavier`>rigelk: not related directly to the glibc header error, but is there a way to configure rust to use a system llvm?
<rigelk>bavier`, i can’t say for sure. reading rust’s makefile shows llvm variables but i’m not used to pass arguments to the configure phase, so not sure can be used
<bavier`>rigelk: Looks like you can pass the --llvm-root=... variable to rust's configure script
<mark_weaver>jxself: it would be great to have an older stable kernel series anyway.
<jxself>There'd be two then - an older RT and older non-RT since the RT ones aren't as power efficient as the non-RT one, AIUI.
<mark_weaver>jxself: if you were willing to craft a kernel config that would be good for recording video, it would be much appreciated!
<mark_weaver>jxself: indeed, RT is a tradeoff. the thread synchronization becomes more expensive
<jxself>Coming up with the config shouldn't be too hard (but maybe I'll regret that statement later?)
<mark_weaver>heh :)
<jxself>I had look into making a new kernel package for a long-term one but eventually gave up because I didn't make progress.
<mark_weaver>well, we had 3.14 at one point. we could just resurrect it and bring it up to date with the latest point release?
<jxself>Seems it should be possible to use that inherit thing (or whatever it's called) to re-use part of the existing kernel package thing but I couldn't figure it out.
<mark_weaver>I'm still using 3.14 on the yeeloong, so it would also be a prerequisite for producing a kernel package for it.
<mark_weaver>(I had trouble with newer kernels, but haven't checked in a while; maybe the problem has been fixed)
<mark_weaver>jxself: oh, I can help with that.
*mark_weaver looks
<jxself>Okay, so I suppose the first thing is making a 3.14 RT config.
<jxself>I already have a good non-RT one for 3.14.
<jxself>Oh, and checking that the patches apply - They are for 3.14.29 and not 3.14.31.
<jxself>But hopefully that's not too difficult.
*mark_weaver works on the inherit stuff.
<jxself> http://linux-libre.fsfla.org/pub/linux-libre/freesh/configs/3.14/
<mark_weaver>maybe we should rename the kernel config files to include the major+minor version number. WDYT?
<mark_weaver>it would simplify the code
<jxself>Those could be re-used as-is (except for the names.)
<jxself>For the non-RT.
<jxself>And yes, naming is a good thing.
<jxself>Those should probably be added into version control since the files could change with later versions.
<jxself>Ignoring the non-pae one, that is.
<jxself>Unless having a non-PAE kernel is also desirable?
<jxself>The number of combinations seemt to be quickly expanding...
<mark_weaver>while I'm generalizing this, I'll add support for "variants" as well.
<mark_weaver>(new arguments to 'kernel-config')
<jxself>And 3.19 is probably coming out this weekend - https://lkml.org/lkml/2015/2/2/14
<mark_weaver>hmm, should I call these "variants" or "flavors" ?
<mark_weaver>or "flavours" :)
<jxself>Oh, no U please.... :)
<bavier`>haha
<mark_weaver>:)
<jxself>Will RT be considered one? I assume?
<jxself>And non-PAE?
<mark_weaver>right, that kind of thing
<jxself>What about a non-RT version of say 3.14 that's a long-term support kernel?
<mark_weaver>we'll also need special configs and patches for yeeloong and novena
<jxself>I think I like variant better but it's total bikeshedding on my part.
<mark_weaver>jxself: a 3.14 LTS kernel sounds good to me.
<jxself>Yeah, that was why I was originally looking into the inherit thing.
<mark_weaver>I'm actually doing it a bit differently.
<mark_weaver>I'm changing 'linux-libre' into a procedure that takes arguments and returns a package.
<jxself>I could probably also come up with one for armh or armf or whatever it's called on the Novena.
<mark_weaver>(and renaming it to linux-libre*)
<mark_weaver>and then linux-libre just calls it with the right parameters
<jxself>Hmmm.
<mark_weaver>in this case, it turns out to be much simpler this way.
<jxself>OK.
<DusXMT>mark_weaver: Will it have a custom config parameter? That might be useful for people who like fine-tuning their kernels for their systems
<mark_weaver>the 'variant' makes that relatively easy, yes.
<jxself>Yeah, that might be a good idea too. Since you're at it. :)
<mark_weaver>because it can be any string, and is included in the config file name.
<mark_weaver>okay, I've done the changes, now to see if they actually work.
<mark_weaver>if I omit the configuration file renames, it generated the exact same derivation so didn't have to rebuild. that's a good sign.
<mark_weaver>but the config file renames force a rebuild.
<jxself>May be good to save it for 3.19 when when a rebuild is due anyway?
<jxself>And 3.19 is supposed to be out soon, possibly this weekend.
<jxself>Asuming that there are no major problems that come up with release candidate #7.
<mark_weaver>that's fine
<mark_weaver>jxself: http://paste.lisp.org/+34DA
<mark_weaver>what do you think? the last hunk contains the new 'linux-libre' package definition, which just uses the general machinery of 'linux-libre*' to produce the package.
<mark_weaver>it should make it very easy to produce more versions and variants.
<mark_weaver>oh, that 'patches' keyword argument shouldn't be there.
<mark_weaver>so 'linux-libre*' takes three required arguments (package-name, version, source-origin), and two optional keyword arguments #:variant and #:gcc
<mark_weaver>if variant is given, it is put in the configuration file name after the arch.
<mark_weaver>e.g. linux-libre-3.18-i686-rt.conf
<mark_weaver>for #:variant "rt"
<mark_weaver>this also gives me enough flexibility to produce kernel packages for loongson 2f and novena
<mark_weaver>hmm, we might be able to remove the gcc-4.9 workaround now that we have 4.8.4
<mark_weaver>probably 'linux-linux*' should have a different name.
<mark_weaver>'linux-libre*' I mean
<bavier`>mark_weaver: how about custom-linux-libre? Like the custom-gcc we have in (gnu packages gcc)
<mark_weaver>bavier`: possibly. I thought about that exact name, and then thought "but it's not always (or even usually) a custom one".
<mark_weaver>custom-gcc is not the primary gcc definition, rather it inherits.
<mark_weaver>still, it might be the best choice nonetheless.
<bavier`>naming can be quite difficult sometimes
<mark_weaver>increasingly, I think that coming up with good names is one of the hardest parts of programming
<bavier`>;)
<mark_weaver>and well worth the effort in most cases
<bavier`>yes
<mark_weaver>hmm, it occurs to me that those kernel configuration options that are appended to our main kernel configs should be an argument as well.
<mark_weaver>in most cases, when people want a modified config, they only want to change a few specific options.
<mark_weaver>I guess that's what DusXMT was getting at, and I didn't see it clearly at the time.
<mark_weaver>yeah, my current design here is not so good.
<jcca>Hi, is there http://paste.lisp.org/+34DC error when I want build hello 'guix build hello' or vm
<bavier`>jcca: is the error reproducible?
<jcca>yep
<jcca>bavier`: same error every time
<mark_weaver>jcca: it could be related to the kernel you're using on the host system.
<mark_weaver>what kernel version, and what platform (i686 or x86_64)?
<jcca>maybe downgrade to 3.18.4
<mark_weaver>I wouldn't
<jcca>3.18.5 x86_64
<mark_weaver>hmm
<mark_weaver>you're running guix-daemon as root?
<jcca>yeah
<jcca>guix was working properly
<mark_weaver>dunno, I'm at a loss
<bavier`>is it possible to get at the derivation for an unpatched origin?
<civodul>mark_weaver: yay for wicd!
<civodul>bavier`: there's no direct API for that, but it's doable
<civodul>it was purposefully "hidden", actually
*civodul -> zZz
<civodul>happy hacking, good night/day, etc.! :-)
<jxself>Good night sir.
<jgrant>Is there room for Docker and/or applications to provide functionality outside of Guix, or is it almost entirely a replacement for such things?
<mark_weaver>IMO, it's a replacement for such things
<mark_weaver>but civodul is the person to ask