=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== fginther` is now known as fginther | ||
dbarth | hey Mirv | 08:13 |
---|---|---|
dbarth | mardy and I are wondering how to land https://requests.ci-train.ubuntu.com/#/ticket/1219 | 08:13 |
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:14 |
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:16 |
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:17 |
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:18 |
dbarth | ok | 08:20 |
sil2100 | bzoltan_: hey! So, any changes in UITK that would warrant a new framework for OTA-11? | 08:30 |
sil2100 | At least from the UITK point of view | 08:31 |
bzoltan_ | sil2100: i am digging up the api changes right now | 08:34 |
sil2100 | bzoltan_: thanks :) | 08:35 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
oSoMoN | chrisccoulson, does chromium build on arm64? | 09:09 |
chrisccoulson | oSoMoN, on android, I believe so | 09:23 |
sil2100 | oSoMoN, chrisccoulson: would be nice if we were able to make it building, otherwise our "big plan" might be endangered | 09:32 |
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:33 |
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:34 |
morphis | sil2100: can you retry with https://requests.ci-train.ubuntu.com/#/ticket/1370 ? | 09:36 |
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:39 |
morphis | sil2100: yes, I am ok with that | 09:46 |
bzoltan_ | sil2100: so... I have the scientifical and official answer to you :) | 09:47 |
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:48 |
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:49 |
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:51 |
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:52 |
bzoltan_ | sil2100: shame that so little change forces us to bump | 09:53 |
morphis | sil2100: it failed again | 10:02 |
morphis | that is interesting | 10:02 |
morphis | sil2100: but it doesn't seem to be because of hybris | 10:03 |
sil2100 | hm, yeah | 10:20 |
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:21 |
sil2100 | tvoss: could you take a look at the papi build failure I mentioned above? Looks like some test is constantly failing now | 10:22 |
=== 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 | ||
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:47 |
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:48 |
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:49 |
bregma | ever since the ido scandal | 13:50 |
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:10 |
sil2100 | ;) | 14:11 |
tedg | Haha, nice. | 14:12 |
robru | cjwatson: was it perl? it was perl, wasn't it? | 14:18 |
cjwatson | robru: don't recall, possible | 14:19 |
cjwatson | if it was it's not in perl itself any more | 14:20 |
robru | heh, you checked | 14:23 |
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! | 14:34 |
ChrisTownsend | rvr: silo 15 is good to go! | 15:45 |
rvr | ChrisTownsend: Just installed it ;D | 15:47 |
ChrisTownsend | rvr: Thanks! | 15:47 |
rvr | ChrisTownsend: I still don't see the gedit icon in the Launcher | 16:01 |
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:02 |
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:03 |
ChrisTownsend | rvr: Hmm... | 16:04 |
bregma | rvr, it needs a new Puritine click | 16:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
rvr | ChrisTownsend: The gedit icon in the App scope is fine. But the gedit icon in the Launcher is missing as before. | 16:10 |
rvr | I can't reproduce it easily, but I got a bad window flickering in gedit's top left side | 16:11 |
cjwatson | ChrisTownsend: LP builders? | 16:12 |
ChrisTownsend | cjwatson: Yes | 16:13 |
cjwatson | ChrisTownsend: poked, should clear up soon | 16:13 |
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:14 |
ChrisTownsend | cjwatson: It's this PPA: https://launchpad.net/~libertine-team/+archive/ubuntu/devel/+packages | 16:17 |
cjwatson | ChrisTownsend: scored up | 16:18 |
ChrisTownsend | cjwatson: Thanks again! | 16:19 |
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:20 |
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:21 |
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:22 |
rvr | davmor3: The attack of the clone! | 16:38 |
rvr | ChrisTownsend: How's the click generation going? | 16:38 |
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:39 |
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:42 |
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:43 |
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:44 |
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:47 |
rvr | ChrisTownsend: | 16:48 |
rvr | ChrisTownsend: Yes, I'm testing in frieza | 16:48 |
ChrisTownsend | rvr: Ok. | 16:49 |
tedg | bregma: How does the unity8-desktop-mir-session package get released? | 16:58 |
tedg | bregma: Would like to get the policykit-unity8 package in there. | 16:59 |
=== alan_g is now known as alan_g|EOW | ||
tedg | bregma: Added a task to bug 1396611 | 17:04 |
ubot5 | bug 1396611 in Canonical System Image "Cannot install click packages on ISO installs of Ubuntu" [High,Confirmed] https://launchpad.net/bugs/1396611 | 17:04 |
davmor2 | jhodapp: get ready for it | 17:16 |
jhodapp | davmor2, :) | 17:16 |
jhodapp | davmor2, woohoo! | 17:16 |
jhodapp | sil2100, can I get some help publish silo 51 please? | 17:18 |
jhodapp | or kenvandine ^ | 17:19 |
kenvandine | jhodapp, looking | 17:20 |
jhodapp | thanks | 17:21 |
rvr | ChrisTownsend: Seems it finished | 18:23 |
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:24 |
rvr | ChrisTownsend: I must leave now, will check later. Downloading... | 18:32 |
ChrisTownsend | rvr: Ok, thanks and thanks for being patient:) | 18:32 |
rvr | ChrisTownsend: No problem :) | 18:39 |
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:10 |
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:11 |
dobey | poor vivid | 19:14 |
slangasek | robru: is that a binary copy? | 19:29 |
robru | slangasek: that was my intention, yes, since it's still early in yakkety | 19:30 |
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:31 |
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:32 |
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:33 |
robru | dobey: i don't see an issue there? | 19:34 |
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:35 |
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:36 |
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:37 |
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:39 |
jgdx | rdf landings | 19:45 |
slangasek | robru: targetting xenial and copying forward to yakkety would be ok, yes | 19:46 |
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:47 |
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:48 |
sil2100 | Yeah, we'll do it 'somewhen' next week, no fully decided week | 19:56 |
sil2100 | s/week/date | 19:56 |
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 | 19:57 |
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. | 20:19 |
=== salem_ is now known as _salem |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!