=== jjohansen is now known as jj-afk === smb` is now known as smb [14:26] Riddell: please could you wait a few hours with the kde uploads? [14:27] especially not uploading a new kdebindings before the armel build is in the archive [14:33] doko: why? [14:34] did you read my email about making python 2.7 the default today? [14:38] don't think I did === bjf[afk] is now known as bjf === jj-afk is now known as jjohansen [18:27] 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] Still waiting for a kernel to get published. [21:16] GrueMaster: processed; should be visible in ~1.5 hours [21:22] Thanks. I've been asked to test it for two days now. [21:27] it only appeared in the NEW queue six or seven hours ago. [21:33] I know. But the kernel team released it yesterday. [21:34] And it was published for everything BUT armel. [21:34] 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] So it is a manual process. Good to know. [21:35] Any time package names change it requires manual intervention. [21:36] Thus, any kernel ABI change requires manual intervention. === bjf is now known as bjf[afk] [22:53] 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] sconklin: you'll have to ask #launchpad if there's a way - the Ubuntu archive admins have no control over PPAs [23:02] cjwatson: thanks [23:02] (for Ubuntu the answer would be "the only way is to bump the upstream version") [23:03] that's also pretty much true for ppas, as well. [23:06] that's a bit of a problem for the kernel ;-) [23:07] 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] there are some good reasons for it in corner cases around making corresponding source available, even for PPAs [23:08] 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] yeah. It's a case of totally understanding the rules and why they exist, but trying to unwind a mistake [23:08] ok, I tried deleting it and waiting an hour [23:09] anyway, #launchpad may be able to advise on adminy options that are available [23:09] I'm asking there [23:09] sconklin: Make a different PPA and upload it there. consistency among PPAs is not enforced. [23:10] ScottK: this is our non-virtualized kernel build PPA [23:10] Yeah, well that makes it a bit tough. [23:11] You might arange for a hot spare in case it's needed. [23:11] (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] cjwatson: totally understood. And it's possible that someone (anyone) grabbed a copy of the built package [23:13] 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] I expect actually that it's just too annoying to figure out the publication rules :-)