[00:40] <lifeless> james_w: are you still up?
[00:46] <highvoltage> #ubuntu-devel is quite different when you're in a US timezone
[01:43] <kees> is initramfs-tools stuck in binary NEW?
[01:46] <kees> hm, no...
[01:46] <kees> is the publisher just being slow?
[01:49] <ScottK> Might have been affected by the LP downtime.
[07:02] <pitti> 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] <ricotz> pitti, good morning
[08:03] <ronc> hi devs
[08:04] <ronc> I just wanted to say that some man pages are not being updated since the early days of ubuntu
[08:04] <dholbach> good morning
[08:06] <ronc> 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] <ronc> which is like crazy, man
[08:20] <pitti> cking: good morning
[08:21] <pitti> cking: wrt. bug 599352, does linux' suspend-to-disk use compression at all?
[08:24] <cking> pitti, as far as I know, there is no compression used in hibernation
[08:25] <cking> it just dumps the used pages + some meta data
[08:25] <pitti> cking: thanks
[10:26] <ev> Am I going insane or should md5sum /dev/sdb /dev/sdb produce identical results (all partitions are unmounted)?
[10:30] <soren> ev: Sounds like a reasonable assumption.
[10:31] <ev> yeah, I've got three usb disks that continuously produce different results.  I guess it must be a bad lot.
[10:31] <ev> soren: thanks
[10:31] <pitti> ev: do you see read errors in dmesg?
[10:31] <soren> 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] <ev> pitti: nope
[10:32] <ev> hmm
[10:56] <ricotz> pitti, could you please accept the docky sru upload? or is there something wrong? https://bugs.edge.launchpad.net/docky/+bug/579049
[10:57] <pitti> ricotz: I'm not doing SRU every day, just once a week or so (I'm not in platform this cycle)
[10:57] <cjwatson> I can have a look
[10:57] <pitti> ricotz: but I'll get to it this week, promised
[10:57] <ricotz> pitti, sorry, ok
[10:57] <ricotz> cjwatson, that would be great
[10:57] <cjwatson> I've been doing them intermittently, just haven't had time to completely keep up
[10:58] <cjwatson> oh, right, it's the one with an infinite number of bugs
[10:58]  * cjwatson watches queuediff DoS his firefox
[10:59] <ricotz> cjwatson, yes, there are quite some fixes
[10:59] <cjwatson> ricotz: is anyone working on getting this into maverick?  in general, fixes should go to maverick first
[11:00] <ricotz> cjwatson, yes, i requested an sync with debian/unstable
[11:00]  * cjwatson looks at the sync queue
[11:00] <ricotz> the packaging in debian/unstable isnt compatible with lucid anymore
[11:01] <cjwatson> ok, I'll process that
[11:01] <Laney> would be nice if someone could accept lhs2tex too
[11:02] <ricotz> Laney, you are always behind my back :P
[11:02] <Laney> I have my own SRUs in addition to yours!
[11:03] <ricotz> Laney, i know
[11:03] <Laney> :)
[11:04] <BlackZ> cjwatson: could you look at bug #600121 when you can ? we're waiting this sync for the ekiga merge, thanks!
[11:06] <cjwatson> oh dear, I should go back to hiding, now everyone wants a piece
[11:07] <BlackZ> heh
[11:07] <Laney> the joys of archive adminship
[11:08] <Laney> did something happen wrt sparc very recently? I see that glib2.0 has no build record there
[11:08] <cjwatson> not that I know of ...
[11:10] <Laney> oh, no it hasn't in the previous uploads either
[11:10] <cjwatson> ISTR lamont killed glib2.0 on sparc because it had a habit of killing the buildd
[11:11] <Laney> ok then, I won't worry about knock-on failures
[11:12] <ricotz> 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] <Laney> new binaries or source packages do
[11:13] <cjwatson> ricotz: docky done (maverick and lucid-proposed)
[11:13] <ricotz> cjwatson, thank you!!!
[11:14] <cjwatson> BlackZ: opal done
[11:14] <BlackZ> cjwatson: thanks
[11:18] <cjwatson> 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] <ricotz> cjwatson, ok, so this will take some time then, currently it breaks my ia32lib build in xorgedgers
[11:23] <cjwatson> Laney: lhs2tex done
[11:23] <cjwatson> ricotz: hopefully not too long - I've scored it up on the other architectures
[11:23] <cjwatson> they should start very shortly
[11:25] <ricotz> cjwatson, ok
[11:25] <Laney> thanks
[11:25] <Laney> the FP lab will appreciate it
[11:25] <cjwatson> FP lab?
[11:26] <Laney> my research group
[11:27] <cjwatson> ah, right
[11:58] <mdz> mvo: is there a way to test a lucid->maverick upgrade of a real system in a sandbox?
[11:59] <mdz> I remember you'd worked on some tools to do that in the past
[11:59] <soren> mdz: update-manager has a -s option: "-s, --sandbox         Test upgrade with a sandbox aufs overlay"
[12:00] <mdz> soren: do you know if it works in lucid?
[12:01] <dholbach> or just check out http://people.canonical.com/~mvo/automatic-upgrade-testing/2010-07-06-15:03:01/ ;-)
[12:01] <soren> 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] <mdz> soren, mvo: it seems to have hosed my system pretty badly ("command not found: ls" and such)
[12:13] <mdz> seems to be getting EPERM on everything
[12:19] <mvo> mdz: a reboot should cure it
[12:19] <mdz> mvo: it has
[12:19] <mvo> mdz: all changes are in /tmp, but it can take a bit until tmp is cleared
[12:20] <mdz> mvo: my /tmp is tmpfs
[12:20] <mvo> mdz: hrm, hrm, sorry for the trouble, the code should check that
[12:20] <mdz> which is why the upgrade failed early (lack of disk space in /tmp)
[12:20] <mdz> is it possible to set an alternative location for the sandbox?
[12:22] <mvo> mdz: it uses tempfile.mkdtemp(), so it should honor TMPDIR in the environment
[12:23] <mdz> mvo: ok, thanks
[12:23] <mvo> mdz let me know how it goes
[12:23] <mdz> 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] <mdz> 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] <mvo> a kernel bug that happens on upgrade
[12:24] <mvo> ?
[12:25] <mdz> mvo: yes
[12:25] <mvo> 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] <mdz> bug 602261
[12:26] <mdz> rickspencer3 saw this as well
[12:26]  * mvo looks
[12:26] <mdz> I thought it was related to apparmor, but apw suspects it may be ext4
[12:26] <mvo> mdz: is it only reproducable on real HW?
[12:26] <mvo> otherwise the auto-upgrade-tester may be helpful
[12:27] <mdz> mvo: I don't know
[12:27] <apw> certainly there are reports of jdb2 being stuck running for over 2 minutes which is abnormal
[12:28] <mvo> 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] <mdz> 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] <mdz> maybe even a combination of them
[12:30]  * mvo nods
[12:31] <mvo> I can create a auto-login profile so that there is a normal session
[12:33] <mdz> apw: interestingly, doing a big dd on this system doesn't bog it down like it does my laptop
[12:33] <mdz> though both are ext4
[12:33] <mdz> this one has a faster disk and less memory
[12:33] <mdz> and is 32-bit
[12:33] <apw> mdz i wonder why that would be, less memory?
[12:33] <mdz> (while the other is 64)
[12:34] <apw> 32bit does have an effect on the kernel memory size
[12:34] <mdz> apw: I get very high CPU utilization (system) and very low I/O wait
[12:34] <mdz> flush-8:16 is the active thread
[12:35] <mdz> on the other system I believe I get high I/O wait
[12:37] <apw> hrm ... i use 64 bit quite a bit and have done an upgrade there without issue (lucid -> maverick)
[13:06] <psurbhi> 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] <Keybuk> psurbhi: we don't really have unreleased/in development repos like that
[13:07] <Keybuk> the latest version is generally just in the archive
[13:08] <Keybuk> if there's a bzr branch, it's possibly lp:ubuntu/mdadm
[13:08] <psurbhi> ok, i checked that.. no bzr branch then. So does it mean that apt-get source mdadm is the latest mdadm package?
[13:09] <amitk> psurbhi: 'rmadison mdadm'
[13:10] <psurbhi> amitk, Keybuk, thanks
[13:10] <Keybuk> psurbhi: yup
[13:10] <psurbhi> ok
[14:27] <LucidFox> I think for the next year's April Fools, I'm going to blog about Ubuntu Genuine Advantage.
[14:27] <LucidFox> With fake activation screens and everything.
[14:30] <mdz> mvo_: /var/log/dist-upgrade/term.log suddenly stopped (in the middle of a line), but the upgrade is continuing to run
[14:30] <mdz> plenty of disk space, no obvious problem
[14:31] <mvo_> oh
[14:31] <mvo_> odd, anything from strace?
[14:32] <mdz> mvo_: it's as if a buffer isn't getting flushed somewhere
[14:32] <mvo_> that is insndbox mode? or nomal?
[14:32] <soren> LucidFox: http://www.linuxgenuineadvantage.org/
[14:32] <mdz> mvo_: normal
[14:32] <mdz> mvo_: strace of the maverick process shows write(11, "pmstatus:ure:70.6563:Installed u"..., 35
[14:33] <mvo_> mdz: ok, that looks normal
[14:33] <LucidFox> "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] <LucidFox> Yeah, that's WGA in a nutshell
[14:33] <mvo_> mdz: do you have apt-term as well? and if so, is that keep getting updated?
[14:33] <mdz> mvo_: but there is no activity in strace even though dpkg is completing more operations
[14:33] <mdz> mvo_: I have a tail -f running on /var/log/dist-upgrade/*.log and nothing is changing
[14:33] <mdz> mvo_: the terminal window is not updating either
[14:34] <mdz> (the one inside the upgrader)
[14:34] <soren> LucidFox: LGA doesn't work with upstart, though.
[14:34] <LucidFox> Hmmmm *scribble scribble*
[14:34] <LucidFox> soren> You know...
[14:35] <LucidFox> Now I'm actually tempted to write an actual GUI system for Ubuntu mimicking WGA. Deliberately easily circumventable, of course
[14:35] <soren> LucidFox: sorry :)
[14:35] <mdz> 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] <LucidFox> Sorry? :)
[14:35] <mdz> definitely some buffering issue
[14:35] <soren> LucidFox: Yeah, didn't mean to get you motivated on.. um.. slightly less than useful things :)
[14:36] <mdz> mvo_: I've emailed you the logs
[14:36] <LucidFox> Hah
[14:36] <mvo_> 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] <mvo_> mdz: it looks like there are some issues in p-apt itself, nothing too scary so far fortunately, all easily work-aroundable
[14:40] <mdz> mvo_: there seem to be two upgrader processes, and the child is blocking writing to the pipe to the parent
[14:41] <mdz> 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] <mvo_> mdz: thanks, got the logs.
[14:42] <mvo_> mdz: which frontend did you use? text? gtk? I will try to reproduce in a vm
[14:42] <mdz> mvo_: GTK
[15:12] <tseliot> cjwatson: do you have news on bug #258486?
[15:13] <cjwatson> tseliot: no, sorry - please check with ev though
[15:13] <cjwatson> I've not been doing much on ubiquity this cycle
[15:14] <cjwatson> and he's reworking jockey handling anyway, iirc
[15:14] <tseliot> cjwatson: yes, that's why I asked but I was looking for "evand" not "ev". Thanks
[15:19] <kirkland> pitti: howdy, around?
[15:19] <pitti> kirkland: hey, how are you? I'm in the OEM meeting, but otherwise here, yes
[15:20] <kirkland> 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] <kirkland> pitti: it needed a minor version change in the upload;  i just re-uploaded that to lucid-proposed
[15:21] <kirkland> pitti: i just wanted to make sure the other end didn't slip through the cracks too :-)
[15:21] <pitti> kirkland: ah, thanks; I'll have a look at it
[15:22] <kirkland> pitti: cheers, mate
[15:23] <ev> tseliot: you're seeing something like this on Maverick?
[15:24] <ev> Intrepid was a long time ago :)
[15:25] <tseliot> ev: I haven't tried with Maverick yet. The problem can be reproduced in Lucid though
[15:25] <tseliot> and this makes it more recent ;)
[15:25] <ev> interesting
[15:26] <tseliot> ev: basically xorg.conf remains there but the packages don't
[15:26] <tseliot> but I guess that's already in the report
[15:27] <ev> indeed, I'm quite surprised we haven't heard more people screaming about this
[15:27] <ev> I've bumped the priority and assigned it to myself
[15:29] <tseliot> ev: thanks. Let me know if you need any help for debugging, etc.
[15:30] <ev> sure thing
[15:36] <mdz> mvo_: I sent you a merge request with a  couple of small update-manager fixes I did while looking at this problem
[15:38] <mvo_> thanks mdz
[15:39] <mvo_> merged
[15:39] <mdz> mvo_: one is a documentation fix, the other is a one-line code change (untested but trivial)
[15:47] <apw> cjwatson, the grub boot sexification, are we keeping X on VT7 ?
[15:50] <bankix> Hello.
[15:51] <bankix> 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] <pitti> wgrant: hey, how are you?
[15:57] <pitti> lamont, wgrant: do you happen to know the current state of native soyuz ddeb support?
[15:59] <lamont> pitti: nfc
[15:59] <a_ok> 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
[16:01] <cjwatson> apw: yes
[16:01] <a_ok> 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] <cjwatson> (to the best of my knowledge)
[16:02] <ogra> apw, sexification ? will it be male or female after that ?
[16:03] <apw> 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] <apw> then if you fiddle manually mid-boot you get the normal behaviour too
[16:03] <a_ok> this is the exact error I get when trying to boot http://pastebin.com/3UXhaPKu
[16:04] <cjwatson> apw: breaking VT switching definitely isn't on
[16:04] <cjwatson> apw: remember that server boots won't have a VT switch but will have plymouth and the grub splash, though
[16:04] <cjwatson> apw: so I'm not sure that's the right trigger
[16:05] <apw> cjwatson, hrm, then i suspect i will need to be told you are clear
[16:05] <cjwatson> apw: how about plymouth's switch to KD_TEXT?
[16:05] <cjwatson> that seems like a good indicator
[16:05] <apw> cjwatson, i presume it only does that on non-desktop
[16:05] <apw> oh perhaps also on timeout ?
[16:05] <cjwatson> we always switch back to KD_TEXT at some point, even if it's only when people do ctrl-alt-f1 fromX
[16:06] <a_ok> is there a way I can get some more information on what goes wrong?
[16:06] <apw> cjwatson, well no you don't change mode then you change which vt is displayed which is in a different mode
[16:07] <apw> 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] <apw> i thin
[16:07] <apw> i think
[16:07] <cjwatson> that seems fair
[16:07] <cjwatson> apw: vt1 is switched to KD_TEXT even on desktop boots, I believe
[16:07] <cjwatson> bloody well ought to be anyway
[16:07] <apw> once i figure out why vt2 ->6 are all full of vomit of course i can smarten things up
[16:08] <apw> 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] <cjwatson> plymouth is on vt1
[16:10] <cjwatson> we switch to vt7 when X starts
[16:10] <apw> cjwatson, so if we vt switch to the same contents that is scemeless ?
[16:10] <apw> visually ?
[16:11] <apw> ie. plymouth maks vt1 purple, x starts on vt7 and copies the contents over, then vt switches ?
[16:11] <cjwatson> 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] <apw> cjwatson, i suspect that as you said you don't have KMS therefore you cannot do a seemless cut
[16:12] <apw> i will get this heap installed on some kms h/w and see what happens there
[16:12] <pitti> 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] <YokoZar> 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] <pitti> kirkland: (or at least committed to bzr)
[16:12] <apw> cjwatson, what do you use to take the video of the VM ?
[16:12] <cjwatson> apw: gtk-recordmydesktop
[16:12] <pitti> YokoZar: right, but as long as nobody does that, copying the SRU is better than nothing
[16:13] <cjwatson> apw: by way of scoping I'm intentionally only caring about the period until plymouth comes up
[16:13] <kirkland> Daviey: you've been managing that one ... can you tell us if that code has been applied to maverick?
[16:13] <YokoZar> 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] <kirkland> Daviey: i suspect it has, in the course of your regular weekly Eucalyptus merges
[16:13] <apw> cjwatson, yeah, but sadly i have to care thorugh KMS to make sure i am not breaking that by munching the kernel
[16:13] <kirkland> Daviey: can you check?
[16:13] <cjwatson> apw: ah, fair enough
[16:14] <pitti> YokoZar: no, I didn't mean "you" in particular
[16:14] <YokoZar> pitti: I know that, but I usually do the ia32-libs uploads ;)
[16:14] <pitti> YokoZar: I don't know about the multiarch plan, I'm afraid
[16:14] <Daviey> pitti, Ah.. yes.. -> PM
[16:14] <pitti> YokoZar: it's much faster to do in the DC, though
[16:16] <YokoZar> slangasek might know about multiarch
[16:17] <slangasek> step 1) fix dpkg
[16:29] <pitti> is it just me, or is LP very slow today? (including launchpadlib)
[16:30] <apw> pitti, it was upgraded to a nice shiney version last night i think
[16:30] <sebner> apw: shiny = b0rken? :P
[16:30] <pitti> they forgot to take out the sleep() debugging statements?
[16:30] <sebner> pitti: agreed, slowwww
[16:31] <apw> pitti, it does feel slow, but i am not sure if its more excruciatingly slow than normal
[16:31] <apw> i already want to poke my own eyes out
[16:31] <YokoZar> does anyone know if the new SFTP for PPAs can be done for normal uploads?
[16:31] <YokoZar> to the main repository
[16:31] <Laney> yes
[16:32] <Laney> you have to set incoming to ubuntu, or so geser told me
[16:32] <pitti> apw: it's even slow with the CLI tools on cocoplum, so I guess it's real
[16:32] <YokoZar> Laney: and presumably modify /etc/dput.cf manually
[16:33] <Laney> right
[16:33] <apw> pitti, i am usng edge of course, so my milage is different
[16:33] <pitti> apw: same here
[16:33] <pitti> there, all SRU queues emtpy (except for some disputed uploads)
[16:33] <geser> YokoZar: see http://paste.ubuntu.com/460266/ for my ~/.dput.cf for SFTP uploads
[16:34] <apw> pitti, heh the kernel per
[16:34] <apw> perhaps ?
[16:34] <pitti> that (karmic), and sane
[16:34] <YokoZar> geser: thanks
[16:34] <apw> yep, thats the one
[16:34] <YokoZar> geser: (I need sftp to upload ia32-libs from home otherwise my internet connection hangs forever)
[16:38] <arulalan> 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] <arulalan> i cant post this query in #gcc. it says ' Cannot send to channel'
[16:52] <Chipzz> 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] <Chipzz> 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] <arulalan> Chipzz: Ok sir. i need to write a program using graphics.h header file like turboc. is opengl right choice ?
[17:01] <Chipzz> 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] <Chipzz> but again, this is not the right place to ask.
[17:02] <apw> cjwatson, http://people.canonical.com/~apw/misc/fbcon-handoff.ogv <-- video from my latest test kernel
[17:02] <Chipzz> but if graphics.h refers to sth like VGA/SVGA drawing, the closest thing on linux is SDL I would say
[17:04] <apw> arulalan, normally you can't send to a channel if you arn't registered as owning that nick
[17:16] <cjwatson> apw: not bad
[17:16] <apw> cjwatson, note the cursor only appears when the debugging printk's come out, and they are at KERN_EMERG
[17:19] <cjwatson> incidentally, with this, does the console subsystem start in KD_GRAPHICS or KD_TEXT?
[17:26] <dupondje> 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] <Riddell> dupondje: no librsvg?
[17:26] <dupondje> Riddell: nope
[17:27] <dupondje>  Package: libmagickcore3
[17:27] <Riddell> dupondje: something must depend on it though surely?
[17:35] <dupondje> Riddell: libmagickcore3-extra and libmagickcore-dev depend on librsvg2-dev,
[17:35] <dupondje> libmagickcore3-extra on librsvg2-2, libmagickcore-dev depend on librsvg2-dev
[17:35] <Riddell> dupondje: that seems fine then
[17:36] <dupondje> true :) can you give it a sync ? :)
[17:38] <Riddell> dupondje: what about liblqr-1-0-dev ?
[17:40] <dupondje> Riddell: it was dropped because it wasn't in main, but now it is
[17:41] <Riddell> dupondje: groovy
[17:41] <Riddell> dupondje: synced
[17:44] <dupondje> sweet :)
[17:59] <LucidFox> 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] <nigelb> vish: poke!
[18:00] <vish> nigelb: here? me? o.0
[18:00] <nigelb> vish: ^^ I think thats something ayatana could look at
[18:01] <nigelb> LucidFox wrote this awesome patch to get indicator working with liferea, which we use via ppa for now
[18:01] <vish> LucidFox: tried #ayatana  ?
[18:01] <LucidFox> I did, nobody replied there either
[18:01] <vish> i think tedg already had a patch for that.
[18:02] <LucidFox> Where? It's not on LP
[18:02] <LucidFox> 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] <vish> LucidFox: bug #  , tedg/kenvandine are probably the best people to review it?
[18:04] <vish> LucidFox: its attached to a bug? or just a branch?
[18:04] <LucidFox> bug #540490
[18:05] <nigelb> g63
[18:05] <nigelb> grr
[18:05] <nigelb> window fail again
[18:06] <vish> LucidFox: tedg seems absent today .. :(
[18:07] <nigelb> isn't there a tag for it?
[18:07] <vish> yeah , there is
[18:07] <vish> LucidFox: if no response , jcastro is the next best person who can be poked :)
[18:10] <kenvandine> tedhave you looked at that?
[18:11] <kenvandine> whoops
[18:11] <kenvandine> tedg isn't here :)
[18:11] <kenvandine> LucidFox, ping tedg in #ayatana
[18:14] <vish> kenvandine: thanks  :)
[18:15] <vish> kenvandine: seems LucidFox has been asking about that for a while and no one has responded..
[18:28] <JontheEchidna> 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] <JontheEchidna> 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] <LucidFox> I wonder, how does bash tab completion know when to unwrap to .dsc, when to .changes, and the like?
[18:31] <LucidFox> I noticed that it always tab-completes to .dsc with pbuilder-dist, and to .changes with dput
[18:31] <pitti> LucidFox: you can't upload (dput) a .dsc
[18:31] <pitti> LucidFox: and likewise you can't unpack (dpkg-source -x) a .changes, only a .dsc
[18:31] <pitti> so it's quite obvious
[18:31] <JontheEchidna> dput installs a file for the bash autocomplete to use: /etc/bash_completion.d/dput
[18:31] <pitti> likewise dpkg -i expands in *.deb
[18:31] <geser> LucidFox: it's context-sensitive (i.e. command specific)
[18:31] <LucidFox> I know, but how does bash know which file to tab-complete t-- oh
[18:32] <pitti> ah, yes; completion.d/ rules
[18:32] <JontheEchidna> I imagine the other CLI tools do similar things
[18:33] <mvo_> JontheEchidna: the missing authentication keys for the ppa are most likely the problem
[18:33] <mvo_> JontheEchidna: if you add them the origins should become visible
[18:33] <JontheEchidna> mvo_: ok, neat. thanks
[18:34] <JontheEchidna> Is there a way to manually add the keys without the keyserver.ubuntu.com lookup?
[18:34] <JontheEchidna> oh, the PPA page gives the key, nevermind :)
[18:34] <mvo_> you can manually grab them from launchpad
[18:35] <mvo_> but that is a bit cumbersome
[18:35] <mvo_> is keyserver.u.c timeing out for you?
[18:35] <JontheEchidna> for both software-properties and add-apt-repository, yes
[18:36] <JontheEchidna> the web interface seems to be working though
[18:38] <JontheEchidna> well, the import seems to be working now :)
[18:38] <JontheEchidna> must have fixed itself while I was at lunch
[18:39] <bigon> dhcp 4 is now in debian unstable, any plan to switch to this version for maverick?
[18:41] <JontheEchidna> mvo_: yeah, it's all fine now. Origin and origin labels showing up as expected :)
[18:45] <mvo_> cool
[18:47] <shadeslayer> jcastro: thanks :D
[20:22] <td123> 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:23] <Laney> td123: you better talk to the gnome do developers
[20:24] <td123> Laney: it's an ibus issue btw :)
[22:50] <apachelogger> 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
[22:55] <apachelogger> neversfelde: bug 528259 is on your todo?
[22:57] <bdrung> to which mailing list can i send legal questions?
[22:59] <apachelogger> 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] <JontheEchidna> apachelogger: kk, I was about to message you about noise pollution in that regard, actually :P
[23:01] <geser> bdrung: I'd probably try debian-legal as both Debian and Ubuntu share a great part of a common understanding in licenses
[23:02] <geser> bdrung: and if the questions is very Ubuntu specific, I'd probably mail the TB
[23:02] <bdrung> geser: it's not a license problem. it's a problem with laws.
[23:02] <geser> in what way? can you be more specific?
[23:03] <bdrung> 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] <maxwellian> Oh man, I forgot about Kubuntu tutorials day!
[23:03] <apachelogger> interesting, apparently one can only decline nominations for all packages, despite affected status -.-
[23:03] <Riddell> maxwellian: still going on
[23:04] <apachelogger> yeah, you hijacked my doctor who fan talk channel -.-
[23:04] <maxwellian> Awesome. :)  I wanted to see the packaging one, but I think I missed it.  Anyway, thanks.
[23:04] <apachelogger> JontheEchidna: don't blink! :P
[23:04] <JontheEchidna> not the angels!
[23:04] <apachelogger> in that case...
[23:04] <apachelogger> can anyone here the drums? ;)
[23:05] <apachelogger> s/here/hear
[23:12] <apachelogger> JontheEchidna: muon build fails horribly if debconf stuff is not there :/
[23:12] <lex79> apachelogger: iirc the latest pkg-kde-tools needs the latest dpkg :)
[23:12] <JontheEchidna> apachelogger: don't I have a cmake check for that now?
[23:12] <apachelogger> I really think a find script would be good there :/
[23:12] <apachelogger> JontheEchidna: yeah, just that it will fall because the file is not there
[23:12] <lex79> but I will backport your patch
[23:12] <apachelogger> which is not a good error message :/
[23:13] <apachelogger> lex79: well, you can backport my changes to pkg-kde-tools ;)
[23:13] <apachelogger> lex79: you only need to take the cdbs bits I suppose
[23:13] <lex79> kk
[23:13] <lex79> I have to redo kdelibs, they uploaded the wrong tarballs
[23:13] <lex79> bah
[23:13] <lex79> 4.5.60 instead of 4.4.92
[23:14] <apachelogger> that is because dirk is using a custom rip off of markey's amarok release script, instead of using my superior rewrite
[23:14] <Riddell> dirk messed up?
[23:14] <JontheEchidna> apachelogger: I will also have to talk to dantti about libdebconf-kde, it currently does not installed a versioned .so, so dh_shlibdeps isn't picking it up as a dependency
[23:15] <lex79> Riddell: he already fixed in ktown, me not yet :)
[23:15] <apachelogger> Riddell: it rarely happens I have been told :)
[23:16] <geser> bdrung: I guess mailing the TB is the best plan. They can forward this to the Canonical lawyer if necessary. I've only found a thread from 2006 but with no clear answer.
[23:16] <apachelogger> JontheEchidna: updating muon is quite the adventure with all those deps ^^
[23:16] <apachelogger> JontheEchidna: search is the broken
[23:16] <JontheEchidna> orly?
[23:16] <apachelogger> JontheEchidna: search for linux -> does not yield linux-* stuff
[23:16] <bdrung> geser: the mail is sent to the TB. let's wait for the results.
[23:16] <Riddell> bdrung: the letterws DCMA would be the reason
[23:17] <Riddell> although ordered as DMCA :)
[23:17] <apachelogger> JontheEchidna: search for linux-image works though
[23:18] <JontheEchidna> apachelogger: it might be that linux-* is below the quality cutoff for "linux" search term
[23:18]  * apachelogger finds that unhandy
[23:18] <apachelogger> oh, while I am at it
[23:18] <JontheEchidna> e.g. other package names/descriptions contain "linux" to place "linux-" below the threshold
[23:18] <apachelogger> what would be cool is to have a button "nuke all old kernels" ^^
[23:18] <JontheEchidna> since "linux" is a more exact match
[23:19] <apachelogger> with such a button I would not mind linux not matching linux-image ;)
[23:19] <geser> Riddell: but wouldn't this only prevent it from entering main/universe? e.g. the DMCA doesn't apply (yet) to Europe (but they might be other laws in Europe that prevent the legal use there)
[23:19] <JontheEchidna> I usually search for "2.6.35" or whatever
[23:19] <apachelogger> even though that is the most appropraite package really :P
[23:19] <apachelogger> JontheEchidna: well, I had a billion billion kernels installed, as noticed earlier
[23:20] <JontheEchidna> lol
[23:20] <apachelogger> spanning across various versions of course
[23:20]  * apachelogger missed mass marking for action on that occasion too :)
[23:20] <Riddell> geser: main and universe are mirrored in the US, and in Europe the Copyright Directive 2001/29/EC makes it illegal here too
[23:21] <bdrung> Riddell: it's in the gray zone in europe.
[23:21] <JontheEchidna> apachelogger: oh oh, try marking the package "gnome" for install :D
[23:21] <JontheEchidna> apachelogger: are you in maverick?
[23:22] <apachelogger> no
[23:22]  * apachelogger needs to do serious development for master Riddell :P
[23:22] <JontheEchidna> I'll have to show you then ^.^
[23:22] <apachelogger> must not have my system broken by lex79 uploading something funny :P
[23:22]  * apachelogger hugs lex79
[23:22] <apachelogger> JontheEchidna: pretty please :)
[23:22] <Riddell> bdrung: Copyright Directive 2001/29/EC is pretty clear
[23:22] <lex79> my stuff is always good
[23:22] <JontheEchidna> apachelogger: http://simplest-image-hosting.net/i0-plasma-desktopv18355-jpg.jpg <- apt-get has the same error, so it's not muon. I suppose I should file a bug
[23:23] <geser> Riddell: does it imply that if a package is illegal in one country with an Ubuntu mirror, it can't be included in main/universe at all?
[23:23] <Riddell> geser: in a country where canonical has an office yes
[23:24] <Riddell> where there's a serious likelyhood of canonical getting sued it won't go in the archive
[23:24] <apachelogger> JontheEchidna: yeah sure, like you couldnt sell this as killer feature :P
[23:24] <JontheEchidna> :P
[23:24]  * apachelogger would buy a product that prevented him from having a billion billion kernels ;)
[23:24] <apachelogger> oh, and associated headers \o/
[23:26] <apachelogger> JontheEchidna: marking foo as purge, where bar depends on foo, will mark bar as remove - IMHO logical assumption should be that bar ought to be purged too (though I suppose a dialog presenting additional changes with a tick box for purging would be best either way)
[23:27] <JontheEchidna> hrm, recursive purge
[23:27] <JontheEchidna> I'd probably have to set an apt setting or something
[23:27] <JontheEchidna> because when you hit that button, you're really only telling that package to purge, then apt takes care of dependencies and you have no say in what it does
[23:28] <JontheEchidna> kinda sucks
[23:28] <apachelogger> meh
[23:28] <apachelogger> more interesting: http://imagebin.ca/view/sbgYh6V.html
[23:29] <apachelogger> can not help but noticing that it orders 19 < 22 < 23 < 20 < 21 < 16
[23:29] <JontheEchidna> that is a lot of headers
[23:29] <apachelogger> that is an interesting way of seeing the world really :)
[23:32] <JontheEchidna> that is some compression: http://simplest-image-hosting.net/i0-plasma-desktopa18355-jpg.jpg
[23:32] <JontheEchidna> (download size vs install size)
[23:33] <JontheEchidna> apt-get agrees, but I had to check to make sure it wasn't a bug :P
[23:33] <apachelogger> imagine if that was all lzma ^^
[23:34] <apachelogger> 3mib vs. 1.2 gib :P
[23:34] <JontheEchidna> :P
[23:34]  * JontheEchidna uses the fancy undo button
[23:35] <JontheEchidna> undo only goes back 20 actions, tho.
[23:35] <JontheEchidna> to save ur RAMz
[23:36] <apachelogger> hm
[23:36] <apachelogger> manually swap it
[23:36] <apachelogger> that way you can go across sessions
[23:36] <apachelogger> imagine that!
[23:37] <apachelogger> you go install foo
[23:37] <apachelogger> test foo
[23:37] <apachelogger> dont like it
[23:37] <apachelogger> open muon again
[23:37] <apachelogger> press undo
[23:37] <apachelogger> and voila!
[23:37] <JontheEchidna> undo gets lost after commit
[23:37] <apachelogger> that would be brilliant I think
[23:37] <apachelogger> JontheEchidna: well, manually rebuild it ;
[23:37] <apachelogger> )
[23:37] <JontheEchidna> but a history log is definitely a good idea
[23:38] <apachelogger> if you log it you can go the extra mile and store it in a format that can be reused for cross session undo ;)
[23:39]  * apachelogger wishes he had a timey wimey detector just to be a bit cooler :/
[23:45] <apachelogger> JontheEchidna: suggestions on bug 554514 ?
[23:46] <JontheEchidna> abandon all hope -> close
[23:46] <apachelogger> other than setting it on fire and run while we can
[23:46] <JontheEchidna> heh
[23:46] <apachelogger> :/
[23:46] <apachelogger> akonadi trunk is a whole different code base -.-
[23:46] <apachelogger> there is not even hope to get that stuff fixed
[23:47] <JontheEchidna> we could start a role playing game where we pose as various different animals and the reportees have to guess which animal we are
[23:47] <JontheEchidna> *reporters
[23:47] <apachelogger> rofl
[23:47] <kees> can an archive admin take a look at the -7 kernel binaries in NEW?
[23:48] <apachelogger> JontheEchidna: so, how do I bring this news to the reports without getting shot? there are 41 people affected, which is mostly because that bug is as inprecise as they get :/
[23:49] <JontheEchidna> apachelogger: bribe an LP admin to silently delete it? :P (just kidding)
[23:50] <ScottK> JontheEchidna: appmenu in action: http://kitterman.com/kubuntu/appmenu1.jpeg
[23:50] <JontheEchidna> oh lovely, it has icons and shortcuts now. (It didn't at UDS)
[23:50] <apachelogger> "due to ethic believes I must not do certain things to dead people, animals or inspects"
[23:51] <apachelogger> s/inspects/insects
[23:51]  * apachelogger really should get more sleep
[23:52] <apachelogger> ScottK: I wonder how that goes under load
[23:52] <ScottK> apachelogger: That's on my netbook, so everythin is always under load it seems.  Not too bad so far.
[23:52] <apachelogger> k
[23:52] <ScottK> Just started playing with it today though.
[23:53] <apachelogger> dbusmenu has some oddish issues when it comes to high load situations, seeing that menus can have loads and loads of entries that is a bit of concern of mine
[23:56] <apachelogger> how kubuntu.org will look on fluffy http://imagebin.ca/view/V-aeXjgi.html \o/
[23:57] <lex79> lol
[23:58] <Riddell> we should just do that for stock kubuntu.org, would give us a new market niche
[23:59] <apachelogger> agreed