=== heroux_ is now known as heroux === danilos` is now known as danilos [10:18] The review queue is getting rather backed up ... [10:33] Hm, just the one from Thursday and five from Friday, or am I missing some? [10:40] Those, I think. [10:41] Oh, and ~cjwatson/turnip/merge-prerequisite, and a recheck of my recent changes to ~cjwatson/launchpad/team-mail would be good since those introduce async jobs. [10:41] Ah, I see, will do. [10:41] Ta. I'm about to tackle the immediate mail delivery thing in zopeless, at least moving things along a bit. [10:42] Hm, which thing is that? [10:42] https://bugs.launchpad.net/launchpad/+bug/29744 [10:42] Bug #29744: In Zopeless, mails should be sent only when the transaction is commited

[10:42] That's a huge amount of trouble. [10:42] Due to archiveuploader relying on them being sent on abort [10:42] Not terrible to at least make it more opt-in. [10:42] IIRC [10:42] True. [10:42] I've almost fixed archiveuploader. [10:43] Ooh [10:43] But the first step is to make it easier for archiveuploader to opt-in selectively. [10:43] Actually the first first step is to convert more stuff to pop_notifications, because otherwise there's a pattern that's rather too easy to fit where you do self.assertEqual([], stub.test_emails) without committing first, and moving away from immediate delivery makes that kind of test silently ineffective. [10:44] I have a fully passing test suite (with the exception of some unrelated buildmaster cruft) with immediate delivery disabled in zopeless in general but enabled in BaseMailer and a few other places. [10:46] The reason I care is that otherwise converting the world of mail notifications to zopeless (so that we don't have to care about having an actor who might not be allowed to know about some subscribers) might be a rather more exciting stealth change than it ought t obe. [10:47] I'm not too concerned about that. [10:47] It is a slight issue, but not very large. [10:47] As the main thing that can fail is operation itself, not the email transmission. [10:47] Good to fix, anyway. [10:47] archiveuploader is relatively easy now that most of the code is in PackageUploadMailer. The fix is to use the mailer directly rather than relying on going through PackageUpload.notify; then it doesn't have to abort in order to get rid of the temporary PU object, and can just do abort; send mail; commit [10:48] Requires pushing a couple of extra bits of logic down into the mailer to avoid duplication, but not very much. [10:48] Yep [10:49] And that self.queue_root.notify business in archiveuploader was something I always hated. [10:54] Ha, I found something that was still depending on the "debian" alias for binarypackage! [10:55] I believe it works due to a very old launchpad-buildd on the buildbot slaves. [10:56] Yep. But they have at least 121 per my IRC logs, so we can use the new forms. [10:57] I'll get a clean bin/test locally yet. [10:57] Oh, I didn't realise they were that new. Handy. [11:03] Hmm [11:03] We should really stop catching IntegrityError in places. [11:04] aaaa [11:04] Only Packageset, Snap and LiveFS do it still. [11:04] What triggered the IPv6 alarm? [11:04] Oh, yeah, I forget why I couldn't think of a better way to do that [11:04] Just fear at what else that could hide [11:04] It just had me running in circles for a bit. [11:04] Though it is indeed my fault in this case [11:05] Chasing down why a snap got created despite the feature flag being disabled and causing a 401. [11:05] Of course it was actually lying when it said one existed -- instead, git_path was null. [11:05] The correct thing to do in this situation is LBYL [11:05] I was about to say exactly that! [11:05] We're raising a specific error so should check for a specific condition. [11:05] Yep [11:06] I think you actually copied that originally from a place that I fixed reasonably recently... [11:06] Almost certainly. [11:06] Yay clean buildmaster tests [11:07] Marvellous. [11:07] I believe that's an entirely clean bin/test for me locally now, with the codeimport fixes. I ran the whole thing at the weekend to see what exploded without immediate delivery. [11:08] 3.5 hours [11:08] Ah, that's right, LibraryFileAlias.create said a filename contained illegal characters whenever there was an IntegrityError. [11:08] Not quite the same, but close. [11:09] Yep, even Haswell-U is pretty snappy at running the test suite nowadays. [19:23] cjwatson: 3.5 *hours* ? [19:58] lifeless: In which direction is that surprising? :) [20:04] cjwatson: seems slow - I recall running it locally in ~90m ? [20:04] cjwatson: (with parallel of course) [20:04] lifeless: This is just serially [20:05] No particular effort to make them go faster, I was doing housework for those 3.5 hours :-) I very rarely run the whole thing locally, this is the first time it's been necessary for me in eight months full-time on LP [20:05] If I did it more often I expect I'd bother setting up the parallel harness stuff [20:06] cjwatson: ah. Fair enough ... the parallel setup is pretty easy, and it helps even with running subsets [20:06] It's probably worth an hour of effort at some point [20:07] Effort in that direction would be more appealingly spent on being able to run tests on more than one branch at once, mind you (though I suppose it involves some of the same work) [20:08] huh, what stops you running on more than one branch? [20:08] presumably the only thing is the template db [20:08] and thats (IIRC) controllable via an env variable. [20:09] Never having bothered to work out the details :-) [20:09] There are various specific tests that are singleton in odd ways [20:09] Like starting up servers on hardcoded port numbers [20:10] pretty sure all the fixtures report back the port number [20:10] if not, I think thats likely a regression [20:10] Pretty sure not everything uses them right [20:10] entirely possible :) [20:10] anyhow, yes the work doth likely overlap [20:10] but - the container approach gives you entire isolation anyhow [20:10] Like the buildmaster integration tests have AIUI never done dynamic port selection [20:11] So a few tests fail obscurely if you happen to have a real buildd running in the same environment [20:11] so if you have parallel, you have multibranch with at most trivial glue [20:11] Yeah. One of these days ... [20:14] indeed http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/buildmaster/tests/harness.py [20:14] is missing port randomisation [20:15] there's glue for that elsewhere in the three. TUITs huh [20:16] There's lib/lp/services/librarianserver/testing/server.py [20:17] I think that's the only bit of .tac glue that does it [20:17] log parsing, nasty [20:18] yes [20:18] well [20:19] its better than the race of the 'find a port in parent and say 'use port X' on the command line [20:19] an actual fd handover would arguably be better [20:19] log parsing is at least race free [20:19] Yeah [20:20] Would want to try to push that down a level if using that from more places [23:46] lifeless: There are heaps of things that were never isolated [23:46] That's why the container approach was used,. [23:47] eg. AppserverLayer even conflicts with the dev appserver.