| chx | just out of curiosity ,how can i use bzr blame to find the oldest surviving code in a tree? | 00:00 |
|---|---|---|
| mkanat | Gee, that's a good question. | 00:20 |
| mkanat | chx: I'm betting that's plugin territory. | 00:20 |
| mwhudson | especially as i guess you'll want some heuristics | 00:22 |
| mwhudson | (only considering non-blanks lines for example?) | 00:22 |
| chx | hrm, right | 00:45 |
| chx | and no } either | 00:45 |
| === Meths_ is now known as Meths | ||
| mwhudson | well, in some lesser languages, yea :) | 00:49 |
| spiv | Or in Python code with lots of multiline dict literals ;) | 00:54 |
| 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:08 |
| spiv | No, I don't think it's a hard compatibility problem, I thought I'd already chatted with vila about this. | 01:11 |
| 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. | 01:12 |
| === zyga is now known as zyga-gone | ||
| poolie | spiv, well, from what he said it was actually breaking looms | 01:20 |
| poolie | i have not tested myself | 01:20 |
| spiv | I just made the small patch to bzr-loom it needs to be compatible. | 01:32 |
| poolie | great | 01:33 |
| spiv | Compatibility with older bzr is unaffected. | 01:33 |
| spiv | https://code.launchpad.net/~spiv/bzr-loom/bzr-2.3-compat/+merge/43851 | 01:35 |
| poolie | :) | 01:35 |
| 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:44 |
| 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. | 01:45 |
| poolie | probably that | 02:01 |
| 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! | 06:23 |
| vila | hi all ! | 07:07 |
| vila | poolie: thanks for the pqm email ! | 07:07 |
| vila | poolie: I have *no* idea what is happening there though... never saw this kind of failure | 07:08 |
| vila | it may be another isolation issue uncovered by my fix... | 07:09 |
| mgz | morning vila. | 07:10 |
| vila | mgz: hey ! | 07:11 |
| mgz | just looks like doctest isolation vila? | 07:16 |
| 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:17 |
| vila | lol, pfew, I feel better :D | 07:18 |
| vila | ok, so I accidentally provided what ? | 07:18 |
| 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:19 |
| vila | I'll have a look today | 07:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| vila | kidding ! I don't want to start a religious discussion about doctests so early in my day :D | 07:26 |
| 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:27 |
| vila | https://code.launchpad.net/~vila/bzr/690563-better-env-isolation/+merge/43871 | 07:28 |
| vila | mgz: as soon as I reproduce it (my pqmlike setup was broken, fixing it right now) | 07:29 |
| 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:30 |
| vila | just added a comment explaining one dormant bug we have today | 07:31 |
| poolie | sure, i was going to do a couple more reviews | 07:34 |
| 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:36 |
| 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:37 |
| vila | I think I'll probably go with several submissions to address and discuss each controversial point one by one | 07:39 |
| vila | I smell bike-shedding coming up at least as hard as the import saga ;D | 07:40 |
| 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:41 |
| poolie | it is still on my list | 07:42 |
| 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:43 |
| poolie | what does "with a boolean False path" mean there? | 07:46 |
| poolie | oh i see, meaning if we call it with '' | 07:49 |
| poolie | vila, will merging that to 2.0 actually make things harder when we merge up? why? | 07:52 |
| 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 | 07:54 |
| * mgz returns | 08:03 | |
| 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:07 |
| vila | mgz: error prone more than painful, which is why I mentioned it | 08:08 |
| vila | mgz: is there a bug filed for doctest isolation ? | 08:42 |
| 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:43 |
| 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:45 |
| 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:46 |
| vila | poolie: ok, I'll tweak as much I feel reasonable and land it then | 08:48 |
| vila | mgz: damn, you're right ! ... and wrong too, I should not let this leak happen, hmm | 08:49 |
| 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:50 |
| 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:51 |
| poolie | vila that would be great, thanks | 08:52 |
| vila | mgz: unicode bug cruncher would be appropriate ;D | 08:52 |
| vila | mgz: a bit restrictive though... | 08:53 |
| poolie | :) | 08:53 |
| poolie | ok, i should go | 08:54 |
| vila | poolie: enjoy your evening ! And thanks for the reviews ! | 08:55 |
| mgz | bye poolie! | 08:55 |
| vila | mgz: so this will be http://paste.ubuntu.com/544345/, still ok ? | 08:59 |
| 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:00 |
| vila | done | 09:01 |
| 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:04 |
| 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:07 |
| mgz | it's possibly the last milestone I added to the bug? | 09:08 |
| mgz | it's a little odd it picks that one though. | 09:09 |
| vila | no big deal :) I was just surprised and wondered if *you* had changed your mind (sent to pqm) | 09:10 |
| vila | a fix for 'lost connection during test' will make me so happy... ;D | 09:16 |
| mgz | urk, running out of time, will have to file paths bug later. | 09:27 |
| 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:28 |
| vila | mgz: I expect it to be a bit stretched along the day if you wait for pqm | 09:29 |
| 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 | 09:31 |
| vila | grr, one more pqm failure without mail :( | 10:04 |
| vila | mgz: if you're still around may be you can submit for me ;) | 10:09 |
| tacone | hello, i need a quick way to check if bzr is locked. anyone ? | 10:28 |
| Peng | tacone: bzr info, if you're really asking about the lock status of a bzrdir. | 10:42 |
| tacone | yes, that. thanks ! | 10:43 |
| === Leonidas_ is now known as Leonidas | ||
| === zyga is now known as zyga-food | ||
| mgz | ack, vila, sorry, I didn't notice, you commented the wrong line to skip that doctest | 14:36 |
| 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:37 |
| 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:38 |
| vila | why ? | 14:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| vila | what was the problem with apport tests last time ? | 14:44 |
| vila | or was it maxb ? | 14:44 |
| maxb | ? | 14:45 |
| mgz | hefixedit. | 14:46 |
| 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:47 |
| 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:48 |
| * vila bangs ahead a bit nore | 14:50 | |
| vila | python2.5 only so unrelated to pqm | 14:50 |
| vila | mgz: I've filed an RT about pqm access, I'll keep you informed (but the admins are quite busy these days ;-/) | 14:52 |
| 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. | 14:54 |
| mgz | vila: https://code.launchpad.net/~gz/bzr/merge_2.0_to_2.1/+merge/43913 | 15:01 |
| Peng | The admins are too busy? Sounds like somebody needs to have their sleeping privileges taken away. | 15:02 |
| === Ursinha is now known as Ursinha-brb | ||
| vila | Peng: that the problem with admins: they are the ones handling the privileges | 15:02 |
| === zyga-food is now known as zyga | ||
| fullermd | How does one go about aquiring these "sleeping privileges" of which you speak? | 15:12 |
| 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:19 |
| vila | s/no/now/ shudder tyop ekoj | 15:20 |
| lvh | Hi! | 15:50 |
| 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:51 |
| jam | lvh: AIUI eclipse-bzr has closer integration, but qbzr has more total polish | 15:54 |
| 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:55 |
| vila | mgz: yeeeeehaaaa, one more blue target on babune ;) | 15:56 |
| vila | mgz: 2.1 landed | 15:57 |
| mgz | cool! will do the next merge step. | 15:57 |
| jam | morning vila | 15:57 |
| 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:58 |
| 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 :) | 15:59 |
| mgz | +o | 16:01 |
| vila | +o..... female symbol turned clock-wise ? some unknown smiley ? /me facepalms tyop ! to+o :D | 16:05 |
| mgz | right :) | 16:06 |
| 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 :) | 16:08 |
| === deryck is now known as deryck[lunch] | ||
| vila | mgz: sent | 16:09 |
| 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:10 |
| vila | because NEWS -> doc/en/release-notes/bzr-2.3.txt which produces horribly wrong merge results | 16:11 |
| vila | garyVDM ! gary ! gary ! Come back ! | 16:12 |
| === beuno is now known as beuno-lunch | ||
| hallyn_ | Hi, when i try to do a 'bzr merge-upstream' from a packaging tree, i get: | 16:33 |
| hallyn_ | bzr: ERROR: Merge upstream in merge mode is not yet supported. | 16:34 |
| hallyn_ | will it do any harm if i temporarily remove 'merge = True' from .bzr-buildddeb/default.conf ? | 16:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 | |
| 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:44 |
| 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:45 |
| 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:46 |
| 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 | 16:48 |
| === dbarth_ is now known as dbarth | ||
| === deryck[lunch] is now known as deryck | ||
| vila | mgz: 2.2 landed | 17:28 |
| mgz | pull me push you. | 17:28 |
| vila | too bad, I missed the joke ;-/ | 17:29 |
| === beuno-lunch is now known as beuno | ||
| vila | mgz: by the way, you've got a mac ? | 18:20 |
| * vila revises his beliefs... | 18:21 | |
| === smoser is now known as smoser` | ||
| === smoser` is now known as smoser | ||
| 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:35 |
| mgz | what's bug 687653 about ubot5? | 18:51 |
| ubot5 | Bug 687653 on http://launchpad.net/bugs/687653 is private | 18:51 |
| mgz | vila: does this look about right? http://paste.ubuntu.com/544559/ | 18:54 |
| 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) | 18:57 |
| mgz | ah, I see what you mean. | 19:01 |
| mgz | so I can just revert doc/en/release-notes/bzr-2.3.txt | 19:01 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| lifeless | what seems to be different to me is that we get just the class name, not the <..> sutff | 19:41 |
| mgz | yup. which implies either the exception doesn't propogate, or that __str__ method is never called and something else stringifies it. | 19:42 |
| jam | lifeless: so I'm sitting here, and I can paste the output | 19:45 |
| jam | what are you looking for? | 19:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| mgz | they need to be going through TestResult._exc_info_to_unicode | 19:49 |
| lifeless | format_exc generates non-local-encoding bytestrings | 19:49 |
| 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:52 |
| mgz | either that, or it's somehow escaping that method. | 19:53 |
| 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:54 |
| mgz | or just on the terminal | 19:56 |
| 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:58 |
| jam | mgz: so yes, testtools.TestResult._exc_info_to_unicode(exc_info, ...) is generating output that only has the class name | 19:59 |
| mgz | okay, that's borked. step into the execution of that call? | 20:00 |
| mgz | you should end up in testtools.compat | 20:00 |
| 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:01 |
| lifeless | kk | 20:02 |
| jam | At least manually doing "raise Foo" and "raise Foo()" gave the same results | 20:02 |
| 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:03 |
| 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:04 |
| jam | mgz: when I step through it, I've gotten into the testtools.compat._format_exc_info | 20:06 |
| mgz | jump forward to near the end and the _exception_to_text call | 20:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| val_ | ping vila | 20:16 |
| 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:23 |
| 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 | 20:25 |
| === Ursinha-brb is now known as Ursinha | ||
| === Ursinha-afk is now known as Ursinha | ||
| 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:54 |
| mgz | just adding note to the bug so I have a record. | 20:55 |
| lifeless | care to put that as a note in the branch too ? | 20:56 |
| lifeless | spiv: ^ btw, thats why we override __unicode__ | 20:57 |
| lifeless | spiv: or something | 20:57 |
| mgz | done. | 20:59 |
| mgz | quite glad I ran into this now, I'm fiddling with unicode and exceptions in bzr currently. | 20:59 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| renatosilva | how to resolve conflicts in bynary files? | 22:02 |
| renatosilva | bzr status is showing as removed and unknown even if I bzr resolve binfile (where binfile is the right one, resolved) | 22:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!