mneptokTODO: tonight when the moon is high in the sky, go and let loose a prolonged howl. think of igc.00:52
pooliehi spiv01:01
maxbpoolie: 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
mwhudson+1 mneptok01:10
pooliecan you add that to the ppa.txt doc?01:11
maxbah yes - will do01:12
spmmneptok: +1 indeed01:19
maxbhmm. we really need --stacked-on= to support lp: urls01:37
spivHmm, I thought that there had been a patch towards that a while back...01:40
pooliemaxb, done01:40
maxbthanks poolie01:41
spivspm: bzr's pqm seems to be stuck?03:33
=== r0bby_ is now known as robbyoconnor
pooliespiv, yes, the job i sent up yesterday didn't seem to succeed or fail03:55
pooliespiv, did you ping anyone?03:55
spivpoolie: not apart from just then.04:04
pooliespm: could you help us with pqm?04:08
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
* mneptok smiles upwardly05:33
fullermdWell, 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:34
spmpoolie: looking05:38
spmpoolie: 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?05:41
spivspm: 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
spivspm: I'll be a lot more interested in debugging it if it recurs :)06:18
spmheh, call it a one off and stab then?06:19
spivHmm, 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:20
spivspm: how about just do a quick strace to see which syscall it's stuck in then kill it with SIGINT?06:21
spmattach: ptrace(PTRACE_ATTACH, ...): Operation not permitted <== sigh06:22
spivOh, joy.  Possibly related to the strace subprocess left over from the test suite...06:24
spivOr at least, I presume it's a left over and not used by the test in question...06:25
spmthat would make sense. I'll try killing that first; see if that frees things up at all06:25
spmhaha. that just fired off another strace06:26
spmfwiw, stracing the strace gives:06:27
spm strace -p 181606:27
spmProcess 1816 attached - interrupt to quit06:27
spmoki, killed 24617; things *seem* to be moving again06:28
spivWow, starting a new strace isn't what I would have guessed.06:28
spmi tried it twice; same. so ... whee06:30
spmand yup; things are definately moving again.06:30
spivWell, 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:33
spivspm: thanks06:39
spmspiv: I'm quietly confidant that bzr blame will show it's your fault; no matter who really did the change that caused it. fwiw. :-P06:39
maxblifeless: 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
lifelessi don't think so07:28
lifelesswhat url are you seeing?07:28
lifelessif its bzr+ssh://bazaar.launchpad.net/~lifeless/debian/sid/subunit/sid I'm pushing against just in case07:29
maxbahh, so the collab-maint branch is a red herring07:30
maxbAlso, looks like you didn't 'bzr mark-uploaded' the last upload :-)07:32
magciusIs there a decent way to show the changes brought by the current commit?07:40
GaryvdMmagcius: bzr diff -c -107:40
magciusnext question: is there any way to set it up so that if it's on a tty it uses a pager?07:41
vilahi all !07:57
lifelessmaxb: hmm, sorry.08:02
lifelessmaxb: I should probably do that08:02
spivHmm, the test suite seems to have slowed down quite a bit for me recently.08:21
spivAnd as a bonus an https test seems to be tripping over http://bugs.python.org/issue972908:22
vilaspiv: yup, you can safely ignore the failure in that case, it's transient. I encounter it from time to time on babune.08:23
spivYeah, somehow my CPU cores now seem to be about 50% idle, so it's taking twice as long :(08:23
vilaspiv: your bug report is indeed pointing the problem, EBADF should be raised (and will be caught by the test suite)08:24
vilaspiv: I don't observer that *at all* if it helps08:24
vilaspiv: I don't observe that *at all* if it helps08:24
vilaspiv: is that for a full test run or a partial one ?08:24
spivYeah, the interaction between SSLSocket and _socketobject is clearly broken for those methods in that case once you know what to look for.08:24
spivFull run.08:25
spivThe utilisation is varying, actually.08:25
spivBut there was definitely a point about midway through the run where it was literally 50-50, despite having one process per core.08:25
vilahmm, 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 point08:26
spivAnd 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
vilaspiv: I meant, see the patch itself, we actually slow down sftp tests to cope with paramiko08:27
vilaspiv: doesn't match my experience nor babune ones08:28
vilaspiv: 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:29
spivWell, 3000 tests sleeping for 0.2 seconds would equal 10 minutes.08:30
vilaspiv: I'd be glad to proven wrong though :)08:31
vilaspiv: well, one more reason to consider bug #626876 critical then :-D08:31
ubot5Launchpad 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/62687608:31
spivvila: I'll trying commenting out that time.sleep and see what happens08:31
* bialix waves hello08:31
vilaspiv: excellent !08:32
vilabialix: _0/08:32
spivvila: is that time.sleep there really there to make just one test pass?  10 minutes is huge cost to pay for that!08:32
vilaspiv: yes.08:33
spiv(And 25 minutes if you're going to increase it from 0.2 to 0.5!)08:33
vilaspiv: yes08:34
spivOk, 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
vilaspiv: jam even said that it needed to set it to 5.0s to make it pass on a heavily loaded windows machine08:34
spivWell, basically time.sleep is never the right thing to do in an automated test suite.08:35
vilaspiv: I strongly prefer to get rid of it by rewriting that test as I complained about for months :-P Care to help ?08:35
spivBecause there's never a value where it will reliably cause the test to pass.08:35
vilaspiv: agreed, hence the FIXMEsssss08:36
GaryvdMHi bialix08:36
bialixHi Gary08:36
spivvila: incidentally, no ssl-related member_descriptor error on this run so far, but a EBADF traceback has leaking onto my stderr08:37
vilaspiv: speaking of timeouts, paramiko use a 0.1s timeout for every ssh socket (and an associated thread)08:37
spivOh, no, spoke too soon, there's the ssl bug again :)08:37
spivvila: well, in my ideal universe, Twisted's SSH implementation would be more suitable for us which would avoid that sort of mess ;)08:38
vilaspiv: I expect a *few* and shallow fallouts from the leak fixes and babune confirms that so far08:38
spivAh, the EBADF is from a paramiko thread in fact.08:39
vilawhich test ?08:39
spivvila: don't know, it's a traceback from a thread08:40
spiv'Thread-630' :P08:40
vilaspiv: but still... 20 minutes ? How many concurrent runs ?08:40
vilaha, this one :)08:40
spivBut this run is so far looking to take roughly 20 min too :(08:41
pooliehello maxb, vila08:41
spiv--parallel=fork on a 4 core laptop.08:41
vilaspiv: so, regarding paramiko threads, one idea is to monkey patch the thread creation to inject ThreadWithException, but I haven't looked at the details yet08:41
vilaspiv: so concurrency == 8 or 4 ?08:41
spiv== 408:41
vilahmm, weird, you do use tmpfs for /tmp right ?08:42
spivI don't.  (Although I've been meaning to play with that at some stage)08:42
vilaspiv: just try08:43
vilaspiv: most important optimization for selftest, ever08:43
spivvila: Well, I'd really like to fix selftest to not hit the filesystem so much in the first place :)08:43
vilaspiv: 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 :D08:44
vilaspiv: I don't hold my breath but I keep thinking about it though...08:45
vilapoolie: hey :) ;) :-| ;-/ AAAAAOOOO08:45
pooliei know :(08:46
vilaok, 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
vilaRan 24311 tests in 4727.204s08:47
vilaFAILED (failures=1, errors=4)08:47
vilaRecording test results08:47
vilaERROR: Failed to archive test reports08:47
vilamgz: we're getting there... finally08:47
vilaspiv: still running without sleep ?08:48
vilaoh my, how will that be interpreted....08:48
bialix_GaryvdM: can you look at https://answers.launchpad.net/qbzr/+question/121019 please08:49
* GaryvdM looks08:50
=== bialix_ is now known as bialix
bialixGaryvdM: I'm not sure how we're interacting with extmerge08:51
vilabialix: http://paste.ubuntu.com/486635/  \o/08:51
bialixvila: cool08:52
bialixsorry, today I'm not able to enjoy08:52
vilabialix: and that's the real stuff running from bzr.dev08:52
vilabialix: I know :-(08:52
GaryvdMvila: That is great.08:53
vilaGaryvdM: 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_log09:01
spivvila: oh wow09:02
vilaGaryvdM: 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
spivvila: so it's because when I don't have my battery in my laptop the CPU is throttled to half speed!09:02
vilaspiv: LOL, thanks for that laugh :)09:02
spivvila: note that I'm on AC power either way09:03
* spiv boggles09:03
vilaspiv: what a trap :)09:04
vilalaptop want a battery, laptop want a battery !09:04
GaryvdMvila: 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:05
fullermdIf you put two batteries in it, does it go to double speed?09:06
vilaGaryvdM: I read something about that in the IRC logs but I haven't realized it was generated, great !09:06
GaryvdMvila: and I wrote a whole bunch of tests for existing bugs09:06
vila4 ! 8 ! Give it more batteries ! Tell Intel we've solved their problem with Moore's law !09:06
vilaGaryvdM: Excellent ! Isn't it nice ?09:07
spivHmm.  /sys/devices/system/cpu/cpu*/cpufreq/bios_limit drops when I remove the battery.09:09
vilaGaryvdM: meh, stringify won't work for dotted revnos, I'm an idiot :)09:09
GaryvdMvila: http://pastebin.com/YdsrMyEw09:10
vilaGaryvdM: wow, amazing !09:11
spivPerhaps it's http://www.thinkwiki.org/wiki/Problem_with_CPU_frequency_scaling09:11
* vila checks that virtual machines have a soldered battery....09:13
vilaGaryvdM: 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 needed09:15
vilaGaryvdM: or something09:15
GaryvdMvila: If I could output unicode, I could make the graphs more readable, like this: http://pastebin.com/ZW7i4nZF09:16
vilaGaryvdM: but still, wow, I will certainly look at that the next time I play with ancestry graphs09:16
vilaGaryvdM: wow wow wow, you need to make this available outside of tests  !09:17
GaryvdMvila: like a ncurses version of qlog?09:18
vilaGaryvdM: no, as a generic utility to visualize graphs09:19
vilaso we can use that when discussing, here, in mails, anywhere09:19
vilahmm, 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 clearer09:21
vilaGaryvdM: anyway, you may have better things to do right now but it may be worth considering as a long term goal...09:22
pooliei'm going to update and re-fire the strace things09:35
pooliehopefully not causing another hang09:35
pooliehm, i can imagine why that's hangign09:39
pooliebut this is a kind of unprofitable mole to whack09:39
GaryvdMVery interesting website igc had linked on his site: http://headrush.typepad.com/09:42
poolieit is, though it came to an ugly end a few years ago09:47
poolievila, i'm going to re09:49
pooliere-send the strace thing, with the tests disabled09:49
pooliewhich should not make pqm hang09:49
pooliebut if it does, please just as a SA to kill it09:49
vilapoolie: ok, I'll keep an eye on it09:51
Odd_BlokeHello 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:56
vilaOdd_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
spivOdd_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-on10:58
spivvila: the first command created a bzrdir with a repo10:59
spivOdd_Bloke: although10:59
spivOdd_Bloke: why specify the stacked-on branch manually?10:59
spivOdd_Bloke: LP should have that set up for you by default11:00
spivAlso, that first error is weird!11:01
Odd_Blokespiv: Ignorance. :)11:01
Odd_BlokeSo just 'bzr push lp:~username/projectname/branchname' should do stacking automagically?11:01
Odd_BlokeOoh, shiny.11:02
spivOdd_Bloke: well, assuming you have set a development focus for the project in Launchpad11:05
spivOdd_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:05
vilaspiv: gee, I so mis-read the paste :-/ Anyway, does lp support stacking on a branch other than dev focus ?11:06
spivWhich may be related to the original failure11:06
spivvila: yes (but may require some amount of prodding, I don't recall)11:06
vilaRight, poolie's strace patch landed11:13
=== Ursinha-afk is now known as Ursinha
vila(jelmer) Add ControlDirFormat.supports_workingtrees cvar. (Jelmer Vernooij) is currently failing on pqm, let me know if you get the failure email from pqm13:21
jelmervila: Will do, thanks.13:21
vilajelmer: 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.13:28
=== Ursinha is now known as Ursinha-afk
vilajelmer: something like http://paste.ubuntu.com/486734/ should be enoug (not tested)13:31
vilaurgh no, you need more :-/13:31
mgzvila: http://babune.ladeuil.net:24842/job/selftest-windows/149/console <- looks good13:36
mgzI see bug 625574 and bug 273978 and bug 581311 and use of osutils.safe_unicode which should be called osutils.break_randomly13:36
ubot5Launchpad bug 625574 in Bazaar "testtools details should not be shared between parameterised tests (affected: 1, heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/62557413:36
ubot5Launchpad bug 273978 in Bazaar "UnicodeDecodeError when strerror is not ascii (affected: 1, heat: 4)" [Low,Confirmed] https://launchpad.net/bugs/27397813:36
ubot5Launchpad 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/58131113:36
vilamgz: yeah :)13:36
mgzI've got the first one, which will mean we get the pretty result display when you install a fixed pyjunitxml13:37
vilamgz: err, I meant for the windows run, for safe_unicode, I'm a bit surprised13:37
mgzThe second I'm going to get back to now I've fixed testtools so can actually test it without breaking the infrastructure13:37
=== Ursinha-afk is now known as Ursinha
vilapyjunitxml, I had *that* installed ? Where ? 8-/13:38
mgzsafe_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 time13:38
mgzbut actually the code could be totally bogus.13:38
vilamgz: 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 other13:39
mgzthey're little plasters over api mistakes.13:40
mgzall in all though, looks in  pretty good shape, babune's closer to green than I am :)13:41
vilablue blue ! Because he is frustrated to not be able to report failures, it turns red when it laugh at us :-D13:42
vilabut I don't seem to have python-junitxml installed...13:43
mgzyou must have something, I see in the log your pipeline is:13:44
mgzPython 2.7.0+13:44
mgz+ ./bzr selftest -x TestBreakin --subunit13:44
mgz+ subunit2junitxml -o tests.xml -f13:44
mgz+ subunit2pyunit13:44
mgzit's the subunit2junitxml that's failing because of bad unicode/xml handling, and that code is in pyjunitxml13:44
vilahmm, then I think it may be part of udson which is written in java, no python involved there13:44
mgzbut but but!13:45
vilameh, subunit2junitxml may be failing then, but it's part of subunit13:45
mgzthe last revision on the branch is an encoding change to fix a problem you reported!13:45
mgzso... you must have it :)13:45
* vila asks his clones13:46
vilaoh ! right, got that on babune master, running from sources... wth13:47
vilaoh ! and also on slaves, running from sources too, geee13:48
mgzokay, so I'll give you a new branch to try later, should give us nice results for maverick and xp13:49
vilaPfew, up-to-date with trunk so far. Pfew13:49
vilamgz: yummy :)13:49
mgzfirst... lunch!13:50
vilamgz: enjoy !13:50
jelmervila: Yep, I did get the email.13:59
jelmervila: The testsuite was passing with current bzr-svn13:59
=== zyga is now known as zyga-away
vilajelmer: 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:00
vilajelmer: anyway, it means that your are not *yet* using a lock to protect your config file against concurrent write accesses14:01
jelmerahh, ok14:01
vilajelmer: just a heads-up :)14:02
jelmervila: Thanks14:02
jelmerI'll have a look tonight.14:02
vilajelmer: I'm still interested by your feedback on the transition, I see you use _get_filename.... hehe, you redefine it :)14:03
vilajelmer: anyway, if you think we should change something in bzr.dev to ease this transition, let me know14:04
=== 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
jamGaryvdM: I should note your graphs don't line up correctly in unicode for me in Firefox15:35
jamand they don't format at all in VIM15:36
jamvila: ping about the connection code15:57
jamI just noticed this line in the old "SocketListener" code that you removed:15:57
jam-            readable, writable_unused, exception_unused = \15:58
jam-                select.select([self._socket], [], [], 0.1)15:58
jamalso, 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 event16:01
jamvila: 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 have16:12
jamI 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 sometimes16:13
jamso the test accidentally passes16:13
jamIOW, I think we are somehow asking the service to shut down early, but it just didn't know yet16:13
jamah wait, I have at least 1 boolean inverted, let me fix that first16:14
vilajam: hmm, I seem to remember using an Event for self.serving before realizing it was useless, so I revert to a boolean, let me check16:14
jamvila: 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
vilajam: yup, that was revno 5247.5.3116:16
vilajam: probably SocketServer.py16:16
jamvila: you're right, there is a server_activate() function16:17
vilajam: yup, in the implementation of server_activate16:17
vilawhich is called by default at init time16:17
jamthough why do you override server_bind only to get rid of the 'setsockopt' option?16:18
jamsame for 'get_request', etc16:18
vilajam: for compatibility with previous python versions IIRC16:18
vilaSO_RESUSEADDR is useless in our case and IIRC have different semantics between unix and windows16:19
jamvila: I know there is a comment to that effect in places, at least16:19
jamvila: so one interesting change. The default "listen(*)" amount is actually 5, and not 116:20
vilaand ?16:21
jamvila: just an interesting difference16:27
=== Ursinha-afk is now known as Ursinha
zygabzr lp-propose-merge suddenly stopped working for me: http://pastebin.ubuntu.com/486840/17:24
zygaI'm not sure what is missing but should it not be a dependency handled by dpkg/apt?17:24
vilazyga: try 'bzr -Derror lp-propose-merge' that should give a traceback17:25
zygavila, http://pastebin.ubuntu.com/486842/17:26
vilazyga: that's from lazr imported from launchpadlib.... a bit surprising but I don't know launchpadlib enough to tell you more17:27
zygavila, it's quite surprising as it was working just a few days ago17:28
zyga(apart form all the updates I got in between)17:28
vilazyga: indeed17:28
* zyga needs to reboot after kernel update17:28
vilahmm, if python libs needs a reboot now...17:29
=== 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
jamvila: I think I've found the race event in the paramiko code18:56
jamif you're interested18:56
vilajam: you can bet I am ! (But I've EODed so expect some lag :-)18:59
jamvila: Transport._parse_newkeys sets: completion_event.set()18:59
jamwhich makes the outer loop say "oh he must be done, lets exit"18:59
vilajam: so the fix is just to remove that set() ?19:00
jamnot sure yet :)19:00
jamstill digging19:00
jamas to why it succeeds sometimes19:00
vila...or move it elsewhere/later19:00
vilaI'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:02
jamvila: current thoughts19:04
jamThe completion event gets set *multiple* times19:04
jamthe first time it is set, is after the key exchange19:04
jamafter that, it gets set when messages are done processing19:04
jamwe only wait for the first one, but used to leave the thread running19:04
jamso now we are killing the thread once it is "ready"19:04
jamand the race is such that if we can complete before the kill comes through19:04
jamthen we succeed19:05
vilawhat thread are you talking about ?19:05
jamvila: paramiko.Transport()19:06
jamis its own thread19:06
jamwith its own 'completion_event'19:06
jamif I wait(), then clear(), then wait() again, the test passes19:06
vilaerr, without any other change ? Where are you waiting ?19:06
jamI'll put up a diff to make sure19:07
jamvila: where you used to call' time.sleep()'19:07
vilahmmm, very promising19:08
jamvila: http://paste.ubuntu.com/486894/19:09
jamor: lp:///~jameinel/bzr/2.3-bzr-connect-ssh19:09
jamvila: what I was noticing was that while "completion_event" was set, it *also* has "self.active" still True19:11
jamnote that at this point, I probably have hacked-up paramiko as well, so I'm working to make sure everything is clean19:11
vilawhat is self.active ? another paramiko attribute ?19:14
jamvila: paramiko.Transport().active19:14
jamvila: at the end of "start_server" it returns completion_event.isSet() == True, and active == True19:14
jamvila: looking at the start_server docstring19:15
vilajam: doing that right now19:15
jamit says "this method will not return until negotation (sic) is done"19:15
vilaactive should be checked19:16
jamit doesn't say when all conversation is doen19:16
jamjust that it has finished negotiation19:16
vilawhat if you just set completion_event to None ?19:18
jamvila: we still want to loop on it to know when the channel gets shut down (IMO)19:18
jamwe can't set it to None for start_server because it creates one if you pass None19:19
jamand it waits until the negotiation has finished19:19
jamwe then need to wait until the conversation has actually completed at some point19:19
jamwe may as well clear() and wait on completion_event19:19
jamthough there is a potential race condition then19:19
vilayou said you had to clear it, who is setting it again ?19:19
jamvila: Transport.run() sets it at the end 'if self.active: self.active = False; self.completion_event.set()"19:20
vilaMy suspicion is that several events are needed and paramiko seems to just use completion_event if it's set19:20
jamvila: I would guess that you are correct. There is the race that the rekey finishes and then the next action also finishes before we notice19:20
jamwe can pass in our own completion event, though, rather than using the paramiko loop19:21
vilathis... sounds promising (did I say that already or what :)19:22
jamvila: so I think a race still exists in the new code, but it is much better than just 'time.sleep()'19:22
vilaI think you're on the right track, check that the other sftp tests are still passing though19:22
vilajam: 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
vilajam: I'm off to dinner, gf yelling :)19:23
vila<jam> vila: so I think a race still exists in the new code, but it is much better than just 'time.sleep()'19:24
vilayup that was my gut feeling when I wrote the comment above the sleep, but I hadn't time to dig into paramiko code19:24
vilajam: 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 problem19:36
jamvila: 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 request19:38
jamvila: and I'm having good results with 2 events19:39
jamthough AFAICT, only the connect_bzr_ssh code actually runs the gives "SFTP" handler19:39
jamnot sure why that is yet19:39
jamat least, running "bzr selftest "(?i)sftp" ran all the tests even though I had tyos19:40
=== khmarbaise_ is now known as khmarbaise
vilajam: yes, but I was ignoring the paramiko thread here20:24
vilajam: request == connection in this context20:26
chxhi. 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.20:32
=== Ursinha is now known as Ursinha-afk
tedgHowdy, where does one file bugs for bzr-launchpad?  It seems they don't use Launchpad for bugs.21:32
tedgWhich is richly ironic.21:32
rubbsspecifically https://bugs.launchpad.net/launchpad21:33
rubbstedg: ^ sorry forgot to ping you with the answer ;)21:34
tedgrubbs, Okay, thanks.21:34
vilarubbs: nope, tedgis talking about bzr-launchpad with indeed didn't activate the bug tracking. jml, that's indeed pretty ironic :-P21:34
rubbsoh, sorry I missread21:35
rubbstedg: my bad.21:35
vilatedg: I'm sure jml will see to that quickly21:35
tedgrubbs, Ah, okay.  I figured jml would see it there as well :)21:35
tedgvila, He's probably boycotting their bugs.  Switching to bugzilla or something.21:35
vilatedg: yup, I think we've discovered yet another hint about his evil plans... not sure which though21:37
vilatedg: meh, there is no code either.... what do you refer as bzr-launchpad ?? :-)21:38
vilatedg: there is a launchpad plugin in the core bzr plugins, if that's the one, you can file the bug against bzr itself21:39
vilatedg: but nobody calls it bzr-launchpad, it's just the launchpad plugin for bzr21:39
tedgvila, Ah, that's what I was thinking, bzr help lp-propose-merge says that it's in the launchpad plugin.21:41
vilaI think bzr-launchpad may be the next generation, jml talked about it, but he hasn't released anything yet apparently21:42
tedgAh, okay.  I'm already ahead of the game ;)21:43
vilatedg: 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:43
vilatedg: its path should end with bzrlib/plugins/launchpad21:44
tedgvila, Yeah, but wouldn't all packaged plugins be there?21:44
vilahave a look21:44
tedgYeah, and things like bzr-search turns into bzrlib/plugins/search.21:45
vilaif you use external plugins, the path should be different21:45
vilacan you !paste the output ?21:46
ubot5For 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:46
tedgvila, http://pastebin.com/gGZtdgsR21:47
tedgvila, Those aren't all core, but they're all packaged.21:47
vilawow, all in the same place ! Hmm, I didn't know about that21:48
vilaHmm, in that case I don't know how to differentiate the core ones from the others using the command line only...(python one-liners doesn't count ;)21:49
tedgvila, Isn't that kinda the point of a good plugin system ;)21:49
vilawell, it means there could be a name collision... Dunno how this is handled21:50
tedgvila, In Ubuntu that's handled through the packaging, but typically those get distro patched so they don't conflict.21:55
tedgvila, If you use something unpackaged, well, you're insane :)21:55
vilaright, that indeed guarantee that the packagers will warn us if we create a plugin with a name which is already used. But it also means we need to be vocal when a new release introduces a plugin.21:58
vilaWhich is already the case anyway.21:58
lifelessvila: this is how plugins are designed to work22:00
lifelesscooexist as regular submodules of bzr22:01
vilalifeless: yes22:01
vilalifeless: But if jml defines a bzr-launchpad plugin that overrides the core one, this must be somehow handled by the packaging (the core one should never replace the external one).22:03
chx(this is a re-question but noone seemed to be active when i asked ~2 hours ago) 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.22:03
vilalifeless: and this still defeats making a difference between BZR_PLUGIN_PATH=user:site and BZR_PLUGIN_PATH=user:site:core22:03
lifelessvila: I had no idea about such a proposal, it seems pointless to me22:04
lifelessvila: there isn't IMO a 'core' plugin definition, doesn't exist.22:04
lifelessvila: sure there is 'we ship it' but thats the extent of the separation IMO22:04
vilalifeless: that's not a proposal, that's how it works today and without it you can't run from source22:07
lifelessvila: oh, well it seems strange to me22:08
vilalifeless: it makes no difference as long as there is no name collision22:09
lifelessvila: FWIW I run from source all th etime and have never set BZR_PLUGIN_PATH22:09
vilalifeless: :-P22:10
vilalifeless: that's because you don't always run the full test suite :-D22:10
lifelessback to lp code; getting performance under control :)22:11
=== Ursinha-afk is now known as Ursinha
FryGuy-is there an easy way to get the list of files modified from revision X to Y?23:22
lifelessst -r x..y23:23
FryGuy-:D thanks23:23
poolieFryGuy-: bzr st -r X..Y23:23
FryGuy-i didn't even think about status23:24
FryGuy-even though that's the format I wanted it in23:24
FryGuy-that's in the range (X, Y], right?23:25
FryGuy-i get confused if it's inclusive or not.. i'll just double check myself23:26
lifelesshalf open23:26
FryGuy-thanks again23:28

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!