[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-333b5cbf08 barrier-2.4.0-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-b2015c9ac8 seamonkey-2.53.11-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-17ae719cb2 syncthing-1.18.6-3.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing libwbxml-0.11.8-1.el8 perl-CryptX-0.076-1.el8 synergy-1.14.3.5-1.el8 Details about builds: libwbxml-0.11.8-1.el8 (FEDORA-EPEL-2022-c7301c1295) Library and tools to parse, encode and handle WBXML documents Update Information: This release adapts to changes in expat >= 2.4.6. It also fixes a crash when parsing an invalid input. ChangeLog: * Tue Mar 1 2022 Petr Pisar - 0.11.8-1 - 0.11.8 bump References: [ 1 ] Bug #2059444 - libwbxml-0.11.8 is available https://bugzilla.redhat.com/show_bug.cgi?id=2059444 perl-CryptX-0.076-1.el8 (FEDORA-EPEL-2022-323b1cd067) Cryptographic toolkit Update Information: First EPEL 8 build. ChangeLog: * Mon Feb 14 2022 Xavier Bachelot - 0.076-1 - Update to 0.076 (RHBZ#1549877) - Use bundled libtomcrypt and libtommath to enable ECC support (RHBZ#1654710) * Fri Jan 21 2022 Fedora Release Engineering - 0.053-25 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Mon Jan 10 2022 Petr Pisar - 0.053-24 - Hide internal functions (upstream bug #68) * Wed Oct 6 2021 Petr Pisar - 0.053-23 - Adapt to changes in Math-BigInt-1.999825 (bug #2011184) * Thu Jul 22 2021 Fedora Release Engineering - 0.053-22 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Mon Jul 19 2021 Petr Pisar - 0.053-21 - Do not disable LTO (upstream bug #70) * Fri May 21 2021 Jitka Plesnikova - 0.053-20 - Perl 5.34 rebuild * Tue Mar 30 2021 Petr Pisar - 0.053-19 - Fix handling PEM decoding failures (upstream bug #67) - Package tests * Wed Jan 27 2021 Fedora Release Engineering - 0.053-18 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Jul 28 2020 Fedora Release Engineering - 0.053-17 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Fri Jun 26 2020 Jitka Plesnikova - 0.053-16 - Perl 5.32 rebuild * Wed Jun 24 2020 Petr Pisar - 0.053-15 - Remove t/wycheproof.t test (bug #1850379) * Tue Jun 23 2020 Jitka Plesnikova - 0.053-14 - Perl 5.32 rebuild * Wed Jan 29 2020 Fedora Release Engineering - 0.053-13 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Thu Nov 7 2019 Petr Pisar - 0.053-12 - Adapt to changes in Math-BigInt 1.999817 (bug #1769850) * Fri Jul 26 2019 Fedora Release Engineering - 0.053-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Mon Jul 1 2019 Petr Pisar - 0.053-10 - Require Math::Complex for running tests * Fri May 31 2019 Jitka Plesnikova - 0.053-9 - Perl 5.30 rebuild * Fri Feb 1 2019 Fedora Release Engineering - 0.053-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Thu Nov 29 2018 Petr Pisar - 0.053-7 - Adapt to changes in libtomcrypt-1.18.2 (bug #1605403) - Adapt to changes in Math-BigInt-1.999815 * Fri Jul 13 2018 Fedora Release Engineering - 0.053-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Thu Jun 28 2018 Jitka Plesnikova - 0.053-5 - Perl 5.28 rebuild * Thu May 3 2018 Petr Pisar - 0.053-4 - Adapt tests to changes in Math::BigInt 1.999813 * Thu Mar 1 2018 Florian Weimer - 0.053-3 - Rebuild with new redhat-rpm-config/perl build flags * Wed Feb 28 2018 Petr Pisar - 0.053-2 - Validate decode_b58b input properly * Thu Feb 15 2018 Petr Pisar 0.053-1 - Specfile autogenerated by cpanspec 1.78. synergy-1.14.3.5-1.el8 (FEDORA-EPEL-2022-bfcaa872dd) Share mouse and keyboard between multiple computers over the network Update Information: - Upstream update 1.14.3.5 ChangeLog: * Fri Feb 25 2022 Ding-Yi Chen - 1:1.14.3.5-1 - Upstream update to v1.14.3.5-stable - Add
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-18ac3af1c8 varnish-4.0.5-3.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-af77a11507 seamonkey-2.53.11-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing nodejs-less-4.1.2-1.el7 perl-CryptX-0.076-1.el7 Details about builds: nodejs-less-4.1.2-1.el7 (FEDORA-EPEL-2022-650bd8199d) Less.js The dynamic stylesheet language Update Information: Update to the latest release (4.1.2), adding compatibility with recent Node.js versions. ChangeLog: * Mon Feb 28 2022 Stephen Gallagher - 4.1.2-1 - Upgrade to 4.1.2 for support of recent Node.js versions perl-CryptX-0.076-1.el7 (FEDORA-EPEL-2022-35a4e24bd0) Cryptographic toolkit Update Information: First EPEL 7 build ChangeLog: * Mon Feb 14 2022 Xavier Bachelot - 0.076-1 - Update to 0.076 (RHBZ#1549877) - Use bundled libtomcrypt and libtommath to enable ECC support (RHBZ#1654710) * Fri Jan 21 2022 Fedora Release Engineering - 0.053-25 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild * Mon Jan 10 2022 Petr Pisar - 0.053-24 - Hide internal functions (upstream bug #68) * Wed Oct 6 2021 Petr Pisar - 0.053-23 - Adapt to changes in Math-BigInt-1.999825 (bug #2011184) * Thu Jul 22 2021 Fedora Release Engineering - 0.053-22 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Mon Jul 19 2021 Petr Pisar - 0.053-21 - Do not disable LTO (upstream bug #70) * Fri May 21 2021 Jitka Plesnikova - 0.053-20 - Perl 5.34 rebuild * Tue Mar 30 2021 Petr Pisar - 0.053-19 - Fix handling PEM decoding failures (upstream bug #67) - Package tests * Wed Jan 27 2021 Fedora Release Engineering - 0.053-18 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Jul 28 2020 Fedora Release Engineering - 0.053-17 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Fri Jun 26 2020 Jitka Plesnikova - 0.053-16 - Perl 5.32 rebuild * Wed Jun 24 2020 Petr Pisar - 0.053-15 - Remove t/wycheproof.t test (bug #1850379) * Tue Jun 23 2020 Jitka Plesnikova - 0.053-14 - Perl 5.32 rebuild * Wed Jan 29 2020 Fedora Release Engineering - 0.053-13 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Thu Nov 7 2019 Petr Pisar - 0.053-12 - Adapt to changes in Math-BigInt 1.999817 (bug #1769850) * Fri Jul 26 2019 Fedora Release Engineering - 0.053-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Mon Jul 1 2019 Petr Pisar - 0.053-10 - Require Math::Complex for running tests * Fri May 31 2019 Jitka Plesnikova - 0.053-9 - Perl 5.30 rebuild * Fri Feb 1 2019 Fedora Release Engineering - 0.053-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Thu Nov 29 2018 Petr Pisar - 0.053-7 - Adapt to changes in libtomcrypt-1.18.2 (bug #1605403) - Adapt to changes in Math-BigInt-1.999815 * Fri Jul 13 2018 Fedora Release Engineering - 0.053-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Thu Jun 28 2018 Jitka Plesnikova - 0.053-5 - Perl 5.28 rebuild * Thu May 3 2018 Petr Pisar - 0.053-4 - Adapt tests to changes in Math::BigInt 1.999813 * Thu Mar 1 2018 Florian Weimer - 0.053-3 - Rebuild with new redhat-rpm-config/perl build flags * Wed Feb 28 2018 Petr Pisar - 0.053-2 - Validate decode_b58b input properly * Thu Feb 15 2018 Petr Pisar 0.053-1 - Specfile autogenerated by cpanspec 1.78. ___ 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: Missing RHEL 9 buildroot packages in EPEL 9 buildroot
On Tue, Mar 1, 2022 at 8:45 AM Stephen John Smoogen wrote:
>
>
>
> On Tue, 1 Mar 2022 at 08:19, Richard W.M. Jones wrote:
>>
>> On Tue, Mar 01, 2022 at 04:21:56AM -0500, Neal Gompa wrote:
>> > On Tue, Mar 1, 2022 at 3:07 AM Richard W.M. Jones
>> > wrote:
>> > >
>> > >
>> > > https://bugzilla.redhat.com/show_bug.cgi?id=2058274
>> > >
>> > > fails to build with:
>> > >
>> > > DEBUG util.py:444: No matching package to install: 'ocaml-dune >= 1.0'
>> > >
>> > > This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
>> > >
>> > > I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
>> > > disappearing from the EPEL 9 buildroot") and it seems to indicate that
>> > > RHEL 9 buildroot packages aren't going to be available in EPEL 9.
>> > > This seems crazy, is it really correct?
>> > >
>> >
>> > It's not crazy. EPEL is intended to build on RHEL content, which means
>> > we can't depend on something RHEL doesn't publish. If Red Hat wants to
>> > publish their buildroot repo, then sure, we could use it.
>>
>> I wasn't very clear, but I was addressing my remark at Red Hat.
>> There's really no reason why we (Red Hat) don't publish buildroot, in
>> fact my personal view is we ought to for open source reasons.
>>
>
> I do not think you will find much disagreement here.. but after 3+ years of
> saying it and nothing changing, many of us have made our peace.
To be a bit more fair, we have not blindly added all buildroot content
to RHEL. However, we have made progress on coming up with a way to
request these packages be added and worked to help teams internally
understand the implications of this. We continue to add content to
every RHEL minor release.
That's not nothing. It's just not everything.
josh
___
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: Missing RHEL 9 buildroot packages in EPEL 9 buildroot
On Tue, 1 Mar 2022 at 08:19, Richard W.M. Jones wrote:
> On Tue, Mar 01, 2022 at 04:21:56AM -0500, Neal Gompa wrote:
> > On Tue, Mar 1, 2022 at 3:07 AM Richard W.M. Jones
> wrote:
> > >
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2058274
> > >
> > > fails to build with:
> > >
> > > DEBUG util.py:444: No matching package to install: 'ocaml-dune >=
> 1.0'
> > >
> > > This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
> > >
> > > I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
> > > disappearing from the EPEL 9 buildroot") and it seems to indicate that
> > > RHEL 9 buildroot packages aren't going to be available in EPEL 9.
> > > This seems crazy, is it really correct?
> > >
> >
> > It's not crazy. EPEL is intended to build on RHEL content, which means
> > we can't depend on something RHEL doesn't publish. If Red Hat wants to
> > publish their buildroot repo, then sure, we could use it.
>
> I wasn't very clear, but I was addressing my remark at Red Hat.
> There's really no reason why we (Red Hat) don't publish buildroot, in
> fact my personal view is we ought to for open source reasons.
>
>
I do not think you will find much disagreement here.. but after 3+ years of
saying it and nothing changing, many of us have made our peace.
> > Just because it happens to exist in the CentOS Stream 9 buildroot
> > content does not mean we would be able to rely on it once we replace
> > CentOS Stream with RHEL for EPEL 9. Thus, we don't use the CentOS
> > Stream 9 buildroot either.
>
> So this was going to be my next question - is it that difficult to use
> C9S buildroot packages to replace the "missing" ones? AFAIK they
> ought to be almost identical. Obviously they are rebuilds and they
> might be a little out of sync, but saves EPEL doing a literal third
> rebuild of the same content!
>
>
The issue in the past has been that it takes manual matching at times to
make it work. Koji, mock and rpmbuild will all complain in different ways
when package content varies in minute ways. Someone then has to rebuild
that package when that happens, which usually only is found at 2am by some
very cranky engineer who posts a lot of less than polite messages about how
EPEL people are complete crap. Or you find that the internal package is
good enough to have built the RHEL content but still is lacking something
that you expected to be there for anything NOT a RHEL content. Again that
takes inspection and someone to care enough to do it. If we need that, then
we might as well rebuild the content and make sure it is what we wanted in
the first place.
> > If we did, we'd wind up in a situation where packages were built once
> > and then not buildable ever again. That already kind of happened when
> > we initially had that buildroot repo in the EPEL build environment and
> > it made it way harder for us to figure out what gaps we had for things
> > to build against RHEL later. We've fortunately dealt with the small
> > number of cases that occurred from then.
>
> I'm not sure I totally understand this bit. Is it right to say that
> packages wouldn't be "buildable ever again" only in the case where we
> used C9S buildroot and then dropped it? If we just use C9S buildroot
> packages + RHEL 9 packages - forever - we'd be OK?
>
>
The way Fedora build system deals with RHEL packages is a bit of 'hack'
compared to how it builds Fedora packages. It sees them as external
packages and (mis)-uses a method which was originally only for
bootstrapping a distro to see packages it did not build itself. This then
requires additional hacks on top of that to keep the facade working.. those
hacks break regularly and have to be manually dealt with. Usually the
breakage then requires some 'we can break the koji database again so do a
full backup and possibly a restore' actions by Fedora release engineering
to delete some entry koji 'thinks' should be there but isn't (or vice
versa). [I believe this happened at least twice when we tried mixing stream
and non-stream.]
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> ___
> 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
>
--
Stephen J Smoogen.
Let us be kind to one another, for most of us
[EPEL-devel] Re: Missing RHEL 9 buildroot packages in EPEL 9 buildroot
On Tue, Mar 1, 2022 at 8:20 AM Richard W.M. Jones wrote:
>
> On Tue, Mar 01, 2022 at 04:21:56AM -0500, Neal Gompa wrote:
> > On Tue, Mar 1, 2022 at 3:07 AM Richard W.M. Jones wrote:
> > >
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2058274
> > >
> > > fails to build with:
> > >
> > > DEBUG util.py:444: No matching package to install: 'ocaml-dune >= 1.0'
> > >
> > > This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
> > >
> > > I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
> > > disappearing from the EPEL 9 buildroot") and it seems to indicate that
> > > RHEL 9 buildroot packages aren't going to be available in EPEL 9.
> > > This seems crazy, is it really correct?
> > >
> >
> > It's not crazy. EPEL is intended to build on RHEL content, which means
> > we can't depend on something RHEL doesn't publish. If Red Hat wants to
> > publish their buildroot repo, then sure, we could use it.
>
> I wasn't very clear, but I was addressing my remark at Red Hat.
> There's really no reason why we (Red Hat) don't publish buildroot, in
> fact my personal view is we ought to for open source reasons.
>
> > Just because it happens to exist in the CentOS Stream 9 buildroot
> > content does not mean we would be able to rely on it once we replace
> > CentOS Stream with RHEL for EPEL 9. Thus, we don't use the CentOS
> > Stream 9 buildroot either.
>
> So this was going to be my next question - is it that difficult to use
> C9S buildroot packages to replace the "missing" ones? AFAIK they
> ought to be almost identical. Obviously they are rebuilds and they
> might be a little out of sync, but saves EPEL doing a literal third
> rebuild of the same content!
>
Theoretically, yes. And for some stuff, that would work. It depends on
how sensitive things are and where they lie in the dependency chain.
> > If we did, we'd wind up in a situation where packages were built once
> > and then not buildable ever again. That already kind of happened when
> > we initially had that buildroot repo in the EPEL build environment and
> > it made it way harder for us to figure out what gaps we had for things
> > to build against RHEL later. We've fortunately dealt with the small
> > number of cases that occurred from then.
>
> I'm not sure I totally understand this bit. Is it right to say that
> packages wouldn't be "buildable ever again" only in the case where we
> used C9S buildroot and then dropped it? If we just use C9S buildroot
> packages + RHEL 9 packages - forever - we'd be OK?
>
Those packages are not necessarily guaranteed to be installable
forever because they're effectively only there as a side-effect. But
it's *possible* we'd be fine.
There is another issue with using buildroot packages: they're not
signed and mirrored at all. There's no reasonable way to expect
downstreams to be able to figure out how to build our packages with
any reasonable trust. People already don't like the fact that RHEL
doesn't do it, I think they'd be extremely upset if it led to EPEL
packages that people couldn't easily locally (re)build and update.
It's also more common for EPEL packagers to be in environments where
unsigned content is simply flat out blocked by policy, so RPM would
trip up over installing those packages.
And yay supply chain attacks! :(
--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Missing RHEL 9 buildroot packages in EPEL 9 buildroot
On Tue, Mar 01, 2022 at 04:21:56AM -0500, Neal Gompa wrote:
> On Tue, Mar 1, 2022 at 3:07 AM Richard W.M. Jones wrote:
> >
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2058274
> >
> > fails to build with:
> >
> > DEBUG util.py:444: No matching package to install: 'ocaml-dune >= 1.0'
> >
> > This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
> >
> > I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
> > disappearing from the EPEL 9 buildroot") and it seems to indicate that
> > RHEL 9 buildroot packages aren't going to be available in EPEL 9.
> > This seems crazy, is it really correct?
> >
>
> It's not crazy. EPEL is intended to build on RHEL content, which means
> we can't depend on something RHEL doesn't publish. If Red Hat wants to
> publish their buildroot repo, then sure, we could use it.
I wasn't very clear, but I was addressing my remark at Red Hat.
There's really no reason why we (Red Hat) don't publish buildroot, in
fact my personal view is we ought to for open source reasons.
> Just because it happens to exist in the CentOS Stream 9 buildroot
> content does not mean we would be able to rely on it once we replace
> CentOS Stream with RHEL for EPEL 9. Thus, we don't use the CentOS
> Stream 9 buildroot either.
So this was going to be my next question - is it that difficult to use
C9S buildroot packages to replace the "missing" ones? AFAIK they
ought to be almost identical. Obviously they are rebuilds and they
might be a little out of sync, but saves EPEL doing a literal third
rebuild of the same content!
> If we did, we'd wind up in a situation where packages were built once
> and then not buildable ever again. That already kind of happened when
> we initially had that buildroot repo in the EPEL build environment and
> it made it way harder for us to figure out what gaps we had for things
> to build against RHEL later. We've fortunately dealt with the small
> number of cases that occurred from then.
I'm not sure I totally understand this bit. Is it right to say that
packages wouldn't be "buildable ever again" only in the case where we
used C9S buildroot and then dropped it? If we just use C9S buildroot
packages + RHEL 9 packages - forever - we'd be OK?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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: Missing RHEL 9 buildroot packages in EPEL 9 buildroot
On Tue, 1 Mar 2022 at 03:06, Richard W.M. Jones wrote:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2058274
>
> fails to build with:
>
> DEBUG util.py:444: No matching package to install: 'ocaml-dune >= 1.0'
>
> This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
>
> I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
> disappearing from the EPEL 9 buildroot") and it seems to indicate that
> RHEL 9 buildroot packages aren't going to be available in EPEL 9.
> This seems crazy, is it really correct?
>
>
This is the same as what was done for RHEL-8 and going back a bit to RHEL-5
also since it was not fully published. Buildroot-only packages will need
extra care and work to make 'epel-only' versions on them. [Experiments of
trying to mix and match CentOS Stream build root and RHEL packages have not
gone well in enough cases to keep that up.] EPEL-only packages will be also
needed as modules are added to RHEL-9 in various future dot releases.
--
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Missing RHEL 9 buildroot packages in EPEL 9 buildroot
On Tue, Mar 1, 2022 at 3:07 AM Richard W.M. Jones wrote:
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2058274
>
> fails to build with:
>
> DEBUG util.py:444: No matching package to install: 'ocaml-dune >= 1.0'
>
> This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
>
> I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
> disappearing from the EPEL 9 buildroot") and it seems to indicate that
> RHEL 9 buildroot packages aren't going to be available in EPEL 9.
> This seems crazy, is it really correct?
>
It's not crazy. EPEL is intended to build on RHEL content, which means
we can't depend on something RHEL doesn't publish. If Red Hat wants to
publish their buildroot repo, then sure, we could use it. Just because
it happens to exist in the CentOS Stream 9 buildroot content does not
mean we would be able to rely on it once we replace CentOS Stream with
RHEL for EPEL 9. Thus, we don't use the CentOS Stream 9 buildroot
either.
If we did, we'd wind up in a situation where packages were built once
and then not buildable ever again. That already kind of happened when
we initially had that buildroot repo in the EPEL build environment and
it made it way harder for us to figure out what gaps we had for things
to build against RHEL later. We've fortunately dealt with the small
number of cases that occurred from then.
--
真実はいつも一つ！/ Always, there's only one truth!
___
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] Missing RHEL 9 buildroot packages in EPEL 9 buildroot
https://bugzilla.redhat.com/show_bug.cgi?id=2058274
fails to build with:
DEBUG util.py:444: No matching package to install: 'ocaml-dune >= 1.0'
This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
disappearing from the EPEL 9 buildroot") and it seems to indicate that
RHEL 9 buildroot packages aren't going to be available in EPEL 9.
This seems crazy, is it really correct?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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
