[00:16] <kenvandine> rvr, grrr... i thought it was
[00:16] <kenvandine> rvr, approved now :)
[00:16] <kenvandine> it's just dropping a hack to work around the schema issue
[00:16] <rvr> kenvandine: Cool
[03:48] <bzoltan> Mirv:  ehh... this one keeps entertaining me - https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-047/excuses.html
[04:43] <Mirv> bzoltan: rerunning... blame mzanetti for unity8 autopkgtest flakiness :)
[04:49] <bzoltan> Mirv: I do not dare to blame anybody :) he does have enough problems without me already
[04:50] <bzoltan> Mirv: anyway, i have started that landing before the previous one was released in xenial so I think that the diff is not correct. Should I do a rebuild?
[04:53] <Mirv> bzoltan: no, not really. we land only to overlay and I think you started after trunk was merged?
[04:54] <bzoltan> Mirv: yes
[04:54] <Mirv> bzoltan: I believe the xenial diff may be wrong since robru may not have taken into account all corner cases now that we're landing new landings (after landings) to overlay for xenial too
[04:55] <bzoltan> Mirv: is the xenial closed now?
[04:55] <Mirv> robru: now that I saw one problem repeatedly, I'll mention it: with control.gles in there, the UITK packaging changes says every time that there are new binary packages (lists all -gles packages from control.gles)
[04:55] <Mirv> bzoltan: yes, xenial is closed from us unless there's something desktop critical
[05:00] <bzoltan> Mirv: the UITK examples are desktop specific features
[05:01] <bzoltan> Mirv:  it is not like security or performance issue... but the installed examples are useless without the manifest files...
[05:02] <bzoltan> Mirv: But most developers are expected to use the examples from the ubuntu-sdk-dev package... what is built from overlay... so it is not relevant.
[07:38] <mzanetti> Mirv, which one?
[07:56] <bzoltan> Mirv: thanks, now we need this ön a qa fast track https://requests.ci-train.ubuntu.com/#/ticket/1266
[08:12] <bzoltan> rvr: For the SDK IDE release i need the UITK examples be in shape. This silo has the zero functional change fix -> https://requests.ci-train.ubuntu.com/#/ticket/1266 may I get it on a fast track?
[08:15] <Mirv> mzanetti: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-047/xenial/amd64/u/unity8/20160414_202451@/log.gz
[08:16] <Mirv> mzanetti: qmltestrunner::Wizard::test_accountPage() function returned unexpected result
[08:16] <mzanetti> Mirv, ack. will ask ltinkl to stabilize it
[08:16] <Mirv> mzanetti: thanks!
[08:17] <Mirv> robru: the diff:s at https://requests.ci-train.ubuntu.com/#/ticket/1213 (qtpim) are all wrong
[08:20] <mzanetti> what?
[08:20] <mzanetti> that was quick
[09:39] <Mirv> sil2100: so just FYI train diffs seem pretty much as good as broken at the moment
[09:39] <sil2100> Mirv: packaging diffs in overall? Did robru make any changes recently to that?
[09:40] <Mirv> sil2100: overall. not sure, but might be related to the xenial overlay change too. although affects vivid as well.
[09:40] <Mirv> sil2100: for example https://requests.ci-train.ubuntu.com/#/ticket/1266 - vivid diff:s claim the previous 20160412 landing would not be in overlay while it is, and xenial diffs are empty
[09:40] <sil2100> huh
[09:42] <Mirv> sil2100: qtpim https://requests.ci-train.ubuntu.com/#/ticket/1213 is another example. they're like diffed in wrong direction and also to a really old version.
[09:42] <sil2100> Ok, that looks strange indeed, the empty xenial diffs I could understand due to the switch to overlay in xenial (might need some tweaking) - but the vivid ones worry me
[10:32] <rvr> bzoltan: Sure
[10:47] <davmor2> morphis: get ready for it
[10:49] <morphis> davmor2: yeah!
[10:52] <Mirv> rvr: commented on https://trello.com/c/nFp6LOrW/3063-1213-ubuntu-landing-039-qtpim-opensource-src-renatofilho-timo-jyrinki earlier
[10:53] <rvr> Mirv: Ah, great
[10:54] <rvr> Mirv: Which apps do use qtpim datetime functions?
[11:00] <Mirv> rvr: I'd refer to renato or bfiller for definitive list, but calendar would be the obvious one, likely dialer/messaging too for the timestamps
[11:00] <Mirv> (neither of them is online yet)
[11:01] <rvr> Mirv: Ok
[11:13] <bzoltan> rvr: thank you
[13:26] <sil2100> oSoMoN: hey! Did you have a moment to take a look at the browser/oxide bug we're encountering in the emulator?
[13:28] <oSoMoN> sil2100, yes, I’ve commented on it
[13:44] <dobey> sil2100: can you do https://autopkgtest.ubuntu.com/request.cgi?release=vivid&arch=armhf&package=unity-scope-click&trigger=pay-service%2F15.10%2B15.04.20160413-0ubuntu1&ppa=ci-train-ppa-service%2Fstable-phone-overlay&ppa=ci-train-ppa-service%2Flanding-061 please?
[13:44] <sil2100> dobey: done
[13:44] <dobey> sil2100: thanks!
[13:44] <sil2100> yw!
[13:46] <sil2100> oSoMoN: thanks! Nice to hear we at least have a possible workaround
[13:51] <oSoMoN> sil2100, yeah, but we should really be getting to the bottom of things, i.e. understand why GL in the emulator thinks GL_SHADING_LANGUAGE_VERSION is an invalid value
[13:54] <Elleo> trainguards: heya, could someone kick off a rebuild of just the vivid arm64 build for silo 37?
[13:54] <sil2100> Elleo: on it
[13:55] <Elleo> sil2100: thanks :)
[13:55] <sil2100> Elleo: done :)
[13:55] <Elleo> sil2100: great, thanks
[13:59] <sil2100> yw!
[17:06] <robru> sil2100: Mirv: re: diffs, I would expect a slight hiccup with xenial diffs where the first silo since a switch would not be able to generate a xenial diff because there's no xenial package in the overlay ppa, however vivid diffs should be totally fine and unaffected. all subsequent silos should be diffing correctly against the xenial packages in xeenial
[17:06] <robru> overlay
[17:32] <robru> Mirv: I regenerated your qtpim diffs and they are much smaller now, can you confirm that they're correct? next time you see any diff issues just regenerate first then complain if they're stil wrong after that
[18:07] <popey> robru: do you look after the rights for people to create tasks on https://requests.ci-train.ubuntu.com/ ?
[18:07] <popey> DanChapman (dekko maintainer needs to be able to
[18:12] <robru> popey: I do (also sil)
[18:13] <robru> popey: he's not a canonical employee is he? generally only canonical people are accepted (there's only one non-canonical person currently, it's quite exceptional)
[20:00] <bzoltan> jibel: rvr: would there be any chance to publish the silo47 content? It is a super critical fix for the IDE and Xenial is closing for real in no time... this change is a super minor, but very important for me
[20:05] <rvr> bzoltan: It just changes code in examples, right?
[20:33] <rvr> bzoltan: Done
[21:39] <Saviq> robru, hey, any idea what https://jenkins.canonical.com/system-apps/job/run-commands/node=cyclops-node19/lastBuild/console is about?
[22:03] <boiko> trainguards: can someone please trigger a rebuild of telephony-service/arm64 for both vivid and xenial on silo 55?
[22:15] <robru> Saviq: i dunno, that's jenkaas
[22:16] <Saviq> robru, I know that's jenkaas, just asking if the error means anything to you
[22:18] <robru> Saviq: it looks the chroot isn't found, sorry, i dunno why
[22:18] <Saviq> robru, grr wrong link ;)
[22:18] <Saviq> robru, anyway, recreating the chroot
[22:18] <Saviq> robru, https://jenkins.canonical.com/system-apps/job/run-commands/node=cyclops-node19/16/console was the issue
[22:18] <Saviq> will see if that's a problem still after the chroot is recreated
[22:57] <Saviq> plars, hey, good news: my arale seems to be working reliably now with the wait/reboot approach - I will monitor whether the reboot is actually needed https://unity8-jenkins.ubuntu.com/computer/arale-01/builds
[22:58] <Saviq> plars, on less good news, system apps team has a weird issue I can't pinpoint: https://jenkins.canonical.com/system-apps/job/run-commands/node=cyclops-node19/18/console
[22:59] <plars> Saviq: no problems are allowed to happen on friday night!
[22:59] <plars> Saviq: j/k :) looking
[22:59] <Saviq> plars, the armhf chroot on cyclops have trouble with apt-get update - for whatever reason apt decides apt-key is broken
[23:00] <Saviq> plars, I can't repro that anywhere else
[23:02] <Saviq> plars, if you've ssh access to the box - if you could poke about, I'd be obliged
[23:03] <plars> Saviq: something broken with your schroot perhaps?
[23:03] <Saviq> plars, yeah I recreated it and same thing...
[23:06] <plars> Saviq: try again, should be better now
[23:06] <plars> Saviq: you did, indeed, have a duplicate entry in /etc/apt/sources.list. If you didn't put it there, then bad update I guess?
[23:10] <Saviq> plars, hah, wonder what's happened there - thanks, will have a look what happened there
[23:13] <Saviq> plars, huh, where did you find the dupe entries? https://jenkins.canonical.com/system-apps/job/run-commands/21/node=cyclops-node19/console looks fine wrt sources.list on the other node, apt still complains?
[23:15] <plars> Saviq: /etc/apt.source.list had two versions of 'deb http://ports.ubuntu.com/ubuntu-ports trusty-backports main restricted multiverse universe'
[23:20] <Saviq> plars, aah you mean the node itself
[23:22] <Saviq> plars, ok, thanks for the help - I know where the problem is then
[23:42] <Saviq> plars, hmm so it wasn't that after all, that single node behaves weird
[23:43] <plars> Saviq: it's still doing it?
[23:43] <Saviq> plars, yeah, try `schroot -d / -u root apt-get update`
[23:43] <Saviq> erm
[23:43] <Saviq> -c xenial-armhf
[23:44] <plars> Saviq: I get: E: default: Chroot not found
[23:45] <Saviq> plars, schroot -c xenial-armhf -d / -u root apt-get update
[23:45] <Saviq> sry
[23:48] <Saviq> plars, gtg, don't sweat it - we can pick it up next week