[EPEL-devel] Re: The incredibly shrinking RHEL

2022-01-17 Thread Troy Dawson 
On Sat, Jan 15, 2022 at 12:33 PM Orion Poplawski  wrote:

>
> I've done some poking, and this is what I've come up with for *new*
> missing -devel packages in CS9 with their approximate number of users in
> rawhide:
>
> 389-ds-base-devel 2
> accel-config-devel 0
> anthy-unicode-devel 3
> atlas-corei2-devel 0
> avahi-glib-devel 1
> avahi-gobject-devel 4
> avahi-ui-devel 1
> bind-devel 3
> blis-devel 2
> Box2D-devel 1
> cjose-devel 1
> clutter-devel 9
> clutter-gst3-devel 1
> clutter-gtk-devel 8
> cogl-devel 0
> compat-lua-devel 26
> cppunit-devel 35
> double-conversion-devel 9
> dpdk-devel 1
> emacs-devel 1
> evince-devel 3
> fdk-aac-free-devel 4
> flashrom-devel 1
> flexiblas-devel 33
> freeglut-devel 68
> fstrm-devel 4
> glusterfs-api-devel 8
> glusterfs-devel 2
> gnome-calculator-devel 0
> gnome-menus-devel 1
> gnome-software-devel 0
> gsl-devel 51
> gtk4-devel-tools 0
> gtksourceview4-devel 6
> hexchat-devel 1
> hidapi-devel 11
> ibus-anthy-devel 0
> ibus-table-devel 7
> inih-devel 3
> iscsi-initiator-utils-devel 1
> isns-utils-devel 1
> kernel-rt-debug-devel-matched 0
> kernel-rt-devel-matched 0
> ldns-devel 8
> libass-devel 1
> libblockdev-crypto-devel 1
> libblockdev-devel 1
> libblockdev-fs-devel 1
> libblockdev-loop-devel 1
> libblockdev-lvm-devel 1
> libblockdev-mdraid-devel 1
> libblockdev-part-devel 1
> libblockdev-swap-devel 2
> libblockdev-utils-devel 0
> libbytesize-devel 5
> libcbor-devel 0
> libcephfs-devel 2
> libcephsqlite-devel 0
> libdazzle-devel 1
> libeconf-devel 1
> libell-devel 3
> libepubgen-devel 0
> libev-devel 22
> libev-libevent-devel 0
> libfido2-devel 2
> libfl-devel 3
> libfoma-devel 0
> libhandy-devel 2
> libldac-devel 0
> libmng-devel 12
> libmpeg2-devel 2
> libmtp-devel 7
> libotr-devel 8
> libqrtr-glib-devel 2
> libradosstriper-devel 1
> libshaderc-devel 1
> libslirp-devel 3
> libsmartcols-devel 1
> libsmi-devel 1
> libstoragemgmt-devel 1
> libtpms-devel 1
> liburing-devel 6
> libverto-libev-devel 0
> libwpe-devel 0
> libXpresent-devel 2
> libzip-devel 16
> lldpd-devel 0
> lpsolve-devel 1
> luajit-devel 11
> make-devel 5
> mecab-devel 7
> mesa-vulkan-devel 2
> minizip-compat-devel 6
> mptcpd-devel 0
> nmstate-devel 0
> nodejs-devel 19
> ocaml-camomile-devel 5
> ocaml-csexp-devel 3
> ocaml-dune-devel 17
> physfs-devel 17
> postgresql-upgrade-devel 1
> pybind11-devel 19
> qgpgme-devel 3
> rados-objclass-devel 0
> rapidjson-devel 18
> sid-base-libs-devel 0
> sid-iface-libs-devel 0
> sid-log-libs-devel 0
> sid-resource-libs-devel 0
> speech-tools-libs-devel 1
> suitesparse64-devel 3
> suitesparse64_-devel 1
> swtpm-devel 0
> sysprof-devel 1
> tesseract-devel 5
> tix-devel 8
> uchardet-devel 4
> umockdev-devel 2
> unbound-devel 8
> v8-devel 2
> vm-dump-metrics-devel 0
> volume_key-devel 1
> web-assets-devel 66
> wireplumber-devel 0
> wpebackend-fdo-devel 1
> xkbcomp-devel 0
> xorg-x11-drv-evdev-devel 0
>
> That's a lot.  Now, many of these are pretty obscure and do not have any
> users - but I'm also seeing a number that are going to hit me and the
> scitech sig:
>
> blis-devel 2
> flexiblas-devel 33
> gsl-devel 51
> suitesparse64-devel 3
>
> There are some other big ones as well.
>

First off, thank you Orion for all your efforts and work on Fedora and
EPEL.  I don't look in Fedora as much, but I definitely do see it in EPEL,
and I appreciate it.

Second off, love your list of missing devel and how many Fedora packages
require them.  That really helps give a good perspective.

Third, and perhaps most important, we have a process to fix missing -devel
packages that affect us.[1]  I'm in the middle of making it it's own page,
along with examples and so forth.  But here's a summary.

- Short Term: Create an -epel EPEL package that only has the
missing packages.
- Long Term: Request the package be added to RHEL 8 and 9 CRB repository.

Go to the the EPEL web page[1] for more details.  Again, a better page is
coming.

Also, look in epel8 or epel9 to see if some of those missing -devel
packages are already there.  For example, gsl-devel in epel9 is already
there, because someone has already started the process.[2]

[1] -
https://docs.fedoraproject.org/en-US/epel/epel-faq/#rhel_8_has_binaries_in_the_release_but_is_missing_some_corresponding__devel_package._how_do_i_build_a_package_that_needs_that_missing__devel_package
[2] - https://bugzilla.redhat.com/show_bug.cgi?id=2035401

Troy
___
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: The incredibly shrinking RHEL

2022-01-17 Thread Paul Howarth 
On Fri, 14 Jan 2022 07:02:23 -0500
Josh Boyer  wrote:
> 2) Moving content to CRB in RHEL is not a silver bullet solution in
> many scenarios.  If it's strictly for build dependencies, CRB works
> well.  If an EPEL package has a runtime requires on CRB content, that
> is less desirable.  RHEL CodeReady Linux Builder (CRB) content is
> unsupported, not enabled by default, and not intended to be used at
> runtime in production.  EPEL itself is clearly in the same unsupported
> category, but requiring another unsupported repo at runtime may lead
> to unintentional surprises for many users.

The EPEL documentation specifically says to enable CRB/PowerTools if
you're using EPEL:

https://docs.fedoraproject.org/en-US/epel/#how_can_i_use_these_extra_packages

NOTE for RHEL 8 users with certificate subscriptions: EPEL packages
assume that the 'codeready-builder' repository is enabled. You can
do this with:

subscription-manager repos --enable
"codeready-builder-for-rhel-8-$(arch)-rpms"

NOTE for CentOS 8 and CentOS Stream 8 users: EPEL packages assume
that the 'powertools' repository is enabled. You can do this with:

dnf config-manager --set-enabled powertools


Whilst that is for EL-8 I don't see why it would be different for EL-9.
In particular, for interpreted languages like perl there are a large
number of runtime dependencies from EPEL packages to packages in CRB.

Paul.
___
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: The incredibly shrinking RHEL

2022-01-16 Thread Stephen John Smoogen 
On Sun, 16 Jan 2022 at 07:23, Miro Hrončok  wrote:

> On 16. 01. 22 12:49, Andrew C Aitchison wrote:
> > On Sun, 16 Jan 2022, Miro Hrončok wrote:
> >
> >> On 15. 01. 22 20:22, Andrew C Aitchison wrote:
> >>> On Sat, 15 Jan 2022, Miro Hrončok wrote:
> >>>
>  python-pytest-cov is something I've lobbied has no business in an
>  enterprise distro at all.
> >>>  ......
>  As for EPEL I strongly suggest not to introduce python-pytest-cov
> either.
>  If your package depends on it, please drop the dependency instead,
> see
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters
> >>>
> >>> In %check, packages SHOULD NOT run “linters”: code style checkers,
> test
> >>> coverage checkers and other tools that check code quality rather
> than
> >>> functionality.
> >>> Agreed.
> >>>
> >>> Linters do make sense in upstream CI. But not in Fedora.
> >>> Not inside Fedora *packages*, but
> >>> if these tools are not available to those using RHEL, Fedora or EPEL
> >>> is that a suitable platform for CI or for developers ?
> >>>
> >>
> >> Yes, most certainly it is a sustainable *platform* for CI. On such
> platform,
> >> you install your dev-dependendencies from PyPI. Not from the platform
> itself.
> >
> > Hmm.
> > A linter is a tool.
> > I cannot build most packages without a C compiler and I don't see many
> packages
> > with
> >  BuildRequires: gcc
> > yet I expect a dev platform to include a C compiler.
>
> I do expect a dev platform to include a C compiler as well.
> I also expect it includes Python interpreter and a tool to install Python
> packages.
> I *do not* except it to include every dev-usefull Python package however.
>
>
So two different things:
1. Actually
https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/ says
that packages do now require it. I believe this started in Fedora 30-ish so
EPEL-8/EPEL-9 packages will start requiring that.
2. We aren't talking about the OS including every dev-useful Python
package. We are talking about a repository called EPEL including things
which are in Fedora and trying to meet the  needs for Enterprise clients
which can be a mass of bailing wire of software going back to 20 years ago
but also requiring the latest stuff. A good many of them can't just do a
pypi install because they have ITIL or some other change control standard
which says that the software must have been bundled in XYZ format,
reviewed, etc. In the past EPEL was a good fit for python etc but it may
not be with the modularization and fast moving python streams.






-- 
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: The incredibly shrinking RHEL

2022-01-16 Thread Miro Hrončok 

On 16. 01. 22 12:49, Andrew C Aitchison wrote:

On Sun, 16 Jan 2022, Miro Hrončok wrote:


On 15. 01. 22 20:22, Andrew C Aitchison wrote:

On Sat, 15 Jan 2022, Miro Hrončok wrote:

python-pytest-cov is something I've lobbied has no business in an 
enterprise distro at all.

 ...    ...
As for EPEL I strongly suggest not to introduce python-pytest-cov either. 
If your package depends on it, please drop the dependency instead, see 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters


    In %check, packages SHOULD NOT run “linters”: code style checkers, test
    coverage checkers and other tools that check code quality rather than
    functionality.
Agreed.

    Linters do make sense in upstream CI. But not in Fedora.
Not inside Fedora *packages*, but
if these tools are not available to those using RHEL, Fedora or EPEL
is that a suitable platform for CI or for developers ?



Yes, most certainly it is a sustainable *platform* for CI. On such platform, 
you install your dev-dependendencies from PyPI. Not from the platform itself.


Hmm.
A linter is a tool.
I cannot build most packages without a C compiler and I don't see many packages 
with

 BuildRequires: gcc
yet I expect a dev platform to include a C compiler.


I do expect a dev platform to include a C compiler as well.
I also expect it includes Python interpreter and a tool to install Python 
packages.
I *do not* except it to include every dev-usefull Python package however.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: The incredibly shrinking RHEL

2022-01-16 Thread Andrew C Aitchison 

On Sun, 16 Jan 2022, Miro Hrončok wrote:


On 15. 01. 22 20:22, Andrew C Aitchison wrote:

On Sat, 15 Jan 2022, Miro Hrončok wrote:

python-pytest-cov is something I've lobbied has no business in an 
enterprise distro at all.

 ...    ...
As for EPEL I strongly suggest not to introduce python-pytest-cov either. 
If your package depends on it, please drop the dependency instead, see 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters


    In %check, packages SHOULD NOT run “linters”: code style checkers, test
    coverage checkers and other tools that check code quality rather than
    functionality.
Agreed.

    Linters do make sense in upstream CI. But not in Fedora.
Not inside Fedora *packages*, but
if these tools are not available to those using RHEL, Fedora or EPEL
is that a suitable platform for CI or for developers ?



Yes, most certainly it is a sustainable *platform* for CI. On such platform, 
you install your dev-dependendencies from PyPI. Not from the platform itself.


Hmm.
A linter is a tool.
I cannot build most packages without a C compiler and I don't see many 
packages with

BuildRequires: gcc
yet I expect a dev platform to include a C compiler.

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk___
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: The incredibly shrinking RHEL

2022-01-15 Thread Miro Hrončok 

On 15. 01. 22 18:41, Orion Poplawski wrote:


I was also confused about two things here:

- It's retired on the "main" branch, but the c9s branch seems intact.


Indeed, that is how this was done for many (all?) retired c9s packages. I 
believe this is confusing.



- What does "retired for CS-569" mean?


"CS-569" is a reference for an internal ticket. I believe this is not 
transparent.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: The incredibly shrinking RHEL

2022-01-15 Thread Miro Hrončok 

On 15. 01. 22 21:42, Orion Poplawski wrote:

On 1/15/22 12:22, Andrew C Aitchison wrote:

On Sat, 15 Jan 2022, Miro Hrončok wrote:

python-pytest-cov is something I've lobbied has no business in an enterprise 
distro at all.

 ...    ...
As for EPEL I strongly suggest not to introduce python-pytest-cov either. If 
your package depends on it, please drop the dependency instead, see 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters


    In %check, packages SHOULD NOT run “linters”: code style checkers, test
    coverage checkers and other tools that check code quality rather than
    functionality.
Agreed.

    Linters do make sense in upstream CI. But not in Fedora.
Not inside Fedora *packages*, but
if these tools are not available to those using RHEL, Fedora or EPEL
is that a suitable platform for CI or for developers ?



No, but that's why it will be provided in EPEL :)


Yet again, I beg you not to.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: The incredibly shrinking RHEL

2022-01-15 Thread Miro Hrončok 



On 15. 01. 22 20:22, Andrew C Aitchison wrote:

On Sat, 15 Jan 2022, Miro Hrončok wrote:

python-pytest-cov is something I've lobbied has no business in an enterprise 
distro at all.

 ...    ...
As for EPEL I strongly suggest not to introduce python-pytest-cov either. If 
your package depends on it, please drop the dependency instead, see 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters


    In %check, packages SHOULD NOT run “linters”: code style checkers, test
    coverage checkers and other tools that check code quality rather than
    functionality.
Agreed.

    Linters do make sense in upstream CI. But not in Fedora.
Not inside Fedora *packages*, but
if these tools are not available to those using RHEL, Fedora or EPEL
is that a suitable platform for CI or for developers ?



Yes, most certainly it is a sustainable *platform* for CI. On such platform, 
you install your dev-dependendencies from PyPI. Not from the platform itself.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: The incredibly shrinking RHEL

2022-01-15 Thread Josh Boyer 
On Sat, Jan 15, 2022 at 1:29 PM Orion Poplawski  wrote:
>
> On 1/14/22 05:02, Josh Boyer wrote:
> > On Fri, Jan 14, 2022 at 5:31 AM Miro Hrončok  wrote:
> >>
> >> On 14. 01. 22 5:11, Orion Poplawski wrote:
> >>> While working on EPEL9, it seems that even more packages are missing from 
> >>> RHEL9
> >>> than were in RHEL8.  The latest I found was cppunit, which appears to be
> >>> completely missing from the CS9 repos despite having been built (See
> >>> https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and
> >>> presumably in the CS9/RHEL9 buildroot.
> >>>
> >>> So I scraped some screens from pkgs.org:
> >>>
> >>> Stream 9:
> >>>
> >>> CentOS AppStream Official   x86_64 8882
> >>> CentOS BaseOS Official  x86_64 2357
> >>> CentOS CRB Official x86_64 1856
> >>>
> >>> Stream 8:
> >>>
> >>> CentOS AppStream Official   x86_64 15008
> >>> CentOS BaseOS Official  x86_64 6721
> >>> CentOS PowerTools Official  x86_64 3771
> >>>
> >>> That's a pretty big difference.  Now, I don't know how many were dropped
> >>> completely and how many are of the "buildroot only" variety.  But I 
> >>> suspect
> >>> there is a fair amount of the latter and so a lot of make-work ahead of 
> >>> us for
> >>> EPEL9.
> >
> > A fairly accurate list of packages removed in RHEL 9 can be found in
> > our RHEL 9 Adoption documentation:
> >
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages
>
> Thanks for that.
>
> >>> Packaging for EPEL9 is starting to feel more and more like cleaning the 
> >>> Augean
> >>> stables with RedHat piling up more manure.
> >>
> >> If there is any Python stuff that's in Buildroot only, let me know and 
> >> I'll do
> >> my best to persuade the maintainers to move it to CRB (but my powers are 
> >> limited).
> >
> > I will politely point out two things.
> >
> > 1) The entirety of the RHEL buildroot is available in the CentOS
> > Stream koji buildroots.  I know the EPEL stewards have qualms about
> > using it, but they are there and the technical hurdles to consume them
> > are not large.
>
> Well, we are making use of it via epel-next.  But it's the "Stream"
> buildroot.  Once that diverges from the current released RHEL there
> could be issues with trying to do updated builds for the current release
> of RHEL.

"...could be issues...".  Yes, I agree it is possible to have issues.
I do not believe the number that may be found is large enough to
cripple EPEL or cause the community to have to request dozens of
-devel packages be added to product repos just to build things.  It is
my hope that EPEL-next proves this out and EPEL proper can benefit
from it in a similar manner.  I can appreciate the caution the EPEL
community is taking.

> > 2) Moving content to CRB in RHEL is not a silver bullet solution in
> > many scenarios.  If it's strictly for build dependencies, CRB works
> > well.  If an EPEL package has a runtime requires on CRB content, that
> > is less desirable.  RHEL CodeReady Linux Builder (CRB) content is
> > unsupported, not enabled by default, and not intended to be used at
> > runtime in production.  EPEL itself is clearly in the same unsupported
> > category, but requiring another unsupported repo at runtime may lead
> > to unintentional surprises for many users.
> >
> > josh
>
> I don't buy any of these arguments, and it doesn't really address the
> situation of "missing -devel" packages.  E.g. utf8proc - it's in

I'm sorry, I did not mean to intend an argumentative tone.  What I
wrote is a factual statement from a product perspective, based on
feedback we've heard directly from some customers.  It's ok for you to
not share the same view, of course.  Feedback from some of our other
customers highlights they don't share it either.

> "AppStream" - so it's presumably "supported" and "intended to be used at
> runtime in production".  But without the -devel package available we
> can't build anything in EPEL that uses it.  So we have to go through
> contortions to make sure we build the proper version of utf8proc-devel
> and keep it in sync with RHEL.

This is difficult to describe, both in approach and in actual customer
facing documentation, even though we try.  Content in RHEL is
generally supported, but the scope of that support can differ based on
a number of factors.  There is the largest class of content supported
for general use with a full 10 year lifecycle and ABI stability
guarantees.  However, there are also classes of content that are
supported for less than the full life of the RHEL release (Application
Streams, not to be conflated with the AppStream repo).  Finally, there
are classes of content supported as internal to RHEL dependencies not
intended for wider use.  The latter is a smaller set, and we continue
to evaluate the overall content set based on customer and user
feedback.

> Is the trade off of perhaps a few less RHEL

[EPEL-devel] Re: The incredibly shrinking RHEL

2022-01-15 Thread Orion Poplawski 

On 1/15/22 12:22, Andrew C Aitchison wrote:

On Sat, 15 Jan 2022, Miro Hrončok wrote:

python-pytest-cov is something I've lobbied has no business in an 
enterprise distro at all.

 ...    ...
As for EPEL I strongly suggest not to introduce python-pytest-cov 
either. If your package depends on it, please drop the dependency 
instead, see 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters 



    In %check, packages SHOULD NOT run “linters”: code style checkers, test
    coverage checkers and other tools that check code quality rather than
    functionality.
Agreed.

    Linters do make sense in upstream CI. But not in Fedora.
Not inside Fedora *packages*, but
if these tools are not available to those using RHEL, Fedora or EPEL
is that a suitable platform for CI or for developers ?



No, but that's why it will be provided in EPEL :)

--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic Signature
___
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: The incredibly shrinking RHEL

2022-01-15 Thread Orion Poplawski 

On 1/14/22 10:33, Troy Dawson wrote:



On Fri, Jan 14, 2022 at 8:13 AM Stephen John Smoogen > wrote:




On Fri, 14 Jan 2022 at 10:57, Stephen John Smoogen mailto:smo...@gmail.com>> wrote:



I mirrored the source rpms down and did the following for 8 and
9-stream.
```
$ for i in AppStream BaseOS PowerTools; do echo $i; find ./$i
-type f -name "*src.rpm" | xargs rpm --nosignature
--qf='%{NAME}\n' -qp > /tmp/a-$i; sort -o /tmp/a-$i -u
/tmp/a-$i; done
$ sort -o /tmp/a -u /tmp/a-* ; sort -o /tmp/b -u /tmp/b-*
$ wc -l /tmp/a* /tmp/b*
   2652 /tmp/a
   1740 /tmp/a-AppStream
    536 /tmp/a-BaseOS
    503 /tmp/a-PowerTools
   2273 /tmp/b
   1620 /tmp/b-AppStream
    399 /tmp/b-BaseOS
    295 /tmp/b-CRB
$ comm -1 -2 /tmp/a /tmp/b | wc -l
2090
$ comm -1 -3 /tmp/a /tmp/b | wc -l
183
$ comm -2 -3 /tmp/a /tmp/b | wc -l
562
```
So 183 packages were added to 9 that weren't in 8 and 562
packages were 'removed'. Some of those are obsolete packages like

python2, python36,python38, gcc-toolset-9, gcc-toolset-10,
autoconf213. Others are module things which aren't shipped already. 



The following statement was wrong. Some subset of that 500 may be
built and could go into CRB, but that would require mirroring the
CentOS Stream koji which I didn't do.

That leaves about 500 source packages which aren't even built
internally so aren't going into CRB.


I was gathering each of the names of the binary and source packages 
directly from the repos for my "Will It Build", so I did a few tweaks 
and  got these numbers.  I feel they are quite accurate.


CentOS Stream 8:
AppStream: 4553
BaseOS: 1715
CRB: 1614
Total Source RPMS: 2260

CentOS Stream 9:
AppStream: 5225
BaseOS: 1130
CRB: 1370
Total Source RPMS: 2252

So, there is a drop of 250 packages in CRB from RHEL8 to RHEL9.  But 
beyond that, things are quite close.


Troy


First off, I apologize for:

- injecting bad data into this discussion
- making assumptions about packages being in the RHEL9 buildroot that 
were not true

- using a subject that didn't really reflect what my real concern was

So, I really don't care if RHEL overall is shrinking or not.  My concern 
was over the possible increase in 'buildroot-only' packages - which 
seems may not be any worse than it is with RHEL8 (although that's 
annoying enough - more on that in another response).


Thanks Troy and Smooge for your data.  But I guess what I would be 
really interested in finding out (if possible) is the number of 
buildroot-only packages in the two distros.


I've done some poking, and this is what I've come up with for *new* 
missing -devel packages in CS9 with their approximate number of users in 
rawhide:


389-ds-base-devel 2
accel-config-devel 0
anthy-unicode-devel 3
atlas-corei2-devel 0
avahi-glib-devel 1
avahi-gobject-devel 4
avahi-ui-devel 1
bind-devel 3
blis-devel 2
Box2D-devel 1
cjose-devel 1
clutter-devel 9
clutter-gst3-devel 1
clutter-gtk-devel 8
cogl-devel 0
compat-lua-devel 26
cppunit-devel 35
double-conversion-devel 9
dpdk-devel 1
emacs-devel 1
evince-devel 3
fdk-aac-free-devel 4
flashrom-devel 1
flexiblas-devel 33
freeglut-devel 68
fstrm-devel 4
glusterfs-api-devel 8
glusterfs-devel 2
gnome-calculator-devel 0
gnome-menus-devel 1
gnome-software-devel 0
gsl-devel 51
gtk4-devel-tools 0
gtksourceview4-devel 6
hexchat-devel 1
hidapi-devel 11
ibus-anthy-devel 0
ibus-table-devel 7
inih-devel 3
iscsi-initiator-utils-devel 1
isns-utils-devel 1
kernel-rt-debug-devel-matched 0
kernel-rt-devel-matched 0
ldns-devel 8
libass-devel 1
libblockdev-crypto-devel 1
libblockdev-devel 1
libblockdev-fs-devel 1
libblockdev-loop-devel 1
libblockdev-lvm-devel 1
libblockdev-mdraid-devel 1
libblockdev-part-devel 1
libblockdev-swap-devel 2
libblockdev-utils-devel 0
libbytesize-devel 5
libcbor-devel 0
libcephfs-devel 2
libcephsqlite-devel 0
libdazzle-devel 1
libeconf-devel 1
libell-devel 3
libepubgen-devel 0
libev-devel 22
libev-libevent-devel 0
libfido2-devel 2
libfl-devel 3
libfoma-devel 0
libhandy-devel 2
libldac-devel 0
libmng-devel 12
libmpeg2-devel 2
libmtp-devel 7
libotr-devel 8
libqrtr-glib-devel 2
libradosstriper-devel 1
libshaderc-devel 1
libslirp-devel 3
libsmartcols-devel 1
libsmi-devel 1
libstoragemgmt-devel 1
libtpms-devel 1
liburing-devel 6
libverto-libev-devel 0
libwpe-devel 0
libXpresent-devel 2
libzip-devel 16
lldpd-devel 0
lpsolve-devel 1
luajit-devel 11
make-devel 5
mecab-devel 7
mesa-vulkan-devel 2
minizip-compat-devel 6
mptcpd-devel 0
nmstate-devel 0
nodejs-devel 19
ocaml-camomile-devel 5
ocaml-csexp-devel 3
ocaml-dune-devel 17
physfs-devel 17
postgresql-upgrade-devel 1
pybind11-devel 19
qgpgme-devel 3
rados-objclass-devel 0
rapidjson-devel 18
sid-base-libs-devel 0
sid-iface-libs-devel 0
sid-log-libs-devel 0

[EPEL-devel] Re: The incredibly shrinking RHEL

2022-01-15 Thread Gary Buhrmaster 
On Sat, Jan 15, 2022 at 6:29 PM Orion Poplawski  wrote:

> I don't buy any of these arguments, and it doesn't really address the
> situation of "missing -devel" packages.

The missing devel packages for shipped libraries
are a clear pain point for those that just want build
something for their EL system(s), and not go through
something like mock to do it (or create/build/maintain
their own -epel package).

This is not a new issue, though.  A number of
missing devel packages were identified with
EL8, with the statement that the long term
would be to open tickets requesting the devel
packages be added to CRB.  As I recall, some
were, and some were not.  I would have
preferred the EL8 experience was taken to heart
for EL9, and if it was felt necessary to ship the
base library, the devel package would have
been in CRB by default just to avoid a repeat
of the pain point.  To be fair, I have seen some
devel packages for EL9 libraries (after a bugzilla
ticket) being added to the stream 9 CRB repo,
so the RH teams are being responsive, even
as I am sure there are internal processes to
work through.
___
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: The incredibly shrinking RHEL

2022-01-15 Thread Andrew C Aitchison 

On Sat, 15 Jan 2022, Miro Hrončok wrote:

python-pytest-cov is something I've lobbied has no business in an enterprise 
distro at all.

... ...
As for EPEL I strongly suggest not to introduce python-pytest-cov either. If 
your package depends on it, please drop the dependency instead, see 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters


   In %check, packages SHOULD NOT run “linters”: code style checkers, test
   coverage checkers and other tools that check code quality rather than
   functionality.
Agreed.

   Linters do make sense in upstream CI. But not in Fedora.
Not inside Fedora *packages*, but
if these tools are not available to those using RHEL, Fedora or EPEL
is that a suitable platform for CI or for developers ?

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk___
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: The incredibly shrinking RHEL

2022-01-15 Thread Orion Poplawski 

On 1/14/22 05:02, Josh Boyer wrote:

On Fri, Jan 14, 2022 at 5:31 AM Miro Hrončok  wrote:


On 14. 01. 22 5:11, Orion Poplawski wrote:

While working on EPEL9, it seems that even more packages are missing from RHEL9
than were in RHEL8.  The latest I found was cppunit, which appears to be
completely missing from the CS9 repos despite having been built (See
https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and
presumably in the CS9/RHEL9 buildroot.

So I scraped some screens from pkgs.org:

Stream 9:

CentOS AppStream Official   x86_64 8882
CentOS BaseOS Official  x86_64 2357
CentOS CRB Official x86_64 1856

Stream 8:

CentOS AppStream Official   x86_64 15008
CentOS BaseOS Official  x86_64 6721
CentOS PowerTools Official  x86_64 3771

That's a pretty big difference.  Now, I don't know how many were dropped
completely and how many are of the "buildroot only" variety.  But I suspect
there is a fair amount of the latter and so a lot of make-work ahead of us for
EPEL9.


A fairly accurate list of packages removed in RHEL 9 can be found in
our RHEL 9 Adoption documentation:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages


Thanks for that.


Packaging for EPEL9 is starting to feel more and more like cleaning the Augean
stables with RedHat piling up more manure.


If there is any Python stuff that's in Buildroot only, let me know and I'll do
my best to persuade the maintainers to move it to CRB (but my powers are 
limited).


I will politely point out two things.

1) The entirety of the RHEL buildroot is available in the CentOS
Stream koji buildroots.  I know the EPEL stewards have qualms about
using it, but they are there and the technical hurdles to consume them
are not large.


Well, we are making use of it via epel-next.  But it's the "Stream" 
buildroot.  Once that diverges from the current released RHEL there 
could be issues with trying to do updated builds for the current release 
of RHEL.



2) Moving content to CRB in RHEL is not a silver bullet solution in
many scenarios.  If it's strictly for build dependencies, CRB works
well.  If an EPEL package has a runtime requires on CRB content, that
is less desirable.  RHEL CodeReady Linux Builder (CRB) content is
unsupported, not enabled by default, and not intended to be used at
runtime in production.  EPEL itself is clearly in the same unsupported
category, but requiring another unsupported repo at runtime may lead
to unintentional surprises for many users.

josh


I don't buy any of these arguments, and it doesn't really address the 
situation of "missing -devel" packages.  E.g. utf8proc - it's in 
"AppStream" - so it's presumably "supported" and "intended to be used at 
runtime in production".  But without the -devel package available we 
can't build anything in EPEL that uses it.  So we have to go through 
contortions to make sure we build the proper version of utf8proc-devel 
and keep it in sync with RHEL.


Is the trade off of perhaps a few less RHEL support requests about a few 
packages that are clearly important enough to be included directly in 
RHEL really worth the ill-will being generated in the volunteers that 
help support the ecosystem around RHEL?


Perhaps it's unreasonable for me to be as upset about this as I am, but 
largely it's because I just can't understand the motivation behind it 
and it's a deliberate action that directly makes my *volunteer* work 
harder.  I have put in thousands of hours of work on Fedora/EPEL over 
16+ years - and generally it has just gotten better.  Better tools, 
better infrastructure, etc.  This is the first time I can remember 
having something change that makes the work harder - so maybe it's just 
the shock of that.  Feels like a betrayal of those 16 years of working 
together towards what seemed like a common goal.


Oh, and for cppunit just putting it in CRB should be just fine as it 
generally does not produce runtime deps.


--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic Signature
___
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: The incredibly shrinking RHEL

2022-01-15 Thread Orion Poplawski 

On 1/14/22 19:45, epel-devel@lists.fedoraproject.org wrote:

On 1/14/22 03:29, Miro Hrončok wrote:

On 14. 01. 22 5:11, Orion Poplawski wrote:
While working on EPEL9, it seems that even more packages are missing 
from RHEL9 than were in RHEL8.  The latest I found was cppunit, which 
appears to be completely missing from the CS9 repos despite having 
been built (See 
https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) 
and presumably in the CS9/RHEL9 buildroot.


So I scraped some screens from pkgs.org:

Stream 9:

CentOS AppStream Official   x86_64 8882
CentOS BaseOS Official  x86_64 2357
CentOS CRB Official x86_64 1856

Stream 8:

CentOS AppStream Official   x86_64 15008
CentOS BaseOS Official  x86_64 6721
CentOS PowerTools Official  x86_64 3771

That's a pretty big difference.  Now, I don't know how many were 
dropped completely and how many are of the "buildroot only" variety. 
But I suspect there is a fair amount of the latter and so a lot of 
make-work ahead of us for EPEL9.


Packaging for EPEL9 is starting to feel more and more like cleaning 
the Augean stables with RedHat piling up more manure.


If there is any Python stuff that's in Buildroot only, let me know and 
I'll do my best to persuade the maintainers to move it to CRB (but my 
powers are limited).




Others:

python-pytest-cov ->
   python-pyttest-xdist ->
     python-execnet ->
   python-gevent ->
     python-zope-interface ->
   python-zope-testing
   python-apipkg

https://bugzilla.redhat.com/buglist.cgi?bug_id=2032588_id_type=anddependson=tvp_id=12369805# 


So it turns out that this came from a misunderstanding of how things 
work in CS9.  I saw the builds in koji and assumed that they were then 
available.  But apparently they have been retired:


https://gitlab.com/redhat/centos-stream/rpms/python-pytest-cov

I was also confused about two things here:

- It's retired on the "main" branch, but the c9s branch seems intact.
- What does "retired for CS-569" mean?

So, apologies for jumping to conclusions.  I'm afraid I'm still pretty 
upset about the whole "missing -devel" package thing.



--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic Signature
___
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: The incredibly shrinking RHEL

2022-01-15 Thread Miro Hrončok 

On 15. 01. 22 11:19, Miro Hrončok wrote:
As for EPEL I strongly suggest not to introduce python-pytest-cov either. If 
your package depends on it, please drop the dependency instead, see 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters


And this goes without saying: If you have package and need help doing it 
because it's not trivial, let me know and I'll try to help.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: The incredibly shrinking RHEL

2022-01-15 Thread Miro Hrončok 

On 15. 01. 22 3:45, Orion Poplawski wrote:

Others:

python-pytest-cov ->
   python-pyttest-xdist ->
     python-execnet ->
   python-gevent ->
     python-zope-interface ->
   python-zope-testing
   python-apipkg

https://bugzilla.redhat.com/buglist.cgi?bug_id=2032588_id_type=anddependson=tvp_id=12369805# 



Thanks.


python-pytest-cov is something I've lobbied has no business in an enterprise 
distro at all. And it was removed. It is not in the Buildroot repo. What you 
see is a retired package:


https://gitlab.com/redhat/centos-stream/rpms/python-pytest-cov/-/commit/a27e0d8b463e23ad7f9827e4bd61c8528114bf5f

How do you recognize a package is "in the buildroot"? If you just search on 
kojihub.stream.centos.org your results are not accurate. As in Fedora, it 
includes retired packages.


As for EPEL I strongly suggest not to introduce python-pytest-cov either. If 
your package depends on it, please drop the dependency instead, see 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters



Recently I came across the python-zope-* packages, e.g.:

https://bugzilla.redhat.com/show_bug.cgi?id=2038512


Same story:

https://gitlab.com/redhat/centos-stream/rpms/python-zope-testing/-/commit/18bf2416bdaf7f9b8746d56e4a6a4184e3ee0ac1

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: The incredibly shrinking RHEL

2022-01-14 Thread Orion Poplawski 

On 1/14/22 05:36, Neal Gompa wrote:

On Fri, Jan 14, 2022 at 7:27 AM Leon Fauster via epel-devel
 wrote:


Am 14.01.22 um 13:02 schrieb Josh Boyer:

A fairly accurate list of packages removed in RHEL 9 can be found in
our RHEL 9 Adoption documentation:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages



It seems that RH does not see RHEL as workstation OS anymore.
Many tools were/will be removed. I do not need to be bright to
anticipate that in the future (e.g. RHEL11) the trouble will
prevails the benefit. EPEL QA is better then ever but it will
not fill the gap. Thats like swimming agains the stream. Unless
RH incorporates EPEL into his strategies. Like keeping the volume
of packages officially and just shifting the borders ... thought.



I think that's an unfair characterization. While it's certainly true
that RHEL focuses on server workloads (it's easily an order of
magnitude more sales than workstation ones), it's also true that Red
Hat is *finally* investing in EPEL. This is the *first* RHEL release
where Red Hat is *directly* investing in helping the community bring
up EPEL. The RHEL folks are giving us a path to request packages as
needed from being buildroot-only (thus internal to non-public RHEL
Koji) to published repositories (thus usable by EPEL and
third-parties).

I *personally* have done this now many times with great success, and
the consequence of that is we're able to get content into EPEL faster
than ever before. We're even going to be ready for the RHEL 9.0 GA,
which is something we've never had before.


I seem to have missed how to do this, could you point me to the right 
process?


Thanks!

--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic Signature
___
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: The incredibly shrinking RHEL

2022-01-14 Thread Orion Poplawski 

On 1/14/22 03:29, Miro Hrončok wrote:

On 14. 01. 22 5:11, Orion Poplawski wrote:
While working on EPEL9, it seems that even more packages are missing 
from RHEL9 than were in RHEL8.  The latest I found was cppunit, which 
appears to be completely missing from the CS9 repos despite having 
been built (See 
https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and 
presumably in the CS9/RHEL9 buildroot.


So I scraped some screens from pkgs.org:

Stream 9:

CentOS AppStream Official   x86_64 8882
CentOS BaseOS Official  x86_64 2357
CentOS CRB Official x86_64 1856

Stream 8:

CentOS AppStream Official   x86_64 15008
CentOS BaseOS Official  x86_64 6721
CentOS PowerTools Official  x86_64 3771

That's a pretty big difference.  Now, I don't know how many were 
dropped completely and how many are of the "buildroot only" variety.  
But I suspect there is a fair amount of the latter and so a lot of 
make-work ahead of us for EPEL9.


Packaging for EPEL9 is starting to feel more and more like cleaning 
the Augean stables with RedHat piling up more manure.


If there is any Python stuff that's in Buildroot only, let me know and 
I'll do my best to persuade the maintainers to move it to CRB (but my 
powers are limited).




Others:

python-pytest-cov ->
  python-pyttest-xdist ->
python-execnet ->
  python-gevent ->
python-zope-interface ->
  python-zope-testing
  python-apipkg

https://bugzilla.redhat.com/buglist.cgi?bug_id=2032588_id_type=anddependson=tvp_id=12369805#

Thanks.

--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic Signature
___
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: The incredibly shrinking RHEL

2022-01-14 Thread Orion Poplawski 

On 1/14/22 03:29, Miro Hrončok wrote:

On 14. 01. 22 5:11, Orion Poplawski wrote:
While working on EPEL9, it seems that even more packages are missing 
from RHEL9 than were in RHEL8.  The latest I found was cppunit, which 
appears to be completely missing from the CS9 repos despite having 
been built (See 
https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and 
presumably in the CS9/RHEL9 buildroot.


So I scraped some screens from pkgs.org:

Stream 9:

CentOS AppStream Official   x86_64 8882
CentOS BaseOS Official  x86_64 2357
CentOS CRB Official x86_64 1856

Stream 8:

CentOS AppStream Official   x86_64 15008
CentOS BaseOS Official  x86_64 6721
CentOS PowerTools Official  x86_64 3771

That's a pretty big difference.  Now, I don't know how many were 
dropped completely and how many are of the "buildroot only" variety.  
But I suspect there is a fair amount of the latter and so a lot of 
make-work ahead of us for EPEL9.


Packaging for EPEL9 is starting to feel more and more like cleaning 
the Augean stables with RedHat piling up more manure.


If there is any Python stuff that's in Buildroot only, let me know and 
I'll do my best to persuade the maintainers to move it to CRB (but my 
powers are limited).




Recently I came across the python-zope-* packages, e.g.:

https://bugzilla.redhat.com/show_bug.cgi?id=2038512

--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic Signature
___
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: The incredibly shrinking RHEL

2022-01-14 Thread Troy Dawson 
On Fri, Jan 14, 2022 at 8:13 AM Stephen John Smoogen 
wrote:

>
>
> On Fri, 14 Jan 2022 at 10:57, Stephen John Smoogen 
> wrote:
>
>>
>>
>> I mirrored the source rpms down and did the following for 8 and 9-stream.
>> ```
>> $ for i in AppStream BaseOS PowerTools; do echo $i; find ./$i -type f
>> -name "*src.rpm" | xargs rpm --nosignature --qf='%{NAME}\n' -qp >
>> /tmp/a-$i; sort -o /tmp/a-$i -u /tmp/a-$i; done
>> $ sort -o /tmp/a -u /tmp/a-* ; sort -o /tmp/b -u /tmp/b-*
>> $ wc -l /tmp/a* /tmp/b*
>>   2652 /tmp/a
>>   1740 /tmp/a-AppStream
>>536 /tmp/a-BaseOS
>>503 /tmp/a-PowerTools
>>   2273 /tmp/b
>>   1620 /tmp/b-AppStream
>>399 /tmp/b-BaseOS
>>295 /tmp/b-CRB
>> $ comm -1 -2 /tmp/a /tmp/b | wc -l
>> 2090
>> $ comm -1 -3 /tmp/a /tmp/b | wc -l
>> 183
>> $ comm -2 -3 /tmp/a /tmp/b | wc -l
>> 562
>> ```
>> So 183 packages were added to 9 that weren't in 8 and 562 packages were
>> 'removed'. Some of those are obsolete packages like
>>
> python2, python36,python38, gcc-toolset-9, gcc-toolset-10, autoconf213.
>> Others are module things which aren't shipped already.
>>
>
> The following statement was wrong. Some subset of that 500 may be built
> and could go into CRB, but that would require mirroring the CentOS Stream
> koji which I didn't do.
>
>
>> That leaves about 500 source packages which aren't even built internally
>> so aren't going into CRB.
>>
>
I was gathering each of the names of the binary and source packages
directly from the repos for my "Will It Build", so I did a few tweaks and
got these numbers.  I feel they are quite accurate.

CentOS Stream 8:
AppStream: 4553
BaseOS: 1715
CRB: 1614
Total Source RPMS: 2260

CentOS Stream 9:
AppStream: 5225
BaseOS: 1130
CRB: 1370
Total Source RPMS: 2252

So, there is a drop of 250 packages in CRB from RHEL8 to RHEL9.  But beyond
that, things are quite close.

Troy
___
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: The incredibly shrinking RHEL

2022-01-14 Thread Stephen John Smoogen 
On Fri, 14 Jan 2022 at 10:57, Stephen John Smoogen  wrote:

>
>
> I mirrored the source rpms down and did the following for 8 and 9-stream.
> ```
> $ for i in AppStream BaseOS PowerTools; do echo $i; find ./$i -type f
> -name "*src.rpm" | xargs rpm --nosignature --qf='%{NAME}\n' -qp >
> /tmp/a-$i; sort -o /tmp/a-$i -u /tmp/a-$i; done
> $ sort -o /tmp/a -u /tmp/a-* ; sort -o /tmp/b -u /tmp/b-*
> $ wc -l /tmp/a* /tmp/b*
>   2652 /tmp/a
>   1740 /tmp/a-AppStream
>536 /tmp/a-BaseOS
>503 /tmp/a-PowerTools
>   2273 /tmp/b
>   1620 /tmp/b-AppStream
>399 /tmp/b-BaseOS
>295 /tmp/b-CRB
> $ comm -1 -2 /tmp/a /tmp/b | wc -l
> 2090
> $ comm -1 -3 /tmp/a /tmp/b | wc -l
> 183
> $ comm -2 -3 /tmp/a /tmp/b | wc -l
> 562
> ```
> So 183 packages were added to 9 that weren't in 8 and 562 packages were
> 'removed'. Some of those are obsolete packages like
>
python2, python36,python38, gcc-toolset-9, gcc-toolset-10, autoconf213.
> Others are module things which aren't shipped already.
>

The following statement was wrong. Some subset of that 500 may be built and
could go into CRB, but that would require mirroring the CentOS Stream koji
which I didn't do.


> That leaves about 500 source packages which aren't even built internally
> so aren't going into CRB.
>
>
>
>
>
> --
> Stephen J Smoogen.
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
>


-- 
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: The incredibly shrinking RHEL

2022-01-14 Thread Stephen John Smoogen 
On Fri, 14 Jan 2022 at 10:22, Troy Dawson  wrote:

>
>
> On Thu, Jan 13, 2022 at 8:12 PM Orion Poplawski  wrote:
>
>> While working on EPEL9, it seems that even more packages are missing
>> from RHEL9 than were in RHEL8.  The latest I found was cppunit, which
>> appears to be completely missing from the CS9 repos despite having been
>> built (See
>> https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and
>> presumably in the CS9/RHEL9 buildroot.
>>
>> So I scraped some screens from pkgs.org:
>>
>> Stream 9:
>>
>> CentOS AppStream Official   x86_64 8882
>> CentOS BaseOS Official  x86_64 2357
>> CentOS CRB Official x86_64 1856
>>
>> Stream 8:
>>
>> CentOS AppStream Official   x86_64 15008
>> CentOS BaseOS Official  x86_64 6721
>> CentOS PowerTools Official  x86_64 3771
>>
>>
> Sorry, but those numbers are wrong for a comparison.
> There are not 15,000 unique packages in AppStream, not even close.
> What I believe you, or they, are counting is the total number of packages
> released.
> So, if the kernel has been released 15 times since Stream 8 started, then
> it's counted as 15.
> Because of that, it's natural for the numbers to be bigger, because Stream
> 8 has been out longer.
>
> If you want the numbers, I can get them.
> Last time I checked, RHEL9 was very close to the same number of packages
> as RHEL8.
> It was more, but very close to the same number.
>
>
I mirrored the source rpms down and did the following for 8 and 9-stream.
```
$ for i in AppStream BaseOS PowerTools; do echo $i; find ./$i -type f -name
"*src.rpm" | xargs rpm --nosignature --qf='%{NAME}\n' -qp > /tmp/a-$i; sort
-o /tmp/a-$i -u /tmp/a-$i; done
$ sort -o /tmp/a -u /tmp/a-* ; sort -o /tmp/b -u /tmp/b-*
$ wc -l /tmp/a* /tmp/b*
  2652 /tmp/a
  1740 /tmp/a-AppStream
   536 /tmp/a-BaseOS
   503 /tmp/a-PowerTools
  2273 /tmp/b
  1620 /tmp/b-AppStream
   399 /tmp/b-BaseOS
   295 /tmp/b-CRB
$ comm -1 -2 /tmp/a /tmp/b | wc -l
2090
$ comm -1 -3 /tmp/a /tmp/b | wc -l
183
$ comm -2 -3 /tmp/a /tmp/b | wc -l
562
```
So 183 packages were added to 9 that weren't in 8 and 562 packages were
'removed'. Some of those are obsolete packages like
python2, python36,python38, gcc-toolset-9, gcc-toolset-10, autoconf213.
Others are module things which aren't shipped already. That leaves about
500 source packages which aren't even built internally so aren't going into
CRB.





-- 
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: The incredibly shrinking RHEL

2022-01-14 Thread Troy Dawson 
On Thu, Jan 13, 2022 at 8:12 PM Orion Poplawski  wrote:

> While working on EPEL9, it seems that even more packages are missing
> from RHEL9 than were in RHEL8.  The latest I found was cppunit, which
> appears to be completely missing from the CS9 repos despite having been
> built (See
> https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and
> presumably in the CS9/RHEL9 buildroot.
>
> So I scraped some screens from pkgs.org:
>
> Stream 9:
>
> CentOS AppStream Official   x86_64 8882
> CentOS BaseOS Official  x86_64 2357
> CentOS CRB Official x86_64 1856
>
> Stream 8:
>
> CentOS AppStream Official   x86_64 15008
> CentOS BaseOS Official  x86_64 6721
> CentOS PowerTools Official  x86_64 3771
>
>
Sorry, but those numbers are wrong for a comparison.
There are not 15,000 unique packages in AppStream, not even close.
What I believe you, or they, are counting is the total number of packages
released.
So, if the kernel has been released 15 times since Stream 8 started, then
it's counted as 15.
Because of that, it's natural for the numbers to be bigger, because Stream
8 has been out longer.

If you want the numbers, I can get them.
Last time I checked, RHEL9 was very close to the same number of packages as
RHEL8.
It was more, but very close to the same number.

Troy
___
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: The incredibly shrinking RHEL

2022-01-14 Thread Neal Gompa 
On Fri, Jan 14, 2022 at 7:27 AM Leon Fauster via epel-devel
 wrote:
>
> Am 14.01.22 um 13:02 schrieb Josh Boyer:
> > A fairly accurate list of packages removed in RHEL 9 can be found in
> > our RHEL 9 Adoption documentation:
> >
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages
>
>
> It seems that RH does not see RHEL as workstation OS anymore.
> Many tools were/will be removed. I do not need to be bright to
> anticipate that in the future (e.g. RHEL11) the trouble will
> prevails the benefit. EPEL QA is better then ever but it will
> not fill the gap. Thats like swimming agains the stream. Unless
> RH incorporates EPEL into his strategies. Like keeping the volume
> of packages officially and just shifting the borders ... thought.
>

I think that's an unfair characterization. While it's certainly true
that RHEL focuses on server workloads (it's easily an order of
magnitude more sales than workstation ones), it's also true that Red
Hat is *finally* investing in EPEL. This is the *first* RHEL release
where Red Hat is *directly* investing in helping the community bring
up EPEL. The RHEL folks are giving us a path to request packages as
needed from being buildroot-only (thus internal to non-public RHEL
Koji) to published repositories (thus usable by EPEL and
third-parties).

I *personally* have done this now many times with great success, and
the consequence of that is we're able to get content into EPEL faster
than ever before. We're even going to be ready for the RHEL 9.0 GA,
which is something we've never had before.

If you want Red Hat to care more about workstation workloads, then buy
Red Hat Enterprise Linux Workstation[1]. It's not that expensive and
you get support from Red Hat if you pay for standard support. As a
good friend recently said: "Red Hat is coin-operated". Give them
coins, and magic will happen. :)

And for what it's worth, I think Red Hat Enterprise Linux 9 is shaping
up to be a fantastic workstation. It may not be as good as Fedora
Linux at it, but it's head and shoulders better than all the rest.

Can RHEL do better? Absolutely! But let's give credit where it's due:
this is substantially better than three years ago with RHEL 8.

[1]: https://www.redhat.com/en/store/red-hat-enterprise-linux-workstation




--
真実はいつも一つ！/ 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: The incredibly shrinking RHEL

2022-01-14 Thread Leon Fauster via epel-devel 

Am 14.01.22 um 13:02 schrieb Josh Boyer:

A fairly accurate list of packages removed in RHEL 9 can be found in
our RHEL 9 Adoption documentation:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages



It seems that RH does not see RHEL as workstation OS anymore.
Many tools were/will be removed. I do not need to be bright to
anticipate that in the future (e.g. RHEL11) the trouble will
prevails the benefit. EPEL QA is better then ever but it will
not fill the gap. Thats like swimming agains the stream. Unless
RH incorporates EPEL into his strategies. Like keeping the volume
of packages officially and just shifting the borders ... thought.

--
Leon


___
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: The incredibly shrinking RHEL

2022-01-14 Thread Josh Boyer 
On Fri, Jan 14, 2022 at 5:31 AM Miro Hrončok  wrote:
>
> On 14. 01. 22 5:11, Orion Poplawski wrote:
> > While working on EPEL9, it seems that even more packages are missing from 
> > RHEL9
> > than were in RHEL8.  The latest I found was cppunit, which appears to be
> > completely missing from the CS9 repos despite having been built (See
> > https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and
> > presumably in the CS9/RHEL9 buildroot.
> >
> > So I scraped some screens from pkgs.org:
> >
> > Stream 9:
> >
> > CentOS AppStream Official   x86_64 8882
> > CentOS BaseOS Official  x86_64 2357
> > CentOS CRB Official x86_64 1856
> >
> > Stream 8:
> >
> > CentOS AppStream Official   x86_64 15008
> > CentOS BaseOS Official  x86_64 6721
> > CentOS PowerTools Official  x86_64 3771
> >
> > That's a pretty big difference.  Now, I don't know how many were dropped
> > completely and how many are of the "buildroot only" variety.  But I suspect
> > there is a fair amount of the latter and so a lot of make-work ahead of us 
> > for
> > EPEL9.

A fairly accurate list of packages removed in RHEL 9 can be found in
our RHEL 9 Adoption documentation:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages

> > Packaging for EPEL9 is starting to feel more and more like cleaning the 
> > Augean
> > stables with RedHat piling up more manure.
>
> If there is any Python stuff that's in Buildroot only, let me know and I'll do
> my best to persuade the maintainers to move it to CRB (but my powers are 
> limited).

I will politely point out two things.

1) The entirety of the RHEL buildroot is available in the CentOS
Stream koji buildroots.  I know the EPEL stewards have qualms about
using it, but they are there and the technical hurdles to consume them
are not large.

2) Moving content to CRB in RHEL is not a silver bullet solution in
many scenarios.  If it's strictly for build dependencies, CRB works
well.  If an EPEL package has a runtime requires on CRB content, that
is less desirable.  RHEL CodeReady Linux Builder (CRB) content is
unsupported, not enabled by default, and not intended to be used at
runtime in production.  EPEL itself is clearly in the same unsupported
category, but requiring another unsupported repo at runtime may lead
to unintentional surprises for many users.

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: The incredibly shrinking RHEL

2022-01-14 Thread Miro Hrončok 

On 14. 01. 22 5:11, Orion Poplawski wrote:
While working on EPEL9, it seems that even more packages are missing from RHEL9 
than were in RHEL8.  The latest I found was cppunit, which appears to be 
completely missing from the CS9 repos despite having been built (See 
https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and 
presumably in the CS9/RHEL9 buildroot.


So I scraped some screens from pkgs.org:

Stream 9:

CentOS AppStream Official   x86_64 8882
CentOS BaseOS Official  x86_64 2357
CentOS CRB Official x86_64 1856

Stream 8:

CentOS AppStream Official   x86_64 15008
CentOS BaseOS Official  x86_64 6721
CentOS PowerTools Official  x86_64 3771

That's a pretty big difference.  Now, I don't know how many were dropped 
completely and how many are of the "buildroot only" variety.  But I suspect 
there is a fair amount of the latter and so a lot of make-work ahead of us for 
EPEL9.


Packaging for EPEL9 is starting to feel more and more like cleaning the Augean 
stables with RedHat piling up more manure.


If there is any Python stuff that's in Buildroot only, let me know and I'll do 
my best to persuade the maintainers to move it to CRB (but my powers are limited).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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