[00:52] TODO: tonight when the moon is high in the sky, go and let loose a prolonged howl. think of igc. [00:59] heh [01:00] Morning. [01:01] hi spiv [01:10] poolie: Hi. Could I trouble you to add a new PPA under ~bzr called 'builddeps', to use as a container for common build-time-only dependencies for ~bzr/proposed, ~bzr/ppa, ~bzr-beta-ppa/ppa ? (Mainly debhelper for older distroseries) [01:10] +1 mneptok [01:10] sure [01:11] can you add that to the ppa.txt doc? [01:12] ah yes - will do [01:19] mneptok: +1 indeed [01:37] hmm. we really need --stacked-on= to support lp: urls [01:40] Hmm, I thought that there had been a patch towards that a while back... [01:40] maxb, done [01:41] thanks poolie [03:33] spm: bzr's pqm seems to be stuck? === r0bby_ is now known as robbyoconnor [03:55] spiv, yes, the job i sent up yesterday didn't seem to succeed or fail [03:55] spiv, did you ping anyone? [04:04] poolie: not apart from just then. [04:08] spm: could you help us with pqm? === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [05:32] http://blogs.gnome.org/mneptok/2010/09/01/ian-clatworthy-howl-a-thon/ [05:33] * mneptok smiles upwardly [05:34] Well, it's not yet midnight. I have strict rules about howling at the moon too early in the evening... but I'll definitely put it on the docket for later. [05:35] \o/ [05:35] AAAAAAAAAAAOOOOOOOOOOOOOOOOOOOOOO! [05:38] poolie: looking [05:41] poolie: spiv: https://pastebin.canonical.com/36543/ looks pretty stuck to me; shall I stab with a sharpened hammer, or did you want some debug first? [06:18] spm: I suppose it'd be interesting to know where exactly 24617 is stuck, although hopefully sending SIGINT to that process would make it exit with a relevant traceback. [06:18] spm: I'll be a lot more interested in debugging it if it recurs :) [06:19] heh, call it a one off and stab then? [06:20] Hmm, there's been a bit of flux in the test infrastructure lately (ironically to try reduce these sorts of issues), so I guess it's moderately likely to recur. [06:21] spm: how about just do a quick strace to see which syscall it's stuck in then kill it with SIGINT? [06:22] attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted <== sigh [06:24] Oh, joy. Possibly related to the strace subprocess left over from the test suite... [06:25] Or at least, I presume it's a left over and not used by the test in question... [06:25] that would make sense. I'll try killing that first; see if that frees things up at all [06:26] haha. that just fired off another strace [06:27] fwiw, stracing the strace gives: [06:27] strace -p 1816 [06:27] Process 1816 attached - interrupt to quit [06:27] wait4(4294967295, [06:27] [06:28] oki, killed 24617; things *seem* to be moving again [06:28] Wow, starting a new strace isn't what I would have guessed. [06:30] i tried it twice; same. so ... whee [06:30] and yup; things are definately moving again. [06:33] Well, I guess that means it was probably stuck in the strace tests, rather than where the http://pqm.bazaar-vcs.org/ suggested it was stuck. Hmm. [06:34] :< [06:39] spm: thanks [06:39] spiv: I'm quietly confidant that bzr blame will show it's your fault; no matter who really did the change that caused it. fwiw. :-P [07:28] lifeless: Hi. the debian/control Vcs-Bzr field of subunit points to a branch missing the last few uploads. Has it moved somewhere else? [07:28] i don't think so [07:28] what url are you seeing? [07:29] http://bzr.debian.org/collab-maint/subunit/unstable/ [07:29] if its bzr+ssh://bazaar.launchpad.net/~lifeless/debian/sid/subunit/sid I'm pushing against just in case [07:30] ahh, so the collab-maint branch is a red herring [07:32] Also, looks like you didn't 'bzr mark-uploaded' the last upload :-) [07:40] Is there a decent way to show the changes brought by the current commit? [07:40] magcius: bzr diff -c -1 [07:41] next question: is there any way to set it up so that if it's on a tty it uses a pager? [07:57] hi all ! [07:57] igc: good bye, AAAAAAAAAAAAAAAAAAOOOOOOOOOOOOOO ;-( [08:02] maxb: hmm, sorry. [08:02] maxb: I should probably do that [08:21] Hmm, the test suite seems to have slowed down quite a bit for me recently. [08:22] And as a bonus an https test seems to be tripping over http://bugs.python.org/issue9729 [08:23] spiv: yup, you can safely ignore the failure in that case, it's transient. I encounter it from time to time on babune. [08:23] Yeah, somehow my CPU cores now seem to be about 50% idle, so it's taking twice as long :( [08:24] spiv: your bug report is indeed pointing the problem, EBADF should be raised (and will be caught by the test suite) [08:24] spiv: I don't observer that *at all* if it helps [08:24] spiv: I don't observe that *at all* if it helps [08:24] spiv: is that for a full test run or a partial one ? [08:24] Yeah, the interaction between SSLSocket and _socketobject is clearly broken for those methods in that case once you know what to look for. [08:25] Full run. [08:25] The utilisation is varying, actually. [08:25] But there was definitely a point about midway through the run where it was literally 50-50, despite having one process per core. [08:26] hmm, see lp:~vila/bzr/626876-bzr-connect-to-bzr-ssh but it could only be relevant if you happened to run sftp tests at this precise point [08:27] And concretely it used to take just under 10 minutes to run the full no-plugins suite, now it's taking just over 20! [08:27] spiv: I meant, see the patch itself, we actually slow down sftp tests to cope with paramiko [08:28] spiv: doesn't match my experience nor babune ones [08:29] spiv: I'm still waiting a bit for more data to analyze but I even expect the leak fixes to *improve* the performances (if only because there are far less dangling threads and sockets for python to care about) [08:30] Well, 3000 tests sleeping for 0.2 seconds would equal 10 minutes. [08:31] spiv: I'd be glad to proven wrong though :) [08:31] spiv: well, one more reason to consider bug #626876 critical then :-D [08:31] Launchpad bug 626876 in Bazaar "tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh considered harmful (affected: 1, heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/626876 [08:31] vila: I'll trying commenting out that time.sleep and see what happens [08:31] * bialix waves hello [08:32] spiv: excellent ! [08:32] bialix: _0/ [08:32] vila: is that time.sleep there really there to make just one test pass? 10 minutes is huge cost to pay for that! [08:33] spiv: yes. [08:33] (And 25 minutes if you're going to increase it from 0.2 to 0.5!) [08:34] spiv: yes [08:34] Ok, so please please please find a way to apply that hack for just the duration of that one test if it has to stay. [08:34] spiv: jam even said that it needed to set it to 5.0s to make it pass on a heavily loaded windows machine [08:35] Well, basically time.sleep is never the right thing to do in an automated test suite. [08:35] spiv: I strongly prefer to get rid of it by rewriting that test as I complained about for months :-P Care to help ? [08:35] Because there's never a value where it will reliably cause the test to pass. [08:36] spiv: agreed, hence the FIXMEsssss [08:36] Hi bialix [08:36] Hi Gary [08:37] vila: incidentally, no ssl-related member_descriptor error on this run so far, but a EBADF traceback has leaking onto my stderr [08:37] spiv: speaking of timeouts, paramiko use a 0.1s timeout for every ssh socket (and an associated thread) [08:37] s/leaking/leaked/ [08:37] Oh, no, spoke too soon, there's the ssl bug again :) [08:38] vila: well, in my ideal universe, Twisted's SSH implementation would be more suitable for us which would avoid that sort of mess ;) [08:38] spiv: I expect a *few* and shallow fallouts from the leak fixes and babune confirms that so far [08:39] Ah, the EBADF is from a paramiko thread in fact. [08:39] :-D [08:39] which test ? [08:40] vila: don't know, it's a traceback from a thread [08:40] 'Thread-630' :P [08:40] spiv: but still... 20 minutes ? How many concurrent runs ? [08:40] ha, this one :) [08:41] But this run is so far looking to take roughly 20 min too :( [08:41] hello maxb, vila [08:41] --parallel=fork on a 4 core laptop. [08:41] spiv: so, regarding paramiko threads, one idea is to monkey patch the thread creation to inject ThreadWithException, but I haven't looked at the details yet [08:41] spiv: so concurrency == 8 or 4 ? [08:41] == 4 [08:42] hmm, weird, you do use tmpfs for /tmp right ? [08:42] I don't. (Although I've been meaning to play with that at some stage) [08:43] spiv: just try [08:43] spiv: most important optimization for selftest, ever [08:43] vila: Well, I'd really like to fix selftest to not hit the filesystem so much in the first place :) [08:44] spiv: sure, but I'm not holding my breath on that and using tmpfs in the mean time doesn't hurt and will even help getting there sooner :D [08:45] spiv: I don't hold my breath but I keep thinking about it though... [08:45] poolie: hey :) ;) :-| ;-/ AAAAAOOOO [08:46] i know :( [08:47] ok, with that last patch for gentoo, babune is back in blue except for the usual suspects and even that 's' may disappear soon (windows, I'm looking at you) [08:47] Ran 24311 tests in 4727.204s [08:47] FAILED (failures=1, errors=4) [08:47] Recording test results [08:47] ERROR: Failed to archive test reports [08:47] mgz: we're getting there... finally [08:48] spiv: still running without sleep ? [08:48] oh my, how will that be interpreted.... [08:49] GaryvdM: can you look at https://answers.launchpad.net/qbzr/+question/121019 please [08:50] * GaryvdM looks === bialix_ is now known as bialix [08:51] GaryvdM: I'm not sure how we're interacting with extmerge [08:51] bialix: http://paste.ubuntu.com/486635/ \o/ [08:52] vila: cool [08:52] sorry, today I'm not able to enjoy [08:52] bialix: and that's the real stuff running from bzr.dev [08:52] bialix: I know :-( [08:53] aaaoooooowww! [08:53] vila: That is great. [09:01] GaryvdM: so, regarding your qlog tests, you may simplify the expected data to make your tests more readable by using helpers like assertLogRevnos or assertLogRevnosAndDepths in bb.test_log [09:02] vila: oh wow [09:02] GaryvdM: the idea is that you don't always need to check all the details and using revids matching the revnos also simplify reading (come to think about it, I should even use raw ints and stringify them in the helper themselves) [09:02] vila: so it's because when I don't have my battery in my laptop the CPU is throttled to half speed! [09:02] spiv: LOL, thanks for that laugh :) [09:03] vila: note that I'm on AC power either way [09:03] * spiv boggles [09:04] spiv: what a trap :) [09:04] laptop want a battery, laptop want a battery ! [09:05] vila: I was quite busy last night, and wrote a assertComputedLines method. If the assertion fails, it shows the rendered graph as an ascii art. [09:06] If you put two batteries in it, does it go to double speed? [09:06] GaryvdM: I read something about that in the IRC logs but I haven't realized it was generated, great ! [09:06] vila: and I wrote a whole bunch of tests for existing bugs [09:06] 4 ! 8 ! Give it more batteries ! Tell Intel we've solved their problem with Moore's law ! [09:07] GaryvdM: Excellent ! Isn't it nice ? [09:09] Hmm. /sys/devices/system/cpu/cpu*/cpufreq/bios_limit drops when I remove the battery. [09:09] GaryvdM: meh, stringify won't work for dotted revnos, I'm an idiot :) [09:10] vila: http://pastebin.com/YdsrMyEw [09:11] GaryvdM: wow, amazing ! [09:11] Perhaps it's http://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling [09:13] * vila checks that virtual machines have a soldered battery.... [09:15] GaryvdM: So concretely, you may want to reduce ('rev-f', 3, None, [(0, 0, 0, True), (3, 1, 0, True), (3, 3, 3, True)]) to ('3', '3.1.0', '3.3.3') when applicable and use the full version only when needed [09:15] GaryvdM: or something [09:16] vila: If I could output unicode, I could make the graphs more readable, like this: http://pastebin.com/ZW7i4nZF [09:16] GaryvdM: but still, wow, I will certainly look at that the next time I play with ancestry graphs [09:16] WOW [09:17] GaryvdM: wow wow wow, you need to make this available outside of tests ! [09:18] vila: like a ncurses version of qlog? [09:19] GaryvdM: no, as a generic utility to visualize graphs [09:19] so we can use that when discussing, here, in mails, anywhere [09:21] hmm, I suspect it uses quite a lot of qlog code though... may be tricky to extract... but that will certainly make the qlog internal design clearer [09:22] GaryvdM: anyway, you may have better things to do right now but it may be worth considering as a long term goal... [09:35] i'm going to update and re-fire the strace things [09:35] hopefully not causing another hang [09:39] hm, i can imagine why that's hangign [09:39] but this is a kind of unprofitable mole to whack [09:42] Very interesting website igc had linked on his site: http://headrush.typepad.com/ [09:42] Aaaoooooowww [09:47] it is, though it came to an ugly end a few years ago [09:49] vila, i'm going to re [09:49] re-send the strace thing, with the tests disabled [09:49] which should not make pqm hang [09:49] but if it does, please just as a SA to kill it [09:51] poolie: ok, I'll keep an eye on it [10:56] Hello all. I want to push a branch to Launchpad that is stacked on another branch on Launchpad. I'm hitting some problems, however, as detailed at http://paste.pocoo.org/show/257054/. [10:58] Odd_Bloke: 1) I'm not sure you can do that on lp itself... 2) You got 2 different error messages for the same command ? [10:58] Odd_Bloke: hmm, that's odd. Try removing/renaming the branch through the web UI, and then try using the expanded bzr+ssh: URL with --stacked-on [10:59] vila: the first command created a bzrdir with a repo [10:59] ha! [10:59] Odd_Bloke: although [10:59] Odd_Bloke: why specify the stacked-on branch manually? [11:00] Odd_Bloke: LP should have that set up for you by default [11:01] Also, that first error is weird! [11:01] spiv: Ignorance. :) [11:01] So just 'bzr push lp:~username/projectname/branchname' should do stacking automagically? [11:02] yes [11:02] Ooh, shiny. [11:05] Odd_Bloke: well, assuming you have set a development focus for the project in Launchpad [11:05] Odd_Bloke: which I was assuming you had because you were trying lp:openerp-addons in your command, but actually I don't see that any such branch exists... [11:06] spiv: gee, I so mis-read the paste :-/ Anyway, does lp support stacking on a branch other than dev focus ? [11:06] Which may be related to the original failure [11:06] vila: yes (but may require some amount of prodding, I don't recall) [11:06] kthks [11:13] Right, poolie's strace patch landed === Ursinha-afk is now known as Ursinha [13:21] (jelmer) Add ControlDirFormat.supports_workingtrees cvar. (Jelmer Vernooij) is currently failing on pqm, let me know if you get the failure email from pqm [13:21] vila: Will do, thanks. [13:28] jelmer: I just had a look at revno 3464 in bzr-svn trunk, inheriting from LockableConfig is not enoug, you need a needs_write_lock decorator on set_user_option. Otherwise the way you ensure compatibility with older bzr releases is nicely short. === Ursinha is now known as Ursinha-afk [13:31] jelmer: something like http://paste.ubuntu.com/486734/ should be enoug (not tested) [13:31] urgh no, you need more :-/ [13:36] vila: http://babune.ladeuil.net:24842/job/selftest-windows/149/console <- looks good [13:36] I see bug 625574 and bug 273978 and bug 581311 and use of osutils.safe_unicode which should be called osutils.break_randomly [13:36] Launchpad bug 625574 in Bazaar "testtools details should not be shared between parameterised tests (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/625574 [13:36] Launchpad bug 273978 in Bazaar "UnicodeDecodeError when strerror is not ascii (affected: 1, heat: 4)" [Low,Confirmed] https://launchpad.net/bugs/273978 [13:36] Launchpad bug 581311 in Bazaar "bt.test_bundle.TestReadMergeableFromUrl.test_smart_server_connection_reset fails on windows (affected: 1, heat: 2)" [Medium,Confirmed] https://launchpad.net/bugs/581311 [13:36] mgz: yeah :) [13:37] I've got the first one, which will mean we get the pretty result display when you install a fixed pyjunitxml [13:37] mgz: err, I meant for the windows run, for safe_unicode, I'm a bit surprised [13:37] The second I'm going to get back to now I've fixed testtools so can actually test it without breaking the infrastructure === Ursinha-afk is now known as Ursinha [13:38] pyjunitxml, I had *that* installed ? Where ? 8-/ [13:38] safe_unicode tries decoding as utf-8, which means you can pass it arbitrary byte strings and it'll appear to work on nix nearly all the time [13:38] but actually the code could be totally bogus. [13:39] mgz: well, we should get rid of safe_unicode and safe_utf8 completely. AIUI, they help because we are not fully clear about which API expect one or the other [13:40] right. [13:40] they're little plasters over api mistakes. [13:41] all in all though, looks in pretty good shape, babune's closer to green than I am :) [13:42] blue blue ! Because he is frustrated to not be able to report failures, it turns red when it laugh at us :-D [13:43] but I don't seem to have python-junitxml installed... [13:44] you must have something, I see in the log your pipeline is: [13:44] Python 2.7.0+ [13:44] + ./bzr selftest -x TestBreakin --subunit [13:44] + subunit2junitxml -o tests.xml -f [13:44] + subunit2pyunit [13:44] it's the subunit2junitxml that's failing because of bad unicode/xml handling, and that code is in pyjunitxml [13:44] hmm, then I think it may be part of udson which is written in java, no python involved there [13:45] but but but! [13:45] http://bazaar.launchpad.net/~lifeless/pyjunitxml/trunk/revision/16 [13:45] meh, subunit2junitxml may be failing then, but it's part of subunit [13:45] 8-) [13:45] the last revision on the branch is an encoding change to fix a problem you reported! [13:45] so... you must have it :) [13:46] * vila asks his clones [13:47] oh ! right, got that on babune master, running from sources... wth [13:48] oh ! and also on slaves, running from sources too, geee [13:49] okay, so I'll give you a new branch to try later, should give us nice results for maverick and xp [13:49] Pfew, up-to-date with trunk so far. Pfew [13:49] mgz: yummy :) [13:50] first... lunch! [13:50] mgz: enjoy ! [13:58] re [13:59] vila: Yep, I did get the email. [13:59] vila: The testsuite was passing with current bzr-svn === zyga is now known as zyga-away [14:00] jelmer: yeah, current should be fine since there is no tests for "foreign" config files (they would be hard to define anyway), but that also means that the bzr-svn test suite didn't trigger the _write_config_file assertion about being locked (of course since you don't use it...) [14:01] jelmer: anyway, it means that your are not *yet* using a lock to protect your config file against concurrent write accesses [14:01] ahh, ok [14:02] jelmer: just a heads-up :) [14:02] vila: Thanks [14:02] I'll have a look tonight. [14:03] jelmer: I'm still interested by your feedback on the transition, I see you use _get_filename.... hehe, you redefine it :) [14:04] jelmer: anyway, if you think we should change something in bzr.dev to ease this transition, let me know === zyga-away is now known as zyga === oubiwann is now known as oubiwann-away === oubiwann-away is now known as ouibiwann === tchan1 is now known as tchan === Ursinha is now known as Ursinha-afk === ouibiwann is now known as oubiwann [15:35] GaryvdM: I should note your graphs don't line up correctly in unicode for me in Firefox [15:36] and they don't format at all in VIM [15:57] vila: ping about the connection code [15:57] I just noticed this line in the old "SocketListener" code that you removed: [15:58] - readable, writable_unused, exception_unused = \ [15:58] - select.select([self._socket], [], [], 0.1) [16:01] also, I noticed that 'self.serving' is just a boolean in TestingTCPServerMixin, and I've found that to get reliable start/stop you really need an event [16:12] vila: I tried changing 'serving' from being a boolean to being an Event, and once I do that, it fails regardless of the amount of time.sleep I have [16:13] I have the feeling that we *are* actually calling 'serving = False' at some point, but because the threads aren't always synchronized we don't see it sometimes [16:13] so the test accidentally passes [16:13] IOW, I think we are somehow asking the service to shut down early, but it just didn't know yet [16:14] ah wait, I have at least 1 boolean inverted, let me fix that first [16:14] jam: hmm, I seem to remember using an Event for self.serving before realizing it was useless, so I revert to a boolean, let me check [16:16] vila: I also see "TestingTCPServerMixin.server_bind" where it calls bind() but doesn't call .listen(1). Do you know where 'listen(1)' is occurring? [16:16] jam: yup, that was revno 5247.5.31 [16:16] jam: probably SocketServer.py [16:17] vila: you're right, there is a server_activate() function [16:17] jam: yup, in the implementation of server_activate [16:17] which is called by default at init time [16:18] though why do you override server_bind only to get rid of the 'setsockopt' option? [16:18] same for 'get_request', etc [16:18] jam: for compatibility with previous python versions IIRC [16:19] SO_RESUSEADDR is useless in our case and IIRC have different semantics between unix and windows [16:19] vila: I know there is a comment to that effect in places, at least [16:20] vila: so one interesting change. The default "listen(*)" amount is actually 5, and not 1 [16:21] and ? [16:27] vila: just an interesting difference === Ursinha-afk is now known as Ursinha [17:24] bzr lp-propose-merge suddenly stopped working for me: http://pastebin.ubuntu.com/486840/ [17:24] I'm not sure what is missing but should it not be a dependency handled by dpkg/apt? [17:25] zyga: try 'bzr -Derror lp-propose-merge' that should give a traceback [17:26] vila, http://pastebin.ubuntu.com/486842/ [17:27] zyga: that's from lazr imported from launchpadlib.... a bit surprising but I don't know launchpadlib enough to tell you more [17:28] vila, it's quite surprising as it was working just a few days ago [17:28] (apart form all the updates I got in between) [17:28] zyga: indeed [17:28] * zyga needs to reboot after kernel update [17:29] hmm, if python libs needs a reboot now... === beuno is now known as beuno-lunch === deryck is now known as deryck[lunch] === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck [18:56] vila: I think I've found the race event in the paramiko code [18:56] if you're interested [18:59] jam: you can bet I am ! (But I've EODed so expect some lag :-) [18:59] vila: Transport._parse_newkeys sets: completion_event.set() [18:59] which makes the outer loop say "oh he must be done, lets exit" [19:00] jam: so the fix is just to remove that set() ? [19:00] not sure yet :) [19:00] still digging [19:00] as to why it succeeds sometimes [19:00] ...or move it elsewhere/later [19:02] I've made some progress rewriting the test but I'm not done yet, it will be very simple.... a handful of lines... but each word counts there :-/ [19:04] vila: current thoughts [19:04] The completion event gets set *multiple* times [19:04] the first time it is set, is after the key exchange [19:04] after that, it gets set when messages are done processing [19:04] we only wait for the first one, but used to leave the thread running [19:04] so now we are killing the thread once it is "ready" [19:04] and the race is such that if we can complete before the kill comes through [19:05] then we succeed [19:05] what thread are you talking about ? [19:06] vila: paramiko.Transport() [19:06] is its own thread [19:06] with its own 'completion_event' [19:06] if I wait(), then clear(), then wait() again, the test passes [19:06] err, without any other change ? Where are you waiting ? [19:07] I'll put up a diff to make sure [19:07] vila: where you used to call' time.sleep()' [19:08] hmmm, very promising [19:09] vila: http://paste.ubuntu.com/486894/ [19:09] or: lp:///~jameinel/bzr/2.3-bzr-connect-ssh [19:11] vila: what I was noticing was that while "completion_event" was set, it *also* has "self.active" still True [19:11] note that at this point, I probably have hacked-up paramiko as well, so I'm working to make sure everything is clean [19:14] what is self.active ? another paramiko attribute ? [19:14] vila: paramiko.Transport().active [19:14] k [19:14] vila: at the end of "start_server" it returns completion_event.isSet() == True, and active == True [19:15] hmm [19:15] vila: looking at the start_server docstring [19:15] jam: doing that right now [19:15] it says "this method will not return until negotation (sic) is done" [19:16] active should be checked [19:16] it doesn't say when all conversation is doen [19:16] just that it has finished negotiation [19:18] what if you just set completion_event to None ? [19:18] vila: we still want to loop on it to know when the channel gets shut down (IMO) [19:19] we can't set it to None for start_server because it creates one if you pass None [19:19] and it waits until the negotiation has finished [19:19] we then need to wait until the conversation has actually completed at some point [19:19] we may as well clear() and wait on completion_event [19:19] though there is a potential race condition then [19:19] you said you had to clear it, who is setting it again ? [19:20] vila: Transport.run() sets it at the end 'if self.active: self.active = False; self.completion_event.set()" [19:20] My suspicion is that several events are needed and paramiko seems to just use completion_event if it's set [19:20] vila: I would guess that you are correct. There is the race that the rekey finishes and then the next action also finishes before we notice [19:21] we can pass in our own completion event, though, rather than using the paramiko loop [19:22] this... sounds promising (did I say that already or what :) [19:22] vila: so I think a race still exists in the new code, but it is much better than just 'time.sleep()' [19:22] I think you're on the right track, check that the other sftp tests are still passing though [19:23] jam: and as soon as you have a testable branch, let me know, I'll try to run it on babune (if you have a subset of tests that would help too) [19:23] jam: I'm off to dinner, gf yelling :) [19:24] vila: so I think a race still exists in the new code, but it is much better than just 'time.sleep()' [19:24] yup that was my gut feeling when I wrote the comment above the sleep, but I hadn't time to dig into paramiko code [19:36] jam: just I thought: there is one thread for the server and one for each connection. If I'm not mistaken, sftp is the only case where my changes may have allow both of them to run concurrently (explaining the bug). Why they use the *same* event (as you seem to demonstrate) is yet to be understood, otherwise using two events (as you seem to hint) should address the problem [19:38] vila: well, there is 1 more thread as well. TestServerInAThread spawns a thread per request, which calls the Handler, which then spawns a paramiko.Transport thread to actually handle the request [19:39] vila: and I'm having good results with 2 events [19:39] though AFAICT, only the connect_bzr_ssh code actually runs the gives "SFTP" handler [19:39] not sure why that is yet [19:40] at least, running "bzr selftest "(?i)sftp" ran all the tests even though I had tyos [19:40] typos === khmarbaise_ is now known as khmarbaise [20:24] jam: yes, but I was ignoring the paramiko thread here [20:26] jam: request == connection in this context [20:32] hi. i made a merge. it warned about criss-cross. then it gave me 18 conflicts, all of the are adding files. the files being added are the very same as the files exisitng. yet bzr did not check this just created the conflicts. === Ursinha is now known as Ursinha-afk [21:32] Howdy, where does one file bugs for bzr-launchpad? It seems they don't use Launchpad for bugs. [21:32] Which is richly ironic. [21:33] https://launchpad.net/launchpad [21:33] specifically https://bugs.launchpad.net/launchpad [21:34] tedg: ^ sorry forgot to ping you with the answer ;) [21:34] rubbs, Okay, thanks. [21:34] rubbs: nope, tedgis talking about bzr-launchpad with indeed didn't activate the bug tracking. jml, that's indeed pretty ironic :-P [21:34] np [21:35] oh, sorry I missread [21:35] tedg: my bad. [21:35] tedg: I'm sure jml will see to that quickly [21:35] rubbs, Ah, okay. I figured jml would see it there as well :) [21:35] vila, He's probably boycotting their bugs. Switching to bugzilla or something. [21:36] ;) [21:37] tedg: yup, I think we've discovered yet another hint about his evil plans... not sure which though [21:38] tedg: meh, there is no code either.... what do you refer as bzr-launchpad ?? :-) [21:39] tedg: there is a launchpad plugin in the core bzr plugins, if that's the one, you can file the bug against bzr itself [21:39] tedg: but nobody calls it bzr-launchpad, it's just the launchpad plugin for bzr [21:41] vila, Ah, that's what I was thinking, bzr help lp-propose-merge says that it's in the launchpad plugin. [21:42] I think bzr-launchpad may be the next generation, jml talked about it, but he hasn't released anything yet apparently [21:43] Ah, okay. I'm already ahead of the game ;) [21:43] tedg: then, yes, that's from the launchpad plugin (as mentioned in the help) and you can wee were it's installed on your system with 'bzr plugins -v' [21:44] tedg: its path should end with bzrlib/plugins/launchpad [21:44] vila, Yeah, but wouldn't all packaged plugins be there? [21:44] have a look [21:45] Yeah, and things like bzr-search turns into bzrlib/plugins/search. [21:45] if you use external plugins, the path should be different [21:46] can you !paste the output ? [21:46] !paste [21:46] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. [21:47] vila, http://pastebin.com/gGZtdgsR [21:47]