[09:53] <Ng> before I file a bug, would encrypted home directory be expected to have worked in yesterday's amd64 alternate daily?
[09:55] <cjwatson> please go ahead and file that
[09:57] <Ng> ok :)
[09:59] <cjwatson> oh, actually
[09:59] <cjwatson> maybe don't bother
[10:00] <cjwatson> bug 395082 seems likely to apply
[10:00] <cjwatson> Ng: ^-
[10:00]  * Ng looks
[10:01] <cjwatson> the lack of sudo access is fixed now, but there was an underlying ecryptfs breakage there too
[10:02] <cjwatson> which didn't seem to me to be especially specific to TheMuso's setup
[10:02] <Ng> I think I have slightly newer looking errors after user-setup, but I guess that just matches up with your comment on that bug
[10:02] <Ng> otherwise it seems to be trying to say the same kinda thing
[10:05] <Ng> thanks :)
[12:53] <CIA-8> debian-installer-utils: cjwatson * r680 ubuntu/debian/changelog: releasing version 1.70ubuntu1
[13:32]  * rgreening cracks code whip... {eyes evand}
[13:33] <evand> rgreening: indeed.  Unfortunately the development machine that I've been using for usb-creator hacking is in pieces scattered about two rooms (new carpets going in today), so I'm afraid I wont be able to work on it until later.
[13:33] <rgreening> gak! :)
[13:33] <rgreening> who said you could remodal :P
[13:33] <rgreening> lol
[13:34] <rgreening> evand: got anything you can push/publish ?
[13:34] <rgreening> oh, nm... scattered...
[13:34] <rgreening> haha
[13:34] <evand> unfortunately not, it's a local bzr branch that I quite stupidly haven't pushed anywhere yet
[13:35] <evand> quite close to doing so though, I did a fair amount of clean up on it this morning before they came to put the carpets in
[13:35] <rgreening> you need a cortical implant... to work directly with the ubu hive
[13:35] <evand> hahaha
[13:35] <rgreening> ;)
[13:36]  * rgreening ponders, does that make mark the borg queen?
[13:40] <evand> star trek humor is lost on me (despite having seen the recent film)
[13:54] <evand> cjwatson: I think https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/396414 is invalid for ubiquity, but do you have differing thoughts, or can you think of a more suitable target for it?  perhaps gnome-app-install?
[13:54] <rgreening> evand: it's one of those genres... either you love it or you hate it... I'm in the former camp
[13:55] <rgreening> though, I cant quote entire movies verbatim like some fans I know
[13:55] <rgreening> :)
[13:55] <evand> heh
[13:56]  * rgreening helps 'put down' the carpet for evand... {BAD CARPET... BAD CARPET...}
[13:56] <evand> haha
[14:01] <cjwatson> evand: yeah, somewhere in the package management frontend system anyway ...
[14:02] <evand> thanks
[16:41] <cjwatson> fader: looking at your logs now ...
[16:41] <cjwatson> (bear with me, I'm trying to upgrade a chroot at the same time)
[16:41] <fader> cjwatson: Thanks.  I have the machine sitting here with the broken install if you need it
[16:42] <fader> cjwatson: No problem -- I'm actually sprinting right now so take your time :)
[16:43] <cjwatson> fader: could you confirm the contents of /lib/modules/ in the installer environment?
[16:44] <cjwatson> just the immediate subdirectory of that
[16:44] <cjwatson> fader: also, which kernel version is listed in /cdrom/pool/main/l/linux/ ?
[16:44] <fader> cjwatson: Will do.... lost my connection so give me 2-3 minutes
[16:53] <fader> cjwatson: ~ # ls /lib/modules/
[16:53] <fader> 2.6.24-24-generic
[16:55] <fader> cjwatson: /cdrom isn't mounted but this is on the NFS server: linux-image-2.6.24-24-server_2.6.24-24.55_amd64.deb
[17:02] <cjwatson> fader: check for kernel-image-*, please?
[17:02] <cjwatson> i.e. udebs not debs
[17:04] <fader> fader@nickel:~/servers.hardy$ ls /srv/enablement/www/cdimage.ubuntu.com/ubuntu-server/hardy/daily/current/hardy-server-amd64/pool/main/l/linux/kernel-image*
[17:04] <fader> oops heh
[17:05] <fader> kernel-image-2.6.24-16-generic-di_2.6.24-16.30_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-17-generic-di_2.6.24-17.31_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-18-generic-di_2.6.24-18.32_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-19-generic-di_2.6.24-19.41_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-20-generic-di_2.6.24-20.38_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-21-generic-di_2.6.24-21.43_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-22-generic-di_2.6.24-22.45_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-23-generic-di_2.6.24-23.52_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-24-generic-di_2.6.24-24.55_amd64.udeb
[17:05] <cjwatson> ok
[17:06] <cjwatson> this set of errors is pretty baffling
[17:06] <cjwatson> any way I can get a shell?
[17:06] <cjwatson> Jul  7 11:12:06 main-menu[2582]: (process:14177): mdadm: /dev/sda5 does not appear to be an md device
[17:06] <cjwatson> Jul  7 11:12:06 main-menu[2582]: (process:14177): mdadm: /dev/sda1 does not appear to be an md device
[17:06] <cjwatson> Jul  7 11:12:06 main-menu[2582]: (process:14177): mount: Mounting /dev/sda1 on /target/ failed: No such device
[17:06] <cjwatson> *appears* to be the relevant stuff but why on earth would mdadm be involved?
[17:13] <cjwatson> I think the mdadm thing is a red herring
[17:13] <cjwatson>                         if mdadm --detail "$fs" | greq -qsi " raid1$" 2>/dev/null; then
[17:13] <cjwatson> (a) probably needs 2>/dev/null on the first command too (b) can't spell "grep"
[17:13] <cjwatson> but not a regression in hardy ...
[17:15] <fader> cjwatson: Looks like this particular one has a failed RAID drive, but I've been seeing install problems on other machines as well
[17:16] <fader> cjwatson: Let me dig in and see what else I can turn up on other machines in that environment
[17:16] <c0nfus3d> Hi All, I am trying to figure how I can change the text in Ubiquity "Prepare Disk Space" window - kindly refer the following image - http://imagebin.org/54855
[17:16] <c0nfus3d> i am basically trying to customize the live CD
[17:17] <cjwatson> c0nfus3d: change /.disk/info on the CD
[17:17] <c0nfus3d> thanks cjwatson - let me try it
[17:17] <cjwatson> the first two fields are used for the partitioning display
[17:40] <eeejay> hola
[17:40] <eeejay> i am trying to preseed ubiquity over dhcp, is this possible?
[18:18] <evand> rgreening: lp:~usb-creator-hackers/usb-creator/cleanup - it's still fairly incomplete, but it's mostly cleaned up.  Feel free to start hacking on it.  I'm trying to do proper test driven development this time around, so I would greatly appreciate it if you write tests before code, but don't fret too much if that becomes a burden.  I've written a fake devicekit-disks to allow us to test without having devicekit installed, and to help us identify
[18:19] <evand> I haven't written any policykit code yet as that appears to be in a state of flux in devicekit (it was ripped out of gnome-disk-utility before the last release and appears to have been refactored in dk trunk since)
[18:19] <rgreening> heh
[18:20] <evand> I'd like to move any common frontend/backend code into the respective base frontend/backends, if any exists
[18:20] <rgreening> I'll grab it and look it over...
[18:20] <evand> (see what ubiquity does for an example of that)
[18:20] <rgreening> sure
[18:21] <evand> I remerged bin/usb-creator as the two separate files were quite similar and we can just do runtime importing to sort out which frontend/backend to use (though that code is a bit ugly at the moment)
[18:21] <rgreening> as long as gtk/gobject/glib and kde/qt never meet or cross over
[18:22] <rgreening> dunno if I like that...
[18:22] <evand> glib is in the devicekit backend at the moment, but only because I haven't ported that work over from trunk yet
[18:22] <evand> oh?  What are your concerns with it?
[18:23] <rgreening> evand: I think keeping two seperate bin would be better and not do runtime checking...
[18:23] <rgreening> imo
[18:24] <evand> I'm concerned about the code duplication there, but I'm sure there's an easy solution to that
[18:24] <rgreening> in the fe bin?
[18:24] <evand> feel free to tackle that bit, or I'll take a look myself tomorrow
[18:24] <evand> in bin/usb-creator-{gtk,kde,win}
[18:25] <rgreening> evand: the traceit, fail, excepthook should be pulled ouyt i
[18:25] <rgreening> stead into a sep lib
[18:25] <evand> I'm keen to get rid of the trace option
[18:25] <rgreening> then no code dup issues and we have diff bins
[18:25] <rgreening> me too
[18:26] <rgreening> imo, no need for trace in user version. if it works, it works...
[18:26] <evand> option parsing would still be duplicated, but I think you're on the right track, we should just have a common module to source that stuff from
[18:26] <rgreening> option parsing is not dups
[18:26] <rgreening> look again at the kde version
[18:26] <rgreening> :)
[18:27] <evand> ah
[18:27] <rgreening> I use the kde equiv of cmdline
[18:27] <rgreening> :)
[18:27] <evand> okay, fair enough
[18:27] <rgreening> but, yeah, pull the common into a seperate file...
[18:28] <rgreening> so, backend,py, install,py, and tools.py (or similar)
[18:28] <evand> Indeed, I'll unwind that mess tomorrow
[18:28] <rgreening> awesome :)
[18:28] <rgreening> you da man
[18:29] <cjwatson> fader: I've reopened the bug, but I think the problem is that your mirror is hosed
[18:29] <cjwatson> Jul  7 11:10:41 anna[6644]: wget:
[18:29] <cjwatson> Jul  7 11:10:41 anna[6644]: server returned error 404: HTTP/1.1 404 Not Found^M
[18:30] <fader> cjwatson: Hmm, let me take a look.  Maybe something has moved on me again.
[18:33] <cjwatson> easiest way to see what URL it's fetching is probably in the server logs unfortunately
[18:34] <cjwatson> but it'll be http://<IP_ADDRESS>/enablement/cdimage.ubuntu.com/ubuntu-server/hardy/daily/current/hardy-server-amd64/dists/something
[18:42] <tormod> is there a way with grub2 to set boot options for certain kernels only? (like there was for grub-legacy)
[18:44] <cjwatson> you can use GRUB_CMDLINE_LINUX or GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub depending on what you want
[18:44] <cjwatson> anything more fine-grained than that in grub legacy never really worked with automatic updates anyway
[18:46] <tormod> I thought I could do per-kernel options with kopt_2_6_31 etc, but in fact I don't know how well it actually worked
[18:47] <cjwatson> oh, maybe you could, I'm not sure about that
[18:47] <cjwatson> there's no such facility in grub2 right now - please do take it up upstream if you can justify it
[18:47] <tormod> ok thanks
[19:34] <fader> cjwatson: The only 404s I'm seeing on the server are for hardy-updates.  I see the same thing for karmic installs (which succeed), so I'm not sure that's the problem with the install.
[19:34] <cr3> eeejay: did you get an answer regarding preseeding ubiquity?
[19:48] <cjwatson> fader: hmm. the problem is definitely that the ext3 module isn't available ...
[19:49] <cjwatson> and it's not even trying to load fs-core-modules, which is the udeb containing it
[19:50] <cjwatson> I wonder if the overrides are busted
[19:53] <cjwatson> hmm! the CD has -23 on it
[19:53] <cjwatson> oh, I see, incorrect seeds
[19:54] <cjwatson> fader: ok, sorry, that was a bit of a saga, largely because there were uncommitted changes in my platform.hardy seeds branch so a simple grep didn't find the problem
[19:54] <cjwatson> fader: the next CD build should work - I'll do a special one shortly
[19:54] <fader> cjwatson: You rock. :)  Thanks!
[19:56] <cjwatson> oh, if I rocked that much I'd have committed these changes when I made them locally, which was apparently *months* ago
[19:56] <cjwatson> like, February
[19:56] <fader> Hehe
[19:57] <cjwatson> server CD build running now ...
[20:10] <cjwatson> right, *now* it's better
[20:10] <cjwatson> fader: wanna re-mirror and try again?
[20:10] <cjwatson> I've verified that 2.6.24-24 udebs are on the new server CD images
[20:33] <fader> cjwatson: Roger, images are downloading.
[20:34] <cjwatson> cool
[20:40] <fader> cjwatson: That seems to have fixed it.  I'm seeing results start to trickle in from the automated tests :D
[20:48] <cjwatson> fader: thank goodness for that
[20:48] <fader> :)
[21:01] <sbeattie> fader: yay!
[21:02] <fader> sbeattie: Indeed!  I'll whip up an HTML report once the results are all in.


[11:29] <mitya57> Unit193, there are new KDE applications 17.04.3, and some Qt modules could have been autosynced from Debian.
[11:34] <juliank> grr, apt autopkgtests are horribly broken on non-amd64
[11:34] <juliank> on ppc64el there is still the regression from the gcc 7 upgrade
[11:36] <juliank> probably because that compiles with -O3 (IIRC)
[19:29] <ktosiek[m]> Hi! What are the tools for working on a debian package? I've had to mock a bit with network-manager today (basically backport a patch to a backported patch :-)), and neither doing a full rebuild with dpkg-buildpackage nor generating patches for said tool to apply was nice
[19:32] <ktosiek[m]> I've started with `apt-get source`, copied the source dir, edited one of them, did a diff, added patch to series, and waited for full dpkg-buildpackage
[23:24] <JanC> ktosiek[m]: did you see http://packaging.ubuntu.com/html/ ?
[23:25] <ktosiek[m]> JanC: not yet, thank you!
[23:25] <JanC> and maybe also https://www.debian.org/doc/manuals/maint-guide/ if it's not in there
[23:26] <ktosiek[m]> I was just doing the things the way I've remembered, it was probably never a good one :-)
[23:26] <JanC> there is Debian-specific stuff in the latter that might not apply to Ubuntu, but OTOH it might have details that the Ubuntu one doesn't have
[23:32] <JanC> it's probably best to use a "clean" build environment like pbuilder (which uses a chroot) or similar


[01:12] <lifeless> wtf
[01:12] <lifeless> bash.preinst is binary ?!
[01:12] <mjg59> lifeless: Uh. How else are you going to guarantee you can execute it?
[01:12] <mjg59> (In the common /bin/sh is bash case)
[01:13] <lifeless> mjg59: yeah, it was just surprise
[01:13] <lifeless> hmm, now wtf does it do.
[02:48] <bddebian> Heya
[03:54] <wasabi_> Heh. A fun massive initramfs-tools update.
[03:54] <wasabi_> This should be entertaining.
[03:54] <jdong> wasabi_: oh come on, it's not like such an update has ever caused an issue before ;-)
[03:55] <bddebian> heh
[03:57] <Lathiat> EMBRACE THE CHANGES!
[04:02] <wasabi_> feisty hasn't had many changes pushed in in the last few days...
[04:02] <wasabi_> wonder if a buildd is stuck. ;)
[04:03] <mjg59> soyuz has been broken
[04:03] <mjg59> Also, holidays
[04:03] <wasabi_> Yeah. There's going to be quite the flood when that's turned back on.
[05:16] <superm1> cjwatson, ping
[09:59] <siretart> elmo: many many thanks! :)
[10:00] <siretart> Riddell: xine-lib 1.1.3 reached feisty and has built on all archs. will upload to debian/experimental tonight.
[10:01] <stub> Launchpad will be going down in 15 minutes time for a code update. Estimated downtime is under 10 minutes.
[10:07] <jdub> jono: ping
[10:08] <jono> jdub: pong!
[10:08] <jdub> jono: caps warning
[10:08] <jdub> jono: REPLY TO LINDSAY'S EMAILS ABOUT LCA
[10:08] <jdub> thanks
[10:08] <jono> jdub: hmmm, thought I had, will check
[10:25] <auxesis> jono, i just sent through another one, just reply to that :-)
[10:25] <jono> auxesis: thanks, sorry, I thought I had replied
[10:25] <jono> will get to it in a sec :)
[10:25] <auxesis> jono, no worries :-)
[10:49] <cjwatson> superm1_: yes?
[10:58] <lifeless> cjwatson: is it fair to assume that all dpkg-diversion and undiversion in maintainer scripts will occur in preinst and postrm ?
[11:01] <cjwatson> lifeless: does not seem to be empirically true
[11:01] <lifeless> cjwatson: hmm
[11:01] <cjwatson> dpkg-divert is sometimes used in the postinst to clean up old diversions
[11:01] <lifeless> ah
[11:01] <lifeless> I dont care about that :)
[11:02] <cjwatson> dash uses dpkg-divert in interesting debconf-dependent ways in its postinst
[11:02] <lifeless> I'm putting the finishing touches on the missing conflict finder
[11:02] <cjwatson> (and its prerm)
[11:02] <lifeless> so diversion use that doesn't impact the ability to unpack the package is really what I should have restricted my statement to
[11:03] <cjwatson> or rather diversion use that does (positively) affect the ability to unpack the package
[11:03] <lifeless> touche
[11:04] <cjwatson> "wisdom teeth are impacted, people are affected by the effects of events" as the .signature of a correspondent at a previous job used to say
[11:04] <cjwatson> a piece of grammar pedantry that was somewhat tarnished by its use of a run-on sentence ...
[11:06] <cjwatson> I wonder if anyone plays with dpkg-divert in prerm deconfigure; that would hurt my brain
[11:06] <cjwatson> lifeless: aside from that probably-irrelevant detail I think your analysis is correct
[11:07] <lifeless> cjwatson: cool. I'm cooking up a hopefully 'good enough' parser to allow heuristic elimination of conflicts
[11:07] <lifeless> http://people.ubuntu.com/~robertc/possible-conflicts.txt is the current output, running from cron
[11:12] <Mithrandir> Adri2000: please do actually list the remaining changes when merging packages, don't just refer to another version.
[11:28] <giskard> ciao
[11:40] <gicmo> hmm where is seb128 and dholbach
[11:41] <mneptok> gicmo: seb is still on leave
[11:42] <gicmo> ahh, and I still have this strange cant-upgrade problem ...
[11:49] <mneptok> what problem is that?
[11:50] <lifeless> gnight all.
[11:50] <gicmo> like dist-upgrade doesnt work since weeks (I was on vacation for two weeks though) .. something with the package resolve
[11:51] <gicmo> feisty that is
[11:53] <mneptok> gicmo: did you properly edit /etc/apt/sources.lst?
[11:55] <gicmo> I didnt  touch that at all for a long time, and apt-get update works
[11:56] <mvo> gicmo: please install the latest apt manually
[11:56] <mvo> gicmo: that will fix the problem
[11:56] <mvo> gicmo: apt-get install apt that is
[11:57] <gicmo> yeah, I know how to do that ;-)
[11:57] <gicmo> I am not *that* stupid ;-)
[11:58] <gicmo> ahh solved it, nice!
[11:59] <mneptok> mvo + mneptok > seb + dholbach
[11:59] <mneptok> >:)
[12:00] <gicmo> hahah
[12:00] <mvo> gicmo: I know that you are not :-D
[12:00] <mvo> just wanted to make clear what manual means (not wget apt; dpkg -i apt)
[12:00] <gicmo> *autsch*
[12:00] <gicmo> ;-)
[12:01] <gicmo> mvo: how were your holidays? ;-)
[12:01] <mneptok> s/m/n/
[12:01] <mvo> gicmo: great! very relaxing. I'm back with a lot of energy :)
[12:01] <mneptok> uhhhh ... no
[12:01] <mvo> gicmo: what about you? did you enjoy christmas?
[12:01] <mneptok> no vacation for you!
[12:02] <mvo> mneptok: I take you with me on vac, ok?
[12:02] <mneptok> ooo!
[12:02] <mneptok> OOOO!
[12:02] <gicmo> pretty good, actually!
[12:03] <mvo> HAHA
[12:04] <mneptok> *muah*
[12:07] <mneptok> Keybuk: maybe you've been a vewwy, vewwy baaaaad puppy, and m-city knows ...
[12:15] <cjwatson> Riddell: I'm attempting to merge ubiquity/experimental-qt4-port now
[12:16] <cjwatson> it's, uh, a slightly complicated megre
[12:16] <cjwatson> merge
[12:19] <StevenK> mvo: Do you have a few seconds to look at apt?
[12:20] <mvo> StevenK: what bit/bug in particular?
[12:20] <ogra_> could someone let edsadmin out of the NEW queue ?
[12:20] <Riddell> cjwatson: has much changed since I started it?  there shouldn't be any conflicts
[12:21] <ogra_> Keybuk, cjwatson ^^^ ?
[12:21] <cjwatson> Riddell: yes, enormous change :-)
[12:21] <cjwatson> Riddell: it's ok, I've resolved it all
[12:21] <cjwatson> ogra_: -> Mithrandir
[12:21] <ogra_> ah, k
[12:21] <Mithrandir> ogra_: I'll take a look at it.
[12:21] <ogra_> thanks
[12:21] <cjwatson> Riddell: I merged the new-partitioner branch, and over the last day or two I've been doing bits of UI rearrangement in preparation for other things
[12:22] <Riddell> cjwatson: ah, that will affect it right enough
[12:22] <StevenK> mvo: I'm looking at the libept build failure.
[12:22] <Mithrandir> ogra: or, I could if stuff wasn't broken; I can't access the queue right now.  I'll poke the relevant people.
[12:23] <cjwatson> Riddell: I'm reverting the prints you added to gtkui.py in your branch, and I think I'll go through and clean up spurious str("...") as well
[12:23] <ogra> Mithrandir, thanks, there is no hurry as long as someone cares for it ...
[12:23] <Mithrandir> ogra: it's in a queue, I'll get to it eventually. :-P  Source NEW just takes quite a bit of time.
[12:24] <ogra> yep
[12:24] <ogra> understood :)
[12:25] <ogra> whom do i poke for promotion/demotion now ? Mithrandir is that you as well now ?
[12:25] <cjwatson> Mithrandir can do it, or I'm happy to if it's properly anastacia'd in advance
[12:25] <ogra> netkit-inetd -> openbsd-inetd shows up on anastacia now
[12:25] <cjwatson> I'll have a look
[12:26] <Keybuk> ogra: the archive admin team hasn't changed, though for obvious reasons, cjwatson and I have a little less time for it than Mithrandir
[12:26] <ogra> thanks
[12:26] <Keybuk> so if you have urgent things, it's usually easier to ping him
[12:26] <ogra> Keybuk, i never asked Mithrandir for pro/demotions yet :)
[12:27] <cjwatson> netkit-inetd/openbsd-inetd done
[12:27] <Mithrandir> ogra: pinging me is generally fine
[12:27] <ogra> oki, noted :)
[12:27] <ogra> cjwatson, thanks, that will make my CDs more happy again :)
[12:28] <Riddell> talking about promotions, will gwenview-i18n need a main inclusion report?  it's just the .po files from gwenview which is already in main
[12:28] <ogra> do they build from the same source ?
[12:28] <ogra> MIRs are for sources usually ...
[12:29] <mvo> StevenK: this is still http://librarian.launchpad.net/5346111/buildlog_ubuntu-feisty-i386.libept_0.4.7_FAILEDTOBUILD.txt.gz?
[12:29] <StevenK> Yup.
[12:30] <Riddell> ogra: not any more, it's recently been separated
[12:30] <ogra> ah
[12:30] <StevenK> mvo: If I edit apt-pkg/packagemanager.h, at around line 107 and comment out the Cache.writeStateFile(NULL); call, the build is sucessful.
[12:30] <Mithrandir> Riddell: if it used to be the same source, promoting without a MIR is fine.
[12:31] <Mithrandir> ogra: the copyright file for edsadmin is talking about "countdown timer" which seems to be something entirely else?
[12:31] <ogra> hrm
[12:31] <ogra> i missed that
[12:32] <ogra> crap ...
[12:32] <Mithrandir> ok, I'll reject it, please fix and reupload.
[12:32] <mvo> StevenK: I would rather like to have that feature enabled, writeStateFile() writes out e.g. auto-install information. is pkgDepCache a class that does not come from libapt? I suspect something fishy going on, let me check
[12:32] <ogra> Mithrandir, will do ...
[12:33] <Mithrandir> ogra: and it seems to be forcing the use of python 2.3?
[12:33] <Mithrandir> without depending on it.
[12:33] <StevenK> mvo: Sure, I was just seeing if that was the cause.
[12:33] <StevenK> mvo: Actually, I think I know why.
[12:34] <StevenK> bool pkgDepCache::writeStateFile(OpProgress *prog, bool InstalledOnly)
[12:34] <StevenK> And yet, it's being called with (NULL)...
[12:34] <ogra> Mithrandir, urgh ... i see it ... i'll patch it and mail upstream ...
[12:35] <Mithrandir> ogra: ok, I'll just reject it for now and you can retry later.
[12:35] <ogra> yep
[12:36] <mvo> StevenK: ok, so the problem is that pkgDepCache is copied from libapt and heavily modified in libept.  the only course of action is probably to  copy the writeStateFile() into the libept implementation (yeah for duplication of code)
[12:36] <ogra> funnily the automake setup he uses checks for python2.4 ... i didnt even bother to look at the shebang lines ....
[12:37] <StevenK> Ew.
[12:38] <StevenK> mvo: I could make it a no-op in libept, though, right?
[12:39] <mvo> StevenK: that would lose the auto-install information. but given that it is a reimplementation anyway auto-inst is probably not supported (I haven't checked that)
[12:39] <StevenK> mvo: But only in libept?
[12:40] <mvo> StevenK: yes. what is using this version of libept?
[12:40] <StevenK> packagesearch of the top of my head
[12:40] <mvo> ok, that is harmless as it does not installs anything
[12:41] <StevenK> mvo: Just checking for anything else in a sid chroot.
[12:41] <mvo> anything that uses it for installing packages would loose the auto-install information. this is not fatal, just a regression from standard apt using tools
[12:42] <gicmo> ok, of course now the nvidia drivers broke and I dont have X
[12:42] <gicmo> *sigh*
[12:47] <StevenK> mvo: debtags, debtags-edit and packagesearch
[12:47] <StevenK> mvo: None of which install stuff.
[12:48] <mvo> StevenK: ok, in this case a no-op should be fine
[12:48] <mvo> StevenK: thanks for working on this!
[12:48] <StevenK> mvo: No problem!
[12:54] <cjwatson> Riddell: merged
[12:55] <Riddell> cjwatson: all very exciting.  does it need changes to keep up with the new-partitioner branch and your other UI changes?
[12:56] <StevenK> Hum. If debtags is in main, then libept needs to be promoted.
[12:56] <StevenK> (It's now a build-dep of debtags and debtags-edit)
[12:56] <cjwatson> Riddell: new-partitioner isn't ready for porting to other UIs yet; still too much in flux
[12:56] <cjwatson> Riddell: I've dealt with the other UI changes
[12:57] <cjwatson> totally untested, mind :)
[12:58] <cjwatson> Riddell: you can probably start looking at new-partitioner now, but I wouldn't advise putting in serious resources yet
[12:59] <StevenK> cjwatson: I'd be curious about a screenshot or two for the new partitioner, but only if you have some handy.
[12:59] <cjwatson> StevenK: I don't, unfortunately; I posted directions for trying it out on ubuntu-devel@ just before Christmas
[01:00] <cjwatson> StevenK: it's lacking the disk bar still which would really be the screenshot-worthy bit; it's just a crude list of partitions at the moment
[01:00] <Hobbsee> hooray, feisty still boots!
[01:02] <StevenK> cjwatson: The disk bar, a'la gparted?
[01:03] <cjwatson> er, sort of
[01:03] <cjwatson> StevenK: http://wiki.ubuntu.com/Ubiquity/AdvancedPartitionerRewrite
[01:03] <cjwatson> that's probably more useful
[01:06] <cjwatson> Riddell: Depends: ${misc:Depends}, ${python:Depends}, ubiquity, python-kde3, qtparted
[01:07] <cjwatson> Riddell: is that Depends line still right for ubiquity-frontend-kde? looks like it could do with an update
[01:08] <Riddell> cjwatson: it'll need python-qt4 now not -kde3
[01:10] <cjwatson> Riddell: fixed
[01:10] <cjwatson> thanks
[01:11] <cjwatson> Riddell: sorry, one more thing, is there a way to produce a hyperlink widget in Qt4 in some way other than a QLabel whose text is the URL? I don't actually want to display the URL - this is for ubiquity-release-notes
[01:11] <StevenK> Just a reality check here, do I need a MIR to get libept promoted given debtags Build-Depends on it? And if not, should I file a bug and subscribe ubuntu-archive asking for it?
[01:12] <Mithrandir> StevenK: yes, it needs a MIR if it's not just split out from something already in main.
[01:12] <cjwatson> StevenK: yes, you do, unless it's code that was moved from somewhere else; no, you shouldn't file a bug
[01:12] <cjwatson> we have http://people.ubuntu.com/~cjwatson/anastacia.txt to track promotions and demotions
[01:13] <gicmo> ok, got the X back but lost SMP support for now ;-)
[01:13] <gicmo> *sigh*
[01:13] <gicmo> binary drivers shit
[01:14] <Riddell> cjwatson: QLabel accepts HTML, so you can do text
[01:15] <Riddell> although it'll need the same stuff done to it as the label in the crash dialogue to make it do anything
[01:15] <cjwatson> aha, ok
[01:15] <cjwatson> yeah, that's fine
[01:15] <cjwatson> I missed the  already in crashdialog.ui - whoops
[01:18] <StevenK> Right. libept looks to be a rename of libapt-front, which is in main.
[01:18] <StevenK> But if it gets promoted, I can't fix it, since I can't upload to main. :-)
[01:19] <Riddell> StevenK: I'm happy to upload
[01:19] <StevenK> Riddell: Let's see if my fix or the promotion happen first. :-)
[01:19] <Riddell> StevenK: seems like we still need libapt-front though, adept hasn't been ported to the new (libept) version
[01:19] <StevenK> libapt-front still exists.
[01:20] <Riddell> StevenK: have you asked for a promotion?
[01:21] <StevenK> Probably not, I'm not sure if dicussing here counts. :-)
[01:21] <StevenK> Based on what Mithrandir and cjwatson said earlier, it doesn't need an MIR.
[01:21] <Riddell> no, it won't, being just a rename
[01:26] <Riddell> Mithrandir: able to do some propotions?
[01:27] <Mithrandir> Riddell: do they show up in the anastacia output?
[01:28] <Riddell> not libept, StevenK does debtags not depend on that yet?
[01:28] <Riddell> Mithrandir: but gwenview-i18n source and binary does
[01:28] <Riddell> Mithrandir: and kplato binary from koffice needs it too
[01:29] <StevenK> Riddell: debtags does Build-Depend on it, and is in depwait.
[01:29] <Mithrandir> Riddell: just let me finish this source review I'm doing and I'll take a look at those.
[01:30] <Riddell> StevenK: yes, so I'm not sure why it doesn't show up in anastacia
[01:32] <Mithrandir> Riddell: and gwenview-i18n was just split from gwenview?
[01:32] <Riddell> Mithrandir: yes
[01:33] <Mithrandir> Riddell: ok, promoted.
[01:34] <Riddell> thanks Mithrandir
[01:34] <Mithrandir> Riddell: you want kplato promoted too?
[01:34] <Riddell> Mithrandir: yes please
[01:34] <Mithrandir> done
[01:34] <Riddell> yay
[01:35] <Riddell> Mithrandir: any idea why libept doesn't show up in anastacia since debtags is dep-wait on it?
[01:35] <Mithrandir> Riddell: not yet, I'll investigate.
[01:35] <cjwatson> I'd done kplato not that long ago, but doing it twice won't hurt ;)
[01:36] <StevenK> Hah
[01:36] <Mithrandir> sneaky Colin. ;-)
[01:36] <imbrandon_> Mithrandir , thanks for the note, i ment to ask you to reject those anyhow as the mesa isnt needed ( among other things ) with the new version, I just hadent got arround to uploading the packages yet
[01:37] <Mithrandir> imbrandon_: ok, good to hear.
[01:37] <imbrandon_> heya Riddell
[01:37] <Mithrandir> imbrandon_: the licence problems in -plugins seem a bit more serious, though.
[01:37] <imbrandon_> ahh yea , that is one thats still ummmm questionable at best
[01:37] <imbrandon_> i need to grab them again about it
[01:37] <Mithrandir> Riddell: libept ftbfs, that'd explain it
[01:38] <StevenK> Which I almost have a patch for.
[01:38] <Riddell> ah, so StevenK needs to upload his fix first
[01:38] <Mithrandir> yeah, there's no libept-dev yet, so no package to promote.
[01:39] <Riddell> Mithrandir: one other anastacia question, kdeaddons won't install because knewsticker-scripts isn't in main, but it's not in anastacia either
[01:39] <StevenK>  -lapt-pkg -lwibble -ltagcoll2 -lz -lwibble -lz
[01:40] <StevenK> Yay for specifying libraries twice!
[01:40] <StevenK> Just in case ld wasn't listening.
[01:40] <ogra> Riddell, its in main here
[01:40] <Riddell> oh, it has another depends that isn't
[01:40] <Riddell> ok, ignore me Mithrandir
[01:41] <Mithrandir> sure. ;-)
[01:42] <ogra> hmm, pulse doesnt like the ugly esd patch of the flashplugin package :(
[01:43] <Mithrandir> it has good taste?
[01:43] <ogra> well
[01:43] <ogra> indeed
[01:44] <ogra> but that brings me in a dilemma ... do i break flash or do i break pulse now to fix the issue ?
[01:45] <Riddell> flash uses esd?
[01:45] <ogra> no
[01:45] <Riddell> phew
[01:45] <ogra> libflash only plays sound if /tmp/.esd/socket exists
[01:45] <Hobbsee> ogra: you break flash, then blame it on someone else.
[01:45] <ogra> which we touch from an initscript, since our esd is patched to use rather /tmp/.esd-$UID/socket
[01:46] <ogra> apart from that socket file isnt used at all
[01:46] <ogra> but pulse doesnt start the esd compat mode if the file exists
[01:46] <ogra> Hobbsee, cool idea, i could just blame adobe and be done with it :P
[01:46] <StevenK> libept uploaded.
[01:46] <Hobbsee> ogra: *grin*
[01:52] <StevenK> Hrm. /distros doesn't appear the in Launchpad URL anymore.
[01:57] <highvoltage> do most ubuntu developers use aptitude, or apt-get when installing from a terminal?
[01:58] <StevenK> Can someone give-back libapache2-mod-fcgid on all arches, it FTBFS, but should build fine now.
[01:58] <Hobbsee> highvoltage: i use apt-get - clearer output
[01:59] <Hobbsee> Mithrandir: @ StevenK's request
[02:00] <thom> apt-get - i've been burnt by aptitude's problem resolution once too many times
[02:00] <StevenK> highvoltage: Either.
[02:00] <mneptok> highvoltage: make
[02:00] <mneptok> ;)
[02:01] <Mithrandir> Hobbsee: thanks dudette. :-)
[02:01] <highvoltage> mneptok: heh!
[02:01] <Mithrandir> StevenK: given-back
[02:01] <Hobbsee> Mithrandir: :)
[02:01] <StevenK> Mithrandir: Thanks!
[02:02] <StevenK> And it's already building on three arches. Neat.
[02:02] <mneptok> feel the love.
[02:02] <Mithrandir> StevenK: probably time to give back all our failed builds, then. :-P
[02:04] <StevenK> Heh
[02:05] <Hobbsee> mneptok: indeed.
[02:09] <mneptok> morgen boggle :)
[02:11] <boggle> moin mneptok
[02:12] <Hobbsee> hehe
[02:12] <Hobbsee> Mithrandir: when's the next archive admin day, and will we see a mass of syncs, presumably?
[02:13] <Mithrandir> Hobbsee: I've done more or less nothing but archive stuff yesterday and today; there's a fairly big backlog of stuff from christmas.
[02:14] <Mithrandir> Hobbsee: some of the source NEW I've been doing has been around for a month, so it's about time.  I'll see if I manage to get to syncs today as well, though I doubt it.
[02:14] <Hobbsee> Mithrandir: OK, that's fine.  had expected that :)
[02:14] <Hobbsee> Mithrandir: cool :)
[02:21] <StevenK> The syncs ought to sort out MoM neatly, too.
[02:25] <mneptok> StevenK: you keep your hot VCS porn away from my mom, ok?
[02:25] <cjwatson> Mithrandir: bug 77438 makes sense to me. Any objections to me applying that?
[02:26] <Mithrandir> cjwatson: makes sense; please apply.
[02:28] <cjwatson> Mithrandir: donoe
[02:28] <cjwatson> done
[02:29] <Mithrandir> danke
[02:43] <yellowbee> www.myspace.com/doggerdan <---- New myspace XSS exploit PoC (proff of concept)
[02:43] <Keybuk> that's a new one on me
[02:44] <Keybuk> gfxboot on edgy i386 release got corrupted by grub messages
[02:44] <yellowbee> :O
[02:44] <Mithrandir> Keybuk: that'd be.. special, given that gfxboot is on CDs and those don't use grub.
[02:45] <Mithrandir> yellowbee: that's hardly relevant to Ubuntu development, isn't it?
[02:45] <Keybuk> well, the "Loading" and dots type messages
[02:45] <Keybuk> I thought it was very odd
[02:45] <Keybuk> they appeared in greenish text at the top
[02:45] <Amaranth> Mithrandir: the website itself probably totally fscks up a system when you look at it with IE
[02:46] <ogra> Keybuk, isnt that the kernel itself ?
[02:46] <ogra> (instead of grub)
[02:47] <Amaranth> that reminds me, is it possible to make the kernel shut up about those pci errors at bootup?
[02:48] <Keybuk> ogra: why would the kernel be "Loading casper/vmlinuz" ?
[02:48] <Mithrandir> then it's not grub, it's isolinux
[02:51] <ogra> Keybuk, well i thought you meant the uncompressing of the kernel image ...
[02:51] <ogra> i thought that part comes from the kernel directly
[02:52] <zul> ogra: nope
[02:53] <cjwatson> Keybuk: has been happening for ages
[02:53] <cjwatson> I've never worked out the x86 assembly necessary to avoid that
[02:53] <cjwatson> in fact, as far as I know that's been happening since we introduced gfxboot
[02:54] <Mithrandir> it's only on some gfx cards, iirc
[02:57] <Keybuk> weird, had a usplash timeout too
[03:15] <ogra> pitti, did you see anything significant in pulse that prevents it from entering main (apart from the fact that it breaks with flash)
[03:16] <ogra> else i'll write the MIR now
[03:16] <pitti> ogra: no, it works fine, apart from some issues; let's talk later (phone call with Scott)
[03:16] <ogra> yep
[03:16] <ogra> i'll prepare the MIR
[03:23] <ogra> argh, the syntax of /etc/exports has changed ? damned ...
[03:25] <ogra> BenC, how is the status of the bcm43xx driver ? does it make sense to test the latest 2.6.20 for me ? seems it doesnt work on my ppc
[03:25] <ogra> (so i'm a bit scared to test it on my main work machine)
[03:39] <lritter> hi there
[03:39] <lritter> i'm trying to build a package, and i added libjack0.100.0-dev as dependency, but pbuilder can't find it... what's my mistake?
[03:40] <Hobbsee> lritter: please dont cross-post.  see -motu
[03:43] <Keybuk> cjwatson: I have a weird thing; the debconf database doesn't match my xorg.conf
[03:44] <ogra> btw, werent we supposed to see a lot of X uploads recently ?
[03:45] <Keybuk> (or the running X)
[03:54] <cjwatson> Keybuk: in what way?
[03:58] <Keybuk> cjwatson: xorg.conf says i810, 1280x800 .. but debconf says and X appears to be running as vesa at 1024x768
[03:59] <cjwatson> um, buggeredifIknow, maybe some desktop tool edited xorg.conf directly?
[03:59] <cjwatson> dunno why X would be in sync with debconf and not xorg.conf, since xorg.conf is canonical, unless you haven't restarted X recently
[03:59] <bddebian> Morning
[04:01] <sroecker> hi
[04:01] <sroecker> did feisty change something with the initramfs?
[04:01] <_ion> Yes.
[04:02] <sroecker> my newer kernels crash with: libgcc.so not found, pthread_cancel not working
[04:02] <sroecker> or something like that
[04:02] <Keybuk> cjwatson: fresh install
[04:04] <cjwatson> Keybuk: iz xserver-xorg.postinst's fault probably
[04:04] <cjwatson> Keybuk: somebody would have to trace through that and make sure to keep a gingerbread trail
[04:26] <Keybuk> cjwatson: ah, apparently I need to install 915resolution
[04:28] <geser> or xserver-xorg-video-i810-modesetting
[04:28] <cjwatson> Keybuk: fun
[04:28] <tepsipakki> are sounder subscriptions moderated?
[04:28] <Hobbsee> Keybuk: welcome to widescreen laptops - is that the first time you've needed that?
[04:29] <Keybuk> Hobbsee: yes, my previous laptop had an ATI Radeon and no widescreen display
[04:29] <Hobbsee> Keybuk: ahh
[04:36] <pitti> ogra: I'll try the new powerpc kernel on my laptop now (with bcm43xx)
[04:39] <sladen> Keybuk: or use the mode-setting branch of video-driver-intel
[04:39] <sladen> Keybuk: which is in universe IIRC
[04:41] <geser> yes it is in universe, package xserver-xorg-video-i810-modesetting in feisty
[04:44] <jdub> ha ha fisty in 80MB RAM
[04:44] <zul> eh?
[04:44] <Nafallo> fisty? :-)
[04:44] <Nafallo> sounds kinky ;-)
[04:45] <sladen> jdub: oh, just the kernel, right :)
[04:47] <_ion> jdub: I don't see why that would be a problem, unless you happen to be running stuff that requires more memory.
[04:49] <pitti> mvo_: ping
[04:56] <Keybuk> hmm, language-support-en problem?
[04:56] <cjwatson> Keybuk: openoffice.org-l10n build failure, last I traced it
[04:56] <Keybuk> ah, yes
[04:57] <Keybuk> and no LRM?
[04:57] <Mithrandir> lrm is in NEW
[04:57] <BenC> ogra: It should be working now
[05:22] <doko> cjwatson: openoffice.org-l10n sucessfully built
[05:27] <Keybuk> hmm, why does the hostname have a bogus IP in /etc/hosts?
[05:31] <cjwatson> doko: yay
[05:31] <cjwatson> Keybuk: what IP?
[05:32] <Keybuk> cjwatson: <IP_ADDRESS>
[05:33] <cjwatson> that's not bogus; anything in 127.* identifies the local host
[05:33] <Robot101> that's not bogus, it's also localhost. I always assumed it was for round-trippable forward/reverse DNS lookups of both localhost and hostname.
[05:33] <Robot101> hm :)
[05:33] <cjwatson> Robot101: I think it's something along those lines, although I forget the details of the long drawn-out thread that led to that conclusion
[05:34] <Keybuk> cjwatson: only on  Linux, no?
[05:35] <cjwatson> Keybuk: (a) I can't say I care (b) cite?
[05:36] <Keybuk> from reading the bug and thread, I can see the reasoning for it
[05:37] <cjwatson> RFC1060 says that anything in network 127 is "Internal host loopback address"
[05:37] <_ion> At least one thing comes to mind: let's say a box in DMZ has a local IPv4 address which is different from its public address. boxname.mydomain points to the public address. When a program at the box tries to connect to boxname.mydomain, the packets go out to the router, which may or may not route them back to the box, and if it does, the box may block them as spoofed.
[05:38] <Keybuk> I thought the fact that the lo device replied to all IPs in its configured range was a Linux-specific thing
[05:38] <Keybuk> and more to do with its implementation in the kernel
[05:39] <Keybuk> I'm sure I've seen an OS that needed multiple los configured if you wanted multiple IPs in that range
[05:39] <_ion> PING <IP_ADDRESS> (<IP_ADDRESS>): 56 data bytes
[05:39] <_ion> ping: sendto: Network is unreachable
[05:39] <_ion> says an OpenBSD box
[05:39] <Keybuk> (and arguably, lo is configured wrong ... it should be <IP_ADDRESS>/<IP_ADDRESS> not <IP_ADDRESS> <g>)
[05:39] <iwj> We need dpkg triggers so badly.  This slightly stale feisty install is taking an age to update.
[05:40] <Robot101> lo        Link encap:Local Loopback   inet addr:<IP_ADDRESS>  Mask:<IP_ADDRESS>
[05:40] <Robot101> it has the mask right :)
[05:40] <Keybuk> Robot101: the mask is right, but the addr isn't
[05:40] <Keybuk> technically
[05:40] <Keybuk> but I'm digressing into meaningless pedantry
[05:40] <_ion> iwj: Perhaps someone should just say "this is how it should work, screw the other opinions" and implement it. ;-)
[05:40] <pitti> ogra: btw, 2.6.20-3 still crashes with bcm43xx
[05:41] <iwj> _ion: I need to actually write down the design first though.
[05:41] <ogra> pitti, yeah i noticed after the upgrade
[05:41] <ogra> (thats why i was offline the last hour :P )
[05:41] <Keybuk> Robot101: as I understand the implementation, Local devices merely route all traffic into a special "device" that happens to reply to any traffic routed to it
[05:41] <Keybuk> which means that they actually reply to any traffic within their configured netmask
[05:42] <Keybuk> based on that, there's no real IP for that device, so it should only have the network configured -- which is <IP_ADDRESS> not <IP_ADDRESS>
[05:42] <Keybuk> but that'd shock people
[05:42] <Keybuk> :p
[05:42] <_ion> A virtual (in some sense) package for each trigger script that goes unconfigured if the script fails seems like a good way, but someone probably points out why it won't work.
[05:42] <iwj> Keybuk: Yes, but packets destined for <IP_ADDRESS> ought to be rejected at the next layer up.
[05:42] <ogra> bah, FF doesnt recover the contents of half filled forms after a crash ...
[05:42] <Keybuk> iwj: on linux, there isn't a next layer
[05:42] <iwj> Keybuk: Yes, there is, it's routing.
[05:43] <_ion> orga: IIRC it should do that.
[05:43] <Robot101> Keybuk: that sounds bogus, because <IP_ADDRESS> is still the network address isn't it?
[05:43] <Keybuk> iwj: ?
[05:43] <ogra> _ion, well .. should ...
[05:43] <Robot101> $ ping <IP_ADDRESS>
[05:43] <Robot101> Do you want to ping broadcast? Then -b
[05:43] <Keybuk> Robot101: you're missing the point
[05:43] <iwj> Keybuk: Or are you saying that if I send to box-a's ethernet MAC address a packet with a destination IP address on the same segment but not box-a's, then box-a's TCP stack will answer it ?
[05:43] <Keybuk> the implementation of lo in Linux means that it doesn't need an IP address
[05:44] <Keybuk> iwj: no, I'm only talking about link encap: Local -- not Ether
[05:44] <Keybuk> a device with Link encap: Local will treat any package routed to it as something to reply to
[05:44] <iwj> You do seem to be right.
[05:44] <iwj> This is, however, clearly bogus.
[05:44] <Keybuk> indeed
[05:45] <Keybuk> and our default install relies on this bogus behaviour <g>
[05:45] <iwj> Checking the IP address for local/remote is a routing function and should be done by the IP layer and not by some crazy code in the network device!
[05:45] <cjwatson> http://bugs.debian.org/316099 is the relevant reference
[05:45] <iwj> I'm going to go and do something more useful now :-).
[05:46] <cjwatson> (executive summary: it was to stop 'hostname --fqdn' from returning 'localhost.localdomain' if the system doesn't have a permanent IP address known to the installer)
[05:47] <cjwatson> IIRC localhost.localdomain is bogus too but that's a different argument ...
[05:48] <cjwatson> ah, and localhost.localdomain is gone now, good; but the canonical hostname would just have been localhost instead without the <IP_ADDRESS> change
[05:48] <Keybuk> "gone now" ?
[05:48] <cjwatson> http://lists.debian.org/debian-devel/2005/10/msg00559.html
[05:48] <_ion> ogra: Workedforme
[05:48] <_ion> ogra: That's not to say that it couldn't be buggy, of course.
[05:48] <ogra> _ion, hmm, might be a moin problem
[05:48] <cjwatson> and netcfg 1.17 changelog
[05:49] <Keybuk> so it is
[05:49] <Keybuk> \o/
[05:49] <iwj> Why not set uname to something not in /etc/hosts and let hostname -f just print the nodename ?
[05:49] <Keybuk> the argument appears to be that some apps may look up the hostname with DNS to find its IP
[05:50] <Keybuk> and thus if its not in /etc/hosts, it won't work
[05:51] <iwj> To find what IP address ?
[05:51] <iwj> I mean, what are they going to do next ?  Something bogus, obviously.
[05:51] <cjwatson> listen on it is my only guess
[05:52] <cjwatson> the whole thread made my head hurt and I confess I zoned out about halfway through
[05:53] <cjwatson> maybe it's to make sure stuff like tcp-wrappers' reverse DNS check doesn't get upset?
[05:54] <iwj> I'm playing Chinese Whispers with ignoramuses at the far end, I think.  Time to give up.
[06:13] <Keybuk> hmm
[06:13] <Keybuk> I can't seem to install xserver-xorg-i810-modesetting
[06:15] <thom> xserver-xorg-video-i810-modesetting
[06:15] <Keybuk> thom: conflicts with the i810 driver
[06:15] <Keybuk> which is a dependency of ubuntu-desktop
[06:15] <thom> well, yes
[06:21] <geser> Keybuk: where exactly does ubuntu-desktop depend on xserver-xorg-video-i810?
[06:22] <Keybuk> geser: depends on xorg depends on xserver-xorg depends on xserver-xorg-video-all depends on xserver-xorg-video-i810
[06:23] <geser> xserver-xorg depends alternatively on xserver-xorg-video which is provided by xserver-xorg-video-i810-modesetting
[06:25] <geser> so this dependency should be satisfied by xserver-xorg-video-i810-modesetting (once xserver-xorg-video-i810 and xserver-xorg-video-all are removed)
[06:26] <Keybuk> weird, why didn't aptitude let me do that then?
[06:26] <Keybuk> ah
[06:26] <Keybuk> I have a later version than what's in feisty
[06:27] <Keybuk> there's a 6.2 from edgy updates installed
[06:39] <mbiebl> Is there an easy way to reopen a bug in launchpad?
[06:40] <_ion> I haven't reopened one, but i'd expect it to happen the same way a bug's status is changed to any other value.
[06:43] <mbiebl> I'm the original bug reporter, but I can't change the status (which is "Fix Released")
[06:43] <mbiebl> At least I don't know how.
[06:44] <cjwatson> only people in ubuntu-qa can do that; otherwise, post a comment explaining the situation and asking the person who made the change to revert it
[06:44] <mbiebl> cjwatson: that would be you ;-)
[06:44] <mbiebl> https://launchpad.net/ubuntu/+source/console-setup/+bug/60483
[06:45] <cjwatson> mbiebl: there's already a different bug about that, so that one can happily stay closed, I think
[06:45] <Keybuk> cjwatson: hmm, all of a sudden I'm getting very strange messages from ssh
[06:45] <Keybuk> buffer_get_ret: trying to get more bytes 257 than in buffer 39
[06:45] <mbiebl> cjwatson: ok
[06:46] <cjwatson> mbiebl: bug 73955
[06:46] <cjwatson> Seveas: 17:46 [Freenode]  -Ubugtu(n=bugbot@ubuntu/bot/ubugtu)- Error: Error getting Malone bug #73955: Bug does not exist
[06:46] <cjwatson> it lies
[06:46] <cjwatson> Keybuk: I have no idea - try with -vvv and/or search upstream bug?
[06:46] <cjwatson> s
[06:51] <Keybuk> cjwatson: ah, corrupted .pub file
[06:53] <cjwatson> Keybuk: fun error. I think there may be a Debian bug about that ...
[07:00] <cjwatson> Keybuk: I thought I'd seen this before, but I can't find a bug, so feel free to file one
[07:01] <Keybuk> the only real bug to my mind is that it doesn't tell you what file caused the error
[07:01] <Keybuk> "error parsing .ssh/id_dsa.pub" needed
[07:04] <cjwatson> right, it's using the generic buffer-handling code which basically fatal()s out of library code, iirc
[07:04] <Keybuk> "Why abort() is not an exception handler"
[07:09] <Seveas> cjwatson, will check asap
[07:38] <ogra> lifeless, around ?
[07:53] <Zomb> hi. Who can change the cdrkit packages? mvo accidentaly a "gg" into the md5sum list in wodim.preinst file. Just search for gg.
[07:53] <somerville32> Keybuk, ping
[07:53] <Zomb> s,a ,added ,
[07:54] <Keybuk> somerville32: yo
[07:55] <somerville32> keybuk: Could I get you to sponsor my upload to main? I see you're a member of ubuntu-main-sponsors
[07:56] <somerville32> keybuk: It is an SRU approved by cjwatson
[07:58] <somerville32> please :)
[08:00] <Keybuk> somerville32: ask me tomorrow
[08:00] <somerville32> keybuk: Alrighty. If I can't find anyone by tomorrow, I'll ping you :]
[08:14] <cjwatson> Zomb: I'll fix it now; thanks for the report
[08:15] <mdke_> cjwatson: hiya. Happy new year. What is the general time for feedback on SRU bug reports?
[08:15] <Seveas> cjwatson, ubugtu is fied again. Launchpad devs broke him
[08:18] <cjwatson> mdke_: "depends"
[08:18] <mdke_> cjwatson: :)
[08:18] <cjwatson> mdke_: holidays have obviously left me well behind
[08:19] <cjwatson> I try to get to them in days; earlier if explicitly asked
[08:19] <cjwatson> Seveas: thanks!
[08:19] <mdke_> cjwatson: it's not that urgent, so I won't explicitly ask you. Just curious
[08:19] <cjwatson> Zomb: fixed
[08:45] <LaserJock> do edgy-proposed uploads show up in the edgy queue on LP?
[08:48] <cjwatson> LaserJock: yes, from the point of view of the web interface; c.f. https://launchpad.net/ubuntu/edgy/+queue which shows a backports upload
[08:48] <LaserJock> cjwatson: do uploads have to be approved by ubuntu-archive first?
[08:48] <cjwatson> LaserJock: "first" => before what?
[08:49] <LaserJock> cjwatson: I'm pretty sure I uploaded rpy to edgy-proposed last month
[08:49] <LaserJock> but I couldn't find it on the queue
[08:49] <cjwatson> LaserJock: it's the unapproved queue, not the new queue
[08:49] <LaserJock> cjwatson: can us mortals see that. I don't think we can if I remember right
[08:49] <cjwatson> LaserJock: https://launchpad.net/ubuntu/edgy/+queue?queue_state=1&queue_text= (you may or may not have access to that)
[08:49] <cjwatson> LaserJock: it's there
[08:50] <LaserJock> cjwatson: forbidden for me, and thanks
[08:50] <LaserJock> I just wanted to make sure I wasn't loosing my mind
[08:50] <cjwatson> LaserJock: it appears to be in ubuntu-archive's queue as normal; Mithrandir should process it at some point if the SRU is well-formed
[08:51] <LaserJock> excellent, thanks
[08:51] <ttoine> cjwatson: ??
[08:56] <ttoine> cjwatson: ping ?
[09:00] <cjwatson> ttoine: yes?
[09:00] <ttoine> cjwatson: ah, cool
[09:01] <ttoine> cjwatson: i am one of the dev of ubuntu studio
[09:01] <ttoine> and to enable real time for applications, we need of course a real time kernel with pre-empt. BenC is working on that
[09:01] <ttoine> but looking for how to set up and tweak....
[09:02] <ttoine> we need to have a specific version of PAM
[09:03] <ttoine> and as you are one of the current maintener/uploader i would like to know if the version 0.8 of PAM is scheduled for ubuntu feisty or not ?
[09:03] <cjwatson> ttoine: you mean beyond the nice and rtprio extensions that already went into pam_limits?
[09:03] <ttoine> cjwatson: https://wiki.ubuntu.com/MultimediaProductionKernel#preview
[09:03] <ttoine> cjwatson: yes, that's it
[09:04] <cjwatson> ttoine: those are in our pam all the way back to dapper
[09:04] <tsmithe> yay!
[09:04] <cjwatson> ttoine: as for new upstream versions in general, see my comment in https://launchpad.net/ubuntu/+source/pam/+bug/43169
[09:04] <Ubugtu> Malone bug 43169 in pam "RFE: Update pam to 0.99 or greater" [Unknown,Unconfirmed]
[09:04] <ttoine> cjwatson: so wa can tweak even if it is not the 0.80 version ?
[09:05] <cjwatson> ttoine: yes, that change was backported
[09:05] <ttoine> so it is in edgy...
[09:05] <cjwatson> yes
[09:06] <ttoine> ok
[09:06] <ttoine> thanks
[09:06] <ttoine> and of course will be in feisty
[09:07] <cubicool> heno: ping
[09:07] <ttoine> so, as i just know at the moment wich file should be edited for the 0.8 version, can you tell me what it the file to edit with the current version ?
[09:07] <heno> cubicool: Hi
[09:07] <cubicool> heno: Mind if I send you a /msg? :)
[09:07] <heno> cubicool: go ahead
[09:07] <cjwatson> ttoine: the instructions you already have should work fine
[09:07] <cjwatson> ttoine: why don't you try them first? :-)
[09:08] <ttoine> cjwatson : i can't try everything on my laptop, i use it for work
[09:08] <ttoine> so i if crashed.... it is not good for me
[09:09] <ttoine> cjwatson: i think that do you know where i can find what packages are in the backports ?
[09:09] <cjwatson> ttoine: no, that sort of thing is pretty unlikely to cause a crash; what you do is try the change, keep the file open in your editor running as root, log in e.g. from the console on Ctrl-Alt-F1 and run 'ulimit -a' to see what it says
[09:10] <cjwatson> then if it seems to be going wrong you can always undo the change in the running editor and save again
[09:10] <cjwatson> ttoine: it's in regular dapper/edgy; you already have it installed
[09:10] <cjwatson> assuming you have dapper/edgy installed at all
[09:11] <cjwatson> by backport I mean that the individual change was backported from upstream before dapper was released, not that it was uploaded to dapper-backports or edgy-backports
[09:11] <ttoine> ok, i am running edgy or dapper, it depends
[09:11] <ttoine> oh, ok, sorry
[09:11] <ttoine> so it is in
[09:11] <ttoine> so the only thing i miss on edgy is pre-empt
[09:12] <ttoine> i will need to test with dapper or dist-upgrade to feisty, to test
[09:12] <ttoine> edgy's kernell is not good for real time
[09:13] <_MMA_> ttoine: If I remember right BenC said you could use the -lowlatency kernels on Edgy.
[09:13] <_MMA_> I dont know if thats changed.
[09:13] <_MMA_> I did it a while ago.
[09:13] <crimsun> you still can.
[09:13] <_MMA_> cool
[09:13] <BenC> it should work, but I suggest updating module-init-tools and initramfs-tools aswell
[09:14] <ttoine> well, men, just, these are not in the standards ubuntu edgy repo, no ?
[09:14] <_MMA_> No. You would have to chang to the feisty repos than change back.
[09:14] <_MMA_> *change
[09:15] <ttoine> ok, will try that
[09:15] <ttoine> thanks for answers, cjwatson and BenC
[09:15] <_ion> ...or use pinning to get updates.
[09:15] <ttoine> what is pinning ?
[09:16] <BenC> complex apt stuff
[09:16] <ttoine> so not for me
[09:16] <LaserJock> why not just download the packages, it's not that many really
[09:16] <ttoine> could be a good simple way, yes
[09:17] <_ion> apt_preferences(5) for horrible documentation, but there are some examples.
[09:17] <BenC> LaserJock: Because you don't get dependencies
[09:17] <ttoine> so i need the -lowlatency kernell, module-init-tools and initramfs-tools
[09:17] <ttoine> right ?
[09:17] <LaserJock> BenC: bah ;-)
[09:18] <LaserJock> there for a sec I thought we were talking about rpms :p
[09:18] <Nafallo> just run feisty. it's not that broken :-)
[09:19] <_ion> At least when it happens to boot. ;-)
[09:19] <Nafallo> I'm glad DMA is back though :-P
[09:19] <ttoine> actually, i am waiting a lot for bluez-gnome too for my mobile internet connection
[09:25] <ttoine> so feisty will be soon on my laptop
[09:25] <Nafallo> :-)
[10:11] <pitti> cjwatson: I fixed the regression from bug 59946 and added the new g-s-t debdiff; eyeballing and approval appreciated
[10:11] <Ubugtu> Malone bug 59946 in gnome-system-tools "Admin tools require admin group membership" [High,Fix committed]  https://launchpad.net/bugs/59946
[10:48] <pitti> good night everyone!
[11:13] <sistpoty> lamont | Mithrandir: can one of you please give back kdesvn? (builds fine now). Thanks.
[11:24] <lifeless> moining
[11:26] <bddebian> Heya lifeless
[11:30] <Nafallo> hi lifeless :-)
[11:45] <Keybuk> that's weird, why has X-Chat lost the tabs and gained a list box instead?
[11:46] <Keybuk> oh, I see
[11:46] <Keybuk> it's a menu option
[11:49] <Nafallo> Keybuk: :-)
[11:50] <Keybuk> Monospace looks too tall :-/
[11:50] <Nafallo> Keybuk: what have you done to the poor system? :-)
[11:50] <Keybuk> Nafallo: installed it
[11:51] <Nafallo> Keybuk: how mean ;-)
[11:55] <Keybuk> I seem to be, as usual, getting the best looking results by setting everything *exactly* wrong!
[11:56] <Nafallo> lol
[11:57] <Keybuk> enabling the Autohinter for Vera
[12:01] <keescook> say, in python, what's the best way to test that an array contains a specific value?
[12:01] <Keybuk> ok, think that's best
[12:01] <Keybuk> the wrong DPI setting, and auto-hinter enabled ;)
[12:02] <Nafallo> :-P
[12:05] <sistpoty> keescook: how about yourarray.count(needle) > 0?
[12:06] <keescook> sistpoty: yeah, cool, I was about to use .index, but .count works too.  thanks!
[12:06] <sistpoty> np
[12:07] <sistpoty> keescook: bah, I'm dumb... x in yourarray should be the simplest
[12:08] <keescook> ack!  ah, yeah, I think that's the syntax I'd seen before but couldn't find.  :)
[12:10] <Riddell> Keybuk: do you know what the status of digikamimageplugins is?  when I upload a new version it disappears without notice
[12:11] <Keybuk> Riddell: no, I haven't arranged ssh access with the key on this laptop yet either