=== josepht` is now known as josepht === salem_ is now known as _salem === slangase` is now known as slangasek [05:37] Trevinho: not top-approved, couldn't publish silo 028 https://code.launchpad.net/~feng-kylin/unity/lp_1573897/+merge/292883 === chihchun_afk is now known as chihchun [08:21] Mirv, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#indicator-network won't pass without --all-proposed until a unity8 migrates === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:41] Saviq: we will need serious foundations team support anyway with getting yakkety migrating - there's now a billion things that are preventing each other from migrating [08:42] we even got new KDE [08:42] Mirv, yup [08:43] Mirv, but at least unity8 should be unblocked soon [08:44] which blocked a lot of other things === ogra_` is now known as ogra_ === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === sil2100 changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? Use JenkaaS: http://bit.ly/jenkins-docs | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known issues: no free silos! [10:13] rvr, fifteenth time the charm? ;) (re: silo 58 testing) [10:13] Saviq: Is it ready this time? :D [10:13] rvr, AFAICT, yes [10:14] Good, good [10:14] rvr, it was always ready, and then became not... [10:14] and then it was ready again... and then not [10:14] aand... you know the drill ;) === chihchun is now known as chihchun_afk [10:57] Mirv, sil2100, hey, need a bit of a packaging hand, if I have a B-D: foo[!armhf], bar[armhf] - how do I add the same for arm64? separate line? [10:57] no way to do [!armhf,!arm64] or somethin? [11:21] Saviq: hm, wouldn't [!armhf !arm64] work? Not sure if it works for negations [11:21] [armhf arm64] should certainly work though [11:21] ah [11:21] space [11:23] hmm looky like arm64 cross-build for cmake is broken [11:24] aarch64-linux-gnu-cc not there [11:24] or I'm missing something [12:02] ooh, out of silos [12:03] sil2100, what say you that we merge&clean silos that are blocked on yakkety migration? [12:28] Saviq: I think selectively yes we should clean, but more like when it's quite certain there are no migration surprises that comes from the landing itself [12:28] anyway, right now there's one free [12:33] Mirv, https://requests.ci-train.ubuntu.com/#/ticket/1450 can be merged IMO === alex-abreu|off is now known as alex-abreu [12:39] Saviq: done. we need to monitor the full yakkety situation for a while anyway. [12:46] Mirv, yup === _salem is now known as salem_ [13:11] jibel, sil2100, FYI: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-005/+build/9799124 [13:11] adding to our next silo === chihchun_afk is now known as chihchun === mardy_ is now known as mardy [14:08] Saviq, something pyton-related appears broken now.. I wonder how did it pass earlier with my ftbfs fix. https://launchpadlibrarian.net/261391362/buildlog_ubuntu-yakkety-ppc64el.unity-scopes-shell_0.5.7+16.10.20160524-0ubuntu1_BUILDING.txt.gz [14:09] pstolowski, something must've showed up in proposed since then [14:09] pstolowski, and you should really move to py3 ;) [14:09] our tests need python-tornado; and it requires singledispatch module which is not installed [14:11] pstolowski, lemme get a yakkety container, sec [14:13] Saviq, I know, but I prefer to pick time to do that ;) [14:24] Saviq, yeah, reproduced in a container locally. python-tornado has changed [14:24] Saviq, after installing python-backports-abc and singledispatch modules the test passes [14:25] pstolowski, sounds like you wanna those depends (and migrate to py3) [14:25] Saviq, so cleary the dependencies of python-tornado were changed (are broken now) [14:25] pstolowski, https://launchpad.net/ubuntu/+source/python-tornado/4.3.0-1ubuntu1 [14:25] "* Added dep on singledispatch and backports_abc." [14:26] pstolowski, wonder if this was a temporary fail [14:29] w00t http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 "Valid candidate" [14:29] Saviq, hmm i don't get it, that was on May 16 [14:30] pstolowski, but it only got uploaded 6h ago [14:30] pstolowski, that changelog is from debian, I suppsoe [14:31] pstolowski, btw, good news http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-shell "Valid candidate" [14:31] things are migrating again [14:31] Mirv, sil2100 ↑↑ [14:34] Saviq, hmm but Y has 4.3.0-1ubuntu1 and it doesn't have these deps [14:35] pstolowski, could be a bad merge from debian [14:36] pstolowski, ping LocutusOfBorg on #ubuntu-devel maybe [14:37] Saviq, yeah, he is offline [14:44] pstolowski, file a bug then [14:44] Saviq, k. in the meantime i'll add a workaround [14:44] pstolowski, yeah, probably don't wanna land it though [14:50] Saviq, I can revert in the next landing [14:50] anyway, the bug https://bugs.launchpad.net/ubuntu/+source/python-tornado/+bug/1585238 [14:50] Launchpad bug 1585238 in python-tornado (Ubuntu) "Missing singledispatch and bacports-abc dependency" [Undecided,New] [14:50] pstolowski, yeah you could [14:51] pstolowski, confirmed [14:51] tx [15:16] Mirv, ping [15:24] sil2100, ping [15:46] rvr, WOOOOT [15:47] Saviq: I am going to buy a micro HDMI adaptor to check the remaining test case [15:47] Everything else seems fine [15:48] rvr, which one? can I help so we can push it through quicker? [15:51] Saviq, python workaround doesn't help, one of these packages doesn't exist in vivid/xenial :/ [15:52] pstolowski, (<< ) | [15:53] Saviq, hmm can you elaborate? [15:54] pstolowski, python-$whateveritwas | python-tornado (<< $yakkety_version), python-$theotherwhatever | python-tornado (<< $yakkety_version), python-tornado [15:54] I think that should work [15:59] Saviq, nice idea, trying [16:08] charles_, i see silo 50 wasn't a trio silo... [16:09] charles_, mind if i go ahead an publish that, with a manual copy to yakkety? [16:34] sil2100: ubuntu-touch-meta 1.270 adds arm64, but ubuntu-touch appears to not be installable there, and this apparently blocks the gdal/ctemplate/qgis/tinyxml transition [16:44] koza, i kicked a rebuild of silo 0 since i just published another landing [16:44] koza, what's the status of that silo? [16:45] kenvandine: he is on holiday till next week [16:45] ah... that's why :) [17:08] Saviq: Silo 58 approved [17:08] rvr, awesome, thanks [17:08] Saviq, ooh [17:08] just noticed :) [17:09] and we actually migrated too https://launchpad.net/ubuntu/+source/unity8 [17:09] just in time [17:09] mterry, publish please https://requests.ci-train.ubuntu.com/#/ticket/1381 [17:42] jgdx: did you just convert to trio? One more build should overcome that error [17:42] robru, that was me. I'm on it :) [17:43] mterry: OK. This is the issue I mentioned in the email, only happens if you do a trio build same day as the last dual build [17:43] yeah [17:44] I don't actually need it to build, just wanted to get it in the right place so that next time we need it to build today, it will [17:45] Saviq, why does silo 58 mark qtmir-gles in vivid and xenial as UNAPPROVED? that's just going into the overlay, right? [17:46] mterry, huh it should, it's a triple silo [17:46] robru, ↑↑? [17:47] Saviq, yeah and the yakkety upload seems to have gone well [17:48] mterry, hmm publish job says the right thing https://ci-train.ubuntu.com/job/ubuntu-landing-058-2-publish/11/console [17:49] mterry, it did, however, push it to xenial and vivid queues https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=qtmir https://launchpad.net/ubuntu/vivid/+queue?queue_state=1&queue_text=qtmir [17:50] Saviq, oh ick [17:50] I think it forgot to push qtmir-gles to overlay and SRUd them... [17:50] robru, BUUUG [17:51] robru, would you mind trying to publish this please: https://requests.ci-train.ubuntu.com/#/ticket/1436 [17:51] mterry, can you help jhodapp ↑ [17:51] sure [17:51] thanks [17:51] gotta have robru's full attention for silo 58 :) [17:51] jhodapp: I can't publish anything you can't [17:52] no worries [17:52] robru, ok for some reason I thought that had changed [17:53] jhodapp: I used to be able to publish stuff but that was a long time ago [17:53] k no worries [17:53] mterry: Saviq huh looks like gles gets the wrong dest. Will fix asap [17:53] jhodapp, ↑ [17:53] i fixed it [17:53] not sure if you're getting queuebot pings, I don't [17:54] ah ack [17:54] full service [17:54] thanks mterry [17:54] Saviq, I don't either! Wasn't sure why my client ignored it. It also prints the bot in purple [17:54] Must know it's special. But not sure why it thinks I don't want the pings [17:55] * Saviq changed to "Notify each message" [17:55] looks scary but let's se [17:56] queuebot, care to ping me about something? ;P [17:56] Saviq: mterry: queuebot messages are "channel notices" instead of normal messages, some irc clients treat that stupidly. [18:00] mterry: do you have the power to reject those gles uploads from xenial/vivid queues? code is fixed on trunk, should roll to production in ~20, I copied the packages into overlay so it'll soon update to 'Release pocket', just need to clear them from the UNAPPROVED queue. [18:00] robru, I don't, try an archive admin [18:00] mterry: ok, just pinged in #ubuntu-release [18:08] * mterry is going to cafe for better internet, bbiab === chihchun is now known as chihchun_afk [18:32] Yay [18:32] Brb [18:39] Saviq, remind me what controls when ci-train merges the branches into trunk? It doesn't wait until proposed migration is over, surely? (/me wants to respin silo 59 and do final testing) [18:42] or robru ^ [18:48] mterry: it does wait for migrating to the release pocket [18:48] sil2100, oh wow ok [18:48] So it doesn't auto-merge the silo until it's at the final destination, just in case some of your changes cause the packages to be blocked in -proposed etc. [18:49] sil2100, ok thanks [18:50] mterry: heh, "surely", yes the purpose of waiting for proposed is so that if your package explodes in proposed then you'll be responsible for it, rather than fire-and-forget. [18:50] mterry: force-merging is allowed if you're in a huge hurry and you have a silo with the same packages in it, so when you publish that other one you'll still be monitoring proposed. [18:51] but generally discouraged. [18:51] robru, I can wait :) === salem_ is now known as _salem [22:16] robru, sil2100: I get this error when building u8 in a silo right now: "unity8 8.12+16.10.20160520.1-0ubuntu1 is missing from the changelog, which has up to 8.12+16.04.20160518.1-0ubuntu1. Please sync destination version back to trunk." -- sounds like it wants me to sync from yakkety-proposed, but the train hasn't merged that version into trunk yet for me to merge. Is this an expected no-mans-land wait period, or is there something I'm not do [22:16] ing right? [22:18] mterry: yes this is an expected result of conflicting silos, you can force build if you really want to build but you'll just have to rebuild again later once it merges [22:19] robru, go it, force build it is, thanks. Not really conflicting, since I'm dealing with a testing silo, which is not uncommon, I'd have thought [22:20] robru, I see in the text for the "force build" option that it mentions this scenario, but might be nice if the error message from the train suggested that if the user doesn't care about the drawbacks you mentioned [22:20] mterry: "conflicting silos" in train terms just means two silos that have one or more of the same source package. In this case one has been published so building others is discouraged since the build won't include published one [22:20] robru, but thanks for setting me straight :) [22:21] robru, right of course. Just saying that for testing silos, it doesn't matter as much, and conflicting/discouraged are stronger language than I would use [22:22] mterry: file a bug? Btw i added support for comments to my big branch, hopefully that'll hit production within a week [22:22] * mterry hugs robru [22:22] Hehe [22:25] robru, https://bugs.launchpad.net/bileto/+bug/1585393 [22:25] Launchpad bug 1585393 in Bileto "Suggest "force build" to user when a version in distro hasn't landed in trunk yet" [Undecided,New] [22:26] guh, now I see 503 errors.. [22:26] mterry: thanks [22:26] * mterry signs off, can't deal with this now :) [22:26] mterry: lp is fussy, give it time [22:27] cheers!