[00:06] <maxb> Anyone else on intel graphics hardware or otherwise finding themselves severely affected by bug 307306 still?
[00:07] <james_w> maxb: still slow for me
[00:08] <james_w> maxb: not sure it's entirely gpm's fault, though the symptoms suggest that it is at least related
[00:09] <maxb> I've just re-opened the gnome-desktop bugtask, after finding that removing the workaround patch to gnome-desktop that is in the bug comments made the problem worse again
[00:09] <maxb> I'm assuming it has to be driver-related since I'm only seeing it on one of my three machines, each with a different video card manufacturer
[06:38] <sainath> i have written a program using libwnck which activates the neighbor workspace
[06:38] <sainath> but when executed it returns null
[06:39] <sainath> even though there is a neighbor workspace still is not recognizing
[06:39] <sainath> can u tell me what is the problem?
[06:48] <Amaranth> sainath: If you're using compiz there are no workspaces
[06:48] <Amaranth> Well, there is the one you're on, but it is split up into viewports
[06:49] <sainath> then which methods i have to use?
[06:52] <Amaranth> I don't quite remember but I know you have to do some of the math yourself to figure out where to move
[06:55] <Amaranth> sainath: You need to get the height of the screen and the height of the workspace to figure out the number of viewports
[06:55] <sainath> k
[06:55] <sainath> i now understood where the problem is
[06:55] <sainath> thanks
[06:55] <Amaranth> then use wnck_workspace_get_viewport_x/y to figure out where you are
[06:55] <sainath> i'll figure it out
[06:56] <sainath> k
[06:56] <Amaranth> sainath: then wnck_screen_move_viewport to move
[06:56] <sainath> yes
[06:56] <sainath> how viewport values change for diff workspaces?
[06:57] <Amaranth> No one mixes workspaces and viewports
[06:57] <Amaranth> It's technically possible but you'd go insane as there is no way to manage it
[06:58] <sainath> k
[06:58] <Amaranth> sainath: In compiz and in gnome using multiple workspaces each with multiple viewports is considered Not Supported so you don't have to worry about it
[07:00] <sainath> k
[07:36] <pitti> Good morning
[08:22] <bryce> hey, is there a simple way to disable GNOME's hardcoding of 96 dpi?
[08:32] <bryce> nevermind, found it
[09:14] <pitti> seb128: are you planning major new changes in GNOME until next Thursday (alpha-4)?
[09:15] <seb128> pitti: GNOME 2.25.90 due next week so yes
[09:15] <pitti> seb128: we'll have a soft freeze again Tue to Thu; do you think it's possible to get that in?
[09:15] <pitti> (remember, we are also on the sprint)
[09:16] <seb128> pitti: depends what you call new changes, lot of new versions but they are feature, api, etc frozen for 2.25 so no important changes, just lot of updates next week
[09:16] <pitti> seb128: okay; in theory we could also do them the week after, if the sprint is too busy?
[09:16] <seb128> pitti: having freezes during new GNOME weeks suck, I can't say now how busy I will be during the sprint
[09:17] <seb128> pitti: I will not, it's either next week or we skip since the next tarball are just one week after the sprint
[09:17] <pitti> seb128: hm, seems if there will be major rebuilds next week/afterwards, I better try and push the updated .desktop translation patches in
[09:17] <pitti> oh, ok
[09:24] <mvo> seb128: the compiz session problem should be fixed with the next upload
[09:24] <seb128> mvo: cool, what did you change?
[09:25] <mvo> seb128: compiz-manager has a workaround now, the real problem is in gnome-session (http://bugzilla.gnome.org/show_bug.cgi?id=559450)
[09:25] <mvo> did I mention that compiz upstream are rockstars ;) ?
[09:25] <huats> morning everyone
[09:25] <seb128> mvo: ah ok, I did read this bug upstream but didn't really understand what that meant from an user point of view
[09:25] <seb128> lut huats
[09:28] <mvo> seb128: it works for me now, please let me know if its good for you too once it enters the archive (0.7.8-0ubuntu9)
[09:28] <seb128> mvo: I'll do updated bootchart once it's available ;-)
[09:28]  * seb128 eyes vuntz
[09:28] <mvo> thanks!
[09:29] <seb128> vuntz: my gnome-panel is frozen, e-d-s crashed and it didn't like that, I though you changed the calendar calls to be async and not block everything?
[09:47] <sainath> I am using metacity as window manager.When i tried to create a new workspace through a program and want to switch to it ,it creates a new workspace but failing to switch.
[09:48] <sainath> i have used libwnck funcin my prog
[10:59] <seb128> mvo: could you look to bug #322955?
[11:06] <mvo> seb128: done
[11:06] <seb128> mvo: thanks
[11:07] <mvo> I have a theory, I think the real bug is memory corruption on the box or something (ld segfauled) bt the subsequent error looks like something in apt to fix
[11:11] <seb128> mvo: did you see my ping about an another upgrade bug yesterday?
[11:13] <seb128> mvo: btw this guy opened several bugs you might want to dup the other ones
[11:48] <mvo> seb128: yes, I have it open somewhere, it was a dpkg issue update-manager should be able to resolve it automatically
[11:50] <seb128> mvo: there is over a thousand of apport-package bugs open
[12:04] <vuntz> seb128: stack trace of the panel hang?
[12:05] <seb128> vuntz: I did restart it since, there was one thread blocked on a e_flag_something call
[12:05] <seb128> I will get it for you next time but it seems similar to the bug before your changes
[12:05] <vuntz> seb128: was it talking about a thread?
[12:05] <seb128> talking?
[12:05] <vuntz> seb128: and are you using a calendar that requires a password?
[12:06] <seb128> no
[12:06] <seb128> but evolution was frozen too
[12:06] <vuntz> ok, then not what I thought
[12:06] <seb128> I think e-d-s got screwed
[12:06] <vuntz> seb128: I'd blame the eds library first, fwiw ;-)
[12:06] <seb128> the applets were still working
[12:06] <seb128> yes, evolution was frozen too
[12:06] <seb128> but I would expect to still have working menus when the clock applet hangs
[12:07] <seb128> that + nozap in jaunty = no easy way to close your session
[12:08] <vuntz> seb128: don't compile the clock in process :-)
[12:08] <pitti> seb128: alt+sysrq+k ?
[12:08] <vuntz> seb128: there's a configure flag
[12:08] <mvo> seb128: apport-package bugs> right, they deserve attention
[12:09] <pitti> vuntz: .desktop gettext patch> why did you add this fallback to _G_KEY_FILE_DEFAULT_DOMAIN ("desktop_translations")?
[12:09] <seb128> pitti: I did use power button which opens the session dialog ;-)
[12:09] <seb128> vuntz: right but that would means extra ressources use
[12:09] <pitti> seb128: oh, if that still works, it is so much better than killing X..
[12:10] <seb128> well theorically
[12:10]  * seb128 looks at vuntz again
[12:10] <vuntz> pitti: because that's what we use in openSUSE -- in the end, we don't add the gettext key for most desktop files
[12:10] <seb128> but right now session closing is doing really different
[12:10] <seb128> +nothing
[12:10] <pitti> vuntz: but doesn't that require you to duplicate the application's .mo files to "desktop_translations.mo"?
[12:10] <vuntz> pitti: (and because the KDE people didn't implement the gettext key in openSUSE, just hacked it this way)
[12:11] <vuntz> pitti: no, we just have the translations from the desktop file
[12:11] <pitti> vuntz: I don't think I can justify this bit for upstream inclusion
[12:11] <pitti> vuntz: do you want that upstream as well?
[12:11] <vuntz> pitti: yeah, this one is... harder :-) Although it makes some sense from a distro point of view
[12:12] <vuntz> pitti: note that it's also why we first check for translation with a context
[12:12] <pitti> vuntz: well, I think I'll first submit a patch without that fallback, and the fallback can become another request, once it is generally accepted; WDYT?
[12:12] <mvo> seb128: apport-package bugs> I can try to do another scan over them, but there is no chance that I can do that daily with my current other tasks
[12:12] <seb128> mvo: try to organize a bug day to clean those?
[12:13] <pitti> vuntz: also, do you still remember why you need key_file->file_basename ?
[12:13] <vuntz> pitti: makes sense
[12:14] <vuntz> pitti: for the context, which is needed for the desktop_translations.mo stuff
[12:14] <pitti> aaah, so it's part of that fallback
[12:14] <pitti> merci
[12:14] <vuntz> (the context is the desktop filename)
[12:15] <seb128> lunch, bbl
[12:16] <pitti> vuntz: uh, your patch calls setlocale (LC_MESSAGES, NULL);
[12:16] <pitti> vuntz: that shouldn't really be in glib, should it? applications should usually initialize/set their locales?
[12:17] <pitti> vuntz: ignore me, I clearly need food
[12:17] <vuntz> pitti: nope, it's used
[12:17] <vuntz> :-)
[12:17] <pitti> NULL != ""
[12:41] <fta2> seb128, my gnome-screensaver is severely broken in jaunty. Seems to be bug 320666
[12:42] <Hobbsee> ++
[12:47] <fta2> I use scim but it doesn't seem to be related.
[12:48] <crevette> fta2, I have the same bug
[13:06] <seb128> fta2: don't use an im method and that will work correctly ;-)
[13:07] <crevette> I don't use a IM method I guess
[13:08] <seb128> crevette: if you didn't set some special variable for that you don't
[13:48] <rickspencer3> pitti: you are made of awesome
[13:48] <pitti> rickspencer3: what a nice way to say "good morning" :-)
[13:49] <pitti> rickspencer3: what did I break this time?
[13:49] <seb128> pitti: isn't that early to say morning in his timezone? ;-)
[13:49] <rickspencer3> I got up early today to get my head around the release status for the meeting, and was greeted with your email
[13:50] <pitti> seems Rick is a true larch
[13:50] <pitti> rickspencer3: heh
[13:50] <rickspencer3> "larch" as in the tree?
[13:50] <pitti> as in the bird?
[13:50] <pitti> don't you say larch vs. owl, too?
[13:50] <rickspencer3> aaah
[13:51] <pitti> as in, people who get up early, and people who stay up late?
[13:51] <rickspencer3> we do way night owl, but I'm not sure about "larch"
[13:51] <rickspencer3> we do say "early bird" though
[13:51]  * pitti checks the dictionary
[13:51] <pitti> oh, I think I meant to say "lark"
[13:51] <rickspencer3> actually, I never got up this early before I stared working at Canonical
[13:52] <pitti> similar in German as well, Lärche vs. Lerche
[13:53] <rickspencer3> that makes sense
[13:54] <rickspencer3> thanks for putting the release status page together, I was pretty worried about getting that done before the meeting this morning
[13:55] <pitti> rickspencer3: you're welcome; it kind of falls on my plate anyway, and since I had everyone online (including bryce), and it came in short notice, I just did it this morning
[13:56] <pitti> seb128: do you happen to know if gnome-panel actually uses the desktop bits from libgnome-desktop-2-11, or if it only uses GKeyFile? I'm trying vuntz' patches, but they prefer gettext over inline, instead of the other way round (as vuntz, and now we, want)
[13:56] <pitti> but the code reads correctly, it *should* prefer inline over gettext
[13:59] <vuntz> pitti: panel doesn't use gnome-desktop to read desktop files anymore
[14:03] <pitti> vuntz: on that matter, it was already deprecated years ago; does anything still use it, btw?
[14:03] <pitti> (since we, and you, are still carrying a patch for gettext support)
[14:03]  * pitti throws out the gnome-desktop patch, just to be sure
[14:06] <crevette> hey andreasn
[14:06] <andreasn> hi crevette
[14:09] <pitti> vuntz: just to make 100% sure: with a valid X-GNOME-Gettext-Domain, and Name[de]=InlineTranslation, and gettext(Name) == "GettextTranslation", gnome-panel should show "InlineTranslation", right?
[14:09] <pitti> vuntz: I ported your patch, and it shows GettextTranslation
[14:11] <vuntz> pitti: I think some people still use gnome-desktop since they didn't port to gkeyfile
[14:11] <vuntz> pitti: it should
[14:11] <vuntz> let me try it here
[14:12] <pitti> but looking at the code, the fallback should be correct
[14:12]  * pitti scratches his head
[14:14] <vuntz> pitti: err. Doesn't work anymore?
[14:14] <vuntz> grml
[14:15] <pitti> vuntz: not for you either?
[14:15] <pitti> vuntz: ok, then I'm not on crack
[14:15] <pitti> vuntz: I'll have a look at this
[14:15] <vuntz> let me finish the two other things I started, and I'll look at this
[14:15] <kwwii> seb128: I noticed that in the login-window settings dialog I can set a gtkrc for gdm to use, but it seems to not respect it (or sometimes even start) if I set the path of that to the gtk-2.0/gtkrc file included in the theme package...can we sit down in Berlin and have a look at that?
[14:16] <seb128> pitti: not replying since vuntz did before
[14:16] <seb128> kwwii: no clue about that we can have a look next week though
[14:16] <seb128> brb
[14:17] <kwwii> seb128: it seems to be a really funky bug of some kind...we've been shipping that gtkrc since I started and apparently it never worked :p
[14:17] <pitti> vuntz: theory: it might try de_DE first, not find that in the .desktop file, look it up in gettext, find it, and not come to the next language[i] any more, which might be [de] (which is in the .desktop file)
[14:17] <seb128> it did, we tested it when doing the change
[14:17] <seb128> vuntz: don't forget to fix gnome-session too ;-)
[14:17] <seb128> brb
[14:19] <pitti> vuntz: IMHO it should be moved out of, and after the loop, and s/strcmp (msg_locale, languages[i]) == 0/!translated_value/
[14:26] <rickspencer3> pitti: do you think it's worthing bringing up the fglrx/-ati situation at the release status meeting?
[14:27] <pitti> rickspencer3: my report mentions it, and I don't think we can do much about it; AMD/NVidia know about the situation
[14:29] <pitti> vuntz: yep, that helped, works perfectly now
[14:29] <pitti> FWIW, hooray for -panel's inotity; I still remember, four years ago I had to restart the panel each time...
[14:29] <pitti> inotify, too
[14:35] <chrisccoulson> pitti, i think i'm getting somewhere with bug 314263
[14:35]  * pitti hugs chrisccoulson
[14:35] <chrisccoulson> you can't contact the gvfs daemon when you use sudo
[14:36] <chrisccoulson> sudo scrubs the DBUS_SESSION_BUS_ADDRESS from the environment
[14:36] <chrisccoulson> that causes glib to take a different code path, which has always happened. i think a recent change in glib just exposed the problem though
[14:37] <pitti> ah, maybe; since in intrepid that worked without problems
[14:39] <chrisccoulson> it did. currently, g_vfs_get_local returns a GDaemonVfs if the gvfs daemon is contactable, which is when it works. but when it isn't contactable, it returns a GLocalVfs, which should allow gio applications to still function without the daemons
[14:39] <chrisccoulson> that obviously isn't working though
[14:40] <chrisccoulson> that's the next bit to figure out!
[14:41] <chrisccoulson> **i meant g_vfs_get_default
[14:41] <chrisccoulson> d'oh
[14:52] <pitti> vuntz: patch sent upstream, you are in CC
[14:57] <rickspencer3> pitti: you attend the release meeting, right?
[14:57] <pitti> rickspencer3: right, I do, /joining now
[14:57] <rickspencer3> ok
[14:57] <rickspencer3> I wasn't sure. I didn't see you on the invite, but it sounded like you planned to attend
[14:58] <pitti> I usually do
[14:58] <rickspencer3> great
[15:14] <chrisccoulson> i think i understand that bug completely now pitti. i'm going to try and write a patch for it and send it upstream
[15:14] <pitti> chrisccoulson: you are awesome
[15:14] <chrisccoulson> **blushes**
[15:14] <chrisccoulson> lol
[15:14] <chrisccoulson> i havent written it yet;)
[15:15] <pitti> well, debugging the reason is great on its own
[15:15] <chrisccoulson> it all makes sense now i think
[15:34] <davmor2> Guys quick query I'm writing a testcase but want to know what the app is called.  It is the app which triggers the dialogue when ever you put in a music player/cd/dvd/camera etc into the machine
[15:34] <pitti> davmor2: that's nautilus
[15:34] <pitti> triggered through gvfs
[15:34] <vuntz> pitti: thanks, you're awesome!
[15:35] <davmor2> pitti: thanks I thought it would be something like that but figured I'd best be sure :)
[15:35] <pitti> vuntz: as discussed, I removed the fallback domain for now, and fixed the fallback bug, to make the patch smaller and upstream-palatable
[15:37] <pitti> vuntz: if you want to take it, you need http://people.ubuntu.com/~pitti/tmp/02_gettext-desktopfiles-ubuntu.patch with s/Ubuntu/SUSE/
[15:37]  * pitti uploads that glib and fixed build system rules
[15:37] <pitti> vuntz: btw, I'm using this in our build rules:
[15:37] <pitti>                     sed -ri '/^(Name|GenericName|Comment)\[/d' $$d; \
[15:37] <pitti>                     echo "X-GNOME-Gettext-Domain=$$DOMAIN" >> $$d; \
[15:38] <pitti> with $d iterating over find debian/$(cdbs_curpkg) -type f \( -name "*.desktop" -o -name "*.directory"
[15:39] <vuntz> sounds like what we do :-)
[15:40] <pitti> great
[15:40] <pitti> . o O { good to have a bug fix cycle like jaunty to clean up such old mess)
[15:48] <pitti> vuntz: btw, did you patch pyxdg for that, too?
[15:54] <vuntz> pitti: no
[15:59] <chrisccoulson> pitti - that patch is working ok. i've made a debdiff if you want to sponsor it
[15:59] <pitti> chrisccoulson: can you please attach it to the bug and subscribe "pitti" (should already be, though)
[15:59] <pitti> chrisccoulson: I'll sponsor it the
[15:59] <chrisccoulson> it's attached to the bug now, and you're already subscribed:)
[16:00] <pitti> I should get mail soon then
[16:00] <chrisccoulson> cool. thanks
[16:00] <pitti> thanks to you!
[16:01] <chrisccoulson> you're welcome
[16:03] <fta2> pitti, why did you drop the file association in calibre? lrf, lit, ...
[16:03] <fta2> +s
[16:03] <pitti> 'drop'?
[16:03] <pitti> I didn't drop them deliberately
[16:04] <fta2> i see you removed the linux integration code, it was part of this. you re-added the desktop files, but not the mime files
[16:05] <pitti> fta2: ah, you mean it has never been there in the first place?
[16:05] <pitti> I thought you meant "recently", as in "in the last upload"
[16:06] <fta2> no
[16:06] <pitti> fta2: can you please file a bug about it and assign it to me? ("pitti")
[16:06] <fta2> there's also a typo in the control file
[16:07] <fta2> i fixed that locally but i wasn't sure about your intentions for the mime types
[16:07] <pitti> fta2: mime assocations should be there, of course
[16:07] <pitti> I just need to hammer a lot on this post_install stuff that upstream provides
[16:07] <pitti> to make it work at build time
[16:07] <pitti> so there are certainly still smaller bugs in it
[16:08] <fta2> last time i tried, calibre was not able to detect my PRS 700
[16:10] <vuntz> pitti: which tarballs are you looking at (re intltool stuff)?
[16:11] <vuntz> pitti: my gnome-panel tarball doesn't have all this, eg
[16:11] <pitti> vuntz: hm, nautilus was one, IIRC
[16:11] <vuntz> indeed
[16:11] <pitti> but good to know that they will disappear at all
[16:11] <pitti> that'll make such things so much easier
[16:12] <pitti> fta2: I see three PRS700 vendor/product IDs in /usr/share/hal/fdi/information/15osvendor/10-calibre.fdi; is your's amongst those?
[16:13] <pitti> fta2: erm, in fact, that's just one ID (the other looks like the same in decimal)
[16:14] <fta2> pitti: I can't test right now, i had to send my reader back to sony, broken
[16:14] <fta2> software bug of some kind
[16:14] <fta2> it froze, and now it is no longer able to complete the boot sequence. too bad.
[16:15] <pitti> ugh
[16:15] <pitti> fta2: poor you
[16:15] <pitti> fta2: I got it on January 5, and I won't give it away any more. ever.
[16:15] <pitti> I just love this thing
[16:15] <pitti> (I have a 505)
[16:19] <fta2> I like mine too, but a 705 would be nice if they can make it as readable as the 505
[16:21] <fta2> the touchscreen in the 700 is very nice, but it makes the device harder to read in under some light conditions (too much reflections)
[16:22] <pitti> chrisccoulson: hm, which bug was that? I didn't get mail about the patch
[16:22] <chrisccoulson> bug 314263
[16:28] <pitti> chrisccoulson: thanks, will upload; do you want to put this into the upstream bug, or shall I?
[16:28] <chrisccoulson> i'm just doing that now
[16:30] <chrisccoulson> thats on the upstream bug now
[16:30] <pitti> rock
[16:47] <vuntz> pitti: I think people would love to see time measurement for the gettext file. Ie, what's the impact if you have to build, say, the applications menu
[16:55] <pitti> vuntz: just replied to Matthias' mail, with a pointer to the benchmarks
[16:56] <pitti> vuntz: I was actually quite surprised to see that it just disappears in the noise
[16:56] <pitti> I had expected it to have at least a two-second penalty
[16:56] <pitti> but it seems that gettext()'s mmap lookup is pretty darn fast :)
[17:21] <rickspencer3> bryce: tseliot: ping
[17:21] <tseliot> rickspencer3: hey
[17:21] <rickspencer3> if bryce is here, I thought we might briefly discuss your "hold for several seconds" offer
[17:22] <tseliot> ok
[17:22] <rickspencer3> tseliot: you are a total rock start
[17:22] <rickspencer3> I'll be back soon
[17:42] <maxb> tseliot: Hi, I had cause to reopen the tasks in bug 307306, which I did by just setting them back to the status they had before they were changed to "Fix Released", but that status was "In Progress" - I'm not sure whether that's an accurate statement any longer. Could you check whether you still want to be shown as the assignee of them?
[17:43] <tseliot> maxb: let me check
[17:43] <maxb> thanks
[17:47] <tseliot> maxb: they have yet to accept the patch in comment 10 in the gnome bugzilla. The authors are still discussing this
[17:47] <tseliot> maxb: let's keep things as they are
[17:47] <maxb> ok
[17:48] <maxb> Did you see my comment on g-p-m still having problems even with all the patches?
[17:54] <tseliot> maxb:did you apply also the 2 patches which upstream hasn't adopted yet?
[17:55] <tseliot> did
[17:56] <maxb> http://bugzilla.gnome.org/attachment.cgi?id=126753&action=view and http://bugzilla.gnome.org/attachment.cgi?id=126770&action=view ?
[17:58] <tseliot> maxb: I meant the ones for the gnome-settings-daemon i.e. for gnome-desktop
[17:58] <bryce> rickspencer3: yep I'm around
[17:59] <tseliot> maxb: this one: http://bugzilla.gnome.org/attachment.cgi?id=126905&action=view
[17:59] <maxb> Yes - (as per my comment 33 in the LP bug)
[18:00] <rickspencer3> so, should we talk about tseliot's latest proposal related to control-alt-delete?
[18:00] <maxb> (and my last comment in the LP bug too)
[18:01] <tseliot> maxb: let's discuss this in the bug report
[18:03] <maxb> Sure - I just wanted to check you'd seen that additional issue (and didn't want me to make an entirely separate bug about it)
[18:03] <tseliot> bryce: https://code.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/+merge/3208/comments/7142
[18:04] <bryce> rickspencer3, tseliot: could we just take the opensuse patch?  It's already been thoroughly tested
[18:05] <mvo> I'm in favour of this solution (press it two times or 5s, I don't care personally which one is used)
[18:05] <rickspencer3> I am concerned that we are deviating from our decsion at UDS
[18:05] <rickspencer3> what changed?
[18:06] <tseliot> bryce: I have the patch here and the patch can also be modified (if Mark agrees)
[18:07] <rickspencer3> are we only considering this patch because we don't know if we'll get the xorg.conf editor ready for Jaunty/universe?
[18:09] <bryce> rickspencer3: my opinion is 1) we should not put in a patch, just let the shortcut die.  2) if we must put in a patch to retain the shortcut, then go with the (already tested) opensuse patch.
[18:09] <tseliot> I'm simply open to this because other developers suggested this change. The xorg-options-editor will be available in universe only
[18:09] <rickspencer3> tseliot: understood
[18:10] <rickspencer3> I should point out how much I appreciate your efforts here.
[18:10] <rickspencer3> Your pursuit of quality related to x has been very impressive and appreciated!
[18:10] <tseliot> :-)
[18:11] <rickspencer3> May I propose that we let it die for the alpha next week, and see what kind of feedback/response we get?
[18:11] <rickspencer3> that would include not having the GUI selector for Ubuntu as well
[18:11] <rickspencer3> mvo: thoughts?
[18:11] <tseliot> it's not a bad idea
[18:12] <bryce> I'm on board with that
[18:12] <mvo> I'm ok with that, as long as we do not disable magic sysreq :)
[18:12] <rickspencer3> bryce: we'll still look at tseliot's editor next week though, right?
[18:12] <bryce> yep
[18:12] <tseliot> ok
[18:13] <mvo> (I always thought that ctrl-alt-backspace does more than alt-sysreq-k - but I never checked that)
[18:13] <bryce> mvo, other way around
[18:13] <rickspencer3> this means that we are just going to use the upstream x behavior, right? No delta to maintain?
[18:13] <tseliot> yep
[18:13] <bryce> correct
[18:13] <rickspencer3> has OpenSuse approached upstream with their patch?
[18:14] <bryce> yes
[18:15]  * mvo needs to leave for dinner
[18:15] <bryce> rickspencer3: that was actually what sparked off the whole thread which resulted in the key getting disabled
[18:15]  * tseliot needs to leave for dinner too
[18:15] <rickspencer3> bye mvo and tseliot: thanks
[18:15] <rickspencer3> bryce: so around and around we go
[18:15] <rickspencer3> :)
[18:15] <bryce> yep
[18:15] <bryce> in fact it's a bit more circular
[18:16] <rickspencer3> so the plan now is not to change the plan of record :)
[18:16] <bryce> this really got started in the ctrl-alt-backspace spec, as one person was advocating the opensuse patch over our design approach (hold for 5 sec)
[18:17] <bryce> I think I said something about that it'd be so much easier if this was upstream
[18:17] <bryce> anyway, the guy then went directly to upstream to lobby them to take the opensuse patch
[18:18] <bryce> rickspencer3: I can try to update the merge request
[18:19] <rickspencer3> bryce: I'm not sure which request you are referring to. The upstream one to take the OpenSuse patch?
[18:20] <bryce> rickspencer3:  no, alberto's merge request #3208
[18:22] <rickspencer3> yes
[18:22] <rickspencer3> we shouldn't make any changes until we see if we get feedback after the alpha
[18:23] <rickspencer3> if we do need to change, we have several low risk ways of doing so, depending on what problems are reported
[18:29] <calc> bryce: well it would be nice if it was done upstream so it would work the same across all Xorg installs :)
[18:32] <bryce> calc: true true
[18:32] <bryce> calc: I think upstream has made their final decision on this though.
[18:41] <calc> bryce: so upstream disabled it entirely? and then all linux dists are finding ways to make it work again? sounds like upstream didn't really think that through
[18:41] <bryce> calc: no they didn't disable it, they just switched the default to off
[18:42] <calc> bryce: ah ok
[18:56] <seb128> pitti: dude, be less quick to upload patches, the glib one is wrong, cf upstream bug
[18:56] <pitti> seb128: right, I saw, but at least it works; I'm following the upstream bug
[18:56] <seb128> hum ok
[18:56] <seb128> I usually wait on upstream comments a few days before uploading changew when there is no hurry
[18:57] <seb128> especially for libraries
[18:57] <seb128> every has his own approch to changes ;-)
[18:57] <seb128> good work on the gettext thing btw
[18:57]  * seb128 hugs pitti
[18:58] <pitti> seb128: right, I just got lots of complaints about people not being able to send crash reports
[18:58]  * pitti hugs seb128 back
[18:58] <seb128> pitti: I would call that a feature and not a bug ;-)
[18:58] <pitti> seb128: it's good to have some time to clean up those old patches
[18:58] <pitti> although I am now currently arguing with upstream, but that's ok
[18:58] <pitti> seb128: hehe
[18:58] <pitti> <jedi wave>there are no crashes!
[19:02] <seb128> I enjoy this period of the cycle where we have time to catch up with bugs reports which stacked
[19:12] <seb128> mvo: bug #323306 bug #323309 are the same issue that the other one?
[19:30] <mvo> seb128: it looks like it, yes
[19:43] <pochu> mpt: filled bug upstream for the Vino notification area preferences we discussed the other day
[19:43] <pochu> mpt: GNOME #569888, in case you're interested
[19:47] <mpt> pochu, thanks, commented
[19:48] <pochu> great, thank you
[19:52] <pochu> mpt: I've also reported GNOME #569886, in case you want to have a look at it
[19:53] <pochu> heh
[19:53] <pochu> http://bugzilla.gnome.org/show_bug.cgi?id=569886
[19:53] <mpt> (why did you think ubottu would do any better with that?:-)
[19:54] <pochu> it was for you :-)
[19:55]  * mpt used ubottu's URL instead :-P
[19:55] <mpt> I don't see any Preferences dialog in 2.24.1
[19:56] <mpt> pochu, is this new in 2.26?
[19:56] <pochu> mpt: System>preferences>Remote desktop
[19:56] <pochu> mpt: no, it's been redesigned
[19:56] <mpt> huh
[19:56] <mpt> Is that related at all to Applications > Internet > Remote Desktop Viewer?
[19:56] <pochu> more or less
[19:57] <mpt> Then why doesn't the latter provide access to the former?
[19:57] <pochu> they are different applications. Vino (the system preferences) is to share your desktop via VNC so that other people can connect to your computer and control it remotely
[19:58] <pochu> Remote Desktop Viewer (vinagre) is to connect to a remote computer via VNC
[19:58] <pochu> so we could say one's the server and the other the client
[19:58] <mpt> oh I see
[19:58] <mpt> one is from, the other is to
[19:58] <pochu> but the preferences is to provide access locally, and you usually don't want to connect to localhost
[19:58] <pochu> so that's why it doesn't provide access from the preferences to vinagre
[19:58] <pochu> yeah, that's it
[19:58] <mpt> fair enough
[20:07] <seb128> mvo: bug #323316 seems a common one
[20:07] <mvo> seb128: is it always triggered by the xine crash?
[20:08] <seb128> mvo: it seems indeed
[20:09] <mvo> seb128: could you please ask the users if they can attach their /var/lib/dpkg/status file (i did it for this one)?
[20:09] <seb128> mvo: ok will do
[20:09] <mvo> seb128: I work on a fix now
[20:09] <pochu> hey seb128 and mvo
[20:10] <mvo> seb128: that is intrepid right? that makes it doublely bad
[20:10] <seb128> mvo: I don't think there is a real hurry since that's only a candidate update but should be fixed before having those moved to intrepid-updates
[20:10] <seb128> hello pochu
[20:10] <mvo> seb128: aha, good
[20:10]  * mvo s blood pressure decreases a lot 
[20:11] <seb128> mvo: it will not be moved to intrepid-updates this week so let's look at that during the sprint
[20:12] <mvo> seb128: hm, I wonder if I can reproduce it here with the xine update, than I don't need to wait for a status file
[21:00] <seb128> mvo: #323316 the guy replied to your request
[21:00] <mvo> seb128: and I replied too :)
[21:01] <seb128> mvo: ok, you are faster than me at reading emails ;-)
[21:01]  * seb128 hugs mvo
[21:04] <mvo> only this time, only this time .)
[21:26] <mvo> seb128: I may have a fix, now I just need a way to reproduce the intrpeid failure, the fix is based on my theory how the failure happend. maybe lool knows how to reproduce
[21:26] <seb128> mvo: it's specific to some locales apparently
[21:27] <mvo> aha
[21:27] <mvo> good
[21:29] <chrisccoulson> hi pitti - you still about?
[21:31] <seb128> hey chrisccoulson, I think he ran for the weekend
[21:32] <chrisccoulson> ah
[21:32] <chrisccoulson> i just scrolled through the chat history actually
[21:32] <chrisccoulson> he already knows my patch was wrong ;)
[21:32] <seb128> chrisccoulson: thanks for the work you are doing on the desktop bugs btw ;-)
[21:32] <chrisccoulson> you're welcome
[21:33] <chrisccoulson> i havent had much time to work on it this week really
[21:36] <chrisccoulson> hey seb128 - i see you packaged the new version of gdm in the ubuntu-desktop ppa for intrepid
[21:36] <seb128> indeed
[21:36] <chrisccoulson> were you planning to do that for jaunty too?
[21:36] <seb128> did you read my email to the ubuntu-desktop mailing list?
[21:37] <chrisccoulson> not yet
[21:37] <chrisccoulson> ah, i'm not subscribed to that list i don't think
[21:37] <chrisccoulson> that could be why;)
[21:39] <seb128> basically it will go to universe this cycle
[21:39] <seb128> but waiting for some feedback first to upload
[21:40] <chrisccoulson> thanks :) i've just subscribed to the list now