[00:01] <StevenK> slangasek: Is it a bunch of rebuilds?
[00:02] <slangasek> I don't think so
[00:02] <slangasek> bug #260918
[00:03]  * StevenK waits for LP
[00:08]  * ogra sighs
[00:09] <ogra> lpia-lrm ftbfs'ed
[00:09]  * ogra decides to leave that to amit
[00:14] <cjwatson> ogra: it did? where?
[00:14] <cjwatson> I only see the one for the old ABI
[00:14] <ogra> The following packages have unmet dependencies:
[00:14] <ogra>   linux-headers-2.6.27-4-lpia: Depends: linux-headers-2.6.27-4 but it is not installable
[00:14] <ogra>   linux-headers-2.6.27-4-lpiacompat: Depends: linux-headers-2.6.27-4 but it is not installable
[00:14] <ogra> E: Broken packages
[00:14] <ogra> lpia-linux-restricted-modules_2.6.27-4.4
[00:14] <cjwatson> oopsie
[00:14] <cjwatson> well that isn't going to work :)
[00:14] <ogra> apparently
[00:15] <slangasek> hee
[00:15] <cjwatson> the perils of excessive kernel source package splitting
[00:15] <slangasek> so much for "getting rid of the ABI checks"
[00:15] <ogra> but i spent a night on the broken linux-lpia this week already with getting nowhere
[00:15] <cjwatson> you don't get to use common stuff any more, at least not easily ...
[00:15] <ogra> so i'll leave it to amit to fix it
[00:15] <cjwatson> all this split source package stuff is a confusing mess
[00:16] <cjwatson> slangasek: speaking of lpia, could you accept d-i?
[00:16] <ogra> slangasek, dont say abi checks ... that costed me a night to just find out even my ignore files get ignored
[00:16] <slangasek> cjwatson: already did, unless you've uploaded another in the past 30m
[00:17] <StevenK> ogra: So, slangasek said you're the person to talk to about libflashsupport?
[00:17] <slangasek> I did?
[00:17] <StevenK> Blah. Someone did.
[00:17] <ogra> it should die die DIE !
[00:17]  * ogra looks for a shotgun
[00:18]  * ogra realizes he isnt american and thus doesnt own something like that 
[00:18] <crimsun> (err?  who/what needs libflashsupport still?)
[00:18] <StevenK> I'll take that as I shouldn't fix it to use libgnutls26 and should purge it from the archive.
[00:18] <slangasek> crimsun: we don't know; if it's supposed to go away, this hasn't been communicated effectively to ubuntu-archive
[00:18] <ogra> crimsun, its just idling in the archive
[00:18] <StevenK> Someone file a removal bug and I'll get killed.
[00:18] <ogra> slangasek, i pinged here several times but always during busy times
[00:18] <StevenK> Errrr. s/I'll/it'll/
[00:19] <ogra> so that likely got lost ...
[00:19] <StevenK> ogra: Right, so file a bug.
[00:19] <slangasek> ogra: well, pinging here is not the right way to go about requesting package removals anyway, there's no review or accountability
[00:19] <StevenK> Bugs assigned to -archive tend not to get lost.
[00:19] <StevenK> Er, subscribed
[00:19]  * StevenK gives up on this whole IRC thing and goes to inject a bunch of caffeine
[00:19] <ogra> StevenK, really, i just came here to quickly upload the kernel for amit after a 14h day, now i'm stuck in conversations for 2h already again
[00:19] <crimsun> bug 267749
[00:20] <crimsun> just to note, libflashsupport is gone from ia32-libs thanks to \sh
[00:20] <ogra> if you want to remove it, just wipe it ... else i'll file a bug tomorrow
[00:20] <ogra> s/kernel/lrm/
[00:20] <cjwatson> slangasek: oh, I lose
[00:20] <cjwatson> ok
[00:20] <kwwii> libflashsupport should be killed
[00:20] <cjwatson> that's what I get for failing to catch up on -release
[00:21] <StevenK> kwwii, crimsun, ogra: Then one of you file a bug asking for removal. :-)
[00:21] <crimsun> StevenK: I've just pointed to the one I'm going to modify
[00:21] <StevenK> crimsun: Fair enough
[00:21] <slangasek> cjwatson: no worries :)
[00:21] <crimsun> ogra: your LTSP use cases are fine with libasound2-plugins in intrepid, correct?
[00:22] <crimsun> (I've asked before, but it doesn't hurt to ask again)
[00:22] <ogra> crimsun, i hope so
[00:22] <ogra> i didnt have the time to test ltsp on real HW this cycle
[00:23] <kwwii> is there any info on how to create a sponsoring bug?
[00:23] <ogra> well, tats not true, but all testing until mid cycle i did had to be for hardy
[00:23] <StevenK> kwwii: Attach debdiff with rationale, and subscribe ubuntu-{main,universe}-sponsors
[00:23] <ogra> for intrepid i didnt have the opportunity
[00:24] <kwwii> I have a new human-icon-theme package which fixes a bug in the fusa applet stuff and have anew package
[00:24] <kwwii> erm, debdiff...something new to me
[00:24] <ogra> crimsun, let it go, worst case i'll revive it in a PPA
[00:24] <kwwii> StevenK: how does one make a debdiff?
[00:24] <kwwii> or pointers to info?
[00:25] <crimsun> ogra: I'll try to create a vm and test it tonight then modify the bug into a removal request
[00:25] <kwwii> sorry for asking stupid questions but /me is an artist :p
[00:26] <crimsun> kwwii: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff
[00:26] <ogra> kwwii, debdiff human-theme_1.2.3.dsc human-theme_1.2.4.dsc >human-theme.debdiff
[00:26] <StevenK> kwwii: Okay, so you have your two source packages, foo_0.1.dsc and foo_0.2.dsc. If you run 'debdiff foo_0.1.dsc foo_0.2.dsc > foo.debdiff' it will give a diff of everything that changed between the two versions
[00:27] <james_w> hey kwwii, did you see my bug about the location of the panel background for DarkRoom? I'm not sure whether it actually breaks anything, is the panel background looked up based on the theme name when you switch?
[00:27] <kwwii> StevenK, ogra, crimsun: considering the fact that I already removed the old dsc files that sounds like more work than just buggin seb128 tomorrow :p
[00:27] <kwwii> james_w: yes, I saw that..stupid mistake of mine
[00:28] <kwwii> james_w: not sure if I can fix that before the release though
[00:28] <ogra> kwwii, apt-get source human-icon-theme (in a different dir) ;)
[00:28] <kwwii> ogra: but the last version was not released either
[00:28] <kwwii> I guess I could get it per bzr somehow
[00:28]  * ogra has a bautifully looking DarkRoom theme here, no breakage seen so far
[00:29] <kwwii> ogra: the panel bg gets installed in a dir called Darkroom
[00:29] <slangasek> kwwii: for sponsorship, one typically wants to see the whole diff from the last version in the archive
[00:29] <kwwii> which, althouh not a direct bug is stupid
[00:29] <slangasek> but if it's normally released from bzr, there are other ways to achieve this that don't involve sending debdiffs to LP
[00:30] <ogra> kwwii, hmm, so i am supposed to have a pixmap background, not a plain color ?
[00:30] <kwwii> slangasek: everything is in bzr
[00:31] <kwwii> ogra: nope, for the dark theme I just include the bg but cannot set it per default
[00:31] <kwwii> I need to ask vuntz how to do that within a theme
[00:31] <kwwii> but I don't even know him
[00:31] <ogra> hmm, trying that out i must admit it like it better without
[00:31] <kwwii> funny, he works for us :-)
[00:31] <slangasek> ?
[00:32] <kwwii> oh, try the bg
[00:32] <ogra> i do
[00:32] <kwwii> and set the gconf setting to stretch first
[00:35] <ogra> kwwii, i see what you mean, but that doesnt make it brighter :)
[00:35] <kwwii> ogra: true
[00:35] <kwwii> I tried to make it very subtle
[00:35] <kwwii> erm spelling
[00:35] <ogra> i like it in the system color
[00:36] <kwwii> hehe, and mark thinks it looks good
[00:36] <kwwii> funny how that works, eh?
[00:36] <ogra> heh
[00:36] <kwwii> sometimes it would be easier if mark wasn't my boss :p
[00:36] <ogra> it somewhat hides the beauty of the button and menu effects
[00:38] <ogra> i like how the taskbar buttons look slighty sunk in with that soft shadow ... the drakness of the background just makes that go away
[00:38] <kwwii> ture
[00:38] <kwwii> ahh
[00:38] <ogra> same for the rounded menu top items
[00:38] <kwwii> true
[00:39] <kwwii> if I removed the alpha is you would like better
[00:39] <kwwii> -is
[00:39] <kwwii> anyway
[00:39] <kwwii> time for sleep
[00:39] <kwwii> night
[00:40] <ogra> heh
[00:40] <ogra> night
[00:41]  * ogra goes to bed as well
[00:47] <slangasek> bryce: haven't we had bug #277831 previously, or am I thinking of a different driver?
[00:48] <bryce> slangasek: yep, rotation on -ati sucks big
[00:48] <bryce> has for some time.  but it's been getting better
[00:49] <bryce> hmm, is proper grammar even that?
[00:49] <slangasek> bryce: right, so no reason I should accept the intrepid nomination under the present circumstances, really
[00:50] <bryce> slangasek: no reason.  In the upstream bug it says rotation isn't supported on this hardware.
[00:50] <slangasek> funny, some software will return error messages instead of locking up when something isn't supported ;)
[00:50] <bryce> slangasek: yeah :-/
[00:51] <bryce> I've been keeping a close eye on -ati lately, and if a patch turns up that implements that, I'll hopefully notice it and we can consider bringing it in
[00:51]  * slangasek nods
[00:51] <bryce> but -ati crashing on rotate is nothing new, I don't think it's going to be seen as a regression
[00:52] <bryce> (indeed I'm not sure r6xx cards even worked on -ati when hardy was out)
[00:52] <slangasek> well, the submitter is one who makes voracious use of the regression-* tags when they apply, so I would suppose not :)
[00:53] <bryce> heh
[00:54] <bryce> wouter's a good triager.  I'm surprised he didn't have a bugzilla account at fdo already
[01:49] <mrmike> Hi, looking for a sockets library in the repository? ideas?
[01:49] <mrmike> Also, i saw libasio-dev, is that boost::asio?
[02:09] <TheMuso> slangasek: yeah re the totem segfault with pulse, I can not, with mp3s, oggs, flacs etc, reproduce it at all.
[02:09]  * slangasek nods
[02:16] <slangasek> tjaalton: did the X logs posted to bug #256142 help you any?
[03:15] <ScottK> slangasek: All the binary for kviewshell is also shoved into kdvi.  Kdvi needed it as a dependency, but nothing else does so re-introducing two binary packages didn't make sense.
[03:31] <slangasek> ScottK: ah, so this usr/lib/libdjvu.so existed before, yuck
[03:31] <ScottK> slangasek: The new kdvi conflicts/replaces kviewshell, so it should work out OK.
[03:32]  * slangasek nods
[03:32] <ScottK> slangasek: Taking the entire kdegraphics package for KDE3 and paring it down to build just one package involved some compromises.
[03:32] <slangasek> sure
[03:52] <ScottK> slangasek: Would you please accept guidance-power-manager.  This patch has a funny story behind it.  I thought I fixed this bug number yesterday, but I fixed a large fraction of the dupes stacked under it instead, so this is a good patch.
[04:12] <slangasek> ScottK: done
[04:13] <ScottK> slangasek: Thanks.
[04:24] <kirkland> slangasek: fyi, i'm rolling and testing your ecryptfs patch, as well as the counter
[05:14] <kirkland> slangasek: still around?
[05:40] <tjaalton> slangasek: well, they are more helpful for upstream, and those are already there but no solution yet..
[05:41] <tjaalton> slangasek: also, that particular bug is a strange one, since one patch fixing things for others can (and has) broken it for others
[05:45] <tjaalton> and the root cause can be in the kernel DRM driver too
[06:07] <slangasek> kirkland: in and out
[06:08] <kirkland> slangasek: k, tested your patch
[06:08] <kirkland> slangasek: it fixes at least one case (non matching passwords)
[06:08] <kirkland> slangasek: but not cases where it asks you to try again 3 times
[06:08] <kirkland> slangasek: like leaving a blank password x6
[06:08] <kirkland> slangasek: or a 'too simple' password x6
[06:08] <slangasek> hrm, I thought I tested that case
[06:10] <kirkland> slangasek: anyway, i put a test package in my ppa
[06:10] <kirkland> slangasek: i rolled your fix for that bug, plus mine with the counter
[06:10] <kirkland> slangasek: counter is working quite well
[06:11] <kirkland> slangasek: that patch is here: https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/259293
[06:41] <dholbach> good morning
[06:43] <NCommander> morning dholbach
[06:44] <dholbach> hi NCommander
[07:04] <slangasek> sbeattie: I notice that http://people.ubuntu.com/~sbeattie/regression_tracker.html shows entries with Release: none for bugs that, if you look at their bug pages, are "tracked in Intrepid"
[07:05] <kirkland> slangasek: i posted an updated patch at https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/272232
[07:05] <kirkland> slangasek: it contains the fix for 283477 as well
[07:05] <kees> slangasek: not sure about the remaining v4l bits -- I handled everything in "main" plus some stuff in universe.
[07:05] <kirkland> slangasek: i'm grouping those together, as i'd like them sponsored together, after kees reviews the counter code :-)
[07:06] <sbeattie> slangasek: example bug number? (I'm not surprised, just want a quickly identifiable testcase)
[07:06] <kees> kirkland: I won't be back "at work" until monday.
[07:06] <kirkland> kees: :-) sure
[07:06] <slangasek> sbeattie: 260918
[07:07] <slangasek> sbeattie: i.e., the first one listed in the regression-potential list :)
[07:07] <kirkland> kees: i'll get jdstrand to review it tomorrow, then
[07:07] <kees> kirkland: cool
[07:07] <slangasek> kirkland: ok; I'm dead for the night, so I'll have a look tomorrow after the release meeting
[07:07] <kirkland> slangasek: i hear ya
[07:07] <kirkland> slangasek: thanks for your help with this
[07:08] <slangasek> sure
[07:08] <kirkland> kees: fwiw, i added an increment/decrement counter to the mount.ecryptfs_private/umount.ecryptfs_private code
[07:08] <kirkland> kees: it's before the setuid bits
[07:09] <kirkland> kees: which makes the private mount "survive" cronjobs, and multiple simultaneous ssh/console logins/logouts
[07:09] <kees> kirkland: ah, cool
[07:10] <kirkland> kees: sports an flock() and everything :-)
[07:15] <kees> hehe
[07:17] <StevenK> kees: Since you're here, do you want help with the libv4l stuff?
[07:17]  * StevenK actually reads backscroll
[07:19] <kees> StevenK: I helped package it and fixed everything in main.  :P
[07:25] <StevenK> Right. vlc, mplayer, camstream, camorama and amsn]
[07:25] <StevenK> s/]//
[07:25]  * StevenK curses his ] key
[07:26] <kees> StevenK: I'm not interested in writing those patches, no.
[07:27] <kees> StevenK: camstream is very strange -- it didn't like the patch from the v4l website either.
[07:27] <StevenK> kees: I think most of them have patches
[07:28] <StevenK> kees: Send a mail to ubuntu-motu mentioning the bug number and "Fix them, please? :-)" ?
[07:37] <pitti> Good morning
[07:37] <StevenK> Morning pitti
[07:37]  * pitti declares a component-mismatches squashing day
[07:38] <StevenK> \o/
[07:38] <StevenK> pitti: If you want my help, throw me bits
[07:38] <pitti> StevenK: awesome work on NBS!
[07:39] <StevenK> pitti: The last thing is octave-gpc, which is broken, and I can't fix
[07:39] <pitti> StevenK: this gtklookat thing is unfixable, too?
[07:39] <StevenK> pitti: And has already been killed
[07:39] <pitti> great
[07:40] <pitti> and linux-lpia?
[07:40] <StevenK> It's dead upstream, and has been for a while
[07:40] <StevenK> Not sure, didn't look very closely
[07:40] <NCommander> Pici, can I do anything to do to help?
[07:40] <StevenK> Heh
[07:40] <NCommander> oh
[07:40] <NCommander> screw me
[07:40] <NCommander> *pitti
[07:41] <StevenK> pitti: We don't have -meta yet for lpia
[07:41] <StevenK> pitti: And LRM FTBFS, since linux-headers-2.6.27-4 doesn't exist, and I probably need to resurrect it :-(
[07:42] <NCommander> StevenK, isn't it a little late in the cycle to not have it?
[07:42] <StevenK> NCommander: We don't have a meta for -4
[07:42] <pitti> StevenK: why doesn't linux-lpia build -headers?
[07:42] <StevenK> IE, it isn't uploaded yet, smart alec
[07:42] <StevenK> pitti: Because it doesn't build on i386. It's neatly complicated :-(
[07:43] <NCommander> StevenK, can I help?
[07:43] <pitti> StevenK: right, it would probably be Architecture: lpia, not all?
[07:43] <NCommander> We had the same problem with -ports
[07:43] <StevenK> pitti: Right
[07:43] <NCommander> And we managed to get it to work
[07:43] <StevenK> NCommander: How did you solve it?
[07:43] <NCommander> I *think* we made it so the kernel packages build on i386
[07:43] <NCommander> But I'm not sure offhand
[07:43]  * NCommander looks at the git tree to remember
[07:44] <StevenK> pitti: I'm not sure if Soyuz will like a linux-headers-2.6.27-4 package since it already saw one
[07:44]  * StevenK pokes at the -lpia kernel on rookery
[07:45] <NCommander> We have linux-ports-headers
[07:45] <NCommander> (provides linux-headers/linux-headers-2.6)
[07:45] <wgrant> StevenK: Why wouldn't it?
[07:45] <StevenK> Hmmm
[07:45] <StevenK> wgrant: Why wouldn't it what?
[07:45] <wgrant> StevenK: Why wouldn't Soyuz like it?
[07:46] <pitti> StevenK: oh, we aren't talking about -headers-2.6.27-4-lpia?
[07:46] <NCommander> StevenK, I'm looking at the package right now
[07:46] <StevenK> pitti: No, we're talking about -headers-2.6.27-4
[07:46] <pitti> StevenK: anyway, if you actually need -headers-2.6.27, reintroducing that should be ok as long as it has a newer version than the one built from linux
[07:47] <StevenK> pitti: Or I can fix the kernel to build linux-lpia-headers-2.6.27-4
[07:47] <NCommander> StevenK, I think I can fix it for you
[07:47]  * NCommander is checking out ubuntu-lpia.git now
[07:47] <StevenK> Which then doesn't rely on this mess
[07:47] <NCommander> StevenK, I've been dealing with the same mess for ports :-)
[07:47] <StevenK> Heh
[07:48] <NCommander> You'll forgive me if I'm a git-tard though
[07:48] <tjaalton> pitti: hey, I've got a new evdev ready, finally fixes bug 274203
[07:48]  * NCommander tries to avoid git at all costs
[07:48] <StevenK> NCommander: Me too.
[07:48] <tjaalton> pitti: upstream change; http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=7243116f55609a2a5f73bb88cf6ad6386c9bbc0b
[07:48] <StevenK> NCommander: I e-mail diffs to Amit
[07:48] <tjaalton> pitti: ok to upload?
[07:48] <pitti> tjaalton: yay, I already wondered about that, nice! (I wanted to fix the default permissions of the joystickdevice)
[07:48] <StevenK> Actually, no, I just throw them onto rookery
[07:48] <NCommander> StevenK, I think I can pull the build-indep rules from ports which does what you want
[07:49] <pitti> tjaalton: curious fix :) sure, go ahead
[07:49] <tjaalton> pitti: thanks, uploading
[07:49] <StevenK> NCommander: Yeah, except we want to be binary-arch (And ITYM binary-indep)
[07:50] <NCommander> Wait, you want the all package to be built by lpia and not i386?
[07:50]  * NCommander can see Soyuz crying not
[07:50] <tjaalton> pitti: hmm, what permissions?
[07:50] <pitti> tjaalton: of /dev/input/jsX
[07:50] <StevenK> NCommander: Make it any, not all
[07:50] <tjaalton> pitti: ah
[07:50] <pitti> tjaalton: hal sees it as a mouse device, not a joystick one
[07:51] <StevenK> NCommander: IE, linux-lpia-headers-2.6.27-ABI should be arch: any, even if it's a hack
[07:51] <pitti> tjaalton: so I can't apply the magic dynamic ACL trick
[07:51] <NCommander> StevenK, I'm trying to understand your reasoning :-/
[07:51] <pitti> doko: python-reportlab> did this get slangasek's blessing? there's no bug associated, and new upstream version doesn't explain what it changes
[07:52] <StevenK> NCommander: -lpia won't build on i386, and I suspect I don't want it to
[07:52] <pitti> StevenK: arch: lpia?
[07:52] <StevenK> pitti: Well, probably
[07:52] <doko> pitti: not yet, have to write a FF ex report
[07:53] <StevenK> NCommander: Does my reasoning make sense?
[07:53] <NCommander> StevenK, make ARCH=i386 headers would work fine on i386
[07:53] <NCommander> It could be an all target
[07:54] <StevenK> NCommander: Except that it never gets that far
[07:54] <StevenK> NCommander: Since i386.mk doesn't exist in -lpia
[07:54] <NCommander> We added one for -ports
[07:54] <StevenK> Sure, but ports tries to build everywhere
[07:54] <NCommander> No
[07:55] <NCommander> ports is Arch powerpc, hppa, ia64, sparc
[07:55] <StevenK> Well, if you can make it build on i386, then I'm all for it
[07:55]  * StevenK kicks his local mirror
[07:56] <StevenK> So, you synced at 8:00am this morning. Why do you have an newer packages file, and want to download 1.2GB?
[07:56] <StevenK> apt-mirror, I will get you.
[07:57]  * NCommander shall do so
[07:57] <NCommander> :-)
[07:57]  * NCommander creates an lpia intrepid tarball
[07:58] <NCommander> StevenK, the changelog file for the kernel is kinda odd ...
[07:58] <StevenK> Duh
[07:58] <NCommander> Ok, how do I make a new changelog ;-)
[07:58] <NCommander> entry
[07:58] <StevenK> dch -i
[07:58] <pitti> bryce: do you have the patch for bug 226668 in a PPA? if not, I'll start a build now
[07:58] <NCommander> Er, what about the point numbers?
[07:59] <StevenK> NCommander: You want 2.6.27-4.8
[07:59] <NCommander> Ok
[07:59] <NCommander> Makes sense
[08:00] <tjaalton> pitti, bryce: there are related patches on the fedora xserver, but I don't know if they fix apport as well
[08:01] <tjaalton> they also turn modedebugging on by default, hmm
[08:01] <NCommander> StevenK, I think you also need linux-lpia-doc
[08:02] <NCommander> so there is no conflict with the regular -doc packages
[08:03]  * StevenK hand waves
[08:03] <StevenK> Not so concerned about -doc
[08:03] <NCommander> Ok
[08:12] <StevenK> NCommander: Is it done yet? :-P
[08:13] <NCommander> Figuring out how to make source package, I haven't messed with this before
[08:13] <StevenK> dpkg-source ?
[08:14] <NCommander> Make?
[08:14]  * NCommander finds debuild -S -sa doesn't work
[08:14] <StevenK> Due to no i386/amd64.mk?
[08:14] <StevenK> NCommander: Do it by hand. cd .. ; dpkg-source -b <dir>
[08:15] <NCommander> I got debuild -S -sa to work
[08:15]  * NCommander had to install kernel-wedge
[08:15] <NCommander> No, there is an i386.mk now
[08:15] <StevenK> Ah
[08:15] <StevenK> You nasty man
[08:15] <NCommander> And a check in the makefiles to make sure it doesn't build linux-lpia on i386
[08:15] <NCommander> (so just the binary-indep target is hit)
[08:15] <NCommander> I'm not completely sure I got it right.
[08:16] <NCommander> I have that off feeling I need to rename the abi folder for the new point release
[08:16] <StevenK> Why?
[08:16] <NCommander> Cause its linux-2.6.27-4.6
[08:16] <NCommander> And the changelog says its 4.7~ppa1
[08:16] <StevenK> Where did you pull it from? 4.7 is in the archive
[08:16] <NCommander> er
[08:16] <NCommander> sorry
[08:16] <NCommander> .7 and .8 respectively
[08:17] <pitti> StevenK: so, as a first step, should hildon-control-panel, midbrowser, etc. really go back to universe?
[08:17] <StevenK> pitti: I want to say no, because I fought tooth and nail to get them into main, but they can probably be demoted.
[08:17] <StevenK> pitti: Let me wait for lool to surface
[08:18] <pitti> StevenK: that's ok, britney just wants them to go
[08:18] <pitti> it seems that c-m got unfixed again
[08:18] <pitti> StevenK: problem is now that I can't really see now which of the main->universe depends can actually go
[08:18] <NCommander> StevenK, test building on i386 with debuild -B -A to simulate an arch all pass
[08:19] <pitti> StevenK: ok, I'll ignore that for now
[08:19] <NCommander> StevenK, this is going to take a few minutes to build, brb for some food
[08:33] <lool> cjwatson: xvfb is still broken; I tried to setup qemu ppc and qemu sparc envs yesterday to debug it, but wasn't successful; I'm looking at using porter machines now
[08:39] <StevenK> pitti: How can I debug why a key doesn't get automounted on Hardy?
[08:46] <pitti> StevenK: do you see it in the computer place, unmounted?
[08:46] <pitti> or not at all?
[08:46] <StevenK> pitti: I do
[08:46] <pitti> and can you mount it from there with clicking?
[08:47] <StevenK> pitti: Double clicking it and right-clicking -> Mount Volume seems to be a no-op
[08:52] <pitti> StevenK: ok, that would be it then
[08:52] <StevenK> But how does one debug that?
[08:52] <pitti> StevenK: gnome-mount -vbd /dev/whatever output?
[08:52] <StevenK> ** Message: Mount failed for /org/freedesktop/Hal/devices/volume_uuid_48F2_CE36
[08:52] <StevenK> org.freedesktop.Hal.Device.PermissionDeniedByPolicy : org.freedesktop.hal.storage.mount-removable no <-- (action, result)
[08:52] <StevenK> Thank you for telling me, Nautilus
[08:53] <StevenK> pitti: /sys/block/sdb/removable is 1, though
[08:57] <StevenK> NCommander: No news?
[08:57] <NCommander> StevenK, I can build the headers, but not in a sane way yet
[08:58]  * NCommander is debugging the makefile ATM
[08:59] <NCommander> oh THAT's ugly
[08:59] <StevenK> Now you have to share
[09:00] <NCommander> THe -ports control file has a i386 kernel to make rules happy
[09:00] <NCommander> But
[09:00] <NCommander> It looks like I can fix this with a little hacking to remove that requirement
[09:00] <NCommander> I can generate the headers file on i386
[09:00] <NCommander> Its just a matter of rules hacking
[09:01] <PecisDarbs> is there OpenOffice.org 3 PPA for Hardy?
[09:01] <cjwatson> NCommander: I think it's inappropriate and worryingly complex for linux-lpia to build on i386, FWIW
[09:01] <pitti> StevenK: I guess you don't have a CK session?
[09:01] <NCommander> cjwatson, the -headers package?
[09:01] <cjwatson> lool: can we just turn off the test suite in pygtk for now?
[09:01] <cjwatson> NCommander: yes
[09:01] <NCommander> cjwatson, that's how the other kernels do it, both -ports, and amd64's kernel
[09:01] <lool> cjwatson: finishing that as we speak
[09:01] <NCommander> and how it was done when it was just a single kernel package
[09:01] <cjwatson> NCommander: both of them naturally build on i386
[09:01] <lool> wanted to do something too clever which is taking me too much time
[09:01] <cjwatson> -ports builds the 386 kernel
[09:02] <cjwatson> NCommander: I'll reject a linux-lpia that builds on i386; I really think it's wrong
[09:02] <NCommander> cjwatson, ports-headers also builds on i386.
[09:02] <cjwatson> NCommander: yes, that's because linux-ports builds other i386 packages
[09:02] <NCommander> Fair enough
[09:02] <NCommander> So then its just a matter of making it Arch: lpia, and then hacking rules to build headers in the right spot
[09:03] <cjwatson> NCommander: plus, if you build linux-lpia on i386 just so that it can build linux-header-2.6.27-4, then you'll run into trouble when the ABI is the same as the main linux package
[09:03] <NCommander> I was just building the headers on i386
[09:03] <NCommander> THe main kernel would be built on lpia
[09:03] <StevenK> cjwatson: If it's called linux-lpia-headers-2.6.27-4, I can deal
[09:03] <cjwatson> NCommander: yes, I know, that's what I object to.
[09:03] <cjwatson> just build the whole thing on lpia.
[09:04]  * StevenK notes saying that roughly 40 minutes ago
[09:04]  * NCommander runs away
[09:04] <NCommander> Ok, ok :-P
[09:04] <cjwatson> it's only needed for one architecture, there's no reason to mess around with i386 just so that you can have an arch: all package.
[09:04] <NCommander> Point taken ;-)
[09:05] <cjwatson> lool: thanks
[09:05] <StevenK> pitti: I ought to have a CK session
[09:05] <StevenK> ... except I don't
[09:05] <NCommander> I'll cook a package then that builds the headers on lpia. It needs some rules love, but not that difficult
[09:05] <pitti> StevenK: CK crashed?
[09:06] <StevenK> root     11053  0.0  0.1  32712  1596 ?        Ssl  Oct14   0:00 /usr/sbin/console-kit-daemon
[09:06] <NCommander> cjwatson, for my first venture into kernel hacking, I shot myself into the foot quite well ;-)
[09:06] <cjwatson> NCommander: first rule, keep it simple :)
[09:06] <pitti> cjwatson: is it actually deliberate that the mobile seed isn't considered in component-mismatches?
[09:07] <StevenK> pitti: Yes. The mobile seed meta packages are in universe
[09:07] <NCommander> cjwatson, so shouldn't Linux be microkernel based if we're keeping things simple ;-)
[09:08] <pitti> lool: seems we need to demote the Recommends: elisa-plugins-ugly to Suggests:; it's pulling in two handfuls of non-main-wanted packages; ok for me to do that? (or do you want to do it in bzr or so?)
[09:08] <cjwatson> I take it you've never actually seen a microkernel
[09:08] <NCommander> cjwatson, I wrote /dev/random for GNU Hurd :-P
[09:08] <cjwatson> they are elegant, but hardly simple
[09:08]  * NCommander was being sarcastic 
[09:08] <lool> -ugly is supposedly in universe I think
[09:09] <lool> let me check
[09:09] <lool> yeah it is
[09:09] <lool> besides, it's lagging, don't look at the current version
[09:09] <StevenK> main can't really Recommend universe
[09:09] <pitti> that's the very thing I want to fix, yes :)
[09:09] <lool> right, I think we can demote the recommends from elisa to a suggests
[09:10] <lool> i thought you were speaking of recommends of -ugly on other stuff
[09:10] <lool> It's weird cause I thought I had fixed this before uploading elisa
[09:10] <pitti> lool: no, just from the "elisa" package, that should solve it
[09:10] <NCommander> cjwatson, so do you agree that linux-headers -> linux-lpia-headers makes sense?
[09:10] <StevenK> pitti: And empties component-mismatches by about half?
[09:10] <cjwatson> NCommander: more or less
[09:10] <NCommander> cjwatson, ok, so I wasn't completely loosing my mind ;-)
[09:10] <cjwatson> it'll certainly do the job for intrepid
[09:10] <pitti> StevenK: not quite, by maybe 10 packages
[09:11] <StevenK> pitti: Pity
[09:11] <NCommander> cjwatson, what i386 kernels built out of -ports? That seems wrong ...
[09:11] <cjwatson> for jaunty I really think some kind of re-merging of all these kernel sources makes sense
[09:11] <StevenK> -386, isn't it
[09:11]  * NCommander also notes the ports package needs some serious love
[09:11] <cjwatson> NCommander: the 386 variant, as I said above
[09:11] <NCommander> Oh
[09:11] <pitti> lool: ok, I'll do the change now
[09:11] <NCommander> sorry
[09:11] <cjwatson> I think this is wrong
[09:11] <NCommander> When I think of 386, I think of -generic
[09:11] <cjwatson> and have said so several times to the kernel team
[09:11] <StevenK> cjwatson: Me too
[09:11] <NCommander> Its hard to think of it as a varient ;-)
[09:11] <cjwatson> but nevertheless, it is the case
[09:11] <lool> pitti: pushing already
[09:11] <pitti> lool: oh, nice; thanks!
[09:11] <pitti> lool: let me know when you uploaded,  I'll wave it through the queue
[09:12] <lool> done
[09:13] <StevenK> pitti: So the daemon didn't crash, but I lost my session?
[09:13] <pitti> StevenK: well, did it crash? anything in /var/crash? or apport.log?
[09:13] <pitti> StevenK: you don't "just lose" your session
[09:13] <pitti> StevenK: ck-list-sessions is empty?
[09:13] <pitti> it's usually because CK crashes
[09:14] <StevenK> pitti: ck-list-sessions is empty, yes
[09:14] <StevenK> pitti: /var/crash is empty, too
[09:15] <StevenK> pitti: And nothing in apport.log
[09:15] <StevenK> Well, nothing relevant in apport.log{,.1,*.gz}
[09:16] <lool> cjwatson: (I'm testing my pygtk change in my ppa)
[09:16] <seb128> StevenK: look for how long the ck daemon is running compared to your session?
[09:16] <StevenK> Hm. A whole month difference
[09:17] <StevenK> steven   27114  0.0  0.2 193700  3572 ?        Ssl  Sep24   0:03 x-session-manager
[09:17] <StevenK> root     11053  0.0  0.1  32712  1596 ?        Ssl  Oct14   0:00 /usr/sbin/console-kit-daemon
[09:18] <pitti> StevenK: so aport.log and crash report just got rotated away then
[09:18] <cjwatson> lool: won't build on any of the affected architectures, mind you ...
[09:18] <bigon> could someone have a look at bug 258192 it breaks ldap support of dhcpd
[09:19] <StevenK> pitti: But it covers crashes before this boot, like back in May
[09:19] <pitti> hmm
[09:19] <lool> cjwatson: I changed it to trigger on amd64
[09:20] <lool> cjwatson: But it was a good idea to remind me nevertheless, thanks
[09:20] <seb128> StevenK: maybe it did abort and not crash
[09:20] <NCommander> StevenK, I'm test building the changes now
[09:22] <StevenK> NCommander: Which will take like 3 hours?
[09:22] <NCommander> On this machine, kernel builds are pretty fast
[09:24] <maco> can someone look at bug 282977 ? xscreensaver and gnome-screensaver both have entries in System->Preferences as just "Screensaver" in Intrepid.  Is it too late to nominate a semi-cosmetic but also rather confusing bug like that for release?
[09:24] <StevenK> seb128: That's possible.
[09:25] <StevenK> I can recall that bug happening before
[09:25] <StevenK> Like Dapper or Edgy
[09:25] <maco> StevenK: the one i mentioned? crimsun said it was in hoary
[09:26] <StevenK> I wasn't around for Hoary, but I remember it happening
[09:26] <StevenK> maco: But yes
[09:26] <StevenK> Ah, Breezy is the bug
[09:27] <StevenK> pitti: Would that result in my lost session? console-kit-daemon abort()'ing?
[09:27] <directhex> duplicate screensaver icons definitely worth fixing IMHO, it's a stupid annoying bug
[09:29] <pitti> StevenK: yes, if it hits an assert or so
[09:31] <Mirv> mvo: thanks for upload, fine now for intrepid. but out of interest, did you merge from Debian? I'd now have at least certain case of non-import.
[09:33] <pitti> ScottK: still awake?
[09:34] <Mirv> mvo: in case you did a merge, see http://paste.ubuntu.com/58718/
[09:35] <pitti> StevenK: hm, seems that clamav slided back to universe, repromoting
[09:37] <lool> cjwatson: Concerning the xvfb issue itself, it's relatively important to fix, I have little time today due to meetings and other issues here (see email), so feel free to grab someone to chase it -- especially if you know someone with ppc, sparc, or hppa hardware
[09:37] <lool> Just for the record, I have ppc, but never used linux on it, would take me a while to setup
[09:37] <mvo> Mirv: I can not currently merge from debian, they stopped publishing the po files - I think it was due to some hardware problems
[09:37] <mvo> Mirv: it used to be on http://ddtp.debian.net/debian/dists
[09:38] <lool> cjwatson: I was fortunate to test with ppa: testsuite fails on all arches when g_get_home_dir() isn't writable
[09:38] <lool> cjwatson: I've pushed pygtk_2.13.0-0ubuntu8 with testsuite running everywhere but not failing the build
[09:38] <mvo> Mirv: if you have more information, I would love to reenable the merge
[09:38] <NCommander> lool, I have powerpc hardware I can test on
[09:38] <lool> Can someone please accept pygtk?
[09:38] <lool> NCommander: Cool, I need to disappear in some minutes to move to a new location to work
[09:39] <lool> NCommander: Let me give you instructions
[09:39] <lool> NCommander: the problem is that Xvfb doesn't work anymore on some arches
[09:39] <NCommander> lool, I also have sparc (hardy only), and hppa (intrepid) access, but I don't have physical access to those boxs
[09:39] <lool> NCommander: Might be an endianess issue, we don't know
[09:39] <NCommander> And I don't have root on the sparc box
[09:39] <lool> NCommander: A chroot on any of these arches is fine
[09:39] <NCommander> I'll have to ping a sysadmin to get a sparc chroot
[09:39] <NCommander> I do have ia64 also ;-)
[09:40] <lool> NCommander: What you need is the intrepi's xvfb, try e.g. to launch "xvfb-run xterm -e ls" or something along these lines
[09:40] <Mirv> mvo: like I said in another message earlier, DDTP is now hosted on official mirrors like ftp.de.debian.org, so there was no need for ddtp.debian.net hosting anymore
[09:40] <NCommander> lool, I have never used xvfb, what's susposed to happen?
[09:40] <lool> NCommander: You might want to pass -e xvfb-run.log to xvfb-run to see Xvfb errors
[09:40] <lool> NCommander: xvfb is just like Xorg, except it doesn't use any physical device
[09:40] <Mirv> mvo: eg. http://ftp.de.debian.org/debian/dists/sid/main/i18n/
[09:40] <mvo> Mirv: right, but that is just the "Translation-*" files, right?there used to be a po file export too
[09:41] <NCommander> lool, ok
[09:41] <lool> NCommander: So what's supposed to happen is that the applications runs as if it was displayed on the screen, but it doesn't use any real hardware
[09:41] <Mirv> mvo: oh, ok then, I have no idea about any PO export...
[09:41] <lool> NCommander: it's used for graphical testsuites of misc packages, e.g. gtk, pygtk, bonoboui etc.
[09:41] <NCommander> Ok, checking on powerpc
[09:41] <mvo> Mirv: thanks, I will add code that does a Translation->po translation I think
[09:41] <lool> NCommander: So the current Xvfb doesn't work; it seems it's since the new snapshot we pulled recently, around beginning of oct
[09:42] <lool> 2:1.5.1-1ubuntu3 I would guess
[09:42] <NCommander> lool, xvfb is not installable on powerpc it seems
[09:42] <pitti> lool: pygtk accepted
[09:42] <Mirv> mvo: yes, it might be they don't have resources to develop/admin it or something. would be nice for jaunty.
[09:42] <lool> NCommander: It would help if you could test the current intrepid version, the 2:1.5.1-1ubuntu3 version, and git bisect between the two
[09:42] <NCommander> git bisect?
[09:43] <mvo> Mirv: I hope to find a bit of time to write this import for intrepid so that we can do another merge, but for jaunty we should talk to the debian team again I think
[09:43] <lool> NCommander: Ok, so upstream and the ubuntu package use git
[09:43] <NCommander> ok
[09:43] <Mirv> mvo: ok, of course it'd be great for intrepid too, I just assume a great bit of hurry everywhere :)
[09:44] <lool> NCommander: git allows you to do a dichotomy between two git "revisions" to see which is the first one which caused a regression
[09:44] <NCommander> lool, its nice that someone cares about ports ;-)
[09:44] <mvo> Mirv: it is, it just means longer hours ;)
[09:44] <mvo> Mirv: but I think its worth it
[09:44] <NCommander> lool, I try to avoid git like the plague, so your probably going to need to talk me through this (I apologize)
[09:45]  * directhex gives NCommander the plague
[09:45] <Mirv> mvo: it'd be great, yes, since together with the new app-install-data translatability it brings a better experience for gnome-app-install users
[09:45] <lool> NCommander: It's called git bisect, has a man page, and it basically helps you in checkouting all intermediate revisions of a tree; you tell the tool what version you know fail, which one works, and it tells you to try one between the two; after each step, you tell the tool whether test failed or not, and it tells you next rev to try etc.
[09:45] <lool> pitti: thx
[09:45] <NCommander> directhex, I'm immune to your plague, I already suffered from mono
[09:45] <pitti> doko: libspe2-dev recommends: cell-gcc, which is in universe; ok to drop that to suggests:?
[09:45] <NCommander> lool, sounds like a feature bazaar should adopt ;-)
[09:45] <mvo> Mirv: yes! that reminds me, have you seen  http://people.ubuntu.com/~mvo/nightmonkey ?
[09:46] <mvo> Mirv: I think Nyitrai posted about it on the i18n list a while ago
[09:46] <pitti> doko: (this wants to pull in cell-binutils, too)
[09:46] <mvo> Mirv: it hopefully makes it easier to find out about relevant strings
[09:46] <lool> NCommander: Projects using bazaar never have any regressions, they don't need the feature
[09:46] <Mirv> mvo: actually not your version, someone hosted one for Finnish, though
[09:46] <Mirv> mvo: yes it does
[09:47] <mvo> Mirv: another think I would like to talk to debian about if/how we can push our translations back to debian
[09:47] <NCommander> lool, so Microsoft should adopt bzr in place of source safe for Windows 7 ;-)
[09:47]  * wgrant points NCommander at https://code.edge.launchpad.net/bzr-bisect
[09:48] <pitti> doko: or can we demote elfspe2 instead?
[09:48] <pitti> doko: (it seems to be seeded, no rdepends)
[09:49] <Mirv> mvo: would be interesting. I've tried to suggest people to Debian's DDTP primarily (https://wiki.ubuntu.com/DdtpLpHtml etc.), but some languages have good amount of work done on ddtp-ubuntu as well
[09:50] <mvo> Mirv: I share this view
[09:51] <StevenK> pitti: Oh, blah
[09:51] <StevenK> pitti: My -mid install does the same thing
[09:51] <StevenK> pitti: But that has a session
[09:56] <NCommander> lool, the PowerPC box is updating now, and the sparc one is available as well
[09:58] <pitti> StevenK: still EPERM from gnome-mount?
[09:58] <pitti> StevenK: can you pastebin the ck-list-sessions output?
[09:59] <lool> NCommander: #281610
[09:59] <lool> NCommander: I'm disappearing now, will read your comments via the bug
[10:02] <StevenK> pitti: Not really, no network
[10:03] <pitti> StevenK: check if is-local is TRUE and x11-display-device exists?
[10:03] <pitti> StevenK: and if active is TRUE
[10:03] <StevenK> pitti: active is FALSE
[10:03] <pitti> StevenK: that would be it then
[10:03] <StevenK> pitti: is-local is TRUE and x11-display-device is ""
[10:03] <pitti> StevenK: hm, is that actually for your currently running session then?
[10:03] <pitti> or maybe for VT1 or so
[10:04] <StevenK> pitti: It says display-device = '/dev/tty7' , so I think so
[10:04] <StevenK> NCommander: Still building?
[10:04] <pitti> weird
[10:04] <NCommander> StevenK, yup
[10:05] <pitti> StevenK: how was this started? its not gdm, I figure
[10:05] <StevenK> pitti: Directly
[10:05] <StevenK> Let me dig
[10:05] <pitti> StevenK: so probably through ck-launch-session in /etc/X11/Xsession.d/90consolekit
[10:05] <StevenK> pitti: Sounds right
[10:08] <StevenK> Hm.
[10:08] <StevenK> I may have done a bad thing.
[10:09] <StevenK> I gave my Q1 running -mobile to my wife. She has discovered playing Aislerot with a touchscreen, and now I might not get it back.
[10:09] <wgrant> Haha.
[10:09] <StevenK> pitti: Why would it not be active, then?
[10:10] <StevenK> pitti: Do we need to call something later in mid-gui-start?
[10:10] <pitti> StevenK: no, CK should be able to figure it out
[10:10] <StevenK> pitti: It seems that doesn't hold true. :-P
[10:10] <pitti> StevenK: so it doesn't have an x11-display?
[10:10] <StevenK> pitti: Nope
[10:10] <pitti> if not, that would probably be the reason
[10:11] <StevenK> Surely $DISPLAY should be set that late ...
[10:12] <pitti> seb128: is there a particular reason why we use 'libgtop' source package name, while Debian uses 'libgtop2'?
[10:13] <seb128> pitti: no
[10:13] <pitti> seb128: mind if I do an upload to change the name?
[10:13] <seb128> pitti: that's just the upstream name
[10:13] <pitti> seb128: and remove libgtop?
[10:13] <seb128> pitti: go for it, I don't really see the point but whatever
[10:13] <pitti> seb128: well, just being able to merge/sync later
[10:13] <pitti> seb128: (it appears in component-mismatches, too)
[10:13] <pitti> seb128: one source package should go; I don't particularly mind which one
[10:14] <seb128> pitti: how is the source name revelant to component-mismatches?
[10:14] <pitti> seb128: libgtop2 source doesn't build current binaries and thus wants to go to universe
[10:14] <seb128> pitti: rename it, I was expected debian to rename the source but lool is against that so they will not likely do it
[10:14] <pitti> seb128: ok, thanks
[10:14]  * StevenK manages to prise his Q1 out of his wife hands
[10:14] <doko> pitti, cjwatson: we did seed libspe2 because we wanted it on the cd. if we want to keep it, we should use binutils-spu and gcc-spu to build it. but I don't mind demoting
[10:15] <StevenK> doko: You're no archive admin :-P
[10:15] <StevenK> doko: I can demote it, unless pitti is all over it
[10:15] <StevenK> NCommander: Is it done yet?
[10:15] <pitti> doko: right, I guess the real question is "do we want to support cell in intrpeid"; so I guess we should either promote cell-gcc and the spu binutils as well, or demote it all?
[10:16] <doko> StevenK: no time for that, have to fix packages like cacao and that ;p
[10:16]  * pitti delegates resolution of this to StevenK, to fan out the enormous pile a bit :)
[10:16] <cjwatson> cell-gcc/binutils must have been demoted, since I'm sure they used to be in main
[10:16] <StevenK> cacao is broken?
[10:16] <pitti>   cell-gcc | 4.1.1r840-0ubuntu7 | gutsy/universe | source
[10:16] <StevenK> I thought I fixed it
[10:16] <doko> we never had the cell packages in main, afaik
[10:16] <pitti>   cell-gcc | 4.1.1r840-0ubuntu7 | hardy/universe | source
[10:16] <pitti>   cell-gcc | 4.1.1r840-0ubuntu7 | intrepid/universe | source
[10:16] <cjwatson> odd
[10:16] <pitti> cjwatson: it's just a recommends, wasn't relevant so far
[10:16] <pitti> cjwatson: libspe2-dev recommends: cell-gcc, that's everything
[10:17] <doko> the recommends does make sense
[10:17] <cjwatson> hmm, ok, no build-dep?
[10:17] <doko> no
[10:17] <NCommander> StevenK, no
[10:17] <StevenK> NCommander: How about now?
[10:17] <StevenK> NCommander: Sorry :-P
[10:17]  * NCommander takes his HPPA box and smashs StevenK head on it
[10:18]  * StevenK re-adds ClueBat to his packing list
[10:19] <StevenK> pitti: Any way to debug this mess, like ck-launch-... -v ?
[10:19] <pitti> StevenK: you could augment 90consolekit with some gdb/strace/set -x love
[10:19] <StevenK> set -x is no fun
[10:19] <StevenK> "Yes, it calls ck-launch-session. I knew that already."
[10:20] <StevenK> Bah, no strace
[10:20] <pitti> StevenK: does ck-launch-session work correctly if you run it from an X terminal?
[10:20] <pitti> StevenK: i. e. do you get a proper active session then, with DISPLAY?
[10:20] <StevenK> pitti: Yup
[10:23] <pitti> ArneGoetje: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt "binary-only main->universe" has a couple of packages which should be added to the language-support packages; can you please have a look?
[10:24] <pitti> ogra: ah, discover1 can go now, thansk for fixing ltsp
[10:25] <pitti> StevenK: gnutls13 can go now?
[10:26] <StevenK> pitti: libflashsupport and kio-sword needs to die
[10:26] <pitti> -- intrepid/universe i386 deps on libgnutls13:
[10:26] <pitti> kio-sword
[10:26] <pitti> libflashsupport
[10:26] <pitti> oh, darn
[10:26] <pitti> StevenK: any word from ogra about libflashsupport?
[10:26] <pitti> or TheMuso?
[10:27] <StevenK> pitti: ogra says kill it
[10:27] <StevenK> pitti: No bug, though
[10:27] <StevenK> pitti: Bug 267749 is close-ish
[10:27] <pitti> StevenK: ok; want to do? I'd just ignore kio-sword, it seems to be stale anyway
[10:28] <StevenK> pitti: icthux blah blah wants kio-sword
[10:28] <StevenK> pitti: So we can bin libgnutls13 leaving it brokener
[10:28] <pitti> right
[10:28] <pitti> done
[10:28] <doggymenz> 8.10 isnt out yet, and im looking forward to 9.04, with kernel 2.6.28 having merged GEM (kernel memory manager) in rc1
[10:28] <StevenK> pitti: But that will make icthux uninstallable
[10:29] <pitti> StevenK: it can just be unseeded there?
[10:29] <StevenK> pitti: So we probably want to remove the package anyway
[10:29] <StevenK> pitti: Since it doesn't make what cleaning we do, we break icthux
[10:30] <slytherin> Now that default-jdk on powerpc is openjdk, can someone try doing a test build by enabling java features in openoffice.org for powerpc as well?
[10:32] <maco> StevenK: what about that bug?
[10:32] <pitti> tjaalton, bryce: x11proto-dri2, xserver-xorg-video-{nsc,radeonhd,tga} all want to go to universe; ok?
[10:32] <maco> StevenK: libflashsupport is not needed in intrepid from what crimsun's been telling me
[10:33] <maco> the combination of flashplugin-nonfree version 10 and libasound2-plugins and "asoundconf set-pulseaudio" takes care of it
[10:34] <tjaalton> pitti: yep, dri2 is not needed yet, nsc doesn't work, radeonhd is not used by default and tga useful only on alpha
[10:34] <maco> flashplugin-nonfree installs libasound2-plugins, and the configuration is pre-seeded in systems that have pulse, like ubuntu (as opposed to kubuntu since it uses phonon)
[10:34] <pitti> tjaalton: thanks
[10:35] <pitti> evand: usb-creator wants to go back to universe, please seed it to an appropriate place
[10:35] <StevenK> maco: It hasn't effectively said "Please kill it"
[10:36] <maco> StevenK: does a bug need to be filed saying it's unneeded in intrepid and reiterating its instability (as if that hasnt been mentioned by everyone but me all through hardy's cycle)?
[10:37] <StevenK> maco: It needs to be effectively communicated to -archive, though
[10:38] <maco>  ah wait now that firefox stopped timing out, that's basically what that bug says
[10:40] <pitti> zul: you recently seeded virt-viewer to DVD, but there is no MIR, and it pulls in xen-3.1 into main; I unseeded it again for now; if you need it in main, please fix the package and create an MIR. thanks!
[10:42] <pitti> zul, kirkland, dendrobates: nagios wants some more packages in main; can you please have a look at http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt and check what should be promoted or demoted, or which dependencies should be weakened?
[10:42] <StevenK> NCommander: Please grab me when the kernel finishes
[10:42] <NCommander> StevenK, it's finishing now building packages
[10:43] <pitti> seb128: hm, gnome-games-extra-data is in universe; is that deliberate, or a glitch?
[10:43] <NCommander> StevenK, I need to make some tweaks because we now have package collisions
[10:43] <NCommander> (i.e. linux-source/linux-doc now collide with the non-lpia packages)
[10:44] <seb128> pitti: that's deliberate, there is no real point to have it in main since it doesn't bring anything useful
[10:44] <pitti> seb128: ok; gnome-games-data recommends it, so that should be dropped to suggests then?
[10:44] <seb128> pitti: and this way motu can do the updates, etc
[10:44] <seb128> pitti: suggests look correct
[10:44] <pitti> we do instal gnome-games by default, so the recommends doesn't do anything anyway
[10:45] <pitti> seb128: ok, thanks; uploading
[10:45] <seb128> pitti: thanks
[10:48] <mvo> Riddell: the notification about fusa (that confused you yesterday) will only be shown when there is actually a gnome-panel running :)
[10:48] <pitti> TheMuso: I dropped the festival recommends from libgnome-speech7 (see changelog for rationale); please yell if that wasn't right
[10:48] <mvo> Riddell: thanks for reporting that!
[10:50] <Riddell> mvo: thanks, that should sort it
[10:50] <pitti> mvo: oh, that update-notifier change looks quite intrusive (run for non-admins)
[10:51] <mvo> pitti: it is
[10:51] <mvo> pitti: sorry for that :/
[10:51] <mvo> pitti: its required so that every user seens the notification
[10:52] <NCommander> StevenK, pijng
[10:52] <NCommander> *ping
[10:55] <pitti> mvo: it won't show the icon or upgrade stuff to non-admins?
[10:56] <mvo> pitti: so far update-notifier did not start for non-admin users
[10:57] <mvo> pitti: that means that no notification is shown for non-admins
[10:57] <mvo> pitti: the patch changes it so that only the icon for updates is not shown, the other stuff (notifications, crashes, ...) are shown
[10:57] <mvo> pitti: I'm not very happy about that myself, its unfortunate that this did not get the fusa migration work speced/discussed early
[10:58] <amitk> NCommander: if you can work through the whole ports and lpia dependency mess, you should probably have an account on kernel.u.c :)
[10:58] <NCommander> amitk, well, I got lpia's headers building
[10:58] <amitk> NCommander: nice
[10:58] <NCommander> amitk, now I just need to remove the package collisions, and then fix meta to refer to the new linux-lpia-* packages
[10:59] <amitk> NCommander: meta has a git tree too
[10:59] <NCommander> amitk, its not the prettest hack ever (I simply hooked binary-indep from binary-arch, but it does the trick)
[10:59] <NCommander> Right :-)
[11:00] <amitk> NCommander: just send me the patches with your signoff and I'll commit it to the git tree.
[11:00] <mvo_> pitti: sorry, disconnected
[11:01] <NCommander> amitk, Well, at the moment, I'm avoiding commiting, since I'm not quite sure how to make patches with git expect from the last commit to working base :-/
[11:01]  * NCommander is really a git idiot
[11:01] <NCommander> amitk, I assume a freeze exception for the kernel freeze date will be given since lpia doesn't have a working kernel?
[11:01] <realist> I haven't quite got the hang of it yet, either.
[11:02] <amitk> NCommander: ok, after the successful build, fakeroot debian/rules clean, and git diff > lpia.patch should work for now
[11:02] <NCommander> amitk, is there a how to use git for idiots guide ;-)
[11:02] <amitk> but the command you really want to look up is git-commit
[11:02]  * NCommander understands rebasing and all that
[11:02] <NCommander> DO I use debcommit once I'm done with everything and attach a new changelog?
[11:03]  * amitk laughs. NCommander understands rebase and not commit. That's a first :)
[11:03] <NCommander> amitk, I'm surprised no one else attacked this mess before :-/
[11:03] <amitk> https://wiki.ubuntu.com/KernelGitGuide
[11:04] <NCommander> amitk, I understand git commit -a easy enough, just not the specific rules w.r.t. to Ubuntu since it seems every patch landing is a single commit, and not ten
[11:04] <pitti> mvo_: hm, wouldn't that mean that non-admins get a notification about a new ubuntu release?
[11:04] <amitk> NCommander: kernel team has a lack of packaging experts. Most are simple kernel folk.
[11:04] <NCommander> amitk, so I take it I'll be usefult hen
[11:04] <amitk> absolutely
[11:04] <NCommander> I looked at lpia lrm
[11:04] <NCommander> That's going to be *fun* to fix
[11:05] <NCommander> amitk, oh, this is everything I need to know about git, perfect :-)
[11:05] <mvo_> pitti: no, that is the job of update-manager to display those
[11:05] <amitk> NCommander: my motto was get it to work with minimal changes to the base Ubuntu kernel packages.
[11:05] <mvo_> pitti: they won't see that in their menu and its not available via update-notifier (because the update icon is not shown for them)
[11:06] <NCommander> amitk, lpia, lrm, or in general?
[11:06] <amitk> NCommander: lpia, lpia-lrm, lpia-meta
[11:06] <mvo_> pitti: its not ideal for crashes, because they will be asked about system crashes too, but because we disable crashreporting for final that should be ok
[11:06] <NCommander> amitk, I'm just happy ports-meta finally cleared new, so we can have CDs for intrepid
[11:07] <mvo_> it will also show reboot notifications for them, but that should be ok too, it uses the session to request the reboot so it should be equivalent for them to hit the menu item
[11:09] <NCommander> amitk, I've done some kernel hacking before, I managed to get my ethernet card working on Hurd ;-)
[11:09]  * NCommander also ported Linux's entropy framework to Hurd
[11:10] <amitk> hmmm.. "Starting Administrative Application" and then nothing. Doesn't ask me for my password.
[11:10] <amitk> NCommander: good to know...
[11:10] <NCommander> amitk, so I won't break the kernel too badly
[11:10] <amitk> heh
[11:10]  * NCommander has more interest in ports vs. lpia/main
[11:11] <NCommander> amitk, I actually been doing some work in rebasing ports to a more recent kernel
[11:11] <amitk> NCommander: yes. we talked about this yesterday in #u-k
[11:11] <NCommander> oh right
[11:11] <NCommander> sorry, time is relative when you have a screwed up sleep cycle ;-)
[11:11] <NCommander> w00t, successful build run :-)
[11:12]  * NCommander now figures out what magic is needed to get docs and other fun packages not conflicting with each other
[11:13] <amitk> mvo_: who should I ping if the graphical sudo dialog doesn't pop up?
[11:14] <mvo_> amitk: that would be me I guess - what app do you try to start?
[11:14] <mvo_> amitk: intrepid I assume?
[11:15] <mvo_> amitk: could you please open a terminal and run "gksu id" there and see what it prints?
[11:15] <amitk> mvo_: intrepid. update-manager and the bug-buddy both
[11:15] <NCommander> amitk, are linux-doc packages not normally built?
[11:15] <amitk> mvo: Segmentation fault (core dumped)
[11:15] <mvo_> amitk: geh
[11:16] <NCommander> or do we care about those at all?
[11:16] <NCommander> (the rules file suggest that they are disabled on autobuilder runs, thus not built on Ubuntu)
[11:16] <mvo_> amitk: do you have a crash file? or could run run gdb with it please?
[11:16] <amitk> NCommander: they would be nice to have.
[11:16] <emgent> popey: around ?
[11:17] <NCommander> amitk, well, is it going to be different from the normal docs? (I can only see that being the case if the lpia and main kernels diverage in version parity)
[11:19] <amitk> NCommander: they should be exactly the same i think
[11:19] <amitk> s/i think//
[11:19] <mvo_> amitk: can you see if gksu is crashing or sudo (that is called from gksu)
[11:19] <mvo_> amitk: is that with compiz or without?
[11:19] <NCommander> amitk, if thats the case, then the normal docs should suffice
[11:19] <NCommander> (i.e., not much point in having a seperate linux docs package)
[11:20] <amitk> mvo_: no compiz, amd64. I have the crash file in /var/crash. Any tool to extract the core out of it?
[11:21] <lool> amitk: apport-cli should get you a bt
[11:21] <amitk> mvo_: sudo apt-get blah works fine. So probably not sudo.
[11:21] <pitti> lool: I demoted elisa-plugins-bad to universe for now; it pulls in tons and tons of stuff
[11:21] <mvo_> amitk: update-notifier should have poped up a notifciaton about the crash, but apport-cli will do
[11:21] <pitti> lool: if that's wrong, let's discuss that in a bit (I have a phone call now)
[11:21] <mvo_> apport-cli -c /var/crash/crashfile iirc
[11:22] <NCommander> amitk, building in my PPA to confirm success, and then I'll have a patch for you
[11:22] <lool> pitti: It needs to stay with elisa
[11:22] <lool> pitti: Perhaps we can demote some of its deps, but not -plugins-bad as a whole
[11:22] <pitti> lool: ok, promoted back
[11:23] <pitti> lool: at least the -ugly recommends needs to be dropped then
[11:23] <lool> (or we can perhaps split it)
[11:23] <lool> pitti: Sure
[11:23] <pitti> lool: and gstreamer0.10-ffmpeg, too
[11:23] <lool> pitti: Will look after lunch
[11:23]  * lool disappears
[11:23] <pitti> lool: libvisual-plugins -> MIR or drop recommends?
[11:24] <popey> emgent: yes
[11:26] <amitk> mvo_: https://pastebin.canonical.com/10309/ <-- top part of apport report. I think this bug is already in LP, let me find it
[11:27] <mvo_> amitk: https://bugs.edge.launchpad.net/ubuntu/+source/gksu/+bug/277189 ?
[11:28] <mvo_> amitk: could you still submit it via apport so that the retracer can do its work and produce a debug backtrace?
[11:28] <amitk> mvo_: sure
[11:29] <mvo_> amitk: and that happens for you without compiz, right?
[11:30] <mvo_> amitk: (I ask because that code should be run only if compiz is available)
[11:30] <mvo_> amitk: what video card/driver do you use?
[11:30] <StevenK> NCommander: I'm back, I was eating
[11:30] <NCommander> StevenK, success
[11:30] <StevenK> \o/
[11:30] <NCommander> StevenK, the headers came out properly
[11:30]  * NCommander is doing one final build run to confirm success
[11:31] <StevenK> NCommander: Won't that build run take another hour?
[11:31] <NCommander> I caught a minor bug which I corrected, but I don't want anything to land in the tree until I'm absolutely sure I'm not going to hose a build ;-)
[11:31] <NCommander> StevenK, not with -j4 and ccache
[11:31] <StevenK> Heh
[11:31] <NCommander> amitk & StevenK: http://paste.ubuntu.com/58754/ - current diff. If it looks ok to you, I'll put it in proper patch format and send it to ubuntu-kernel@l.u.c
[11:31]  * NCommander realizes he's going to get that long awaited upload to restricted by fixing lpia lrm
[11:32] <StevenK> NCommander: Actually, it's lpia-linux-restricted-modules
[11:32] <NCommander> StevenK, yeah, lpia lrm :-)
[11:32]  * NCommander is just lazy to type out the whole thing
[11:32] <amitk> mvo_: https://bugs.edge.launchpad.net/ubuntu/+source/gksu/+bug/284894 , intel graphics. I'll attached details to the bug
[11:32] <NCommander> oh
[11:32] <NCommander> you mean in the changelog
[11:32] <NCommander> d'oh
[11:33] <StevenK> NCommander: Right.
[11:33] <StevenK> amitk: If you're okay with me sponsoring NCommander's work, I'm happy to do so.
[11:33] <NCommander> I"ll correct that when I make a patch that can land in the tree
[11:33] <mvo_> amitk: hm, could you make the bug public please? I can not access it it seems
[11:33] <StevenK> NCommander: s/autobuilder/buildd/
[11:34] <StevenK> NCommander: And the reason should be "this allows linux-headers-2.6.27-4 to use it's own headers, rather than the ones provided by the linux source package" rather than "this allows linux-lpia-meta
[11:34] <StevenK> ... and linux-lpia-restrict-modules to exist and work correctly"
[11:35] <NCommander> ok
[11:35] <StevenK> Er, linux-headers-2.6.27-ABI-lpia
[11:35]  * NCommander edits the changelog
[11:35] <StevenK> NCommander: Besides, the kernel is in main
[11:35] <StevenK> linux-lpia-meta is in restricted
[11:35] <NCommander> er, wait, what?
[11:35] <NCommander> Yeah
[11:35] <StevenK> NCommander: "You looz"
[11:36] <mvo_> MacSlow: could you please have a look at this crash http://launchpadlibrarian.net/18001582/Stacktrace.txt ? it seems to be in the blur patch for the gksu dialog
[11:36] <amitk> mvo_: interesting why it became private. Try now.
[11:36]  * NCommander figures out how to write the new changelog ;-)
[11:37] <mvo_> amitk: excellent, thanks
[11:37] <StevenK> NCommander: If you write in lol-speak, I'll steal your upload. :-P
[11:37] <NCommander> lol-speak?
[11:37] <NCommander> ack, THAT's evil
[11:37] <StevenK> Haha
[11:38] <mvo_> amitk: could you (just for the fun of it) enable compiz and run "gksu id" again? does it crash than too?
[11:38] <NCommander> StevenK, see PM
[11:39] <amitk> StevenK: let me look at it real quick. And I have no issues with you sponsoring him.
[11:40] <NCommander> amitk, maybe this is a stupid question, but shouldn't the Signed-off-by: flag only be done by people who are ubuntu kernel team members, and not by the patch submittor?
[11:40] <StevenK> amitk: It seems NCommander will feed you a git diff
[11:40] <NCommander> *submitter
[11:42] <amitk> NCommander: StevenK: diff looks ok to me except the ~ppa in the version.
[11:43] <NCommander> amitk, that's gone for now just because I was uploading it to my PPA :-)
[11:43] <amitk> NCommander: no, signed off is from anybody who does the work. I can append my sign-off saying I have reviewed it.
[11:43] <StevenK> NCommander: I'd prefer it just go to the archive
[11:43] <NCommander> amitk, oh I see. So commit locally, run git commit with the right message, then git format-patch and send it where specifically?
[11:44]  * NCommander is learning fast
[11:44] <NCommander> StevenK, any changes to the kernel need to land in git first AFAIK.
[11:44] <NCommander> StevenK, and I'm just always a tad paranoid when touching the kernel ;-)
[11:44] <StevenK> NCommander: They do not.
[11:44]  * StevenK has broken that rule
[11:45]  * NCommander would think thats bad practice then :-/
[11:45] <NCommander> hola emgent
[11:45] <amitk> NCommander: you have the correct sequence
[11:46]  * NCommander waits for his build run to finish so I can do extactly that ;-)
[11:48] <StevenK> pitti: How does c-m look now?
[11:48] <NCommander> amitk, I assume linux-lpia-meta needs to be fixed next, right?
[11:49] <StevenK> No
[11:49] <StevenK> lpia-lrm needs to build next
[11:49] <NCommander> restricted-modules then?
[11:49] <NCommander> ah, ok
[11:49] <StevenK> There's already a linux-lpia-meta upload, too
[11:49] <StevenK> So after I sponsor you, I get to fix the rest
[11:49] <NCommander> StevenK, that might need to be changed because of the changes in the headers package names
[11:50] <NCommander> StevenK, you sure you want to fix the lrm package?
[11:50] <StevenK> NCommander: As long as you fixed linux-headers-2.6.27-4-lpia Depends, lpia-lrm shouldn't
[11:50]  * NCommander won't mind getting more experience in this respect in
[11:50] <NCommander> StevenK, its linux-lpia-headers now
[11:50] <NCommander> (might not be strictly necessary, but that puts it in line with -ports, which does the same thing)
[11:50] <StevenK> NCommander: Right. Only -4$ should change
[11:51] <StevenK> Beh
[11:51] <NCommander> Er, its linux-lpia-headers-2.6.27-4-$FLAVOR
[11:51] <StevenK> Grumble
[11:51] <StevenK> I like that less
[11:51] <StevenK> Then lpia is in it twice
[11:51] <NCommander> amitk, which way should be it set
[11:52] <ogra> cant we drop $FLAVOUR altogether from it ?
[11:52] <NCommander> ogra, probably the lpia flavor should become generic
[11:52] <NCommander> i.e. linux-lpia-headers-2.6.27-4-generic
[11:52] <ogra> heh, fun
[11:52] <NCommander> It's only -lpia because it used to be built out of the main source package
[11:53] <NCommander> oh wait
[11:53] <NCommander> We can't do that
[11:53] <NCommander> wait
[11:53] <NCommander> we can
[11:53] <StevenK> Argh
[11:53] <ogra> heh
[11:53] <amitk> my head hurts
[11:53] <StevenK> NCommander: Stop breaking the world!
[11:53] <NCommander> :-)
[11:53]  * ogra doesnt mind, as long as he fixes it again
[11:53]  * NCommander forgot you can have the same package name from multiple source packages as long as there are no collisions
[11:54] <StevenK> NCommander: I'd rather it stayed with 'linux-headers-2.6.27-<ABI>-<FLAVOUR>' which Depends on linux-lpia-headers-2.6.27-4
[11:54] <StevenK> Er, linux-lpia-headers-2.6.27-<ABI>
[11:54] <NCommander> There is still a provides linux-headers
[11:54] <NCommander> and linux-headers-$version
[11:54] <NCommander> (and 2.6)
[11:54] <StevenK> That way doesn't involve an upload of lrm, fix it.
[11:55] <NCommander> Well, the problem I have is the linux-headers package is arch all
[11:55] <mvo_> amitk: could you please run "python -c 'import gtk.gdk; print gtk.gdk.display_get_default().get_default_screen().is_composited()'" ?
[11:55] <StevenK> linux-headers-2.6.27-<ABI>-<FLAVOUR> isn't Arch: all
[11:55] <StevenK> linux-lpia-headers-2.6.27-<ABI> won't be either
[11:56] <NCommander> amitk, so you agree with StevenK that it shouldn't be linux-lpia-headers?
[11:56] <StevenK> NCommander: Half of them shouldn't be linux-lpia-headers
[11:56]  * NCommander notes his diff gets a hell of a lot smaller then
[11:56] <NCommander> StevenK, er, what?
[11:56] <StevenK> NCommander: It should stay for the package that ends with -<ABI> but not the -<ABI>-<FLAVOUR> packages
[11:57] <amitk> NCommander: not being linux-lpia-headers would bring it more in line with the rest of the kernel packages
[11:57] <NCommander> Oh
[11:57] <NCommander> OH
[11:57] <NCommander> I get that
[11:57] <NCommander> That makes perfect sense
[11:57] <NCommander> :-)
[11:58] <StevenK> It should make the diff smaller, too
[11:58] <amitk> mvo_: Just tried enabling compiz, it was refused for my graphics chip
[11:58] <NCommander> StevenK, not really, I need to make additional rules changes to make this fly, there is an assumption on the header package name being consistent
[11:59] <NCommander> Ok
[11:59] <NCommander> Now to test build :-)
[11:59] <amitk> mvo_: interestingly, your python script returns "True"
[12:00]  * NCommander notes someone should bump the standards version
[12:00] <NCommander> 3.6.1 is old!
[12:03] <NCommander> amitk-lunch, how do I undo a commit?
[12:04]  * NCommander discovered gedit should not be used as EDITOR when dealing with git
[12:04] <StevenK> Haha
[12:04] <StevenK> git uncommit ?
[12:05] <amitk-lunch> git reset --soft HEAD^
[12:05] <highvoltage> heh
[12:06] <pitti> StevenK: a bit better, but elisa is still wreaking a lot of havoc; I'm back from my phone call, I'll continue to attack it now
[12:06] <pitti> there's a plethora of perl modules which want to get in, too, untangling this will take a while
[12:07] <NCommander> THat didn't work
[12:07] <NCommander> bah
[12:07]  * NCommander saved a diff
[12:07]  * NCommander blows away his branch and reclones
[12:11] <NCommander> Git feels like RPM. You can shoot your foot off, then spend the next week figuring out how to reattach it
[12:12] <Mithrandir> amitk-lunch: or just git commit --amend
[12:15]  * NCommander has already rebuilt the git tree in the time it would take to figure that out ;-)
[12:20] <NCommander> amitk-lunch, I got a patch for you when your back
[12:27] <StevenK> NCommander: Can I see the new diff?
[12:28] <StevenK> pitti: I note bug 221844 looks like what I am seeing
[12:32] <mvo_> amitk-lunch: thanks, I was suspecting this
[12:33] <amitk-lunch> Mithrandir: git commit --amend doesn't help if you want to remove some stuff from the existing commit AFAIK.
[12:33] <amitk> NCommander: shoot
[12:40] <cjwatson> asac: have you gone through all the possible NM regressions listed in http://people.ubuntu.com/~sbeattie/regression_tracker.html?
[12:41] <cjwatson> asac: there aren't lots, but some of them are still New/Undecided
[12:44]  * NCommander returns with coffee :-)
[12:44] <NCommander> StevenK & amitk http://paste.ubuntu.com/58771/
[12:46] <StevenK> NCommander: Stop saying linux-lpia-headers-* in the Description
[12:46] <StevenK> That is my complaint. If it builds, I'm good
[12:46] <StevenK> My only complaint
[12:47] <NCommander> You said that changelog entry was good!
[12:47] <amitk> frozen browser...
[12:47] <NCommander> :-P!
[12:47] <StevenK> NCommander: That's the Description
[12:47] <StevenK> NCommander: The changelog entry is fine
[12:47] <emgent> heya NCommander
[12:47] <emgent> sorry for delay..
[12:47] <NCommander> Morning emgent
[12:48] <NCommander> emgent, no problem, I just got a crash course in kernel hacking, and for some strange reasoning fixing linux-lpia ... :-)
[12:48] <emgent> hehe
[12:50] <StevenK> NCommander: Description of packages != changelog entry
[12:50] <NCommander> StevenK, ok, ok, point taken!
[12:50]  * NCommander will give you a revised patch once I confirm the rules build properly
[12:51] <mvo_> amitk: is there anything special in your /etc/X11/xorg.conf ? sorry for asking so many questions, but I wonder what might cause that you get the is_composited = true
[12:51] <amitk> NCommander: so you haven't tested this yet?
[12:52] <NCommander> amitk, I had to make one additional change to rules which is in the patch, its still building
[12:52] <NCommander> SOrry if that wasn't clear
[12:53] <asac> cjwatson: no. will go through this afternoon. thanks. actually havent used that site :/
[12:53] <amitk> mvo_: https://pastebin.canonical.com/10311/ xorg.conf, glad to help track this down.
[12:53] <amitk> NCommander: ack
[12:56] <NCommander> amitk, I need to change the package description in the control files, but the stuff that actually changes stuff is fine as is.
[12:56] <StevenK> NCommander: It builds correctly?
[12:58] <NCommander> Still building
[12:59] <fta> seb128, pitti, i'm having a problem with the last nspluginwrapper i pushed 2 days ago. it's supposed to build "Architecture: amd64 i386", yet, only the amd64 deb has been produced, seems i386 was just ignored. See https://edge.launchpad.net/ubuntu/intrepid/+builds?build_text=nspluginwrapper&build_state=all and https://edge.launchpad.net/ubuntu/+source/nspluginwrapper/+publishinghistory#  Any idea why?
[13:00] <pitti> fta: I bet it's in P-a-s
[13:01] <pitti> %nspluginwrapper: amd64      # 64-bit wrapper for 32-bit i386 plugins
[13:01] <pitti> fta: can you please talk to lamont or infinity? They can fix that, if the package actually makes sense on i386
[13:01] <fta> now it does
[13:02] <fta> the previous version was already on 64 + 32
[13:02] <NCommander> pitti, nspluginwrapper can prevent firefox from crashing if flash hangs
[13:02] <directhex> what's the use-case for it on i386? i don't get it :|
[13:02] <NCommander> pitti, so there is some point to having it on i386
[13:02] <directhex> nspluginwrapper is doom. we hatses it. why would you use it if you had the option not to?
[13:03] <lool> pitti: Pas was borken two days ago
[13:03] <lool> After the move to cocoplum
[13:03] <NCommander> who broke P-a-s?!
[13:03] <ogra> asac, midbrowser doesnt pick up the gnome proxy settings (i guess thats by design since it wasnt built for gnome), can you point me to the area where to look in FF to make that hapen ?
[13:03] <ScottK> pitti: Here now if it's still relevant.
[13:03] <lool> Bug #283731
[13:03] <lool> (bug title is wrong, it was Pas missing from cocoplum entirely)
[13:03] <pitti> ScottK: sorted out now, thanks
[13:03] <ogra> asac, or would that be a heavy patch to midbrowser ?
[13:05] <fta> lool, pitti: so, if it's fixed, how can i force the build? bump and repush? or ask an lp admin ? or what?
[13:06] <NCommander> amitk, waiting for the kernel to build sucks
[13:06] <lool> fta: You're saying nspluginwrapper should be built on more than amd64?
[13:06] <pitti> fta: it's not fixed yet, P-a-s says "just amd64"
[13:06] <pitti> see my copy&paste above
[13:06] <lool> Now the Pas entry needs fixing
[13:07] <fta> lool, yes, it was before too, no reason to stop.
[13:07] <lool> You need to mail lamont + elmo + infinity to ask for the addition on other arches
[13:07] <fta> pitti, ok, i'll ask. thanks
[13:08] <lool> fta: Sent you list of email addresses in query
[13:09] <fta> lool, thanks
[13:10] <amitk> NCommander: story of my life :) Though I do have slightly faster machines.
[13:10] <lool> pitti: I'll try testing elisa without the packages you hinted at in a sec
[13:10] <lool> If I get it working on ati r500
[13:10] <NCommander> amitk, it reminds me of xkcd
[13:10] <lool> Otherwise, it will have to wait that I get back home
[13:10] <pitti> lool: promoting some harmless packages is fine, too, but some are tricky
[13:10] <pitti> lool: merci
[13:10] <lool> gstreamer0.10-ffmpeg obviously isn't possible
[13:11] <seb128> lool: why?
[13:11] <lool> Doesn't it pull ffmpeg libs which we don't want?
[13:12] <lool> pitti: In general, elisa isn't trivial because it's huge python import hub
[13:12] <seb128> lool: the ffmpeg source is in main apparently
[13:12] <lool> seb128: Ok; I know it's handled very specially
[13:13] <lool> Indeed libavcodec51 is in main, so it wouldn't be a problem to promote gstreamer0.10-ffmpeg due to ffmpeg I'd guess
[13:14] <lool> the dep was added for 0.5 by Phil
[13:15] <lool> seb128: Promoting gstreamer0.10-ffmpeg to main seems risky in terms of codec installation though
[13:16] <lool> It provides many codecs, and I'm not sure I'd be confortable making the list visible to users at this point of the cycle
[13:16] <ogra> Keybuk, do you plan to revisit https://wiki.ubuntu.com/DesktopTeam/Specs/Prefetch for intrepid ? (and are you aware of sreadahead ? http://www.moblin.org/downloads/super-read-ahead-002) ...
[13:16]  * ogra was asked that by some mobile community people yesterday
[13:16] <ogra> err
[13:16] <ogra> s/intrepid/jaunty/
[13:16] <seb128> lool: right, I just know slomo asked why ffmpeg was in main and not gst-ffmpeg this week and I was not sure if there was a good reason
[13:16] <Keybuk> Some amount of revisiting prefetch/readahead/etc. is definitely on the cards
[13:16] <ogra> great
[13:17] <ogra> thats what i thought
[13:17] <ogra> but wanted sure i didnt talk rubbish
[13:17] <ogra> +make
[13:17] <Keybuk> the biggest problem with jaunty is going to be prioritising
[13:17] <lool> seb128: There's an interesting problem that the package faces: it supports more codecs than advertized via it's headers when it's used with the multiverse libs
[13:17] <ogra> yeah
[13:17] <lool> I'll mention to slomo
[13:18] <lool> ogra: sreadahead is being itped in Debian IIRC
[13:19] <lool> debian #502121
[13:20] <lool> I wonder how the next readahead with additional features will be called -- hreadahead?
[13:20] <directhex> sreadahead++
[13:21] <lool> Or MiReadAhead
[13:21] <pitti> mvo_: u-n will only start for UID >= 500? (it says 'make sure to not run for guest')
[13:21] <ogra> extra-readahead :)
[13:21] <ogra> uber-readahead
[13:21] <pitti> lool: skimahead
[13:21] <lool> -ng
[13:21] <directhex> of course, doesn't readahead violate microsoft's superfetch patents? :O
[13:21]  * lool scratches-head
[13:21] <Keybuk> directhex: what patents?
[13:21]  * Keybuk never investigates such things
[13:21] <lool> patents to read from files before using them!
[13:21] <Keybuk> which means I don't know about them
[13:22] <Keybuk> which is a valid defence
[13:22] <cjwatson> wise advice for programmer
[13:22] <cjwatson> s
[13:23] <NCommander> Keybuk, it's not a complete defense
[13:23] <cjwatson> NCommander: it's a defence against punitive damages
[13:23] <NCommander> Keybuk, it just means that you'll be hit with lesser max charges
[13:23] <cjwatson> AIUI
[13:23] <cjwatson> which isn't to be sneezed at
[13:23] <NCommander> cjwatson, you can still be hit with charges, just to a lesser extent
[13:23] <NCommander> */criminal justice student*
[13:23] <cjwatson> yes, that's what I said
[13:23] <NCommander> oh
[13:23] <NCommander> Hrm
[13:23] <directhex> actually, seems every bugger has a prefetch patent. ibm, sun, hp...
[13:24] <cjwatson> or triple damages, or whatever they're called in your jurisdiction
[13:24] <directhex> dec
[13:24] <NCommander> I won't be suprised if someone had a patent on breathing
[13:24] <pitti> NCommander: yes, Darth Vader
[13:24] <Keybuk> if they don't, I think I'll register one ;)
[13:24] <lool> NCommander: Make sure you check before your next breath
[13:24] <ogra> check *fast* though :)
[13:25] <Keybuk> a friend of mine once tried to patent entry of text onto a computer screen through use of a mechanical input device
[13:25] <lool> haha
[13:25] <Keybuk> it only got rejected because a patent already existed
[13:25] <amitk> NCommander: http://www.freepatentsonline.com/5685292.html luckily it is free :)
[13:26] <pitti> seb128: deskbar-applet recommends python-soappy; however, that's in universe and it explicitly says it's deprecated and not maintained any more
[13:26] <pitti> seb128: it also pulls in python-fpconst, but that's a no-ob
[13:27] <NCommander> Keybuk, that's wrong
[13:29] <asac> ogra: hmm
[13:29] <seb128> pitti: no clue about those, that comes from debian, I guess it's alright to just not recommends those or change to a suggest
[13:29] <asac> ogra: in the past we maintained a fork for xulrunner in mobile
[13:29] <asac> ogra: the question is, whether you really need "gconf" integration ... or if the env http_proxy... support is enough
[13:29] <pitti> seb128: ok
[13:30] <pitti> seb128: doing another gnome-games upload, FYI
[13:30] <pitti> seb128: (ok for you?)
[13:30] <StevenK> NCommander: Is the kernel still building?
[13:30] <asac> ogra: if you need gconf integration we need to do a mobile specific xul build again ... unfortunately
[13:30] <NCommander> StevenK, yes
[13:30] <seb128> pitti: yes, I'm not working on any package right now so feel free to do any desktop upload
[13:30] <asac> ogra: so let me know ;)
[13:30] <pitti> seb128: roger
[13:31] <lool> asac: Sorry, didn't have time to work on tihs
[13:31] <mvo_> pitti: yes, that is modelled after the gdm-guest-session, I added the same checks in u-m as you did in the guest session
[13:31] <StevenK> asac: You can't enable gconf for everything?
[13:31] <lool> asac: I prefer we live without; we have no place for forks anymore, nor do we want to live with non-Ubuntu bits
[13:31] <asac> StevenK: no, simply because upstream doesnt want that (YET)
[13:31] <ogra> asac, well, -mobile uses standard packages and the generic arch
[13:31] <lool> "ubuntu4ever"
[13:31] <pitti> mvo_: ok, thanks; seems we don't have much choice about it anyway, I'll wave it through now; after it's built, can you please mail u-devel@ about a call for testing?
[13:31] <asac> ogra: right.
[13:31] <mvo_> pitti: sure, thanks
[13:32] <lool> StevenK: It needs to be moved as an extension, it can't be in libxul
[13:32] <asac> ogra: so ... it should support the "normal" mechanism that picks the proxies from environment
[13:32] <apachelogger> james_w: hey, are there concrete plans for a migration to bzr based development?
[13:32] <ogra> asac, so thats set in xul, not in the frontend, i see
[13:32] <lool> It shouldn't be too hard to move it, if I recall asac's instructions, just ENOTIME
[13:32] <ogra> asac, i'll have to ask ian_brasil about it then
[13:32] <asac> ogra: xul has to provide the backend capability
[13:32] <ogra> asac, btw, ubuntu ?
[13:32] <asac> ogra: midbrowser has to select the default it wants
[13:32] <ogra> *ubucon
[13:32] <ogra> heh
[13:32] <james_w> apachelogger: yeah, though the concrete is just being poured
[13:33] <asac> ogra: most likely that default is currently gconf -> which means that it doesnt work
[13:33] <james_w> apachelogger: is there something you want to know specifically, or you are just interested?
[13:33] <ogra> asac, well, gconf means gnome setting, no ?
[13:33] <ogra> so that should work
[13:33] <asac> lool: right. i didnt do it yet. ENOTIME is one reason... the other is that it dropped off my radar as noone complaine :/
[13:33] <lool> ogra: It doesn't because we don't have the xulrunner backend fo rit
[13:33] <ogra> i think the main prob is that you cant reach the midbrowser menu in mobile
[13:34] <asac> ogra: gconf means "perfect gnome setting"
[13:34] <apachelogger> james_w: if I can get the fellow Kubuntu dudes to agree, I'd like to move all core KDE packages to bzr in the jaunty cycle, does that make any sense?
[13:34] <ogra> so my guess was it would be best to just have it use the setting we have an UI for
[13:34] <asac> ogra: for instance apt or update-manager use the "env" either afaik
[13:34] <ogra> ah
[13:34] <asac> ogra: so its not midbrowser alone that would have a "not perfect" solution
[13:34] <ogra> right
[13:34] <lool> Right
[13:35] <lool> But if you set http_proxy, everybody should be happy
[13:35] <asac> but that gconf thing is nice
[13:35] <lool> Damn, just setup iptables!
[13:35] <lifeless> mvo_: so
[13:35] <ogra> lol
[13:35] <NCommander> apachelogger, no objections here
[13:35] <asac> if you edit proxy settings in gconf it will instantly update midbrowser and if you edit it in midbrowser it will update gconf ;)
[13:35] <james_w> apachelogger: yeah, we're aiming to have packages available in bzr for the opening of jaunty, but it doesn't look like we'll be able to put them on launchpad for a little while, so they will be read-only to start with.
[13:35]  * ogra tries 
[13:35] <asac> lool: yes. but i think we have to switch the default proxy setting still
[13:36] <asac> e.g. midbrowser currently has "gconf" as proxy method
[13:36] <asac> and it should be "system2
[13:36] <james_w> apachelogger: but they will be kept up-to-date from uploads to the archive.
[13:36] <lool> asac: We should do that now; doesn't sound long to do; it's still in git at moblin?
[13:36] <james_w> apachelogger: and Debian won't be available, which means you won't be able to merge from there yet.
[13:37] <lool> asac: (are you working with moblin people?)
[13:37] <asac> lool: its just a one line patch
[13:37] <lool> Yeah
[13:37] <james_w> apachelogger: but we can work around these issues if you want to go for it.
[13:37] <asac> lool: well. midbrowser is in maintenance mode. just basic communication is still done with them
[13:37] <lool> asac: Would you have the time to push that fto git and intrepid?
[13:37] <ogra> hey, it works perfectly with the gnome capplet
[13:37] <lool> asac: Ok; I wondered about midbrowser for moblin 2
[13:38] <asac> ogra: what does midbrowser have for network.proxy.type
[13:38]  * ogra will keep quiet in the future before he complains
[13:38] <asac> lool: most likely everything will go for fennec ... which we should do to in the next cycle i guess
[13:38] <sdschwarz> Hi! I've got a question about usb-creator: When creating space for persistency, does it make a casper-rw file or a casper-rw partition?
[13:38] <ogra> all persia's fault
[13:38] <NCommander> StevenK, its almost done building
[13:38] <StevenK> \o/
[13:38] <persia> ogra, What?
[13:39] <ogra> asac, 5
[13:39] <ogra> persia, proxy works fine if you use the gnome proxy applet to set it
[13:39] <asac> ogra: ok so it works?
[13:40] <persia> ogra, Right.  That's not in -mid.
[13:40] <apachelogger> james_w: sounds good :) I'll add the topic to a Kubuntu meeting and contact you to find a date/time, so you can attend
[13:40] <james_w> apachelogger: great, I'd be happy to
[13:40] <mvo_> lifeless: so?
[13:40] <ogra> asac, if i use "apply systemwide" at least, i didnt try it differently yet
[13:41] <ogra> asac, but there is a way to make it work, so nothing i need to look deeper into for mobile at least ... no idea about mid though
[13:42] <lifeless> mvo_: conflict finder
[13:42] <lifeless> mvo_: I see you changed the error :P
[13:43] <lifeless> mvo_: I haven't had time to dig
[13:43] <asac> ogra: ok. but changes dont apply instantly right? e.g. you still have to relogin
[13:43] <pitti> Riddell: koffice-i18n-engb (main) currently recommends kde-i18n-engb (universe); what's the best course to fix that?
[13:43] <ogra> no, works i get a direct complaint that the proxy is unreachable in midbrowser
[13:43] <lifeless> pitti: I suggest a patch and an upload
[13:43] <ogra> looks perfect to me
[13:43] <lifeless> :>
[13:44] <Riddell> pitti: make it recommend language-pack-kde-en I guess
[13:44] <pitti> Riddell: I wondered whether koffice-i18n-engb actually makes sense in main
[13:44] <apachelogger> Riddell: wouldn't that be the KDE 4 translation?
[13:44] <pitti> Riddell: isn't it just stripped and thus completely empty?
[13:44] <pitti> lifeless: well, in this situation it's not actually obvious
[13:44] <Riddell> pitti: it has to be in main so launchpad extracts the files from it (same as k3b-i18n)
[13:44] <lifeless> pitti: its 2345 here, I was being entirely silly
[13:45]  * pitti hugs lifeless
[13:45]  * lifeless hugs back
[13:45] <Riddell> apachelogger: it should be all translations in kubuntu intrepid
[13:45] <pitti> Riddell: hm, then I wonder why kde-i18n-engb isn't actually in main; it should be stripped and moved to langpacks, too?
[13:45] <zul> pitti: is  it nagios-plugins having problems?
[13:45] <Riddell> pitti: it's not used not, that's the KDE 3 one
[13:45] <Riddell> pitti: it's not used now, that's the KDE 3 one
[13:46] <pitti> zul: nagios-plugins-extra pulls in fping, nagios3-common pulls in nagios-images; just search for "nagios" on the URL
[13:46] <apachelogger> *cough* used in KDE 3 apps
[13:46] <pitti> Riddell: ah, ok; then the changed dep makes sense; shall I just uplaod that?
[13:46] <Riddell> pitti: yes please
[13:46] <Riddell> apachelogger: only universe ones
[13:46] <pitti> zul: and -extra wants qstat, too
[13:47] <apachelogger> ok
[13:47] <pitti> zul: should -extra actually be promoted to main? (isn't now)
[13:47] <cjwatson> sdschwarz: a file
[13:48] <zul> pitti: we had this problem in hardy as well, I dont think -extra needs to be in main Im not sure what nagios-images is gimme a minute
[13:48] <pitti> zul: or nagios-plugins? (both that and -extra are in universe ATM)
[13:48] <pitti> zul: ah, nagios3-common (main) Recommends: nagios-plugins (universe); that's probably what should be changed?
[13:48] <zul> to a suggests?
[13:49] <pitti> zul: if you don't actually want the plugins in main, then yes
[13:49] <mvo_> lifeless: I have some code in my branch that mostly makes it work, but the remaing issue is the one where strom complains, I think I sent you the error message some days go
[13:49] <pitti> zul: if you do, we need some MIRs or dependnecy changes for fping and qstat
[13:49] <lifeless> mvo_: oh
[13:49] <zul> nagios-plugins should be in main nagios-plugins-extra shouldnt (because of fping etc)
[13:50] <apachelogger> ogra: what is the difference between ubuntu-mobile and ubuntu-mid?
[13:50] <pitti> zul: and the -images thing is an entirely separate problem
[13:50] <lifeless> mvo_: uhm, can you send it to me again, evolution-fail
[13:50] <mvo_> lifeless: its not merged into the production tree yet, I didn't want to break anything
[13:50] <zul> pitti: yeah I didnt handle nagios this time around so Im not quite sure what that is
[13:50] <mvo_> (harder)
[13:50] <lifeless> :P
[13:50] <pitti> zul: ok, then plugin can't depend: plugin-extra
[13:50] <zul> pitti: yep
[13:50] <ogra> apachelogger, https://wiki.ubuntu.com/MobileTeam/Mobile/History
[13:50] <persia> apachelogger, ubuntu-mobile is based on GNOME, and loosely designed for 7-9" screeens (although it has been used on larger and smaller).  Ubuntu MID is based on hildon, and loosely designed for 4-6" screens (although it also has been used on different sizes).
[13:50] <NCommander> amitk, note to self, figure out a better way to hook up pbuilder and ccache :-)
[13:51] <pitti> zul: who in the server team can I bother about nagios then? (or will you pass it on?)
[13:51] <mvo_> lifeless: this is the error from my branch https://pastebin.canonical.com/9716/
[13:51] <zul> pitti: Koon but he isnt here today afaik
[13:51] <zul> im dealing with it now though
[13:51] <lifeless> mvo_: its trying to insert something it already has, or thinks it has
[13:52] <zul> pitti: what we did for hardy was to split off nagios-plugins-extra for its own package
[13:52] <lifeless> mvo_: is that testing on your machine, the test suite, or trying to run it live ?
[13:52] <apachelogger> ogra, persia: so basically -mid is the better mobile desktop?
[13:52] <pitti> Riddell: hm, that looks curious; all koffice-i18n-* are in universe, except koffice-i18n-engb; I guess it is the one main package which keeps the entire source in main and thus translation-stripped
[13:52] <mvo_> lifeless: running it life with a copy of the database
[13:52] <ogra> apachelogger, no
[13:52] <mvo_> lifeless: (in my homedir)
[13:52] <pitti> zul: aah
[13:52] <persia> apachelogger, Nope.  They are different, and meet different use cases.
[13:52] <zul> pitti: so I will do that now :)
[13:52] <pitti> zul: thanks
[13:52] <persia> apachelogger, join #ubuntu-mobile, and we can discuss in depth.
[13:53] <lifeless> mvo_: we need to trap the failing data, and then confirm that a) it is a dupe, and b) why
[13:53] <pitti> zul: so, the -extra dependency and look what -images does (promote or drop dependency)
[13:53] <ogra> apachelogger, mid is better for devices you carry in your pocket usually, mobile rther targets UMPCs
[13:53] <zul> pitti: sounds like a plan :)
[13:53] <pitti> zul: I promoted nagios-plugins to main; let me know about -images
[13:53] <pitti> zul: great, thanks!
[13:54] <zul> pitti: do we still have to do the MIR if we want nagios-images in main as well?
[13:54] <pitti> zul: no, it's from a source already in main
[13:54] <pitti> zul: just make sure it's sane and something we want
[13:55] <zul> k
[13:55] <mvo_> amitk: I uploaded a new libgksu (macslow fixed it) - please let me know if that fixes the issue for you, it should be available in ~1-2h if its not in unapproved for too long
[13:55] <lool> pitti: Sorry, elisa on ati r500 is too slow; I could setup fglrx, but prefer testing on intel this we or next week to confirm whether libvisual is fine
[13:55] <Riddell> pitti: not a very elegant solution but it works
[13:55] <lool> (it's demotion)
[13:55] <lool> demoting -ffmpeg is fine, it's only to enable more formats
[13:55] <amitk> mvo_: thanks
[13:56] <mvo_> lifeless: right, let me add something so that is prints what it add
[13:56] <pitti> Riddell: yeah, I know; koffice-l10n upload prepared
[13:57] <pitti> Riddell: kpovmodeler -- remove from Kubuntu.Intrepid dvd seed or promote?
[13:58] <NCommander> StevenK, it's almost done building
[13:58] <lool> pitti: pushed -bad demoting -ffmpeg for now
[13:58] <Riddell> pitti: hmm, let me install and see how well it works
[13:59] <lool> I know that libvisual is used for visualization, and I think there's an alternate renderer, but need to try out without to see how it looks
[13:59] <StevenK> NCommander: You said that before
[13:59] <pitti> lool: right, was just going to ask
[13:59] <NCommander> StevenK, its in the install phase :-)
[13:59] <lifeless> StevenK: only another day or so
[13:59] <rainct> Uhm.. Rhythmbox on Intrepid crashes with "(rhythmbox:6703): GLib-GIO-CRITICAL **: g_file_get_uri: assertion `G_IS_FILE (file)' failed" each time I try to import my complete audio library..
[13:59] <Riddell> pitti: works for me, promote?
[14:00] <lool> rainct: isolate the culprit and file a bug with a test case please
[14:00] <pitti> lool: oh argh, soyuz ate the binaries of -plugins-bad (demotion/promotion in the same run, it doesn't seem to like that)
[14:00] <pitti> Riddell: ack
[14:00] <lool> rainct: You can rhythmbox -d to see what it's doing
[14:00] <lool> or strace if all fails
[14:00] <pitti> lool: so we now need a -bad upload anyway :/
[14:00] <lool> pitti: We might promote visual?
[14:00] <pitti> Riddell: done
[14:00] <pitti> lool: yes, if libvisual is sane, ok for me
[14:01] <lool> But I prefer not promoting it at this point if possible
[14:01] <lool> So will test and report
[14:01] <pitti> lool: do you still have hte old c-m page? the current one has all of elisa dropped due to the binaries going to oblivion
[14:01] <lool> if it's ugly, will review or file a MIR
[14:01] <lool> c-m?
[14:01] <pitti> lool: promoting a sane package is less intrusive than ripping apart the package
[14:01] <pitti> lool: component-mismatches.txt
[14:02] <lool> No, it's not in my cache anymore
[14:03] <lifeless> gnight
[14:03] <pitti> lool: ok, so let's sort out ffmpeg and libvisual (for both: either promote or drop recommends), and see later what remains
[14:03] <pitti> sleel well, lifeless
[14:03] <lifeless> mvo_: drop me mail if you would
[14:03] <lool> pitti: I dropped recommend on ffmpeg already
[14:03] <mvo_> lifeless: sure, will do
[14:04] <mvo_> lifeless: its rather late in your TZ, right?
[14:04] <lifeless> 0002
[14:04] <lifeless> so very early :P
[14:04] <mvo_> :P
[14:05] <NCommander> Oh ****, got to run
[14:07] <rainct> lool: ok, it crashes if there's a directory without execution permission
[14:07] <pitti> $ change-override.py -S -c main ubuntu-policy
[14:07] <pitti> oh dear, how could we have *not*? :-)
[14:08] <geser> Riddell: do you know if qyoto can be build with libsmokeqt4-2-dev? This would allow to kill the libqt4-ruby source package (it got merged into kde4bindings)
[14:08] <cjwatson> oh, that reminds me, I need to push current ubuntu-policy bzr to the archive
[14:08] <lool> rainct: Please look for an existing bug or file one :)
[14:08] <StevenK> pitti: Haha
[14:08] <pitti> cjwatson: if you do it now, it will fail to upload (no problem, we can give it back, just FYI)
[14:09] <rainct> lool: yep, I'm doing that right now :)
[14:09] <pitti> anyway, high time for lunch, bbl
[14:09] <lool> pitti: bon appétit
[14:09] <pitti> lool: merci Monsieur
[14:09] <cjwatson> pitti: yeah, I know
[14:09] <cjwatson> though thanks for the reminder :)
[14:10] <Riddell> geser: what does qyoto use currently?
[14:11] <geser> Riddell: it build-depends on libsmokeqt4-dev (build from libqt4-ruby)
[14:12] <Riddell> geser: I suspect it doesn't use that, qyoto is from kde4bindings so it should build with the smoke from kde4bindings
[14:14] <geser> Riddell: ah, I see now qyoto got also merged into kde4bindings
[14:14] <Riddell> yep
[14:14] <geser> so it can get removed to (the old qyoto source package)
[14:14] <directhex> it did. i'm talking to pusling about qyoto right now
[14:14]  * rainct created bug #284970
[14:15] <Riddell> directhex: for Debian?
[14:17] <geser> Riddell: should I reassign the old qyoto bugs to kde4bindings before filing a remove request for it?
[14:18] <Riddell> geser: ok
[14:18] <bugabundo_work> doko: ping
[14:18] <directhex> Riddell, aye
[14:18] <ScottK> geser: Bug reassinging can be done after it's removed.  It's not a prerequisite for the request.
[14:18] <jdong> tedg: what's the status on getting 278810 into Intrepid?
[14:19] <Riddell> geser: I can just remove it, no need for a request
[14:19] <doko> bugabundo_work: ?
[14:19] <bugabundo_work> doko: can you give a kick jump to #ubuntu+1 to answer the usual question if OOo will be in ibex? thanks
[14:19] <Riddell> don't we have a list of source packages that don't build any packages?  opposite of NBS
[14:19] <doko> OOo is in intrepid
[14:19] <bugabundo_work> sorry
[14:19] <bugabundo_work> OOo3
[14:19] <bugabundo_work> lol you knew that...
[14:20] <tedg> jdong: Needs release team approval.  I realized I didn't subscribe them... I can do that.
[14:20] <cjwatson> tedg: at this point, please upload before approval; it will be held in the queue
[14:20] <Riddell> geser: removed
[14:20] <bugabundo_work> doko: danbh_intrepid was the guy asking
[14:21] <jdong> tedg: ok, cool
[14:21] <doko> no
[14:21] <tedg> cjwatson: Well, I can't do that :)  If you'd like to sponsor it... ;)
[14:21] <cjwatson> well, I mean get somebody to upload before approval
[14:21] <tedg> cjwatson: Should I still subscribe the release team?
[14:21] <jdong> Keybuk: ^^ you were interested in bug 278810; can you upload? :)
[14:21] <geser> Riddell: can you also remove the libqt4-ruby source package?
[14:22] <Riddell> ok
[14:22] <Riddell> geser: gone
[14:22] <cjwatson> that's probably a good idea, I don't currently speak dbus well enough to review this
[14:22] <geser> Riddell: thanks
[14:22] <cjwatson> (I should ...)
[14:23] <tedg> DBus, ten times more useful than Esperanto.  :)
[14:28] <jdong> tedg: but DBus doesn't get you into the cool clubs on campus
[14:28] <jdong> it does get you strangled every time you non-sarcastically start a sentence with "I love how NetworkManager..."
[14:31] <nand> Hey!
[14:32] <Keybuk> looks reasonable
[14:32] <nand> I'm tracking down and updating the status of the latest "in development" ideas. Unfortunately some of them, I can't find out myself the status.
[14:32] <nand> Anyone knows about the status of https://wiki.ubuntu.com/KernelTeam/removing-old-kernels ?
[14:33] <ScottK> nand: I think the latest in development ideas this week is get Intrepid out the door.
[14:33] <nand> ScottK: Sorry, was not clear : I'm updating this list : http://brainstorm.ubuntu.com/ideas_being_worked_upon/
[14:37] <zul> pitti: ping (nagios-plugins) when you are back from lunch
[14:44] <directhex> okay, qyoto stuff is looking good
[14:45] <pitti> zul: pong
[14:46] <pitti> zul: oh, why did you split the source? just changing the dependencies would have been enough?
[14:47] <amitk> NCommander: still building?
[14:48] <gouki> Can anyone tell me where is the .xml file used to generate the menu entries in Gnome?
[14:49] <zul> pitti: keep it like it was in hardy
[14:50] <zul> pitti: anyways nagios-images should be ok in main as well is just a bunch of icons and images for the web frontend
[14:50] <persia> gouki, /etc/xdg/menus/
[14:50] <gouki> persia, thank you very much!
[14:50] <StevenK> amitk: It looks NCommander ran off
[14:50] <pitti> zul: yes, that sounds fine
[14:51] <amitk> StevenK: ouch!
[14:51] <pitti> zul: I just mean, wouldn't it be easier (and less delta to Debian) to just drop the -plugins depends: -plugins-extra instead of completely splitting the source?
[14:52] <zul> pitti: yeah it would have, can you reject it Ill upload it again
[14:52] <pitti> zul: sure
[14:52] <evand> seb128: Is System Tools an apporpriate menu location for usb-creator?
[14:53] <davmor2> evand: will it be in the default install or not?
[14:54] <pitti> zul: nagios-images promoted (trivial, and just a splitout from earlier package)
[14:54] <evand> davmor2: it will be
[14:55] <zul> pitti: thanks
[14:55] <persia> evand, There's been great effort in several previous releases to not put anything at all in system tools.  I'd recommend Accessories.
[14:55] <davmor2> evand: in that case do you really want another menu option on by default? Might be easier in System -> Administration along with thing like gparted etc...
[14:56] <persia> davmor2, Good point, as it requires root access.
[14:57] <evand> ah, will do
[14:58] <zul> pitti: uploaded
[14:59] <gouki> persia, any idea of how to find a specific entry? On a .ISO I built Evolution entry keeps getting created, even though the application isn't present on the OS.
[15:00] <persia> gouki, Check in /usr/share/applications/
[15:00] <gouki> persia, thank you.
[15:01] <persia> gouki, I highly recommend reading the desktop item and desktop menu specs at freedesktop.org.  I suspect they will answer your next question :)
[15:01] <gouki> persia, hehe. I will. Thank you for the help.
[15:16] <pitti> mvo_: what's the current status of bug 145360? (it's an outstanding TODO item from release meeting)
[15:22] <pitti> mvo_, tseliot: with the workaround in compiz for bug 269904, the nvidia task shouldn't be intrepid RC any more, right?
[15:24] <ScottK> slangasek: I will be late for the Release meeting today.  I have a kid pickup to do at the meeting start time, so I'll be there ~20 minutes late.
[15:24] <tseliot> pitti: mvo_ told me that he would have a look at the patch but I don't know if it can be included in the RC
[15:24] <pitti> tseliot: the compiz workaround mentioned in the bug is uploaded
[15:25] <tseliot> pitti: ah, nice
[15:25] <pitti> tseliot: so we can say "yes, it is a bug in nvidia, but we have a workaround, thus it's not RC"; does that sound right?
[15:26] <tseliot> pitti: AFAIK it's a bug in the xserver
[15:26] <tseliot> but it seems to affect nvidia users
[15:27] <tseliot> pitti: would it be a problem to include it in the RC?
[15:28] <pitti> tseliot: which? the only patch I see is http://launchpadlibrarian.net/18617329/049-damage-report-non-empty.patch, and as I already said, that is already uploaded
[15:29] <tseliot> pitti: aah, sorry, I've read your first question again and the answer is no, the nvidia task shouldn't be intrepid RC any more
[15:30] <cjwatson> tseliot: any idea what's happening to Brian Watson in bug 278963?
[15:31] <tseliot> let me check
[15:32] <tseliot> cjwatson: it's hard to tell without a Xorg.0.log
[15:32] <cjwatson> tseliot: could you ask him for one?
[15:32] <tseliot> sure
[15:33] <cjwatson> thanks
[15:33] <tseliot> but maybe the log is lost as we store only Xorg.0.log and Xorg.0.log.old
[15:33] <tseliot> I can ask him to try the upgrade again and post his Xorg.0.log.old
[15:40] <tseliot> mvo_: it looks like my workaround worked for liw in in bug 278963
[15:40] <cjwatson> liw: usb-creator just moved from System Tools to System -> Administration - should system-cleaner do the same? it's going to be orphaned in that menu
[15:41] <persia> liw, Please do move it: getting rid of System Tools was a Dapper goal (IIRC)
[15:42] <cjwatson> liw: (see lp:~ubuntu-installer/usb-creator/trunk r42)
[15:44] <StevenK> NCommander: I'm not sure if amitk has commited yet
[15:44] <NCommander> amitk, ping?!
[15:45] <amitk> StevenK: had to re-create diff to remove the git remains
[15:45] <amitk> about to commit now
[15:46] <mvo_> tseliot: having a look now
[15:48] <pitti> Riddell: in bug 280997, woudl using bluez-gnome actually be possible/sensible? it looks quite curious to me
[15:48] <cjwatson> bryce,tjaalton: any movement on bug 270002? there's a fix in wgrant's PPA
[15:49] <tseliot> mvo_: basically making Update Manager upgrade the linux-restricted-modules (with a hack) before any other package seems like a good workaround
[15:49] <liw> cjwatson, a) I have more things in the menu, such as virt-manager and something to config x screensavers b) can I just unilaterally edit the .desktop file or do I need permission from some grand master of menus?
[15:50] <cjwatson> liw: so do I, but I believe nothing else is there in the default install
[15:50] <cjwatson> liw: might be worth stating your intentions on #ubuntu-desktop and asking for objections
[15:50] <pitti> mvo_: FYI, testing the patch in bug 278112 now; if it works for me, too, I'll sponsor this
[15:50] <Riddell> pitti: no that's not acceptable.  I'm pretty much resigned to not having a working bluetooth at release, maybe we can backport the port to the new bluez when it happens for -updates
[15:50] <liw> cjwatson, ok, I'll do that; I need to run out now to catch a bus, I'll take care of it before Monda
[15:51] <pitti> Riddell: ok, what I thought
[15:51] <Riddell> I'll add that to the bug
[15:51] <pitti> Riddell: ok, then I have my snippet for the release meeting
[15:51] <amitk> StevenK: diff.gz pushed to regular place on rookery.
[15:51] <amitk> NCommander: git tree updated too
[15:51] <mvo_> pitti: the if strcmp() one?
[15:52] <NCommander> amitk, d'oh
[15:52] <mvo_> pitti: I think koon mentioned that there was some negative feedback on it
[15:52] <NCommander> amitk, there was a part of that patch that should have been dropped
[15:52] <NCommander> (nothing critical but ...)
[15:52] <pitti> mvo_: yes, it does strcmp(w->resName,"gnome-screensaver") != 0
[15:52] <NCommander> amitk, the change to control.d/flavour-stub should be dropped (its a change in the description)
[15:52] <amitk> NCommander: https://pastebin.canonical.com/10321/ what part?
[15:52] <pitti> mvo_: oh, was it? it wasn't entirely successful, but no regression reports
[15:52] <Riddell> pitti: that in 10 minutes?
[15:52] <NCommander> ^- amitk
[15:53] <pitti> Riddell: yes
[15:53] <StevenK> amitk: NCommander can't read that.
[15:53] <NCommander> (StevenK caught that mistake, there are no problems with the rules themselves, I dunno if you saw, but it builds successfully now ;-))
[15:53] <mvo_> pitti: I only talked to him briefly about it, I check if he is around
[15:53] <StevenK> amitk: For obvious reasons
[15:53] <amitk> aah shit
[15:53] <StevenK> amitk: http://paste.ubuntu.com/
[15:53] <pitti> mvo_: is there any update on "the" compiz crasher bug?
[15:53] <pitti> mvo_: (#145360)
[15:53]  * NCommander didn't even know there was a canonical pastebin
[15:54] <Riddell> NCommander: it still turns line endings into windows ones :)
[15:54] <NCommander> StevenK, did I earn my service award for LPIA this cycle now ;-)
[15:54] <StevenK> NCommander: Heh
[15:54] <mvo_> pitti: no, sorry. I talked to upstream about it and it seems to be a memory corruption. the currnt theory is that it happens on shutdown so people see the crash report on the next login
[15:55] <slangasek> ScottK: ack, thanks for the heads-up
[15:55] <amitk> NCommander: http://pastebin.ubuntu.com/58840/
[15:55] <pitti> mvo_: ok, so that isn't so important once we disable apport :)
[15:55] <Riddell> pitti: you have a line about language packs too?  or is that cjwatson's domain for release meeting?
[15:55] <pitti> Riddell: I do
[15:55] <mvo_> pitti: yeah, I *think* so - its funny because everybody says that they get the notification but compiz works fine :)
[15:56] <cjwatson> wgrant: and re the above, do you believe your xfree86-driver-synaptics PPA change is ready for merging?
[15:56] <NCommander> amitk, Looks fine. obviously the change in the description was fixed without me being there
[15:56] <NCommander> amitk, commit when ready ;-)
[15:56] <pitti> mvo_: screensaver works fine for me, too, with this patch
[15:56] <StevenK> NCommander: Can you run dpkg -c linux-lpia-headers-2.6.27-4 | wc -l for me?
[15:57] <StevenK> Sigh
[15:57] <StevenK> dpkg -c linux-lpia-headers-2.6.27-4_lpia.deb | wc -l
[15:57] <amitk> StevenK you need to upload it
[15:57] <StevenK> amitk: I know
[15:57] <pitti> mvo_: do you actually think the patch is bad?
[15:57] <StevenK> I need to sign it first
[15:57] <NCommander> wait
[15:58] <NCommander> Bah
[15:58] <NCommander> Hold that thought
[15:58] <NCommander> The build didn't work right
[15:58] <NCommander> (the latest one)
[15:58] <mvo_> pitti: no, probably not - might be not ideal, let me talk to upstream about it
[15:58] <StevenK> NCommander: Because that command returns 0?
[15:58] <NCommander> I think so
[15:58] <pitti> mvo_: right, I won't upload just yet, waiting for your ok
[15:58] <NCommander> The first test build didn't do that I think
[15:58] <mvo_> pitti: its a bit hackish, but we had it enabled for some time to workaround a issue with the xserver when it did redirection of windows
[15:59] <pitti> mvo_: I know it's a hack, but hey, we are in final freeze, a.k.a. "bad hacks" time :)
[15:59] <mvo_> pitti: :)
[15:59] <mvo_> pitti: if I don't hear hear anything I upload, I have a new compiz patch for nvdiai and damage problems pending as well
[16:00] <StevenK> NCommander: The first test build had every -headers being linux-lpia, too
[16:00] <pitti> mvo_: ok, great
[16:00] <emgent> hello
[16:00] <NCommander> StevenK, yes well, you asked if the build successed, you didn't say if it worked ;-)
[16:00]  * NCommander is figuring out what went wrong
[16:00]  * StevenK is poking too
[16:01] <NCommander> linux-lpia-headers didn't get made
[16:01] <NCommander> and linux-headers is empty
[16:01] <StevenK> amitk: We have another problem
[16:01] <StevenK> amitk: Where's the orig tarball?
[16:01] <NCommander> StevenK, you generate it by hand with a script
[16:02] <amitk> StevenK: with the 'linux' source
[16:02] <StevenK> amitk: And why didn't -4.5, -4.6, -4.7 have one?
[16:02] <amitk> StevenK: i dunno, ogra uploaded it
[16:02] <amitk> we use the 2.6.27 final tar ball now
[16:02] <StevenK> I'm not sure if Soyuz will reject it
[16:03] <StevenK> amitk: Can you upload the .orig to rookery?
[16:03] <amitk> StevenK: sure. its big
[16:03] <StevenK> Oh, I know that.
[16:04] <StevenK> That's the main reason I'm not uploading the dratted thing from my home machine.
[16:04] <StevenK> Because we would have reached Jaunty DIF, and it would have just finished
[16:04] <amitk> StevenK: eta about 10 mins
[16:04] <NCommander> StevenK, it looks like binary-arch-headers does the right thing
[16:04] <NCommander> Which is a good thing
[16:05] <NCommander> but its not building the actual headers package itself
[16:05] <NCommander> which is a bad thing
[16:06] <NCommander> StevenK, have you done a build recently?
[16:06] <StevenK> NCommander: Nope
[16:06] <StevenK> I want the source tarball so I can read the rules file
[16:06]  * amitk kicks off a build
[16:06] <neighborlee> does ubuntu use debug mode during development , as in things run slightly slower, or do they say just use the ubuntu crash handler ...
[16:06] <NCommander> StevenK, grab the git tree, its all theres
[16:06] <amitk> StevenK: there is no rules in orig tarball
[16:07] <StevenK> amitk: No, but I need it to unpack it
[16:07] <persia> neighborlee, The debug symbols are stripped in the builds, and can be used to recover symbols when needed (sometimes with the crash handler, and sometimes manually).
[16:07] <StevenK> dpkg-source -x doesn't like it if the files listed in Files: don't exist
[16:07] <persia> StevenK, That's a feature.
[16:07] <StevenK> amitk: Besides it, I'll need it to upload
[16:07] <neighborlee> persia, ok thx ;0
[16:08] <NCommander> Bah
[16:08] <NCommander> I think I see what went wrong
[16:08] <NCommander> One of my changes to 3-binary-indep got dropped
[16:09] <StevenK> I thought so
[16:09] <NCommander> That prevented the arch all package from building
[16:09] <amitk> NCommander: dropped by me?
[16:09] <NCommander> no
[16:09] <NCommander> My fault
[16:10] <NCommander> It simply didn't get into the diff I gave you originally
[16:10]  * NCommander thinks he had an old commit lingering by accident
[16:11] <amitk> StevenK: I _have_ to leave for a couple of hours now. I'll look for NCommander's fix when I get back.
[16:11] <StevenK> Argh
[16:11]  * StevenK goes to bed
[16:11] <NCommander> amitk, thats ok, this will take a couple of hours to build another round
[16:11] <amitk> NCommander: if you can get me the patch in the next 15-20 minutes, I can kick off a build on my machine too...
[16:12] <NCommander> amitk, how long does the build take on your machine
[16:12] <amitk> StevenK: when did you last sleep?
[16:12]  * NCommander has to leave in 50-ish minutes for class
[16:12] <StevenK> Umm
[16:12] <amitk> NCommander: 1.5 hrs approx
[16:12] <NCommander> It only took about an hour here ...
[16:12]  * NCommander hugs his dual cores
[16:12] <StevenK> amitk: I got up at 10am local
[16:13] <amitk> NCommander: debuild -b?
[16:13] <StevenK> Ah ha
[16:13] <NCommander> just debuild
[16:13] <StevenK> indep_hdrpkg = linux-headers-$(abi_release) should be indep_hdrpkg = linux-lpia-....
[16:13] <NCommander> yeah
[16:13] <NCommander> That's what I just said ;-)
[16:14] <NCommander> But one of the packages still isn't building
[16:14] <amitk> NCommander: send me the patch nevertheless. In case you disappear, I'll get the build started
[16:14] <StevenK> Which?
[16:14] <NCommander> StevenK, the actual linux-lpia-headers-*api* meta package
[16:14]  * amitk really goes off now
[16:14] <NCommander> (the linux-headers package does build, in that case, the files just ended up somewhere other than devscripts expected them to be)
[16:15] <StevenK> amitk, NCommander: I'm going to crash, I'll resurface at ~ 10am local and upload the kernel
[16:15] <NCommander> StevenK, make sure there is a fix to upload ;-)
[16:15]  * NCommander is going to sleep tooish :-/
[16:16] <StevenK> NCommander: I daresay your patch is a brilliant starting point
[16:17] <NCommander> StevenK, it would have worked if not for sleep-deperivation ;-)
[16:17] <StevenK> Heh
[16:17] <NCommander> StevenK, I'll figure out what went wrong, but its progress. This should be fully fixed by tommorow
[16:17] <ogra> its all about training
[16:17] <StevenK> NCommander: Mine, or yours?
[16:17] <NCommander> StevenK, probably both
[16:17] <NCommander> ogra, well, I already shot myself in the foot with git by mixing up git reset and git revert
[16:18]  * ogra stays away from git based software 
[16:18] <NCommander> ogra, don't you hack on the kernel too?
[16:18] <ogra> nah
[16:18] <ogra> i just play upload bitch for it :)
[16:18] <StevenK> ogra has teeth marks from linux-lpia
[16:18] <ogra> and probably make config changes on package level
[16:19] <ogra> StevenK, hey i bult my own one for classmate
[16:19] <NCommander> StevenK, right now I'm just trying to figure out why not all the meta packages are getting properly built
[16:19] <ogra> but all changes happened on package level
[16:20]  * NCommander notes he'll get the silver star of good try vs. execellence
[16:20]  * NCommander caught another bug
[16:20] <NCommander> StevenK, we have yet another package collision that was overlooked
[16:20]  * StevenK sobs like a 2 year old
[16:20] <NCommander> linux-source collides :-)!
[16:21] <StevenK> Right
[16:21] <NCommander> Easy fix
[16:22]  * StevenK really goes to bed
[16:22] <NCommander> StevenK, good night
[16:22] <StevenK> NCommander: Night
[16:22] <NCommander> oh bugger
[16:22]  * NCommander found the issue
[16:22] <NCommander> :-P
[16:23] <StevenK> NCommander: Oh?
[16:23] <NCommander> StevenK, binary-arch is loaded before binary-indep
[16:23] <NCommander> Thus the laters rules aren't called
[16:23] <StevenK> Err?
[16:24] <NCommander> StevenK, binary-indep is what generates the metapackages -source/-lpia-headers, etc.
[16:24] <NCommander> 2-binary-arch.mk is before 3-binary-indep.mk, so the rules don't seem to properly call each other if I make sense of this
[16:25] <NCommander> actually
[16:25] <NCommander> ignore me
[16:25] <NCommander> I'm an idiot :-)
[16:25] <pitti> tseliot: hm, nvidia-settings is in universe; is that actually free?
[16:25] <tseliot> pitti: yes, it's gpl
[16:25] <pitti> tseliot: right now, nvidia-glx-177 Recommends: it, so it would be suitable in restricted
[16:26] <pitti> tseliot: is the recommends: actually appropriate? do people need it to set up their graphics stuff?
[16:26] <pitti> oh, just read the package description
[16:26] <StevenK> NCommander: Did you set the Arch: to lpia for them?
[16:26] <pitti> tseliot: I'd rather have it as Suggests:, tough
[16:26] <tseliot> pitti: in a number of cases it can help users with the screen resolution, multiple screens, etc.
[16:27] <NCommander> StevenK, yes
[16:27] <StevenK> I don't remember seeing that in the diff
[16:27] <NCommander> StevenK, it still builds out of the binary-lpia rule however
[16:27] <NCommander> StevenK, it was already set before I got here
[16:27] <tseliot> pitti: actually they used to complain about having to install nvidia-settings manually
[16:27] <StevenK> NCommander: I'll stop second guessing you and go to bed
[16:27] <NCommander> StevenK, I wish I could do the same
[16:27] <tseliot> pitti: I don't think it hurts to keep it as a Recommends
[16:28] <pitti> tseliot: main/restricted can't depend/recommend on universe/multiverse stuff
[16:28] <sistpoty|work> pitti: it used to live in restricted, was removed from there and I reuploaded it and it was put in universe, but I checked all code bits, and all that's in there is gpl-2 (or mit/bsd license)
[16:28] <pitti> nvidia-settings | 1.0+20070502-1ubuntu2 | gutsy/restricted | source, amd64, i386, ia64
[16:28] <pitti> oh, indeed
[16:29] <pitti> ok, so maybe it's easiest to put it back there
[16:29] <tseliot> pitti: yes, it's restricted. It's what I was about to suggest
[16:29] <sistpoty|work> pitti: erm, the static lib is used in universe as a build-dependency
[16:29] <tseliot> pitti: s/it's restricted/in restricted/
[16:29] <pitti> eww
[16:30] <sistpoty|work> pitti: for a gnome applet thingy to display the gpu temperature (but I don't recall the package name right now)
[16:30] <pitti> having that thing in main doesn't feel right
[16:31] <pitti> -- intrepid/universe build deps on nvidia-settings:
[16:31] <pitti> sensors-applet
[16:31] <pitti> sistpoty|work: ^
[16:31] <sistpoty|work> pitti: yep, that's it
[16:32] <RainCT> pitti: what script are you using for that?
[16:32] <pitti> http://people.ubuntu.com/~pitti/scripts/checkrdepends
[16:32] <pitti> it's conveniently installed on our archive master
[16:32] <pitti> but it works from anywhere with a fast network connection
[16:33] <pitti> (downloads all the packages.gz/sources.gz0
[16:33] <RainCT> oh ok, then it's nothing for me :P
[16:33] <RainCT> thx
[16:34] <maestrolinux> http://s2.ar.bitefight.org/c.php?uid=19732
[16:35] <cjwatson> maestrolinux: please don't spam this channel
[16:37] <tseliot> pitti: if recommends on universe/multiverse are not allowed then let's make nvidia-settings a Suggest. Users won't be pleased though
[16:39] <persia> Is there a reason nvidia-settings can't be in main?  For a while it was built from sources in restricted, although that changed.
[16:39] <MacSlow> amitk, ping
[16:42] <pitti> persia: not technically, mainly political ones, I guess
[16:42] <persia> pitti, It's not non-free or anything.  Does it break anything?
[16:43] <pitti> persia: if that thing is actually GPL, it just needs a MIR, I figure
[16:44] <persia> pitti, Looks GPL/BSD to me (http://changelogs.ubuntu.com/changelogs/pool/universe/n/nvidia-settings/nvidia-settings_177.78-0ubuntu2/copyright)
[16:45] <persia> tseliot, You seem to have been chasing that source : up for drafting an MIR?
[16:46] <tseliot> persia: ok, I can do it
[16:47] <persia> tseliot, Feel free to ping me if you get stuck : I've drafted a couple before, but it's always best to have someone familiar with the source start it (and my contributions to nvidia-settings were about changing Conflicts entries)
[16:48] <tseliot> persia: ok, thanks
[17:01] <pitti> oh good, I wish there was a tool to display the 203942304 perl modules on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt as a graph
[17:01] <pitti> s/good/god/
[17:06] <gouki> persia, sorry to ping you, but .. I'm getting a launcher created at the top bar, even though I deleted all entries for launchers. Any idea of how I can troubleshoot that?
[17:06] <persia> gouki, Nope.
[17:08] <seb128> what is the question exactly?
[17:09] <gouki> seb128, mine?
[17:10] <seb128> gouki: did anybody else asked a question? ;-)
[17:10] <gouki> seb128, I scrolled up a bit, but didn't see it :P
[17:11] <gouki> seb128, I'm editing the files responsible for creating the menus in Gnome. For some reason, a launcher, right next to the menu bar, is being created. I've look in all the .xml I know and can't find any reason for it to be created.
[17:11] <seb128> gouki: the layout is a gconf configuration
[17:13] <gouki> seb128, yes, but I'm building an .ISO, and so I'm editing the files by hand. I removed all entries (three actually) for the launchers, but 1, empty one, stills shows up.
[17:13] <gouki> By default yelp, evolution and firefox are created. Since none of those are present on the CD, I removed them from the .xml configuration files.
[17:14] <seb128> what xml?
[17:14] <gouki> seb128, /etc/xdg/menus/
[17:15] <seb128> that describes the menu not the bar layout which is gconf configuration as said before
[17:15] <gouki> I've also looked into /etc/gconf, but didn't find anything there.
[17:16] <seb128> gouki: /usr/share/gconf/defaults/05_panel-default-setup.entries is the default configuration
[17:16] <gouki> seb128, hmmm. Interesting. Let me look into that one. Thanks!
[17:17] <gouki> seb128, indeed. There is an entry for the browser_launcher. Thank you.
[17:20] <seb128> gouki: the schemas are not used at runtime but registered in the gconf database at installation time so you might need to change the gconf configuration directly
[17:20] <seb128> gouki: the configuration is in /var/lib/gconf
[17:21] <gouki> seb128, I will. Thank you very much for the help.
[17:21] <kirkland> Keybuk: i know you've told me this before, but which of these two are preferred ... "udevsettle" or "udevadm settle" ?
[17:22] <Keybuk> only one of them exists ;)
[17:22] <Keybuk> udevadm settle
[17:22] <kirkland> Keybuk: thx
[17:23] <pitti> cjwatson: FYI, I'll upload installation-report with the reportbug recommends dropped
[17:24] <cjwatson> pitti: ok, please commit to bzr too
[17:24] <pitti> cjwatson: yeah, just checking out
[17:25] <tseliot> persia: I haven't filed a bug report about the MIR yet but what do you think of this? https://wiki.ubuntu.com/MainInclusionReportNvidiaSettings
[17:28] <persia> tseliot, In what situatins does the package not work out of the box without configuration: when the "nvidia" driver is not enabled in X.
[17:28] <tseliot> persia: ah, right
[17:30] <persia> tseliot, Has it had different names in the past : In Edgy, Feisty, and Gutsy this package was produced by linux-restricted-modules, although previous and current releases have maintained the name.
[17:30] <persia> s/this package/the nvidia-settings binary package/
[17:30] <persia> (that didn't actually work, but it's worth mentioning for posterity)
[17:32] <tseliot> persia: but doesn't the question refer to the binary i.e. to nvidia-settings the binary?
[17:32] <persia> tseliot, I thought it was source+binary, but your answer is correct for the binary.
[17:33] <tseliot> from what I remember its name has always been nvidia-settings
[17:33] <tseliot> persia: ok
[17:33] <bryce> cjwatson: okay I didn't know about the fix for 270002; I'll follow up with wgrant on getting his patch in.
[17:33] <radix> Can I get a core-dev to look at Bug #285030? It's a minor change to the "Replaces" line for landscape-common to allow upgrades to intrepid to work (mathiaz? slangasek?)
[17:33] <tseliot> persia: as the questions are What do upstream call this software ? Has it had different names in the past ?
[17:33] <bryce> cjwatson: it may be just some confusion over freeze exception procedures
[17:34] <mathiaz> radix: I'll have a look at it
[17:34] <radix> mathiaz: you're a wonderful person :)
[17:34] <cjwatson> bryce: thnks
[17:34] <cjwatson> +a
[17:34] <persia> tseliot, Ah, yeah, upstream never called it anything else, it was just us breaking it for a few releases because we didn't want to maintain it.
[17:35] <tseliot> persia: ah, ok. I'll file a bug report now and add a reference to it to the wiki
[17:39] <persia> tseliot, "Main Inclusion report for sourcepackage" should probably be "Main Inclusion Report for nvidia-settings" :)
[17:40] <tseliot> persia: yes, right ;)
[17:40] <persia> And the MIR bug number is wrong, but everything else looks good.  Thanks for writing that up.
[17:40] <radix> mathiaz: fwiw, we have stopped the release of non-split landscape-client packages in our own repos, and our next release will have the split packages, so this shouldn't happen again
[17:41] <tseliot> persia, pitti: the MIR is here: https://bugs.launchpad.net/ubuntu/+source/nvidia-settings/+bug/285067
[17:42] <radix> mathiaz: ah, and as usual I forgot to include the "(LP: #foo)"... I'll update the branch
[17:42] <mathiaz> radix: ok. I haven't looked at the bug yet.
[17:42] <radix> cool :)
[17:42] <pitti> lool: elisa-plugins-bad still recommends gst-plugins-ugly0.10
[17:43] <pitti> lool: I think we need to drop that to Suggests:, too
[17:43] <pitti> lool: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt just got updated
[17:43] <lool> That's going to be bad, but I'll test as well
[17:44] <lool> and given that I'm not at home and the release meeting isn't over yet, I don't see myself testing tinight
[17:44] <lool> *tonight
[17:44] <persia> pitti, What wants JACK?
[17:46] <pitti> [Reverse-Build-Depends: libvisual-plugins]
[17:46] <pitti> another thing that elisa pulls in
[17:46] <persia> OK.  Part of elisa then.  Thanks.
[17:46]  * persia wants jack-in-main, but for jaunty, not intrepid, and was confused
[17:51] <amitk> MacSlow: pong
[17:52] <MacSlow> amitk, hi there
[17:52] <pitti> Riddell: kttsd currently Recommends: festival | flite | epos
[17:52] <MacSlow> amitk, did you already have a change to test the updated libgksu package for interpid to see if you still encounter the crash?
[17:52] <pitti> Riddell: of those, festival is in universe (and IIRC TheMuso wanted to keep it that way, flite could be moved to main, and epos is in universe
[17:52] <MacSlow> amitk, s/change/chance
[17:52] <pitti> Riddell: any idea about that, or anyone I could ask about a11y in KDE?
[17:53] <amitk> MacSlow: no, haven't upgrade since afternoon. Hold on.
[17:53] <Riddell> pitti: probably easiest to move kttsd to universe
[17:53] <Riddell> pitti: would need kdeaccessilibity meta package changed
[17:54] <pitti> Riddell: right now it seems to get installed by default without any backend
[17:54] <pitti> so we could either add a backend (easy: flite), or drop kttsd, right
[17:55] <pitti> Riddell: either solution involves a kdeaccessibility upload, yes
[17:55] <Riddell> yep
[17:55] <pitti> I just don't know what the better solution is
[17:55] <amitk> MacSlow: there is not libgksu available on a dist-upgrade
[17:56] <amitk> *no
[17:56] <MacSlow> amitk, hm ... still taking it's time
[17:57] <MacSlow> amitk, are you comfortable with creating you own packge from a set of .dsc/.diff.gz ? If so you could give my patched version a try.
[17:57] <MacSlow> amitk, you would have to create a .deb yourself.
[17:58] <amitk> MacSlow: I could. I'm just a bit busy with guests :) So I'll just wait another couple of hours.
[17:58] <lool> MacSlow: Push to your ppa perhaps?
[17:58]  * lool keeps amitk all for himself
[17:58] <MacSlow> lool, yeah I could do that
[18:00] <MacSlow> lool, initially I just pointed mvo to my patch (.diff.gz, .dsc, .changes) and he sponsored it... that's why I initally thought doing a PPA for that is not needed
[18:00] <MacSlow> amitk, lool: let's see
[18:05] <pitti> Riddell: hm, so shall I drop kttsd to universe or promote flite?
[18:06] <Riddell> pitti: drop kttsd, I've no idea what sort of a working state it's in
[18:06] <pitti> Riddell: alright
[18:09] <jdstrand> pitti: hi!
[18:09] <jdstrand> pitti: can you de-NEW bind9 for hardy-proposed?
[18:09] <jdstrand> (bug #257682)
[18:09] <MacSlow> amitk, just uploading it to my PPA ... let's see which is faster ... offical repo or my PPA :)
[18:11] <MacSlow> amitk, btw... while I never saw a crash for libgksu with my inital version, I found tiny rendering artefacts that I only recognized today ... after mvo pointed me to the bug LP #275172
[18:13] <pitti> jdstrand: done
[18:13] <jdstrand> \o/
[18:13] <jdstrand> pitti: thanks! :)
[18:15] <MacSlow> amitk, hm... the upload hangs
[18:15] <pitti> zul, dendrobates: bacula-sd currently recommends: mt-st (*blowing the dust off*, a tape control thingy); do we really want that in main (MIR needed), or the recommends dropped?
[18:15] <MacSlow> lool, is some ppa-server down?
[18:16] <zul> pitti: yes its necessary, ill write the MIR for it
[18:27] <sbeattie> slangasek: is bug 269539 likely to go away now that last-good-kernel has been postponed.
[18:28] <MacSlow> amitk, uploaded to PPA ... compiling now
[18:28] <MacSlow> amitk, https://edge.launchpad.net/~macslow/+archive
[18:35] <pitti> sbeattie: hm, isn't that from update-grub when a new kernel ABI hits?
[18:35] <pitti> i. e. not really related to last-known-good-boot
[18:37] <sbeattie> pitti: looking at http://launchpadlibrarian.net/17780561/menu.lst.ucf-new is what makes me suspect last-known-good-boot, but that's with little knowledge of what's happening.
[18:38] <pitti> sbeattie: ah, ok
[18:38] <pitti> sbeattie: sorry, I just read the bug title
[18:39] <sbeattie> pitti: well, I'm not sure either, that's why I'm asking. :-)
[18:40] <pitti> I got a similar situation when I edited the autogenerated stanzas without editing the defaults
[18:40] <pitti> but I got a proper ucf dialog
[18:47] <lool> MacSlow: dunno
[18:49] <tedg> Can someone please sponsor bug 278810 ?
[18:51] <bdmurray> tkamppeter: Have you seen bug 255583?
[18:59] <ScottK> pitti: If an apport crash is consistently put against the wrong package, is that an Apport problem or a Launchpad problem?
[19:01] <pitti> ScottK: it's not at all a LP bug; it is an apport bug, but in some cases it's not practically fixable without concrete manually maintained lists
[19:01] <pitti> ScottK: do you have an example?
[19:02] <ScottK> pitti: Bug 281918 and the bazillion dupes.
[19:02] <ScottK> pitti: I've seen it on other guidance-power-manager bugs too.
[19:04] <pitti> ScottK: where was it originally assigned to?
[19:04] <pitti> oh, python2.5
[19:04] <ScottK> pitti: python2.5
[19:05] <pitti> ScottK: that's indeed a bug which should be fixable; it works correclty for a lot of other python packages; can you please file an apport bug about it?
[19:05] <ScottK> Sure
[19:05] <pitti> ExecutablePath: /usr/bin/python2.5
[19:05] <pitti> Right
[19:05] <pitti> that should usually be /usr/bin/guidance-power-manager
[19:05] <pitti> i. e. the python script
[19:06] <pitti> I'm off for today, have a good weekend everyone!
[19:07] <ScottK> pitti: Have a good weekend.  Bug #285106 filed.
[19:12] <didrocks> slangasek: around?
[19:20] <calc> what package does the workspace switcher belong to?
[19:20]  * calc is trying to determine which package to reassign this bug to
[19:22]  * calc guesses at gnome-panel
[19:24] <james_w> calc: depends what the bug is, might be libwnck, but I think you are right to assign it there, it can be moved if necessary.
[19:27] <tkamppeter> bdmurray, Bug 255583 is already fixed in Intrepid.
[19:49] <slangasek> sbeattie: 269539 - I really have no idea, because I have yet to see a menu.lst.ucf-new that tells me what the source of the conflicts are
[19:49] <slangasek> oh, but apparently there's one available now
[19:50] <slangasek> didrocks: hi
[19:57]  * ogra wonders why http://paste.ubuntu.com/58928/ can result in http://paste.ubuntu.com/58930/ if compiled and run
[19:57] <ogra> sems my system cant compile gtk binaries anymore
[19:57] <slangasek> sbeattie: ok, that particular conflict is a non-issue because last-good-boot is disabled now, yes
[19:57]  * ogra is irritated
[19:57] <slangasek> I'll have to keep an eye on that for jaunty when l-g-b is revisited
[19:58] <didrocks> slangasek: hi :) does pitti spoke with you about bug #212098
[19:58] <didrocks> ?
[19:58] <slangasek> didrocks: we discussed it in the release meeting today, yes
[19:59] <didrocks> slangasek: ok, apparently, pitty told me that what we planned initially will not work
[20:00] <didrocks> that is to say get the group from the current session
[20:00] <slangasek> sbeattie: which of the dupes was that menu.lst.ucf-new hiding in, btw?
[20:00] <didrocks> and then compare it to getpwent
[20:00] <slangasek> didrocks: the issue is not the group.  there were two reasons why the user needed to logout and log back in
[20:01] <didrocks> pitti spoke to me about some pass hash ?
[20:01] <slangasek> er - trying to compare groups by hand is definitely not going to work, no
[20:01] <didrocks> (the idea was just to warn user if getpwent tell that the user is in the right group, but that the session has not been reloaded)
[20:02] <slangasek> that part has been resolved by adding sambashare to the list of groups created by the installer
[20:02] <slangasek> the other part is that libpam-smbpasswd has to be installed, and then the user has to authenticate, before that user can be used for authentication to shares
[20:02] <didrocks> yes, and all users with admin "profile" in "user and group" are in the sambashare group
[20:02] <tseliot> pitti: thanks ;)
[20:03] <slangasek> if you're only doing anonymous shares, then that doesn't matter
[20:03] <slangasek> sorry, libpam-smbpass
[20:03] <slangasek> but if you're doing authentication, then each user needs to authenticate to the local system in order for libpam-smbpass to pick up the password and create the NTLM password hash
[20:04] <didrocks> is libpam-smbpass installed on enabling sharing?
[20:04] <slangasek> yes
[20:06] <didrocks> ok, so, this is harder to detect. Is there any API or I have to parse some conf files?
[20:06] <mvo_> amitk: did you had a chance to test the new libgksu?
[20:07] <slangasek> didrocks: what are you trying to detect?
[20:07] <didrocks> slangasek: that libpam-smbpass didn't create a NTLM password hash for the current user
[20:07] <tseliot> cody-somerville: can you have a look at my FFE for Hardy, please? https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/261816
[20:08] <slangasek> didrocks: libpam-smbpass *doesn't* create an NTLM password hash for the user *until the next time that user logs in*
[20:08] <slangasek> didrocks: this is why we wanted a notice telling the user to log out and log back in :)
[20:09] <didrocks> slangasek: yes, and that's a way to detect that we have to tell to a user that he has to log out and back in :)
[20:09] <slangasek> didrocks: the first iteration should always tell the user to log out and log back in
[20:09] <slangasek> didrocks: or to do this any time the libpam-smbpass package was not previously installed
[20:10] <didrocks> slangasek: but for "normal" user (not admin one)
[20:10] <slangasek> hmm?
[20:10] <didrocks> slangasek: see last case on https://bugs.edge.launchpad.net/ubuntu/+source/nautilus-share/+bug/212098/comments/57
[20:10] <didrocks> we still have the group issue there without noticing
[20:12] <slangasek> under what circumstances is a non-admin user installing packages?
[20:13] <slangasek> oh, you're talking about a user being given sambashare privs by the admin
[20:13] <didrocks> no, that's not what I described in my use-case
[20:13] <didrocks> yes
[20:13] <didrocks> and the admin ssh to the host
[20:13] <didrocks> or use "switch user", without unlogging the current one
[20:13] <slangasek> then the user has to log out and log in again
[20:13] <slangasek> and we have no communications channel by which to tell them this
[20:14] <didrocks> yes, but he has no warning about that
[20:14] <slangasek> so the admin has to tell the user
[20:14] <slangasek> that's far out of scope for what we're trying to get fixed...
[20:14] <didrocks> and what about getwgrent to detect this case?
[20:14] <didrocks> getpwent, sorry
[20:15] <slangasek> what component is going to do the detection?
[20:15] <ion_> pitti: May i suggest renaming “Guest session” as “New guest session” to avoid confusion with the “Guest” item which shows up when there is a guest session running?
[20:15] <ion_> pitti: Alternatively, fusa could hide “Guest session” in that case.
[20:15] <slangasek> didrocks: is nautilus-share supposed to do this when the user clicks on 'sharing options'?
[20:16] <didrocks> slangasek: that's what I was thinking, but I might be totally wrong :)
[20:17] <slangasek> didrocks: so if the current process doesn't have the group permissions, but getgrnam("sambashare") lists the user, pop a warning telling them to logout/login
[20:17] <didrocks> exactly
[20:17] <didrocks> and we fix both issues
[20:17] <slangasek> didrocks: I think that makes sense.  But I also think it's out of scope for what we should be trying to fix for intrepid
[20:17] <slangasek> which "both"?
[20:17] <slangasek> it doesn't fix the NTLM hash issue
[20:18] <didrocks> yes, but it will force them to unlog too
[20:18]  * ogra cries ... my system cant build working gtk binaries anymore ... no seb128 either :(
[20:18] <slangasek> that issue needs to be fixed with an *unconditional* message after installing libpam-smbpass, *regardless* of the group membership
[20:18] <slangasek> ogra: debsums -s?
[20:18] <ogra> slangasek, debsums ?
[20:18] <ogra> its a plain .c file
[20:18] <ogra> slangasek, http://paste.ubuntu.com/58928/
[20:19] <slangasek> ogra: I mean you should check the integrity of your sysetm
[20:19] <slangasek> system
[20:19] <didrocks> slangasek: yes, I agree, but do we want to add this additional detection too? It's a workaround, yes, but waiting for a better solution…
[20:19] <ogra> oh
[20:19] <slangasek> didrocks: I would, on the first iteration for intrepid, not mess around with trying to detect group memberships
[20:20] <slangasek> didrocks: an unconditional message, after installation of libpam-smbpass, addresses the immediate problem, and we can refine it from there
[20:20] <didrocks> slangasek: ok, I will build my first proposal on that :)
[20:20] <didrocks> thanks for having clarified that :)
[20:20] <slangasek> didrocks: ok, thanks :)
[20:21] <slangasek> didrocks: when do you think you might have a chance to work on this?  We're obviously well into freeze territory already
[20:21] <didrocks> slangasek: yes, I think it would be possible to do this for Monday/Tuesday (will try to handle it this week-end), will be it ok?
[20:22] <slangasek> didrocks: Monday would be best
[20:22] <didrocks> slangasek: ok, will do my best, so :)
[20:22] <slangasek> didrocks: ok, thanks. :)
[20:23] <didrocks> slangasek: you're welcome!
[20:25] <ogra> slangasek, that prouces some output, but nothing strikes me as related to gtk ... the segfaulting started out of the blue
[20:25] <ogra> *produces
[20:25] <ogra> i first thought i had a typo in my code
[20:25] <ogra> which made me write that little test code to notice it segfaults as well
[20:26] <slangasek> hmm, it produces output other than "no md5sums for <package>"?
[20:27] <slangasek> ogra: ok, I just tested your code, it segfaults here too :)
[20:27] <ogra> wow
[20:28] <slangasek> but nothing else does
[20:28] <ogra> weird
[20:28] <slangasek> ogra: google: gtk "hello world" says you're missing a gtk_init()
[20:29] <ogra> eek
[20:29] <ogra> oh man ... i should probably stop for the day instead of wasting other peoples time with my sillyness
[20:41] <kiffi1> I have a question about Ubuntu 8.10 beta...
[20:42] <ScottK> kiffi1: #ubuntu+1 is almost certainly the place to ask it.
[20:43] <kiffi1> If I install it can I easily upgrade to 8.10 via package manager or do I have to reinstall everything again?
[20:43] <ScottK> Upgrading should be fine.  If you have to reinstall we messed up bad.
[20:43] <kiffi1> Had a heck of a time getting my atheros wifi card to work properly so this should be okay right?
[20:44] <kiffi1> Alright then, here I go. Keep those old fingers crossed...
[20:47] <kiffi1> I have a dual boot Windows Vista (1st partition) and Ubuntu 8.10 (2nd partition), can I use gparted to remove the 1st and move/resize the original Ubuntu partition to take up the whole disk?
[21:07]  * ogra would like to know why evo forgets his pop passwd after every reboot 
[21:07] <directhex> it forgets your password on every failed connection
[21:07] <directhex> on the assumption that it must've been a password-based fail
[21:08] <ogra> hmm, it didnt do that in hardy
[21:08] <ogra> i cant even remember when i had to type it in the last time
[21:08] <ogra> probably early gutsy or so
[21:11] <slangasek> kirkland: did you get a security review of the mount counter?
[21:25] <maco> ogra: i think it does do that in hardy.  i just unlocked my screen after it being off overnight, and it was prompting for my IMAP password
[21:26] <ogra> maco, well, i'm sure it didnt do that for me
[21:27] <ogra> and it does it on every reboot in intrepid since about a week (it didnt do it either in intrepid until recently)
[21:27] <maco> ogra: i dont think it did that a few months ago, but i'm not sure
[21:28] <maco> er, not the computer being off, the screen being locked overnight.
[21:30] <Laney> TheMuso_, crimsun: Commented on the pulseaudio race bug. Latest fix seems to nail it for me, good work
[21:37] <LimCore> hi
[21:37] <LimCore> how to have my event.sh evecuted when ever the power button is pressed?
[21:40] <maco> now that acpi-support's going away
[21:40] <maco> (adding to the end of LimCore's question)
[21:42] <wgrant> cjwatson: It's not entirely, but somebody upstream decided to merge it anyway... I've got a new version pretty much ready, but I'm talking to upstream. And what is "the above"? I can't see any relevant conversation earlier.
[21:46] <LimCore> is there nttp NEWS access to ubutnu devels ML ?
[21:48] <persia> LimCore, There's some mirrors, but nothing official.
[21:57] <slangasek> TheMuso_: is bug #273507 something we should fix for intrepid?
[22:03] <cjwatson> wgrant: I mentioned your name about a page above that (on my screen anyway) when asking bryce/timo if they were aware of your patch; but doesn't matter, you got the idea anyway
[22:04] <wgrant> cjwatson: Ah, right, lastlog sees it.
[22:04] <bryce> yeah we were just chatting about that
[22:04] <wgrant> The tapping fix is fine to go in.
[22:05] <wgrant> The syndaemon one isn't small, but it reduces the overall patch size and simplifies it significantly, and it's less braindead and thus less likely to crash in the signal handler.
[22:07] <wgrant> (and syndaemon isn't used by many, and most existing users run it in the old SHMConfig mode, which this change doesn't touch)
[22:09] <maco> wgrant: i mentioned your patch in a security talk at Ohio Linux Fest because SHMConfig isn't exactly nice for security
[22:09] <wgrant> We've very nearly got rid of the need for it.
[22:12] <wgrant> bryce: New debdiff on bug #270002. I've also attached the more useful final patch to syndaemon, as the diff between the two patches is horrific.
[22:19] <bryce> wgrant: hmm, that's a more involved patch than I'd hoped
[22:20] <wgrant> It is, yes.
[22:21] <wgrant> But with the old one, you're likely to be without a touchpad until you reboot if the signal handler doesn't work properly. And my old signal handler was awful.
[22:22] <emgent> heya
[22:23] <bryce> wgrant: how much testing has been done on this so far?
[22:25] <wgrant> bryce: I've been using it for a couple of days in both configs, and I had two forums users test a version that was only slightly different.
[22:25] <bryce> wgrant, the 106_fix_twofinger_disentanglement.patch patch that closes #270002 I'm totally comfortable with, it's the other patch I'm less certain about
[22:25] <wgrant> Same.
[22:25] <wgrant> 106 is clearly fine.
[22:26] <bryce> as well, the other patch is fixing a non-release-critical bug
[22:26] <bryce> so I'm wondering, would it be okay if we isolated this to just the fix for the release critical bug for now?
[22:26] <wgrant> If you feel that way, of course.
[22:27] <wgrant> I realise it's likely far too late for the 104 changes, but it's a nasty problem and it was worth a try.
[22:52] <bryce> wgrant: ok, I've uploaded that fix
[22:52] <bryce> wgrant: the syndaemon fix may still be doable, but I'd like to see it get some additional independent testing first
[22:52] <maco> bryce: if im running intrepid in a vm, can i test it?
[22:53] <wgrant> bryce: Sure.
[22:53] <wgrant> bryce: Thanks.
[22:53] <maco> or is actual hardware required?
[22:53] <wgrant> You'd need a touchpad, and VMs don't have touchpads.
[22:53] <bryce> maco: yeah hw required
[22:54]  * maco looks at unused laptop
[22:54] <bryce> wgrant, I figure separating these out will make future regression testing simpler too, in case there's problems
[22:54] <crimsun> maco: get daily-live, get deb, install deb, restart gdm
[22:55] <maco> crimsun: you're smart
[22:55] <maco> ooo so this is why i bought more blank cds a few weeks ago
[22:55] <crimsun> no, I'm crimsun.
[22:55] <wgrant> bryce: True, true.
[22:56] <maco> wgrant: do you have 32 and 64bit debs available in your ppa?
[22:56] <wgrant> maco: They should both be there, yes.
[22:56] <wgrant> And lpia, if you're that way inclined.
[22:56] <maco> ok
[22:57] <wgrant> maco: Make sure you get ~wgrant2 and not ~wgrant1.
[22:58] <maco> hey, there's no daily live
[22:58] <maco> just alternate
[22:59] <persia> maco, Which arch?
[22:59] <maco> there's no daily live for x86 or amd64
[23:00] <persia> I have an i386 daily live from the 17th.
[23:00] <maco> http://cdimage.ubuntu.com/daily/20081017/ <-- not there
[23:00] <wgrant> maco: For testing syndaemon, try to use it as normal both with and without -S. Also kill it in various ways (just not SIGKILL) and make sure you're not left with your touchpad not working.
[23:00] <persia> http://cdimage.ubuntu.com/daily-live/current/ has some links to the latest ones.  New ones come out in three or four hours.
[23:01] <maco> ah ok thanks
[23:01] <bryce> slangasek, pitti: fix for 270002 has been uploaded; please review/approve
[23:01] <slangasek> ack
[23:05] <persia> maco, daily is the alternate CD.  daily-live is the live CD.  That said, I wonder why Ubuntu Desktop didn't get generated for i386/amd64, as I did get a daily alternate for Ubuntu Desktop lpia and Ubuntu Studio i386.
[23:06] <maco> persia: yeah, i got the url wrong
[23:06] <maco> it exists
[23:08] <persia> Oh.  You typed it wrong in the browser and perfectly in IRC?  I see.  Sorry for the confusion.
[23:08] <bryce> cjwatson: ok debs built for testing for 264462, for all combinations of patches.  I'm cool to upload whatever combo solves the problem.
[23:09] <bryce> cjwatson: it sounds like the OEM folks are going to need some of my time this evening and this weekend, so I'm going to nip out to get a haircut right now, and will be back in an hour or so.
[23:09] <cody-somerville> doh
[23:09] <cody-somerville> I wanted to get a haircut today
[23:09] <cody-somerville> I totally forgot
[23:09]  * jdong got a haircut today :)
[23:10]  * maco doesn't get haircuts
[23:22] <calc> damn it why is launchpad always going down
[23:22] <calc> that is twice in the past what two days now
[23:23]  * calc thinks launchpad needs some sort of backup so they don't have to take the whole thing down every week or so
[23:23] <wgrant> They must have found some regression in 2.1.10.
[23:23] <mthaddon> calc, it's a follow up to yesterday's rollout
[23:23] <slangasek> launchpad is always going down because Canonical pays a team of programmers to make changes to it. :)
[23:23] <calc> mthaddon: ok
[23:24] <calc> slangasek: yes but usually for important sites there is some sort of redundancy
[23:24] <calc> they do it late at night european time which is almost always while i am still working here in the US :\
[23:24]  * calc hopes it is another short 20min outage like yesterday
[23:25] <mthaddon> will see what I can do (expect it to be a short one)
[23:25] <calc> mthaddon: ok
[23:25] <calc> i guess the big deal is that there is only one database server on the backend so whenever they do make changes it takes the whole thing down?
[23:26] <calc> i guess i can use this time to do the complete reinstall of my laptop that i wanted to try out
[23:26] <slangasek> calc: er, considering how often the roll-outs include database schema changes, db server redundancy doesn't help
[23:27] <calc> slangasek: maybe those should be stacked together to only do database changes every (large time gap) apart
[23:27]  * wgrant notes that read-only-launchpad is nearly implemented, and should mean that Launchpad will be up, though read-only, during rollouts.
[23:27] <calc> wgrant: ok that would help quite a bit
[23:27] <wgrant> calc: It done monthly now...
[23:27] <wgrant> s/It/It's/
[23:27] <calc> wgrant: ah it seemed more often than that, but maybe i just have bad timing of when i work on a lot of bug reports, heh :)
[23:28] <calc> i think part of it may be the multiday rollouts though, i remember one time lp was down for a long time (6hr+ iirc)
[23:28] <calc> then out again the next day for a while, but i might be wrong about that
[23:28] <wgrant> The last time it was down for ages for a rollout was for the Rosetta schema changes.
[23:29] <wgrant> That was particularly bad because somebody stuffed up the time calculation, and they had to abort the 8-hour upgrade before it was finished, and schedule an even more ridiculous window for some other day.
[23:29] <calc> wgrant: would there be some way with read-only lp to queue up changes while it is running in that mode to not commit them to the database until later?
[23:29] <calc> iirc there is some way to make changes via email as well, which basically would be queued anyway, right?
[23:29] <wgrant> calc: That's probably a lot more work than it'd be worth...
[23:30] <cjwatson> maco: doesn't get haircuts> that's the one true way to do it
[23:30] <calc> wgrant: ah yea i think that is the outage i am remembering, heh
[23:30]  * wgrant hasn't had a haircut for a little while.
[23:31] <slangasek> "Launchpad will be going offline for maintenance very very soon." heh
[23:31] <wgrant> I wonder how much of the downtime window is actually upgrading things, and how much is stopping and starting it all.
[23:31] <maco> cjwatson: well, ok, its a lie. i get a haircut when, once a year, my mom gets sick of my split ends and makes me get a hair cut.  but id rather it just get longer
[23:33] <calc> hmm that reminds me i need to get a haircut
[23:34]  * calc looks a bit shaggy for his wife's school reunion tomorrow
[23:34] <cjwatson> you know, just after reading news about an LP code update, I should know not to try to 'bzr up'
[23:35] <wgrant> Does maintenance really could as scheduled if we're told an hour beforehand?
[23:35] <wgrant> GAH
[23:35] <wgrant> s/could/count/
[23:37] <brendan_> is OpenOffice.org 3, going to make it into ibex?
[23:38] <RainCT> brendan_: Not for the CD. Into -updates/-backports, I don't know.
[23:38] <brendan_> dam (am using ibex, now and would like to try it)
[23:38] <RainCT> brendan_: there's a PPA
[23:39] <slangasek> not into -updates, switching OOo major versions is not an appropriate SRU
[23:39] <RainCT> brendan_: https://launchpad.net/~openoffice-maints/+archive or something like that (I've just closed my web browser so I don't know the exact url)
[23:39] <slangasek> but there's a PPA and it might find its way into -backports, yes
[23:39] <brendan_> cool
[23:40] <calc> brendan_: ~openoffice-pkgs/  of course lp is down now
[23:40] <brendan_> might just install it from the main OOo website
[23:40] <calc> brendan_: well if you want less bugs the one on the ppa should be better
[23:41] <calc> brendan_: or you could get the one from go-oo.org which is roughly equivalent
[23:41] <brendan_> calc, ok
[23:41] <brendan_> thanks all
[23:42] <calc> brendan_: ubuntu's uses ooo-build which is what go-oo.org uses and has 500+ patches that aren't in upstream
[23:42] <brendan_> oh, ok
[23:55] <calc> hmm lp is still working
[23:56] <wgrant> calc: It's back.