[04:34] <electrofreak> why is there the lack of the kernel config in /proc/. I swear it was there in previous versions of ubuntu
[04:37] <TheMuso> electrofreak: Because its found in /boot
[04:37] <electrofreak> TheMuso: ah, that'll work. thanks for pointing that out
[04:38] <TheMuso> np
[05:37] <pitti> Good morning
[06:23] <diwic> Good morning pitti
[06:28] <pitti> hey diwic
[06:28]  * pitti NEWs the new kernel
[06:32] <diwic> pitti: For Lucid, Maverick, or what?
[06:32] <pitti> maverick
[06:32] <TheMuso> Ah that explains linux-generic etc being kept back on update a little earlier.
[06:32] <TheMuso> Didn't even think to consider that. :)
[06:32] <pitti> right, and why today's images failed to build
[06:34] <diwic> Good morning to TheMuso as well, although I guess it's evening in Australia.
[06:34] <TheMuso> diwic: Mid afternoon to be more precise.
[07:09] <hdon> !!!!
[07:10] <hdon> i found a security vulnerability in sudo!
[07:11] <micahg> hdon: please file a private bug against the sudo package and flag it security vulnerability
[07:11] <micahg> hdon: on launchpad under ubuntu
[07:12] <hdon> i am creating a ttyrec to demonstrate the problem
[07:13] <DreadKnight> 10.10 is fail for me.... the internet connection fails for about 10-20 seconds every 5 minutes or so, not cool
[07:14] <micahg> DreadKnight: please seek support in #ubuntu+1
[07:14] <DreadKnight> ok
[07:17] <hdon> micahg, perhaps it is not a bug,  but it is not the behavior i expected
[07:17]  * hdon reads the man page
[07:17] <hdon> oh
[07:17] <hdon> i guess it's not the sudo man page that it woudl be in
[07:17] <hdon> but gnome-terminal
[07:20] <sbeattie> hdon: if it's not already covered by https://wiki.ubuntu.com/SecurityTeam/FAQ#Sudo perhaps you could add it there.
[07:21] <kees> we should really add sudo -K to .bash_logout and gnome-session to avoid this :)
[07:22] <hdon> sbeattie, thanks for the tip
[07:23] <sbeattie> kees: heh, yeah.
[07:23]  * hdon adds
[07:23] <hdon> kees, thanks
[07:23] <hdon> sbeattie, doesn't seem to do the trick
[07:23]  * sbeattie also wants to resurrect the patch to sudo he was working on to add an option to kill all cached sudo tokens
[07:24] <hdon> sbeattie, ~/.bash_logout is not being executed when i exit bash and/or close the terminal
[07:27] <sbeattie> hdon: ah, gnome-terminal is not starting bash as a login shell.
[07:27]  * sbeattie discovers he already had "/usr/bin/sudo -k" in his .bash_logout
[07:30] <sbeattie> ... though whether the shell is started as a login shell is configurable under gnome-terminal's profile settings.
[07:40] <dholbach> good morning
[08:00]  * hdon looks
[08:00] <hdon> sbeattie, there's a check box
[08:01] <hdon> that worked
[09:00] <ravibn> Hi!
[09:00] <ravibn> Any one here?
[09:09] <apw> as package sets _still_ don't confer nomination accept rights ... i wonder if someone could accept the nom for lucid on bug #601192
[09:25] <smb> cjwatson, pitti I have another question on SRU able changes. In l-b-m we got backported drivers. At the moment the same source package produces l-b-m-wireless and l-b-m-alsa so people do not have to opt in for all backported modules. Is it allowed to add additional binary packages when new types of modules should be required. The might be need for l-b-m-input or l-b-m-wwan soon.
[09:26] <pitti> smb: we usually don't allow new packages in SRUs, but since this is really more like -backports, it sounds fine from my side; it's what lbm is for, after all
[09:28] <smb> pitti, Right, it is backports for what its worth. I just wanted to be sure this is ok. And not needs a MIR (I would think this is only needed for new source packages but I just might be plainly wrong)
[09:28] <pitti> smb: correct, MIRs are source based
[09:28] <pitti> the new binary will just go to main as well
[09:29] <smb> pitti, ok, perfect. Thanks. :)
[10:54] <wgrant> pitti: pkgstriptranslations is mangling Installed-Size badly.
[10:54] <pitti> wgrant: version 70 you mean?
[10:54] <wgrant> It assumes that du splits the size and path with a space -- it in fact uses a tab.
[10:54] <wgrant> Right.
[10:55] <wgrant> This is causing rejections.
[10:55] <pitti> wgrant: and you tell me that 5 seconds after I upload version 72 :)
[10:55] <pitti> wgrant: hm, odd; do you have a build log?
[10:55] <wgrant> pitti: http://launchpadlibrarian.net/51966247/buildlog_ubuntu-maverick-sparc.gnome-power-manager_2.30.1-1ubuntu2_BUILDING.txt.gz and http://launchpadlibrarian.net/51966250/upload_1871365_log
[10:55] <wgrant> (geser pointed me at them)
[10:56] <pitti> http://launchpadlibrarian.net/51966250/upload_1871365_log is 404
[10:56] <wgrant> Er, add a .txt, sorry.
[10:57] <pitti> wgrant: thanks for pointing out; will fix immediately
[10:57] <wgrant> Thanks to geser for pointing the upload failure out in the first place.
[10:58] <pitti> geser: thanks
[10:59] <pitti>     self.assert_(re.match('^Installed-Size: \d+$', l))
[10:59] <pitti> AssertionError
[10:59] <pitti> wgrant: ok, added to test suite
[10:59] <wgrant> Great.
[10:59] <wgrant> Now, hopefully pkgbinarymangler doesn't itself have translations!
[10:59] <pitti> wgrant: no, it builds itself with NO_PKG_MANGLE for reasons like this :)
[11:00] <wgrant> Heh, fortunate.
[11:03] <pitti> meh, you can test however much you want, *something* in this bloody beast will fail
[11:03] <pitti> sorry about that
[11:03] <pitti> wgrant: uploaded
[11:03] <wgrant> Great.
[11:03] <pitti> is there a way to get a list of recent FTBFSes?
[11:04] <pitti> so that I can retry them in two hours
[11:06] <wgrant> It's an upload failure, not a normal build failure, so https://edge.launchpad.net/ubuntu/+builds?build_text=&build_state=uploadfail should do it.
[11:06] <wgrant> Looks like there's only been a couple.
[11:08] <pitti> wgrant: thanks, I'll go through that once the fixed version is in
[11:10] <pitti> just three for now
[11:15] <pitti> oh noes
[11:16] <pitti> it seems that they now fail to build because apt gets confused by an extra output line of dpkg-deb; I reverted that in version 72, but seems that's causing it to fail now
[11:16]  * pitti shoots himself
[11:19] <doko_> pitti: is this the same? http://launchpadlibrarian.net/51973452/buildlog_ubuntu-maverick-i386.pylirc_0.0.5-2_FAILEDTOBUILD.txt.gz
[11:20] <pitti> elmo, lamont: I'm sorry, seems that the recent pkgbinarymangler confuses apt, causing everything to FTBFS
[11:20] <pitti> elmo, lamont: apparently it stumbles over an "INFO: version" line; I reverted this, but now we again have the situation that I can't pull myself out of the swamp
[11:21] <geser> pitti: as far as I can see on https://edge.launchpad.net/ubuntu/+builds?build_text=&build_state=uploadfail only 3 builds got hit by it till now
[11:21] <pitti> seems we need a manual build of current pkgbinarymangler; after that I can give back everything that failed
[11:21] <pitti> doko_: presumably
[11:21] <wgrant> geser: Different issue.
[11:23] <wgrant> An easy fix is to just restore the buildd chroots from yesterday, I suppose... they have pkgbinarymangler held.
[11:23] <cjwatson> apw: approved the nomination.  can you poke bdmurray about the nominations / package sets bug, to see if he can get that fixed?
[11:24] <apw> cjwatson, yeah i regularly poke at them on tha tone, but they say its not important in essence
[11:24] <apw> i tend to !concur with that position
[11:24] <pitti> wgrant: I guess that needs lamont/elmo powers, though?
[11:24] <cjwatson> apw: that's why I suggested specifically bdmurray; he's seconded to Launchpad from platform, and I understand is putting some effort into fixing things important to platform
[11:25] <apw> ahh very good, nice, liking your thought process :)
[11:26] <wgrant> pitti: Ah, maybe, not sure if anyone else can do that.
[11:26] <cjwatson> wgrant: if I had the previous chroots, I think I could probably stuff them back in
[11:27] <cjwatson> I believe I can do that with manage-chroot.py on cocoplum; I certainly used to be able to, though I don't remember whether that's before or after archive-master stopped being builddmaster
[11:27] <wgrant> cjwatson: http://launchpadlibrarian.net/50312513/chroot-ubuntu-maverick-i386.tar.bz2
[11:27] <wgrant> (link retrieved from dogfood, but it's the old production one)
[11:27] <cjwatson> can I have the links for all architectures?
[11:27] <pitti> we only need i386, no?
[11:27] <pitti> pkgbinarymangler is arch:all
[11:28] <pitti> we just need to get the new version built and into the archive
[11:28] <wgrant> Roght, that's whatI was thinking.
[11:28] <cjwatson> ah
[11:28] <cjwatson> let me see then
[11:28] <pitti> in fact, I have the .deb right here, but I guess we can't manually upload that
[11:28] <elmo> you know chroot management is done on cesium now, right?
[11:28] <elmo> it's possible cocobanana still has DB access to do it, but I'd hope it doesn't
[11:28] <cjwatson> elmo: as I said above - I wasn't sure whether it was still possible from cocoplum
[11:29] <cjwatson> mm, yeah, ident auth failed for fiera
[11:29] <cjwatson> 2010-07-15 10:28:34 INFO    Creating lockfile: /var/lock/launchpad-mangage-chroot.lock
[11:29] <cjwatson> classy, btw
[11:29] <elmo> I'll do it
[11:29] <cjwatson> thanks
[11:31] <pitti> cjwatson, elmo, lamont: I set all main builders to manual, to avoid further FTBFSes
[11:37]  * apw throws pitti a stought rope
[11:37] <wgrant> Hmm, not building yet?
[11:37] <pitti> wgrant: I set everything to manual
[11:37] <pitti> I'm waiting on the word to retry pkgbinarymangler
[11:38] <pitti> i. e. when elmo/cjwatson say that the old chroot has been enabled again
[11:38] <cjwatson> not I
[11:38] <wgrant> It appears to be.
[11:38] <pitti> oh
[11:38]  * cjwatson wonders what magic check wgrant is using
[11:39] <pitti> wgrant: trying then
[11:39] <wgrant> cjwatson: I exported the chroot URL via the API a couple of months back. https://edge.launchpad.net/api/devel/ubuntu/maverick/i386 handily shows it now.
[11:39] <cjwatson> aha
[11:40] <wgrant> Yay, building. You caught buildd-manager at just the right time...
[11:40] <wgrant> Ah, or all the PPA buildds have vanished again.
[11:41] <pitti> yohoo, works
[11:41] <pitti> i386 buildds back to manual
[11:41] <wgrant> Phew.
[11:41] <geser> wgrant: do you know if downloading such a chroot tar would work with pbuilder? that would save me some time to setup my own for i386
[11:42] <wgrant> geser: The sources.list is different, but apart from that it should be OK.
[11:42] <wgrant> (the buildd chroots use ftpmaster.internal rather than a.u.c)
[11:42] <pitti> wgrant: hm, seems oem:common PPA has its own chroot?
[11:43] <wgrant> pitti: Impossible.
[11:43] <pitti> wgrant: hm, it failed again there, same error
[11:43] <pitti> https://edge.launchpad.net/~oem-archive/+archive/common/+build/1873638/+files/buildlog_ubuntu-lucid-i386.pkgbinarymangler_74common1_FAILEDTOBUILD.txt.gz
[11:43] <pitti> wgrant: (not sure whether you can see this)
[11:43] <wgrant> I can't, no.
[11:43] <wgrant> Is it possible that they've overridden the hold somehow?
[11:43] <pitti> it's a nonvirtual PPA
[11:43] <wgrant> Also, that's lucid.
[11:44] <pitti> ah, right
[11:44] <wgrant> So maybe yu just need to delete pkgbinarymangler from the PPA for a few minutes.
[11:44] <pitti> wgrant: I can't
[11:44] <wgrant> :(
[11:44] <pitti> elmo: is it possible that you can restore the lucid chroot as well for a minute?
[11:44] <wgrant> The lucid chroot isn't broken, is it?
[11:44] <pitti> but the oem:common PPA is now (same problem)
[11:45] <apw> pitti, would someone have access to delete the package from the PPA ?
[11:45] <pitti> apw: cody-somerville perhaps
[11:45] <wgrant> pitti: Oh, has the lucid chroot just had it unheld too?
[11:45] <apw> there must be an elmo equivalent for PPA's i recon
[11:45] <pitti> cjwatson, elmo: maverick pkgbinarymangler built, so the chroot can be swapped back
[11:45] <elmo> (sorry, hotel called me away)
[11:45] <pitti> wgrant: right
[11:45] <elmo> but it's been done
[11:45] <elmo> oh
[11:45] <wgrant> pitti: Don't we want to wait for publication?
[11:46] <elmo> pitti: surely if I swap it back it'll add the old/broken pkgbinarymangler, no?
[11:46] <pitti> wgrant: well, we can, but all buildds are on manual
[11:46] <wgrant> Oh, I guess swap back, then unmanual.
[11:46] <elmo> or will it get upgraded as part of the build?
[11:46] <wgrant> Right.
[11:46] <pitti> elmo: the problem is that builds upgrade to the broken one
[11:46] <YokoZar> Is there a way to change the email address of my bzr commits without un/recommitting (not yet merged) ?
[11:46] <wgrant> elmo: It gets upgraded.
[11:46] <elmo> ok
[11:46] <wgrant> YokoZar: No.
[11:46] <pitti> elmo: version 70 was still fine
[11:46] <pitti> Preparing to replace pkgbinarymangler 70 (using .../pkgbinarymangler_71_all.deb) ...
[11:47] <elmo> pitti: lucid swapped back
[11:47] <pitti> that's when things started to go wrong
[11:49] <elmo> pitti: and maverick rolling forward now
[11:49]  * pitti waits on buildd-queue to kick in
[11:49] <geser> pitti: luckily you didn't these uploads on a friday short before you leave for the weekend
[11:49] <pitti> geser: deliberately
[11:49] <apw> pitti, won't we still need to wait for the new version to publish before putting any builds thorugh?
[11:49] <elmo> pitti: mavrick back on the 'new' chroot
[11:49] <pitti> apw: correct
[11:50] <pitti> elmo: thanks
[11:50] <pitti> lucid oem:common mangler building now
[11:50] <pitti> apw: I'll wait for this and then mass-retry
[11:50] <pitti> (and set buildds to auto again)
[11:52] <elmo> pitti: let me know when lucid can roll forward again
[11:52] <pitti> elmo: will do; ETA 2 mins
[11:53] <pitti> elmo: done; please switch back lucid chroots
[11:53] <pitti> elmo: thanks so much, and sorry for the hassle!
[11:54] <elmo> pitti: done
[11:55]  * pitti makes a mental note to add apt testing should he ever change dpkg-deb again
[11:55] <cjwatson> is anyone seeing bug 605614 on a system that *doesn't* have an ATI graphics card?
[11:56] <cjwatson> apw: ^- I'm thinking that this might be a straightforward kernel bug; mjg59 did warn that there might be some cases where KMS drivers fail to go from VESA->native
[11:57] <cjwatson> (cf. http://irclogs.ubuntu.com/2010/04/08/%23ubuntu-kernel.txt)
[11:59] <apw> cjwatson, from the panic there i'd say so yes, its a gpu lockup it seems
[12:00] <cjwatson> I'll clone off a kernel tas
[12:00] <cjwatson> k
[12:18] <geser> apw: have you an idea why with the -8 kernel in maverick X only detects one of my two monitors while with the -7 kernel both are detected? /me goes to file a bug about it
[12:19] <apw> geser, no specific info on that no ... obviously the kernel has been rebased on mainline so anything can and does happen
[12:24] <seb128> is there an easy way to reinstall grub from a livecd? ie running update-grub or something
[12:25] <seb128> it's on a box where a winxp reinstalled kicked grub out of the mbr or something
[12:26] <geser> seb128: I'd try dpkg-reconfigure grub-pc in the chroot with the system
[12:27] <seb128> ie, on the installed partition there?
[12:27] <seb128> I've tried to run update-grub there without success
[12:28] <geser> update-grub only updates the grub config file
[12:28] <seb128> install-grub hd0 didn't work either
[12:37] <seb128> geser, ok, wiki was helpful, https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows
[12:38] <seb128> grub-install works you just have to mount the install you want to restore and give it as an option
[12:43] <pitti> seb128: I usually mount and chroot into the installed partition and run sudo grub-install /dev/sda
[12:44] <pitti> ah, seems you figured this out
[12:46] <seb128> pitti, yes, thanks
[12:47] <cjwatson> seb128: also https://help.ubuntu.com/community/Grub2#Reinstalling%20from%20LiveCD "METHOD 3 - CHROOT", which is what we usually refer people to upstream
[12:47] <cjwatson> (I would steer clear of the other methods - I need to find time to do some redrafting on that page
[12:48] <seb128> cjwatson, that's what I did yes
[12:48] <cjwatson> the problem with the grub-install --root-directory= approach is that it gives you the grub images from the live CD rather than those on the system, which isn't always necessarily desirable
[12:48] <seb128> right
[12:49] <seb128> in this case that's lucid on both systems so that's ok ;-)
[13:04]  * pitti cautiously tries a new package build, now that the new pkgbinarymangler has been published
[13:07] <towolf> something's wrong with new freetype.
[13:07] <towolf> http://i.imgur.com/sR2hO.png
[13:08] <towolf> looks like its limited to opentype.
[13:15] <towolf> should i take that to freetype upstream or file in launchpad first?
[13:26] <pitti> yay, maverick builds working again
[13:26]  * pitti opens the floodgates and sends annoucnement
[14:38] <seb128> hum
[14:38] <seb128> had somebody see "fb: conflicting fb hw usage inteldrmfv vs VESA VGA"
[14:38] <ricotz> hello, please let builds like these stop if there are older than 100 days or so - https://edge.launchpad.net/~patrick-hetu/+archive/ppa/+build/739056
[14:38] <seb128> bugs on maverick?
[14:41] <seb128> not sure where to report the bug
[14:44] <cjwatson> ricotz: we don't manage PPAs here, try #launchpad
[14:45] <smoser> cjwatson, so if i have a 'default X' in my menu.lst, that will trump 'savedefault' ?
[14:45] <cjwatson> smoser: so 0.97's stage2 does read /etc/grub/default, and in the once-only case it writes a modified block back to disk before booting
[14:45] <smoser> yeah, so i really have no stage 2
[14:45] <cjwatson> let me check
[14:46] <cjwatson> pvgrub will be the stage2 equivalent, I expect
[14:47] <cjwatson> smoser: you have to have "default saved", or the saved default won't be used
[14:47] <smoser> ok. i have some things to test here. i'm fairly sure now that i need to have 'saved' in menu.lst
[14:47] <smoser> yeah
[14:48] <cjwatson> let me ask a Xen developer I know
[14:52] <smoser> so i'm confused as to why grub-reboot calls grub (with set-default and --once) where grub-set-default just writes the entire 'default' file itself.
[14:53] <cjwatson> smoser: the savedefault patch is apparently in pvgrub, so you should at least not be entirely doomed
[14:53]  * cjwatson curses smoser for making him dredge up 0.97 memories
[14:53] <ricotz> cjwatson, i already done this, but i was hoping to find some supporters
[14:54] <smoser> cjwatson, i shouldn't really be wasting time on this, so i definitely should'nt be wasting yours.
[14:54] <smoser> i'd like to have boot once behavior, as in a ec2 instance-store instance, if you boot into a bad kernel you're 100% hosed otherwise.
[14:54] <cjwatson> smoser: I'm not entirely sure why it bothers with that either.  I think you could just write out the file directly.
[14:54] <smoser> but i have this same work to do for grub2, so I'll pester you (and #grub) with those questions which wont have the bad memories.
[14:54] <cjwatson> that's all the implementation of savedefault --once seems to do.
[14:55] <geser> ricotz: I've read recently about this problem, but I can't find where right now, still looking. It is because debhelper 7 is in hardy-backports and the script which checks the debwait that debhelper >= 7 is available but doesn't consider that your PPA doesn't use hardy-backports and retries anyways
[14:55] <smoser> cjwatson, i thought it might be in order to work with an older grub or something.
[14:55] <smoser> one that didn't just write 0:1, but did something else.
[14:55] <cjwatson> smoser: no, I think the reason it's done in C is because it needs to parse out the previous default from /etc/grub/default, and there was already C code to do that
[14:56] <cjwatson> because grub-reboot is "read previous default from /etc/default/grub, then write $prev_default:$new_default"
[14:56] <smoser> well, certainly that would be almost impossible to do in shell :)
[14:56] <smoser> thanks cjwatson .
[14:57] <cjwatson> if you don't want to rewrite it, can you just call grub?  It doesn't actually have to be the running grub
[14:57] <cjwatson> as long as the installed bootloader has support for parsing the $previous:$new syntax in /etc/grub/default, which apparently pvgrub does
[14:57] <ricotz> geser, yes, they get started like every hour and with the current ppa queue situation it is waste of resources
[14:58] <smoser> well, at the moment, my legacy-grub-ec2 conflicts with grub and doens't have the grub binary. i can rewrite that easy enough if it is a win for --once.
[14:59] <smoser> oh, and grub moans when running it on ec2 anyway, because it can't get the bios drives sorted out
[15:00] <cjwatson> smoser: might be easier to just write a standalone program to do the parsing.  can't be that hard.
[15:03] <smoser> sh -c 'IFS=: read default once < /boot/grub/default'
[15:03] <smoser> but it seems at this point like its for naught
[15:03] <smoser> as
[15:03] <smoser> $ grep ^default /boot/grub/menu.lst
[15:03] <smoser> default         saved
[15:04] <smoser> $ head -n 1 /boot/grub/default
[15:04] <smoser> 0:1
[15:04] <smoser> rebooted, came up in '1'
[15:04] <smoser> but that file still has '0:1'
[15:04] <smoser> rebooted again just for kicks
[15:04] <smoser> still in '1'
[15:04] <smoser> and file still the same.
[15:04] <smoser> i'll have to get the amazon folks to help me.
[15:21] <Daviey> Is anyone ACK'ing SRU's today?
[15:24] <pitti> I did some processign today
[15:25] <Daviey> pitti, would you mind looking at bug #605358 , please? :)
[15:25] <pitti> Daviey: not now, sorry
[15:25] <Daviey> pitti, thanks anyway
[15:43] <cjwatson> smoser: it could be that pvgrub is writing to /etc/grub/default in the dom0 rather than in the domU or something
[15:44] <cjwatson> (if that makes sense.  I never did get my head around Xen.)
[15:45] <smoser> well if it was in the dom0, that would be quite bad !
[15:45] <smoser> :)
[16:14] <cjwatson> apw: hm, the original reporter of bug 605614 has quite a different crash from the one that geser reported.  Do you think geser should file a separate bug?
[16:15] <apw> cjwatson, definatly if they look differnet, we can always dup them back
[16:15] <cjwatson> ah, well, there is a GPU lockup in there
[16:15] <cjwatson> also weird stuff like "*ERROR* invalid framebuffer id" before that
[16:15] <cjwatson> I'm not quite sure, somebody more qualified would need to check
[16:25] <achiang> for upstart debugging (http://upstart.ubuntu.com/wiki/Debugging) where it says add "--debug" after init=.... ; just want to confirm that means unpacking the initrd to modify that command, right?
[16:27] <cjwatson> achiang: no, it goes on the kernel command line.  If you're using GRUB then you can edit that on the fly from the boot loader menu.
[16:28] <cjwatson> (You may not have an init= item there; that doesn't matter.
[16:28] <cjwatson> )
[16:28] <achiang> cjwatson: hm, do i need to specify the init= as well? or does just a plain old '--debug' anywhere on the kernel cmdline magically work?
[16:29] <cjwatson> the latter.  you don't need to specify init=, that's just for people installing upstart in some non-default location.
[16:29] <achiang> ah, thx
[16:29] <cjwatson> dunno why that page talks about it at all.
[16:30] <achiang> i'll clean it up in a bit
[16:30] <ari-tczew> mvo: question about update-manager: is it a new feature? previously I could see a package name, not I can see only package's description. it's not good idea (IMHO).
[16:31] <mvo> ari-tczew: its a new feature, the pkgname is still there, just second instead of first.
[16:34] <geser> cjwatson: comparing the both Xorg crash call traces from the both logs in that grub2 bug, they look pretty similar
[16:37] <cjwatson> geser: ok
[16:37] <cjwatson> geser: did you have the "*ERROR* invalid framebuffer id" as well?
[16:37] <dholbach> Day 4 of https://wiki.ubuntu.com/UbuntuDeveloper Week starts in 23 minutes in #ubuntu-classroomDay 4 of https://wiki.ubuntu.com/UbuntuDeveloper Week starts in 23 minutes in #ubuntu-classroom
[16:37] <cjwatson> maybe not relevant since I've sometimes seen that too
[16:38] <geser> cjwatson: no
[16:41] <hv> Hi. I am having trouble changing the X11 cursor theme: The change does not propagate to all places.  For instance, try resizing a window after you change the X11 cursor theme, and see if the new theme is used.
[16:49] <dholbach> didrocks, vish, ttx, charlie-tca, beuno-lunch: all set for UDW sessions later on?
[16:50] <didrocks> dholbach: ready to roll :)
[16:50] <dholbach> fantastico
[16:50] <dholbach> :)
[16:50] <vish> hey .. :)
[16:50] <vish> yup
[16:50] <dholbach> :-D
[16:50] <vish> damn it i got stuck after didrocks ! a tough act to follow :s
[16:51] <didrocks> vish: ahah ;)
[16:51] <vish> :)
[16:51] <ttx> dholbach: yes
[16:51] <ttx> dholbach: I even got my DSL fixed
[16:54] <charlie-tca> ready as I can be
[17:45] <beuno> dholbach, not really, have been flooded today  :(
[17:48] <dholbach> beuno: you still have some time :)
[17:49] <beuno> yeah, I have an outline in my head, but haven't managed to bring it down to bytes
[17:49]  * dholbach hugs beuno
[18:34] <smoser> cjwatson, around ?
[18:34] <smoser> I'm considering providing a grub-set-default in legacy-grub-ec2 that would divert /usr/sbin/grub-set-default and wrap it.  it would then call both grub-set-default.real and grub-set-default-legacy-ec2. so that a user who just expected to run 'grub-set-default' would get the end result independent of which loader was used.
[18:39] <smoser> the only negative i can think of the above is that the user may read the wrong config file (ie, menu.lst instead of grub.cfg) and have the wrong entry (in the case they are not alighed).
[19:15] <LucidFox> Okay, if anyone's interested, I've fixed the white buttons bug with Murrine/Ambiance/Radiance and Cairo 1.9
[19:15] <LucidFox> just need a core developer to sponsor it
[19:15] <LucidFox> bug #605979
[20:03] <ari-tczew> TheMuso: did you comment on MoM "Please do not touch this." on jack-audio-connection-kit  ?
[20:09] <maxb> bdrung: Hi, those Eclipse code imports you requested - The layout of the svn repository would seem to imply that they should be imported as one branch, not three.
[20:12] <bdrung> maxb: i need them separately, because the two -config and -feature repositories needs to be nested into the eclipse-build repository.
[20:13] <maxb> Hmm. Well I won't presume to assume that Eclipse buildsystems are sane :-)
[20:14] <bdrung> maxb: they aren't same ;)
[20:14] <bdrung> sane
[20:14] <maxb> This is probably going to mean bzr-svn won't really understand branches and tags in svn for these, is that ok?
[20:15] <bdrung> maxb: the problem is that these three are all eclipse projects and eclipse projects can be nested
[20:15] <bdrung> maxb: yes, that's ok
[20:16] <bdrung> maxb: the next step is to import the complete eclipse project. IIRC there was a bug preventing it
[21:16] <blink_> alright, I need to rebuild gnome-volume-control-applet from source because the volume step by mouse wheel is hard coded instead of referencing the value in gconf. where I can I find the build settings that were used in creating the package in apt so I can replicate it on my own machine (with the change in source to fix this); I  have the apt sources for gnome-media here...
[21:16] <blink_> or should I just report this as a bug here or upstream and hope somebody picks it up
[22:34] <cjwatson> smoser: I'd really prefer that you didn't divert grub-set-default.  My hunch is that that will get really messy.
[22:35] <cjwatson> smoser: stuff that has different implementations between legacy and 2 already gets pretty complicated
[23:12] <TheMuso> ari-tczew: Yes, because I will be taking care of it shortly, and there is some other jack related stuff that needs taking care of, before that can be merged.
[23:26] <ari-tczew> TheMuso: ok. I won't touch it.
[23:48] <shadeslayer> any bughugger devs around?