[00:00] <chx> just out of curiosity ,how can i use bzr blame to find the oldest surviving code in a tree?
[00:20] <mkanat> Gee, that's a good question.
[00:20] <mkanat> chx: I'm betting that's plugin territory.
[00:22] <mwhudson> especially as i guess you'll want some heuristics
[00:22] <mwhudson> (only considering non-blanks lines for example?)
[00:45] <chx> hrm, right
[00:45] <chx> and no } either
=== Meths_ is now known as Meths
[00:49] <mwhudson> well, in some lesser languages, yea :)
[00:54] <spiv> Or in Python code with lots of multiline dict literals ;)
[01:08] <poolie> spiv:
[01:08] <poolie> <vila> oh, and I tried to warn spiv this morning but he was gone, his patch changing the branch creation signatures broke loom
[01:08] <poolie> <vila> I didn't have time to look at that but I'm afraid that will mean some hard compatibility issue for such plugins: 2.3 XOR the rest
[01:11] <spiv> No, I don't think it's a hard compatibility problem, I thought I'd already chatted with vila about this.
[01:12] <spiv> Implementations of BranchFormat.initialize etc need to accept a new optional keyword arg.
[01:12] <spiv> That won't impact their compatibility with old bzrlib versions at all.
=== zyga is now known as zyga-gone
[01:20] <poolie> spiv, well, from what he said it was actually breaking looms
[01:20] <poolie> i have not tested  myself
[01:32] <spiv> I just made the small patch to bzr-loom it needs to be compatible.
[01:33] <poolie> great
[01:33] <spiv> Compatibility with older bzr is unaffected.
[01:35] <spiv> https://code.launchpad.net/~spiv/bzr-loom/bzr-2.3-compat/+merge/43851
[01:35] <poolie> :)
[01:44] <mkanat> Why does bzr seem to print spaces out to the right side of the terminal for some things that it prints to the terminal?
[01:44] <mkanat> I'd think that it was just my terminal, except that it's only the first and last line of the commit output.
[01:45] <fullermd> Maybe where it had printed a progress bar, so had to put spaces to cover it up?
[01:45] <mkanat> fullermd: Oh, that could be, yeah.
[02:01] <poolie> probably that
[06:23] <Chris79> Hi, anyone here using the bzr-eclipse plugin with eclipse helios on win 7? I have trouble committing / updateing a project pulled from a remote bzr repo. Thanks for you help!
[07:07] <vila> hi all !
[07:07] <vila> poolie: thanks for the pqm email !
[07:08] <vila> poolie: I have *no* idea what is happening there though... never saw this kind of failure
[07:09] <vila> it may be another isolation issue uncovered by my fix...
[07:10] <mgz> morning vila.
[07:11] <vila> mgz: hey !
[07:16] <mgz> just looks like doctest isolation vila?
[07:17] <vila> mgz: now you're really reading above my shoulder ! This is in a private mail from poolie, how on earth can you see that ? :D
[07:17] <mgz> as in, you accidentally provided some.
[07:17] <mgz> it's in the mp!
[07:18] <vila> lol, pfew, I feel better :D
[07:18] <vila> ok, so I accidentally provided what ?
[07:19] <mgz> some isolation :)
[07:19] <vila> ha ! yes, that's the idea
[07:19] <poolie> on phone atm
[07:19] <poolie> perhaps we should look at tarmac now
[07:20] <vila> I'll have a look today
[07:22] <vila> mgz: given the order of the tests, that sounds right, and id didn't fail here because I have (as almost everybody running the tests) a valid whoami
[07:22] <vila> in my home directory
[07:22] <vila> which is now reached because BZR_HOME has been cleared
[07:22] <mgz> yup.
[07:23] <mgz> annoyingly the proper fix here is moderately hard.
[07:23] <vila> that's exactly the type of failure I was afraid of and why my fix may seem very shallow but the problem is deeper
[07:23] <vila> just a sec
[07:23] <poolie> don't know if it's actually going to fix this type of issue
[07:24] <mgz> all the bzrlib.tests.TestCase.setUp code needs factoring out into a method that can be passed to the doctest constructor
[07:24] <vila> poolie: no, in fact it will *uncover* other occurrences of this type of issue
[07:24] <poolie> is that good?
[07:24] <vila> yes
[07:25] <vila> otherwise we don't test what we think we test
[07:25] <mgz> but it was nice ignoring the fact doctests were borked vila :)
[07:25] <vila> mgz: hehe, we could just delete them :D
[07:26] <vila> kidding ! I don't want to start a religious discussion about doctests so early in my day :D
[07:27] <mgz> I'll bump the doctest bug up my todo list, can you hack around this failure by adding some whoami setting line to the doctest that fails?
[07:27] <mgz> ideally without further breaking the underlying environment...
[07:27] <mgz> now I need to go get ready and things.
[07:28] <vila> https://code.launchpad.net/~vila/bzr/690563-better-env-isolation/+merge/43871
[07:29] <vila> mgz: as soon as I reproduce it (my pqmlike setup was broken, fixing it right now)
[07:30] <vila> poolie: feedback on the above would be good (mgz too if you're still there), I don't want to land as is, but don't want to deploy to be said after the fact "Oh, why didn't you use *this* name instead ;)
[07:31] <vila> just added a comment explaining one dormant bug we have today
[07:34] <poolie> sure, i was going to do a couple more reviews
[07:36] <poolie> vila are you going to clean up the existing methods and their users?
[07:36] <poolie> or add an alternative?
[07:36] <poolie> i'd like the first a bit more
[07:37] <vila> My plan is to first remove all uses of _captureVar in the code base
[07:37] <vila> then I can cleanup further but I suspect some plugins may be using _captureVar and there I don't know if I should deprecate or delete it
[07:39] <vila> I think I'll probably go with several submissions to address and discuss each controversial point one by one
[07:40] <vila> I smell bike-shedding coming up at least as hard as the import saga ;D
[07:41] <poolie> on the environment stuff? i doubt it
[07:41] <vila> poolie: smooth_upgrade still on your list ?
[07:41] <poolie> vila, mgz: can i get you two to agree on https://code.launchpad.net/~gz/bzr/add_two_in_unicode_cwd_686611/+merge/43152
[07:41] <vila> mgz, poolie : yeah, can you agree ?
[07:41] <vila> :D
[07:42] <poolie> it is still on my list
[07:43] <vila> mgz: more seriously, what do you have in mind here ? I'm open to patches on any stable branches (it's simple enough), the main problem I mentioned was merging up to trunk but even if you plan a different fix for trunk, handling the merges yourself will be the simplest (unless we do it in sync via discussion here)
[07:46] <poolie> what does "with a boolean False path" mean there?
[07:49] <poolie> oh i see, meaning if we call it with ''
[07:52] <poolie> vila, will merging that to 2.0 actually make things harder when we merge up? why?
[07:54] <vila> poolie: only the NEWS related part is messy especially when we cross 2.2 -> 2.3
[07:54] <poolie> ok
[07:54] <poolie> but, generally speaking, we are still going to fix things in 2.2
[07:54] <poolie> so we have to cross that
[07:54] <vila> but even the 2.0 -> 2.1 doesn't merge that cleanly if news_merge is not configured
[07:54] <poolie> it's not a reason not to merge any particular change?
[07:54] <vila> not at all
[07:54] <poolie> ok, so i approved that with tweaks
[07:54] <vila> the one doing the merge should just be aware of the issue
[08:03]  * mgz returns
[08:07] <mgz> will comment on both those mps.
[08:07] <vila> mgz: ok
[08:07] <mgz> I'd be happy to do the merging up if it'll be particularly painful vila.
[08:08] <vila> mgz: error prone more than painful, which is why I mentioned it
[08:42] <vila> mgz: is there a bug filed for doctest isolation ?
[08:43] <mgz> it's bug 321320
[08:43] <ubot5> Launchpad bug 321320 in Bazaar "bzr's doctests are not isolated (branchbuilder doctests check global gpg configuration)" [High,Confirmed] https://launchpad.net/bugs/321320
[08:43] <vila> mgz: if you dont' know... 8-) Rock & roll !
[08:45] <vila> mgz: http://paste.ubuntu.com/544336/ is enough to fix the failure I'm encountering while trying to land bug #690563 fix
[08:45] <ubot5> Launchpad bug 690563 in Bazaar "bzrlib.tests.test_import_tariff.TestImportTariffs.test_simple_local failure" [Medium,In progress] https://launchpad.net/bugs/690563
[08:46] <mgz> that's the sort of thing I meant, yep
[08:46] <vila> mgz: sounds ok to land with this workaround until we fix 321... ok
[08:46] <poolie> vila, ok, upgrade thing is reviewed
[08:46] <mgz> you'll then be leaking that envvar again, but... that's only what we were doing before anyway
[08:48] <vila> poolie: ok, I'll tweak as much I feel reasonable and land it then
[08:49] <vila> mgz: damn, you're right ! ... and wrong too, I should not let this leak happen, hmm
[08:50] <mgz> import osutils instead and use set_or_unset twice?
[08:50] <vila> how does one disable a doctest ?
[08:50] <vila> mgz: would still be too brittle for my taste
[08:51] <mgz> no easy way to disable them, apart from changing the syntax so the scraper doesn't spot them
[08:51] <vila> oh easy, I would just comment out branchbuilder in the list of doc tests with a ref to 321320 to fix it
[08:51] <mgz> ah, or that works.
[08:51] <vila> I'll add a comment to that effect to the bug
[08:51] <mgz> how am I spelling my name in news these days...
[08:52] <poolie> vila that would be great, thanks
[08:52] <vila> mgz: unicode bug cruncher would be appropriate ;D
[08:53] <vila> mgz: a bit restrictive though...
[08:53] <poolie> :)
[08:54] <poolie> ok, i should go
[08:55] <vila> poolie: enjoy your evening ! And thanks for the reviews !
[08:55] <mgz> bye poolie!
[08:59] <vila> mgz: so this will be http://paste.ubuntu.com/544345/, still ok ?
[09:00] <vila> grr, fill-paragraph is too agressive, the bzrlib.branchbuilder should be on its own line
[09:00] <mgz> Looks fine. Could explicitly state it involves no user being set in the environment.
[09:00] <vila> indeed !
[09:01] <vila> done
[09:04] <mgz> I've pushed up NEWS for the bug 686611, could I ask you to look at it again and maybe land it for me vila?
[09:04] <ubot5> Launchpad bug 686611 in Bazaar 2.2 "`bzr add file1 file2` in non-ascii folder fails, but `bzr add file1` works" [Low,Confirmed] https://launchpad.net/bugs/686611
[09:04] <mgz> +fix
[09:07] <vila> ubot5: why the hell are you choosing 2.2 when most of the discussion is whether we start fixing it in 2.0 ???
[09:07] <ubot5> Error: I am only a bot, please don't think I'm intelligent :)
[09:07] <vila> ubot5: I wasn't implying anything...
[09:07] <ubot5> Error: I am only a bot, please don't think I'm intelligent :)
[09:08] <mgz> it's possibly the last milestone I added to the bug?
[09:09] <mgz> it's a little odd it picks that one though.
[09:10] <vila> no big deal :) I was just surprised and wondered if *you* had changed your mind (sent to pqm)
[09:16] <vila> a fix for 'lost connection during test' will make me so happy... ;D
[09:27] <mgz> urk, running out of time, will have to file paths bug later.
[09:28] <vila> spiv: oh ! Thanks for the loom fix ! Sorry to mention it so late, I was thrilled when I read the irc log !
[09:28] <vila> mgz: let me know about where you end up merging this fix up
[09:29] <vila> mgz: I expect it to be a bit stretched along the day if you wait for pqm
[09:31] <mgz> vila: yup, and I'll put them in the review queue anyway as I can only submit to bzr.dev
[09:31] <mgz> will start some time early afternoon when I get back.
[09:31] <vila> mgz: really ? We should fix that
[09:31] <vila> mgz: ok
[10:04] <vila> grr, one more pqm failure without mail :(
[10:09] <vila> mgz: if you're still around may be you can submit for me ;)
[10:28] <tacone> hello, i need a quick way to check if bzr is locked. anyone ?
[10:42] <Peng> tacone: bzr info, if you're really asking about the lock status of a bzrdir.
[10:43] <tacone> yes, that. thanks !
=== Leonidas_ is now known as Leonidas
=== zyga is now known as zyga-food
[14:36] <mgz> ack, vila, sorry, I didn't notice, you commented the wrong line to skip that doctest
[14:37] <mgz> you want _test_suite_modules_to_doctest 'bzrlib.branchbuilder'
[14:37] <vila> no ???
[14:37] <mgz> but did _test_suite_testmod_names 'bzrlib.tests.test_branchbuilder'
[14:38] <mgz> that'll fix that and I'll send to pqm so we get the output in case it complains again
[14:38] <vila> and I'm banging my head on an apport failure for nothing ?
[14:38] <mgz> (personally, I'd do that as a seperate branch, first, then send lp:~vila/bzr/690563-test-isolation without that change on it at all.
[14:39] <vila> why ?
[14:40] <mgz> it's not really related, and wants to be backed out in the future. also, if that change is wrong, 's more obvious pqm'ed seperately
[14:40] <mgz> I don't think it matters much in this case.
[14:40] <vila> it *is* related, the change *uncover* the problem
[14:40] <mgz> right, but say, for example, the wrong line was commented out.
[14:41] <mgz> having a pqm run first just for that workaround makes it more obvious we've just lost a bunch of tests.
[14:41] <mgz> (just... babune would be clearer, but doesn't run each change)
[14:42] <vila> yeah :-/ I don't know what happened, I clearly remember seeing your comment on _modules_to_doctest...
[14:42] <mgz> brains are funny things.
[14:42] <mgz> sometimes they work, sometimes...
[14:43] <vila> right, that's a bit excessive I think, it will also clutter the bzr.dev history plus I'm almost ready to submit a more robust alternative (while also realizing there is an even more robust one possible ;-/)
[14:44] <vila> what was the problem with apport tests last time ?
[14:44] <vila> or was it maxb ?
[14:45] <maxb> ?
[14:46] <mgz> hefixedit.
[14:47] <mgz> see bug 686439
[14:47] <ubot5> Launchpad bug 686439 in Bazaar "easy_install breaks due to SandboxViolation on SLES" [Medium,Fix released] https://launchpad.net/bugs/686439
[14:47] <vila> python -Werror -O ./bzr selftest -s bt.test_crash fails reliably on my pqmlike host
[14:48] <vila> I thought that was why my submission was failing and start bisecting like crazy until I realize it was related to '-Werror -O'
[14:48] <mgz> ah, different thing.
[14:50]  * vila bangs ahead a bit nore
[14:50] <vila> python2.5 only so unrelated to pqm
[14:52] <vila> mgz: I've filed an RT about pqm access, I'll keep you informed (but the admins are quite busy these days ;-/)
[14:54] <vila> mgz: your fix has landed for 2.0, tell me when you're ready for 2.1
[14:54] <mgz> just doing it now.
[15:01] <mgz> vila: https://code.launchpad.net/~gz/bzr/merge_2.0_to_2.1/+merge/43913
[15:02] <Peng> The admins are too busy? Sounds like somebody needs to have their sleeping privileges taken away.
=== Ursinha is now known as Ursinha-brb
[15:02] <vila> Peng: that the problem with admins: they are the ones handling the privileges
=== zyga-food is now known as zyga
[15:12] <fullermd> How does one go about aquiring these "sleeping privileges" of which you speak?
[15:19] <vila> mgz: sent to pqm
[15:19] <mgz> thanks!
[15:19] <vila> . o O (Damn, no he will be suspicious about his lack of sleep)
[15:20] <vila> s/no/now/ shudder tyop ekoj
[15:50] <lvh> Hi!
[15:51] <lvh> I'm ordinarily an Emacs user, but if I want to try bzr with Eclipse/Pydev, should I use the Eclipse-Bzr plugin or the QBzr plugin?
[15:54] <jam> lvh: AIUI eclipse-bzr has closer integration, but qbzr has more total polish
[15:55] <lvh> jam: Hm, okay.
[15:55] <lvh> jam: I'll try both and see what happens.
[15:55] <lvh> jam: It's not the case that one is particularly deprecated/bad, right?
[15:55] <vila> jam: good morning !
[15:56] <vila> mgz: yeeeeehaaaa, one more blue target on babune ;)
[15:57] <vila> mgz: 2.1 landed
[15:57] <mgz> cool! will do the next merge step.
[15:57] <jam> morning vila
[15:58] <jam> I'm very happy that we're really close to getting lp-forking-service rolled out on qastaging.
[15:58] <mgz> blue macs mean I could feasably tackle the filesystem normalisation issue.
[15:58] <jam> the service is installed and running, and the mp is submitted to activate it
[15:58] <vila> jam: yeeehaaa ! :D
[15:59] <vila> mgz: or submit your fixes to turn the windows one blue ;)
[15:59] <jam> fullermd: sorry, no sleeping priviledges are available at this time. Please submit form INTS5525. Expect processing to take 1-5 weeks.
[15:59] <mgz> yeah, to many things not enough time.
[15:59] <vila> I know :)
[16:01] <mgz> +o
[16:05] <vila> +o..... female symbol turned clock-wise ? some unknown smiley ? /me facepalms tyop ! to+o :D
[16:06] <mgz> right :)
[16:08] <mgz> you can sort of parse what I said with the wrong too? but the meaning is different
[16:08] <mgz> vila: https://code.launchpad.net/~gz/bzr/merge_2.1_to_2.2/+merge/43925
[16:08] <vila> well, my parser is tolerant to some form of typos :)
=== deryck is now known as deryck[lunch]
[16:09] <vila> mgz: sent
[16:10] <mgz> thanks! I can do the last one myself, but will probably bug you anyway to check I've understood spiv's split correctly.
[16:10] <vila> mgz: and now the tricky one :) You'll have to update the doc/en/release-notes manually during the merge
[16:11] <vila> because NEWS -> doc/en/release-notes/bzr-2.3.txt which produces horribly wrong merge results
[16:12] <vila> garyVDM ! gary ! gary ! Come back !
=== beuno is now known as beuno-lunch
[16:33] <hallyn_> Hi,  when i try to do a 'bzr merge-upstream' from a packaging tree, i get:
[16:34] <hallyn_> bzr: ERROR: Merge upstream in merge mode is not yet supported.
[16:35] <hallyn_> will it do any harm if i temporarily remove 'merge = True' from .bzr-buildddeb/default.conf ?
[16:37] <jelmer> hallyn_, hi
[16:37] <jelmer> hallyn_: if you're trying to run "bzr merge-upstream" I wonder if you should need "merge = True" at all
[16:37] <jelmer> hallyn_, Does your packaging branch contain the upstream source code ?
[16:38] <hallyn_> no
[16:38] <jelmer> hallyn_: "bzr merge-upstream" will add the upstream source, is that what you're trying to do?
[16:38] <hallyn_> upstream source code is in lp:vmbuilder, the packaging branch is at bzr+ssh://bazaar.launchpad.net/~vmbuilder-dev/vmbuilder/packaging/
[16:38] <hallyn_> heh, i don't know.  i didn't create the trees, i inherited them
[16:39] <hallyn_> i'm just trying to build a package to propose for archive, based on the new pacakaging and source trees
[16:39] <jelmer> hallyn_: So you mainly want to add a new changelog entry for the appropriate revision in lp:vmbuilder /
[16:39] <jelmer> ?
[16:39] <hallyn_> i did that
[16:40] <hallyn_> now i want a bzr command in place of building a source package and asking someone to dput that.  i.e. somethint to create a tree that someone can review and sponsor
[16:40] <hallyn_> AIUI that was bzr merge-upstream...
[16:40] <jelmer> hallyn_: Ah, ok. You're probably after "bzr builddeb -S"
[16:41] <jelmer> hallyn_: "bzr merge-upstream" merges in an upstream revision and updated debian/changelog appropriately
[16:41] <hallyn_> no, that creates the package which i then have to scp somewhere for someont to look at out of band
[16:41] <jelmer> hallyn_: So you'd like to propose a merge that somebody can review?
[16:42] <hallyn_> right, what i want is a bzr tree which someone can review and sponsor as though it had been a package
[16:42] <hallyn_> if that makes any sense at all
[16:42] <hallyn_> (sorry, terrible network lag due to sync)
[16:42] <hallyn_> yes
[16:42] <jelmer> hallyn_: yep - I think "bzr lp-propose" should do that, or you can click "Propose for merging" on the branch web page
[16:43] <hallyn_> awesome, let me try that, thanks
[16:43] <hallyn_> well no, wait
[16:43]  * hallyn_ wonders why hundreds of megs are being xferred to sync one changed U1 file)
[16:44] <hallyn_> jelmer: i guess where i am confused is that this is not the actual source tree.  I'ts *just8 the packaging tree with only the contents of debian/
[16:45] <jelmer> hallyn_: You would propose your branch for merging into the packaging branch
[16:45] <jelmer> hallyn_: The upstream branch is only used by "bzr builddeb" and should not be relevant here
[16:45] <hallyn_> the packaging branch being which?
[16:46] <jelmer> lp:~vmbuilder-dev/vmbuilder/packaging/
[16:46] <hallyn_> IIUC i've already pushed the change into the packaging branch
[16:46] <hallyn_> ok, yes
[16:46] <hallyn_> i own that.  So now the next step is actuallyuploading the resulting package to the archive
[16:46] <jelmer> hallyn_: The only way to do that is to create a source tarball and upload it
[16:48] <hallyn_> jelmer: ok, thanks.  i think the hope was for there to be a single bzr tree containing source+packaging which could be diffed for whoever sponsors the package upload.  But I guess that doesn't quite fit into this setup
=== dbarth_ is now known as dbarth
=== deryck[lunch] is now known as deryck
[17:28] <vila> mgz: 2.2 landed
[17:28] <mgz> pull me push you.
[17:29] <vila> too bad, I missed the joke ;-/
=== beuno-lunch is now known as beuno
[18:20] <vila> mgz: by the way, you've got a mac ?
[18:21]  * vila revises his beliefs...
=== smoser is now known as smoser`
=== smoser` is now known as smoser
[18:35] <mgz> vila: no. I have babune!
[18:35] <vila> LOL
[18:35] <vila> I should definitely make it easier to use selftest-subset then :)
[18:51] <mgz> what's bug 687653 about ubot5?
[18:51] <ubot5> Bug 687653 on http://launchpad.net/bugs/687653 is private
[18:54] <mgz> vila: does this look about right? http://paste.ubuntu.com/544559/
[18:57] <vila> mgz: pretty much, but I think we don't copy the new entry across the 2.2/2.3 barrier (cooking time here, but check what I did with ... can't remember, last merge from 2.2)
[19:01] <mgz> ah, I see what you mean.
[19:01] <mgz> so I can just revert doc/en/release-notes/bzr-2.3.txt
[19:35] <lifeless> mgz: hola
[19:35] <mgz> shazam.
[19:35] <lifeless> mgz: I think jam is preoccupied atm
[19:35] <lifeless> mgz: so we should decide if its environmental or not, and move forward accordingly
[19:36] <jam> lifeless: sorry, I'm missing the context
[19:36] <jam> testtools stuff?
[19:36] <lifeless> jam: yes
[19:36] <lifeless> jam: we can't reproduce the problem
[19:37] <mgz> jam, can you just run that test and still repo the random failure?
[19:37] <jam> lifeless: k. Fully reproducible here, what would you like from me
[19:37] <jam> mgz: what test?
[19:37] <jam> (i'm missing something from the traceback, I guess)
[19:37] <mgz> the one that fails.
[19:37] <jam> just the failing one?
[19:37] <lifeless> jam: probably drop into pdb and see whats going on
[19:38] <lifeless> mgz has a crazy theory about twisted but I think thats ... crazy :)
[19:38] <jam> lifeless: is there a new testtools I should be using?
[19:38] <mgz> otherwise yeah, stick a breakpoint in the __str__ method and step out from there to see what happens
[19:38] <lifeless> jam: just tip
[19:39] <lifeless> to run a single test, python -m testtools <testid>
[19:39] <lifeless> grah
[19:39] <lifeless> testtools.run <testid>
[19:39] <lifeless> [doesn't work for scenarios yet, but the failing test wasn't a scenario test anyhow IIRC]
[19:41] <lifeless> what seems to be different to me is that we get just the class name, not the <..> sutff
[19:42] <mgz> yup. which implies either the exception doesn't propogate, or that __str__ method is never called and something else stringifies it.
[19:45] <jam> lifeless: so I'm sitting here, and I can paste the output
[19:45] <jam> what are you looking for?
[19:46] <jam> lifeless: also note, you are doing "raise UnprintableError"
[19:46] <jam> not "raise UnprintableError()"
[19:46] <jam> I don't know if that matters
[19:47] <jam> lifeless: http://paste.ubuntu.com/544575/
[19:47] <jam> If I just run the test and capture the 'stream.getvalue()' that is the traceback the test runner sees
[19:47] <jam> If I create the class in a python interactive shell
[19:47] <jam> and raise it
[19:47] <jam> that is what I see
[19:48] <jam> I'm assuming something in testtools is supposed to be catching the error for formatting and isn't?
[19:48] <jam> Aren't you just using traceback.format_exc() ?
[19:48] <mgz> nope, this is the whole point of these tests.
[19:49] <mgz> they need to be going through TestResult._exc_info_to_unicode
[19:49] <lifeless> format_exc generates non-local-encoding bytestrings
[19:52] <mgz> so, if you do that same microtest, but try/except round the raise and pass to testtools.TestResult()._exc_info_to_unicode do you get the same final line?
[19:52] <mgz> because that's what your test failure imples.
[19:52] <mgz> +i
[19:53] <mgz> either that, or it's somehow escaping that method.
[19:54] <jam> mgz: I'm trying to get there, but you also need a test case
[19:54] <jam> mgz: are you saying inside the created file?
[19:56] <mgz> or just on the terminal
[19:58] <mgz> putting a break point anywhere before or during the actual test run would also work, but there are a lot of testtools levels to step through, and the fact these tests use generated files probably isn't helping any
[19:58] <jam> mgz: using this hack: http://paste.ubuntu.com/544580/
[19:58] <jam> I get this: http://paste.ubuntu.com/544581/
[19:58] <jam> printed to stdout
[19:59] <jam> mgz: so yes, testtools.TestResult._exc_info_to_unicode(exc_info, ...) is generating output that only has the class name
[20:00] <mgz> okay, that's borked. step into the execution of that call?
[20:00] <mgz> you should end up in testtools.compat
[20:01] <mgz> if you didn't, all the other tests would fail...
[20:01] <jam> mgz: at what point?
[20:01] <lifeless> mgz: jam's query is interesting
[20:01] <lifeless>             testline="raise UnprintableError")
[20:01] <jam> the immediate jump is to unittest._exc_info_to_string
[20:01] <lifeless> aren't you meant to construct things always, these days ?
[20:01] <mgz> doesn't make any difference.
[20:01] <jam> lifeless: I think you are, but it doesn't seem to change the tracebacks
[20:02] <lifeless> kk
[20:02] <jam> At least manually doing "raise Foo" and "raise Foo()" gave the same results
[20:03] <mgz> so jam, what should happen is from testtools.compat._format_exc_info the exception instance is passed to testtools.compat._exception_to_text to do the stringifying
[20:04] <jam> mgz: (Pdb) tr._exc_info_to_unicode.im_func.func_globals['traceback']
[20:04] <jam> <module '__fake_traceback' (built-in)>
[20:04] <mgz> oooo... I wonder if there's a __unicode__ method screwing me up here?
[20:04] <jam> which looks like it is properly overriding the thing you want to
[20:06] <jam> mgz: when I step through it, I've gotten into the testtools.compat._format_exc_info
[20:07] <mgz> jump forward to near the end and the _exception_to_text call
[20:08] <mgz> hm, no __unicode__ issue on 2.6.6 at least: http://paste.ubuntu.com/544585/
[20:08] <jam> mgz: if I'm doing it right, for some reason at the point of "svalue = _exception_to_text(evalue)" the evalue is None
[20:08] <jam> even though there is an earlier "if evalue is None: return"
[20:08] <jam> ah wait, probably just a bug in "pp evalue" in the debugger
[20:08] <jam> since this class isn't printable
[20:09] <jam> mgz: unicode(evalue) returns
[20:09] <jam> unicode(evalue) == u''
[20:09] <mgz> Exception.__repr__(evalue) would give you feedback if pdb has issues
[20:09] <mgz> okay, that's bad and wrong, and the bug.
[20:09] <mgz> I'll defend the test from it.
[20:10] <jam> mgz: so is this just a bug in python 2.6.4 then?
[20:10] <jam> (Pdb) evalue.__unicode__
[20:10] <jam> <built-in method __unicode__ of UnprintableError object at 0x025732B0>
[20:10] <mgz> I presume they added a seperate __unicode__ method to the base Exception class... then removed it again.
[20:10] <lifeless> yes
[20:10] <lifeless> I thought I mentioned that the first day ;)
[20:10] <mgz> ...you did? where did you ;_;
[20:10] <lifeless> here
[20:11] <mgz> thanks jam! you have been very patient with me.
[20:11] <lifeless>  /lastlog futzed|changed might find my comment
[20:11] <lifeless> I'm not 100% sure I did - but there is a python bug on __unicode__ in Exception in 2.6.x
[20:12] <vila> lifeless: by the way, when do you plan to push a debian release of python-testtools ? Our MRE/SRU is blocked on that so far (in short)
[20:12] <lifeless> vila: when we can release
[20:12] <jam> mgz: http://mail.python.org/pipermail/python-bugs-list/2006-September/035171.html
[20:12] <lifeless> vila: which is why I'm talking to mgz and jam now
[20:12] <vila> lifeless: great, so this will be 0.9.8 ?
[20:12] <mgz> I'll put a branch up now avoiding that.
[20:13] <lifeless> vila: something like that
[20:13] <jam> mgz: I assume you can just add "def __unicode__(self): raise RuntimeError"
[20:13] <mgz> yup, that's what I'll do.
[20:16] <val_> ping vila
[20:23] <mgz> lifeless: https://code.launchpad.net/~gz/testtools/avoid_exception_unicode_method_bug_689858/+merge/43967
[20:23] <lifeless> jam: can you confirm that that passes?
[20:25] <jam> runs clean
[20:25] <jam> lifeless, mgz: ^^
[20:25] <lifeless> thanks
[20:25] <lifeless> I'll pull it in and do a release later today
=== Ursinha-brb is now known as Ursinha
=== Ursinha-afk is now known as Ursinha
[20:54] <mgz> ha, lifeless, I see you even commented in the bug for the __unicode__ method backout
[20:54] <lifeless> mgz: yes, this is why I was able to mention it easily :)
[20:54] <lifeless> what was the issue number again ?
[20:54] <mgz> http://bugs.python.org/issue6108
[20:55] <mgz> just adding note to the bug so I have a record.
[20:56] <lifeless> care to put that as a note in the branch too ?
[20:57] <lifeless> spiv: ^ btw, thats why we override __unicode__
[20:57] <lifeless> spiv: or something
[20:59] <mgz> done.
[20:59] <mgz> quite glad I ran into this now, I'm fiddling with unicode and exceptions in bzr currently.
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[22:02] <renatosilva> how to resolve conflicts in bynary files?
[22:03] <renatosilva> bzr status is showing as removed and unknown even if I bzr resolve binfile (where binfile is the right one, resolved)