[09:12] <brendand> does anyone know the milestone at which the images go from being hosted on cdimage to being hosted on releases?
[09:12] <brendand> i see alpha1 is on cdimage. will alpha2 be?
[09:20] <cjwatson> brendand: we normally put betas on releases.u.c, not alphas
[09:21] <brendand> cjwatson, thanks. that would make the most sense. is there any sort of enforcement around that? will betas always be on releases?
[09:21] <cjwatson> Why are you asking?
[09:22] <cjwatson> It's currently implemented in lp:ubuntu-archive-tools publish-image-set.pyp
[09:22] <cjwatson> .py
[09:22] <cjwatson>     if 'alpha' in milestone:
[09:22] <cjwatson>         official = 'no'
[09:22] <cjwatson>     else:
[09:22] <cjwatson>         official = 'named'
[09:22] <brendand> good enough for me
[09:23] <brendand> it's for a script that needs to assemble url's to iso's as part of it's operation
[09:23] <cjwatson> OK
[09:54] <brendand> cjwatson, are there a fixed number of possible milestones?
[09:56] <cjwatson> brendand: No
[10:17] <Laney> I would appreciate it if people could comment on my proposal on list so that it can be rolled out before A2 freezes start if indeed we want it.
[10:18] <Laney> it would involve a DB change to LP, so the lead time is kind of long
[10:23] <tumbleweed> Laney: is this a safe change to make, before we can get -backports to build against packages in -backports?
[10:26] <Laney> I think the intended fix there is to have the buildds ignore it
[10:27] <Laney> and I believe infinity was going to do that, so maybe it is a simple matter of pokage
[11:07] <jamespage> please could someone reject 'simple-http' from the quantal NEW queue - uploaded with a crufty orig.tar.bz2
[11:24] <seb128> jamespage, done
[11:24] <jamespage> thanks seb128!
[11:24] <seb128> yw
[13:40] <stgraber> mute tracker
[13:40] <stgraber> mute
[13:40] <stgraber> unmute tracker
[13:41] <stgraber> ^ upgraded to the multi-threaded version, should be lower latency for queue monitoring and when controling the mute entries
[13:54] <xnox> stgraber: =))))
[13:59] <highvoltage> stgraber: I guess LP bug 1013172 is a security bug?
[14:08] <stgraber> highvoltage: no, just private
[14:08] <highvoltage> ah right I guess since it might contain passwords
[14:09] <stgraber> highvoltage: and it's public now as it doesn't contain anything private that I could see
[14:09] <highvoltage> stgraber: I think it might contain passwords entered in ubiquity
[14:10] <stgraber> highvoltage: no, ubiquity wasn't running in debug mode, so the debconf transactions aren't logged and IIRC even when it's in debug mode, the passwords are stripped
[14:11] <highvoltage> stgraber: ok great
[14:12] <stgraber> highvoltage: oh, I see the problem. cjwatson ported ubiquity-bluetooth-agent to python3 but didn't add a dependency on python3-gobject
[14:12] <stgraber> highvoltage: I'll quickly test that it's indeed the only missing bit and will add the dependency if that's the case
[14:17] <highvoltage> stgraber: k
[14:19] <cjwatson> stgraber: no such thing as python3-gobject
[14:19] <cjwatson> stgraber: needs to be ported to gi
[14:20] <stgraber> cjwatson: yeah, I just noticed. Moving it to Gobject from gi.repository
[14:20] <cjwatson> (which looks like it should be easy)
[14:20] <cjwatson> but yeah, my bad for not noticing that
[14:20] <cjwatson> stgraber: "IIRC even when it's in debug mode, the passwords are stripped" sadly not
[14:20] <cjwatson> (well, unless I've forgotten something)
[14:24] <stgraber> cjwatson: that's too bad, though at least it's easy to check in the logs whether they're running in debug mode or not and carefuly check then...
[14:25] <stgraber> cjwatson: "from gi.repository import GObject as gobject" did the trick, same API
[14:25] <cjwatson> Good, but no need to use 'as gobject', you can just change the single place where it's used
[14:26] <cjwatson> Sorry, two places
[14:27] <stgraber> indeed :)
[14:33] <stgraber> could someone review my -proposed upload of nagios-plugins in hardy-proposed, it's been waiting in the queue for 10 days now?
[14:35] <xnox> stgraber: review or SRU verify?
[14:36] <stgraber> xnox: just review and let through to -proposed. Verification is easy, I have 15 machines hitting the bug every day :)
[14:36] <xnox> stgraber: ok =))))
[14:36] <stgraber> so I just need to upgrade them to that package and check that I don't get angry e-mail from Nagiosafter that
[14:37]  * xnox has stopped reading automatic email from my server.... maybe I should make them less verbose
[14:38] <stgraber> yeah, I have adopted a policy of fixing the source of the e-mail rather than ignoring them, monitoring is pointless if you don't read the notifications :)
[16:46] <henrix> infinity: hi. could you take a look at the hardy kernel, to copy it into -proposed?
[16:46] <henrix> infinity: bug #1012143
[16:46] <ubot2> Launchpad bug 1012143 in linux "linux: 2.6.24-31.102 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1012143
[16:48] <infinity> henrix: I thought you guys were doing the proposed copies yourselves these days (except where we need to clean up overrides after the fact)
[16:48] <infinity> henrix: But this one shouldn't need override tidying, as there's no ABI bump.
[16:48] <henrix> infinity: well, i know we execute the copy-proposed-kernel.py script, but that alone doesn't do the job, does it?
[16:49] <henrix> infinity: i believe brad executed that script on this kernel already anyway
[16:50] <henrix> infinity: (i don't actually have upload rights, so i can't run the script. but i can bug other guys on the stable team to do... something...?)
[16:50] <infinity> henrix: copy-proposed-kernel.py is all that should be required in this case.
[16:50] <henrix> infinity: hmm, ok. so maybe brad forgot to run it on this kernel.
[16:51] <henrix> infinity: so, i'll ping him again to run it.
[16:51] <henrix> infinity: thanks
[16:51] <infinity> henrix: I can just do it right now.
[16:52] <infinity> henrix: Was just pointing out that you guys can, and have been. :)
[16:52] <henrix> infinity: yeah, i knew we were able to run that script but i though something else had to be done by an AA
[16:52] <infinity> henrix: AAs need to intervene post-script-run if there's an ABI bump (because the new packages land in universe)
[16:52] <henrix> infinity: but it looks like this is only needed for kernels that require the overrides
[16:53] <infinity> henrix: For non-ABI-changing uploads (like this one), we don't need to get involved.
[16:53] <henrix> infinity: ok, got it. thanks for the clarification.
[16:53] <infinity> henrix: Oh, hah.
[16:53] <infinity> henrix: It could be that the script has been run a few times and no one has accepted it from UNAPPROVED.
[16:53] <infinity> :P
[16:54] <infinity> La la la.
[16:54] <infinity> Done.
[16:54] <henrix> infinity: heh :)
[16:54] <henrix> infinity: cool, thanks! :)
[16:54] <infinity> Sorry, this is a rather Mondayish Monday.
[16:54] <henrix> infinity: yeah, similar problem here!
[18:51]  * slangasek blinks
[18:51] <slangasek> 2012-06-18 18:50:40 ERROR   Cross-PARTNER copies are not allowed.
[18:51] <slangasek> what's that about?
[18:53] <slangasek> hmm, apparently requires --to-partner with it, ok