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
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/
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 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 <package>-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 <package>-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
[1] -
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/…
- Third bullet point
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.
Thanks,
Mukundan.
[0] https://copr.fedorainfracloud.org/coprs/nonamedotc/xfce416-epel8/
--
GPG Key: E5C8BC67
The following Fedora EPEL 7 Security updates need testing:
Age URL
62 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef openjpeg2-2.3.1-11.el7
5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-edab6b43f2 seamonkey-2.53.8.1-1.el7
The following builds have been pushed to Fedora EPEL 7 updates-testing
ansible-2.9.24-2.el7
rpki-client-7.2-1.el7
Details about builds:
================================================================================
ansible-2.9.24-2.el7 (FEDORA-EPEL-2021-85cfa9cb1c)
SSH-based configuration management, deployment, and task execution system
--------------------------------------------------------------------------------
Update Information:
Actually apply rocky linux patch. ---- Update to 2.9.24 upstream bugfix
release.
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jul 28 2021 Kevin Fenzi <kevin(a)scrye.com> - 2.9.24-2
- Actually apply rocky linux patch.
* Sun Jul 25 2021 Kevin Fenzi <kevin(a)scrye.com> - 2.9.24-1
- Update to 2.9.24. Fixes rhbz#1983837
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1968728 - BackPort Ansible to Include Support for Rocky Linux ansible_os_family change
https://bugzilla.redhat.com/show_bug.cgi?id=1968728
--------------------------------------------------------------------------------
================================================================================
rpki-client-7.2-1.el7 (FEDORA-EPEL-2021-a27f240123)
RPKI validator to support BGP Origin Validation
--------------------------------------------------------------------------------
Update Information:
rpki-client 7.2 =============== * Use RRDP as default protocol for
syncronizing the RPKI repository data, with rsync used as secondary * At
startup, warn if the filesystem containing the cache directory is probably too
small, 500 MB is the suggested minimum size * Handle running out of disk space
more gracefully, including cleanup of temporary and old files before exiting *
Improve the HTTP/1.1 request headers being sent * Improved validation checks
for ROA and MFT objects
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jul 28 2021 Robert Scheck <robert(a)fedoraproject.org> 7.2-1
- Upgrade to 7.2 (#1987093)
* Fri Jul 23 2021 Fedora Release Engineering <releng(a)fedoraproject.org> - 7.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1987093 - rpki-client-7.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1987093
--------------------------------------------------------------------------------
The following Fedora EPEL 8 Security updates need testing:
Age URL
7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-8676850578 chromium-91.0.4472.164-1.el8
6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1b74f2e3ca tor-0.4.5.9-1.el8
5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-eafd1f0f4d seamonkey-2.53.8.1-1.el8
4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-659234979d mbedtls-2.16.11-1.el8
2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-f87dd166fd pdns-4.5.1-1.el8
The following builds have been pushed to Fedora EPEL 8 updates-testing
python-opentracing-2.4.0-2.el8
rpki-client-7.2-1.el8
Details about builds:
================================================================================
python-opentracing-2.4.0-2.el8 (FEDORA-EPEL-2021-e8351e0d65)
OpenTracing interface for Python
--------------------------------------------------------------------------------
Update Information:
This is the port of python-opentracing to EL8.
--------------------------------------------------------------------------------
ChangeLog:
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1908526 - Review Request: python-opentracing - OpenTracing interface for Python
https://bugzilla.redhat.com/show_bug.cgi?id=1908526
--------------------------------------------------------------------------------
================================================================================
rpki-client-7.2-1.el8 (FEDORA-EPEL-2021-732f41a01d)
RPKI validator to support BGP Origin Validation
--------------------------------------------------------------------------------
Update Information:
rpki-client 7.2 =============== * Use RRDP as default protocol for
syncronizing the RPKI repository data, with rsync used as secondary * At
startup, warn if the filesystem containing the cache directory is probably too
small, 500 MB is the suggested minimum size * Handle running out of disk space
more gracefully, including cleanup of temporary and old files before exiting *
Improve the HTTP/1.1 request headers being sent * Improved validation checks
for ROA and MFT objects
--------------------------------------------------------------------------------
ChangeLog:
* Wed Jul 28 2021 Robert Scheck <robert(a)fedoraproject.org> 7.2-1
- Upgrade to 7.2 (#1987093)
* Fri Jul 23 2021 Fedora Release Engineering <releng(a)fedoraproject.org> - 7.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
--------------------------------------------------------------------------------
References:
[ 1 ] Bug #1987093 - rpki-client-7.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1987093
--------------------------------------------------------------------------------
On Wed, Jul 28, 2021 at 9:18 AM Simon Matter <simon.matter(a)invoca.ch> wrote:
> > First off, thank you very much for that.
> > That is perhaps the best "Here is my environment" anyone has ever sent
> me.
> >
> > The problem is that you don't have the epel-next repo anywhere.
>
> I wasn't aware of epel-next, is it the EPEL for CentOS Stream or what
> exactly?
>
>
Yes.
It is supposed to be layered on top of the regular epel repository because
it doesn't have all the epel packages.
epel-next builds off centos-stream instead of RHEL, like regular epel
does. It only has those packages that need to be rebuilt in stream due to
some library or version update.
In this case, qt5 was updated in stream from 5.12 to 5.15, thus all the kde
desktop needed to be rebuilt (and we updated kde as well). Once RHEL 8.5
is released, I will rebuild all those packages on normal epel8 and we won't
need them in the epel-next repository.
If you are running centos-stream, and do a
dnf install epel-release
you should automatically get epel-next-release.
But it looks like if you are doing a kickstart install, that doesn't work,
so it will have to be listed.
https://fedoraproject.org/wiki/EPEL_Next
Thanks,
> Simon
>
> > At the very least you need to have "epel-next-release" in
> > kickstarts/8/base.ks
> > If you wanted the newer kde packages installed during install you need to
> > add the epel-next repo to kickstarts/8/base-repo.ks
> > I believe it should be
> > repo --name=epel-next --mirrorlist=
> >
> https://mirrors.fedoraproject.org/metalink?repo=epel-next-$releasever&arch=…
> > or possibly just
> > repo --name=epel-next --mirrorlist=
> >
> https://mirrors.fedoraproject.org/metalink?repo=epel-next-$releasever&arch=…
> >
> > Hope this helps.
> > Troy
> >
> > On Wed, Jul 28, 2021 at 3:13 AM Massi aka Ergosum
> > <massi.ergosum(a)gmail.com>
> > wrote:
> >
> >> Il giorno mar 27 lug 2021 alle ore 17:24 Troy Dawson
> >> <tdawson(a)redhat.com> ha scritto:
> >> >
> >> > I've been able to install, and update all of the packages listed here.
> >> > So, unless you are able to give more details about how your machine is
> >> setup, there isn't much I can help with.
> >> >
> >>
> >> A "fresh install" means an image build using the following kickstarts:
> >> [1]
> >> [2].
> >> I'm using repos listed here [3].
> >>
> >> I'm still investigating, but I suspect I'm not using the latest
> >> versions.
> >>
> >> Thanks
> >> Massimiliano
> >>
> >> [1] https://github.com/mbugni/centos-remix
> >> [2]
> >>
> https://github.com/mbugni/centos-remix/blob/master/kickstarts/8/l10n/kde-wo…
> >> [3]
> >>
> https://github.com/mbugni/centos-remix/blob/master/kickstarts/8/base-repo.ks
> >> _______________________________________________
> >> kde mailing list -- kde(a)lists.fedoraproject.org
> >> To unsubscribe send an email to kde-leave(a)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/kde@lists.fedoraproject.org
> >> Do not reply to spam on the list, report it:
> >> https://pagure.io/fedora-infrastructure
> >>
> > _______________________________________________
> > CentOS-devel mailing list
> > CentOS-devel(a)centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
> >
>
>
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel(a)centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
>