IRC channel logs
2015-02-04.log
back to list of logs
<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 ;) <rigelk>lint requires… guess what ? -> gnutls, which I, ehm, haven’t yet setup properly ^^' <mark_weaver>after you think it's all set, can you paste the final version somewhere? *mark_weaver wants to resume work on wicd <rigelk>do you want the standalone version or the one embedded in python.scm ? <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>’seen that #:use-module (gun packages) appears twice <mark_weaver>although 'package-with-python2' won't work here, unfortunately. <mark_weaver>I think maybe you are misread (guix packages) as (gnu packages) <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>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>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 <mark_weaver>Sleep_Walker: let me take a look, but if so it should go in the wip-gnutls branch <mark_weaver>rigelk: there's an extra close parenthesis at the end of the #:use-modules line. does this actually compile? <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'. <rigelk>desc is just what python-dbus devs tell on their website <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. » <rigelk>to reduce the number of columns, I but the actual desc under the description attribute <mark_weaver>yes, that's a good idea. and also, it's okay to put newlines in that string literal. <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>rigelk: the description looks good, but the string-append is not indented right <mark_weaver>put the first argument to 'string-append' directly below the 'string-append'. <mark_weaver>and then put the other two arguments next to each other on the line after that. <mark_weaver>so "version" should be lined up with the first argument (string literal) *mark_weaver goes afk for a bit, but will be back soon <rigelk>mark_weaver, I’ll go to sleep for now <rigelk>mail w/patch sent to your commit adress, mark_weaver. i’ll come back tomorrow for wicd ;) <kete>A couple of us are getting kernel panics after installing 0.8.1. <kete>I'll make sure it's the same <kete>mark_weaver, yes, same Call Trace <mark_weaver>so the installer booted, but then after installing the system, the first boot failed? <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>so it should be stored in /gnu/store/...-connman-1.28/etc/dbus-1/system.d instead <mark_weaver>okay, and now I have a 'wicd-service' that works fairly well :) <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 <mark_weaver>in fact, I made ~/bin/guix a little shell script that just does this: <mark_weaver>anyway, I sent patches for wicd and wicd-service to guix-devel, and now must sleep.. 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>andreoss`: could you please file a bug and request documentation improvement? <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? <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 <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. <mark_weaver>IMO, I think we should abandon this clever way to save a few characters and make three real links. <rigelk>mark_weaver, i’ve just seen the update. nice work on wicd :) <mark_weaver>wicd was *much* more difficult to package than I would have guessed. <rigelk>looking at the timestamp of your patchh, indeed ^^ <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 <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>btw, is there a package i can take as an example on how to do such a configure phase replacement ? <rigelk>seems appropriated mark_weaver, thanks <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 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. <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>but that would be trivial to implement <civodul>andreoss`: could you mail your request to bug-guix@gnu.org? <jgrant>We have an installer image, I wouldn't really call that a LiveCd unless I've missed some news. <iMn00b>it was fr the add in the list of FSF-endorsed distros <iMn00b>does anyone have a link to FOSDEM video ? <jgrant>iMn00b: It probably didn't get recorded, from what I've heard -- sadly. <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 ? <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. <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>it seems like they had a very sophisticated setup that just flopped. <iMn00b>mark_weaver, ok, you could have recorded <civodul>then there are like 30+ tracks in parallel, so if something goes wrong, you're screwed <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>davexunit, oh it should be HD and fully quality <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 <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 <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 <iMn00b>then it is going to be pathetic quality video again <iMn00b>Ok then you would end up more or less like FOSDEM <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>hope you guys do my plan as your backup plan <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>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 <davexunit>my focus is mainly going to be on the web aspect, naturally. <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>I would gladly take you up on that offer once travelling becomes a bit easier around here :) <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. <mark_weaver>I might be able to act as one of those redundant backups, on either my Libreboot X60 or my X200. <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. <mark_weaver>I could probably borrow WMBR's nice USB-audio adapter, and I have a USB camera that's fairly decent. <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>well, it might already be good enough, dunno. would have to test <jxself>mark_weaver: So you need an RT kernel then? <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?) <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) <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. <mark_weaver>maybe we should rename the kernel config files to include the major+minor version number. WDYT? <jxself>Those could be re-used as-is (except for the names.) <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. <jxself>Will RT be considered one? I assume? <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. <jxself>Yeah, that was why I was originally looking into the inherit thing. <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 then linux-libre just calls it with the right parameters <mark_weaver>in this case, it turns out to be much simpler this way. <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 <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. <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>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>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. <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. <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 <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. <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 <jcca>guix was working properly <bavier`>is it possible to get at the derivation for an unpatched origin? <civodul>bavier`: there's no direct API for that, but it's doable <civodul>it was purposefully "hidden", actually <civodul>happy hacking, good night/day, etc.! :-) <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?