[12:05] benji, did you see william & my comments on https://bugs.launchpad.net/launchpad/+bug/996729 ? [12:05] <_mup_> Bug #996729: zope.testing --subunit allows bad output on stdout, which can break subunit processing and tests

< https://launchpad.net/bugs/996729 > [12:05] summary: we've got unknown and mysterious work to do [12:05] gary_poster: not yet; taking a look [12:06] "In a world, where unknown and mysterious work must be done..." [12:06] heh [12:08] bac benji frankban gmb call in 2 [12:08] ack [12:08] rt [12:10] bac benji frankban gmb https://plus.google.com/hangouts/_/5e18fb3d6f696ec0a22278e5d5f27e055d2f4ef4?authuser=1&hl=en-US [12:11] argh, conneciton errors... [12:22] https://bugs.launchpad.net/launchpad/+bug/996729 [12:22] <_mup_> Bug #996729: zope.testing --subunit allows bad output on stdout, which can break subunit processing and tests

< https://launchpad.net/bugs/996729 > [12:31] https://pastebin.canonical.com/67982/ [12:34] rejoining [12:43] * gmb lunches [12:43] so benji i've already "released" my changes on top of yours as p10. are you going to revert your change and make p11? [12:43] bac: sure [13:52] benji: please ping me when p11 is available [13:53] benji: or i can do it if you're busy [13:53] bac: that would be great, I'm neck deep in this at the moment [13:54] benji: okey doke [14:13] gary_poster: for my little plugin, should/could I use email@canonical and AGPL? [14:14] frankban, yeah, your canonical email would be good since it was slack time project. AGPL...shrug I guess that's the right thing to do, yes. Is it a problem? [14:16] No, I don't think. [14:22] cool [14:22] benji http://ec2-50-16-151-255.compute-1.amazonaws.com:8010/waterfall [14:36] benji: in the future would you do work on shared branches (like zope.testing) in dev branches so there is one checkin-per-revision bump? the reverse cherry pick worked fine but p9 spanned about 5 branch revisions. [14:37] bac: that's a good idea [14:39] gary_poster, i've made my changes and updated zope.testing. i'm going to do a full ec2 run to ensure the zope.testing drop doesn't munge anything. [14:40] great thanks bac. I suggest you further manually examine the results before you land [14:40] in particular, make sure test counts don't change [14:40] gary_poster: oh, ok. let me go kill that 'ec2 land' then [14:40] bac, I can run it on the 32 core machine if you'd like, in a bit [14:41] gary_poster: you may if you want. seems like overkill since we are going back to what should be a known version. my changes shouldn't cause any problems wrt test counts. [14:42] bac, neither should ours have :-P [14:42] true enough [14:50] benji, maybe you didn't commit the change to p6 to your branch? it isn't here [15:46] benji http://ec2-50-16-151-255.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/4/steps/shell_9/logs/subunit [16:02] benji http://pastebin.ubuntu.com/1039294/ [16:05] benji lp.testing.tests.test_zope_test_in_subprocess.TestZopeTestInSubProcessLayer [16:09] benji, gary_poster, Quick question: what would be the sanest way for zope.testing to issue a warning about duplicate tests? An exception is simple, but the bug talks about warning for now (and I don't want to break any more test runs just yet). [16:09] It would seem that writing to stdout or stderr would be a bad idea, especially if --subunit is switched on... Any ideas? [16:09] gmb, I'l be curious to see what benji thinks, but since bac has fixed the existing tests, I think it is OK to raise an (informative) error [16:10] gmb, IOW, there should be nothing to warn about at this time because bac has fixed it [16:10] So let's jump straight to the error [16:10] gary_poster, Something like ("Duplicate test id found: %s" % test.id)? Or are you thinking more info than that. [16:10] But okay, I'm happy to do that. [16:10] +1 [16:10] gmb, yeah, sounds like a good start :-) [16:10] Wahey. [16:11] Okay, branch coming shortly. [16:11] s/branch/mp [16:11] zt [16:11] Er. [16:11] Note to self: x-chat != vim [16:25] Ahaha. [16:25] Hmm. [16:25] So, my fix for bug 682711 breaks the test suite for zope.testing quite comprehensively. [16:25] Hmm. [16:31] benji https://bugs.launchpad.net/launchpad/+bug/986429 [16:31] <_mup_> Bug #986429: lp.testing.tests.test_zope_test_in_subprocess.TestZopeTestInSubProcess.test deposits global "zope:layer" tag in subunit stream

< https://launchpad.net/bugs/986429 > [16:33] Ah, wait, no it doesn't. My assumptions were broken. [16:47] gary_poster, So, interesting meta-problem: the tests for zope.testing contain a doctest called src/zope/testing/testrunner/testrunner-debugging-layer-setup.test, which writes a python file, then loads it and runs it. The file it writes out contains two layers and a function with a doctest, and when that doctest gets loaded, of course, it blows up because the doctest gets registered twice. Any ideas about how I should handle that? [17:25] gmb, sorry, was lunching [17:25] gmb, yeah i saw repetitive test ids in my change in the zope.testing tests. [17:26] gmb, make it a flag? [17:26] and then our bin test can always turn the flag on, he said, waving his hands? [17:43] benji https://plus.google.com/hangouts/_/afdae2431954bae99aae1d5075449031334b6481?authuser=1&hl=en-US when you are ready [17:57] gary_poster, Yeah, that sounds like the sanest solution. [17:57] cool [18:43] gary_poster: my branch has failed twice in ec2 with hung tests. [18:44] bac :-( [18:45] bac, you want me to run it in parallel machine for you? I could do it in about 40 minutes [18:45] sure [18:46] gary_poster: it is lp:~bac/launchpad/bug-682772 [18:46] bac ok will get it set up for you and ping you when done [18:46] gary_poster: do you mean you can get to it in 40 minutes or it will take 40 minutes? [18:47] bac, I meant #1 but I changed my mind. It will take 40 minutes [18:55] bac, fwiw it is running here if you want to follow along http://ec2-50-16-151-255.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/9 [18:56] bac, which tests hung, out of curiosity? [18:58] bac, it looks like list-tests is broken http://ec2-50-16-151-255.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/9/steps/shell_9/logs/stdio [18:59] * bac looks [19:00] gary_poster: where does that show brokenness? [19:00] bac, it is actually supposed to run tests after it runs --list-tests [19:00] bac, it didn't get any tests to run [19:00] gotcha [19:01] gary_poster: the two ec2 runs ended like http://paste.ubuntu.com/1039543/ [19:02] bac, that looks like it in includes an incomplete version of what benji used [19:03] bac, have you verified that what you have differs from the p6 version in only the way you expect? [19:03] in zope.testing [19:03] gary_poster: i have not done that. i examined the diff from the reverse cherry pick and it looked reasonable [19:04] bac, your p11 revert I think went wrong [19:04] understandably [19:04] since there were a number of commits [19:04] bac, I'm running p10 now [19:05] because we think we fixed our issue [19:05] and the fix was in Launchpad [19:05] bac, and it is working so far (http://ec2-50-16-151-255.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/10/steps/shell_9/logs/stdio fwiw) [19:05] gary_poster: do you see something fishy from p11? [19:05] or just that it broke the world? [19:05] bac, the result you just showed me from the pastebin looked exactly like ou had a naive version of the stdout replacement code [19:06] ok [19:06] ok, so just toss p11? [19:07] bac, benji, if build 10 (which uses p10) passes, yeah, I will be tempted to toss p11 [19:07] but i've got to the branch back to a good state [19:07] and revert the revert in zope.testing [19:07] yeah [19:07] forks are fun [19:07] IIRC it is bad form to uncommit and push, isn't it [19:08] I say, let's wait for this rest result [19:08] i think if you're guaranteed no one is working on the version you're wiping out it can be done [19:08] but probably better to avoid [19:08] I will be on team lead call by the time it finishes [19:08] but if it succeeds [19:08] then we land p10 [19:08] ok, well, i'll change my LP branch to use p10 and submit to ec2 [19:09] unless it looks like my change to zope testing broke --list [19:09] and we merge the reverse of the last two changes to zope.testing [19:09] bac, p10 --list works fine [19:09] oh, yay [19:09] I am pretty sure that this is, again, just the fact that you didn't revert completely back to p6 when you added your code in (which was very understandable) [19:11] well, i couldn't as it wasn't yet bad. [19:11] :-) [19:11] r 37 was a good check in [19:11] of my stuff [19:11] ack [19:12] so here's the pedantic question [19:12] if i revert the last change, do we change setup.py to call it p12? [19:12] so bac, benji...I have team lead call...bac, why don't you join us briefly in https://plus.google.com/hangouts/_/afdae2431954bae99aae1d5075449031334b6481?authuser=1&hl=en-US [19:12] otherwise it'll say p10 and the next guy will re-use p11 [19:37] bac, benji, yay, I think! [19:37] gary_poster, benji: http://paste.ubuntu.com/1039594/ [19:37] p10 nominally == p12 [19:38] bac, awesome [19:38] bac, benji we have a full, green test run http://ec2-50-16-151-255.compute-1.amazonaws.com:8010/waterfall [19:39] for julian: [19:39] bzr ci -m "Update zope.testing to p12 which reverts p11 to be the inaccurately maligned p10. Dont ask." [19:39] lol [19:44] bac or benji lemme know if I should re-run any of your branches [19:44] on the buildbot [19:45] gary_poster: ok, I think I'll be good [19:45] gary_poster: benji and i decided to let him pqm-submit his branch. i'll merge, update to use p12, and then get you to run it [19:45] great benji, bac [19:58] bac: any help using pqm-submit; I've only used it once or twice and it's been quite a while [19:58] this command line: bzr pqm-submit -m 'Use version p10 of our zope.testing fork for its redirection of non-subunit output away from stdout when --subunit is specified' lp:~/launchpad/bug-996729 [19:59] gives me this error: bzr: ERROR: There is no public branch set for "bzr+ssh://bazaar.launchpad.net/~benji/launchpad/bug-996729/". [19:59] benji: actually if you have a MP you can just use 'bzr lp-land' [19:59] bac: I do, but it's already been merged; is setting it back to approved kosher? [20:00] how about: bzr pqm-submit -m "[r=gary][bug=996729][no-qa] blah" [20:01] i don't need to specify the branch b/c i've got my .bazaar/locations.conf set up correctly. i recall you do not, right? [20:01] I guess not. Any refrence for setting it up? [20:04] benji: i'm looking [20:04] bac: I'm inclined to just make another MP (or reset the one I have) [20:06] benji: here is the relevant part of my .bazaar/locations.conf [20:06] http://paste.ubuntu.com/1039635/ [20:06] i'm sure it has some cruft in it due to the way things evolved [20:08] bac: it worked! [20:08] (hopefully PQM will actuall accept it) [20:08] whee ha [20:08] how did you make it this far in life without a locations.conf? [20:10] I have one but since I use a lpsetup-created setup now the paths were different, once fixed (plus another tweak) it worked [20:30] benji, looks like it hasn't landed yet? [20:30] gary_poster: hmm it should have [20:30] * benji looks [20:32] gary_poster: hmm, this doesn't look like my fault: "Conflicts during merge: Text conflict in lib/lp/soyuz/model/archive.py" [20:32] * benji looks at subsequent PQM emails. [20:32] benji, that's to dbdevel, I think you'll find [20:32] mmm [20:33] benji, we have two recent lands to devel, within the past 14 minutes [20:33] https://code.launchpad.net/~launchpad-pqm/launchpad/devel [20:33] ooh, it is [20:34] arg! Sender not authorised to commit to branch bzr+ssh://bazaar.launchpad.net/~benji/launchpad/devel [20:34] I hate PQM. [20:34] :-) [20:35] any idea how I'm supposed to make it think I'm authorized? [20:35] wait! that says ~benji [20:35] benji, look at that error message [20:35] right :-) [20:35] I hate PQM more now. [20:35] heh [20:37] is this what I need in my .bazzar/locations? [20:37] public_branch = bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel [20:37] submit_branch = bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel [20:38] eh, I don't use locations. I used the raw pqm options for awhile and now just use bzr lp-land when I need to do this sort of thing [20:38] I'll see if I can help... [20:39] benji, you want this kind of thing: [20:39] submit_branch = bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel [20:39] public_branch = bzr+ssh://bazaar.launchpad.net/~gary/launchpad [20:39] public_branch:policy = appendpath [20:39] push_location = lp:~gary/launchpad [20:39] push_location:policy = appendpath [20:39] s/gary/benji obv [20:41] * benji resubmits. [20:42] * benji watches https://pqm.launchpad.net/ while reciting the good luck charm of his people: "come on baby!" [20:46] that worked, benji, cool. [20:46] bac ^^ [20:47] yep, it looks good [20:47] ok [20:50] benji, you are sure about that logs dir removal? [20:50] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/15409 [20:52] gary_poster: can you run my branch through your parallel buildbot? lp:~bac/launchpad/bug-682772 [20:52] it has my changes, merged with the most recent trunk, using p12 [20:53] bac, sure [20:58] bac http://ec2-50-16-151-255.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/13fwiw [20:58] http://ec2-50-16-151-255.compute-1.amazonaws.com:8010/builders/lucid_lp/builds/13 that is [20:58] thanks [20:59] welcome [21:35] gary_poster: http://ec2-50-16-151-255.compute-1.amazonaws.com:8010/waterfall [21:35] Mr. Green Jeans [21:35] * bac -> lands [21:35] bac, yay!