[EPEL-devel] A coordinated plan for ansible-collection updates in EPEL?
So, I'm wondering if we should have some kind of (at least semi-)coordinated plan for updating ansible collections in EPEL? My initial thought is we would sort of piggy back on to what the "ansible" community collection bundles on top of the ansible-core package provided by RedHat. So, currently in EL8.7 we have: ansible-core-2.13.3 and EPEL ships: ansible-6.3.0 - which corresponds to the ansible community package that ships with ansible-2.13.3. Then we would endeavor to ship the individual package collection versions that are contained in that package, .e.g: (taken from the MANIFEST.json files): ansible.posix 1.4.0 ansible.utils 2.6.1 chocolatey.chocolatey 1.3.0 community.docker 2.7.1 community.general 5.5.0 community.libvirt 1.2.0 community.mysql 3.4.0 community.rabbitmq 1.2.2 containers.podman 1.9.4 netbox.netbox 3.7.1 For reference, currently in epel we have: ansible-collection-ansible-posix.noarch 1.4.0-1.el8 epel ansible-collection-ansible-utils.noarch 2.6.1-1.el8 epel ansible-collection-chocolatey-chocolatey.noarch 1.4.0-1.el8 epel ansible-collection-community-docker.noarch 2.6.0-1.el8 epel ansible-collection-community-general.noarch 3.8.9-1.el8 epel ansible-collection-community-libvirt.noarch 1.1.0-3.el8 epel ansible-collection-community-mysql.noarch 3.5.1-1.el8 epel ansible-collection-community-rabbitmq.noarch1.2.3-1.el8 epel ansible-collection-containers-podman.noarch 1.10.1-1.el8epel ansible-collection-netbox-netbox.noarch 3.7.1-1.el8 epel However, it's hard for me to resist the allure of the shiny and new, so I've updated chocolatey. Similarly some others have been updated to later versions. The other interesting case here is community.general - ansible has it at 5.5.0, but it looks like Maxwell G has taken the generally preferred course for EPEL of sticking with the stable release track of 3.X. Although I suspect very few collections maintain multiple release tracks (no idea). I don't really have a particular agenda here, just trying to solicit people's thoughts. Personally I like minimal installs so I have been only using ansible-core + collections on the systems I maintain and would like to continue to see them be usable together. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ 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: python3-qt5-webkit for EPEL 8
On Sun, 2023-01-29 at 10:26 -0700, Orion Poplawski wrote: > The python-qt5 package in RHEL 8 does not ship the webkit package. > I'm > assuming that this is unlikely to be changed since qt5-qtwebkit isn't > in > RHEL but is in EPEL. > > I think I'm close to producing a python-qt5-epel package here [1] > that > produces python3-qt5-webkit and would love to hear from people more > familiar with the package if this seems like it's > reasonable/workable. > Hi, I got a similar problem with smtube , all distros are starting dropping qt5-webkit and the natural replacement is qtwebengine . https://github.com/smplayer-dev/smtube/issues/7 https://fedoraproject.org/wiki/User:Smani/QtwebkitRemoval > I think we're depending on the fact that the RHEL python3-qt5-devel > package does ship the WebKit sip files and that these would match up > with what this package ships. > > It also just seems like webengine isn't in there, or I'm missing > what's > needed to build it. I also don't need it for my purposes. > > [1] - https://copr.fedorainfracloud.org/coprs/orion/python-qt5-epel/ > > > ___ > 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 -- Sérgio M. B. ___ 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
