[08:13] <dbarth> hey Mirv
[08:13] <dbarth> mardy and I are wondering how to land https://requests.ci-train.ubuntu.com/#/ticket/1219
[08:14] <dbarth> this silo has been put aside because of oxide not being available on certain platforms (same old problem)
[08:14] <dbarth> the silo is precisely about moving X11/OA to a supported webview
[08:16] <Mirv> dbarth: I don't see any missing platforms compared to before, only one armhf autopkgtest failure on ubuntu-system-settings-online-accounts which I just pushed the retry button for
[08:17] <Mirv> on this page https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-021/excuses.html
[08:17] <dbarth> oh, i thought that was those which were blocking
[08:18] <dbarth> there is a regression marker indeed; mardy wdyt ?^^
[08:18] <Mirv> better to file an internal bug to try to fix the flaky test, if it's something that now passes on second run.
[08:20] <dbarth> ok
[08:30] <sil2100> bzoltan_: hey! So, any changes in UITK that would warrant a new framework for OTA-11?
[08:31] <sil2100> At least from the UITK point of view
[08:34] <bzoltan_> sil2100: i am digging up the api changes right now
[08:35] <sil2100> bzoltan_: thanks :)
[09:00] <jgdx> Saviq, hey, what's the story on the failing autopkg unity8 tests?
[09:00] <Saviq> jgdx, there is one flaky one that we  know of
[09:00] <sil2100> oSoMoN, chrisccoulson: hey guys!
[09:00] <Saviq> jgdx, got a log?
[09:01] <jgdx> Saviq, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-008/xenial/amd64/u/unity8/20160428_132659@/log.gz for silo 8
[09:01] <sil2100> oSoMoN, chrisccoulson: we're working on an arm64 xenial touch initiative right now, trying to get all the seeded packages to build on arm64 xenial
[09:01] <sil2100> oSoMoN, chrisccoulson: we finally got libhybris 'enabled' for arm64 and did a few no-change rebuilds of its reverse-deps
[09:02] <Saviq> jgdx, yeah, that's the one - another run should make it better and I'll ask my guys to look into this asap
[09:02] <jgdx> Saviq, I'm unable to start a run and so are <other people i've asked>
[09:02] <sil2100> oSoMoN, chrisccoulson: sadly, oxide-qt (which was dep-waiting on hybris) seems to fail to build on the configure step for arm64: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+build/9694223
[09:02] <jgdx> I just want to rerun the failing tests, not the whole thing
[09:03] <Saviq> seb128, could you please recycle https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-008/excuses.html for jgdx
[09:03] <Saviq> jgdx, you need a core-dev for that
[09:03] <seb128> Saviq, "recycle"?
[09:03] <seb128> I can click buttons
[09:03] <Saviq> seb128,  ♻
[09:03] <seb128> just tell me which ones
[09:03] <seb128> lol
[09:04] <Saviq> well what! ;)
[09:04] <seb128> oh
[09:04] <seb128> k
[09:04] <seb128> it's a retry :p
[09:04] <Saviq> no it's not
[09:04] <seb128> "Test request submitted."
[09:04] <Saviq> https://duckduckgo.com/?q=%E2%99%BB
[09:04] <Saviq> seb128, thanks :)
[09:04] <seb128> yw!
[09:09] <oSoMoN> chrisccoulson, does chromium build on arm64?
[09:23] <chrisccoulson> oSoMoN, on android, I believe so
[09:32] <sil2100> oSoMoN, chrisccoulson: would be nice if we were able to make it building, otherwise our "big plan" might be endangered
[09:33] <sil2100> tvoss, morphis: hey guys! So, after libhybris got available for xenial arm64 I did a no-change rebuild of platform-api aaand... suddenly all archs failed because of a test failure
[09:34] <sil2100> tvoss, morphis: could you take a look in a free moment? Could it be related to the hybris stub linker change? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/6391641/+listing-archive-extra
[09:36] <morphis> sil2100: can you retry with https://requests.ci-train.ubuntu.com/#/ticket/1370 ?
[09:39] <sil2100> morphis: hm, let me push the platform-api no-change rebuild to that silo, we'll see if it still fails
[09:39] <sil2100> (if you're ok with that)
[09:46] <morphis> sil2100: yes, I am ok with that
[09:47] <bzoltan_> sil2100:  so... I have the scientifical and official answer to you :)
[09:48] <sil2100> bzoltan_: \o/ what's the answer then?
[09:48] <bzoltan_> sil2100:  I also explain the whol thing, so you will understand why I am pushing our method to all API providers
[09:49] <bzoltan_> sil2100:  we have a components.api in the root of the UITK project. We have an automatic process to check all the APIs on each new revision... whenever a new API is introduced or an API is changed this file represents the changes
[09:49] <bzoltan_> sil2100:  so... simple bzr diff -r1289..1306 (OTA10..OTA11) on components api shows all the relevnat changes.
[09:51] <bzoltan_> sil2100:  http://pastebin.ubuntu.com/16253921/ so we have 4 (four) new properties... if we do not bump the framework version and a poor app developer uses these properties in an app... and that app is installed on a device what is not upgraded to OTA11, then the app might see problems.
[09:51] <bzoltan_> sil2100:  this is a rock solid and acidproof way to track APIs and see if we need to bump the  framework version...
[09:52] <sil2100> bzoltan_: nice to know, yeah, +1 on a framework bump in that case
[09:52] <sil2100> Let me prepare the new framework in a bit
[09:53] <bzoltan_> sil2100:  shame that so little change forces us to bump
[10:02] <morphis> sil2100: it failed again
[10:02] <morphis> that is interesting
[10:03] <morphis> sil2100: but it doesn't seem to be because of hybris
[10:20] <sil2100> hm, yeah
[10:21] <sil2100> tvoss: ^
[10:21] <sil2100> Strange, it's been a while when we last rebuilt platform-api, maybe the dependency changes now make it fail to build in overall
[10:22] <sil2100> tvoss: could you take a look at the papi build failure I mentioned above? Looks like some test is constantly failing now
[13:47] <tedg> rvr: So ChrisTownsend is going to put liblibertine in that silo.
[13:47] <rvr> tedg: Which one?
[13:47] <tedg> rvr: His silo is blocked on translation issues, so he is going to use that one for hte lib stuff associated with the UAL changes
[13:47] <tedg> rvr: 15
[13:48] <rvr> tedg: Ah, ok
[13:48] <rvr> I will block it then
[13:48] <tedg> rvr: Thanks, it should just be 15 minutes or so.
[13:48] <robru> I'm gonna create a new library called Ertine just to confuse people.
[13:49] <ChrisTownsend> robru: No, don't do it!  The world will explode!
[13:49]  * tedg tried to convince them to call the lib that, but no, they're too conservative over there on the libertine project
[13:49] <rvr> conservatine
[13:50] <bregma> ever since the ido scandal
[14:10] <cjwatson> I remember some code once that put some of its library code in a directory called "arry" just so that it could build with options -Larry -Wall.
[14:11] <sil2100> ;)
[14:12] <tedg> Haha, nice.
[14:18] <robru> cjwatson: was it perl? it was perl, wasn't it?
[14:19] <cjwatson> robru: don't recall, possible
[14:20] <cjwatson> if it was it's not in perl itself any more
[14:23] <robru> heh, you checked
[14:34] <ChrisTownsend> rvr: Hey, just an update...waiting on britney to run on silo 15 now.
[14:34] <rvr> ChrisTownsend: Ping me when ready!
[14:34] <ChrisTownsend> rvr: Sure thing!
[15:45] <ChrisTownsend> rvr: silo 15 is good to go!
[15:47] <rvr> ChrisTownsend: Just installed it ;D
[15:47] <ChrisTownsend> rvr: Thanks!
[16:01] <rvr> ChrisTownsend: I still don't see the gedit icon in the Launcher
[16:02] <ChrisTownsend> rvr: Well, ok, here's the deal.  If you are using the Libertine Scope, then no you won't because 1) the Puritine click has not been updated yet to include the humanity-icon-theme package and 2) you will need the blocked libertine-scope from silo 50.
[16:03] <ChrisTownsend> rvr: If you launch gedit from the App Scope, it should be fine.
[16:03] <rvr> ChrisTownsend: Ahh.. so it needs a new gedit click
[16:03] <rvr> ChrisTownsend: I'm launching it from the App scope
[16:04] <ChrisTownsend> rvr: Hmm...
[16:04] <bregma> rvr, it needs a new Puritine click
[16:05] <rvr> bregma: Is it available? Or how can I test the fix?
[16:05] <ChrisTownsend> bregma: Not if he's launching it from the App scope.  That uses the libertine-demo package.
[16:06] <ChrisTownsend> tedg: So does u-a-l now ignore the icons that we use for the libertine demo stuff when launching from the App scope?
[16:07] <tedg> ChrisTownsend: No, it shouldn't. It should show the ones from the demo.
[16:07] <tedg> ChrisTownsend: Not sure what the precedence would be there.
[16:07] <ChrisTownsend> tedg: I mean in the Launcher.  If I now launch gedit from the App scope, the gedit icon is now missing in the Launcher/Switcher.
[16:07] <tedg> We need to unseed the demo package
[16:07] <tedg> ChrisTownsend: Yes, that makes sense.
[16:08] <ChrisTownsend> tedg: Not until we can land libertine-scope.
[16:08] <ChrisTownsend> tedg: Ugh, that's kind of a regression I would think.
[16:08] <tedg> ChrisTownsend: It only looks in the container if it is in the container.
[16:08] <tedg> ChrisTownsend: It won't be once you add the theme to puritine?
[16:08] <ChrisTownsend> tedg: Oh, ok.
[16:08] <ChrisTownsend> tedg: Right
[16:09] <ChrisTownsend> rvr: So I'm in the process of creating a new Puritine click, but armhf builders are slammed and I keep waiting for it to build.
[16:09] <rvr> ChrisTownsend: Ack
[16:09] <ChrisTownsend> rvr: Sorry about the confusion on that.  I thought the App scope icons would still work as before.
[16:10] <rvr> ChrisTownsend: The gedit icon in the App scope is fine. But the gedit icon in the Launcher is missing as before.
[16:11] <rvr> I can't reproduce it easily, but I got a bad window flickering in gedit's top left side
[16:12] <cjwatson> ChrisTownsend: LP builders?
[16:13] <ChrisTownsend> cjwatson: Yes
[16:13] <cjwatson> ChrisTownsend: poked, should clear up soon
[16:14] <ChrisTownsend> cjwatson: Thanks!
[16:14] <ChrisTownsend> rvr: Window flickering should be independent of this landing.
[16:14] <cjwatson> (I'm assuming you mean the virtual builders, as the non-virtual builders have no queue)
[16:17] <ChrisTownsend> cjwatson: It's this PPA: https://launchpad.net/~libertine-team/+archive/ubuntu/devel/+packages
[16:18] <cjwatson> ChrisTownsend: scored up
[16:19] <ChrisTownsend> cjwatson: Thanks again!
[16:20] <cjwatson> and rebalanced the builder pool a bit to help it catch up there
[16:20] <ChrisTownsend> cjwatson: Also, after that first PPA builds and publishes it's arm packages, I will need to build arm packages in this ppa: https://launchpad.net/~libertine-team/+archive/ubuntu/puritine-devel
[16:20] <ChrisTownsend> cjwatson: Any way to give it a higher priority?
[16:21] <ChrisTownsend> cjwatson: Well, you said non-virtual has no queue, so it should be ok.
[16:21] <cjwatson> ChrisTownsend: yeah, that won't need intervention
[16:21] <ChrisTownsend> cjwatson: Ok, thanks
[16:22] <cjwatson> we rarely need score hacks nowadays, it's just in the odd exceptional case, and I prefer not to apply them unnecessarily
[16:22] <ChrisTownsend> cjwatson: I understand and thanks for helping out my build.
[16:38] <rvr> davmor3: The attack of the clone!
[16:38] <rvr> ChrisTownsend: How's the click generation going?
[16:39] <davmor3> rvr I wish my laptop just lost connection randomly and can't see the ap at all now
[16:39] <ChrisTownsend> rvr: The libertine tools that I use to generate it in a PPA just completed and published.  I will now start the build, but it takes some time as it's a ~550MB package.
[16:42] <ChrisTownsend> rvr: Generating a Puritine click is all automated in a Jenkins job.  If you want to watch: https://jenkins.canonical.com/libertine/job/puritine-build-click/87/console
[16:42] <rvr> ChrisTownsend: Thanks
[16:43] <ChrisTownsend> rvr: So it has to build a puritine Debian package first in a PPA: https://launchpad.net/~libertine-team/+archive/ubuntu/puritine-devel
[16:43] <ChrisTownsend> rvr: And when that finishes, the job will download and extract the deb and then generate a click from it.
[16:44] <ChrisTownsend> rvr: And we only care about armhf, which of course is the slowest:)
[16:44] <ChrisTownsend> rvr: Here is the current puritine armhf debian build: https://launchpad.net/~libertine-team/+archive/ubuntu/puritine-devel/+build/9700633
[16:47] <ChrisTownsend> rvr: BTW, if you are installing this click on a frieza, it will probably be better to uninstall the current Puritine click on it, then run 'initctl --session start puritine-click', then install the new one via 'pkcon install-local --allow-untrusted com.ubuntu.puritine_0.8_armhf.click', then rerun the initctl command again.
[16:48] <rvr> ChrisTownsend:
[16:48] <rvr> ChrisTownsend: Yes, I'm testing in frieza
[16:49] <ChrisTownsend> rvr: Ok.
[16:58] <tedg> bregma: How does the unity8-desktop-mir-session package get released?
[16:59] <tedg> bregma: Would like to get the policykit-unity8 package in there.
[17:04] <tedg> bregma: Added a task to bug 1396611
[17:16] <davmor2> jhodapp: get ready for it
[17:16] <jhodapp> davmor2, :)
[17:16] <jhodapp> davmor2, woohoo!
[17:18] <jhodapp> sil2100, can I get some help publish silo 51 please?
[17:19] <jhodapp> or kenvandine ^
[17:20] <kenvandine> jhodapp, looking
[17:21] <jhodapp> thanks
[18:23] <rvr> ChrisTownsend: Seems it finished
[18:24] <ChrisTownsend> rvr: Indeed it has.  Here is a link to the click: https://jenkins.canonical.com/libertine/job/puritine-build-click/lastSuccessfulBuild/artifact/com.ubuntu.puritine_0.8_armhf.click
[18:24] <ChrisTownsend> rvr: Note that I have not tested that at all, so...
[18:32] <rvr> ChrisTownsend: I must leave now, will check later. Downloading...
[18:32] <ChrisTownsend> rvr: Ok, thanks and thanks for being patient:)
[18:39] <rvr> ChrisTownsend: No problem :)
[19:10] <ChrisTownsend> trainguard: I have a package I want in Xenial overlay and Yakkety, but not in Vivid overlay.  What's the best way to handle that?
[19:10] <ChrisTownsend> Err, trainguards ^^^^
[19:11] <robru> ChrisTownsend: just do a yakkety-only silo and then when it's ready to publish wecan just copy the package to xenial-overlay manually
[19:11] <ChrisTownsend> robru: Ok, cool, thanks
[19:11] <robru> ChrisTownsend: yw
[19:14] <dobey> poor vivid
[19:29] <slangasek> robru: is that a binary copy?
[19:30] <robru> slangasek: that was my intention, yes, since it's still early in yakkety
[19:31] <slangasek> robru: for SRUs we allow copies the other direction (devel-1 -> devel), but never allow binary copies from devel to an SRU; even early in the cycle there can be binary incompatibilities
[19:31] <slangasek> and while a binary compatibility would be caught in devel-proposed, there's nothing to catch it when copying the other way
[19:31] <robru> slangasek: alright I'll source copy then
[19:32] <robru> slangasek: or should we tell him to target xenial?
[19:32] <dobey> you'd need to rebuild with a different version number, no?
[19:33] <robru> dobey: nah
[19:33] <dobey> different binary contents with same version number == bad though
[19:33] <robru> dobey: actually overlay is full of xenial packages that'll we'll copy to yakkety soon
[19:33] <dobey> yes, but see what slangasek just said about that :)
[19:34] <robru> dobey: i don't see an issue there?
[19:35] <dobey> robru: a binary copy from x -> y isn't (generally) a problem, but a source copy would mean different contents, so the version should be bumped in those cases.
[19:35] <dobey> robru: likewise, copying a source from y -> x would be a rebuild, and should have a different (lower) version number
[19:35] <robru> dobey: yeah. We're doing binary copies from x to y soon
[19:36] <robru> ChrisTownsend: sorry, you should target xenial then we'll copy it to yakkety after
[19:36] <ChrisTownsend> robru: Ack
[19:36] <dobey> robru: any idea when we'll be able to do y+x+v landings? :)
[19:37] <robru> dobey: early next week
[19:37] <robru> dobey: everything is ready to go, just waiting for go ahead from Pat
[19:37] <dobey> yay
[19:39] <ChrisTownsend> robru: I accidentally built previously for both vivid and xenial, but I don't vivid.  So I just abandon the silo and start over?
[19:45] <jgdx> rdf landings
[19:46] <slangasek> robru: targetting xenial and copying forward to yakkety would be ok, yes
[19:47] <slangasek> robru: and when is the mass-copy to yakkety planned to happen?
[19:47] <robru> slangasek: not sure, sil will do it next week sometime
[19:48] <robru> ChrisTownsend: that will work, yes. Abandon and reassign the same request
[19:48] <ChrisTownsend> robru: Ok, thanks
[19:48] <robru> ChrisTownsend: you're welcome
[19:56] <sil2100> Yeah, we'll do it 'somewhen' next week, no fully decided week
[19:56] <sil2100> s/week/date
[19:57] <sil2100> Since we want to do it after we snapshot OTA-11 and have the first candidate image ready, which is not yet sadly
[19:57] <sil2100> Possibly somewhere mid-next-week we would be doing the batch copy and triple landing switch from robru
[20:19] <ChrisTownsend> rvr: Whenever you get back and test, I had to reboot my frieza after installing silo 15 in order for the gedit icon to show in the Launcher.