[00:38] <chrisccoulson> lol @ bug 745350
[00:38] <ubot2> Launchpad bug 745350 in firefox "while working on Firefox/Gmail, my cat sit down on keyboard " [Undecided,New] https://launchpad.net/bugs/745350
[00:38]  * RAOF is intrigued.
[00:39] <chrisccoulson> he just seems to be reporting a bug to tell me that his cat sat on his keyboard
[00:42] <TheMuso> That is amusing.
[01:05] <ryanpg> Hi there, not sure if this is the right place to ask but... I installed gnome-shell from the gnome3 ppa, all went well except themes are broken, can't install gtk3-engines because it depends on libgtk3.0-0 and that breaks everything :) solutions?
[01:10] <mimico> ryanpg, possibly gnome-icon-themes-symbolic
[01:12] <ryanpg> mimico, I'm not finding that package... googling it now
[01:12] <mimico> *gnome-icon-theme-symbolic
[01:13] <mimico> my bad
[01:14] <ryanpg> ahh... well both that and gnome-icon-theme are installed
[01:15] <mimico> hmm.
[01:15] <ryanpg> the issue is that gtk3-engines seems to want libgtk3.0-0 and not libgtk3-0
[01:15] <ryanpg> and installing libgtk3.0-0 means dumping 90% of gnome
[01:17] <ryanpg> someone over in gnome-shell on irc.gnome.org just told me that PPA isn't fully installable atm
[01:18] <mimico> 64bit?
[01:18] <ryanpg> nope, 32... I guess I'll just purge and do jhbuild
[01:18] <mimico> k
[01:18] <ryanpg> mimico, but thank you for your help! :)
[01:18] <mimico> :-)
[02:27] <psusi> I'm a little new to the whole gnome/gui programming scene... I've always preferred working on kernels and daemons, but the last few days I've been trying to change that.  I have ended up fixing a bug in gnome-power-manager that made it stop respecting the gconf settings to lock the screen or not on suspend or hibernate
[02:28] <psusi> and I realized that these settings seem like they belong in the preferences gui rather than requiring the user to go digging around in gconf.  Is that correct?  Secondly, do you think this new page I added to the gui looks good or should it be done differently?
[02:29] <RAOF> psusi: Is there some reason why they're not identically equal to “lock screen on screensaver”?
[02:32]  * psusi is struggling to figure out photobucket
[02:32] <RAOF> Use Do's imageshack upload plugin!
[02:32] <psusi> RAOF, yea... I want my system to lock on hibernate, but not on suspend or general screen saver kicking in
[02:33] <RAOF> Why?
[02:34] <RAOF> I mean - that seems like a pretty *specific* desire.  Is it something that enough people will/should want to do that it is usefully exposed in preferences?
[02:36] <psusi> so you think that most people either want to always lock when the screen saver kicks in, or never?  so why bother adding the checkbox to the preferences dialog?
[02:37] <RAOF> Which checkbox?
[02:37] <psusi> http://i745.photobucket.com/albums/xx95/phreak0r/Screenshot-PowerManagementPreferences.png
[02:38] <psusi> that's what I've managed so far
[02:38] <RAOF> Ah.
[02:40] <RAOF> So, yeah.  I don't think having those options exposed makes sense.
[02:41] <psusi> so you think it should just start the screen saver and either universally lock or not based on the screen saver setting, unless someone figures out how to go into gconf and set the more specific settings?
[02:41] <RAOF> Yes.
[02:41] <psusi> why?
[02:43] <RAOF> Because those preferences are extremely niche.  If you want some security (lock my screen) then why is hibernate different from suspend?  And you should obviously also lock the keyring in that case, and have the screensaver unlock it.
[02:43] <RAOF> I'll admit that lock on screensaver might be sufficiently different to lock on suspend/hibernate, though.
[02:44] <psusi> RAOF, yea, I think plenty of people don't want it to lock every time they don't touch the keyboard for 5 minutes
[02:45] <psusi> I was also thinking of maybe using a drop down list with the options to lock on [suspend, hibernate, neither, both], but it was easiest to add a checkbox tied to the existing bool gconf key
[02:46] <RAOF> I'd say there should be at most one checkbox.
[02:47] <RAOF> I'd probably side towards locking iff the user needs to enter a password at login.
[02:55] <psusi> if the options are there though, why hide them from the gui?
[02:56] <RAOF> It's a tradeoff for users like you who want to do something strange :)
[02:56] <psusi> I was thinking about that the other night... it seems to be part of the gnome philosophy right?  if it's kind of esoteric, don't bother exposing it in the gui, make people use gconf?
[02:57] <psusi> seems like what we need is a secret keystroke to enable the gui equivalent of --verbose... something you can hit to say show me all the goodies! ;)
[02:57] <RAOF> gnome-plumbing.
[02:57] <psusi> ?
[02:57] <RAOF> That's the project you're thinking of :)
[03:00] <psusi> hrm... not finding much on it so far...
[03:00] <psusi> doesn't look like it ever got off the ground ;(
[03:03] <RAOF> I think there's at least *some* code, but you're right, it's not exactly taking the world by storm.
[03:04] <psusi> many applications have an "advanced" settings button to put all the esoteric stuff behind
[03:04] <psusi> it seems like gnome doesn't like that idea
[03:05] <RAOF> Right.  It clutters things up, encourages making options where fixing a problem would be better, and *everyone* hits the advanced settings button at some point.
[03:06] <psusi> how does it clutter things up?  it reduces clutter by hiding esoteric options unless you really want them?
[03:06] <RAOF> Well, it's an extra tab / button that doesn't have an obvious reason.
[03:07] <RAOF> It's a grab-bag of options that would naturally be elsewhere, but aren't because they're not important enough.
[03:07] <psusi> yea, but one button is a very small amount of clutter to continue to allow access to many options hidden behind it
[03:08] <psusi> I agree, rather than gather them all under one place, there should be a way to just make them show up in their natural position
[03:08] <psusi> a sort of global --verbose or I'm an advanced user option that makes them show up all over rather than in a tightly constrained grab bag
[03:09] <kklimonda> meh, you are talking like a real kernel hacker :}
[03:09] <psusi> not surprising ;)
[03:09] <psusi> I'm still getting used to this whole gui thing ;)
[03:10] <kklimonda> the magical button that toggles a number of options in the interface sucks - I've seen software that does that, and it's not pretty.
[03:10] <psusi> the underlines on accelerator keys are hidden until you hold down the alt key, maybe something like that could be done for more esoteric options
[03:10] <psusi> ohh?
[03:11] <psusi> why isn't it pretty?  and more importantly, how is it worse than forcing people to dig around in gconf? ;)
[03:11] <kklimonda> same for the --verbose flag - the problem with adding more buttons, checkboxes, tabs, and text entries is that they really clutter interface, and only a small minority of users is going to ever need them
[03:11] <psusi> well that's why they aren't shown normally
[03:12] <kklimonda> yeah - but they have to be there, they have to be designed, and taken into account.
[03:12] <psusi> yea
[03:13] <psusi> it's one thing if the devs don't feel like taking the time to add an option to the gui preferences screen because it is so esoteric... but if someone wants to take the time, the question is, how to do so that both avoids clutter for most people, but still provides the option for advanced users
[03:14] <kklimonda> psusi: but advanced users have gconf - there is nothing hard about it..
[03:14] <kklimonda> psusi: if something is popular enough there are tools like ubuntu-tweak or gnome-tweak (new tool in gnome3) that can provide ui for that.
[03:14] <psusi> kklimonda, ADVANCED users do, yes... but... well... not quite so advanced users don't ;)
[03:14] <psusi> those struggling in the middle are screwed
[03:15] <kklimonda> middle class is always getting shorter end of the stick :)
[03:15] <psusi> indeed
[03:16] <kklimonda> It's simply impossible to create something that fits all needs so we have to compromise. GNOME has always been about creating simple, and usable desktop.
[03:16] <kklimonda> KDE3 went the other way
[03:17] <kklimonda> and I still remember applications that had 3 different configuration dialogs :)
[03:18] <lifeless> kklimonda: actually, gnome /became/ about that; it wasn't initially
[03:19] <psusi> there should be a way to get the best of both worlds
[03:20] <psusi> that's why I started thinking of a magic key you can smack to verbose++
[03:21] <kklimonda> lifeless: right, I've oversimplified - I've meant GNOME 2, which has introduced HIG
[03:21] <psusi> that way it isn't clutter unless someone thinks to themselves, gee, I'm looking for something that seems like it should be here, I wonder if it's just hidden by default?
[03:22] <kklimonda> psusi: you will love the fact that in GNOME3 you can't even change Gtk+ theme without running gnome-tweak ;)
[03:22] <psusi> I've never even looked at gnome-tweak
[03:23] <kklimonda> it's a new project, created for GNOME 3
[03:23] <psusi> ohh, I was thinking ubuntu-tweak
[03:23] <lifeless> kklimonda: metacity 4 eva
[03:23] <kklimonda> it's called gnome-tweak-tool actually
[03:25] <kklimonda> psusi: you should really talk with mpt, or some other ux folks - they can explain the drawbacks of "advanced" button better.
[03:27] <psusi> kklimonda, I agree that it isn't good to lump all esoteric options under an advanced button... but there should be some way to tell the system that you are looking for more options and don't care if it adds clutter... telling users to use gconf just seems like a cop-out
[03:29] <psusi> the magical "zoom in and enhance", hehe...
[03:29]  * psusi asks for OPONIES while he's at it
[03:30] <kklimonda> -ENOPONIES :P
[03:30] <psusi> --use-the-force-luke
[03:31] <lifeless> so the whole thing about options is often misrepresented
[03:31] <lifeless> the thing is that *if* you can make it better without an option, that is clearly a win: simpler code, less defects, less maintenance
[03:31] <lifeless> easier for users to train each other because there is less variation
[03:32] <psusi> in other words, don't make it an option if it is a universally good change
[03:32] <kklimonda> there is no such thing like an "universally good change" but noone has said that you have to please everyone.
[03:33] <RAOF> And also *push back* on options before you've been convinced that it can't be done better.
[03:33] <kklimonda> right, once you have introduced some new setting, it's pretty much impossible to remove it :)
[03:34] <lifeless> jdubs recent series of posts about gnome culture have a pretty good analysis of this meme
[03:34] <kklimonda> you would have to rename your application, or rewrite a huge chunks of it.
[03:34] <psusi> that seems like an argument for changing/removing a feature rather than converting it to an option
[03:34] <lifeless> kklimonda: thats not true at all
[03:34] <lifeless> if you remove an option you need to be willing to wear the feedback
[03:35] <kklimonda> lifeless: feedback, not the outcry for restoring it, and threats of forking your application.
[03:35] <psusi> but if you decide to make it an option, why should it NOT be accessible without going into gconf was more the issue I was contemplating
[03:35] <lifeless> kklimonda: depends on the option obviously
[03:36] <lifeless> kklimonda: but if you've got *that many objectors* its pretty good data about the importance of supporting their use case.
[03:36] <psusi> lock on screen saver vs suspend vs hibernate is already an option, my question is, why is there no way to configure it in the g-p-m preferences dialog?
[03:37] <RAOF> It's a cop-out, basically.
[03:37] <kklimonda> psusi: I see options that are not available in the gui as situational tweaks.
[03:38] <kklimonda> psusi: by your definition we should provide gui for g-p-m to switch between suspend on the remaining batter %, or the remaining time
[03:38] <kklimonda> psusi: and then additional controls to tweak the numbers
[03:39] <lifeless> kklimonda: thats not what psusi argued at all though
[03:39] <kklimonda> lifeless: but you have to put the line somewhere.
[03:39] <lifeless> kklimonda: its not about the line
[03:39] <lifeless> kklimonda: its about asking how we can improve the syste,
[03:40] <psusi> kklimonda, if it's an option you can set via gconf, yes, why not?
[03:40] <lifeless> for instnace, on the time vs % issue, I don't see any use case for a % based limit *unless* time based limits are unreliable.
[03:40] <lifeless> And as it turns out, time based limits are terribly unreliable.
[03:41] <lifeless> g-p-m, for all its 500MB footprint, is terrible about remaining runtime estimation on my hardware.
[03:41] <lifeless> (and btw, 500MB for a battery manager? WTF!)
[03:41] <kklimonda> 500M of what?
[03:41] <psusi> huh?  it's 10mb
[03:42] <lifeless> virt, resident is 150MB
[03:42] <lifeless> sorry, 200MB
[03:42] <lifeless>  2354 robertc   20   0  448m 198m 2680 S    0  2.6   0:55.31 gnome-power-man
[03:42] <kklimonda> huh
[03:42] <kklimonda> 1000       850  0.0  0.7  78392 29164 ?        Sl   Mar29   0:00 gnome-power-manager
[03:42] <kklimonda> and I blame nvidia for that
[03:43] <psusi> lifeless, rss here is 8.7m
[03:43] <RAOF> Mine's 5.5m
[03:43] <lifeless> RAOF: want a bug ? :P
[03:43] <lifeless> RAOF: I just figured it was terrible
[03:44] <kklimonda> well, 500M is terrible :)
[03:46] <lifeless> yes, yes it is :)
[03:46] <RAOF> I'm not sure what to do with such a bug; a pmap might be interesting,though.
[03:46] <kklimonda> there are lots of settings in gconf that has probably been introduced years before, and now they can't remove them as they are used.
[03:47] <lifeless> RAOF: I can ubuntu-bug it up, if you like
[03:47] <psusi> vsz is in general, ridiculously huge, and should be ignored.
[03:47] <kklimonda> there are keys like /apps/gnome-search-tool/disable_quick_search_second_scan with description "This key determines if the search tool disables the use of the find command after performing a quick search."
[03:47] <kklimonda> or even /apps/gnome-search-tool/show_additional_options heh
[03:48] <RAOF> lifeless: You might as well, attaching pmap -x $(pidof gnome-power-manager); it's certainly a bug!
[03:49] <psusi> my g-p-m has 8792 rss and 176984 vsz... I've long given up on even looking at the vsz of gnome apps
[03:51] <lifeless> RAOF: shouldn't that be a apport hook ?
[03:52] <RAOF> lifeless: It's not common information to ask for.
[03:52] <psusi> hell, x-chat has a vsz of 426m but only 30.9m rss
[03:52] <lifeless> admittedly, its not as bad as chromium
[03:53] <lifeless> 740M for one web page
[03:53] <lifeless>  3085 robertc   20   0 1642m 739m 3100 S    0  9.6   1:10.51 chromium-browse
[03:54] <psusi> lifeless, yep... similar results here.. hence, ignore vsz, it's meaningless
[03:54] <lifeless> psusi: its only meaningless when its shared libraries
[03:54] <lifeless> psusi: when its swap, its meaningful
[03:54] <psusi> when it's shared anything
[03:54] <lifeless> sure
[03:54] <RAOF> It's annoying how difficult it is to distinguish between the two.
[03:55] <psusi> I've got no swap, but thunderbird is showing 858m virt, but only 139 rss and 30.9 shared
[03:55] <psusi> indeed
[03:55] <lifeless> 0000000000942000       0  194932  194256 rw---    [ anon ]
[03:56] <lifeless> RAOF: ^
[03:56] <RAOF> !!!
[03:57] <RAOF> Something is horribly broken.  Valgrinding it might reveal leaks, I guess.  Does it start out so big, or grow so over time?
[03:57] <lifeless> https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/745420
[03:57] <ubot2> Launchpad bug 745420 in gnome-power-manager "high res (and virtual) memory sizes" [Undecided,New]
[03:57] <RAOF> Please be to not dirtying 200MiB of memory.
[03:59] <RAOF> Hm.  In other “why are you so big” news… indicator-datetime-service probably shouldn't be using 270MiB RSS.
[04:00] <lifeless> RAOF: pmap is there
[04:01] <lifeless> RAOF: I'm not sure if it grows or not
[04:01] <RAOF> That should be pretty easy to check, though; just restart it?
[04:02] <lifeless> RAOF: sure
[04:02] <lifeless> but if there is stuff you want from the current process, should get that first
[04:03] <RAOF> Not that I can think of; my next step would generally be a valgrind check.
[04:06] <lifeless> RAOF: fresh started instance pmap attached to the bug
[04:07] <RAOF> Right.  So, it's leaking over time.
[04:10] <lifeless> RAOF: it seems to stabilise at 500m
[04:10] <lifeless> RAOF: so I suspect something like a cache
[04:10] <lifeless> RAOF: (500MB virt; 200M rss)
[04:11] <RAOF> That could be its time-to-empty/charge history feature happening.
[04:11] <lifeless> yeah
[04:11] <lifeless> I swap batteries from time to time, and go on off power a lot as I wander around
[04:12] <RAOF> I guess you could check natty?  I'll see if I can reproduce that by wandering around on/off power.
[04:23] <lifeless> RAOF: I should upgrade, just been afraid
[04:23] <RAOF> You can be a beta 1 tester :)
[06:18] <TheMuso> RAOF: Is there a way you can query X as to how much VRAM is available? I'd like to get an exact figure of how much VRAM my Thinkpad's Intel GPU is taking from system RAM.
[06:19] <TheMuso> More out of curiosity than anything else, the notebook has tons of RAM.
[06:21] <bryceh> TheMuso, there is xrestop which shows pixmap memory usage, which isn't total vram but it might give some insights
[06:21] <RAOF> TheMuso: I'm not sure that the question actually makes sense any more; I'm not sure that the GPU actually steals memory.
[06:22] <RAOF> Rather it'll dynamically acquire and release memory as necessary.
[06:22] <TheMuso> RAOF: Ah, that makes sense.
[06:22] <RAOF> Certainly before GEM/KMS it stole a fixed chunk of memory, but I don't *think* that's the case anymore.
[06:23] <TheMuso> bryceh: Thanks.
[06:24] <bryceh> TheMuso, cat /sys/kernel/debug/dri/0/*vram* shows some vram related data on my radeon.  ymmv
[06:25] <bryceh> # cat /sys/kernel/debug/dri/0/*vram* | tail -n 1
[06:25] <bryceh> total: 131072, used 37553 free 93519
[06:25] <TheMuso> Ok thanks.
[06:25]  * RAOF investigates what's new in intel /sys
[06:26] <RAOF> Oh, that's right.  /sys/kernel/debug is now restricted.
[06:27] <RAOF>  /sys/kernel/debug/dri/0/i915_gem_objects are what you're after.
[06:27] <TheMuso> ah ok
[06:28] <RAOF> I have ~500MiB worth of objects there, most of which are inactive.
[06:30] <TheMuso> I like the fact that the amount of RAM used for intel GPUs is now dynamic.
[06:30] <TheMuso> At least in Linux
[06:31] <TheMuso> One can only hope Windows does the same...
[06:31] <RAOF> I'd presume so; one of the prerequisites for DX 10 hardware/drivers is a sane memory manager.
[06:31] <TheMuso> Ah ok.
[06:32] <TheMuso> This is weird, in /sys/kernel/debug/dri I have 0 and 64.
[06:32] <RAOF> Yeah.
[06:33] <RAOF> I'm not entirely sure what the 64 is to be honest :)
[06:34] <TheMuso> Well I get the same on my desktop with my radeon card.
[06:34] <TheMuso> 0 and 64.
[06:35] <TheMuso> Speaking of Windows, one really nice thing that the Thinkpad power management software does is completely disable/hot unplug the optical drive when not in use for a period of time, to the point where Windows doesn't know its there, but power is still being fed to it.
[06:35] <TheMuso> So you press the eject button, and windows sees it again and you can use it.
[06:35] <TheMuso> Really neat.
[06:36] <RAOF> That's pretty cool.
[06:37] <RAOF> I'm in the market for a new laptop, but no-one seems to make the laptop I want :)
[06:38] <TheMuso> What do you want?
[06:40] <RAOF> Basically: I'd like a 13" macbook with a faster processor, discrete graphics card, and higher resolution screen :)
[06:40] <TheMuso> Right.
[06:41] <RAOF> There are any number of things which satisfy some subset of these critera, but nothing that satisfies all ;)
[06:42]  * TheMuso nods.
[06:42] <TheMuso> Nothing in the lenovo range?
[06:42] <RAOF> Oh, and a multitouch screen would be nice for actually, you know, *testing* the multitouch stuff Chase wants me to upload :)
[06:42] <TheMuso> haha
[06:43] <RAOF> The x220 is promising, but no discrete chip.  The new t420s might be what I'm looking for, although that's a bit bigger at 14" and has an nvidia chip rather than the ati chip I'd prefer.
[06:43] <TheMuso> Right.
[06:43] <TheMuso> Nice to know the discrete chip you want is AMD.
[06:44] <RAOF> That's not *entirely* because I expect it to work better; it's because it's the chip I'm most likely to be able to get wine working on with free drivers. :)
[06:44] <TheMuso> lol ok.
[06:44] <RAOF> I'd also expect it to work better out of the box, though.
[06:45] <TheMuso> What are you wanting to use in wine?
[06:45] <RAOF> Just have worse proprietary drivers.
[06:45] <RAOF> Civ 5, Portal 2, that sort of thing…
[06:45] <TheMuso> Ok so you want to play games, fair enough.
[06:45] <TheMuso> Things that are generally rather GPU intensive.
[06:45] <RAOF> There 'aint any other windows software I'm pining for!
[06:46] <TheMuso> Well I didn't know that. :p
[06:46] <RAOF> True
[06:47] <TheMuso> robert_ancell, RAOF, did either of you manage to see Four Corners on Monday night, about the A380 fault from last year?
[06:51] <RAOF> Oh, no I didn't.  That sounds quite topical!
[06:51] <RAOF> It should be on iview, though, so I'll watch it sometime!
[06:51] <robert_ancell> TheMuso, nope
[06:51] <robert_ancell> TheMuso, interesting?
[06:54] <TheMuso> Yes, they went through and talked about exactly what happened.
[06:54] <TheMuso> Including a rather elaborate re-enactment.
[06:54] <TheMuso> Yes, I suggest watching/downloading from iview.
[07:03] <pitti> Good morning
[07:17] <pitti> bryceh: FYI, fglrx is on the DVDs, coordinating with #u-release to accept it
[07:18] <tjaalton> pitti: huh?
[07:18] <pitti> in ship, no in the live session
[07:18] <tjaalton> ok
[07:19] <tjaalton> nvidia too?
[07:19] <bryceh> pitti, ah right, forgot
[07:20] <pitti> yes
[07:20] <pitti> I don't think it warrants rebuilding the DVDs, though; it's just in ship, not in the live session or anything
[07:20] <pitti> i. e. if people install it, they should get it from the archive
[07:22] <pitti> bryceh, tjaalton: ok, accepting
[07:22] <pitti> bryceh: I guess this package still has the ABI dep problem on amd64?
[07:22] <Amaranth> RAOF: btw iirc DX 11 requires a sane memory manager but the requirements were relaxed for DX 10 because nvidia couldn't get going in time for vista
[07:22]  * pitti -> vaccination, bbl
[07:25] <RAOF> Amaranth: nvidia?  I thought it was intel (cf: Vista Ready™ lawsuit)
[07:26] <Amaranth> RAOF: No, intel wanted a way for non-DX10 parts to be vista ready
[07:26] <RAOF> Regardless *some* version of DX requires a sane memory manager.  Oh, but if it's DX11 then there's no guarantee that intel has one; they have no DX11 parts.
[07:26] <RAOF> Amaranth: Ah, of course :/
[07:27] <Amaranth> RAOF: but back when we were having so much trouble with nvidia memory management and compiz I learned they didn't have it fully done on Windows either
[07:27] <RAOF> Aaaah.
[07:27] <RAOF> Yeah, that's not really something they'd needed to care too much about before.
[07:28] <Amaranth> RAOF: Remember everyone complaining about nvidia drivers when Vista was released? They were slow, buggy, etc
[07:28] <Sweetshark> Morning all.
[07:28] <Amaranth> morning Sweetshark
[07:28] <RAOF> Goooood morning.
[07:47] <ricotz> robert_ancell, hello
[07:48] <robert_ancell> ricotz, hey
[07:48] <ricotz> did you had a chance to look at libwnck3, basically it is what you started
[07:48] <robert_ancell> ricotz, I'm fine with the wnck package btw, please upload
[07:49] <ricotz> robert_ancell, ok
[08:00] <desrt> robert_ancell, ricotz; either of you guys know about this intense background flickering problem?
[08:00] <robert_ancell> desrt, in?
[08:00] <desrt> shell
[08:01] <desrt> on login or setting the background from the control centre, the background flickers very rapidly between the desired image and complete blackness for a couple of seconds before randomly settling on one or the other (ie: sometimes the background, sometimes blackness)
[08:01] <robert_ancell> desrt, in the GNOME3 PPA?
[08:01] <desrt> yes
[08:01] <ricotz> desrt, hmm, no, probably a driver issue?
[08:02] <desrt> it doesn't seem like a driver issue because the problem persists
[08:02] <ricotz> desrt, you were able and updated everything?
[08:02] <desrt> ricotz: i'm avoiding upgrades at the moment in order to reduce the number of things i accidentally pull in from your ppa :)
[08:03] <desrt> but i'm up to date as of yesterday
[08:03] <desrt> (it was happening before then for a day or two)
[08:03] <desrt> it almost looks like two things are fighting with each other to have the background be black or not
[08:06] <ricotz> desrt, is this on nvidia blob?
[08:06] <desrt> ironlake
[08:07] <desrt> +1 for awesome use of the word 'blob', though :)
[08:08] <didrocks> good morning
[08:08] <desrt> didrocks: sup?
[08:09] <didrocks> hey desrt, do you enjoy your trip? :)
[08:09] <desrt> ya.  it's going pretty nicely so far.
[08:09] <desrt> having fun with some of the PPAs at the moment
[08:09] <ricotz> desrt, yeah, best way to name it ;) -- cant find any bug reports for intel, but nvidia had a similar problem
[08:10] <desrt> ricotz: if we've seen the problem on nvidia and intel as well then maybe it's not a driver problem
[08:10] <ricotz> desrt, i am on 270.30 without problems though
[08:10] <desrt> hm.  interesting.
[08:10] <desrt> do you still experience the problem with slowness when notification icons are present?
[08:10] <didrocks> desrt: excellent. That's everytime the same kind of "fun" with drivers and such :)
[08:11] <ricotz> desrt, yes
[08:11] <desrt> so the weird thing is that i never had it before and then after upgrading maybe 4 days ago i had the problem, and have it 100% of the time
[08:11] <desrt> i should check my apt log...
[08:12] <ricotz> desrt, maybe a clutter bug then
[08:14] <desrt> it could have been really a lot of things
[08:14] <desrt> there was a massive number of upgrades
[08:14] <desrt> maybe it was libpcre
[08:15] <desrt> would be nice if we had apt-bisect :)
[08:16] <desrt> had an X server upgrade here too
[08:16] <ricotz> desrt, there seems to be workaround for the nvidia issue, perhaps it solves intel too http://bugzilla-attachments.gnome.org/attachment.cgi?id=157326
[08:17] <ricotz> desrt, you are running the x-stack from natty repo?
[08:17] <desrt> yes
[08:17] <desrt> nothing fancy there
[08:17] <desrt> ricotz: i'll try this patch.  give me a moment.
[08:18] <ricotz> just apply it and restart gnome-shell should be enough
[08:18] <desrt> ya.  that's what i'm doing
[08:18] <ricotz> ;)
[08:18] <desrt> not fixed
[08:18] <desrt> it was just changing the priority to 500, right?
[08:19] <desrt> ya...
[08:19] <ricotz> looks so, yes
[08:19] <desrt> it's an a substantially different offset in my version of the file
[08:19] <ricotz> does the flickering effect the whole screen or only a part of it?
[08:19] <desrt> just the background
[08:20] <desrt> and only when trying to set the background
[08:20] <ricotz> have you turned on the nautilus-desktop?
[08:20] <desrt> no.
[08:21] <desrt> maybe i should try that, though :)
[08:21] <desrt> is that a dconf key or something these days?
[08:21] <ricotz> i was thinking if you are using it, it might be the cause
[08:21] <ricotz> use can the gnome-tweak-tools
[08:22] <ricotz> http://git.gnome.org/browse/gnome-tweak-tool
[08:22] <desrt> ah.  i've heard rumours about this mythical tool
[08:22] <ricotz> you can start it right out of the source folder
[08:22]  * desrt hopes it is small
[08:23] <desrt> having nautilus draw the desktop fixes it
[08:24] <desrt> i love tweak tool!
[08:24] <ricotz> hmm, so i might need to turn it off then to see the problem :P
[08:26] <ricotz> nope, works fine
[08:28] <desrt> i'm tempted to leave nautilus rendering the desktop so i don't see the problem anymore :p
[08:29] <pitti> hey seb128
[08:30] <seb128> hellio pitti
[08:30] <seb128> how are you?
[08:31] <pitti> seb128: pretty good, thanks!
[08:31] <pitti> how about yourself?
[08:31]  * pitti prepares for a mixed release / patch pilot day
[08:36] <seb128> pitti, I'm fine thanks, ready for a mixed iso testing, bug triaging day
[08:51] <seb128> ok, pitti just beat me to the g-c-c button id thing while I was reviewing the commits
[08:51] <seb128> pitti, will you commit to the packaging vcs as well?
[08:51] <pitti> oh, sorry for overlapping then
[08:51] <pitti> seb128: already at it
[08:51] <seb128> ok
[08:52] <pitti> you are too fast!
[08:52] <seb128> pitti, btw the gtk bug just assigned to our team is an indicator issue and fixed in natty
[08:52] <pitti> oh, awesome, I didn't get to that one yet
[08:52] <seb128> pitti, btw do you watch all desktop bugs?
[08:53] <pitti> seb128: I don't, but I'm subscribed to oem-priority bugs
[08:53] <seb128> just wondering how you noticed the gcc one since it was not assigned to the team or anything
[08:53] <seb128> oh ok
[08:53] <seb128> it makes sense ;-)
[08:53] <pitti> I can't keep up with them all, I'm afraid -- I don't have seb128 powers
[08:54] <didrocks> pitti: (it's blackmagic) :) hey pitti!
[08:54]  * pitti hugs didrocks
[08:54]  * didrocks hugs pitti
[08:54]  * pitti hugs seb128 as well
[08:56] <pitti> seb128: and I need 4 more bug fixes to catch up with mvo :)
[08:57]  * pitti pats https://bugs.launchpad.net/~pitti/+assignedbugs?field.status=Fix+Committed  -- take that, mvo!
[08:57]  * pitti hugs mvo
[08:57]  * seb128 hugs pitti
[08:58]  * pitti gets into the plane seat
[08:59] <seb128> pitti, hum
[08:59] <seb128> pitti, happy piloting! ;)
[08:59] <pitti> thanks :)
[09:00] <pitti> seb128: what's the "hum"?
[09:01] <seb128> pitti, nothing, I was about to make a comment about bug fixed and didrocks but decided to not ;)
[09:01] <pitti> I've given up trying to chase him :)
[09:02] <didrocks> \o/
[09:03] <rodrigo_> morning
[09:03] <didrocks> hey rodrigo_
[09:04] <seb128> hey rodrigo_
[09:04] <seb128> we get quite some pygtk UnicodeDecodeError crashes nowadays
[09:04] <pitti> didrocks: looking forward to another 43 from https://bugs.launchpad.net/unity/+bugs?field.status=Fix+Committed :)
[09:04] <seb128> it's weird
[09:04] <seb128> did something change in regard of encoding, utf handling?
[09:04] <pitti> seb128: yeah, I fixed another bunch of them yesterday
[09:04] <pitti> 2.7 changed the unicode handling a bit to be a bit closer to 3.0
[09:05] <pitti> but some things actually work better now
[09:05] <mvo> pitti: oh? time to get into gears it seems ,)
[09:05] <didrocks> pitti: we decided to not stop at 42, still 2 days to go! :-)
[09:05] <mvo> (for me)
[09:06] <pitti> mvo: well, you are already -- you are first on the list (not counting ueber-didrocks)
[09:06] <seb128> mvo, hey, wie gehts?
[09:06] <seb128> pitti, bah, bug #745022, seems the bug pattern is not working?
[09:06] <ubot2> Launchpad bug 745022 in apport "apport-gtk assert failure: python: ../../src/xcb_io.c:462: _XAllocID: Assertion `ret != inval_id' failed." [Medium,New] https://launchpad.net/bugs/745022
[09:06] <mvo> seb128: danke, gut!
[09:07] <pitti> didrocks: bug 737467  perhaps? :-)
[09:07] <ubot2> Launchpad bug 737467 in compiz "compiz crashed with SIGSEGV in g_closure_invoke()" [Medium,Confirmed] https://launchpad.net/bugs/737467
[09:07] <seb128> pitti, bug #738939 is weird but seems to affect some users
[09:07] <ubot2> Launchpad bug 738939 in apport "apport-gtk crashed with TypeError in __init__(): must be a subtype of GObject" [Undecided,New] https://launchpad.net/bugs/738939
[09:07] <pitti> seb128: looking
[09:07] <pitti> seb128: (the bug pattern one first)
[09:08] <ricotz> seb128, hi, are icon theme updates still possible?
[09:08] <didrocks> pitti: should be fixed with the bunch of signal and handler disconnection that are already landed or about to lan :)
[09:08] <didrocks> land*
[09:08] <pitti> seb128: ah
[09:08] <seb128> the second one is not specific to apport, jockey has similar ones
[09:08] <pitti> <!-- bdmurray - 2011-03-23 disabling temporarily to see if it is still happening on natty.
[09:08] <seb128> pitti, oh ok, so yes, it is ;)
[09:08] <seb128> ricotz, define icon theme
[09:09] <seb128> ricotz, gnome-icon-theme-symbolic for example can be updated
[09:09] <pitti> seb128: bah, I can't even open the original bug any more
[09:09] <seb128> ricotz, we will not likely update g-i-t though
[09:09] <ricotz> seb128, elementary-icon-theme
[09:10] <seb128> ricotz, guess it can be updated, I've no clue about it but it's not on the default installation
[09:10] <seb128> so should be easier to get a freeze break approval
[09:10] <ricotz> seb128, yes the symbolic theme can be synced
[09:10] <seb128> ricotz, right, it's on my list of things to sync after the beta freeze
[09:10] <ricotz> elementary-icon-theme is the default for xubuntu and lubuntu
[09:11] <ricotz> seb128, ok
[09:11] <seb128> ok, so check with them
[09:11] <seb128> you will likely need a freeze break approval for the update with a rational
[09:11] <ricotz> seb128, alright
[09:17] <seb128> pitti, do you have any clue about that nautilus crash btw?
[09:17] <pitti> seb128: it's next on my list, but haven't had time for it yet
[09:18] <pitti> I don't seem to get it, so I'll need to play around with it (or stare hard at the trace and patches)
[09:18] <pitti> seb128: it's now the only "in progress" bug on my list, though
[09:18] <seb128> pitti, ok, rodrigo said he would have some extra time to help on some GNOME bugs now that he's done mostly with unity work
[09:18] <pitti> just patch pilot got in the way today
[09:18] <seb128> pitti, so maybe bounce him his way if you want
[09:18] <pitti> oh, feel free to steal, of course :)
[09:19] <seb128> rodrigo_, bug #740765 if you want to have a go to this one
[09:19] <ubot2> Launchpad bug 740765 in nautilus "nautilus crashed with SIGABRT in __kernel_vsyscall()" [High,In progress] https://launchpad.net/bugs/740765
[09:19] <didrocks> desrt: is there a convienent hidden function to transform a bitmask to a gvariant? :)
[09:19] <rodrigo_> seb128, ok
[09:19] <pitti> rodrigo_: if you have some time, would you like to have a look at bug 707705?
[09:19] <ubot2> Launchpad bug 707705 in vino "Vino not accepting incoming connection to more than a single desktop session when the "network_interfaces=lo" option is set" [Medium,Triaged] https://launchpad.net/bugs/707705
[09:19] <rodrigo_> pitti, yes
[09:20] <pitti> rodrigo_: that one is rather important for OEM
[09:20] <desrt> didrocks: array of booleans, or something?
[09:20] <pitti> rodrigo_: that would be appreciated
[09:20] <seb128> rodrigo_, ok, let's put those 2 on your buglist to start then
[09:20] <rodrigo_> pitti: are you working on https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/740765 ? it's in progress and assigned to you, or can I take it?
[09:20] <ubot2> Launchpad bug 740765 in nautilus "nautilus crashed with SIGABRT in __kernel_vsyscall()" [High,In progress]
[09:20] <seb128> rodrigo_, that's what I was just asking before pinging you
[09:21] <pitti> rodrigo_: TBH I think the other is more important; I think I can deal with the nautilus one (just not today, but we're frozen anyway)
[09:21] <seb128> if you read the backlog ;-)
[09:21] <didrocks> desrt: yeah, but that means I have to iterate to every bit in the mask, hence I wanted to know if there was already that in gvariant to avoid rewritting this. Seems not, so I'll, thanks! :)
[09:21] <seb128> rodrigo_, ok, start with the vino one then please
[09:21] <rodrigo_> ok
[09:21] <seb128> bah
[09:21] <seb128> something since yesterday is breaking my keypad, annoying
[09:21] <desrt> didrocks: i guess it will require about 4-5 lines :)
[09:22] <seb128> I swear it was working when I logged in
[09:22] <desrt> didrocks: why not send the bitmask as a uint, though?
[09:22] <pitti> seb128: oh, wait -- I debugged that with claire the other day
[09:22]  * pitti digs out IRC logs
[09:22] <pitti> seb128: does gconftool --recursive-unset /desktop/gnome/acces
[09:22] <pitti> sibility
[09:22] <pitti> sorry
[09:23] <pitti> seb128: does this help: gconftool --recursive-unset /desktop/gnome/accessibility
[09:23] <didrocks> desrt: I want to output it through dbus as a debug statement without firing up gcaltool each time to convert it back ;)
[09:23] <didrocks> desrt: ok, will iterate then!
[09:23] <pitti> seb128: it took me 2 hours to get to that when debugging claire's broken keypad after a maverick upgrade
[09:23] <pitti> (the upgrade apparently was unrelated, just coincidence)
[09:24] <desrt> didrocks: makes sense
[09:24] <desrt> didrocks: something that might be neat is an API in GObject to convert a registered flag type to a strv of the nicks of the individual bits that are set
[09:26] <seb128> pitti, ok, thanks, it was mousekeys_enable set to ture
[09:27] <seb128> true
[09:27] <seb128> I've turned a11y on and off the other day to try a bug but I didn't think it would have been related to the keyboard issues
[09:28] <seb128> pitti, you just saved me hours of head scratching ;-)
[09:28] <seb128> pitti, ;-)
[09:28] <pitti> \o/
[09:28] <didrocks> desrt: yeah, we are using enums right now, but that would be neat :)
[09:46] <kamstrup> mvo: good morning, have you seen https://bugs.launchpad.net/oem-priority/+bug/745243 ?
[09:46] <ubot2> Launchpad bug 745243 in unity-2d "[dash] wrong search result in Chinese" [Critical,New]
[09:47] <kamstrup> mvo: i was wondering if you had some working knowledge in xapian vs ibus/chinese..?
[09:52] <pitti> didrocks: btw, do you know about lp-set-dup <master> <bug1> <bug2> ..?
[09:53] <pitti> didrocks: it's very handy for duplicating a lot of bugs (which have dupes themselves), and isn't affected by timeouts
[09:53] <didrocks> pitti: oh no, I'll do that then, thanks a lot (no right now as I want to finish something first and the list of dup is long) :)
[09:53] <chrisccoulson> good morning everyone
[09:55] <pitti> hey chrisccoulson
[09:55] <chrisccoulson> hi pitti, how are you?
[09:55] <pitti> chrisccoulson: I'm great, thanks!
[09:56] <pitti> chrisccoulson: hey, *shhh*, want something sponsored? only five dollahs
[09:56] <seb128> hey chrisccoulson
[09:56] <chrisccoulson> heh :)
[09:56] <chrisccoulson> hi seb128
[09:56] <seb128> pitti, you can also directly open the duplicate page for the bug which has not timeout issue
[09:57] <pitti> didrocks: I can't do it myself, as you typoed the master bug (it's not 74167)
[09:58] <didrocks> pitti: don't worry, I'll do it :)
[09:59] <pitti> seb128: so you are saying bug 551809 is fixed in natty in some indicator bits? do you happen to know where?
[09:59] <ubot2> Launchpad bug 551809 in gtk+2.0 "gnome-settings-daemon crashed with SIGSEGV" [High,Triaged] https://launchpad.net/bugs/551809
[09:59] <pitti> seb128: (I don't see indicator stuff in the trace)
[10:00] <seb128> pitti, the most recent libappindicator upload
[10:00] <pitti> seb128: ah, thanks
[10:01] <pitti> duping to bug 729150 then
[10:01] <ubot2> Launchpad bug 729150 in libappindicator "libappindication crashes in gtkstatusicon code on update" [High,Fix released] https://launchpad.net/bugs/729150
[10:01] <seb128> right, you can read the bug if you are interested
[10:01] <seb128> but it might be a bug in gtk as well, they workaround it now though by stopping using gicon
[10:02] <seb128> pitti, it's happening basically for things using the notification area fallback (i.e when no indicator applet is in use) when the icons are updated
[10:04] <seb128>  
[10:04] <seb128> kamstrup, hey
[10:05] <seb128> kamstrup, so the gwibber account desktop is named "compte de microblogage" in french
[10:05] <seb128> kamstrup, but when I type "blog" in the application place it has no match, is that a bug?
[10:06] <seb128> or you don't do substring matching this way?
[10:10] <kamstrup> seb128: no substring matching
[10:10] <kamstrup> (and I think that's a feature :-))
[10:10] <seb128> kamstrup, well, having nothing matching "blog" sucks ;-)
[10:11] <seb128> kamstrup, what you basically say is that it should be adressed by adding keywords
[10:11] <seb128> ?
[10:11] <kamstrup> seb128: indeed. the .desktop metadata sucks in general, but that's part of a much bigger problem
[10:11] <kamstrup> the .desktop files where just not designed to have search friendly metadata
[10:12] <seb128> why don't you do subtring searches?
[10:12] <kamstrup> I think substring matching works for apps like Do and Synapse because the show *1* result. When you show many results they will just flood you with useless junk because there are so many matches
[10:13] <Amaranth> You could only do substring matching if you're not getting many matches normally
[10:15] <kamstrup> substring matching on 2,4k apps from the software center is not gonna be fun on a netbook
[10:16] <kamstrup> also seems that substring matching is just a band aid because the .desktop metadata is so bad
[10:16] <kamstrup> band aids are ok, if it improves the UX of course
[10:17] <seb128> well GNOME3 has a Keywords key in their .desktop to solve that issue
[10:17] <kamstrup> but my gut tells me that substring matching is a can of worms
[10:17] <seb128> so let's wait for next cycle
[10:17] <kamstrup> indeed
[10:17] <Amaranth> What are you searching now? The file name and the Name and Comment keys?
[10:17] <seb128> kamstrup, thanks
[10:17] <kamstrup> name, generic name, exec, and comment
[10:17] <kamstrup> with ranking boosted descendingly in that order
[10:21] <seb128> hum
[10:21] <seb128> pitti, wth?
[10:22] <seb128> pitti, how did you duplicate that g-s-d crash bug?
[10:23] <pitti> lp-set-dup 729150  551809
[10:23] <seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=646209 -> wrong component, bugzilla has a l10n component
[10:23] <ubot2> Gnome bug 646209 in general "Wrong time format shown at login screen (gdm) for locale pt-PT" [Minor,Unconfirmed]
[10:23] <seb128> pitti, so .po patches should be opened on l10n, locale concerned
[10:24] <pitti> seb128: hm, gdm only has "general" and "docs"?
[10:24] <seb128> so it reaches the translators
[10:24] <seb128> pitti,"l10n", not "gdm" ;-)
[10:24] <seb128> ups
[10:24] <seb128> sorry "product" l10n
[10:24] <seb128> component "pt"
[10:24] <pitti> ah, ok
[10:25] <seb128> pitti, dup -> please use launchpad, your lp-set-dup sent a mail by bug it reassigned where launchpad do it silently
[10:26] <pitti> seb128: LP timed out :/
[10:26] <seb128> pitti, use <bugnumber>/+duplicate
[10:26] <seb128> that should not timeout
[10:26] <seb128> it's a page with only the dup entry
[10:26] <pitti> ah, thanks; will remember next time
[10:26] <seb128> thanks ;-)
[10:27] <pitti> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=646209 fixed
[10:27] <ubot2> Gnome bug 646209 in Portuguese from Portugal [pt] "Wrong time format shown at login screen (gdm) for locale pt-PT" [Minor,Unconfirmed]
[10:27] <seb128> pitti, danke
[10:28] <seb128> pitti, it's basically the equivalent of opening the bug on the langpack for us
[10:28] <pitti> ah, after an unity --reset the "semi-maximize" actually works -- nice!
[10:28] <seb128> pitti, translators deal with translations on GNOME, not maintainers
[10:35] <mvo> kamstrup: thanks for the pointer, I have not seen this one yet. I need to look into it
[10:35] <mvo> kamstrup: though my chinese is that that great ;)
[10:39] <kamstrup> mvo: bugger, i was hoping you were fluent :-)
[10:44] <mvo> kamstrup: I look into it now, probably the xapian index that is not properly build with the localized names
[10:51] <seb128> pitti, can you add bug #572260 to your review list?
[10:51] <ubot2> Launchpad bug 572260 in gnome-menus "package python-gmenu 2.30.0-0ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/572260
[10:51] <pitti> seb128: sure
[10:51] <seb128> pitti, it seems lucid specific, just closed a bunch of duplicates though
[10:52] <seb128> well bug #608535
[10:52] <ubot2> Launchpad bug 608535 in gnome-menus "package python-gmenu 2.30.0-0ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/608535
[10:52] <seb128> could be the same issue
[10:52] <seb128> there is a suggested patch for it
[10:52] <pitti> will look at them both
[10:56] <Sweetshark> hmmm, when trying to do a build in my lucid pbuilder I get a lots and lots of errors after "dependency problems prevent configuration of pbuilder-satisfydepends-dummy", what might I be doing wrong?
[11:09] <mvo> kamstrup: I added info to the bug, I suspect its a non-systemwide chinese setting, that is currently known to not fully work (i.e. the xapian index is build for the defualt language only currently)
[11:15] <kamstrup> mvo: yeah, i was thinking something like that as well
[11:16] <kamstrup> mvo: do you do anything special to handle chinese - because it appears the matching is wrong for installed apps as well (where I create an in-mem index of the gnome-menu contents)
[11:18] <mvo> kamstrup: no special handling here, what is wrong exactly?
[11:18] <mvo> kamstrup: installed stuff looks fine for me, but I can't do searches as I don't know what to type into ibus :/
[11:18] <kamstrup> mvo: from what I can tell the lower unity window here should match Empathy, not the stuff that it actually does https://launchpadlibrarian.net/67620390/Screenshot.png
[11:22] <mvo> hm, ok
[11:22] <mvo> I think I will add code that builds multiple indexes
[11:22] <mvo> for each installed language
[11:23] <Amaranth> kamstrup: I thought you didn't do substring matching
[11:23] <kamstrup> Amaranth: prefix matching on each indexed term
[11:24]  * mvo goes to get some lunch
[11:24] <mvo> maybe chinese today ;)
[11:24] <kamstrup> So "aw" "bl" "po" all match "Awesome Blog Post!"
[11:24] <Amaranth> oh, I see
[11:25] <Amaranth> I thought you just did prefix matching of the entire Name
[11:25] <Amaranth> But you split on spaces
[11:25] <kamstrup> oh, yeah, that would be a bit limited
[11:25] <kamstrup> we split on non-alphanumeric characters right now I think
[11:26] <kamstrup> So "disp" matches "gnome-display-properties"
[11:29] <didrocks> pitti: oh nice, lp-set-dup dups as well duplicates of duplicates to the master bug as the UI does for a short time, excellent :)
[11:29] <Amaranth> kamstrup: That explains why I can search for "display" and get "Monitors" as a result
[11:29] <pitti> didrocks: yes, that's the main point of it; but see seb128's concern about email spam above
[11:29] <Amaranth> kamstrup: since it matches display in gnome-display-properties
[11:29] <pitti> didrocks: so it seems using /+duplicate is better
[11:30] <Amaranth> When I first saw that I actually thought you were doing tagging
[11:30] <didrocks> ok, too late for this one though, sorry seb128 :)
[11:34] <seb128> didrocks, no worry, I hate you now but it's ok ;-)
[11:34] <didrocks> seb128: it doesn't change then? :-)
[11:34] <kamstrup> Amaranth: hehe, no. We're just lucky with the metadata :-)
[12:08] <Amaranth> RAOF, bryceh: I thought everyone knew nvidia's libGL caused lots of extra memory usage
[12:08] <Amaranth> KDE even has some complex hack to avoid this because they have so many GL apps
[12:09] <Amaranth> I doubt you'll get them to change, it has been like this so long I believe even KDE3 had a similar hack
[12:09] <Amaranth> (looking at bug 725434)
[12:09] <ubot2> Launchpad bug 725434 in cairo "Nvidia drivers lead to extra memory usage for each process using libGL" [High,In progress] https://launchpad.net/bugs/725434
[12:10] <RAOF> I certainly didn't know that until I looked.
[12:12] <Amaranth> http://www.kdedevelopers.org/node/3959
[12:15] <Sweetshark> whats the story about gcj-native-helper? I had that as a dep in my last lucid release, but now I get "pbuilder-satisfydepends-dummy: Depends: gcj-native-helper which is a virtual package." in the pbuilder. Any hints?
[12:33] <ricotz> rodrigo_, hi :)
[12:34] <rodrigo_> hi ricotz
[12:34] <seb128> rodrigo_, can you add bug #740729 to your list?
[12:34] <ubot2> Launchpad bug 740729 in gnome-control-center "The indicators for gnome-control-center should be extended with icon/accessible descriptions." [Low,Triaged] https://launchpad.net/bugs/740729
[12:34] <rodrigo_> seb128, yes
[12:34] <seb128> thanks
[12:35] <seb128> I guess it's an easy one if you know what to do ;-)
[12:35] <ricotz> rodrigo_, great to have gnome-session ;), but there is a problem "default.list" shouldnt be installed
[12:35] <rodrigo_> ricotz, yes, that's not the only problem I've seen
[12:35] <rodrigo_> so still working on it
[12:36] <ricotz> rodrigo_, good, just wanted to point this out, good luck
[12:36] <rodrigo_> ricotz, thanks :-)
[12:36] <rodrigo_> ricotz, hmm, I merged it from debian, so it's wrong there also?
[12:37] <ricotz> rodrigo_, i am not sure how the handle desktop-file-utils
[12:37] <rodrigo_> ok
[12:37] <ricotz> the/they
[12:37] <seb128> rodrigo_, Debian used to ship defaults.list in gnome-vfs but we ship it in desktop-file-utils, it's easier to get updated there
[12:38] <rodrigo_> ah, ok
[12:38] <seb128> rodrigo_, if they moved it to gnome-session we should just update it to not install it
[12:38] <seb128> we want to keep it in desktop-file-utils, it's a smaller source and either to update
[12:39] <seb128> either->easier
[12:39] <rodrigo_> ok, I see
[13:04] <rodrigo_> desrt, oh, you got 2 approvals from r-t for my patch?
[13:12] <pitti> Sweetshark: hallo! would you mind to join #ubuntu-devel? all devs should be there, and it's easier for other teams to find people
[13:13] <desrt> rodrigo_: yup.  it's ready to go if you want
[13:13] <desrt> rodrigo_: but i think we should wait for ray to give his opinion
[13:13] <rodrigo_> desrt, well, let's wait a couple of days, for Ray's opinion
[13:14] <desrt> exactly
[13:14] <rodrigo_> ok, lunch then :)
[13:14] <rodrigo_> bbiab
[13:14] <desrt> :)
[13:17] <rickspencer3> pitti, seb128 any idea who I talk to about the new dialogs and such for setting the tz in the clock indicator?
[13:17] <Sweetshark> pitti: done
[13:17] <seb128> rickspencer3, mpt and mterry
[13:17] <mterry> seb128, hello
[13:17] <seb128> rickspencer3, do you have a specific issue? mterry fixed a stack of issues since the beta freeze
[13:17] <seb128> hey mterry
[13:18] <pitti> Sweetshark: danke
[13:25] <rickspencer3> seb128, well, someone here at millbank showed me some wonky things in the tz picker part that was worrying them
[13:25] <rickspencer3> I'll follow up with mterry
[13:28] <seb128> rickspencer3, things like "can enter unknow location without getting feedback" are known and fix commited
[13:28] <seb128> rickspencer3, ok, feel free to raise the issue there if you want
[13:29] <seb128> there is like 15 bugs fix commited that will land after beta in natty
[14:18]  * bcurtiswx waves to room
[14:19] <mterry> bcurtiswx, hi!  :)
[14:21] <bcurtiswx> hey mterry :)
[14:29]  * vish wonders if PETA knows about the commands chrisccoulson recommends! Bug #745350 ;p
[14:29] <ubot2> Launchpad bug 745350 in firefox "while working on Firefox/Gmail, my cat sit down on keyboard " [Undecided,Invalid] https://launchpad.net/bugs/745350
[14:30] <chrisccoulson> lol
[14:30] <chrisccoulson> shhhhhh, don't tell them
[14:30] <seb128> rodrigo_, do you know if bug #707007 is still an issue in GNOME3?
[14:31] <ubot2> Launchpad bug 707007 in gnome-control-center "Monitor Preferences dialog buttons lacks conformity with rest of OS" [Low,Confirmed] https://launchpad.net/bugs/707007
[14:31] <james_w> chrisccoulson, nice tag :-)
[14:31] <chrisccoulson> heh :)
[14:36] <kklimonda> chrisccoulson: this bug is missing the lolcats tag ;)
[14:36] <chrisccoulson> kklimonda, feel free to add it ;)
[14:36] <kklimonda> I would, I just can't think of a good comment :)
[14:37] <chrisccoulson> heh :)
[14:37] <chrisccoulson> i think we already used up all the available cat-related jokes ;)
[14:38] <kklimonda> well, I'm working on "cat got your tongue", but so far nothing has come out of it ;)
[14:39] <chrisccoulson> heh
[14:44] <dobey> mvo: ping
[14:45] <mvo> dobey: pong
[14:46] <dobey> mvo: hey, so i'm trying to use aptdaemon from C with dbus, but I am having a very hard time determining when everything is actually done.
[14:48] <mvo> dobey: is your code available somewhere? what is the problem exactly? that the signals are not good? or timing issues with them?
[14:49] <rodrigo_> seb128, looking...
[14:50] <dobey> mvo: it seems that when i get the ExitStatus signal in PropertyChanged, the install/configure of the package has still not yet completed, and it takes several seconds afterward to complete.
[14:51] <rodrigo_> seb128, we don't have 'close' button anymore, just 'Detect displays' on the left and 'Apply' on the right, so I guess it doesn't apply anymore
[14:51] <seb128> rodrigo_, ok thanks, so not worth reporting upstream ;-)
[14:52] <seb128> that will just get autosolved next cycle
[14:52] <seb128> tedg, bug #745115, can you make anything from the stacktrace?
[14:52] <ubot2> Launchpad bug 745115 in indicator-application "indicator-applet-complete crashed with SIGSEGV in g_cclosure_marshal_VOID__POINTER()" [High,Confirmed] https://launchpad.net/bugs/745115
[14:52] <seb128> tedg, https://launchpadlibrarian.net/67607315/Stacktrace.txt
[14:53] <seb128> tedg, it's missing the first functions for some reasons but it might have enough infos to be useful?
[14:53] <seb128> or do you need details?
[14:54]  * tedg clicks
[14:55] <tedg> seb128, Not sure, let me look at the code a minute.
[15:00] <mvo> dobey: hmmmm, is your code available somewhere?
[15:01] <tedg> seb128, I don't think so.  It seems most likely to be an accessible string change (the only code that has really changed there), but I don't see anything obviously wrong with what it's doing :-/
[15:01] <tedg> seb128, There is a bug about that update not working though.
[15:01] <seb128> tedg, ok, let's see if we can get a better stacktrace then
[15:01] <seb128> tedg, thanks for checking
[15:02] <dobey> mvo: it's just on my hard disk at the moment, but i can commit/push i guess
[15:02] <mvo> fwiw, unity consitently crashes for me (bug #742233) on my nviddia box
[15:02] <ubot2> Launchpad bug 742233 in unity "compiz crashed with SIGSEGV in nux::GraphicsDisplay::GrabKeyboard()" [Medium,Fix committed] https://launchpad.net/bugs/742233
[15:02] <mvo> dobey: or just mail it, I haven't seen a problem like this yet
[15:05] <seb128> rodrigo_, can you check on bug #737539 as well?
[15:05] <ubot2> Launchpad bug 737539 in gnome-settings-daemon "[launcher] The "Low disk space" warning appears with title "gnome-settings-daemon"" [Low,Confirmed] https://launchpad.net/bugs/737539
[15:05] <rodrigo_> seb128, yes
[15:06] <seb128> thanks ;-)
[15:06] <dobey> mvo: ok
[15:06] <seb128> rodrigo_, oh and bug #740726 to match the g-c-c one you had earlier
[15:06] <ubot2> Launchpad bug 740726 in gnome-settings-daemon "Gnome-settings-daemon should set icon/accessible descriptions for app indicators." [Undecided,Triaged] https://launchpad.net/bugs/740726
[15:06] <seb128> rodrigo_, and I think I'm done with bouncing you bugs for today ;-)
[15:07] <rodrigo_> seb128, heh
[15:07] <rodrigo_> seb128, just keep bouncing, no problem
[15:07] <rodrigo_> seb128, ok, https://bugs.launchpad.net/unity-2d/+bug/737539 is fixed in 3.0, I guess we can just provide a patch for the 2.32 package
[15:07] <ubot2> Launchpad bug 737539 in gnome-settings-daemon "[launcher] The "Low disk space" warning appears with title "gnome-settings-daemon"" [Low,Confirmed]
[15:08] <seb128> rodrigo_, right, just do a merge request if you can, I will merge it
[15:08] <rodrigo_> hmm, well, now that I see the screenshot, I think it's a bug in unity
[15:08] <rodrigo_> the dialog has the correct title
[15:08] <rodrigo_> so not sure what it needs for unity launcher to show the correct one?
[15:10] <seb128> rodrigo_, ok, I guess it's similar to bug #740844 then, I've asked robert_ancell to have a look to that yesterday so let's wait for him to come back
[15:10] <ubot2> Launchpad bug 740844 in unity ""Authenticate" window shows in launcher as "Polkit-gnome-authentication-agent-1"" [Low,Confirmed] https://launchpad.net/bugs/740844
[15:10] <rodrigo_> seb128, right, looks it's the same issue
[15:11] <rodrigo_> it looks to me it's on apps that don't set the app name by not calling gtk_init
[15:11] <rodrigo_> that is, daemons
[15:12] <seb128> rodrigo_, right, see what macslow wrote on the polkit bug
[15:12] <rodrigo_> ok
[15:12] <seb128> "something like g_application_set_application_id(app, _("Authenticate")) should be used."
[15:12] <seb128> still it seems there is no reason why those need to be patched, the launcher should be able to get the title
[15:13] <rodrigo_> yes
[15:13] <rodrigo_> because there are lots of apps/daemons that would do that
[15:13] <rodrigo_> g-p-m I guess also has the same problem
[15:18] <chrisccoulson> cyphermox, the firefox-stable PPA is fully translated now btw
[15:20] <cyphermox> chrisccoulson, cool!, thanks
[15:24] <ricotz> cyphermox, hi :), do you think it is still possible to split libnm-glib2 in two packages (libnm-glib2 and libnm-glib-vpn1)
[15:25] <ricotz> cyphermox, while shipping these two libs in one package will cause problem with the transition to nm0.9
[15:26] <cyphermox> right, but we can still split them later once we prepare the packages for 0.9
[15:27] <cyphermox> ricotz, I'll look into it
[15:27] <ricotz> cyphermox, there are already packages ;) and let people test them causes upgrade problems
[15:27] <cyphermox> ricotz, what do you mean?
[15:27] <ricotz> cyphermox, simply splitting them and make glib2 hard depend on glib-vpn1 should solve it without breaking anything
[15:28] <cyphermox> ricotz, yes, I get that, but upgrade problems?
[15:29] <ricotz> cyphermox, libnm-glib-vpn1 is still there and will be overwritten be the newer packaging
[15:29] <ricotz> one sec
[15:29] <ricotz> cyphermox, https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1606258/+listing-archive-extra
[15:32] <dobey> mvo: sent
[15:33] <mvo> dobey: thanks, I have a call now, I look when that is finished
[15:33] <dobey> mvo: ok, thanks
[15:33] <ricotz> cyphermox, so i mean there are file conflicts while the current natty package ships two libs in one package
[15:34] <cyphermox> ricotz, you might be missing some further changes to make that work properly, no?
[15:36] <cyphermox> ricotz, I'm not against it, I just want to really know what's going wrong in your case because if I do the split, I'll likely fall in the same holes ;)
[15:37] <cyphermox> ricotz, from what I see in your package, looks to me like it would be the soname change that's causing you pain, not the fact that the package is split
[15:37] <ricotz> cyphermox, i dont think so, the nmglib library got bumped to 4 and also depends on the vpn1 lib, but many packages are linked againt the nmglib2 which cant be uninstalled
[15:37] <cyphermox> that's another problem... you need to rebuild those too
[15:37] <ricotz> yes, and this bumps are causing the problem while shipping two public libs in one package
[15:38] <ricotz> cyphermox, i know that the dependencies would need a rebuild, but i might be possible two let the different nmglib version co-exist
[15:39] <cyphermox> oh, I see what you mean
[15:39] <ricotz> so this split would be actually a bugfix in my opinion ;)
[15:40] <cyphermox> ricotz, like I said, I'm not against it I just don't want to break things one month from release ;)
[15:40] <ricotz> and let the natty packaging hard depend on the vpn package would harm the current linking
[15:41] <ricotz> i know what you mean
[15:42] <cyphermox> ricotz, are you planning on rebuilding the VPN plugins too?
[15:43] <ricotz> cyphermox, not really, these packages are for testing gnome-shell
[15:44] <cyphermox> k
[15:44] <ricotz> and i was hoping since the vpn library version is the same it would work
[15:44] <ricotz> relying on upstream abi stability
[15:45] <cyphermox> ok.
[15:45] <cyphermox> so I'll get started on this, and let you know (shouldn't take long, and it's something I have to do anyway)
[15:45] <ricotz> so splitting the package is quite a proper fix though ;)
[15:45] <ricotz> cyphermox, alright, thank you
[15:46] <ricotz> cyphermox, make the vpn dependency unversioned or (>= 0.8.4)
[15:46] <cyphermox> ricotz, it's part of what I had to do to reduce the delta with debian
[15:47] <ricotz> ok
[15:55] <cyphermox> ricotz, can you file a bug about it please?
[15:57] <ricotz> cyphermox, can do, so it will be the 525th bug ;)
[15:57] <ricotz> these are many bugs :(
[16:02] <pitti> kenvandine, seb128, didrocks, rodrigo_: so the current rebuild test showed some FTBFSes (libgtop2, gnome-games, glib-networking, bamf): can we split them amongst us?
[16:02] <pitti> (mostly multiarch related)
[16:02] <didrocks> pitti: I can take bamf
[16:02] <kenvandine> sure
[16:02] <rodrigo_> pitti, fine by me
[16:02]  * kenvandine will take libgtop2
[16:02] <seb128> pitti, there is a libgtop in unapproved and I wanted to sync on debian so I can do this one
[16:03] <seb128> kenvandine, ^
[16:03] <kenvandine> ok
[16:03] <pitti> rodrigo_: https://launchpadlibrarian.net/67639771/buildlog_ubuntu-natty-i386.glib-networking_2.28.0-1_FAILEDTOBUILD.txt.gz looks easy, do you want to try this one?
[16:03]  * kenvandine takes gnome-games then
[16:03] <pitti> seb128: ah, thanks
[16:03] <rodrigo_> pitti, sure
[16:03] <pitti> erm, and what do I fix then?
[16:03] <kenvandine> hehe
[16:03] <pitti> well, I guess I'll wait for the next one then :)
[16:03] <seb128> pitti, there is a new version for the glib one in debian to sync, not sure if that would fix it
[16:03] <pitti> rebuild is ongoing, after all
[16:04] <ricotz> cyphermox, https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/745769
[16:04] <ubot2> Launchpad bug 745769 in network-manager "Update packaging according to libraries" [Undecided,New]
[16:04] <pitti> seb128: unlikely (see log), but I guess it's worth fixing the FTBFS on top of the latest unstable one indeed (<- rodrigo_)
[16:04] <pitti> kenvandine: I thought robert might want to take gnome-games
[16:04] <kenvandine> he would be best
[16:05] <kenvandine> but he isn't here now :)
[16:05] <kenvandine> humm, our gnome-games packaging branch is out of date
[16:06] <pitti> rodrigo_: if you have difficulties, please let me know and I can help you or take over
[16:06] <rodrigo_> pitti, seems easy from a 1st look, so trying, will ping you if it's not that easy :)
[16:06] <pitti> kenvandine: perhaps robert forgot to push?
[16:06] <pitti> rodrigo_: cool, thanks
[16:06] <kenvandine> mterry it appears :)
[16:06]  * kenvandine gets it in sync
[16:07] <mterry> kenvandine, ?
[16:07] <kenvandine> the latest bzr branch for gnome-games doesn't match what is in natty
[16:07] <pitti> seb128: https://launchpadlibrarian.net/67675825/buildlog_ubuntu-natty-i386.libgtop2_2.28.1-1ubuntu1_FAILEDTOBUILD.txt.gz
[16:07] <pitti> kenvandine: https://launchpadlibrarian.net/67645831/buildlog_ubuntu-natty-amd64.gnome-games_1%3A2.32.1-0ubuntu3_FAILEDTOBUILD.txt.gz
[16:08] <kenvandine> mterry, it was ages ago now
[16:08] <pitti> didrocks: https://launchpadlibrarian.net/67608122/buildlog_ubuntu-natty-i386.bamf_0.2.80-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:08] <pitti> FYI
[16:08] <kenvandine> pitti, thx
[16:08] <pitti> thanks guys, you rock
[16:08] <seb128> pitti, thanks
[16:08] <didrocks> pitti: yeah, I've it opened, looking why the gio module isn't built
[16:08] <rodrigo_> pitti, hmm, my 1st thought was to remove the rm command in debian/rules, but it builds fine on x86_64, so is it because on i386 it doesn't generate the .a files?
[16:08] <pitti> the test rebuild is about half through, so we should expect some more; I'll follow it and take some more
[16:08] <pitti> didrocks: gio recently changed the module dir for multiarch, didn't it?
[16:09] <pitti> rodrigo_: they might have changed the library path due to the new multiarch directories
[16:09] <rodrigo_> ah
[16:09] <didrocks> pitti: right!
[16:09] <seb128> dpm, hi, is there any way to see what the last unity template has been imported?
[16:09] <pitti> rodrigo_: so there might actually be some more to it, like also moving the libraries to the right destination, etc.
[16:10] <didrocks> pitti: should we upload now for post-beta or just pend the change in a vcs?
[16:10] <pitti> didrocks: as you prefer
[16:10] <pitti> didrocks: if it's likely that you'll get more changes post beta (like for bamf), vcs is probably enough
[16:11] <didrocks> pitti: ok, thanks! ;)
[16:11] <pitti> but as we have a frozen queue, uploading is fine
[16:11] <didrocks> let's avoid an upload for now, I'll upload if we have no more change after beta
[16:12] <nessita> seb128: ping
[16:12] <seb128> nessita, pong
[16:13] <nessita> seb128: can I ask you about your last comment on bug #722485? in theory, you (as user) should not be able to reach the devices tab if you have no UBuntu One credentials (having credentials == having your device configured)
[16:13] <ubot2> Launchpad bug 722485 in ubuntuone-control-panel ""Value could not be retrieved" keeps appearing ont the control panel" [Low,Triaged] https://launchpad.net/bugs/722485
[16:13] <seb128> nessita, what device?
[16:13] <nessita> seb128: your current computer
[16:13] <seb128> nessita, I've an account configured on my laptop, I'm syncing files
[16:14] <nessita> seb128: so, what do you mean with "the device tab display this error in red which is not a real user friendly way to say I've no device configured"?
[16:14] <seb128> nessita, well, I though device would be i.e a phone
[16:14] <rodrigo_> so, anyone on i386 can run this command: pkg-config --variable giomoduledir gio-2.0 ?
[16:14] <seb128> nessita, I've an account and I'm connected, I'm syncing files on u1
[16:14] <nessita> seb128: are you connected to the internet?
[16:14] <seb128> nessita, but I don't have any other computer or device identificated
[16:15] <seb128> nessita, yes, "File Sync is up-to-date" it says
[16:15] <didrocks> rodrigo_: /usr/lib/i386-linux-gnu/gio/modules
[16:15] <seb128> nessita, and files uploads if I copy those to the UbuntuOne folder
[16:15] <nessita> seb128: then, you're having any other kind of error. Could you please attach your log file to the bug report? (~/.cache/ubuntuone/log/controlpanel.log)
[16:15] <rodrigo_> didrocks, ok, on x86_64 it's /usr/lib/gio/modules, so that's the problem then
[16:16] <didrocks> rodrigo_: are you up to date? it seems it's /usr/lib/x86_64-linux-gnu/gio/module
[16:16] <didrocks> like for https://launchpadlibrarian.net/67612895/buildlog_ubuntu-natty-amd64.bamf_0.2.80-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:16] <dpm> seb128, otp, will be back to you later
[16:17] <rodrigo_> didrocks, hmm, not really, haven't upgraded in a few days
[16:17] <didrocks> rodrigo_: I think you don't have the multiarch love then :)
[16:17] <pitti> didrocks, rodrigo_: /usr/lib/gio/modules/ is still the fallback path for modules which haven't been converted to multiarch yet
[16:18] <rodrigo_> yeah
[16:18] <Amaranth> ah, lovely multiarch paths
[16:18] <Amaranth> I'll probably never remember them :)
[16:19] <didrocks> pitti: oh ok :)
[16:19] <pitti> Amaranth, didrocks, rodrigo_: FYI, the canonical library dir is /usr/lib/`dpkg-architecture -qDEB_HOST_MULTIARCH` now
[16:20] <pitti> in debian/rules /usr/lib/$(DEB_HOST_MULTIARCH) should also work
[16:20] <pitti> kenvandine: ^
[16:20] <didrocks> thanks :)
[16:21] <rodrigo_> pitti, well, in this case I guess it's better to use the gio-2.0 pkgconfig variable, as this is the same used in the upstream source, right?
[16:21] <kenvandine> thx
[16:21] <pitti> rodrigo_: right
[16:21] <rodrigo_> pitti, testing now a build with that on x86_64, and will do it on i386 as soon as it's ok
[16:21] <dpm> seb128, on the admin page I see "2011-03-25 18:18:38.414867+00:00" as the last update - does that sound ok? I can't see anything on the imports queue , but imported templates are deleted from the queue history after a couple of days (https://translations.launchpad.net/ubuntu/natty/+source/unity/+imports?field.filter_status=IMPORTED&field.filter_extension=pot)
[16:21] <dpm> re: unity template
[16:22] <pitti> rodrigo_: does the .pc have the correct multiarch already? (it ought to)
[16:22] <seb128> didrocks, ^
[16:22] <seb128> didrocks, dpm: ok, I guess it imports the upstream outdated one since the rules update is failing
[16:22] <seb128> dpm, thanks
[16:22] <seb128> dpm, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/745774
[16:22] <ubot2> Launchpad bug 745774 in unity "the translation template update is broken" [High,Confirmed]
[16:22] <rodrigo_> pitti, not on my system, which is not up-to-date, but updating now
[16:23] <didrocks> will fix that just after bamf
[16:23] <didrocks> one pbuilder at a time ;)
[16:23] <dpm> seb128, ah, ok, thanks for the heads up. Yeah, it probably imports the non-updated pot in the tarball
[16:23] <didrocks> dpm: there is a variable issue, too bad we don't know which latest update contained a change though
[16:40] <didrocks> ok, seems slangasek beat me for bamf while I was fixing it :)
[16:40] <seb128> so maybe I should wait to not duplicate work ;-)
[16:41] <seb128> pitti, ^ did you sync with steve to make sure we don't all dup work?
[16:41] <pitti> seb128: doko was discussing the general issues with slangasek, but I didn't ask Steve about particular packages yet
[16:41] <pitti> I did tell doko, though
[16:41] <pitti> or, rather, he asked the desktop team to look into those
[16:44] <seb128> ok
[16:53] <seb128> pitti, the upload robert_ancell did yesterday for libgtop seems to fix the build
[16:53] <seb128> so you can cross that one from the list
[16:56] <pitti> seb128: cool, thanks
[16:59] <rodrigo_> pitti, lp:~rodrigo-moya/ubuntu/natty/glib-networking/fix-ftbf <- builds fine on x86_64 (with upgraded glib), so testing now on i386 and if it works there, I'll submit
[17:01] <dobey> mvo: any luck?
[17:03] <mvo> dobey: not yet, but the meeting only ended ~15min or so ago)
[17:06] <dobey> mvo: oh wow, ok. long call :)
[17:07] <mvo> dobey: foundations call and then irc meeting :)
[17:07] <dobey> mvo: that's ok. i just finished lunch :)
[17:08] <mvo> dobey: I don't see anything obvious, I would like to debug a little bit, but I need more of the code for it. I need to go for dinner soon, could you just mail me more (or point me to a repor?). I can check it out tomorrow morning then
[17:16] <dobey> mvo: ok
[17:18] <mvo> thanks!
[17:21] <rodrigo_> pitti, ok, builds fine on both 64 and 32 bits, so https://code.edge.launchpad.net/~rodrigo-moya/ubuntu/natty/glib-networking/fix-ftbf/+merge/55588 is up for review/merge/upload
[17:38]  * didrocks hugs pitti for dh_translations :)
[17:39] <didrocks> pitti: however, what do you think about an env var to force intltool to be used? It doesn't here because we are using cmake and there is no intltool official support last time we checked with neil (we are abusing bzr export for this)
[17:40] <didrocks> pitti: or maybe, I can base on  GETTEXT_PACKAGE, and assume we are using intltool with that
[17:43] <pitti> re (sorry, was busy in a phone call)
[17:43] <pitti> rodrigo_: yay you! I'll sponsor in a bit, thanks
[17:44] <pitti> rodrigo_: ah, that looks great; would you mind sending the patch to Debian as well?
[17:44] <pitti> rodrigo_: they will get multiarch soon as well, then it'll hit them as well
[17:44] <pitti> and it can already be applied as it is right now
[17:48] <pitti> didrocks: GETTEXT_PACKAGE in po/Makefile isn't intltool specific
[17:49] <pitti> didrocks: I'm fine with a variable to force intltool, but I wonder if we can autodetect it in this case?
[17:49] <pitti> didrocks: i. e. should we always call intltool if we are using cmake/
[17:49] <pitti> ?
[17:49] <didrocks> pitti: I'm going to assume that for now if that's fine with you, I didn't see any support i cmake
[17:50] <pitti> sure
[17:50] <pitti> didrocks: as this is currently undefined, feel free to define it :)
[17:50] <didrocks> pitti: heh, just doing it! ;) building unity to check it's updated
[17:56] <kenvandine> pitti, should girepository-1.0 go in the multiarch libdir as well?
[17:56] <kenvandine> i don't have anything there yet, but that seems weird
[17:57] <pitti> kenvandine: hm, good point -- as they seem to be platform specific, I guess they should
[17:57] <kenvandine> i just wonder if that breaks anything
[17:57] <kenvandine> we don't seem to have anything there yet
[18:14] <dobey> pitti, didrocks: you can detect intltool from po/Makefile
[18:14] <pitti> kenvandine: more importantly, does our current g-i actually look in the multiarch dir?
[18:14] <pitti> dobey: does that exist with cmake?
[18:14] <didrocks> dobey still, cmake doesn't have po/Makefile
[18:14] <dobey> pitti: intltool doesn't support cmake
[18:15] <didrocks> dobey: that's what I told, see above
[18:15] <kenvandine> dobey, i am going to test that theory :)
[18:15] <kenvandine> whoops
[18:15] <kenvandine> pitti, ^^
[18:15] <kenvandine> dobey, sorry :)
[18:15] <dobey> heh
[18:15]  * kenvandine eats lunch first though :)
[18:15] <dobey> didrocks: ok, well i'm confirming as intltool maintainer that we don't support it :)
[18:16] <didrocks> dobey: any plans btw? We are making ugly things in unity to workaround that ;)
[18:16] <didrocks> pitti: can you have a look at rev 168 of pkgbinarymangler to see if I didn't screw everything
[18:17] <pitti> didrocks: any chance you can write a little test for this?
[18:17] <dobey> no current plans, no. i don't kno whow cmake works exactly, and generally avoid it if possible :)
[18:17] <didrocks> pitti: oh sure, but little little then! :-) </kidding>
[18:18] <didrocks> dobey: maybe after natty we can have look at that together?
[18:18] <pitti> didrocks: a test_dh_translations_cmake, similar to test_dh_translations_python()
[18:19] <pitti> didrocks: hm, I wonder if we actually need the po/Makefile checks in build_pot
[18:19] <dobey> didrocks: maybe. we can chat in budapest if you want
[18:19] <didrocks> dobey: that would be nice!
[18:19] <pitti> didrocks: perhaps it would be sufficient to always call intltool-update with -g?
[18:19] <pitti> didrocks: and just check if we have $domain
[18:20] <pitti> didrocks: but the code looks good to me
[18:20] <didrocks> pitti: I wanted to avoid widespreading the impact, hence this check
[18:20] <pitti> didrocks: only nitpick: please fix the version number to be 94 :)
[18:20] <pitti> didrocks: we've got test cases for everything, so I think cleaner code wins
[18:20] <didrocks> pitti: oh oh ;)
[18:20] <didrocks> pitti: adding the check and fixing that
[18:20] <didrocks> pitti: ok, in that case, removing that
[18:21] <pitti> and also, I'd like to keep having tests for everything, as inevitably we'll get the n+first build system which we also need to support, and then we mustn't break the older stuff
[18:21]  * didrocks flushes && -e
[18:21] <pitti> didrocks: and no didrock@localhost in changelog :)
[18:21] <didrocks> pitti: agreed, doing that now
[18:21] <pitti> didrocks: cheers
[18:21] <didrocks> pitti: that will teach me working on my sandbox :p
[18:35] <Sweetshark> pitti: Now here is a strange one: The build almost completes but on lucid a call to "dh_link -i" complains about a symlink, which it did not on maverick. Any idea why? The "-i" and calling it without any further parameter is not documented, so I am a bit confused by it.
[18:36] <seb128> tedg, hey
[18:38] <tedg> seb128, Howdy
[18:38] <seb128> tedg, will the file, close default menu go away in natty?
[18:39] <seb128> tedg, I'm asking to know if I still need to backport the gtk patch to get the menu translated or if I should not bother
[18:39] <tedg> seb128, It will for Unity, but stay for applet.
[18:39] <seb128> ok, so still worth backporting it
[18:39] <seb128> thanks
[18:51] <cyphermox> ricotz, I have packages ready for NM in my PPA with the changes we discussed
[18:54] <rodrigo_> pitti, what's the proper way to send a patch to debian?
[18:55] <pitti> rodrigo_: http://www.debian.org/Bugs/Reporting is the canonical method
[18:55] <rodrigo_> ok
[18:55] <pitti> rodrigo_: there's a script submittodebian which automates this
[18:55] <pitti> I haven't used it much
[18:55] <rodrigo_> ah, cool!
[19:00] <kenvandine> pitti, so the answer is no... GI doesn't look in the multiarch libdir
[19:02] <didrocks> pitti: ok, rev 170 sould fix + add a test (which pass, unbelieavable \o/ ;))
[19:02] <didrocks> dinner time, bbl
[19:05] <ricotz> cyphermox, looks good and installs fine :) could you add a debdiff to the bug report
[19:06] <pitti> didrocks: cool, thanks! bzr diff -r 167.. looks fine to me
[19:07] <pitti> didrocks: just fixed the indentation in r171
[19:08] <cyphermox> ricotz, I'll upload that as soon as I can ;)
[19:09] <ricotz> cyphermox, great and hopefully it will be accepted
[19:09] <cyphermox> bbl
[19:20] <didrocks> pitti: thanks! Should I upload or should we wait for tomorrow? (not sure if you have other pending changes planned). Next unity will build-dep on it
[19:22] <cyphermox> ricotz, just confirmed that the vpns work too
[19:33] <desrt> does anyone know darren's email address?
[19:34] <ricotz> cyphermox, great
[19:35] <desrt> the man is ungoogleable
[19:42] <pitti> didrocks: feel free to upload, I have nothing
[19:43] <didrocks> pitti: ok, doing then. thanks :)
[20:33] <sirgad> Hey. Anyone here now how to configure gconf settings or similar on a LiveCD to offer default settings on boot?
[20:35] <pitti> rodrigo_: sponsored
[20:49] <Sarvatt> anyone have any idea why compiz doesn't even try to start up in a unity session with fglrx? http://paste.ubuntu.com/587508/ it just goes to a classic session instead, yeah I'm using the unity daily PPA
[20:49] <Sarvatt> if I unity --replace it comes up fine, except I can't kill the gnome-panel
[20:50] <Sarvatt> remove fglrx, the unity session works fine again
[20:51] <didrocks> Sarvatt: run /usr/lib/nux/unity_support_test -p and check as well the exit code
[20:52] <Sarvatt> http://paste.ubuntu.com/587512/
[20:53] <didrocks> Sarvatt: and the exit code?
[20:54] <Sarvatt> 234?
[20:54] <didrocks> Sarvatt: should be 0, something else means it doesn't work…
[20:55] <didrocks> hence the fact that gnome-session fallback
[20:55] <didrocks> Sarvatt: the test tool is changing starting tomorrow and rewritten from scratch, so hopefully, this will be fixed
[20:55] <Sarvatt> sarvatt@sachiel:/etc/X11$ DISPLAY=:0 /usr/lib/nux/unity_support_test -p || echo $?
[20:55] <Sarvatt> ..spam
[20:55] <Sarvatt> 234
[20:56] <didrocks> yeah, that's why it fallback
[21:06] <Sarvatt> hrm, wonder if it's https://launchpadlibrarian.net/67681186/compiz_1%3A0.9.4git20110322-0ubuntu6%2Br2720%2B201103291330_1%3A0.9.4git20110322-0ubuntu6%2Br2723%2B201103301010.diff.gz
[21:07] <Sarvatt> the compiz check is whats failing
[21:07] <didrocks> Sarvatt: no, because you can run compiz… and it was a match in the name
[21:08] <didrocks> Sarvatt: so, the test tool has nothing "compiz" in its name
[21:08] <didrocks> Sarvatt: anyway, as told, it's rewrittent and the new version will land tomorrow once beta released
[21:08] <didrocks> Sarvatt: so, compiz is working for you from the ppa + fglrx driver?
[21:09] <Sarvatt> yeah, unity too, just the session isn't starting it right
[21:12] <didrocks> Sarvatt: yeah, so hopefully the new unity test tool will fix it
[21:32] <cyphermox> anyone got a moment to look over https://code.launchpad.net/~mathieu-tl/ubuntu/natty/ubuntu-mono/icon-cache/+merge/55629 and sponsor it ? :)
[21:33]  * didrocks waves goodbye, just too tired right now :)
[22:33] <pitti> good night everyone
[23:02] <kenvandine> robert_ancell, ping
[23:02] <robert_ancell> kenvandine, hey
[23:02] <kenvandine> hey!
[23:03] <kenvandine> during the multiarch rebuild gnome-games is one of the packages that fails to rebuild
[23:03] <kenvandine> i took a swing at fixing it... but didn't nail it yet
[23:03] <kenvandine> robert_ancell, can you finish it off?
[23:04] <kenvandine> i pushed my changes to the ~ubuntu-desktop branch
[23:04] <kenvandine> dh_girepository: Could not find library libgames-support-gi.so.0
[23:04] <kenvandine> make: *** [binary-predeb-IMPL/aisleriot] Error 2
[23:04] <kenvandine> is the current error
[23:04] <robert_ancell> kenvandine, sure.  man gi, vala, dso linking, multiarch - they're really trying to make our life hard!
[23:04] <kenvandine> indeed
[23:04] <kenvandine> :)
[23:05] <robert_ancell> kenvandine, oh, I fixed that in the GNOME3 branch, I can do that
[23:05] <kenvandine> with libdir set to $${prefix}/lib/$(DEB_HOST_MULTIARCH)
[23:05] <kenvandine> oh... then you can revert any changes i made :)
[23:05] <kenvandine> woot
[23:05] <kenvandine> robert_ancell, thx!
[23:05] <robert_ancell> it's a private library, so dh_girepository goes mental.  I have a patch that moves the typelib to a private location so it doesn't even notice it
[23:05] <kenvandine> robert_ancell, out of curiousity, why doesn't the typelib get put in a separate gir package?
[23:06] <kenvandine> great!
[23:06] <kenvandine> :-D