[00:06] <__monty__> Mmm, socket.error is a child class of IOError, so should the test for socket.error happen before the test for IOError? [00:10] i wonder why it isn't being handled by the existing code that tries to treat IOError as a user error? [00:10] in python 2.6 and later. [00:11] hi mgz [00:11] ah, perfect [00:11] <__monty__> Ah, yes the user was using 2.5 [00:11] in that case you could just list it in the same exception clause, and perhaps add a comment why it's being caught separately [00:12] <__monty__> What do you mean by listing it in the same exception clause? [00:14] having it before with a special note about connectivity would also be reasonable [00:17] i meant having (OSError, IOError, socket.error) [00:17] you should also add a test [00:17] i think this is pretty well covered in test_trace so you can go from those examples [00:19] <__monty__> What would be the best solution, testing it first with a specific message about connectivity or making the message for IOError more general and including OSError and socket.error? [00:22] can you explain the second alternative more? [00:22] <__monty__> The second alternative is what I understood you were proposing. [00:23] add a test that raises socket.errer [00:23] *error [00:23] check it does not print a traceback [00:24] the easiest way to make this test pass is probably to just also catch that exception in the same way as for IOError [00:24] hm [00:24] actually, on trunk, since we need py2.6 now, this bug may be obsolete [00:24] you could just interactively test that it works [00:25] <__monty__> How exactly do I test it? How do I try to get a socket.error? [00:25] look at eg test_format_io_error [00:26] probably a good way to get a realistic one is to try to connect to some unlikely port on localhost [00:26] like tcp port 2 [00:29] it's safe to just construct your own socket.error [00:29] it is [00:30] <__monty__> Yes, but how? [00:30] i feel if you do it yourself, you may miss quirks in how python constructs them [00:30] for instance there have been some bugs along the lines of actual python not setting named attributes on errors the way we expected, iirc [00:30] so if it's easy i'd lean towards generating a real owne [00:30] *one [00:32] <__monty__> I should write a new method in test_trace.py to test if this is no longer a problem in python 2.6, right? [00:32] yes [00:33] so, for instance, in bzrlib.tests.test_trace use test_format_pywintypes_error as a template but raise a likely looking socket.error instead [00:33] ...and I note there I did do what poolie said rather than what I suggested [00:33] in that I called a function that will raise a real error rather than constructing my own [00:35] this will probably cover bug 598158 [00:35] Launchpad bug 598158 in Bazaar "Socket is closed errors are not caught/wrapped." [Medium,Confirmed] https://launchpad.net/bugs/598158 [00:35] well, it's probably a dupe [00:36] in fact both are probably dupes of bug 393173 [00:36] Launchpad bug 393173 in amarok (Ubuntu) "Amarok does not transfer album art to iPod (dup-of: 260091)" [Undecided,New] https://launchpad.net/bugs/393173 [00:36] Launchpad bug 260091 in amarok (Ubuntu) "Amarok does not correctly re-format cover art when transferring to Ipod" [Undecided,Won't fix] https://launchpad.net/bugs/260091 [00:38] sorry bug 393713 [00:38] Launchpad bug 393713 in Bazaar "[master] socket.error causes a traceback" [Medium,Confirmed] https://launchpad.net/bugs/393713 [00:39] some socket errors are deeply unhelpful so some extra text in the advice param is probably a good idea [00:41] <__monty__> As extra text just point to bzr.log or something more helpful? [00:41] socket.socket(0) gives me a nice fast error, but that's probably a bad idea [00:41] depends if the constants are standardised at all I guess [00:42] i think there probably the thing is to catch them close to the point they're raised and rethrow something more meaningful [00:42] like try: socketblah: except socket.error: [00:42] raise something("failed to connect to smtp server %s:%d: %s" % (host, port, e)) [00:44] ehehe, funny mail from jam about the 2.4b3 release [00:44] :) [00:44] that was such a fun sprint [00:46] <__monty__> So, the error should be caught before we have to handle it in trace.py? Or did you mean something else poolie? [00:46] poolie, I've got half a thing written trying to convey that sense of fun, if I mail it to you will you proof read? [00:46] sure [00:46] i'd kind of like to consciously understand what we (or i) did right [00:46] to reproduce it [00:47] it seemed like there was just enough focus on having a hit list, but it wasn't overstructured [00:54] <__monty__> How does the test method work, I make sure an error is raised in the try block, then 'pass' the except block, then 'msg = _format_exception()', then self.assertContainsRe(msg, r"The string for the error here")? [00:57] that sounds right [00:58] <__monty__> Still how do I raise a socket.error that's realistic? [00:59] like mgz said just a socket.socket(0) could be a good start [00:59] __monty__: hmm, perhaps try to call sock.accept without first calling sock.listen? [00:59] o/ spiv [00:59] or socket.socket() then socket.send("something") yells at you for not being connected [01:00] really realistic ones like timeouts are probably not something we want in the test suite :) [01:00] mgz's idea sounds good too. [01:00] Hi poolie [01:01] <__monty__> Which one of these is least likely not to fail? [01:02] they should all fail! :) [01:02] either of those last two should be reliable [01:02] if it turns out they're not we can fix it [01:05] <__monty__> What would the error string look like for the socket.socket() socket.send("string") scenario? [01:06] just try it :) [01:06] python -c "import socket; s = socket.socket(); s.send('string')" :) [01:10] <__monty__> Is this correct for the string? Are the backslashes necessary since it's a raw string? [01:12] <__monty__> r"^bzr: ERROR: \[Errno .*\] Socket is not connected" [01:15] the backslashes are needed if you're trying to match it as a regexp [01:16] <__monty__> so it's not really necessary in this case since the error will always be: socket.error: [Errno 57] Socket is not connected [01:17] i don't think it's guaranteed to be error 57 on all platforms [01:17] spiv could i mumble at you about bug 220464? [01:17] Launchpad bug 220464 in Bazaar "Bazaar doesn't detect its own stale locks" [High,In progress] https://launchpad.net/bugs/220464 [01:19] <__monty__> Then this is good? r"^bzr: ERROR: \[Errno .*\] Socket is not connected" [01:19] yup [01:19] does it pass? [01:19] try running ./bzr selftest -s bt.test_trace [01:20] <__monty__> I get this: bzr: ERROR: No module named testtools [01:20] <__monty__> You may need to install this Python library separately. [01:20] <__monty__> bzr: warning: some compiled extensions could not be loaded; see [01:20] yes, you'll need testtools to run the tests [01:21] on ubuntu or debian, apt-get install python-testtools [01:26] <__monty__> This is the output: [01:26] <__monty__> bzr selftest: /Users/toon/src/bzr/connection-timed-out-364462/bzr [01:26] <__monty__> /Users/toon/src/bzr/connection-timed-out-364462/bzrlib [01:26] <__monty__> bzr-2.4.0dev4 python-2.6.5 Darwin-9.8.0-i386-32bit [01:26] poolie: sure; via which medium? [01:26] <__monty__> ---------------------------------------------------------------------- [01:26] <__monty__> Ran 25 tests in 0.577s [01:26] <__monty__> OK [01:26] <__monty__> Missing feature 'meliae' skipped 1 tests. [01:26] <__monty__> Missing feature 'pywintypes' skipped 1 tests. [01:26] <__monty__> bzr: warning: some compiled extensions could not be loaded; see [01:27] <__monty__> Sorry for the excessive pasting. [01:28] rockin [01:28] spiv, here, or mumble, or the phone [01:28] mostly it's been a while since i touched it so i can't recall if i meant to do anything else before proposing it [01:29] actually if you could just review it now that would be nice [01:29] <__monty__> Should I submit the change now? [01:29] yes please [01:29] poolie: sure, already started reading [01:30] poolie: So far it looks very nice! [01:31] there's another thing connected but just out of scope [01:31] which is to do with trying to release locks as we terminate [01:31] and there was some discussion at the sprint [01:32] which leaned me a bit closer towards a crash-only design [01:32] iow better to just pretty much terminate when something unexpected happens and then pick up next time [01:38] __monty__: all ok? [01:39] <__monty__> Yes, I'm composing the cover letter(?) I should mention all three of the bugs right? [01:39] since they're all dupes only the master is enough [01:39] thanks for fixing thins! [01:39] *this [01:40] poolie: I've emailed you a thingy. [01:40] ta [01:41] that's really nice, thanks! [01:41] i didn't know about bialix's shirt [01:41] i don't have any particular corrections or suggestions [01:41] i'd like to put it on the blog too [01:42] which will make it easy to add links [01:42] do you have access? [01:43] not currently. [01:44] ok sent [01:47] <__monty__> Merge proposed. Thank you for all the help poolie, mgz. :) [01:48] thanks poolie, and thanks monty :) [01:48] np, thanks for your contribution [01:49] <__monty__> See you later! [01:51] okay, gzlist on wordpress is now me. [01:51] darn minimum four character username restrictions :) [01:56] mgz: your nick is too compressed :) [01:57] poolie: branch reviewed, very nice [02:06] thanks spiv [02:07] okay, I think the post should be in the review queue on the blog [02:07] feel free to edit or change if anyone spots something that could do with improving [02:14] mgz, it looks like it is published [02:14] "Someone even" in the second sentence a mistake? [02:15] *how [02:15] dammit, I thought I'd changed that :) [02:15] i published it [02:15] well spotted [02:15] you should still be able to edit it? [02:15] spiv interesting question about reraising incidental errors [02:16] hm [02:16] hm I don't see the edit button [02:20] i'll fix it [02:21] I've got some fixes for your lock breaking branch in return :) [02:22] :) [02:39] mgz are you going to comment on the mp - should i wait for you? [02:39] yes please. [02:39] will try and be fast. [02:40] np [02:40] just didn't want to stand around looking silly [02:48] okay, nearly there [02:49] I don't really need to implement this twice... [02:49] requiring 2.6 means has_ctypes should always be true [03:14] okay, tests pass [03:15] i wonder if i should change this to cast to unicode to get the human form, rather than to str [03:15] to make it safer for py3 and indeed also for unicode values [03:22] it's generally the right thing to do [03:23] but it's a little annoying in Python 2 because it can be dangerous to pass somethings unicode rather than str [03:23] it can break exceptions and such like [03:29] okay, posted branch poolie [03:29] thanks mgz [03:30] I'm a bit past a coherant review, hopefully the changes make sense, otherwise it'll have to wait till tomorrow :) [03:31] sure [03:31] i have some other things to fix in it anyhow [03:31] have a good night [03:31] I got a few of them in the branch I think. Night poolie! [07:02] woohoo, nice blog post mgz ! [07:52] it is isn't it [07:52] hi vila [07:53] i might call it a day though [07:53] poolie: heya [07:53] thanks for the release [07:53] vila i don't know if you saw the mail from https://bugs.launchpad.net/bzr-cvsps-import/+bug/788914 [07:53] Ubuntu bug 788914 in CVS to Bazaar importer "unexpected keyword argument 'pb'" [Critical,Confirmed] [07:53] but it would be nice to review and merge his patch [07:53] *yawn* [07:54] hmm, never touch this code so far :-/ [07:54] they should be shallow fixes [07:54] or maybe we can get lifeless to review them [07:55] anyhow i should really go [07:55] have a good day [07:55] will try to be online later next week [07:55] have a nice weekend [07:55] you too [08:02] vila: you might enjoy https://code.launchpad.net/~spiv/bzr/subprocess-log-in-test-details/+merge/62612 [08:03] It might help demystify some babune failures. [08:04] spiv: amazingly, I just found a trick to avoid the hangs... [08:04] Heh. [08:04] What's the trick? [08:04] redirecting *selftest* stderr at the invocation seems to be enough (how that's inherited is yet unclear, but probably works for all cases where we don't explicitly handle stderr) [08:05] so, what did I collect there ? [08:05] I'm glad you asked: http://paste.ubuntu.com/613637/ [08:06] *2* deprecation warnings... sound very small to block a pipe no ? [08:06] Well, depends on what the pipe's buffer size is [08:06] hmm, 277 chars... [08:06] awfully close to 256 :) [08:06] And how close we were to hitting the buffer limit without the extra noise :) [08:07] Yeah. [08:08] That worryingly suggests that jenkins or whatever is driving selftest in the slave isn't draining both stdout and stderr concurrently. [08:09] my head spins a bit trying to understand the ramifications... [08:09] dosen't clearly explain why your patch for osx/windows didn't work, I should retry that now [08:10] It also appears to disprove my optimism in saying “It's hopefully safe to assume that the terminal or whatever is draining both our stdout and stderr reliably!” :( [08:11] yup, that remark triggered my trick test [08:11] on the other hand, selftest is not supposed to output anything on stderr other than potential issues that needs to be addressed [08:11] does that sound correct ? [08:12] vila: well, deprecation warnings sound like fair game for stderr to me [08:12] yes, as things that should be addressed [08:12] And it's always possible to have lots of them [08:12] hmm [08:12] let me clarify [08:13] we seem to encounter various issues with anything that appears on stderr [08:13] And there's some value in testing that we work in environments that do emit deprecation warnings. [08:13] i.e. with older libraries [08:13] jenkins and subunit being brittle there [08:14] so diverting stderr at the top level and investigating issues found there separately may help us reach a more robust babune [08:15] And in extreme situations (i.e. sufficiently bad bugs) we might even get subprocesses exploding with tracebacks on stderr [08:15] I agree there is valuable information there, I don't mean to redirect to dev/null ! [08:15] Sure I didn't take it to mean that. [08:15] right, my guess is that this should trigger test failures nevertheless [08:15] I'm just saying we can't rely on driving stderr output in babune down to zero either [08:16] We have to be able to cope with it (even if we do manage to get it down to zero normally, bugs happen) [08:16] oh, right, may be not in the short term, but that's still a good target ;) [08:16] I don't feel especially at ease with this deprecation warnings [08:16] It's probably a good target, but we can't depend on it. :) [08:16] indeed [08:17] so 2>selftest.stderr and cat selftest.stderr may be a useful trick [08:17] In the extreme case imagine someone introduces a syntax error in lazy loaded code that is only hit by a test subprocess [08:17] vila: +1 [08:17] buildbot gets this right :/ [08:17] ? [08:18] oh, you mean by handling it by default ? [08:18] It reads stdout and stderr from the subprocess just fine (and even shows stderr in red in the default console output display) [08:18] Right [08:19] I can't believe (yet) the solution to so many babune problems could be that simple... [08:19] time for more coffee :) [08:19] hmm, by the way... [08:20] OMG ! [08:20] fullermd is not there ! [08:20] Hell must be frozen ! [08:21] ok, so plan: 1) more coffee, 2) look at spiv's stderr handling patch..... 4) profit ! [08:28] vila: given the state of http://webnumbr.com/.join%28bzr-active-reviews,bzr-pqm-queue-length,bzr-merged-reviews.derivative%29 you have quite a challenge as patch pilot today :) [08:29] Hangover from the sprint I guess! [08:29] well, I backuped jelmer so I have a bit of lag, but I'm also waiting for reviews for my own proposals... [08:30] may be I should just land them pretexting a user error while landing and approved one without realizing some pre-requisites weren't approved ;-D [08:47] spiv: still hanging on OSX :-/ [08:49] vila: :/ [08:49] vila: does subprocess-log-in-details help at all? [08:49] not tried that one yet [08:49] (Obviously it won't help the hang, but maybe it'll give better info if you interrupt the hang) [08:50] vila: I just did a couple of very quick reviews for you [08:50] And now I'm off! [08:50] great ! [08:50] have a nice week-end ! [08:50] Happy hacking, piloting, and babune-wrangling. [08:51] And have a nice weekend when you finally get there :) [09:21] Riddell: hello there ! [09:22] Riddell: I realized my comment on your https://code.launchpad.net/~jr/bzr/330063-merge-non-existing/+merge/61728 may need explanations about bb:tweak [09:22] Riddell: or do you understand the meaning already ? [09:22] it means tweaking the blackbox tests? [09:22] hehe no [09:23] BB == bundle buggy, that's what we used before reviews were available on lp [09:23] different votes were available there and we still miss the 'tweak' one on lp [09:23] ah [09:24] we use it to convey: your patch looks good, you can land it without an additional review as long as you agree with the modifications asked by the reviewer and implement them [09:24] but shorter ;) [09:25] since this doesn't exist on lp, we use an idiom which is: review: needsfixing, status: approved [09:26] Riddell: do you need further help with this proposal ? [09:26] hopefully not, I'll get to it shortly once I've looked at my e-mail (I was taking a swap day yesterday) [09:27] but I'll let you know if i do :) [09:27] Riddell: ok, cool, welcome back :) [10:43] vila: heh, TestImportTariffs.start_bzr_subprocess_with_import_check explicitly uses the real $HOME! [10:44] vila: so you could argue that including ~/.bzr.log in the details is therefore appropriate ;) [10:44] oh my, I routinely have Megs there ! [10:45] I just didn't look at the result of my first run even if it was limited to ~10 tests, imagine what it will contain for a whole test suite ! [10:46] vila: it's just TestImportTariffs [10:46] Megs * ~20.000, we will end up with GOs ! [10:46] ha right, still we will end up with gOs :) [10:47] It shouldn't be much: [10:47] * details are discarded for passing tests [10:47] * only TestImportTariffs uses start_bzr_subprocess with a real $HOME [10:47] Worth checking my assumptions are right, of course. [10:48] why not make them use a temp home then ? [10:48] But they should be ;) [10:48] “ # Normally we want test isolation from the real $HOME but here we [10:48] # explicitly do want to test against things installed there, therefore [10:48] # we pass it through. [10:48] ” [10:48] argh [10:48] i.e. test_import_tariffs wants to make use ~/.bazaar/plugins [10:48] There's probably a better way to do that [10:49] we rotate at 4M I think [10:49] Maybe set BZR_PLUGIN_PATH for the subprocess to explicitly be exactly what the parent uses [10:49] that's 2M of noise on average ;-/ [10:52] vila: should I be on the patch pilot schedule? [10:52] vila: I don't follow [10:52] vila: it only keeps the log contents if the test fails [10:53] vila: so normal cost: 0 [10:53] vila: no matter how large ~/.bzr.log is for that one test [10:53] Riddell: up to you, feeel free to insert yourself, probably at the end of the cycle so you get some time to accomodate [10:54] spiv: meh, maybe I misread your patch but I thought your were installing some automatic trigger for all subprocess calls ? [10:55] vila: for all start_bzr_subprocess calls [10:55] vila: but for all tests *except* TestImportTariff $HOME is some temporary directory [10:55] vila: and all in-process logging goes to an in-memory log during selftest [10:56] vila: so the only contents it will find are from test subprocesses, with the exception of TestImportTariff [10:56] (Ok, the doctests use real bzr $HOME too, but I don't think they use start_bzr_subprocess) [10:59] spiv: right, worth adding as comments then, I'll look into it again later (I thought I said that in the review no ?) [10:59] anyway, thanks for the explanations, will avoid useless roundtrips [11:00] vila: sure, just some drive by info as I was peeking at my mail :) [12:57] * Riddell blogs http://www.kdedevelopers.org/node/4435 [13:37] here's an odd question: is there anyways, from bzr command line, to "know" if someone has proposed a merge request? [13:37] Riddell: 1) Nice. 2) I'm confused by your user icon. 3) s/zx/xz/ [13:37] i have a private lp account, and I need to integrate it with some CI tools, and it requires me knowing merge requests. [13:37] Not via the bzr command line, no [13:38] damn. ok. [13:38] so i instead need to figure out some way of automating a browser request to the LP MR page. [13:38] which would normally be easy if it were public, but it's private. [13:38] maxb: the user icon comes from Umbrello which was my university project back in the day [13:39] Morbus: can't you use launchpad APIs? [13:39] Riddell: didn't even know LP had APIs :) [13:39] take a look at https://help.launchpad.net/API/launchpadlib [13:39] I'm not sure if merges have APIs, but they ought to if there's any justice in the world [13:40] heh, heh. [13:40] ask in #launchpad to find out [13:40] Morbus: You probably want to look at the Launchpad Web Services API, and in particular, if you use python and launchpadlib, lp.branches.getByUrl(url="lp:.......").getMergeProposals(...) [13:40] of course, i don't know any python, but i could figure it outl, I suspect. [13:40] maxb: thanks! [13:40] Riddell: you too :D [13:41] hrm. if it's just a webservice that seems to export JSON, I shouldn't have to use python lib... [13:42] Python is not the only integration possibility, but it is the one with the most advanced client libraries [13:42] sure. [13:42] i don't necessarily need a whole shebang - i /just/ need the list of branches that have a merge request in. [13:42] everything else i can handle from the command line locally. [13:43] Morbus: Try hitting this URL, then: https://api.launchpad.net/1.0/~bzr-pqm/bzr/bzr.dev?ws.op=getMergeProposals&status=Approved [13:44] maxb: right. i presume that's protected by the same cookie auth as a private project is? [13:44] cookie/session auth? [13:45] If it works, that's accidental. [13:45] how do you mean? [13:45] private thingies aren't supposed to be in the API? [13:45] The api.launchpad.net vhost is supposed to be accessed via OAuth tokens for authorization [13:46] ah. [13:46] does the pythonlib handle that too? [13:47] yes [13:47] Launchpad.login_with is the main entry point for authenticated access [13:48] hrm. i think i tweaked this wrong: https://api.launchpad.net/1.0/~morbusiff/examiner/trunk?ws.op=getMergeProposals&status=Approved [13:49] * maxb disappears for lunch, back ~15mins [13:49] * Morbus heads off to try the pythonlib. [13:56] or 5mins as the case may be [13:56] Morbus: Try hitting https://launchpad.net/api/1.0/~morbusiff/examiner/trunk?ws.op=getMergeProposals&status=Approved with your cookie [13:56] same error. [13:56] Object: , name: u'trunk' [13:57] Hm [13:57] No idea then, sorry [13:57] i woudln't worry too much about it now. got launchpadlib installed and i'm gonna fiddle with that for a bit. [13:57] Probably time to hop over to #launchpad for any further questions [13:58] <__monty__> If I want to rename a branch can I just rename the directory? [13:59] <__monty__> Or can I use bzr mv oldbranch/* newbranch/ ? [14:00] just rename the directory [14:00] <__monty__> ty === Ursinha is now known as Ursinha-afk [14:07] hrm. where does this launchpadlib store the OAuth details I'm abotu to put in? [14:08] the script will be running as a different (non-Unix) user than my current Unix user, so I don't want it to overwrite my own data. === Ursinha-afk is now known as Ursinha [14:09] wrong chan. [14:14] ug, I keep using the broken "s" for submit option on feed-pqm [14:14] lifeless: is it true you have a good reason for keeping that around? [14:17] Riddell: hehe, was just reading such emails :) [14:21] poolie: if you add me to ~hydrazine-core I'll set up daily builds so the packaging is no longer a year out of date [14:21] I might also get rid of the broken "s" option on feed-pqm while nobody is looking :) [14:27] Riddell: Propose a branch for merge, I run from sources ;) [15:27] Riddell: nope [15:27] * lifeless disappears [15:28] oh good [15:57] spiv: wake up ! wake up ! I have good news ! [16:03] spiv: what ? Not even 1AM and you're not there... Sheesh [16:04] For the rest of the crowd: one source of selftest hanging on babune shut got a head-shot, thanks to spiv ;) [16:04] For the rest of the crowd: one source of selftest hanging on babune just got a head-shot, thanks to spiv ;) [16:04] just not shut... tyops are back [16:05] I blame fullermd [16:05] it's generally his fault. [16:07] vila: can you run a branch of mine on one of your forking babune slaves? [16:07] I think I fixed the remaining pain, just want to double check before proposing [16:07] mgz: sure [16:08] which branch and which subset ? [16:08] lp:~gz/bzr/cleanup_testcases_by_collection_613247 as always hang fix before r [16:08] ...interesting edit [16:08] that branch, but merge in whatever you need to make a full run work too. [16:08] say that again ? [16:09] so, the import tariff hang fix if that was an issue on the slae [16:09] *slave [16:09] I'd prefer a significant subset, not *all* hangs are fixed, I have a couple of pretty good silver bullets now tough [16:09] * mgz blames vila's infectious typos [16:09] hehe [16:10] justasec, a couple of zombies to kill first [16:10] `-s bb. -s bt.test_` isn't bad, but I want a full run to compare resource usage really [16:11] I got it through a complete selftest on the laptop (after stopping X, had som OOMs trying to fork otherwise), so it should run inside 240MB or so [16:11] hmm, a full run will be more complex *right now*, let's try with the subset and ping me again if I forget the full one [16:11] okay [16:12] but how will you check resources usage on babune ? [16:12] but parallel=fork please, and optionally -Euncollected_cases [16:12] ^...it doesn't give metrics? er... speed I guess then. [16:12] hmm, you know what ? File a bug on lp against babune so I can better track that [16:13] yeah, speed could be a good indirect indicator [16:14] hmm, bt.test_ will include tariff, no good, can *you* merge lp:~vila/bzr/import-tariff-test-subprocess-deadlock instead ? [16:15] can we start with -s bb instead ? [16:15] okay, -s bb. then [16:15] or is it not good enough ? [16:15] that should be clean though. [16:16] mgz: http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/109/aggregatedTestReport/ [16:19] crap typo in the branch name ;) [16:21] ehhee [16:21] add -s bt.test_selftest to the subset if you've not restarted yet [16:21] that should give some output [16:22] I did, but it' soon enough to cancel [16:24] hmm, 3 slaves running concurrently, if bad things happen, don't take the blame... [16:24] ...or not too fast ;) [16:25] http://babune.ladeuil.net:24842/view/debug/job/selftest-subset-all/111/aggregatedTestReport/ [16:26] mgz: gentoo failures already available, shallow ? [16:26] hm, that's the hard test case. [16:27] mgz: same number on freebsd, karmic, osx (macadam is osx) [16:27] Oh, I didn't specify -Exxx [16:27] if that helps... [16:27] should work anyway, but those failures are from trying to exercise the parallel=fork code [16:28] which is... tricky [16:28] unexplored territory.. unfortunately [16:29] mgz: which makes me believe you're not splitting your proposal enough :-D [16:29] the code needs to work... [16:30] I can continue landing things that don't actually fix the issue for ever [16:30] but maybe I'll split fixing parallel=fork from the rest. [16:31] mgz: well, -Euncollected_cases as a first step would be good to start with no ? [16:31]