[06:40] -queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.10 => 1:2.5+dfsg-5ubuntu10.11] (ubuntu-server, virt) (sync)
[09:36] <xnox> tsimonq2, horum, that is bad.
[09:36] <xnox> slangasek, could you please activate run-once no-network test case for lubuntu products?
[09:38] <xnox> balloons, please add me to the https://launchpad.net/~ubuntu-testcase team =) i am lead for s390x product releases in the iso tracker.
[10:38] <jamespage> please could someone reject neutron 2:8.4.0-0ubuntu2 from the xenial unapproved queue
[10:39] <apw> jamespage, looking
[10:39] <jamespage> apw: it needs pairing up with another neutron sru
[10:40] <apw> jamespage, what about neutron-lbaas
[10:40] <jamespage> apw: that ones ok as it
[10:40] <jamespage> as is rather
[10:41] <apw> jamespage, ack and done
[10:41] <jamespage> apw: ta
[10:41] -queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu2]
[10:43] -queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.24+17.04 => 2.24.1+17.04] (desktop-core, ubuntu-server)
[10:43]  * apw looks at the snapd uploads ^
[10:47] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.24.1+17.04]
[11:29] <flocculant> xnox: all the current 'no network' testcases are based on doing other things - me and balloons were discussing it yesterday, https://irclogs.ubuntu.com/2017/04/18/%23ubuntu-quality.html
[11:30] <flocculant> probably best to wait for tsimonq2 to write the testcase - I'm an admin on the manual stuff and watch for merges for that - so atm waiting for tsimonq2 :)
[11:31] <flocculant> once that's done he'll be able to add it to his test list - at least once the tracker is set up for the AA release
[11:41] <tsimonq2> flocculant: Tonight, I can't do it right now.
[11:42] <flocculant> tsimonq2: even if you could - I can't I'm off again shortly :) if it's there 0700 uk time I'll look first thing
[11:43] <tsimonq2> And flocculant has a point, I really don't think it's something we can just enable... so please wait, xnox
[11:44] <tsimonq2> slangasek: ^
[11:49] <tsimonq2> flocculant: Ack, I'll make it happen. :)
[11:55] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.24]
[11:55] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.24+16.10]
[11:55] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.24~14.04]
[12:05] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23.6+16.10 => 2.24.1+16.10] (desktop-core, ubuntu-server)
[12:06] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23.6 => 2.24.1] (desktop-core, ubuntu-server)
[12:06] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23.6 => 2.24.1] (desktop-core, ubuntu-server)
[12:07] -queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu1 => 2:8.4.0-0ubuntu2] (openstack, ubuntu-server)
[12:07] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23.6+16.10 => 2.24.1+16.10] (desktop-core, ubuntu-server)
[12:13] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.23.1~14.04 => 2.24.1~14.04] (no packageset)
[12:49]  * apw deals with snapd ^
[12:51] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.24.1+16.10]
[12:51] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.24.1]
[12:56] <rbasak> "deals with" :-P
[12:57] <mitya57> apw, right, I want the last qtbase which includes the first. (I uploaded the first, it was not accepted for some time, then I needed one more fix and uploaded it too)
[12:57] <apw> rbasak, they were duplicates ...
[12:58] <apw> rbasak, i am reviewing the rest, as i am familiar with the changes we asked for
[12:58] <mitya57> If two uploads is a problem, I can squash them into a single one.
[14:14] -queuebot:#ubuntu-release- Unapproved: open-vm-tools (zesty-proposed/main) [2:10.1.5-5055683-1ubuntu1 => 2:10.1.5-5055683-1ubuntu1.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[14:56] <slangasek> bdmurray: should the pending-sru report maybe show a bug as green instead of purple when it's verified for *this* series that we're currently looking at?
[14:58] <bdmurray> slangasek: because now if its purple you won't look at the bug, but if it's green you would?
[15:00] <slangasek> bdmurray: if I have a mix of green and purple I have to look at the bug to see if it's fixed for this release; if it's all green I know it should be ready to release and can just load up all the bugs for one final check
[15:02] <bdmurray> slangasek: ack, so it'd help with multi-bug SRUs.
[15:04] <slangasek> bdmurray: imho yes
[15:06] <howefield> x/exit
[15:17] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.24.1+16.10]
[15:18] -queuebot:#ubuntu-release- Unapproved: rejected graphviz [source] (trusty-proposed) [2.36.0-0ubuntu3.2]
[15:19] -queuebot:#ubuntu-release- Unapproved: graphviz (trusty-proposed/main) [2.36.0-0ubuntu3.1 => 2.36.0-0ubuntu3.2] (core)
[15:19] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.24.1]
[15:20] <apw> slangasek, bdmurray could we just get rid of verification-needed et al and _only_ have per series ones ...
[15:21] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.24.1~14.04]
[15:22] <rbasak> apw: +1
[15:22] <rbasak> I've considered asking for that too.
[15:22] <apw> we are afterall the only ones who put those in the request inside the bug via sru-foo
[15:23] <apw> we can detect people who don't read and use the old ones and auto respond on those
[15:24] <bdmurray> apw: I already made slangasek's change though! So you want to switch to tagging v-n-$series and v-d-$series?
[15:26] <apw> bdmurray, personally i find it confusing we have a tag for all series and one per series
[15:26] <apw> bdmurray, i assume so do people setting them
[15:27] <apw> bdmurray, or you may yet tell me that is not what the v-n means of course and i demonstrate how confused i am
[15:29] <bdmurray> apw: v-n captures that there is some kind of verification of the SRU needed so people could search LP for bugs needing verification with one tag.
[15:29] -queuebot:#ubuntu-release- Unapproved: accepted graphviz [source] (trusty-proposed) [2.36.0-0ubuntu3.2]
[15:29] <apw> bdmurray, ok so the sru-report will now essentially only show the state of the -series tags ?
[15:29] <bdmurray> apw: For verification-done that's my intent.
[15:30] <apw> bdmurray, i can see that that is useful as long as we are only using the -series ones
[15:30] <rbasak> Also sru-review needs to change to munge the existing tags correctly (and create the correct new ones)
[15:30] <apw> and that is just a convineince for "finding verification work"
[15:31] <apw> bdmurray, though in some sense if verification-needed is meant to set if any v-n-* exists then we ought to be doing that via a robot
[15:32] <bdmurray> Maybe we should open a bug so we can discuss this in a better medium than irc.
[15:32] <bdmurray> https://bugs.launchpad.net/ubuntu-archive-tools
[15:38] <bdmurray> I think I understand what y'all want but don't want to put effort into the wrong thing, nor lose track of the idea since its not a one line / one tool fix.
[15:40] <rbasak> While we're on the subject...
[15:40] <rbasak> The git workflow stuff is able to do SRU reviews from the queue now.
[15:41] <rbasak> It's easier to review this way (IMHO anyway) because I can diff something in unapproved against anything in the archive currently (and indeed any tree in any upstream git repo)
[15:41] <rbasak> I'm still using sru-review to accept currently, as it does some other checks as well potentially.
[15:42] <rbasak> But I'd like to add queue accept and reject functions to the git workflow tool instead.
[15:42] <rbasak> To do that, maybe I could factor out the actual checking bits of sru-review/accept/release into some kind of API and access that instead?
[15:42] <rbasak> As I don't want to duplicate code.
[15:43] <rbasak> Anyway, opinions welcome.
[15:44] <rbasak> Perhaps if everyone wants to deprecate the current tools in favour of the git workflow, then duplicating the code for now and then ditching the old tooling would be easier.
[15:45] <nacc> and i'm 100% on board with making the tooling more flexible to support the most generic cases
[15:45] <nacc> don't want the tooling to dictate workflow, just to supprot it
[16:28] <bdmurray> wxl: You might want to have a look at bug 1633913.
[16:29] <wxl> bdmurray: thanks. we've been discussing what's up with that. it's a little unclear.
[16:29] <bdmurray> wxl: was xnox's comment not clear re the test case being missing?
[16:30] <wxl> bdmurray: i guess what i'm saying is we have no idea what change precipitated it.
[16:30] <bdmurray> wxl: the test case used to be there?
[16:30] <xnox> bdmurray, there is more discussion about it here and testing channels; as in the stock "No Network" tests as used in Ubuntu might not be suitable for Lubuntu.
[16:31] <wxl> bdmurray: yeah obviously the tests are something that need to be added, but that doesn't necessarily fix the problem at hand, which i'm a bit more concerned about at this point.
[16:31] <bdmurray> Okay, I hadn't seen the previous discussion and only looked at the bug. I justed wanted to make sure it was being discussed.
[16:34] <flocculant> xnox:  on the other hand almost all of the install testcases say "Available options should represent the state of your system accurately" and the first option relates to network. So if I booted and knew network was available - but didn't see the Download updates option - then I would fail the test
[16:35] <xnox> flocculant, the problem is that for a year, nobody did an offline test of lubuntu - e.g. start a VM without a network interface.
[16:36] <xnox> everybody seems to configure network / wifi; or use VMs with networking
[16:37] <flocculant> xnox: ohh I see - that's not something that we test either
[16:38] <xnox> flocculant, well, for ubuntu desktop there is a run-once "No Network" install test cases. and doing that for lubuntu would have caught the bug of not shipping a repository with debs sufficient to complete offline installs.
[16:41] <flocculant> xnox: right - I see that now - was perhaps reading things odd here
[16:42]  * flocculant wonders what happens for me 
[16:52] <flocculant> no surprises
[16:55] <flocculant> tsimonq2: so when I see this testcase and deal with that side - you want it added to http://iso.qa.ubuntu.com/admin/config/services/qatracker/testsuites/297/edit at the same time?
[18:51] -queuebot:#ubuntu-release- Unapproved: neutron (zesty-proposed/main) [2:10.0.0-0ubuntu5 => 2:10.0.0-0ubuntu5.1] (openstack, ubuntu-server) (sync)
[19:21] <tumbleweed> ./win 34
[19:21] <tumbleweed> win 34
[19:24] <slangasek> bdmurray: +1 for dropping purple altogether, then
[19:25] <slangasek> bdmurray: fwiw I thought it was useful to know "this bug was verified for some series but not this one" because it seems like that's low-hanging fruit to get the verification done by prodding someone on the bug
[19:30] <bdmurray> slangasek: okay
[21:00] <tsimonq2> bdmurray: fwiw I filed a bug about adding the test before xnox said anything, I picked up on that.
[21:09] <tsimonq2> flocculant: Which testcase?
[21:11] <slangasek> bdmurray: should I also drop the remaining reference to 'purple' in the text?
[21:16] <bdmurray> slangasek: refresh, I caught that in 1094
[21:20] <slangasek> bdmurray: done and merged, thanks!
[23:03] <tsimonq2> What's this do? http://people.canonical.com/~ubuntu-archive/package-team-mapping.json
[23:13] <slangasek> it occupies space on a disk
[23:14] <tsimonq2> XD
[23:14] <tsimonq2> slangasek: What's the file mean?
[23:14] <tsimonq2> What's it's purpose?
[23:14] <slangasek> it provides a cache mapping source packages to teams which are considered owners of those packages, in Ubuntu main
[23:15] <infinity> As far as I can tell, its purpose is to point out that Foudnations is the bug subscriber for way too many things.
[23:15] <tsimonq2> lol :P
[23:57] -queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (zesty-proposed/universe) [17.04.11 => 17.04.12] (ubuntu-mate)