[00:06] Anyone else on intel graphics hardware or otherwise finding themselves severely affected by bug 307306 still? [00:06] Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress] https://launchpad.net/bugs/307306 [00:07] maxb: still slow for me [00:08] maxb: not sure it's entirely gpm's fault, though the symptoms suggest that it is at least related [00:09] 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] 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 === bluesmoke_ is now known as Amaranth [06:38] i have written a program using libwnck which activates the neighbor workspace [06:38] but when executed it returns null [06:39] even though there is a neighbor workspace still is not recognizing [06:39] can u tell me what is the problem? [06:48] sainath: If you're using compiz there are no workspaces [06:48] Well, there is the one you're on, but it is split up into viewports [06:49] then which methods i have to use? [06:52] 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] 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] k [06:55] i now understood where the problem is [06:55] thanks [06:55] then use wnck_workspace_get_viewport_x/y to figure out where you are [06:55] i'll figure it out [06:56] k [06:56] sainath: then wnck_screen_move_viewport to move [06:56] yes [06:56] how viewport values change for diff workspaces? [06:57] No one mixes workspaces and viewports [06:57] It's technically possible but you'd go insane as there is no way to manage it [06:58] k [06:58] 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] k [07:36] Good morning [08:22] hey, is there a simple way to disable GNOME's hardcoding of 96 dpi? [08:32] nevermind, found it === BugMaN1 is now known as BugMaN [09:14] seb128: are you planning major new changes in GNOME until next Thursday (alpha-4)? [09:15] pitti: GNOME 2.25.90 due next week so yes [09:15] seb128: we'll have a soft freeze again Tue to Thu; do you think it's possible to get that in? [09:15] (remember, we are also on the sprint) [09:16] 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] seb128: okay; in theory we could also do them the week after, if the sprint is too busy? [09:16] pitti: having freezes during new GNOME weeks suck, I can't say now how busy I will be during the sprint [09:17] 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] 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] oh, ok [09:24] seb128: the compiz session problem should be fixed with the next upload [09:24] mvo: cool, what did you change? [09:25] 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] Gnome bug 559450 in gnome-session "Gnome-session should try to match .desktop files against XSMP and/or resumed clients" [Normal,Unconfirmed] [09:25] did I mention that compiz upstream are rockstars ;) ? [09:25] morning everyone [09:25] 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] lut huats [09:28] 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] mvo: I'll do updated bootchart once it's available ;-) [09:28] * seb128 eyes vuntz [09:28] thanks! [09:29] 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? === seb128_ is now known as seb128 [09:47] 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] i have used libwnck funcin my prog === asac_ is now known as asac [10:59] mvo: could you look to bug #322955? [10:59] Launchpad bug 322955 in gtk+2.0 "package libgtk2.0-bin 2.14.4-0ubuntu2 failed to install/upgrade: package libgtk2.0-bin is already installed and configured" [Undecided,New] https://launchpad.net/bugs/322955 [11:06] seb128: done [11:06] mvo: thanks [11:07] 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] mvo: did you see my ping about an another upgrade bug yesterday? [11:13] mvo: btw this guy opened several bugs you might want to dup the other ones [11:48] seb128: yes, I have it open somewhere, it was a dpkg issue update-manager should be able to resolve it automatically [11:50] mvo: there is over a thousand of apport-package bugs open [12:04] seb128: stack trace of the panel hang? [12:05] vuntz: I did restart it since, there was one thread blocked on a e_flag_something call [12:05] I will get it for you next time but it seems similar to the bug before your changes [12:05] seb128: was it talking about a thread? [12:05] talking? [12:05] seb128: and are you using a calendar that requires a password? [12:06] no [12:06] but evolution was frozen too [12:06] ok, then not what I thought [12:06] I think e-d-s got screwed [12:06] seb128: I'd blame the eds library first, fwiw ;-) [12:06] the applets were still working [12:06] yes, evolution was frozen too [12:06] but I would expect to still have working menus when the clock applet hangs [12:07] that + nozap in jaunty = no easy way to close your session [12:08] seb128: don't compile the clock in process :-) [12:08] seb128: alt+sysrq+k ? [12:08] seb128: there's a configure flag [12:08] seb128: apport-package bugs> right, they deserve attention [12:09] vuntz: .desktop gettext patch> why did you add this fallback to _G_KEY_FILE_DEFAULT_DOMAIN ("desktop_translations")? [12:09] pitti: I did use power button which opens the session dialog ;-) [12:09] vuntz: right but that would means extra ressources use [12:09] seb128: oh, if that still works, it is so much better than killing X.. [12:10] well theorically [12:10] * seb128 looks at vuntz again [12:10] 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] but right now session closing is doing really different [12:10] +nothing [12:10] vuntz: but doesn't that require you to duplicate the application's .mo files to "desktop_translations.mo"? [12:10] pitti: (and because the KDE people didn't implement the gettext key in openSUSE, just hacked it this way) [12:11] pitti: no, we just have the translations from the desktop file [12:11] vuntz: I don't think I can justify this bit for upstream inclusion [12:11] vuntz: do you want that upstream as well? [12:11] pitti: yeah, this one is... harder :-) Although it makes some sense from a distro point of view [12:12] pitti: note that it's also why we first check for translation with a context [12:12] 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] 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] mvo: try to organize a bug day to clean those? [12:13] vuntz: also, do you still remember why you need key_file->file_basename ? [12:13] pitti: makes sense [12:14] pitti: for the context, which is needed for the desktop_translations.mo stuff [12:14] aaah, so it's part of that fallback [12:14] merci [12:14] (the context is the desktop filename) [12:15] lunch, bbl [12:16] vuntz: uh, your patch calls setlocale (LC_MESSAGES, NULL); [12:16] vuntz: that shouldn't really be in glib, should it? applications should usually initialize/set their locales? [12:17] vuntz: ignore me, I clearly need food [12:17] pitti: nope, it's used [12:17] :-) [12:17] NULL != "" [12:41] seb128, my gnome-screensaver is severely broken in jaunty. Seems to be bug 320666 [12:41] Launchpad bug 320666 in gnome-screensaver "gnome-screensaver fails to unlock after gtk 2.15.0 upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/320666 [12:42] ++ [12:47] I use scim but it doesn't seem to be related. [12:48] fta2, I have the same bug [13:06] fta2: don't use an im method and that will work correctly ;-) [13:07] I don't use a IM method I guess [13:08] crevette: if you didn't set some special variable for that you don't [13:48] pitti: you are made of awesome [13:48] rickspencer3: what a nice way to say "good morning" :-) [13:49] rickspencer3: what did I break this time? [13:49] pitti: isn't that early to say morning in his timezone? ;-) [13:49] I got up early today to get my head around the release status for the meeting, and was greeted with your email [13:50] seems Rick is a true larch [13:50] rickspencer3: heh [13:50] "larch" as in the tree? [13:50] as in the bird? [13:50] don't you say larch vs. owl, too? [13:50] aaah [13:51] as in, people who get up early, and people who stay up late? [13:51] we do way night owl, but I'm not sure about "larch" [13:51] we do say "early bird" though [13:51] * pitti checks the dictionary [13:51] oh, I think I meant to say "lark" [13:51] actually, I never got up this early before I stared working at Canonical [13:52] similar in German as well, Lärche vs. Lerche [13:53] that makes sense [13:54] thanks for putting the release status page together, I was pretty worried about getting that done before the meeting this morning [13:55] 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] 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] but the code reads correctly, it *should* prefer inline over gettext [13:59] pitti: panel doesn't use gnome-desktop to read desktop files anymore [14:03] vuntz: on that matter, it was already deprecated years ago; does anything still use it, btw? [14:03] (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] hey andreasn [14:06] hi crevette [14:09] 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] vuntz: I ported your patch, and it shows GettextTranslation [14:11] pitti: I think some people still use gnome-desktop since they didn't port to gkeyfile [14:11] pitti: it should [14:11] let me try it here [14:12] but looking at the code, the fallback should be correct [14:12] * pitti scratches his head [14:14] pitti: err. Doesn't work anymore? [14:14] grml [14:15] vuntz: not for you either? [14:15] vuntz: ok, then I'm not on crack [14:15] vuntz: I'll have a look at this [14:15] let me finish the two other things I started, and I'll look at this [14:15] 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] pitti: not replying since vuntz did before [14:16] kwwii: no clue about that we can have a look next week though [14:16] brb [14:17] 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] 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] it did, we tested it when doing the change [14:17] vuntz: don't forget to fix gnome-session too ;-) [14:17] brb [14:19] vuntz: IMHO it should be moved out of, and after the loop, and s/strcmp (msg_locale, languages[i]) == 0/!translated_value/ [14:26] pitti: do you think it's worthing bringing up the fglrx/-ati situation at the release status meeting? [14:27] rickspencer3: my report mentions it, and I don't think we can do much about it; AMD/NVidia know about the situation [14:29] vuntz: yep, that helped, works perfectly now [14:29] FWIW, hooray for -panel's inotity; I still remember, four years ago I had to restart the panel each time... [14:29] inotify, too [14:35] pitti, i think i'm getting somewhere with bug 314263 [14:35] Launchpad bug 314263 in gvfs "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Confirmed] https://launchpad.net/bugs/314263 [14:35] * pitti hugs chrisccoulson [14:35] you can't contact the gvfs daemon when you use sudo [14:36] sudo scrubs the DBUS_SESSION_BUS_ADDRESS from the environment [14:36] 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] ah, maybe; since in intrepid that worked without problems [14:39] 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] that obviously isn't working though [14:40] that's the next bit to figure out! [14:41] **i meant g_vfs_get_default [14:41] d'oh [14:52] vuntz: patch sent upstream, you are in CC [14:57] pitti: you attend the release meeting, right? [14:57] rickspencer3: right, I do, /joining now [14:57] ok [14:57] I wasn't sure. I didn't see you on the invite, but it sounded like you planned to attend [14:58] I usually do [14:58] great [15:14] 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] chrisccoulson: you are awesome [15:14] **blushes** [15:14] lol [15:14] i havent written it yet;) [15:15] well, debugging the reason is great on its own [15:15] it all makes sense now i think [15:34] 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] davmor2: that's nautilus [15:34] triggered through gvfs [15:34] pitti: thanks, you're awesome! [15:35] pitti: thanks I thought it would be something like that but figured I'd best be sure :) [15:35] 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] 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] vuntz: btw, I'm using this in our build rules: [15:37] sed -ri '/^(Name|GenericName|Comment)\[/d' $$d; \ [15:37] echo "X-GNOME-Gettext-Domain=$$DOMAIN" >> $$d; \ [15:38] with $d iterating over find debian/$(cdbs_curpkg) -type f \( -name "*.desktop" -o -name "*.directory" [15:39] sounds like what we do :-) [15:40] great [15:40] . o O { good to have a bug fix cycle like jaunty to clean up such old mess) [15:48] vuntz: btw, did you patch pyxdg for that, too? [15:54] pitti: no [15:59] pitti - that patch is working ok. i've made a debdiff if you want to sponsor it [15:59] chrisccoulson: can you please attach it to the bug and subscribe "pitti" (should already be, though) [15:59] chrisccoulson: I'll sponsor it the [15:59] it's attached to the bug now, and you're already subscribed:) [16:00] I should get mail soon then [16:00] cool. thanks [16:00] thanks to you! [16:01] you're welcome [16:03] pitti, why did you drop the file association in calibre? lrf, lit, ... [16:03] +s [16:03] 'drop'? [16:03] I didn't drop them deliberately [16:04] 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] fta2: ah, you mean it has never been there in the first place? [16:05] I thought you meant "recently", as in "in the last upload" [16:06] no [16:06] fta2: can you please file a bug about it and assign it to me? ("pitti") [16:06] there's also a typo in the control file [16:07] i fixed that locally but i wasn't sure about your intentions for the mime types [16:07] fta2: mime assocations should be there, of course [16:07] I just need to hammer a lot on this post_install stuff that upstream provides [16:07] to make it work at build time [16:07] so there are certainly still smaller bugs in it [16:08] last time i tried, calibre was not able to detect my PRS 700 [16:10] pitti: which tarballs are you looking at (re intltool stuff)? [16:11] pitti: my gnome-panel tarball doesn't have all this, eg [16:11] vuntz: hm, nautilus was one, IIRC [16:11] indeed [16:11] but good to know that they will disappear at all [16:11] that'll make such things so much easier [16:12] 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] fta2: erm, in fact, that's just one ID (the other looks like the same in decimal) [16:14] pitti: I can't test right now, i had to send my reader back to sony, broken [16:14] software bug of some kind [16:14] it froze, and now it is no longer able to complete the boot sequence. too bad. [16:15] ugh [16:15] fta2: poor you [16:15] fta2: I got it on January 5, and I won't give it away any more. ever. [16:15] I just love this thing [16:15] (I have a 505) [16:19] I like mine too, but a 705 would be nice if they can make it as readable as the 505 [16:21] 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] chrisccoulson: hm, which bug was that? I didn't get mail about the patch [16:22] bug 314263 [16:22] Launchpad bug 314263 in glib2.0 "regression - URIs opened with firefox %u load as local files (file:///...)" [High,Triaged] https://launchpad.net/bugs/314263 [16:28] chrisccoulson: thanks, will upload; do you want to put this into the upstream bug, or shall I? [16:28] i'm just doing that now [16:30] thats on the upstream bug now [16:30] rock [16:47] 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] vuntz: just replied to Matthias' mail, with a pointer to the benchmarks [16:56] vuntz: I was actually quite surprised to see that it just disappears in the noise [16:56] I had expected it to have at least a two-second penalty [16:56] but it seems that gettext()'s mmap lookup is pretty darn fast :) [17:21] bryce: tseliot: ping [17:21] rickspencer3: hey [17:21] if bryce is here, I thought we might briefly discuss your "hold for several seconds" offer [17:22] ok [17:22] tseliot: you are a total rock start [17:22] I'll be back soon [17:42] 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:42] Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress] https://launchpad.net/bugs/307306 [17:43] maxb: let me check [17:43] thanks [17:47] maxb: they have yet to accept the patch in comment 10 in the gnome bugzilla. The authors are still discussing this [17:47] maxb: let's keep things as they are [17:47] ok [17:48] Did you see my comment on g-p-m still having problems even with all the patches? [17:54] maxb:did you apply also the 2 patches which upstream hasn't adopted yet? [17:55] did [17:56] http://bugzilla.gnome.org/attachment.cgi?id=126753&action=view and http://bugzilla.gnome.org/attachment.cgi?id=126770&action=view ? [17:58] maxb: I meant the ones for the gnome-settings-daemon i.e. for gnome-desktop [17:58] rickspencer3: yep I'm around [17:59] maxb: this one: http://bugzilla.gnome.org/attachment.cgi?id=126905&action=view [17:59] Yes - (as per my comment 33 in the LP bug) [18:00] so, should we talk about tseliot's latest proposal related to control-alt-delete? [18:00] (and my last comment in the LP bug too) [18:01] maxb: let's discuss this in the bug report [18:03] 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] bryce: https://code.launchpad.net/~albertomilone/gnome-control-center/randr-virtual/+merge/3208/comments/7142 [18:04] rickspencer3, tseliot: could we just take the opensuse patch? It's already been thoroughly tested [18:05] I'm in favour of this solution (press it two times or 5s, I don't care personally which one is used) [18:05] I am concerned that we are deviating from our decsion at UDS [18:05] what changed? [18:06] bryce: I have the patch here and the patch can also be modified (if Mark agrees) [18:07] 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] 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] I'm simply open to this because other developers suggested this change. The xorg-options-editor will be available in universe only [18:09] tseliot: understood [18:10] I should point out how much I appreciate your efforts here. [18:10] Your pursuit of quality related to x has been very impressive and appreciated! [18:10] :-) [18:11] May I propose that we let it die for the alpha next week, and see what kind of feedback/response we get? [18:11] that would include not having the GUI selector for Ubuntu as well [18:11] mvo: thoughts? [18:11] it's not a bad idea [18:12] I'm on board with that [18:12] I'm ok with that, as long as we do not disable magic sysreq :) [18:12] bryce: we'll still look at tseliot's editor next week though, right? [18:12] yep [18:12] ok [18:13] (I always thought that ctrl-alt-backspace does more than alt-sysreq-k - but I never checked that) [18:13] mvo, other way around [18:13] this means that we are just going to use the upstream x behavior, right? No delta to maintain? [18:13] yep [18:13] correct [18:13] has OpenSuse approached upstream with their patch? [18:14] yes [18:15] * mvo needs to leave for dinner [18:15] 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] bye mvo and tseliot: thanks [18:15] bryce: so around and around we go [18:15] :) [18:15] yep [18:15] in fact it's a bit more circular [18:16] so the plan now is not to change the plan of record :) [18:16] 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] I think I said something about that it'd be so much easier if this was upstream [18:17] anyway, the guy then went directly to upstream to lobby them to take the opensuse patch [18:18] rickspencer3: I can try to update the merge request [18:19] bryce: I'm not sure which request you are referring to. The upstream one to take the OpenSuse patch? [18:20] rickspencer3: no, alberto's merge request #3208 [18:22] yes [18:22] we shouldn't make any changes until we see if we get feedback after the alpha [18:23] if we do need to change, we have several low risk ways of doing so, depending on what problems are reported [18:29] bryce: well it would be nice if it was done upstream so it would work the same across all Xorg installs :) [18:32] calc: true true [18:32] calc: I think upstream has made their final decision on this though. [18:41] 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] calc: no they didn't disable it, they just switched the default to off [18:42] bryce: ah ok [18:56] pitti: dude, be less quick to upload patches, the glib one is wrong, cf upstream bug [18:56] seb128: right, I saw, but at least it works; I'm following the upstream bug [18:56] hum ok [18:56] I usually wait on upstream comments a few days before uploading changew when there is no hurry [18:57] especially for libraries [18:57] every has his own approch to changes ;-) [18:57] good work on the gettext thing btw [18:57] * seb128 hugs pitti [18:58] 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] pitti: I would call that a feature and not a bug ;-) [18:58] seb128: it's good to have some time to clean up those old patches [18:58] although I am now currently arguing with upstream, but that's ok [18:58] seb128: hehe [18:58] there are no crashes! [19:02] I enjoy this period of the cycle where we have time to catch up with bugs reports which stacked [19:12] mvo: bug #323306 bug #323309 are the same issue that the other one? [19:13] Launchpad bug 323306 in rhythmbox "Software updating issue occured after a set up updates this week. Fixed by going to 'fix broken dependencies' in Synaptic" [Undecided,New] https://launchpad.net/bugs/323306 [19:13] Launchpad bug 323309 in gtk+2.0 "package libgtk2.0-bin 2.14.4-0ubuntu2 failed to install/upgrade: package libgtk2.0-bin is not ready for configuration" [Undecided,New] https://launchpad.net/bugs/323309 [19:30] seb128: it looks like it, yes [19:43] mpt: filled bug upstream for the Vino notification area preferences we discussed the other day [19:43] mpt: GNOME #569888, in case you're interested [19:43] Gnome bug 569888 in Preferences Dialog "Merge notification area preference into a checkbox" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=569888 [19:47] pochu, thanks, commented [19:48] great, thank you [19:52] mpt: I've also reported GNOME #569886, in case you want to have a look at it [19:53] Error: Could not parse XML returned by Gnome: timed out (http://bugzilla.gnome.org/xml.cgi?id=569886) [19:53] heh [19:53] http://bugzilla.gnome.org/show_bug.cgi?id=569886 [19:53] Error: Could not parse XML returned by Gnome: timed out (http://bugzilla.gnome.org/xml.cgi?id=569886) [19:53] (why did you think ubottu would do any better with that?:-) [19:54] it was for you :-) [19:55] * mpt used ubottu's URL instead :-P [19:55] I don't see any Preferences dialog in 2.24.1 [19:56] pochu, is this new in 2.26? [19:56] mpt: System>preferences>Remote desktop [19:56] mpt: no, it's been redesigned [19:56] huh [19:56] Is that related at all to Applications > Internet > Remote Desktop Viewer? [19:56] more or less [19:57] Then why doesn't the latter provide access to the former? [19:57] 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] Remote Desktop Viewer (vinagre) is to connect to a remote computer via VNC [19:58] so we could say one's the server and the other the client [19:58] oh I see [19:58] one is from, the other is to [19:58] but the preferences is to provide access locally, and you usually don't want to connect to localhost [19:58] so that's why it doesn't provide access from the preferences to vinagre [19:58] yeah, that's it [19:58] fair enough [20:07] mvo: bug #323316 seems a common one [20:07] Launchpad bug 323316 in gtk+2.0 "package libgtk2.0-dev 2.14.4-0ubuntu2 failed to install/upgrade: package libgtk2.0-dev is already installed and configured" [Undecided,New] https://launchpad.net/bugs/323316 [20:07] seb128: is it always triggered by the xine crash? [20:08] mvo: it seems indeed [20:09]