Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests fail due to unsupported SO_REUSEPORT when building Python 3.3.2-r2 #64100

Closed
RubyTuesdayDONO mannequin opened this issue Dec 5, 2013 · 7 comments
Closed

tests fail due to unsupported SO_REUSEPORT when building Python 3.3.2-r2 #64100

RubyTuesdayDONO mannequin opened this issue Dec 5, 2013 · 7 comments
Assignees
Labels
build The build process and cross-build easy type-bug An unexpected behavior, bug, or error

Comments

@RubyTuesdayDONO
Copy link
Mannequin

RubyTuesdayDONO mannequin commented Dec 5, 2013

BPO 19901
Nosy @gpshead, @davidmalcolm

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = 'https://github.com/gpshead'
closed_at = <Date 2013-12-07.19:35:25.902>
created_at = <Date 2013-12-05.20:59:45.945>
labels = ['easy', 'type-bug', 'build']
title = 'tests fail due to unsupported SO_REUSEPORT when building Python 3.3.2-r2'
updated_at = <Date 2013-12-16.13:08:52.748>
user = 'https://bugs.python.org/RubyTuesdayDONO'

bugs.python.org fields:

activity = <Date 2013-12-16.13:08:52.748>
actor = 'RubyTuesdayDONO'
assignee = 'gregory.p.smith'
closed = True
closed_date = <Date 2013-12-07.19:35:25.902>
closer = 'gregory.p.smith'
components = ['Build']
creation = <Date 2013-12-05.20:59:45.945>
creator = 'RubyTuesdayDONO'
dependencies = []
files = []
hgrepos = []
issue_num = 19901
keywords = ['easy']
message_count = 7.0
messages = ['205320', '205343', '205479', '206073', '206074', '206202', '206302']
nosy_count = 3.0
nosy_names = ['gregory.p.smith', 'dmalcolm', 'RubyTuesdayDONO']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue19901'
versions = ['Python 3.3', 'Python 3.4']

@RubyTuesdayDONO
Copy link
Mannequin Author

RubyTuesdayDONO mannequin commented Dec 5, 2013

When building Python 3.3.2-r2 from Gentoo's Portage tree 1, I encountered two failed tests which probably should not have been attempted on my OS (Gentoo 3.7.10): test_bind_port and test_find_unused_port both use the SO_REUSEPORT socket option which, to the best of my knowledge is only available since kernel version 3.9. I was able to build by skipping the tests — but I believe the tests are there for a reason, and it would be best if a test that is known to fail should be skipped (or replaced with a fallback that is likely to succeed). Issue bpo-16594 3 may be related (not sure).

Is it possible to detect the kernel version and skip (or modify) these tests if SO_REUSEPORT is not available? Better yet (since even a 3.9 kernel could have it disabled) — try the test with SO_REUSEPORT, but trap the exception for lack of OS support, print a warning, and try again without SO_REUSEPORT.

+=== excerpt of portage build log:
======================================================================
ERROR: test_bind_port (test.test_support.TestSupport)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/test_support.py", line 87, in test_bind_port
    support.bind_port(s)
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py", line 548, in bind_port
    if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1:
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_find_unused_port (test.test_support.TestSupport)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/test_support.py", line 80, in test_find_unused_port
    port = support.find_unused_port()
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py", line 522, in find_unused_port
    port = bind_port(tempsock)
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py", line 548, in bind_port
    if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1:
OSError: [Errno 92] Protocol not available
===+

@RubyTuesdayDONO RubyTuesdayDONO mannequin added the build The build process and cross-build label Dec 5, 2013
@gvanrossum gvanrossum added the easy label Dec 5, 2013
@davidmalcolm
Copy link
Member

[FWIW, this looks similar to an issue I ran into on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=913732
which was due to a mismatch between the kernel headers on the system vs the actually running kernel. I patched around it there with a downstream-only patch (our builds are done on chroots on RHEL-5 boxes, so such mismatches tend to occur)]

@gpshead
Copy link
Member

gpshead commented Dec 7, 2013

I fixed this in 3.3 and 3.4 several weeks ago.

http://hg.python.org/cpython/rev/9791c5d55f52
http://hg.python.org/cpython/rev/00766fa3366b

@gpshead gpshead closed this as completed Dec 7, 2013
@gpshead gpshead self-assigned this Dec 7, 2013
@gpshead gpshead added the type-bug An unexpected behavior, bug, or error label Dec 7, 2013
@RubyTuesdayDONO
Copy link
Mannequin Author

RubyTuesdayDONO mannequin commented Dec 13, 2013

On Sat, Dec 7, 2013 at 1:35 PM, Gregory P. Smith <report@bugs.python.org>wrote:

I fixed this in 3.3 and 3.4 several weeks ago.

@RubyTuesdayDONO
Copy link
Mannequin Author

RubyTuesdayDONO mannequin commented Dec 13, 2013

On Sat, Dec 7, 2013 at 1:35 PM, Gregory P. Smith <report@bugs.python.org>
wrote:

I fixed this in 3.3 and 3.4 several weeks ago.

Sorry for the duplicate message a few moments ago … "fat-fingered" my send
button.

So, has the fix just not reached the Portage tree yet? I don't fully
understand how upstream commits reach Portage, and would appreciate any
direction you might have to avoid reporting something already fixed.

@gpshead
Copy link
Member

gpshead commented Dec 14, 2013

You didn't do anything wrong. You were running 3.3.3 which is the latest release of 3.3. Portage is Gentoo's thing, you'd have to ask the gentoo python portage ebuild maintainer and point them at the commit with the additional patch to apply if you want it fixed there. (or file a bug on gentoo's bug tracking system and point it at this one)

In general gentoo is one of the more up to date distros (compared to everything else) but it is always helpful to try checking out and compiling the latest source tree from hg.python.org as described in http://docs.python.org/devguide/ (on the 3.3 branch in your case) when reporting an issue.

I just happened to have noticed this problem myself and fixed it without bothering to file an issue about it a few weeks before you ran into it. :)

@RubyTuesdayDONO
Copy link
Mannequin Author

RubyTuesdayDONO mannequin commented Dec 16, 2013

On Sat, Dec 14, 2013 at 2:38 PM, Gregory P. Smith <report@bugs.python.org>
wrote:

ask the gentoo python portage ebuild maintainer and point them at the
commit with the additional patch to apply if you want it fixed there. (or
file a bug on gentoo's bug tracking system and point it at this one)

try checking out and compiling the latest source tree from hg.python.orgas described in
http://docs.python.org/devguide/ (on the 3.3 branch in your case) when
reporting an issue.

That's actually really good advice (applicable to other projects beyond
Python) — thank you so much, Gregory!

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build The build process and cross-build easy type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

3 participants