[00:03] wgrant: http://pastebin.ubuntu.com/5785377/ is the last failure, but the tests are very strange [00:05] StevenK: Which test is that? [00:06] lp.testing.tests.test_layers_functional.LaunchpadTestCase.testLibrarianWorking [00:06] But anyway, the problem is fairly clear [00:06] It expects an AttributeError or ComponentLookupError when the ZCA is not loaded [00:06] But now it gets a TypeError [00:54] StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1193157/+merge/170722 [00:57] wgrant: Looks good, r=me === tasdomas_afk is now known as tasdomas === jamesh_ is now known as jamesh [10:49] StevenK: Ooh, just noticed bug 1188034. Excellent. Do you have client code already or should I write one for ubuntu-archive-tools? [10:49] <_mup_> Bug #1188034: Should be possible to upload chroots over the API [10:49] (I'm happy to do so) [10:51] StevenK: Archive owner is an interesting choice for the permission. You didn't consider launchpad-buildd-admins instead, which I think was what infinity and I were expecting to use? [12:18] cjwatson: infinity requested archive owner [12:19] cjwatson: My client code was a horrible hack, so please write a better one [12:19] OK :) [12:19] Do we want an equivalent of 'manage-chroot.py remove'? [12:21] I think that's the only piece missing to be able to kill that script [12:23] BTW I have a test now that exercises the case of copies into private archives owned by private teams causing /builders to 403, so hope to be able to push up a branch fixing that soon [12:24] cjwatson: Hmmm [12:25] cjwatson: data=None, perhaps? I suspect it will need a small code change [12:27] It might be clearer as a separate method [12:27] Particularly since sha1sum is a weird thing to have to pass with None [12:27] But just for clarity in general [12:27] Hmmm, indeed [12:29] cjwatson: The QA with that method wasn't exactly smooth on qas, so I'd like to see a test against prod with someone who doesn't suffer from Australian internet [12:35] Maybe infinity fancies doing a chroot refresh [12:37] I'd rather something like hardy i386 or something known just in case it does go pear shaped, TBH, but your call === wedgwood_away is now known as wedgwood === tasdomas is now known as tasdomas_afk === tasdomas_afk is now known as tasdomas === tasdomas is now known as tasdomas_afk [17:19] EC2 gave a few errors for one of my recent branches, most of which I've fixed; they were unreliable tests rather than anything I'd caused, I think. I don't understand http://paste.ubuntu.com/5787381/ though - is that one that's known to be unreliable? === joeyfreenode is now known as joey === wedgwood is now known as wedgwood_away [23:52] cjwatson: Yeah, that one's known to be unreliable. [23:53] You might have also run into two ddeb failures that I think are arch-dependent but I haven't bothered to fix yet.