[12:08] <keescook> mjg59: okay.  yeah, figured it was going to be vga16, but thought I'd ask anyway.  cool.
[12:08] <Kamion> pitti: you have about five minutes before I just upload anyway and go to sleep, BTW :)
[12:08] <mjg59> keescook: But thanks for taking a look!
[12:09] <Amaranth> Oh, that explains the need for all the new usplash themes to support the old format
[12:09] <tfheen> Amaranth: they should have all along.
[12:11] <tfheen> mjg59: the artwork shipped in the usplash package in dapper was the ubuntu artwork, wasn't it?
[12:11] <pitti> Kamion: install is at 22gnome_panel_data script
[12:12] <tfheen> BenC: you sparc-utils FTBFS-ed
[12:12] <tfheen> BenC: https://launchpad.net/+builds/+build/256146
[12:12] <BenC> tfheen: Hmm, I'll tak a look
[12:13] <mjg59> tfheen: Yes
[12:13] <Kamion> pitti: oh, worth waiting
[12:14] <pitti> Kamion: ah, the skip button for langpack download is nice :)
[12:16] <Kamion> that was an option designed for us, yes :-)
[12:18] <pitti> ah, in check-kernels now
[12:18] <pitti> Kamion: yay, it's removing all the powerpc64-smp related packages now
[12:19] <Kamion> excellent; let's see if it works
[12:20] <Kamion> just fixing a bit of KDE frontend desync I noticed
[12:20] <pitti> I was a bit nervous when I saw update-initramfs before puring the kernel; I hope it'll be called again
[12:20] <pitti> Kamion: it's purging langpacks now, and /target/boot has no initrd
[12:20] <Kamion> no, but does it need to be?
[12:20] <Kamion> oh, hmmmm
[12:21] <pitti> ok, ubiquity finished
[12:22] <Kamion> pitti: does 'chroot /target update-initramfs -u' now fix it?
[12:22] <pitti> Kamion: shall I save the log for you?
[12:22] <Kamion> pitti: may as well, yes please
[12:24] <pitti> Kamion: after update-initramfs -s I have an initrd again, contents looks fine
[12:25] <pitti> Kamion: http://people.ubuntu.com/~pitti/tmp/syslog
[12:25] <pitti> Kamion: I do an actual boot test now
[12:26] <Kamion> -s?
[12:26] <pitti> erm, -u
[12:26] <Kamion> Oct 16 22:18:55 ubuntu ubiquity: rmdir:
[12:26] <Kamion> Oct 16 22:18:55 ubuntu ubiquity: /lib/modules/2.6.17-10-powerpc64-smp
[12:26] <Kamion> Oct 16 22:18:55 ubuntu ubiquity: : Directory not empty
[12:26] <Kamion> pitti: what's in there?
[12:27] <pitti> darn, too late; I have to reboot to find out
[12:27] <pitti> urgh, 'Unable to mount root fs on unknown-block(0,0)
[12:29] <pitti> . o O { We are bug. Resistance is futile. }
[12:34] <pitti> Kamion: the only thing left in the ppc64 modules dir is the 'build' symlink to linux-headers-2.6.17-powerpc64-smp, which is apparently still installed
[12:34] <Kamion> ah, ok, I'll ignore that
[12:35] <Kamion> I'm afraid this is going to be slightly more invasive to fix
[12:35] <pitti> I just wonder why it doesn't boot at all
[12:35] <ajmitch> pitti: heard that the nvidia driver has a root exploit available?
[12:35] <pitti> Kamion: I bind-mounted /dev, mounted /proc in the chroot and called ybin
[12:35] <Kamion> I had to shuffle a chunk of code around, because you have to create the kernel symlink after creating the initramfs
[12:35] <Kamion> pitti: I bet the initrd symlink isn't there
[12:35] <Kamion> /boot/initrd.img
[12:35] <pitti> Kamion: I get 'Failed to initialize HFS working directories: No such file or directory'
[12:36] <Kamion> check for /boot/vmlinux while you're there
[12:36] <pitti> Kamion: and 'ybin: /dev/hda2 appears to have never had a bootstrap installed, please run kmkofboot'
[12:36] <Kamion> sounds like yaboot-installer gave up
[12:36] <pitti> Kamion: indeed, vmlinuz symlink is there
[12:36] <pitti> Kamion: but initrd symlink isn't
[12:36] <pitti> Kamion: it might have given up because there was no initrd at all?
[12:36] <Kamion> no, mkofboot definitely worked
[12:37] <Kamion> according to your syslog
[12:37] <Kamion> Oct 16 22:19:12 ubuntu yaboot-installer: mkofboot: Blessing /dev/hda2 with Holy Penguin Pee...
[12:37] <Kamion> Oct 16 22:19:13 ubuntu yaboot-installer: mkofboot: Updating OpenFirmware boot-device variable in nvram...
[12:37] <Kamion> Oct 16 22:19:15 ubuntu yaboot-installer: mkofboot: Installation complete.
[12:37] <Kamion> pitti: failed to initialize HFS blah> check $HOME
[12:37] <Kamion> IIRC the HFS tools want to fiddle with $HOME/.hcwd
[12:37] <pitti> heh, indeed
[12:38] <pitti> that did the trick
[12:40] <pitti> still doesn't boot (same error), but oh well, let's do that tomorrow
[12:40] <pitti> Kamion: let's get some sleep, shall we/
[12:41] <pitti> ?
[12:41] <Kamion> I need to upload something of this tonight
[12:41] <ajmitch> pitti: anyway to mark an existing bug as security-related?
[12:41] <pitti> ajmitch: sure, there's an entry for that in the menu ('Visibility/Security')
[12:41] <ajmitch> aha, missed it, thanks :)
[12:41] <pitti> ajmitch: nvidia root> no, can you please mail any pointer/info? thanks!
[12:42] <ajmitch> seems that bug 46034 is a bit more serious
[12:42] <Ubugtu> Malone bug 46034 in Ubuntu "Page crashes X" [High,Confirmed]  http://launchpad.net/bugs/46034
[12:42] <ajmitch> attaching the info to that
[12:42] <mjg59> pitti: http://download2.rapid7.com/r7-0025/
[12:42] <pitti> ah, thanks
[12:42] <mjg59> (Summary: We're screwed)
[12:42] <ajmitch> more or less
[12:43] <pitti> phun
[12:44] <mjg59> Has anyone actually tested the exploit?
[12:44] <ajmitch> not that brave
[12:44] <Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/ubiquity-testing.diff updated
[12:45] <Kamion> I had to shovel the symlink fixing code around, and haven't tested this because my vmware setup is in the next room and I honestly don't want to get out of bed again
[12:47] <Kamion> tfheen: I know this is a bad time for this sort of request, but can I upload it and fix up anything that goes wrong tomorrow if necessary? I've been as careful as I can, and *something* needs to be done about this bug anyway or we have to drop *-desktop-powerpc.iso
[12:47] <pitti> keescook: gcc -I/usr/include/freetype2/ -o nv_exploit nv_exploit.c  -lfreetype -lX11 -lXft -lXt builds the exploit, but it wants two addresses
[12:47] <tfheen> Kamion: yeah, skimming it now.
[12:47] <Kamion> the s/remove_kernels/self.remove_kernels/ stuff is an unnecessary remnant; removing that now
[12:47] <keescook> pitti: yeah, reading through it now.
[12:48] <tfheen> Kamion: feel free to upload, my brain is in usplash mode right now so python looks weird.
[12:48] <Kamion> I think we now have to run the kernel-symlink stuff for all architectures because we removed the initrd
[12:48] <Kamion> (from the squashfs)
[12:48] <pitti> keescook: have fun. I think I really need to sleep now, most parts of my brain apparently are..
[12:48] <Kamion> although I suspect Adam only removed the actual image, not the symlink ...
[12:48] <keescook> pitti: hehe.  oka, good night!
[12:48] <Fujitsu> mjg59, that is seriously bad.
[12:49] <Kamion> tfheen: sorry about this :-/
[12:49] <ajmitch> night pitti 
[12:49] <pitti> Kamion: ok, if you'll upload that, it should catch tomorrow's dailies; I'll do a full test again in the morning as soon as the CDs are available
[12:49] <Kamion> pitti: thanks a lot, I appreciate it
[12:50] <Kamion> I'll get i386 tested as soon as I wake up tomorrow
[12:50] <tfheen> Kamion: dude, get some sleep.
[12:50] <tfheen> Kamion: no worries about this; we'll fix it tomorrow.
[12:50] <sivang> night pitti 
[12:50] <pitti> tfheen: listen to your own advice, btw :)
[12:50] <Kamion> http://people.ubuntu.com/~cjwatson/tmp/ubiquity-1.2.3.diff <- final patch
[12:51] <tfheen> pitti: I have three uploads left; I want usplash on amd64 to work tomorrow morning.
[12:51] <pitti> tfheen: good luck!
[12:54] <tfheen> mjg59: it seems like the "cannot allocate memory" (when using vga16fb) in the initramfs might be because the fb isn't ready yet at that point.
[12:54] <mjg59> Oh.
[12:54] <mjg59> I wonder if that's why the sleep was there.
[12:58] <Kamion> tfheen: bug 66424 is in main. ok to sync?
[12:58] <Ubugtu> Malone bug 66424 in elementtree "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66424
[12:59] <Kamion> tfheen: also, did you reach agreement on bug 65963?
[12:59] <Ubugtu> Malone bug 65963 in flex "sync request" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65963
[12:59] <tfheen> Kamion: ok; please sync elementtree.
[12:59] <tfheen> Kamion: doko_ said he needed to investigate two build failures (or possible build failures) in main.
[01:00] <Kamion> ok
[01:01] <tfheen> so I'm not entirely sure what happens there.
[01:02] <Kamion> done the other two targetted sync requests
[01:02] <tfheen> which one was the last one?
[01:03] <Kamion> python-goopy (universe)
[01:03] <tfheen> oh, ok.
[01:03] <tfheen> sleep tight
[01:06] <sivang> so user-mode-linux is building? there are lots of stuff in universe with unmetdeps waiting for it
[01:08] <tfheen> mjg59: hmm, same error with a sleep in there.
[01:08] <mjg59> tfheen: Fun
[01:08] <sivang> hmm, no I'm getting tired then
[01:08] <tfheen> mjg59: I'm going to look at why.  It might be I just suck.
[01:16] <shawarma> sivang: user-mode-linux? Where do you see that?
[01:19] <sivang> shawarma: it's too late :-)
[01:19] <sivang> shawarma: see my comments to the bug
[01:20] <shawarma> sivang: -> #ubuntu-motu
[01:26] <tfheen> mjg59: hmm, no, it's the config file which claims I want 1280x1024.  This doesn't work with VGA, for obvious reasons.
[01:26] <TheMuso> c/
[01:26] <mjg59> tfheen: Ha.
[01:26] <mjg59> tfheen: Ok. The bogl code should try the change resolution ioctl
[01:26] <tfheen> mjg59: rm -f /etc/usplash.conf if arch is != i386
[01:26] <mjg59> tfheen: And then if that fails, it should just return whatever resolution it has, rather than returning an error
[01:26] <mjg59> tfheen: Please don't
[01:27] <mjg59> Otherwise we'll have to regenerate it on upgrade when we finally get this working properly
[01:27] <tfheen> mjg59: that won't work either; the artwork picked will be the wrong one, wont it?
[01:27] <mjg59> tfheen: The artwork picking is done afterwards, isn't it?
[01:27] <mjg59> Or...
[01:27] <mjg59> Argle.
[01:27] <sivang> night all
[01:27] <mjg59> That's how it was supposed to work. It's possible that it no longer does.
[01:28] <tfheen> mjg59: it seems to be able to DTRT.
[01:28] <mjg59> Ah, cool
[01:29] <tfheen> except it does usplash_set_resolution ; usplash_init;
[01:35] <jdong> just peachy :)
[01:35] <pygi> :P
[01:36] <_ion> Yeah.
[01:36] <bddebian> Heya folks
[01:40] <tfheen> mjg59: ok, how about I make the initramfs script not pass xres and yres if DPKG_ARCH is amd64?  That's easy enough to reverse?
[01:41] <mjg59> Yeah, that sounds good
[01:44] <BenC> tfheen: New sparc-utils uploaded
[01:44] <tfheen> BenC: and this one'll build, I hope.
[01:44] <tfheen> infinity: please accept sparc-utils upload from BenC once you're awake.
[01:44] <BenC> yep, I fixed sparc32, but didn't know that audioctl was broken
[01:45] <BenC> I had to disable audioctl, because it is no longer supported by the kernel
[01:45] <tfheen> ok
[01:46] <tfheen> mjg59: It. Worked.
[01:47] <tfheen> (hooray)
[02:04] <BenC> http://it.slashdot.org/article.pl?sid=06/10/16/2038253&from=rss
[02:04] <BenC> Anyone know what we are doing about that for edgy release?
[02:05] <BenC> "Root Exploit For NVIDIA Closed-Source Linux Driver"
[02:05] <ajmitch> BenC: dunno, I told pitti about it earlier
[02:06] <zul> is there a fix yet besides running the nvidia binaries?
[02:06] <elmo> zul: or not running them even
[02:06] <elmo> ;-)
[02:06] <zul> that works
[02:06] <BenC> there is a 1.0-9625
[02:06] <ajmitch> zul: I don't know if the 9726 binaries have been tested
[02:06] <BenC> that supposedly fixed it a month ago
[02:07] <ajmitch> not sure if they're still beta or not
[02:07] <BenC> it is beta
[02:07] <ajmitch> they released 9625 as beta, 9626 didn't appear on their beta page iirc
[02:08] <ajmitch> either way there's still a lot of problems reported with the 9xxx drivers still
[02:09] <HrdwrBoB> given the choice between a lot of problems
[02:09] <HrdwrBoB> and root exploit
[02:10] <BenC> lesser of two evils
[02:10] <BenC> and I can't decide which one is lesser :)
[02:10] <HrdwrBoB> heh
[02:11] <ajmitch> with 9626 you'd make all the beryl-using junkies happy :)
[02:11] <ajmitch> not sure if that's a good thing or not..
[02:12] <Fujitsu> THe solution is simple. Ban binary drivers in Ubuntu.
[02:12] <HrdwrBoB> ok
[02:12] <Fujitsu> Hm. I haven't been kicked for trolling yet?
[02:12] <HrdwrBoB> and now for something useful and contstructive
[02:12] <HrdwrBoB> constructive
[02:15] <_ion> Well, it's easy to modify l-r-m to install 'nvidia-beta' just like it installs 'nvidia-legacy' in addition to 'nvidia'. :-)
[02:57] <tfheen> good night, everybody.
[02:58] <zul> ] night tfheen 
[04:04] <infinity> zul_: You around?
[06:03] <stub> Launchpad will be going down for about an hour in around 30 minutes time. Longer than usual downtime this week due to some data migration that needs doing.
[06:03] <infinity> stub: Thanks for the warning.
[06:04] <infinity> stub: BTW, from here until release, we'd probably appreciate something more like 24 hours' notice. :)
[06:04] <infinity> stub: (But today, this downtime should be fine)
[06:05] <stub> Hopefully this will be the only significant downtime between now and then anyway. Need to copy a load of translations to edgy, and after that it should be clear sailing.
[06:05] <infinity> Famous last words. :)
[06:06] <imbrandon> is that kinda like the redneck saying "hey yall watch this ......" ( just teasin )
[06:08] <infinity> Okay, this is sad.  I've just spent the last 4 hours dealing with a backlog of requests made while I was asleep, and NOW I can get to work on the things I had planned for the day.
[06:08] <infinity> Oi.
[06:09] <imbrandon> infinity, heh
[06:10] <ajmitch> infinity: any universe uploads for me to pick over?
[06:11] <infinity> ajmitch: Here...
[06:11] <infinity>   109863 | S- | ichthux-default-sett | 1:6.10-2             | 6 hours 30 minutes
[06:11] <infinity>          | * ichthux-default-settings/1:6.10-2 Component: universe Section: kde
[06:12] <infinity>   109857 | S- | mythtv               | 0.20-0.2ubuntu2      | seven hours
[06:12] <infinity>          | * mythtv/0.20-0.2ubuntu2 Component: multiverse Section: graphics
[06:12] <infinity>   109856 | S- | projectmanager.app   | 0.1.2-1ubuntu1       | seven hours
[06:12] <infinity>          | * projectmanager.app/0.1.2-1ubuntu1 Component: universe Section: devel
[06:12] <infinity>   109855 | S- | quixote              | 2.4-4ubuntu1         | seven hours
[06:12] <infinity>          | * quixote/2.4-4ubuntu1 Component: universe Section: web
[06:12] <infinity>   109854 | S- | python-pyrss2gen     | 1.0.0-2ubuntu1       | 7 hours 10 minutes
[06:12] <infinity>          | * python-pyrss2gen/1.0.0-2ubuntu1 Component: universe Section: python
[06:12] <infinity>   109853 | S- | python-omniorb2      | 2.6-3.1ubuntu2       | 7 hours 10 minutes
[06:12] <infinity>          | * python-omniorb2/2.6-3.1ubuntu2 Component: universe Section: devel
[06:12] <infinity> Some of the changelogs are less than informative..
[06:13] <ajmitch> not even listing bugs closed, I guess?
[06:13] <infinity> Some do...
[06:13] <infinity>  python-omniorb2 (2.6-3.1ubuntu2) edgy; urgency=low
[06:13] <infinity>  .
[06:13] <infinity>    * debian/omniidl4-python.files: fix file list (Closes: Malone #65411).
[06:13] <Ubugtu> Malone bug 65411 in python-omniorb2 "[UNMETDEPS]  python-omniorb2 has unmet dependencies" [Undecided,Fix committed]  http://launchpad.net/bugs/65411
[06:13] <infinity>  python-pyrss2gen (1.0.0-2ubuntu1) edgy; urgency=low
[06:13] <infinity>  .
[06:13] <infinity>    * debian/control: fix build-depends to fix FTBFS
[06:13] <infinity>    * Closes: Malone #65405
[06:13] <Ubugtu> Malone bug 65405 in python-pyrss2gen "[UNMETDEPS]  python-pyrss2gen has unmet dependencies" [Undecided,Fix committed]  http://launchpad.net/bugs/65405
[06:13] <infinity> I'm guessing those two are approved?
[06:13] <ajmitch> yep
[06:13] <infinity>  quixote (2.4-4ubuntu1) edgy; urgency=low
[06:13] <infinity>  .
[06:13] <infinity>    * debian/patches/01-ptl_compile.py.dpatch: fix path to python
[06:13] <infinity>      (Closes: Malone #65347)
[06:13] <infinity>    * rename debian/quixote-doc.* to debian/python-quixote-doc.* to get the
[06:13] <ajmitch> crimsun probably did the mythtv fix as well
[06:14] <Ubugtu> Malone bug 65347 in quixote "[UNMETDEPS]  quixote has unmet dependencies" [Undecided,Fix committed]  http://launchpad.net/bugs/65347
[06:14] <infinity>      documentation included into the python-quixote-doc package
[06:14] <infinity>  mythtv (0.20-0.2ubuntu2) edgy; urgency=low
[06:14] <infinity>  .
[06:14] <infinity>    * Import changeset #11365 from mythtv SVN to resolve mythreplex bug
[06:14] <infinity>      (Closes Ubuntu: #65790)
[06:14] <infinity>    * Update maintainer to be MOTU-Media
[06:14] <infinity> Changed-By: Mario Limonciello <superm1@ubuntu.com>
[06:14] <ajmitch> ok, apprve those two, I saw them discussing the mythtv bug earlier
[06:15] <infinity>  projectmanager.app (0.1.2-1ubuntu1) edgy; urgency=low
[06:15] <infinity>  .
[06:15] <infinity>    * Modified build deps to reflect new libgnustep packages.
[06:15] <infinity> That one's the "not so informative" one.
[06:15] <infinity> I can grab a debdiff for you, or just reject it.
[06:15] <ajmitch> yeah, i know the context, it should be approved
[06:15] <ajmitch> there are about 50 or so gnustep packages that had to be rebuilt/fixed
[06:15] <infinity> Ahh, kay.
[06:16] <infinity>  ichthux-default-settings (1:6.10-2) edgy; urgency=low
[06:16] <infinity>  .
[06:16] <infinity>    * New KDM/Ksplash themes
[06:16] <infinity>    * New wallpaper
[06:16] <infinity>    * New usplash theme
[06:16] <infinity>    * New kmenu sidebar
[06:16] <infinity>    * Add Konqueror background
[06:16] <infinity>    * Add usplash-dev to Build-Depends to build new usplash
[06:16] <mjg59> infinity: Done
[06:16] <infinity> mjg59: Danke.
[06:16] <infinity> mjg59: Tested this time, perchance? :)
[06:16] <mjg59> Tested lsat time
[06:16] <ajmitch> ichthux-default-settings should be fine as well, just another derivative
[06:16] <mjg59> But not in a pbuild
[06:16] <infinity> mjg59: Ahh.
[06:17] <infinity> ajmitch: Alright, that clears your queue.  Congrats.
[06:17] <ajmitch> thanks
[06:17] <ajmitch> I'll try & fill it up again tonight
[06:17] <infinity> :)
[06:17] <infinity> For feisty, I'll make sure some MOTU folk can actually see into the queue.
[06:17] <infinity> Should make this slightly less painful.
[06:17] <imbrandon> yea
[06:17] <infinity> I do think a universe freeze does make sense in the last 1/2-week stretch, though.
[06:18] <Chipzz> feisty = edgy + 1?
[06:18] <infinity> Encouraging random buggy uploads for universe isn't any better than for main.
[06:18] <ajmitch> Chipzz: apparantly, we're still waiting on the official announcement
[06:19] <ajmitch> the problem is that all uploads to universe have slowed down, and people are afraid to make any fixes
[06:19] <ajmitch> we just have to get them into line
[06:19] <imbrandon> maybe just a UVF 1 month out and freeze at RC for +1
[06:20] <ajmitch> could work, you can discuss it in a few weeks
[06:20] <imbrandon> yea
[06:20] <ajmitch> hm
[06:21] <ajmitch> tempting to grab a flight to MV
[06:21] <imbrandon> ajmitch, DO IT !!
[06:22] <imbrandon> would be nice to have you there for the stuff whiprush was speaking about too
[06:22] <ajmitch> imbrandon: PAY ME! :)
[06:22] <imbrandon> ajmitch, i wish i could , i would in a second
[06:25] <infinity> BenC: Where did debian/copyright (and a mess of other things) go in that last sparc-utils upload?
[06:25] <infinity> BenC: Care to debdiff and tell me WTF? :)
[06:26] <infinity> BenC: Oh, you dropped audioctl COMPLETELY.  I see.
[06:26] <infinity> BenC: checking over the diff for sanity, then. :)
[06:26] <infinity> BenC: approved.
[06:47] <ajmitch> infinity: reject libsdl-ruby_1.1.0-1ubuntu1.dsc, please - versioning is wrong :)
[06:49] <infinity> ajmitch: Err, what libsdl-ruby?
[06:49] <ajmitch> one that was just uploaded, should have been 1.1.0-1build1
[06:49] <infinity> Oh, won't be in the queue for another 30 seconds, then. :)
[06:49] <infinity> (Every 5 minutes)
[06:49] <ajmitch> maybe it hasn't got through to the queue
[06:49] <ajmitch> right :)
[06:49] <ajmitch> I hope that -1build1 doesn't get rejected
[06:49] <ajmitch> since that's the right version
[06:50] <infinity> You did both in the same run?
[06:50] <ajmitch> not me
[06:50] <infinity> You'll probably have to re-upload -1build1, since it's the lower version number.
[06:50] <ajmitch> but yes, they were both uploaded in the same 5 min period
[06:50] <ajmitch> ok, thanks
[06:50] <infinity> Oh, no, they both landed in unapproved.  Of course.
[06:50] <infinity> Since the version checks aren't done until I accept.
[06:50] <ajmitch> ah, useful
[06:50] <infinity> It's all good.  Rjecting ubuntu, accepting build.  Yes?
[06:51] <ajmitch> yes
[06:51] <infinity> Done.
[06:51] <ajmitch> thanks
[06:58] <stub> Launchpad is going down in 15 minutes for a code update and data migration work. Estimated downtime is 1 hour but will hopefully be significantly less.
[07:04] <ernstp> is usplash meant to work on AMD64 in edgy?
[07:06] <ernstp> there's some updates today that hints that the developers want splash on AMD64 too?
[07:07] <keescook> ernstp: there were problems with uspalsh on amd64 at higher resolutions
[07:07] <infinity> ernstp: Once today's updates build and hit the archive, it's meant to work, yes.
[07:07] <infinity> keescook: s/were/are/
[07:08] <infinity> keescook: We're forcing usplash on amd64 to bogl-mode with vga16fb.
[07:08] <infinity> (As of today)
[07:08] <ernstp> hmm... it didn't work at any resolution here
[07:08] <ernstp> eh, that's great! :-)
[07:08] <infinity> ernstp: Yes, it won't work for beans until today's stuff hits the mirrors.
[07:08] <ernstp> right. I've been a bit confused if it was supposed to work or not, didn't find any bugs on the matter either
[07:34] <caleb-> Hello, edgy uses dash as /bin/sh, and it break *MANY* old scripts. Can it be fixed before edgy's official release?
[07:35] <fabbione> caleb-: no, you need to fix the scripts to either use /bin/bash or make them *sh* compliant
[07:36] <caleb-> fabbione: OK. I see. Thank you. :-)
[07:40] <mnepton> or symlink bash to dash
[07:40] <Treenaks> mnepton: but that will slow down your system boot
[07:40] <mnepton> which is The Big F-ing Hammer approach
[07:41] <mnepton> Treenaks: which is why i don't tend to use The Big F-ing Hammer approach ;)
[08:09] <pitti> Good morning
[08:10] <siretart> morning Pitti!
[08:12] <Huahua> Good morning, pitti 
[08:12] <Fujitsu> I wouldn't say it was good, but morning!
[08:14] <pitti> hi siretart 
[08:14] <pitti> moin Huahua 
[08:18] <mnepton> moin pittilicious
[08:39] <Chandan> Hi
[08:40] <Chandan> I want to know how ubuntu is adding its own version for debian upstream .. like gdm 2.8.0-0ubuntu1 ... XubuntuY form
[08:40] <Burgundavia> Chandan: yep, what do you need to know about it?
[08:41] <Chandan> I am working on building a debian based distro ... I am modifying some gnome related packages ..and I want to add my own version 
[08:41] <Chandan> I have done taht adding same as ubuntu .. like gdm2.8.0 to gdm-2.8.0-0boss1
[08:42] <Chandan> Burgundavia, I want to on what basis Ubuntu is adding its own version .. Is Ubuntu is adding for all 15000 packagexs of debian
[08:43] <Burgundavia> Chandan: only those changed in Ubuntu
[08:43] <Chandan> Burgundavia, What changes that has been done .. 
[08:43] <Burgundavia> any time the source package gets changed in Ubuntu, we add the -XubuntuY stuff
[08:43] <Chandan> Burgundavia, I have changes some debian images to our distro boss images .. and in some packages I ahve modified some script 
[08:44] <Chandan> Burgundavia, If we are adding our version only to the packages we are mdifying  wont it give the depenency problem while isntalling other packages 
[08:45] <Chandan> Burgundavia, Wont it ask for the Debian upstream version 
[08:45] <Chandan> Burgundavia, I am facing that problem .. I am trying to install one package ..But it is showing that the pacakge depends on debian sarge version ,but boss version is installed on the system
[08:46] <Burgundavia> Chandan: that is beyond me. You would need to ask one of the more experienced people around. I would ask in -motu, as they are better equipped to answer your question
[08:46] <Chandan> Burgundavia, ok ..HOw can interact with motu
[08:46] <Burgundavia> their channel is #ubuntu-motu
[08:48] <AnAnt> in which package did Dapper put it's usplash image?
[08:58] <Kagou> morning
[09:00] <pitti> fabbione: yup, shadow seems to be a fallout from new gettext 0.15
[09:01] <fabbione> WOOOO
[09:01] <infinity> pitti: I'm not sure I wanted to hear that. :/
[09:01] <pitti> seems to be quite common, there's a lot of Debian ML activity about that
[09:02] <pitti> I fixed the first failure and now fight with the second
[09:02] <infinity> Does this mean I get to do another re-run on i386 to catch all of these? :/
[09:02] <pitti> infinity: preferably
[09:02] <pitti> but after all those uploads, another test would be nice anyway
[09:02] <fabbione> infinity: well i am running main here already
[09:02] <fabbione> infinity: that should be enough to catch them
[09:03] <fabbione> infinity: directfb is still FTBFS on sparc 
[09:03] <fabbione> ah hold on
[09:04] <fabbione> never mind
[09:04] <fabbione> skip that
[09:04] <infinity> fabbione: Are you doing arch:all as well?  Some arch"all stuff uses autotools and could explode on this.
[09:04] <fabbione> infinity: i think i am...
[09:04] <fabbione> $sbuild_args .= ' --arch-all' if ($arch eq "sparc");
[09:05] <infinity> Kay.
[09:05] <fabbione> well it's still worth to give another run on x86 tho
[09:05] <fabbione> or ppc for the matter
[09:05] <infinity> Your machine is faster than terranova, so I'm happy with that.
[09:05] <infinity> But I can get elmo to re-import for i386/amd64/powerpc.
[09:05] <infinity> Which might not be a bad plan.
[09:13] <pitti> yay, shadow builds
[09:15] <mdke_> I need to go through a document and replace '<!ENTITY language "C">' with '<!ENTITY language "$i">', but for some reason sed won't let me, saying "bash: !ENTITY: event not found". Does anyone know what the problem is?
[09:16] <infinity> fabbione: perl suite passes on sejong.  You may have a Niagara-specific bug there, or random bogons.
[09:16] <fabbione> infinity: so it seems.. yes
[09:16] <infinity> mdke_: Quoting.
[09:17] <infinity> mdke_: sed -i -e 's/<!ENTITY language "C">/<!ENTITY language "$i">' file
[09:17] <infinity> mdke_: (works for me anyway)
[09:17] <infinity> mdke_: Unless you wanted your shell to expand "$i"... I assumed it was a literal string. :)
[09:18] <mdke_> infinity: yeah, I want it to expand $i.
[09:19] <tfheen> mdke_: sed -i -e 's/<!ENTITY language "C">/<!ENTITY language '"$i"'>' file should work then
[09:19] <mdke_> aha. That quoting thing is weird.
[09:19] <infinity> But with another /
[09:20] <Kamion> mdke_: you're running into bash's history expansion
[09:20] <infinity> And some backslashes.
[09:20] <mdke_> Kamion: you sort of explained it yesterday but I didn't get it 
[09:20] <Kamion> ! is special unless escaped by \ or single quotes; double quotes aren't enough
[09:20] <infinity> 's/<!ENTITY language "C">/<!ENTITY language '\"$i\"'>/'
[09:21] <mdke_> infinity: ok, trying!
[09:21] <Kamion> personally I turn off that history expansion using 'set +H' because I prefer readline history handling and like using 'shopt -s extglob' (stuff like !(foo|bar*) to expand to all files except foo or those that begin with bar)
[09:21] <Kamion> but you might as well get the quoting right anyway
[09:21] <pitti> good morning Kamion 
[09:21] <Kamion> morning
[09:22] <pitti> infinity, tfheen: http://people.ubuntu.com/~pitti/tmp/shadow.ftbfs.patch fixes shadow FTBFS
[09:22] <Kamion> infinity: I would've done 's/<!ENTITY language "C">/<!ENTITY language "'$i'">/'
[09:22] <Kamion> and actually, no, that's not right, what if $i contains spaces
[09:22] <Kamion> 's/<!ENTITY language "C">/<!ENTITY language "'"$i"'">/'
[09:23] <mdke_> gosh
[09:23] <pitti> infinity, tfheen: I checked binary debdiffs, 1.9 makes no difference
[09:23] <infinity> Kamion: I doubt it would in this case. (and the backslashes were just the fastest way between tfheen's and something that worked, not how I would have written it) :)
[09:23] <pitti> infinity, tfheen: and, of course, I did a functionality test
[09:23] <Kamion> pitti: ugh, but fine
[09:24] <Kamion> infinity: :-)
[09:24] <pitti> Kamion: yeah, 'ugh' was my first reaction too. Yay for packages doing dynamic autoreconf'ing :/
[09:24] <tfheen> pitti: approved.  And ugh.
[09:24] <pitti> I guess this style of patch works for other gettext fallout, too, I found some hints on Debian BTS and MLs
[09:24] <Kamion> on the upside, it made the diff less horrible than it might have been
[09:24] <mdke_> infinity: works, yippee!
[09:25] <pitti> Kamion: weeel, with static patches we wouldn't need to fix it in the first place :)
[09:25] <Kamion> true :)
[09:25] <pitti> uploaded
[09:26] <infinity> pitti: Wait, err.  Fuck.  Anything using automake1.7 is going to break?
[09:26] <infinity> pitti: I don't like the sounds of that.
[09:26] <pitti> infinity: well, anything using gettext 0.15, automake 1.7 *and* doing dynamic autoreconf is likely to break
[09:26] <pitti> many packages don't autoreconf at build time and should be fine
[09:26] <infinity> Also, nice UTF-8 TM in the changelog.
[09:27] <infinity> Freak. :)
[09:27] <pitti> infinity: that's why I think another rebuild test is a good idea :/
[09:27] <infinity> Yeah, I've already requested elmo do another import of the current archive and we'll re-do it.
[09:27] <pitti> infinity: /me  vim's compose key
[09:27] <mdke_> morning dholbach 
[09:28] <tfheen> infinity: can we have monthly rebuild tests or something for edgy+1?
[09:28] <infinity> tfheen: This is an LP spec that was meant to be done during the edgy cycle.
[09:28] <dholbach> good morning
[09:28] <dholbach> hey mdke_
[09:28] <infinity> tfheen: But, if I can't get priority for it in UDS-MV, we'll have to look at doing it the dak way.
[09:28] <infinity> tfheen: Cause the current situation sucks.
[09:28] <fabbione> tfheen: i was going to suggest each time we change linux-libc-dev and a week before each milestone
[09:29] <tfheen> fabbione: milestones are every two to three weeks.
[09:29] <tfheen> so that's a bit on the too often side.
[09:29] <infinity> TBH, if it was in LP, we could just do rolling rebuilds.
[09:29] <fabbione> tfheen: so? .. CPU cycles are "cheap"
[09:29] <infinity> Nevermind schedules.
[09:29] <infinity> We have the buildd power to just rebuild forever.
[09:29] <infinity> Which is what I'd prefer.
[09:29] <tfheen> infinity: I care less about whether it's in LP/dak; I do care more about that we don't end up in this situation again.
[09:29] <fabbione> or that
[09:29] <cbx33> can anyone confirm if the beta nvidia driver is going into edgy?
[09:30] <seb128> cbx33: beta driver?
[09:30] <fabbione> cbx33: no it's not
[09:30] <infinity> cbx33: Well, the root hole does make it "attractive", but we'll see.
[09:30] <seb128> cbx33: beta doesn't sound something for a stable distro
[09:30] <cbx33> seb128: no I know hat
[09:30] <cbx33> was thinking in light of the root hole as discussed
[09:31] <fabbione> root hole?
[09:31] <infinity> http://download2.rapid7.com/r7-0025/
[09:32] <Kamion> fabbione: buffer overflow in the binary nvidia driver
[09:32] <fabbione> Kamion: oh ok
[09:32] <Kamion> exploitable by random web page
[09:32] <tfheen> can't really say I'm surprised.
[09:32] <pitti> tfheen: well, it was hard to avoid anyway in this case; we synced gettext, like, three days ago?
[09:32] <fabbione> hmm annoying
[09:33] <Kamion> tfheen: kicking off some CD builds
[09:33] <tfheen> pitti: yes.  I want a proper toolchain freeze for edgy+1.  And a pony.
[09:33] <pitti> Kees poked in the assembly a bit, but in the end we'll have to rely on nvidia 
[09:34] <cbx33> :(
[09:34] <pitti> fabbione: if you encounter similar build failures, feel free to toss them to me; I'll have some time for them while testing the CDs
[09:34] <pitti> tfheen: did you disable daily CDs? the daily ones should be there by now, but aren't
[09:38] <Kamion> pitti: 08:33 < Kamion> tfheen: kicking off some CD builds
[09:38] <Kamion> (yes, the cron jobs are off)
[09:38] <pitti> aah
[09:38] <Kamion> I noticed that the same way. :-)
[09:39] <pitti> ok, time for some breakfast then, bbl
[09:39] <cbx33> sorry to seem like I'm banging on about this....does anybody use the nvidia drivers here? - I'm thinking about using the ones from the nvidia site, but is it possible to go back to the repos at a later date?
[09:42] <fabbione> pitti: yeps will do
[09:44] <fabbione> pitti: i only did 20% of main in the last 3 hours (pkg numbers).. so it might take up to tomorrow morning to finish *
[09:44] <Hobbsee> hey jono!
[09:45] <seb128> cbx33: use the nv driver ;)
[09:46] <Treenaks> seb128: does that support multi-monitor setups?
[09:46] <seb128> Treenaks: you are asking the wrong person, I've no multi-monitor and no idea on the topic :)
[09:46] <Fujitsu> seb128, that's the wrong answer. The correct answer is `Don't buy NVIDIA!'
[09:47] <Treenaks> Fujitsu: too bad, my boss did it..
[09:47] <cbx33> seb128: well, I have the slight problem of liking beryl :p - and wanting to play a few games through wine - mainly because my brother - in - law is having a LAN party
[09:47] <cbx33> Fujitsu: what do you suggest instead....
[09:47] <cbx33> intel?
[09:47] <Fujitsu> cbx33, I don't care about anything like that. I'm a console person, so whatever.
[09:47] <Fujitsu> I am currently using an i915, yes.
[09:48] <tfheen> you can't get amd64s with intel graphics..
[09:48] <seb128> I'm happy with my radeon card
[09:49] <cbx33> I've never had a problem with nvidia thus far.....I know it's all binary drivers and that.......but, I guess, somethings I live with....my main joy is that I'm now totally windows free
[09:49] <cbx33> :D
[09:50] <seb128> games with wine, that's not optimal :/
[09:50] <seb128> what games are you running with it?
[09:50] <mnepton> Intel graphics are no guarantee of proper Linux support. there are Intel certification machines all over this office with half-working or completely b0rken hardware.
[09:51] <Fujitsu> mnepton, but they work properly at the moment with FOSS drivers.
[09:52] <cbx33> seb128, CS:Source
[09:52] <cbx33> works pretty well actually.
[09:52] <cbx33> I get between 30-50 fps
[09:52] <mnepton> Fujitsu: not all of them do.
[09:53] <cbx33> on 1024x768 with most settings on high
[09:53] <mnepton> Fujitsu: in fact, the i845 doesn;t work at all without a third party patch
[09:53] <cbx33> I was pretty pleased with it actually ;)
[09:54] <mnepton> and the 965? don;t even get me started.
[09:54] <mnepton> horrendous.
[09:57] <AnAnt> I got a problem in Edgy, when I proprietry software, I get this error:
[09:57] <AnAnt> Error: Could not create FontSet for font '-adobe-helvetica-medium-r-normal-*-12-*-*-*-*-*-*'.
[09:57] <AnAnt> The following character sets cannot be drawn with this font:
[09:57] <AnAnt> according to xfontsel, I do have that font.
[09:57] <AnAnt> this software used to work in Dapper
[10:01] <Kamion> pitti: at least the Ubuntu images are available now
[10:02] <tfheen> Kamion: doing livefs-es too?
[10:02] <Kamion> yes
[10:02] <Kamion> oh, er
[10:02] <Kamion> no
[10:02] <Kamion> same thing :)
[10:02] <Kamion> ok, sigh, guess I'd better do those ...
[10:02] <pitti> Kamion: thanks, /me cranks up jigdo and rsync
[10:03] <Kamion> pitti: you'll have to just upgrade ubiquity to 1.2.3 on the fly to test that
[10:03] <pitti> oh, it didn't make it? sure, no problem
[10:03] <Kamion> forgot that the livefs cron jobs were also turned off
[10:07] <pitti> tfheen: hm, maybe it's time to start using the testing matrix?
[10:07] <Kamion> terranova.buildd starting at Tue Oct 17 09:03:11 BST 2006
[10:07] <Kamion> terranova.buildd finished at Tue Oct 17 09:04:28 BST 2006
[10:07] <Kamion> uh, that doesn't look good
[10:08] <Kamion> E: Couldn't find task ubuntu-standard
[10:08] <Kamion> DOH
[10:08] <Kamion> infinity: please change all *-standard tasks in livecd.sh to just 'standard'
[10:08] <tfheen> pitti: yes, can you please clean the grid for me?
[10:08] <pitti> sure
[10:09] <tfheen> thanks
[10:09] <tfheen> (I'm in the middle of fixing up a few things on lithium and need to take the puppy out for a minute.)
[10:09] <pitti> I cleaned up the bugs yesterday
[10:09] <Kamion> oh, I need to bump debian-cd to RC, don't I ...
[10:09] <pitti> will set the current images to 20061017 for now
[10:10] <tfheen> Kamion: I did yesterday
[10:10] <Kamion> tfheen: please tell me when you change code so that I can merge it
[10:10] <tfheen> if it's just the OFFICIAL thingy.
[10:10] <Kamion> yes
[10:10] <tfheen> Kamion: ok; sorry.
[10:10] <Kamion> but thanks
[10:12] <infinity> Kamion: Yessir.
[10:16] <infinity> Kamion: Should I s/ubuntu-minimal/minimal^/ while I'm at it?
[10:18] <tfheen> Kamion: put a bzr diff into the daily-checks script?
[10:20] <infinity> Kamion: Okay, try now.
[10:21] <Kamion> infinity: um, not sure about minimal, maybe best to leave that as the metapackage
[10:21] <Kamion> trying
[10:24] <Kamion> tfheen: another qt4-x11 upload in unapproved, from Riddell
[10:24] <Kamion> +  * Fix typo in debian/rules -qt-sql-slite to -qt-sql-sqlite
[10:24] <Kamion> +  * Add missing plugin files to libqt4-gui.install and qt4-designer.install
[10:24] <tfheen> Kamion: approved.
[10:25] <tfheen> Riddell: what is up with https://launchpad.net/distros/ubuntu/+source/kde-systemsettings/+bug/63325 ?
[10:25] <Ubugtu> Malone bug 63325 in kde-systemsettings "systemsettings won't load the desktop_kde-systemsettings.mo translation in Edgy" [Undecided,Confirmed]  
[10:25] <infinity> Come on, queue-builder.  You can do it!
[10:27] <Riddell> tfheen: I'm still working on a fix
[10:28] <infinity> Setting up app-install-data-commercial (6) ...
[10:28] <infinity> Traceback (most recent call last):
[10:28] <infinity>   File "/usr/sbin/update-app-install", line 17, in ?
[10:28] <infinity>     from AppInstall.CoreMenu import *
[10:28] <infinity>   File "/usr/lib/python2.4/site-packages/AppInstall/CoreMenu.py", line 5, in ?
[10:28] <infinity>     from Util import *
[10:28] <infinity>   File "/usr/lib/python2.4/site-packages/AppInstall/Util.py", line 6, in ?
[10:28] <infinity>     import apt
[10:28] <infinity> ImportError: No module named apt
[10:28] <infinity> Is that expected?
[10:28] <tfheen> I hope not.
[10:28] <tfheen> mvo: ^^
[10:29] <Kamion> dholbach: big gnunet change in unapproved that doesn't convince me (if a rebuild's all that's needed, it should just be a rebuild, not a 183K merge including a repackaging, surely?)
[10:29] <Kamion> dholbach: http://people.ubuntu.com/~cjwatson/tmp/gnunet.diff
[10:30] <mdz> infinity: context?
[10:30] <mvo> infinity: kubuntu cd build?
[10:31] <StevenK> Kamion: Oh damn. So noted, though. Thanks.
[10:31] <dholbach> Kamion: ok, StevenK: you look after it?
[10:31] <StevenK> Hum?
[10:32] <Kamion> dholbach: StevenK was at very high reply latency
[10:32] <Kamion> the gnunet upload was from Kai Kasurinen
[10:32] <dholbach> oh ok
[10:33] <dholbach> Kamion: I'm not sure I know who that is, I'll try to find out what's going on.
[10:33] <infinity> mvo: ubuntu livefs.
[10:33] <infinity> mvo: +build.
[10:33] <Kamion> dholbach: thanks. if you want to reject it, I'll do so and send mail
[10:33] <StevenK> Kamion: I tend to check IRC before leaving for work, I didn't this morning.
[10:33] <infinity> mvo: The postinst doesn't error out, so I assumed perhaps you were ignoring that exit code for a reason. :)
[10:34] <infinity> mvo: Either that, or there are two bugs there.
[10:34] <Kamion> infinity: python-apt is configured just a little bit afterwards; I assume app-install-data-commercial doesn't depend on it for some reason
[10:34] <Kamion> (which might be a bug)
[10:34] <mvo> infinity: yeah, I don't want the postinst to fail if update-app-install fails, its just a cache, its not critical
[10:34] <infinity> Right, which would be perhaps two bugs.  Missing dep, and postinst ignoring errors.
[10:34] <mdz> Kamion: it's g-a-i which contains update-app-install (and that does depend on python-apt) but -data doesn't depend on it
[10:34] <infinity> mvo: Ahh, kay.  Is the missing dep a bug?
[10:36] <mvo> infinity: strictly speaking the app-install-data-commercial does not really need python-apt - and when g-a-i is installed (later I presume) update-app-install will be called again and that gives us a valid cache
[10:36] <mvo> infinity: but it shouldn't make that much noise about it :)
[10:36] <infinity> mvo: Kay, perhaps just a redirect of stderr then, if you know it's likely to fail and spew.
[10:36] <infinity> mvo: But hardly critical if the cache is rebuilt later, thanks.
[10:37] <Kamion> pitti: could you reupload shadow without whatever dpkg-buildpackage -i option you're using to skip .svn? It makes the diff rather noisy
[10:37] <mvo> infinity: if app-install-data or g-a-i is configured later, then that should be fine
[10:37] <tfheen> just use -i and it'll DTRT
[10:37] <Kamion> no, don't
[10:37] <pitti> Kamion: oh, oops; the filterdiff -x output is on http://people.ubuntu.com/~pitti/tmp/shadow.ftbfs.patch
[10:37] <Kamion> skip -i altogether to keep the .svn directory there, since it's there already
[10:37] <pitti> yes, I use -i by default, since it makes diff.gz's annoyingly hard to read and big
[10:38] <tfheen> oh, point
[10:38] <Kamion> pitti: yeah, the diff without it is fine, but please reupload with a minimal non-filtered diff so that we don't have merge pain later
[10:38] <pitti> alright
[10:38] <Kamion> i.e. just dpkg-buildpackage -S
[10:38] <Kamion> (I use -i by default too, but turn it off when the package already has revision control junk in it)
[10:39] <pitti> Kamion: do you reject the current version or shall I bump the version number?
[10:39] <pitti> s/current version/current upload/
[10:39] <Kamion> pitti: I'll reject the current version
[10:39] <janimo> infinity: how recent are the packages on the new liveCDs made in the past hours? I see it does not contain packages uploaded and build yesterday
[10:39] <Kamion> janimo: see scrollback please
[10:40] <Kamion> janimo: I forgot that the livefs cron jobs were disabled before building the live CD images; I'm rebuilding the livefses now (which will take a while) and will rebuild images after that
[10:41] <dholbach> Kamion: 0.7.0e-3 seems to bring the big changes (which is from Debian) (cf bug 66507)
[10:41] <Ubugtu> Malone bug 66507 in gnunet "[DEBDIFF]  gnunet: merge new debian version" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66507
[10:41] <janimo> Kamion: just logged in, no scrollback but thanks, will look at the irclogs
[10:41] <janimo> Kamion: ok, thanks
[10:41] <Kamion> dholbach: that's the CDBSisation, yes, but this is the changelog for -3ubuntu1:
[10:41] <Kamion> +  * Merge from debian unstable.
[10:41] <Kamion> +  * Rebuild fixes missing dependencies (Closes: Malone #66467)
[10:41] <Ubugtu> Malone bug 66467 in gnunet "Missing dependencies" [Undecided,Confirmed]  http://launchpad.net/bugs/66467
[10:41] <Kamion> +  * Build with IPv6 support
[10:41] <Kamion> +  * Use debhelper compatibility level 5
[10:41] <stub> launchpad is recovered and back on its feet in case nobody has noticed.
[10:41] <Kamion> +  * Update init script:
[10:42] <Kamion> +   - create /var/run/gnunetd in init script
[10:42] <Kamion> +   - support reload
[10:42] <Kamion> +  * Add Spanish translation
[10:42] <Kamion> I don't see the justification for that merge
[10:42] <imbrandon> Kamion, ajmitch asked me to look over it and upload then ask dholbach, i dident see dholbach login so i dident poke him and ajmitch isnt back yet
[10:43] <Kamion> imbrandon: I think it's a big change with few benefits. What was the rationale for the change rather than simply uploading a rebuild (and possibly fixing the init script to create /var/run/gnunetd as well)?
[10:44] <imbrandon> Kamion, its not critical imho so rejection is fine with me and i'll revist it +1 but ajmitch might have othere reasons for me to have looked it over
[10:44] <dholbach> Kamion: ok, reject it, I'll ask for a justification of it.
[10:44] <pitti> Kamion: uploaded; sorry for the inconvenience
[10:45] <imbrandon> Kamion, the main change was the merge, a rebuild ( and init fix ) would be sufecent imho , would you rather that or wait for justifcation from ajmitch ?
[10:46] <Kamion> imbrandon: I'm sending mail to Kai
[10:46] <pitti> wow, apt-get dist-upgrade on current live CDs wants to suck 117 MB of updates
[10:47] <Kamion> I'll CC you
[10:47] <dholbach> Kamion: thanks for that.
[10:47] <pitti> tfheen: ^ hmm, I think I don't advertise this version on the Testing/Current page yet
[10:47] <imbrandon> Kamion, ok
[10:49] <dholbach> tfheen: ok to upload the ubuntu-docs (translations added)?
[10:50] <Kamion> pitti: yeah, not much point until we've rebuilt the livefses
[10:51] <tfheen> pitti: the desktop one?  No point, as Colin says
[10:52] <pitti> right
[10:52] <tfheen> dholbach: yes.
[10:52] <pitti> Kamion: ok, ubiquity updated, I'll give it a shot now
[10:53] <dholbach> oh lord, it's bloody huge
[10:53] <dholbach> pitti: I ordered more ram for an (even older) ppc too :)
[10:53] <pitti> well, 1 GB more should make a difference
[10:54] <dholbach> definitely
[10:56] <imbrandon> pitti, heh i've been using my 800mhz 640mb ram ppc lately , intersting to say the leaste
[10:57] <imbrandon> definately makes me appreciate my fast build box when i'm on it
[10:58] <cbx33> is there a quick way in the alternative install for skipping the checking the mirror step?
[10:58] <cbx33> I'm behind a proxy at the mo....but not where I use it normally
[11:00] <Chandan> imbrandon, How to build custom ubuntu cd
[11:00] <ajmitch> imbrandon: yeah, that's why I asked you to look over it before I gave an ok - I wasn't completely present either :)
[11:02] <imbrandon> ajmitch, right
[11:03] <ajmitch> all I looked at was the changelog
[11:03] <imbrandon> ajmitch, no worries, i think its pretyy clear now, hopefull kai will take care of it today, if not i will tonight
[11:03] <ajmitch> ok 
[11:03] <Kamion> cbx33: no, sorry
[11:03] <StevenK> infinity: Oh, I've fixed hat too, but my poor Sparc is too crappy to build it.
[11:03] <imbrandon> Chandan, there is a howto on the wiki ( http://wiki.ubuntu.com )
[11:04] <fabbione> StevenK: what fix needs to be tested on sparc?
[11:05] <cbx33> Kamion: can we come up with something for edgy + 1
[11:06] <pitti> oh, firefox 2.0rc3
[11:06] <sabdfl> ok, did the "free the fish" thing, now how do i make it go away for good?
[11:07] <pitti> sabdfl: killall gnome-panel should do
[11:07] <sabdfl> thanks pitti
[11:07] <ajmitch> heh
[11:07] <pitti> sabdfl: . o O { we should totally have an Ubuntu specific easter egg! }
[11:07] <sabdfl> free the warthog
[11:07] <ajmitch> pitti: how close to release will april 1 be next year? :)
[11:08] <Kamion> cbx33: maybe
[11:08] <Kamion> cbx33: probably a cancel button, the problem is communicating it to apt
[11:09] <realist> StevenK: Are you Steve Kemp?
[11:09] <cbx33> Kamion: ah I see, of course
[11:10] <cbx33> could apt have a shorter timeout period?
[11:10] <infinity> cbx33: /whois is your friend.
[11:10] <infinity> Err.
[11:10] <infinity> realist: /whois is your friend.
[11:10] <StevenK> realist: I am not.
[11:10] <infinity> cbx33: Ignore my inability to read.
[11:11] <Kamion> cbx33: that wouldn't actually help
[11:11] <StevenK> fabbione: Not including a file. I can send you the (small) diff, if you like.
[11:11] <fabbione> StevenK: up to you.. i have a machine up
[11:11] <cbx33> Kamion: heheh, just shows my knowledge level about it all then :p
[11:11] <Kamion> cbx33: the shortest timeout period that's sane in the face of stupid network conditions is a minute or two, and you have to multiply that up by the number of repositories apt is contacting by default
[11:11] <pitti> tfheen: current DVD is 20061014; can you roll new ones for testing, too? (once new livefses are ready)
[11:11] <Kamion> cbx33: there are two real problems here
[11:11] <cbx33> Kamion: yeh I get ya!
[11:11] <StevenK> fabbione: I'd rather know it builds sucessfully rather than just upload it.
[11:11] <tfheen> pitti: yes, we'll want that.
[11:12] <Kamion> cbx33: (a) apt doesn't notice that it timed out last time; it could just give up if so
[11:12] <fabbione> StevenK: ok.. send me the patch then.. as i said.. up to you :)
[11:12] <Kamion> (timed out on the same host)
[11:12] <realist> infinity: that depends how friendly people's IRC clients are
[11:12] <cbx33> Kamion: true
[11:12] <fabbione> StevenK: i don't mind testing it for you since i offered :)
[11:12] <Kamion> cbx33: (b) no facility to tell apt to give up now in response to a cancel button
[11:12] <cbx33> hmmm...
[11:12] <cbx33> indeed those are big problems
[11:13] <StevenK> fabbione: How do you want it?
[11:14] <StevenK> I'd put it on the web, but my webserver isn't booting. :-/
[11:14] <fabbione> StevenK: mail is fine
[11:14] <fabbione> fabbione@ 
[11:14] <StevenK> I figured. :-)
[11:15] <mdz> Kamion: SIGTERM should do fine for (b)
[11:15] <cbx33> mdz I was wondering that
[11:15] <Kamion> mdz: ok, no race conditions there?
[11:15] <cbx33> then we could have a "skip" button
[11:15] <Kamion> we already have the (c)debconf facility for a cancel button
[11:16] <Kamion> oh, er, no we don't here
[11:16] <StevenK> fabbione: Sent.
[11:16] <Kamion> the state of the cancel button is only checked at each db_progress command
[11:16] <Kamion> and at the moment db_progress is only run once per apt-get update
[11:16] <cbx33> I see there is still the Alt-Tab bug too :(
[11:16] <Kamion> we'd have to rearrange that and have a sleep loop or something
[11:16] <Kamion> cbx33: what?
[11:16] <cbx33> if you press alt-tab anytime there is a progress bar it crashes the whole install
[11:17] <Kamion> cbx33: nobody has ever told me about that, and I've never seen it
[11:17] <cbx33> I have LP'd a bug about it
[11:17] <Kamion> so your "still" is a bit much for me ;)
[11:17] <Kamion> cbx33: where?
[11:17] <cbx33> I'll find it hang on
[11:17] <cbx33> sorry Kamion, wasn't a dig at anyone
[11:17] <cbx33> just an observation
[11:17] <Kamion> no, I just hate hearing about bugs for the first time two days before release candidate
[11:18] <cbx33> https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/47643
[11:18] <Ubugtu> Malone bug 47643 in debian-installer "Alt + Tab freezes progress bar" [Medium,Unconfirmed]  
[11:18] <Kamion> gar, wrong package, no wonder
[11:18] <fabbione> StevenK: go it.. will let you know soon.. i need to reboot this machine first
[11:18] <Kamion> oh, maybe not
[11:18] <Kamion> cbx33: this is in the alternate install?
[11:18] <cbx33> I did mention it in here a few weeks ago
[11:18] <cbx33> Kamion: yes
[11:18] <Kamion> ok, I thought you meant in ubiquity
[11:18] <cbx33> which isn't so crucial
[11:18] <Kamion> a few weeks ago, I was moving house and not reliably contactable
[11:18] <cbx33> Kamion no....sorry to have scared you
[11:19] <cbx33> it came about as I was installing in a VM...and alt-tabbing before I'd ctal+alt'd
[11:19] <cbx33> but I tried it on "real" hardware and it still happens
[11:20] <mdz> Kamion: I'm pretty sure it DTRT for the downloads; somewhat less so about the cache updating
[11:20] <Kamion> yeah, that's the bit that concerns me
[11:20] <mdz> Kamion: anyway, surely this is one for post-edgy unless there's a newer and more serious issue
[11:20] <Kamion> mdz: absolutely post-edgy
[11:21] <Kamion> no way am I messing about with that now
[11:21] <cbx33> hehe
[11:21] <Kamion> oh, crap, cdebconf-keystep is broken
[11:21] <pitti> Testing/Current cleaned, live images marked as obsolete
[11:21] <Kamion> tfheen: ^-- sorry :(
[11:23] <tfheen> Kamion: broken how?
[11:24] <Kamion> tfheen: doesn't accept YES/NO after the (new) FINDP command
[11:24] <Kamion> so it generally falls over midway through layout detection
[11:25] <tfheen> ouch.
[11:26] <Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/cdebconf-keystep.diff
[11:26] <pitti> seb128, mvo: I'll test the powerpc alternate variants and some amd64; can any of you test i386 alternate and maybe some amd64, too?
[11:26] <seb128> pitti: are we in grid test mode already?
[11:27] <pitti> seb128: I just cleaned it
[11:27] <cbx33> but I guess you want 17?
[11:27] <seb128> pitti: I've no alternate iso handy so I need to download them completly, it'll take some hours on my not-that-fast-dsl
[11:27] <pitti> seb128: desktop is out of date, should arrive within some hours, but alternates should be fine for testing
[11:27] <tfheen> Kamion: go for it.
[11:27] <seb128> I do desktop CD testing usually
[11:27] <pitti> seb128: ah, I see; 
[11:27] <pitti> seb128: I thought you had an i386 installation
[11:27] <seb128> desktop CD
[11:28] <pitti> seb128: (jigdo immensely helps with a good apt cache :) )
[11:28] <seb128> I'll give it a try :)
[11:28] <pitti> seb128: but nevermind
[11:28] <seb128> I'll download them anyway
[11:28] <seb128> still good to give them some testing
[11:28] <seb128> and so I can rsync next time
[11:34] <pitti> Kamion: current desktop with dist-upgraded ubiquity installs the kernel fine and creates an initrd, but doesn't boot
[11:34] <infinity> Yay, dirty chroots.
[11:34] <infinity> scim-gtk2-immodule can't be removed.
[11:34] <pitti> Kamion: 'Loading ramdisk...\nramdisk load failed !', and then I get the OF shell
[11:35] <sivang> mornig
[11:35] <infinity> Removing scim-gtk2-immodule ...
[11:35] <infinity> /var/lib/dpkg/info/scim-gtk2-immodule.postrm: line 8: /usr/sbin/update-gtk-immodules: No such file or directory
[11:35] <infinity> dpkg: error processing scim-gtk2-immodule (--purge):
[11:35] <infinity>  subprocess post-removal script returned error exit status 1
[11:35] <infinity> Anyone want to fix the above?
[11:36] <pitti> infinity: I'll have a look
[11:36] <infinity> I suspect it's trying to call it in purge, or something.
[11:36] <infinity> Cause it looks like the dep should be there for remove.
[11:36] <dholbach> a dep on libgtk2.0-bin is missing
[11:37] <Kamion> pitti: can you find out if (a) the initrd link is present in /boot and (b) /etc/yaboot.conf is correct?
[11:37] <pitti> dholbach: dependencies don't help you in purge
[11:37] <pitti> Kamion: (a) yes; booting live image right now to find out (b)
[11:37] <infinity> dholbach: libgtk2.0-0 depends on -biso the dep is fine.
[11:37] <infinity> s/-biso/-bin, so/
[11:37] <infinity> Latency is hell on my typing. :/
[11:37] <pitti> infinity: hm, it calls update-gtk-immodules in 'remove', not 'purge'
[11:38] <infinity> And another:
[11:38] <infinity> Removing python-zopeinterface ...
[11:38] <infinity> dpkg: error processing python-zopeinterface (--purge):
[11:38] <infinity>  subprocess pre-removal script returned error exit status 1
[11:40] <infinity> pitti: Hrm, I may have to try to replicate this harder, then.
[11:40] <infinity> pitti: COuld be something else buggering it earlier.
[11:40] <pitti> inmI can't see an obvious flaw here
[11:40] <mdz> infinity: can you confirm that -bin is installed at the time?
[11:40] <pitti> and it should be legitimate to use dependency on 'remove'
[11:40] <infinity> mdz: Oh, I'm sure it's not, but I need to find out how the chroot got in that state now.
[11:40] <infinity> Ineed to add a flag to launchpad-buildd (and the DB) to flag builds where chroots are left dirty.
[11:41] <infinity> This is the one thing we're missing with the new world order of a fresh chroot for every build.
[11:42] <mdz> doko: would you have a look at python-zopeinterface?
[11:43] <infinity> Err, wait.  This one could be an apt bug...
[11:43] <infinity> How is this even possible?
[11:44] <infinity> Removing libgtk2.0-bin ...
[11:44] <infinity> Purging configuration files for libgtk2.0-bin ...
[11:44] <infinity> Removing scim-gtk2-immodule ...
[11:44] <infinity> /var/lib/dpkg/info/scim-gtk2-immodule.postrm: line 8: /usr/sbin/update-gtk-immodules: No such file or directory
[11:44] <infinity> It pretty clearly shouldn't let me do that...
[11:45] <mdz> infinity: unless it's doing --force-depends, things are not as they seem in the dependency chain
[11:46] <mdz> or else dpkg gets it wrong too, which seems increasingly unlikely
[11:46] <infinity> scim-gtk2-immodule depends on libgtk2.0-0, which depends on libgtk2.0-bin, but it's removing -bin, then scim, then libgtk.
[11:47] <mdz> infinity: you're certain that you're looking at the same versions of all packages involved, etc.?
[11:48] <infinity> Yeah, other than being dirty, the chroot is up to date.
[11:49] <infinity> Trying to remove the cruft, it always removes in the above order (unless I go one pakcage at a time, obviously, which solves it)
[11:51] <mdz> dholbach: how serious is bug 66323?
[11:51] <Ubugtu> Malone bug 66323 in bluez-gnome "Problem report for bluez-passkey-gnome" [Medium,Unconfirmed]  http://launchpad.net/bugs/66323
[11:52] <dholbach> mdz: it seems to crash - I'm on it, needs extraction of bits out of a patch that upstream sent
[11:53] <dholbach> (although it didn't crash for me in any of my tests yet)
[11:53] <mdz> dholbach: it crashes under what circumstances?
[11:53] <infinity> mdz: Completely reproducible at home with a clean --variant=buildd chroot, "apt-get install scim-gtk2-immodule && apt-get --purge remove [list of packages just installed] "
[11:54] <mdz> infinity: is there a cycle in there somewhere perhaps?
[11:54] <mdz> aha
[11:54] <mdz> libgtk2.0-0 depends: libgtk2.0-bin depends: libgtk2.0-0
[11:54] <fabbione> StevenK: almost done.. sorry but i had some hell of a crash here
[11:55] <infinity> Oh, that would do it. :/
[11:55] <mdz> seb128: why does libgtk2.0-0 depend on libgtk2.0-bin?
[11:55] <infinity> mdz: So, scim-gtk2-immodule needs an explicit dep on -bin, or the cycle needs to be broken.
[11:55] <dholbach> mdz: "just like that", upstream's patch also "fixes another problem with the D-Bus proxy handling" (cf bug 65645)
[11:55] <Ubugtu> Malone bug 65645 in bluez-gnome "Die systray icon die!" [Undecided,Fix released]  http://launchpad.net/bugs/65645
[11:55] <infinity> (The explicit dep seems sane anyway, since it calls binaries from there)
[11:55] <cbx33> I asked this question earlier on, does anyone know why nvidia-glx depends on the 386 restricted modules...even if I'm using the genreic modules?
[11:56] <mdz> an explicit dep would probably do it
[11:56] <seb128> mdz: because the -bin has the program required for the loaders and modules registration
[11:56] <infinity> Counting on the transient dep to pull in the binary seems iffy.
[11:56] <StevenK> fabbione: No problem.
[11:56] <tfheen> pitti: https://launchpad.net/distros/ubuntu/+source/language-pack-pl/+bug/63344 should be fixed with new langpacks, or?
[11:56] <Ubugtu> Malone bug 63344 in language-pack-pl "rosetta truncated plural form for pl and that breaks python apps" [Medium,Confirmed]  
[11:56] <cbx33> and is it a bug, or just a thing!
[11:56] <mdz> cbx33: as you can see by looking at the package, it doesn't
[11:56] <infinity> mdz: Even then, the removal order seems suboptimal, but whatever.
[11:56] <cbx33> mdz, why when I try to install nvidia-glx does it try to pull in the restricted modules then?
[11:57] <mdz> seb128: but libgtk2.0-0 doesn't seem to call those programs when it's installed or removed
[11:57] <infinity> mdz: (I'd expect "remove evertthing that depends on libgkt|libgtk-bin, then break the loop arbitrarily"
[11:57] <infinity> )
[11:57] <cbx33> but the 386 modules....not the generic modules
[11:57] <mdz> cbx33: because it depends on having _some_ nvidia module, not any one in particular
[11:57] <cbx33> ok, so if I install the generic one, it'll be fine
[11:57] <infinity> cbx33: Because we can't express a "install this if you have that" dependency.
[11:58] <seb128> mdz: no, libgtk2.0-bin does the registration, but it needs to be installed for that
[11:58] <cbx33> because it then wants to install the 386 linux image
[11:58] <cbx33> ok that's fine
[11:58] <infinity> cbx33: If you explicitely install the ones you want, it'll be fine, yes.
[11:58] <cbx33> thanks guys
[11:58] <cbx33> sorry to have troubled you with that one
[11:58] <cbx33> still learning 0_o
[11:58] <pitti> tfheen: depends, Rosetta has to export correct PO files first
[11:58] <infinity> mdz: Anyhow, the immediate fix for the scim thing seems obvious, so I'll fix that.
[11:59] <tfheen> pitti: ok.  If it's still broken with the final export on Friday, can we just hack around it?
[11:59] <pitti> tfheen: I'll talk to carlos; yes, I can manually put good po files into the tarball and rebuild the packs
[11:59] <infinity> tfheen: Permission to upload a scim with scim-gtk2-immodule explicitely depending on libgtk-bin?
[12:00] <tfheen> pitti: ok, thanks, that's all I wanted to know.
[12:00] <tfheen> infinity: go ahead.
[12:00] <seb128> mdz: the circular Depends has been broken to Debian by moving things to libgtk2.0-0, that's not for edgy though
[12:00] <mdz> seb128: oh, i see
[12:01] <infinity> mdz: After a full rebuild, the only dirt in the chroots was the scim thing anyway, so the consequences of the loop seem limited.
[12:01] <infinity> mdz: So we can likely ignore it (with the scim dependency hack).
 daily limit reached
[12:02] <infinity> Hah.
[12:03] <mdz> that's even sillier than usual
[12:03] <infinity> It needs to shut off your machine forcefully at that point. :)
[12:03] <mdz> it's 1103
[12:03] <infinity> "Now doing 'cat /dev/random > /proc/kcore', hang on"
[12:06] <Kamion> mdke_: I'm not wild about sucking an out-of-date version of installation-guide into ubuntu-docs
[12:07] <Kamion> if you're copying that, it needs to be *automatically* kept up to date
[12:10] <Kamion> mdke_: oh, am I correct that you aren't building it by default?
[12:10] <Kamion> (I hope not. It's already in the installation-guide source package, we don't need duplication there)
[12:11] <ogra> +extern struct usplash_pixmap pixmap_usplash_640_400;
[12:11] <ogra> +extern struct usplash_pixmap pixmap_usplash_800_600, pixmap_usplash_1024_768, pixmap_usplash_1365_768_scaled;
[12:11] <ogra> shouldnt there be a theme for 640x480 as well in usplash-theme-ubuntu.c ?
[12:12] <ogra> (accor4ding to the changelog there is, but there is no definition in the code)
[12:13] <ogra> Seveas, mjg59 ?? ^^^^
[12:15] <sladen> StevenK: you can write to /dev/mem ...
[12:19] <cbx33> in my latest edgy install, the usplash doesn't fit the screen as it did before
[12:19] <carlos> tfheen: that's a know bug, I will try to prepare a fix before the final language pack generation 
[12:19] <cbx33> it runs at 1280x1024 with a 1024x768 window for usplash
[12:19] <ogra> cbx33, what does /etc/usplash.conf say ?
[12:19] <cbx33> is that known?
[12:20] <cbx33> can't say I'm not at that machine now
[12:20] <mdz> infinity: did this initramfs-tools upload turn on a chunk of maintainer script which had been dormant (and potentially untested), as it sounds?
[12:20] <sabdfl> is xutils supposed to be bringing in xutils-dev and cpp?
[12:21] <ogra> so can anybody confirm usplash handles 640x480 as it should ? (did anybody test it ?)
[12:21] <tfheen> ogra: it works with 640x400 at least.
[12:21] <ogra> tfheen, yes, i see that in the code, but we'll have tons of users where 7etc/usplash.-conf defines 640x480) all from beta had that iirc
[12:22] <ogra> */etc/usplash.conf
[12:22] <tfheen> ogra: on amd64 or in general?
[12:22] <ogra> in  general
[12:22] <jamesh> does anyone else have problems with truetype fonts not being registered with the old X font system in Edgy?
[12:22] <tfheen> ogra: well, it ought to work, but I haven't tested.
[12:22] <ogra> we had a bug in usplash that made these values default to 640x480
[12:22] <jamesh> I reported a bug about it here: https://launchpad.net/bugs/66360
[12:22] <Ubugtu> Malone bug 66360 in x-ttcidfont-conf "x-ttcidfont-conf.defoma fails to create fonts.dir file on Edgy" [Undecided,Unconfirmed]  
[12:23] <tfheen> oh, gnr.  my usplash-theme-ubuntu upload is (slightly) broken.  I removed the update-initramfs call in postinst.
[12:23] <ogra> ouch
[12:23] <tfheen> infinity: did you fix that before accepting it or should I upload a new one?
[12:24] <infinity> tfheen: I didn't notice that in the diff, no...
[12:25] <sladen> sabdfl: xutils used to depend on imake, which is now provided by xutils-dev.  debatable, perhaps the naming could be better
[12:25] <infinity> mdz: It was code that was previously testes (and is necessary) in the postinst, and it moved to preinst, hence taking the "configure" test with it (which should now be "install")
[12:25] <tfheen> ogra: which theme patch?  The hack I did in u-t-u last night?
[12:25] <ogra> yes
[12:25] <mdz> sabdfl: doesn't sound right, no.  Kamion?
[12:26] <ogra> tfheen, i know that most of edubuntu testers has 640x480 ... so it would be odd if it wouldnt work 
[12:26] <ogra> *had
[12:26] <mdz> infinity: how long ago did it move?
[12:26] <tfheen> ogra: well, that was just grabbing the dapper artwork and making it look _slightly_ less shit.  No need for it in other packages, I'd guess.
[12:27] <ogra> tfheen, well, if i want edubuntu usplash themeing, i should have a matching theme for the size :)
[12:27] <ogra> so i'll have to adjust u-t-e
[12:27] <ogra> and i guess the others as well
[12:28] <Seveas> ogra, I'm working on the ubuntu theme right now
[12:28] <ogra> Seveas, can you provide a proper pacth that i can apply to usplash-theme-edubuntu.c ? i'll care for the artwork
[12:28] <StevenK> fabbione: Any news?
[12:28] <Seveas> will do
[12:28] <ogra> thanks !
[12:28] <ogra> :)
[12:28] <fabbione> StevenK: it's building..
[12:29] <StevenK> fabbione: Ah.
[12:29] <fabbione> StevenK: the machine has average load of 48.. please be patiente :)
[12:29] <StevenK> It took 17 minutes on my amd64, so I shouldn't be impatient.
[12:31] <tfheen> Seveas: please make sure to remove my # from the "update-initramfs" line.
[12:31] <cbx33> ogra: shouild that sound issue in ubuntu be fixed now?
[12:31] <Seveas> tfheen, heh, you hate that too when testing>
[12:31] <Seveas> ?
[12:33] <tfheen> Seveas: no shit. :-)
[12:34] <infinity> mdz: The bug was merged in July, and fixed in Debian after that.  It only affects new installs (and only in ways you'd notice if you were looking for them, I suspect), so I'm guessing no one really noticed.
[12:34] <ogra> cbx33, with the new ltsp-server package
[12:34] <mdz> infinity: new installs like every beta install?
[12:35] <infinity> mdz: Half the code if for mkinitrd -> mkinitramfs migration (so not a big deal anymore anyway, I suppose), and the other half is RESUME configuration, which is handled by ubiquity and d-i if you're using "proper installatoin methods".
[12:35] <cbx33> ogra: ok...i'll investigate..
[12:35] <mdz> wouldn't this cause RESUME not to be set properly on all of those?
[12:35] <infinity> mdz: The code is meaningless to most people, IOW.  But still should be there and should work.
[12:35] <ogra> cbx33, i still cant reproduce it btw, i made various tests on the weekend
[12:35] <cbx33> that sux...
[12:35] <sivang> can anybody take a look at http://librarian.launchpad.net/4862302/buildlog_ubuntu-edgy-ia64.debtags-edit_1.1.3build1_FAILEDTOBUILD.txt.gz , seems odd as I can install libapt-front-dev on my local edgy.
[12:35] <infinity> mdz: But it's a straight cut'n'paste of the old postinst (and well-tested in Debian), so I'm confident it's all good.
[12:35] <cbx33> i can tell you it's still happeneing here
[12:36] <cbx33> though I need to update my ltsp chroot
[12:36] <ogra> nah ... its a gstreamer issue (server sided)
[12:36] <infinity> mdz: (I also passed it by Kamion and tfheen for review before accpeting it)
[12:36] <cbx33> ogra: oh...then it still seems present
[12:36] <ogra> cbx33, did you see that ? http://developer.novell.com/wiki/index.php/Edgy/HOWTO:_PulseAudio
[12:36] <mdz> infinity: I'm trying to understand the impact of the original problem
[12:37] <cbx33> ogra: no...oooooooooooooh !
[12:37] <ogra> :)
[12:37] <ogra> skype via ltsp :)
[12:37] <mdz> infinity: the code which used to be in the 'configure' block includes more than just the initrd migration; it sets RESUME, no?
[12:37] <cbx33> will we be moving to pulse?
[12:37] <ogra> (and without local apps)
[12:37] <ogra> yes
[12:37] <cbx33> nice
[12:38] <cbx33> is local apps planned for edgy + 1
[12:38] <ogra> rather +2
[12:38] <ogra> we'll need a network auth system in place first
[12:38] <ogra> getting that running properly out of the box will take most of edgy+1 development i guess
[12:39] <cbx33> right
[12:39] <StevenK> sivang: I had a look at the build log for libapt-front on ia64, and it blows up violently, and I don't know enough C++ to diagnose.
[12:39] <StevenK> sivang: The same thing is affecting my packagesearch upload.
[12:40] <sivang> StevenK: interesting. from what I can see it looks like a libapt-front-dev mis-version dependency ? 
[12:40] <sivang> StevenK: libapt-front-dev: Depends: libtagcoll-dev (< 1.6) but 1.6.3-1 is to be installed
[12:40] <StevenK> sivang: The new version built on everything bar ia64.
[12:40] <StevenK> Um. New version of libapt-front
[12:41] <sivang> yes, I see
[12:42] <StevenK> If libapt-front is fixed, both debtags and packagesearch should deal with a give-back on ia64.
[12:42] <sivang> StevenK: hmm, maybe dropping the << specification would help:
[12:42] <sivang> StevenK: Depends: libtagcoll-dev (>= 1.6), libtagcoll-dev (<< 1.7), 
[12:42] <doko_> ajmitch, dholbach: please approve http://people.ubuntu.com/~doko/edgy/optcomplete.debdiff
[12:43] <doko_> mvo: ping
[12:43] <sivang> (from libapt-front-0.3.9ubuntu5/debian/control)
[12:43] <StevenK> Ah.
[12:43] <dholbach> doko_: looks good :)
[12:43] <StevenK> sivang: It builds on everything but ia64, though...
[12:44] <sivang> StevenK: maybe only there the version is higher?
[12:44] <sivang> anyway, gotta run for now
[12:45] <StevenK> Doesn't seem to be.
[12:46] <fabbione> StevenK: it's  still building.. but i need to go offline for one hour or so.. i will ping you back once i am here again
[12:46] <mdz> ogra: can you confirm bug 63303?
[12:46] <Ubugtu> Malone bug 63303 in gnome-power-manager "No sleep button in edgy?" [Critical,Confirmed]  http://launchpad.net/bugs/63303
[12:46] <StevenK> fabbione: No problem.
[12:46] <StevenK> fabbione: Thanks for your help. :-)
[12:47] <fabbione> StevenK: no problem.
[12:47] <Kamion> sabdfl: xutils is a transitional package, and we'll move away from it once we have time; the naming is not ideal
[12:50] <ogra> mdz, yes, i can confirm at least that the key is set to "nothing" in our default setup ... 
[12:50] <ogra> mdz, its a one line change if i should enable it again ... but it was like that in dapper already
[12:51] <mdz> ogra: really?  my sleep key works
[12:51] <mdz> ogra: why is it disabled by default?
[12:51] <mdz> i don't remember using gconf to enable it either
[12:51] <ogra> i think it went hand in hand with a patch from Kinnison 
[12:51] <pitti> ugh, automatic keyboard detector is broken on alternate, it just loops
[12:52] <Amaranth> In dapper when you tried to tell gnome-power-manager to suspend on some event it popped up a warning dialog telling you it doesn't work everywhere
[12:52] <sabdfl> ok kamion - was just checking because it pulled 5mb of CPP into my Xubuntu setup
[12:52] <Kamion> bringing in cpp is not ideal, but I'm not sure that's fixable right now
[12:52] <Kamion> xutils-dev is one big package (that was a merge from Debian), depends on cpp, and includes stuff that used to be in xutils
[12:53] <mdz> pitti: targeted bug please
[12:53] <pitti> yep, was about to do it
[12:53] <ogra> mdz, oh, the kinnison patch added a row in the pulldown menu of the UI that set this key, its incompatible with the 2.16.X UI changes of g-p-m ... 
[12:53] <jdub> Kamion: shouldn't that be changed to mcpp?
[12:54] <Kamion> jdub: only if whatever uses it can actually cope with mcpp. I have not checked
[12:54] <jamesh> sabdfl: X resource files get preprocessed by cpp, so a CPP implementation is necessary
[12:54] <jamesh> Kamion: xrdb should handle it fine ...
[12:54] <Kamion> jamesh: it's not for X resource files
[12:54] <Kamion> xrdb is a separate package
[12:55] <jamesh> ah.
[12:55] <Kamion> it's for one of ccmakedep, imake, lndir, makedepend, or makeg
[12:55] <Kamion> probably imake
[12:55] <mdz> ogra: so it is a regression in fact
[12:55] <ogra> mdz, so should i change the default for the gconf key to "suspend" ?
[12:55] <mdz> ogra: why was it set otherwise in the first place?
[12:56] <Kamion> the only reason I made that xutils upload was that xbase-clients, xlibs-dev, and xutils weren't being built by any source and yet were (build-)depended on by other packages, which was an archive consistency error
[12:56] <mdz> ogra: is that the default upstream?
[12:56] <Kamion> I didn't particularly want to end up being responsible for xutils-dev in the process ;-)
[12:56] <Kamion> s/xutils upload/xorg upload/
[12:56] <ogra> mdz, well, Kinnison would know ... i think there was a problem that it wasnt selectable at all ... 
[12:56] <mdz> mjg59: can you think of any reason why that was so?
[12:57] <mdz> it doesn't make any sense to me but I'm wary of changing the default at the 11th hour if it was done for a reason
[12:57] <ogra> there was an UI element before ....
[12:57] <siretart> yay, nvidia we love you! http://download2.rapid7.com/r7-0025/
[12:57] <ogra> you coul dchange it to 2suspend" via the settings ... which is not possible in the 2.16.x UI
[12:58] <mdz> ogra: regardless of the UI it doesn't make sense to disable it by default
[12:58] <ogra> the initial problem was that the suspend button didnt work for everyone ...  if that has changed we should take upstream defaults "suspend"
[12:59] <mdz> ogra: please revert to the upstream default
[12:59] <ogra> it does, as long as you can enable it :)
[12:59] <ogra> yup
[12:59] <infinity> mdz: It does both the migration and sets RESUME, yes, but our installer(s) also set RESUME in their own fashion so the problem is only visible if you're installing initramfs-tools outside the installer.
[12:59] <tfheen> mdz: any suggestions on what we should do with the NM bug? bug 63975
[12:59] <Ubugtu> Malone bug 63975 in network-manager "Please sponsor network-manager upload" [High,Confirmed]  http://launchpad.net/bugs/63975
[01:00] <mdz> infinity: oh? I thought we intentionally moved that from the installer to initramfs-tools
[01:00] <mdz> tfheen: the one with the unhelpful summary?
[01:00] <tfheen> mdz: I'm inclined to just untarget it since it's so late.
[01:00] <infinity> mdz: Which, since it's not a base package or anything, is perfectly doable, both by Ubuntu users, and by derivatives, but not a normal use case for the average "using  aCD" folk.
[01:00] <tfheen> mdz: that's an accurate description, yes.  The problem is ndiswrapper and n-m aren't friends, it seems.
[01:01] <infinity> mdz: I can't be positive if d-i still does it (Kamion?), but ubiquity clearly must, since the RESUME partition is chosen long after initramfs-tools has been installed.
[01:01] <infinity> mdz: Anyhow, I spent a day in vmware, doing install tests and upgrade tests, full-well realising how close we were to RC, and it all seems quite happy with itself.
[01:02] <mdz> tfheen: definitely not an issue for RC, but worth keeping on the radar if we can get an authoritative opinion on it
[01:02] <mdz> tfheen: the attached patch does more than just disable the ndiswrapper bits
[01:02] <pitti> mdz, tfheen: do you deem bug 66532 as important enough for edgy milestone? (this worked until recently)
[01:02] <Ubugtu> Malone bug 66532 in debian-installer "selected German in gfxboot, got English installer" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66532
[01:03] <mdz> pitti: yes
[01:03] <mdz> pitti: does it work on the desktop CD?
[01:04] <tfheen> mdz: it fixed the issue for a friend of mine who needs ndiswrapper, so I know it's not _totally_ broken at least.
[01:04] <pitti> mdz: I'll check in half an hour, both of my boxes are busy with alternate installs
[01:04] <tfheen> mdz: but then, I'm wary of doing uploads of any packages we don't have to at this point.
[01:04] <mdz> tfheen: even if it fixes that particular issue, the fact that it does more than what is described makes me disinclined to trust it
[01:05] <mdz> if ndiswrapper is the issue, then we should change only that
[01:05] <tfheen> mdz: http://librarian.launchpad.net/4821656/nm-patch seems fairly clean, though?  It does move a bit of code from a later patch to the workarounds patch, but that doesn't change functionality.
[01:05] <mdz> -+	else if (!strcmp (kernel_driver, "ndiswrapper"))
[01:05] <mdz> -+		wpa_driver = "ndiswrapper";
[01:05] <mdz> ++	else if (!strcmp (kernel_driver, "hostap_pci") || !strcmp (kernel_driver, "hostap_cs") || !strcmp (kernel_driver, "hostap_plx"))
[01:05] <mdz> ++		wpa_driver = "hostap";
[01:05] <mdz> those look like entirely unrelated changes
[01:06] <Q-FUNK> it appears that 'upstart' cannot be used on a host with mixed pinned APT.  it lacks the "Essential: Yes" header in the control file.
[01:07] <tfheen> mdz: it moves the later changes from debian/patches/11-j-hostap-supplicant-driver.patch ; probably somebody who used dpatch-edit-patch and wasn't careful enough.
[01:07] <mdz> oh, I see
[01:08] <mdz> tfheen: if that's cleaned up so that the only change is the ndiswrapper bit, I'm OK with that
[01:08] <tfheen> mdz: ok.  Now or post-rc?
[01:09] <mdz> tfheen: now, unless we're otherwise ready to build candidates
[01:10] <pitti> carlos: can you please take a look at bug 63344? it would be nice to fix the export by Friday
[01:10] <Ubugtu> Malone bug 63344 in language-pack-pl "rosetta truncated plural form for pl and that breaks python apps" [Medium,In progress]  http://launchpad.net/bugs/63344
[01:10] <carlos> pitti: I'm already on it, it's a duplicate of #2322
[01:10] <pitti> carlos: splendid, thanks!
[01:12] <ogra> tfheen, mdz, http://people.ubuntu.com/~ogra/g-p-m.debdiff (just testbuilding)
[01:12] <infinity> mdz: Nah, there are still builds trickling in and such, one more publisher run or two won't hurt (especially if someone drives by hand)
[01:12] <mdz> ogra: ok
[01:12] <mdz> infinity: rumour has it that the publisher is much faster now
[01:12] <infinity> tfheen: And yes, I can drive LP by hand for a while tonight, just say the word if you want speed.
[01:13] <infinity> mdz: Yes, hnce why driving by hand is a win now.
[01:13] <infinity> mdz: One a good day, it can complete in 20-25 mins.
[01:13] <mdz> it was a win before, too
[01:13] <infinity> It was less of wa win when it was hobbling along at the 45 minute mark. :)
[01:14] <zul_> infinity: pong
[01:14] <infinity> responseTime++
[01:14] <tfheen> ogra: approved.
[01:14] <infinity> zul_: Will you be around for ~10 mins?  I'm running to 7-11 for iced coffee and other such necessities. :)
[01:14] <zul_> infinity: sure
[01:14] <ogra> tfheen, great, i'll upload as soon as i know it builds properly :)
[01:15] <infinity> (literally running)
[01:19] <madduck> aye
[01:19] <madduck> sorry. this was *totally* unwanted
[01:20] <jdub> http://weihwa.feedback.googlepages.com/seriesoftubes
[01:23] <tfheen> mvo,doko: https://launchpad.net/distros/ubuntu/+source/gcj-4.1/+bug/64395 ; what's up here?  
[01:23] <Ubugtu> Malone bug 64395 in gcj-4.1 "Update manager aborts on eclipse-platform-gcj when updating from Dapper to Edgy" [Undecided,Unconfirmed]  
[01:23] <tfheen> it's targetted for 6.10
[01:23] <mdz> last I heard they were unable to reproduce it
[01:25] <tfheen> Kamion: https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/66533 should be fixed by new cdebconf-keystep?  Requires yet another d-i upload?
[01:25] <Ubugtu> Malone bug 66533 in debian-installer "keyboard detection loops" [Undecided,Unconfirmed]  
[01:25] <Kamion> infinity: d-i (specifically base-installer) still does it
[01:26] <Kamion> tfheen: correct, same issue I saw
[01:26] <tfheen> Kamion: are you on top of https://launchpad.net/distros/ubuntu/+source/debian-installer/+bug/66532 too?  (If you're already watching the RC list, tell me and I won't nag you)
[01:26] <Ubugtu> Malone bug 66532 in debian-installer "selected German in gfxboot, got English installer" [Undecided,Unconfirmed]  
[01:27] <doko_> tfheen: unreproducible for me; gij-4.1 depends on libgcj7-0, it's unclear why the library is not found
[01:27] <tfheen> doko_: are there circular depends involved?
[01:27] <doko_> in gij-4.1? no
[01:30] <Kamion> tfheen: only just saw it, will investigate
[01:30] <Kamion> tfheen: if you didn't see, powerpc ubiquity is still broken
[01:30] <Kamion> tfheen: I'm proposing this change to ubiquity/scripts/install.py to fix it:
[01:30] <Kamion> -            self.chrex('update-initramfs', '-u')
[01:30] <Kamion> +            self.chrex('update-initramfs', '-c', '-k', os.uname()[2] )
[01:31] <tfheen> Kamion: for all arches or just ppc?
[01:31] <Kamion> just powrpc
[01:31] <Kamion> powerpc
[01:31] <Kamion> I've tested the above change on i386
[01:31] <Kamion> pitti is going to test it on powerpc
[01:32] <tfheen> ok; go ahead.
[01:32] <tfheen> looks good to me
[01:33] <Kamion> sabdfl: will you be able to make the CC meeting today? I would like to be excused on the grounds that I need my full attention for the multiple edgy-RC issues I'm trying to deal with at the moment
[01:33] <Kamion> I don't know if mako can be there, thoug
[01:33] <Kamion> h
[01:33] <Kamion> so if I need to be, so be it
[01:35] <doko_> tfheen: please approve http://people.ubuntu.com/~doko/edgy/python-central.debdiff
[01:36] <tfheen> doko_: looks good to me.
[01:37] <mdz> tfheen: that was fast; I hadn't even finished reading it yet
[01:37] <doko_> tfheen: ok, waiting for mvo to have a small review
[01:37] <tfheen> doko_: yeah, I was going to add "but I don't know python-central, so it'd be good to have somebody else look at it too"
[01:38] <pitti> weird - I could have sworn http://cdimage.ubuntu.com/daily[-live] / had 20061017 this morning
[01:39] <mdz> pitti: and now?
[01:39] <infinity> doko_: Will that fix the zope removal bug?
[01:39] <infinity> (looks like it should..)
[01:39] <ogra> mdz, 20061016
[01:39] <tfheen> doko_: have either of you been able to reproduce the problem?
[01:39] <doko_> infinity: zope removal?
[01:39] <mdz> pitti: lithium has 20061017
[01:39] <ogra> (seems we're moving backwards in time :) )
[01:39] <mdz> problem with one of the mirrors perhaps?
[01:39] <infinity> [...] + read t n
[01:39] <infinity> + case "$t" in
[01:39] <infinity> + rmdir --ignore-fail-on-non-empty /usr/lib/python2.3/site-packages/zope/interface/common/tests
[01:39] <infinity> dpkg: error processing python-zopeinterface (--purge):
[01:40] <infinity>  subprocess pre-removal script returned error exit status 1
[01:40] <pitti> mdz: only 20061016 for me
[01:40] <infinity> doko_: ^^^ While removing python-zopeinterface from chroots.
[01:40] <mdz> pitti: it shows 20061017 for me
[01:40] <mdz> on cdimage as well
[01:40] <infinity> doko_: Looks like pycentral is involved somehow.
[01:40] <pitti> weird, not for me
[01:40] <pitti> $ host cdimage.ubuntu.com
[01:40] <pitti> cdimage.ubuntu.com has address 195.248.90.25
[01:40] <pitti> cdimage.ubuntu.com has address 195.248.90.24
[01:40] <doko_> infinity: do you have a log?
[01:40] <ogra> for me neither
[01:41] <infinity> doko_: I'll put the whole output online.
[01:41] <pitti> mdz: ah, .25 has the latest image for me, .24 not
[01:41] <mdz> pitti: .24 is out  of date, e.25 is ok
[01:41] <ogra> weird
[01:41] <infinity> doko_: I just added set -x to the prerm before purging.
[01:41] <tfheen> mdz: http://err.no/patches/network_manager_remove_ndiswrapper_specialcase.diff
[01:41] <mdz> yep
[01:41] <mdz> elmo: see above; one of the cdimage mirrors has a problem
[01:41] <tfheen> mdz: I have at least one verification that binaries built with that patch works where the current edgy version doesn't.
[01:42] <mdz> tfheen: looks good
[01:42] <infinity> doko_: http://cerberus.0c3.net/~adconrad/argh.log
[01:42] <cbx33> 20061016 for me
[01:42] <tfheen> mdz: thanks; uploaded.
[01:42] <janimo> Riddell: is the kubuntu human theme shipped by hk-default-settings?
[01:43] <janimo> s/hk/kubuntu/
[01:44] <elmo> mdz: fixing
[01:48] <elmo> I don't suppose someone could fix LP #24519, could they?  It's a trivial patch and cricket is pretty useless without it
[01:49] <janimo> bug 24519
[01:49] <Ubugtu> Malone bug 24519 in cricket "cricket: Completely broken with latest rrdtool package 1.2.11-0.4" [Unknown,Fix released]  http://launchpad.net/bugs/24519
[01:50] <elmo> how does that thing not recognise "LP #" yet? :P
[01:50] <rideout> dholbach: since Riddell is not here, could you fix the qt4 packages, Riddell submitted a new version, but included a few makefiles that should have been generated and thus the build failed. I can explain the changes that need to be made
[01:55] <Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/localechooser.diff for bug 66532
[01:55] <Ubugtu> Malone bug 66532 in debian-installer "selected German in gfxboot, got English installer" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66532
[01:55] <StevenK> Heh, there's a bug in Ubugtu too.
[01:56] <StevenK> It reports [Unknown,Fix released] , but that's the Debian status
[01:56] <Kamion> without that patch it goes "process preseeding, fetch previous language, ask for language, oh, hey, it's the same as the previous one, don't do anything"
[01:57] <pitti> Kamion: you rock!
[01:57] <pitti> fixing bugs faster than I can whine about them
[01:58] <tfheen> Kamion: ok, looks sane to me.
[01:58] <ogra> oh, what a bad date to run a CC meeting
[01:58] <dholbach> rideout: I can have a look at it after lunch - if you give me instructions to a query, that'd be a good start - brb
[01:59] <janimo> dholbach: hi, I took the liberty of subscribing you to bug 65870 :)
[01:59] <Ubugtu> Malone bug 65870 in human-cursors-theme "xfce crashes repeatedly after changing icon theme to default" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65870
[02:00] <janimo> dholbach: as it looks like it is fixable in human-cursors-theme
[02:00] <mdz> ogra: that reminds me to defer next week's TB
[02:00] <rideout> dholbach: i'm sending you an email right now
[02:00] <dholbach> rideout: thanks
[02:00] <mdz> sabdfl,mjg59,Keybuk: OK with you to not hold TB next week due to the release?
[02:00] <dholbach> janimo: i'll take a look, after lunch
[02:00] <janimo> dholbach: bon appetit
[02:00] <mjg59> mdz: Sure
[02:01] <mjg59> mdz: Though do we then actually have a TB before our terms end?
[02:02] <mdz> mjg59: unclear; afaik that's on the agenda for UDS rather than an online meeting
[02:02] <infinity> Argh.
[02:03] <infinity> Riddell: qt4-x11 is FTBFS.
[02:03] <tfheen> didn't the previous version just build?  And this one just changed a depends field?
[02:03] <ogra> tfheen, infinity, see dholbach/rideout conversation above
[02:04] <infinity> tfheen: No, this was a new upload after the depends change.
[02:04] <rideout> tfheen: riddell submitted an unclean build, it had makefiles for his machine, that should be generated by the configure script
[02:04] <infinity> ogra: Ahh, thanks, I'm not glued to scrollback.
[02:05] <mdz> tfheen: wasn't a diff submitted for review which only changed a dependency field?
[02:05] <Kamion> 22:55 < tfheen> I _think_ qt4-x11 is ok; Riddell didn't scream when dholbach uploaded it.
[02:05] <tfheen> Kamion: and then Riddell said he was happy with it.
[02:05] <Kamion> unless there was a later one?
[02:06] <Kamion> oh, yeah, this morning
[02:06] <Kamion> as soon as LP came up
[02:06] <infinity> mdz: That was ubuntu3
[02:06] <infinity> mdz: ubuntu4 was this:
[02:06] <infinity> 02:24 < Kamion> tfheen: another qt4-x11 upload in unapproved, from Riddell
[02:06] <infinity> 02:24 < Kamion> +  * Fix typo in debian/rules -qt-sql-slite to -qt-sql-sqlite
[02:06] <infinity> 02:24 < Kamion> +  * Add missing plugin files to libqt4-gui.install and qt4-designer.install
[02:06] <infinity> 02:24 < tfheen> Kamion: approved.
[02:07] <infinity> Anyhow.
[02:07] <infinity> rideout: Care to post a diff somewhere about how to unbugger this?
[02:07] <infinity> rideout: I'd like to get it fixed ASAP.
[02:08] <infinity> Kamion: Do we want the ttf-bpg-georgian-fonts udeb in main?
[02:08] <infinity> 9Yes, it finally built)
[02:08] <infinity> s/9/(/
[02:08] <Kamion> infinity: no
[02:08] <Kamion> it's only for d-i/gtk
[02:08] <StevenK> Er.
[02:09] <rideout> infinity: i just sent dholbach an email with the fix, here is a copy http://pastebin.ca/206437
[02:09] <infinity> Kamion: Kay, universifying it, then.
[02:09] <Kamion> rideout: damn, I noticed that in the queue and should have commented on it at the time
[02:09] <Kamion> I just assumed it was qmake noise
[02:10] <rideout> Kamion: somehow "make clean" must have gone foobar on riddells machine
[02:11] <dholbach> rideout, Kamion: I'll do a testbuild with the fix, then do an upload.
[02:11] <dholbach> rideout: Thanks a lot for investigatin!
[02:11] <dholbach> g
[02:11] <infinity> dholbach: Thanks.
[02:11] <rideout> thanks
[02:11] <sabdfl> mdz: fine by me
[02:13] <infinity> tfheen: Has you n-m upload seen more eyes than your own? (ie: should I accept it?)
[02:13] <ogra> janimo, /usr/share/icons/default/index.theme isnt in the -cursors-theme package ... 
[02:13] <tfheen> infinity: mdz was fine with it and I have at least one user whose network it fixed, so I think "yes" is fine.
[02:14] <ogra> no idea where you got that from, but i dont have it on any edubuntu systems (with -cursor-themes installed)
[02:14] <infinity> tfheen: Alright, accepting.
[02:16] <ogra> tfheen, is my g-p-m upload still sitting in the queue ? i dotn see it on -changes
[02:17] <Kamion> all livefses rebuilt; rebuilding live ISOs
[02:17] <mdz> infinity: yes, I reviewed it
[02:17] <tfheen> ogra: I presume so, yes.
[02:17] <tfheen> infinity: how's the queue looking?
[02:18] <tfheen> elmo: http://err.no/patches/cricket_read_new_rrdtool_x86.diff makes you happy?
[02:20] <elmo> tfheen: that'd be great, thanks
[02:20] <tfheen> elmo: just waiting for Adam to tell me that he's happy with it too, since it touches the server CD.
[02:22] <janimo> ogra: it is installed by postinst
[02:22] <ogra> janimo, not here it seems, neither on upgraded system nor on new installs
[02:23] <ogra> and it shouldnt btw ... its a theme file that belongs into a theme not into a cursor theme 
[02:24] <janimo> ogra, do you have human-cursors-theme?
[02:24] <ogra> yes, we use it by default in edubuntu
[02:24] <infinity> tfheen: 
[02:24] <ogra> hmm, i have /etc/alternatives/x-cursor-theme -> /usr/share/themes/Human/cursor.theme
[02:24] <infinity>   110004 | S- | gnome-power-manager  | 2.16.1-0ubuntu3      | 55 minutes
[02:24] <infinity>          | * gnome-power-manager/2.16.1-0ubuntu3 Component: main Section: gnome
[02:24] <infinity>   110003 | S- | optcomplete          | 1.2-5ubuntu1         | 1 hour 20 minutes
[02:24] <janimo> the file is installed here, and the invocation is there in the source package (0.3)
[02:24] <infinity>          | * optcomplete/1.2-5ubuntu1 Component: universe Section: python
[02:24] <infinity>   109987 | S- | gnome-panel          | 2.16.1-0ubuntu3      | 2 hours 10 minutes
[02:24] <infinity>          | * gnome-panel/2.16.1-0ubuntu3 Component: main Section: gnome
[02:24] <infinity>   109950 | S- | ubuntu-docs          | 6.10.2               | 3 hours 10 minutes
[02:25] <infinity>          | * ubuntu-docs/6.10.2 Component: main Section: text
[02:25] <tfheen> infinity: g-p-m is fine if it's from ogra.
[02:25] <infinity> tfheen: And yes, please fix elmo's bug, keeping elmo happy helps me keep my job. :P
[02:25] <infinity> tfheen: It is.
[02:25] <tfheen> infinity: gnome-panel is from dholbach and updates an URL, ubuntu-docs is a general update, also from dholbach?
[02:25] <tfheen> if so, approved.
[02:25] <tfheen> infinity: cricket uploaded.
[02:25] <infinity> tfheen: ubuntu-docs is from mdke
[02:26] <infinity>  ubuntu-docs (6.10.2) edgy; urgency=low
[02:26] <infinity>  .
[02:26] <infinity>    * Adding translations for all documents
[02:26] <dholbach> I sponsored it
[02:26] <infinity> Right, then. :)
[02:26] <seb128> just curious, how much spaces do translations take?
[02:27] <pitti> seb128: you mean, how many langpacks are on the CDs?
[02:27] <tfheen> Riddell: did you or somebody else target https://launchpad.net/distros/ubuntu/+source/katapult/+bug/49901 and what's happening with it?
[02:27] <Ubugtu> Malone bug 49901 in katapult "Katapult slows down to a near crawl when amarok is open" [Medium,Confirmed]  
[02:27] <ogra> do we mail the DD by default now ?
[02:27] <seb128> pitti: no, the ubuntu-docs upload mentioned some lines up
[02:27] <pitti> tfheen: speaking about langpacks, many CDs have plenty of space; can I fill them with some langpacks (leaving 10 MB grace space?)
[02:28] <pitti> ah
[02:28] <seb128> ogra: the maintainer is giskard
[02:28] <ogra> seb128, yes
[02:28] <Kamion> pitti: we haven't done the final langpack update yet
[02:28] <tfheen> pitti: what Colin says; let's hold it off.
[02:28] <Kamion> pitti: I'd be a bit reluctant to fill up the CDs until we know how big they're going to be
[02:28] <pitti> Kamion: right; so Saturday would be a good time
[02:28] <ogra> seb128, but he's in the To: line of the reciept mail i got from LP
[02:28] <ogra> that appears wrong to me ...
[02:28] <Kamion> if we're updating langpacks post-RC anyway, then yes
[02:29] <giskard> ogra: hey :)
[02:29] <giskard> hello seb128 :)
[02:29] <ogra> giskard, yo
[02:29] <dholbach> seb128: translated ubuntu-docs is HUGE
[02:29] <giskard> hello dholbach :)
[02:29] <Riddell> tfheen: I didn't target it
[02:29] <Kamion> pitti: oh yes, and I'd like to know how big the new ubuntu-docs is going to be ...
[02:29] <dholbach> hi giskard - changed the nick?
[02:29] <pitti> Kamion: oh, I thought we agreed to doing this at Friday? if not, how and when do you think we should decide that?
[02:29] <Kamion> pitti: langpack update = Friday = post-RC
[02:30] <seb128> hi giskard
[02:30] <giskard> dholbach: yes :) kristog is deprecated ;)
[02:30] <seb128> dholbach: how huge?
[02:30] <dholbach> Installed-Size: [-2192-]  {+31352+}
[02:30] <Riddell> tfheen: in the comments mez says he's working on a patch, but I don't consider it a major issue
[02:30] <Kamion> dholbach: what about Size?
[02:30] <seb128> dholbach: and the .deb ?
[02:30] <pitti> Kamion: ah, I misinterpreted the 'if', sorry
[02:30] <dholbach> the debs went from: 327544 to 5287886
[02:30] <seb128> utch
[02:30] <Kamion> pitti: sorry, yes, s/if/since/
[02:30] <ogra> seb128, i'm not worried about the fact giskard gets the mails for my uploads, i'm just wondering if any ulpoad i do now generally mails the DD
[02:30] <seb128> ogra: ah, that would be weird
[02:31] <ogra> yes
[02:31] <giskard> ogra: feel free to mail for important changes 
[02:31] <tfheen> Riddell: Unless you mind, I'll untarget it, then?
[02:31] <ogra> giskard, you're getting the reciept mails from launchpad anyway it seems
[02:31] <Kamion> well, we do have space for that extra 5MB for Ubuntu at present
[02:32] <giskard> ogra: yeah :)
[02:32] <Kamion> I'd be inclined to accept it since we were only going to fill it up with translations anyway, but I'd like to hear from the rest of the release team too
[02:32] <Kamion> dholbach: can you check to make sure it doesn't contain the installation guide?
[02:32] <Kamion> that's in the source, but shouldn't be in the .deb
[02:32] <Riddell> tfheen: fine with me
[02:38] <Kamion> tfheen: is anyone doing anything with that imake upgrade bug?
[02:39] <Kamion> tfheen: actually I wonder if it will go away for most people due to xutils depending on xutils-dev
[02:39] <Kamion> I think that might have been why it broke
[02:39] <tfheen> Kamion: I though mvo was going to do it?  Or it should go away as you said.
[02:39] <Kamion> aha, yes, old xutils had:
[02:39] <Kamion> Depends: imake (>= 1:1.0.0) | xmkmf
[02:39] <Kamion> so the Provides wouldn't have been enough
[02:40] <Kamion> xutils was imake's only rdepends
[02:41] <dholbach> Kamion:   grep -i install /var/lib/dpkg/info/ubuntu-docs.list    only lists bits in the desktop-guide and server-guide
[02:42] <tfheen> ogra: you're aware of https://launchpad.net/distros/ubuntu/+source/gnome-power-manager/+bug/60442 ?
[02:42] <Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  
[02:44] <ogra> tfheen, "... partially diagnosed upstream ..." doesnt seem like a RC exception bug to me
[02:44] <Kamion> dholbach: ok
[02:44] <Kamion> thanks
[02:44] <dholbach> de rien
[02:44] <Riddell> dholbach: are you working on qt4?
[02:45] <infinity> seb128: You around?
[02:45] <seb128> infinity: yep
[02:45] <dholbach> Riddell: yes, did the suggested fix and now it's testbuilding
[02:45] <infinity> seb128: https://launchpad.net/distros/ubuntu/+source/gnome-system-tools/+bug/9208
[02:45] <Ubugtu> Malone bug 9208 in gnome-system-tools "Samba upgrade failure due to broken rc.d symlinks" [High,Fix released]  
[02:45] <seb128> ah, that bug
[02:45] <seb128> we have it since hoary or something like that
[02:45] <infinity> seb128: Are you familiar enough with the g-s-t source to know A) how that bug was originally happening, and B) how it's *still* happening?
[02:45] <infinity> seb128: All the grep-fu in the world, and I still can't nail it down.
[02:46] <infinity> seb128: And I can't reproduce it to save my life, though users get bitten by it all the time.
[02:46] <seb128> infinity: g-s-t is only the fronted, the code is to system-tools-backend probably
[02:46] <infinity> (of course, none of them know HOW they're being hit by it, since it's a sleeper bug, so cause and effect are tough)
[02:46] <mvo> tfheen: wasn't rodarvus going to add a transitional package to fix the imake upgrade problem? at least I thought so 
[02:46] <seb128> system-tools-backends rather
[02:46] <Kamion> mvo: I think it may not be necessary any more
[02:47] <Kamion> mvo: xutils used to versioned-depends: imake, but now depends: xutils-dev
[02:47] <Kamion> I think that might be enough to fix it
[02:47] <seb128> infinity: I'm not sure it has been fixed though
[02:47] <mvo> yeah, that sounds good. I will do a dist-upgrade test to verify that
[02:47] <Kamion> mvo: I can do one here
[02:47] <cbx33> hmm....my tosh laptop won;t recognise when the ac power is disconnected
[02:47] <Kamion> and/or you can, if you prefer
[02:48] <infinity> seb128: I'm positive it hasn't been fixed. :)
[02:48] <ogra> tfheen, the battery_status_changed_primary() function needs to be rewritten, i dont think thats something we want to do now ... and i dont see why this is a regression from dapper ... it seems it never handled that right .... 
[02:48] <mvo> Kamion: feel free :) 
[02:48] <seb128> infinity: k :/
[02:48] <tfheen> ogra: can you please discuss that with mjg59 either now or in the bug?
[02:48] <seb128> infinity: are we sure it comes from g-s-t or that's a random guess on a potential package?
[02:48] <infinity> seb128: I'm sure it's not coming from samba, that's the best I can do.
[02:48] <ogra> mjg59, why is bug 60442 a regression ? it seems it never handled such cases right (according to the upstream bug)
[02:48] <Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  http://launchpad.net/bugs/60442
[02:48] <cbx33> oh maybe it has.....seems very slow on the uptake
[02:49] <infinity> seb128: I can't think all that many things enable/disable samba on a whim.
[02:49] <Riddell> thanks dholbach 
[02:49] <dholbach> Riddell: anytime
[02:49] <infinity> seb128: And if it was a more general thing (like  rnulevel editor), the bugs would be scattered across other packages.
[02:49] <popey> cbx33: my hp takes a while to spot that power has gone, I thought that was working as designed
[02:49] <infinity> seb128: So, it's an educated guess, but not a for sure thing.
[02:49] <seb128> right
[02:49] <popey> cbx33: I have seen issues with machines that poll too often
[02:50] <mjg59> ogra: Because dapper doesn't appear to have that problem
[02:50] <cbx33> popey: yeh it is picking it up, but it is slow
[02:50] <popey> cbx33: takes about 5-10 seconds here
[02:50] <ogra> mjg59, according to hughsies comment in the upstream bug it never handled two batteries
[02:51] <mjg59> ogra: Shrug. It doesn't happen in dapper. It's a regression.
[02:51] <ogra> (i cant compare since i dont have any machines with two batteries)
[02:53] <mvo> doko: python-central diff looks good
[02:53] <zul_> infinity: ping
[02:53] <tfheen> seb128: system - administration - anything gives me permission denied on my laptop.
[02:53] <ogra> mjg59, since you set the milestone for it, any suggestion how to fix that without rewriting the battery_status_changed_primary function completely ?
[02:53] <seb128> tfheen: are you member of the admin group?
[02:53] <ogra> i dont see how we could fix that today
[02:54] <tfheen> seb128: no, this machine predates that group.
[02:54] <tfheen> it was originally installed with hoary, iirc.
[02:54] <seb128> tfheen: ok, that's why
[02:54] <infinity> seb128: Another point to note is that googling for the bug symptoms (K09samba dangling symlink) only returns hits for Ubuntu users, no Debian users, so the bug is in a patch we're carrying.
[02:55] <infinity> seb128: (At least, I'd guess so)
[02:55] <seb128> infinity: like the shares-admin patch to install samba
[02:55] <seb128> tfheen: https://launchpad.net/distros/ubuntu/+source/gnome-system-tools/+bug/59946
[02:55] <infinity> seb128: Yeah...
[02:55] <Ubugtu> Malone bug 59946 in gnome-system-tools "run action as root without prompting for a password" [High,Confirmed]  
[02:56] <Trewas> mdz: sorry to bother, but old and closed bug 14575 is now back as bug 61989, and you fixed the old bug for hoary... shortly: dhclient.conf was again changed to ask for interface-mtu which some routers get wrong -> network not working. just mentioning it here because it already has few duplicates, probably a lot more if edgy is released with it
[02:56] <Ubugtu> Malone bug 14575 in dhcp3 "interface-mtu change from yesterday hoses the network interface" [Medium,Fix released]  http://launchpad.net/bugs/14575
[02:56] <Ubugtu> Malone bug 61989 in dhcp3 "[Edgy dhclient regression]  error: Message too long" [Undecided,Confirmed]  http://launchpad.net/bugs/61989
[02:57] <mdz> Trewas: the description says dhcp.conf but surely ti means dhclient.conf
[02:57] <Trewas> mdz: yes, dhclient.conf
[02:58] <pitti> Kamion: ubiquity 1.2.3 plus the update-initramfs patch from above works great on ppc now; you rock!
[02:58] <mdz> hmm, that change was propagated to Debian and we re-inherited it
[03:02] <Kamion> pitti: hooray
[03:02] <pitti> erm, I'm afraid we don't even have that, have we?
[03:03] <Kamion> the only other change in 1.2.4 was to incorporate the localechooser fix for your preseeding bug
[03:05] <tore> hello.  can I (being a debian developer), upload packages straight to ubuntu?
[03:05] <ogra> tore, no
[03:05] <tfheen> tore: no, you need to go through MOTU and such, but it's a quicker process for people who are already DDs.
[03:05] <tore> MOTU?
[03:05] <ogra> mdz, want me to care for dhcp3 and remove the "interface-mtu" from dhclient.conf ?
[03:05] <ogra> tore, masters of the universe
[03:05] <tfheen> tore: Masters of the Universe; see http://wiki.ubuntu.com/MOTU
[03:06] <Kamion> tore: MOTU -> masters of the universe -> those people who can upload to Ubuntu's "universe" and "multiverse" components
[03:06] <mdz> ogra: I'm investigating
[03:06] <Kamion> i.e. packages not directly supported by Canonical; it's the outer ring of the development team
[03:06] <ogra> oki
[03:07] <tore> Kamion: yep.  my munin packages are there, I just uploaded a new version to sid and thought it would be good if it was added to etch as well, as it contains a fix for the /var/run/foo-goes-missing behaviour in ubuntu
[03:07] <Kamion> tore: of course when we're in the phase of development where we're syncing regularly from Debian, Debian developers often don't need to upload directly to Ubuntu, unless it's a package that has been changed in Ubuntu
[03:07] <Mirv> tore: https://wiki.ubuntu.com/UbuntuForDebianDevelopers
[03:07] <Kamion> tore: edgy is deep-frozen for release shortly
[03:07] <mdz> ogra: yes, i think that's what we need to do.  please do
[03:07] <Kamion> although /var/run fixes are still acceptable
[03:07] <tore> oki.
[03:07] <Kamion> tore: anyway, #ubuntu-motu should be able to help here
[03:07] <tore> Mirv: sweet, thanks
[03:07] <ogra> mdz, greyt, will do ...
[03:07] <Kamion>      munin | 1.2.4-1ubuntu1 | edgy/universe | source, all
[03:07] <tfheen> and munin is universe, so it's not that frozen
[03:08] <Kamion> +munin (1.2.4-1ubuntu1) dapper; urgency=low
[03:08] <Kamion> +
[03:08] <Kamion> +  * Added patch from Dagfinn Ilmari Mannsker to ensure that directory
[03:08] <Kamion> +    for PID file exists when munin is started (Closes: Malone #33847)
[03:08] <Kamion> +
[03:08] <Ubugtu> Malone bug 33847 in munin "Munin node fails to start after reboot" [High,Fix released]  http://launchpad.net/bugs/33847
[03:08] <Kamion> + -- Benjamin Montgomery <bmontgom@montynet.org>  Fri, 17 Mar 2006 21:09:47 -0600
[03:08] <Kamion> tore: looks like we already have that fix, but you incorporating it means that we can drop our modifications next release
[03:08] <tore> Kamion: yes, but that only handles the munin-node package, for the munin one you need to add this line to /etc/cron.d/munin:
[03:08] <tore> @reboot         root  if [ ! -d /var/run/munin ] ; then /bin/bash -c 'perms=(`/usr/sbin/dpkg-statoverride --list /var/run/munin`); mkdir /var/run/munin; chown ${perms[0] :-munin}:${perms[1] :-root} /var/run/munin; chmod ${perms[2] :-0755} /var/run/munin'; fi
[03:09] <tore> (I've also improved the init-script workaround to respect the statoverride)
[03:09] <Kamion> tore: ah, right; #ubuntu-motu should indeed be able to help then
[03:09] <mdz> eek
[03:10] <tore> Kamion: cheers, I'll head over there
[03:12] <mdz> sfllaw: ping
[03:12] <tfheen> mdz: can we have a half-release milestone?  Something for bugs which have bit us during the release crunch, but which aren't critical enough that they're RC.
[03:13] <tfheen> 7.04-early or something like that.
[03:13] <mdz> tfheen: we can't create milestones for 7.04 until edgy+1 is created in LP
[03:13] <infinity> mdz: But then we can have arbitrary ones?
[03:13] <mdz> of course, that was supposed to happen by now...
[03:13] <mdz> infinity: yes, I can create them at least
[03:14] <StevenK> I don't know what it is, but the version number 7.04 looks wrong...
[03:14] <infinity> mdz: Basically, what tfheen and I were discussing was a "take a few days early in the release to fix these bugs that bit us last release, BEFORE it's too late, too hard, and too intrusive"
[03:14] <elmo> mdz: sabdfl said last night it was blocked on you explaining fawn or some such
[03:14] <mdz> infinity: yes, I understand and agree
[03:14] <mdz> elmo: that is utter crap
[03:15] <fabbione> StevenK: buildd is still munging on it... 
[03:15] <StevenK> Oh geez.
[03:17] <fabbione> pitti: ping?
[03:17] <pitti> fabbione: hi
[03:17] <fabbione> pitti: did you already uploaded a fix for shadow?
[03:17] <pitti> fabbione: sure, this morning
[03:17] <fabbione> what version?
[03:20] <pitti> fabbione: shadow_4.0.16-2ubuntu3_source.changes
[03:20] <fabbione> ok.. it has not been accepted yet..
[03:21] <Kamion> 08:25:20 DEBUG      Subject: Accepted shadow 1:4.0.16-2ubuntu3 (source)
[03:21] <Kamion> where did it go?
[03:22] <Kamion> oh, no, that was the one I rejected
[03:22] <Kamion> pitti: did you definitely reupload?
[03:23] <pitti> Kamion: aah, wait, I have an already existing .upload filee on chinstrap
[03:23] <infinity> Ah-ha.,
[03:24] <pitti> Kamion: I got an Accepted mail, but apparently that was from the previous upload
[03:24] <infinity> Kamion, tfheen : elmo's reimported the archive for another autotest run for me, but I intentionally have the buildds disabled right now to give you livefs breathing room.  If you'd prefer I hold off on autotest round 2 until after RC, let me know.. If not, I'll turn it on and you can contend for CPU/disk.  Your call.
[03:25] <pitti> Kamion: confirmed uploaded now
[03:25] <pitti> fabbione: thanks for the poke
[03:25] <tfheen> infinity: I'm ok with autotest now, actually, we can always bump the priority of non-autotest builds.
[03:26] <fabbione> pitti: no problem.. i just noticed that it was FTBFS in this second run and i couldn't understand why
[03:27] <infinity> tfheen: Err, you misunderstand.
[03:28] <infinity> tfheen: autotest runs in dak, which means it's on the livefs buildds.
[03:28] <infinity> tfheen: So, if I'm building, say, gcc-4.0 in autotest, you get to fight for cpu/disk when doing livefs builds.
[03:28] <tfheen> infinity: oh, point.
[03:28] <tfheen> infinity: oh well, post-rc should be fine, then
[03:29] <infinity> tfheen: Kay.  I'll make sure it's on as soon as I see (or help draft) an RC announce. :)
[03:34] <Tonio_> tfheen, infinity: I have an upload to commit to universe, missing dep on binary package k9copy, is one of you able to approve ?
[03:35] <dholbach> janimo: I'm not so happy about renaming files
[03:35] <tfheen> Tonio_: I don't do universe; talk to dholbach 
[03:35] <Tonio_> tfheen: okay
[03:35] <Tonio_> dholbach: ?
[03:35] <dholbach> janimo: but we can make the 'theme' hidden
[03:35] <dholbach> Tonio_: sure, go ahead - which dep is that?
[03:36] <gnomefreak> whats the chances initramfs-tools could affect a net connection?
[03:36] <Tonio_> dholbach: mencoder... that'll cause the binary package to -> multiverse
[03:36] <dholbach> Tonio_: not sure, is that an automatic process?
[03:36] <Tonio_> but that's a change in 1.0 version, now uses mencoder for mpeg2, we have to do with it
[03:36] <fabbione> Riddell, doko: bug #66561
[03:36] <Ubugtu> Malone bug 66561 in kdebindings "FTBFS in edgy [kdebindings] " [High,Confirmed]  http://launchpad.net/bugs/66561
[03:36] <Tonio_> dholbach: afaik I think it is automatic, but I'm unsure
[03:37] <ogra> tfheen, http://people.ubuntu.com/~ogra/dhcp3.debdiff for Bug #61989
[03:37] <Ubugtu> Malone bug 61989 in dhcp3 "[Edgy dhclient regression]  error: Message too long" [High,Confirmed]  http://launchpad.net/bugs/61989
[03:37] <dholbach> Tonio_: best to ask Kamion or infinity about that? how does demotion (because of deps) to multiverse work?
[03:37] <dholbach> Tonio_: does anything depend on k9copy?
[03:37] <Tonio_> dholbach: nope
[03:38] <Tonio_> fabbione: I'm having a look at kdebindings
[03:38] <janimo> dholbach: as long as it it fixes the crash  I am fine with whatever you chose
[03:38] <Kamion> dholbach: it's not automatic, we have to be told (or notice)
[03:38] <Tonio_> dholbach: I'll ask Kamion, no pb
[03:38] <Riddell> thanks Tonio_ 
[03:38] <janimo> dholbach: is the theme seen by the gnome icon theme selectro btw?
[03:38] <dholbach> janimo: it's Hidden=True - I'll have to test if that works with gnome-mouse-properties still
[03:38] <Tonio_> Kamion: ah okay, so can you handle that if I upload k9copy again ?
[03:38] <dholbach> janimo: will test
[03:39] <dholbach> janimo: not icon theme, no
[03:39] <tfheen> ogra: approved.
[03:39] <janimo> dholbach: as the reporter of the other bug with kubuntu cursor theme said it crahsed gnome as well
[03:39] <Kamion> Tonio_: yes, just let me know when you've done it
[03:39] <dholbach> janimo: which package gives me the "kubuntu human cursor"?
[03:40] <ogra> tfheen, thanks, uploading
[03:40] <janimo> dholbach: kubuntu-default-settings
[03:41] <Tonio_> Kamion: sure, thanks
[03:41] <Lure> I think that regression from bug 61746 should be at least considered as RC (several duplicate bugs, multiple laptops)
[03:41] <Ubugtu> Malone bug 61746 in xorg-server "Xorg exits when it receives an ACPI button/lid event" [High,Confirmed]  http://launchpad.net/bugs/61746
[03:41] <janimo> dholbach: what's weird that the section in the desktop file is [Icon theme]  when it is not one :)
[03:42] <janimo> dholbach: but that's the same for the well-behaving industrial as well..
[03:42] <doko_> mvo, tfheen: final debdiff to upload: http://people.ubuntu.com/~doko/edgy/python-central.debdiff
[03:42] <Tonio_> Kamion: done
[03:42] <dholbach> janimo: Not sure *shrug*
[03:43] <StevenK> fabbione: I'm off to bed, let me know how the build goes.
[03:43] <fabbione> StevenK: will do of course
[03:43] <tfheen> doko_: it looks good to me; have it fixed any test cases for you?
[03:43] <StevenK> fabbione: Thanks!
[03:44] <janimo> dholbach: with Hidden=true it shows up  in xfce mouse cursor themes but not in icon themes so it's ok as far as this bug is concerned
[03:44] <tfheen> doko_: if mvo and you're both happy with it, please upload.  I can't see anything wrong with it, at least.
[03:45] <janimo> dholbach: but only with true, not True
[03:45] <dholbach> janimo: kubuntu human works fine for me
[03:45] <doko_> tfheen: yes (after having installed some packages causing these failures)
[03:45] <janimo> dholbach: not sure how the reported got gnome to crash then
[03:45] <tfheen> doko_: ok, cool, upload away.
[03:45] <janimo> s/reported/reporter/
[03:45] <dholbach> *shrug*
[03:46] <mvo> doko_: thanks for fixing the prerm-pycentral stuff!
[03:46] <doko_> mvo: will require some no-change uploads ...
[03:47] <dholbach> janimo: I'll test this on two boxes now, then upload a package for you to test with xubuntu
[03:47] <ogra> could someone approve my dhcp3 upload ?
[03:47] <janimo> dholbach: thanks
[03:48] <mvo> doko_: yeah
[03:49] <ogra> s/approve/unqueue/
[03:50] <bddebian> Howdy
[03:58] <Kamion> Tonio_: Depends: libdvdnav is bogus - no such (binary) package
[03:58] <Tonio_> Kamion: hu ?
[03:58] <Kamion> -Depends: ${shlibs:Depends}, ${misc:Depends}, vamps, dvd+rw-tools, dvdauthor
[03:59] <Kamion> +Depends: ${shlibs:Depends}, ${misc:Depends}, vamps, dvd+rw-tools, dvdauthor, mencoder, libdvdnav
[03:59] <Kamion> the binary package is called libdvdnav4
[03:59] <Tonio_> Kamion: argh, should be dvdnav4, sorry.....
[03:59] <Kamion> shouldn't that be picked up by shlibs, anyway?
[03:59] <Kamion> or is it dlopened?
[03:59] <Tonio_> yeah I know, I missed this when typing probably.....; I'm reuploading, sorry
[03:59] <mdz> ogra: accept or reject?
[03:59] <ogra> mdz, accept indeed
[04:00] <ogra> :)
[04:00] <doko_> dholbach: please approve an update for python-cxx, making it compatible with python2.5, see http://people.ubuntu.com/~doko/edgy/pycxx.diff
[04:01] <mdz> diff looks good
[04:01] <ogra> tfheen, already accepted it 
[04:01] <ogra> its just sitting in the queue
[04:01] <ogra> (it == debdiff)
[04:01] <Kamion> I'll process it
[04:01] <mdz> ogra: no it isn't
[04:01] <ogra> thanks
[04:01] <mdz> I debdiff'd it and approved it
[04:01] <Kamion> oh
 tfheen, http://people.ubuntu.com/~ogra/dhcp3.debdiff for Bug #61989
[04:02] <Ubugtu> Malone bug 61989 in dhcp3 "[Edgy dhclient regression]  error: Message too long" [Medium,Fix released]  http://launchpad.net/bugs/61989
 ogra: approved.
[04:02] <dholbach> doko_: sure
[04:03] <pitti> aah, I think I finally found out when the installer offers resizing and when not -- the big partition must be the last one, as it seems
[04:03] <Tonio_> Kamion: uploaded a fixed version, sorry for the error
[04:04] <Kamion> pitti: ... sort of
[04:04] <Kamion> pitti: read the script? :-)
[04:04] <Kamion> pitti: that's not actually a requirement, but it could be a consequence of other restrictions
[04:04] <pitti> Kamion: no, I didn't, I just occured to me that the default layout for 'wipe the disk' does not work, becasue it puts swap last
[04:05] <pitti> Kamion: right; I don't mind much, I'm just happy to have found how to reliably produce a setup where I can test resizing
[04:05] <Kamion> resize does get offered in circumstances where the big partition is at the start; I see it all the time
[04:05] <dholbach> Riddell, rideout: it builds nicely, uploading
[04:05] <Kamion> indeed, I see it on installations done immediately after "wipe disk" installations
[04:05] <dholbach> Riddell: debdiff here: http://daniel.holba.ch/temp/qt4-x11.debdiff
[04:06] <dholbach> 10 insertions(+), 1787 deletions(-) ;-)
[04:06] <janimo> are new CDs being built for today?
[04:06] <pitti> Kamion: hm, I had a 5 GB ext3 (sda1) and a 500 MB swap (sda2), no furhter partitions, and wasn't offered resizing. with only a 5.5 GB ext3 I was
[04:06] <Kamion> janimo: yes
[04:06] <Kamion> in fact I already did ...
[04:06] <Kamion> but we'll probably be doing another round later
[04:07] <dholbach> rideout: thanks for your efforts!
[04:08] <rideout> dholbach
[04:08] <rideout> dholbach: thanks, sounds good
[04:11] <dholbach> janimo: http://daniel.holba.ch/temp/human-cursors-theme_0.4-0ubuntu1_all.deb for your testing pleasure
[04:12] <rideout> dholbach: will your package be 4.2.0-1ubuntu5 ?
[04:12] <doko_> dholbach: please approve upload of pysvn to build for python2.5 (b-d on new pycxx)
[04:12] <dholbach> rideout: yes
[04:13] <dholbach> doko_: sure
[04:14] <tfheen> doko_: can you close the python-central bug reports too, then?
[04:15] <doko_> tfheen: will do
[04:16] <dholbach> janimo: want to mark the bug as RC?
[04:18] <janimo> dholbach: would be nice to be fixed but not critocal, as long as it is in final
[04:18] <dholbach> tfheen: bug 66323 has a comment from upstream - what do you think? at the moment, I'm more tending to unmark it RC (it was the only crasher until now and might have been an upgrade issue / dbus fuckup) and fix it through edgy-updates
[04:18] <Ubugtu> Malone bug 66323 in bluez-gnome "Problem report for bluez-passkey-gnome" [Medium,Needs info]  http://launchpad.net/bugs/66323
[04:18] <dholbach> janimo: if it crashes xubuntu all the way, I'd consider it critical :)
[04:19] <Kamion> doko_: that python-central upload doesn't involve rebuilding any other packages, does it?
[04:19] <dholbach> tfheen: whatever patch or set of patches we choose to fix it will have to be more tested (as they're not exactly obvious)
[04:20] <mdz> Kamion: it'll involve testing that they still build correctly at least
[04:20] <janimo> dholbach: ok, works, thanks. Then try to get it in RC if it's ok with you
[04:20] <dholbach> tfheen: but I'd leave that to the release-team's discretion
[04:20] <Kamion> doko_: how much of that have you done?
[04:20] <dholbach> janimo: oh, I meant: mark it as 6.10 :)
[04:20] <dholbach> janimo: "release critical" - sorry :)
[04:21] <tfheen> dholbach: it works in most cases now, it's not really critical for the desktop's functionality, so I'm happy with -updates.
[04:21] <janimo> dholbach: well no xubuntu bugs are marked 6.10 so far. But as far as xubuntu's definition of release critical this is one :)
[04:21] <dholbach> tfheen: Ok, I'll 'downgrade' it.
[04:21] <dholbach> janimo: alrighty
[04:22] <janimo> dholbach: as this crash sets an invalid theme in the config files so xfce does not only crash but no longer start unless the config file is hand edited
[04:23] <dholbach> janimo: interesting... the big desktop environments should sit together more often and talk about implementing specifications properly, then. ;-)
[04:23] <seb128> dholbach: what file is that?
[04:24] <seb128> dholbach: isn't what freedesktop is about? ;)
[04:24] <dholbach> seb128: yeah, but some desktop environment means seem to react differently on that kind of stuff ;-)
[04:24] <dholbach> /usr/share/themes/Human/cursor.theme
[04:24] <janimo> dholbach: indeed. In this case xfce code which crashes need to be more cautious as well. But I did not debug yet what part crashes.
[04:24] <dholbach> seb128: I added:
[04:24] <dholbach> Hidden=true
[04:24] <dholbach> Directories=
[04:25] <dholbach> janimo: I'll mark the kubuntu bug as a dup and open a kubuntu-default-settings task
[04:25] <janimo> dholbach: thanks!
[04:25] <seb128> dholbach: why the empty directories?
[04:26] <dholbach> seb128: the fd.o spec says that this entry is mandatory
[04:26] <tfheen> mdz,fabbione: I'm thinking about removing the milestone from https://launchpad.net/distros/ubuntu/+source/apt/+bug/63680 .  It's certainly a bug, but I don't see a solution which will be implementable in the time we have available.
[04:26] <Ubugtu> Malone bug 63680 in apt "dapper -> edgy dist-upgrade holds back essential packages" [Medium,Confirmed]  
[04:26] <janimo> seb128: to keep xfce from crashing. That entry is mandatory in the icon them spec, but gnome seems to cope with it missings
[04:26] <dholbach> seb128: xfce crashes without it :)
[04:26] <seb128> I would call that an xfce bug ;)
[04:26] <seb128> it should not crash on a wrong theme
[04:27] <tfheen> if an application crashes, it's an application (or library, possibly) bug.
[04:27] <janimo> seb128: I agree it's an xfce bug. But the thme file not being entirely kosher is a bug even if a smaller one
[04:27] <tfheen> apps should never crash on malformed input.
[04:27] <fabbione> tfheen: can we add it at least to the release notes?
[04:27] <fabbione> tfheen: and remove the tag after?
[04:27] <tfheen> fabbione: sure, release notes is fine.
[04:27] <fabbione> it doesn't make me happy at all, but i see no other way out nor does mvo
[04:27] <seb128> what spec did you look at?
[04:27] <seb128> there is a cursor theme spec?
[04:27] <seb128> or you used the icon theme one?
[04:28] <tfheen> fabbione: I'm not too happy about it either, but given that we don't have a fix and RC is two days away..
[04:28] <mvo> tfheen: yeah, it sucks - for edgy+1 we get a text-mode dist-upgrader that can solve similar issues for us automatically
[04:28] <fabbione> tfheen: yeah...
[04:28] <janimo> no point in agreeing upon standard file formats if everyone implements slightly differnt variants and has to have code to handle all of them
[04:28] <ondrej> mm all
[04:28] <fabbione> mvo: we want a working apt-get... sysadmins want apt-get or kitties will die
[04:28] <seb128> hi ondrej
[04:29] <janimo> seb128: I looke ta the icon them spec as the cursor file in cause call themselves index.themes instead of cursor.themes
[04:29] <ondrej> tfheen: hi, did you get any reply on ubuntu.cz yesterday?
[04:29] <mvo> fabbione: right
[04:29] <seb128> janimo: what theme is that?
[04:29] <janimo> seb128:  so they make xfce look at them. If I renamed them that's another workaround but dholbach said he;s not comfortable with a rename at this stage
[04:29] <tfheen> ondrej: no, sorry.
[04:29] <fabbione> StevenK: it builds fine.
[04:30] <janimo> seb128: human-cursors-theme and kubuntu's cursor theme
[04:30] <dholbach> janimo: human cursors theme (and kubuntu human cursors theme)
[04:30] <janimo> seb128: for comparison Industrial while it lack Directories= it is properly named so does not cause problems
[04:30] <seb128> my human-cursors-theme has only a cursor.theme
[04:30] <seb128> no index.theme
[04:30] <janimo> seb128: the alternative link needs to be named differently then
[04:31] <janimo> in /usr/share/icons/default/index.theme
[04:31] <seb128> $ dpkg -L human-cursors-theme | grep "\.theme"
[04:31] <seb128> /usr/share/themes/Human/cursor.theme
[04:31] <janimo> maybe changing postrm would suffice then I dunno
[04:31] <seb128> right
[04:31] <janimo> postinst I mean
[04:31] <seb128> better to do that after edgy though :)
[04:32] <dholbach> yeah
[04:32] <dholbach> *uploading*
[04:32] <seb128> but if any wrong theme can crash xfce you should better patch xfce
[04:33] <dholbach> tfheen: uploaded a fix for human-cursors-theme to make xfce not crash any more.
[04:33] <janimo> seb128: right, I wanted to make sure it is worked around in case I don;t find the bug. And one reported said thekubuntu one caused gnome to crash which made me think this could be a more serious issue. As I also had gt warnings related to no Diretcories entry in the error log
[04:33] <dholbach> tfheen: (buf 65870)
[04:34] <dholbach> janimo: as I said: the kubuntu cursor works fine for ubuntu - no crash for me
[04:34] <janimo> gtk warnings.
[04:34] <janimo> dholbach: right I did not test, so relied on what the reporter said
[04:34] <dholbach> *nod*
[04:34] <dholbach> Riddell: bug 65870 should be easy to fix and something for somebody on the kubuntu end to fix and test
[04:34] <Ubugtu> Malone bug 65870 in xfce-mcs-manager "xfce crashes repeatedly after changing icon theme to default" [Undecided,Confirmed]  http://launchpad.net/bugs/65870
[04:35] <tfheen> dholbach: I'll respond after som food.
[04:35] <dholbach> tfheen: bon apptit
[04:38] <Riddell> dholbach: ok
[04:47] <sfllaw> mdz: pong
[04:51] <doko_> dholbach: please approve http://people.ubuntu.com/~doko/edgy/logilab-common.debdiff, fixing an upgrade error
[04:52] <Kamion> 15:20 < Kamion> doko_: how much of that have you done?
[04:52] <Kamion> doko_: ^-- python-central, checking that other packages still build
[04:53] <dholbach> doko_: sure, go ahead
[04:55] <doko_> Kamion: oops, didn't notice. building itself isn't affected; infinity reported a removal error on the buildd's (package removal when python-central already is removed)
[04:56] <doko_> Kamion: for that to fix, ... theoretically all packages with files located in /usr/share/pycentral need to be rebuilt; in practice ... ?
[05:08] <seb128> Riddell: do you know about https://launchpad.net/distros/ubuntu/+source/pango1.0/+bug/65820 ?
[05:08] <doko_> dholbach: please approve http://people.ubuntu.com/~doko/edgy/straw.debdiff
[05:08] <Ubugtu> Malone bug 65820 in pango1.0 "Ugly fonts in gtk apps under edgy KDE (kubuntu)" [Undecided,Unconfirmed]  
[05:08] <Riddell> seb128: nope, but I can test it out
[05:09] <dholbach> doko_: looks good
[05:09] <seb128> Riddell: would be nice. Do you know if KDE changed the way it manages fonts or something?
[05:09] <Riddell> seb128: I did change the default fonts this week, Deja Sans -> Sans Serif
[05:10] <seb128> Riddell: ok, I've asked since when he has the issue
[05:16] <mdz> Keybuk: does network-magic need more discussion this time around at UDS?
[05:17] <Keybuk> mdz: if we want to have more discussion, I think we should create smaller less handy-wavy/christmas-tree specs for it
[05:19] <Keybuk> seb128 and dholbach may care about NM seeing as it's potentially part of the next release of GNOME
[05:19] <Keybuk> specs I can invision include
[05:19] <mdz> Keybuk: what's network-information-sharing about?  sounds very handwavy
[05:19] <Keybuk> static networks
[05:19] <Keybuk> vpns
[05:19] <Keybuk> integration with ifup
[05:19] <Keybuk> etc.
[05:19] <Keybuk> hmm
[05:20] <Keybuk> oh, that's the spec for sharing information with avahi
[05:20] <mdz> Keybuk: someone else registered it and you put it on the agenda
[05:20] <Keybuk> I hadn't yet fully tidied it up -- it was the most appropriate spec of the set
[05:20] <Keybuk> default-network-services is the "discuss what policy we should have wrt open ports, etc."
[05:20] <dholbach> Keybuk: I'd prefer it, if somebody else who'd know more about network stuff and about integration with the network bits in Ubuntu took care of it.
[05:21] <Keybuk> and there's a few deps of that
[05:21] <Keybuk> the spec for d-n-s should be an informational policy
[05:21] <Keybuk> whereas the spec for n-i-s should be how we plan to exploit the new policy
[05:22] <Keybuk> if that makes sense
[05:22] <Keybuk> one is a dep of the other, so the scheduler will ensure they happen in the right order (in theory, the second may never have a discussion bof and go straight to drafting)
[05:23] <tfheen> dholbach: about 65870 ; I don't think this is RC in either of the themes.
[05:23] <dholbach> tfheen: hum... it crashes xubuntu
[05:23] <tfheen> dholbach: then fix the crash there, if it's not very hard?
[05:24] <janimo> tfheen: I do not know how hard it is. But that icon them file is not in standard format
[05:24] <ogra> fixing the xfce thme handling will surely be more intrusive
[05:25] <dholbach> tfheen: I agree with janimo there.... while it's preferrable to have xfce fixed and it should be investigated and forwarded, this is something which should have been done anyway
[05:25] <tfheen> dholbach: I'm not saying it's not a bug, I'm merely saying it's not RC for those package.
[05:28] <janimo> tfheen: right, it's not RC for those specific packages, just affects others :)
[05:28] <dholbach> So that's the distinction "it's RC" vs. "the implication of this little bug gives another distro RC bugs"? :-)
[05:29] <dholbach> But alright, I uploaded the human-c-t fix, that's all I could do for my part.
[05:29] <tfheen> dholbach: yes, and in some cases it can "bleed" over if the fix is really painful.  (Say if xfce-mcs-manager would have to be rewritten completely, I'd be more inclined than in the case here where I would guess a strdup("") is all that's called for.
[05:30] <dholbach> tfheen: right... it could be an easy fix. agreed.
[05:31] <tfheen> at this point, I want to not only have minimal changes, I want to not rebuild anything unless we have to.  Bugs have cropped up in the past because some seemingly insignificant piece changed in a subtle way.
[05:31] <tfheen> so from the POV of ubuntu, kubuntu and edubuntu, it makes more sense to implement the fix in xubuntu.
[05:31] <mdz> sfllaw: good morning
[05:32] <mdz> sfllaw: do you have those test cases prepared?
[05:36] <pirast> infinity, any news on the bootstrap of fpc?
[05:47] <rideout> the network-manager update that just went out causes knetworkmanger to bomb on me constantly
[05:47] <Keybuk> *sigh*
[05:47] <doko_> tfheen: please approve http://people.ubuntu.com/~doko/edgy/python-setuptools.debdiff
[05:47] <tfheen> rideout: which network card do you have?
[05:47] <tfheen> rideout: or rather, which driver do you use?
[05:48] <tfheen> doko_: which problem does it fix?
[05:48] <rideout> ipw3945
[05:49] <doko_> tfheen: running easy_install without having python2.5 installed
[05:50] <tfheen> rideout: the network-manager update only changed behaviour for people using ndiswrapper, so I doubt your claim.
[05:50] <tfheen> doko_: oh, ok, approved.
[05:50] <Keybuk> tfheen: no it didn't
[05:50] <tfheen> Keybuk: oh?
[05:51] <Keybuk> the guy snuck in another change into the patch
[05:51] <Keybuk> (at least the one I read)
[05:51] <Keybuk> which is why I rejected it
[05:51] <Keybuk> no idea why it suddenly got applied and uploaded
[05:51] <tfheen> Keybuk: there was no other change in it, but a patch applied on top had to be adjusted.
[05:52] <rideout> tfheen: well, i'll do some more testing...
[05:52] <tfheen> Keybuk: http://err.no/patches/network_manager_remove_ndiswrapper_specialcase.diff is the patch.
[05:52] <tfheen> or, interdiff
[05:53] <Keybuk> ok, that's somewhat cleaner than the one I read
[05:53] <tfheen> it's semantically equivalent.  The other guy just fumbled a bit with dpatch.
[05:53] <Keybuk> wasn't wpasupplicant updated as well?
[05:55] <Tonio_> fabbione: just fixed kdebindings (and update to 3.5.5)
[05:55] <Tonio_> mdz: as that is part of kde 3.5.5, I assume it doesn't need uvf exception request for upload does it ?
[05:56] <doko_> dholbach: please approve python-4suite to add replaces fixing an upgrade error
[05:56] <dholbach> doko_: sure
[05:56] <tfheen> Keybuk: I didn't do that, at least, and it works fine with unencrypted networks.
[05:58] <rideout> tfheen: wpa_supplicant is actually the problem some TKIP error, but it was working 20 minutes ago ... i'll dig deeper
[05:58] <Keybuk> rideout: try a clean reboot
[06:00] <tfheen> anyway, I'm afk for a few hours.  Roleplaying session.
[06:01] <mdz> Tonio_: that exception was granted some time ago and I understood that 3.5.5 was already in
[06:01] <mdz> Tonio_: it's too late to be pushing new upstreams at this point unless they're incredibly minimal
[06:01] <Tonio_> mdz: no it isn't since the package failed to build
[06:02] <Tonio_> mdz: well the problem is that the current package now ftbfs too, due to libgcj7-dev update......
[06:02] <Tonio_> mdz: isn't that problematic enough to update ?
[06:02] <mdz> Tonio_: if it fails to build, that should be fixed directly, not by bringing in a new upstream
[06:03] <Tonio_> mdz: bah I can fix the current package too, the fix is the same
[06:03] <Tonio_> mdz: I just updated because kde 3.5.5 was approved
[06:03] <Tonio_> mdz: so I can fix and upload the current package then...
[06:03] <mdz> Tonio_: that was before the freeze
[06:04] <Tonio_> mdz: okay, let's fix the current package then
[06:04] <mdz> thanks
[06:08] <Tonio_> dholbach: I'll probably upload kdebindings (universe) in a moment, corrects the ftbfs issue, can you aprove ?
[06:09] <dholbach> Tonio_: No sorry - I'm not allowed to. That's the realm of tfheen, mdz, infinity and Kamion.
[06:09] <dholbach> oh
[06:09] <dholbach> that'S universe?
[06:09] <Tonio_> yup
[06:09] <Tonio_> ;)
[06:09] <infinity> No, it's in main.
[06:09] <dholbach> what I thought
[06:10] <infinity> Tonio_: Show mdz the diff (I'd say "show me", but I'm in no state to make sound technical decisions)
[06:10] <infinity> I'm sane enough to know which component it's in, though. :P
[06:10] <Tonio_> tonio@kubuntu:/usr/lib$ apt-cache show kdebindings-java | grep Filename
[06:10] <Tonio_> Filename: pool/universe/k/kdebindings/kdebindings-java_3.5.4-0ubuntu1_all.deb
[06:10] <Tonio_> looks in universe for me
[06:10] <infinity> Tonio_: The source is in main, that one package is in universe.
[06:10] <dholbach> apt-cache showsrc kdebindings
[06:11] <Tonio_> infinity: ah ok sorry, gimme a moment to do the debdiff
[06:11] <Tonio_> dholbach: yeah thanks I didn't though about the source package indeed
[06:13] <Tonio_> infinity: http://paste.tonio.homelinux.org/30 the debdiff
[06:14] <keescook> Keybuk: do have a moment to pull a sync?  dirvish is currently half-broken in edgy: bug 66273
[06:14] <Ubugtu> Malone bug 66273 in dirvish "sync request" [Undecided,Confirmed]  http://launchpad.net/bugs/66273
[06:15] <Tonio_> infinity: I'm just testing the fix on the current package and if it builds correctly and you are okay I'll upload
[06:19] <Keybuk> keescook: done
[06:24] <zul> how do you get a spec on the agenda for uds?
[06:26] <fabbione> zul: it's written in the email from mdz to ubuntu-devel-announce
[06:26] <fabbione> zul: somebody will review and approve them IIRC
[06:27] <zul> fabbione: ok thanks
[06:32] <geser> fabbione: any news on the outdated Contents files on archive.u.c for edgy?
[06:33] <fabbione> geser: no, you can ask in #launchpad 
[06:33] <fabbione> geser: malcc or SteveA or kiko
[06:34] <geser> will do
[06:34] <Riddell> seb128: I've just done a new install and fonts in gtk apps running under kde look fine
[06:34] <Riddell> seb128: he seems to have commented that it's fixed for him
[06:36] <infinity> Tonio_: As I said, please ask mdz for review/approval, I'm not all here.
[06:36] <infinity> (and going to bed now)
[06:40] <ogra> does ff take ~30sec for anyone else to open a url you clicked on in IRC or other external apps ?
[06:40] <ogra> (i.e. evolution)
[06:41] <ogra> it seems to take ages here to open a new tab if i click anything
[06:41] <ivoks> no
[06:42] <Tonio_> infinity: ah sorry, I'll ask mdz then
[06:44] <Tonio_> mdz: http://paste.tonio.homelinux.org/30 is that okay for upload according to you ?
[06:45] <agutierr> hello all: I have a serious problem. Someone knows if its possible to convert the yp/nis passwd.byname file to a passwd file ?
[06:46] <ogra> agutierr, please ask in #ubuntu, this is not a support channel
[06:46] <agutierr> thanks ogra 
[06:48] <wasabi> ajmitch: You going to bring up anything about network auth at UMV?
[06:48] <mdz> Tonio_: what is the effect of that change?
[06:48] <mdz> sfllaw: did you see my earlier messages?
[06:49] <mdz> Tonio_: why is that patch no longer necessary?
[06:49] <Tonio_> mdz: builds correctly, the patch removed caused ftbfs due to libgcj7-dev change
[06:49] <mdz> Tonio_: what that patch seems to do is replace some find commands with hardcoded defaults
[06:49] <mdz> Tonio_: why does that cause it to fail to build and how does removing the patch fix it?
[06:50] <Tonio_> in fact libgcj.so is no longuer in /usr/lib in latest  libgcj7-dev 
[06:50] <Tonio_> mdz: then configure fails, but works correctly without that patch
[06:50] <sfllaw> mdz: Ah yes.  Testing/Current is uptodate.
[06:53] <Tonio_> mdz: the point is that patch simplifies the configure commands, true, but the point is that libgcj.so path as changed
[06:53] <mdz> sfllaw: you, cr3, pitti and fabbione seem to have an excessive number of test cases
[06:53] <Tonio_> mdz: /usr/lib/gcc/i486-linux-gnu/4.1.2/libgij.so in currently i386 package , that's why it is necesarry to go back to the find commands
[06:54] <seb128> Riddell: ok, thank you for testing and confirming it works fine on a fresh install :)
[06:54] <sfllaw> mdz: cr3 actually has to do these test cases for certification.  :(
[06:54] <Tonio_> mdz: previous libgcj7-dev created a symlink in /usr/lib which has been removed
[06:54] <mdz> sfllaw: it will take him all day though
[06:55] <sfllaw> mdz: So I'm helping him out with those as a side-effect.
[06:55] <sfllaw> We have a lot of computers, so parallel processing is the plan.
[06:55] <pitti> mdz: I'm fine with doing two architectures, that doesn't slow me down; it would just not hurt to split one arch between two people
[06:55] <sfllaw> I'm going to hop out and buy a few more CD-RW.
[06:55] <cr3> pitti: I can do i386 and amd64, maybe some powerpc if only I had more time (not likely to happen)
[06:56] <sfllaw> pitti: Is that too much?  We don't seem to have a lot of developers with  PPC machines any more.
[06:56] <cr3> I'm also working on sparc actually, so scratch powerpc, I definatly won't have time for that
[06:56] <pitti> cr3: I'm fine with doing the powerpc range
[06:56] <cr3> pitti: cheers
[06:56] <pitti> I can easily test them while working on my amd64 desktop
[06:56] <pitti> sfllaw: it just takes a while, my ibook is painfully slow
[06:56] <sfllaw> pitti: Understood.
[06:57] <pitti> I ordered some more RAM today, that should help a little
[06:57] <sfllaw> pitti: Sadly, our Pegasus box in the lab doesn't boot off of CDs.
[06:57] <sfllaw> And the lab bandwidth is terrible.
[06:58] <cr3> by the way, ubuntu 6.10 desktop for i386 built on 20061016 didn't install on two machines. I'm currently updating my iso to 20061017, but is that worth reporting while waiting for the download?
[06:58] <Riddell> Kamion: why the rebuild?
[06:58] <sfllaw> cr3: It never hurts to mark down additional information.  Just make sure -fail is in lowercase.
[06:58] <Kamion> Riddell: new d-i
[06:59] <Kamion> fixes a couple of targetted bugs
[06:59] <Kamion> cr3: it always helps if you give more information than "didn't install" when reporting things like that here
[06:59] <Kamion> we cannot possibly tell you if it's worth reporting otherwise
[07:01] <keescook> tfheen: is aolserver4 sitting in the queue somewhere?  dholbach said it was okay to upload yesterday (along with ettercap that looks to have gone through)
[07:01] <cr3> Kamion: oh, I thought the problem might've been known to others in here, so that's why I was so brief. since nobody seems to have encountered such severe installation problems with 20061016, I should definately report it. thanks.
[07:01] <Kamion> cr3: you say that as if there is only one possible mode of installation failure!
[07:01] <Kamion> "the problem"
[07:01] <sfllaw> :)
[07:02] <Kamion> it could be ANYTHING
[07:02] <sfllaw> Aliens from outer space have abducted my installer!
[07:02] <sfllaw> Help!!!
[07:03] <Kamion> my wife says that happened to her with Win95, but sadly they gave it back
[07:03] <Tonio_> mdz: need more infos or is it clear concerning the patch removal ?
[07:04] <Kamion> cr3: seriously, plain "didn't install" always raises my blood pressure, so please just don't say that :-)
[07:06] <cr3> Kamion: I tend to be more brief on irc so I'll just report bugs in malone and copy/paste in Testing/Current. thanks for the tip.
[07:08] <Kamion> sfllaw: for that hang in installer package selection, you didn't accidentally press alt-tab, did you?
[07:09] <Kamion> I was just told about a bug today where cdebconf hangs if you press alt-tab
[07:09] <Kamion> (during a progress bar)
[07:09] <Kamion> I assume it's some crazy code in newt
[07:09] <elmo> argh, something broke C-s in emacs
[07:09] <elmo> so much hate
[07:09] <sfllaw> Kamion: I don't think I did.
[07:09] <ogra> who cares about emacs anyway 
[07:09] <sfllaw> I can be careful not to.
[07:10] <ogra> use openoffice
[07:14] <fabbione> mdz: sorry about what?
[07:16] <mdz_> Tonio_: how out of date is kdebindings?
[07:16] <Keybuk> tfheen: new amd64 usplash utterly screws VT 1
[07:17] <Keybuk> at least you can't flip back to it again
[07:17] <mdz_> Tonio_: did the current version originally fail to build, ro did it only start to fail to build due to the other changes?
[07:17] <fabbione> mdz: sorry .. too many test cases for what?
[07:18] <mdz> Tonio_: if the current binaries are up to date and it's just an ftbfs due to the gcj changes, then please go ahead
[07:18] <mdz> fabbione: too many to complete in a reasonable amount of time
[07:18] <Tonio_> mdz: the current version started to fail building when libgcj7-dev was updated, but it has been built and we have binary packages in the repos
[07:18] <Tonio_> mdz: okay I'm uploading, thanks
[07:19] <fabbione> mdz: you mean install tests? or something else? i didn't even get to the test matrix yet. T2000 is still busy rebuildin
[07:20] <mdz> fabbione: I mean installation tests, yes
[07:21] <fabbione> mdz: ok.. let me check the matrix
[07:22] <pitti> fabbione: don't forget the blue pill :)
[07:22] <fabbione> mdz: clearly who did the matrix doesn't know that there are no desktop CD for sparc and that we don't support full desktop
[07:22] <fabbione> mdz: no big deal.. i am going to clean it up
[07:22] <fabbione> same for kubuntu
[07:22] <fabbione> we only support server sparc
[07:23] <sfllaw> fabbione: Ah.
[07:23] <sfllaw> Sorry about that.
[07:23] <sfllaw> fabbione: Do you want me to fix it?
[07:23] <fabbione> sfllaw: do you want to clean up or should I?
[07:23] <sfllaw> I'll do it.
[07:23] <mvo> tfheen: would it be possible to upload another dist-upgrader version? http://people.ubuntu.com/~mvo/tmp/dist-upgrader_20061017.1916_all.diff <- it fixes one crash for strange dpkg error output and ensures proper upgrading for bzr/tomboy/xserver-xorg-input
[07:23] <fabbione> sfllaw: there is no check cd for sparc either
[07:23] <fabbione> or DVD's
[07:23] <Tonio_> mdz: uploaded thanks
[07:24] <sfllaw> How do you know if the CD's broken then?
[07:24] <sfllaw> And is there a DVD version?
[07:24] <fabbione> sfllaw: when that thing was implemented nobody did it for silo.. so there is no way to execute it AFAIK
[07:24] <sfllaw> Oh.
[07:24] <fabbione> sfllaw: nope.. no DVD's
[07:24] <Kamion> nobody told me about that
[07:24] <sfllaw> Is there also a Netboot for sparc?
[07:24] <fabbione> sfllaw: yes.. netboot is VITAL for sparc
[07:24] <fabbione> it needs more testing than Cd's
[07:25] <sfllaw> OK.  So Netboot + Server CD is all it has.
[07:25] <Kamion> fabbione: er, did you ever try booting the sparc server CD with 'check'?
[07:25] <fabbione> Kamion: i don't blame anybody.. i didn't know about it and when i figured it was too late (like 20 seconds ago)
[07:25] <Kamion> # Media integrity check
[07:25] <Kamion> image[sun4u] =/boot/sparc64
[07:25] <Kamion>   label=check
[07:25] <Kamion>   append="MENU=/bin/cdrom-checker-menu --"
[07:25] <Kamion> ^-- in debian-cd/data/edgy/sparc/silo.conf
[07:25] <sfllaw> fabbione: So is ther Kubuntu support?
[07:25] <fabbione> Kamion: last i checked it was not there..
[07:25] <fabbione> Kamion: EVEN BETTER!
[07:25] <Kamion> that's been there so long I don't remember adding it
[07:26] <fabbione> EVERYBODY HUG KAMION *NOW*!
[07:26] <Kamion> no, don't :)
[07:26] <Riddell> sfllaw: no,there's not
[07:26] <dholbach> sfllaw: I can't do the ppc tests - i have an *ancient* machine
[07:26] <fabbione> Kamion: usually silo does tab complation and it didn't show up for beta.. tho ..well i am happy :)
[07:26] <pitti> hugs, too
[07:27] <sfllaw> dholbach: Can you remove your PPC machine from StaffHardware thaen?
[07:27] <fabbione> sfllaw: anyway the amount of tests are really not balanced
[07:27] <dholbach> sfllaw: I can do one or another alternate/server install, but not so many
[07:27] <fabbione> sfllaw: across the team..
[07:27] <Kamion> fabbione: not saying it's necessarily correct
[07:27] <Kamion> I added it on 2006-01-04
[07:27] <fabbione> Kamion: i will test it tomorrow or so
[07:27] <mdz> mjg59: how do we unintrusively fix bug 60442?
[07:27] <Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  http://launchpad.net/bugs/60442
[07:27] <fabbione> Kamion: i am sure these CDs are not 100% gold yet ;)
[07:27] <sfllaw> dholbach: Hardware on ppc was rough.
[07:28] <mdz> mjg59: given that gpm doesn't seem to understand properly about multiple batteries at all, adding that functionality isn't feasible
[07:28] <sfllaw> People have machines that are old, have no hard disks, broken, etc.
[07:28] <sfllaw> :(
[07:28] <dholbach> sfllaw: it already says "very aged G4" :)
[07:28] <mdz> mjg59: what did it do in dapper?
[07:28] <fabbione> sfllaw: there are people with gazillions of tests and people with none
[07:28] <Kamion> hmm, I never updated gfxboot-theme-ubuntu at the non-langpack translation deadline
[07:28] <dholbach> sfllaw: as I said: I'm happy to do one or another install (hoping that the memory for it will arrive soon), but not all of them
[07:28] <sfllaw> dholbach: It didn't say "Apple Quadra 700".
[07:29] <Kamion> mdz: how would you feel about me doing a quick update from Rosetta there? should be pretty safe and just requires CD rebuilds
[07:29] <sfllaw> fabbione: Who are the people with none?  I tried to fill up everyone from the Devel team.
[07:29] <Kamion> (which I bet are going to happen anyway ...)
[07:29] <sfllaw> Obviously, I can't steal people from kiko.  :)
[07:29] <mdz> Kamion: ok with me
[07:29] <Kamion> thanks. the last translation update was 5 September
[07:29] <fabbione> sfllaw: BenC? seb128 (and not 123!)...
[07:30] <Kamion> and predates the rename of "Install a server" to "Install a command-line system"
[07:30] <BenC> fabbione: Yo
[07:30] <fabbione> BenC: never mind.. i was just reminding sfllaw that you exist
[07:30] <ogra> <- dinner/breakfast/lunch, however you wanna call it ... bbl
[07:31] <fabbione> sfllaw: Kamion is missing from the list.. like our test GOD!
[07:31] <Kamion> dear god, gfxboot-theme-ubuntu has a fledgling Klingon translation now
[07:31] <dholbach> seb123 - LOL
[07:31] <sfllaw> fabbione: Oh, transcription errors.
[07:31] <Treenaks> Kamion: almost 'enterprise-ready' then
[07:31] <sfllaw> I had them written out on a piece of paper.
[07:31] <Kamion> Treenaks: *groan*
[07:31] <Treenaks> Kamion: ;)
[07:31] <Kamion> sfllaw: how quaint
[07:32] <elmo> remember kids, every time you use a winky smiley, jono kills a kitten
[07:32] <sfllaw> ;)
[07:32] <sfllaw> ;)
[07:32] <Treenaks> elmo: ooh! ;) ;) ;) ;)
[07:32] <fabbione> sfllaw: also.. did you send out a mail for global testing?
[07:32] <sfllaw> ;) ;) ;) ;)
[07:32] <Keybuk> ;)
[07:32] <fabbione> ehhehe
[07:32] <bhale> if he kills them with a guitar, sign me up
[07:32] <Treenaks> elmo: he has to eat _something_
[07:32] <sivang> elmo: ahah, true
[07:32] <sfllaw> fabbione: I have a draft.
[07:32] <sivang> I lost my online emotions for a while after reading his blog post
[07:33] <sivang> actually it was nice feeling so cool and emotionless for a while, but then people are winking at you...wont'ya wink them back? 
[07:33] <mdz> mjg59: we don't have any laptops with two batteries around, so if you feel this bug is this important, I'll need your help to do anything about it
[07:33] <sivang> bhale: you play ?
[07:33] <sfllaw> Kamion: Do we know when those "out of date, do not test yet" images will be up to date?
[07:33] <bhale> sivang: barely, these days
[07:33] <sfllaw> Kamion: Or should we get users thrown at the Alternates first?
[07:34] <mjg59> mdz: Right
[07:35] <sivang> bhale: you should practice or your wrist will stiffen
[07:35] <sivang> bhale: I do wrist practice to not let it go bad although I have played a note since ages
[07:36] <_ion> Yay, artists.
[07:36] <sivang> s/have/haven\'t/
[07:37] <_ion> Why escape the '?
[07:37] <mdz> mjg59: I looked at the code a bit and I don't see why it would behave differently in dapper
[07:37] <mjg59> mdz: I have no rational explanation, merely the observation that it doesn't happen in dapper
[07:39] <Treenaks> _ion: for the people with strict parsing auto-replacing irc clients ;)
[07:39] <seb128> fabbione: thank you for reminding people to give me extra work :p
[07:39] <fabbione> seb128: no.. for you was just a mispell :)
[07:39] <fabbione> seb128: or do you feel downgraded to sev123 ?
[07:39] <seb128> hehe
[07:39] <seb128> no, I just didn't feel concerned since I don't know that seb123
[07:39] <fabbione> sfllaw: note that also BenC has sparc...
[07:39] <dholbach> seb128: we all know how much you like your name mispellt
[07:40] <mdke_> Kamion: no, that's not built/shipped by default - it's just in our svn tree. We can exclude it from the source package if that helps
[07:40] <dholbach> :-)
[07:40] <seb128> anyway downloading DVD will take some time for me
[07:40] <seb128> I've just CD images handy atm
[07:40] <seb128> and my dsl is not that fast
[07:40] <mdke_> Kamion: (I hope it's not out of date though)
[07:42] <sfllaw> seb128: rsync?
[07:42] <seb128> sfllaw: rsync works fine when you have a base :)
[07:42] <sfllaw> Start downloading now!
[07:42] <sfllaw> :)
[07:42] <seb128> will do
[07:42] <seb128> it's just going to take 1 day
[07:42] <sfllaw> Yeah.
[07:43] <sfllaw> The Montreal office's connexion is not much better.
[07:43] <fabbione> seb128: cat alternate.iso > dvd.iso
[07:43] <sfllaw> It takes us a day to get the DVD as well.
[07:43] <fabbione> seaLne: cat live.iso >> dvd.iso
[07:43] <fabbione> rsync
[07:43] <fabbione> seb128: ^^
[07:43] <fabbione> or was the other way around?
[07:43] <seb128> fabbione: right, should give a start :)
[07:43] <sfllaw> The live portion comes after?
[07:43] <fabbione> iirc it comes first
[07:43] <sfllaw> Yeah.
[07:43] <sfllaw> That makes more sense.
[07:43] <sfllaw> cat live.iso alternate.iso > dvd.iso
[07:43] <sfllaw> You know, because it concatenates?
[07:43] <fabbione> Kamion: does live comes first on dvd?
[07:44] <fabbione> sfllaw: yeah.. i am old lazy schoo
[07:44] <fabbione> l
[07:45] <sfllaw> fabbione: Your cat didn't concat files?!?
[07:45] <fabbione> sfllaw: it probably did.. but i was learning pipes and concats at the time and you know.. once you learn one way you keep it that way
[07:46] <dholbach> sfllaw: I'm happy to do some amd64 installs instead and some server installs or something easy on ppc
[07:47] <sfllaw> dholbach: I've got you down for desktop Edubuntu PPC installs.
[07:47] <sfllaw> The check CD and live session tasks are easy.
[07:47] <dholbach> I noticed, that's why I said it :)
[07:47] <dholbach> I know
[07:47] <sfllaw> Is that still too much?
[07:47] <dholbach> but not on a VERY AGED G4 :)
[07:47] <sfllaw> Ah.
[07:47] <sfllaw> I still work on a PII, you know.
[07:47] <dholbach> I don't mind test-installing
[07:48] <dholbach> the problem is that I didn't get the memory for it yet - I hope it'll be there tomorrow, but I can't promise
[07:48] <sfllaw> If you go down from three installs to two, is that good enough?
[07:48] <sfllaw> Oh.
[07:48] <sfllaw> I get it.
[07:48] <dholbach> I'm happy to do other installs
[07:48] <dholbach> no problem
[07:48] <sfllaw> I'm slow today.
[07:48] <sfllaw> Someone gave me the cold.
[07:49] <fabbione> sfllaw: you are really tempting me..
[07:49] <dholbach> fabbione: tempting how?
[07:49] <fabbione> to say s/ today//
[07:50] <sfllaw> :)
[07:55] <dholbach> sfllaw: Ok, rsyncing.
[07:57] <Lure> mdz: which bug with dual battery?
[08:00] <Lure> mdz: I got it in backlog - bug 60442 - I can try this as I have looked g-p-m code when implementing kde-powermanager multibattery
[08:00] <Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  http://launchpad.net/bugs/60442
[08:02] <mdz> Lure: any help you can provide would be appreciated
[08:10] <Lure> mdz: the problem is that multi-battery support in g-p-m is limted to presenting remaining time properly, while low/critical is done on battery events - which means that every battery getting to critical state will cause problems
[08:11] <Lure> mdz: it will work somehow only on laptop that discharge both batteries at the same time (not that many) and if batteries are of similar capacity :-(
[08:15] <bhale> I admit it is annoying to get a notification when my first battery runs out, but i doubt that is a huge install base
[08:15] <mjg59> bhale: The default behaviour is then to hibernate
[08:15] <bhale> oh, I've surely changed that first thing
[08:15] <Lure> mdz: quick (dirty) fix could be to use remaing from cache instead of from single battery (this is what we do in kde-powermanager)
[08:15] <mdz> Lure: why was it better in dapper and how can we revert to it?
[08:16] <Lure> mdz: I do not know (not gnome person), but I suspect that g-p-m did not use events to trigger critical action
[08:16] <mdz> the code was there, maybe it was somehow broken
[08:16] <mdz> in which case we should simply disable it in edgy to avoid this regression
[08:17] <mdz> we could just default to doing nothing on a critical event, and let the user change it if they like
[08:17] <Lure> mdz: it may have used battery property change event instead and just reclaculated levels at that time
[08:17] <Lure> mdz: we could hack a quick solution, but I am not sure if it is the right time to include it so late
[08:19] <Lure> mjg59: are you looking at the g-p-m code?
[08:20] <mjg59> Yes
[08:21] <Lure> mjg59: if we would pass gpm_manager_get_warning_type() status from cache (which is cumulative for all primary batteries), then warning level would be properly calculated
[08:21] <mjg59> Lure: I agree
[08:22] <Lure> mjg59: I am just not sure how big surgery would this be
[08:22] <mjg59> Lure: Well, it needs to be slightly more complicated than that.
[08:22] <mjg59> Lure: Since otherwise you'll never get low reporting for bluetooth devices
[08:23] <Lure> mjg59: no, because there are different callbacks for different types
[08:23] <mjg59> Lure: Oh, sorry, I see what you mean
[08:23] <Lure> mjg59: we would just pull type_status in battery_status_changed_primary() 
[08:24] <Lure> mjg59: see battery_kind_cache_update() for cache version 
[08:25] <Lure> mjg59: I know that part as I used this as refernce for all pecularities when implementing kde-pm
[08:26] <mjg59> Lure: Right. I agree.
[08:27] <mjg59> battery_status_changed_primary should look at the battery_status entry of the cache, not the status provided by the individual battery
[08:27] <Lure> mjg59: we would need to call battery_kind_cache_find (power, PRIMARY) to get entry and then pass entry->battery_status to gpm_manager_get_warning_type() 
[08:27] <Lure> exactly
[08:28] <mjg59> Lure: That sounds like a demonstrably correct and non-invasive change
[08:28] <Lure> mjg59: it is correct, not sure if it is the thing the author of g-p-m would do though ;-)
[08:28] <mjg59> Lure: It's the minimal invasive change and we don't have time to do anything else :)
[08:29] <Lure> mjg59: and true, it is not as dirty as I though initially
[08:30] <Lure> mjg59: I can try building something, but it will be the fisrt gnome build for me ;-)
[08:31] <Lure> mjg59: I can test on my dual-battery hp nw8240 (as I have still test gnome install used to check how ubuntu does laptop support)
[08:32] <mjg59> Lure: Cool
[08:32] <mjg59> Lure: Oh, wait. Do we want to update the cache before doing the cache_find?
[08:33] <Lure> mjg59: I suspect it is already up-to-date as it gets updated on battery propertly change event
[08:33] <mjg59> And that happens before the manager update?
[08:33] <Lure> I suspect this is before critical/low warning event
[08:33] <Lure> but would need to test
[08:33] <mjg59> Ok
[08:33] <mjg59> It's an extra line in the worst case
[08:34] <mjg59> Lure: Every reference to battery_status needs to be changed to type_status in the rest of battery_status_changed_primary
[08:35] <mjg59> But not the ones before the warning state is grabbed
[08:36] <Lure> mjg59: not sure regarding before ones though
[08:37] <Lure> mjg59: if one of two is charging, then we should reset warning to NONE, no?
[08:37] <Lure> mjg59: my HP charge first the built-in, then external and sure any one charging means that we are on AC
[08:38] <Lure> mjg59: so no warnings should be issued
[08:39] <Lure> mjg59: only not sure about fully charged -> do we want one for each battery or only one notify when both are charged (this is what kde-pm does)
[08:40] <mjg59> Lure: Ah, I see what you mean
[08:40] <mjg59> Yeah, ok, that makes sense
[08:40] <cbx33> hmm.....firefox is refusing to start in edgy....
[08:40] <cbx33> I installed from the 16 build
[08:40] <cbx33> copied my home dir from nmy old dapper
[08:41] <cbx33> it said it was checking the plugins/extensions....
[08:41] <cbx33> that took forever, and to my knowledge I didn't have many/any installed
[08:41] <cbx33> now it just hangs
[08:41] <cbx33> no gui no nothing
[08:41] <cbx33> the process is there
[08:41] <cbx33> strace yeilds lots of futex and gettimeofday
[08:42] <mjg59> Lure: Of course, there's the problem that gpm-manager can't call battery_kind_cache_find directly...
[08:42] <Lure> mjg59: why not?
[08:42] <Lure> static?
[08:42] <mjg59> Oh, yeah
[08:43] <Lure> mjg59: what about gpm_power_get_battery_status() - this is called from gpm-manager.c
[08:43] <mjg59> Lure: Just make them non-static
[08:44] <mjg59> Oh, wait, yeah. That might be cleaner.
[08:44] <mjg59> Yeah, go with that.
[08:44] <mjg59> It looks perfect.
[08:44] <Lure> mjg59: it looks like this is external wrapper for cahce_fine
[08:45] <mjg59> Yup
[08:45] <Lure> cache_find too
[08:45] <Lure> mjg59: but this is already done in power_battery_status_changed_cb() :-(
[08:46] <mjg59> Wurgh.
[08:49] <mjg59> Lure: Yes, that looks awkwardly like it should work
[08:50] <Lure> mjg59: something else confuses gpm_manager_get_warning_type() 
[08:51] <mjg59> No, here is fine
[08:52] <mjg59> I can't see how get_warning_type could be doing anything wrong
[08:52] <mjg59> Which leaves me wondering about the contents of the cache
[08:53] <Lure> mjg59: use_time might be tricky if cache value is bad - see comment in line 2808
[08:55] <mjg59> Which file?
[08:55] <Lure> gpm-manager.c
[08:55] <Lure> mjg59: search for GPM_PREF_USE_TIME_POLICY
[08:55] <mjg59> Ah, yeah
[08:56] <mjg59> The cache calculations may be wrong when one battery empties?
[08:57] <mjg59> Lure: I think we're going to have to do this the hard way, add some debugging and then see what actually happens when the changeover occurs
[08:57] <Lure> mjg59: not sure how (I am using similar for kde-pm and works for me
[09:00] <Lure> mjg59: only questionable code in cache is for me use of percentage_charge before being set in the check in lgpm-power.c:973
[09:01] <Lure> mjg59: percentage_charge is set later :-(
[09:03] <mjg59> Lure: I can't see why that would result in bad things, though
[09:03] <Lure> mjg59: and this might be exactly the case: one battery just empty (so disharging is false), the other still not reporting it is discharging 
[09:03] <mjg59> Ah
[09:04] <mjg59> Yeah
[09:04] <mjg59> Ok. It's probably worth fixing that, then
[09:04] <Lure> mjg59: but then, the percentage check is not needed
[09:04] <mjg59> Yes
[09:05] <mjg59> Right now, it looks like it'll never go through that block
[09:05] <Lure> mjg59: it will sure not get in
[09:06] <mjg59> So you think in this case we'd end up with type_battery not reporting either state?
[09:06] <Lure> mjg59: and I have seen both charging/discharging being false on my machine when fully charged
[09:07] <Lure> mjg59: never monitored hal events when switching from travel to built-in though
[09:07] <Lure> mjg59: do you have contacts with upstream author?
[09:08] <mjg59> Yeah
[09:08] <mjg59> Lure: Would you mind commenting in the upstreaem bug?
[09:08] <Lure> mjg59: upstream bug?
[09:08] <mjg59> Linked to from the one in Launchpad
[09:08] <Lure> mjg59: I see - I can add some points there...
[09:09] <mjg59> Thanks!
[09:09] <Lure> ;-)
[09:15] <mvo> mdz:  would it be possible to upload another dist-upgrader version? http://people.ubuntu.com/~mvo/tmp/dist-upgrader_20061017.1916_all.diff <- it fixes one crash for strange dpkg error output and ensures proper upgrading for bzr/tomboy/xserver-xorg-input (I asked tfheen earlier, but he is currently away apparently)
[09:16] <sladen> Lure: is that the multiple batteries?  I think there might be two problems (a) g-p-m not coping with multiple batteries.  (b) Us not handling hotplug events and fixing out how to get ACPI to 're-probe' for new batteries---I'm not entirely sure how to do the latter
[09:16] <keescook> permission (and sponsorship) for a main upload?  fixes bug 65763.  debdiff/changes: http://people.ubuntu.com/~kees/edgy-fixes/
[09:16] <Ubugtu> Malone bug 65763 in xorg "X configuration fails with NFS root (simple fix)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/65763
[09:16] <Lure> sladen: g-p-m has code for multi battery, but probably buggy in some special case
[09:16] <mjg59> sladen: No, the kernel deals with battery hotplug fine
[09:17] <Lure> mjg59: it does (at least here)
[09:17] <Lure> mjg59: not sure how g-p-m handles it though
[09:18] <Lure> sladen: bug is not linked just with plug/unplug battery, but also when both are loaded and first gets empty
[09:18] <sladen> mjg59: I thought I saw that it only copes with battery hotplug /if/ /booted/ with both batteries inserted
[09:18] <mjg59> sladen: No
[09:18] <mjg59> Batteries are fine
[09:19] <sladen> okay.  I don't have a Ultrabay battery to test
[09:19] <mjg59> There's two types of evaluation with batteries
[09:19] <mjg59> Whether the battery object is present, and whether there's actually a battery present
[09:19] <keescook> mdz: since tfheen is out, can I ping you for upload permission?  (see above for bug and url)
[09:19] <mjg59> The battery object is always present, so the kernel has no problem
[09:20] <Ubugtu> Malone bug 63123 in acpi-support "battery info does not change after hibernate (HP nw8240)" [Undecided,Needs info]  http://launchpad.net/bugs/63123
[09:20] <Lure> sladen: ^^ this is probably kernel bug
[09:20] <Lure> sladen: but not relatated ;-)
[09:21] <mjg59> Who is townsonu2003?
[09:21] <mjg59> towsonu2003, rather
[09:22] <sladen> mjg59: so BAT1 is present in the DSDT, but not populated?
[09:22] <mjg59> sladen: It's present and the _STA method evaluates to true
[09:22] <Burgwork> mjg59:  I have seen him in -marketing once or twice
[09:22] <mjg59> Because he keeps reassigning random bugs to acpi-support
[09:23] <mjg59> And I'd quite like him to stop
[09:24] <Burgwork> mjg59: I have his email, you want to email him
[09:27] <mdz> mvo: eating
[09:27] <mdz> mvo: will have a look though
[09:27] <mdz> keescook: yes
[09:28] <mdz> keescook: looks ok
[09:28] <keescook> mdz: great, thanks.
[09:29] <mvo> mdz: no rush, thanks
[09:29] <mdz> mvo: ok to upload
[09:31] <mvo> thanks mdz!
[09:31] <keescook> mvo: have a second to sign my upload?  :)
[09:32] <mvo> keescook: please /msg me details
[09:33] <bluefoxicy> bah there is no #ubuntu-legal
[09:33] <Lure> mjg59: added note to gnome #361583
[09:33] <Ubugtu> Gnome bug 361583 in gnome-power-manager "With Two Batteries, Twice as many Notification Bubbles" [Minor,New]  http://bugzilla.gnome.org/show_bug.cgi?id=361583
[09:37] <Burgwork> bluefoxicy: what is the issue?
[09:38] <bluefoxicy> Burgwork:  I'm confused about the MIT license is all, it seems to require "the above copyright notice and this permission notice" to be in tact but the disclaimer is below that and not mentioned as needed in tact.
[09:40] <bluefoxicy> Burgwork:  Copyright (c) 2006 SomePerson, with no disclaimer of no warranty, when a second hand redistributes?  That sounds like it could put the copyright holder at risk; but I'm not a lawyer, so I don't know.
[09:49] <mdz> Lure: is there hope?
[09:51] <Lure> mdz: I will try to reproduce it (need to boot in gnome), if not I may build a test version to try for bug reporters - but it is still just theory... 
[09:56] <ajmitch> morning all
[09:57] <sivang> hey ajmitch 
[09:58] <sfllaw> bluefoxicy: The best thing to do is to reproduce the entire copyright notice as well as the warranty disclaimer.
[09:59] <bluefoxicy> sfllaw:  I'm the one writing the software ;)
[10:08] <tfheen> keescook: aolserver4> universe; no idea.
[10:09] <keescook> tfheen: should I re-upload it?
[10:10] <tfheen> mvo: new dist-upgrader> looks ok.
[10:10] <mvo> tfheen: thanks
[10:11] <seb128> are uploads still accepted? 
[10:21] <tfheen> seb128: what is it that you want uploaded?
[10:23] <seb128> tfheen: dbus-glib to get a dbgsym, can probably wait after edgy though, I just noticed that there was no debug package when trying to get a debug bt for a crash bug 
[10:23] <seb128> those dbgsym are handy, I'm becoming lazy to build a debug package :)
[10:25] <tfheen> seb128: while useful; edgy+1?
[10:26] <seb128> tfheen: works for me
[10:26] <pitti> seb128: [nice to see them being useful] 
[10:26] <seb128> pitti: yeah, they rock
[10:26] <seb128> and apport rocks too, I really like the coredump attached
[10:26] <seb128> I can get debug backtraces without relying on the submitter
[10:27] <tfheen> keescook: sorry for being slow getting back to you; a reupload shouldn't be needed.
[10:27] <seb128> and print variables from gdb, etc
[10:27] <seb128> pitti: you rock :)
[10:27] <tfheen> keescook: I'll chase it up
[10:27] <pitti> seb128: and you!
[10:27] <keescook> tfheen: okay, no problem.  it's not high priority.  :)
[10:27] <seb128> pitti: thank *you* :)
[10:27] <desrt> goodday, buntus
[10:30] <pitti> hey desrt 
[10:30] <desrt> pitti; got some flowers for your hair?
[10:30] <pitti> desrt: will bring some!
[10:31] <mvo> can someone approve my dist-upgrader upload please?
[10:31] <pitti> desrt: in fact, I'm looking for a nice hostel ATM
[10:32] <desrt> pitti; not staying at the hotel?
[10:32] <desrt> or are you staying past the conference?
[10:33] <pitti> desrt: well, during the conference we will, of course, but not after it for some holidays
[10:33] <desrt> cool :)
[10:33] <pitti> hey rodarvus!
[10:33] <desrt> 1 week is already a lot of time to miss.
[10:33] <Kamion> mdke_: it is out of date - I said that because I'd checked :)
[10:33] <rodarvus> hi pitti :)
[10:33] <mdke_> Kamion: I downloaded it last week - shall I update it?
[10:33] <Kamion> fabbione: live coming first> no idea, check the extents with isoinfo. probably
[10:34] <ajmitch> pitti: what hotel are you at during the UDS week?
[10:35] <seb128> desrt: hi. Did you mail Claire about UDS?
[10:35] <Kamion> mdke_: as I say, it should be updated automatically on a regular basis
[10:35] <Kamion> things that require human intervention will inevitably get out of date
[10:35] <Kamion> (I have another update pending)
[10:36] <Kamion> sfllaw: I'm rebuilding the livefses now, but I'm off to bed shortly
[10:36] <desrt> seb128; yes.  i did.
[10:36] <mdke_> Kamion: that would require a fair bit of work, and I don't have access to the server either. I'll update it shortly before Edgy goes out for the website
[10:36] <seb128> desrt: ok, just making sure :)
[10:36] <Kamion> sfllaw: alternates are close to RC now, so those are good to test
[10:37] <desrt> seb128; i have yet to book my flight.  will do that tomorrow or later today
[10:37] <seb128> desrt: k
[10:37] <Kamion> sfllaw: either desktops will need to wait until tomorrow morning, or hassle somebody else in /people/ubuntu-cdimage to build them once the 'buildlive' processes running as cdimage@lithium (livefs builds) have finished
[10:37] <Burgwork> desrt: is your hotel in SF?
[10:37] <desrt> Burgwork; pitti, i think you mea
[10:39] <Kamion> mvo: dist-upgrader accepted
[10:40] <Kamion> mdke_: ok, thanks. it is out of date at present
[10:45] <mdke_> Kamion: will add to todo list, when do you think the last upload will be before Edgy?
[10:46] <sivang> can we still upload fixes to universe?
[10:47] <tfheen> mdke_: we're going to accept some select updates on Friday.  Unless we see serious regressions when RC is out or in those, that's the last uploads for edgy main.
[10:48] <mdke_> tfheen: sorry, I mean the last upload of installation-guide
[10:48] <Kamion> mdke_: tomorrow probably
[10:49] <Kamion> tfheen:   * en/appendix/preseed.xml, en/using-d-i/modules/lilo-installer.xml: Device
[10:49] <mdke_> Kamion: great.
[10:49] <Kamion>     name updates for no-more-devfs.
[10:49] <Kamion> tfheen: ^-- pending installation-guide changelog
[10:49] <Kamion> tfheen: I could upload it now, maybe
[10:51] <mvo> thanks Kamion
[10:52] <Kamion> tfheen: unapproved main: xorg/1:7.1.1ubuntu5 kdebindings/4:3.5.4-0ubuntu2 python-setuptools/0.6c3-1ubuntu4 xfdesktop4/4.3.99.1svn+r23428-0ubuntu2 human-cursors-theme/0.4-0ubuntu1 qt4-x11/4.2.0-1ubuntu5 python-central/0.5.6ubuntu2
[10:54] <Kamion> tfheen: infinity/mdz will have to handle the queue when they're around; I need to go now
[10:55] <mdz> I'm here
[10:55] <mdz> for a bit
[10:56] <Kamion> I've accepted my gfxboot-theme-ubuntu upload, since mdz approved it earlier (translation updates)
[10:56] <Kamion> otherwise, got to run
[10:57] <Kamion> mdz: see my comment about live CD builds above, once the buildlive processes are all gone
[10:57] <mdz> Kamion: I can't stay long myself, need sleep
[10:58] <mdz> didn't quite nail my $TZ change
[10:58] <mdz> but I'll check before I go
[10:58] <mdz> Kamion: gfxboot-theme-ubuntu isn't needed for RC?
[11:07] <mdz> I'm heading back to the hotel but will be back online from there to do desktop CD builds
[11:08] <Lure> mjg59: booted gnome, but cannot get g-p-m icon in tray 
[11:08] <Lure> mjg59: did change option as always show icon, but does not help - any idea
[11:21] <tfheen> Kamion: sorry, was afk
[11:22] <tfheen> Kamion: what's the xorg diff?
[11:23] <tfheen> mdz: once you're around; what's the diff for xorg?
[11:23] <tfheen> mdz: python-setuptools and python-central are approved.
[11:30] <rem64> hi all
[11:31] <BHSPitLappy> yo
[11:31] <rem64> is there someone here?
[11:33] <keescook> tfheen: is that the xorg upload with my name on it? mdz approved it for fixing bug 65763
[11:33] <Ubugtu> Malone bug 65763 in xorg "X configuration fails with NFS root (simple fix)" [Undecided,Fix committed]  http://launchpad.net/bugs/65763
[11:34] <tfheen> keescook: ok, looks sane.  That is, if NFS is sane in any way.
[11:34] <keescook> hehe
[11:43] <sivang> Feisty , then it is :)
[11:44] <tfheen> mdz: 23:23 < tfheen> mdz: python-setuptools and python-central are approved.
[11:44] <tfheen> mdz: xorg seems approvable too.
[11:46] <mdz> tfheen: they're needed for RC?
[11:47] <tfheen> mdz: python-central fixes two RC bugs, at least.  We can accept it after RC if you'd rather have us do that.
[11:48] <tfheen> python-setuptools isn't needed for RC, but it allows the use of -setuptools without 2.5
[11:48] <mdz> tfheen: the python-central diff I saw looked non-trivial; how much review and testing has it seen?
[11:49] <mdz> new set of ubuntu/desktop CDs are now up
[11:49] <mdz> sfllaw: ^^
[11:49] <tfheen> mdz: doko and mvo worked together a fair bit on reproducing the errors and fixing them today.
[12:03] <mdz> tfheen: I've stared at it a bit more and I hope that it fixes more than it could break
[12:03] <mdz> accepted that and xorg
[12:04] <mdz> but I'm not convinced we should ditch the current candidate for these fixes; we will need all the time we can get to validate it
[12:04] <mdz> kubuntu and edubuntu desktop builds in progress now
[12:05] <tfheen> mdz: agreed.
[12:06] <ogra> only desktop ?
[12:06] <tfheen> mdz: I have no idea about kdebindings, qt4-x11 and xfdesktop4 in the queue and I am reluctant to accept human-cursors-theme.
[12:06] <mdz> ogra: yes
[12:06] <mdz> Oct 17 21:36:58 <Kamion>        sfllaw: alternates are close to RC now, so those
[12:06] <mdz>  are good to test
[12:06] <mdz> tfheen: kdebindings is an ftbfs fix and it isn't out of date, so it's not urgent
[12:07] <sfllaw> Hurray!
[12:07] <sfllaw> Will download now.