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
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.
Created attachment 999002 [details] Patch to fix this bug.
That's not a proper fix. You fix it for the python3 case, but now it's broken for the python2 bindings.
(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.
I suppose one brute-force fix would be for python3-qt5-devel to depend on the the python2-based python-qt5
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.
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)?
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.
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
Thanks, using such a wrapper is definitely less bad than the alternatives considered so far.
Rats, python3 -c "import PyQt5" doesn't seem to return an error code on failure :(
Nevermind, silly user error there.
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
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
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.
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.