[00:37] jam: nice [01:34] otfl [01:34] meh [01:36] lifeless: where are we at with the pqm shiny? can I mark that RT as complete? Or we're still testing? [01:37] we rolled back last night [01:37] I'm stabbing with a BIG KNIFE [01:37] unfuckingbelievable where this was at [01:46] wow, that bad eh? [02:02] yes [02:02] stdout and stderr are different fd's *for a reason* [02:06] oh my. :-) [02:51] Can anybody give me a hand with fixing history? [02:51] dmuir: elaborate :-) [02:52] Basically, I have several revisions where files were deleted/added instead of moved, and I'd like to fix that. [02:54] Is there some way I can create a branch up to the offending revision, fix it, then play back the other changes on top? [02:54] fix, from the point of view of making the actual old revisions look different, or fix, from the point of view of just stopping it causing a problem with future merging? [02:54] would be nice to fix so the old revision looks different, but primarily because it causes problems with merging. [02:55] Whichever is easiest :-) [02:55] rewriting history is awkward. sorting future merging is easier [02:55] ok [02:55] say the offending revno is 20 [02:56] bzr branch -r 19 trunk fix_moves [02:56] cd fix_moves [02:56] do I then do: [02:56] bzr merge -c 20 ../trunk [02:56] ? [02:57] and then fix the problems? Or is there a better way? [02:58] the problem with the above is merging back into trunk is a pain with fixing all the conflicts... [02:58] * maxb ponders [02:59] I've only ever fixed this sort of thing by carefully rearranging things *while* in the middle of doing a merge that generated contents conflicts [03:00] ah, ok. Yeah, a bunch of these are old revisions that are now causing problems... [03:01] and the conflicts are really hard to figure out... [03:02] Hello? Anyone not AFK here? I sheepishly approach, with a n00b question 0:-) [03:03] zearing: ask away [03:03] err, sorry, zearin [03:03] lol np [03:04] K, so…2 computers. House WiFi. I have a Bzr branch on my desktop I want to access on my laptop. I am embarrassed to admit that I found this to be waaaaay harder than I expected :D [03:04] OS? [03:05] Both computers are Macs on OSX 10.6, latest version of Bazaar, and I have discovered the joy of Bazaar Explorer [03:05] hmm... can you set up a shared folder? [03:05] Oh yeah, I do sharing all the time [03:06] Does OS X run a ssh server by default? [03:06] If so, that'll be a good way to do it [03:06] I'm just clumsy and novice when it comes to networking and URLs that aren't Web-ish [03:06] I have successfully SSHed into my Desktop from this machine, but I want to be able to do it in Bazaar Explorer [03:07] bzr+ssh://othermachine/path/to/branch :-) [03:07] (Also, I think I want to make it a "bound" branch so both stay in sync…that is correct, right?) [03:07] oh! :) [03:07] No username@machine/path/etc/etc ? [03:07] (with the protocol prefix I forgot to type?) [03:08] (gonna try it out right now…) [03:08] You can stick a username@ in before the machine name if your username is different on one end of the connection to the other [03:08] no, same username. [03:08] no need, then [03:08] 'bound' means 'when I commit, make sure it happens both remotely and locally' [03:09] And—I feel stupid asking as I'm pretty sure the answer is "yes", but—this is a URL, so I should choose "Open URL" instead of "Open" in Bazaar Explorer right? [03:09] uh, possibly. I'm a command-line person [03:09] no idea :-) [03:09] :) [03:09] I have full respect and reverence for the CLI [03:10] But I have a visual brain and I forget commands repeatedly unless I can see them as a button :) [03:10] Hehe [03:10] Thanks…gonna give this a shot, but I wanna say this was great support—you guys (and gals?) rock! [03:12] maxb: I've got another problem too... I have some cases where some stuff was added to both a trunk and staging branch, independently. When I try to merge between the two, conflicts galore... any "quick" way to solve? [03:12] um. not 'quick' [03:12] bummer :-) [03:13] The only way I know is to actually merge, get the conflicts, and then make sure you sort them out the right way such that you never need to do it again [03:13] Gah. No luck with bzr+ssh: "Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist." :( [03:13] Guess I'm off to launchpad :) [03:14] zearin: That'll work too... the other alternative would be to set up a share, and put the branch there. You should then be able to access it via the file system. [03:14] under /Volumes/ ? [03:14] zearin: there's probably an error from SSH just before that line that may be relevant [03:15] I tried the SSH in the OSX Terminal and it worked fine [03:15] maybe a password issue? [03:15] well correction…I tried a plain SSH to my other machine in the Terminal, and it worked fine [03:15] I didn't test the bzr+ssh on the CLI [03:16] maxb: what's the "right way"TM to merge so I never need to to do it again? :-) [03:18] zearin: I've found that by using ssh keys, you're much less likely to have issues when using bzr+ssh. [03:19] Hm okay…again, this is something I have fiddled with. Barely. But I don't really know what I'm doing with keys. I have a GUI app to help me manage them (don't laugh! :P) [03:19] last time I tried using bzr over a protocol requiring authentication, it would crap out if asked for a password. [03:20] that seems to be what is happening [03:20] I tried it in terminal and after I gave the password it died [03:20] bzr doesn't have the ability to do ssh passwords - ssh grabs the terminal entirely itself. [03:21] so if you're using ssh (and lp: ends up using ssh), you have to use an agent that can prompt you, or hold the keys open for you [03:21] define "grabs the terminal entirely" ? [03:21] okay [03:21] zearin: tutorial for setting up ssh keys: http://wiki.dreamhost.com/Ssh#Passwordless_Login [03:22] I have one already set up [03:22] I set it up for LP [03:22] I just don't know how to use it otherwise :) [03:22] zearin: my point is that the "Connection close: Unexpected end of message..." error is usually not the whole error. There's often some more output just before that that indicates why the connection failed. [03:22] Okay spiv … onesec [03:23] Tonys-MacBook:~ tony$ bzr branch bzr+ssh://Tonys-iMac.local/Developer/Projects/org.lyris [03:23] Unable to load plugin 'rebase'. It requested API version (2, 1, 0) of module but the minimum exported version is (2, 2, 0), and the maximum is (2, 2, 0) [03:23] Password: [03:23] bash: bzr: command not found [03:23] bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. [03:23] That "rebase" error always occurs [03:24] But I've never used the rebase command, and other operations seem unaffected, so I ignore it. It can't be connected to the SSH issue, can it? [03:24] zearin: 'command not found' - you don't have bzr installed on your server. [03:24] I do, though [03:24] zearin: iYou need to add the same key you added to LP to your other mac, and you'll be able to log in to it without a password. [03:24] OOooh [03:25] both the identity & identity_rsa ? [03:25] zearin: is it in your path ? [03:25] zearin: try "ssh Tonys-iMac.local bzr help", I think you'll see that fail too [03:25] zearin: do this: "ssh Tonys-iMac.local bzr help" [03:25] spiv: \o/ [03:26] it did fail. WTF? I know I have bzr on my Desktop because I've already used it there! [03:26] Yes, when you log in directly, but it might not be on the path for ssh. [03:27] Well I also tried bzr+ssh://Tonys-iMac.local/~/rest/of/path , which according to the Documentation should unambiguously start me at the home dir [03:27] with same results. :( [03:28] zearin: When you connect via ssh, it typically uses a different profile. [03:29] okay, so I just did this: [03:29] Tonys-MacBook:~ tony$ ssh Tonys-iMac.local [03:29] Password: [03:29] Last login: Wed Jun 9 22:11:37 2010 from tonys-macbook.local [03:29] -bash: /Users/tony/.bashrc: No such file or directory [03:29] Tonys-iMac:~ tony$ bzr [03:29] Bazaar 2.1.2 -- a free distributed version-control tool [03:29] http://bazaar-vcs.org/ [03:29] … [03:29] … [03:29] … [03:29] I am so beyond confused. :( [03:29] you're setting the path to bzr in your bash_profile, not your bashrc, or vice verca [03:29] I can never remember which is which :) [03:30] Neither can any of Google's search results :) [03:30] or you may have it beyond an interactive-only guard in bashrc [03:30] or something like that [03:30] Tonys-iMac:~ tony$ which bzr [03:31] /usr/local/bin/bzr [03:32] lifeless: I'm not sure that execing a command via ssh will run your bashrc (or whatever your shell of choice is) at all? [03:32] I'm not sure what you mean… :( [03:33] Tonys-iMac:~ tony$ cat .bash_profile [03:33] . ~/.bashrc [03:33] # Setting PATH for MacPython 2.6 [03:33] # The orginal version is saved in .bash_profile.pysave [03:33] PATH="/Library/Frameworks/Python.framework/Versions/2.6/bin:${PATH}" [03:33] export PATH [03:33] # Aliases [03:33] # [03:33] # @TODO - use "-G" and customize color outputs [03:33] alias ls="ls -aehAF" [03:33] Does that help? [03:33] .bashrc is used for non-login shells [03:33] zearin: (please use a pastebin) [03:33] How do I use a pastebin? [03:33] spiv: zearin put the PATH version in .bashrc [03:33] bah [03:33] zearin: ^ [03:34] spm: ready for some monkey love? [03:34] … [03:34] lifeless: perhaps not literally [03:34] *innocent look* [03:34] spm - please pull lp:~lifeless/pqm/attachments into pqm, after grabbing the current revision-info [03:34] I prefer my girlfriend :) She's much nicer than a monkey [03:34] hookay [03:34] ok... this is getting weird... back to work... [03:35] zearin: you need to set PATH in your .bashrc [03:35] Okay [03:35] Can I be lazy and just…cp .bash_profile .bashrc? [03:35] no [03:35] Damn. [03:36] spiv: I wonder if thats the macosx installer's fault? [03:36] lifeless: hmm, possibly [03:36] :(* [03:36] :*( [03:36] lifeless: 232 robertc@robertcollins.net-20100422043204-70jn37kx2whdm8fr [03:36] lifeless: worth asking someone that knows, at least :) [03:36] spiv: will you file the bug, or should I? [03:37] lifeless: Now on revision 252. u1 and ls are disabled for now; bzr is not [03:37] spm: and do 'python -c "import bzrlib.tests"' just to check [03:37] lifeless: please do, if you don't mind. [03:37] worked [03:37] spm: thanks [03:37] * spm waves heyo to spiv-the-dad [03:38] zearin: how did you install bzr ? [03:38] Mac installer. [03:38] spm: hey :) [03:40] lifeless: I installed it from the command line before, but I could never get Bazaar Explorer to install and work when I did that. I tried installing all the dependencies from scratch and went through tons of grief in a long Launchpad troubleshooting dialogue. Finally a new Mac installer came out, and I used it, and Bazaar Explorer worked. I was ecstatic. :) [03:40] lifeless: Both machines are using bzr from the Mac Installer now. [03:44] All I want is to sync two machines in my house. :( Why do I fail? [03:45] zearin: make the change spiv recommended [03:47] trying… [03:49] Gah [03:49] I'm too clumsy at this stuff :( And tired. I gotta go sleep. [03:50] But you were really supportive and I totally appreciate that! lifeless, spiv, dmuir, anybody else I forgot—thanks. I'll try again soon. ;) [03:50] Good night all, and may your commands complete execution flawlessly! [04:46] maxb: thanks for the help. I've been able to fix the conflicts and now merging works again :-) [05:01] spm: again please [05:01] dmuir: cool [05:03] lifeless: Now on revision 253. [05:03] spm: thanks [05:04] that was from lp:~lifeless/pqm/attachments again, to verify for you [05:09] yes [05:09] hi lifeless [05:10] can we talk about pqm some time? [05:10] poolie: sure [05:10] now is good [05:10] me too [06:06] hi lifeless, i'm back if you want to talk about fixtures [06:25] please ring me [06:25] poolie: ^ [06:35] bzr 2.1.1 on lucid. if i do 'bzr merge /other/branch/' i get 'bzr: ERROR: Working tree has uncommitted changes (See bzr status).' but 'bzr status' says nothing. whats going on? [06:36] m3ga: that's strange [06:36] hey spiv. yes, strange indeed [06:37] m3ga: I suppose that might happen if you had aliased bzr status to actually do "bzr status ." and your cwd isn't the project root... [06:37] nope, thats not it [06:38] Yeah, that did seem a bit far-fetched. [06:38] is just did 'bzr revert' and it removed a couple of files. [06:38] Hmm, then 'bzr status' should have reported something before the revert. [06:38] i agree :-) [06:39] and now it thinks there is no common ancestor [06:39] Or perhaps 'bzr --no-plugins --no-aliases status' should have ;) [06:39] thay may in fact not have a common ancestor. [06:40] Yeah, that message is generally right :) [06:40] yep, no common ancestor [06:41] thanks spiv [07:33] spm: hi [07:33] lifeless: I'd thought you'd forgotten about me.... [07:33] no [07:33] :-) [07:33] sadly python 2.x sucks [07:33] and something is upcasting things to unicode [07:33] switch to VisualBasic, make all our probvlems go away [07:34] so it only shows up in prod :( [07:35] excellent [07:36] spmdo? [07:39] sec [07:39] managed to reproduce locally [07:39] via the magic of paranoia [07:39] :-) [07:40] lifeless: just for the moment: http://www.youtube.com/watch?v=rpRiSb_Ir-s [07:45] hi all [07:45] hey vila [07:46] spm: spmdo, 254 incoming [07:48] lifeless: 254 from lp:~lifeless/pqm/attachments pulled in [07:52] spm: nice song [07:53] lifeless: you've not come across Garbage before? havea few of their cd's. not too shabby. [07:53] oh, I have cd's :) [07:53] doesn't stop it being a nice song [07:56] heh [07:57] I got into garbage at uni [07:58] -not to be quoting thast- [08:13] struggling to remember who I was listening to at Uni. zztop, pink floyd, queen, icehouse for a local band - live at expo '88 - awesomeness; /me quickly checks his record (yes record) collection, gets embarrassed and stops describing right there. [08:15] spm: yeah, better stop there or you will look even older than me :) (There was a Status Quo appearance near Strasbourg a couple of weeks ago and that's how I learned that they weren't dead after all :) [08:17] vila: you'll be pleased to know we've been educated our 7yo with Status Quo, (and Slade etc) which he tends to sing very loudly. I only hope it's a few more years before he discovers the meaning of some of those lyrics... :-D [08:18] hehe [08:19] * vila takes note to listen to the lyrics again now that his english has hopefully improved enough to understand ;) [08:19] 'the wanderer' is a classic that way [08:22] lifeless: how are we going with pqm? safe to open for U1 et al yet? or keep it wrapped? [08:22] waiting on spivs job [08:22] then my test one will go through [08:22] so - 1.3 hours prob [08:22] I'll liase with mthaddon [08:23] lifeless: what is up with pqm ? [08:23] * lifeless needs to send mail [08:23] trying to fix the terrible output people were getting [08:24] for value of terrible including None ? [08:24] no [08:24] truncated subunit stuff [08:25] filtered, no cause of error show, stdout+stderr conflated [08:25] lifeless: oki, I'll make sure the R Tis updated with the deatils of where we're at [08:25] thanks [08:26] lifeless: oooh, the one poolie mentioned, great, I think babune encountered it from time to time but I thought it was due to something else, since it was sporadic I had no way to diagnose, so any fix there will be warmly welcome [08:26] lifeless: so you're fixing subunit or pqm ? [08:26] vila: morning, how was your trip home? [08:26] hi there spiv, vila, mwhudson, lifeless [08:26] vila: pqm [08:27] hey mwhudson [08:27] lifeless, do you know off hand a good incantation to run a unittest from the interpreter [08:27] or more particularly from a doctest [08:27] mwhudson: I missed a train in Cambridge, got the next one (luckily 20 mins later), had on horrible trip between London and Paris due to 6 guys playing cards, drinking beer and laughing louder than you can imagine, but I arrived safely in the end :) [08:28] vila: :/ [08:28] vila: arriving safe is the main point i guess [08:28] and the worst thing... they work for us :/ [08:28] ;-) [08:28] mwhudson: I managed to fix two bugs related to BZR_PLUGINS_AT. Since I couldn't fight the guys, I throw my anger at the bugs :) [08:30] poolie: hehe, no way, we have some guys who drink but they manage to make *us* laugh instead :) [08:31] s/some/one/ [08:31] :-) [08:31] mwhudson: well, protecting the innocent(s) requires some blurry references :) [08:32] one guy who drinks? i think you need to pay more attention :) [08:34] there is drinking.... and then there is... drinking... [08:35] poolie: testscenarios has a doctest demo doing that [08:35] poolie: already fixed up to not chat to stdout/stderr [08:35] ok thanks [08:35] you may recognize it still :) [08:36] I drink only water and I'm not responsible for what is added there by barmaids as long that it's less than say 20% of the total :) [08:36] :) [09:15] I hate python2 [09:17] :-( [09:17] i like java :+) [09:17] btw lifeless, if i have changes in my files, and bzr know about that modified: [09:17] ChangeLog [09:17] src/cv_paintbrush_tool.c [09:18] why he still dosnt want to update... has uncommitted changes (See bzr status). Use --no-strict to force the push. [09:46] netshine: newer bzr doesn't do that, it says '--strict to prevent' [09:46] netshine: but are you pushing, or updating ? they are different things [09:48] thats ok fixed that. i was needed to mark the changes. === radoe_ is now known as radoe === lifeless_ is now known as lifeless [14:10] I have clearly gone mad [14:10] apparently left this branch in a completely broken state on the last commit [14:11] syntax errors and everything [14:11] this last bug is at least in codecs.open rather than my code [14:33] hey mgz [14:34] hey Alexander, just read the mail about a branch you want me to review [14:35] privet sacha, hi mgz [14:36] vila has been practicing his russian? or is very interested in hedges. [14:36] mgz: can jython use ctypes ? [14:36] mgz: Either way, he's branching out 8-} [14:37] One more joke going over my head :-/ [14:37] fullermd: _o/ [14:37] vila: not currently, but there is com.sun.jna [14:37] * fullermd buys vila a very tall hat. [14:38] I hate hats (sounds funny :) [14:38] http://www.hedging.co.uk/acatalog/pics_10273.html [14:39] mgz: hehe, so, bialix told me privet is the closest to hello indeed ;) [14:42] what? [14:43] why are hedges? [14:44] I was just making a little joke, bialix :) [14:45] ali g? [14:45] I don't want a chicken [14:46] bonjour vila [14:46] :-P [15:02] bialix: lp:~jspashett/bzr/587868_args_handling_cant_debug looks sensible to me, could do with some tests though [15:03] yep, I think it's possible to write tests here by replacing sys.argv with some value and then back [15:03] can you add such comment? I'm not sure is Jason will be able to write such tests though [15:05] no problem. [15:11] nice Bug 592083 [15:11] Launchpad bug 592083 in Bazaar "UnicodeDecodeError in get_password if user name is unicode (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/592083 [15:12] there are several nasty bugs when user name is non ascii, or have a space inside. [15:12] I know, but never got enough time to fix :-/ [15:12] yeah, the space inside one bugged me for agest [15:13] but removing the default userid stuff last month was good enough for me [15:13] it's not enough [15:13] and that bug show === TheLyle is now known as IslandUsurper [16:06] vila: are you still around? [16:06] jam: hellloooo jam, yes [16:12] parthm... isn't in the channel... === IslandUsurper is now known as IslandUsurperAFK === beuno is now known as beuno-lunch [17:41] jam: ping [17:52] hi parthm [17:52] jam: hi [17:53] jam: i was looking into the "Will continue to try.." message. removing it totally seems good to me. [17:54] jam: if the timeout is always 0 i can also remove the code for it. do you know if "poll" is bzrlib.lockdir.wait_lock is used or is that also always 0? [17:55] parthm: the timeout is not 0 locally [17:55] just for the smart server [17:56] jam: ok. in that case i suppose i will just put the message in a conditional for time > 0 [17:56] s/time/timeout/ === IslandUsurperAFK is now known as IslandUsurper [17:57] jam: thanks for the clarification. i will update the mp for this. === beuno-lunch is now known as beuno [18:17] okay, let's finish this off, building py3k now. [18:19] mgz: did you port bzr to python 3? [18:19] ha, no, need to finish getting it working on less exotic pythons first [18:20] I need to check that my testtools change doesn't break py3k though. [18:38] okay, this is going to be a problem [18:38] looks like testtools has been written to be source-compatible with py3k [18:39] don't see how I can easily maintain that and actually test things related to unicode [18:41] wonder if they'd take a patch that ran 2to3 in setup.py instead [18:50] though, does appear to be broken on py3k currently anyway [19:34] okay, back to work [19:35] why I hate DocTestMatches - what the hell is the mismatch here: [19:35] http://paste.ubuntu.com/447885/ [19:46] okay, got it. [19:47] py3k removes the word "integer" from the exception message raised by `1/0` which means there's one too many spaces between the dots [20:22] anybody know how to get loggerhead to serve up robots.txt? [20:23] spiders suck, but at least some of them play by the rules [20:31] why should that be loggerhead's job? or are you using it without any kind of front end webserver? [20:35] morning [20:38] morning lifeless [20:39] mgz: it is running proxied behind apache [20:39] so, get apache to serve up robots.txt then. [20:39] but the "top level" for the domain is the loggerhead server [20:40] Alias robots.txt /path/to/robots.txt # or something [20:41] hm... my conf uses AliasMatch ^/robots.txt$ - but can't remember if I had a reason or was just being anal [20:42] mgz: can you post the whole line? [20:43] well, what I have to hand is: [20:43] AliasMatch ^/robots.txt$ "C:/Program Files/Apache2/htdocs/robots.txt" [20:44] I remember why I wrote it like that now, means paths like /robots.txt/extra/junk won't be translated [20:46] hmm [20:46] that doesn't seem to do it in my case [20:47] what mechanism are you using to forward requests to the (I presume) seperate loggerhead server? [21:00] mod_rewrite [21:00] I have a working rewrite rule now [21:01] ugh, could also be called mod_misuse [21:01] mgz: I've been using it to front Zope for more than a decade [21:02] bet you could do exactly what you are already with shorter, more readable config and just straight mod_proxy [21:02] nope [21:02] for some reason people treat mod_rewrite as a front end to everything else [21:02] I really do need to rewrite the URLs to get virtual hosting working [21:03] anyway, glad it's working. [21:03] it uses mod_proxy on the backend [21:03] thanks [21:03] I still think that loggerhead should be able to serve static files trivially [21:04] I think that might be nice [21:11] lifeless: howdy! you find a house yet? [21:12] http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=40+Rowse+Street,+Rangiora,+Canterbury,+New+Zealand&sll=-43.561088,172.721778&sspn=0.007961,0.017767&ie=UTF8&hq=&hnear=40+Rowse+St,+Rangiora+7400,+New+Zealand&ll=-43.316451,172.586439&spn=0.007993,0.017767&z=16&layer=c&cbll=-43.316371,172.586489&panoid=QOxqEX79iOaIyNEKwDze-A&cbp=12,283.41,,0,12.7 [21:13] we've put an offer in on it [21:13] cool [21:15] good luck [21:17] we lost a bidding war when I was looking 10 years ago [21:17] :( [21:18] turned out the place would've sucked -- the one we got is better (and cheaper) [21:18] :) [21:18] they have accepted out offer [21:18] but we're doing due diligence stuff atm [21:19] so contract isn't unconditional yet [21:19] ah, ok [21:38] I want to make the first revision the current revision. How do I do that? [22:06] TresEquis: hey [22:06] mars: since TresEquis is here, lets talk zope.testing briefly [22:06] mars: you might like to read https://code.edge.launchpad.net/~gz/testtools/unicode_tracebacks_501166/+merge/26094 [22:08] lifeless: I'm still around [22:08] lifeless, well, that is interesting :) [22:08] TresEquis: I'm worried that I'm going to hold up actual fixes going into zope.testing for mars [22:09] when it seems to be that all the proposed patches improve things, there doesn't seem to be a benefit holding one hostage to a separate infrastructure issue [22:09] so I'm hoping to change your -1 that you put in the zope.testing utf8 traceback review ;) [22:09] lifeless: new features that the Zope developers can't test shouldn't land [22:09] and bugfixes that we can't test are iffy, too [22:10] TresEquis: they can test it, its just not convenient, AIUI. [22:10] TresEquis: or am I wrong? [22:10] testing means that it can be run in buildbots, on multiple OSes, etc. [22:11] yes [22:11] and in the case in point it can be [22:11] its just not convenient - which there is a separate task going on to fix. [22:11] If somebody who actually uses subunit can take point on it, then I think we can merge fixes [22:11] frankly, the original feature should never have landed without reproducible tests [22:11] TresEquis: mars and sidnei both do - lp uses it for its c-i stuff, and landscape uses it for client tests [22:12] that don't depend on having subunit installed in the OS default path [22:12] You had me totally convinced until that line; how something is installed is really irrelevant, isn't it ? [22:12] so, if sidnei wants to merge the fix, and promise that it actually helps, I guess I'm -0 on that [22:13] lifeless: it needs to be testable in isolation [22:13] on *every* machine where *anybody* develops zope.testing [22:13] which means one of the two solutions we talked about the other day [22:13] TresEquis, does the test suite pass right now when subunit isn't installed? I see that there are doctests for the subunit support. [22:13] TresEquis: yes, thats orthogonal to virtualenv though: you have vm's, chroots, virtualenv, ec2 as different means to do isolated testing. [22:13] mars: but nobody except you guys can keep from breaking the subunit support [22:14] true [22:14] TresEquis: I don't buy every machine, as soon as you have any OS specifici stuff, *some* tests have to become conditional. [22:14] e.g., zope.testing's testrunner is now deprecated [22:14] TresEquis: I'm not saying 'dont improve the testing situation with subunit' [22:14] lifeless: there is *nothing* actually OS-specific about htis [22:15] just that subunit's Python support is tied at the hip (for now) to its C build [22:15] TresEquis: I'm saying 'don't hold actual fixes hostage to a different *improvement*'. If mars was reducing test coverage, I wouldn't be saying what I'm saying. [22:15] TresEquis: the risk you speak of already exists, and mars's patch doesn't make it worse - AIUI. [22:15] right now, *everything* to do with subunit in zope.testing is bitrotted [22:15] TresEquis: which is impressive, as its what - 3 weeks old or something ? :) [22:16] no, its a year old [22:16] particularly because zope.testing.testrunner is itself deprecated in favor of zope.testrunner [22:16] wow, time flies. [22:16] I was sure jml's patch only landed a month or so back [22:16] but none of the developers working to manage the split to zope.testrunner can test the subunit stuff without a major timesuck [22:17] I did that merge [22:17] but subunit support was around longer than that [22:17] TresEquis, ok, would getting subunit onto PyPI solve the problem? Then we can make zope.testing properly depend on subunit for devs. [22:17] mars: yes, that would help [22:18] 'subunit-python' or 'python-subunit', that is [22:18] I contributed a setup.py for that [22:18] TresEquis, I'm confused [22:18] TresEquis, I added subunit support to zope.testing this year [22:18] Didn't sidnei add other subunit-related stuff last year some time? [22:19] TresEquis, there's some other stuff related to running tests in subprocesses [22:19] TresEquis, which has, sadly, nothing to do with subunit [22:19] TresEquis, although if it were implemented properly, it would probably use subunit :) [22:19] TresEquis: so what I think you are saying is "There is a testing and refactoring risk with subunit in zope.testing at the moment" [22:19] yes [22:19] TresEquis: and "That risk must not be increased and should be decreased" [22:20] in particular, we are actively refactoring zope.testing [22:20] TresEquis: and I agree with both of those. [22:20] the subunit stuff in zope.testing is very well tested, fwiw and was added just before the recent split-out of zope.testing.testrunner was proposed [22:20] TresEquis: however you also seem to be implying "the patch from mars increases the risk" [22:20] TresEquis: which seems entirely false to me, as it comes with tests. [22:21] lifeless: I said earlier in this conversation that I could see mars' fixes landed by somebody like sidnei [22:21] ok cool. [22:21] who can test them [22:21] then we're good. I will get to your subunit patch, I promise. [22:22] now we're not house hunting I should be able to catch up with my personal projects :) [22:22] but I'm unwilling to see *more* features added that can't be tested by anybody working on zope.testing [22:22] TresEquis, yes. I didn't even realize the subunit tests were conditional when I added them. My subunit unit test would break on those dev's workstations :( [22:23] if subunit support in zope.testing were automated, for instance, then I or Lennart or somebody could help get them ported to zope.testrunner (without aforementioned timesuck) [22:24] sorry, I've joined late, but by "automated" you mean something more than the large number of doctests that are already present and run whenever subunit is installed? [22:24] zope.testing's self-dependency (it needs itself to run its own tests) has been a major stumbling block on porting zope.* code to Py3k, for instance [22:24] jml: they should run *always* [22:24] or else the code will bitrot [22:25] TresEquis, what about the code in z.testrunner that only works if Python is compiled with certain options? [22:25] which means that getting subunit-python into the buildout (or better, the virtualenv) is crucial [22:25] hmm? [22:25] those features are tested on buildbots [22:26] TresEquis, so, would it be good enough for me to set up a hudson instance (or I guess a buildbot) that runs the tests in an environment w/ subunit installed? [22:26] those features are also used frequently by at least some of the folks who maintain zope.testing [22:26] subunit isn't (yet, at least) [22:27] except for sidnei, apparently [22:27] TresEquis, my outsider status aside, I do use subunit w/ zope.testing frequently and I do send patches [22:27] jml: right [22:28] it's just hard to do the refactoring of zope.testing / zope.testrunner without knowing whether we have broken the conditional tests [22:28] TresEquis, well, you'll have to test both paths anyway as long as it's an optional dependency [22:29] my branch for subunit adds a distutils setup.py for the package, for instance: lifeless is going to look into merging it [22:29] TresEquis, I guess you could hack up something that tweaks sys.modules or what-have-you [22:29] jml: we have patterns for that: e.g., the buildout has separate parts for separate Python versions, etc. [22:29] oh right. [22:29] buildout :) [22:30] jml, I think the idea was to make subunit a required dependency for developers, but optional for users [22:30] jml: not everybody lives in a .deb monculture [22:30] mars: rithe [22:30] sorry, right [22:30] and make it trivial to install [22:30] I actually made a stab at doing a CMMI build *inside* the buildout [22:31] but ran out of tuits [22:31] TresEquis, you should have read my blog post first :) [22:31] subunit is just a little cranky to build [22:31] yep. [22:31] the Python bits are straightforward, though [22:31] at least for now [22:32] lp:~tseaver/subunit/add_distutils_support [22:33] creates an sdist which installs the library code and the tests cleanly [22:33] sorry, s/tests/filters/ [22:34] TresEquis, have you verified that this makes a usable egg for your purposes? [22:35] lifeless, does your testtools traceback branch obsolete my zope.testing traceback branch? [22:35] I don't think so [22:35] ok [22:36] jml: that was at the end of the tuit stack, too [22:37] hi [22:37] I did verify that it made an sdist installable in a virtualenv [22:37] and that the filter scripts could run with '--help' [22:37] lifeless, actually, it looks like they are unrelated. testtools can't handle utf-8 : neither could the zope.testing subunit output. Same bug, different pieces of code. [22:37] meaning that they could import subunit [22:37] mars: right [22:37] mars: the testtools fix that mgz is doing is rather deeper [22:37] TresEquis, cool. [22:37] mars: because pedants [22:38] i have a friend who uses Windows who will be testing a project i'm working on.... he installed Python 2.6.5, Bazaar, and Bazaar Explorer, but he gets a cannot execute bzr error [22:38] TresEquis, I guess ideally I'd like to know it works before I merge it, particularly since setup.py's are quite hard to test automatically. [22:38] mars: and interestingly I've got a patch I'm looking at right now to address a similar cause in subunit itself [22:38] lifeless, yes, I thought about finding and fixing traceback inputs for all of 5 minutes before moving to a defensive code solution [22:39] jml: one trivial test is to run 'python setup.py --long-description', or whatever, and examine the output [22:39] which at least guards against syntax errors [22:39] lp:~mars/zope.testing/fix-subunit-utf8-traceback-reporting right? [22:39] but the folks doing the release-to-PyPI are the ultimate watchdogs [22:40] which works because they rely on setup.py to do that task [22:40] mars: yes [22:40] bah [22:40] toomanyms [22:40] TresEquis, I don't know who's going to do that :) [22:40] mgz: yes [22:40] mgz, yep. We had a crash where the traceback coming into the code could be uft8, unicode or ASCII. And it is in a testrunner, so for the tb contensts, anything goes! [22:40] it's similar in that it adds handling for arbitrary bytestrings as tracebacks. [22:41] jml: I'm happy for any subunit committer, which includes you, to upload stuff to pypi - I'd like them all to have permissions. [22:41] in fact [22:41] I'd like a lp-group-to-pypi-project permission syncer [22:41] I can has automation please? [22:41] lifeless, LP has APIs. Don't know about PyPI [22:41] the branch for testtools is more like changing your OutputFormatter.format_traceback code to always return unicode [22:42] but both are trying to squish the same kind of problem. [22:42] jml: it has a web UI at lesat ;) [22:42] jml: Stephan Richter has some script he uses to bless / blast users with perms for zope.* packages [22:42] lifeless, and james_w has beautifulsoup matchers. you should write the syncer now :) [22:43] \o/ [22:43] did you see my bug about matchers and addDetail? [22:43] no, I didn't. [22:44] PyPI speaks xmlrpc, I think: http://wiki.python.org/moin/PyPiXmlRpc [22:44] Mismatches should have a way to persuade assertThat to call addDetail with a bunch of Content if it fails due to them [22:45] I want to stop the Mistmatch.describe() methods in soupmatchers stop printing the whole html, as that's a terrible idea, but I would love to provide it for looking at if desired [22:46] TresEquis, if I merge this patch into trunk but don't release, will that help / unblock you? [22:47] james_w: oh thats a great aidea [22:47] james_w: please do it [22:47] james_w: I suggest a query interface on Mismatch [22:47] james_w: get_details, or something [22:47] I suggested an attribute, but that works fine [22:48] and then, assertThat can do 'for content in Mismatch.get_details: self.addDetail(unique_name, content)' [22:48] or roughly that [22:48] bug 591327 [22:48] adjust as you please [22:48] Launchpad bug 591327 in testtools "Please allow Mismatches to add detail to the result (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/591327 [22:49] these abstractions are feeling really right [22:49] yeah [22:49] though of adding disposition to Content? [22:49] thought [22:49] mm [22:49] as in inline/attachment [22:50] which could be interpreted by a runner as to whether to display by default? [22:50] I don't think it belongs there [22:50] derailing the Matchers topic a bit, did anyone play my spot-the-difference from earlier? http://paste.ubuntu.com/447885/ [22:50] content maps well to email, http, disk files [22:50] what to do and how to address it is a wrapper issue - IMO, I may well be wrong [22:51] jml: we aren't really unblocked meaningfully until we can either install 'subunit-python' from PyPI (or another URL) [22:51] or else build subunit inside the buildout [22:51] I prefer the former at this point ;) [22:51] TresEquis, ok. that's good to know. [22:51] if somebody made the sdist from that branch and put it up somewhere "permanent" [22:52] plus there's my testtools merge request if someone wants to take a look? [22:52] then we could point to that URL in the 'find-links' bit for the buildout [22:52] TresEquis, I'm a little reluctant to release subunit right now, mostly because it's too much of a context switch and I'm not 100% the setup.py does what we want. Also I have to leave for a flight in ~30mins [22:52] (t-i-p IRC channel?) [22:52] james_w, yeah, let's [22:52] and procede accordingly [22:52] james_w: that is #python-testing [22:56] TresEquis, but I'll try to get to it tomorrow or next week, and try prodding lifeless to get there first :) [22:57] mgz, nothing stands out [22:58] jml: OK -- in the meanwhile, sidnei or gary_poster or somebody with subunit-fu can go ahead and do the merge of mars' branch [22:59] TresEquis, cool. [22:59] indeed. only printing the actual line for the Mismatch would help, and putting the whole thing as an attachement as was being discussed [23:35] lifeless: so, bug 309682 [23:35] Launchpad bug 309682 in Bazaar Subversion Plugin "tags are copied but their revisions may not be (affected: 0, heat: 9)" [Low,Triaged] https://launchpad.net/bugs/309682 [23:36] james_w: ^ [23:36] I'm wondering if the right approach is to fetch all revisions for which we have tags [23:53] jelmer: I'd be happy with that [23:54] jelmer: would it be any more expensive for bzr-svn? [23:55] james_w: not particularly [23:56] james_w: of course if there's a revision tagged that doesn't have any relation to the mainline it will mean fetching more data [23:56] but that doesn't seem unreasonable [23:57] jelmer: I think we should do that