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:14 |
lifeless | ah, little early. | 00:17 |
lifeless | hmm, I need a teddy bear | 00:17 |
Meths | What's the error msg? | 00:19 |
lifeless | it doesn't crash-fail, it formats wrongly | 00:20 |
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:21 |
lifeless | ok, \o/ | 00:23 |
lifeless | python3 would be so much nicer | 00:23 |
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:29 |
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:30 |
lifeless | http://pastebin.com/M7AwUADN | 00:31 |
mgz | http://paste.ubuntu.com/447983/ <- I just want my repl :_: | 00:31 |
lifeless | mgz: ironpython3 ? | 00:31 |
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:32 |
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:33 |
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:34 | |
lifeless | PQM is failing to format and attach subunit summaries | 00:35 |
lifeless | even though the WEBUI is doing just fine | 00:35 |
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:36 |
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:37 |
lifeless | its weakly coupled - speaks the same object protocol, magic happens | 00:38 |
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:39 |
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:40 |
lifeless | my testtools patch would seem in line with that change | 00:41 |
lifeless | neither right or wrong | 00:41 |
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:42 |
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:43 |
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:44 |
strk | like disabling autopacking while on gprs ? | 00:45 |
mgz | <lifeless> 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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
mgz | yup, got to be careful about what you put in builtin exceptions | 00:58 |
lifeless | mgz: ok, 3.1 support pushing up now | 01:04 |
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:05 |
jelmer | nice | 01:06 |
lifeless | we had 3.0 | 01:06 |
lifeless | but 3.1 changed the rules for imports again | 01:06 |
mgz | pushing my fixes for idiocy, I'll then get py3k working | 01:07 |
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:09 |
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:10 |
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:11 |
lifeless | my concern is just that we will probably have folk wanting backports/SRU's | 01:12 |
lifeless | and the easier for them, the better - particularly when its low cost to us. | 01:13 |
poolie | hi there lifeless, mgz | 01:15 |
mgz | hey poolie | 01:16 |
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:17 |
mgz | let's squish that last one | 01:18 |
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:24 |
poolie | similarly setUp | 01:25 |
poolie | and we just went through realizing this was error-prone in test cases themselves | 01:25 |
lifeless | agreed | 01:26 |
lifeless | this seems more an internal contract question, not the public composing contract though ? | 01:26 |
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:33 |
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:34 |
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:35 |
lifeless | james_w: while you're looking at testtools.run, supporting bug 505386 would be most awesome | 01:36 |
ubot5 | Launchpad bug 505386 in testtools "testtools.run should support selecting tests by id (affected: 2, heat: 8)" [Wishlist,Triaged] https://launchpad.net/bugs/505386 | 01:36 |
spm | lifeless: heyo; where are we at with pqm this fine friday? | 01:40 |
lifeless | spm: nothing to do at the moment | 01:40 |
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:41 |
spm | \o/ | 01:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:49 |
lifeless | mars: bug 592262, if you want to chat in realtime, I'm here | 01:55 |
ubot5 | Launchpad bug 592262 in testtools "testtools breaks if a string exception is raised (affected: 1, heat: 6)" [Wishlist,Incomplete] https://launchpad.net/bugs/592262 | 01:55 |
lifeless | ba | 01:55 |
lifeless | bah - mars sorry! | 01:55 |
lifeless | mgz: ^ | 01:55 |
lifeless | too many m's | 01:55 |
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:56 |
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:57 |
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:58 |
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 | 01:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:10 | |
lifeless | :< | 02:11 |
lifeless | what should it do if it can't encode to your terminal - show the repr ? | 02:11 |
mgz | well, this is in the context of running a testsuite | 02:12 |
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:13 |
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:14 |
lifeless | at least bytes are a different type now | 02:15 |
lifeless | :P | 02:15 |
mgz | okay... | 02:17 |
mgz | return stream.__class__(stream.buffer, stream.encoding, "replace", stream.newlines, stream.line_buffering) | 02:17 |
mgz | and I actually get complete output. | 02:18 |
mgz | horrible hack, but I'll survive | 02:18 |
lifeless | oh my | 02:23 |
lifeless | mgz: I could send you a CD of Ubuntu, if you like. | 02:23 |
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:24 |
lifeless | mgz: I was teasing :) | 02:31 |
mgz | I would play along, but py3k is keeping me up past my bed time... | 02:33 |
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:34 |
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:35 | |
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:36 |
lifeless | self.pop() | 02:37 |
lifeless | looms, right | 02:37 |
lifeless | I feel the need for wotw | 02:37 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
mgz | get this string into this file in this encoding escaped thusly, test than running said file gets sensible unicode output | 02:49 |
=== parthm_ is now known as parthm | ||
thumper | how do you 'close' a branch? | 06:10 |
spiv | chmod -R a-r? Or is there something more you want than "no-one has permission to change this"? | 06:14 |
rockstar | spiv, I think thumper wants something like open().close(), but for branches. | 06:16 |
spiv | Oh, ok. | 06:16 |
spiv | There's no explicit close in the API. The closest we have is "release all references to that object". | 06:17 |
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:18 |
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:25 |
lifeless | jam: I'm going to feel all guilty now. | 06:51 |
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 | 06:52 |
BlindWolf8 | Hello. Anyone here? | 07:08 |
spiv | Yes. | 07:09 |
BlindWolf8 | Hi spiv. | 07:10 |
BlindWolf8 | I have a question about Bazaar setup. Are you able to help me? | 07:10 |
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:11 |
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:12 |
BlindWolf8 | The user that I logged in as should have permission for everything. I am not sure what it's trying to do. | 07:13 |
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:14 |
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:15 |
BlindWolf8 | there's a .bzr.log will that help? | 07:16 |
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:17 |
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:18 |
BlindWolf8 | The exact error I get in Bazaar Explorer is: bzr: ERROR: Permission denied: ".": : [Errno 13] Permission denied: '/.bzr' | 07:20 |
BlindWolf8 | Hello? | 07:22 |
BlindWolf8 | Hi Adys | 07:27 |
BlindWolf8 | Hello all. | 07:30 |
spiv | BlindWolf8: the bzr log from the client to start with, I think, but the remote one might be interesting too | 07:31 |
spiv | BlindWolf8: that error does sound likely to be a simple permissions problem, though | 07:32 |
vila | hi all | 07:33 |
spm | hey vila | 07:33 |
vila | thumper, spiv: In a forthcoming submission I implemented a transport.disconnect() method that close the socket for transports that have one | 07:34 |
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:35 |
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:36 |
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:37 |
BlindWolf8 | spiv: Here's the client log: http://pastebin.com/CBmzHwZd | 07:39 |
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:40 |
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:41 |
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:42 |
spm | spiv: Bazaar (bzr) 2.0.4, so no. :-) | 07:43 |
BlindWolf8 | spiv: huh? | 07:43 |
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:44 |
* 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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
spiv | BlindWolf8: I'm not sure what you're talking about? | 07:55 |
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:56 |
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:57 |
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:58 |
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? | 07:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
lifeless | spiv: switched the readlock/deprecated lines, works better | 08:12 |
BlindWolf8 | Thanks again guys. I think I got it from here. | 08:12 |
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:13 |
spiv | lifeless: I haven't read the docs yet | 08:14 |
spiv | lifeless: and that's my comments so far! | 08:14 |
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:15 |
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:16 |
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:17 |
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:18 |
spiv | 3.something, at least. | 08:19 |
spiv | The exact value of ".something" is a bit academic as far as bzr is concerned :) | 08:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
spiv | Ok, good. | 08:25 |
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:26 |
spiv | :) | 08:27 |
=== radoe_ is now known as radoe | ||
BlindWolf8 | Hello? | 08:41 |
parthm | BlindWolf8: hi | 08:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:51 |
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:52 |
parthm | spiv: oh. where should i look? | 08:53 |
parthm | spiv: ah. line 55 ... let me check. | 08:53 |
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:55 |
parthm | spiv: ok. sure. just for my info. what is the fix? | 08:56 |
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:57 |
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:58 |
parthm | spiv: cool. | 08:59 |
lifeless | spiv: parthm: a nice way is | 09:02 |
lifeless | self.addCleanup(branch.lock_read().unlock) | 09:02 |
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:03 |
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:04 |
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:05 |
lifeless | spiv: I found bugs when I introduced the idiom to builtins.py | 09:06 |
lifeless | spiv: (in plugins) | 09:06 |
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:07 |
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:08 |
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:09 |
lifeless | spiv: then it sounds like brainstorming to find another way to spell 'these things are connected' is appropriate. | 09:10 |
spiv | *nod* | 09:10 |
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:11 |
spiv | Anyway, thanks for the quick teddy bear. I'll followup on Monday. | 09:13 |
lifeless | sounds good | 09:13 |
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:33 |
mobby | I've tried clicking on the links for the stable and the nightlies as well and they do the same thing | 09:34 |
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:36 |
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:38 |
mobby | hmm strange, I'm in work so it might be our proxy settings. I'll try something else. | 09:39 |
mobby | yeah it was our proxy. Apologies, should have tried that first. Thanks for the help. | 09:47 |
cbz | what does 'conflicting tags' mean? | 12:02 |
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:12 |
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:13 |
jpds | #export BZR_EMAIL="$NAME <$EMAIL>" # Override email for Bazaar. | 12:19 |
Mez | jp~. | 12:37 |
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:38 |
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 | 12:39 |
=== nlisgo_ is now known as nlisgo | ||
=== gnomefreak76 is now known as gnomefreak | ||
ciss_ | hi | 13:48 |
n3l | Quick question... just install bzr on mac os x. Where is the gui app installed to? Not found in applications. | 13:58 |
n3l | Nevermind... bzr explorer : this isn't noted in bzr -h : https://answers.launchpad.net/bzr/+question/99420 | 14:00 |
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:10 |
parthm | ciss_: you can add patterns for files to be ignored to .bzrignore (see 'bzr help ignore') | 14:15 |
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:17 |
parthm | ciss_: i tend to add files i need to ignore at the pop up as unknown in 'bzr st'. so black-list. | 14:20 |
=== deryck_ is now known as deryck | ||
krisives-gearbox | Does anyone know how nested branches in BZR 2 are handled? | 17:10 |
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 |
=== beuno is now known as beuno-lunch | ||
krisives-gearbox | it appears to not touch to sub branch | 17:12 |
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:13 |
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:14 |
krisives-gearbox | Yeah, which isn't worth getting into lol | 17:15 |
krisives-gearbox | Have you ever used Stacked Branches? | 17:15 |
jelmer | krisives-gearbox: yep | 17:17 |
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:18 |
krisives-gearbox | A and B are the same, so B can be a branch of A because their changes can be shared easily | 17:19 |
=== IslandUsurper is now known as IslandUsurperAFK | ||
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:20 |
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:24 |
jelmer | no, I don't have experience with config-manager | 17:26 |
=== deryck is now known as deryck[lunch] | ||
=== beuno-lunch is now known as beuno | ||
=== deryck[lunch] is now known as deryck | ||
=== IslandUsurperAFK is now known as IslandUsurper | ||
ericmoritz\0 | I mean | 18:43 |
=== Pilky_ is now known as Pilky | ||
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:37 |
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:38 |
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:40 |
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:41 |
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:42 |
krisives-gearbox | either way, thanks for the help :) | 19:44 |
fullermd | np :) | 19:44 |
krisives-gearbox | are you a bzr dev fullermd? | 19:45 |
fullermd | Oh, no. I just sit around and harass them. | 19:45 |
krisives-gearbox | great minds think alike | 19:46 |
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:47 |
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:48 |
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:50 |
fullermd | Is folderC versioned? | 19:51 |
ciss_ | oh. yes, it is. | 19:52 |
* fullermd nods. | 19:52 | |
fullermd | That'll break the ignore chain then. | 19:52 |
ciss_ | thanks a lot, knowing this should end all my troubles with .bzrignore :) | 20:00 |
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:03 |
TresEquis | e.g. '$ bzr commit -m "Should have ignored." folderA/folderB/folderC/fileA' | 20:04 |
ciss_ | sorry to ask: (how) can i use a text file as source for the file listing? it's a rather long list. | 20:05 |
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:06 |
ciss_ | thanks | 20:09 |
hazmat | is there anything like a more permanent shelf | 20:58 |
hazmat | like i can unshelve some changes, but still keep the patch/content shelved | 20:59 |
radoe | hazmat: bzr unshelve --keep? | 21:03 |
hazmat | radoe, perfect, thanks | 21:04 |
=== Leonidas_ is now known as Leonidas__ | ||
=== Leonidas is now known as Leonidas_ | ||
=== Leonidas__ is now known as Leonidas | ||
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:52 |
jelmer | maxb: have you tried disabling the cache? | 22:59 |
maxb | jelmer: It improved matters considerably for read only operations | 23:09 |
maxb | However, when I tried to push back, I got bit by 'determining revprop revisions' | 23:10 |
jelmer | maxb: do client and server both run svn >= 1.5 ? | 23:12 |
maxb | yes, they do | 23:12 |
jelmer | maxb: can you get me a traceback of that? | 23:14 |
jelmer | (Ctrl+\ then running bt) | 23:14 |
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:23 |
maxb | only another 240 thousand revisions :-/ | 23:24 |
jelmer | heh | 23:24 |
jelmer | maxb: please file a bug with the traceback | 23:30 |
maxb | will do | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!