[00:40] james_w: are you still up? [00:46] #ubuntu-devel is quite different when you're in a US timezone === bjf is now known as bjf[afk] === Chex changed the topic of #ubuntu-devel to: Alpha-2 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs === Chex changed the topic of #ubuntu-devel to: Alpha-2 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [01:43] is initramfs-tools stuck in binary NEW? [01:46] hm, no... [01:46] is the publisher just being slow? [01:49] Might have been affected by the LP downtime. === rootusr is now known as tutux === tutux is now known as tutuxg === jjohansen is now known as jjohansen-afk === bjf[afk] is now known as bjf === j1mc is now known as j1mc|away === bjf is now known as bjf[afk] === bjf[afk] is now known as bjf === rootusr is now known as tutuxg === un214_ is now known as un214 === v is now known as vorian [07:02] achiang: no, debian.tar.gz is created automatically, no need to fuss with that; you just need to apply the patch (quilt push -a) before building binaries [07:09] pitti, good morning === freeflyi1g is now known as freeflying [08:03] hi devs [08:04] I just wanted to say that some man pages are not being updated since the early days of ubuntu [08:04] good morning [08:06] I was trying to browse in w3m the other day, but couldn't find the items that these websites told me... then wham! I found this bug report: https://bugs.launchpad.net/w3m/+bug/525360 [08:06] Launchpad bug 525360 in w3m (Ubuntu) "Man page isn't synchronized" [Undecided,Confirmed] [08:06] which is like crazy, man [08:20] cking: good morning [08:21] cking: wrt. bug 599352, does linux' suspend-to-disk use compression at all? [08:21] Launchpad bug 599352 in upower (Ubuntu) "[Maverick] Need to not display hibernation in UI if do not have enough swap space" [Low,Confirmed] https://launchpad.net/bugs/599352 [08:24] pitti, as far as I know, there is no compression used in hibernation [08:25] it just dumps the used pages + some meta data [08:25] cking: thanks === fddfoo is now known as fdd === almaisan-away is now known as al-maisan === DrPepperKid is now known as MacSlow [10:26] Am I going insane or should md5sum /dev/sdb /dev/sdb produce identical results (all partitions are unmounted)? [10:30] ev: Sounds like a reasonable assumption. [10:31] yeah, I've got three usb disks that continuously produce different results. I guess it must be a bad lot. [10:31] soren: thanks [10:31] ev: do you see read errors in dmesg? [10:31] ev: Have you had anything from sdb mounted since your last reboot? Perhaps there's some cache flushing going on that's massing things up. [10:32] pitti: nope [10:32] hmm === amitk is now known as amitk-afk [10:56] pitti, could you please accept the docky sru upload? or is there something wrong? https://bugs.edge.launchpad.net/docky/+bug/579049 [10:56] Launchpad bug 579049 in docky (Ubuntu Lucid) "Dragging files to folders causes data "corruption"" [Undecided,New] [10:57] ricotz: I'm not doing SRU every day, just once a week or so (I'm not in platform this cycle) [10:57] I can have a look [10:57] ricotz: but I'll get to it this week, promised [10:57] pitti, sorry, ok [10:57] cjwatson, that would be great [10:57] I've been doing them intermittently, just haven't had time to completely keep up [10:58] oh, right, it's the one with an infinite number of bugs [10:58] * cjwatson watches queuediff DoS his firefox [10:59] cjwatson, yes, there are quite some fixes [10:59] ricotz: is anyone working on getting this into maverick? in general, fixes should go to maverick first [11:00] cjwatson, yes, i requested an sync with debian/unstable [11:00] * cjwatson looks at the sync queue [11:00] the packaging in debian/unstable isnt compatible with lucid anymore [11:01] ok, I'll process that [11:01] would be nice if someone could accept lhs2tex too [11:02] Laney, you are always behind my back :P [11:02] I have my own SRUs in addition to yours! [11:03] Laney, i know [11:03] :) [11:04] cjwatson: could you look at bug #600121 when you can ? we're waiting this sync for the ekiga merge, thanks! [11:04] Launchpad bug 600121 in opal (Ubuntu) "Sync opal 3.6.8~dfsg-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/600121 [11:06] oh dear, I should go back to hiding, now everyone wants a piece [11:07] heh [11:07] the joys of archive adminship [11:08] did something happen wrt sparc very recently? I see that glib2.0 has no build record there [11:08] not that I know of ... [11:10] oh, no it hasn't in the previous uploads either === smb is now known as smb-afk [11:10] ISTR lamont killed glib2.0 on sparc because it had a habit of killing the buildd [11:11] ok then, I won't worry about knock-on failures [11:12] do built packages need to be accepted manually like https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.7.0~beta1+git20100706-0ubuntu1 ? [11:13] new binaries or source packages do [11:13] ricotz: docky done (maverick and lucid-proposed) [11:13] cjwatson, thank you!!! [11:14] BlackZ: opal done [11:14] cjwatson: thanks [11:18] ricotz: qt> I'd like to accept all architectures at once if possible, to minimise the chance of build failures due to them being out of sync [11:21] cjwatson, ok, so this will take some time then, currently it breaks my ia32lib build in xorgedgers [11:23] Laney: lhs2tex done [11:23] ricotz: hopefully not too long - I've scored it up on the other architectures [11:23] they should start very shortly [11:25] cjwatson, ok [11:25] thanks [11:25] the FP lab will appreciate it [11:25] FP lab? [11:26] my research group [11:27] ah, right [11:58] mvo: is there a way to test a lucid->maverick upgrade of a real system in a sandbox? [11:59] I remember you'd worked on some tools to do that in the past [11:59] mdz: update-manager has a -s option: "-s, --sandbox Test upgrade with a sandbox aufs overlay" [12:00] soren: do you know if it works in lucid? [12:01] or just check out http://people.canonical.com/~mvo/automatic-upgrade-testing/2010-07-06-15:03:01/ ;-) [12:01] mdz: Nope, never used it. The option is available on Lucid, though. [12:01] * mdz notices --sandbox isn't documented on the man page, and prepares a branch [12:12] soren, mvo: it seems to have hosed my system pretty badly ("command not found: ls" and such) [12:13] seems to be getting EPERM on everything [12:19] mdz: a reboot should cure it [12:19] mvo: it has [12:19] mdz: all changes are in /tmp, but it can take a bit until tmp is cleared [12:20] mvo: my /tmp is tmpfs [12:20] mdz: hrm, hrm, sorry for the trouble, the code should check that [12:20] which is why the upgrade failed early (lack of disk space in /tmp) [12:20] is it possible to set an alternative location for the sandbox? [12:22] mdz: it uses tempfile.mkdtemp(), so it should honor TMPDIR in the environment [12:23] mvo: ok, thanks [12:23] mdz let me know how it goes [12:23] mvo: having a non-functional $PATH will make it difficult to monitor the upgrade, which is a pain because I'm trying to reproduce a kernel bug [12:24] mvo: (the disk free space was correctly checked, that worked fine. it's just that my system was still non-functional after the upgrade was canceled) [12:24] a kernel bug that happens on upgrade [12:24] ? [12:25] mvo: yes [12:25] mdz: the --sandbox option did not got a lot of love because aufs is not really suitable for the workload. this is why its a bit bumpy [12:25] bug 602261 [12:25] Launchpad bug 602261 in linux (Ubuntu) "Thrashing and OOM during upgrade from 10.04 to Maverick" [High,Confirmed] https://launchpad.net/bugs/602261 [12:26] rickspencer3 saw this as well [12:26] * mvo looks [12:26] I thought it was related to apparmor, but apw suspects it may be ext4 [12:26] mdz: is it only reproducable on real HW? [12:26] otherwise the auto-upgrade-tester may be helpful [12:27] mvo: I don't know [12:27] certainly there are reports of jdb2 being stuck running for over 2 minutes which is abnormal [12:28] mdz: http://people.canonical.com/~mvo/automatic-upgrade-testing/current/ shows that a server upgrade (minimal server) is about 10min, ubuntu 30min, so total runtime seems to be not a good indicator [12:29] mvo: I suspect it may be related to any/all of a) running processes (i.e. a normal user session), b) replacing apparmor profiles, or c) the idle I/O scheduler (ionice -c3) [12:30] maybe even a combination of them [12:30] * mvo nods [12:31] I can create a auto-login profile so that there is a normal session [12:33] apw: interestingly, doing a big dd on this system doesn't bog it down like it does my laptop [12:33] though both are ext4 [12:33] this one has a faster disk and less memory [12:33] and is 32-bit === amitk-afk is now known as amitk [12:33] mdz i wonder why that would be, less memory? [12:33] (while the other is 64) [12:34] 32bit does have an effect on the kernel memory size [12:34] apw: I get very high CPU utilization (system) and very low I/O wait [12:34] flush-8:16 is the active thread [12:35] on the other system I believe I get high I/O wait [12:37] hrm ... i use 64 bit quite a bit and have done an upgrade there without issue (lucid -> maverick) === al-maisan is now known as almaisan-away === smb-afk is now known as smb === MacSlow is now known as MacSlow|lunch [13:06] i wanted to know where I could pick the latest unreleased (or in development) mdadm source package for maverick. Is there a bzr repository for mdadm? where would that be? [13:07] psurbhi: we don't really have unreleased/in development repos like that [13:07] the latest version is generally just in the archive [13:08] if there's a bzr branch, it's possibly lp:ubuntu/mdadm [13:08] ok, i checked that.. no bzr branch then. So does it mean that apt-get source mdadm is the latest mdadm package? [13:09] psurbhi: 'rmadison mdadm' [13:10] amitk, Keybuk, thanks [13:10] psurbhi: yup [13:10] ok === cking is now known as cking-afk === yofel_ is now known as yofel === almaisan-away is now known as al-maisan === MacSlow|lunch is now known as MacSlow [14:27] I think for the next year's April Fools, I'm going to blog about Ubuntu Genuine Advantage. [14:27] With fake activation screens and everything. [14:30] mvo_: /var/log/dist-upgrade/term.log suddenly stopped (in the middle of a line), but the upgrade is continuing to run [14:30] plenty of disk space, no obvious problem [14:31] oh [14:31] odd, anything from strace? [14:32] mvo_: it's as if a buffer isn't getting flushed somewhere [14:32] that is insndbox mode? or nomal? [14:32] LucidFox: http://www.linuxgenuineadvantage.org/ [14:32] mvo_: normal [14:32] mvo_: strace of the maverick process shows write(11, "pmstatus:ure:70.6563:Installed u"..., 35 [14:33] mdz: ok, that looks normal [14:33] "According to an independent study conducted by some scientists, many users of Linux are running non-Genuine versions of their operating system. This puts them at the disadvantage of having their computers work normally, without periodically phoning home unannounced to see if it's OK for their computer to continue functioning." [14:33] Yeah, that's WGA in a nutshell [14:33] mdz: do you have apt-term as well? and if so, is that keep getting updated? [14:33] mvo_: but there is no activity in strace even though dpkg is completing more operations [14:33] mvo_: I have a tail -f running on /var/log/dist-upgrade/*.log and nothing is changing [14:33] mvo_: the terminal window is not updating either [14:34] (the one inside the upgrader) [14:34] LucidFox: LGA doesn't work with upstart, though. [14:34] Hmmmm *scribble scribble* [14:34] soren> You know... [14:35] Now I'm actually tempted to write an actual GUI system for Ubuntu mimicking WGA. Deliberately easily circumventable, of course [14:35] LucidFox: sorry :) [14:35] mvo_: hmm, it just dumped about 2k of text into term.log and apt-term.log, all at once, and then stopped again [14:35] Sorry? :) [14:35] definitely some buffering issue [14:35] LucidFox: Yeah, didn't mean to get you motivated on.. um.. slightly less than useful things :) [14:36] mvo_: I've emailed you the logs [14:36] Hah [14:36] mdz: thanks, I'm working on the code currently (to port to the latest python-apt 0.8 api), that is going to be interessting :) [14:37] mdz: it looks like there are some issues in p-apt itself, nothing too scary so far fortunately, all easily work-aroundable [14:40] mvo_: there seem to be two upgrader processes, and the child is blocking writing to the pipe to the parent [14:41] mvo_: two things look weird to me: 1) the parent still has both ends of the pipe open, and 2) the parent is polling but it doesn't seem to be polling this FD [14:41] mdz: thanks, got the logs. [14:42] mdz: which frontend did you use? text? gtk? I will try to reproduce in a vm === cking-afk is now known as cking [14:42] mvo_: GTK === rgreening_ is now known as rgreening === rgreening is now known as rgreening_ === rgreening_ is now known as rgreening [15:12] cjwatson: do you have news on bug #258486? [15:12] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/258486) [15:13] tseliot: no, sorry - please check with ev though [15:13] I've not been doing much on ubiquity this cycle [15:14] and he's reworking jockey handling anyway, iirc [15:14] cjwatson: yes, that's why I asked but I was looking for "evand" not "ev". Thanks [15:19] pitti: howdy, around? [15:19] kirkland: hey, how are you? I'm in the OEM meeting, but otherwise here, yes [15:20] pitti: awesome, i'm okay ... i just realized a libvirt SRU that has slipped through the cracks for me for ~1 month: https://bugs.edge.launchpad.net/ubuntu/+source/multipath-tools/+bug/571093 [15:20] Launchpad bug 571093 in libvirt (Ubuntu Lucid) "[SRU] multipath + libvirtd eats away more memory over time" [Medium,In progress] [15:20] pitti: it needed a minor version change in the upload; i just re-uploaded that to lucid-proposed [15:21] pitti: i just wanted to make sure the other end didn't slip through the cracks too :-) [15:21] kirkland: ah, thanks; I'll have a look at it [15:22] pitti: cheers, mate [15:23] tseliot: you're seeing something like this on Maverick? [15:24] Intrepid was a long time ago :) [15:25] ev: I haven't tried with Maverick yet. The problem can be reproduced in Lucid though [15:25] and this makes it more recent ;) [15:25] interesting [15:26] ev: basically xorg.conf remains there but the packages don't [15:26] but I guess that's already in the report [15:27] indeed, I'm quite surprised we haven't heard more people screaming about this [15:27] I've bumped the priority and assigned it to myself [15:29] ev: thanks. Let me know if you need any help for debugging, etc. [15:30] sure thing [15:36] mvo_: I sent you a merge request with a couple of small update-manager fixes I did while looking at this problem [15:38] thanks mdz [15:39] merged [15:39] mvo_: one is a documentation fix, the other is a one-line code change (untested but trivial) [15:47] cjwatson, the grub boot sexification, are we keeping X on VT7 ? === sconklin-gone is now known as sconklin [15:50] Hello. [15:51] I'm currently customizing Lucid, but however I'm unable to find out which file is responsible for the little ubuntu logo in the upper left corner of the gnome panel. Could you give me a pointer? [15:57] wgrant: hey, how are you? [15:57] lamont, wgrant: do you happen to know the current state of native soyuz ddeb support? === thekorn_ is now known as thekorn [15:59] pitti: nfc [15:59] I still seem to have the problem that looks a lot like https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/546964 . I am using an Intel ET Nic and I have confirmed that the igb.ko driver is in the initrd image [15:59] Launchpad bug 546964 in initramfs-tools (Ubuntu) "10.04 beta1 iSCSI-on-root fails on boot" [High,Fix released] [16:01] apw: yes [16:01] I am using the stable 10.4 release by the way and the latest initramfs-tools seems to be the one that comes with it (0.92ubuntu78) [16:01] (to the best of my knowledge) [16:02] apw, sexification ? will it be male or female after that ? [16:03] cjwatson, the kernel patches as were break VTs basically for good. we really want the special functionality to remain only till we are on VT7 and settled in, i am thinking a VT switch may be the correct trigger to return normal behviour [16:03] then if you fiddle manually mid-boot you get the normal behaviour too [16:03] this is the exact error I get when trying to boot http://pastebin.com/3UXhaPKu [16:04] apw: breaking VT switching definitely isn't on [16:04] apw: remember that server boots won't have a VT switch but will have plymouth and the grub splash, though [16:04] apw: so I'm not sure that's the right trigger [16:05] cjwatson, hrm, then i suspect i will need to be told you are clear [16:05] apw: how about plymouth's switch to KD_TEXT? [16:05] that seems like a good indicator [16:05] cjwatson, i presume it only does that on non-desktop [16:05] oh perhaps also on timeout ? [16:05] we always switch back to KD_TEXT at some point, even if it's only when people do ctrl-alt-f1 fromX [16:06] is there a way I can get some more information on what goes wrong? [16:06] cjwatson, well no you don't change mode then you change which vt is displayed which is in a different mode [16:07] cjwatson, anyhow i am getting ahead. i suspect a switch from graphics mode to text within a VT or switching VT should trigger normality [16:07] i thin [16:07] i think [16:07] that seems fair [16:07] apw: vt1 is switched to KD_TEXT even on desktop boots, I believe [16:07] bloody well ought to be anyway [16:07] once i figure out why vt2 ->6 are all full of vomit of course i can smarten things up [16:08] cjwatson, so can you tell me when we switch to vt7 and which thing plymouth is on, i thought it was on vt7 [16:09] plymouth is on vt1 [16:10] we switch to vt7 when X starts [16:10] cjwatson, so if we vt switch to the same contents that is scemeless ? [16:10] visually ? [16:11] ie. plymouth maks vt1 purple, x starts on vt7 and copies the contents over, then vt switches ? [16:11] X is *supposed* to take care of that; it didn't seem to quite work in my video but I am deliberately not caring about that [16:12] cjwatson, i suspect that as you said you don't have KMS therefore you cannot do a seemless cut [16:12] i will get this heap installed on some kms h/w and see what happens there [16:12] kirkland: do you know the status of bug 566792 in maverick: the SRU is ready for -updates, but I won't as long as it's not yet fixed in maverick [16:12] pitti: you probably don't need to copy the SRUed ia32-libs to maverick, as it needs to be freshly generated there to get the maverick versions of the libs [16:12] Launchpad bug 566792 in eucalyptus (Ubuntu) "metadata service returns empty data with 200 OK" [High,Confirmed] https://launchpad.net/bugs/566792 [16:12] kirkland: (or at least committed to bzr) [16:12] cjwatson, what do you use to take the video of the VM ? [16:12] apw: gtk-recordmydesktop [16:12] YokoZar: right, but as long as nobody does that, copying the SRU is better than nothing [16:13] apw: by way of scoping I'm intentionally only caring about the period until plymouth comes up [16:13] Daviey: you've been managing that one ... can you tell us if that code has been applied to maverick? [16:13] pitti: I suppose that somebody is supposed to be me. Is there any movement on multiarch at all in maverick (and thus things that can be dropped from ia32-libs?) [16:13] * Daviey reads [16:13] Daviey: i suspect it has, in the course of your regular weekly Eucalyptus merges [16:13] cjwatson, yeah, but sadly i have to care thorugh KMS to make sure i am not breaking that by munching the kernel [16:13] Daviey: can you check? [16:13] apw: ah, fair enough [16:14] YokoZar: no, I didn't mean "you" in particular [16:14] pitti: I know that, but I usually do the ia32-libs uploads ;) [16:14] YokoZar: I don't know about the multiarch plan, I'm afraid [16:14] pitti, Ah.. yes.. -> PM [16:14] YokoZar: it's much faster to do in the DC, though [16:16] slangasek might know about multiarch [16:17] step 1) fix dpkg [16:29] is it just me, or is LP very slow today? (including launchpadlib) === Amto_res_ is now known as Amto`OFF [16:30] pitti, it was upgraded to a nice shiney version last night i think [16:30] apw: shiny = b0rken? :P [16:30] they forgot to take out the sleep() debugging statements? [16:30] pitti: agreed, slowwww [16:31] pitti, it does feel slow, but i am not sure if its more excruciatingly slow than normal [16:31] i already want to poke my own eyes out [16:31] does anyone know if the new SFTP for PPAs can be done for normal uploads? [16:31] to the main repository [16:31] yes [16:32] you have to set incoming to ubuntu, or so geser told me [16:32] apw: it's even slow with the CLI tools on cocoplum, so I guess it's real [16:32] Laney: and presumably modify /etc/dput.cf manually [16:33] right [16:33] pitti, i am usng edge of course, so my milage is different [16:33] apw: same here [16:33] there, all SRU queues emtpy (except for some disputed uploads) [16:33] YokoZar: see http://paste.ubuntu.com/460266/ for my ~/.dput.cf for SFTP uploads [16:34] pitti, heh the kernel per [16:34] perhaps ? [16:34] that (karmic), and sane [16:34] geser: thanks [16:34] yep, thats the one [16:34] geser: (I need sftp to upload ia32-libs from home otherwise my internet connection hangs forever) [16:38] Dear All, i have a doubt. How can i write graphics program in GCC. I googled , but cant get good link for this [16:39] i cant post this query in #gcc. it says ' Cannot send to channel' === amitk is now known as amitk-afk === MacSlow is now known as MacSlow|afk [16:52] arulalan: this is not a good question for this channel; but either way, you don't specify what kind of graphics program you want to write (ie plain OpenGL, Gtk+, Qt...) [16:54] arulalan: and if you can't send to the channel, there's probably a very good reason for it (like the channel being moderated); read the topic, it most likely has further instructions (and this goes for any channel, including this one; if you would have read the topic, you would have known your question wasn't appropriate here) [16:56] Chipzz: Ok sir. i need to write a program using graphics.h header file like turboc. is opengl right choice ? [17:01] arulalan: again, your question is not appropriate here. also, a quick google for graphics.h shows a lot of different projects (quite expectable with such a filename) so your question is ambigous [17:01] but again, this is not the right place to ask. [17:02] cjwatson, http://people.canonical.com/~apw/misc/fbcon-handoff.ogv <-- video from my latest test kernel [17:02] but if graphics.h refers to sth like VGA/SVGA drawing, the closest thing on linux is SDL I would say [17:04] arulalan, normally you can't send to a channel if you arn't registered as owning that nick [17:16] apw: not bad [17:16] cjwatson, note the cursor only appears when the debugging printk's come out, and they are at KERN_EMERG [17:19] incidentally, with this, does the console subsystem start in KD_GRAPHICS or KD_TEXT? [17:26] Riddell: I did build imagemagick from debian, and those are the depds: Depends: libbz2-1.0, libc6 (>= 2.11), libfontconfig1 (>= 2.8.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.12.0), libgomp1 (>= 4.2.1), libice6 (>= 1:1.0.0), libjasper1 (>= 1.900.1), libjpeg62, liblcms1 (>= 1.15-1), liblqr-1-0 (>= 0.1.0), libltdl7 (>= 2.2.6b), libpng12-0 (>= 1.2.13-4), libsm6, libtiff4, libx11-6, libxext6, libxml2 (>= 2.7.4), libxt6, zlib1g (>= 1:1.2.3.3.dfsg) [17:26] dupondje: no librsvg? [17:26] Riddell: nope [17:27] Package: libmagickcore3 [17:27] dupondje: something must depend on it though surely? [17:35] Riddell: libmagickcore3-extra and libmagickcore-dev depend on librsvg2-dev, [17:35] libmagickcore3-extra on librsvg2-2, libmagickcore-dev depend on librsvg2-dev [17:35] dupondje: that seems fine then [17:36] true :) can you give it a sync ? :) [17:38] dupondje: what about liblqr-1-0-dev ? [17:40] Riddell: it was dropped because it wasn't in main, but now it is [17:41] dupondje: groovy [17:41] dupondje: synced [17:44] sweet :) [17:59] Any chance I could get the Liferea messaging indicator patch reviewed before the heat death of the universe? It's been waiting on LP for two months now and none of the core-devs even acknowledged its existence in the bugreport [18:00] vish: poke! [18:00] nigelb: here? me? o.0 [18:00] vish: ^^ I think thats something ayatana could look at [18:01] LucidFox wrote this awesome patch to get indicator working with liferea, which we use via ppa for now [18:01] LucidFox: tried #ayatana ? [18:01] I did, nobody replied there either [18:01] i think tedg already had a patch for that. [18:02] Where? It's not on LP [18:02] My patch was all over the news, got talked about on Omg! Ubuntu, and I've never seen any other one in a public place. Definitely not on LP, at least [18:04] LucidFox: bug # , tedg/kenvandine are probably the best people to review it? [18:04] LucidFox: its attached to a bug? or just a branch? [18:04] bug #540490 [18:04] Launchpad bug 540490 in liferea (Ubuntu) "liferea should be added to the indicator applet" [Undecided,Confirmed] https://launchpad.net/bugs/540490 [18:05] g63 [18:05] grr [18:05] window fail again [18:06] LucidFox: tedg seems absent today .. :( [18:07] isn't there a tag for it? [18:07] yeah , there is [18:07] LucidFox: if no response , jcastro is the next best person who can be poked :) [18:10] tedhave you looked at that? [18:11] whoops [18:11] tedg isn't here :) [18:11] LucidFox, ping tedg in #ayatana [18:14] kenvandine: thanks :) [18:15] kenvandine: seems LucidFox has been asking about that for a while and no one has responded.. [18:28] So I've added a few PPAs via software-properties, but they do not seem to be showing up in software-center, and the origin as provided by libapt-pkg is empty. Any APT expert have any idea what could cause that? [18:29] One hint that I have is that while adding the PPA, the lookup for keyserver.ubuntu.com fails, but I don't know if that would make apt not see the origin... [18:31] I wonder, how does bash tab completion know when to unwrap to .dsc, when to .changes, and the like? [18:31] I noticed that it always tab-completes to .dsc with pbuilder-dist, and to .changes with dput [18:31] LucidFox: you can't upload (dput) a .dsc [18:31] LucidFox: and likewise you can't unpack (dpkg-source -x) a .changes, only a .dsc [18:31] so it's quite obvious [18:31] dput installs a file for the bash autocomplete to use: /etc/bash_completion.d/dput [18:31] likewise dpkg -i expands in *.deb [18:31] LucidFox: it's context-sensitive (i.e. command specific) [18:31] I know, but how does bash know which file to tab-complete t-- oh [18:32] ah, yes; completion.d/ rules [18:32] I imagine the other CLI tools do similar things [18:33] JontheEchidna: the missing authentication keys for the ppa are most likely the problem [18:33] JontheEchidna: if you add them the origins should become visible [18:33] mvo_: ok, neat. thanks [18:34] Is there a way to manually add the keys without the keyserver.ubuntu.com lookup? [18:34] oh, the PPA page gives the key, nevermind :) [18:34] you can manually grab them from launchpad [18:35] but that is a bit cumbersome [18:35] is keyserver.u.c timeing out for you? [18:35] for both software-properties and add-apt-repository, yes [18:36] the web interface seems to be working though [18:38] well, the import seems to be working now :) [18:38] must have fixed itself while I was at lunch [18:39] dhcp 4 is now in debian unstable, any plan to switch to this version for maverick? === Lutin is now known as Guest14959 === MacSlow|afk is now known as MacSlow [18:41] mvo_: yeah, it's all fine now. Origin and origin labels showing up as expected :) [18:45] cool [18:47] jcastro: thanks :D === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === al-maisan is now known as almaisan-away === fta_ is now known as fta === fta_ is now known as fta [20:22] does anyone know where I can get the source to the mentioned fixed package all the way at the bottom of https://bugs.launchpad.net/do/+bug/591998 ? I'm mainly interested in the patch they applied to fix this bug [20:22] Launchpad bug 591998 in Do "Can't not recive any command" [Undecided,New] [20:23] td123: you better talk to the gnome do developers [20:24] Laney: it's an ibus issue btw :) === fta__ is now known as fta === tkamppeter_ is now known as tkamppeter === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [22:50] lex79: you might want to consider backporting my superior desktop file patch in kde4libs to the PPA, should improve performance quite a bit, especially combined with latest pkg-kde-tools === sconklin is now known as sconklin-gone [22:55] neversfelde: bug 528259 is on your todo? [22:55] Launchpad bug 528259 in kdepim (Ubuntu) "Blogilo "QSqlDatabase: QSQLITE driver not loaded" " [Undecided,New] https://launchpad.net/bugs/528259 [22:57] to which mailing list can i send legal questions? [22:59] JontheEchidna: in case I forget, I booted cia off kubuntu-devel for now, to revert that just set the basic filtering to custom again :) [22:59] apachelogger: kk, I was about to message you about noise pollution in that regard, actually :P === bjf is now known as bjf[afk] [23:01] bdrung: I'd probably try debian-legal as both Debian and Ubuntu share a great part of a common understanding in licenses [23:02] bdrung: and if the questions is very Ubuntu specific, I'd probably mail the TB [23:02] geser: it's not a license problem. it's a problem with laws. [23:02] in what way? can you be more specific? [23:03] geser: then i mail the TB. i want an answer to the question why libdvdcss2 is not in the archive. i found no answer on the web. [23:03] Oh man, I forgot about Kubuntu tutorials day! [23:03] interesting, apparently one can only decline nominations for all packages, despite affected status -.- [23:03] maxwellian: still going on [23:04] yeah, you hijacked my doctor who fan talk channel -.- [23:04] Awesome. :) I wanted to see the packaging one, but I think I missed it. Anyway, thanks. [23:04] JontheEchidna: don't blink! :P [23:04] not the angels! [23:04] in that case... [23:04] can anyone here the drums? ;) [23:05] s/here/hear [23:12] JontheEchidna: muon build fails horribly if debconf stuff is not there :/ [23:12] apachelogger: iirc the latest pkg-kde-tools needs the latest dpkg :) [23:12] apachelogger: don't I have a cmake check for that now? [23:12] I really think a find script would be good there :/ [23:12] JontheEchidna: yeah, just that it will fall because the file is not there [23:12] but I will backport your patch [23:12] which is not a good error message :/ [23:13] lex79: well, you can backport my changes to pkg-kde-tools ;) [23:13] lex79: you only need to take the cdbs bits I suppose [23:13]