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