[Cython] test failure for cython-devel in Py2.4

[mark florisson]

On 13 October 2011 06:10, Stefan Behnel <stefan_ml at behnel.de> wrote:
>
> mark florisson, 12.10.2011 23:46:
>>>>>
>>>>> On 10 October 2011 16:17, Stefan Behnel wrote:
>>>>>>
>>>>>> Jenkins currently reports several failures, and this one seems to be
>>>>>> due to your tempita changes:
>>>>>>
>>>>> https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/cython-devel-lxml-trunk/PYVERSION=py24/31/console
>>>>>
>>>>> Thanks! I'll try to fix that somewhere this week.
>
> We should really get to the habit of not pushing changes to the master branch that turn out to be broken in the personal branches, or, if they appear to be ok and only turn out to break the master branch *after* pushing them (which is ok, we have Jenkins to tell us), revert them if a fix cannot be applied shortly, i.e. within a day or two at most.
>
> It's very annoying when the master branch is broken for weeks in a row, especially since that means that it will keep attracting new failures due to the cover of already broken tests, which makes it much harder to pinpoint the commits that triggered them.
>

Yes I totally agree. The thing is that memoryviews on hudson were
rebased on the latest master and my Jenkins was entirely blue. So I
merged them, I don't recall checking the cython-devel-tests results,
but I think it might have only been 2.4 failing with the tempita
stuff. Unfortunately I only have a 2.3 build that is perpetually
broken on Jenkins.

At some point my fused types py3k build also got broken after merging
stuff in from  master. None of it is reproducible on my machine
though.

>>> Is it me or are other builds broken as well?
>>>
>>> I pushed a fix for the tempita thing, but it seems the entire py3k build is
>>> broken:
>>>
>>> https://sage.math.washington.edu:8091/hudson/view/All/job/cython-devel-build/54/PYVERSION=py3k/console
>
> It's not only the py3k tests, the build is broken in general. The problem here is that it only *shows* in the py3k tests because the Py2 builds do not bail out when one of the Cython modules fails to build. That needs fixing as well.
>
>
>> I just cannot reproduce that error on my system, let me investigate it
>> further.
>
> My guess was that it's due to the innocent looking change that Robert did to enable type inference for the GeneralCallNode. It seems that there was a bit more to do here.
>
> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel