[03:35] trainguards: hi, can someone click retry on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+build/8845368 please? thanks [03:36] dobey: on it [03:41] dobey: big train rollout today, let me know if you have any issues [03:44] robru: ok, thanks. yeah, i came back from dinner/etc, and saw the request page changed [03:44] was slightly startling :) [03:44] dobey: haha, auto reload feature waiting ;-) [03:45] Working [06:38] robru: \o/ for Lander Signoff / QA Signoff [06:45] Mirv: sorry that took so long ;-) [06:46] no problem! === chihchun_afk is now known as chihchun [08:55] sil2100, Mirv: morning! time for another silo-upload? :-) [08:55] morphis: sure thing! [08:55] sil2100: great [09:52] 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] mardy: ping [09:53] jibel, ack [10:00] sil2100: looks like I am running into corner cases everytime :-) [10:00] 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] morphis: hey, yeah... sadly that's not possible, dual landings are either manual uploads or one MP for both :) [10:01] perfect [10:01] sil2100: then I will need three silos ... [10:09] rvr: pong [10:30] mardy: Silo 34 [10:31] mardy: There are two programs now installing for Account Tester. What is SASL? [10:32] rvr: you can ignore that, it's not relevant for this silo [10:32] rvr: use the non SASL one [10:32] mardy: Ah, good. Then it's ok :) === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === _salem is now known as salem_ === alan_g is now known as alan_g|afk [13:21] hey trainguards, i need help to upload an oxide release into a silo [13:21] this is https://requests.ci-train.ubuntu.com/#/ticket/871 (ie silo 048) === chihchun is now known as chihchun_afk [14:15] dbarth: just give the info what needs to be copied [14:15] not mozilla-security ppa this time it seems [14:18] Mirv, sil2100: time for another upload? [14:23] morphis: sure [14:23] 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] 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] dobey: hm, ok - need to consult this with some other core-devs [15:16] But I suppose we could conditionally land it + fill in a bug as we did for media-hub then [15:16] ok [15:31] 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] davmor2, I appreciate the manual ack, then :-) [15:32] davmor2: the bot is probably b0rken (e.g. not updated) [15:33] sil2100: okay add it to the list so it isn't forgotten ;) [15:33] davmor2: you'd have to poke robru about that, I don't know much abut the bot ;) [15:33] robru: ^ [15:33] * sil2100 goes off to publish stuff now [15:33] davmor2, the 'ready for qa' queue is empty then [15:34] sil2100: I don't care who you blame, it's landing stuff so it's all your fault ;) [15:34] popey, do you know what this request is https://requests.ci-train.ubuntu.com/#/ticket/342 ? seems old [15:35] jibel: unless our bot needs updating to create new tickets of course :) [15:35] it is old. [15:35] davmor2, my irc nick does not correspond to my launchpad nick [15:35] i will re-submit [15:35] (a new one) [15:35] tvoss: no there was no announcement I checked [15:36] sil2100, and what it https://requests.ci-train.ubuntu.com/#/ticket/115 ? it is also marked ready for qa [15:36] is* [15:36] popey, okay I removed the status ready for qa [15:37] 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] jibel: well, robru mentioned something about old silos possibly having some erroneous statuses [15:39] sil2100, k, i'll remove the status ready for qa too [15:39] Thanks! [15:40] Yay, ready for QA = 'No Results' === chihchun_afk is now known as chihchun [16:17] Blah, need to clear lander signoff when ppa gets rebuilt [16:34] robru: Hey, when I try setting "QA Signoff" to "N/A", it keeps resetting back to "Required". Is this expected? [16:35] ChrisTownsend: yep, the train is enforcing qa states, anything that targets the phone requires qa [16:35] robru: Oh... [16:36] 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] robru: Alright. I'll see what we need to do about QA then. [16:37] robru: Thanks [16:37] 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] ChrisTownsend: yw [16:37] robru: Alright [16:38] "Without testing anything" (on mobile) [16:45] 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] 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] ChrisTownsend: pd? [16:46] robru: Pocket Desktop image. [16:47] Ah [16:47] ChrisTownsend: i guess just let qa know that it's not in the images then they can rubberstamp it [16:48] 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] ChrisTownsend: probably jibel or davmor2 [16:51] robru: Ok, thanks [16:51] You're welcome [17:02] sil2100: meeting? === timp is now known as t1mp === chihchun is now known as chihchun_afk [17:58] 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] ChrisTownsend: the excuses page says you have an unsatisfiable depends, so yeah you're going to want to figure that out... [18:01] 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] robru: Hmm, ok, I'll look into it, but it's the unsatisfiable depends causing the failures, right? [18:02] ChrisTownsend: yup. Note that there's two in vivid and one in xenial [18:03] 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] ChrisTownsend: you're welcome [18:57] yay [19:36] robru: where to the autopkgtests for britney signoff run? [19:36] dobey: in bileto [19:36] dobey: no wait [19:36] dobey: the *autopkgtest* are run in the standard autopkgtest hardware, same as proposed-migration [19:36] dobey: bileto is just running britney which triggers them [19:37] hmm [19:40] ok, i think i found the ones triggered by my silo on running now [19:41] dobey: yeah the 'running' page is a bit of a maze [20:00] hmm, would be nice if it was a bit more optimized [20:01] having N things in a silo that all trigger different autopkgtest runs for the same package N times is a bit much. [20:12] robru: If I rebuild a silo, does the britney test automatically start again? [20:13] dobey: raise that with pitti [20:13] omg it takes 1.5hrs to run unity8 autopkgtests?! [20:13] 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] 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] 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] 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] ChrisTownsend: which request? [20:16] robru: Ok...now it says it's running. I'm just not patient enough:) [20:16] robru: Thanks [20:17] hehe [20:18] hmm [20:24] fginther, read my email further down [20:27] Saviq, regarding them "showing up as you go deeper"? [20:27] fginther, yeah [20:28] 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] Saviq, but can they be found programmatically through the API? That's the problem I see at the moment [20:29] fginther, https://unity8-jenkins.ubuntu.com/job/lp-unity8-1-ci/73/api/json?depth=4&pretty=true [20:30] fginther, look for "triggeredBuilds" [20:30] or rather, look at them [20:30] oh [20:30] depth could be an arg to voteOnMergeProposal [20:32] I see it now, interesting [20:33] yeah, that would be the way to go. Add the extra "depth=4" to the url and then parse through the triggeredBuilds [20:34] of course the older version of the plugin doesn't output 'triggeredBuilds' [20:34] but that may be a don't care [20:35] we could leave the current support as is [20:36] Saviq, yes, that shouldn't be too difficult to support both [20:50] 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] Saviq, they are parsed as JUnit results [20:52] "Publish JUnit test result report" [20:52] robru: ok, so i guess this new thing isn't handling the "always failed" situation? [20:53] 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] hmm, oh weird s390x thing on xenial [20:54] dobey: yeah, failures include autopkgtest regressions but also anything 'Not considered' for any other reason [20:55] fginther, do you know what "Test reports were found but none of them are new." is about? [20:55] ... is 53 sec old ORLY? [20:56] bah, bloody s390x [20:56] 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] fginther, well, yeah, I touched them all... 53 sec old is "not new"? [20:57] unless it compares with job start [20:57] comparing with the job start would make sense [20:58] \o/ [20:59] seems I just overcomplicated things [20:59] with the xUnit plugin [20:59] Saviq, FWIW, pretty much everything we did could be consumed by the JUnit parser [21:00] fginther, not by the xUnit parser for JUnit format, apparently ;) [21:01] :-) [21:24] robru: Sorry to keep bothering you, but another question. [21:24] ChrisTownsend: please, go ahead [21:24] 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] ChrisTownsend: the logs are updated at the same time the status on the ticket is set. what ticket is it? [21:25] ChrisTownsend: you might be looking at a cached page, try reloading? [21:25] robru: https://requests.ci-train.ubuntu.com/#/ticket/875 [21:26] robru: Ah, ok, it was cached. === salem_ is now known as _salem [21:26] ChrisTownsend: I'm seeing "python3-libertine-chroot/arm64 unsatisfiable Depends: proot" in vivid [21:27] robru: Yeah, that is expected. [21:28] ChrisTownsend: is that package in the overlay ppa but not in vivid proper or something? [21:28] robru: Um, let me check on that. [21:29] 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] robru: No, the arm64 proot is not in the PPA nor the main archive. [21:30] 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] dobey: yeah thereabouts. [21:31] robru: Ok, thanks again. [21:31] 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] ChrisTownsend: you're welcome [21:33] robru: yeah, cron jobs will always have weird race issues like that [21:33] robru: Now that I'm satisfied with this, do I leave QA Signoff as Required? [21:34] ugh, and like 2/3 of the x86 ppa builders are gone [21:34] ChrisTownsend: I guess so. technically you could set it to 'approved' but that's probably a bad habit to get in... [21:34] robru: Ready seems appropriate, but it keeps getting set back to Required. [21:35] hmm, although lp builders says those are all virtual [21:35] ChrisTownsend: yeah it can't be ready unless britney approves and britney isn't going to approve it. [21:35] robru: Ah, ok. [21:35] robru: Thanks [21:35] ChrisTownsend: you're welcome [21:35] but doesn't show any builders for non-virt x86 [21:38] 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] robru: hey, is there a way to rebuild on train for one specific arch on one specific target archive ? [22:45] like in case the build failed and it might be a fluke [22:45] kgunn: yes! all you have to do is ask me ;-) [22:45] robru: sweet! silo 36 amd64 for vivid [22:47] kgunn: one sec [22:51] kgunn: ok it's started apparently the x86 builders are stressed today so it might be slower than usual to build. [22:52] np, thanks [22:55] you're welcome