=== maclin1 is now known as maclin === ahoneybun is now known as Guest36814 === maclin1 is now known as maclin [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) === klebers_ is now known as klebers [09:36] tsimonq2, horum, that is bad. [09:36] slangasek, could you please activate run-once no-network test case for lubuntu products? [09:38] balloons, please add me to the https://launchpad.net/~ubuntu-testcase team =) i am lead for s390x product releases in the iso tracker. === santa is now known as Guest66899 [10:38] please could someone reject neutron 2:8.4.0-0ubuntu2 from the xenial unapproved queue [10:39] jamespage, looking [10:39] apw: it needs pairing up with another neutron sru [10:40] jamespage, what about neutron-lbaas [10:40] apw: that ones ok as it [10:40] as is rather [10:41] jamespage, ack and done [10:41] apw: ta [10:41] -queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu2] === Guest66899 is now known as santa_ [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] 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] 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] 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] flocculant: Tonight, I can't do it right now. [11:42] 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] And flocculant has a point, I really don't think it's something we can just enable... so please wait, xnox [11:44] slangasek: ^ [11:49] 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] === bregma__ is now known as bregma === slashd- is now known as slashd [12:56] "deals with" :-P [12:57] 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] rbasak, they were duplicates ... [12:58] rbasak, i am reviewing the rest, as i am familiar with the changes we asked for [12:58] If two uploads is a problem, I can squash them into a single one. === caribou_ is now known as caribou [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] 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] slangasek: because now if its purple you won't look at the bug, but if it's green you would? [15:00] 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] slangasek: ack, so it'd help with multi-bug SRUs. [15:04] bdmurray: imho yes [15:06] 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] 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] apw: +1 [15:22] I've considered asking for that too. [15:22] we are afterall the only ones who put those in the request inside the bug via sru-foo [15:23] we can detect people who don't read and use the old ones and auto respond on those [15:24] apw: I already made slangasek's change though! So you want to switch to tagging v-n-$series and v-d-$series? [15:26] bdmurray, personally i find it confusing we have a tag for all series and one per series [15:26] bdmurray, i assume so do people setting them [15:27] 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] 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] bdmurray, ok so the sru-report will now essentially only show the state of the -series tags ? [15:29] apw: For verification-done that's my intent. [15:30] bdmurray, i can see that that is useful as long as we are only using the -series ones [15:30] Also sru-review needs to change to munge the existing tags correctly (and create the correct new ones) [15:30] and that is just a convineince for "finding verification work" [15:31] 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] Maybe we should open a bug so we can discuss this in a better medium than irc. [15:32] https://bugs.launchpad.net/ubuntu-archive-tools [15:38] 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] While we're on the subject... [15:40] The git workflow stuff is able to do SRU reviews from the queue now. [15:41] 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] I'm still using sru-review to accept currently, as it does some other checks as well potentially. [15:42] But I'd like to add queue accept and reject functions to the git workflow tool instead. [15:42] 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] As I don't want to duplicate code. [15:43] Anyway, opinions welcome. [15:44] 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] and i'm 100% on board with making the tooling more flexible to support the most generic cases [15:45] don't want the tooling to dictate workflow, just to supprot it [16:28] wxl: You might want to have a look at bug 1633913. [16:29] bug 1633913 in lubuntu-meta (Ubuntu) "lubuntu and ubuntustudio are missing pool; can not install without internet connection" [Undecided,New] https://launchpad.net/bugs/1633913 [16:29] bdmurray: thanks. we've been discussing what's up with that. it's a little unclear. [16:29] wxl: was xnox's comment not clear re the test case being missing? [16:30] bdmurray: i guess what i'm saying is we have no idea what change precipitated it. [16:30] wxl: the test case used to be there? [16:30] 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] 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] 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] 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] 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] everybody seems to configure network / wifi; or use VMs with networking [16:37] xnox: ohh I see - that's not something that we test either [16:38] 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] xnox: right - I see that now - was perhaps reading things odd here [16:42] * flocculant wonders what happens for me [16:52] no surprises [16:55] 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] ./win 34 [19:21] win 34 [19:24] bdmurray: +1 for dropping purple altogether, then [19:25] 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] slangasek: okay [21:00] bdmurray: fwiw I filed a bug about adding the test before xnox said anything, I picked up on that. [21:09] flocculant: Which testcase? [21:11] bdmurray: should I also drop the remaining reference to 'purple' in the text? [21:16] slangasek: refresh, I caught that in 1094 [21:20] bdmurray: done and merged, thanks! [23:03] What's this do? http://people.canonical.com/~ubuntu-archive/package-team-mapping.json [23:13] it occupies space on a disk [23:14] XD [23:14] slangasek: What's the file mean? [23:14] What's it's purpose? [23:14] it provides a cache mapping source packages to teams which are considered owners of those packages, in Ubuntu main [23:15] 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] lol :P [23:57] -queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (zesty-proposed/universe) [17.04.11 => 17.04.12] (ubuntu-mate)