[08:25] <seb128> hello there
[08:27] <crevette> hey
[08:29] <mvo> hey seb128
[08:29] <seb128> lut crevette
[08:29] <seb128> hello mvo!
[08:29] <crevette> salut seb128
[08:31] <BugMaN> hi all
[09:38] <huats> morning everyone !
[09:39] <seb128> lut huats
[09:39] <huats> how are you seb128 ?
[09:40] <seb128> huats: got a cold but otherwise good, you?
[09:41] <huats> the same :) (a cold and good) :)
[09:52] <glatzor> mvo, please take a look at this: https://translations.edge.launchpad.net/ubuntu/intrepid/+source/app-install-data-ubuntu/+pots/app-install-data
[09:52] <glatzor> mvo, the desktop files should not be translated in app-install-data
[09:54] <mvo> glatzor: why not?
[09:55] <glatzor> mvo, because the translation of the desktop file in the original package and the one in app-install-data should be the same
[09:56] <mvo> glatzor: right, I agree, but not all package use "GettextDomain=" in their desktop file for example
[09:56] <mvo> glatzor: so e.g. /usr/share/app-install/desktop/emacs22.desktop can never be translated
[09:57] <mvo> because it does not have inline translations nor a gettextdomain in the original file
[09:58] <mvo> glatzor: or is there a better approach that I'm overlooking here?
[09:59] <glatzor> mvo, you should just ship the desktop files with the in-file translations
[09:59] <glatzor> mvo, if a project doesn't ship a translated desktop file it is perhaps not translated at all.
[10:00] <mvo> glatzor: we do ship inline translations too, but for some desktop files (e.g. the emacs example) there are none
[10:01] <glatzor> mvo, this should be fixed in emacs.
[10:01] <glatzor> mvo, we are talking here about 3000 not translated strings
[10:03] <glatzor> mvo, this means a lot of translator resources. do you plan to extract the translations and send them upstream?
[10:03] <mvo> emacs is just a example, there are quite a few packages that do not ship translations in the desktop file. what is the problem with the untranslated strings? that people start working on them and do not work on the more important ones?
[10:03] <glatzor> mvo, it is a dead end for the translations
[10:04] <mvo> what is the alternative? I'm not confortable with leaving the 3000 strings untranslated in the UI. I got the patch from someone who wants to translate this for his derivate
[10:05] <glatzor> mvo, you should at least communicate this to the translators.
[10:06] <glatzor> mvo, take a look at the recent posts at the ubuntu-translators list
[10:06] <james_w> hey glatzor
[10:06] <glatzor> hello james_w !
[10:07] <mvo> glatzor: ok, I will check that out. sorry that I haven't done so from the beginning
[10:07] <james_w> glatzor: I'm going to apply for a standing freeze exception for packagekit, do you mind?
[10:07] <mvo> glatzor: forwarding to upstream> I can write a script that does that and merges the translaions into the desktop files quite easily, most work will probably to find the contact adresses where to sent the translations to
[10:07] <glatzor> james_w, great. thanks.
[10:08] <glatzor> mvo, the desktop files will be created at build time in most cases
[10:09] <glatzor> mvo, so forwarding the desktop file is not a real solution
[10:10] <mvo> glatzor: well, both can be done relatively easily, a po file snippet and a desktop file merge. so that people who properly build it can just merge the po and people who maintain it manually benefit too. I don't think thats is going to be very hard, I think contacing upstreams is going to be more work
[10:10] <mvo> don't get me wrong, I'm not 100% happy with putting this big dump of strings into rosetta, its really far from ideal, but I don't see a alternative other than ignoring the problem
[10:13] <seb128> mvo: what is the discussion about exactly?
[10:14] <glatzor> mvo, what is about the synchronisation problem with the translation of the corresponding package which could also exist in Rosetta?
[10:14] <mvo> seb128: gnome-app-install uses strings from the desktop files of the packages. those strings are not all translated and g-a-i now has a way to add them
[10:15] <mvo> glatzor: shouldn't rosetta suggest the strings then?
[10:15] <seb128> mvo: would be nice to have a way to translate menu entries too, quite some packages add .desktop in the debian directory which have no translations and doing source upload for every translation change would just not work there
[10:20]  * mvo nods
[10:50] <glatzor> see you guys!
[12:19] <slomo> seb128: did anything bad happen after syncing good/bad from experimental? i mean, any evil bugs or something :)
[12:35] <seb128> slomo: no new bug reported since the update which is good ;-)
[12:36] <seb128> hey pedro_
[12:37] <pedro_> salut seb128!
[13:23] <Laney> seb128: Erm, the file-roller upload ftbfsed
[13:23]  * Laney hides
[13:24] <seb128> Laney: I fixed it already
[13:24] <Laney> right, sorry about that
[13:24] <seb128> Laney: that's my fault, I did some tweaking in the source to see why you changed the menu patch without documenting the change
[13:24] <Laney> Oh, it was just a quilt refresh
[13:25] <seb128> Laney: right, next time don't refresh patches or write that you did so somewhere, that makes debdiff confusing to read otherwise
[13:25] <seb128> diff of patches are no fun to read ;-)
[13:25] <seb128> I had to apply the patch to make sure it was not changing the content
[13:25] <Laney> seb128: Sorry. I mentioned it in the comment but didn't think it warranted saying in the changelog
[13:26] <seb128> that's alright
[13:26] <seb128> but there is no real point to refresh patches you don't touch in a revision update
[13:26] <Laney> I guess. Just wanted to tidy it up
[13:27] <Laney> ah well
[13:30] <Ng> mvo: have you seen any issues with compiz when switching workspaces of focus not being transferred to a window on the target workspace?
[13:30] <Ng> only seems to have started in the last few days
[13:31] <mvo> Ng: seb128 reported the issue, but I have no (reliable) way to reproduce - do you have found one?
[13:31] <Ng> well it seems to happen on basically every workspace switch I do - want a dump of my config?
[13:31] <seb128> mvo: want to try something?
[13:31] <Ng> although hrm, sometimes it does work
[13:32] <seb128> mvo: assign a keybinding to go to workspace 1
[13:32] <seb128> mvo: change workspace, select something on screen and do the keybinding
[13:32] <seb128> mvo: and see if whatever you have on workspace 1 is selected
[13:32] <seb128> I don't get the bug when using ctrl-alt-arrows nor the mouse
[13:33] <seb128> but I get it every time I do a alt-number to switch
[13:34] <seb128> mvo: try to map super-n to a workspace for example if you can
[13:34] <mvo> seb128: trying now
[13:36] <seb128_> hum
[13:36] <seb128_> mvo: did you change something recently?
[13:36] <mvo> seb128_: sorry, works for me
[13:36] <seb128_> it works for me now, I had the bug still yesterday and just dist-upgraded today
[13:37] <mvo> I'm happy to debug this, I'm just at a loss how to reproduce it
[13:40] <seb128> mvo: I'll keep watching for it ;-)
[13:40] <mvo> thanks
[13:40] <mvo> Ng: let me know if you find a way
[13:41] <seb128> mvo: I though you were getting it the other day?
[13:41] <mvo> I did, but it was not reliable, pure chance
[13:41] <mvo> I did a bunch of switches and had it
[13:41] <mvo> then I tried again and never got it again
[13:42] <Ng> mvo: basically what seb said, but something about it is unpredictable
[13:42] <Ng> I *always* switch workspaces with alt-F1 to alt-F4, so I'm seeing it quite a lot
[13:43] <Ng> (and I have terminals, mail and firefox on separate workspaces, so I switch a lot)
[13:43] <Ng> it's happening for me most of the time, but sometimes the focus switches properly
[13:43] <mvo> Ng: could you file a bug please? I will look at it when I'm finished with my current task
[13:44] <Ng> sure
[13:48] <seb128> mvo: similar to what Ng said in my case too, I have IRC always on a workspace so I switch a lot between this workspace and other using keybindings (not the ctrl-alt but direct shortcuts for each workspaces)
[13:53] <Ng> mvo: https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/283215
[13:53] <mvo> thanks Ng
[13:53] <Ng> np :)
[13:55] <seb128> slomo: bug #283176 could be due to one of the gstreamer updates
[14:44] <asac> mvo: whats the state on apturl support for third party repos in intrepid?
[14:45] <mvo> asac: unchanged, noone came up with a schema that is somewhat secure
[14:46] <mvo> asac: the code is there, its a matter of flipping a swtich, but the consequences are probably too risky
[14:54] <fta2> seb128, asac: i have cairo 1.8.0 ready, but i'm concerned about the corruption seen by some users: http://ubuntuforums.org/showthread.php?t=946574
[14:55] <fta2> seb128, asac: debian extracted a patch for cairo from the mozilla tree: http://glandium.org/blog/?p=209
[14:55] <fta2> seb128, asac: should I add that to 1.8.0 too ?
[14:56] <seb128> fta2: how can those users have an issue using 1.8 if 1.8 has not been uploaded yet?
[14:56] <seb128> fta2: or is the issue orthogonal to the update?
[14:56] <seb128> ie, is the update creating an issue
[14:56] <fta2> seb128, no, it's not 1.8.0, it's in all cairo versions
[14:57] <seb128> ok, so you are just asking if you should add the workaround?
[14:57] <fta2> yes
[14:57] <seb128> do you know if the change has been discussed upstream already?
[14:58] <asac> fta2: where is the patch? i only have seen binary blobs from glandium still
[14:58] <fta2> upstream mozilla sure, it has been done by vlad, which is also a core-dev in cairo
[14:58] <asac> fta2: ask vlad what he thinks about the impact then :)
[14:58] <fta2> asac, mike said he diffed the in-source cairo, so it's the same patch i pointed you weeks/months ago
[14:58] <asac> maybe its a mozilla specific solution
[14:59] <asac> fta2: ok. i understand. thats a more advanced variant of the bandaid isnt it?
[14:59] <fta2> yes
[14:59] <asac> with not that many features disabled as before
[14:59] <asac> we should definitly ask him
[14:59] <asac> to at least assess the risk
[14:59] <seb128> fta2: has this patch been commited to cairo git and if not why not?
[15:04] <fta2> seb128, no, but i don't know why. i'll ask vlad
[15:06] <fta2> seb128, asac: http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/buggy-repeat.patch
[15:07] <seb128> is that the change we dropped just before 8.04.1 because it was slowing down things a lot for users?
[15:07] <seb128> you guys added a buggy repeat workaround before hardy too
[15:08] <fta2> sure but it was inconditionnal, now, it's smarter
[15:09] <asac> seb128: he?
[15:09] <seb128> asac: he!
[15:09] <asac> seb128: we never claimed a workaround would be regression free ;)
[15:09] <fta2> that's mozilla bug 456467
[15:10] <asac> it was just curing more than hurting. anyway. i am against doing stuff now. our default dont show this behaviour
[15:10] <seb128> asac: I accepted the workaround previous time and it took us ages to figure that created real slowness issue for quite some users
[15:10] <seb128> asac: I'm not wanting to take an another cairo workaround without having upstream commenting on it first ;-)
[15:10] <asac> seb128: i cant remember that it took ages to figure that out. it was just not reproducible for us ... that was all i think.
[15:10] <asac> seb128: thats what i am saying
[15:10] <asac> seb128: previous workaround was also discussed upstream
[15:11] <seb128> asac: right, that was bug #219587
[15:11] <asac> seb128: we knew that it might have some impact. but general issues turned out that for some it was harder than expected
[15:12] <seb128> asac: right
[15:12] <asac> seb128: still ... at the point of the patch we had no other choice. after investigating we found a x workaround which then made the patch droppable
[15:12] <seb128> asac: just saying that I would avoid adding workarounds so soon before intrepid if we don't have a real need for those
[15:12] <asac> only point i am trying to say: if we hadnt found the X workaround we probably wouldnt have dropped the patch ;)
[15:12] <asac> seb128: yes. i dont see the real need for this patch now
[15:12] <seb128> ok good
[15:12] <asac> but maybe i am just not on top of bugmail
[15:13] <seb128> fta2: let's update to 1.8 now and discuss the workaround later
[15:13] <asac> could be that chipsets see this issue again
[15:13] <tedg> seb128: So I've got a patch to GNOME Panel which removes the shutdown/logout from the system menu if the FUSA applet is in the panel.  I'm guessing I need some sort of exception for that patch.  If so, what kind should I be asking for?
[15:13] <fta2> seb128, ok, so no patch. i'm done then.
[15:13] <asac> fta2: seb128: i think first thing to do would be to go through bugs and see if this is an issue for our users at all ;)
[15:13] <seb128> tedg: I'm against a such patch
[15:13] <seb128> tedg: I use both the applet and the menus
[15:13] <asac> the shutdown/logout thing isnt finished yet, right?
[15:13] <seb128> asac: it is
[15:14] <asac> urgh.
[15:14] <pitti> uh, different menus depending on which applets you have installed? how confusing
[15:14] <asac> i still ahve the green man and nothing else on my panel :(
[15:14] <seb128> asac: did you upgrade recently?
[15:14] <asac> almost every day
[15:14] <asac> let me check
[15:14] <dobey> pitti: indeed
[15:14] <seb128> asac: you should have get a bubble light in the notification area asking if you want to migrate your configuration
[15:15] <asac> seb128: on my laptop i had the "shutdown" button reappear i think two days ago
[15:15] <asac> seb128: yes. that notification thing disappeared for me
[15:15] <asac> and i didnt know how to get it back
[15:15] <tedg> seb128, pitti: Well, mpt is very much against having two ways to logout.  He's flying right now, so we can't really get his input.
[15:16] <seb128> tedg: I'll not make those menus change dynamically when adding an applet or remove it, that's confusing as pointed by pitti and I use those items and I'm probably not the only one
[15:16] <seb128> tedg: we can discuss making it a gconf key though
[15:16] <fta2> seb128, http://www.sofaraway.org/ubuntu/tmp/cairo_1.8.0-0ubuntu1.dsc http://www.sofaraway.org/ubuntu/tmp/cairo_1.8.0-0ubuntu1.diff.gz
[15:16] <pitti> seb128++
[15:16] <pitti> what's wrong with having extra ways to log out?
[15:16] <pitti> g-p-m has offerend suspend/resume for ages, and nobody complained
[15:17] <seb128> pitti: looks like people prefer having an empty system menu ;-)
[15:17] <pitti> and so did ctrl+alt+del, or pressing the power button, or closing lid, etc. pp
[15:17] <seb128> fta2: thanks
[15:17] <pitti> or ripping out the plug :)
[15:17] <tedg> pitti: I think that mpt hasn't had time to file all the bugs he'd like to ;)
[15:18] <dobey> pitti: so we should hide shutdown from the menus if the system has a battery, and the icon is shown? :P
[15:18] <tedg> pitti: In general, the problem is that it's easier to have "a way" to do things -- simpler explanation.  While different ways are okay, two menus are a touch odd.
[15:19] <pitti> tedg: exactly my point; the only thing which is currently guraranteed to be there is the systme menu
[15:19] <dobey> tedg: the problem is that to every person who has ever used windows or mac os, that "way" is the menus
[15:19] <pitti> if we wouldn't have it any more, our documentation would need to say "look if you have this, or if not, look ---> there, etc."
[15:19] <tedg> dobey: Yes, and we are maintaining that.  Just the FUSA menu instead of the System one.
[15:20] <dobey> tedg: like they say in retail... location location location :)
[15:20] <dobey> i especially don't think "shutdown" makes sense under "list of users"
[15:21] <pitti> well, I think it's great to have the option there, but that's new in intrepid
[15:22] <seb128> you can't assume that users will know about the fusa because they just upgraded
[15:22] <seb128> those using the menu will just wonder why they can't close their session and press the power button
[15:23] <tedg> dobey: The idea is to more have "all status and session stuff" in one menu.  Shutdown is really a session operation with a power plug thrown in.
[15:23] <seb128> tedg: users will not know that, especially if they are used to the old switch user applet
[15:23] <dobey> i don't think that's an appropriate assumption really
[15:23] <seb128> they will never look there
[15:23] <tedg> seb128: Well, I think that a large number of users clicked on the "big red button in the corner" -- which will still be there.
[15:24] <seb128> they will just remove the power plug and complain
[15:25] <dobey> what happens if fusa crashes?
[15:25] <dobey> and the main menu is open?
[15:25] <seb128> tedg: I do use the applet only for user switching and the menus for logout etc, you consider that not as a valid usecase?
[15:25] <dobey> logout/shutdown suddnely appear/disappear?
[15:26] <tedg> dobey: No, unfortunately not.  But, if FUSA crashes it will get a prompt to reload.
[15:27] <tedg> seb128: Personally, I don't care.  But the UI theory here is that there should be "one way".
[15:27] <dobey> modifying the main menu based on the context of an external applet is just bad ui
[15:27] <tedg> dobey: It's not context.  It's modifying the menu based on the configuration of the panel.
[15:27] <seb128> tedg: ok fine, add a gconf key to hide the menu items and enable it by default
[15:28] <pitti> tedg: but by removing logout from the menus, we are exactly destroying the only reliable "one way" (menus) we currently have
[15:28] <seb128> tedg: but don't do your dynamic configuration depending on the layout because nobody will understand what's going on
[15:28] <dobey> we already have multiple ways to log out/shutdown
[15:28] <tedg> pitti: It's as reliable to say that the menus will be there as the FUSA applet will be there.  People can remove the menus too.
[15:29] <tedg> seb128: The problem there is that if we enable it by default, and someone doesn't have the FUSA applet, then they will have no menu items anywhere!  So, I think the GConf key should be "disable if FUSA applet."
[15:29] <seb128> tedg: it's not obvious to guess why menu items just vanished because you changed your applets configuration
[15:29] <dobey> if you somehow wish to coax users into using your preferred way, that's fine, but you shouldn't force them out of their preferred ways
[15:30] <seb128> tedg: I'm against a such patch then, the system menu doesn't have to many items and users will expect those actions there
[15:30] <seb128> s/to/too
[15:30] <seb128> let's wait for mpt to be there
[15:31] <tedg> Sounds good.  I'll open a bug.  Everyone can comment there.
[15:31] <tedg> BTW, considering there is unlikely to be a "System" menu in the future, coaxing them away from it isn't about being "preferred" it's about migrating them to where things are going.
[15:31] <pitti> tedg: I disagree; fusa applet is nowhere near guaranteed to exist for upgrades
[15:32] <tedg> pitti: Correct, and that's why the patch looks for it before removing them from the system menu.
[15:32] <seb128> tedg: there is still a system menu though and as long there is one some users will expect system actions to be there
[15:32] <pitti> tedg: yes, I understand; but still there would be "two half-true ways", not one
[15:32] <tedg> pitti: But, the menus aren't guaranteed either for upgrades.  More likely, but not guaranteed.
[15:33] <seb128> tedg: what we do when the system menu is deprecated is an another topic
[15:33]  * dobey thinks the whole panel concept needs to be deprecated
[15:33] <pitti> tedg: but if someone removed logout from the system menu, he certainly uses a different way; which we cannot assume for the vast majority of people who didn't customize their system menu
[15:33] <seb128> brb switching computer
[15:34] <dobey> arbitrary content in something so important as the panel is the bane of usability
[15:34] <tedg> dobey, pitti, seb128: http://live.gnome.org/Boston2008/GUIHackfest/WindowManagementAndMore
[15:34] <dobey> yeah
[15:34] <dobey> how very macin-vista
[15:36] <dobey> heh, that's another thing i hate... using the term "Quit"
[15:37] <dobey> it's really unfortunate that i couldn't be at the hackfest/summit
[15:41] <seb128> fta2: what was the cairo update url?
[15:44] <seb128> anybody having the url fta2 gave some time ago for the cairo update?
[15:45] <dobey> seb128: the mozilla blog thing?
[15:45] <pitti> uh, poor panel (looking at above URL)
[15:45] <seb128> dobey: no, the diff.gz and .dsc for 1.8
[15:45] <dobey> oh
[15:46] <dobey> 10:16 < fta2> seb128,  http://www.sofaraway.org/ubuntu/tmp/cairo_1.8.0-0ubuntu1.dsc  http://www.sofaraway.org/ubuntu/tmp/cairo_1.8.0-0ubuntu1.diff.gz
[15:46] <dobey> seb128: there
[15:46] <seb128> dobey: thank you
[15:46] <pitti> what's the point of having a single "Activities" thingy? that's just going to increase the length of the click path for everything?
[15:46] <fta2> seb128, oops, sorry (i'm on the phone)
[15:47] <dobey> seb128: you should look into using screen+irssi :)
[15:47] <seb128> fta2: that's ok, I changed box to do the cairo build and testing but I didn't note the url before ;-)
[15:47] <dobey> pitti: i don't know
[15:47] <dobey> pitti: i'm as confused as you are :)
[15:47] <seb128> dobey: that or having an irc proxy running somewhere
[15:47] <dobey> yeah
[15:47] <pitti> znc++
[15:48] <dobey> i think i'm going to set up a private jabber server soon, with transports, for my IM, so i can be connected to everything from multiple machines
[15:49] <dobey> still have yet to find a good jabber client for my phone though
[15:52] <dobey> i guess i should update my linkedin profile now
[15:57] <tedg> pitti: Not really.  Currently you have to click on "Applications" -- no real difference clicking on "Activities"
[15:57] <tedg> bug #283278
[16:04] <dobey> hrmm. linkedin is totally triflin. why does it send me to the company page for "Canon, Inc." when i search for "Canonical"
[16:21] <mvo> asac: did you upload the fix for network-maanager so that it does not show the "resource missing" dialog anymore?
[16:21] <mvo> seb128: I get the evo alarm notifier error on pretty much each test upgrade, do you think I could simply kill it before the upgrade?
[16:21] <mvo> or disable it in some way temporarely
[16:23] <seb128> mvo: shouldn't we rather try to figure what the issue is?
[16:24] <seb128> mvo: I guess that stopping it before upgrade would work but some users might expect to still get their meeting, etc notifications during upgrade
[16:24] <seb128> mvo: and it'll be automatically restarted if they are running evolution for example
[16:26] <asac> mvo: no i have to do that. thanks
[16:27] <mvo> asac: ok, just checking (because I have seen it just some minutes ago :)
[16:28] <asac> yeah
[16:28] <asac> sorry
[16:28] <mvo> seb128: yeah, I have little clue about evo :/
[16:28] <asac> i will try to upload that today. just want to check if we need something else for the "release candidate" upload :)
[16:29] <mvo> asac: cool, thanks
[17:27] <seb128> bbl
[17:39] <Ng> mvo: do we have http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=46e4aa0308fe542f2586835e86ee249ebea6fafb in our compiz packages? Seems like it makes GIMP2.6 nicer
[17:39] <Ng> but I dunno if there are wider implications
[18:38] <mvo> Ng: if its not part of 0.7.8 we don't have it, but if upstream thinks its a good idea, I can take it, I have a lot of faith in them :)
[18:39] <Ng> I came across it in a discussion about gimp2.6 and how compiz sucks at handling its toolbar windows, I have no further reason to assume/believe/think it's a good idea ;)
[18:42] <mvo> Ng: ok, I will inquire tomorrow
[18:42] <Ng> :)
[19:11] <mvo> pitti: what is the current status with camera/gio/fuse and gthumb? I get "An error occurred in the io-library ('Could not lock the device'): Camera is already in use." when opening gthumb
[19:23] <pitti> mvo: right, we just fixed f-spot in that regard
[19:23] <pitti> but actually we wanted to disable automounting of libgphoto cameras
[19:23] <pitti> and get back to gthumb/f-spot talking to the cam directoy
[19:23] <pitti> directly
[19:23] <pitti> otherwise they are unbearingly slow
[19:23] <mvo> pitti: aha, cool. thanks for this update
[19:24] <mvo> pitti: do we know why its slower? is fuse slow? or the gvfs implementation?
[19:24] <pitti> mvo: neither, it's f-spot making wrong assumptions
[19:24]  * mvo nods
[19:25] <pitti> mvo: e. g. with direct libgphoto it downloads the thumbnails
[19:25] <pitti> mvo: with the fuse path, it downloads the full images, produces a thumbnail, and throws away the image
[19:25] <pitti> mvo: thus presenting the import dialog takes like 5 minutes
[19:25] <pitti> and then you download them all over again
[19:25] <mvo> right
[22:09] <james_w> tedg: hey, you around?
[22:10] <tedg> james_w: Yes, but I'm playing with an experiemental window manager -- I may disappear ;)
[22:10] <james_w> heh :-)
[22:11] <james_w> http://bugzilla.gnome.org/show_bug.cgi?id=550817 was the bug that I mentioned earlier
[22:11] <james_w> it's got a link to the Ubuntu bug
[22:12] <james_w> tedg: also, chrisccoulson has an interesting bug report
[22:12] <chrisccoulson> hi tedg
[22:12] <james_w> chrisccoulson, meet tedg, he's the expert on all this
[22:12] <chrisccoulson> good stuff!
[22:12] <tedg> james_w: Yes, so hughsie likes the patch -- yeah!  That makes life easier.
[22:13] <james_w> always :-)
[22:13] <tedg> chrisccoulson: Nice to meet you.
[22:13] <chrisccoulson> when i hit the power button on my machine, g-p-m seems to open the logout session dialog on every logged-in users desktop (including all inactive users)
[22:13] <chrisccoulson> unfortunately, the upstream session dialog has a 60s timeout, which logs you out automatically if you dont respond
[22:14] <chrisccoulson> that means that all inactive users get logged out automatically after 60s if i accidentally hit the power button,because they aren't available to respond to the session dialog which appears
[22:14] <tedg> Hmm, that's odd.  Are you using the GPM in my PPA?  While that's probably a GNOME Session bug -- the PPA version may work around it.  It uses the DBus interface instead of the XSMP one.
[22:15] <chrisccoulson> i'm using the standard gpm at the moment
[22:15] <chrisccoulson> i'll try your PPA version, although I probably won't get a chance straight away
[22:17] <tedg> chrisccoulson: Okay.  The normal GPM is just using XSMP -- which shouldn't connect to all sessions, but there may be a bug in GNOME Session.
[22:17] <tedg> chrisccoulson: Hopefully, as I get everyone's patches in, I'll upload that GPM here shortly.
[22:17] <chrisccoulson> thanks, i'll try that out