| slowcon | hey guys. was wondering if there is a way to uninstall xorg without uninstalling lubuntu | 04:19 |
|---|---|---|
| slowcon | i saw some things online, but when i run them they all say they are going to remove desktop | 04:20 |
| slowcon | i got into root and that let me kill xorg so its not uploading anymore, but still havent removed it | 04:39 |
| RAOF | slowcon: You want a headless server? | 04:53 |
| pitti | Good morning | 04:55 |
| RAOF | Hey pitti! Good morning! | 05:01 |
| pitti | hey RAOF, how are you? | 05:09 |
| RAOF | I'm well. Your fine self?+ | 05:09 |
| pitti | RAOF: I'm good too, thanks; my cold is almost gone, and got some good night's sleep | 05:10 |
| pitti | had some really enjoyable Easter holidays :) | 05:10 |
| RAOF | :) | 05:10 |
| RAOF | Sounds like things are looking up! | 05:11 |
| slowcon | RAOF: sorrry, didnt see your reply. basically what happened is someone got onto my server and installed a bitcoin miner | 05:48 |
| slowcon | RA0F:trying to get it off | 05:48 |
| RAOF | slowcon: Urgh, sorry to hear that. | 05:48 |
| RAOF | slowcon: The only _safe_ way to proceed is to repave that server with a clean image; you can't really trust anything it says. | 05:49 |
| RAOF | slowcon: But Xorg is (probably) not the droid you're looking for. Xorg is the display server, which is required for any form of desktop. Which will be why lubuntu depends on it. | 05:50 |
| RAOF | (Unless your server's got UEFI secure boot enabled and enforced; in that case you can _probably_ trust a freshly-booted kernel) | 05:51 |
| slowcon | RAOF: ahhh damn, i had just got the firewall, novnc and everything setup | 05:55 |
| slowcon | RAOF: I have a cloud server, i asked if they had backups and they said they had snapshots, which "is like a backup" | 05:56 |
| slowcon | Vexxhost is the provider | 05:56 |
| slowcon | you think i should go that route? | 05:56 |
| RAOF | If you can restore a snapshot from before your server was compromised that would work. | 05:57 |
| RAOF | As long as you know *when* it was compromised :) | 05:57 |
| RAOF | This is sort of the point where what you do depends on your acceptable level of paranoia. | 05:58 |
| RAOF | If the attackers had root, they could do pretty arbitrarily bad things, including installing kernel mods that hide themselves and resist removal. But they probably *haven't* done that. | 05:59 |
| RAOF | But you can't really tell unless you go back to a known-good state. | 06:00 |
| mlankhorst | Hello, world!\n | 06:43 |
| mlankhorst | RAOF: yeah but I'm wondering what prevents you from patching the kernel and making it say secure boot is enabled? | 06:44 |
| RAOF | mlankhorst: You'd need to know that before the machine was compromised, of course. | 06:44 |
| mlankhorst | :s | 06:46 |
| RAOF | *If* your machine was enforcing secure boot (and the UEFI wasn't compromised), then a reboot should get you a known-good kernel, at least as-loaded-from-grub :) | 06:47 |
| mlankhorst | yeah but I don't trust bios vendors to get enforced secure boot right :P | 06:48 |
| slowcon | RAOF: is it possible for whoever got into my server to spoof all the times in the history? | 07:13 |
| RAOF | slowcon: This depends on where that history is stored. | 07:14 |
| RAOF | But the general rule is that nothing the attacker had access to is entirely trustworthy; ie: if you're reading logs off the disc, it's entirely possible they've been doctored. | 07:16 |
| slowcon | yeah he left a command in the clipboard that erased the history hahahaha | 07:17 |
| slowcon | RAOF: this is what was in the clipboard | 07:18 |
| slowcon | http://pastebin.com/4Krkfsex | 07:19 |
| RAOF | Heh. Sophisticated! :) | 07:21 |
| slowcon | -_- | 07:22 |
| slowcon | i dont know how to fix it hahaha | 07:22 |
| RAOF | Well, the way to be *sure* is to destroy that cloud server and create a new one from a fresh image. The way to be _mostly_ sure is to restore a previous snapshot that you're pretty sure pre-dates the attack. | 07:25 |
| === MacSlow is now known as MacSlow|errand | ||
| Laney | hey hey | 08:06 |
| seb128 | good morning desktopers | 08:06 |
| seb128 | Laney, hey, how are you? | 08:06 |
| pitti | hey Laney, bonjour seb128 | 08:06 |
| seb128 | pitti, hey, wie gehts? | 08:06 |
| pitti | seb128: gut, danke! und selbst? | 08:06 |
| seb128 | pitti, auch gut, danke! | 08:07 |
| Laney | hey seb128 | 08:07 |
| Laney | the blue skies have come back so i'm good! | 08:07 |
| Laney | guten morgen pitti | 08:07 |
| seb128 | same here | 08:07 |
| GunnarHj | seb128: Good morning! | 08:25 |
| seb128 | GunnarHj, hey | 08:25 |
| GunnarHj | seb128: Time for a licensing question? | 08:25 |
| seb128 | GunnarHj, you can ask, I'm not sure I'm the best person to ask about licenses though | 08:25 |
| seb128 | but others can reply on the channel as well if that's one I don't know about | 08:25 |
| GunnarHj | seb128: Ok, I ask: | 08:26 |
| GunnarHj | I'm about to create a package with Skype-translations which are not shipped with the Skype client: | 08:26 |
| GunnarHj | https://www.transifex.com/projects/p/skype-translation-project/ | 08:26 |
| GunnarHj | Wondering about the license. Currently I have this in debian/copyright: | 08:26 |
| GunnarHj | "Files: *.ts | 08:26 |
| GunnarHj | License: public-domain | 08:26 |
| GunnarHj | Collaborative work by community members; no natural copyright holder." | 08:26 |
| seb128 | GunnarHj, I've no idea how transifex is working, I guess projects pick their license there? but I don't find any indication on the page you pointed to | 08:29 |
| GunnarHj | seb128: I have really looked around, and haven't found anything about licenses. | 08:29 |
| GunnarHj | seb128: transifex seems to simply provide a tool for anyone to use... | 08:30 |
| === jhernand1z is now known as jhernandez | ||
| GunnarHj | seb128: Is there a 'license guru'? | 08:34 |
| seb128 | not really | 08:34 |
| seb128 | but no "guru" is going to be able to guess what licenses those datas are under if that's not specified on the website that provide them | 08:35 |
| GunnarHj | seb128: Right. And my conclusion was: public-domain. :) | 08:35 |
| seb128 | how can you conclude that when it's not specified? | 08:36 |
| seb128 | you should email whoever is listed as contact on the site imho | 08:36 |
| GunnarHj | seb128: Do you mean that those providing the site are the ones who should determine the license terms? Or are you talking about the groups of individuals for respective translation? | 08:39 |
| GunnarHj | seb128: I have a feeling that most people involved never gave it a thought. | 08:41 |
| seb128 | GunnarHj, well, whoever is handling the project | 08:42 |
| seb128 | but yeah, it's likely | 08:42 |
| GunnarHj | seb128: Ok, I'll give it a try. There is some forum or something, I think. | 08:43 |
| GunnarHj | seb128: Thanks for your comments! | 08:44 |
| seb128 | GunnarHj, yw! | 08:44 |
| NoNameYet_xnox | bug #1297969 | 10:17 |
| ubot2 | Launchpad bug 1297969 in ubuntu-push (Ubuntu Trusty) "Check cert" [High,In progress] https://launchpad.net/bugs/1297969 | 10:17 |
| seb128 | NoNameYet_xnox, wrong channel? | 10:19 |
| NoNameYet_xnox | seb128: testing bot, and on #ubuntu-devel it would probably wouldn't print the message as the repeat would be too soon =) | 10:20 |
| NoNameYet_xnox | seb128: and i choose to spam #ubuntu-desktop rather than using bot's PM inteface ;-) | 10:21 |
| seb128 | NoNameYet_xnox, I see ;-) | 10:25 |
| === alan_g is now known as alan_g|afk | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === alan_g|afk is now known as alan_g | ||
| andyrock | seb128, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1311344 and https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1311617 | 11:59 |
| ubot2 | Launchpad bug 1311344 in Unity "lock screen password not recognised after wake from sleep (may be related to sticky keys)" [Medium,Confirmed] | 11:59 |
| ubot2 | Launchpad bug 1311617 in lightdm (Ubuntu) "After suspending, shift key is stuck down" [Undecided,New] | 11:59 |
| seb128 | hey andyrock | 12:00 |
| andyrock | are the same bugs | 12:00 |
| === alan_g is now known as alan_g|lunch | ||
| andyrock | *bug | 12:00 |
| seb128 | could be | 12:00 |
| seb128 | did you confirm it? | 12:00 |
| andyrock | yes | 12:00 |
| andyrock | because if i print the password using printf | 12:00 |
| andyrock | it appears in uppercase | 12:01 |
| andyrock | not sure it's unity fault | 12:01 |
| andyrock | and not sure it's lightdm's fault | 12:01 |
| andyrock | any idea which pkg we should target it to? | 12:01 |
| seb128 | is the issue the "sticky keys" ... is the input uppercase in the session as well? | 12:04 |
| andyrock | let me try to disable the lockscreen so I can test it | 12:04 |
| andyrock | yep the bug happens in the sessions as well | 12:09 |
| seb128 | k, so probably an unity-settings-daemon issue | 12:09 |
| seb128 | can you reassign there and maybe add a description of the issue | 12:10 |
| seb128 | is the uppercase happening only after suspend/resume? | 12:10 |
| andyrock | seb128, yeah... it can only reproduce after s/r | 12:10 |
| ochosi | hey seb128 | 12:29 |
| ochosi | (and everyone else) | 12:29 |
| seb128 | ochosi, hey, how are you? | 12:29 |
| ochosi | good good :) | 12:29 |
| ochosi | still suffering from a bit of post-release-tiredness | 12:29 |
| ochosi | but the easter-holidays helped | 12:29 |
| ochosi | how | 12:29 |
| ochosi | 're things with you? | 12:29 |
| seb128 | things are pretty good, it was nice to have a long w.e indeed! | 12:30 |
| ochosi | :) | 12:30 |
| seb128 | looking at what needs to be SRUed now, based on the release feedback | 12:30 |
| ochosi | yeah, we also have a few locking problems like you | 12:30 |
| ochosi | actually i have a bug that was assigned to light-locker, but it's actually the | 12:30 |
| ochosi | unity lockscreen | 12:31 |
| ochosi | what would i assign it to? | 12:31 |
| ochosi | https://bugs.launchpad.net/ubuntu/+bug/1311036 | 12:31 |
| ubot2 | Launchpad bug 1311036 in Ubuntu "unlock keystrokes sent to virtual-box session" [Undecided,New] | 12:31 |
| seb128 | unity | 12:31 |
| ochosi | (fwiw, i think this is the known issue) | 12:31 |
| seb128 | the one where something has a grab when the lock screen happens? | 12:31 |
| seb128 | bug #1305586 | 12:32 |
| ubot2 | Launchpad bug 1305586 in Unity "Lock screen is unusable when a password dialog has a keyboard/mouse grab" [High,Triaged] https://launchpad.net/bugs/1305586 | 12:32 |
| ochosi | i could at least imagine, yes | 12:32 |
| ochosi | just a different app/window that has the grab | 12:32 |
| seb128 | could be indeed | 12:32 |
| === alan_g|lunch is now known as alan_g | ||
| GunnarHj | seb128: We guessed right; they hadn't thought about it. | 12:45 |
| GunnarHj | https://www.transifex.com/projects/p/skype-translation-project/announcement/43361/ | 12:45 |
| seb128 | GunnarHj, I don't have the permissions to see that url | 12:45 |
| GunnarHj | seb128: Aha... | 12:46 |
| === MacSlow|lunch is now known as MacSlow | ||
| NoNameYet_xnox | GunnarHj: paste a screenshot, please =) | 12:46 |
| GunnarHj | NoNameYet_xnox: Right.. | 12:46 |
| * mvo is away for a bit | 12:52 | |
| GunnarHj | seb128: I asked the admin of the Skype translation project at transifex about licenses, and he made this announcement: | 12:57 |
| GunnarHj | http://people.ubuntu.com/~gunnarhj/transifex-licenses.png | 12:57 |
| seb128 | GunnarHj, k, good that you asked then ;-) | 12:59 |
| NoNameYet_xnox | GunnarHj: yeah, it should be permissive MIT/BSD/Apache2.0 otherwise it's pointless. | 12:59 |
| NoNameYet_xnox | GunnarHj: launchpad uses 3-clause bsd https://help.launchpad.net/Translations/LicensingFAQ so you could recommend that. | 12:59 |
| GunnarHj | NoNameYet_xnox: Thanks for the tip! Will do. | 13:00 |
| mpt | I can reliably hang Compiz by clicking on an iPhone in the Unity launcher. That is strange. | 13:29 |
| seb128 | indeed | 13:30 |
| seb128 | it just hangs? | 13:30 |
| seb128 | or does it segfault (with apport keeping it hanging while it's dealing with the report) | 13:30 |
| mpt | seb128, every window stops responding to clicks until I kill -9 the compiz process | 13:33 |
| seb128 | mpt, is apport running when that happens? | 13:34 |
| seb128 | e.g what is in top | 13:34 |
| mpt | good question, I’ll look | 13:34 |
| mpt | seb128, no, apport is not running — it really is a hang, not a crash | 13:36 |
| seb128 | weird | 13:36 |
| seb128 | can you get a stacktrace of compiz will it's hanging? | 13:36 |
| seb128 | you can kill -11 it and let apport get the bt | 13:37 |
| seb128 | or use gdb yourself directly | 13:37 |
| mpt | ok | 13:39 |
| mpt | “Sorry, the application apport-retrace has stopped unexpectedly.” \o/ | 13:43 |
| mpt | seb128, I attached the stacktrace to bug 1311663 | 13:45 |
| ubot2 | Launchpad bug 1311663 in compiz (Ubuntu) "Clicking iPhone in Launcher hangs Compiz" [Undecided,New] https://launchpad.net/bugs/1311663 | 13:45 |
| seb128 | mpt, thanks | 13:45 |
| davmor2 | kenvandine: Friends app should scrolling in the app really be using 70% of the cpu? | 13:48 |
| kenvandine | davmor2, no... it really shouldn't | 13:49 |
| kenvandine | but lots of stuff has changed in that listview, i haven't looked at it lately | 13:49 |
| seb128 | mpt, that seems another of those bugs where a sync call to gvfs hangs for whatever reason :/ | 13:50 |
| kenvandine | davmor2, on the desktop or device? | 13:50 |
| davmor2 | kenvandine: I was looking on my pc let me try the device | 13:51 |
| mpt | seb128, so it’s two bugs? First that gvfs shouldn’t hang, and second that Compiz shouldn’t hang when gvfs does | 13:51 |
| seb128 | mpt, I guess we can say that yes | 13:52 |
| davmor2 | kenvandine: 102.2% on device | 13:53 |
| kenvandine | yikes | 13:53 |
| kenvandine | davmor2, file a bug, that needs some profiling done and optimizing | 13:53 |
| davmor2 | kenvandine: wilko | 13:53 |
| kenvandine | thx | 13:53 |
| ogra_ | use a bucket to catch these extra percents in case they drip out of the case | 13:53 |
| kenvandine | :) | 13:54 |
| kenvandine | i love that crazy math | 13:54 |
| ogra_ | heh, yeah | 13:54 |
| davmor2 | kenvandine: https://bugs.launchpad.net/ubuntu/+source/friends-app/+bug/1311674 | 13:58 |
| ubot2 | Launchpad bug 1311674 in friends-app (Ubuntu) "Friends-app uses 70% on pc and 102.2% on mako scrolling list view" [Undecided,New] | 13:58 |
| mpt | And now report a bug in ubot2 | 13:59 |
| mpt | for misparsing that bug summary | 13:59 |
| davmor2 | mpt: how did it? | 14:01 |
| mpt | Oh, turns out it’s actually a bug in my graphics driver, never mind :) | 14:01 |
| kenvandine | haha | 14:04 |
| kenvandine | another bug to file | 14:04 |
| davmor2 | mpt: of course bug number 1 is the iphone ;) | 14:05 |
| NoNameYet_xnox | lol =) | 14:07 |
| mlankhorst | gah found another bug while switching :P | 14:18 |
| ogra_ | dont switch ! | 14:19 |
| mpt | “Doctor it hurts when I do this” | 14:24 |
| ogra_ | :) | 14:24 |
| mlankhorst | what's missing from the joke is that the patient's complaining about a broken arm | 14:28 |
| mlankhorst | :p | 14:28 |
| BigWhale | Greetings. | 15:05 |
| BigWhale | Is it possible to bump version of python3-cairo in the next 14.04 update? Who should I bug about this? seb128? :) | 15:07 |
| Laney | What for? | 15:08 |
| BigWhale | Laney, version 1.10.0 which is included now, is three years old and is missing few things that future version of Kazam will be using. | 15:09 |
| BigWhale | I could provide it in a PPA, but this is really something that every python developer dealing with cairo would benefit from. | 15:10 |
| Laney | BigWhale: 14.04 is released now and so it can only accept bug fixes | 15:11 |
| Laney | Providing it in U and then in trusty-backports is an option if someone's willing to test the packages which depend on python3-cairo keep on working with the new one | 15:11 |
| BigWhale | Laney, from my point of view, those are bug fixes, certain things were broken in python implementation and are fixed in 1.10.1. | 15:17 |
| Laney | BigWhale: Check the stable update criteria https://wiki.ubuntu.com/StableReleaseUpdates#When | 15:22 |
| Laney | If you think each of the fixes (I can't check as I cannot find this 1.10.1 release) meet the definition then feel free to follow the procedure | 15:22 |
| BigWhale | Laney, I'll look at the changes later today. I didn't have the chance to do so. | 15:23 |
| Laney | It's also an option to cherry-pick only some of them | 15:24 |
| === gatox is now known as gatox_lunch | ||
| MacSlow | commit 75e82a1b3f495a3abbc78e50a5c66356d320fb15, commit 2f9e604ac7bb5f6386179a3d0fad6f095c386f66 | 15:32 |
| MacSlow | these two commits after pycairo's 1.10.0 provide ImageSurface.create_for_data() and cairo_region_t which should be enough... | 15:33 |
| MacSlow | make those into distro-patches and we might have an easier time getting those into 14.04 LTS | 15:33 |
| Laney | I can help upload if you like, can't promise the SRU team will accept that though | 15:40 |
| Laney | Doesn't really sound like it fixes bugs | 15:40 |
| Laney | And arguing that 'misses an important feature' is a bug doesn't fly | 15:40 |
| Laney | But you never know | 15:40 |
| Trevinho | seb128, Laney: about that grab issue for password fields, indeed unity must be fixed, to handle these cases better, but imho there we should still disable the grabs in libgcr by default. Grabs are just bad. | 15:42 |
| Trevinho | not to mention that for some reason that client doesn't inform the xserver that a grab has just been done | 15:44 |
| seb128 | Trevinho, that sounds like a loosing strategy, similar issues have been reported with e.g virtualbox | 16:18 |
| seb128 | Trevinho, you can't make sure users are never going to have something doing grabs, the safe way is to just handle those case better in unity | 16:18 |
| seb128 | BigWhale, MacSlow, Laney: wrapping functions that were missing seems like something that could be SRUed in a LTS imho | 16:19 |
| Laney | shrug | 16:19 |
| seb128 | but I'm not in the SRU team | 16:19 |
| Laney | It's not my call | 16:19 |
| MacSlow | seb128, that would be very cool | 16:19 |
| seb128 | Laney, you seem to disagree with the principle though? | 16:20 |
| Laney | not really | 16:20 |
| seb128 | k, I misread the "shrug" then ;-) | 16:20 |
| Laney | But it doesn't really fit with the criteria | 16:20 |
| Laney | so I don't want to say it's a good idea when I have no idea if it's the kind of thing that gets accepted | 16:20 |
| seb128 | yeah, I think it's worth trying to get in if they are useful | 16:20 |
| seb128 | we want the LTS to be a solid platform for devs | 16:21 |
| Trevinho | seb128: no, that was not my idea of fixing it... Grabs should be handled better compiz/unity side... But I also think that we should get rid of that grab | 16:21 |
| MacSlow | seb128, Laney: in this particular case it doesn't really add functionality, but fixes the implementation | 16:21 |
| seb128 | MacSlow, hum, does it change api? wrapping things that were missing is one thing, changing an existant implementation another | 16:21 |
| seb128 | MacSlow, like by wrapping new thing you can't create issues for existing clients so that's fine | 16:22 |
| MacSlow | seb128, no it does not | 16:22 |
| seb128 | MacSlow, changing an existing implementation seems more risky | 16:22 |
| MacSlow | seb128, it corrects the exposure of cairo_region_t and cairo_image_surface_create_for_data() | 16:23 |
| MacSlow | in pycairo | 16:23 |
| seb128 | MacSlow, "corrects", like they were implemented with a wrong api and it fixes that? | 16:23 |
| Laney | Trevinho: why? | 16:24 |
| seb128 | MacSlow, which would create issues for clients relying on the incorrect implementation? | 16:24 |
| MacSlow | seb128, no... api stays the same... it just works after those patches | 16:24 |
| seb128 | k | 16:24 |
| MacSlow | seb128, it didn't work at all before :) | 16:24 |
| seb128 | well, as long as it can't create bugs for existing clients which were relying on the buggy api/using it a way that worked and would stop working | 16:24 |
| seb128 | k | 16:24 |
| Trevinho | Laney: because grabs are just bad and goes against all the design we have... We always tried to remove grabs everywhere around | 16:24 |
| Laney | I've not heard of that | 16:25 |
| seb128 | Laney, I think our design has been in favor of password prompts being "normal dialog" | 16:26 |
| seb128 | in opposition to what e.g gnome-shell is doing (or gksu used to do) | 16:26 |
| seb128 | which is like dim the whole screen and force the password prompt | 16:26 |
| Laney | that's not the same as a grab though | 16:26 |
| MacSlow | seb128, I understand the concern, but can't image how those fixes could affect existing clients using pycairo 1.10.0 (from 14.04 LTS) | 16:26 |
| seb128 | MacSlow, k, good, you guys should open a bug with the commits to backport listed and ask for sponsoring | 16:27 |
| Trevinho | the ibky grabs we've around are there only for X limitations, although i've just seen that using Xi2 could give us the ability of removing many of them | 16:27 |
| MacSlow | BigWhale, ^ see seb128's comment | 16:27 |
| seb128 | Laney, Trevinho: what do we call "grab" there? the polkit dialog force foreground but don't lock input | 16:27 |
| seb128 | I wouldn't object to have polkit and keyring having a consistent behaviour | 16:28 |
| seb128 | not sure which one is the more correct one though | 16:28 |
| Laney | Doesn't let you type elsewhere | 16:28 |
| Trevinho | seb128: https://github.com/GNOME/gcr/blob/master/ui/gcr-prompt-dialog.c#L626 | 16:28 |
| === gatox_lunch is now known as gatox | ||
| seb128 | mdeslaur, hey, do you know if the security team has an opinion on whether e.g gnome-keyring password dialogs should have a keyboard grab? | 16:33 |
| Trevinho | seb128: at least not in unity-env... | 16:33 |
| mdeslaur | seb128: hrm, not off the top of my head | 16:35 |
| mdeslaur | seb128: perhaps it's an artifact from when they used to make the whole screen inactive? | 16:35 |
| mdeslaur | or maybe there's another reason I'm not thinking of at the moment | 16:35 |
| Laney | I'm not sure I can think enough about the subject atm to have a good opinion | 16:36 |
| Laney | it's not necessary to fix this now anyway as Unity needs to be fixed anyway | 16:36 |
| Laney | is this something that'd be different across desktops? not sure about that... | 16:37 |
| mdeslaur | The one thing I do know, is the screen lock needs to get the grab, and needs to abort if it can't get it ie: a gtk menu is open | 16:37 |
| Laney | yes | 16:37 |
| Trevinho | Laney: unity needs a fix, but that lib is wrong anyway... | 16:37 |
| Laney | I don't know | 16:37 |
| mdeslaur | If unity does abord because it can't get the grab, it would be nice to print out an error to the log file, so when people file bugs that they're screen didn't lock, we know why | 16:38 |
| mdeslaur | IMHO | 16:38 |
| seb128 | right | 16:38 |
| Laney | But concentrating on this one prompt is a bit of a distraction | 16:38 |
| seb128 | Laney, well, I know I hate the passwords with grabs like the keyring ones | 16:38 |
| Laney | okay... | 16:38 |
| seb128 | I had cases where keyring had a password open on another screen | 16:38 |
| seb128 | which was off | 16:38 |
| seb128 | and I could click and open stuff on my primary screen | 16:39 |
| seb128 | but not type anything | 16:39 |
| seb128 | I even plugged another keyboard once :p | 16:39 |
| seb128 | before realizing something somewhere was having a grab | 16:39 |
| Laney | I believe there are weird cases | 16:39 |
| mdeslaur | hrm, perhaps they try to grab the keyboard to simply be sure nothing _else_ is grabbing the keyboard | 16:40 |
| seb128 | well in any case polkit prompt don't seem to grab (just tried with unlock in the user settings) | 16:40 |
| seb128 | so we have an inconsistant behaviour | 16:40 |
| Laney | sure | 16:40 |
| Laney | I get why you might want to do it, because then you are sure (as you can be) the password isn't going anywhere else | 16:40 |
| seb128 | but yeah, nothing major there | 16:40 |
| seb128 | let's start by fixing unity | 16:40 |
| Laney | I don't think it's as simple as "this grab is wrong, let's get rid of it" | 16:41 |
| Laney | it's a conversation to be had upstream imho | 16:41 |
| seb128 | we had it | 16:41 |
| Trevinho | the problem with that dialog is that it grabs *before* being mapped and that makes compiz crazy... So while I've found a solution for compiz, that dialog should do that after mapping it | 16:41 |
| seb128 | Laney, I think mpt and GNOME upstream were in disagreement on the design | 16:42 |
| seb128 | upstream GNOME think that the password prompt should be the only thing on screen | 16:42 |
| seb128 | (that's what they did, they dim the bg and display only that) | 16:42 |
| seb128 | I think to remember that mpt was more on the opinion that password dialogs should be normal dialogs | 16:42 |
| seb128 | mpt, let me know if I remember wrongly | 16:42 |
| mdeslaur | seb128: that sounds accurate, yes | 16:43 |
| seb128 | our current implementation is a bit in between (which sucks) | 16:43 |
| seb128 | we do grab for e.g keyring, but we don't display it a visible way | 16:43 |
| seb128 | which leads to the possible confusing scenario I described a bit earlir | 16:43 |
| seb128 | earlier | 16:43 |
| Laney | well, I get why you do want them, that's all I'm saying | 16:44 |
| Laney | I don't want to accidentally type my gpg passphrase into irc | 16:44 |
| seb128 | Laney, right, but if that's a real concern we should have it for polkit prompt as well, because you don't want to type your user password here either | 16:51 |
| Laney | I guess so | 16:51 |
| Laney | I've just never noticed before | 16:52 |
| === tkamppeter_ is now known as tkamppeter | ||
| === ChrisTownsend1 is now known as ChrisTownsend | ||
| === m_conley_away is now known as m_conley | ||
| === bschaefer_ is now known as bschaefer | ||
| MikeRL | https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1311847?comments=all | 21:32 |
| ubot2 | Launchpad bug 1311847 in unity-settings-daemon (Ubuntu) "Neither Print, SHIFT+Print, nor CTRL+Print keyboard shortcuts work on Trusty" [Undecided,New] | 21:32 |
| MikeRL | I filed this bug, but I need someone who can help tell me if there's a better package to classify it under. | 21:33 |
| === sarnold_ is now known as sarnold | ||
| === NoNameYet_xnox is now known as xnox | ||
| helder | hi there | 22:53 |
| === m_conley is now known as m_conley_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
