[00:02] okay, I'm seeing 101 failures. [00:02] will try the _make_stream_binary fix. [00:04] yes, thats about right [00:04] I have [00:04] 95 [00:09] os.fdopen needs fixing too [00:09] I wonder if the same thing can be tweaked [00:09] mgz: pushing up my current [00:09] 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] def __init__(self, stream, passthrough=None, forward=False): [00:13] ... [00:13] self._forward = forward [00:13] _make_stream_binary(forward) [00:13] that's just an error right? [00:14] in ProtocolTestCase. [00:15] lineReceived is currently very unhappy because it doesn't know if it's dealing with bytes or strings. [00:15] always bytes [00:15] you fixed it for bytes, and now all the tests that pass string literals are making it cry. [00:15] yes [00:16] oh, wow, redirecting stdout just did something interesting [00:17] http://paste.ubuntu.com/598473/ [00:18] the current set of different types of failure is reassuringly small though. [00:19] iteritems -> items done and pushing [00:20] I'm running the tests thusly [00:20] :!PYTHONPATH=python:~/source/unittest/testtools/working python3.1 ./runtests.py 2>&1 | less [00:23] I did `%PY3K% -m testtools.run subunit.tests.test_suite > B:\subtests.log` [00:24] possibly some weird testtools interaction, I'll use your way. [00:27] hm, streams certainly getting crossed somewhere if I redirect. [00:30] can anyone help me? I am trying to run bzr.dev from source, but keep getting the following warnings: [00:30] _dirstate_helpers_pyx.so: undefined symbol: __stack_chk_guard [00:31] kingos: what os ? [00:31] lifeless: re 5 [00:32] re? [00:32] anyway, getting distracted, fix seems to work, I'll push it up for your consideration [00:32] redhat [00:32] enterprise [00:32] ah [00:32] hmm [00:32] kingos: what python version ? [00:32] and which source? a tarball, or a bzr checkout where you're compiling with what pyrex version? [00:32] lifeless: 2.4 [00:33] bzr checkout [00:33] no pyrex [00:33] do I need to install pyrex? [00:33] possibly yeah [00:33] or do a make clean [00:33] and run without the C extensions [00:36] urgh, something is really broken. running bzr selftest still fails with hundreds of errors [00:37] the selftest looks for the C extensions [00:37] check the names of the failures [00:37] or pastebin them and I'll eyeball for you [00:41] lifeless: lp:~gz/subunit/py3k [00:42] 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] mgz: ok [00:44] delete the build dir, then tee the setup.py log to file and post it. [00:45] 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] yeah, that sounds possible. going again from scratch is the right option in those situations. [00:46] mgz: although I am still getting __stack_chk_guard undefined [00:46] in a few .so files [00:47] 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] ok [00:48] I am still getting failures on bzr selftest stats, a plugin I am trying to use [00:51] you may need to report bugs, not all plugins are covered by the bazaar testing infrastructure yet [00:51] and there have been some changes to command registration etc recently [00:52] mgz: ok, thanks for the help [00:52] 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] as in, would need them to update that package. [00:56] 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] What exactly does "nosmart" do? [01:16] quotemstr: basically reduces to fetching files [01:16] Ah. The Emacs bzr instructions recommend its use, but I don't recall seeing it mentioned in TFM. [01:16] 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] That seems like a strange thing to recommend. Perhaps savannah doesn't have much memory? [01:19] there was a thread about the initial checkout speed on the bazaar mailing list, wasn't there spiv? [01:19] spiv? [01:20] I'm just talking about the instructions in the wiki: http://www.emacswiki.org/emacs/BzrForEmacsDevs [01:21] https://lists.ubuntu.com/archives/bazaar/2011q1/071574.html [01:22] particularly https://lists.ubuntu.com/archives/bazaar/2011q1/071683.html [01:27] Thanks. [01:30] 50 errors [01:48] quotemstr: mgz: that should be revisited with jam's recent perf work [01:48] both server and client will need updating [01:49] lifeless: I'll look forward to the change when it's available on bzr and launchpad. [01:49] lifeless: How far is bzr from git performance parity? [01:50] quotemstr: depends on your ø [01:50] for most things its not meaningfully different [01:51] mgz: we're getting there - FAILED (failures=17, errors=16) [01:52] lifeless, have you merged my branch yet? [01:52] yes [01:53] pushed rev 149 which merges yours [01:54] quotemstr: there were some standouts which hav ebeen fixed in trunk in the last fortnight [01:54] cool, that's down to 28 for me. [01:55] 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] Cool. [01:58] 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:58] Launchpad bug 663600 in testtools "Use Python 3 style qualified exception names in tracebacks" [Medium,Triaged] https://launchpad.net/bugs/663600 [01:59] oh, and test_join_dir not getting the path it wants. [02:10] mgz: the exception name is fixed [02:10] basestring stuff is in the iso8601 module [02:11] mgz: the os.fork & fdopen ones will be less mechanical, if you want to look at it === Ursinha is now known as Ursinha-afk [02:55] grrrr [02:55] bytes('fo %d %d', 'utf8') % (1, 2) -> boom [02:59] If a plugin command does "raise errors.BzrCommandError", how come the return code of bzr is not set to something non-zero? [03:08] hello? [06:30] mgz: thanks for your help [06:31] jml: around ? [07:38] hi, if I run a test by run_bzr, how do I check the error code? the typical usage seems to be: [07:38] kingos: usually you specify the expected error code [07:38] out, err = self.run_bzr(...), where err is sys.err [07:39] e.g. "out, err = self.run_bzr(["command", "arg1"], retcode=3) [07:39] jelmer: thanks, is there an example of that somewhere? [07:39] ah... I was grepping for errors.EXIT_ERROR [07:39] I think we usually just use numbers in the testsuite [07:40] ah, that worked! thanks [07:42] 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] kingos: which string is padded? [07:47] and where is it padded? [07:48] jelmer: if I add that option, then just do print "blah=", blah [07:48] then run bzr blah=abc [07:49] kingos: I think that's more just the print command [07:49] I get 'blah= abc ' [07:49] >>> print "bla=", "foo" [07:49] bla= foo [07:49] jelmer: ah ok [07:49] python amateur [07:49] :) [07:58] 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] test against out (stdout) rather than err [07:59] in other words, the first element in the tuple returned by run_bzr [07:59] oh, so tests shouldn't check the contents of error? [08:00] they should check the contents of both [08:00] some things (like errors) will go to stderr, some things (e.g. file content from "bzr cat") will go to stdout [08:01] 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] I think it's on by default, at least that's what the testsuite uses [08:04] ah ok thanks [08:04] Something like --quiet might turn it off, but I don't think I've ever used bzr without it [08:11] time for some sun :) Back later [15:47] has anyone noticed that on natty (ubuntu), after installing bzr and bzr-fastimport apt packages, "bzr plugins" does not list fastimport ? [15:47] am i supposed to do something extra to activate that plugin? [15:47] rocky: Which packages? Ubuntu primary archive only, or ~bzr PPA ? [15:48] maxb: ubuntu natty standard packages (no extra ppa's) [15:49] huh, you're right. how odd [15:49] 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] There are multiple ~bzr PPAs [15:50] bzr/ppa for the really stable stuff [15:50] bzr/proposed for the probably stable stuff, but we're checking and occasionally building interdependent sets of packages [15:51] bzr/beta for the not-exactly-stable but still mostly safe stuff [15:51] bzr/daily for the really bleeding edge stuff [15:51] :-) [15:56] sounds like i'll go with bzr/beta ;) [15:56] Bear in mind that some plugins in there can be expected to be occasionally broken [15:56] right [15:57] like bzr-svn at the moment, I think [15:57] Because it's still catching up with bzr core [16:00] Hmm [16:00] 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] 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 [16:05] Launchpad bug 752396 in bzr-fastimport (Ubuntu) "bzr-fastimport is not listed in "bzr plugins" list" [Undecided,Confirmed] https://launchpad.net/bugs/752396 === deryck is now known as deryck[lunch] === Ursinha-afk is now known as Ursinha === CardinalFang__ is now known as CardinalFang === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno === Ursinha is now known as Ursinha-lunch === Ursinha-lunch is now known as Ursinha