[07:25] <stewart> hi all!
[07:25] <stewart> is there a magic "upgrade all launchpad bzr trees for project X to new repo format" button hiding somewhere?
[07:25] <stewart> or does the magic sftp "bzr upgrade" work for all that...
[07:27] <stewart> and also, any idea what "Standalone tree (format: unnamed)" could possibly mean ?
[07:39] <lifeless> it info -v
[07:39] <lifeless> bah
[07:39] <lifeless> info -v will help you see what it means
[07:41] <stewart> ahh.. packs with knits without subtree
[07:41] <lifeless> probably an unusual combination of tree/branch/repo
[08:10] <Jordan_U> I'm working with the branch http://bzr.savannah.gnu.org/r/grub/trunk/grub/. "bzr log | grep tags:" prints "tags: 1.99" yet "bzr checkout -r tag:1.99 /tmp/grub" fails with "bzr: ERROR: No such tag: 1.99". What am I doing wrong?
[08:11] <Jordan_U> Ahh, I see what I did wrong now.
[08:16] <Jordan_U> I thought that if ommitted branch location would be the branch corrosponding to the current directory. I guess it's not.
[08:32] <LarstiQ> Jordan_U: it will try to check out /tmp/grub in the current location
[08:32] <Jordan_U> LarstiQ: Thanks.
[08:35] <LarstiQ> Jordan_U: I suspect you might be used to git checkout?
[08:36] <Jordan_U> LarstiQ: Yes :)
[08:36] <LarstiQ> Jordan_U: yeah, same names unfortunately don't always imply same operation :)
[08:37] <Jordan_U> LarstiQ: I actually did read "bzr help checkout" before using it.
[08:37]  * LarstiQ shakes a fist at Estonian/Finnish false friends while at it
[08:38] <LarstiQ> Jordan_U: maybe it should be more explicit that one can't supply TO_LOCATION without supplying BRANCH_LOCATION?
[08:38] <Jordan_U> LarstiQ: I'd say so.
[08:39] <LarstiQ> hmm, not sure how to get the option parser to spit that out
[08:43]  * LarstiQ will file a bug and let other people sort it out
[08:44] <dandaman> is there anything for bzr in ubuntu 10.10 like there is for tortoise svn on windows where the UI is your file explorer?
[08:44] <Jordan_U> LarstiQ: Thanks.
[08:44] <LarstiQ> dandaman: nautilus-bzr exists, don't know if it is on the same level
[08:45] <LarstiQ> dandaman: might be packaged in bzr-gtk
[08:45] <dandaman> i shall investigate
[08:46] <dandaman> i'm not well acquainted with the command line yet(which i'd really like to, but no time) and the explorer ui is garbage
[08:46]  * dandaman apologizes if anyone who worked on that is in the channel, just my opinion
[08:46] <dandaman> his*
[08:47] <LarstiQ> dandaman: the apology would carry more weight if you gave feedback on why you think that ;P
[08:48] <LarstiQ> not that I'm involved
[08:49] <dandaman> its just a lot less inferior to a folder explorer UI, less intuitive
[08:55] <LarstiQ> dandaman: mkay, that might be taste I suppose
[08:55] <LarstiQ> dandaman: found nautilus-bzr yet?
[08:55] <dandaman> yeah i installed it
[08:55] <dandaman> I'll get it set up when i'm not stoned, and thus be able to read instructions
[08:55]  * LarstiQ personally abhors the explorer/nautilus view
[08:56] <LarstiQ> dandaman: hah, ok :)
[08:56] <dandaman> really?
[08:56] <LarstiQ> yeah
[08:56] <dandaman> its so easy to us
[08:56] <dandaman> use*
[08:56] <LarstiQ> dandaman: how do you quantify easy? :)
[08:56] <dandaman> just right click on the file you worked on a second ago and its committed
[08:56] <LarstiQ> dandaman: except I don't use a filemanager in my daily workflow to begin with
[08:56] <dandaman> barely worry about conflicts because you commit one file at a time
[08:56] <dandaman> do you use the command line?
[08:56] <LarstiQ> yeah
[08:57] <dandaman> well see
[08:57] <LarstiQ> and emacs/vi integration
[08:57] <dandaman> command line is probably the most efficient
[08:57] <LarstiQ> and qbzr
[08:57] <dandaman> i just don't exactly have the time to learn how to use it to the point where i'd feel comfortable with it
[08:57]  * LarstiQ nods
[08:57] <LarstiQ> that's fair
[08:57] <dandaman> after graduation i'll have some time
[08:57] <dandaman> and i'm going to learn a whole bunch of stuff i meant to learn on the side
[08:58] <dandaman> also, i need to find a place that wants to hire api programmers
[08:58] <dandaman> don't know why, but i decided that's what I want to do
[09:06] <LarstiQ> Jordan_U: took a while, but: https://bugs.launchpad.net/bzr/+bug/784459
[09:23] <mgz> morning all!
[09:24] <LarstiQ> morning mgz :)
[09:26] <mgz> LarstiQ: if you're still interested in the file handles issue for pypy, I have a couple of tools that may help
[09:27] <mgz> also, vila and I are going to investigate later today to see if the babune osx and windows issues are also file handle exhaustion related
[09:30] <LarstiQ> mgz: yeah
[09:30] <LarstiQ> mgz: I have made some notes
[09:30] <LarstiQ> and some lacking commits
[09:30] <LarstiQ> I'll push the latter
[09:32] <LarstiQ> mgz: http://richtlijn.be/~larstiq/DEBUG_NOTES
[09:33] <LarstiQ> mgz: and maybe it is useful to put a small test script to demonstrate the generator-with-resources problem
[09:36] <LarstiQ> mgz: http://richtlijn.be/~larstiq/halfcon.py
[09:37] <LarstiQ> mgz: most fun: enable the pdb line, run the script (cpython or pypy, doesn't matter in this case), note the pid it prints out, run "watch -n 1 'ls -lU /proc/<pid>/fd"; and step through the code
[09:37] <LarstiQ> mgz: (not too fast, watch only updates once a second)
[09:38]  * jelmer waves
[09:38] <LarstiQ> jelmer: hei jelmer :)
[09:39] <jelmer> LarstiQ, dude!
[09:40] <LarstiQ> mgz: even with those attempts at cleaning up resources, running `pypy ./bzr selftest -s bt.blackbox` the amount of open files fluctuates. Usually between 700 and 1023 (where we get too many open files)
[09:40] <LarstiQ> jelmer: still alive ;)
[09:41] <LarstiQ> mgz: I hope the DEBUG_NOTES file is clear?
[09:42] <mgz> okay, back from swapping
[09:42]  * mgz reads notes
[09:45] <mgz> LarstiQ, so, jam recently added a cleanup in Transport._seek_and_read which is what Transport._readv (always?) calls
[09:46] <mgz> are there cases where that codepath with the close isn't being hit?
[09:46]  * LarstiQ looks at the code
[09:46] <jam> mgz: LocalTransport should always call _seek_and_read, HTTP and others don't
[09:46] <LarstiQ> mgz: where is this cleanup?
[09:47] <jam> LarstiQ: try/except/fp.close raise else: fp.close
[09:47] <jam> line 718 in bzrlib/transport/__init__.py
[09:47] <LarstiQ> jam: that is no good if the generator is not fully consumed
[09:47] <jam> mgz: and we can change that back to try/finally now \o/
[09:47] <jam> LarstiQ: generators raise GeneratorExit if they aren't consumed
[09:47] <jam> at least in python 2.5+
[09:48] <jam> pypy *should* be doing the same
[09:48] <LarstiQ> jam: in what case?
[09:48] <LarstiQ> when they're garbage collected?
[09:48] <LarstiQ> That may take a while
[09:48] <jam> LarstiQ: yes
[09:48] <LarstiQ> jam: it _does_ clean them up from time to time, dropping from say 800 to 300 open files
[09:48] <LarstiQ> but not fast enough
[09:49] <mgz> okay, that sounds fun.
[09:49] <jam> LarstiQ: so 1) we can change it to try/finally so it is at least clearer. 2) We can look at changing the StopIteration code black to close them again
[09:49] <LarstiQ> jam: the reason I think it is due to not being consumed is that I added debug prints/sys.counter checking, and we were not hitting the final fp.close
[09:50] <jam> LarstiQ: http://paste.ubuntu.com/609397/
[09:50] <jam> try that
[09:50] <jam> it should allow the file to get closed when its associated iterator is consumed
[09:50] <jam> before we yield
[09:50] <jam> and it should be pretty rare that we don't access all the readv data
[09:50] <mgz> LarstiQ: I also have a record of which testcases in the suite use files and rely on refcount semantics to clean them up, this can also add to your 800 files open scenario
[09:50] <mgz> lots of the problems are shallow issues with particular tests
[09:50] <jam> it will occasionally happen that we do "zip(X, readv)" and the X stops, so it doesn't even check if the readv is stopped
[09:50] <jam> I have another idea, too
[09:51] <LarstiQ> jam: that is almost what my code looks like, but I'll try that (the raise might be different)
[09:51] <jam> LarstiQ: we don't want the raise there
[09:51] <jam> that was a bug in my diff
[09:51] <jam> ah, my diff removed it
[09:51] <jam> I just read it wrong
[09:51] <LarstiQ> mgz: hmm, maybe. But I don't think so
[09:51] <mgz> see (warning, big page) http://float.endofinternet.org/xmlbin/newtestresult and click any of the little yellow boxes
[09:51] <jam> anyway, you don't have to do that part, but you can
[09:52] <jam> except... that's buggy to
[09:52] <jam> too
[09:52] <jam> it looks like we still iterate c_offset
[09:52] <mgz> it's possible pypy can be clever about some of those formulations
[09:52] <jam> so closing the file early will bring other bugs
[09:52] <jam> let me think about it a bit
[09:52] <jam> we should only close the file once we're sure we've read everything
[09:53] <jam> ah, nm
[09:53] <jam> if offset_stack is empty
[09:53] <jam> then we know we're done
[09:53] <jam> since we have returned everything the caller asked of us
[09:55] <LarstiQ> jam: that fp.close in the StopIteration works wonder
[09:55]  * LarstiQ failed to see it the first time :/
[09:56] <jam> LarstiQ: it used to be there, but we moved it because it is cleaner to have just the try/finally (and doesn't matter much in production code)
[09:56] <mgz> that's a little suprising,
[09:56] <jam> mgz: I'm not terribly surprised. anything with a lazy garbage collector can be *really* lazy
[09:56] <jam> and we do a lot of readv
[09:56] <mgz> do lots of callers use the zip idiom and never exhaust the generator?
[09:56] <jam> mgz: I wouldn't have thought lots
[09:56] <mgz> if so, might want the close there, and try/except/close/raise
[09:57] <jam> but if BTreeGraphIndex does
[09:57] <jam> that is a pretty core
[09:57] <mgz> rather than try/finally
[09:57] <jam> mgz: you can always close twice
[09:57] <jam> at least with all the objects I tried
[09:57] <LarstiQ> but can't close lists
[09:57] <mgz> ...that's probably safe
[09:57] <jam> LarstiQ: fp should never be a list
[09:57] <jam> mgz: note that you *can't* os.close(FID) twice, but that should be safely encapsulated for us
[09:58] <LarstiQ> jam: aye, I was referring to the 'if isinstance(data_ranges, types.GeneratorType)' in https://code.launchpad.net/~larstiq/bzr/bzr-pypy/+merge/60986
[09:58] <LarstiQ> since you can explicitly close a generator
[09:59] <LarstiQ> since python 2.5 iirc
[09:59] <mgz> yup.
[10:00]  * LarstiQ is 10% into the blackbox tests and observes a maximum of 37 open files dropping down to 7 every couple of seconds
[10:08] <jam> LarstiQ: so I'd rather not change btree_index unless we have to.
[10:08] <jam> it is going to be really rare for btree_index to not get fully consumed
[10:09] <jam> I'm guessing what you are running into is actually in pack.py
[10:09] <jam> Where when reading disk content
[10:09] <LarstiQ> jam: I have no firm grasp on the matter
[10:09] <jam> we create a Readv* class
[10:09] <jam> which doesn't have StopIteration written anywhere
[10:09] <jam> so it is probably never consuming the readv object
[10:09] <LarstiQ> jam: right, I pondered a .close method on that
[10:13] <LarstiQ> jam: so, shall I uncommit the previous revision, reinstate the close on StopIteration, and push --overwrite?
[10:15] <poolie> jam, hi
[10:15] <poolie> you can dial in if you like
[10:15] <poolie> also i was wondering if it would work for you to benchmark on gcc-linaro rather than a synthetic tree
[10:15] <jam> poolie: I'm dialed in
[10:16] <jam> just on mute because they are doing construction here
[10:16] <jam> poolie: I did it on gcc-linaro
[10:19] <LarstiQ> yay, blackbox tests completed with 160 open files max
[10:19] <poolie> o/ LarstiQ
[10:19] <poolie> great
[10:20] <poolie> i wonder if we can add assertion there are no more open files from the start of a test to an end
[10:20] <poolie> well, not specifically an assertion, but eg a fixture
[10:46] <LarstiQ> mgz: I'm fixing the remaining cases of file(path, mode).write(content) in the blackbox tests
[11:05] <poolie> jam are you still there and muted?
[11:05] <poolie> i'm just putting statik's graphs onto the blogpost
[11:05] <poolie> i love how the right hand bar is basically imperceptible
[11:05] <Daviey> Hi, is there a pre branch hook?  I can't seem to find one?
[11:05] <mgz> LarstiQ: cool. do refer to that webpage I posted earlier if it helps you see which tests don't close files.
[11:06] <LarstiQ> mgz: I got the ones done that were causing failures in blackbox
[11:07] <LarstiQ> loads more of occurences that don't cause immediate failures, but won't tackle those right now
[11:07] <LarstiQ> mgz: http://float.endofinternet.org/xmlbin/newtestresult makes my browser unhappy :)
[11:09] <mgz> yes, that's the problem with the number of tests bzr has... I need to remember one of the blackbox-only runs
[11:10]  * LarstiQ is running all the tests now
[11:10]  * LarstiQ knows of 3 failures in blackbox: 1 LocaleError, and two cases where the order of files returned is different than under cpython
[11:11] <LarstiQ> we'll see if there are any outside
[11:11] <LarstiQ> in, oh, 2 hours
[11:11] <jam> mgz: is the width of an entry relevant there?
[11:11] <jam> I don't quite understand the narrow grey vs the wide green, etc.
[11:13] <mgz> the wide ones are tests
[11:13] <mgz> the narrow ones are containers, test class, module etc
[11:13] <mgz> click the narrow one to expand all the tests in that class
[12:01] <jam> mgz, LarstiQ: the fp.close() change has landed in bzr.dev 5890
[12:13] <LarstiQ> jam: cheers
[12:13] <LarstiQ> bah
[12:13] <LarstiQ> pypy oomed :/
[12:14] <jam> LarstiQ: is there a way to ask pypy to run the garbage collector more often?
[12:14] <LarstiQ> jam: --jit threshold=N maybe
[12:14]  * LarstiQ looks for more documentation
[12:15] <LarstiQ> or, now that I think of it, that probably has to do with how often code runs before it is cached
[12:16] <jam> LarstiQ: AIUI, pypy has higher memory requirements than CPython, but mostly for the code parts, not necessarily for the data parts
[12:16] <jam> though how would you OOM from code parts?
[12:17]  * LarstiQ has trouble reading the oom-killer output
[12:19] <LarstiQ> jam: http://paste.ubuntu.com/609458/ fwiw
[12:20]  * LarstiQ does have a fairly memory constrained setup, and no swap
[12:20] <jam> LarstiQ: not that I know what to do with that :)
[12:20] <LarstiQ> jam: you're good at making sense of things ;)
[12:20] <jam> offhand it looks like you were about 1.5GB which would certainly be oh-crap big
[12:21] <jam> are you in 32-bit or 64-bit?
[12:22] <LarstiQ> 32bit, and 1.5GB is the amount of physical memory I have
[12:34] <LarstiQ> jam: trying PYPY_GC_MAX=50MB now
[12:39] <jam> vila: set_last_revision_info *is* an RPC, but we always allow VFS fallbacks. so it is possible for clients to override if they get really clever, or run old versions of bzr
[12:39] <jam> so in the "I haven't tested this" I think if the server says "append_revisions_only=True" then it will be refused
[12:40] <vila> jam: yeah, I know this will take time to be truly fixed :-/
[12:40] <vila> jam: but I'm happy enough with what we already have in the mean time
[12:45] <vila> jam: also, IMHO, the "flaw" I'm referring to is that we shouldn't *blindly* allow overriding server settings
[12:46] <jam> vila: believing that a pure client will respect server settings is flawed
[12:46] <jam> someone can always hack the client to not
[12:46] <jam> making sure that it is enforced *by the server* is a much better way
[12:58] <jam> vila: and then we disable VFS
[12:59] <vila> jam: sure, we can enforce that for a smart server but we should also try to have a reasonable behavior for dumb servers
[12:59] <vila> jam: I think we're are in violent agreement here ;)
[13:00] <jam> vila: I think having someone set it in locations.conf is not much removed from someone hacking branch.py to ignore the value
[13:00] <jam> it is slightly easier, but they need to know to do it
[13:01] <vila> jam: s/removed/remote/ ?
[13:02] <poolie> jam:  what do we do with https://code.launchpad.net/~songofacandy/bzr/fix-523746-dev/+merge/20537
[13:03] <vila> right, but you mentioned consenting adults, so my point is that we should be clearer for the users about what *can* be safely overriden in locations.conf and what shouldn't
[13:04] <jam> vila: someone setting append_revisions_only = False in locations.conf could almost as easily change branch.py to ignore the setting
[13:04] <jam> so if someone is going to hack their client to get around a setting
[13:04] <jam> they're going to do it anywhay
[13:04] <vila> ...
[13:05] <jam> so lets make sure we do it correctly where it matters
[13:05] <jam> and try to be nice, but we don't have to bend over backwards
[13:05] <jam> vila: as said above, if they have direct write access they can also not hack bzr but just do
[13:05] <jam> sftp .bzr/branch/last-revision sftp://REMOTE/branch/.bzr/branch
[13:06] <jam> vila: so I file it under "I'm not worried about local settings overriding remote ones for cases where users can do the work anyway'"
[13:06] <vila> dumb servers can't enforce anything obviously
[13:06] <spiv> jam: I think perhaps vila's point is that it's surprising to users, not that users can do it anyway
[13:07] <vila> what I want is that a smart server admin can say: this is my server, you can access it only with bzr+ssh, and don't mess my append_revisions_only, ok ?
[13:07] <vila> we are not there yet
[13:07] <jam> vila: we are if we were at the point that you could disable VFS
[13:07] <jam> so lets do that instead
[13:07] <vila> no
[13:08] <vila> even with no vfs we don't forbid overriding in locations.conf
[13:08] <jam> vila: with no vfs the *server* will enforce append_revisions_only
[13:08] <vila> but yes
[13:08] <jam> set_last_revision() is already calling an RPC
[13:08] <vila> let's get rid of vfs first
[13:08] <jam> and I'm sure the server can't read my locations.conf fil/e
[13:08] <jam> file
[13:08] <spiv> vila: well, if the server is enforcing it what the client's config thinks is a bit irrelevant.
[13:11] <vila> really ? Even when we create the branch ? Where is append_revisions_only is coming from ?
[13:11] <vila> and what if I just use bzr config -d remote a_r_o=False ?
[13:12] <spiv> The server may have a plugin installed that always sets that flag when creating branches.
[13:12] <spiv> It could even have a plugin that intercepts config update RPCs.
[13:12] <vila> right, there are various ways to solve the issue, but there still is an issue ;)
[13:14] <spiv> Or perhaps the server's locations.conf globally enables append_revisions_only ;)
[13:15] <vila> spiv: indeed, but this works only for the smart server since we don't even try to read the remote locations.conf for the dumb ones
[13:15] <spiv> Of course, but we were discussing the smart server case.
[13:15] <vila> and that's the flaw I'm referring to, the actual model has some dark spots
[13:15]  * vila nods
[13:15] <spiv> There's no ambiguity about what dumb servers do :)
[13:16] <vila> I'm worried for people that don't realize that running both a smart server *and* a dumb one can have surprising effects
[13:16] <spiv> Conflicts during merge: Text conflict in doc/en/release-notes/bzr-2.4.txt
[13:16]  * spiv blinks
[13:16] <vila> and until recently even lp was running both a smart and an sftp server right ?
[13:17] <spiv> vila: still is
[13:18] <spiv> I think people aren't too surprised by "you can set a setting in multiple places, and if you do and they disagree, then you might have to think carefully/experiment to find out which value wins"
[13:19] <vila> spiv: hmm, right, so I don't want to discuss to much on that now but can we agree that there are some confusing scenarios around ?
[13:19] <vila> spiv: yup
[13:20] <spiv> In general our story for "I'm an admin of a bzr host, and I want to set policies for the branches/repos" is pretty lacking.
[14:17] <vila> spiv: yes, thanks, that's I was trying to express :)
[14:17] <vila> s//what/
[14:18] <vila> it's related to the way we [should] handle BranchConfig and RemoteBranchConfig (or even RemoteConfig)
[14:21] <santagada> http://bazaarvcs.wordpress.com/2011/05/17/faster-large-tree-handling/ this seems really interesting, is there some more benchmarks planned for when this is merged?
[14:21] <santagada> comparing to mercurial and git, etc
[14:23] <santagada> I do know that the guy that did some benchmarks for bazaar passed away but this looks like a huge speed gain for it
[14:31] <poolie> santagada: yes, we probably will
[14:31] <poolie> do comparisons
[14:31] <poolie> jam, still here? want to join us?
[14:32] <LarstiQ> hrmf
[14:33] <LarstiQ> someone with more memory will need to run the complete testsuite under pypy
[14:33] <poolie> cos it leaks?
[14:33] <santagada> LarstiQ, if you have a simple step by step I can run it here (4gb 64bit linux)
[14:34] <LarstiQ> poolie: at 1.0GB rsize my oom-killer won't let it live anymore
[14:34] <LarstiQ> santagada: just a sec
[14:36] <santagada> LarstiQ, do you want to run it on trunk or 1.5? I would recommend trunk
[14:42] <LarstiQ> santagada: I've been using a 1.5 binary, but if you can try pypy trunk that would be nice too
[14:42]  * LarstiQ has no resources to translate it himself
[14:43] <LarstiQ> santagada: once you have a copy of lp:bzr and pypy, it is just "pypy ./bzr selftest | tee selftest.log"
[14:45] <santagada> LarstiQ, will do... will take some time to download lp:bzr
[14:46] <LarstiQ> santagada: that's ok with me
[14:46] <santagada> maybe I should update bzr first (2.3.1 here)
[14:46] <LarstiQ> santagada: where is it at now?
[14:47] <santagada> I think the daily nightly has some of the patches I just pated here so it should be faster at checkout stuff
[14:48] <LarstiQ> santagada: the 2.4 fixes are about a local checkout afaik, the issue is working tree handling/building, not network transfer
[14:49] <LarstiQ> santagada: are you branch over http or bzr+ssh? (ie, is your launchpad-login set)
[14:49] <LarstiQ> santagada: do I understand correctly you already have pypy setup?
[14:54] <santagada> bzr: ERROR: No module named testtools
[14:54] <santagada> LarstiQ, bzr: ERROR: No module named testtools
[14:55] <LarstiQ> santagada: ah, right
[14:55] <santagada> LarstiQ, I use bzr+ssh, and I have pypy-1.5 and the latest nightly installed
[14:55] <LarstiQ> santagada: cool :)
[14:56]  * LarstiQ growls at browsers
[14:57] <LarstiQ> santagada: you can download testtools from pypi.python.org
[14:57] <LarstiQ> untar it, and run `pypy setup.py install`
[14:57] <santagada> LarstiQ, ok
[14:57] <LarstiQ> possibly you could get away with importing it from cpython site-packages, but this is quick enough
[14:59] <santagada> LarstiQ, installed in both pypy version... it is running 5/25157
[15:00] <LarstiQ> santagada: thanks!
[15:00] <santagada> just to be clear, tests are probably going to be slower or the same speed as cpython
[15:01] <santagada> not much the jit can do about those
[15:01] <santagada> LarstiQ, I could also run some benchmarks if they are as easy as this selftest thing
[15:02] <LarstiQ> santagada: they're quite a bit slower ime
[15:02] <LarstiQ> santagada: that would be good too, let me see if I can figure out how the benchmarking is done
[15:03] <santagada> I would guess merges are going to be faster if using this new ordering/data structure
[15:05] <LarstiQ> santagada: https://launchpad.net/bzr-usertest replaced the old selftest --benchmark apparently
[15:06] <santagada> should I stop the selftest?
[15:06] <santagada> 118/25k
[15:06] <LarstiQ> santagada: please let that run (first)
[15:07] <LarstiQ> santagada: I'm aware of a couple of failures on pypy, but I'd like the complete set run now
[15:07] <santagada> the docs on that page point to a user that doesn't exist anymore on launchpad
[15:07] <LarstiQ> it is probably similar to what Naoki reported, but want to be sure
[15:07] <LarstiQ> santagada: yeah :/
[15:08] <santagada> LarstiQ, I'm running on nightly so you don't report on issues already solved. After I can run on pypy-1.5 just for comparisons
[15:08] <LarstiQ> poolie: https://launchpad.net/bzr-usertest links to http://people.ubuntu.com/~ianc/plugins/usertest/doc/
[15:08] <LarstiQ> poolie: which no longer exists
[15:09] <LarstiQ> santagada: right, I'm reasonably confident they're bugs in bzr depending on cpythong behaviour, but extra confirmation doesn't hurt :)
[15:09] <poolie> hm
[15:10] <poolie> i wonder if i can still get it out
[15:10] <poolie> or perhaps i have a copy
[15:10] <santagada> LarstiQ, cpython
[15:10] <santagada> :D
[15:10] <LarstiQ> argh
[15:10] <LarstiQ> santagada: indeed
[15:10] <santagada> pythong would be a good 1st April joke
[15:11] <LarstiQ> I think it's been made before
[15:11] <santagada> a leaner python or something
[15:38] <santagada> LarstiQ, 701/25k I think this will take a lot of time
[15:39] <LarstiQ> santagada: hmm, I'm inclined to say that seems to go slower than it did on my netbook?
[15:40] <LarstiQ> santagada: if you don't mind running it, I can wait
[15:40] <LarstiQ> or rather, do mathematics in the mean time :)
[15:45] <Riddell> vila: http://people.canonical.com/~mwh/bzrlibapi/bzrlib.html
[15:45] <vila> Riddell: thanks ;)
[15:49] <spiv> Riddell: http://doc.bazaar.canonical.com/bzr.dev/developers/integration.html and http://doc.bazaar.canonical.com/bzr.dev/developers/overview.html were those docs I just mentioned
[15:49] <spiv> (in case you hadn't already seen them)
[16:18] <LarstiQ> santagada: hmm, we might actually have found a pypy bug
[16:18] <quiznilo> I'm trying to use bzr just to download some source code... I don't even know what that is called in bzr-lingo.  I can't find any docs basic enough to help me, is there a good starting point doc-wise?
[16:18] <santagada> LarstiQ, what?
[16:19] <santagada> quiznilo, I don't know for sure, but "bzr checkout --lightweight lp:<launchpad project>" might be exactly what you want
[16:19] <LarstiQ> santagada: you might not have seen the failure yet, but you made me ready for the posibility it might not be bzr :)
[16:20] <quiznilo> thank you sir
[16:20] <LarstiQ> santagada: locale.setlocale() raises different error classes between python and pypy it seems
[16:21] <LarstiQ> santagada, quiznilo: --lightweight isn't really designed for non-local usage, so that might be slower than just `bzr branch lp:<launchpad project>`
[16:22] <quiznilo> unable to authenticate to SSH host
[16:22] <quiznilo> I'm just downloading, I'm not uploading...
[16:22] <santagada> LarstiQ, my log for now http://nopaste.linux-dev.org/?11997
[16:23] <LarstiQ> quiznilo: if you have launchpad-login set, bzr will use ssh also for download because it can be faster that way
[16:23] <quiznilo> so unset launchpad-login?
[16:23] <santagada> quiznilo, I think launchpad should have a tarball download option you should probably fill a issue somewhere
[16:24] <LarstiQ> quiznilo: that, or login, or there is some way to turn ssh off
[16:24] <santagada> quiznilo, yep, or send your ssh-key to launchpad
[16:24]  * LarstiQ looks it up
[16:24] <quiznilo> this is windows lol
[16:24] <quiznilo> I don't have a ssh-key
[16:24] <santagada> ok then just unset it
[16:24] <santagada> if you just want to look at code
[16:24] <LarstiQ> santagada: hmm, blackbox.test_info.TestInfo.test_info_locking is new to me
[16:25] <santagada> LarstiQ, this is running with the latest pypy
[16:25] <LarstiQ> santagada: that, and mgz turned on unexpected successes counting as failures today or yesterday
[16:25] <LarstiQ> but he's not online atm
[16:26]  * LarstiQ is currently looking into that LocaleError
[16:26] <santagada> LarstiQ, I leave work in 2 hours, but I will let this running
[16:26] <LarstiQ> santagada: cheers
[16:27] <LarstiQ> the mbcs one is also new to me, but the rest I've squashed
[16:30] <quiznilo> there is no 'bzr unset' command or anything else to unset my user
[16:40] <maxb> james_w: Thanks for the approve on lp:~maxb/udd/explanations - just to note, I don't have landing access - will you land, or shall I ask one of the folks at the bzr sprint with me to do so? (Or is it acceptable for me to be added to ~udd ?)
[16:41] <james_w> maxb, I don't think there would be an issue with you being in ~udd, let me add you
[16:42] <santagada>  quiznilo, I don't know, maybe edit the bzr config by hand
[16:43] <james_w> maxb, added, please go ahead and land
[16:43] <maxb> Thanks, will do!
[16:48] <LarstiQ> santagada: https://code.launchpad.net/~larstiq/bzr/bzr-pypy/+merge/60986 fwiw
[16:49] <LarstiQ> quiznilo: there is bzr config, which has a --remove option
[16:52] <quiznilo> k
[16:53] <santagada> LarstiQ, my user is santagada on launchpad.net also
[16:53] <quiznilo> http://howto.praqma.net/bazaar/bazaar-on-windows <-- helped with SSH issues
[16:53] <LarstiQ> santagada: stable usernames are so convenient :)
[16:53] <LarstiQ> quiznilo: good
[16:59] <quiznilo> bzr checkout lp:IrcDotNet <- yeilds: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/%2Bbranch/IrcDotNet/".
[17:00] <quiznilo> I know the project has a link to the 0.4.0 SRC, but I was told to use BZR to download 'tip'
[17:01] <LarstiQ> quiznilo: the projectname appears to be lower case
[17:01] <quiznilo> I think he said 'tip'
[17:01] <LarstiQ> quiznilo: lp:ircdotnet exists
[17:01] <quiznilo> hmm
[17:01] <quiznilo> there it goes... I think
[17:01] <LarstiQ> quiznilo: 'tip' means the most recent revision (on a branch, in this case lp:ircdotnet is assumed methinks)
[17:02] <LarstiQ> well, it's a bit more general in say mercurial, but never mind that :)
[17:02] <quiznilo> I think I got it, thanks for your help, I've never used a VCS system before beyond: git co git://whatever
[17:09] <santagada> quiznilo, if you plan to program you should learn at least one
[17:09] <santagada> quiznilo, and use it
[17:13] <quiznilo> I've been programming for years
[17:14] <quiznilo> thanks for the help
[18:52] <poolie> o/ jam
[18:52] <jam> hi poolie, just casually around
[18:57] <poolie> np, hi
[18:57] <jam> I have this update_basis_by_delta monkey on my back
[18:57] <jam> I can't shake it :)
[19:01] <poolie> http://www.pixoulphotography.com/2011/05/18/official-uds-o-group-photo-and-personal-photo-set/ nice
[19:53] <james_w> jelmer, maxb: thanks for all the branches/fixes
[19:53] <james_w> I guess you've finished for the day now, so I can get back to work ;-)
[20:01] <jelmer> james_w: Hey :)
[20:02] <jelmer> james_w: Sorry (: Thanks for the quick reviews, that's really useful.
[20:02] <james_w> no problem
[20:02] <james_w> I'm only kidding
[20:02] <jelmer> You know where to find me if I can return the favour :)
[20:02] <james_w> it doesn't take me at all long to review your code
[20:44] <workthrick> hiya, is it currently possible/reasonable to work with bzr-colo on a bound branch?
[20:45] <workthrick> I work from multiple machines, and have in the past forgot to commit things in one place and then couldn't use it in the other. So I moved to having all of my branches bound to a single remote one so that it's impossible to forget to push
[20:46] <workthrick> but now I've got enough complexity in the code that I'd actually like to have colocated branches. Yet I don't want to go back to pushing manually
[20:51] <workthrick> I see I can't make a chain of bound branches, bzr errors at me if I have A bound to B and B bound to C
[20:51] <workthrick> which is good in a way, at least it states plainly that it refuses to cooperate instead of breaking silently :)
[20:52] <mgz> ...it's really time to leave and get some food now
[20:52] <mgz> just *one* little merge proposal first
[21:00] <LarstiQ> doh
[21:00]  * LarstiQ will have to ask mgz tomorrow
[21:08] <workthrick> hmm, actually it seems that bzr-colo should be happy working with a remote workspace
[21:34] <thomi> Hi. Why is "Repository.copy_content_into(...)" a "destrive operation"? Surely if it's a _copy_... or am I missing something?
[21:34] <thomi> *destructive, that is.
[21:41] <workthrick> hmm, how can I tell bzr to filter out paramiko's messages below WARN? It connects a logger, and it outputs everything to console by default, which is horribly verbose
[22:14] <workthrick> hmm, why does bzr connect 4 times (!) over ssh to carry out bzr colo-branches on a remote workspace?
[22:14] <workthrick> remote == sftp://