[00:13] <chrisccoulson> robert_ancell - so, this crash might be a gconf issue
[00:14] <chrisccoulson> when an application calls gconf_client_add_dir for the first time, there should eventually be a call to CORBA_ORB_init
[00:14] <robert_ancell> chrisccoulson, right
[00:14] <chrisccoulson> but this never gets called again because it assumes it remains initialized
[00:14] <chrisccoulson> even after shutdown_orb is called
[00:15] <chrisccoulson> in gconf_get_config_listener()
[00:15] <chrisccoulson> thats the interesting bit
[00:16] <chrisccoulson> anyway, i'm going to have to stop looking at this for tonight, else i will never sleep
[00:16] <chrisccoulson> it will take me the whole night just to wind down ;)
[00:16] <robert_ancell> chrisccoulson, sleep on it! :)
[00:17] <chrisccoulson> i should comment on the bug report really, else i will just forget it all by morning ;)
[02:23] <Amaranth> hmm, that seahorse bug sounds like a fun bug compiz used to have with gconf
[06:57] <amin888> i need some help.... i installed nvidia driver NVIDIA-Linux-x86-190.42-pkg1.run manually for GeForce 7300 LE since Hardware Drivers show empty driver... the installation is succefull and i can play 3D game... but i can't have compiz started ???
[06:57] <amin888> btw this is for Ubuntu 9.10
[08:30] <pitti> Good morning
[08:34] <didrocks> good morning pitti
[08:36] <pitti> hey didrocks
[08:39] <mpt> mvo, good morning. Should software-center trunk still work on 9.10?
[08:42] <mvo> mpt: yes
[08:43] <mvo> mpt: is it not for you?
[08:43] <mpt> mvo, no, I get "NameError: global name 'os' is not defined" whenever navigating to an application screen
[08:43] <mpt> File "/home/mpt/hacking/software-center/softwarecenter/distro/aptutils.py", line 36, in get_release_date_from_release_file
[08:43] <mvo> mpt: oh, give me a sec
[08:43] <mvo> mpt: I fix that
[08:45] <mvo> mpt: r420
[08:46] <mpt> mvo, that's changed the error: it's now "NameError: global name 'datetime' is not defined"
[08:47] <mpt> mvo, File "/home/mpt/hacking/software-center/softwarecenter/distro/Ubuntu.py", line 122, in get_maintenance_status
[08:48] <mvo> mpt: heh :) let me switch to a karmic machine to test
[08:48] <seb128> good morning desktopers
[08:49] <mpt> mvo, on another topic, I don't see a 1.0 branch on the Branches page. Should there be one? Or is lp:ubuntu/karmic/software-center enough for that?
[08:49] <mvo> mpt: the karmic branch is the 1.0 branch, we can create a explicit name if you prefer that
[08:50] <chrisccoulson> good morning seb128
[08:50] <seb128> hey chrisccoulson, how are you?
[08:51] <chrisccoulson> good thanks - it's nearly the weekend :)
[08:51] <chrisccoulson> how are you?
[08:51] <mpt> mvo, I don't mind, just as long as there's somewhere to apply critical 1.0.x fixes if there are any (and to turn on the angled path button by default, perhaps)
[08:51]  * seb128 wonder if chrisccoulson ever sleep, he's up after everybody and already there in the morning too
[08:51]  * seb128 wonder if chrisccoulson ever sleep, he's up after everybody and already there in the morning too
[08:51] <seb128> chrisccoulson, good thank you
[08:51] <chrisccoulson> heh, i don't sleep very much ;)
[08:51] <chrisccoulson> although i have been to bed before 2am several times recently
[08:53] <mvo> mpt: please try r421
[08:54] <mpt> mvo, that works, thanks :-)
[08:55] <seb128> "Launchpad will be going offline for maintenance in five minutes. "
[08:55] <seb128> urg
[08:55] <mvo> mpt: is this  https://wiki.ubuntu.com/SoftwareCenter?action=AttachFile&do=get&target=1.0-available-category.jpg still desired? or will that change again for 2.0 ? otherwise I give it a short at implementing it now
[08:55]  * mvo wants something more exciting than bug triage
[08:56] <seb128> mvo, launchpad is going down so you will be forced into it ;-)
[08:57] <seb128> mvo, there is plenty of merges and updates too
[08:58] <mpt> mvo, I'd give that a 60% probability, though I need to discuss the layout with ivanka
[08:58] <mpt> mvo, there are other things that are both more certain and probably more exciting :-)
[08:58] <mvo> mpt: what do you have in mind ?
[08:58] <mvo> mpt: for 60% I won't start
[08:59] <mpt> fair enough -- one moment
[08:59] <pitti> seb128: FYI, versions.py failed over night (for some mystical reason index/lucid/var was removed completely)
[08:59] <pitti> running now
[09:00] <seb128> hey pitti
[09:00] <seb128> ok thanks
[09:00] <seb128> grrrr at robert_ancell
[09:00] <seb128> hard to make him things he has not interest in
[09:01] <seb128> he started full steam on 2.29 but doesn't seem to care about merging on debian
[09:01] <seb128> let's wait for him to join tonight ;-)
[09:02] <mpt> mvo, there's this <https://wiki.ubuntu.com/SoftwareCenter#cancel-bar>
[09:02] <mvo> you promisied "more exciting"
[09:02] <mpt> mvo, or this <https://wiki.ubuntu.com/SoftwareCenter#Handling%20an%20externally-changed%20apt%20cache>
[09:02] <mpt> oh, foo
[09:03] <mpt> The intersection of {more exciting} and {fully specified} is mainly Clutter animations
[09:03] <mpt> at the moment
 and <https://wiki.ubuntu.com/SoftwareCenter#Animation%20of%20the%20main%20pane>
[09:04] <mvo> mpt: is https://wiki.ubuntu.com/SoftwareCenter?action=AttachFile&do=get&target=1.0-installed-home.jpg (as a treeview) still the plan?
[09:05] <mvo> mpt: what will it do when packages are activated? still a treeview?
[09:06] <mpt> mvo, that's subject to the same 60% certainty -- if we change how we present departments, the "Installed Software" section will change to look much more similar to the "Get Software" section
[09:06] <mvo> mpt: ok
[09:16] <chrisccoulson> was there an announcement for LP going offline?
[09:17] <chrisccoulson> (or perhaps it just got lost in my inbox)
[09:17] <seb128> I didn't read one
[09:18] <chrisccoulson> i can't find one either
[09:18] <chrisccoulson> it seems we never get announcements any more
[09:41] <huats> morning
[09:42] <seb128> lut huats
[09:43] <huats> hello seb128 !
[09:44] <seb128> cassidy, hey
[09:44] <seb128> cassidy, should we sync telepathy-gabble 0.9.2 in lucid?
[09:45] <seb128> ie is that the right version for this cycle?
[09:45] <cassidy> seb128, this version still have regressions comparing to the 0.8.x branch but hopefully that should be fixed for the Lucid release
[09:46] <seb128> hum
[09:46] <seb128> seems a "no" ;-)
[09:46] <seb128> thanks
[09:46] <cassidy> and we'll probably use new feature from this version in Emapthy 2.30 so I'd say to go for it
[09:46] <seb128> well
[09:46] <cassidy> tbh, the main regression is the proxy support which has always be broken so...
[09:46] <seb128> "should be fixed" is not good for a lts
[09:46] <cassidy> oh, LTS, right
[09:46] <seb128> we need to aim for something which will be stable by lucid time
[09:46] <seb128> not something which might be in the middle of unstable serie
[09:47] <cassidy> you can keep 0.8 for now and I'll let you know when we think 0.9 is good enough to replace it
[09:47] <seb128> thanks
[09:47] <cassidy> 0.8.x is still well maintained as that's the version shipped with Maemo 5
[10:08] <seb128> cassidy, is empathy supposed to unhide the list on the same workspace it was?
[10:08] <seb128> or on the current workspace?
[10:09] <seb128> when you click on the notification area icon
[10:09] <seb128> using compiz
[10:09] <cassidy> ahah, good question. IIRC we uses gtk_window_present() whose behaviour is unclear
[10:09] <seb128> if that makes a different
[10:09] <cassidy> and depends of your WM
[10:09] <seb128> ok
[10:09] <cassidy> (I know that sucks)
[10:10] <seb128> dunno what pidgin do but that works
[10:10] <seb128> it open the list on the workspace where you are
[10:10] <seb128> the empathy behaviour is driving me crazy
[10:10] <seb128> I work on several workspace and the list never opens where I'm working
[10:10] <cassidy> we have lot of troubles with that; seems lot of WM are broken
[10:10] <Zdra> seb128, I really want some WM guru to take a look
[10:10] <cassidy> seb128, do you have that in house? :)
[10:10] <Zdra> seb128, because IMO it is *all* WM that are broken
[10:11] <Zdra> and each version is broken in a different way
[10:11] <cassidy> I just tried and the contact list appear on the active desktop
[10:11] <cassidy> (metacity)
[10:11] <seb128> the best wm guru we have there is Amaranth
[10:11] <Zdra> rb/pidgin does ugly hacks to position the window
[10:11] <seb128> dunno what hack they do but that works mostly
[10:11] <seb128> you could maybe copy some of those
[10:11] <cassidy> seb128, some help on this issue would be really appreciated
[10:11] <seb128> alright
[10:11] <Zdra> seb128, they reposition manually the window on the desktop and the position/size
[10:11] <seb128> noting that for sprint and UDS
[10:11] <Zdra> which should be useless
[10:12] <seb128> but we don't have wm gurus either
[10:12] <cassidy> we'd prefer to have the bugged code fixed properly (in Empathy, WM, ...) than adding more hack
[10:12] <seb128> that's not going to happen though
[10:12] <cassidy> afaik it works fine with metacity
[10:12] <Zdra> cassidy, that's what I keep saying for years... but really that need WM guru to look into. I don't know enough how it works
[10:13] <seb128> it's an user story fail for empathy meanwhile
[10:13] <Zdra> I'm prepared to be told empathy is doing something wrong, but I would like to know the real reasons, not just pull hacks to make it work by hiding the real defect
[10:13] <seb128> cassidy, the issue is that as you said the gtk function behaviour is not defined
[10:13] <seb128> and the gtk issue is open for years
[10:13] <cassidy> we already tried different hack and they always fix one case and broke others
[10:13] <seb128> I appreciate you don't want to have hacks but meanwhile your software look buggy compared to others
[10:14] <Zdra> tbh I almost never had any problem using ubuntu with metacity and its compositor
[10:14] <seb128> Zdra, the main issue is that the gtk call behaviour is not defined
[10:14] <Zdra> but other users report problems even in the exact same configuration... that's crazy
[10:14] <seb128> ie should present bring you to the dialog, bring the dialog to you or just raise it
[10:15] <seb128> it's let to the wm to decide right now
[10:15] <seb128> so with some wm you will get the dialog on your workspace
[10:15] <seb128> some others will change the active workspace
[10:15] <seb128> some others will make it claim for attention in the taskbar
[10:16] <Zdra> seb128, the biggest problem reported by users is that the window position is reset to left/top corner after unhide the window
[10:16] <seb128> there is that issue
[10:16] <Zdra> seb128, and that is not supposed to be WM-dependent, the position really should be remembered
[10:17] <seb128> and the fact that using compiz it doesn't show it on the right workspace
[10:17] <seb128> I will put it on the lucid list of issues so we look at it
[10:17] <Zdra> seb128, for the move to desktop, give focus, etc, I can understand empathy should do it, because it is not guaranteed by gtk_window_present
[10:17] <seb128> but I think you will have to workaround in empathy
[10:17] <seb128> the gtk behaviour not being defined is the issue
[10:17] <seb128> and it will require spec changes and gtk changes
[10:17] <seb128> which I doubt will happen quickly
[10:17] <cassidy> Zdra, did we try to use the same hacks as rb ?
[10:18] <Zdra> cassidy, no
[10:18] <Zdra> cassidy, I saw it and told "I don't want to be responsible of such a hack"
[10:18] <cassidy> maybe that's something we should try
[10:18] <seb128> let's be pragmatic in some case hacks are required to make the user experience good
[10:19] <cassidy> yeah :(
[10:19] <Zdra> IIRC other app does gtk_window_hide() gtk_window_show() instead of gtk_window_present() to be sure it is forced to be moved to current ws
[10:19] <seb128> I will try to see what we can do for a proper fix there
[10:19] <seb128> but as said if that require xdg spec changes and gtk changes it will take a while
[10:19] <seb128> so meanwhile we will want to workaround
[10:20] <seb128> Zdra, seems to be a good way if that works
[10:20] <Zdra> seb128, tbh the whole concept of window hiding in the status icon is not well supported in GNOME
[10:20] <Zdra> seb128, note that even rb is not unbreakable, I already had window possition issues with it ;)
[10:21] <Zdra> I think the best hack is in piding
[10:21] <Zdra> pidgin
[10:21] <Zdra> best in the sense of works the best, not the nicer
[10:23] <seb128> right
[10:23] <seb128> as said pidgin seems to work fine for users
[10:23] <seb128> ie we get no complain about it
[11:44] <seb128> Laney, hey
[11:44] <seb128> Laney, do you want to sru the new f-spot update?
[11:45] <seb128> to sru = to work on the sru changes
[11:56] <Laney> seb128: yeah, maybe tomorrow
[11:56] <seb128> Laney, ok thanks
[12:28] <pitti> chrisccoulson: would you have some time for another SRU? (bug 463353)
[12:29] <pitti> sorry for delegating, SRU management and UDS planning pretty much eat all my time these days
[12:29] <pitti> or seb128?
[12:29] <chrisccoulson> pitti - yeah, i can take a look at that
[12:29] <chrisccoulson> do you want to assign it to me? (i'm just about to go for lunch)
[12:30] <seb128> pitti, I will let chrisccoulson look at this one, I have only today left as work day before sprint and uds
[12:30] <pitti> chrisccoulson: thanks muchly; will do
[12:38] <mvo> asac: around?
[12:39] <seb128> mvo, he's on vac for the week
[12:40] <mvo> *pff*
[12:40] <mvo> seb128: thanks :)
[12:40] <seb128> mvo, you're welcome
[12:40] <seb128> mvo, what you mean by *pff* is *slacker* right? ;-)
[12:40] <mvo> seb128: I just wanted his feedback on the "XB-Restart-Required idea
[12:40] <mvo> seb128: yeah
[12:40] <mvo> :P
[12:40] <seb128> what is that?
[12:41] <seb128> oh
[12:41] <seb128> you want to be able to know in advance what will need a restart
[12:41]  * seb128 switches channel for the discussion
[15:04] <seb128> urg
[15:06] <seb128> pitti, there is 2181 i386 crash bug in the retracer queue
[15:06]  * seb128 look to the amd64 one
[15:06] <rickspencer3> bonjour seb128 what's the matter?
[15:06] <seb128> hey rickspencer3
[15:06] <seb128> rickspencer3, just 2181 crash bugs in launchpad which have not been retraced yet
[15:07] <seb128> on i386
[15:07] <rickspencer3> *sigh*
[15:07] <chrisccoulson> seb128 - they're not all seahorse-agent crashes are they?
[15:07] <chrisccoulson> ;)
[15:07] <seb128> chrisccoulson, could be, we will know when they will be retraced...
[15:07] <seb128> chrisccoulson, still looking for bugs?
[15:08] <chrisccoulson> seb128 - i don't think we're going to get away without fixing the seahorse-agent crash - the crash reports are still flying in quite quickly even with apport disabled by default
[15:08] <chrisccoulson> seb128 - did you have any bugs in mind?
[15:08] <seb128> chrisccoulson, bug #442130
[15:08] <seb128> chrisccoulson, we should add a bug pattern for the seahorse crash
[15:08] <seb128> chrisccoulson, that would block bug filing pointing to the open bug
[15:09] <chrisccoulson> yeah, that might be a good idea
[15:09] <chrisccoulson> seb128 - i'll take a look at that gvfs one later as well then
[15:10] <seb128> chrisccoulson, thanks
[15:10] <seb128> 892 amd64 crash bugs to retrace
[15:10] <chrisccoulson> seb128 - are you not here next week?
[15:10] <seb128> chrisccoulson, I will be traveling on monday and then be on us time
[15:10] <seb128> and sprinting
[15:11] <chrisccoulson> ah, ok
[15:11] <seb128> I will probably be there but on different hours
[15:11] <chrisccoulson> it's going to be quiet in here next week
[15:11] <seb128> and not as much as I usually do
[15:12] <chrisccoulson> i'll probably have a baby by the time you arrive back from the US. when she decides that she wants to arrive!
[15:13] <seb128> oh right
[15:13] <seb128> you are going to have short nights for other reasons soon ;-)
[15:13] <seb128> you are going to have short nights for other reasons soon ;-)
[15:13] <seb128> ups
[15:13] <kenvandine> chrisccoulson, when we stop seeing you everyday, we will assume the baby came :)
[15:14] <chrisccoulson> lol
[15:14] <chrisccoulson> i think i should just forget about sleep entirely!
[15:14] <kenvandine> sleep is overrated
[15:14] <chrisccoulson> that's what i keep telling people ;)
[15:14] <chrisccoulson> but sometimes i feel like i could sleep at work
[15:15] <chrisccoulson> probably not the best place to fall asleep ;)
[15:15] <kenvandine> hehe
[15:15]  * kenvandine was replacing the brakes on my car at midnight last night... i would rather have been sleeping... but if i am hacking on stuff i would prefer that to sleep :)
[15:18] <chrisccoulson> kenvandine - i take it you have a source of light to be able to work on your car that late at night?
[15:18] <chrisccoulson> i can't do anything to mine at the moment, as it's dark when i get back from work
[15:20] <kenvandine> garage
[15:21] <kenvandine> i need a bright portable light though
[15:21] <kenvandine> the overhead lights aren't great for working under fenders :)
[15:21]  * kenvandine has some busted up knuckles today from not being able to see well
[16:11] <pitti> seb128: ugh
[16:11] <pitti> seb128: does it keep breaking on the same bug, or does it make progress?
[16:11] <seb128> pitti, it makes progress
[16:11] <seb128> pitti, retraced 50 bugs between the 2 recent restart
[16:12] <pitti> ok, and today's crashes were due to the LP rollout, I guess
[16:12] <seb128> I'm suprised we keep getting so many crash bugs
[16:12] <seb128> is apport still on in karmic?
[16:13] <seb128> pitti, they crash every hour
[16:13] <seb128> gateway errors
[16:13] <seb128> or permission errors
[16:20] <Laney> seb128: what's the bug # for the unclickable button in --view mode?
[16:23] <seb128> Laney, bug #448162
[16:23] <Laney> thanks
[16:23] <Laney> testbuilding
[16:24] <seb128> thank you
[16:48] <pitti> rickspencer3: do you know whom to subscribe to a bug report about "Add Service Tag and support URL in System Monitor"?
[16:48] <pitti> rickspencer3: (someone from OEM?)
[16:49] <rickspencer3> yes, bfox
[16:49] <pitti> thanks
[16:50] <Amaranth> eep I'm subscribed to a blueprint for a UDS session
[16:50] <pitti> Amaranth: I just subscribed you, yes
[16:50] <Amaranth> I'm not going to be there :P
[16:50] <pitti> thought you were interested in following/commenting on the blueprint
[16:50] <Amaranth> sure
[16:51] <Amaranth> cube by default == no way :)
[16:51] <seb128> what blueprint?
[16:51] <pitti> Amaranth: if you aren't, please unsubscribe again and accept my apology about the spam
[16:51] <seb128> oh, set of effects to use
[16:51] <pitti> Amaranth: see, that's why I subscribe you :)
[16:51] <rickspencer3> cube by default == yea baby
[16:51] <rickspencer3> also, flaming cursor
[16:51] <pitti> rickspencer3: it looks ridiculous on slower hw, though
[16:51] <Amaranth> rickspencer3: we'd have to switch to 4 workspaces by default too
[16:51] <seb128> pitti, don't fall into the troll
[16:51] <Amaranth> hehe
[16:51] <pitti> see, the subscription was useful :)
[16:51] <rickspencer3> thanks seb128
[16:52] <seb128> ;-)
[16:52]  * pitti ignores the flamewar^Wbikeshed^Wdiscussion and goes on with planning
[16:52] <Amaranth> There are some things we should change though...
[16:52] <Amaranth> for example, the video plugin is completely useless
[16:52] <rickspencer3> I thought the "flaming cursor" part was a bit of give away
[16:52] <Amaranth> rickspencer3: I liked that part
[16:52] <rickspencer3> Amaranth, anything we can remove to speed up load time?
[16:53] <Amaranth> rickspencer3: You can test my branch to speed up load time and see if that helps :)
[16:53] <rickspencer3> sweet
[16:53] <rickspencer3> tbh, I would like to turn on the cube if possible
[16:53] <rickspencer3> but sounds like there will be some serious issue
[16:53] <Amaranth> otherwise if we strip plugins we consider worthless it could help a little too
[16:53] <Amaranth> less for it try to find
[16:53] <rickspencer3> but when I show the cube, it gets people really interested
[16:53] <seb128> would it make a difference to put everything now on by default in an -extra binary
[16:53] <seb128> and have that not installed?
[16:54] <seb128> now -> not
[16:54] <rickspencer3> maybe add Cube to the High Level of effects option?
[16:54] <Amaranth> seb128: it could help a little
[16:54] <seb128> Amaranth, a little only? what is all the time spent?
[16:54] <Amaranth> seb128: it'd at least make people not enable cracktastic things without thinking
[16:54] <seb128> compiz takes 10s if there is nothing to read too?
[16:54] <Amaranth> seb128: well most of the time seems to have been spent in that shell script...
[16:55] <Amaranth> otherwise it only loads information for plugins it has loaded
[16:55] <seb128> ok, let's see how it goes with your version first
[16:55] <Amaranth> so not shipping a plugin would save a stat call or whatever
[16:55] <Amaranth> on the other hand the ccp plugin loads information for every single plugin
[16:55] <seb128> it's weird that a piece of shell takes 15 seconds to run
[16:56] <Amaranth> but it uses protobuf so it's pretty fast and there isn't as much IO
[16:56] <Amaranth> compiz itself uses DOM + XPath to load XML for the plugins that are loaded
[16:57] <Amaranth> robert_ancell seems to have added something to compiz to tell what part is taking the most time, he might have a better idea of where any potential bottleneck actually is
[16:57] <Amaranth> at least it loads faster than gnome-shell ;)
[16:59] <chrisccoulson> gconf is a bottleneck on my desktop
[16:59] <chrisccoulson> 4 seconds
[17:00] <Amaranth> yeah, that'd be ccp
[17:00] <Amaranth> so not shipping as many plugins would help some there
[17:00] <Amaranth> since ccp loads the info for all of them
[17:00] <chrisccoulson> oh, i meant gconfd starting is the bottleneck on mine
[17:00] <Amaranth> oh :)
[17:00] <chrisccoulson> this is before compiz starts
[17:02] <chrisccoulson> wow, i wish my company would spend some money on some decent laptops
[17:17] <Riddell> pitti, dpm: we have https://blueprints.edge.launchpad.net/ubuntu/+spec/community-lucid-kubuntu-translations-feedback-and-improvements and https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-kubuntu-translations  I propose to replace them with kubuntu-lucid-translations
[17:18] <mvo> Amaranth: I did a profiling patch some tme ago for compiz, should be in bzr
[17:18] <Amaranth> mvo: oh, that was you
[17:19] <Riddell> asac: can we have a kubuntu firefox session to look at the KDE firefox integration bits?
[17:21] <dpm> Riddell, that's fine by me, but I'd like to be able to add info to the spec, at least move the summary in the community blueprint to the desktop one
[17:22] <pitti> Riddell: WFM; I didn't really put a lot of meat into it, so we can just invalidate it
[17:23] <dpm> Riddell, also, the <track>-lucid- name I think should be kept for consistency with other sessions on the Desktop track
[17:23] <Laney> seb128: I added SRU stuff and opened a Karmic task on bug 448162. We'll get it to Lucid by a sync.
[17:23] <Riddell> dpm: I'm planning on using kubuntu-lucid for all our kubuntu ones, I have scheduling powers now I'm told so we're partly a track to ourselves
[17:24] <seb128> Laney, thanks
[17:24] <pitti> Riddell: done
[17:24] <dpm> Riddell, ahaaa, then feel free to use the superpowers and move it to the Kubuntu track
[17:24] <Laney> thank you for triaging and chasing
[17:24] <Riddell> pitti: what have you done?
[17:25] <pitti> Riddell: marking desktop-lucid-kubuntu-translations as superseded by community-lucid-kubuntu-translations-feedback-and-improvements ?
[17:26] <Riddell> pitti: I wanted to make a kubuntu-lucid-translations the superseed them both
[17:26] <pitti> Riddell: ah, there's a third one; sure, please go ahead
[17:26] <Riddell> there will be
[17:28] <pitti> you can also just rename the existing one, FYI
[17:28] <pitti> Riddell: ^
[17:28] <pitti> (if everything else in it is correct, that's easier)
[17:29] <Riddell> so I can, that's clever
[18:00] <dpm> pitti, ccheney` I was thinking about having a dedicated session on OO.o translations, but seeing that there is https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-openoffice already, do you think it might be a better idea to discuss translations in there as well instead?
[18:31] <mac_v> djsiegel: ping... sent the mail.. sorry, for sending it late ... i forgot about it :(
[18:31] <djsiegel> oh, thanks mac_V!
[18:31] <djsiegel> n
[18:31] <djsiegel> np
[18:33] <mac_v> :)
[18:40] <chrisccoulson> hmmmm, i'm really confused about how screensaver inhibiting works at all in totem
[18:40] <chrisccoulson> it calls Inhibit on the wrong dbus path
[18:40] <chrisccoulson> :-/
[19:11] <pitti> chrisccoulson: perhaps that's the s3kr1t bus that works :)
[19:37] <mclasen> chrisccoulson: if you look at gnome-screensaver, it actually registers an object at that path
[21:04] <chrisccoulson> mclasen - sorry, i went away
[21:04] <chrisccoulson> my gnome-screensaver only registers a path at "/"
[21:04] <chrisccoulson> :(
[21:04] <mclasen> the other one doesn't show up in d-feet
[21:05] <chrisccoulson> ah
[21:05] <mclasen> don't know why
[21:05] <chrisccoulson> mclasen - totem always gives me this warning:
[21:05] <chrisccoulson> WARNING **: Problem inhibiting the screensaver: Method "Inhibit" with signature "ss" on interface "org.gnome.ScreenSaver" doesn't exist
[21:05] <chrisccoulson> but the inhibit is registered
[21:05] <mclasen> oh, interesting
[21:06] <chrisccoulson> and this is why totem isn't cleaning them up properly for me, because it *thinks* it failed to register it, and so doesn't save the cookie
[21:06] <chrisccoulson> i'm a bit confused why i seem to be the only person with this problem though
[21:08] <seb128> did you try with an another user or a guest session?
[21:09] <chrisccoulson> seb128 - one second, i will try that now
[21:12] <chrisccoulson> hmmm, that's wierd - it works ok from the guest account
[21:43] <chrisccoulson> well, i'm totally confused!
[21:47] <seb128> Ampelbein, hum, if totem is crashing that's a totem problem ... not true
[21:48] <seb128> ups
[21:48] <seb128> Amaranth, ^
[21:48] <Amaranth> seb128: it's certainly not a compiz problem :)
[21:48] <seb128> Amaranth, and not a totem one either
[21:48] <Amaranth> seb128: totem or one of the libraries it uses (nvidia fail again?)
[21:49] <seb128> I just hate those bugs about video crashing when compiz is on
[21:49] <seb128> nobody wants to take responsability for those
[21:49] <Amaranth> heh
[21:49] <seb128> I would like to know where to reassign it
[21:49] <seb128> totem is wrong but xorg or compiz would bounce back
[21:49] <Amaranth> If it's not a crash in compiz I have no idea
[21:49] <seb128> so we are stucked with useless replies
[21:50] <Amaranth> see if you get can a backtrace from him or something
[21:50] <seb128> I did ask for one
[21:50] <Amaranth> but then again you can't tell with nvidia and X, only with nvidia OpenGL
[21:50] <Amaranth> (if the nvidia driver is the cause, I mean)
[21:50] <seb128> but I guess it will be one of those xerror due to limited video ressources
[21:56] <seb128> hey robert_ancell
[21:56] <robert_ancell> seb128, hey
[21:57] <seb128> robert_ancell, thanks for the update, some notes though
[21:57] <robert_ancell> always with the notes :)
[21:57] <seb128> 1, could you please do the merges on debian?
[21:57] <robert_ancell> yeah, I knew you were going to get me on 1
[21:57] <seb128> I know it's no fun
[21:57] <seb128> but it's no fun for your coworkers either
[21:58] <seb128> so let's share those and not just dump the task on others ;-)
[21:58] <robert_ancell> :P
[21:58] <seb128> 2- I'm not sure if we should run into 2.29
[21:58] <robert_ancell> ?
[21:58] <seb128> it's probably fine for the ones you did
[21:59] <seb128> but we should check upstream roadmap
[21:59] <seb128> we don't want to get stucked in the middle of refactoring
[21:59] <seb128> especially that GNOME3 will likely be 2.32
[21:59] <robert_ancell> oh, is that what you've heard?
[21:59] <seb128> and some maintainer can decide to skip 2.30 or have it an unstable version toward GNOME 2.32
[22:00] <seb128> well, since the gnome-shell guys mailed d-d-l saying gnome-shell will not be ready before 2.32
[22:00] <Amaranth> seb128: plus if GSettings makes it we probably don't want to try to transition to that in lucid
[22:00] <seb128> ie will only be a tech preview version this cycle
[22:00] <seb128> Amaranth, no
[22:01] <seb128> things I'm not sure we should change count glib and gtk
[22:01] <seb128> I know it's not going to be popular
[22:01] <seb128> but I'm not sure it's the right cycle to get gvariant, dconf, etc early changes
[22:01] <Amaranth> so I would stay away from everything GNOME that uses gconf until the decision for gsettings/dconf is made
[22:01] <robert_ancell> Amaranth, i.e.  every package?
[22:01] <Amaranth> robert_ancell: yeah, pretty much
[22:01] <seb128> Amaranth, dconf you mean there no?
[22:02] <Amaranth> seb128: eh? I said dconf
[22:02] <seb128> I didn't get why staying away from apps using gconf
[22:02] <seb128> in case they migrate mid cycle you mean?
[22:03] <Amaranth> right
[22:03] <Amaranth> If you upload 2.29.1 now then 2.29.2 switches to gsettings...
[22:03] <seb128> that's a good point
[22:03] <seb128> I doubt dconf will be ready this cycle though
[22:03] <seb128> they are still discussing migration strategies
[22:04] <seb128> they will probably land the glib, etc changes required
[22:04] <seb128> and have dconf working and ready to be used
[22:04] <seb128> but I doubt many applications will switch
[22:04] <seb128> some might experiment
[22:04] <seb128> but there is a need to solve to migration issue before
[22:04] <seb128> desrt will be at uds
[22:05] <seb128> robert_ancell, I would suggest we are careful on 2.29 until uds
[22:05] <Amaranth> From the way the conversation seemed to be going the migration plan was "migrate wallpaper and such and toss the rest"
[22:05] <seb128> that is the opinion from some people
[22:05] <seb128> I don't see that work for distros
[22:05] <robert_ancell> seb128, right.  Is it worth queueing them up anyway?
[22:06] <seb128> robert_ancell, it's fine doing selected ones I think
[22:06] <seb128> like evince, eog you did, it's easy to roll an application back
[22:06] <robert_ancell> seb128, in the archive?>
[22:07] <seb128> yes
[22:07] <seb128> upload 2.28 as 2.29.is.2.28
[22:07] <Amaranth> 2.29.1+really2.28.2-0ubuntu1 :(
[22:07] <robert_ancell> seb128, then lets be optimistic and say "no applications are going to cause a problem" then roll back any that are
[22:07] <seb128> it's not nice looking but works
[22:07] <seb128> robert_ancell, right
[22:07] <seb128> things I would be careful about nautilus, gnome-panel
[22:08] <seb128> things I would be careful about nautilus, gnome-panel
[22:08] <seb128> urg
[22:08] <seb128> + I'm not sure about glib, gtk
[22:08] <Amaranth> gnome-panel, really?
[22:08] <seb128> I want to discuss that at uds
[22:08] <seb128> Amaranth, we got stucked in the gvfs transition in hardy due to those
[22:09] <Amaranth> sure but I don't think anyone is doing _anything_ with gnome-panel anymore
[22:09] <Amaranth> since it's going away and all
[22:09] <seb128> it's the sort of code which interact with other components
[22:09] <seb128> well; not in 2.30
[22:09] <seb128> but right
[22:09] <seb128> I'm not sure about the evo stack too
[22:10] <seb128> they are switching to dbus and gtk rather than bonoboui
[22:10] <Amaranth> the kill-bonobo branch landed, didn't it?
[22:10] <Amaranth> right
[22:10] <seb128> it's good but it's a lot of refactoring
[22:10] <seb128> and I'm not sure if it will reach stability for lucid
[22:10] <seb128> since we have to keep bonobo anyway
[22:10] <Amaranth> let's shove compiz 0.9 in there ;)
[22:10] <seb128> gnome-panel; gconf, etc ...
[22:11] <seb128> robert_ancell, well small example or refactoring is gcalctool
[22:11] <seb128> you said you would take the opportunity of GNOME3 for that no?
[22:12] <robert_ancell> seb128, it's got a new UI but the changes are incremental
[22:12] <seb128> ok
[22:12] <seb128> robert_ancell, anyway I will let you judge what you consider risky or not
[22:12] <seb128> I might disagree on something and not sponsor it
[22:13] <robert_ancell> mwuhahaha
[22:13] <seb128> but if you feel something should be fine for the lts do the update
[22:13] <robert_ancell> ok
[22:13] <seb128> let's wait for glib, gtk though
[22:13] <seb128> I'm not sure when gtk 2.20 is scheduled
[22:13] <seb128> we need to check that before shipping 2.19
[22:14] <TheMuso> Greetings all.
[22:14]  * TheMuso will help with GNOME merge stuff once he has the audio stack updated.
[22:15] <seb128> hey TheMuso, thanks
[22:15] <seb128> robert_ancell, btw I will fix eog build now
[22:16] <robert_ancell> seb128, oh, haven't read email yet. problem?
[22:17] <seb128> robert_ancell, gnome bug #600706
[22:17] <seb128> robert_ancell, the same issue
[22:18] <seb128> robert_ancell, recent python version break that, it's not meant to be used this way
[23:20] <chrisccoulson> seb128 - i figured out my inhibit issue :)
[23:20] <seb128> chrisccoulson, oh?
[23:21] <chrisccoulson> the hamster-applet is snooping on the org.gnome.ScreenSaver messages, but not handling them correctly
[23:21] <chrisccoulson> which makes dbus return an error, even though gnome-screensaver inhibits correctly
[23:21] <chrisccoulson> if i get rid of the hamster-applet, it all works correctly!
[23:21] <chrisccoulson> that was a wierd one to figure out
[23:22] <chrisccoulson> but because dbus returns an error, rather than the inhibit cookie, totem cannot remove the inhibit when it closes ;)
[23:22] <seb128> good catch, how did you figure that?
[23:22] <chrisccoulson> seb128 - i just started randomly killing things in my session
[23:24] <seb128> ok
[23:25] <chrisccoulson> i took the "scientific" approach ;)
[23:26] <seb128> yeah
[23:26] <seb128> I would probably have started to look into user config
[23:26] <seb128> and start stracing things
[23:29] <chrisccoulson> seb128 - yeah, i was starting to get to that stage, but then i noticed when i was using dbus-send, that the call was returning before gnome-screensaver had handled it (and i knew this, because i had gnome-screensaver interrupted in GDB when i ran dbus-send)
[23:29] <seb128> in any case good catch
[23:29] <chrisccoulson> i need to try and figure out what hamster-applet is doing wrong now
[23:47] <seb128> good night everybody
[23:57] <chrisccoulson> 'night seb128
[23:58] <seb128> night chrisccoulson!