[14:26] <doko> Riddell: please could you wait a few hours with the kde uploads?
[14:27] <doko> especially not uploading a new kdebindings before the armel build is in the archive
[14:33] <Riddell> doko: why?
[14:34] <doko> did you read my email about making python 2.7 the default today?
[14:38] <Riddell> don't think I did
[18:27] <GrueMaster> Can someone publish linux-image-2.6.35-24-omap?  It is pending publication, and I need to get it tested from -proposed before it can be released.
[20:54] <GrueMaster> Still waiting for a kernel to get published.
[21:16] <cjwatson> GrueMaster: processed; should be visible in ~1.5 hours
[21:22] <GrueMaster> Thanks.  I've been asked to test it for two days now.
[21:27] <cjwatson> it only appeared in the NEW queue six or seven hours ago.
[21:33] <GrueMaster> I know.  But the kernel team released it yesterday.
[21:34] <GrueMaster> And it was published for everything BUT armel.
[21:34] <cjwatson> I can't make armel builds go faster :-)  I imagine somebody looked at the queue when armel hadn't finished building yet, that's all.
[21:35] <GrueMaster> So it is a manual process.  Good to know.
[21:35] <cjwatson> Any time package names change it requires manual intervention.
[21:36] <cjwatson> Thus, any kernel ABI change requires manual intervention.
[22:53] <sconklin> How can I solve this problem? - A source package containing an incorrect .orig.tar.gz (which had the correct file name) was uploaded to a ppa, and now I need to make that orig.tar.gz go away, or replace it with the correct one.
[23:02] <cjwatson> sconklin: you'll have to ask #launchpad if there's a way - the Ubuntu archive admins have no control over PPAs
[23:02] <sconklin> cjwatson: thanks
[23:02] <cjwatson> (for Ubuntu the answer would be "the only way is to bump the upstream version")
[23:03] <sbeattie> that's also pretty much true for ppas, as well.
[23:06] <sconklin> that's a bit of a problem for the kernel ;-)
[23:07] <sbeattie> sconklin: I don't disagree, and I also think it should be relaxed for PPAs versus the ubuntu archive, but that's what people in #soyuz tell me.
[23:08] <cjwatson> there are some good reasons for it in corner cases around making corresponding source available, even for PPAs
[23:08] <sbeattie> sconklin: it's *possible* for it to go away eventually from the ppa, if you delete it and wait on the order of a couple of weeks.
[23:08] <sconklin> yeah. It's a case of totally understanding the rules and why they exist, but trying to unwind a mistake
[23:08] <sconklin> ok, I tried deleting it and waiting an hour
[23:09] <cjwatson> anyway, #launchpad may be able to advise on adminy options that are available
[23:09] <sconklin> I'm asking there
[23:09] <ScottK> sconklin: Make a different PPA and upload it there.  consistency among PPAs is not enforced.
[23:10] <sconklin> ScottK:  this is our non-virtualized kernel build PPA
[23:10] <ScottK> Yeah, well that makes it a bit tough.
[23:11] <ScottK> You might arange for a hot spare in case it's needed.
[23:11] <cjwatson> (corner cases: imagine that your new version fails to build on one architecture.  now ppa.launchpad.net is distributing source for the new version but can't distribute source for the old version due to a filename clash.  imagine you never bother to fix this.  is ppa.launchpad.net now violating the GPL?)
[23:12] <sconklin> cjwatson: totally understood. And it's possible that someone (anyone) grabbed a copy of the built package
[23:13] <ScottK> cjwatson: That wouldn't necessarily be an issue for a private PPA.  Perhaps the rules could be relaxed for those (I've got a use case for that).
[23:18] <cjwatson> I expect actually that it's just too annoying to figure out the publication rules :-)