[00:00] <ScottK> poolie: I didn't know about bzr remove-branch when I filed the bug.  Apparently lifeless didn't either as he didn't suggest it ...
[00:01] <ScottK> So if that had worked, I'd have been happy.
[00:02] <ScottK> It may just be that bzr on alioth is too old (2.1.5.)
[00:02] <ScottK> poolie: Does that clarify it?
[00:04] <poolie> yep
[00:04] <poolie> actually i answered, and i had forgotten it was now built in
[00:04] <poolie> maybe robert did too
[00:04] <poolie> given all this i think it's not an upstream bug
[00:06] <poolie> do you agree?
[00:06] <poolie> it's probably not something we would put back into the 2.1 series
[01:23] <ScottK> I agree it shouldn't be backported.
[01:31] <lifeless> poolie: hi, https://bugs.launchpad.net/launchpad/+bug/717094 - may benefit from a bzr person eyeballing it
[01:31] <poolie> hi lifeless
[01:32] <lifeless> poolie: hi :)
[01:33] <mgz> that bug description sounds like it's my kind of thing.
[01:33] <lifeless> mgz: its in the lp bzr codehosting stack
[01:34] <mwhudson> oh what, i thought i fixed all of them
[01:34] <lifeless> tada
[01:35] <mwhudson> oh
[01:37]  * mwhudson preemptively hates mod_rewrite a bit
[01:37] <poolie> i'm happy to hand it to either of you
[01:39] <mgz> ...maybe I'll get a copy of launchpad in may, I've never succeeded in branching it.
[01:41] <mwhudson> poolie: i think you can keep it :)
[01:41] <mgz> the bzrlib side seems too strict for urls that might just get entered by hand, I don't see a mod_rewrite fix unless you do something like surrogate-escape does.
[01:42] <jam> mwhudson, lifeless: sorry I didn't make it back before. Fell asleep while putting my son to sleep.
[01:42] <jam> Note that the fix for loggerhead (mentioned elsewhere) should probably be using urllib.quote(path.encode('utf-8'))
[01:42] <mwhudson> poolie: strange that clicking download on the file with chinese characters on http://bazaar.launchpad.net/~czhedu/+junk/hi_baidu_com_xxai/files works though
[01:42] <jam> rather than cgi.escape()
[01:42] <jam> since it is URL stuff, rather than HTML content stuff.
[01:42] <jam> and I wonder if this isn't something similar
[01:43] <jam> where we are generating a url and escaping it via the wrong transformation
[01:43] <lifeless> jam: mwhudson: ECHANNEL
[02:06] <poolie> go to bed jam! :)
[02:08] <jam> poolie: well, I slept a little bit already
[06:51] <mr-russ> spiv: are you online?
[06:52] <spiv> mr-russ: I am
[06:53] <mr-russ> cool.  I'm the bzr as single user doc patch guy.
[06:53] <spiv> I just figured that out :)
[06:53] <spiv> Did my review make sense?
[06:53] <mr-russ> The reason I wrote the doc is I was one of the users you mention and I couldn't find how to do it.
[06:54] <mr-russ> Your review makes sense.  However my bzr doc skillz are basically zero.
[06:54] <spiv> Apparently better than that!
[06:54] <mr-russ> I get the idea, but I don't know how to build the docs, or view the tags.
[06:54] <mr-russ> and the :: type stuff, I don't know where I might find out more about that.
[06:54] <mr-russ> So I'm happy to give it a try, but I feel like I might need a bit of formatting help.
[06:55] <spiv> 'make docs-sphinx'
[06:55] <spiv> That should build the docs, you probably need to install some dependencies to have that work
[06:55] <mr-russ> package hunting now.
[06:56] <poolie> thanks for adding that mr-russ
[06:56] <spiv> The format is called restructured text
[06:56] <mr-russ> It's probably the biggest barrier to switching from svn.  How to do an svn type setup easily on bzr.
[06:57] <mr-russ> I tried apache route but too hard, danger.  But it was documented mostly :)
[06:58] <spiv> http://sphinx.pocoo.org/rest.html is a good intro, and http://sphinx.pocoo.org/contents.html in general for the overall documentation tool we're using (sphinx)
[06:59] <mr-russ> my question/concern about the bzr_ssh_path_limiter is that it's not installed by default.  So it's more work to make it all go.
[06:59] <mr-russ> I don't even know how to install it under ubuntu.
[06:59] <spiv> mr-russ: fwiw, the only svn repo I interact with regularly is via a regular ssh account with a real user and home dir etc :)
[06:59] <spiv> Yeah, that's a good point.
[06:59] <spiv> I guess the obvious question is where should it be installed?  I suppose /usr/bin would be reasonable
[07:00] <spiv> (for the Ubuntu package at least)
[07:00] <mr-russ> /usr/bin is obvious.  lots of debian packages just put contrib in a /usr/share/bzr/contrib type area.
[07:00] <spiv> But you could install it anywhere, really
[07:00] <spiv> And just adjust the command="..." config to give the full path to it
[07:01] <mr-russ> But for this kind of documentation, having it easy for a new user is key from my perspective.
[07:01] <mr-russ> so if it gets installed by default for 2.4.x, then we can change the command.
[07:01] <spiv> /usr/share/doc/bzr/contrib would be better than nothing, but not great.
[07:02] <spiv> I'm happy to avoid mentioning bzr_ssh_path_limiter for now until it genuinely becomes easy
[07:02] <spiv> (i.e. have it installed somewhere by default)
[07:02] <spiv> You should definitely fix the missing --inet though :)
[07:03] <mr-russ> yeah, waiting for doc build to finish.
[07:04] <mr-russ> My 5 year old laptop is okay, not brilliant.
[07:04] <mr-russ> how can I improve my markup knowledge?
[07:04] <mr-russ> :: is an example, is there a reference file, or anything else basic to know.
[07:05] <mr-russ> spiv: thanks for the review though.  Very helpful.  As you can see I'd like to get this completed :)
[07:05] <spiv> The links to sphinx.pocoo.org I gave above are probably the best source for docs about the doc system
[07:06] <spiv> Heh, although their ReST primer doesn't mention ::
[07:07] <spiv> http://docutils.sourceforge.net/docs/user/rst/cheatsheet.txt, http://docutils.sourceforge.net/docs/user/rst/quickstart.html
[07:07] <spiv> Specifically for preformatted text with :: -> http://docutils.sourceforge.net/docs/user/rst/quickstart.html#preformatting-code-samples
[07:08] <spiv> Ok, I'm off for a little bit
[07:10] <poolie> cheerio spiv, see you in a bit
[07:37] <vila> hi all !
[07:39] <mr-russ> my bzr newbieness has got me again.
[07:39] <mr-russ> I bzr pulled from the bzr branch.
[07:39] <mr-russ> It says I've diverged and need to merge.  I ran bzr merge and there are all these files for me to commit.
[07:40] <mr-russ> Should I commit them, but what message do I put?  is there a default merged commit message?
[07:42] <spiv> mr-russ: "Merge trunk." or similar
[07:43] <spiv> A commit message is generally used to describe what you did, and that's what you did :)
[07:43] <mr-russ> thanks.
[07:43] <mr-russ> my first use of shelving my changes, merge and unshelve.
[07:43] <poolie> spiv, jam, vila, want to chat in a couple of minutes?
[07:43] <vila> sure
[07:43] <jam> poolie: sure
[07:43] <spiv> Yes, let's :)
[07:44] <vila> here or mumble ?
[07:44] <poolie> let's mumble?
[07:45] <jam> I'm on mumble with spiv

[07:47] <jam> vila: same problems today?
[07:47] <jam> vila: can you hear us at least?
[07:47] <vila> yup
[07:48] <mr-russ> okay, my next attempt is up, I'll leave it for you all to review.
[07:48] <spiv> mr-russ: thanks!
[07:48] <jam> jelmer: if you're up, we're on mumble
[07:48] <jam> spiv: your' mic is locking "on" with background noise
[07:53] <poolie> spiv?
[07:56] <spiv> poolie: X crashed and apparently took my whole system with it
[07:56] <poolie> wow
[07:56] <poolie> insert xkcd joke about '2003 called'
[07:57] <jam> poolie: did you warn them?
[07:57] <spiv> (I'm back)
[08:12] <xarinatan> May i ask a silly simple question? How do i set the remote username in the windows bzr interface? It keeps using my workstation's username, like so http://j.mp/enNaNX
[08:13] <jam> xarinatan: you can do it in the URL, "http://myuser@host/"
[08:16] <xarinatan> Ah, thanks, i vaguely heard of that before, but i did user@bzr+ssh://hostname instead ^^; thanks again
[08:35] <jam> anyone care to second review: https://code.launchpad.net/~mgiuca/bzr/test-log-show-ids/+merge/54199
[08:35] <jam> I'm actually going to be afk for a while, taking my son to the doctor.
[08:40] <jelmer> jam: I'll have a look
[08:47] <xarinatan> is it normal that bzr stays a while in the background after committing, seeming to do a lot of processing?
[08:48] <xarinatan> http://j.mp/h4CpWR (taskmanager screenshot)
[08:49] <jelmer> xarinatan: "bzr commit" (the command) should exit right after it's finished
[08:49] <jelmer> perhaps something else has started it in this case though (e.g. tortoisebzr?)
[08:50] <xarinatan> jelmer: I used tortoisebzr to commit data to my server, but after that finished and the window closed, that process stayed for a while, 2 processes at first, now they're both gone, just wondering if it's normal
[08:53] <xarinatan> I gotta say though, i just switched from SVN to BZR and i like it a lot better, SVN simply wasn't usable for my needs (versioned backup for my project/school data sticks) and bloated my data a lot, especially clientside made that unusable for me
[08:56] <bob2> to be fair, most things are better than svn :)
[08:57] <xarinatan> Heh, true i suppose, but SVN is sort of the 'standard' these days. Kind of like how IPv4 is still the standard for internet communication :P
[08:57] <xarinatan> But that could be me
[09:19] <jelmer> xarinatan: I suspect it's got something to do with how tortoisebzr works, but I'm not sure.
[11:29] <jam> anyone care to give a second review to: https://code.launchpad.net/~mgiuca/bzr/log-not-in-branch/+merge/53955
[11:30] <Peng> Nice, ubot5.
[11:53] <jelmer> jam: I'm on it
[11:53] <jam> jelmer: thanks
[11:58] <jam> thanks for the earlier one, too
[11:58] <jelmer> jam: least I could do after all the reviews two weeks ago :)
[11:58] <jelmer> jam: Did you see the bug I filed about get_revisions / revision_trees / get_deltas ?
[11:58] <jam> jelmer: sounds hazy
[11:59] <jelmer> jam: Basically, "bzr log" uses those methods underneath but if one of the specified revids is a ghost the entire method will fail.
[12:00] <jelmer> the simple solution is to use the singular fetch functions so when we get a NoSuchRevision exception we know which revision is missing
[12:00] <jelmer> but that obviously has performance consequences
[12:00] <jam> jelmer: can we do X and then fall back to Y if there is a problem?
[12:00] <jam> or not easily?
[12:00] <jam> it shouldn't have the same implications it used to
[12:00] <jam> we used to be spending all our times deserializing the inventories
[12:00] <jam> which should be much better now
[12:03] <jam> jelmer: you're the one packaging meliae, right?
[12:03] <jelmer> jam: We can't fall back easily as far as I can tell
[12:03] <jam> have you seen bug #735284
[12:03] <jam> i'm just trying to understand who is running 'sdist' and why
[12:03] <jam> rather than, say, running 'setup.py install'
[12:03] <jam> I know *I* build the tarball using "bzr export ../foo.tar"
[12:04] <jelmer> jam: Yep, I'm packaging it for Debian and Ubuntu.
[12:04] <jelmer> jam: I don't use sdist, the packaging magic simply runs "setup.py install" directly from the packaging branch (which is derived from your trunk with an extra debian/ dir)
[12:15] <spiv> jelmer: just briefly
[12:15] <spiv> jelmer: some of the new fetch_spec stuff has a if_present_ids param (or something like that)
[12:16] <spiv> jelmer: because e.g. when fetching revisions named by tags we want to fetch them if they exist, but not fail if they turn out to be not present in that repo
[12:16] <spiv> jelmer: perhaps that concept is what that "bzr log" issue needs
[12:17]  * spiv -> zzz
[12:17] <jelmer> spiv: We do want to know about missing revisions, since they should still be mentioned in log as being missing
[12:17] <jelmer> spiv: anyway,  perhaps we can discuss that later. G'night!
[12:18] <jam> jelmer: we could have 'revision_trees' return None rather than raising an exception, as an example
[12:18] <jam> possibly by adding a flag so that current users of the api aren't surprised
[12:26] <jelmer> jam: Yeah, it's the current callers I'm worried about. A flag would work.
[12:32] <jelmer> jam: Perhaps returning an AbsentTree rather than None, so we can still access the relevant revision id?
[12:32] <jam> jelmer: something like that seems fine to me
[12:32] <jam> I thought revision_trees always returned in order
[12:32] <jam> and most callers zip the input list with the returned values
[12:33] <jam> I could be wrong
[12:34] <xarinatan> Hey guys, i'm getting a weird error when trying to commit a lot of data with tortoise bzr http://pastebin.com/XMtwzW0r can someone help me?
[12:35] <jam> xarinatan: so usually "TooManyConcurrentConnections" is actually a failure somewhere else, that is then covered up by us getting an error while running the cleanup code to handle the original error.
[12:36] <jam> I'm very surprised to see this happening during the "_rpc_open_2_1"
[12:36] <jam> since it indicates it is happening before we've even connected to the other branch.
[12:37] <xarinatan> Weird, i am currently SSH'd into that server with said username and everything seems fine
[12:37] <xarinatan> I had the same error earlier and i couldn't find out why it did, so i recreated the repository and first checked in a small bit of data, that worked fine
[12:41] <xarinatan> Small bits of data seem to go fine
[12:46] <xarinatan> the 'big' commit was ~340MB, 25756 files
[12:47] <xarinatan> oh wait, apparently the 'small' commit was bigger then i thought, about 720MB
[12:47] <xarinatan> but only 250 files
[12:52] <xarinatan> Maybe i'm overfilling some buffers or my RAM if i commit that much files..
[12:57] <dOxxx> good morning
[12:57] <vila> hey dOxxx !
[12:57] <dOxxx> vila: quick question re plugin versions
[12:57] <vila> yup, fire it :)
[12:58] <dOxxx> vila: should I be using trunk for all plugins or just the two that didn't work with bzr 2.4b1?
[12:58] <dOxxx> didn't load*
[12:58] <vila> hehe, tricky one ;)
[12:58] <dOxxx> I was thinking I should only do it for hte plugins which didn't load
[12:58] <vila> the conservative answer would be: switch to trunk when something bad happen
[12:59] <dOxxx> I don't want to distirbute tip for all plugins and then have to switch back for final release because the author never made a stable release
[12:59] <vila> the aggressive one would be: always use trunk until we approach the .0 release
[12:59] <vila> exactly
[12:59] <vila> plus some trunks may be bogus
[12:59] <dOxxx> yeah
[12:59] <vila> on the other hand, we have beta releases to *expose* the latest and greatest
[13:00] <dOxxx> bleh
[13:00] <vila> ?
[13:00] <dOxxx> just an annoying situation
[13:00] <vila> yeah
[13:00] <dOxxx> I don't have time to test all the plugins
[13:01] <vila> I think it's a balance between packagers and plugin authors being pro-active or not
[13:01] <vila> yup, the installer focused test suite...
[13:01] <dOxxx> it would be nice
[13:01] <vila> ... which still doesn't exist :-/
[13:01] <dOxxx> something that exercises all the bundled plugins to see that nothing blows up
[13:01] <vila> but indeed would help
[13:02] <vila> yeah, so, what we currently have is the daily builds which help decide which plugin versions should be distributed
[13:02] <dOxxx> we do?
[13:03] <vila> but the ppas imply that *some* version is defined and tracked in a branch
[13:03] <vila> dOxxx: for Ubuntu yes
[13:04] <vila> dOxxx: for 2.4b1, I'd say just switch bzr-pipeline to tip
[13:04] <dOxxx> and svn
[13:04] <vila> jelmer: is there a 2.4-compatible release for bzr-svn ?
[13:05] <vila> jelmer: or is the trunk tip good enough to embed in the 2.4b1 OSX installers ?
[13:07] <xarinatan> Can someone point me to what i should change or how i can fix this error: http://pastebin.com/XMtwzW0r ? small commits are fine (<1000 files) but large commits seem to give that error
[13:10] <maxb> The implication is a bug in bzr, but that's not something I've ever seen.
[13:12] <vila> xarinatan: there nothing obvious there, file a bug at http:/pad.lv/fb/bzr
[13:12] <vila> xarinatan: that would be easier to track progress and ask you for more details
[13:12] <xarinatan> vila: Okay, i'll do that then.
[13:13] <vila> xarinatan: the weird thing is that the *size* of the commit shouldn't matter...
[13:15] <vila> xarinatan: the only vaguely similar issue I can think of was one related to ssh key renegotiation when reaching a 1GB threshold (on transmitted data) but 1) I'm pretty sure launchpad has some specific config that was exhibiting it 2) the symptom was different
[13:16] <vila> xarinatan: did you look at the .bzr.log on the server ?
[13:16] <xarinatan> Well it's only 70MB of data, but nearly 10,000 files
[13:17] <xarinatan> 'small' commits of 720MB with only 250 files go through just fine
[13:17] <xarinatan> So i'm suspecting some buffer overflow maybe?
[13:18] <vila> xarinatan: add the relevant parts of the .bzr.log from client and server to the bug report, there may be something there
[13:19] <vila> xarinatan: there are bigger projects (in terms of # files), but 720MB for 250 files sounds big, any binaries there ? (Shouldn't matter either..)
[13:21] <xarinatan> Some archive(zip) files and images, i was planning on using bazaar as 'versioned backup system' for my School and work project data sticks, which both hold about 5 gigs of data, of which most is 100% original content created by me, so for that this system would be perfect if it works ^^;
[13:22] <xarinatan> I have a lightweight ubuntu virtual machine setup at home for the data storage
[13:22] <vila> xarinatan: hmm, there was a report recently about some weird ssh issues when using NAT for a VM
[13:22] <xarinatan> Where can i find the .bzr.log file btw?
[13:23] <vila> what virtualization software are you using ?
[13:23] <xarinatan> It's not NATted
[13:23] <xarinatan> I'm using KVM
[13:23] <xarinatan> I'm logging in through OpenVPN..
[13:23] <dOxxx> `bzr version` will tell you where your log file is
[13:24] <vila> xarinatan: like dOxxx said, but make sure you run it on the server with the same settings as the user connecting there
[13:24] <xarinatan> what do you mean by 'same settings'?
[13:25] <vila> xarinatan: just do 'ssh user@host  bzr version' and you should be fine
[13:26] <xarinatan> Oh! That could be it, i'm using the default ubuntu repos for the bzr installation, those might be a bit behind on the actual version
[13:27] <xarinatan> Hah, yes, stupid me, the server is running 2.2.1 and i'm running 2.3.1 on the client ^^;..
[13:28] <xarinatan> Weird that it works with smaller commits though
[13:28] <vila> xarinatan: still worth reporting as a bug mentioning the client/server versions involved
[13:29] <xarinatan> villa: Will do
[13:29] <vila> xarinatan: this should be supported, servers can't always be upgraded as fast as clients and they are supposed to be compatible
[13:29] <vila> xarinatan: it's not even sure that upgrading the server will address the issue
[13:31] <vila> good afternoon mgz ;)
[13:31] <xarinatan> I'll check if it fixes it =p
[13:32] <vila> hmmm, how much memory does your VM server has ?
[13:32] <vila> mgz: before your patch, can you remember me how memory errors were reported from a smart server ?
[13:34] <vila> xarinatan: hmmm, how much memory does your VM server has ?
[13:35] <vila> bleh, 'how much memory on the VM server' is probably better english :-/
[13:35] <Peng> I'd go with "how much memory does it have".
[13:36] <vila> rats, thanks Peng ;)
[13:36] <fullermd> "does it have the geebees?"
[13:37] <dOxxx> hmmm just thinking about it now... the rules on when to use 'has' vs 'have' are not clear
[13:38] <dOxxx> I have. You have. They have. It has. vila has. the server has. how much does it have?
[13:38] <dOxxx> really not predictable
[13:38] <fullermd> 'has' is third person...
[13:38] <vila> fullermd: geebees like the shaddoks friends ?
[13:38] <fullermd> I have.  You have.  He/she/it has.
[13:38] <dOxxx> so why then is "how much does it have?" correct?
[13:39] <vila> fullermd: http://en.wikipedia.org/wiki/Les_Shadoks says it's spelled Gibis (even in english) so probably not ;)
[13:39] <dOxxx> I guess there are exceptions.
[13:40] <fullermd> Ugh, I've forgotten too much linguistics to explain it.  It's not a subject verb there...
[13:40] <dOxxx> oh hmm I see
[13:40] <dOxxx> the ver is 'does' in the sentence
[13:40] <dOxxx> verb*
[13:40] <vila> and when should it be "does it had" vs "does it have" ?
[13:40] <dOxxx> never
[13:40] <fullermd> It's not a participle, it's something related.
[13:40] <dOxxx> it would "did it have" for past tense
[13:41] <dOxxx> be^
[13:41] <fullermd> I'll go with "languages are all stupid" for $300, Alex.
[13:42] <xarinatan> Sorry, back, upgraded BZR on the server in question
[13:42] <xarinatan> And the VM has 1GB RAM and 1GB Swap, previously had 256MB RAM but that was obviously not enough when i committed large files :P
[13:42] <fullermd> Also related: http://www.qwantz.com/index.php?comic=1915   :p
[13:44] <jam> anyone in the US or AU that can run a script for me? I'm trying to see how long interactions take with Launchpad from various locations
[13:44] <xarinatan> Also, isn't it "How much does your server have?"? I'm dutch, i don't remember exactly how the rules were taught back in highschool, but surely it had some correlation to what form was used
[13:45] <beuno> jam, Argentina any good?
[13:45] <jam> http://paste.ubuntu.com/584285/
[13:45] <jam> beuno: would be good for me
[13:46] <jam> beuno: can you run the above paste ?
[13:46] <dOxxx> xarinatan: yes 'have' would be correct, we were just trying to figure out why :)
[13:46] <beuno> jam, running
[13:46] <jam> beuno: I'm seeing 300+ms from Netherlands, which seems pretty crazy long.
[13:47] <vila> 10 loops, best of 3: 330 msec per loop from here
[13:47] <fullermd> Maybe it is a [present] participle...
[13:47] <vila> fullermd: hehe nice comic ;)
[13:47] <fullermd> 10 loops, best of 3: 897 msec per loop
[13:47] <beuno> jam, 10 loops, best of 3: 1.87 sec per loop
[13:48] <jam> beuno, fullermd, vila: that is the time to resolve "lp:bzr" into a bzr+ssh url
[13:48] <xarinatan> dOxxx: your ____ have, it's a property of someone else. . oh well, i'm not linguist :P I'll leave that upto people who actually study the language
[13:48] <vila> jam: I'm sure you've know found a great way to stress test the forking server ;-D
[13:48] <vila> s/know/now/ :-(
[13:48] <jam> vila: no, that is the XMLRPC server
[13:48] <jam> vila: https://code.launchpad.net/~jameinel/bzr/2.3-avoid-xmlrpc-ssh-397739/+merge/54523
[13:48] <jam> if you want that time to go away
[13:49] <vila> jam: nm, the joke was lost
[13:49] <dOxxx> xarinatan: yeah something like that. possessive.
[13:49] <jam> vila: it would have been better if we actually logged in
[13:49] <beuno> jam, that's pretty crazy
[13:49] <fullermd> (LP being ~125ms from here)
[13:49] <fullermd> So a mere 7 round trips...
[13:50] <xarinatan> vila: I'm currently doing a commit with the upgraded version on my server, see if it makes a difference
[13:50] <xarinatan> vila: It looks like it's working this time, with about 12,000 files
[13:50] <fullermd> vila: Everybody loves Dinosaur Comics, don't they?   :p
[13:51] <jelmer> hmm, something is eating PQM emails again for me :(
[13:52] <xarinatan> jam: Are you from holland btw? Since you mentioned the netherlands
[13:53] <jam> xarinatan: I'm actually from the US, but I'm living in Netherlands for a couple years.
[13:53] <jelmer> jam: I thought launchpad supported short names for http as well these days. Certainly bzr log http://code.launchpad.net/bzr works for me.
[13:53] <jam> my wife got a promotion and temporary training here
[13:53] <jam> jelmer: it works for Loggerhead, but not for 'bzr branch'
[13:53] <fullermd> I had to kick jam out of my $TZ; he was making me look bad with all that "getting up at a reasonable hour" stuff   :p
[13:53] <xarinatan> jam: How's the language for you? :P I heard some people who tried to move over to here complain about it a lot
[13:54] <jam> xarinatan: I know almost no dutch. It happens that we live in Eindhoven, where 90% of the people work for Philips, who mandates English on campus
[13:54] <jam> I'm exaggerating slightly, but I haven't had a problem getting people to talk to me in English
[13:54] <jam> except for the ones that stop asking for directions while I'm walking down the street.
[13:54] <jam> why are they picking me? :)
[13:54] <xarinatan> jam: Aha, well that's nice too, though most of the 'dutchies' speak english anyway ^^;
[13:55] <vila> jam: cos' you're walking and not using a car ? :-D
[13:55] <jam> vila: so are they
[13:55] <jelmer> jam: Hah, so I guyess you already make the impression you look like you belong ? :-P
[13:55] <jam> but I'm also walking with my son
[13:55] <jam> so maybe I'm safe
[13:55] <xarinatan> jam: You must be secretly dutch! :P
[13:55] <jam> jelmer: It happened to happen 2 times over the weekend
[13:55] <jam> xarinatan: german descent...
[13:56] <jelmer> jam: it works for bzr branch for me too ("bzr branch http://code.launchpad.net/bzr ~/tmp/bzr")
[13:56] <xarinatan> jam: Same difference, except everything sounds like a curse there, i love german xD
[13:56] <vila> jam: yes, that's why they can stop you ;-D
[13:57] <vila> jam: but, jokes aside, the kid part is probably the trigger
[13:57] <jam> vila: yeah, that was my guess
[13:57] <jam> you don't look much like a tourist when you have a kid with you
[13:57] <jam> though if you hear him chattering away, they would know better
[13:58] <vila> hehe
[13:58] <dOxxx> jelmer: I may have missed your reply but should I be using bzr-svn trunk tip for bzr.2.4b1?
[13:58] <jelmer> dOxxx: ah
[13:58] <jelmer> dOxxx: yes
[13:58] <dOxxx> ok
[13:58] <jelmer> two more bugs to fix before 1.1.0
[14:02] <jam> jelmer: speaking of which, new development in the dutch saga. We just found out that Customs won't actually let our goods through until April 1st. And our lease for short-term apartment ends on the 31st. Just silly given that they arrived before we did a month ago.
[14:02] <vila> jam: regarding https://code.launchpad.net/~jameinel/bzr/2.3-avoid-xmlrpc-ssh-397739/+merge/54523
[14:02] <vila> jam: nice one :) But one question:
[14:03] <vila> what are the risks that we diverge from lp ? (0 ? We were already making assumptions about the lp implementation ?)
[14:03] <jelmer> jam: wtf? This is the Dutch customs?
[14:04] <jam> jelmer: yep.
[14:04] <jam> I guess part of the issue is they can't start the paperwork until we get here and get BSN numbers, etc
[14:04] <jam> which takes a wek
[14:04] <jam> week
[14:04] <fullermd> I told you trying to smuggle in those kidneys would be trouble...
[14:04] <vila> jam: how tasty for an April 1st hoax...
[14:04] <jam> vila: you can follow the bug
[14:04] <jam> but LP explicitly implemented "+branch/foo" so that we could use it
[14:04] <jelmer> jam: And I thought moving to the US was hard (a friend of mine is moving from Eindhoven to CA)
[14:05] <jam> very low chance we'll diverge
[14:05] <jam> especially since it will start breaking for people once we stop using xmlrpc :)
[14:05] <jam> jelmer: well, there are quite a few things that could have made it smoother. Having my bank in the US allow scheduling international wires without being physically present.
[14:06] <jam> What's funny is that most of the Expat stuff from Eindhoven was very fast
[14:06] <jam> and they have a huge Expat center in the middle of town
[14:06] <jam> so its something they supposedly care a lot about
[14:06] <jelmer> jam: Ah :-/ How's that going, is the bank still holding up your cheques?
[14:06] <jam> (30% tax free income for my wife, etc)
[14:06] <jam> jelmer: yep
[14:06] <jam> we have confirmation that it made it to Amsterdam, a *week* after we gave it to the local bank
[14:07] <jam> apparently they operate by carrier pidgeon
[14:07] <jelmer> heh
[14:07] <jelmer> a courier walked to Amsterdam perhaps?
[14:08] <fullermd> It went by boat.  For security reasons, y'know.
[14:08] <briandealwis> Hi everybody.  I have a private branch that I want to amend a couple of commit messages before pushing to a public branch.  I should know this, but is there a plugin for rewriting a commit message — knowing that it'll destroy history?  Or is there an alternative beyond merging each commit one at a time?
[14:09] <jelmer> briandealwis: you should be able to fastexport the commits, edit the stream and reimport
[14:09] <maxb> jelmer: "I'm able to branch from https://code.launchpad.net/bzr-svn ." ..... really!?!? Does not work for me and I cannot see how it would.
[14:09] <jelmer> maxb:
[14:09] <jelmer> charis:~/src/hydrazine/trunk% BZR_PDB=1 bzr branch --no-plugins https://code.launchpad.net/bzr-svn ~/tmp/bsa
[14:09] <briandealwis> jelmer: hmm, there's 16000-odd commits...
[14:09] <jelmer> Branched 3647 revision(s).
[14:09] <dOxxx> briandealwis: you can also, with some effort, combine uncommit and shelve to reverse your commits and recommit them with updated messages.
[14:10] <briandealwis> dOxxx: that's a good idea.  thx
[14:10] <jam> maxb: code.launchpad.net/bz-svn has a 'BranchReference' pointer at
[14:10] <jam> ttps://code.launchpad.net/bzr-svn/.bzr/branch/location
[14:10] <jam> https://code.launchpad.net/bzr-svn/.bzr/branch/location
[14:10] <maxb> ahh! (And it is probably being broken by one of the foreign bzr plugins, then)
[14:10] <jam> maxb, jelmer: that was how we implemented lp:foo before the XMLRPC was added
[14:10] <jelmer> maxb: Yeah, bzr-hg breaks it
[14:11] <jam> jelmer: because it inserts itself earlier in the stack?
[14:11] <jelmer> jam: ah, I wasn't aware of that
[14:11] <jelmer> jam: yep
[14:11] <maxb> Is there a reason why we don't always probe for bzr-native formats first?
[14:11] <jelmer> jam: is there any reason to prefer XMLRPC over the branch references? It seems in case of the branch references it's possible to keep the same HTTP connection
[14:11] <jam> jelmer: I mentioned on the bug, it also involves an SSL request in what would otherwise be pure-HTTP
[14:11] <jam> jelmer: not possible
[14:11] <jam> different top-level domain, and HTTPS vs HTTP
[14:12] <jelmer> maxb: the bzr smart server does a POST request and that blows up on several foreign servers (e.g. google code errors with a 401)
[14:12] <jam> so you can't re-use the connection
[14:12] <jelmer> jam: ah, argh :-(
[14:12] <vila> jam: just re-read the bug (bunch of pages ;) and it mentions the http urls too, may be you should clarify the situation in a bug comment before closing the bug
[14:12] <maxb> It seems like it would be nice to allow foreign plugins to attach fallback probing after such a failure
[14:13] <jelmer> maxb: that's been discussed a couple of times on the list
[14:13] <jelmer> maxb: and there's a bug about it
[14:14] <jam> jelmer: yeah, I think the issue is that there are *valid* cases where a server would issue 401 (that is Auth required, right?) in response to POST
[14:14] <vila> jam: or may be just file a new bug so your proposal is not blocked on the http discussion
[14:14] <jelmer> jam: right
[14:15] <jam> jelmer: seems like it would be nicest to have a whitelist/blacklist of known sites that use X format.
[14:16] <jam> or just remember the last one to succeed and use it first next time
[14:16] <jelmer> jam: I think we should try to avoid the POST unless we know there is bzr at that site
[14:17] <jelmer> jam: e.g. check for .bzr/branch-format, then try the POST and if that fails fall back to use with the format directly
[14:17] <jam> jelmer: but how do we *find out* (and arguably, it adds a round-trip overhead for what we want to be the fast case)
[14:17] <maxb> Encourage people to use bzr+http, hg+http etc?
[14:17] <jam> maxb: we had svn+ and I guess people really didn't like it
[14:18] <jelmer> maxb: I think a single very small HTTP request is worthwhile overhead to not have to type foo+
[14:18] <vila> jam: the issue that was discussed made it clear that POSt was also forcing an additional round-trip (and led to failures)
[14:18] <jelmer> it is still always possible for people to use bzr+http://.... if they care about that roundtrip
[14:19] <vila> jam: the situation today is that people that install foreign plugins *do* an additional round-trip *before* trying the POST
[14:19] <jelmer> right now we do one extra roundtrip per foreign VCS plugin that's loaded before we probe for bzr formats
[14:19] <vila> yeah, per plugin even ;)
[14:20] <maxb> I think we should do the POST .bzr/smart, and if it fails, give plugins a chance to try things, and if none succeed, continue raising the original error
[14:20] <jelmer> maxb: that doesn't work, as the POST can trigger a username/password prompt
[14:20] <maxb> gah
[14:21] <vila> and that's without mentioning walking up the url to find the format ?
[14:21] <vila> or is it only after we successfully found the branch format ?
[14:21] <jelmer> vila: yes, though generally people don't specify inside-branch paths for remote URLs
[14:23] <jelmer> vila: that's something we could make better though - there's no need to walk down for SVN branches for example
[14:24]  * vila nods
[14:24] <dOxxx> looks like bzr 2.4b1 is happy with trunk versions of svn and pipeline
[14:25] <dOxxx> or at least they pass the `bzr plugins` smoketest
[14:27] <dOxxx> uploading...
[14:27] <vila> dOxxx: \o/
[14:27] <jelmer> jam,vila: Actually, if a user specifies a URL that doesn't contain a .bzr dir it's quicker to check for .bzr/format first because then we can skip the dumb format check before descending one level
[14:27] <jelmer> though I'm not sure how much we care about that use case
[14:29] <dOxxx> it's murdering my remote desktop connection to work though XD
[14:32] <jam> jelmer: there is no .bzr/format, there is .bzr/branch/format and .bzr/branch-format
[14:32] <xarinatan> Just submitted the bug report regarding the large amount of file issue from 2.3.1 clients to 2.2.1 servers https://bugs.launchpad.net/bzr/+bug/741015
[14:32] <jelmer> jam: Sorry, I mean .bzr/branch-format
[14:33] <jelmer> I still think that's an odd name for something that actually describes the control dir format, but I guess that's for historical reasons?
[14:33] <jam> jelmer: ideally we would have a proper probe to .bzr/smart to get the full branch + repository at any given level. It is certainly one of my pet-peeves that we have about 10 round trips just to say "yes you have a Branch"
[14:33] <jam> jelmer: yeah, we had it before we did the split out
[14:33] <jam> and by keeping the name, old clients can say "I don't know what branch format this is" rather than saying "I don't see a branch"
[14:34] <jam> of course, it has been 4 years since we had clients that didn't know about MetaDir :)
[14:34] <jam> but also no push to actually change it
[14:34] <jam> vila: is there any way to instrument the XMLRPC stuff? It looks like the current lp: resolving code is going to an https server
[14:34] <jam> which is where all the overhead is
[14:35] <jam>            1            0      1.1641      1.1641   <built-in method do_handshake>
[14:35] <jam> which is part of the ssl module
[14:35] <jam> the stack goes through our _urllib2_wrappers
[14:35] <dOxxx> I must revisit my qbzr branch for the mergetool stuff so that it can be bundled into bzr 2.4
[14:36] <vila> jam: -Dhttp from command-line, for more stuff see DEBUG in _u2_wrappers 1 for basic stuff 9 for all
[14:36] <jelmer> jam: It would be nice if we could do that without a POST request..
[14:37] <jam> jelmer: "do that without" ?
[14:37] <jam> probe for whether there is a smart server?
[14:37] <jelmer> jam: Probing to .bzr/smart
[14:37] <vila> jam: but I don't think you'll get timings from that
[14:37] <jam> vila: I have -Dhttp set, and it doesn't seem to see the XMLRPC stuff
[14:38] <jam> vila: I'm wrong, it is in the log
[14:38] <jam> just hard to find
[14:38] <vila> may be because it use a cutom Request ?
[14:39] <jam> it looks like we explicitly only make the request to xmlrpc.launchpad.net:443
[14:41] <jam> vila:         LAUNCHPAD_INSTANCE[instance] = 'https://xmlrpc.%s/bazaar/' % domain
[14:42] <jam> it looks like at some point we recently updated the launchpad lp_registration plugin to make its requests via SSL
[14:42] <jam> which adds a rather significant amount of overhead
[14:42] <jam> in my lsprof timing, it is 1.2s
[14:42] <jam> which is far worse than the 300ms or so if you do it in a loop
[14:42] <jam> vila: do you automatically get connection sharing via our urllib2  enhancements?
[14:43] <jam> or do you have to save some object to get that?
[14:43] <vila> from what layer ?
[14:46] <dOxxx> vila: osx installer uploaded and changes on trunk committed. I haven't branched for 2.4 yet.
[14:46] <vila> dOxxx: ok, I was wondering about that, do you plan to create 2.4 branch or should we wait for the 2.4.0 release instead ?
[14:47] <dOxxx> I think I'll wait
[14:54] <vila> ok
[14:56] <jam> vila: I was just wondering if my looping xmlrpc stuff was connection sharing
[14:56] <jam> which would explain why it looks like 1.2s real world time, but the loop shows it as 300ms
[14:58] <vila> haaa, well, I looked briefly at the lp_directory stuf but I'm not even sure it uses _u2_wrappers there...
[14:59] <vila> and you need to poke hard at urllib2 to use persistent connections (unless things have changed in recent python versions but I really doubt it)
[15:01] <vila> jam: you can copy httplib.py and patch it (that's what I did pas then), there should be a debug or DEBUG variable or attribute somewhere
[15:01] <vila> s/pas/past/
[15:02] <jam> vila: then it most likely isn't a persistent connection thing
[15:02] <jam> we create a new LaunchpadRequest object, etc. each time
[15:03] <jam> there isn't any cache state in LaunchpadDirectory
[15:03] <jam> and I'm not trying to make it faster, I'm trying to skip the ssl handshake entirely :)
[15:05] <vila> use http :)
[15:16] <jam> jelmer: your first report about bzr-git not allowing --excludes :)
[15:16] <jam> lucky you (bug 403811) why is it showing up as NEW for me
[15:17] <jam> ah, it is just connecting it to the debian bug
[15:26] <jelmer> yep
[15:30] <jelmer> hmm, I wonder if the cleanup.OperationWithCleanup could be useful as a decorator
[15:35] <jelmer> vila: I'm getting test failures during 2.4b1
[15:35] <jelmer> 3 instances of IllegalUseOfScopeReplacer and a remote upgrade command that takes fewer requests than expected
[15:37] <vila> O_o context ?
[15:38] <jelmer> vila: I'm trying to build the 2.4b1 packages, currently trying to figure out what we're doing differently in the packaging to trigger those errors
[15:39] <vila> ha, at least you don't get the failures locally ?
[15:41] <jelmer> well, I get them locally but only when run in my debian sid chroot using the packaging arguments (disabling the launchpad plugin, for example)
[15:41] <vila> with --no-plugins ?
[15:41]  * vila running B_P_P=-site to see
[15:46] <vila> jelmer: right, can't reproduce here :-/ Any more hints ?
[15:51] <briandealwis> jelmer: I'm doing a dpush to push up 4 small revisions with bzr-svn to a server (first time ever dpushing here).  There's a message: "Storing Bazaar metadata in file properties. Use `bzr dpush` for lossfull push without file properties.Upgrade the server to Subversion 1.5 or later to use (less visible) revision properties.", and it seems to be transferring the world: almost 300MB so far.
[15:51] <briandealwis> jelmer: is this expected?  It's a big deep tree (16k revisions).
[15:52] <briandealwis> jelmer:  and I don't know what version it's running remotely, and can't see how to find out
[15:56] <vila> jelmer: got the one failure in bb bzr info you fixed lately with --no-plugins
[15:57] <vila> jelmer: are you trying to run with --parallel ? (just checking, I did my run with --parallel=fork anyway)
[15:59] <jelmer> vila: yes, this is with --parallel
[15:59] <jelmer> I haven't reproduced it outside of the package scripts yet
[16:00] <vila> jelmer: any idea of the number of processes involved ?
[16:00] <jelmer> vila: it'd be 4 processes. The env variables we set include: BZR_HOME=debian/bzrhome \
[16:00] <jelmer> 	BZR_PLUGIN_PATH=-site:-user \
[16:00] <jelmer> 	BZR_DISABLE_PLUGINS=launchpad \
[16:00] <jelmer> briandealwis: what version of bzr-svn?
[16:01] <briandealwis> jelmer: 1.0.4
[16:01] <vila> jelmer: I always run with 8, but there was failures loooong ago when using different numbers (because it slices tests in different ways, this may trigger different isolation test bugs)
[16:01] <briandealwis> It sounds very much like the problem described here: http://web.archiveorange.com/archive/v/mvjb49H5gqOiXreQjtmn
[16:02] <vila> jelmer: -user is useless here ;) Why do you disable launchpad /
[16:02] <vila> ?
[16:03] <jelmer> vila: the launchpad plugin tests connect with launchpad
[16:03] <vila> grrr, sorry, forgot it again :-/
[16:04] <briandealwis> jelmer: I interrupted it after 500mb; it pushed 3 revisions up.  Pushing the final revision was very quick.  Very bizarre.
[16:05] <jelmer> briandealwis: there's a bug about that, fixed in trunk
[16:05] <briandealwis> jelmer: ah great!
[16:06] <jelmer> vila: http://pastebin.ubuntu.com/584355/
[16:09] <vila> jelmer: right, so 'ui' is involved in all cases so probably the same root cause
[16:09] <jelmer> vila: ui? I thought it was branch
[16:10] <vila> well, not in the pastebin you just paste AFAICS
[16:10] <vila> errr, except for the first failure >-/
[16:10] <vila> s/failure/error/
[16:10] <jelmer> and the last
[16:11] <jelmer> I hate how we catch all exceptions during upgrade :-/
[16:12] <jelmer> I'm not entirely sure how to deal with these scope exceptions though - these imports seems perfectly reasonable to me
[16:12] <vila> old == _mod_branch.BzrBranchFormat5 ... I'm not sure you're allowed to do that with lazy objects (jam ?)
[16:12] <jelmer> it's been like that forever though, we haven't touched it in the last few cycles
[16:13] <vila> jelmer: unfortunately, that's irrelevant :-/ There could be side-effects with lazy loading
[16:17] <jelmer> ah, I see
[16:23] <vila> jelmer: the bright side is that you're exposing genuine bugs in our imports here :-/
[16:24] <vila> jelmer: as generally fixing these bugs is adding the right import in the right place.... :-}
[16:25] <jelmer> vila: what worries me is that these are hard to reproduce :-/
[16:26] <vila> jelmer: I know :-( Not using --parallel may work around the issue in the mean time
[16:54] <sidnei_> uhm, is there any change with plugins in bzr trunk? i installed the daily build and now my custom plugins don't seem to be registered anymore
[16:55] <sidnei_> oh, maybe they are not compatible with the api version and didn't get loaded or something
[16:56] <vila> sidnei_: probably, but this didn't happen yesterday, more like several weeks ago (unless the daily build has been failing for some time ?)
[16:56] <sidnei_> vila, i installed the daily build today to check out jam's fixes
[16:56] <vila> sidnei_: right, but when was your previous install ?
[16:57] <sidnei_> vila, i haven't used daily builds, not since i reinstalled from scratch several weeks ago. i was running 2.3.0 before.
[16:57] <vila> ha ok, then yes, the API have changed
[16:58] <vila> well, if your plugins *test* the compatible API that is
[17:10] <briandealwis> I'm in a situation where I have a codebase where I need to make some patches for the code to work locally within my IDE.  These patches shouldn't be committed.  But shelving and unshelving them before a commit is a bit painful.  Pipeline/loom doesn't seem the right fit…  Any suggestions?
[17:14] <briandealwis> mm, I guess I want something like Darcs' ability to reorder patches
[19:22] <ryan_scott> I have to use a different VCS for work reasons, but am really missing the bzr visual diff tool.
[19:22] <ryan_scott> Does anyone know if it can be called by itself?
[19:23] <beuno> ryan_scott, which one is that?
[19:23] <beuno> meld?
[19:24] <ryan_scott> Whatever is the default for bzr on the windows client.
[19:24]  * beuno doesn't do windows
[19:27]  * ryan_scott used to not do windows and was happier about it.
[19:28] <ryan_scott> Specifically I miss doing development on Linux
[19:49] <jam> lifeless: sometime I'd like you to take a look at a possible race issue for concurrent fetching into a pack repository.
[19:50] <jam> My bug comment is here: https://bugs.launchpad.net/bzr/+bug/709349/comments/13
[19:50] <jam> but the basic summary
[19:50] <jam> 2 bzr processes are run concurrenty to fetch from the same branch into the same repository.
[19:50] <jam> Both of them are thus fetching exactly the same content, but since they start concurrently, neither one sees that the other is doing the work
[19:50] <jam> when one finishes, it adds the pack to the repo
[19:50] <jam> (renames it into packs, updates pack-names)
[19:51] <jam> it then goes to autopack, and sees that this new pack needs to be moved to obsolete packs
[19:51] <jam> so it removes it from pack-namse, but has not renamed it to obsolete yet
[19:51] <jam> the second process then sees "ok, I'm done fetching, let me put this new content into the repo"
[19:51] <jam> "oh look, it isn't already presenT"
[19:51] <jam> renames it *over top* of the existing pack file
[19:52] <jam> updates pack-names to add the new file
[19:52] <jam> process 1 finishes and renames the newly re-added file to obsolete_packs
[19:52] <lifeless> jam: kk; I just got off a call; I'll look right after breakfast
[19:53] <jam> lifeless: no problem. I'm heading out.
[19:53] <jam> I just wanted a second opinion since you did a lot of the pack danec
[19:53] <jam> dance
[19:53] <jam> lifeless: the key is 2 fetches doing identical content concurrently, I think
[19:53] <lifeless> nice
[19:53] <lifeless> sounds plausible
[19:53] <lifeless> damn concurrency is hard
[23:55] <LeoNerd> Someone remind me... having accidentally killed a branch by overwriting a pull... how do I get it back? I can see it in  bzr heads --dead
[23:58] <soren> LeoNerd: bzr pull . -r revid:your_rev_id
[23:59] <LeoNerd> Hrmmmm.. it claims it's diverged...