[00:14] <lifeless> argh
[00:14] <lifeless> traceback.format_exception_only is broken
[00:14] <lifeless> whats wrong with this (python 2.6):
[00:14] <lifeless> 171  ->     if (isinstance(etype, BaseException) or
[00:14] <lifeless> 172             isinstance(etype, types.InstanceType) or
[00:14] <lifeless> 173             etype is None or type(etype) is str):
[00:14] <lifeless> 174             return [_format_final_exc_line(etype, value)]
[00:14] <lifeless> mgz: ^
[00:17] <lifeless> ah, little early.
[00:17] <lifeless> hmm, I need a teddy bear
[00:19] <Meths> What's the error msg?
[00:20] <lifeless> it doesn't crash-fail, it formats wrongly
[00:21] <lifeless> looks like some remaining 'string exception' support that hasn't been cleaned up
[00:21] <lifeless> I'm going to see about tackling it differently
[00:23] <lifeless> ok, \o/
[00:23] <lifeless> python3 would be so much nicer
[00:29] <mgz> you say that lifeless
[00:29] <mgz> I spent this afternoon looking at python 3, and have come to the conclusion it doesn't do unicode properly
[00:30] <lifeless> mgz: that doesn't entirely suprise me
[00:30] <lifeless> hey, can I get your opinion on two small patches
[00:30] <lifeless> gimme a sec to pastebin em
[00:30] <lifeless> http://pastebin.com/qrys3xgK
[00:31] <lifeless> http://pastebin.com/M7AwUADN
[00:31] <mgz> http://paste.ubuntu.com/447983/ <- I just want my repl :_:
[00:31] <lifeless> mgz: ironpython3 ?
[00:32] <mgz> no, straight up python 3, built from trunk by my own fair hand this afternoon
[00:32] <mgz> I guess it's just no one has bothered testing it on a non-utf-8 terminal or something
[00:33] <lifeless> is your console encoding set correctly ?
[00:33] <mgz> yes, it's correctly set tp cp932
[00:33] <lifeless> weird
[00:33] <lifeless> so what do you think of those two patches
[00:33] <mgz> sys.stdout is "strict" though, which added to them trying to be clever with repr = bad experience
[00:34] <mgz> first one seems fine.
[00:34] <lifeless> the subunit one is for [] tracebacks, which have no explicit encoding (but I am just going to treat as utf8 and retroactively define them thusly
[00:34] <mgz> second one is building on wrong code.
[00:34] <mgz> the current __str__ method there doesn't do what the person who added it thinks it does
[00:34]  * lifeless provides context
[00:35] <lifeless> PQM is failing to format and attach subunit summaries
[00:35] <lifeless> even though the WEBUI is doing just fine
[00:36] <lifeless> its failing because bzr's formatters upcast stuff to unicode in a couple of places [bad], and because testtools uses the iter_text code path for deserialising text/* objects
[00:36] <lifeless> which become unicode
[00:36] <lifeless> and then traceback.format_exception_only triggers an implicit conversion to __str__, and ye old ascii codec raises its head
[00:37] <lifeless> so the subunit one permits iter_text to work
[00:37] <mgz> where does subunit hook into testtools test results?
[00:37] <lifeless> and the testtools lets it format properly in traceback.format_exception
[00:37] <lifeless> subunit/details.py line 47
[00:38] <lifeless> its weakly coupled - speaks the same object protocol, magic happens
[00:39] <mgz> okay, in which case, I think you just need my traceback branch
[00:39] <mgz> the problem with testtools currently is that exceptions go through traceback.format_exception *twice*
[00:40] <mgz> once originally in the test result, and then again in _StringException form
[00:40] <lifeless> ok
[00:40] <mgz> I changed both of those to use unicode, so it's no longer cooercing to str
[00:41] <lifeless> my testtools patch would seem in line with that change
[00:41] <lifeless> neither right or wrong
[00:42] <lifeless> mgz: I want your patch; is it finished?
[00:42] <lifeless> win goto #debian-devel
[00:42] <mgz> ^it's similar indeed, it's just spelled more specifically in the unicode traceback branch (because the possible variations are reduced)
[00:43] <lifeless> ok
[00:43] <lifeless> so as I'm going to be getting the syadmins to do a kindof backport of these two things
[00:43] <strk> Bazaar (bzr) 2.1.1
[00:43] <lifeless> I'm going to go with the little one, unless it will break your branch.
[00:43] <strk> 4 lines diff
[00:43] <strk> over sftp
[00:43] <strk>   4272KB     3KB/s | Uploading data to master branch - Stage:Fetching revisio
[00:44] <mgz> the main problem with yours is you're hardcoding certain things from the environment that won't always be correct
[00:44] <lifeless> strk: sftp is the problem, its a database
[00:44] <lifeless> strk: if this is savannah, bzr+ssh support is being worked on.
[00:44] <strk> no 'packing' thing ?
[00:44] <strk> long ago someone mentioned it was "packing" one of the problems
[00:44] <mgz> for a backport to fix pqm, I presume this isn't a concern, it's only one machine
[00:44] <lifeless> strk: autopacking is part of the database layer yes
[00:44] <strk> I mean, is there anything I could do to improve the situation while over 'sftp' ?
[00:44] <lifeless> strk: not really.
[00:45] <strk> like disabling autopacking while on gprs ?
 mgz: I want your patch; is it finished? <- I have some brown paper bag things to push, then need to work out how to no re-break py3k support (which is currently broken, so may not matter much), then the moving around we discussed
[00:46] <mgz> it's close, want to get it done before I go away for the weekend really
[00:46] <lifeless> mgz: py3k is broken? worked for me in our hudson
[00:46] <lifeless> mgz: I need to start that machine up again soon
[00:46] <mgz> what method are you using to install it? both ways I tried had problems.
[00:47] <mgz> I filed a bug and made a merge proposal at any rate
[00:47] <lifeless> ah, import issue with the result refactoring
[00:47] <mgz> and 2to3 had problems with the Queue import.
[00:48] <lifeless> yeah, testtools is single-source not 2to3
[00:48] <mgz> anyway, I have a big issue in that there seems to be no source-compatible way of spelling unicode literals
[00:48] <mgz> so I'm not sure how to write the tests I need to do
[00:48] <mgz> u"\u1234" -> ???
[00:49] <mgz> the _u function is useless because it assumes latin-1
[00:49] <mgz> everything else I think I can hack around though.
[00:49] <mgz> (well, I can hack around that too, I just need to pick which ugly method I least dislike)
[00:49] <lifeless> change _u to assume utf8 ?
[00:50] <mgz> that breaks one of the current uses, so I assume it's the way it is for a reason, though it's not clear
[00:50] <lifeless> point me at the use?
[00:50] <mgz> testtools/tests/test_content.py:        self.assertEqual([_u("bytes\xea")], list(content.iter_text()))
[00:51] <lifeless> I love the way 3.x is becoming harder and harder to be compatible with.
[00:51] <lifeless> Its almost like upstream want -no- adopters
[00:51] <mgz> yeah, a bunch of this stuff just doesn't seem thought through
[00:51] <lifeless> mgz: recode that literal as utf8 ?
[00:51] <mgz> can do.
[00:52] <lifeless> mmm
[00:52] <lifeless> actually
[00:52] <lifeless> here's the algorithm:
[00:52] <lifeless>  - find out what python3.x will do with a bare string
[00:52] <mgz> the other option is something like... _unicode(r"\u1234") where I call .decode("unicode-escape") for Python 2
[00:52] <lifeless>  - pick some bare string that will result in the same unicode object that that current one does, with a changed _u function
[00:53] <lifeless>  - then change the _u function as you desire
[00:53] <mgz> need to remember the r for that, but is easier to read than encoded utf-8
[00:54] <lifeless> hah
[00:54] <mgz> also filed a bug for the string exception thing as you requested, I can't actually see any downside to changing to a bare except clause
[00:54] <lifeless> james_w: your patch from python3.x :)
[00:54] <lifeless> whats 'print "foo"' in python3 ?
[00:55] <lifeless> mgz: oh, base exception in all 2.x releases is broken broken broken in its unicode handling
[00:55] <lifeless> mgz: theres a upstream bug about it
[00:55] <lifeless> mgz: __unicode__ triggers ascii decoding, __str__ triggers ascii encoding, with all sorts of weird side conditions IIRC
[00:58] <mgz> yup, got to be careful about what you put in builtin exceptions
[01:04] <lifeless> mgz: ok, 3.1 support pushing up now
[01:05] <mgz> cool, I'll merge trunk back in rather than fiddling with it more here
[01:05] <jelmer> 3.1 support for testtools?
[01:05] <lifeless> jelmer: yep
[01:06] <jelmer> nice
[01:06] <lifeless> we had 3.0
[01:06] <lifeless> but 3.1 changed the rules for imports again
[01:07] <mgz> pushing my fixes for idiocy, I'll then get py3k working
[01:09] <mgz> lifeless: what do you think about moving testtools.utils.iterate_tests to testtools.testsuite.iterate_tests and renaming utils 'compat' or similar?
[01:09] <mgz> it's mostly encoding stuff, but some other misc py3k things too
[01:10] <lifeless> sure
[01:10] <lifeless> uhm
[01:10] <lifeless> please rename utils.py, and then add back a module which imports the old things and does the deprecationwarning dance if its imported at all
[01:11] <mgz> well, iterate_tests is the only public function
[01:11] <lifeless> yes
[01:11] <mgz> I could just leave it there, and move everything else
[01:11] <lifeless> whatever is easier
[01:12] <lifeless> my concern is just that we will probably have folk wanting backports/SRU's
[01:13] <lifeless> and the easier for them, the better - particularly when its low cost to us.
[01:15] <poolie> hi there lifeless, mgz
[01:16] <mgz> hey poolie
[01:17] <mgz> okay, I'm now at... clean on 2.4, clean on IronPython, two failures on Jython due to a single space difference, and syntax error on py3k
[01:18] <mgz> let's squish that last one
[01:24] <poolie> lifeless, i don't want to spend all day on test frameworks
[01:24] <lifeless> I can feel a but turning up ;)
[01:24] <poolie> but i did realize last night that the current protocol means many fixtures
[01:24] <poolie> heh
[01:24] <poolie> many fixtures must override tearDown and then super-call
[01:25] <poolie> similarly setUp
[01:25] <poolie> and we just went through realizing this was error-prone in test cases themselves
[01:26] <lifeless> agreed
[01:26] <lifeless> this seems more an internal contract question, not the public composing contract though ?
[01:33] <poolie> we could say that when you subclass Fixture, you should implement doTearDown for example
[01:33] <poolie> separating out the template method
[01:33] <poolie> alternatively we could just say that fixtures are ObjectWithCleanup
[01:34] <lifeless> [template] I don't think that works very well in python for avoiding 'fail to upcall', because as soon as two classes in one MRO do it, it requires upcalling.
[01:35] <lifeless> something like TestCase.addCleanup would be good, I think
[01:35] <lifeless> I was thinking self.manageFixture(fixture_I_created)
[01:35] <lifeless> to hook into setUp and tearDown in LIFO order
[01:36] <lifeless> james_w: while you're looking at testtools.run, supporting bug 505386 would be most awesome
[01:40] <spm> lifeless: heyo; where are we at with pqm this fine friday?
[01:40] <lifeless> spm: nothing to do at the moment
[01:41] <lifeless> spm: I am doing some metaphorical housecleaning
[01:41] <lifeless> will have some new dep packages to build in CAT later
[01:41] <spm> so... all finished? ie I can close the RT? or leave it pending for now?
[01:41] <spm> ahhh
[01:41] <lifeless> spm: turtles all the way down (python2 and unicode and str types is a freaking disasterous mess)
[01:42] <spm> \o/
[01:43] <mkanat> I thought it was mud all the way down. :-)
[01:43] <lifeless> mkanat: its terrible every which way ;)
[01:43] <mkanat> :-D
[01:43] <lifeless> mkanat: hey glad you're here, we had some 500's on loggerhead today
[01:43] <lifeless> mkanat: not server hangs though
[01:43] <mkanat> lifeless: 500's? That's odd.
[01:43] <lifeless> mkanat: hopefully Chex will have filed a bug
[01:44] <lifeless> mkanat: yes
[01:44] <lifeless> mkanat: a restart didnae halp
[01:44] <mkanat> Dang.
[01:44] <lifeless> which suggests incomplete handling of a bzr core exception, to me.
[01:45] <lifeless> something we should show rather than go boom on.
[01:45] <lifeless> so conceptually shallow
[01:45] <lifeless> mars: what was the branch again ^
[01:45] <poolie> lifeless, i wonder if we should say that the person setting things up is responsible for starting them, if that's needed
[01:46] <poolie> probably it's not needed in most cases
[01:46] <poolie> anyhow it's not complicated to do so
[01:46] <poolie> then just use addCleanup to shut them down, and fixtures that themselves create fixtures are responsible for getting them shut down
[01:49] <lifeless> poolie: I think the start/stop are paired, separate from instantiation, and the responsibility of the instantiator
[01:49] <lifeless> poolie: so convenience support for that would be nice.
[01:55] <lifeless> mars: bug 592262, if you want to chat in realtime, I'm here
[01:55] <lifeless> ba
[01:55] <lifeless> bah - mars sorry!
[01:55] <lifeless> mgz: ^
[01:55] <lifeless> too many m's
[01:56] <mgz> so, I don't see any risk in just doing:
[01:56] <mgz> -    except Exception:
[01:56] <mgz> +    except:
[01:56] <lifeless> mgz: KeyboardInterrupt and SystemExit
[01:56] <mgz> but I've not looked at py3k properly till today and it's still... suprising me
[01:56] <mgz> KeyboardInterrupt is being explicitly caught above anyway
[01:57] <lifeless> ah
[01:57] <spiv> And string exceptions ;)
[01:57] <mgz> if we worry about SystemExit/GeneratorThingy, can just add them up there too
[01:57] <lifeless> mgz: I think my main hesitation is that there's no good reason to care :)
[01:57] <mgz> (caught and re-raised)
[01:57] <lifeless> mgz: [that I know of]
[01:58] <mgz> well, people sometimes forget their classnames, and unittest Does The Right Thing
[01:58] <mgz> it's not a big issue, I just wrote a test for it and it made the run fall over
[01:59] <spiv> In addition to GeneratorExit, there's anything else that someone decides to base off BaseException rather than Exception in their own code.
[01:59] <mgz> well, there's bags of code in the stdlib that gets the exception heirachy wronger than this
[02:00] <mgz> catching the wrong stuff, letting to much through, etc etc
[02:00] <spiv> So, if the goal is "not catch string exceptions"
[02:00] <lifeless> mgz: heh. We don't need to lower ourselves to its level ;)
[02:00] <spiv> Then why not explicitly "except BaseException:" ?
[02:00] <mgz> current annoyance - how the hell am I meant to get a copy of stdout that won't blow up randomly for py3k
[02:00] <mgz> BaseException doesn't exist in 2.4
[02:01] <mgz> and no, the goal is catching string exceptions, in my opinion.
[02:01] <spiv> Or "except BaseException: raise" "except Exception:..."
[02:01] <lifeless> ok
[02:01] <lifeless> so what do I care about here?
[02:01] <lifeless> I care that:
[02:01] <mgz> attribte lookup code and other core stuff can swallow SystemExit and so on
[02:01] <lifeless>  - we do the right thing on as many pythons as possible.
[02:01] <mgz> nothing does is right
[02:02] <spiv> mgz: "try: BaseException; except NameError: BaseException = Exception".  Or even = () ;)
[02:02] <lifeless>  - where we can't do it right on both 2.N and 2.N+(M>0), and can do it right on either of them, I'd rather 2.N lose out.
[02:03] <lifeless>  - where we can't get it right no matter what, maintainable code in testtools should become a consideration
[02:03] <lifeless> string exceptions in particular I had discounted because python itself, in the 2 series, has made them illegal.
[02:03] <lifeless> but I have no intrinsic objection to supporting them.
[02:04] <lifeless> I *suspect* the rabbit hole is kindof deep.
[02:04] <mgz> doesn't seem all that bad to me.
[02:04] <mgz> not compared to trying to actually make sure KeyboardInterrupt is always propogated
[02:04] <lifeless> mgz: we do pretty good on KI at the moment I think
[02:05] <mgz> sure it's just the platform that's the problem :D
[02:05] <lifeless> mgz: so, the question spiv raised earlier is a good one. What about 'class MyBase(BaseException): pass'
[02:05] <mgz> `getattr(a, "b", None) is not None` only gets you so far
[02:05] <lifeless> mgz: indeed, thats buggy :)
[02:06] <lifeless> sentinel = object(); getattr(a, "b", sentinel) is not sentinel
[02:06] <mgz> ^if not isinstance(e, (Exception, str)): raise
[02:06] <lifeless> mgz: ok, so
[02:06] <mgz> where we get e from sys.exc_info for py3k source happiness
[02:06] <lifeless> except:
[02:06] <lifeless>  exc_info = sys.exc_info()
[02:06] <lifeless> etc
[02:07] <mgz> right. three line diff.
[02:07] <lifeless> mgz: ok, if you add a couple of tests for failure modes we've discussed and are avoiding here. Then +1
[02:07] <mgz> what could possibly go wrong. ;)
[02:07] <lifeless> mgz: ohhhh, we've seen a bit
[02:10] <mgz> argh, this is a nightmare... I think I have to manually clone this wrapper just to get a working stdout
[02:10]  * mgz curses people with unicode terminals and no imagination
[02:11] <lifeless> :<
[02:11] <lifeless> what should it do if it can't encode to your terminal - show the repr ?
[02:12] <mgz> well, this is in the context of running a testsuite
[02:13] <mgz> it has a failure on some test, that happens to involve some non-english text
[02:13] <mgz> py3k would currently throw a UnicodeError when trying to print the result
[02:14] <mgz> this seems the least helpful option to me
[02:14] <lifeless> \o/
[02:14] <mgz> unfortunately, it also seems to provide no way of actually *doing* anything with the multi-layered nightmare of wrappers, either
[02:14] <lifeless> but thats ok
[02:15] <lifeless> at least bytes are a different type now
[02:15] <lifeless> :P
[02:17] <mgz> okay...
[02:17] <mgz> return stream.__class__(stream.buffer, stream.encoding, "replace", stream.newlines, stream.line_buffering)
[02:18] <mgz> and I actually get complete output.
[02:18] <mgz> horrible hack, but I'll survive
[02:23] <lifeless> oh my
[02:23] <lifeless> mgz: I could send you a CD of Ubuntu, if you like.
[02:24] <mgz> I could run this on another box, but the code still needs to be able to print test results to a non-unicode target
[02:31] <lifeless> mgz: I was teasing :)
[02:33] <mgz> I would play along, but py3k is keeping me up past my bed time...
[02:34] <lifeless> mgz: http://pastebin.com/bPhtYmkg
[02:34] <lifeless> mgz: could you give that a very quick eyeball
[02:34] <lifeless> I've added a comment since you saw it last
[02:35] <mgz> ack, yes, that self._exc_info_to_string you've added the comment by will be an issue
[02:35] <lifeless> yeah
[02:35] <lifeless> I thought it would be :)
[02:35]  * lifeless upgrades it to XXX
[02:36] <lifeless> spm: I has updated rt
[02:36] <lifeless> spm: please advise if I can assist with the CAT stuff
[02:36] <spm> lifeless: yarp; just read same. ta.
[02:36] <spm> possibly - should be ok from here.
[02:36] <mgz> currently I'm doing .encode("ascii", "replace") in _StringException.__str__ so even people with fancy utf-8 terminals will see errors when everyone else does ;)
[02:36] <lifeless> mgz: evil!
[02:37] <lifeless> self.pop()
[02:37] <lifeless> looms, right
[02:37] <lifeless> I feel the need for wotw
[02:42] <mgz> okay, is my py3k just broken, or is something really stupid going on:
[02:42] <mgz> >>> open(os.devnull, "w", encoding="ascii").write("it's a repr %r" % "\u1234")
[02:42] <mgz> Traceback (most recent call last):
[02:42] <mgz>   File "<stdin>", line 1, in <module>
[02:42] <mgz> UnicodeEncodeError: 'ascii' codec can't encode character '\u1234' in position 13: ordinal not in range(128)
[02:42] <mkanat> mgz: That sounds right.
[02:42] <mkanat> mgz: ascii can't encode Unicode character 1234.
[02:43] <mgz> I see no reason that trying to write a repr to file should be attempting to encode the *escaped* string
[02:43] <mgz> I'm not writing \u1234, I'm writing \\u1234
[02:43] <mgz> as it were.
[02:43] <mkanat> mgz: Did you mean r"\u1234"?
[02:43] <lifeless> what does "%r" % "\u1234" do ?
[02:43] <mgz> that, I'd hope.
[02:44] <lifeless> mkanat: he's simulating the code path of a test error report
[02:44] <mkanat> mgz: I think %r of a string is the string.
[02:44] <mgz> then what's %s?
[02:44] <mkanat> mgz: Also a string.
[02:44] <lifeless> >>> "%r" % "\u1234"
[02:44] <lifeless> "'ሴ'"
[02:44] <lifeless> >>> type("%r" % "\u1234")
[02:44] <lifeless> <class 'str'>
[02:44] <mgz> okay, so these days, repr is useless.
[02:44] <mkanat> mgz: But %r takes any data type.
[02:44] <lifeless> >>> len("%r" % "\u1234")
[02:44] <lifeless> 3
[02:44] <lifeless> >>> len("\u1234")
[02:44] <lifeless> 1
[02:45] <lifeless> mkanat: its not the string itself
[02:45] <mkanat> lifeless: Sure, it's the string in quotes. :-)
[02:45] <mgz> it just... adds quotes
[02:45] <lifeless> it is, helpfully, '-thestring-'
[02:45] <lifeless> mgz: yes, :)
[02:45] <mgz> so, I need encode ascii and backslashreplace instead I guess
[02:45] <lifeless> so repr is unicode these days
[02:46] <mkanat> mgz: Is there not a way to make encode="ascii" be more lax?
[02:46] <lifeless> mkanat: terrible for debugging
[02:46] <mgz> not and actually have the test still be meaningful
[02:46]  * mkanat nods.
[02:46] <lifeless> mkanat: we want a codec that shows how to get back a unicode string from an ascii editor
[02:47] <mkanat> lifeless: Ah.
[02:47] <lifeless> mkanat: which repr in python 2.1 was
[02:47] <lifeless> mgz: unless I've got something wrong ?
[02:47] <lifeless> s/1/x/
[02:47] <mgz> nope, that's it.
[02:48] <mgz> I'm testing string roundtripping in testtools, this means I need to be knowing exactly where I am at all stages... which py3k source compat is confusing somewhat
[02:49] <mgz> get this string into this file in this encoding escaped thusly, test than running said file gets sensible unicode output
[06:10] <thumper> how do you 'close' a branch?
[06:14] <spiv> chmod -R a-r?  Or is there something more you want than "no-one has permission to change this"?
[06:16] <rockstar> spiv, I think thumper wants something like open().close(), but for branches.
[06:16] <spiv> Oh, ok.
[06:17] <spiv> There's no explicit close in the API.  The closest we have is "release all references to that object".
[06:18] <spiv> What's this for?  If it's to do with tests and connections vila is working on something in that area.
[06:18] <rockstar> thumper, ^^
[06:25] <lifeless> indeed, Branches have the same lifetime as any python object.
[06:25] <lifeless> 'del' should do
[06:25] <lifeless> a 'closed Branch' does not make any sense, it would be an invalid state for the object to be in.
[06:51] <lifeless> jam: I'm going to feel all guilty now.
[06:52] <jam> lifeless: don't, I'm capped on everything but goo
[06:52] <jam> it's actually a bit boring
[06:52] <lifeless> jam: yeah, I saw when you zerged me :)
[06:52] <jam> please steal some stuff so i feel worthwhile again :)
[06:52] <lifeless> ok, well the weekend is approach
[06:52] <lifeless> I'll see what I can do
[07:08] <BlindWolf8> Hello. Anyone here?
[07:09] <spiv> Yes.
[07:10] <BlindWolf8> Hi spiv.
[07:10] <BlindWolf8> I have a question about Bazaar setup. Are you able to help me?
[07:11] <spiv> Maybe :)
[07:11] <spiv> Ask the question and we'll find out!
[07:11] <BlindWolf8> Haha... I have Bazaar v2.2b3 installed on my server
[07:11] <BlindWolf8> right from source
[07:11] <BlindWolf8> I am on a Windows box and I installed bzr on a Linux box
[07:12] <BlindWolf8> I downloaded Bazaar on my Widnows box and went to create a new shared repo remotely on the Linux box through Bazaar explorer
[07:12] <BlindWolf8> I get Permission errors (error 13)
[07:13] <BlindWolf8> The user that I logged in as should have permission for everything. I am not sure what it's trying to do.
[07:14] <spiv> Hmm.
[07:14] <spiv> Creating a shared repo just tries to create a few directories and files, and does some renames of files along the way.
[07:15] <BlindWolf8> Could it be the group the user is in?
[07:15] <spiv> There should be a traceback in bzr's log file, if you run "bzr --version" it should tell you where to find it.  If you can pastebin that it might provide a clue.
[07:15] <BlindWolf8> OK, hold on one moment...
[07:16] <BlindWolf8> there's a .bzr.log will that help?
[07:17] <spiv> Yes, that's the file.
[07:17] <lifeless> also look in the .bzr.log on the server :)
[07:17] <lifeless> depending on versions and so forth, some of the code runs on the server side
[07:17] <spiv> How are you accessing the shared repo remotely?  Via a bzr+ssh URL, or a SMB share, or..?
[07:18] <BlindWolf8> bzr+ssh
[07:18] <BlindWolf8> using a public/private key, which works
[07:18] <BlindWolf8> yeah, I meant the .bzr log on the server
[07:18] <BlindWolf8> so, whihc log do you want?
[07:20] <BlindWolf8> The exact error I get in Bazaar Explorer is: bzr: ERROR: Permission denied: ".": : [Errno 13] Permission denied: '/.bzr'
[07:22] <BlindWolf8> Hello?
[07:27] <BlindWolf8> Hi Adys
[07:30] <BlindWolf8> Hello all.
[07:31] <spiv> BlindWolf8: the bzr log from the client to start with, I think, but the remote one might be interesting too
[07:32] <spiv> BlindWolf8: that error does sound likely to be a simple permissions problem, though
[07:33] <vila> hi all
[07:33] <spm> hey vila
[07:34] <vila> thumper, spiv: In a forthcoming submission I implemented a transport.disconnect() method that close the socket for transports that have one
[07:35] <vila> thumper, spiv: That means that the transport objects as still usable since they will reconnect on demand while also providing a way to collect the unused sockets when needed
[07:35] <spiv> vila: and the hooks we discussed?
[07:35] <vila> spm, spiv: Could we configure the news_merge plugin on the pqm host ? I got two submissions failing yesterday because of that
[07:36] <BlindWolf8> OK, I'm back.
[07:36] <vila> spiv: I've still to implement them and they still sound like the best idea so I will :)
[07:36] <spm> vila: I guess, not sure what you need/where tho?
[07:37] <BlindWolf8> spiv: Where are the logs on the client side?
[07:37] <spiv> I think lifeless may have filed a RT about enabling news_merge on the PQM host, not sure.
[07:37] <vila> spm: Either in branch.conf or locations.conf in the appropriate section, we need: news_merge_files = NEWS
[07:37] <spiv> BlindWolf8: open a command prompt and run "bzr --version" and it should tell you.
[07:37] <BlindWolf8> spiv: got it!
[07:39] <BlindWolf8> spiv: Here's the client log: http://pastebin.com/CBmzHwZd
[07:40] <spm> spiv: vila: if he has, it's not got 'news_merge' anywhere in it.
[07:40] <vila> spm: 'he' == lifeless ?
[07:40] <spm> yup
[07:41] <spiv> spm: ok, good to know.  Thanks for looking :)
[07:41] <spm> tho, specifically, anyone; the search was pretty open. :-)
[07:41] <vila> spm: It could be that he asked for a bzr upgrade so the plugin was available but didn't mention the .conf stuff
[07:41] <spm> we have been faffing around with pqm upgrades the past few days; so possibly in there somehow
[07:42] <spiv> Yes, I think the only pre-req is that PQM is using bzr 2.1 or newer to do the merges.
[07:42] <spiv> If that's done, then probably turning on news_merge is a good idea.
[07:42] <BlindWolf8> spiv: If this helps: client: 2.1.1, server: 2.2b3
[07:43] <spm> spiv: Bazaar (bzr) 2.0.4, so no. :-)
[07:43] <BlindWolf8> spiv: huh?
[07:44] <spiv> BlindWolf8: was talking to spm, sorry!
[07:44] <spm> spiv: hrm. interesting. might actually be running 1.17. we're not using the system bzr for bzr itself; have a local copy
[07:45]  * spm has visions of shaving yaks in the near future
[07:45] <BlindWolf8> spiv: haha, no problem
[07:45] <lifeless> woo
[07:45] <lifeless> Ran 2 tests in 0.578s
[07:45] <lifeless> OK
[07:45] <lifeless> bzrlib.plugins.loom.tests.test_branch.TestLoom.test_sprout_remote_loom is leaking threads among 1 leaking tests.
[07:45] <BlindWolf8> spiv: Thanks again for any help you can provide...I've come this far...so close!
[07:46] <vila> lifeless: using an http or sftp server ?
[07:46] <lifeless> vila: bzr+ssh
[07:46] <lifeless> vila: I must be tired, I didn't answer 'False' :)
[07:46] <spiv> BlindWolf8: so, this seems likely to be a fairly normal permissions problem: that error seems likely to be due to "mkdir .bzr" in failing
[07:47] <vila> lifeless: yeah, so one leaked thread for each connection, we need one of the hook spiv mentioned above to catch them
[07:47] <BlindWolf8> spiv: Odd. I can ssh in and make the dir myself no problem.
[07:47] <vila> lifeless:  :)
[07:47] <spiv> BlindWolf8: hmm, odd indeed!
[07:47] <BlindWolf8> spiv: my exact commend, for reference is bzr+ssh://user@site.com:port
[07:48] <vila> lifeless: i.e. the smart server starts a daemonic thread for each client connection, a hook there will allow the tests to shut them down
[07:48] <spiv> For some value of "exact", I'm sure ;)
[07:48] <BlindWolf8> spiv: LOL
[07:48] <spiv> If there is a traceback in the server's .bzr.log that would be interesting too.
[07:48] <BlindWolf8> spiv: there's not. The only thing I notice is that there's two return code...btoh are 0s
[07:49] <BlindWolf8> spiv: I can pastebin it tho if needed for ref.
[07:49] <spiv> Did the server manage to create any directories?
[07:49] <BlindWolf8> spiv: no
[07:49] <spiv> No I don't need to see the server log then, that's ok, that's what I'd expect.
[07:50] <BlindWolf8> spiv: oh wait, whoa...
[07:50] <lifeless> vila: oh, I wasn't talking about the leak
[07:50] <lifeless> vila: I was talking about the remote loom branch working
[07:50] <spiv> lifeless: hooray for loom working!
[07:50] <BlindWolf8> spiv: looking at the server log, looks like there was a traceback at one point
[07:50] <vila> lifeless: hurrah !!!
[07:50] <spiv> BlindWolf8: to do with permission denied?
[07:50] <lifeless> spiv: please comment on http://pastebin.com/e4fs3zey
[07:50] <vila> lifeless: I had to copy the last-loom file manually this week
[07:51] <lifeless> vila: the shutdown-of-the-server thing - no hook needed, surely. We already call tearDown on the server, that can DTRT, can't it ?
[07:52] <vila> lifeless: Well, we *can* collect the threads/sockets for all cases but we really need it for the tests
[07:52] <BlindWolf8> spiv: here's the log from the server: http://pastebin.com/UPez6RS7
[07:52] <spiv> lifeless: Hmm, _ensure_real for sprout?  Isn't that going to regress some HPSS call count ratchets?
[07:52] <lifeless> spiv: thats on Format
[07:53] <spiv> lifeless: oh right
[07:53] <lifeless> spiv: :!./bzr selftest --no-plugins branch.*acceptance --strict
[07:53] <lifeless> bzr selftest: /home/robertc/source/baz/pending/working/bzr
[07:53] <lifeless>    /home/robertc/source/baz/pending/working/bzrlib
[07:53] <lifeless>    bzr-2.2b3 python-2.6.5 Linux-2.6.32-22-generic-x86_64-with-Ubuntu-10.04-lucid
[07:53] <lifeless>                                                                                                                                                                                                                                               
[07:53] <lifeless> ----------------------------------------------------------------------
[07:53] <lifeless> Ran 3 tests in 6.135s
[07:54] <spiv> BlindWolf8: yeah, that's nothing interesting (at some point you ran "bzr whoami" and it logged some stuff about the whoami info not being set yet)
[07:54] <BlindWolf8> spiv: before that though
[07:54] <lifeless> vila: Clean shutdown matters for real servers too - we need to interrupt long running threads somewhat cleanly or we can cause bad http results and so forth (think 1.0 envelopes)
[07:54] <BlindWolf8> spiv: I did notice a traceback
[07:54] <lifeless> vila: I still don't understand why a hook is needed
[07:54] <lifeless> vila: and I'm really concerned that its just confusing overhead we don't need
[07:55] <spiv> BlindWolf8: I'm not sure what you're talking about?
[07:56] <BlindWolf8> lemme see...
[07:56] <lifeless> vila: why won't 'tearDown the server kills its threads' do the right thing ?
[07:56] <lifeless> vila: -and- why does a hook do better ?
[07:56] <BlindWolf8> spiv: ah eyah, misread...it was the whoami
[07:57] <spiv> BlindWolf8: I'd be interested to see if you can make that directory using a sftp://... URL instead of bzr+ssh://...
[07:57] <BlindWolf8> spiv: so, what would you recommend?
[07:57] <lifeless> spiv: any other comment than that ?
[07:57] <vila> lifeless: that's what I've currently implemented for SmartTCPServer_for_testing
[07:57] <BlindWolf8> spiv: Would it have to do with my version being beta on the server?
[07:57] <vila> lifeless: spiv mentioned the hook as being useful in the general case too
[07:57] <spiv> lifeless: it's not just about threads, it's about FDs
[07:57] <lifeless> vila: qualify that please :) - what is the that that you speak of
[07:57] <BlindWolf8> spiv: OK, I'll try it out
[07:57] <vila> lifeless: collecting the threads
[07:58] <spiv> lifeless: you can prod the test server to shutdown its threads and close its fds
[07:58] <BlindWolf8> spiv: SFTP Test: FAIL
[07:58] <lifeless> spiv: right; and we can use the paste glue to raise exceptions in the threads to close their fds immediately etc
[07:59] <spiv> lifeless: but what about the client side?  The transport objects won't necessarily notice their connection has had the other side close and thus close their fds too.
[07:59] <vila> lifeless: I haven't implemented killing threads yet as I'm unclear about adding a ctypes dependency here, and even more if it's needed outside the tests
[07:59] <vila> spiv: client side is a different problem *anyway*
[07:59] <spiv> vila: ?  I thought we were discussing transport.disconnect?
[08:00] <vila> spiv: no, we're talking about connections received by the smart server
[08:00] <spiv> BlindWolf8: but you can ssh to that server as the same user and make that directory (or even "bzr init-repo")?
[08:00] <lifeless> spiv: client side sockets only matter for zope.testing AFAICT
[08:00] <lifeless> spiv: and for them, 'del my_branch' should be entirely sufficient.
[08:01] <lifeless> spiv: in fact, the test attribute cleanup we already do should remove all references; it may be we have cycles to take care of.
[08:01] <BlindWolf8> spiv: I can ssh in and make the dir and run "bzr init". Have not tried "bzr init-repo"
[08:01] <BlindWolf8> spic the directory that I'm using has nothing in it. DOes that matter?
[08:01] <lifeless> spiv: While I dislike transport.disconnect intensely, I'm resigned to it coming in, but I don't see that thats a hook situation - and a dict of things such a hook would call seems terrible.
[08:02] <BlindWolf8> spiv: the directory that I'm using has nothing in it. Does that matter?
[08:02] <spiv> BlindWolf8: no, that doesn't matter
[08:03] <spiv> BlindWolf8: I'm not sure what the problem is :(
[08:03] <lifeless> BlindWolf8: whats the URL you're using ?
[08:03] <lifeless> BlindWolf8: if it is really ' bzr+ssh://user@site.com:port'
[08:04] <lifeless> BlindWolf8: then you're trying to create a repo in the root of the server
[08:04] <spiv> BlindWolf8: there should be no difference in access between "ssh user@host mkdir foo" and "ssh user@host" followed by typing "mkdir foo" at the prompt
[08:04] <lifeless> BlindWolf8: which only 'root' can do
[08:04] <BlindWolf8> lifeless: the repo isn't public
[08:04] <lifeless> BlindWolf8: sure, I get that you would want to obfuscate the url.
[08:04] <lifeless> BlindWolf8: I'm saying that if you don't include a *path* after the port, its making it in /
[08:04] <lifeless> BlindWolf8: which, unless you're root, really isn't going to work.
[08:05] <spiv> lifeless has a good point, bzr+ssh (and sftp) URLs in bzr are relative to the root of the filesystem, not the home directory.
[08:05] <BlindWolf8> lifeless: hmmmm...
[08:05] <lifeless> a much more usual path would be e.g. /srv/myrepo, e.g. bzr+ssh://user@site.com:port/srv/myrepo
[08:05] <spiv> lifeless: well spotted!
[08:05] <lifeless> and you'd mkdir /srv/myrepo on the server as root first, and chown it to your group/user as appropriate.
[08:05] <lifeless> spiv: :)
[08:06] <BlindWolf8> lifeless: that's really odd...I would think that bzr would default to the user's home dir
[08:06] <lifeless> spiv: really, I just want to get you to tell me about my patch in more detail, can't have you spinning on helping a user ;)
[08:06] <BlindWolf8> lifeless: as I made a special user with a specific home directory for security reasons
[08:06] <lifeless> BlindWolf8: we use /~/ to mean 'the users home directory'
[08:06] <spiv> BlindWolf8: but then how would you give a URL to somewhere not in the home directory?
[08:06] <lifeless> BlindWolf8: as long as you have a new bzr on both ends that will work fine
[08:07] <BlindWolf8> lifeless: sorry for bugging you guys :P
[08:07] <lifeless> BlindWolf8: hey, no problem at all.
[08:07] <spiv> lifeless: he has 2.2b3 on the server, so /~/ should be fine
[08:07] <lifeless> BlindWolf8: it was confusing you, and we're here to help :)
[08:07] <BlindWolf8> lifeless: lemme try it out guys
[08:07] <spiv> BlindWolf8: Thanks for your patience!
[08:08] <spiv> We should make this less confusing somehow, although I'm not immediately sure how.
[08:08] <BlindWolf8> lifeless: I guess that's what I get for assuming that bzr would see the user taht logged in and go "Oh, OK, I'll make it in their home dir"
[08:08] <spiv> Some sort of verbose logging flag for the server, I guess.
[08:08] <lifeless> BlindWolf8: indeed, bzr is more like wget than scp
[08:09] <spiv> BlindWolf8: you can configure the SSH server to do that if you want in the authorized_keys file
[08:09] <spiv> BlindWolf8: http://doc.bazaar.canonical.com/development/en/admin-guide/security.html#using-ssh
[08:10] <BlindWolf8> Thanks guys
[08:10] <BlindWolf8> OK, here's what happened...
[08:10] <BlindWolf8> Did the command, then the it said it created it. I was like :) but I clicked Close.
[08:10] <spiv> lifeless: so regarding your patch
[08:11] <lifeless> I want a 'deprecated_method_blows_up' switch
[08:11] <BlindWolf8> error'd out complaining about it not being a repo, and I was like :(, but I did Open URL and it looks like it's all good
[08:11] <spiv> lifeless: python -Werror, or something
[08:12] <lifeless> spiv: switched the readlock/deprecated lines, works better
[08:12] <BlindWolf8> Thanks again guys. I think I got it from here.
[08:13] <BlindWolf8> You guys won't be forgotten
[08:13] <lifeless> great. Do ask again if you have further issues ;)
[08:13] <spiv> lifeless: the code change looks ok after a quick look.  Moving this stuff to format does still feel a bit weird but the result doesn't seem worse structurally.
[08:13] <BlindWolf8> You two will get credit on our game :P
[08:13] <lifeless> \o/
[08:13] <BlindWolf8> hahah
[08:13] <BlindWolf8> l8r guys
[08:13] <spiv> lifeless: try/finally blocks make me a bit sad, but I realise bzrlib.cleanup isn't as convenient :/
[08:14] <spiv> lifeless: I haven't read the docs yet
[08:14] <spiv> lifeless: and that's my comments so far!
[08:15] <lifeless> so, I haven't done the 'migrate callers across' yet
[08:15] <lifeless> it may look worse after that
[08:15] <lifeless> the try:finally stuff - I was going to ask about the best way to do it now
[08:15] <lifeless> however, I realised I only have one write lock in each code path, and it was previously @decorated anyhow
[08:16] <lifeless> spiv: what might be nice is an @ decorator to cleanup
[08:16] <lifeless> @cleanup('source', 'read_lock')
[08:16] <spiv> Hmm, that might be a touch evil.
[08:16] <lifeless> spiv: meaning 'call source.read_lock and add the result's unlock to a cleanup object just for this'
[08:16] <lifeless> spiv: I wants sugah
[08:17] <spiv> You'd need to burrow uncomfortably deeply in the code object to find which argument is called source
[08:17] <lifeless> spiv: SUGAH
[08:17] <spiv> If you required that the relevant arg is a kwarg it wouldn't be so bad.
[08:18] <lifeless> yeah
[08:18] <lifeless> is it 3.2 that has kwawrgonly stuf?
[08:18] <spiv> Sugar is nice, but sugar that has to do complex things at import time and possibly rely on details that aren't guaranteed outside of CPython...
[08:19] <spiv> 3.something, at least.
[08:19] <spiv> The exact value of ".something" is a bit academic as far as bzr is concerned :)
[08:20] <lifeless> anyhow
[08:20] <lifeless> I'll polish this a bit
[08:20] <lifeless> but I like the following bits:
[08:20] <lifeless>  - no VFS for bzr branches
[08:21] <lifeless>  - no runtime introspection to decide which are bzr and which aren't
[08:21] <lifeless>  - heads in a direction where we could do a multimethod without the somewhat ugly Remote* magic we had to do for similar stuff in Repository.
[08:22] <spiv> It would be less pretty, but @cleanup(0, 'read_lock') [where 0 is which positional argument to cleanup] wouldn't be unreasonably ugly to implement.
[08:22] <spiv> Yeah.
[08:23] <spiv> The part where it allows looms to DTRT with minimal fuss is a good sign that this is good.
[08:23] <lifeless> this is the loom patch so far
[08:23] <lifeless> http://pastebin.com/JnspcZMf
[08:23] <spiv> lifeless: so, with the PQM issues
[08:23] <lifeless> should be the entire thing
[08:23] <lifeless> the key bit is
[08:24] <lifeless>             # If we're copying from a proxied Loom - a RemoteBranch, unwrap it.
[08:24] <lifeless>             if not isinstance(source, LoomSupport):
[08:24] <lifeless>                 source._ensure_real()
[08:24] <lifeless>                 source = source._real_branch
[08:24] <lifeless> which is a little not-right
[08:24] <lifeless> alternatively we could make RemoteBranch more pass-through
[08:24] <spiv> lifeless: I have a submission that is failing without any useful hints in the reply from PQM.  If I turn off subunit in the makefile for that submission will that help me?
[08:24] <lifeless> spiv: yes
[08:24] <lifeless> spiv: [probably, maybe not]
[08:25] <spiv> Ok, good.
[08:26] <spiv> Yeah, that's a bit of a hack, but at least it'll make things work now, and we can make it elegant later.
[08:26] <lifeless> its not as gross as it could have been :)
[08:27] <spiv> :)
[08:41] <BlindWolf8> Hello?
[08:42] <parthm> BlindWolf8: hi
[08:43] <spiv> Hello again
[08:43] <spiv> parthm: oh hey
[08:43] <parthm> spiv: hi :)
[08:43] <vila> parthm: \o_
[08:43] <spiv> parthm: I wanted to thank you for answering that active directory question on Launchpad
[08:43] <spiv> parthm: so... thanks! :)
[08:43] <parthm> vila: _o/
[08:44] <parthm> spiv: np. i don't know much about active directory ... but some errors were general enough :)
[08:44] <vila> parthm: I second spiv thanks :)
[08:44] <BlindWolf8> spic: I just have one more quick question about bzr_ssh_path_limiter: Can I just pop that script anywhere?
[08:44] <BlindWolf8> spiv: I just have one more quick question about bzr_ssh_path_limiter: Can I just pop that script anywhere?
[08:45] <spiv> BlindWolf8: yeah, pretty much, although if it's not on PATH you'll have to give the full path to it in authorized_keys I think
[08:46] <BlindWolf8> spiv: Right. Anything else I should know about the files that got unzipped from the original bzr source?
[08:46] <BlindWolf8> spiv: I'm assuming they're safe to delete since I installed bzr and bzrtools?
[08:47] <spiv> Sure, it's safe to delete the stuff you unzipped.  If you are interested in the contents of the doc/ or contrib/ or whatever directories again you can always unzip again.
[08:47] <BlindWolf8> spiv: OK, great!
[08:48] <BlindWolf8> spiv: You guys have made my night!
[08:48] <spiv> BlindWolf8: :)
[08:48] <parthm> i see a bunch of gc warning for '--no-plugins selftest test_lock' on trunk. is this expected? http://pastebin.com/Qj8tJ6kg
[08:51] <BlindWolf8> spiv: Bye once again spiv. Everything seems to be working perfectly now! :)
[08:51] <spiv> BlindWolf8: great!
[08:51] <spiv> parthm: not sure if it's expected precisely, but it certainly would be good to fix
[08:52] <parthm> spiv: ok. i will file a report for now so its not lost.
[08:52] <spiv> parthm: looks like a one-line fix
[08:53] <parthm> spiv: oh. where should i look?
[08:53] <parthm> spiv: ah. line 55 ... let me check.
[08:55] <spiv> parthm: yeah, it's a one-liner, I'll just submit that to PQM right now, it's trivial (and IIRC my fault!)
[08:56] <parthm> spiv: ok. sure. just for my info. what is the fix?
[08:57] <spiv> parthm: self.addCleanup(branch.unlock) immediately after branch.lock_read()
[08:57] <spiv> The warning is about an object that was locked being garbage collected, i.e. something forgot to unlock it
[08:58] <parthm> spiv: ahh. ok. thanks.
[08:58] <spiv> In this case, the "something" is the test itself which does the lock_read but never unlocks.
[08:59] <parthm> spiv: cool.
[09:02] <lifeless> spiv: parthm: a nice way is
[09:02] <lifeless> self.addCleanup(branch.lock_read().unlock)
[09:03] <lifeless> that idiom makes missing unlocks more obvious
[09:03] <spiv> lifeless: Hmm, I actually don't like that so much
[09:03] <spiv> It emphasises the cleanup rather than the locking.
[09:04] <spiv> Which seems backwards to me
[09:04] <lifeless> spiv: branch.lock_read(register_with=self.addCleanup) ?
[09:04] <spiv> I'd almost rather have self.lock_read(branch) helpers.
[09:05] <lifeless> spiv: helpers like that would be ok too; that said I don't think it particularly emphasises anything other than 'if you lock you should unlock'
[09:05] <spiv> Hmm, it's wordy and I'm not sure if pushing that into the lock_read contract is wise, but otherwise yes I'd prefer that.
[09:06] <lifeless> spiv: I found bugs when I introduced the idiom to builtins.py
[09:06] <lifeless> spiv: (in plugins)
[09:07] <spiv> I definitely agree with the overall direction of pushing it to be a single step
[09:07] <lifeless> spiv: I think its worth having an idiom like this - even if you spell it differently - to make ... right
[09:07] <lifeless> spiv: if you feel strongly that it should be different, 2.2 would be the time to change it :)
[09:07] <spiv> True!
[09:07] <spiv> But not 6pm on a Friday :)
[09:07] <lifeless> indeed ;)
[09:08] <spiv> I'll make a note to look at this on Monday
[09:08] <lifeless> personally
[09:08] <spiv> Would you like me to mail the list about it, or just propose a patch to add lock_read/lock_write helpers to TestCase and Command?
[09:08] <lifeless> I think the loose coupling of returning a cleanupable is better than locks knowing they need to do something with a cleanup
[09:09] <lifeless> spiv: I'm entirely happy with what we have; I won't block other changes, but I don't see them as being better.
[09:09] <lifeless> Just, at best, different.
[09:09] <spiv> I'm not totally sold on the tastefulness of such a patch, which is why I hadn't yet done so, but I'm not finding the new idiom very loveable either.
[09:09] <lifeless> spiv: ok
[09:10] <lifeless> spiv: then it sounds like brainstorming to find another way to spell 'these things are connected' is appropriate.
[09:10] <spiv> *nod*
[09:11] <spiv> My current thinking is: I think the returning a callable is a sound design, but lock_read and lock_write in TestCase and Command are overwhelmingly our common case so let's make that stupidly easy to do right.
[09:13] <spiv> Anyway, thanks for the quick teddy bear.  I'll followup on Monday.
[09:13] <lifeless> sounds good
[09:33] <mobby> Hi, I've just tried to add the bazaar beta PPA repository but I can't seem to access the signing key. I've tried through the terminal and through the web browser. Any ideas?
[09:33] <mobby> Clicking the link on the launchpad site doesn't load and the terminal times out after a while
[09:34] <mobby> I've tried clicking on the links for the stable and the nightlies as well and they do the same thing
[09:36] <parthm> a 300sec timeout for local lock contention ("Will continue to try...") seems quite long. Does this need to be high? Maybe this should be reduced?
[09:38] <parthm> mobby: seems to work for me. this is the url i got http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0xD702BF6B8C6C1EFD
[09:39] <mobby> hmm strange, I'm in work so it might be our proxy settings. I'll try something else.
[09:47] <mobby> yeah it was our proxy. Apologies, should have tried that first. Thanks for the help.
[12:02] <cbz> what does 'conflicting tags' mean?
[12:12] <Mez> Can I force bzr to pick up the "whoami" info from an environment variable?
[12:12] <jelmer> Mez: hey
[12:12] <jelmer> Mez: I think it honors $EMAIL
[12:12] <Mez> jelmer: hey :)
[12:13] <Mez> As these feckers here generally all log in as the same user, I want to try and set the whoami on their ssh key
[12:13] <jelmer> :-)
[12:19] <jpds> #export BZR_EMAIL="$NAME <$EMAIL>"       # Override email for Bazaar.
[12:37] <Mez> jp~.
[12:38] <Mez> jpds: except - If you've set it in bzr.conf - it doesn't override - and also - "export" would make it the same for anyone who logged in - surelt... so X logs in and then Y logs in - X's commits show as coming from Y
[12:38] <Mez> so I've set it based on the SSH key used to login
[12:38] <jpds> Mez: Yep, that's what I have in my shell conf.
[12:39] <Mez> jp~.environment="EMAIL=Martin Meredith <martin.meredith@mobilefun.co.uk>" ssh-rsa AAAAB3NzaC1yc2 <-- etc etc
[12:39] <Mez> o_o
[12:39] <Mez> environment="EMAIL=Martin Meredith <martin.meredith@mobilefun.co.uk>" ssh-rsa AAAAB3NzaC1yc2 <-- etc etc
[12:39] <Mez> in authorized_keys
[13:48] <ciss_> hi
[13:58] <n3l> Quick question... just install bzr on mac os x.  Where is the gui app installed to?  Not found in applications.
[14:00] <n3l> Nevermind... bzr explorer : this isn't noted in bzr -h : https://answers.launchpad.net/bzr/+question/99420
[14:10] <ciss_> what is your preferred strategy to set up ignored files: do you explicity exlcude files and directories, or do you exclude everything and then explicitely add files?
[14:15] <parthm> ciss_: you can add patterns for files to be ignored to .bzrignore (see 'bzr help ignore')
[14:17] <ciss_> parthm, i'm aware of that. i was just curious if you prefer white-listing or black-listing files
[14:17] <ciss_> it's a workflow related question
[14:20] <parthm> ciss_: i tend to add files i need to ignore at the pop up as unknown in 'bzr st'. so black-list.
[17:10] <krisives-gearbox> Does anyone know how nested branches in BZR 2 are handled?
[17:12] <jelmer> krisives-gearbox: there is no support in the core for nested branches
[17:12] <jelmer> krisives-gearbox: there are some plugins that provide some degree of support
[17:12] <krisives-gearbox> jelmer: That's what I see on the documentation, but I don't know what BZR will do when it encounters nested .bzr directories
[17:12] <krisives-gearbox> it appears to not touch to sub branch
[17:13] <jelmer> krisives-gearbox: afaik it will ignore them, not sure what happens if you try to 'bzr add' a nested branch
[17:13] <krisives-gearbox> I tried bzr add from inside the nested branch and out and I can't seem to get files in the sub directory/branch to get added to the outer branch
[17:14] <krisives-gearbox> I'm not trying to do "true nested trees", I don't care if things propigate, I just want it to version those files
[17:14] <jelmer> I don't think there is a way to version those files in the outer rather than the inner branch
[17:14] <jelmer> not unless you move the .bzr directory of the inner branch out of the way somehow
[17:15] <krisives-gearbox> Yeah, which isn't worth getting into lol
[17:15] <krisives-gearbox> Have you ever used Stacked Branches?
[17:17] <jelmer> krisives-gearbox: yep
[17:18] <krisives-gearbox> I'm using Bazaar to version web software for a company that has created 3 versions of software that share many common similarities
[17:19] <krisives-gearbox> A and B are the same, so B can be a branch of A because their changes can be shared easily
[17:20] <krisives-gearbox> C is the problem, because we want to be able to make changes to C and push them to A (which will ultimately go to B)
[17:20] <jelmer> krisives-gearbox: stacked branches are just a storage optimization, they won't help you in this regard
[17:24] <krisives-gearbox> I see, have you used ConfigManager?
[17:24] <krisives-gearbox> I basically need to make a frankenstein branch
[17:24] <krisives-gearbox> Take this, that, this, etc. and throw it all together into a new one
[17:26] <jelmer> no, I don't have experience with config-manager
[18:43] <ericmoritz\0> I mean
[19:37] <krisives-gearbox> Does anyone know how I can specify a FTP that has @ in it's username?
[19:37] <krisives-gearbox> Like foo@bar on baz.com
[19:38] <krisives-gearbox> (bar and baz are the same though)
[19:38] <krisives-gearbox> foo@baz.com doesnt work because foo isn't foo@bar
[19:38] <fullermd> URL-encode it.
[19:38] <krisives-gearbox> I'll give that a shot
[19:40] <krisives-gearbox> fullermd: Thx, where do I send the remaining amount on my gift card ?
[19:40] <krisives-gearbox> :)
[19:40] <fullermd> Sorry, I only accept Krugerrand and first-born.
[19:41] <krisives-gearbox> Damn, and I skipped right to second-born, so I can't compensate you there
[19:41] <fullermd> Well, maybe you can fill in the first-born later.  I'll waive interest charges for a year.
[19:41] <krisives-gearbox> Well, I do have a few spare dollars on the gift card, you're welcome to it
[19:41] <krisives-gearbox> BZR folks need more love
[19:42] <krisives-gearbox> I'm willing to fund git away from usage
[19:42] <krisives-gearbox> Just so I don't have to remember SHA1 hashes
[19:44] <krisives-gearbox> either way, thanks for the help :)
[19:44] <fullermd> np   :)
[19:45] <krisives-gearbox> are you a bzr dev fullermd?
[19:45] <fullermd> Oh, no.  I just sit around and harass them.
[19:46] <krisives-gearbox> great minds think alike
[19:47] <krisives-gearbox> I made a script to doctor up merging .moved directories to contain the old unversioned contents with the new versioned contents overriding it, I wonder what chance I have of getting that included as a --cleanup-moved-dirs ?
[19:47] <krisives-gearbox> and if I did, how long until that version could trickle down to my users
[19:48] <ciss_> hi, i could use a little help on an ignore rule: i have a folder structure "./folderA/folderB/folderC/fileA". i added an ignore rule "folderA/folderB" expecting everything below to be ignored as well. still bazaar wants to add fileA
[19:50] <ciss_> do i really have to use "folderA/folderB" and "folderA/folderB/**/*" each time i want a folder and its contents to be ignored?
[19:51] <fullermd> Is folderC versioned?
[19:52] <ciss_> oh. yes, it is.
[19:52]  * fullermd nods.
[19:52] <fullermd> That'll break the ignore chain then.
[20:00] <ciss_> thanks a lot, knowing this should end all my troubles with .bzrignore :)
[20:03] <ciss_> is it possible to commit only removed files, but keep modified ones for a later commit?
[20:03] <TresEquis> ciss_: you can name the specific files as arguments to 'bzr commit'
[20:04] <TresEquis> e.g. '$ bzr commit -m "Should have ignored." folderA/folderB/folderC/fileA'
[20:05] <ciss_> sorry to ask: (how) can i use a text file as source for the file listing? it's a rather long list.
[20:06] <fullermd> No way with bzr itself.  You could 'bzr ci `cat foo`' or 'cat foo | xargs bzr ci' or the like, assuming it'll fit on the command line and not get in trouble with special chars.
[20:06] <fullermd> Or you could go the other way around, and shelve the other changes, commit, and unshelve.  That might be easier if the 'other' changes are a small list.
[20:06] <fullermd> ci also has an --exclude you could use to name the things not to commit.
[20:09] <ciss_> thanks
[20:58] <hazmat> is there anything like a more permanent shelf
[20:59] <hazmat> like i can unshelve some changes, but still keep the patch/content shelved
[21:03] <radoe> hazmat: bzr unshelve --keep?
[21:04] <hazmat> radoe, perfect, thanks
[22:52] <maxb> bzr-svn is so amazing, but it's somewhat crippled when your project is one of many in a repository with half a million revisions :-(
[22:59] <jelmer> maxb: have you tried disabling the cache?
[23:09] <maxb> jelmer: It improved matters considerably for read only operations
[23:10] <maxb> However, when I tried to push back, I got bit by 'determining revprop revisions'
[23:12] <jelmer> maxb: do client and server both run svn >= 1.5 ?
[23:12] <maxb> yes, they do
[23:14] <jelmer> maxb: can you get me a traceback of that?
[23:14] <jelmer> (Ctrl+\ then running bt)
[23:23] <maxb> jelmer: oh, sorry. of what? pushing?
[23:23] <jelmer> yeah
[23:23] <jelmer> of the step taht is takin too long
[23:23] <maxb> I will, but not for a while - I'm in the middle of actually building the cache and I don't really want to interrupt it
[23:24] <maxb> only another 240 thousand revisions :-/
[23:24] <jelmer> heh
[23:30] <jelmer> maxb: please file a bug with the traceback
[23:35] <maxb> will do