[EPEL-devel] Re: EPEL 10 status update
On 8/10/24 16:41, Carl George wrote: > What has not been completed yet: > > - publish the epel/10 repo Do we have an ETA for an EPEL10 compose (if only in koji)? Thanks! -- Orion Poplawski he/him/his - surely the least important thing about me Manager of IT Systems 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 10 status update
I just built fail2ban and it generated a bunch of comments on various fail2ban bugs, e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=2217649 Why? On 8/10/24 16:41, Carl George wrote: Hey Orion, I planned to send a status update following the hackfest, but I didn't think about the confusion that would be caused for packagers not at the hackfest who were getting branch requests. Sorry about that. I just posted a summary on the discussion thread. I'll include it below as well. --- The EPEL 10 hackfest at Flock took place yesterday. We were able to get enough of the infrastructure working prior to the hackfest to enable packagers in attendance to do a controlled trial run building packages. This also resulted in a few branch request bugzillas for dependencies, which I realize in hindsight was confusing for packagers not at the hackfest. I apologize for not setting that expectation ahead of time. Here is a summary of what is and isn't working at this point. What works: - creating epel10 branches (`fedpkg request-branch epel10`) - pushing commits to epel10 branches - pull requests to epel10 branches - Fedora CI scratch builds for epel10 pull requests - creating epel10.0 builds from epel10 branches (`fedpkg build` from an epel10 branch) - automatic bodhi updates, similar to rawhide What has not been completed yet: - publish the epel/10 repo - mirror the epel/10 repo - create epel-release for epel10 - epel10 configs in mock-core-configs - Fedora CI tasks for epel10 pull requests - enable the testing period in bodhi With no published repo, no mirroring, and no testing period (0 days to stable in bodhi), this is not a good time to start consuming EPEL 10. However, it is a good time for packagers to start building their packages. To be clear, this is the announcement to packagers that they can start building their packages. I'm hoping that in the next week or two we'll be able to get the mock configs done to enable packagers to do local builds, but in the mean time koji scratch builds are a solid alternative. We built about 70 packages during the allotted time of the hackfest, and as I write this we just passed 100 builds. Things seem to be working well. Please let me know if you notice any issues, aside from known items on the "not completed yet" list above. Happy packaging! On Sat, Aug 10, 2024 at 12:29 AM Orion Poplawski wrote: On 7/4/24 01:45, Carl George wrote: I originally posted this on Fedora Discussion [0], but I'm sharing it here as well for awareness. # Executive summary EPEL 10 is expected to be launched in Q4 of 2024. You may start noticing parts of the infrastructure coming online sooner than that. **Please do not start creating EPEL 10 builds until we announce that we are ready for packagers to start building.** I'm seeing some builds and bugzilla requests for branching/builds. What is the current status? -- 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/ -- ___ 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 -- 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 10 status update
Thank you for the update. Is it time for an epel10 version in bugzilla? Seems like it. On 8/10/24 16:41, Carl George wrote: Hey Orion, I planned to send a status update following the hackfest, but I didn't think about the confusion that would be caused for packagers not at the hackfest who were getting branch requests. Sorry about that. I just posted a summary on the discussion thread. I'll include it below as well. --- The EPEL 10 hackfest at Flock took place yesterday. We were able to get enough of the infrastructure working prior to the hackfest to enable packagers in attendance to do a controlled trial run building packages. This also resulted in a few branch request bugzillas for dependencies, which I realize in hindsight was confusing for packagers not at the hackfest. I apologize for not setting that expectation ahead of time. Here is a summary of what is and isn't working at this point. What works: - creating epel10 branches (`fedpkg request-branch epel10`) - pushing commits to epel10 branches - pull requests to epel10 branches - Fedora CI scratch builds for epel10 pull requests - creating epel10.0 builds from epel10 branches (`fedpkg build` from an epel10 branch) - automatic bodhi updates, similar to rawhide What has not been completed yet: - publish the epel/10 repo - mirror the epel/10 repo - create epel-release for epel10 - epel10 configs in mock-core-configs - Fedora CI tasks for epel10 pull requests - enable the testing period in bodhi With no published repo, no mirroring, and no testing period (0 days to stable in bodhi), this is not a good time to start consuming EPEL 10. However, it is a good time for packagers to start building their packages. To be clear, this is the announcement to packagers that they can start building their packages. I'm hoping that in the next week or two we'll be able to get the mock configs done to enable packagers to do local builds, but in the mean time koji scratch builds are a solid alternative. We built about 70 packages during the allotted time of the hackfest, and as I write this we just passed 100 builds. Things seem to be working well. Please let me know if you notice any issues, aside from known items on the "not completed yet" list above. Happy packaging! On Sat, Aug 10, 2024 at 12:29 AM Orion Poplawski wrote: On 7/4/24 01:45, Carl George wrote: I originally posted this on Fedora Discussion [0], but I'm sharing it here as well for awareness. # Executive summary EPEL 10 is expected to be launched in Q4 of 2024. You may start noticing parts of the infrastructure coming online sooner than that. **Please do not start creating EPEL 10 builds until we announce that we are ready for packagers to start building.** I'm seeing some builds and bugzilla requests for branching/builds. What is the current status? -- 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/ -- ___ 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 -- 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 10 status update
On 7/4/24 01:45, Carl George wrote: I originally posted this on Fedora Discussion [0], but I'm sharing it here as well for awareness. # Executive summary EPEL 10 is expected to be launched in Q4 of 2024. You may start noticing parts of the infrastructure coming online sooner than that. **Please do not start creating EPEL 10 builds until we announce that we are ready for packagers to start building.** I'm seeing some builds and bugzilla requests for branching/builds. What is the current status? -- 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] Basic pyproject-rpm-macros now in EPEL8
EPEL8 now has a stripped down version of pyproject-rpm-macros. Notably, it does NOT support/provide %pyproject_generate_buildrequires, but it does support the basic build/install related macros. Also note that this only supports building with python 3.8+. -- 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] python2 in epel8-next
I'm building python3.11-setuptools_scm-epel in epel8-next. It requires mercurial for the tests which requires: /usr/bin/python2 libpython2.7.so.1.0()(64bit) python(abi) = 2.7 python2 On my CS8 system this is satisfied by python2-2.7.18-12.module_el8+299+aa6e9afa.x86_64 from the python27 module. In the epel8-next build I end up with: python2 x86_64 2.7.17-1.el8 python2-for-tests x86_64 2.7.17-1.el8 python2-libs x86_64 2.7.17-1.el8 despite this message: DEBUG util.py:445: Enabling module streams: DEBUG util.py:445: mercurial 4.8 DEBUG util.py:445: python27 2.7 Which then emits a complaint when run: ERROR: Python 2 is disabled in RHEL8. - For guidance on porting to Python 3, see the Conservative Python3 Porting Guide: http://portingguide.readthedocs.io/ - If you need Python 2 at runtime: - Use the python27 module - If you do not have access to BZ#1533919: - Use the python27 module - If you need to use Python 2 only at RPM build time: - File a bug blocking BZ#1533919: https://bugzilla.redhat.com/show_bug.cgi?id=1533919 - Set the environment variable RHEL_ALLOW_PYTHON2_FOR_BUILD=1 (Note that if you do not file the bug as above, this workaround will break without warning in the future.) - If you need to use Python 2 only for tests: - File a bug blocking BZ#1533919: https://bugzilla.redhat.com/show_bug.cgi?id=1533919 (If your test tool does not have a Bugzilla component, feel free to use `python2`.) - Use /usr/bin/python2-for-tests instead of python2 to run your tests. (Note that if you do not file the bug as above, this workaround will break without warning in the future.) For details, see https://hurl.corp.redhat.com/rhel8-py2 Fatal Python error: Python 2 is disabled 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? -- 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: Future of ClamAV on EPEL ?
On 3/7/23 13:48, Stephen Smoogen wrote: On Tue, 7 Mar 2023 at 15:00, Andrew C Aitchison <mailto:and...@aitchison.me.uk>> wrote: This question is prompted by a question from kumar bava about EPEL7 on the ClamaAV Users list: https://lists.clamav.net/pipermail/clamav-users/2023-March/013338.html <https://lists.clamav.net/pipermail/clamav-users/2023-March/013338.html> EPEL currently ship the anti-virus ClamAV v0.103.8 From September ClamAV 0.103 will be EOL, and all supported versions will require Rust. Rust is available on RHEL 7, 8 and 9 as a part of Red Hat Developer Tools. Does that mean that EPEL will or will not be able to continue packaging ClamAV ? ClamAV do provide rpms, so it may not be the end of the world if ClamAV disappears from EPEL, but the details of the packing, especially config locations and defaults may be different. EPEL packages are maintained by volunteers who 'shephard' a particular package for as long as the volunteer can do so. I have cc'd the main ones I have seen making commits and builds in case they aren't following the epel-devel list closely. That said, EL7 will only be around til June 2024. There will only be so much 'heavy-lifting' possible to keep things going in that time-frame I've been looking into things and I think we will be able to update clamav in EL7 and EL8 to 1.0.X once 0.103.X goes EOL. We're basically just waiting on one issue to get resolved at the moment: https://github.com/Cisco-Talos/clamav/issues/842 -- 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: [SPF:fail] A coordinated plan for ansible-collection updates in EPEL?
On 1/31/23 11:03, Maxwell G wrote: On Tue Jan 31, 2023 at 15:01 +0200, Sagi Shnaidman wrote: Hi all, Hi, Orion Thanks for raising this question. Indeed! I wonder if it's possible to continue to update collections to the newest versions anyway. If someone wants to use the collection version provided in "big ansible", they would use ansible 6.3.0 with all included. If they want a newer collection, they can install a separate newest RPM. I agree. I think we should update collections to the next major version (if it exists) after each RHEL minor release and then keep them updated with point releases in between. We update the ansible bundle to the next major version that corresponds to RHEL's ansible-core version at each RHEL minor release, so it makes to do the same with the standalone collection packages. Collection versions that are EOL upstream won't be tested with newer ansible-core versions. Does this capture the general sentiment? - ansible is the static/stable collection of collections paired with the provided ansible-core for the life of the point release - ansible-collection-* packages will be at least the version of the collection in ansible, and optionally higher while giving due diligence to avoiding breaking changes. -- 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] 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] python3-qt5-webkit for EPEL 8
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.
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/
--
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/%global with_python3 1
%global python3_dbus_dir %(%{__python3} -c "import dbus.mainloop; print(dbus.mainloop.__path__[0])" 2>/dev/null || echo "%{python3_sitearch}/dbus/mainloop")
# enable/disable individual modules
# drop power64, it's not supported yet (than)
%ifarch %{?qt5_qtwebengine_arches}%{?!qt5_qtwebengine_arches:%{ix86} x86_64 %{arm} aarch64 mips mipsel mips64el}
%global webengine 0
%endif
%global webkit 1
%global py3_sipdir %{_datadir}/sip/PyQt5
%global sip_ver 4.19.23
# see also https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JQQ66XJSIT2FGTK2YQY7AXMEH5IXMPUX/
%undefine _strict_symbol_defs_build
Summary: PyQt5 is Python bindings for Qt5
Name:python-qt5-epel
Version: 5.15.0
Release: 3.0.1%{?dist}
License: GPLv3
Url: http://www.riverbankcomputing.com/software/pyqt/
Source0: https://files.pythonhosted.org/packages/8c/90/82c62bbbadcca98e8c6fa84f1a638de1ed1c89e85368241e9cc43fcbc320/PyQt5-%{version}.tar.gz
## upstreamable patches
Patch0: python-qt5_sipdir.patch
# support newer Qt5 releases
Patch1: PyQt5-Timeline.patch
#BuildRequires: pkgconfig(dbus-1)
BuildRequires: python%{python3_pkgversion}
BuildRequires: python%{python3_pkgversion}-sip-devel >= %{sip_ver}
%description
%{summary}.
%global __provides_exclude_from ^(%{_qt5_plugindir}/.*\\.so)$
%if 0%{?webengine}
%package -n python%{python3_pkgversion}-qt5-webengine
Summary: Python3 bindings for Qt5 WebEngine
BuildRequires: pkgconfig(Qt5WebEngine)
Requires: python%{python3_pkgversion}-qt5%{?_isa} = %{version}-%{release}
%{?python_provide:%python_provide python%{python3_pkgversion}-qt5-webengine}
%description -n python%{python3_pkgversion}-qt5-webengine
%{summary}.
%endif
%package -n python%{python3_pkgversion}-qt5-webkit
Summary: Python3 bindings for Qt5 Webkit
BuildRequires: pkgconfig(Qt5WebKit)
BuildRequires: pkgconfig(Qt5WebKitWidgets)
Requires: python%{python3_pkgversion}-qt5%{?_isa} = %{version}-%{release}
%{?python_provide:%python_provide python%{python3_pkgversion}-qt5-webkit}
%description -n python%{python3_pkgversion}-qt5-webkit
%{summary}.
%prep
%setup -q -n PyQt5-%{version}
%patch0 -p1
%patch1 -p1
%build
PATH=%{_qt5_bindir}:$PATH ; export PATH
mkdir %{_target_platform}-python3
cp -a * %{_target_platform}-python3/ ||:
pushd %{_target_platform}-python3
%{__python3} ./configure.py \
--assume-shared \
--confirm-license \
--qmake=%{_qt5_qmake} \
%{?py3_sip:--sip=%{_bindir}/python3-sip} \
%{?py3_sipdir:--sipdir=%{py3_sipdir}} \
--enable QtWebKit \
--enable QtWebKitWidgets \
--verbose \
QMAKE_CFLAGS_RELEASE="%{optflags}" \
QMAKE_CXXFLAGS_RELEASE="%{optflags} `pkg-config --cflags dbus-python`" \
QMAKE_LFLAGS_RELEASE="%{?__global_ldflags}"
# --dbus=%{_includedir}/dbus-1.0/ \
%make_build
popd
%install
%make_install INSTALL_ROOT=%{buildroot} -C %{_target_platform}-python3
rm -r %{buildroot}%{_datadir} \
%{buildroot}%{_bindir} \
%{buildroot}%{python3_sitearch}/PyQt5*info \
%{buildroot}%{python3_sitearch}/PyQt5/__init__.py \
%{buildroot}%{python3_sitearch}/PyQt5/py* \
%{buildroot}%{python3_sitearch}/PyQt5/Qt.so \
%{buildroot}%{python3_sitearch}/PyQt5/uic
%if 0%{?webengine}
%files -n python%{python3_pkgversion}-qt5-webengine
%{python3_sitearch}/PyQt5/QtWebEngine.*
%{python3_sitearch}/PyQt5/QtWebEngineCore.*
%{python3_sitearch}/PyQt5/QtWebEngineWidgets.*
%endif
%files -n python%{python3_pkgversion}-qt5-webkit
%{python3_sitearch}/PyQt5/QtWebKit.*
%{python3_sitearch}/PyQt5/QtWebKitWidgets.*
%changelog
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
[EPEL-devel] python3-qt5-webkit for EPEL 8
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.
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/
--
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/%global with_python3 1
%global python3_dbus_dir %(%{__python3} -c "import dbus.mainloop; print(dbus.mainloop.__path__[0])" 2>/dev/null || echo "%{python3_sitearch}/dbus/mainloop")
# enable/disable individual modules
# drop power64, it's not supported yet (than)
%ifarch %{?qt5_qtwebengine_arches}%{?!qt5_qtwebengine_arches:%{ix86} x86_64 %{arm} aarch64 mips mipsel mips64el}
%global webengine 0
%endif
%global webkit 1
%global py3_sipdir %{_datadir}/sip/PyQt5
%global sip_ver 4.19.23
# see also https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JQQ66XJSIT2FGTK2YQY7AXMEH5IXMPUX/
%undefine _strict_symbol_defs_build
Summary: PyQt5 is Python bindings for Qt5
Name:python-qt5-epel
Version: 5.15.0
Release: 3.0.1%{?dist}
License: GPLv3
Url: http://www.riverbankcomputing.com/software/pyqt/
Source0: https://files.pythonhosted.org/packages/8c/90/82c62bbbadcca98e8c6fa84f1a638de1ed1c89e85368241e9cc43fcbc320/PyQt5-%{version}.tar.gz
## upstreamable patches
Patch0: python-qt5_sipdir.patch
# support newer Qt5 releases
Patch1: PyQt5-Timeline.patch
#BuildRequires: pkgconfig(dbus-1)
BuildRequires: python%{python3_pkgversion}
BuildRequires: python%{python3_pkgversion}-sip-devel >= %{sip_ver}
%description
%{summary}.
%global __provides_exclude_from ^(%{_qt5_plugindir}/.*\\.so)$
%if 0%{?webengine}
%package -n python%{python3_pkgversion}-qt5-webengine
Summary: Python3 bindings for Qt5 WebEngine
BuildRequires: pkgconfig(Qt5WebEngine)
Requires: python%{python3_pkgversion}-qt5%{?_isa} = %{version}-%{release}
%{?python_provide:%python_provide python%{python3_pkgversion}-qt5-webengine}
%description -n python%{python3_pkgversion}-qt5-webengine
%{summary}.
%endif
%package -n python%{python3_pkgversion}-qt5-webkit
Summary: Python3 bindings for Qt5 Webkit
BuildRequires: pkgconfig(Qt5WebKit)
BuildRequires: pkgconfig(Qt5WebKitWidgets)
Requires: python%{python3_pkgversion}-qt5%{?_isa} = %{version}-%{release}
%{?python_provide:%python_provide python%{python3_pkgversion}-qt5-webkit}
%description -n python%{python3_pkgversion}-qt5-webkit
%{summary}.
%prep
%setup -q -n PyQt5-%{version}
%patch0 -p1
%patch1 -p1
%build
PATH=%{_qt5_bindir}:$PATH ; export PATH
mkdir %{_target_platform}-python3
cp -a * %{_target_platform}-python3/ ||:
pushd %{_target_platform}-python3
%{__python3} ./configure.py \
--assume-shared \
--confirm-license \
--qmake=%{_qt5_qmake} \
%{?py3_sip:--sip=%{_bindir}/python3-sip} \
%{?py3_sipdir:--sipdir=%{py3_sipdir}} \
--enable QtWebKit \
--enable QtWebKitWidgets \
--verbose \
QMAKE_CFLAGS_RELEASE="%{optflags}" \
QMAKE_CXXFLAGS_RELEASE="%{optflags} `pkg-config --cflags dbus-python`" \
QMAKE_LFLAGS_RELEASE="%{?__global_ldflags}"
# --dbus=%{_includedir}/dbus-1.0/ \
%make_build
popd
%install
%make_install INSTALL_ROOT=%{buildroot} -C %{_target_platform}-python3
rm -r %{buildroot}%{_datadir} \
%{buildroot}%{_bindir} \
%{buildroot}%{python3_sitearch}/PyQt5*info \
%{buildroot}%{python3_sitearch}/PyQt5/__init__.py \
%{buildroot}%{python3_sitearch}/PyQt5/py* \
%{buildroot}%{python3_sitearch}/PyQt5/Qt.so \
%{buildroot}%{python3_sitearch}/PyQt5/uic
%if 0%{?webengine}
%files -n python%{python3_pkgversion}-qt5-webengine
%{python3_sitearch}/PyQt5/QtWebEngine.*
%{python3_sitearch}/PyQt5/QtWebEngineCore.*
%{python3_sitearch}/PyQt5/QtWebEngineWidgets.*
%endif
%files -n python%{python3_pkgversion}-qt5-webkit
%{python3_sitearch}/PyQt5/QtWebKit.*
%{python3_sitearch}/PyQt5/QtWebKitWidgets.*
%changelog
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
[EPEL-devel] Re: Forcing Python minor version in EPEL builds
On 1/7/23 06:04, Mark E. Fuller wrote: Hi Folks, I am looking to update one of my packages in EPEL 8 and Python3.6 was dropped. Can anyone point me in the right direction as to how to edit my spec file `buildrequires` and the macros to enforce Python 3.7 (or higher) instead of Python 3.6 anto do it "the right way", not a kludge? For producing versions for other python 3.X versions, there is this: https://fedoraproject.org/wiki/EPEL/Python3X and you can check out the various python3*-foo-epel packages. I don't know of a 3.7, but there is 3.8 and 3.9. HTH, Orion -- 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] Is is worth packaging PHP stuff in EPEL8+?
Is is worth packaging PHP stuff in EPEL8+? It seems very modular in RHEL and Remi's repos, but EPEL isn't doing modules. If it is worthwhile, is anyone interested in helping out? I was hoping to get mediawiki 1.35 into EPEL8. Orion -- Orion Poplawski 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: python-passlib for python38 module
On 5/24/22 11:53, Maxwell G via epel-devel wrote:
On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote:
I've been coming to the thinking that naming the SRPMS
python3X-%{srcname}-epel is a better choice. This makes modifying
original Fedora specs simpler.
I think that makes sense, especially considering that these packages will not
be built for Fedora.
Right - that's the other help hopefully to reduce bugzilla issues filed
against the wrong component.
See https://fedoraproject.org/wiki/EPEL/Python3X
Here is some feedback:
First, aren't we trying to move off the wiki? Wouldn't this be a better
candidate for the EPEL docs on docs.fp.o?
Sure, except I know nothing about how docs.fp.o works ;)
separate Python 3 minor versions in EPEL 8 are packaged as separate python3X
(currently python38) packages to allow for independent versions for each
Python version.
There is also python39.
egads. added.
== 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}.
When I built ansible-5 for Python 3.8, I just ran `:%s python3-/python%
{python3_pkgversion}-/` and added `%global python3_pkgversion 38`. `%
{python3_pkgversion}` is set to 3
by default. I would recommend doing that in your example instead of hardcoding
`python38`.
Yeah, I think maybe a sed script is in order.
== Example Spec ==
[...]
%global sum An example python module
I don't think there's any point to have a %sum macro when you can use `%
{summary}` in subpackage definitions. Admittedly, this is more of a packaging
nitpick than a comment related to the issue at hand :D.
%global __python3 /usr/bin/python3.8
I think it's better to add `Requires: python%{python3_pkgversion}-rpm-macros`.
To be fair, they both do effectively the same thing: set %__python3 to the
correct value. In any case, I submitted https://src.fedoraproject.org/rpms/
epel-rpm-macros/pull-request/44 so neither should be necessary.
%check
%{__python3} setup.py test
I was going to suggest using `%pytest`, but then I remembered that https://
pagure.io/releng/issue/10679 is still outstanding :(.
%files -n python38-%{srcname}
[...]
%{python3_sitelib}/*
Globs like this are against the Python Packaging Guidelines.
True. Fixed.
Thanks.
--
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 on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
On 5/17/22 12:05, Leon Fauster via epel-devel wrote:
Am 17.05.22 um 18:08 schrieb Maxwell G:
On Tuesday, May 17, 2022 9:58:33 AM CDT Leon Fauster via epel-devel
wrote:
https://paste.centos.org/view/06187bdb
adapts
https://src.fedoraproject.org/rpms/python-passlib/blob/main/f/python-passlib.spec
to build it locally (for the sake of progress I disabled the tests/nose
dep).
Unless you are planning to remove python3-passlib (the python36
version) or make it a modular package, I think it is better to just
create a new SRPM named python38-passlib with no subpackages.
https://bugzilla.redhat.com/show_bug.cgi?id=2087268
I've been coming to the thinking that naming the SRPMS
python3X-%{srcname}-epel is a better choice. This makes modifying
original Fedora specs simpler. See
https://fedoraproject.org/wiki/EPEL/Python3X
PS: Is it only my impression or do others feel also the same. Starting
with EL8 the expenses just for the platform (distribution) gets more and
more attention in our daily work. Shouldn't it be the other way around?
Yes, I seem to be staring down a huge amount of work to package up
python 3.8 deps for EPEL8. I suppose I should just give up and start
using pip and virtual envs.
--
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 on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: %generate_buildrequires
On 12/3/20 14:06, Andrew C Aitchison wrote: On Thu, 3 Dec 2020, Michel Alexandre Salim wrote: Apart from the usual package-not-available story (which I want to fix as part of my work bringing up the EPEL Packagers SIG), my current snag is that python-tox-current-env uses %generate_buildrequires which does not work on CentOS 8: CentOS 8 is still on RPM 4.14: sh-4.4# rpm -q rpm rpm-4.14.2-37.el8.x86_64 I'll put up a patch to hardcode dependencies for non-Fedora releases, though that sorts of defeat the purpose of dynamic build requirements. Then again, this is only needed for EPEL8, since EPEL9 will have a new enough RPM. Given that %generate_buildrequires is the selling point of pyproject- rpm-macros, I'm guessing a better way forward for EPEL8 would be to not require it on EPEL8 since there's no way it would work, since RH won't update RPM? https://src.fedoraproject.org/rpms/pyproject-rpm-macros I've been playing around with a hacked version of pyproject-rpm-macros which at least allows some basic functionality in EPEL8. Comments welcome. https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/284 -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: How can I request vnstat gets updated in EPEL7
On 5/15/22 06:08, Nick Howitt via epel-devel wrote: Hi, I've been having a look at vnstat and to get 5 minute output (vnstat -5), the epel7 package needs to be updated. I've updated mine to upstream 2.9, but how do I request a proper epel release? Currently in epel there is: vnstat-1.15-2.el7 vnstat-2.6-2.el8 vnstat-2.8-1.el9 So all the packages are out of sync. When I compiled 2.9 for el7 all the Hardening section needs to be removed from the systemd unit file. I also had a problem with the vnstati package and I can't remember how I fixed and the machine where I sis the build no longer exists. I would have thought it was a good idea to update all packages to the latest 2.9? How do I request it? https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL&component=vnstat&version=epel7 -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Modules for EPEL9
Is there a timeline for supporting building modules for EPEL9? At the moment I get: Could not execute module_build: The build failed with: None of the base module (platform or bootstrap) streams in the buildrequires section could be found -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: How to support python 3.8 from RHEL 8.2 in EPEL?
On 3/2/22 14:14, epel-devel@lists.fedoraproject.org wrote: > Except that we are going to need python38-pytest, etc. in the EPEL8 buildroot > if we are going to build (most of) the packages in the first place. That's > the problem I'm running into now trying to build python38-jmespath: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=83570866 > DEBUG util.py:444: No matching package to install: 'python38-pytest' > > So I'm back to my original questions: > > * Do we just make EPEL python38- packages as modules or try to hack up some > kind of build system support for it? > * If modules, every package a module or one (or a few) modules? I have been told that the lack of python38-pytest is an issue with the buildroot generation and so have filed: https://pagure.io/releng/issue/10679 Hopefully this will make everything simpler as nothing has to be a module or special in any way. -- Orion Poplawski 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: How to support python 3.8 from RHEL 8.2 in EPEL?
On 2/13/20 02:21, Tomas Orsava wrote: > On 2/13/20 5:18 AM, Orion Poplawski wrote: >> On 1/30/20 8:39 AM, Miro Hrončok wrote: >>> On 30. 01. 20 16:32, Orion Poplawski wrote: >>>> Folks - >>>> >>>> Looks like RHEL 8.2 will have python 3.8 in addition to python 3.6. >>>> From >>>> the 8.2 beta: >>>> >>>> Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs) >>>> Name Stream Profiles Summary >>>> python27 2.7 [d][e] common [d] Python programming >>>> language, version 2.7 >>>> python36 3.6 [d][e] build, common [d] Python programming >>>> language, version 3.6 >>>> python38 3.8 [d][e] build, common [d] Python programming >>>> language, version 3.8 >>>> >>>> Currently, %python_pkgversion is set to 3 in >>>> /usr/lib/rpm/macros.d/macros.python-srpm from python-srpm-macros. >>>> >>>> python3-devel is still provided only by python36-devel, so presumably all >>>> EPEL8 python packages will continue to be built against python 3.6. But I >>>> imagine that people will soon be asking for python 3.8 versions of EPEL >>>> packages. How can we provide those? Does this have to be done in some >>>> modular fashion - which seems to come back to the discussion of whether or >>>> not >>>> every package has to become its own module or whether to group them >>>> together >>>> somehow. Or since both python modules are "default" modules and we can >>>> install both python36-devel and python38-devel at the same time, perhaps we >>>> can define the python3_other* macros again for python38 and just go that >>>> way? >>>> >>>> Thoughts? >>> >>> The idea is that the versions fo stuff we build in RHEL for different >>> python versions is different and I'd like to keep that idea in EPEL as >>> well. Building a python38-foo package from it's own spec should work as >>> follows: >>> >>> BR python38-rpm-macros >>> BR python38-devel >>> BR python38-bar etc... >>> >>> Regular specfile follows. >>> >>> You can even have a single specfile that build for different Python version >>> based on local override of %python_pkgversion in the buildroot. >>> >>> Building both versions from single spec file---single build would require a >>> new set of macros, yes (or hardcoding stuff). However I'd not call them >>> python3_other* unless you want to end up with python3_other_other* the next >>> time this happens. >>> >> >> This along with some more info from rhel 8.2 beta yields more questions for >> me. While I do agree that building the python38 packages from separate >> specs probably is the best route (biggest reason being it allows for >> updating of individual module versions) I'm hoping we can brainstorm ways to >> make this less onerous on individual packagers. >> >> Looks like python38-devel is a module in RHEL 8.2 that provides a bunch of >> stuff needed for building modules (python38-devel, python38-pytest, etc): > > > Hi! > Just a little correction, despite the name suggesting otherwise, the > "python38-devel" package is not in the python38-devel module, but in the > python38 module itself, which has a default stream. > > The python38-devel module contains only python38-pytest and it's dependencies > (pyparsing, atomicwrites, attrs, packaging, py, more-itertools, pluggy, > wcwidth). And the reason it's not default is not an intention but a current > technical limitation of the automatically generated "-devel" modules shipped > in the CRB. > > >> >> Red Hat CodeReady Linux Builder Beta for RHEL 8 x86_64 (RPMs) >> Name Stream Profiles Summary >> python38-devel 3.8 [e] Python programming >> language, version 3.8 >> >> Since this isn't a default module, does this again mean the python38 >> packages in EPEL 8 need to be modules as well? Or can we provide a >> buildroot that enables this module? >> >> My current pie-in-the-sky idea is that we could do: >> >> - create a epel8-python38 branch for all of the python-* packages with epel8 >> branches. >> - epel8-python38 buildroot would enable python38-devel and install >> python38-rpm-macros an
[EPEL-devel] Re: Developer access to RHEL8 on s390x
On 1/17/22 16:42, epel-devel@lists.fedoraproject.org wrote: I'm trying to look into a package test failure on RHEL8 s390x. However, it seems that my free developer subscription does not give me access to this platform: [linux1@rhel8 ~]$ sudo subscription-manager attach Installed Product Current Status: Product Name: Red Hat Enterprise Linux for IBM z Systems Status: Not Subscribed Unable to find available subscriptions for all your installed products. Would it be possible to obtain one? Any other suggestions for how to get access to such a platform? I've already reached out to Dan Horák who gave me access to a Fedora system and pointed me to the LinuxONE community cloud where I launched the above instance. Well, despite "not receiving updates", I was able to install the packages I needed to test this particular issue. So I'm okay at the moment, though still somewhat curious if I could get access. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Developer access to RHEL8 on s390x
I'm trying to look into a package test failure on RHEL8 s390x. However, it seems that my free developer subscription does not give me access to this platform: [linux1@rhel8 ~]$ sudo subscription-manager attach Installed Product Current Status: Product Name: Red Hat Enterprise Linux for IBM z Systems Status: Not Subscribed Unable to find available subscriptions for all your installed products. Would it be possible to obtain one? Any other suggestions for how to get access to such a platform? I've already reached out to Dan Horák who gave me access to a Fedora system and pointed me to the LinuxONE community cloud where I launched the above instance. Thanks, Orion -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
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 :) -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
evel 3 rados-objclass-devel 0 rapidjson-devel 18 sid-base-libs-devel 0 sid-iface-libs-devel 0 sid-log-libs-devel 0 sid-resource-libs-devel 0 speech-tools-libs-devel 1 suitesparse64-devel 3 suitesparse64_-devel 1 swtpm-devel 0 sysprof-devel 1 tesseract-devel 5 tix-devel 8 uchardet-devel 4 umockdev-devel 2 unbound-devel 8 v8-devel 2 vm-dump-metrics-devel 0 volume_key-devel 1 web-assets-devel 66 wireplumber-devel 0 wpebackend-fdo-devel 1 xkbcomp-devel 0 xorg-x11-drv-evdev-devel 0 That's a lot. Now, many of these are pretty obscure and do not have any users - but I'm also seeing a number that are going to hit me and the scitech sig: blis-devel 2 flexiblas-devel 33 gsl-devel 51 suitesparse64-devel 3 There are some other big ones as well. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 1/14/22 05:02, Josh Boyer wrote: On Fri, Jan 14, 2022 at 5:31 AM Miro Hrončok wrote: 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. A fairly accurate list of packages removed in RHEL 9 can be found in our RHEL 9 Adoption documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages Thanks for that. 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). I will politely point out two things. 1) The entirety of the RHEL buildroot is available in the CentOS Stream koji buildroots. I know the EPEL stewards have qualms about using it, but they are there and the technical hurdles to consume them are not large. Well, we are making use of it via epel-next. But it's the "Stream" buildroot. Once that diverges from the current released RHEL there could be issues with trying to do updated builds for the current release of RHEL. 2) Moving content to CRB in RHEL is not a silver bullet solution in many scenarios. If it's strictly for build dependencies, CRB works well. If an EPEL package has a runtime requires on CRB content, that is less desirable. RHEL CodeReady Linux Builder (CRB) content is unsupported, not enabled by default, and not intended to be used at runtime in production. EPEL itself is clearly in the same unsupported category, but requiring another unsupported repo at runtime may lead to unintentional surprises for many users. josh I don't buy any of these arguments, and it doesn't really address the situation of "missing -devel" packages. E.g. utf8proc - it's in "AppStream" - so it's presumably "supported" and "intended to be used at runtime in production". But without the -devel package available we can't build anything in EPEL that uses it. So we have to go through contortions to make sure we build the proper version of utf8proc-devel and keep it in sync with RHEL. Is the trade off of perhaps a few less RHEL support requests about a few packages that are clearly important enough to be included directly in RHEL really worth the ill-will being generated in the volunteers that help support the ecosystem around RHEL? Perhaps it's unreasonable for me to be as upset about this as I am, but largely it's because I just can't understand the motivation behind it and it's a deliberate action that directly makes my *volunteer* work harder. I have put in thousands of hours of work on Fedora/EPEL over 16+ years - and generally it has just gotten better. Better tools, better infrastructure, etc. This is the first time I can remember having something change that makes the work harder - so maybe it's just the shock of that. Feels like a betrayal of those 16 years of working together towards what seemed like a common goal. Oh, and for cppunit just putting it in CRB should be just fine as it generally does not produce runtime deps. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 1/14/22 19:45, epel-devel@lists.fedoraproject.org wrote: On 1/14/22 03:29, Miro Hrončok wrote: 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). 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&bug_id_type=anddependson&format=tvp&list_id=12369805# So it turns out that this came from a misunderstanding of how things work in CS9. I saw the builds in koji and assumed that they were then available. But apparently they have been retired: https://gitlab.com/redhat/centos-stream/rpms/python-pytest-cov I was also confused about two things here: - It's retired on the "main" branch, but the c9s branch seems intact. - What does "retired for CS-569" mean? So, apologies for jumping to conclusions. I'm afraid I'm still pretty upset about the whole "missing -devel" package thing. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 1/14/22 05:36, Neal Gompa wrote: On Fri, Jan 14, 2022 at 7:27 AM Leon Fauster via epel-devel wrote: Am 14.01.22 um 13:02 schrieb Josh Boyer: A fairly accurate list of packages removed in RHEL 9 can be found in our RHEL 9 Adoption documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages It seems that RH does not see RHEL as workstation OS anymore. Many tools were/will be removed. I do not need to be bright to anticipate that in the future (e.g. RHEL11) the trouble will prevails the benefit. EPEL QA is better then ever but it will not fill the gap. Thats like swimming agains the stream. Unless RH incorporates EPEL into his strategies. Like keeping the volume of packages officially and just shifting the borders ... thought. I think that's an unfair characterization. While it's certainly true that RHEL focuses on server workloads (it's easily an order of magnitude more sales than workstation ones), it's also true that Red Hat is *finally* investing in EPEL. This is the *first* RHEL release where Red Hat is *directly* investing in helping the community bring up EPEL. The RHEL folks are giving us a path to request packages as needed from being buildroot-only (thus internal to non-public RHEL Koji) to published repositories (thus usable by EPEL and third-parties). I *personally* have done this now many times with great success, and the consequence of that is we're able to get content into EPEL faster than ever before. We're even going to be ready for the RHEL 9.0 GA, which is something we've never had before. I seem to have missed how to do this, could you point me to the right process? Thanks! -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 1/14/22 03:29, Miro Hrončok wrote: 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). 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&bug_id_type=anddependson&format=tvp&list_id=12369805# Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On 1/14/22 03:29, Miro Hrončok wrote: 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). Recently I came across the python-zope-* packages, e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=2038512 -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] The incredibly shrinking RHEL
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. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Status of python-gevent in EL9
Can someone shed light on the status of python-gevent in EL9? It seems to have been built for CS9: https://kojihub.stream.centos.org/koji/packageinfo?packageID=3414 (though perhaps not tagged?) but builds for EPEL9 fail to find it: https://koji.fedoraproject.org/koji/taskinfo?taskID=80607754 Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Get BR: %{py3_dist } working on EPEL7
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.
Thoughts?
--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems 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 on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: proposed recommendation - missing devel packages
On 9/23/21 9:00 AM, Miro Hrončok wrote:
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.
Thanks, good ideas!
--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems 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 on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: proposed recommendation - missing devel packages
On 9/23/21 7:28 AM, Troy Dawson wrote:
That looks great, and very close to what I've done.
I have a couple of variations.
I think the biggest is that I set a variable called rhel_name and then
change %{name} to %{rhel_name}. It looks like you only had two
instances of %{name} but I've had a couple with many instances of it,
and this makes it easier.
The second is that I usually put a link to the upstream spec file, in
comments. I use the CentOS Stream git repo, because it's publicly
available. This is mainly for me, cuz I never know where to find them.
So, this is at the top of my spec files.
# This spec file is derived from the RHEL8 spec file.
# They should be kept in sync over time.
# https://git.centos.org/rpms/libpinyin/blob/c8/f/SPECS/libpinyin.spec
<https://git.centos.org/rpms/libpinyin/blob/c8/f/SPECS/libpinyin.spec>
%global rhel_name libpinyin
%global _debugsource_template %{nil}
But, that's just my preferences. I think yours should be fine.
Thanks, good ideas.
I'm thinking we might want to break this out from a question in the FAQ
to it's own page.
+1
Troy
--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems 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 on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: proposed recommendation - missing devel packages
On 7/1/21 4:05 PM, Troy Dawson wrote:
I believe this is a recommendation, versus a policy.
I wanted to get people's thoughts on it, and if ya'll like it, put it in
the documentation.
In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
packages that are built from RHEL spec files. This will also be true of
RHEL 9, and possibly future RHEL releases. These missing packages are
usually -devel packages and may impact an EPEL package build.
If your EPEL package is impacted by a missing -devel package, do the
following.
1 - Request the package be added to RHEL 8 and 9 CRB repository.
-- To initiate this process, please file a bug in
https://bugzilla.redhat.com <https://bugzilla.redhat.com> and request it
be added to RHEL 8 and 9. Report the bug against the "CentOS Stream"
version of the "Red Hat Enterprise Linux 8" and/or "Red Hat Enterprise
Linux 9" product.
-- Be sure to say that it is impacting an EPEL build, and which package
it is impacting.
2 - Create an epel package that only has the missing packages.
-- Be prepared to maintain this package as long as it is needed.
-- It is recommended that you name it -epel
-- It is recommended that you add the epel-packaging-sig group as a
co-maintainer
-- It qualifies for an exception to the review process[1] so you can
request the repo with
--- fedpkg request-repo --exception -epel
-- If you need help building this, ask for help. We have some examples.
3 - When/If the missing package(s) are added to RHEL CRB, retire your
-epel package.
---
Sorry, this is a little rushed. I wanted to get something out sooner,
rather than later.
Troy
So, I've decided to try this with utf8proc. I've requested the
utf8proc-epel package and now requested an epel8 branch (and will retire
the rawhide branch).
These are the changes I have made, does this seem correct? Notes on
changes:
* We are not shipping binaries, so need to disable the debug package
* Need to change Name and %{name}
* Need to explicitly name the devel package
* Need to use relative Requires for the main package. Both to allow
RHEL to update and (in this case) to deal with module release tags
* Remove the files installed for the main package
* Remove %files and %post* for the main package
* Add %changelog entry
--- SPECS/utf8proc.spec 2021-09-22 21:24:59.304665646 -0600
+++ /export/home/orion/fedora/utf8proc-epel/utf8proc-epel.spec
2021-09-22 21:32:01.568719918 -0600
@@ -1,11 +1,13 @@
+%global debug_package %{nil}
+
Summary: Library for processing UTF-8 encoded Unicode strings
-Name:utf8proc
+Name:utf8proc-epel
Version: 2.1.1
Release: 5%{?dist}
License: Unicode and MIT
Group: System Environment/Libraries
URL: http://julialang.org/utf8proc/
-Source:
https://github.com/JuliaLang/utf8proc/archive/v%{version}.tar.gz#/%{name}-v%{version}.tar.gz
+Source:
https://github.com/JuliaLang/utf8proc/archive/v%{version}/utf8proc-%{version}.tar.gz
BuildRequires: gcc
%description
@@ -21,12 +23,12 @@
This package only contains the C library.
-%package devel
+%package -n utf8proc-devel
Summary: Header files, libraries and development documentation for
%{name}
Group:Development/Libraries
-Requires: %{name}%{?_isa} = %{version}-%{release}
+Requires: utf8proc%{?_isa} >= %{version}-%{release}
-%description devel
+%description -n utf8proc-devel
Contains header files for developing applications that use the %{name}
library.
@@ -35,7 +37,7 @@
strings, unless you want to allocate memory yourself.
%prep
-%setup -qn %{name}-%{version}
+%setup -qn utf8proc-%{version}
# Disable slow tests and tests which require network access
sed -i '/-C bench/d;/\ttest.* data/d' Makefile
touch data/NormalizationTest.txt data/GraphemeBreakTest.txt
touch data/NormalizationTest.txt data/GraphemeBreakTest.txt
@@ -50,19 +52,16 @@
%install
make install DESTDIR=%{buildroot} prefix=%{_prefix}
includedir=%{_includedir} libdir=%{_libdir}
rm %{buildroot}%{_libdir}/libutf8proc.a
+rm %{buildroot}%{_libdir}/libutf8proc.so.*
-%post -p /sbin/ldconfig
-%postun -p /sbin/ldconfig
-
-%files
-%doc LICENSE.md NEWS.md README.md
-%{_libdir}/libutf8proc.so.*
-
-%files devel
+%files -n utf8proc-devel
%{_includedir}/utf8proc.h
%{_libdir}/libutf8proc.so
%changelog
+* Wed Sep 22 2021 Orion Poplawski - 2.1.1-5
+- EPEL -devel only package
+
* Mon Aug 05 2019 Lubos Uhliarik - 2.1.1-5
- Resolves: #1696354 - Ensure modular RPM upgrade path
Comments?
--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems 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@
[EPEL-devel] modular bugzilla components
The "zabbix" package exists in EPEL8 in two forms: zabbix40 - non-module 4.0 package. zabbix - module with 5.0 stream. Because the "zabbix" dist-git does not have a epel8 branch, there is no "zabbix" component in bugzilla for EPEL8. Should I create an epel8 branch but then retire it just to create a bugzilla component? Or something else? -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Xfce 4.16 on EPEL-8
On 2/7/21 8:56 AM, Mukundan Ragavan wrote: Hi all, I have a COPR containing xfce 4.16 packages for EPEL-8 packages [0]. I would like to get some testing done using this COPR before getting into EPEL-8. Please email if and when you notice problems and I will try to fix it as soon as possible. As a reminder - xfce 4.16 will be available in F34. Mukundan - Just a note that as mentioned on the CentOS list here: https://lists.centos.org/pipermail/centos/2021-February/353317.html # dnf group install Xfce Last metadata expiration check: 0:02:24 ago on Mon 15 Feb 2021 03:41:53 PM MST. No match for group package "NetworkManager-gnome" No match for group package "thunar-archive-plugin" So perhaps the comps file needs to get cleaned up? And then possibly new with the copr seems to be: Problem: cannot install the best candidate for the job - nothing provides pulseaudio-daemon needed by xfce4-pulseaudio-plugin-0.4.3-5.el8.x86_64 Thanks for working on Xfce for EPEL, much appreciated. -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Status of KDE in EPEL8
As noted in the CentOS list: https://lists.centos.org/pipermail/centos/2021-February/353324.html # dnf group install "KDE Plasma Workspaces" Last metadata expiration check: 3:50:42 ago on Sun 14 Feb 2021 04:52:10 PM MST. no group '3d-printing' from environment 'kde-desktop-environment' no group 'cloud-management' from environment 'kde-desktop-environment' no group 'firefox' from environment 'kde-desktop-environment' no group 'kde-telepathy' from environment 'kde-desktop-environment' No match for group package "dnfdragora" No match for group package "kmail" No match for group package "korganizer" No match for group package "kget" No match for group package "k3b-extras-freeworld" No match for group package "kaddressbook" No match for group package "plasma-discover" No match for group package "akregator" No match for group package "kontact" No match for group package "qt-at-spi" No match for group package "pinentry-qt" No match for group package "NetworkManager-config-connectivity-fedora" This isn't a great look. I've submitted a pull request for the epel8 comps here: https://pagure.io/fedora-comps/pull-request/608 to remove the missing components. Perhaps we want to make a push to add some of these missing items first? I don't use any of these so I'm not particularly interested. Comments? Orion -- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/13/20 10:37 AM, Orion Poplawski wrote:
On 12/11/20 5:04 PM, Miro Hrončok wrote:
On 12/12/20 12:12 AM, Troy Dawson wrote:
We discussed this in the EPEL Steering Committee this week, and your
way has alot less "mess with the server and modules" work.
It would probably get us up to 75% of the missing packages.
If people who have been waiting for packages want to give this a try
and show what they did for others to follow, that would be great.
I'll probrubly do it for some of the packages I want. And see what
type of scripts, patches, and other things are needed.
Let me know if you have a devel package in mind and I can give it a try.
Can we just jump in and try this out? I'd like to get qpdf-devel
available.
Here's what I have for a diff so far for qpdf-devel:
--- /export/home/orion/centos/qpdf/SPECS/qpdf.spec 2020-12-13
10:39:15.439288925 -0700
+++ qpdf-devel.spec 2020-12-13 10:52:37.567863216 -0700
@@ -1,5 +1,7 @@
+%global debug_package %{nil}
+
Summary: Command-line tools and library for transforming PDF files
-Name:qpdf
+Name:qpdf-devel
Version: 7.1.1
Release: 10%{?dist}
# MIT: e.g. libqpdf/sha2.c
@@ -72,7 +74,7 @@
QPDF Manual
%prep
-%setup -q
+%setup -q -n qpdf-%{version}
# fix 'complete manual location' note in man pages
%patch0 -p1 -b .doc
@@ -99,35 +101,17 @@
make install DESTDIR=%{buildroot}
rm -f %{buildroot}%{_libdir}/libqpdf.la
+rm -rf %{buildroot}/usr/{bin,share} %{buildroot}%{_libdir}/*.so.*
%check
make check
-%post libs -p /sbin/ldconfig
-
-%postun libs -p /sbin/ldconfig
-
%files
-%{_bindir}/fix-qdf
-%{_bindir}/qpdf
-%{_bindir}/zlib-flate
-%{_mandir}/man1/*
-
-%files libs
-%doc README.md TODO ChangeLog
-%license Artistic-2.0
-%{_libdir}/libqpdf*.so.*
-
-%files devel
%doc examples/*.cc examples/*.c
%{_includedir}/*
%{_libdir}/libqpdf*.so
%{_libdir}/pkgconfig/libqpdf.pc
-%files doc
-%{_pkgdocdir}
-
-
%changelog
Seem reasonable? I was able to install the resulting qpdf-devel fine.
--
Orion Poplawski
Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages
On 12/11/20 5:04 PM, Miro Hrončok wrote: On 12/12/20 12:12 AM, Troy Dawson wrote: There is also a problem if a missing package has been specifically blocked by a module. I think libuv-devel is this way. If that happens, wouldn't it be blocked in both scenarios (module+grobisplitter+tagging and devel-only-component)? Or would grobisplitter put them in an additional repo with module_hotfixes=yes? If that's the case, it might be possible to create a separate repo with such packages only and manually tag them there. E.g. after a build I'd do `koji tag epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and the epel8-buildroot-module-hotfixes repo would be available from EPEL 8 Koji/mock builds with module_hotfixes=yes. Yes, unlike the rest of this proposal, it requires some work (on infra to set up this extra repo and on packagers to remember to do the tagging, but that still sounds like less work than the grobisplitter proposal for both groups). Is there any easy way to tell if a package is explicitly blocked vs just not being present. We discussed this in the EPEL Steering Committee this week, and your way has alot less "mess with the server and modules" work. It would probably get us up to 75% of the missing packages. If people who have been waiting for packages want to give this a try and show what they did for others to follow, that would be great. I'll probrubly do it for some of the packages I want. And see what type of scripts, patches, and other things are needed. Let me know if you have a devel package in mind and I can give it a try. Can we just jump in and try this out? I'd like to get qpdf-devel available. If so, I guess I would do: fedpkg request-repo --exception qpdf-devel right? -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Initial attempts to build for Python 3.8 in EPEL8
I'm starting to try to build some EPEL packages for Python 3.8. I've
started some notes here:
https://fedoraproject.org/wiki/EPEL/Python3X
The main points are:
* separate python38-foo repos to allow for independent versions of modules
* Need to override __python3 to build with the proper python
* How do we want to handle the %py3_dist macro? Create a new
%py38_dist? Modify %py3_dist to use another macro rather than hard
coding "python3dist("?
Comments?
--
Orion Poplawski
Manager of NWRA Technical Systems 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
[EPEL-devel] Re: plasma desktop not starting on CentOS 8.3
On 12/9/20 9:27 AM, Orion Poplawski wrote: After updating to CentOS 8.3, my plasma (KDE) desktop is not starting. It seems like X is not starting. Is anyone else seeing this and knows what's happening? I haven't had a chance to dig much deeper myself yet... Orion This was likely triggered by our anti-virus software (don't ask), so unlikely to affect others. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] plasma desktop not starting on CentOS 8.3
After updating to CentOS 8.3, my plasma (KDE) desktop is not starting. It seems like X is not starting. Is anyone else seeing this and knows what's happening? I haven't had a chance to dig much deeper myself yet... Orion -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ 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: argbash
On 8/9/20 4:19 AM, Tom Yates wrote: On Fri, 7 Aug 2020, Troy Dawson wrote: The correct procedure for getting a package into EPEL 8 is to open a bugzilla[1] requesting it. That way it will go to the package maintainer. sorry to ask idiot questions, but what's the correct procedure for opening a bugzilla to request a package in EPEL when the component (specifically, rcs) isn't listed because prior to RHEL8 it was in core RHEL? Then file it in the Fedora product. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds
On 7/7/20 12:09 PM, Neal Gompa wrote: > On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski wrote: >> >> On 6/15/20 1:47 PM, Ben Cotton wrote: >>> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds >>> >>> == Upgrade/compatibility impact == >>> Existing packages can (and most likely will) become FTBFS, but >>> proposal owners will fix as many Fedora packages as possible. However >>> fixing third-party packages is not possible and out of scope. >>> Third-party packagers will need to adapt based on the recommendations >>> noted in this Change. >> >> What's the plan for EPEL8/7 compatibility? >> > > I need to talk to EPEL folks about how to handle this. I'm not sure > exactly what strategy we should take here. I could override the macros > entirely with epel-rpm-macros, which is probably the easiest way to do > it. > Any progress here? This is becoming a large pain point for me. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ 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: Problems with yum update
On 7/16/20 1:59 PM, warron.french wrote: I work in a lab environment that has a proxy somewhere on the network. I have my VMware VM running CentOS8 and have installed the epel-latest-release package. When I execute a generic *yum update *I run into problems. They are here: [root@wsf-owt-dev001:yum.repos.d]# yum update Extra Packages for Enterprise Linux 8 - Playground - x86_64 0.0 B/s | 0 B 00:01 Errors during downloading metadata for repository 'epel-playground': - Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://mirrors.fedoraproject.org/metalink?repo=playground-epel8&arch=x86_64&infra=stock&content=centos [SSL certificate problem: EE certificate key too weak] Error: Failed to download metadata for repo 'epel-playground': Cannot prepare internal mirrorlist: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://mirrors.fedoraproject.org/metalink?repo=playground-epel8&arch=x86_64&infra=stock&content=centos [SSL certificate problem: EE certificate key too weak] I see the curl error, so I try a curl command and also run into problems: [root@wsf-owt-dev001:yum.repos.d]# curl -v https://mirrors.fedoraproject.org/metalink?repo=playground-epel8&arch=x86_64&infra=stock&content=centos [1] 683465 [2] 683466 [3] 683467 [root@wsf-owt-dev001:yum.repos.d]# * Uses proxy env variable https_proxy == 'http://214.3.129.49:80' * Trying 214.3.129.49... * TCP_NODELAY set * Connected to 214.3.129.49 (214.3.129.49) port 80 (#0) * allocate connect buffer! * Establish HTTP proxy tunnel to mirrors.fedoraproject.org:443 <http://mirrors.fedoraproject.org:443> > CONNECT mirrors.fedoraproject.org:443 <http://mirrors.fedoraproject.org:443> HTTP/1.1 > Host: mirrors.fedoraproject.org:443 <http://mirrors.fedoraproject.org:443> > User-Agent: curl/7.61.1 > Proxy-Connection: Keep-Alive > < HTTP/1.0 200 Connection established < * Proxy replied 200 to CONNECT request * CONNECT phase completed! * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CONNECT phase completed! * CONNECT phase completed! * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS alert, bad certificate (554): * SSL certificate problem: EE certificate key too weak * Closing connection 0 curl: (60) SSL certificate problem: EE certificate key too weak More details here: https://curl.haxx.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. [1] Exit 60 curl -v https://mirrors.fedoraproject.org/metalink?repo=playground-epel8 [2]- Done arch=x86_64 [3]+ Done infra=stock I don't know what to do to fix this. Can someone please explain what the problem is on a high level and then what to do about it so that I can learn from this? What's the output of: curl --trace-ascii - 'https://mirrors.fedoraproject.org/metalink?repo=playground-epel8&arch=x86_64&infra=stock&content=centos' -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Gnome 2 for EPEL8
Anyone interested in maintaining some Gnome 2 libraries (at least libgnomeui and deps) in EPEL8? I might if no one else is as someone at work needs it, but I'm hoping that someone with more Gnome experience would be willing. Thanks. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Modules again
On 5/17/20 6:34 AM, Paul Howarth wrote: I'm trying to do a local build of gtkwave for EPEL-8. A koji scratch build somehow works: http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837 But a local build does not: $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm ... Error: Problem: conflicting requests - package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is excluded - package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is excluded Adding a repo with a local build of Judy doesn't help; that gets excluded too. Any clues? Paul. Judy-devel appears to be part of the mariadb-devel module. Locally I can do: dnf module enable mariadb-devel dnf install Judy-devel This was discovered with: dnf module provides Judy-devel on RHEL 8.2, though that does not appear to work on CentOS 8.1. For mock, this seems to work: mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel --config-opts module_enable= gtkwave-3.3.104-2.el8.src.rpm or add to /etc/mock/templates/centos-8.tpl: config_opts['module_enable'] = ['mariadb-devel'] koji does some magic to essentially auto-enable some modules that I don't believe mock has. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Updating CMake in EPEL-8: How to create a module?
On 5/15/20 8:32 AM, Alexander Korsunsky wrote: Has anyone asked if CMake could be updated in RHEL yet? This would be the absolute best option here, but it depends on the benevolence of Red Hat. I don't have a subscription and I don't know how to ask them for a rebase without one. Maybe there's some kind of process for getting stuff into CentOS Stream? So far the interaction with upstream seems to be limited to "create an issue on Bugzilla". That would be my suggestion: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=cmake -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: What to do about python 3.4 in EPEL7?
On 5/6/20 4:31 AM, Miro Hrončok wrote:
On 06. 05. 20 3:39, Orion Poplawski wrote:
This is related to my breaking of various packages by dropping
python34-six. Should we:
- re-add python34-six
For now, yes please. This will need a big announcement and coordination,
in the meantime, users are impacted.
Agreed - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d06905e9a7
- Make an announcement and start removing python34- from EPEL7
starting with:
# repoquery --whatrequires python34-six --recursive --disablerepo=*
--enablerepo=epel* | sort -u
python34-dateutil-1:2.4.2-5.el7.noarch
python34-httmock-0:1.2.6-2.el7.noarch
python34-mock-0:2.0.0-2.el7.noarch
python34-pyvirtualize-0:0.10-2.20191018gitdc2d971.el7.noarch
python34-pyvmomi-0:6.7.3-4.el7.noarch
python34-requests-0:2.14.2-2.el7.noarch
python34-slack_cleaner-0:0.5.0-2.el7.noarch
python34-slacker-0:0.12.0-4.el7.noarch
python34-urllib3-0:1.25.6-1.el7.noarch
python36-collada-0:0.4-16.el7.noarch
slack-cleaner-0:0.5.0-2.el7.noarch
Upstream python 3.4 is EOL.
See https://pagure.io/epel/issue/70
This has been already proposed 9 months ago. It "just" needs somebody to
drive it.
I am happy to *help*, but I am not available to coordinate this.
$ repoquery --repo=epel7 --whatrequires python34
avogadro2-0:1.90.0-7.el7.x86_64
python34-Cython-0:0.28.5-1.el7.x86_64
python34-HepMC3-0:3.2.1-2.el7.x86_64
python34-HepMC3-rootIO-0:3.2.1-2.el7.x86_64
python34-HepMC3-search-0:3.2.1-2.el7.x86_64
python34-PyYAML-0:3.12-1.el7.x86_64
python34-apsw-0:3.7.17.r1-3.el7.x86_64
python34-argcomplete-0:1.7.0-4.el7.noarch
python34-asn1crypto-0:0.24.0-7.el7.noarch
python34-backports-ssl_match_hostname-0:3.5.0.1-1.el7.noarch
python34-blosc-0:1.2.8-5.el7.x86_64
python34-bottle-0:0.12.13-3.el7.noarch
python34-bsddb3-0:6.2.6-4.el7.x86_64
python34-certifi-0:2018.10.15-5.el7.noarch
python34-chardet-0:3.0.4-1.el7.noarch
python34-click-0:6.7-8.el7.noarch
python34-coverage-0:4.0.3-5.el7.x86_64
python34-cups-0:1.9.74-4.el7.x86_64
python34-dateutil-1:2.4.2-5.el7.noarch
python34-debug-0:3.4.10-4.el7.x86_64
python34-devel-0:3.4.10-4.el7.x86_64
python34-docutils-0:0.14-1.el7.noarch
python34-empy-0:3.3.3-2.el7.noarch
python34-httmock-0:1.2.6-2.el7.noarch
python34-idna-0:2.7-2.el7.noarch
python34-iso3166-0:1.0.1-1.el7.noarch
python34-jinja2-0:2.11.1-1.el7.noarch
python34-jsmva-0:6.20.04-1.el7.noarch
python34-jupyroot-0:6.20.04-1.el7.x86_64
python34-lark-parser-0:0.7.1-1.el7.noarch
python34-leveldb-0:0.194-2.el7.x86_64
python34-lhapdf-0:6.2.1-6.el7.x86_64
python34-libs-0:3.4.10-4.el7.x86_64
python34-markdown-0:2.4.1-4.el7.noarch
python34-markupsafe-0:0.23-3.el7.x86_64
python34-mock-0:2.0.0-2.el7.noarch
python34-nose-0:1.3.7-4.el7.noarch
python34-numpy-0:1.12.1-3.el7.x86_64
python34-numpy-f2py-0:1.12.1-3.el7.x86_64
python34-parso-0:0.3.1-2.el7.noarch
python34-pbr-0:4.2.0-3.el7.noarch
python34-pip-0:8.1.2-12.el7.noarch
python34-prelude-0:5.1.1-1.el7.x86_64
python34-preludedb-0:5.1.0-2.el7.x86_64
python34-prettytable-0:0.7.2-19.el7.noarch
python34-process-tests-0:1.0.0-11.el7.noarch
python34-psutil-0:5.6.7-1.el7.x86_64
python34-psycopg2-0:2.7.7-2.el7.x86_64
python34-psycopg2-tests-0:2.7.7-2.el7.x86_64
python34-py-0:1.4.32-2.el7.noarch
python34-py4j-0:0.10.7-4.el7.noarch
python34-pycryptodomex-0:3.9.7-1.el7.x86_64
python34-pycurl-0:7.43.0-7.el7.x86_64
python34-pygments-0:2.2.0-3.el7.noarch
python34-pygraphviz-0:1.3-2.rc2.el7.2.x86_64
python34-pyscard-0:1.9.7-1.el7.x86_64
python34-pysocks-0:1.6.8-7.el7.noarch
python34-pytest-0:2.9.2-4.el7.noarch
python34-pytest-cov-0:2.5.1-3.el7.noarch
python34-pythia8-0:8.2.43-1.el7.x86_64
python34-pyvirtualize-0:0.10-2.20191018gitdc2d971.el7.noarch
python34-pyvmomi-0:6.7.3-4.el7.noarch
python34-requests-0:2.14.2-2.el7.noarch
python34-rfc3986-0:1.3.0-1.el7.noarch
python34-root-0:6.20.04-1.el7.x86_64
python34-setuptools-0:39.2.0-4.el7.noarch
python34-setuptools_scm-0:1.17.0-3.el7.noarch
python34-slack_cleaner-0:0.5.0-2.el7.noarch
python34-slacker-0:0.12.0-4.el7.noarch
python34-snowballstemmer-0:1.2.1-9.el7.noarch
python34-sphinx-0:1.2.3-6.el7.noarch
python34-sqlalchemy-0:1.1.3-3.el7.x86_64
python34-tabulate-0:0.8.3-8.el7.noarch
python34-test-0:3.4.10-4.el7.x86_64
python34-tkinter-0:3.4.10-4.el7.x86_64
python34-tools-0:3.4.10-4.el7.x86_64
python34-urllib3-0:1.25.6-1.el7.noarch
python34-uwsgidecorators-0:2.0.17.1-2.el7.x86_64
python34-virtualenv-0:15.1.0-5.el7.noarch
python34-whoosh-0:2.7.4-5.el7.noarch
python34-xrootd-1:4.11.3-1.el7.x86_64
slack-cleaner-0:0.5.0-2.el7.noarch
uwsgi-plugin-python34-0:2.0.17.1-2.el7.x86_64
$ repoquery --repo=epel7{,-source} --whatrequires python34-devel
HepMC3-0:3.2.1-2.el7.src
lhapdf-0:6.2.1-6.el7.src
libprelude-0:5.1.1-1.el7.src
libpreludedb-0:5.1.0-2.el7.src
py4j-0:0.10.7-4.el7.src
pyscard-0:1.9.7-1.el7.src
pythia8-0:8.2.43-1.el7.src
python-apsw-0:3.7.17.r1-3.el7.src
python-argcomplete-0:1.7.0-4.el7.src
python-asn1crypto-0:0.24.0-7.el7.src
python-blosc-0:1.2.8-5.el7.src
python-bottle-0:0.12.13-3.el7.
[EPEL-devel] What to do about python 3.4 in EPEL7?
This is related to my breaking of various packages by dropping python34-six. Should we: - re-add python34-six - Make an announcement and start removing python34- from EPEL7 starting with: # repoquery --whatrequires python34-six --recursive --disablerepo=* --enablerepo=epel* | sort -u python34-dateutil-1:2.4.2-5.el7.noarch python34-httmock-0:1.2.6-2.el7.noarch python34-mock-0:2.0.0-2.el7.noarch python34-pyvirtualize-0:0.10-2.20191018gitdc2d971.el7.noarch python34-pyvmomi-0:6.7.3-4.el7.noarch python34-requests-0:2.14.2-2.el7.noarch python34-slack_cleaner-0:0.5.0-2.el7.noarch python34-slacker-0:0.12.0-4.el7.noarch python34-urllib3-0:1.25.6-1.el7.noarch python36-collada-0:0.4-16.el7.noarch slack-cleaner-0:0.5.0-2.el7.noarch Upstream python 3.4 is EOL. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Looking for someone to take ngircd in EPEL
On 5/1/20 8:39 AM, Kevin Fenzi wrote: On Thu, Apr 30, 2020 at 08:39:48PM -0600, Orion Poplawski wrote: Anyone willing to take over ngircd for EPEL? https://bugzilla.redhat.com/show_bug.cgi?id=1830182 Sure. I can do that. Will add it to my list. kevin ___ Thanks, kevin! -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Looking for someone to take ngircd in EPEL
Anyone willing to take over ngircd for EPEL? https://bugzilla.redhat.com/show_bug.cgi?id=1830182 -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] EPEL 8 python builds broken
python38-rpm-macros brought into EPEL8.2 buildroot causing problems. See: https://pagure.io/epel/issue/103 -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Cannot retire epel7 package
zabbix22 (epel7)]$ fedpkg retire 'Zabbix 2.2 is no longer maintained upstream' Fedora release (epel7) is in state 'current' - retire operation is not allowed. What's up? -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: EPEL8 conflict policy
On 4/8/20 7:20 PM, Orion Poplawski wrote:
There does not appear to be an explicit conflict policy for EPEL8:
https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F
I got a report against python3-s3transfer and python3-botocore
conflicting with the CentOS 8 HighAvailability repo. No idea if this is
an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630
It looks like we have avoided conflicts with the "ha" repos in the past,
and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my
RHEL8 developer license machine so it does seem available to everyone.
yum list --showduplicates | awk '$1 == lastpkg && (lastrepo == "epel"
|| $3 == "epel" ) { print $0; print last;}; { last = $0; lastpkg = $1;
lastrepo = $3 };'
Other conflicts with HA:
python3-boto3.noarch 1.10.21-1.el8
epel
python3-boto3.noarch 1.6.1-2.el8
rhel-8-for-x86_64-highavailability-rpms
python3-botocore.noarch 1.13.21-1.el8
epel
python3-botocore.noarch 1.9.1-2.el8
rhel-8-for-x86_64-highavailability-rpms
python3-fasteners.noarch 0.14.1-20.el8
epel
python3-fasteners.noarch 0.14.1-14.el8
rhel-8-for-x86_64-highavailability-rpms
python3-google-api-client.noarch 1:1.6.7-10.el8
epel
python3-google-api-client.noarch 1.6.5-3.el8
rhel-8-for-x86_64-highavailability-rpms
python3-oauth2client.noarch 4.1.3-9.el8
epel
python3-oauth2client.noarch 4.1.2-6.el8
rhel-8-for-x86_64-highavailability-rpms
python3-s3transfer.noarch0.2.1-1.el8
epel
python3-s3transfer.noarch0.1.13-1.el8
rhel-8-for-x86_64-highavailability-rpms
python3-uritemplate.noarch 3.0.0-10.el8
epel
python3-uritemplate.noarch 3.0.0-3.el8
rhel-8-for-x86_64-highavailability-rpms
With appstream:
python3-psutil.x86_645.6.3-5.el8
epel
python3-psutil.x86_645.4.3-10.el8
rhel-8-for-x86_64-appstream-rpms
From 8.2 beta:
dwarves.x86_64 1.15-5.el8
codeready-builder-beta-for-rhel-8-x86_64-rpms
dwarves.x86_64 1.15-4.el8
epel
libzstd.x86_64 1.4.4-1.el8
epel
libzstd.x86_64 1.4.2-2.el8
rhel-8-for-x86_64-baseos-beta-rpms
libzstd-devel.x86_64 1.4.4-1.el8
epel
libzstd-devel.x86_64 1.4.2-2.el8
rhel-8-for-x86_64-baseos-beta-rpms
perl-Convert-ASN1.noarch 0.27-17.el8
rhel-8-for-x86_64-appstream-beta-rpms
perl-Convert-ASN1.noarch 0.27-16.el8
epel
perl-LDAP.noarch 1:0.66-7.el8
rhel-8-for-x86_64-appstream-beta-rpms
perl-LDAP.noarch 1:0.66-5.el8
epel
python3-psutil.x86_645.6.3-5.el8
epel
python3-psutil.x86_645.4.3-10.el8
rhel-8-for-x86_64-appstream-beta-rpms
whois.x86_64 5.5.1-2.el8
rhel-8-for-x86_64-appstream-beta-rpms
whois.x86_64 5.5.1-1.el8
epel
whois-nls.noarch 5.5.1-2.el8
rhel-8-for-x86_64-appstream-beta-rpms
whois-nls.noarch 5.5.1-1.el8
epel
zstd.x86_64 1.4.4-1.el8
epel
zstd.x86_64 1.4.2-2.el8
rhel-8-for-x86_64-appstream-beta-rpms
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-
[EPEL-devel] EPEL8 conflict policy
There does not appear to be an explicit conflict policy for EPEL8: https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F I got a report against python3-s3transfer and python3-botocore conflicting with the CentOS 8 HighAvailability repo. No idea if this is an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630 It looks like we have avoided conflicts with the "ha" repos in the past, and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my RHEL8 developer license machine so it does seem available to everyone. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: How to support python 3.8 from RHEL 8.2 in EPEL?
On 1/30/20 8:39 AM, Miro Hrončok wrote: On 30. 01. 20 16:32, Orion Poplawski wrote: Folks - Looks like RHEL 8.2 will have python 3.8 in addition to python 3.6. From the 8.2 beta: Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs) Name Stream Profiles Summary python27 2.7 [d][e] common [d] Python programming language, version 2.7 python36 3.6 [d][e] build, common [d] Python programming language, version 3.6 python38 3.8 [d][e] build, common [d] Python programming language, version 3.8 Currently, %python_pkgversion is set to 3 in /usr/lib/rpm/macros.d/macros.python-srpm from python-srpm-macros. python3-devel is still provided only by python36-devel, so presumably all EPEL8 python packages will continue to be built against python 3.6. But I imagine that people will soon be asking for python 3.8 versions of EPEL packages. How can we provide those? Does this have to be done in some modular fashion - which seems to come back to the discussion of whether or not every package has to become its own module or whether to group them together somehow. Or since both python modules are "default" modules and we can install both python36-devel and python38-devel at the same time, perhaps we can define the python3_other* macros again for python38 and just go that way? Thoughts? The idea is that the versions fo stuff we build in RHEL for different python versions is different and I'd like to keep that idea in EPEL as well. Building a python38-foo package from it's own spec should work as follows: BR python38-rpm-macros BR python38-devel BR python38-bar etc... Regular specfile follows. You can even have a single specfile that build for different Python version based on local override of %python_pkgversion in the buildroot. Building both versions from single spec file---single build would require a new set of macros, yes (or hardcoding stuff). However I'd not call them python3_other* unless you want to end up with python3_other_other* the next time this happens. This along with some more info from rhel 8.2 beta yields more questions for me. While I do agree that building the python38 packages from separate specs probably is the best route (biggest reason being it allows for updating of individual module versions) I'm hoping we can brainstorm ways to make this less onerous on individual packagers. Looks like python38-devel is a module in RHEL 8.2 that provides a bunch of stuff needed for building modules (python38-devel, python38-pytest, etc): Red Hat CodeReady Linux Builder Beta for RHEL 8 x86_64 (RPMs) Name Stream Profiles Summary python38-devel 3.8 [e] Python programming language, version 3.8 Since this isn't a default module, does this again mean the python38 packages in EPEL 8 need to be modules as well? Or can we provide a buildroot that enables this module? My current pie-in-the-sky idea is that we could do: - create a epel8-python38 branch for all of the python-* packages with epel8 branches. - epel8-python38 buildroot would enable python38-devel and install python38-rpm-macros and define python3_pkgversion to 38. - This would imply an epel8-python38 repo. It's possible that some packages from epel8-python38 wouldn't be able to be installed unless the python38-devel module was enabled. - This might lead to an explosion of repos if we try to work around other modules in RHEL8 like this (php 7.3, perl, ruby 2.6) Otherwise I think we will need python38 packages in EPEL8 to be modular. If the module route is the way to go, I really do think that we should try to not have every package be its own module, though the other extreme (all packages in one module) probably is untenable as well. In any case, this will require a lot more coordination among packagers (not necessarily a bad thing). Thoughts? Plans? -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] How to support python 3.8 from RHEL 8.2 in EPEL?
Folks - Looks like RHEL 8.2 will have python 3.8 in addition to python 3.6. From the 8.2 beta: Red Hat Enterprise Linux 8 for x86_64 - AppStream Beta (RPMs) Name Stream Profiles Summary python27 2.7 [d][e] common [d] Python programming language, version 2.7 python36 3.6 [d][e] build, common [d] Python programming language, version 3.6 python38 3.8 [d][e] build, common [d] Python programming language, version 3.8 Currently, %python_pkgversion is set to 3 in /usr/lib/rpm/macros.d/macros.python-srpm from python-srpm-macros. python3-devel is still provided only by python36-devel, so presumably all EPEL8 python packages will continue to be built against python 3.6. But I imagine that people will soon be asking for python 3.8 versions of EPEL packages. How can we provide those? Does this have to be done in some modular fashion - which seems to come back to the discussion of whether or not every package has to become its own module or whether to group them together somehow. Or since both python modules are "default" modules and we can install both python36-devel and python38-devel at the same time, perhaps we can define the python3_other* macros again for python38 and just go that way? Thoughts? -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Packaging guidelines
On 12/9/19 7:25 PM, Orion Poplawski wrote: On 12/7/19 1:53 AM, Mattia Verga wrote: I've also seen that there are some files in the newly created epel8 branch: .cvsignore, Makefile and package.cnf. I would like to do a `git merge master` to sync epel8 branch with fedora rawhide, but doing that would delete these files... do I have to checkout every single files one by one from Rawhide? 'git merge master' will not remove or change those files. Or at least won't remove package.cnf unless you had one in master. I'm not sure what's up with the others. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Packaging guidelines
On 12/7/19 1:53 AM, Mattia Verga wrote: I've also seen that there are some files in the newly created epel8 branch: .cvsignore, Makefile and package.cnf. I would like to do a `git merge master` to sync epel8 branch with fedora rawhide, but doing that would delete these files... do I have to checkout every single files one by one from Rawhide? 'git merge master' will not remove or change those files. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: "python3" vs "python%{python3_pkgversion}"
On 12/2/19 4:54 PM, Kevin Fenzi wrote:
On Tue, Dec 03, 2019 at 12:38:01AM +0100, Miro Hrončok wrote:
On 02. 12. 19 23:09, Ken Dreyer wrote:
On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa wrote:
On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer wrote:
Hi folks,
In EPEL 7 we have some packages with "python34" and "python36"
prefixes in their names. I guess this is a consequence of using the
%{python3_pkgversion} macro over time.
Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
EPEL 7, I'm wondering about this.
If I'm introducing a Python 3 subpackage in a new build today, should
I name this sub-package "python3-foo" or
"python%{python3_pkgversion}-foo" ?
The subpackage should be "python%{python3_pkgversion}-foo" and you
should also make sure you have "%{?python_provide:%python_provide
python%{python3_pkgversion}-foo}" in the subpackage declaration too.
This is confusing to me, and it diverges from what Fedora does. Can we
just reduce this down to "python3-" now that RHEL 7 has python3, and
we'll probably never put another Python version into EPEL 7?
We **can** but we **haven't yet**. IMHO doing it in random packages is wrong.
Currently, python36-foo is form EPEL (and if done right, provides python3-foo).
OTOH python3-bar is from RHEL (and if done right, provides python36-bar).
They both provide both names, but from first glance, the origin of the
package is obvious. I kinda like that.
If we decide to redo this, it will be a lot of boring work for no clear benefit.
If we decide to only allow it for new packages, it would be a mess.
That said, technically:
- it works either way
- there is no real EPEL packaging guideline forcing one way or the other
I think we should encourage people to just use python3-foo now, but I
agree it would be a lot of work to try and convert everything to do
that.
The orig reason was so we could move python stacks forward since we were
maintaining them in epel. Since python 3.6 is in rhel and rhel7 is past
the point where I would expect many changes, I think 3.6 is here to
stay, so we dont really need it anymore. It's just extra noise that
makes spec files less readable now.
kevin
I'd like to see some broader discussion about what we might face in the
future with RHEL8 and how we might handle that. I'm also not so sure
that there won't be some kind of push for python 3.8 in EL7 at some
point since EOL is 6/30/2024.
--
Orion Poplawski
Manager of NWRA Technical Systems 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
[EPEL-devel] Re: usbauth package suite for EPEL8
On 11/25/19 3:30 PM, Stefan Koch wrote: Hi I have successfully built my packages of the usbauth package suite for rawhide, f31 and epel8 branches. Currently, the packages are only part of the rawhide repo. How to get these packages copied to the epel8 and of course f31 repo? libusbauth-configparser: https://koji.fedoraproject.org/koji/packageinfo?packageID=30003 usbauth: https://koji.fedoraproject.org/koji/packageinfo?packageID=30004 usbauth-notifier: https://koji.fedoraproject.org/koji/packageinfo?packageID=30005 You submit updates with bodhi: https://bodhi.fedoraproject.org/updates/new https://fedoraproject.org/wiki/Package_update_HOWTO -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: epel8 build failing
On 11/22/19 4:03 AM, Paul Howarth wrote: > On Thu, 21 Nov 2019 21:56:46 -0700 > Orion Poplawski wrote: > >> DEBUG util.py:596: No available modular metadata for modular package >> 'python2-rpm-macros-3-38.module+el8.1.0+3111+de3f2d8e.noarch', it >> cannot be installed on the system >> DEBUG util.py:596: Error: No available modular metadata for modular >> package >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=39186949 > > https://pagure.io/releng/issue/9048 > > Paul. Thanks. Hopefully this will get fixed soon. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] epel8 build failing
DEBUG util.py:596: No available modular metadata for modular package 'python2-rpm-macros-3-38.module+el8.1.0+3111+de3f2d8e.noarch', it cannot be installed on the system DEBUG util.py:596: Error: No available modular metadata for modular package https://koji.fedoraproject.org/koji/taskinfo?taskID=39186949 -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Any plans for supporting multiple python3 versions in EPEL8?
On 11/16/19 8:25 AM, Miro Hrončok wrote: > On 16. 11. 19 3:53, Orion Poplawski wrote: >> I'm wondering if anyone can shed any light on possible roadmaps for >> transitioning to newer python 3.X in RHEL8/EPEL8. What we have now appears >> to be: >> >> A module for different pythonXY versions: >> >> python27 2.7 [d] common [d] Python programming >> language, version 2.7 >> python36 3.6 [d][e] common [d], build Python programming >> language, version 3.6 >> >> A python3Y base package: >> >> python36.x86_64 3.6.8-2.module+el8.1.0+3334+5cb623d7 >> python36-debug.x86_64 >> 3.6.8-2.module+el8.1.0+3334+5cb623d7 python36-devel.x86_64 >> 3.6.8-2.module+el8.1.0+3334+5cb623d7 >> python36-rpm-macros.noarch 3.6.8-2.module+el8.1.0+3334+5cb623d7 >> >> But python3- modules, including: >> >> python3-libs.x86_64 3.6.8-15.1.el8 >> python3-tkinter.x86_64 3.6.8-15.1.el8 >> >> And since: >> >> # rpm -E %python3_pkgversion >> 3 >> >> It seems any transition is going to have to be a hard break and/or we're >> going to need modules. Is there any hope for parallel installable python3Y >> stacks in RHEL8? Are we just going to have python36 forever? > > The EL8 Python modules are planned to be parallel installable. > That's why the module name is python36, not python or python3. > Okay, but what does that actually get us in practice? If I have python36 and python38 installed: - what verion(s) of python3-libs do I have? - what version(s) of python modules from EPEL do I have? With EPEL7 I can have both python34-blah and python36-blah, but with python3_pkgversion = 3 we just have python3-blah in EPEL8 (currently built for 3.6). -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Any plans for supporting multiple python3 versions in EPEL8?
I'm wondering if anyone can shed any light on possible roadmaps for transitioning to newer python 3.X in RHEL8/EPEL8. What we have now appears to be: A module for different pythonXY versions: python27 2.7 [d] common [d] Python programming language, version 2.7 python36 3.6 [d][e]common [d], build Python programming language, version 3.6 A python3Y base package: python36.x86_643.6.8-2.module+el8.1.0+3334+5cb623d7 python36-debug.x86_64 3.6.8-2.module+el8.1.0+3334+5cb623d7 python36-devel.x86_64 3.6.8-2.module+el8.1.0+3334+5cb623d7 python36-rpm-macros.noarch 3.6.8-2.module+el8.1.0+3334+5cb623d7 But python3- modules, including: python3-libs.x86_643.6.8-15.1.el8 python3-tkinter.x86_64 3.6.8-15.1.el8 And since: # rpm -E %python3_pkgversion 3 It seems any transition is going to have to be a hard break and/or we're going to need modules. Is there any hope for parallel installable python3Y stacks in RHEL8? Are we just going to have python36 forever? -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Please don't add Python 2 packages to EPEL 8 unless absolutely necessary
On 11/8/19 9:06 AM, LAHAYE Olivier wrote: And BTW, please add more python3 package in EPEL7 (and EPEL6 before it goes EOL). As a developer, it's very difficult to support (EPEL6) EPEL7 and EPEL8 at the same time. Many python3 packages are missing in EPEL7 and many python2 packages are missing in EPEL8. I'm for move to python3, but current python3 support in epel7 is "poor". (e.g. python3-twisted, python3-cheetah, python3-pyserial, ...) I took fedora packages and they build fine against python36, so the effort should be acceptable IMHO. File bugs for what you need. We're not going to builds things just to do it. Thanks. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: What to do about old packages in epel8-playground
On 11/3/19 12:47 PM, Kevin Fenzi wrote: On Fri, Nov 01, 2019 at 08:06:07AM -0700, Troy Dawson wrote: For KDE, I built all the packages in epel8-playground. At the time, it seemed like the right thing to do. (Whether it was or not is another discussion). I also built several packages in playground that were not part of KDE, but were build and runtime dependencies. Those non-KDE packages, I have been trying to get built on regular epel8 by their normal maintainers. Or building myself if the normal maintainer don't want to support epel8. Question: What do I do about those package currently in -playground, that just got built in regular epel8? The versions may, or may not, be the same. A related question, but not necessarily for this set of packages. What is our plan in a year or two, if a package clearly is maintained in epel8, but abandoned in epel8-playground? Right, so this is what Kanarip was talking about the other day on IRC. Consider the case: - I have foo-1.0-1 in epel8 and epel8-playground - I want to play with foo-2.0 in playground, so I tweak packages.cfg and build it in playground. - Later I decide its stable so I build foo-2.0-1 in epel8. - A update comes out to 2.1, so I build foo-2.1-1 in epel8, but I didn't put the packages.cfg back and the version in epel8-playground is now foo-2.0-1 still. - I later try and build bar-2.0 in epel8-playground, and it builds against foo-2.0-1 instead of foo-2.1 I guess the expectation is that the maintainer should put the packages.cfg back in place when merging back to epel8, but I could see this getting forgotten. So, perhaps the best way forward here is some reporting? ie, check upgrade path between all epel8 and epel8-playground packages. The playgound ones should always upgrade the epel8 one. kevin I guess I don't see why anyone needs to muck with packages.cfg. If you want to build something for epel8-playground, just build it from the epel8-playground branch. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] How do we want to handle ruby gems in EPEL8?
Do we have a plan for how we want to handle ruby gems in EPEL8? ruby is a module in RHEL8 so it seems like we would want to do that it a modular way, which also suggests the possibility of a group effort to produce a "EPEL8 rubygems" module. Or just dump them into the main repo, at least for now. Or something else? We currently have some ruby packages in epel directly, and some just in playground: ruby-caca 0.99-0.43.beta19.el8 ruby-caca 0.99-0.43.beta19.epel8.playground rubygem-builder3.2.3-6.el8 rubygem-hpricot0.8.6-26.epel8.playground rubygem-introspection 0.0.4-6.el8 rubygem-metaclass 0.0.4-8.el8 rubygem-mustache 1.0.2-8.epel8.playground rubygem-qpid_proton0.29.0-1.epel8.playground rubygem-rake-compiler 1.0.7-3.epel8.playground.1 rubygem-rdiscount 2.2.0.1-5.epel8.playground rubygem-ronn 0.7.3-13.epel8.playground ruby-caca gets built from libcaca - not sure how those kinds of libraries should be handled. Currently I'm holding off building shapelib (and thus plplot) for EPEL8 directly due to its dependency on rubygem-ronn (and its deps) until we sort this out. Thanks! -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: python3-rpm-macros
On 10/8/19 7:32 PM, Orion Poplawski wrote: I retired this: https://bodhi.fedoraproject.org/overrides/python-rpm-macros-3-31.el7 To allow epel 7 builds get the RHEL7.7 3-32.el7 version. As a heads up - this will cause %py3_build to use /usr/bin/python3 rather than /usr/bin/python3.6 - which can have some interesting side effects on packages. Notably, numpy generates /usr/bin/f2py3 rather than /usr/bin/f2py3.6. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] python3-rpm-macros
I retired this: https://bodhi.fedoraproject.org/overrides/python-rpm-macros-3-31.el7 To allow epel 7 builds get the RHEL7.7 3-32.el7 version. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: libssh2 issues in EPEL8 buildroot
On 8/14/19 6:40 PM, Stephen John Smoogen wrote: On Wed, 14 Aug 2019 at 18:07, Orion Poplawski wrote: I see virt modules (from dnf module info virt): 820190510171727 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 820190516125745 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 820190529063309 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 820190618154454 - libssh2-0:1.8.0-7.module+el8.0.0.z+3418+a72cf898.1 820190226174025 - libssh2-0:1.8.0-7.module+el8+2833+c7d6d092 and virt-devel: 820190226174025: - libssh2-devel-0:1.8.0-7.module+el8+2833+c7d6d092 Seems to me like the EPEL8 builder is failing to pick up 820190226174025 virt module - possibly because the version does not sort higher than 820190618154454 ? Which seems perfectly understandable to me, but I have no idea how this is all supposed to work. Okay, I see your point now - we're missing the 820190618154454 virt-devel module... FWIW - I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1741362 Yeah the problem is that the 2 sets of modules have to match up for this work. We could try to keep the old one for building but I believe it has cve's in it. I think in the end I may just remove the virt-devel from the build system until they get it fixed as it is not helping in anyway. This appears to be resolved now with the release of 820190828150510 -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1
On 8/26/19 2:33 AM, Petr Pisar wrote: On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote: So, I see the following options for how to handle default streams in RHEL 8 Option 1: We disallow assigning default streams at all within EPEL 8. This will protect us against a future change where RHEL wants to set a default. Additionally, it means that all EPEL modules are explicitly opt-in and so we don't ever surprise anyone. Option 2: We allow making EPEL streams the default stream if RHEL does not currently provide a default stream. We set strict policy regarding what a default stream may contain (such as "must not replace any package provided by RHEL 8"). If RHEL later decides to set a default for this stream, the RHEL release engineering must ensure that the `data.version` value is higher than what EPEL 8 carries. I'm somewhat more in favor of Option 1 here, mostly because it minimizes the chance of conflicts and ensures the opt-in nature of EPEL. But I'm willing to hear counter-arguments. I don't like the Option 1. It makes adding modularized packages into a build root impossible. Efectivelly forcing everbody to modularize everything or nothing. That's exactly the deficiency the modularity has in Fedora and does not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in Fedora. Example: RHEL has two perl streams: perl:5.24 perl:5.26 [d] You can add a non-modular perl-Foo package into EPEL bacause EPEL magically adds perl:5.26 into the build root. If you add a perl-Foo module into EPEL, you won't be able to set a default stream, hence you won't be able to have it in the build root and therefore you won't be able to add a non-modular perl-Bar package that requires a perl-Foo module component into EPEL. The only solution would be either add perl-Bar as a module, or not add perl-Foo as a module. If you go the second path (i.e. no modules), it means you won't be able build none of the packages for the non-default streams (i.e. perl:5.24). That effectively pushes modules into the role of leaf-only dependencies. That's quite awkward situation if you consider that RHEL delivers language runtimes as modules. The proposed EPEL policy would devalute the non-default runtimes. -- Petr What if we could have "slave" modules? I.e. "epel-perl" that would acquire the state of the "perl" module and could contain the EPEL perl packages. This would require coordination among the EPEL perl packagers to maintain the epel-perl module but would also allow it to automatically track the state of the RHEL module - and allow it to have a default stream. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: KDE now available on EPEL 8 ... playground
On 9/20/19 7:41 AM, Troy Dawson wrote: > On Fri, Sep 20, 2019 at 6:12 AM Troy Dawson wrote: >> >> On Thu, Sep 19, 2019 at 9:09 PM Orion Poplawski wrote: >>> >>> On 9/3/19 3:01 PM, Troy Dawson wrote: >>>> # KDE now available on EPEL 8 playground >>>> >>>> Many thanks to all those who have helped make this happen. >>> >>> Thanks! >>> >>>> [3] - Currently gdm does not like to start plasma, use sddm instead >>> >>> Is there a bug for this I can follow? >>> >> Never thought of opening one, but it's a good idea. >> I won't be able to test this for another week. Would you (or anyone >> else) test to see if gdm works with plasma yet, and if not, file a >> bugzilla. >> For me, the problem was that plasma would show up in the list, but it >> wouldn't do anything. I'm assuming it was simply calling the wrong >> thing to start it, or permissions. I never investigated to much since >> I wanted to include sddm anyway. >> > > Huh ... it's working now. > Though that was on a machine that already had sddm installed, and had > booted KDE previously. I'll have to test on a fresh machine. > Seems to work fine here as well. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: KDE now available on EPEL 8 ... playground
On 9/3/19 3:01 PM, Troy Dawson wrote: # KDE now available on EPEL 8 playground Many thanks to all those who have helped make this happen. Thanks! [3] - Currently gdm does not like to start plasma, use sddm instead Is there a bug for this I can follow? -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] please help with epel8 branches
The epel8 branches were not properly created for hypre and superlu_dist. They were apparently made in the PDC, but they don't exist in pagure. What to do now? Thanks. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: New release of Mock (fixes and subscription-manager support)
On 8/27/19 9:08 AM, Stephen John Smoogen wrote: On Tue, 27 Aug 2019 at 10:20, Miroslav Suchý wrote: Hi, I released new version of Mock and mock-core-configs. For full release notes see: https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.18 I just submitted packages to Bodhi. I would like to point two things here: 1) It should fixes all those issues you reported in past days (selinux, rprivate, groupadd). 2) Mock now supports subscription-manager, which allows you to build packages for RHEL with cost-free developer license. No need to wait for CentOS 8. Big thanks to Pavel Raiskup who done those two things. Note that this drops python2 support. You will need Python36 on any system using. Also note that mock will no longer be targeted to build on EL-7 systems sometime next spring (2020). I believe this means that mock will no longer be supported or built in EPEL-7 as it is probably no longer built in EPEL-6 these days. You will need to use EL-8 boxes to build but can target EL-6/EL-7 builds. [I don't know if you can build EL-5 but I know people need to do so still so I am not sure how to do that.] Well, building much of anything new in Fedora land on EL-7 seems pretty much impossible due to rpm changes so the useful lifetime of EL-7 for a Fedora and EPEL contributor is already essentially at an end. Centos 8 can't come fast enough... -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ 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: Getting packages into EPEL-8
On 8/16/19 8:16 PM, Orion Poplawski wrote: On 8/16/19 12:16 AM, willi.feh...@t-online.de wrote: Dear EPEL developers, I would like to request a handful of packages for EPEL-8. Name of the packages and short description and a reason why the package is needed. *Fail2Ban:* Fail2Ban is an Intrusion Prevention Software which protects systems from brute-force attacks. It's already available in EPEL-7 and it's actively used so I guess it make sense to push an .el8 package. This is on my incredibly long list of things to do. Any help is appreciated... https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-4338446786 -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ 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: Getting packages into EPEL-8
On 8/16/19 12:16 AM, willi.feh...@t-online.de wrote: Dear EPEL developers, I would like to request a handful of packages for EPEL-8. Name of the packages and short description and a reason why the package is needed. *Fail2Ban:* Fail2Ban is an Intrusion Prevention Software which protects systems from brute-force attacks. It's already available in EPEL-7 and it's actively used so I guess it make sense to push an .el8 package. This is on my incredibly long list of things to do. Any help is appreciated... -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ 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: Automatic python dependency generation on EPEL 8
On 8/16/19 7:45 PM, Scott Talbert wrote: Is automatic python dependency generation supposed to work on EPEL 8? It seems to be working for me - not sure what the "official" stance is. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Missing arches on EPEL 8 for LibRaw?
(Moving to EPEL list) On 8/15/19 10:22 PM, Richard Shaw wrote: I assume this is because LibRaw is available in RHEL but only for x86_64 and ppc64le? So I'm assuming there is some sort of procedure to build only for s390x and aarch64 for EPEL? Yes, many libs appear to be missing on those arches. ExcludeArch: aarch64 s390x seems to be the thing to do. We have a limited arch policy for EPEL6/7, but I'm not sure if we want to continue that for EPEL8. https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ 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 8 not finding buildroot overrides
On 8/15/19 7:31 AM, Troy Dawson wrote: > Oh ... then there really is a problem. 12 hours (or longer) is a very > long time for a package to not make it into the repo. The longest I > had to wait was 4 hours, because I was doing things in the middle of > the F31 mass rebuild. > I'm afraid helping with this is above my fedora permissions. I cannot > do a koji regen-repo. > > On Wed, Aug 14, 2019 at 5:54 PM Richard Shaw wrote: >> >> Here's the link... >> >> https://bodhi.fedoraproject.org/overrides/hdf5-1.10.5-3.el8 >> >> Which is showing as active. >> >> Thanks, >> Richard Sometimes things go awry... What I've found is that expiring the override and then re-submitting it (with a later date as required) often works. I just did this with the hdf5 update and it appears to be working now. - Orion -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] What to do about missing gcc-objc from RHEL8?
What to do about missing gcc-objc from RHEL8? Are there alternative compilers yet that we can access? Will we have to package gcc-objc for EPEL8 separately? -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: libssh2 issues in EPEL8 buildroot
On 8/14/19 3:35 PM, Orion Poplawski wrote: > On 8/14/19 3:26 PM, Orion Poplawski wrote: >> On 8/14/19 2:54 PM, Stephen John Smoogen wrote: >>> On Wed, 14 Aug 2019 at 16:01, Orion Poplawski wrote: >>>> >>>> My zabbix40 build for epel8 failed: >>>> >>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=37041678 >>>> >>>> DEBUG util.py:585: BUILDSTDERR: Error: >>>> DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests >>>> DEBUG util.py:585: BUILDSTDERR: - nothing provides libssh2(x86-64) = >>>> 1.8.0-7.module+el8+2833+c7d6d092 needed by >>>> libssh2-devel-1.8.0-7.module+el8+2833+c7d6d092.x86_64 >>>> >>> >>> Argh. I thought they fixed this in RHEL. The problem is that they did >>> not rebuild the virt-devel module so the version shipped in RHEL >>> currently is >>> >>> ./RHEL-8-001/virt:rhel:820190618154454:f8e95b4e:x86_64/libssh2-1.8.0-7.module+el8.0.0.z+3418+a72cf898.1.x86_64.rpm >>> >>> but the version they ship in CRB is: >>> >>> ./RHEL-8-001/virt-devel:rhel:820190226174025:9edba152:x86_64/libssh2-devel-1.8.0-7.module+el8+2833+c7d6d092.x86_64.rpm >>> >>> This is a RHEL issue versus anything we can fix :/. >>> >>>> On my RHEL8 VM: >>>> >>>> # dnf repoquery --whatprovides 'libssh2(x86-64) = >>>> 1.8.0-7.module+el8+2833+c7d6d092' >>>> libssh2-0:1.8.0-7.module+el8+2833+c7d6d092.x86_64 >>>> >>>> There appear to be 3 different libssh2 builds: >>>> >>>> libssh2.x86_64 1.8.0-7.module+el8.0.0.z+3418+a72cf898.1 >>>> rhel-8-for-x86_64-appstream-rpms >>>> libssh2.x86_64 1.8.0-7.module+el8.0.0+3075+09be6b65.1 >>>> rhel-8-for-x86_64-appstream-rpms >>>> libssh2.x86_64 1.8.0-7.module+el8+2833+c7d6d092 >>>> rhel-8-for-x86_64-appstream-rpms >>>> >>>> Is it possible that an odd combination of them are ending up in the EPEL8 >>>> buildroot? >>>> >>>> The other odd thing is that I cannot install libssh2-devel on my RHEL8 vm >>>> because it does not appear to exist: >>>> >>> >>> That is because the version in your VM is seeing the newer >>> libssh2.x86_64 and so there is no libssh2-devel for it to match up >>> with. >>> >>> >>>> # dnf install libssh2-devel >>>> Updating Subscription Management repositories. >>>> Last metadata expiration check: 0:07:30 ago on Wed 14 Aug 2019 03:50:13 PM >>>> EDT. >>>> No match for argument: libssh2-devel >>>> >>>> I've got Code Ready Builder enabled. Anything else needed? >>>> >>>> repo id repo name >>>> status >>>> codeready-builder-for-rhel-8-x86_64-rpms Red Hat CodeReady Linux Builder >>>> for >>>> RHEL 8 x86_64 ( 1,497 >>>> epel Extra Packages for Enterprise >>>> Linux 8 >>>> - x86_64310 >>>> epel-testing Extra Packages for Enterprise >>>> Linux 8 >>>> - Testing - x 202 >>>> rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for >>>> x86_64 >>>> - AppStream ( 5,739 >>>> rhel-8-for-x86_64-baseos-rpmsRed Hat Enterprise Linux 8 for >>>> x86_64 >>>> - BaseOS (RPM 2,097 >>>> rhel-8-for-x86_64-supplementary-rpms Red Hat Enterprise Linux 8 for >>>> x86_64 >>>> - Supplementa20 >> >> >> Hmm, I'm not entirely sure I grok this. After enabling the virt-devel module >> I was able to install libssh2-devel-1.8.0-7.module+el8+2833+c7d6d092 just >> fine. >> >> I see virt modules (from dnf module info virt): >> 820190510171727 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 >> 820190516125745 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 >> 820190529063309 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 >> 820190618154454 - libssh2-0:1.8.0-7.module+el8.0.0.z+3418+a72cf898.1 >> 820190226174025 - libssh2-0:1.8.0-7.module+el8+2833+c7d6d092 >> >> and virt-devel: >> 820190226174025: - libssh2-devel-0:1.8.0-7.module+el8+2833+c7d6d092 >> >> >> Seems to me like the EPEL8 builder is failing to pick up 820190226174025 virt >> module - possibly because the
[EPEL-devel] Re: libssh2 issues in EPEL8 buildroot
On 8/14/19 3:26 PM, Orion Poplawski wrote: > On 8/14/19 2:54 PM, Stephen John Smoogen wrote: >> On Wed, 14 Aug 2019 at 16:01, Orion Poplawski wrote: >>> >>> My zabbix40 build for epel8 failed: >>> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=37041678 >>> >>> DEBUG util.py:585: BUILDSTDERR: Error: >>> DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests >>> DEBUG util.py:585: BUILDSTDERR: - nothing provides libssh2(x86-64) = >>> 1.8.0-7.module+el8+2833+c7d6d092 needed by >>> libssh2-devel-1.8.0-7.module+el8+2833+c7d6d092.x86_64 >>> >> >> Argh. I thought they fixed this in RHEL. The problem is that they did >> not rebuild the virt-devel module so the version shipped in RHEL >> currently is >> >> ./RHEL-8-001/virt:rhel:820190618154454:f8e95b4e:x86_64/libssh2-1.8.0-7.module+el8.0.0.z+3418+a72cf898.1.x86_64.rpm >> >> but the version they ship in CRB is: >> >> ./RHEL-8-001/virt-devel:rhel:820190226174025:9edba152:x86_64/libssh2-devel-1.8.0-7.module+el8+2833+c7d6d092.x86_64.rpm >> >> This is a RHEL issue versus anything we can fix :/. >> >>> On my RHEL8 VM: >>> >>> # dnf repoquery --whatprovides 'libssh2(x86-64) = >>> 1.8.0-7.module+el8+2833+c7d6d092' >>> libssh2-0:1.8.0-7.module+el8+2833+c7d6d092.x86_64 >>> >>> There appear to be 3 different libssh2 builds: >>> >>> libssh2.x86_64 1.8.0-7.module+el8.0.0.z+3418+a72cf898.1 >>> rhel-8-for-x86_64-appstream-rpms >>> libssh2.x86_64 1.8.0-7.module+el8.0.0+3075+09be6b65.1 >>> rhel-8-for-x86_64-appstream-rpms >>> libssh2.x86_64 1.8.0-7.module+el8+2833+c7d6d092 >>> rhel-8-for-x86_64-appstream-rpms >>> >>> Is it possible that an odd combination of them are ending up in the EPEL8 >>> buildroot? >>> >>> The other odd thing is that I cannot install libssh2-devel on my RHEL8 vm >>> because it does not appear to exist: >>> >> >> That is because the version in your VM is seeing the newer >> libssh2.x86_64 and so there is no libssh2-devel for it to match up >> with. >> >> >>> # dnf install libssh2-devel >>> Updating Subscription Management repositories. >>> Last metadata expiration check: 0:07:30 ago on Wed 14 Aug 2019 03:50:13 PM >>> EDT. >>> No match for argument: libssh2-devel >>> >>> I've got Code Ready Builder enabled. Anything else needed? >>> >>> repo id repo name >>> status >>> codeready-builder-for-rhel-8-x86_64-rpms Red Hat CodeReady Linux Builder for >>> RHEL 8 x86_64 ( 1,497 >>> epel Extra Packages for Enterprise >>> Linux 8 >>> - x86_64310 >>> epel-testing Extra Packages for Enterprise >>> Linux 8 >>> - Testing - x 202 >>> rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for >>> x86_64 >>> - AppStream ( 5,739 >>> rhel-8-for-x86_64-baseos-rpmsRed Hat Enterprise Linux 8 for >>> x86_64 >>> - BaseOS (RPM 2,097 >>> rhel-8-for-x86_64-supplementary-rpms Red Hat Enterprise Linux 8 for >>> x86_64 >>> - Supplementa20 > > > Hmm, I'm not entirely sure I grok this. After enabling the virt-devel module > I was able to install libssh2-devel-1.8.0-7.module+el8+2833+c7d6d092 just > fine. > > I see virt modules (from dnf module info virt): > 820190510171727 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 > 820190516125745 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 > 820190529063309 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 > 820190618154454 - libssh2-0:1.8.0-7.module+el8.0.0.z+3418+a72cf898.1 > 820190226174025 - libssh2-0:1.8.0-7.module+el8+2833+c7d6d092 > > and virt-devel: > 820190226174025: - libssh2-devel-0:1.8.0-7.module+el8+2833+c7d6d092 > > > Seems to me like the EPEL8 builder is failing to pick up 820190226174025 virt > module - possibly because the version does not sort higher than > 820190618154454 ? Which seems perfectly understandable to me, but I have > no idea how this is all supposed to work. Okay, I see your point now - we're missing the 820190618154454 virt-devel module... -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: libssh2 issues in EPEL8 buildroot
On 8/14/19 2:54 PM, Stephen John Smoogen wrote: > On Wed, 14 Aug 2019 at 16:01, Orion Poplawski wrote: >> >> My zabbix40 build for epel8 failed: >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=37041678 >> >> DEBUG util.py:585: BUILDSTDERR: Error: >> DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests >> DEBUG util.py:585: BUILDSTDERR: - nothing provides libssh2(x86-64) = >> 1.8.0-7.module+el8+2833+c7d6d092 needed by >> libssh2-devel-1.8.0-7.module+el8+2833+c7d6d092.x86_64 >> > > Argh. I thought they fixed this in RHEL. The problem is that they did > not rebuild the virt-devel module so the version shipped in RHEL > currently is > > ./RHEL-8-001/virt:rhel:820190618154454:f8e95b4e:x86_64/libssh2-1.8.0-7.module+el8.0.0.z+3418+a72cf898.1.x86_64.rpm > > but the version they ship in CRB is: > > ./RHEL-8-001/virt-devel:rhel:820190226174025:9edba152:x86_64/libssh2-devel-1.8.0-7.module+el8+2833+c7d6d092.x86_64.rpm > > This is a RHEL issue versus anything we can fix :/. > >> On my RHEL8 VM: >> >> # dnf repoquery --whatprovides 'libssh2(x86-64) = >> 1.8.0-7.module+el8+2833+c7d6d092' >> libssh2-0:1.8.0-7.module+el8+2833+c7d6d092.x86_64 >> >> There appear to be 3 different libssh2 builds: >> >> libssh2.x86_64 1.8.0-7.module+el8.0.0.z+3418+a72cf898.1 >> rhel-8-for-x86_64-appstream-rpms >> libssh2.x86_64 1.8.0-7.module+el8.0.0+3075+09be6b65.1 >> rhel-8-for-x86_64-appstream-rpms >> libssh2.x86_64 1.8.0-7.module+el8+2833+c7d6d092 >> rhel-8-for-x86_64-appstream-rpms >> >> Is it possible that an odd combination of them are ending up in the EPEL8 >> buildroot? >> >> The other odd thing is that I cannot install libssh2-devel on my RHEL8 vm >> because it does not appear to exist: >> > > That is because the version in your VM is seeing the newer > libssh2.x86_64 and so there is no libssh2-devel for it to match up > with. > > >> # dnf install libssh2-devel >> Updating Subscription Management repositories. >> Last metadata expiration check: 0:07:30 ago on Wed 14 Aug 2019 03:50:13 PM >> EDT. >> No match for argument: libssh2-devel >> >> I've got Code Ready Builder enabled. Anything else needed? >> >> repo id repo name >> status >> codeready-builder-for-rhel-8-x86_64-rpms Red Hat CodeReady Linux Builder for >> RHEL 8 x86_64 ( 1,497 >> epel Extra Packages for Enterprise Linux >> 8 >> - x86_64310 >> epel-testing Extra Packages for Enterprise Linux >> 8 >> - Testing - x 202 >> rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for >> x86_64 >> - AppStream ( 5,739 >> rhel-8-for-x86_64-baseos-rpmsRed Hat Enterprise Linux 8 for >> x86_64 >> - BaseOS (RPM 2,097 >> rhel-8-for-x86_64-supplementary-rpms Red Hat Enterprise Linux 8 for >> x86_64 >> - Supplementa20 Hmm, I'm not entirely sure I grok this. After enabling the virt-devel module I was able to install libssh2-devel-1.8.0-7.module+el8+2833+c7d6d092 just fine. I see virt modules (from dnf module info virt): 820190510171727 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 820190516125745 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 820190529063309 - libssh2-0:1.8.0-7.module+el8.0.0+3075+09be6b65.1 820190618154454 - libssh2-0:1.8.0-7.module+el8.0.0.z+3418+a72cf898.1 820190226174025 - libssh2-0:1.8.0-7.module+el8+2833+c7d6d092 and virt-devel: 820190226174025: - libssh2-devel-0:1.8.0-7.module+el8+2833+c7d6d092 Seems to me like the EPEL8 builder is failing to pick up 820190226174025 virt module - possibly because the version does not sort higher than 820190618154454 ? Which seems perfectly understandable to me, but I have no idea how this is all supposed to work. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] libssh2 issues in EPEL8 buildroot
My zabbix40 build for epel8 failed: https://koji.fedoraproject.org/koji/taskinfo?taskID=37041678 DEBUG util.py:585: BUILDSTDERR: Error: DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests DEBUG util.py:585: BUILDSTDERR: - nothing provides libssh2(x86-64) = 1.8.0-7.module+el8+2833+c7d6d092 needed by libssh2-devel-1.8.0-7.module+el8+2833+c7d6d092.x86_64 On my RHEL8 VM: # dnf repoquery --whatprovides 'libssh2(x86-64) = 1.8.0-7.module+el8+2833+c7d6d092' libssh2-0:1.8.0-7.module+el8+2833+c7d6d092.x86_64 There appear to be 3 different libssh2 builds: libssh2.x86_64 1.8.0-7.module+el8.0.0.z+3418+a72cf898.1 rhel-8-for-x86_64-appstream-rpms libssh2.x86_64 1.8.0-7.module+el8.0.0+3075+09be6b65.1 rhel-8-for-x86_64-appstream-rpms libssh2.x86_64 1.8.0-7.module+el8+2833+c7d6d092 rhel-8-for-x86_64-appstream-rpms Is it possible that an odd combination of them are ending up in the EPEL8 buildroot? The other odd thing is that I cannot install libssh2-devel on my RHEL8 vm because it does not appear to exist: # dnf install libssh2-devel Updating Subscription Management repositories. Last metadata expiration check: 0:07:30 ago on Wed 14 Aug 2019 03:50:13 PM EDT. No match for argument: libssh2-devel I've got Code Ready Builder enabled. Anything else needed? repo id repo name status codeready-builder-for-rhel-8-x86_64-rpms Red Hat CodeReady Linux Builder for RHEL 8 x86_64 ( 1,497 epel Extra Packages for Enterprise Linux 8 - x86_64310 epel-testing Extra Packages for Enterprise Linux 8 - Testing - x 202 rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream ( 5,739 rhel-8-for-x86_64-baseos-rpmsRed Hat Enterprise Linux 8 for x86_64 - BaseOS (RPM 2,097 rhel-8-for-x86_64-supplementary-rpms Red Hat Enterprise Linux 8 for x86_64 - Supplementa 20 -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: EPEL-ANNOUNCE EPEL-8 package requests are now open
On 8/8/19 8:38 AM, Robert Scheck wrote: > Hello Stephen, > > On Thu, 01 Aug 2019, Stephen John Smoogen wrote: >> I would like to thank everyone for their patience and for the people who >> have put in a lot of work to get us to where we can start building >> packages. > > even it's late, I still want to thank you for your hard work on EPEL 8 and > for handling my perpetual nagging (is it the correct phrase?) very kindly! > > For me, RHEL without EPEL is kind of incomplete in about all enviroments I > have or need to support - thus all efforts on EPEL are highly appreciated. > > > Regards, > Robert A hearty second! EPEL is key to our use of EL. Thanks Stephen, Kevin, and everyone else. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Zabbix 4.0
I've got a package of Zabbix 4.0.5 going to epel-testing: https://bodhi.fedoraproject.org/updates/zabbix40-4.0.5-1.el7 feedback appreciated. -- Orion Poplawski Manager of NWRA Technical Systems 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
[EPEL-devel] Re: Bodhi 4 in EPEL 7
On 6/13/19 4:03 PM, Randy Barlow wrote: > Greetings! > > Fedora Infrastructure recently deployed Bodhi 4.0.0 to production, > which included quite a few backwards incompatible changes[0]. Some of > the changes have resulted in older Bodhi clients (less than 4.0.0) not > being compatible with the new version of the server. > > In Fedora, FESCo decided to allow the Bodhi 4.0.0 update to go to > Fedora 29 and 30, and for us to add a bodhi3 compat client package in > case there were any users counting on using the bodhi3 client with a > non-Fedora Bodhi server[1] (believe it or not, there are other Bodhi > deployments out there!) > > EPEL 7 currently has a fairly old Bodhi version (2.11.0). This version > is also not compatible with the Bodhi 4 server. > > What do you think about upgrading Bodhi in EPEL 7 as well? > > There are a few things I'd like to highlight for consideration here: > > * Bodhi 4 is Python 3 only. Bodhi 2 is Python 2 only. So, upgrading to > Bodhi 4 isn't just a switch to a newer Bodhi, it will also mean a > switch in Python versions. This will affect dependencies (there are a > few). I think that's fine. Lot's of things have been moving to python3 in EPEL7. > * I think we might be missing Python 3 dependencies for Bodhi 4. Could be. Hopefully not to hard to remedy that. > * It might be good to consider dropping the Bodhi server as we do this. > EPEL 7 has versions of some of Bodhi's server dependencies that are > too old for Bodhi 4. I *think* the client should be OK with the > client dependency versions, but of course you never know until you > try. Fine by me. > * Would we want to maintain a bodhi2 compat package for EPEL 7, > analagous to the bodhi3 compat package we made for Fedora? I guess the question is are there any bodhi2 servers running on EL7 out there? Probably won't know until someone screams. I wouldn't add it unless someone complains. > * What about EPEL 6? It's still on Bodhi 0.9, and I have never seen or > worked on that codebase. Unfortunately, it has Python 2.6 and not any > verison of Python 3, to my knowledge. EPEL 6 does have python 3.4, I would just let that rot as is. -- Orion Poplawski Manager of NWRA Technical Systems 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: KDE rebuild for RHEL8
On 5/8/19 4:09 PM, Troy Dawson wrote: > On Fri, Jan 18, 2019 at 9:03 AM Troy Dawson wrote: >> >> I have uploaded my build to my fedora people area. Unfortunately the >> source rpm's wouldn't fit. I'll work on getting just the packages >> that I changed into the source rpm area. Hopefully that trims it down >> for those that want to see what got changed. >> I also uploaded a repo file [1], the build order [2] , what didn't >> build [3] , and a README [4] that includes how to install the desktop. >> >> == How to install KDE on rhel8-beta >> -- # First make sure you can get regular rhel8-beta packages >> -- # All of these should be done as root or sudo >> -- wget -O /etc/yum.repos.d/rhel8-beta-kde.repo >> https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.repo >> -- dnf group install "KDE Plasma Workspaces" >> -- (Optional) dnf group install kde-desktop >> -- (Optional) dnf group install kde-apps >> -- (Optional) dnf group install kde-media >> -- (Optional) dnf group install kde-education >> -- (Optional) dnf group install kde-software-development >> -- (Optional) dnf group install kf5-software-development >> -- # Currently gdm does not like to start plasma, use sddm instead >> -- dnf install switchdesk system-switch-displaymanager >> -- switchdesk kde >> -- system-switch-displaymanager sddm >> -- # Incase you aren't in graphical mode yet >> -- systemctl set-default graphical.target >> >> Troy >> >> [1] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.repo >> [2] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.build-order >> [3] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.not-built >> [4] - https://tdawson.fedorapeople.org/epel8/kde/readme.txt >> > > Just a heads up, incase people are wondering. > My KDE build that I built on RHEL8 beta works [1] on RHEL8 final release. > I have taken a RHEL8-Beta, already running KDE, and updated it to > RHEL8, and everything updated, and worked [1] > I have also taken a fresh installed, and updated, RHEL8 minimal, and > run the above commands to install KDE, and it worked also. > > That doesn't mean this repo will be up forever, but it should last > until we get KDE in EPEL8, whenever that happens. > > Troy > Thanks for your work on this. My observation is - do want KDE to be a module for EPEL8? I'm actually slightly surprised to find that Gnome does not appear to be modular in RHEL8, but if we face something at all like the KDE 4->plasma transition during RHEL8's lifetime it seems like a good thing to have. Also, I've found them quite useful for building ordered sets of dependencies and dealing with updates. -- Orion Poplawski Manager of NWRA Technical Systems 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: postgis-2.0.7-2.el7 still in epel7-testing
On 4/21/19 5:32 PM, Sérgio Basto wrote: On Fri, 2019-04-12 at 09:36 +0200, Danny Smit wrote: Hi all, I'm looking for a fix in postgis, which seems to be fixed already in postgis-2.0.7-2.el7. However that package seems to be 'stuck' in the epel7-testing repository for a long time: https://koji.fedoraproject.org/koji/buildinfo?buildID=750618 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b6c229157e Can the package be pushed to stable? I gave +1 karma and more one and package will be pushed to updates automatically . Can someone give one more positive karma ? please Thanks I pushed it to batched. -- Orion Poplawski Manager of NWRA Technical Systems 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: yum update problem
On 4/5/19 7:06 AM, m...@tdiehl.org wrote: Hi, I am seeing the following error when trying to run yum update: (tigger pts11) # yum update Loaded plugins: changelog, fastestmirror, langpacks, priorities Loading mirror speeds from cached hostfile ... Transaction check error: file /usr/lib/python3.4/site-packages/virtualenv-15.1.0-py3.4.egg-info from install of python34-virtualenv-15.1.0-3.el7.noarch conflicts with file from package python34-virtualenv-15.1.0-2.el7.noarch Error Summary - (tigger pts11) # I am seeing this anywhere I have python34-virtualenv from epel installed. Anyone know how to resolve this short of uninstalling python34-virtualenv? Should be fixed with: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-813cc12887 -- Orion Poplawski Manager of NWRA Technical Systems 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL: Python34 moving to Python36
On 3/13/19 9:05 PM, Chris wrote: Amazing work! I just wanted to ask if it was a bug that the Python v2 branch provided the following RPMs, but the Python v3.6 did not: - python36-requests-oauthlib - python36-oauthlib The above python2 packages are in RHEL7, so new python3- packages will need to be created in Fedora for EPEL7. - python36-markdown - python36-pytest-runner These are now in epel-testing. Buildroot overrides would need to be created for them for them to be in the buildroot. Perhaps these ones just haven't been ported over yet? Thoughts? Here's the source of my prob: https://koji.fedoraproject.org/koji/taskinfo?taskID=33463886 Chris -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL: Python34 moving to Python36
On 3/13/19 11:48 AM, Miro Hrončok wrote: On 13. 03. 19 18:42, Wart wrote: Transaction check error: file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from install of python34-six-1.11.0-2.el7.noarch conflicts with file from package python34-six-1.11.0-1.el7.noarch IS that a file to directory problem? Otherwise python34-six-1.11.0-2.el7.noarch should just replace python34-six-1.11.0-1.el7.noarch "naturally" without any specific conflict. I think I figured this out. During the install step if we didn't have a tests_require package installed we got: running install_egg_info Writing /builddir/build/BUILDROOT/python3-six-1.11.0-2.el7.noarch/usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info BUILDSTDERR: /usr/lib64/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'tests_require' BUILDSTDERR: warnings.warn(msg) and ended up with a file egg-info instead of a directory. I've rebuilt python3-six with the test requirements installed for both versions now. I'll add python3-six-1.11.0-3.el7.src.rpm to the update. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL: Python34 moving to Python36
On 3/13/19 9:46 AM, Dridi Boukelmoune wrote:
Hello,
On Wed, Mar 13, 2019 at 3:37 PM Stephen John Smoogen wrote:
Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
and several helpers have gotten nearly all of the python34 packages
moves over to python36 in EPEL-7. They are being included in 6 Bodhi
pushes because of a limitation in Bodhi for the text size of packages
in an include.
I was about to start a thread about this, so it saves me a fair amount of time.
I have been working on this today, so this is very fresh:
https://github.com/varnishcache/pkg-varnish-cache/pull/124
My complaint is that the current packages for
python34-{sphinx,docutils} don't seem to have provides with a
"python3-" prefix. So while I can live with that fact, I'm not happy
with the prospect of having to break the continuity soon and have to
move my BuildRequires to a python36- prefix.
That's a reasonable suggestion. I would suggest you file an RFE request
again python-rpm-macros in EPEL to have the %python_provide macro
produce a Provides: python3-%{name} for the "active" python3 version.
One more thing about those two specific packages, they also don't
provide binaries suffixed with "-3" so that means having to change
packaging again so that configures picks up rst2man-3.6 instead of
rst2man-3.4 and that's not a comfortable place to be in downstream.
The python3{4,6}-sphinx packages do provide /usr/bin/sphinx-build-3,
etc. In fact one reason why you currently cannot install both.
As for docutils, file a bug against python3-docutils in EPEL and we'll
get that fixed up.
The current day for these package groups to move into EPEL regular is
April 2nd. We would like to have all tests we find in the next week or
so also added so that the updates can occur in a large group without
too much breakage.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9e9f81e581
I'm a bit confused because it seems the update above contains both
builds for the packages I'm interested in, and seems to keep building
the 3.4 variant of the package in addition to the new 3.6 builds.
That means I should not worry about having to move away from today's
work, right?
Most EPEL python3 package will build for both python3 versions. We are
not (yet) dropping python34. It's just that the default
/usr/bin/python3 is switching to python 3.6, and packages that only
build for one python3 version are now shipping for 3.6.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL: Python34 moving to Python36
On 3/13/19 11:48 AM, Miro Hrončok wrote: On 13. 03. 19 18:42, Wart wrote: Transaction check error: file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from install of python34-six-1.11.0-2.el7.noarch conflicts with file from package python34-six-1.11.0-1.el7.noarch IS that a file to directory problem? Otherwise python34-six-1.11.0-2.el7.noarch should just replace python34-six-1.11.0-1.el7.noarch "naturally" without any specific conflict. It appears to be a directory -> file problem. Why did this change? # ls -l /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info total 16 -rw-r--r--. 1 root root1 Sep 28 12:18 dependency_links.txt -rw-r--r--. 1 root root 1818 Sep 28 12:18 PKG-INFO -rw-r--r--. 1 root root 253 Sep 28 12:18 SOURCES.txt -rw-r--r--. 1 root root4 Sep 28 12:18 top_level.txt # repoquery --enablerepo=epel-testing -l python34-six-1.11.0-2.el7.noarch | grep egg /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Koji Build Failure Due To Dependency EPEL Dependency Issue
COPR builds against CentOS, EPEL builds against RHEL, which can lead to differences. Bringing in the EPEL list to see what others have to say. But my RHEL7 seven machine can see it: python2-oauthlib.noarch 2.0.1-8.el7 rhel-7-server-rpms On 2/23/19 2:36 PM, Chris wrote: > Perhaps a link to the koji build might be helpful? Certainly, Here is a working Copr link: https://copr.fedorainfracloud.org/coprs/build/861900/ Same .src.rpm, here is a failing Koji one: https://koji.fedoraproject.org/koji/taskinfo?taskID=32993375 Here is the COPR post output: copr-cli build apprise python-apprise-0.7.3-1.el7.nuxref.src.rpm Uploading package python-apprise-0.7.3-1.el7.nuxref.src.rpm 100% || 589kB 1.4MB/s eta 0:00:00 Build was added to apprise: https://copr.fedorainfracloud.org/coprs/build/861900/ Created builds: 861900 Watching build(s): (this may be safely interrupted) 15:58:20 Build 861900: pending 15:58:51 Build 861900: running 16:02:25 Build 861900: succeeded Where as here is the Koji one: koji build --scratch epel7 python-apprise-0.7.3-1.el7.nuxref.src.rpm Uploading srpm: python-apprise-0.7.3-1.el7.nuxref.src.rpm [] 100% 00:00:00 566.16 KiB 756.73 KiB/sec Created task: 32993375 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=32993375 Watching tasks (this may be safely interrupted)... 32993375 build (epel7, python-apprise-0.7.3-1.el7.nuxref.src.rpm): free 32993375 build (epel7, python-apprise-0.7.3-1.el7.nuxref.src.rpm): free -> open (buildvm-ppc64-06.ppc.fedoraproject.org <http://buildvm-ppc64-06.ppc.fedoraproject.org>) 32993376 buildArch (python-apprise-0.7.3-1.el7.nuxref.src.rpm, noarch): open (buildvm-28.phx2.fedoraproject.org <http://buildvm-28.phx2.fedoraproject.org>) 32993376 buildArch (python-apprise-0.7.3-1.el7.nuxref.src.rpm, noarch): open (buildvm-28.phx2.fedoraproject.org <http://buildvm-28.phx2.fedoraproject.org>) -> FAILED: BuildError: error building package (arch noarch), mock exited with status 30; see root.log for more information 0 free 1 open 0 done 1 failed 32993375 build (epel7, python-apprise-0.7.3-1.el7.nuxref.src.rpm): open (buildvm-ppc64-06.ppc.fedoraproject.org <http://buildvm-ppc64-06.ppc.fedoraproject.org>) -> FAILED: BuildError: error building package (arch noarch), mock exited with status 30; see root.log for more information 0 free 0 open 0 done 2 failed 32993375 build (epel7, python-apprise-0.7.3-1.el7.nuxref.src.rpm) failed Chris On Sat, Feb 23, 2019 at 4:29 PM Orion Poplawski <mailto:or...@nwra.com>> wrote: On 2/23/19 1:02 PM, Chris wrote: > The error: > > DEBUG util.py:490: BUILDSTDERR: Error: > DEBUG util.py:490: BUILDSTDERR: Problem: conflicting requests > DEBUG util.py:490: BUILDSTDERR: - nothing provides python2-oauthlib needed by python2-requests-oauthlib-0.8.0-5.el7.noarch > DEBUG util.py:634: Child return code was: 1 > > This same package builds fine using copr (done so here): > https://copr.fedorainfracloud.org/coprs/lead2gold/apprise/ > > The spec file entry (that works fine for epel7 on Copr) is: > BuildRequires: python2-requests-oauthlib > BuildRequires: python2-oauthlib > > This entry just produces an error that all requirements couldn't be met > and the scratch build aborts then too. > BuildRequires: python-oauthlib > > It appears to be an upstream issue... a missing entry in the > python-oauthlib such as: > Provides: python2-oauthlib > > I originally thought maybe i should be filing an issue with the oauthlib > group, but then if that were the case, it wouldn't have worked perfectly > fine on Copr. > > Thoughts? Advice? > > Chris Perhaps a link to the koji build might be helpful? -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com <mailto:or...@nwra.com> Boulder, CO 80301 https://www.nwra.com/ -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Zabbix 3.0 available for EPEL7
Zabbix 3.0 is now available for EPEL7 via the zabbix30-* packages. Enjoy. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
