Python's %check has started failing in rawhide, as of python-2.7.3-26.fc19 onwards (may be related to the mass rebuild for F19, rather than python patches) I'm seeing lots of errors of the form: ====================================================================== ERROR: test_read_very_eager_A (test.test_telnetlib.ReadTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Python-2.7.3/Lib/test/test_telnetlib.py", line 99, in _read_setUp self.port = test test_telnetlib failed -- multiple errors occurred test_support.bind_port(self.sock) File "/builddir/build/BUILD/Python-2.7.3/Lib/test/test_support.py", line 308, in bind_port if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1: File "/builddir/build/BUILD/Python-2.7.3/Lib/socket.py", line 224, in meth return getattr(self._sock,name)(*args) error: [Errno 92] Protocol not available In each case, sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) is called on a socket from socket(AF_INET, SOCK_STREAM, 0) within test_support.bind_port(), but the call is failing with ENOPROTOOPT (errno 92). As it happens, the call is purely part of assertion checking in the selftests: if sock.family == socket.AF_INET and sock.type == socket.SOCK_STREAM: [...snip...] if hasattr(socket, 'SO_REUSEPORT'): if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1: raise TestFailed("tests should never set the SO_REUSEPORT " \ "socket option on TCP/IP sockets!") [...snip...] so we could code around this - but why did this start occurring? Related to the mass rebuild?
I successfully did a mock build of: python-2.7.3-27.fc19.src.rpm with fedora-devel-x86_64 on a Fedora 17 x86_64 box (i.e. without seeing the above errors).
Still failing in Koji: Building python-2.7.3-30.fc19 for rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5044950 Failed as in comment #0.
Still failing in Koji for python: Building python-2.7.3-31.fc19 for rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5074636 and also failing in same way for python3 (first time I've rebuilt python3 since the mass rebuild): Building python3-3.3.0-4.fc19 for rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5074642
Still failing in Koji: Building python-2.7.3-31.fc19 for rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5074636 and also failed for python3 in the same way (this is the first time python3 has been rebuilt since the mass rebuild): Building python3-3.3.0-4.fc19 for rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5074642
Candidate workaround committed for python to git as: http://pkgs.fedoraproject.org/cgit/python.git/commit/?id=d542bae2c2089f4a13f6aca59f0ea962997db1cf Building python-2.7.3-32.fc19 for rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5078462 Candidate workaround committed for python3 to git as: http://pkgs.fedoraproject.org/cgit/python3.git/commit/?id=260ceea047a1580c1fd10aa3ce84c4ab26d1d81f Building python3-3.3.0-5.fc19 for rawhide Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=5078496
(In reply to comment #5) Both builds succeeded
If I'm reading https://lwn.net/Articles/542629/ right, SO_REUSEPORT was only very recently added to Linux. The existence of Python's socket.SO_REUSEPORT is guarded by: #ifdef SO_REUSEPORT Was this only recently added to <socket.h> ? If so, that could explain the issue seen here.
Yes: on this f17 box: /usr/include/asm-generic/socket.h:10:#define SO_REUSEADDR 2 /usr/include/asm-generic/socket.h:25:/* To add :#define SO_REUSEPORT 15 */ kernel-headers-3.5.2-1.fc17.x86_64 >>> socket.SO_REUSEADDR 2 >>> socket.SO_REUSEPORT Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'SO_REUSEPORT' So this appears to have be due to kernel-headers starting to expose this feature, and thus it appearing in the socket module, and thus Python's selftests poking at it, but it not working due to the underlying build kernel (RHEL 5?) not supporting the feature.
...and based on that, the workaround I applied (comment #5) continues to seem reasonable: it's due to a mismatch between the kernel-headers and the actual running kernel (due to building within mock), and thus a downstream-only patch triggered by WITHIN_PYTHON_RPM_BUILD is sane.
Filed upstream as http://bugs.python.org/issue19901