[00:19] james_w: but the commit() call that tarmac is making, is passing committer='Tarmac' as an argument [00:19] it was working fine before i upgraded to 2.2.0 today [00:21] Is "bzr send" using a "mailto" url or something? [00:21] Not all MUAs support all the mailto query parameter extensions. [00:22] it worked fine in kde, just not gnome [00:22] probably a weird setting [00:23] Ahh, yeah. [00:47] Good morning. [00:48] hi there spiv [00:50] mkanat: just a note, the primary in-memory cache is brought down to disk in trunk with the bzr-history-db work [00:50] hi spiv [00:50] jam: Yeah, that's the primary thing that makes this possible. [00:50] jam: But the revision cache is still in memory, IIRC. [00:50] mkanat: it is, but it isn't as necessary [00:51] * mkanat nods. [00:51] ISTR there are times when it is useful [00:51] we would have to check [00:51] Yeah, there are times we have to map revids to revnos in a loop, IIRC. [00:51] we could push harder on moving it to disk if we had to [00:51] jam: I think that's probably what we'll do. [00:51] short-term denormalization of a given table [00:52] jam: But that won't work in the codehosting situation, will it? Because we can't write to the disk. [00:52] we can [00:52] it already does [00:52] Ah, okay. [01:13] dobey: well, that's when the error was added, so that's no surprise [01:19] dobey: is test_branch a file you have added? [01:20] dobey: and in your pastebin "a_branch.tree.commit("Reading, 'riting, 'rithmetic")" doesn't look like it is passing committer= [02:14] 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] reconfigure [02:15] fullermd: heh. that's too easy [02:16] Oh. Well, the Seven Trials of Courage, climbing the North Face of the Eiger, _then_ reconfigure. [02:17] fullermd: excelent. that's better [02:19] Anything for a steady customer :p [02:31] 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] mkanat: nothing springs to mind, i'd just suggest talking to chex or spm or similar if you see them online [03:00] poolie: All right. :-) === Ursinha is now known as Ursinha-afk [05:47] 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:47] Launchpad bug 559436 in Bazaar 2.1 "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 8, heat: 45)" [High,Fix released] https://launchpad.net/bugs/559436 [05:52] spiv: read all about it on the stable release update pacge [06:09] spiv, or see my previous mail about srus [06:20] 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] mtaylor: we use it in prod to import hg on lp.net. [06:22] mtaylor: go figure :P [06:22] lifeless: oh - well, that's something then :) [06:22] 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] http:// ? [06:23] I dunno [06:24] lifeless: hah! I was trying to make it much harder - doing hg+http :) [06:24] lifeless: thanks [06:59] 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] i don't think there's any good answer [07:11] we should have [07:11] the make-a-release chain is already pretty long [07:20] *nod* [07:27] 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] I may have done so even. [07:30] Hmm, I wonder where it is then... [07:31] https://bugs.edge.launchpad.net/ubuntu/+source/bzr needs some love [07:32] Yeah, I was just noticing that :( [07:33] https://code.edge.launchpad.net/~lifeless/ubuntu/lucid/bzr/2.1.2-sru [07:33] linked to bug 528041 [07:33] Launchpad bug 528041 in Bazaar 2.2 "bzr: ERROR: exceptions.AssertionError: _remember_remote_is_before((2, 1)) called, but _remember_remote_is_before((1, 6)) was called previously. (affected: 21, heat: 136)" [High,Fix released] https://launchpad.net/bugs/528041 [07:33] there you go [07:33] I was about to claim that I sucked [07:35] So where in the SRU process did that get stalled? [07:35] probably the usual place : the start [07:35] * lifeless takes off the bitter hat [07:35] Heh. [07:36] Well, it looks like we got past step 1 of https://wiki.ubuntu.com/StableReleaseUpdates#Procedure :P [07:44] 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] AIUI no [07:46] ww haven't set up per-package uploads for bzr and its in main [07:48] So we should subscribe ubuntu-sponsors to the bug to find a sponsor? [07:48] probably [07:48] you may need to nag someone [07:51] I'll sponsor it. [07:52] cody-somerville: thanks! [07:55] Does bzr have an exception from the TB to push entire new releases via -updates? [07:55] cody-somerville: no, and we're not asking for that [07:55] cody-somerville: these point releases are managing in an SRU way upstream [07:55] cody-somerville: if this is from 2.1.1 to 2.1.2 the changes should be compatible with the sru criteria [07:55] safe fixes for important bugs [07:57] This is from 2.1.1 to 2.1.2 [07:57] 47 files changed, 2926 insertions(+), 2331 deletions(-) [07:58] noooo [07:58] its either very mechanical, or something confused in udd [07:59] A heap of that is noise from Pyrex-generated C, I suspect. [07:59] bzr diff -r bzr-2.1.1..bzr-2.1.2 | diffstat [07:59] 34 files changed, 717 insertions(+), 160 deletions(-) [08:00] cody-somerville: ignore the .c files, they are autogenerated - equivalent to configure [08:00] Heh, yep, lots of /home/mbp/ became /home/robertc/ in Pyrex-generated comments in the C. [08:01] we should probably add some sed in there [08:04] urk [08:05] 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] rejected. [08:05] hm [08:05] we have done previous SRUs on similar changes [08:08] 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] ok [08:08] Expedite the process in future, anyway, perhaps not expedite this particular SRU ;) [08:09] so in the interim, do you want to merge the patch just for this change? [08:09] i find it a bit hard to believe that will be much safer but i understand the general process [08:09] 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] 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] 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] Launchpad bug 559436 in Bazaar 2.1 "AttributeError: 'NoneType' object has no attribute 'get_config' (affected: 8, heat: 45)" [High,Fix released] https://launchpad.net/bugs/559436 [08:10] cody-somerville: and how do we get that approval? [08:11] subscribe ubuntu-sru team [08:11] and then possibly poke someone on the team [08:20] spiv, can you do that? [08:36] * bialix waiting for Garyvdm [08:37] hi bialix [08:37] hi poolie ! === oubiwann is now known as oubiwann-away [08:46] poolie: sure [08:48] (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) === oubiwann-away is now known as oubiwann [08:49] spiv, so re https://bugs.edge.launchpad.net/launchpad/+bug/615740 [08:49] Launchpad bug 615740 in Launchpad itself "test_on_merge.py doesn't handle eintr (affected: 1, heat: 6)" [Undecided,New] [08:49] what the best plan for handling eintr now? [08:49] such a saga... === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [09:02] poolie: depends! [09:03] so there's one select call that's failing [09:03] poolie: don't have any signal handlers is a good plan, if you can [09:03] oddly, raising select.error not IOError [09:04] poolie: if you can't, register it with signal.siginterrupt is good, if you can assume python >= 2.6.6 [09:05] 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] select at least is safe to retry the call, if it's happening in your own code. [09:05] i think it is [09:06] i don't know if lp assumes 2.6.6 yet? [09:06] probably not [09:08] Given that 2.6.6rc1 only just hit maverick, I doubt it :) [09:10] 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] yay [10:03] hi.. how do I get only a list of modified/added files for the last few commits? [10:22] dakira: bzr st -r -3 (last two commits) [10:42] luks: great.. thx! === khmarbaise__ is now known as khmarbaise [10:44] 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] fullermd: so "-r -3" == "-r-3.."? [10:46] No, "-r-3" == "-r-3"... I don't think there's any long form. "-r-3.." == "-r-3..-1" [10:47] fullermd: look closely... not "-r-3" but "-r-3".. the latter seems to be equivalent to "-r-3.." [10:47] "-r-3.." != "-r-3..-1" because the range is exclusive [10:47] They're the same thing, space or not. [10:48] Standard option parsing. [10:48] Er, -r-3.. IS exactly the same as -r-3..-1. Open ended ranges go to the end of the tree. [10:48] then my bzr is doing something wrong :) [10:48] (well, mod some bugs that have existed in the past with parsing them at least) [10:49] oh [10:49] my bad [10:49] it's sorted differently [10:50] I wonder why -r-3..-1 isn't sorted [10:52] Any other day, I'd say "I dunno". Today, the answer is obviously "the world is out to get me". [10:54] 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] That's... unexpected. [10:55] I occasionally think that -0 should mean "working tree". [10:55] I'd rather have a tree: or something. [10:56] Then I go have a nice cup of tea in a quiet corner somewhere and reason returns ;) [10:56] 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] spiv: Really, it should be "+1" ;p [10:57] fullermd: no, 0 comes after -1 [10:57] fullermd: and the uncommitted working tree is the nearest thing we have to the next revision after the most recently committed one... [10:57] Yes, but 0 is already taken for null. Anyway, we want to go one rev forward from the current state, so... [10:57] Right, hence -0 ;) [10:58] Of course, since it's not committed yet, it's not real. So, it should be 'i'. [10:58] 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] $\lim_{revno\to 0}revision(revno)$ [11:01] fullermd: here's what I get http://pastebin.com/NvRWeNWq [11:01] Or something. [11:01] * spiv wanders off [11:02] bzr is 2.1.1 === Ursinha-afk is now known as Ursinha === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [14:15] james_w: a_branch is a tarmac.Branch, and its commit method calls the bzr commit with committer='Tarmac' [14:16] 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] http://bazaar.launchpad.net/~rockstar/tarmac/main/annotate/head%3A/tarmac/branch.py [14:24] http://bazaar.launchpad.net/~rockstar/tarmac/main/annotate/206/tarmac/tests/test_branch.py#L40 [14:25] ddaa: hello [14:25] hey bialix [14:25] 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 === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [14:37] 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] 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] hi jelmer [14:42] hi jelmer [15:03] ah, how the little things can wreck havoc [15:08] a_branch.*tree*.commit() is not a_branch.commit(). sorry :) [15:09] hehe [15:09] been there, done that.. with the exact same method. [15:28] 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] dobey, the latter [15:29] dobey: see also "bzr cat-revision", that will dump the raw representation of a revision [15:29] ah [15:30] thanks === deryck is now known as deryck[lunch] [15:49] 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] I've been trying to backtrack to find the test that is abusing the scope replacer, but so far no dice. [15:53] nope, 's one of the oddities I've run into before and not had time to track down. [15:54] a bunch of the doctests fall over with it on ironpython and jython. [15:54] mgz, with the Launchpad test suite or the bzr test suite? [15:54] in bzr, sorry. [16:36] If I push to a location, why would then running bzr update in that location produce "bzr: ERROR: No WorkingTree exists" [16:36] jam: For some reason, paramiko is no longer being included in libary.zip [16:36] hmmm. I wonder if it got installed as a plain .egg [16:37] .egg doesn't work with py2exe [16:37] Typh: If you push to a remote location, working trees are not created. [16:37] jam: Yes - It is installed as an .egg [16:37] Typh: you can create the working tree by running bzr checkout [16:38] GaryvdM: oh. oops :D. thanks. [16:38] 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] Typh: This is due to limitations in the remote protocols. [16:39] heya Gary! [16:39] Hi bialix [16:40] did you saw my messages? [16:40] bialix: Yes - was just going to reply. [16:40] 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] ok [16:41] 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] Typh: ah, cool. Just checking. [16:41] bialix: Surely there is a syntax that will work for both versions. I'll take a look. === Ursinha is now known as Ursinha-afk [16:46] GaryvdM: I'll log in now and try to fix that [16:51] 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] bialix: Please could you see if this runs with pyqt4.4: http://pastebin.org/466026 [16:56] GaryvdM: with your patch test suite did not errored, but tests failed === deryck[lunch] is now known as deryck [16:56] GaryvdM: it should be fixed now, care to try again? [16:56] jam: Thanks [16:57] bialix: Please pastebin test output. [16:57] GaryvdM: that paste writes success, but is it really success? === Ursinha-afk is now known as Ursinha [16:58] bialix: Yhea - need to check that it's actually connected.... [16:58] GaryvdM: http://pastebin.org/466035 [17:10] 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] ouch! [17:11] Funny that they are connecting in qt 4.4, and not 4.6/4.7. === beuno is now known as beuno-lunch [17:16] GaryvdM: I would like to add direct support of colo in qbzr. E.g for commands qswitch, qmerge, maybe others [17:16] 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] is there way to bind branch multiple times? [17:33] jam: Thanks - that worked. [17:34] jam: Is there an easy to test the speed of paramiko? I'd like to see if my patch makes it faster. [17:34] 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] I don't really know how to set that up, though [17:35] ok [17:35] probably you could do something with a loopback to openssh via sftp, and just try to read a 1GB file [17:35] or ssh localhost dd if=/dev/urandom [17:35] or something like that [17:36] 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] doesn't urandom wait for entropy? [17:37] CcxCZ: I thought /dev/random did and /dev/urandom layered cryptographic randomness on top of entropy [17:37] psuedorandomness [17:38] A read from the /dev/urandom device will not block waiting for more entropy. [17:38] * CcxCZ RTFMed [17:38] Yeah, it's the other way around. urandom doesn't block; random does. [17:39] though that's not very good for benchmark I guess [17:40] 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] That handles all of the "how do I set up paramiko" stuff :) [17:41] jam: I specifically want to see if I'v removed the "1-2 seconds" that you mention in Bug 271791 [17:41] Launchpad bug 271791 in paramiko "Paramiko depends on RandomPool (affected: 3, heat: 17)" [Medium,Triaged] https://launchpad.net/bugs/271791 [17:41] GaryvdM: well that is easy to tell [17:41] bzr log sftp://host [17:41] we've patched pycrypto repeatedly for that IIRC [17:42] however, you also have to have a system where time.time()'s resolution is 15ms [17:42] 1ms is fast enough to not really notice 100 calls. [17:42] 1ms == 100ms total, 15ms == 1.5s total, very noticeable [17:42] you can do a loop on time.time() to determine the resolution [17:43] 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] jam: I have 1ms time.time() resolution, so I guess I won't be able to test. [17:45] GaryvdM: well, IIRC 'import paramiko' triggered it, you could see if it takes 100ms to do so. [17:45] However, I'm pretty sure that code doesn't exist in pycrypto 2.1+ [17:45] 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] 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] dobey: can you elaborate on that? [18:02] 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] 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] but it's not clear to me how to do that exactly [18:08] 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] dobey: Maybe take a look at what bzr missing does. [18:12] debey: It will involve some graph call, which, I'm not sure. [18:16] dobey: If you look at bzrlib.missing._find_unmerged , It's quite clear. [18:17] Instead if the remote_branch.last_revision_info(), use the last revision that you used when you looked at the branch. [18:18] dobey: You can also look at the revisons that have been removed from branch using uncommit, or pull/push --overwrite === beuno-lunch is now known as beuno [18:23] 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] jam, do you have any suggestion how to debug it? [18:32] GaryvdM: hrmm, i'm doing a missing._find_unmerged to try and see what's going on, and i get an error: [18:32] bzrlib.errors.ObjectNotLocked: is not locked [18:33] dobey: Things are normally locked by missing.find_unmerged, which then calls missing._find_unmerged [18:34] dobey: I pointed out _find_unmerged, because thats were the interesting code is. [18:34] ah [18:48] GaryvdM: thanks! [19:21] abentley: does it tell you the name of the variable it isn't liking? [19:21] jam, "ui". [19:22] jam, it's raised from a use of bzrlib.ui.ui_factory.nested_progress_bar in bzrlib/transform.py [19:23] jam, my bad. It's _factory. [19:23] 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] jam, http://pastebin.ubuntu.com/476067/ [19:24] abentley: no it is 'ui', '_factory' is the LazyObject attribute that failed [19:25] jam, okay. I thought you were looking for the attribute it wasn't liking. [19:25] abentley: The attribute in the module, which is 'ui', not the attribute of the lazy object. [19:26] jam, right. [19:26] 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] you might try excluding the meliae tests vs running everything [19:26] (or including it :) [19:26] jam, I don't think the launchpad test suite runs the bzr test suite. [19:27] abentley: not the bzr suite. But recently someone added meliae support to launchpad [19:27] jam, hmm. Okay. [19:27] 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] 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] jam, there are no tests that match 'meliae', so I'm not sure if we're testing it. [19:31] abentley: you might grep the source for 'dump_all_objects()" [19:33] jam, only used in one place, and its test is disabled because it broke other tests. [19:34] ok, so it isn't me triggering it (directly) [19:35] jam, no I was asking your advice partly because you're awake, and partly because you implemented lazy imports. [19:36] abentley: you could try something trivial like: http://paste.ubuntu.com/476074/ [19:36] sorry, there is some noise there [19:36] just the import ui change [19:36] jam, that noise looks strangely familiar :-) [19:36] mostly I'm trying to help isolate the issue. [19:37] this sort of thing usually occurs when you do [19:37] from module import attribute [19:37] and in module that is actually a lazy attribute [19:37] 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] 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] hi, while pushing a branch bzr hangs with "| 2KB 0KB/s | Fetching revisions:Inserting stream ". Any idea why this happens? TIA. [20:15] 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] never mind, problem solved, network issue [20:26] hi [20:26] how can i checkout a single file from a repo? [20:26] like in git: git checkout folder/file.txt === verterok1 is now known as verterok [20:27] 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] no :S? [20:28] mmm [20:28] huh [20:28] well sulk then :-) [20:29] I was about to suggest that 'bzr revert file' might actually be wanted === oubiwann is now known as oubiwann-away [20:30] abentley, maxb: given http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html [20:30] it actually means he wanted "bzr revert" [20:30] yup [20:30] !blame git [20:30] Apparently 'git checkout PATH' is revert the content [20:30] to the explicit value [20:31] not exactly what I think of for checkout, but maybe it fits gits model [20:31] since 'git checkout' is turn the wt into a given revision (possibly based on branch pointer) [20:32] 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] jam, crazy. [20:33] abentley: :) [20:33] 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] It probably makes some sense. My guess would be: ease of implementation [20:34] jam, the bug doesn't cause pain in earlier releases because they won't raise NoWhoami. [20:34] since that seems to be an overriding design factor in git [20:35] 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] git is confusing [20:35] * rubbs is grateful he learned with bzr, it just makes sense [20:42] 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] (And to anyone who wonders what I meant about mercurial.... 'hg resolve' == 'bzr remerge') [20:46] 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] and the empty directory tracking has saved my bacon before [20:47] mhm. I'm not sold on the one directory per branch thing, but the rest, yes. [20:49] maxb: There is a patch in progress to resolve that :-) [20:50] Yes. I'm eagerly looking forward to it :-) [20:50] 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] Although Bazaar's lacklustre Eclipse support is likely still going to be a major sticking point [20:51] maxb: I guess lightweight checkouts can be of use there, but unfortunately their setup is less trivial than colocated branches. [20:52] 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] 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] Does anyone know how nested branch support is started/coming along? [20:53] jelmer: Did you want me to run the test suit on bzr-svn tip, or the last release? [20:53] GaryvdM, tip please === oubiwann-away is now known as oubiwann [20:54] ok - Doing that now [20:54] GaryvdM: also, thanks for doing so! [20:54] Sure, np [21:02] jelmer: Sorry - bug seems to still exist. [21:03] GaryvdM: ok [21:03] GaryvdM: Thanks for checking. [21:03] jelmer: we need to nag vila to add our plugins to babune... [21:03] yeah [21:04] I'm also hoping to setup a daily build of the windows installers [21:05] krisives-gearbox, AFAIK, no one is working on it. [21:09] abentley: Is the draft doc rather complete? [21:10] krisives-gearbox, I don't remember. It certainly wasn't approved, though. [21:11] abentley: Where would I go to help that get into motion? My employer wants the feature and is willing to commission it [21:11] krisives-gearbox, you shoul talk to poolie. [21:12] abentley: Does that involve idling in IRC all the time ? [21:13] krisives-gearbox, he also can be emailed at mbp@canonical.com [21:13] jam: I'm done on the ec2 instance. So you can shutdone if needed. [21:13] Oh, Martin Pool [21:13] jam: Can we please save it state to. [21:13] jam: The paramiko patch is working nicely. === Ursinha is now known as Ursinha-lunch [21:15] GaryvdM: starting a bundle request now [21:17] 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] Maybe setup nightly builds. [21:23] GaryvdM: that would be nice. Though we may just want to get it set up on babune [21:23] once vila gets back [21:23] (next week) === oubiwann is now known as oubiwann-away === Ursinha-lunch is now known as Ursinha-afk === oubiwann-away is now known as oubiwann === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann === oubiwann is now known as oubiwann-away [22:42] 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] but it doesn't seem to obey/work. [22:42] I've tried in C:\Users\foo\.ssh\config and C:\Users\foo\AppData\Roaming\.ssh\config [22:43] neither seem to have an effect. [22:43] Any suggestions? [22:44] are you using putty ? [22:44] or openssh ? [22:44] if you're using openssh, wherever your openssh looks for the config should work [22:44] AFAIK, openssh, I used the "standalone" installer to install bzr. [22:44] if you're using putty, I think you need to use pageant or whatever [22:44] the standalone installer uses putty I think [22:44] what change do you need make on a per-host basis (there may be another way to change it) [22:45] lifeless: it says: "Connected (version 2.0, client OpenSSH_3.8.1p1)" when connecting... [22:45] Or perhaps bzr on windows might be using paramiko? [22:46] latexer: ok definitely openssh then :) [22:49] lifeless: yeah, so I was trying the usual OpenSSH spots, no luck. [22:50] lifeless: suggestions for how to find out where OpenSSH is looking? [22:51] well, we run ssh pretty simply [22:51] uhm, sysinternals have a strace-like tool [22:51]