[00:09] <infinity> tjaalton: Around?
[04:16] <tjaalton> infinity: off this week. xorg metapkg isn't uploaded yet btw..
[05:21] <infinity> tjaalton: xorg-lts-vivid, you mean (which is in the queue), or something else?
[05:21] <infinity> tjaalton: Also, I rejected one of your uploads, would be nice if you could look at that, despite the VAC.
[05:28] <tjaalton> infinity: oh i uploaded it? ok.. i'll check the other one
[05:40] <tjaalton> infinity: looks like -qxl doesn't follow the same packaging as rest, so there's some tarball diff
[05:40] <tjaalton> or such
[05:42] <infinity> tjaalton: That crufty weirdness didn't happen between utopic and lts-utopic, FWIW.
[05:42] <infinity> tjaalton: And nothing in the utopic->vivid diff would have caused that.
[05:42] <infinity> tjaalton: So, I assume it was just a dirty tree when building lts-vivid.
[05:43] <tjaalton> weird
[05:43] <tjaalton> i use the source from apt get
[05:43] <infinity> tjaalton: Err, wait.  WAT?
[05:43] <tjaalton> pulled the source package from vivid
[05:44] <tjaalton> renamed
[05:44] <infinity> tjaalton: qxl is native in utopic/lts-utopic, and vivid.  Where did that orig magically come from for lts-vivid?
[05:44] <tjaalton> debuild
[05:44] <tjaalton> oh
[05:44] <tjaalton> grr
[05:44] <infinity> tjaalton: That orig is likely the culprit. :P
[05:44] <tjaalton> shitfuck
[05:44] <tjaalton> ok i'll delete the orig then
[05:45] <infinity> Where did it even come from? :)
[05:45] <infinity> Given that there's no orig in vivid... So confused.
[05:46] <infinity> But yeah, I'd assume unpacking vivid, running rename mojo on it, and building source withut the orig should give you a nice, small diff.
[05:46] <infinity> tjaalton: And assuming xorg-lts-vivid is the last piece of the puzzle, then you can rest without me bugging you.
[05:46] <infinity> tjaalton: And I might have functional dailies for you to test when you get back.
[05:46] <tjaalton> and now the debdiff makes sense
[05:47] <tjaalton> the rename script was buggy for a reason then!
[05:48] <tjaalton> it would happily build the source for you without a proper tarball
[05:48] <tjaalton> qxl uploaded again
[05:49] <tjaalton> infinity: yeah apparently i uploaded the metapkg at some point, so it should be all good then
[05:50] <infinity> tjaalton: Alright, lemme quickly re-review this.
[05:51] <infinity> tjaalton: That looks much saner, thanks.
[05:51] <tjaalton> cool
[05:52] <tjaalton> time for bf ->
[11:04] <sil2100> Hello everyone! I would need to disable the importer on nusakan again for a while
[15:45]  * Laney looks at stgraber 
[15:46] <Laney> iso tracker halp? :)
[15:48] <stgraber> Laney: hey
[15:48] <stgraber> Laney: what's up?
[15:48] <stgraber> (sorry, been taking some days off this past week so may have missed some pings)
[15:48] <Laney> no worries
[15:49] <Laney> how can I add a new 'owner' team?
[15:51] <stgraber> Laney: is that for a new product?
[15:51] <Laney> no, I want to set one for desktop-next
[15:52] <stgraber> ok, it's not exactly the easiest thing in the world :)
[15:52] <stgraber> first you have to go create a new role, that's in the admin interface under user IIRC
[15:52] <Laney> I see a list here: http://iso.qa.ubuntu.com/admin/config/services/qatracker/products/363/edit
[15:52] <stgraber> once done, go to the permissions tab and make sure that the permissions for the new role matches that of a similar product owner team
[15:53] <Laney> ah, that'll get it in there I suppose
[15:53] <stgraber> once that's done, go to the LP team module configuration and setup a new mapping between the LP team and the role you created
[15:53] <stgraber> once you've done that, you can go and edit the product to assign it the role
[15:53] <Laney> I don't have user in there
[15:53] <stgraber> oh, you're probably not admin enough :)
[15:54] <Laney> oh man, there are higher levels of power?
[15:54] <stgraber> and stupid 3G here has busted routes to SSO
[15:54] <stgraber> let me proxy through a server somewhere so I can actually login
[15:58] <stgraber> ok, I'm logged in
[15:59] <stgraber> Laney: what's the LP team?
[15:59] <Laney> ~ubuntu-desktop-next-release
[16:05] <stgraber> Laney: role should be setup now
[16:05] <stgraber> Laney: I'm EODing now and about to leave till Monday, do you need anything else from me?
[16:06] <Laney> stgraber: not if it works
[16:06] <Laney> happy holidays!
[16:06] <Laney> and thanks
[16:07] <Laney> ah wait, it's not posting to the tracker it seems
[16:08] <stgraber> Laney: btw, those with admin access for that kind of stuff are ~ubuntu-qa-website-devel
[16:08] <Laney> ah, maybe it doesn't have to be
[16:08] <stgraber> No iso.qa.ubuntu.com product found for ubuntu-desktop-next/daily-preinstalled/wily-preinstalled-desktop-next-i386; skipping.
[16:08] <stgraber> No iso.qa.ubuntu.com product found for ubuntu-desktop-next/daily-preinstalled/wily-preinstalled-desktop-next-armhf; skipping.
[16:08] <Laney> etc/qa-products?
[16:09] <stgraber> yep
[16:09] <Laney> k, will fix
[16:09] <Laney> will that break triggering the rebuild?
[16:09] <stgraber> qa-products is used both by the build script and process-rebuilds so yeah, you need to fix this
[16:10] <Laney> ok then
[16:10] <Laney> I'll hassle you on monday if it doesn't work by then
[16:10] <stgraber> ok :)
[16:10] <stgraber> rebuild-requests can be run in dry-run and verbose mode to see if the change works
[16:10] <stgraber> as for publishing, look at the end of the build log: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-desktop-next/wily/daily-preinstalled-20150611.log
[16:17]  * Laney tries a test build
[16:18]  * stgraber -> out
[17:01] <sil2100> I'll have to disable the importer again...
[17:01] <sil2100> ...or maybe not
[17:36] <coreycb> hello, can we have python3-tempest-lib and python3-paramiko promoted to main please?
[17:39] <infinity> coreycb: I don't see anything on my reports indicating that they're being pulled in.
[17:40] <coreycb> infinity, do I need an MIR for them?  the python 2 binary packages are in main.
[17:41] <infinity> coreycb: No, you don't need an MIR.  But you need something uploaded that depends on them, or to have them explicitly seeded with a rationale.
[17:41] <infinity> coreycb: If your intent was the former, please upload, and we'll clean it up.
[17:42] <coreycb> infinity, ok I still need to get the package in that depends on python3-tempest-lib, but there's already a dep on python3-paramiko:  https://launchpad.net/ubuntu/+source/python-tempest-lib/0.5.0-1/+build/7528029
[17:43] <infinity> coreycb: You do, however, need an MIR for python-ddt.
[17:44] <coreycb> infinity, we have one somewhere, lemme find it
[17:44] <infinity> And I'm very confused about why none of this is showing up on my mismatches reports.  Hrm.
[17:44] <coreycb> infinity, bug 1459151
[17:44] <infinity> coreycb: Ta.
[17:51] <infinity> coreycb: Should all be promoted.
[17:51] <coreycb> infinity, great, thanks!
[17:51] <infinity> coreycb: Or, will be once a publisher cycle happens.
[17:52] <infinity> coreycb: By "all", I mean the two packages in that MIR, and paramiko.
[17:52] <infinity> coreycb: tempest will want love after you upload something else that needs it.
[17:52] <coreycb> infinity, yep, got it
[19:37] <infinity> coreycb: tempest still has an issue.
[19:38] <infinity> coreycb: It build-depends on python3-oslo.log and python-oslo.log, but those don't actually exist.  They're -log, not .log
[19:39] <infinity> coreycb: Oh, nevermind, the new .log just hasn't built yet.
[19:39] <infinity> La la la.
[19:39] <infinity> This namespace renaming is such a mess.
[19:42] <coreycb> infinity, yeah jamespage worked through a bunch of those to rename them back to .log recently.  anything needed from us?
[19:42] <infinity> coreycb: Not yet.  I'll keep babysitting and see where it ends up.
[19:43] <coreycb> infinity, ok thanks
[19:44] <infinity> coreycb: Oh, filling in all the MIR info for LP: #1464158 would help.  That seems to be the next snag.
[19:51] <coreycb> infinity, ok I'll do that
[21:28] <coreycb> infinity, I've updated that MIR bug for  python-debtcollector and python-wrapt
[21:29] <infinity> coreycb: Thanks.