[06:17] good morning [06:40] didrocks: good morning! [06:43] good morning desktopers [06:45] waow desrt! still working? :) [06:45] salut seb128 [06:46] lut didrocks [06:51] didrocks: gvariant hacking for fun and profit [06:58] moin! [07:09] hey Sweet5hark [07:37] Good morning [07:43] hey pitti! [07:43] * pitti ^5s didrocks, I just G+ed about you :) [07:43] pitti: it fixes the kde thingy as well :) [07:43] * didrocks ^5s back :) [07:43] didrocks: oh, does it? I didn't see his response yet, just your "it should fix" [07:43] (it's very likely, though) [07:45] pitti: he answered since [07:45] pitti: my best bet was that /etc wasn't mounted yet [07:45] didrocks: ah, I guess the CC: is slower then [07:46] didrocks: ah, got it now; do you want to do the duplication/merging dance, or shall I? [07:48] pitti: you are a better bts than I am :) [07:48] master* [07:48] 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:49] didrocks: done [07:50] pitti: thanks :) [07:50] didrocks: the liberte0 guys? [07:51] Sweet5hark: yep, my wife is sometimes contracting with them as well (doing design) [07:51] well s/design/visual assets/ [07:53] didrocks: yeah, they were interested in a11y for LibreOffice. Interesting discussion there ... [07:55] hey pitti, wie gehts? [07:57] seb128: gut, danke! ein bisschen muede, ich bin zu spaet ins Bett gegangen [08:03] hey seb128 [08:03] icon scaling needs to be fixed in the apps [08:04] hey, I had a feeling that was coming [08:04] doesn't seem an acceptable solution though [08:04] "let's change gtk in an incompatible way and declare that all the apps need fixing" [08:04] seb128, gtk no longer scales icons if they are outside limits set in icon theme [08:06] mostly it should be as simple as setting GTK_ICON_LOOKUP_FORCE_SIZE flag when getting the icon info [08:06] oh, is that a blocker for updateing gtk to 3.14? [08:06] 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] nautilus is a little more complicated though since its using deprecated GtkActions to generate context menu [08:07] but I will file a bug upstream for that [08:08] thanks [08:08] larsu was looking at those issues yesterday and discussed them on #gtk+ [08:08] pitti: not only auto-imported, of merged as well [08:08] pitti, yes, it's one of the blockers [08:09] pitti, see http://pad.ubuntu.com/gtk-update-v [08:09] darkxst, that still seems a behaviour change from gtk and buggy and wrong [08:11] seb128, https://bugzilla.gnome.org/show_bug.cgi?id=738467 [08:11] Gnome bug 738467 in general "Some icons are enormously large" [Normal,Resolved: fixed] [08:12] darkxst, that's not a fix though... [08:13] I wonder if we could revert the behaviour change in gtk [08:13] seb128, how many things are broken? [08:14] 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] most of the GNOME things are fixed it seems except nautilus [08:14] on a default unity desktop, at least several indicators and nautilus [08:14] yeah [08:15] oh, the unity dash is having issues as well [08:15] but as usual, GNOME apps are the most likely to be fine [08:15] but they are like 1% of the gtk users [08:15] so they give a false summary [08:15] gtk users->apps using gtk [08:16] 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:17] seb128, yes, probably [08:18] I don't suppose there is any real harm in reverting that patch, though I haven't looked for it so far [08:18] gtg be back in half an hour or so [08:18] ttyl [08:25] pitti: on empty machine-id, I think I can create some shell script and playing with setup-machine-id/commit [08:25] with a bunch of bind mounts [08:38] morning [08:39] hey mlankhorst [08:39] hey :) [08:40] morning mlankhorst [08:42] 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] mlankhorst: last time I checked, it was using some xrandr-like functions, but that may have changed [08:43] mlankhorst: not sure there is an API to force that (apart from developping a compiz plugin of course :p) [08:52] darkxst: it can't be fixed in the apps in many cases (for example menus) [08:52] didrocks: or in nspawn perhaps [08:53] didrocks: although the current nspawn test is rather simple, it just sets up a tiny busybox file system [08:54] pitti: so, it means that I would run a debootstrap as part of the autopkgtests? Won't we have $random failures? [08:54] (happens that debootstrap fails) [08:54] didrocks: nah, I think that's too much effort [08:55] didrocks: yeah I will probably just create a 'windowed' xrandr mode which changes names every time a resize event happens [08:55] didrocks: we do debootstrap in the sbuild and lxc autopkgtests, but they always take a while [08:55] pitti: I would nspawn on what then? it needs a chroot, right? [08:55] 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] mlankhorst: yeah, that shuld work :) [08:56] pitti: ah, so no nspawn then [08:56] didrocks: i. e. you could just remove /etc/machine-id, reboot, and see if it comes back properly [08:57] didrocks: (that one should have a "Restrictions: breaks-testbed" :) ) [08:57] 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] didrocks: anyway, only if you are interested in this [08:57] didrocks: you could download ubuntu core perhaps, or the daily LXC builds [08:58] 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] 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:59] didrocks: for now the tests work right on the testbed itself [08:59] (except for nspawn, of course) [08:59] g'mornin [08:59] yeah, but we never tried to break the testbed, did we? [08:59] pitti: in case it's not coming back? [08:59] hey willcooke [08:59] didrocks: then the timeout will hit and the test will fail [09:00] pitti: and a new vanilla testbed will then run other tests? [09:00] didrocks: qemu's reboot hook has a timeout of 5 minutes [09:01] pitti: ok, so each tests are running on its own testbed, tests are isolated? (I guess, by script) [09:01] didrocks: anyway, this is low-prio; I think I want a test for the DM generators much more badly [09:01] didrocks: yes, adt-run takes care of that [09:02] ok, so yeah, little need for nspawn [09:02] pitti: I need to find an example, but yeah, will do that [09:02] didrocks: do you have an idea how the generators can be tested efficiently? [09:03] didrocks: i. e. is there something faster than rebooting the VM each time for each test? [09:03] (although it's not *that* bad -- it takes maybe 10 seconds) [09:03] seb128: this is one of those times where I think we should deviate from the xdg spec [09:03] 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] seb128: it's just really bad and never what you want [09:04] pitti: TBH, I would prefer the end-to-end user experience, meaning: choosing in debconf/postinst [09:04] reboot [09:04] didrocks: sure, that sounds good as well [09:04] and then, check which dm has been restarted [09:04] it's slower, but we know we test what users will have [09:04] yeah, right [09:05] 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] didrocks: I'm not aware of an existing autopkgtest which does that [09:06] something to pioneer then :) [09:07] larsu, yeah, [09:07] larsu, how did the discussion on #gtk+ go? was there anything more (I did read on the afternoon) [09:08] seb128: nah. Alex says the spec is the soec [09:08] *spec [09:09] I'll ask mclasen again today, he made the change [09:09] k [09:09] I'm pondering just distro reverting otherwise [09:09] at least to give some times for apps to be fixed [09:09] same as the wrapping one [09:09] GTK does things in a stupid way by not giving some transition time [09:09] it's "oh, btw, that stopped working, you better fix your code because your app is buggy" [09:10] well, we have transition time now that we're one cycle behind [09:10] but yeah.. [09:10] I don't even know why he made the change... [09:11] the real problem is that he didn't fix the occurences in gtk istelf (like menus) [09:11] is that what bites us on indicators? [09:12] larsu, hmm right, I Guess menu icons are deprecated these days also [09:13] and such code paths will be problematic at best [09:14] darkxst: no, they're not [09:15] what do you mean by "problematic"? [09:15] seb128: yes, you only supply an icon name in gmenu, and gtkmodelmenuitem puts the icon there [09:15] 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:16] (this is Alex' proposed way of fixing this...) [09:17] larsu, maybe I am confusing the menus show icon setting [09:17] larsu, problematic, to fix apps that are calling into gtk (like nautilus with gtkaction's) [09:18] gio has no knowledge of icon sizing [09:20] darkxst: of course it doesn't, it doesn't load any icons... [09:21] darkxst: right, that's what I mean. If it's changed it in gtk, *at least* also change the usage in gtk itself [09:22] 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:24] what exactly is the problem in nautilus? [09:25] didn't someone port it to GAction already? [09:25] if nautilus has problems, someone will fix the code [09:26] larsu, open with menu get huge icons for gvim atleast [09:27] haha, this is awesome :) [09:27] takes the whole screen... [09:33] yeh its pretty big! === shiznix_ is now known as shiznix [10:32] 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:33] any idea if this is caused by hw or something? [10:35] 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:36] seb128, yeah so it doesn't seem to be hw, the screen just gets disabled in the settings [10:36] that would be weird [10:37] I guess you could stop unity-settings-daemon and put a suspend inhibitor another way [10:37] and close the lid [10:37] and see what happens [10:38] seb128, nothing [10:38] shrug [10:38] at least now I know what to file the bug with [10:38] u-s-d? [10:39] maybe try to run it with --debug and provide the log of what happens when you close the lid [10:39] that doesn't make much sense to me of why it would remove the screen and how [10:39] seb128, yeah, I was almost sure it was a suspend issue [10:40] seb128, but then I disconnected the screen and picked up the laptop and it suspended fine [10:40] and then I noticed that the external screen actually gets all of my windows [10:40] is the screen coming back when you reopen the lid? [10:40] yeah [10:40] where is the bug then? [10:40] if you close the lid that screen is virtually missing [10:40] so removing it seems right [10:40] 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] I wonder if this might be a BIOS thing for that? [10:41] Saviq, you've got a Dell? [10:41] willcooke, yes [10:41] XPS12 [10:43] Saviq, dual graphics cards? [10:43] willcooke, no [10:49] hrm [10:52] bug #1398771 then [10:52] 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:57] 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] like if I only have the external screen on, then maybe it makes sense to not react to lid close [10:59] maaaaaybe [11:00] I mean, it kinda makes sense - but feels like there should be a choice somewhere [11:00] there certainly is/was with Windows [11:00] willcooke, well, there is a "when lid is closed:" setting in the power panel [11:00] question is whether that's the desired behavior [11:01] and it didnt do this in 14.10 I assume [11:03] not sure, really [11:04] next strange question then: does having external power connected change anything? [11:08] * willcooke installs U7 on to his desktop next machine [11:33] Does anyone have a good way to debug 993837 - got a friend with it now. [11:33] bug 993837 [11:33] bug 993837 in update-manager (Ubuntu) "Can't open Update Manager window after a while" [High,Confirmed] https://launchpad.net/bugs/993837 [11:33] (update manager is running, icon is there but you can't alt-tab to it to bring it to the front) [11:53] 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:54] having power connected doesnt seem to have any effect [11:54] willcooke, do you have the "on lid closed: suspend" setting enabled in settings? [11:54] Saviq, yeah [11:54] willcooke, and you mean it doesn't suspend even without the external screen connected? [11:55] willcooke, might be related, but mine generally suspends without an external screen [11:55] * Saviq confirms [11:57] had to restart the session on resume (connected the external screen too early, probably) [11:57] but yeah, it suspended fine [11:59] hrm - and now it works. [11:59] I was running u-s-d --debug that time, and it did suspect [11:59] suspend [12:00] but with the external screen connected it doesnt [12:01] mine locks on lid close [12:01] despite me having it set to "do nothing" [12:03] I see "removing lid switch inhibitor" in the logs fwiw [12:05] logs: http://paste.ubuntu.com/9354257 [12:05] that is *with* external screen connected [12:07] disconnect screen, shut lid --> now nothing is responding to a click [12:07] or alt-tab etc [12:07] switch away to vty1 and back [12:07] and I get a 15.04 wallpaper but no option to unlock [12:25] willcooke, can you summarize the issue? [12:25] what config/option/action/result? [12:26] seb128, sure: [12:26] On my Desktop Next machine, I installed "ubuntu-desktop" so I could log in to a U7 session [12:27] (just checking what I'm typing is correct) [12:28] Boot up -> Log in to U7 -> System Settings -> Confirm "close lid" == "suspend" [12:29] Close lid -> Nothing [12:30] where nothing means doesnt suspend [12:30] is that behaviour on battery or power? [12:31] battery [12:31] then: [12:31] open term -> stop u-s-d -> start again with --debug [12:31] then close lid and it suspends [12:32] so now suspend is working again, I connect external screen [12:32] screen gets detected by u-s-d [12:33] close lid -> display moves to external display, no suspend [12:33] open lid -> moves back to laptop display [12:33] disconnect external screen [12:33] doesnt seem to effect usd [12:33] close lid -> nothing [12:34] quite a long summary, sorry [12:35] and now if I switch to vty1 and back to 7 [12:35] its like its locked, but there is no unlock option [12:38] is that on vivid? [12:38] yes [12:38] does the password entry come if you move the mouse on your current [12:38] +screen [12:38] like it might be on the laptop or a ghost screen [12:38] nope [12:38] try going far left or right [12:38] or up/down [12:39] the mouse wont move off the screen [12:39] like it knows there is only one screen [12:39] so it's on the screen [12:39] k, is that vivid? [12:39] yes [12:40] ^ Trevinho conveniently just timeouted :p [12:40] but what you describe seems like we still have an unity7 bug where the unlock prompt is not displayed in some cases [12:40] willcooke, bug #1311316 was supposed to be fix [12:40] 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:41] so maybe it's not fully [12:41] andyrock, bregma, ^ [12:42] ok, so that's one bug, and the suspend thing is likely a different one? [12:43] yeah [12:43] oh, Trevinho_ is back ;-) [12:43] 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:47] seb128, this is interesting... it reliably works on the first lid close once I restart usd [12:47] then second one breaks [12:47] hum [12:47] restart usd, works again once [12:47] does it break as well if you don't use external screens? [12:48] yes, this is just internal screen [12:48] k [12:48] I wonder if external screen is a red herring [12:48] Saviq, ^ [12:48] let me try on my inspiron 11 [12:48] I upgraded it yesterday to do some unity8 testing, I've unity7 on it as well [12:48] should be the same as mine then [12:48] same hardware too :D [12:49] damn it - its working now [12:50] lol [12:50] I think it's related to the time between opens and closes [12:50] willcooke, for me it's rather reliable, ext screen → no suspend, no ext screen → suspend [12:51] 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] I think we've got a cluster of related issues then [12:51] possibly [12:52] Saviq, @ vaapi - yeah, I think we know about that one [12:54] right, that's mentioned on bug #1075774 and we have some other bugs about similar issues [12:54] bug 1075774 in gstreamer-vaapi (Ubuntu) "[MIR] gstreamer-vaapi" [Undecided,Confirmed] https://launchpad.net/bugs/1075774 [12:55] seb128, @ suspend -> seems to be broken right after boot. Log in, close lid, nada [12:55] willcooke, wfm on my inspiron 11 with current vivid [12:56] ok, I'll reinstall and see what gives. Might just be me [12:56] reinstall is not going to make a difference [12:57] Look! Over there! A wild goose [12:57] :D [12:57] can you share your ~/.cache/upstart/unity-settings-daemon.log [12:57] after getting the issue [12:57] it might have useful info [12:57] you can also edit /usr/share/upstart/sessions/unity-settings-daemon.conf [12:57] to add --debug to the Exec [12:58] to try to get a debug log [12:58] seb128, upstart log: http://paste.ubuntu.com/9354548 [13:00] that's ~/.cache/upstart/usd.log [13:02] seb128, and this: http://paste.ubuntu.com/9354555/ [13:02] seb128, is boot up -> log in -> close lid -> wait -> open lid [13:02] (with --debug on the exec line) [13:02] no external screen, battery power === alan_g is now known as alan_g|lunch [13:02] did it suspend? [13:03] nope [13:03] k [13:03] seems like a systemd/logind issue to me [13:03] (unity-settings-daemon:2232): power-plugin-DEBUG: no lid-switch inhibitor [13:03] logind is suposed to suspend on lid close if there is no inhibitor [13:03] I just closed the lid again, and it did suspend [13:03] didrocks, pitti, ^ can you help debugging that? is logind/systemd having any log of those events? [13:04] seb128, this is from where it just worked: http://paste.ubuntu.com/9354572/ [13:04] 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:05] seb128: I don't know yet, but I can look :) [13:06] willcooke, how do you see that it fails to suspend? [13:06] how much do you wait? [13:06] seb128, ssh'd in, some seconds, maybe 5 [13:06] trying again from a fresh boot... [13:06] k [13:06] I just had a case where it tooks like 15 seconds to suspend [13:06] make sure to wait a bit [13:06] oh man [13:06] i didn't know that willcooke was a topposter [13:07] lol [13:07] yeah, he is [13:07] desrt, it's the future, embrace it [13:07] NEVER [13:07] desrt: I guess it's part of the manager's pack [13:07] something something something dark side [13:07] you get a free top posting kit with every spreadsheet or slide deck you create [13:08] Level up! +1 to top-posting. [13:08] achievement unlocked [13:08] seb128, aaaaaaand - I've massively wasted your time [13:08] desrt: I'm sure they get a bonus if they succeed in us top-posting :) [13:09] seb128, it was taking a long time to suspend [13:09] didrocks: they just use it to decide who gets promoted to manager next :) [13:09] ahah [13:09] seb128: getting disconnected frequently -_- === Trevinho_ is now known as Trevinho [13:09] willcooke, hahah, I can confirm that one ;-) [13:09] Trevinho, hey [13:10] ok, so generally not suspending - not a bug [13:10] seb128: hi [13:10] willcooke: on the order of 30 seconds, perhaps? [13:10] desrt, yeah [13:10] I can time it.... [13:10] it's 30 seconds [13:10] Trevinho, willcooke is still having cases of "unity7 doesn't have an password prompt widget on the unlock screen" in current vivid [13:10] that's what gnome does as a timeout for any suspend that's not directly related to an immediate lid-close [13:10] seb128: mh, damnit... -_- [13:11] got changed to (iirc) 8 seconds in a recent release [13:11] willcooke: do you have anything intresting from auth.log? [13:11] Trevinho, let me find a way to recreate it and I'll take a look [13:12] desrt: isn't that ('sleep', 'didrocks', 'GNOME needs to lock the screen', 'delay', 1000, 1352) ? (I see 1s then) [13:12] willcooke: also, single monitor? [13:14] desrt, seb128 - took exactly 1m to suspend [13:15] Trevinho,I'll have to check, I've had a lot of permutations of screens in the last hour. [13:15] willcooke: the gdbus call output seb128 pasted would be of help [13:15] gdbus call --system -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.ListInhibitors [13:16] willcooke: weird... [13:16] ([('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] reen', 'delay', 1000, 2227)],) [13:17] second lid close is more or less immediate [13:17] ~ 1 sec [13:17] no weird inhibitors at least [13:17] Now, with the second screen attached [13:17] and the lid closed. [13:17] No suspend [13:17] ([('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] reen', 'delay', 1000, 2227), ('handle-lid-switch', 'will', 'Multiple displays attached', 'block', 1000, 2227)],) [13:18] yeah, I can confirm that one [13:18] desrt, didrocks, pitti, does systemd suspend on lid close only if there is no external monitor? [13:18] and is that new behaviour? [13:18] seb128: yes [13:18] seb128: no [13:18] are you sure it's not new? [13:18] pretty sure [13:18] for some value of "new" [13:19] willcooke, anyway that's why it doesn't suspend [13:19] i've been docking my laptop for years and with the lid closed (but external monitor connected) it would stay on [13:19] seb128: I guess this is the handle-lid-switch inhibitor [13:19] the systemd behaviour is not really compatible with our u-c-c options [13:19] and here's the thing... imagine i have a laptop plugged in to an external monitor and the lid is open [13:19] seb128: the pid is the one of u-s-d [13:19] 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] if i do: unplug monitor, close lid -- the result is an immediate suspend [13:20] but... if i do: close lid, unplug monitor -- the result is a 30 seconds wait [13:20] why? [13:20] the reason for that is to handle the case that i do: unplug monitor, open lid [13:20] I see [13:20] I've just unplugged monitor and closed lid -> no suspending (currently waiting with the lid closed) [13:20] ie: would be stupid to suspend immediately for that case [13:20]