[06:48] <ginggs> Would someone please 'force-badtest r-cran-surveillance/1.13.0-1' ?  The tests were broken in the release pocket by the upload of gdata/2.18.0-1
[07:30] <tsimonq2> stgraber: I think we're still on for Alpha 1, can you set the archive freeze and spin up the images please?
[07:30] <tsimonq2> stgraber: Or set something in iso.qa.ubuntu.com, rather.
[07:31] <tsimonq2> stgraber: All of the participating flavors are indicated here: https://wiki.ubuntu.com/ArtfulAardvark/Alpha1
[07:36] <acheronuk> tsimonq2: just need to quickly update kubuntu meta
[07:40] <tsimonq2> acheronuk: ack
[07:40] <acheronuk> will upload in a few secs when the script finishes
[07:40] <tsimonq2> wfm
[07:41] <acheronuk> tsimonq2: ???
[07:42] <tsimonq2> acheronuk: works for me
[07:42] <acheronuk> oh, right
[07:42] <tsimonq2> yeah
[07:42] <tsimonq2> lol
[07:42] <tsimonq2> acheronuk: Either way I don't think stgraber is around.
[07:42] <tsimonq2> My sleep schedule is erratic as it is...
[07:42]  * acheronuk makes more coffee to wake up the acronym cells
[07:42] <apw> normally the freezes are at around 1800 UTC
[07:43] <apw> (or so it seems to me)
[07:43] <tsimonq2> apw: *shrug*
[07:43] <acheronuk> yeah, though would be just my luck to miss it if I assumed that
[07:43] <apw> heh there is that
[07:44] <tsimonq2> acheronuk: Good idea. *fetches coffee when it's almost 3 AM*
[07:44] <acheronuk> oi! you should sleep sometime!
[07:45] <tsimonq2> That's what the daytime is for. :P
[07:50] <acheronuk> lol.... uploaded. so should be through in plenty of time
[08:04] <rbasak> SRU team: second opinion on bug 1700373 please?
[08:04] <ubot5`> bug 1700373 in intel-microcode (Ubuntu Zesty) "Please update microcode to version 20170511 on all supported platforms" [Undecided,In progress] https://launchpad.net/bugs/1700373
[08:14] <apw> rbasak, oh any particular aspect?
[08:14] <rbasak> apw: my comment 10
[08:15] <rbasak> apw: on the full package backport vs blob only question.
[08:19] <apw> rbasak, i would feel the same, that backporting the content ony would be my expectation, as delivery is local to the series
[08:19] <apw> rbasak, pretty much i agree with your comment en-toto
[08:20] <rbasak> apw: thanks. Mind if I comment on the bug?
[08:20] <rbasak> (ie. quote you)
[08:21] <rbasak> And xnox: ^ - do you want to keep driving this? We can either figure out an exception for intel-microcode with a commitment from a team for regular updates, or push a one-off blob update through, or both of those.
[08:22] <apw> rbasak, feel free to quote me indeed
[08:22] <rbasak> (an exception documented and approved in the usual way)
[08:22] <rbasak> apw: thanks!
[08:31] <jamespage> apw: morning
[08:32] <jamespage> apw: any chance you could look at the keystone updates in UNAPPROVED for xenial and yakkety; the equivalent is already in zesty proposed
[08:37] <apw> jamespage, will try and fit it in today ...
[08:37] <jamespage> apw: ta
[08:41] <Laney> slangasek: https://bugs.launchpad.net/auto-package-testing/+bug/1688516
[08:41] <ubot5`> Ubuntu bug 1688516 in Auto Package Testing "No way to mark a test as 'accepted regression'" [Undecided,New]
[09:33] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.26.4~14.04 => 2.26.6~14.04] (no packageset)
[09:33] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.26.4+16.10 => 2.26.6+16.10] (desktop-core, ubuntu-server)
[09:34] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.26.4 => 2.26.6] (desktop-core, ubuntu-server)
[09:34] -queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.26.4+17.04 => 2.26.6+17.04] (desktop-core, ubuntu-server)
[09:39] <ginggs> Would someone please 'force-badtest r-cran-surveillance/1.13.0-1' ?  The tests were broken in the release pocket by the upload of gdata/2.18.0-1
[09:41] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-123.172] (core, kernel)
[09:41] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-58.63] (core, kernel)
[09:42] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-83.106] (core, kernel)
[09:47]  * apw eyes the snapds sideways
[09:49] <xnox> the version numbers used are neat, with xenial getting the naked version number.
[09:57] <apw> they are confusing and annoying :)
[09:57] <apw> and backwards
[09:58] <xnox> i find them perfectly reasonable, just like my intel-microcode backports.
[09:58] <xnox> above are back and forward ports =)
[09:59] <ogra_> yeah, the release with development focus actually has the plain versionn
[10:15] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-83.106]
[10:15] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-58.63]
[10:16] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-123.172]
[10:45] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.26.6+16.10]
[10:45] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (zesty-proposed) [2.26.6+17.04]
[10:45] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.26.6~14.04]
[10:45] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.26.6]
[10:46] <apw> ^ rejecting per uploader, issue with artful needing a rework
[11:40] -queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-83.106~14.04.1] (kernel)
[11:40] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-58.63~16.04.1] (kernel)
[12:05] -queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-83.106~14.04.1]
[12:06] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-58.63~16.04.1]
[13:58] <gaughen> slangasek - looks like cloud-init and nplan are reading to be pushed to the xenial archive. Would you handle it please?
[14:22] <gaughen> slangasek, also would you look at klibc for trusty
[14:22] <gaughen> fginther, ^^
[14:32] <ginggs> Would someone please 'force-badtest r-cran-surveillance/1.13.0-1' ?  The tests were broken in the release pocket by the upload of gdata/2.18.0-1
[15:14] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.11.0-9.14] (core, kernel)
[15:15] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.11.0-9.14]
[15:51] <slangasek> gaughen: looks like nplan/xenial has already been released (but not yakkety,zesty; so those are also done now)
[15:52] <apw> erp, i wonder how that happened
[15:52] <gaughen> I hear that bdmurray took care of nplan - thanks Brian!
[15:55] <bdmurray> I didn't do yakkety or zesty because of the autopkgtest failures.
[15:55] <slangasek> gaughen: cloud-init released; klibc released
[15:55] <gaughen> slangasek, thank you! woot!
[15:56] <slangasek> bdmurray: yeah, it's a known flaky test; I've marked it badtest now in the hints, and will pester for improvement for the next SRU
[15:56] <gaughen> fginther, xnox ^^
[15:56] <slangasek> bdmurray: related, LP: #1700668
[15:59] <slangasek> Laney: in regards to your response on the bug, I am personally unconvinced this is the right level of stick to use for getting people to fix their autopkgtests.  How often do you enforce in a situation like this, vs. doing a bunch of analysis and then giving it a pass anyway?
[16:09] <Laney> slangasek: Sometimes, and more often I fix things myself.
[16:09] <Laney> Where is the stick at all?
[16:10] <Laney> I think we're too far on the ignoring side ATM.
[16:10]  * apw feels that too
[16:17] <rbalint> apw: sil2100 told me you may had comments regarding the gce-compute-image-packages update #1700027
[16:18] <rbalint> apw: but i was not around :-(. is there anything i should fix in the upload?
[16:19] <slangasek> Laney: ok; but is it a better use of time to use the gate like this, vs. acknowledging that the gate failed (because the regression made it into devel) and then spending some time working through the backlog of failing autopkgtests more generally?
[16:20] <ginggs> slangasek, Laney: seeing you are discussing autopkgtests, would you please consider 'force-badtest r-cran-surveillance/1.13.0-1' ? The tests were broken in the release pocket by the upload of gdata/2.18.0-1 - I don't think holding back r-base because of this gains us anything
[16:20] <slangasek> rbalint: apw had concerns about the lintian warnings; but I think it was just this one, in which case it's ignorable because it's an NSS module? W: google-compute-engine-oslogin: package-name-doesnt-match-sonames libnss-oslogin2
[16:20] <apw> slangasek, yes htat was the one
[16:21] <slangasek> ginggs: yes, that's a great example, I saw your request last night and re-triggered against the release pocket, to confirm it was really a regression there before overriding, and now it takes a release team member's time again to act on that rather than it being automatic ;)
[16:21] <slangasek> Laney: ^^ for your consideration
[16:21] <slangasek> (and I'm adding the hint)
[16:22] <slangasek> apw: I'm +1 on ignoring that warning because it's an nss module and sonames are superfluous there anyway; I haven't reviewed the rest of it so I'll defer to you if you want to accept
[16:24] <ginggs> slangasek: thanks!
[16:28] <ginggs> slangasek: just to be clear, does running the r-cran-surveillance tests with trigger r-cran-surveillance/1.13.0-1 run only against the release pocket?
[16:29] <slangasek> ginggs: yes
[16:29] <slangasek> ginggs: this trick fails if there is a newer version of the package itself in -proposed, but that's not the case here
[16:30] <ginggs> slangasek: ah, ok
[16:33] <slangasek> xnox: so this new version of ocaml seems to have changed something about int types that are exposed by default?  a bunch of build failures w/ int64, uint32 undefined...
[16:34] -queuebot:#ubuntu-release- Unapproved: libvirt (zesty-proposed/main) [2.5.0-3ubuntu5.2 => 2.5.0-3ubuntu5.3] (ubuntu-server, virt)
[16:42] -queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.10 => 1.3.1-1ubuntu10.11] (ubuntu-server, virt)
[17:00] <xnox> slangasek, i have noticed that. It seems that 4.04 is more strict than before, and e.g. these used to end up as warnings before, but are errors now. I have fixed some already by looking at the right/matching signature types in the headers.
[17:00] <xnox> slangasek, it is a common case of "use C99 compliant uint32_t instead of weird uint32"
[17:01] <xnox> i'm uploading rounds and fixing them. Many/most of round2 uploaded and fixed. round3 uploaded and yet to fix up.
[17:26] <slangasek> xnox: ack
[17:27] <xnox> there are 12 rounds in total =/
[17:31] <slangasek> xnox: fwiw I've tended to prefer uploading them all in a go and sorting out the build failures on launchpad; ymmv
[17:33] <xnox> slangasek, i semi do that. Imho it's a bit nicer to follow the installability chain. But meh. Feel free to pinch in if you wish, archive is the current state of the art together with http://people.canonical.com/~ubuntu-archive/transitions/html/html/ocaml.html
[17:33] <slangasek> have looked at htslib autopkgtest regressions and punted them to the Debian maintainer
[17:33] <xnox> i'll try to do levels 3 and 4 tomorow.
[17:33] <xnox> yeah, i'm working on build-failures and instalability at the moment, then autopkgtests....
[17:33] <slangasek> xnox: I filled my quota with ghc last week, I'm not touching the ocaml uploads right now ;)
[17:34] <xnox> =)))))))
[17:34] <xnox> i have never done ocaml before, so this is somewhat fun.
[17:34] <slangasek> xnox: fishing for French citizenship, then?
[17:34] <xnox> i love how it tangles into everything perl4caml camljava ocaml-libvirt =)
[17:34] <xnox> slangasek, qui!
[17:34] <xnox> slangasek, i don't need citizenship I can use one of my booklets to move there.
[17:35] <xnox> I will be off to scouting trips to milan, barcelona, and prague. To check if they are any good.
[17:38] <xnox> i only want to move to places i have permanent residence on arival, such that i don't need to naturalise yet again.
[17:59] <slangasek> Laney: so in the case of the 34 regressed perl modules (whose cause I don't know), do you think I should have handled them differently than I did?
[18:12] <slangasek> apw: are you good with google-compute-engine-oslogin now, or should I re-review it?
[18:23] <ginggs> slangasek: would you 'force-badtest node-tap/8.0.0-4ubuntu2/armhf' please?  it was flaky in zesty too http://autopkgtest.ubuntu.com/packages/node-tap/zesty/armhf
[18:30] <slangasek> ginggs: you just want it marked for artful, not zesty, right?  Yes, I had triggered a baseline test for that one yesterday and hadn't come back around to notice the result
[18:30] <slangasek> (done)
[18:30] <ginggs> slangasek: yes, for artful. thanks!
[19:44] <jbicha> hi, can we demote metacity to universe now? the only rdepends is ubiquity but that's an alternate (and src:metacity is not present on Ubuntu's artful daily images)
[19:45] <infinity> jbicha: Not until component-mismatches agrees.
[19:45] <infinity> Err, wait.
[19:46] <infinity> jbicha: It's in universe. :P
[19:46] <infinity>  metacity | 1:3.25.1-1ubuntu2    | artful/universe | source, amd64, arm64, armhf, i386, ppc64el, s390x
[19:46] <jbicha> oh, sorry about that, thanks :)
[19:55] <bdmurray> infinity / slangasek: Could one of you review my apport uploads in the SRU queues? Its just a test fix.
[19:55] <infinity> bdmurray: Yup.
[19:55] <infinity> bdmurray: Which releases?
[19:57] <infinity> bdmurray: Guess who didn't use -v when building?
[20:06] <bdmurray> uh me?
[20:06] <infinity> bdmurray: Yup.
[20:07] <bdmurray> infinity: Okay, I'll handling the rejecting too then.
[20:10] -queuebot:#ubuntu-release- Unapproved: apport (zesty-proposed/main) [2.20.4-0ubuntu4.2 => 2.20.4-0ubuntu4.3] (core)
[20:11] -queuebot:#ubuntu-release- Unapproved: rejected apport [source] (zesty-proposed) [2.20.4-0ubuntu4.3]
[20:12] <infinity> cpaelzer: I added some comments to your ntpd bug.  Also, bileto SRUs make me a sad panda.
[20:18] -queuebot:#ubuntu-release- Unapproved: apport (yakkety-proposed/main) [2.20.3-0ubuntu8.4 => 2.20.3-0ubuntu8.5] (core)
[20:19] -queuebot:#ubuntu-release- Unapproved: rejected apport [source] (yakkety-proposed) [2.20.3-0ubuntu8.5]
[20:21] -queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.7 => 2.20.1-0ubuntu2.8] (core)
[20:24] -queuebot:#ubuntu-release- Unapproved: rejected apport [source] (xenial-proposed) [2.20.1-0ubuntu2.8]
[20:27] <bdmurray> infinity: okay, should be fixed now
[20:51] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (xenial-proposed) [2.20.1-0ubuntu2.8]
[20:52] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (yakkety-proposed) [2.20.3-0ubuntu8.5]
[20:53] -queuebot:#ubuntu-release- Unapproved: accepted apport [source] (zesty-proposed) [2.20.4-0ubuntu4.3]
[20:53] <Laney> slangasek: Well, if 34 packages start failing at once that probably sounds like something to investigate and fix. But if you did, and you think that all those tests are bad, then it's correct.
[20:54] <slangasek> Laney: it's perl, so 34 out of a couple hundred; and they regressed in the release pocket, so they're bad for reasons unrelated to either perl or the module package itself having regressed; and I have no idea about the perl auto-autopkgtesting stuff
[20:55] <slangasek> do you think perl should block (and hold up other stuff in -proposed) because of a small percentage of tests that are broken because of a regression in the perl test infrastructure?
[20:57] <slangasek> my argument is: once we've identified that the failed autopkgtest is not a regression in -proposed, what is the value of blocking packages which are not to blame in -proposed until this is fixed?
[20:58] <Laney> ok, what's the path to getting these tests passing again?
[21:01] <Laney> I think the fact that our infrastructure isn't fine grained enough to catch all regressions when they happen is unfortunate, and when we do get pointed to something that's gone wrong then somehow it should be looked at.
[21:01] <Laney> If we'd have managed to catch the regressions at the right time there would be no question that there was a bug to be fixed
[21:01] <Laney> Unfortunately we didn't, but we're still being told about a problem heere
[21:02] <Laney> got to go, sorry
[21:02] <slangasek> Laney: so, someone can investigate the perl automated test harness to understand why it broke, and whose fault it is that it's now broken, and fix either the harness or the tests.  But given that it has already regressed in devel, is there any reason that these should be a higher priority to fix, or more of a blocker, than any of the other failing autopkgtests in devel?
[21:03] <slangasek> I certainly think that once the cause is identified, we should figure out a way to trigger tests for the test harness updates so we don't do the same in the future
[21:09] <slangasek> Laney: what this comes down to, for me, is the sense that everything beyond the actual triggering of tests to get a baseline view - the log analysis and the setting the hints - was busywork; and while I could have opted to dig into the test failures instead to resolve them, which would have not been busy work, it also would have not been /priority/ work and would not have been a sensible path
[21:09] <slangasek> towards my goal at the time, which was unblocking perl for migration
[21:25] <xnox> slangasek, Laney, i think a lot of autopkgtest work that ubuntu does is futile, until debian starts to gate on autopkgtests failures too.
[21:25]  * xnox did not follow all of the discussion
[21:26] <slangasek> Laney: so I would like to explicitly decouple, as a policy, the work of getting transitions unstuck from -proposed from the work of improving the quality of tests in devel.  Unpicking transitions is already a lot of yak shaving, and I think having to debug tests in devel is a yak too far :)
[21:27] <doko> xnox: should we propose an autopkg BoF for DebConf?
[21:27] <xnox> slangasek, i guess we should be staging transitions in a silo?
[21:27] <doko> please no ...
[21:28] <xnox> doko, probably.
[21:31] <slangasek> xnox, doko: the piece that's missing is a committment from the Debian release team to gate.  I think an email follow-up to debian-release is needed
[21:31] <slangasek> as for staging in a silo, <shrug> not all transitions are going to happen that way
[21:32] <slangasek> and it will trigger all the autopkgtests twice
[21:32] <slangasek> and it doesn't fix anything about the problem I'm currently complaining about
[21:33] <xnox> sure. but things would be easier if adt tests do pass for things synced from debian.
[21:33] <xnox> and do not regress
[21:39] <slangasek> xnox: here's an irrelevancy to distract you: should we change the autopkgtest interface from returning a boolean to returning a bitfield, so that packages can be fine grained about declaring success/failure, and we can ratchet individual tests separately?
[21:44] <xnox> slangasek, at clearlinux.org QA team wrote a log analyzer to extract the results of many variety of test suite and report them in https://testanything.org/tap-specification.html and then they would monitor regressions of individual tests.
[21:44] <xnox> thus the granularity tracking of regressions was down to asserts.
[21:46] <slangasek> if there was a log analyzer that ensured I would never again have to traverse log files by hand guessing which of 'FAIL' / 'fail' / 'not ok' / 'bad' / 'ERROR' I needed to key on for a particular package, I would enjoy that
[21:48] <xnox> it did support java, perl, python, php, R, the GNU thing, gcc etc.
[21:49] <bdmurray> The linux autopkgtests are flaky and shouldn't be considered when looking at releasing an SRU correct?
[21:52] <xnox> slangasek, does cooked rhubarb count as fruit?
[21:53] <slangasek> bdmurray: generally so, yes.  I usually spot check the failures to be sure that it's not a real regression /this/ time, and get a little bit more annoyed in the process ;)
[21:53] <slangasek> xnox: sure, why not
[21:54] <xnox> slangasek, is it xavier approved? =)
[21:55] <slangasek> xnox: haven't offered him any yet
[21:56] <xnox> rhubarb compote hmmmm
[21:58] <doko> bdmurray: your bot for the -done tags still triggers if there is a release specific tag and an unspecific tag. is this intended?
[21:58] <doko> https://bugs.launchpad.net/bugs/1667407
[22:01] <bdmurray> doko: I saw that happen and probably not.
[22:02] <slangasek> xnox: but not Chinese rhubarb
[22:34] -queuebot:#ubuntu-release- Unapproved: gpaste (xenial-proposed/universe) [3.18.3-1 => 3.18.6-0ubuntu1] (no packageset)