[00:11] lifeless / maxb: https://launchpad.net/ubuntu/lucid/+source/dpkg/1.15.5.6ubuntu4.4 [00:13] The diff LP has generated is: http://launchpadlibrarian.net/57004735/dpkg_1.15.5.6ubuntu4.2_1.15.5.6ubuntu4.4.diff.gz [00:13] which is against *4.2 [00:14] https://launchpad.net/ubuntu/+source/dpkg/1.15.5.6ubuntu4.2/+publishinghistory <--- is odd [00:14] *.1 is marked Superseded by 4.3 ! [00:14] *.2 isn't marked superseeded, just deleted with the comment "moved to -updates" === bjf is now known as bjf[afk] [00:17] The debian/changelog for 4.3 doesn't mention 4.1 (oddly) [00:18] In any case, LP is giving an incorrect diff to me.... :/ [00:18] (if you debdiff 4.3 and 4.4, you get the diff i expected. [00:18] ^^ Downloading the .dsc's from launchpad. [00:21] Daviey: File a bug? [00:25] lifeless: wilco [00:43] Daviey: 4.3 was a security update [00:44] Therefore, at the time 4.4 was uploaded to proposed, it's possibly that 4.2 was still the latest in the updates pocket? [00:45] * maxb curses at the difficulty of finding a link to https://launchpad.net/ubuntu/+source/dpkg/+publishinghistory, and manually composes the URL [00:45] hmm, apparently not, 4.3 was copied to updates long before 4.4 hit proposed [00:46] oh, gah, I bet LP saw that there was an earlier dpkg in lucid-proposed, and didn't check other pockets [01:07] Daviey: seen the above ^ [01:07] ? [01:08] maxb: the link is on the package page on the top right [01:09] Ah, I failed to look to the portlet [01:23] * achiang is looking for some help with recipes [01:23] i created one for my package here - https://code.edge.launchpad.net/~achiang/+recipe/abby [01:23] 1st question - my latest lucid build failed, but looking at the build log, it looks like it wasn't my fault [01:24] (dangerous thing to say, yes...) [01:24] but i want to just try and rebuild that if i can, and i don't see any way to do that [01:24] heh, good timing, I was about to raise the same issue :-) [01:25] Aborting on failed virtualization check: [01:25] xen-detect is not installed [01:25] Looks like terranova is broken, at least for recipe builds? [01:25] laaaaaaaaaaaaaamont [01:25] ? [01:25] mwhudson: i live in the same time zone as lamont and it's 1830 here [01:26] ah [01:26] s/time zone/town/ :) [01:26] https://code.launchpad.net/builders/terranova/+history <---- all recipe builds fail [01:26] ok, so it's not just me then [01:27] 2nd question then, is -- shouldn't my maverick package (which built successfully) have been uploaded to my ppa? [01:27] yet, apt-get update ; apt-cache policy doesn't seem to show the new version. and it built quite a while ago [01:28] i have a build from 2010-11-11 whose icon says, "build uploading". perhaps that is bollixed up? [01:29] yeah, there's a bug for that already [01:29] maxb: pointer? [01:30] mwhudson: otoh, I work somewhat mid-atlantic timezone hours [01:30] terranova, you say? [01:30] * lamont goes looking [01:31] terranova has the right launchpad-buildd in it.. [01:32] gah [01:32] lamont: lessee... GMT-2 is exactly in the middle of the atlantic. meaning you're working at 2330? ;) [01:32] I am now roughly 4 hours past my EOD [01:32] OTOH, my day starts at 0500 local [01:32] * achiang is a slacker at only EOD+2 [01:34] lamont: that might explain why I thought you were in the UK [01:34] * lamont is feeling post-EOD laziness... any other machines that have "xen-detect is not installed" as a recipe build failure, please let me know about it. [01:34] micahg: understandable [01:34] note that I am not a morning person. I just really value my afternoons [01:35] terranova is fixe [01:35] d [01:35] meh. /me checks the others, TSA-style [01:36] lamont: any hints on packages not uploading to PPAs? or is that outside your bailiwick? [01:37] describe this "not uploading" thing of which you spea, [01:37] k [01:38] here's my recipe page - https://code.edge.launchpad.net/~achiang/+recipe/abby [01:38] lamont: from that, i would have assumed that the builds from 1 hour ago would have been uploaded by now [01:38] hm. [01:38] * achiang goes to double check and ensure he pushed the "push to ppa" option [01:39] They have uploaded. [01:39] lamont: yes, i did have an archive selected when i requested the build [01:39] Apart from the one from two weeks, which was caught in a bug that has since been fixed. [01:39] 6 of the 16 had xen-detect installed. :( [01:40] Huh. I just skimmed all the i386 builders history pages and didn't spot any others broken [01:40] achiang: Which build seems to still be uploading? [01:40] achiang: that'd be "why don't my recipe builds seem to upload to my ppa", which would be in the land of "not familiar with that yet" [01:41] maxb: to be fair, the 16 include many amd64 and lpia buildds [01:41] wgrant: hm, i don't see it uploaded? http://pastebin.ubuntu.com/535739/ [01:41] and it's quite likely that the ones that were already correct were the rest of the i386 family [01:41] achiang: Which build? [01:42] wgrant: this one claims to still be uploading, but note i do not really care about it. the packages i built today supersede it - https://code.edge.launchpad.net/~achiang/+recipe/abby/+build/7286 [01:42] achiang: That apt-cache policy checks that the binaries are all built and published. [01:42] * lamont leaves achiang in wgrant's very capable hands [01:42] wgrant: the package i care about is either https://code.edge.launchpad.net/~achiang/+recipe/abby/+build/8665 or this one https://code.edge.launchpad.net/~achiang/+recipe/abby/+build/8667 [01:43] lamont: thanks [01:43] achiang: 8667's binary build (https://code.launchpad.net/~achiang/+archive/laika/+build/2060780) finished not long ago and isn't yet published. [01:43] Also, is there a reason you're still using edge? [01:43] edge is deprecated now. [01:44] wgrant: so you're saying apt-cache policy isn't a good check? apt-get dist-upgrade doesn't show me laika as a candidate for install then [01:44] achiang: The source is uploaded and published, but the binaries aren't published yet. [01:44] wgrant: Do you happen to know if someone is doing to do some sql to fix up all the spuriously "uploading build" build records? [01:44] maxb: I don't know. You'd have to ask Code. [01:44] wgrant: i don't know why i'm still on edge. one reason is because i don't see an option for recipes on !edge [01:45] wgrant: but i am pretty incompetent, so highly likely to be PEBCAK [01:45] achiang: Ah, you're not in the beta testers team? [01:45] wgrant: i never asked to be part of that team, so if it was an explicit opt-in, then no, i am not on that team [01:46] achiang: You might want to join https://launchpad.net/~launchpad-recipe-beta. [01:46] wgrant: I find I still use edge because tab completion in firefox still only knows edge [01:46] wgrant: ah, now i see that 8667 superseded 8665, which is why 8665's binaries were never published [01:46] achiang: (recipes were previously exposed to everyone on edge, since we didn't have a way to restrict a feature to a particular team) [01:46] lamont: is that history or something else? [01:47] lamont: Yeah, that's almost fixed for me. [01:47] achiang: the recipe beta team includes launchpad-beta [01:47] lamont: But some little-used pages still want to go to edge :( [01:47] * achiang joins launchpad-recipe-beta [01:47] lifeless: history [01:47] that and not caring enough to correct history [01:48] ah, now i see the recipe link on !edge, thank you [01:49] if a recipe package builds in one distro series, but not another, do the successful build's binaries still get published? [01:50] achiang: yes. [01:50] They're pretty much independent. [01:50] ok [01:50] Oh, hmm, good point about edge and firefox [01:50] * maxb fires up sqlite3 on firefox places.sqlite ;-) [01:51] last dumb question -- is there a way to request a rebuild on a failed recipe build, the way that i [think] i can on a normal package in a PPA? [01:52] * lamont wanders off with family [01:52] achiang: No, you have to request a new build. It was decided that there was no benefit allowing an existing build to be retried. [01:52] achiang: But perhaps we could add a retry link which automatically populates the build request form. [01:52] wgrant: ok, fair enough. i just think it is a little confusing that i can request a rebuild sometimes, but not all the time [01:53] (normal PPA binary build retrying is a hack from 5 or so years ago, and we haven't managed to find the time to fix it yet) [01:56] i think that might be a slight exaggeration [01:56] as ppas are only about 3 years old... [01:57] mwhudson: But the binary build retry button came years before PPAs. [01:57] ah ok [02:32] how do i delete/edit a comment with accidental sensitive information in it? [02:35] someone will be with you soon to help [02:38] lifeless: thanks, you a bot or a person? :) [02:38] A person I hope [02:40] sorry, that nick in correspondence with that answer made me think that there might be a bot that says that if noone responds within a certain timeframe (not even a bad idea actually ;) ) [02:42] I suspect the nearest sysadmin is having lunch [02:42] you may need to wait here a bit [02:44] yeah, no worries [02:44] the sooner I get it removed, the happier my customer will be :) [03:03] walterheck: heyo, sorry, yes was at lunch. [03:04] spm: no worries [03:10] spm: thanks for teh quick and great help! [03:10] anytime === Lcawte is now known as Lcawte|Away [07:12] when i do a release, is there an easy way to have the status of all bugs targeted to that milestone change to "Fix Released"? [07:14] there are scripts around that can do that [07:14] there is one in the lp source tree [07:15] lifeless: ah, that brings me to another question: what are the current best practices for automating launchpad releases, what tools do you recommend? [07:16] theres some stuff in ubuntu-dev-tools [07:16] or in lptools [07:16] I use the lptools ones myself [07:17] okay, thank you! [07:18] lp-milestones release foo/bar [07:18] lifeless: maybe just *one* more question: is there a way to test release automation in a sandbox? to make sure stuff is working with launchpad how i want, but not actually make a release [07:19] * jderose installs lptools [07:19] jderose: Use staging.launchpad.net [07:19] StevenK: awesome, thanks. [07:21] there's an environment variable you can set to do that [07:21] aaron has some now 'thekraken' thing, but I haven't looked into that yet. [07:24] lifeless: I've got a new oops timeout for bug 575450 that's marked pg83 [07:24] Launchpad bug 575450 in Soyuz "+copy-packages nearly unusable due to timeouts (affected: 5, heat: 17)" [High,Triaged] https://launchpad.net/bugs/575450 [07:25] micahg: great [07:25] lifeless: do you want it here or in a comment on teh bug? [07:25] either [07:25] lifeless: OOPS-1789EA420 [07:25] https://lp-oops.canonical.com/oops.py/?oopsid=1789EA420 [07:28] micahg: s/edge// ! [07:29] lifeless: I can try it :) [07:29] it won't be better [07:29] was an old bookmark [07:29] but the cluster has more resources [07:29] lifeless: is it worth a shot for a cleaner oops? [07:30] micahg: its the same code [07:30] won't make a difference [07:30] ok, thanks [07:30] lifeless: should I try one package at a time (this was 3) [07:30] may help [07:30] its doing BESERK query counts [07:30] 1218 [07:31] wow, ok, do you need me to keep anything for a test case? [07:31] StevenK: hey [07:32] lifeless: ? [07:32] https://bugs.launchpad.net/soyuz/+bug/575450 has you assigned to it [07:32] Launchpad bug 575450 in Soyuz "+copy-packages nearly unusable due to timeouts (affected: 5, heat: 28)" [High,Triaged] [07:32] is that accurate? [07:34] I thought that was a regression I introduced and then fixed [07:34] r10847 [07:34] StevenK: introduced maybe. [07:34] Fixed, no. [07:34] (of devel) [07:35] StevenK: I just want to know if you're looking at it [07:35] No [07:35] or if the assignee is stale [07:36] This could be an unrelated change [07:36] Because I did fix the root cause I introduced [07:37] sure [07:37] I'm not one for blame anyhow [07:37] lifeless: The bug as reported by Max can be closed; I'm not sure what micahg's issue is [07:38] StevenK: I've taken over the bug [07:38] StevenK: I found it based on tag and title [07:38] as it wasn't marked closed [07:38] shrug, Making a new one would be needless ffort at this point I think. [07:39] That OOPS is old, do we have a new one? [07:40] the oops is new, 5 minutes old [07:40] OOPS-1789EA420 is new? [07:40] https://lp-oops.canonical.com/oops.py/?oopsid=1789EA420 [07:40] 15 surely? [07:40] $new [07:41] Bleh [07:41] Editing the first comment of a bug just confuses people [07:41] good practice for keeping things understandable [07:42] No, it doesn't help at all. Since the first comment doesn't show a time it was updated, you corrlate that with the reported date [07:42] Which leads to confusion [07:42] erm [07:42] you may [07:42] but its the description [07:43] Okay, let me clarify. It confuses *me* [07:43] nearly everyone edits it when things change [07:43] that brings up the issue of hijacked bugs, if the bug's not hijacked, it keeps the important information in one place [07:43] its not the first comment, its the description. Iz Different. [07:43] Okay, so it's an UI bug, then [07:43] But it's comment #0 :( [07:43] Which could be read as the first comment [07:43] StevenK: that there's no timestamp on the description ? [07:43] wgrant: comment #0 is the original description link [07:43] Right [07:44] Anyway, I'm not interested in arguing semantics [07:44] StevenK: its clearly not the first comment because there are fields between it and the others. [07:44] sure. [07:44] lets see if there is a bug fo rthat [07:45] Ah, ~ubuntu-mozilla-security [07:45] That PPA is *large* [07:46] StevenK: not much in it ATM though [07:46] copying three packages though... doing 1218 queries for a 3 package copy is nuts [07:46] micahg: Where are you copying to? [07:46] lifeless: Nuts? This. Is. Soyuz. :/ [07:46] StevenK: ppa:mozillateam/thunderbird-stable [07:46] wgrant: Nuts is as Nuts Do [07:47] wgrant: that should be 40 queries, tops. [07:47] maybe 50 if you put me over a barrel [07:47] sorry, that's pretty unhelpful: https://edge.launchpad.net/~mozillateam/+archive/thunderbird-stable [07:47] Yeah, I found it [07:48] Not sure what's going on there [07:48] https://bugs.launchpad.net/malone/+bug/680808 [07:48] Launchpad bug 680808 in Launchpad Bugs "edit time of description should be shown near the descripton (affected: 1, heat: 6)" [Undecided,New] [07:49] StevenK: single object based code [07:49] StevenK: I sent mail about those idioms again today :) [07:50] * StevenK tries to swap in how the packing copier works [07:50] s/ing/age/ [07:55] that gives me the idea for a feature request -- Dehijack bugs [07:56] ah, bug 279370 [07:56] Launchpad bug 279370 in Launchpad Bugs "Method for splitting one bug report into two (affected: 3, heat: 6)" [Low,Triaged] https://launchpad.net/bugs/279370 === almaisan-away is now known as al-maisan [08:14] anyone involved with purple-plugins-pack? [08:14] there's a typo bug which leads to a plugin not being included [08:14] uhm [08:14] you might want #ubuntu-devel or something for that === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === kancerman_ is now known as kancerman [10:10] hi, I have a problem with merging an old account of mine. I don't have access to the old email anymore, but I can "prove" pretty well that i'm the person ;) Whom to contact? [10:38] seife? [10:38] bah, gone [10:38] no patience === matsubara-afk is now known as matsubara [11:45] Hmm... the builders seem to be plentiful, but https://launchpad.net/ubuntu/+source/openvswitch/1.1.0~pre2-5ubuntu1 hasn't been built yet - is there something wrong? [11:46] (published 20hrs ago) [11:49] There are no builds. [11:49] The architecture string is 'all linux-any', which may be confusing things. [11:49] I'm not even sure that makes sense. [11:53] Debian Policy seems OK with it :( [11:54] It doesn't make much sense to me, though. [11:56] wgrant: what does the policy say it means? [11:57] jelmer: It doesn't. [11:57] ah. fun. [11:57] But we should treat it the same as linux-any. === mrevell is now known as mrevell-lunch [11:58] I' [11:58] m pretty sure we don't have any tests for that sort of thing at the moment. [11:58] I believe I added some when I added linux-any support in the first place. [11:58] * wgrant looks. [12:00] Yeah, package-arch-specific.txt is not too bad. [12:00] Bug #680889 [12:00] Launchpad bug 680889 in Soyuz "Needs to handle "all linux-any" like "linux-any" (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/680889 [12:02] that upload should have been rejected if it doesn't have any builds [12:02] bigjools: Not for the primary archive. [12:02] ! [12:02] Ah, actually, I missed the bit of Policy which specifies this behaviour: [12:03] "Specifying a list of architectures or architecture wildcards indicates that the source will build an architecture-dependent package, and will only work correctly on the listed or matching architectures. If the source package also builds at least one architecture-independent package, all will also be included in the list." [12:03] I don't understand how that's remotely useful [12:03] bigjools: Distro people asked for it. [12:03] wgrant: Which section is that? [12:03] soren: 5.6.8 [12:04] bigjools: I believe the specific case was that they didn't want to blacklist ARM-specific stuff, since ARM was to be introduced soon. [12:04] bigjools: But if they tried to sync it, LP rejected. [12:04] The same thing applies to bootloaders for various archs now. [12:04] do our server kernels have CONFIG_SECURITY_CAPABILITIES ? [12:05] bigjools: You're not trying that mlockall thing, are you? [12:05] yes [12:05] :( [12:05] any better ideas? [12:05] Do we actually know that that's the problem? :/ [12:05] no [12:06] the problem is that the SYN packets are not acked [12:06] which triggers the 30 second kernel timeout [12:06] not a lot we can do about that [12:06] bigjools: Concerning. [12:07] From the Lucid -server config: [12:07] CONFIG_SECURITY_FILE_CAPABILITIES=y [12:07] not quite the same.... unless it changed? [12:07] wgrant: "In the main debian/control file in the source package, this field may contain the special value all, the special architecture wildcard any, or a list of specific and wildcard architectures separated by spaces. If all or any appears, that value must be the entire contents of the field. Most packages will use either all or any." [12:07] soren: ... so I wasn't crazy to implement it like that. [12:08] wgrant: I think the section you quoted refers to what will land in the binary .changes file. [12:08] Policy contradicts itself, yay. [12:08] Oh. [12:08] That line you quoted refers to debian/control. [12:08] Which isn't relevant here. [12:08] wgrant: which explains the phrasing: "..*will* also be included.." (emphasis mine) [12:09] soren: It says that the .dsc can include a list of architectures, architecture wildcards and 'all'. [12:09] This should really be three or four subsections. [12:10] wgrant: You're absolutely right. My bad. === al-maisan is now known as almaisan-away [12:26] wgrant: sorry, just seen your reply - and your LP bug, thanks [12:27] wgrant: short term fix is to revert the linux-any ? [12:28] Daviey: Right. [12:28] wgrant: thanks. [12:35] wgrant: if i comment the LP: # of the bug you raised in the changelog of that package, it won't mark that one fix released - right? [12:36] Daviey: Right. [12:36] groovy === apachelogger is now known as releaselogger [12:49] Daviey: Hi, did you see my remarks on soyuz diff generation yesterday? [12:50] maxb: I did, thanks - i copied them onto the package bug [12:50] great [12:51] maxb: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/633015/comments/6 [12:51] Launchpad bug 633015 in dpkg (Ubuntu Lucid) "debian/source/include-binaries doesn't allow for inclusion of modified binaries (affected: 1, heat: 49)" [Undecided,Fix committed] [12:51] * Daviey notes he is having bad luck finding LP bugs atm :) [12:52] Did you file a Soyuz bug on it? [12:53] maxb: yes... :) [12:54] bug #680911 [12:54] Launchpad bug 680911 in Soyuz "Soyuz doesn't reliably use the correct previous package version, when calculating supersedes and diffs. (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/680911 [12:55] what's wrong with the supersedes? [12:55] *.2 isn't marked superseeded, just deleted with the comment "moved to -updates" [12:55] ?? [12:56] We don't supersede deleted things, because they don't exist to be supersedd. [12:56] So .2 was deleted, then later .4 was uploaded. [12:56] There was nothing left to supersede. [12:56] hmm [12:56] Daviey: can you please not post IRC logs in bug descriptions [12:57] bigjools: oh, why is that? [12:57] it's much easier for people if you can post the actual problem, the logs are quite raw to read [12:57] or you can post the irc log underneath a summary, that's fine [12:57] bigjools: Hmm.. Have others made a similar point? [12:58] I've never heard that as an objection before, that is all. [12:58] Daviey: It's common sense really: don't make every person reading the bug re-derive the problem from the IRC log [12:58] Daviey: it's been mentioned in passing that it makes it harder to go into a bug and .... what maxb says [12:59] maxb: Regarding the superseded stuff - https://launchpad.net/ubuntu/lucid/+source/dpkg/1.15.5.6ubuntu4.1 <-- confuses me [12:59] states it was superseded by .3 [12:59] Yes, something is odd there - it looks like 4.2 was not actually ever moved to updates, despite the comment on the deletion from proposed implying that [12:59] bigjools: perhaps guidance on what the Soyuz project wants in bug reports would be helpful :) [12:59] .1 was in -proposed, then copied to -updates and deleted from -proposed. [13:00] .2 was deleted from -proposed, but never copied to -updates. [13:00] Then .3 was deleted from -proposed and copied to -updates. [13:00] Daviey: This is not Soyuz specific. It's just general optimization of use of people's time [13:01] Daviey: what maxb said :) [13:01] fair comment. [13:02] Daviey: I'm not singling you out or anything, it's just that as you can imagine I get a *lot* of bugs on Soyuz and when I read ones like yours I'm far less likely to deal with it right away [13:03] * maxb retitles: Diff generation in the proposed pocket should consider the updates pocket even when there are previous proposed publications. [13:03] bigjools: It is somewhat frustrating to discover two Soyuz bugs in under 24 hours, which is slowing me down also... :) [13:04] Daviey: I understand. We're working hard to fix them all, honest :) [13:05] bigjools: Thanks... I can reform the description if you want. === mrevell-lunch is now known as mrevell [13:05] Daviey: that'd be awesome [13:05] bigjools: There's only 150 each. We should be able to knock them all off during the bugjam... right? :P [13:06] hahaha [13:06] Daviey: I just rewrite the description [13:06] it's also highly likely this is a dupe bug, I need to check [13:07] wgrant: you should fix 150 bugs before breakfast! :) [13:08] so it looks like it should ignore the pocket really [13:08] Except for security and backports :/ [13:09] proposed should look at the latest from {updates, proposed, security} [13:09] security should just look at security. [13:10] Although I guess security never has direct uploads at the moment. [13:10] well it can use the pocket dependency guff === kostja_osipov is now known as feodor === feodor is now known as kostja_osipov === almaisan-away is now known as al-maisan [14:25] Could someone see what's the matter with https://edge.launchpad.net/ubuntu/+source/gnat-gps/4.3-5ubuntu3/+build/2061206 ? [14:25] Terminate it please [14:25] it has been running since 5 hours [14:26] * bilalakhtar got to go === matsubara is now known as matsubara-lunch === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === matsubara-lunch is now known as matsubara === al-maisan is now known as almaisan-away [15:41] despite dput telling the upload was successful, I can't find any trace of it on lp, is there some lag currently ? === almaisan-away is now known as al-maisan [15:42] I did the upload ~20 mins ago [15:42] bah, nvm, here it is [15:43] How do I make a mailing list private on LP? [15:49] vila: it should always email within 5 minutes [15:50] * vila cheks [15:52] bigjools: the mail arrived, but almost at the time I found it on lp, no big deal, that could indicate a lag in the mail transport instead [15:52] it could [15:52] rhaa, I mean a lag on the mail from me to lp [15:53] yeah, I read it as that :) [15:53] ok :D [15:54] the 5 mins is a good tip anyway, I'll add that before complaining next time ;) [15:54] * vila notes: always wait 5 mins more before complaining [15:55] Won't the world be a better place if this was applied recursively... [15:55] :D === bjf[afk] is now known as bjf [16:20] Is soyuz OK? I'm getting "Connection failed, aborting. Check your network [Errno 111] Connection refused" [16:20] (when trying to upload to a PPA) [16:20] ScottK: I'll check [16:20] Thanks. [16:21] Also the last two uploads I did have failed to appear. [16:22] vila said his were slow too [16:22] hmmm [16:22] ScottK: ftp server is up again [16:22] it had died [16:22] Thanks. [16:23] you beat nagios :) [16:23] bigjools: Can you check on if an upload made it for a private PPA? [16:23] I can, PM me details [16:23] OK [16:33] ScottK: you can blame pitti, he's uploaded what looks like a million language packs to ~ubuntu-langpack [16:34] OK. [16:34] it's anywhere from 5 seconds to 15 seconds to process each upload [16:36] It might be nice if the queue were visible like the build queue. [16:36] I agree === beuno is now known as beuno-lunch [16:40] bigjools: Maybe you could speak to a soyuz developer about the idea? [16:40] ;-) [16:41] * bigjools blinks. Did ScottK just crack a joke? [16:59] Does anyone here know about LP mailing lists? === al-maisan is now known as almaisan-away [17:13] mrevell, ping, if you have a moment, I have a question about the feedback@ mail auto-reply text. [17:13] Hi mars === beuno-lunch is now known as beuno [17:40] how long should I expect to wait until my package is no longer "i386 - Pending publication" [17:41] PPA or main archive? [17:41] PPA [17:41] jml: 5-15 minutes depending on load [17:42] given that pitti just uploaded a million langpacks the system is quite busy right now :( [17:43] ahh [18:27] back [18:52] what's the ETA for the next launchpad update? i need rev11953 (so one more than the current) === releaselogger is now known as apachelogger === apachelogger is now known as bloglogger [19:22] fta: we're green now, I'll schedule a deploy [19:22] excellent [19:27]