mgz | okay, I'm seeing 101 failures. | 00:02 |
---|---|---|
mgz | will try the _make_stream_binary fix. | 00:02 |
lifeless | yes, thats about right | 00:04 |
lifeless | I have | 00:04 |
lifeless | 95 | 00:04 |
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:09 |
* mgz pulls | 00:10 | |
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:13 |
mgz | in ProtocolTestCase. | 00:14 |
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:15 |
mgz | oh, wow, redirecting stdout just did something interesting | 00:16 |
mgz | http://paste.ubuntu.com/598473/ | 00:17 |
mgz | the current set of different types of failure is reassuringly small though. | 00:18 |
lifeless | iteritems -> items done and pushing | 00:19 |
lifeless | I'm running the tests thusly | 00:20 |
lifeless | :!PYTHONPATH=python:~/source/unittest/testtools/working python3.1 ./runtests.py 2>&1 | less | 00:20 |
mgz | I did `%PY3K% -m testtools.run subunit.tests.test_suite > B:\subtests.log` | 00:23 |
mgz | possibly some weird testtools interaction, I'll use your way. | 00:24 |
mgz | hm, streams certainly getting crossed somewhere if I redirect. | 00:27 |
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:30 |
lifeless | kingos: what os ? | 00:31 |
kingos | lifeless: re 5 | 00:31 |
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:32 |
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:33 |
kingos | urgh, something is really broken. running bzr selftest still fails with hundreds of errors | 00:36 |
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:37 |
mgz | lifeless: lp:~gz/subunit/py3k | 00:41 |
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:42 |
kingos | mgz: ok | 00:44 |
mgz | delete the build dir, then tee the setup.py log to file and post it. | 00:44 |
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:45 |
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:46 |
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:47 |
kingos | I am still getting failures on bzr selftest stats, a plugin I am trying to use | 00:48 |
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:51 |
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:52 |
mgz | as in, would need them to update that package. | 00:53 |
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 | 00:56 |
quotemstr | What exactly does "nosmart" do? | 01:06 |
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:16 |
spiv | That seems like a strange thing to recommend. Perhaps savannah doesn't have much memory? | 01:17 |
mgz | there was a thread about the initial checkout speed on the bazaar mailing list, wasn't there spiv? | 01:19 |
quotemstr | spiv? | 01:19 |
quotemstr | I'm just talking about the instructions in the wiki: http://www.emacswiki.org/emacs/BzrForEmacsDevs | 01:20 |
mgz | https://lists.ubuntu.com/archives/bazaar/2011q1/071574.html | 01:21 |
mgz | particularly https://lists.ubuntu.com/archives/bazaar/2011q1/071683.html | 01:22 |
quotemstr | Thanks. | 01:27 |
lifeless | 50 errors | 01:30 |
lifeless | quotemstr: mgz: that should be revisited with jam's recent perf work | 01:48 |
lifeless | both server and client will need updating | 01:48 |
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:49 |
lifeless | quotemstr: depends on your ΓΈ | 01:50 |
lifeless | for most things its not meaningfully different | 01:50 |
lifeless | mgz: we're getting there - FAILED (failures=17, errors=16) | 01:51 |
mgz | lifeless, have you merged my branch yet? | 01:52 |
lifeless | yes | 01:52 |
lifeless | pushed rev 149 which merges yours | 01:53 |
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:54 |
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:55 |
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:58 |
ubot5 | Launchpad bug 663600 in testtools "Use Python 3 style qualified exception names in tracebacks" [Medium,Triaged] https://launchpad.net/bugs/663600 | 01:58 |
mgz | oh, and test_join_dir not getting the path it wants. | 01:59 |
lifeless | mgz: the exception name is fixed | 02:10 |
lifeless | basestring stuff is in the iso8601 module | 02:10 |
lifeless | mgz: the os.fork & fdopen ones will be less mechanical, if you want to look at it | 02:11 |
=== Ursinha is now known as Ursinha-afk | ||
lifeless | grrrr | 02:55 |
lifeless | bytes('fo %d %d', 'utf8') % (1, 2) -> boom | 02:55 |
kingos | If a plugin command does "raise errors.BzrCommandError", how come the return code of bzr is not set to something non-zero? | 02:59 |
kingos | hello? | 03:08 |
lifeless | mgz: thanks for your help | 06:30 |
lifeless | jml: around ? | 06:31 |
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:38 |
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:39 |
kingos | ah, that worked! thanks | 07:40 |
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:42 |
jelmer | kingos: which string is padded? | 07:46 |
jelmer | and where is it padded? | 07:47 |
kingos | jelmer: if I add that option, then just do print "blah=", blah | 07:48 |
kingos | then run bzr blah=abc | 07:48 |
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:49 |
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:58 |
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? | 07:59 |
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:00 |
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:01 |
jelmer | I think it's on by default, at least that's what the testsuite uses | 08:03 |
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:04 |
jelmer | time for some sun :) Back later | 08:11 |
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:47 |
rocky | maxb: ubuntu natty standard packages (no extra ppa's) | 15:48 |
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:49 |
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:50 |
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:51 |
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:56 |
maxb | like bzr-svn at the moment, I think | 15:57 |
maxb | Because it's still catching up with bzr core | 15:57 |
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:00 |
maxb | And a nasty little incompatibility between bzrlib's plugin loading mechanism and different python package management methodology methods is breaking things | 16:01 |
* maxb comments on bug 752396 | 16:05 | |
ubot5 | Launchpad bug 752396 in bzr-fastimport (Ubuntu) "bzr-fastimport is not listed in "bzr plugins" list" [Undecided,Confirmed] https://launchpad.net/bugs/752396 | 16:05 |
=== 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 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!