[00:00] <asac> pitti: thanks.
[00:12] <blueyed> geser: I'm working on virtualbox-ose-modules.. I wasn't aware that 7 already FTBFS when uploading version 8. Currently waiting for the testbuild in ppa.
[00:13] <geser> blueyed: good, I just wanted to look at it myself
[00:14] <geser> blueyed: you need some special case for i386/amd64 as linux-headers-{i386,virtual} doesn't seem to exist on amd64
[00:26] <dcode> this isn't a specific question about ubuntu, but I figured you guys could point me in the right direction.....how can I get the source for Launchpad?
[00:26] <RAOF> dcode: You'd be after #launchpad, and you can't.
[00:26] <dcode> the URL for hte project on launchpad is sftp...which obviously requires a user/pass
[00:26] <TheMuso> dcode: The source for launchpad is not available
[00:26] <dcode> drat
[00:26] <dcode> okeyday....
[00:27] <dcode> thanks for the infos
[00:33] <blueyed> geser: yes, that's what I have in my ppa already. The FTBFS however seems to occur because of KDIR vs. KERN_DIR.
[00:34] <geser> blueyed: I could successfully build a slightly modified package (changed flavours for amd64) on amd64
[00:34] <geser> blueyed: what was the problem there as I didn't need to change here nothing
[00:36] <blueyed> geser: seems specific to the buildds, because it worked in my pbuilder, too. See http://launchpadlibrarian.net/11610543/buildlog_ubuntu-hardy-i386.virtualbox-ose-modules_7_FAILEDTOBUILD.txt.gz
[00:38] <geser> blueyed: looking at your -9~blueeyedppa2 packages: you need to change dh_gencontrol -a to dh_gencontrol -s as else dh_gencontrol will complain that some packages aren't for amd64
[00:38] <geser> the same for dh_builddeb
[00:39] <blueyed> geser: ok, anything else?
[00:41] <geser> blueyed: that seems to be the only change between your rules and mine
[00:42] <geser> blueyed: my package build successfully in my amd64 pbuilder but not in the i386 pbuilder, it failed during the -generic flavour
[00:42] <geser> at least I've packages for amd64 so I can play with virtualbox tomorrow :)
[00:43] <blueyed> geser: fine.. :) i386 does not  fail for me.. I'll reupload to my ppa and to universe, if it works out ok. Thanks.
[00:43] <geser> Thank you.
[02:38]  * Hobbsee waves
[02:39] <bddebian> Heya Hobbsee
[02:46] <TheMuso> Heya Hobbsee.
[02:46] <Hobbsee> hiya luke!
[07:12] <warp10> Good morning
[07:12] <Hobbsee> morning
[07:13] <warp10> Hobbsee: :)
[07:30] <dholbach> good morning
[07:32] <pitti> Good morning
[07:33] <Hobbsee> pitti!
[07:33]  * pitti hugs Hobbsee
[07:33]  * Hobbsee hugs pitti back
[07:33] <warp10> Good morning pitti! :)
[07:34] <pitti> hey warp10
[07:37] <StevenK> Hey pitti!
[07:40]  * pitti waves towards Australia again and sends hugs to StevenK
[07:41]  * StevenK isn't in Australia right now. Please leave a hug after the beep.
[07:41] <Hobbsee> oy!
[07:44] <pitti> StevenK: oh. sprint. right
[07:44] <StevenK> pitti: Right :-)
[07:48] <superm1> doko, are you around?  I wanted to chat with you re vnc4's src package.
[07:51] <superm1> doko, particularly regarding bug 184225 whenever you return.
[07:51] <ubotu> Launchpad bug 184225 in vnc4 "FTBFS in latest archive rebuild test" [High,Confirmed] https://launchpad.net/bugs/184225
[08:49] <juliank> aufs support for casper - patch now available - bug #187259
[08:49] <ubotu> Launchpad bug 187259 in casper "Add support for Aufs" [Undecided,New] https://launchpad.net/bugs/187259
[08:53] <cjwatson> asac: so, network-manager in your PPA doesn't seem to manage to support either my wired or my wireless interface. Where do you want me to start with debugging?
[09:11] <Mez> hmm - and my PC now no longer has permission to set an IP address by DHCP
[09:22] <asac> cjwatson: intersting ... what do you mean by "manage" ... not detected, or just cannot connect?
[09:28] <asac> what chipsets do you have?
[09:28] <cjwatson> asac: as soon as I upgraded, it brought the running wired interface (managed by n-m 0.6) down, and the applet now only offers manual configuration as an option
[09:28] <cjwatson> asac: tg3 (wired), b43 (wireless)
[09:28] <cjwatson> it recognises both and says "eth0: Device is fully-supported using driver 'tg3'." and "eth1: Device is fully-supported using driver 'b43'." respectively
[09:28] <cjwatson> for the latter, it says "eth1: driver does not support SSID scans (scan_capa 0x00)."
[09:28] <cjwatson> (pretty sure it used to though)
[09:29] <asac> odd
[09:30] <asac> i think our kernel lacks the linville scan_capa patches ... but that shouldn't make the interfaces completely unusable
[09:30] <cjwatson> Jan 30 08:52:08 sarantium NetworkManager: <info>  eth0: Device is fully-supported using driver 'tg3'.
[09:30] <cjwatson> that's just weird, too :)
[09:30] <cjwatson> Jan 30 08:52:08 sarantium NetworkManager: <info>  Now managing wired Ethernet (802.3) device 'eth0'.
[09:31] <cjwatson> Jan 30 08:52:08 sarantium NetworkManager: <info>  Bringing down device eth0
[09:31] <cjwatson> followed by:
[09:31] <cjwatson> Jan 30 08:52:10 sarantium NetworkManager: <info>  Bringing up device eth0
[09:31] <cjwatson> Jan 30 08:52:10 sarantium kernel: [21713.328605] ADDRCONF(NETDEV_UP): eth0: link is not ready
[09:31] <cjwatson> Jan 30 08:52:10 sarantium NetworkManager: <info>  Deactivating device eth0.
[09:31] <asac> hmm ... do you have the right applet version?
[09:32] <cjwatson> http://people.ubuntu.com/~cjwatson/tmp/nm-syslog
[09:32] <asac> is it 0.7 as well?
[09:32] <asac> cjwatson: Forbidden :)
[09:32] <asac> ah now
[09:32] <cjwatson> network-manager-gnome   0.7~~svn20080121t194048-0ubuntu0~pre6
[09:32] <cjwatson> 403 fixed
[09:33] <asac> i assume you tried to restart nm-applet multiple times already?
[09:35] <cjwatson> *** glibc detected *** nm-applet: munmap_chunk(): invalid pointer: 0x0807ac8e ***
[09:35] <cjwatson> I don't think it likes me
[09:35] <asac> yes ... that happens sometimes on startup
[09:35] <asac> just try another time ... should come up then
[09:35] <cjwatson> http://people.ubuntu.com/~cjwatson/tmp/nm-applet-crash
[09:36] <cjwatson> seems to be in the code to migrate gconf from 0.6
[09:36] <asac> oh it crashes while migrating
[09:36] <asac> hmm
[09:36] <asac> maybe backup your gconf database and wipe everything below /system/networking in gconf
[09:36] <cjwatson> ok, good call, after restarting nm-applet it detects the wired interface again
[09:37] <asac> (backup to keep it reproducible)
[09:37] <cjwatson> pretty messy upgrade issue though
[09:37] <asac> cjwatson: was the previous start your first start?
[09:37] <cjwatson> oh, err, I've already restarted nm-applet, so it might be too late; taken a backup now
[09:37] <cjwatson> yes
[09:37] <asac> damn :)
[09:38] <asac> well ... i assume that your previous nm-applet instance running was still the old one then.
[09:38] <cjwatson> it was
[09:38] <asac> next start was your first start (migration crashed) ... and now it works
[09:38] <cjwatson> looks like we need to arrange to restart it though, somehow
[09:38] <asac> cjwatson: any pointers appreciated :)
[09:38] <cjwatson> since it takes out networking otherwise
[09:39] <asac> seb128: i think nm-applet is started by gnome session ... can i somehow trigger a restart for specific apps on upgrade?
[09:40] <seb128> asac: no
[09:40] <seb128> asac: you can get nm-applet react to signals and have the postinst using that though
[09:40] <cjwatson> seb128: got a handy time machine? :)
[09:41] <asac> lol
[09:41] <cjwatson> you could have the postinst search for processes called nm-applet, kill them, switch to the corresponding user(s), and restart them
[09:41] <cjwatson> (UGLY AS SIN)
[09:41] <asac> ouch
[09:41] <cjwatson> ... with the right command-line arguments
[09:42] <asac> then we should just restart twice as on first start it will crash :-P
[09:42] <cjwatson> have you tried something like: basic gutsy install, connect to wireless network, save that gconf database?
[09:42] <asac> yeah ... but at least we could do it somehow
[09:42] <asac> (restarting)
[09:44] <asac> cjwatson: nope ... I haven't really looked into this as its just a random snapshot from a quick progressing svn tree.
[09:44] <asac> if it doesn't go away in next snapshot i know where and how to look now
[09:46] <asac> unfortunately, i have to stop everything and do mozilla security now ... an exploit leaked so the release was rescheduled to be next mon/tue.
[09:47] <asac> :(
[09:47] <Kano> hi
[09:48] <superm1> hi Kano. juliank ended up adding aufs to lum today
[09:48] <Kano> i know, i use that kernel already
[09:48] <Kano> but casper is not yet patched
[09:48] <superm1> yeah there is a bug filed regarding it
[09:48] <Kano> live-helper worked however
[09:48] <superm1> just needs a sponsor from core-dev
[09:49] <superm1> bug #187259
[09:49] <ubotu> Launchpad bug 187259 in casper "Add support for Aufs" [Undecided,New] https://launchpad.net/bugs/187259
[09:49] <cjwatson> asac: disassembly says it's the g_object_unref after reading a wireless connection, btw
[09:49]  * asac looking
[09:49] <cjwatson> (there are two in that function)
[09:50] <Kano> superm1: i updated my patch a little bit
[09:50] <superm1> Kano, juliank is the one that attached it to the bug.  any differences you have you may just want to attach to that same bug
[09:50] <Kano> panic "Unionfs mount failed" is now panic "${UNIONTYPE} mount failed"
[09:51] <Kano> because then you see what ovfs you used
[09:51] <Kano> rest is still the same
[09:52] <Kano> not huge, but looks better
[09:52] <juliank> Kano: it is ${UNIONFS} now, not ${UNIONTYPE} used in Debian.
[09:52] <Kano> call it like you want
[09:52] <asac> cjwatson: can you see if its the wireless ... or the vpn one?
[09:52] <Kano> but use it at this point
[09:53] <cjwatson> asac: fairly sure it's the wireless one; it's well under halfway through the function (lots of inlined stuff)
[09:53] <cjwatson> and the calls before it look to be from the inlined wireless code
[09:53] <tkamppeter> pitti, hi
[09:53] <pitti> hi tkamppeter
[09:53] <Kano> basically some more options from live-helper should be backported, casper is really very primitive against it...
[09:54] <cjwatson> asac: it might be relevant that the most recent change to gconf-helpers.c was labelled as fixing memory leaks
[09:54] <tkamppeter> pitti, about bug 185602, you fixed the ghostscript documentation issues once, with this bug they reappeared, can you fix this again?
[09:54] <ubotu> Launchpad bug 185602 in ghostscript "[amd64] Building of architecture-independent parts (docs) of Ghostscript not stable against small toolchain changes" [High,New] https://launchpad.net/bugs/185602
[09:54] <Kano> like live-media-path option
[09:55] <pitti> tkamppeter: it doesn't have anything to do with the toolchain; I suspect the patch was dropped during the last merge, or so
[09:55] <TheMuso> evand: You are a bloody legend! I have been meaning to do that in casper for quite a while now! I owe you a beer at the next event!
[09:55] <Kano> or how do you combine more than one live cd on dvd?
[09:55] <pitti> tkamppeter: yes, it's in my ubuntu mbox, I'll have a look
[09:55] <pitti> tkamppeter: (feel free to beat me to it :) )
[09:55] <tkamppeter> pitti, and if you fix that one, can you also apply the proposed patch of bug 183628
[09:55] <ubotu> Launchpad bug 183628 in ghostscript "ghostscript crashes after loading 20 page repeatedly" [Undecided,New] https://launchpad.net/bugs/183628
[09:56] <pitti> tkamppeter: ok
[09:57] <tkamppeter> pitti, I have marked the bug 185602 as an alpha 4 milestone, as it can break the distro's consistency.
[09:57] <ubotu> Launchpad bug 185602 in ghostscript "[amd64] Building of architecture-independent parts (docs) of Ghostscript not stable against small toolchain changes" [High,New] https://launchpad.net/bugs/185602
[09:57] <tkamppeter> pitti, thanks in advance
[09:58] <cjwatson> asac: for the record, wireless works too having restarted nm-applet, so I'm happy for the time being
[09:59] <juliank> Kano: Updated the patch
[09:59] <Kano> fine
[09:59] <Kano> now you only need a number for the new kernel/lum and casper
[09:59] <Kano> and then you can autobuild it
[10:00] <Kano> do you know live-helper?
[10:01] <juliank> Kano: I wrote the patch to add aufs support to live-helper/live-initramfs.
[10:01] <Kano> juliank: well the change is not really huge ;)
[10:01] <Kano> how about adding some things from live-helper back
[10:02] <Kano> toram, media*
[10:03] <juliank> Kano: toram is already in casper
[10:04] <Kano> i think it had a problem in live-helper, then something went wrong
[10:04] <Kano> i think the cd could not be used
[10:04] <TheMuso> juliank: Perhaps it might be better to branch casper trunk, add your patch, and add the URL to your branch on the bug.
[10:04] <Kano> to burn then
[10:04] <Kano> did you try?
[10:04] <TheMuso> Then its a matter of a core-dev merging your changes.
[10:04] <juliank> TheMuso: The branch is not working.
[10:04] <cjwatson> a patch is usually fine, FWIW
[10:05] <Kano> the patch is so small, hard to make any huge mistakes ;)
[10:05] <TheMuso> cjwatson: Yeah I know. I just remember back in the day when I started the a11y stuff, I was asked to do a branch. :)
[10:05] <cjwatson> yeah, I think that was larger and more complex, and possibly needed a few iterations of merging and such
[10:05]  * ogra wonders why he finds his laptop hardlocked every morning :(
[10:05] <TheMuso> cjwatson: There is truth to that.
[10:07] <juliank> TheMuso, cjwatson: "KnitCorrupt: Knit 9e/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21
[10:07] <juliank> "
[10:07] <cjwatson> well, today's alternate CDs seem happier
[10:07] <cjwatson> juliank: blink; I can only say it works fine for me and suggest #bzr for debugging
[10:08] <TheMuso> juliank: Where are you getting that branch from?
[10:08] <cjwatson> could be genuine network data corruption I suppose
[10:08] <cjwatson> Arch-1:matt.zimmerman@canonical.com%casper--main--0--patch-21 is in the tree I have
[10:08] <Kano> also is it really hard to add a very small patch to mesa?
[10:09] <cjwatson> (corresponding to r22)
[10:09] <Kano> until you add that i can not boot ubuntu
[10:10] <Kano> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/151974
[10:10] <ubotu> Launchpad bug 151974 in mesa "[RV410] X700SE [1002:5e4f] - DRI images corrupted" [Undecided,Fix committed]
[10:10] <Kano> that patch is not in the debian package,but debian does not enable compiz by default
[10:10] <cjwatson> Kano: our X maintainer is GMT-0800 and unlikely to be around right now ...
[10:10] <juliank> TheMuso, cjwatson: lightweight checkout worked - I am also not able to view files using codebrowse.launchpad.net for this project, gives 500 internal error
[10:11] <juliank> debian/changelog
[10:11] <cjwatson> Kano: (oh, well, tjaalton is in a convenient timezone, I didn't realise he was dealing with this one)
[10:11] <Kano> he added 2 debian patches, a 3rd one would not hurt...
[10:11] <Kano> err 2 ubuntu ones
[10:12] <TheMuso> cjwatson: re the initramfs error handling spec: I have managed to reproduce the behavior reported in bug 31126, however unlike what one comment in that bug says, dpkg now fails, due to no space left on device. However, the initramfs is still corrupted. So in terms of the spec, I guess aborting is bhappening somewhat, but I am now not sure how part of the spec applies...
[10:12] <ubotu> Launchpad bug 31126 in initramfs-tools "Doesn't check for failure due to full filesystem" [High,Confirmed] https://launchpad.net/bugs/31126
[10:13] <Kano> it is really bad when you boot a system and see a chess board only
[10:13] <cjwatson> TheMuso: software should recover from out-of-disk-space without corrupting data, as a general rule
[10:13] <cjwatson> TheMuso: it does indeed abort, but it should leave you with a working initramfs
[10:13] <TheMuso> cjwatson: Yes, but how do we do that if there is no room?
[10:13] <cjwatson> TheMuso: see the design in the spec :)
[10:13] <cjwatson> it should write the new initramfs and move it into place
[10:13] <cjwatson> that approach defends against this problem
[10:14] <TheMuso> But thats what happens now is it not?
[10:14] <cjwatson> no, it is not
[10:14] <davmor2> is Ubuntu safe for iso testing?  Are there any major bug fixes in process?
[10:14] <TheMuso> cjwatson: Oh, it gzips it straight into boot?
[10:14] <cjwatson> TheMuso: right
[10:14] <Kano> juliank: do you work with live-helper on ubuntu?
[10:14] <cjwatson> TheMuso: the standard approach is gzip -c > foo.new and then move foo.new to foo
[10:15] <cjwatson> but mkinitramfs just does this:
[10:15] <cjwatson> (cd "${DESTDIR}" && find . | cpio --quiet --dereference -o -H newc | gzip -9 >"${outfile}") || exit 1
[10:15] <cjwatson> that's guaranteed to leave a corrupted initramfs if anything goes wrong
[10:15] <cjwatson> which is what the first part of the suggested code changes in the spec address
[10:15] <cjwatson> es
[10:15] <juliank> Kano: I don't build ubuntu live disks, I just provided this patch for casper.
[10:16] <TheMuso> cjwatson: But how does symlinking the .bak help here? (From reading the code in the spec)
[10:16] <cjwatson> http://codebrowse.launchpad.net/~ubuntu-core-dev/casper/trunk/files seems to work for me, FWIW
[10:17] <juliank> cjwatson: Click on debian/changelog
[10:17] <cjwatson> TheMuso: that's not a symlink
[10:17] <Kano> cjwatson: did you see that left over swp file in the casper package?
[10:17] <cjwatson> Kano: yes, I don't care, it'll go away next upload
[10:17] <TheMuso> cjwatson: Ah right, I see that now
[10:17] <Kano> not that you forget that ;)
[10:17] <cjwatson> evand: ^-- .swp presumably in your tree
[10:17] <cjwatson> Kano: it doesn't matter, it makes no difference to anything
[10:18] <cjwatson> TheMuso: let me try to remember, I know that logic was important
[10:18] <cjwatson> TheMuso: oh, right, it was because the existing initramfs logic tries to leave a .bak file
[10:19] <TheMuso> cjwatson: So, let me try and get this right in my head. It hard links to a .bak file, conserving some space. The new initramfs is built, and moved into place... If it fails, theres still a useful initramfs?
[10:19] <cjwatson> TheMuso: at the moment, it moves the old one to .bak first and then regenerates
[10:19] <TheMuso> cjwatson: Right, I noticed the .bak file using up space on /boot which seemed pointless
[10:20] <cjwatson> well, it would still be a separate file, but let's not worry about that right now; simplest approach is to preserve existing behaviour while making it safer
[10:20] <cjwatson> the ln/mkinitramfs/mv approach means that at most 2x the size of the initramfs is used in /boot at any one time
[10:20] <cjwatson> cp would work as well as ln, but would use 3x the size of the initramfs for a short period
[10:21] <cjwatson> so hardlinking is more efficient in this case
[10:21] <cjwatson> the point where the initramfs generation can fail is when it's writing to .new
[10:21] <TheMuso> cjwatson: Right, So we hard link, generate new initramfs, copy over, if all is well, remove hard link?
[10:21] <cjwatson> but that's fine, because the boot process doesn't look at it
[10:21] <TheMuso> oh right .new
[10:21] <cjwatson> mv (on the same filesystem) is atomic; it either succeeds or fails, but cannot fail part-way through
[10:21] <TheMuso> right
[10:22] <cjwatson> don't need to remove the hard link because the mv breaks it
[10:22] <cjwatson> but safely, so that .bak is still the old fine
[10:22] <TheMuso> Ah of course.
[10:22] <cjwatson> file
[10:23] <pitti> tkamppeter: fixed
[10:23] <TheMuso> cjwatson: Ok, thanks. Things are much clearer, I've got something to go from now. Will hack on it tomorrow and go from there.
[10:23] <cjwatson> TheMuso: this is all done under 'set -e', so any failures will cause the shell script to terminate immediately
[10:23] <cjwatson> well, update-initramfs is set -e at any rate; mkinitramfs isn't, but it checks errors in the important places here already
[10:24] <TheMuso> Right.
[10:25] <cjwatson> under set -e, you basically get try/catch ;-)
[10:25] <TheMuso> cjwatson: Yeah I know. I've done a lot of my own stuff under -e.
[10:26]  * cjwatson nods
[10:26] <TheMuso> And of course, at set -x would have helped me find that gzip dumps straight to boot. :p
[10:27] <cjwatson> juliank: good point; I'm not sure whether that's a matter for #bzr or #launchpad but it'll be one of those
[10:27] <cjwatson> juliank: like I say, a patch is fine for now
[10:29] <tkamppeter> pitti, thanks
[10:30] <Mez> cjwatson, your issues with NM - for some reason I have issues with NM too ... and now can only select manual configuration to have it work properly, as it seems that dhclient is recieving permission denied errors when trying to configure the card (however, when I manually set things up - everything's fine)
[10:31] <Mez> but setting up things manually for wireless isn;t going to be fun
[10:33] <cjwatson> Mez: unless you're using asac's hardy PPA, it's unrelated
[10:33] <Mez> cjwatson, oh, damn - then I have an issue which I need to fix :( and have no idea where to start
[10:36] <tkamppeter> pitti, important HPLIP bug fix for Alpha 4, biff
[10:37] <pitti> tkamppeter: while you are at touching/testing hplip, could you please make it stop using the 'scanner' group?
[10:37] <pitti> tkamppeter: in theory your user should have an ACL on whichever devices are created for this, so that you can access them without a particular group
[10:41]  * TheMuso will do CD testing in the morning, and notify accordingly. Need sleep now. :)
[10:52] <tjaalton> Kano: as I told you it would be nice if you first make sure that the patch will get in 7.0.3. I'm not sure there's time for a new upload for alpha4 though
[11:02] <davmor2> having massive issue's with gvfs.  I'm an iso tester and I can't burn more than one cd without needing to restart the machine to burn the next :(  That's a major regression
[11:03] <awalton__> and that's a GVFS issue.. how exactly?
[11:04] <davmor2> awalton__: never happened before gvfs was introduced
[11:04] <awalton__> that's not really an answer, that's a coincidence.
[11:05] <awalton__> hal problems perhaps?
[11:06] <awalton__> if it's really a GVFS issue, we've gotta know because it'd be a pretty serious bug.. but from my POV it's hard to see gvfs doing anything special in this regard.
[11:06] <davmor2> awalton__: I've been having serious issues with gnomes reliablity sinse gvfs was introduced.  I'm no expert by any shape or means but it has only been since it's introduction.  Before hand everything worked fine.
[11:07] <awalton__> have you tried removing gvfs and seeing if the problem still presents?
[11:07] <davmor2> If you can tell me how to track it down I can help.  But I have no idea at all
[11:07] <awalton__> removing the hal backend?
[11:07] <davmor2> I'll give it a bash
[11:08] <davmor2> is it just gvfs I need to remove?  What is the hal backend called?
[11:09] <awalton__> the first thing I'd try is just plain removing all of gvfs.. apt-get remove it
[11:09] <Kano> tjaalton: agd5f merged it, ask him if you don't believe me
[11:09] <awalton__> if the problem goes away, then we can pin it down from there
[11:10] <davmor2> awalton__: ok nps need to reboot I'm running in kubuntu live at the moment so I could get some discs burnt
[11:11] <Kano> tjaalton: i gave him another patch, he made this one, i tested it and he added it to mesa
[11:12] <Kano> tjaalton: as long as the patch is not applied i can not boot ubuntu with enabled compiz, thats clear or not?
[11:14] <tjaalton> Kano: ok, that was 20h ago according to the logs
[11:20] <tjaalton> Kano: uploaded
[11:21] <Kano> fine
[11:21] <Kano> maybe i can test u sooner or later on real hardware then...
[11:21] <Kano> vbox is abit boring ;)
[11:26] <Riddell> evand, cjwatson: ubiquity install fails with "The installer needs to remove operating system files from the install target, but was unable to do so.  The install cannot continue."
[11:28] <cjwatson> Riddell: evand was working on that yesterday
[11:28] <cjwatson> 16:41 <evand> ah, so my logic in clear_partitions completely fails to account for the fact that you cannot remove a directory that's a mountpoint.
[11:29] <cjwatson> I believe it's on the alpha-4 milestone list
[11:29] <Riddell> cjwatson: ok thanks
[11:32] <Kano> cjwatson: do you think you could modify initramfs to support a blacklist option BEFORE udev is started. i see no hook to get started before udev
[11:33] <tkamppeter> pitti, about HPLIP, can you upload my package and I remove the scanner group stuff with the next HPLIP upload, as this HPLIP fixes an urgent bug for Alpha 4.
[11:33] <pitti> tkamppeter: I can do that
[11:33] <tkamppeter> thanks, pitti.
[11:33] <cjwatson> Kano: I don't maintain initramfs-tools routinely; I just edit it when I need to
[11:35] <pitti> tkamppeter: done
[11:39] <cjwatson> slangasek: I synced debconf 1.5.19; should help with grub/ucf
[11:42] <zero-9376> hi can someone tell me if the bug where nautilus doesn't fall back on default search if tracker is removed has been resolved please ive been searching the forums but there's no definitive answer that i can see and i dont have the data allowance to download the alpha
[11:43] <zero-9376> and the closest matching launchpad bug i can see is wishlisted?
[11:44] <zero-9376> ahh sorry wrong channel :-[
[12:13]  * Hobbsee stomps on tomboy
[12:44] <jwendell> morning, seb128
[12:44] <seb128> hey jwendell
[12:44] <jwendell> seb128, do you plan to package new gdm to hardy?
[12:45] <seb128> jwendell: no
[12:45] <jwendell> seb128, :(
[12:45] <seb128> jwendell: it's not tested, has no themed login, no setting migration, no autologin, no graphical config tool, etc
[12:46] <seb128> jwendell: hardy will be a lts, that would not be a smart move, why do you need this one?
[12:46] <jwendell> seb128, you mean gdm 2.21.5 ?
[12:46] <seb128> jwendell: no, I mean 2.21 SVN
[12:47] <seb128> jwendell: they should be in freeze and debug bug, not writting thousand of lines of code every week now
[12:47] <jwendell> seb128, actually I don't need that version. It's just that I'd want to fill a bug about not playing the sound, and I'd like to test newer version before doing this...
[12:48] <seb128> jwendell: 2.21 is a rewrital, but you can still open 2.20 bugs, it's still maintained and they will another tarball
[12:48] <seb128> they will roll another tarball
[12:48] <jwendell> seb128, ok, thanks
[12:48] <seb128> you are welcome
[13:05] <Kano> how about updateing fuse+ntfs-3g?
[13:05] <Kano> until it is frozen again ;)
[13:09] <Kano> btw. fuse has a newer version in debian. for ntfs-3g you could look at my package if needed...
[13:09] <cjwatson> Kano: I already updated fuse
[13:09] <Kano> when?
[13:09] <cjwatson> yesterday
[13:09] <Kano> good
[13:09] <Kano> then only ntfs-3g remains
[13:09] <cjwatson> I'll do ntfs-3g once the Debian maintainer does it; he's usually pretty quick
[13:10] <Kano> well i am quicker, i had even the rc packaged ;)
[13:10] <cjwatson> that's nice
[13:10] <Kano> it is a bit different
[13:10] <Kano> because you dont need fuse as build-dep
[13:10] <Kano> has integrated fuse-lite
[13:10] <cjwatson> I don't see a reason to avoid the fuse build-dep
[13:11] <Kano> i see it
[13:11] <Kano> when ntfs-3g would need an fuse update then you need to update 2 package, so only 1
[13:12] <cjwatson> that doesn't count
[13:12] <Kano> well if you dislike it you can enable external fuse
[13:12] <Kano> as you have 2.7.2 this should do too
[13:12] <cjwatson> a much more important reason *not* to do that is that if a security problem is found in fuse then the security team would have to run around finding everything that's copied it.
[13:13] <cjwatson> we dislike it and already have enabled external fuse. you do not need to tell us that :)
[13:13] <Kano> http://ntfs-3g.org/releases.html
[13:13] <Kano> New: the --with-fuse=external configure option makes NTFS-3G to be compiled with an external FUSE library. For non-Linux operating systems this is the default and the only compilation option currently.
[13:13] <Kano> then use that option
[13:14] <cjwatson> I'm sure the Debian maintainer will do so
[13:14] <cjwatson> I am quite happy to wait
[13:14] <Kano> i am sure he will not
[13:14] <cjwatson> if he doesn't, the Debian security team will ask him to change
[13:14] <cjwatson> (as soon as they notice)
[13:15] <Kano> btw. it makes it more easy to backport
[13:15] <cjwatson> please leave me alone
[13:15] <cjwatson> I have said no and I mean no
[13:15] <Kano> as long as you update it...
[13:16]  * cjwatson applies /ignore, as he is getting bad-tempered
[13:23] <ogra> who is doing release notes for alpha4 ?
[13:24] <seb128> do we add users to the fuse group nowadays?
[13:25]  * ogra hopes not 
[13:25] <Hobbsee> ogra: slangasek
[13:25] <seb128> ogra: why?
[13:25] <seb128> ogra: that's required to get gvfs using fuse which is very handy (allow all GTK applications to use network shares transparently)
[13:25] <ogra> seb128, well, i rely with ltspfs on the fact that users have no local device access by default on thin clients ...
[13:25] <ogra> i would have to rework that model
[13:26] <ogra> my users want this access to be off by default ...
[13:26] <ogra> the fuse group was my switch until now, as nothing else used it by default
[13:26] <seb128> ogra: just don't install gvfs-fuse on ltsp then
[13:26] <ogra> seb128, its not about gvfs ... but the group membership
[13:27] <ogra> an admin has to enable it deliberately currently
[13:27] <seb128> can't you have different membership on ltsp then?
[13:27] <seb128> right
[13:27] <seb128> and I just noticed that's why gvfs fuse mounting is not working
[13:27] <ogra> no, i'd need hacks to ltspfs
[13:27] <ogra> its not designed for extra ACL stuff yet
[13:27] <seb128> and I think transparent access to network share for all gtk applications is something we should have
[13:28] <seb128> that would allow acroread, etc to open files on smb shares
[13:28] <ogra> i bet i can do it easily on a per client base ... but thast not how its documented and would need changes in my users habits
[13:28] <seb128> I take acroread as an example because that's one we can't hack to make it use gvfs ;-)
[13:28] <ogra> since we currently do it on a per-user base
[13:29] <seb128> maybe that should be something to discuss on the mailinglist
[13:29] <ogra> seb128, if thats really decided to be done, please notify me and i'll ask the ltsp community how they like to have it
[13:30] <seb128> well, that's how gvfs work
[13:30] <ogra> probably they would even be happy with all users being able to use localdev out of the box :)
[13:30] <seb128> we can decide to use the feature or not now
[13:31] <stgraber> ogra: I would :) I never was requested to turn local devices off
[13:32] <Mirv> Hi. If someone would have time, please do a rebuilt / binary-only upload of openoffice.org-voikko to have bug #187083 fixed for Alpha 4 testers.
[13:32] <ubotu> Launchpad bug 187083 in openoffice.org-voikko "[hardy] openoffice.org-voikko needs a rebuild" [Unknown,Fix released] https://launchpad.net/bugs/187083
[13:33] <ogra> stgraber, right, when i defaulted to having it on for everyone jammcq and sbalneav complained it should be an opt-in feature and no default
[13:33] <ogra> so i'll return to tehm to discuss it
[13:34] <stgraber> ogra: it should be something we can turn on or off for everyone (or eventually a lts.conf option), having to add all the users to the fuse group isn't really admin-friendly
[13:34] <ogra> the prob here is that you cant steer it through the group membership anymore (which is documented everywhere in the edubuntu docs)
[13:34] <ogra> it will tear down other features as well
[13:34] <ogra> thats waht worries me most here
[13:35] <ogra> stgraber, right, but that would work only on a per-client-machine base, not per-user anymore
[13:36] <ogra> lts.conf doesnt know about users
[13:36] <ogra> and i hope it will naver have to :)
[13:37] <ogra> *never
[13:38] <tjaalton> Mirv: I can do that
[13:41] <tjaalton> Mirv: uploaded
[13:41] <stgraber> ogra: indeed, but are people really using it as a per user filter ? or just as an on/off switch for all the users ?
[13:42] <tjaalton> Mirv: I didn't even notice that l-s-fi isn't on my systems currently :)
[13:44] <ogra> stgraber, no idea, i have to rely on jammcq and sbalneav, i onlyheard complaints from users that it wasnt on by default
[13:44] <ogra> so having it might actually please people
[13:45] <ogra> what i'm worried abotu is that rther is no way to disable it on a per user base anymore
[13:45] <Mirv> tjaalton: ah, thanks! yep, l-s-fi was probably uninstalled (if it was installed before) when upgrading to OOo 2.3.1, because of this.
[13:46] <tjaalton> indeed
[13:46]  * ogra would love to know what hardlocks his laptop as soon as DPMS kicks in :/
[13:46] <ogra> grmbl
[13:50] <Kano> maybe update gfx driver
[13:50] <ogra> and that should hardlock the kernel ... ? i dounbt it
[13:50] <Kano> then update kernel too ;)
[13:50]  * ogra suspects g-p-m rather
[13:50] <stgraber> ogra: or maybe acpi ?
[13:51] <ogra> stgraber, hmm
[13:51] <ogra> i never had acpi probs on that laptop
[13:51] <ogra> but a place to look at i guess
[13:53] <stgraber> ogra: oh btw, do you have an idea of why is my g-p-m detecting 3 batteries, 2 of them being the same when I only have one plugged in ? :)
[13:53] <ogra> hal bug
[13:53] <stgraber> ogra: I can understand the second one as I have an extra battery slot, but having the first 1 reported twice is hmm, weird :)
[13:53] <ogra> i think its known upstream ... ask ted gould if he's around
[13:54] <pitti> stgraber: this is pretty well understood already
[13:54] <ogra> he's doing powermanager and screensaver now
[13:54] <pitti> stgraber: primary reason is that current kernel duplicates battery information in /sys and /proc
[13:54] <ogra> ah, right
[13:54]  * ogra remembers that thread from the hal list
[13:54] <pitti> ogra, stgraber: no, it's got nothing to do with gpm; hal picks up and reports the battery twice
[13:54] <ogra> pitti, yup
[13:55] <stgraber> pitti: hmm, and hal is checking both places ?
[13:55] <pitti> stgraber: yes, to work with older and newer kernels
[13:56] <stgraber> pitti: ok, I'll have a look at hal as it also shouldn't report a battery with present=no ...
[13:56] <stgraber> or if it should, then g-p-m shouldn't as having two battery slots usually means it's some kind of docking station slot and then not likely to be used by the average user
[13:57] <cjwatson> pitti: do you think we should be having PolicyKit constrain device access to local users only?
[13:57] <stgraber> (and should only appear when you actually plug a battery in it)
[13:57] <ogra> cjwatson, eeek
[13:57] <cjwatson> pitti: I'm looking at adding ConsoleKit support to ssh (somehow) for ogra, and am concerned about the effect on the security model
[13:57] <pitti> cjwatson: which kind of device?
[13:57] <ogra> dont do that to me ...
[13:57] <cjwatson> ogra: LTSP would have to count as local somehow
[13:57] <cjwatson> err
[13:57] <cjwatson> 13:25 <ogra> seb128, well, i rely with ltspfs on the fact that users have no local device access by default on thin clients ...
[13:57] <ogra> ltspfs wouldnt
[13:57] <cjwatson> ogra: what exactly do you mean by the above?
[13:57] <cjwatson> I am very confused about LTSP's requirements :-)
[13:58] <pitti> block devices?
[13:58] <cjwatson> pitti: err, not sure
[13:58] <ogra> local == device attached to the thin client
[13:58] <Kano> ogra: what do you use for sound via network?
[13:58] <cjwatson> ogra: here, local == local to the PolicyKit instance in question
[13:58] <ogra> we have a udev rule that attaches to the ssh tunnel and fires a fuse mount script on the server ...
[13:58] <cjwatson> ogra: do you expect users to have access to e.g. a pluggable USB stick? if so from where?
[13:58] <pitti> hal currently grants access to the current user for USB devices like printers, scanners, cameras, and mass storage
[13:59] <ogra> which then establishes a ltspfs/fuse mount towards the client
[13:59] <cjwatson> pitti: let's phrase it differently; what would happen to the security model if sshd were to activate a ConsoleKit session?
[13:59] <ogra> cjwatson, physically on the client ... session management wise on the desktop
[13:59] <cjwatson> this would mean you could no longer assume that active sessions are local
[13:59] <ogra> Kano, alsa
[13:59] <pitti> cjwatson: the ssh session would be able to drive power management, mount local removable block devices, etc.
[14:00] <cjwatson> ogra: OK, let me have this conversation with pitti so that I understand the model, and then we can think about how LTSP fits in
[14:00] <cjwatson> ogra: without the former I cannot do the latter
[14:00] <Kano> ogra: alsa has network support?
[14:00] <cjwatson> pitti: do you think that is desirable?
[14:00] <pitti> the privs are currently granted under the assumption that local session  == physical access
[14:00] <stgraber> Kano: alsa plugin for pulseaudio, pulseaudio for the network part and back to alsa on the thin client
[14:01] <Kano> ah
[14:01] <stgraber> Kano: so any alsa compatible apps should work
[14:01] <cjwatson> pitti: as far as I can see, the current set of privileges are oriented around active sessions, not local sessions
[14:01] <pitti> cjwatson: in general the idea is to *not* open a *local* CK session for ssh
[14:01] <ogra> stgraber, wrong way round :)
[14:01] <pitti> cjwatson: you can have a CK session with "is-local = FALSE" if that helps
[14:01] <cjwatson> pitti: yes; does any of our current policy actually look at that, though?
[14:01] <pitti> depending on whether the problem is that no CK session exists at all, or whether it's local
[14:01] <ogra> alsa with puls plugin in the backend emulates a virtual alsa card ... pulse sits only on the client ... listening
[14:01] <cjwatson> I can't find anything that does, though I see code in PK that checks
[14:02] <cjwatson> pitti: well, the immediate problem is the former, but I want to avoid breaking things while fixing it
[14:02] <pitti> cjwatson: it's supposed to; if not, that would be a bug
[14:02] <stgraber> ogra: hmm, by alsa plugin I mean the thing redirecting the output of a software to pulse, pulse running on the thin client and having alsa as output to the speakers
[14:02] <cjwatson> $ grep local /usr/share/PolicyKit/policy/*
[14:02] <cjwatson> /usr/share/PolicyKit/policy/libvirtd.policy:      <description>Monitor local virtualized systems</description>
[14:02] <cjwatson> /usr/share/PolicyKit/policy/libvirtd.policy:      <message>System policy prevents monitoring of local virtualized systems</message>
[14:02] <cjwatson> /usr/share/PolicyKit/policy/libvirtd.policy:      <description>Manage local virtualized systems</description>
[14:02] <cjwatson> /usr/share/PolicyKit/policy/libvirtd.policy:      <message>System policy prevents management of local virtualized systems</message>
[14:02] <cjwatson> should I be looking at something else?
[14:03] <pitti> cjwatson: give me a minute to find where it evaluates locality
[14:03] <ogra> stgraber, ah, then you are right :)
[14:03] <pitti> cjwatson: one place where it is checked is the dbus policy, but that shouldn't be the only place ideally
[14:04] <pitti> cjwatson: (<policy at_console="true">) in /etc/dbus/system.d/)
[14:05] <ogra> stgraber, i'm just trying to avoid the name pulse at all because users start to play with it session side and break stuff usually (overriding teh alsa setup with some pulse tweaks etc) ... thats hard to debug
[14:05] <pitti> cjwatson: the hal addon which adds ACLs to /dev/* stuff checks it
[14:05] <cjwatson> pitti: the pam_console compat patch doesn't seem to check locality anywhere? it's just done in the session leader code
[14:07] <pitti> cjwatson: good point; I should add a check for this, thanks for spotting
[14:07] <cjwatson> ok, if that's the design, then it doesn't sound like it should break too much
[14:08] <cjwatson> (that isn't already essentially broken)
[14:08] <cjwatson> just using pam-ck-connector already spots PAM_RHOST and turns off is-local, so that much is fine; just need to get the rest to work
[14:08] <pitti> ok; I can commit to unbreaking stuff that silently assumes that any CK session is local and shouldn't
[14:08] <cjwatson> ogra: ok, so does LTSP want to pretend that the ssh session is equivalent to a local console?
[14:09] <ogra> hmm
[14:09] <pitti> cjwatson: I'll do that CK fix right now
[14:09] <cjwatson> pitti: great, thanks
[14:09] <ogra> cjwatson, sounds like the right thing to me ... and like how ts currently handled
[14:10] <ogra> i'd like to do some testing how that affects things like FUSA
[14:10] <ogra> (which we need to disable atm since CK support is required in gutsy for it already)
[14:14] <ogra> Riddell, seems nixternal did get that across right ... KdeEdu apps have no startup notification at all on gnome desktops atm with the missing entry in .desktop
[14:15] <ogra> *didnt
[14:15] <ogra> its not a matter of timeout values but about having it at all
[14:28] <Riddell> ogra: is this a recent thing?  is it specific to the classmate at all?  why can't it do something more intelligent that doesn't involve editing every .desktop file?
[14:28] <ogra> Riddell, not classmate specific
[14:28] <ogra> classmate is just wheer it really hurts
[14:29] <ogra> i never noticed it before though
[14:29] <ogra> but then i probably didnt look close enough
[14:29] <ogra> to me it looks like we could just omit X-KDE from StartupNotuify and it works on both desktops
[14:30] <ogra> cjwatson, does that model work for multiple logins as well ? upstream just noted each client should have its own seat
[14:38] <jdong> lookie that, new version of transmission
[14:45] <pitti> cjwatson: fixed CK uploaded, thanks again for spotting
[14:59] <slangasek> cjwatson: debconf 1.5.19> w00t, thanks
[15:03] <cjwatson> ogra: err, pass, would have to investigate
[15:04] <ogra> cjwatson, well, we can get mccann involved for details ... getting basic support is already a huge advantage
[15:05] <ogra> he asked that we look at gdm's xdmcp handling
[15:06] <ogra> that should gain us waht we want
[15:07] <cjwatson> I really don't want to c'n'p that code; would rather use the PAM module if at all possible
[15:07] <cjwatson> I've replied to your mail; if it seems a bit confused that's because I was investigating the software stack while writing it
[15:11] <ogra> cjwatson, hmm, i think the latter option is actually what the majority of users uses nowadays ....
[15:11] <ogra> ssh user@host sh -c 'DISPLAY="12.34.56.7:6.0 sudo time-admin'
[15:12] <ogra> i'll think about a solution on ltsp side for that one
[15:12] <cjwatson> consolekit needs to be passed DISPLAY; I think it uses its value to distinguish seats
[15:12] <ogra> (its not the default mode so i can tell them they needs some ldm-server-helper package or so on servers where they want to drop X encryption)
[15:12] <cjwatson> and, as I say, you'll need to remove sudo from that in hardy
[15:13] <ogra> i just copied from the mail :)
[15:13] <ogra> i understood that
[15:14] <cjwatson> one alternative might be to forward the DISPLAY environment variable using SendEnv/AcceptEnv
[15:14] <ogra> given the fact that thin client device access isnt handled by hal or dbus i think we can ignore it for now as long as gvfs still monitors /media for mounts
[15:15] <ogra> i can trigger something from the ommand ldm issues in that case as well ...
[15:15] <ogra> *command
[15:15] <ogra> in: ssh user@host sh -c 'DISPLAY="12.34.56.7:6.0 time-admin' everything between the quotes is configurable on my side
[15:16] <cjwatson> hmm, the PAM session is opened before setting environment variables in the child
[15:18] <ogra> i think thats what upstream meant about privilege separaation probs
[15:19] <cjwatson> that's the least of the problems, actually
[15:20] <cjwatson> actually, no, ignore that
[15:23] <cjwatson> ogra: from my reading of this, it'll need some small modifications to openssh certainly, but basically just to ensure that the proper environment variables are set before opening the PAM session
[15:23] <ogra> ok
[15:23] <ogra> if thats enough i'm fine
[15:24] <cjwatson> i.e. fish out the things that would be set for the tty and DISPLAY from the Session structure, and fill those into CKCON_blah
[15:24] <ogra> yep
[15:24] <ogra> lets do that then and let me test how my clients behave ... it moght already be enough
[15:24] <ogra> *might
[15:25] <ogra> we surely dont need to csre for local devices beyond gvfs having to monitor 7media
[15:25] <ogra> */media
[15:25] <cjwatson> ogra: at the moment, sshing in twice (with -o ControlPath=none) gives me two separate sessions on two separate seats
[15:26] <cjwatson> FYI
[15:26] <ogra> we use ControPath iirc
[15:26] <ogra> and the second ssh attaches to that
[15:26] <cjwatson> obviously if you multiplex then it's all one session
[15:26] <cjwatson> by definition
[15:26] <ogra> oh, you refer to my last qestion
[15:26] <cjwatson> logins from separate people won't (can't) multiplex that way so will be separate seats
[15:26] <cjwatson> was referring to:
[15:26] <cjwatson> 14:30 <ogra> cjwatson, does that model work for multiple logins as well ? upstream just noted each client should have its own seat
[15:26]  * ogra was thinking you look at ldm source :)
[15:27] <cjwatson> no, not yet
[15:27] <ogra> thats great, then even FUSA should work :)
[15:32]  * ogra is afk until the meeting ...
[15:55] <\sh> pitti, ia32-libs problem...If I see it right, there is no shlibs entry for libxml2 inside of ia32-libs.shlibs
[15:55] <pitti> ia32-libs has a shlibs??
[15:55] <\sh> pitti, it has, yes ;)
[15:55] <\sh>  /var/lib/dpkg/info/ia32-libs.shlibs
[15:56] <pitti> wow, wasn't aware of that
[15:56] <\sh> pitti, and everything seems fine...but not with libxml2...where I'm running now into problems with wine ;)
[15:56] <pitti> I certainly never bumped the shlibs fine, and TBH I think it's crack
[15:56] <pitti> because as it is it is unmaintainabe
[15:57] <ogra> slangasek, https://lists.ubuntu.com/archives/edubuntu-users/2008-January/003218.html would be good if we could hint the ltsp changes for alpha4 users in the release notes
[15:57] <\sh> pitti, looks like debian/rules in ia32-libs should do this automagically...
[15:57] <ogra> not that wordy though :)
[15:57] <pitti> it should be bumped autoamtically, not manually
[15:58] <slangasek> ogra: release notes draft are publically editable at https://wiki.ubuntu.com/HardyHeron/Alpha4, if you'd like to add something there
[15:58] <ogra> oki, thanks :)
[15:59] <pitti> \sh: but I still don't see what it's good for; it shouldn't be a build dependency
[15:59] <\sh> pitti, well, for wine on amd64 we need ia32-libs as b-d...
[16:00] <\sh> pitti, because some .so inside the wine universe are using those libs..e.g. msxml*.dll.so which links against libxml2 which can't be found now during shlibdeps call :)
[16:01] <\sh> pitti, everything is fine afaiks, but this ;)
[16:04] <ScottK> pitti: Do you know if openldap is going to be gotten off of libdb4.2?  If so, it looks reasonable to think about removing DB 4.2 entirely instead of just demoting it.
[16:04] <slangasek> it's not
[16:05] <slangasek> unfortunately, openldap + db4.6 gives performance issues
[16:05] <ScottK> OK, so trying to get Universe stuff off of it isn't likely to help then.  Thanks.
[16:05] <pitti> ScottK: unknown; I was told that something was fixed upstream in 4.6, but it's at least not in Debian yet
[16:06] <slangasek> ScottK: getting universe stuff off it is probably worthwhile anyway, so that people not using openldap only need one bdb version?
[16:06] <slangasek> pitti: hmm, is it fixed upstream?
[16:06] <pitti> slangasek: no idea; wasn't it you who mentioned this?
[16:06] <\sh> pitti, dpkg-shlibdeps: failure: no dependency information found for /usr/lib32/libxml2.so.2 (used by debian/wine/usr/lib32/wine/msxml3.dll.so).
[16:06] <\sh> argl
[16:06] <\sh> ia32-libs: shlib-missing-in-control-file libxml2 usr/lib32/libxml2.so.2.6.16
[16:07] <pitti> \sh: I'd rather drop ia32-libs' .shlibs file completely
[16:07] <slangasek> pitti: I think we may have misunderstood each other, then; I only said that it /needs/ to be fixed by bdb upstream, not that it has been
[16:07] <jwendell> when building gnome packages we pass to configure --with-gconf-schema-file-dir=/usr/share/gconf/schemas right?
[16:07] <ScottK> It's fewer than half a dozen packages in Universe, so it should be doable.
[16:07] <pitti> slangasek: ah
[16:08] <ScottK> 4.3 is less than 20...
[16:08] <\sh> pitti, and adding the deps manually into debian/control of the package needing the ia32 libs?
[16:08] <pitti> \sh: yes; it's just ia32-libs itself, after all
[16:09] <pitti> \sh: if you can fix ia32-libs' .shlibs and rules to not be on crack, that works, too, of course
[16:09] <\sh> pitti, sure...I just need to find out, what's the best to fix this damn problem :)
[16:09] <pitti> but I don't have time to do this today
[16:09] <pitti> \sh: I can tell you
[16:09] <\sh> pitti, well, it looks like that the problem is inside libxml2
[16:10] <pitti> \sh: throw away this ia32-libs abdomination and either make the required lib sources build a lib32* package, or make a more generic facility to depend on _i386 .debs on amd64
[16:10] <slangasek> ScottK: and pushing the changes to Debian, so everybody wins? :-)
[16:10] <ScottK> slangasek: Sure.
[16:11] <\sh> pitti, I wonder why we didn't do it by default...adding a lib32<insert name here> shouldn't be so hard at all
[16:11] <pitti> \sh: it's insanely painful to introduce multibuild into a lot of source packages
[16:11] <pitti> \sh: and even the lib32foo_amd64.deb is a nasty hack
[16:11] <pitti> it should just use the libfoo_i386.deb somehow
[16:12] <\sh> pitti, and what would make "depending on _i386.deb" happening? I really don't know how to tell dpkg to use it on amd64
[16:12] <pitti> \sh: neither apt nor dpkg support this ATM
[16:13] <\sh> pitti, so we should discuss it for hardy+n somehow...
[16:14] <pitti> \sh: I think this has been discussed several times already (jbailey, Mithrandir, doko?), but I don't know the current status
[16:14]  * \sh hates wine ,-9
[16:15] <slangasek> \sh: really, the solution is that you only have to use libfoo_i386.deb because you only need to *build* wine once, and can then install the 32-bit binaries directly on amd64; but now we're talking about multiarch :)
[16:15] <doko> ohh, who did implement it? ;-)
[16:16] <\sh> slangasek, as long there is no "real" solution for everyone (reading debian + ubuntu) I don't see any possibility to go away from the ia32-libs approach...
[16:16] <\sh> -ETOOMANYHACKSINVOLVED
[16:17] <\sh> the other problem I have now is why libxml2 doesn't provide a usable shlibs file ,)
[16:17] <slangasek> doko: some day...
[16:20]  * \sh shouls switch off the computer and should go and fetch some new clothes 
[16:22] <Riddell> pitti: I've got patches to allow new flash to work in konqueror, when you get a moment let me know if they're suitable for SRU https://bugs.edge.launchpad.net/ubuntu/+source/kdebase/+bug/184149
[16:22] <ubotu> Launchpad bug 184149 in kdebase "[hardy]xembed and flash support patches doesn't work for konqueror" [Medium,New]
[16:23] <pitti> Riddell: ooh, that means that we can finally update the flash downloader in stables and put an end to this insane bug thread?
[16:23] <Riddell> pitti: well, there's still Opera, I don't know if we care about it or not
[16:23] <Hobbsee> claim ignorance about -commercial.  problem solved.
[16:24] <pitti> well, it seems that much more people are whining about broken flash in stables than broken opera...
[16:24] <pitti> and if new flash plugin breaks opera, then it should be fixed in flash or opera; not much we can do about it, AFAICS?
[16:24] <Riddell> pitti: the kdebase patches for edgy and dapper are quite big, I had to backport the whole of nsplugin viewer
[16:40]  * \sh should go and have a drink somehow instead of understanding ia32-libs system to write and not to write shlibs from a to b
[16:41] <sistpoty|work> have some wine, \sh :P
[16:41] <\sh> sistpoty|work, lol
[16:55] <calc> cjwatson: i'm guessing that wouldn't work though since you already run ubiquity as root
[16:55] <cjwatson> calc: (from #ubuntu-platform) the problem is that EDD involves real-mode BIOS calls
[16:55] <cjwatson> calc: so there are two basic approaches that stand any chance at all
[16:55] <calc> cjwatson: hmm could that be done via a kernel module at boot time?
[16:55] <cjwatson> calc: one is to do it very early in kernel init
[16:55] <cjwatson> calc: the other is to do it from userspace with libx86
[16:55] <cjwatson> calc: the former was tried in the past, but has been known to wedge certain machines
[16:56] <cjwatson> calc: unfortunately this is in a stage where there is no space to add anything fancy like a blacklist; it's right at the start of kernel bringup
[16:56] <cjwatson> calc: so libx86 held out some hope of being able to do it in a more controlled fashion
[16:56] <cjwatson> calc: but not unless we can make it work :)
[16:56] <calc> ah :\
[16:57] <calc> EFI ftw ;-)
[16:57] <calc> well in all seriousness this may eventually become a dead issue (in several years) if companies start taking advantage of Vista SP1 support of EFI (at least i think it will support EFI in SP1)
[16:58] <Mithrandir> I wouldn't hold my breath.
[16:59] <calc> Mithrandir: yea
[16:59] <calc> it will be a while from now in any case
[17:00] <StevenK> People were talking about EFI by default "in several years" several years ago if I recall correctly. :-)
[17:01] <Mithrandir> given that the APIC specification is 11 years old and we are still seeing various bugs related to it..
[17:02] <StevenK> For an advanced interrupt controller, it's pretty dumb
[17:03] <elmo> EFI is the IPv6 of the hardware world
[17:04] <TheMuso> We'll only use EFI once windows uses nothing else. :p
[17:05] <calc> Mithrandir: APIC bugs are fun :) (had a very buggy APIC laptop a few years back)
[17:05] <calc> APIC bugs, ACPI bugs, bugs in everything :\
[17:06] <TheMuso> Hrm. I have a ksoftirqd process here, thats consuming 24% CPU usage. This is gutsy.
[17:06] <thom> elmo: that's pretty generous to EFI
[17:07] <calc> thom: apple and ia64 use it or so i hear
[17:07] <calc> but nobody else, heh
[17:07] <TheMuso> Apple uses 1.1 I think.
[17:07] <thom> call it the perl6 of the hardware world... :P
[17:08] <Mithrandir> it should be called efi6
[17:08] <Mithrandir> or bios6
[17:08] <\sh> doko, pitti: should the `sed` change in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456914 be attached, it helps to generating sane shlibs file for ia32-libs, leaving out the udeb: lines
[17:08] <ubotu> Debian bug 456914 in ia32-libs "ia32-libs: Missing shlibs entry for libxml2" [Serious,Open]
[17:09] <\sh> doko, pitti: which are not used anyways, afaik
[17:10] <doko> \sh: adding a shlibs file doesn't make sense for me. it's not used for development, you should just manually add a dependency on ia32-libs if needed
[17:11] <IntuitiveNipple> Can someone give me some advice on how to ensure, when patching a package, that a source file is removed? I've been looking at the new version .diff and I can't see any sign that the file is removed.
[17:12] <\sh> doko, k...let's workaround it :) thx
[17:12] <Mithrandir> IntuitiveNipple: rm it in the rules file
[17:12] <ScottK> IntuitiveNipple: I don't think you can actually remove a file.  You can just make it empty.  If you want to remove it, do it in debian/rules
[17:13] <IntuitiveNipple> Mithrandir: In the 'build' section? It's a Makefile that shouldn't be there.
[17:13] <IntuitiveNipple> ScottK: Yeah, it has to 'disappear' :)
[17:13] <Mithrandir> IntuitiveNipple: build or clean
[17:13] <IntuitiveNipple> Mithrandir: Ahh! clean would make sense!
[17:14] <IntuitiveNipple> Thanks!
[17:14] <IntuitiveNipple> I found the bug in mysql-query-browser that was causing the amd64 build to create 32-bit libraries and when run, cause SIGSEVs in gtksourcview
[17:15] <IntuitiveNipple> It's taking me longer to work out the repacking than finding the bug!
[17:15] <dmb> i strongly recommend we use uvesafb in hardy
[17:15] <Mithrandir> dmb: why?
[17:15] <dmb> it seems to work a lot better, especially with buggy bioses
[17:15] <dmb> i think its in the mainline kernel now
[17:16] <Mithrandir> a lot better than the VGA console?
[17:16] <dmb> well, its a framebuffer console
[17:16] <Mithrandir> yes, you have yet to say which problem you're trying to solve. :-)
[17:17] <dmb> in gutsy, vesafb is broken
[17:17] <Mithrandir> we're not using vesafb, though.
[17:18] <Mithrandir> unless you ask for it explicitly.
[17:18] <dmb> Mithrandir: well, i just mean being able to ask for uvesafb explicitly then
[17:18] <dmb> i think its in the mainline 2.16.23, so it will probably be in hardy anyway
[17:31] <evand> slangasek: so if I trigger a CD build tonight it will mess up your work, correct?
[17:31] <slangasek> no
[17:31] <evand> oh
[17:31] <evand> fantastic then
[17:31] <slangasek> I can still float earlier images as alpha candidates, or if the later ones fix key bugs you can tell me that and I'll push those instead :)
[17:32] <evand> noted
[17:38] <IntuitiveNipple> Can someone remind who should be subscribed to a bug report once a -proposed debdiff has been attached?
[17:39] <lool> Depends whether it's an update for main or universe
[17:39] <IntuitiveNipple> I suspect it's universe, since the maintainer is MOTU
[17:40] <IntuitiveNipple> I was just looking in the control file but I can't recall how to determine it :(
[17:41] <slangasek> by apt-cache policy; control is not authoritative
[17:42] <IntuitiveNipple> thanks
[17:42] <IntuitiveNipple> Yup, universe
[17:42] <Mithrandir> or rmadison -u ubuntu $pkg
[17:43] <IntuitiveNipple> Are you trying to confuse me?! :)
[17:43] <IntuitiveNipple> Ok, so who is it I subscribe for a universe bug-fix debdiff?
[17:43] <IntuitiveNipple> I've set it to gutsy-proposed, and am doing one for hardy too
[17:54] <geser> IntuitiveNipple: ubuntu-universe-sponsors
[17:55] <ogra> geser, i was planning to get the lib to main for tuxtype ...
[17:55] <IntuitiveNipple> geser: Oh! the Wike said motu-sru
[17:55] <IntuitiveNipple> s/Wike/Wiki/
[17:55] <ogra> (to answer your question from last night)
[17:56] <geser> IntuitiveNipple: it's for a SRU? then the wiki page is correct
[17:56] <ogra> i just didnt have the time to write a MIR yet
[17:56] <ScottK> IntuitiveNipple: Also for an SRU it has to be fixed in Hardy first if it's not.
[17:56] <geser> ogra: no problem, I was just checking the FTBFS page and saw that tuxtype is in depwait
[17:57] <ogra> on my radar ... just pushed down on my prio list
[17:57] <IntuitiveNipple> geser: Ok, good.
[17:57] <IntuitiveNipple> ScottK: Yes, I've published a debdiff for hardy too
[17:57] <IntuitiveNipple> Maybe, if you have a few moments, you could check I've done it correctly? bug #2382
[17:57] <ubotu> Launchpad bug 2382 in mysql-query-browser "mySQL Query Browser segfaults on AMD64" [High,Confirmed] https://launchpad.net/bugs/2382
[18:01] <glatzor> hello bryce
[18:31] <bryce> hi glatzor
[19:01] <LaserJock> I need some advice from an archive admin. I need to completely replace the packaging of a set of packages in Multiverse. Would filing removal bugs and the uploading the new packages to NEW be OK?
[19:04] <sistpoty|work> LaserJock: why not just upload your new packages?
[19:05] <LaserJock> well, because it's a real mess
[19:05] <LaserJock> the packages are changing names
[19:05] <sistpoty|work> as in source packages are changing names?
[19:05] <LaserJock> yes
[19:05] <LaserJock> and source package names mixing with binary package names
[19:06] <sistpoty|work> ah... I guess then there is no real other option, is there?
[19:06] <LaserJock> that was my guess, but I wasn't sure
[19:06]  * sistpoty|work isn't 100% sure either
[19:10] <exarkun> If I think the latest gcc package in hardy is misbehaving, who's the best person to tell?
[19:10] <ScottK> LaserJock: How does removal help?
[19:11] <LaserJock> ScottK: well, I was thinking it would clean the slate
[19:11] <ScottK> LaserJock: You'll still have to provide a transition for users that have the old ones installed.
[19:11] <LaserJock> yeah ... well I'm figuring that out later
[19:11] <ScottK> OK
[19:11] <LaserJock> with FF looming I just need to get the new packaging in
[19:13] <crimsun> exarkun: filing a bug report using Launchpad is recommended.
[19:14] <exarkun> crimsun: Okay, thanks!
[19:19] <exarkun> When I click the "Report a bug" button on bugs.launchpad.net/gcc/ I get a confusing page
[19:19] <IntuitiveNipple> Anyone here familiar with gtksourceview_marshal used in gtksourceview?
[19:21] <evand> exarkun: assuming you're using gcc-4.2: https://bugs.launchpad.net/ubuntu/+source/gcc-4.2/+filebug
[19:21] <exarkun> evand: thanks
[19:21] <evand> no problem
[19:32] <\sh> cjwatson, do you want to fix some things on your gpg-key? :)
[19:38] <IntuitiveNipple> Is there a way to get pbuilder to not delete the build image in the same way --save-after-exec works for execute?
[19:46] <pitti> cjwatson, slangasek: do you have an idea why restricted-manager, and now jockey aren't getting on the CDs? did we have a change in germinate or cdimage to silently drop stuff from restricted?
[19:47] <pitti> evand: also, can you please remind me again why r-m needed to go into restricted?
[19:47] <james_w> IntuitiveNipple: I don't think so. http://blog.madism.org/index.php/2006/06/27/93-pbuilder-custom-configurations might get you what you want
[19:47] <evand> pitti: gobuntu
[19:47] <pitti> evand: since jockey is not limited to restricted drivers any more, I'd like to see it in main, so that we can use it for free driver updates in the future, too
[19:47] <pitti> evand: right, I know that much, but why exactly?
[19:48] <evand> oh, because at the time it only managed restricted things, something that gobuntu wanted to avoid entirely
[19:48] <pitti> evand: at least jockey will remain completely silent (no notifications) and just don't display anything if you don't have restricted enabled
[19:48] <IntuitiveNipple> Thanks.. I'm just trying to use a kvm 32-bit image now - I need to trap the build autogenerated files
[19:48] <evand> fantastic, I see no problem with that going in main then
[19:48] <pitti> evand: it currently Recommends: linux-restricted-modules-...
[19:48] <pitti> evand: if I drop that to Suggests:, would that suffice?
[19:48] <evand> yes, I believe so
[19:49] <pitti> slangasek: ok for me to move jockey from restricted to main to circumvent whatever makes it disappear from the CDs?
[19:49] <pitti> evand: ok, thanks
[19:54] <slangasek> pitti: well, no problem for me
[20:05] <popey> I know this is a premature question, but does anyone have any clues as to the location of the next UDS?
[20:05] <popey> (for those of us that need to think about budgets)
[20:07] <james_w> how about popey's house?
[20:09] <popey> yay!
[20:09] <popey> might be a _bit_ of a squash
[20:10]  * popey imagines the wifes reaction
[20:10] <popey> "Few friends coming over.. nah, they're not staying long.. few days.. I'll get my coat"
[20:12] <slangasek> popey: "Europe" is next on the rotation; there's a tentative venue selected, but I hesitate to spread it too widely before it's confirmed
[20:13] <popey> is it? I thought Asia would be next
[20:13] <popey> ah well, Europe is easier for me, so if that comes off, that would be smashing.
[20:21] <cjwatson> LaserJock: it would be best not to remove the package, otherwise you can end up downgrading by accident which would be bad
[20:21] <cjwatson> \sh: tell me what's wrong with it
[20:22] <\sh> cjwatson, your subkey has some sigs on it and breaks some apps which are not ignoring them like gpg
[20:23] <cjwatson> feel free to refer me to documentation
[20:23] <\sh> cjwatson, we (misa from rpath.com and I) were tracking this problem down to your key, because something went wrong during my test of foresight linux .. http://lists.gnupg.org/pipermail/gnupg-devel/2008-January/024232.html is what gnupg guys are saying...
[20:24] <\sh> cjwatson, documentation about it: rfc4880 section 12.1 :)
[20:24] <LaserJock> cjwatson: ok, I was just afraid of having multiple source packages producing the same binaries, but it seems that's not a problem
[20:24] <StevenK> slangasek: Will you hate me if I upload a new libhildon?
[20:24] <\sh> cjwatson, no worries about it, just wanted to inform you
[20:25] <TheMuso> popey: I doubt that Asia will be considered any time soon.
[20:25] <cjwatson> I don't have a problem with removing them, but am not convinced that me doing so will have any effect on keyservers
[20:26] <cjwatson> \sh: ^--
[20:27] <cjwatson> LaserJock: nope, that's fine
[20:27] <cjwatson> (ish)
[20:27] <\sh> cjwatson, yepp...that's one true problem...but hopefully, most software will ignore those sigs
[20:27] <LaserJock> cjwatson: I think it should only be temporary, I'll file removal requests for the deprecated packages after the new packages are in
[20:28] <cjwatson> gpg says "gpg: moving a key signature to the correct place" six times when I run it and seems to have shuffled them over
[20:28] <cjwatson> \sh: I've sent it; that's all I can do
[20:29] <\sh> cjwatson, as I said, just FYI :)
[20:29] <cjwatson> \sh: doing a --recv-keys adds them straight back again
[20:29] <cjwatson> \sh: so if it's actually breaking something, somebody's going to have to make software more lenient, or get a keyserver admin to fix it on the keyservers; I am powerless
[20:30] <elmo> you can't do the latter
[20:30] <elmo> it needs to be the former
[20:30] <\sh> cjwatson, yepp...keyservers will preserve the sigs ... so nothing to worry about, we just stumbled upon it...and software is going to be fixed for rpath :)
[20:30] <elmo> the keyserver network is too distributed for fixing individual keys to be viable
[20:31] <cjwatson> elmo: I thought not, but they stood a better chance than the poor key owner ;)
[20:32] <cjwatson> so this means that every time I run gpg --edit-key --send-keys --recv-keys I'm going to grow six signatures on my key
[20:32] <cjwatson> which seems, er, suboptimal
[20:33] <slangasek> StevenK: is libhildon seeded on any CDs?
[20:33] <StevenK> slangasek: Nope
[20:33] <StevenK> slangasek: Just seeded by -mobile
[20:34] <slangasek> StevenK: then it's all you
[20:34] <StevenK> slangasek: Cool, I'll upload it.
[20:40] <\sh> cjwatson, I wonder why someone signed your subkey at all? :)
[20:41] <cjwatson> \sh: I didn't tell them to :-P
[20:44] <\sh> cjwatson, :)
[20:51] <james_w> StevenK: any thoughts on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452687 ? I realise it may just be pulling up a one off patch from the distant patch.
[20:51] <ubotu> Debian bug 452687 in bacula "bacula: Catalog backup fails: incorrect parameters format for make_catalog_backup" [Normal,Open]
[20:52] <james_w> distant past, sorry.
[21:32] <calc> how big is a full mirror of a.u.c?
[21:32]  * calc ponders buying a server to mirror the full archive
[21:32] <calc> or an extra hard drive to do it
[21:32] <jpatrick> calc: more than 120GB I think
[21:33] <calc> jpatrick: ah thats not too bad
[21:33] <jpatrick> calc: last time I read what archive.*'s size was
[21:34] <elmo> bigger
[21:34] <calc> hmm mirror page says 220GB
[21:35]  * calc might need an extra hard drive
[21:35] <elmo> that's out of date now
[21:35] <elmo> it's closer to 250GB
[21:35] <elmo> roll on edgy being obsolete
[21:36] <Nafallo> when edgy becomes obsolete hardy should be stable though... and there will be another release cycle ;-)
[21:36] <calc> ah ok
[21:36] <calc> phasing out releases won't reduce the amount required...
[21:36] <calc> Nafallo: it will just keep growing :)
[21:36] <Nafallo> calc: yea, I know.
[21:37] <calc> hmm i should get a 750gb from fry's when i see one on sale
[21:37] <Nafallo> calc: soon two LTSes in the archive to start off with :-)
[21:37] <calc> Nafallo: yea
[21:38]  * calc is lucky to have 3 fry's within an hour of where he lives
[21:58] <LaserJock> calc: 3 Fry's?
[21:58] <LaserJock> that's pretty good. I've got 2 within 2hrs
[22:02] <articpenguin> how can i request for an updated package
[22:04] <calc> LaserJock: at least iirc we have 3 in houston
[22:04] <calc> LaserJock: 1 about 10m away
[22:04] <calc> LaserJock: of course Houston is pretty big there is a much higher concentration of them in the valley
[22:05] <LaserJock> articpenguin: file a bug, make it "wishlist", and tag it "upgrade", I believe
[22:06] <LaserJock> calc: ah, I've got 2 in Sacramento
[23:16] <IntuitiveNipple> Is there a standard method in Makefiles to switch between building shared libraries and static (I'm trying to cause AR to put some .o files into a .a rather than creating .so) ?