Bug 1193107 - wrong python release used in pyuic5 launch script from the python3-qt5-devel package
Summary: wrong python release used in pyuic5 launch script from the python3-qt5-devel ...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: python-qt5
Version: 21
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-16 15:12 UTC by adrien
Modified: 2015-08-25 16:16 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-08-25 16:16:26 UTC


Attachments (Terms of Use)
Patch to fix this bug. (114 bytes, patch)
2015-03-06 21:09 UTC, Peter Brantsch
no flags Details | Diff

Description adrien 2015-02-16 15:12:06 UTC
Description of problem:

the launch script of the pyuic5 program from the python3-qt5-dev package use the wrong python release:

the /usr/bin/pyuic5 script is :
#!/bin/sh
exec /usr/bin/python2 -m PyQt5.uic.pyuic ${1+"$@"}

and it should be :
#!/bin/sh
exec /usr/bin/python3 -m PyQt5.uic.pyuic ${1+"$@"}


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Try to launch the pyuic5 program
2.
3.

Actual results:

python2 crash because he can't find pyqt5 module

Expected results:

Additional info:
This is my first bug report ever, I tried to do my best

Comment 1 Rex Dieter 2015-03-06 21:05:55 UTC
Hrm, we build both python2 and python3 bindings, and both want to provide a /usr/bin/pyuic5

I'll have to look closer and/or rename one or both of them.

Comment 2 Peter Brantsch 2015-03-06 21:09:51 UTC
Created attachment 999002 [details]
Patch to fix this bug.

Comment 3 Rex Dieter 2015-03-07 20:09:05 UTC
That's not a proper fix.  You fix it for the python3 case, but now it's broken for the python2 bindings.

Comment 4 Peter Brantsch 2015-03-08 00:45:27 UTC
(In reply to Rex Dieter from comment #3)
> That's not a proper fix.  You fix it for the python3 case, but now it's
> broken for the python2 bindings.

I fixed it for the python3 case, because this bug relates to the python3-qt5-devel package.

As an alternative to renaming at least one of the scripts, I suggest having the script first try python2, and if that fails, python3, or vice versa.
Any python code generated by the PyQt5 UI code generator which I have seen was not obviously specific to python2 or python3.

Comment 5 Rex Dieter 2015-06-05 18:43:49 UTC
I suppose one brute-force fix would be for python3-qt5-devel to depend on the the python2-based python-qt5

Comment 6 Rex Dieter 2015-06-05 18:46:46 UTC
that feels wrong though, I think I'll go with renaming the binaries (to not conflict with python2 ones):

pylupdate5 => py3lupdate5
pyrcc5 => py3rcc5
pyuic5 => py3uic5


Better ideas welcome.

Comment 7 Sandro Mani 2015-06-05 23:46:43 UTC
Do these programs really produce python-version dependent code? If not, how about just using the unversioned /usr/bin/python and including these scripts in both the python2 and python3 packages, making sure the files are identical (i.e have the package co-own the scripts)?

Comment 8 Rex Dieter 2015-06-05 23:56:46 UTC
They require the python-qt5 runtime too, would it be annoying to need
(python2-based) python-qt5 in order to use python3-qt5-devel (or vice-versa)?

I'm also working on a proof-of-concept use of alternatives here, but I'm not sure how crazy that is.

Comment 9 Sandro Mani 2015-06-06 00:02:16 UTC
Oh, right. Well in that case how about something along the lines

#!/bin/sh
python3 -c "import PyQt5" &> /dev/null
if [ $? -eq 0 ]; then
  exec /usr/bin/python3 -m PyQt5.uic.pyuic ${1+"$@"}
else
  exec /usr/bin/python2 -m PyQt5.uic.pyuic ${1+"$@"}
fi

Comment 10 Rex Dieter 2015-06-06 00:09:21 UTC
Thanks, using such a wrapper is definitely less bad than the alternatives considered so far.

Comment 11 Rex Dieter 2015-06-06 00:31:46 UTC
Rats, 

python3 -c "import PyQt5"

doesn't seem to return an error code on failure :(

Comment 12 Rex Dieter 2015-06-06 00:38:42 UTC
Nevermind, silly user error there.

Comment 13 Fedora Update System 2015-06-06 14:13:10 UTC
sip-4.16.7-2.fc22,PyQt4-4.11.3-5.fc22,pykde4-4.14.3-5.fc22,python-qt5-5.4.1-5.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/sip-4.16.7-2.fc22,PyQt4-4.11.3-5.fc22,pykde4-4.14.3-5.fc22,python-qt5-5.4.1-5.fc22

Comment 14 Fedora Update System 2015-06-06 14:14:50 UTC
sip-4.16.7-2.fc21,PyQt4-4.11.3-5.fc21,pykde4-4.14.3-5.fc21,python-qt5-5.4.1-5.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/sip-4.16.7-2.fc21,PyQt4-4.11.3-5.fc21,pykde4-4.14.3-5.fc21,python-qt5-5.4.1-5.fc21

Comment 15 Fedora Update System 2015-06-21 00:17:12 UTC
sip-4.16.7-2.fc22, PyQt4-4.11.3-5.fc22, pykde4-4.14.3-5.fc22, python-qt5-5.4.1-5.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2015-06-22 10:37:00 UTC
sip-4.16.7-2.fc21, PyQt4-4.11.3-5.fc21, pykde4-4.14.3-5.fc21, python-qt5-5.4.1-5.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


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