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