[00:22] <Umeaboy> mhall119: The desktop iso should always be able to boot Live.
[00:23] <Umeaboy> You press ESC almost instantly after booting it up.
[00:23] <Umeaboy> Then you can choose to Use Ubuntu without installing it.
[00:29] <mhall119> Umeaboy: I was asking about a Unity 8 session specifically
[00:29] <Umeaboy> OK.
[00:29] <mhall119> IIRC, the Desktop Next ISO was discontinued at some point, and I don't know if it's been restarted
[00:30]  * mhall119 used to try Desktop Next on his wife's laptop
[05:11] <Mirv> Saviq: ok to 939, will update
[05:14] <Mirv> mhall119: I asked a few weeks ago and it was still on hold. maybe after xenial release?
[08:28] <tsdgeos> man we did a landing and still have 21 approved branches to land D:
[09:38] <cimi> tsdgeos, hola
[09:38] <tsdgeos> cimi: hola
[09:39] <cimi> that branch seems to have passed qmltests too https://code.launchpad.net/~cimi/unity8/more_stable_lazy_image_test/+merge/284596
[09:39] <cimi> tsdgeos, you prefer this or transitionCount?
[09:41] <tsdgeos> let me un the tests here
[09:42] <tsdgeos> cimi: anything you miss on https://code.launchpad.net/~aacid/unity8/preview_audio_playlist/+merge/284624 for the top approval?
[09:44] <cimi> tsdgeos,  I was missing the CI comment
[09:44] <cimi> tsdgeos, can top approve
[09:44] <Saviq> ltinkl, kbdLayout on unity8 conflicts, you can't merge trunk in your branch if it's based on some other branch - you need to follow the chain - otherwise bzr goes into criss-cross mode and barfs up conflicts
[09:44] <Saviq> ltinkl, so you'll need to rewrite history on that one, too
[09:56] <tsdgeos> cimi: can you do https://code.launchpad.net/~aacid/unity8/do_not_use_components_generated_code/+merge/284289 too?
[09:56] <tsdgeos> Saviq: will you do https://code.launchpad.net/~aacid/unity8/fallback_for_empty/+merge/284235 or do i ask cimi?
[09:56] <cimi> tsdgeos, I can do both if you want
[09:58] <tsdgeos> cimi: works for me
[10:02] <tsdgeos> Saviq: any idea what's wrong in https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/376/arch=armhf,release=xenial/console ?
[10:16] <tsdgeos> cimi: ok we can you with your branch if you prefer that
[10:16] <tsdgeos> cimi: i'll delete my branch and MR and you resubmit yours on top of trunk?
[10:17] <cimi> tsdgeos, when I did transitionCount, I didn't really like it :D
[10:17] <cimi> tsdgeos, can do
[10:18] <tsdgeos> cimi: oh launchpad is smart enough to do it itself
[10:18] <tsdgeos> except the diff...
[10:19] <tsdgeos> cimi: anyway merge unity8 trunk and see what happens to the MR
[10:19] <tsdgeos> Saviq: this seems bad https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1540490 :/
[10:19] <ubot5`> Launchpad bug 1540490 in unity8 (Ubuntu) "app icons getting their top cut off (Ubuntu Touch)" [Undecided,New]
[10:22] <Saviq> tsdgeos, well, not crazy bad since easily recoverable, but yeah, would be nice to fix - LVWPH looks like it?
[10:23] <Saviq> tsdgeos, "Cannot allocate memory" hum
[10:23] <tsdgeos> Saviq: yeah, probably together with the new "better updates" from the scopes-pluigin
[10:23] <cimi> tsdgeos, Saviq https://code.launchpad.net/~cimi/unity8/more_stable_lazy_image_test/+merge/284708
[10:25] <Saviq> tsdgeos, re: jenkins build, I'll monitor stuff to see if we get it again
[10:25] <tsdgeos> Saviq: i'd say we just did, see the two new failed emails
[10:26] <Saviq> tsdgeos, I was looking at the top of https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/arch=armhf,release=xenial/
[10:26] <tsdgeos> k
[10:27] <tsdgeos> cimi: clean your tas
[10:27] <tsdgeos> tags
[10:27] <Saviq> tsdgeos, and can't see the same issues anywhere else
[10:35] <cimi> tsdgeos, all clean
[10:35] <cimi> tsdgeos, ta
[10:38] <Saviq> tsdgeos, ah I know what happened, it's running two builds in parallel on the armhf nodes, should only be one... but there's $reasons why I had to give it two executors
[10:38] <Saviq> and it just OOMed
[10:38] <Saviq> I've a plan, though
[10:39] <Saviq> let's see how bad this becomes
[10:39] <tsdgeos> ok
[10:49] <Mirv> Saviq: ok 053 qtmm is now there (with updated symbols)
[10:50] <Saviq> Mirv, tx
[10:50] <dandrader> Saviq, something funny happened with the qtubuntu landing
[10:50] <Saviq> dandrader, ?
[10:50] <dandrader> Saviq, revision 308 "Implement QPlatformOffscreenSurface" is also carrying its prerequisite (lp:~dandrader/qtubuntu/loggingCategory)
[10:51] <dandrader> Saviq, so lp:~dandrader/qtubuntu/loggingCategory didn't land on its own, separate, commit
[10:51] <Saviq> dandrader, d'uh, not funny, just /me being daft :/
[10:52] <Saviq> missed the prerequisite in there
[10:52] <Saviq> dandrader, did we break something?
[10:52] <dandrader> Saviq, no, just the bzr history got "weird"
[10:53] <Saviq> dandrader, I think we missed a commit or two from the top of loggingCategory, /me checks
[10:53] <dandrader> Saviq, I would think the landing machinery would automagically sort out those declared pre-requisites....
[10:53] <Saviq> dandrader, it does, when they are added as MPs, apparently it doesn't check whether they are
[10:53]  * Saviq files a bug
[10:54]  * dandrader sets https://code.launchpad.net/~dandrader/qtubuntu/loggingCategory/+merge/279629 to merged
[10:55] <ltinkl> Saviq, I'm a bit puzzled now, should I revert my trunk merge in kbdLayout and push+overwrite?
[10:56] <Saviq> dandrader, I'll see if I can fix the hisotry
[10:56] <Saviq> dandrader, but seems no diff missing
[10:56] <Saviq> dandrader, can you merge trunk in unity8 initial geom, and ltinkl you uncommit your last merge and merge ← into yours instead of trunk
[10:57] <ltinkl> Saviq, ok
[10:57] <dandrader> Saviq, yeah, it missed only a "merge trunk" commit from the original loggingCategory branch, which is irrelevant
[10:57] <Saviq> ltinkl, basically, bzr can't deal with you merging foo and then bar if foo is based on bar
[10:57] <Saviq> dandrader, indeed
[10:58] <ltinkl> Saviq, I see, so trunk has to be merged only in the root of the chain
[10:58] <Saviq> ltinkl, unfortunately, yes
[10:58] <Saviq> ltinkl, well, in theory it works, just until there's conflicts, which is usually the reason to have the chain in the first place, so...
[10:59] <ltinkl> dandrader, just ping me when you're done
[11:00] <cimi> tsdgeos, example of concierge mode is the photos scope where it asks for instagram account right?
[11:00] <tsdgeos> cimi: no, it's the "My videos" when no videos are present
[11:00]  * cimi checks
[11:01] <Saviq> dandrader, bug #1540860
[11:01] <ubot5`> bug 1540860 in CI Train [cu2d] "Should error out if a branch's prerequisite isn't in the list of MPs" [Undecided,New] https://launchpad.net/bugs/1540860
[11:01] <cimi> tsdgeos, btw which one is the card for facebook and instagram account for example
[11:01] <cimi> ?
[11:01] <cimi> tsdgeos, we have an issue of aspect ratio over there
[11:01] <tsdgeos> it's a regular horizontal card, no?
[11:01] <cimi> tsdgeos, I have to see
[11:01] <tsdgeos> cimi: you mean the bug i filed like 3 years ago?
[11:01] <cimi> tsdgeos, maybe :D
[11:01] <Saviq> dandrader, can you uncommit the trunk merge from loggingCategory please and overwrite
[11:01] <cimi> tsdgeos, link,?
[11:02] <tsdgeos> cimi: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1421293
[11:02] <ubot5`> Launchpad bug 1421293 in ubuntu-ui-toolkit (Ubuntu) "Icon width is inconsistent when height is specified" [Low,Triaged]
[11:03] <tsdgeos> ok, only 1 year ago
[11:03] <cimi> tsdgeos, yeah
[11:03] <cimi> tsdgeos, on arale is bad
[11:03] <cimi> tsdgeos, because we have 50gu
[11:03] <dandrader> Saviq, so that it matches the loggingCategory copy in offscreenSurface-lp1527737?
[11:03] <Saviq> dandrader, yes
[11:03] <tsdgeos> cimi: it's not, see it's marked as "Low" ;)
[11:04] <cimi> tsdgeos, :)
[11:04] <Saviq> dandrader, so when I merge it as I'm rewriting history, we get the ~same result
[11:05] <Saviq> w00t we're starting to get green test-0-autopkgtest :]
[11:05] <dandrader> Saviq, merged trunk in lp:~dandrader/unity8/initialSurfaceGeom
[11:05] <Saviq> dandrader, thanks, ltinkl you can merge ↑
[11:05]  * ltinkl on it
[11:06] <dandrader> Saviq, removed the top-most "Merge trunk" from lp:~dandrader/qtubuntu/loggingCategory
[11:06] <Saviq> dandrader, thanks
[11:07] <ltinkl> Saviq, done
[11:12] <ltinkl> Saviq, can I start the build?
[11:13] <Saviq> ltinkl, go for it
[11:13] <Saviq> dandrader, lp:qtubuntu fixeded
[11:14] <cimi> tsdgeos, just a comment https://code.launchpad.net/~aacid/unity8/do_not_use_components_generated_code/+merge/284289
[11:16] <tsdgeos> cimi: right we can
[11:16] <tsdgeos> i used to have the code wrong
[11:16] <dandrader> Saviq, cool
[11:16] <tsdgeos> and then i was using isConciergeMode directly
[11:17] <Saviq> dandrader, thanks for noticing
[11:17] <tsdgeos> and that we can not since noone guarantees components["art"] && components["art"]["conciergeMode"] would be a bool
[11:17] <tsdgeos> but since we're ! it then it is fine
[11:17] <Saviq> dandrader, now let's hope no trainguard or davmor2 notices what we did ;)
[11:17] <Saviq> OOPS
[11:18] <sil2100> ..do I want to know?
[11:20] <davmor2> Saviq: I'm gonna beat you with sil2100 big stick so I don't have to travel with one
[11:21] <Saviq> sil2100, davmor2, j/k, we messed up lp:qtubuntu history (forgot to put a prerequisite MP in the train), but nothing bad happened
[11:22] <Saviq> like, code is the same, just there wasn't an explicit MP for it (and it was just logging refactor)
[11:22] <Saviq> I've now overwritten lp:qtubuntu history to say the truth about it
[11:23] <Saviq> and filed a train bug about it letting us do this
[11:23] <Saviq> sil2100, bug #1540860
[11:23] <ubot5`> bug 1540860 in CI Train [cu2d] "Should error out if a branch's prerequisite isn't in the list of MPs" [Undecided,New] https://launchpad.net/bugs/1540860
[11:24]  * davmor2 slaps Saviq repeatedly with a stick of celery and tells him not to do it again
[11:31] <davmor2> Saviq:  on a fresh install in windowed mode open the clock app, here maps or weather app what happens to the window is ugly do you know if there is a way to work around that I assume the issue is the trust-prompt overlay right?
[11:31] <Saviq> davmor2, lemme see
[11:31] <tsdgeos> Saviq: still mismatches :/ https://unity8-jenkins.ubuntu.com/job/build-2-binpkg/381/arch=i386,release=xenial/console
[11:32] <davmor2> Saviq: check for window size and title of window
[11:32] <cimi> tsdgeos, we have a failing GenericScopeView test in that branch, is it related?
[11:32] <cimi> seems like possiblwe
[11:35] <Saviq> davmor2, window size seemed fine, title we'll have to look at
[11:36] <davmor2> Saviq: seriously when the prompt appear the window changes from a square to a rectangle and when you accept the prompt it changes back to a square
[11:36] <Saviq> davmor2, I think the problem is that the title gets set to that and then the app is blocked because of the trust prompt and is only able to reset the window title properly after it's let go
[11:37] <Saviq> davmor2, huuh, didn't see that
[11:37] <Saviq> davmor2, but I have an idea
[11:37] <tsdgeos> cimi: good question, should not, i'll have a look
[11:37] <tsdgeos> cimi: and actually we need the "true" : "false"
[11:37] <tsdgeos> without it we end up with 1 or 0
[11:37] <tsdgeos> which upsets qml
[11:37] <tsdgeos> since visible: 1 is wrong
[11:37] <cimi> tsdgeos, ok
[11:37] <Saviq> davmor2, does that include silo 19 btw?
[11:38] <Saviq> davmor2, scratch that, we've not landed those yet
[11:38] <davmor2> Saviq: I noticed testing it yesterday but only remembered it today because you only trigger the prompt once
[11:39] <Saviq> davmor2, I'd say it's bug #1532974
[11:39] <ubot5`> bug 1532974 in unity8 (Ubuntu) "large window flicker on ubuntu apps launching in window mode" [Critical,In progress] https://launchpad.net/bugs/1532974
[11:39] <Saviq> just amplified by the trust prompt
[11:39] <Saviq> davmor2, I'll have a look out
[11:39] <davmor2> Saviq: thanks
[11:40] <tsdgeos> cimi: so it seems the test is indeed reproducible there
[11:40] <tsdgeos> that's scary :D
[11:40] <tsdgeos> s/test/test failure
[11:41] <cimi> tsdgeos, well, reproducing is always good :)
[11:47] <Saviq> tsdgeos, yeah I've asked for access to an internal mirror, didn't get it yet
[11:47] <Saviq> re hash mismatches
[11:47] <tsdgeos> ah
[11:48] <tsdgeos> i thought we had that alread
[11:48] <tsdgeos> y
[11:53] <Saviq> /food
[14:22] <Saviq> dandrader, ltinkl, can we wrangle https://code.launchpad.net/~dandrader/unity8/sizeHints/+merge/278743 and friends in between initial size geom and kbdlayout? FWIW it might be time to split out the API bumps into a separate MP, assuming we're not conflicting elsewhere (which we probably do?)
[14:22] <Saviq> in between, or after, /me no cares
[14:23] <dandrader> Saviq, well, since sizeHints is the oldest branch of them all, I think we should put the others on top of it
[14:23] <Saviq> dandrader, not sure if oldest/newest is a factor, whatever's easiest, really
[14:23] <ltinkl> makes sense... that means a lot of rebasing again right? :/
[14:23] <tsdgeos> cimi: if you have time https://code.launchpad.net/~aacid/unity8/circleForAudioCards/+merge/284747 is something design wants to get soon asap
[14:23] <Saviq> ltinkl, dandrader, which is why I'd put sizeHints on top of kbdLayout instead
[14:23] <Saviq> as it doesn't have any prereq atm
[14:23] <ltinkl> Saviq, I agree :)
[14:24] <ltinkl> less rebasing imo
[14:24] <dandrader> Saviq, makes sense
[14:24] <Saviq> tsdgeos, https://code.launchpad.net/~aacid/unity8/nodda/+merge/280814 - dependencies correct there? no need for anything in build deps?
[14:24] <ltinkl> I see mzanetti already threw in another stuff
[14:25] <tsdgeos> Saviq: there's a newer branch required but it also landed in the currently released uitk
[14:25] <Saviq> tsdgeos, https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/xvfb_pixels_per_mm/+merge/282149 didn't get released yet, did it?
[14:25] <Saviq> says revision 1801
[14:25] <mzanetti> ltinkl, ?
[14:25] <mzanetti> ah, the silo
[14:26] <ltinkl> mzanetti, yeah, the silo 51
[14:26] <Saviq> tsdgeos, and last released is 1795 https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit
[14:26] <tsdgeos> Saviq: hmmm
[14:26] <tsdgeos> i just ran nodda branch today under xvfb and all aws good
[14:26] <Saviq> tsdgeos, can you add a >= 1.3.1801
[14:26] <dandrader> Saviq, ltinkl, but kbdLayout hasn't been approved yet
[14:27] <Saviq> dandrader, well, it will be, before we land it, hopefully
[14:27] <dandrader> Saviq, ltinkl, what I mean is that it's still subject to change, not a good branch to have as a prereq
[14:28] <dandrader> Saviq, ltinkl, so I still think it better to follow the seniority order
[14:29] <Saviq> dandrader, TBH I'd rather wait for kbdLayout to get approved instead of doing the rebase dance again
[14:29] <Saviq> it's not git :P
[14:29] <Saviq> dandrader, but, what we can do, is extract the debian/ changes and API bumps to a separate MP
[14:30] <Saviq> as long as the actual code changes won't touch the same areas, they wouldn't need to be chained then
[14:31] <dandrader> Saviq, sounds messy
[14:31] <Saviq> dandrader, why?
[14:31] <dandrader> Saviq, "yet another branch"
[14:31] <Saviq> dandrader, better than chaining IMO
[14:33] <dandrader> Saviq, + dependencies between those split branches. having a hard time visualizing that. how to split the diff to avoid conflicts
[14:34] <tsdgeos> Saviq: ha ha, it passed here because i rebuilt my uitk with that patch and forgot about it :D
[14:34] <cimi> tsdgeos, will review after my lunch :)
[14:34] <Saviq> tsdgeos, right, so keeping it out, please add >= 1.3.1801
[14:35] <Saviq> dandrader, we maintain api-bump branches for unity-api, qtmir, unity8 under unity-team,
[14:35] <Saviq> dandrader, MPs requiring those changes will have those as prereq
[14:36] <Saviq> dandrader, as we go, we bump things in the api-bump branches, but subsequent code MPs don't need to prereq each other
[14:36] <tsdgeos> Saviq: done
[14:36] <Saviq> unless they really touch code close to one another, at which point we're in the position we're in today, and have to chain
[14:37] <Saviq> dandrader, but until then we can relatively freely juggle MPs that will land together
[14:38] <Saviq> tsdgeos, do we care about https://codereview.qt-project.org/#/c/143073/ ?
[14:39] <tsdgeos> Saviq: doesn't seem critical i'd say, nice to have sure
[14:39] <cimi> tsdgeos, ok on it
[14:40] <Saviq> tsdgeos, Timo was asking if it was us, but I don't remember having asked for it
[14:40] <Saviq> likely SDK team
[14:40] <Saviq> dandrader, I can prepare a set of branches doing that across the ones we're talking about now to see how it'd work
[14:41] <tsdgeos> Saviq: yeah don't think it was us
[14:42] <dandrader> Saviq, still don't see how having yet more interdependent branches will help. but if you wanna do it...
[14:43] <dandrader> Saviq, I probably didn't understand your plan...
[14:43] <Saviq> dandrader, we have initial geom, kbdlayout, sizehints today
[14:43] <Saviq> dandrader, as it stands, we need to make them all a chain
[14:44] <dandrader> Saviq, which is ok
[14:44] <dandrader> Saviq, it's like having a virtual staging branch
[14:44] <Saviq> dandrader, except for when we need to bump one of them from the list when we discover an issue
[14:44] <Saviq> dandrader, un-chaining them is a chore (as is chaining them, for that matter)
[14:45] <dandrader> Saviq, it's like having to revert something from a staging branch
[14:45] <Saviq> dandrader, with "distilling" the conflicts (usually debian/ and API bumps) into a separate MP, we can just skip some without the need to modify the rest
[14:45] <Saviq> dandrader, also, maintaining the chain is a pain unless we put them all under unity-team since we have to merge trunk through it in case of conflicts
[14:46] <Saviq> otherwise we need to wait for whoever owns the branch
[14:47] <dandrader> Saviq, the root cause being that it takes too long to release, so we have way too many branches piling up
[14:48] <Saviq> dandrader, maybe, but I don't see it getting quicker any time soon
[14:48] <dandrader> Saviq, maybe a staging would help with that, as merging an MP into the staging branch should take much less time.
[14:48] <Saviq> dandrader, with the staging approach I'm after, I won't allow branches relying on other projects into staging anyway
[14:49] <Saviq> unless I can find that actually reverting on staging is relatively doable
[14:50] <dpm> hi all, I was wondering if someone could help wit a unity 8 session related question:
[14:50] <dpm>  I installed unity8-desktop-session-mir to dogfood unity 8 on the desktop (16.04) and how convergent apps behave
[14:50] <dpm>  I can choose the session and log into unity 8 via lightdm
[14:50] <dpm>  then the scopes window is shown
[14:51] <dpm>  however, when I click on an app, it's shown for a split second and then exits
[14:51] <Saviq> mzanetti, tsdgeos, shall I add https://code.launchpad.net/~mzanetti/unity8/launcher-sizing/+merge/280149 ?
[14:51] <dpm> it happens to all apps
[14:51] <Saviq> dpm, install cgmanager...sthg (known dependency bug, should be fixed soon)
[14:51] <tsdgeos> Saviq: afaics it doesn't merge, so it won't build, no?
[14:51]  * Saviq finds the right package name
[14:51] <Saviq> tsdgeos, just asking :)
[14:51] <dpm> Saviq, ah, cool, thanks, will try that later on this evening
[14:52] <mzanetti> Saviq, pelase
[14:52] <mzanetti> Saviq, I will merge things now
[14:53] <mzanetti> Saviq, but this one is a big one, it will conflict with every upcoming branch, so the earlier the better
[14:53] <Saviq> dpm, ah! bug #1535058
[14:53] <ubot5`> bug 1535058 in ubuntu-app-launch (Ubuntu) "applications close instantly when launched from the launcher or dash" [High,In progress] https://launchpad.net/bugs/1535058
[14:53] <Saviq> dpm, install libpam-cgm
[14:55] <Saviq> mzanetti, and launcher-updates
[14:55] <mzanetti> yep
[14:55] <Saviq> mzanetti, we've no settings UI for sizing or autohide yet, do we?
[14:56] <mzanetti> Saviq, no, I pinged ken about it, but he didn't reply... let me try to ping again
[14:56] <dpm> Saviq, actually, libpam-cgm is already installed, but I'll look at the bug comments in more detail
[14:57] <Saviq> dpm, ack, note that it's still not a good experience on a mixed click/deb system, you need to manually install .clicks and such
[14:57] <Saviq> mzanetti, do we have a bug for ↑ do you know?
[14:58] <dpm> Saviq, meaning that apps installed as .deb are not supposed to be startable on the unity 8 session?
[14:58] <dpm> I don't have any clicks, as they're not installable and won't be afaik
[14:58] <mzanetti> Saviq, the bug you linked, no?
[14:58] <Saviq> mzanetti, for clicks vs. deb
[14:58] <mzanetti> dpm, debs should work too I believe
[14:58] <Saviq> dpm, of course they will be
[14:59] <mzanetti> Saviq, no, clicks are not and I don't think that will change any time
[14:59] <Saviq> mzanetti, on a desktop unity8 session?
[14:59] <mzanetti> yeah
[14:59] <Saviq> what's it useful for, then/
[14:59] <Saviq> mzanetti, the store has to be functional there, why not?
[14:59] <dpm> Saviq, it will be, but with snappy
[15:00] <Saviq> oh well, .clicks, .snappy, potato, potahto
[15:00] <mzanetti> problem is that polkit/pkcon/dpkg bail out on it. I've reported a bug 2 years ago and pinged all sorts of managers. Eventually I got the reply that this is not working intentionally beause we can't guarantee the confinement promises of clicks
[15:00] <ubot5`> Error: Launchpad bug 2 could not be found
[15:00] <tsdgeos> ;D
[15:00] <mzanetti> I believe this is nuts and is probably just an excuse to not have to spend someones time to fix the polkit stuff for it
[15:01] <mzanetti> anyhow, that is as far as I could get
[15:01] <mzanetti> you can still manually force install them
[15:01] <Saviq> mzanetti, that's bshit
[15:01] <mzanetti> I know... but well, I tried for a long time
[15:01] <mzanetti> you might retry with your manager powers now
[15:01] <mzanetti> let me find the bug report
[15:02] <Saviq> thanks
[15:03] <dpm> I'm still not sure I follow what the issue with .debs on that bug report is
[15:03] <mzanetti> Saviq, https://bugs.launchpad.net/ubuntu/+source/click/+bug/1396611
[15:03] <ubot5`> Launchpad bug 1396611 in click (Ubuntu) "Can't install click packages with pkcon" [Undecided,Confirmed]
[15:07] <Saviq> mzanetti, I'm bumping https://code.launchpad.net/~unity-team/indicator-display/usage-mode/+merge/284730 from the silo then?
[15:07] <mzanetti> Saviq, why?
[15:07] <Saviq> mzanetti, because we don't wanna land it, and we do wanna land the silo
[15:08] <mzanetti> ooh, I thot this would be the MWC silo
[15:08] <mzanetti> in that case, sure, drop it, and the other I added too
[15:08] <mzanetti> ~mzanetti/unity8/better-windowed-logic
[15:08] <mzanetti> that's not ready for landing yet
[15:08] <mzanetti> Saviq, ^
[15:08] <Saviq> mzanetti, ack
[15:08] <mzanetti> Saviq, do we have a silo for MWC then?
[15:09] <Saviq> mzanetti, not yet, but we won't really need one for a week or two
[15:09] <mzanetti> Saviq, it would make things easier to test I think. I'll get started with one then
[15:15] <cimi> tsdgeos, I'd go for the code of my comment, I like it :D
[15:16] <tsdgeos> cimi: makes it harder to read, but whatever
[15:17] <cimi> tsdgeos, harder is relative :D
[15:17] <tsdgeos> of course
[15:17] <Saviq> @unity: if your branch is not top-acked, but should land in our next landing (and is not in silo 51 already https://requests.ci-train.ubuntu.com/#/silo/051), please let me know
[15:17] <tsdgeos> that's why i said "whatever"
[15:18] <cimi> tsdgeos, we can also put radius width / 2 too
[15:18] <cimi> tsdgeos, usually it's what people write when they mean a circle
[15:20] <tsdgeos> cimi: pushed
[15:22] <mzanetti> tsdgeos, merged launcher-updates
[15:22] <cimi> tsdgeos, stylistic changes :D polite :D
[15:22] <cimi> tsdgeos, better than cimi's nonsense :D
[15:23] <Saviq> let the Conflict Olympics begin!
[15:23] <Saviq> oh just 33 MPs this time :P
[15:23] <mzanetti> pff... easy
[15:23] <tsdgeos> mzanetti: ok
[15:23] <ltinkl> in bzr case it's rather paralympics
[15:24] <cimi> lol ltinkl
[15:24] <cimi> tsdgeos, approved, waiting for ci to top approve
[15:25] <mzanetti> still better than the black magic you get when you put git on it... I'd end up in a "you are now in detached head state and can never got back" all the time
[15:28] <tsdgeos> mzanetti: you also fixing launcher-sizing ?
[15:30] <cimi> tsdgeos, we can top approve https://code.launchpad.net/~cimi/unity8/more_stable_lazy_image_test/+merge/284708
[15:31] <tsdgeos> done
[15:34] <mzanetti> tsdgeos, launcher-sizing merged
[15:41] <tsdgeos> mzanetti: depending on how we do the merging lp:~mzanetti/unity8/spread-visual-updates also fails to merge (directly against trunk), but i guess that if do all the merges of prerequisties in order it'll work
[15:45] <Saviq> tsdgeos, that shouldn't be possible in theory, should it? assuming the top-most branch has all the changes from the previous ones
[15:46] <tsdgeos> Saviq: ok
[15:58] <mzanetti> mterry, ltinkl: the OOBE meeting happening? want me there?
[15:59] <ltinkl> mzanetti, I guess we'll be fine
[15:59] <mterry> mzanetti, I want you in ALL my meetings :)  But yeah I bet we can do it
[15:59] <mzanetti> hah
[15:59] <mzanetti> I can surely join, no prob... just don't wanna be a pain with my comments if you guys think you're set
[17:06] <Saviq> dandrader, check out the top-four ~unity-team branches here https://code.launchpad.net/unity-api
[17:06] <Saviq> dandrader, this is what I propose for the api bump changes, that breaks the ~artificial prereq between initialSurfaceGeom and kbdLayouts
[17:07] <Saviq> in this case kbdLayouts still conflict with surfaceItemSizeHints, but that's more natural than prereq'ing because of changelog
[17:08] <Saviq> the api-bump doesn't even need to be a prereq for the others, with the caveat that it would "miss" the version and CMake bumps, which, you could say, is a bad thing
[17:08] <Saviq> so we could make it prereq after all
[17:10] <Saviq> dandrader, in any case, updating the changelog and CMakeLists accordingly would be a topic for landing, contained in that one MP instead of spread across all the separate MPs
[17:12] <dandrader> Saviq, so you're saying you want to strip all MPs of debian/changelog entries and version bumps? I'm fine with that.
[17:12] <dandrader> Saviq, it's the stuff of landing/releasing indeed
[17:13] <Saviq> dandrader, the CMakeLists.txt bumps are indeed debatable
[17:13] <Saviq> dandrader, as they will most likely conflict every time if they touch the same API
[17:13] <dandrader> Saviq, I say CMakeLists.txt version bumps fall into the same category
[17:14] <Saviq> dandrader, ack, so we're in violent agreement, this leaves you guys to work on actual code changes, and paperwork happens at release time
[17:15] <dandrader> Saviq, ok, so I should remove deban/changelog, debian/control and CMakeLists.txt version bumps from my MPs then?
[17:16] <Saviq> dandrader, just resubmit your branches with the ones I did, with api-bumps as prereq
[17:16] <Saviq> for unity-api that is
[17:16] <Saviq> dandrader, for others (unity8, qtmir), please strip the relevant changes, yes
[17:16] <Saviq> /away
[17:17] <dandrader> Saviq, having api-bumps as prereq looks weird
[17:17] <dandrader> Saviq, to me it looks like api-bumps should be the lid at the top of them all, not the base
[17:18] <Saviq> dandrader, ack, fine by me (only this means that commits are not "releasable" by themselves, but meh)
[17:21] <dandrader> Saviq, if I resubmit I gonna lose the approvals. can't I just remove the changes in order to keep those approvals?
[18:08] <dandrader> Saviq, removed version bumps and changelog entries from all initialSurfaceGeom branches (unity-api, qtmir and unity8)
[19:27] <josharenson> Do any of you use vim + YouCompleteMe?  I can't figure out how to work around this https://bugs.launchpad.net/ubuntu/+source/vim-youcompleteme/+bug/1538532  I've tried building vim with python2 enabled, but it still isn't working...
[19:27] <ubot5`> Launchpad bug 1538532 in vim-youcompleteme (Ubuntu) "Broken in Xenial, vim requires python3 now" [Undecided,Confirmed]
[19:39] <mterry> Saviq, you suggest in bug 1540497 to "just react to clicks on Unlock" -- that's the proposed temp fix until ubuntu-ux gets back to us?  So just the little "unlock" area on the bottom, to make it clickable?  And probably look like a button.  Which would just swipe away the top layer and show the pin/passcode entry
[19:39] <ubot5`> bug 1540497 in Canonical System Image "No way to unlock narrow greeter with a mouse" [Critical,Triaged] https://launchpad.net/bugs/1540497
[20:29] <Saviq> mterry, fwiw the whole surface could react to clicks...
[20:29] <Saviq> (but not to taps!)
[20:33] <Saviq> mzanetti_, please put lp:~mzanetti/unity8/edgebarrier-click-transparent on top of launcher sizing
 mterry, fwiw the whole surface could react to clicks...
[20:33] <Saviq>  (but not to taps!)
[20:37] <mterry> Saviq, OK.  (just as a short-term fix right?)
[20:39] <mterry> Saviq, when a mouse is attached, we actually always use the wide view greeter, regardless of width.  In which case there should be a text prompt / login button...  I need to re-do the bug steps and see what actually happening
[21:05] <Saviq> mterry, not any more
[21:05] <mterry> Saviq, ah interesting
[21:05] <Saviq> mterry, we released yesterday a change where it needs to be more than 90GU long on the short edge
[21:05] <mterry> ah
[21:18] <mzanetti_> Saviq, I've merged it, but I found a test failure, will look at it in a few. need to put the baby to bed
[21:39] <mterry> mzanetti_, what's the best way to distinguish between a mouse click and a touch click?
[21:46] <mzanetti_> mterry, for what?
[21:47] <mterry> mzanetti_, I was looking at a short-term fix for bug 1540497 (hide greeter cover page on a mouse click but NOT a touch)
[21:48] <ubot5`> bug 1540497 in Canonical System Image "No way to unlock narrow greeter with a mouse" [Critical,Triaged] https://launchpad.net/bugs/1540497
[21:49] <mzanetti_> mterry, ah, options are: something like InputKeysFilter and emit the appropriate signals, or a MouseArea and a MultipointTouchArea
[21:49] <mhall119_> jhodapp: ping about aethercast
[21:50] <jhodapp> mhall119_, pong
[21:50] <mhall119_> jhodapp: hey, I'm following the instructions on https://wiki.ubuntu.com/Touch/DisplayCasting
[21:51] <mhall119_> and it finds my roku/tv, but when I try to connect to it I get Failed to connect with device: GDBus.Error:org.freedesktop.DBus.Error.Failed: Operation failed
[21:51] <jhodapp> mhall119, yeah it's not really that robust in connecting yet
[21:51] <jhodapp> mhall119, try again
[21:52] <jhodapp> mhall119, sometimes it'll work after the 2nd or 3rd time
[21:52] <mzanetti_> jhodapp, apart from connecting, what's the state there? somewhat functional?
[21:52] <mterry> mzanetti_, ah thanks :)
[21:52] <mhall119> I've tried 3 or 4 times, same thingaethercastctl> info ae:b5:7d:5e:ad:21
[21:52] <mhall119> Address: ae:b5:7d:5e:ad:21
[21:52] <mhall119> Name: Mike & Michelle Bonus Room TV
[21:52] <mhall119> State: failure
[21:52] <mhall119> Capabilities:
[21:52] <mzanetti_> jhodapp, asking because I need to build something on top of it when it's stable enough, and I haven't checked in a while
[21:52] <jhodapp> mzanetti_, it'll utilize software encoding in the version in that silo, so you'll get very very slow video
[21:52] <mhall119> I've tried a half dozen times now
[21:53] <jhodapp> mhall119, ok, best to ask morphis tomorrow then...he wrote the connecting part
[21:53] <mhall119> ok, thanks
[21:53] <mzanetti_> mhall119, last time I tried it had issues with 5GHz, would only work with devices that only have 2.4
[21:53] <mhall119> oh, hmmm....
[21:54] <mzanetti_> but it's been a while now, so not sure if that's still accurate
[21:54] <jhodapp> mhall119, also, you can try sudo service aethercast; sudo aethercast -d
[21:54] <jhodapp> mhall119, you'll see the debug output then
[21:54] <mhall119> well I'm on 2.4
[21:54] <jhodapp> mhall119, oops add a stop in there
[21:55] <jhodapp> mhall119, morphis will want to see that debug output
[21:58] <mhall119> [DD 2016-02-02 21:57:36] [p2pdevicestub.cpp:300@Connect]
[21:58] <mhall119> [DD 2016-02-02 21:57:36] [p2pdevicestub.cpp:305@Connect] path /fi/w1/wpa_supplicant1/Interfaces/1/Peers/aeb57d5ead21
[21:58] <mhall119> [DD 2016-02-02 21:57:36] [miracastservice.cpp:298@OnDeviceStateChanged] Device state changed: address ae:b5:7d:5e:ad:21 new state association
[21:58] <mhall119> [DD 2016-02-02 21:57:36] [networkmanager.cpp:177@StartConnectTimeout]
[21:58] <mhall119> [DD 2016-02-02 21:57:36] [p2pdevicestub.cpp:127@OnGONegotiationFailure]
[21:58] <mhall119> [DD 2016-02-02 21:57:36] [networkmanager.cpp:423@OnGroupOwnerNegotiationFailure] peer /fi/w1/wpa_supplicant1/Interfaces/1/Peers/aeb57d5ead21
[21:58] <mhall119> [DD 2016-02-02 21:57:36] [miracastservice.cpp:298@OnDeviceStateChanged] Device state changed: address ae:b5:7d:5e:ad:21 new state failure
[21:58] <mhall119> seems like maybe it doesn't like my roku
[21:59] <mhall119> which does say that screen mirroring is a beta feature
[21:59] <mhall119> so, maybe it's just my TV
[22:07] <mhall119> which would be disappointing
[22:18] <mzanetti_> Saviq, resubmitted: https://code.launchpad.net/~mzanetti/unity8/edgebarrier-click-transparent/+merge/284806
[22:20] <Saviq> mzanetti_, tx
[22:20] <mzanetti_> Saviq, I've updated the silo
[22:20] <Saviq> mterry, we've magic options on MouseArea and MultiPointTouchArea to deal with that
[22:20] <mhall119> jhodapp: do you know if the phone will act like a touchpad/keyboard when connected via aethercast, or does it just literally mirror the display?
[22:21] <mzanetti_> Saviq, yeah, but if you need both, you need two of them. not sure if a custom evenfilter in a simple QObject wouldn't be better
[22:21] <mterry> Saviq, I see tthe one on MultiPoint, but not on MouseArea.  Looks like I have to stack them?
[22:22] <mterry> mzanetti_, I just went with the stacked MouseArea way.  You think the eventfilter is cleaner?
[22:22] <mzanetti_> well, it's not many of them... so... either works for me I guess
[22:23] <Saviq> mzanetti_, we probably should make it easier in our SDK, have a component that will do both and let you decide what to do on each
[22:23] <mzanetti_> thinking if there are other areas where we need to use stacked areas... if we use that more often I'd definitely create some sort of mousearea that has different signals for both
[22:23] <mzanetti_> yeah
[22:25] <Saviq> mterry, kalikiana had a talk about that on FOSDEM https://fosdem.org/2016/schedule/event/converged_desktop_experience/ - there's a link to the slides
[22:25] <Saviq> page 12
[23:03] <jhodapp> mhall119, it'll act exactly like it does via HDMI today, it'll mirror the virtual display port that shows a full desktop in convergence mode
[23:55] <mhall119> jhodapp: awesome, that means I'll be able to go full convergence without cables or accessories