[EPEL-devel] EPEL 8 Next rebuild blocked by modularity magic, please help
Hello, I opened this ticket 1+ month ago: https://pagure.io/releng/issue/11947 tl;dr RHEL modular python39-pip-wheel and python39-setuptools-wheel packages are available in epel8 Koji buildroot but not in epel8-next Koji buildroot. Can somebody please help to fix this? 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Orphaning python-mistune on EPEL
On 10. 01. 24 22:16, Michel Lind wrote: Hi Miro, On Wed, Jan 10, 2024 at 02:51:33PM +0100, Miro Hrončok wrote: Hello, I recently took python-mistune in Fedora. I am not interested in maintaining it in EPEL. It is branched for epel7, epel8 and epel9. @epel-packagers-sig is a collaborator so I assume somebody built this in epel9 without taking responsibility. There is a low impact CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2112231 If somebody want to maintain it, let me know and I'll make you the epel point of contact. Please mark me as the EPEL POC. Already marked Neil. Neil, let me know if I should change 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Orphaning python-mistune on EPEL
On 10. 01. 24 15:21, Neil Hanlon wrote: I'll take this one for epel. Thank You, Neil. Done. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Orphaning python-mistune on EPEL
Hello, I recently took python-mistune in Fedora. I am not interested in maintaining it in EPEL. It is branched for epel7, epel8 and epel9. @epel-packagers-sig is a collaborator so I assume somebody built this in epel9 without taking responsibility. There is a low impact CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2112231 If somebody want to maintain it, let me know and I'll make you the epel point of contact. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: python311-dnf for el8 and el9
On 05. 10. 23 21:52, Ken Dreyer wrote: Hi folks, I have some Python apps that "import dnf". I wanted to run these on the parallel Python versions in RHEL 8 and 9, but there's no python311-dnf library available. I haven't looked into this yet. Has anyone else looked at it? I think I'll need something like https://src.fedoraproject.org/rpms/python3-rpm/c/966f38637a7f51376e57b7aeb19a872986a39b8a , but for a "python3-dnf" package? (By the way, thanks Python team for python3.11 in RHEL 8 and 9. That is helpful for moving workloads across RHEL versions and helping the Python ecosystem move forward. And thank you Miro for python311-rpm!) Hello. Packaging python3.11-dnf for EPEL 8 and 9 should be trivial, but it's not a single package. $ repoquery -q --repo=c9s-baseos --requires python3-dnf --latest=1 | grep python /usr/bin/python3.9 python(abi) = 3.9 python3-gpg python3-hawkey >= 0.66.0 python3-libcomps >= 0.1.8 python3-libdnf python3-libdnf >= 0.66.0 python3-rpm >= 4.14.0 We would need to package (at least) 4 packages: python3.11-gpg (gpgme) python3.11-hawkey and python3.11-libdnf (libdnf) python3.11-libcomps (libcomps) python3.11-dnf (dnf) There's also a possible usage of the gi.Modulemd module from libmodulemd , but I've only been able to grep that in tests :/ Reproducing the approach from python3-rpm should work, but I haven't tried it. I am not able to commit myself to maintaining the dnf stack in EPEL for couple 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: RHEL 8 Python 3.8 EOL
On 18. 05. 23 13:25, Josh Boyer wrote: On Thu, May 18, 2023 at 3:17 AM Miro Hrončok wrote: Hello folks, just a heads up that according to https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle#rhel8_application_streams the Python 3.8 application stream will be retired in May 2023 (I suppose at the end). Yes, at the end of May. For clarity, the content will still be available however it will no longer be updated or supported. Miro, do you have recommendations to the EPEL maintainers? E.g. Upgrade to python39/python3.11, or use the system-level python? Well, using the "system-level" Python is probably out of the question, I suppose if that was possible, EPEL maintainers would do that in the first place. If you chose 3.8 for you app because 3.6 was too old (e.g. the case of git-revise), I suggest switching to 3.11 if possible (or at least to 3.9). As for all the "library" packages, I have no idea what to recommend. I'd say keeping them in the repos does not do much harm, considering that is what RHEL is doing anyway. However, I'd strongly advise against packaging new EPEL packages for Python 3.8. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] RHEL 8 Python 3.8 EOL
Hello folks, just a heads up that according to https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle#rhel8_application_streams the Python 3.8 application stream will be retired in May 2023 (I suppose at the end). $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3.8 --whatrequires 'python(abi) = 3.8' --whatrequires 'libpython3.8.so.1.0()(64bit)' | pkgname git-revise openscap-report pagure-ev pagure-milters python38-click python38-dateutil python38-freezegun python38-git-revise python38-hvac python38-hypothesis python38-itsdangerous python38-jmespath python38-jsonschema python38-ldap python38-netaddr python38-netaddr-shell python38-ntlm-auth python38-pyasn1 python38-pyasn1-modules python38-pynetbox python38-pyrsistent python38-pytest-runner python38-radicale3 python38-requests_ntlm python38-setuptools_scm python38-textfsm python38-toml python38-winrm python38-xmltodict radicale3 $ repoquery ... --source | pkgname openscap-report pagure python-git-revise python38-click-epel python38-dateutil-epel python38-freezegun-epel python38-hvac python38-hypothesis-epel python38-itsdangerous-epel python38-jmespath python38-jsonschema-epel python38-ldap-epel python38-netaddr-epel python38-ntlm-auth-epel python38-pyasn1-epel python38-pynetbox python38-pyrsistent-epel python38-pytest-runner-epel python38-requests_ntlm-epel python38-setuptools_scm-epel python38-textfsm-epel python38-toml-epel python38-winrm-epel python38-xmltodict-epel radicale -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: python3.11-rpm to EPEL 9
On 16. 05. 23 15:44, Maxwell G wrote:
On Tue May 16, 2023 at 11:04 +0200, Miro Hrončok wrote:
On 15. 05. 23 16:49, Maxwell G wrote:
On Mon May 15, 2023 at 12:14 +0200, Miro Hrončok wrote:
Hello,
I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next.
See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4.
Cool!
I decided to reuse the python3-rpm component (currently epel7 only). Let me
know if I should not.
Are we able to build for multiple Python versions out of the same
specfile?
It's possible, but it's not nice.
In principle, this works:
%build
%define py3x_build() %{global python3_pkgversion %1}%py3_build
%py3x_build 39
%py3x_build 3.11
%install
%define py3x_install() %{global python3_pkgversion %1}%py3_install
%py3x_install 39
%py3x_install 3.11
But with a project like RPM, we might need to run configure multiple times as
well and create separate working directories. Will need to check.
Yeah, that could work,
but I'd change %{global python3_pkgversion %1} to
%{define python3_pkgversion %1} in the py3x_* macro definitions so you
only change the definition of %python3_pkgversion within those macros'
scopes.
Unless there's some other way to work around this, I'd use a
python3.11-rpm or python3.11-rpm-epel component like we've been doing
for the other alt python stacks in RHEL 8.
I consider the "not nice" way easier, as it will only require to keep one
package synced with c8s rpm, and not many. Will try to hack it up and show how
it looks like.
I tend to agree. Syncing packages with RHEL and CentOS Stream is
difficult and tedious so better to limit the amount of times you have to
do it. Carl's new EPEL 10 proposal will hopefully with this.
OK, here's an EPEL 8 demo with multiple Python versions:
https://src.fedoraproject.org/rpms/python3-rpm/pull-request/5
(I am not sure if Python 3.11 is available in the EPEL 8 buildroot already, but
if it is not, we can probably just wait a bit instead of building this in EPEL
8 Next first.)
Unfortunately the trick with %{global python3_pkgversion %1} inside a %define
seemed to work on Fedora 37, but RHEL 8 did not like it (especially with
multiline macros) an I was unable to make it work. Instead, I kept %global'ing
%python3_pkgversion back and forth.
It is not as bad as expected actually, this version of RPM still supports
building and installing the Python bindings via distutils, so I only needed to
run configure once.
--
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: python3.11-rpm to EPEL 9
On 15. 05. 23 16:49, Maxwell G wrote:
On Mon May 15, 2023 at 12:14 +0200, Miro Hrončok wrote:
Hello,
I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next.
See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4.
Cool!
I decided to reuse the python3-rpm component (currently epel7 only). Let me
know if I should not.
Are we able to build for multiple Python versions out of the same
specfile?
It's possible, but it's not nice.
In principle, this works:
%build
%define py3x_build() %{global python3_pkgversion %1}%py3_build
%py3x_build 39
%py3x_build 3.11
%install
%define py3x_install() %{global python3_pkgversion %1}%py3_install
%py3x_install 39
%py3x_install 3.11
But with a project like RPM, we might need to run configure multiple times as
well and create separate working directories. Will need to check.
That PR has:
```
+ # We'll build python3.11-rpm only for now
+ # Once a new Python version is added,
+ # the spec will need to change to support multiple Pythons anyway
+ %global python3_pkgversion 3.11
```
but I thought we got rid of the %py3_other_* stuff that allowed building
for multiple Python versions out of the same specfile.
We did.
Unless there's some other way to work around this, I'd use a
python3.11-rpm or python3.11-rpm-epel component like we've been doing
for the other alt python stacks in RHEL 8.
I consider the "not nice" way easier, as it will only require to keep one
package synced with c8s rpm, and not many. Will try to hack it up and show how
it looks like.
If there is a significant demand, I can try add this (and python39-rpm) to EPEL
8 as well.
As I said on IRC, I'd like that for fedrq.
Ack.
--
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] python3.11-rpm to EPEL 9
Hello, I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next. See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4. I decided to reuse the python3-rpm component (currently epel7 only). Let me know if I should not. If there is a significant demand, I can try add this (and python39-rpm) to EPEL 8 as well. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: python2 in epel8-next
On 07. 04. 23 4:49, Orion Poplawski wrote: I can work around it by defining RHEL_ALLOW_PYTHON2_FOR_BUILD=1, but it seems like we really should be pulling in python2 from the module? FTR I agree EPEL should pull Python 2 from the module. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On 20. 03. 23 12:20, Neal Gompa wrote: I could think of other reasons as well. E.g. it's not important for customers but it's important for Red Hat. Or maybe it is a not-so-important dependency of something else. Does Red Hat have any other motivation with RHEL other than a customer needing the functionality? Those other reasons are generally driven by someone needing it. See e.g. https://bugzilla.redhat.com/2175213 -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On 17. 03. 23 0:08, Troy Dawson wrote: This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. I know I am late to the party, so feel free to ignore me. Is it OK to claim guessed reasons for new packages being added to RHEL? I could think of other reasons as well. E.g. it's not important for customers but it's important for Red Hat. Or maybe it is a not-so-important dependency of something else. What I am trying to say, wouldn't it be generally more accurate to simply state: "Red Hat has decided to promote this package to be an official part of RHEL." ? -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
On 30. 01. 23 21:39, Miro Hrončok wrote: On 30. 01. 23 20:13, Miro Hrončok wrote: On 11. 12. 22 15:48, Miro Hrončok wrote: On 21. 11. 22 12:56, Miro Hrončok wrote: On 09. 11. 22 20:07, Miro Hrončok wrote: On 08. 11. 22 22:36, Troy Dawson wrote: Hi Miro, You have explained the problem very well, and a possible solution. But I'm a bit confused as to what you want to happen. Is this a heads up, that you are going to change something? Do you want us to discuss what is the best thing to do? Yes, that was my intention. Are you letting us know about the problem, and want someone else to implement a solution? I was prepared to implement it myself, but Maxwell is already looking into it. https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/54 As a followup, when we merge this, we might neeed to rebuild some affected packages. A naïve query that returns everything that uses /usr/bin/python3 shebang but probably wants /usr/bin/python3.6: $ comm -12 <(repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | sort) <(repoquery -q --repo=epel8 --whatrequires 'python3.6dist(*)' --whatrequires 'python(abi) = 3.6' | sort) apprise-0:1.0.0-1.el8.noarch argparse-manpage-0:4-1.el8.noarch cekit-0:4.4.0-1.el8.noarch copr-cli-0:1.103-1.el8.noarch csmock-common-0:3.3.4-1.el8.noarch csmock-plugin-gitleaks-0:3.3.4-1.el8.noarch csmock-plugin-infer-0:3.3.4-1.el8.noarch csmock-plugin-unicontrol-0:3.3.4-1.el8.noarch distgen-0:1.14-1.el8.noarch dmlite-shell-0:1.15.2-11.el8.x86_64 drgn-0:0.0.21-1.el8.x86_64 fedpkg-0:1.43-2.el8.noarch fts-rest-client-0:3.12.0-1.el8.noarch glances-0:3.3.0.1-1.el8.noarch kf5-kapidox-0:5.96.0-1.el8.noarch lightdm-gtk-greeter-settings-0:1.2.2-18.el8.noarch meld-0:3.20.4-1.el8.noarch mozo-0:1.26.2-1.el8.noarch nordugrid-arc-arcctl-0:6.16.1-1.el8.x86_64 nordugrid-arc-arex-0:6.16.1-1.el8.x86_64 nordugrid-arc-0:6.16.1-1.el8.x86_64 podman-compose-0:1.0.3-3.el8.noarch pypolicyd-spf-0:2.9.3-1.el8.noarch PyQt-builder-0:1.13.0-2.el8.noarch python3-bloom-0:0.11.2-1.el8.noarch python3-breathe-0:4.11.1-1.el8.noarch python3-django3-0:3.2.15-3.el8.noarch python3-dotenv-0:0.19.2-4.el8.noarch python3-impacket-0:0.10.0-1.el8.noarch python3-ipython-0:7.16.3-1.el8.noarch python3-junitxml-0:0.7-28.el8.noarch python3-kaptan-0:0.5.12-15.el8.noarch python3-kiwi-0:9.24.48-2.el8.noarch python3-subunit-test-0:1.4.0-13.el8.noarch python3-subunit-0:1.4.0-13.el8.noarch python3-tabulate-0:0.8.10-1.el8.noarch python3-testrepository-0:0.0.20-29.el8.noarch python3-vcstool-0:0.3.0-1.el8.noarch python3-virt-firmware-0:1.5-1.el8.noarch python3-websockify-0:0.10.0-3.el8.noarch rednotebook-0:2.26-1.el8.noarch resalloc-openstack-0:9.3-1.el8.noarch resalloc-server-0:4.8-1.el8.noarch resalloc-webui-0:4.8-1.el8.noarch retrace-server-0:1.24.2-1.el8.noarch suricata-0:5.0.10-1.el8.x86_64 s3cmd-0:2.3.0-1.el8.noarch tito-0:0.6.21-1.el8.noarch yamllint-0:1.28.0-1.el8.noarch But obviously, anything in this list *might* be affected: $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | wc -l 92 $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 --source | sort | uniq | wc -l 73 I am building all the packages in https://copr.fedorainfracloud.org/coprs/churchyard/epel8-python3.6-shebang-rebuild/ to see if the shebang changes. Something else came up, than the holidays and suddenly that repo is expired because I have created it as temporary :D Will start over. When it does change I plan to rebuild the package in EPEL 8. The following packages FTBFS: kwin The following packages still build after an hour and I need to remember to check them later: qt-creator root The rest needs a rebuild: ansible-collection-community-general ansible-packaging argparse-manpage asterisk cepces clifm cockpit-file-sharing distgen fedpkg fmf fts-rest-client git-tools ipython kcachegrind kde-dev-scripts kf5-kapidox konversation lightdm-gtk-greeter-settings meld mozo netplan packit plasma-desktop pluma podman-compose pypolicyd-spf PyQt-builder python-bloom python-breathe python-colcon-core python-django3 python-dotenv python-impacket python-junitxml python-kaptan python-tabulate python-testrepository python-vcstool python-websockify resalloc retrace-server rlwrap rpmconf sasutils subunit s3cmd tacacs tito vcs-diff-lint zchunk I don't want to disrupt any "the rawhide and epel8 branch must be in sync" workflows, so I'll probably send PRs. I merged the PRs without response, built the packages and submitted the Bodhi updates. They gone stable by now. This has been "done" from my part. Leftovers are on track: $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 --source | pkgname ansible-collection-community-general https://src.fedoraproject.org/rpms/ansible-collection-community-general/pull-request/12#comment-129648 mozo my PR was merged but not built, submitted the update myself https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-5dd853f8d9 pluma my P
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On 01. 11. 22 15:07, Troy Dawson wrote: Does this sound good to people? Yes please. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
On 30. 01. 23 22:29, Miro Hrončok wrote: On 30. 01. 23 21:39, Miro Hrončok wrote: When it does change I plan to rebuild the package in EPEL 8. The following packages FTBFS: kwin It failed because it has an %if-%rhel-defined Patch :( Trying again from a patched spec. Done. Also needs a rebuild. The following packages still build after an hour and I need to remember to check them later: qt-creator Built, needs a rebuild as well. root Still in progress. Done. Also needs a rebuild. All the packages needed a rebuild. All PRs open (and some fo them already merged). A handful of packages uses rpmautospec and Pagure does not allow me to send an empty PR. I've emailed the maintainers. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
On 30. 01. 23 21:39, Miro Hrončok wrote: When it does change I plan to rebuild the package in EPEL 8. The following packages FTBFS: kwin It failed because it has an %if-%rhel-defined Patch :( Trying again from a patched spec. The following packages still build after an hour and I need to remember to check them later: qt-creator Built, needs a rebuild as well. root Still in progress. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
On 30. 01. 23 20:13, Miro Hrončok wrote: On 11. 12. 22 15:48, Miro Hrončok wrote: On 21. 11. 22 12:56, Miro Hrončok wrote: On 09. 11. 22 20:07, Miro Hrončok wrote: On 08. 11. 22 22:36, Troy Dawson wrote: Hi Miro, You have explained the problem very well, and a possible solution. But I'm a bit confused as to what you want to happen. Is this a heads up, that you are going to change something? Do you want us to discuss what is the best thing to do? Yes, that was my intention. Are you letting us know about the problem, and want someone else to implement a solution? I was prepared to implement it myself, but Maxwell is already looking into it. https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/54 As a followup, when we merge this, we might neeed to rebuild some affected packages. A naïve query that returns everything that uses /usr/bin/python3 shebang but probably wants /usr/bin/python3.6: $ comm -12 <(repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | sort) <(repoquery -q --repo=epel8 --whatrequires 'python3.6dist(*)' --whatrequires 'python(abi) = 3.6' | sort) apprise-0:1.0.0-1.el8.noarch argparse-manpage-0:4-1.el8.noarch cekit-0:4.4.0-1.el8.noarch copr-cli-0:1.103-1.el8.noarch csmock-common-0:3.3.4-1.el8.noarch csmock-plugin-gitleaks-0:3.3.4-1.el8.noarch csmock-plugin-infer-0:3.3.4-1.el8.noarch csmock-plugin-unicontrol-0:3.3.4-1.el8.noarch distgen-0:1.14-1.el8.noarch dmlite-shell-0:1.15.2-11.el8.x86_64 drgn-0:0.0.21-1.el8.x86_64 fedpkg-0:1.43-2.el8.noarch fts-rest-client-0:3.12.0-1.el8.noarch glances-0:3.3.0.1-1.el8.noarch kf5-kapidox-0:5.96.0-1.el8.noarch lightdm-gtk-greeter-settings-0:1.2.2-18.el8.noarch meld-0:3.20.4-1.el8.noarch mozo-0:1.26.2-1.el8.noarch nordugrid-arc-arcctl-0:6.16.1-1.el8.x86_64 nordugrid-arc-arex-0:6.16.1-1.el8.x86_64 nordugrid-arc-0:6.16.1-1.el8.x86_64 podman-compose-0:1.0.3-3.el8.noarch pypolicyd-spf-0:2.9.3-1.el8.noarch PyQt-builder-0:1.13.0-2.el8.noarch python3-bloom-0:0.11.2-1.el8.noarch python3-breathe-0:4.11.1-1.el8.noarch python3-django3-0:3.2.15-3.el8.noarch python3-dotenv-0:0.19.2-4.el8.noarch python3-impacket-0:0.10.0-1.el8.noarch python3-ipython-0:7.16.3-1.el8.noarch python3-junitxml-0:0.7-28.el8.noarch python3-kaptan-0:0.5.12-15.el8.noarch python3-kiwi-0:9.24.48-2.el8.noarch python3-subunit-test-0:1.4.0-13.el8.noarch python3-subunit-0:1.4.0-13.el8.noarch python3-tabulate-0:0.8.10-1.el8.noarch python3-testrepository-0:0.0.20-29.el8.noarch python3-vcstool-0:0.3.0-1.el8.noarch python3-virt-firmware-0:1.5-1.el8.noarch python3-websockify-0:0.10.0-3.el8.noarch rednotebook-0:2.26-1.el8.noarch resalloc-openstack-0:9.3-1.el8.noarch resalloc-server-0:4.8-1.el8.noarch resalloc-webui-0:4.8-1.el8.noarch retrace-server-0:1.24.2-1.el8.noarch suricata-0:5.0.10-1.el8.x86_64 s3cmd-0:2.3.0-1.el8.noarch tito-0:0.6.21-1.el8.noarch yamllint-0:1.28.0-1.el8.noarch But obviously, anything in this list *might* be affected: $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | wc -l 92 $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 --source | sort | uniq | wc -l 73 I am building all the packages in https://copr.fedorainfracloud.org/coprs/churchyard/epel8-python3.6-shebang-rebuild/ to see if the shebang changes. Something else came up, than the holidays and suddenly that repo is expired because I have created it as temporary :D Will start over. When it does change I plan to rebuild the package in EPEL 8. The following packages FTBFS: kwin The following packages still build after an hour and I need to remember to check them later: qt-creator root The rest needs a rebuild: ansible-collection-community-general ansible-packaging argparse-manpage asterisk cepces clifm cockpit-file-sharing distgen fedpkg fmf fts-rest-client git-tools ipython kcachegrind kde-dev-scripts kf5-kapidox konversation lightdm-gtk-greeter-settings meld mozo netplan packit plasma-desktop pluma podman-compose pypolicyd-spf PyQt-builder python-bloom python-breathe python-colcon-core python-django3 python-dotenv python-impacket python-junitxml python-kaptan python-tabulate python-testrepository python-vcstool python-websockify resalloc retrace-server rlwrap rpmconf sasutils subunit s3cmd tacacs tito vcs-diff-lint zchunk I don't want to disrupt any "the rawhide and epel8 branch must be in sync" workflows, so I'll probably send PRs. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
On 11. 12. 22 15:48, Miro Hrončok wrote: On 21. 11. 22 12:56, Miro Hrončok wrote: On 09. 11. 22 20:07, Miro Hrončok wrote: On 08. 11. 22 22:36, Troy Dawson wrote: Hi Miro, You have explained the problem very well, and a possible solution. But I'm a bit confused as to what you want to happen. Is this a heads up, that you are going to change something? Do you want us to discuss what is the best thing to do? Yes, that was my intention. Are you letting us know about the problem, and want someone else to implement a solution? I was prepared to implement it myself, but Maxwell is already looking into it. https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/54 As a followup, when we merge this, we might neeed to rebuild some affected packages. A naïve query that returns everything that uses /usr/bin/python3 shebang but probably wants /usr/bin/python3.6: $ comm -12 <(repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | sort) <(repoquery -q --repo=epel8 --whatrequires 'python3.6dist(*)' --whatrequires 'python(abi) = 3.6' | sort) apprise-0:1.0.0-1.el8.noarch argparse-manpage-0:4-1.el8.noarch cekit-0:4.4.0-1.el8.noarch copr-cli-0:1.103-1.el8.noarch csmock-common-0:3.3.4-1.el8.noarch csmock-plugin-gitleaks-0:3.3.4-1.el8.noarch csmock-plugin-infer-0:3.3.4-1.el8.noarch csmock-plugin-unicontrol-0:3.3.4-1.el8.noarch distgen-0:1.14-1.el8.noarch dmlite-shell-0:1.15.2-11.el8.x86_64 drgn-0:0.0.21-1.el8.x86_64 fedpkg-0:1.43-2.el8.noarch fts-rest-client-0:3.12.0-1.el8.noarch glances-0:3.3.0.1-1.el8.noarch kf5-kapidox-0:5.96.0-1.el8.noarch lightdm-gtk-greeter-settings-0:1.2.2-18.el8.noarch meld-0:3.20.4-1.el8.noarch mozo-0:1.26.2-1.el8.noarch nordugrid-arc-arcctl-0:6.16.1-1.el8.x86_64 nordugrid-arc-arex-0:6.16.1-1.el8.x86_64 nordugrid-arc-0:6.16.1-1.el8.x86_64 podman-compose-0:1.0.3-3.el8.noarch pypolicyd-spf-0:2.9.3-1.el8.noarch PyQt-builder-0:1.13.0-2.el8.noarch python3-bloom-0:0.11.2-1.el8.noarch python3-breathe-0:4.11.1-1.el8.noarch python3-django3-0:3.2.15-3.el8.noarch python3-dotenv-0:0.19.2-4.el8.noarch python3-impacket-0:0.10.0-1.el8.noarch python3-ipython-0:7.16.3-1.el8.noarch python3-junitxml-0:0.7-28.el8.noarch python3-kaptan-0:0.5.12-15.el8.noarch python3-kiwi-0:9.24.48-2.el8.noarch python3-subunit-test-0:1.4.0-13.el8.noarch python3-subunit-0:1.4.0-13.el8.noarch python3-tabulate-0:0.8.10-1.el8.noarch python3-testrepository-0:0.0.20-29.el8.noarch python3-vcstool-0:0.3.0-1.el8.noarch python3-virt-firmware-0:1.5-1.el8.noarch python3-websockify-0:0.10.0-3.el8.noarch rednotebook-0:2.26-1.el8.noarch resalloc-openstack-0:9.3-1.el8.noarch resalloc-server-0:4.8-1.el8.noarch resalloc-webui-0:4.8-1.el8.noarch retrace-server-0:1.24.2-1.el8.noarch suricata-0:5.0.10-1.el8.x86_64 s3cmd-0:2.3.0-1.el8.noarch tito-0:0.6.21-1.el8.noarch yamllint-0:1.28.0-1.el8.noarch But obviously, anything in this list *might* be affected: $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | wc -l 92 $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 --source | sort | uniq | wc -l 73 I am building all the packages in https://copr.fedorainfracloud.org/coprs/churchyard/epel8-python3.6-shebang-rebuild/ to see if the shebang changes. Something else came up, than the holidays and suddenly that repo is expired because I have created it as temporary :D Will start over. When it does change I plan to rebuild the package in EPEL 8. And I am not even querying EPEL 8 Next. There seem to be 13 packages in EPEL Next and none of them requires /usr/bin/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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Updating tox to 4 in EPEL 9
On 21. 12. 22 5:44, Carl George wrote: I would prefer using the incompat process [0] to upgrade epel9's python-tox to version 4, and introducing a python-tox3 compat package. We could use the same naming scheme in Fedora if it makes any sense to keep tox 3 around there for some period of time. [0]https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ I'll take into consideration. However, as of now we even have some trouble updating tox to 4 in Rawhide so we are focusing on 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://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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Updating tox to 4 in EPEL 9
Hello folks. A new major version of tox was released. The bump form version 3 to version 4 should be flawless to users but breaks all the plugins that have not been updated to the new API yet. I would like to avoid the need to maintain tox 3 in EPEL9 for many years after upstream abandoned it (they have no intention to do maintenance releases for tox 3.x). We are currently upgrading to tox 4 in Fedora Rawhide. When the dust settles I'd like to have the possibility to update it in EPEL too. One way to do it is to package a new tox4 component in EPEL 9 (and make it conflict with tox < 4) and keep the old tox around until it breaks (the breakage might mean it no longer supports a newly added Python version being added to RHEL 9). Is that a sensible approach for 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
On 21. 11. 22 12:56, Miro Hrončok wrote: On 09. 11. 22 20:07, Miro Hrončok wrote: On 08. 11. 22 22:36, Troy Dawson wrote: Hi Miro, You have explained the problem very well, and a possible solution. But I'm a bit confused as to what you want to happen. Is this a heads up, that you are going to change something? Do you want us to discuss what is the best thing to do? Yes, that was my intention. Are you letting us know about the problem, and want someone else to implement a solution? I was prepared to implement it myself, but Maxwell is already looking into it. https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/54 As a followup, when we merge this, we might neeed to rebuild some affected packages. A naïve query that returns everything that uses /usr/bin/python3 shebang but probably wants /usr/bin/python3.6: $ comm -12 <(repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | sort) <(repoquery -q --repo=epel8 --whatrequires 'python3.6dist(*)' --whatrequires 'python(abi) = 3.6' | sort) apprise-0:1.0.0-1.el8.noarch argparse-manpage-0:4-1.el8.noarch cekit-0:4.4.0-1.el8.noarch copr-cli-0:1.103-1.el8.noarch csmock-common-0:3.3.4-1.el8.noarch csmock-plugin-gitleaks-0:3.3.4-1.el8.noarch csmock-plugin-infer-0:3.3.4-1.el8.noarch csmock-plugin-unicontrol-0:3.3.4-1.el8.noarch distgen-0:1.14-1.el8.noarch dmlite-shell-0:1.15.2-11.el8.x86_64 drgn-0:0.0.21-1.el8.x86_64 fedpkg-0:1.43-2.el8.noarch fts-rest-client-0:3.12.0-1.el8.noarch glances-0:3.3.0.1-1.el8.noarch kf5-kapidox-0:5.96.0-1.el8.noarch lightdm-gtk-greeter-settings-0:1.2.2-18.el8.noarch meld-0:3.20.4-1.el8.noarch mozo-0:1.26.2-1.el8.noarch nordugrid-arc-arcctl-0:6.16.1-1.el8.x86_64 nordugrid-arc-arex-0:6.16.1-1.el8.x86_64 nordugrid-arc-0:6.16.1-1.el8.x86_64 podman-compose-0:1.0.3-3.el8.noarch pypolicyd-spf-0:2.9.3-1.el8.noarch PyQt-builder-0:1.13.0-2.el8.noarch python3-bloom-0:0.11.2-1.el8.noarch python3-breathe-0:4.11.1-1.el8.noarch python3-django3-0:3.2.15-3.el8.noarch python3-dotenv-0:0.19.2-4.el8.noarch python3-impacket-0:0.10.0-1.el8.noarch python3-ipython-0:7.16.3-1.el8.noarch python3-junitxml-0:0.7-28.el8.noarch python3-kaptan-0:0.5.12-15.el8.noarch python3-kiwi-0:9.24.48-2.el8.noarch python3-subunit-test-0:1.4.0-13.el8.noarch python3-subunit-0:1.4.0-13.el8.noarch python3-tabulate-0:0.8.10-1.el8.noarch python3-testrepository-0:0.0.20-29.el8.noarch python3-vcstool-0:0.3.0-1.el8.noarch python3-virt-firmware-0:1.5-1.el8.noarch python3-websockify-0:0.10.0-3.el8.noarch rednotebook-0:2.26-1.el8.noarch resalloc-openstack-0:9.3-1.el8.noarch resalloc-server-0:4.8-1.el8.noarch resalloc-webui-0:4.8-1.el8.noarch retrace-server-0:1.24.2-1.el8.noarch suricata-0:5.0.10-1.el8.x86_64 s3cmd-0:2.3.0-1.el8.noarch tito-0:0.6.21-1.el8.noarch yamllint-0:1.28.0-1.el8.noarch But obviously, anything in this list *might* be affected: $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | wc -l 92 $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 --source | sort | uniq | wc -l 73 I am building all the packages in https://copr.fedorainfracloud.org/coprs/churchyard/epel8-python3.6-shebang-rebuild/ to see if the shebang changes. When it does change I plan to rebuild the package in EPEL 8. And I am not even querying EPEL 8 Next. There seem to be 13 packages in EPEL Next and none of them requires /usr/bin/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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Replace versioned MODULE_COMPAT_ requires by generators
On 06. 12. 22 15:02, Jitka Plesnikova wrote: The dependency generator would be added to perl-srpm-macros which is in buildroot of Fedora. Why not perl-generators instead? -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
On 09. 11. 22 20:07, Miro Hrončok wrote: On 08. 11. 22 22:36, Troy Dawson wrote: Hi Miro, You have explained the problem very well, and a possible solution. But I'm a bit confused as to what you want to happen. Is this a heads up, that you are going to change something? Do you want us to discuss what is the best thing to do? Yes, that was my intention. Are you letting us know about the problem, and want someone else to implement a solution? I was prepared to implement it myself, but Maxwell is already looking into it. https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/54 As a followup, when we merge this, we might neeed to rebuild some affected packages. A naïve query that returns everything that uses /usr/bin/python3 shebang but probably wants /usr/bin/python3.6: $ comm -12 <(repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | sort) <(repoquery -q --repo=epel8 --whatrequires 'python3.6dist(*)' --whatrequires 'python(abi) = 3.6' | sort) apprise-0:1.0.0-1.el8.noarch argparse-manpage-0:4-1.el8.noarch cekit-0:4.4.0-1.el8.noarch copr-cli-0:1.103-1.el8.noarch csmock-common-0:3.3.4-1.el8.noarch csmock-plugin-gitleaks-0:3.3.4-1.el8.noarch csmock-plugin-infer-0:3.3.4-1.el8.noarch csmock-plugin-unicontrol-0:3.3.4-1.el8.noarch distgen-0:1.14-1.el8.noarch dmlite-shell-0:1.15.2-11.el8.x86_64 drgn-0:0.0.21-1.el8.x86_64 fedpkg-0:1.43-2.el8.noarch fts-rest-client-0:3.12.0-1.el8.noarch glances-0:3.3.0.1-1.el8.noarch kf5-kapidox-0:5.96.0-1.el8.noarch lightdm-gtk-greeter-settings-0:1.2.2-18.el8.noarch meld-0:3.20.4-1.el8.noarch mozo-0:1.26.2-1.el8.noarch nordugrid-arc-arcctl-0:6.16.1-1.el8.x86_64 nordugrid-arc-arex-0:6.16.1-1.el8.x86_64 nordugrid-arc-0:6.16.1-1.el8.x86_64 podman-compose-0:1.0.3-3.el8.noarch pypolicyd-spf-0:2.9.3-1.el8.noarch PyQt-builder-0:1.13.0-2.el8.noarch python3-bloom-0:0.11.2-1.el8.noarch python3-breathe-0:4.11.1-1.el8.noarch python3-django3-0:3.2.15-3.el8.noarch python3-dotenv-0:0.19.2-4.el8.noarch python3-impacket-0:0.10.0-1.el8.noarch python3-ipython-0:7.16.3-1.el8.noarch python3-junitxml-0:0.7-28.el8.noarch python3-kaptan-0:0.5.12-15.el8.noarch python3-kiwi-0:9.24.48-2.el8.noarch python3-subunit-test-0:1.4.0-13.el8.noarch python3-subunit-0:1.4.0-13.el8.noarch python3-tabulate-0:0.8.10-1.el8.noarch python3-testrepository-0:0.0.20-29.el8.noarch python3-vcstool-0:0.3.0-1.el8.noarch python3-virt-firmware-0:1.5-1.el8.noarch python3-websockify-0:0.10.0-3.el8.noarch rednotebook-0:2.26-1.el8.noarch resalloc-openstack-0:9.3-1.el8.noarch resalloc-server-0:4.8-1.el8.noarch resalloc-webui-0:4.8-1.el8.noarch retrace-server-0:1.24.2-1.el8.noarch suricata-0:5.0.10-1.el8.x86_64 s3cmd-0:2.3.0-1.el8.noarch tito-0:0.6.21-1.el8.noarch yamllint-0:1.28.0-1.el8.noarch But obviously, anything in this list *might* be affected: $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 | wc -l 92 $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3 --source | sort | uniq | wc -l 73 And I am not even querying EPEL 8 Next. -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
On 08. 11. 22 22:36, Troy Dawson wrote: Hi Miro, You have explained the problem very well, and a possible solution. But I'm a bit confused as to what you want to happen. Is this a heads up, that you are going to change something? Do you want us to discuss what is the best thing to do? Yes, that was my intention. Are you letting us know about the problem, and want someone else to implement a solution? I was prepared to implement it myself, but Maxwell is already looking into it. https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/54 -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] EPEL 8: %__python3 == /usr/bin/python3 creates runtime problems with alternatives
Hello EPEL folks,
In EL 8, it is possible to change the "meaning" of /usr/bin/python3 because it
is managed by alternatives:
$ ls -l /usr/bin/python3
lrwxrwxrwx. ... /usr/bin/python3 -> /etc/alternatives/python3
And since %__python3 on EPEL 8 is set to /usr/bin/python3 by epel-rpm-macros:
$ rpm --eval '%__python3'
/usr/bin/python3
When packages have %py3_shebang_fix on EPEL 8:
%py3_shebang_fix %{buildroot}%{_bindir}/*
The shebengs have #!/usr/bin/python3 in them.
(This is done by %__brp_mangle_shebangs automatically, so even packages without
%py3_shebang_fix might be affected.)
But when the package has importable modules in %{python3_sitelib} or
%{python3_sitearch} or simply depends on other Python 3.6 modules, and the user
uses alternatives to change /usr/bin/python3 to e.g. python3.9, the script no
longer works.
I suppose the default value of %__python3 needs to be /usr/bin/python3.6 to
prevent this way of shooting the users to their legs.
(I apologize for letting the alternatives happen, but that ship has sailed a
long time ago. Fortunately, EL 9 no longer have 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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL 8 Modules get the axe on Halloween 2022
On 07. 10. 22 9:33, Petr Pisar wrote: Does EPEL have any communication channel to EPEL users besides this mailing list? If it does, do you plan to announce this change there? Preferably ahead of time. I worry that users do not follow a list called epel-devel because they think it's only for EPEL developers. As such this change will come to them as a surprise. https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/ I agree this should be said 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On 01. 09. 22 0:19, Troy Dawson wrote:
** Solution(s)
A - At the very least, we need to change the wording of the bugs. I am
proposing the following
Subject: Remove from epel9 when rhel 9.1 is released
Comment: This package is being added to RHEL 9.1 at the next minor release.
After the next RHEL minor release, please verify this package was released in
RHEL, and if so remove it from epel9.
Yes please. Ideally, even add a reproducer that verifies this ("go to X and
search for the package name" or "run this repoquery" or even "go to this
documentation page to check it")
B - If possible, move the EPEL2RHEL check to later in the development cycle. I
would like it to be in the step where the packages get added to BaseOS,
AppStream, or CRB. That way we would know it isn't going to be a BuildRoot
only package, and it would reduce the time the bugs sit waiting.
I don't know if this is possible, but I'm going to ask.
Agreed. It could even say which (sub)packages are being added and link to the
appropriate documentation in case some of the EPEL subpackages need to be split
into a spearate component.
C - ?? What if we only created the bugs on the tracker itself, and not the
individual packages ??
Would that be a good thing? Or would it irritate the maintainers?
What do you mean by this? I don't understand it. File it against the
distribution? If there is a dedicated (and educated) person/team who would deal
with this at all RHEL release boundaries, than this makes sense. Otherwise it
just hides this information from the EPEL maintainers.
--
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Proposal: Dropping modules from EPEL-8. Not adding modules to EPEL-9
On 31. 08. 22 23:08, Stephen Smoogen wrote: When EPEL-8 was launched, it came with some support for modules with the hope that a module ecosystem could be built from Fedora packages using RHEL modules as an underlying tool. This has never happened and we have ended up with a muddle of modular packages which will 'build' but may not install or even run on an EL-8 system. Attempts to fix this and work within how EPEL is normally built have been tried for several years by different people but have not worked. At this point it is time to say this experiment with modules in EPEL has not worked and focus resources on what does work. I would like to propose that modular support is removed from EPEL by January 2023. Steps: 1. Approval of this proposal by the EPEL Steering committee and any other ones required. 2. Announcement of end of life to various lists. 3. Archiving of the modules on XYZ date to /pub/archive/epel/8.-MM/Modular and pointing mirrormanager to that for that 4. Make changes in bodhi to turn off reporting about modules for EL8. 5. Make changes in MBS configs to turn off building modules for EL8. 6. Make changes in PDC for EL8 modules 7. Make changes in compose scripts and tools to no longer cover EPEL-8 modules 8. Remove epel-8 modules from /pub/epel/8 9. Announce closure of this proposal and any lessons learned. 10. Drop https://src.fedoraproject.org/rpms/epel-release/blob/epel8/f/epel-testing-modular.repo -- 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] EPEL 8: All Python 3.8 and 3.9 packages provide python3dist(...)
Hello EPEL people,
apparently, all EPEL 8 Python 3.8 and 3.9 packages that should only provide
python3.8dist(...)/python3.9dist(...) also provide python3dist(...).
That means, any Python 3.6 package that BuildRequires python3dist(...) might
get a Python 3.8/3.9 package instead.
This has been fixed via
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/47 (and
accidentally pushed without epel-rpm-macros maintainers ack).
I propose that we ship the fix and rebuild all affected packages. That would be:
$ repoquery --repo=epel8{,-testing} --whatprovides 'python3.8dist(*)'
--whatprovides 'python3.9dist(*)' --source | pkgname | sort | uniq
ansible
lutris
python38-click-epel
python38-dateutil-epel
python38-freezegun-epel
python38-hvac
python38-hypothesis-epel
python38-itsdangerous-epel
python38-jmespath
python38-jsonschema-epel
python38-netaddr-epel
python38-ntlm-auth-epel
python38-pynetbox
python38-pyrsistent-epel
python38-pytest-runner-epel
python38-requests_ntlm-epel
python38-setuptools_scm-epel
python38-textfsm-epel
python38-toml-epel
python38-winrm-epel
python38-xmltodict-epel
python39-click-epel
radicale
+ new packages that have not yet reached the either EPEL 8 repo
+ probably the same query in EPEL 8 next, but I miss a repo file for it ATM
--
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-attrs on epel very outdated
On 05. 07. 22 12:43, Stephen Smoogen wrote: You will need to work with the upstream RHEL team to see if they can update python-attrs The rule of thumb is that we don't. If you need a certain feature from the newer version, you can try requesting a backport, explaining your use case. We generally try to help fellow EPEL packagers even when they are not RHEL customers (when the backport is doable with reasonable effort). However, if you just want a newer version because you like new things, maybe try Fedora Linux instead of EL+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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] How to remove builds from EPEL 9 Next?
Hey EPEL folks, The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0 GA, as the frozen set of packages from CentOS Stream made it segfault during build. So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next. Now, it builds in regular EPEL 9 successfully (as the segfault was fixed in the meantime). So, we should probbaly build and ship the package in EPEL 9. But we should also remove/obsolete/replace the EPEL 9 build somehow. I suppose there are multiple options here: 1. bump and build in epel9, so the EVR is higher, do nothing with epel9-next 2. build in epel9, untag the old epel9-next build What is the general guideline in this situation? Related, but not necessarily blocking question: Should EPEL 9 Next be purged after each RHEL 9.Y release and all the purged builds built in regular EPEL 9 instead? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
On 25. 05. 22 2:52, Maxwell G via epel-devel wrote:
On Tuesday, May 24, 2022 6:56:41 PM CDT Orion Poplawski wrote:
Sure, except I know nothing about how docs.fp.o works ;)
The source code for the EPEL docs page is here[1]. Honestly, I'm not super
familiar with it either :).
[1]: https://pagure.io/epel/tree/main
It looks like it's hard-coded to python3dist, so I think it has to
change to %{py38_dist}.
I looked at the macros file on Fedora and saw that it was dynamic, but I was
too lazy to look at an actual EL 8 system and notice it hadn't been backported
;(. I opened https://bugzilla.redhat.com/show_bug.cgi?id=2090007. Let's see
what the RHEL Python maintainers have to say... As far as I know, `%
{py38_dist}` doesn't exist at all.
Just for the record. We can fix %{py3_dist} to include the 3.X part, but it
will only work when either %python3_pkgversion is redefined in the specfile or
python3X-rpm-macros are installed in the buildSRPM buildroot (and the latter is
not happening for Koji builds). I.e. doing just this:
BuildRequires: python38-rpm-macros
BuildRequires: %{py3_dist ...}
Will *not* work. That is a limitation we cannot workaround.
--
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
On 25. 05. 22 1:56, Orion Poplawski wrote:
== Issues ==
* How to handle %{py3_dist} macro?
I believe `%{py3_dist}` works properly if you add `%global python3_pkgversion
3X`.
It looks like it's hard-coded to python3dist, so I think it has to change to
%{py38_dist}.
That could (should?) be fixed by either redefining the macro in each
python3X-rpm-macros or by changing the macro in python-srpm-macros to use
%python3_pkgversion value -- that would require some "guess-work" where to put
the dot, but I suppose the logic won't be that convoluted:
* 3 -> python3dist
* 3X -> python3.Xdist
* 3XY -> python3.XYdist
* 3.X -> python3.Xdist
* 3.Y -> python3.XYdist
* anything else -> blow up?
That reminds me https://bugzilla.redhat.com/show_bug.cgi?id=1812665 which was
fixed incorrectly in RHEL 7 but a followup was never opened.
--
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
On 17. 05. 22 16:58, Leon Fauster via epel-devel wrote:
Am 17.05.22 um 14:57 schrieb Stephen Smoogen:
On Tue, 17 May 2022 at 07:02, Josh Boyer <mailto:jwbo...@redhat.com>> wrote:
On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel
mailto:epel-devel@lists.fedoraproject.org>> wrote:
>
> Hi all,
>
> with the "upcoming" ansible-core migration, I wonder if its
possible to
> provide a python-passlib package (or stream) for the python38
> environment (ansible-core dependency).
>
> The current status:
>
> # rpm -q python3-passlib --requires |head -1
> python(abi) = 3.6
>
> Whats the best approach. Upgrade the ABI compat or provide a
module build?
Modular build against the python38 module.
[resend because lists did not like me previously.]
As far as I know, the Fedora/EPEL MBS/Koji can not do this without itself
building a python38 module which matches/replaces the RHEL one. MBS can only
use modules which it has built itself and does not have a way to understand
about 'external' modules. [ All RHEL code is 'external' to both koji and mbs
databases so they do not have a way to reference them for a build.]
Because of this, we have to use grobisplitter to put the python38 as a
'regular' rpm (which works because the pythons are parallel installable.).
I think what could be done is a python38-passlib package which was built
against the python38 rpms.
Ok, thanks. A quick local test was successful. python38-passlib and
python3-passlib are parallel installable.
Following patch
https://paste.centos.org/view/06187bdb
Why %{?python_disable_dependency_generator} ?
--
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: RHEL 9 packages available in EPEL 9 (in different versions as well)
On 04. 05. 22 22:03, Josh Boyer wrote: The only difference I can spot is anthy-unicode-devel and double-conversion-devel, which apparently might be allowed in EPEL 9 for now. Both of those were requested and added in the last month (anthy-unicode-devel just this week). That should be reflected in CentOS Stream 9 now(ish) and a future version of RHEL 9 at some point. That is how I udnerstood this. The rest of the packages however appear to be both in EPEL 9 and in RHEL 9.0. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: RHEL 9 packages available in EPEL 9 (in different versions as well)
On 04. 05. 22 15:40, Troy Dawson wrote:
I just want to make sure that you are querying RHEL 9.0 and not 9.1.
Well, I was querying 9.1, so you have a point. However, with 9.0 it is almost
the same:
$ comm -12 <(repoquery -q
--repo=RHEL9.0-{BaseOS,AppStream,CRB,HighAvailability} -a | pkgname | sort |
uniq ) <(repoquery -q --repo=epel9 -a | pkgname | sort | uniq)
libwmf
libwmf-lite
pybind11-devel
python3-pybind11
tesseract
tesseract-devel
tesseract-langpack-eng
tesseract-tessdata-doc
$ comm -12 <(repoquery -q
--repo=RHEL9.0-{BaseOS,AppStream,CRB,HighAvailability}-source -a | pkgname |
sort | uniq ) <(repoquery -q --repo=epel9-source -a | pkgname | sort | uniq)
libwmf
pybind11
tesseract
tesseract-tessdata
The only difference I can spot is anthy-unicode-devel and
double-conversion-devel, which apparently might be allowed in EPEL 9 for 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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] RHEL 9 packages available in EPEL 9 (in different versions as well)
Hello EPEL.
I have just found out that the pybind11 component from c9s / RHEL 9 CRB has
been built in EPEL 9 in different version:
$ repoquery -q --repo=c9s-crb-source pybind11
pybind11-0:2.6.2-3.el9.src
pybind11-0:2.6.2-4.el9.src
$ repoquery -q --repo=RHEL9-CRB-source pybind11
pybind11-0:2.6.2-4.el9.src
$ repoquery -q --repo=epel9-source pybind11
pybind11-0:2.9.1-1.el9.src
$ repoquery -q --repo=c9s-crb pybind11-devel python3-pybind11
pybind11-devel-0:2.6.2-3.el9.i686
pybind11-devel-0:2.6.2-3.el9.x86_64
pybind11-devel-0:2.6.2-4.el9.i686
pybind11-devel-0:2.6.2-4.el9.x86_64
python3-pybind11-0:2.6.2-3.el9.x86_64
python3-pybind11-0:2.6.2-4.el9.x86_64
$ repoquery -q --repo=RHEL9-CRB pybind11-devel python3-pybind11
pybind11-devel-0:2.6.2-4.el9.i686
pybind11-devel-0:2.6.2-4.el9.x86_64
python3-pybind11-0:2.6.2-4.el9.x86_64
$ repoquery -q --repo=epel9 pybind11-devel python3-pybind11
pybind11-devel-0:2.9.1-1.el9.x86_64
python3-pybind11-0:2.9.1-1.el9.x86_64
I always assumed fedora-scm-requests admins would refuse such branch requests,
but apparently not:
https://pagure.io/releng/fedora-scm-requests/issue/42248
I've checked and we have more components that clash:
$ comm -12 <(repoquery -q
--repo=RHEL9-{BaseOS,AppStream,CRB,HighAvailability}-source -a | pkgname | sort
| uniq ) <(repoquery -q --repo=epel9-source -a | pkgname | sort | uniq)
libwmf
pybind11
tesseract
tesseract-tessdata
As well as "binary" RPMs:
$ comm -12 <(repoquery -q --repo=RHEL9-{BaseOS,AppStream,CRB,HighAvailability}
-a | pkgname | sort | uniq ) <(repoquery -q --repo=epel9 -a | pkgname | sort |
uniq)
anthy-unicode-devel
double-conversion-devel
libwmf
libwmf-lite
pybind11-devel
python3-pybind11
tesseract
tesseract-devel
tesseract-langpack-eng
tesseract-tessdata-doc
And apparently, this is not just CRB, but also AppStream:
$ repoquery -q --repo=RHEL9-{BaseOS,AppStream,CRB,HighAvailability}{,-source}
--queryformat='%{name} %{reponame}' libwmf pybind11 tesseract
tesseract-tessdata anthy-unicode-devel double-conversion-devel libwmf-lite
pybind11-devel python3-pybind11 tesseract-devel tesseract-langpack-eng
tesseract-tessdata-doc
anthy-unicode-devel RHEL9-CRB
double-conversion-devel RHEL9-CRB
libwmf RHEL9-AppStream
libwmf RHEL9-AppStream-source
libwmf-lite RHEL9-AppStream
pybind11RHEL9-CRB-source
pybind11-devel RHEL9-CRB
python3-pybind11RHEL9-CRB
tesseract RHEL9-AppStream
tesseract RHEL9-AppStream-source
tesseract-devel RHEL9-CRB
tesseract-langpack-eng RHEL9-AppStream
tesseract-tessdata RHEL9-AppStream-source
tesseract-tessdata-doc RHEL9-AppStream
Do I understand correctly that this is still *not* allowed? If so, what can we
do to prevent 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://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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Qt update and packages rebuild
On 29. 04. 22 22:01, Troy Dawson wrote: And ... now I just realized that this sounds alot like taking my Will-It-Install and pointing it at the CentOS Stream 9 development compose. I am afraid that we would need to point it to a repository that contains all the builds immediately as they happen, before they pass gating. And I am not sure such repository exists. Is there a Koji repo from the c9s-gate tag? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Does EPEL 9 Koji have older c9s packages than local mock?
On 22. 04. 22 19:53, Miro Hrončok wrote: Hello, I've been trying to debug a segfault during %check that only occurs in epel9 Koji, but not in mock. At the end, I compared the list of packages with: $ koji list-buildroot 34845388 | sort > koji $ mock -r centos-stream+epel-9-x86_64 shell -- rpm -qa | sort > mock $ diff -u koji mock | grep -v ' ' +acl-2.3.1-3.el9.x86_64 -audit-libs-3.0.7-101.el9.x86_64 ... This seems like my local mock has newer c9s packages than the Koji build repo. Is that expected, or is pulling c9s packages into the build repo stuck on Koji side? Actually, I got an idea that EPEL 9 Koji might already be using (internal?) RHEL 9.0, possibly I have missed this switch... However, the centos-stream-release package contraditcs taht idea :/ I've checked with an EPEL 9 Next Koji scratchbuild and it got e.g. pyproject-rpm-macros-1.0.1-1.el9. Thanks for all the answers -- I see them in the archives but never received them :( Was this "freeze" ever announced somewhere? I might have missed that as well, considering I am clearly missing some email. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Does EPEL 9 Koji have older c9s packages than local mock?
Hello, I've been trying to debug a segfault during %check that only occurs in epel9 Koji, but not in mock. At the end, I compared the list of packages with: $ koji list-buildroot 34845388 | sort > koji $ mock -r centos-stream+epel-9-x86_64 shell -- rpm -qa | sort > mock $ diff -u koji mock | grep -v ' ' +acl-2.3.1-3.el9.x86_64 -audit-libs-3.0.7-101.el9.x86_64 +audit-libs-3.0.7-102.el9.x86_64 -binutils-gold-2.35.2-17.el9.x86_64 -binutils-2.35.2-17.el9.x86_64 +binutils-gold-2.35.2-19.el9.x86_64 +binutils-2.35.2-19.el9.x86_64 -centos-gpg-keys-9.0-9.el9.noarch -centos-stream-release-9.0-9.el9.noarch -centos-stream-repos-9.0-9.el9.noarch +centos-gpg-keys-9.0-12.el9.noarch +centos-stream-release-9.0-12.el9.noarch +centos-stream-repos-9.0-12.el9.noarch -crypto-policies-20220203-1.gitf03e75e.el9.noarch +crypto-policies-20220404-1.git845c0c1.el9.noarch +cryptsetup-libs-2.4.3-4.el9.x86_64 -cyrus-sasl-lib-2.1.27-19.el9.x86_64 +cyrus-sasl-lib-2.1.27-20.el9.x86_64 +dbus-broker-28-5.el9.x86_64 +dbus-common-1.12.20-5.el9.noarch +dbus-1.12.20-5.el9.x86_64 +device-mapper-libs-1.02.183-4.el9.x86_64 +device-mapper-1.02.183-4.el9.x86_64 -elfutils-debuginfod-client-0.186-1.el9.x86_64 -elfutils-default-yama-scope-0.186-1.el9.noarch -elfutils-libelf-0.186-1.el9.x86_64 -elfutils-libs-0.186-1.el9.x86_64 -elfutils-0.186-1.el9.x86_64 -epel-release-9-2.el9.noarch +elfutils-debuginfod-client-0.186-3.el9.x86_64 +elfutils-default-yama-scope-0.186-3.el9.noarch +elfutils-libelf-0.186-3.el9.x86_64 +elfutils-libs-0.186-3.el9.x86_64 +elfutils-0.186-3.el9.x86_64 -expat-2.2.10-9.el9.x86_64 -fedpkg-minimal-1.2.0-4.el9.noarch +expat-2.2.10-10.el9.x86_64 -flexiblas-netlib-3.0.4-7.el9.x86_64 -flexiblas-openblas-openmp-3.0.4-7.el9.x86_64 -flexiblas-3.0.4-7.el9.x86_64 +flexiblas-netlib-3.0.4-8.el9.x86_64 +flexiblas-openblas-openmp-3.0.4-8.el9.x86_64 +flexiblas-3.0.4-8.el9.x86_64 -glibc-common-2.34-25.el9.x86_64 -glibc-gconv-extra-2.34-25.el9.x86_64 -glibc-minimal-langpack-2.34-25.el9.x86_64 -glibc-2.34-25.el9.x86_64 +glibc-common-2.34-29.el9.x86_64 +glibc-gconv-extra-2.34-29.el9.x86_64 +glibc-minimal-langpack-2.34-29.el9.x86_64 +glibc-2.34-29.el9.x86_64 -gnutls-3.7.3-6.el9.x86_64 +gnutls-3.7.3-9.el9.x86_64 +gpg-pubkey-3228467c-613798eb +gpg-pubkey-8483c65d-5ccc5b19 -krb5-libs-1.19.1-13.el9.x86_64 +kmod-libs-28-7.el9.x86_64 +krb5-libs-1.19.1-15.el9.x86_64 -libgcc-11.2.1-9.4.el9.x86_64 -libgcrypt-1.10.0-2.el9.x86_64 -libgfortran-11.2.1-9.4.el9.x86_64 -libgomp-11.2.1-9.4.el9.x86_64 +libgcc-11.2.1-10.el9.x86_64 +libgcrypt-1.10.0-3.el9.x86_64 +libgfortran-11.2.1-10.el9.x86_64 +libgomp-11.2.1-10.el9.x86_64 -libquadmath-11.2.1-9.4.el9.x86_64 +libquadmath-11.2.1-10.el9.x86_64 +libseccomp-2.5.2-2.el9.x86_64 -libstdc++-11.2.1-9.4.el9.x86_64 +libstdc++-11.2.1-10.el9.x86_64 -libxml2-2.9.12-4.el9.x86_64 +libxml2-2.9.13-1.el9.x86_64 -openblas-openmp-0.3.15-2.el9.x86_64 +openblas-openmp-0.3.15-3.el9.x86_64 -openblas-0.3.15-2.el9.x86_64 -openldap-2.4.59-3.el9.x86_64 -openssl-libs-3.0.1-12.el9.x86_64 -openssl-3.0.1-12.el9.x86_64 +openblas-0.3.15-3.el9.x86_64 +openldap-2.4.59-4.el9.x86_64 +openssl-libs-3.0.1-18.el9.x86_64 +openssl-3.0.1-18.el9.x86_64 -pyproject-rpm-macros-1.0.0~rc1-1.el9.noarch +pyproject-rpm-macros-1.0.1-1.el9.noarch -systemd-libs-250-3.el9.x86_64 +systemd-libs-250-4.el9.x86_64 +systemd-pam-250-4.el9.x86_64 +systemd-rpm-macros-250-4.el9.noarch +systemd-250-4.el9.x86_64 -tpm2-tss-3.0.3-7.el9.x86_64 -zlib-1.2.11-31.el9.x86_64 +zlib-1.2.11-32.el9.x86_64 This seems like my local mock has newer c9s packages than the Koji build repo. Is that expected, or is pulling c9s packages into the build repo stuck on Koji side? Actually, I got an idea that EPEL 9 Koji might already be using (internal?) RHEL 9.0, possibly I have missed this switch... However, the centos-stream-release package contraditcs taht idea :/ I've checked with an EPEL 9 Next Koji scratchbuild and it got e.g. pyproject-rpm-macros-1.0.1-1.el9. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Missing RHEL 9 buildroot packages in EPEL 9 buildroot
On 11. 03. 22 10:36, Richard W.M. Jones wrote: On Fri, Mar 04, 2022 at 11:14:31AM +, Richard W.M. Jones wrote: On Fri, Mar 04, 2022 at 11:01:20AM +, Richard W.M. Jones wrote: On Fri, Mar 04, 2022 at 10:51:48AM +, Richard W.M. Jones wrote: I'll see if we can move the OCaml packages to CRB. It seems to be the easiest way to fix the original coccinelle build problem. This gets odder. I see from our internal spreadsheet and downloads that some of the ocaml packages are in fact already in CRB for RHEL 9.0, and others are not. We previously requested that all ocaml-* packages be added to CRB. Binary packages which are not in CRB but should be: ocaml-calendar* ocaml-camomile* ocaml-csexp* ocaml-csv* ocaml-curses* ocaml-dune* ocaml-fileutils* ocaml-gettext* ocaml-libvirt* ocaml-source ocaml-xml-light* Do you need a BZ opened to move these packages to CRB? https://bugzilla.redhat.com/show_bug.cgi?id=2060850 Currently even with this bug fixed we won't be able to build Coccinelle until RHEL 9.1 is released, which is like 9+ months away. This (if true) is ridiculous. Is there some other solution? Given that EPEL 9 now builds against CentOS Stream, this is not necessarily true. The other solution would have been to include the packages in CRB sooner :D -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Does EPEL 9 maintain upgrade path from EPEL 8?
Hello, I have a Fedora package that I've recently also branched for EPEL 9. The (so called) binary package used to be called "python3-tox", but has been renamed to "tox" in Fedora 34. All supported Fedora versions and EPEL 9 have the package named as "tox". The package has: %py_providespython3-tox # Remove this once Fedora 36 goes EOL: Obsoletes: python3-tox < 3.24.4-2 However, the EPEL 8 package is still called python3-tox. Once I remove the Obsoletes line from Fedora, should I worry about merging that commit to the epel9 branch or not? Logic dictates that the Obsolete should remain in EPEL 9 forever, but I wonder if there is a policy/rule of thumb. E.g. in Fedora, we only support upgrades to Fedora N+2. Do we support upgrades of EL+EPEL systems as well and how "far"? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9
On 17. 02. 22 13:52, Stephen John Smoogen wrote: On Thu, 17 Feb 2022 at 07:11, Miro Hrončok <mailto:mhron...@redhat.com>> wrote: Hello EPEL packagers. I get it that you want as much as possible packages available in EPEL 9, but before you blindly branch all the dependencies of the packages you care about, could you maybe take a step back and consider for a few minutes if all the dependencies actually make sense? The dependency might be a leftover from long time ago and might not be actually needed. Get rid of it in Fedora instead of keeping it that way on EPEL 9. The dependency might be optional (e.g. it is only BuildRequired to test integration with that thing). Do you really need to add a package to EPEL 9 just because your package tests that it can interact with it if it is present? The working assumption has been that the Fedora package is already cleaned up and dependencies are there because the main packager thought they were needed. That is however not the reality. In reality, a Fedora package has an unknown quality. It has historical baggage. The miantainer who added that dependency has left 12 years ago. In my opinion, the EPEL packager should inspect the package they want to branch and improve both Fedora and EPEL by getting it in a better shape. I see now that you've been yelled at in the past for doing that (that is a new information to me) so I understand why you would not want to do that again. See my next replies. I and other EPEL packagers have spent enough time 'cleaning up' a package and then getting yelled at by the main packager that I broke something important and they wanted me to not touch their package anymore. [Heck we have caused a couple of people to quit Fedora completely over the years because of this.] In the past we didn't have pull requests. I don't propose the EPEL maintainers go and change Fedora packages freely. I propose they suggest changes. And if the Fedora maintainers are not interested, they can just make those changes in EPEL branches only. Furthermore, some changes are not suitable for Fedora but might be suitable for EPEL. IMHO we must understand that some maintainers might not want an %if-%rhel conditional to be pushed to a Fedora branch by the EPEL maintainer. That however does not mean the change cannot be done in EPEL only to avoid an unwanted dependency. See for example this PR: https://src.fedoraproject.org/rpms/python-django/pull-request/24 The EPEL maintainer suggested to drop dependencies that are not needed. It turned out that it would skip a bunch of tests that we don't want to skip in Fedora. Had the EPEL maintainer pushed this change directly, the Fedora maintainers would be perfectly OK to tell them this was not OK. Instead, they used a pull request, received feedback and only done the changes in EPEL. Everybody is happy. Due to that, we usually err on if the upstream SIG or packager has put the package dependency in, they know what they are doing and we are just going to cause another round of 'EPEL is breaking our distro' threads if we do otherwise. Heck just getting the package into EPEL from many groups is on the promise that WE DON'T MAKE CHANGES to their spec file. So while I understand where you are coming from, we are also not in a position to know when we can do this and when we can't. My opinion? It is always OK to suggest changes. It is never OK to push nontrivial changes without giving Fedora maintainers chance for a review (unless we enjoy being yelled at). Finally. There is NO PROMISE that we are putting these packages in for 10 years. We have said this over and over again for the last 4 years, but it comes up like a bad penny. Packages that are not useful and are not to be maintained CAN and WILL be retired. We just need guidance versus pissed off emails. But packages that are not useful are being imported, built and left to rot. Why bother retiring them later if we don't bother not adding them in the first place? In other words, retiring the packages requires somebody to do exactly what I am asking here: Taking a moment to reconsider a dependency. I'm just asking everybody to do it now because I know from experience, that it will probably not happen later. The packages will be in EPEL forever, despite not being useful. The package might be deprecated in Fedora and used just because nobody got the time to do a trivial removal of the dependency. Try removing it or poke the Fedora maintainer to do it, before you blindly include that tech debt to EPEL 9. (E.g. I'd be happy to help you remove any python-mock or python-nose dependency.) I realize that analyzing the dependencies is tedious and boring. But please do us all a favor and invest couple minutes of your time *before* you open that bugzilla EPEL 9 request or branch that package. If you are not able to donate
[EPEL-devel] Plea: Take a moment before you branch everything for EPEL 9
Hello EPEL packagers. I get it that you want as much as possible packages available in EPEL 9, but before you blindly branch all the dependencies of the packages you care about, could you maybe take a step back and consider for a few minutes if all the dependencies actually make sense? The dependency might be a leftover from long time ago and might not be actually needed. Get rid of it in Fedora instead of keeping it that way on EPEL 9. The dependency might be optional (e.g. it is only BuildRequired to test integration with that thing). Do you really need to add a package to EPEL 9 just because your package tests that it can interact with it if it is present? The package might be deprecated in Fedora and used just because nobody got the time to do a trivial removal of the dependency. Try removing it or poke the Fedora maintainer to do it, before you blindly include that tech debt to EPEL 9. (E.g. I'd be happy to help you remove any python-mock or python-nose dependency.) I realize that analyzing the dependencies is tedious and boring. But please do us all a favor and invest couple minutes of your time *before* you open that bugzilla EPEL 9 request or branch that package. If you are not able to donate couple minutes of your time to the package now, will you be able to take care of the dozens packages you've just imported in the next ten years? Thanks for listening, I'll show myself 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] pyproject-rpm-macros 1.0.0~rc1 available in EPEL 9 buildroot
Hello Pythonistats, just letting you know that as of today, I can finally see pyproject-rpm-macros-1.0.0~rc1-1.el9.noarch in the EPEL 9 Koji buildroot. That means, the %pyproject_* macros should now have identical features and behavior across Fedora and EPEL 9. Happy packaging, -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Removing playground from package.cfg files
On 28. 01. 22 3:37, Troy Dawson wrote: On Wed, Jan 26, 2022 at 7:54 AM Troy Dawson <mailto:tdaw...@redhat.com>> wrote: On Wed, Jan 26, 2022 at 7:37 AM Miro Hrončok mailto:mhron...@redhat.com>> wrote: On 26. 01. 22 16:30, Troy Dawson wrote: > EPEL 8 Playground is going away. > One of the steps in that process [1] is to clean out playground from all the > various package.cfg files. > I will not be removing the package.cfg files. I will only remove > epel8-playground entry if it is there. If you, as a package maintainer, want > to remove the package.cfg file, you are free to do so. > I have seen too many package.cfg files that have been modified, and I do not > feel safe globally removing them. > > Note: I will be checking the epel8, epel9, rawhide and f35 branches for > package.cfg files. > > This will be happening later today. Let me know if you have any concerns > and/or comments. Hey Troy. Could you please share the list for inspection before actually changing anything? I can, and will. Good idea. It will be a couple hours before I have that list. Troy That took longer than expected. Sorry about that. I know I said that I was only going to take the epel8-playground out of the files, but it turned out that there were so many that only have the default package.cfg that we put in, that I feel we should take all those default files out. There was three groups. ** A - Custom package.cfg * I will only remove epel8-playground argbash (custom) rawhide f35 nss-mdns (custom) f35 RBTools (custom) rawhide f35 ** B - Default epel8 package.cfg - in Rawhide and F35 * I am going to remove the package.cfg from rawhide and f35 beanstalk-client (default) rawhide f35 copr-selinux (default) rawhide f35 czmq (default) rawhide f35 fctxpd (default) rawhide f35 gedit-plugin-editorconfig (default) f35 glances (default) rawhide f35 gnome-doc-utils (default) rawhide f35 libwebsockets (default) rawhide f35 MUMPS (default) f35 netcdf4-python (default) rawhide f35 opentrep (default) rawhide f35 python-astroid (default) rawhide f35 python-cftime (default) rawhide f35 python-kubernetes (default) rawhide f35 python-lazy-object-proxy (default) rawhide f35 python-multidict (default) rawhide f35 python-repoze-tm2 (default) rawhide f35 python-repoze-who (default) rawhide f35 python-transaction (default) rawhide f35 R (default) f35 sagator (default) f35 TurboGears2 (default) rawhide f35 ... Let me know if anyone disagrees with my plan. Thank You! Looking for example at python-astroid where your plan is to remove it from f35 and rawhide but not from f34. The f35 and rawhide branches are not in sync but f35 is "reachable" from rawhide history. Do we really need to diverge f35 just to remove a file that we are OK keeping on f34? Looking at python-astroid in Koji: https://koji.fedoraproject.org/koji/packageinfo?packageID=16809 It doesn't seem this was submitted regularly for many targets. The file has: [koji] targets = epel8 epel8-playground Yet when I run `fedpkg build` on rawhide, it only submits a build for rawhide. Similarly on f35, it only submits a build for f35. When I run `$ fedpkg --release=epel8 build` it submits 2 builds, so it indeed does at least something. The dangerousnes of this is... minimal? Considering the Koji target will be blocked. Hence I propose to only remove the file from f35 if the branch has the same HEAD as rawhide, but not to remove it otherwise to avoid git mess. Similarly, I would also remove it from f34 in such case. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] EPEL 9: Interested in fails to install reports?
Hello EPEL, would you be interested in automated bugzilla reports for EPEL 9 packages that fail to install in the buildroot? Or is it too soon? When testing upcoming changes in c9s we have found out some packages (e.g. ansible-lint) were imported and built in epel9 but they miss runtime dependencies (and requests for them don't even exists in bugzilla). The automated bugzillas could be used to mark blocking the eple9 package requests and generally help track things better. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Removing playground from package.cfg files
On 26. 01. 22 16:30, Troy Dawson wrote: EPEL 8 Playground is going away. One of the steps in that process [1] is to clean out playground from all the various package.cfg files. I will not be removing the package.cfg files. I will only remove epel8-playground entry if it is there. If you, as a package maintainer, want to remove the package.cfg file, you are free to do so. I have seen too many package.cfg files that have been modified, and I do not feel safe globally removing them. Note: I will be checking the epel8, epel9, rawhide and f35 branches for package.cfg files. This will be happening later today. Let me know if you have any concerns and/or comments. Hey Troy. Could you please share the list for inspection before actually changing anything? 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 16. 01. 22 12:49, Andrew C Aitchison wrote: On Sun, 16 Jan 2022, Miro Hrončok wrote: On 15. 01. 22 20:22, Andrew C Aitchison wrote: On Sat, 15 Jan 2022, Miro Hrončok wrote: python-pytest-cov is something I've lobbied has no business in an enterprise distro at all. ... ... As for EPEL I strongly suggest not to introduce python-pytest-cov either. If your package depends on it, please drop the dependency instead, see https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters In %check, packages SHOULD NOT run “linters”: code style checkers, test coverage checkers and other tools that check code quality rather than functionality. Agreed. Linters do make sense in upstream CI. But not in Fedora. Not inside Fedora *packages*, but if these tools are not available to those using RHEL, Fedora or EPEL is that a suitable platform for CI or for developers ? Yes, most certainly it is a sustainable *platform* for CI. On such platform, you install your dev-dependendencies from PyPI. Not from the platform itself. Hmm. A linter is a tool. I cannot build most packages without a C compiler and I don't see many packages with BuildRequires: gcc yet I expect a dev platform to include a C compiler. I do expect a dev platform to include a C compiler as well. I also expect it includes Python interpreter and a tool to install Python packages. I *do not* except it to include every dev-usefull Python package however. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 15. 01. 22 18:41, Orion Poplawski wrote: I was also confused about two things here: - It's retired on the "main" branch, but the c9s branch seems intact. Indeed, that is how this was done for many (all?) retired c9s packages. I believe this is confusing. - What does "retired for CS-569" mean? "CS-569" is a reference for an internal ticket. I believe this is not transparent. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 15. 01. 22 21:42, Orion Poplawski wrote: On 1/15/22 12:22, Andrew C Aitchison wrote: On Sat, 15 Jan 2022, Miro Hrončok wrote: python-pytest-cov is something I've lobbied has no business in an enterprise distro at all. ... ... As for EPEL I strongly suggest not to introduce python-pytest-cov either. If your package depends on it, please drop the dependency instead, see https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters In %check, packages SHOULD NOT run “linters”: code style checkers, test coverage checkers and other tools that check code quality rather than functionality. Agreed. Linters do make sense in upstream CI. But not in Fedora. Not inside Fedora *packages*, but if these tools are not available to those using RHEL, Fedora or EPEL is that a suitable platform for CI or for developers ? No, but that's why it will be provided in EPEL :) Yet again, I beg you not 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 15. 01. 22 20:22, Andrew C Aitchison wrote: On Sat, 15 Jan 2022, Miro Hrončok wrote: python-pytest-cov is something I've lobbied has no business in an enterprise distro at all. ... ... As for EPEL I strongly suggest not to introduce python-pytest-cov either. If your package depends on it, please drop the dependency instead, see https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters In %check, packages SHOULD NOT run “linters”: code style checkers, test coverage checkers and other tools that check code quality rather than functionality. Agreed. Linters do make sense in upstream CI. But not in Fedora. Not inside Fedora *packages*, but if these tools are not available to those using RHEL, Fedora or EPEL is that a suitable platform for CI or for developers ? Yes, most certainly it is a sustainable *platform* for CI. On such platform, you install your dev-dependendencies from PyPI. Not from the platform itself. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 15. 01. 22 11:19, Miro Hrončok wrote: As for EPEL I strongly suggest not to introduce python-pytest-cov either. If your package depends on it, please drop the dependency instead, see https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters And this goes without saying: If you have package and need help doing it because it's not trivial, let me know and I'll try to help. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 15. 01. 22 3:45, Orion Poplawski wrote: Others: python-pytest-cov -> python-pyttest-xdist -> python-execnet -> python-gevent -> python-zope-interface -> python-zope-testing python-apipkg https://bugzilla.redhat.com/buglist.cgi?bug_id=2032588_id_type=anddependson=tvp_id=12369805# Thanks. python-pytest-cov is something I've lobbied has no business in an enterprise distro at all. And it was removed. It is not in the Buildroot repo. What you see is a retired package: https://gitlab.com/redhat/centos-stream/rpms/python-pytest-cov/-/commit/a27e0d8b463e23ad7f9827e4bd61c8528114bf5f How do you recognize a package is "in the buildroot"? If you just search on kojihub.stream.centos.org your results are not accurate. As in Fedora, it includes retired packages. As for EPEL I strongly suggest not to introduce python-pytest-cov either. If your package depends on it, please drop the dependency instead, see https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters Recently I came across the python-zope-* packages, e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=2038512 Same story: https://gitlab.com/redhat/centos-stream/rpms/python-zope-testing/-/commit/18bf2416bdaf7f9b8746d56e4a6a4184e3ee0ac1 -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 14. 01. 22 5:11, Orion Poplawski wrote: While working on EPEL9, it seems that even more packages are missing from RHEL9 than were in RHEL8. The latest I found was cppunit, which appears to be completely missing from the CS9 repos despite having been built (See https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and presumably in the CS9/RHEL9 buildroot. So I scraped some screens from pkgs.org: Stream 9: CentOS AppStream Official x86_64 8882 CentOS BaseOS Official x86_64 2357 CentOS CRB Official x86_64 1856 Stream 8: CentOS AppStream Official x86_64 15008 CentOS BaseOS Official x86_64 6721 CentOS PowerTools Official x86_64 3771 That's a pretty big difference. Now, I don't know how many were dropped completely and how many are of the "buildroot only" variety. But I suspect there is a fair amount of the latter and so a lot of make-work ahead of us for EPEL9. Packaging for EPEL9 is starting to feel more and more like cleaning the Augean stables with RedHat piling up more manure. If there is any Python stuff that's in Buildroot only, let me know and I'll do my best to persuade the maintainers to move it to CRB (but my powers are limited). -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL Playground shutting down
On 11. 01. 22 18:51, Troy Dawson wrote: * Steps I didn't think of (possible) EOL all the epel8-playground branches in PDC and block the target in Koji? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: recent failures with "fedpkg mockbuild" for epel8
On 06. 01. 22 15:26, Ken Dreyer wrote: Hi folks, When I run "fedpkg mockbuild" for my epel8 dist-git branches, it fails with the following error: Error: Error downloading packages: Status code: 403 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/audit-libs-3.0-0.17.20191104git1c2f876.el8.x86_64.rpm (IP: 38.145.60.16) I'm using mock-2.16-1.fc34 and fedpkg-1.41-2.fc34 What should I do to mock-build EPEL 8 packages locally with fedpkg? See the discussion here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7d4aaa6fe -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL 9 vs EPEL 9 Next buildroot
On 13. 12. 21 13:37, Miro Hrončok wrote: Hello. Considering that EPEL 9 Next repo is an **additional** repo to EPEL 9 (is that still the case?), should EPEL 9 overrides be visible for EPEL 9 Next builds? They are currently not. Also, consider 2 different builds of package foo: - foo-1.0-1.el9.next in stable EPEL 9 Next - foo-1.0-2.el9 in stable EPEL 9 EPEL 9 Next users will get foo-1.0-2.el9 because it is > foo-1.0-1.el9.next. However, is this also true for the EPEL 9 Next buildroot? As I expected, I've now verified EPEL 9 Next buildroot contains the older 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL 9 is now available
On 15. 12. 21 17:49, Miroslav Suchý wrote: Dne 03. 12. 21 v 19:06 Troy Dawson napsal(a): Instructions to enable the EPEL repository are available in our documentation.[1] If there is a Fedora package you would like to see added to EPEL 9, please let the relevant package maintainer know with a package request.[2] For new builds, should we file an update in Bodhi? Yes. Or it gets to compose automagically? No. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Requesting branches for epel9
On 13. 12. 21 15:25, Miroslav Suchý wrote: Hi. I have two questions regarding epel9: 1) I have requested dozen of epe9 branches for my packages. It was 20+ hours ago. E.g. https://pagure.io/releng/fedora-scm-requests/issue/39402 Is it manual process? Or is the automation broken? The tickets are processed by automated scripts that are run manually by a couple of heroes. This quite unfortunately combines disadvantages of both automated and manual approach: - it takes a long time for requests to be processed - nobody needs to check the requests for sanity A FESCo ticket that touches this topic is https://pagure.io/fesco/issue/2115 2) It was quite pain to go through all my packages and find which ones actually have EPEL version. And which ones are in RHEL9 now... Note that fedpkg request-branch epel9 *should* fail if the component is already present in CentOS Stream 9: [python3.9 (rawhide)]$ fedpkg request-branch epel9 Could not execute request_branch: This package is already an EL package, therefore it cannot be in EPEL. If this is a mistake or you have an exception, please contact the Release Engineering team. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] EPEL 9 vs EPEL 9 Next buildroot
Hello. Considering that EPEL 9 Next repo is an **additional** repo to EPEL 9 (is that still the case?), should EPEL 9 overrides be visible for EPEL 9 Next builds? They are currently not. Also, consider 2 different builds of package foo: - foo-1.0-1.el9.next in stable EPEL 9 Next - foo-1.0-2.el9 in stable EPEL 9 EPEL 9 Next users will get foo-1.0-2.el9 because it is > foo-1.0-1.el9.next. However, is this also true for the EPEL 9 Next buildroot? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Is anyone still using EPEL8 Playground?
On 10. 12. 21 21:12, Troy Dawson wrote: What are other's thoughts about if/when to remove the epel8-playground repo? My thoughts: Sunset the contributing ways for Playground ASAP. Remove the repo with the next RHEL 8.x release. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed
On 22. 11. 21 15:25, Miroslav Suchý wrote: But EPEL is built against RHEL (not Alma, not Rocky). True. As well as it is true today that it is not built against CentOS Linux (and yet we do that in 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL 9 Next Bodhi updates: Set lower days to stable limit?
On 19. 11. 21 17:54, Troy Dawson wrote: On Fri, Nov 19, 2021 at 8:46 AM Stephen John Smoogen <mailto:smo...@gmail.com>> wrote: On Fri, 19 Nov 2021 at 11:42, Miro Hrončok mailto:mhron...@redhat.com>> wrote: > > Hello EPEL people, > > what do you think about setting the Bodhi days to stable limit to 3 days for > EPEL 9 Next (at least until RHEL 9 GA)? > I think EPEL-9 Next being based off of Stream with its major changes should have a small stable limit. 3 days sounds about right. +1 There seem to be a consensus, do I file a ticket at infra, or does the EPSCo need to approve it a meeting? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] EPEL 9 Next Bodhi updates: Set lower days to stable limit?
Hello EPEL people, what do you think about setting the Bodhi days to stable limit to 3 days for EPEL 9 Next (at least until RHEL 9 GA)? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plan for EPEL-9
On 17. 11. 21 19:50, Troy Dawson wrote: I'd say open a ticket. At this point, I don't know what the status is. Some step(s) have not been done. https://pagure.io/fedscm-admin/issue/73 -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plan for EPEL-9
On 17. 11. 21 19:41, Troy Dawson wrote: Looks like not yet. My branch requests are also getting rejected. I see this comment: https://pagure.io/fedscm-admin/pull-request/72#comment-157918 It seems like a release is needed. Should I open a ticket? Or a backport PR to https://src.fedoraproject.org/rpms/fedscm-admin? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plan for EPEL-9
On 09. 11. 21 16:07, Troy Dawson wrote: The people on the rel-eng team that do the branches need to have their fedscm-admin updated with the correct patches. I'm told that should happen today or tomorrow. Did this actually happen? My branch request was closed repeatedly: https://pagure.io/releng/fedora-scm-requests/issue/37456 -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plan for EPEL-9
On 09. 11. 21 16:07, Troy Dawson wrote: If you can get them branched for epel9-next, you can work on them. Currently a fedpkg that understands epel9-next needs to be built. I used this pull request [1] and it worked, at least it requested the branch. The people on the rel-eng team that do the branches need to have their fedscm-admin updated with the correct patches. I'm told that should happen today or tomorrow. If your package is a noarch, and you manage to get it built (koji loves to put srpm builds on s390x), then yes, run it through bodhi and it should do it's normal thing and packages will arrive in the epel9-next-testing, and epel9-next repos I got: DEBUG util.py:444: No match for group package "epel-release" DEBUG util.py:444: No match for group package "epel-rpm-macros" Hence, my package dd not build, because https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2021-341875060f is not yet stable and I'm blocked on https://bugzilla.redhat.com/show_bug.cgi?id=2001034 Other than that, it seems to build fine. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Plan for EPEL-9
On 08. 11. 21 15:56, Troy Dawson wrote: On Mon, Nov 8, 2021 at 3:31 AM Neal Gompa <mailto:ngomp...@gmail.com>> wrote: On Mon, Nov 8, 2021 at 2:18 AM Remi Collet mailto:fed...@famillecollet.com>> wrote: > > As both RHEL-9 Beta and CentOS 9 Stream are available, > what are the plan for EPEL-9 ? > > > I really this should be available ASAP to be > available to our users at GA time. EPEL 9 Next for CentOS Stream 9 is blocked on the migration of our s390x systems to z15[1], because currently all s390x builds fail[2]. Once that's taken care of, we'll launch EPEL 9 Next. [1]: https://pagure.io/fedora-infrastructure/issue/10302 <https://pagure.io/fedora-infrastructure/issue/10302> [2]: https://pagure.io/releng/issue/10360 <https://pagure.io/releng/issue/10360> Our current goal to have epel9-next completely available for maintainers/developers is December 1st. Basically one month after RHEL 9 beta was released. We are hoping to have it available earlier, but as Neal pointed out, we've got a (known) blocker with the build platform. And it's possible that once that get's fixed there might be something else we weren't expecting. So, December 1st is our goal. When it is available, we will announce it on as many channels as we can. Hello Troy. Is preparing specfiles in the epel9-next branches discouraged at this point? Or even shipping noarch packages with no arched EPEL-only deps? Another question I have is the branch structure. Will we start by building from the eple9-next branches and eventually fork them to epel9 branches once EPEL 9 exists as well? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Get BR: %{py3_dist } working on EPEL7
On 07. 10. 21 4:43, Orion Poplawski wrote:
Would it be possible to get BuildRequires: %{py3_dist NAME} working on EPEL7?
At first I thought it was sufficient for epel-rpm-macros to require
python3-rpm-macros, but now I think we may need to override the definition of
py3_dist. In fedora it uses %python3_pkgversion, in RHEL7 it uses
%python3_version, and in RHEL8 "python3dist".
But %python3_version requires python to evaluate.
Presumably we're using %python3_version to allow for multiple python versions,
but I think we've given up on that in single spec files.
The use of %python3_version on RHEL7 was an attempted solution.
https://bugzilla.redhat.com/show_bug.cgi?id=1812665
But since it requires Python to evaluate, it didn't work.
https://bugzilla.redhat.com/show_bug.cgi?id=1812665#c11
I've suggested a new bugreport and than I forgot.
Not however that RHEL 7 is unlikely to get this fixed this late in the RHEL 7
lifetime, we would need to override the macro in 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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On 01. 10. 21 22:11, Troy Dawson wrote: I'll have to file all those "please move these packages into CRB" bugz after RHEL9 is out. I wonder whether we should file those before it is out, if at all possible? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-gevent and pytest-cov in el9
On 24. 09. 21 21:45, Ken Dreyer wrote: This means that python-pytest-cov and python-pytest-xdist won't be available on epel9, since those require gevent. Ignoring the rest of your email for now, but I don't the gevent dependency does not exsist: $ [dnf] install python3-pytest-cov python3-pytest-xdist ... Installed: expat-2.4.1-2.fc35.x86_64 mpdecimal-2.5.1-2.fc35.x86_64 openssl1.1-1:1.1.1l-1.fc36.x86_64 python-pip-wheel-21.2.3-2.fc36.noarch python-setuptools-wheel-57.4.0-1.fc35.noarch python3-3.10.0~rc2-2.fc36.x86_64 python3-attrs-21.2.0-4.fc35.noarch python3-coverage-5.6-0.3b1.fc35.x86_64 python3-execnet-1.9.0-2.fc35.noarch python3-iniconfig-1.1.1-5.fc35.noarch python3-libs-3.10.0~rc2-2.fc36.x86_64 python3-packaging-21.0-2.fc35.noarch python3-pluggy-1.0.0-1.fc36.noarch python3-py-1.10.0-5.fc35.noarch python3-pyparsing-2.4.7-9.fc35.noarch python3-pytest-6.2.5-1.fc36.noarch python3-pytest-cov-2.12.1-1.fc36.noarch python3-pytest-forked-1.3.0-4.fc35.noarch python3-pytest-xdist-2.4.0-1.fc36.noarch python3-setuptools-57.4.0-1.fc35.noarch python3-toml-0.10.2-5.fc35.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: proposed recommendation - missing devel packages
On 23. 09. 21 5:41, Orion Poplawski wrote:
-Requires: %{name}%{?_isa} = %{version}-%{release}
+Requires: utf8proc%{?_isa} >= %{version}-%{release}
I'd assume that anybody (even you) might need to rebuild this package in EPEL
at any time for various reasons and %{release} might be larger than the RHEL
package release. This >= requireement will break.
Also, if the RHEL version gets updated to e.g. 2.1.2 (unlikely, but not
impossible), the EPEL devel package will still be able to be installed, which
is probably undesired.
If you don't need to follow RHEL's release number that much, I suggest to do:
Requires: utf8proc%{?_isa} = %{version}
And if you do, I suggest to do:
%global rhel_release 5
Requires: (utf8proc%{?_isa} = %{version} with utf8proc%{?_isa} >=
%{version}-%{rhel_release})
You could even incorporate the RHEL's release to the EPEL's release, if you
feel like it:
%global rhel_release 5
%global base_release 1
Release: %{rhel_release}.%{base_release}%{?dist}
Side note: I also suggest to BuildRequire the runtime requirement (sans
%{?_isa}) and track the package in Koschei. That way, you can get a
notification if the requirement was broken by an RHEL update and the EPEL
package needs to be updated as well.
--
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: modular bugzilla components
On 24. 08. 21 3:40, Orion Poplawski wrote: Should I create an epel8 branch but then retire it just to create a bugzilla component? AFAIK this wont work. Packages retired on EPEL have the components blocked. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL8 and EPEL7: Introduce %py3_check_import - review needed
On 03. 08. 21 3:49, Kevin Fenzi wrote: Thank you! Both updates now exist: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-dfd462a782 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e3b1cc2b6e I deliberately didn't do the epel8 build because I wanted to wait for: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/33 to get rebased, but ok.;) Ah. Sorry about that. It always confuses me when a PR is merged, who is supposed to do the build and update. I've triggered both builds, but the epel7 one failed (as it was already running by you). -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL8 and EPEL7: Introduce %py3_check_import - review needed
On 03. 08. 21 2:10, Kevin Fenzi wrote: On Tue, Aug 03, 2021 at 01:55:52AM +0200, Miro Hrončok wrote: Hello, I've opened the following two pull requests to introduce %py3_check_import to EPEL8 and EPEL7: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/31 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/32 So far, there has been no response. Is there anybody willing to merge them? They are manually tested, as indicated in the comments. When we introduce new macros to Fedora, I strive to backport them to EPELs if possible, so package maintainers don't need to think "may I use this?" if they desire EPEL compatibility. However, I don't want to merge my own pull requests to epel-rpm-macros (unless they are urgent bug fixes). I can merge them... Thank you! Both updates now exist: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-dfd462a782 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e3b1cc2b6e A meta question: Should the epel-sig group co-maintain the package? They could if desired. I think it is desired. Why wouldn't it be? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] EPEL8 and EPEL7: Introduce %py3_check_import - review needed
Hello, I've opened the following two pull requests to introduce %py3_check_import to EPEL8 and EPEL7: https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/31 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/32 So far, there has been no response. Is there anybody willing to merge them? They are manually tested, as indicated in the comments. When we introduce new macros to Fedora, I strive to backport them to EPELs if possible, so package maintainers don't need to think "may I use this?" if they desire EPEL compatibility. However, I don't want to merge my own pull requests to epel-rpm-macros (unless they are urgent bug fixes). A meta question: Should the epel-sig group co-maintain the package? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)
On 28. 07. 21 1:19, Neal Gompa wrote: 3) In Fedora, various Python interpreters use pip/setuptools/wheel wheels from /usr/share/python-wheels or bundle their own wheel when the "general" ones are too new to work with old Pythons. Given the differences of life cycle of RHEL and Fedora, we plan to use wheels from /usr/share/python3.X-wheels instead (and have the possibility to build newer versions of pip/setuptools/wheel wheels for each newer Python version we introduce to RHEL 9). RHEL 8 already partially does that for Python 3.8+, but in RHEL 9, we want to do this from the beginning. I intent to do the rpm-macros-groundwork for this in Fedora, but we might need to explicitly not make this change in ELN to preserve Rawhide/ELN builds compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1982668 Aren't wheels fully versioned themselves? Why do you need the wheel directory itself to be versioned? (This entire answer applies to pure-python wheels only, which is what we ship anyway.) They include the version of the project, not version of the Python interpreter. They only declare Python 2/3 compatibility in the name: $ ls -1 /usr/share/python-wheels/ pip-20.2.2-py2.py3-none-any.whl setuptools-49.1.3-py3-none-any.whl wheel-0.34.2-py2.py3-none-any.whl -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)
On 27. 07. 21 23:03, Neal Gompa wrote: On Tue, Jul 27, 2021 at 5:09 AM Tomas Orsava wrote: If I understand what you're describing correctly, this is not a bug. In the default state, /usr/bin/python should *not* exist, that's correct behaviour. If you want it to exist, you need to configure it using alternatives [0]. We considered making /usr/bin/python exist but be a noop, but that breaks a lot of automated (build) tools that search for Python executables (they often start with python, if not found search for python3, or python2, etc.). And there was no reasonable default for Python in RHEL 8 because it sits between the past (Python 2 default in RHEL 7) and the future (Python3 default in RHEL 9). Either default would cause problems, often hidden and hard to debug problems, for some subset of our customers. [0] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_configuring-the-unversioned-python_configuring-basic-system-settings But this won't be a problem in RHEL 9, will it? I don't want to suffer through this when we're not even going to have Python 2 in RHEL 9 at all... Not at all. We have reviewed all the RHEL 8 differences from Fedora and how much painful they were/are and decided to play the "if we would not do this in Fedora, we should not do it in RHEL 9 either" card. That includes /usr/bin/python (optionally (un)installable but only one), platform-python (don't), modularity (don't), and other things. Some differences are still planned though, albeit hopefully minor: 1) We plan non-modular parallel-installable Python stacks in RHEL 9, but we don't want to take care of such stacks in Fedora. However, we intent to fully support this case for Fedora's downstreams (not only RHEL: any downstream, e.g. even Copr repos): https://bugzilla.redhat.com/show_bug.cgi?id=1821489 2) We need some upgrade-path compatibility shims from RHEL 8's platform-python that are not needed in Fedora and we plan to include them in RHEL 9 only: https://bugzilla.redhat.com/show_bug.cgi?id=1891487 3) In Fedora, various Python interpreters use pip/setuptools/wheel wheels from /usr/share/python-wheels or bundle their own wheel when the "general" ones are too new to work with old Pythons. Given the differences of life cycle of RHEL and Fedora, we plan to use wheels from /usr/share/python3.X-wheels instead (and have the possibility to build newer versions of pip/setuptools/wheel wheels for each newer Python version we introduce to RHEL 9). RHEL 8 already partially does that for Python 3.8+, but in RHEL 9, we want to do this from the beginning. I intent to do the rpm-macros-groundwork for this in Fedora, but we might need to explicitly not make this change in ELN to preserve Rawhide/ELN builds compatibility. https://bugzilla.redhat.com/show_bug.cgi?id=1982668 Usual disclaimer applies: Those are our plans as engineers, not promises by Red Hat as a company. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)
On 22. 07. 21 23:58, Troy Dawson wrote:
On Thu, Jul 22, 2021 at 2:45 PM Miro Hrončok <mailto:mhron...@redhat.com>> wrote:
On 22. 07. 21 22:33, Troy Dawson wrote:
>
>
> On Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok mailto:mhron...@redhat.com>
> <mailto:mhron...@redhat.com <mailto:mhron...@redhat.com>>> wrote:
>
> On 22. 07. 21 21:47, Miro Hrončok wrote:
> > On 22. 07. 21 21:25, Troy Dawson wrote:
> >> I've been bitten by this yet again. A package needing
/usr/bin/python and
> >> not python2 or python3. And it's way down in the code so it's
hard to
> >> patch. But, it works fine on Fedora.
> >>
> >> Is anyone in the middle of porting python-unversioned-command
over to
> epel8?
> >> If not, does anyone object to me porting it over?
> >
> > I wonder how would that package work?
> >
> > /usr/bin/python is co-owned by several RHEL-proper packages and
managed by
> > alternatives.
>
> I hit "Send" to early, apologies, here is the rest of my email:
>
> Could you please share the package spec file with us (Python Maint
team at Red
> Hat, specifically Tomas Orsava and me) before you actually push it
to EPEL, so
> we get a chance to review it (and maybe test it)?
>
>
> On RHEL 8, if there is something that provides /usr/bin/python I can't
find it,
> nor can dnf.
> I've been running RHEL 8 since 8.0, I'm currently at 8.4 and this is
what I have.
>
> # dnf provides '/usr/bin/python'
> Error: No Matches found
> # ls /usr/bin/python
> ls: cannot access '/usr/bin/python': No such file or directory
> # which python
> /usr/bin/which: no python in
> (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
>
> On Fedora, it's rather simple, just look at the contents of
> python-unversioned-command
> Two files, no scripts or triggers.
>
> # rpm -ql python-unversioned-command
> /usr/bin/python
> /usr/share/man/man1/python.1.gz
> # ls -lh /usr/bin/python
> lrwxrwxrwx. 1 root root 9 May 18 03:48 /usr/bin/python -> ./python3
> # ls -lh /usr/share/man/man1/python.1.gz
> lrwxrwxrwx. 1 root root 14 May 18 03:48
/usr/share/man/man1/python.1.gz ->
> ./python3.1.gz
>
> It looks like it will be very simple spec file.
> I'll probably just cut it out of the Fedora python spec file.
On Fedora, it is simple.
On RHEL 8, it is the opposite of simple.
The /usr/bin/python file is managed by alternatives but it deliberately not
owned by any Python package, so `yum install /usr/bin/python` does not work.
If the /usr/bin/python file is created/changed by the admin (or by a package
copied from Fedora), upon (re)installation or upgrade of python2 or
pytohn3{6,8,9} it will be restored based on the alternatives database.
See the %post sctriplets of the mentioned packages.
Ugg ... no wonder nobody has done this yet.
But, is that working right. It looks like it should be making a
/usr/bin/python pointing to unversioned-python but I don't have any of that.
I'm not an Alternatives expert.
I guess what I'm really asking is if this is a bug or not?
I don't have a /usr/bin/python
I do have a /usr/bin/unversioned-python
But, what good is that, nothing calls "unversioned-python"
Should I open a bug on this? Or continue with my plan of making a fix via a
package?
I am not entirely sure I understand the bug you are describing.
--
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)
On 22. 07. 21 22:33, Troy Dawson wrote:
On Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok <mailto:mhron...@redhat.com>> wrote:
On 22. 07. 21 21:47, Miro Hrončok wrote:
> On 22. 07. 21 21:25, Troy Dawson wrote:
>> I've been bitten by this yet again. A package needing /usr/bin/python
and
>> not python2 or python3. And it's way down in the code so it's hard to
>> patch. But, it works fine on Fedora.
>>
>> Is anyone in the middle of porting python-unversioned-command over to
epel8?
>> If not, does anyone object to me porting it over?
>
> I wonder how would that package work?
>
> /usr/bin/python is co-owned by several RHEL-proper packages and managed
by
> alternatives.
I hit "Send" to early, apologies, here is the rest of my email:
Could you please share the package spec file with us (Python Maint team at
Red
Hat, specifically Tomas Orsava and me) before you actually push it to EPEL,
so
we get a chance to review it (and maybe test it)?
On RHEL 8, if there is something that provides /usr/bin/python I can't find it,
nor can dnf.
I've been running RHEL 8 since 8.0, I'm currently at 8.4 and this is what I
have.
# dnf provides '/usr/bin/python'
Error: No Matches found
# ls /usr/bin/python
ls: cannot access '/usr/bin/python': No such file or directory
# which python
/usr/bin/which: no python in
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin)
On Fedora, it's rather simple, just look at the contents of
python-unversioned-command
Two files, no scripts or triggers.
# rpm -ql python-unversioned-command
/usr/bin/python
/usr/share/man/man1/python.1.gz
# ls -lh /usr/bin/python
lrwxrwxrwx. 1 root root 9 May 18 03:48 /usr/bin/python -> ./python3
# ls -lh /usr/share/man/man1/python.1.gz
lrwxrwxrwx. 1 root root 14 May 18 03:48 /usr/share/man/man1/python.1.gz ->
./python3.1.gz
It looks like it will be very simple spec file.
I'll probably just cut it out of the Fedora python spec file.
On Fedora, it is simple.
On RHEL 8, it is the opposite of simple.
The /usr/bin/python file is managed by alternatives but it deliberately not
owned by any Python package, so `yum install /usr/bin/python` does not work.
If the /usr/bin/python file is created/changed by the admin (or by a package
copied from Fedora), upon (re)installation or upgrade of python2 or
pytohn3{6,8,9} it will be restored based on the alternatives database.
See the %post sctriplets of the mentioned packages.
--
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)
On 22. 07. 21 21:47, Miro Hrončok wrote: On 22. 07. 21 21:25, Troy Dawson wrote: I've been bitten by this yet again. A package needing /usr/bin/python and not python2 or python3. And it's way down in the code so it's hard to patch. But, it works fine on Fedora. Is anyone in the middle of porting python-unversioned-command over to epel8? If not, does anyone object to me porting it over? I wonder how would that package work? /usr/bin/python is co-owned by several RHEL-proper packages and managed by alternatives. I hit "Send" to early, apologies, here is the rest of my email: Could you please share the package spec file with us (Python Maint team at Red Hat, specifically Tomas Orsava and me) before you actually push it to EPEL, so we get a chance to review it (and maybe 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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)
On 22. 07. 21 21:25, Troy Dawson wrote: I've been bitten by this yet again. A package needing /usr/bin/python and not python2 or python3. And it's way down in the code so it's hard to patch. But, it works fine on Fedora. Is anyone in the middle of porting python-unversioned-command over to epel8? If not, does anyone object to me porting it over? I wonder how would that package work? /usr/bin/python is co-owned by several RHEL-proper packages and managed by alternatives. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Planning for EPEL9
On 08. 07. 21 2:28, Mohan Boddu wrote: Also, people who wish to opt out of this mass rebuild can add 'noautobuild' file to the epel9-next branch beforehand, this however does not stop from creating the epel9 branch, just the package won't be included in the rebuild. I think there are 3 possible opt outs here: 1) The epel9-next packager does not intent to maintain the package in epel9, only in epel9-next. While we might not like this goes, as long as there is no policy against this approach, always creating the branch will create work for the packager they have not signed for. I think there should be an opt out for branching as well. 2) The epel9-next packager does intent to maintain the package in epel9, however the commits in the epel9-next branch already contain stuff that is necessary for c9s but doe snot work with RHEL 9.0. They want to branch for epel9, but from an earlier commit, so they don't need to revert and eventually unrevert later. (Yes, I know they could potentially build from an older commit, but that's not very transparent and many packagers don't do that.) I think there should be an opt out for branching with all the comits as well (i.e. opt in to create the epel9 branch empty). 3) The epel9-next packager does intent to maintain the package in epel9, all the commits are fine, but they intent to do manual bootstrapping themselves. I agree there should be an opt out for automatically rebuilding the package. However, I don't think the noautobuild file in git is ideal. At this point of EL 9 life cycle, many packagers are likely to at least attempt to maintain Fedora and EPEL 9 packages from identical branches. By requiring to add an EPEL 9 specific file, we put them in a bad position. They would essentially be forced to pick the least bad solution: a) divert the branches like they did for the package.cfg file in epel8¹ b) put the file to Fedora branches, essentially disabling mass rebuilds c) not opt out from building and deal with the rebuilds later by release bumps And I think all three options either generate unnecessary work or have other consequences. ¹ IIRC this was a huge 陵 for packagers trying to use a single branch for Fedora and EPEL 8. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: missing rhel devel packages - another proposal
On 23. 06. 21 0:31, Kevin Fenzi wrote: Outside of that on the technical side... if these are from stream they might not always work for base epel would they? I think that if we don't download the latest version from Stream, but the build with the corresponding epoch:version-release to the RHEL package instead, it should work. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python39 in EPEL7
On 07. 04. 21 4:50, Carl George wrote: What do you mean by support? The only thing EPEL supports (using the term loosely) is enabling Fedora packagers to branch and build their packages for EPEL. Any maintainer of the Fedora python3.9 package (or any related package necessary for bootstrapping) can request an epel7 branch and start building. The main thing to be aware of is to comply with EPEL policy [0], especially the part about not replacing/disturbing the base distribution. RHEL7 includes python3, so an epel7 python3.9 build would need to ensure it doesn't conflict with any filesystem paths from that package. I believe the confusion is my fault. By "support" I've meant: Does EPEL-devel generally agree that adding Python 3.9 to EPEL 7 is a good idea, even if we don't phase out Python 3.4 at the same time? E.g. building RPMs for Python 3.9 in EPEL would require redefining %__python3 (or %__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://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Proposal: EPEL9 timeline
On 10. 02. 21 20:24, Stephen John Smoogen wrote: On Wed, 10 Feb 2021 at 14:19, Miro Hrončok <mailto:mhron...@redhat.com>> wrote: On 10. 02. 21 19:53, Stephen John Smoogen wrote: > fedpkg-minimal > epel-release > epel-rpm-macros Those make perfect sense to me. > fedpkg > koji > bodhi But I don't understand why those are required. What am I missing? A lot of EPEL developers do their development on an EL system and use the base tools to do so. That needs fedpkg to be on that system to talk to koji/bodhi and a host of other items. In order to get fedpkg to do that you end up needing parts of koji and bodhi because of library needs. That requires the yak train. Oh, so this is only needed to make EPEL "self hosting" in a sense. So packagers can contribute to EPEL 9 from an EL 9 system. I agree that this is a valuable goal, but should this be an essential part of the initial "bootstrap"? I'm asking because I know that yak train has a lot of packages, including some deprecated that I maintain in Fedora. So I'd rather see a real maintainer deciding to package e.g. python-nose or python-mock for EPEL 9, than a SIG member who is more likely to import/build it once and move on. -- 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: Proposal: EPEL9 timeline
On 10. 02. 21 19:53, Stephen John Smoogen wrote: fedpkg-minimal epel-release epel-rpm-macros Those make perfect sense to me. fedpkg koji bodhi But I don't understand why those are required. What am I missing? -- 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: Proposal: EPEL9 timeline
On 08. 02. 21 14:19, Stephen John Smoogen wrote: There is a little nuance here. In order to get the repository going, we had to 'mass-branch' about 40 or so packages. fedpkg and some other items require quite a few packages which all have to be done at once. Without those you can't build anything else to put into EPEL... so I would say that EPEL is the specific set of packages in order to get a minimal repository working in the Fedora Build System. Everything else is just extras people add to it. Is this needed to allow building EPEL 9 packages from RHEL 9 system? Should that indeed be the minimal requirement? Because AFAIK we don't need fedpkg in EPEL 9 to build packages in mock/koji, just fedpkg-minimal, epel-release and epel-rpm-macros (+ eventually other epel packages required by that one, but I imagine that to be zero at the start). -- 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 request access for EPEL-only package which existed in Fedora previously?
On 05. 02. 21 10:11, Felix Schwarz wrote: Hi, I created a review request for python3-configobj which is needed to update certbot in EPEL 7. (certbot now only supports Python 3). The python3-configobj repo was used in Fedora (in ancient history) but I think it can be "reused" to provide an EPEL7-only package. Now my review request was successful [1] and I need to use "fedpkg request-repo" to request a new repo. [2] says: > Simply go through the review process for Fedora and specify only EL targets for the initial import. How would I do that? I tried to request access without any extra arguments [3] but that only caused confusion I think. Open an unretirement releng ticket: https://pagure.io/releng/new_issue?template=package_unretirement In "Branches that you need it to be unretired for?" say 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 whats version of RHEL will follow
On 03. 02. 21 12:58, Miro Hrončok wrote: On 03. 02. 21 12:14, john tatt wrote: Hi So if I understand well, an EPEL package could be have to be desinstalled just because an update in Stream make it not compatible any more ? No. Apologies, I've misread your email and I've mistaken "desinstalled" for "removed from EPEL repos". Disregard 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://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 whats version of RHEL will follow
On 03. 02. 21 12:14, john tatt wrote: Hi So if I understand well, an EPEL package could be have to be desinstalled just because an update in Stream make it not compatible any more ? No. -- 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 contacting EPEL maintainers when package goes into RHEL
On 20. 01. 21 15:27, Troy Dawson wrote:
This last week in the EPEL Steering Committee meeting, we talked about
what happens when an EPEL package gets pulled in and released in RHEL.
There were a couple of people who said that had happened to them and
they were totally un-aware that it was going to happen.
I contacted a couple people in Red Hat and found out that part of the
New Package procedure includes an EPEL check. If the package is in
EPEL they are supposed to contact the EPEL maintainer. They are also
supposed to have the NVR higher than the EPEL version.
This is a new procedure, implemented in June 2020.
If you are a EPEL package maintainer, and your package was pulled into
RHEL 7 or 8, and you were not contacted, please let me know. Red Hat
wants this procedure to work, because when things go wrong, it affects
their customers.
Their current way of finding out who to contact is to do the following
curl https://src.fedoraproject.org/_dg/bzoverrides/rpms/
example
$ curl https://src.fedoraproject.org/_dg/bzoverrides/rpms/git-lfs
{
"epel_assignee": "carlwgeorge",
"fedora_assignee": "qulogic"
}
If anyone knows of a better way to find the EPEL maintainer, please
let me know and I'll pass it on.
Apparently, the EPEL maintainer receives an automated message like this:
This is an email notification that the new package: pybind11 is being
added to RHEL 8.4.0 and also exists in EPEL 8. You may want to remove
pybind11 from EPEL 8 or at least confirm that the pybind11
Version-Release will cleanly upgrade from and replace the EPEL package.
This also happens when the package is only added to a modular non-default
stream. Is there a way the message could be adapted to:
- discourage immediate retirement (RHEL 8.4 is not yet out, also CentOS Linux)
- mention that removal is not always desired (especially with modular packages)
?
--
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: EPEL7 python3/python36 standardization
On 22. 01. 21 19:29, Andrew C Aitchison wrote: Sorry, I should have said Requires: python >= 36 or Requires: python >= 3.6 Neither would work, as nothing provides "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: EPEL7 python3/python36 standardization
On 21. 01. 21 21:38, Carl George wrote:
I had originally hoped to limit this guideline change to EPEL7's
python36 packages, not EPEL7's python34 packages or anything about
EPEL8. But I do see the appeal of taking it a step further to lay out
the guidelines for all EPEL python packages. The overall intent is to
have EPEL python package prefixes match the RHEL python stack they are
intended to work with. That means the recommended prefixes for EPEL7
would be python and python3. The recommended prefixes for EPEL8 would
be python2, python3, and python38.
Well, technically, to match RHEL7's prefixes, python- is Python 2. But I'd
rather keep it explicitly python2-, as Carl suggests.
EPEL7: python2-, python3-, python34- (but recommend not building for 3.4)
EPEL8: python2-, python3-, python38- (but recommend not building for 2.7)
EPEL 8 note: We could possibly override %python_provide/%py_provides to provide
python36- for pytohn3- and vice versa. In RHEL proper, this does AFAIK not
happen, but it might, if EPEL representatives speak up in this bugzilla about
macro backports (really quickly, pull request is on review):
https://bugzilla.redhat.com/show_bug.cgi?id=1892797
Regarding EPEL7's python34 packages, all the changes discussed here
can take place without modifying the
python%{python3_other_pkgversion}- (python34-)
subpackages. EPEL7's python34 packages should just be retired as that
Python version is EOL upstream, but so far no one (myself included)
has stepped up to drive that effort. I don't know if it's worth the
effort, as surely some will complain about it being removed,
regardless of the upstream status.
We still have a couple years with EPEL 7, it is most likely worth the effort.
Any security fix now has to be backported from 3.6 as 3.5 is also EOL, and with
time, this will only get worse.
As always, if we keep Python 3.4 in EPEL7, work is needed. See e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=1918176 (high severity CVE)
https://bugzilla.redhat.com/show_bug.cgi?id=1765139 (medium severity CVE)
https://bugzilla.redhat.com/show_bug.cgi?id=1763231 (medium severity CVE)
I think a tracker bug would only be necessary if we made the prefix
recommendations a MUST. As a SHOULD, it would be fine to let packages
get corrected naturally over time. The important piece would be to
have the guideline in place for package reviews to reference, to
prevent any further packages using non-standard prefixes from being
added.
I agree. Not worth mass changing the packages for the prefix. Possibly together
with python34- package removal.
--
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: EPEL7 python3/python36 standardization
On 21. 01. 21 7:19, Carl George wrote: I propose that we standardize on the python3 prefix to match RHEL7 packages and document in EPEL guidelines that maintainers SHOULD use the python3 prefix. I'm fine with that, is we also say they MUST use %python_provide (or that the packages MUST provide/obsolete python36-...). -- 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} no defined in epel-7-aarch64?
On 04. 01. 21 18:38, José Abílio Matos wrote:
I have used copr to build the first alpha release of lyx-2.4:
https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/
<https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/>
For EPEL7 it build for x86_64 and it fails for aarch64, due to %{python3} not
being defined.
The spec file has BR: python3-devel.
In the install stage I have this:
%py_byte_compile %{python3} %{buildroot}%{_datadir}/%{name}/lyx2lyx
This fails in epel-7-aarch64...
Is this known?
Yes. The macro was added to EPEL 7 only after aarch64 was discontinued there:
https://lists.fedoraproject.org/archives/list/epel-annou...@lists.fedoraproject.org/thread/YVLZGTBBW2M3GMXHLIA2QMKENBEGPEJY/
No easy way to solve this except to stop building for aarch64 on EPEL 7. You
could use the %__python3 macro instead to workaround this particular problem,
but you will most likely hit another one later.
I wonder whether Copr should disable EPEL 7 aarch64 chroots or at least put a
big red sign next to 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: Disabling Python Dependency Generator Challenges
On 22. 12. 20 17:01, Georg Sauthoff wrote: Ok, I'll try to work-around this by either disabling the generator like you suggested or by patching the setup.py INSTALL_REQUIRES. Modifing setup.py INSTALL_REQUIRES is the preferred solution. In case other different dependencies are added, they can be easily left out if the generator is disabled. -- 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
