Description of problem: Trying out the Hello world: http://blog.qt.io/blog/2018/05/04/hello-qt-for-python/ Traceback (most recent call last): File "./tool.py", line 5, in <module> from PySide2.QtCore import Qt # dnf --enablerepo=rawhide search pyside2 Last metadata expiration check: 0:02:26 ago on Mon 01 Oct 2018 12:38:41 PM EEST. No matches found. Version-Release number of selected component (if applicable): Fedora release 28 (Twenty Eight) Additional info: # dnf --enablerepo=rawhide search pyside Fedora - Rawhide - Developmental packages for the next Fedora release 10 MB/s | 63 MB 00:06 Last metadata expiration check: 0:00:25 ago on Mon 01 Oct 2018 12:38:41 PM EEST. pyside-tools.x86_64 : Development tools for PySide python2-pyudev-pyside.noarch : PySide integration for pyudev python-pyside-devel.x86_64 : Development files for python-pyside python2-pyside.x86_64 : Python bindings for Qt4 python3-pyside.x86_64 : Python bindings for Qt4 python2-QtAwesome.noarch : FontAwesome icons in PyQt and PySide applications python3-QtAwesome.noarch : FontAwesome icons in PyQt and PySide applications Pyside2 would be "Python bindings for Qt5".
We are not responsible for the stuff that is not packaged. You can ask on Fedora devel mailing list whether somebody want's to package this or do it yourself. There is also https://fedoraproject.org/wiki/Package_maintainers_wishlist As a workaround, you can use PyQt5 bindings packaged as python3-qt5. Or, use virtual environment and pip as described at https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html
Also ccing python-qt5 maintainers, so they are aware of this.
This was supposed to be tracking entry for the topic - and it will, is it closed or not.
OK. Reopening, but changing component.
(In reply to Miro Hrončok from comment #4) > OK. Reopening, but changing component. Thanks.
making as Tracking bug to avoid autoclose Though I will echo previous sentiments, tracking bugs are generally only created when there is concrete (agreed-upon) work to be done by maintainers. it less less appropriate for tracking wishlist items.
So, how huge beast that is to package and is python3-pyside kosher for template?
Fwiw, anyone that wants a solution now/asap, I'd recommend sticking with PyQt5 that is packaged in fedora already, which should be largely compatible, per comment from the aforementioned blog author at: http://blog.qt.io/blog/2018/05/04/hello-qt-for-python/#comment-1203223 ".... Since both projects keep the Qt API, most of the time the only difference is the import statement."
> Qt for Python is a fully supported feature of Qt 5.12. > Everything you can do in C++ with Qt, you can now do with Python instead. https://www.qt.io/press/the-qt-company-introduces-qt-512-the-latest-version-of-its-framework-for-the-creation-of-fast-high-quality-applications-and-user-interfaces
FreeCAD decided to use PySide over PyQt so this is preventing me from updating it from Qt4... Unfortunately I don't have time to maintain another package right now.
Created attachment 1527111 [details] python-pyside2.spec draft I'ved rafted a spec file for pyside2. it fails to locate clang now, and I have no idea why it needs both gcc and clang. It also probably bundles other stuff. So as said, far from perfect. But anybody want to dive into it, feel free to take it. Richard, if you have time to at least make the package into Fedora, i can help you maintain it longterm, however I don't have time to make this work at this moment.
I got a little further... Now it's failing the cmake check for c++ compiler (but I got the clang/llvm stuff fixed)... -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - failed -- Detecting CXX compile features -- Detecting CXX compile features - failed I'll have to dig into the cmake stuff to see what it's trying to do. Maybe it just doesn't get gcc 9.x...
(In reply to Miro Hrončok from comment #11) > I'ved rafted a spec file for pyside2. it fails to locate clang now, and I > have no idea why it needs both gcc and clang. gcc is the system compiler for Fedora, and Pyside2 requires libclang. That is documented here: https://wiki.qt.io/Qt_for_Python/GettingStarted The `BuildRequires` should be `clang-devel` instead of `clang`.
Yes, already got those corrected but don't know why the C++ cmake check is failing, that one is new to me... Maybe just a cmake config error on their part, if they're exclusively using clang then they should set it in the cmake config...
Bah... Fixed the C++ issue... They don't do a very good job of setting the compiler so I had to add: export C="/usr/bin/clang" export CXX="/usr/bin/clang++" %py3_build But I still get an error: /builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/shiboken2/ApiExtractor/typesystem.cpp:168:20: error: no member named 'compare' in 'QStringView' return e1.name.compare(e2.name, cs) == 0; ~~~~~~~ ^
`QStringView::compare` was introduced in Qt 5.12: https://doc.qt.io/Qt-5/qstringview.html#compare If you are using Qt-5.11, then tou should compile Pyside2 and Shiboken from the branches 5.11 as well.
I went with 5.11.3 when I started because that's the last version I saw at https://koji.fedoraproject.org/koji/packageinfo?packageID=22646
(In reply to Richard Shaw from comment #15) > But I still get an error: > > /builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/shiboken2/ > ApiExtractor/typesystem.cpp:168:20: error: no member named 'compare' in > 'QStringView' > return e1.name.compare(e2.name, cs) == 0; > ~~~~~~~ ^ The name of your build directory `pyside-setup-everywhere-src-5.12.1` seems to indicate that you were not building pyside2 from the branch corresponding to Qt-5.11. When you prepare your source package, from Git, be careful to chose the branch named `5.11.3`. See all the branches at http://code.qt.io/cgit/pyside/pyside-setup.git/refs/
Freenode IRC channel #qt-pyside @2019-02-07: > <crmaurei> Tuju: I would recommend to stick with 5.12, since 5.11 was a Technical Preview
(In reply to Laurent Rineau from comment #18) > (In reply to Richard Shaw from comment #15) > > But I still get an error: > > > > /builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/shiboken2/ > > ApiExtractor/typesystem.cpp:168:20: error: no member named 'compare' in > > 'QStringView' > > return e1.name.compare(e2.name, cs) == 0; > > ~~~~~~~ ^ > > The name of your build directory `pyside-setup-everywhere-src-5.12.1` seems > to indicate that you were not building pyside2 from the branch corresponding > to Qt-5.11. When you prepare your source package, from Git, be careful to > chose the branch named `5.11.3`. See all the branches at > http://code.qt.io/cgit/pyside/pyside-setup.git/refs/ I wasn't aware they had to match... I found links for actual archives which is preferred over a git snapshot for packaging purposes. https://download.qt.io/official_releases/QtForPython/pyside2/ (In reply to Juha Tuomala from comment #19) > Freenode IRC channel #qt-pyside @2019-02-07: > > <crmaurei> Tuju: I would recommend to stick with 5.12, since 5.11 was a Technical Preview Not sure what to do there, for one, it's not compiling and per the previous reply they need to match the version of Qt.
(In reply to Richard Shaw from comment #20) > (In reply to Juha Tuomala from comment #19) > > Freenode IRC channel #qt-pyside @2019-02-07: > > > <crmaurei> Tuju: I would recommend to stick with 5.12, since 5.11 was a Technical Preview > > Not sure what to do there, for one, it's not compiling and per the previous > reply they need to match the version of Qt. It's probably more important that c++ and python versions match than having the non-preview version. It's up to Qt-people in Fedora project to decide what is the version that is in release (and worth of own bug report).
It's Qt that 5.12 is the stable release and 5.11 the Technical Preview, but that's what's packaged in Rawhide so that's what I have to use for PySide2. Getting though all the issues has been terribly slow because I can't get parallel builds to work. It uses setuptool to call cmake and cmake directly calls "make" so I haven't found a way to inject "%{_smp_mflags}". I was able to find a variable "JOB_OPTIONS" or something like that but I haven't been able to untangle the web of setuptools files to figure out where it's set. "python3 setup.py --help" is NO HELP. It also currently bundled apiextractor and shiboken2, the latter isn't a problem since it's not packaged in Fedora. I've got everything building now but stuck here: BUILDSTDERR: error: Missing build-id in /builddir/build/BUILDROOT/python-pyside2-5.11.2-1.fc30.x86_64/usr/lib64/python3.7/site-packages/PySide2/pyside2-rcc BUILDSTDERR: error: Missing build-id in /builddir/build/BUILDROOT/python-pyside2-5.11.2-1.fc30.x86_64/usr/lib64/python3.7/site-packages/PySide2/pyside2-lupdate BUILDSTDERR: error: Missing build-id in /builddir/build/BUILDROOT/python-pyside2-5.11.2-1.fc30.x86_64/usr/lib64/python3.7/site-packages/PySide2/shiboken2 BUILDSTDERR: error: Generating build-id links failed
I was missing python3-wheel when running python3 setup.py --help so I see the options now, however, neither --verbose or %{_smp_mflags} is passed to CMake.
(In reply to Richard Shaw from comment #23) > I was missing python3-wheel when running python3 setup.py --help so I see > the options now, however, neither --verbose or %{_smp_mflags} is passed to > CMake. Are you already able to get it to the end and have something installable?
Working on it... Without parallel builds working every build attempt takes forever.
It accepted the --debug option but I'm still getting the error above. I give up for now. Anyone else want to take a shot at it? https://hobbes1069.fedorapeople.org/python-pyside2-5.11.2-1.fc29.src.rpm
FYI, Qt-5.12.x should be coming to rawhide soonish (I'd hoped to do it last week, but then the mass-rebuild-rpmsign-opocalypse happened). You can follow progress in bug #1661849
Ok, i'll make that bug blocking for now and try again when complete.
The PySide2's setup.py docuemnts --parallel as an option [0], but with 5.11.3 it wasn't accepted. This is what I've tried to do: %global py_setup_args --qmake=/usr/bin/qmake-qt5 --build-tests --ignore-git %{?_smp_mflags:--parallel=%(echo %{_smp_mflags} | sed 's/-j//')} %build %py3_build ... However I got something like "unrecognized option --parallel". Maybe it was introduced in 5.12.x. [0] https://wiki.qt.io/Qt_for_Python/GettingStarted/X11
`--jobs`` was deprecated around 5.11.13 so it didn't got into that version, but for 5.12.0 (the official release), and as you pointed out, the option now is `--parallel`. 5.11.x are still part of the Technical Preview releases, so I highly recommend to work on a package based on 5.12.0 or 5.12.1, since those are the official release versions. Regarding the errors you pointed out Richard, it could be related to the fact that those are 'sub-proeject' of the whole PySide2 package. Please check this out: https://bugreports.qt.io/browse/PYSIDE-749 The setup.py currently is splitted into building sub-projects besides PySide2. Also, by default the build process is `verbose`, we opted to have that behavior as default (you have the --quiet option though...) If there are more questions, the devs are in the channel #qt-pyside on Freenode. Cheers
(In reply to Cristián Maureira-Fredes from comment #30) > 5.11.x are still part of the Technical Preview releases, so I highly > recommend to work on a package based on 5.12.0 or 5.12.1, since those are > the official release versions. Any idea is this change https://bugreports.qt.io/browse/QTBUG-54877 Implement client SSL certificates included into python bindings and working? Or does it have to be taken care/activated in build time/packaging? It looks like it's related to WebEngine but maybe it can be used in all TCP-connections as well? Last comment is about qtnetwork > Ah that reminds me that I need to fix the ifdefs. I > changed qtnetwork so QSslCertificate could still be used without openssl. Anyway, it looks they committed it to 5.12 so I'm supporting that version, unlike i mentioned earlier comments.
(In reply to Miro Hrončok from comment #29) > The PySide2's setup.py docuemnts --parallel as an option [0], but with > 5.11.3 it wasn't accepted. This is what I've tried to do: > > %global py_setup_args --qmake=/usr/bin/qmake-qt5 --build-tests --ignore-git > %{?_smp_mflags:--parallel=%(echo %{_smp_mflags} | sed 's/-j//')} > > %build > %py3_build > ... > > However I got something like "unrecognized option --parallel". Maybe it was > introduced in 5.12.x. Nope, the problem is whatever you put in %Py_setup_args is inserted in front of build/install instead of after... Which to me makes it useless... I'll go with: %py3_build - -build-tests --ignore-git %{?_smp_mflags:--parallel=%(echo %{_smp_mflags} | sed 's/-j//')} I haven't had any problem with it finding qmake...
Getting through the build but now hitting a build id issue... explicitly decompress any DWARF compressed ELF sections in /builddir/build/BUILDROOT/python-pyside2-5.12.1-1.fc31.s390x/usr/lib64/python3.7/site-packages/PySide2/pyside2-lupdate extracting debug info from /builddir/build/BUILDROOT/python-pyside2-5.12.1-1.fc31.s390x/usr/lib64/python3.7/site-packages/PySide2/pyside2-lupdate BUILDSTDERR: *** ERROR: No build ID note found in /builddir/build/BUILDROOT/python-pyside2-5.12.1-1.fc31.s390x/usr/lib64/python3.7/site-packages/PySide2/pyside2-lupdate BUILDSTDERR: /usr/lib/rpm/find-debuginfo.sh: line 478: /tmp/find-debuginfo.3NfdNL/res.*: No such file or directory https://koji.fedoraproject.org/koji/taskinfo?taskID=33167114 https://kojipkgs.fedoraproject.org//work/tasks/7119/33167119/build.log
Build log: Bytecompiling .py files below /builddir/build/BUILDROOT/python-pyside2-5.12.1-1.fc31.x86_64/usr/lib64/python3.7 using /usr/bin/python3.7 + /usr/lib/rpm/brp-python-hardlink + /usr/lib/rpm/redhat/brp-mangle-shebangs BUILDSTDERR: *** ERROR: ambiguous python shebang in /usr/lib64/python3.7/site-packages/PySide2/scripts/pyside_tool.py: #!/usr/bin/env python. Change it to python3 (or python2) explicitly. https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error > *** ERROR: ambiguous python shebang in /usr/bin/taskotron_result: #!/usr/bin/python. > Change it to python3 (or python2) explicitly. > The script will exit with nonzero exit code, rendering the build failed. > > The warning and a promise of the error was there for 2 releases (28 and 29). Taskotron check was also present. > > There are standard mechanics to avoid this buildroot policy script or to block certain files form it. > Those remain intact by this change. For details see Shebang lines and BuildRoot Policy Scripts > sections of the packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_shebang_lines (lists switches how to disable if needed) https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts Not sure if this helps or not.
Don't disable, just fix or remove the shebang please.
Juha, it looks like we're both working on the package right now which doesn't make sense. If you like I can setup a pagure project so we can at least work from the same source. I'm using the python fixup script to fix the shebangs in mine.
(In reply to Richard Shaw from comment #36) > Juha, it looks like we're both working on the package right now I'm not working with anything. What makes you think so?
(In reply to Juha Tuomala from comment #37) > (In reply to Richard Shaw from comment #36) > > Juha, it looks like we're both working on the package right now > > I'm not working with anything. What makes you think so? (In reply to Juha Tuomala from comment #34) > Build log: > Bytecompiling .py files below > /builddir/build/BUILDROOT/python-pyside2-5.12.1-1.fc31.x86_64/usr/lib64/ > python3.7 using /usr/bin/python3.7 > + /usr/lib/rpm/brp-python-hardlink > + /usr/lib/rpm/redhat/brp-mangle-shebangs > BUILDSTDERR: *** ERROR: ambiguous python shebang in > /usr/lib64/python3.7/site-packages/PySide2/scripts/pyside_tool.py: > #!/usr/bin/env python. Change it to python3 (or python2) explicitly. Based on the output here I thought you were attempting to build the package.
(In reply to Richard Shaw from comment #38) > Based on the output here I thought you were attempting to build the package. I was reading your build attempt log and had a moment to spare so tried to help. If you're able to finish the package (it's almost there), I will try it and report here. So far don't even have a single spec on my disk nor any attempt to pkg it. Keep on going, you're doing just fine.
The last output I had with the missing build id means the package completely built but rpmbuild doesn't like that particular binary because it's not connected to a build id which I think is used for debuginfo or debugsource packages. I don't have a lot of experience fixing those and this package using setuptool to kick off cmake to build using qmake is complicated :)
(In reply to Richard Shaw from comment #40) > because it's not > connected to a build id which I think is used for debuginfo or debugsource > packages. I don't have a lot of experience fixing those and this package > using setuptool to kick off cmake to build using qmake is complicated :) https://bugzilla.redhat.com/show_bug.cgi?id=1547952 > you should build the package with -g flag so that debugging information is generated during build. > find-debuginfo.sh which is now being automatically run will then be satisfied. So I recommend > adding -g into CXXFLAGS in your Makefile. Then it should start to work. > > (There is also a possibility of including %global debug_package %{nil} at the beginning of > your spec but I would really recommend using "-g" instead). https://docs.fedoraproject.org/en-US/packaging-guidelines/Debuginfo/ > It is normal for noarch package builds to not produce a debuginfo package. Also more comments about -g and FLAGS. https://bugzilla.redhat.com/show_bug.cgi?id=192422 > For this package, adding an empty %build seems to solve the problem. Any help?
Kinda... I haven't had time to investigate the logs but it's probably not getting built with -g, however, CXXFLAGS are set but may not be picked up for the aforementioned (setuptools->cmake->qmake) mess.
Looking at the log I see this: Running process in directory /builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/pyside3d_build/py3.7-qt5.12.1-64bit-debug/pyside2-tools: command /usr/bin/cmake -G "Unix Makefiles" -DBUILD_TESTS=True -DQt5Help_DIR=/usr/share/doc/qt5 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/pyside3d_install/py3.7-qt5.12.1-64bit-debug /builddir/build/BUILD/pyside-setup-everywhere-src-5.12.1/sources/pyside2-tools -DPYTHON_EXECUTABLE=/usr/bin/python3 -DPYTHON_INCLUDE_DIR=/usr/include/python3.7m -DPYTHON_LIBRARY=/usr/lib64/libpython3.7m.so -DQT_SRC_DIR=/Src/qtbase -DPYTHON_DEBUG_LIBRARY=/usr/lib64/libpython3.7m.so -DPACKAGE_SETUP_PY_PACKAGE_VERSION=5.12.1 -DPACKAGE_SETUP_PY_PACKAGE_TIMESTAMP= -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=yes -DUSE_PYTHON_VERSION=3.3 Which shows -DCMAKE_BUILD_TYPE=Debug but the build is not verbose (even though I have that enabled for setuptools), so I can't inspect the flags. If I could use mock to build instead of having to use koji I could shell into the chroot and figure it out... But it doesn't have Qt 5.12.1 yet.
Inside the `setup.py` you can find many options for the setup process. One of them is `--verbose-build` that will give you more information of the building process itself. From what I understood from the logs, the problem lies on some internal mechanism of the script "find-debuginfo.sh", do you really need to generate a package in Debug mode? Here you can find an example that I use for development purposes: python setup.py install --qmake=/path/to/your/qtbase/bin/qmake --debug --build-tests --ignore-git --parallel=X --make-spec=ninja --verbose-build --limited-api=no Please take into account that I use `--limited-api=no` because my Python include debug symbols (pydebug) and that's not compatible with the limited-api. For a normal release I would rather use: python setup.py install --qmake=/path/to/your/qtbase/bin/qmake --build-tests --ignore-git --parallel=X --make-spec=ninja --verbose-build
(In reply to Richard Shaw from comment #43) > If I could use mock to build instead of having to use koji I could shell > into the chroot and figure it out... But it doesn't have Qt 5.12.1 yet. Try mock with --enablerepo=local
Ok, I had --verbose but not --verbose-build... I don't see it in the options though... Bah... using --enablerepo=local has a missing package gcc 9.0.1... I'm pretty just it just uses cxx w/ clang so I may just reassign the C compiler to clang and be done with it. One scratch build it installed a bunch of pure python stuff to /usr/lib so I added lines for %{python3_sitelib} and then did another build and nothing was installed as noarch. I can't win today.
Ok, back here again... I temporarily added a patch to make the cmake build verbose for pyside2-lupdate and it was getting -g so I'm stuck: BUILDSTDERR: error: Missing build-id in /builddir/build/BUILDROOT/python-pyside2-5.12.1-1.fc31.x86_64/usr/lib64/python3.7/site-packages/PySide2/pyside2-lupdate BUILDSTDERR: error: Missing build-id in /builddir/build/BUILDROOT/python-pyside2-5.12.1-1.fc31.x86_64/usr/lib64/python3.7/site-packages/PySide2/pyside2-rcc
Ok, and the i686 build completed so I'm not sure what the difference is... https://koji.fedoraproject.org/koji/taskinfo?taskID=33215202
For some reason it's either losing the build-id or not generating DWARF debug info on 64bit but is on 32bit? Should I open a bug against clang?
Ok, with the latest rawhide compose I can finally build locally in mock. I still get the same error but when I shell into the mock chroot I can see: # file usr/lib64/python3.7/site-packages/PySide2/pyside2-lupdate usr/lib64/python3.7/site-packages/PySide2/pyside2-lupdate: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=7443aef494160064e68d6b2e9538c36fec152e01, with debug_info, not stripped # file usr/lib64/python3.7/site-packages/PySide2/pyside2-rcc usr/lib64/python3.7/site-packages/PySide2/pyside2-rcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=fbcdeee15c0583b25020496bbd1c63c84f03a351, with debug_info, not stripped Should I resort to: %undefine _missing_build_ids_terminate_build ???
For now, yes, I'm, the workaround is acceptable
Ok, I got a "good" build. I still need to break things up into subpackages. I suppose I should follow the same package breakdown as the current tools? Thils build tries to break it into rational sub-packages but I'm sure there is more work to do. I haven't yet added any interdependencies between packages. https://koji.fedoraproject.org/koji/taskinfo?taskID=33340496 Constructive criticism welcomed :)
[tuju@wasa]~/% rpmbuild -ba SPECS/python-pyside2.spec Error: missing dependencies: qt5-devel >= 5.12 is needed by python-pyside2-5.12.1-1.fc28.x86_64 [tuju@wasa]~/% cat /etc/system-release Fedora release 28 (Twenty Eight) [tuju@wasa]~/%
I'm upgradin now, will try again later and report how it works.
It's not expected to build on less than f30... I've been using mock (now that it works) and koji scratch-builds.
I have the subpackages broken out to something reasonable[1] and trying to work on getting inter-package dependencies right. Doing that I noticed that python3-pyside package requires the libshiboken2 python module but no package was providing it. Upon further inspection I found out it's not getting installed to the buildroot so I have opened a ticket at QT[2]. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=33457361 [2] https://bugreports.qt.io/browse/PYSIDE-970
Ok guys, I need some input here. After searching around I found that Arch just does a straight cmake build and doesn't use setuptools. I can probably do the same thing but there's two approaches because they basically bundle 3 separate projects in one big archive: * shiboken2 * pyside2 * pyside2-tools I can either: (A) Manage doing all the builds manually within one big master package BUT this means I'll have to manage some sort of temporary in tree install as the packages are dependent on each other. OR (B) Use the same source 3 times and submit 3 Review Requests.
I need to be signed up to another mailing list like I need another hole in my head but I signed up to the PySide one to hopefully get what I need to move this along.
(In reply to Richard Shaw from comment #55) > It's not expected to build on less than f30... I've been using mock (now > that it works) and koji scratch-builds. # cat /etc/system-release Fedora release 30 (Thirty) # rpmbuild -ba SPECS/python-pyside2.spec error: Failed build dependencies: qt5-devel >= 5.12 is needed by python-pyside2-5.12.1-1.fc30.x86_64 # dnf install qt5-devel Package qt5-devel-5.11.3-2.fc30.noarch is already installed. f30 has not been released yet and this is broken all over, even grub booting doesn't work anymore (and kdm), i need to manually write everything to get this up-n-running. Is that rawhide where you get that qt version?
I can't fix Qt 5.12 being in F30, I don't maintain that package. You'll have to ask Rex about that.
# dnf update qt5\* --enablerepo=rawhide $ rpmbuild -ba SPECS/python-pyside2.spec make[1]: *** [CMakeFiles/Makefile2:132: ApiExtractor/CMakeFiles/apiextractor.dir/all] Error 2 make[1]: Leaving directory '/net/********/home/tuju/PKGS/BUILD/pyside-setup-everywhere-src-5.12.1/pyside3d_build/py3.7-qt5.11.3-64bit-debug/shiboken2' make: *** [Makefile:144: all] Error 2 error: Error compiling shiboken2 Traceback (most recent call last): File "setup.py", line 289, in <module> setup_runner.run_setup() File "/net/*******/home/tuju/PKGS/BUILD/pyside-setup-everywhere-src-5.12.1/build_scripts/setup_runner.py", line 157, in run_setup raise RuntimeError(msg) RuntimeError: setup.py invocation failed with exit code: 1. setup.py invocation was: /usr/bin/python3 setup.py build --executable=/usr/bin/python3 -s --verbose --verbose-build --debug --parallel 8 --qmake=/usr/bin/qmake-qt5 --build-tests --ignore-git --internal-build-type=shiboken2 error: Bad exit status from /var/tmp/rpm-tmp.VvESCz (%build) Prviously i saw plenty of 5.11 mixup cd /net/*******/home/tuju/PKGS/BUILD/pyside-setup-everywhere-src-5.12.1/pyside3d_build/py3.7-qt5.11.3-64bit-debug/shiboken2/tests/libother && /usr/bin/cmake -E cmake_link_script CMakeFiles/libother.dir/link.txt --verbose=1 (accidentally posted this into bug #1661849 too, altough related)
I'm not sure what to tell you. It works in mock now that we had a good rawhide compose and it works as a scratch build. Something with your environment is different.
# rpm -qa --qf="%{NAME}-%{VERSION}\n" | grep qt5|grep 5.11 shows plenty of 5.11 versions, i removed some packages and now pulling more rawhide guts in. Scary feeling. These i couldn't update: python-qt5-rpm-macros-5.11.3 qt5-qttools-doc-5.11.1 python3-qt5-base-5.11.3 python3-qt5-webkit-5.11.3 qt5-qtconnectivity-5.11.3 python2-qt5-base-5.11.3 qt5-qtconnectivity-devel-5.11.3 python3-qt5-5.11.3 python2-qt5-webkit-5.11.3 python2-qt5-5.11.3 python3-qt5-webengine-5.11.3 Well, now it compiles....and it takes looooong time. Finally: Processing files: shiboken2-5.12.1-1.fc30.x86_64 Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.bn8NZP + umask 022 + cd /home/tuju/PKGS/BUILD + cd pyside-setup-everywhere-src-5.12.1 + DOCDIR=/home/tuju/PKGS/BUILDROOT/python-pyside2-5.12.1-1.fc30.x86_64/usr/share/doc/shiboken2 + export LC_ALL=C + LC_ALL=C + export DOCDIR + /usr/bin/mkdir -p /home/tuju/PKGS/BUILDROOT/python-pyside2-5.12.1-1.fc30.x86_64/usr/share/doc/shiboken2 + cp -pr README.shiboken2-generator.md README.shiboken2.md /home/tuju/PKGS/BUILDROOT/python-pyside2-5.12.1-1.fc30.x86_64/usr/share/doc/shiboken2 + exit 0 Provides: python3.7dist(shiboken2) = 5.12.1 python3.7dist(shiboken2-generator) = 5.12.1 python3dist(shiboken2) = 5.12.1 python3dist(shiboken2-generator) = 5.12.1 shiboken2 = 5.12.1-1.fc30 shiboken2(x86-64) = 5.12.1-1.fc30 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: /usr/bin/python3 python(abi) = 3.7 python3.7dist(shiboken2) Processing files: python-pyside2-debugsource-5.12.1-1.fc30.x86_64 error: Empty %files file /home/tuju/PKGS/BUILD/pyside-setup-everywhere-src-5.12.1/debugsourcefiles.list RPM build errors: Missing build-id in /home/tuju/PKGS/BUILDROOT/python-pyside2-5.12.1-1.fc30.x86_64/usr/lib64/python3.7/site-packages/PySide2/pyside2-rcc Missing build-id in /home/tuju/PKGS/BUILDROOT/python-pyside2-5.12.1-1.fc30.x86_64/usr/lib64/python3.7/site-packages/PySide2/pyside2-lupdate Empty %files file /home/tuju/PKGS/BUILD/pyside-setup-everywhere-src-5.12.1/debugsourcefiles.list
I added this but hadn't posted a new SRPM at the top of the spec %undefine _missing_build_ids_terminate_build It's some sort of artifact of the clang compiler
I have that there already.
Wrote: /home/tuju/PKGS/SRPMS/python-pyside2-5.12.1-1.fc30.src.rpm Wrote: /home/tuju/PKGS/RPMS/x86_64/python3-pyside2-5.12.1-1.fc30.x86_64.rpm Wrote: /home/tuju/PKGS/RPMS/x86_64/pyside2-tools-5.12.1-1.fc30.x86_64.rpm Wrote: /home/tuju/PKGS/RPMS/x86_64/shiboken2-5.12.1-1.fc30.x86_64.rp I put %define debug_package %{nil} # rpm -q --provides shiboken2 python3.7dist(shiboken2) = 5.12.1 python3.7dist(shiboken2-generator) = 5.12.1 python3dist(shiboken2) = 5.12.1 python3dist(shiboken2-generator) = 5.12.1 shiboken2 = 5.12.1-1.fc30 shiboken2(x86-64) = 5.12.1-1.fc30 # rpm -ivh /home/tuju/PKGS/RPMS/x86_64/python3-pyside2-5.12.1-1.fc30.x86_64.rpm error: Failed dependencies: libshiboken2.cpython-37m-x86_64-linux-gnu.so.5.12()(64bit) is needed by python3-pyside2-5.12.1-1.fc30.x86_64
# rpm -q python3-pyside2 pyside2-tools shiboken2 python3-pyside2-5.12.1-1.fc30.x86_64 pyside2-tools-5.12.1-1.fc30.x86_64 shiboken2-5.12.1-1.fc30.x86_64 And finally, since last october: % ./tool.py Traceback (most recent call last): File "./tool.py", line 5, in <module> from PySide2.QtCore import Qt File "/usr/lib64/python3.7/site-packages/PySide2/__init__.py", line 49, in <module> _setupQtDirectories() File "/usr/lib64/python3.7/site-packages/PySide2/__init__.py", line 21, in _setupQtDirectories import shiboken2 ModuleNotFoundError: No module named 'shiboken2' % Close but no cigar.
Okay, I got it working. Not so difficult as pacaking, but compile times makes every change slow even with --short-circuit. Only problem I still see is the f30 default /usr/bin/python that is still python2. When creating a Qt python project and running it, it runs it with default Wizard settings that creates files main.pyproject main.pyproject.user into project folder and latter has XML inside it: <value type="QString" key="PythonEditor.RunConfiguation.Interpreter">/usr/bin/python</value> that defines what is the interpreter that the project is run. With default, it tracebacks. If I put python3 there, everything works fine. Problem is that Qt Creator user interface doesn't even shot that *.user file, you have to go to the shell or Dolphin to see it and then look for that setting inside of gazillion other setting. I could not find a Creator user interface setting for it. For an enduser, that's waster 20mins or so to figure it out. Multiply that with everyone trying this out. Funny enough, I could not figure out either, how it creates that when project is set up. There is a package called qt-creator-data that has a path /usr/share/qtcreator/templates/wizards that contains those wizard templates. But there is no main.pyproject.user XML template. Not sure how it should even be fixed if there would be one. Rest of the world (mouse camp et al) seem to live happily as '/usr/bin/python' is already python3. And their official docs https://wiki.qt.io/Qt_for_Python/GettingStarted#Building_PySide2_from_scratch is not how they say it should be built. How hard it is to change that page? Go figure. I try to post my spec variant tomorrow, someone else should clean it up.
Created attachment 1547940 [details] A %build section that includes shiboken2 module to site-packages. Spec that might use replacement some macros once build issues were sorted out. Tweaked it here and there, a full review should be done. Qt Creator "2vs3-Run-traceback" is still unresolved.
Should that shiboken2_generator be an own package? Haven't used it yet and for me all these relations are bit unclear.
(In reply to Juha Tuomala from comment #69) > > Qt Creator "2vs3-Run-traceback" is still unresolved. Ha! Qt Creator left sidebar: Projects -> Build & Run -> Run Settings -> Run -> Interpreter -> s#/usr/bin/python#/usr/bin/python3#g so it is GUI configurable. This is not a problem, just needs a Fedora Wiki page or something. Also maybe a Fedora specific notes into RPM file /usr/share/doc/... for offline users.
Ok, we may need to merge our changes. I have changed things quite a bit since the last SRPM I posted. I'll review your spec and see about combining the two... (In reply to Juha Tuomala from comment #70) > Should that shiboken2_generator be an own package? Haven't used it yet and > for me all these relations are bit unclear. shiboken2_generator is what produces the shiboken2 binary so those should be packaged together. I've been reworking the packages to follow more of the style of shiboken1 shiboken2 python3-shiboken2-libs python3-shiboken2-devel
Ok, I tried upstreams suggestion to call the internal build but I'm still getting pyside2 installed 3 times instead of shiboken and shiboken-generator... %py3_install -- --reuse-build --internal-build-type=shiboken2 %py3_install -- --reuse-build --internal-build-type=shiboken2-generator %py3_install -- --reuse-build --internal-build-type=pyside2 Which is slightly different from your method in that I'm trying to use the %py3_install macro but the result should pretty much be the same. Bah... This is really aggravating. I would prefer to use the cmake build directly but upstream abuses CMAKE_INSTALL_PREFIX in order to to a fake install within the build tree for dependency purposes and then custom compiles a rpath fix program and run it against the libraries to fix it during install. I may try running cmake twice and see if it doesn't rebuild everything. Hopefully it only relinks the libraries which I think would be OK.
Looking at your spec I'm pretty sure you're building everything (at least shiboken2 and shiboken2_generator) twice... I'm moving on to the direct CMake build. I'll share something when I get it in a working state.
Ok, a local mock build FINALLY completed so I kicked off a scratch build to check other arches: https://koji.fedoraproject.org/koji/taskinfo?taskID=33794664 I would pull the SRPM from there once it completes. NOTE: While I was working with both setuptools and cmake I had two spec files, so the one in this SRPM is called python-pyside2-cmake.spec. Not an issue for playing around but if I submit a review request I'll rename it back to the base package name.
(In reply to Richard Shaw from comment #72) > Ok, we may need to merge our changes. I have changed things quite a bit > since the last SRPM I posted. I'll review your spec and see about combining > the two... Note I added custom %clean to achive deprecated --noclean option for rpmbuild. > (In reply to Juha Tuomala from comment #70) > > Should that shiboken2_generator be an own package? Haven't used it yet and > > for me all these relations are bit unclear. > > shiboken2_generator is what produces the shiboken2 binary so those should be > packaged together. > > I've been reworking the packages to follow more of the style of shiboken1 > > shiboken2 > python3-shiboken2-libs > python3-shiboken2-devel Those would probably be more familar for Fedora communit as it's already used in other pkgs.
(In reply to Richard Shaw from comment #73) > Ok, I tried upstreams suggestion to call the internal build but I'm still > getting pyside2 installed 3 times instead of shiboken and > shiboken-generator... > > %py3_install -- --reuse-build --internal-build-type=shiboken2 > %py3_install -- --reuse-build --internal-build-type=shiboken2-generator > %py3_install -- --reuse-build --internal-build-type=pyside2 > > Which is slightly different from your method in that I'm trying to use the > %py3_install macro but the result should pretty much be the same. > > Bah... This is really aggravating. > > I would prefer to use the cmake build directly but upstream abuses > CMAKE_INSTALL_PREFIX in order to to a fake install within the build tree for > dependency purposes and then custom compiles a rpath fix program and run it > against the libraries to fix it during install. I may try running cmake > twice and see if it doesn't rebuild everything. Hopefully it only relinks > the libraries which I think would be OK. I do understand the heavy use of RPM marcros in distro building, as those allow mass changes without touching any packages. There's a real benefit. I removed them just to figure out the real problem not getting shiboken, but like said before, someone should clean this up and put them back. That setup.py vs cmake, I understood that upstream provides setup.py as 'customer interface' to build all this. I would still keep using it as who knows how they change it in the future, would those changes require more manhours to fix .spec again? I'd be very happy to keep them responsible on their own yard and use that what they provide and recommend. Thou it's maintainer who deciceds that. About that multiple builds, that might have happened indeed. Those builds took one hour in my 8-core desktop. But still, imo that is upstream problem and should be communicated with them if spec uses interface what they recommend. For now, setup.py --internal-build produces wanted end result that can be released which is the main target of this excercise imo. I would commit it, close this tracking bug and do this multiple-build-issue as fine tuning in further spec releases. In devleoper point of view there is a big difference having qt-python and not having it - if it's all about cutting down unnessessary computing time. :) Richard, do you have any idea where Qt Creator gets its pyproject.user template that I mentioned before?
hmmm, also note, I might have dropped the --build-tests to speed up spec tuning. Don't remember did I put 'em back.
(In reply to Juha Tuomala from comment #77) > > Richard, do you have any idea where Qt Creator gets its pyproject.user > template that I mentioned before? No idea. I'm not even a direct user for this package, I just need it to move FreeCAD to Qt5 which is preferred as of release 0.18. I'm doing some final tweaks to my cmake build. I accidentally globed some libraries twice and I found a way (I hope, it's still building) to create and install egg-info for the python packages. If this works, I'll review the spec one more time and document in comments the reason for the hacks. I also need to go through the source thoroughly to review the licences per package. Once complete I'll create a Review Request and close this tracker bug.
Juha, Here's what I plan to move forward with if it works. Since you've actually used the tools can you try these packages when the build completes? https://koji.fedoraproject.org/koji/taskinfo?taskID=33817221
Still see some arches failing... The ppc64le and s390x ones should be OK once qt5-webengine makes it into rawhide. For some reason those arches were skipped in an earlier build but I've seen new ones in koji for all arches. The armv7hf build is a problem. For some reason clang is segfaulting: https://kojipkgs.fedoraproject.org//work/tasks/4670/33794670/build.log
Juha, Have you had a chance to test my last scratch build? I'd like to know if the package "works" before submitting a review request.
(In reply to Richard Shaw from comment #82) > Have you had a chance to test my last scratch build? I'd like to know if the > package "works" before submitting a review request. Not yet, I was trawelling. Now I'm back so once I get thing sorted out, I'll give it a try.
(In reply to Richard Shaw from comment #81) > Still see some arches failing... The ppc64le and s390x ones should be OK > once qt5-webengine makes it into rawhide. For some reason those arches were > skipped in an earlier build but I've seen new ones in koji for all arches. > > The armv7hf build is a problem. For some reason clang is segfaulting: > > https://kojipkgs.fedoraproject.org//work/tasks/4670/33794670/build.log https://koji.fedoraproject.org/koji/taskinfo?taskID=33817222 Those build results are not available anymore. If you want me to test those, fire up a new build. I'm also seeing some fc31 pkgs in my dnf downloads, no idea where those are coming as I don't have rawhide enabled.
I wasn't sure what release you were running so here's a SRPM: https://hobbes1069.fedorapeople.org/python-pyside2-5.12.1-1.fc29.src.rpm
I think this may also be affect yubikey and pyotherwise in Fedora 30 beta: Problem 1: package pyotherside-1.5.4-3.fc30.x86_64 requires qt5-qtbase(x86-64) = 5.11.3, but none of the providers can be installed - cannot install both qt5-qtbase-5.12.1-2.fc30.x86_64 and qt5-qtbase-5.11.3-4.fc30.x86_64 - cannot install both qt5-qtbase-5.11.3-4.fc30.x86_64 and qt5-qtbase-5.12.1-2.fc30.x86_64 - cannot install the best update candidate for package qt5-qtbase-5.11.3-4.fc30.x86_64 - cannot install the best update candidate for package pyotherside-1.5.4-3.fc30.x86_64 Problem 2: problem with installed package pyotherside-1.5.4-3.fc30.x86_64 - package pyotherside-1.5.4-3.fc30.x86_64 requires libQt5Quick.so.5(Qt_5.11.3_PRIVATE_API)(64bit), but none of the providers can be installed - cannot install both qt5-qtdeclarative-5.12.1-1.fc30.x86_64 and qt5-qtdeclarative-5.11.3-2.fc30.x86_64 - cannot install both qt5-qtdeclarative-5.11.3-2.fc30.x86_64 and qt5-qtdeclarative-5.12.1-1.fc30.x86_64 - cannot install the best update candidate for package qt5-qtdeclarative-5.11.3-2.fc30.x86_64 Problem 3: package yubioath-desktop-4.3.5-4.gitd1187b6.fc30.x86_64 requires pyotherside, but none of the providers can be installed - package pyotherside-1.5.4-3.fc30.i686 requires qt5-qtbase(x86-32) = 5.11.3, but none of the providers can be installed - package pyotherside-1.5.4-3.fc30.x86_64 requires qt5-qtbase(x86-64) = 5.11.3, but none of the providers can be installed - package qt5-qtbase-5.11.3-4.fc30.i686 requires qt5-qtbase-common = 5.11.3-4.fc30, but none of the providers can be installed - cannot install both qt5-qtbase-5.12.1-2.fc30.x86_64 and qt5-qtbase-5.11.3-4.fc30.x86_64 - cannot install both qt5-qtbase-5.11.3-4.fc30.x86_64 and qt5-qtbase-5.12.1-2.fc30.x86_64 - cannot install both qt5-qtbase-common-5.12.1-2.fc30.noarch and qt5-qtbase-common-5.11.3-4.fc30.noarch - cannot install both qt5-qtbase-common-5.11.3-4.fc30.noarch and qt5-qtbase-common-5.12.1-2.fc30.noarch - package python2-qt5-5.11.3-6.fc30.x86_64 requires libQt5Core.so.5(Qt_5.12)(64bit), but none of the providers can be installed - cannot install the best update candidate for package yubioath-desktop-4.3.5-4.gitd1187b6.fc30.x86_64 - cannot install the best update candidate for package qt5-qtbase-common-5.11.3-4.fc30.noarch - cannot install the best update candidate for package python2-qt5-5.11.3-4.fc30.x86_64 Problem 4: problem with installed package yubioath-desktop-4.3.5-4.gitd1187b6.fc30.x86_64 - package yubioath-desktop-4.3.5-4.gitd1187b6.fc30.x86_64 requires pyotherside, but none of the providers can be installed - pyotherside-1.5.4-3.fc30.i686 has inferior architecture - package pyotherside-1.5.4-3.fc30.x86_64 requires qt5-qtbase(x86-64) = 5.11.3, but none of the providers can be installed - cannot install both qt5-qtbase-5.12.1-2.fc30.x86_64 and qt5-qtbase-5.11.3-4.fc30.x86_64 - cannot install both qt5-qtbase-5.11.3-4.fc30.x86_64 and qt5-qtbase-5.12.1-2.fc30.x86_64 - package python2-qt5-base-5.11.3-6.fc30.x86_64 requires libQt5Core.so.5(Qt_5.12)(64bit), but none of the providers can be installed - package python2-qt5-base-5.11.3-6.fc30.x86_64 requires libQt5Core.so.5(Qt_5.12.1_PRIVATE_API)(64bit), but none of the providers can be installed - package python2-qt5-base-5.11.3-6.fc30.x86_64 requires qt5-qtbase(x86-64) = 5.12.1, but none of the providers can be installed - cannot install the best update candidate for package python2-qt5-base-5.11.3-4.fc30.x86_64
Yes, due to the way pyside versions and qt versions need to stay in sync (5.12.x for both) there's no way currently to test on fc30 unless it get's upgraded to 5.12... Darn.
f30 has been updated to Qt 5.12.x, https://bodhi.fedoraproject.org/updates/FEDORA-2019-74ad6b133a Just a couple of straggler packages need rebuilding (pyotherside, yubioath-desktop), see bug #1697330
f30 scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=34218060
There are requires/provides like this: libshiboken2.cpython-37m-x86_64-linux-gnu.so.5.12()(64bit) I think those should be filtered out, as those are Python modules. Something like (untested): %global __requires_exclude_from ^%{python3_sitelib}/lib.*\\.so$ %global __provides_exclude_from ^%{python3_sitelib}/lib.*\\.so$ https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/
Demos like https://doc.qt.io/qtforpython/tutorials/basictutorial/dialog.html work!
This is one area that's always confused me. These don't look like "private" provides, so should they be filtered? Wouldn't a package the links to the library add it as a "Requires" during package building?
(In reply to Rex Dieter from comment #88) > f30 has been updated to Qt 5.12.x, > https://bodhi.fedoraproject.org/updates/FEDORA-2019-74ad6b133a > > Just a couple of straggler packages need rebuilding (pyotherside, > yubioath-desktop), see bug #1697330 Rex, my system with command % rpm -qa | grep qt | grep "5.11" returns 65 packages. Should that go to zero at some point?
Ric, are you going to make more changes or wrapping up already and submitting this into f30?
I don't have any changes planned unless someone can convince me we should be filtering the requires/provides on the CPython library. If everyone is good to go I'll submit a Review Request and close this bug.
> unless someone can convince me we should be filtering the requires/provides on the CPython library. I was not planning to do that.
I'll ask for someone with a lot of knowledge of Python packaging to do the review and we'll go from there :)
The Review Request can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1701013 Closing this bug.
What is the status on this? I still haven't seen it in repositories. Ric?
I had a lot of trouble getting the package to build for a number of reasons and finally got the FTBFS problems fixed but forgot to build for f30 so I just kicked off a build: https://koji.fedoraproject.org/koji/taskinfo?taskID=37237518 Hopefully no issues.
Update submitted for Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-26a662a9b9
Yes, now visible with: dnf search --enablerepo=updates-testing pyside2
Hellow World starts, works. So most likely it's all okay.
Running transaction Preparing : 1/1 Installing : python3-pyside2-5.12.4-1.fc30.x86_64 1/3 Installing : pyside2-tools-5.12.4-1.fc30.x86_64 2/3 Installing : python3-pyside2-devel-5.12.4-1.fc30.x86_64 3/3 Running scriptlet: python3-pyside2-devel-5.12.4-1.fc30.x86_64 3/3 Verifying : pyside2-tools-5.12.4-1.fc30.x86_64 1/3 Verifying : python3-pyside2-5.12.4-1.fc30.x86_64 2/3 Verifying : python3-pyside2-devel-5.12.4-1.fc30.x86_64 3/3 Installed: pyside2-tools-5.12.4-1.fc30.x86_64 python3-pyside2-5.12.4-1.fc30.x86_64 python3-pyside2-devel-5.12.4-1.fc30.x86_64 Complete! Installs cleanly from production repos. Looks like this is finally over. Thank you Ric for all the hours you put into it and for maintaining it.
Thanks for the confirmation! I'm working on moving freead over to pyside2 but there are several python2 removal bugs for other consumers of the old pyside so they need to be moved over as well.