[Bug 2048109] Please branch and build perl-IO-Async in epel9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-56a8bcadcb has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-56a8bcadcb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2048109
___
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 2031796] perl-Email-Sender for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-56a8bcadcb has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-56a8bcadcb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031796
___
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 2031798] perl-FCGI-Client for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-56a8bcadcb has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-56a8bcadcb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031798
___
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 2048963] Add perl-Cache-LRU to EPEL9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-62ea3f4c25 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-62ea3f4c25

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2048963
___
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 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML for EPEL-8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-8cd0241486 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-8cd0241486

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2036125
___
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: CVE-2021-4034: why is pkexec still a thing?

[Sam Varshavchik]

Lennart Poettering writes:


On Di, 01.02.22 09:01, Sam Varshavchik (mr...@courier-mta.com) wrote:

> And an isolated process will be capable of rate-limiting itself in this
> situation any better than a sudo process, which could do the same kind of
> rate-limiting itself, exactly how?

"Rate-limiting"? Not sure what "rate-limiting" has to do with any of
this.


Rate limiting is a generic term. It doesn't only mean "how often  
something happens". Anyway:



If priv code runs with extremely low prio, and acquires a shared
resource, that other priv code might wait for that isn't low prio,
then you have a classic prio inversion issue. because the higher prio
code will be slowed down to the level of the low prio process, which
can be used to DoS things.


The relevant part would be "limiting". Something that repeatedly does what's  
described here could be described as a rate-limiting problem, but that's a  
minor issue. More importantly: it seems to me that an isolated daemon which  
acquires the same resource, on behalf of a low-priority, unprivileged  
process, will also end up block a higher-priority unprivileged process from  
getting that resource, in the same manner. Not sure how this would address  
priority inversion.


Perhaps one can say that an isolated process might factor this in, then  
juggle the competing resource requests based on the requesters' priorities.  
But that sounds like a lot of work for me, and more complicated work for a  
privileged process to do. More opportunities for bugs to happen. Bugs in  
privileged processes are bad.


But I want to closely focus on the exact "shared resource" part here, and  
examine the actual requirements. I really don't like discussing things in  
this kind of a general manner. Practical details matter to me. I would like  
to dig into the specific, actual instance here, on its own merits.


Is this shared resource really needed to be used in the manner that makes it  
possible for priority inversion to happen; or can it be used differently,  
somehow, in a way to avoids it. The questions to answer should be a little  
bit more sophisticated than "how to remove an setuid bit from a program,  
this'll fix all the problems".



prio inversion issues are well known and more or less just bugs. But
they become a security issue once unpriv code has control of the prios
of priv code and can bring the system to a standstill hence. Which is
the case here with sudo.

(i.e. the fact that sudo dosn't at least do a simple
setpriority(PRIO_PROCESS, 0, 0); is beyond me...)


Maybe it should, maybe this is a good idea. Maybe it makes sense for a shell  
with elevated privileges to start with a lowered priority by default, and  
root would be able to elevate its privileges if needed. I don't play root  
very often, I have no opinion, but this is an unrelated topic.


But if I was convinced that it was a good idea then this is what I would do  
already: contacting the sudo-stewards and submitting a patch. It's worth a  
shot, and that's what I would do, if it bugged me. A few years ago, because  
of a crazy reason, I thought that adding a few bits to libxcb would be a  
useful thing to do, and I did exactly that. And they agreed!  So, rather  
than wondering, why doesn't X do Y, how about: take the bull by the horns  
and see what happens?



Yeah, OpenSSH split up its stuff into multiple processes that talk to
each other via IPC and where privs are never acquired, but only
lost. it's the perfect example of how to actually do things well, and
*not* using setuid because it's a broken design.


I would agree: having openssh being a suid program is …not recommended.


Anyway, I understand your love suid and sudo.


I love suid and sudo no more, no less, and exactly the same as I love my  
screwdriver. I'm married to neither. Both are just tools. Both can be used,  
by people, correctly. Both can be used also, by people, incorrectly. But it  
makes no sense to use that as a reason for replacing screwdrivers with  
wrenches.



But please accept that
some people, me being one of them, think the concept is a very bad
idea. Some others have voiced their takes already on this mailing
list.


I never claimed that others are not allowed to have different opinions, or  
there's something wrong with them if they do. I have to admit that a long  
time ago I might've believed something like that. But I'm older now and I  
recognize that others will have different opinions. I'm not affiliated with  
sudo, in any way, and have no skin in the game. If they choose to update  
sudo to work in the described way, more power to them and we'll see how that  
works out. If Fedora decides to get sudo replaced by some alternative that  
works this way, we'll see how well that works out too, when it happens.




pgpsrbL1UNcIV.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

[Bug 2032433] perl-namespace-sweep for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-namespace-sweep-0.006-
   ||16.el9
 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2022-02-02 00:23:55



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-ff35d4670a has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2032433
___
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 2037243] perl-String-Similarity missing from EPEL

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-EPEL-2022-e5e754fef7 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2037243
___
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 2031796] perl-Email-Sender for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-56a8bcadcb has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-56a8bcadcb


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031796
___
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 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML for EPEL-8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-8cd0241486 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-8cd0241486


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2036125
___
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 2048109] Please branch and build perl-IO-Async in epel9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-56a8bcadcb has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-56a8bcadcb


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2048109
___
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 2031798] perl-FCGI-Client for EPEL 9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-56a8bcadcb has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-56a8bcadcb


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031798
___
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: Announcing LLVM Snapshot Packages for Fedora Linux

[Davide Cavalca via epel-devel]

On Tue, 2022-02-01 at 13:59 +0100, Konrad Kleine wrote:
> Davide,
> 
> thank you for your interest in this. May I ask what plans you have
> using it for? We're investigating an integration into CentOS Stream.

Hi Konrad,

the immediate usecase for us is making it easier to do development on
BPF upstream and run the test suite. CentOS Stream would actually work
well in this case, as that's what we actually run, though I don't think
the delta between targeting CentOS Stream and EPEL would be that
significant.

Cheers
Davide
___
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: Announcing LLVM Snapshot Packages for Fedora Linux

[Davide Cavalca via devel]

On Tue, 2022-02-01 at 13:59 +0100, Konrad Kleine wrote:
> Davide,
> 
> thank you for your interest in this. May I ask what plans you have
> using it for? We're investigating an integration into CentOS Stream.

Hi Konrad,

the immediate usecase for us is making it easier to do development on
BPF upstream and run the test suite. CentOS Stream would actually work
well in this case, as that's what we actually run, though I don't think
the delta between targeting CentOS Stream and EPEL would be that
significant.

Cheers
Davide
___
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: search among all spec files

[Kevin Fenzi]

On Tue, Feb 01, 2022 at 01:47:43PM -0800, Michel Alexandre Salim wrote:
> On Tue, Feb 01, 2022 at 01:16:57AM +0100, Miro Hrončok wrote:
> > On 01. 02. 22 1:03, Germano Massullo wrote:
> > > Good day. I have to search gcc-toolset among all Fedora packages specs
> > > files, in order to read some example of usage.
> > > Is that possible? For example cloning the whole git repository.
> > 
> > This tarball contains all Rawhide spec files, updated I believe daily.
> > 
> > https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz
> > 
> Quick question on this, since.. it seems to be known to old-timers but I
> can't really find it in documentation.
> 
> Which URL is supposed to be canonical? They all seem to point to the
> same place
> 
> - https://pkgs.fedoraproject.org/repo/ redirects to
>   https://src.fedoraproject.org/repo/
> - https://pkgs.fedoraproject.org/lookaside/ redirects to
>   https://src.fedoraproject.org/lookaside/
> - /repo/ and /lookaside/ have the same content
> - https://src.fedoraproject.org/repo returns 404, but
>   https://src.fedoraproject.org/lookaside redirects to /lookaside/

This last one should be right: 

https://src.fedoraproject.org/lookaside/

pkgs exists for historical reasons. It's used when packagers use git via
ssh. So, pkgs has ssh directly into the machine, but all https goes via
our proxy setup, so src.fedoraproject.org is proxies where it's in front
of the real machine. 

> 
> And ... I'm happy to document this, but where should this live? (or, if
> there's documentation for it, where is it?)

I don't think there is any, and I'd expect it to be in the packager
docs?

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

Re: GenericError: cannot update build 1910991, state: COMPLETE

[Kevin Fenzi]

On Tue, Feb 01, 2022 at 10:34:24PM +0100, Florian Weimer wrote:
> * Kevin Fenzi:
> 
> > On Tue, Feb 01, 2022 at 05:27:22PM +0100, Florian Weimer wrote:
> >>  failed
> >> with this error.  What is going on there?
> >> 
> >> I have tagged the glibc-2.34.9000-39.fc36 manually into
> >> f36-updates-candidate, which I assume will subject the build to gating.
> >> But it's still surprising.
> >
> > I suspect, but am not 100% sure, that this error was caused by koji
> > builders and hubs being different versions. I had downgraded the hubs to
> > 1.26.1 to avoid the failed tagging issue, but builders were still on
> > 1.27.1. 
> >
> > I have now re-upgraded the hubs (with 1.27.1 + patch for the tagging
> > issue) so hopefully this just goes away. 
> >
> > If anyone does see it again now, do let us know.
> 
> Thanks, it just happened again:
> 
> 82254171 build (f35-candidate, 
> /rpms/glibc.git:b9f986221822180f163fca98bd0ae5d00a92938f^^): open 
> (buildvm-s390x-18.s390.fedoraproject.org) -> FAILED: GenericError: cannot 
> update build 1911183, state: COMPLETE
> 
> This is glibc-2.34-22.fc35.

Filed https://pagure.io/koji/issue/3236 on this. 

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

Re: search among all spec files

[Michel Alexandre Salim]

On Tue, Feb 01, 2022 at 01:16:57AM +0100, Miro Hrončok wrote:
> On 01. 02. 22 1:03, Germano Massullo wrote:
> > Good day. I have to search gcc-toolset among all Fedora packages specs
> > files, in order to read some example of usage.
> > Is that possible? For example cloning the whole git repository.
> 
> This tarball contains all Rawhide spec files, updated I believe daily.
> 
> https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz
> 
Quick question on this, since.. it seems to be known to old-timers but I
can't really find it in documentation.

Which URL is supposed to be canonical? They all seem to point to the
same place

- https://pkgs.fedoraproject.org/repo/ redirects to
  https://src.fedoraproject.org/repo/
- https://pkgs.fedoraproject.org/lookaside/ redirects to
  https://src.fedoraproject.org/lookaside/
- /repo/ and /lookaside/ have the same content
- https://src.fedoraproject.org/repo returns 404, but
  https://src.fedoraproject.org/lookaside redirects to /lookaside/

And ... I'm happy to document this, but where should this live? (or, if
there's documentation for it, where is it?)

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

Re: Odd annobin output during mock build?

[Gary Buhrmaster]

On Tue, Feb 1, 2022 at 9:27 PM Richard Shaw  wrote:
>
> I just did a local mock build of the latest version of OpenImageIO which was 
> just released and saw this on every cpp line:
>
> annobin: /builddir/build/BUILD/oiio-2.3.12.0/src/libutil/errorhandler.cpp: 
> Warning: -D_GLIBCXX_ASSERTIONS not defined
>
> Is this harmless?

This (well, the related and additionally documented case)
was reported in https://bugzilla.redhat.com/show_bug.cgi?id=2047148
and the various packages have been rebuild, but as I recall
that for other reasons rawhide has not had a successful compose
so you need to explicitly specify the local repo to get the latest
buildroot (until everything settles down, hopefully RSN).
___
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: Odd annobin output during mock build?

[Florian Weimer]

* Richard Shaw:

> On Tue, Feb 1, 2022 at 3:33 PM Florian Weimer  wrote:
>
>  * Richard Shaw:
>
>  > I just did a local mock build of the latest version of OpenImageIO which 
> was just
>  released
>  > and saw this on every cpp line:
>  >
>  > annobin: /builddir/build/BUILD/oiio-2.3.12.0/src/libutil/errorhandler.cpp: 
> Warning:
>  > -D_GLIBCXX_ASSERTIONS not defined
>  >
>  > Is this harmless?
>
>  Not really, it means that the annobin/gcc ABI is out of whack.  You need
>  --enablerepo=local to get a consistent set of packages.
>
> Well the build completed so I assume performing a real build would
> have local available so I should be alright.

Correct, the buildroot is consistent right now.  A real build will not
have this problem.

Thanks,
Florian
___
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: Odd annobin output during mock build?

[Richard Shaw]

On Tue, Feb 1, 2022 at 3:33 PM Florian Weimer  wrote:

> * Richard Shaw:
>
> > I just did a local mock build of the latest version of OpenImageIO which
> was just released
> > and saw this on every cpp line:
> >
> > annobin:
> /builddir/build/BUILD/oiio-2.3.12.0/src/libutil/errorhandler.cpp: Warning:
> > -D_GLIBCXX_ASSERTIONS not defined
> >
> > Is this harmless?
>
> Not really, it means that the annobin/gcc ABI is out of whack.  You need
> --enablerepo=local to get a consistent set of packages.
>

Well the build completed so I assume performing a real build would have
local available so I should be alright.

Thanks,
Richard
___
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: Odd annobin output during mock build?

[Dan Horák]

On Tue, 1 Feb 2022 15:27:06 -0600
Richard Shaw  wrote:

> I just did a local mock build of the latest version of OpenImageIO which
> was just released and saw this on every cpp line:
> 
> annobin: /builddir/build/BUILD/oiio-2.3.12.0/src/libutil/errorhandler.cpp:
> Warning: -D_GLIBCXX_ASSERTIONS not defined
> 
> Is this harmless?

run mock with --enablerepo=local, then you will get the latest
buildroot, same as in koji


Dan
___
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: GenericError: cannot update build 1910991, state: COMPLETE

[Florian Weimer]

* Kevin Fenzi:

> On Tue, Feb 01, 2022 at 05:27:22PM +0100, Florian Weimer wrote:
>>  failed
>> with this error.  What is going on there?
>> 
>> I have tagged the glibc-2.34.9000-39.fc36 manually into
>> f36-updates-candidate, which I assume will subject the build to gating.
>> But it's still surprising.
>
> I suspect, but am not 100% sure, that this error was caused by koji
> builders and hubs being different versions. I had downgraded the hubs to
> 1.26.1 to avoid the failed tagging issue, but builders were still on
> 1.27.1. 
>
> I have now re-upgraded the hubs (with 1.27.1 + patch for the tagging
> issue) so hopefully this just goes away. 
>
> If anyone does see it again now, do let us know.

Thanks, it just happened again:

82254171 build (f35-candidate, 
/rpms/glibc.git:b9f986221822180f163fca98bd0ae5d00a92938f^^): open 
(buildvm-s390x-18.s390.fedoraproject.org) -> FAILED: GenericError: cannot 
update build 1911183, state: COMPLETE

This is glibc-2.34-22.fc35.

Thanks,
Florian
___
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: Odd annobin output during mock build?

[Florian Weimer]

* Richard Shaw:

> I just did a local mock build of the latest version of OpenImageIO which was 
> just released
> and saw this on every cpp line:
>
> annobin: /builddir/build/BUILD/oiio-2.3.12.0/src/libutil/errorhandler.cpp: 
> Warning:
> -D_GLIBCXX_ASSERTIONS not defined
>
> Is this harmless?

Not really, it means that the annobin/gcc ABI is out of whack.  You need
--enablerepo=local to get a consistent set of packages.

Thanks,
Florian
___
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

Odd annobin output during mock build?

[Richard Shaw]

I just did a local mock build of the latest version of OpenImageIO which
was just released and saw this on every cpp line:

annobin: /builddir/build/BUILD/oiio-2.3.12.0/src/libutil/errorhandler.cpp:
Warning: -D_GLIBCXX_ASSERTIONS not defined

Is this harmless?

Thanks,
Richard
___
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: Retire openCOLLADA?

[Bruno Postle]

On Sat, 29 Jan 2022, 21:28 Richard Shaw, wrote:

> It seems to fail with gcc 12 due to uninitialized variables. That's easy
> enough to work around but the last release was in 2018 and the only
> consumer in Fedora in Blender.
>
> Maybe it's time to retire it?
>

It's a dependency of IfcOpenShell, which at some point I intend to
introduce to fedora:
https://copr.fedorainfracloud.org/coprs/bpostle/IfcOpenShell/package/IfcOpenShell/

-- 
Bruno

>
___
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: openexr tests segfaulting on ppc64le only

[Richard Shaw]

Getting closer, now just test 86 is segfaulting...

Thanks,
Richard
___
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: openexr tests segfaulting on ppc64le only

[Dan Horák]

On Tue, 1 Feb 2022 14:35:52 -0600
Richard Shaw  wrote:

> What's the best way to modify the flags? I tried this but it bombed out...
> 
> %ifarch ppc64le
> %global optflags "%{optflags} -fno-inline-small-functions"
> %endif

I believe you need to omit the quotes


Dan
___
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: Weirdness with clang and stdatomic.h on Rawhide

[Jonathan Wakely]

On Tue, 1 Feb 2022 at 15:00, Ron Olson wrote:
>
> Well, yes and no. The code I linked to in the pastebin is what demonstrates 
> the issue. The code in question is Apple’s libdispatch which I package 
> separately as well as part of Swift. In that situation they’re using a C++ 
> file that uses the underlying primitives in stdatomic in macros for their own 
> higher-level functions, thus why stdatomic is ultimately being invoked.

Does this help?

https://github.com/apple/swift-corelibs-libdispatch/compare/main...jwakely:patch-1
___
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: openexr tests segfaulting on ppc64le only

[Richard Shaw]

What's the best way to modify the flags? I tried this but it bombed out...

%ifarch ppc64le
%global optflags "%{optflags} -fno-inline-small-functions"
%endif

Thanks,
Richard
___
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: Self Introduction: Stewart Smith

[Matthew Miller]

On Thu, Jan 20, 2022 at 10:49:59AM -0800, Stewart Smith via devel wrote:
> Hi there, I’m Stewart, a Principal Engineer at AWS working on Amazon
> Linux, and thanks to our new direction in basing Amazon Linux on Fedora,
> also Fedora.

Hi Stewart! Welcome -- it's great to see you here!

-- 
Matthew Miller

Fedora Project Leader
___
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 2031796] perl-Email-Sender for EPEL 9

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Emmanuel Seyman  ---
https://pagure.io/releng/fedora-scm-requests/issue/41676


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031796
___
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 2031798] perl-FCGI-Client for EPEL 9

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Emmanuel Seyman  ---
https://pagure.io/releng/fedora-scm-requests/issue/41675


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031798
___
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 2036125] Please branch and build perl-HTML-TreeBuilder-LibXML for EPEL-8

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #3 from Emmanuel Seyman  ---
epel8: https://pagure.io/releng/fedora-scm-requests/issue/41673
epel9: https://pagure.io/releng/fedora-scm-requests/issue/41674


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2036125
___
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 2048109] Please branch and build perl-IO-Async in epel9

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Emmanuel Seyman  ---
https://pagure.io/releng/fedora-scm-requests/issue/41672


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2048109
___
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: Package review wanted - xterm-console

[Michel Alexandre Salim]

On Tue, Feb 01, 2022 at 11:38:41AM -0800, Adam Williamson wrote:
> Hi folks! Was wondering if any packager would be able to do a quick
> package review for me:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049236
> 
> It's a relatively small and simple package so it shouldn't be too hard,
> though it's slightly unusual both in terms of what it does and how it
> does it.
> 
> I'd be happy to swap for a package review of similar complexity, or
> some other approximately equal task which you need doing and which I
> can do :)

This looks interesting, taken!

If you have time, getting any of the dependencies of 
https://bugzilla.redhat.com/show_bug.cgi?id=2040994
reviewed would be nice (only if you're fine with reviewing Rust!)


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

Re: Retire openCOLLADA?

[Richard Shaw]

On Sat, Jan 29, 2022 at 4:20 PM Nico Kadel-Garcia  wrote:

> "uninitalized variables" is generally easy to fix in the source code.
> Has the author dropped the project, the last update in the github repo
> is frm at least 3 years ago.
>

I found a fork with some of the fixes needed so at least it's building
again. So we're OK for now but I consider it on "life support" at this
point.

Thanks,
Richard
___
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

Package review wanted - xterm-console

[Adam Williamson]

Hi folks! Was wondering if any packager would be able to do a quick
package review for me:

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

It's a relatively small and simple package so it shouldn't be too hard,
though it's slightly unusual both in terms of what it does and how it
does it.

I'd be happy to swap for a package review of similar complexity, or
some other approximately equal task which you need doing and which I
can do :)

Thanks folks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
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 2043397] perl-Email-Abstract for EPEL9

[bugzilla]

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



--- Comment #7 from Paul Howarth  ---
(In reply to Tom "spot" Callaway from comment #6)
> (In reply to Paul Howarth from comment #3)
> > Thanks. perl-Mail-Transport and perl-Mail-Message look OK but I don't see me
> > listed for perl-Email-Abstract yet. That won't matter for epel9 because it's
> > already branched but it'd be nice to have for when epel10 comes around. I've
> > done the branch requests for perl-Mail-Transport and perl-Mail-Message and
> > should be able to handle all three packages once they're done.
> 
> Not sure how that broke, but it is fixed now.

Thanks.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2043397
___
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 2049238] New: perl-Devel-PPPort-3.64 is available

[bugzilla]

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

Bug ID: 2049238
   Summary: perl-Devel-PPPort-3.64 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Devel-PPPort
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.64
Current version/release in rawhide: 3.63-3.fc36
URL: http://search.cpan.org/dist/Devel-PPPort/

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/5760/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2049238
___
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 2043397] perl-Email-Abstract for EPEL9

[bugzilla]

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



--- Comment #6 from Tom "spot" Callaway  ---
(In reply to Paul Howarth from comment #3)
> (In reply to Tom "spot" Callaway from comment #2)
> > Paul, you should have admin rights on perl-Mail-Transport,
> > perl-Mail-Message, and perl-Email-Abstract now. Email-Abstract has an epel9
> > branch, but until Mail-Message is done, it won't build.
> 
> Thanks. perl-Mail-Transport and perl-Mail-Message look OK but I don't see me
> listed for perl-Email-Abstract yet. That won't matter for epel9 because it's
> already branched but it'd be nice to have for when epel10 comes around. I've
> done the branch requests for perl-Mail-Transport and perl-Mail-Message and
> should be able to handle all three packages once they're done.

Not sure how that broke, but it is fixed now.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2043397
___
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: GenericError: cannot update build 1910991, state: COMPLETE

[Kevin Fenzi]

On Tue, Feb 01, 2022 at 05:27:22PM +0100, Florian Weimer wrote:
>  failed
> with this error.  What is going on there?
> 
> I have tagged the glibc-2.34.9000-39.fc36 manually into
> f36-updates-candidate, which I assume will subject the build to gating.
> But it's still surprising.

I suspect, but am not 100% sure, that this error was caused by koji
builders and hubs being different versions. I had downgraded the hubs to
1.26.1 to avoid the failed tagging issue, but builders were still on
1.27.1. 

I have now re-upgraded the hubs (with 1.27.1 + patch for the tagging
issue) so hopefully this just goes away. 

If anyone does see it again now, do let us know. 

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

Re: Fwd: conditional require (RPM dependency solving puzzle)

[Steven A. Falco]

On 2/1/22 01:45 PM, przemek klosowski via devel wrote:


On 2/1/22 12:54, Miro Hrončok wrote:

Thanks to Steven, Stephen and Miro for finding this solution. Still, having to 
add flags and deleting the existing doc package is not completely 
gruntling---it works, but it's not automatic and, for the future, I am curious 
if there's another way.

Sorry for flogging this fine stallion, but I believe that 'dnf update kicad 
kicad-doc' would have worked (I did check that updating kicad-doc followed by 
updating kicad works). Isn't there some combination of 
Required/Obsoletes/Conflicts/??? to coax dnf to upgrade both packages instead 
of deleting kicad-doc?


This should work without --allowerasing once the packages are actually in a repository. "dnf update kicad" will see the newer version of kicad-doc and it will update both at the same time. 

This is after enabling Steven's COPR 
copr:copr.fedorainfracloud.org:group_kicad:kicad , which contains kicad, 
kicad-doc and kicad-packages3d. Are you saying that it would make a difference 
when they are in the main Fedora - Updates repo?


It is not in Copr yet, as I just pointed out in my previous email.

Steve
___
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: Fwd: conditional require (RPM dependency solving puzzle)

[Steven A. Falco]

On 2/1/22 12:54 PM, Miro Hrončok wrote:

On 01. 02. 22 18:01, przemek klosowski via devel wrote:




rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
kicad-doc < 1:6.0.1-4.fc35 

...

When I add the '--best --allowerasing' flags, then I get the desired result:

# dnf update kicad-6.0.1-4.fc35.x86_64.rpm --best --allowerasing
Last metadata expiration check: 0:43:04 ago on Mon 31 Jan 2022 05:06:19 PM EST.
Dependencies resolved.

  Package    Architecture    Version Repository Size

Upgrading:
  kicad  x86_64  1:6.0.1-4.fc35 @commandline 90 M
Removing dependent packages:
  kicad-doc  noarch  1:5.1.12-1.fc35 @updates 111 M


Thanks to Steven, Stephen and Miro for finding this solution. Still, having to 
add flags and deleting the existing doc package is not completely 
gruntling---it works, but it's not automatic and, for the future, I am curious 
if there's another way.

Sorry for flogging this fine stallion, but I believe that 'dnf update kicad 
kicad-doc' would have worked (I did check that updating kicad-doc followed by 
updating kicad works). Isn't there some combination of 
Required/Obsoletes/Conflicts/??? to coax dnf to upgrade both packages instead 
of deleting kicad-doc?


This should work without --allowerasing once the packages are actually in a repository. 
"dnf update kicad" will see the newer version of kicad-doc and it will update 
both at the same time.


That is correct.  The --allowerasing only happened because I was testing from a 
local mock build, and deliberately only supplied the main package as part of my 
testing.  You won't have that problem in normal use, once I get Copr to 
complete the build.

However, Copr is being difficult at the moment.  For some reason, the ppc64le 
builders all failed after an hour with:

Connection timed out during banner exchange
Connection to 140.211.168.28 port 22 timed out

Sigh.  The build normally takes over 5 hours.  I'll have to restart it yet 
again.

(Aside: the koji build of KiCad for rawhide went fine, but because KiCad just 
went through a major version change, I have to use Copr for F34/F35.)

Steve
___
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: Fwd: conditional require (RPM dependency solving puzzle)

[przemek klosowski via devel]

On 2/1/22 12:54, Miro Hrončok wrote:
Thanks to Steven, Stephen and Miro for finding this solution. Still, 
having to add flags and deleting the existing doc package is not 
completely gruntling---it works, but it's not automatic and, for the 
future, I am curious if there's another way.


Sorry for flogging this fine stallion, but I believe that 'dnf update 
kicad kicad-doc' would have worked (I did check that updating 
kicad-doc followed by updating kicad works). Isn't there some 
combination of Required/Obsoletes/Conflicts/??? to coax dnf to 
upgrade both packages instead of deleting kicad-doc?


This should work without --allowerasing once the packages are actually 
in a repository. "dnf update kicad" will see the newer version of 
kicad-doc and it will update both at the same time. 
This is after enabling Steven's COPR 
copr:copr.fedorainfracloud.org:group_kicad:kicad , which contains kicad, 
kicad-doc and kicad-packages3d. Are you saying that it would make a 
difference when they are in the main Fedora - Updates repo?___
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

Fedora CoreOS Community Video Meeting 2022-02-02

[Dusty Mabe]

Hi All,

Tomorrow we will be holding a video meeting for the Fedora CoreOS community.

We will be discussing Fedora 36 changes as well as our high level goals.

Time: 16:30 UTC (same as normal) on Wednesday February 2nd
Location: https://meet.google.com/meo-enbb-rur (will be recorded)
Agenda/Notes: https://hackmd.io/R5RGUFUATG-pPl34KhgXXg?view

Dusty
___
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: Fwd: conditional require (RPM dependency solving puzzle)

[Miro Hrončok]

On 01. 02. 22 18:01, przemek klosowski via devel wrote:




rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
kicad-doc < 1:6.0.1-4.fc35 

...

When I add the '--best --allowerasing' flags, then I get the desired result:

# dnf update kicad-6.0.1-4.fc35.x86_64.rpm --best --allowerasing
Last metadata expiration check: 0:43:04 ago on Mon 31 Jan 2022 05:06:19 PM 
EST.

Dependencies resolved.
 


  Package    Architecture    Version Repository Size
 


Upgrading:
  kicad  x86_64  1:6.0.1-4.fc35 @commandline   
90 M

Removing dependent packages:
  kicad-doc  noarch  1:5.1.12-1.fc35 @updates  
111 M


Thanks to Steven, Stephen and Miro for finding this solution. Still, having to 
add flags and deleting the existing doc package is not completely 
gruntling---it works, but it's not automatic and, for the future, I am curious 
if there's another way.


Sorry for flogging this fine stallion, but I believe that 'dnf update kicad 
kicad-doc' would have worked (I did check that updating kicad-doc followed by 
updating kicad works). Isn't there some combination of 
Required/Obsoletes/Conflicts/??? to coax dnf to upgrade both packages instead 
of deleting kicad-doc?


This should work without --allowerasing once the packages are actually in a 
repository. "dnf update kicad" will see the newer version of kicad-doc and it 
will update both at the same time.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: List of long term FTBFS packages to be retired in March

[Artur Frenszek-Iwicki]

> chocolate-doomsundaram
I've managed to get this to build successfully in koji.
I'll try to contact the maintainer, though looking at bugzilla, they haven't 
been active since April 2020.
I'm willing to adopt the package should the maintainer drop it or be declared 
unresponsive.

A.FI.
___
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

Fwd: conditional require (RPM dependency solving puzzle)

[przemek klosowski via devel]

rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
kicad-doc < 1:6.0.1-4.fc35 

...

When I add the '--best --allowerasing' flags, then I get the 
desired result:


# dnf update kicad-6.0.1-4.fc35.x86_64.rpm --best --allowerasing
Last metadata expiration check: 0:43:04 ago on Mon 31 Jan 2022 
05:06:19 PM EST.

Dependencies resolved.
 

  Package    Architecture    Version Repository 
Size
 


Upgrading:
  kicad  x86_64  1:6.0.1-4.fc35 
@commandline   90 M

Removing dependent packages:
  kicad-doc  noarch  1:5.1.12-1.fc35 
@updates  111 M


Thanks to Steven, Stephen and Miro for finding this solution. Still, 
having to add flags and deleting the existing doc package is not 
completely gruntling---it works, but it's not automatic and, for the 
future, I am curious if there's another way.


Sorry for flogging this fine stallion, but I believe that 'dnf update 
kicad kicad-doc' would have worked (I did check that updating kicad-doc 
followed by updating kicad works). Isn't there some combination of 
Required/Obsoletes/Conflicts/??? to coax dnf to upgrade both packages 
instead of deleting kicad-doc?


___
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: openexr tests segfaulting on ppc64le only

[Jerry James]

On Tue, Feb 1, 2022 at 9:53 AM Richard Shaw  wrote:
> No, I haven't tried building on one of the packager ppc boxes to investigate 
> further. Fighting other gcc 12 / python 3.10/3.11 issues :)
>
> Did you add the flag for ppc64le only? I'll try and see if it fixes things 
> for me as well.

Yes, for ppc64le only.  The bigger hammer of -fno-inline-functions
also does the job.  The challenge with clisp is that the sources are
written in Lisp, then converted to C and passed to the compiler, so
I'm looking at machine-generated C code rather than human-written C
code.  Lots of fun. :-)
-- 
Jerry James
http://www.jamezone.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: openexr tests segfaulting on ppc64le only

[Richard Shaw]

On Tue, Feb 1, 2022 at 10:40 AM Jerry James  wrote:

> On Sun, Jan 30, 2022 at 9:38 AM Richard Shaw  wrote:
> > I thought the gcc 12 related issues with ppc64le had been fixed but
> perhaps not in all cases?
> >
> > On the original rebuild[1] two tests failed (segfaulting) but on my
> latest attempt with the new gcc 12 build[2] I now have 3 tests segfaulting.
>
> Did you ever figure this out?  I have similar symptoms with the clisp
> package: one test segfaults on ppc64le only.  I experimented with
> various build flags and found that adding -fno-inline-small-functions
> makes the test pass.  I haven't had time to dig into any further than
> that yet.
>

No, I haven't tried building on one of the packager ppc boxes to
investigate further. Fighting other gcc 12 / python 3.10/3.11 issues :)

Did you add the flag for ppc64le only? I'll try and see if it fixes things
for me as well.

Thanks,
Richard
___
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: openexr tests segfaulting on ppc64le only

[Jerry James]

On Sun, Jan 30, 2022 at 9:38 AM Richard Shaw  wrote:
> I thought the gcc 12 related issues with ppc64le had been fixed but perhaps 
> not in all cases?
>
> On the original rebuild[1] two tests failed (segfaulting) but on my latest 
> attempt with the new gcc 12 build[2] I now have 3 tests segfaulting.

Did you ever figure this out?  I have similar symptoms with the clisp
package: one test segfaults on ppc64le only.  I experimented with
various build flags and found that adding -fno-inline-small-functions
makes the test pass.  I haven't had time to dig into any further than
that yet.
-- 
Jerry James
http://www.jamezone.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

GenericError: cannot update build 1910991, state: COMPLETE

[Florian Weimer]

 failed
with this error.  What is going on there?

I have tagged the glibc-2.34.9000-39.fc36 manually into
f36-updates-candidate, which I assume will subject the build to gating.
But it's still surprising.

Thanks,
Florian
___
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 2048963] Add perl-Cache-LRU to EPEL9

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-62ea3f4c25 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-62ea3f4c25


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2048963
___
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 2048250] perl-DateTime-Calendar-Julian-0.107 is available

[bugzilla]

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
   Doc Type|--- |If docs needed, set a value
Last Closed||2022-02-01 15:50:55



--- Comment #2 from Tom "spot" Callaway  ---
perl-DateTime-Calendar-Julian-0.107-1.fc36 in rawhide.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2048250
___
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

spot pushed to perl-DateTime-Calendar-Julian (rawhide). "0.107"

[notifications]

Notification time stamped 2022-02-01 15:43:53 UTC

From 2e6fcfb083c69762919064da6c742c839fd43d13 Mon Sep 17 00:00:00 2001
From: Tom spot Callaway 
Date: Feb 01 2022 15:43:47 +
Subject: 0.107


---

diff --git a/.gitignore b/.gitignore
index ad4d9c6..48a3515 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@
 /DateTime-Calendar-Julian-0.104.tar.gz
 /DateTime-Calendar-Julian-0.105.tar.gz
 /DateTime-Calendar-Julian-0.106.tar.gz
+/DateTime-Calendar-Julian-0.107.tar.gz
diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
index 080395b..26009bf 100644
--- a/perl-DateTime-Calendar-Julian.spec
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -1,13 +1,13 @@
 Name:  perl-DateTime-Calendar-Julian
-Version:   0.106
-Release:   2%{?dist}
+Version:   0.107
+Release:   1%{?dist}
 License:   GPL+ or Artistic
 Summary:   Julian Calendar support for DateTime.pm
 Url:   https://metacpan.org/release/DateTime-Calendar-Julian
 Source:
https://cpan.metacpan.org/authors/id/W/WY/WYANT/DateTime-Calendar-Julian-%{version}.tar.gz
 BuildArch: noarch
 BuildRequires: perl-generators, perl-interpreter, make
-BuildRequires: perl(DateTime) >= 0.15
+BuildRequires: perl(DateTime) >= 1.48
 BuildRequires: perl(ExtUtils::MakeMaker) >= 6.76
 BuildRequires: perl(strict)
 BuildRequires: perl(Test::More)
@@ -39,6 +39,9 @@ make test
 %{_mandir}/man3/DateTime::Calendar::Julian.3pm*
 
 %changelog
+* Tue Feb  1 2022 Tom Callaway  - 0.107-1
+- update to 0.107
+
 * Fri Jan 21 2022 Fedora Release Engineering  - 
0.106-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
 
diff --git a/sources b/sources
index 528bf4b..59d9e8c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (DateTime-Calendar-Julian-0.106.tar.gz) = 
180955341937d6d809df70006e9ca45ec1c4fc0e3db79d32cd40cb934a7cbe022b893ba4dc2f914d5f502e355214e9ead44ec1846db9b18d649b9222aacce800
+SHA512 (DateTime-Calendar-Julian-0.107.tar.gz) = 
8219c4d8e998ebeb536d46f2d81b40a5ff21a3fc3c6e8c2c063b334e7a9f2cb73f14cdb5c82cac60bc9b1c6eb6ff43235f955f7775e47aaf4f903db654a34a5b



https://src.fedoraproject.org/rpms/perl-DateTime-Calendar-Julian/c/2e6fcfb083c69762919064da6c742c839fd43d13?branch=rawhide
___
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: Weirdness with clang and stdatomic.h on Rawhide

[Ron Olson]

Well, yes and no. The code I linked to in the pastebin is what demonstrates the 
issue. The code in question is Apple’s libdispatch which I package separately 
as well as part of Swift. In that situation they’re using a C++ file that uses 
the underlying primitives in stdatomic in macros for their own higher-level 
functions, thus why stdatomic is ultimately being invoked.



On 1 Feb 2022, at 3:26, Jonathan Wakely wrote:

> On Tue, 1 Feb 2022 at 09:15, Jonathan Wakely  wrote:
>>
>> On Mon, 31 Jan 2022 at 22:45, Ron Olson  wrote:
>>>
>>> Hey all,
>>>
>>> I’m troubleshooting an issue and came up with this sample program: 
>>> https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 
>>> 13, on Rawhide, won’t compile that program, while on Fedora 35 it does.
>>>
>>> The reason why is that on Rawhide, stdatomic.h exists under 
>>> /usr/include/c++/12 while it does not exist on 35, so clang uses its 
>>> built-in stdatomic per 
>>> https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations.
>>
>> But that's about C, not C++.
>>
>>> If it uses its internal version, the sample program compiles fine.
>>>
>>> Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > 
>>> 202002L”, so that means C++2b or later, not C++20. This seems to create a 
>>> problem for clang which, since the file is present, wants to use it, but 
>>> since it’s effectively empty due to the #ifdef, compiling of the sample 
>>> program fails.
>>>
>>> Is it possible to disable clang’s use of the header file as a flag? I’ve 
>>> been unable to find anything like that, and obviously renaming the header 
>>> is out of the question.  Also, is it correct to the setting stdatomic.h to 
>>> only be used by c++2b?
>>
>> Yes, that's 100% correct.
>>
>> Clang is at fault here.  does not exist in C++ up to and
>> including the current C++20 standard, so Clang should not assume it's
>> present or usable.
>>
>> In C++23 there is now a  header in the C++ library for
>> compatibility. That's what I added to GCC, and that's what Clang is
>> now picking up.
>>
>> Why is C++ code in Clang using a C header that isn't part of C++?
>
> I think I misread, this isn't code in Clang, this is your code and
> you're just using Clang, right?
>
> So then you can fix your code fairly easily.
> ___
> 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

[Fedocal] Reminder meeting : Fedora Source-git SIG

[csomh]

Dear all,

You are kindly invited to the meeting:
   Fedora Source-git SIG on 2022-02-02 from 14:30:00 to 15:30:00 GMT
   At meet.google.com/mic-otnv-kse

The meeting will be about:
Meeting of the Fedora source-git SIG

Agenda:
https://pagure.io/fedora-source-git/sig/issues?tags=meeting=Open

SIG Info:
https://fedoraproject.org/wiki/SIGs/Source-git


Source: https://calendar.fedoraproject.org//meeting/10165/

___
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

F37 Change: MinGW OpenSSL 3.x update (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/F37MingwOpenSSL3

== Summary ==
Update OpenSSL for MinGW to version 3.x

== Owner ==
* Name: [[User:smani|Sandro Mani]]
* Email: manisan...@gmail.com


== Detailed Description ==

mingw-openssl will be updated to version 3.x. The following
dependencies will be rebuilt:

* mingw-spice-gtk (will be updated to version 0.39)
* mingw-spice-protocol (will be updated to 0.14.3)
* mingw-qt6-qtbase
* mingw-qca
* mingw-gstreamer1-plugins-bad-free
* mingw-curl
* mingw-python3
* mingw-postgresql
* mingw-podofo
* mingw-opusfile
* mingw-minizip
* mingw-libssh2
* mingw-gdal
* mingw-openssl

== Benefit to Fedora ==

Ship up-to-date OpenSSL libraries for MinGW.

== Scope ==
* Proposal owners: mingw-openssl will be updated and the mentioned
dependencies rebuilt.
* Other developers: No action required
* Release engineering: Mass rebuild requested
* Policies and guidelines: No policies need to be changed

== Upgrade/compatibility impact ==
No impact

== How To Test ==
If your application uses OpenSSL to communicate via TLS or perform
other tasks that use cryptographic algorithms from OpenSSL, please
test whether it continues to work properly. This should be covered by
the comprehensive upstream testsuite of OpenSSL. However many
dependent packages also provide good test coverage of OpenSSL
functionality.

== User Experience ==
There should be no impact on end-user experience.

== Dependencies ==
None

== Contingency Plan ==
* Contingency mechanism: Revert to older versions of environment /
toolchain, mass rebuild mingw packages again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No

== Release Notes ==
Fedora 37 comes with mingw-openssl-3.x.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F37 Change: MinGW OpenSSL 3.x update (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/F37MingwOpenSSL3

== Summary ==
Update OpenSSL for MinGW to version 3.x

== Owner ==
* Name: [[User:smani|Sandro Mani]]
* Email: manisan...@gmail.com


== Detailed Description ==

mingw-openssl will be updated to version 3.x. The following
dependencies will be rebuilt:

* mingw-spice-gtk (will be updated to version 0.39)
* mingw-spice-protocol (will be updated to 0.14.3)
* mingw-qt6-qtbase
* mingw-qca
* mingw-gstreamer1-plugins-bad-free
* mingw-curl
* mingw-python3
* mingw-postgresql
* mingw-podofo
* mingw-opusfile
* mingw-minizip
* mingw-libssh2
* mingw-gdal
* mingw-openssl

== Benefit to Fedora ==

Ship up-to-date OpenSSL libraries for MinGW.

== Scope ==
* Proposal owners: mingw-openssl will be updated and the mentioned
dependencies rebuilt.
* Other developers: No action required
* Release engineering: Mass rebuild requested
* Policies and guidelines: No policies need to be changed

== Upgrade/compatibility impact ==
No impact

== How To Test ==
If your application uses OpenSSL to communicate via TLS or perform
other tasks that use cryptographic algorithms from OpenSSL, please
test whether it continues to work properly. This should be covered by
the comprehensive upstream testsuite of OpenSSL. However many
dependent packages also provide good test coverage of OpenSSL
functionality.

== User Experience ==
There should be no impact on end-user experience.

== Dependencies ==
None

== Contingency Plan ==
* Contingency mechanism: Revert to older versions of environment /
toolchain, mass rebuild mingw packages again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No

== Release Notes ==
Fedora 37 comes with mingw-openssl-3.x.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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: search among all spec files

[Germano Massullo]

Thank you everybody for your suggestions!
___
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

List of long term FTBFS packages to be retired in March

[Miro Hrončok]

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 36 approximately one week before branching.

However, 5 weekly reminders are required and I forgot to start this sooner,
hence the retirement will happen in 5 weeks, i.e. March 1st 2022.
Since this is after the Beta Freeze,
I will skip retiring components with depending packages.
Such components will be retired during the next release cycle,
and are included in this report for completeness.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 33.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.

Package  (co)maintainers

adf-tribun-fonts  frixxon, nim
catharsis-cormorant-fonts nim
chocolate-doomsundaram
ecolier-court-fonts   frixxon, nim
gfs-ambrosia-fontsfrixxon, nim
gfs-artemisia-fonts   nim
gfs-baskerville-fonts nim
gfs-bodoni-classic-fonts  nim
gfs-bodoni-fonts  nim
gfs-complutum-fonts   nim
gfs-decker-fonts  nim
gfs-didot-classic-fonts   nim
gfs-didot-display-fonts   nim
gfs-didot-fonts   nim
gfs-eustace-fonts nim
gfs-fleischman-fonts  nim
gfs-galatea-fonts nim
gfs-garaldus-fontsnim
gfs-gazis-fonts   nim
gfs-goschen-fonts nim
gfs-ignacio-fonts nim
gfs-jackson-fonts nim
gfs-neohellenic-fonts nim
gfs-neohellenic-math-fontsnim
gfs-nicefore-fontsnim
gfs-olga-fontsnim
gfs-orpheus-classic-fonts nim
gfs-orpheus-fonts nim
gfs-orpheus-sans-fontsnim
gfs-philostratos-fontsnim
gfs-porson-fonts  nim
gfs-pyrsos-fonts  nim
gfs-solomos-fonts nim
gfs-theokritos-fonts  nim
ht-alegreya-sans-fontsnim
ibm-plex-fontssuraia
impallari-dancing-script-fontsnim
impallari-raleway-fonts   nim
intel-clear-sans-fontsnim
jetbrains-mono-fonts  nim
kemie-bellota-fonts   nim
libicu65  pwalter
ndiscover-exo-2-fonts nim
rubygem-cucumber-railsmmorsi, vondruch
rubygem-selenium-webdrivermmorsi, ruby-packagers-sig, vondruch
rubygem-supdcallagh, jaruga, ruby-packagers-sig, shreyankg
sil-alkalami-fontsnim
sil-andika-compact-fonts  nim
sil-andika-fonts  nim
sil-andika-new-basic-fontsnim
sil-annapurna-fonts   nim
sil-apparatus-fonts   nim
sil-awami-nastaliq-fonts  nim
sil-charis-compact-fonts  nim
sil-charis-fonts  kevin, nim
sil-dai-banna-fonts   nim
sil-ezra-fontsnim
sil-gentium-plus-compact-fontsnim
sil-harmattan-fonts   nim
sil-mondulkiri-extra-fontsnim
sil-mondulkiri-fonts  nim
sil-namdhinggo-fonts  nim
sil-shimenkan-fonts   nim
sil-sophia-nubian-fonts   nim
sil-tagmukay-fontsnim
sil-tai-heritage-pro-fontsnim
symbian-m-yuppy-gb-fonts  nim
tmux-top  ttomecek
typesetit-great-vibes-fonts   nim
uswds-public-sans-fonts   nim
vernnobile-muli-fonts nim
vernnobile-nunito-fonts   nim
vernnobile-oswald-fonts   nim
wagesreiter-patrick-hand-fontsnim
weiweihuanghuang-work-sans-fonts  nim
yanone-kaffeesatz-fonts   nim

The following packages require above mentioned packages:
Depending on: impallari-raleway-fonts (90)
R-rmarkdown (maintained by: qulogic)
		R-rmarkdown-2.10-2.fc36.src requires impallari-raleway-fonts = 
4.025-3.20200310git98add57.fc33


sympa (maintained by: xavierb)
		sympa-6.2.68-1.fc36.src requires impallari-raleway-fonts = 
4.025-3.20200310git98add57.fc33
		sympa-6.2.68-1.fc36.x86_64 requires impallari-raleway-fonts = 
4.025-3.20200310git98add57.fc33


R-BiocFileCache (maintained by: spot)
R-BiocFileCache-2.0.0-3.fc36.src requires R-rmarkdown = 
2.10-2.fc36

R-DBItest (maintained by: qulogic)
R-DBItest-1.7.0-6.fc36.src requires R-rmarkdown = 

Re: CVE-2021-4034: why is pkexec still a thing?

[Lennart Poettering]

On Di, 01.02.22 09:01, Sam Varshavchik (mr...@courier-mta.com) wrote:

> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B2ZCFBIM3AWBUFJKNHGZWPLZZDZPH43Y/
> >
> > I explained a locking DoS there: run privileged code, but with
> > extremly restrictive resource scheduling settings, so that it will
> > acquire privileged resources such as locks (which it can, since it is
> > privileged) but is extremely slow to give up again since it runs
> > awfully slow, due to the extremely restrictive resource settings which
> > are under control of an unpriv caller.
>
> And an isolated process will be capable of rate-limiting itself in this
> situation any better than a sudo process, which could do the same kind of
> rate-limiting itself, exactly how?

"Rate-limiting"? Not sure what "rate-limiting" has to do with any of
this.

If priv code runs with extremely low prio, and acquires a shared
resource, that other priv code might wait for that isn't low prio,
then you have a classic prio inversion issue. because the higher prio
code will be slowed down to the level of the low prio process, which
can be used to DoS things.

prio inversion issues are well known and more or less just bugs. But
they become a security issue once unpriv code has control of the prios
of priv code and can bring the system to a standstill hence. Which is
the case here with sudo.

(i.e. the fact that sudo dosn't at least do a simple
setpriority(PRIO_PROCESS, 0, 0); is beyond me...)

> About the only thing that works to its advantage is that it'll be in a
> better position to employ rate limiting, by its virtue of being
> persistent.

So, apparently I am beyond terrible in explaining the issue, given
your unrelated responses. But I don't think I am going to waste more
time on this. If my explanations weren't useful now I doubt I can
improve them, so let's end this specific branch of the thread
here.

> An excellent example would be what happened to OpenSSH. My understanding is
> that they shuffled off all authentication stuff into a separate daemon that
> runs with restricted privileges. This is not quite a good analogue for sudo,
> there is no setuid bit involved here. But this is the right approach:
> analyze the individual situation, and figure out the best solution. For
> OpenSSH it seems to be what they picked to do, which makes a lot of
> sense.

Yeah, OpenSSH split up its stuff into multiple processes that talk to
each other via IPC and where privs are never acquired, but only
lost. it's the perfect example of how to actually do things well, and
*not* using setuid because it's a broken design.

> CVE-2006-0151: https://bugzilla.redhat.com/show_bug.cgi?id=139478
>
> # Statement for NVD:
> #
> # If an administrator is concerned that users who have been granted sudo #
> privileges can alter the environment, the existing "env_reset" option should
> # be used which cleans the whole environment.
>
> Mic drop.
>
> CVE-2005-3629: this is initscripts, not sudo, the topic here.
>
> CVE-2008-3825: this is PAM, not sudo.
>
> CVE-2014-9680:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1191144

These are all issues where insufficent process context cleanup
(specifically env var cleanup) made setuid transitions
exploitable. It's always the same issue.

Anyway, I understand your love suid and sudo. But please accept that
some people, me being one of them, think the concept is a very bad
idea. Some others have voiced their takes already on this mailing
list. Let's end this branch of the thread here, it's really pointless
from my PoV I just keep repeating myself.

Lennart

--
Lennart Poettering, Berlin
___
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: Action Required: Bugzilla - API Authentication changes

[Kevin Kofler via devel]

Miro Hrončok wrote:
> From: Jeff Fearn 
[…]
> If you attempt to use an old method to authenticate to the API after this
> change has been made, the API_KEY or password supplied will be treated as
> potentially compromised and invalidated immediately. If you supplied your
> password then you will need to follow the forgot password process to reset
> it. If you supplied an API_KEY it will have been banned and you will need
> to generate a new API_KEY in the UI.
> 
> This invalidation will happen every time an attempt to use an outdated
> authentication method is detected.

Wow! This is *extremely* unfriendly and unhelpful. There really needs to be 
at least a transition period where the old methods fail with an error 
without invalidating the credentials!

Kevin Kofler
___
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

List of long term FTBFS packages to be retired in March

[Miro Hrončok]

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 36 approximately one week before branching.

However, 5 weekly reminders are required and I forgot to start this sooner,
hence the retirement will happen in 5 weeks, i.e. March 1st 2022.
Since this is after the Beta Freeze,
I will skip retiring components with depending packages.
Such components will be retired during the next release cycle,
and are included in this report for completeness.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 33.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.

Package  (co)maintainers

adf-tribun-fonts  frixxon, nim
catharsis-cormorant-fonts nim
chocolate-doomsundaram
ecolier-court-fonts   frixxon, nim
gfs-ambrosia-fontsfrixxon, nim
gfs-artemisia-fonts   nim
gfs-baskerville-fonts nim
gfs-bodoni-classic-fonts  nim
gfs-bodoni-fonts  nim
gfs-complutum-fonts   nim
gfs-decker-fonts  nim
gfs-didot-classic-fonts   nim
gfs-didot-display-fonts   nim
gfs-didot-fonts   nim
gfs-eustace-fonts nim
gfs-fleischman-fonts  nim
gfs-galatea-fonts nim
gfs-garaldus-fontsnim
gfs-gazis-fonts   nim
gfs-goschen-fonts nim
gfs-ignacio-fonts nim
gfs-jackson-fonts nim
gfs-neohellenic-fonts nim
gfs-neohellenic-math-fontsnim
gfs-nicefore-fontsnim
gfs-olga-fontsnim
gfs-orpheus-classic-fonts nim
gfs-orpheus-fonts nim
gfs-orpheus-sans-fontsnim
gfs-philostratos-fontsnim
gfs-porson-fonts  nim
gfs-pyrsos-fonts  nim
gfs-solomos-fonts nim
gfs-theokritos-fonts  nim
ht-alegreya-sans-fontsnim
ibm-plex-fontssuraia
impallari-dancing-script-fontsnim
impallari-raleway-fonts   nim
intel-clear-sans-fontsnim
jetbrains-mono-fonts  nim
kemie-bellota-fonts   nim
libicu65  pwalter
ndiscover-exo-2-fonts nim
rubygem-cucumber-railsmmorsi, vondruch
rubygem-selenium-webdrivermmorsi, ruby-packagers-sig, vondruch
rubygem-supdcallagh, jaruga, ruby-packagers-sig, shreyankg
sil-alkalami-fontsnim
sil-andika-compact-fonts  nim
sil-andika-fonts  nim
sil-andika-new-basic-fontsnim
sil-annapurna-fonts   nim
sil-apparatus-fonts   nim
sil-awami-nastaliq-fonts  nim
sil-charis-compact-fonts  nim
sil-charis-fonts  kevin, nim
sil-dai-banna-fonts   nim
sil-ezra-fontsnim
sil-gentium-plus-compact-fontsnim
sil-harmattan-fonts   nim
sil-mondulkiri-extra-fontsnim
sil-mondulkiri-fonts  nim
sil-namdhinggo-fonts  nim
sil-shimenkan-fonts   nim
sil-sophia-nubian-fonts   nim
sil-tagmukay-fontsnim
sil-tai-heritage-pro-fontsnim
symbian-m-yuppy-gb-fonts  nim
tmux-top  ttomecek
typesetit-great-vibes-fonts   nim
uswds-public-sans-fonts   nim
vernnobile-muli-fonts nim
vernnobile-nunito-fonts   nim
vernnobile-oswald-fonts   nim
wagesreiter-patrick-hand-fontsnim
weiweihuanghuang-work-sans-fonts  nim
yanone-kaffeesatz-fonts   nim

The following packages require above mentioned packages:
Depending on: impallari-raleway-fonts (90)
R-rmarkdown (maintained by: qulogic)
		R-rmarkdown-2.10-2.fc36.src requires impallari-raleway-fonts = 
4.025-3.20200310git98add57.fc33


sympa (maintained by: xavierb)
		sympa-6.2.68-1.fc36.src requires impallari-raleway-fonts = 
4.025-3.20200310git98add57.fc33
		sympa-6.2.68-1.fc36.x86_64 requires impallari-raleway-fonts = 
4.025-3.20200310git98add57.fc33


R-BiocFileCache (maintained by: spot)
R-BiocFileCache-2.0.0-3.fc36.src requires R-rmarkdown = 
2.10-2.fc36

R-DBItest (maintained by: qulogic)
R-DBItest-1.7.0-6.fc36.src requires R-rmarkdown = 

Re: Orphaning some packages (w3c-markup-validator fallout)

[Paul Howarth]

Hi Nathanael,

On Mon, 31 Jan 2022 09:28:27 -0700
"Nathanael D. Noblet"  wrote:
>   I recently gave ownership of w3c-markup-validator to Sérgio Basto
> which reminded me that there are a handful of perl packages that I
> probably created/took a hand in as part of that. I haven't touched
> them in as long as w3c-markup-validator so probably should also
> orphan them as well. There are also some other packages like dspam
> that were great at the time and I used to use them but they don't get
> much if any development anymore and I don't run mail servers anymore.
> 
> The are as follows:
> 
> dspam

This one is already orphaned but you are the sole co-maintainer.

> html401-dtds

This one is yours with dcantrell as co-maintainer. Maybe ask him if he
wants it?

> perl-Config-General

You can give that one to me (FAS: pghmcfc) as I have other things that
depend on it.

> perl-HTML-Encoding

Just yours.

> perl-HTML-Tidy

Owned by eseyman and several others. I have emailed them separately.

> perl-Mail-Mbox-MessageParser

I am already the main admin for this.

> perl-Mail-MboxParser

This is owned by jplesnik.

> perl-SGML-Parser-OpenSP

Just yours.

> php-pecl-cairo

This one is yours with remi as co-maintainer. Maybe ask him if he
wants it?

> wkhtmltopdf

This is owned by mtasaka.

For the packages that have other people as main admins, you can just
remove yourself from the package. For the others, you could orphan them
or maybe reach out to any co-maintainers first.

Please assign perl-Config-General to me.

Cheers, Paul.
___
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: Orphaning some packages (w3c-markup-validator fallout)

[Paul Howarth]

Hi Nathanael,

On Mon, 31 Jan 2022 09:28:27 -0700
"Nathanael D. Noblet"  wrote:
>   I recently gave ownership of w3c-markup-validator to Sérgio Basto
> which reminded me that there are a handful of perl packages that I
> probably created/took a hand in as part of that. I haven't touched
> them in as long as w3c-markup-validator so probably should also
> orphan them as well. There are also some other packages like dspam
> that were great at the time and I used to use them but they don't get
> much if any development anymore and I don't run mail servers anymore.
> 
> The are as follows:
> 
> dspam

This one is already orphaned but you are the sole co-maintainer.

> html401-dtds

This one is yours with dcantrell as co-maintainer. Maybe ask him if he
wants it?

> perl-Config-General

You can give that one to me (FAS: pghmcfc) as I have other things that
depend on it.

> perl-HTML-Encoding

Just yours.

> perl-HTML-Tidy

Owned by eseyman and several others. I have emailed them separately.

> perl-Mail-Mbox-MessageParser

I am already the main admin for this.

> perl-Mail-MboxParser

This is owned by jplesnik.

> perl-SGML-Parser-OpenSP

Just yours.

> php-pecl-cairo

This one is yours with remi as co-maintainer. Maybe ask him if he
wants it?

> wkhtmltopdf

This is owned by mtasaka.

For the packages that have other people as main admins, you can just
remove yourself from the package. For the others, you could orphan them
or maybe reach out to any co-maintainers first.

Please assign perl-Config-General to me.

Cheers, Paul.
___
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.1-0.3.fc36 now in rawhide

[Dan Horák]

On Tue, 01 Feb 2022 14:55:14 +0100
Thomas Haller  wrote:

> On Thu, 2022-01-27 at 14:00 +0100, Thomas Haller wrote:
> > On Thu, 2022-01-27 at 11:09 +0100, Jakub Jelinek wrote:
> > > On Thu, Jan 27, 2022 at 10:32:22AM +0100, Thomas Haller wrote:
> > > > On Wed, 2022-01-26 at 23:57 +0100, Jakub Jelinek wrote:
> > > > > A new gcc with most importantly the
> > > > > https://gcc.gnu.org/PR104172
> > > > > bug (that caused a lot of ppc64le failures) fixed and various
> > > > > other
> > > > > fixes (e.g. std::basic_string(std::nullptr_t) = deleted only
> > > > > done
> > > > > for C++23 etc.) is now in rawhide.
> > > > > 
> > > > > Can rel-eng please retry all FTBS builds that failed on
> > > > > ppc64le?
> > > > 
> > > > it appears to me, that this breaks build of NetworkManager:
> > > >    https://koji.fedoraproject.org/koji/taskinfo?taskID=81998774
> > > > 
> > > > 
> > > >   checking if gcc supports flag -fno-strict-aliasing in envvar
> > > > CFLAGS... yes
> > > >   checking if gcc supports flag -flto -flto-partition=none in
> > > > envvar CFLAGS... no
> > > >   configure: error: Link Time Optimization -flto is not
> > > > supported.
> > > >   error: Bad exit status from /var/tmp/rpm-tmp.FQqAFe (%build)
> > > 
> > > Apparently it was annobin (although it passed the test done during
> > > gcc.spec
> > > testing, apparently it was incompatible again).
> > > Florian has rebuilt it, so please just retry.
> 
> 
> Hi,
> 
> after a few days, it seems, the problem still exists in the buildroot
> for copr:
> https://copr.fedorainfracloud.org/coprs/networkmanager/NetworkManager-main/build/3288936/
> 
> Should we just wait longer and it solves itself?

it should resolve itself (soon), copr is using the published repos and
there wasn't a successful compose for a while :-( The fixed builds
landed after the last one.


Dan
___
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.1-0.3.fc36 now in rawhide

[Jakub Jelinek]

On Tue, Feb 01, 2022 at 02:55:14PM +0100, Thomas Haller wrote:
> > > Apparently it was annobin (although it passed the test done during
> > > gcc.spec
> > > testing, apparently it was incompatible again).
> > > Florian has rebuilt it, so please just retry.
> 
> 
> Hi,
> 
> after a few days, it seems, the problem still exists in the buildroot
> for copr:
> https://copr.fedorainfracloud.org/coprs/networkmanager/NetworkManager-main/build/3288936/
> 
> Should we just wait longer and it solves itself?

I bet it depends on whether there was a successful rawhide compose or not.

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: CVE-2021-4034: why is pkexec still a thing?

[Sam Varshavchik]

Lennart Poettering writes:


On Di, 01.02.22 07:14, Sam Varshavchik (mr...@courier-mta.com) wrote:

> Lennart Poettering writes:
>
> > On Mo, 31.01.22 18:32, Sam Varshavchik (mr...@courier-mta.com) wrote:
> >
> > > Lennart Poettering writes:
> > >
> > > > See the discussion around seccomp and NNP. i.e. a new kernel facility
> > > > was added precisely to ensure that seccomp cannot be used to run code
> > > > that is intended to be run privileged – under security policies in
> > > > control by an unprivileged user. i.e. if you can take certain privs
> > > > away from code that expects to have them you might be able to trigger
> > > > vulnerable codepaths that the developer didn't expect you to be able
> > > > to trigger.
> > > >
> > > > But anyway, don't focus so much in cgroups here. There are plenty
> > > > other props these days that sudo doesn#t clean up. consider this for
> > >
> > > Ok, so where's the track record of potential security exploits, in  
similar
> > > kinds of tools, that: 1) leverage any of the resources that you  
mentioned,

> > > and 2) but were mitigated, and became ordinary bugs, thanks to the
> > > vulnerable code being an isolated daemon process, with a clean
> > > environment.
> >
> > I already described you a vulnerability. And the vulnerabilities in
>
> I must've missed those descriptions. Is there a reference somewhere that I
> can read, which describes them.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B2ZCFBIM3AWBUFJKNHGZWPLZZDZPH43Y/

I explained a locking DoS there: run privileged code, but with
extremly restrictive resource scheduling settings, so that it will
acquire privileged resources such as locks (which it can, since it is
privileged) but is extremely slow to give up again since it runs
awfully slow, due to the extremely restrictive resource settings which
are under control of an unpriv caller.


And an isolated process will be capable of rate-limiting itself in this  
situation any better than a sudo process, which could do the same kind of  
rate-limiting itself, exactly how?


About the only thing that works to its advantage is that it'll be in a  
better position to employ rate limiting, by its virtue of being persistent.


But if this is a concern, there's a much better, hybrid approach. The user- 
initiated executable would be a setuid executable that connects to a  
filesystem socket, with the permissions adjusted so that only a privileged  
process can connect to it.


This mitigates resource attacks that establish connections to the persistent  
daemon, and just hold them open, without doing anything. Depending on the  
particulars the setuid executable could do its own sanity checks first,  
before establishing a connection to the persistent daemon, for the next step  
in the process.


The suid bit itself is not a problem. Much like everything else, it is a  
useful tool when used correctly. But just because it is used incorrectly,  
sometimes, doesn't make it bad. And I tend to avoid making an absolute one- 
size-fits-all, blanket assumption on the order of "X is bad". That's a bit  
simplistic, and too naive for my taste. I'd rather take a look at each  
individual situation, on its own merits, and figure out the best solution.


An excellent example would be what happened to OpenSSH. My understanding is  
that they shuffled off all authentication stuff into a separate daemon that  
runs with restricted privileges. This is not quite a good analogue for sudo,  
there is no setuid bit involved here. But this is the right approach:  
analyze the individual situation, and figure out the best solution. For  
OpenSSH it seems to be what they picked to do, which makes a lot of sense.



> > sudo from not cleaning up env vars are pretty well documented, too no?
> > And they are the same kind: not cleaned up context.
>
> A basic search finds the most recent sudo exploit was a heap based buffer
> overflow in sudo about a year ago. Something that can equally happen in an
> isolated process, too, if triggered the same way.

CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646,
CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629,
CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, …

These are all env var cleanup issues in su/sudo context.


Picking a few of them, at random:

CVE-2006-0151: https://bugzilla.redhat.com/show_bug.cgi?id=139478

# Statement for NVD:
#
# If an administrator is concerned that users who have been granted sudo  
# privileges can alter the environment, the existing "env_reset" option should  
# be used which cleans the whole environment.


Mic drop.

CVE-2005-3629: this is initscripts, not sudo, the topic here.

CVE-2008-3825: this is PAM, not sudo.

CVE-2014-9680: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1191144

Looks like env_reset does not reset the TZ variable – that's a bug in that  
option. Going back to the current thought experiment: what if sudo was a  
persistent daemon?

Re: CVE-2021-4034: why is pkexec still a thing?

[Kevin Kofler via devel]

Lennart Poettering wrote:
> CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646,
> CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629,
> CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, …
> 
> These are all env var cleanup issues in su/sudo context.

And the environment variable cleanup (which is uncontestably necessary for 
security (*)) also comes with collateral damage that makes it a bad idea to 
run monolithic GUI programs under such tools, see, e.g.:
https://bugzilla.redhat.com/show_bug.cgi?id=1171779

(*) Now, arguably, the default configuration of pkexec actually does *not*
need the cleanup because it does not allow unprivileged users to run
only selected commands, but both sudo and pkexec can be configured to
allow that, and then you need to prevent the invoker from getting
arbitrary code execution through environment variable hacks.

(Of course, D-Bus-activating those GUI programs will not work either. They 
need to be split into unprivileged GUI and privileged helper(s).)

Kevin Kofler
___
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.1-0.3.fc36 now in rawhide

[Thomas Haller]

On Thu, 2022-01-27 at 14:00 +0100, Thomas Haller wrote:
> On Thu, 2022-01-27 at 11:09 +0100, Jakub Jelinek wrote:
> > On Thu, Jan 27, 2022 at 10:32:22AM +0100, Thomas Haller wrote:
> > > On Wed, 2022-01-26 at 23:57 +0100, Jakub Jelinek wrote:
> > > > A new gcc with most importantly the
> > > > https://gcc.gnu.org/PR104172
> > > > bug (that caused a lot of ppc64le failures) fixed and various
> > > > other
> > > > fixes (e.g. std::basic_string(std::nullptr_t) = deleted only
> > > > done
> > > > for C++23 etc.) is now in rawhide.
> > > > 
> > > > Can rel-eng please retry all FTBS builds that failed on
> > > > ppc64le?
> > > 
> > > it appears to me, that this breaks build of NetworkManager:
> > >    https://koji.fedoraproject.org/koji/taskinfo?taskID=81998774
> > > 
> > > 
> > >   checking if gcc supports flag -fno-strict-aliasing in envvar
> > > CFLAGS... yes
> > >   checking if gcc supports flag -flto -flto-partition=none in
> > > envvar CFLAGS... no
> > >   configure: error: Link Time Optimization -flto is not
> > > supported.
> > >   error: Bad exit status from /var/tmp/rpm-tmp.FQqAFe (%build)
> > 
> > Apparently it was annobin (although it passed the test done during
> > gcc.spec
> > testing, apparently it was incompatible again).
> > Florian has rebuilt it, so please just retry.


Hi,

after a few days, it seems, the problem still exists in the buildroot
for copr:
https://copr.fedorainfracloud.org/coprs/networkmanager/NetworkManager-main/build/3288936/

Should we just wait longer and it solves itself?


best,
Thomas
___
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: the meaning of pkgconfig's Libs fields

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:
> I think Suggests would be OK. Even Recommends seems like too much. You may
> be using clang++ to compile the code, or just accessing headers from
> doxygen, or maybe testing an alternate version of g++ from copr, i.e. with
> a different package name…

Suggests is actually pretty useless though, because nothing (on the consumer 
side) really uses it in Fedora.

> I also think that it doesn't make sense to pull in the compiler from a
> -devel package because you need so many other things: a linker, make or
> ninja, maybe meson/autotoolz/cmake/ant/whatever, so pulling in cmake+g++
> is not enough in some cases and too much in other.

Well, a lot of this used to be part of the default buildroot once upon a 
time, e.g., make was only recently dropped from it. These changes have made 
it harder to build software for Fedora.

In fact, even g++ was once part of the default buildroot, and in fact, one 
of the motivations for adding those Requires: gcc-c++ to some strategic 
-devel packages was to avoid having to add the BuildRequires to hundreds of 
packages.

Kevin Kofler
___
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: conditional require

[Steven A. Falco]

On 1/31/22 06:17 PM, Miro Hrončok wrote:

On 31. 01. 22 23:51, Steven A. Falco wrote:

On 1/31/22 05:08 PM, Steven A. Falco wrote:

On 1/31/22 04:04 PM, Miro Hrončok wrote:

On 31. 01. 22 21:58, przemek klosowski via devel wrote:

During recent major version update, some files were moved from -doc to , 
and as a result updates of  fail due to a file conflict. Manual update of 
-doc resolves this, of course.

A simple solution would be to declare that 

Required: package-doc >= 6.0.0

but that would force the install of the docs package if it wasn't already there.

Is there a way to declare a dependency only if the other package is 
present/installed? Would

Obsoletes: package-doc < 6.0.0

be the right thing to do?


The right thing to do is:

   Conflicts: package-doc < 6.0.0


Ok, so that doesn't do what I'd like.  I definitely added the conflict property:

# rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
kicad-doc < 6.0.0

But when I try to upgrade just the kicad package without upgrading the docs 
package, I still get:

# dnf update kicad-6.0.1-4.fc35.x86_64.rpm
...
Running transaction test
Error: Transaction test error:
   file /usr/share/doc/kicad/scripts/lib_convert.py from install of 
kicad-1:6.0.1-4.fc35.x86_64 conflicts with file from package 
kicad-doc-1:5.1.12-1.fc35.noarch
   file /usr/share/doc/kicad/scripts/test_kicad_plugin.py from install of 
kicad-1:6.0.1-4.fc35.x86_64 conflicts with file from package 
kicad-doc-1:5.1.12-1.fc35.noarch

So the Conflicts line doesn't actually seem to buy me anything.

I'll try again with the version from Stephen Gallagher (including the epoch) 
and see if that is any better.

The Conflict flag is now set to:

# rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
kicad-doc < 1:6.0.1-4.fc35


Oh, I did not know the package has an epoch.


It just has an epoch of "1", and that hasn't changed, so I didn't think it was 
important.  But I guess I was wrong about that. :-(


And the result is:

# dnf update kicad-6.0.1-4.fc35.x86_64.rpm
Last metadata expiration check: 0:40:27 ago on Mon 31 Jan 2022 05:06:19 PM EST.
Dependencies resolved.

  Problem: problem with installed package kicad-doc-1:5.1.12-1.fc35.noarch
   - package kicad-1:6.0.1-4.fc35.x86_64 conflicts with kicad-doc < 
1:6.0.1-4.fc35 provided by kicad-doc-1:5.1.12-1.fc35.noarch
   - cannot install the best update candidate for package 
kicad-1:5.1.12-1.fc35.x86_64

  Package  Architecture  Version Repository   Size

Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
  kicad    x86_64    1:6.0.1-4.fc35 @commandline 90 
M

Transaction Summary

Skip  1 Package

When I add the '--best --allowerasing' flags, then I get the desired result:

# dnf update kicad-6.0.1-4.fc35.x86_64.rpm --best --allowerasing
Last metadata expiration check: 0:43:04 ago on Mon 31 Jan 2022 05:06:19 PM EST.
Dependencies resolved.

  Package    Architecture    Version Repository Size

Upgrading:
  kicad  x86_64  1:6.0.1-4.fc35 @commandline   90 M
Removing dependent packages:
  kicad-doc  noarch  1:5.1.12-1.fc35 @updates  111 M

So that looks like the best solution.


What you haven't mentioned is if kicad-doc 1:6.0.x still exists but just with 
fewer files or if it is gone entirely.
If it is gone, you should probably obsolete it.


The doc package still has many files in it.  So, it should not be obsoleted.

Thanks again for all the help.  I think I'm good now.

Steve
___
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 2048953] perl-GDGraph-1.54-18.fc36 FTBFS: t/bugfixes.t test fails: GD Warning: Cannot open TIFF imagegdImageCreateFromTiff error at /usr/lib64/perl5/vendor_perl/GD/Image.pm line 233

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-GD-2.75-2.fc36
 Resolution|--- |RAWHIDE
Last Closed||2022-02-01 13:46:40



--- Comment #2 from Paul Howarth  ---
Fix worked, merged upstream.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2048953
___
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: Action Required: Bugzilla - API Authentication changes

[Cole Robinson]

On 2/1/22 7:37 AM, Fabio Valentini wrote:
> On Tue, Feb 1, 2022 at 12:37 PM Miro Hrončok  wrote:
>>
>>  Forwarded Message 
>> Subject: [Bugzilla-announce-list] Action Required: Bugzilla - API
>> Authentication changes
>> Date: Tue, 1 Feb 2022 12:28:13 +1000
>> From: Jeff Fearn 
>> To: bugzilla-announce-l...@redhat.com
>>
>> Tl;dr From Monday 28th February, applications making API calls to Bugzilla 
>> may
>> no longer authenticate using passwords or supplying API keys in call
>> parameters. Instead, API keys must be supplied in the Authorization header.
>>
>> Support for using the Authorization header has been deployed to all Red Hat
>> Bugzilla instances. You can change your code at any time and not have to wait
>> for the old methods to be disabled.
>>
>> We will require all authenticated API usage to use this new method; this will
>> break API access to Red Hat Bugzilla for any tools that don't use the
>> Authorization header [1].
>>
>> If you are not certain your tooling authenticates using this header then you
>> need to take action to confirm it does and to modify your tooling to use it 
>> if
>> it doesn't.
>>
>> This new method does away with logging in and out of the API and uses 
>> API_KEYs
>> in a standard Authorization header. This header needs to be sent with every
>> call to the API.
>>
>> The old methods will be disabled on a rolling basis across the RHBZ servers.
>>
>> Target Dates:
>>
>> https://bugzilla.stage.redhat.com - Mon 07th Feb 00:00 UTC
>> https://bugzilla.redhat.com - Mon 28th Feb 00:00 UTC
>>
>> IMPORTANT
>>
>> If you attempt to use an old method to authenticate to the API after this
>> change has been made, the API_KEY or password supplied will be treated as
>> potentially compromised and invalidated immediately. If you supplied your
>> password then you will need to follow the forgot password process to reset 
>> it.
>> If you supplied an API_KEY it will have been banned and you will need to
>> generate a new API_KEY in the UI.
>>
>> This invalidation will happen every time an attempt to use an outdated
>> authentication method is detected.
>>
>> If you are using python-bugzilla you need to upgrade to version 3.2.0 which
>> will automatically use the new method of authentication.
>>
>> If you are using other tools you will need to look into how they work and see
>> how to adjust them to use the Authorization header instead of the other 
>> parameters.
>>
>> If you need assistance understanding how to update your applications, please
>> reach out to us by the following means.
>>
>> - If you have an active subscription via https://access.redhat.com/support/
>>
>> - If you are a Red Hat Partner then please contact your partner 
>> representative
>>
>> - Or email us at bugzilla-ow...@redhat.com
>>
>> The Red Hat Bugzilla Team.
> 
> Hi Miro,
> 
> Thanks for forwarding this announcement.
> Apparently the talk about "improving communication between RHBZ and
> the Fedora Project" has not born fruit yet. ;)
> 

RHBZ devs contacted me twice about this change: once in the fall, which
is when I added support to python-bugzilla git, and once in January
requesting I push a release. crobinso + python-bugzilla != fedora, but
there was some proactive communication

Thanks,
Cole
___
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: Action Required: Bugzilla - API Authentication changes

[Tomasz Torcz]

On Tue, Feb 01, 2022 at 02:25:36PM +0100, Pierre-Yves Chibon wrote:
> On Tue, Feb 01, 2022 at 01:41:01PM +0100, Miro Hrončok wrote:
> > On 01. 02. 22 13:37, Fabio Valentini wrote:
> > > Hi Miro,
> > > 
> > > Thanks for forwarding this announcement.
> > > Apparently the talk about "improving communication between RHBZ and
> > > the Fedora Project" has not born fruit yet. ;)
> > 
> > Well the announcement was public, I recommend subscribing to
> > https://listman.redhat.com/mailman/listinfo/bugzilla-announce-list if you
> > interact with bugzilla a lot.
> > 
> > > Do we know if any of our tools and scripts that interact with RHBZ
> > > will get broken by this?
> > > I assume you have an eye on at least some of the releng scripts (FTI,
> > > FTBFS, etc.).
> > 
> > I will check. I think it's all broken.
> > 
> > > But what about fedora-review? fedora-create-review? The tool that
> > > syncs assignees from dist-git to RHBZ?
> > 
> > No idea.
> 
> Most of these tools are written in python and as the email says, the most 
> recent
> version of python-bugzilla works fine (which is already in Fedora and EPEL -
> stable).
> 
> So as long as your systems are up to date, it should be somewhat transparent.

  abrt-gui on up-to-date Fedora 35 still asks for Username and Password
in Bugzilla configuration panel. No mention of API keys.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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: Action Required: Bugzilla - API Authentication changes

[Pierre-Yves Chibon]

On Tue, Feb 01, 2022 at 01:41:01PM +0100, Miro Hrončok wrote:
> On 01. 02. 22 13:37, Fabio Valentini wrote:
> > Hi Miro,
> > 
> > Thanks for forwarding this announcement.
> > Apparently the talk about "improving communication between RHBZ and
> > the Fedora Project" has not born fruit yet. ;)
> 
> Well the announcement was public, I recommend subscribing to
> https://listman.redhat.com/mailman/listinfo/bugzilla-announce-list if you
> interact with bugzilla a lot.
> 
> > Do we know if any of our tools and scripts that interact with RHBZ
> > will get broken by this?
> > I assume you have an eye on at least some of the releng scripts (FTI,
> > FTBFS, etc.).
> 
> I will check. I think it's all broken.
> 
> > But what about fedora-review? fedora-create-review? The tool that
> > syncs assignees from dist-git to RHBZ?
> 
> No idea.

Most of these tools are written in python and as the email says, the most recent
version of python-bugzilla works fine (which is already in Fedora and EPEL -
stable).

So as long as your systems are up to date, it should be somewhat transparent.


Pierre
___
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 2046802] perl: FTBFS in Fedora rawhide/f36

[bugzilla]

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

Dan Horák  changed:

   What|Removed |Added

 CC|dho...@redhat.com   |d...@danny.cz
 Blocks||1071880 (PPCTracker)





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1071880
[Bug 1071880] (PPCTracker) Fedora for PowerPC architectures (ppc64,ppc64le):
Bug Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2046802
___
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 2048953] perl-GDGraph-1.54-18.fc36 FTBFS: t/bugfixes.t test fails: GD Warning: Cannot open TIFF imagegdImageCreateFromTiff error at /usr/lib64/perl5/vendor_perl/GD/Image.pm line 233

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

   Assignee|spo...@gmail.com|p...@city-fan.org




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2048953
___
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

Action Required: Bugzilla - API Authentication changes

[Miro Hrončok]

 Forwarded Message 
Subject: [Bugzilla-announce-list] Action Required: Bugzilla - API 
Authentication changes

Date: Tue, 1 Feb 2022 12:28:13 +1000
From: Jeff Fearn 
To: bugzilla-announce-l...@redhat.com

Tl;dr From Monday 28th February, applications making API calls to Bugzilla may 
no longer authenticate using passwords or supplying API keys in call 
parameters. Instead, API keys must be supplied in the Authorization header.


Support for using the Authorization header has been deployed to all Red Hat 
Bugzilla instances. You can change your code at any time and not have to wait 
for the old methods to be disabled.


We will require all authenticated API usage to use this new method; this will 
break API access to Red Hat Bugzilla for any tools that don't use the 
Authorization header [1].


If you are not certain your tooling authenticates using this header then you 
need to take action to confirm it does and to modify your tooling to use it if 
it doesn't.


This new method does away with logging in and out of the API and uses API_KEYs 
in a standard Authorization header. This header needs to be sent with every 
call to the API.


The old methods will be disabled on a rolling basis across the RHBZ servers.

Target Dates:

https://bugzilla.stage.redhat.com - Mon 07th Feb 00:00 UTC
https://bugzilla.redhat.com - Mon 28th Feb 00:00 UTC

IMPORTANT

If you attempt to use an old method to authenticate to the API after this 
change has been made, the API_KEY or password supplied will be treated as 
potentially compromised and invalidated immediately. If you supplied your 
password then you will need to follow the forgot password process to reset it. 
If you supplied an API_KEY it will have been banned and you will need to 
generate a new API_KEY in the UI.


This invalidation will happen every time an attempt to use an outdated 
authentication method is detected.


If you are using python-bugzilla you need to upgrade to version 3.2.0 which 
will automatically use the new method of authentication.


If you are using other tools you will need to look into how they work and see 
how to adjust them to use the Authorization header instead of the other parameters.


If you need assistance understanding how to update your applications, please 
reach out to us by the following means.


- If you have an active subscription via https://access.redhat.com/support/

- If you are a Red Hat Partner then please contact your partner representative

- Or email us at bugzilla-ow...@redhat.com

The Red Hat Bugzilla Team.

1: 
https://bugzilla.redhat.com/docs/en/html/api/core/v1/general.html#authentication
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2048953] perl-GDGraph-1.54-18.fc36 FTBFS: t/bugfixes.t test fails: GD Warning: Cannot open TIFF imagegdImageCreateFromTiff error at /usr/lib64/perl5/vendor_perl/GD/Image.pm line 233

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
  Component|perl-GDGraph|perl-GD
Link ID||Github
   ||lstein/Perl-GD/pull/43 CPAN
   ||140910



--- Comment #1 from Paul Howarth  ---
Should be fixed with perl-GD-2.75-2.fc36.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2048953
___
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: CVE-2021-4034: why is pkexec still a thing?

[Lennart Poettering]

On Di, 01.02.22 07:14, Sam Varshavchik (mr...@courier-mta.com) wrote:

> Lennart Poettering writes:
>
> > On Mo, 31.01.22 18:32, Sam Varshavchik (mr...@courier-mta.com) wrote:
> >
> > > Lennart Poettering writes:
> > >
> > > > See the discussion around seccomp and NNP. i.e. a new kernel facility
> > > > was added precisely to ensure that seccomp cannot be used to run code
> > > > that is intended to be run privileged – under security policies in
> > > > control by an unprivileged user. i.e. if you can take certain privs
> > > > away from code that expects to have them you might be able to trigger
> > > > vulnerable codepaths that the developer didn't expect you to be able
> > > > to trigger.
> > > >
> > > > But anyway, don't focus so much in cgroups here. There are plenty
> > > > other props these days that sudo doesn#t clean up. consider this for
> > >
> > > Ok, so where's the track record of potential security exploits, in similar
> > > kinds of tools, that: 1) leverage any of the resources that you mentioned,
> > > and 2) but were mitigated, and became ordinary bugs, thanks to the
> > > vulnerable code being an isolated daemon process, with a clean
> > > environment.
> >
> > I already described you a vulnerability. And the vulnerabilities in
>
> I must've missed those descriptions. Is there a reference somewhere that I
> can read, which describes them.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B2ZCFBIM3AWBUFJKNHGZWPLZZDZPH43Y/

I explained a locking DoS there: run privileged code, but with
extremly restrictive resource scheduling settings, so that it will
acquire privileged resources such as locks (which it can, since it is
privileged) but is extremely slow to give up again since it runs
awfully slow, due to the extremely restrictive resource settings which
are under control of an unpriv caller.

> > sudo from not cleaning up env vars are pretty well documented, too no?
> > And they are the same kind: not cleaned up context.
>
> A basic search finds the most recent sudo exploit was a heap based buffer
> overflow in sudo about a year ago. Something that can equally happen in an
> isolated process, too, if triggered the same way.

CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646,
CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629,
CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, …

These are all env var cleanup issues in su/sudo context.

Lennart

--
Lennart Poettering, Berlin
___
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: Uninitialized variables and F37

[Jonathan Wakely]

On Tue, 1 Feb 2022 at 12:03, Florian Weimer  wrote:
>
> * Jonathan Wakely:
>
> > Vitaly, it looks like you didn't respond to this. I'm also curious why
> > this change would lead to crashes. Are we missing something?
>
> I've seen cases where access to uninitialized data was fine as long as
> the memory location was never zero, something that was always true for
> how GCC compiled the program at the time.

Ah, so uninitialized pointers that were non-zero, and so reading from
some arbitrary mapped page. If the pointer gets initialized to zero
reading from it would be a segfault, because the zero page isn't
mapped.

That seems like an improvement, and worth finding and fixing the code.
"Maintainers should not have to fix bugs in their packages" seems like
a totally bogus argument to me.

>
> But I most say that I find the other direction more likely (as in, the
> program is fine because it works correctly on Fedora).
___
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: Announcing LLVM Snapshot Packages for Fedora Linux

[Konrad Kleine]

Davide,

thank you for your interest in this. May I ask what plans you have using it
for? We're investigating an integration into CentOS Stream.

Regards
Konrad




On Thu, 27 Jan 2022 at 17:55, Davide Cavalca via devel <
devel@lists.fedoraproject.org> wrote:

> On Fri, 2021-10-08 at 12:13 +0200, Konrad Kleine wrote:
> > Dear Fedora packagers, developers and users,
> >
> > we have some good news for you:
> >
> > We are beginning to build nightly snapshot packages of LLVM for the
> > latest
> > versions of Fedora Linux (currently 34, 35 and rawhide) for a growing
> > list of
> > architectures.
> >
> > You can grab them here:
> >
> >
> https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/
>
> This is excellent, thanks for putting it together! Would you be open to
> adding builds for EPEL and CentOS Stream? I saw some preliminary work
> in that direction in
>
> https://github.com/kwk/llvm-daily-fedora-rpms/commit/cc9d02dc300aeed583ccda960e7eb16962686e33
> but it was later reverted. I'd be happy to help with testing that if
> needed (also adding the EPEL list in case other folks are interested).
>
> Cheers
> Davide
> ___
> 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: Action Required: Bugzilla - API Authentication changes

[Miro Hrončok]

On 01. 02. 22 13:37, Fabio Valentini wrote:

Hi Miro,

Thanks for forwarding this announcement.
Apparently the talk about "improving communication between RHBZ and
the Fedora Project" has not born fruit yet. ;)


Well the announcement was public, I recommend subscribing to 
https://listman.redhat.com/mailman/listinfo/bugzilla-announce-list if you 
interact with bugzilla a lot.



Do we know if any of our tools and scripts that interact with RHBZ
will get broken by this?
I assume you have an eye on at least some of the releng scripts (FTI,
FTBFS, etc.).


I will check. I think it's all broken.


But what about fedora-review? fedora-create-review? The tool that
syncs assignees from dist-git to RHBZ?


No idea.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Action Required: Bugzilla - API Authentication changes

[Fabio Valentini]

On Tue, Feb 1, 2022 at 12:37 PM Miro Hrončok  wrote:
>
>  Forwarded Message 
> Subject: [Bugzilla-announce-list] Action Required: Bugzilla - API
> Authentication changes
> Date: Tue, 1 Feb 2022 12:28:13 +1000
> From: Jeff Fearn 
> To: bugzilla-announce-l...@redhat.com
>
> Tl;dr From Monday 28th February, applications making API calls to Bugzilla may
> no longer authenticate using passwords or supplying API keys in call
> parameters. Instead, API keys must be supplied in the Authorization header.
>
> Support for using the Authorization header has been deployed to all Red Hat
> Bugzilla instances. You can change your code at any time and not have to wait
> for the old methods to be disabled.
>
> We will require all authenticated API usage to use this new method; this will
> break API access to Red Hat Bugzilla for any tools that don't use the
> Authorization header [1].
>
> If you are not certain your tooling authenticates using this header then you
> need to take action to confirm it does and to modify your tooling to use it if
> it doesn't.
>
> This new method does away with logging in and out of the API and uses API_KEYs
> in a standard Authorization header. This header needs to be sent with every
> call to the API.
>
> The old methods will be disabled on a rolling basis across the RHBZ servers.
>
> Target Dates:
>
> https://bugzilla.stage.redhat.com - Mon 07th Feb 00:00 UTC
> https://bugzilla.redhat.com - Mon 28th Feb 00:00 UTC
>
> IMPORTANT
>
> If you attempt to use an old method to authenticate to the API after this
> change has been made, the API_KEY or password supplied will be treated as
> potentially compromised and invalidated immediately. If you supplied your
> password then you will need to follow the forgot password process to reset it.
> If you supplied an API_KEY it will have been banned and you will need to
> generate a new API_KEY in the UI.
>
> This invalidation will happen every time an attempt to use an outdated
> authentication method is detected.
>
> If you are using python-bugzilla you need to upgrade to version 3.2.0 which
> will automatically use the new method of authentication.
>
> If you are using other tools you will need to look into how they work and see
> how to adjust them to use the Authorization header instead of the other 
> parameters.
>
> If you need assistance understanding how to update your applications, please
> reach out to us by the following means.
>
> - If you have an active subscription via https://access.redhat.com/support/
>
> - If you are a Red Hat Partner then please contact your partner representative
>
> - Or email us at bugzilla-ow...@redhat.com
>
> The Red Hat Bugzilla Team.

Hi Miro,

Thanks for forwarding this announcement.
Apparently the talk about "improving communication between RHBZ and
the Fedora Project" has not born fruit yet. ;)

Do we know if any of our tools and scripts that interact with RHBZ
will get broken by this?
I assume you have an eye on at least some of the releng scripts (FTI,
FTBFS, etc.).
But what about fedora-review? fedora-create-review? The tool that
syncs assignees from dist-git to RHBZ?

Fabio
___
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: Announcing LLVM Snapshot Packages for Fedora Linux

[José Abílio Matos]

On Tuesday, 1 February 2022 11.54.01 WET Jonathan Wakely wrote:
> Which is also mentioned at https://jwakely.github.io/pkg-gcc-latest/
> so I've added a link to that page from the copr description.

Thank you.
That answered all my questions (regarding this issue :-) ).

Regards,
-- 
José Abílio

___
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: CVE-2021-4034: why is pkexec still a thing?

[Sam Varshavchik]

Lennart Poettering writes:


On Mo, 31.01.22 18:32, Sam Varshavchik (mr...@courier-mta.com) wrote:

> Lennart Poettering writes:
>
> > See the discussion around seccomp and NNP. i.e. a new kernel facility
> > was added precisely to ensure that seccomp cannot be used to run code
> > that is intended to be run privileged – under security policies in
> > control by an unprivileged user. i.e. if you can take certain privs
> > away from code that expects to have them you might be able to trigger
> > vulnerable codepaths that the developer didn't expect you to be able
> > to trigger.
> >
> > But anyway, don't focus so much in cgroups here. There are plenty
> > other props these days that sudo doesn#t clean up. consider this for
>
> Ok, so where's the track record of potential security exploits, in similar
> kinds of tools, that: 1) leverage any of the resources that you mentioned,
> and 2) but were mitigated, and became ordinary bugs, thanks to the
> vulnerable code being an isolated daemon process, with a clean
> environment.

I already described you a vulnerability. And the vulnerabilities in


I must've missed those descriptions. Is there a reference somewhere that I  
can read, which describes them.



sudo from not cleaning up env vars are pretty well documented, too no?
And they are the same kind: not cleaned up context.


A basic search finds the most recent sudo exploit was a heap based buffer  
overflow in sudo about a year ago. Something that can equally happen in an  
isolated process, too, if triggered the same way.


A more careful search located the sudo exploit you described, from 2014,  
CVE-2014-0106. I couldn't find anything similar in sudo's history, so this  
must be what you are referring to. Looks like it was in a non-default  
configuration, and after reading up the details of the exploit:


The only argument I see here, is that if the isolated process-based  
implementation of an sudo-alternative did not implement the non-env_reset  
option in the first place. If it did implement the non-env_reset related  
option, presumably there would've been some mechanism for the client to  
transmit its environment to the isolated process, for the benefit of the  
spawned subshell.


And it that turned out to be the case, the same exact bug would've happened.  
The process isolation would not've accomplished anything, here. The problem  
was not inherent with an suid-based approach. sudo had a broken  
implemenation of an optional configuration setting. If it was broken in the  
same way, in an isolated process, the lack of the setuid bit would not've  
made any material difference.




pgpZwrbUzSEPJ.pgp
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

Re: Uninitialized variables and F37

[Florian Weimer]

* Jonathan Wakely:

> Vitaly, it looks like you didn't respond to this. I'm also curious why
> this change would lead to crashes. Are we missing something?

I've seen cases where access to uninitialized data was fine as long as
the memory location was never zero, something that was always true for
how GCC compiled the program at the time.

But I most say that I find the other direction more likely (as in, the
program is fine because it works correctly on Fedora).

Thanks,
Florian
___
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: Announcing LLVM Snapshot Packages for Fedora Linux

[Jonathan Wakely]

On Tue, 1 Feb 2022 at 11:25, Jonathan Wakely  wrote:
>
> On Thu, 27 Jan 2022 at 16:29, José Abílio Matos  wrote:
> >
> > On Thursday, 27 January 2022 16.14.36 WET José Abílio Matos wrote:
> >
> > > $ src/lyx
> >
> > >
> >
> > > [1] 61542
> >
> > >
> >
> > > src/lyx: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found 
> > > (required
> >
> > > by src/lyx)
> >
> > >
> >
> > >
> >
> > > Any help here?
> >
> >
> > OK, one option is set the linker path
> >
> > $ LD_LIBRARY_PATH=/opt/gcc-latest/lib64/ src/lyx
>
> See the docs: 
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic

Which is also mentioned at https://jwakely.github.io/pkg-gcc-latest/
so I've added a link to that page from the copr description.
___
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

Action Required: Bugzilla - API Authentication changes

[Miro Hrončok]

 Forwarded Message 
Subject: [Bugzilla-announce-list] Action Required: Bugzilla - API 
Authentication changes

Date: Tue, 1 Feb 2022 12:28:13 +1000
From: Jeff Fearn 
To: bugzilla-announce-l...@redhat.com

Tl;dr From Monday 28th February, applications making API calls to Bugzilla may 
no longer authenticate using passwords or supplying API keys in call 
parameters. Instead, API keys must be supplied in the Authorization header.


Support for using the Authorization header has been deployed to all Red Hat 
Bugzilla instances. You can change your code at any time and not have to wait 
for the old methods to be disabled.


We will require all authenticated API usage to use this new method; this will 
break API access to Red Hat Bugzilla for any tools that don't use the 
Authorization header [1].


If you are not certain your tooling authenticates using this header then you 
need to take action to confirm it does and to modify your tooling to use it if 
it doesn't.


This new method does away with logging in and out of the API and uses API_KEYs 
in a standard Authorization header. This header needs to be sent with every 
call to the API.


The old methods will be disabled on a rolling basis across the RHBZ servers.

Target Dates:

https://bugzilla.stage.redhat.com - Mon 07th Feb 00:00 UTC
https://bugzilla.redhat.com - Mon 28th Feb 00:00 UTC

IMPORTANT

If you attempt to use an old method to authenticate to the API after this 
change has been made, the API_KEY or password supplied will be treated as 
potentially compromised and invalidated immediately. If you supplied your 
password then you will need to follow the forgot password process to reset it. 
If you supplied an API_KEY it will have been banned and you will need to 
generate a new API_KEY in the UI.


This invalidation will happen every time an attempt to use an outdated 
authentication method is detected.


If you are using python-bugzilla you need to upgrade to version 3.2.0 which 
will automatically use the new method of authentication.


If you are using other tools you will need to look into how they work and see 
how to adjust them to use the Authorization header instead of the other parameters.


If you need assistance understanding how to update your applications, please 
reach out to us by the following means.


- If you have an active subscription via https://access.redhat.com/support/

- If you are a Red Hat Partner then please contact your partner representative

- Or email us at bugzilla-ow...@redhat.com

The Red Hat Bugzilla Team.

1: 
https://bugzilla.redhat.com/docs/en/html/api/core/v1/general.html#authentication
___
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: Announcing LLVM Snapshot Packages for Fedora Linux

[Jonathan Wakely]

On Thu, 27 Jan 2022 at 16:29, José Abílio Matos  wrote:
>
> On Thursday, 27 January 2022 16.14.36 WET José Abílio Matos wrote:
>
> > $ src/lyx
>
> >
>
> > [1] 61542
>
> >
>
> > src/lyx: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required
>
> > by src/lyx)
>
> >
>
> >
>
> > Any help here?
>
>
> OK, one option is set the linker path
>
> $ LD_LIBRARY_PATH=/opt/gcc-latest/lib64/ src/lyx

See the docs: 
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic
___
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: Uninitialized variables and F37

[Jonathan Wakely]

On Sat, 22 Jan 2022 at 14:58, Richard W.M. Jones wrote:
>
> On Sat, Jan 22, 2022 at 12:36:01PM +0100, Vitaly Zaitsev via devel wrote:
> > On 21/01/2022 19:04, Steve Grubb wrote:
> > >Uninitialized variables are a big problem.
> >
> > Yes, but as a package maintainer, I don't want to deal with dozens
> > of crashes after this change.
> >
> > Such problems must be fixed by upstream developers, not by
> > volunteers [package maintainers].
> >
> > Most upstreams will close such bug reports with "Fedora specific
> > issue" reason, as it was with GLIB assertions. I've manually fixed
> > many of them in my packages.
>
> I'm curious here how you think programs could crash with the proposed
> changes.

Vitaly, it looks like you didn't respond to this. I'm also curious why
this change would lead to crashes. Are we missing something?
___
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: Uninitialized variables and F37

[Jonathan Wakely]

On Fri, 28 Jan 2022 at 16:40, Steve Grubb  wrote:
>
> >> Of course gcc -fsanitize=undefined cannot be used on production code.
> >
> > Why not? Will it find too many errors?
>
> This discussion is at least 5 years old:
>
> https://seclists.org/oss-sec/2016/q1/363
>
> I don't know if the problems have been addressed or if new problems have
> popped up. The short of it, if you don't read the link above, is that you can
> use the _OPTIONS environmental variable with a setuid application and clobber
> any file on the file system.

(That's about ASan, but UBSAN_OPTIONS will do the same.)

It's worth noting that -fsanitize=undefined
-fsanitize-undefined-trap-on-error doesn't use UBSAN_OPTIONS and
doesn't require libubsan.so. With the trap-on-error option you just
get a crash instead of a user-friendly description of the error, but
it does still check for UB and halt the process when it's detected.
___
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: hdf5 fortran build failure with gcc 12

[Dave Love]

Orion Poplawski  writes:

> On 1/29/22 19:40, Mamoru TASAKA wrote:

>> Looks like "minusone" variable looking like constant value defined
>> in
>> fortran/test/tH5A_1_8.F90 needs PARAMETER attribute. Tried this diff:
>> ```
>> diff --git a/hdf5.spec b/hdf5.spec
>> index 3b1d27b..2bac44d 100644
>> --- a/hdf5.spec
>> +++ b/hdf5.spec
>> @@ -187,6 +187,8 @@ autoreconf -f -i
>>   # Modify low optimization level for gnu compilers
>>   sed -e 's|-O -finline-functions|-O3 -finline-functions|g' -i
>> config/gnu-flags
>> +sed -i fortran/test/tH5A_1_8.F90 -e 's|INTEGER :: minusone|INTEGER, 
>> PARAMETER :: minusone|'
>> +
>>   %build
>>   #Do out of tree builds
>>   %global _configure ../configure
>> ```
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=82124997
>> Unfortunately ppc64le %check fails, looking like long double
>> related,
>> which I believe is related to recent gcc default change to
>> -mabi=ieeelongdouble on ppc64le,
>> however I don't know how to fix this.
>
> Thank you!  I've passed that on to upstream.

I'm no longer a language lawyer, but it looks to me as if it should be
reported as a GCC bug.  Is there something in the standard which says
the code is invalid?
___
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

Fedora-Cloud-34-20220201.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20220131.0):

ID: 1116946 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1116946
ID: 1116954 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1116954

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: the meaning of pkgconfig's Libs fields

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jan 31, 2022 at 08:57:45PM +0100, Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > Well, that is the reverse of how we do things in general. If I want to
> > look for libraries using pkg-config, I install pkg-config. If I want
> > to look for libraries using 'gcc test.c -lfoo', then I install gcc.
> >
> > What we have now is like saying that .h files should depend on gcc
> > because you use gcc to consume them.
> 
> Several KDE -devel packages do require cmake and even g++ though. The idea 
> is that you will normally need CMake and g++ to build anything against that 
> -devel package.

I think Suggests would be OK. Even Recommends seems like too much. You may
be using clang++ to compile the code, or just accessing headers from doxygen,
or maybe testing an alternate version of g++ from copr, i.e. with a different
package name…

I also think that it doesn't make sense to pull in the compiler from a -devel
package because you need so many other things: a linker, make or ninja,
maybe meson/autotoolz/cmake/ant/whatever, so pulling in cmake+g++ is
not enough in some cases and too much in other.

> That said, for CMake, this is not currently part of the AutoRequires, that 
> only drags in cmake-filesystem for directory ownership (and in fact, I guess 
> directory ownership is a reason for the pkg-config AutoRequires too), any 
> Requires: cmake is manually added.

Zbyszek
___
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 2048963] Add perl-Cache-LRU to EPEL9

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/41634


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2048963
___
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: Weirdness with clang and stdatomic.h on Rawhide

[Jonathan Wakely]

On Tue, 1 Feb 2022 at 09:15, Jonathan Wakely  wrote:
>
> On Mon, 31 Jan 2022 at 22:45, Ron Olson  wrote:
> >
> > Hey all,
> >
> > I’m troubleshooting an issue and came up with this sample program: 
> > https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 
> > 13, on Rawhide, won’t compile that program, while on Fedora 35 it does.
> >
> > The reason why is that on Rawhide, stdatomic.h exists under 
> > /usr/include/c++/12 while it does not exist on 35, so clang uses its 
> > built-in stdatomic per 
> > https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations.
>
> But that's about C, not C++.
>
> >If it uses its internal version, the sample program compiles fine.
> >
> > Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > 
> > 202002L”, so that means C++2b or later, not C++20. This seems to create a 
> > problem for clang which, since the file is present, wants to use it, but 
> > since it’s effectively empty due to the #ifdef, compiling of the sample 
> > program fails.
> >
> > Is it possible to disable clang’s use of the header file as a flag? I’ve 
> > been unable to find anything like that, and obviously renaming the header 
> > is out of the question.  Also, is it correct to the setting stdatomic.h to 
> > only be used by c++2b?
>
> Yes, that's 100% correct.
>
> Clang is at fault here.  does not exist in C++ up to and
> including the current C++20 standard, so Clang should not assume it's
> present or usable.
>
> In C++23 there is now a  header in the C++ library for
> compatibility. That's what I added to GCC, and that's what Clang is
> now picking up.
>
> Why is C++ code in Clang using a C header that isn't part of C++?

I think I misread, this isn't code in Clang, this is your code and
you're just using Clang, right?

So then you can fix your code fairly easily.
___
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: Weirdness with clang and stdatomic.h on Rawhide

[Jonathan Wakely]

On Tue, 1 Feb 2022 at 09:15, Jonathan Wakely  wrote:
>
> On Mon, 31 Jan 2022 at 22:45, Ron Olson  wrote:
> >
> > Hey all,
> >
> > I’m troubleshooting an issue and came up with this sample program: 
> > https://pastebin.com/g9S8Z64q to demonstrate the problem.

That's not a valid C++ program, even in C++23 after  is added.

For C++23 it needs to be _Atomic(int) because in C++ _Atomic is not a
type qualifier (unlike in C). Clang supports the _Atomic qualifier in
C++ mode, but that's non-standard.

This code is not portable to any compiler except Clang, and is no
longer even portable to Clang when using G++ in C++23 mode.

I suppose we could enable the contents of  for the
non-strict -std=gnu++XX modes before C++23, but you'd still need to
adjust your program to use _Atomic(int) instead of _Atomic int.

Why not just write it in proper C++, using std::atomic or the
atomic_int typedef instead?
___
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