[00:06] Good morning. [00:11] hi there spiv [00:14] The cold seems to have mostly subsided today, thankfully. [00:14] poolie: do you know much about bzr reconcile behaviour? [00:14] that's great [00:14] peitschie: a bit, what do you want to know? [00:16] poolie: i've been running into issues where the canonicalize-checks take around 20hrs to run over my repository at work [00:16] i was trying to come up with some ways of speeding things up a bit [00:16] i did notice that the process seems to be very heavily cpu bound... but it's only single-threaded [00:18] as far as you know, does reconcile require sequential repair work (i.e., the next revision requires all previous revs to be fixed) or are chunks of it disconnected (i.e., multiple revs could be farmed out to be repaired by each core and then updates sequentialized back to the main thread)? [00:21] normally you should only need to run it to recover from a previous problem? [00:21] did someone or some program actually tell you to run it? [00:21] i think it probably could be parallelized === Ursinha-afk is now known as Ursinha [00:34] poolie: at the moment I'm still trying to recover from https://bugs.launchpad.net/bzr/+bug/522637 and https://bugs.launchpad.net/bzr/+bug/485601 [00:34] Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 96)" [Low,Triaged] [00:35] poolie: I ran reconcile last weekend, but found someone checked in on monday without getting the "reconciled" repo... which broke things again [00:35] poolie: because of the amount of time it takes to run things, I don't have a big enough space to really do a full reconcile during the week, as it takes a full day to do it :) [00:36] it's one of the things I think is important to a corporate environment... any repair job needs to be able to happen over night [00:36] because I know programmers a not infallible, and there is always a chance there will be another repo-breaking bug... [00:37] i've been considering spending some time trying to speed up reconcile, so recovery from future bugs of this nature can be achieved during the working week without stopping all dev work during the day [00:37] :? [00:37] yuck [00:37] one good way to start might be to be able to select particular types of reconciliation to do [00:38] yep... those were some of the other things i was going to look at [00:38] similarly for check for that matter [00:39] i figured a lot of time is likely spent calculating sha's and similar tho as well... so if I can potentially just multi-thread *that* part slightly, I think there might be a reasonable gain to be made [00:40] I started playing with some profiling last night to see, so I don't really have any clear ideas on it yet :) [00:40] but just thought i'd ask in case you were aware of much around it :) [00:42] the other thing i'm considering is how we might potentially be able to generate more useful debug information for the previously listed bugs as well [00:42] in the case of both of those, they have proved exceedingly hard to track down and verify because of the requirement of having it occur on a publically available repo [00:43] again... i have no real plans at this point... just pondering some things that would make my adoption here a little less risky a prospect [00:44] mm, again maybe having a task-specific check output some non-sensitive debug data would be good [00:44] it's a bit hard to predict ahead of time what would be useful [00:44] but it is possible [00:44] i figured that there is always some things taht would be missed [00:45] i'm wondering if perhaps dumping things like revision history, sha's, ancestry... i.e., mainly the repo and branch histories might be sufficient to get a head-start [00:46] my thought is to try and work out what info would have helped track down the previously listed bugs... see how hard it is to produce... then potentially wrap that up in a command/tool of some sort (potentially even as part of check) [00:46] that would be good [00:46] so even if we don't get everything next time, *hopefully* future issues like these (that seem to revolve a bit around shared repo => shared repo) might be a bit easier to track [01:45] Good evening. [01:46] Anybody here know about bzr-explorer internals? [01:46] hi there [01:46] In particular, the way it invokes qbzr commands? [01:46] not a lot, but what's up? [01:46] I'm working on my mergetools thing and it looks like explorer is using my system installed bzr to run qbzr commands instead of the dev version of bzr that I invoked explorer with. [01:47] So I get an ImportError because my qbzr references a module (mergetools) which doesn't exist in bzr 2.2.0 [01:48] but which does exist in my dev bzr [01:48] hm, interesting [01:48] that sounds right [01:48] hi, spiv, so what are you up to today? [01:48] poolie: what sounds right? that it uses the system bzr to invoke qbzr? [01:49] i mean, that sounds like a correct diagnosis, but i agree it's a bug [01:49] it should use the matching version, i would say [01:49] poolie: http://paste.ubuntu.com/507655/ is the relevant section of bzr.log if you could double-check my diagnosis? [01:51] I'll be damned if I can think of how to search for this bug to see if it already is known :) [01:55] i don't recall hearing of it [01:56] dOxxx: i think there is a bzr symbol to find the right executable [01:56] because the tests do the same thing [01:56] i'd just file a new bug; we can always dedupe later [01:56] I thought I remembered some discussion about it on the bzr mailing list in the last month or two. [01:56] yeah I'm typing up the bug now [01:56] poolie: so far mainly catching up on a week's worth of email [01:57] oh, wow [01:58] it has been a while [01:58] good luck :) [02:00] dOxxx: if you want to talk about where the bug is or how to fix it just ask, otherwise i'll leave it with you [02:01] poolie: no I'm good, just writing it up. :) [02:01] Thanks :) [02:34] * spiv -> food [03:16] Is there a plugin that will just run a particular external command before "commit"? [03:20] sure there is a externals hook plugin [03:20] or you can just trivially do a custom one yourself. [03:31] lifeless: Yeah, I figured it would be trivial, I just wanted to know if it already existed. === Ursinha is now known as Ursinha-afk === zyga is now known as zyga-gone === dOxxx1 is now known as dOxxx === JayFo is now known as JFo [06:43] spiv, what do you think we should do about news? [06:43] one news file per series? [06:44] I think so. [06:49] do you want to split it up then, while you're there? [06:50] I can do that, what's the exact path names you're after? [06:50] hm, possibly we should just move it into doc/en now, and perhaps just leave a pointer in news? [06:50] that would be similar to whatsnew [06:50] and everything else [06:50] s/in news/in NEWS in the root [06:51] whatever we do, we'll need to update the doc builds rules [06:52] Right. [06:52] It would be nice to have something fairly visible in the root. [06:52] But not nice to accumulate clutter for every historical release in the root. [06:53] I suppose we could have the current series in /NEWS, and everything else in doc/en/old-news/*, but that feels a bit weird. [06:53] istm just a pointer there would be ok [06:53] Ok, phew :) [06:54] I'll do that. [07:05] hi all ! [07:05] Hey vila! [07:05] spiv: Welcome back ! [07:06] spiv: can I have paramiko package from your ppa for maverick with my pony ? Pretty please :) [07:06] *a paramiko package [07:10] vila: hmm [07:10] vila: I'm not sure at a glance why my last attempt to do so failed: http://launchpadlibrarian.net/52203585/buildlog.txt.gz [07:11] (https://code.edge.launchpad.net/~spiv/+recipe/paramiko-test/+build/340) [07:11] spiv: the point is that there is only one test failing on babune for the maverick slave [07:11] ha, yeah, I forgot that, you mentioned it at the time though [07:11] spiv: sudo build-my-package ? [07:13] spiv: hmm, rather obscure... "they" did manage to build it for maverick so there should be a way... [07:13] I'll hit the button again and we'll see what happens. [07:13] aptitude command not found ?? [07:13] hello vila [07:14] hey poolie, hopefully I'd feel better today :-/ [07:14] and do you? [07:14] well, so far, yes [07:14] but yesterday and the day before I went down without notice :-/ [07:16] Maybe the universe is corrupted. Look at the checksum? [07:17] quantic checksums make my head hurt, bad idea [07:18] Just pick a worldline where they don't. [07:18] * vila facepalms [07:18] ouch [07:18] Also, don't smack yourself. It hurts less that way 8-} [07:20] vila: apparently it built and uploaded okay this time [07:20] fullermd: you should have said so earlier [07:20] spiv: yeah just noticed ! [07:21] Well, I did. You just heard me later. Speed of light and all that, y'know. [07:24] fullermd: yeah sound travels slower than light around here [07:25] Naturally. Sound is heavy. Light is... well, you know. [07:26] spiv: http://ppa.launchpad.net/spiv/packaging-test/ubuntu/dists/ not updated yet, I suppose I should wait a bit [07:27] * fullermd cranks up his sound to compensate. [07:27] Luckily, nobody around minds if I do that at 0130 :p [07:27] spiv: ha right, the details at https://code.edge.launchpad.net/~spiv/+archive/packaging-test/+packages shows that it's still pending publication [07:28] fullermd: :) [07:32] (on that topic, I wish Youtube would sort out their 34/18 formats, so that one was consistently the better, rather than random, or even more often, one having sucky audio and decent video, and the other being the other way around :| ) [07:46] hm, not sure whether to send this to the list or file a bug [07:46] vila: can I request a full babune run on windows of a branch? [07:46] mgz: sure, just name it [07:47] http://float.endofinternet.org/bazaar/bzr/hack_get_transport [07:48] sorted out what from your leaks branch was causing me problems, but I'm not sure why it's not broken for other people, or the best way to fix it. [07:50] mgz: hmm, looks like your bandwith will suffer :) [07:50] mgz: push to lp next time ;) [07:51] it's a five line diff, how badly can bzr... oh, are you not stacking? [07:52] mgz: nah, it's ok, I did branch it locally to look at it... [07:53] mgz: err, this fix changes what exactly (in behaviour) ? It looks like you're working around some import aliasing bug here [07:54] ha, good guess. I'll post to the list. [07:55] mgz: note that the current approach is hackish, we should define a hook triggered when a transport *connects* [07:56] that sounds like a good suggestion. [07:56] mgz: running: http://babune.ladeuil.net:24842/job/selftest-subset-windows/8/ [07:57] thanks! [08:03] okay, sent email. [08:17] mgz, nice mail [08:17] i thought there already was a way to disable laziness but imbw [08:17] that babune report is great! [08:18] to be fair on that front, by the time I realised it was lazy import causing issues not something else, I didn't need to test anything else [08:18] it was the getting to that point which was the hard bit :) [08:19] (so it may well be that I could have found a way to disable lazy import, if I'd thought to( [08:20] )) [08:26] poolie: can mgordan be added to the contrib agreement group? I landed his first branch already as I got cced. [08:28] will do [08:28] heya poolie, mgz [08:28] hi there [08:44] mgz: you run finished: FAILED (failures=2, errors=3) [08:45] not bad for a hack, and 45 mins rather than 77 is the great bit :) [08:47] mgz: I see to... what's the message... this test would have hang or something, right ? [08:47] s/to/no/ [08:47] bonjour vila [08:48] which means the leak fixes were correct except they didn't catch some import aliases right ? (I confess I focused on the ones in tests...) [08:48] http://babune.ladeuil.net:24842/job/selftest-windows/190/ <- Took 1 hr 32 min on xp-32bits.local [08:48] bialix: hey ! [08:48] http://babune.ladeuil.net:24842/job/selftest-subset-windows/8/ <- Took 45 min on xp-32bits.local [08:48] right, most probably the cause is that we don't wait for threads to finish anymore [08:49] basically yeah, complete for fix and all the "thread ('127.0.0.1', 2265) -> ('127.0.0.1', 2263) hung" goes away [08:49] shudder [08:49] care to comment on https://code.edge.launchpad.net/~vila/bzr/imports/+merge/36324 ? [08:50] no. :P [08:50] I think I failed to convey some hard numbers about time spent to debug such obscure crazyness [08:51] anyway, thanks for pointing out the obvious fix, but that's still a hack on top of a hack, so we should implement a hook [08:52] I went out of steam on the subject at the time, may be we can pair on this ? [08:53] mgz: A most probably related topic being the test suite still can't be run on OSX because some sockets are still leaking, I will try your branch there [08:53] vila can you try to help a bit with reviews/landings? [08:53] i realize i'm pp and i've done some but it's still queued [08:53] poolie: yup [08:53] poolie: I think it's fine that PP ask for help when needed [08:55] ^I agree merging namespaces can cause bugs like this, but it's also useful. I don't think we can coding style it away. [08:55] hm, i just did a parallel test and got ebadf again [08:55] poolie: and I wonder if we should not *all* focus on getting the queue back into control, it's awesome to have so many contributions but it will collapse fast if we don't address them [08:55] poolie: for an https one ? [08:56] vila, sftp actually, inside paramiko [08:56] I'll happily have a crack at fixing this the right way, especially if you're offering help/ [08:56] running parallel=fork seems to be the only time my machine's fan spins all the way up :) [08:56] hehe [08:56] it would probably be an even stronger effect on apple hardware [08:56] vila's the one most in need of reviewing I think, you'll need to press gang someone else as well :) [08:56] poolie: sry I can't remember without a tracback, what's the failing test ? [08:57] i appreciate yours [08:57] I have a pselftest='selftest --parallel=fork' alias [08:57] spiv: tss [08:57] :) [08:57] vila, for the ebadf thing? [08:57] though neil's on a roll too. [08:57] spiv: bzr alias tss="selftest --parallel=fork" :-D [08:58] poolie: yup [08:58] Hopefully now I'm back from a week of leave + virus I'll be able to help with the queue too. [08:58] Help reduce it, rather than grow it, that is ;) [08:58] mgz: and you've helped a lot too, thanks for that [08:58] * spiv -> dinner [08:59] I still need a lazr.restfulclient reviewer if anyone can dig one of those up. [08:59] poolie: on a related note, we have an RT asking for an upgraded testtools on pqm that seem to be blocked by a desire to upgrade to lucid, I'm a bit lost about the whys here, can you summarize ? [09:00] https://bugs.edge.launchpad.net/bzr/+bug/656170 [09:00] Launchpad bug 656170 in Bazaar "EBADF in paramiko during parallel selftest (affected: 1, heat: 6)" [High,Confirmed] [09:00] vila, sorry, i don't know many specifics [09:00] i know the GSAs are in the process of upgrading some boxes [09:00] suggest you ask in canonical is [09:00] BIG RED FLASHING WARNING: lp read-only [09:01] no warning? [09:01] poolie: ha, that one, but it doesn't make the test fail right ? [09:01] IIRC when I asked spm last week the RT wasn't blocked, merely some way down the queue? [09:02] it's been announced, but I lost a bug report yesterday, so I'm warning others ;) [09:03] poolie: I'll comment on the bug, but roughly, yes, it's a bad timing, but no it's really a bug [09:05] poolie: the fix would be to catch the exception like we do for our threads, but this one is private to paramiko and injecting our class here can't be done cleanly, so it's way down my TODO list and I would even make the bug importance a wishlist, the test doesn't fail [09:08] vila: i.e. the bug is (partly?) in paramiko? [09:12] spiv: hmmm, IMHO, the bug is partly in python: there should be a simpler way to handle exceptions in threads than redefining the Thread class [09:12] spiv: and a way to kill a thread by throwing an exception too (and a pony) [09:14] spiv: that won't give us a direct way to tell paramiko to ignore EBADF for its threads either though, but that will become easier [09:15] the problem here is that we want to ignore this exception before stopping the thread but *not* when starting it [09:19] mgz: so the idea for the hook is that we want to replace the hackish overideAttr with a hook that will do roughly the same thing: keep track of the transport and disconnect it when tearing down the test [09:20] vila: you don't need to subclass Thread [09:20] vila: you just need to wrap the function you pass as the target [09:20] there is more than one way to do it :) [09:21] vila: unless you mean monkey-patching the threading.Thread globally to change the behaviour of *all* threads... which seems risky. [09:21] spiv: the most convenient is to be able to say to a running thread: from now on, swallow these exceptions [09:22] I mean, it is a bit weird to me that the main thread has sys.excepthook, and the other threads don't. [09:22] Just because it's inconsistent. [09:22] (Or does sys.excepthook intercept unhandled exceptions from all threads...?) [09:22] interesting approach... [09:23] (Nope, it doesn't.) [09:23] too bad :-/ [09:24] But anyway, in principle you don't need any special facility to deal with top-level exceptions. You can already write "try: ...; except: top_level_exc_hander()" at the top-level of the code. [09:25] spiv: for a third-party library ? [09:25] Well, how a 3rd-party library runs its threads is ideally its own business. [09:26] hehe [09:26] It's like how you can't really add logging to a 3rd-party library from the outside [09:27] Either it already does that (and ideally allows you to have some control over where/how much it logs), or it doesn't and you need to get it fixed upstream. [09:36] spiv: right, in this sense, yes, this could be seen as a paramiko bug, but given the time it takes for your fix about the wrong address families to be taken into account, I'm not holding my breath for something that impact only tests :-( [09:38] vila: well, being clear about the causes and deciding what to do about the problem given the circumstances are different issues. [09:38] vila: maybe there's a workaround we ought to do, but that doesn't magically make it not paramiko's fault :) [09:41] well, paramiko rightly raises the EBADF exception, *we* want to be able to ignore it in *some* cases and even there, we change our mind *after* asking paramiko to start its thread [09:41] that's the cause [09:41] there is indeed more than one way to deal with it [09:43] and like the other problems encountered with the leaks, the fact that we run the server and the client in the same process is something that hasn't been taken into account in the design [09:44] it works better for paramiko than for SocketServer though [09:45] vila: the bug isn't that paramiko raises EBADF, it's that it spews it to stderr rather than giving the app a chance to know about it. [09:46] Probably the obvious thing for paramiko to do would be log the exception. [09:46] spiv: well, if I was the paramiko author I could answer: hey, that's Thread that is spewing on stderr :-P [09:46] Seeing as it already uses the logging module. [09:46] Sure, that's the mechanism. [09:46] But that doesn't make "unconditional spew on stderr" the right behaviour for a library. [09:47] and whatever happens in this thread is supposed to be conveyed to the user via the channel object (or whatever, don't remember the details) [09:48] (Especially given that in general paramiko takes a fair bit of care to use logging rather than unconfigurable spew on stderr) [09:48] spiv: my suspicion is that reproducing this without running the server and the client in the same process is non trivial (if possible) [09:49] Sure, I'm not arguing about that point. [09:50] do you know where abouts in the paramiko code it's printing directly to stderr? [09:50] (In fact, if robey had encountered it himself already I bet he'd have fixed it to be suppressed or logged, rather than let the Python threading bits spew it to stderr) [09:51] Glenjamin: lol, nowhere in this specific case, it's a side effect of using a thread and having an uncaught exception bubbling up to the top level [09:51] that sounds broken [09:53] the thread's exception has nowhere to bubble up to, and can't kill the master process i guess? [09:55] It doesn't kill the main thread, no. [09:55] The Python VM just writes a traceback to stderr when an unhandled exception happens in a thread. [09:56] So if you don't want that, make sure you never have unhandled exceptions in your thread. [09:56] well, that's my main grief against python threads, the interpreter takes a great care to handle them but the exception handling is left to the user, requiring him to be ready for it in the function given to the thread [09:56] Which isn't that hard, really. [09:56] So the only fix is to wrap the thread contents in an except block [09:56] vila: I really don't see the difference with the main thread [09:57] well, the exception in the thread is not propagated there for one [09:57] so if you change your design to use threads your callers are suddenly doomed [10:01] Propagated where? [10:01] They have a separate call stack, that's kinda the point ;) === maxb_ is now known as maxb [10:06] I started a thread, I want a simple mean to know that something bad occurred [10:07] vila: you started the thread, so you can [10:07] vila: just pass in a function that reports that [10:07] mgz: wooohhoooo, yeeeehaaa, test suite passes on OSX ! Pfew, my last attempt was depressing, I thought there was some more unknown leaks... [10:08] spiv: that's not simple enough, see my previous point: callers have to care now [10:08] It's not hard to write a generic wrapper ("try: foo(); except: report_error()") to help you [10:08] vila: you're better than you thought you were :) [10:09] mgz: yeah, something like that ;) [10:09] spiv: isn't the problem that it's not "you" it's paramiko, and we can't raise the maintainer currently anyway [10:09] So that your start thread call becomes Thread(target=err_wrapper, args=(func,)) rather than Thread(target=func) [10:09] Which isn't exactly onerous. [10:09] spiv: and you also need to provide this to the caller which itself, etc [10:09] I mean, it would be nice to have it more convenient. [10:10] exactly [10:10] Perhaps even have Thread.get_result that blocks (i.e. calls join), and then either returns the value the target func returned, or reraises the exception it terminated with. [10:10] (And in Twisted, you can use blockingCallFromThread for something like that) [10:11] ..or are we on testing now, not the EBADF bug? [10:11] * mgz went off to get food [10:11] But it's really not hard to roll your own :) [10:11] mgz: right, the problem is in paramiko, that's my point :) [10:12] mgz: and I argue that paramiko can point the finger at python :) [10:12] ThreadWithException was my answer for bzr :) [10:12] Eh, it can point the finger at python for making it merely simple, rather than trivially easy. [10:13] ..where the exception is re-raised by join() [10:13] So pardon me if I don't consider that a great excuse :) [10:15] spiv: well, if you require all thread users to implement such a mechanism, why not implementing it in thread ? [10:16] spiv: the try/except/finally is not always enough, you also need a guarding event in most cases and this event should be set to ensure the caller is not blocked [10:17] hi [10:18] mgz: to be precise, there are still 3 failures on OSX (plus some tweaks of LC_ALL) but at least it *completes* [10:18] mgz: which is *huge* from my POV :) [10:18] vila: the standard library has many deficiencies [10:18] vila: this is just one of them :) [10:19] I have been trying to use git-bzr-ng plugin to get two way git<>bzr bridge so I will not have to learn bzr and can use git for it. clone works but push works only if there were no changes done. push with change ends with http://pastebin.com/XA8LJgVv reported. [10:19] can someone look at pastebin and comment? [10:23] it works when changes are pushed to new bzr branch but not when pushed to existing one [10:25] hrw: by git-bzr-ng you mean bzr-git ? [10:25] no [10:26] hrw: and you seem to be using bzr-fast-import... [10:26] http://github.com/termie/git-bzr-ng/ [10:26] git-bzr-ng uses bzr-fast-import in backend [10:26] bzr-git is to get git repo in bzr. git-bzr-ng is to get bzr repo in git [10:27] hrw: why don't you try to use bzr-git instead ? I never heard about git-bzr-ng so I'm not sure you get a lot of answers in *this* channel... [10:27] vila: http://marcin.juszkiewicz.com.pl/2010/10/06/bazaar-what-is-wrong-with-it/ summaries my feelings about bzr [10:28] vila: in short: I do not like bzr. [10:28] hrw: I'm not discussing whether you like bzr or not, just trying to point you to the right place to get the right answers [10:28] sure [10:29] but coming here saying that don't like what we do doesn't sound like the best start :) Welcome anyway [10:31] I know - just wanted to ask for help to understand where from error comes. [10:33] the traceback tells it's from fast-import, try adding BZR_PDB=1 in front or your command and poke at parts and self_git_to_bzr_name for a start [10:33] thx, will check in few minutes [10:34] vila: to be clear, mac osx needs hack_get_transport to complete, or have you just not tried since your previous fixes? [10:35] mgz: I tried with my fixes, the hack is needed, so the remaining leaks were caused by calls to the original get_transport, defeating the override [10:36] ha. [10:36] mgz: I ran with the hack and a live open-files windows and I never seen such a clean run :) [10:36] yeah, we're getting there! [10:37] a bit more chipping away and we'll have a clean suite on all the platforms we try and support [10:37] your hack ensures get_transport is properly overridden so it validates all the fixes, I just wished I thought about it myself ;) [10:38] the bit I don't get though, is why this made such a huge difference between windows/OSX on one side and all the other on the other side... [10:39] I'm just answering poolie's question on the list, my understanding is it's how the different socket libraries work [10:39] and no cheap joke about proprietary softwares leaking resources :) [10:40] mgz: oooh, let's try it on FreeBSD [10:40] and naturally that the tests are written by people on nix, so when there are problems there it's fixed before it ever lands [10:41] in the *socket* library... [10:41] windows at least has diverged rather from its start, not sure what osx uses. [10:42] but still worth seeing if we get a speed up on freebsd [10:43] awesume [10:44] git-bzr-ng - ill have to check it out [10:44] mgz: yup, that's the idea [10:45] I want to know what the ng is for. Does it do time travel into the victorian age as well? [10:46] there is already some git-bzr hack, so he wanted to make it sound new and cool [10:46] hrw: Your post is not very specific about what is missing in bzr, filing bugs at https://launchpad.net/bzr/+filebug would get you more attention and better hope that we address your needs [10:46] ok [10:47] it's missing a proper remote managing interface [10:47] the stuff you said in here the other day was actually more enlightening [10:48] those half backed branches which are tied to remote branches are buggy as shit [10:48] you were trying to adapt your git-y workflow to bzr and struggling [10:49] i can adapt to new bzr'ish workflows [10:49] no problem [10:49] that was aimed at hrw, but either way. [10:50] hacking up a giant change then splitting it into little bits to merge on the current trunk isn't something bzr supports particularly well, but there are ways [10:57] hrw: re: your blog post - the first link on related is a similarly exasperated post about git from 3 years ago (which i presume is when you started using it) [10:58] Glenjamin: yes, related posts are often crazy [10:58] my point being, maybe you'll get used to it :) [10:58] who knows.. maybe in 2014 I will use bzr more often [11:00] heh, good point Glenjamin. I do "graaa, new thing I don't want to adapt to" all the time. [11:02] for instance, I wouldn't generally try and re-organise a patch before trying to get it upstream, i'd just supply a mergable branch [11:02] but presumably cleaning up a patch like this is common in git [11:02] yeah, it's standard workflow for a bunch of projects. [11:03] my assumption is the reviewer would look at the final diff [11:11] mgz: 22min on FreeBSD, nothing spectacular nor unseen [11:12] unless [11:12] no, parallel=fork in both cases [11:19] Hello [11:19] the slowness there does seem to be a little all over from disk access rather than lots in smart server tests, so shouldn't be suprised [11:19] I had some breakage in a repository earlier today, so I thought I'd take the opportunity to upgrade bzr to 2.1.2 (on Windows). [11:20] With the previous (2.0.0) version I got a bazaar directory with a bzr.exe file, but with this new version, I have not bzr.exe. [11:20] ..and not bzr.py along the path. [11:20] Do I need to do some post-installation set up to get a command line "bzr" in Windows? [11:21] okay, #1 did you use the right installer? and #2 were there any error messages during the install process? [11:21] No error -- and I'm certain I used the correct installer. [11:22] Oh, just found it. I think. There's no dedicated bazaar directory any longer, but it has placed a bzr.bat under c:\python26\scripts. [11:22] I assume that's what I'm supposed to use instead. [11:22] called -setup.exe rather than .win32-py2.6.exe right? [11:22] okay, so you did use a different installer. [11:23] Hmm.. I wasn't aware there was more than one. :) [11:23] that's fine (and often actually preferable if you have python installed anyway), but you do need to add the scripts dir to your path manually for some reason [11:23] the actual python installer should do it for you really. [11:24] So the *-setup.exe contains a full python installation too? [11:24] it does. [11:24] and various bundled plugins as well. [11:24] Hm.. Seems overkill since I already had it. Well, that's one mystery less. [11:25] Well, time to get back to work. Thanks for the clarification. [11:27] meh, I meant 2.2.1 not 2.1.2 right ? [11:28] you typoing release notices still vila? :) [11:28] errr, *he* meant, DaffyDuck_ [11:30] nope, I think they really meant 2.1.2 as was upgrading from 2.0 [11:30] and had done it long enough ago not to remember the installer looked different last time. [11:31] shudder [11:32] okay, so about this hook. [11:32] we want something that runs just before an actual connection is established? [11:33] or just after ? [11:33] or a generic transport setup thingy? [11:33] no, I think at connection, so that it gets called if we re-connect too [11:34] both pre and post can be useful, but I think we want post first [11:35] currently I see there's no one connect method like the disconnect you added, instead it's all connect_something [11:37] right, unifying this may come later, since we're talking about connection, the hook may be specific to ConnectedTransport, but generally adding stuff there is not worth avoiding adding it as unimplemented as the Transport level [11:38] I mean, define the hook at the Transport level even if it's called only by ConnectedTransport [11:38] And ConnectedTransport defines _set_connection that should be used by all relevant classes as part of their connect_something [11:42] hm, yeah, after the connection has been established [11:42] yes, post_connect [12:01] spiv: ......and lp finally made your maverick package available, I installed it on the babune slave which turned blue for the first time. Pfew, just in time ;) [12:48] bzr-svn is giving me problems since a day, bzr pull https+urllib://svn.uitburo.nl/Website/trunk barfs at me: http://pastebin.com/PZUuaHyU [12:49] Bazaar (bzr) 2.2.1 / svn 1.0.4 [12:50] Ideas are very welcome [12:50] :) [13:08]