=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[01:38] <kenvandine> ugh... it didn't make me ack the packaging changes last time when it went to the unapproved queue
[01:38] <kenvandine> robru, publishing again
[02:53] <robru> kenvandine: yeah for some reason it didn't have a packaging diff to vivid, only to vivid overlay.
[02:53] <robru> kenvandine: thanks
[08:58] <Mirv> Saviq: I'm not sure yet if the logic is 100% correct, but the CI Train has detected that qtubuntu would need a rebuild in 021
[08:59] <Mirv> no, but that sounds false really
[08:59] <Mirv> the latest is 20151021
[09:00] <Mirv> let's try something, but if train is mistaken completely we might eventually need robru
[09:00] <Mirv> since we don't want to rebuild if it's not really needed
[09:00] <Mirv> or well, I could consider doing the copies manually and merge+clean
[09:01] <Mirv> Saviq: ah, no it's not error, dednick has changed one branch 25 mins ago!
[09:01] <Mirv> dednick: this went through whole QA now and was accepted, but your change now made the silo dirty :(
[09:01] <dednick> i dint know it was accepted.
[09:01] <Mirv> in https://code.launchpad.net/~nick-dedekind/qtubuntu/lp1475678.surface-occlude/+merge/273424
[09:02] <Mirv> dednick: when it's given to QA, at that point it should be completely frozen
[09:02] <Mirv> robru: unping, train working completely correctly, thanks for the nice checks! :)
[09:02] <dednick> i didnt know it had gone to QA either. my branch wasn't even Approved yet.
[09:02] <dednick> "top approved"
[09:03] <Mirv> dednick: top-approved 2015-10-20 it says at https://code.launchpad.net/~nick-dedekind/qtubuntu/lp1475678.surface-occlude/+merge/273424  ?
[09:04] <dednick> oh right, my bad. dandrader set it to "needs fixing" again yesterday after a change.
[09:04] <dednick> bug fix.
[09:05] <dednick> Mirv: the change yesterday was just a variable name change. i can revert if necessary.
[09:05] <Saviq> dednick, yes, if we can, please revert to the state before yesterday evening
[09:06] <Mirv> yeah it's all alright if you don't really need a rebuild. if nothing else, I can copy the packages manually but maybe uncommit + push-overwrite would convince train again
[09:06] <Saviq> Mirv, it won't
[09:06] <Mirv> maybe file a bug to change the variable name later
[09:06] <Saviq> Mirv, not even a watch-only rebuild
[09:06] <dednick> Saviq: done.
[09:06] <Mirv> Saviq: ah, you've been there. well then, then I'll handle it manually.
[09:06] <Saviq> Mirv, thanks
[09:07] <Mirv> after seeing myself that yes it won't work :)
[09:15] <Mirv> Saviq: ok done except for unity-api which is the only main package and only package that didn't have packaging changes so I didn't notice I can't copy it...
[09:16] <Mirv> vivid all done, so xenial unity-api need to find core-dev before merge&clean can be done
[09:16] <Saviq> Mirv, ack, not a huge problem as that's a build dependency only anyway
[09:25] <oSoMoN> jibel, did you change the status of https://bugs.launchpad.net/qtubuntu/+bug/1504293 by mistake? afaik the fix is still in silo 21
[09:25] <ubot5> Ubuntu bug 1504293 in qtubuntu (Ubuntu) "Screen.pixelDensity is incorrect on all devices" [High,In progress]
[09:25] <jibel> oSoMoN, silo 21 landed last night
[09:25] <jibel> not copied though
[09:26] <Mirv> landed but not copied :) now copied too.
[09:26] <jibel> thanks
[09:27] <jibel> I'll ask sil2100 to rebuild an image with all that stuff in the afternoon
[09:27] <oSoMoN> jibel, trainguards: then https://requests.ci-train.ubuntu.com/#/ticket/564 is lying, it doesn’t say "landed"
[09:31] <Mirv> oSoMoN: so jibel meant it "landed" as in QA approved it. I meant that there was a wrong commit 1h ago that confused train, but I've now _copied_ ie published the packages, and about to clean the silo. a bit complex landing, that is :)
[09:32] <oSoMoN> yeah, I’ve seen the packages in the overlay PPA and in the xenial archive, was wondering why the discrepancy in the train status, thanks for clarifying
[09:32] <Mirv> oSoMoN: currently train can't undirty a silo once it has dirtied it, even if a mistaken commit is pulled away
[09:33] <Mirv> nice that the merging works without forcing ie it checks that my manual publishing was complete and was happy with it
[09:33] <jibel> yeah sorry, I jumped the gun, I didn't check the landed status. Usually when it's mark QA Granted the copy happens quickly after
[09:35] <jibel> bileto could probably update the status of canonical system image tasks automatically and save some clicks
[09:36] <jibel> Saviq, bug 1511711 was also fixed in silo 21?
[09:36] <ubot5> bug 1511711 in qtmir (Ubuntu) "Infographic does not switch with double tap" [High,In progress] https://launchpad.net/bugs/1511711
[09:37] <jibel> oSoMoN, bug 1487090 was fixed in latest landing of oxide?
[09:37] <ubot5> bug 1487090 in Canonical System Image "Download initiated from context menu’s saveLink/saveMedia doesn’t expose a mime type" [High,In progress] https://launchpad.net/bugs/1487090
[09:40] <oSoMoN> jibel, yes
[09:41] <jibel> cool, then that's 1 regression left in OTA8
[09:43] <oSoMoN> jibel, which one?
[09:44] <jibel> oSoMoN, not webbrower related. bug 1509118
[09:44] <ubot5> bug 1509118 in Canonical System Image "U1 account stops working and prevents using the store" [Critical,Confirmed] https://launchpad.net/bugs/1509118
=== _salem is now known as salem_
=== alan_g is now known as alan_g|lunch
[13:19] <rvr> seb128: ping
[13:19] <seb128> rvr, hey
[13:19] <rvr> seb128: Hey
[13:19] <rvr> seb128: Silo 3
[13:19] <rvr> seb128: In the test plan https://wiki.ubuntu.com/Process/Merges/TestPlan/gsettings-qt
[13:20] <rvr> seb128: «Open system settings with the security panel. Ensure "Dash search" is set to "Phone and Internet"»
[13:20] <rvr> seb128: I see no Dash search option in the phone :-/
[13:21] <seb128> rvr, oh, right, that got removed, we should update the test plan
[13:22] <rvr> seb128: Second test case still valid?
[13:22] <seb128> it should
[13:23] <seb128> rvr, for the first test case, replace that by
[13:23] <jibel> dbarth_, hi, if bug 1511768 has to go into ota8, there is still time but the MP must be reviewed and top approved.
[13:23] <ubot5> bug 1511768 in Ubuntu Online Accounts API "[QML] Application crashes if AccountModel::applicationId is not set" [Critical,In progress] https://launchpad.net/bugs/1511768
[13:24] <jibel> dbarth_, it's in silo 1
[13:24] <seb128> rvr, open system settings->about->storage, change the sort order from applications between name/size, close the panel and reopen, it should have the previous value still used
[13:26] <rvr> seb128: Second time I open, it also takes time to calculate the disk used. Is that fine?
[13:26] <seb128> yes
[13:26] <seb128> it does the full calculation every time
[13:28] <rvr> seb128: Nice, it passes
[13:28] <seb128> rvr, great, thanks for testing, and sorry about the outdated wiki, I'm going to fix it
[13:33] <rvr> seb128: The qml test case is no longer valid also, at least the bit of the Dash search.
[13:33] <rvr> Possible values are right
[13:33] <seb128> k
[13:34] <seb128> going to fix that as well
[13:38] <rvr> dbarth_: The merge proposal in silo 1 needs review and approval
[13:38] <rvr> mardy: ^
[13:42] <jibel> cihelp: do you know anything about http://ci.ubuntu.com/mir_performance/glmark2/ and what is supposed to be under this link?
[13:50] <mardy> rvr: I guess I shouldn't self-approve it... can you start the testing of the silo anyway, while we wait for dbarth's ack?
[13:50] <rvr> mardy: What if he doesn't like it? :D
[13:51] <mardy> rvr: nah, he likes eveything that I do :-)
[14:07] <dbarth_> rvr: ack
[14:09] <mardy> rvr: you see? I told you :-p
=== alan_g|lunch is now known as alan_g
[14:20] <mardy> dbarth_: silo 58 has also finished building now, you can start reviewing the branches if you like (signon, libaccounts-qt and accounts-qml-module have already been reviewed upstream, so you can go light on them)
[14:40] <josepht> jibel: nothing other than it was some mir testing that was being run at one time but they stopped.
[14:41] <jibel> josepht, do you know where the code of the test is or who owned it,
[14:41] <jibel> ?
[14:44] <josepht> jibel: I have no idea where the code is.  afair it was the mir team that owned it.  It was something Chris Gagnon was working on quite a while ago.
[14:44] <jibel> josepht, ack, thanks. I'll see we kgunn and his team.
[14:53] <josepht> jibel: https://code.launchpad.net/~josharenson/qa-dash-mir-performance/trunk is where that plugin comes from
[14:54] <josepht> jibel: It's supposed to be parsing the results of this job https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/
[14:54] <josepht> jibel: and it was Josh Arenson not Chris Gagnon
[14:55] <jibel> josepht, Excellent. Thanks for the details.
[14:55] <josepht> jibel: you're welcome
[14:56] <abeato> trainguards, the armhf build of silo 9 is taking too long: https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/393/console
[14:56]  * abeato wondering if there is something wrong happening
[14:56] <abeato> jhodapp, ^^
[15:06] <jibel> sil2100, do you think you could rebuild an image today to have a build before the week end with latest unity8/mir ?
[15:09] <sil2100> jibel: sure thing
[15:09] <sil2100> I saw a lot of stuff landing till now
[15:09] <sil2100> Do we have everything we need now? I could kick an image in a moment then
[15:10] <jibel> sil2100, the only package that has not been copied is gsettings-qt I think
[15:10] <pmcgowan> yeah major landings today, very nice
[15:10] <pmcgowan> sooo many fixes
[15:10] <jibel> sil2100, we have everything. davmor2 will prbaobly fail libinput and rvr just started on online-accounts
[15:11] <jibel> sil2100, you can kick an image now if you want
[15:11] <jibel> sil2100, custom tarballs failed verification
[15:11] <jibel> sil2100, so it's a next week thing now
[15:11] <davmor2> jibel: I am failing libinput
[15:11] <jibel> davmor2, all right
[15:12] <anpok_> fail?
[15:12] <jibel> davmor2, ^
[15:13] <robru> abeato: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-009/+build/8271527 the build is happening, so it's not a train issue (eg, train isn't stalled, train is accurately reporting that the build is bulding).
[15:13] <sil2100> I was pretty scared by the number of things landing in the overlay today when I woke up
[15:13] <davmor2> anpok_: Yes, short power button tap on krillin is not functioning and power button and screen are not working on arale at all
[15:13] <sil2100> I'm like, damn, devs and QA went crazy with those silos
[15:13] <sil2100> Kicking an image
[15:14] <jibel> boiko, which version of messaging app has the fix for bug 1513044 ?
[15:14] <ubot5> bug 1513044 in Canonical System Image "autopilot tests failing, unable to find 'Label'" [High,Confirmed] https://launchpad.net/bugs/1513044
[15:15] <boiko> jibel: it landed yesterday, I forgot to mark the branch as fixing the bug, just a sec, let me check
[15:15] <anpok_> davmor2: ok - I believe that will be fixed by https://bugs.launchpad.net/canonical-pocket-desktop/+bug/1511095
[15:15] <ubot5> Ubuntu bug 1511095 in unity8 (Ubuntu) "unity-system-compositor crash, no interaction on windowed mode" [High,New]
[15:15] <boiko> jibel: 0.1+16.04.20151104-0ubuntu1
[15:16] <anpok_> davmor2: but will look again..
[15:17] <jibel> boiko, which silo was it? I cannot find it
[15:17] <boiko> jibel: let me check
[15:17] <jibel> ah 29
[15:18] <boiko> jibel: https://requests.ci-train.ubuntu.com/#/ticket/603
[15:19] <jibel> boiko, yeah it was marked 'no qa needed' that's why I didn't find a trace of the verification
[15:20] <boiko> jibel: no code changes were necessary, only changes to the autopilot tests themselves
[15:26] <jibel> boiko, right, thanks.
[15:47] <rvr> mardy: Weird, without the silo it the app doesn't crash
[15:49] <rvr> mardy: dbus[2168]: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/com/ubuntu/OnlineAccounts/Manager" interface="com.ubuntu.OnlineAccounts.Manager" member="RequestAccess" mask="send" name="com.ubuntu.OnlineAccounts.Manager" pid=2543 label="it.mardy.uploader_uploader_0.3" peer_pid=2577 peer_label="unconfined"
=== robru changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: experimental train changes just landed in production, please report any strange behavior to robru immediately
[16:02] <kgunn> sil2100: bregma was just saying if you know the file that needs to be added
[16:02] <kgunn> they could put it in the libertine-demo pkg
[16:16] <jhodapp> robru, hey when you get a chance can you please dput my latest qtmultimedia changes from ppa:jhodapp/ubuntu/ppa to silo 9
[16:30] <Mirv> jhodapp: hey. so trying to understand the playlist stuff.. for example if upstream addItems, possibly insertItems, and we have addSources, how does that not cause problems in the future when we drop our addSources public function? or is the scope of the usage of qdeclarativeplaylist so that for example no store apps are allowed to use those?
[16:31] <jhodapp> Mirv, upstream switched to *Items for Qt 5.5, for 5.4 it's *Source
[16:31] <jhodapp> Mirv, so this is only for 5.4...I will have to port it to 5.5
[16:31] <jhodapp> and upstream
[16:32] <Mirv> jhodapp: yes, but I'm trying to understand how we are not going to be screwed even worse than with audio role API changes if we allow apps to use addSources now, and later drop all the current patches you have and get upstream ones instead. for example, I'd like to backport all the patches from upstream to 5.5 so that we follow upstream as soon as possible.
[16:33] <jhodapp> Mirv, I see what you're saying, so we haven't found a way to deal with API changes with our store yet?
[16:33] <Mirv> jhodapp: yes, and that's why I asked earlier to upstream everything first before shipping anything to our stable image users
[16:34] <jhodapp> Mirv, well to your point upstreaming won't solve it here
[16:34] <jhodapp> Mirv, the thing that will break it is a change from Qt 5.4 to 5.5
[16:34] <Mirv> jhodapp: they didn't have qdeclarativeplaylist in 5.4, it was added in 5.5 in the first place?
[16:35] <jhodapp> Mirv, right but other APIs are broken with the new 5.5/5.6 qtmultimedia
[16:35] <Mirv> jhodapp: actually, they only have it beginning with 5.6 https://codereview.qt-project.org/#/c/122801/ so they're committing to the 5.6 version
[16:35] <jhodapp> Mirv, err changed
[16:35] <Mirv> jhodapp: by other API:s you mean the API:s that we're shipping?
[16:36] <jhodapp> Mirv, yeah, I can't think of one offhand
[16:36] <Mirv> jhodapp: yeah, so the thing is that we shouldn't have shipped _anything_ in our stable images that upstream hasn't merged to theirs
[16:36] <Mirv> jhodapp: similar to the audio role API changes that we are now barely surviving
[16:36] <Mirv> sil2100: jibel: I need you to stay on top of these ^ too since I anticipate trouble from us deviating from upstream
[16:37] <jhodapp> Mirv, right, we shipped the audio role patch long before they were accepting upstream changes from us so fluidly
[16:37] <jhodapp> Mirv, but anyway, your idea of porting to what's in 5.6 is a good idea
[16:38] <Mirv> jhodapp: or with 5.6 I mean 5.6 + 5.7 (current dev) + what you'll submit next from us
[16:38] <jhodapp> Mirv, right
[16:39] <Mirv> jhodapp: can we still port everything in our 5.4 to what is in upstream and will be? like, before any apps in the store start using the obsolete API?
[16:39] <jhodapp> Mirv, I'll plan on back porting that next here
[16:39] <jhodapp> Mirv, yes, absolutely
[16:39] <jhodapp> now is the time
[16:39] <Mirv> jhodapp: ok, thanks, then we're on the same page :)
[16:39] <jhodapp> Mirv, thanks for bringing this up, I don't have any experience in this myself so I'm learning about the caveats
[16:41] <Mirv> jhodapp: yeah, it's good to know that this needs to be handled. so always upstream first, once it's approved there we can ship a feature. even with that approach there are some risks - for example, they are free to change 5.7 at the moment even if they would first accept your changes, and they wouldn't commit to the API until feature freeze.
[16:41] <Mirv> (or maybe not until the release is out, not sure what's their process)
[16:42] <jhodapp> Mirv, yeah ideally I'll try to do that, but you know how everything is needing to ship ASAP
[16:44] <Mirv> jhodapp: sure. there just needs to be a line drawn somewhere, otherwise we end up in a mess that's hard to clean later when we have competing API:s from upstream, our own version, and people trying to use either or both.
[16:45] <jhodapp> Mirv, agreed...I really hope we can solve this issue in general for apps in the store. Because underlying API breakage will happen.
[16:46] <Mirv> pmcgowan: you might be interested in defining our internal rules on how we introduce API:s to (upstream) Qt. I'd appreciate requiring upstream acceptance first, but currently it's not so.
[16:47] <pmcgowan> Mirv, we are changing qt apis?
[16:48] <Mirv> pmcgowan: yes, or we're contributing Qt API:s but shipping our own, different ones earlier. This QML Playlist feature in silo 009 and also earlier uploads is something that is not upstreamed, and the portions that are upstreams got changes that are incompatible with our version.
[16:50] <pmcgowan> Mirv, ok, yeah we can easily coordinate that now with our biweekly
[16:51] <jhodapp> Mirv can you please dput my latest qtmultimedia changes from ppa:jhodapp/ubuntu/ppa to silo 9
[16:51] <jhodapp> seems robru isn't around
[16:51] <Mirv> pmcgowan: ok. jhodapp, maybe you should join the next Tuesday's meeting and we'd try to get the final API solved so that we know what to port everything to including 5.4? or at least have a plan how to go forward.
[16:51] <Mirv> jhodapp: ok
[16:52] <robru> Mirv: jhodapp: oh sorry I overlooked the last ping. I can do it
[16:52] <Mirv> robru: I copied it now
[16:52] <jhodapp> Mirv, you're welcome to invite me, I'm pretty confident that what's in 5.6 is the final API but I can double check this with Yoann, QtMultimedia upstream
[16:52] <robru> Mirv: thanks
[16:52] <jhodapp> thanks Mirv and robru
[16:54] <jhodapp> Mirv, just emailed Yoann and CCed you on it
[16:57] <Mirv> jhodapp: isn't it still evolving? you're submitting the addItems() to 5.7 (dev) and Yoann is asking it to be renamed, and the ubuntu15 upload had eg. moveMedia which isn't in upstream either? so not "final" as such.
[16:57] <jhodapp> Mirv, well I mean from their point of view
[16:57] <jhodapp> upstream's
[16:58] <Mirv> jhodapp: well you'd need to eventually submit everything we want to use to their 5.7, otherwise we shouldn't add our own functions in the first place? but yes, if you mean that they're not going to do changes to their current API, yes, then I understand.
[16:58] <jhodapp> Mirv, yes I mean that and I'll have to coordinate with Yoann for our further changes
[16:59] <Mirv> jhodapp: ok!
[16:59] <jhodapp> Mirv, I don't anticipate anymore API changes from what's in silo 9 now
[17:00] <Mirv> jhodapp: good that the API is gettinng final from our POV. let's get OTA-9 in line with upstream, and have the remaining moveMedia() etc changes in upstream by then too.
[17:00] <jhodapp> Mirv, yeah indeed, that'll definitely be part of my focus for this next week
=== alan_g is now known as alan_g|EOD
=== alan_g|EOD is now known as alan_g|EOW
=== salem_ is now known as _salem