[11:54] <sil2100> Saviq: hey! You mentioned that you guys were looking into the unity8 security-bugfix and checking if the deployed fix is enough - all good in regards to that?
[11:54] <sil2100> No follow up fix needed?
[12:12] <tsdgeos> sil2100: there's a follow up fix needed
[12:12] <sil2100> tsdgeos: hmm... this won't make it for OTA-9 then, we'll have to get that into OTA-9.5
[12:12] <tsdgeos> sil2100: saviq is on usa still, visiting friends, not sure if he said he'd be working or not though
[12:13] <tsdgeos> sil2100: yes, 9.5 is like "next week" anyway, right?
[12:13] <sil2100> Yeah
[12:13] <tsdgeos> ok
[13:27] <Saviq> tsdgeos, hey, yeah, I'm working
[13:28] <tsdgeos> oki
[13:28] <tsdgeos> morning
[13:41] <tsdgeos> Saviq: was wondering, the few last MRs failed on xenial jenkass
[13:42] <tsdgeos> would it make sense like "wait 5 min and try again before failing"
[13:42] <tsdgeos> if the apt-get step fails?
[13:43] <Saviq> tsdgeos, assuming I'm getting a meaningful exit code out of it, I might do that, yeah
[13:47] <Saviq> tsdgeos, better than that I'll try to switch to the internal archive cache, which should have less trouble like that
[13:47] <tsdgeos> oki
[14:01] <tsdgeos> Saviq: where's the autopkg test run in https://requests.ci-train.ubuntu.com/#/ticket/877 ? can't see it
[14:01] <Saviq> tsdgeos, they only run when it's approved by the lander
[14:01] <tsdgeos> ah
[14:02] <Saviq> tsdgeos, and since it got rebuilt, they got cleared
[14:02]  * Saviq rebuilds
[14:56] <alan_g> Saviq: does API this work for you? https://code.launchpad.net/~alan-griffiths/mir/add-mir_surface_spec_set_shell_chrome/+merge/283818
[14:58] <Saviq> alan_g, looks good here, dednick, can you have a look ↑
[15:03] <mzanetti> tsdgeos, added that test. was harder that I thought. but should make us more bulletproof for the future
[15:04] <tsdgeos> mzanetti: cool, checking
[15:04] <dednick> alan_g, Saviq: is that dynamic?
[15:05] <Saviq> IIUC, yes
[15:05] <dednick> Saviq: or doesnt it need to be?
[15:05] <Saviq> it does need to be
[15:05] <dednick> i'm not familiar with the surface spec, but it doesnt look like it to me.
[15:05] <alan_g> dednick: yes. It can be set on creation, or applied later
[15:05] <Saviq> dednick, the second test is "apply..."
[15:06] <dednick> ah. ok. mir::options = cool.
[15:06] <dednick> then looks all good.
[15:07] <dednick> ahh. theres mir_surface_apply_spec. got it.
[15:11] <oSoMoN> hey, is https://launchpad.net/bugs/1537782 a known issue?
[15:14] <Saviq> dandrader, does that ring a bell ↑?
[15:21] <dandrader> Saviq, yeah... it might be possible that the modifiers get lost in translation in the "mir server interface -> unity8 qml scnene -> mir server-client wire procotol -> qtubuntu" road
[15:24] <Saviq> dandrader, think you could have a look?
[15:26] <dandrader> Saviq, once I get back home preferably. no bluetooth kbd or test machine to play with
[15:27] <Saviq> dandrader, ack
[15:31] <mzanetti> @unity: whoever is not jetlagged, standup :)
[15:39] <cimi> mzanetti, wrong irc server :P
[15:39] <mzanetti> ?
[15:39] <mzanetti> cimi, ^
[15:39] <cimi> mzanetti, we usually ping for standup in canonical irc
[15:40] <mzanetti> ah... didn't know that was intentionally
[15:40] <cimi> mzanetti, was taking piss that you are probably jetlagged too :)
[15:41] <mzanetti> I kinda am, yes
[15:41] <mzanetti> feels like 4am, rather than 4pm right now
[15:44] <tsdgeos> :D
[15:44] <tsdgeos> mzanetti: is there a bug for https://code.launchpad.net/~mzanetti/unity8/edgebarrier-click-transparent/+merge/283735 ?
[15:48] <mzanetti> tsdgeos, don't think so, but it's easy to repro and quite annoying when typing messages
[15:48]  * mzanetti searches
[15:48] <tsdgeos> mzanetti: i'm just trying to know what i need to do to test it :D
[15:48] <mzanetti> tsdgeos, type something with the OSK. the q key is quite nasty to press
[15:49] <mzanetti> depending on the layout, the a and shift key too
[15:49] <mzanetti> the ones that touch the left edge
[15:50] <mzanetti> tsdgeos, you'll notice the difference immediately if you try to press the osk very close to the edge.
[15:50] <dandrader> tsdgeos, also have to ensure that the edge push to show spread & launcher are no affected
[15:50] <dandrader> *not
[15:50] <mzanetti> if you just type a normal message, you'd notice the q key often just doesn't react
[15:50] <tsdgeos> dandrader: you mean with the mouse?
[15:51] <dandrader> tsdgeos, yes
[15:51] <tsdgeos> k
[16:13] <tsdgeos> mzanetti: dandrader: about the push to show launcher, can you guys confirm that if you exit the launcher form the unity icon it won't autohide?
[16:16] <dandrader> tsdgeos, confirm if it happens or if it's the expected behavior?
[16:16] <tsdgeos> dandrader: happens
[16:16] <tsdgeos> i guess it's not the expected behaviour
[16:17] <tsdgeos> but if it is, that also helps :D
[16:17] <dandrader> tsdgeos, by clicking with a mouse?
[16:18] <dandrader> tsdgeos, I don't think it should autohide while the mouse is still hovering over it....
[16:18] <tsdgeos> dandrader: "exit the launcher"
[16:19] <tsdgeos> i have a typo
[16:19] <tsdgeos> form -> from
[16:19] <dandrader> tsdgeos, ah, so you mean the mouse if hovering over the dash icon and then you move it away from the launcher?
[16:20] <tsdgeos> dandrader: yes
[16:20] <dandrader> tsdgeos, I confirm it happens and that's a bug in trunk it seems
[16:22] <dandrader> tsdgeos, doesn't happen all the time though...
[16:23] <tsdgeos> dandrader: ok, so do i file a bug, correct?
[16:24] <dandrader> tsdgeos, yes.to safely reproduce it you have to perform the edge push already at the y position where the dash button will show up
[16:24] <tsdgeos> that may be, yes
[16:25] <mzanetti> hmm, haven't managed to hit it yet
[16:25] <dandrader> tsdgeos, if you do the edge push from elsewhere, move the pointer to the dash button, then exit the launcher. it will still autohide
[16:25] <tsdgeos> ok
[16:25] <tsdgeos> so it's not hide from
[16:25] <mzanetti> ah now it did
[16:25] <tsdgeos> but show and exit from
[16:25] <mzanetti> yeah, bug
[16:25] <dandrader> tsdgeos, yes
[16:25] <mzanetti> nice catch :D
[16:26] <dandrader> I hope we can catch this with a tst_Shell.qml test...
[16:28] <tsdgeos> dandrader: mzanetti: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1537817 makes sense?
[16:29] <dandrader> tsdgeos, yes
[16:29] <mzanetti> tsdgeos, it's also called BFB :)
[16:29] <mzanetti> but yeah, this works
[16:29] <mzanetti> and it's the ubuntu icon, not unity :D
[16:29] <tsdgeos> someone was confused about the BFB terminology the other day
[16:29] <dandrader> mzanetti, BFB?
[16:29] <mzanetti> big fat button
[16:29] <mzanetti> designers call it that way
[16:30] <dandrader> mzanetti, was searching for BFB and all kinds of stuff showed up :)
[19:30] <Jemand_> Hallo
[19:32] <davmor2> mzanetti: Oh Fat yeah not the version I heard
[19:35] <gnukarabatak> Hello everybody.  I am using Ubuntu 15.10 unity. Work areas are not working isolated from each other. I am writing this post to report it. Maybe the solution can be found.
[19:35] <gnukarabatak>  work areas "workspace" :)
[19:36] <Saviq> gnukarabatak, can you please file a bug by running Alt+F2, "apport-bug unity"?
[19:37] <Saviq> or via https://bugs.launchpad.net/ubuntu/+source/unity/+filebug, but the former is preferable as it will add some details about your setup
[19:38] <gnukarabatak> thanks.
[20:23] <mterry> tedg, I'm debugging why my qtmir branch doesn't work on top of your app-object branch -- it looks like I'm no longer seeing callbacks from ubuntu_app_launch_observer_add_app_starting
[20:24] <mterry> tedg, you said to keep using the old callbacks, right?
[20:24] <tedg> mterry: Hmm, not sure of a good reason that would happen. Yeah, use the old callbacks.
[20:24] <mterry> (rather than the new-style object callbacks)
[20:25] <tedg> mterry: I've tried to keep it as mostly a wrapper on the old code to reduce risk...
[20:25] <mterry> tedg, I could still be doing something dumb...
[20:25] <tedg> mterry: Hmm, okay, you can start a ubuntu-app-watch to see the signals in the CLI.
[20:26] <tedg> mterry: That might help to see if they're getting setn.
[20:26] <tedg> sent
[21:43] <mterry> tedg, ok...  so what would cause Application::info() to return a null ptr?  Seems I'm getting that for "ubuntu-system-settings"
[21:54] <mterry> tedg, line 61 in application-impl-legacy?
[21:54] <mterry> .cpp
[22:14] <mterry> tedg, and line 60 needs an "applications" in it
[22:17] <tedg> mterry: Fixed and pushed, need to still write tests for that code.
[22:18] <tedg> mterry: Does U8 have tests for all the desktop keys?
[22:18]  * tedg will have to look
[22:18] <mterry> tedg, I don't think u8 does...  qtmir might test some of them
[22:18] <mterry> tedg, but it would mock out u-a-l in that case
[22:19] <tedg> mterry: I mean, from before when it read the desktop file itself.
[22:20] <dandrader> tedg, fwiw qtmir has some tests for its desktop file reader I think
[22:27] <mterry> tedg, oh yeah, qtmir had some tests yeah
[22:27] <mterry> tedg, now I'm seeing why click apps aren't launching either  :-P  but ubuntu-system-settings does!
[22:27]  * tedg prefers to steal rather than write
[22:28] <tedg> mterry: Heh, are you saying the real world is different than the one that exists inside my head? ;-)
[22:30] <mterry> tedg, who's to say we're not all figments of your imagination?  But please tell your imagination to let click apps work
[22:40] <mterry> tedg, ...
[22:41] <mterry> tedg, so if I give parse() "com.ubuntu.camera_camera" what should I expect?
[22:41] <mterry> AppID::parse that is
[22:42] <tedg> mterry: I think you need the full appid today.
[22:43] <tedg> mterry: Yeah, it'll error.
[22:43] <mterry> tedg, hrm.  So I have an appid input from an API, there's no easy way to get a proper AppID object...  I don't know whether I have package or appname or version or what, so I can't use the discover API
[22:45] <tedg> So we need it to be smart enough to handle legacy AppIDs as well.
[22:45] <tedg> legacy/short/full
[22:45] <mterry> tedg, yeah I hoped parse() would parse what it could and use discover() behind the scenes if it wasn't enough
[22:46] <mterry> tedg, maybe that behavior should be a third call.  But it would be a useful api call
[22:46] <tedg> Yeah, that's what I'm thinking. I can't think of a good name though.
[22:46] <tedg> "figure it out"
[22:46] <tedg> fromWTF
[22:47] <tedg> interpet?
[22:48] <tedg> applyHuristics()
[22:49] <mterry> tedg, an overloaded parse call?  or another discover call?
[22:49] <tedg> Forgot the "e", knew that didn't look right.
[22:49] <tedg> Yeah, kinda thinking I want it a different name to just say "this might be doing more than you want"
[22:50] <tedg> stringSolver()
[22:51] <mterry> tedg, "discover" already implies that
[22:51] <mterry> tedg, "find" ?
[22:52] <tedg> Ah, I like find(), let's go with that.
[22:52] <mterry> tedg, also I don't think parse() does throw any errors
[22:52] <mterry> tedg, but if you try to use the result in other places, you might get errors yeah
[22:52] <tedg> mterry: No, it returns an empty() AppID.
[22:53] <mterry> tedg, only if the input is empty
[22:54] <tedg> mterry: Sure, otherwise it returns a legacy AppID.
[22:54] <mterry> tedg, otherwise it looks like it will have a valid package/appname but empty version
[22:54] <tedg> I think package is empty as well.
[22:54] <mterry> in the com.ubuntu.camera_camera case
[22:54] <mterry> tedg, that's in the legacy case
[22:54] <tedg> Yeah, so when you're going back to string it's not putting anymore '_' in.
[22:54] <mterry> tedg, but in any case, those aren't errors
[22:55] <tedg> We probably shouldn't let legacy appid's include a '_' — wonder if that'd break anything.
[22:55] <mterry> tedg, I'm not talking about legacy apps right now.   com.ubuntu.camera_camera is a click id without a version
[22:55] <mterry> tedg, which AppID::parse correctly parses as an appId without a version
[22:56] <mterry> tedg, but it doesn't give an error.  You implied you expected it to
[22:57] <tedg> Yeah, what it's doing is returning the tuple { '', 'com.ubuntu.camera_camera', '' } which is a legacy appid.
[22:58] <mterry> tedg, ah I see.  weird behavior, yeah
[23:04] <tedg> mterry: Cool, I need to head out now, but I should get to this tomorrow.