Bug 1556279 - python-uvloop: FTBFS in F28
Summary: python-uvloop: FTBFS in F28
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-uvloop
Version: 28
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Igor Gnatenko
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F28FTBFS
TreeView+ depends on / blocked
 
Reported: 2018-03-14 23:34 UTC by Fedora Release Engineering
Modified: 2018-07-06 17:22 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-06 17:22:40 UTC
Type: ---


Attachments (Terms of Use)
build.log (40.62 KB, text/plain)
2018-05-28 22:12 UTC, Fedora Release Engineering
no flags Details
root.log (71.54 KB, text/plain)
2018-05-28 22:12 UTC, Fedora Release Engineering
no flags Details
state.log (643 bytes, text/plain)
2018-05-28 22:12 UTC, Fedora Release Engineering
no flags Details

Description Fedora Release Engineering 2018-03-14 23:34:42 UTC
Your package python-uvloop failed to build from source in current F28.

https://koji.fedoraproject.org/koji/taskinfo?taskID=24883378

For details on mass rebuild see https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

Comment 1 Fedora Release Engineering 2018-05-28 22:12:31 UTC
Created attachment 1444372 [details]
build.log

Comment 2 Fedora Release Engineering 2018-05-28 22:12:35 UTC
Created attachment 1444375 [details]
root.log

Comment 3 Fedora Release Engineering 2018-05-28 22:12:38 UTC
Created attachment 1444377 [details]
state.log

Comment 4 Jason Tibbitts 2018-06-20 15:39:17 UTC
For the record, I did a naïve upgrade to the current release by changing the version to 0.10.1, then spectool -g *spec and fedpkg mockbuild.  The result did build successfully.

I've no idea if updating to the latest version is appropriate (or would still work with python 3.7) or if other packaging changes would be needed, but it would at least solve the current FTBFS issue and perhaps unblock the rest of the stack.

Comment 5 Miro Hrončok 2018-06-20 16:55:33 UTC
Could you please try it with 3.7?

    fedpkg --release master  build --target=f29-python  --nowait  --srpm --scratch

If it builds, feel free to ship it. (Or open a PR and link it here.)

Comment 6 Jason Tibbitts 2018-06-20 18:26:49 UTC
Oddly, it builds fine on some arches but fails hard on i686 and armv7hl.  I'm not waiting around for a s390x builder, but if it succeeds there then I guess there's a problem with 32 bit architectures.  The set of test failures appears to be identical.

https://koji.fedoraproject.org/koji/taskinfo?taskID=27755506

Looking at some of the build output, it definitely hits some deprecations:

uvloop/loop.c: In function ‘__pyx_f_6uvloop_4loop_9UVProcess__after_fork’:
uvloop/loop.c:103098:3: warning: ‘PyOS_AfterFork’ is deprecated [-Wdeprecated-declarations]
   PyOS_AfterFork();
   ^~~~~~~~~~~~~~
In file included from /usr/include/python3.7m/Python.h:125,
                 from uvloop/loop.c:20:
/usr/include/python3.7m/intrcheck.h:18:18: note: declared here
 PyAPI_FUNC(void) PyOS_AfterFork(void) Py_DEPRECATED(3.7);
                  ^~~~~~~~~~~~~~

but the 32-bit failures are in the test suite.  All of the failures I looked at are basically identical (regardless of architecture) and take this form:

ERROR: test_call_later_2 (test_base.TestBaseUV)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/uvloop-0.10.1/uvloop/_testbase.py", line 81, in setUp
    self.loop = self.new_loop()
  File "/builddir/build/BUILD/uvloop-0.10.1/uvloop/_testbase.py", line 299, in new_loop
    return uvloop.new_event_loop()
  File "/builddir/build/BUILD/uvloop-0.10.1/uvloop/__init__.py", line 20, in new_event_loop
    return Loop()
  File "uvloop/loop.pyx", line 110, in uvloop.loop.Loop.__cinit__
    self._transports = weakref_WeakValueDictionary()
TypeError: 'NoneType' object is not callable


I don't really know anything about this package or Python internals as I was just trying to see if an update would build.  So I probably don't have anything else to offer here.  But do note that a build on plain rawhide does appear to succeed: https://koji.fedoraproject.org/koji/taskinfo?taskID=27755604 so this appears to be something new with python 3.7.

Comment 7 Jason Tibbitts 2018-06-20 18:42:42 UTC
Well I guess there is one more thing I can do, which is to try an update to the master branch.  Unfortunately there's no real difference: https://koji.fedoraproject.org/koji/taskinfo?taskID=27755886

Ignore the version; I just hacked in a github checkout and didn't change anything else.

Comment 8 Miro Hrončok 2018-06-21 13:22:50 UTC
https://github.com/MagicStack/uvloop/issues/172

Comment 9 Jerry James 2018-06-22 04:26:01 UTC
See the URL in comment 8 for the real issue, which was that thread IDs do not fit into the C long type on 32-bit platforms.  I added a patch for that and just did a successful build in the f29-python tag.

Comment 10 Victor Stinner 2018-06-26 11:37:02 UTC
Bug fixed upstream in version 0.10.2.

https://github.com/MagicStack/uvloop/issues/172 has been fixed by https://github.com/MagicStack/uvloop/commit/700582a9bfce73efb001c45ad3bd888335f7e2a7 and the release 0.10.2 includes the fix:
https://github.com/MagicStack/uvloop/releases/tag/v0.10.2

Comment 11 Zbigniew Jędrzejewski-Szmek 2018-07-06 17:22:40 UTC
A build was successfull: python-uvloop-0.8.1-1.fc28 [1].
No update was found in bodhi. Closing the bug nonetheless.

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=970026


Note You need to log in before you can comment on or make changes to this bug.