So, after a good deal of flailing around getting caught up on the specifics of this "python3-only builds on epel7" plan, and how it would need to be executed, I finally have package build sources and .specs for python3-sip and python3-qt5 committed to (respectively):
https://github.com/ferdnyc/el7-python3-sip https://github.com/ferdnyc/el7-python3-qt5 el7-python3-sip started as the python3-sip branch of your rpms/sip fork @ src.fedoraproject, but I ended up making fairly extensive changes (more on that in a moment). el7-python3-qt5 started from the contents of python-qt5-5.10-3.fc28.src.rpm. They're even both built for EPEL7 in COPR, with python3-sip used for python3-qt5: https://copr.fedorainfracloud.org/coprs/ferdnyc/python3-sip/ https://copr.fedorainfracloud.org/coprs/ferdnyc/python3-qt5/ (I'm about to submit a new python3-qt5 build, though, so that'll be several minutes at least.) I don't have an EL7 machine to test them on, but I built the packages locally for F28 x86_64, uninstalled the distro packages (forcibly via `rpm -e --nodeps`), and installed these. An openshot-2.4.2.rpm built and run using the new python3-qt5 launched and ran fine. So, I'm hopeful the same would be true of the EPEL7 builds in COPR. Of course, COPR doesn't help with getting openshot@rpmfusion packaged for EPEL7, so what are the next steps? Getting them into the official EPEL7 repos? Or into rpmfusion-el7-free? (Not sure what help I can be on the official side, I'm not even a Fedora packager yet. I did have my first package reviewed and approved, but haven't had a chance to arrange sponsorship and take the next steps.) *A note about the packaging* As I said, I started with your SIP fork, and started out keeping the .spec files as close as possible to the original python2/3 dual builds. But once I fully understood the requirement for python3-sip to be installable *alongside* the python2-only distro build *of a different version*, I tossed all that out. My thinking was: 1. The package and SRPM *names* even have to be different; I'm not sure how you'd even conditionalize that. 2. Both build subpackages (sip-macros, python-qt5-rpm-macros / python-qt5-doc) that are common to both the python2- and python3- paths; they don't perfectly segregate python2-* and python3-*, whereas my packages *must*. So, the specs differ significantly from the originals even on the Python3 build path. Subpackage names change, some contents get moved to different subpackages, etc. 3. I further modified some of the supplementary files used in the build. For instance, I removed the python2 fallback from those py*.sh wrapper scripts python-qt5.spec installs. (In fact, looking at it again now, those wrappers don't appear to make sense without a python2 fallback. I'll remove them entirely.) 4. My python3-sip-macros-4.19.8-5 uses a different filename ( macros.python3-sip) and different macro names (%_py3sip_api-*), so that it can be installed alongside sip-macros-4.14.6-4.el7.x86_64.rpm without conflicting 5. Because of #3, my python3-qt5.spec uses the %_py3sip_api_* macros instead of the standard ones. (It builds python3-qt5-rpm-macros with the usual names/location, mostly for convenience & since there's no python-qt5 on EPEL7 to conflict.) 6. Because SIP will be two entirely different releases, API versions, and macros, all installed simultaneously, it's unlikely any dependent spec could or WOULD generate python2- and python3- packages from the same build, regardless. So, polluting sip.spec and python-qt5.spec from the distro sources with conditionals for these special-case packages didn't make much sense to me (even if it's possible), and since there's no conceivable scenario where these will need to generate python2-compatible packages, I dropped the python2/dual-version build path(s) entirely. The conditionals for distro and python version are all gone, and these specs are suitable only for generating packages using python3 on EPEL7. If that was the wrong call, I'm open to suggestions on a good way to incorporate this into the common cross-distro .spec files. On Tue, Sep 4, 2018 at 2:04 PM Sérgio Basto <[email protected]> wrote: > On Tue, 2018-09-04 at 10:27 -0400, FeRD wrote: > > > On Sun, Aug 12, 2018 at 10:17 PM FeRD <[email protected]> wrote: > > > > On Sun, Aug 12, 2018 at 9:30 PM Sérgio Basto <[email protected]> wrote: > > Hi Frank > > to build openshot on epel7, first we need python3-qt5 on it [1] > but as we have python2-qt5 in EL7 core, we need do a python3 only for > epel 7 , we need create a new package because src.rpm can't have the > same name ... > > [1] > https://src.fedoraproject.org/fork/sergiomb/rpms/python-qt5/commits/master > > > Or maybe I didn't see, completely. Does the python3-qt5 package for el7 > need to go into rpmfusion, or over on the upstream side? (I guess what I'm > really asking would be: is there something I can do to make it available, > or do I just need to wait on it?) > > > Richard bringing it up reminded me that I never followed up on this. I'd > originally sent it while you were on holiday, and I'm sure it was buried in > the deluge of mail you probably had waiting for you when you returned. > > > > "Thread here [1] as wrote here [2] "Yes, that's really the only viable > option here, to do *only* python3-sip and python3-qt5" " > > So IIRC we need create package python3-sip only on epel 7 and we may do > that on Fedora , after that we may add python-qt5 to epel 7 . > > Epel 7 don't have python-qt5, but may we have to do a only python3-qt5 to > avoid conflicts IIRC. > > Best regards, > > [1] > > https://lists.fedoraproject.org/archives/list/[email protected]/thread/S4TXGVDZKEPCPXTA5S3E6IPNNPXDCCM2/#FWL36MDAAG6F3QUMW4EF772TOTRQLD5D > > [2] > > https://lists.fedoraproject.org/archives/list/[email protected]/message/QKLM7IJCH4ZRE4PHIPRCQE4MHZAMHGAS/ > > > > > > On Mon, 2018-08-13 at 03:07 +0200, Frank R Dana wrote: > > Summary of changes: > > > > d159021... - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_M > > ass (*) > > bd53ea4... - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_M > > ass (*) > > 6e98368... New upstream release (*) > > dbb1498... Add missing patch (*) > > > > (*) This commit already existed in another branch; no separate mail > > sent > > _______________________________________________ > rpmfusion-developers mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > -- > > Sérgio M. B. > > _______________________________________________ > rpmfusion-developers mailing list -- > [email protected] > To unsubscribe send an email to > [email protected] >
_______________________________________________ rpmfusion-developers mailing list -- [email protected] To unsubscribe send an email to [email protected]
