[00:25] <lifeless> jelmer: what deltas does svn use?
[00:25] <lifeless> ideally you can provide an adaptor to allow you to use insert_record_stream
[00:26] <jelmer> it's byte-based
[00:26] <lifeless> ok
[00:26] <lifeless> so add_lines does get_lines(), applies delta, does a diff(), writes the text out
[00:27] <jelmer> basically it's a list of instructions like "insert this sequence of bytes at offset X"
[00:27] <lifeless> so we're doing twice as many get_lines() as needed
[00:27] <jelmer> ah, cool
[00:27] <lifeless> this will be nontrivial for you
[00:27] <lifeless> but look at insert_record_stream
[00:27] <lifeless> conceptually, you would define a new record type ('svn-delta')
[00:28] <lifeless> and then look at KnitVersionedFile.insert_record_stream to teach it how to coerce that to a more useful form
[00:28] <lifeless> the key thing is that in that function you can e.g. emit a knit record directly (because you may know what lines were altered, or something similar)
[00:30] <jelmer> hmmok
[00:30] <lifeless> some assembly will be required, but the goal of the interface is to permit this - as the first external user, you'll have to poke things to line up more
[00:30] <jelmer> I'll file a bug about this, it's something nice to look at in the future but I'd like to get 0.5 out at all first
[00:31] <AfC> lifeless: batteries not included
[00:35] <lifeless> jelmer: yes, for sure
[01:36] <TheMuso> c
[03:26] <Toksyuryel> Is a feature like this planned for bzr? 'cause that would be pretty awesome http://tech.slashdot.org/tech/08/12/04/1625226.shtml
[03:42] <Rolly> Looks interesting
[03:46] <mneptok> KERNEL 2.6.35 = AWESOME QUALITY!!!! 10/10!!! PLZ SEED! (p.s. doesn't play on my 286. i have VLC).
[04:39] <lifeless> Toksyuryel: I don't know of anyone working directly on it; doing dissemination based networking is probably better down further down the stack so that mor ethings can benefit, but - if someone gets the bug and haks it up, the more the merrier
[04:41]  * Toksyuryel nods
[07:12] <vila> hi all
[07:33] <lifeless> hi vila
[07:42] <lifeless> beuno: yo
[07:43] <beuno> lifeless, hey hey
[07:43] <lifeless> so
[07:43] <lifeless> I want to show you a little about using the profiling middleware
[07:43] <lifeless> cause it just confused me :)
[07:43] <lifeless> are you crashing yet, or got a few ?
[07:44] <beuno> I have a few. IRC or RL?
[07:44] <lifeless> IRC is fune
[07:44] <lifeless> *fine*
[07:44] <beuno> ok, sjoot
[07:44] <beuno> er
[07:44] <beuno> shoot
[07:44] <lifeless> to start with, get a browser with lh running against something that is indexed
[07:44] <lifeless> svn is best, but you probably haven't pulled all the branches etc yet
[07:45] <lifeless> so bzr.dev or lh itself or something, it sfine
[07:45] <beuno> I've got LH on LH indexed and running
[07:45] <lifeless> kay
[07:45] <lifeless> type something into the search box without hitting enter
[07:45] <lifeless> just to get completion results showing
[07:45] <lifeless> now, stop lh
[07:45] <lifeless> and run it with --profile
[07:46] <lifeless> then hit the down arrow key once in the browser, which will cause a single refresh of the completion results
[07:46] <lifeless> stop lh
[07:46] <lifeless> and run kcachegrind 1-stats.callgrind
[07:46] <beuno> http://paste.ubuntu.com/80740/
[07:46] <beuno> traceback!
[07:47] <lifeless> you have an old bzr-search, I fixed that bug
[07:47]  * beuno pulls
[07:47] <lifeless> TMI
[07:48] <beuno> hrm
[07:48] <beuno> pulling didn't do it
[07:49] <beuno> of course, it helps if I pull the right thing...
[07:50] <lifeless> what did you pull?
[07:50] <beuno>   File "/var/lib/python-support/python2.5/paste/httpserver.py", line 166, in wsgi_start_response
[07:50] <beuno>     assert 0, "Attempt to set headers a second time w/o an exc_info"
[07:50] <beuno> AssertionError: Attempt to set headers a second time w/o an exc_info
[07:51] <lifeless> heh
[07:51] <lifeless> well hit down again, until it works
[07:51] <beuno> I pulled bzr-search, but not the one that I'm using for bzr
[07:51] <lifeless> then cachegrind the one that worked
[07:52] <beuno> ok, nothing seems to be working
[07:52] <beuno> maybe I should stop doing it on a checkout
[07:52] <lifeless> just do bzr unbind
[07:52] <lifeless> you canbzr bind later
[07:53] <beuno> ok, now
[07:54] <beuno> let's run it through kcachegrind...
[07:55] <beuno> which I don't have, and will take 22 minutes to get with all it's deps.......
[07:55] <lifeless> heh
[07:55] <lifeless> get it, you needs it
[07:56]  * beuno stares at apt while it downloads
[07:56] <lifeless> give it tha ol evil eye
[07:56] <lifeless> ok, so let it install, I show you tomorrow
[07:57] <beuno> kei
[07:57] <beuno> it's really insisting on taking those full 22 minutes
[07:57] <beuno> so it's downloading
[07:57] <beuno> and I haave that callgrind file
[07:58] <beuno> so we can have fun on the bus tomorrow
[07:58] <lifeless> :>
[07:58] <lifeless> I have a question
[07:58] <lifeless> what are 'apps'
[07:59] <beuno> that's a question for mwhudson. He chose the name, and I just made it work in my head. To me, it's the paste stuff.
[07:59] <lifeless> ok
[08:00] <lifeless> cause its the branch app that appears to be chewing up time
[08:00] <beuno> that's odd, it shouldn't really do much
[08:01] <lifeless> it calls get_history unconditionally AFAICT
[08:01] <beuno> which should have a nice cache
[08:02] <beuno> both internal and sqlite
[08:02] <lifeless> profile -> trasnlogger -> httpexceptions ->apps.error ->apps.filesystem ->apps.filesystem->apps.branch->search
[08:03] <lifeless> we call last_revision twice
[08:03] <beuno> ah, hm
[08:03] <lifeless> it takes 56% of the time
[08:03] <beuno> that's bad
[08:03] <lifeless> ciao!
[08:04] <lifeless> see you on ze bus
[08:04] <beuno> :)
[08:04] <beuno> have a good night
[10:49] <nbjayme> hello all. greetings from the philippines!  did launchpad change the port number of the bzr+ssh access? i keept on having a Connection timeout error on port 22. :(
[10:52] <Peng_> nbjayme: No, it didn't.
[10:54] <Peng_> nbjayme: You might find #launchpad more helpful.
[10:54] <nbjayme> thanks Peng_.
[11:58] <nbjayme> my clumsiness.... ﻿bzr push sftp://bazaar.launchpad.net <---- is the right url.
[13:26] <jam> vila: ping
[13:27] <vila> jam: pong
[13:29] <jam> good morning
[13:29] <jam> Any chance you could try to review: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C493709CC.4090307%40arbash-meinel.com%3E
[13:29] <jam> I mentioned it to Aaron yesterday, but he hasn't commented.
[13:29] <jam> It seems it is a fairly serious regression in stacked repositories
[13:30] <jam> so I'd like to land it before 1.10
[13:30] <jam> Also, I wanted to chat with someone whether I should be releasing 1.10-final today, or doing rc2 instead ?
[13:30] <jam> (Given that bug)
[13:32] <vila> Re-reading (but from last read you got at least a BB:I-like-the-topo-order-so-go-go-go :)
[13:33] <vila> You have one import pdb; pdb.set_trace()
[13:35] <vila> jam: My feeling there (having read the thread as it came in) is that sorting by topo order is the key.
[13:36] <vila> You know my feelings about it and here you say it makes things simpler (good) so it should make it more robust
[13:37] <jam> vila: thanks for catching the pdb, it sure stands out in BB :)
[13:38] <vila> Now, as you describe it, this bug is nasty and hard to reproduce which testify that you have a good grasp on it. As such, you make reviewer life hard: either I give you an approve nased on trust or I need to work as hard as you :)
[13:38] <jam> So... with just the topo-order fix, it will still create Fulltexts at merge revisions
[13:38] <vila> OrderingVersionedFilesDecorator is just a test helper ?
[13:38] <jam> OVFD is a test helper, yes
[13:38] <jam> I split it out into another patch
[13:38] <jam> though perhaps that got "superseded"
[13:38] <vila> Wow, so you really pinpoint the bug in the test
[13:39] <jam> yeah, it di: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C4936F5EF.2060208%40arbash-meinel.com%3E
[13:39] <vila> Ha, I thought I read that but wasn't finding it in the submission
[13:39] <jam> vila: yeah, the bug is really a cascade of about 3 different failures
[13:39] <jam> which made writing a test case.... interesting
[13:40] <jam> Considering the fix was small, it took me all day to finish the test case.
[13:40] <jam> but at least I got a full handle on the bug
[13:40] <vila> That itself grants aBB:approve I think
[13:40] <jam> and feel confident about the fix
[13:40] <vila> The code modification is light, you ran the full test suite ?
[13:41] <jam> I did not, I'm on win32 where it doesn't pass anyway
[13:41] <jam> I ran bits I thought were appropriate
[13:41] <jam> (And trust that PQM will run the whole thing for me :)
[13:42] <vila> Ok
[13:43] <vila> jam: voted
[13:44] <vila> Now, regarding inclusion in 1.10, I'm not the RM, but given the effort that went into stacked branches related bugs, I'll vote for inclusion
[13:44] <vila> Are *you* the RM ?
[13:47] <jam> I'm the RM for 1.10-final(ish)
[13:47] <jam> yes
[13:47] <jam> poolie is away
[13:53] <vila> So, I didn't follow closely the bug history, were there some feedback that triggered your patch based on 1.10rc1 or is it just a work-in-progress that happens to be finished now ?
[13:54] <vila> I don't have a strong preference for rc2 or final anyway as long a 1.11 serie is opened anyway  :-)
[13:59] <jam> vila: bug #304841 is on 1.10rc1 + martin's patch
[13:59] <jam> his patch was for bug #303856
[14:01] <vila> I mixed up the two, thanks
[14:01] <vila> 303856 was targeted to 1.10final, that's a good hint to go with final
[14:03] <vila> I mean, you already put more polish on it (and addressed a critical bug), release !
[14:33] <balor> I accidently added a directory to my bzr repo.  I've not checked in the change.  Is there any way to undo adding the directory (and it's contents) before I check in?
[14:35] <balor> bzr remove
[14:35] <balor> just works
[14:35] <jam> balor: "bzr rm --keep"
[14:35] <balor> jam: I did bzr rm --force
[14:35] <balor> jam: then recreated the dir.
[14:35] <balor> jam: thanks though.
[14:35] <jam> np
[14:36] <jam> keep would have meant not needing to recreate it
[14:51] <LeoNerd> I've just installed bzr-svn and I'm trying to  bzr push svn+ssh://server/path  from my existing bzr native branch. I get an instant assert error, which doesnt' seem to give much detail. Anything I can try to debug this?
[14:54] <LeoNerd> The particular line that fails is   File "/usr/lib/python2.5/site-packages/bzrlib/plugins/svn/remote.py", line 52, in __init__
[14:54] <LeoNerd>     assert svn_url.startswith(self.svn_root_url)
[15:02] <lifeless> balor: or bzr revert <dir> would have kept it too
[15:03] <LeoNerd> Ooh... OK.. bug perhaps?
[15:03] <LeoNerd> svn+ssh://server//root/path/here   dies,   svn+ssh://server/root/path/here   works fine
[15:04] <jelmer> LeoNerd, any chance you can file a bug?
[15:05] <LeoNerd> debian reportbug be OK?
[15:05] <jelmer> yeah, sure
[15:07] <LeoNerd> done
[15:08] <lifeless> hi jelmer
[15:09] <jelmer> 'morning lifeless
[15:15] <lifeless> jelmer: did you see the bzr-svn branch I tossed up?
[15:15] <jelmer> lifeless, yeah, thanks for that
[15:16] <jelmer> lifeless, I'm about to rebase it on 0.5
[15:16] <lifeless> jelmer: ok
[15:18] <jelmer> lifeless, merged into 0.5
[15:19] <lifeless> jelmer: thanks. bzr-search needs get_transaction on repository (not direcyly, but  for Repository.iter_file_bytes
[15:20] <jelmer> fwiw, bzr-svn doesn't do Repository.iter_file_bytes()
[15:20] <lifeless>   File "/home/robertc/source/baz/bzr-test-fixes/bzrlib/repository.py", line 1399, in iter_files_bytes
[15:20] <lifeless>     transaction = self.get_transaction()
[15:20] <lifeless> it inherits it
[15:20] <lifeless>   File "/home/robertc/.bazaar/plugins/svn/repository.py", line 175, in get_transaction
[15:20] <lifeless>     raise NotImplementedError(self.get_transaction)
[15:21] <LeoNerd> Mm.. So this "determining changes" it's running on a new repo.. What's that for, and how long is it going to take?
[15:21] <LeoNerd> It's been chewing away for about 10 minutes now..
[15:22] <lifeless> jelmer: nvm, it canbe fixed in bzrlib.
[15:22] <lifeless> jelmer: this is a bit odd
[15:23] <lifeless> $ bzr search radix
[15:23] <lifeless> stacking support in bzr-svn is experimental.
[15:23] <lifeless> nevowlore.py in ...
[15:33] <lifeless> LeoNerd: it is calculating the shape of the repository in bzr terms
[15:33] <lifeless> LeoNerd: branches, per file graph and the like
[15:34] <LeoNerd> Right. It suddenly finished without warning :) I think the progress meter is broken
[15:34] <lifeless> LeoNerd: following that it will be able to start pulling
[15:34] <LeoNerd> It was claiming 0/204005 for aaages
[15:37] <LeoNerd> Hrm.. it doesn't preserve timestamps. No big issue, but it just upsets the stats a bit :P
[15:39] <lifeless> how do you mean?
[15:41] <LeoNerd> I've pushed a bzr branch into the svn repo, and according to our "trac" view of svn, it was all modified a few minutes ago, rather than last week
[15:41] <jelmer> LeoNerd, see the FAQ
[15:42] <jelmer> you can make bzr-svn modify the svn:date property, but it requires changing the settings in your svn repository
[15:42] <LeoNerd> Ahhright
[15:43] <lifeless>  jelmer so - whats that stacknig warning about, that svn branch isn't stacked
[15:43] <jelmer> lifeless, it happens whenever versionedfiles are involved
[15:44] <lifeless> :( I know this is a repeating theme, but how can I turn that warning off?
[15:46] <jelmer> there's no way to disable it at the moment
[15:46] <jelmer> I'd rather not allow turning that off, at least not in any released versions of bzr-svn, as the versionedfiles stuff is pretty much untested
[15:46] <jelmer> and it allows people to do b0rked imports
[15:46] <jam> lifeless: BB:approve on the iter_file_bytes fix, though if you could wait to submit it until after I've gotten 1.10 out the door, I would appreciate it
[15:47] <lifeless> jam: that was fast :P
[15:47] <lifeless> jam: tell me when to land it
[15:47] <lifeless> jelmer: how do you mean [borked imports]
[15:47] <jam> lifeless: I saw it on the bazaar-commits list while going through some other stuff :)
[15:48] <jam> I'll let you know when PQM is free
[15:48] <jelmer> lifeless, if you use "bzr branch --stacked" it uses versionedfiles and that can broken
[15:48] <jelmer> if there's some easy way to only warn when doing a stacking clone, I'm happy
[15:48] <jam> lifeless: for your InterDifferingSerializer change (where you buffer 100 revs at-a-time, and use apply_inventory_delta). What tests should I be looking at bringing across?
[15:48] <jam> I found a couple small issues for it
[15:49] <jam> and would like to get it merged into bzr.dev
[15:49] <jam> so we can have the improved version in-play and under-regular-testing
[15:49] <lifeless> jam: I had hit commit 2 seconds earlier :)
[15:50] <lifeless> jelmer: what goes wrong with the imports if they do this?
[15:50] <lifeless> jam: well first, add_inventory_delta, which poolie had some review feedback on
[15:51] <jam> lifeless: I don't see your "apply_inventory_delta" fix in BB
[15:51] <jam> ah, this one? http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480811102304s60b1df9cnf62aec9748a61346%40mail.gmail.com%3E
[15:51] <jelmer> lifeless, inconsistent text parents, text contents
[15:51] <lifeless> jelmer: !
[15:51] <lifeless> jam: no
[15:52] <jelmer> lifeless: this is why there is a warning :-)
[15:52] <jam> yeah, looking closer I realized that
[15:52] <jam> still looking
[15:52] <lifeless> jelmer: your warning is not accurate :P its not experimental its known broke
[15:52] <jelmer> lifeless, I'm not aware of any cases where that has happened, but the code is not very well tested
[15:52] <jelmer> and that's the sort of thing that *would* happen
[15:53] <lifeless> jelmer: oh
[15:53] <lifeless> jam: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1223873271.9015.266.camel%40lifeless-64%3E
[15:54] <jam> lifeless: what do you think about calling it "add_inventory_by_delta" ?
[15:55] <jam> And was Martin's main complaint that it was against an arbitrary rev? Rather than only the basis?
[15:56] <jam> I guess you already agreed to _by_delta
[15:57] <lifeless> I'm fine with add_inventory_by_delta, it is more clear
[15:57] <jam> I guess I'm a bit confused by his comment: "I still think it's dangerous to have something that looks like a delta  but is not,"
[15:57] <lifeless> thats the basis_delta list
[15:58] <jam> If you haven't said "recording_deletes = True" it is not an accurate delta?
[15:58] <lifeless> see the list for a convesation - bb deleted his initial comments when he commented again
[15:58] <lifeless> jam: yes
[15:58] <lifeless> jam: so I proposed to him that we make basis_delta be get_basis_delta()
[15:58] <jam> and we need to not have a delete for the current functionality?
[15:58] <lifeless> and if you haven't called recording_deletes, then get_basis_delta() errors
[15:59] <jam> that sounds ok, but I don't quite have a grasp on when/why you need to *not* record the deletes in the basis_delta
[15:59] <jam> It seems like you would need it to update the WT as well
[16:00] <lifeless> the existing commit driver generates it's own basis delta object
[16:00] <lifeless> that is
[16:00] <lifeless> in bzr.dev, and anything like plugins that is using CommitBuilder directly, code makes its own delta by using the return value from record_entry and adding deletes by hand
[16:01] <lifeless> with the patch, commit.py is fixed, but other clients wouldn't be - they would end up with a CommitBuilder object with what 'looks' like a good delta, but still wouldn't have deletes in it
[16:01] <Tak> are there existing bzr icons somewhere for things like branch, pull, merge, ...?
[16:01] <lifeless> Tak: bzr-gtk might have some
[16:01] <lifeless> jam: breakfast time
[16:02] <jam> lifeless: eat hardy. I think I have a feeling now
[16:02] <jam> so basically, you want get_basis_delta() to fail if you aren't aware of the new API
[16:02] <Tak> it appears to be using stock gnome icons atm
[16:02] <lifeless> jam: yah; simply if !self._recording_deletes: raise AssertionError("you can't use this until you've updated your apip usage per ...")
[16:11] <jam> lifeless: So... to set this variable True... we could do a Constructor variable, or bikeshed a bit on the proposed name (will_record_deletes()?). I prefer the constructor approach, except you have to pass it through Repository.get_commit_builder() which is a bit ugly
[16:11] <jam> I suppose we have a slightly smaller api compatibility issue if we just have a function on CommitBuilder
[16:12] <jam> as SVNCB can just inherit that function
[16:12] <jam> (though if it doesn't respect it... we have a problem anyway, so probably better to have it fail)
[16:13] <jam> who are all these people that have bzr-dbus installed?
[16:13] <jam> Is it a Recommends somewhere?
[16:36] <lifeless> jam: for compatibility I avoided constructor
[16:36] <jam> yeah, I went that route too
[16:36] <lifeless> jam: a client that does not use the function will work fine
[16:36] <lifeless> jam: because they won't try to get the delta, and the finish_inventory method knows to only use the delta if it is going to be valid
[16:37] <lifeless> jam: probably
[16:37] <lifeless> (re bzr-dbus)
[16:40] <jam> ?
[16:40] <lifeless> 03:11 < jam> who are all these people that have bzr-dbus installed?
[16:40] <lifeless> 03:11 < jam> Is it a Recommends somewhere?
[16:41] <jam> Ah probably a Recommends
[16:41] <jam> sure
[16:41] <jam> I thought that was the last line of the previous statement. :)
[16:43] <jam> lifeless: for the default implementation of "add_inventory_by_delta". Should we be adding "create_by_apply_delta" to Inventory and using it instead?
[16:43] <jam> It means requiring an Inventory.copy() which is a bit slow
[16:43] <jam> but is necessary for CHK inventories.
[16:43] <jam> We happen to know the lifetime of the inventory in add_inventory_by_delta is safe
[16:43] <jam> but apply_delta is not always a safe function otherwise.
[16:50] <lifeless> jam: I don't think so
[16:51] <jelmer> jam, bzr-gtk recommends bzr-dbus
[16:57] <lifeless> jam: create_by_apply_delta doesn't make sense to me on th ein memory invetory, not in the same way
[16:57] <lifeless> jam: the key ting here is that *repository* is the interface for adding inventories to
[17:04] <lifeless> jam: heading over to MV now, lets chat in about 2 hours ater the opening
[17:05] <jam> np
[17:05] <jam> enjoy the show :)
[17:28] <jam> lifeless: you can go ahead and submit your iter_files_bytes fix.
[17:37] <jkakar> I've just added 11MB of crap to a branch and committed it... and then realized that will bloat subsequent branches after merging this one to trunk.
[17:37] <jam> jkakar: bzr uncommit
[17:37] <jkakar> jam: That won't work, as I did the commit several revisions ago.
[17:37] <jam> jkakar: it would still work, you just have to do more to get things back
[17:37] <jkakar> jam: I've realized I can trim down that 11MB to 300k and now want to remove the history of that 11MB entirely...
[17:37] <jam> however, you can install the bzr-rebase plugin
[17:38] <jam> and have it help you recreate the extra revs
[17:38] <jkakar> bzr-rebase has never worked for me.  I probably don't understand how to use it.
[17:38] <jam> jkakar: I *think* you want bzr uncommit -rBEFORE_I_WAS_FOOLISH
[17:38] <jam> bzr revert
[17:39] <jam> bzr replay -r AFTER_I_WAS_FOOLISH..-1
[17:39] <jam> well, you probably need to keep 1 branch around to replay from
[17:39] <jkakar> Woah.  I'll try that, thanks.
[17:39] <jam> make sure to check "bzr help replay" just in case I have some syntax wrong
[17:58] <jkakar> jam: It worked!   Thanks a lot. :)
[17:58] <jam> np
[18:45] <lzhang> is there an easy way to see files that have been bzr rm'd in the file?
[18:46] <lzhang> in the current directory*
[18:46] <lzhang> bzr rm'd and committed in the past
[18:53] <etank> I have bzr installed on an ubuntu box and the windows bzr installer on a XP box. how can i do a checkout/branch/clone of my repo to on the Windows box?
[18:54] <etank> the initial bzr init, etc was done on the ubuntu box
[18:55] <jam> jelmer: ping, you just announced bzr-svn 0.4.16, but it doesn't seem to be tagged in http://bzr.debian.org/pkg-bazaar/bzr-svn/experimental/
[18:55] <jelmer> bleh, I suck at this
[18:55] <jelmer> jam, Sorry, that's at least the third time you have to remind me :-(
[18:56] <etank> i get the following when i try to do a branch
[18:56] <etank> C:\Documents and Settings\user\Desktop>bzr branch ssh://user@ipaddr:~/Code myCode
[18:56] <etank> bzr: ERROR: Unsupported protocol for url "ssh://user@157.184.82.74:~/Code"
[18:56] <jelmer> etank, you probably want sftp:// or bzr+ssh://
[18:57] <jelmer> jam, should be tagged now
[18:58] <jam> jelmer: so you are now tagging it as "debian-0.4.16" right?
[18:58] <jam> rather than bzr-svn-0.4.16
[18:58] <jam> btw, 0.4.15 also is not tagged
[18:58] <etank> jelmer: with either of those i get this now "bzr: ERROR: Invalid url supplied to transport: "invalid port number ~ in url:"
[18:59] <jelmer> etank, please use a / rather than a :
[18:59] <jam> etank: the URL you want is probably: sftp://user@host/~/Code
[18:59] <jam> if you want to use bzr+ssh then it would be
[18:59] <etank> ok
[18:59] <jam> bzr+ssh://user@host/home/user/Code
[18:59] <jelmer> jam, yeah, debian-0.4.16-1
[18:59] <jam> bzr+ssh doesn't support ~ yet
[18:59] <jam> jelmer: that really messes up the bzr-builddeb I have
[18:59] <jam> as in... it always wants bzr-svn-0.4.16
[19:00] <jelmer> jam, I'm still tagging the upstream release as bzr-svn-0.4.16
[19:00] <jam> Ah, I guess I just need to edit .bzr-builddeb/defaults.conf
[19:00] <jelmer> jam, just the debian packaging as debian-0.4.16-1
[19:00] <jelmer> jam, so you want to merge in debian-0.4.16-1 but have it build against bzr-svn-0.4.16
[19:01] <jam> k, I should mention the bzr-svn-0.4.16 isn't there *either*
[19:01] <jam> and neither is 0.4.15
[19:01] <jam> nor debian-0.4.15
[19:01] <jelmer> ah, that's actually a bzr-builddeb bug that I think has been fixed
[19:01]  * etank is wondering if using the python sources would be better
[19:02] <jam> anyway, if I go back and "bzr merge lp:bzr-svn && bzr revert && bzr merge lp:bzr-svn/0.4" I seem to have all the tags
[19:02] <jelmer> jam, now pushed with the original upstream tags
[19:02] <etank> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is require
[19:02] <jam> I'm not sure why they aren't in your packaging branches
[19:02] <etank> d)
[19:02] <etank> HPSS calls: 1 <bzrlib.smart.medium.SmartSSHClientMedium object at 0x01714810>
[19:02] <jelmer> jam, bzr-builddeb's "bzr merge-upstream" command used to not pull in tags
[19:02] <etank> thats what i got with  bzr+ssh
[19:02] <jelmer> I think James fixed that recently
[19:03] <jam> etank: if you are getting that, it means the ssh connection closed
[19:03] <jam> What version of the bzr client are you using ?
[19:03] <etank> im not sure why though
[19:03] <etank> one sec
[19:03] <jam> "bzr --version" should tell you
[19:03] <etank> bzr-setup-1.9.exe
[19:03] <etank> Bazaar (bzr) 1.9
[19:03] <jam> k, that one should be fine
[19:04] <etank> i can ssh to the box with no problems using putty
[19:04] <jam> etank: are you using custom keys or anything like that?
[19:04] <jam> or just username & password?
[19:04] <etank> nope. password loging
[19:04] <etank> login i mean
[19:05] <jam> and when you do "bzr branch bzr+ssh://..." it doesn't prompt you for a password?
[19:05] <etank> jam: nope
[19:06] <etank> C:\Documents and Settings\elake\Desktop>bzr branch bzr+ssh://elake@157.184.82.74/Code myCode
[19:06] <etank> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is require
[19:06] <etank> d)
[19:06] <etank> that is the exact ouput
[19:06] <etank> i wonder if it is something in the sshd_config that needs to be changed
[19:08] <jam> etank: ah, I have an idea
[19:08] <jam> try doing
[19:09] <jam> set BZR_SSH=paramiko
[19:09] <jam> on the command line
[19:09] <jam> and then running bzr branch
[19:09] <jam> and if that fails
[19:09] <jam> try
[19:09] <jam> set BZR_SSH=plink
[19:09] <jam> plink should fail because it doesn't support passwords as a sub-process
[19:09] <jam> but it may fail in a *different* way
[19:10] <jam> etank: did you rename "plink" to "ssh" btw?
[19:10] <jam> as that would probably confuse us
[19:10] <etank> nope
[19:10] <etank> neither of those worked
[19:10] <etank> pscp elake@elake-ibex:/home/elake/Code/mailer.py ./  <-- that command would work though
[19:11] <jam> etank: you might try looking at "My Documents\.bzr.log" to see if there is any more info there
[19:11] <etank> SocketConnectionError: Unable to connect to SSH host 157.184.82.74; EOF during negotiation
[19:11] <jam> jelmer: Why would "dch" keep trying to add a new record with your name instead of mine?
[19:12] <jelmer> I'm listed as maintainer
[19:12] <jelmer> debia/control
[19:13] <jam> jelmer: yeah, I was accidentally using "-m" thinking I needed it as the update message
[19:13] <jam> rather than realizing it set the "use the ID of a maintainer" flag
[19:14] <jelmer> I've done that a couple of times as well
[19:14] <jelmer> bzr commit ruined dch for me
[19:14] <jam> etank: does it say anything about failing to import paramiko, etc?
[19:18] <etank> jam: no but here is the output of the last two tests http://dpaste.com/96468/
[19:18] <etank> maybe the .ssh/know_hosts part is the issue
[19:19] <jam> etank: can you try using "sftp://" just to see if that gives different results?
[19:19] <jam> (I don't expect it to, but we can try it)
[19:20] <etank> jam: same thing
[19:20]  * etank wonders where putty puts is known_host info
[19:21] <jam> etank: with bzr-1.9 we shouldn't actually be using putty
[19:21] <jam> we should be using paramiko to connect
[19:21] <jam> as plink doesn't allow us to ask the user for a username and/or password
[19:21] <jam> (so it works only if you are using ssh keys)
[19:21] <etank> i was going to look at puttys file and place it where bzr wants to find it
[19:22] <jam> I don't *think* it is a known_hosts issue
[19:23] <jam> something weird is going on, though if both "BZR_SSH=paramiko" and "plink" are failing
[19:23] <etank> bzr: ERROR: Unable to connect to SSH host elake-ibex; (10061, 'Connection refused')
[19:23] <jam> what shell are you using?
[19:23] <etank> windows command shell
[19:23] <jam> and you don't have something like a non-standard ssh port, right?
[19:23] <etank> cmd.exe
[19:23] <etank> nope
[19:23] <etank> 22. default install on the ubuntu side
[19:27] <etank> back in a few
[19:32] <jam> etank: ... for the .bzr.log you gave, I can imagine that if BZR_SSH is plink it will fail because we cannot ask for a password
[19:32] <jam> for the "set BZR_SSH=paramiko" I don't see why it would be failing
[19:33] <jam> for the other one, it is definitely *using* paramiko
[19:33] <jam> as the exception traceback is coming from that code
[19:42] <lifeless> jam: so
[19:42] <lifeless> jam: I don't mind if you want to write a create_by_apply_delta for Inventory, but I don't think its going to be any faster or anything; and its another method to support
[19:43] <lifeless> create_by_apply_delta on CHKInventory was/is semi private
[19:44] <jam> I agree that it isn't going to be faster
[19:44] <jam> it is more about consistent apis between different Inventory implementations
[19:45] <jam> considering that "apply_delta" is public
[19:45] <jam> and certainly a more dangerous function than "create_by_apply_delta"
[19:46] <lifeless> apply_delta isn't on CHKInventory at all
[20:04] <LarstiQ> jelmer: how about a bzr-dch plugin? ;)
[20:05] <jam> lifeless: I seem to be getting build failures for bzr-svn because it can't find the bzr packages
[20:05] <jam> and the bzr-svn ones require >1.10
[20:05] <jam> do you know if this is just transient?
[20:05] <jam> (I also happened to upload bzr-svn *before* I uploaded bzr, as I was trying to make sure I got all the packages built before I updated the ppa)
[20:06] <jam> (but I already did one "retry" and it still is unhappy)
[20:10] <lifeless> jam <-> jelmer
[20:10] <lifeless> jam: You'll need to up load bzr, upload bzrtools, upload bzr-svn, then update the ppa
[20:10] <lifeless> this requires a separate ppa and package copying
[20:11] <jelmer> jam, you may get away with a build-dependency on 1.9
[20:12] <jam> So the specific error seems to be this line:
[20:12] <jam> After installing, the following source dependencies are still unsatisfied: bzr(inst 1.9-1~bazaar1~hardy1 ! >= wanted 1.10~)
[20:12] <jam> And I'm concerned about whether the 1.10-1~bazaar1~hardy1
[20:12] <jam> is evaluating versus 1.10~ correctly
[20:13] <jam> well, *will* evaluate
[20:13] <jam> obviously it is only finding the old 1.9-1 so far
[20:19] <jam> hmm.. bzrtools built fine
[20:19] <jam> ah, but Jelmer didn't update the control file for bzrtools
[20:19] <jam> it still says 1.9~
[20:21] <jelmer> jam, I didn't update the build dependency
[20:21] <LarstiQ> 1.9~ for what, the version of bzrtools, or the dependency on bzr?
[20:21] <jelmer> jam, that's still at >=1.9~, but shouldn't matter
[20:21] <jelmer> jam, the runtime dependency I did update
[20:22] <jam> LarstiQ: the bzrtools 1.10 package only depends on bzr 1.9
[20:22] <jam> for some reason, the bzr-svn ppa is failing to build the 0.4.16 package because it depends on bzr >= 1.10~
[20:22] <jam> I don't know if it was because my upload ordering was reverseed
[20:22] <jam> or if it is just having a problem finding the packages now that they are present in the ppa
[20:23] <jam> I would guess that my upload order confused the initial attempt
[20:23] <jelmer> jam, what makes you say bzrtools depends on bzr 1.9..?
[20:23] <rocky> jelmer: hey, is there a bzr-svn release for bzr 1.10 yet?
[20:23] <jam> but I would have thought it fixed when I did "retry"
[20:23] <jam> rocky: bzr-svn 0.4.16
[20:23] <jam> jelmer: Build-Depends-Indep: bzr (>= 1.9~), rsync
[20:23] <jam> though I also see:
[20:23] <rocky> awesome, thanks
[20:24] <jam> After installing, the following source dependencies are still unsatisfied: bzr(inst 1.9-1~bazaar1~hardy1 ! >= wanted 1.10~)
[20:24] <jam> sorry
[20:24] <jelmer> jam, That's just saying building the package should work with 1.9 and 1.10
[20:24] <jam> Depends: ${python:Depends}, bzr (>= 1.10~), bzr (<< 1.11~), patch
[20:25] <jelmer> jam, seems fine to me
[20:25] <jam> Well, bzr-svn does have "bzr >= 1.10~" in its "Build-Depends"
[20:25] <jam> which bzrtools doesn't have
[20:26] <LarstiQ> I don't think bzrtools needs it?
[20:26] <jam> to build? probably not
[20:27] <jam> I would have assumed bzr-svn wouldn't need it to *build* either
[20:27] <jam> The discussion may not matter in a bit
[20:27] <jam> as it seems the ppa *might* be figuring out that it really does have access to bzr >= 1.10 now
[20:27] <jam> at least, the link to the "lpia" build went away
[20:28] <jam> which I'm hoping means it successfully built
[20:28] <jam> In the future, I just need to make sure to upload bzr before any plugins
[20:29] <jam> It certainly has to be able to grab packages from the ppa itself, otherwise it wouldn't have been able to install bzr-1.9 either
[20:29] <jam> since that only exists in a ppa, IIRC
[20:29] <jam> I didn't think 1.9 has made it into any release
[20:41] <BratscherBen> is there a possibility to use Hooks as in subversion? As far as I see, hooks in bzr are registered in ~/.bazaar/plugins which affects all usage of bzr. In my concrete example I want to run a bzr export in a remote repository after push, but not in all my repositorys.
[20:42] <etank> jam: yeah i did the set for paramiko and it is still a no go
[20:42] <LarstiQ> BratscherBen: hooks can check which branch they're operating on, and have programmatice access to it's branch.conf
[20:43] <LarstiQ> (and to ~/.bazaar/ config as well if needed)
[20:43] <BratscherBen> yes, but I want that this command is run not only when I check something in, but also when others do
[20:45] <BratscherBen> so is the post_push hook called on the remote server, when somebody pushes or only on the machine that pushes?
[20:46] <BratscherBen> the docu says “runs on client”
[20:47] <jam> BratscherBen: there is a hook that is run on the server side (post-branch-tip-changed, IIRC)
[20:47] <BratscherBen> yes, just found it
[20:47] <jam> Apparently it may be getting a semi-bogus URL at the moment (because when run on the server things are run in a chroot)
[20:48] <etank> im not getting the bzr on windows thing :/
[20:49] <BratscherBen> so I assume I have to install a plugin in /usr/share/pyshared/bzrlib/plugins for which I also need root access and have to check there, from which repository I am called
[20:49] <lifeless> BratscherBen: you should set the hook on the server, it will run for all branches on the server; you can then filter that down by checking its a branch you want to take the action on
[20:49] <jam> etank: unfortunately, it "just works" here... which makes it all the more difficult
[20:49] <jam> also, when we use an all-in-one installer we lose some of the ability to debug
[20:50] <jam> if it was installed into a regular python install
[20:50] <BratscherBen> sounds like a solution, but not a nice one
[20:50] <etank> i can do a regular python install
[20:50] <jam> then you can drop down into a python shell, and try various things
[20:50] <etank> jam: will it work with py2.6?
[20:50] <etank> the site said 2.4 and 2.5 so that is why i went with the all in one installer
[20:50] <jam> vila has been working on 2.6 compatibility. I believe it currently works
[20:51] <jam> They did some odd backwards-incompatible changes in 2.6
[20:51] <LarstiQ> but there might not be a 2.6 installer
[20:51] <BratscherBen> the solution in other vcs are nicer, why bzr has not such an option to just run a shellscript in .bzr/hooks/post-tip-change ...
[20:51] <jam> LarstiQ: I would guarantee there isn't :)
[20:52] <jam> BratscherBen: in a distributed setup, you don't always have control over ".bzr/hooks/*" and that tends to lead to running $RANDOM other person's code
[20:52] <jam> which is a good way to have a security problem
[20:52] <jam> That said, there is a "shell-scripts" plugin that adds support for shell hooks
[20:52] <BratscherBen> the person who owns the repository has control over this
[20:52] <jam> I don't remember the exact name
[22:09] <lifeless> BratscherBen: there is a plugin that can do what you want; but you can as a user in your own account setup plugins too
[22:23] <BratscherBen> I managed it now with this shell-scripts plugin. Problem here is a bit, that the post_change_branch_tip_hook is executed while a still is in progress and so the lock is not free. I made a workaround like {sleep 3; bzr export foo.zip} around to avoid this, but it of course is not really nice
[22:24] <BratscherBen> but it works, thanks for the answers…
[22:43] <luigi> hi
[22:43] <luigi> is python 2.6 supported?
[22:47] <LarstiQ> luigi: it should be
[22:47] <luigi> ok
[22:49] <NfNitLoop> 3.0?  ;p
[22:49] <luigi> yeah
[22:50] <NfNitLoop> ... really?
[22:50] <luigi> dont know
[22:50] <LarstiQ> NfNitLoop: no
[23:07] <NfNitLoop> I didn't figure so. :)