[00:23] RAOF: hi [00:23] RAOF: so turns out we don't need screen crtc pixmaps to do what I want [00:23] Funkysauce. [00:23] RAOF: I did it using a trick in xcomposite [00:24] RAOF: so now all we need is for lightdm to implement a simple compositor and have that carry through into the session until compiz tries to replace it, if at all possible [00:25] Probably fairly simple. [00:25] and then in the logout case, if it's possible to allow lightdm to "take over" a currently running x server, then have it's compositor replace the gnome-session one which will replace the compiz one [00:25] and ta-da, no flicker! :) [00:26] RAOF: actually, even for the restart case, it looks really cool [00:26] What's the XComposite trick? [00:27] instead of going CLUNCK, flashflashflashflashflash, VANISH, BOOM (shift) [00:27] it's just *stop* *start [00:27] RAOF: oh, the new compositor doesn't take the selection until it's painted at least one frame [00:27] so the old compositor stays around until the new compositor has done this [00:28] Nifty [00:29] (basically, there's a property that the outgoing and incoming compositors set on the window used for the composite selection which says they support the handoff protocol [00:30] so when the new compositor comes in, it checks for the existence of the protocol, and doesn't try to do CompositeRedirectManual, but instead does CompositeRedirectAutomatic and *doesn't* touch the composite overlay window [00:30] and then it paints one full frame [00:30] and then it takes the selection [00:31] upon losing the selection, the old compositor checks the new selection owner for the property, and if that's present, it doesn't unmap the composite overlay window or touch it in any way (but it does redirect using CompositeRedirectManual) [00:31] err, *unredirect [00:31] then the new compositor waits for the old one to finally go away, and does a redirect using CompositeRedirectManual, but the output window is still visible [00:32] (because both have a reference on it) [00:32] however, the only caveat so far is that it makes the giant assumption that you will lose the composite selection, which is a problem if you went from compositor to no compositor [00:33] Heh. [00:33] so if you replace compiz with an unpatched metacity your screen hangs [00:33] (mostly because of the loose marriage between 'compositor' and 'window manager') [00:34] I suppose I could make a new selection, but then I'd have to resort to checking incoming properties on the root window and I've found that to be racy [00:34] or it could just time out [00:38] RAOF: what I *really* want to do though is enforce compositing, like maybe we can do something in gnome-session to always try and composite the screen if it stops being composited or whatever, but that's really hard to do because of the way selections work [00:39] I wouldn't mind, personally, if the answer to "what happens if you run an unpatched metacity" was "it breaks". [00:39] RAOF: s/metacity/xmonad/ [00:40] think of the people who will ditch ubuntu for arch :p [00:40] s/metacity/*/ [00:40] unity-greeter could quite happily only do this when running an "Ubuntu" session, which we know will start Unity. [00:40] yeah I suppose [00:41] and then we could just ignore --replace except when allowing it inside of unity [00:41] And could start compiz with "--compositor-handoff" [00:41] but *gosh* that's a hack :p [00:41] similar idea to what GDM is doing with it being part GNOME Shell now if the hardware supports it [00:41] yeah [00:41] I'm not really keen on running compiz on lightdm [00:42] *thinks of the security implications* [00:42] And it's slow on startup. [00:42] compiz by itself is really fast to start [00:42] it could be faster [00:42] Oh, right. I was thinking a full session compiz. :) [00:42] but if you did composite --replace composite opengl its pretty much instance :) [00:42] err [00:42] *compiz [00:43] RAOF: I'm more thinking of [00:43] "hey, install this BLING BLING plugin" [00:43] "GLScreen::glPaintOutput () { execl ("/bin/bash"); } [00:44] my software center is busted, are y'all having any problems with it? [00:44] Nope. Well, apart from my self-inflicted PolicyKit wound. [00:45] I wonder if its possible to use PolicyKit for things other than granting root permissions [00:45] Yes, absolutely. [00:45] oh, cool [00:46] I get a blank white window and this is the only output on the terminal: http://paste.ubuntu.com/705203/ [00:46] I was thinking of something like being able to have a "blessed" screensaver window [00:46] It'll become more possible once https://bugs.freedesktop.org/show_bug.cgi?id=41025 gets accepted, too :) [00:46] Freedesktop bug 41025 in daemon "Add an ‘owner’ user to actions." [Enhancement,New] [00:46] smspillaz: PolicyKit doesn't actually grant root permissions anyway; it's just a way for $DAEMON to check whether $CLIENT should be able to perform $ACTION. [00:46] I figured [00:47] RAOF: and I suppose it gives keys or somesuch to applications so you don't have to authorize it all the time ? [00:48] Depends; you can define that in the action description: http://hal.freedesktop.org/docs/PolicyKit/polkit-conf.html#conf-declaring-actions [00:51] Although until that patch gets applied your $DAEMON needs to run as root for PolicyKit to be useful. [00:52] pitti: python plugins are broke in Totem (libpeas again) bug 855100 [00:52] Launchpad bug 855100 in totem "python plugins not working" [Undecided,Confirmed] https://launchpad.net/bugs/855100 [01:10] RAOF: neat === jincreator1 is now known as jincreator === ejat- is now known as ejat === micahg_ is now known as micahg === tkamppeter__ is now known as tkamppeter [05:19] Baurgh. What part of gdk_x11_display_grab are you not understanding, damnit? [06:01] Bah! Of course, my old nemesis, XSync. [06:14] RAOF: :) [06:15] RAOF: or XNextEvent [06:16] For my future self, in the hope that writing it down again will make it stick: If you call XGrabServer, it's a good really idea to XSync afterward if you expect it to take effect properly. [06:16] yeah [06:16] uhh actually [06:16] XGrabServer is synchronous iirc [06:16] it's XUngrabServer that isn't [06:16] or is it not synchronous? [06:17] smspillaz: So, turns out that if you fork quickly enough you can get in before XGrabServer takes effect. [06:17] since if that's the case there's lots of code in compiz that depends on sever grabs (because we send synthetic events) [06:17] XGrabServer was not sufficiently synchronous for my testing. [06:17] RAOF: hmm ok, I think I'll need to do XSync directly befor and after XGrabServer then [06:17] *before [06:18] well really, when you do XGrabServer, you should first do XSync, then XSynchronize, then XGrabServer, then do your stuff, then XUngrabServer [06:18] In my case, I was trying to check that I correctly handled the case where XGrabServer causes check_gl_texture_size to hang waiting for XOpenDisplay. [06:18] then XSynchronize (false) [06:18] RAOF: ah, yikes [06:19] I, too, thought that XGrabServer was synchronous, so I just called it at the top of the function that forks off check_gl_texture_size... which proceeded to *work* and happily return the correct GL_MAX_TEXTURE_SIZE. [06:19] huh [06:19] Obviously not the effect I was hoping for :) [06:20] So, in short: ?XGrabServer: your paranoia is justified.? [06:21] well, XGrabServer without synchronous behaviour kind of defeats the purpose of XGrabServer if you ask me [06:22] because what ends up happening is this: [06:22] listen only to me, stop listening only to me, do stuff [06:23] since if you're using server grabs, its likely that you're doing stuff with whats directly on the server at that time, which means you have to flush your output buffer [06:23] In this case, gnome-desktop only wants to batch up some X state fiddling into a single notify. [06:24] Oh, hai check_gl_texture_size. *You're* what's consuming 100% cpu? [06:38] good morning [06:41] Morning didrocks! [06:41] hey RAOF, how are you? [06:41] Chagrined. [06:42] For being insufficiently paranoid with check_gl_texture_size :) [06:42] Also, still slightly sick, but that's easier to ignore ? [06:44] oh really? [06:44] Good morning [06:44] Morning pitti [06:44] Oh, whoops. [06:45] * RAOF has noticed a *tiny* problem with the most recent gnome-desktop3 upload. [06:45] guten morgen pitti, feeling better? [06:45] We really should set --abort-on-upstream-changes by default, shouldn't we :) [06:46] didrocks: a bit, yes [06:46] hey RAOF [06:46] RAOF: I think dpkg 1.16.1 will help [06:47] RAOF: you got a debian-changes* stuff that reverted your patch? [06:47] That basically flips that option to default-on, doesn't it? [06:47] seems so, yes [06:49] oneiric-proposed is open, right? [06:53] RAOF: yes [07:10] pitti, hi [07:10] pitti, first thank you for approving my 0-day SRUs during the weekend. [07:11] tkamppeter: guten Morgen [07:12] pitti, I have a little problem with my eeePC. I got a flooding of WLAN password requests due to bug 868293 and then turned off WLAN in the indicator applet menu. This also removed the menu entry to turn on WLAN again, and now I am totally locked out, the machine looks like having no WLAN by hardware now. [07:12] Launchpad bug 868293 in unity "compiz assert failure: *** glibc detected *** compiz: free(): corrupted unsorted chunks: 0xa05166e0 *** (drm_intel_gem_bo_unreference)" [High,Fix committed] https://launchpad.net/bugs/868293 [07:12] pitti, as usual, scrambling bug numbers, I meant bug 854833. [07:13] Launchpad bug 854833 in gnome-keyring "(oneiric) wireless passwords not remembered" [Undecided,Confirmed] https://launchpad.net/bugs/854833 [07:13] tkamppeter: that's something for cyphermox [07:15] cyphermox, hi [07:16] tkamppeter: he's in the US, so he'll answer this afternoon [07:16] pitti, as you have seen the CUPS SRU is verified. I have joined the two bugs as duplicates as they are fixed by the same patch. [07:19] pitti, do you know which package is the culprit for the disappeared WLAN? [07:22] tkamppeter: I don't, no; works here [07:23] good morning everyone [07:23] hey chrisccoulson [07:24] welcome back! (well, if we consider you didn't connect during your vacations ;)) [07:24] hi didrocks :) [07:24] pitti, have found out what happend: Turning of wireless has put the machine into inflight mode (did not see that directly as a plugged USB Bluetooth adapter carried on working, I pressed Fn + F2 to leave inflight mode, then the wireless entry reappeared in the menu and I could turn on wireless again by the menu. [07:24] thanks ;0 [07:24] how are you? [07:24] tkamppeter: aah, kill switch? [07:25] chrisccoulson: I'm fine thanks, and you? [07:25] didrocks, yeah, good thanks [07:25] hey chrisccoulson -- don't you need some holiday now? :-) [07:25] hi pitti. yeah, i'll need some more holiday again soon ;) [07:27] pitti, what do you mean with "kill switch"? [07:27] tkamppeter: the key/slider which disables/enables wifi is usually called "kill switch" [07:28] pitti, some boxes have a physical slider which cannot be set by software, this netbook not. [07:32] pitti, in this case the software can set the kill switch which this action should not do. [07:33] chrisccoulson: How would you like to test gnome-desktop later? [07:34] RAOF, sure, can do [07:34] I can either PPA it up or point you at a packaging branch. [07:43] chrisccoulson: First cut is in ppa:raof/aubergine, pending building. That should ensure your desktop is never blocked by check_gl_texture_size, no matter how crazy gnome-desktop/g-s-d want to be. [07:47] morning [07:59] hey rodrigo_ [08:02] Morning all! [08:04] hi pitti, Sweetshark [08:05] hey Sweetshark, how are you? [08:05] hey [08:05] good morning Sweetshark, rodrigo_ [08:05] hi didrocks, seb128 :) [08:06] hey didrocks pitti rodrigo_ [08:06] how is everybody, [08:06] bonjour seb128, ca va? [08:06] ? [08:06] pitti, ca va bien, merci ;-) [08:06] still a bit oneiric :) [08:06] hehe [08:06] pitti, how is your cold? [08:06] did you manage to get over it? [08:06] release candidates are built and on the tracker, if you guys feel so inclined [08:06] seb128: seems to be a very slow one; it's not very bad, but already lasting a week :/ [08:07] pitti, I will do some iso testing for sure today [08:07] let me start syncs while I catch up on emails etc [08:12] pitti: a cold takes 14 days to heal off, with medicine it takes two weeks ... [08:13] Sweetshark: that used to be 7 days -- the germs keep getting better! [08:13] pitti: we are training them with antibiotics [08:13] I don't [08:13] but they might have gotten resistant against chicken soup and apple pie as well [08:14] pitti: ow, now thats bad [08:20] pitti, do you know about udisk2 and davidz plans for it? [08:21] seb128: he wants to try and push it into gnome 3.4 [08:21] ok, what I was feating [08:21] but I haven't played around with it much yet [08:21] I'm pondering staying on GNOME 3.2 for the lts [08:21] it's somewhere on my list of things to do [08:21] do you see that as a risky move in a lts cycle? [08:21] it's installable in parallel with old udisks [08:21] moderate, I think [08:21] well, he's porting gnome-disk-utility and gvfs [08:21] it's completely rewritten [08:21] not sure he will keep both backends [08:22] seb128: no, I mean for other desktops like KDE [08:22] seb128: but anyway, it turns some concepts upside down [08:22] like the distinction between "internal" and "external" [08:22] I'd feel better if this landed in Q TBH [08:23] but then again, I need to actually look at it before I make up my mind [08:23] something to play with next week [08:23] ok, me as well [08:23] pitti, can you look before UDS? thanks ;-) [08:23] one thing I want to do is writing an integration test, similar to what udisks 1 has [08:23] pitti, it's going to be one of the parameters in the "what GNOME version to go for" discussion [08:23] seb128: ok, will make sure I'm prepared for this part [08:23] the glib changes desrt is doing makes me nervous for a lts as well [08:24] and since GNOME sucks at being able to ship a new version on a non current platform I doubt we will be able to take 3.4 without udisks2; glib 2.32 gtk 3.4 etc [08:26] udisks2 and glib/gdu/gvfs certainly go together, yes [08:28] yeah, as usually with GNOME you can't easily cherrypick components [08:28] it's the lot or nothing [08:29] well, that's fairly understandable, though [08:29] keeping both udisks 1 and 2 code in gdu/gvfs would be quite some effort, and nobody would extensively test that upstream anyway [08:29] pitti, well I still wish that "applications" like gedit, eog etc would be handled as standalone applications and a bit lax on their depends ;-) [08:30] I don't think the API changes at the gvfs level, though [08:30] so it still ought to be possible to update udisks/gdu/gvfs/glib, but keep the apps, for example [08:31] that's already something [08:31] well anyway something for UDS [08:31] I just wanted to make sure somebody has a clue about that transition at UDS for the discussion ;-) [08:32] pitti: does anyone know how to setup a software-raid after the install? Mine sorta kinda works -- it sometimes boots through, it is complaining about degradedraids on boot sometimes and just doesnt boot at all at other times (just hangs with a blank screen). I assume I would need to get my raid setup into the initramfs somehow maybe? [08:32] Sweetshark: did you try the latest udev from Friday/Saturday? [08:33] Sweetshark: you mean moving your root fs to raid after install? [08:33] I've done that on my server just through ssh years ago, with repartitioning two times (that was fun) [08:33] but I kept /boot/ on non-RAID; not sure if that works now [08:40] pitti: no, no fancy stuff like root or /boot on raid. Just /home and a custom partition. [08:40] Sweetshark: that should "just work" (tm); i. e. do the mdadm stuff, add /dev/mapper/whatever to /etc/fstab for /home [08:41] mdadm udev rules sohuld assemble the array on boot, and trigger the mounting [08:51] re [08:56] morning mvo, debugging aptdaemon I just realized that the session indicator performs a UpgradeSystem Simulate after every change of the transaction queue [08:56] mvo, that seems to be a little bit too much [08:56] mvo, the simulate is also processed in the main loop (we don't use threading in oneiric) so the system gets a short block after each transaction [08:57] glatzor: urgh [08:57] glatzor: that is very much not ideal [08:58] glatzor: hm, what can we do, what is the best way to fix session indicator? or should we simply do some clever caching? [08:59] mvo, for P indicator should use the PackageKit interface. The GetUpdates will be cached in aptdaemon. [09:00] mvo, it could listen to the org.debian.apt.CacheChanged transaction [09:00] transaction != signal [09:01] mvo, I am away [09:01] glatzor: thanks for the notify! [09:07] Aloha [09:16] mvo, the signal won't be enough. [09:17] mvo, it seems to be difficult to this right with the current infrastructure. we have to accept some inaccuranceness [09:17] ok [09:17] oh that word seems to be odd :) [09:17] I know what you mean [09:17] its just a bit inaccurate ;) [09:17] mvo, right :) [09:18] pitti: well, it doesnt "just work" here. and the sometimes works, sometimes doesnt stuff scares me a bit. [09:18] * mvo is still proud member of blatant errors and awkward grammar [09:18] * glatzor too [09:18] see you, mvo [09:19] * mvo waves [09:22] Sweetshark: when it doesn't work, does the /dev/mapper/* device exist? or not even that? [09:27] pitti: I am not used dmapper or lvm, just md. [09:28] Sweetshark: yes, but that should still end up in /dev/mapper/ [09:28] hmmm, so, since i went on vacation, something seems to have broken the panel menus in unity on my second monitor :( [09:28] they no longer stay open anymore, but instead, they appear briefly and close immediately again [09:28] that never used to happen [09:29] didrocks, have you seen that? [09:30] chrisccoulson: I'm not with my second monitor right now [09:30] njpatel: you still have your second monitor, isn't it, do you have this? ^ [09:30] Sweetshark: hm, or maybe not -- what do you get there, /dev/mdsomething? [09:30] hmmm, it's pretty broken. i tried logging out and back in again, just to make sure it wasn't transient [09:31] and it's consistently broken on my second monitor [09:31] all the menus are unusable [09:32] pitti: I have /dev/md/1 and /dev/md/2 in /etc/mdadm/mdadm.conf and am using the UUIDs of those arrays in fstab. However, even when booting trough I get /dev/md127 and /dev/md126 instead of 1 and 2 [09:32] chrisccoulson, didrocks, erm, no, but let me try [09:33] hey chrisccoulson [09:33] * njpatel upgrades first, though [09:33] Sweetshark: oh, mdadm.conf? that shouldn't have been necessary for some ten years or longer.. [09:33] hi seb128 [09:33] njpatel, chrisccoulson: kenvandine (I think) mentioned the same second monitor issue [09:33] ah, so it might not just be me then :) [09:33] chrisccoulson, how are you? had nice holidays? happy to be back? [09:33] okay [09:33] Sweetshark: perhaps try to move that away, and see what it does then? [09:33] damn [09:33] chrisccoulson, bug please, sir :) [09:33] Sweetshark: (just to rule out the possibility of some mis-configuration ther) [09:33] seb128, yeah, the holiday was great thanks [09:34] it felt like i never left really ;) [09:34] njpatel, did you manage to confirm it? [09:34] chrisccoulson, no, but I have a feeling you might be right [09:34] njpatel, chrisccoulson: bug #869196 [09:34] Launchpad bug 869196 in unity "unity panel menus don't stay open when clicked on second monitor" [Undecided,New] https://launchpad.net/bugs/869196 [09:34] not yet* [09:34] seb128, swheet [09:34] shweet* [09:34] excellent, thanks :) [09:35] it seems all the bugs come out of the woodwork when i finish my vacation ;) [09:35] no, they have been sitting there [09:35] heh [09:35] seb128: my concerns about clutter weren't so much about performance, but about not working at all on some hardware; or can that be ruled out? [09:35] the issue is that dx didn't fix bugs previous week because njpatel was not around [09:35] ah, ok [09:35] i found a nice bug for RAOF at the weekend too [09:35] seb128, come on, they were fixing bugs [09:36] pitti, well, if it's for games or side features it's easy enough to not care or turn the features off at beta time? [09:36] it's just the bugs are harder at this point the cycle, so sometimes they take days instead of hours [09:36] seb128: right; but I'm concerned about it for the video player [09:37] njpatel, yeah, sorry, it was a bit of exageration [09:37] seb128: TBH I'd rather stay with totem 3.0 than moving to banshee or clutter-totem for LTS [09:37] njpatel, I'm a bit annoyed that things like the launcher not showing, the dash not getting the focus, the right menu list not working on for use, etc didn't get fixed [09:37] njpatel, sorry for turning that in wrong accusation ;-) [09:38] pitti, right, which is the topic of my email, I just responded to the "let clutter out of the CD" bit, I totally agree with you otherwiwse [09:38] seb128, funnily enough, I just asked for a patch of the first one you mentioned, which fingers-crossed fixes it (will be in compiz release today), and the second two are the same bug with jason has been working on. I'll help him out today too [09:39] seb128: ah, ok; we violently agree then :) [09:40] njpatel, \o/ thanks [09:40] dear xchat, thanks for crashing [09:40] pitti: you mean completely removing mdadm.conf? [09:42] Sweetshark: well, renaming for now [09:43] so, now oneiric is nearly released, who wants to carry on running the firefox beta before they upgrade to precise (and help test the next security update)? [09:43] https://launchpad.net/~mozillateam/+archive/firefox-next [09:43] ;) [09:45] * pitti updates [09:46] chrisccoulson: oh, 8.0 already? [09:47] yeah, firefox version numbers increase every day now :) [09:47] pitti - yeah, that's the next release [09:47] chrisccoulson: this disables ubufox, known/intended? [09:47] pitti - yeah, that's known, but unintended [09:47] i've got a fix for that [09:47] chrisccoulson, your screens have different geometries? [09:47] njpatel, yeah, my secondary screen is slightly bigger [09:48] thanks [09:48] chrisccoulson: I now get an annoying "Extension-Update" dialog about test pilot [09:48] chrisccoulson: clicking "Update..." button doesn't do anything, and it keeps staying on all desktops [09:48] does it use gsettings for proxies yet? :-) [09:48] pitti - oh, i've not seen that [09:48] you could try disabling test pilot [09:48] i think people do that anyway ;) [09:48] chrisccoulson: the red "X" button on the top right works [09:49] pitti - yeah, the issue with it appearing on all desktops has been mentioned before [09:49] note that test pilot is only switched on in the beta and aurora builds [09:49] feel free to switch it off ;) [09:59] mvo: would you miss attach_gconf() much from source_update-manager.py? [09:59] mvo: u-m and gnome-power-manager seem to be the only two package hooks using it, and I just removed the g-p-m one in bzr [10:00] mvo: it uses the static "gconf" python module which will certainly mess up apport-gtk, and it's gsettings these days anyway [10:03] pitti: no, this needs updating to gconf anyway its outdated [10:03] pitti: no in the sense that I will not miss it [10:03] mvo: ok, thanks; I'll remove it and replace it with a no-op function, so that it doesn't immediately break hooks [10:06] pitti, we need an _gsettings() variant ;-) [10:06] seb128: bug 836489, working on it :) [10:06] Launchpad bug 836489 in apport "apport should have built-in support for gsettings hooks" [Medium,In progress] https://launchpad.net/bugs/836489 [10:07] pitti, \o/ ;-) [10:08] ok, I'm going to make friends :p [10:08] pitti: thanks [10:08] I'm suggesting on ubuntu-devel list that we stop getting stuff in universe and lock them to our freeze cycle but that we push packagers and upstreams to extra.ubuntu.com [10:08] let's see how much people will hate me :p [10:11] hm, is there any way to find out the system default of a gsettings key? [10:12] pitti, not that I know, but better to ask desrt [10:13] maybe there's a way to parse .config/dconf/user [10:15] oh, perhaps with g_settings_new_with_backend () [10:15] pitti, look to the dconf-editor source? [10:15] pitti, the non default value keys are bold in there [10:15] seb128: ah, right, that does get the default [10:15] pitti, so robert_ancell probably does it in some way [10:18] wendar: are you on very latest oneiric? several bugs of that sort got fixed last week [10:19] very latest, just updated [10:19] wendar: so, for the record, your screen gets completely turned off right after logging in, but only for your user account? [10:19] rodrigo_: ^ I just asked her to reset org.gnome.settings-daemon.plugins.power *, but that didn't help [10:20] yes, backlight turned off completely [10:20] has to be manually turned back on [10:20] how do you do this? with the brightness keys? [10:20] (through the keyboard brigtness key) [10:20] yes [10:20] what is the bug? [10:20] seb128, i agree with you btw (about extras.ubuntu.com) [10:20] ELACKCONTEXT [10:20] chrisccoulson, great ;-) [10:21] i have an upstream currently asking me to package their software in ubuntu, and i was going to direct them there instead ;) [10:21] well I wish the appreviewboard was functional [10:21] seb128: pitti and I just switched an ongoing conversation to the channel for more perspective [10:21] wendar: for bisecting, you could start with chmod 0'ing /usr/lib/gnome-settings-daemon-3.0/*power* and *xrandr*, and checking if that "fixes" it [10:21] let's see if they fix it if they get new people on board [10:21] wendar, pitti: could you describe the issue? [10:21] seb128: so, when I log in, my backlight turns off, and doesn't turn back on again [10:22] seb128: it used to do the same when I resumed from sleep, but resuming is fine now [10:22] seb128: so it's just login, and only on my installed user account, not on a guest account on a LiveCD [10:22] hum [10:24] why do we have shutdown actions listed under "Applications" in the dash? [10:24] http://www.omgubuntu.co.uk/2011/10/how-to-log-out-from-unity-dash/ [10:24] mpt? ^^ [10:24] pitti: do you want both the lib*.so and the *.gnome-settings-plugin versions of both? [10:24] wendar: can't hurt to just chmod both [10:24] chrisccoulson, lol, I have no idea [10:25] heh [10:25] chrisccoulson, mpt: ted figured people might want to search for shutdown and find it [10:25] pitti: brb [10:25] seb128, yeah, having actions in the dash might make sense. but it doesn't make sense that they are grouped with "Applications" [10:25] that's weird ;) [10:25] +1 [10:27] is there any way to get them listed but not in applications? [10:27] do we have any other category? [10:27] he added "System" to the category in http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk/revision/217 [10:27] seb128: bah -- dconf-editor parses the schemas [10:28] pitti, there is probably no other way... [10:28] pitti: that does it [10:28] pitti: both on relogin and reboot [10:28] wendar: can you now chmod 644 one, and see whether it's xrandr or power? [10:28] yup [10:30] Hmm ... Random question: Would it be theoretically practical for code in g-c-c to warn you that the language pack you're about to uninstall is being used by N user accounts? [10:31] wendar, pitti: sorry, just reading the backlog now... [10:32] mpt, yes, trivial [10:33] mpt: not very precisely, but should usually be correct [10:33] mpt, the "language" info is in the accountsservice dbus service, so it's easy to iterate through users looking for their language and match with the one you remove [10:33] wendar, hmm, chmod'ing those lib* files fixed the problem for you? [10:33] seb128: not all derivatives use accountsservice, though [10:33] pitti, those who don't use it don't use gnome-control-center [10:33] rodrigo_: just trying to bisect which plugin it was; I already had her reset the power gsettings [10:33]