epel-devel November 2021

epel-devel@lists.fedoraproject.org

25 participants
89 discussions

%generate_buildrequires
by Andrew C Aitchison 23 May '22

23 May '22

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: >> <mock-chroot> 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 Is %generate_buildrequires suppose to work for packages which do not used python ? From the name I would expect it to, but reading that doc makes me think %generate_buildrequires *is* python specific. If so, the name is misleading. (I am also confused/suspicious of the point of a macro to automate build requires, except as a step on a path to somewhere else. If build requirements need to be stated explicitly, then automating their statement is a good way of hiding an issue that needs to be reviewed whenever changes are made. ) -- Andrew C. Aitchison Kendal, UK andrew(a)aitchison.me.uk

3 3

How to support python 3.8 from RHEL 8.2 in EPEL?
by Orion Poplawski 04 Mar '22

04 Mar '22

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 orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

5 10

EPEL9 Rollout Proposals
by Troy Dawson 03 Dec '21

03 Dec '21

In our last EPEL Steering Committee meeting, Carl brought up a new proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best way to explain things like that, it got a little confusing. Carl and I had a good video chat to clean up confusion and talk about some pros and cons of the various proposals. Here are the three proposals. * PLAN A Plan A is basically what we've been working towards for the past couple of months. - launch epel9-next now-ish (ideally aligned with c9s launch promotion) - After RHEL9 goes GA -- perform a mass branch and mass rebuild to populate epel9 -- launch epel9 after RHEL9 GA is launched. ** Plan A Pros: - epel9-next and epel9 are only set up once, and not changed - ready to go now ** Plan A Cons: - complexity and added work of mass branch and mass rebuild - mass rebuild will have a moderate rate of failure due to buildroot differences (unshipped devel packages) - epel9 not available at rhel9 ga - confusing messaging to packagers: -- target epel9-next for ~6 months -- after epel9 exists target that instead, only use epel9-next when needed - confusing messaging to users: -- use epel9-next now for c9s and rhel9 beta -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled -- use epel9 primarily once it exists * PLAN B - epel9-next stays the way it is currently setup. - Setup epel9 using RHEL9 Beta for the buildroot. -- Pull in any errata as it comes. -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB - Launch epel9 and epel9-next together (In 1-2 weeks). - When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA ** Plan B Pros: - simple messaging to packagers: -- epel9 is the primary target, use epel9-next only when needed (same as epel8-next) - simple messaging to users: -- use epel9 everywhere (epel-next-release is a recommends on c9s) - no mass branching - no mass rebuild - No confusion from using the full CentOS Stream buildroot -- epel9 buildroot will only have AppStream, BaseOS and CRB ** Plan B Cons: - potential for large divergence between rhel9 beta and ga - changing our messaging right before the launch * PLAN C - epel9-next stays the way it is currently setup. - setup up epel9 using c9s for the buildroot -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB - freeze epel9 buildroot before c9s switches to 9.1 content - launch epel9 and epel9-next together (1-2 weeks) - switch epel9 buildroot from frozen c9s to rhel9 ga later ** Plan C Pros: - simple messaging to packagers: -- epel9 is the primary target, use epel9-next only when needed (same as epel8-next) - simple messaging to users: -- use epel9 everywhere (epel-next-release is a recommends on c9s) - no mass branching - no mass rebuild - No confusion from using the full CentOS Stream buildroot -- epel9 buildroot will only have AppStream, BaseOS and CRB ** Plan C Cons: - potential infrastructure complexity of freezing the epel9 buildroot - changing our messaging right before the launch Please let us know what you think. If we do choose to go with Plan B or C we will need to make the decision fairly quickly. Troy

8 16

Re: Neovim 0.5 for EPEL8 (FAO Andreas Schneider... I think)
by David Else 30 Nov '21

30 Nov '21

Hello, RHEL 8.5 and Neovim 0.6 were released! https://github.com/neovim/neovim/releases/tag/v0.6.0 Please could you build and release Neovim 0.6? Thanks! Sent with ProtonMail Secure Email.

1 0

[Fedocal] Reminder meeting : EPEL Steering Committee
by tdawson＠redhat.com 30 Nov '21

30 Nov '21

Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-12-01 from 16:00:00 to 17:00:00 US/Eastern At fedora-meeting(a)irc.libera.chat The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic EPEL-9 #topic Openfloor #endmeeting Source: https://calendar.fedoraproject.org//meeting/9854/

1 0

Fedora EPEL 8 updates-testing report
by updates＠fedoraproject.org 29 Nov '21

29 Nov '21

The following Fedora EPEL 8 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b660985bb3 gsi-openssh-8.0p1-9.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing awscli-1.18.156-3.el8 fira-code-fonts-6-1.el8 libretls-3.4.2-1.el8 python-rsa-4.8-1.el8 rpkg-1.63-4.el8 seamonkey-2.53.10-2.el8 singularity-3.8.5-1.el8 snapd-2.53.2-2.el8 Details about builds: ================================================================================ awscli-1.18.156-3.el8 (FEDORA-EPEL-2021-91d16610fd) Universal Command Line Environment for AWS -------------------------------------------------------------------------------- Update Information: Fix RSA pin. -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Gwyn Ciesla <gwync(a)protonmail.com> - 1.18.156-3 - Fix rsa pin. -------------------------------------------------------------------------------- References: [ 1 ] Bug #2027421 - awscli will not install with python-rsa 4.8 https://bugzilla.redhat.com/show_bug.cgi?id=2027421 -------------------------------------------------------------------------------- ================================================================================ fira-code-fonts-6-1.el8 (FEDORA-EPEL-2021-d1982966a2) Monospaced font with programming ligatures -------------------------------------------------------------------------------- Update Information: Update to 6 -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Michael Kuhn <suraia(a)fedoraproject.org> - 6-1 - Update to 6 * Wed Jul 21 2021 Fedora Release Engineering <releng(a)fedoraproject.org> - 5.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild -------------------------------------------------------------------------------- References: [ 1 ] Bug #2027533 - fira-code-fonts-6 is available https://bugzilla.redhat.com/show_bug.cgi?id=2027533 -------------------------------------------------------------------------------- ================================================================================ libretls-3.4.2-1.el8 (FEDORA-EPEL-2021-e0a3ad1d52) Port of libtls from LibreSSL to OpenSSL -------------------------------------------------------------------------------- Update Information: - Upgrade to 3.4.2 (#2027520) -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Robert Scheck <robert(a)fedoraproject.org> 3.4.2-1 - Upgrade to 3.4.2 (#2027520) -------------------------------------------------------------------------------- References: [ 1 ] Bug #2027520 - libretls-3.4.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=2027520 -------------------------------------------------------------------------------- ================================================================================ python-rsa-4.8-1.el8 (FEDORA-EPEL-2021-e102354e11) Pure-Python RSA implementation -------------------------------------------------------------------------------- Update Information: Update to 4.8 -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Jason Montleon <jmontleo(a)redhat.com> - 4.8-1 - Update to 4.8 -------------------------------------------------------------------------------- References: [ 1 ] Bug #2026523 - python-rsa-4.8 is available https://bugzilla.redhat.com/show_bug.cgi?id=2026523 -------------------------------------------------------------------------------- ================================================================================ rpkg-1.63-4.el8 (FEDORA-EPEL-2021-c36753e53a) Python library for interacting with rpm+git -------------------------------------------------------------------------------- Update Information: Patch: Fixes import fail with sources already imported -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Ond��ej Nosek <onosek(a)redhat.com> - 1.63-4 - Patch: Fixes import fail with sources already imported * Mon Sep 13 2021 Ond��ej Nosek <onosek(a)redhat.com> - 1.63-3 - Add python-requests-kerberos as a new dependency for RHEL packages - Patch: Print SpecFile parsing debug info -------------------------------------------------------------------------------- ================================================================================ seamonkey-2.53.10-2.el8 (FEDORA-EPEL-2021-b9fd954bc5) Web browser, e-mail, news, IRC client, HTML editor -------------------------------------------------------------------------------- Update Information: Update to 2.53.10 . Backport support for custom date format, see https://support.mozilla.org/en-US/kb/customize-date-time-formats-thunderbird for more info. ---- Update to 2.53.10 . Backport support for custom date format, see https://support.mozilla.org/en-US/kb/customize-date-time-formats-thunderbird for more info. -------------------------------------------------------------------------------- ChangeLog: * Tue Nov 30 2021 Dmitry Butskoy <Dmitry(a)Butskoy.name> 2.53.10-2 - add allsettled patch * Tue Nov 23 2021 Dmitry Butskoy <Dmitry(a)Butskoy.name> 2.53.10-1 - update to 2.53.10 - backport support for custom date format (mozbz#1426907) - fix compile with rust >= 1.56 -------------------------------------------------------------------------------- ================================================================================ singularity-3.8.5-1.el8 (FEDORA-EPEL-2021-4d1a9eb326) Application and environment virtualization -------------------------------------------------------------------------------- Update Information: Upgrade to upstream 3.8.5 -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Dave Dykstra <dwd(a)fedoraproject.org> - 3.8.5-1 - Upgrade to upstream 3.8.5 -------------------------------------------------------------------------------- References: [ 1 ] Bug #2027538 - singularity-3.8.5 is available https://bugzilla.redhat.com/show_bug.cgi?id=2027538 -------------------------------------------------------------------------------- ================================================================================ snapd-2.53.2-2.el8 (FEDORA-EPEL-2021-9f018db377) A transactional software package manager -------------------------------------------------------------------------------- Update Information: Cherry pick upstream fixes for RHBZ#2025264 -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Maciek Borzecki <maciek.borzecki(a)gmail.com> - 2.53.2-2 - Cherry-pick a fix for snap-device-helper (RHBZ#2025264) --------------------------------------------------------------------------------

1 0

Fedora EPEL 7 updates-testing report
by updates＠fedoraproject.org 29 Nov '21

29 Nov '21

The following Fedora EPEL 7 Security updates need testing: Age URL 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-144ba84404 gsi-openssh-7.4p1-7.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing libretls-3.4.2-1.el7 php-phpseclib-2.0.35-1.el7 rpkg-1.63-4.el7 seamonkey-2.53.10-2.el7 singularity-3.8.5-1.el7 snapd-2.53.2-2.el7 Details about builds: ================================================================================ libretls-3.4.2-1.el7 (FEDORA-EPEL-2021-d5e9584bda) Port of libtls from LibreSSL to OpenSSL -------------------------------------------------------------------------------- Update Information: - Upgrade to 3.4.2 (#2027520) -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Robert Scheck <robert(a)fedoraproject.org> 3.4.2-1 - Upgrade to 3.4.2 (#2027520) -------------------------------------------------------------------------------- References: [ 1 ] Bug #2027520 - libretls-3.4.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=2027520 -------------------------------------------------------------------------------- ================================================================================ php-phpseclib-2.0.35-1.el7 (FEDORA-EPEL-2021-6e8c03ab7b) PHP Secure Communications Library -------------------------------------------------------------------------------- Update Information: **Version 2.0.35** - 2021-11-28 - SSH2: add "smart multi factor" login mode (enabled by default) (#1648) - SSH2: error out when no data is received from the server (#1647) - SFTP: don't attempt to parse unsupported attributes (#1708) - SFTP: getSupportedVersions() call didn't work -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Remi Collet <remi(a)remirepo.net> - 2.0.35-1 - update to 2.0.35 -------------------------------------------------------------------------------- ================================================================================ rpkg-1.63-4.el7 (FEDORA-EPEL-2021-893340aa4f) Python library for interacting with rpm+git -------------------------------------------------------------------------------- Update Information: Patch: Fixes import fail with sources already imported -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Ond��ej Nosek <onosek(a)redhat.com> - 1.63-4 - Patch: Fixes import fail with sources already imported * Mon Sep 13 2021 Ond��ej Nosek <onosek(a)redhat.com> - 1.63-3 - Add python-requests-kerberos as a new dependency for RHEL packages - Patch: Print SpecFile parsing debug info -------------------------------------------------------------------------------- ================================================================================ seamonkey-2.53.10-2.el7 (FEDORA-EPEL-2021-2413c1a726) Web browser, e-mail, news, IRC client, HTML editor -------------------------------------------------------------------------------- Update Information: Update to 2.53.10 . Backport support for custom date format, see https://support.mozilla.org/en-US/kb/customize-date-time-formats-thunderbird for more info. ---- Update to 2.53.10 . Backport support for custom date format, see https://support.mozilla.org/en-US/kb/customize-date-time-formats-thunderbird for more info. -------------------------------------------------------------------------------- ChangeLog: * Tue Nov 30 2021 Dmitry Butskoy <Dmitry(a)Butskoy.name> 2.53.10-2 - add allsettled patch * Tue Nov 23 2021 Dmitry Butskoy <Dmitry(a)Butskoy.name> 2.53.10-1 - update to 2.53.10 - backport support for custom date format (mozbz#1426907) - fix compile with rust >= 1.56 -------------------------------------------------------------------------------- ================================================================================ singularity-3.8.5-1.el7 (FEDORA-EPEL-2021-1c3b678bfa) Application and environment virtualization -------------------------------------------------------------------------------- Update Information: Upgrade to upstream 3.8.5 -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Dave Dykstra <dwd(a)fedoraproject.org> - 3.8.5-1 - Upgrade to upstream 3.8.5 -------------------------------------------------------------------------------- References: [ 1 ] Bug #2027538 - singularity-3.8.5 is available https://bugzilla.redhat.com/show_bug.cgi?id=2027538 -------------------------------------------------------------------------------- ================================================================================ snapd-2.53.2-2.el7 (FEDORA-EPEL-2021-8fbb19af6b) A transactional software package manager -------------------------------------------------------------------------------- Update Information: Cherry pick upstream fixes for RHBZ#2025264 -------------------------------------------------------------------------------- ChangeLog: * Mon Nov 29 2021 Maciek Borzecki <maciek.borzecki(a)gmail.com> - 2.53.2-2 - Cherry-pick a fix for snap-device-helper (RHBZ#2025264) --------------------------------------------------------------------------------

1 0

Fedora Review Package for epel8
by Robby Callicotte 29 Nov '21

29 Nov '21

Hello, This issue [1] is open for an epel8 build of fedora-review. I would like to help out and co-maintain if possible. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1868827 -- Robby Callicotte He/Him/His Timezone: America/Chicago IRC: c4t3l | Twitter: @robbycl2v

1 0

Re: Mock/Copr default epel-8-* configuration to be changed
by Stephen John Smoogen 29 Nov '21

29 Nov '21

On Sun, 28 Nov 2021 at 19:32, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote: > > On Sun, Nov 28, 2021 at 7:06 PM Neal Gompa <ngompa13(a)gmail.com> wrote: > > > > On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote: > > > > > > On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa <ngompa13(a)gmail.com> wrote: > > > > > > > > On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote: > > > > > > > > > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý <msuchy(a)redhat.com> wrote: > > > > > > > > > > > > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a): > > > > > > > Hello Fedora EPEL maintainers! > > > > > > > > > > > > > > First I don't feel comfortable announcing this, I'm not happy about the > > > > > > > situation and so I don't want to be the lightning rod :-). But I believe > > > > > > > that we can come to acceptable Copr/Mock solution and this needs to be > > > > > > > discussed... so here we are. > > > > > > > > > > > > > > By the end of the year 2021 we have to fix our default EPEL 8 Mock > > > > > > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8 > > > > > > > goes EOL by then. > > > > > > > > > > > > > > > > > > I wrote down the possible options and their pros and cons and I done my best to catch all the feedback here. > > > > > > > > > > > > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4… > > > > > > > > > > > > Miroslav > > > > > > > > > > That seems to be a succinct listing. I think you left out my > > > > > suggestion.of "support people re-inventing point releases for CentOS", > > > > > which is what major CentOS users will do using internal mirrors. due > > > > > to concern about unexpected and unwelcome updates of CentOS Stream, > > > > > while they assess whether AlmaLinux or Rocky are reliable and stable > > > > > enough to use. It's not an uncommon behavior for EPEL itself, partly > > > > > because of EPEL's bad habit of deleting RPMs without warning and > > > > > stripping out all previous releases. That's caused me problems with > > > > > chromium and firefox when updates were incompatible with contemporary > > > > > regression testing systems. > > > > > > > > > > > > > It's not a "bad habit", it happens because when packages are retired, > > > > keeping the packages there does a disservice to the community by > > > > effectively forcing a maintenance burden when there's no maintainer. > > > > As for stripping out previous releases, that's just how Pungi and > > > > Bodhi do update composes at the moment. Someday that'll be fixed, but > > > > then we'd have to come up with a policy on how many because there are > > > > storage concerns for mirrors if we kept everything published forever. > > > > > > It causes problems and confusion for people who need to lock down > > > evisting versions for deployment. And it happens for packages that are > > > not retired, but merely updated. I was bitten by it myself with > > > chromium updates last year. It forces users of EPEL to maintain > > > internal repos, or out of band access to previously accessible RPMs. > > > It's destabilizing and breaks the use of bills-of-material based > > > deployments with complete lists of all desired RPMs. > > > > > > Storage and bandwidth concerns are legitimate concerns, as is > > > potentially continuing to publish older releases with known > > > vulnerabilities or bugs. But neither Fedora nor RHEL simply discard > > > previously published versions this way, they aggregate new releases. I > > > consider this a longstanding bug for EPEL, and one of the reasons I > > > set up internal mirrors in large deployments. > > > > > > > This is not true. Fedora and EPEL share the same system, and have the > > same issues. The only difference is that the release repo is frozen in > > Fedora, so only the updates repo is affected this way. So there's at > > most two versions of a package at any time. > > You're correct. With the current setup, it's also relatively simple to > revert to the "frozen" release, which handles most of the regression > situations. And Fedora releases are nowhere near so long-lived as RHEL > and EPEL, so it tends to be less of a long-lived problem. > > > RHEL *does* maintain multiple old versions, but their system is > > completely different and supports that capability. > > What would it take to get Fedora, or at least EPEL, to preserve old > releases in the default published repos? I appreciate that it would > require thought and expand them noticeably, especially for bulky and > frequently updating components like chromium. I admit to not having > numbers on how much churn happens there: does anyone have numbers? In order to keep older package releases, it would require changes to the compose tool pungi. It would also have to make it so it worked for EPEL versus Fedora. [Fedora Linux releases have grown to the point that many mirrors can barely carry the OS as is.. adding in older packages is out of the question for them.] I do not have numbers on how often packages churn or which ones churn the most. -- Stephen J Smoogen. Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren

4 4

EPEL 9 Next Bodhi updates: Set lower days to stable limit?
by Miro Hrončok 29 Nov '21

29 Nov '21

Hello EPEL people, what do you think about setting the Bodhi days to stable limit to 3 days for EPEL 9 Next (at least until RHEL 9 GA)? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

7 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

epel-devel November 2021