[03:35] <dobey> trainguards: hi, can someone click retry on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+build/8845368 please? thanks
[03:36] <robru> dobey: on it
[03:41] <robru> dobey: big train rollout today, let me know if you have any issues
[03:44] <dobey> robru: ok, thanks. yeah, i came back from dinner/etc, and saw the request page changed
[03:44] <dobey> was slightly startling :)
[03:44] <robru> dobey: haha, auto reload feature waiting ;-)
[03:45] <robru> Working
[06:38] <Mirv> robru: \o/ for Lander Signoff / QA Signoff
[06:45] <robru> Mirv: sorry that took so long ;-)
[06:46] <Mirv> no problem!
[08:55] <morphis> sil2100, Mirv: morning! time for another silo-upload? :-)
[08:55] <sil2100> morphis: sure thing!
[08:55] <morphis> sil2100: great
[09:52] <jibel> tvoss, ^ it worked, proposed-migration passed and QA status changed to ready, the card should be added to the qa board in 8 min
[09:52] <rvr> mardy: ping
[09:53] <tvoss> jibel, ack
[10:00] <morphis> sil2100: looks like I am running into corner cases everytime :-)
[10:00] <morphis> sil2100: I am right that I can't add a vivid-only MP and a xenial-only MP to a dual-landing silo, right?
[10:00] <sil2100> morphis: hey, yeah... sadly that's not possible, dual landings are either manual uploads or one MP for both :)
[10:01] <morphis> perfect
[10:01] <morphis> sil2100: then I will need three silos ...
[10:09] <mardy> rvr: pong
[10:30] <rvr> mardy: Silo 34
[10:31] <rvr> mardy: There are two programs now installing for Account Tester. What is SASL?
[10:32] <mardy> rvr: you can ignore that, it's not relevant for this silo
[10:32] <mardy> rvr: use the non SASL one
[10:32] <rvr> mardy: Ah, good. Then it's ok :)
[13:21] <dbarth> hey trainguards, i need help to upload an oxide release into a silo
[13:21] <dbarth> this is https://requests.ci-train.ubuntu.com/#/ticket/871 (ie silo 048)
[14:15] <Mirv> dbarth: just give the info what needs to be copied
[14:15] <Mirv> not mozilla-security ppa this time it seems
[14:18] <morphis> Mirv, sil2100: time for another upload?
[14:23] <Mirv> morphis: sure
[14:23] <morphis> Mirv: great
[14:27]  * sil2100 is AFKish for lunch now
[14:28]  * davmor2 bets sil2100 isn't really away and it just pretending
[15:08] <dobey> sil2100: hi. the trust-store dual-landing branch in itself is't critical, but we have it along with some other critical changes to trust-store in the pay-service silo, so that we can land them all together rather than having complexity of landing multiple trust-store silos and then blocking the pay-service changes on those landing first.
[15:15] <sil2100> dobey: hm, ok - need to consult this with some other core-devs
[15:16] <sil2100> But I suppose we could conditionally land it + fill in a bug as we did for media-hub then
[15:16] <dobey> ok
[15:31] <davmor2> sil2100, jibel: both silo 40 and 46 I've marked as qa approved but I've not seen a notice here to tell charles and tvoss is the bot a bit broken now?
[15:32] <charles> davmor2, I appreciate the manual ack, then :-)
[15:32] <sil2100> davmor2: the bot is probably b0rken (e.g. not updated)
[15:33] <davmor2> sil2100: okay add it to the list so it isn't forgotten ;)
[15:33] <sil2100> davmor2: you'd have to poke robru about that, I don't know much abut the bot ;)
[15:33] <sil2100> robru: ^
[15:33]  * sil2100 goes off to publish stuff now
[15:33] <jibel> davmor2, the 'ready for qa' queue is empty then
[15:34] <davmor2> sil2100: I don't care who you blame, it's landing stuff so it's all your fault ;)
[15:34] <jibel> popey, do you know what this request is https://requests.ci-train.ubuntu.com/#/ticket/342 ? seems old
[15:35] <davmor2> jibel: unless our bot needs updating to create new tickets of course :)
[15:35] <popey> it is old.
[15:35] <tvoss> davmor2, my irc nick does not correspond to my launchpad nick
[15:35] <popey> i will re-submit
[15:35] <popey> (a new one)
[15:35] <davmor2> tvoss: no there was no announcement I checked
[15:36] <jibel> sil2100, and what it https://requests.ci-train.ubuntu.com/#/ticket/115 ? it is also marked ready for qa
[15:36] <jibel> is*
[15:36] <jibel> popey, okay I removed the status ready for qa
[15:37] <davmor2> tvoss: see the one above I expected something similar for qa approved which would ping you and sil2100 so you can land it
[15:38] <sil2100> jibel: well, robru mentioned something about old silos possibly having some erroneous statuses
[15:39] <jibel> sil2100, k, i'll remove the status ready for qa too
[15:39] <sil2100> Thanks!
[15:40] <jibel> Yay, ready for QA = 'No Results'
[16:17] <robru> Blah, need to clear lander signoff when ppa gets rebuilt
[16:34] <ChrisTownsend> robru: Hey, when I try setting "QA Signoff" to "N/A", it keeps resetting back to "Required".  Is this expected?
[16:35] <robru> ChrisTownsend: yep, the train is enforcing qa states, anything that targets the phone requires qa
[16:35] <ChrisTownsend> robru: Oh...
[16:36] <robru> ChrisTownsend: i meant to take it a step further and only let qa people set that field, but didn't get around to it yet
[16:37] <ChrisTownsend> robru: Alright.  I'll see what we need to do about QA then.
[16:37] <ChrisTownsend> robru: Thanks
[16:37] <robru> ChrisTownsend: you'll have to explain to a qa person why you think you don't need qa and get them to just approve it without reading anything
[16:37] <robru> ChrisTownsend: yw
[16:37] <ChrisTownsend> robru: Alright
[16:38] <robru> "Without testing anything" (on mobile)
[16:45] <robru> ChrisTownsend: to clarify, it was always a requirement that anything targeting the phone requires qa, it's just that the train was on the honor system before and now it's more rigidly enforcing rules
[16:46] <ChrisTownsend> robru: I understand.  It's just that Libertine is only on the PD image right now, so it's not on the proper phone image.
[16:46] <robru> ChrisTownsend: pd?
[16:46] <ChrisTownsend> robru: Pocket Desktop image.
[16:47] <robru> Ah
[16:47] <robru> ChrisTownsend: i guess just let qa know that it's not in the images then they can rubberstamp it
[16:48] <ChrisTownsend> robru: Right, just trying to figure out who to let know so we can get this moving as it fixes a very critical issue holding up MWC stuff.
[16:49] <robru> ChrisTownsend: probably jibel or davmor2
[16:51] <ChrisTownsend> robru: Ok, thanks
[16:51] <robru> You're welcome
[17:02] <rvr> sil2100: meeting?
[17:58] <ChrisTownsend> robru: Britney sign off failed for https://requests.ci-train.ubuntu.com/#/ticket/875.  Is this something I need to be concerned about?
[17:59] <robru> ChrisTownsend: the excuses page says you have an unsatisfiable depends, so yeah you're going to want to figure that out...
[18:01] <robru> ChrisTownsend: i mean i suppose it's possible that it's a false positive but if you publish the silo in this state it will most likely just get stuck in proposed, so this is an early warning for you
[18:01] <ChrisTownsend> robru: Hmm, ok, I'll look into it, but it's the unsatisfiable depends causing the failures, right?
[18:02] <robru> ChrisTownsend: yup. Note that there's two in vivid and one in xenial
[18:03] <ChrisTownsend> robru: Right, ok.  I think the Vivid one we've accounted for in the past.  Need to check out why the powerpc one is complaining.  Thanks!
[18:03] <robru> ChrisTownsend: you're welcome
[18:57] <charles> yay
[19:36] <dobey> robru: where to the autopkgtests for britney signoff run?
[19:36] <robru> dobey: in bileto
[19:36] <robru> dobey: no wait
[19:36] <robru> dobey: the *autopkgtest* are run in the standard autopkgtest hardware, same as proposed-migration
[19:36] <robru> dobey: bileto is just running britney which triggers them
[19:37] <dobey> hmm
[19:40] <dobey> ok, i think i found the ones triggered by my silo on running now
[19:41] <robru> dobey: yeah the 'running' page is a bit of a maze
[20:00] <dobey> hmm, would be nice if it was a bit more optimized
[20:01] <dobey> having N things in a silo that all trigger different autopkgtest runs for the same package N times is a bit much.
[20:12] <ChrisTownsend> robru: If I rebuild a silo, does the britney test automatically start again?
[20:13] <robru> dobey: raise that with pitti
[20:13] <dobey> omg it takes 1.5hrs to run unity8 autopkgtests?!
[20:13] <robru> ChrisTownsend: as long as the lander signoff is 'Approved' then britney will continuously run and continuously notice new packages & trigger new tests, yeah
[20:14] <dobey> robru: yeah, maybe i'll file a bug. the PPA is added in both, so the sames packages should be installed in both executions anyway.
[20:14] <ChrisTownsend> robru: Hmm, ok.  I've been waiting for a bit and I don't see any evidence that is running again.  How long should I wait?
[20:15] <robru> ChrisTownsend: it currently takes britney about 30m to run, and it's triggered in 5 minute intervals, so generally I'd expect it to update every 35 minutes for the time being.
[20:16] <robru> ChrisTownsend: which request?
[20:16] <ChrisTownsend> robru: Ok...now it says it's running.  I'm just not patient enough:)
[20:16] <ChrisTownsend> robru: Thanks
[20:17] <robru> hehe
[20:18] <dobey> hmm
[20:24] <Saviq> fginther, read my email further down
[20:27] <fginther> Saviq, regarding them "showing up as you go deeper"?
[20:27] <Saviq> fginther, yeah
[20:28] <Saviq> fginther, so you can discover what jobs were triggered from a particular run, not even going up to project, finding the downstream ones and matching them
[20:29] <fginther> Saviq, but can they be found programmatically through the API? That's the problem I see at the moment
[20:29] <Saviq> fginther, https://unity8-jenkins.ubuntu.com/job/lp-unity8-1-ci/73/api/json?depth=4&pretty=true
[20:30] <Saviq> fginther, look for "triggeredBuilds"
[20:30] <Saviq> or rather, look at them
[20:30] <fginther> oh
[20:30] <Saviq> depth could be an arg to voteOnMergeProposal
[20:32] <fginther> I see it now, interesting
[20:33] <fginther> yeah, that would be the way to go. Add the extra "depth=4" to the url and then parse through the triggeredBuilds
[20:34] <fginther> of course the older version of the plugin doesn't output 'triggeredBuilds'
[20:34] <fginther> but that may be a don't care
[20:35] <Saviq> we could leave the current support as is
[20:36] <fginther> Saviq, yes, that shouldn't be too difficult to support both
[20:50] <Saviq> fginther, do you remember, when we were collecting test results from unity8's qmluitests, what was used to parse them? I have the xunit plugin here but have trouble selecting the right parser
[20:51] <fginther> Saviq, they are parsed as JUnit results
[20:52] <fginther> "Publish JUnit test result report"
[20:52] <dobey> robru: ok, so i guess this new thing isn't handling the "always failed" situation?
[20:53] <dobey> robru: https://requests.ci-train.ubuntu.com/#/ticket/780 says "Failed" but there are no failures that weren't "always failed" in the excuses page
[20:53]  * Saviq needs to touch them all, d'oh :/
[20:53] <dobey> hmm, oh weird s390x thing on xenial
[20:54] <robru> dobey: yeah, failures include autopkgtest regressions but also anything 'Not considered' for any other reason
[20:55] <Saviq> fginther, do you know what "Test reports were found but none of them are new." is about?
[20:55] <Saviq> ... is 53 sec old ORLY?
[20:56] <dobey> bah, bloody s390x
[20:56] <fginther> Saviq, not sure. I thought it checked the timestamps of the files as they were parsed in case they were left in the workspace from an old build
[20:56] <Saviq> fginther, well, yeah, I touched them all... 53 sec old is "not new"?
[20:57] <Saviq> unless it compares with job start
[20:57] <fginther> comparing with the job start would make sense
[20:58] <Saviq> \o/
[20:59] <Saviq> seems I just overcomplicated things
[20:59] <Saviq> with the xUnit plugin
[20:59] <fginther> Saviq, FWIW, pretty much everything we did could be consumed by the JUnit parser
[21:00] <Saviq> fginther, not by the xUnit parser for JUnit format, apparently ;)
[21:01] <fginther> :-)
[21:24] <ChrisTownsend> robru: Sorry to keep bothering you, but another question.
[21:24] <robru> ChrisTownsend: please, go ahead
[21:24] <ChrisTownsend> robru: The britney test has failed again, but the log links still point to the old failures.  Does it take a bit for those logs to be updated?
[21:25] <robru> ChrisTownsend: the logs are updated at the same time the status on the ticket is set. what ticket is it?
[21:25] <robru> ChrisTownsend: you might be looking at a cached page, try reloading?
[21:25] <ChrisTownsend> robru: https://requests.ci-train.ubuntu.com/#/ticket/875
[21:26] <ChrisTownsend> robru: Ah, ok, it was cached.
[21:26] <robru> ChrisTownsend: I'm seeing "python3-libertine-chroot/arm64 unsatisfiable Depends: proot" in vivid
[21:27] <ChrisTownsend> robru: Yeah, that is expected.
[21:28] <robru> ChrisTownsend: is that package in the overlay ppa but not in vivid proper or something?
[21:28] <ChrisTownsend> robru: Um, let me check on that.
[21:29] <robru> ChrisTownsend: the way it's currently set up is that as long as that failure stays there, the request will be marked as a failure, but if you go to publish it it'll probably be fine because vivid doesn't go through -proposed when publishing, it's just copied directly to the ppa.
[21:29] <ChrisTownsend> robru: No, the arm64 proot is not in the PPA nor the main archive.
[21:30] <dobey> robru: so if i added another MP and built it in my silo, the britney stuff will pick it up ~35min after it's published in the PPA or what?
[21:30] <robru> dobey: yeah thereabouts.
[21:31] <ChrisTownsend> robru: Ok, thanks again.
[21:31] <robru> dobey: there's timing issues, like I've seen it where britney will run *just* before your binaries get published, and it'll report everything as a failure "no binaries on any arch" or whatever, then it'll fix itself 35 min later.
[21:31] <robru> ChrisTownsend: you're welcome
[21:33] <dobey> robru: yeah, cron jobs will always have weird race issues like that
[21:33] <ChrisTownsend> robru: Now that I'm satisfied with this, do I leave QA Signoff as Required?
[21:34] <dobey> ugh, and like 2/3 of the x86 ppa builders are gone
[21:34] <robru> ChrisTownsend: I guess so. technically you could set it to 'approved' but that's probably a bad habit to get in...
[21:34] <ChrisTownsend> robru: Ready seems appropriate, but it keeps getting set back to Required.
[21:35] <dobey> hmm, although lp builders says those are all virtual
[21:35] <robru> ChrisTownsend: yeah it can't be ready unless britney approves and britney isn't going to approve it.
[21:35] <ChrisTownsend> robru: Ah, ok.
[21:35] <ChrisTownsend> robru: Thanks
[21:35] <robru> ChrisTownsend: you're welcome
[21:35] <dobey> but doesn't show any builders for non-virt x86
[21:38] <ChrisTownsend> ubuntu-qa: Hi, anyone disagree about no QA needed for https://requests.ci-train.ubuntu.com/#/ticket/875 and just setting it to Approved?
[22:45] <kgunn> robru: hey, is there a way to rebuild on train for one specific arch on one specific target archive ?
[22:45] <kgunn> like in case the build failed and it might be a fluke
[22:45] <robru> kgunn: yes! all you have to do is ask me ;-)
[22:45] <kgunn> robru: sweet! silo 36 amd64 for vivid
[22:47] <robru> kgunn: one sec
[22:51] <robru> kgunn: ok it's started apparently the x86 builders are stressed today so it might be slower than usual to build.
[22:52] <kgunn>  np, thanks
[22:55] <robru> you're welcome