date:20220115

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Test-LWP-UserAgent-0.0 |perl-Test-LWP-UserAgent-0.0
   |35 is available |36 is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.036
Current version/release in rawhide: 0.034-6.fc35
URL: http://search.cpan.org/dist/Test-LWP-UserAgent/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/6999/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2041002
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

Hi Jakub,

On Fri, Jan 14, 2022 at 03:31:43PM +0100, Jakub Jelinek wrote:
> Hi!
> 
> gcc 12 snapshot has landed as the system compiler into rawhide today.
> GCC 12 is going to enter its stage4 development phase (only regression
> and documentation bugfixes allowed) on Monday 17th, so there should be
> just those bugfixes and not new features etc. anymore.
> https://gcc.gnu.org/gcc-12/changes.html lists important changes,
> most important is probably that vectorization is enabled at -O2 now
> which is the option with most of the distribution is built with.
> 
> https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists
> some cases where people need to adjust their code.  Other things
> include the usual C++ header changes, where previously some standard
> header included some other header as an implementation detail but it doesn't
> any longer and so code that relied on such indirect include that isn't
> required by the standard needs to include the header that provides whatever
> it relies on.  Or e.g. packages using -Werror where new warnings are
> reported with the newer compiler and -Werror results in build failures.

Can this be documented soon?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99032

It hit nextcloud-client:
https://bugzilla.redhat.com/show_bug.cgi?id=2041135 which compiles fine
with GCC 11 for F34 and F35.

> 
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.
> 
I'm going to exercise this with the new Folly stack on Monday once the
weekly tags are created. Will try and report ASAP.

Speaking of which, folly is also affected by this which affected GCC 11,
so I'll update the bug either to confirm it is still broken in 12 or it
has been fixed:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008

Best regards,

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

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

Re: Heads-up: trousers (TPM 1.2) silently orphaned

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/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


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


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




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

Re: Proposal: Make -r (include runtime deps) the default for %pyproject_buildrequires

On Mon, Jan 10, 2022 at 01:55:39PM +0100, Miro Hrončok wrote:
> Hello Pythonistas.
> 
> When we invented the %pyproject_buildrequires BuildRequires generator, it
> generated build-dependencies. Imediatelly we realized that for several
> reasons, also generating the runtime dependencies as BuildRequires is
> needed:
> 
>  - they are needed to run the test suite
>  - they are needed to run an import check
>  - they make the build fail when runtime dependencies are not found
> 
> Hence, %pyproject_buildrequires -r was introduced. This flag is implied by
> other flags (-x, -t, -e) but it is not a default behavior.
> 
Yes please. I find myself having to add it several times, for packages
that don't use Tox.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


signature.asc
Description: PGP signature
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2038286] Please branch and build perl-Search-Xapian for EPEL8 and EPEL9

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

Michel Alexandre Salim  changed:

   What|Removed |Added

  Flags||needinfo?(emmanuel@seyman.f
   ||r)
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Michel Alexandre Salim  ---
Will you be able to branch and build perl-Search-Xapian for epel8 and epel9?
I would be happy to be a co-maintainer if you do not wish
to build it for EPEL (FAS: salimma).


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2038286
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Workflow and other problems with the Fedora container infrastructure

2022-01-15 Thread Kevin Fenzi

On Thu, Jan 13, 2022 at 02:14:19PM -0500, Neal Gompa wrote:
> 
> One of the things that has recently happened in the Koji space is the
> addition of a kiwi-build task to build images using the KIWI tool[1].
> 
> KIWI supports building all kinds of operating system images, including
> OCI containers. The Fedora Cloud WG is poking at the idea of using
> KIWI for the cloud image to replace the unmaintained and brittle
> ImageFactory, and we could also look at doing container builds with
> KIWI to replace the OpenShift Atomic Reactor system. That would
> drastically simplify the architecture and make container image builds
> considerably more reasonable for the Container SIG and any other
> stakeholders.

Yeah, thats quite interesting. I would be happy to move to a pipeline
thats less fragile here. :) 

There's also talk about moving things to use ImageBuilder, but I don't
think it does containers. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2038283] Please branch and build perl-Plack-Middleware-ReverseProxy for EPEL8 and EPEL9

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

Michel Alexandre Salim  changed:

   What|Removed |Added

  Flags||needinfo?(emmanuel@seyman.f
   ||r)



--- Comment #1 from Michel Alexandre Salim  ---
Will you be able to branch and build perl-Plack-Middleware-ReverseProxy in
epel8 and epel9?
I would be happy to be a co-maintainer if you do not wish
to build it on epel9 (FAS salimma).


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2038283
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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


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


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

[Bug 2041077] New: Please build perl-Net-XMPP for EPEL 9

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

Bug ID: 2041077
   Summary: Please build perl-Net-XMPP for EPEL 9
   Product: Fedora EPEL
   Version: epel9
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-Net-XMPP
  Severity: medium
  Assignee: xav...@bachelot.org
  Reporter: redhat-bugzi...@linuxnetz.de
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org,
redhat-bugzi...@linuxnetz.de, xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Description of problem:
Please build perl-Net-XMPP for EPEL 9. It's at least a build-time dependency of
the sendxmpp package.

Version-Release number of selected component (if applicable):
perl-Net-XMPP-1.05-20.fc35

Actual results:
No perl-Net-XMPP in EPEL 9.

Expected results:
perl-Net-XMPP-1.05-20.el9 or better ;-)

Additional info:
Please let me know if you are not interested in maintaining the package on EPEL
9 branch.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2041077
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2041074] Please build perl-Spreadsheet-ParseExcel for EPEL 9

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

Robert Scheck  changed:

   What|Removed |Added

Summary|Please build gnustep-make   |Please build
   |for EPEL 9  |perl-Spreadsheet-ParseExcel
   ||for EPEL 9
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2041074
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2041074] New: Please build gnustep-make for EPEL 9

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

Bug ID: 2041074
   Summary: Please build gnustep-make for EPEL 9
   Product: Fedora EPEL
   Version: epel9
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-Spreadsheet-ParseExcel
  Severity: medium
  Assignee: m...@fale.io
  Reporter: redhat-bugzi...@linuxnetz.de
QA Contact: extras...@fedoraproject.org
CC: jpazdzi...@redhat.com, m...@fale.io,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Description of problem:
Please build perl-Spreadsheet-ParseExcel for EPEL 9. It's at least a build-time
dependency of the perl-Spreadsheet-XLSX package.

Version-Release number of selected component (if applicable):
perl-Spreadsheet-ParseExcel-0.6500-30.fc35

Actual results:
No perl-Spreadsheet-ParseExcel in EPEL 9.

Expected results:
perl-Spreadsheet-ParseExcel-0.6500-30.el9 or better ;-)

Additional info:
Please let me know if you are not interested in maintaining the package on EPEL
9 branch.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2041074
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-15 Thread Ben Beasley

To clarify, this is affecting the 
https://src.fedoraproject.org/rpms/json package and (since it is a 
header-only library) some or all of the many packages that use it.


Here’s the upstream issue: https://github.com/nlohmann/json/issues/3138

It looks like they’re not sure what to do about it yet.

– Ben

On 1/15/22 13:17, Vitaly Zaitsev via devel wrote:

On 14/01/2022 15:31, Jakub Jelinek wrote:

gcc 12 snapshot has landed as the system compiler into rawhide today.


Another regression:

FAILED: test/CMakeFiles/test-regression1.dir/src/unit-regression1.cpp.o
/usr/bin/g++ -DDOCTEST_CONFIG_SUPER_FAST_ASSERTS -DJSON_DIAGNOSTICS=0 
-DJSON_USE_IMPLICIT_CONVERSIONS=1 
-I/builddir/build/BUILD/json-3.10.5/redhat-linux-build/include 
-I/builddir/build/BUILD/json-3.10.5/test/thirdparty/doctest 
-I/builddir/build/BUILD/json-3.10.5/test/thirdparty/fifo_map 
-I/builddir/build/BUILD/json-3.10.5/include -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
-mbranch-protection=standard -fasynchronous-unwind-tables 
-fstack-clash-protection -Wno-deprecated -Wno-float-equal 
-Wno-deprecated-declarations -MD -MT 
test/CMakeFiles/test-regression1.dir/src/unit-regression1.cpp.o -MF 
test/CMakeFiles/test-regression1.dir/src/unit-regression1.cpp.o.d -o 
test/CMakeFiles/test-regression1.dir/src/unit-regression1.cpp.o -c 
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp: In 
function 'void DOCTEST_ANON_FUNC_2()':
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp:392:22: 
error: ambiguous overload for 'operator=' (operand types are 
'std::string' {aka 'std::__cxx11::basic_string'} and 
'nlohmann::basic_json<>::value_type' {aka 'nlohmann::basic_json<>'})

  392 | s2 = o["name"];
  |  ^
In file included from /usr/include/c++/12/string:53,
 from /usr/include/c++/12/bits/locale_classes.h:40,
 from /usr/include/c++/12/locale:39,
 from 
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp:33:
/usr/include/c++/12/bits/basic_string.h:733:21: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::nullptr_t) [with _CharT = char; _Traits = 
std::char_traits; _Alloc = std::allocator; std::nullptr_t 
= std::nullptr_t]' (deleted)

  733 |   basic_string& operator=(nullptr_t) = delete;
  | ^~~~
/usr/include/c++/12/bits/basic_string.h:801:7: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = 
char; _Traits = std::char_traits; _Alloc = std::allocator]'

  801 |   operator=(const basic_string& __str)
  |   ^~~~
/usr/include/c++/12/bits/basic_string.h:842:7: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>&&) [with _CharT = char; _Traits = std::char_traits; 
_Alloc = std::allocator]'

  842 |   operator=(basic_string&& __str)
  |   ^~~~
In file included from 
/builddir/build/BUILD/json-3.10.5/test/thirdparty/doctest/doctest_compatibility.h:6,
 from 
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp:30:
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp: In 
lambda function:
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp:398:37: 
error: ambiguous overload for 'operator=' (operand types are 
'std::string' {aka 'std::__cxx11::basic_string'} and 
'nlohmann::basic_json<>::value_type' {aka 'nlohmann::basic_json<>'})

  398 | CHECK_THROWS_AS(s2 = o["int"], json::type_error);


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/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

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-15 Thread Vitaly Zaitsev via devel


On 14/01/2022 15:31, Jakub Jelinek wrote:

gcc 12 snapshot has landed as the system compiler into rawhide today.


Another regression:

FAILED: test/CMakeFiles/test-regression1.dir/src/unit-regression1.cpp.o
/usr/bin/g++ -DDOCTEST_CONFIG_SUPER_FAST_ASSERTS -DJSON_DIAGNOSTICS=0 
-DJSON_USE_IMPLICIT_CONVERSIONS=1 
-I/builddir/build/BUILD/json-3.10.5/redhat-linux-build/include 
-I/builddir/build/BUILD/json-3.10.5/test/thirdparty/doctest 
-I/builddir/build/BUILD/json-3.10.5/test/thirdparty/fifo_map 
-I/builddir/build/BUILD/json-3.10.5/include -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
-mbranch-protection=standard -fasynchronous-unwind-tables 
-fstack-clash-protection -Wno-deprecated -Wno-float-equal 
-Wno-deprecated-declarations -MD -MT 
test/CMakeFiles/test-regression1.dir/src/unit-regression1.cpp.o -MF 
test/CMakeFiles/test-regression1.dir/src/unit-regression1.cpp.o.d -o 
test/CMakeFiles/test-regression1.dir/src/unit-regression1.cpp.o -c 
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp: In 
function 'void DOCTEST_ANON_FUNC_2()':
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp:392:22: 
error: ambiguous overload for 'operator=' (operand types are 
'std::string' {aka 'std::__cxx11::basic_string'} and 
'nlohmann::basic_json<>::value_type' {aka 'nlohmann::basic_json<>'})

  392 | s2 = o["name"];
  |  ^
In file included from /usr/include/c++/12/string:53,
 from /usr/include/c++/12/bits/locale_classes.h:40,
 from /usr/include/c++/12/locale:39,
 from 
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp:33:
/usr/include/c++/12/bits/basic_string.h:733:21: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::nullptr_t) [with _CharT = char; _Traits = 
std::char_traits; _Alloc = std::allocator; std::nullptr_t = 
std::nullptr_t]' (deleted)

  733 |   basic_string& operator=(nullptr_t) = delete;
  | ^~~~
/usr/include/c++/12/bits/basic_string.h:801:7: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::operator=(const 
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = 
char; _Traits = std::char_traits; _Alloc = std::allocator]'

  801 |   operator=(const basic_string& __str)
  |   ^~~~
/usr/include/c++/12/bits/basic_string.h:842:7: note: candidate: 
'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& 
std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, 
_Alloc>&&) [with _CharT = char; _Traits = std::char_traits; _Alloc 
= std::allocator]'

  842 |   operator=(basic_string&& __str)
  |   ^~~~
In file included from 
/builddir/build/BUILD/json-3.10.5/test/thirdparty/doctest/doctest_compatibility.h:6,
 from 
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp:30:
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp: In 
lambda function:
/builddir/build/BUILD/json-3.10.5/test/src/unit-regression1.cpp:398:37: 
error: ambiguous overload for 'operator=' (operand types are 
'std::string' {aka 'std::__cxx11::basic_string'} and 
'nlohmann::basic_json<>::value_type' {aka 'nlohmann::basic_json<>'})

  398 | CHECK_THROWS_AS(s2 = o["int"], json::type_error);

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/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


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

Re: Review swap

2022-01-15 Thread Sandro Mani


I can take this

Can you take 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2041042 in exchange?


Thanks
Sandro

On 15.01.22 14:25, Mattia Verga via devel wrote:

Is anyone available for a review swap?

I've got https://bugzilla.redhat.com/show_bug.cgi?id=2038675 waiting in
the queue, I can offer a review in return (possibly not rust-* or
golang-* stuff, where I have little or no knowledge about).

Thanks
Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Review swap

2022-01-15 Thread Mattia Verga via devel

Is anyone available for a review swap?

I've got https://bugzilla.redhat.com/show_bug.cgi?id=2038675 waiting in
the queue, I can offer a review in return (possibly not rust-* or
golang-* stuff, where I have little or no knowledge about).

Thanks
Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-15 Thread Ben Beasley

I (and others) encountered this too. It’s reported here[1], with a fix promised 
today.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2040825

On Sat, Jan 15, 2022, at 7:06 AM, Vitaly Zaitsev via devel wrote:
> On 14/01/2022 15:31, Jakub Jelinek wrote:
>> gcc 12 snapshot has landed as the system compiler into rawhide today.
>
> On ppc64le:
>
> gcc -c -std=gnu99 -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mcpu=power8 
> -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection 
> -DNDEBUG -pipe -Iinclude/ -IOpenCL/ -Ideps/LZMA-SDK/C -I/usr/include 
> -I/usr/include/contrib -I/usr/include -DWITH_BRAIN -I/usr/include 
> -DWITH_CUBIN -DWITH_HWMON src/affinity.c -o obj/affinity.NATIVE.o -fpic
> In file included from /usr/include/CL/cl_platform.h:379,
>   from /usr/include/CL/cl.h:21,
>   from include/ext_OpenCL.h:17,
>   from include/types.h:1095,
>   from src/affinity.c:7:
> /usr/lib/gcc/ppc64le-redhat-linux/12/include/altivec.h:58:10: fatal 
> error: rs6000-vecdefines.h: No such file or directory
> 58 | #include "rs6000-vecdefines.h"
>|  ^
> compilation terminated.
> make: *** [src/Makefile:565: obj/affinity.NATIVE.o] Error 1
>
> -- 
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-15 Thread Jakub Jelinek

On Sat, Jan 15, 2022 at 01:06:48PM +0100, Vitaly Zaitsev via devel wrote:
> On 14/01/2022 15:31, Jakub Jelinek wrote:
> > gcc 12 snapshot has landed as the system compiler into rawhide today.
> 
> On ppc64le:
> 
> gcc -c -std=gnu99 -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mcpu=power8
> -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -DNDEBUG
> -pipe -Iinclude/ -IOpenCL/ -Ideps/LZMA-SDK/C -I/usr/include
> -I/usr/include/contrib -I/usr/include -DWITH_BRAIN -I/usr/include
> -DWITH_CUBIN -DWITH_HWMON src/affinity.c -o obj/affinity.NATIVE.o -fpic
> In file included from /usr/include/CL/cl_platform.h:379,
>  from /usr/include/CL/cl.h:21,
>  from include/ext_OpenCL.h:17,
>  from include/types.h:1095,
>  from src/affinity.c:7:
> /usr/lib/gcc/ppc64le-redhat-linux/12/include/altivec.h:58:10: fatal error:
> rs6000-vecdefines.h: No such file or directory
>58 | #include "rs6000-vecdefines.h"
>   |  ^
> compilation terminated.
> make: *** [src/Makefile:565: obj/affinity.NATIVE.o] Error 1

That is #2040825 and gcc-12.0.0-0.5.fc36 that should fix it is building in
koji for 12 hours already.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-15 Thread Vitaly Zaitsev via devel


On 14/01/2022 15:31, Jakub Jelinek wrote:

gcc 12 snapshot has landed as the system compiler into rawhide today.


On ppc64le:

gcc -c -std=gnu99 -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -mcpu=power8 
-mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection 
-DNDEBUG -pipe -Iinclude/ -IOpenCL/ -Ideps/LZMA-SDK/C -I/usr/include 
-I/usr/include/contrib -I/usr/include -DWITH_BRAIN -I/usr/include 
-DWITH_CUBIN -DWITH_HWMON src/affinity.c -o obj/affinity.NATIVE.o -fpic

In file included from /usr/include/CL/cl_platform.h:379,
 from /usr/include/CL/cl.h:21,
 from include/ext_OpenCL.h:17,
 from include/types.h:1095,
 from src/affinity.c:7:
/usr/lib/gcc/ppc64le-redhat-linux/12/include/altivec.h:58:10: fatal 
error: rs6000-vecdefines.h: No such file or directory

   58 | #include "rs6000-vecdefines.h"
  |  ^
compilation terminated.
make: *** [src/Makefile:565: obj/affinity.NATIVE.o] Error 1

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Heads-up: trousers (TPM 1.2) silently orphaned

2022-01-15 Thread Peter Robinson

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:
> > On Fri, 2021-12-17 at 10:35 -0800, Michel Alexandre Salim wrote:
> > > On Thu, Dec 16, 2021 at 10:11:53AM -0800, Michel Alexandre Salim wrote:
> > > > Hi all,
> > > >
> > > > `trousers` got silently orphaned around the time an EPEL9 branch for it
> > > > was requested: https://bugzilla.redhat.com/show_bug.cgi?id=2032258
> > > >
> > > > Looks like we're slowly uncoupling ourselves from it, e.g.
> > > >
> > > > - for ARM, uboot-tools no longer pulls in vboot-utils which pulls in
> > > >   trousers: 
> > > > https://lists.fedoraproject.org/archives/list/scm-comm...@lists.fedoraproject.org/message/JAAC32MNLJMMENVJG7QUSKHGZFABLUHX/
> > > >
> > > > - Neal disabled TPM/TSS 1.2 support in strongswan, dropping the trousers
> > > >   dependency, in 
> > > > https://src.fedoraproject.org/rpms/strongswan/pull-request/13
> > > >
> > > > but there are several dependencies still around (strongswan still shows
> > > > up here as the PR just got merged a few hours ago)
> > > >
> > > I've taken this package for now.
> > >
> > > It's probably OK for most of the trousers dependent to drop their
> > > dependencies on it though, the use case I have in mind is rather
> > > specialized.
> >
> > 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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/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


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