[04:59] <wgrant> blr: How's it looking?
[10:00] <wgrant> cjwatson: Did you work out your team mail stuff?
[10:09] <cjwatson> wgrant: No serious blockers but I got distracted by landing all the things yesterday.
[10:22] <cjwatson> Hm.  I just found RecipeBuildBehaviour._extraBuildArgs and config.builddmaster.bzr_builder_sources_list.  I wonder if I should replace my tools_archive stuff with that?
[10:22] <wgrant> Oh, I thought that had been removed.
[10:22] <wgrant> Oops.
[10:22] <wgrant> We haven't used it in years.
[10:23] <cjwatson> tools_archive is in one way a bit more elegant, but it doesn't support specifying a different series, nor does it support specifying a sources.list somewhere that isn't the same LP instance.
[10:23] <cjwatson> I assumed it had been removed ages ago and hadn't even looked; I only ran across it by accident
[10:26] <cjwatson> I'm inclined to push the bzr_builder_sources_list stuff down to get_sources_list_for_building and remove tools_archive.  It's basically the same as the deprecated OEM external dependencies stuff.
[10:27] <cjwatson> Except per-build-behaviour rather than per-archive.
[10:27] <wgrant> Right, sounds reasonable to me.
[10:27] <wgrant> Sorry, I hadn't realised it was still around.
[10:27] <cjwatson> NP
[10:28] <cjwatson> RecipeBuildBehaviour puts it after the primary archive in sources.list, but I think just before (as tools_archive) is conceptually slightly better.
[10:28] <wgrant> Agreed.
[10:29] <cjwatson> Little difference in practice unless the same version ends up in the primary archive.
[10:30] <wgrant> One day I am going to hack Zope to allow deep views.
[10:30] <wgrant> +webhooks, +webhook/foo, +new-webhook
[10:30] <wgrant> Madness
[10:57] <cjwatson> wgrant: Your celery tests seem very unreliable in buildbot ...
[10:58] <wgrant> cjwatson: Yes, I've relaxed the two unreliable ones in my latest branch.
[10:58] <wgrant> buildbot really can be very slow at running code :(
[11:35] <cjwatson> wgrant: Were you thinking that I should have a straight-through test that there's failure-counting if the snap source has been deleted, or is it enough to trust the general scan/scanFailed behaviour of builddmaster and check for the AssertionError on dispatch?
[11:36] <wgrant> cjwatson: I think the latter is fine.
[11:36] <wgrant> buildd-manager tests are awkward, and that behaviour is already reasonably well tested.
[11:38] <cjwatson> Good, that's what I thought/hoped.
[11:38] <wgrant> I'm not that cruel.
[11:41] <cjwatson> Oh, fixing this will imply making branch/repository deletion hook into snaps, though.  Which was on my to-do, just a bit further down.
[11:41] <cjwatson> I guess it's not hard.
[11:42] <wgrant> Ah, fair.
[11:42] <wgrant> It's not a blocker for landing the branch.
[11:42] <wgrant> But I'd quite like to have some assertion that the behaviour is sane so when we rework something in three years we don't burn alphecca down.
[11:48] <cjwatson> I think I'll just propose a separate branch first to fix deletion.  Easier that way round than some kind of weird assertion about what happens if a reference points into the void ...
[11:49] <wgrant> Yep