[00:01] <cody-somerville> Is there a udeb include and exclude file? I remember reading something about that.
[00:02] <cjwatson> yes, there's one on the standard CD images. It contains netcfg, ethdetect, pcmcia-cs-udeb, and wireless-tools-udeb.
[00:03] <cjwatson> anyway, I could debug ericdc's problem if I could see the syslog.
[00:05] <cody-somerville> cjwatson, What takes precedence? The heuristics listed in your e-mail or the exclude list?
[00:08] <cjwatson> cody-somerville: (they're rules not heuristics.) excludes seem to be dropped after everything else, apart from dependency resolution
[00:09] <cjwatson> TBH it's easiest to look at anna.c:choose_modules() in the anna source package if you want details; it's not that hard to read
[00:12] <cody-somerville> ok
[00:14] <cjwatson> I've had trouble tracking down why people were seeing pppoe questions on customised images in the past and would actually quite like to sort it out with a syslog
[00:16] <cjwatson> but now, bed
[00:54] <StevenK> mv planet-ubuntu Danny-Piccirillo-planet
[00:56] <directhex> StevenK, blogspot rss shat itself, then
[00:58] <StevenK> directhex: Looks like
[01:00] <lool> FIS partition ends at 16777215B and doesn't leave enough room for FIS 16777216B
[01:00]  * lool sighs
[01:00] <slangasek> cjwatson: ...long day. :)
[01:03] <jdong> now it's release candidate released :)
[01:03] <lifeless> cjwatson: bug 12230
[01:04]  * jdong thought it was better when it was release candidate candidate released
[01:04] <jdong> for those people who read topics right to left
[01:04] <lifeless> cjwatson: I find the repeated 'is it really still a bug' questions converge on 100% noise. Do you?
[01:04] <jdong> O_O a 5 digit bug
[01:05] <lifeless> jdong: yes, but its just an example of the make-work pattern in the 'bug team' that I have grown to loathe
[01:05] <lifeless> its been triaged; its been analysed, the root cause is known.
[01:05] <jdong> If I may appoint as a quote of the day:
[01:05] <jdong> "Not a high priority, but should be fixed for Hoary so that Robert can remove the
[01:05] <lifeless> all it needs is to be fixed.
[01:05] <jdong> workaround and get better throughput"
[01:05] <lifeless> and indeed, the cscvs test suite *still* works around this bug
[01:10]  * lool sighs
[01:11] <lool> Another 3 hours of sleep wasted, solution was trivial
[01:16] <LaserJock> lifeless: do you actually want the status changed to Confirmed on that bug? it's still set at Incomplete
[01:16] <lifeless> LaserJock: I replied via mail, the mail processor should andle it
[01:16] <lifeless> oh, frell I forgot to indent
[01:16] <lifeless> *so* annoying.
[01:17] <LaserJock> just thought I'd check ;-)
[01:17] <lifeless> thanks, appreciated
[01:20] <alex-weej> does anyone semi-officially maintain linux 2.6.29?
[01:20] <alex-weej> (an ubuntu package that is)
[01:23] <TheMuso> alex-weej: there are mainline builds
[01:23] <TheMuso> alex-weej: let me get an URL for you
[01:24] <TheMuso> alex-weej: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.29.1/
[01:26] <alex-weej> mainline = vanilla?
[02:51] <TheMuso> dtchen: I've created a jaunty pulseaudio branch to allow for handling of SRUs etc, while the ubuntu branch will remain trunk/karmic development branch.
[02:59] <slangasek> TheMuso: this linux-ports upload includes renames of the powerpc kernel packages; not mentioned in the changelog at all, and not acceptable post-RC
[02:59] <slangasek> TheMuso: so I'm rejecting this out - can you fix that and reupload?
[03:13]  * hyperair groans
[03:13] <hyperair> shit. nautilus-share segfault huh
[03:14] <hyperair> now if only i had the time to go digging for bugs right now
[03:30] <TheMuso> Can I assume the linux-ports rejection was due to no bug task for the ext4 bugfix?
[03:31] <StevenK> [11:59] < slangasek> TheMuso: this linux-ports upload includes renames of the powerpc kernel packages; not mentioned in the changelog at all, and not acceptable post-RC
[03:31] <StevenK> [11:59] < slangasek> TheMuso: so I'm rejecting this out - can you fix that and reupload?
[03:33] <TheMuso> StevenK: thanks must have missed that.
[03:33]  * TheMuso ponders how that could have happened, and looks
[03:33] <StevenK> TheMuso: The next line was you disconnecting :-P
[03:33] <TheMuso> heh right
[03:42]  * TheMuso finds the problem... Damn auto-generated control files. :S
[04:17] <ebroder> Not cool: marking a public bug a duplicate of a private bug so I can't see the discussion
[04:19] <cody-somerville> ebroder, I'm sure they didn't do it on purpose.
[04:19] <cody-somerville> ebroder, Whats the bug number?
[04:19] <ebroder> bug #273283. bug #349987 was marked as its duplicate
[04:19] <ebroder> What?
[04:20] <ebroder> Weird. I'm pretty sure I don't have any special bits that would let me see 349987
[04:20] <cody-somerville> ebroder, fixed
[04:21] <ebroder> :-D
[04:21] <ebroder> Thanks
[04:21] <ebroder> Oh, do apport bugs with proc maps/tracebacks/etc attached get marked private automatically?
[04:22] <wgrant> Apport crashes do, yes.
[04:22] <wgrant> For non-Python things they have coredumps.
[04:22]  * ebroder nods. Makes sense
[04:22] <wgrant> And publicising coredumps or tracebacks with variables expanded is a bad idea.
[04:25] <ebroder> Hmm...re: bug #362691, it seems like a no-change rebuild will probably change the deps to use Python 2.6 instead of 2.5, but that also seems incredibly risky to do this late in final freeze. Is there any way to just change the dependencies of the package without actually doing a full rebuild?
[04:25] <ebroder> I guess the package could possibly be hacked to force it to use Python 2.5, but that seems kind of poor
[04:27] <ebroder> I guess this may actually be better fixed as an SRU
[04:30] <ScottK> ebroder: I'd rather fix it now and SRU if needed than release it known broken.
[04:31] <ebroder> Fix it as in do a full rebuild?
[04:31] <ScottK> Assuming that works, yes.  I didn't check if more was needed.
[04:31] <ebroder> I have no idea if more's needed - I'm really theorizing here. I just wanted to get a second opinion before I went source diving
[04:35] <ebroder> ScottK: It looks like the Makefile just uses `python setup.py` (with some environment vars and such), so I /think/ a rebuild might just fix it
[04:35] <ajmitch> it may need the --install-layout change as well
[04:35] <ScottK> Yep.
[04:35] <ebroder> Oh, good point
[04:35] <ScottK> ebroder: As ajmitch said, it may also need --install-layout=deb
[04:36] <ebroder> I just add that to the setup.py install invoke, right?
[04:36] <ScottK> I'd say give it a shot.
[04:36] <ScottK> Yes.
[04:36] <ajmitch> and if it has --prefix there, they are mutually exclusive now (iirc)
[04:36]  * ajmitch may be wrong about that now
[04:38] <ebroder> Wow...what a weird way of calling setup.py: `python setup.py install --home="$(DESTDIR)/usr" --prefix="" --force --install-lib="$(DESTDIR)$(LIBPATH)/python"`
[04:41] <calc> hey what happened to karma?
[04:41] <calc> i lost like 80K in the past couple days
[04:41] <ScottK> calc: See planet.  Translation credits got adjusted.
[04:41] <calc> ah ok
[04:42] <ScottK> Personally, I think everyone who had to put up with those mails deserved the karma.  I know one guy got 14,000 before we got the job manually killed.
[04:44] <Hobbsee> ++
[04:44] <Hobbsee> or at least, if the karma was actually useful for something - like, redeemable at the canonical store or something.
[04:46] <ajmitch> if it could be used like that, you can bet there'd be many more people doing less-than-helpful bug triage
[04:46] <ScottK> And we have enough of that already.
[04:47] <ScottK> Personally I try to keep my karma below a certain level and use it as a guage of "You've been spending too much time on Ubuntu lately".
[04:48]  * cody-somerville makes a note to have Launchpad OSA's regularly cut ScottK's karma in half.
[04:48] <ajmitch> now that karma's been adjusted, you can spend a whole lot more time on ubuntu for the same value
[04:49] <ScottK> Well last time I looked it was ~15K and now it's 60K, so I've messed something up.
[04:50] <cody-somerville> uploads now get you loads of karma
[04:51] <superm1> do main uploads get you more than universe uploads or anything crazy like that?
[04:52] <ScottK> Yeah.  I just looked and without the soyuz karma about about at ~10K, which has been my goal.
[04:52] <ScottK> There should be negative karma for uploada that FTBFS.
[04:52] <ScottK> uploada/uploads
[04:53] <ebroder> Ugh. I hate when the clean target doesn't work in a package "W: xen-3.3 source: patch-system-but-direct-changes-in-diff .hgignore and 110 more"
[04:53] <superm1> ScottK, at least that FTBFS from supported architectures maybe.
[04:54] <ScottK> Sure.
[04:54]  * ScottK heads off to bed.  Good night all.
[04:54] <ebroder> Night
[05:26] <ebroder> Hmm...how long until main stops taking uploads?
[05:27] <StevenK> It's very very slushy right now. Critical bug fixes only
[05:27] <wgrant> And probably then only for a couple more days.
[05:28] <ebroder> Oh! I was getting my Gutsy EOL date and my Jaunty release date confused
[05:28] <ebroder> I guess I'm not /quite/ so rushed to get a patch for bug 362691 together
[05:29] <wgrant> You should be...
[05:29] <ebroder> I'm rushing, I just don't have to get it ACKed and uploaded /tonight/
[05:29] <ebroder> And I don't think my change is likely to affect the one binary package in main; if anything it'll break one of the universe packages
[05:30] <persia> even universe is slushy
[05:30] <wgrant> Ah.
[05:30] <ebroder> *nods* I won't be heartbroken if this has to get fixed as an SRU instead of fixing it now, but I want to try anyway
[05:37] <slangasek> ebroder: how does that patch address the stated bug ("needs python 2.5 but is missing a dependency")?
[05:38] <ebroder> The makefile just uses "python", so rebuilding will use python2.6
[05:38] <slangasek> then the package will still be wrong
[05:39] <slangasek> if it currently depends on python 2.5 but misses a dependency, your patch would appear to make it depend on python 2.6 without an explicit dependency
[05:39] <ebroder> Good poitn
[05:39] <ebroder> *point
[05:40] <slangasek> the package probably needs some ${python:Depends} in the debian/control or something
[05:40] <TheMuso> slangasek: linux-ports re-uploaded, sorted out control changes so they aren't in the diff. Just waiting for linux-source-2.6.28 from mainline to be available so I can upload linux-rt.
[05:40] <ebroder> slangasek: I think you're right, although that still doesn't solve the fact taht we'll be upgrading it to 2.6 in the last week of the release cycle
[05:40] <slangasek> TheMuso: saw, thanks
[05:41]  * TheMuso looks forward to using git for linux-rt in karmic and beyond.
[05:41] <slangasek> ebroder: indeed - though there's little risk of regression if the package is already broken, I think this is probably better suited to an SRU anyway
[05:42] <ebroder> So..don't rush to get the fix in place now?
[05:43] <slangasek> ebroder: right
[05:48] <slangasek> TheMuso: linux/i386 is in ACCEPTED right now, so you should be able to grab for linux-rt in a couple of hours
[05:49] <TheMuso> slangasek: Got a better idea. I'll build arch indep packages locally, and use that as a base. By the time I upload and its accepted thigns will be fine at the DC end of things.
[05:49] <TheMuso> Doing it that way will mean I have to wait much less time.
[05:49] <TheMuso> just need linux-source-2.6.28 to be present for the buildds.
[05:50] <slangasek> ah, well, if you're in that much of a hurry you could also just download the .deb from launchpad
[05:51] <TheMuso> slangasek: I would if I hadn't gone over my quota for this month and thus connectino has been slowed somewhat. :S
[05:51] <TheMuso> connection
[05:51] <slangasek> heh
[05:54] <jdong> heh. How does e-mail subject / header unicode work / not work?
[05:54] <jdong> i.e. https://lists.ubuntu.com/archives/jaunty-changes/2009-April/009498.html
[05:54] <jdong> the transliteration seems to have exploded
[05:55] <ebroder> Haha
[05:57]  * slangasek blinks
[05:59] <superm1> okay everyone hide, when slangasek opens his eyes, he'll be really confused!
[06:00] <jdong> it was reproduced fine in the body of the e-mail
[06:00] <slangasek> everyone's gone!  I guess I can reject this mesa upload then, no one needs it
[06:01] <slangasek> jdong: yes, clearly a case of overly-enthusiastic mail software
[06:01] <superm1> haha
[06:01] <jdong> slangasek: interestingly. Definitely the upload sticks out in the jaunty-changes list :)
[06:09] <TheMuso> slangasek: uploading linux-rt. Strictly a rebase, so since the package only contains metadata, the only changes are changeloge entries, and an update to debian/control to explicitly depend on the latest linux-source-2.6.28 package. SRUs will not be rebased, but have the SRU patches added to the package proper.
[06:09] <slangasek> TheMuso: ok
[06:20] <StevenK> slangasek: livecd-rootfs will get pushed through today?
[06:21] <slangasek> yes
[06:52] <liw> slangasek, kiitos
[07:11] <dholbach> good morning
[07:23] <slangasek> liw: n/p
[08:10] <pitti> Good morning
[08:11] <pitti> kees: known bug, and fix waiting in unapproved queue
[08:25] <slangasek> StevenK: ping
[08:26] <slangasek> StevenK: the latest livecd-rootfs upload includes a full load of .bzr cruft; could you clean that up and re-upload?
[08:27] <StevenK> slangasek: Oh, damn it. Sorry about that.
[08:27] <dholbach> bzr bd for the win!
[08:28] <slangasek> except when it fails :)
[08:28] <StevenK> slangasek: Fixed and re-uploaded.
[08:28] <slangasek> StevenK: thanks
[08:28] <mvo> doko: what is your opinion on https://bugs.edge.launchpad.net/ubuntu/+source/python2.6/+bug/353251/comments/13 ?
[08:28] <dholbach> slangasek: fails?
[08:28] <pitti> StevenK: DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I.bzr -I.svn -I.shelf"
[08:28] <pitti> StevenK: FTW :)
[08:29] <slangasek> dholbach: sure, bzr bd has been broken at various points this cycle
[08:29] <slangasek> pitti: isn't "-i" alone supposed to be sufficient?
[08:29] <pitti> slangasek: -i only works on the diff.gz according to documentation
[08:29] <pitti> -I filters from built tar.gz
[08:29] <pitti> (native packages)
[08:29] <slangasek> -i -I, then? :)
[08:29] <pitti> but maybe they fixed that
[08:30] <liw> very few things are great when they fail
[08:30] <liw> but awesome is awesome even in failure, I'm sure
[08:30] <StevenK> pitti: Yeah, I used -i, not -I :-(
[08:30] <pitti> slangasek: nice, indeed
[08:30] <pitti> wasn't there yet years ago when I added that
[08:30]  * pitti simplifies his ~/.devscripts
[08:33] <dholbach> what's wrong about "bzr bd --native -- -S"? :)
[08:34] <slangasek> nothing when it's working
[08:34] <dholbach> ok
[08:34] <dholbach> you guys make it sound like it's always broken :)
[08:34] <dholbach> I use it all the time and I'm happy
[08:35] <Amaranth> whee, 15 second boot and 2-5 second warm cache login time
[08:35]  * Amaranth just did a fresh install
[08:54] <pitti> Keybuk: hm, bootchart-java pulls in libcommons-compress-java and libcommons-cli-java; before the package split they weren't in main; why did it grow those deps?
[09:00] <pitti> Riddell: do you want kgrubeditor back in main (see concerns in bug 262309) or unseed it?
[09:02] <slangasek> pitti: kgrubeditor seems to have so far failed its MIR?
[09:19] <pitti> slangasek: it's been in main before, but only preliminarily promoted
[09:20] <slangasek> ah
[09:20] <Keybuk> pitti: they were probably just missing Depends before?
[09:20] <Keybuk> some weird java build system change madness maybe?
[09:20] <Keybuk> I just looked at the intrepid deb, and they're inside the .jar there
[09:20] <pitti> Keybuk: ah, so bundled vs. split out
[09:21] <Keybuk> where the whole change to java-* seems to have made them depends instead
[09:38] <madduck> is it deliberate that i cannot install openssh-server with 'add/remove software' (but it works with synaptic) on 9.04rc?
[09:38] <BUGabundo> madduck: was it ever there?
[09:38] <madduck> no idea
[09:38] <madduck> but it's *openssh-server*
[09:39] <madduck> i would think that that's part of the core system, no?
[09:40] <mvo> madduck: hello! add/remove is designed to show stuff for end-users (basicly what comes with a desktop file). we bend the rules a bit for some stuff like codecs. its a really good question if openssh-server should be in or not
[09:41] <madduck> fair enough
[09:41] <madduck> i was assuming something like that
[09:41] <madduck> and it's a worthwhile consideration
[09:41] <madduck> it just startled me a bit...
[09:41] <madduck> btw, i liked the 9.04rc install, folks.
[09:41] <madduck> and so far, it's all working
[09:42]  * madduck replaced the old etch kde install of his ex-girlfriend with 9.04rc
[09:43] <StevenK> slangasek: Oh, are dailies enabled again, or are they manual only from here on out?
[09:44] <slangasek> StevenK: I may end up enabling dailies to save myself the effort of rolling things by hand over the weekend, but perhaps not until the installer is where we want it
[09:44] <liw> madduck, hi
[09:45] <madduck> hello. funny, this channel is like #d-d five years ago. :)
[09:46] <slangasek> /invite Overfiend
[09:46] <mvo> haha - I was just thinking that
[09:46] <StevenK> Bwaha
[09:47]  * mvo remembers some words starting with f* that he learned in this channel at this time
[09:47] <pitti> lool: hm, /usr/lib/sendmail? Shouldn't that be /usr/bin/sendmail?
[09:47] <slangasek> heh
[09:47] <StevenK> mvo: Like the fire brigade?
[09:47] <mvo> it was suprising how rich the english language can be
[09:47] <mvo> StevenK: exactly :P
[09:47] <BUGabundo> mvo: so where is the list of apps to show in GAI at?
[09:48] <mvo> BUGabundo: ls /usr/share/app-install/desktop/*.desktop
[09:49] <madduck> thanks folks, i'll be back if there are problems with 9.04rc
[10:14] <cjwatson> lifeless: absolutely noise. That was the very first thing I objected to in my blog post about bug triage (http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2009-02-27-bug-triage-rants.html) and I've been complaining about it for years, on and off
[10:18] <cjwatson> jdong: can you file a bug on Soyuz about that bogus From line if you haven't already? (It used to mangle the body of the mail as well; at least that's been fixed ...)
[10:19] <liw> cjwatson, lifeless: perhaps it'd be helpful to have a tag for the handful of bug reports that have an automated test case, at least
[10:19] <cjwatson> TBH I think that's a red herring; bug triagers should have the skill to read and understand a bug before commenting on it
[10:20] <liw> fair enough
[10:20] <liw> (I updated the description)
[10:21] <liw> (otoh, automated test cases for bugs are a good thing anyway, more bug submitters should provide them :)
[10:22] <bryce_> cjwatson: optimist.
[10:26] <cjwatson> bryce_: beats editing every bug to say in different ways "hey guys, this is a real bug, please leave it alone" (which IME a certain set of bug triagers ignore anyway, so you end up in an arms race)
[10:27] <liw> dammit, can we stop improving boot time: I didn't even notice my desktop booted
[10:27] <slangasek> radix: hmm, was this landscape-client upload meant to go to jaunty release, or was it supposed to go to a PPA?
[10:27] <liw> (I was trying to halt it, and wondered why the heck it was taking so long -- it had rebooted instead)
[10:28]  * slangasek laughs
[10:30] <slangasek> zul: looks like you sponsored this landscape-client upload to jaunty-release?  can you clarify what the intent is here?
[10:33] <BUGabundo> liw: lucky ! mine still take 35 secs to gdm, and a lot more into it until I can use it
[10:33] <BUGabundo> liw: http://fileland.bugabundo.net/fotos/Linux/bootchart
[10:36] <Riddell> pitti: yes I'd like kgrubeditor in main
[10:38] <ogra> slangasek, i know i'm a bit hasty, but i'd like to report that the NSLU2 RC install finished successfully
[10:38] <slangasek> hasty? :)
[10:38] <ogra> :)
[10:39] <slangasek> which image is NSLU2, again?
[10:39] <ogra> ixp4xx
[10:39] <pitti> Riddell: that means people can wedge their grub configuration with it and get ucf questions, you are aware of that?
[10:39] <ogra> netinstall
[10:39] <Riddell> pitti: ucf?
[10:40] <pitti> Riddell: /boot/grub/menu.lst is managed with ucf nowadays (or somethign that looks very much like it), AFAIK
[10:40] <slangasek> ogra: thanks, published to the netboot rc page
[10:40] <slangasek> pitti: it is ucf, yes
[10:40] <ogra> thanks
[10:40] <Riddell> pitti: they can also fix their grub configuration when something goes wrong or needs changed
[10:43] <cjwatson> Riddell: does it round-trip cleanly - that is, if you load a grub configuration in it and then save it without making any changes, does it produce an identical file? likewise if you make just one change, it should make only that change and not also make trivial changes elsewhere
[10:47] <Riddell> cjwatson: no, doesn't seem to
[10:48] <cjwatson> that's going to result in a good few bugs filed on grub then :(
[10:49] <pitti> that was the primary concern why the MIR hasn't been approved yet
[10:49] <ogra> the first is easily solved by greying out the save button until a change has been made though
[10:51] <liw> yay, upstream fixed the problem with the kernel not recognizing my disks (LP: #257790)
[10:52] <Riddell> ok, I'll remove it from the seeds
[10:53] <liw> how difficult is it to create one's own version of the ISOs, with a custom kernel?
[10:53] <BUGabundo> liw: not hard! just takes a bit
[10:53] <hyperair> more difficult than just installing the kernel manually
[10:53] <BUGabundo> there's a wiki with the steps
[10:53] <BUGabundo> hyperair: that's true
[10:53] <hyperair> =p
[10:53] <BUGabundo> we need a tool to make costum images!
[10:54] <BUGabundo> like suse studio
[10:54] <hyperair> for one, the kernels will get superseded
[10:54] <liw> hyperair, installing the kernel manually ... to a system that hasn't been installed?
[10:54] <hyperair> liw: install, then install the kernel on top of it
[10:54] <hyperair> liw: if your kernel won't boot, then chroot comes to mind
[10:54] <liw> hyperair, no can install when installer does not see disks
[10:54] <hyperair> oh wait O_o
[10:54] <hyperair> ah
[10:54] <hyperair> that sounds painful X_X
[10:55] <hyperair> guess the ISO's the only way for you
[10:55] <BUGabundo> netboot maybe?
[10:55] <hyperair> actually...
[10:55] <hyperair> no
[10:55] <hyperair> if you use a USB startup disk..
[10:55] <hyperair> it would be pretty easy
[10:55] <hyperair> just crack open the squashfs..
[10:55] <hyperair> then install the kernel
[10:55] <hyperair> and remove the old kernel
[10:55] <hyperair> i think
[10:56] <cjwatson> parts of the kernel are also, rather necessarily, outside the squashfs
[10:56] <BUGabundo> hyperair: that's the manual way
[10:56] <BUGabundo> and still requires a bit of work
[10:56] <hyperair> ah crap
[10:56] <hyperair> lol
[10:57] <BUGabundo> let me find the wiki page
[10:57] <hyperair> the ISO structure is something i still know next to nothing about
[10:59] <BUGabundo> and now I can't find the wiki
[10:59] <hyperair> hehe
[10:59] <hyperair> it always eludes you when you need it doesn't it? =p
[11:00] <BUGabundo> LiveCDCustomization
[11:00] <BUGabundo> luckly I save all wikis to disk....
[11:00] <BUGabundo> makes it easy to have on hand when google fails
[11:00] <BUGabundo> https://help.ubuntu.com/community/LiveCD?highlight=((LiveCDCustomization))
[11:01] <BUGabundo> there you go https://help.ubuntu.com/community/LiveCDCustomization
[11:01] <liw> BUGabundo, thanks, I'll give that a try
[11:01] <BUGabundo> all the trouble to extract squashfs and redo the FS is too much
[11:02] <BUGabundo> aint anyone working on a tool to do that for us?
[11:02] <lool> pitti: You mean /sbin
[11:02] <lool> pitti: /lastlog sendmail on #ubuntu-release :)
[11:03] <pitti> lool: ah, saw it; thanks
[11:06] <hyperair> BUGabundo: is there a guide for customizing what gets installed?
[11:13] <liw> note to self: copying initrd to vmzlinuz is not conducive to getting a working installer
[11:14] <BUGabundo> hyperair: humm start with minimal and base metapackages?
[11:15] <hyperair> BUGabundo: ?
[11:16] <hyperair> BUGabundo: how does a desktop cd get generated generally?
[11:16] <hyperair> BUGabundo: i mean without cracking it open blah blah
[11:16] <Hobbsee> hyperair: seeds, and germinate
[11:16] <BUGabundo> don't know! ask the images admins
[11:16] <hyperair> hehehe
[11:16] <BUGabundo> there you go
[11:17] <Hobbsee> hrm, which doesn't seem to be in this guide
[11:17] <hyperair> yeah
[11:17] <hyperair> they don't
[11:17] <BUGabundo> there's a wiki on how to do your own germinate
[11:17] <hyperair> hmm there is?
[11:18] <BUGabundo> I read part of it once
[11:18] <hyperair> considering that germinate does ring a bell, i think i might have as well
[11:19] <hyperair> on an unrelated note, i'm curious as to how many people agree with the new update-notifier behaviour
[11:19] <cjwatson> hyperair: livecd-rootfs does the work of generating the live filesystem
[11:20] <BUGabundo> hyperair: -1
[11:20] <hyperair> cjwatson: ah cool, i'll look into that too =p
[11:20] <hyperair> BUGabundo: hahah. personally, i view the new behaviour as a security hole.
[11:21] <BUGabundo> we will ppl just closing and not updating
[11:21] <hyperair> not just that
[11:21] <hyperair> i'm talking about using the new behaviour to trick people into giving the password to gksudo
[11:22] <BUGabundo> I'm tired of this. I was among those that discussed this in +1, and opened the bug
[11:22] <hyperair> heh yeah
[11:22] <BUGabundo> Mark as closed it *twice* with won't fix
[11:22] <BUGabundo> so either we discuss for kk, or forget it
[11:22] <hyperair> they seem pretty stubborn regarding this
[11:22] <hyperair> so.
[11:22] <Hobbsee> Please take this discussion elsewhere, guys.
[11:22] <BUGabundo> I won't even comment anymore on the bug
[11:22] <hyperair> right
[11:23] <pitti> Riddell: ok, please tell me when you uploaded k-meta, I'll wave it through the queue
[11:23] <Hobbsee> like you say, the bug has been marked twice as won'tfix, and there's no point disturbing this channel withit
[11:24] <pitti> directhex: at the expense of bringing mono out of sync again, would you agree to droping the Recommends: libgluezilla from libmono-webbrowser0.5-cil? or should it get a MIR?
[11:25] <directhex> hm, what do we need libmono-webbrowser0.5-cil for?
[11:26] <pitti> directhex: mono-tools build-dep and reverse dep of libmono-winforms2.0-cil
[11:26] <pitti> OTOH gluezilla looks harmless enough
[11:27] <pitti> and the recommends: seems to be justified, WDYT?
[11:27] <directhex> it's harmless enough, yes
[11:27] <directhex> oh. oh ARSES
[11:28]  * directhex files a big nasty bug against ubuntu-dev-tools
[11:28] <pitti> directhex: so, MIR then?
[11:28] <ogra> can someone let usb-imagewriter out of binary NEW ?
[11:28] <liw> hm, I did something wrong. my ISO doesn't boot (at least not under kvm)
[11:28] <liw> or, the live system doesn't boot
[11:28] <directhex> pitti, yeah. golly gee, i love MIR paperwork \o/
[11:30] <taavikko>  any change for "ubuntu-bug -p pkg" tool to have it uploading it's contents to an existing bug?
[11:31] <pitti> directhex: we just need to sort out http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt RSN
[11:31] <taavikko> as of now, it seems to be missing that functionality?
[11:31] <pitti> taavikko: to do that, use apport-collect
[11:31] <taavikko> pitti: thanks :)
[11:31] <directhex> pitti, Bug #362845 is my excuse for why this wasn't spotted sooner
[11:32] <pitti> directhex: hah
[11:32] <pitti> ogra: done
[11:32] <ogra> Pici, thanks :)
[11:32] <ogra> err pitti
[11:35] <pitti> Keybuk: uh, bootchart-java uses gcj, not default-jdk
[11:36] <Keybuk> does it?
[11:36] <Keybuk> see, shows how much I know ;P
[11:36] <Keybuk> Java confuses me
[11:36] <pitti> +export JAVA_HOME=/usr/lib/jvm/java-gcj
[11:36] <pitti> the build deps are correct, though
[11:36] <pitti> Keybuk: not just you :)
[11:37] <Keybuk> it doesn't help that our Java policy doesn't actually appear to be written down anywhere
[11:37] <Keybuk> like the wiki
[11:37] <ogra> hmm, works for me without exporting JAVA_HOME
[11:37] <ogra> even on armel
[11:37] <directhex> ...........................
[11:37] <directhex> i need to start using Tomboy.
[11:37] <pitti> Keybuk: I collect stuff in bug 362849
[11:37] <directhex> https://wiki.ubuntu.com/MainInclusionReportgluezilla
[11:38] <directhex> check the date/time it was written
[11:38] <ogra> oh, i thought the decision was to demote bootchart to universe instead
[11:38] <Laney> directhex: that bug looks fixed already
[11:38] <Laney> are you using the latest u-d-t?
[11:38] <pitti> directhex: oh, nice! ah, it's not linked to a MIR bug, thus it escaped our attention
[11:38] <pitti> directhex: thanks, I'll deal with it
[11:38] <directhex> Laney, i think so. this machine is on jaunty
[11:39] <Keybuk> pitti: I thought we decided to just demote bootchart to universe anyway?
[11:39] <ogra> yeah
[11:39] <Laney> directhex: well it is fixced for me
[11:39] <pitti> Keybuk: WFM; I don't know where it should  live
[11:39] <ogra> Keybuk, i bet someone forgot to close the bug :)
[11:40] <Keybuk> slangasek: ?
[11:40] <pitti> Keybuk: (having it in universe makes sense to me, though)
[11:40] <pitti> Keybuk: slangasek is sleeping
[11:40] <directhex> pitti, perhaps i never got around to filing the bug, and it sorta slipped my mind
[11:40] <pitti> no reverse dependencies, so I guess it's just seeded in supported
[11:40] <Keybuk> he'll be up later ;)
[11:40] <ogra> so your ping was really informative :P
[11:40] <directhex> pitti, of course, i would only have written an MIR on request, so you can feel better about having spotted the issue back in November ;)
[11:40] <cjwatson> installer and supported-development
[11:41] <pitti> cjwatson: bootchart is in the installer seed?
[11:41] <cjwatson> it is, but it's no longer used
[11:41] <cjwatson> feel free to rip it out
[11:41] <pitti> okay
[11:41] <ogra> we had a udeb for it
[11:41] <ogra> ages ago
[11:42] <Riddell> pitti: kgrubeditor isn't in kubuntu-meta
[11:43] <pitti>  o kgrubeditor: kgrubeditor
[11:43] <pitti>    [Reverse-Depends: Kubuntu.Jaunty desktop seed]
[11:43] <pitti> hmm
[11:43] <pitti> Riddell: oh, of course
[11:43] <pitti> Riddell: -meta ignores apckages in universe, so it's just the seed change
[11:43] <pitti> so much the better
[11:44] <pitti> cjwatson: ok, committed; thanks
[11:44] <pitti> Riddell: ok, thanks
[11:45] <pitti> Riddell: what's the rationale for the kde-l10n-* uploads? there's no bug # associated with them
[11:47] <lifeless> cjwatson: yes me too; was seeking confirmation we really are on the same page; we are :)
[11:47] <lifeless> liw: the problem isn't metadata, its makework/quantity not quality
[11:55] <zul> slangasek: it was suppose to be going to a ppa
[11:58] <Riddell> pitti: the futile hope of having complete translations.  bug 362229
[11:59] <pitti> Riddell: ah, thanks
[12:26] <kwwii> pitti, slangasek: I've made the png a jpg and now it is almost 1MB, the package also includes a fix for another bug
[12:26] <directhex> kwwii, is 1mb better or worse?
[12:27] <pitti> kwwii: how come that it grew so much? it's currently an PNG as well
[12:27] <pitti> directhex: current size is 1.6 MB
[12:27] <directhex> pitti, how bad's the crunch for space this release?
[12:28] <pitti> directhex: CDs are nicely at the limit, so any package size increases are a no-go at this point
[12:28] <kwwii> pitti: I have no idea, the problem was the transparent pixels and the fix came with a file which is much larger
[12:29] <kwwii> pitti: I tried to reduce it but couldn't get much more than a couple hundred KBs
[12:29] <kwwii> directhex: -1MB is always good just before release :)
[12:29] <pitti> (-0.6 MB, but that's still good, of course)
[12:29] <kwwii> pitti: hehe, right :)
[12:30] <kwwii> how many command line tools is that?
[12:30] <liw> the desktop ISO can't set up a RAID to install to, can it? but the alternate can?
[12:31] <hyperair> that's right.
[12:31] <pitti> liw: yes, d-i partitioner allows you to set up lvm, raid, crypto, etc.
[12:31] <directhex> liw, mdadm softraid? yes
[12:31] <liw> then I need to switch my attempts at creating a custom ISO to that, thanks
[12:31] <directhex> pitti, and these rumblings over openjdk in a future release. how is freeing up the ~100 meg required even possible?
[12:33] <pitti> directhex: sure, we could throw out OO.o
[12:33] <pitti> (just kidding)
[12:33] <ion_> Replace it with LyX and Gnumeric! :-P
[12:34] <directhex> pitti, great! now who was it who wanted OpenJDK? oh, right, calc...
[12:34] <pitti> directhex: frankly, I have no idea, and my personal opinion is that we shouldn't sacrifice 1/6 of the CD for a single programming language
[12:34] <pitti> but I think that remains to be discussed
[12:34] <pitti> once we have the space, we can argue about how to use it
[12:35] <directhex> pitti, i could save you >4 meg today with some teeny bits of package substitution!
[12:35] <pitti> directhex: sounds great for karmic!
[12:35] <pitti> we can also free some more space by ripping out GNOME help translations and moving them to language packs
[12:35] <pitti> that shoudl be in the order of 50 MBs
[12:35] <pitti> but we need some soyuz support for that (bug filed)
[12:36] <directhex> oh, yes please. tomboy is 95% translated images
[12:36] <directhex> in docs
[12:37] <directhex> jms@osc-bigmac:~$ du -hs /usr/lib/tomboy/
[12:37] <directhex> 520K	/usr/lib/tomboy/
[12:37] <directhex> jms@osc-bigmac:~$ du -hs /usr/share/gnome/help/tomboy/
[12:37] <directhex> 4.4M	/usr/share/gnome/help/tomboy/
[12:43] <liw> hm, this is weird: in gnome-terminal, if I open a new tab, it tries to use the same working directory as the previous tab; if I am running man, the new tabs open in /usr/share/man
[12:44] <directhex> liw, oh, that's right! well spotted
[12:47] <liw> #362880
[13:14] <cjwatson> mvo: how are upgrade tests looking, from your POV?
[13:18] <mvo> cjwatson: pretty good now, there were bug #357884 and bug #361194 that were pretty anoying but those are fixed now
[13:18] <mvo> cjwatson: but I will do a re-run with the current archive today (now that some new stuff entered)
[13:58] <vlada_> hi guys
[13:58] <vlada_> I want to install kde3 libs in order to build older version of rosegarden
[13:59] <vlada_> is there any howto?
[14:01] <ScottK> vlada_: sudo apt-get install kdelibs4-dev
[14:02] <vlada_> ScottK: 4?
[14:02] <vlada_> i NEED 3
[14:02] <vlada_> stivky caps lock, sorry
[14:03] <Riddell> vlada_: that is KDE 3
[14:03] <vlada_> just a strange naming scheme, I guess. Thanks
[14:04] <vlada_> Riddell: any idea why's that?
[14:04] <vlada_> except to confuse users...
[14:04] <wgrant> It's probably the ABI version.
[14:05] <Riddell> as wgrant says
[14:07] <vlada_> I still find it confusing. But hay, nobody's perfect :)
[14:07] <]NeRoNexX[> hi
[14:08] <]NeRoNexX[> :)
[14:08] <liw> I finally have a working custom alternate ISO, which passed the integrity check; trying to install under kvm results in a complaint that PPPoE doesn't work
[14:08] <cjwatson> liw: can I see the syslog please?
[14:09] <cjwatson> you're not the first person to report this with customised images, and I'd like to track it down
[14:09] <liw> cjwatson, un moment
[14:11] <liw> (need to convert image to raw, mount it with the help of kpartx before I can extract)
[14:13] <liw> in the meanwhile, the vanilla alternate ISO (from which my custom one is made) does work
[14:13] <cjwatson> uhh - I would expect you to need to extract syslog from the running installer
[14:13] <cjwatson> i.e. scp it out or similar
[14:13] <liw> cjwatson, without network?
[14:13] <elmo> cjwatson: I suspect liw means the KVM image?
[14:13] <liw> oh, but it doesn't write the syslog to disk of course
[14:14] <liw> yeah, kvm image
[14:14] <cjwatson> liw: you should be able to configure it manually
[14:14] <persia> liw, Pass kvm another disk image (not using kpartx), and copy it into there.
[14:14] <cjwatson> you have dhclient
[14:14] <cjwatson> elmo: sure, but as liw says the syslog is only in RAM
[14:14]  * liw goes back to reproduce
[14:15] <cjwatson> liw: if you could add DEBCONF_DEBUG=developer to the boot arguments while you're at it, that would be helpful
[14:15] <pitti> kirkland: FYI, you can now use report.pid in apport hooks instead of grepping it out of ProcStatus
[14:16] <liw> hm, scp is not installed
[14:16] <liw> cjwatson, I can do that, too, for the next run
[14:16] <cjwatson> scp: 'anna-install openssh-client-udeb'
[14:16] <kirkland> pitti: i ended up dropping that all together
[14:16] <kirkland> pitti: and just using:     report['KvmCmdLine'] = command_output(['ps', '-C', 'kvm', '-F'])
[14:17] <kirkland> which might grab more than one kvm command line
[14:18] <pitti> kirkland: I know, just FYI
[14:18]  * liw curses Linus for giving in and not keeping Finnish as the default kernel keymap
[14:19] <kirkland> pitti: what's the usage syntax?  report['Pid'] ?
[14:19] <pitti> kirkland: report.pid
[14:19] <pitti> (integer)
[14:19] <kirkland> pitti: oh, strange
[14:19] <kirkland> pitti: why is it not a key/value pair?
[14:19] <pitti> it's not a field we want to put into bug reports
[14:19] <kirkland> pitti: okay
[14:19] <pitti> at that point it would just clutter
[14:20] <kirkland> gotcha
[14:20] <liw> cjwatson, do you care about the one without DEBCONF_DEBUG=developer?
[14:20] <kirkland> pitti: how do i get rid of stock fields that I consider clutter for my package?
[14:20] <seb128> evand1: is usb-creator displaying a "Unable to determine the partition number." error a known issue?
[14:20] <pitti> kirkland: you can del report['Field']
[14:20] <pitti> kirkland: but please test it
[14:21] <cjwatson> liw: yes
[14:21] <pitti> kirkland: and just for safety, wrap it in a try: except KeyError: pass
[14:21] <cjwatson> liw: I may turn out not to need the debconf debugging; we'll see
[14:22] <liw> cjwatson, sent; fwiw, running dhclient brings up networking without a problem
[14:22] <kirkland> pitti: thanks
[14:23] <seb128> evand1: I've filed bug #362917 let me know if you need details
[14:23] <liw> cjwatson, shall I save the ISO I have, to make further debugging for you? or would you like a copy of it?
[14:24] <cjwatson> liw: can you save it just for the moment? I'll look at your log today
[14:24] <cjwatson> (once I get it ...)
[14:24] <liw> cjwatson, I can save it for a long while, if you need me to :)
[14:25] <liw> mv sembfix.iso custom-jaunty-rc-iso-that-cannot-get-networking-up-automatically-saved-for-cjwatson.iso # there
[14:27] <liw> now, the next logical step for me would be to try my custom ISO on real hardware, hopefully without breaking anything... (me, touch hardware and not break anything? bwahaha)
[14:28] <cjwatson> superm1: bug 352572: which, specifically, are the patent-encumbered files in the mythtv source package, and why is there no mention of the encumbrance in debian/copyright?
[14:30] <cjwatson> liw: actually, could you dump it on rookery or something? that would be no slower for you and would save me download times, since I just need to look at a couple of files in it
[14:30] <superm1> cjwatson, the bits that are included from ffmpeg.  i suspect that the original author of the package, on debian-multimedia didn't mention them in detail
[14:30] <liw> cjwatson, sure
[14:32] <cjwatson> superm1: ah. please document this for a future upload?
[14:32] <superm1> cjwatson, sure will do
[14:34] <liw> hm, usb-creator no longer offers to format a stick
[14:35] <pitti> MacSlow: did you see my question in bug 331369?
[14:35] <MacSlow> pitti, rechecking
[14:36] <MacSlow> pitti, oh ja klar ... sorry :)
[14:37] <MacSlow> pitti, but you should just grab rev 293 (or tag 0.9.12)
[14:37] <MacSlow> pitti, that has only that one-line patch from david
[14:37] <pitti> MacSlow: 0.9.12 has other unrelated changes
[14:38] <MacSlow> pitti, well commit 293 is what you're after then
[14:38] <pitti> MacSlow: ok, thanks; can you please say so in the bug report, so that I won't forget?
[14:39] <MacSlow> pitti, done
[14:40] <pitti> mvo: could you upload the update-manager fix for bug 351394 ?
[14:44] <liw> bah, it seems I failed to put in my custom kernel onto the custom cd
[14:44] <mvo> pitti: the fix is to comment out the nvidia driver to let xorg work its magic to detetct what driver to use. in this case it would not help (because -nv is buggy). I'm a bit heasitant to upload it to jaunty
[14:45] <pitti> mvo: oh, ok; I thought it was related to restricted temporarily not being available
[14:45] <mvo> pitti: i.e. it will not fix this particular problem but may introduce regressions (also the risk is relatively low)
[14:46] <mvo> pitti: sorry, the comment in the bug is a bit short, I will make it better
[14:46] <pitti> mvo: so -180 doesn't support that model any more? shouldn't it transition to -173 then?
[14:46] <pitti> tseliot: ^
[14:46] <pitti> this bug is pretty confusing
[14:46] <pitti> -nv shouldn't have a role here at all
[14:46] <superm1> cjwatson, in looking for a good set of text to describe the ffmpeg bits, i was hoping debian/copyright in ffmpeg-debian would have it, but it's missing the same type of information
[14:46] <mvo> pitti: the user has -177 installed but restricted is disabled for some reason
[14:46] <pitti> an nvidia -> nv switch is a regression
[14:47] <pitti> mvo: ah, he disabled restricted himself?
[14:47] <mvo> pitti: probably, mmight be a mistake on his part of course
[14:47] <pitti> ok, that's relieving, though
[14:47] <mvo> pitti: its not clear to me what u-m should do, probably warn
[14:47] <tseliot> pitti: yep, nvidia->nv doesn't work in his case
[14:48] <mvo> and the additional bug is that nv claims to support the card but it does not
[14:48] <tseliot> right
[14:50] <pitti> ok, I updated the bug
[14:55] <liw> oh, silly me: I only put the new kernel .deb on the cd, I didn't modify the installer to actually use it
[14:57]  * liw decides to give in to the angry wolf in his stomach and go out for groceries
[14:58] <ogra> oh, that was the noise all day ?
[15:00] <liw> cjwatson, the ISO is now in my home directory on rookery
[15:01] <liw> cjwatson, I'll delete it after you tell me you're done with it, to save disk space
[15:04] <jcastro> Keybuk: fyi: http://www.harald-hoyer.de/linux/boot-time-distro-comparison
[15:10] <Keybuk> jcastro: I just posted that to you on #distro
[15:11] <jcastro> always a day late and a dollar short
[15:12]  * ogra sends jcastro a dollar
[15:16] <Keybuk> jcastro: harald is on the cabal channel, so I knew waayyyy ahead of you <g>
[15:16] <Keybuk> I even told him to use the german mirror to get the iso since the usual one was slow for him :p
[15:22] <jcastro> Keybuk: I am just the catch-all for things just in case.
[15:24] <jcastro> Keybuk: I am down to 7 seconds on my X200 with the intel SSD
[15:24] <jcastro> 7.00
[15:24] <Keybuk> see, I don't get these fancy Intel SSDs :'(
[15:25] <robbiew> heh
[15:44] <pitti> mdz: for your freezes, https://edge.launchpad.net/~bryceharrington/+archive/purple is worth testing (mesa with 965 fix)
[15:45] <mdz> pitti: bryce already said on the bug that it didn't fix things for him, so I wasn't going to bother
[15:45] <Mirv> ^ helped me on a GMA X3100
[15:45] <pitti> ah, ok
[15:45] <Mirv> and helped tjaalton as well
[15:46] <pitti> mdz: greedy, or Option "EXAOptimizeMigration" "off" don't help either?
[15:46] <siretart`> wow
[15:47] <Mirv> I'd suggest mdz to try it since it helped us already. it'd be worthwhile to know if it fixes problems for many/most i965 users.
[15:47] <siretart`> linux 2.6.30-rc2 + libdrm 2.4.9 + intel 2.7.0 == win
[15:47] <cjwatson> mvo: I'm trying to puzzle out whether the python2.4 part of bug 353251 is release-critical. Can it be fixed in an SRU, since the default python won't be 2.4 and will therefore work?
[15:47] <siretart`> 3d performance wise
[15:47] <mdz> pitti: I haven't tried it.  I had to turn off desktop effects in order to be able to work, and that was enough of a workaround
[15:47] <pitti> siretart`: that's what I heard, too; not quite jauntyable though, I'm afraid
[15:48] <pitti> mdz: ah, ok; that's one of the workarounds documented in the release notes
[15:48] <pitti> to get people through the first few weeks until we have an SRU
[15:50] <siretart`> pitti: yeah, indeed.
[15:50] <Mirv> pitti: greedy/exaoptimizemigration seems to cause severe graphical problems on i965, so it's probably better for i945 series experiencing problems.
[15:51] <mvo> cjwatson: I honestly don't know. I asked doko for input earlier if that is a design decision or a bug. and if its a bug if the bug is to byte compile for unsupported runtimes when a new python-foo package gets installed or if the bug is that no rtinstall script is run for unsupported runtimes
[15:52] <mvo> cjwatson: its definitely confusing (and gave me some trouble when I tried to get python-distutils-extra to work with p2.4)
[15:53] <mvo> cjwatson: but whatever the decision is, I think we can SRU it, we just need to force a rtinstall for lower version than the sru version (we did something similar for python2.6)
[15:55] <cjwatson> doko: ^- can you comment?
[15:57] <cody-somerville> Whats the accepted practise for versioning of uploads of snapshots from a git repository?
[15:58] <directhex> cody-somerville, don't use the git hash in the version number. i saw someone do that once
[15:58] <cody-somerville> lol
[15:58] <doko> cjwatson: I'll have a look, but not today. weekend should be ok
[15:58] <cjwatson> if it's SRUable, yes
[15:58] <cjwatson> cody-somerville: I believe 1.0+git20090417-0ubuntu1 is fairly usual
[15:59] <cjwatson> where 1.0 is the previous release. If you're thinking of it as "pre-release of 1.1" instead, then 1.1~git20090417-0ubuntu1
[16:00] <pitti> mvo: could we tell compiz to not start by default on 965 for now, but still allow people to enable it in the GUI tool?
[16:00] <cody-somerville> cjwatson, How do you know for sure how upstream will version the next release though?
[16:01] <pitti> mvo: until we found a real solution for bug 359392?
[16:01] <cjwatson> cody-somerville: you may have contact with upstream that allows you to guess very accurately, or you may not
[16:01] <pitti> bryce: also, would the right solution for ^ still be to revert some intel related patches from mesa 7.4?
[16:01] <cjwatson> cody-somerville: I am not pretending to know what is appropriate in your situation
[16:01] <cjwatson> cody-somerville: (for example, it's entirely plausible for some packages in Ubuntu that you *are* upstream :-P)

[16:04] <mvo> pitti: ok
[16:04] <pitti> mdz:
[16:05] <mdz> mvo: "ok" meaning it's possible to disable it by default but still allow people to enable it in preferences?
[16:05] <pitti> mdz: so with tjaalton and Mirv's positive experiences with the mesa PPA package, maybe it's worth a try after all?
[16:05] <mdz> pitti: what would we do if we find a fix for the bug?  re-enable it?
[16:05] <pitti> mdz: yes, of course
[16:06] <pitti> I currently wonder where we could disable it by default
[16:06] <pitti> one option would be to disable dri by default in -intel on 965
[16:06] <pitti> then you could enable it in xorg.conf
[16:06] <mvo> mdz: I need to look at the code and think about a not too intrusive way how this can be done, definitely a bit tricky because we currently have no such mechanism (other than the blacklist/whitelist)
[16:06] <pitti> the other to blacklist it in compiz, but then you coudln't enable it at all
[16:06] <mdz> mvo: I don't like the idea of adding more bugs for the sake of a workaround
[16:06] <mdz> mvo: how about using the blacklist instead?
[16:07] <pitti> and we have a pretty clear and proven way how to disable DRI for a chipset in -intel
[16:07] <rickspencer3> is there a way to add post-install step that changes the setting?
[16:07] <mvo> mdz: that definitely very easy. and still possilbe to override (but not with the gui)
[16:08] <ericdc> I am attempting to remaster a CD (Ubuntu 8.04 LTS Server) to automate its installation. Then the installer complains about not finding the CD-ROM (USB CD-ROM Drive). I guess some USB module is not installed. So I press "continue". It proposes to load a driver from floppy, eventually it brings me back to the installation menu when it fails. I choose detect cdrom and it works fine but goodbye automation!
[16:09] <mdz> pitti,mvo,rickspencer3: are any of you personally affected by this bug?
[16:10] <rickspencer3> mdz: I am not
[16:10] <tjaalton> pitti, mdz: by dropping the patch we are closer to upstream. it's now known to need more work to allow 4k*4k textures to work, so dropping it is safe and sane
[16:10] <Lure> pitti: can you look at bug 358576 and comment how likely it is to get exiv2 0.18.1 in that late?
[16:10] <Lure> pitti: or should somebody rather spend time on hunting individual fixes (may take time)
[16:10]  * Lure is sorry if you got it multiple times - my IRC is bad currently
[16:11] <pitti> mdz: no, I have a 945 and experience a different set of bugs (freezes and slowness)
[16:11] <mdz> pitti: does disabling desktop effects fix your problems as well?
[16:11] <pitti> mdz: yes, that fixes the hang after resuming
[16:12] <Mirv> mdz: if you added the PPA, do you also find that the version number actually isn't shown for updating, since the real ubuntu2 version already come out as well? me and tjaalton build our mesa on our own, just removing the 103 patch similar to what's been done in the PPA packages.
[16:12] <pitti> mdz: (bug 339091)
[16:12] <mdz> Mirv: I have not tried the package in the PPA, I'm not in front of my i965 system right now
[16:12] <tjaalton> trading the patch for dri/compiz is a no-brainer to me :)
[16:12] <mdz> pitti: is there any known problem which is *not* fixed by disabling desktop effects?
[16:13] <mdz> tjaalton: why did it go in in the first place?
[16:13] <Mirv> mdz: ok, right. well, one has to force to use the version in the PPA. I'm upgrading from my own build now to those built by the build farm.
[16:13] <pitti> mdz: bug 311895, but it seems that it's very rare (I'm hit by it)
[16:13] <pitti> mdz: it has a workaround as well, though
[16:13] <Mirv> one point was that the patch doesn't give us anything really significant, so if it helps some it should be an easy decision to drop it
[16:14] <tjaalton> mdz: because it was requested, and the regression was not known back then
[16:14] <mdz> the changelog says it was to fix bug 146298
[16:15] <tjaalton> right, and it was a mistake to add it
[16:16] <tjaalton> leaving it out is not a regression compared to intrepid
[16:16] <mdz> if it was clear that it caused this regression, I would agree
[16:16] <mdz> however, it's not at all clear to me that this patch is the root cause
[16:16] <tjaalton> there are others too which have confirmed that
[16:16] <mdz> we have multiple reports in the bug that people still see frequent freezes with the patch reverted
[16:17] <mdz> including one from bryce: https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/xserver-xorg-video-intel/+bug/359392/comments/56
[16:18] <tjaalton> in some of the bugs
[16:18] <tjaalton> ok
[16:18] <tjaalton> gotta go now ->
[16:18] <mdz> there is no reproducer
[16:18] <slangasek> kwwii: what tools did you use to make the updated .png for bug #345523, OOI?  I poked a bit with gimp, and haven't seen anywhere near that big of a size increase on the new .png
[16:20] <mvo> mdz: I can get hold of a 965 system if we need someone to reproduce
[16:21] <kwwii> slangasek: I didn't make it, it was from the community
[16:21] <kwwii> slangasek: and I tried to make it smaller but to no avail
[16:23] <slangasek> kwwii: ah - strange, wonder how that got mangled
[16:23] <slangasek> well, .jpg seems sensible anyway, but is the extension stored in the gconf settings?
[16:24] <kwwii> slangasek: well, only if you have selected it as a background :)
[16:24] <slangasek> kwwii: right, so, that'd be a regression for some people...
[16:24] <kwwii> yeah, for anyone who has already installed and selected that pic
[16:25] <kirkland> slangasek: dput -f kvm_84+dfsg-0ubuntu11_source.changes
[16:25] <kirkland> slangasek: uploaded without the clock fix
[16:25] <slangasek> kwwii: how about if I continue poking at the original image later today, and see if I can come up with a minimal fix?
[16:25] <slangasek> kirkland: thanks
[16:25] <kirkland> slangasek: we'll work on that one a bit more
[16:25] <kwwii> slangasek: sounds good to me
[16:26] <pitti> kwwii, slangasek: wouldn't it be enough to just drop the alpha channel from the png?
[16:26] <kwwii> pitti: no, it will then have stripes on the left and bottom
[16:27] <pitti> kwwii: uh, why?
[16:27] <pitti> how's that different to any other background image which doesn't match the screen ratio?
[16:27] <slangasek> pitti: because the area in question doesn't have any meaningful color data :)
[16:27] <slangasek> so it'd render as *some* color
[16:27] <slangasek> but not a pretty one
[16:28] <kwwii> pitti: we zoom the pics, the pics themselves do not have a solid colored border
[16:28] <pitti> hm, then could we just cut off the invalid areas?
[16:29] <Aleksey_S> hi all
[16:29] <kwwii> pitti: no, it would not have a decent aspect ratio
[16:29] <slangasek> that, and you would be scaling by a percentage that's just off a sane ratio
[16:29] <directhex> zoom & crop!
[16:31] <Mirv> I wonder if tjaalton uses amd64, and if dropping the max texture patch only helps amd64 users. that might be one explanation, or else there are some pretty big differences between even different GMA X3100 implementations (bug 345119)
[16:31] <BUGabundo> hi
[16:32] <BUGabundo> just tripped on a memory leak on gnome search tool
[16:32] <BUGabundo> how can I run it with valgrind ?
[16:32] <Aleksey_S> Guys, are there someone experienced in audio?
[16:32] <BUGabundo> Aleksey_S: talk to dtchen if is around!
[16:33] <Aleksey_S> BUGabundo: : seems as he is away
[16:33] <BUGabundo> yeah it's a bit soon
[16:33] <BUGabundo> try after 18h GMT
[16:34] <slangasek> kwwii, pitti: do you want to see whether http://people.ubuntu.com/~vorlon/simple-ubuntu.png appears correct to you?
[16:34] <Keybuk> jcastro: SuSE is not coming out happy at all on these graphs :)
[16:35] <BUGabundo> slangasek: isn't that a bit to bright in the center?
[16:36] <pitti> slangasek: works fine for me
[16:36] <slangasek> BUGabundo: art is not my department, I'm trying to fix a technical bug
[16:36] <BUGabundo> ok
[16:36] <pitti> slangasek: I see no noticeable difference except for the weird borders going away
[16:36] <slangasek> pitti: this one is 16K smaller than the original :)
 :)
[16:36] <pitti> slangasek: heh, 16KB worth of bugs :)
[16:38] <calc> Keybuk: looks like f11 could beat us by the time it is released
[16:39] <kwwii> slangasek: looks good to me
[16:40] <pitti> kwwii: could you commit that to the branch, and I get it uploaded?
[16:40] <kwwii> pitti: will do, just take a second
[16:40] <pitti> slangasek: thanks, I'll shepherd it through
[16:40] <slangasek> great, thanks
[16:41] <Keybuk> calc: possibly, they release later
[16:41] <Keybuk> though harald's numbers are a bit different to mine
[16:42] <Keybuk> he installed Snap1 and updated, I installed Beta
[16:42] <calc> what is the boot time goal for karmic? :)
[16:42] <calc> 10s? :)
[16:42] <Keybuk> there is no current goal
[16:42] <ion_> −5 s would be nice.
[16:42] <calc> ok
[16:42] <Keybuk> I've suggested 10s, but the desktop team are pushing back very hard and saying they can't make login any faster
[16:43] <kwwii> pitti: commited to ~ubuntu-art-pkg/ubuntu-wallpapers
[16:44] <Mirv> calc: note also that harald only measures time to gdm. what is more meaningful is time from grub to usable desktop (timeable with auto-login)
[16:44] <calc> Mirv: yea
[16:44] <LaserJock> is the boot time defined as 'til gdm or with gdm starting a session?
[16:44] <calc> Keybuk: what is your current time to desktop?
[16:45] <Keybuk> calc: haven't measured since beta actually
[16:45] <Mirv> LaserJock: for our purposes it's untild desktop, but often casual looks to "boot time" only mean to gdm
[16:45] <Keybuk> but we're in the 25-30s range I suspect
[16:45] <Keybuk> unless something has gone horribly wrong
[16:45] <calc> Keybuk: ok
[16:45] <Mirv> for me it's a tiny bit under a minute, but I'm using encrypted installation
[16:45] <LaserJock> I noticed for jaunty that startup -> gdm got very fast, but gdm -> desktop got much slower
[16:46] <MattJ> Hmm, seemed faster to me
[16:46] <cjwatson> liw: oh, crap, I know what's happening here
[16:46] <MattJ> But then without numbers that means nothing :)
[16:46] <calc> at 25s thats barely within 30s for a cold boot for systems with relatively good bios, so it would be nice to make a bit quicker, but not too bad in any case
[16:46] <cjwatson> liw: sort your Packages file lexicographically by package name and it'll work ...
[16:47] <cjwatson> liw: unfortunately there's a bit of undefined behaviour in d-i that's currently resolved by "netcfg" < "ppp-udeb" :-(
[16:48] <cjwatson> liw: (this is a bug, obviously! please file it)
[16:49] <cody-somerville> cjwatson, Should ppp-udeb maybe be moved to universe?
[16:50] <pitti> dendrobates: likewise-open-gui starts here, but I have no way to test it; do you know about positive test results with it?
[16:51] <cjwatson> cody-somerville: I think the most practical fix might be to take it off the CD
[16:52] <cjwatson> that way, it'll still be usable for netboot installations
[16:52] <cjwatson> slangasek: ^- would you be OK with that at this point? the change would consist of moving ppp-udeb from platform.jaunty/installer to platform.jaunty/supported-installer
[16:52] <cjwatson> or supported-installer-something
[17:18] <Mirv> bug 327362 might be worth a release note, since it apparently affects sizeable part of Nordic countries' users at least, and possibly other ISP:s
[17:18] <slangasek> cjwatson: having trouble finding the referent for this discussion in scrollback; what's the intent of this change?
[17:18] <Mirv> of course, it's ISP:s fault, but it worked in hardy and intrepid nevertheless
[17:19] <Mirv> though it can be argued whether avahi is a commonly used feature or not
[17:19] <slangasek> Mirv: please file a bug on the ubuntu-release-notes project
[17:19] <Mirv> slangasek: ok.
[17:19] <slangasek> i.e., open a task on
[17:19] <slangasek> using the same bug
[17:19] <kees> Mirv: how did it work in Intrepid?  that's been a long-standing behavior for Avahi.
[17:20] <radix> sladen: hi, I saw your message from last night, was the landscape-client confusion resolved?
[17:20] <radix> erg
[17:20] <radix> s/sladen/slangasek/
[17:20] <Mirv> kees: I don't really know what's been changed, but probably the detection routine used.
[17:20] <radix> slangasek: I think it was a mistaken upload; we definitely weren't trying to get another landscape-client released to jaunty
[17:20] <jdong> Mirv: avahi is pretty important on my home network and within my virtualization system...
[17:21] <jdong> cjwatson: soyuz bug on arabic transliteration filed.
[17:21] <Mirv> so far looking at the bug report there is one big ISP culprit, TeliaSonera. I don't know if there are others.
[17:21] <liw> cjwatson, what package should I file against? (ref. Package file needing to be sorted) -- debian-installer?
[17:23] <kees> pitti: is the amd64 retracer hung?
[17:23] <kees> pitti: (specifically 362197, 362256)
[17:24]  * calc headed to meet with a Ubuntu Tunisia person who is visiting Houston, be back in a few hours.
[17:25]  * calc hates driving in Houston traffic :\
[17:27] <pitti> kees: ah, thanks; the reboot killed it
[17:27] <pitti> kees: removed lock file, will run again soon
[17:28] <slangasek> radix: was still waiting in the queue pending your response - I've rejected it now, thanks
[17:28] <slangasek> huh, Ubuntu Tunisia
[17:30] <calc> https://wiki.ubuntu.com/TunisianTeam/En
[17:30] <calc> one of them is here in Houston for an international meeting of some sort
[17:30] <calc> http://isweep.org/
[17:33] <liw> cjwatson, #362989
[17:37] <kees> pitti: great, thanks
[17:37] <cjwatson> slangasek: the referent is bug 362989, which liw just filed
[17:38] <cjwatson> slangasek: both netcfg and ppp-udeb provide configured-network, so which one gets used is essentially random (there's nothing much else to resolve it, in this case); ppp-udeb isn't something I've ever seen used in Ubuntu
[17:39] <cjwatson> I wouldn't like to rule out that some people are trying to use it in preseeded cases, so I don't want to drop it out of main at this point
[17:39] <liw> are there still ISPs that require PPPoE for ADSL or cable modems?
[17:39] <ogra> in germany thats common standard
[17:40] <ogra> for dsl
[17:40] <liw> ogra, does ppp-udeb enable use of PPPoE during install?
[17:40] <ogra> not cable though
[17:41] <ogra> ugh, no idea, i never used pppoe during install
[17:41] <ogra> my router is installed from CD and then i simply ran pppoeconf post install
[17:42] <liw> cjwatson, can I delete the ISO on rookery?
[17:43] <cjwatson> liw: yes, fefel free
[17:43] <cjwatson> feel
[17:44] <cjwatson> liw: regardless of whether it enables it, it's never received any proper testing in Ubuntu, and I can see at least one flaw in it by eye
[17:44] <ScottK> liw: There's one fiber provider (Verizon FIOS for those who care) in the US that uses PPPoe on their older installs.
[17:46] <ogra> can someone let the recent usb-imagewriter upload into universe (sitting in unapproved, StevenK gave his ok as mobile RM for universe but is likely asleeep)
[17:47] <slangasek> well, the ppp-udeb package does include the pppoe module; but if it's not known to be usable, on balance it seems ok to me to drop the package out to supported
[17:47] <slangasek> cjwatson: ^^ so yeah, go ahead with that seed change
[17:47]  * slangasek goes back to digesting the very large morsel that is the ubiquity debdiff
[17:54] <cjwatson> slangasek: I don't think it's even normally installed, FWIW
[17:54]  * slangasek nods
[17:55] <liw> cjwatson, do you have instructions handy for replacing the kernel in the alternate image?
[17:56] <liw> cjwatson, it can't be simple enough to just replace install/initrd.gz and vmlinuz, can it?
[17:57] <cjwatson> liw: not beyond what's on InstallCDCustomization. Replacing those files (indeed, probably just vmlinuz) is enough as long as the module ABI hasn't changed
[17:57] <cjwatson> liw: but you'll also need to arrange for the correct kernel to be installed on the target system somehow
[17:58] <liw> cjwatson, that could be done manually via a chroot from the installer, surely?
[17:59] <ScottK> ogra: Accepted.
[17:59] <cjwatson> liw: yes
[17:59] <ogra> ScottK, gracias :)
[17:59] <ScottK> No problem.
[17:59] <liw> cjwatson, excellent, thanks; I'll give it a try later, then
[18:14] <kirkland> slangasek: with respect to https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/361754 ...
[18:14] <kirkland> slangasek: <soren> kirkland: It's hard to say that we shouldn't worry about regressions.. What I /can/ say, though, is that the other clock sources are very well tested.
[18:14] <kirkland> slangasek: perhaps not entirely the answer you're looking for
[18:15] <kirkland> slangasek: personally, i'm okay with vetting that fix through the -propsed and -updates channel
[18:15] <kirkland> slangasek: strangely, dholbach is the only person I know of that has hit that bug
[18:15] <kirkland> slangasek: and we weren't able to isolate "why"
[18:22] <azimut> xerakko
[18:31] <ebroder> This is going to sound more...frustrated than I actually am, but when the release team or SRU team ACKs an upload for someone who doesn't have upload privileges, why don't they just upload it themselves? Why does the contributor have to go hunting for a sponsor after that?
[18:31] <ebroder> Is it that the release/SRU ACK is just on a conceptual level, and not an ACK on the specific implementation?
[18:31] <cody-somerville> ebroder, correct
[18:32] <ebroder> Ok. I guess that makes sense
[18:32] <jdong> ebroder: generally when  I ACK and there is a debdiff attached and the sponsors have been subscribed, I will just sponsor it in.
[18:32] <jdong> it isn't standard procedure though, but perhaps it should be
[18:33] <ebroder> jdong: Yes, you've been particularly good to me in that regard :)
[18:33] <jdong> otherwise sponsorship latency is a bit annoying
[18:35] <cjwatson> ebroder: the other reason is that the release/SRU teams are small and tend to be bottlenecks as it is, and need to be able to process requests efficiently
[18:36] <ebroder> I'm not actually sure I believe that - I feel like when release/SRU hasn't sponsored the upload when the ACKed, I've spent a lot more time trying to find a sponsor than I spent trying to get the ACK
[18:37] <ebroder> I guess I tend to try and push on my bugs here, which tends to find more release/SRU types and fewer sponsors, at least on a per capita basis
[18:37] <cjwatson> ebroder: you don't believe that the release/SRU team are bottlenecks? (note that I didn't say the sponsoring teams are any better, although I do think they should be)
[18:39] <ebroder> I'm sure there are a lot of factors. I probably have good luck, and also tend to push uncontroversial bugs that don't take a lot of time to investigate for the release/SRU signoff
[18:39] <ebroder> I suspect that bugging people in IRC has a lot to do with being able to move my bugs forward
[18:40] <jdong> ebroder: well the responsibility of the SRU/release teams is to review and say yes/no, and the job of the sponsors is to upload on behalf of those who cannot...
[18:40] <jdong> but yeah the sponsor queue can get understandably large
[18:40] <jdong> and sponsors I found back while I was non-MOTU tended to be a bit gun-shy about rubber-stamping uploads too
[18:41] <ebroder> *nods* That's understandable - if I could sponsor I wouldn't want to just rubber-stamp either
[18:43] <LaserJock> originally we thought that 1) that non-MOTU should have MOTU sponsors *before* going to MOTU SRU 2) that MOTU SRU shouldn't be burdened with the whole SRU cycle
[18:44] <ScottK> But no one would take the time to review stuff for sponsorship they didn't even know if would go in.
[18:45] <LaserJock> the presumption was that rejections from MOTU-sponsored SRUs would be quite rare
[18:45] <LaserJock> but yeah, it turns out people want to know if they *should* fix before the do the fix
[18:47] <dtchen> really? i've found that i have to push quite hard to get fixes in
[18:47] <dtchen> (...which seems a bit odd, since one would think that a former core-dev would know which fixes are appropriate at the point in the dev cycle)
[18:48] <LaserJock> well, when we went from no-SRU policy to a SRU policy the idea was that it was just minimal quality control to avoid the X-in-dapper problems
[18:48] <LaserJock> it was mostly presumed that developers knew what a SRU was and what qualified
[18:49] <ebroder> Hmm...that's interesting. I didn't know that there weren't always SRUs. I bet the view of what's acceptable for an SRU today has broadened substantially since then
[18:49] <LaserJock> well, there has pretty much always been SRUs in the sense of having -updates
[18:50] <LaserJock> but it used to be that a dev could upload directly to -updates, without any paperwork or testing
[18:52] <LaserJock> dtchen: it is odd, yes
[18:54] <jdong> ebroder: at one point it was literally universe-glues-shut-on-release....
[18:54] <jdong> ebroder: everything from unbuildable packages to segfaults-on-launch.
[18:55] <jdong> Universe was kinda "that crap from Sid nobody bothered to look at carefully"
[18:55] <LaserJock> ah, the good old days ;-)
[18:57] <cjwatson> ebroder: the SRU process was introduced as a reaction to the major X regression in 2006
[18:57] <jdong> LaserJock: brings back so many good memories. Probably nightmares of former jdong to you guys though :)
[18:58] <LaserJock> "OMG, what the heck is that backports nut doing now!!!!"
[18:58] <LaserJock> you know we love you and your large MIT brain :-)
[19:04] <paolob> Hi guys! Let me ask you before opening a bug. In my Jaunty beta gnome, it's happening that when I'm writing a doc with Oo.o, after some 100/200 characters the keyboard begins entering very strange characters, and I haven't found any way to modify this behaviour rather than closing Oo.o and reopening it. I have italian localization, italian keyboard, but I have a spanish layout too in my gnome settings. Any idea about anything similar?
[19:11] <ScottK> I just did an upgrade to Jaunty and ended up with no 2.6.28 in grub/menu.list.  Do I follow up on that here or #ubuntu-kernel?
[19:12] <ogra> did you get a debconf question for your menu.lst ?
[19:12] <ScottK> I did not.
[19:12] <ScottK> I then ran update-grub and it still isn't there.
[19:13]  * ogra saw that for people that had edited menu.lst in the wrong place, got a debconf question and asked debconf to keep the old file 
[19:13] <ogra> but thats the only case i have seen it yet
[19:13] <ebroder> ScottK: The update did install the new kernel, right?
[19:13] <ScottK> It's vaguely possible I looked away and accidentallly hit something.
[19:13] <ScottK> Yes
[19:13] <JFo> j/k
[19:13] <ScottK> update-grub lists it as found, but it doesn't get added.
[19:14] <bryce> pitti, mdz, rickspencer3: mesa change uploaded, to drop patch 103.  Ready for archive admin review.  Moving on to tool packaging.
[19:14] <pitti> bryce: rock, thank you
[19:15] <ScottK> So I assume I can manually add it, but wanted to see if there's anything that should be checked first?
[19:15] <ScottK> I do have a manually edited menu.list.
[19:15] <slangasek> ScottK: sounds like ucf remembering a previous "no thanks"
[19:15] <slangasek> ScottK: or, what do you have your debconf frontend set to?
[19:16] <davmor2> bryce: I'm after a cheapish ati card for testing purposes but I want to get one that will be supported for a while do you have an suggestions on preferred chipsets?
[19:16] <bryce> R5xx are my favorite
[19:16] <davmor2> bryce:  Thanks dude
[19:17] <ScottK> slangasek: This is on my kid's computer, so I didn't set it to anything.
[19:17] <bryce> at this point in time, on jaunty R5xx with -ati seems to be the optimal point in terms of {performance, stability, functionality, upstream support, openness}
[19:17] <cody-somerville> Why is linux-generic in restricted?
[19:18] <dtchen> Depends: linux-restricted-modules-generic  <--
[19:18] <davmor2> bryce: so any regressions would be quite apparnet then :)
[19:18] <slangasek> ScottK: the thing would be to compare /var/lib/ucf/cache/\:var\:run\:grub\:menu.lst and /boot/grub/menu.lst (ignoring the diff for the non-managed sections of the file)
[19:19] <ScottK> Chekcing
[19:20] <slangasek> if the 2.6.28 shows up in the cache, then it's a ucf issue; if it doesn't, it's a non-ucf update-grub issue
[19:21] <bryce> davmor2: yep
[19:21] <bryce> davmor2: RV535 [Radeon X1650 Series] is what I own and use on my desktop
[19:21] <bryce> davmor2: and I always install new -ati's on it before uploading to check for regressions, so....  ;-)
[19:24] <ScottK> slangasek:  /var/lib/ucf/cache/\:var\:run\:grub\:menu.lst has all the 2.6.28 options listed in it.
[19:24] <slangasek> ScottK: ok - and it has other diffs as well, relative to your live kernel list?
[19:25] <ScottK> No.  Just htat
[19:26] <ScottK> slangasek: That file contains exactly what I would have expected to see starting with ## End Default Options ## to the end of the automagic kernels list.
[19:26] <ScottK> Nothing else.
[19:26] <slangasek> ScottK: hrm, that's odd
[19:26] <slangasek> ScottK: I can't account for that, then; please open a bug on grub and attach both files
[19:27] <ScottK> slangasek: OK.  Will do.
[19:34] <pitti> bryce: the mesa upload will auto-close the bug, but I don't think that's justified since it doesn't help all people
[19:35] <pitti> bryce: ah ignore me, the bug is against -intel
[19:36] <slangasek> superm1: ping, re: bug #341898
[19:36] <ScottK> slangasek: Bug 363049 filed.
[19:36] <slangasek> superm1: would like to get that pushed in for you ASAP, but would also like to know that it's getting upstream eyeballs on it
[19:36] <bryce> pitti: yep.  If it did close it, I'd reopen it.  Although, we have no shortage of other freeze bug reports ;-)
[19:37] <pitti> bryce: it's just the one we just asked everyone to comment on
[19:37] <bryce> pitti: yep, I wanted to make sure to link it to the patch in the upload note
[19:40] <superm1> slangasek, yeah i dropped in #dri-devel, and had some comments that it looked sane.  they wanted me to send it to mesa3d-dev ML, and the upstream wants me to try a different patch not yet in git before resorting to this patch, so i'll have feedback later today about that
[19:40] <slangasek> superm1: ok, so I should continue sitting on the package in the queue...?
[19:40] <superm1> slangasek, yeah let it sit in the queue for the moment being
[19:41] <slangasek> superm1: note that there's some other mesa work in progress related to intel, so it may be better to reject and let you re-upload based on bryce's latest changes once decided
[19:41] <superm1> slangasek, sure that sounds fine to me
[19:42] <superm1> tjaalton, bryce: the git tree will need to be adjusted with relation to that though ^
[19:42] <slangasek> bryce: ^^ sorry for the hassle; can you reupload the intel fix as -3, dropping the radeon change for now?
[19:42] <pitti> bryce: can you please rebase your upload in -2 then?
[19:42] <pitti> heh
[19:43] <bryce> ah, sure... one sec
[19:44] <pitti> bryce: I rejected your ubuntu4 upload
[19:44] <slangasek> bryce: also, the previous upload had an extra debian/patches/05_texture_size.patch in it, not mentioned in the changelog (or in the series file)
[19:45] <bryce> (hrm, I bet there is a simple way to do this in git, but I don't trust my git fu)
[19:47] <bryce> hmm
[19:49] <bryce> slangasek: ah, got it sorted thanks.  stray patch
[19:52] <slangasek> ScottK: well, there is another difference: your menu.lst also mentions 2.6.27-7, which I think is no longer installed?
[19:52] <ScottK> True
[19:53] <ScottK> I missed that.
[19:53] <slangasek> that at least explains a possible path how this happened
[19:53] <ScottK> That's comforting.
[19:53] <slangasek> 1) customize menu.lst by hand, 2) remove a kernel, 3) remove the customization in menu.lst but leave the old kernel stanzas in place
[19:53] <slangasek> is that plausible here?
[19:54] <ScottK> The customization was still there (it's the rootdelay=90)
[19:54] <slangasek> ah, yes
[19:54] <ScottK> There is good news though.
[19:55] <ScottK> This is the original machine against which the D945 fails to boot bug was filed and it booted 2.6.28-11 without the rootdelay.
[19:55] <slangasek> ah :)
[19:55] <ScottK> I'm rebooting again to make sure it wasn't a fluke.
[19:56] <slangasek> if you want to make ucf happy, you can add '# kopt_2_6_27_11_generic=root=UUID=d73b6252-08ff-4920-b197-7b5492045931 ro rootdelay=90' and rerun update-grub, and it should prompt you to reconcile
[19:57] <slangasek> oh, maybe it won't
[19:57] <slangasek> but if you make that change, and delete the stale 2.6.27-7, it will
[19:57] <slangasek> we do need a better way to be able to trigger a ucf prompt for this
[19:58] <mvo> mathiaz: should I talk to aobut iscsi: http://paste.ubuntu.com/152977/ - just happendin a auto-upgrade test
[19:58] <ScottK> OK.  If I like my menu.lst the way it is now, is there an easy way to get ucf just to believe that's what should be there?
[20:07] <asac> any idea how the /usr/lib/gcc/x86_64-linux-gnu/4.3/32/libstdc++.so link is shipped ? dpkg -S doesnt know about it and some amd64 installs seems not to have that (but i have it)
[20:07] <jdong> what is the correct place regarding dell mini 9 Hardy specific concerns?
[20:07] <asac> for me its /usr/lib/gcc/x86_64-linux-gnu/4.3.3/32/libstdc++.so -> ../../../../../lib32/libstdc++.so.6
[20:07] <jdong> I am pretty unhappy that the udev security update has not propagated into its security repo in an acceptable latency
[20:07] <slangasek> asac: because /4.3/ is a symlink to /4.3.3/
[20:08] <mathiaz> mvo: was that an upgrade from intrepid?
[20:08] <mvo> mathiaz: yes
[20:08] <slangasek> asac: so canonicalize the parent path
[20:08] <kees> jdong: ?
[20:08] <mvo> mathiaz: let me create a proper bugreport with the full terminal log
[20:08] <asac> slangasek: great. thanks!
[20:08] <mathiaz> mvo: ok - TBH iscsi is broken in intrepid.
[20:08] <kees> jdong: on, for the mini
[20:09] <kees> er, s/on/oh/
[20:10] <jdong> kees: right, the canonical archive that is used for the mini; for security updates in gneeral it seems to lag at least a month or two or forever behind.
[20:10] <kees> jdong: yeah, they're trying to keep up.
[20:11] <cody-somerville> They don't lag a month or two
[20:11] <jdong> cody-somerville: really? Since day0's update of owning this thing for a month, today is the first set of updates I have received.
[20:11] <cody-somerville> Security updates are generally deployed within three days
[20:11] <cody-somerville> hpmini or dell mini?
[20:12] <jdong> dell mini
[20:12] <jdong> I will take a closer look but I am 99% confident it is not three days
[20:12] <ScottK> jdong: Stock Kubuntu works on the Dell mini if you want to run it out of the regular repos (Jaunty)
[20:13] <jdong> ScottK: right, I plan on moving to a stock jaunty this weekend
[20:13] <jdong> ScottK: but considering these things are sold with no upgrade path it still concerns me
[20:13] <ScottK> There was a recent blog post on planet about support for them too I recall.
[20:14] <jdong> libxine1: Installed: 1.1.11.1-1ubuntu3.1
[20:14] <jdong> vs libxine1: Installed: 1.1.11.1-1ubuntu3.1
[20:15] <jdong> err 3.3 rather
[20:15] <jdong> USN 746-1 Mar 26 2009
[20:15] <jdong> closing in on a month.
[20:15] <cody-somerville> Whats the candidate?
[20:15] <jdong> that is the latest candidate from         500 http://dell-mini.archive.canonical.com hardy-security/main Packages
[20:16] <bryce> pitti, slangasek, mdz, superm1: Rejiggered mesa 7.4-0ubuntu3 uploaded
[20:16] <jdong> dash:   Candidate: 0.5.4-8ubuntu1
[20:16] <kees> cody-somerville: did you mean CVE?  that's  CVE-2009-0698
[20:16] <jdong> vs   Candidate: 0.5.4-8ubuntu1
[20:16] <jdong> vs 1.1 rather
[20:16] <cody-somerville> :P
[20:16] <jdong> mar 10 USN 732-1
[20:17] <jdong> more than one month
[20:17] <slangasek> cody-somerville:   libxine1 | 1.1.11.1-1ubuntu3.3 | hardy-security | amd64, hppa, i386, ia64, lpia, powerpc, sparc
[20:17] <jdong> sudo
[20:17] <jdong> 3.2 vs 3.4
[20:17] <pitti> bryce: thanks
[20:17] <jdong> USN 722-1 Feb 17
[20:17] <jdong> two months.
[20:18] <mvo> mathiaz: look like its bug #306678
[20:19] <mathiaz> mvo: yes.
[20:19] <mathiaz> mvo: it's one of the issue.
[20:20] <mathiaz> mvo: I've added the upgrade failure you've just pasted.
[20:20] <mvo> mathiaz: this one looks relatively simple to fix?
[20:20] <mathiaz> mvo: yes - there are two things to fix actually.
[20:20] <cody-somerville> jdong, What is your sources.list?
[20:20] <mathiaz> mvo: I'm preparing a debdiff. Should this go in release or -updates?
[20:21] <jdong> cody-somerville: whatever the stock one is that ships, lemme paste it
[20:21] <jdong> cody-somerville: http://paste.ubuntu.com/152993/
[20:21] <mvo> mathiaz: this is a release-manager question :) I personally think if its just "remove open-iscsi" -> "open-iscsi remove" (or similar scale) we should aim for release
[20:22] <mathiaz> mvo: it's this change plus an ln -s to ln -sf
[20:22] <mvo> mathiaz: thanks, I think this should be -release if  possible (is it on the CD?)
[20:23] <cody-somerville> jdong, Are you sure dash is not up to date?
[20:23] <mvo> mathiaz: but of course the slangasek has the final word in this. a sru should be simple enough for it too
[20:23] <mathiaz> mvo: yes - it's on the -server iso.
[20:24] <cody-somerville> jdong, nvm
[20:25] <jdong> cody-somerville: well unless there's an apt-get secret-moo-upgrade ;-)
[20:25] <mvo> mathiaz: I got a failure with bacula-sd as well: http://paste.ubuntu.com/152998/
[20:27] <mathiaz> mvo: hm - this hasn't been reported yet. Could you file a report?
[20:28] <mvo> mathiaz: sure
[20:29] <mathiaz> slangasek: bug 306678 <- should this go to jaunty or jaunty-proposed?
[20:32] <c_korn> odd, I have an invisible mouse cursor in jaunty using virtualbox. but I can open menus and everything with it
[20:33] <c_korn> is compiz related. mouse cursor is visible after disabled compiz
[20:34] <slangasek> mathiaz: jaunty please
[20:34] <ikus060> Hi, I have an issue with Apple Keyboard here. I manage to fix it in the kernel, but I want it to be in the next one. Is there any way to accelerated the process ??
[20:34] <mvo> mathiaz: filed as bug #363077
[20:40] <askand> Anyone here familliar with the new notify-osd?
[20:40] <pitti> askand: davidbarth or MacSlow, but neither are online any more
[20:40] <askand> pitti: ever again?
[20:41] <pitti> well, try Monday during European work hours, or email :)
[20:41] <askand> ah ok :)
[20:42] <askand> Well, I might as well bring my toughts now, it won't hurt
[20:43] <mathiaz> mvo: is there a way to tell do-release-upgrade to not disable local apt repositories when doing an system upgrade?
[20:43] <ikus060> askand: Ask you question. Maybe someone  can help you
[20:43] <askand> http://pici.se/396034/ here is a screenshot of pidgin using the new notify-osd, as you can see the image is lowres. The problem is that that image is all we get. I don't know how this can be solved
[20:43] <askand> Perhaps not upscaling them
[20:45] <jcastro> pitti: wrt the rotate-forver script, if you right click on the titlebar and check "always on visible workspace" on the terminal with the script that should make sure it's on the screen when it locks up
[20:45] <mvo> mathiaz: yes, give me a sec
[20:45] <jcastro> pitti: as opposed to just being unlucky
[20:46] <pitti> jcastro: good idea
[20:47] <mvo> mathiaz: create /etc/update-manager/release-upgrades.d/myconf.cfg and put in there [Sources]\nAllowThirdParty=yes
[20:48] <mathiaz> mvo: great. Will that modify the occurence of jaunty in the third party apt sources.list?
[20:49] <mvo> mathiaz: it should just rewrite intrepid, jaunty and leave everyhting it does not understand alone
[20:49] <mvo> mathiaz: let me know if that works as expected
[20:49] <mathiaz> mvo: awesome thanks.
[20:50] <kees> language packs are biiig
[20:53] <ScottK> mvo: If you end up doing another update-manager upload, I'd like to toss Bug 363022 your way for consideration.
[21:02] <mvo> ScottK: thanks, I have a look
[21:02] <ScottK> Great.
[21:12] <ScottK> Does anyone have access to ia64 hardware with Jaunty (or chroot) and can help me figure out a build failure apparantely due to an installability issue with one of the depends?
[21:17]  * calc thinks users (non bug control) should not be able to change status of a bug once it has been marked as triaged
[21:18] <calc> i just had to mark a bug as triaged again after some user claimed to be "reopening it" by marking the bug as triaged->new and saying he still saw the bug, when it was already linked upstream and is going to be fixed in the next upstrem release
[21:19]  * calc thinks having non bug control not be able to change them at all would be better but at least not go from triaged->any other state would be helpful
[21:21] <ScottK> I'd vote for no non-developer being able to unmark fix released too.
[21:21] <ScottK> I see plenty of "This bug from two years ago isn't actually fixed because I see something kind of similar"
[21:22] <mathiaz> mvo: hm - it doesn't look like the AllowThirdParty option in release-upgrade.d is working.
[21:22] <mathiaz> mvo: my local apt repository has been disabled
[21:23] <mathiaz> mvo: http://paste.ubuntu.com/153021/
[21:25] <calc> ScottK: yea that too
[21:26] <calc> ScottK: anything marked triaged, fix committed, fix released, should be developer only for setting originally and changing (imho)
[21:27] <calc> ScottK: i've seen people mark my bugs invalid as well, since they were upstream (argh), but i can't remember if i had them already marked as triaged at the time
[21:27] <ScottK> Gotta get the bug numbers good.
[21:30] <calc> my bug numbers are already good :-)
[21:30] <calc> triaged doesn't really count against you, its new/incomplete bugs that hurt the stats
[21:30] <calc> and unfixed non-upstream bugs
[21:31] <mvo> mathiaz: hrm, so it commented stuff out in sources.list? or is it just a misleading message?
[21:31] <calc> only about 7% of my bugs aren't triaged atm :)
[21:31] <mathiaz> mvo: it commented out stuff in sources.list
[21:32] <mvo> mathiaz: thanks, testing now
[21:33] <calc> mvo: do you know if it is feasible to catch out of space errors from dpkg, or have dpkg report out of space issues better. so we don't get bug reports from users for those cases (as noted in my ubuntu-devel post from a few days ago)?
[21:36] <mvo> calc: hm, it tries to do that :/
[21:37] <mvo> calc: it checks for ENOMEM errors
[21:37] <calc> mvo: oh? the reports i've seen it looked like dpkg didn't report it up the stack properly to keep the user from reporting it as a bug
[21:37] <mvo> and ENOSPEC
[21:37] <mvo> ENOSPC
[21:37] <calc> like bug 359176
[21:38] <calc> its possible its fixed in jaunty but wasn't in hardy/intrepid i suppose?
[21:41] <calc> i'm not sure what the user was using to upgrade, so perhaps the various packaging manager frontends need to be fixed to report disk out of space, instead of the dumb buffer_write failure message that the user reported
[21:41] <mvo> calc: it was added in intrepid, its quite possible that it does not get caught in cases where dpkg send a multi line progress string
[21:42] <calc> mvo: was the check just added to update-manager or in a way that other programs like synaptic report it properly as well?
[21:42] <mvo> calc: update-manager tries to figure it out these days, but in general its a hard problem as we do not know what parts of the deb take what size beforehand (e.g. is there enough space in /usr if that is on a different parition etc)
[21:42] <mvo> calc: just the higher level tools because its a heuristic
[21:43] <calc> well running out of space is bad... but if we know the system ran of space afterwards we can tell them it did and then make it such that they just don't report the bug in launchpad
[21:44] <calc> mvo: in case like this bug report it shows that dpkg knows it ran out of space, so it should be reporting up the chain a disk out space error code instead of a general failure code (not sure what it does exactly) and then keep apport from reporting the error
[21:44] <calc> eg:
[21:44] <calc> Dépaquetage de la mise à jour de openoffice.org-core ...
[21:44] <calc> dpkg : erreur de traitement de /var/cache/apt/archives/openoffice.org-core_1%3a2.4.1-11ubuntu2.1_amd64.deb (--unpack) : échec dans « buffer_write(fd) » (11, ret=-1) : backend dpkg-deb pendant « ./usr/lib/openoffice/program/libvcl680lx.so »: Aucun espace disponible sur le périphérique
[21:44] <calc> so dpkg-deb knows it ran out of space
[21:45] <mvo> mathiaz: could you please pastebin the full /var/log/dist-upgrade/main.log ? that is a bit myserious, when I test it locally here it works
[21:46] <mathiaz> mvo: ok - give me a few minutes. I'll try again
[21:46] <mvo> calc: agreed, I suspect the bug is that dpkg send the error message in two parts over the status pipe
[21:46] <mathiaz> mvo: I've started an apt-get dist-upgrade on the system as I need to test the open-iscsi update
[21:46] <mvo> mathiaz: sure, thanks (its getting late, I may not be around, just mail it in this case)
[21:47] <mathiaz> mvo: sure.
[21:47] <calc> mvo: i wasn't sure what packages need to have the bug reported etc so i just emailed the list, i'll try to remember to talk to you about it more at UDS and to upstream at Debconf
[21:49] <calc> fsck its hailing here now, we missed it last sunday but not today
[21:50] <calc> guess i'll have to take my cars into to be fixed next week :\
[21:50] <calc> s/into/in/
[21:50]  * calc might vanish soon if the power goes out
[21:57] <Jordan_U> Is it normal that update-manager wants to install a lot of -dbg packages on upgrade from 8.10 to 9.04 ?
[21:57] <Jordan_U> Sorry, wrong channel
[21:58] <calc> Jordan_U: if you have the ddebs line probably
[22:08] <cjwatson> calc: Triaged->Incomplete "does this still exist?" is my favourite bugbear
[22:09] <cjwatson> Jordan_U: you might have bug-buddy installed?
[22:09] <cjwatson> it recommends gnome-dbg, I believe
[22:10] <Jordan_U> cjwatson: Yes I do
[22:11] <cjwatson> it's no longer installed by default, although it's surprising that update-manager doesn't offer to remove it since it dropped out to universe
[22:12] <cjwatson> you might want to file a bug about that ('ubuntu-bug update-manager' after the upgrade)
[22:13] <Jordan_U> cjwatson: Will do, thanks
[22:14] <calc> cjwatson: heh yea
[22:22] <ScottK> mvo: Very nice quick turnaround on the gwenview bug.
[22:22] <ScottK> Thanks.
[22:22] <mvo> cheers, np
[23:03] <bryce> ogasawara: heya, I'd like to stick the 2.6.30-rc2 kernel into a ppa for folks to debug X.org freezes with
[23:03] <bryce> ogasawara: there's debs available at http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc2/
[23:04] <ogasawara> bryce: yup
[23:04] <bryce> ogasawara: however to put it in my ppa I need the .dsc file.  Any idea on if such a thing is available somewheres?
[23:04] <ogasawara> bryce: hrm, apw would be the one to ask, but he's away I think
[23:05] <IntuitiveNipple> Some update today has upset metacity: no window-decorations, cursor on 2nd screen becomes the default X cursor, no hot-key responses, blank and vertically extended tomboy notes
[23:05] <ogasawara> bryce: lemme ask rtg and see if he knows
[23:05] <bryce> kewl thanks
[23:05] <IntuitiveNipple> I've looked and the most likely are libgtk, libpanel-applet and libgail, but not sure where to start!
[23:05] <bryce> IntuitiveNipple: there was a new mesa upload today
[23:06] <ogasawara> bryce: shoot, rtg doesn't seem to be online at the moment
[23:06] <IntuitiveNipple> bryce: would that affect nvidia restricted driver?
[23:06] <bryce> IntuitiveNipple: only -intel
[23:06] <ogasawara> bryce: apw appears to be in #ubuntu-kernel (or at least logged in)
[23:06] <bryce> ogasawara: hmm, okay thanks.  I'll just put a link to those debs from my ppa for now
[23:06] <IntuitiveNipple> bryce: well that eliminates mesa as a cause then :)
[23:07] <bryce> that's a first ;-)
[23:07] <LaserJock> bryce: you know, you can build your own .dsc too
[23:08] <bryce> LaserJock: from just the .deb?
[23:08] <LaserJock> bah, no, I see what you mean
[23:08] <LaserJock> you meant source package
[23:08] <LaserJock> I thought you were just missing a .dsc
[23:09] <bryce> no... need like a git repo, or source tarball or something
[23:09] <bryce> not a huge deal, these .deb's should be fine for now
[23:09] <bryce> but I think folks would like having everything wrapped up in a single ppa
[23:59]  * calc notes the more he looks at upstream OOo the more scared he becomes :\ fixing this mess is a near impossible task