[01:22] <mangojambo> hi, I 'm using bazaar explorer on mac and  when I try to go to Settings > Configuration > User configuration it is giving me this error: QFileSystemWatcher: failed to add paths: /Users/myuser/.bazaar/bazaar.conf
=== jfroy_ is now known as jfroy_mobile
[16:57] <dev001> I've had xmloutput installed as a plugin.  it recently started reporting: "cannot import name _escape_cdata; Unable to load plugin 'xmloutput' from '/usr/local/lib/python2.6/site-packages/bzrlib/plugins'" at any/all bzr pulls ...
[16:58] <dev001> I've not found any related/recent bugs (yet)  ... anyone heard of this?  maybe a config issue on _my_ end?
[17:29] <maxb> dev001: can you check the traceback in .bzr.log and see what module that symbol is being imported from?
[17:49] <dev001> maxb: sorry, didn't hear you 'ping' ... here's the log output: http://pastebin.com/jNf0nD1S
[18:04] <maxb> dev001: I'm supposing your bzr version is too old, then
[18:04] <mgz> that's me.
[18:05] <mgz> see bug 614522 for the whys
[18:05] <ubot5> Launchpad bug 614522 in Bazaar "Monkey patching private escaping functions breaks with ElementTree 1.3 (affected: 1, heat: 6)" [High,Fix released] https://launchpad.net/bugs/614522
[18:06] <mgz> I'm still planning on working out some kind of minimal xmloutput branch that doesn't get my name in the blame all over the place
[18:07] <mgz> what else was I going to say in this review comment to vila... I forget
[18:12] <vila> mgz: then just finish that patch :-D Sorry, I didn't found the time to work on it myself, I just reverted the deletion of __escape_cdata as a quick-and-dirty fix :-}
[18:12]  * vila off for dinner
[18:12] <mgz> ah, on bzr.dev already?
[18:12] <vila> mgz: but your pyjunitxml fixes did wonders...
[18:12] <vila> mgz: no ! only locally
[18:13] <mgz> okay, okay, branch up today to get it out the way :)
[18:13] <mgz> I'll leave my other >_< over xmloutput for later
[18:13] <vila> (locally for both the _escape_cdata fix and the pyjunitxml one
[18:14] <dev001> maxb I'm using an up to date pull of: Bazaar (bzr) 2.3.0dev1
[18:15] <vila> mgz: indeed, you should talk with verterok about it anyway as bzr-xmlouput is used by other plugins, but the long term plan should be to have an 'xml' log formatter and from there the same kind of formatter for other commands. After all, this is supposed to be a supported way to comunnicate with some IDEs or something
[18:15] <mgz> dev001: as I was saying, that's the problem, I just broke it a few days ago
[18:15] <vila> mgz: that's what should drive the 'cleanless' of the xml used, may json should be used even
[18:16] <dev001> mgz: ah, just catching up reading ... thx.  so, update xmloutput branch?
[18:16] <mgz> you can cherrypick out r5407 on bzr.dev for the moment, and I'll get a fix up for xmloutput in a bit
[18:17] <dev001> mgz: np, and thanks!
[18:19] <dev001> hm.  while i'm 'looking', i also see: "/usr/lib64/python2.6/site-packages/Crypto/Util/randpool.py:40: RandomPool_DeprecationWarning: This application uses RandomPool, which is BROKEN in older releases.  See http://www.pycrypto.org/randpool-broken RandomPool_DeprecationWarning)"
[18:19] <dev001> which, i think, is unrelated ... checking
[18:24] <mgz> that is, it's... bug 271791
[18:24] <ubot5> Launchpad bug 271791 in paramiko "Paramiko depends on RandomPool (affected: 5, heat: 26)" [Medium,Triaged] https://launchpad.net/bugs/271791
[18:25] <dev001> mgz: jeez!  to which I'd posted ... getting old & forgetful.  thx!
[18:26] <mgz> so you had :)
[18:26]  * dev001 blames it on the weather, or moon phase, or a black-cat, ... or sumthin ;-p
[18:27] <dev001> tracking the bug-trackers is a job in itself!
=== jfroy_ is now known as jfroy
=== Pilky_ is now known as Pilky
=== ScottK2 is now known as ScottK
[21:57] <micahg> does bzr have an issue with non-ascii commit messages?
[21:58] <vila> micahg: it had, I shouldn't anymore. Which version ? (bzr version)
[21:58] <micahg> vila: 2.1.1
[21:59] <vila> micahg: 2.2 is out, try it and file a bug if the problem persists. I'm 80% sure we fixed bugs in this area
[22:00]  * micahg tries adding the bzr dev PPA to see if it helps
[22:01] <vila> micahg: 2.1.2 is out in case you want to be extra careful about updates
[22:01] <vila> micahg: oh, ppa, you're on Ubuntu then, which release ?
[22:01] <micahg> vila: lucid, about to upgrade to maverick though
[22:01] <micahg> maverick has 2.2.0, I guess I can jsut wait :)
[22:03] <micahg> thanks vila
[22:03] <vila> micahg: what's your locale ?
[22:03] <micahg> C ATM, I need to fix it
[22:04] <vila> micahg: this alone could explain the problem. bzr needs to know how to decode your non-ascii message, so if you tell it it's C...it can't
[22:04] <vila> just try export LC_ALL=UTF-8
[22:05] <micahg> I tried setting LANG to en_US-UTF.8, but it didn't help
[22:05] <micahg> oops, might have had the syntax wrong :)
[22:05] <vila> micahg: the last I tried to understand which one has to be set, I resigned, I just use LC_ALL :-/
[22:05]  * micahg tries again
[22:06] <micahg> vila: it's happy, thanks
[22:06] <vila> micahg: great, care to file a bug ? We should issue a better error message in that case I'm afraid
[22:07] <micahg> vila: well, it warned that it was an unsupported locale string
[22:08]  * micahg just didn't read the error messages well (running on 4 hrs sleep :))
[22:08] <vila> micahg: but enough to help you find the solution. bzr can't (... or could it ?) guess the encoding, but it could tell you that you tried to use a commit message that requires one
[22:09] <vila> micahg: but NOT enough to help you find the solution. bzr can't (... or could it ?) guess the encoding, but it could tell you that you tried to use a commit message that requires one
[22:09] <micahg> vila: no, it was clear enough, I just focused on the bzr error, the locale error should've tipped me off
[22:14] <vila> micahg: It looks like we are in violent argument :) What I mean is that WARNING about locale could be nicely complemented by an additional help in the bzr ERROR to tipped you off :)
[22:14] <vila> grrr, joke ruining typo of the day: s/argument/agreement/
[22:15] <fullermd> Typo?  You?
[22:15] <vila> blast on that's typo ruining joke, even fullermd missed it or kindly believed it was a joke in itself ;-}
[22:16] <fullermd> Hey!  No recursion!
[22:17] <vila> yeah, always put a stop condition or it degrades into a mere loop...
[22:18] <micahg> vila: http://pastebin.ubuntu.com/488920/
[22:18] <vila> fullermd: hey, look at that: http://babune.ladeuil.net:24842/ freebsd is the only one with 5 successful builds ;-)
[22:19] <fullermd> Naturally.  Good solid American code.  None of that flaky European imitation hackery   ;p
[22:20] <vila> fullermd: yeah, who cares if some of those accented letters get translated into CR or even LF when they lose their high bit, really who ?
[22:20] <fullermd> High bits are a device of the devil anyway.
[22:21] <vila> fullermd: and anti-democratic at that, what with high and low bits, all bits are equal !!
[22:21] <fullermd> 7 bits were good enough for Jesus, and they're good enough for m1
[22:21] <fullermd> And me.
[22:22] <vila> fullermd: really ? I thought he multiply them... didn't know he stopped at 7... IMBW though
[22:23] <fullermd> Yeah.  Just vicious lies told by the people who tried to sell 36 bit words  :p
[22:24] <vila> micahg: ha ! _get_uicode_argv is now called _get_unicode_argv and... http://pastebin.ubuntu.com/488925/
[22:24] <vila> micahg: looks like we don't to fix *that* bug ;)
[22:24] <vila> micahg: looks like we don't need to fix *that* bug ;)
[23:07] <_habnabit> Is there a web interface similar to hg's interface but for bzr? Really what I'm looking for is loggerhead + easy tarball exports.
=== CcxCZ_ is now known as CcxCZ
=== Ursinha is now known as Ursinha-afk