[00:05] -queuebot:#ubuntu-release- Unapproved: nano (xenial-proposed/main) [2.5.3-2 => 2.5.3-2ubuntu1] (core)
[00:31] -queuebot:#ubuntu-release- Unapproved: libseccomp (trusty-proposed/main) [2.2.3-2ubuntu1~ubuntu14.04.1 => 2.1.1-1ubuntu1~trusty1] (core)
[00:34] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (xenial-proposed) [1.78ubuntu3]
[00:40] <slangasek> coreycb: hi, so ddebs.  What kind of disk requirements do you have for these on the cloud archive, now / in the future?
[02:32] -queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu13 => 229-4ubuntu14] (core)
[02:39] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (yakkety-proposed) [1.79ubuntu1.1]
[02:40] -queuebot:#ubuntu-release- Unapproved: resolvconf (xenial-proposed/main) [1.78ubuntu3 => 1.78ubuntu4] (core)
[02:45] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (xenial-proposed) [1.78ubuntu4]
[02:47] <slangasek> bdmurray: I could use ^^ a different set of eyes on the systemd/xenial piece of that
[05:23] -queuebot:#ubuntu-release- New binary: jdupes [ppc64el] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:23] -queuebot:#ubuntu-release- New binary: jdupes [s390x] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: jdupes [arm64] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: jdupes [powerpc] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:25] -queuebot:#ubuntu-release- New binary: jdupes [armhf] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: zorp [ppc64el] (zesty-proposed/universe) [6.0.10-1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: libcgns [ppc64el] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: libcgns [s390x] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: chicken [s390x] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: chicken [ppc64el] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: jdupes [i386] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: jdupes [amd64] (zesty-proposed/universe) [1.6.2-3] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: libcgns [powerpc] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: libcgns [arm64] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: libcgns [armhf] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: chicken [powerpc] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: libcgns [i386] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:33] -queuebot:#ubuntu-release- New binary: libcgns [amd64] (zesty-proposed/universe) [3.3.0-2] (no packageset)
[05:34] -queuebot:#ubuntu-release- New binary: chicken [i386] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:35] -queuebot:#ubuntu-release- New binary: zorp [amd64] (zesty-proposed/universe) [6.0.10-1] (no packageset)
[05:37] -queuebot:#ubuntu-release- New binary: netdata [amd64] (zesty-proposed/none) [1.3.0+dfsg-1] (no packageset)
[05:38] -queuebot:#ubuntu-release- New binary: chicken [armhf] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:39] -queuebot:#ubuntu-release- New binary: chicken [amd64] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:39] -queuebot:#ubuntu-release- New binary: zorp [i386] (zesty-proposed/universe) [6.0.10-1] (no packageset)
[05:42] -queuebot:#ubuntu-release- New binary: zorp [arm64] (zesty-proposed/universe) [6.0.10-1] (no packageset)
[05:48] -queuebot:#ubuntu-release- New binary: chicken [arm64] (zesty-proposed/universe) [4.11.0-1] (no packageset)
[05:48] -queuebot:#ubuntu-release- New binary: zorp [armhf] (zesty-proposed/universe) [6.0.10-1] (no packageset)
[07:10] <mardy> seb128: hi! Would you have a little time to remove a couple of packages from xenial-proposed?
[07:10] <seb128> mardy, hey, are they in the queue or accepted SRUs? I'm not in the SRU team so while I technical can I'm not supposed to deal with SRUs
[07:13] <mardy> seb128: I'm not sure, they certainly were not accepted, the verification failed
[07:13] <seb128> oh, then they got accepted
[07:13] <mardy> seb128: it's online-accounts and gnome-control-center-signon, in case you are able to check
[07:13] <seb128> otherwise they would be in the unapproved queue and nobody would have tested them
[07:13] <seb128> but let me have a look
[07:14] <seb128> https://launchpad.net/ubuntu/+source/gnome-control-center-signon/0.1.9+16.04.20160719-0ubuntu1
[07:17] <seb128> mardy, is that the upload you are talking about ^? the corresponding bug is verification-needed with a comment from you stating what to verify, not verification-failed?
[07:20] <mardy> seb128: yes, it's that one: dbarth verified it and noticed the failure, I'll ask him to add a comment there
[07:21] <seb128> mardy, thanks, once it's verification-failed the SRU team should handle it (maybe add a comment stating if you want it removed or if you want to do a follow up upload with extra fix to replace the current version in xenial-proposed)
[07:22] <mardy> seb128: ah ok, that makes sense
[07:22] <mardy> seb128: thanks!
[07:23] <seb128> yw!
[07:26] -queuebot:#ubuntu-release- Unapproved: signing-party (yakkety-proposed/universe) [2.4-1 => 2.4-1ubuntu1] (no packageset)
[09:37] <jibel> Could someone review snapd 2.20 in xenial and yakkety queues?
[09:38] <jibel> apw, ^ can you help with this ?
[10:02] <jibel> tjaalton, ^ can you help with the review of snapd 2.20?
[10:04] <jibel> rbasak, ^ or anyone from the sru team :)
[10:05] <tjaalton> jibel: i can give it a try later
[10:05] <seb128> tjaalton, you joined the SRU team? ;-)
[10:05] <tjaalton> yes
[10:05] <seb128> nice
[10:06] <jibel> tjaalton, cool, how later is later?
[10:06] <sil2100> Could someone review dbus in the xenial and yakkety queues? ;)
[10:07] <jibel> sil2100, no way, snapd first ;)
[10:07] <seb128> in all fairness he's asking for several days
[10:07] <seb128> so dbus should be first :p
[10:07] <jibel> meh
[10:07] <sil2100> ...sorry!
[10:07] <seb128> we already miss pitti :-/
[10:07] <tjaalton> jibel: I see 14 older packages in the queue ;)
[10:08] <jibel> tjaalton, I know, do your best.
[10:08] <seb128> but would be good to get snapd in today, otherwise I can see some people who are going to be grumpy about things
[10:09] <seb128> on the good side, maybe that would convince some of the team managers to allocate resources in their team to do SRU reviews... ;-)
[10:10] <sil2100> I'm in mid-training to join the SRU team
[10:10] <sil2100> At least that's the idea, I guess
[10:11] <tjaalton> great
[10:13] -queuebot:#ubuntu-release- Unapproved: accepted nano [source] (xenial-proposed) [2.5.3-2ubuntu1]
[10:16] <tjaalton> jibel: looks like bdmurray reviewed it already? see the comment on 1648520
[10:21] -queuebot:#ubuntu-release- Unapproved: accepted krb5 [source] (xenial-proposed) [1.13.2+dfsg-5ubuntu1]
[10:21] -queuebot:#ubuntu-release- Unapproved: accepted krb5 [source] (trusty-proposed) [1.12+dfsg-2ubuntu5.3]
[10:23] -queuebot:#ubuntu-release- Unapproved: accepted krb5 [source] (yakkety-proposed) [1.14.3+dfsg-2ubuntu1]
[10:39] -queuebot:#ubuntu-release- New binary: strongswan [s390x] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[10:40] -queuebot:#ubuntu-release- New binary: strongswan [ppc64el] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[10:43] -queuebot:#ubuntu-release- New binary: strongswan [amd64] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[10:43] -queuebot:#ubuntu-release- New binary: strongswan [powerpc] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[10:43] -queuebot:#ubuntu-release- New binary: strongswan [i386] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[10:55] <jibel> tjaalton, thanks, I'll check with mvo
[11:01] <tjaalton> sil2100: I don't know why, but sru-review can't see dbus for yakkety, while it's clearly on the queue
[11:03] <sil2100> tjaalton: hmm, maybe it's because I set yakkety-updates in the changelog instead of yakkety?
[11:03] <tjaalton> ah
[11:03] <sil2100> I noticed that a bit uh later
[11:04] -queuebot:#ubuntu-release- Unapproved: accepted dbus [source] (xenial-proposed) [1.10.6-1ubuntu3.2]
[11:05] <tjaalton> well, I can ack it from lp instead, but it won't send a notification to the bug(s)
[11:05] <tjaalton> aiui
[11:05] -queuebot:#ubuntu-release- New binary: strongswan [armhf] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[11:06] -queuebot:#ubuntu-release- New binary: strongswan [arm64] (zesty-proposed/main) [5.5.1-1ubuntu1] (ubuntu-server)
[11:06] <tjaalton> I'll do it manually
[11:07] <sil2100> I can re-upload if this is the problem
[11:07] <tjaalton> oh actually
[11:07] <tjaalton> yeah
[11:07] <sil2100> (I mean, yakkety-updates instead of yakkety)
[11:07] <tjaalton> probably best
[11:08] <tjaalton> rejected
[11:08] -queuebot:#ubuntu-release- Unapproved: rejected dbus [source] (yakkety-updates) [1.10.10-1ubuntu1.2]
[11:09] <sil2100> tjaalton: re-uploaded :)
[11:09] <sil2100> Thanks!
[11:09] -queuebot:#ubuntu-release- Unapproved: dbus (yakkety-proposed/main) [1.10.10-1ubuntu1.1 => 1.10.10-1ubuntu1.2] (core)
[11:12] <tjaalton> sil2100: now zeromq3, maybe upload with a changelog that does not refer to (LP: #1597439), because the MIR is fixed already
[11:12] <ubot5`> Launchpad bug 1597439 in zeromq3 (Ubuntu) "[MIR] zeromq3" [High,Fix released] https://launchpad.net/bugs/1597439
[11:14] -queuebot:#ubuntu-release- Unapproved: rejected zeromq3 [source] (yakkety-proposed) [4.2.0-2ubuntu0.16.10]
[11:14] -queuebot:#ubuntu-release- Unapproved: accepted dbus [source] (yakkety-proposed) [1.10.10-1ubuntu1.2]
[11:26] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.17.1ubuntu1 => 2.20ubuntu1] (desktop-core, ubuntu-server)
[11:28] <sil2100> tjaalton: ah, you mean with the same changelog but without the bug reference, yes?
[11:28] <tjaalton> sil2100: right, or ref modified so that the tools don't catch it
[11:28] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10ubuntu1 => 2.20+16.10ubuntu1] (desktop-core, ubuntu-server)
[11:31] <sil2100> tjaalton: ok, re-uploaded :)
[11:31] -queuebot:#ubuntu-release- New source: snapd (trusty-proposed/primary) [2.20~14.04.0ubuntu1]
[11:32] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10ubuntu1 => 2.20+16.10ubuntu1] (desktop-core, ubuntu-server)
[11:32] -queuebot:#ubuntu-release- Unapproved: zeromq3 (yakkety-proposed/main) [4.1.5+git20160811+2fc86bc-0ubuntu2 => 4.2.0-2ubuntu0.16.10] (kubuntu)
[11:43] <tjaalton> sil2100: thanks, looks like 4.2.0 is still in zesty-proposed so can't ack it yet
[11:44] <sil2100> tjaalton: oh? Oh my, how did I miss that
[11:44]  * sil2100 feels ashamed now
[11:44] <sil2100> Ok, I'll re-poke you once I deal with this
[11:44] <bluesabre> Good morning! Would anybody be interested in releasing sgt-launcher from the NEW queue? lp 1641300
[11:44] <ubot5`> Launchpad bug 1641300 in Ubuntu "[needs-packaging] sgt-launcher" [Wishlist,Fix committed] https://launchpad.net/bugs/1641300
[11:52] <tjaalton> how come ubuntu doesn't have cairo-c5, which blocks ricochet
[11:53] -queuebot:#ubuntu-release- Unapproved: gnome-online-accounts (yakkety-proposed/main) [3.20.4-0ubuntu1 => 3.20.5-0ubuntu0.1] (ubuntu-desktop)
[11:57] <tjaalton> cairo-5c actually, just doesn't build
[12:00] <jibel> tjaalton, mvo replied, snapd ready for review again
[12:42] <jibel> or bdmurray ^
[12:49] -queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (yakkety-proposed) [16.07.2-0ubuntu0.16.10.1]
[12:49] <tjaalton> ok
[13:06] <coreycb> slangasek, it looks like the quota for our newton-updates PPA is 20GB.  so my guess of PPA disc space used currently would be 100GB (20 x 5 releases).  do you think we can translate that to space needed for ddebs?
[13:13] <cjwatson> so, um
[13:14] <cjwatson> ddebs.ubuntu.com is basically a compatibility thing
[13:14] <cjwatson> is it not possible for clients to fetch the ddebs directly from LP?
[13:18] <cjwatson> you're going to have to store the ddebs in LP regardless, so let's not duplicate that storage on ddebs.u.c
[13:38] <tjaalton> jibel: you uploaded the same snapd package twice?
[13:47] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1.2]
[13:47] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [0.90ubuntu0.3]
[13:50] -queuebot:#ubuntu-release- Unapproved: accepted tracker [source] (yakkety-proposed) [1.10.2-0ubuntu0.1]
[14:01] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.20+16.10]
[14:02] -queuebot:#ubuntu-release- Unapproved: accepted signing-party [source] (yakkety-proposed) [2.4-1ubuntu1]
[14:03] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.20]
[14:12] <jibel> tjaalton, mvo uploaded the same package and modified the changelog to remove the reference to lp bugs and address bdmurray's comment. I'm just relaying the message here because mvo's on holidays
[14:21] <slangasek> jibel, tjaalton: I see that the new snapd package has merged ubuntu-core-launcher / snap-confine into the source.  I am concerned about whether the existing SRU exception provides appropriate CI coverage of those components
[14:23] <tjaalton> jibel: ok
[14:27] <tjaalton> slangasek: good point, I probably wouldn't have noticed..
[14:28] <jibel> slangasek, okay, let me check with the team
[15:03] <jibel> slangasek, a successful run of the unit tests for snap-confine on one arch would be enough for this time?
[15:30] <slangasek> jibel: on one arch> I wouldn't think so.  Do the unit tests not run at package build time / autopkgtest time?
[16:15] <lamont> can someone please accept cloud-init into yakkety-proposed?
[16:18] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.20ubuntu1]
[16:20] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.20+16.10ubuntu1]
[16:22] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.20+16.10ubuntu1]
[16:47] <lamont> tjaalton: can you accept cloud-init into yakkety-proposed?
[16:57] <lamont> tjaalton: actually, hold off on that for a bit
[17:05] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (trusty-proposed/main) [0.103ubuntu4.5 => 0.103ubuntu4.6] (core)
[17:21] <tjaalton> lamont: okay
[17:22] <lamont> tjaalton: chatted with smoser - we're going to have that one land after the current SRU lands on Monday.  (trivial workaround in new functionality, ergo not critical to the current SRU)
[17:22] <tjaalton> sounds perfect ;)
[17:22] <lamont> not sure what your processes say about letting it sit in the queue until then
[17:23] <tjaalton> can sit
[17:23] <ppisati> bug 1636838
[17:23] <ubot5`> bug 1636838 in linux-raspi2 (Ubuntu) "Failed to boot" [Undecided,Confirmed] https://launchpad.net/bugs/1636838
[17:23] <ppisati> so, i've covered all the possible upgrade paths
[17:24] <ppisati> if the four packages mentioned there could be release from -proposed to -updates
[17:24] <ppisati> that would be nice
[17:24] <ppisati> Xenial and Yakkety, thanks
[17:25] <smoser> tjaalton, lamont actually, just nix the yakkety cloud-init
[17:25] <smoser> i'll upload another in line with what is in zesty
[17:27] <lamont> smoser: presumably that upload will be next week?
[17:28] -queuebot:#ubuntu-release- New binary: mongo-tools [s390x] (zesty-proposed/universe) [3.2.11-1] (no packageset)
[17:28] -queuebot:#ubuntu-release- New binary: mongo-tools [ppc64el] (zesty-proposed/universe) [3.2.11-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: node-tar-stream [amd64] (zesty-proposed/universe) [1.5.2-1] (no packageset)
[17:31] -queuebot:#ubuntu-release- New binary: fsm-el [amd64] (zesty-proposed/universe) [0.2.1-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: node-has-cors [amd64] (zesty-proposed/universe) [1.1.0-1] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: node-lodash-packages [amd64] (zesty-proposed/universe) [4.15.0-1] (no packageset)
[17:34] -queuebot:#ubuntu-release- New binary: mongo-tools [i386] (zesty-proposed/universe) [3.2.11-1] (no packageset)
[17:35] <smoser> lamont, well, i'll put it into the queue right now
[17:35] <smoser> and then it can be let into -proposed later.
[17:37] -queuebot:#ubuntu-release- New binary: mongo-tools [amd64] (zesty-proposed/universe) [3.2.11-1] (no packageset)
[17:37] -queuebot:#ubuntu-release- New binary: mongo-tools [armhf] (zesty-proposed/universe) [3.2.11-1] (no packageset)
[17:42] <lamont> ack
[18:01] <doko> please unblock the binutils/linux autopkg test, this test always failed with 4.8 ...
[18:16] <lamont> smoser: I believe that all of the cases 1621507 cares about are verified, so I marked it verification-done... anything specific that we need to do wrt 1621615 before I also mark it?
[18:17] <infinity> doko: I'll grab binutils in my big unblock the world right after I'm done cleaning up the kernel (so in a few hours, probably).
[18:24] <smoser> lamont, its fine with me
[18:34] <clivejo> infinity: did you get a chance to look at krita?
[18:35] <infinity> clivejo: Nope, going flat out with several other things.  If it's urgent, you'll want another AA.  If not, it might have to wait for my holidays.
[18:35] <clivejo> it used to be in the source package calligra
[18:35] <infinity> And the goodwill of me as a community member, rather than a Canonical employee.
[18:35] <clivejo> which has been split out
[18:35] <infinity> Since Canonical owns about 180% of my time until next week. :)
[18:37] <clivejo> wow, were you naughty as the company Christmas party too?!?
[18:38] <clivejo> any other AA willing to have a look please?
[18:51] -queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.23+16.10 => 2.24+16.10] (no packageset)
[18:52] <davmor2> infinity: only 180% what did you do so right? ;)
[18:52] <infinity> davmor2: Time off for good behaviour.
[18:52] <davmor2> infinity: pfff
[18:59] -queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.23 => 2.24] (no packageset)
[18:59] <sergiusens> slangasek mind taking a look ^ ?
[19:19] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.17.1ubuntu1 => 2.20ubuntu1] (desktop-core, ubuntu-server)
[19:22] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10ubuntu1 => 2.20+16.10ubuntu1] (desktop-core, ubuntu-server)
[19:25] <slangasek> sergiusens: looking
[19:27] <slangasek> sergiusens: what's this armv7 autopkgtest disabling about?
[19:30] <slangasek> sergiusens: a lot of autopkgtest disabling going on today in the SRU queue.  NACK on this; we want the tests to run, and if they fail they fail
[19:31] <slangasek> sergiusens: also, your check won't actually match the armhf autopkgtest runners, if that was your intent, since they're all arm64 kernels ;)
[19:33] <sergiusens> slangasek because we want them green and making them green progressively
[19:34] <slangasek> sergiusens: making them artificially green is not particularly beneficial here
[19:34] <sergiusens> slangasek these are in-flight right now https://github.com/snapcore/snapcraft/pull/971 https://github.com/snapcore/snapcraft/pull/990
[19:34] <sergiusens> elopio ^
[19:35] <sergiusens> slangasek the reason we care to make them green is to not break them again, but I can understand your concerns
[19:35] <slangasek> sergiusens: but you're making them green by no-op'ing all of the autopkgtests that are run
[19:35] <slangasek> "To not break them again" - but they seem to have never worked in the first place
[19:36] <sergiusens> slangasek in my defense, I took my QA guy's advice
[19:37] <slangasek> :-)
[19:37] <sergiusens> slangasek I can enable them in a new push if you want
[19:37] <slangasek> sergiusens: yes please
[19:37] <sergiusens> slangasek if you reject I can use the same versions, right?
[19:37] <slangasek> sergiusens: (or I can just edit this out and reupload on my side)
[19:37] <slangasek> sergiusens: yes
[19:38] <elopio> slangasek: we are not disabling them. We are enabling them[
[19:38] <sergiusens> slangasek k, will do in a bit
[19:38] <slangasek> elopio: that's not what the diff looked like to me?
[19:38] <elopio> slangasek: previously, they just failed so didn't block the landings.
[19:38] -queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (xenial-proposed) [2.24]
[19:39] <elopio> in this SRU, we are disabling integration tests so the unit tests for arm will pass and start blocking landings in case of regression.
[19:39] <elopio> in the next SRU. we are enabling the others.
[19:39] <sergiusens> slangasek fwiw, pitti had mocked the containers to return a uname for an expected armhf machine on those arm64 servers
[19:40] <slangasek> elopio: what unit tests are those?  debian/tests/control lists only two tests; both of which are failing on armhf; and both of which have been no-op'ed in this upload
[19:40] <elopio> slangasek: the unit tests run during package build.
[19:40] <slangasek> sergiusens: a) ugh b) it's still not the right way to check the target architecture
[19:40] <sergiusens> slangasek I know, we have a fix planned for that
[19:40] <slangasek> elopio: ok, which still means that you're getting a meaningless green on autopkgtests
[19:40] <elopio> before this sru, our package failed to build in armhf.
[19:41] <slangasek> elopio: the autopkgtests are being run at build time?
[19:41] <elopio> slangasek: yes, meaningless green for now. My PRs that are ready to land will make the autopkgtests blockers in case of regression too.
[19:42] <slangasek> elopio: still a nack from me.  Failing autopkgtests > skipped autopkgtests.
[19:42] <elopio> uh, I disagree totally with that. Failing autopkgtests means that if unit tests also fail, we still land.
[19:43] <elopio> right now, we are blocking on unit tests regression, that's better than never identifying regressions.
[19:43] <slangasek> where are you triggering the autopkgtests from that this blocks landing?
[19:43] <elopio> travis on each pull request.
[19:43] <elopio> we caught a failure in a test yesterday, that was assuming amd64.
[19:43] -queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.23 => 2.24] (no packageset)
[19:43] <elopio> that wouldn't have been possible if we had just full autopkgtest failures.
[19:44] <sergiusens> elopio just fix it all in one stretch during holidays ;-)
[19:44] -queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.23+16.10 => 2.24+16.10] (no packageset)
[19:44] <sergiusens> slangasek pushed both up again
[19:44] <elopio> I tried to land the three in the same SRU last week, but failed.
[19:45] <slangasek> if you wanted to conditionally skip these tests in the travis environment, that would be fine with me
[19:45] <slangasek> but in proposed-migration, failing autopkgtests > skipped autopkgtests
[19:45] <elopio> I can't skip only in travis, because travis runs the same as proposed-migration.
[19:45] -queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (yakkety-proposed) [2.24+16.10]
[19:46] <slangasek> but it runs under travis as a harness, which could be configured to ignore autopkgtest failures on armhf
[19:46] <elopio> and, I still disagree. It's better to notice that there are regressions in a few tests, than to run many more tests but never catch anything.
[19:46] <elopio> but well, we can revert and just plainly fail in arm for one more release.
[19:46] <sergiusens> elopio if it is a requirement, it is a requirement, just take that and propose a change later ;-)
[19:46] <sergiusens> slangasek elopio to be fair as well, this is not travis, this is the adt webhook for upstreams thing
[19:46] <slangasek> you're not running *a few* tests.  You are literally running *zero* autopkgtests, with this change
[19:47] <slangasek> if you had left one autopkgtest enabled, then I would agree with you ;)
[19:48] <sergiusens> slangasek unit tests run on package build and given our arch all nature the package is built only on amd64 whilst on adt it is natively built (in the case of adt for upstreams at least)
[19:48] <elopio> https://github.com/snapcore/snapcraft/pull/1005
[19:48] <sergiusens> slangasek in any case I see you rejected rejected snapcraft [source] (yakkety-proposed) [2.24+16.10] after I uploaded again any reason?
[19:51] <infinity> 12:31 < slangasek> sergiusens: also, your check won't actually match the armhf autopkgtest runners, if that was your intent, since they're all arm64 kernels ;)
[19:51] <infinity> slangasek: ^-- If you mean "uname -m" won't be "armv7l", you'd be wrong.  Though, still fair to point out that assuming uname==userspace is wrong.
[19:52] <sergiusens> infinity I promise to migrate to what we discussed 2 weeks ago as soon the holidays are over
[19:53] <infinity> sergiusens: Yeah, I know you're good for keeping your promise there.  Was more just pointing out to slangasek that his understanding of the infrastructure is wrong. :)
[19:54] <infinity> slangasek: Also, it's not about "mocked containers", per se, as sergiusens implies, it's just that 32-bit tests are run under linux32, just as 32-bit builds are.
[19:54] <infinity> slangasek: Though, the extra trick there is that linux32 on aarch64 would usually return armv8l, and we have a kernel hack in place that makes that armv7l because upstream is wrong and I'm sick of arguing the point with them. :P
[19:58] <slangasek> infinity: haha ok
[19:59] <elopio> infinity: hey, your point was taken. No argue there.
[19:59] <slangasek> sergiusens: that should have been the reject of the original yakkety upload, which I hadn't rejected yet. your second upload is still in the queue
[19:59] <slangasek> except now it's not - accepted
[20:00] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.24+16.10]
[20:05] <elopio> thanks slangasek. For the next release I will give you a full green armhf. And then, the rest archs.
[20:05] <slangasek> elopio: great :)
[20:06] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.24]
[20:16] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.20ubuntu1]
[20:16] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.17.1ubuntu1 => 2.20ubuntu1] (desktop-core, ubuntu-server)
[20:17] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.20+16.10ubuntu1]
[20:17] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10ubuntu1 => 2.20+16.10ubuntu1] (desktop-core, ubuntu-server)
[20:32] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.20ubuntu1]
[20:33] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.20+16.10ubuntu1]
[20:33] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.17.1ubuntu1 => 2.20ubuntu1] (desktop-core, ubuntu-server)
[20:34] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.17.1+16.10ubuntu1 => 2.20+16.10ubuntu1] (desktop-core, ubuntu-server)
[21:09] <sergiusens> slangasek thanks!
[22:35] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.20ubuntu1]
[22:46] -queuebot:#ubuntu-release- Unapproved: tracker (yakkety-proposed/main) [1.10.2-0ubuntu0.1 => 1.10.3-0ubuntu0.1] (desktop-extra, ubuntugnome)