[00:07] <mwhudson> jelmer: did i tell you before about bzr-svn tests segfaulting with python 2.4 ?
[00:16] <jelmer> mwhudson: no
[00:16] <jelmer> mwhudson: please file a bug with gdb backtrace if possible
[00:17] <mwhudson> ok
[00:17] <mwhudson> doesn't happen with 2.5
[00:17] <mwhudson> trying on hardy w/ec2 now
[00:20] <mwhudson> oh waht
[00:20] <mwhudson> jelmer: any ideas? http://pastebin.ubuntu.com/210808/
[00:20] <mwhudson> (haven't dug at all, maybe i'm doing something dumb)
[00:31] <poolie> hello
[00:31] <Peng_> Hi
[00:34] <jelmer> mwhudson: that one should be fixed now
[00:34] <mwhudson> jelmer: in bzr-svn?
[00:34] <mwhudson> (i was testing the release-0.6.3 tag)
[00:44] <Pilky> poolie: did you get my email about the bzr licence?
[00:44] <poolie> hi
[00:44] <poolie> i did get it on friday
[00:44] <Pilky> cool
[00:44] <poolie> i'll reply today
[00:44] <Pilky> thanks
[00:44] <Pilky> just wanted to make sure, been having a few problems sending emails recently
[00:45] <Pilky> anyway time for bed for me, night
[00:50] <spiv> Hello.
[00:50] <poolie> hello spiv
[01:14] <mwhudson> oh hm, does happen on hardy too
[01:18] <mrooney> lifeless: checking out grisbi, eh? saw your bug reports :)
[01:19] <lifeless> mrooney: yah
[01:19] <lifeless> mrooney: for 'easy to use' it seems harder than gnucash
[01:19] <lifeless> ><
[01:20] <poolie> hello lifeless
[01:20] <lifeless> hi poolie
[01:20] <poolie> is it better in some other way?
[01:20] <poolie> i think i tried it...
[01:20] <lifeless> poolie: I think it may have saner defaults, but in my limited experiment it wasn't really better/worse
[01:21] <poolie> gnucash doesn't seem to be changing very fast
[01:21] <lifeless> I was hoping for something like MS Money, which I used inthe late 90's, that was at least polished, for all its defects
[01:21] <mrooney> lifeless: I popped in to ask if you had a minute to evaluate the personal finance software I am working on, wxBanker, and let me know what you think coming from grisib/gnucash. I am currently working on a newer version for Karmic
[01:21] <RAOF> I've quite liked Homebank's interface, but I'm may well be looking for something a little bit different to you.
[01:22] <poolie> mrooney: what do you think is better than gnucash in wxbanker?
[01:22] <lifeless> mrooney: karmic package is the thing to try?
[01:22] <mrooney> there are some screenshots at wiki.ubuntu.com/wxBanker I do believe :)
[01:22] <mrooney> nope bzr branch lp:wxbanker is the thing to try, it just needs python-wxgtk2.8 and python-numpy
[01:23] <mrooney> poolie: gnucash is more featureful and advanced, I tried it and initially was overwhelmed and just wanted something simple to keep track of basic transactions in arbitrary accounts
[01:23] <lifeless> RAOF: could be; I need to manage (today) a mortgage, bills that are paid by proxy, income in multiple currencies (pay + investments), and an utterly useless export facility from my bank
[01:24] <mrooney> lifeless: oh no multiple currencies yet, although you can csv import
[01:24] <poolie> ah
[01:24] <poolie> yay Vanguard :)
[01:24] <RAOF> Homebank manages the last criterion with reasonable applomb, and the rest are use-cases I've never tried.
[01:24] <lifeless> vanguard?
[01:24] <poolie> the RMS of finance :)
[01:24] <poolie> s/^/John Bogle is/
[01:25] <lifeless> $ apt-cache search vanguard
[01:25] <lifeless> $
[01:25] <lifeless> poolie: did you play with https://edge.launchpad.net/bzr-guess/trunk ?
[01:25] <poolie> http://en.wikipedia.org/wiki/The_Vanguard_Group
[01:25] <jelmer> mwhudson: yeah, in bzr-svn
[01:25] <poolie> featured in his screenshots
[01:25] <jelmer> mwhudson: it can be worked around by installing python-apt
[01:25] <jelmer> s/python-apt/python-tdb/
[01:26] <poolie> lifeless: nup, i only saw the mail so far
[01:26] <mwhudson> jelmer: oh
[01:26] <mwhudson> jelmer: ok, have gdb on a python2.4 segfault
[01:26] <mrooney> anyway I was just poking around looking for UI / intuitiveness opinions / reviews so I can improve it for karmic, let me know if you have any :)
[01:26] <poolie> mrooney: i might try it too
[01:26] <poolie> i use gnucash quite a lot
[01:26] <mrooney> hmm, I suspect you will find it lacking but, let me know what is most lacking
[01:26] <poolie> and can see many ways in which it could be improved up
[01:27] <poolie> upon
[01:27] <mwhudson> jelmer: this is the start of the traceback http://pastebin.ubuntu.com/210848/
[01:27] <poolie> can it do the 'total for this financial period'? i use that a lot
[01:27] <mrooney> poolie: my target audience is people overwhelmed by gnucash or people who want to start tracking finances, so people happy with gnucash will probably find features missing in wxbanker
[01:27] <lifeless> I can tell you what I find most frustrating about most of these tools
[01:27] <lifeless> and thats polish
[01:28] <lifeless> I mean, I can run a double entry system on cards if I want to
[01:28] <lifeless> Simple reports and data entry for that are *not a win*
[01:28] <mrooney> poolie: hm, you can search by date regex, I could also add a start and end date control to the graph
[01:30] <mrooney> I should just add a start and end option in the search, let me do that now :)
[01:31] <poolie> mrooney: to do my tax, i need to answer things like "how much did depreciation of the work-related fraction of my computer equipment cost between 1 jul 08 and 30 jun 09"
[01:32] <mrooney> yeah, that isn't really possible to do in an automated way currently :)
[01:32] <mrooney> it will be soon with recurring transactions, and then searching on those based on description / account
[01:33] <mrooney> but these are already good things to write down :)
[01:37] <poolie> so, for me too, like lifeless
[01:37] <poolie> i am not at all overwhelmed by the double entry concept
[01:37] <poolie> i just wish there was more polish
[01:37] <poolie> oh maybe more speed wbn too
[01:38] <poolie> it takes about a minute to start
[01:38] <poolie> at this rate it would take years to
[01:38] <poolie> at this rate it would take weeks* to boot for Mark :)
[01:41] <garyvdm> I got a question about trees.
[01:41] <poolie> would probably be rewarding to try MYOB or some windows program
[01:41] <poolie> hello gary
[01:41] <garyvdm> Background: for qcommit, the user can select files to be added.
[01:41] <garyvdm> Hi poolie
[01:42] <garyvdm> This only happens when the ok is press, and is achived by running bzr add
[01:43] <garyvdm> We also have a diff button which show a diff of all selected changes.
[01:44] <garyvdm> But due to the design, it does not include the files that the user has selected to be added
[01:44] <garyvdm> Is there a way that I can temporally add files to the working tree without anything being written to disk?
[01:45] <lifeless> no
[01:46] <lifeless> trees don't have a transactional model
[01:46] <lifeless> you could use a preview tree
[01:46] <garyvdm> lifeless: Hi
[01:46] <lifeless> or you could just add the files, and unversion afterwards
[01:46]  * garyvdm looks at preview trees
[01:57] <lifeless> mrooney: I want two key things: planning features: what-if on mortgage, debt management, investment management. And country specific glue - a chart of accounts that dumps everything into the right buckets for AU tax returns
[01:59] <mrooney> lifeless: interesting, I have some budgeting stuff planned so you can add your own lines to the graph, like saying, I want my savings account to grow by 7% plus 10K a year, and see that in comparison to the actual balance
[02:01] <mrooney> so that could work to set debt paying guides as well. the tax stuff sounds more complicated :)
[02:16] <poolie> budgets would be nice
[02:16] <poolie> you could do a lot there
[02:17] <poolie> like if i've budgeted to spend say $x on ugg boots per year
[02:17] <poolie> well, actually for a simpler example
[02:17] <poolie> $x on groceries
[02:17] <poolie> it could show if i'm running a bit high for this month
[02:18] <poolie> but some things are very lumpy, if they're only paid for once per year
[02:18] <poolie> and it could help take that into account too
[02:18] <poolie> for quoted investments i'd like to see the current value compared to what i spent on it
[02:18] <poolie> gnucash could do that, but doesn't
[02:18] <poolie> oh and then you could calculate the irr
[02:34]  * SamB wishes the daily PPA builds would now have versions of form bzr 1.16.1+XXXX
[02:37] <lifeless> SamB: why not 1.17~
[02:38] <SamB> lifeless: well, right now it's 1.16+XXXX
[02:38] <SamB> whereas the latest is "1.16.1"
[02:38] <poolie> i wonder what the trunk currently
[02:38] <poolie> say
[02:38] <poolie> says*
[02:38] <poolie> i noticed that the other day too
[02:38] <SamB> I mean, that's what aptitude thinks is the latest ;-)
[02:39] <lifeless> what is it about GUI help that they all a) want to run a browser and b) want to *not run my default browser*
[02:40] <SamB> lifeless: it's because you aren't using Windows, maybe ;-P
[02:41] <SamB> where they probably have a simple API to run the default browser
[02:47] <mwhudson> jelmer: the subverpy tests pass for me, of course :)
[02:51] <lifeless> kfogel: please put backtraces in bug reports
[02:54] <lifeless> ok deepish hacking mode on; SMS me if you want my attention
[03:09] <lifeless> poolie: install bzr-guess, would like to see what you think
[03:32] <kfogel> lifeless: I did (or so I thought...?)
[03:33] <lifeless> no, you linked to a pastebin site
[03:33] <lifeless> totally useless for reviewing bugmail
[03:34] <lifeless> what I mean is, it adds a lot of latency to the task of figuring out what the bug is
[03:34] <lifeless> because I have to fire up a web page
[03:35] <lifeless> this turns a 5-10 second operation into more like a minute
[03:35] <lifeless> unless its an lp web page
[03:35] <lifeless> in which case its a couple of minutes
[03:36] <kfogel> lifeless: uh, did you see the attachment on the bug?
[03:36] <kfogel> the one that my initial comment said I was attaching, and that I did attach? :-)
[03:37] <lifeless> kfogel: launchpad doesn't forward attachments
[03:37] <kfogel> lifeless: I would happily paste a backtrace directly into the bug desc/comment form *if* that form would give me any clue about what its formatting rules are.
[03:37] <lifeless> kfogel: just paste them, it preserves CR
[03:38] <kfogel> lifeless: CR only?
[03:38] <lifeless> if you paste it will work
[03:38] <kfogel> lifeless: I will try to remember that, but shouldn't have to :-).
[03:39] <lifeless> kfogel: agreed
[03:39] <lifeless> lp should have attached the attachment to the bug mail
[03:39] <lifeless> but what it does is send a separate mail out with the url
[03:39] <lifeless> its very frustrating
[03:40] <kfogel> lifeless: also, not sure how, but your comment comes after a conversation between James and me in which we find out exactly what you said in your comment.
[03:40] <kfogel> Is that because of the "lp bugs don't implement mid-air collision" thing?
[03:41] <lifeless> kfogel: I do bugs via email
[03:41] <lifeless> kfogel: I was replying to your 4:06 comment "This could be related to bug #120930, though I tend to think not, as no"...
[03:41] <kfogel> lifeless: While I appreciate the convenience of an email interface, I do think that makes you more likely to enter into a conversation without having heard what was most recently said.
[03:42] <lifeless> kfogel: be generous in what you accept :)
[03:42] <lifeless> kfogel: for all that you had both decided on bzr-search, I still needed to make the backtrace more visible for me, as i"ll need it when investigating the cause.
[03:42] <lifeless> I had seen all the discussion when I replied
[03:43] <kfogel> lifeless: I think you know all the things I might say at this point in the conversation, so I won't say them :-).
[03:44] <kfogel> Thank you for looking into it, anyway.
[03:44] <lifeless> I haven't yet, but I will
[03:44] <lifeless> oh
[03:44] <lifeless> what bzr-search revno do you have?
[03:45] <lifeless> kfogel: ^
[03:45] <kfogel> lifeless: 70
[03:46] <lifeless> update
[03:46] <kfogel> lifeless: I haven't fetched in a while
[03:46] <kfogel> should I?
[03:46] <kfogel> ok
[03:47] <kfogel> lifeless: commit seems to work now
[03:48] <kfogel> lifeless: closed bug as invalid, therefore
[03:49] <lifeless> kfogel: fixreleased actually
[03:49] <lifeless> kfogel: I've already done it
[03:49] <kfogel> heh!
[03:49] <kfogel> now, even though I'm using the web interface, I did the same thing you did -- I didn't see a previous comment, and therefore had a non-reported mid-air collision.
[03:49] <kfogel> lifeless: ^^
[03:49] <lifeless> one of the things that makes the email interface frustrating actually, is latency
[03:50] <lifeless> theres no good technical reason that smtp events should be any higher latency than http, for in or out.
[03:50] <lifeless> kfogel: well, I closed it by email
[03:50] <kfogel> lifeless: I think the method by which you closed it doesn't matter here -- even if you had done it via web, that problem still would have happened, b/c the bug tracker doesn't do conflict detection.
[03:50] <poolie> hm
[03:51] <lifeless> (time to close, 3 seconds - 1/5th the time to close the web page)
[03:51] <lifeless> kfogel: yes, and it doesn't do real-time update on open views either
[03:51] <poolie> i suspect, without strong evidence, that midair collisions actually do _worse_ than just taking the latest values
[03:51] <kfogel> lifeless: as I said, no argument about the convenience (to that user) of email.
[03:51] <lifeless> kfogel: I filed a couple of bugs last week about the webui in this regard
[03:51] <poolie> let alone taking the latest values of changed fields i
[03:51] <poolie> it's hard to see how that could be true
[03:51] <kfogel> poolie: I've worked with both, and this way is worse.
[03:52] <kfogel> poolie: mid-air collision just means notice the conflict, inform the user, and let them figure out what to do.
[03:52] <poolie> kfogel: both which?
[03:52] <kfogel> the way I just described, and the current way
[03:52] <poolie> oh you mean you'd prefer it gives you an error
[03:52] <kfogel> lifeless: I thought that was an old bug, though?
[03:52] <poolie> like um bugzilla does?
[03:52] <kfogel> poolie: VASTLY
[03:52] <lifeless> kfogel: which-was ? :)
[03:52] <kfogel> poolie: or like every other tracker I've worked with, as far as I know? :-)
[03:53] <lifeless> kfogel: debbugs doesn't.
[03:53] <kfogel> lifeless: that the bug tracker not doing conflict detection is a bug
[03:53] <kfogel> lifeless: ah, good example.  okay, except debbugs (which could, though -- email interface vs web interface has nothing to do with this)
[03:54] <poolie> ok
[03:54] <lifeless> kfogel: I didn't file bugs about c-d, rather about stale-pages.
[03:54] <lifeless> kfogel: if you have a view on e.g. a list of bugs
[03:54] <lifeless> and poolie closes one
[03:54] <lifeless> it would be nice if the list updated
[03:55] <kfogel> lifeless: oh, I see -- yes, great idea
[03:55] <poolie> yes
[03:56] <poolie> a real pony of an idea :)
[03:56] <poolie> btw Black Sheep A+
[03:58] <mwhudson> i watched black sheep on the way back from allhands/uds
[03:58] <lifeless> glad you like it
[03:58] <mwhudson> at one point i had half the cabin crew watching it over my shoulder, which was a bit of an odd experience
[03:59] <lifeless> LOL
[03:59] <kfogel> is this some movie?
[04:00] <thumper> poolie: black sheep isn't that funny
[04:00] <thumper> poolie: certainly a good b-grade movie, but A+? B+ maybe
[04:02] <lifeless> http://en.wikipedia.org/wiki/Black_Sheep_(2007_film)
[04:04] <mwhudson> jelmer: still awake?
[04:05] <lifeless> http://en.wikipedia.org/wiki/Wilhelm_scream wow.
[04:05] <mwhudson> (i hope not)
[04:11] <kfogel> anyone know the bzr flag to ignore ~/.bazaar ?
[04:11] <kfogel> bzr help hasn't turned it up yet, though I'm sure it's there somewhere
[04:11] <thumper> kfogel: are you versioning ~/ ?
[04:11] <thumper> kfogel: bzr ignore .bazaar
[04:11] <kfogel> thumper: Yes.  In Subversion :-).
[04:12] <kfogel> thumper: no, not to ignore for vc
[04:12] <kfogel> thumper: to ignore for running a command
[04:12] <thumper> kfogel: huh?
[04:12] <kfogel>     bzr --behave-as-if-i-had-no-.bazaar-dir
[04:13] <thumper> kfogel: ah
[04:13] <thumper> kfogel: something to do with $HOME or $BZR_DIR
[04:14]  * thumper thinks
[04:16] <spiv> kfogel: perhaps "BZR_HOME=/dev/null bzr ..." ?
[04:17] <lifeless> spiv: will error
[04:17] <spiv> It generates a bit of "No handlers ..." noise on stderr probably due to being unable to initialise the .bzr.log trace file, though.
[04:18] <lifeless> (I think this is a bug) - bzr writes a default ~/.bazaar/ignore on first use.
[04:18] <spiv> Ah, drat, so it does.
[04:18] <spiv> I tried 'bzr whoami', and that worked.
[04:18] <spiv> But actual working tree ops die as you say.
[04:18] <lifeless> kfogel: why
[04:20] <spiv> I guess there's always "tmpdir=$(mktemp -d); BZR_HOME=$tmpdir bzr ... ; rm -r $tmpdir", although you'd need more complexity to preserve the exit code...
[04:20] <lifeless> and still. why?
[04:27] <kfogel> lifeless: I wanted to test some pulls over http and know for sure that my launchpad identity was not affecting them.  I just moved the dir out of the way temporarily, it's no problem.
[05:07] <spiv> Oops, streaming is still generating more root records than IDS.  I guess I need to more ruthlessly reuse more of the IDS logic...
[05:33] <lifeless> spiv: did the test suite catch it?
[05:34] <spiv> lifeless: not directly, I found when digging into a inventory-parents/stacking related failure.
[05:34] <spiv> I'll certainly add a direct test.
[05:34] <lifeless> could you add tests then ?
[05:34] <lifeless> thanks
[05:34] <spiv> :)
[05:34] <lifeless> spiv: direct-interface level would be my preference
[05:36] <spiv> lifeless: I was thinking interrepo test for any non-rr -> rr, with rev1:[] and rev2:[rev1], do a fetch, rev2's inv should have (root-id, rev1) (and corresponding text record).
[05:37] <lifeless> spiv: there's one like that already
[05:37] <spiv> Yeah, I expect so.
[05:37] <lifeless> spiv: rev2's inv should have (root-id, rev2)
[05:37] <itistoday> i have a lightweight checkout that's bound to a bzr:// address, but that address has changed, how do I point the checkout to the new location?
[05:37] <spiv> Hmm.  Really?
[05:38] <fullermd> itistoday: switch
[05:38] <lifeless> spiv: yes, the algorithm is meant to be identical in the presence of ghosts
[05:38] <mwhudson> itistoday: i think you have to edit the .bzr/branch/location file by hand :(
[05:38] <mwhudson> unless that bug has been fixed
[05:38] <lifeless> mwhudson: --force
[05:38] <mwhudson> ah good
[05:38] <lifeless> mwhudson: fixed about a year ago
[05:39] <fullermd> Heck, who has time to keep THAT up to date?
[05:39] <itistoday> fullermd: yeah, doesn't work :-(
[05:39] <itistoday> mwhudson: hmmm... thanks i'll try that... odd that there isn't a command to do this
[05:39] <lifeless> itistoday: there is a command
[05:39] <lifeless> itistoday: bzr switch --force NEWURL
[05:40] <itistoday> lifeless: it doesn't seem to work, i get a connection refused error for the  old location
[05:41] <spiv> lifeless: ah, I see.  So it's actually IDS that's wrong then, not the streaming.  Hmm.
[05:42] <lifeless> itistoday: oh, thats odd.
[05:42] <lifeless> itistoday: what bzr version do you have?
[05:42] <lifeless> spiv: look in log for a commit from me about this
[05:42] <lifeless> spiv: and you'll find the test I wrote for it
[05:42] <itistoday> lifeless: 1.16
[05:43] <spiv> lifeless: will do
[05:43] <itistoday> mwhudson: thanks, that seemed to have worked, although very odd, it will give an error if that file ends in a newline.
[05:43] <lifeless> itistoday: what does 'bzr plugins' report?
[05:44] <mwhudson> itistoday: ah, could have warned you about that
[05:44] <lifeless> we have a test that this works
[05:44] <mwhudson> itistoday: bzr switch --force worked for me though
[05:44] <lifeless> so its being cause by something outside of bzr core, or something unusual
[05:44] <lifeless> bzrlib.tests.blackbox.test_switch, test_switch_lightweight_after_branch_moved
[05:44] <itistoday> lifeless: bzr_push_and_update (0.2dev), bzrtools 1.16, launchpad 1.16, netrc_credential_store 1.16
[05:46] <itistoday> perhaps it's a bug to do with switching from a URL that looks like this: bzr://foo/  => bzr://foo:9990/repo/trunk ?
[05:46] <mwhudson> itistoday: i guess it's too late now (maybe you could copy the tree and mangle the location file in the copy?) but if you can reproduce the problem, could you run with -Derror and pastebin the traceback?
[05:47] <itistoday> mwhudson: it might be easy to turn things back... just by editing that file again, i'll try, one sec
[05:47] <mwhudson> looking at the code i can't see how --force isn't working
[05:47] <mwhudson> unless as lifeless says, switch is being entirely replaced somehow
[05:47] <lifeless> itistoday: also if you can reproduce it, please try 'bzr switch --no-plugins --force NEWURL'
[05:48] <itistoday> lifeless: ok
[05:48] <itistoday> where does the -Derror go?
[05:48] <itistoday> immediately after bzr?
[05:48] <itistoday> or after the command?
[05:48] <mwhudson> anywhere
[05:49] <lifeless> between bzr and the command normally
[05:49] <itistoday> k, able to reproduce, 1 sec
[05:49] <itistoday> what's a good pastie site?
[05:49] <lifeless> rafb.net
[05:49] <lifeless> or paste.ubuntu.com
[05:49] <lifeless> or whatever
[05:50] <mwhudson> spiv: can reproduce the pyflakes problem btw
[05:50] <itistoday> http://pastie.org/535315
[05:52] <itistoday> hope that's helpful
[05:52] <mwhudson> spiv: and fixed it
[05:52] <lifeless> itistoday: it is thanks
[05:52] <lifeless> itistoday: i'll turn it into a bug
[05:53] <itistoday> lifeless: k cool
[05:53] <mwhudson> aaah
[05:53] <spiv> mwhudson: oh, great.  Thanks!
[05:53] <mwhudson> spiv: r29 of my branch
[05:53] <mwhudson> itistoday: the code was expecting "not branch", not "connection refused"
[05:54] <itistoday> mwhudson: sorry, don't really follow, but does that mean you know what the problem was?
[05:55] <mwhudson> itistoday: yes
[05:55] <itistoday> mwhudson: cool :-)
[05:55] <itistoday> btw, is 'cool' still in use today?
[05:55] <itistoday> i come from the past you see...
[05:57] <mwhudson> so do i, in internet terms :)
[05:57] <fullermd> I like living in the past.  I know when to cringe.
[05:57] <thumper> mwhudson: aren't you still under 30?
[05:58] <mwhudson> thumper: no
[05:58] <thumper> well... at least I never used punch cards :)
[05:59] <fullermd> My FORTRAN book instructs me to use punch cards in the exercises...
[06:00] <fullermd> ...  OK, now I have to go see if Google knows who makes a USB card reader...
[06:00] <lifeless> good luck with that search term
[06:01] <mwhudson> haha
[06:06] <fullermd> Whoah.  I should know that doing a search like that is likely to give me even weirder results than what I'm looking for...
[06:06] <fullermd> "Proposed solution: Construct an adapter that interfaces a standard PC USB port to the tape drive interface of the 1401."
[06:06] <fullermd> http://ed-thelen.org/1401Project/IBM_1401_to_PC_Interface_Adapter.html
[06:06] <fullermd> So, just follow those instructions, feed your cards into the 1401, and write them to the tape [PC].
[06:07] <fullermd> All you need is a 1401...
[07:27] <vila> hi all
[07:31] <vila> go away vila , damn ghost mouse events ! I swear I didn't click...
[07:35] <fullermd> Are ghost mice more or less frightening to elephants?
[07:44] <vila> fullermd: far more ! Imagine mouse clicks occurring not even where your pointer is...
[07:44] <vila> elephants just can't support that...
[08:12] <lifeless> night all
[08:13] <vila> night lifeless
[08:17] <poolie> lifeless: are you still here?
[08:18] <poolie> can i now lazily register commands?
[08:18] <poolie> i can certainly be lazy by asking rather than digging more :)
[08:19] <poolie> vila, your comment "Turn test_non_ascii.py test_mv errors into failures." is interesting to me
[08:19] <vila> poolie: hehe, command lazy registering is certainly a continuum :)
[08:20] <poolie> i wonder if at least getting to actual failures rather than other types of exception is a good intermediate step
[08:20] <vila> good, the idea was to either start discussion during review or leave a starting point for a better diagnostic or bug filing
[08:21] <vila> oops, message crossing
[08:21] <poolie> so you did find it useful?
[08:21] <vila> we have the actual failures, but keeping them undiagnosed is counter-productive for the test farm
[08:22] <vila> given that the failures date back to 1.6 ....
[08:22] <poolie> oh, you meant into known failures
[08:22] <poolie> i agree about that
[08:22] <vila> yes, thinking more about it I should just turn the TestSkipped into a KnownFailure
[08:23] <vila> I was thinking about doing that as a tweak during the week-end
[08:26] <poolie> i was thinking about something else which is whether a TestFailure (or whatever it's called) is better than say a TypeErorr
[08:26] <poolie> probably not enough better to be worth making a separate step for it
[08:26] <poolie> um
[08:26] <poolie> regarding TestSkipped etc
[08:27] <poolie> i'd like to overhaul that too
[08:27] <poolie> i think we're missing a couple of useful classes
[08:27] <vila> I don't get it. What TypeError are you talking about ?
[08:27] <poolie> also, marc tardif(?) recently posted about the taxonomy of test failures used by different frameworks
[08:27] <poolie> it might be worth looking at that
[08:27] <poolie> um
[08:27] <poolie> it's just an abstract example-
[08:28] <poolie> i'm talking about the difference between tests that crash when run
[08:28] <poolie> and those that fail with in a specific test assertion
[08:28] <vila> Oh ERROR instead of FAIL
[08:28] <poolie> some people think that failures of the first type are worse than the second type
[08:28] <poolie> right
[08:28] <poolie> i don't think that's that ERROR is worse, or even very different, in our case
[08:29] <lifeless> (program over :P)
[08:29] <lifeless> so I think there is a good concrete difference
[08:29] <lifeless> say you break something
[08:29] <vila> I view ERRORs as compilation issues as opposed to FAIL as run-time issues. The former should indeed occurs only during dev
[08:29] <lifeless> things /testing/ the thing broken are more likely (one hopes) to FAIL, and all the ERRORS are fallout that one can ignore until the FAILures are fixed
[08:29] <lifeless> and probably once the FAILures are fixed the errors will go away
[08:30] <vila> lifeless: interesting counter-example :) I should try that next time, but I'm pretty sure I always try to address the ERRORs first...
[08:32] <poolie> this is kind of a beer question :)
[08:32] <lifeless> poolie: so, re lazy - I don't think its good to have to manually maintain a cache
[08:32] <poolie> so i'm going back to your review then to my code
[08:33] <lifeless> poolie: other than that its all open ;)
[08:33] <poolie> lifeless: i agree, once and only once is better
[08:33] <lifeless> and, try bzr-guess :):)
[08:33] <poolie> ok
[08:33] <poolie> i'd rather have better zsh completion :)
[08:33] <lifeless> fortunately its not an exclusive choice
[08:34] <lifeless> anyhoo - see you all tomorrow
[08:35] <poolie> lifeless: ok, very cute
[08:36] <poolie> vila, +1
[08:36] <poolie> to your osx patch
[08:36] <lifeless> poolie: this might be something to put in core
[08:36] <poolie> which?
[08:36] <lifeless> bzr-guess
[08:36] <poolie> :? maybe
[08:36] <poolie> um
[08:36] <poolie> it's an interesting test case
[08:37] <poolie> i don't know how many people will specifically go out and get it separately
[08:37] <poolie> and it's presumably small
[08:37] <lifeless> distributors could
[08:37] <poolie> otoh people may want it off by default?
[08:37] <lifeless> git has something similar - type 'git inti'
[08:37] <vila> lifeless, poolie : I'd like bzr-guess to be put in core *as a plugin* so that it gives one more plugin example and leave the core code simple
[08:37] <poolie> interesting
[08:37] <poolie> mm
[08:37] <poolie> as i posted a while ago
[08:37] <poolie> i think shipped plugins are probably a bad idea
[08:37] <poolie> merge or merge not
[08:38]  * poolie attempts to get his nose down
[08:38] <lifeless> poolie: I still disagree with you. We have lots of plugin structured code - repo formats, merge handlers etc.
[08:38] <vila> poolie: and thanks for the review
[08:38] <poolie> um
[08:38] <poolie> we might be talking about somewhat different variables
[08:39] <lifeless> not an urgent discussion
[08:39] <lifeless> put your nose down.
[08:39] <poolie> i completely support having it cleanly separated
[08:39] <poolie> through registries or whatever
[08:39] <poolie> actually maybe i mainly care about 'selftest --no-plugins' etc
[08:40]  * lifeless waves
[08:40] <lifeless> lets chat about this later
[10:14] <poolie> vila: would you agree in principle with a patch for bug 391411?
[10:18] <vila> poolie: I agree that it should be part of reconfigure, it would be nice if it works with remote branches too... ha! Yes, bug #391405 already linked
[10:18] <vila> poolie: that will require a bunch of tests though...
[10:23] <poolie> vila, i was hoping to tackle that later
[10:23] <poolie> i think they can be fixed separately
[10:23] <poolie> i was hoping for fairly small smoke tests at the ui layer
[10:23] <poolie> at least for this one it should be mostly a matter of using apis that are already there
[10:24] <vila> poolie: can't you raise NotLocalUrl until your address the problem ?
[10:27] <Youssef> Hi guys!!!
[10:27] <Youssef> I come to report a litte bug!!!!
[10:28] <Youssef> Who want to liste to me...?
[10:29] <vila> Youssef: https://bugs.launchpad.net/bzr/+filebug !!! :-)
[10:29] <Youssef> lol
[10:29] <Youssef> im already there
[10:29] <Youssef> lol
[10:29] <Youssef> :D
[10:30] <vila> Youssef: otherwise: ask, don't ask to ask !!!
[10:30] <vila> Until you ask, nobody knows if he/she can answer
[10:30] <Youssef> :P
[10:31] <vila> poolie: the LockNotHeld in a stacking env reminds me of jam encountering the same kind of problem...
[10:32] <vila> poolie: I vaguely remember him sending a patch even... not sure it landed though
[10:49] <poolie> hm
[10:50] <poolie> well, if you can find it that would be nice
[10:50] <poolie> i'm not sure what you mean about NotLocalURL
[10:50] <poolie> that i could make it work only locally at first?
[10:50] <poolie> i guess so
[10:56] <vila> poolie: yes, make it work locally first
[10:59] <poolie> any idea about that patch for the unlock error?
[11:02] <vila> poolie: from jam you mean ?
[11:02] <poolie> yeah, for the problem jam reported
[11:02] <poolie> just if you happen to have it
[11:03]  * vila doing a quick search
[11:06] <vila> poolie: [MERGE] Cleanups for fallback repos and stacking is what I had in mind
[11:06] <vila> poolie: so I think this has landed, but you may still find it inspiring
[11:07] <vila> poolie: part of 1.16
[11:08] <vila> poolie: hmm, just see your comment, you may be right about the branch not having a stacking-on branch anymore
[11:13] <poolie> hm, i'm working off today's trunk
[11:14] <Pilky> poolie: hey, just read your reply
[11:15] <Pilky> I've tried --xml before but the big issues I've had is that going through the main UI makes working with push, pull, branch etc awkward as getting the progress and giving the authentication credentials is very hacky
[11:18] <Pilky> it also seems like bzr-eclipse have the same issue
[11:21] <poolie> vila, i'm running out of concentration, i think i'll leave it there for today
[11:21] <poolie> i think that fix won't be very hard
[11:21] <poolie> Pilky: ok, so how about just keeping a compatible licence and then dealing with what arises?
[11:23] <Pilky> could work, I mean would it be a huge problem with the API being LGPL. I'm not planning on modifying bzr itself, the API will be designed to work with the standard bzr implementation
[11:23] <Pilky> I just want something that would allow others to use the API in any sort of app, open or closed source
[11:23] <vila> poolie: ok, lunch time for me anyway, cu
[11:24] <Pilky> as I think it could really help get bzr support into many tools on the Mac
[11:24] <poolie> i guess it just seems a bit speculative to me
[11:24] <poolie> changing licence is a big deal and basically irrevocable
[11:24] <Pilky> yeah
[11:25] <poolie> and the question of lgpl vs gpl is hard to understand for python code
[11:25] <poolie> i'd definitely like to see good support in xcode and other mac apps, certainly
[11:26] <Pilky> well the idea is for me to write the API in PyObjC and bundle it in a framework
[11:26] <poolie> well
[11:26] <Pilky> of course the issue is I'll be looking at bzrlib.builtins to learn how to use bzrlib
[11:26] <poolie> i'll talk to other people here about it
[11:27] <Pilky> ok cool
[11:27] <poolie> um
[11:27] <Pilky> yeah
[11:28] <poolie> i think this is going to be a lot more convincing if there's already a good mac ui and people are then saying "we'd like to integrate with $app but we need $thing"
[11:29] <poolie> than just 'will you change your licence?' right from the word go
[11:29] <Pilky> yeah
[11:29] <poolie> i think if there's an objc api that provides a similar level of functionality but that can be called as a component
[11:29] <poolie> in principle that should be fine
[11:30] <Pilky> ok
[11:30] <poolie> but, maybe there's some good mechanism like the os x Services rpc (the details are rusty) that actually turn out to be a better way to integrate
[11:31] <Pilky> well one way that is in the back of my mind is to make the Obj-C API into a separate binary and then use distributed objects to communicate between the two processes
[11:31] <Pilky> much more complicated that I'd like but it satisfies the GPL
[11:32] <poolie> ok
[11:32] <poolie> well,
[11:33] <poolie> work on the objc library and we'll see how it comes out
[11:33] <poolie> good night
[11:33] <Pilky> ok, ttyl
[11:39] <bialix> lifeless: https://bugs.launchpad.net/bzr/+bug/285055/
[15:16] <jam> morning vila
[15:16] <vila> morning jam !
[16:07] <LarstiQ> lifeless: could it be that I no longer have PQM access? I'm not seeing any rejection mails, but it did show up on http://pqm.bazaar-vcs.org/
[16:26] <vila> LarstiQ: what are your public and parent branches (precise URLs as shown by bzr info) ?
[16:27] <LarstiQ> lp:~larstiq/bzr/reinvoke-2.6 and /home something, but I specified --submit-branch=http://bazaar-vcs.org/bzr/bzr.dev
[16:27] <mozmck_work> question: if I have used bzr init to put a project under bzr, can I later change it to a shared repository?
[16:27] <Peng_> mozmck_work: Yes, using "bzr reconfigure".
[16:28] <Peng_> I think. Even if not, you could still do it; it'd just take a little more work.
[16:28] <vila> LarstiQ: don't use lp branches
[16:29] <vila> LarstiQ: convert them to their http equivalent, there seems to be one bug related to lp that keeps coming and going ...
[16:29] <mozmck_work> Peng_: thanks
[16:29] <LarstiQ> vila: k, will try that
[16:35] <LarstiQ> vila: it seems to be running
[16:35] <vila> LarstiQ: ping spiv, I think he's the last who encounter that kind of problem
[16:36] <vila> LarstiQ: by the way, do you know how to automatically start ssh tunnels ?
[16:37] <LarstiQ> vila: automatically? /me feels he is missing context
[16:37] <LarstiQ> vila: I've got a jumphost setup though
[16:38] <LarstiQ> vila: http://blog.ganneff.de/blog/2007/12/15/using-a-ssh-jumphost.html
[16:38] <vila> LarstiQ: from my laptop I use local forwarding to my desktop for smtp, but that requires me to manually initiate an ssh connection or starting the tunnel manually,
[16:38] <spiv> LarstiQ: last time I tried lp: URLs weren't working with PQM, I need to pester spm about that again.
[16:39] <vila> wow, good night spiv :-)
[16:39] <spiv> LarstiQ: try setting the public_location for your branch to http://...
[16:39] <spiv> vila: yeah, I know... I'm about to sleep :)
[16:39] <LarstiQ> spiv: I did, PQM is rrunning the tests now :)
[16:39] <spiv> LarstiQ: ok, good, it's still that problem then :)
[16:39]  * spiv -> land of zzz
[16:41] <vila> LarstiQ: now I'd like these tunnel to be up when I need it so I'd like to put it in a @reboot cron entry, but ssh ask for my password at that time instead of waiting for a connection on the local port
[16:42] <LarstiQ> vila: ah, right
[16:42] <LarstiQ> vila: I believe mutt has some support for setting up ssh tunnels
[16:43] <LarstiQ> personally I deliver over tlsed port 587
[16:43] <vila> LarstiQ: ok, more context :-) I said mail but I want to do that other uses so I'd like a ssh-only solution if possible :-)
[16:44] <vila> s/other uses/for other uses/
[16:44] <LarstiQ> vila: you could use an openpgp card with an auth key and then pinentry-qt for the passphrase, to deal with the password prompting?
[16:44] <vila> no
[16:46] <vila> my two problems are: 1) starting without password or reliably delay until the ssh agent is up, 2) restart if the connection is lost
[16:47] <vila> I wonder I should wrap the process in python script myself or if there is already some solution I can't think about :-/
[16:47] <vila> jam: didn't you use ssh tunnels yourself ?
[16:48] <rocky> is there anyway to specific file ignores for stuff on your own local workstation such that they don't have to get committed with .bzrignore ? (ie inside bazaar.conf)
[16:49] <vila> rocky: there is a global ignore file alongside bazaar.conf
[16:49] <rocky> heh
[16:49] <rocky> too obvious =P
[16:50] <vila> rocky: sometimes it helps to think: "If I were programming that tool, I'd put that feature here" and just go checking :)
[16:51] <vila> sometimes it doesn't though, like my ssh tunnels :-D
[16:51] <jam> vila: Sometimes
[16:52] <jam> I didn't quite see what was going wrong (network went flakey)
[16:52] <vila> jam: don't tell me you use an ssh tunnel for chatting :
[16:52] <vila> :) Ooops, typo in smileys now :)
[16:52] <jam> *I* don't
[16:53] <jam> I believe Robert uses a remote IRSSI correction
[16:53] <vila> jam: Do you use ssh tunnels for anything ?
[16:53] <jam> Mostly for sending mail when I'm away from home
[16:53] <vila> jam: do you start manually or automatically ?
[16:53] <jam> manually
[16:54] <vila> I'd like to automate that (I now have three of them smtp/ssh/buildbot)
[16:55] <vila> I used to start the smtp one manually by issuing an ssh connection and declaring the local forwarding in ssh/config, I've seen that I can do: "ssh -L port:host:port -N&",
[16:55] <vila> but I still need to issue that manually and the process errors out under some conditions
[16:55] <vila> so,
[16:56] <vila> my two problems are: 1) starting without password or reliably delay until the ssh agent is up, 2) restart if the connection is lost
[16:56] <vila> jam: thoughts ?
[16:57]  * awilkins uses an SSH tunnel for chat, what's wrong with that?
[16:57]  * awilkins uses SSH tunnels for many things
[16:58] <vila> awilkins: do you know how to start them while addressing my 2 points above ?
[16:58] <awilkins> I have 2 mins until train, I shall look briefly but may speak later
[16:58] <vila> ok
[16:59] <awilkins> vila: Yes you can define port forwarding in .ssh/config
[16:59] <awilkins> hMM
[16:59] <vila> awilkins: been there, done that, want more :)
[16:59] <awilkins> Not sure this is issue but now must run
[17:23] <jam> vila: I've seen people do stuff like "ssh-add -l" to determine if keys have been added to the agent.
[17:23] <jam> As for "wait until agent starts", isn't it enough to just put your script as starting after the ssh-agent script starts?
[17:23] <jam> you could also use a script like
[17:24] <jam> ps -efww | grep "ssh.*-L..."
[17:24] <jam> to check if your process is running
[17:24] <jam> and then add something into cron that checks
[17:24] <jam> if [ssh-add -l] and not [ps -efww | grep "ssh.*-L..."]; then ssh ... -L
[17:24] <jam> Though I might wrap the complex logic into a python script
[17:27] <vila> jam: I need to use that from various OSes, so the ssh agent... is not well standardized :-/ But thanks for the hints (ssh-add -l may works everywhere)
[17:27] <jam> vila: ssh-add is present under Cygwin...
[17:28] <jam> and -l works here
[17:28] <jam> and fails with an error if the ssh-agent isn't available, etc.
[17:28] <vila> As for cron checking, I'm always a bit uncomfortable with scripts that starts again even if *I* stop them :-)
[17:29] <vila> ssh-add -l works well on OSX too
[17:29] <jam> vila: well, you just asked for it to restart if you drop a connection
[17:29] <jam> cron works well for that
[17:29] <jam> you can write your *own* cron replacement as a python script...
[17:29] <jam> but blah
[17:30] <jam> just create something like a "proc.no-autorun" or "proc.stop" file
[17:30] <jam> and have that checked as well.
[17:30] <vila> but cron is hard to stop or easy to forget to stop, I ran into the issue with my croned fetchmail (restarted every hour)
[17:33] <vila> jam: thanks for your answer, I'm searching for something easier to setup (I can handle hacks but I want it to be easy for others), so all your advices are good but make me think there is no known and supported packaged solution :-/
[17:33] <vila> jam: I think I'm more into #3 at http://www.debian-administration.org/article/SMTP_via_a_SSH_tunnel
[17:34] <vila> aka special ssh private/public key without password and start at connection
[17:35] <jam> vila: interesting thought. Though starting an ssh connection for each time you want to send an email seems a bit heavyweight
[17:36] <jam> I suppose if you have a local MTA it would probably work quite well
[17:36] <jam> since it would likely send things in batches.
[17:37] <vila> jam: I have indeed a local MTA and for the other uses I don't mind establishing an ssh connection
[17:38] <vila> but I want that connection to be established automatically :-)
[18:27] <LarstiQ> vila, spiv: pqm success, so yeah the lp: url seemed to be the culprit
[19:49] <nbauernf> Can anyone explain to me what might be going on with this:? $ bzr branch http://mc.pp.se/bzr/ps3sdk
[19:49] <nbauernf> bzr: ERROR: Invalid http response for http://mc.pp.se/bzr/ps3sdk/: Unable to handle http code 501: Not Implemented
[19:51] <mzz> nbauernf: works for me. Which bzr?
[19:51] <nbauernf> mac osx
[19:51] <Tak> I get the same result as nbauernf
[19:51] <mzz> nbauernf: more interested in the version number :)
[19:51] <nbauernf> v 1.16.1
[19:51]  * Tak bzr 1.16.1
[19:51] <mzz> huh, 1.16.1 here too. Got pycurl?
[19:52] <mzz> (I think I don't, checking...)
[19:52] <nbauernf> mzz: what can I do to reasonable check for pycurl?
[19:52] <mzz> sec
[19:52] <nbauernf> reasonably*
[19:53] <Tak> same result after installing pycurl
[19:53] <nbauernf> I'm able to checkout the http bzr repository of bzr
[19:53] <nbauernf> i.e. this works:  bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev
[19:53] <mzz> ~/.bzr.log (or wherever that lives on your os) may be interesting
[19:54] <Tak> http://paste2.org/p/307245
[19:55]  * LarstiQ gets the 501 with bzr.dev
[19:55] <LarstiQ> it almost sounds like that is intermittent
[19:56] <nbauernf> I have the same problem as in Tak's paste
[19:56] <Tak> is this an svn repo or a bzr repo?
[19:56] <nbauernf> LartsiQ: I get it consistently with httphttp://mc.pp.se/bzr/ps3sdk/
[19:56] <LarstiQ> Tak, nbauernf: do you have bzr-svn?
[19:56] <Tak> yes
[19:56] <nbauernf> I don't think I do
[19:57] <LarstiQ> --no-plugins and it works
[19:57] <Tak> interesting - I tried bzr+http and got a 404
[19:57] <LarstiQ> nbauernf: `bzr plugins` will tell you
[19:58] <nbauernf> yeah --no-plugins works
[19:58] <nbauernf> Thanks!!
[19:58]  * Tak also @ --no-plugins
[19:58] <LarstiQ> nbauernf: mind filing a bug against bzr-svn?
[19:59] <nbauernf> hmm this is the first time I've ever used bzr, but I don't mind if I can find the bug tracking system
[19:59] <RenatoSilva> how do I run tests?
[20:00] <mzz> RenatoSilva: bzr help selftest
[20:00] <RenatoSilva> mzz: it's a plugin
[20:00] <LarstiQ> nbauernf: http://bugs.launchpad.net/bzr-svn
[20:00] <LarstiQ> RenatoSilva: same thing
[20:00] <mzz> RenatoSilva: I am insufficiently bored to figure out how to run the tests specific to your plugin, sorry
[20:01] <mzz> RenatoSilva: (also, I'd have to assume I'm correctly guessing this is still about xmloutput)
[20:01] <LarstiQ> bzr plugins usually (and should, imnsho) have their testsuite run via bzr selftest
[20:01] <LarstiQ> RenatoSilva: see -s and bp.xmloutput
[20:02] <LarstiQ> if that is indeed the plugin you have in mind
[20:03] <mzz> I think I just wildly guessed "bzr selftest xmloutput" would do something reasonable, and it did
[20:03] <LarstiQ> mzz: it does
[20:03] <RenatoSilva> mzz: I figured out that the plugin registers itself, I can run them with selftest <registered_name>
[20:03] <mzz> this is often the case with bzr :)
[20:03] <LarstiQ> mzz: -s bp.<pluginname> will restrict the tests to be loaded to that plugin
[20:04] <RenatoSilva> mzz: yes, xmloutput, Guillermo asked me to write tests for my branch proposal, I'm trying to achieve this
[20:04] <LarstiQ> so it's a bit quicker cycle if you're developing a plugin
[20:06] <Pilky> anyone know if the developer(s) of bzr-eclipse come in here?
[20:07] <RenatoSilva> LarstiQ: I'm sorry I'm new to bzr tests, I don't get what you said about -s and bp.*
[20:07] <RenatoSilva> LarstiQ: I run the tests with bzr selftest <test_name>
[20:08] <verterok> RenatoSilva: hi!
[20:08] <RenatoSilva> there are some test failures
[20:08] <RenatoSilva> verterok: hi, who are you :) ?
[20:09] <verterok> RenatoSilva: Guillermo
[20:09] <RenatoSilva> verterok: oh!
[20:09] <RenatoSilva> verterok: nice to meet you
[20:09] <verterok> RenatoSilva: nice to meet you too
[20:09] <verterok> Pilky: shoot, I'll be around a bit
[20:10] <LarstiQ> Pilky: verterok?
[20:10] <Pilky> ah cool
[20:10] <LarstiQ> RenatoSilva: `bzr selftest -s bp.xmloutput`
[20:10] <RenatoSilva> verterok: as I said, I'm new to bzr tests...
[20:10] <verterok> LarstiQ: heya! how are you?
[20:10] <LarstiQ> Pilky: there are two Eclips projects though, the other is Nick Allen, who doesn't irc (much)
[20:10] <RenatoSilva> LarstiQ: what does that command do?
[20:11] <LarstiQ> RenatoSilva: so when you say `bzr selftest <pattern>` bzr loads _all_ tests, filters down to ones matching <pattern> and runs those
[20:11] <Pilky> verterok: I'm just wondering how you guys get around the problems with authentication and getting progress information from push/pull/branch actions without using bzrlib
[20:11] <verterok> RenatoSilva: I ussually do: BZR_PLUGINS_PATH=/path/to/branch/parent bzr selftest xmloutput
[20:11] <LarstiQ> RenatoSilva: when instead you say `bzr selftest -s bp.<plugin>` it will only load the tests for that plugin.
[20:11] <LarstiQ> RenatoSilva: on my hardware, that saves a couple of minutes
[20:11] <LarstiQ> verterok: good, thanks :) Just been to EuroPython, adjusting again now
[20:12] <Pilky> verterok: because I think I've got an idea that can let me use bzrlib and get around the GPL but it seems a tiny bit hackish so I was wondering if you guys had come up with anything
[20:12] <LarstiQ> Pilky: have you talked with Martin Pool yet?
[20:12] <verterok> Pilky: I basically lie a bit a about progress :)
[20:13] <RenatoSilva> LarstiQ: I see, it could check if it's a plugin name and internally run the -s bp.
[20:13] <Pilky> LarstiQ: yep, he basically said it is better to having something to show before they could consider anything about licences, but since I talked to him this morning I think I've come up with a way to get around licensing issues
[20:13] <LarstiQ> RenatoSilva: eh, no
[20:13] <verterok> Pilky: regarding auth there is a bug since the start, but bzr-eclipse only supports bzr+ssh if the user previously added the ssh key to an agent
[20:13] <LarstiQ> Pilky: ah ok, good
[20:13] <Pilky> verterok: right
[20:13] <verterok> Pilky: what are you working on? :)
[20:14] <Pilky> an Objective-C API for bzr
[20:14] <RenatoSilva> LarstiQ: that -s xxx is hard to remember
[20:14] <LarstiQ> RenatoSilva: the pattern is very useful for finer or wider grained matching
[20:14] <Pilky> but I want it to be MIT licensed so non GPL projects can use it
[20:14] <Pilky> as ultimately I want to write an MIT licensed GUI for bzr on the Mac
[20:15] <verterok> Pilky: I'ld suggest using xmloutput, but it sucks compared to pure python :)
[20:15] <Pilky> well, I have come up with a plan to allow me to use both
[20:15] <Pilky> xmloutput is fine for stuff like logs, annotations etc
[20:16] <Pilky> but pure python is better for push, pull etc
[20:16] <Pilky> the only problem is the pesky GPL ;)
[20:16] <verterok> Pilky: what about splitting the project into library and UI, once you have the library bits solved, you can try to fix the licensing issues
[20:16] <verterok> Pilky: oh, linking... forget what I said :)
[20:16] <Pilky> well I'm planning on doing the library first and then building the UI on top of it
[20:17] <Pilky> but yeah, my idea might possibly help you as well
[20:18] <Pilky> we can do the xmloutput thing and not have to GPL our code because you can talk to a separate binary that is GPLd without having to GPL your code
[20:18] <Pilky> so my idea is, where I have to talk to bzrlib directly through python, create a separate binary
[20:18] <Pilky> then use distributed objects from my main API to talk to that binary
[20:18] <Pilky> the separate binary is GPL licensed
[20:18] <Pilky> the main API is MIT licensed
[20:19] <verterok> Pilky: I already found a very non-xml solution, you could use xmlrpc to pass python objects around, bypasing all the manual xml generation
[20:19] <verterok> s/very/very nice/
[20:19] <Pilky> hmm
[20:19] <verterok> and you keep python on both sides
[20:19] <RenatoSilva> verterok: about bug 393010: the message comes from server as python-like str encoded as utf-8, it is being parsed by KXML lib and returned to bzr-java-lib's log parser as latin-1, something like new String(msg_bytes, getWorkspaceEncoding()), instead of getXMLEncoding().
[20:20] <Pilky> verterok: well I'm planning on using PyObjC when I need to talk to python so I can convert the Python object to Objective-C fairly easily and vice versa
[20:20] <LarstiQ> Pilky: did I already ask why you don't want to GPL your code?
[20:20] <verterok> Pilky: the downside is the need to almost rewrite every commands
[20:20] <Tak> it seems as though xmlrpc is still "linking"
[20:20] <Pilky> LarstiQ: because GPL is a horrible licence for APIs
[20:21] <LarstiQ> Pilky: I see what you mean, what API are you writing?
[20:21] <verterok> RenatoSilva: uh, I think to remember a workaround I did some time ago, about wrapping all the xml in a xmlrpclib.Binary object
[20:21] <Pilky> LarstiQ: an Objective-C "wrapper" for talking to bzr
[20:21] <verterok> RenatoSilva: to work around the java-python encoding mismatch
[20:22] <Pilky> so Mac developers can add support for bzr to apps such as text editors and such much more easily
[20:22] <verterok> RenatoSilva: with the latest changes we worked in the last days, that might not be neccesary any more
[20:22] <LarstiQ> Pilky: you think for this specific case the GPL is actually a hurdle?
[20:22] <RenatoSilva> verterok: a possible workaround while KXML is not fixed is to get the message bytes again, and create a new String using utf-8 (or whatever macthes the commit message returned by the server)
[20:22] <Pilky> LarstiQ: well, yes as if a library is licensed under the GPL then linking to it requires the linking application to also be GPL
[20:22] <Pilky> if it was LGPL it wouldn't be too much of an issue
[20:23] <LarstiQ> Pilky: yes, that is theory though
[20:23] <verterok> RenatoSilva: all the xml is sent inside a Binary, so it's hidden from kxml
[20:23] <Pilky> theory and also what the license says ;)
[20:23] <LarstiQ> Pilky: yes :P
[20:23] <Pilky> plus the minute I put "GPL" on the licence for the product lots of developers run for the hills ;)
[20:23] <LarstiQ> Pilky: but so far there are very little people wanting to integrate bzr in their application
[20:23] <verterok> RenatoSilva: I think the missing  bit is the conversion to the correct encoding in the Java side
[20:24] <LarstiQ> Pilky: anyway
[20:24] <Pilky> LarstiQ: true, but that is partly due to the fact that bzr isn't quite as popular as git on the Mac
[20:24] <Pilky> and the fact that svn is currently the easiest to integrate into an app
[20:24] <goundy> Hi.
[20:24] <LarstiQ> Pilky: no, I mean, overall, anywhere
[20:24] <goundy> How to remove a file from source control ? thank you.
[20:24] <LarstiQ> Pilky: right
[20:24] <LarstiQ> goundy: `bzr rm`
[20:25] <goundy> LarstiQ, bzr rm deletes the file from the hard drive :/
[20:25] <goundy> I just want to kick it from source control
[20:25] <verterok> goundy: bzr rm --keep
[20:25] <goundy> verterok, thank you very much
[20:25] <LarstiQ> Pilky: anyway, if your current plan doesn't pan out, you could write your wrapper, license it under the GPL, and lobby to get bzr relicensed, and relicense when that goes trhough.
[20:25] <goundy> LarstiQ, thank you too
[20:25] <RenatoSilva> verterok: maybe KXML is just returning a new String(msg_utf8_bytes). As they probably use Linux, they didn't get any error. However in my case, Java preferred encoding is not UTF-8 but latin-1 (cp1252), so that it tries to decode the bytes as latin-1 and then I see the wrong chars. KXML should explicitly specify the encoding for the string.
[20:25] <LarstiQ> Pilky: as from my pov it will be useful even if not MIT licensed
[20:26] <LarstiQ> goundy: also see `bzr help rm`
[20:26] <goundy> thanks ! :)
[20:26] <goundy> See you
[20:26] <Pilky> LarstiQ: well hopefully my plan will pan out, though it'll take a while as I'll only be working on it a day or two a week, got the day job to work on the rest of the week ;)
[20:26] <LarstiQ> RenatoSilva: eh? If not otherwise specified isn't the xml encoding always utf8?
[20:27] <LarstiQ> Pilky: aight
[20:27] <Pilky> I'm hoping to have the API in a fairly usable state by the end of summer
[20:27] <verterok> RenatoSilva: do you have the bzr-java-lib sourcecode?
[20:27] <RenatoSilva> verterok: do you mean it's not KXML who is parsing the server CDATA and creating the corresponding bytes?
[20:28] <RenatoSilva> verterok: not in hand
[20:28] <verterok> RenatoSilva: yes, little and dirty hack :p
[20:28] <verterok> RenatoSilva: let me find you the url, but the file is: src/main/java/org/vcs/bazaar/client/xmlrpc/internal/XMLRPCCommandRunner.java line 161
[20:31] <verterok> RenatoSilva: http://bazaar.launchpad.net/~verterok/bzr-java-lib/bzr-java-lib/annotate/head%3A/src/main/java/org/vcs/bazaar/client/xmlrpc/internal/XMLRPCCommandRunner.java
[20:32] <verterok> RenatoSilva: by default it's doing new String(result.getBinary(1))
[20:32] <verterok> RenatoSilva: but that method should be deprecated for the one in line 161
[20:32] <RenatoSilva> verterok: public String getStandardOutput(final String charsetName)?
[20:32] <RenatoSilva> verterok: it was not running in my debug session
[20:32] <RenatoSilva> verterok: And I was running it very times
[20:34]  * RenatoSilva was disconnected
[20:34] <verterok> RenatoSilva: the base COmmand class use public String getStandardOutput() by default
[20:35] <Peng_> RenatoSilva: You didn't miss anything.
[20:35] <verterok> RenatoSilva: I think that we should change that to: public String getStandardOutput(final String charsetName)
[20:36] <RenatoSilva> verterok: I was talking about this line: http://bazaar.launchpad.net/%7Everterok/bzr-java-lib/bzr-java-lib/annotate/head%3A/src/main/java/org/vcs/bazaar/client/commandline/parser/XMLLogParser.java#L123
[20:36] <RenatoSilva> verterok: parser.nextText() is KXML
[20:37] <RenatoSilva> verterok: it is returning a String (in python it's like an u'')
[20:37] <RenatoSilva> verterok: with wrong chars...
[20:37] <verterok> RenatoSilva: yes, I think it's because the string parsed by kxml is the one returned by Command.getStandardOutput
[20:37] <verterok> RenatoSilva: and Command.getStandardOutput don't specify any charset, so I think Java is using the default one
[20:40] <verterok> RenatoSilva: this line: http://bazaar.launchpad.net/~verterok/bzr-java-lib/bzr-java-lib/annotate/195.2.11/src/main/java/org/vcs/bazaar/client/commandline/CommandLineClient.java#L317
[20:41] <verterok> RenatoSilva: My guess is that the xml log parser is receiving a bad string, and so the nextText() call is returning that
[20:41] <RenatoSilva> verterok: I checked it out, the message in server response is something like <![CDATA[Ma\xc3\xa7\xc3\xa3]]> encoded as base64, but parser.nextText is not decoding from UTF-8. As I said, KXML (or something in the call hierarchy) should be doing something like new String(bytes) (which decodes from UTF-8 for the developers) instead of new String(bytes, "UTF-8") (which explicitly decodes from UTF-8 all the time)
[20:42] <verterok> RenatoSilva: that should be in the line I just pointed out, just before passing the stdout string to the XMLLogParser
[20:43] <verterok> RenatoSilva: http://bazaar.launchpad.net/~verterok/bzr-java-lib/bzr-java-lib/annotate/195.2.11/src/main/java/org/vcs/bazaar/client/commandline/CommandLineClient.java#L317
[20:43] <RenatoSilva> verterok: comparing to python... imagine you received the utf-8 bytes from server: 'Ma\xc3\xa7\xc3\xa3'
[20:43] <verterok> RenatoSilva: I'm missing something?
[20:44] <RenatoSilva> verterok: it's like nextText() is returning a 'Ma\xc3\xa7\xc3\xa3'.decode('latin-1') or .decode() (from prefered encoding)
[20:44] <verterok> RenatoSilva: hmm, weird, I must debug it, but I believe you :)
[20:46] <verterok> RenatoSilva: kxml is doing: new String(bytes)
[20:48] <RenatoSilva> verterok: put a breakpoint in the line I mentioned, you'll see that the string is already wrong in that point, check also the server response. It was a bit hard to me as it comes into an InputStream. I had to hunt the buffer (is isnisde is inside is...), then I put the bytes in a Java test file and decoded. As it is base64, then I run python and decoded the response, Then I got the XML with the mentioned CDATA.
[20:49] <RenatoSilva> verterok: do you have kxml source? ok, just like I imagined...
[20:50] <verterok> RenatoSilva: yes, maven do all kind of neat tricks ;)
[20:50] <verterok> RenatoSilva: I'm fireing up eclipse, to start the debug session, give me a few minutes :)
[20:53] <RenatoSilva> verterok: ok, just to point it out for a possible fix in KXML: I don't know how can it guess the CDATA encoding, as it is pure ascii...
[20:53] <verterok> RenatoSilva: I don't think it's kxml job to do that, bzr-java-lib should know what to do with those bytes
[20:55] <RenatoSilva> verterok: ok I just think it's a bit weird to decode, then encode, then decode again, but ok...
[20:55] <verterok> RenatoSilva: agreed!
[20:55] <RenatoSilva> verterok: in this case bzr-java-lib should somehow know what is the encoding of such CDATA
[20:55] <verterok> RenatoSilva: what do you suggest?, not encoding at all in the xmloutput side?
[20:55] <verterok> RenatoSilva: as you mentioned in one of the bugs
[20:56] <verterok> RenatoSilva: we could send all utf-8 encoded data over "the wire"
[20:56] <RenatoSilva> verterok: I think that static encoding may be better. In this case, you can trust that the CDATA is always UTF-8
[20:57] <LarstiQ> who is producing the CDATA?
[20:57] <verterok> RenatoSilva: that's the way it should be working today, at least in 0.8.4 utf-8 is hardcoded in the xmlrpc server
[20:57] <verterok> LarstiQ: bzr-xmloutput
[20:58] <verterok> LarstiQ: actually, the xmlrpc server in bzr-xmloutput
[20:58] <RenatoSilva> verterok: you mean just the preamble right?
[20:58] <LarstiQ> verterok: ok, from what source? bzr historical data, or also files on disk?
[20:58] <verterok> RenatoSilva: the stdout encoding is changed to utf-8
[20:58] <verterok> LarstiQ: both
[20:59] <NfNitLoop> *siiiiiiigh*  reading all the caveats to svn 1.5 merging makes me miss bzr. :)
[20:59] <LarstiQ> verterok: ah, that complicates matters a bit
[20:59] <LarstiQ> NfNitLoop: you don't have to ;)
[20:59] <RenatoSilva> verterok: because it's always utf-8, but the actual data is the terminal encoding. This way when I run bzr xmlstatus I get a header <?xml ... encoding="utf8"?> but the data itself is cp850...
[21:00] <RenatoSilva> LarstiQ: btw, does bzr stores its metadata always as UTF-8?
[21:00] <NfNitLoop> LarstiQ: Unfortunately I do.  I don't think bzr-svn handles some of the SVN features we're relying on.
[21:00] <verterok> RenatoSilva: that was a bug, when running xmlstatus from the terminal, I pushed a branch to fix that (utf-8 was hardcoded in the preamble)
[21:00] <verterok> RenatoSilva: the xmlrpc service is a different story :)
[21:01] <verterok> RenatoSilva: take a look to the decorator defined in line 87 of service.py,
[21:01] <LarstiQ> RenatoSilva: yes.
[21:01] <LarstiQ> NfNitLoop: ah, which would that be?
[21:01] <RenatoSilva> verterok: so when you said it was always using utf-8, it was just the header right?
[21:02] <verterok> RenatoSilva: the commands executed via xmlrpc are executed, with  utf-8 as the user encoding, and stored in a StringIO instead of redirecting the stdout output
[21:03] <verterok> RenatoSilva: the idea is to always use utf-8 in the xmlrpc calls
[21:04] <RenatoSilva> verterok: oh I didn't understand that part, I'm sorry. I just noticed that the final result I receive is variable encoding...
[21:05] <verterok> RenatoSilva: the utf-8 is set as the user encoding when the xmlrpc server starts, in the serve_forever() method, service.py line 74
[21:06] <RenatoSilva> verterok: you mean to decode client commands?
[21:07] <verterok> RenatoSilva: for all other operations that use osutils.get_user_encoding()
[21:07] <verterok> RenatoSilva: the osutils._cached_user_encoding and bzrlib.user_encoding are updated
[21:07] <RenatoSilva> verterok: and how the response gets its encoding changed? (as I said, I receive cp850 data)
[21:08] <verterok> RenatoSilva: that's the weird part, looks like a bug in service.py
[21:08] <RenatoSilva> verterok: if it's always using utf-8, I should receive utf-8, but I receive cp850
[21:09] <RenatoSilva> verterok: oh...
[21:09] <verterok> RenatoSilva: you could easily test this wihtout putting bzr-java-lib in the middle, there is a client.py file in the xmloutput tree to call the xmlrpc service via python
[21:09] <verterok> RenatoSilva: a lot easier to debug ;)
[21:09] <RenatoSilva> verterok: well, somewhere it is getting the terminal encoding ont the one you had set when starting the server...
[21:10] <verterok> RenatoSilva: you could check what's the encoding of the data inside the Binary Blob using a slightly modified client.py
[21:10] <RenatoSilva> verterok: humm wait a minute, I receive variable encoding in terminal!
[21:10] <verterok> RenatoSilva: looks like that might be the cause
[21:10] <RenatoSilva> verterok: I'm sorry, in terminal no xmlrpc call is involved
[21:11] <verterok> RenatoSilva: right
[21:11] <verterok> RenatoSilva: the xmlrpc service is a different world
[21:12] <RenatoSilva> verterok: so in the server you make xmloutput think that it has an utf-8 terminal, and so you receive data as utf-8....
[21:12] <verterok> RenatoSilva: that's the idea, and I replace sys.stdout in order to catch all the output
[21:13] <LarstiQ> that is a bit iffy
[21:13] <RenatoSilva> verterok: well, if the server certaintly is always returning utf-8, you could safely do new String(parser.nextText(), "UTF-8")
[21:14] <LarstiQ> verterok: is this because you're calling cmd_ classes?
[21:14] <verterok> LarstiQ: I know.. it's a hack
[21:14] <verterok> LarstiQ: exactly
[21:14] <verterok> LarstiQ: the idea is to stop calling bzr commands, and call exposed methods via xmlrpc
[21:15]  * LarstiQ nods at verterok 
[21:15] <verterok> LarstiQ: the xmlrpc service is in the middle of a transition, it's just a band aid to workaround the slow startup
[21:15] <LarstiQ> verterok: aye :/
[21:16] <verterok> RenatoSilva: now I need to make sure that's true...but for that I need my windows vm...sadly I can take a loook to it tomorrow, as I;m not in my home (the VM is in my desktop :p )
[21:17] <RenatoSilva> verterok: or instead of hard-coded "UTF-8", the server response itself could have some element or attribute to tell the right encoding of the python-like strings inside the CDATAs (something like python_str_encoding="UTF-8" or "XML" (indicating that it's the same as the xml itself))
[21:17] <verterok> RenatoSilva: that's a good idea :)
[21:18] <verterok> RenatoSilva: first I want to make sure the xmlrpc service is actually sending all the info in one encoding...to be sure from where I should get the encoding it's using
[21:19] <LarstiQ> verterok: couldn't you change your terminal encoding in !win32 to test?
[21:19] <verterok> LarstiQ: I'ld love to know how to do that in linux :)
[21:20] <verterok> LarstiQ: what'do you know what's the *nix equivalent of cp??? encodings?
[21:20] <verterok> s/what'//
[21:20] <LarstiQ> verterok: export LC_ALL=C will probably already trip things up
[21:21] <LarstiQ> verterok: if not, you can pick a non-utf8 locale
[21:21] <verterok> LarstiQ: ack, thanks!
[21:22] <LarstiQ> verterok: say nl_NL@euro
[21:22] <LarstiQ> verterok: (LC_ALL should be enough, but if not, be a bit more brute with the variables from `locale`)
[21:23] <RenatoSilva> verterok: I will update the log view bug later...
[21:24] <verterok> RenatoSilva: ok, thanks!
[21:24] <RenatoSilva> verterok: what about the tests for teh emrge proposal? I'm not familiar with writing them :(
[21:25] <verterok> RenatoSilva: ok, don't worry I'll try to write a test for it
[21:26] <RenatoSilva> verterok: ok I'll try too, if it's not good you reject it...for services it may be easy, but for xml info it's a big file...I'll take a look anyway
[21:26] <RenatoSilva> verterok: thanks for helping!
[21:27] <verterok> RenatoSilva: it should be a simple test, about passing url with unicode names, etc. not a test for each command :)
[21:27] <verterok> RenatoSilva: thanks you, for digging into this and help me out!
[21:29] <RenatoSilva> thank you too
[21:31] <blueyed> What's the best way to check (from a shell script), if a file is under bzr control?
[21:31] <Peng_> blueyed: "bzr st" on it, maybe?
[21:32] <verterok> blueyed: take a look to: bzr ls --versioned
[21:32] <blueyed> Peng_: yes, makes sense. unfortunately the return code does not indicate an error.
[21:32] <blueyed> verterok: well, I have a given file and want to check if bzr knows about it.
[21:33] <blueyed> bzr ls only lists current directory.
[21:33] <Peng_> "bzr inventory" lists everything, but it's a bit evil to do it that way.
[21:33] <verterok> blueyed: there is a --recursive but as Peng_ said, it's a bit evil
[21:33] <blueyed> bzr st, with grepping for error might work.
[21:34] <verterok> blueyed: there is the 'bzr file-id' hidden command
[21:34] <Peng_> I just ran a quick test. For a file that wasn't versioned, "bzr st" exited with 3. For one that was versioned an unchanged, it was 0.
[21:34] <Peng_> Oh, that's a good idea.
[21:36] <blueyed> Peng_: bzr st exits with 0 for an non existant file.. (1.16.1)
[21:36] <blueyed> verterok: bzr file-id exits with error 3. great.
[21:40] <Peng_> blueyed: I'm on bzr.dev. Huh!
[21:41] <mwhudson> good morning
[21:41] <mwhudson> jelmer: ping
[21:42] <jelmer> mwhudson: pong
[21:42] <mwhudson> jelmer: did you look at that python2.4 crash bug at all?
[21:52] <RenatoSilva> how do I assertNoExceptionIsRaised?
[21:52] <Peng_> Isn't that what tests do by default?
[21:52] <Peng_> That's like doing "try: ...; except: raise".
[21:57] <RenatoSilva> how to avoid output?
[21:59] <RenatoSilva> I don't want the commands I'm running to print to stdout...
[21:59] <Peng_> Eh? What commands? Where?
[22:00] <RenatoSilva> Peng_: http://pastie.org/536241
[22:01] <RenatoSilva> Peng_: last command
[22:02] <Peng_> Ehh, I don't know anything.
[22:03] <RenatoSilva> Peng_: is it the pratice to let them write out to output?
[22:03] <Peng_> < Peng_> Ehh, I don't know anything.
[22:03] <RenatoSilva> Peng_: I 'd want just to see 'passed'
[22:04] <RenatoSilva> Can anyone suggest me a dummy command containing a non-ascii string?
[22:04] <jelmer> mwhudson: not really yet, sorry
[22:04] <mwhudson> jelmer: ok
[22:04] <mwhudson> jelmer: any ideas on where it's likely to be?
[22:04] <jelmer> mwhudson: I'm in .ie on vacation atm so my response times may be a bit slow the next couple of days
[22:04] <mwhudson> jelmer: ok
[22:05] <RenatoSilva> someting like bzr branch lp:xxx Maçã, but easy to set up inside a test
[22:05] <jelmer> mwhudson: no idea when I'll have a look exactly, depends on whether I can find a spare moment when I get back at the airport, etc
[22:05] <mwhudson> jelmer: it's a race between you and whoever is working on getting launchpad running on python 2.5 then :)
[22:05] <RenatoSilva> oh, bzr init :)
[22:05] <jelmer> mwhudson: :-)
[22:06] <jelmer> mwhudson: I'm quite sure it's a bug in subvertpy btw, since that's the only part of the code that actually has C extensions and could reasonably crash
[22:06] <RenatoSilva> but I need to delete the folder...no no... bad option....I want something simpler
[22:06] <mwhudson> jelmer: fair enough
[22:08] <LarstiQ> RenatoSilva: hmm?
[22:10] <verterok> RenatoSilva: take a look to the xmllog tests, I think there are encoding related tests
[22:10] <NfNitLoop> LarstiQ: re: SVN use cases -- we're making lots of use of svn:externals
[22:11] <NfNitLoop> (sorry, was AFK at a meeting)
[22:11] <RenatoSilva> verterok: currently I'm trying the custom_commands_main ...
[22:13] <verterok> RenatoSilva: I think that passing the raw str should be enough to test your fix, right?
[22:14] <LarstiQ> NfNitLoop: right, that is a bit of a sore spot. Have you looked at lp:bzr-scmproj?
[22:15] <verterok> RenatoSilva: like, 't\xc3\xba' that's tú in UTF-8
[22:16] <verterok> RenatoSilva: but in whatever encoding you want to check
[22:16] <NfNitLoop> LarstiQ: Haven't even heard of it till just now, I'll take a look.
[22:17] <jelmer> mwhudson: btw, do you happen to know what eventually was decided about nested trees?
[22:17] <mwhudson> jelmer: no, not really
[22:17] <LarstiQ> jelmer: not being hindered by knowledge of the facts, afaik no decision has been reached
[22:18] <jelmer> LarstiQ: so I guess that implies it's all going to be 3.0+
[22:18] <jelmer> ?
[22:20] <LarstiQ> jelmer: I'd really have to actually read something before trying to answer that
[22:20] <NfNitLoop> LarstiQ: Aah, scmproj sounds cool.  Unfortunately, what I need to manage is merging svn:external properties.  (Fun, right?) :p
[22:21] <jelmer> LarstiQ: last I heard (at UDS) spiv and abentley were working on dealing with the concerns raised
[22:21] <LarstiQ> NfNitLoop: *blink*
[22:21] <RenatoSilva> verterok: http://pastie.org/536241 (f.type is wrong, I'm trying to get the right attribute for the id)
[22:22] <jelmer> NfNitLoop: scmproj doesn't help in that regard unfortunately
[22:22] <LarstiQ> NfNitLoop: you people do _what_? ;P
[22:22] <NfNitLoop> LarstiQ: It sounds crazier than it is...
[22:22] <NfNitLoop> and it's a hell of a lot better than the system it replaced.
[22:23] <verterok> RenatoSilva: are you trying to catch an xmlrpc exception? or a bzr specific error?
[22:23] <NfNitLoop> We use a SVN repo full of svn:externals to deploy our (PHP) code to our servers in EC2.
[22:23] <NfNitLoop> we're going to have a branch of that for our staging environment.
[22:23] <NfNitLoop> when we are ready to launch staging to prod, we'll merge the changes to the externals into our prod repo.
[22:23] <NfNitLoop> It's... very meta. :p
[22:24] <NfNitLoop> (i.e. NOT something I would expect any other tools to support.)
[22:24] <LarstiQ> right. imnsho that is abusing vcs for deployment
[22:25] <RenatoSilva> verterok: catch the custom_command_main exceptions, it raises a Fault for UnicodeEncodeError
[22:25] <NfNitLoop> LarstiQ: It is.
[22:25] <NfNitLoop> But, did I mention that it's still *waay* better than our previous system? :)
[22:25] <LarstiQ> NfNitLoop: yes, you did :)
[22:25]  * LarstiQ goes to bed
[22:26] <NfNitLoop> The upshot is that it's always trivial to make sure that our production environment(s) haven't diverged from a known code state.  Which, unfortunately... happens.
[22:26] <RenatoSilva> verterok: I think I'll need to change the code itself a bit to raise the unicode error...
[22:26] <RenatoSilva> verterok: can I put any code into the fault code?
[22:26] <verterok> RenatoSilva: try doing a print dir(t)
[22:26] <RenatoSilva> verterok: ?
[22:26] <verterok> RenatoSilva: 42 is bzr specific error code
[22:27] <RenatoSilva> verterok: and 32?
[22:27] <verterok> RenatoSilva: all other non-bzr errors
[22:27] <RenatoSilva> verterok: what about not wrapping the error with fault? If it is UEE, then I just raise it
[22:28] <RenatoSilva> verterok: If I should use the Fault, then what code do I fill for UEE?
[22:28] <davidstrauss> What's the difference between a "bound branch" and a normal, heavyweight "checkout"?
[22:28] <verterok> RenatoSilva: it will be wrapped in a Fault, as it's a client/server talk
[22:28] <dash> davidstrauss: one difference
[22:28] <dash> oh wait
[22:28] <dash> no, those are the same thing.
[22:29] <davidstrauss> dash: That's why I thought.
[22:29] <verterok> RenatoSilva: I think 32, but this is just a way to note the error is from the bzr command or a bug/server side error
[22:29] <davidstrauss> But why does bzr explorer show a tab for each?
[22:31] <davidstrauss> dash: This suggests they're not the same thing: http://bazaar-vcs.org/DraftSpecs/SimpleCheckouts
[22:32] <dash> davidstrauss: Oh hmm
[22:32] <dash> i'm not gonna think about that lest it complicate my understanding of the world
[22:33] <verterok> RenatoSilva: you can get the code with: t.faultCode
[22:34] <verterok> RenatoSilva: you can get the code with: f.faultCode
[22:35] <RenatoSilva> verterok: yeah I've found it, but I did with raising a raw exception, see: http://pastie.org/536241. How about it?
[22:36] <verterok> RenatoSilva: using the code you pasted prviously, and using f.faultString I get the xml with the error: <?xml version="1.0" encoding="UTF-8"?><error><class>UnicodeEncodeError</class><dict></dict><message>'ascii' codec can't encode characters in position 2-3: ordinal not in range(128)</message></error>
[22:37] <verterok> RenatoSilva: and how is the UnicodeError handled?
[22:37] <verterok> RenatoSilva: e.g: a client send bad encoded args, what should the client expect in order to hanlde the error?
[22:37] <RenatoSilva> verterok: in main code?
[22:37] <verterok> RenatoSilva: in the client side
[22:38] <RenatoSilva> verterok: you mean we must send a Fault?
[22:38] <lamalex> Has anyone here given a talk on bzr at a lug or something similar? I'm giving on in two weeks, was wondering what other people talked about in theirs
[22:38] <RenatoSilva> verterok: I'm sorry could you explain better
[22:39] <RenatoSilva> verterok: humm maybe something's wrong with my test
[22:39] <verterok> RenatoSilva: look how the error are wrapped in XMLError(e), when client get a xmlrpc Fault with f.faultString containing the xml version of the exception
[22:40] <RenatoSilva> verterok: does Fault objects contain the exception object involved?
[22:40] <verterok> RenatoSilva: an xml version of the exception
[22:40] <RenatoSilva> verterok: only?
[22:40] <RenatoSilva> verterok: that's hard, I'd have to parse it...
[22:41] <verterok> RenatoSilva: yes, if you look at the definition of XMLError, it's just a way to serialize an exception to xml
[22:42] <RenatoSilva> verterok: I'm thinking of a better way to describe the test...
[22:44] <RenatoSilva> verterok: how about http://pastie.org/536241
[22:45] <verterok> RenatoSilva: looks good!, also you can check for an specific regexp in f.faultString
[22:45] <RenatoSilva> verterok: self.assertEquals...
[22:45] <RenatoSilva> verterok: yeah, regex...
[22:46] <verterok> RenatoSilva: e.g: self.assertContainsRe(f.faultString, 'UnicodeEncodeError')
[22:47] <RenatoSilva> verterok: when I remove the if isinstance(a, str) test in main code, the test fails, when not it passes ok
[22:47] <verterok> RenatoSilva: yay! :)
[22:52] <RenatoSilva> verterok: a minute please...
[22:55] <RenatoSilva> verterok: what now: http://pastie.org/536241
[22:56] <verterok> RenatoSilva: looks good, but the test should fail if you get a Fault...that means something else is completely broked
[22:56] <verterok> RenatoSilva: so, the previous self.assertEquals(21, f.faultCode) was ok
[22:56] <RenatoSilva> verterok: it does not test the whole method, just the encoding handling :)
[22:57] <RenatoSilva> verterok: test_custom_commands_main_unicode_handling
[22:57] <verterok> RenatoSilva: agreed, but "fail early" is good ;)
[22:57] <jam> poolie: if you wake up and want to chat, please call my cell phone
[22:58] <RenatoSilva> verterok: not always teh test should fail if you get a Fault
[22:58] <verterok> RenatoSilva: in this case, if you are calling an existing command it should fail :)
[22:58] <RenatoSilva> verterok: if you give it a wrong value, you expect a Fault, and therefore everything is ok and the test must pass
[22:59] <verterok> RenatoSilva: but it's good for me
[23:00] <RenatoSilva> verterok: this test runs a bzr log Maçã, where Maçã is not a branch, whcih will raise a Bzr error, that's why we can't use assert to fault code
[23:00] <verterok> RenatoSilva: so, if you like the later, I'm ok with it
[23:00] <verterok> RenatoSilva: ok, good point :)
[23:02] <RenatoSilva> verterok: I'll let you write the other tests custom_commands_main ok? :)
[23:02] <verterok> RenatoSilva: sure thing, thanks a lot!
[23:04] <RenatoSilva> verterok: ok I need to eat something, I can't push stuff to lp at work, I'll save this test and push later at home, I'll try to take a look for the other issue (non-ascii URLs) too...
[23:05] <verterok> RenatoSilva: ok, thanks again! Bom apetite!
[23:05] <RenatoSilva> verterok: thank you too, see you
[23:43] <jml> spiv, ping
[23:44] <lifeless> hai