bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22137: python-urwid on x86_64: AsyncEventLoopTest


From: Ludovic Courtès
Subject: bug#22137: python-urwid on x86_64: AsyncEventLoopTest
Date: Mon, 04 Jan 2016 00:02:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Leo Famulari <address@hidden> skribis:

> On Sun, Jan 03, 2016 at 03:18:23PM +0100, Ludovic Courtès wrote:
>> Leo Famulari <address@hidden> skribis:
>> 
>> > On Thu, Dec 10, 2015 at 02:05:56AM -0500, Leo Famulari wrote:
>> >> python-urwid-1.3.0 fails to build on x86_64 during the
>> >> "AsyncioEventLoopTest" test with the error "KeyError: '5 is not
>> >> registered'". It has failed repeatedly for some time now. It fails in
>> >> the same way when updated to python-urwid-1.3.1.
>> >> 
>> >> I looked for interesting changes made between the last successful build
>> >> and the first failing build. Notably, this range includes the upgrade
>> >> from python-3.3.5 to python-3.4.3 (08c04509). Asyncio was integrated
>> >> into the Python standard library in 3.4 — previously it had been an
>> >> external library. [0] Our python-3.4.3 package passes its 'test_asyncio'
>> >> test, FWIW.
>> >> 
>> >> I entered the failed build tree and successfully ran the tests using the
>> >> python-3.4.3-7 [1] installed by Debian Stretch. That only tells us so
>> >> much, but I think it does indicate either a bug in our python-3.4.3, or
>> >> some problem with python-urwid caused by the unfamiliar Guix build
>> >> environment.
>> >> 
>> >> Here's the hydra.gnu.org page:
>> >> http://hydra.gnu.org/build/861615
>> >
>> > BTW, I filed a bug upstream:
>> > https://github.com/urwid/urwid/issues/164
>> >
>> > No response yet, although I should add some more information to the bug
>> > report.
>> >
>> > In the meantime, what about downgrading python-urwid to 1.2.2 and
>> > leaving python2-urwid at 1.3.0?
>> 
>> I think it’s best to avoid introducing version differences.
>> 
>> What about disabling tests in python2-urwid in the meantime, with a
>> comment pointing to the above bug report?
>
> I assume you mean "disabling tests in python-urwid"?

Yes, sorry.

> In that case, how about just disabling that test by changing the failing
> procedure's name, as done in python-pyopenssl?

Sure, that’s even better.

Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]