[00:02] <mgz> okay, I'm seeing 101 failures.
[00:02] <mgz> will try the _make_stream_binary fix.
[00:04] <lifeless> yes, thats about right
[00:04] <lifeless> I have
[00:04] <lifeless> 95
[00:09] <lifeless> os.fdopen needs fixing too
[00:09] <lifeless> I wonder if the same thing can be tweaked
[00:09] <lifeless> mgz: pushing up my current
[00:09] <mgz> well, fix gets me 11 errors down, and there are some more which, somehow are getting a *bool* for the stream
[00:10]  * mgz pulls
[00:13] <mgz>     def __init__(self, stream, passthrough=None, forward=False):
[00:13] <mgz> ...
[00:13] <mgz>         self._forward = forward
[00:13] <mgz>         _make_stream_binary(forward)
[00:13] <mgz> that's just an error right?
[00:14] <mgz> in ProtocolTestCase.
[00:15] <mgz> lineReceived is currently very unhappy because it doesn't know if it's dealing with bytes or strings.
[00:15] <lifeless> always bytes
[00:15] <mgz> you fixed it for bytes, and now all the tests that pass string literals are making it cry.
[00:15] <lifeless> yes
[00:16] <mgz> oh, wow, redirecting stdout just did something interesting
[00:17] <mgz> http://paste.ubuntu.com/598473/
[00:18] <mgz> the current set of different types of failure is reassuringly small though.
[00:19] <lifeless> iteritems -> items done and pushing
[00:20] <lifeless> I'm running the tests thusly
[00:20] <lifeless> :!PYTHONPATH=python:~/source/unittest/testtools/working python3.1 ./runtests.py 2>&1 | less
[00:23] <mgz> I did `%PY3K% -m testtools.run subunit.tests.test_suite > B:\subtests.log`
[00:24] <mgz> possibly some weird testtools interaction, I'll use your way.
[00:27] <mgz> hm, streams certainly getting crossed somewhere if I redirect.
[00:30] <kingos> can anyone help me? I am trying to run bzr.dev from source, but keep getting the following warnings:
[00:30] <kingos> _dirstate_helpers_pyx.so: undefined symbol: __stack_chk_guard
[00:31] <lifeless> kingos: what os ?
[00:31] <kingos> lifeless: re 5
[00:32] <lifeless> re?
[00:32] <mgz> anyway, getting distracted, fix seems to work, I'll push it up for your consideration
[00:32] <kingos> redhat
[00:32] <kingos>  enterprise
[00:32] <lifeless> ah
[00:32] <lifeless> hmm
[00:32] <lifeless> kingos: what python version ?
[00:32] <mgz> and which source? a tarball, or a bzr checkout where you're compiling with what pyrex version?
[00:32] <kingos> lifeless: 2.4
[00:33] <kingos> bzr checkout
[00:33] <kingos> no pyrex
[00:33] <kingos> do I need to install pyrex?
[00:33] <lifeless> possibly yeah
[00:33] <lifeless> or do a make clean
[00:33] <lifeless> and run without the C extensions
[00:36] <kingos> urgh, something is really broken. running bzr selftest still fails with hundreds of errors
[00:37] <lifeless> the selftest looks for the C extensions
[00:37] <lifeless> check the names of the failures
[00:37] <lifeless> or pastebin them and I'll eyeball for you
[00:41] <mgz> lifeless: lp:~gz/subunit/py3k
[00:42] <mgz> kingos: if you're doing setup.py in a checkout, you must have pyrex or cython installed or you wouldn't get any of hte pyx files like _dirstate_helpers_pyx at all
[00:44] <kingos> mgz: ok
[00:44] <mgz> delete the build dir, then tee the setup.py log to file and post it.
[00:45] <kingos> mgz: ok, maybe I have screwed stuff up .. Pyrex is installed under python2.4, but not python2.6, and I tried running setup.py with 2.6 after already running 2.4. Selftest is passing again now
[00:46] <mgz> yeah, that sounds possible. going again from scratch is the right option in those situations.
[00:46] <kingos> mgz: although I am still getting __stack_chk_guard undefined
[00:46] <kingos> in a few .so files
[00:47] <mgz> if you want to try on 2.6 you can use `python2.6 ./setup.py build_ext --allow-python-fallback install` to not require pyrex
[00:47] <kingos> ok
[00:48] <kingos> I am still getting failures on bzr selftest stats, a plugin I am trying to use
[00:51] <mgz> you may need to report bugs, not all plugins are covered by the bazaar testing infrastructure yet
[00:51] <mgz> and there have been some changes to command registration etc recently
[00:52] <kingos> mgz: ok, thanks for the help
[00:52] <mgz> the warning smells like a problem with the code pyrex is generating, or the flags it's getting compiled with, which is presumably a bug the red hat end.
[00:53] <mgz> as in, would need them to update that package.
[00:56] <mgz> kingos: to try a still recent, but slightly earlier version of bzr, you could do `bzr update -r tag:bzr-2.4b1` and rebuild to see if the plugin failures are regressions
[01:06] <quotemstr> What exactly does "nosmart" do?
[01:16] <spiv> quotemstr: basically reduces to fetching files
[01:16] <quotemstr> Ah. The Emacs bzr instructions recommend its use, but I don't recall seeing it mentioned in TFM.
[01:16] <spiv> quotemstr: so it still uses the smart protocol, but no requests in it smart than say SFTP, it's all "get this file, put this file" rather than "open branch, insert revisions"
[01:17] <spiv> That seems like a strange thing to recommend.  Perhaps savannah doesn't have much memory?
[01:19] <mgz> there was a thread about the initial checkout speed on the bazaar mailing list, wasn't there spiv?
[01:19] <quotemstr> spiv?
[01:20] <quotemstr> I'm just talking about the instructions in the wiki: http://www.emacswiki.org/emacs/BzrForEmacsDevs
[01:21] <mgz> https://lists.ubuntu.com/archives/bazaar/2011q1/071574.html
[01:22] <mgz> particularly https://lists.ubuntu.com/archives/bazaar/2011q1/071683.html
[01:27] <quotemstr> Thanks.
[01:30] <lifeless> 50 errors
[01:48] <lifeless> quotemstr: mgz: that should be revisited with jam's recent perf work
[01:48] <lifeless> both server and client will need updating
[01:49] <quotemstr> lifeless: I'll look forward to the change when it's available on bzr and launchpad.
[01:49] <quotemstr> lifeless: How far is bzr from git performance parity?
[01:50] <lifeless> quotemstr: depends on your ø
[01:50] <lifeless> for most things its not meaningfully different
[01:51] <lifeless> mgz: we're getting there - FAILED (failures=17, errors=16)
[01:52] <mgz> lifeless, have you merged my branch yet?
[01:52] <lifeless> yes
[01:53] <lifeless> pushed rev 149 which merges yours
[01:54] <lifeless> quotemstr: there were some standouts which hav ebeen fixed in trunk in the last fortnight
[01:54] <mgz> cool, that's down to 28 for me.
[01:55] <lifeless> quotemstr: all but one of those are accessible just by running a trunk build; the final one requires the server to change (because the server is sending data andthe fix is in the sending logic)
[01:55] <quotemstr> Cool.
[01:58] <mgz> a few from bug 663600, some from basestring not existing, a few remaining bytes/unicode lineReceived ones, two os.fork ones, some bytes ones in _addOutcome, and some serialisation ones
[01:59] <mgz> oh, and test_join_dir not getting the path it wants.
[02:10] <lifeless> mgz: the exception name is fixed
[02:10] <lifeless> basestring stuff is in the iso8601 module
[02:11] <lifeless> mgz: the os.fork & fdopen ones will be less mechanical, if you want to look at it
[02:55] <lifeless> grrrr
[02:55] <lifeless> bytes('fo %d %d', 'utf8') % (1, 2) -> boom
[02:59] <kingos> If a plugin command does  "raise errors.BzrCommandError", how come the return code of bzr is not set to something non-zero?
[03:08] <kingos> hello?
[06:30] <lifeless> mgz: thanks for your help
[06:31] <lifeless> jml: around ?
[07:38] <kingos> hi, if I run a test by run_bzr, how do I check the error code? the typical usage seems to be:
[07:38] <jelmer> kingos: usually you specify the expected error code
[07:38] <kingos> out, err = self.run_bzr(...), where err is sys.err
[07:39] <jelmer> e.g. "out, err = self.run_bzr(["command", "arg1"], retcode=3)
[07:39] <kingos> jelmer: thanks, is there an example of that somewhere?
[07:39] <kingos> ah... I was grepping for errors.EXIT_ERROR
[07:39] <jelmer> I think we usually just use numbers in the testsuite
[07:40] <kingos> ah, that worked! thanks
[07:42] <kingos> jelmer: another question while I have you, if I pass an option to takes_options as part of a command, ie. option.Option('blah', type=str'), the string seems to be padded with a space either side. Is this expected?
[07:46] <jelmer> kingos: which string is padded?
[07:47] <jelmer> and where is it padded?
[07:48] <kingos> jelmer: if I add that option, then just do print "blah=", blah
[07:48] <kingos> then run bzr blah=abc
[07:49] <jelmer> kingos: I think that's more just the print command
[07:49] <kingos> I get 'blah= abc '
[07:49] <jelmer> >>> print "bla=", "foo"
[07:49] <jelmer> bla= foo
[07:49] <kingos> jelmer: ah ok
[07:49] <kingos> python amateur
[07:49] <kingos> :)
[07:58] <kingos> hi, another question, if a command is outputting something with trace.note, how do I setup the tests correctly so I still can do self.assertEquals(err, '')
[07:59] <jelmer> test against out (stdout) rather than err
[07:59] <jelmer> in other words, the first element in the tuple returned by run_bzr
[07:59] <kingos> oh, so tests shouldn't check the contents of error?
[08:00] <jelmer> they should check the contents of both
[08:00] <jelmer> some things (like errors) will go to stderr, some things (e.g. file content from "bzr cat") will go to stdout
[08:01] <kingos> sure. I thought trace.note output was optional though, it could be turned on or off depending on some settings? in which case, I should be testing with it off right?
[08:03] <jelmer> I think it's on by default, at least that's what the testsuite uses
[08:04] <kingos> ah ok thanks
[08:04] <jelmer> Something like --quiet might turn it off, but I don't think I've ever used bzr without it
[08:11] <jelmer> time for some sun :) Back later
[15:47] <rocky> has anyone noticed that on natty (ubuntu), after installing bzr and bzr-fastimport apt packages, "bzr plugins" does not list fastimport ?
[15:47] <rocky> am i supposed to do something extra to activate that plugin?
[15:47] <maxb> rocky: Which packages? Ubuntu primary archive only, or ~bzr PPA ?
[15:48] <rocky> maxb: ubuntu natty standard packages (no extra ppa's)
[15:49] <maxb> huh, you're right. how odd
[15:49] <rocky> maxb: is the bzr ppa stable enough? i'd just use that if it's going to keep more recent bzr and bzr plugin releases
[15:50] <maxb> There are multiple ~bzr PPAs
[15:50] <maxb> bzr/ppa for the really stable stuff
[15:50] <maxb> bzr/proposed for the probably stable stuff, but we're checking and occasionally building interdependent sets of packages
[15:51] <maxb> bzr/beta for the not-exactly-stable but still mostly safe stuff
[15:51] <maxb> bzr/daily for the really bleeding edge stuff
[15:51] <maxb> :-)
[15:56] <rocky> sounds like i'll go with bzr/beta ;)
[15:56] <maxb> Bear in mind that some plugins in there can be expected to be occasionally broken
[15:56] <rocky> right
[15:57] <maxb> like bzr-svn at the moment, I think
[15:57] <maxb> Because it's still catching up with bzr core
[16:00] <maxb> Hmm
[16:00] <maxb> So, I think bzr-fastimport is broken in natty because it's the only packaged bzr plugin to be using python-support instead of python-central
[16:01] <maxb> And a nasty little incompatibility between bzrlib's plugin loading mechanism and different python package management methodology methods is breaking things
[16:05]  * maxb comments on bug 752396