[00:24] <slangasek> kirkland: ah - if he cares, I guess he probably already pruned it when committing :)
[00:28] <mdz> booting the latest karmic only blew up a little for me (grub.cfg/MBR mismatch)
[00:55] <TheMuso> Is there an easy way to search for ITP bugs in bugs.debian.org?
[00:56] <ajmitch> the only way I know of is looking at bugs.debian.org/wnpp
[00:57] <TheMuso> ajmitch: thanks
[01:19] <TheMuso> dtchen: Lennart really pushes the boundary. We will not be able to offer pulse 0.9.16 for testing till we have kernel 2.6.31. :S
[01:21]  * TheMuso goes and fumes in the corner.
[02:18] <ScottK> That'll teach dtchen to promise we're dropping our diff from upstream.
[02:22] <TheMuso> ScottK: Well its not really a diff. Its having to wait till we move onto the newer kernel version.
[02:22] <ajmitch> TheMuso: we'll be getting 2.6.31 for karmic?
[02:23] <TheMuso> ajmitch: I believe so.
[02:23] <TheMuso> Its even mentioned in the #ubuntu-kernel channel topic.
[02:24] <ajmitch> ok
[02:24]  * ajmitch doesn't visit there :)
[02:25] <TheMuso> At one point I would have said that thats pushing things a bit far, but now that Pulse needs it, I await it eagerly.
[02:25] <TheMuso> Pulse development is still moving very rapidly.
[02:26] <ion> Why does it need 2.6.31?
[02:26] <ScottK> So it's a 3 kernel version release agaon.
[02:26] <ScottK> again ....
[02:26] <TheMuso> ion: Pulse specifically doesn't, but pulse now depends on rtkit which needs 2.6.31.
[02:26] <ScottK> That worked out soooo well last time.
[02:27] <TheMuso> ScottK: I tend to agree.
[02:27] <ajmitch> ScottK: hopefully with a few more people working on it this time it'll be a bit less problematic
[02:27] <ion> rtkit, huh. /me looks it up. Probably not as bad as it sounds. ;-)
[02:27] <TheMuso> ion: its a new Lennart creation.
[02:27] <ScottK> ajmitch: What makes you think there will be more people working on the kernel in Karmic than Intrepid?
[02:28] <ajmitch> ScottK: I thought that the team had grown a little in the last year or so
[02:28] <TheMuso> I believe it has.
[02:28] <ScottK> OK.  Well I hope so.
[02:28] <ScottK> Intrepid was the first time I had systems I couldn't upgrade due to kernel problems.
[02:30] <ajmitch> I don't recall too many people saying that intrepid's kernel was buggier than previous releases
[02:33] <ScottK> My personal experience was pretty awful, but of course everyone has different stuff, so see it differently.
[05:54] <lifeless> yay karmic
[05:54] <lifeless> $ python
[05:54] <lifeless> Python 2.6.2+ (release26-maint, Jun 19 2009, 15:16:33)
[05:54] <lifeless> [GCC 4.4.0] on linux2
[05:54] <lifeless> Type "help", "copyright", "credits" or "license" for more information.
[05:54] <lifeless> >>> import qt
[05:54] <lifeless> Segmentation fault
[05:55] <NCommander> lifeless, by some definitions, that's a feature
[06:28] <mrooney> haha, truly
[06:40] <dholbach> good morning
[06:48] <pitti> Good morning
[06:53] <directhex> microsoft-sponsored party this evening. i feel it is my duty to wear my uds crew shirt
[06:57] <pitti> didrocks: lol! have fun
[06:57] <enrico> directhex: and to eat and drink as much as possible, so that as much as possible of their money gets spent on free software people!
[07:00] <pitti> (with drinking not necessarily into free software _quality_ :-P)
[07:02] <Chipzz> NCommander: rofl :)
[07:24] <pitti> tkamppeter_: when you merge, please use debuild -S -v<previous version in Ubuntu>, so that the .changes gets the merged changelogs from Debian as well; thanks!
[07:28] <tkamppeter> pitti, sorry.
[07:28] <pitti> tkamppeter: no problem, just a reminder for the future; nicer to read on karmic-changes@
[07:29] <tkamppeter> pitti, now my only missing merge is Gutenprint, but I will wait for the 5.2.4 release which will come in the next days.
[07:29] <pitti> tkamppeter: that'll go into Debian soon?
[07:31] <tkamppeter> pitti, depends on the Debian maintainer.
[07:32] <tkamppeter> I want to have it in Karmic anyway.
[07:33] <tkamppeter> pitti, by the way, Poppler 0.11.0 did not make it into Debian yet.
[07:39] <pitti> tkamppeter: ah, I thought you wanted to wait with the merge until .4 is in Debian
[07:39] <pitti> tkamppeter: poppler> they'll wait for 0.12 to get the stable series; Seb said it should get released in a few weeks
[07:41] <tkamppeter> pitti, if the Debian maintainer quickly updates I can get gutenprint 5.2.4 in by merge, if not I will take it directly to get it in before FF.
[07:46] <tkamppeter> pitti, OK if 0.12 gets into Debian before our FF, we simply reactivate pdftoopvp in the cups package, if it comes too late, we need to reactivate pdftoopvp in a Ubuntu-only way.
[07:48] <pitti> tkamppeter: gutenprint> sure; but if that will still take a while, don't hesitate to merge it now (also to get our remaining patches to Debian), then the next merge will be easier, and Debian can also apply patches to their 5.2.4 upload
[07:48] <pitti> tkamppeter: poppler> right, that will be a little tricky in the cups package, but doable
[07:57] <dholbach> does anybody else have held mono packages in karmic? (amd64?)
[08:00] <TheMuso> dholbach: Yeah when I upgraded earlier today I did.
[08:01] <dholbach> does anybody know what the hold up is there?
[08:01]  * dholbach wants his gnome-do to work again
[08:02] <pitti> works fine here; only held back package here is libgdl-1-common
[08:02] <pitti> (I guess due to amd64/i386 build skew)
[08:02] <persia> dholbach, Likely arch-all vs. arch-any and a publisher run, try refreshing your cache.
[08:03] <dholbach> persia: it's stuck since yesterday
[08:04] <persia> dholbach, Erg.  That's too long.  What's at the bottom of the stack?
[08:04]  * persia doesn't currently have any working amd64 hw, and can't check.
[08:05] <persia> Alternately, if you don't want to chase the stack, just feed rmadison a *really* long line including all the packages you have held back, and see if there is any skew.
[08:05] <dholbach> The following packages will be REMOVED:
[08:05] <dholbach>   mono-2.0-runtime mono-common mono-jit ubuntu-desktop update-manager
[08:05] <dholbach>   update-notifier
[08:05] <dholbach> The following NEW packages will be installed:
[08:05] <dholbach>   binfmt-support libmono-i18n-west2.0-cil
[08:05] <dholbach> The following packages will be upgraded:
[08:05] <dholbach>   libmono-corlib2.0-cil libmono-data-tds2.0-cil libmono-data2.0-cil
[08:05] <dholbach>   libmono-getoptions2.0-cil libmono-posix2.0-cil libmono-security2.0-cil
[08:05] <dholbach>   libmono-sharpzip2.84-cil libmono-sqlite2.0-cil libmono-system-data2.0-cil
[08:05] <dholbach>   libmono-system-web2.0-cil libmono-system2.0-cil libmono2.0-cil mono-2.0-g
[08:05] <dholbach>   mono-gac mono-gmcs mono-runtime update-manager-core
[08:05] <dholbach> hi mvo :)
[08:05] <pitti> dholbach: oh, I think I had that yesterday, and I just had it remove them
[08:05] <mvo> hey dholbach
[08:05] <pitti> dholbach: it looked like -runtime got split into several smaller libs or so
[08:05] <pitti> dholbach: I didn't really care
[08:05] <persia> It did.  Part of the continued effort to make mono take less space on the CD.
[08:06] <pitti> dholbach: (btw, that's not "held back", that's usual conflicts/replaces:)
[08:06] <dholbach> hum
[08:07] <directhex> it had better be! if it was held back i'd be sad
[08:08] <dholbach> ok, looks like gnome-do works again :)
[08:08] <Hobbsee> yay, gnome-do!
[08:09] <dholbach> gracias
[08:11]  * dupondje waiting for busybox to get fixed :P
[08:13] <hyperair> is anyone else besides me noticing update-manager-core having a newer version, but update-manager not?
[08:14]  * hyperair scratches his head
[08:14] <pitti> update-manager-core |    1:0.122 |        karmic | i386
[08:14] <pitti> update-manager-core |    1:0.123 |        karmic | amd64
[08:14] <pitti> update-manager |    1:0.122 |        karmic | all
[08:14] <pitti> I'd say that i386 FTBFSed
[08:16] <mvo> its waiting in binary NEW
[08:16] <mvo> well, auto-upgrade-tester is waiting there I would guess
[08:17] <dupondje> hyperair: same here indeed :p
[08:17] <StevenK> pitti: So, I suck, and didn't upload last night.
[08:17] <hyperair> ah i see
[08:18] <dupondje> https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/391299
[08:18] <dupondje> fixxor plz :)
[08:19] <pitti> ah, is that why I'm thrown into a busybox shell now?
[08:19] <pitti> (just ctrl-d'ing helps)
[08:20] <seb128> same here
[08:21] <dupondje> yep pitti
[08:21] <dupondje> I have a fixed version in my ppa
[08:22] <pitti> I'd wait for cjwatson to comment, though
[08:22] <dupondje> well the previous versions had a patch included
[08:22] <dupondje> custom
[08:22] <dupondje> to support sleep 0.1
[08:23] <dupondje> the newest version (used in karmic) has sleep for floats built in, so no more patch included. But its a configuration option that needs to be enabled. If its not enabled ofc, it will not work :P
[08:28] <dupondje> should be pushed into repo's imo :) nothing fancy changed ;)
[08:31] <pitti> dupondje: I expect cjwatson to turn up in about 30 minutes, I'll confirm with him and then upload
[08:31] <pitti> dupondje: thanks for your investigations!
[08:32] <directhex> anyway, yays @ mono 2.4 in karmic
[08:32] <directhex> should mean a little saving on the cd (possibly a couple of apps need to be rebuilt to pick up on lighter dep tree)
[08:32] <pitti> directhex: \o/ rock
[08:32] <directhex> and a <=25% drop in RAM consumption
[08:33] <directhex> pitti, when (not if, when!) the latest tomboy goes into Experimental & gets requestsynced, that gives you 5 meg
[08:33] <dupondje> pitti: np :) at least its working here again with the changes :)
[08:33] <pitti> directhex: wow! *hug*
[08:33]  * pitti sheds a tear
[08:34] <pitti> directhex: admittedly, _every_ upload has a <= 25% drop in RAM consumption :)
[08:34] <pitti> erm, at least almost all
[08:34] <directhex> pitti, it's thanks to a snippet of debian/rules wizardry which symlinks gnome doc images with matching md5sums, since stupid gnome help requires a full set of images for every translation (even though the images are usually dupes)
[08:35] <pitti> directhex: ah, we have that in cdbs for quite a whilw
[08:35] <pitti> I wasn't aware that tomboy didn't catch that
[08:35] <pitti> nice air to be squeezed out indeed
[08:36] <directhex> pitti, well, the theory is 25% drop in mono's runtime overhead in the new jitter - but real-world in apps, much of the memory consumption comes from the underlying gtk+ and mono's not to blame, so real-world gui apps will give less than 25%
[08:39] <hyperair> directhex: does 25% drop mean a 25% decrease in startup time then? =D
[08:40] <hyperair> oh RAM consumption only =(
[08:40] <directhex> hyperair, tomboy in karmic is <=50% faster to start up due to changes in the way it works with mono-addins
[08:40] <hyperair> cool
[08:40] <hyperair> but it doesn't help my incredibly long login time
[08:40] <hyperair> it takes longer to log in than to boot
[08:40] <hyperair> =(
[08:41] <hyperair> in fact, i think i can take a shit faster than it can log in
[08:41] <StevenK> !ohmy
[08:42]  * hyperair facepalms
[08:42] <hyperair> shit is now a swear word eh
[08:42] <directhex> i run no mono apps on login, and login is slow
[08:42] <directhex> hyperair, always has been
[08:43] <StevenK> hyperair: The image is ... not attractive, hm?
[08:43] <hyperair> fine. i take a shorter time to defecate than it takes for my notebook to log in
[08:43] <StevenK> That doesn't help!
[08:43] <Hobbsee> hyperair: dude...
[08:44] <Hobbsee> hyperair: besides, if you want a faster boot time, switch to metacity, adn don't use copiz
[08:44] <hyperair> i know, damnit.
[08:44] <directhex> or dump gnome and use twm
[08:44] <directhex> erm, wait, don't use the word "dump" there. um...
[08:44] <hyperair> but why can't we put some effort into speeding up the login process instead of the bootup process?
[08:44] <hyperair> it's so fast already!
[08:45]  * Hobbsee throws both hyperair and directhex into the gutter
[08:45] <Hobbsee> hyperair: who's to say that they aren't?
[08:45] <directhex> hyperair, such things ARE being worked on. there was a talk about it at UDS
[08:45] <hyperair> oh there was?
[08:45] <hyperair> it seemed that bootup time got more attention
[08:45] <StevenK> Boot time means BOTH
[08:46] <directhex> hyperair, the 10 second boot time being talked about for lurid lemur is grub->desktop not grub->login
[08:46] <pitti> hyperair: we will
[08:46] <hyperair> heh okay
[08:46] <hyperair> lurid lemur..
[08:46] <hyperair> nice name
[08:46] <pitti> hyperair: seb128 wants to work on nautilus, I'll look into speeding  up the panel
[08:46] <hyperair> cool =D
[08:46] <pitti> maybe robert_ancell and mvo can make the compiz startup faster, this is dreadful right now
[08:47] <directhex> the panel occasionally wants to delete half my widgets on login. i wish i knew why
[08:47] <pitti> those are the three main offenders, the rest is pretty negligible
[08:47] <hyperair> the applets crashed
[08:47] <hyperair> that's why
[08:47] <directhex> pitti, those specifically, or their deps? e.g. does gconf take time to behave?
[08:47] <mvo> we did ~30% faster startup last cycle :)
[08:47] <mvo> (with compiz)
[08:47] <pitti> directhex: those specifically; well, with panel you have bonobo and all the applets, which are deps in some way
[08:47] <hyperair> that's 30%?
[08:48] <seb128> mvo, still 70% to go ;-)
[08:48] <pitti> lol
[08:48]  * mvo hugs seb
[08:48] <pitti> yeah, must take zero time!
[08:48] <Hobbsee> agreed!
[08:48] <pitti> mvo: we so much need KCWM
[08:48] <directhex> seb128, sorry btw, my fault tomboy 0.15.1 is late. i went for beer with meebey on monday so he couldn't sponsor it
[08:48]  * hyperair read that compiz took a lot of time to just read configuration
[08:49] <seb128> directhex, this "waiting on debian" doesn't really make sense why don't we upload to ubuntu and sync when they wake up in some weeks?
[08:49] <seb128> it's blocked for debian for almost 2 weeks now
[08:49] <seb128> on debian
[08:50] <directhex> seb128, poke Laney about it - i think he's been using git in a sufficiently sensible way that it should be safe to do so
[08:51] <seb128> he tell me every day that it will be uiploaded to debian today
[08:51] <seb128> but apparently that's not happening
[08:51] <directhex> well, yes, there's a bottleneck there.
[08:52] <directhex> if only we had more than one DD in that team (http://lists.debian.org/debian-newmaint/2009/06/msg00037.html)
[08:53] <cjwatson> dupondje: ok, thanks, looking
[08:54] <cjwatson> pitti: I don't think the patch as attached is quite right so please don't sponsor it directly
[08:54] <pitti> cjwatson: good morning
[08:54] <pitti> cjwatson: right, I had a feeling it was better to wait for you :)
[08:54] <dupondje> cjwatson: did my best ;) it works here anyway ;)
[08:54] <pitti> cjwatson: like, you might not need it in the udeb, etc.
[08:55] <directhex> seb128, i think Laney is using pristine-tar so there shouldn't (!) be any problems with mismatched origs from a 0ubuntu1
[08:55] <cjwatson> exactly
[08:55] <pitti> dupondje: nothing to worry about; tracking it down was the hardest part here
[08:55] <cjwatson> definitely my fault though, I knew about the new config option and it obviously just slipped my mind
[08:56] <dupondje> quit the drugs :)
[08:56] <cjwatson> I don't think we need FANCY_SLEEP
[08:56] <dupondje> yep u need it
[08:56] <dupondje> FLOAT depends on it
[08:56] <cjwatson> oh, but yes you're right
[08:56] <dupondje> if u don't enable FANCY then FLOAT doesn't work
[08:56] <cjwatson> u => you please
[08:57] <pitti> cjwatson: so, that patch with static and udeb dropped?
[08:57] <cjwatson> anyway, I'm on it :)
[08:57] <pitti> okay
[08:57] <pitti> thanks
[08:57]  * directhex blames twitter for making txt spk fashionable again
[08:57] <cjwatson> I just want to think briefly about whether we actually do need it in the udeb
[08:59] <cjwatson> we didn't have FANCY_SLEEP turned on there before, but the prior patch didn't require FANCY_SLEEP for fractional sleep
[09:06] <cjwatson> uploaded, anyway
[09:09] <dupondje> cjwatson: your computer was to fast, so it didn't need to sleep :) Looks like some people fixed it by replacing UUID by /dev/sd* etc. Cause everything worked, but if it really needed to sleep a bit, it wasn't
[09:09] <cjwatson> probably
[09:09] <cjwatson> ah well, sorry about that anyway :-/
[09:10] <dupondje> bugs happen :)
[09:17] <maxb_> Ah, I just filed a bug about that sleep issue
[09:18] <maxb_> Anyway, on the trail of *another* bug, where does hal keep its device information these days? I need to find whatever rules it's applying for synaptics touchpads and apply them to another device name
[09:18] <cjwatson> maxb_: you already duped it?
[09:18] <maxb> I filed mine on initramfs-tools
[09:19] <cjwatson> ah, I'll dup it now
[09:20] <maxb> ok, I was just hunting scrollback for the number to dupe it to
[09:20] <MTecknology> pitti: you around?
[09:20] <pitti> MTecknology: hi
[09:21] <MTecknology> pitti: I have a question about a bug report
[09:21] <MTecknology> You think this is still valid? https://bugs.edge.launchpad.net/ubuntu/+source/swfdec-gnome/+bug/188150
[09:21] <cjwatson> maxb: oh, note that you'll need to run 'sudo update-initramfs -u' by hand after the upgrade
[09:21] <maxb> ah, thanks
[09:22] <cjwatson> busybox-initramfs is a dependency of initramfs-tools, so can't itself run update-initramfs ...
[09:22] <cjwatson> annoying, but there it is
[09:22]  * maxb scratches head on why for one boot only, synaptics device was called 'PS/2 Synaptics TouchPad' not 'SynPS/2 Synaptics TouchPad'
[09:22] <pitti> MTecknology: nobody followed up on it recently, so right now I don't consider it valid
[09:23] <MTecknology> pitti: care if I close it?
[09:24] <pitti> MTecknology: I'm fine with that
[09:25] <MTecknology> pitti: you think you have enough open bugs?
[09:25] <pitti> heh, yes :)
[09:26] <dupondje> what should I do when I find bugs of Ibex Beta ... mark as Invalid ? cause no need to keep them open ?
[09:27] <cjwatson> err, that depends on whether they are still bugs in karmic
[09:28] <cjwatson> bugs are not automatically invalid just because they were filed on intrepid!
[09:28] <cjwatson> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/ubuntu/2009-02-27-bug-triage-rants.html
[09:28] <dupondje> https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/278434 <- this for example :)
[09:29] <cjwatson> the correct procedure is to figure out what the problem was
[09:29] <cjwatson> if that problem is fixed, fix released
[09:29] <cjwatson> if that problem is not fixed, leave it open
[09:30] <cjwatson> I've reassigned that bug to linux, where it likely belongs
[09:30] <cjwatson> it should definitely not be summarily marked invalid
[09:31] <MTecknology> pitti: what is your job at canonical?
[09:31] <cjwatson> not without further investigation
[09:31] <dupondje> ok :)
[09:31] <pitti> MTecknology: see https://launchpad.net/~pitti
[09:34] <MTecknology> pitti: i just saw you're karma score too. It makes me feel like my 30k look like I don't do a single thing in lp :P
[09:34] <MTecknology> convert that to decent english in your head.. I must be tired
[09:34] <pitti> MTecknology: well, I do quite a lot, but admittedly most of my karma is a bug (see bug 373772)
[09:35] <MTecknology> wow
[09:36] <MTecknology> I thought soyuz was for packaging ppa
[09:36] <cjwatson> soyuz does the Ubuntu archive
[09:37] <MTecknology> I think I'd need to learn too much to understand all that
[09:38] <MTecknology> maybe
[09:38] <cjwatson> briefly, Soyuz is the component of Launchpad that accepts uploads, publishes them in archives, etc.
[09:39] <StevenK> pitti: If I upload this package now, can you review it soonish?
[09:39] <pitti> StevenK: yes, I can
[09:44] <StevenK> pitti: Uploaded, unr-meta. If you can put it into universe for the moment, I'll look at getting it thrown to main when all of its depends are.
[09:45] <cjwatson> TheMuso: was the 386 kernel flavour not meant to have been merged along with the rest of ports?
[09:47] <dupondje> Launchpad will be going offline for maintenance in 13 minutes.
[09:47] <dupondje> eeek :)
[09:48] <pitti> StevenK: not in the queue yet
[09:49] <StevenK> pitti: I just checked, I did at least target karmic
[09:50] <cjwatson> I do wish people would NEW kernel udebs properly :-/
[09:50] <cjwatson> and not just casually dump stuff into universe
[09:50] <pitti> cjwatson: hm, kernel-overrides should catch them, doesn't it?
[09:50] <cjwatson> only if they match a previously existing package
[09:51] <pitti> ah, so "real" NEW
[09:51] <pitti> StevenK: still not in the queue; did you get a reject mail?
[09:51] <cjwatson> you're supposed to check the results of kernel-overrides, not just go kernel-overrides; q accept :)
[09:51] <cjwatson> I've cleaned up the overrides now
[09:51] <StevenK> pitti: Lemme check
[09:56] <mvo> cjwatson: do you mind if I upload grub2 with the following patch http://paste.ubuntu.com/202725/ to support crashkernel= in it?
[09:56] <StevenK> pitti: Seems like I didn't get a mail about it at all
[10:01] <TheMuso> cjwatson: apw, rtg and I were discussing this the other day. I didn't merge 386 thinking there was a chance that Ubuntu would move to 586 only. There is also the issue of the 386 kernel possibly breaking kernel builds, since it has kernels that are supported. I await their decision as to whether it gets put back in for now.
[10:07] <cjwatson> mvo: spell "crashkernel" correctly in the patch name :)
[10:08] <robbiew> lol
[10:08] <cjwatson> mvo: um, it's OK for upload now, but that file is mainly maintained by upstream and we'd like to stay close to them. Could you please send it to grub-devel@gnu.org as well to discuss what a good upstreamable solution would be?
[10:09] <cjwatson> TheMuso: I was under the impression we were planning to *tune* for 586 (-mtune vs. -march), but could be misremembering
[10:09] <cjwatson> actually it's possible I am misremembering since 586 isn't a good tune target :)
[10:10] <mvo> cjwatson: *cough* sorry for the typo - I will fix that and send the patch to the devel list as well
[10:11] <cjwatson> mvo: (you might need to give grub-devel some background, of course ...)
[10:18] <mvo> cjwatson: thanks , I will add that info too
[10:54] <freinhard> hi!
[11:10] <ogra> cjwatson, do we have a udeb that sets up a serial console ?
[11:10] <cjwatson> does it need a separate udeb?
[11:10] <cjwatson> I thought rootskel did that if you followed the directions in the installation guide
[11:11] <ogra> well, we're just discussing a) debootstrapped systems  and b) the possible need to set up a serial console later in an installed system
[11:11] <cjwatson> debootstrapped systems get to configure some stuff themselves. I'm uninterested in "fixing" that
[11:11] <cjwatson> finish-install does serial console setup in that case
[11:11] <ogra> i'm in the camp that we should just have a serial-console package that has preseedable options for device speed etc
[11:12] <cjwatson> err, let me rephrase that. "now that I understand what you mean, finish-install is where the code lives"
[11:12] <ogra> and drops the /etc/event.d file in place
[11:12] <cjwatson> it really doesn't need a separate udeb
[11:12] <ogra> ok, well, i was hoping if there is a udeb we could just make an easy change to make the source spit out an additional deb :)
[11:13] <cjwatson> no point in it being preseedable, we just fish the options out of the serial console on which the installer is already presumptively running by means of stty
[11:13] <ogra> right, in case of the installer
[11:13] <cjwatson> sounds like overengineering. just tell people how to set it up; debootstrapped systems already require quite a bit of manual setup after debootstrapping.
[11:13] <ogra> in case of me using debootstrap inside qemu i wont have the actual device string the target HW will use
[11:13] <cjwatson> serial console is just one tiny piece of that.
[11:16] <ogra> well, my original prob is that plenty of people use my arm-rootfs-builder script ... i drown in requests from people not being able to set up the serial parts after rolling the rootfs.tgz ... i would like to add an option to my script ... and i dont want to addd anything self hacked but something we all benefit from :)
[11:16] <ogra> specifically i'D like to obsolete https://help.ubuntu.com/community/SerialConsoleHowto
[11:17] <freinhard> anyone else with broken wlan on karmic? http://paste.ubuntu.com/202401/
[11:21] <cjwatson> ogra: for the moment, I think you should just extend your script
[11:21] <ogra> ok ...
[11:21] <cjwatson> I don't see a purpose in creating a deb that solves just this one piece of the configure-after-debootstrap problem, and not the whole thing
[11:22] <ogra> indeed and the deb would only be a postinst dropping 7etc/event.d/serial (or some such) in place
[11:28] <lifeless> slangasek: getting there before d-d does; 'Why do you hate freedom?'
[11:32] <dupondje> python-xml is renamed to python-xmlbase in karmic ?
[11:35] <maxb> dupondje: I'd suggest you check the removal reason... but LP is down for maintenance.
[11:35] <maxb> But I'd guiess that python-xml is removed in karmic
[11:35] <dupondje> yea indeed, seems so
[11:35] <maxb> Yup, it's on the sync-blacklist
[11:36] <dupondje> its now for default in python or so ?
[11:37] <dupondje> damn launchpad :) when its down you realise you use it ALOT :)
[11:46] <StevenK> pitti: Is it there now? *whine*
[11:47] <pitti> StevenK: as you can check yourself with "q info unr", no :/
[11:47] <StevenK> pitti: Hmmm.
[11:47] <StevenK> :-(
[11:47] <pitti> perhaps because LP is read-only ATM?
[11:54] <StevenK> pitti: I uploaded it before that, but hopefully it hasn't disappeared
[12:01] <maxb> Could someone giveback dia/i386? Looks like some kind of weird transient problem (CHROOTWAIT / Resource temporarily unavailable) - https://launchpad.net/ubuntu/+source/dia/0.97-2/+build/1087621
[12:21] <StevenK> pitti: Just got the e-mail, please NEW it
[12:21] <pitti> StevenK: so apparently it was stuck by the LP rollout
[12:22] <pitti> StevenK: "Copyright 2004, Canonical Ltd." -- please fix in bzr
[12:23] <pitti> StevenK: also, debhelper 4 is deprecated, please use at least 5
[12:23] <pitti> (and S-V 3.8.2 while you are at it)
[12:23] <pitti> StevenK: accepted
[12:31] <cjwatson> maxb: done
[12:40] <StevenK> pitti: Thanks!
[12:44] <bigon> https://edge.launchpad.net/ubuntu/+source/empathy/2.27.3-1ubuntu1/+build/1091194 failed to upload
[12:44] <bigon> :/
[12:53] <cjwatson> bigon: no idea what happened there, but I've retried everything in the failed-to-upload state
[12:53] <cjwatson> if it happens again, let me know and we'll investigate
[12:53] <wgrant> cjwatson: It was demoted during the build.
[12:53] <wgrant> Known bug.
[12:54] <wgrant> Well, not during, but before a publisher.
[12:57] <cjwatson> ah
[12:58] <wgrant> So, due to the demotion plus the downtime, there were two non-superseded publishings, so it got confused.
[13:02] <bigon> mmm and why empathy has been demoted?
[13:03] <seb128> bigon, to get it to build I though the previous build failed because of universe build-depends
[13:03] <seb128> bigon, could have been wrong, I will promote it again once it has build
[13:05] <StevenK> seb128: Won't promoting it to main also rebuild it?
[13:05] <seb128> StevenK, no
[13:06] <seb128> why would a component change trigger a rebuild?
[13:06] <seb128> we don't have bin-nmu anyway
[13:15] <ScottK> pitti: I have an SRU question.  In amavisd-new, we have an issue in Jaunty where the secondary virus scanner function doesn't successfully call clamav.  Would that be SRU material do you think or should I just backport the new version from Karmic?  The fix itself is quite small.
[13:18] <Kano> hi, why is a ? in the console-setup/layoutcode?=xx option in karmic iso images?
[13:18] <Kano> when you check with: cat /proc/cmdline
[13:19] <Kano> that must be wrong
[13:20] <juanje1> Kano: hummm... it seems so to me...
[13:24] <cjwatson> Kano: no, it's correct
[13:25] <Kano> define correct
[13:25] <Kano> it is definitely not german when i boot it
[13:25] <cjwatson> Kano: ?= means "set value, but don't mark as seen"
[13:25] <cjwatson> if it isn't working, it's not because of the ?=
[13:26] <cjwatson> (see scripts/casper-bottom/24preseed)
[13:26] <cjwatson> (or indeed scripts/casper-bottom/19keyboard)
[13:29] <Kano> btw. you should set de-latin1-nodeadkeys for install-keymap
[13:29] <Kano> in case of german
[13:29] <cjwatson> no we shouldn't. That's for console-data which we haven't used since edgy.
[13:30] <Kano> and do you really think that karmic works correctly
[13:31] <cjwatson> I didn't say karmic worked correctly. I said that the ?= is not the problem.
[13:31] <cjwatson> nodeadkeys: I'm not going to change the default variant on the word of a single person - file a bug and get consensus from German users
[13:32] <cjwatson> since I don't use German layouts myself, it would be inappropriate for me to be deciding on what's best, and inappropriate to flip-flop in response to single bug reports
[13:33] <freinhard> Kano: please post the bug id, i'll vote for nodeadkeys ;)
[13:33] <cjwatson> I get a German layout in X when booting with the German layout
[13:33] <cjwatson> it's just the console that's broken
[13:34] <cjwatson> and I think it's broken for everyone, not just German
[13:34] <cjwatson> it'll be some horrible initramfsy thing
[13:34] <ogra> beyond that there was a vote on the forums and german mailing list to keep deadkeys
[13:35] <kenvandine_wk> cjwatson, is there a work around?
[13:35] <ogra> we touched that topic end of jaunty/start of karmic
[13:35] <cjwatson> kenvandine_wk: for broken console? run 'sudo setupcon' after boot
[13:35] <kenvandine_wk> ok
[13:36] <Kano> cjwatson: and you like brokin console,do you
[13:37] <cjwatson> Kano: huh? of course I don't
[13:37] <cjwatson> Kano: if you're just going to abuse me, please go away
[13:37] <cjwatson> it's clearly a bug at present
[13:39] <cjwatson> and in fact I noticed it myself on my normal system with a UK layout earlier today, but hadn't got round to doing anything about it yet
[13:39] <Kano> fine
[13:39] <Kano> will check it next week again
[13:40] <ogra> ah, damned, he's gone ... http://forum.ubuntuusers.de/topic/welches-deutsche-tastaturlayout-benutzt-du/ ...
[13:43] <ogra> freinhard, you missed the vote :)
[13:44] <freinhard> that vote asks the wrong question! shouldn't be "which keyboard layout do you use" but rather "which keyboard layout should be default"
[13:45] <ogra> well, the according mail i wrote made the issue pretty clear, i admit the poll question isnt perfect :)
[13:45] <freinhard> i use deadkeys as well, but that's because i'm to lazy to change it
[13:47] <ogra> i hate deatkeys and switch it during install ... but the thread and forum discussion brought up way to valid reasons to keep deadkeys as default
[13:47] <ogra> so it wont be switched
[13:48] <ogra> https://lists.ubuntu.com/archives/ubuntu-de/2009-April/016569.html is the thread
[13:51] <bigon> seb128: so you've planned to put empathy back to main?
[13:51] <seb128> yes, why not?
[13:51] <seb128> I just wanted to get the new version to build and I though the issue was universe requirements
[13:52] <pgraner> asac: what the plan for ff 3.5 for Karmic, still a ppa or will it become the default?
[13:52] <bigon> ok no problem do you know if some ppl have asked a mir for the needed packages?
[13:53] <seb128> issues are being worked yes
[13:54] <kenvandine> seb128, btw... fedora has a patch that moves the gst plugins empathy needs to -good
[13:54] <asac> pgraner: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-firefox-3.5
[13:54] <kenvandine> so that is their fix
[13:54] <seb128> cool
[13:54] <kenvandine> doesn't mean upstream agrees yet
[13:54] <kenvandine> but maybe we should follow suit
[13:54] <pgraner> asac: show off.... I must have missed it... I even looked... *sigh*
[13:54] <asac> pgraner: its in universe
[13:54] <asac> pgraner: go ahead and start using it ;)
[13:54] <asac> (its just not yet officially branded)
[13:55] <asac> pgraner: apt-get install firefox-3.5 :)
[13:55] <pgraner> asac: I have been for months now from your ppa
[13:55] <pgraner> asac: thats why I was asking
[13:55] <asac> pgraner: ah ok. so yeah. things are moving; its quite a lot of work though ;)
[13:56] <bigon> seb128: don't forget to put geoloc stuff (libchamplain and geoclue) in main too :)
[13:57] <seb128> we are not likely to use those by default
[14:00] <pgraner> asac: I use the weave extension and it only works with that version...
[14:00] <pgraner> asac: thanks for the info
[14:00] <robbiew> pgraner: I didn't know you wore a weave extension :P
[14:00] <pgraner> robbiew: trying to keep hip and all :-/
[14:03] <pitti> ScottK: is it a regression from intrepid?
[14:03] <pitti> ScottK: OTOH it almost sounds like a -security issue, is it?
[14:27] <mvo> hm, could someone please check/binary-NEW auto-upgrade-tester from my latest update-manager upoad?
[14:28] <mdz> cjwatson: Keybuk: do you recall  which TB meeting it was where we outlined the patent policy?  I have an overdue action to write it up
[14:29] <Keybuk> mdz: off hand, about three
[14:29] <Keybuk> Jono's drafts were Apr 07 and Apr 15
[14:29] <Keybuk> in which he said "a few weeks back"
[14:29] <Keybuk> so Mar-Apr sometime ;)
[14:29] <mdz> Keybuk: I'm looking for the one where Mark turned up
[14:29] <Keybuk> Feb 18 minutes say "assigned to Jono"
[14:30] <mdz> Keybuk: hmm, that's right, it's coming back to me now
[14:32] <Keybuk> it appeared on the agenda from about Jan 4 through to March by the looks it
[14:33] <mdz> and then jono wrote something up, and emailed asking for feedback
[14:33] <mdz> and then I lost the plot
[14:34] <cjwatson> mdz: the TB meeting action gives the date
[14:34] <cjwatson> 15:19 <cjwatson> [ACTION] mdz to write up patent policy minutes from 2009-03-24 meeting
[14:34] <Keybuk> I used Jono's draft text for the position statement
[14:34] <cjwatson> http://irclogs.ubuntu.com/2009/03/24/%23ubuntu-meeting.html
[14:34] <mdz> cjwatson: was that before or after jono was involved?
[14:34] <Keybuk> after
[14:34] <mdz> so I have the ball
[14:34] <cjwatson> the meeting log suggests it was after
[14:35] <mdz> but I'm not sure what I need to do
[14:35] <mdz> I'm about to just copy Jono's draft to the tb list and add my commentary
[14:35] <cjwatson> what I intended by that action was simply a write-up of the discussion in that meeting
[14:35] <Keybuk> that seems like a good idea
[14:35] <cjwatson> but if there's already a draft policy to amend with it, all the better
[14:40] <mdz> cjwatson: Keybuk: sent to t-b@
[14:40] <cjwatson> ta
[14:47] <StevenK> pitti:   * Removed udev-extras from standard
[14:47] <StevenK> pitti: From a germinate on ubuntu.karmic ...
[14:47] <pitti> StevenK: that depends on Keybuk uploading udev 143
[14:47] <superm1> StevenK, all of udev-extras got pulled into udev for udev 143
[14:48] <pitti> don't upload that yet, please
[14:48] <ScottK> pitti: It's a regression in that clamav changed (we have 0.95 in Jaunty) and the new clamav works slightly differently.  I think it's not security since it's a functional failure, not any kind of access issue.
[14:48] <StevenK> pitti: Right, I'll wait until my tomorrow.
[14:48] <pitti> ScottK: I meant in the sense of "bypassing viruses to the scanner"?
[14:48] <pitti> ScottK: anyway, if that worked in intrepid, fine to SRU
[14:49] <ScottK> pitti: OK.  Thanks.
[14:49] <superm1> pitti, do you think you'll get some time this week to look at the jockey-text frontend I proposed?
[14:49] <ScottK> pitti: With the clamav stuff if I really look at it hard almost everything could be a security issue.  It's hard to know.
[15:15] <pitti> superm1: sorry, that seems to have slipped my attention?
[15:18] <seb128> hum
[15:18] <seb128> james_w, is that normal that I get emails about code imports failing?
[15:18] <james_w> seb128: shouldn't get them from me
[15:18] <james_w> seb128: forward me the email and I'll take a look
[15:19] <seb128> james_w, those are not from you, I just figured you might know ;-)
[15:19] <james_w> heh
[15:20] <seb128> "Subject: Code import gvfs/trunk status: Failed
[15:20] <seb128> Hello,
[15:20] <seb128> The import has been marked as failing.
[15:20] <seb128> https://code.launchpad.net/~vcs-imports/gvfs/trunk
[15:20] <seb128> You are receiving this email as you are subscribed to the branch."
[15:20] <seb128> basically
[15:20] <seb128> same for nautilus and gnome-control-center
[15:21] <seb128> I guess that's rather a launchpad question than a bzr one
[15:21] <cjwatson> well, you *are* subscribed to the branch
[15:22] <cjwatson> I assume https://code.launchpad.net/~vcs-imports/gvfs/trunk will let you unsubscribe
[15:22] <seb128> cjwatson, I was rather wondering about the failure than the email ;-)
[15:22] <cjwatson> it seems to be having trouble due to (perhaps?) a git rebase
[15:23] <cjwatson> but yes, it's a launchpad-bazaar question
[15:23] <seb128> yeah sorry I first though that was due to the packages import in bzr
[15:23] <seb128> I pinged too quickly
[15:23] <ttx> cjwatson: thx for sponsoring the ecj thing. I'll file a bug with update-maintainer, it doesn't comply with new DebianMaintainerField.
[15:23] <seb128> cjwatson, james_w: thanks
[15:24] <james_w> seb128: no problem, just glad it wasn't me for once :-)
[15:24] <cjwatson> ttx: don't bother, I'll fix it in bzr now. I thought it was fixed already but apparently now
[15:24] <cjwatson> not
[15:25] <ttx> cjwatson: ok
[15:26] <cjwatson> ttx: uh ... I do apologise. I misremembered what DebianMaintainerField said ...
[15:26] <cjwatson> I'll fix it properly this time. The e-mail address was fine but the name was wrong (and the latter is fixed in bzr)
[15:28] <ttx> cjwatson: heh :)
[15:29] <ttx> cjwatson: about the other part of that GCJ email, would you find the "any" trick still valid if it covers 7-10 packages ?
[15:30] <ttx> cjwatson: the overhead will be more significant but I'm not sure we can find a better solution in the karmic timeframe
[15:31] <amitk> Keybuk: how does one update the readahead list on an upgraded system (jaunty->karmic)?
[15:32] <Keybuk> amitk: boot with "profile" on the kernel command line
[15:33] <amitk> nice... and easy
[15:33] <Keybuk> it's easier with sreadahead
[15:33] <Keybuk> it just does it itself once a month ;)
[15:36] <dholbach> a bunch of packages have ubuntu-devel@lists.ubuntu.com as their maintainer address and the list gets lots of archive@ubuntu.com mails due to that
[15:36] <dholbach> can you please use ubuntu-devel-discuss@lists.ubuntu.com (what 'update-maintainer' from the ubuntu-dev-tools package will do for you)?
[15:36] <amitk> Keybuk: is sreadahead a drop-in replacement for readahead?
[15:37] <Keybuk> on SSD, yes
[15:37] <Keybuk> though use the one from the ubuntu-boot PPA, since that doesn't uninstall ubuntu-desktop <g>
[15:38] <amitk> so it is not recommended on platters?
[15:38] <Keybuk> it'll be quite pessimal on platters
[15:38] <amitk> or its benefits are only seen on SSDs
[15:38] <amitk> ?
[15:46] <superm1> pitti, ah i had thought it might have (last time i sent a merge request on jockey it got lost in filters for a while too) : https://code.edge.launchpad.net/~superm1/jockey/jockey-text/+merge/7781
[15:58] <cjwatson> ttx: I'm not that bothered ...
[16:10] <cjwatson> StevenK: are you guys planning to merge libhildon? it should not be my merge
[16:13] <ogra> cjwatson, i doubt we care in the mobile team, there is a new MID community team that casers for moving MID to mer ... (yay for confusing abbreviations)
[16:14] <ogra> *cares
[16:14] <ogra> YokoZar1, ^^^ do you guys need libhildon ?
[17:26] <JohnTeddy> yahoo broke for all pidgin users of Jaunty's version of pidgin. the problem/solution is located here: http://theflamingbanker.blogspot.com/2009/06/some-clarification-on-yahoo-issues.html ... I updated my pidgin and it works. I think this should go into jaunty repositories. this is an fyi if anyone cares.
[17:27] <YokoZar1> persia: ^^ ~ ogra
[17:29] <JohnTeddy> This is for 2.5.5 update to 2.5.7, not many changes except mostly yahoo authentication stuff to fix yahoo. binaries located here: http://pidgin.im/download/ubuntu/
[17:55] <kees> is anyone available to test bug 336554 in -proposed and comment on the bug?  I'd do it, but I was the fixer.  :)
[17:58] <mac9416> Can someone point me to some documentation explaining how apt-get dist-upgrade works?
[17:59] <ScottK> mac9416: Did you already read man apt-get?
[17:59] <mac9416> ScottK, unfortunately, I'm on a Windoze machine ATM.
[18:00] <cjwatson> mac9416: manpages.ubuntu.com
[18:00] <YokoZar1> If foo-1 and foo-2 both Provides: foo and Conflicts: foo, will installing foo-2 uninstall foo-1?
[18:00] <cjwatson> type 'apt-get' into the search box, hit "Title"
[18:01] <cjwatson> YokoZar1: you might need a Replaces: as well, possibly, but yes
[18:01] <YokoZar1> cjwatson: thanks
[18:01] <YokoZar1> cjwatson: you mean Replaces: foo I assume
[18:02] <cjwatson> yes
[18:02] <cjwatson> YokoZar1: lots of packages use this pattern with mail-transport-agent
[18:02] <YokoZar1> Thanks, that's exactly what I want then
[18:14] <cjwatson> lool: I don't suppose you could merge cairo? I don't really know what I'm doing there, but am TIL due to a no-change rebuild
[18:14] <cjwatson> fta: or you maybe?
[18:25] <lool> cjwatson: TIL?
[18:28] <kirkland> james_w: around?
[18:29] <cjwatson> lool: touched it last
[18:29] <lool> I'm looking into it
[18:30] <cjwatson> thanks
[18:32] <james_w> kirkland: hey
[18:32] <kirkland> james_w: hey, i've been struggling for several weeks now with vcs-imports
[18:32] <james_w> of git?
[18:33] <kirkland> james_w: i'm giving up on LP for the moment and trying to get it working locally, and i'll just cronjob an import/push until LP gets straightened out
[18:33] <kirkland> james_w: yes
[18:33] <kirkland> james_w: i'm trying to chase down all the bzr, plugins, dulwich, and such necessary to get this to work
[18:33] <kirkland> james_w: i'm simply trying to: bzr branch git://git.savannah.nongnu.org/qemu.git
[18:34] <kirkland> james_w: or bzr git-import git://git.savannah.nongnu.org/qemu.git
[18:34] <kirkland> james_w: at this point, i think i'm stuck with a version of dulwich that is too old
[18:34] <kirkland> james_w: i installed from https://edge.launchpad.net/~dulwich/+archive/ppa
[18:35] <kirkland> james_w: bzr: ERROR: exceptions.ImportError: bzr-git: Dulwich is too old; at least 0.3.1 is required
[18:36] <cjwatson> I used to have that kind of problem, but my problems went away upon upgrading to karmic
[18:36] <james_w> I guess you have to install from lp:dulwich
[18:36] <kirkland> cjwatson: is that directed at me, or lool?
[18:36] <cjwatson> you
[18:36] <kirkland> james_w: where do i install that to?
[18:36] <james_w> setup.py install should do it
[18:37] <james_w> or just grab the branch and use PYTHONPATH
[18:37] <kirkland> james_w: okay, i'll try that
[18:38] <kirkland> james_w: cool, thanks, that gets me a bit further
[19:02] <genii> Hello. Is there some place .deb pre/postinst pre/postrm scripts get cached and used other than perhaps /var/lib/dpkg/info/packagename.scriptname  ? I had an error in the postrm, manually fixed it there (/var/lib...postrm) which allowed removal. But then after install of the new package with the fix, it seems to be using the old version for some reason.
[19:03] <cjwatson> no, only /var/lib/dpkg/info
[19:04] <cjwatson> of course if you installed a new version then dpkg will likely have overwritten that
[19:04] <genii> Weird.
[19:05] <genii> cjwatson: I required an -f on an update-rc.d line... made the fix (on another box), rebuilt the deb, scp'd it over and installed... then the postrm somehow reverts to the previous one in /var/lib even after a rm'd it. Maybe scp is caching??
[19:11] <cjwatson> genii: scp doesn't cache
[19:11] <cjwatson> I think you almost certainly just made a mistake somewhere
[19:14] <YokoZar1> pitti: ~ Karmic Wine Integration: were you referring to slower startup by starting clamd at login or slower startup by starting clamd upon opening executable-handler?  clamd takes about 5 seconds to start, but it takes very little memory to leave running and can be started in parallel (eg at login).
[19:18] <ScottK> Virtually all of the time is spent reading in virus definitions, so the time wil be related to HD speed.
[19:18] <ScottK>  ... and how much else is going on at the same time.
[19:20] <YokoZar1> ScottK: would making it a low priority task that ran at login be reasonable?
[19:20] <ScottK> YokoZar1: I don't know enough about the boot process to know, but since it's reading from the HD the entire time it'll slow other stuff down if one is IO bound.
[19:21] <YokoZar1> ScottK: also is there a way to tell if clamd is starting up but isn't yet started yet?  We could have it run as the very last thing after the user logs in, and then if they happen to open an executable in the first 5 seconds the script could just wait till it's started
[19:21] <ScottK> YokoZar1: I think if you call it while it's reading in the signatures it'll just block until it's finished.  I'd test this.
[19:23] <YokoZar1> ScottK: hmm that sounds like exactly what we want
[19:23] <ScottK> YokoZar1: Yes, but as I said, I'd test it and make sure.
[19:24] <genii> cjwatson: Weird. When I have the deb on box1, open and examine the postinst there, is correct. On box2 after I scp it over, timestamp is same as original but extracting the postinst shows it is the previous one.
[19:25] <pochu> pitti: hi! pkg-create-dbgsym's dh_strip is missing "-k" for the "--keep-debug" option handling
[19:25] <pochu> pitti: that is, it should be "-k|--keep-debug)"
[19:27] <pochu> pitti: oh, there's a bzr branch... I'll create my own and request a merge if I have further changes :-)
[19:27] <pochu> pitti: just started looking at the ddebs project
[19:30] <pochu> pitti: same for --exclude= and -X
[19:30] <pochu> pitti: I'll look at creating a branch and requesting a merge ;)
[19:34] <genii> OK, found the issue. box1 deb is on an NFS mount which hadn't synced
[20:09] <pochu> huh, are there still packages with debhelper compat 1?
[20:27] <chrisccoulson> mdke - is there a reason that ubuntu-docs no longer ships a /usr/share/omf/about-ubuntu/about-ubuntu-C.omf file anymore in karmic, or is that a mistake?
[20:29] <chrisccoulson> cjwatson - just looking at your gnome-session issue. do you see the same issue with the dialog flicker if you logout instead of rebooting?
[20:42] <ebroder> Any SRU-types around? I have a few bugs that I've been trying to get someone to look at for a few weeks now
[20:46]  * beuno nudges cody-somerville and runs away
[20:52] <slangasek> lifeless: I hate freedom because it makes people lazy and stupid, of course :)
[21:03] <ScottK> slangasek: Would you mind having a look at kubuntu-meta in binary New?  I'm working on getting ready for kubuntu-netbook images early.
[21:12] <nixternal> pitti: just used ubuntu-bug from the command line for the first time, I think I like it better than the GUI :)
[21:24] <slangasek> ScottK: I'm traveling today, don't really have the bandwidth to look at that currently
[21:24] <ScottK> slangasek: OK.  Thanks for lettting me know.
[21:25]  * ScottK shops for archive admins ....
[21:25] <ScottK> jdstrand: Could you  have a look at kubuntu-meta for binary New?
[21:27]  * ScottK notices the time and runs off ....
[21:27] <jdstrand> ScottK: sure
[21:28] <ScottK> jdstrand: Thanks.
[21:33] <jdstrand> ScottK: I'm going to accept it, but kubuntu-netbook doesn't seem to do anything...
[21:36] <Sarvatt> speaking of metapackages, someone was having a problem with netbook remix not pulling in udev-extras (ubuntu-standard?) so they werent getting permissions set right for dri in karmic
[21:38] <Sarvatt> https://bugs.launchpad.net/bugs/384934
[22:01] <ebroder> Is anyone from motu-sru around?
[22:37] <micahg> will there be another round of importing before the freeze tomorrow or do I need to file a requiest at this point?
[22:40] <ripps> Hey, can anybody here give me some help, I'm trying to help Qball, the developer for gmpc, to fix his libnotify plugin to properly display album images in his libnotify plugin.
[22:41] <kirkland> hrm
[22:42] <kirkland> up-to-date karmic
[22:42] <kirkland> gdm login, then kicks me out immediately
[22:42] <kirkland> known issue?
[22:44] <maxb> kirkland: Intel graphics?
[22:45] <maxb> try rolling back the latest mesa update
[22:45] <bryce> kirkland, I've got a fix in my ppa -  mesa - 7.4.1-1ubuntu4
[22:45] <Chipzz> ripps: pls read the topic
[22:46] <bryce> kirkland, once it's finished building and someone can verify, I'll be uploading
[22:48] <kirkland> bryce: thanks
[22:48] <kirkland> maxb: yes, intel
[22:49] <bryce> kirkland, people were complaining about how boringly stable X.org had been so far in karmic
[22:49] <kirkland> bryce: great, thanks for shaking it up some
[22:49] <kirkland> sheesh
[22:49] <bryce> hehe
[22:49] <mathiaz> kees: jdstrand: is it know that apparmor init script fails to reload properly in karmic?
[22:49] <mathiaz> *known*
[22:50] <jdstrand> mathiaz: yes-- apparmor hasn't been forward ported to the karmic kernel yet
[22:50] <kirkland> bryce: ping me if you notice it's done building and i'll test for you
[22:50] <kirkland> on an unrelated note...
[22:50] <mathiaz> jdstrand: ok - should I file a bug for it?
[22:50] <kirkland> karmic seems to be running *very* hot on my thinkpad
[22:50] <dtchen> existing bug, mathiaz
[22:51] <kirkland> 60+ degrees hotter
[22:51] <ajmitch> bryce: are the nvidia 185.x drivers in the PPA liable to make my system crash & burn then, since X.org is so boring? :)
[22:51] <jdstrand> mathiaz: no, it is well known: bug #375422
[22:51] <dtchen> mathiaz: 375422
[22:52] <jdstrand> it is being actively worked on
[22:52] <bryce> ajmitch, sadly no, they should be mind numbingly boring.  We believe they actually make some well loved bugs go away.
[22:53] <ajmitch> I noticed that the package name was still referring to 180, so wasn't sure if it was wise to upgrade
[22:54] <bryce> ajmitch, should be fine.  I'm not sure if we're going to s/180/185/ for consistency; need to chat with tseliot about that
[22:54] <bryce> ajmitch, I'm just waiting on some positive user testing cases and will upload
[22:56] <ajmitch> bryce: alright, I'll try it out
[22:57] <NCommander> Is there a good trick to getting USB modules available in the initramfs?
[22:58] <NCommander> I'm trying to do some debugging in it on ia64, and I find my keyboard is useless there :-/
[22:59] <bryce> kirkland, amd64 and lpia builds ready.  i386 still in progress.  https://edge.launchpad.net/~bryceharrington/+archive/ppa
[23:03] <ScottK> jdstrand: I think that's inevitable the first time through since it's recurseive.
[23:04]  * ScottK prepared to find out I'm wrong.
[23:04] <dtchen> NCommander: /etc/initramfs-tools/modules
[23:04] <dtchen> NCommander: regenerate (update) the initramfs afterward
[23:05] <ebroder> Any motu-sru types around to look at a few bugs? I've had a few waiting for motu-sru review for a few weeks now
[23:05] <NCommander> dtchen, now, you won't happen to know what voodoo is needed to get /dev/fb0 working on ia64 now would you ;-)?
[23:06] <dtchen> NCommander: not offhand, no
[23:08] <maco> ebroder, i think there are only 3 people on the motu-sru team, so that could be why
[23:08] <maco> dtchen, that team you were supposed to start...did ya?
[23:09] <dtchen> maco: no
[23:09] <ebroder> maco: Sounds like they should expand the team, not let bugs fester for weeks/months at a time
[23:09] <dtchen> it's fairly ineffective without seeding the group with people who actually have upload privileges
[23:09] <NCommander> ebroder, maco there's been two open slots for ages
[23:10] <ebroder> I'm kind of frustrated at the moment because I've been practically unable to get anybody to touch my bugs for both SRUs or just normal sponsorship for the last 2 months or so
[23:11] <maco> NCommander, oh, so we need to convince a random motu to go apply for it?
[23:11] <dtchen> ebroder: yes, i know well the feeling. that's the idea behind the "ubuntu-reviewers" (name not set) LP team.
[23:11] <maco> ah! that's the channel missing from my buffer list
[23:11] <maco> (must find a better name than "buffer" for that in quassel. suggestions?)
[23:11] <RAOF> Channel?
[23:12] <maco> motu
[23:12] <RAOF> I meant: maybe "channel" is a better name than "buffer" :)
[23:12] <maco> oh :P well they use it for PMs too
[23:15] <Fenix|work> Greetings...
[23:15] <Fenix|work> TheMuso, Would you happen to be around?
[23:17]  * maxb  installs bryce's mesa
[23:18] <Fenix|work> Does anyone have TheMuso's email address?
[23:19] <maco> Fenix|work, i'd guess he'd be on in about 12 hours
[23:19] <maco> thats when i usually see folk from his area on IRC
[23:19] <DktrKranz> Fenix|work, look at ~themuso on LP
[23:20] <Fenix|work> yeah, I just thought of that... themuso@ubuntu.com
[23:20] <ajmitch> maco: closer to 2 hours, it's just past 8am there
[23:20] <bryce> maxb, possibly there is still one crash (which there is also a patch for, just not enabled in the ppa build yet)
[23:21] <maco> ajmitch, oh yeah, im still not accustomed to this "awake before noon" idea ;)
[23:21] <dtchen> bryce: 185.18.14-0ubuntu1~xup~1 WFM on C67/GeForce 7150M
[23:21] <maco> (slightly kidding...i get up before dawn...which i contend is still night)
[23:22] <ajmitch> maco: it's a hard life...
[23:22] <bryce> dtchen, thanks
[23:23] <maxb> bryce: It's working fine for me. I can't crash it by doing what I could reliably crash 1ubuntu3 by doing
[23:25] <Fenix|work> Just sent him an email.  We'll see if I get a response. :)
[23:25] <Fenix|work> Thanks all.  Have a good night.
[23:26] <bryce> maxb, aha excellent
[23:28] <kirkland> bryce: installing
[23:29] <cjwatson> chrisccoulson: I didn't see one with m.Logout(dbus.UInt32(2))
[23:30] <chrisccoulson> cjwatson - hmmm, that is strange, as it activates the same code path i think. i'll try and recreate this tomorrow when i get the chance
[23:30] <chrisccoulson> the other thing that can cause the inhibit dialog to appear is a client not responding to the QueryEndSession fast enough
[23:31] <cjwatson> chrisccoulson: should be pretty easy to recreate with the python snippet I posted and a karmic desktop cd
[23:31] <kirkland> bryce: fixed
[23:32] <cjwatson> unless I'm totally on crack of course :)
[23:32] <bryce> kirkland, sweet, thanks.  Upload coming
[23:32] <cjwatson> chrisccoulson: (and thanks for looking at it)
[23:32] <chrisccoulson> cjwatson - i'll have another look at it tomorrow when i finish work
[23:33] <cjwatson> it's not especially urgent, just seems likely to be a bit ugly at the end of installations
[23:33] <cjwatson> although even with the ugliness it's well worth killing off the old code
[23:34] <cjwatson>  23 files changed, 5119 insertions(+), 16381 deletions(-)
[23:41] <maco> why does http://package-import.ubuntu.com/ not include karmic packages yet?
[23:49] <james_w> maco: we are transferring over to LP, and trying to keep two imports going at the same time was too much
[23:50] <maco> oh
[23:50] <james_w> sorry if that confused you
[23:50] <maco> james_w, is nothing going into import or is it that stuff-on-lp isnt in import?
[23:51] <james_w> stuff-on-lp is new branches
[23:51] <james_w> which will include Debian as well, so they don't share revision history
[23:51] <james_w> so it wasn't just a case of pushing to two places
[23:54] <mathiaz> james_w: what's the state of the branches actually?
[23:54] <james_w> the LP ones are starting to appear
[23:55] <mathiaz> james_w: where can I find them?
[23:55] <james_w> we've got what is apparently an LP problem to try and diagnose, but we're pretty much at the point where it's just a case of churning through the packages to import them
[23:55] <james_w> https://code.launchpad.net/~ubuntu-branches houses them all
[23:56] <james_w> you can also get to branches from a package from https://code.launchpad.net/<distro>/<distroseries>/+source/<sourcepackagename>
[23:56] <james_w> the other overview pages are coming
[23:57] <redvamp128> Okay developers- I have a rather strange issue that involves enlightenment(opengeu) and gnome- I have looked for a room on this and there is none (this is a default 8.04 install)
[23:58] <redvamp128> I can sign into the window manger just fine-- and then sign back into my gnome-- and it put shortcuts to drives on my default desktop
[23:59] <redvamp128> It uses thunar-- but why does it not do that when I use the XFCE but does that with that D-E (window manger) any clues?