pyqt5 misbuild with python3.5
Bug #1477759 reported by
Steve Langasek
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
comedilib (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Wily |
Fix Released
|
High
|
Unassigned | ||
dh-python (Ubuntu) |
Fix Released
|
Critical
|
Matthias Klose | ||
Wily |
Fix Released
|
Critical
|
Matthias Klose | ||
newt (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Wily |
Fix Released
|
High
|
Unassigned | ||
pyqt5 (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Wily |
Fix Released
|
High
|
Unassigned | ||
python3.5 (Ubuntu) |
Fix Released
|
High
|
Matthias Klose | ||
Wily |
Fix Released
|
High
|
Matthias Klose |
Bug Description
pyqt5 fails its autopkgtests after rebuild with python3.5, with a failure to find the enginio module under python3.5:
testing python3.5
Traceback (most recent call last):
File "test_import.py", line 1, in <module>
from PyQt5.Enginio import EnginioClient
ImportError: No module named 'PyQt5.Enginio'
This is because the filename is wrong inside the package; the architecture string is doubled:
$ dpkg -L python3-
/usr/lib/
/usr/lib/
$
Changed in pyqt5 (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in python3.5 (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Barry Warsaw (barry) |
Changed in dh-python (Ubuntu): | |
assignee: | nobody → Barry Warsaw (barry) |
status: | New → Triaged |
importance: | Undecided → High |
Changed in python3.5 (Ubuntu Wily): | |
assignee: | Barry Warsaw (barry) → Matthias Klose (doko) |
Changed in dh-python (Ubuntu Wily): | |
assignee: | Barry Warsaw (barry) → Matthias Klose (doko) |
Changed in pyqt5 (Ubuntu Wily): | |
status: | Triaged → Fix Committed |
Changed in dh-python (Ubuntu Wily): | |
status: | Triaged → Fix Committed |
To post a comment you must log in.
This is a bug in either python3.5 or in dh-python, I'm not sure which. dh-python inspects sysconfig for the interpreter version to determine the filenames it should use. The code it runs is:
$ python3.5 __SEP__ ".join( i or "" for i in s.get_config_ vars("SOABI" ,"MULTIARCH" ,"INCLUDEPY" ,"LIBPL" ,"LDLIBRARY" ))) 35m-x86_ 64-linux- gnu__SEP_ _x86_64- linux-gnu_ _SEP__/ usr/include/ python3. 5m__SEP_ _${prefix} /lib/python3. 5/config- 3.5m-x86_ 64-linux- gnu__SEP_ _libpython3. 5m.so
>>> import sysconfig as s
>>> print("
cpython-
>>>
on python3.4, this gives:
$ python3.4 __SEP__ ".join( i or "" for i in s.get_config_ vars("SOABI" ,"MULTIARCH" ,"INCLUDEPY" ,"LIBPL" ,"LDLIBRARY" ))) 34m__SEP_ _x86_64- linux-gnu_ _SEP__/ usr/include/ python3. 4m__SEP_ _/usr/lib/ python3. 4/config- 3.4m-x86_ 64-linux- gnu__SEP_ _libpython3. 4m.so
>>> import sysconfig as s
>>> print("
cpython-
>>>
The difference between 3.4 and 3.5 is that the multiarch string is now included as *part of* the SOABI variable; so concatenating the two variables to form the filename means that the architecture name is doubled when it shouldn't be.
This is bound to cause misbuilds of a number of python extensions, which will need to be rebuilt once this is fixed.
Assuming the python3.5 behavior is a deliberate change that should not be reverted, it seems it should be a simple thing to check that the multiarch value isn't a substring of the SOABI.