EPEL Weird error with libXft
$ mock -r epel-7-x86_64 --install libXft-devel Error: Package: libXft-devel-2.3.1-4.el7.x86_64 (build) Requires: libXft.so.2()(64bit) Available: libXft-2.3.1-4.el7.x86_64 (build) libXft.so.2()(64bit) You could try using --skip-broken to work around the problem Error: Package: libXft-devel-2.3.1-4.el7.x86_64 (build) Requires: libXft = 2.3.1-4.el7 Available: libXft-2.3.1-4.el7.x86_64 (build) libXft = 2.3.1-4.el7 You could try running: rpm -Va --nofiles --nodigest Any idea what that means? As I look at the error, it seems like there is no error at all and everything should be fine. libXft-devel requires libXft.so.2()(64bit), that is found in libXft-2.3.1-4.el7.x86_64. It also requires libXft = 2.3.1-4.el7, that is found in libXft-2.3.1-4.el7.x86_64 So where is the problem? I might be blind, but have no idea what's wrong. Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL mock configs for epel7
Dne 16.1.2014 16:38, Ken Dreyer napsal(a): Would anyone mind sharing their mock configurations for EPEL 7? I've got this http://ur1.ca/gfot7 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Re: python 2 retirement commo efforts
On 18.7.2018 20:24, R P Herrold wrote: On Tue, 17 Jul 2018, R P Herrold wrote: I've poked at getting accurate counts and manifests of unique python(2) package SRPMs off my mirror today -- I'll supplement this email with the script and links to the mainfests tomorrow. A 'sort | uniq' let me down as to getting an accurate count released today tomorrow arrived on me, but here are the promised report and links to the results and the generator script [/share/MD0_DATA/Mirror/lftp] # time ./stats.sh # packages starting with target: python # but NOT python3 # collated from a mirror: 20180718 264 /tmp/redhat_rhel_SRPMSonly_6Server.txt 475 /tmp/redhat_rhel_SRPMSonly_7Server.txt 644 /tmp/redhat_epel_6.txt 825 /tmp/redhat_epel_7.txt 2776 /tmp/redhat_fedora_fedora-28.txt 2132 /tmp/redhat_rawhide2017.txt real64m28.714s user1m11.330s sys 3m6.450s The first column is the number of unique SRPMs for a given archive, seen. Inside the files (the link of which is my second column and the basename of which is accessible per the links below) are detail counts of the number for each distinct SRPMs within a given package name, as seen on a local private mirror I use and maintain Copies of the detail, and of the script producing the reports are at: http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_6Server.txt http://gallery.herrold.com/stuff/redhat_rhel_SRPMSonly_7Server.txt http://gallery.herrold.com/stuff/redhat_epel_6.txt http://gallery.herrold.com/stuff/redhat_epel_7.txt http://gallery.herrold.com/stuff/redhat_fedora_fedora-28.txt http://gallery.herrold.com/stuff/redhat_rawhide2017.txt http://gallery.herrold.com/stuff/stats.sh The _purpose_ of getting the count of 'number of updated packages' for each given package is to permit seeing 'hot spots', and the 'no issues' 'build once and forget' packages particularly in RHEL and EPEL. Because of the way that current Fedora and RawHide are built, there is churn on rebuilds, even with non-material internal changes. THe The ** POINT ** of producing such a report is to 'put numbers' on the scope of the work rather than loose armwaving assertions such as: Fedora still has more than 3000 packages depending on python2 – many more than we can support without upstream help. Those are real Fedora numbers [0]. No armwaving involved. 1311 python2 only packages 1734 python2+python3 packages + 88 with packaging problem where I'm not sure That is something between 3045 and 3133. That can be rounded to 3k. No idea why we moved the discussion to another list as well, but stop accusing us from armwaving. We have data (for Fedora, because that where we started the discussion). As for RHEL/EPEL: current ones can remain as they are. Future ones see [1]. > Python 2 will be replaced with Python 3 in the next Red Hat Enterprise > Linux (RHEL) major release. [0] http://fedora.portingdb.xyz/ [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/DYI742D7UPV2M2EGDHUW55R6TJLEE5VH/
[EPEL-devel] EPEL: Python 3.4 will be EOL in March 2019
On 13.8.2018 11:49, Larry Hastings wrote on python-...@python.org: > We of the core dev community commit to supporting Python releases for > five years. Releases get eighteen months of active bug fixes, followed > by three and a half years of security fixes. Python 3.4 turns 5 next > March--at which point we'll stop supporting it, and I'll retire as 3.4 > release manager. > > My plan is to make one final release on or around its fifth birthday > containing the last round of security fixes. That's about seven > months from now. See also PEP 429 -- Python 3.4 Release Schedule [0]. We have python34 and python36 in EPEL7. python34 being the "main" one and python36 the "other" one. The original plan [1] was that once the ecosystem is adapted well enough, we can switch what "main" and "other" is and eventually drop python34, creating room for maybe another python3 release to be the "other" next (python38 maybe?). Originally this was supposed to happen for each release [2], but this was later abandoned due to lack of manpower. Do we want to ever switch "main" with "other"? The problem here is: $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.4' | pkgname | sort | uniq | wc -l 243 $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' | pkgname | sort | uniq | wc -l 15 The original idea is that all packages would have the python3_other macros in them [2] and all we need is rebuild everything in proper order, maybe with some bootstrapping. However that never happened and most of the packages I've seen lack the python3_other bits (no statistics, just my impression). Is this something we want? If so, are the packagers willing to adapt their packages (as much as I'd like to do this, I lack the resources to hack on 228 packages)? The Python Maint team in Red Hat is here to help. However the drive would need to come from the EPEL community, as now we are only guessing what are the needs here. [0] https://www.python.org/dev/peps/pep-0429/ [1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/VLTFSZEQHXBZHHDAKMT4KCQEKPSFV5OS/ [2] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/WIDTOW7HUOJI3QO4WNCG2DTTF5B3CLBE/
[EPEL-devel] Re: EPEL: Python 3.4 will be EOL in March 2019
On 21.8.2018 19:27, Stephen John Smoogen wrote: On Tue, 21 Aug 2018 at 13:24, Miro Hrončok wrote: On 13.8.2018 11:49, Larry Hastings wrote on python-...@python.org: > We of the core dev community commit to supporting Python releases for > five years. Releases get eighteen months of active bug fixes, followed > by three and a half years of security fixes. Python 3.4 turns 5 next > March--at which point we'll stop supporting it, and I'll retire as 3.4 > release manager. > > My plan is to make one final release on or around its fifth birthday > containing the last round of security fixes. That's about seven > months from now. See also PEP 429 -- Python 3.4 Release Schedule [0]. We have python34 and python36 in EPEL7. python34 being the "main" one and python36 the "other" one. The original plan [1] was that once the ecosystem is adapted well enough, we can switch what "main" and "other" is and eventually drop python34, creating room for maybe another python3 release to be the "other" next (python38 maybe?). Originally this was supposed to happen for each release [2], but this was later abandoned due to lack of manpower. Do we want to ever switch "main" with "other"? The problem here is: $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.4' | pkgname | sort | uniq | wc -l 243 $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' | pkgname | sort | uniq | wc -l 15 The original idea is that all packages would have the python3_other macros in them [2] and all we need is rebuild everything in proper order, maybe with some bootstrapping. However that never happened and most of the packages I've seen lack the python3_other bits (no statistics, just my impression). Is this something we want? If so, are the packagers willing to adapt their packages (as much as I'd like to do this, I lack the resources to hack on 228 packages)? The Python Maint team in Red Hat is here to help. However the drive would need to come from the EPEL community, as now we are only guessing what are the needs here. Understood. What are the groups initial recommendations for us to follow? I agree we need to have this done this fall/winter. [AKA I would like to say python34 will be removed by whatever EL7.x release comes out next.] I'd start untangling the deps and getting the following in: * six (looking at that one now) * pytest * Cython * PyYAML * pip * attrs * requests * mock -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/DO5PWOJAQBTKV4565Q5XJI5WQX5ZUTXV/
[EPEL-devel] Re: EPEL: Python 3.4 will be EOL in March 2019
On 21.8.2018 19:56, Miro Hrončok wrote: On 21.8.2018 19:27, Stephen John Smoogen wrote: On Tue, 21 Aug 2018 at 13:24, Miro Hrončok wrote: On 13.8.2018 11:49, Larry Hastings wrote on python-...@python.org: > We of the core dev community commit to supporting Python releases for > five years. Releases get eighteen months of active bug fixes, followed > by three and a half years of security fixes. Python 3.4 turns 5 next > March--at which point we'll stop supporting it, and I'll retire as 3.4 > release manager. > > My plan is to make one final release on or around its fifth birthday > containing the last round of security fixes. That's about seven > months from now. See also PEP 429 -- Python 3.4 Release Schedule [0]. We have python34 and python36 in EPEL7. python34 being the "main" one and python36 the "other" one. The original plan [1] was that once the ecosystem is adapted well enough, we can switch what "main" and "other" is and eventually drop python34, creating room for maybe another python3 release to be the "other" next (python38 maybe?). Originally this was supposed to happen for each release [2], but this was later abandoned due to lack of manpower. Do we want to ever switch "main" with "other"? The problem here is: $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.4' | pkgname | sort | uniq | wc -l 243 $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' | pkgname | sort | uniq | wc -l 15 The original idea is that all packages would have the python3_other macros in them [2] and all we need is rebuild everything in proper order, maybe with some bootstrapping. However that never happened and most of the packages I've seen lack the python3_other bits (no statistics, just my impression). Is this something we want? If so, are the packagers willing to adapt their packages (as much as I'd like to do this, I lack the resources to hack on 228 packages)? The Python Maint team in Red Hat is here to help. However the drive would need to come from the EPEL community, as now we are only guessing what are the needs here. Understood. What are the groups initial recommendations for us to follow? I agree we need to have this done this fall/winter. [AKA I would like to say python34 will be removed by whatever EL7.x release comes out next.] I'd start untangling the deps and getting the following in: * six (looking at that one now) https://src.fedoraproject.org/rpms/python3-six/pull-request/1 * pytest * Cython * PyYAML * pip * attrs * requests * mock -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/QV7HL77AUZQIB6E3BB7DSRP5WBUKO2WA/
[EPEL-devel] Re: Singularity and python3 - was Re: EPEL: Python 3.4 will be EOL in March 2019
On 25.8.2018 19:29, Andrew C Aitchison wrote: On Tue, 21 Aug 2018, Miro Hrončok wrote: On 13.8.2018 11:49, Larry Hastings wrote on python-...@python.org: We of the core dev community commit to supporting Python releases for five years. Releases get eighteen months of active bug fixes, followed by three and a half years of security fixes. Python 3.4 turns 5 next March--at which point we'll stop supporting it, and I'll retire as 3.4 release manager. My plan is to make one final release on or around its fifth birthday containing the last round of security fixes. That's about seven months from now. See also PEP 429 -- Python 3.4 Release Schedule [0]. We have python34 and python36 in EPEL7. python34 being the "main" one and python36 the "other" one. The original plan [1] was that once the ecosystem is adapted well enough, we can switch what "main" and "other" is and eventually drop python34, creating room for maybe another python3 release to be the "other" next (python38 maybe?). Originally this was supposed to happen for each release [2], but this was later abandoned due to lack of manpower. How does this affect EPEL6 ? It doesn't. No python36 in EPEL 6. I guess it will just have an EOLed Python 3.4 packaged until it's also EOLed. We have just released singularity-runtime-2.6.0-1.1.el6.x86_64.rpm which adds a dependency on /usr/bin/python3 Will EPEL6 users have to pull in an epel python3.6 as well as epel python3.4 (and possibly in addition to SCL python33) ? /usr/bin/python3 is provided by python34, so it will just use that. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Updating python3-setuptools in EPEL7
On 05. 11. 18 1:12, Orion Poplawski wrote: I'd like to update python3-setuptools from 19.6.2 to something newer (at least 20.8.1 but hopefully much later) without breaking the world. However, I don't have much experience with possible setuptools breakage. Any suggestions would be greatly appreciated. I'd do it in copr and mass rebuild everything (all python3 packages) in it. If it works, I'd assume it is safe. If there are FTBFS, I'd investigate if they are setuptools related. Feel free o bring any possible setuptools related problems here so we can all try to figure them out. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposal for EPSCO: Python34 Moving to Python36
On 18. 11. 18 1:21, Orion Poplawski wrote: On 11/15/18 10:08 AM, Stephen John Smoogen wrote: I missed this in the last meeting from items that needed to be voted on. The changes would be to make epel macros to have %python3_pkgversion 36 %python3_other_pkgversion 34 This should allow for the build system to rebuild python3 items as default. Then we will need a tracking ticket and bump/rebuild the packages Be aware that this will cause many current python34-* packages to disappear the next time they are rebuilt for EPEL7. This was the plan from the beginning and as long as we inform all the interested parties (read: maintainers of such packages, users), we shall be good. EPEL "officials" need to decide whether to do it now, or align the change with the next RHEL 7.x release. As a Python Maintainer in Fedora and RHEL, I can say that we would very much like to see this happen and preferably sooner than later . We would like to add Python 3.6 to RHEL 7, but at this point we cannot make any promises. If we add it, it will most likely own /usr/bin/python3 and %__python3 will in all likelihood point to 3.6. We want to avoid as much breakage in EPEL as possible. Proposal: * We change macros.python3 [1] to 3.6. * We change macros.python3_other [2] to 3.4. * We rename the package to python-rpm-epel-macros (or whatever is the name convention) and the subpackages to python-srpm-epel-macros etc. In case python-rpm-macros comes to RHEL proper. Once (if) it does, we remove macros.python3 from the EPEL package. * We put this to all the announcement channels EPEL has. Caveat: If a packager needs to rebuild their package without changing the Python version, they need to invert the macros. This information needs to be part of the announcement. [1] https://src.fedoraproject.org/rpms/python-rpm-macros/blob/epel7/f/macros.python3 [2] https://src.fedoraproject.org/rpms/python-rpm-macros/blob/epel7/f/macros.python3_other -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python34 -> Python36 test copr
On 12. 02. 19 13:59, Stephen John Smoogen wrote: The Fedora Python team has been working on getting a test rebuild of Python for moving epel-7 to python36 [Thank you very much for this work.] https://copr.fedorainfracloud.org/coprs/g/python/epel-python3/monitor/ Out of 282 packages which are compiled with python34, only 35 have failed to build and will need extra help to make work. This will be on us in EPEL to get done as it might require various updates of packages and other items. Currently there is no obsoletes package path so python34 and python36 conflict. We need to work out how a person will move their system and what problems can occur. See also: https://src.fedoraproject.org/rpms/python3-zope-interface/pull-request/1 https://src.fedoraproject.org/rpms/python3-pytest/pull-request/2 https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/16 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Epel7 Questions: Python34 - 36 transition
On 10. 03. 19 4:15, Troy Dawson wrote: Hello, There are a few questions I have, and since I'm not positive who all of the correct people ask are, I'm sending to the epel-devel list. Before I start the questions, thank you to everyone who helped out in getting the build failures working. Thank you. thank you. thank you. We have all the python packages rebuilt. All of the packages needed for the rebuilds are tagged into override, and thus in the buildroot. None of these rebuilt packages have been put into updates, and thus are not in -testing. Where do we go from here? A) Do I do one big update for all of the rebuilt packages? B) Do I do individual updates for each package? C) Some combination of above? D) Do a side tag, and take out all the overrides? I personally think C. Do the main components (rpm macros, python34 and python36) in one update. All the rest get their individual update. To be sure, I think you have to do it all together (A). Lets say there is a package that has following subpackage / file / shebang: pytohn3X-foo: /usr/bin/foo : #!/usr/bin/python3 + files in python3.X sitelib/sitearch - if you push this before the interpreters, it breaks - if you push the interpreters before this, it breaks Theoretically, you should be able to write a clever automation that would give you some hint about packages that do this, but in practice, going with (A) is much easier. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Epel7 Questions: Python34 - 36 transition
On 11. 03. 19 15:54, Troy Dawson wrote: On Sat, Mar 9, 2019 at 8:16 PM Kevin Fenzi wrote: On 3/9/19 7:15 PM, Troy Dawson wrote: Hello, There are a few questions I have, and since I'm not positive who all of the correct people ask are, I'm sending to the epel-devel list. Before I start the questions, thank you to everyone who helped out in getting the build failures working. Thank you. thank you. thank you. We have all the python packages rebuilt. All of the packages needed for the rebuilds are tagged into override, and thus in the buildroot. None of these rebuilt packages have been put into updates, and thus are not in -testing. Where do we go from here? A) Do I do one big update for all of the rebuilt packages? Yes. B) Do I do individual updates for each package? C) Some combination of above? Bad idea, as then some dependent packages could go out stable without all the packages they need. D) Do a side tag, and take out all the overrides? Nope... side tag won't push them out, unless we just merge them into the main tag, but then they are bypassing testing. I personally think C. Do the main components (rpm macros, python34 and python36) in one update. All the rest get their individual update. All the other ones are going to need at least python36, so no, they should all be in one big update. Otherwise some of them could go stable and not have the python36 yet. How long do we expect to be in this testing stage? I'd say at least 2 weeks? If packagers want to update their python package for whatever reason, what should they do? Build as usual, but ask someone to edit the update and remove the previous one and add in the new one. Thanks for building and coordinating everything! kevin Thanks for the feedback. You too Miro. After reading both of your reasons for doing A), I agree with you both. Unless anyone objects, we'll plan to do option A Here is my build to include: python-distlib-0.2.7-3.el7 Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL: Python34 moving to Python36
On 13. 03. 19 18:42, Wart wrote: Transaction check error: file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from install of python34-six-1.11.0-2.el7.noarch conflicts with file from package python34-six-1.11.0-1.el7.noarch IS that a file to directory problem? Otherwise python34-six-1.11.0-2.el7.noarch should just replace python34-six-1.11.0-1.el7.noarch "naturally" without any specific conflict. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL: Python34 moving to Python36
On 14. 03. 19 0:53, Orion Poplawski wrote: On 3/13/19 11:48 AM, Miro Hrončok wrote: On 13. 03. 19 18:42, Wart wrote: Transaction check error: file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from install of python34-six-1.11.0-2.el7.noarch conflicts with file from package python34-six-1.11.0-1.el7.noarch IS that a file to directory problem? Otherwise python34-six-1.11.0-2.el7.noarch should just replace python34-six-1.11.0-1.el7.noarch "naturally" without any specific conflict. I think I figured this out. During the install step if we didn't have a tests_require package installed we got: running install_egg_info Writing /builddir/build/BUILDROOT/python3-six-1.11.0-2.el7.noarch/usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info BUILDSTDERR: /usr/lib64/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'tests_require' BUILDSTDERR: warnings.warn(msg) and ended up with a file egg-info instead of a directory. I've rebuilt python3-six with the test requirements installed for both versions now. I'll add python3-six-1.11.0-3.el7.src.rpm to the update. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36
On 13. 03. 19 15:30, Stephen John Smoogen wrote: Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George, and several helpers have gotten nearly all of the python34 packages moves over to python36 in EPEL-7. They are being included in 6 Bodhi pushes because of a limitation in Bodhi for the text size of packages in an include. The current day for these package groups to move into EPEL regular is April 2nd. We would like to have all tests we find in the next week or so also added so that the updates can occur in a large group without too much breakage. A problem was pointed out in https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada#comment-914787 If you have 3rd party software using /usr/bin/python3 and you have python34 installed, updating your system will remove that symlink and your software breaks. However we cannot obsolete python34 form python36, because that breaks software that actually wants and uses /usr/bin/python3.4 and possibly make python34 uninstallable (not sure). So arguably, the update should update both python34 and install python36, keeping both Pythons available, the user/admin could than remove the one that is not needed. AFAIK The only thing that would make this happen is to require python36 from python34. And that seems like a huge ugly workaround with unwanted side affects. Any ideas? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36
On 25. 03. 19 18:56, Kevin Fenzi wrote: Just make python36 obsolete the old version of python34 that had /usr/bin/python3. This causes yum to install the new python34 and pull in python36 for /usr/bin/python3. If that works, we are good. Does it really behave like that with plain upgrade? E.g. without specifying what to upgrade? I thought that obsoleting old py34 can do one of the following: A) python34 gets queued for upgrading first, there is no more old python34 to be obsoleted by python36, python36 isn't installed. B) python36 gets queued for obsoleting old python34 first, python34 gets queued for removing instead of updating, there is more pytho34 to be updated. C) what you said. If C) is the guaranteed behavior, I guess we are good to do this. It does mean people with 3rd party software are now using python36 instead of 34, but if they only speficied /usr/bin/python3, it should just run with any python3 version right? As long as they are only using standard library, yes. Otherwise there might be problems. However that was anticipated. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36
On 26. 03. 19 1:51, Miro Hrončok wrote: On 25. 03. 19 18:56, Kevin Fenzi wrote: Just make python36 obsolete the old version of python34 that had /usr/bin/python3. This causes yum to install the new python34 and pull in python36 for /usr/bin/python3. If that works, we are good. Does it really behave like that with plain upgrade? E.g. without specifying what to upgrade? I thought that obsoleting old py34 can do one of the following: A) python34 gets queued for upgrading first, there is no more old python34 to be obsoleted by python36, python36 isn't installed. B) python36 gets queued for obsoleting old python34 first, python34 gets queued for removing instead of updating, there is more pytho34 to be updated. C) what you said. If C) is the guaranteed behavior, I guess we are good to do this. It does mean people with 3rd party software are now using python36 instead of 34, but if they only speficied /usr/bin/python3, it should just run with any python3 version right? As long as they are only using standard library, yes. Otherwise there might be problems. However that was anticipated. A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27 I'm still not sure about how it will behave. We should probably test it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36
On 28. 03. 19 21:54, Tuomo Soini wrote: On Thu, 28 Mar 2019 13:22:26 +0100 Miro Hrončok wrote: A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27 I'm still not sure about how it will behave. We should probably test it. https://bugzilla.redhat.com/show_bug.cgi?id=1687196 Check my bug report first. You only need obsoletes in one place and there was my suggested patch which was not good enough for some, but it i a lot better than suggested change from Conflicts to Obsoletes all over. I don't understand why the obsoletes all over are any worse than just one. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL: Python34 moving to Python36
On 04. 04. 19 10:08, Phil Wyett wrote: Hi, Just performed migration from 34 to 36. After yum update to pull all packages and install, I proceeded to install 36 packages to match my current 34 install before removing 34 packages. The only issue in the whole process was the one below that required python34-pylint be removed before installing the 36 version. [philwyett@ks-kenobi ~]$ sudo yum install python36-pylint [sudo] password for philwyett: Loaded plugins: langpacks, product-id, search-disabled-repos, subscription- : manager Resolving Dependencies - --> Running transaction check - ---> Package python36-pylint.noarch 0:1.6.5-5.el7 will be installed - --> Processing Dependency: python36-setuptools for package: python36-pylint- 1.6.5-5.el7.noarch - --> Running transaction check - ---> Package python36-setuptools.noarch 0:39.2.0-3.el7 will be installed - --> Finished Dependency Resolution Dependencies Resolved PackageArch Version Repository Size Installing: python36-pylintnoarch1.6.5-5.el7 epel437 k Installing for dependencies: python36-setuptoolsnoarch39.2.0-3.el7epel631 k Transaction Summary Install 1 Package (+1 Dependent package) Total download size: 1.0 M Installed size: 5.7 M Is this ok [y/d/N]: y Downloading packages: (1/2): python36-pylint-1.6.5-5.el7.noarch.rpm | 437 kB 00:01 (2/2): python36-setuptools-39.2.0-3.el7.noarch.rpm | 631 kB 00:01 - Total 591 kB/s | 1.0 MB 00:01 Running transaction check Running transaction test Transaction check error: file /usr/bin/epylint-3 from install of python36-pylint-1.6.5-5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch file /usr/bin/pylint-3 from install of python36-pylint-1.6.5-5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch file /usr/bin/pyreverse-3 from install of python36-pylint-1.6.5-5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch file /usr/bin/symilar-3 from install of python36-pylint-1.6.5-5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch file /usr/share/man/man1/epylint-3.1.gz from install of python36-pylint-1.6.5- 5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch file /usr/share/man/man1/pylint-3.1.gz from install of python36-pylint-1.6.5- 5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch file /usr/share/man/man1/pylint-gui-3.1.gz from install of python36-pylint- 1.6.5-5.el7.noarch conflicts with file from package python34-pylint-1.6.5- 4.el7.noarch file /usr/share/man/man1/pyreverse-3.1.gz from install of python36-pylint- 1.6.5-5.el7.noarch conflicts with file from package python34-pylint-1.6.5- 4.el7.noarch file /usr/share/man/man1/symilar-3.1.gz from install of python36-pylint-1.6.5- 5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch Thanks for the report. A fix: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f076346dfb -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] EPEL7: Adapting %python_provide to provide python3- for python36-
Hey,
since the plan is to have some python3-... packages in RHEL proper, should we
adapt the %python_provide macro to provide python3-... when it gets python36-...?
%{python_provide python36-foo} currently does nothing.
I propose to change it to do: Provides: python3-foo = %{version}-%{release}.
Note: %{python_provide python2-foo} currently adds obsoletes, let's not add them
for the python36 case (there is nothing to obsolete here, quite the opossite -
python3-foo from RHEL would in theory obsolete python36-foo from EPEL).
Arguably, this discussion should have happened before we did the mass rebuild
for 3.4 -> 3.6 transition, however I don't consider such provides essential. The
idea is to change the macro, but don't mass rebuild - instead start providing
the provides gradually.
Note that not all EPEL7 Python 3 packages use this macro, but many do.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL7: Adapting %python_provide to provide python3- for python36-
On 24. 04. 19 12:43, Stephen John Smoogen wrote: Note that not all EPEL7 Python 3 packages use this macro, but many do. Should they? So far there was no reason apart from the "make this similar to Fedora spec" kind of reason. Today, the macro is essentially a no-op for Python 3 both in Fedora and EPEL, however in Fedora, the guidelines explicitly say to use it. For EPEL, there are no Python guidelines, only tribal knowledge AFAIK. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL7: Adapting %python_provide to provide python3- for python36-
On 24. 04. 19 12:23, Miro Hrončok wrote:
Hey,
since the plan is to have some python3-... packages in RHEL proper, should we
adapt the %python_provide macro to provide python3-... when it gets python36-...?
%{python_provide python36-foo} currently does nothing.
I propose to change it to do: Provides: python3-foo = %{version}-%{release}.
Note: %{python_provide python2-foo} currently adds obsoletes, let's not add them
for the python36 case (there is nothing to obsolete here, quite the opossite -
python3-foo from RHEL would in theory obsolete python36-foo from EPEL).
Arguably, this discussion should have happened before we did the mass rebuild
for 3.4 -> 3.6 transition, however I don't consider such provides essential. The
idea is to change the macro, but don't mass rebuild - instead start providing
the provides gradually.
Note that not all EPEL7 Python 3 packages use this macro, but many do.
A PR is here:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/18
I'd appreciate feedback from EPEL packagers.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL7: Adapting %python_provide to provide python3- for python36-
On 25. 04. 19 16:43, Miro Hrončok wrote:
On 24. 04. 19 12:23, Miro Hrončok wrote:
Hey,
since the plan is to have some python3-... packages in RHEL proper, should we
adapt the %python_provide macro to provide python3-... when it gets python36-...?
%{python_provide python36-foo} currently does nothing.
I propose to change it to do: Provides: python3-foo = %{version}-%{release}.
Note: %{python_provide python2-foo} currently adds obsoletes, let's not add
them for the python36 case (there is nothing to obsolete here, quite the
opossite - python3-foo from RHEL would in theory obsolete python36-foo from
EPEL).
Arguably, this discussion should have happened before we did the mass rebuild
for 3.4 -> 3.6 transition, however I don't consider such provides essential.
The idea is to change the macro, but don't mass rebuild - instead start
providing the provides gradually.
Note that not all EPEL7 Python 3 packages use this macro, but many do.
A PR is here:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/18
I'd appreciate feedback from EPEL packagers.
Update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dad4eed6b7
Override: https://bodhi.fedoraproject.org/overrides/python-rpm-macros-3-24.el7
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: What happened to the 'python34-pycurl' and 'python34-mysql' packages?
On 30. 04. 19 22:41, Fred Gleason wrote: Greetings! I am attempting to ascertain the current status of the 'python34- pycurl' and 'python34-mysql' packages on EPEL for RHEL7. It appears that these may have gone missing around the time of the addition of the 'python36-' packages about a month ago. Were these packages withdrawn intentionally? Curiously, I can still see numerous other 'python34-' packages --i.e. 'python34-requests' -- as being available. I can also see that 'python36-pycurl' and 'python36-mysql' packages both currently exist. Yes, with the transition form 3.4 to 3.6, some python34 packages are gone. Some packages build for both versions (such as requests), some only build for the "primary version". That changed from 3.4 to 3.6. I suggest to migrate to Python 3.6. If you indeed need those packages, file RFE bugzillas against python3-mysql: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&version=epel7&component=python3-mysql Or/and python3-pycurl: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&version=epel7&component=python3-pycurl -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL7: Adapting %python_provide to provide python3- for python36-
On 30. 04. 19 10:50, Miro Hrončok wrote:
On 25. 04. 19 16:43, Miro Hrončok wrote:
On 24. 04. 19 12:23, Miro Hrončok wrote:
Hey,
since the plan is to have some python3-... packages in RHEL proper, should we
adapt the %python_provide macro to provide python3-... when it gets
python36-...?
%{python_provide python36-foo} currently does nothing.
I propose to change it to do: Provides: python3-foo = %{version}-%{release}.
Note: %{python_provide python2-foo} currently adds obsoletes, let's not add
them for the python36 case (there is nothing to obsolete here, quite the
opossite - python3-foo from RHEL would in theory obsolete python36-foo from
EPEL).
Arguably, this discussion should have happened before we did the mass rebuild
for 3.4 -> 3.6 transition, however I don't consider such provides essential.
The idea is to change the macro, but don't mass rebuild - instead start
providing the provides gradually.
Note that not all EPEL7 Python 3 packages use this macro, but many do.
A PR is here:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/18
I'd appreciate feedback from EPEL packagers.
Update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dad4eed6b7
Override: https://bodhi.fedoraproject.org/overrides/python-rpm-macros-3-24.el7
Note that it currently only works for Python 3 only SRPMS as python-devel from
RHEL7 overrides the macro with its original version. We plan to change the macro
on RHEL7 side as well, but (business as usual) we cannot do it right away.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: What happened to the 'python34-pycurl' and 'python34-mysql' packages?
On 02. 05. 19 19:10, Fred Gleason wrote: On Wed, 2019-05-01 at 16:17 -0700, Kevin Fenzi wrote: Can you please refile that as two bugs? On python3-pycurl and python3-mysql? The python34 component is only for python34 itself, you will need to get those other two packages to fix things. I did attempt this initially, but the 'Component' field refuses to accept 'python34-mysql' or 'python34-pycurl' as a valid value. What should the proper value there be? From my previous e-mail: File RFE bugzillas against python3-mysql: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&version=epel7&component=python3-mysql Or/and python3-pycurl: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&version=epel7&component=python3-pycurl -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy
On 30. 05. 19 20:21, Stephen Gallagher wrote: ## epel8-rawhide: This branch will be left alone until and unless the packager decides that they want to stage a major (possibly incompatible) change for the next RHEL 8.Y minor release. At that time, they will need to remove the package.cfg file from the epel8 branch and manually merge the proposed changes desired into the epel8-rawhide branch and build there. Just a small consideration here: Can this thing not be called Rawhide? Rawhide is Fedora. I'd like to keep that clear, so when we talk about rawhide in various places, we don't have to say: Fedora Rawhide (although we often do). Imagine this conversation: A: I want to do a major cleanup of %scripts in Fedora. B: But what about EPEL? A: I'll do it in Rawhide only. Having an EPEL Rawhide makes the last statement ambiguous. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: RHEL 7.7 Beta
On 12. 06. 19 8:14, Thomas Stephen Lee wrote: Hi, Just for your information. https://www.redhat.com/en/blog/red-hat-enterprise-linux-77-beta-now-available Python 3.6 is there in 7.7 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.7_release_notes/overview thanks In that case, let's proceed with: https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/19 https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/20 https://src.fedoraproject.org/rpms/python34/pull-request/35 Starting here: https://bugzilla.redhat.com/show_bug.cgi?id=1719633 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: RHEL 7.7 Beta
On 19. 06. 19 19:22, Kevin Fenzi wrote: On 6/12/19 1:48 AM, Miro Hrončok wrote: On 12. 06. 19 8:14, Thomas Stephen Lee wrote: Hi, Just for your information. https://www.redhat.com/en/blog/red-hat-enterprise-linux-77-beta-now-available Python 3.6 is there in 7.7 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.7_release_notes/overview thanks In that case, let's proceed with: https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/19 https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/20 https://src.fedoraproject.org/rpms/python34/pull-request/35 Starting here: https://bugzilla.redhat.com/show_bug.cgi?id=1719633 But we don't want to actually land that until 7.7 is out right? We do. It is designed to work, after 7.7 GA python-rpm-macros package gets retired on EPEL. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: RHEL 7.7 Beta
On 19. 06. 19 23:58, Miro Hrončok wrote: On 19. 06. 19 19:22, Kevin Fenzi wrote: On 6/12/19 1:48 AM, Miro Hrončok wrote: On 12. 06. 19 8:14, Thomas Stephen Lee wrote: Hi, Just for your information. https://www.redhat.com/en/blog/red-hat-enterprise-linux-77-beta-now-available Python 3.6 is there in 7.7 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7-beta/html/7.7_release_notes/overview thanks In that case, let's proceed with: https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/19 https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/20 https://src.fedoraproject.org/rpms/python34/pull-request/35 Starting here: https://bugzilla.redhat.com/show_bug.cgi?id=1719633 But we don't want to actually land that until 7.7 is out right? We do. It is designed to work, after 7.7 GA python-rpm-macros package gets retired on EPEL. Everything ready as an EPEL7 update, with buildroot overrides: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f505f7d2fb If you get some weird failures, please report it there. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
Hey, when RHEL 7.7 will be released, the following new components/packages will be provided (assuming from 7.7 beta): python3 - the Python 3.6 package This new RHEL7 component builds several subpackages, all obsoleting the subpackages of epel7 python36 package. We will simply retire python36 from epel7. python-rpm-macros = This new RHEL7 component is a drop-in replacement of python-rpm-macros from epel7, we will simply retire the package. python-epel-rpm-macros already provide the necessary macros for python34 in epel7. python3-setuptools == This new RHEL7 component produces the python3-setuptools package that obsoletes the python36-setuptools package (built from the python3-setuptools epel7 component). We cannot simply retire python3-setuptools from epel7, as it also builds python34-setuptools in epel7 and there is no replacement for that in RHEL7. Easiest thing would be to stop building python36-setuptools and only keep python34-setuptools in epel7, however IIRC we cannot have the same component name as in RHEL. If that is indeed the case, python3-setuptools needs to be retired and a new python34-setuptools component needs to be created in epel7. Is my assumption correct? python-pip == This new RHEL7 component produces the python3-pip package that obsoletes the python36-pip package (built from the python-pip epel7 component). The python-pip epel7 component also produces python34-pip and python2-pip (neither available in RHEL 7.7). If my previous assumption about components with RHEL names is correct, we need 1 or 2 new components for python34-pip and python2-pip - either we have each in a separate component or we create a new component that builds both (called python-pip-epel maybe?). python-wheel This new RHEL7 component produces the python3-wheel package. The python-wheel epel7 component produced python-wheel package (Python 2). The epel7 package was adapted to produce python2-wheel and python36-wheel, however there was no successful build of this in epel7. If my previous assumption about components with RHEL names is correct, we need to add a new python2-wheel component to epel7. Are my assumptions correct? If we indeed need new packages/components, I can help to create them, but I do not intent to maintain them. Any takers? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 17. 07. 19 0:00, Miro Hrončok wrote: ...we need 1 or 2 new components for python34-pip and python2-pip - either we have each in a separate component or we create a new component that builds both (called python-pip-epel maybe?). What is the advice here? If I want it to be just one package, what shall be its name? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 25. 07. 19 14:51, Stephen John Smoogen wrote:
Yes your assumption is correct. Koji uses src.rpm names to determine what it
pulls into a buildroot. That means that the python34 items need to have
non-conflicting names with the python3 ones shipped by upstream.. or we will
just start building with python34 or worse.
I've already prepared python34-setuptools:
https://src.fedoraproject.org/rpms/python3-setuptools/pull-request/4
https://bugzilla.redhat.com/show_bug.cgi?id=1733190
And python2-wheel:
https://src.fedoraproject.org/rpms/python-wheel/pull-request/10
https://bugzilla.redhat.com/show_bug.cgi?id=1733193
I'm waiting for the name suggestion for python{2,34}-pip.
> Would it make sense to just retire python34 completely from EPEL at the 7.7
> release date?
Python 3.4 is upstream unsupported, so getting rid of it sooner than later is
probably a good idea. However, I suggest to keep it around until EL6 is EOL.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 25. 07. 19 15:30, Miro Hrončok wrote:
I'm waiting for the name suggestion for python{2,34}-pip.
Is python-pip-epel fine? Or should it be 2 source RPMs?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 29. 07. 19 13:17, Miro Hrončok wrote:
On 25. 07. 19 15:30, Miro Hrončok wrote:
I'm waiting for the name suggestion for python{2,34}-pip.
Is python-pip-epel fine? Or should it be 2 source RPMs?
I went with python-pip-epel, since nobody seems to mind that one:
https://bugzilla.redhat.com/show_bug.cgi?id=1737028
https://src.fedoraproject.org/rpms/python-pip/pull-request/39
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le
On 09. 08. 19 11:13, Antonio Trande wrote: Hi all. 'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on EPEL7 ppc64le only? https://koji.fedoraproject.org/koji/getfile?taskID=36879492&volume=DEFAULT&name=root.log&offset=-4000 It does it on all architectures. This looks like the RHEL 7.7 version of the package. python(2)-rpm-macros 3-32 should be there as well. Is it possible that you have caught the builders mid updating? Such as the ppc64le packages were updated to 7.7 but the noarch packages were not yet? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le
On 09. 08. 19 12:17, Pablo Sebastián Greco wrote: El 9/8/19 a las 07:08, Miro Hrončok escribió: On 09. 08. 19 11:13, Antonio Trande wrote: Hi all. 'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on EPEL7 ppc64le only? https://koji.fedoraproject.org/koji/getfile?taskID=36879492&volume=DEFAULT&name=root.log&offset=-4000 It does it on all architectures. This looks like the RHEL 7.7 version of the package. python(2)-rpm-macros 3-32 should be there as well. Is it possible that you have caught the builders mid updating? Such as the ppc64le packages were updated to 7.7 but the noarch packages were not yet? I think that what is happening is that koji is ignoring the RHEL version. The last python-rpm-macros built in koji for epel, is 3.25, and this one has priority over 3.32 imported from RHEL 7.7 (locally built is more important than external, no matter the version). This package needs to be retired from EPEL so it can pick up the RHEL version, which is also mandatory due to EPEL guidelines. Will do. I was waiting for the release to happen. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 17. 07. 19 0:00, Miro Hrončok wrote: Hey, when RHEL 7.7 will be released, the following new components/packages will be provided (assuming from 7.7 beta): https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-31bd12e515 Please somebody do a sanity check, so I can retire python-pip, python3-setuptools and python-wheel. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 09. 08. 19 16:49, Stephen John Smoogen wrote: I have tested python2-wheel and it worked. Looking to see what needs to be done for th eohters. Thanks. The update is for all 3 of them. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 09. 08. 19 17:38, Stephen John Smoogen wrote: I tested all three and gave karma. Thanks. I'll wait for the push and retire the old packages. I hope everything will work as expected. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le
On 10. 08. 19 11:53, Antonio Trande wrote: When will it happen? I did that right after that e-mail: https://src.fedoraproject.org/rpms/python-rpm-macros/c/b6f2fa0c7616565c964e5c72ecfddb6e712c2266?branch=epel7 If ti doesn't work, maybe some Koji admins need to do stuff? Or it just takes a while? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem
While I really tried to do my best, it seems that I broke CentOS by retiring python36. Should it be unretired? Or is it reasonable to say: Please wait for CentOS 7.7? https://bugzilla.redhat.com/show_bug.cgi?id=1739804 Also after retiring python-rpm-macros, Koji doesn't seem to see the RHEL one. Is there any action to take? https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/UKHD6IXORQ6RNNL4JZ67PGQHOMIBVUZZ/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem
On 10. 08. 19 21:23, Miro Hrončok wrote: While I really tried to do my best, it seems that I broke CentOS by retiring python36. Should it be unretired? Or is it reasonable to say: Please wait for CentOS 7.7? https://bugzilla.redhat.com/show_bug.cgi?id=1739804 If any EPEL expert thinks the package should be unretired for now, please do so. Also after retiring python-rpm-macros, Koji doesn't seem to see the RHEL one. Is there any action to take? https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/UKHD6IXORQ6RNNL4JZ67PGQHOMIBVUZZ/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem
On 11. 08. 19 2:58, Stephen John Smoogen wrote: On Sat, 10 Aug 2019 at 17:12, Miro Hrončok <mailto:mhron...@redhat.com>> wrote: On 10. 08. 19 21:23, Miro Hrončok wrote: > While I really tried to do my best, it seems that I broke CentOS by retiring > python36. Should it be unretired? Or is it reasonable to say: Please wait for > CentOS 7.7? > > https://bugzilla.redhat.com/show_bug.cgi?id=1739804 If any EPEL expert thinks the package should be unretired for now, please do so. Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is out in the CR repo. My apologies for not thinking of this when you were mentioning things yesterday. I do not have the rights to unretire things so will need to get in touch with Mohan/Kevin/Mizdebsk on what to do. https://pagure.io/releng/issue/8607 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Is Koschei using CentOS 7 in the EPEL 7 resolve check?
See for example: https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7 2019-08-11 07:50:11 - nothing provides python(abi) = 3.6 ... This is provided in RHEL 7.7. (Note that we've unretired the python36 package, so later it resolved correctly.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem
On 11. 08. 19 9:59, Mohan Boddu wrote: I unretired the packages and tagged the old builds, I think that should fix the buildroot and got a testing build working. Thanks, now. Assuming Koji sees RHEL 7.7, can we somehow: - keep the packages in the repos - but make Koji prefer the RHEL ones (they have higher EVR)? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem
On 10. 08. 19 21:23, Miro Hrončok wrote: While I really tried to do my best, it seems that I broke CentOS by retiring python36. Should it be unretired? Or is it reasonable to say: Please wait for CentOS 7.7? https://bugzilla.redhat.com/show_bug.cgi?id=1739804 Currently I cannot even init an epel7 mock: Error: Problem: conflicting requests - nothing provides python-rpm-macros needed by epel-rpm-macros-7-20.noarch - nothing provides python-srpm-macros needed by epel-rpm-macros-7-20.noarch - nothing provides python2-rpm-macros needed by epel-rpm-macros-7-20.noarch -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 11. 08. 19 20:41, Tuomo Soini wrote: On Fri, 9 Aug 2019 17:39:45 +0200 Miro Hrončok wrote: On 09. 08. 19 17:38, Stephen John Smoogen wrote: I tested all three and gave karma. Thanks. I'll wait for the push and retire the old packages. I hope everything will work as expected. I noticed a issue, python-pip-epel can't be build on up to date 7.7 system because python3_other srpm related macros are not provided by any package. I guess python-epel-rpm-macros package should provide python3-other-srpm-macros for python34 related bits. And these two new packages python3-other-srpm-macros and python3-other-rpm-macros should be added as dependency to epel-rpm-macros. There is python-epel-rpm-macros source package in EPEL now. It builds the python3-other-rpm-macros package. python34-devel requires python3-other-rpm-macros. epel-rpm-macros requires python-srpm-macros. python-srpm-macros form RHEL 7.7+ indeed don't have this bit: %python3_other_pkgversion 34 I believe the easiest fix is to define that directly in epel-rpm-macros: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5 Thanks for the report! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 12. 08. 19 8:14, Tuomo Soini wrote: On Sun, 11 Aug 2019 22:26:45 +0200 Miro Hrončok wrote: %python3_other_pkgversion 34 I believe the easiest fix is to define that directly in epel-rpm-macros: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5 Correct. That fixes this issue but not the huge issue we have now. Thanks for the report! I agree. But we have much bigger problem with epel python naming. python3_other is now defined to 3 in rhel7.7. By what? Do you mean python3_pkgversion? W can override that as well. Because epel is supposed to add packages to rhel, we have now new definition which is our master. That means with 7.7 system and mock, there is no possibility to build python36 packages any more. Because rhel selected python3 naming when inroduced python3 that gives epel7 new baseline for naming standard for python3 packages which means we should now follow that on epel7 post rhel7.7. Before python3 was added to rhel we could play with python3x naming freely but not any more. We have two choises really, this suggestion of mine is based on the expectation that rhel7 continues to have more python3 packages in future with naming python3-. Let's list some history, please notify if I forgot something important. python3 packages were introduced to epel with python3x naming originally, and unlike fedora naming, python3 was replaced on every package with %python3_pkgversion and related macros. When python 3.6 was introduced to epel7 there was new macro %python3_other_pkgversion and related to that macros added. When python 3.4 got EOL, macros were switched and python36 naming was set for %python3_pkgversion rhel7.7 introduced python3 with fedora style python3 naming and %python3_pkgversion set to 3. Now systems using new python-rpm-macros from rhel7.7 can't any more build any python3 package because all dependencies switch from python36- to python3- so package builds will fail inside mock. Because of koji still using old python*rpm-macros this is not yet visible on fedora build system but I tested and verified this with mock. Also these new macros cause all new python packages to be named python3-. There are two possibilities how to handle this: Introduce conflicting %python3_pkgversion (and other related macros) with 36 and 3.6 etc in them. Let's do that as a quick hotfix for now decide the rest later. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?
On 12. 08. 19 11:12, Mikolaj Izdebski wrote:
On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok wrote:
See for example:
https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
2019-08-11 07:50:11
- nothing provides python(abi) = 3.6 ...
This is provided in RHEL 7.7.
(Note that we've unretired the python36 package, so later it resolved
correctly.)
Koschei uses Koji repos. You can find out the exact repo URL at given
timestamp in the following way:
In [1]: import koji, datetime
In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
In [5]: event = ks.getLastEvent(before=ts)
In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
event=event['id'])
In [7]: pi.repo(repo['id'], 'epel7-build')
Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
And for RHEL packages?
x86_64 repos are used for dependency resolution. At that time python36
was not available in epel7-build:
Are RHEL packages available directly from epel7-build?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3 packages to be removed form EPEL 7 (provided by RHEL 7)
On 12. 08. 19 10:52, Miro Hrončok wrote: On 12. 08. 19 8:14, Tuomo Soini wrote: On Sun, 11 Aug 2019 22:26:45 +0200 Miro Hrončok wrote: %python3_other_pkgversion 34 I believe the easiest fix is to define that directly in epel-rpm-macros: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5 Correct. That fixes this issue but not the huge issue we have now. Thanks for the report! I agree. But we have much bigger problem with epel python naming. python3_other is now defined to 3 in rhel7.7. By what? Do you mean python3_pkgversion? W can override that as well. Because epel is supposed to add packages to rhel, we have now new definition which is our master. That means with 7.7 system and mock, there is no possibility to build python36 packages any more. Because rhel selected python3 naming when inroduced python3 that gives epel7 new baseline for naming standard for python3 packages which means we should now follow that on epel7 post rhel7.7. Before python3 was added to rhel we could play with python3x naming freely but not any more. We have two choises really, this suggestion of mine is based on the expectation that rhel7 continues to have more python3 packages in future with naming python3-. Let's list some history, please notify if I forgot something important. python3 packages were introduced to epel with python3x naming originally, and unlike fedora naming, python3 was replaced on every package with %python3_pkgversion and related macros. When python 3.6 was introduced to epel7 there was new macro %python3_other_pkgversion and related to that macros added. When python 3.4 got EOL, macros were switched and python36 naming was set for %python3_pkgversion rhel7.7 introduced python3 with fedora style python3 naming and %python3_pkgversion set to 3. Now systems using new python-rpm-macros from rhel7.7 can't any more build any python3 package because all dependencies switch from python36- to python3- so package builds will fail inside mock. Because of koji still using old python*rpm-macros this is not yet visible on fedora build system but I tested and verified this with mock. Also these new macros cause all new python packages to be named python3-. There are two possibilities how to handle this: Introduce conflicting %python3_pkgversion (and other related macros) with 36 and 3.6 etc in them. Let's do that as a quick hotfix for now decide the rest later. Updated https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/5 Please some EPEL people, review and possibly build soon. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Is Koschei using CentOS 7 in the EPEL 7 resolve check?
On 12. 08. 19 11:16, Mikolaj Izdebski wrote:
On Mon, Aug 12, 2019 at 11:14 AM Miro Hrončok wrote:
On 12. 08. 19 11:12, Mikolaj Izdebski wrote:
On Sun, Aug 11, 2019 at 10:44 AM Miro Hrončok wrote:
See for example:
https://apps.fedoraproject.org/koschei/package/python-mccabe?collection=epel7
2019-08-11 07:50:11
- nothing provides python(abi) = 3.6 ...
This is provided in RHEL 7.7.
(Note that we've unretired the python36 package, so later it resolved
correctly.)
Koschei uses Koji repos. You can find out the exact repo URL at given
timestamp in the following way:
In [1]: import koji, datetime
In [2]: ks = koji.ClientSession('https://koji.fedoraproject.org/kojihub')
In [3]: pi = koji.PathInfo('https://kojipkgs.fedoraproject.org')
In [4]: ts = datetime.datetime(2019,8,11,8,8,10).timestamp()
In [5]: event = ks.getLastEvent(before=ts)
In [6]: repo = ks.getRepo(tag='epel7-build', state=koji.REPO_READY,
event=event['id'])
In [7]: pi.repo(repo['id'], 'epel7-build')
Out[7]: 'https://kojipkgs.fedoraproject.org/repos/epel7-build/1234463'
And for RHEL packages?
Selected RHEL packages are available in EPEL buildroots.
Oh. Do you know any pointers about how do I add more?
x86_64 repos are used for dependency resolution. At that time python36
was not available in epel7-build:
Are RHEL packages available directly from epel7-build?
Yes, they are. Eg python-0:2.7.5-80.el7_6.x86_64 from my example is a
RHEL build.
I see. Thanks.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le
On 09. 08. 19 11:13, Antonio Trande wrote: Hi all. 'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on EPEL7 ppc64le only? https://koji.fedoraproject.org/koji/getfile?taskID=36879492&volume=DEFAULT&name=root.log&offset=-4000 Funny thing: ppc64le gets: Problem: conflicting requests - nothing provides python-rpm-macros > 3-30 needed by python-devel-2.7.5-86.el7.ppc64le - nothing provides python2-rpm-macros > 3-30 needed by python-devel-2.7.5-86.el7.ppc64le x86_64 gets python-devel-2.7.5-80.el7.x86_64 It seems that the ppc64le build has the arched package from RHEL 7.7 but misses the noarch packages from RHEL 7.7 and the x86_64 builder just has pacages from RHEL 7.6 altogether. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Missing python-rpm-macros>3.30 on EPEL7 ppc64le
On 12. 08. 19 13:20, Miro Hrončok wrote: On 09. 08. 19 11:13, Antonio Trande wrote: Hi all. 'python-devel-2.7.5-86.el7' requires 'python(2)-rpm-macros > 3-30' on EPEL7 ppc64le only? https://koji.fedoraproject.org/koji/getfile?taskID=36879492&volume=DEFAULT&name=root.log&offset=-4000 Funny thing: ppc64le gets: Problem: conflicting requests - nothing provides python-rpm-macros > 3-30 needed by python-devel-2.7.5-86.el7.ppc64le - nothing provides python2-rpm-macros > 3-30 needed by python-devel-2.7.5-86.el7.ppc64le x86_64 gets python-devel-2.7.5-80.el7.x86_64 It seems that the ppc64le build has the arched package from RHEL 7.7 but misses the noarch packages from RHEL 7.7 and the x86_64 builder just has pacages from RHEL 7.6 altogether. https://pagure.io/fedora-infrastructure/issue/8084 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem
On 13. 08. 19 20:08, Kevin Fenzi wrote: On 8/11/19 1:45 AM, Miro Hrončok wrote: On 11. 08. 19 9:59, Mohan Boddu wrote: I unretired the packages and tagged the old builds, I think that should fix the buildroot and got a testing build working. Thanks, now. Assuming Koji sees RHEL 7.7, can we somehow: - keep the packages in the repos - but make Koji prefer the RHEL ones (they have higher EVR)? Are they using the same source package name? If so, the epel one will always be used. If not, they should both be available. Some, most importantly python-rpm-macros, use the same source package name and were retired in EPEL, however that broke centos. So they got unretired, but that broke Koji. We could possibly package "python-rpm-macros-temporary" but this has already drained a lot of my energy, so somebody else needs to do that, sorry. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3.6: RHEL 7.7 vs. CentOS 7.6 EPEL7 retirement problem
On 18. 09. 19 0:55, Kevin Fenzi wrote: Now that CentOS 7.7 is out shall we retire things again? I guess we do. But I dare to touch it. It works now. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Attention: Removal of python36 from EPEL-7 on 2019-10-03
On 01. 10. 19 19:30, Stephen John Smoogen wrote: With the release of RHEL-7.7, many of the packages for python36 in EPEL were replicated in the release as python3-3.6 packages. The normal pattern when this is seen is to remove the packages from EPEL so that they do not cause problems. However, this did cause problems for users of CentOS-7 who did not have access to the newer packages. Two weeks ago, CentOS-7.7.1908 was released and should have flowed out to users as needed. So it is time to remove the following src.rpm packages from EPEL: python36-3.6.8-1.el7.src.rpm python3-setuptools-39.2.0-3.el7.src.rpm There is also: python-pip python-rpm-macros -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Attention: Removal of python36 from EPEL-7 on 2019-10-03
On 01. 10. 19 21:14, Stephen John Smoogen wrote: On Tue, 1 Oct 2019 at 15:00, Miro Hrončok wrote: On 01. 10. 19 19:30, Stephen John Smoogen wrote: With the release of RHEL-7.7, many of the packages for python36 in EPEL were replicated in the release as python3-3.6 packages. The normal pattern when this is seen is to remove the packages from EPEL so that they do not cause problems. However, this did cause problems for users of CentOS-7 who did not have access to the newer packages. Two weeks ago, CentOS-7.7.1908 was released and should have flowed out to users as needed. So it is time to remove the following src.rpm packages from EPEL: python36-3.6.8-1.el7.src.rpm python3-setuptools-39.2.0-3.el7.src.rpm There is also: python-pip python-rpm-macros Were those removals or changes to make them python2 only? Removals. See the last 2-3 commits: https://src.fedoraproject.org/rpms/python-pip/commits/epel7 https://src.fedoraproject.org/rpms/python-rpm-macros/commits/epel7 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL 7 is broken for python3 related builds
On 09. 10. 19 0:27, Stephen John Smoogen wrote: On Tue, 8 Oct 2019 at 15:49, Irina Boverman wrote: Ok, how will I know what test results are? On Tue, Oct 8, 2019 at 2:56 PM Kevin Fenzi wrote: On Tue, Oct 08, 2019 at 07:54:37PM +0200, Miro Hrončok wrote: On 08. 10. 19 18:48, Irina Boverman wrote: My build (qpid-proton package) cannot find pythin36-devel package, I also tried python3-devel (also not found). It appears python36 was removed from EPEL 7 recently. Yes it was, as it was added to RHEL 7.7. The error is: https://koji.fedoraproject.org/koji/taskinfo?taskID=38143406 No matching package to install: 'python36-devel' It only happens on aarch64. I have no idea what's wrong. EPEL people, could you please help? With 7.7 RHEL dropped support for aarch64, so while all the other arches have moved on, aarch64 is stuck at 7.6. We are trying to see if we can keep support for it in epel by using the CentOS 7.7 aarch64 repo. We have just finished syncing those bits over and now we have to try and test it. So, options: 1) wait and let us test and see what the outcome is. 2) ExcludeArch: aarch64 for now and then pay attention to how the testing comes out, if it works, drop your ExcludeArch. kevin The test results were that we can keep running aarch64 in EPEL-7. Koji assumes that same name packages are the same in every repository and will fail if they aren't. Trying to do any build failed with the CentOS-7 packages because the filesystem (and every other noarch RPM) had different hashes. [I am pretty sure Dennis Gilmore will be saying 'yes and I told you this would happen when you wanted to do this 5 years ago'] At this point we will be disabling aarch64 from EPEL-7 and freezing those repositories. So should the python36 package had stayed in the frozen repo? Are we going to unretire it once again? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python3-rpm-macros
On 09. 10. 19 3:32, Orion Poplawski wrote: I retired this: https://bodhi.fedoraproject.org/overrides/python-rpm-macros-3-31.el7 To allow epel 7 builds get the RHEL7.7 3-32.el7 version. Thanks. I thought that when retiring the package, the override gets automatically expired. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: lua5.1-lpeg for EPEL8
On 22. 10. 19 15:51, Stephen John Smoogen wrote: I only see RHEL shipping 1 version of lua and that is 5.3. I don't see any lua51 packaged up anywhere so wouldn't that also need to be done? There is already a compat-lua in EPEL8 Thanks.. I was looking for the wrong name scheme. My apologies. Arguably, you were looking for the correct name scheme. compat-lua is the wrong one. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Please don't add Python 2 packages to EPEL 8 unless absolutely necessary
Hello EPEL packagers. More and more of you are asking for Python packages to be added into EPEL 8. I see that in some cases, the Python 2 subpackage is added as well, because it is possible. While there is absolutely no policy whatsoever that would forbid this in EPEL 8, I personally beg you not to do that, unless it is absolutely necessary. Python 2 upstream support ends in 2 months (minus 8 days). Python 2 support in RHEL 8 ends in 2024 (IIRC). RHEL/EPEL 8 support ends in 100 years (give or take). By adding Python 2 packages, you are creating a technical debt that will need to be resolved in couple years. Avoid this problem early. Don't add them. Pretty please. Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Missing Python 3 bindings for C libraries in EL7
On 12. 11. 19 7:52, Mike DePaulo wrote:
Hi everyone,
Background:
The Pulp 3 upstream project is written in Python 3.
Our installer normally uses PyPI for pure python packages, and OS
packages for C libraries & their python bindings.
Problem:
With RHEL7/CentOS7, we often run into the following thorny situation:
- Package libjuicy, written in C, exists in EL7 (main, optional, or extras).
- Subpackage python2-libjuicy with python2 bindings exists in EL7.
- Subpackage python3-libjuicy does not exist at all for EL7.
Note: libjuicy is a made up name :)
If you post the actual libraries, I would bring that up with my team (Python
Maint @ Red Hat).
I am not sure how to provide the python3 bindings .
Solutions I've thought of:
1. I see that for pure python packages ("chardet" being an example I
stumbled upon), there's often a python2 package in EL7, but a python3
package in EPEL7. Often at different versions. And I found guidelines
for this. [1]
However, I am worried about robustness (& feasibility) of a
python3-libjuicy bindings-only source package in EPEL7 for an EL7
libjuicy. What if there's a libjuicy update and it breaks the bindings
until we (Pulp / Fedora contributors) update them? And would it be
permissible in EPEL 7?
You would need to be ready to update the package every time it updates in EL.
That is usually not very often.
It would be permissible. See for example:
https://src.fedoraproject.org/rpms/python3-rpm
3. We can request that RHEL7 provides an updated libjuicy with the
python3-libjuicy subpackage.
However, even if they say yes, it would take too long for upstream
release schedule.
Also note that RHEL 7 is slowly getting to a phase where feature request might
end up being denied. Here is a potentially successful one, but it already took
half a year:
https://bugzilla.redhat.com/show_bug.cgi?id=1719978
Suggestions?
BTW, thank you for all the hard work on EPEL7 Python 3 support. I've
been following the RHEL 7.7 situation.
Thanks for the kind words!
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Any plans for supporting multiple python3 versions in EPEL8?
On 16. 11. 19 3:53, Orion Poplawski wrote: I'm wondering if anyone can shed any light on possible roadmaps for transitioning to newer python 3.X in RHEL8/EPEL8. What we have now appears to be: A module for different pythonXY versions: python27 2.7 [d] common [d] Python programming language, version 2.7 python36 3.6 [d][e] common [d], build Python programming language, version 3.6 A python3Y base package: python36.x86_64 3.6.8-2.module+el8.1.0+3334+5cb623d7 python36-debug.x86_64 3.6.8-2.module+el8.1.0+3334+5cb623d7 python36-devel.x86_64 3.6.8-2.module+el8.1.0+3334+5cb623d7 python36-rpm-macros.noarch 3.6.8-2.module+el8.1.0+3334+5cb623d7 But python3- modules, including: python3-libs.x86_64 3.6.8-15.1.el8 python3-tkinter.x86_64 3.6.8-15.1.el8 And since: # rpm -E %python3_pkgversion 3 It seems any transition is going to have to be a hard break and/or we're going to need modules. Is there any hope for parallel installable python3Y stacks in RHEL8? Are we just going to have python36 forever? The EL8 Python modules are planned to be parallel installable. That's why the module name is python36, not python or python3. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Menulibre for EPEL8
On 18. 11. 19 15:45, Troy Dawson wrote: Not sure why, but this was assigned to "Orphaned Owner". In Fedora it was recently updated this last June, and has been rebuilt for F32. Anyway, just letting people know, if they want to support this, it's theirs for the taking. It was orphaned at 2019-10-11, previously owned by marcusk. https://github.com/fedora-python/portingdb/commit/49801635620#diff-78d915ed17d7ee4bcd431ee2eba5a820L46593 https://github.com/fedora-python/portingdb/commit/49801635620#diff-e70e68b96459d67385323df7d75bcb49R82 I see no releng ticket about his, so assume it was done by the owner. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: "python3" vs "python%{python3_pkgversion}"
On 02. 12. 19 23:09, Ken Dreyer wrote:
On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa wrote:
On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer wrote:
Hi folks,
In EPEL 7 we have some packages with "python34" and "python36"
prefixes in their names. I guess this is a consequence of using the
%{python3_pkgversion} macro over time.
Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
EPEL 7, I'm wondering about this.
If I'm introducing a Python 3 subpackage in a new build today, should
I name this sub-package "python3-foo" or
"python%{python3_pkgversion}-foo" ?
The subpackage should be "python%{python3_pkgversion}-foo" and you
should also make sure you have "%{?python_provide:%python_provide
python%{python3_pkgversion}-foo}" in the subpackage declaration too.
This is confusing to me, and it diverges from what Fedora does. Can we
just reduce this down to "python3-" now that RHEL 7 has python3, and
we'll probably never put another Python version into EPEL 7?
We **can** but we **haven't yet**. IMHO doing it in random packages is wrong.
Currently, python36-foo is form EPEL (and if done right, provides python3-foo).
OTOH python3-bar is from RHEL (and if done right, provides python36-bar).
They both provide both names, but from first glance, the origin of the package
is obvious. I kinda like that.
If we decide to redo this, it will be a lot of boring work for no clear benefit.
If we decide to only allow it for new packages, it would be a mess.
That said, technically:
- it works either way
- there is no real EPEL packaging guideline forcing one way or the other
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: "python3" vs "python%{python3_pkgversion}"
On 03. 12. 19 0:54, Kevin Fenzi wrote:
On Tue, Dec 03, 2019 at 12:38:01AM +0100, Miro Hrončok wrote:
On 02. 12. 19 23:09, Ken Dreyer wrote:
On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa wrote:
On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer wrote:
Hi folks,
In EPEL 7 we have some packages with "python34" and "python36"
prefixes in their names. I guess this is a consequence of using the
%{python3_pkgversion} macro over time.
Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
EPEL 7, I'm wondering about this.
If I'm introducing a Python 3 subpackage in a new build today, should
I name this sub-package "python3-foo" or
"python%{python3_pkgversion}-foo" ?
The subpackage should be "python%{python3_pkgversion}-foo" and you
should also make sure you have "%{?python_provide:%python_provide
python%{python3_pkgversion}-foo}" in the subpackage declaration too.
This is confusing to me, and it diverges from what Fedora does. Can we
just reduce this down to "python3-" now that RHEL 7 has python3, and
we'll probably never put another Python version into EPEL 7?
We **can** but we **haven't yet**. IMHO doing it in random packages is wrong.
Currently, python36-foo is form EPEL (and if done right, provides python3-foo).
OTOH python3-bar is from RHEL (and if done right, provides python36-bar).
They both provide both names, but from first glance, the origin of the
package is obvious. I kinda like that.
If we decide to redo this, it will be a lot of boring work for no clear benefit.
If we decide to only allow it for new packages, it would be a mess.
That said, technically:
- it works either way
- there is no real EPEL packaging guideline forcing one way or the other
I think we should encourage people to just use python3-foo now, but I
agree it would be a lot of work to try and convert everything to do
that.
The orig reason was so we could move python stacks forward since we were
maintaining them in epel. Since python 3.6 is in rhel and rhel7 is past
the point where I would expect many changes, I think 3.6 is here to
stay, so we dont really need it anymore. It's just extra noise that
makes spec files less readable now.
If we want to get rid of it, we might just:
Fix the cases where srpm is called python3-foo and subpackage python36-foo.
Switch the %{python3_pkgversion} to 3 (= remove the redefinition from EPEL).
Rebuild everything. Profit.
The problem of course, is bootstrapping.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Python 3.7 in EPEL?
Hey EPEL people. We got a request to branch Python 3.7 foe EPEL 7: https://bugzilla.redhat.com/show_bug.cgi?id=1781940 Are there volunteers to make that effort? And if so, should this be done in EPEL 8 first? And what about Python 3.8 in EPEL 7? So many questions. So little time. That said. If somebody want this, we (Python Maint) can help coordinate, but we don't have the manpower to really maintain various Python versions in EPEL for next X years. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python 3.7 in EPEL?
On 11. 12. 19 17:01, Stephen John Smoogen wrote: On Tue, 10 Dec 2019 at 20:24, Miro Hrončok wrote: Hey EPEL people. We got a request to branch Python 3.7 foe EPEL 7: https://bugzilla.redhat.com/show_bug.cgi?id=1781940 Are there volunteers to make that effort? And if so, should this be done in EPEL 8 first? And what about Python 3.8 in EPEL 7? So many questions. So little time. That said. If somebody want this, we (Python Maint) can help coordinate, but we don't have the manpower to really maintain various Python versions in EPEL for next X years. Honestly after all the work and pain it got to get python36 in EPEL7... I would prefer not to try that again. Note that there is a big difference between maintaining a stack of various python37-foo packages and maintaining the interpreter only. I think maintaining the version that is the base in RHEL-8 is going to be more than enough headaches and trying to keep up with the python of the year is not productive. I think that any volunteers should first make the versions of python37/38 in COPR and see if they have the volunteers and time to maintain it there. That is true. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Python macro backports for EPEL reviews needed
Hey EPEL experts. Could you please have a look at: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/13 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14 https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/40 Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: How to support python 3.8 from RHEL 8.2 in EPEL?
On 30. 01. 20 16:32, Orion Poplawski wrote: Folks - Looks like RHEL 8.2 will have python 3.8 in addition to python 3.6. From the 8.2 beta: Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs) Name Stream Profiles Summary python27 2.7 [d][e] common [d] Python programming language, version 2.7 python36 3.6 [d][e] build, common [d] Python programming language, version 3.6 python38 3.8 [d][e] build, common [d] Python programming language, version 3.8 Currently, %python_pkgversion is set to 3 in /usr/lib/rpm/macros.d/macros.python-srpm from python-srpm-macros. python3-devel is still provided only by python36-devel, so presumably all EPEL8 python packages will continue to be built against python 3.6. But I imagine that people will soon be asking for python 3.8 versions of EPEL packages. How can we provide those? Does this have to be done in some modular fashion - which seems to come back to the discussion of whether or not every package has to become its own module or whether to group them together somehow. Or since both python modules are "default" modules and we can install both python36-devel and python38-devel at the same time, perhaps we can define the python3_other* macros again for python38 and just go that way? Thoughts? The idea is that the versions fo stuff we build in RHEL for different python versions is different and I'd like to keep that idea in EPEL as well. Building a python38-foo package from it's own spec should work as follows: BR python38-rpm-macros BR python38-devel BR python38-bar etc... Regular specfile follows. You can even have a single specfile that build for different Python version based on local override of %python_pkgversion in the buildroot. Building both versions from single spec file---single build would require a new set of macros, yes (or hardcoding stuff). However I'd not call them python3_other* unless you want to end up with python3_other_other* the next time this happens. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: How to support python 3.8 from RHEL 8.2 in EPEL?
On 30. 01. 20 16:44, Pat Riehecky wrote: While I lack good answers, perhaps another question. What a the thoughts on using python `.pth` files for python modules that work in multiple interpreters? In theory this would permit bit for bit identical libraries in multiple interpreters at once? Where would you put the files on the filesystem level? How would we handle different bytecode caches and extension modules? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: How to support python 3.8 from RHEL 8.2 in EPEL?
On 30. 01. 20 16:52, Pat Riehecky wrote: On 1/30/20 9:47 AM, Miro Hrončok wrote: On 30. 01. 20 16:44, Pat Riehecky wrote: While I lack good answers, perhaps another question. What a the thoughts on using python `.pth` files for python modules that work in multiple interpreters? In theory this would permit bit for bit identical libraries in multiple interpreters at once? Where would you put the files on the filesystem level? How would we handle different bytecode caches and extension modules? Perhaps something like /usr/lib/python-epel? I thought python 3.6+ used the __pycache__ directory that was able to distinguish between the various python bytecodes. Yes, but do we always ship all possible versions? I believe extension modules must be compiled for a specific interpreter... I could be wrong there... I don't recall ever building one myself. That is the case, exactly. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Can we enable some "-devel" modules from CBR in the EPEL8 buildroot?
Hello EPEL. It seems that we have a python38-devel module in the RHEL 8.2 Beta Code Ready Builder repository. It has only one stream but it is not a default stream due to some technical limitations. Can we please enable such stream in the EPEL8 buildroot trough some Ursa Major/Prime/... thing? Is that technically possible on EPEL side? Is that possible by policy? Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Can we enable some "-devel" modules from CBR in the EPEL8 buildroot?
On 15. 02. 20 0:01, Kevin Fenzi wrote: Nope. We don't ever sync or use betas... once it's released it should be possible to use it however. To clarify (I forgot to say that) I meant to do it after the actual release, not during beta. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: What is the proper way to handle python3 python36 in RHEL7
%{python3} = python3
%{python3} = /usr/bin/python3
At least in Fedora. In EPEL, most likely as well.
See https://bugzilla.redhat.com/show_bug.cgi?id=1812665
There's a bug in the macros.
But that bug has nothing to do with either %python3 or %python3_pkgversion.
Requires: %{python3}
Requires: %{python3}-dbus
What does this supposed to evaluate to?
Anyway, the inconsistency problem is:
python36-dbus on EPEL 7 does not provide python3-dbus (can be fixed by adding
%python_provide %{name} to the EPEL package)
python3-dbus in RHEL 8 does not provide python36-dbus (can be fixed by changing
RHEL's %python_provide and rebuilding the RHEL package, not sure if that will go
trough)
I am looking into python3_pkgversion macro but that doesn't seem to be correct
either.
This should work on both EPEL 7 and EPEL 8:
Requires: python%{python3_pkgversion}-dbus
Doesn't it?
$ mock -r epel-7-x86_64 shell
sh-4.2# rpm --eval '%python3_pkgversion'
36
$ mock -r epel-8-x86_64 shell
sh-4.4# rpm --eval '%python3_pkgversion'
3
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: What is the proper way to handle python3 python36 in RHEL7
On 31. 03. 20 23:40, Erinn Looney-Triggs wrote: Interestingly... no it did not and the reason is I built against rhel-7-x86_64 in mock not epel-7-x86_64. I believe there is a macro override for epel-7-x86_64 hence why I was getting a dependency against python3-dbus. Correct. Ok so this would be a bug to file against the package then. Thanks. I'm just gonna do it rigth away. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: What is the proper way to handle python3 python36 in RHEL7
On 01. 04. 20 0:06, Miro Hrončok wrote: On 31. 03. 20 23:40, Erinn Looney-Triggs wrote: Interestingly... no it did not and the reason is I built against rhel-7-x86_64 in mock not epel-7-x86_64. I believe there is a macro override for epel-7-x86_64 hence why I was getting a dependency against python3-dbus. Correct. Ok so this would be a bug to file against the package then. Thanks. I'm just gonna do it rigth away. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0745794f21 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fwd: Modularity Survey
If you have questions or comments about the survey to discuss on the mailing list, use this thread: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/NAACOHBWTKAZN3IOQKWDNTEHS2BQ6OVJ/ -- Forwarded message - From: Daniel Mach Date: Fri, Apr 3, 2020 at 9:54 AM Subject: Modularity Survey To: Development discussions related to Fedora Hello everyone, On behalf of Red Hat's Modularity team, I'd like to ask you to fill out a survey on Modularity: https://docs.google.com/forms/d/e/1FAIpQLScOA97rGONieSOYmlZLsHdkq-EhdePZ4IN3RwOjJKd1F1a9sw/viewform?usp=sf_link Our goal is to use your feedback to improve Modularity, its documentation and hopefully fix any issues you may have. Modularity Survey - The purpose of this survey is to get feedback on Modularity. It is divided into 4 sections: * Information about yourself (optional) * Modularity & you * Problems with Modularity you may have experienced * Glossary review - what do you think the terms mean Privacy / GDPR: * The raw data incl. any personal information you provide will be shared only with Red Hat's Modularity team (approx. 10 people) to evaluate the survey * The raw data will not be provided to anyone else at Red Hat or any 3rd parties * Aggregated (anonymous) results of the survey will be published Thank you for your cooperation. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python-configobj - need Python 3 version for EPEL7 but RHEL ships python-configobj
On 10. 04. 20 12:05, Felix Schwarz wrote: What is the best way to get a Python 3 version for EPEL 7? Do a new package review request for an epel7 only package called python3-configobj that looks like: https://src.fedoraproject.org/rpms/python3-six/blob/epel7/f/python3-six.spec When approved, unorphan this and create an epel7 branch: https://src.fedoraproject.org/rpms/python3-configobj (Make sure to use a releng ticket that explains that you want to own it, but not to unretire it on master.) > Maybe the Fedora maintainers of python-configobj change the spec file so on > EPEL 7 we only generate a Python 3 version? This is not going to work, as the python-configobj component cannot be included in epel7. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: python-configobj - need Python 3 version for EPEL7 but RHEL ships python-configobj
On 10. 04. 20 14:58, Felix Schwarz wrote: I guess I'll start with the other packages to ensure I don't miss any blockers. May I add you to the cc of the review request to ensure this will be handled correctly? Sure. Also, at this point, feel free not to package the python3_other subpackage. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On 02. 01. 20 15:36, Miro Hrončok wrote: Hey EPEL experts. Could you please have a look at: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/13 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14 Thanks. Is EPEL interested in Fedora compatibility? Or shall I stop caring and close them? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On 14. 04. 20 13:26, Stephen John Smoogen wrote: Miro. EPEL is interested in Fedora compatibility but has 0 people staffed to it. I got slammed by the datacentre move and dropped the ball on this. Troy took over for me last month and has been trying to catch up on all the things we have outstanding. Thank you for reminding us of this outstanding work. I appreciate that you care. My interest in EPEL is purely "best effort" as I am not an EPEL user myself -- I try to not break use cases for people who like to maintain packages in Fedora and EPEL alike, but sometimes it's really hard to guess what would work for EPEL best when there is no response. I would very much like to have some "EPEL <-> Python" representative/partner I could bring this sort of stuff to. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On 14. 04. 20 15:56, Troy Dawson wrote:
Hi Miro,
I've taken a look, but haven't done any testing.
Thanks.
EPEL6 patch - no. Even if it works, I'd say no. We're at the last 7
months before EOL and I don't want the EPEL6 stuff to have changes
like this. I could be outvoted by this, but I believe most of the
other EPEL packagers would feel this way.
Makes perfect sense.
EPEL7 patch - This would require some testing. When we tried to turn
on the python automatic-dependency checking, there were things that
broke on EPEL7 so they never got implemented. What, or how they
broke, I don't currently know. I just know that they did, and there
wasn't a big enough demand to debug. As in zero demand. Nobody asked
for it in EPEL7, only EPEL8. So I'm not even sure this would be worth
the testing. Has anyone asked for this?
Not yet. But If we want packagers to start using %pycached, I know there are
some of them who would blindly merge their master branch to epel7 and they
expect it will work. I suggest that we backport %pycached only, the name is
unlikely to clash with anything. %python can be separated and not backported.
Sounds good?
EPEL8 patch - We've had requests to have EPEL8 be as close to Fedora,
so I'm in favor of this.
I'm pretty sure the %pycached shouldn't be a problem.
I agree.
What is %python supposed to resolve to? To me it looks like
/usr/bin/python ... which there isn't any in RHEL8. And, I thought
Fedora got rid of it also, in favor of specifically doing python2 or
python3. Or did that change?
So the main idea was that based on some FPC and RPMdevs discussions about
underscor-prefixed macros, packagers should not be using those directly, however
our guidelines were full of referecens to %{__python3}. We have come up with a
conclusion:
Macros with underscores, such as %__python3 are intended to be reset to change
bahvior of other macros (e.g. when you set %__python to /usr/bin/pythhon3.4 on
EPEL 7, %{python3_version{ will be 3.4), macros without underscores are to be
used in specs (e.g. you do `%{python3} -m pytest` rather than `%{__python3} -m
pytest`.
Details:
https://pagure.io/packaging-committee/issue/907
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comment-30941
The only problem was the %{python} macro. When you redefine %__python to a sane
(explicit) value, you want %{python} to work, because e.g. %{python_version}
works. But we didn't want to encourage usage of "unversioned python" by adding
%{python}.
So Fedora now has a %{python} macro: If %__python is /usr/bin/python (backwards
compatible default), %{python} gives you an error. If %__python is anything
else, %{python} gives that to you.
Fedora 32:
$ rpm --define '__python /usr/bin/python3.6' --eval '%python_version'
3.6
$ rpm --define '__python /usr/bin/python3.6' --eval '%python'
/usr/bin/python3.6
$ rpm --eval '%python_version'
3.8
$ rpm --eval '%python'
error: Cannot use %python if %__python wasn't redefined to something other than
/usr/bin/python.
EPEL 8:
$ rpm --define '__python /usr/bin/python3.6' --eval '%python_version'
3.6
$ rpm --define '__python /usr/bin/python3.6' --eval '%python'
%python
$ rpm --eval '%python_version'
error: attempt to use unversioned python, define %__python to /usr/bin/python2
or /usr/bin/python3 explicitly
$ rpm --eval '%python'
%python
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On 14. 04. 20 17:40, Troy Dawson wrote:
On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok wrote:
On 14. 04. 20 15:56, Troy Dawson wrote:
Hi Miro,
I've taken a look, but haven't done any testing.
Thanks.
EPEL6 patch - no. Even if it works, I'd say no. We're at the last 7
months before EOL and I don't want the EPEL6 stuff to have changes
like this. I could be outvoted by this, but I believe most of the
other EPEL packagers would feel this way.
Makes perfect sense.
EPEL7 patch - This would require some testing. When we tried to turn
on the python automatic-dependency checking, there were things that
broke on EPEL7 so they never got implemented. What, or how they
broke, I don't currently know. I just know that they did, and there
wasn't a big enough demand to debug. As in zero demand. Nobody asked
for it in EPEL7, only EPEL8. So I'm not even sure this would be worth
the testing. Has anyone asked for this?
Not yet. But If we want packagers to start using %pycached, I know there are
some of them who would blindly merge their master branch to epel7 and they
expect it will work. I suggest that we backport %pycached only, the name is
unlikely to clash with anything. %python can be separated and not backported.
Sounds good?
Yep, sounds good to me.
Amended https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14
EPEL8 patch - We've had requests to have EPEL8 be as close to Fedora,
so I'm in favor of this.
I'm pretty sure the %pycached shouldn't be a problem.
I agree.
What is %python supposed to resolve to? To me it looks like
/usr/bin/python ... which there isn't any in RHEL8. And, I thought
Fedora got rid of it also, in favor of specifically doing python2 or
python3. Or did that change?
So the main idea was that based on some FPC and RPMdevs discussions about
underscor-prefixed macros, packagers should not be using those directly, however
our guidelines were full of referecens to %{__python3}. We have come up with a
conclusion:
Macros with underscores, such as %__python3 are intended to be reset to change
bahvior of other macros (e.g. when you set %__python to /usr/bin/pythhon3.4 on
EPEL 7, %{python3_version{ will be 3.4), macros without underscores are to be
used in specs (e.g. you do `%{python3} -m pytest` rather than `%{__python3} -m
pytest`.
Details:
https://pagure.io/packaging-committee/issue/907
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comment-30941
The only problem was the %{python} macro. When you redefine %__python to a sane
(explicit) value, you want %{python} to work, because e.g. %{python_version}
works. But we didn't want to encourage usage of "unversioned python" by adding
%{python}.
So Fedora now has a %{python} macro: If %__python is /usr/bin/python (backwards
compatible default), %{python} gives you an error. If %__python is anything
else, %{python} gives that to you.
Ahh ... now that you explain it, I was reading it totally backwards.
I'd still like to test it on a variety of packages, but unless others
have some type of objection, as long as it passes the tests, I'm good
with it.
What kind of packages would need the test? This is mostly backwards compatible.
The only packages that could be problematic are packages that use a constructs
like this:
%{!?python:...} or %if %{defined python}
-> previously %python was not defined, now it is and hence the conditional will
have a different result
Or like this:
%global pyver_sitelib %python%{pyver}_sitelib
-> previously %python was not defined, now it is and hence the code produces
invalid result
I suppose such cases could be figured out with a grep. Is there something like
https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz but for epel branches?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On 14. 04. 20 18:46, Troy Dawson wrote: Yep, I'm having a hard time finding anything relevant to test. I have verified it doesn't conflict with any other rpm macro, but I'm pretty sure you had already checked that. So, I'm giving it a thumbs up. And I'll give it a thumbs up on the pull requests as well. EPEL 7 update and buildroot override: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3c0bec7842 https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-7-24 EPEL 8 update and buildroot override: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d2bb92fb39 https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-10 I've disabled both time based and karma based push. We can observe the EPEL builds and decide whether to push this or not in ~1 month. In case something is needed for EPEL 8 Playground, please do so, I have no idea really, sorry about that. Thanks, Troy. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Cannot retire epel7 package
On 20. 04. 20 6:09, Orion Poplawski wrote: zabbix22 (epel7)]$ fedpkg retire 'Zabbix 2.2 is no longer maintained upstream' Fedora release (epel7) is in state 'current' - retire operation is not allowed. Sounds like fedpkg bug. See https://pagure.io/fedpkg/issue/337 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Cannot retire epel7 package
On 20. 04. 20 12:13, Miro Hrončok wrote: On 20. 04. 20 6:09, Orion Poplawski wrote: zabbix22 (epel7)]$ fedpkg retire 'Zabbix 2.2 is no longer maintained upstream' Fedora release (epel7) is in state 'current' - retire operation is not allowed. Sounds like fedpkg bug. See https://pagure.io/fedpkg/issue/337 As a workaround, git rm everything, git add dead.package and commit/push manually. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Co-Maintainers wanted for python-lockfile EPEL branches
On 20. 04. 20 13:45, Fabio Valentini wrote:
and it seems I
can't even figure out how to determine which EPEL packages require
python*-lockfile.
Take the attached repo files.
They are good for repoquery, adapted from epel-release.
They don't have -testing repos, but -testingx, so you don't accidentally enable
them with dnf --enablerepo=\*-testing.
Usage:
$ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
pungi-legacy-0:4.1.38-1.el8.2.noarch
python2-pungi-0:4.1.38-1.el8.2.noarch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
[epel7]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel7-testingx]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel7&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel7-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel7-testingx-source]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel7&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel8]
name=Extra Packages for Enterprise Linux 8 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/8/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-8&arch=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
[epel8-testingx]
name=Extra Packages for Enterprise Linux 8 - Testing - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/testing/8/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel8&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
[epel8-source]
name=Extra Packages for Enterprise Linux 8 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/8/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-8&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1
[epel8-testingx-source]
name=Extra Packages for Enterprise Linux 8 - Testing - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/testing/8/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel8&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
gpgcheck=1
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Broken %python_provide macro for Koji's epel8-playground target?
On 30. 04. 20 3:58, Michel Alexandre Salim wrote: Is the epel8-playground builder somehow using an different version of python-rpm-macros? Happy to file a bug if I know where this should go. I have an active buildroot override for epel8 epel-rpm-macros: https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-10 There has been no sync to playground since. See https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/WRXXXFNG2E6TIKXR43RUS526KQNUK3V6/ Might this be relevant? python-rpm-macros come from RHEL, not EPEL, in 8. No idea what's wrong. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On 14. 04. 20 19:04, Miro Hrončok wrote: On 14. 04. 20 18:46, Troy Dawson wrote: Yep, I'm having a hard time finding anything relevant to test. I have verified it doesn't conflict with any other rpm macro, but I'm pretty sure you had already checked that. So, I'm giving it a thumbs up. And I'll give it a thumbs up on the pull requests as well. EPEL 7 update and buildroot override: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3c0bec7842 https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-7-24 EPEL 8 update and buildroot override: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d2bb92fb39 https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-10 I've disabled both time based and karma based push. We can observe the EPEL builds and decide whether to push this or not in ~1 month. My EPEL 8 update got overridden by a new one. I suggest I push the EPEL 7 one, there was no reported breakage. In case something is needed for EPEL 8 Playground, please do so, I have no idea really, sorry about that. Still no idea what is the story there. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Python macro backports for EPEL reviews needed
On 01. 05. 20 20:32, Troy Dawson wrote: I've never un-updated anything, and I'm not sure if it will make it possible for your packages to be pushed to stable. It wont. Just please make sure my commit eventually gets pushed in some update and that there is a buildroot override until that happens. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Playground policy
On 01. 05. 20 21:39, Kevin Fenzi wrote: I'd like to look at seeing if we can accomplish what we wanted with playground by having it just inherit from epel8. As a drive-by epel contributor, this would work so much better for me. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8
On 04. 05. 20 18:11, Troy Dawson wrote: I have not created any bugzila's for these yet. I have not checked to see if these are in -testing already. This is just a list showing what packages currently do not install from EPEL 7. airinv airrac airtsp drawtiming opentrep perl-Image-SubImageFind perl-X11-GUITest php-magickwand python-jenkins-job-builder ripright rmol sevmgr simcrs simfqt slack-cleaner spyder stdair trademgen travelccm This is a much smaller list than in the past. I appreciate everyone's efforts to keep EPEL7 an installable repo. I don't know how that list was assembled, but I know about at least about 1 more package (already has a bugzilla open): $ mock -r epel-7-x86_64 install python34-requests ... Resolving Dependencies --> Running transaction check ---> Package python34-requests.noarch 0:2.14.2-2.el7 will be installed --> Processing Dependency: python(abi) = 3.4 for package: python34-requests-2.14.2-2.el7.noarch --> Processing Dependency: python34-chardet for package: python34-requests-2.14.2-2.el7.noarch --> Processing Dependency: python34-idna for package: python34-requests-2.14.2-2.el7.noarch --> Processing Dependency: python34-urllib3 for package: python34-requests-2.14.2-2.el7.noarch --> Running transaction check ---> Package python34.x86_64 0:3.4.10-4.el7 will be installed --> Processing Dependency: python34-libs(x86-64) = 3.4.10-4.el7 for package: python34-3.4.10-4.el7.x86_64 --> Processing Dependency: libpython3.4m.so.1.0()(64bit) for package: python34-3.4.10-4.el7.x86_64 ---> Package python34-chardet.noarch 0:3.0.4-1.el7 will be installed ---> Package python34-idna.noarch 0:2.7-2.el7 will be installed ---> Package python34-urllib3.noarch 0:1.25.6-1.el7 will be installed --> Processing Dependency: python34-six >= 1.12.0 for package: python34-urllib3-1.25.6-1.el7.noarch --> Processing Dependency: python34-pysocks for package: python34-urllib3-1.25.6-1.el7.noarch --> Running transaction check ---> Package python34-libs.x86_64 0:3.4.10-4.el7 will be installed ---> Package python34-pysocks.noarch 0:1.6.8-6.el7 will be installed ---> Package python34-urllib3.noarch 0:1.25.6-1.el7 will be installed --> Processing Dependency: python34-six >= 1.12.0 for package: python34-urllib3-1.25.6-1.el7.noarch --> Finished Dependency Resolution Error: Package: python34-urllib3-1.25.6-1.el7.noarch (epel) Requires: python34-six >= 1.12.0 You could try using --skip-broken to work around the problem -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Clarification needed: Conflicts in compat packages
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Conflicts_in_compat_packages """Due to the EPEL policy of maintaining backwards compatibility, EPEL has a greater need for forward compat packages than Fedora. When creating, a compat package, note that it is okay to set a Conflicts between them as noted in the Conflicts Guidelines. At this time, this is only allowed for packages overriding packages in EPEL, not in RHEL Base.""" What does "RHEL Base" mean in this context? Is it everything listed in https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F ? What does "At this time" mean? Can an exception be requested for this? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Clarification needed: Conflicts in compat packages
On 05. 05. 20 17:48, Troy Dawson wrote: On Tue, May 5, 2020 at 8:07 AM Miro Hrončok wrote: https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Conflicts_in_compat_packages """Due to the EPEL policy of maintaining backwards compatibility, EPEL has a greater need for forward compat packages than Fedora. When creating, a compat package, note that it is okay to set a Conflicts between them as noted in the Conflicts Guidelines. At this time, this is only allowed for packages overriding packages in EPEL, not in RHEL Base.""" What does "RHEL Base" mean in this context? Is it everything listed in https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F ? Correct, what you are pointing to is considered the "RHEL Base". Thanks for clarifying. What does "At this time" mean? Can an exception be requested for this? I didn't write that, but I believe you are also correct. "At this time" is an escape clause in case something comes up in the future. There would have to be a good reason. It would need to be approved by the steering committee. It would need to be documented somewhere. Understood. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: What to do about python 3.4 in EPEL7?
.2.6-2.el7.src python-iso3166-0:1.0.1-1.el7.src python-lark-parser-0:0.7.1-1.el7.src python-leveldb-0:0.194-2.el7.src python-markdown-0:2.4.1-4.el7.src python-parso-0:0.3.1-2.el7.src python-pbr-0:4.2.0-3.el7.src python-pip-epel-0:8.1.2-12.el7.src python-process-tests-0:1.0.0-11.el7.src python-psutil-0:5.6.7-1.el7.src python-pycryptodomex-0:3.9.7-1.el7.src python-pygraphviz-0:1.3-2.rc2.el7.2.src python-pysocks-0:1.6.8-7.el7.src python-pyvirtualize-0:0.10-2.20191018gitdc2d971.el7.src python-pyvmomi-0:6.7.3-4.el7.src python-rfc3986-0:1.3.0-1.el7.src python-setuptools_scm-0:1.17.0-3.el7.src python-slacker-0:0.12.0-4.el7.src python-snowballstemmer-0:1.2.1-9.el7.src python-tabulate-0:0.8.3-8.el7.src python-whoosh-0:2.7.4-5.el7.src python3-Cython-0:0.28.5-1.el7.src python3-PyYAML-0:3.12-1.el7.src python3-backports-ssl_match_hostname-0:3.5.0.1-1.el7.src python3-chardet-0:3.0.4-1.el7.src python3-coverage-0:4.0.3-5.el7.src python3-cups-0:1.9.74-4.el7.src python3-dateutil-1:2.4.2-5.el7.src python3-docutils-0:0.14-1.el7.src python3-idna-0:2.7-2.el7.src python3-jinja2-0:2.11.1-1.el7.src python3-markupsafe-0:0.23-3.el7.src python3-mock-0:2.0.0-2.el7.src python3-nose-0:1.3.7-4.el7.src python3-numpy-0:1.12.1-3.el7.src python3-prettytable-0:0.7.2-19.el7.src python3-psycopg2-0:2.7.7-2.el7.src python3-py-0:1.4.32-2.el7.src python3-pycurl-0:7.43.0-7.el7.src python3-pygments-0:2.2.0-3.el7.src python3-pytest-0:2.9.2-4.el7.src python3-pytest-cov-0:2.5.1-3.el7.src python3-requests-0:2.14.2-2.el7.src python3-sphinx-0:1.2.3-6.el7.src python3-sqlalchemy-0:1.1.3-3.el7.src python3-urllib3-0:1.25.6-1.el7.src python3-virtualenv-0:15.1.0-5.el7.src python34-debug-0:3.4.10-4.el7.x86_64 python34-numpy-f2py-0:1.12.1-3.el7.x86_64 python34-setuptools-0:39.2.0-4.el7.src python34-virtualenv-0:15.1.0-5.el7.noarch root-0:6.20.04-1.el7.src slack-cleaner-0:0.5.0-2.el7.src uwsgi-0:2.0.17.1-2.el7.src xrootd-1:4.11.3-1.el7.src -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: What to do about python 3.4 in EPEL7?
On 07. 05. 20 5:07, Orion Poplawski wrote:
FWIW, leaves appear to be:
# repoquery --disablerepo=* --enablerepo=epel* --whatrequires python34 | while
read pkg; do [ -z "$(repoquery --disablerepo=* --enablerepo=epel*
--whatrequires $pkg --alldeps --recursive)" ] && echo $pkg; done
Not sure how this works, but my repoquery disagrees wrt src packages (does your
--enablerepo=epel* include epel-source?), see some examples inlined:
avogadro2-0:1.90.0-7.el7.x86_64
python34-Cython-0:0.28.5-1.el7.x86_64
$ repoquery --repo=epel7{,-source} --whatrequires python34-Cython
python3-numpy-0:1.12.1-3.el7.src
python34-HepMC3-rootIO-0:3.2.1-2.el7.x86_64
python34-HepMC3-search-0:3.2.1-2.el7.x86_64
python34-PyYAML-0:3.12-1.el7.x86_64
python34-apsw-0:3.7.17.r1-3.el7.x86_64
python34-argcomplete-0:1.7.0-4.el7.noarch
python34-asn1crypto-0:0.24.0-7.el7.noarch
python34-backports-ssl_match_hostname-0:3.5.0.1-1.el7.noarch
python34-blosc-0:1.2.8-5.el7.x86_64
python34-bottle-0:0.12.13-3.el7.noarch
python3-pycurl-0:7.43.0-7.el7.src
python34-bsddb3-0:6.2.6-4.el7.x86_64
python34-certifi-0:2018.10.15-5.el7.noarch
python34-click-0:6.7-8.el7.noarch
python34-cups-0:1.9.74-4.el7.x86_64
python34-d2to1-0:0.2.12-1.post1.el7.noarch
python34-debug-0:3.4.10-5.el7.x86_64
python34-empy-0:3.3.3-2.el7.noarch
python34-httmock-0:1.2.6-2.el7.noarch
python34-iso3166-0:1.0.1-1.el7.noarch
python34-jupyroot-0:6.20.04-1.el7.x86_64
python34-lark-parser-0:0.7.1-1.el7.noarch
python34-leveldb-0:0.194-2.el7.x86_64
python34-lhapdf-0:6.2.1-6.el7.x86_64
python34-markdown-0:2.4.1-4.el7.noarch
python34-mock-0:2.0.0-2.el7.noarch
python3-pytest-0:2.9.2-4.el7.src
python34-setuptools-0:39.2.0-4.el7.src
python34-numpy-f2py-0:1.12.1-3.el7.x86_64
python34-parso-0:0.3.1-2.el7.noarch
python34-pip-0:8.1.2-12.el7.noarch
python-setuptools_scm-0:1.17.0-3.el7.src
python34-setuptools-0:39.2.0-4.el7.src
python34-preludedb-0:5.1.0-2.el7.x86_64
python34-prettytable-0:0.7.2-19.el7.noarch
python34-process-tests-0:1.0.0-11.el7.noarch
python3-pytest-cov-0:2.5.1-3.el7.src
python34-psutil-0:5.6.7-1.el7.x86_64
python-blosc-0:1.2.8-5.el7.src
python34-psycopg2-tests-0:2.7.7-2.el7.x86_64
python34-py4j-0:0.10.7-4.el7.noarch
python34-pycryptodomex-0:3.9.7-1.el7.x86_64
python34-pycurl-0:7.43.0-7.el7.x86_64
python34-pygraphviz-0:1.3-2.rc2.el7.2.x86_64
python34-pyscard-0:1.9.7-1.el7.x86_64
python34-pytest-cov-0:2.5.1-3.el7.noarch
python34-pythia8-0:8.2.43-1.el7.x86_64
python34-pyvirtualize-0:0.10-2.20191018gitdc2d971.el7.noarch
python34-rfc3986-0:1.3.0-1.el7.noarch
python34-setuptools_scm-0:1.17.0-3.el7.noarch
python34-snowballstemmer-0:1.2.1-9.el7.noarch
python34-sqlalchemy-0:1.1.3-3.el7.x86_64
python3-sphinx-0:1.2.3-6.el7.src
python34-tabulate-0:0.8.3-8.el7.noarch
python34-uwsgidecorators-0:2.0.17.1-2.el7.x86_64
python34-uwsgidecorators-0:2.0.18-7.el7.x86_64
python34-virtualenv-0:15.1.0-5.el7.noarch
python3-pytest-cov-0:2.5.1-3.el7.src
python34-whoosh-0:2.7.4-5.el7.noarch
python3-sphinx-0:1.2.3-6.el7.src
python34-xrootd-1:4.11.3-1.el7.x86_64
slack-cleaner-0:0.5.0-2.el7.noarch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: What to do about python 3.4 in EPEL7?
On 07. 05. 20 11:46, Dominik 'Rathann' Mierzejewski wrote:
Question: should I be using %{python3_pkgversion} at all? Some packages
still use it, e.g. python3-ply (python36-ply binary package), and
some don't.
0) It is no longer required from technical point of view.
1) There was no announcement not to use it.
2) There was never a hard rule to use it.
3) I'd personally still use it, for consistency.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: What to do about python 3.4 in EPEL7?
On 07. 05. 20 19:57, Kevin Fenzi wrote: Would it be needed if we moved from say python 3.6 to python 3.8? If there is enough people going to work on this, python 3.8 can be introduced as %python3_other. But I guess python 3.6 is going to be maintained the entire life of rhel7? AFAIK that's how RHEL works. (For those who are not up to speed, RHEL 7 now contains Python 3.6.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
