=== chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === fginther` is now known as fginther [08:13] hey Mirv [08:13] mardy and I are wondering how to land https://requests.ci-train.ubuntu.com/#/ticket/1219 [08:14] this silo has been put aside because of oxide not being available on certain platforms (same old problem) [08:14] the silo is precisely about moving X11/OA to a supported webview [08:16] 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] on this page https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-021/excuses.html [08:17] oh, i thought that was those which were blocking [08:18] there is a regression marker indeed; mardy wdyt ?^^ [08:18] 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] ok [08:30] bzoltan_: hey! So, any changes in UITK that would warrant a new framework for OTA-11? [08:31] At least from the UITK point of view [08:34] sil2100: i am digging up the api changes right now [08:35] bzoltan_: thanks :) [09:00] Saviq, hey, what's the story on the failing autopkg unity8 tests? [09:00] jgdx, there is one flaky one that we know of [09:00] oSoMoN, chrisccoulson: hey guys! [09:00] jgdx, got a log? [09:01] 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] 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] oSoMoN, chrisccoulson: we finally got libhybris 'enabled' for arm64 and did a few no-change rebuilds of its reverse-deps [09:02] 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] Saviq, I'm unable to start a run and so are [09:02] 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] I just want to rerun the failing tests, not the whole thing [09:03] seb128, could you please recycle https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-008/excuses.html for jgdx [09:03] jgdx, you need a core-dev for that [09:03] Saviq, "recycle"? [09:03] I can click buttons [09:03] seb128, ♻ [09:03] just tell me which ones [09:03] lol [09:04] well what! ;) [09:04] oh [09:04] k [09:04] it's a retry :p [09:04] no it's not [09:04] "Test request submitted." [09:04] https://duckduckgo.com/?q=%E2%99%BB [09:04] seb128, thanks :) [09:04] yw! [09:09] chrisccoulson, does chromium build on arm64? [09:23] oSoMoN, on android, I believe so [09:32] oSoMoN, chrisccoulson: would be nice if we were able to make it building, otherwise our "big plan" might be endangered [09:33] 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] 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] sil2100: can you retry with https://requests.ci-train.ubuntu.com/#/ticket/1370 ? [09:39] morphis: hm, let me push the platform-api no-change rebuild to that silo, we'll see if it still fails [09:39] (if you're ok with that) [09:46] sil2100: yes, I am ok with that [09:47] sil2100: so... I have the scientifical and official answer to you :) [09:48] bzoltan_: \o/ what's the answer then? [09:48] sil2100: I also explain the whol thing, so you will understand why I am pushing our method to all API providers [09:49] 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] sil2100: so... simple bzr diff -r1289..1306 (OTA10..OTA11) on components api shows all the relevnat changes. [09:51] 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] sil2100: this is a rock solid and acidproof way to track APIs and see if we need to bump the framework version... [09:52] bzoltan_: nice to know, yeah, +1 on a framework bump in that case [09:52] Let me prepare the new framework in a bit [09:53] sil2100: shame that so little change forces us to bump [10:02] sil2100: it failed again [10:02] that is interesting [10:03] sil2100: but it doesn't seem to be because of hybris [10:20] hm, yeah [10:21] tvoss: ^ [10:21] 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] tvoss: could you take a look at the papi build failure I mentioned above? Looks like some test is constantly failing now === alan_g is now known as alan_g|lunch === _salem is now known as salem_ === chihchun is now known as chihchun_afk === alan_g|lunch is now known as alan_g [13:47] rvr: So ChrisTownsend is going to put liblibertine in that silo. [13:47] tedg: Which one? [13:47] 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] rvr: 15 [13:48] tedg: Ah, ok [13:48] I will block it then [13:48] rvr: Thanks, it should just be 15 minutes or so. [13:48] I'm gonna create a new library called Ertine just to confuse people. [13:49] 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] conservatine [13:50] ever since the ido scandal [14:10] 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] ;) [14:12] Haha, nice. [14:18] cjwatson: was it perl? it was perl, wasn't it? [14:19] robru: don't recall, possible [14:20] if it was it's not in perl itself any more [14:23] heh, you checked [14:34] rvr: Hey, just an update...waiting on britney to run on silo 15 now. [14:34] ChrisTownsend: Ping me when ready! [14:34] rvr: Sure thing! [15:45] rvr: silo 15 is good to go! [15:47] ChrisTownsend: Just installed it ;D [15:47] rvr: Thanks! [16:01] ChrisTownsend: I still don't see the gedit icon in the Launcher [16:02] 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] rvr: If you launch gedit from the App Scope, it should be fine. [16:03] ChrisTownsend: Ahh.. so it needs a new gedit click [16:03] ChrisTownsend: I'm launching it from the App scope [16:04] rvr: Hmm... [16:04] rvr, it needs a new Puritine click [16:05] bregma: Is it available? Or how can I test the fix? [16:05] bregma: Not if he's launching it from the App scope. That uses the libertine-demo package. [16:06] 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] ChrisTownsend: No, it shouldn't. It should show the ones from the demo. [16:07] ChrisTownsend: Not sure what the precedence would be there. [16:07] 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] We need to unseed the demo package [16:07] ChrisTownsend: Yes, that makes sense. [16:08] tedg: Not until we can land libertine-scope. [16:08] tedg: Ugh, that's kind of a regression I would think. [16:08] ChrisTownsend: It only looks in the container if it is in the container. [16:08] ChrisTownsend: It won't be once you add the theme to puritine? [16:08] tedg: Oh, ok. [16:08] tedg: Right [16:09] 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] ChrisTownsend: Ack [16:09] rvr: Sorry about the confusion on that. I thought the App scope icons would still work as before. [16:10] ChrisTownsend: The gedit icon in the App scope is fine. But the gedit icon in the Launcher is missing as before. [16:11] I can't reproduce it easily, but I got a bad window flickering in gedit's top left side [16:12] ChrisTownsend: LP builders? [16:13] cjwatson: Yes [16:13] ChrisTownsend: poked, should clear up soon [16:14] cjwatson: Thanks! [16:14] rvr: Window flickering should be independent of this landing. [16:14] (I'm assuming you mean the virtual builders, as the non-virtual builders have no queue) [16:17] cjwatson: It's this PPA: https://launchpad.net/~libertine-team/+archive/ubuntu/devel/+packages [16:18] ChrisTownsend: scored up [16:19] cjwatson: Thanks again! [16:20] and rebalanced the builder pool a bit to help it catch up there [16:20] 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] cjwatson: Any way to give it a higher priority? [16:21] cjwatson: Well, you said non-virtual has no queue, so it should be ok. [16:21] ChrisTownsend: yeah, that won't need intervention [16:21] cjwatson: Ok, thanks [16:22] we rarely need score hacks nowadays, it's just in the odd exceptional case, and I prefer not to apply them unnecessarily [16:22] cjwatson: I understand and thanks for helping out my build. [16:38] davmor3: The attack of the clone! [16:38] ChrisTownsend: How's the click generation going? [16:39] rvr I wish my laptop just lost connection randomly and can't see the ap at all now [16:39] 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] 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] ChrisTownsend: Thanks [16:43] 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] rvr: And when that finishes, the job will download and extract the deb and then generate a click from it. [16:44] rvr: And we only care about armhf, which of course is the slowest:) [16:44] rvr: Here is the current puritine armhf debian build: https://launchpad.net/~libertine-team/+archive/ubuntu/puritine-devel/+build/9700633 [16:47] 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] ChrisTownsend: [16:48] ChrisTownsend: Yes, I'm testing in frieza [16:49] rvr: Ok. [16:58] bregma: How does the unity8-desktop-mir-session package get released? [16:59] bregma: Would like to get the policykit-unity8 package in there. === alan_g is now known as alan_g|EOW [17:04] bregma: Added a task to bug 1396611 [17:04] bug 1396611 in Canonical System Image "Cannot install click packages on ISO installs of Ubuntu" [High,Confirmed] https://launchpad.net/bugs/1396611 [17:16] jhodapp: get ready for it [17:16] davmor2, :) [17:16] davmor2, woohoo! [17:18] sil2100, can I get some help publish silo 51 please? [17:19] or kenvandine ^ [17:20] jhodapp, looking [17:21] thanks [18:23] ChrisTownsend: Seems it finished [18:24] 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] rvr: Note that I have not tested that at all, so... [18:32] ChrisTownsend: I must leave now, will check later. Downloading... [18:32] rvr: Ok, thanks and thanks for being patient:) [18:39] ChrisTownsend: No problem :) [19:10] 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] Err, trainguards ^^^^ [19:11] 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] robru: Ok, cool, thanks [19:11] ChrisTownsend: yw [19:14] poor vivid [19:29] robru: is that a binary copy? [19:30] slangasek: that was my intention, yes, since it's still early in yakkety [19:31] 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] and while a binary compatibility would be caught in devel-proposed, there's nothing to catch it when copying the other way [19:31] slangasek: alright I'll source copy then [19:32] slangasek: or should we tell him to target xenial? [19:32] you'd need to rebuild with a different version number, no? [19:33] dobey: nah [19:33] different binary contents with same version number == bad though [19:33] dobey: actually overlay is full of xenial packages that'll we'll copy to yakkety soon [19:33] yes, but see what slangasek just said about that :) [19:34] dobey: i don't see an issue there? [19:35] 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] robru: likewise, copying a source from y -> x would be a rebuild, and should have a different (lower) version number [19:35] dobey: yeah. We're doing binary copies from x to y soon [19:36] ChrisTownsend: sorry, you should target xenial then we'll copy it to yakkety after [19:36] robru: Ack [19:36] robru: any idea when we'll be able to do y+x+v landings? :) [19:37] dobey: early next week [19:37] dobey: everything is ready to go, just waiting for go ahead from Pat [19:37] yay [19:39] 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] rdf landings [19:46] robru: targetting xenial and copying forward to yakkety would be ok, yes [19:47] robru: and when is the mass-copy to yakkety planned to happen? [19:47] slangasek: not sure, sil will do it next week sometime [19:48] ChrisTownsend: that will work, yes. Abandon and reassign the same request [19:48] robru: Ok, thanks [19:48] ChrisTownsend: you're welcome [19:56] Yeah, we'll do it 'somewhen' next week, no fully decided week [19:56] s/week/date [19:57] 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] Possibly somewhere mid-next-week we would be doing the batch copy and triple landing switch from robru [20:19] 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. === salem_ is now known as _salem