Missing RHEL 9 buildroot packages in EPEL 9 buildroot

[Richard W.M. Jones]

  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

[Neal Gompa]

On Tue, Mar 1, 2022 at 3:07 AM Richard W.M. Jones <rjones(a)redhat.com&gt; 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!

[Richard W.M. Jones]

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
> <rjones(a)redhat.com&gt; 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

[Richard W.M. Jones]

On Tue, Mar 01, 2022 at 01:19:32PM +0000, Richard W.M. Jones wrote:
>  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! 
But to add - ideally we wouldn't need to do this if Red Hat published
the buildroot packages, and I don't understand why we don't do this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Neal Gompa]

On Tue, Mar 1, 2022 at 8:20 AM Richard W.M. Jones <rjones(a)redhat.com&gt; 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 <rjones(a)redhat.com&gt; 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!

[Stephen John Smoogen]

On Tue, 1 Mar 2022 at 08:19, Richard W.M. Jones <rjones(a)redhat.com&gt; 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 <rjones(a)redhat.com&gt;
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to epel-devel-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/[e-mail]...
>  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 are fighting a hard battle.
-- Ian MacClaren

[Josh Boyer]

On Tue, Mar 1, 2022 at 8:45 AM Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  On Tue, 1 Mar 2022 at 08:19, Richard W.M. Jones <rjones(a)redhat.com&gt; 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 <rjones(a)redhat.com&gt;
> 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

[Richard W.M. Jones]

To keep this a bit more specific, we're trying to build coccinelle for
EPEL 9.  This requires ocaml [compiler] and a bunch of ocaml packages.
They are mainly in RHEL buildroot.

The problem we're going to have (which to be fair is a problem
somewhat specific to OCaml linking) is that an alternate OCaml
compiler built for EPEL will have different hash values[1] for core
libraries.

If we use a different version from the RHEL compiler, say we use
Fedora Rawhide version, then all the hashes will be different.

If we use the same version as in RHEL, then most hash values will be
the same, but if the compiler flags are even slightly different then
there will be some differences.

OCaml libraries in RHEL that we do ship (ocaml-libnbd and others) will
not be linkable with code compiled with the EPEL toolchain.

It's entirely possible we don't care about this, and I maybe even
agree.  But also that people using RHEL with EPEL added will get into
weird situations if they try to recompile the virt tools packages.

Rich.

[1] Hash values are computed over the modules to prevent linking
incompatible versions:

$ ocamlobjinfo /usr/lib64/ocaml/unix.cma  | grep Unix
Unit name: Unix
     49c6c492a189deeaed5bf77a6793e7fa	Unix

and turned into RPM dependencies:

$ rpm -qR ocaml | grep Unix
ocaml(Unix) = 49c6c492a189deeaed5bf77a6793e7fa

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

[Neal Gompa]

On Wed, Mar 2, 2022 at 8:52 AM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  To keep this a bit more specific, we're trying to build coccinelle for
>  EPEL 9.  This requires ocaml [compiler] and a bunch of ocaml packages.
>  They are mainly in RHEL buildroot.
>
>  The problem we're going to have (which to be fair is a problem
>  somewhat specific to OCaml linking) is that an alternate OCaml
>  compiler built for EPEL will have different hash values[1] for core
>  libraries.
>
>  If we use a different version from the RHEL compiler, say we use
>  Fedora Rawhide version, then all the hashes will be different.
>
>  If we use the same version as in RHEL, then most hash values will be
>  the same, but if the compiler flags are even slightly different then
>  there will be some differences.
>
>  OCaml libraries in RHEL that we do ship (ocaml-libnbd and others) will
>  not be linkable with code compiled with the EPEL toolchain.
>
>  It's entirely possible we don't care about this, and I maybe even
>  agree.  But also that people using RHEL with EPEL added will get into
>  weird situations if they try to recompile the virt tools packages.
>
>  Rich.
>
>  [1] Hash values are computed over the modules to prevent linking
>  incompatible versions:
>
>  $ ocamlobjinfo /usr/lib64/ocaml/unix.cma  | grep Unix
>  Unit name: Unix
>       49c6c492a189deeaed5bf77a6793e7fa   Unix
>
>  and turned into RPM dependencies:
>
>  $ rpm -qR ocaml | grep Unix
>  ocaml(Unix) = 49c6c492a189deeaed5bf77a6793e7fa
>  
So why not have the OCaml toolchain exposed in RHEL CRB? It sounds
like it would be very beneficial to have it there.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Richard W.M. Jones]

On Wed, Mar 02, 2022 at 09:04:04AM -0500, Neal Gompa wrote:
>  So why not have the OCaml toolchain exposed in RHEL CRB? It sounds
>  like it would be very beneficial to have it there. 
It's a good question.  I think we chose not to do that simply because
we were worried about handling CVEs in a timely way and general
support (I'm not sure if CRB is officially supported or not, but there
may be some "implicit" support if we're shipping stuff).  I would not
be opposed to it though.

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

[Josh Boyer]

On Thu, Mar 3, 2022 at 12:27 PM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Wed, Mar 02, 2022 at 09:04:04AM -0500, Neal Gompa wrote:
>  > So why not have the OCaml toolchain exposed in RHEL CRB? It sounds
>  > like it would be very beneficial to have it there.
>
>  It's a good question.  I think we chose not to do that simply because
>  we were worried about handling CVEs in a timely way and general
>  support (I'm not sure if CRB is officially supported or not, but there
>  may be some "implicit" support if we're shipping stuff).  I would not
>  be opposed to it though. 
This requires a Customer Portal account

https://access.redhat.com/solutions/4180391

The CRB repo is documented heavily internally as well.

josh

[Richard W.M. Jones]

On Thu, Mar 03, 2022 at 12:42:03PM -0500, Josh Boyer wrote:
>  On Thu, Mar 3, 2022 at 12:27 PM Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
>  >
>  > On Wed, Mar 02, 2022 at 09:04:04AM -0500, Neal Gompa wrote:
>  > > So why not have the OCaml toolchain exposed in RHEL CRB? It sounds
>  > > like it would be very beneficial to have it there.
>  >
>  > It's a good question.  I think we chose not to do that simply because
>  > we were worried about handling CVEs in a timely way and general
>  > support (I'm not sure if CRB is officially supported or not, but there
>  > may be some "implicit" support if we're shipping stuff).  I would not
>  > be opposed to it though.
>  
>  This requires a Customer Portal account
>  
>  https://access.redhat.com/solutions/4180391
>  
>  The CRB repo is documented heavily internally as well. 
I see "not supported" and "no ABI compatibility guarantee" in bold
there which is what we want.

I'll see if we can move the OCaml packages to CRB.  It seems to be the
easiest way to fix the original coccinelle build problem.

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

[Richard W.M. Jones]

On Fri, Mar 04, 2022 at 10:51:48AM +0000, Richard W.M. Jones wrote:
>  I'll see if we can move the OCaml packages to CRB.  It seems to
> be the
>  easiest way to fix the original coccinelle build problem. 
This gets odder.  I see from our internal spreadsheet and downloads
that some of the ocaml packages are in fact already in CRB for RHEL
9.0, and others are not.  We previously requested that all ocaml-*
packages be added to CRB.

Binary packages which are not in CRB but should be:

ocaml-calendar*
ocaml-camomile*
ocaml-csexp*
ocaml-csv*
ocaml-curses*
ocaml-dune*
ocaml-fileutils*
ocaml-gettext*
ocaml-libvirt*
ocaml-source
ocaml-xml-light*

Do you need a BZ opened to move these packages to CRB?

(Insert here my monthly request that there be a single source of truth
about packages.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Neal Gompa]

On Fri, Mar 4, 2022 at 6:01 AM Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  On Fri, Mar 04, 2022 at 10:51:48AM +0000, Richard W.M. Jones wrote:
>  > I'll see if we can move the OCaml packages to CRB.  It seems to be the
>  > easiest way to fix the original coccinelle build problem.
>
>  This gets odder.  I see from our internal spreadsheet and downloads
>  that some of the ocaml packages are in fact already in CRB for RHEL
>  9.0, and others are not.  We previously requested that all ocaml-*
>  packages be added to CRB.
>
>  Binary packages which are not in CRB but should be:
>
>  ocaml-calendar*
>  ocaml-camomile*
>  ocaml-csexp*
>  ocaml-csv*
>  ocaml-curses*
>  ocaml-dune*
>  ocaml-fileutils*
>  ocaml-gettext*
>  ocaml-libvirt*
>  ocaml-source
>  ocaml-xml-light*
>
>  Do you need a BZ opened to move these packages to CRB?
>
>  (Insert here my monthly request that there be a single source of truth
>  about packages.) 
If you already had a ACKed BZ/Jira for these, you can probably
reference that and make the necessary merge requests to comps[1] and
pungi[2].

[1]: https://gitlab.com/redhat/centos-stream/release-engineering/comps
[2]: https://gitlab.com/redhat/centos-stream/release-engineering/pungi-centos



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Richard W.M. Jones]

On Fri, Mar 04, 2022 at 11:01:20AM +0000, Richard W.M. Jones wrote:
>  On Fri, Mar 04, 2022 at 10:51:48AM +0000, Richard W.M. Jones wrote:
>  > I'll see if we can move the OCaml packages to CRB.  It seems to be the
>  > easiest way to fix the original coccinelle build problem.
>  
>  This gets odder.  I see from our internal spreadsheet and downloads
>  that some of the ocaml packages are in fact already in CRB for RHEL
>  9.0, and others are not.  We previously requested that all ocaml-*
>  packages be added to CRB.
>  
>  Binary packages which are not in CRB but should be:
>  
>  ocaml-calendar*
>  ocaml-camomile*
>  ocaml-csexp*
>  ocaml-csv*
>  ocaml-curses*
>  ocaml-dune*
>  ocaml-fileutils*
>  ocaml-gettext*
>  ocaml-libvirt*
>  ocaml-source
>  ocaml-xml-light*
>  
>  Do you need a BZ opened to move these packages to CRB? 
https://bugzilla.redhat.com/show_bug.cgi?id=2060850

I didn't know what Product / Component to use, so I used
RHEL 9 / distribution.

Rich.

>  (Insert here my monthly request that there be a single source of
> truth
>  about packages.)
>  
>  Rich.
>  
>  -- 
>  Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
>  Read my programming and virtualization blog: http://rwmj.wordpress.com
>  libguestfs lets you edit virtual machines.  Supports shell scripting,
>  bindings from many languages.  http://libguestfs.org
>  _______________________________________________
>  epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to epel-devel-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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- 
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

[Richard W.M. Jones]

On Fri, Mar 04, 2022 at 11:14:31AM +0000, Richard W.M. Jones wrote:
>  On Fri, Mar 04, 2022 at 11:01:20AM +0000, Richard W.M. Jones wrote:
>  > On Fri, Mar 04, 2022 at 10:51:48AM +0000, Richard W.M. Jones wrote:
>  > > I'll see if we can move the OCaml packages to CRB.  It seems to be the
>  > > easiest way to fix the original coccinelle build problem.
>  > 
>  > This gets odder.  I see from our internal spreadsheet and downloads
>  > that some of the ocaml packages are in fact already in CRB for RHEL
>  > 9.0, and others are not.  We previously requested that all ocaml-*
>  > packages be added to CRB.
>  > 
>  > Binary packages which are not in CRB but should be:
>  > 
>  > ocaml-calendar*
>  > ocaml-camomile*
>  > ocaml-csexp*
>  > ocaml-csv*
>  > ocaml-curses*
>  > ocaml-dune*
>  > ocaml-fileutils*
>  > ocaml-gettext*
>  > ocaml-libvirt*
>  > ocaml-source
>  > ocaml-xml-light*
>  > 
>  > Do you need a BZ opened to move these packages to CRB?
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=2060850 
Currently even with this bug fixed we won't be able to build
Coccinelle until RHEL 9.1 is released, which is like 9+ months away.
This (if true) is ridiculous.  Is there some other solution?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Petr Pisar]

V Fri, Mar 11, 2022 at 09:36:08AM +0000, Richard W.M. Jones napsal(a):
>  On Fri, Mar 04, 2022 at 11:14:31AM +0000, Richard W.M. Jones wrote:
>  > On Fri, Mar 04, 2022 at 11:01:20AM +0000, Richard W.M. Jones wrote:
>  > > On Fri, Mar 04, 2022 at 10:51:48AM +0000, Richard W.M. Jones wrote:
>  > > > I'll see if we can move the OCaml packages to CRB.  It seems to be
> the
>  > > > easiest way to fix the original coccinelle build problem.
>  > > 
>  > > This gets odder.  I see from our internal spreadsheet and downloads
>  > > that some of the ocaml packages are in fact already in CRB for RHEL
>  > > 9.0, and others are not.  We previously requested that all ocaml-*
>  > > packages be added to CRB.
>  > > 
>  > > Binary packages which are not in CRB but should be:
>  > > 
>  > > ocaml-calendar*
>  > > ocaml-camomile*
>  > > ocaml-csexp*
>  > > ocaml-csv*
>  > > ocaml-curses*
>  > > ocaml-dune*
>  > > ocaml-fileutils*
>  > > ocaml-gettext*
>  > > ocaml-libvirt*
>  > > ocaml-source
>  > > ocaml-xml-light*
>  > > 
>  > > Do you need a BZ opened to move these packages to CRB?
>  > 
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2060850
>  
>  Currently even with this bug fixed we won't be able to build
>  Coccinelle until RHEL 9.1 is released, which is like 9+ months away.
>  This (if true) is ridiculous.  Is there some other solution?
>   
That's not ridiculous. That's a release cadence of RHEL.

Maybe you could use EPEL 9 Next which is based on CentOS Stream 9. There is
the change already visible
<http://mirror.stream.centos.org/9-stream/CRB/x86_64/os/Packages/>;. However,
I'm not sure whether EPEL 9 Next is still a thing.

-- Petr

[Miro Hrončok]

On 11. 03. 22 10:36, Richard W.M. Jones wrote:
>  On Fri, Mar 04, 2022 at 11:14:31AM +0000, Richard W.M. Jones wrote:
> > On Fri, Mar 04, 2022 at 11:01:20AM +0000, Richard W.M. Jones wrote:
> >> On Fri, Mar 04, 2022 at 10:51:48AM +0000, Richard W.M. Jones wrote:
> >>> I'll see if we can move the OCaml packages to CRB.  It seems to be the
> >>> easiest way to fix the original coccinelle build problem.
> >>
> >> This gets odder.  I see from our internal spreadsheet and downloads
> >> that some of the ocaml packages are in fact already in CRB for RHEL
> >> 9.0, and others are not.  We previously requested that all ocaml-*
> >> packages be added to CRB.
> >>
> >> Binary packages which are not in CRB but should be:
> >>
> >> ocaml-calendar*
> >> ocaml-camomile*
> >> ocaml-csexp*
> >> ocaml-csv*
> >> ocaml-curses*
> >> ocaml-dune*
> >> ocaml-fileutils*
> >> ocaml-gettext*
> >> ocaml-libvirt*
> >> ocaml-source
> >> ocaml-xml-light*
> >>
> >> Do you need a BZ opened to move these packages to CRB?
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2060850
>  
>  Currently even with this bug fixed we won't be able to build
>  Coccinelle until RHEL 9.1 is released, which is like 9+ months away.
>  This (if true) is ridiculous.  Is there some other solution? 
Given that EPEL 9 now builds against CentOS Stream, this is not necessarily true.

The other solution would have been to include the packages in CRB sooner :D

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok

[Richard W.M. Jones]

On Fri, Mar 11, 2022 at 10:57:29AM +0100, Miro Hrončok wrote:
>  On 11. 03. 22 10:36, Richard W.M. Jones wrote:
>  >On Fri, Mar 04, 2022 at 11:14:31AM +0000, Richard W.M. Jones wrote:
>  >>On Fri, Mar 04, 2022 at 11:01:20AM +0000, Richard W.M. Jones wrote:
>  >>>On Fri, Mar 04, 2022 at 10:51:48AM +0000, Richard W.M. Jones wrote:
>  >>>>I'll see if we can move the OCaml packages to CRB.  It seems to be
> the
>  >>>>easiest way to fix the original coccinelle build problem.
>  >>>
>  >>>This gets odder.  I see from our internal spreadsheet and downloads
>  >>>that some of the ocaml packages are in fact already in CRB for RHEL
>  >>>9.0, and others are not.  We previously requested that all ocaml-*
>  >>>packages be added to CRB.
>  >>>
>  >>>Binary packages which are not in CRB but should be:
>  >>>
>  >>>ocaml-calendar*
>  >>>ocaml-camomile*
>  >>>ocaml-csexp*
>  >>>ocaml-csv*
>  >>>ocaml-curses*
>  >>>ocaml-dune*
>  >>>ocaml-fileutils*
>  >>>ocaml-gettext*
>  >>>ocaml-libvirt*
>  >>>ocaml-source
>  >>>ocaml-xml-light*
>  >>>
>  >>>Do you need a BZ opened to move these packages to CRB?
>  >>
>  >>https://bugzilla.redhat.com/show_bug.cgi?id=2060850
>  >
>  >Currently even with this bug fixed we won't be able to build
>  >Coccinelle until RHEL 9.1 is released, which is like 9+ months away.
>  >This (if true) is ridiculous.  Is there some other solution?
>  
>  Given that EPEL 9 now builds against CentOS Stream, this is not necessarily true.
>  
>  The other solution would have been to include the packages in CRB sooner :D 
I've surely learned a lesson never to use RHEL buildroot for anything.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Richard W.M. Jones]

On Fri, Mar 11, 2022 at 09:36:08AM +0000, Richard W.M. Jones wrote:
>  On Fri, Mar 04, 2022 at 11:14:31AM +0000, Richard W.M. Jones wrote:
>  > On Fri, Mar 04, 2022 at 11:01:20AM +0000, Richard W.M. Jones wrote:
>  > > On Fri, Mar 04, 2022 at 10:51:48AM +0000, Richard W.M. Jones wrote:
>  > > > I'll see if we can move the OCaml packages to CRB.  It seems to be
> the
>  > > > easiest way to fix the original coccinelle build problem.
>  > > 
>  > > This gets odder.  I see from our internal spreadsheet and downloads
>  > > that some of the ocaml packages are in fact already in CRB for RHEL
>  > > 9.0, and others are not.  We previously requested that all ocaml-*
>  > > packages be added to CRB.
>  > > 
>  > > Binary packages which are not in CRB but should be:
>  > > 
>  > > ocaml-calendar*
>  > > ocaml-camomile*
>  > > ocaml-csexp*
>  > > ocaml-csv*
>  > > ocaml-curses*
>  > > ocaml-dune*
>  > > ocaml-fileutils*
>  > > ocaml-gettext*
>  > > ocaml-libvirt*
>  > > ocaml-source
>  > > ocaml-xml-light*
>  > > 
>  > > Do you need a BZ opened to move these packages to CRB?
>  > 
>  > https://bugzilla.redhat.com/show_bug.cgi?id=2060850
>  
>  Currently even with this bug fixed we won't be able to build
>  Coccinelle until RHEL 9.1 is released, which is like 9+ months away.
>  This (if true) is ridiculous.  Is there some other solution? 
I have now rebuilt all the packages and they're in a RHEL 9.1 erratum
(RHBA-2022:89734-01 for those who have access).

Is there anything we can do to get these packages into the EPEL
buildroot so we don't have to wait forever to build coccinelle for
EPEL?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Stephen John Smoogen]

On Tue, 1 Mar 2022 at 03:06, Richard W.M. Jones <rjones(a)redhat.com&gt; 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