[00:19] <dobey> james_w: but the commit() call that tarmac is making, is passing committer='Tarmac' as an argument
[00:19] <dobey> it was working fine before i upgraded to 2.2.0 today
[00:21] <mkanat> Is "bzr send" using a "mailto" url or something?
[00:21] <mkanat> Not all MUAs support all the mailto query parameter extensions.
[00:22] <thumper> it worked fine in kde, just not gnome
[00:22] <thumper> probably a weird setting
[00:23] <mkanat> Ahh, yeah.
[00:47] <spiv> Good morning.
[00:48] <poolie> hi there spiv
[00:50] <jam> mkanat: just a note, the primary in-memory cache is brought down to disk in trunk with the bzr-history-db work
[00:50] <jam> hi spiv
[00:50] <mkanat> jam: Yeah, that's the primary thing that makes this possible.
[00:50] <mkanat> jam: But the revision cache is still in memory, IIRC.
[00:50] <jam> mkanat: it is, but it isn't as necessary
[00:51]  * mkanat nods.
[00:51] <jam> ISTR there are times when it is useful
[00:51] <jam> we would have to check
[00:51] <mkanat> Yeah, there are times we have to map revids to revnos in a loop, IIRC.
[00:51] <jam> we could push harder on moving it to disk if we had to
[00:51] <mkanat> jam: I think that's probably what we'll do.
[00:51] <jam> short-term denormalization of a given table
[00:52] <mkanat> jam: But that won't work in the codehosting situation, will it? Because we can't write to the disk.
[00:52] <jam> we can
[00:52] <jam> it already does
[00:52] <mkanat> Ah, okay.
[01:13] <james_w> dobey: well, that's when the error was added, so that's no surprise
[01:19] <james_w> dobey: is test_branch a file you have added?
[01:20] <james_w> dobey: and in your pastebin "a_branch.tree.commit("Reading, 'riting, 'rithmetic")" doesn't look like it is passing committer=
[02:14] <mtaylor> if I don't want to re-branch - is there a way to migrate a standalone branch to one inside of a shared repo?
[02:14] <fullermd> reconfigure
[02:15] <mtaylor> fullermd: heh. that's too easy
[02:16] <fullermd> Oh.  Well, the Seven Trials of Courage, climbing the North Face of the Eiger, _then_ reconfigure.
[02:17] <mtaylor> fullermd: excelent. that's better
[02:19] <fullermd> Anything for a steady customer  :p
[02:31] <mkanat> poolie: I should be able to get to Loggerhead stuff by the end of the week. But if there's something that you need more urgently than that, please let me know.
[03:00] <poolie> mkanat: nothing springs to mind, i'd just suggest talking to chex or spm or similar if you see them online
[03:00] <mkanat> poolie: All right. :-)
[05:47] <spiv> poolie: what's the process for getting 2.1.2 into lucid-updates?  There have been quite a few dupes of bug 559436, and it just bit Mary...
[05:52] <lifeless> spiv: read all about it on the stable release update pacge
[06:09] <poolie> spiv, or see my previous mail about srus
[06:20] <mtaylor> lifeless: all of the web pages say bzr-hg is under heavy dev ... is it usable for day to day? or will I have less pain with just plain hg?
[06:22] <lifeless> mtaylor: we use it in prod to import hg on lp.net.
[06:22] <lifeless> mtaylor: go figure :P
[06:22] <mtaylor> lifeless: oh - well, that's something then :)
[06:22] <mtaylor> lifeless: there doesn't seem to be a _great_ way to figure out what form a url should take... can you recommend any help I should look at? or should I just read the source?
[06:23] <lifeless> http:// ?
[06:23] <lifeless> I dunno
[06:24] <mtaylor> lifeless: hah! I was trying to make it much harder - doing hg+http :)
[06:24] <mtaylor> lifeless: thanks
[06:59] <spiv> poolie: On reflection I think what I really meant to ask was "why didn't 2.1.2 get proposed as an SRU more-or-less when it was released?"  Ideally we'd have proposed it already given the severity/frequency of that bug I think.
[07:11] <poolie> i don't think there's any good answer
[07:11] <poolie> we should have
[07:11] <poolie> the make-a-release chain is already pretty long
[07:20] <spiv> *nod*
[07:27] <spiv> Actually, looking at my mail, lifeless said he was about to propose 2.1.2 as an SRU for lucid the day 2.1.2 released. :P
[07:29] <lifeless> I may have done so even.
[07:30] <spiv> Hmm, I wonder where it is then...
[07:31] <lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/bzr needs some love
[07:32] <spiv> Yeah, I was just noticing that :(
[07:33] <spiv> https://code.edge.launchpad.net/~lifeless/ubuntu/lucid/bzr/2.1.2-sru
[07:33] <spiv> linked to bug 528041
[07:33] <lifeless> there you go
[07:33] <lifeless> I was about to claim that I sucked
[07:35] <spiv> So where in the SRU process did that get stalled?
[07:35] <lifeless> probably the usual place : the start
[07:35]  * lifeless takes off the bitter hat
[07:35] <spiv> Heh.
[07:36] <spiv> Well, it looks like we got past step 1 of https://wiki.ubuntu.com/StableReleaseUpdates#Procedure :P
[07:44] <spiv> lifeless: so my reading of the SRU page says the next thing that needs to happen is someone needs upload the package to lucid-proposed.  Does that sound right to you, and can you do that?
[07:45] <lifeless> AIUI no
[07:46] <lifeless> ww haven't set up per-package uploads for bzr and its in main
[07:48] <spiv> So we should subscribe ubuntu-sponsors to the bug to find a sponsor?
[07:48] <poolie> probably
[07:48] <poolie> you may need to nag someone
[07:51] <cody-somerville> I'll sponsor it.
[07:52] <spiv> cody-somerville: thanks!
[07:55] <cody-somerville> Does bzr have an exception from the TB to push entire new releases via -updates?
[07:55] <lifeless> cody-somerville: no, and we're not asking for that
[07:55] <lifeless> cody-somerville: these point releases are managing in an SRU way upstream
[07:55] <poolie> cody-somerville: if this is from 2.1.1 to 2.1.2 the changes should be compatible with the sru criteria
[07:55] <poolie> safe fixes for important bugs
[07:57] <spiv> This is from 2.1.1 to 2.1.2
[07:57] <cody-somerville> 47 files changed, 2926 insertions(+), 2331 deletions(-)
[07:58] <lifeless> noooo
[07:58] <lifeless> its either very mechanical, or something confused in udd
[07:59] <spiv> A heap of that is noise from Pyrex-generated C, I suspect.
[07:59] <lifeless> bzr diff -r bzr-2.1.1..bzr-2.1.2 | diffstat
[07:59] <lifeless>  34 files changed, 717 insertions(+), 160 deletions(-)
[08:00] <lifeless> cody-somerville: ignore the .c files, they are autogenerated - equivalent to configure
[08:00] <spiv> Heh, yep, lots of /home/mbp/ became /home/robertc/ in Pyrex-generated comments in the C.
[08:01] <lifeless> we should probably add some sed in there
[08:04] <poolie> urk
[08:05] <cody-somerville> Generally an SRU is as minimal as possible to fix a single specific bug. Some packages like landscape have permission from the TB to push point releases like this into -updates. Considering bzr's testsuite, you guys should probably ask for the same exception. In the mean time, is there a minimal diff I can upload? If not, I'd recommend pinging someone from the SRU team to get permission as to avoid doing something that'll end up being
[08:05] <cody-somerville> rejected.
[08:05] <poolie> hm
[08:05] <poolie> we have done previous SRUs on similar changes
[08:08] <spiv> It sounds like it would be good to get formal permission from the TB just to expedite the process?  I know we've had point release SRUs go through before, but IIRC also with some to-and-fro about whether they really satisfy the letter of the SRU policy or not.
[08:08]  * cody-somerville nods.
[08:08] <poolie> ok
[08:08] <spiv> Expedite the process in future, anyway, perhaps not expedite this particular SRU ;)
[08:09] <poolie> so in the interim, do you want to merge the patch just for this change?
[08:09] <poolie> i find it a bit hard to believe that will be much safer but i understand the general process
[08:09] <cody-somerville> Its up to you guys. I was hoping this was just a quick patch that I could do real quick before heading off to bed.
[08:10] <cody-somerville> If you want you can get approval from SRU board and I can upload when I wake up if you haven't found someone else to sponsor it by then
[08:10] <spiv> poolie: well, the linked bug is for the siginterrupt issue, which is definitely good to have fixed, but the bug that triggered me asking about SRUs was bug 559436...
[08:10] <poolie> cody-somerville: and how do we get that approval?
[08:11] <cody-somerville> subscribe ubuntu-sru team
[08:11] <cody-somerville> and then possibly poke someone on the team
[08:20] <poolie> spiv, can you do that?
[08:36]  * bialix waiting for Garyvdm
[08:37] <poolie> hi bialix
[08:37] <bialix> hi poolie !
[08:46] <spiv> poolie: sure
[08:48] <spiv> (The team was already subscribed to that bug as per the procedure on the SRU wiki page, but I'll find and poke someone on it)
[08:49] <poolie> spiv, so re https://bugs.edge.launchpad.net/launchpad/+bug/615740
[08:49] <poolie> what the best plan for handling eintr now?
[08:49] <poolie> such a saga...
[09:02] <spiv> poolie: depends!
[09:03] <poolie> so there's one select call that's failing
[09:03] <spiv> poolie: don't have any signal handlers is a good plan, if you can
[09:03] <poolie> oddly, raising select.error not IOError
[09:04] <spiv> poolie: if you can't, register it with signal.siginterrupt is good, if you can assume python >= 2.6.6
[09:05] <spiv> if you can't do that (you do want the signal to interrupt syscalls, or you can't assume 2.6.6), then your options are less good.
[09:05] <spiv> select at least is safe to retry the call, if it's happening in your own code.
[09:05] <poolie> i think it is
[09:06] <poolie> i don't know if lp assumes 2.6.6 yet?
[09:06] <poolie> probably not
[09:08] <spiv> Given that 2.6.6rc1 only just hit maverick, I doubt it :)
[09:10] <spiv> Ok, I need to wind up for the day, but at least I have code that makes 'bzr reconcile' fix non-canonical CHKs now.
[09:14] <poolie> yay
[10:03] <dakira> hi.. how do I get only a list of modified/added files for the last few commits?
[10:22] <luks> dakira: bzr st -r -3 (last two commits)
[10:42] <dakira> luks: great.. thx!
[10:44] <fullermd> Note the difference between "-r-3" (compare rev -3 to the current working tree status) and "-r-3.." (compare rev -3 to the latest commit)
[10:46] <dakira> fullermd: so "-r -3" == "-r-3.."?
[10:46] <fullermd> No, "-r-3" == "-r-3"...  I don't think there's any long form.  "-r-3.." == "-r-3..-1"
[10:47] <dakira> fullermd: look closely... not "-r-3" but "-r<space>-3".. the latter seems to be equivalent to "-r-3.."
[10:47] <luks> "-r-3.." != "-r-3..-1" because the range is exclusive
[10:47] <fullermd> They're the same thing, space or not.
[10:48] <fullermd> Standard option parsing.
[10:48] <fullermd> Er, -r-3.. IS exactly the same as -r-3..-1.  Open ended ranges go to the end of the tree.
[10:48] <luks> then my bzr is doing something wrong :)
[10:48] <fullermd> (well, mod some bugs that have existed in the past with parsing them at least)
[10:49] <luks> oh
[10:49] <luks> my bad
[10:49] <luks> it's sorted differently
[10:50] <luks> I wonder why -r-3..-1 isn't sorted
[10:52] <fullermd> Any other day, I'd say "I dunno".  Today, the answer is obviously "the world is out to get me".
[10:54] <dakira> luks: hm.. -r-3.. and -r-3 give me the same results (they compare with the working tree) while -r-3..-1 compares with the last commited revision!
[10:54]  * fullermd frowns.
[10:54] <fullermd> That's...  unexpected.
[10:55] <spiv> I occasionally think that -0 should mean "working tree".
[10:55] <fullermd> I'd rather have a tree: or something.
[10:56] <spiv> Then I go have a nice cup of tea in a quiet corner somewhere and reason returns ;)
[10:56] <fullermd> Well, I do see that listed behavior.  I'm pretty sure it used to be like I think it is, so I presume it was changed intentionally...  I don't think I like it though.
[10:57] <fullermd> spiv: Really, it should be "+1"  ;p
[10:57] <spiv> fullermd: no, 0 comes after -1
[10:57] <spiv> fullermd: and the uncommitted working tree is the nearest thing we have to the next revision after the most recently committed one...
[10:57] <fullermd> Yes, but 0 is already taken for null.  Anyway, we want to go one rev forward from the current state, so...
[10:57] <spiv> Right, hence -0 ;)
[10:58] <fullermd> Of course, since it's not committed yet, it's not real.  So, it should be 'i'.
[10:58] <fullermd> Unless, of course, we steal the imaginary axis to be the timeline along which we allow editing commit logs...
[10:58]  * fullermd goes off and hides.
[11:01] <spiv> $\lim_{revno\to 0}revision(revno)$
[11:01] <dakira> fullermd: here's what I get http://pastebin.com/NvRWeNWq
[11:01] <spiv> Or something.
[11:01]  * spiv wanders off
[11:02] <dakira> bzr is 2.1.1
[14:15] <dobey> james_w: a_branch is a tarmac.Branch, and its commit method calls the bzr commit with committer='Tarmac'
[14:16] <james_w> dobey: ok, given that I can't see this code I'll have to take your word for it. Also given that I can't see it I can't help you debug it any more.
[14:23] <dobey> http://bazaar.launchpad.net/~rockstar/tarmac/main/annotate/head%3A/tarmac/branch.py
[14:24] <dobey> http://bazaar.launchpad.net/~rockstar/tarmac/main/annotate/206/tarmac/tests/test_branch.py#L40
[14:25] <bialix> ddaa: hello
[14:25] <ddaa> hey bialix
[14:25] <dobey> i'm trying to get those tests back in trunk and working again. and i almost had it. the commit() worked fine yesterday morning, and the started failing after i ran update-manager and bzr got upgraded to 2.2.0
[14:37] <james_w> dobey: I don't know. It seems to pass it down ok, but it clearly uses it, you might want to pdb and find out at what level it loses it.
[14:41] <dobey> yeah, i went hunting through the code path from the stack trace last night and didn't see anything obvious in the code :-/
[14:42]  * jelmer waves to james_w, dobey
[14:42] <james_w> hi jelmer
[14:42] <dobey> hi jelmer
[15:03] <dobey> ah, how the little things can wreck havoc
[15:08] <dobey> a_branch.*tree*.commit() is not a_branch.commit(). sorry :)
[15:09] <jelmer> hehe
[15:09] <jelmer> been there, done that.. with the exact same method.
[15:28] <dobey> with commit --fixes in bzr, does it store the url as lp:NUM or http://bugs.launchpad.net/bugs/NUM ? or something else?
[15:28] <jelmer> dobey, the latter
[15:29] <jelmer> dobey: see also "bzr cat-revision", that will dump the raw representation of a revision
[15:29] <dobey> ah
[15:30] <dobey> thanks
[15:49] <abentley> Anyone have a suggestion on how to debug InvalidUseOfScopeReplacer in the Launchpad test suite, when the test, run by itself, doesn't cause it?
[15:49] <abentley> I've been trying to backtrack to find the test that is abusing the scope replacer, but so far no dice.
[15:53] <mgz> nope, 's one of the oddities I've run into before and not had time to track down.
[15:54] <mgz> a bunch of the doctests fall over with it on ironpython and jython.
[15:54] <abentley> mgz, with the Launchpad test suite or the bzr test suite?
[15:54] <mgz> in bzr, sorry.
[16:36] <Typh> If I push to a location, why would then running bzr update in that location produce "bzr: ERROR: No WorkingTree exists"
[16:36] <GaryvdM> jam: For  some reason, paramiko is no longer being included in libary.zip
[16:36] <jam> hmmm. I wonder if it got installed as a plain .egg
[16:37] <jam> .egg doesn't work with py2exe
[16:37] <GaryvdM> Typh: If you push to a remote location, working trees are not created.
[16:37] <GaryvdM> jam: Yes  - It is installed as an .egg
[16:37] <GaryvdM> Typh: you can create the working tree by running bzr checkout
[16:38] <Typh> GaryvdM: oh. oops :D. thanks.
[16:38] <GaryvdM> Typh: and if you push to a remote location that allready has a working tree, it will then be out of date, and will need a bzr update
[16:39] <GaryvdM> Typh: This is due to limitations in the remote protocols.
[16:39] <bialix> heya Gary!
[16:39] <GaryvdM> Hi bialix
[16:40] <bialix> did you saw my messages?
[16:40] <GaryvdM> bialix: Yes - was just going to reply.
[16:40] <rubbs> Typh: also, if you are pushing to a remote location just to update files for say a webserver, you may want to look at some plugins like push-and-update. I'll see if I can dig up relevant links
[16:40] <bialix> ok
[16:41] <Typh> rubbs: no no, I was just trying to recreate a borked checkout on the server. I've never had to push a brand new copy anywhere before :)
[16:41] <rubbs> Typh: ah, cool. Just checking.
[16:41] <GaryvdM> bialix: Surely there is a syntax that will work for both versions. I'll take a look.
[16:46] <jam> GaryvdM: I'll log in now and try to fix that
[16:51] <jam> GaryvdM: I needed to do "python setup.py install -O1 easy_install -O1 -Z" to get it to not install using an egg
[16:51] <GaryvdM> bialix: Please could you see if this runs with pyqt4.4: http://pastebin.org/466026
[16:56] <bialix> GaryvdM: with your patch test suite did not errored, but tests failed
[16:56] <jam> GaryvdM: it should be fixed now, care to try again?
[16:56] <GaryvdM> jam: Thanks
[16:57] <GaryvdM> bialix: Please pastebin test output.
[16:57] <bialix> GaryvdM: that paste writes success, but is it really success?
[16:58] <GaryvdM> bialix: Yhea - need to check that it's actually connected....
[16:58] <bialix> GaryvdM: http://pastebin.org/466035
[17:10] <GaryvdM> bialix: I think that previously, the connections in that test were not connecting, and the are now, and exposing bugs in the test.
[17:11] <bialix> ouch!
[17:11] <GaryvdM> Funny that they are connecting in qt 4.4, and not 4.6/4.7.
[17:16] <bialix> GaryvdM: I would like to add direct support of colo in qbzr. E.g for commands qswitch, qmerge, maybe others
[17:16] <bialix> there is custom qswitch in the explorer to understand colo, but I think we can do better in qbzr
[17:18]  * bialix off to home, bbl
[17:29] <CcxCZ> is there way to bind branch multiple times?
[17:33] <GaryvdM> jam: Thanks - that worked.
[17:34] <GaryvdM> jam: Is there an easy to test the speed of paramiko? I'd like to see if my patch makes it faster.
[17:34] <jam> GaryvdM: I don't know of any specific way. I assume trying to do an ssh loopback and see how fast you can transmit bytes
[17:34] <jam> I don't really know how to set that up, though
[17:35] <GaryvdM> ok
[17:35] <jam> probably you could do something with a loopback to openssh via sftp, and just try to read a 1GB file
[17:35] <jam> or ssh localhost dd if=/dev/urandom
[17:35] <jam> or something like that
[17:36] <jam> you could do /dev/zero because it is fast, but I think the channel auto-compresses, and that compresses a bit too well :)
[17:37] <CcxCZ> doesn't urandom wait for entropy?
[17:37] <jam> CcxCZ: I thought /dev/random did and /dev/urandom layered cryptographic randomness on top of entropy
[17:37] <jam> psuedorandomness
[17:38] <CcxCZ> A read from the /dev/urandom device will not block waiting for more entropy.
[17:38]  * CcxCZ RTFMed
[17:38] <fullermd> Yeah, it's the other way around.  urandom doesn't block; random does.
[17:39] <CcxCZ> though that's not very good for benchmark I guess
[17:40] <jam> GaryvdM: if you don't mind working through the bzrlib api, you could probably just use "t = bzrlib.transport.get_transport('sftp://localhost/...'); t.get_bytes()"
[17:40] <jam> That handles all of the "how do I set up paramiko" stuff :)
[17:41] <GaryvdM> jam: I specifically want to see if I'v removed the "1-2 seconds" that you mention in Bug 271791
[17:41] <jam> GaryvdM: well that is easy to tell
[17:41] <jam> bzr log sftp://host
[17:41] <jam> we've patched pycrypto repeatedly for that IIRC
[17:42] <jam> however, you also have to have a system where time.time()'s resolution is 15ms
[17:42] <jam> 1ms is fast enough to not really notice 100 calls.
[17:42] <jam> 1ms == 100ms total, 15ms == 1.5s total, very noticeable
[17:42] <jam> you can do a loop on time.time() to determine the resolution
[17:43] <CcxCZ> anyway I guess there isn't simple way synching multiple branches at once. As I look in .bzr/branch/branch.conf, there can be only one bound branch.
[17:44] <GaryvdM> jam: I have 1ms time.time() resolution, so I guess I won't be able to test.
[17:45] <jam> GaryvdM: well, IIRC 'import paramiko' triggered it, you could see if it takes 100ms to do so.
[17:45] <jam> However, I'm pretty sure that code doesn't exist in pycrypto 2.1+
[17:45] <jam> They, at least, rejected my patch for it on the basis that you shouldn't be using that code anywy
[17:47]  * GaryvdM going to get food, while I wait for my build to download.
[17:59] <dobey> i'm not overly familiar with bzrlib, but i need some help with getting revision properties out of the revisions from one branch that are being merged into another
[18:01] <CcxCZ> dobey: can you elaborate on that?
[18:02] <dobey> i have one branch that has some revisions, with multiple revisions where one revision has a bug fix, but the last revision does not for example
[18:03] <dobey> and when i merge that branch into another, i need to get all the bugs revision properties for all the revisions that are being merged in
[18:03] <dobey> but it's not clear to me how to do that exactly
[18:08] <dobey> i can get properties from the last revision, but it's not clear to me how to get them for all of the revisions which are being merged
[18:11] <GaryvdM> dobey: Maybe take a look at what bzr missing does.
[18:12] <GaryvdM> debey: It will involve some graph call, which, I'm not sure.
[18:16] <GaryvdM> dobey: If you look at bzrlib.missing._find_unmerged , It's quite clear.
[18:17] <GaryvdM> Instead if the remote_branch.last_revision_info(), use the last revision that you used when you looked at the branch.
[18:18] <GaryvdM> dobey: You can also look at the revisons that have been removed from branch using uncommit, or pull/push --overwrite
[18:23] <abentley> jam, I'm trying to debug an InvalidUseOfScopeReplacer in the Launchpad test suite.  Unfortunately, it's not clear what test is actually misbehaving the tests that raise it run fine by themselves.
[18:24] <abentley> jam, do you have any suggestion how to debug it?
[18:32] <dobey> GaryvdM: hrmm, i'm doing a missing._find_unmerged to try and see what's going on, and i get an error:
[18:32] <dobey> bzrlib.errors.ObjectNotLocked: <bzrlib.groupcompress._GCGraphIndex object at 0x959156c> is not locked
[18:33] <GaryvdM> dobey: Things are normally locked by missing.find_unmerged, which then calls missing._find_unmerged
[18:34] <GaryvdM> dobey: I pointed out _find_unmerged, because thats were the interesting code is.
[18:34] <dobey> ah
[18:48] <dobey> GaryvdM: thanks!
[19:21] <jam> abentley: does it tell you the name of the variable it isn't liking?
[19:21] <abentley> jam, "ui".
[19:22] <abentley> jam, it's raised from a use of bzrlib.ui.ui_factory.nested_progress_bar in bzrlib/transform.py
[19:23] <abentley> jam, my bad.  It's _factory.
[19:23] <jam> hmm... there is some confused imports in that file, given that 'ui' is in the lazy section and spelled out explicitly as 'bzrlib.ui'
[19:23] <abentley> jam, http://pastebin.ubuntu.com/476067/
[19:24] <jam> abentley: no it is 'ui', '_factory' is the LazyObject attribute that failed
[19:25] <abentley> jam, okay.  I thought you were looking for the attribute it wasn't liking.
[19:25] <jam> abentley: The attribute in the module, which is 'ui', not the attribute of the lazy object.
[19:26] <abentley> jam, right.
[19:26] <jam> Anyway, I've seen this when asking meliae to dump_all_objects() because it touches everything (In that after it is run, something crashes late)
[19:26] <jam> you might try excluding the meliae tests vs running everything
[19:26] <jam> (or including it :)
[19:26] <abentley> jam, I don't think the launchpad test suite runs the bzr test suite.
[19:27] <jam> abentley: not the bzr suite. But recently someone added meliae support to launchpad
[19:27] <abentley> jam, hmm.  Okay.
[19:27] <jam> and I've seen when running bzr, if I ^\ and do a dump, when the process finishes it crashes with the IllegalUse error
[19:28] <jam> I haven't quite tracked it down yet. (As I don't think meliae should be triggering, but I could see that it might when it tries to call __sizeof__)
[19:30] <abentley> jam, there are no tests that match 'meliae', so I'm not sure if we're testing it.
[19:31] <jam> abentley: you might grep the source for 'dump_all_objects()"
[19:33] <abentley> jam, only used in one place, and its test is disabled because it broke other tests.
[19:34] <jam> ok, so it isn't me triggering it (directly)
[19:35] <abentley> jam, no I was asking your advice partly because you're awake, and partly because you implemented lazy imports.
[19:36] <jam> abentley: you could try something trivial like: http://paste.ubuntu.com/476074/
[19:36] <jam> sorry, there is some noise there
[19:36] <jam> just the import ui change
[19:36] <abentley> jam, that noise looks strangely familiar :-)
[19:36] <jam> mostly I'm trying to help isolate the issue.
[19:37] <jam> this sort of thing usually occurs when you do
[19:37] <jam> from module import attribute
[19:37] <jam> and in module that is actually a lazy attribute
[19:37] <jam> spiv tracked down a case where a package imports a submodule and triggers this (if in bzrlib you used lazy_import to get bzrlib.ui, for example)
[19:41] <abentley> jam, since I can't reproduce the problem without doing a full test run, I've started a full test run with the import changed.
[20:14] <svaksha> hi, while pushing a branch bzr hangs with "|      2KB     0KB/s | Fetching revisions:Inserting stream ". Any idea why this happens? TIA.
[20:15] <svaksha> earlier today it allowed me to commit so at the moment i'm not sure if the error is due to the network or something else.
[20:20] <svaksha> never mind, problem solved, network issue
[20:26] <digitalice> hi
[20:26] <digitalice> how can i checkout a single file from a repo?
[20:26] <digitalice> like in git: git checkout folder/file.txt
[20:27] <abentley> digitalice, you can't checkout a single file, but you can get a copy of one using "bzr cat branch/file.txt > file.txt"
[20:28] <digitalice> no :S?
[20:28] <digitalice> mmm
[20:28] <maxb> huh
[20:28] <maxb> well sulk then :-)
[20:29] <maxb> I was about to suggest that 'bzr revert file' might actually be wanted
[20:30] <jam> abentley, maxb: given http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html
[20:30] <jam> it actually means he wanted "bzr revert"
[20:30] <maxb> yup
[20:30] <maxb> !blame git
[20:30] <jam> Apparently 'git checkout PATH' is revert the content
[20:30] <jam> to the explicit value
[20:31] <jam> not exactly what I think of for checkout, but maybe it fits gits model
[20:31] <jam> since 'git checkout' is turn the wt into a given revision (possibly based on branch pointer)
[20:32] <maxb> git has this madness where several commands do almost completely different things depending on whether they act on the whole tree or specific paths
[20:32] <abentley> jam, crazy.
[20:33] <jam> abentley: :)
[20:33] <jam> abentley: for https://code.launchpad.net/~abentley/bzr/revision-id-from-committer/+merge/32246 why only target 2.2 and not older releases?
[20:34] <ddaa> It probably makes some sense. My guess would be: ease of implementation
[20:34] <abentley> jam, the bug doesn't cause pain in earlier releases because they won't raise NoWhoami.
[20:34] <ddaa> since that seems to be an overriding design factor in git
[20:35] <jelmer> jam: As somebody who has used git on a regular basis, that use of "git checkout" doesn't make sense to me either.
[20:35] <rubbs> git is confusing
[20:35]  * rubbs is grateful he learned with bzr, it just makes sense
[20:42] <maxb> I agree - so much more that git, even a little more than mercurial, bzr's concepts and UI are definitely a strong point
[20:43] <maxb> (And to anyone who wonders what I meant about mercurial.... 'hg resolve' == 'bzr remerge')
[20:46] <rubbs> right, and to be honest I find the one directory per branch a feature. also the lack of a staging area (just why?) and sane by default actions.
[20:47] <rubbs> and the empty directory tracking has saved my bacon before
[20:47] <maxb> mhm. I'm not sold on the one directory per branch thing, but the rest, yes.
[20:49] <jelmer> maxb: There is a patch in progress to resolve that :-)
[20:50] <maxb> Yes. I'm eagerly looking forward to it :-)
[20:50] <maxb> It would help my case for adopting it at work, where we do java stuff. Java IDEs tend to make project setup / pointing at a new filesystem directory more heavyweight than it should be
[20:51] <maxb> Although Bazaar's lacklustre Eclipse support is likely still going to be a major sticking point
[20:51] <jelmer> maxb: I guess lightweight checkouts can be of use there, but unfortunately their setup is less trivial than colocated branches.
[20:52] <rubbs> ah, yeah I can see the colocation being an issue with IDE's. I'm a sysadmin so most of my "coding" is done in Vim.
[20:52] <maxb> The problem with lightweight checkouts is that they make sense to someone who has bought into bazaar, but look like a lot of work to someone who has not
[20:52] <krisives-gearbox> Does anyone know how nested branch support is started/coming along?
[20:53] <GaryvdM> jelmer: Did you want me to run the test suit on bzr-svn tip, or the last release?
[20:53] <jelmer> GaryvdM, tip please
[20:54] <GaryvdM> ok - Doing that now
[20:54] <jelmer> GaryvdM: also, thanks for doing so!
[20:54] <GaryvdM> Sure, np
[21:02] <GaryvdM> jelmer: Sorry - bug seems to still exist.
[21:03] <jelmer> GaryvdM: ok
[21:03] <jelmer> GaryvdM: Thanks for checking.
[21:03] <GaryvdM> jelmer: we need to nag vila to add our plugins to babune...
[21:03] <jelmer> yeah
[21:04] <GaryvdM> I'm also hoping to setup a daily build of the windows installers
[21:05] <abentley> krisives-gearbox, AFAIK, no one is working on it.
[21:09] <krisives-gearbox> abentley: Is the draft doc rather complete?
[21:10] <abentley> krisives-gearbox, I don't remember.  It certainly wasn't approved, though.
[21:11] <krisives-gearbox> abentley: Where would I go to help that get into motion? My employer wants the feature and is willing to commission it
[21:11] <abentley> krisives-gearbox, you shoul talk to poolie.
[21:12] <krisives-gearbox> abentley: Does that involve idling in IRC all the time ?
[21:13] <abentley> krisives-gearbox, he also can be emailed at mbp@canonical.com
[21:13] <GaryvdM> jam: I'm done on the ec2 instance. So you can shutdone if needed.
[21:13] <krisives-gearbox> Oh, Martin Pool
[21:13] <GaryvdM> jam: Can we please save it state to.
[21:13] <GaryvdM> jam: The paramiko patch is working nicely.
[21:15] <jam> GaryvdM: starting a bundle request now
[21:17] <GaryvdM> jam: Thanks for the use of it. Now that I have had the confidence of doing a few builds, I'm going to try build my own build host in a vm.
[21:17] <GaryvdM> Maybe setup nightly builds.
[21:23] <jam> GaryvdM: that would be nice. Though we may just want to get it set up on babune
[21:23] <jam> once vila gets back
[21:23] <jam> (next week)
[22:42] <latexer> hey everyone... when using bzr on windows (Win7), I was expecting to be able to put a .ssh/config file in place to override the User config for a certain host...
[22:42] <latexer> but it doesn't seem to obey/work.
[22:42] <latexer> I've tried in C:\Users\foo\.ssh\config and C:\Users\foo\AppData\Roaming\.ssh\config
[22:43] <latexer> neither seem to have an effect.
[22:43] <latexer> Any suggestions?
[22:44] <lifeless> are you using putty ?
[22:44] <lifeless> or openssh ?
[22:44] <lifeless> if you're using openssh, wherever your openssh looks for the config should work
[22:44] <latexer> AFAIK, openssh, I used the "standalone" installer to install bzr.
[22:44] <lifeless> if you're using putty, I think you need to use pageant or whatever
[22:44] <lifeless> the standalone installer uses putty I think
[22:44] <lifeless> what change do you need make on a per-host basis (there may be another way to change it)
[22:45] <latexer> lifeless: it says: "Connected (version 2.0, client OpenSSH_3.8.1p1)" when connecting...
[22:45] <maxb> Or perhaps bzr on windows might be using paramiko?
[22:46] <lifeless> latexer: ok definitely openssh then :)
[22:49] <latexer> lifeless: yeah, so I was trying the usual OpenSSH spots, no luck.
[22:50] <latexer> lifeless: suggestions for how to find out where OpenSSH is looking?
[22:51] <lifeless> well, we run ssh pretty simply
[22:51] <lifeless> uhm, sysinternals have a strace-like tool
[22:51] <lifeless> you could use that
[22:51] <latexer> lifeless: oh, indeed. I'll give that a try.
[22:51] <latexer> lifeless: thanks.
[23:53] <_habnabit> Is there a bzr command that just returns the URL a branch is bound to?
[23:53] <_habnabit> Nothing more or less.
[23:53] <Meths> bzr info with a bit of grep?
[23:54] <_habnabit> I was hoping to avoid post-processing.
[23:55] <_habnabit> I guess I could make a plugin to do it.
[23:56] <Meths> Well when a branch can have no URLs or many what kind of output do you actually want?
[23:56] <_habnabit> A branch can be bound to multiple URLs?
[23:56] <Meths> well, not bound probably, but push and pull can be different
[23:57] <_habnabit> Yeah. I'm only talking about the bound URL.
[23:57] <lifeless> bzr info only atm
[23:57] <lifeless> I think you need a 3-line python script / plugin
[23:57] <_habnabit> Mmkay.