[EPEL-devel] Re: Heads-up: trousers (TPM 1.2) silently orphaned

[Michel Alexandre Salim]

On Sat, Jan 15, 2022 at 11:42:34AM +, Peter Robinson wrote:
> On Sat, Jan 15, 2022 at 4:20 AM Michel Alexandre Salim
>  wrote:
> >
> > On Fri, Dec 17, 2021 at 12:35:59PM -0800, Adam Williamson wrote:
> > >
> > > It does seem to be used by robosignatory (the thing that signs Fedora
> > > packages, I think):
> >
> > Sorry for the late reply! Meant to ask you about this, as I tried and
> > find what requires trousers before my first post and didn't see
> > robosignatory at all.
> 
> I asked Patrick about this last week, it's an old dependency that was
> never cleaned up. On a previous generation of HW they used to use a
> TPM1 to store bits used by robosignatory but it was never a direct
> dependency. That's no longer the case so it can be cleaned up.

Ah, that's good to know! I still intend to maintain trousers for at
least the next couple of years - but the less dependent packages, the
better.

Best regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP 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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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