[09:25] as handy as it is, the weird string concatination 'feature' of python catches me out more often than not [11:11] https://code.launchpad.net/~twom/launchpad-buildd/include-base-in-digests/+merge/383584 extract the base from OCI images. [14:58] tomwardill: Could you have a look at https://code.launchpad.net/~cjwatson/launchpad-buildd/+git/launchpad-buildd/+merge/383594 ? It sort of partially reverts one of your OCI-related changes from a while back, which I think doesn't cause any problems there but you should probably have a look [14:59] yep, looking [15:01] `CarefulFakeProcessFixture` [15:01] this is a good name [15:20] :) [15:49] cjwatson, pappacena: Tidied up https://code.launchpad.net/~twom/launchpad-buildd/include-base-in-digests/+merge/383584 and found some other bits that were doing silly things with exceptions, if you could check it over again [16:04] tomwardill: re-reviewed [16:04] ta [16:05] cjwatson: the KeyError is actually the same cause as the LXDException [16:05] it's the error the FackBackend raises on a missing file [16:05] Oh right [16:06] Still, my point was that the exceptions raised by copy_out vs. the exceptions raised by everything else are logically different [16:06] yeah, fair, that block should be shorter [16:12] all fixed [16:27] just going to share things here, but RE: DMARC compliance I'm still going to iron out the kinks locally once LP catches up to what I'm after (a branch in my userspace for the LP code) but it looks like DMARC compliance for bug mails might be easier to implement than previously thought heh. fixing up the tests will be the next Big Problem for that but from the functionality perspective it shouldn't be too hard. [16:27] thank you cjwatson for pointers at where to look in the codebase [16:27] once i get that working you'll all ahve a merge to review for those changes :) [16:28] Trying to work out why your fork is timing out - LP has four refs so it really shouldn't be an issue [16:28] Guess I'll try repacking the repository [16:29] cjwatson: unless something else is going wonky? [16:29] No, it's clearly an API timeout on the repository create call [16:40] cool. more work for you then cjwatson xD :P [16:42] teward: Can you retry your push now? [16:42] 1 moment [16:42] didn't time out and is 'writing objects' right now [16:42] (*waits for the eternity to pass*) [20:25] i'm assuming that the dev launchpad env attempts to use localhost:25 for email sending? [20:25] (just checking) [21:29] teward: An improperly configured Launchpad instance could very easily spam a whole bunch of innocent people, so by default it's either configured not to send email at all or to drop them into an mbox somewhere, I forget which. See doc/email.txt [21:30] Yep. I also configure a postfix locally that literally just delivers to an mbox xD So far though i caught two things that needed altered in the tests :P [21:33] You also werent lying the test suite takes an eternity to run [21:33] teward: To give you an idea, the dogfood instance has a mail-configure-normal.zcml that looks like https://paste.ubuntu.com/p/dq5P36X95D/, which just drops everything into an mbox [21:33] You probably don't want to run the entire test suite. [21:34] lp.bugs should be enough - maybe lp.coop.answersbugs too, though it's tiny. [21:34] running the bugs testsuite with the command you stated in #launchpad earlier. Which is fine 'cause I want to make sure that works :) [21:34] yeah i am running lp.bugs :) [21:34] The whole thing takes six hours on my laptop. Fortunately most changes don't require running it all [21:37] indeed. but because I want to make sure nothing with my minor changes in the LP codebase explode all of bugs I"m running lp.bugs entirely. Found a docs discrepancy too because of the email From generations being different, that was an easy thing to fix, but i'm waiting to see what else triggers [21:37] 'course APache just exploded but that i think might've been my fault (oops) [21:37] (like literally seized up the container) [21:38] i only can blame myself there :) [22:14] cjwatson: i think one of the tests is just 'busted' to some extent [22:15] but it might be on my end... *retests with a clean setup* [23:02] teward: We have some flaky tests, but they do all pass [23:02] On a correct setup [23:03] And most of the flakiness doesn't manifest when you're just running the tests serially locally rather than in more complicated parallel setups [23:25] the flakiness i'm seeing is in... lib/lp/bugs/doc/bugnotification-sending.txt [23:26] where Subject lines with ... fail because it's got an actual numeric in there [23:26] ellipsized text not matching [23:26] similar for link behavior [23:26] and the From addresses but it *seems* to be more a case of the docs not matching the expected outputs (hence failures) [23:26] i'm quadruple tasking at the moment heh [23:27] let me run a 'pure' test with LP pure just to make sure this isn't my code changes causing the errors (if it reproduces in clean master I'm assuming the issue is due to flakyTest) [23:29] That test is not known to be flaky, and it's not of the kind that is likely to be flaky. [23:29] wgrant: true, but i'm curious why it's triggering here but not elsewhere hence testing a clean deploy atm [23:30] to rule out my changes (which were only to the from address generator) as the cause [23:30] (i'm testing local heh) [23:33] wgrant: the *expected* failures with those changes are, as I stated, expected, but the specific ones that *aren't* expected are with handling of the Subject line matches [23:35] let me get the traceback into a file that I can share (and then delete after) [23:46] Beware that doctest mismatch output can be extremely confusing and can suggest mismatches that don't exist if you aren't completely sure of how to read them [23:46] cjwatson: yeah those're the tests that failed. This said, those're the only failures in the entire bugs test suite [23:46] (with my changes). Trying to get full output but E:SLOW