| didrocks | good morning | 06:17 |
|---|---|---|
| desrt | didrocks: good morning! | 06:40 |
| seb128 | good morning desktopers | 06:43 |
| didrocks | waow desrt! still working? :) | 06:45 |
| didrocks | salut seb128 | 06:45 |
| seb128 | lut didrocks | 06:46 |
| desrt | didrocks: gvariant hacking for fun and profit | 06:51 |
| Sweet5hark | moin! | 06:58 |
| seb128 | hey Sweet5hark | 07:09 |
| pitti | Good morning | 07:37 |
| didrocks | hey pitti! | 07:43 |
| * pitti ^5s didrocks, I just G+ed about you :) | 07:43 | |
| didrocks | pitti: it fixes the kde thingy as well :) | 07:43 |
| * didrocks ^5s back :) | 07:43 | |
| pitti | didrocks: oh, does it? I didn't see his response yet, just your "it should fix" | 07:43 |
| pitti | (it's very likely, though) | 07:43 |
| didrocks | pitti: he answered since | 07:45 |
| didrocks | pitti: my best bet was that /etc wasn't mounted yet | 07:45 |
| pitti | didrocks: ah, I guess the CC: is slower then | 07:45 |
| pitti | didrocks: ah, got it now; do you want to do the duplication/merging dance, or shall I? | 07:46 |
| didrocks | pitti: you are a better bts than I am :) | 07:48 |
| didrocks | master* | 07:48 |
| didrocks | Sweet5hark: funny, I know 2 of the frenchies from https://plus.google.com/101094190333184858950/posts/TtqsYd4wBC1 (they do live in Paris, didn't know they moved to Toulouse for the hackfest) :) | 07:48 |
| pitti | didrocks: done | 07:49 |
| didrocks | pitti: thanks :) | 07:50 |
| Sweet5hark | didrocks: the liberte0 guys? | 07:50 |
| didrocks | Sweet5hark: yep, my wife is sometimes contracting with them as well (doing design) | 07:51 |
| didrocks | well s/design/visual assets/ | 07:51 |
| Sweet5hark | didrocks: yeah, they were interested in a11y for LibreOffice. Interesting discussion there ... | 07:53 |
| seb128 | hey pitti, wie gehts? | 07:55 |
| pitti | seb128: gut, danke! ein bisschen muede, ich bin zu spaet ins Bett gegangen | 07:57 |
| darkxst | hey seb128 | 08:03 |
| darkxst | icon scaling needs to be fixed in the apps | 08:03 |
| seb128 | hey, I had a feeling that was coming | 08:04 |
| seb128 | doesn't seem an acceptable solution though | 08:04 |
| seb128 | "let's change gtk in an incompatible way and declare that all the apps need fixing" | 08:04 |
| darkxst | seb128, gtk no longer scales icons if they are outside limits set in icon theme | 08:04 |
| darkxst | mostly it should be as simple as setting GTK_ICON_LOOKUP_FORCE_SIZE flag when getting the icon info | 08:06 |
| pitti | oh, is that a blocker for updateing gtk to 3.14? | 08:06 |
| pitti | I noticed that http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is full of auto-imported GNOME stuff which waits for gtk 3.14 | 08:06 |
| darkxst | nautilus is a little more complicated though since its using deprecated GtkActions to generate context menu | 08:06 |
| darkxst | but I will file a bug upstream for that | 08:07 |
| seb128 | thanks | 08:08 |
| seb128 | larsu was looking at those issues yesterday and discussed them on #gtk+ | 08:08 |
| ari-tczew | pitti: not only auto-imported, of merged as well | 08:08 |
| seb128 | pitti, yes, it's one of the blockers | 08:08 |
| seb128 | pitti, see http://pad.ubuntu.com/gtk-update-v | 08:09 |
| seb128 | darkxst, that still seems a behaviour change from gtk and buggy and wrong | 08:09 |
| darkxst | seb128, https://bugzilla.gnome.org/show_bug.cgi?id=738467 | 08:11 |
| ubot5 | Gnome bug 738467 in general "Some icons are enormously large" [Normal,Resolved: fixed] | 08:11 |
| seb128 | darkxst, that's not a fix though... | 08:12 |
| seb128 | I wonder if we could revert the behaviour change in gtk | 08:13 |
| darkxst | seb128, how many things are broken? | 08:13 |
| seb128 | dunno, we would need to run every single gtk rdepends in the archive and look at every icon in their ui to be able to tell | 08:14 |
| darkxst | most of the GNOME things are fixed it seems except nautilus | 08:14 |
| seb128 | on a default unity desktop, at least several indicators and nautilus | 08:14 |
| seb128 | yeah | 08:14 |
| seb128 | oh, the unity dash is having issues as well | 08:15 |
| seb128 | but as usual, GNOME apps are the most likely to be fine | 08:15 |
| seb128 | but they are like 1% of the gtk users | 08:15 |
| seb128 | so they give a false summary | 08:15 |
| seb128 | gtk users->apps using gtk | 08:15 |
| seb128 | there are probably a lot more buggy code in !GNOME, since those don't benefit of GTK hackers fixing them as they do incompatible changes | 08:16 |
| darkxst | seb128, yes, probably | 08:17 |
| darkxst | I don't suppose there is any real harm in reverting that patch, though I haven't looked for it so far | 08:18 |
| darkxst | gtg be back in half an hour or so | 08:18 |
| seb128 | ttyl | 08:18 |
| didrocks | pitti: on empty machine-id, I think I can create some shell script and playing with setup-machine-id/commit | 08:25 |
| didrocks | with a bunch of bind mounts | 08:25 |
| mlankhorst | morning | 08:38 |
| seb128 | hey mlankhorst | 08:39 |
| mlankhorst | hey :) | 08:39 |
| didrocks | morning mlankhorst | 08:40 |
| mlankhorst | didrocks: do you know how compiz determines screen size? I'm trying to handle compiz inside Xmir inside u8, and I'm getting a resize event from u8 after creating a surface, need to pass that on to compiz somehow.. | 08:42 |
| didrocks | mlankhorst: last time I checked, it was using some xrandr-like functions, but that may have changed | 08:42 |
| didrocks | mlankhorst: not sure there is an API to force that (apart from developping a compiz plugin of course :p) | 08:43 |
| larsu | darkxst: it can't be fixed in the apps in many cases (for example menus) | 08:52 |
| pitti | didrocks: or in nspawn perhaps | 08:52 |
| pitti | didrocks: although the current nspawn test is rather simple, it just sets up a tiny busybox file system | 08:53 |
| didrocks | pitti: so, it means that I would run a debootstrap as part of the autopkgtests? Won't we have $random failures? | 08:54 |
| didrocks | (happens that debootstrap fails) | 08:54 |
| pitti | didrocks: nah, I think that's too much effort | 08:54 |
| mlankhorst | didrocks: yeah I will probably just create a 'windowed' xrandr mode which changes names every time a resize event happens | 08:55 |
| pitti | didrocks: we do debootstrap in the sbuild and lxc autopkgtests, but they always take a while | 08:55 |
| didrocks | pitti: I would nspawn on what then? it needs a chroot, right? | 08:55 |
| pitti | didrocks: so I suppose setting up some bind mounts and running the unit right in the actual testbed will be better (note that you can reboot) | 08:55 |
| didrocks | mlankhorst: yeah, that shuld work :) | 08:55 |
| didrocks | pitti: ah, so no nspawn then | 08:56 |
| pitti | didrocks: i. e. you could just remove /etc/machine-id, reboot, and see if it comes back properly | 08:56 |
| pitti | didrocks: (that one should have a "Restrictions: breaks-testbed" :) ) | 08:57 |
| didrocks | pitti: TBH, I like your nspawn idea, not sure how we can just download a ready chroot. That way, we can have a lot of integration tests | 08:57 |
| pitti | didrocks: anyway, only if you are interested in this | 08:57 |
| pitti | didrocks: you could download ubuntu core perhaps, or the daily LXC builds | 08:57 |
| didrocks | pitti: maybe it's something worth digging for future tests, wdyt? (would be then easy to create broken state, ensure they are still working with newer versions…) | 08:58 |
| pitti | didrocks: i. e. http://cdimage.ubuntu.com/ubuntu-core/daily/current/; they don't have systemd, so they need an apt-get install systemd-sysv call; I haven't tried that | 08:58 |
| pitti | didrocks: for now the tests work right on the testbed itself | 08:59 |
| pitti | (except for nspawn, of course) | 08:59 |
| willcooke | g'mornin | 08:59 |
| didrocks | yeah, but we never tried to break the testbed, did we? | 08:59 |
| didrocks | pitti: in case it's not coming back? | 08:59 |
| didrocks | hey willcooke | 08:59 |
| pitti | didrocks: then the timeout will hit and the test will fail | 08:59 |
| didrocks | pitti: and a new vanilla testbed will then run other tests? | 09:00 |
| pitti | didrocks: qemu's reboot hook has a timeout of 5 minutes | 09:00 |
| didrocks | pitti: ok, so each tests are running on its own testbed, tests are isolated? (I guess, by script) | 09:01 |
| pitti | didrocks: anyway, this is low-prio; I think I want a test for the DM generators much more badly | 09:01 |
| pitti | didrocks: yes, adt-run takes care of that | 09:01 |
| didrocks | ok, so yeah, little need for nspawn | 09:02 |
| didrocks | pitti: I need to find an example, but yeah, will do that | 09:02 |
| pitti | didrocks: do you have an idea how the generators can be tested efficiently? | 09:02 |
| pitti | didrocks: i. e. is there something faster than rebooting the VM each time for each test? | 09:03 |
| pitti | (although it's not *that* bad -- it takes maybe 10 seconds) | 09:03 |
| larsu | seb128: this is one of those times where I think we should deviate from the xdg spec | 09:03 |
| didrocks | pitti: I guess there is a bug in "systemctl status" that I observed (status not matching the reality). I needs fixing, but clearly that means if we only use status, we are unsure about the reboot statuts | 09:03 |
| larsu | seb128: it's just really bad and never what you want | 09:03 |
| didrocks | pitti: TBH, I would prefer the end-to-end user experience, meaning: choosing in debconf/postinst | 09:04 |
| didrocks | reboot | 09:04 |
| pitti | didrocks: sure, that sounds good as well | 09:04 |
| didrocks | and then, check which dm has been restarted | 09:04 |
| didrocks | it's slower, but we know we test what users will have | 09:04 |
| pitti | yeah, right | 09:04 |
| didrocks | pitti: apart from prefiling debconf to choose which dm to choose, is there any other tests to manipulate postinst prompts? (I want to follow the general best practices) | 09:05 |
| pitti | didrocks: I'm not aware of an existing autopkgtest which does that | 09:05 |
| didrocks | something to pioneer then :) | 09:06 |
| seb128 | larsu, yeah, | 09:07 |
| seb128 | larsu, how did the discussion on #gtk+ go? was there anything more (I did read on the afternoon) | 09:07 |
| larsu | seb128: nah. Alex says the spec is the soec | 09:08 |
| larsu | *spec | 09:08 |
| larsu | I'll ask mclasen again today, he made the change | 09:09 |
| seb128 | k | 09:09 |
| seb128 | I'm pondering just distro reverting otherwise | 09:09 |
| seb128 | at least to give some times for apps to be fixed | 09:09 |
| seb128 | same as the wrapping one | 09:09 |
| seb128 | GTK does things in a stupid way by not giving some transition time | 09:09 |
| seb128 | it's "oh, btw, that stopped working, you better fix your code because your app is buggy" | 09:09 |
| larsu | well, we have transition time now that we're one cycle behind | 09:10 |
| larsu | but yeah.. | 09:10 |
| larsu | I don't even know why he made the change... | 09:10 |
| larsu | the real problem is that he didn't fix the occurences in gtk istelf (like menus) | 09:11 |
| seb128 | is that what bites us on indicators? | 09:11 |
| darkxst | larsu, hmm right, I Guess menu icons are deprecated these days also | 09:12 |
| darkxst | and such code paths will be problematic at best | 09:13 |
| larsu | darkxst: no, they're not | 09:14 |
| larsu | what do you mean by "problematic"? | 09:15 |
| larsu | seb128: yes, you only supply an icon name in gmenu, and gtkmodelmenuitem puts the icon there | 09:15 |
| larsu | seb128: there's no way to pass "force-size" there. And in fact, there's not even for gtkmodelmenuitem, becasue gtkimage doesn't support the flag | 09:15 |
| larsu | (this is Alex' proposed way of fixing this...) | 09:16 |
| darkxst | larsu, maybe I am confusing the menus show icon setting | 09:17 |
| darkxst | larsu, problematic, to fix apps that are calling into gtk (like nautilus with gtkaction's) | 09:17 |
| darkxst | gio has no knowledge of icon sizing | 09:18 |
| larsu | darkxst: of course it doesn't, it doesn't load any icons... | 09:20 |
| larsu | darkxst: right, that's what I mean. If it's changed it in gtk, *at least* also change the usage in gtk itself | 09:21 |
| darkxst | gio basically passes through a filename for the icon then nautilus stuffs that into a gtkaction, but I doubt anyone is going to fix deprecated code | 09:22 |
| larsu | what exactly is the problem in nautilus? | 09:24 |
| larsu | didn't someone port it to GAction already? | 09:25 |
| larsu | if nautilus has problems, someone will fix the code | 09:25 |
| darkxst | larsu, open with menu get huge icons for gvim atleast | 09:26 |
| larsu | haha, this is awesome :) | 09:27 |
| larsu | takes the whole screen... | 09:27 |
| darkxst | yeh its pretty big! | 09:33 |
| === shiznix_ is now known as shiznix | ||
| Saviq | hey guys, question... when I've an external screen connected, my laptop won't suspend when I close the lid, but disconnect the internal screen instead (like the internal screen actually goes away) | 10:32 |
| Saviq | any idea if this is caused by hw or something? | 10:33 |
| seb128 | Saviq, no idea, you could try to stop unity-settings-daemon and see if it does it too, but I guess in that case it's going to suspend on lid close... | 10:35 |
| Saviq | seb128, yeah so it doesn't seem to be hw, the screen just gets disabled in the settings | 10:36 |
| seb128 | that would be weird | 10:36 |
| seb128 | I guess you could stop unity-settings-daemon and put a suspend inhibitor another way | 10:37 |
| seb128 | and close the lid | 10:37 |
| seb128 | and see what happens | 10:37 |
| Saviq | seb128, nothing | 10:38 |
| seb128 | shrug | 10:38 |
| Saviq | at least now I know what to file the bug with | 10:38 |
| seb128 | u-s-d? | 10:38 |
| seb128 | maybe try to run it with --debug and provide the log of what happens when you close the lid | 10:39 |
| seb128 | that doesn't make much sense to me of why it would remove the screen and how | 10:39 |
| Saviq | seb128, yeah, I was almost sure it was a suspend issue | 10:39 |
| Saviq | seb128, but then I disconnected the screen and picked up the laptop and it suspended fine | 10:40 |
| Saviq | and then I noticed that the external screen actually gets all of my windows | 10:40 |
| seb128 | is the screen coming back when you reopen the lid? | 10:40 |
| Saviq | yeah | 10:40 |
| seb128 | where is the bug then? | 10:40 |
| seb128 | if you close the lid that screen is virtually missing | 10:40 |
| seb128 | so removing it seems right | 10:40 |
| willcooke | Windows has(had) an option where if you closed the lid and the machine was connected to power and an external screen then the internal screen would disappear and you'd be left with a single desktop on the external screen | 10:40 |
| willcooke | I wonder if this might be a BIOS thing for that? | 10:40 |
| willcooke | Saviq, you've got a Dell? | 10:41 |
| Saviq | willcooke, yes | 10:41 |
| Saviq | XPS12 | 10:41 |
| willcooke | Saviq, dual graphics cards? | 10:43 |
| Saviq | willcooke, no | 10:43 |
| willcooke | hrm | 10:49 |
| Saviq | bug #1398771 then | 10:52 |
| ubot5 | bug 1398771 in unity-settings-daemon (Ubuntu) "External screen turned off instead of suspending on lid close" [Undecided,New] https://launchpad.net/bugs/1398771 | 10:52 |
| Saviq | seb128, willcooke, ah, so maybe what happens is that the built-in screen is turned off by hw, and the lid switch inhibitor kicks in | 10:57 |
| Saviq | like if I only have the external screen on, then maybe it makes sense to not react to lid close | 10:57 |
| willcooke | maaaaaybe | 10:59 |
| willcooke | I mean, it kinda makes sense - but feels like there should be a choice somewhere | 11:00 |
| willcooke | there certainly is/was with Windows | 11:00 |
| Saviq | willcooke, well, there is a "when lid is closed:" setting in the power panel | 11:00 |
| Saviq | question is whether that's the desired behavior | 11:00 |
| willcooke | and it didnt do this in 14.10 I assume | 11:01 |
| Saviq | not sure, really | 11:03 |
| willcooke | next strange question then: does having external power connected change anything? | 11:04 |
| * willcooke installs U7 on to his desktop next machine | 11:08 | |
| popey | Does anyone have a good way to debug 993837 - got a friend with it now. | 11:33 |
| popey | bug 993837 | 11:33 |
| ubot5 | bug 993837 in update-manager (Ubuntu) "Can't open Update Manager window after a while" [High,Confirmed] https://launchpad.net/bugs/993837 | 11:33 |
| popey | (update manager is running, icon is there but you can't alt-tab to it to bring it to the front) | 11:33 |
| willcooke | Saviq, seb128 - My 15.04 desktop-next machine with ubuntu-desktop installed doesnt suspend at all when I close the lid. When an external screen is attached the laptop screen gets disconnected | 11:53 |
| willcooke | having power connected doesnt seem to have any effect | 11:54 |
| Saviq | willcooke, do you have the "on lid closed: suspend" setting enabled in settings? | 11:54 |
| willcooke | Saviq, yeah | 11:54 |
| Saviq | willcooke, and you mean it doesn't suspend even without the external screen connected? | 11:54 |
| Saviq | willcooke, might be related, but mine generally suspends without an external screen | 11:55 |
| * Saviq confirms | 11:55 | |
| Saviq | had to restart the session on resume (connected the external screen too early, probably) | 11:57 |
| Saviq | but yeah, it suspended fine | 11:57 |
| willcooke | hrm - and now it works. | 11:59 |
| willcooke | I was running u-s-d --debug that time, and it did suspect | 11:59 |
| willcooke | suspend | 11:59 |
| willcooke | but with the external screen connected it doesnt | 12:00 |
| popey | mine locks on lid close | 12:01 |
| popey | despite me having it set to "do nothing" | 12:01 |
| willcooke | I see "removing lid switch inhibitor" in the logs fwiw | 12:03 |
| willcooke | logs: http://paste.ubuntu.com/9354257 | 12:05 |
| willcooke | that is *with* external screen connected | 12:05 |
| willcooke | disconnect screen, shut lid --> now nothing is responding to a click | 12:07 |
| willcooke | or alt-tab etc | 12:07 |
| willcooke | switch away to vty1 and back | 12:07 |
| willcooke | and I get a 15.04 wallpaper but no option to unlock | 12:07 |
| seb128 | willcooke, can you summarize the issue? | 12:25 |
| seb128 | what config/option/action/result? | 12:25 |
| willcooke | seb128, sure: | 12:26 |
| willcooke | On my Desktop Next machine, I installed "ubuntu-desktop" so I could log in to a U7 session | 12:26 |
| willcooke | (just checking what I'm typing is correct) | 12:27 |
| willcooke | Boot up -> Log in to U7 -> System Settings -> Confirm "close lid" == "suspend" | 12:28 |
| willcooke | Close lid -> Nothing | 12:29 |
| willcooke | where nothing means doesnt suspend | 12:30 |
| seb128 | is that behaviour on battery or power? | 12:30 |
| willcooke | battery | 12:31 |
| willcooke | then: | 12:31 |
| willcooke | open term -> stop u-s-d -> start again with --debug | 12:31 |
| willcooke | then close lid and it suspends | 12:31 |
| willcooke | so now suspend is working again, I connect external screen | 12:32 |
| willcooke | screen gets detected by u-s-d | 12:32 |
| willcooke | close lid -> display moves to external display, no suspend | 12:33 |
| willcooke | open lid -> moves back to laptop display | 12:33 |
| willcooke | disconnect external screen | 12:33 |
| willcooke | doesnt seem to effect usd | 12:33 |
| willcooke | close lid -> nothing | 12:33 |
| willcooke | quite a long summary, sorry | 12:34 |
| willcooke | and now if I switch to vty1 and back to 7 | 12:35 |
| willcooke | its like its locked, but there is no unlock option | 12:35 |
| seb128 | is that on vivid? | 12:38 |
| willcooke | yes | 12:38 |
| seb128 | does the password entry come if you move the mouse on your current | 12:38 |
| seb128 | +screen | 12:38 |
| seb128 | like it might be on the laptop or a ghost screen | 12:38 |
| willcooke | nope | 12:38 |
| seb128 | try going far left or right | 12:38 |
| seb128 | or up/down | 12:38 |
| willcooke | the mouse wont move off the screen | 12:39 |
| willcooke | like it knows there is only one screen | 12:39 |
| seb128 | so it's on the screen | 12:39 |
| seb128 | k, is that vivid? | 12:39 |
| willcooke | yes | 12:39 |
| seb128 | ^ Trevinho conveniently just timeouted :p | 12:40 |
| seb128 | but what you describe seems like we still have an unity7 bug where the unlock prompt is not displayed in some cases | 12:40 |
| seb128 | willcooke, bug #1311316 was supposed to be fix | 12:40 |
| ubot5 | bug 1311316 in Unity 7.2 "After locking screen there is no input field to type password for unlock" [High,In progress] https://launchpad.net/bugs/1311316 | 12:40 |
| seb128 | so maybe it's not fully | 12:41 |
| seb128 | andyrock, bregma, ^ | 12:41 |
| willcooke | ok, so that's one bug, and the suspend thing is likely a different one? | 12:42 |
| seb128 | yeah | 12:43 |
| seb128 | oh, Trevinho_ is back ;-) | 12:43 |
| seb128 | willcooke, would be interesting to have a debug log from u-s-d when it doesn't suspend on lid close and is supposed to | 12:43 |
| willcooke | seb128, this is interesting... it reliably works on the first lid close once I restart usd | 12:47 |
| willcooke | then second one breaks | 12:47 |
| seb128 | hum | 12:47 |
| willcooke | restart usd, works again once | 12:47 |
| seb128 | does it break as well if you don't use external screens? | 12:47 |
| willcooke | yes, this is just internal screen | 12:48 |
| seb128 | k | 12:48 |
| willcooke | I wonder if external screen is a red herring | 12:48 |
| willcooke | Saviq, ^ | 12:48 |
| seb128 | let me try on my inspiron 11 | 12:48 |
| seb128 | I upgraded it yesterday to do some unity8 testing, I've unity7 on it as well | 12:48 |
| willcooke | should be the same as mine then | 12:48 |
| willcooke | same hardware too :D | 12:48 |
| willcooke | damn it - its working now | 12:49 |
| seb128 | lol | 12:50 |
| willcooke | I think it's related to the time between opens and closes | 12:50 |
| Saviq | willcooke, for me it's rather reliable, ext screen → no suspend, no ext screen → suspend | 12:50 |
| Saviq | willcooke, also, your pet peeve, for a while now I've been unable to play any videos with gstreamer on my laptop, had to uninstall gstreamer-vaapi, otherwise was getting stream errors | 12:51 |
| willcooke | I think we've got a cluster of related issues then | 12:51 |
| Saviq | possibly | 12:51 |
| willcooke | Saviq, @ vaapi - yeah, I think we know about that one | 12:52 |
| seb128 | right, that's mentioned on bug #1075774 and we have some other bugs about similar issues | 12:54 |
| ubot5 | bug 1075774 in gstreamer-vaapi (Ubuntu) "[MIR] gstreamer-vaapi" [Undecided,Confirmed] https://launchpad.net/bugs/1075774 | 12:54 |
| willcooke | seb128, @ suspend -> seems to be broken right after boot. Log in, close lid, nada | 12:55 |
| seb128 | willcooke, wfm on my inspiron 11 with current vivid | 12:55 |
| willcooke | ok, I'll reinstall and see what gives. Might just be me | 12:56 |
| seb128 | reinstall is not going to make a difference | 12:56 |
| willcooke | Look! Over there! A wild goose | 12:57 |
| willcooke | :D | 12:57 |
| seb128 | can you share your ~/.cache/upstart/unity-settings-daemon.log | 12:57 |
| seb128 | after getting the issue | 12:57 |
| seb128 | it might have useful info | 12:57 |
| seb128 | you can also edit /usr/share/upstart/sessions/unity-settings-daemon.conf | 12:57 |
| seb128 | to add --debug to the Exec | 12:57 |
| seb128 | to try to get a debug log | 12:58 |
| willcooke | seb128, upstart log: http://paste.ubuntu.com/9354548 | 12:58 |
| willcooke | that's ~/.cache/upstart/usd.log | 13:00 |
| willcooke | seb128, and this: http://paste.ubuntu.com/9354555/ | 13:02 |
| willcooke | seb128, is boot up -> log in -> close lid -> wait -> open lid | 13:02 |
| willcooke | (with --debug on the exec line) | 13:02 |
| willcooke | no external screen, battery power | 13:02 |
| === alan_g is now known as alan_g|lunch | ||
| seb128 | did it suspend? | 13:02 |
| willcooke | nope | 13:03 |
| seb128 | k | 13:03 |
| seb128 | seems like a systemd/logind issue to me | 13:03 |
| seb128 | (unity-settings-daemon:2232): power-plugin-DEBUG: no lid-switch inhibitor | 13:03 |
| seb128 | logind is suposed to suspend on lid close if there is no inhibitor | 13:03 |
| willcooke | I just closed the lid again, and it did suspend | 13:03 |
| seb128 | didrocks, pitti, ^ can you help debugging that? is logind/systemd having any log of those events? | 13:03 |
| willcooke | seb128, this is from where it just worked: http://paste.ubuntu.com/9354572/ | 13:04 |
| seb128 | willcooke, could be useful to get the output from "gdbus call --system -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.ListInhibitors" when it fails to suspend | 13:04 |
| didrocks | seb128: I don't know yet, but I can look :) | 13:05 |
| seb128 | willcooke, how do you see that it fails to suspend? | 13:06 |
| seb128 | how much do you wait? | 13:06 |
| willcooke | seb128, ssh'd in, some seconds, maybe 5 | 13:06 |
| willcooke | trying again from a fresh boot... | 13:06 |
| seb128 | k | 13:06 |
| seb128 | I just had a case where it tooks like 15 seconds to suspend | 13:06 |
| seb128 | make sure to wait a bit | 13:06 |
| desrt | oh man | 13:06 |
| desrt | i didn't know that willcooke was a topposter | 13:06 |
| seb128 | lol | 13:07 |
| seb128 | yeah, he is | 13:07 |
| willcooke | desrt, it's the future, embrace it | 13:07 |
| desrt | NEVER | 13:07 |
| didrocks | desrt: I guess it's part of the manager's pack | 13:07 |
| willcooke | something something something dark side | 13:07 |
| willcooke | you get a free top posting kit with every spreadsheet or slide deck you create | 13:07 |
| desrt | Level up! +1 to top-posting. | 13:08 |
| didrocks | achievement unlocked | 13:08 |
| willcooke | seb128, aaaaaaand - I've massively wasted your time | 13:08 |
| didrocks | desrt: I'm sure they get a bonus if they succeed in us top-posting :) | 13:08 |
| willcooke | seb128, it was taking a long time to suspend | 13:09 |
| desrt | didrocks: they just use it to decide who gets promoted to manager next :) | 13:09 |
| didrocks | ahah | 13:09 |
| Trevinho_ | seb128: getting disconnected frequently -_- | 13:09 |
| === Trevinho_ is now known as Trevinho | ||
| seb128 | willcooke, hahah, I can confirm that one ;-) | 13:09 |
| seb128 | Trevinho, hey | 13:09 |
| willcooke | ok, so generally not suspending - not a bug | 13:10 |
| Trevinho | seb128: hi | 13:10 |
| desrt | willcooke: on the order of 30 seconds, perhaps? | 13:10 |
| willcooke | desrt, yeah | 13:10 |
| willcooke | I can time it.... | 13:10 |
| desrt | it's 30 seconds | 13:10 |
| seb128 | Trevinho, willcooke is still having cases of "unity7 doesn't have an password prompt widget on the unlock screen" in current vivid | 13:10 |
| desrt | that's what gnome does as a timeout for any suspend that's not directly related to an immediate lid-close | 13:10 |
| Trevinho | seb128: mh, damnit... -_- | 13:10 |
| desrt | got changed to (iirc) 8 seconds in a recent release | 13:11 |
| Trevinho | willcooke: do you have anything intresting from auth.log? | 13:11 |
| willcooke | Trevinho, let me find a way to recreate it and I'll take a look | 13:11 |
| didrocks | desrt: isn't that ('sleep', 'didrocks', 'GNOME needs to lock the screen', 'delay', 1000, 1352) ? (I see 1s then) | 13:12 |
| Trevinho | willcooke: also, single monitor? | 13:12 |
| willcooke | desrt, seb128 - took exactly 1m to suspend | 13:14 |
| willcooke | Trevinho,I'll have to check, I've had a lot of permutations of screens in the last hour. | 13:15 |
| didrocks | willcooke: the gdbus call output seb128 pasted would be of help | 13:15 |
| didrocks | gdbus call --system -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.ListInhibitors | 13:15 |
| desrt | willcooke: weird... | 13:16 |
| willcooke | ([('handle-power-key:handle-suspend-key:handle-hibernate-key', 'will', 'GNOME handling keypresses', 'block', uint32 1000, uint32 2227), ('sleep', 'root', 'inhibited', 'delay', 0, 694), ('sleep', 'Unity Lockscreen', 'Unity wants to lock screen before suspending.', 'delay', 1000, 2439), ('shutdown:sleep', 'Telepathy', 'Disconnecting IM accounts before suspend/shutdown...', 'delay', 1000, 2742), ('sleep', 'will', 'GNOME needs to lock the sc | 13:16 |
| willcooke | reen', 'delay', 1000, 2227)],) | 13:16 |
| willcooke | second lid close is more or less immediate | 13:17 |
| willcooke | ~ 1 sec | 13:17 |
| didrocks | no weird inhibitors at least | 13:17 |
| willcooke | Now, with the second screen attached | 13:17 |
| willcooke | and the lid closed. | 13:17 |
| willcooke | No suspend | 13:17 |
| willcooke | ([('handle-power-key:handle-suspend-key:handle-hibernate-key', 'will', 'GNOME handling keypresses', 'block', uint32 1000, uint32 2227), ('sleep', 'root', 'inhibited', 'delay', 0, 694), ('sleep', 'Unity Lockscreen', 'Unity wants to lock screen before suspending.', 'delay', 1000, 2439), ('shutdown:sleep', 'Telepathy', 'Disconnecting IM accounts before suspend/shutdown...', 'delay', 1000, 2742), ('sleep', 'will', 'GNOME needs to lock the sc | 13:17 |
| willcooke | reen', 'delay', 1000, 2227), ('handle-lid-switch', 'will', 'Multiple displays attached', 'block', 1000, 2227)],) | 13:17 |
| seb128 | yeah, I can confirm that one | 13:18 |
| seb128 | desrt, didrocks, pitti, does systemd suspend on lid close only if there is no external monitor? | 13:18 |
| seb128 | and is that new behaviour? | 13:18 |
| desrt | seb128: yes | 13:18 |
| desrt | seb128: no | 13:18 |
| seb128 | are you sure it's not new? | 13:18 |
| desrt | pretty sure | 13:18 |
| seb128 | for some value of "new" | 13:18 |
| seb128 | willcooke, anyway that's why it doesn't suspend | 13:19 |
| desrt | i've been docking my laptop for years and with the lid closed (but external monitor connected) it would stay on | 13:19 |
| didrocks | seb128: I guess this is the handle-lid-switch inhibitor | 13:19 |
| seb128 | the systemd behaviour is not really compatible with our u-c-c options | 13:19 |
| desrt | and here's the thing... imagine i have a laptop plugged in to an external monitor and the lid is open | 13:19 |
| didrocks | seb128: the pid is the one of u-s-d | 13:19 |
| seb128 | well, it means our option on "what to do when lid closed" is not respect in case of external screens on a laptop | 13:19 |
| desrt | if i do: unplug monitor, close lid -- the result is an immediate suspend | 13:19 |
| desrt | but... if i do: close lid, unplug monitor -- the result is a 30 seconds wait | 13:20 |
| seb128 | why? | 13:20 |
| desrt | the reason for that is to handle the case that i do: unplug monitor, open lid | 13:20 |
| seb128 | I see | 13:20 |
| willcooke | I've just unplugged monitor and closed lid -> no suspending (currently waiting with the lid closed) | 13:20 |
| desrt | ie: would be stupid to suspend immediately for that case | 13:20 |
| desrt | i talked to bastien about this though because 30 seconds is too long | 13:20 |
| seb128 | still it means our option of "what to do on lid close" is at least wrongly worded | 13:20 |
| desrt | and he said he was changing it to 8 | 13:20 |
| seb128 | it's "what to do on lid close when no external screen are connected" | 13:20 |
| desrt | dunno if that ever happened | 13:21 |
| desrt | or maybe it stopped being his responsibility when logind took over? | 13:21 |
| willcooke | with second screen disconnected, then lid closed, mine isnt suspending at all | 13:22 |
| willcooke | even after 2 mins | 13:22 |
| willcooke | ([('handle-power-key:handle-suspend-key:handle-hibernate-key', 'will', 'GNOME handling keypresses', 'block', uint32 1000, uint32 2227), ('handle-lid-switch', 'will', 'Multiple displays attached', 'block', 1000, 2227), ('sleep', 'root', 'inhibited', 'delay', 0, 694), ('shutdown:sleep', 'Telepathy', 'Disconnecting IM accounts before suspend/shutdown...', 'delay', 1000, 2742), ('sleep', 'will', 'GNOME needs to lock the screen', 'delay', 100 | 13:22 |
| willcooke | 0, 2227), ('sleep', 'Unity Lockscreen', 'Unity wants to lock screen before suspending.', 'delay', 1000, 2439)],) | 13:22 |
| willcooke | ah ha | 13:23 |
| willcooke | and now I have the broken lock screen | 13:23 |
| seb128 | Trevinho, ^ | 13:23 |
| seb128 | willcooke, the "not suspend at all" is a feature | 13:23 |
| seb128 | but it makes our settings UI confusing | 13:24 |
| seb128 | the option apply only in "stantard laptop mode" | 13:24 |
| willcooke | Trevinho, auth log: http://paste.ubuntu.com/9354644/ | 13:24 |
| Trevinho | andyrock: ^^^^ | 13:24 |
| Trevinho | he worked on delaying the suspension on the unity side (it's the right way to do, but maybe something has a race) | 13:25 |
| willcooke | seb128, @ feature: ack. makes sense | 13:25 |
| bregma | https://bugs.launchpad.net/bugs/1398287 | 13:27 |
| ubot5 | Launchpad bug 1398287 in Unity "Unity 14.04 Lock button sometimes takes 30~60s to enter lock screen" [Undecided,Incomplete] | 13:27 |
| willcooke | this has been sat like it for a few mins now | 13:28 |
| seb128 | didrocks, desrt, https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-power-constants.h#n42 | 13:28 |
| didrocks | ok, 8s now | 13:29 |
| willcooke | re-plugged in 2nd monitor, move mouse over, and now I can escape the bounds of the external screen | 13:29 |
| seb128 | didrocks, desrt, ours is still 30s, I'm going to update it | 13:30 |
| didrocks | seb128: yeah, 8s sounds nicer and enough if you want to unplug and reopen your lid | 13:31 |
| === alan_g|lunch is now known as alan_g | ||
| didrocks | mlankhorst: is it me or the barrier sensitivity isn't working anymore? (there is an option in g-c-c to control it) | 13:46 |
| didrocks | mlankhorst: not sure if it's on the xorg side (I don't mind the launcher appearance itself, but the resistance between monitors) | 13:46 |
| didrocks | Trevinho: you might know ^ | 13:46 |
| didrocks | ah, maybe unity7 side alone | 13:47 |
| didrocks | Trevinho: the launcher responsivness in g-c-c is only controlling launcher reveal edge responsivness | 13:48 |
| didrocks | this value was impacted in the past the edge stop velocity as well | 13:48 |
| mlankhorst | Sweet5hark1: hah, I'm running libreoffice inside XMir inside unity 8 inside unity-system-compositor! :P | 13:48 |
| didrocks | as from one mouse/trackpad to another, it can be hard to go cross barriers | 13:48 |
| Trevinho | didrocks: that setting is only for the launcher yes, but the monitors barrier can be configured from the display pane | 13:49 |
| didrocks | Trevinho: hum, we didn't handle the transition then? | 13:50 |
| didrocks | Trevinho: where in the display pan btw? | 13:50 |
| didrocks | pane* | 13:50 |
| didrocks | Trevinho: there is just sticky edges yes/no | 13:51 |
| didrocks | no way to have a little bit (so that hidden launcher can still be reveal), but adjusting it | 13:51 |
| Trevinho | didrocks: that's the only control we have for monitors | 13:51 |
| didrocks | Trevinho: well, the other option in the past was controlling both values | 13:51 |
| didrocks | Trevinho: that means that I can't reveal the anymore on one of my monitor or I have to push really strongly everytime I cross the edge | 13:52 |
| didrocks | Trevinho: not nice for the users to not handle the transition as we used to :/ | 13:52 |
| Trevinho | didrocks: nothing there changed without design input, I think, by the way: there's also a thing: if you cross the monitor, there's a small delay during which the edge is not sticky anymore | 13:53 |
| Trevinho | didrocks: to fix your position, if you crossed by mistake | 13:53 |
| nessita | hello everyone any advice where to ask about having unity (utopic) acting up regarding: window resizing (when move the mouse pointer to the corner of a window, the pointer changes to the "resizing" pointer as expected, but when trying to actually resize, nothing happens) | 13:54 |
| Trevinho | I'm not in vivid btw, not sure if xorg changed something there | 13:54 |
| didrocks | Trevinho: would have been great to have that discussed, as it took some times in the past to ensure that the global slider was inpacting both. My issue is not to come back to the display, is that the trackpad doesn't have enough velocity by default to cross the monitors | 13:54 |
| nessita | and chromium deciding to stop accepting input from the keyboard after changing windows focus | 13:55 |
| didrocks | Trevinho: I mean, for me, it's fine, I can change the value back in ccsm, not great for $average_user :/ | 13:56 |
| didrocks | (I didn't have my monitors configured left/right for a long time, up/down generally, so didn't notice) | 13:56 |
| Trevinho | I agree | 13:56 |
| seb128 | didrocks, Trevinho, I don't think the u-c-c side of the code changed, is the ccsm value working? | 13:57 |
| seb128 | could be that the config is correctly changed but that unity doesn't use the number anymore | 13:58 |
| didrocks | seb128: right, so the slider is bound to launcher reveal edge responsiveness | 13:58 |
| didrocks | this value (in ccsm) was a combination of all other values regarding launcher reveal and edge barrier | 13:58 |
| Trevinho | didrocks: but probably the ui should have been redisegned anyway, I mean, the bhavior panel controls some stuff which is, according to what the labels say, not related to monitors... And thus in general we should have handled this in different places imho | 13:59 |
| didrocks | it seems now to only impact the launcher reveal pressure | 13:59 |
| Trevinho | didrocks: looking at the code, I think nothing changed btw... so the options still apply to both | 13:59 |
| didrocks | Trevinho: that's would be weird, I didn't touch that one for ages (maybe 3 cycles ago), but didn't use that setup again until today. I'm sure I couldn't live with this barrier and I notice no change in stop velocity depending on what I set | 14:00 |
| mlankhorst | seb128: I have no idea who to ask, how do I start a new user upstart session? | 14:00 |
| Trevinho | we just added it vertical support only | 14:00 |
| mlankhorst | without lightdm.. | 14:01 |
| Trevinho | didrocks: couldn't this related to xorg changes? | 14:01 |
| Trevinho | didrocks: keep in mind that we had a xfixes implementation that was sligthly different to what upstream then included | 14:01 |
| didrocks | Trevinho: can be, but I remember seeing this values changing all others in ccsm | 14:01 |
| didrocks | which isn't the case anymore | 14:01 |
| Trevinho | didrocks: and, indeed we updated our code to support that, but maybe something changed in the internals | 14:02 |
| Trevinho | ah, ok... | 14:02 |
| didrocks | yeah, maybe that breakage is from that transition | 14:02 |
| didrocks | if only all mouse/trackpads were sending similar velocity… | 14:02 |
| Trevinho | seb128: anyway ucc has a bug: if you toggle the launcher autohide the related controls get enabled once and never disabled again | 14:04 |
| Trevinho | seb128: I thought I fixed that some time ago, but maybe it wasn't the case | 14:04 |
| seb128 | mlankhorst, what do you mean "start a new user upstart session"? | 14:05 |
| seb128 | mlankhorst, try asking on #ubuntu-devel maybe | 14:05 |
| mlankhorst | seb128: I want to start the full ubuntu-desktop without lightdm | 14:06 |
| seb128 | mlankhorst, just run gnome-session --session=ubuntu | 14:17 |
| mlankhorst | ok | 14:17 |
| mlankhorst | I'm having problems with getting the unity panels to appear | 14:18 |
| mlankhorst | compiz itself seems to work, but the side panel doesn't show up | 14:27 |
| Sweet5hark1 | seb128: umm, just wondering: anything from me missing still blocking the 4.3/utopic upload? | 14:28 |
| tedg | larsu, Do you know why we have a setting to turn off notifications on scroll wheel adjustments of volume? | 14:29 |
| tedg | Seems like an odd setting that no one would find. | 14:30 |
| tedg | Perhaps mpt as well ^ | 14:30 |
| larsu | tedg: nope, I was wondering this myself at some point | 14:30 |
| larsu | tedg: https://bugs.launchpad.net/indicator-sound/+bug/1225335 | 14:32 |
| ubot5 | Launchpad bug 1225335 in The Sound Menu "[regression] Scrolling over the volume indicator should optionally show the notify-osd" [Medium,Fix released] | 14:32 |
| larsu | tedg: I think I had accidentally removed support for it at some point and promptly got this bug report ;) | 14:32 |
| larsu | cleary some users care about this (*cough* Trevinho *cough*) | 14:32 |
| * tedg is going to wash that setting right out of his hair ♫ | 14:33 | |
| * Trevinho cough | 14:33 | |
| larsu | Trevinho: :) | 14:33 |
| Trevinho | :) | 14:33 |
| larsu | Trevinho: oh, I guess this bug report was more about the notification and less about the setting? | 14:33 |
| larsu | maybe we could remove/deprecate it? | 14:33 |
| Trevinho | larsu: indeed | 14:33 |
| larsu | tedg: you want to remove it? I kind of considered gsettings keys to be API | 14:34 |
| tedg | Eh, I don't think so. | 14:34 |
| Trevinho | larsu: as it was a design change propsal, I put the "option" in, but all it matters is that it works :) | 14:34 |
| tedg | I guess I feel like we've "burned" a name for the future, but I don't think we need to support it in the schemas anymore. | 14:35 |
| larsu | tedg: people's apps will crash if they access the key... (I assume noone does this, though) | 14:35 |
| larsu | Trevinho: right, it makes sense to show the notification. The setting, not so much | 14:36 |
| tedg | I assume everyone has the same cut-and-paste code to work around that API :-/ | 14:36 |
| larsu | hm? | 14:36 |
| tedg | But no one should use a gsettings key in another package. | 14:36 |
| seb128 | Sweet5hark1, no, thanks for the reminder | 14:36 |
| larsu | tedg: "should" | 14:38 |
| larsu | :P | 14:39 |
| larsu | we do this a lot for u-s-d and u-c- | 14:39 |
| larsu | *u-c-c | 14:39 |
| tedg | Yeah, and unfortunately code that depends on those should *really* check for the keys. | 14:39 |
| larsu | there are also some general schemas like org.gnome.desktop | 14:39 |
| tedg | I wish the API was more sane to allow for handling those cases. | 14:39 |
| larsu | tedg: no... the keys should just not change, just like the names of functions in libraries | 14:40 |
| tedg | Runtime breakage is always bad, and hard to debug. Never a solution, always a problem. | 14:40 |
| larsu | right, same for functions in libraries... | 14:41 |
| tedg | There are no tools for things like versioning, which there are in libraries. | 14:41 |
| larsu | maybe we should start having ABI checks for gsettings as well | 14:41 |
| larsu | we could append an api number, like systemd does for dbus names | 14:41 |
| tedg | Heh, still not sure why that's not just the systemd revision number. | 14:42 |
| larsu | because systemd changes faster than those interfaces | 14:42 |
| larsu | desrt: do you know if anyone has ever looked into checking gsettings schemas for abi compat? | 14:43 |
| larsu | desrt: kind of like we do for libs in debian packages | 14:43 |
| tedg | Sure, but if you need to be able to handle multiple, you might as well have lots. Either that or they don't need versioning at all. | 14:43 |
| tedg | You're problem is that you need to be able to check for key usage. | 14:43 |
| tedg | Your | 14:44 |
| tedg | Which is harder. It's easy to see what you export, but not what you use. | 14:44 |
| larsu | ah, I was thinking more along the lines of .symbols files | 14:44 |
| larsu | you get a warning when you remove lines from it | 14:44 |
| larsu | in a package update | 14:45 |
| desrt | larsu: i suspect that nobody has | 14:46 |
| larsu | I wonder if this has ever been a problem in practice | 14:47 |
| larsu | is there a way to deprecate keys? | 14:47 |
| tedg | larsu, Sure, but the other aspect of symbols files is that it makes the package that depends on that library depend on the right version. So it know "> x" by which symbols it uses and when they were introduced. | 14:54 |
| larsu | tedg: ya, that's what I mean. We could have exactly the same | 14:54 |
| tedg | Mostly, it'd be best if it failed to build if a key was missing that it needed. That way it could be an autopkgtest. | 14:55 |
| larsu | do we have that for symbols? | 14:57 |
| tedg | Yeah, it doesn't build :-) | 14:58 |
| willcooke | seb128, desrt - I was just about to reply to that email where I had replied inline and not top posted, but desrt beat me to the reply. ;) | 15:00 |
| willcooke | so yeah, seb128 if you want to start logging desktop specifics that would be a great help | 15:00 |
| seb128 | willcooke, is that specific to Mir or do you want bugs for everything that is needed to make a desktop? | 15:03 |
| seb128 | willcooke, like an example, handling of lid close actions on battery/power with/without external screen, u-s-d does that for us on desktop, we have nothing yet for unity8, not even sure if we need new services or where that should be done | 15:04 |
| willcooke | seb128, hrm. I think we should just stick to Mir for those bugs, and perhaps start another list with another tag for more general features | 15:05 |
| mpt | tedg, I have never seen or heard of that scrollwheel setting. Where is it? | 15:05 |
| tedg | mpt, It's only available via developer tools. | 15:06 |
| seb128 | willcooke, k, do we want to list unity8 features as well | 15:07 |
| willcooke | seb128, yes please, but with another tag | 15:07 |
| seb128 | willcooke, like in multi-monitor what screens should have a launcher, which one is primary | 15:07 |
| seb128 | willcooke, have a tag name in mind? | 15:08 |
| willcooke | kgunn, ^ any preference for a tag to id u8 features *& desktop features? We've got gtk-mir for desrt's ones. How about u8-desktop? | 15:09 |
| kgunn | willcooke: wfm | 15:11 |
| kgunn | Saviq: camako ^ fyi | 15:13 |
| xnox | seb128: are you going to merge https://launchpad.net/ubuntu/+source/libio-socket-ssl-perl/1.965-1ubuntu1 anytime soon? | 15:35 |
| xnox | seb128: it breaks stuff.... like it doesn't talk to ssl sites that disabled sslv3 negotiation -> libwww-perl broken -> uscan is broken -> xnox is not happy and wants to cry | 15:36 |
| seb128 | xnox, no, feel free to grab it | 15:37 |
| seb128 | I've no interest in that package, I just did the mistake to touch it once | 15:37 |
| xnox | seb128: lolz =) | 15:38 |
| xnox | seb128: ok. also doesn't seem to fix my problem =( tested in sid chroot now. | 15:39 |
| seb128 | :-/ | 15:39 |
| seb128 | still feel free to do the merge ;-) | 15:39 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| seb128 | ok, calling it a day a bit earlier today, going to see a spectacle, have a good evening desktopers | 17:02 |
| * Sweet5hark1 mumbles something about being a topposter being a compliment in the same way are being called three star progammer is ... | 20:13 | |
| willcooke | :D | 20:15 |
| * willcooke -> EOD | 20:17 | |
| desrt | Sweet5hark1: ya... three star programming is best avoided | 20:18 |
| desrt | after all, who would want to limit themselves to only three? | 20:19 |
| Sweet5hark1 | desrt: after all in C++ with a std::vector<std::shared_ptr<somthing> > you essentially get the first two stars for free in iteration! | 20:20 |
| ari-tczew | robert_ancell: hi, could you sponsor one merge on bug 1338801 please? | 23:58 |
| ubot5 | bug 1338801 in gnome-screenshot (Ubuntu) "Update to 3.12" [Wishlist,Confirmed] https://launchpad.net/bugs/1338801 | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!