[00:25] <lpotter> mzanetti: is there a launchpad bug for the qinputinfo stuff?
[09:00] <tsdgeos> Saviq: so it seems all things audio related are in place
[09:00] <Saviq> tsdgeos, nice
[09:00] <tsdgeos> Saviq: with pstolowski we were thinking of when to land it
[09:00] <tsdgeos> it = silo 4
[09:01] <Saviq> tsdgeos, now is good
[09:01] <pstolowski> Saviq, silos 22 and 58 need to land at the same time
[09:01] <pstolowski> i mean first
[09:02] <tsdgeos> Saviq: ok, also you or someone else need to lift the needs fixing of Saviq:
[09:02] <tsdgeos> wrong c&p
[09:02] <tsdgeos> Saviq: ok, also you or someone else need to lift the needs fixing of https://code.launchpad.net/~unity-team/unity8/audioCardSupport/+merge/271605 that was introduced because of the Playlist/xenial issue
[09:04] <Saviq> Mirv, so did we get anywhere with having a valid Requires: for the new multimedia bits?
[09:19] <Saviq> pstolowski, by "need to land at the same time", do you mean things will break otherwise?
[09:21] <Mirv> Saviq: I guess for xenial it was that "it's now in release pocket and won't ever go away" so limiting one to vivid as a compromise yields you >= 5.4.1-1ubuntu19~overlay2  (currently in silo 58)
[09:21] <Mirv> the vivid silo is in QA queue
[09:21] <pstolowski> Saviq, not sure, that depends on unity8 relationship with qtmedia i guess, tsdgeos? ^
[09:22] <tsdgeos> we don't have any, just with qtmultimedia
[09:22] <tsdgeos> but that has already landed
[09:22] <tsdgeos> my *guess* is that those silos are for qtmultimedia+media-hub itself
[09:23] <tsdgeos> more than for the unity8+qtmultimedia relationship
[09:23] <tsdgeos> but that's just a guess
[09:23] <Saviq> tsdgeos, well, if we try to import 5.6 and it's not there
[09:23] <Saviq> that's in silo 58
[09:23] <tsdgeos> you sure about that?
[09:24] <tsdgeos> i think i tried that already last year and it worked
[09:24] <tsdgeos> but may be wrong
[09:25] <tsdgeos> let me double-check
[09:32] <Saviq> "last year" sounds so far back :P
[09:55] <tsdgeos> Saviq: ok you're right the 5.6 export is only there in xenial, not vivid
[09:55] <tsdgeos> pstolowski: so we need to wait for that to land
[09:55] <Saviq> tsdgeos, just add a >= like Timo said above ↑ to silo 4
[09:56] <tsdgeos> k
[09:56] <Saviq> tsdgeos, it will then prevent us from installing new unity8 without new qt
[09:57] <tsdgeos> for vivid only, not for xenial, but i guess we care less there
[09:58] <pstolowski> tsdgeos, ack
[09:58] <tsdgeos> Saviq: Mirv: this, rihgt? http://bazaar.launchpad.net/~unity-team/unity8/audioCardSupport/revision/1811
[09:59] <Saviq> tsdgeos, yeah, not ideal, but Mirv frowned at my idea of introducing virtual packages for this :P
[09:59] <tsdgeos> :D
[10:25] <Mirv> tsdgeos: correct
[11:02] <dandrader> dednick, would you have some spare time to review this one?  https://code.launchpad.net/~dandrader/qtmir/removeUselessClass/+merge/281538
[11:05] <tsdgeos> dandrader: the name made it sound "smaller"  in my mind :D
[11:06] <dandrader> tsdgeos, that's the catch :)
[11:06] <dednick> dandrader: can do
[11:06] <dandrader> dednick, thanks
[11:17] <tsdgeos> Saviq: ping
[11:18] <Saviq> tsdgeos, pong
[11:18] <tsdgeos> Saviq: is it my eyes broken or do we have two rules for override_dh_auto_clean: in debian/rules ?
[11:20] <Saviq> tsdgeos, ouch
[11:20] <Saviq> should probably drop the rm -Rf builddir, that's a bit nasty :P
[11:21] <tsdgeos> don't know why it was there
[11:21] <tsdgeos> but anyway it seems given the new one we don't use it either
[11:21] <tsdgeos> so just remove the first target i guess?
[11:21] <tsdgeos> want me to propose a branch?
[11:22] <Saviq> tsdgeos, yes please
[11:26] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/dupe_override_dh_auto_clean/+merge/281607
[13:52] <mterry> pstolowski, regarding https://code.launchpad.net/~stolowski/unity8/shareData-rename/+merge/280056 ...  but do we need to change any scopes?  I see us changing the name unity8 reads but not any names exposed to be read
[13:56] <Saviq> pstolowski, btw, are you processing silo 4?
[14:10] <pstolowski> Saviq, i kicked the build some time ago (a new commit was reported in unity8)
[14:10] <Saviq> right
[14:10] <Saviq> and it's now waiting for new qt
[14:12] <Saviq> tsdgeos, hmm I wonder, do we really need qtmultimedia during build... we're mocking it these days, aren't we? (and we don't have it in Depends:, where we probably should)
[14:12] <Saviq> we need a proper review of debian/control soon...
[14:12] <tsdgeos> Saviq: probably not
[14:12] <Saviq> not to mention we're likely not running any test that actually uses multimedia
[14:13] <Saviq> in build
[14:13] <pstolowski> ah, so now it's waiting for the stuff from the two other silos?
[14:14] <tsdgeos> Saviq: i'd say that is almost for sure (tests should be using the mocks)
[14:14] <Saviq> pstolowski, from 58, should be there shortly (it's enough that it gets into proposed)
[14:15] <Saviq> tsdgeos, I mean even the mock is only used during full tests, not "make test"
[14:15] <tsdgeos> yep
[14:15] <Saviq> so even the mock isn't used during build
[14:23] <pstolowski> mterry, nope, scopes don't use this feature yet
[14:24] <mterry> pstolowski, alright then.  I'll note that this MP exposes that we don't have tests for share-data, but that's not this MP's job to fix
[14:25] <greyback__> Saviq: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtmir - the gles i386 autopackage test failed on text mocking dbus, would guess the mocked dbus server failed to start.
[14:25] <pstolowski> mterry, note, cimi is working on a branch that depends on mine
[14:27] <Saviq> greyback__, a re-run is queued, but there was quite a queue
[14:28] <Saviq> greyback__, http://autopkgtest.ubuntu.com/running.shtml
[14:28] <Saviq> like 20th in the queue or so
[14:28] <greyback__> yes, quite a queue
[14:28] <dandrader> greyback__, https://code.launchpad.net/~dandrader/qtubuntu/offscreenSurface-lp1527737/+merge/281638
[14:29] <dandrader> greyback__, have the actual bug fix ready in a qtmir branch. just writing a test for it now
[14:30] <greyback__> dandrader: ack. Please ensure you test it on desktop and phone.
[14:31] <dandrader> greyback__, ok
[14:31] <greyback__> dandrader: "god-knows-what" = clean the gl context :D
[14:32] <dandrader> greyback__, updated. thanks :D
[14:32] <greyback__> dandrader: and we *do* want that
[14:33] <dandrader> greyback__, that = creating a mir surface
[14:33] <greyback__> well we want the cleanup, but not the mir surface
[14:33] <greyback__> right
[14:33] <greyback__> is fine
[16:22] <Saviq> pstolowski, looks like Xavi went in before you https://launchpad.net/ubuntu/+source/unity8/8.11+16.04.20160105.1-0ubuntu1
[16:22] <Saviq> so you need to rebuild unity8 anyway
[16:23] <pstolowski> okay
[16:23] <Saviq> i.e. https://requests.ci-train.ubuntu.com/#/ticket/645
[16:24] <Saviq> pstolowski, but not before yesterday it doesn't seem, as migration is going to take a while
[16:24] <Saviq> greyback, so how about we land DPR?
[16:24] <Saviq> qtmir migrated
[16:25] <greyback> Saviq: was trying a rebuild, getting odd merge error from train that I can't repro locally, any idea?
[16:25] <Saviq> greyback, qtmir/gles sync at least is merged already
[16:26] <Saviq> greyback, ah but you have a criss-cross merge in qtubuntu
[16:26] <greyback> that I can't repro locally
[16:26] <pstolowski> Saviq, ack
[16:26] <Saviq> greyback, yeah you can, just do exactly what train does - take train, merge loggingCategory, merge DPR
[16:27] <Saviq> greyback, it's because you have trunk merged in both loggingCategory and DPR
[16:27] <greyback> oh I forgot logging category
[16:27]  * greyback kicks himself
[16:27] <Saviq> greyback, since you put DPR on top of loggingCategory, you should not have merged trunk
[16:27] <greyback> durr, my ba
[16:27] <greyback> d
[16:27] <greyback> fixing
[16:27] <Saviq> greyback, need to follow the chain unfortunately
[16:27] <greyback> *grumble*
[16:30] <Saviq> greyback, so if you have conflicts with trunk, dandrader|lunch needs to update loggingCategory first
[16:30] <greyback> it doens't, that's fine
[19:04] <mterry> Saviq, I've noticed that the launcher will give haptic feedback when clicking in its blank spaces -- is that a regression or was it always like that?
[20:27] <dandrader> Saviq, updated
[23:34] <Saviq> mterry, no idea :)