[00:04] woot, with the tarfile fails cleaned off, it's looking quite good. [00:12] I have a one-liner patch that I'd kind of like landed on devel. Is it appropriate to bother with a branch just for this?: [00:12] - >>> http = HTTPCaller(host='launchpad.dev') [00:12] + >>> http = HTTPCaller() [00:14] maxb: How're you dealing with tarfile? Just fixing the tests in the 2.6 branch? [00:15] yes [00:15] I've pushed that [00:15] Great. [00:17] maxb: nothing lands without a branch; but it doesn't have to be yours :P [00:17] I guess my question is: is that too trivial for the reviewer overhead? [00:19] thats what rs= is for :) [00:21] right :-) [00:21] Hrm. valid_absolute_url('whatever://example.com/blah') ---> False in 2.5, True in 2.6, because of stdlb chanes [00:21] *changes [00:22] * maxb wonders what to do about that [00:24] I was wondering about that one. [00:24] Does it now ignore the scheme? [00:24] We already monkeypatch in extra schemes (sftp and bzr+ssh come to mind). [00:25] This may also cause the DB constraint to be relaxed, which would be seriously seriously bad. [00:26] OK, yes, it's seriously seriously bad. [00:27] Oh, wait, that *is* the DB constraint. Oops. [00:27] Or maybe not. i am confused. [00:27] * wgrant reads. [00:28] wtfness [00:28] I don't know. This seems like a Python bug. [00:29] Or at least a really dangerous behaviour change. [00:29] py2.6 urlparse disregard the uses_netloc list when parsing urls and treats anything beginning with // as netloc based [00:29] Yep. [00:29] WTF [00:29] Which is arguably saner than maintaining a list of specific schemes, but changing behaviour is just stupid [00:30] Not just stupid -- very dangerous. [00:31] Should we change both valid_absolute_url implementations to explicitly check the scheme against the monkeypatched uses_netloc? [00:33] It looks to me like the only thing that uses this is c.l.interfaces.validation.validate_url, which already checks against a passed in list of schemes [00:34] maxb: What about valid_absolute_url in trusted.sql? [00:35] That will suffer the same bug, but is an independent implementation to the one failing the tests [00:36] maxb: Right. But I would not fix the tested one until we've fixed the other one too, since it appears to be untested. [00:36] Although i guess it could be tested, but PostgreSQL still uses 2.5. [00:37] But no, PL/Python is built for 2.6 [00:37] So the DB constraint is untested. [00:37] Yay. [00:42] http://bugs.python.org/issue7904 [00:43] It's only a recent change. [00:43] So they must have decided to change behaviour like that in a stable update. [00:43] Awesomeness. [01:01] wgrant: Hi, do you have something in the pipeline towards landing for the foreign branch tdb issues? [01:15] maxb: I don't. I guess I should prepare the two branches. [01:15] Although I wonder if I'm going to cause bzr-hg test failures by ripping out the TDB thing. [01:16] Hm, only 8 tests left to fix. [01:17] I'm looking at the initZopelessTwice one [01:17] I looked at that before. [01:17] My initial thought was that the method had been renamed. [01:17] So the monkeypatch didn't work. [01:17] But it looks fine. [01:18] Close - 2.6 is sending that codepath into a C extension, hence avoiding the monkeypatch [01:18] I saw that evil down the bottom, but then decided to have breakfast first. [01:20] I'm in good humour, having returned to the computer having spent the evening in the pub :-) [01:20] AFAICT there are only two remaining issues that are actually mysterious. [01:20] The leftover thread one, and the _pythonpath one. [01:21] * wgrant takes bugs-emailinterface.txt [01:40] OK, so, bugs-emailinterface.txt tests for the bug that http://bugs.python.org/issue7082 fixed. [01:40] That test is probably insane. [01:41] * wgrant might talk to Bugs about that one tonight. [01:46] hmm, is emailauthentication.txt really just complaining about a wrapped line? [01:46] maxb: yes. [01:46] Just looking at that now. [01:46] The point of the test is to test for whitespace; it tells doctest to not ignore whitespace changes. [01:47] I'm not sure what the point of the test is. [01:47] It says that we must be careful, because Python unfolds things. [01:47] It appears that Python no longer does. [01:47] I cannot see an obvious entry in NEWS about this. [01:48] And the test does not make it clear what the implications of it are. [01:48] Hm, I guess as long as the authenticateEmail succeeds it should be fine. [01:48] - Issue #1670765: Prevent email.generator.Generator from re-wrapping [01:48] headers in multipart/signed MIME parts, which fixes one of the sources of [01:48] invalid modifications to such parts by Generator. [01:52] argh i hate the puller [01:52] i guess i should be happy that i'm deleting chunks of it [01:52] maxb: Do you think that the carefulness it refers to is the manual boundary handling in lp.services.mail.signedmessage.SignedMessage._getSignatureAndSignedContent? [01:53] that seems plausible [01:53] So perhaps this test failure is inviting us to reconsider whether we still need to do that? [01:53] I guess I'll delete the special case and rerun the tests in 2.5. [01:53] I think so. [01:54] Certainly I don't think the failing test has any operational significance [01:54] Hm, I guess we can't actually remove it. [01:54] Since only Lucid has the Python fix. [01:55] Oh, is this a 2.6.x fix? [01:55] So it probably deserves to have the test for broken folding removed, a bug filed, and _getSignatureAndSignedContent XXXd. [01:55] 2.6.5. [01:55] ugh [01:55] 2.6.5rc1, to be precise. [01:56] ok, concur with your plaan [02:02] biab, again [02:09] * maxb wonders what the point of filing a bug for every XXX is [02:17] maxb: Turns out the bug isn't really fixed. [02:17] It's just less broken than before. [02:17] :-/ [02:17] as_string() on the entire message preserves folding, but on the part loses it [02:17] I'll alter the test to look at the part in question, which should work for both. [02:18] * maxb is working on tolerance to the apt-ftparchive changes [02:19] I'm not sure if we want to be tolerant. [02:19] It's going to change the archive. Probably in a good way, but I'd prefer to disable SHA1 and SHA256 for now. [02:20] hmm [02:20] But I can't work out how to do that -- it doesn't seem to respect the config options when they are in the apt-ftparchive config. [02:20] They may have to be in the apt config instead, and I'm not sure if we can pass a custom one into a-f. [02:20] Mind you, I haven't looked at it for two or three months. [02:20] Interestingly, there's stuff left in the code from when the same issue affected Packages files, edgy->feisty [02:20] So I was thinking we'd handle it the smae [02:21] What happened there? [02:21] Just ellipsised out the extra hashes? [02:21] regexed them out, yes [02:21] err, string-maniped them out, rather [02:23] hmm, well, it's actually 2:20am here, so perhaps I should sleep instead :-) [02:23] Heh, probably. [02:23] Night. [02:23] I lean towards letting lucid's apt-ftparchive write the extra sums for the production archive [02:24] If it's been done before, that's fine. [02:24] It looks to have been done that way before for Packages files, we'd now be doing the analogous change for Sources files. [02:26] Hrm, have you noticed that soyuz-upload.txt is now dropping a debian 'changelog' file into the root of the LP tree when run? [02:27] I hadn't noticed. But so it does. [03:13] abentley: around? [03:13] mwhudson, a bit. [03:14] abentley: just replying to that merge proposal if you have time to look at that [03:17] mwhudson, looking. [03:29] spm, could you please run http://pastebin.ubuntu.com/414679/ across some of the logs and paste the first few lines of output? [03:37] poolie: http://paste.ubuntu.com/414681/ [03:38] urk, not quite enough [03:39] i guess it has the refererer url at the end? [03:40] spm how about http://pastebin.ubuntu.com/414683/ [03:41] poolie: yeah it does: 1.2.3.4 bugs.launchpad.net - [14/Apr/2010:07:00:04 +0100] "GET /ubuntu/lucid/+bugs?field.searchtext=&orderby=-importance&search=Search&field.importance%3Alist=CRITICAL&field.importance%3Alist=HIGH HTTP/1.0" 200 90458 "-" "Python-urllib/1.17" [03:42] poolie: http://paste.ubuntu.com/414684/ [03:42] ok, and what about the whole thing piped through '|sort|uniq -c' ? [03:44] poolie: http://paste.ubuntu.com/414686/ <== might be worth checking for skew from robots. maybe. [03:44] wow [03:44] could you chain it together with your anti-robot filter that you showed the other day? [03:45] though actually i think it's unlikely there will be too many [03:45] because there's only a form linking to this url not (i think) generally an A ilnk [03:45] link* [03:45] that histogram is pretty damn suggestive btw [03:45] i guess that's just over less than a day's data? [03:47] poolie: about half of 20 hours worth, for bugs.lp.net; not edge. [03:47] 1 of 2 servers [03:48] so something like 10-20% of a day i guess [03:48] i wonder if power users tend to use edge? [03:48] thanks for helping btw [03:50] poolie: np; just don't mention it too much eh? I have a rep as a BOFH to live up to. k? [03:50] heh [03:51] so would you mind running that on edge, across several days data, just to be sure it's not skewed? [03:51] adding edge - same server/period - doesn't change the number much; sure. [03:52] i mean catting several days of logs into it, if that's possible [03:52] so that we get a few thousand hits altogether [03:53] oh yeah - I was 3/4 thru typiing the above. figured I'd finish and then do several days [03:53] oh thanks [04:04] poolie: http://paste.ubuntu.com/414692/ about half of nearly 2 weeks worth [05:21] mwhudson: Hi. Half of the unsolved python2.6 failures are Codehosting threading things. [05:22] wgrant: oh goodie [05:22] lp.codehosting.puller.tests.test_acceptance.TestBranchPuller.test_hosted_branch_stacked_on_mirrored_branch, in particular. [05:22] If the .join callback is there, it hangs at that point. [05:22] If it is not there, it leaves a thread behind. [05:22] well, the latter isn't really a surprise, that's why the join is there :-) [05:23] Right. [05:23] Threads make me sad -- any ideas? [05:23] one small one [05:24] wgrant: i don't suppose it will make any difference, but if you go to bzrlib/tests/http_server.py:563 [05:24] wgrant: there's a comment about not having a join in a particular place [05:24] does it work if you add the join there? [05:25] wgrant: another idea would be to run gc.collect() before calling join [05:29] mwhudson: Both suggestions hang quite effectively. [05:32] wgrant: :( [05:33] wgrant: is there an easy ish way i can reproduce this myself? [05:33] i have some terrifying gdb hacks lying around i can try to use... [05:34] (https://code.edge.launchpad.net/~mwhudson/+junk/pygdb if you want to try to adapt them yourself) [05:34] mwhudson: https://dev.launchpad.net/PythonMigrationStatus <- just grab the integration branch, follow 'Setup caveats', and revert the patch which comments out the join. [05:37] Four tests remain broken, two of which we have solutions for. Yay. [05:41] not too bad [05:46] What do BranchRevision rows with a NULL sequence signify again? [05:46] stub: off mainline revisions [05:54] stub: *Ouch* at that column type change time. [05:55] difficult estimate to make though - it will be much faster on the kick arse hardware, but there are more nodes to update [05:56] It's a bit sad that 99% of that table is probably duplicated dozens to thousands of times. [05:56] wgrant: https://bugs.edge.launchpad.net/malone/+bug/557432/comments/10 [05:56] Bug #557432: Hot Bugs algorithm works poorly for some projects, making it a bad default listing [05:57] poolie: Yeah, I saw the paste. [05:57] Rather interesting. [05:57] We were both right, it seems :/ [05:57] awkward. [05:57] poolie: Note, however, that since the default view is heat, there is less need to order search results by it. [06:00] tue [06:00] true [06:00] but 42, being about 0.2% of the total, is awfully low [06:00] But I think the factor of 50 probably outweighs it by a bit. [06:00] Right. [06:02] anyhow, i hope we can do more measurements like this [06:02] they're not watertight but they bring something beyond just gut feel [06:02] Indeed. They're much better than guessing. [06:03] * mwhudson fills up his hard drive with 2.6 versions of all the eggs [06:03] mwhudson: Weren't they all in download-cache anyway? [06:03] Although you may have issues with a missing i386 version of some egg that I forget. [06:04] The 2.6 i386 meliae egg is missing, that's right. [06:04] wgrant: the download-cache mostly contains tarballs [06:04] not built eggs [06:04] Oh, so it does. [06:06] * wgrant gives up on checkwatches and leaves the last failure to Bugs. [06:17] wgrant: now i can run the test! [06:17] i wonder if that took long enough :/ [06:22] wgrant: the test passes for me :/ [06:23] wgrant: does it only fail as part of running the whole file or something? [06:23] mwhudson: Did you revert the commenting-out that is in the branch? [06:23] wgrant: yes [06:23] Argh. [06:23] bin/test -vvt TestBranchPuller [06:24] That reproduces it for at least three people. [06:25] ./bin/test -vvc lp.codehosting.puller.tests.test_acceptance [06:25] is what i'm running [06:25] if using -t makes a difference, i am going to become very angry [06:27] Tear down canonical.testing.layers.ZopelessAppServerLayer is hanging for me a _lot_ lately [06:28] Your machine hangs in the wrong place :( [06:28] and not just on this branch [06:28] Whats the fix for the GpgmeError error in the testRepositorySignatureWithSigningKey test? [06:28] i guess it's the sort of thing that rebooting, or at least logging out and in again might fix [06:28] i may have stray processes [06:29] cody-somerville: http://paste.ubuntu.com/414737/ [06:29] merci [06:30] mwhudson: With http://paste.ubuntu.com/414739/ on top of lp:~launchpad-committers/launchpad/python2.6, both my -t and your -c invocations hang. [06:36] it seems test_mirror_imported_branch might have hung [06:37] or is just very very slow [06:39] looks pretty hung by now [06:41] But a different test. [06:41] Lovely...... [06:42] woot, i have some tracebacks [06:42] gdb? [06:42] yes [06:42] after a fashion [06:42] wgrant: this is the hung thread: http://pastebin.ubuntu.com/414743/ [06:44] Doesn't look very stopped to me. [06:44] # Support people who used socket.settimeout() to escape [06:44] # handle_request before self.timeout was available. [06:44] * mwhudson is suspicious [06:44] Where's that? [06:45] wgrant: handle_request in SocketServer is at least quite different between 2.5 and 2.6 [06:45] Ah. [06:47] i guess that if you're select()ing on a server socket that's shutdown, something different happens than if you're accept()ing on a socket that's shutdown? [06:48] because that seems to be the difference [06:48] Could be, yes. [06:49] oh grar [06:49] i guess the select() in SocketServer should have self in the error list as well [06:49] It works if I force the timeout to 10 in SocketServer. [06:50] Hmmm. [06:50] Maybe. [06:52] It also works if self is in all three. [06:52] * wgrant tries with it in wlist but not xlist. [06:53] It doesn't work in just rlist and xlist. [06:54] i think this is perhaps the same issue: http://bytes.com/topic/python/answers/851825-socketserver-shutdown-deadlock [06:57] Similar. [06:57] hm [06:57] So, it works OK with self in rlist, wlist and xlist. But no subset thereof. [06:57] i guess it should be fixed in bzr [06:57] can probably fix it by hacking in launchpad though [06:57] well, it should be fixed in python [06:57] but it's a bit late for that [06:58] Indeed... If you can work out the appropriate Launchpad hack, we can probably have the test suite passing under 2.6 in a few hours. Yay. [07:06] wgrant: http://pastebin.ubuntu.com/414750/ maybe [07:07] mwhudson: Is that actually the right solution, though? [07:07] well it doesn't seem to work :( [07:07] oh no [07:08] confusing slow and hanging tests there [07:08] mwhudson: http://bugs.python.org/issue2302 seems to be a bug about that shutdown thing you linked to earlier. [07:09] wgrant: that seems a bit different [07:10] wgrant: the problem that i saw was that the server thread went into a select that will never return [07:10] Right. [07:10] So server_forever was indeed running at the time, so it's probably irrelevant. [07:11] noi [07:11] server_forever is not called [07:11] Bah. [07:11] by bzrlib [07:11] Anyway, lecture over... I should go home. [07:11] haha [07:12] wgrant: do you want me to push that patch somewhere, or .. ? [07:12] mwhudson: If it makes sense to you and probably doesn't just work by accident, I guess push it to the 2.6 branch. [07:13] At least it's only used in tests; it can't go horribly wrong. [07:16] OK, now I just have to get approval for one change from Bugs, advice from them on another, and we need to work out the best fix for validate_absolute_url. [07:16] Then we are DONE. [07:16] Thanks for fixing that one/ [07:16] * wgrant wanders off. [07:22] hm [07:22] not sure the fix is right actually :( [07:44] good morning [08:51] *blink* [08:51] regexes are really discouraged entirely in launchpad code?! [08:52] is this really true? [08:53] first I've heard of it [08:54] noodles775 attempted to convince me of this in a code review [08:55] I can't remember who had mentioned it to me, intellectronica perhaps - as I mentioned on the MP, it's not in the styleguide, so up to you. [08:55] re is generally faster and more reliable than adhoc stuff [08:55] so I would say 'whatever is clearer' [08:56] noodles775: Yeah, I'm not implying you're being unreasonable, I'm just experiencing shock at the concept :-) [08:56] I don't see anything in the reviewer minutes about it either [08:57] lifeless: I don't even know that it's ever come up... it was just something that I was told for a branch I had ages ago that used a semi-complicated re. [08:57] lifeless: that's why I said it was up to maxb :) [08:58] maxb: in which case, do you want me to send it off to land as is? [09:01] Morning! [09:11] noodles775: yes please, if you're happy with that [09:13] maxb: Sure. Done. [09:35] Any Bugs people around? I need advice on what to do with the section of bugs-emailinterface.txt beginning with 'Some mail clients append a filename to the content type of attachments. [09:35] ' [09:36] It breaks in 2.6, because the behaviour that it says should not occur (extracting a filename from Content-Type, rather than Content-Disposition) now occurs due to a Python bugfix. [09:37] It appears safe to fix the test to expect that the filename is extracted from Content-Type... but I'm wondering why the broken behaviour was tested in the first place. [09:45] wgrant: let me have a look [09:46] (this is one of the four remaining 2.6 failures) [09:46] intellectronica: Thanks. [09:46] actually, adeuring might know more about this. i remember he did some work in this area lately [09:47] wgrant: sorry, I just added another two in MailmanLayer to the wiki page :-) [09:47] maxb: Nooooooo. [09:47] well, I added 3 and fixed 1 [09:48] hrmmm, well, there is something.... main problem is my bad memory... let me look at the affected code/tests [09:48] I was running that just before I headed home, but it disagreed with being suspended for two hours. [09:48] adeuring: maybe i'm wrong, this is about headers in mail. i remembered that you worked on attachments in the webapp. [09:49] BjornT: do you maybe remember why this was done? ^^^ [09:49] intellectronica: yeah, you are probably right... [09:50] wgrant: i'm looking myself at the code, but my guess is as good as yours, which is why i'm looking for someone who might know the history of that code. [09:51] thumper: back, perchance? === henninge_ is now known as henninge [09:52] wgrant: what breaks in this test? [09:53] * maxb has a shocking thought: Python 2.6 for 10.04 == not unachievable [09:54] wgrant: so i'm not sure if it's really important to ignore the filename supplied with content-type, as long as it doesn't change the behaviour of signatures, right? [09:54] adeuring, intellectronica: http://pastebin.ubuntu.com/414824/ is my fix. [09:55] intellectronica: And the signature depends solely on the MIME representation; not our interpretation of it. [09:55] wgrant: yes, that sould be fine [09:55] (well, assuming a lack of Python bugs, which there is not) [09:55] wgrant: yes, that looks like the correct fix to me [09:55] intellectronica, adeuring: Thanks. [09:55] * wgrant commits to the integration branch. [09:57] maxb: Ah, I see you still love the tarfile maintainer. [09:58] :-) [09:58] I suppose I have the consolation that after figuring it out last time, this was a pretty shallow bug [09:58] wgrant: this failure actually means that LP will process mails from Microsoft Entourage somewhat better, once we switch to Python 2.6 [09:59] (another point is that this program should be banned) [09:59] adeuring: That is not a feature. [09:59] Heh, yes. [09:59] lol [09:59] wgrant: I agree completely ;) [10:01] maxb: Ah, so the mailman timeouts are normal? I presumed they were from being asleep for hours. [10:03] well, I'm going by Barry's comment on the wiki page that there are spurious failures if you run those tests not individually [10:03] I ran the ones that failed individually and they passed [10:04] adeuring, intellectronica: Also, there is one other Bugs failure that I haven't got to the bottom of yet. Do you have any ideas about test_bug_496988 on https://dev.launchpad.net/PythonMigrationStatus? [10:06] hmmmm ... it's worth asking allenap and gmb about this one, they might have an idea [10:06] * gmb looks [10:06] gmb, intellectronica: Thanks. [10:07] maybe the result is that we have to doctor the headers to satisfy the new version of xmlrpclib [10:07] intellectronica, wgrant: Yeah, I think that might well be the case. [10:10] intellectronica, gmb: Any specific hints, or shall I go digging? [10:13] wgrant, If you give me five minutes I'll have a look at the test. I suspect that some of our testing infrastructure for the XML-RPC tests, which is mostly a looks-like-xmlrpc-but-isn't object isn't playing nice. [10:13] intellectronica: can i remember why what was done? [10:15] Okay, something weird's going on... [10:16] BjornT: why we had a test for the broken behaviour where a filename specified in the content-type header of a mail is ignored. but unless something comes to mind don't worry about it, i think wgrant has a reasonable fix, now that the behaviour of email parsing was fixed in python2.6 [10:17] Oh, the test's moved. that's why I couldn't find it. [10:17] gmb: Yeah, it took me a while too. [10:18] See, this is why we should never, ever refactor things and just keep the whole of LP in launchpad.py [10:19] OH DEAR GOD. [10:19] Oh dear god? [10:20] wgrant, Badly-written test. [10:20] gmb: So it *wasn't* just me. [10:20] But, might be indicative of issues we'll ahve in the future when we switch to 2.6 with doing XML-RPC queries to remote trackers; I don't know. [10:20] wgrant, nope. [10:20] wgrant, that test actually tries to contact the gnome bugzilla. [10:21] gmb: Oh yes, I noticed that when I tried to run it on the train. [10:21] It was not happy. [10:21] intellectronica: no, i can't remember why. it seems like an odd test. [10:21] wgrant, I think I wrote it, and once I've worked out how to fix it I'll throw myself on my sword. [10:21] * gmb makes a note: buy a sword [10:21] Heh. [10:22] Apr 15 14:48:12 2010 (31672) Received these actions: create [10:22] Apr 15 14:48:12 2010 (31672) List creation error for team: itest-one [10:22] Apr 15 14:48:12 2010 (31672) An error occurred; the list was not created: itest-one [10:22] Thankyou, mailman, for your descriptive errors. === daniloff is now known as danilos [10:30] wgrant, Actually, it's not all that bad, because I *think* it might show that we'll have a problem with XML-RPC and bugtrackers when we move to 2.6. [10:31] wgrant, Is there any tool which using launchpad API? like bzr-eclipse, tarmac, apport, ubuntu-dev-tools, and ilaunchpad-shell [10:32] wgrant, So, one way to fix it is to monkeypatch lp.bugs.externalbugtracker.get_external_bugtracker to return a Bugzilla instance that doesn't try to connect out. See test_updater.py:131 for an example of us doing this. [10:34] wgrant, in this case we want a get_external_bugtracker that returns a subclass of lp.bugs.externalbugtracker.bugzilla.BugzillaAPI whose getExternalBugTrackerToUse() method just returns self rather than contacting the remote server. I *think* that should do the trick. [10:34] dhastha: What do you mean? Aren't those all tools that use it? [10:37] wgrant, sorry. I have to know, is there any application using launchpad api? [10:41] dhastha: All those examples you gave above do, don't they? [10:47] maxb: Um, I'm not sure those two mailman tests even pass in 2.5. [10:47] I get the same errors there. [10:47] wgrant: bzr-eclipse, tarmac don't [10:47] wgrant: last I heard, anyhow. [10:48] (yay for tests that are not run by default?) [10:48] lifeless: Hm, I'm pretty sure tarmac does. [10:49] oh, perhaps I mean 'doesn't use my pet feature' [10:49] lifeless: Merge queues that weren't meant to be exposed? :P [10:50] wgrant: meh, they are meant to be according to thumper [10:50] just not finished [11:03] Morning, all. [11:10] apt-get dist-upgrade on lucid this morning wants to remove launchpad-developer-dependencies :/ [11:19] ah, python-apt got bumped in lucid [11:27] what would cause [11:27] raise HTTPError(response, content) [11:27] lazr.restfulclient.errors.HTTPError: HTTP Error 414: Request-URI Too Large [11:27] That's a new one. [11:27] I'm trying to lookup 126 branches by url at once [11:28] Ah. [11:28] squid allows several mb of URI IIRC [11:28] * lifeless bugifies [11:28] launchpadlib, you think? [11:28] That looks like a server-side error to me. [11:29] bigjools: so it did. uploading.... [11:29] I have this down to executing 'lpnochange python-apt' now :-) [11:30] maxb: :) thanks [11:30] maxb: Those two mailman failures are indeed legit bugs in 2.5 as well. I'm fixing them now. [11:31] I have bigger issues, like the upgrader deciding not to install latest versions of some packages ... [11:31] bigjools: ! [11:31] bigjools: That's normal if there's arch skew. [11:31] And when the build farm breaks, there will be arch skew. [11:31] that's probably what it was [11:31] I need to install the task for the -desktop package [11:32]