subunit-dev team mailing list archive

[Jelmer Vernooij <jelmer@xxxxxxxxx>]

On Mon 31 Oct 2011 18:56:05 CET, Jonathan Lange wrote:
> On Mon, Oct 31, 2011 at 1:09 PM, Jelmer Vernooij <jelmer@xxxxxxxxx> wrote:
>> On 10/31/2011 05:08 PM, Jonathan Lange wrote:
>>>
>>> On Mon, Oct 31, 2011 at 11:35 AM, Jelmer Vernooij<jelmer@xxxxxxxxx>
>>>  wrote:
>>>>
>>>> On 10/31/2011 03:47 PM, Jonathan Lange wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> The daily builds for subunit started failing recently[1]. The logs
>>>>> show that it's due to a conflict with setup.py. The commit log for the
>>>>> packaging branch[2] says that this has happened before in r101 ("Merge
>>>>> trunk to resolve conflict on setup.py - bad auto-merge?")
>>>>>
>>>>> However, the commit after that says "No setup.py for debian, debhelper
>>>>> gets confuddled." My hypothesis is that whenever we change setup.py in
>>>>> trunk, we'll get a conflict when merging a branch that removes
>>>>> setup.py. This in turn means that the daily build will fail whenever
>>>>> we change setup.py.
>>>>>
>>>>> This situation isn't great, but I don't know what to do about it. Any
>>>>> thoughts?
>>>>>
>>>> Another problem (independent of this one, but also blocking the daily
>>>> builds) is that the subunit testsuite currently fails when used with the
>>>> current testtools.
>>>
>>> What's the failure?
>>>
>>> jml
>>
>> make  check-TESTS check-local
>> make[2]: Entering directory
>> `/home/jelmer/src/subunit/build-area/subunit-0.0.7'
>> Traceback (most recent call last):
>>  File "./runtests.py", line 23, in <module>
>>    from subunit.tests.TestUtil import TestVisitor, TestSuite
>>  File
>> "/home/jelmer/src/subunit/build-area/subunit-0.0.7/python/subunit/tests/__init__.py",
>> line 17, in <module>
>>    from subunit.tests import (
>>  File
>> "/home/jelmer/src/subunit/build-area/subunit-0.0.7/python/subunit/tests/test_test_protocol.py",
>> line 25, in <module>
>>    from testtools.tests.helpers import (
>> ImportError: cannot import name Python26TestResult
>
> Thanks. That's subunit importing from an old & unsupported location.
> I'm not averse to adding the import back to testtools, but I'd rather
> that subunit followed the published APIs.
Either works for me. What location should it be using (that will still 
work with older versions of testtools) ? Or perhaps Rob has a 
preference?

The merge issue (no longer?) doesn't seem to be a problem.

Cheers,

Jelmer