%generate_buildrequires
by Andrew C Aitchison
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
1 year
How to support python 3.8 from RHEL 8.2 in EPEL?
by Orion Poplawski
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/
1 year, 3 months
EPEL9 Rollout Proposals
by Troy Dawson
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
1 year, 6 months
[Fedocal] Reminder meeting : EPEL Steering Committee
by tdawson＠redhat.com
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 year, 6 months
Fedora EPEL 8 updates-testing report
by updates＠fedoraproject.org
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 year, 6 months
Fedora EPEL 7 updates-testing report
by updates＠fedoraproject.org
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 year, 6 months
Re: Mock/Copr default epel-8-* configuration to be changed
by Stephen John Smoogen
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-kCFdE6VBWPW8o8zjXd2Z0SG...
> > > > > >
> > > > > > 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
1 year, 6 months
