Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1045780 - no Python 3 package for python-pyside
Summary: no Python 3 package for python-pyside
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-pyside
Version: rawhide
Hardware: All
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Felix Schwarz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1320653
Blocks: PYTHON3
TreeView+ depends on / blocked
 
Reported: 2013-12-21 23:34 UTC by Felix Schwarz
Modified: 2018-09-30 12:08 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-16 17:43:00 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
proposed changes to add Python 3 subpackage + 1.2.4 version bump (deleted)
2016-08-08 10:24 UTC, Felix Schwarz
no flags Details | Diff
support Python 3.5 + egg_info for PySide (deleted)
2016-08-08 10:36 UTC, Felix Schwarz
no flags Details | Diff

Description Felix Schwarz 2013-12-21 23:34:38 UTC
PySide supports Python 3 for quite a long time (http://qt-project.org/wiki/PySide_Python_3_Support) but Fedora does not ship a Python 3 compatible subpackage.

Comment 1 Nick Coghlan 2014-03-14 07:35:25 UTC
Victor Stinner is working on a Qt based visualiser for the new tracemalloc feature coming in Python 3.4, but is hampered by the fact that pyside binaries are not provided for the Python 3 stack: https://mail.python.org/pipermail/python-dev/2014-March/133153.html

It would be handy to have those available in F21 if possible.

Comment 2 Geert Jansen 2014-03-14 10:43:56 UTC
I was in exactly the same situation with a project of mine. Upstream PySide does indeed support Python3 and e.g. Ubuntu provides packages for it, but Fedora doesn't.

I invested quite a bit of time trying to package PySide for Py3K, but finally gave up. I did have a version that sort-of worked, but I had tests segfaulting and I had to patch code that I didn't really understand to fix these segfaults. It just didn't give me a lot of confidence.

I solved the problem by moving to PyQt. I didn't realize this before, but PyQt's v2 API is virtually drop-in compatible with PySide (PySide was modeled after it), and it's got a company behind it that does a great job of maintaining it. Another benefit of PyQt is already supports Qt5 (as a separate package).

My comment doesn't immediately solve the problem here, as currently PyQt isn't packaged for Py3K either. However, IMHO, time would be better spent on packaging PyQt for Py3K than PySide. I may even give it a shot at some point.

[This assumes that the visualizer has a GPL compatible license. PySide is LGPL while PyQt is GPL].

Comment 3 Felix Schwarz 2014-03-14 11:01:02 UTC
Geert, do you still have some srpm/spec from your experiments? This might be a starting point for someone else to start with. For example my project is bound to PySide because of an GPL-incompatible license.

Comment 4 Geert Jansen 2014-03-14 11:24:16 UTC
Felix, afraid not. I took some of the patches from the Ubuntu source package. That can be a starting point..

Comment 5 Tom Repetti 2014-05-28 10:54:07 UTC
You can make sure you have python3-devel and then symlink qmake:

    ln -s /usr/bin/qmake-qt4 /usr/bin/qmake

With that in hand the pip-install will compile successfully. Are the resulting libraries and headers in /usr/lib64/python3.3/site-packages/PySide of any use in creating the package? I'll look at the Python packaging requirements some more to figure out what exactly is needed for an rpm, but I'm pretty new to it, I'm afraid.

Comment 6 Tom Repetti 2014-05-28 11:43:58 UTC
Also, just noticed that with the shiboken update slated for F21, we should be able to compile pyside-qt4.8+1.2.1.tar.bz2 on rawhide. python3-pip just includes a shiboken binary in the site-package directory under F20 when it installs the current 1.2.2 version. Any thoughts on what would make the most sense for a potential package?

Comment 7 Jaroslav Reznik 2014-06-09 14:38:09 UTC
Due to uncertain future of PySide, it wasn't high priority - sorry for that. But I'll take a look on how to enable Python 3 support for it in Fedora.

Comment 8 Ganapathi Kamath 2014-07-26 00:46:35 UTC
In Bug 1121774, I have made 4 srpms by making some changes to existing srpms, pyside can be built on fc21 in one's home folder using those srpms
$ rpm -i <>.srpm 
$ rpmbuild -ba SPEC/<>.spec

Comment 9 Felix Schwarz 2014-10-23 18:26:11 UTC
I'm currently looking into building PySide for Python 3 as I've seen no one else recently working on this but I'm not sure if I'll have enough free time to complete this endeavour.

Therefore I'd like to share some findings (mostly about shiboken though):
- Debian (Jessy) and OpenSuse have PySide/Python3 packages which can be used to check things. Debian's package looks better (though I don't really like the extreme splitting of the pyside package)
- it looks like shiboken needs a separate Python 3 build because 'site-packages/shiboken.so' links to Python directly.
- two shiboken tests fail on Python 3. On a first glance they are caused by simple Python-2-only syntax which can be fixed trivially. IIRC you can find patches in the Debian package.
- shiboken's .pc file includes explicit Python paths. OpenSuse solves that by having the shiboken-devel packages conflicting with each other – not so nice.

In general the pyside/shiboken development is seriously understaffed. A lot of (seemingly ok) bug fixes float around in Jira, github pull requests and other distro packages but they are not integrated.

Comment 10 André 2015-06-19 15:39:39 UTC
I would also like to use PySide with Python 3 ... and I was found this discussion. But unfortunately it doesn't look so that it will be available in the near future.

If there is any possibility, please implement PySide for Python 3!

Comment 11 Geert Jansen 2015-06-19 18:07:27 UTC
(In reply to André from comment #10)
 
> If there is any possibility, please implement PySide for Python 3!

I assume you need an LGPL library, right?

If GPL is OK then I'd highly recommend PyQt. Unlike PySide, PyQt is actively being developed and is up to date both with regards to Python 3 and Qt 5.

Both are 99.9% source compatible. Actually the PySide API was developed to match the PyQt API.

Comment 12 André 2015-06-19 21:49:11 UTC
(In reply to Geert Jansen from comment #11)
> I assume you need an LGPL library, right?

Correct!

Is it a great effort to provide a PySide package for Python 3? (I'm seemingly not alone.)

Comment 13 Geert Jansen 2015-06-20 01:44:54 UTC
(In reply to André from comment #12)
> (In reply to Geert Jansen from comment #11)
> > I assume you need an LGPL library, right?
> 
> Correct!
> 
> Is it a great effort to provide a PySide package for Python 3? (I'm
> seemingly not alone.)

The problem is that PySide is not actively maintained. If I remember correctly from my efforts to package it, some tests fail and some even crash Python. The Ubuntu PySide package has a few patches that are supposed to fix those. Those could be applied to the Fedora package as well. But it's unlikely, in my view, that you will end up with something that is stable.

Without an active upstream, packaging this is almost pointless.

Comment 14 Jacob Welsh 2015-06-20 03:20:28 UTC
Is it really so dead? The latest release is just over a year old, which is after the previous packaging attempt noted in this bug. https://pyside.readthedocs.org/en/latest/changes.html#id2 Both PyQt and PySide are prone to crashing the interpreter if the programmer doesn't do things "just so", due to conflicting memory management of Python and Qt... it just seems to be the nature of the beast.

It is concerning that there's no road map to Qt 5 support, but for what it is, it basically works, and it's nice to have an option without licensing headaches, even if it's a little dustier.

Comment 15 Rex Dieter 2015-06-20 21:01:33 UTC
Another factor is pyside probably could use another fedora package maintainer or 2, to help out.  Anyone able and interested?

That said, I'd encourage users to prefer PyQt4 and python-qt5 (aka PyQt5) is at all possible.

Comment 16 Felix Schwarz 2015-06-22 20:30:36 UTC
As I mentioned earlier I spent some time extended Fedora's spec files to create Python 3 subpackages:
https://fschwarz.fedorapeople.org/2015/shiboken-1.2.2-3.fc22.src.rpm
https://fschwarz.fedorapeople.org/2015/python-pyside-1.2.2-3.fc22.src.rpm

It's been quite a while since I tweaked the spec files but I vaguely remember a few problems with some shiboken devel files if you install i386+x86_64 versions at the same time. Other than that I think my version might be "good enough". At least it works well enough for my project (even though I'm only using Python 3 pyside for development, production deployment uses Windows).

For QT5 status I think at least one freelancer is working full-time on porting pyside for QT5 right now.

Comment 17 David Kaspar // Dee'Kej 2016-08-01 14:52:11 UTC
Hello Felix,

I was able to build the packages for F22. However, right now, I'm on F24 and there's no longer 'libpython3.4m.so.1.0' shared library. Righ now, there's 3.5m version.

I tried to rebuild it in mock for F24, but I was not successful, because it fails to find correct paths to Python3 libraries.

Would you be so kind and try to look into it? I gave it a shot today, but didn't manage to get it work... :-/

Best regards,

Dee'Kej

Comment 18 Felix Schwarz 2016-08-06 20:32:37 UTC
> Would you be so kind and try to look into it?

Sure I'm using this with Python 3.5 on F24 for $DAYJOB. I'll post updated SRPMs next week. However I think you need to update apiextractor (bug 1352326) to fix shiboken FTBS (bug 1240001, bug 1308126) and then use the shiboken patches for Python 3 (bug 1320653).

Comment 19 Felix Schwarz 2016-08-08 10:24:19 UTC
Created attachment 1188605 [details]
proposed changes to add Python 3 subpackage + 1.2.4 version bump

This patch does a couple of things and I don't have enough time right now to untangle them:
 - resolve the FTBS failures (bug 1240001, bug 1308126)
 - update to latest upstream version 1.2.4 (no bug in rhbz currently)
 - provide a Python 3 subpackage

If my request for co-maintainership for shiboken is granted I plan to commit this patch for F25+ (not sure about F24 - I'm using it on F24 so it should be pretty low risk but I'd only do so if there are specific requests from users).

Comment 20 Felix Schwarz 2016-08-08 10:36:09 UTC
Created attachment 1188614 [details]
support Python 3.5 + egg_info for PySide

Ah, seems like I got confused with all these open bugs. My previous attachement 1188605 is of course for shiboken (bug 1320653) while this patch applies to PySide. Sorry for the noise.

The patch conflates two separate issues:
 - support Python 3 (3.5)
 - provide egg_info metadata as suggested in bug 1326469)

If my request for co-maintainership is granted I'll commit these separately.

Comment 21 Rex Dieter 2016-08-08 12:20:12 UTC
acls granted. use your powers for good.

Comment 22 Felix Schwarz 2016-09-17 09:24:11 UTC
Sorry that the Python 3 package is still not in git. So far I was unable to update Shiboken as one test fails on ARM (and I don't have an ARMv7 system for testing). I have to check more closely what other distros are doing with that situation (OpenSuse just disables all tests which I don't like, I think Debian's solution is a bit more sophisticated).

Anyway if you are interested in PySide for Python 3 will be reported in bug 1320653 first.

Comment 23 Felix Schwarz 2018-02-13 09:20:38 UTC
I'll push my Python 3 changes in the next days (finally) after Orion Poplawski did nice Python 3 patches for shiboken. :-)

Comment 24 David Kaspar // Dee'Kej 2018-02-13 11:08:51 UTC
(In reply to Felix Schwarz from comment #23)
> I'll push my Python 3 changes in the next days (finally) after Orion
> Poplawski did nice Python 3 patches for shiboken. :-)

Yaaay, kudos for that! :)

This in turn should allow me to package the drivers for Razer mouses for Fedora at some point, with a GUI interface... ;)

I think this will make a lot of users happy! ^_^

Comment 25 David Kaspar // Dee'Kej 2018-02-13 11:09:38 UTC
(In reply to David Kaspar [Dee'Kej] from comment #24)
> (In reply to Felix Schwarz from comment #23)
> > I'll push my Python 3 changes in the next days (finally) after Orion
> > Poplawski did nice Python 3 patches for shiboken. :-)
> 
> Yaaay, kudos for that! :)
> 
> This in turn should allow me to package the drivers for Razer mouses...
... mice :D

Comment 26 Orion Poplawski 2018-02-14 19:29:50 UTC
Filed https://src.fedoraproject.org/rpms/python-pyside/pull-request/1 with what I have so far.

Comment 27 Felix Schwarz 2018-02-14 22:03:36 UTC
(In reply to Orion Poplawski from comment #26)
> Filed https://src.fedoraproject.org/rpms/python-pyside/pull-request/1 with
> what I have so far.

Thank you very much. I think it looks good - previously I planned to do Python 3 before updating to 1.2.4 (I noticed a few ramblings about 1.2.4 acting weird - nothing too serious). However as you did the upgrade already, I'm willing to do it in one step.

However your patches do not work as-is because you don't set the right "-DPYTHON_SUFFIX=" for Python 3. This needs to be set to ".cpython-36m-x86_64-linux-gnu" on F27/x86_64.

I'm not show if there is a Fedora macro to get that string. Any idea? "x86_64" should be "%{_arch}" but "36" (or "34" for EPEL) seems hard to get.

Callout to Python?
python3 -c 'import sys; v=sys.version_info; print("%s%s" % (v.major, v.minor));'

Anyway: How should we proceed with your pull request? Would you like to fix the errors and resubmit or should I merge your pull + fixup afterwards?

Comment 28 Petr Viktorin (pviktori) 2018-02-16 10:57:29 UTC
That is the [PEP 425] ABI tag. Unfortunately it's not straightforward to get it. This callout to python3 will give you the whole thing:

$ python3 -c 'from distutils.sysconfig import get_config_var; print(get_config_var("SOABI"))'
cpython-36m-x86_64-linux-gnu


[PEP 425]: https://www.python.org/dev/peps/pep-0425/

Comment 29 Felix Schwarz 2018-02-16 17:43:00 UTC
pyside build for Python 3 is in progress now (rawhide only), so I'm closing this bug. Again, all credits to Orion :-)

Currently this is only in rawhide (=F28+). Should we push this update to F27/EPEL? Orion, I noticed your changes should also work for EPEL7. Are you interested in having this package also in EPEL?

Personally I only need pyside on Fedora.

(In reply to Petr Viktorin from comment #28)
> That is the [PEP 425] ABI tag. Unfortunately it's not straightforward to get
> it. This callout to python3 will give you the whole thing:
> 
> $ python3 -c 'from distutils.sysconfig import get_config_var;
> print(get_config_var("SOABI"))'
> cpython-36m-x86_64-linux-gnu

That's good to know, we can simplify the SPEC a bit with your one-liner.

Comment 30 Orion Poplawski 2018-02-16 17:59:29 UTC
(In reply to Felix Schwarz from comment #29)
> Currently this is only in rawhide (=F28+). Should we push this update to
> F27/EPEL? Orion, I noticed your changes should also work for EPEL7. Are you
> interested in having this package also in EPEL?

Yeah, I'd like to get this into EPEL7.  I can make those updates though.

> (In reply to Petr Viktorin from comment #28)
> > That is the [PEP 425] ABI tag. Unfortunately it's not straightforward to get
> > it. This callout to python3 will give you the whole thing:
> > 
> > $ python3 -c 'from distutils.sysconfig import get_config_var;
> > print(get_config_var("SOABI"))'
> > cpython-36m-x86_64-linux-gnu
> 
> That's good to know, we can simplify the SPEC a bit with your one-liner.

Might be nice to get a macro for this into python-rpm-macros...

Comment 31 Felix Schwarz 2018-02-17 10:17:49 UTC
(In reply to Orion Poplawski from comment #30)
> Yeah, I'd like to get this into EPEL7.  I can make those updates though.

Probably you should apply for co-maintainership via pagure (I don't have admin privileges for pyside so one of the other admins needs to step in).

Are you also interested in pyside2 (QT5)? According to a QT Company developer they consider their pyside2 git to be more stable than pyside 1. It's a bit annoying that they don't have any releases so far though. Anyway, feel free to cc me if anyone starts working on it (we need to figure out if we can use the same shiboken for both pyside versions).

Comment 32 Felix Schwarz 2018-02-17 10:19:12 UTC
Oh and btw: I built a F27 package with Python 3 support locally. I someone is interested I can setup a COPR (or push that to Fedora's F27 branch - not sure).

Comment 33 Petr Viktorin (pviktori) 2018-02-19 12:24:30 UTC
> Might be nice to get a macro for this into python-rpm-macros...

I'm not familiar with building PySide, but: is this really a Fedora-specific change? Wouldn't it be better to adjust defaults upstream?

Comment 34 Juha Tuomala 2018-09-30 12:06:08 UTC
Any change getting this pushed into release? Installing it is not that straight-forward:

# dnf --enablerepo=rawhide install -y python3-pyside.x86_64
Last metadata expiration check: 0:01:14 ago on Sun 30 Sep 2018 03:01:03 PM EEST.
Error: 
 Problem: problem with installed package mplayer-1.3.0-11.fc27.x86_64
  - package mplayer-1.3.0-11.fc27.x86_64 requires libgif.so.4()(64bit), but none of the providers can be installed
  - cannot install both giflib-5.1.4-2.fc29.x86_64 and giflib-4.1.6-19.fc27.x86_64
  - cannot install both giflib-4.1.6-19.fc27.x86_64 and giflib-5.1.4-2.fc29.x86_64
  - package fontforge-20170731-10.fc29.x86_64 requires libgif.so.7()(64bit), but none of the providers can be installed
  - problem with installed package fontforge-20170731-2.fc27.x86_64
  - package fontforge-20170731-2.fc27.x86_64 requires python(abi) = 3.6, but none of the providers can be installed
  - python3-3.6.6-1.fc27.i686 has inferior architecture
  - python3-3.6.2-13.fc27.i686 has inferior architecture
  - package python3-3.6.6-1.fc27.x86_64 requires python3-libs(x86-64) = 3.6.6-1.fc27, but none of the providers can be installed
  - package python3-3.6.2-13.fc27.x86_64 requires python3-libs(x86-64) = 3.6.2-13.fc27, but none of the providers can be installed
  - cannot install both python3-libs-3.7.0-9.fc30.x86_64 and python3-libs-3.6.6-1.fc27.x86_64
  - cannot install both python3-libs-3.6.6-1.fc27.x86_64 and python3-libs-3.7.0-9.fc30.x86_64
  - cannot install both python3-libs-3.6.2-13.fc27.x86_64 and python3-libs-3.7.0-9.fc30.x86_64
  - package shiboken-python3-libs-1.2.4-11.fc29.x86_64 requires python(abi) = 3.7, but none of the providers can be installed
  - package python3-3.7.0-9.fc30.i686 obsoletes python37 provided by python37-3.7.0-1.fc27.x86_64
  - package python3-3.7.0-9.fc30.x86_64 requires python3-libs(x86-64) = 3.7.0-9.fc30, but none of the providers can be installed
  - package shiboken-python3-libs-1.2.4-11.fc29.x86_64 requires libpython3.7m.so.1.0()(64bit), but none of the providers can be installed
  - package python3-pyside-1.2.4-7.fc29.x86_64 requires libshiboken.cpython-37m-x86_64-linux-gnu.so.1.2()(64bit), but none of the providers can be installed
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)

Comment 35 Juha Tuomala 2018-09-30 12:08:21 UTC
Well, adding 
   --best --allowerasing

took me where no man has gone before.


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