[08:08] <tsdgeos> Saviq: our ci stuff is again borked?
[08:08] <tsdgeos> https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-utopic/1518/console ?
[08:09] <Saviq> tsdgeos, lookin'
[08:09] <Saviq> ugh, someone added a bad hook ERROR:pbuilderjenkins:H10strip_native_depends not found in hooks
[08:10] <Saviq> at least for that job
[08:11] <tsdgeos> it's similar to the other errors i've seen
[08:23] <mzanetti> kgunn: hmmm. I'm sure I saw an option to enable that in the system settings at some point
[09:06] <Saviq> tsdgeos, dude, ETOOMANYPHONES :P
[09:06] <tsdgeos> sorry ^_^
[09:15] <mzanetti> Saviq: do we have more details on this one now? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1378092
[09:15] <ubot5> Ubuntu bug 1378092 in unity8 (Ubuntu) "Dialer-app is getting sigstopped on greeter mode." [Critical,Triaged]
[09:15] <mzanetti> should it just be closed?
[09:17] <Saviq> let me try and repro
[09:20] <Saviq> mzanetti, yeah, fixed
[09:20] <mzanetti> Saviq: I really wonder why though :D
[09:20] <mzanetti> Saviq: when reproducing with an older image it seems to totally mess up the window stack
[09:21] <mzanetti> i.e. parts of the right edge animation have wrong z
[09:27] <Wellark> mzanetti: you didn't top approve the unity8 branch of dual sim unlocking..
[09:28] <Wellark> is there still something to do with it?
[09:31] <mzanetti> Wellark: I think I did
[09:32] <mzanetti> Wellark: now I top-approved too. forgot that before
[09:34] <Wellark> mzanetti: thanks!
[10:45] <dandrader> Cimi, how do I get to the welcome wizard?
[10:45] <Cimi> dandrader, rm /home/phablet/.config/ubuntu-system-settings/wizard-has-run
[10:45] <Cimi> dandrader, or somethings similar...
[10:46] <dandrader> ok
[10:47] <greyback> tsdgeos: with a little finger mashing, I managed to get this: http://imgur.com/rW6F5oo
[10:48] <greyback> the entire lvwph is frozen now, but I can bring up the scopes view with a bottom edge swipe still
[10:55] <tsdgeos> greyback: what branch is that? regular master?
[10:57] <greyback> tsdgeos: yeah. I just imaged my device with today's devel-proposed and played
[10:57] <tsdgeos> greyback: ouch
[10:57] <tsdgeos> greyback: so the list is totally dead?
[10:58] <greyback> tsdgeos: I was being a jerk though :) But the finger mashing test is good sometimes
[10:58] <greyback> tsdgeos: yeah
[10:58] <greyback> I just now tried to open the video scope via the scopes view thingy, and now the whole UI is frozen
[10:58] <greyback> am working on a backtrace
[11:03] <tsdgeos> greyback: looks as if the fix dandrader did for touch vs mouse clicks didn't really fix everything maybe?
[11:03] <tsdgeos> greyback: since the bottom edge is touch and the rest is mouse
[11:03] <greyback> tsdgeos: that's a possibility
[11:03] <tsdgeos> dandrader: seen the comment i made on touchOwnership?
[11:04] <mzanetti> Wellark: hmm... I think I found an issue
[11:06] <dandrader> tsdgeos, will get to it in a bit
[11:07] <tsdgeos> k
[11:07] <greyback> dandrader: tsdgeos: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1378760
[11:07] <ubot5> Ubuntu bug 1378760 in unity8 (Ubuntu) "[dash] managed to get listview stuck with pull to refresh exposed" [Undecided,New]
[11:10] <dandrader> didn't know we had this "pull to refresh" feature...
[11:10] <dandrader> greyback, what's a "stable device"?
[11:12] <greyback> dandrader: anything I can do while I have the process running in this state?
[11:14] <dandrader>  greyback does the bottom edge swipe to show dash overview still work?
[11:14] <greyback> dandrader: no
[11:15] <tsdgeos> pull to refresh does really nohing since it just piggy backs on the list dragging
[11:15] <dandrader> hmm, then it doesn't seem to be an issue of missing touch events
[11:15] <tsdgeos> greyback: where are you now at a scope?
[11:16] <greyback> tsdgeos: stuck in scope view now
[11:16] <dandrader> greyback, is unity8-dash running in the first place?
[11:17] <dandrader> (who knows, might be suspended)
[11:17] <greyback> dandrader: yes it was running
[11:17] <tsdgeos> greyback: and left and right edges work, no?
[11:17] <greyback> darn I managed to kill it
[11:17] <greyback> tsdgeos: yes unity8 itself was fine
[11:18] <Wellark> mzanetti: ?
[11:18]  * Wellark goes lalala
[11:18] <mzanetti> Wellark: https://code.launchpad.net/~unity-api-team/indicator-network/dual_sim_pin_unlock/+merge/237386/comments/582527
[11:18] <Wellark> mzanetti: don't call it
[11:18] <Wellark> mzanetti: the "unlockallmodems" bug was withdrawn from this MP
[11:19] <mzanetti> Wellark: is there a replacement?
[11:19] <greyback> dandrader: tsdgeos: managed to reproduce it again
[11:19] <mzanetti> Wellark: the dialer app uses it afaik
[11:19] <Cimi> if we do opacity: !hidden instead opacity: hidden ? 0.0 : 1.0 ??
[11:20] <greyback> it takes a minute or two of 3 finger messing
[11:20] <tsdgeos> greyback: :/ i tried and could get it to fail
[11:20] <Cimi> can we do those js tricks or is ugly?
[11:20] <facundobatista> Hola
[11:21] <greyback> Cimi: ugly, it easier to understand what you're doing with the  ? 1 : 0 there
[11:21] <mzanetti> Cimi: I personally don't like such things
=== MacSlow is now known as MacSlow|lunch
[11:23] <greyback> hmm, unity8-dash is continually creating & destroying a thread
[11:24] <Wellark> mzanetti: nope, the dialer app does not use it
[11:24] <mzanetti> managed to reproduce the stuck dash too
[11:24] <Wellark> mzanetti: as it's not working
[11:24] <mzanetti> Wellark: so what's the plan with that?
[11:24] <Wellark> mzanetti: https://bugs.launchpad.net/indicator-network/+bug/1374082
[11:24] <ubot5> Ubuntu bug 1374082 in indicator-network (Ubuntu) "no API to unlock a specific sim" [High,Triaged]
[11:25] <mzanetti> Wellark: right... in unity we'd still need to unlock all though
[11:25] <Wellark> mzanetti: I'm aware of that
[11:25] <mzanetti> ok
[11:26] <Wellark> mzanetti: there's only one me, so I can't fix everything at the same time ;)
[11:26] <Wellark> mzanetti: it will be there
[11:28] <mzanetti> greyback: tsdgeos: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1378760/comments/4
[11:28] <ubot5> Ubuntu bug 1378760 in unity8 (Ubuntu) "[dash] managed to get listview stuck with pull to refresh exposed" [Undecided,New]
[11:28] <mzanetti> Wellark: ack
[11:29] <greyback> mzanetti: nice
[11:30] <tsdgeos> mzanetti: that has nothing to do with greyback's bug though
[11:30] <tsdgeos> mzanetti: since it recovers nicely (or at least does for me)
[11:30] <mzanetti> oh...
[11:31] <tsdgeos> mzanetti: does it recover for you?
[11:31] <mzanetti> yes... it recovers with more interaction..
[11:31]  * mzanetti tries harder
[11:31] <tsdgeos> i mean sure it's a bug that probably needs fixing
[11:31] <tsdgeos> but not as bad as what greyback said
[11:32] <greyback> yep, I managed to make it recover too
=== Malsasa_ is now known as Malsasa
[11:33] <mzanetti> greyback: I guess you can tell us if its the same or if yours is different :)
[11:33] <greyback> mzanetti: mine is different, as I cannot make it recover
[11:33] <greyback> bt
[11:35] <mzanetti> heh, works horizontally too
[11:36] <mzanetti> oh... now I have it stuck too
[11:54] <dandrader> tsdgeos, pushed your forceNonInteractive thing
[11:56] <dandrader> tsdgeos, also used status instead of currentStatus. the latter was created just to help fill up previousStatus.
[11:57] <tsdgeos> dandrader: can you merge to listOnBottomSwipe_touchOwnership and then request a build at https://code.launchpad.net/~unity-ui-team/+recipe/unity8-overviewlist ?
[11:57] <tsdgeos> have to run for food now
=== _salem is now known as salem_
=== Estilanda_ is now known as Estilanda
[12:41] <Wellark> mzanetti: you forgot to restore the top approved:
[12:41] <Wellark> mzanetti: https://code.launchpad.net/~unity-api-team/indicator-network/dual_sim_pin_unlock/+merge/237386
[12:42] <mzanetti> Wellark: I'm quite sure there wasn't one before
[12:42] <mzanetti> at least I didn't remove it
[12:42] <Wellark> mzanetti: oh, then charles forgot to add it
[12:43] <charles> Wellark, mzanetti, I left it out on purpose -- I didn't know if antti had more work/testing in the queue
[12:43] <charles> +1 on top approval though :)
[12:47] <dandrader> tsdgeos, done (PPA just started building though)
=== dandrader is now known as dandrader|afk
[12:47] <Wellark> charles: you could have just asked me, you know! :P
[12:47] <Wellark> charles: just top approve it
[12:48] <Wellark> charles: ok, seems jussi already did
[12:52] <tsdgeos> dandrader|afk: tx
=== dandrader|afk is now known as dandrader
=== MacSlow|lunch is now known as MacSlow
[13:22] <tsdgeos> Saviq: any chance we get the CI build fixed?
[13:28] <kgunn> MacSlow: noticing the vol notification come up in the welcome wiz showing mute, but i don't think it's correct...did you notice as well ?
[13:29] <MacSlow> kgunn, which image?
[13:29] <kgunn> dandrader: tsdgeos \o/ right edge so much better
[13:29] <kgunn> MacSlow: i'm on utopic devel-proposed
[13:29] <MacSlow> kgunn, not seen yet... being deep down with the swipe-to-act button atm
[13:29] <kgunn> MacSlow: no prob
[13:29] <tsdgeos> yeah on the volume notification i'd expect a bar
[13:30] <tsdgeos> not the speaker logo
[13:30] <tsdgeos> kgunn: there's a new build coming in a few mins that should fix a few small annoyances with the bottom edge
[13:30] <tsdgeos> kgunn: i will give it a final test and probably approve, would be cool if you could also test it
[13:30] <kgunn> MacSlow: actually, i don't wanna make you switch if you're in the middle...but i think some quality time with the max vol notfication would be in order
[13:31] <MacSlow> kgunn, tsdgeos: welll that's because two of the three related branches still in the review-pipe
[13:31] <kgunn> MacSlow: reason being, the max vol thing is legal requirement, whereas swipe to answer is user improvement....we can live with click-to-answer, but not w/o max vol notif
[13:31] <MacSlow> kgunn, tsdgeos: one (unity-notifications) is arleady top-approved... the other (unity8) needs another review (approval)
[13:32] <kgunn> and i fear it'll take time to sort out exactly what we're gonna do in a short amount of time
[13:32] <kgunn> cause i think it's gonna require alsa driver or audio DAC driver involvement
[13:33] <tsdgeos> vesar: did you have time to show the new bottom list to JMulholland and the guys? any feedback?
[13:33] <tsdgeos> kgunn: did you see my plethora of answers on the volume thing?
[13:34] <MacSlow> kgunn, regarding the max-volume issue, I think UI/UX is "tiny" compared to the needed foundational underpinnings making it possible
[13:34] <kgunn> tsdgeos: not yet, was bug scrubbing & updating this morning
[13:34] <Saviq> tsdgeos, nobody replied then, will pester
[13:34] <Saviq> tsdgeos, actually fginther is looking into that now
[13:34] <tsdgeos> kgunn: ok, basically there's 2 kinds, the ones that ask "you sure you want more" at 70/80% of volume, and the ones that do nothing
[13:34] <tsdgeos> Saviq: cool
[13:42] <mterry> dednick, looking at your review comments for the greeter-profiles branch.  I thought semicolons were passé?
[13:43] <mterry> We need some team style guidance on that, because we are half-and-half now
[13:43] <tsdgeos> dandrader: found two qmluitest failures in https://code.launchpad.net/~dandrader/unity8/touchOwnership/+merge/236152
[13:43] <dednick> mterry: hm. i've always been told to do them.
[13:43] <dednick> Saviq: ^ ?
[13:43] <dandrader> tsdgeos, commented. are you sure you used the latest version of touchOwnership?
[13:43] <dandrader> tsdgeos, I'm not getting this failure
[13:43] <Saviq> mterry, in JS we want ;
[13:43] <mterry> Saviq, !  OK, my bad
[13:44] <mterry> Saviq, except for one-liners I assume?
[13:44] <tsdgeos> dandrader: yeah, just pulled and make again
[13:44] <tsdgeos> nothing came out of it
[13:44] <mterry> Saviq, do we have a style page for the wiki yet?  That would be great
[13:44] <Saviq> mterry, yeah, if there's no code block/scope (a binding), that's not really JS
[13:44] <tsdgeos> dandrader: i can try make clean and start again
[13:44] <Saviq> mterry, this is the closest we got to defining it https://docs.google.com/a/canonical.com/document/d/1gd87Wo_CSB0DpFWLpTKIIXQfdmFncrq0PHSr9H2PTnk/edit
[13:45] <mterry> Saviq, it is JS though technically right?  Like you can do all the JS stuff just in one line
[13:45] <Saviq> mterry, technically yes
[13:45] <tsdgeos> dandrader: r1338, no?
[13:45] <dandrader> tsdgeos, yes
[13:46] <dandrader> tsdgeos, the tst_Shell failure happens also in trunk
[13:47] <tsdgeos> dandrader: does it?
[13:47] <dandrader> tsdgeos, try it
[13:49] <mterry> Saviq, OK linked that document from the Checklist wiki
[13:51] <tsdgeos> dandrader: ok, there's a path problem
[13:51] <mterry> dednick, another thing -- you rightly show concern about the async line -- if you've got your test device still, try manually adding that line back in -- the delay is quite profound and I think too noticable for this to land with async enabled
[13:51] <tsdgeos> dandrader: i have unity8 installed from the ppa and was "old", now that i dist-upgraded, the test passes
[13:51] <mterry> dednick, considering that once we have different greeter profiles, a common pattern is for a user to log in just to interact with the full indicator
[13:51] <dednick> mterry: ok. i'll give it a try
[13:51] <tsdgeos> dandrader: should prepend the local paths somewhere
[13:51] <dandrader> tsdgeos, you were running qmltest on the device?
[13:51] <tsdgeos> dandrader: no, on the pc
[13:52] <dednick> mterry: perhaps we need to think about loading multiple profiles :/
[13:52] <dandrader> tsdgeos, so you install the PPA on your PC?
[13:52] <tsdgeos> dandrader: i have it yes
[13:52] <dandrader> never thought someone would do this :)
[13:53] <dandrader> tsdgeos, "should prepend the local paths somewhere" <- didn't get it.
[13:53] <tsdgeos> dandrader: in the tests, you should make sure the local library is used and not the system one
[13:54] <tsdgeos> dandrader: i'm guessing it's the new lib you introduced
[13:55] <tsdgeos> dandrader: xvfbtestShell succeeds here in master
[13:56] <Saviq> tsdgeos, if we still get black photos in carousel (I'm checking if we do), that'd be unexpected after your sourceSize thingamajig (lol that's in my spell checking dictionary), right?
[13:57] <tsdgeos> Saviq: there was a thread about someone putting wrong exif info somewhere and thus resulting in black images
[13:57] <tsdgeos> not sure if it may be related
[13:57] <Saviq> tsdgeos, right, from the camera app?
[13:57] <tsdgeos> think so
[13:57] <dandrader> tsdgeos, you sure you have the latest lp:unity8 built and all?
[13:57] <tsdgeos> dandrader: pretty much
[13:58] <dandrader> Saviq, does "make xvfbtestShell" pass for you with lp:unity8?
[13:58] <Saviq> dandrader, checking
=== karni is now known as karni-snack
[13:59] <tsdgeos> dandrader: are you sure you have the latest lp:unity8 and all?
[13:59] <dednick> meh. batter dead :(
[14:00] <kgunn> charles: aiui, the checkable-bindings branch is needed, but doesn't completely solve the bug
[14:00] <kgunn> per  your comment there
[14:01] <dandrader> tsdgeos, yes. but I don't have unity8 installed in my system, unlike you
[14:01] <charles> kgunn, I figured as much, so I left it as a comment instead of needs-fixing
[14:01] <Saviq> kgunn, is there a reason why you committed the last release to rtm-14.09 like this https://code.launchpad.net/~unity-team/unity8/rtm-14.09 ?
[14:01] <Saviq> kgunn, can I overwrite with current trunk?
[14:01] <dandrader> tsdgeos,  if that makes any difference...
[14:01] <kgunn> charles: rock on
[14:01] <charles> kgunn, just as long as the problem doesn't get dropped when checkable-bindings lands
[14:01] <charles> kgunn, :-)
[14:01] <kgunn> charles: nope, dednick already on it
[14:01] <kgunn> (i think :)
[14:02] <charles> dednick, rock on
[14:02] <kgunn> Saviq: did i do something wrong ?
[14:02] <Saviq> kgunn, I usually just push trunk to rtm-14.09 after stuff landed in trunk
[14:02] <kgunn> Saviq: while you were out, seb was climbing up my back side asking me to merge trunk to it
[14:03] <kgunn> Saviq: yeah, i only did it once...
[14:03] <tsdgeos> dandrader: it shouldn't but it may as we've already seen
[14:03] <Saviq> kgunn, basically `bzr push -d lp:unity8 -r 8.00+14.10.20141006-0ubuntu1 lp:unity8/rtm-14.09`
[14:03] <kgunn> Saviq: got it....not merge...you push
[14:03]  * kgunn notes for future
[14:04] <kgunn> mzanetti: ^
[14:04] <Saviq> kgunn, which would take tag 8.00... from lp:unity8 and put it there
[14:04] <Saviq> and it won't even need overwrite, as it has the same history (in general, now it will because of your merge)
[14:05] <kgunn> sorry :-/
[14:05] <kgunn> Saviq: can you revert ?
[14:05] <Saviq> kgunn, just an --overwrite away
[14:05] <Saviq> kgunn, already done
[14:05] <mzanetti> hmm... I thought that would happen automatically when releasing to rtm using the train
[14:05] <Saviq> kgunn, no need to be sorry
[14:05] <kgunn> Saviq: ah so one time penalty of time
[14:05] <Saviq> mzanetti, nope, train has no knowledge of the rtm branch
[14:06] <Saviq> mzanetti, it will soon, when the two diverge and we'll start cherry-picking from trunk to rtm
[14:06] <Saviq> mzanetti, but then there will be no syncing in rtm silos, but MPs as usual
[14:06] <mzanetti> Saviq: right... I guess we should start doing that now...
[14:06] <Saviq> mzanetti, let's see when the floodgates are closed, that's when we'll start
=== karni-snack is now known as karni
[14:23] <kgunn> Saviq: can i ask for some priority love on this one? figure you'll wanna review before top approving
[14:23] <kgunn> https://code.launchpad.net/~josharenson/unity8/better_snap_decision_fix/+merge/237485
[14:23] <kgunn> small at least
[14:25] <Saviq> kgunn, kk
[14:28] <dandrader> Saviq, so, did the test pass?
[14:29] <Saviq> dandrader, ugh, distracted, sorry, built now, running it
[14:30]  * Saviq had some /boot trouble
[14:36] <dednick> mterry: what kind of delay are we talking about here? 1-2 seconds to populate if you open IMMEDIATELY after you switch from greeter?
[14:36] <mterry> dednick, yeah about
[14:36] <mterry> dednick, but I figure that that's going to be common
[14:36] <mterry> dednick, like if you can't see your events or whatever
[14:36] <mterry> dednick, you log in with the intention of immediately going to the menu
=== gatox is now known as gatox_lunch
[14:58]  * mterry starts reviewing all the branches so only mine are left for others to review
[15:00] <dednick> mterry: :/ https://dl.dropboxusercontent.com/u/85539674/greeter-indicators.png
[15:00] <mterry> dednick, is that without the silo?
[15:00] <Saviq> dandrader, yeah, xvfbtestShell passed:
[15:01] <dednick> mterry: that is with the silo
[15:01] <Saviq> Totals: 21 passed, 0 failed, 0 skipped
[15:01] <mterry> dednick, indicator-transfer in utopic has a bug where it shows the datetime UI in greeter mode
[15:01] <mterry> dednick, but you don't have a transfer icon in that screenshot either...
[15:01] <mterry> dednick, I'm suspicious
[15:01] <MacSlow> mterry, which branches do you want to be looked at?
[15:01] <mterry> MacSlow, mine in https://code.launchpad.net/unity8/+activereviews
[15:01] <dednick> mterry: and there are 2 datetimes
[15:02] <mterry> MacSlow, well any of them.  But *I* want mine looked at  :)
[15:02] <MacSlow> mterry, I know that feeling :)
[15:02] <mterry> dednick, yes because transfer shows datetime UI in greeter mode (as a bug -- if you look at it's indicator keyfile, it has a typo and shows the wrong object path)
[15:02] <mterry> dednick, that's fixed in the silo
[15:02] <mterry> dednick, which is why I'm suspicious you are running the silo
[15:03] <dednick> hm. should be using silo
[15:05] <dednick> mterry: i think the ppa has older version than is available.
[15:06] <mterry> dednick, then you can edit /usr/share/unity/indicators/com.canonical.indicator.transfer manually and fix the typo
[15:06] <dandrader> tsdgeos, ahhhh, finally found the cause of the mistery. my local lp:unity8 branch has a pending merge.  and bzr pull still works fine even it you have a merge pending!
[15:06] <dandrader> phew!
[15:07] <dednick> mterry: yup. did already
[15:08] <tsdgeos> lol this is bad
[15:08] <tsdgeos> open the clock app
[15:08] <tsdgeos> clock app takes 70%
[15:08] <tsdgeos> but not only that
[15:08] <mterry> ted, I thought the transfer indicator was fixed in your greeter profile silo?
[15:08] <tsdgeos> untiy8 takes 30% cpy
[15:08] <tsdgeos> why?
[15:09] <ted> mterry, Should be…
[15:09] <mterry> ted, I think maybe the silo just needs a rebuild then to get back above utopic
[15:10] <ted> mterry, Yeah, working on that. merge conflicts.
[15:11] <tsdgeos> ah because unity8 is the display server
[15:11] <tsdgeos> so that 30% is actually mir?
=== Estilanda_ is now known as Estilanda
[15:19] <dednick> mterry: hm. ok, there doesnt really seem to be that much lag to me, but the lag introducedin sync mode is pretty bad i think.
[15:19] <dednick> I think the lag with async will be reduced when my new indicator branch lands. The menu is actually at 0 height when you drag it, so i think the items are being loaded "only as visible". The new panel page is always the same height so the items will be loaded immediately.
[15:22] <tsdgeos> dandrader: so it fails/works for you now?
[15:24] <dandrader> tsdgeos, yeah, now it passes in lp:unity8. working on a fix for it in touchOwnership
[15:24] <tsdgeos> dandrader: \o/
[15:24] <dandrader> :)
[15:27] <dednick> mterry: just commented on your branch
[15:36] <kgunn> mterry having an internet day
=== dandrader is now known as dandrader|lunch
=== gatox_lunch is now known as gatox
=== dandrader|lunch is now known as dandrader
=== alan_g is now known as alan_g|EOD
[17:40] <mterry> dednick, I assume you didn't get my reply an hour ago -- I had awful internet
[17:41] <mterry> dednick, back in a cafe
[17:51] <racarr> Does anyone understand what is up with the qtmir-gles stuff and the "twin packages"
[17:51] <racarr> I wonder if its related to the struggle I am having with building qtmir-desktop on armhf in CI
[17:51] <racarr> ...with cmake
[17:52] <racarr> thats a lot of qualifiers lol
[17:53] <kgunn> racarr: i think bregma knows
[17:53] <greyback_> racarr: Qt has a compile time choice to use DesktopGL or GLES. The results are ABI incompatible. So we've 2 version of Qt in the repos
[17:54] <greyback_> as result, we need separate version of qtmir to compile against the Qt with GL, and the Qt with GLES
[17:57] <racarr> greyback_: I guess I thought thats what qtmir-android v. qtmir-desktop?
[17:57] <racarr> was
[17:58] <bregma> is there a binary package called qtmir-gles?  Not that I can see in the Ubuntu archives.
[17:59] <greyback_> there isn't
[17:59] <racarr> ok so the binary package is qtmir-android
[17:59]  * greyback_ got confused, has to look it up again
[18:00] <racarr> my main problem is I don't understand how qtmir-desktop is building on armhf
[18:00] <racarr> as it stands.
[18:00] <racarr> e.g. ifyou try and build qtmir-desktop and qtmir-android fromt hesame
[18:00] <racarr> build dependencies
[18:00] <racarr> wont qtmir-desktop be linked against
[18:01] <racarr> Qt-gles
[18:01] <greyback_> qtmir-desktop is built for all arches out of lp:qtmir - it's only qtmir-android that is split over qtmir & qtmir-gles
[18:02] <greyback_> qtmir-gles builds qtmir-android for i386 and x64, as those are the situations in the emulator, where Qt has GLES but runs on a non-android system
[18:03] <greyback_> yes qtmir-desktop will link against the qt-gles on armhf
[18:03] <greyback_> which does sound wrong
[18:03] <racarr> then what is it?
[18:03] <racarr> yeah
[18:04] <greyback_> I suspect nothing has ever used qtmir-desktop on armhf
[18:04] <racarr> yeah haha...I think its probably linked against
[18:04] <racarr> GLES...
[18:04] <racarr> the qtmir qmake files
[18:04] <racarr> dont explicitly use GL or GLES afaict
[18:04] <racarr> so its just coming from the
[18:05] <racarr> Qt configuration
[18:05] <greyback_> makes sense yeah
[18:05] <racarr> so the problem is I dont think its possible to build
[18:05] <racarr> qtmir-desktop and qtmir-android from the same source package on armhf?
[18:06] <racarr> Unless Qt/GL and Qt/GLES are parallel installable
[18:07] <greyback_> qtmir-desktop will compile against Qt/GLES, as that's the one on armhf usually
[18:07] <racarr> greyback_: I thought qtmir-desktop was supposed to be qtmir linked against Qt/GL though
[18:08] <racarr> what is the qtmir-desktop/android distinction?
[18:08] <greyback_> racarr: I think it is supposed to be too, but in actuality I suspect it doesn't - but it's not used so no-one ever noticed
[18:08] <greyback_> the main distinction is a call to eglBindAPI(DesktopGL) somewhere
[18:09] <racarr> right...
[18:09] <racarr> hmm ok
[18:09] <racarr> greyback_: Do you think I should just try and replicate this in qtmir/cmake or
[18:10] <racarr> we should get rid of qtmir-desktop on armhf
[18:10] <greyback_> racarr: bregma might object to the latter notion. I would rather not having hacks in our cmake, just to copy qmake weirdness though
[18:12] <greyback_> it's debian that was including that extra runtime dependence on mesa-gl1, can we force it just build-time only?
[18:12] <racarr> greyback_: I realized though, even then the resultingpackage
[18:12] <racarr> would be linked against GL, but Qt/GLES
[18:13] <racarr> so to really fix it you would need to make the Qts parallel installable and selectable
[18:13] <bregma> I thought Qt was going to switch to doing runtime detection?
[18:13] <greyback_> rsalveti will probably say that's not gonna happen any time soon :)
[18:13] <greyback_> bregma: that was on Windows
[18:14] <rsalveti> maybe qt 5.5?
[18:14] <greyback_> mainly as some customer paid them to do it I suspect
[18:14] <rsalveti> let me find the qt bug
[18:14] <bregma> we do runtime detection in libSDL2, so we know it's possible
[18:14] <rsalveti> yeah, not much progress
[18:14] <rsalveti> https://bugreports.qt-project.org/browse/QTBUG-36829
[18:14] <rsalveti> bregma: it's possible, but still require some work on qt
[18:15]  * greyback_ late for the pub
[18:15] <greyback_> o/
[18:15] <racarr> Bye! thanks
[18:15] <racarr> was having lots of trouble wrapping head around it myself
[18:17] <racarr> I think we should just delete the qtmir-desktop armhf package...I kind of doubt its ever worked. Does anyone even have an mesa-opengl (not gles) armhf device
[18:17] <racarr> to test if it works?
[18:17] <racarr> Does such a thing even exist?
[18:17] <racarr> But if its impossible to
[18:17] <racarr> delete packages
[18:17] <racarr> I can work around it now I guess...
=== karni is now known as karni-afk
=== karni-afk is now known as karni
[19:34] <mterry> I don't suppose anyone has extra review cycles floating around?
=== boiko_ is now known as boiko
=== salem_ is now known as _salem