[00:00] <infinity> Pretty sure it would, yeah.
[00:00] <cjwatson>     The filename must be of the form:
[00:00] <cjwatson>         <TYPE>_<VERSION>_<ARCH>.tar.gz
[00:00] <infinity> LP already special-cases translations.tar.gz, IIRC.
[00:00] <cjwatson> And changing <TYPE> would land in the published directory name
[00:00] <cjwatson> So not sure it's worth the effort at the moment TBH :)
[00:01] <infinity> Nope.
[00:01] <cjwatson> I don't think it special-cases _translations.tar.gz so much as cares much less about its name.
[00:01] <infinity> Or that. :P
[00:01] <infinity> Well, _translations also doesn't get caught in NEW.
[00:02] <cjwatson> The raw-translations section is the bit that matters.
[00:02] <infinity> But yeah, probably because of the upload type.
[00:02] <cjwatson> UNAPPROVED in this case.  That's a special case for UEFI.
[00:02] <cjwatson> By request of the security team.
[00:02] <infinity> Oh, derp.  Right, to avoid random people jamming them in.
[00:02] <infinity> We've HAD THIS CONVERSATION.
[00:02] <infinity> I'm getting old.
[00:03] <cjwatson> 'zackly.  Compromise between locking down the set of UEFIable source packages and letting any single-PPU developer get stuff signed with our key.
[00:05] <infinity> I think I'll review GTK and then go get ready for a night of drunken debauchery.
[00:17]  * skaet thinks a glass of wine sounds about right,  at any rate   --> EOD
[00:19] <stgraber> cjwatson: accepting nouveau. The patch that's dropped in the diff wasn't applied in the previous uploads so it looks indeed safe to remove.
[00:19] <stgraber> tjaalton: ^
[00:32] <zul> iulian: no my understanding openstack projects has a standing FFE which includes python-novaclient
[00:39] <infinity> zul: A standing FFe *forever*, or until a certain pre-release date (and didn't this come up last release cycle too?)
[00:39] <infinity> zul: There has to be a cutoff point where we can't just jam in new features and hope they work.
[00:40] <zul> infinity: there hasnt been a a certain pre-relaase date, besides the new novaclient will be the last for quantal
[00:42] <infinity> Oh, vomit.  Looks like a CompSci Java student attacked the code.
[00:42] <infinity> -                if nic_info['net-id']:
[00:42] <infinity> +                if nic_info.get('net-id'):
[00:42] <infinity> Etc.
[00:44] <xnox> infinity: first one can give the KeyError, while the later returns None, casted to bool => False. So actually looks like a bug fix.
[00:45] <xnox> .... unless net-id is always set to something...... in that case vomit.
[00:45] <infinity> xnox: Yeah, I suppose it could be unset (and I wasn't actually paying attention to the part that it was an if, just the []->.get() change)
[00:46] <infinity> xnox: I retract the vomit, based on it being in a test, though that's potentially sketchy in other ways. :P
[00:46]  * xnox feeds vomit back to infinity
[00:46] <infinity> Ew.
[00:46] <infinity> That's my cue to put on pants and leave the house.
[00:47] <xnox> infinity: in a parallel universe it's actually cherries and strawberries =)
[03:28] <tjaalton> stgraber, cjwatson: yeah, the patch was cruft from my local tree.. probably should use git-bp in the future ;)
[04:26] <micahg> if someone with live image knowledge could please review this and make sure I got it right ^^^
[08:24] <henrix> i have a few kernel packages that landed in the wrong component in the -proposed pocket. can someone take a look at that, please?
[08:25] <cjwatson> stgraber: nouveau> ah, thanks
[08:26] <Laney> oh, we're staying frozen?
[08:30] <cjwatson> apparently so
[08:30] <cjwatson> henrix: I'll fix it up in a few minutes
[08:30] <cjwatson> still on child duty
[08:30] <henrix> cjwatson: great, thanks
[08:35] <ev> cjwatson: will do
[08:48] <cjwatson> You know
[08:48] <cjwatson> I think I might just bite the bullet and finish porting this old "fix up all the kernel overrides post-publication" script
[08:52] <cjwatson> henrix: will take a little longer as a result
[08:53] <henrix> cjwatson: ok, no worries
[09:00] <micahg> cjwatson: can you review my livecd-rootfs upload in the queue for quantal, it adds some missing tasks for Ubuntu Studio (I'm 99% sure it's fine)
[09:11] <apw> infinity, as requested
[09:11] <apw> infinity, and yes we do
[09:16] <cjwatson> micahg: yes, in my queue
[09:16] <cjwatson> henrix: oh, hah, I thought you meant they'd been *published* with the wrong components
[09:16] <cjwatson> but they're in NEW
[09:16] <cjwatson> oh well, the effort won't ultimately go to waste
[09:17] <cjwatson> we already have a tool to mangle the queue :)
[09:17] <henrix> cjwatson: ups, sorry :-/
[09:17] <henrix> cjwatson: i should have provided you with a bug number
[09:18] <henrix> cjwatson: bug #1056036 btw
[09:18] <ubot2> Launchpad bug 1056036 in linux "linux: 3.2.0-32.51 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1056036
[09:18] <cjwatson> micahg: oh, yeah, that's fine
[09:18] <cjwatson> henrix: Oh.  You mean precise.
[09:18] <cjwatson> Please tell me the series! :-)
[09:18] <cjwatson> Otherwise I'm going to assume current development
[09:19] <henrix> cjwatson: ok, noted and will do that next time.
[09:20] <cjwatson> all right, I can try out this script after all
[09:39] <Laney> diff from 3.5.12-0ubuntu3 to 3.5.13-0ubuntu1 (14.7 MiB)
[09:40] <tumbleweed> :)
[09:41]  * Laney sides with infinity about "* New upstream release" changelogs
[09:48] <Laney> did someone leave gtkmm3.0 in the queue on purpose?
[09:49]  * Laney abuses barry for not uploading merges with -v
[10:00] <xnox> slangasek> fwiw I've looked at the glibmm2.4 in the queue and think I see a problem with it
[10:00] <xnox> bah. not gtkmm
[10:01] <xnox> related?
[10:10]  * cjwatson sends the LP branch to remove the queue script off to EC2
[10:10] <cjwatson> At last
[10:10]  * Laney misparsed that at first and thought we were to become more cloudy
[10:11] <cjwatson> no
[10:11] <cjwatson> :)
[10:25] <Daviey> bah
[10:31] <ogra_> hmm, am i assuming right that we wont have a release meeting tonight (given there was a release yesterday)
[10:31] <ogra_> ?
[10:46] <Laney> please to score up https://launchpad.net/ubuntu/+source/libsoup2.4/2.40.0-0ubuntu1/+build/3860291
[10:46] <Laney> makes webkit uninstallable, which makes things sad
[10:46] <cjwatson> doing
[10:46] <cjwatson> done
[10:46] <Laney> ta
[10:50] <cjwatson> Daviey: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is looking pretty good, but just needs a bit more of a push; could somebody on your team prepare MIRs as appropriate for ipmitool, javascript-common, python-babel, and wwwconfig-common?
[10:54] <Daviey> cjwatson: ipmitool will be dropped on next upload, and python-babel was pulled in by accident with pydist.
[10:54] <Daviey> But yes, keeping an eye on it.
[10:55] <Daviey> ipmitool MIR was marked Invalid, so not showing on report.
[10:56] <cjwatson> OK ...
[10:56]  * cjwatson gets rid of svn2cl
[10:57] <cjwatson> Not that it'd have been a big deal since it was a split-out, but
[10:58] <Laney> bah, the libsoup rabbit hole gos deeper
[11:04] <henrix> cjwatson: sorry to nag you again, but have you took a look at precise packages (bug
[11:04] <Laney> .
[11:04] <henrix> cjwatson: bug #1056036
[11:04] <ubot2> Launchpad bug 1056036 in linux "linux: 3.2.0-32.51 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1056036
[11:04] <cjwatson> henrix: Just getting back to it now
[11:04] <henrix> cjwatson: ah, cool.  thanks
[11:07] <cjwatson> Just a bit baffled by why my script isn't doing the right thing
[11:07] <cjwatson> Oh, I bet SPPH.getPublishedBinaries is annoying
[11:12] <cjwatson> ... no, my own stupid fault
[11:21] <cjwatson> henrix: done now (I gave up on the script for the moment)
[11:21] <henrix> cjwatson: ack, thanks a lot
[11:32] <doko> Laney, libsoup failed again. I assume we have to wait ...
[11:33] <Laney> yes
[11:33] <doko> Daviey, cjwatson: the python-babel issue will be resolved if the nova ftbfs is fixed
[11:33] <Daviey> doko: right, thanks
[11:34] <Laney> doko: do you know why webkit would fail on armel with the argument list too long error, but not on armhf?
[11:34] <Laney> https://launchpad.net/~laney/+archive/webkit/+packages
[11:34] <doko> Daviey, so what about yui3?
[11:34] <doko> Laney, sorry, no
[11:34] <Daviey> doko: I'll press on that today.
[11:35] <Laney> ogra_: ^ you have any idea?
[11:35] <doko> Daviey, we had another package with this, downgraded to suggests, but if it pops up again, maybe it's better to include these two in main
[11:35] <ogra_> Laney, not really, no
[11:36] <doko> Laney, ahh, this is *with* you patched make?
[11:36] <Daviey> doko: Which two?
[11:36] <Laney> yes
[11:37] <ogra_> Laney, hmm, that seems to be a virtual PPA
[11:37] <ogra_> Kernel version: 2.6.24-32-xen #1 SMP Thu Jul 12 14:30:40 UTC 2012 x86_64
[11:38] <ogra_> i would incline to blame qemu
[11:39] <Laney> ok, i'll try it on my panda then
[11:39] <ogra_> Laney, how about you try it again in the canonical-arm-dev PPA
[11:39] <ogra_> that should be a physical builder
[11:40] <Laney> I'd have to copy the patched make-dfsg in there
[11:40] <Laney> might not be the best idea
[11:40] <ogra_> ah, yeah, no
[11:41] <doko> Daviey, ahh, it was yui, but the downgrade wasn't done for the -debug package ... fixing
[11:41] <Daviey> doko: ah, ok
[11:45] <cjwatson> infinity: ahahahaha bonk
[11:45] <cjwatson> infinity: http://paste.ubuntu.com/1247367/
[12:00] <Laney> bah, too many uninstallables
[12:20] <cjwatson> ogra_,infinity: so, zsync of ARM *.gz files
[12:20] <cjwatson> ogra_,infinity: do you want them always to come out locally as *.gz, or is it appropriate e.g. for zsync to decompress *.img.gz on the fly?
[12:21] <ogra_> cjwatson, the former, else you suddenly end up with a 4G file if you downloaded a 400M img.gz
[12:21] <cjwatson> OK
[12:21] <cjwatson> I'm pretty sure this was just a mistake in publish-release
[12:21] <ogra_> ah, good
[12:21] <cjwatson> And actually it dates back forever
[12:21] <ogra_> funny, i have scripts using zsync here
[12:21] <cjwatson> ./ubuntu-netbook/ports/releases/maverick/release/ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img.gz.zsync:Filename: ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img
[12:21] <cjwatson> But are those scripts pointed at dailies?
[12:21] <ogra_> and that definitely worked before the switch to lubuntu for ac100
[12:21] <ogra_> yes
[12:21] <cjwatson> publish-daily doesn't have the same bug
[12:22] <ogra_> ah
[12:22] <cjwatson> Oh, but apparently it does now
[12:22] <cjwatson> Blast
[12:22] <cjwatson> OK, so we have two bugs here
[12:23] <cjwatson> Oh, I se
[12:23] <cjwatson> e
[12:24] <cjwatson> fixed - I'll regenerate *.zsync now
[12:29] <cjwatson> ogra_: Lubuntu daily should work now
[12:29] <ogra_> yay, great
[12:29] <ogra_> will test, one sec
[12:31] <ogra_> http://paste.ubuntu.com/1247426/
[12:31] <ogra_> looks good
[12:31] <ogra_> (nothing to fetch indeed :) )
[12:32] <cjwatson> awesome, thanks.  I'm going to go round and fix up all the old release directories
[12:39] <cjwatson> ogra_: all fixed now, including a handful on old-releases
[12:39] <micahg> cjwatson: thanks
[12:40]  * ogra_ hugs cjwatson 
[12:42] <cjwatson> Laney: yeesh, I see what you mean about the libsoup rabbit-hole
[12:43] <Laney> cjwatson: I have some tabs open to keep an eye on things, but couldn't be bothered to annoy for many rescores
[12:43] <Laney> gsettings-desktop-schemas armel/ppc would be a good start
[12:43] <cjwatson> that's where I'd just got to
[12:44] <Laney> of course it could go further than that
[12:44] <cjwatson> those at least have satisfiable build-deps
[12:44] <cjwatson> so rescored
[13:05] <Laney> oho, a pre-release backport
[13:15] <cjwatson> ^- needed (along with a debian-installer upload later) to let me check appropriate lowmem levels for bug 1050595
[13:15] <ubot2> Launchpad bug 1050595 in lowmem "Ubuntu Server installation with 128M ram hangs" [High,In progress] https://launchpad.net/bugs/1050595
[13:16] <cjwatson> so I'd quite like that in quickly if somebody has time to review
[13:16]  * ogra_ sees popey's release team report and laughs
[13:16] <ogra_> " Lots of love in lenses" ....
[13:16] <popey> :)
[13:17] <popey> phew!
[13:17] <ogra_> so we ship a partnetr search lens ? or is it p0rn ?
[13:17] <ogra_> :)
[13:18] <stgraber> cjwatson: looking at lowmem
[13:18] <stgraber> well, once LP is done generating the diff...
[13:24] <stgraber> slangasek: we are still requiring FFe for multi-arching packages right? (was looking at libgnomecanvas in the queue)
[13:27] <cjwatson> ta
[13:27] <popey> could a kind release team member please cast an eye over https://bugs.launchpad.net/unity-lens-music/+bug/1054720 ?
[13:27] <ubot2> Launchpad bug 1054720 in unity-lens-music "[UIFE] Previews: Unable to preview banshee songs in the dash" [Medium,Fix committed]
[13:30] <stgraber> I asked Till to confirm that the brother-lpr-drivers-common upload is sane as it's not linked to a bug and it's not clear whether the change has been tested or the impact on the resulting binaries
[13:35] <hallyn> hi - any objections to FFE for bug 1049908 ?  it's a pretty nice improvement in upstart control over auto-start lxc instances
[13:35] <ubot2> Launchpad bug 1049908 in lxc "[FFE] Upstart control of lxc container instances" [Medium,Confirmed] https://launchpad.net/bugs/1049908
[13:38]  * smartboyhw discovers there will be no release weekly update email from Studio oh no:P
[13:38] <stgraber> hallyn: reviewing
[13:39] <stgraber> hallyn: btw, you should subscribe ~ubuntu-release to the FFe
[13:39] <hallyn> i did
[13:41] <hallyn> oh.  well i did, but lp timed out.  9tab os still open)
[13:41] <stgraber> hallyn: change looks reasonable. Did you try it with a lucid container to check that the two minutes timeout works properly and the container gets killed "properly"?
[13:41] <stgraber> (lucid or anything that doens't have a SIGPWR handler)
[13:42] <hallyn> stgraber: no, i'll set up a trst for that, thx
[13:43] <hallyn> (we'll want to knwo that whether the ffe is granted or not :)
[13:44] <stgraber> yeah, and I'm not going to grant the FFe if it regresses containers that aren't running >= precise :)
[13:44] <stgraber> (especially as I'm running a fair number of those myself :))
[13:56] <barry> Laney: gah.  i keep expecting bzr to dtrt :(
[14:30] <hallyn> stgraber: lucid container stops just fine
[14:30] <ogra_> skaet, meeting or not today ?
[14:31] <hallyn> stgraber: and do so immediately, so i assume it's actually listening to sigpwr and shutting down
[14:31] <stgraber> hallyn: hmm, it shouldn't, unless you backported the shutdown job in the lxc package?
[14:32] <stgraber> hallyn: you may want to try removing the shutdown.conf job then and check what happens, without it, the container should take 2min doing nothing then be killed
[14:32] <hallyn> http://paste.ubuntu.com/1247608/
[14:33] <hallyn> stgraber: yeah maybe you're right.
[14:34] <hallyn> re-testing
[14:37] <hallyn> stgraber: after 120 second timeout the container gets killed
[14:37] <hallyn> so seems to DTRT to me
[14:40] <ScottK> popey: The banshee thing doesn't look particularly critical to me (adding functionality that's merely missing, not broken, with a non-default application).
[14:41] <popey> thanks for the feedback ScottK
[14:41] <ScottK> popey: I was about to comment in the bug that it should wait.  Do you disagree?
[14:42] <popey> actually I don't. please comment away./
[14:43] <stgraber> hallyn: good
[14:43] <hallyn> stgraber: actually, i'm not sure lxc-instance beahves the same on reboot
[14:43] <hallyn> 'stop lxc-instance NAME=l1' waits for the timeout,
[14:43] <hallyn> but i have a feeling that reboot immediately kills it.
[14:45] <ScottK> popey: Thanks.
[14:47] <skaet> ogra_, yup meeting.
[14:48] <ogra_> ok
[14:48] <hallyn> feh, bad test
[14:48] <smartboyhw> Yay meeting
[14:48] <ogra_> skaet, thanks (i have a really sick cat around and need to schdule a vet appt. so i needed to know :) )
[14:49] <smartboyhw> skaet, scott-work will be too busy to send the release emails today:(
[14:49] <ogra_> smartboyhw, he could have delegated to you :)
[14:49] <smartboyhw> ogra_, well he didn't:P
[14:49] <skaet> ogra_,  sorry about your cat.  :(   likely short one, since not that many reports made it in,  but its important to sync up.
[14:50] <ogra_> skaet, yeah, i guess he will be fine (has a red swollen nose looking like a clown atm)
[14:51] <ogra_> likely some catfight leftover :) teenagers, y'know :)
[14:51] <skaet> poor fellow.  sounds like an abscess, and yeah you want that looked at as soon as possible.  :/
[14:51] <ogra_> yup
[14:55] <hallyn> stgraber: all right, found a bug.  at this point ig uess it waits until r :)
[14:55] <stgraber> hallyn: what's the bug?
[14:56] <hallyn> stgraber: if instance is running and you reboot, the lxc-instance job times out but then reboot is cancelled
[14:57] <hallyn> it may be easy to fix but is subtle enough not to play with this late.
[14:57]  * hallyn biab
[14:57] <stgraber> ok
[14:59] <stgraber> ScottK: we seem to be good at coliding on FFes ;)
[15:00] <ogra_> smartboyhw, you shoudl tell him your are available for the next time ;)
[15:00] <smartboyhw> ogra_, I did tell him that I am available:P
[15:01] <ScottK> stgraber: Did we agree?
[15:01] <cjwatson> Laney: What's the libaacs sync for?  It looks fine; the changes just all appeared to be for other operating systems :-)
[15:01] <stgraber> ScottK: initially, no, but after hallyn did some more tests, yes :)
[15:02] <ScottK> All good then.
[15:03] <Laney> cjwatson: There's a leak fix that ricotz forgot to mention in the changelog
[15:03] <cjwatson> Ah, I noticed that and wondered if it was relevant.  Fine then.
[15:03] <Laney> (it's a sponsored upload for him)
[15:03] <cjwatson> OK
[15:10] <cjwatson> Laney: I think I left gtkmm3.0 in the queue because the diff was giant and I was tired
[15:10] <cjwatson> Laney: I'll have a look over it now
[15:11] <Laney> I think xnox attempted to say something about it earlier but gave up before he got there ;-)
[15:11] <xnox> Laney: meh... i was wrong anyway
[15:12] <cjwatson> I guess the half-million line new file docs/reference/gtkmm-3.0.tag which I really don't care about helps
[15:12] <cjwatson> giant docs are giant
[15:14] <smartboyhw> skaet: I will change the work item link for Ubuntu Studio in https://wiki.ubuntu.com/ReleaseTeam/Meeting/2012-09-28?action=show&redirect=ReleaseTeam%2FMeeting%2FAgenda, it got an extra hyphen:P
[15:15] <skaet> thanks smartboyhw :)  appreciate it.
[15:16] <smartboyhw> OK link changed
[15:16] <smartboyhw> Eee 38% completed...Not good:(
[15:18] <cjwatson> Right.  It's gigantic, but it's basically all docs, trivial changes such as whitespace, and bits of new API exposed from GTK+ that's appropriately annotated.  Accepted.
[15:25] <cjwatson> xnox: So, this partman-auto upload looks right to me; nice work.  However, doesn't automatically_partition/replace/choices need essentially the same changes?
[15:25] <cjwatson> xnox: I'll accept it for now as I think this is a clear improvement
[15:25] <infinity> cjwatson: Hahaha, re: metalink oops.
[15:26] <xnox> cjwatson: it probably does =) but need to check if I affects desktop installer. It does offer wipe & install currently. Unless replaces is something different....
[15:26] <infinity> cjwatson: Also, that d-i upload there seems a bit premature with a new linux-ti-omap4 sitting in the queue...
[15:27] <ogra_> which actually fixes a d-i issue :)
[15:27] <xnox> cjwatson: ok. thanks for accepting that. Also there is ubiquity commit to go with it: handling "quantal (development branch)" -> "12.10" upgrades.
[15:27] <cjwatson> infinity: Which I saw after the upload :-(
[15:27] <cjwatson> xnox: I forget what replace is
[15:27] <cjwatson> infinity: But I'd kind of like a new d-i before my EOD so that I can do some lowmem testing
[15:27] <xnox> cjwatson: also the reuse is not very multi-disk / multi-install aware.....
[15:28] <cjwatson> It was really more for that than the new kernel
[15:28] <infinity> cjwatson: Oh.  I'll unreject the reject I just did. :P
[15:28] <cjwatson> Heh.  Thanks
[15:28] <cjwatson> xnox: Yeah
[15:28] <cjwatson> Various bits of partman-auto aren't desperately so
[15:28] <infinity> cjwatson: And I'll do another bump tonight when ti-omap is done, no big deal.
[15:28] <xnox> cjwatson: if it's pre-existing it's not very RC then =)
[15:28] <cjwatson> Indeed
[15:29] <cjwatson> And the last thing in the queue is libgnomecanvas, which stgraber was questioning whether it needed an FFe
[15:30] <cjwatson> stgraber: If you think it would be bad for somebody else to accept it without having noticed the conversation, then reject and let stokachu know that it's a hold rather than a hard reject
[15:30] <doko> cjwatson, pinged stokachu. maybe wait until Monday?
[15:31] <cjwatson> doko: I'm in no rush to accept it; I just want to make sure somebody doesn't accept it without seeing this conversation
[15:31]  * infinity would be inclined to grant it the FFe without the paperwork, personally.
[15:31]  * cjwatson has no opinion on that
[15:31] <cjwatson> The actual work looks fine to me, though I haven't line-by-lined it against Multiarch/Implementation
[15:35] <infinity> Oh, hey, maybe those -16 kernels should be in the release pocket first.
[15:35]  * infinity does that.
[15:35] <cjwatson> Oops, did I miss that?  Sorry
[15:36] <infinity> All better.
[15:36] <infinity> I'll retry all the builds after the archive's sorter.
[15:36] <cjwatson> It'll be an hour before d-i can build, then :-/
[15:36] <infinity> And sorted, too.
[15:36]  * cjwatson slowly climbs back up the stack to armel/powerpc builds working again
[15:37] <cjwatson> copied gtk+3.0 from -proposed
[15:37] <cjwatson> and I see -lowlatency's done too
[15:38] <infinity> I copied it too.
[15:38] <infinity> I may have also beaten you to gtk+3.0
[15:38] <cjwatson> Meh, PCJs won't care much
[15:38] <infinity> Sadly, sru-release doesn't appear to actually check pending publishing records.
[15:39] <infinity> Or maybe it's copyPackage itself that doesn't.
[15:39] <smartboyhw> Yay now I got scott's permission to send the mails:P
[15:39] <cjwatson> sru-release doesn't; the check is done in the async job
[15:39] <cjwatson> Or indeed Archive.copyPackage doesn't
[15:39] <cjwatson> Wait, did I understand you right?
[15:40] <infinity> Dunno.
[15:40] <infinity> Clearly, the checks happen a bit late in the tools, given that one ends up with two ACCEPTs, and two messages to -changes, and then the OOPS later. :P
[15:41] <cjwatson> Hah
[15:41] <cjwatson> The OOPS is a bug no matter what
[15:41] <cjwatson> I thought I'd fixed that, actually
[15:41] <stgraber> cjwatson: is there a way to check who's the uploader for something in the queue?
[15:41] <cjwatson> Maybe not well enough
[15:41] <infinity> You may have fixed the OOPS.  Check your mail, since it's your ACCEPT that should have oopsed.
[15:41] <slangasek> stgraber: yes, multiarching is not a no-risk change and ought to go through FFe
[15:42] <infinity> But -changes definitely shows us both accepting gtk+3.0, so that part's broken for sure. :)
[15:42] <cjwatson> stgraber: Look at the .changes
[15:42] <ogra_> slangasek, i'm poked about a MIR for the xdg pam stuff ... coudl you file one ? security team is informed
[15:43] <slangasek> if a separate bug is wanted for the MIR, sure
[15:43] <ogra_> apparently :/
[15:43] <infinity> cjwatson: The .changes in the queue unhelpfully has the signature stripped.
[15:44] <mdeslaur> ogra_, slangasek: nah, that's fine
[15:44] <mdeslaur> ogra_, slangasek: I'm about to comment in the ffe bug
[15:44] <stgraber> infinity: was just about to point that out :)
[15:44] <smartboyhw> skaet, I will help to send the release meeting emails, I got permission from scott-work :)
[15:44] <slangasek> mdeslaur: ok cool
[15:44] <ogra_> mdeslaur, oh, great, the people in -meeting disagreed so heavily :)
[15:44] <Laney> and syncs have no .changes :-)
[15:44] <slangasek> mdeslaur: how many beers is your comment costing me? :-)
[15:45] <ogra_> slangasek, one
[15:45] <mdeslaur> slangasek: none since you actually know how to write good code apparently :)
[15:45] <ogra_> i dealt with that already ;)
[15:45] <slangasek> heh
[15:45] <infinity> Laney: Syncs in the queue actually have an uploader associated with them anyway, quite prominently, so that's not hard to track down. :P
[15:45] <ogra_> oh, i made the deal with jdstrand ... so he might claim the beverage at UDS :)
[15:45] <cjwatson> stgraber: I think failing that there's an API feature somewhere ...
[15:46] <doko> slangasek, I don't care if it's a separate issue, just get the information filed and assign it to security
[15:46] <Laney> infinity: not sponsoree though. So it's kind of the opposite to what you get from .changes
[15:46] <cjwatson> (firefox hangs for a bit every time I look at +apidoc, so give me a minute)
[15:47] <infinity> Laney: Uploader is the more interesting person to me, most of the time, in that I hold them responsible for whatever broke. :P
[15:47] <cjwatson> huh, the uploader isn't exposed
[15:47] <infinity> Laney: (If they want to hunt down the person they broke things on behalf of, that's their issue)
[15:48] <cjwatson> It wouldn't be desperately hard to export PackageUpload.signing_key, if somebody wants a mini-project
[15:49] <stgraber> cjwatson: getting a .uploader for queue entries giving us a person object would be neat, then I could finally have queuebot show the IRC nickname of the uploader :)
[15:49] <cjwatson> Although it might be better to export an API method with a reference to the person
[15:49] <cjwatson> So that you don't have to do URL hacking on signing_key.self_link to get it
[15:50] <cjwatson> Somebody should file a bug for it at least :)
[15:50] <cjwatson> It could just be a renamed version of findPersonToNotify
[15:51] <cjwatson> Though worth checking that it behaves properly for syncs
[15:52] <cjwatson> I suspect you could refactor _giveKarma a little bit in terms of it, too
[15:52] <mdeslaur> skaet: ACK from the security team on pam-xdg-support (LP: #894391)
[15:52] <ogra_> \o/
[15:52] <cjwatson> processing linux-ac100
[15:52] <slangasek> whoo, snowed the security team again
[15:52] <infinity> mdeslaur: Many thanks.
[15:53] <slangasek> fwiw before we seed it there's a license compatibility niggle to sort out
[15:53] <stgraber> cjwatson: https://bugs.launchpad.net/launchpad/+bug/1058186
[15:53] <ubot2> Launchpad bug 1058186 in launchpad "Make it possible to retrieve the uploader (signer) of a package upload" [Undecided,New]
[15:54] <cjwatson> Ta
[15:54] <cjwatson> Any web UI change there would have to be careful to bulk-load the person objects or else it'll be timeout city
[15:55] <cjwatson> I think there might be a query limit test on the queue page already - if not there should be :)
[15:55] <cjwatson> Oh great, did somebody NBS-remove ac100 before processing NEW?
[15:56] <cjwatson> Whoever that was triggered a bug in kernel-overrides. :-)
[15:58] <infinity> cjwatson: linux-ac100 is pure universe anyway, if that helps.
[15:58] <stgraber> ^ stokachu is now doing a few more rebuilds. I'll pull it from rejected once the paperwork is in order.
[15:59] <cjwatson> infinity: Yeah, I worked that out
[15:59] <skaet> thanks mdeslaur   :)
[15:59] <cjwatson> I think the NBS bit may have been a red herring, as it let me remove those.  Probably a bug somewhere else in kernel-overrides.
[16:00] <infinity> cjwatson: I can't say that I use kernel-overrides for >= precise anyway, since we don't actually have any kernel packages that publish to multiple components anymore.
[16:00] <infinity> cjwatson: But I guess it helps that I also do kernels enough to know which ones live where.
[16:00] <popey> skaet, when you have a moment, could you please review https://bugs.launchpad.net/unity-lens-shopping/+bug/1055684 now b2 is out there
[16:00] <ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress]
[16:00] <infinity> cjwatson: (Well, that's even true of SRU kernels at this point, where I know exactly which bits live where, but that's more a sad statement about repetition...)
[16:03] <cjwatson> Anyone have an opinion on the UIFe in bug 1043379?
[16:03] <ubot2> Launchpad bug 1043379 in indicator-sync "[UIFe] sync indicator should use ubuntuone-client-* icons + new paused icon needed" [Low,Confirmed] https://launchpad.net/bugs/1043379
[16:03] <cjwatson> Corresponds to an upload in the queue.
[16:03] <stgraber> cjwatson: oh, I just rejected the upload because nobody had reviewed the UIFe yet :)
[16:03] <cjwatson> Hah
[16:04] <infinity> cjwatson: It doesn't sound like the sort of thing that would affect doc team screenshots and such, but they should probably still sign off.
[16:04] <infinity> (The feature itself sounds like something we'd want though, IMO)
[16:05] <cjwatson> Yeah
[16:05] <infinity> jbicha: Opinions?
[16:05] <Laney> didn't we (skaet) NACK indicator-sync by default anyway?
[16:06] <Laney> so, not a UIFe requiring upload.
[16:06] <infinity> Laney: ?
[16:06] <infinity> Laney: Context?
[16:06] <stgraber> stgraber@castiana:~$ seeded-in-ubuntu indicator-sync
[16:06] <stgraber> gir1.2-syncmenu-0.1 (from indicator-sync) is seeded in:
[16:06] <stgraber>   edubuntu: dvd
[16:06] <stgraber>   ubuntu: daily-live
[16:06] <stgraber> Laney: ^
[16:07] <stgraber> and it's in main
[16:07] <stgraber> ignore me, it's just an unrealted binary built from the same source :)
[16:07] <stgraber> *unrelated
[16:07] <Laney> I'm pretty sure it got denied.
[16:07] <infinity> Yeah.
[16:07] <infinity> I'm curious why that unrelated binary ends up in live, actually.
[16:08] <jbicha> if indicator-sync isn't included by default, it doesn't need UIFE
[16:08] <Laney> Which means not default which means not a UIF matter
[16:08] <infinity> Right.
[16:08] <infinity> Unrejecting. :P
[16:08]  * cjwatson gives back a bunch more stuff
[16:08] <stgraber> infinity: they don't, only thing in daily-live is gir1.2-syncmenu-0.1 (that or seeded-in-ubuntu is lying)
[16:09] <infinity> stgraber: Yes, I was wondering about that binary specifically. :P
[16:09] <stgraber> infinity: my guess is that ubuntuone is pulling it somehow so it can integrate if the indicator is installed
[16:10] <Laney> yeah, stuff uses the APIs
[16:10] <Laney> it's just not exposed in UI
[16:13] <cjwatson> OK, FTBFS due to install failures trimmed a bit
[16:16]  * infinity tidies up the gtkhtml rebuilds.
[16:16] <infinity> Or, rather, will do so once this publisher run finishes.
[16:21] <cjwatson> I thought I'd done that
[16:22] <cjwatson> https://launchpad.net/ubuntu/+source/gtkhtml4.0/4.6.0-0ubuntu1 seems to be all built - did I miss something?
[16:23] <infinity> cjwatson: I just forced it to build on armel and powerpc, but then evoltuion and a couple others need to build, I'm on it.
[16:23] <infinity> cjwatson: It has slightly wonky shlibs.
[16:23] <cjwatson> OK
[16:26] <Daviey> stgraber, ScottK, skaet: Just looked at bug 1055684.. seems wedged on us.
[16:26] <ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress] https://launchpad.net/bugs/1055684
[16:27] <Laney> Daviey: The last comment says what's going to happen.
[16:28] <ScottK> skaet: ^^^ is for your review.
[16:28] <Daviey> Laney: Yes, blocked on us.
[16:28] <Laney> Things are often blocked on us. It's designed that way
[16:29] <Daviey> Laney: I'm really rather aware of that, but thanks for the patronising clarification,
[16:29] <Daviey> I'm merely pinging it as a, 'lets look at this'.
[16:29] <Laney> :/
[16:42] <skaet> Daviey, ScottK, Laney - have added my thoughts to it,  and done some targetting.
[16:42] <skaet> stgraber, ^
[16:43] <Laney> cheers
[16:43] <ScottK> Thanks.
[16:43] <Laney> wasn't there another one we were re-reviewing too?
[16:43] <Laney> emblems or something
[16:43] <skaet> Laney,  mark commented on it.   priority is fixing critical bugs.
[16:44]  * skaet goes to look it up,  checked on it last night and saw it was ok
[16:44] <slangasek> doko: pre-promoting pam-xdg-support before it's seeded?  that's usually a good way to get it dropped out of main again when someone reconciles component-mismatches :)
[16:44] <Laney> yep. I like it.
[16:46] <Laney> ScottK: ^ perhaps you'd care to take -shopping?
[16:46] <ScottK> What bug?
[16:46] <Laney> bug #1055649
[16:46] <ubot2> Launchpad bug 1055649 in unity-lens-shopping "[FFE] Change from http to https and verify cert" [Critical,Confirmed] https://launchpad.net/bugs/1055649
[16:48] <ScottK> Approved.
[16:50] <Laney> ScottK: It's in the queue too
[16:50]  * Laney hopes that's ASAP enough
[16:50] <cjwatson> slangasek: I thought it was usually a good way to get doko to object too ;-)
[16:50] <ScottK> Excellent.
[16:50] <Laney> can't approve it myself as it's my upload
[16:50] <ScottK> Ah.
[16:51]  * ScottK looks
[16:52] <stgraber> hmm, looks like it's unbdling the preview code as well?
[16:52] <Laney> hmm
[16:52] <stgraber> which was rejected
[16:52] <stgraber> http://launchpadlibrarian.net/117674538/unity-lens-shopping_6.0.0-0ubuntu1.1_6.0.0-0ubuntu2.diff.gz
[16:52] <stgraber> a bit long just for a http => https change :)
[16:52] <Laney> well, it's not 'just' that, but you might be right
[16:52] <Laney> sec
[16:53] <ScottK> Is queuediff broken for everyone or just me?  It lies about if there's a diff for ^^^ Laney's upload.
[16:54] <Laney> oh, I get it, trunk got merged into the brnahc without me noticing
[16:54] <Laney> rejecting, reuploading
[16:56] <stgraber> seb128: can I ask you to detail the other fixes in light-themes? It's easy for me to spot what's related to the spinners and I agree that it's a bug but I have no idea what the other changes are and can't be sure they wouldn't need a UIFe
[16:57] <stgraber> I'm fine with you simply explaining them on IRC, no need to re-upload
[16:58] <seb128>   Fix hover check in rows
[16:58] <seb128>   Fixes for the scale progressbar
[16:58] <seb128> Fixes #1055376
[16:58] <seb128> bug #1055376
[16:58] <ubot2> Launchpad bug 1055376 in light-themes "gnome-panel not rendered correctly" [Undecided,Fix committed] https://launchpad.net/bugs/1055376
[16:58] <seb128> fixes to scale in backdrop toolbar
[16:58] <seb128>  
[16:58] <seb128> stgraber, those are the commits
[16:59] <stgraber> ok, that matches the diff. accepted
[16:59] <stgraber> seb128: thanks
[16:59] <seb128> stgraber, thanks
[17:06] <Laney> stgraber: ^ take two
[17:06] <Laney> looks like there's a little refactor in there that's not quite related to the SSL enabling
[17:07] <Laney> but it doesn't seem bad to me
[17:07] <stgraber> Laney: looking
[17:08] <stgraber> well, once LP is kind enough to give me a diff ;)
[17:10]  * Laney feeds LP some more hamsters
[17:10] <Laney> really need to go, once this is OK
[17:13] <popey> thanks for getting this sorted promptly guys & gals. really appreciated.
[17:13] <Laney> ♥
[17:14]  * Laney 's mind is now firmly on the tasty piece o'pork that's waiting to be cooked by me
[17:14] <popey> ooh
[17:14] <popey> i like the sound of that
[17:15] <popey> i prefer the sound of someone else cooking food and bringing it to my door though
[17:15] <Laney> might be a bit cold by then :(
[17:16] <popey> well yes, Nottingham to Farnborough isn't likely to result in a hot meal in my lap :(
[17:16] <popey> although I wasn't specifically requesting you do the making and delivering. i hear there are companies that will do that for me :)
[17:16] <Laney> hot pork direct to your door
[17:16] <Laney> ahem.
[17:17] <popey> :)
[17:18] <Laney> stgraber: a diff has arrived just for you
[17:19] <stgraber> Laney: accepted
[17:20] <Laney> yaaaaaaaay
[17:20] <Laney> thanks
[17:20] <stgraber> np
[17:20] <popey> win
[17:20] <Laney> branch pushed. I'm SO OUTTA HERE
[17:20] <Laney> tara
[18:01] <stgraber> I guess someone other than slangasek and myself should look at nfs-utils
[18:01] <infinity> stgraber: I'll poke it with a stick.
[18:02] <stgraber> thanks infinity
[18:06] <doko> slangasek, I had it already promoted
[18:07] <slangasek> doko: I think that's my point?
[18:07] <slangasek> it's promoted before it's seeded
[18:07] <slangasek> which means it now shows up on component-mismatches
[18:08] <infinity> slangasek: How well-tested are these nfs-utils changes of yours?
[18:09] <slangasek> infinity: I've tested them on my own network, which uses krb5 on both nfsv3 and nfsv4; I've also done some in-VM testing with extra sleeps sprinkled through to try to ferret out any race conditions
[18:10] <infinity> slangasek: I note you use "mounting TYPE=nfs*" in your new upstart jobs, but (at least) nfs-common.statd-mounting.upstart still uses "mounting TYPE=nfs" (others may as well, that one just happened to show in the diff)
[18:11] <infinity> slangasek: Intentional, or incomplete change to the wildcard?
[18:11] <slangasek> infinity: intentional, with slightly inaccurate changelog description
[18:11] <slangasek> infinity: the statd service is only relevant to nfs v3
[18:12] <slangasek> so will never have TYPE=nfs4
[18:12] <infinity> Oh, fair point.
[18:12] <infinity> I was just thinking from the other direction (treat all nfs* the same), but yeah, nothing >> 3 will need statd, and there's no nfs3 type.
[18:13] <slangasek> that was mostly about making things be TYPE=nfs* where they were TYPE=nfs4 before, because using 'nfs4' is deprecated (ask smb for details)
[18:14] <infinity> Right, well, other than that, it looks sane, and it's not the sort of thing that's auditable without actual testing, so I'll trust that you and your VMs have had some quality time. :P
[18:15] <micahg> are the dailies not on yet?
[18:15] <infinity> micahg: They're on, but mostly broken due to the flood of stuff that built/skewed post-beta.
[18:16] <micahg> infinity: ah, I didn't even see a log on people.c.c, so that prompted the question
[18:19] <slangasek> should we perhaps have been rejecting more of those skew-inducing packages from the queue and requiring reuploads to -proposed?
[18:20] <infinity> slangasek: Probably, yes.  I long for the day when uploads to $series just get rewritten as $series-proposed on accept.
[19:04] <phillw> hiya good people, the kernel team have released 3.5.0-16.24 will it quietly arrive in the next iso daily build?
[19:05] <skaet> infinity,  you going to spin the d-i to with that kernel?
[19:07] <phillw> thank you queuebot :)
[19:08] <phillw> the kernel fixes the nVidia issue, along with quite a list! https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1043518/comments/45
[19:08] <ubot2> Launchpad bug 1043518 in linux "live cd is unusable due to video degradation with the splash boot option enabled" [High,Fix released]
[19:10] <infinity> skaet: d-i was already rebuilt for the latest kernel, but there will be another one for omap4 as well soon.
[19:10] <infinity> skaet: Oh, right, new kernel again.  Yes, there will be a new d-i to match. :P
[19:11] <phillw> infinity: will it arrive in tomorrows' cron build? (I ask so I can let the testers affected by it know).
[19:11] <infinity> phillw: If tomorrow's image builds work, the new kernel will be in them, yes.
[19:12] <phillw> thanks :)
[19:12] <skaet> thanks infinity
[19:35] <stgraber> why do I have the feeling that we'll see those again soon?
[19:40] <Daviey> stgraber: any moment... I rejected.
[19:52] <kenvandine> stgraber, they are coming again!
[19:53] <Daviey> queuebot: mute queue new
[19:53] <Daviey> mute ubuntu-release new quantal-releas
[19:53] <Daviey> mute ubuntu-release new quantal-release
[19:53] <Daviey> (i'm causing just as much noise, trying to remmeber the synatx))
[19:58] <stgraber> yeah and the muting wasn't quite working last time someone tried it
[19:58] <stgraber> mute queue New
[20:00] <Daviey> i suck.
[20:02] <kenvandine> Daviey, you seem to have muted it
[20:02] <Daviey> kenvandine: stgraber did
[20:02] <kenvandine> oh
[20:02] <kenvandine> hehe
[20:03] <kenvandine> stgraber, you can unmute now
[20:03] <stgraber> [2012/09/28 20:01:20] DEBUG: New => returning 20 items
[20:03] <kenvandine> they are in
[20:03] <Daviey> wait
[20:03] <Daviey> noise of acceptance, and noise of binaries, and noise of binary acceptance
[20:03] <kenvandine> Daviey, i hope you aren't going to make poor alex change something else :)
[20:03] <kenvandine> ah
[20:03] <kenvandine> whew
[20:04] <stgraber> you shold have pushed an extra 5 webapps, then the flood protection of the bot would have kicked in :)
[20:04] <stgraber> *should
[20:06] <Daviey> hah
[20:06] <Daviey> kenvandine: first binary accepted :)
[20:24] <Daviey> unmute queue New
[20:24] <Daviey> kenvandine: all done
[20:33] <kenvandine> Daviey, thanks!
[22:08] <xnox> Why did I stop getting emails about syncs?
[22:09] <xnox> I used to always get email about it e.g. now in unapproved queue as a sponsor.
[22:09] <xnox> syncpackage: Request succeeded; you should get an e-mail once it is processed.
[22:09] <xnox> namazu2 ^^^^
[22:10]  * xnox is annoyed.
[22:10] <stgraber> e-mails coming from the DC have been quite delayed for me lately, some coming in 2-3 hours after upload (or any other change really)
[22:10] <stgraber> haven't requested syncs in a while though so I'm not sure if those are completely broken
[22:11] <Laney> I haven't gotten Waiting for Approval mails for syncs
[22:11] <Laney> did get accepted though
[22:11] <xnox> Laney: ever or lately?
[22:14] <Laney> xnox: I can't see that I ever had one
[22:15] <xnox> bug 1058364
[22:15] <ubot2> Launchpad bug 1058364 in ubuntu-dev-tools "not getting 'waiting for approval' email when sponsoring syncs when the archive is frozen" [Low,New] https://launchpad.net/bugs/1058364
[22:15] <xnox> it also affects launchpad
[22:16] <Laney> it /only/ affect launchpad
[22:16] <Laney> not much udt can do about that
[22:16] <xnox> Laney: not tell me to wait for an email?! =)
[22:16] <Laney> you also never get FTBFS emails from API syncs
[22:16] <xnox> Laney: loop and query the queue same as queubot does
[22:17] <xnox> Laney: well =) i don't want those
[22:17]  * xnox runs away
[22:21] <ogasawara> ^^ When someone has a moment, could I get the linux-3.5.0-16.25 kernel approved in the queue
[22:25] <infinity> ogasawara: Yep.
[22:26] <ogasawara> infinity: thanks!
[22:26] <infinity> ogasawara: You keep pre-empting my d-i uploads. :P
[22:26] <xnox> infinity: you should spinlock ogasawara
[22:26] <xnox> =)))))
[22:26] <infinity> That sounds dirty.
[22:26] <ogasawara> heh
[23:42]  * ScottK says "No, it can wait for 'R' again" ...