[01:21] <igc> morning
[01:24] <NfNitLoop> evening!
[01:24] <NfNitLoop> :)
[01:27] <poolie> hello
[01:29] <lifeless> hi
[01:32] <jelmer> 'morning igc, NfNitLoop, poolie, lifeless
[01:33] <poolie> hi
[01:33] <igc> morning jelmer
[01:57] <lifeless> wow
[01:57] <lifeless> so much wiki spam
[01:58] <poolie> yeah, sucks
[02:01] <poolie> lifeless, i'm reading your commit overhead patch
[02:04] <lifeless> poolie: ...
[02:05] <poolie> ?
[02:05] <lifeless> you said you're reading the patch
[02:05] <lifeless> and then nothing
[02:05] <poolie> i voted +1
[02:05] <poolie> for 0.91
[02:05] <lifeless> ok
[02:06] <keir> lifeless, did you end up pulling my branch?
[02:07] <lifeless> keir: sorry no I haven't yet
[02:07] <lifeless> I *meant* to but ended up tweaking performance of commit more
[02:08] <lifeless> igc: shall we chat shortly about how we combine branches?
[02:08] <igc> yes - I call in 10 minutes?
[02:09] <keir> lifeless, no problem; i fixed some idiocy in it on the bus
[02:09] <lifeless> igc: please
[02:11] <poolie> lifeless or igc, would you please look at http://bundlebuggy.aaronbentley.com/request/%3Cm2wsuyzoy3.fsf@free.fr%3E
[02:13] <lifeless> igc: I don't think my patch needs to change, I've replied with why.
[02:14] <lifeless> igc: would appreciate you checking back on it so I can merge for 0.91 as per poolies ok.
[02:14] <igc> lifeless: I'll look now
[02:15] <igc> lifeless: no email reply through yet btw
[02:17] <lifeless> poolie: I've looked at it
[02:17] <poolie> i was not disagreeing with igc's comment about naming, btw
[02:18] <poolie> i have not seen your reply yet
[02:18] <lifeless> poolie: its already +2 AFAICT, but it looks fine to me, I agree with your comment on the review
[02:20] <lifeless> poolie: igc: the reply just got through now
[02:20] <igc> just got it
[02:23] <lifeless> can we get a captcha on the wiki add-user page ?
[02:23] <igc> so lifeless, if you add a comment above the call to add_lines_with_ghosts explaining what it's being called instead of add_lines, I'd appreciate it
[02:23] <igc> s/what/why/
[02:23] <lifeless> igc: so there are two reasons;
[02:23] <lifeless> one is that its the right api to use, because it supports committing with ghosts
[02:23] <igc> I got the reasons ...
[02:23] <lifeless> the other is that its a slightly cheaper call
[02:23] <igc> I just want it in the code
[02:23] <lifeless> sure
[02:23] <lifeless> I'm just noting that I didn't mention the former in the patch at all
[02:24] <igc> ok
[02:24] <igc> poolie: do you need more feedback on Vincent's patch?
[02:24] <lifeless> It seems a strange thing to comment on is all I guess
[02:25] <lifeless> kindof like saying 'we use .readlines() because it gives us the file lines with \n'
[02:25] <lifeless> its true, but redundant
[02:25] <igc> not IMO ...
[02:26] <igc> the name _with_ghosts suggests ghosts :-)
[02:26] <lifeless> its a convention across the code base for apis that support ghosts
[02:26] <lifeless> and this api supports ghosts
[02:27] <igc> ok - merge it and we'll move on
[02:28] <igc> ping me when that's done and I'll call you
[02:28] <igc> poolie: anything else you want from me before I call lifeless?
[02:29] <lifeless> did my knits patch seem ok for 0.91 ?
[02:30] <igc> lifeless: I didn't review it because abentley had concerns on IRC
[02:31] <igc> if those concerns are resolved, I'll look closer
[02:31] <igc> it looked ok at first glance yesterday
[02:32] <lifeless> I don't think they are resolved
[02:32] <lifeless> abentley: care to reply to my knits patch ?
[02:32] <lifeless> igc: the patch is away with a comment added
[02:33] <igc> thanks
[02:35] <lifeless> so ring anytime
[02:37] <igc> Right now. Some quick feedback on your other patch emailed just now.
[02:55] <ubotu> New bug: #138787 in bzr "revspec paths don't interpret user refs" [Low,New]  https://launchpad.net/bugs/138787
[03:13] <lifeless> [03:13] <lifeless> --- bzrlib/repofmt/pack_repo.py 2007-09-09 23:45:05 +0000
[03:13] <lifeless> +++ bzrlib/repofmt/pack_repo.py 2007-09-10 07:11:39 +0000
[03:13] <lifeless> @@ -1032,7 +1032,8 @@
[03:13] <lifeless>          return knit.KnitVersionedFile('text:' + file_id, None,
[03:13] <lifeless>              None,
[03:13] <lifeless>              index=knit_index,
[03:13] <lifeless> -            access_method=self.repo._text_knit_access)
[03:13] <lifeless> +            access_method=self.repo._text_knit_access,
[03:13] <lifeless> +            factory=knit.KnitPlainFactory())
[03:13] <lifeless> igc: ^
[03:17] <igc> thanks lifeless
[03:19] <lifeless> like I say, trivial :)
[04:42] <lifeless> poolie: ping
[04:43] <poolie> pong
[04:43] <lifeless> you seem to be marking bugs as fix released before they are in a release
[04:43] <lifeless> our convention documented on the wiki is fix committed until its actually in a release, isn't it ?
[04:44] <poolie> is it?
[04:44] <poolie> i thought we had decided to mark them FR when they were merged, because there is no way to bulk update them
[04:44] <lifeless> oh, I'm confused
[04:44] <lifeless> yes you are right, bzr.dev == FR
[04:45] <poolie> i would much prefer to do it the other way but it's not feasible atm
[04:45] <poolie> well, i guess we could write a script that would generate status-changing mails
[04:45] <fullermd> Is it a bug that bzr rm'ing a file/dir with conflicts doesn't resolve the conflicts (nor does 'resolve' auto-resolve them)?
[04:45] <poolie> yes, but it may not be a known bug
[04:46] <poolie> fucking spammers
[04:47] <lifeless> you can update many bugs with one mail
[04:47] <lifeless> poolie: can we get a captcha on the wiki user creation page ?
[04:47] <fullermd> Mmm.  Don't see it.
[04:47] <poolie> s/mails/mail
[04:48] <fullermd> Search does bring bug 5140 though.  I'm not sure that should be on bzr...   bzr-email, maybe.
[04:48] <ubotu> Launchpad bug 5140 in bzr "Merge emails blow my mind" [Wishlist,Confirmed]  https://launchpad.net/bugs/5140
[04:49] <lifeless> poolie: also, I think we want more grnularity than lp offers
[04:50] <Verterok> bitmonk: I tried with Jython and Jythonx (now dead). but no even closer to do a; import bzrlib :(
[04:51] <bitmonk> worth a try with pypy, i suppose..
[04:51] <lifeless> as if bzr isn't slow enough already
[04:53] <poolie> lifeless, more granularity in bug state?
[04:53] <poolie> or ironpython
[04:54] <lifeless> poolie: yeah, fix in my branch, fix in bzr.dev, fix in tarball
[05:01] <fullermd> Funny.  You can notice how much faster commit has gotten the last few versions, even on tiny branches, when writing and testing bug reproduction scripts.
[05:01] <fullermd> Obviously, we need more bugs, so the speed improvements are visible   :] 
[05:04] <beuno> anyone up to helping me solve a small glitch in a feature I'm trying to add to xml-output plugin?    I want to capture some of the output from 'bzr missing' to put it into the XML, but I can't seem to figure out how to capture the 'Using last location:' bit
[05:05] <ubotu> New bug: #138802 in bzr "tag deletion does not propagate" [Medium,Triaged]  https://launchpad.net/bugs/138802
[05:05] <ubotu> New bug: #138803 in bzr "rm'ing conflicted files doesn't resolve conflicts" [Undecided,New]  https://launchpad.net/bugs/138803
[05:05] <fullermd> beuno: I would presume it's going to stderr...
[05:07] <beuno> fullermd, sorry if the questions are a bit too obvious, I'm still finding my way around python (and bzr code). I'd have to capture that differently then I capture the revision info?  (I'm currently wraping that fine)
[05:10] <fullermd> Oh, well, I dunno anything about catching it in python.  There's probably a standard arg for however you capture stdout to cram stderr in with it, or at least a way to access the fd.
[05:11] <lifeless> beuno: how are you hooking into the command ?
[05:13] <beuno> lifeless, builtins.cmd_missing
[05:13] <beuno> http://codebrowse.launchpad.net/~beuno/bzr-xmloutput/xml-beuno/annotate/argentina%40gmail.com-20070902215621-wiq1c4ssihnfestz?file_id=__init__.py-20070406035637-ac26bagfmjgniyko-1
[05:13] <beuno> line 96 is the function
[05:14] <beuno> or class  :D
[05:17] <lifeless> ok
[05:17] <lifeless> the thing you want to output is not partof the log
[05:17] <lifeless> you just need to do it yourself
[05:18] <poolie> fullermd, thanks for the bug updates
[05:18] <lifeless> you will probably want to file a patch for bzrlib to make it easier
[05:18] <lifeless> e.g. a helper method to factor out that logic
[05:19] <poolie> lifeless, i crave your review of my tag bug patch
[05:19] <beuno> lifeless, I was suspecting that was where it would en up...  :/      Because antoher option would be not to display that for now, since it breaks the XML, but do I have a way to do that?
[05:20] <lifeless> beuno: yes, copy the body of the bzrlib method and change it
[05:20] <lifeless> beuno: I recommend giving us a patch ;)
[05:20] <poolie> lifeless, trust you to know of the http Warning header
[05:20] <lifeless> poolie: ok, will lunch first
[05:20] <lifeless> poolie: :)
[05:20] <poolie> i have never encountered such a athing
[05:20] <beuno> lifeless, argh, you're going to make me fly away into crazy bzr/python world for the next two days...
[05:20] <lifeless> I'm not aware of any client that actually shows it; though I haven't tested in about 3 years
[05:21] <beuno> I never pick the easy stuff...   :p
[05:21] <lifeless> beuno: you could start by filing a bug
[05:21] <lifeless> maybe a python dev will be kind to you
[05:21] <poolie> lifeless, let's talk after that? i might go for a ride in the meantime
[05:21] <lifeless> k
[05:22] <beuno> lifeless, ok, I'll file a bug and try and approach it until I run everyone here out of patience   :D
[05:23] <lifeless> poolie: ok
[06:01] <sabdfl> evening all
[06:01] <beuno> evening sabdfl
[06:02] <lifeless> hiya
[06:05] <igc> evening sabdfl
[06:06] <beuno> lifeless, I'm going to go ahead and reimplement missing in the plugin itself, and then see how we can improve it in bzrlib itself
[06:17] <lifeless> poolie: ring me at your convenience
[06:24] <lifeless> igc: repository branch fixen pushed
[06:24] <lifeless> 2759
[06:24] <igc> great - thanks
[06:25] <lifeless> not entirely failure free;
[06:25] <lifeless> but enough to benchmark reliably again
[06:25] <igc> understood
[06:58] <abentley> lifeless: I've decided to abstain.  If someone else reviews it and decides the tradeoff is worth it, that's fine by me.
[07:00] <ubotu> New bug: #138812 in bzr "no tag --local operation" [Undecided,New]  https://launchpad.net/bugs/138812
[07:11] <lifeless> abentley: did any of the compromises we chatted about seem reasonable ?
[07:13] <abentley> Enabling the tests during test suite runs seems like an improvement.
[07:14] <keir> lifeless, does the transport layer buffer reads automatically? when i read the preamble, i'm reading in 2 chunks, then finally a larger chunk
[07:14] <keir> if the transport would go ahead and grab 4k after the first read, and then i didn't have to deal with buffering that data, that would be great.
[07:14] <abentley> That would mean that a careful tester would catch bugs in this area.
[07:15] <abentley> I think I could live with that.
[07:16] <lifeless> keir: transports have no buffering in general
[07:17] <keir> so i have to implement my own buffering layer?
[07:17] <lifeless> so if you want 4K + preamble, guess at the largest size of preamble and read preamble + 4K
[07:17] <lifeless> well
[07:17] <lifeless> buffering is one way of doing it
[07:17] <lifeless> but buffering on local disk has very different tradeoffs to dealing with a tcp connection
[07:18] <keir> alright. for now i'll just leave it. 1 extra round trip per index is not a big deal
[07:18] <keir> i have single-item get working with caching
[07:19] <keir> but it does a single readv() on every miss
[07:19] <keir> so next i'm going to do fetch-many-keys lookup, which iterates between passes which readv() blocks, and descends them
[07:20] <abentley> keir: On your structure, is it expensive to determine that a key is not present?
[07:21] <keir> no different than if it is
[07:21] <keir> actually, it may be cheaper
[07:21] <keir> depending on the key
[07:21] <keir> but i suspect in most cases checking if a key is present is the same as if it's there
[07:21] <keir> for most packs, i expect it to be only one tree lookup + another 4k block fetch
[07:22] <keir> abentley, is that a very common check?
[07:24] <abentley> I'm not sure.  I just realized it wasn't something we'd discussed.
[07:30] <keir> generators are wacky. i think i'm going to use them to accumulate read vectors. are they slow?
[07:36] <fullermd> Oh look, no useful header to filter launchpad's blueprint mailings on.
[07:39] <abentley> keir: generator iteration is faster than function calls, but slower than a tight loop.
[07:40] <abentley> They are typically a good choice, but if every last drop of performance matters, doing it all in a loop may be better.
[07:40] <abentley> As always, profile.
[07:42] <keir> in the end, i'm using recursion *ducks!*
[08:24] <lifeless> poolie: done
[08:32] <lifeless> poolie: your branch is made
[08:36] <Stevage> hello everyone
[08:36] <Stevage> could someone answer a couple of questions for me?
[08:45] <beuno> Stevage, sure, we'll try
[08:46] <Stevage> coolies - I'm evaluating using bzr for work
[08:46] <Stevage> is it possible to checkout a single file, and not a whole directory?
[08:47] <lifeless> ciao
[08:47] <Stevage> eg, file /docs/doc1.txt - I just want to checkout doc1.txt into a normal directory
[08:47] <lifeless> no but you can cat it - bzr cat url/docs/doc1.txt
[08:48] <igc> lifeless: ping
[08:48] <igc> lifeless: some quick Qs re your branch ...
[08:49] <igc> content_summary is always returning a sha of None ...
[08:49] <lifeless> ring my mobile in 2 mintues please
[08:49] <igc> because it's running the one in workingtree, not workingtree4
[08:49] <igc> cool
[08:50] <Stevage> ah interesting
[08:50] <Stevage> so I can do a kind of one way check out
[08:50] <Stevage> but then not check any changes back in
[08:55] <Stevage> ok next question: say I have a file (versions.h) that is used by two different projects, and should be checked out by both of them. how can I set that up?
[09:02] <jamesh> Stevage: "bzr cat" is roughly equivalent to "cvs update -p"
[09:07] <jamesh> Stevage: for the second question, Bazaar's answer would probably be nested trees
[09:08] <jamesh> the shared files would be in their own branch, and that branch would be nested in the two projects' branches
[09:08] <Stevage> how do I nest?
[09:09] <Stevage> I tried doing it with a checkout, but those files didn't get added to the parent branch
[09:09] <Stevage> as in, I created /shared and /proj1 and in /proj1 did bzr checkout ../shared
[09:09] <Stevage> so then I have /proj1/shared - good. but when I update /work1 which is bound to /proj1, it didn't pull in /shared
[09:12] <jamesh> I am not sure how much of the nested tree stuff is in mainline yet
[09:13] <jamesh> so at present you need to do it manually (this will likely change in the future)
[09:15] <Stevage> yeah looking at ConfigManager atm
[09:15] <Stevage> I'm on windows, so looks like a pain to build
[09:15] <jamesh> or use ConfigManager
[09:15] <jamesh> Stevage: the version of ConfigManager you want is written in Python
[09:16] <jamesh> grab the branch listed here: http://bazaar-vcs.org/3rdPartyDownloads
[09:16] <Stevage> yeah?L
[09:16] <Stevage> that one is C++
[09:16] <Stevage> with a python wrapper
[09:17] <jamesh> the branch contains both the old C++ implementation (which doesn't support bzr, iirc) and the new Python implementation
[09:18] <Stevage> oh yes there is some code in /lib
[09:18] <Stevage> have you tried setting it up on windows?
[09:18] <jamesh> nope.
[09:19] <jamesh> do "bzr branch http://www.robertcollins.net/config-manager/trunk/ config-manager" to download it
[09:19] <jamesh> the files you see when browsing it in a web browser are likely out of date
[09:20] <Stevage> sweet
[09:22] <Stevage> will I need to install python then?
[09:22] <Stevage> bzr comes with the python dll but that's all I have
[09:32] <jamesh> Stevage: no idea.
[09:32] <jamesh> Stevage: but probably.
[09:34] <Stevage> ok
[09:34] <Stevage> might actually be simpler for me to just hack up a couple of batch files that do the job
[09:35] <Stevage> do you know if it's possible to commit several files at once, specifying individual commit messages for each one?
[09:37] <jamesh> Stevage: commits are tree wide, so it isn't possible to do separate messages for separate files within a commit
[09:46] <fullermd> Is there some reason we don't have a Branch.open_containing_from_transport?
[09:47] <poolie> fullermd, it would seem reasonable to have one
[09:48] <fullermd> It'd need direct tests, wouldn't it...
[10:09] <igc> night all
[10:10] <matkor> Hi !
[10:10] <matkor> >>> local_branch.missing_revisions(parent_branch)   ->    bzrlib.errors.DivergedBranches: These branches have diverged. Use the merge command to reconcile them
[10:11] <matkor> How can I get information what revisions are missing on both branches ? TIA
[10:12] <spiv> matkor: bzr missing
[10:13] <spiv> matkor: you can see the implemenation of that command in bzrlib.builtins.cmd_missing
[10:14] <matkor> spiv: Thanks
[10:16] <vila> fullermd: the reason should be historical, the _from_transport methods began to be added when we tried to avoid multiple connections
[10:17] <vila> fullermd: where do you encounter the need for it ?
[10:24] <matkor> Can I browse recent bzr source on web somewhere ? http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.builtins.cmd_missing.html does not give hints and I have only pyo/pyc files installed ...
[10:24] <mwh> matkor: http://codebrowse.launchpad.net/~bzr/bzr/trunk/files
[10:25] <matkor> mwh: thanks !
[10:38] <fullermd> vila: Well, I was trying to fix up pull to be more forgiving, but that's sounding like a lot bigger bite than I can chew.
[10:40] <vila> fullermd: bug ref ? More forgiving about ? (can't relate that to a recent topic, please refresh my memory :)
[10:41] <fullermd> Well, just what you'd expect an open -> open_containing switch; more forgiving about being given a location other than a branch root.
[10:41] <fullermd> No bug ref or topic I recall; just something I ran into earlier tonite and thought (erroneously, perhaps) might be simple enough that I could pull through.
[10:42] <matkor> Is remote_branch.lock_read() expensive ? 2) What may happen if I operate over unlocked branch ? 3) How it is done over http ?
[10:44] <vila> fullermd: hmm, Branch already have an open_containing method
[10:45] <vila> this method already offers a 'possible_transports' parameter so _from_transport should not be needed
[10:46] <fullermd> Well, pull uses open_from_transport() now.  I'm far too wildly unknowledgeable about the differences between funct...  er, methods, and data struc.... er, objects, to have any clue how/if I can turn one into another.
[10:48] <vila> fullermd: b.open_from_transport(location_transport) ~= b.open_containing(location, possible_transports=[location_transport] )
[10:49] <vila> fullermd: for fuzy values of ~=
[10:49] <fullermd> Right, see, I have no business being involved in fuzzy   :p
[10:49] <fullermd> I don't have any business being involved in sharp and clear either, but I like living on the edge.
[10:49] <vila> even with a single 'z' which implied less fuzzyness ? :D
[10:52] <fullermd> Sounds to me like having one eye poked out instead of two   :|
[11:11] <fullermd> Holy squat, bundle is fast now.
[11:21] <matkor> Hmm. One can't add '@" to info_dialog content message ?
[11:22] <dato> AfC: re the scm-gnome thread, I think it'd be better to give each project an independent shared repo, where trunk and branches are kept.
[11:23] <AfC> dato: yeah, duh that makes sense - above that level, revisions are never going to be shared
[11:24] <dato> right.
[11:24] <AfC> [at least, not until we go WAY further down the nested branch and my project uses your project's sources paths] 
[11:24] <AfC> dato: [please do point that out in an email] 
[11:24] <dato> AfC: okay
[11:54] <matkor> jelmer: Could you please review and merge olive-gtk bugfix from https://code.launchpad.net/~matkor/bzr-gtk/trunk-matkor ? TIA
[01:06] <jelmer> matkor: I'll have a look this evening
[01:09] <matkor> jelmer: Szilvester is testing it right now, but more eyeballs - the better ...
[01:09] <Enquest> If I want to delete a branch in my repo how do I do this?
[01:10] <Enquest> rm -R branch ???
[01:10] <dato> Enquest: yes, knowing that revisions belonging to that branch will stay unreferenced in the repo
[01:10] <Enquest> dato and is there a more clean way ??
[01:11] <Enquest> I made some big mistakes starting a branch... And want to start a new
[01:11] <dato> not at the moment.
[01:11] <Enquest> a new branch same name
[01:11] <dato> Enquest: but I think rm -r it's okay, unless you committed some very big files or something.
[01:11] <Enquest> so rm -R is realy ok!
[02:07] <jelmer> matkor: I don't run olive myself but am happy to review
[02:17] <mwhudson> crap
[02:19] <mwhudson> jelmer: bzr-svn just did this to me http://rafb.net/p/FGNzoK46.html
[02:19] <asabil> hi all
[02:20] <asabil> what is the bzr commit --fixes for ?
[02:20] <asabil> is it for bugzilla integration ?
[02:21] <Odd_Bloke> asabil: Launchpad integration, certainly.  I don't know about Bugzilla.
[02:21] <asabil> ok thanks
[02:22] <luks> it isn't integrated with launchpad at the moment, though
[02:24] <luks> http://doc.bazaar-vcs.org/latest/en/user-guide/bug_trackers.html
[02:26] <Enquest> how do I rename a dir with bzr
[02:26] <luks> bzr mv
[02:27] <Odd_Bloke> Enquest: Or if you've already renamed it, 'bzr mv --after'.
[02:29] <Enquest> thanxs
[03:09] <AfC> Enquest: (you use that to rename {,after} files as well)
[03:10] <Enquest> thxs
[03:10] <AfC> Enquest: watch out for moving symlinks though... as I recall, it might choke on those. You might have to remove/add still. [Maybe that's been fixed] 
[03:11] <Enquest> no symlinks in this
[03:11] <Enquest> I'm just starting with bazaar
[03:13] <jelmer> mwhudson: hmm, will have a look this evening
[03:15] <mwhudson> jelmer: okidoke
[03:15] <mwhudson> jelmer: path is a bytestring path with non-ascii characters btw
[03:17] <mwhudson> 'pypy/extradoc/talk/22c3/speaker-beatriced\xc3\xbcring.txt'
[03:17] <mwhudson> in fact
[03:18] <mwhudson> (which looks like utf-8 to me)
[03:32] <matkor> During bzr update of checkout of branch: sftp: I have to provide password three times ... is it bug ?
[03:34] <AfC> Hm. In bad old CVS land, if you have a repository with 20 modules, and you do a change (simple refactoring, say) in each one, does that imply the need to do 20 independent commits? I believe so. Anyone remember?
[03:35] <LeoNerd> Noy really
[03:35] <LeoNerd> *Not
[03:35] <LeoNerd> CVS considers each file individually, nothing bigger.
[03:35] <LeoNerd> If you've changed 20 files, you need to commit 20 files.
[03:35] <LeoNerd> Either 20 individual "cvs commit" commands, or one, or whatever.
[03:38] <AfC> LeoNerd: yeah yeah... but if you're in a given checkout, and you type naked `cvs commit` it storms off recursively, right, same as every other VCS tool. But there's no `cd .. ; cvs commit` that would recurse across 20 directories that happen to be modules from the same repository, is there?
[03:38] <LeoNerd> Not normally, no...
[03:38] <LeoNerd> I don't know about most people, but I have a whole tonne of wrapper scripts for that though
[03:38] <LeoNerd> cvs eachroot commit -m "Here's some changes"     would do that for me ;)
[06:46] <corporate_cookie> I'm having some issues installing bzr 0.90 The problem lies with importing paramiko which i've recently attempted to install. I downloaded paramiko's src and ran python setup install  ..which executes without error. However when I run paramiko's test.py i get an error.  I also get an error when I run python -c "import paramiko"
[06:46] <corporate_cookie> ...this is on a Red Hat ES4 server running Python 2.5.1 and paramiko 1.7
[06:46] <corporate_cookie> any ideas ?
[06:46] <NfNitLoop> corporate_cookie: on what platform?  ..
[06:47] <NfNitLoop> aah.
[06:47] <NfNitLoop> do you have pycrypto installed?
[06:47] <corporate_cookie> i do
[06:47] <corporate_cookie> python -c "import Crypto"  yields no error
[06:47] <NfNitLoop> what is the "problem" you get when you do python -c import paramiko?
[06:48] <corporate_cookie> File "<string>", line 1, in <module>
[06:48] <corporate_cookie>   File "/usr/local/lib/python2.5/site-packages/paramiko/__init__.py", line 69, in <module>
[06:48] <corporate_cookie>     from transport import randpool, SecurityOptions, Transport
[06:48] <corporate_cookie>   File "/usr/local/lib/python2.5/site-packages/paramiko/transport.py", line 36, in <module>
[06:48] <corporate_cookie>     from paramiko.compress import ZlibCompressor, ZlibDecompressor
[06:48] <corporate_cookie>   File "/usr/local/lib/python2.5/site-packages/paramiko/compress.py", line 23, in <module>
[06:48] <corporate_cookie>     import zlib
[06:48] <corporate_cookie> (pardon the mess)
[06:49] <NfNitLoop> is that all of it?   The last lines would probably be the most relevant.
[06:49] <dato> seems some line is missing
[06:49] <corporate_cookie> pardon me ... the last line is
[06:49] <corporate_cookie> ImportError: No module named zlib
[06:49] <NfNitLoop> well, there ya go.
[06:49] <corporate_cookie> which is also strange ..as zlib is up2date
[06:50] <NfNitLoop> Oh.
[06:50] <NfNitLoop> Yeah, that is strange.
[06:50] <thatch> did you build python yourself since it's in /usr/local ?
[06:50] <NfNitLoop> wait, the zlib rpm?   you probably want something like python-zlip.
[06:50] <dato> corporate_cookie: the zlib module is provided by python itself
[06:50] <NfNitLoop> Aaah.
[06:50] <dato> corporate_cookie: so something's broken in your python instalation
[06:50] <thatch> ...when you compile python with --with-zlib
[06:50] <dato> thatch: good catch
[06:51] <corporate_cookie> ah .. i did not compile python with the --with-zlib option
[06:51] <corporate_cookie> thanks : )
[09:02] <asabil> hi all
[09:03] <asabil> how do you benchmark bzr ?
[09:15] <Odd_Bloke> asabil: How do you mean?  You could use the 'time' command if you're running GNU/Linux...
[09:16] <asabil> Odd_Bloke: I wanted to run the benchmarking test suite
[09:17] <Odd_Bloke> asabil: OK, I'm not sure how to do that.
[09:17] <Odd_Bloke> Sorry. :(
[09:17] <asabil> bzr selftest --benchmark
[09:30] <asabil> is it possible to run only the commit benchmarking ?
[09:31] <Odd_Bloke> asabil: Try 'bzr selftest --benchmark commit'?
[09:31] <Odd_Bloke> That's how you'd run only the commit tests...
[09:31] <asabil> :D thanks
[09:32] <asabil> I didn't see that
[09:47] <james_w> siretart: hi. Are you around?
[09:48] <siretart> james_w: yes. how you're doing?
[09:49] <james_w> good thanks. How are you?
[09:49] <siretart> fine, too! (well a bit tired from work, but anyway..) :)
[09:50] <siretart> hmm.. bzr: ERROR: Repository KnitRepository('file://....') is not compatible with repository SvnRepository('svn+ssh://...')
[09:50] <siretart> what repository would be compatible?
[09:50] <james_w> siretart: may I /msg you, my question is not really on topic for this channel.
[09:50] <siretart> sure!
[09:51] <james_w> as for the error have you just updated bzr-svn to the .4 branch?
[09:51] <siretart> I just upgraded bzr and bzr-svn, not the branch
[09:51] <luks> siretart: `bzr upgrade --dirstate-with-subtree` on the local repo is probably what you need
[09:52] <james_w> and probably bzr svn-upgrade as well, but this is a watershed change for the branch.
[09:52] <james_w> though with-subtree is as well I think.
[09:53] <siretart> hm. I see
[09:53] <siretart> this means with the newer bzr-svn the dirstate-with-subtree repo format is mandatory?
[09:54] <luks> yes, afaik
[09:54] <james_w> yeah I believe so. I think jelmer added svn:externals support using subtrees, but I guess it is mandatory rather than as-needed.
[09:54] <NfNitLoop> siretart: No, but if someone has created a repository with that dirstate, you have to use it to be compatible.
[09:54] <NfNitLoop> Oh, yeah, it's mandatory with bzr-svn.
[10:11] <asabil> can a bzr plugin add some option flags to an existing command ?
[10:12] <beuno> asabil, sure it can
[10:12] <luks> by overwriting the original command
[10:12] <beuno> yeap, you can override the current one
[10:12] <asabil> let's say I want to add --with-feature-x to the existing commit command
[10:12] <asabil> is that possible ?
[10:12] <beuno> asabil, yeap
[10:12] <asabil> awesome
[10:13] <beuno> you could probably check if that parameter exists, and run X function, and if it doesn't, run the original
[10:13] <beuno> that's what we do on the xmloutput plugin
[10:14] <ddaa> Is there a way to create BranchReference with bzrlib without opening it?
[10:14] <ddaa> I mean, a branch reference on disk, not the object.
[10:18] <james_w> ddaa: I don't see such an object in bzrlib.
[10:19] <ddaa> bzrlib.branch.BranchReferenceFormat
[10:19] <ddaa> there's actually no BranchReference object, it's just a format
[10:20] <ddaa> as I said, I do not care about the actual object, but about the filesystem data.
[10:20] <james_w> ah, they should be easy to create.
[10:22] <ddaa> my problem is that BranchReferenceFormat.initialize opens the created reference
[10:22] <ddaa> and for the Launchpad test suite I need to create branch references that point to example.com...
[10:23] <james_w> ah, ok. Sorry, I thought you just wanted to create a one-off reference with your editor.
[10:23] <ddaa> I know how to do this :) I wrote the "bzr switch" command.
[10:24] <james_w> I guess you will have to carry a subclass, or ask for a initialise_without_opening method.
[10:24] <ddaa> right
[10:24] <ddaa> I wanted to check first before filing a bug.
[10:25] <james_w> well, I can't speak for the project, but the code offers no way to do so. I would go ahead and file it.
[10:25] <ddaa> creating a subclass that overrides open() for this purpose is NOT going to pass the Launchpad code review :)
[10:26] <ddaa> Thanks.
[10:58] <lifeless> ddaa: bzrdir.get_branch_reference?
[10:58] <lifeless> ddaa: didn't we have this discussion already?
[11:00] <asabil> is there any bookmarking system for bzr branches ?
[11:01] <asabil> so that I can give names to the different pushing locations ?
[11:02] <asabil> something like
[11:03] <asabil> bzr push location://stable-branch ?
[11:08] <james_w> asabil: no that's not available.
[11:08] <asabil> ok thanks
[11:08] <asabil> you suggest I implement that as a plugin ?
[11:09] <james_w> It shouldn't be too hard to add. You could file a bug if there is not one already.
[11:09] <james_w> a plugin would also be easy.
[11:09] <asabil> ok :)
[11:09] <james_w> I can give you some pointers if you would like.
[11:09] <NfNitLoop> I'd love it if someone did that as a plug-in.
[11:09] <asabil> yeah, that would definitely help
[11:09] <lifeless> ddaa: meh, sorry, I see - you want to create a pointer to a non-existent reference.
[11:10] <lifeless> ddaa: you could use a mock branch to do that
[11:10] <lifeless> ddaa: subclass branch to give you a branch you can construct with a url that you can't normally open
[11:11] <ddaa> I believe there was a specific test for which I needed to go through the whole stack, not use a mock.
[11:11] <lifeless> you can use the mock to setup the test
[11:11] <ddaa> but I cannot remember which right now and I am off work
[11:11] <ddaa> uh
[11:12] <lifeless> ofter that you will have a regular branch reference on disk and not be using your mock
[11:12] <lifeless> so it will fail to open the reference if you try to open it
[11:12] <lifeless> etc. but as you say, you're done for the day.
[11:13] <ddaa> I cannot see how you can use a mock object to make BranchReferenceFormat create a reference that it cannot open...
[11:14] <ddaa> especially because it does "real_bzrdir = bzrdir.BzrDir.open(location)"
[11:14] <lifeless> hmm
[11:15] <lifeless> I suggest, if you don't want to talk work after-hours, that you drop a mail to the list and we can have an async discussion on this
[11:15] <ddaa> I'll look at the code again it might be that I do not need to create unopenable branch reference anymore
[11:16] <ddaa> since I needed to create a proxy method for get_branch_reference anyway for testing.
[11:16] <ddaa> Thank for making me question my assumptions :)
[11:17] <lifeless> lol, np
[11:20] <lifeless> abentley: ping