Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-25 Thread Jaroslav Mracek
> Hi
> 
> 
> On Tue, Oct 25, 2022 at 7:14 AM Jaroslav Mracek wrote:
> 
> 
> This response really doesn't clarify what the end result is supposed to be.
>   Are you planning to maintain a symlink from DNF and Yum to DNF5 after the
> transition is complete or not?
> 
> Rahul

Yes, we have a plan to maintain symlinks to `/user/bin/` + ` dnf` or `microdnf` 
or `yum`.

Jaroslav
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)

2022-10-25 Thread Panu Matilainen

On 10/24/22 23:23, Petr Menšík wrote:

Hi, maybe it was already answered.

Not long ago Thunderbird switched from using installed GPG to its own 
implementation inside. I think I have found the library part and it 
seems to be in C++, which should be much more easier to integrate than 
rust libraries.


I think the project link is:

https://github.com/rnpgp/rnp

Wouldn't it solve the problems cause in more compatible way? Is has 
relatively recent release, so it does not seem abandoned. Is there a 
specific reason, why is a Rust implementation chosen instead? 


Yes it was already answered, see

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

and

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

We would've, *of course*, gone for something C-nativeish if that had 
been an option at all. As I said in some other post in this thread, I've 
been on the lookout for a viable C-native option for 15+ years. Yet here 
we are.


And as I've also said elsewhere in this thread, the plan is to keep the 
options open for the future. I don't like the shotgun marriage to Rust 
any more than the next person out there.



I like Rust language, but its integration into a core system
component does not seem easy.


Except for the matter of bootstrap dependencies (which has also been 
discussed here already), I don't know what the difficulty in this case 
is supposed to be.


- Panu
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Steam install bug

2022-10-25 Thread Samuel Sieb

On 10/25/22 21:47, Reon Beon via devel wrote:

They are up to date: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6451


You said it installs fine, so what's the bug?
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Steam install bug

2022-10-25 Thread Reon Beon via devel
They are up to date: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6451
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Steam install bug

2022-10-25 Thread Samuel Sieb

On 10/25/22 19:41, Reon Beon via devel wrote:

Can not download xz-libs.

https://ibb.co/cQPHXQw


Sounds like a not up-to-date mirror or stale metadata.  Did you modify 
your repo config?

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Mailman3 on Fedora 36

2022-10-25 Thread Reon Beon via devel
Subscribe.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Mailman3 on Fedora 36

2022-10-25 Thread Reon Beon via devel
Interesting, thanks.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Steam install bug

2022-10-25 Thread Reon Beon via devel
Can not download xz-libs.

https://ibb.co/cQPHXQw
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Stephen Gallagher
...
> > Concretely, as an upstream  maintainer, what should they do to test
> > the behaviour of their code ?  Is there more to it than just
> > setting CFLAGS="-std=gnu99", if they want to validate this in their
> > upstream CI ahead of GCC 14 arriving ?
>
> It's -Werror=implicit-int -Werror=implicit-function-declaration.  Best
> to throw in -Werror=int-conversion -Werror=strict-prototypes
> -Werror=old-style-definition.  -Werror=int-conversion should really be a
> no-brainer, the other two are about the removal of old-style function
> definitions and declarations that are not prototypes from C2X (also
> mentioned in the proposal).  I can probably spell this out in the
> proposal.

Even better: could you put together an RPM macro we can use in
specfiles to essentially opt-in early to the F40 Change?
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137694] New: perl-experimental-0.029 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137694

Bug ID: 2137694
   Summary: perl-experimental-0.029 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-experimental
  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



Releases retrieved: 0.029
Upstream release that is considered latest: 0.029
Current version/release in rawhide: 0.028-489.fc37
URL: http://search.cpan.org/dist/experimental/

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://docs.fedoraproject.org/en-US/package-maintainers/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/2857/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-experimental


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137694
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F39 proposal: Python 3.12 (System-Wide Change proposal)

2022-10-25 Thread Miro Hrončok

On 25. 10. 22 23:10, Maxwell G via devel wrote:

On Tue Oct 25, 2022 at 15:46 -0400, Ben Cotton wrote:

* 2023-07-17: Expected side tag-merge (pessimistic)
* 2023-07-19: Fedora 39 Mass Rebuild
** The mass rebuild happens with the fourth beta. We might need to
rebuild Python packages later in exceptional case.
** If the Koji side-tag is not merged yet at this point, we defer the
change to Fedora 38.


Should this be Fedora 40?


Yes. Amended.

--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F39 proposal: Python 3.12 (System-Wide Change proposal)

2022-10-25 Thread Maxwell G via devel
On Tue Oct 25, 2022 at 15:46 -0400, Ben Cotton wrote:
> * 2023-07-17: Expected side tag-merge (pessimistic)
> * 2023-07-19: Fedora 39 Mass Rebuild
> ** The mass rebuild happens with the fourth beta. We might need to
> rebuild Python packages later in exceptional case.
> ** If the Koji side-tag is not merged yet at this point, we defer the
> change to Fedora 38.

Should this be Fedora 40?

--
Maxwell G (@gotmax23)
Pronouns: He/Him/His


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137675] New: perl-PDL-2.081 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137675

Bug ID: 2137675
   Summary: perl-PDL-2.081 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PDL
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com,
jakub.jedel...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com, tjczep...@gmail.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 2.081
Upstream release that is considered latest: 2.081
Current version/release in rawhide: 2.80.0-4.fc38
URL: http://search.cpan.org/dist/PDL/

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://docs.fedoraproject.org/en-US/package-maintainers/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/3205/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-PDL


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137675
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


F39 proposal: Python 3.12 (System-Wide Change proposal)

2022-10-25 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/Python3.12

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Update the Python stack in Fedora from Python 3.11 to Python 3.12, the
newest major release of the Python programming language.

== Owner ==
* Name: [[User:Thrnciar|Tomáš Hrnčiar]]
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: python-ma...@redhat.com


== Detailed Description ==
We would like to upgrade Python to 3.12 in Fedora 39 thus we are
proposing this plan early.

See the upstream notes at
[https://peps.python.org/pep-0693/#features-for-3-12 Features for
3.12] and [https://docs.python.org/3.12/whatsnew/3.12.html What's new
in 3.12].

=== Important dates and plan ===

* 2022-05-08: Python 3.12 development begins
* 2022-10-24: Python 3.12.0 alpha 1
** Package it as {{package|python3.12}} for testing purposes
** Start the bootstrap procedure in Copr
** Do a mass rebuild against every future release in Copr
* 2022-11-14: Python 3.12.0 alpha 2
* 2022-12-05: Python 3.12.0 alpha 3
* 2023-01-09: Python 3.12.0 alpha 4
* 2023-02-06: Python 3.12.0 alpha 5
* 2023-02-07: Branch Fedora 38, Rawhide becomes future Fedora 39
** The earliest point when we can start rebuilding in Koji side-tag
* 2023-03-06: Python 3.12.0 alpha 6
* 2023-04-03: Python 3.12.0 alpha 7
* 2023-05-08: Python 3.12.0 beta 1
** No new features beyond this point
* 2023-05-29: Python 3.12.0 beta 2
** The ideal point when we can start rebuilding in Koji
* 2023-06-05: Expected side tag-merge (optimistic)
* 2023-06-19: Python 3.12.0 beta 3
* 2023-06-26: Expected side tag-merge (realistic)
* 2023-07-10: Python 3.12.0 beta 4
* 2023-07-17: Expected side tag-merge (pessimistic)
* 2023-07-19: Fedora 39 Mass Rebuild
** The mass rebuild happens with the fourth beta. We might need to
rebuild Python packages later in exceptional case.
** If the Koji side-tag is not merged yet at this point, we defer the
change to Fedora 38.
* 2023-07-31: Python 3.12.0 candidate 1
** This serves as "final" for our purposes.
* 2023-08-08: Branch Fedora 39, Rawhide becomes future Fedora 40
* 2023-08-08: Fedora 39 Change Checkpoint: Completion deadline (testable)
* 2023-08-22: Fedora Beta Freeze
** If rebuild with 3.12.0rc1 is needed, we should strive to do it
before the freeze - there is a window of 3 weeks.
* 2023-09-04: Python 3.12.0 candidate 2
* 2023-09-12: Fedora 39 Beta Release (Preferred Target)
** Beta will likely be released with 3.12.0rc2.
* 2023-09-19: Fedora 39 Beta Target date #1
* 2023-10-02: Python 3.12.0 final
* 2023-10-03: Fedora 39 Final Freeze
** We'll update to 3.12.0 final using a freeze exception.
* 2023-10-17: Fedora 39 Preferred Final Target date
* 2023-10-24: Fedora 39 Final Target date #1


(From [https://peps.python.org/pep-0693/#release-schedule Python 3.12
Release Schedule] and
[https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
Fedora 39 Release Schedule].)

The schedule might appear somewhat tight for Fedora 39, but Python's
[https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/AKA3USBKFYKUQDSGDK4FNDYYWMKM7XKX/
annual release cycle was adapted for Fedora] and this worked fine
since Python 3.9 and Fedora 33. It is now common that Python is
upgraded on a similar schedule in every odd-numbered Fedora release.

Note that upstream's "release candidates" are frozen except for
blocker bugs. Since we can and will backport blocker fixes between
Fedora and upstream, we essentially treat the Release Candidate as the
final release.

=== Notes from the previous upgrade ===

There are notes from the previous upgrade available, so this upgrade
may go smoother: [[SIGs/Python/UpgradingPython]]

== Benefit to Fedora ==

Fedora aims to showcase the latest in free and open-source software -
we should have the most recent release of Python 3. Packages in Fedora
can use the new features from 3.12.

There's also a benefit to the larger Python ecosystem: by building
Fedora's packages against 3.12 while it's still in development, we can
catch critical bugs before the final 3.12.0 release.

== Scope ==

We will coordinate the work in a side tag and merge when ready.

* Proposal owners:
*# Introduce {{package|python3.12}} for all Fedoras
*# Prepare stuff in Copr as explained in description.
*# Update {{package|python-rpm-macros}} so {{package|python3.12}}
builds {{package|python3}}
*# Build {{package|python3.12}} as the main Python
*# Mass rebuild all the packages that runtime require `python(abi) =
3.11` and/or `libpython3.11.so.1.0` (~3900 known packages in October
2022)
*# Build {{package|python3.12}} as a non-main Python

* Other developers: Maintainers of packages that fail to rebuild
during the rebuilds will be asked, using e-mail and bugzilla, to fix
or remove their packages from the distribution. If any issues 

F39 proposal: Python 3.12 (System-Wide Change proposal)

2022-10-25 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/Python3.12

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Update the Python stack in Fedora from Python 3.11 to Python 3.12, the
newest major release of the Python programming language.

== Owner ==
* Name: [[User:Thrnciar|Tomáš Hrnčiar]]
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: python-ma...@redhat.com


== Detailed Description ==
We would like to upgrade Python to 3.12 in Fedora 39 thus we are
proposing this plan early.

See the upstream notes at
[https://peps.python.org/pep-0693/#features-for-3-12 Features for
3.12] and [https://docs.python.org/3.12/whatsnew/3.12.html What's new
in 3.12].

=== Important dates and plan ===

* 2022-05-08: Python 3.12 development begins
* 2022-10-24: Python 3.12.0 alpha 1
** Package it as {{package|python3.12}} for testing purposes
** Start the bootstrap procedure in Copr
** Do a mass rebuild against every future release in Copr
* 2022-11-14: Python 3.12.0 alpha 2
* 2022-12-05: Python 3.12.0 alpha 3
* 2023-01-09: Python 3.12.0 alpha 4
* 2023-02-06: Python 3.12.0 alpha 5
* 2023-02-07: Branch Fedora 38, Rawhide becomes future Fedora 39
** The earliest point when we can start rebuilding in Koji side-tag
* 2023-03-06: Python 3.12.0 alpha 6
* 2023-04-03: Python 3.12.0 alpha 7
* 2023-05-08: Python 3.12.0 beta 1
** No new features beyond this point
* 2023-05-29: Python 3.12.0 beta 2
** The ideal point when we can start rebuilding in Koji
* 2023-06-05: Expected side tag-merge (optimistic)
* 2023-06-19: Python 3.12.0 beta 3
* 2023-06-26: Expected side tag-merge (realistic)
* 2023-07-10: Python 3.12.0 beta 4
* 2023-07-17: Expected side tag-merge (pessimistic)
* 2023-07-19: Fedora 39 Mass Rebuild
** The mass rebuild happens with the fourth beta. We might need to
rebuild Python packages later in exceptional case.
** If the Koji side-tag is not merged yet at this point, we defer the
change to Fedora 38.
* 2023-07-31: Python 3.12.0 candidate 1
** This serves as "final" for our purposes.
* 2023-08-08: Branch Fedora 39, Rawhide becomes future Fedora 40
* 2023-08-08: Fedora 39 Change Checkpoint: Completion deadline (testable)
* 2023-08-22: Fedora Beta Freeze
** If rebuild with 3.12.0rc1 is needed, we should strive to do it
before the freeze - there is a window of 3 weeks.
* 2023-09-04: Python 3.12.0 candidate 2
* 2023-09-12: Fedora 39 Beta Release (Preferred Target)
** Beta will likely be released with 3.12.0rc2.
* 2023-09-19: Fedora 39 Beta Target date #1
* 2023-10-02: Python 3.12.0 final
* 2023-10-03: Fedora 39 Final Freeze
** We'll update to 3.12.0 final using a freeze exception.
* 2023-10-17: Fedora 39 Preferred Final Target date
* 2023-10-24: Fedora 39 Final Target date #1


(From [https://peps.python.org/pep-0693/#release-schedule Python 3.12
Release Schedule] and
[https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
Fedora 39 Release Schedule].)

The schedule might appear somewhat tight for Fedora 39, but Python's
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AKA3USBKFYKUQDSGDK4FNDYYWMKM7XKX/
annual release cycle was adapted for Fedora] and this worked fine
since Python 3.9 and Fedora 33. It is now common that Python is
upgraded on a similar schedule in every odd-numbered Fedora release.

Note that upstream's "release candidates" are frozen except for
blocker bugs. Since we can and will backport blocker fixes between
Fedora and upstream, we essentially treat the Release Candidate as the
final release.

=== Notes from the previous upgrade ===

There are notes from the previous upgrade available, so this upgrade
may go smoother: [[SIGs/Python/UpgradingPython]]

== Benefit to Fedora ==

Fedora aims to showcase the latest in free and open-source software -
we should have the most recent release of Python 3. Packages in Fedora
can use the new features from 3.12.

There's also a benefit to the larger Python ecosystem: by building
Fedora's packages against 3.12 while it's still in development, we can
catch critical bugs before the final 3.12.0 release.

== Scope ==

We will coordinate the work in a side tag and merge when ready.

* Proposal owners:
*# Introduce {{package|python3.12}} for all Fedoras
*# Prepare stuff in Copr as explained in description.
*# Update {{package|python-rpm-macros}} so {{package|python3.12}}
builds {{package|python3}}
*# Build {{package|python3.12}} as the main Python
*# Mass rebuild all the packages that runtime require `python(abi) =
3.11` and/or `libpython3.11.so.1.0` (~3900 known packages in October
2022)
*# Build {{package|python3.12}} as a non-main Python

* Other developers: Maintainers of packages that fail to rebuild
during the rebuilds will be asked, using e-mail and bugzilla, to fix
or remove their packages from the distribution. If any issues 

Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Miro Hrončok

On 25. 10. 22 16:05, Ben Cotton wrote:

== Summary ==
Back in 1999, a new revision of the C standard removed several
backwards compatibility features. However, GCC still accepts these
obsolete constructs by default. Support for these constructs is
confusing to programmers and potentially affect GCC's ability to
implement features from future C standards.


Could you please update the summary with the summary of what's being changed 
rather than the summary of the status quo? I think that'll be more helpful.


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Alexander Sosedkin
On Tue, Oct 25, 2022 at 7:42 PM Florian Weimer  wrote:
>
> * Alexander Sosedkin:
>
> > Since it's a build-time-only change,
> > can it be rolled out under controlled pressure like this?
> >
> > 1. every package explicitly opts out (with some macro in specfile, IDK)
> > 2. switch gets flipped, nothing changes
> > 3. bugs get filed to drop that macro and opt into new behaviour
> > 4. opting in gets resolved at a leisurely pace
> >across as many releases as needed?
>
> Sorry, what's the advantage of doing it this way?

Spreading out the porting effect =)

Maybe I'm scarred by my own unsuccessful attempt
to spread out SHA-1 switch flipping across releases,
but this sounds like a switch that'll need maintainers
to not just react, but also coordinate with upstreams,
and Fedora's tight cycle is uncomfortably tight.

> We'd have to change all packages that have a C compiler
> in their buildroots as part of the first step.

OK, maybe just the ones failing to build with C99.

> Then we file thousands and thousands of bugs, and hope that
> the maintainers take action?  I'm not sure that's going to work for
> those maintain dozens (hundreds?) of packages.  It's also kind of
> difficult for a Fedora developer to predict GCC 14 behavior in 2024
> today.
>
> Relying on individual developer action also means that we'd have to
> teach many more people about C arcana and autoconf corner cases.  I
> don't think that's a good learning investment to be honest.  Most of
> this knowledge was already obsolete in 1999.
>
> I don't really know how much time we have before GCC disabled legacy C89
> extensions by default because some of them are incompatible with future
> C language directions.  I'm not convinced things will resolve themselves
> over time.  Obviously there's been some progress in the last 25 years
> (not everyone uses GCC and Clang with their extensions to build upstream
> software), but it's been really slow so far.  (Back in 2019, I quickly
> found a bunch of really core packages that needed fixes.)  It's also not
> clear to what degree the Macos efforts that Clemens mentioned have
> reached upstreams.  It doesn't seeem to have helped the Clang 15 release
> much.
>
> To me, all these things argue against spreading out the porting effort.

¯\_(ツ)_/¯

> I wish we could do it this way, but it doesn't look like it's a feasible
> option.

One cycle or many, I wish you to find the best way to pull this off.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Florian Weimer
* Alexander Sosedkin:

> Since it's a build-time-only change,
> can it be rolled out under controlled pressure like this?
>
> 1. every package explicitly opts out (with some macro in specfile, IDK)
> 2. switch gets flipped, nothing changes
> 3. bugs get filed to drop that macro and opt into new behaviour
> 4. opting in gets resolved at a leisurely pace
>across as many releases as needed?

Sorry, what's the advantage of doing it this way?  We'd have to change
all packages that have a C compiler in their buildroots as part of the
first step.  Then we file thousands and thousands of bugs, and hope that
the maintainers take action?  I'm not sure that's going to work for
those maintain dozens (hundreds?) of packages.  It's also kind of
difficult for a Fedora developer to predict GCC 14 behavior in 2024
today.

Relying on individual developer action also means that we'd have to
teach many more people about C arcana and autoconf corner cases.  I
don't think that's a good learning investment to be honest.  Most of
this knowledge was already obsolete in 1999.

I don't really know how much time we have before GCC disabled legacy C89
extensions by default because some of them are incompatible with future
C language directions.  I'm not convinced things will resolve themselves
over time.  Obviously there's been some progress in the last 25 years
(not everyone uses GCC and Clang with their extensions to build upstream
software), but it's been really slow so far.  (Back in 2019, I quickly
found a bunch of really core packages that needed fixes.)  It's also not
clear to what degree the Macos efforts that Clemens mentioned have
reached upstreams.  It doesn't seeem to have helped the Clang 15 release
much.

To me, all these things argue against spreading out the porting effort.
I wish we could do it this way, but it doesn't look like it's a feasible
option.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Richard W.M. Jones
On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
> Neither change is trivial to implement because introducing errors for
> these constructs (as required by C99) alters the result of autoconf
> configure checks. Quite a few such checks use an implicitly declared
> `exit` function, for instance. These failures are not really related
> to the feature under test. If the build system is well written, the
> build still succeeds, the relevant features are automatically disabled
> in the test suite and removed from reference ABI lists, and it's not
> immediately apparent that feature is gone. Therefore, some care is
> needed that no such alterations happen, and packages need to be ported
> to C99. Various tools for this porting activity are being developed to
> support this proposal. Cross-distribution collaboration will help as
> well, sharing patches and insights.

Would it help if we made autoreconf (and the equivalent step for other
build systems) mandatory?  Debian has declared this as "good practice"
since forever[0].

It would mean we could fix any problems in current autoconf
concurrently with the changes to GCC and Fedora.

>  Removal of old-style function definitions 
> 
> An old style function definition looks like this:
>
> int
> sum (a, b)
>   char *a;
>   int b;
> {
>   return atoi (a) + b;
> }



I preferred it when C was like this ..  The first real paying job I
had used a compiler[1] that only supported K C decls.

Rich.

[0] https://wiki.debian.org/Autoreconf
[1] Microware C Compiler for OS-9

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Florian Weimer
* Ralf Corsépius:

> Am 25.10.22 um 16:05 schrieb Ben Cotton:
>> https://fedoraproject.org/wiki/Changes/PortingToModernC.
>> This document represents a proposed Change. As part of the Changes
>> process, proposals are publicly announced in order to receive
>> community feedback. This proposal will only be implemented if approved
>> by the Fedora Engineering Steering Committee.
>
> IMHO, this proposal doesn't make any sense.
>
> Fedora is a collection of packages, which all obey different sets of
> language dialects, have various different upstreams and care about 
> Fedora to varying extents.
>
> I.e. all Fedora can do is to switch on "modern" C-dialects as
> C-defaults, but that's all.

Which part doesn't make sense?

Gentoo is doing similar work (and we're going to collaborate) just to be
able to build the distribution with Clang 16 and later, which is going
to make changes break C89 compatibility in the default configuration.

I think GCC should eventually make this change as well because there are
significant usability improvements possible.  We won't have much of a
choice once C2Y (not next year's release but the one after that) adopts
auto for local type inference because that conflicts with a legacy C89
compatibility features still enabled by GCC by default.  Doing this now
means that “auto copy = strdup(source);” is not valid C99 to C2X, so we
can detect it more easily.  Once upstreams start using the auto keyword
in C sources, this is going to be much harder.  So right now is probably
the absolutely last point in term when this whole thing is going to be a
lot of work, but not *too* complicated.

We will have to build some parts of the distribution in C89 mode
potentially indefinitely, but some work is required to actually achieve
that.  We need to know which packages not to switch, and make sure that
whatever mechanism we use actually works for their (often weird, old)
build systems.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Mailman3 on Fedora 36

2022-10-25 Thread Sjoerd Mullender

On 25/10/2022 18.58, Michael J Gruber wrote:

Can you give a bit more context about what you are trying to achieve?


I want to be able to continue to use Fedora on the system on which I run 
mailman for a bunch of mailing lists.  Currently that system runs Fedora 
35, but that will soon be end-of-life.  So I need to upgrade to at least 
F36, but on F36 mailman, postorius and hyperkitty cannot be installed. 
With some fairly small fixes to the spec files from F36 I was able to 
port the whole suite to F36.



A quick look at mailman3 and postorius in fedora dist-git reveals that they 
were retired from rawhide/f37 because they do not build against python 3.11. 
So, a minor update on f36 (which still has python 3.10) is not really what we 
need to keep them in fedora.


Indeed, this is a problem.  But at least, having mailman available in 
F36 gives me half a year.



In any case, a pull request in dist-git is the usual way to suggest a package 
update which you are authoring, but this should build on top of the existing 
spec. [I hope f26 is a typo ...] Alternatively, feel free to file a bug against 
these packages.


Indeed, 26 is a typo.  I meant 36.


The issue with installing mailman3 might be due to sqlalchemy, though: There is a 1.3 
compat package but it conflicts with the update. If you want to "rescue" 
mailman3 in f36 even though it is retired in rawhide this might be an option.


In my version, I indeed require sqlalchemy1.3.
Another package with a potential problem is mistune where hyperkitty 
requires >= 2.0 and F36 comes with 0.8.4, and the two are not 
compatible.  I think the other packages that needed to be updated are 
more-or-less backward compatible.


--
Sjoerd Mullender
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Heads up! OpenImageIO 2.4 series coming to rawhide

2022-10-25 Thread Richard Shaw
On Tue, Oct 25, 2022 at 10:31 AM Tom Rix  wrote:

>
> On 10/24/22 1:02 PM, Richard Shaw wrote:
>
> On Mon, Oct 24, 2022 at 2:48 PM Tom Rix  wrote:
>
>> I was looking at the epel9 build of 2.4 recently but could not figure out
>> how to get past the OpenColorIO dependency.
>>
>> How do you do that ?
>>
>
> I haven't branched OIIO or OCIO for EPEL 9 yet, but I can if there's a
> need for it.
>
> The short answer is the command line tools are cross dependent so
> initially I have to perform a bootstrap build.
>
> I was going to request epel9 branches for both once I figured out how to
> do the building in koji.
>
> Manually on a clean rhel 9, I can fiddle with the image specfile to
> unstick the build and rebuild image with the just built color
>
> Since opencv has an epel9 now, both build.
>
> There is dcmtk on epel9, so the OpenImageIO.spec could change its check
>
Noted

> OpenColorIO docs still do not build because of missing python3-sphinx-*
>

Easy answer is to disable building docs on EL, though not ideal.


> If it is easy can you do the epel9 build otherwise please give me some
> instruction on bootstrapping koji and I will.
>

I'm creating a CentOS 9 Stream VM right now to do some quick testing. It
may be as easy as commenting out BR: OpenColorIO for OIIO, build OCIO, and
then uncomment and rebuild. It only needs to be done once so I never
created a build conditional.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Adam Williamson
On Tue, 2022-10-25 at 15:51 +0100, Daniel P. Berrangé wrote:
> I feel that this need to start on the prep work in F38/F39 is not
> very obvious from the F40 change proposal text.

I thought this was kinda very obviously implicit in the decision to
file an F40 Change proposal *now*.
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Mailman3 on Fedora 36

2022-10-25 Thread Michael J Gruber
Can you give a bit more context about what you are trying to achieve?

A quick look at mailman3 and postorius in fedora dist-git reveals that they 
were retired from rawhide/f37 because they do not build against python 3.11. 
So, a minor update on f36 (which still has python 3.10) is not really what we 
need to keep them in fedora.

In any case, a pull request in dist-git is the usual way to suggest a package 
update which you are authoring, but this should build on top of the existing 
spec. [I hope f26 is a typo ...] Alternatively, feel free to file a bug against 
these packages.

The issue with installing mailman3 might be due to sqlalchemy, though: There is 
a 1.3 compat package but it conflicts with the update. If you want to "rescue" 
mailman3 in f36 even though it is retired in rawhide this might be an option.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Alexander Sosedkin
On Tue, Oct 25, 2022 at 5:09 PM Daniel P. Berrangé  wrote:
> So this change is talking about a new GCC landing in Fedora 40.
>
> To avoid massive disruption to Fedora though, we need to be doing
> work way earlier than the Fedora 40 dev cycle though.
>
> Identifying all the places where autoconf tests quietly change
> their result, and silently toggle on/off alternative code paths
> is going to be a big job on its own.
>
> Once identified there's the even more work to figure out the right
> changes needed. I don't know how many packages rely on autoconf,
> but the idea of carrying patches in Fedora and re-running autotools
> to re-create configure, isn't that appealing on a large scale.
>
> Obviously the preferred solution is to be able to report the problems
> upstream, and get the fixes included in the next upstream release
> and then rebase in Fedora. Even better is if a major information
> campaign brings this change directly to the attention of upstreams
> communities, bypassing the distros where there is an active upstream.
>
> I'd be concerned about the timeframe for getting through this dance
> for a non-negligible number of packages.
>>
> IOW, this change is talking about something in Fedora 40, but it
> feels like the vast majority of work needs to take place in Fedora
> 38 and Fedora 39.  Fedora 40 neeeds to be nothing more than a "flip
> the switch" scenario, otherwise history suggests the change is likely
> to end up getting punted to Fedora 41/42.

Since it's a build-time-only change,
can it be rolled out under controlled pressure like this?

1. every package explicitly opts out (with some macro in specfile, IDK)
2. switch gets flipped, nothing changes
3. bugs get filed to drop that macro and opt into new behaviour
4. opting in gets resolved at a leisurely pace
   across as many releases as needed?

> I feel that this need to start on the prep work in F38/F39 is not
> very obvious from the F40 change proposal text.
>
> So shouldn't we have explicit distinct 'Fedora 38/39' change proposal(s)
> to describe the prep work that needs to be done across packages in these
> two releases as a matter of urgency, in order to make it possible to the
> F40 change to actually happen ?
>
>
> Concretely, as an upstream  maintainer, what should they do to test
> the behaviour of their code ?  Is there more to it than just
> setting CFLAGS="-std=gnu99", if they want to validate this in their
> upstream CI ahead of GCC 14 arriving ?
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-AnyEvent-BDB] PR #1: Update license to SPDX format

2022-10-25 Thread Michal Josef Špaček

mspacek merged a pull-request against the project: `perl-AnyEvent-BDB` that you 
are following.

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-AnyEvent-BDB/pull-request/1
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-AnyEvent-BDB] PR #1: Update license to SPDX format

2022-10-25 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-AnyEvent-BDB` that 
you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-AnyEvent-BDB/pull-request/1
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Ralf Corsépius

Am 25.10.22 um 16:05 schrieb Ben Cotton:

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


IMHO, this proposal doesn't make any sense.

Fedora is a collection of packages, which all obey different sets of 
language dialects, have various different upstreams and care about 
Fedora to varying extents.


I.e. all Fedora can do is to switch on "modern" C-dialects as 
C-defaults, but that's all.


Ralf
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-libwww-perl] PR #42: Update license to SPDX format

2022-10-25 Thread Michal Josef Špaček

mspacek merged a pull-request against the project: `perl-libwww-perl` that you 
are following.

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/42
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Mailman3 on Fedora 36

2022-10-25 Thread Sjoerd Mullender
I have created RPMs for mailman3 on Fedora 36.  The current (in the 
repos) version cannot be installed, but my version, based on mailman 
3.3.5 can.  Also, I have RPMs for postorius and hyperkitty.


These RPMs are based on the Fedora 26 source RPMs, but updated to later 
versions.  Also, a whole bunch of other packages had to be updated.  A 
full list is at the bottom.


My question is, how do I proceed?  Who can take this in order to push 
this (or something similar) to the repositories?


I have not (yet?) been able to do this for Fedora 37 since the mailman 
suite doesn't yet play nice with Python 3.11.


Here is the list of RPMs.  Source RPMs are of course available.

hyperkitty-1.3.5.9-1.fc36.noarch.rpm
hyperkitty-doc-1.3.5.9-1.fc36.noarch.rpm
mailman3-3.3.5-0.2.fc36.noarch.rpm
postorius-1.3.6.9-1.fc36.noarch.rpm
python3-django-compressor-4.1-0.fc36.noarch.rpm
python3-django-haystack-3.2.1-0.fc36.noarch.rpm
python3-django-mailman3-1.3.7.9-1.fc36.noarch.rpm
python3-flufl-bounce-4.0-0.fc36.noarch.rpm
python3-flufl-i18n-3.2-0.fc36.noarch.rpm
python3-flufl-lock-5.1-0.1.fc36.noarch.rpm
python3-mailmanclient-3.3.3-4.fc36.noarch.rpm
python3-mailman-hyperkitty-1.2.1-0.1.fc36.noarch.rpm
python3-mistune-2.0.4-0.fc36.noarch.rpm
python3-rcssmin-1.1.0-0.fc36.x86_64.rpm
python3-rjsmin-1.2.0-0.fc36.x86_64.rpm
python-django-haystack-docs-3.2.1-0.fc36.noarch.rpm
python-rjsmin-docs-1.2.0-0.fc36.x86_64.rpm

--
Sjoerd Mullender
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Clemens Lang

Hi everyone,

Ben Cotton  wrote:


Neither change is trivial to implement because introducing errors for
these constructs (as required by C99) alters the result of autoconf
configure checks. Quite a few such checks use an implicitly declared
`exit` function, for instance. These failures are not really related
to the feature under test. If the build system is well written, the
build still succeeds, the relevant features are automatically disabled
in the test suite and removed from reference ABI lists, and it's not
immediately apparent that feature is gone. Therefore, some care is
needed that no such alterations happen, and packages need to be ported
to C99. Various tools for this porting activity are being developed to
support this proposal. Cross-distribution collaboration will help as
well, sharing patches and insights.


I may have some good news here: When Apple started shipping arm64 hardware,
it switched its system compiler to always treat implicit function
declarations as errors. Apple engineers did that because the calling ABI for
variadic functions on arm64 differs from that of non-variadic functions, so
a declaration is required to determine the correct code to generate.

As a consequence, the various macOS package managers have been working on
identifying and fixing these autoconf issues for a while now. Obviously,
there is a lot of Linux-specific software that nobody will have fixed yet,
and the package set may be smaller in the macOS package managers, but
commonly used software is probably already fixed.

HTH,
Clemens

--
Clemens Lang
RHEL Crypto Team
Red Hat


___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-libwww-perl] PR #42: Update license to SPDX format

2022-10-25 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-libwww-perl` that 
you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-libwww-perl/pull-request/42
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Florian Weimer
* Neal Gompa:

> Why C99? Why not C18 instead? If we're going to go through this
> effort, we should ramp up like we did for C++ and bump all the way up
> to the latest published standard.

Getting past C99 is the hardest part because it's not possible (as far
as I can see) to do fully automated reporting for implicit function
declarations.  (Because we don't implement, say, setproctitle, that's
going to show up as a legitimate configure check failure.)

The other issues (e.g., implicit ints, true/falls/bool redefined, () for
variadic parameter lists) are more tractable because those have to be
removed completely.  So their presence is always worth reporting.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-Archive-Extract] PR #3: Update license to SPDX

2022-10-25 Thread Michal Josef Špaček

mspacek merged a pull-request against the project: `perl-Archive-Extract` that 
you are following.

Merged pull-request:

``
Update license to SPDX
``

https://src.fedoraproject.org/rpms/perl-Archive-Extract/pull-request/3
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2022-10-25 Thread tdawson
Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2022-10-26 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




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

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Florian Weimer
* Daniel P. Berrangé:

> Good to see it mentions autoconf, as such tests were my immediate
> concern upon reading the intro.
>
> I presume the same problem will exist in other build systems that
> probe for features, both well known ones like cmake/meson/etc,
> but also home grown ones that are package specific (/me glares
> at QEMU's 'configure' that merely pretends to look like it is
> from autoconf, but is actually just a hand written shell script).

Yes, some distributions use config.log diffing.  I've got an
instrumented GCC that logs the relevant errors in a way that is
impossible to hide.  There are pros and cons for each approach.

I found one non-autoconf issue already:

  Unclear how CCompiler.has_function works for functions with parameters
  

This is actually quite typical of the things that are papered over by
implicit function declarations.

>> == Dependencies ==
>> To avoid regressing the porting effort, GCC as the system compiler
>> needs to reject obsolete constructs by default. This is expected for
>> GCC 14, to be released as part of Fedora 40 in Spring 2024.
>
> So this change is talking about a new GCC landing in Fedora 40.
>
> To avoid massive disruption to Fedora though, we need to be doing
> work way earlier than the Fedora 40 dev cycle though.

Yes, I understand that we might be too late already.  I wanted to get
the announcement out of the door that we can start carrying patches for
this in rawhide starting now (particularly where we might have cascading
effects on our testing, like the has_function issue mentioned above).

I don't think I can do this work on a branch because keeping that branch
up-to-date will be too much work on its own.

> Identifying all the places where autoconf tests quietly change
> their result, and silently toggle on/off alternative code paths
> is going to be a big job on its own.

Right, but other distributions are doing this as well (Gentoo has
already begun working on this from a Clang 16 perspective), and we are
trying to come up with ways to share observations and patches.

One tough aspect is that this affects disproportionately legacy software
for which there is no upstream around anymore, or the sources are
difficult to change because they are supposed to keep building on very,
very old systems.  We can switch to building in C89 mode in these cases.

> I feel that this need to start on the prep work in F38/F39 is not
> very obvious from the F40 change proposal text.

I mentioned that package maintainers need to tolerate the odd patch to
fix issues in rawhide.  That's what I'm asking for today.

> Concretely, as an upstream  maintainer, what should they do to test
> the behaviour of their code ?  Is there more to it than just
> setting CFLAGS="-std=gnu99", if they want to validate this in their
> upstream CI ahead of GCC 14 arriving ?

It's -Werror=implicit-int -Werror=implicit-function-declaration.  Best
to throw in -Werror=int-conversion -Werror=strict-prototypes
-Werror=old-style-definition.  -Werror=int-conversion should really be a
no-brainer, the other two are about the removal of old-style function
definitions and declarations that are not prototypes from C2X (also
mentioned in the proposal).  I can probably spell this out in the
proposal.

Some of the planned Clang 16+ and GCC 14+ changes may not be directly
testable with current compilers, but they will be less impactful than
the two main issues, I think.  That's why I'm focusing to get us past
the C99 bump first.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-Archive-Extract] PR #3: Update license to SPDX

2022-10-25 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-Archive-Extract` 
that you are following:
``
Update license to SPDX
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Archive-Extract/pull-request/3
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Heads up! OpenImageIO 2.4 series coming to rawhide

2022-10-25 Thread Tom Rix


On 10/24/22 1:02 PM, Richard Shaw wrote:
On Mon, Oct 24, 2022 at 2:48 PM Tom Rix > wrote:


I was looking at the epel9 build of 2.4 recently but could not
figure out how to get past the OpenColorIO dependency.

How do you do that ?


I haven't branched OIIO or OCIO for EPEL 9 yet, but I can if there's a 
need for it.


The short answer is the command line tools are cross dependent so 
initially I have to perform a bootstrap build.


I was going to request epel9 branches for both once I figured out how to 
do the building in koji.


Manually on a clean rhel 9, I can fiddle with the image specfile to 
unstick the build and rebuild image with the just built color


Since opencv has an epel9 now, both build.

There is dcmtk on epel9, so the OpenImageIO.spec could change its check

OpenColorIO docs still do not build because of missing python3-sphinx-*

If it is easy can you do the epel9 build otherwise please give me some 
instruction on bootstrapping koji and I will.


Tom



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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Florian Weimer
* Ben Cotton:

> On Tue, Oct 25, 2022 at 10:05 AM Ben Cotton  wrote:
>>
>> == Upgrade/compatibility impact ==
>> The change is expected to be transparent to those users who do not use
>> C compilers. No features are supposed to be added or removed as a
>> result. In fact, most of the porting effort focuses on avoiding
>> configuration changes.
>
> [deletia]
>
>> == Release Notes ==
>> Probably not needed because no user visible impact is intended.
>
> These two sections seem in conflict. Wouldn't this Change affect users
> who compile C software? Or is it only a difference in our build
> tooling?

This aspect will be covered by the GCC change proposal when the time
comes (probably with GCC 14/Fedora 40, but it's hard to make predictions
so far in the future).

For each individual package, I expect the required changes mostly within
the scope of a typical binutils/GCC/glibc update that requires some
changes to source code.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Neal Gompa
On Tue, Oct 25, 2022 at 10:51 AM Daniel P. Berrangé  wrote:
>
> On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
> > == Owner ==
> > * Name: [[User:fweimer| Florian Weimer]]
> > * Email: [mailto:fwei...@redhat.com| fwei...@redhat.com]
> >
> >
> > == Detailed Description ==
> > The most important change is the removal of implicit function
> > declarations. This legacy compatibility feature causes the
> > compiler to automatically supply a declaration of type `int
> > function()` if `function` is undeclared, but called as a function.
> > However, the implicit return type of `int` is incompatible with
> > pointer-returning functions, which can lead to difficult debugging
> > sessions if the compiler warning is missed, as described here:
> >
> > * 
> > [https://developers.redhat.com/blog/2019/04/22/implicit-function-declarations-flexs-use-of-reallocarray|
> > Implicit function declarations: flex's use of "reallocarray"]
> >
> > On x86-64, functions returning `_Bool` called with an implicit
> > declaration will also not work correctly because the return register
> > value for `_Bool` functions is partially undefined (not all 32 bits in
> > the implicitly declared `int` are defined).
> >
> > Another change for C99 is the removal of implicit `int` type
> > declarations. For example, in the following fragment, both `i` and
> > `j` are defined as `int` variables:
> >
> > 
> > static i = 1.0;
> > auto j = 2.0;
> > 
> >
> > Support for this obsolete constructs is incompatible with adoption of
> > type inference for `auto` definitions (which are part of C++).
> >
> > Neither change is trivial to implement because introducing errors for
> > these constructs (as required by C99) alters the result of autoconf
> > configure checks. Quite a few such checks use an implicitly declared
> > `exit` function, for instance. These failures are not really related
> > to the feature under test. If the build system is well written, the
> > build still succeeds, the relevant features are automatically disabled
> > in the test suite and removed from reference ABI lists, and it's not
> > immediately apparent that feature is gone. Therefore, some care is
> > needed that no such alterations happen, and packages need to be ported
> > to C99. Various tools for this porting activity are being developed to
> > support this proposal. Cross-distribution collaboration will help as
> > well, sharing patches and insights.
>
> Good to see it mentions autoconf, as such tests were my immediate
> concern upon reading the intro.
>
> I presume the same problem will exist in other build systems that
> probe for features, both well known ones like cmake/meson/etc,
> but also home grown ones that are package specific (/me glares
> at QEMU's 'configure' that merely pretends to look like it is
> from autoconf, but is actually just a hand written shell script).
>
> > == Dependencies ==
> > To avoid regressing the porting effort, GCC as the system compiler
> > needs to reject obsolete constructs by default. This is expected for
> > GCC 14, to be released as part of Fedora 40 in Spring 2024.
>
> So this change is talking about a new GCC landing in Fedora 40.
>
> To avoid massive disruption to Fedora though, we need to be doing
> work way earlier than the Fedora 40 dev cycle though.
>
> Identifying all the places where autoconf tests quietly change
> their result, and silently toggle on/off alternative code paths
> is going to be a big job on its own.
>
> Once identified there's the even more work to figure out the right
> changes needed. I don't know how many packages rely on autoconf,
> but the idea of carrying patches in Fedora and re-running autotools
> to re-create configure, isn't that appealing on a large scale.
>
> Obviously the preferred solution is to be able to report the problems
> upstream, and get the fixes included in the next upstream release
> and then rebase in Fedora. Even better is if a major information
> campaign brings this change directly to the attention of upstreams
> communities, bypassing the distros where there is an active upstream.
>
> I'd be concerned about the timeframe for getting through this dance
> for a non-negligible number of packages.
>
>
> IOW, this change is talking about something in Fedora 40, but it
> feels like the vast majority of work needs to take place in Fedora
> 38 and Fedora 39.  Fedora 40 neeeds to be nothing more than a "flip
> the switch" scenario, otherwise history suggests the change is likely
> to end up getting punted to Fedora 41/42.
>
> I feel that this need to start on the prep work in F38/F39 is not
> very obvious from the F40 change proposal text.
>
> So shouldn't we have explicit distinct 'Fedora 38/39' change proposal(s)
> to describe the prep work that needs to be done across packages in these
> two releases as a matter of urgency, in order to make it possible to the
> F40 change to actually happen ?
>
>
> Concretely, as an upstream  maintainer, what should they do to test
> the 

Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Daniel P . Berrangé
On Tue, Oct 25, 2022 at 10:05:52AM -0400, Ben Cotton wrote:
> == Owner ==
> * Name: [[User:fweimer| Florian Weimer]]
> * Email: [mailto:fwei...@redhat.com| fwei...@redhat.com]
> 
> 
> == Detailed Description ==
> The most important change is the removal of implicit function
> declarations. This legacy compatibility feature causes the
> compiler to automatically supply a declaration of type `int
> function()` if `function` is undeclared, but called as a function.
> However, the implicit return type of `int` is incompatible with
> pointer-returning functions, which can lead to difficult debugging
> sessions if the compiler warning is missed, as described here:
> 
> * 
> [https://developers.redhat.com/blog/2019/04/22/implicit-function-declarations-flexs-use-of-reallocarray|
> Implicit function declarations: flex's use of "reallocarray"]
> 
> On x86-64, functions returning `_Bool` called with an implicit
> declaration will also not work correctly because the return register
> value for `_Bool` functions is partially undefined (not all 32 bits in
> the implicitly declared `int` are defined).
> 
> Another change for C99 is the removal of implicit `int` type
> declarations. For example, in the following fragment, both `i` and
> `j` are defined as `int` variables:
> 
> 
> static i = 1.0;
> auto j = 2.0;
> 
> 
> Support for this obsolete constructs is incompatible with adoption of
> type inference for `auto` definitions (which are part of C++).
> 
> Neither change is trivial to implement because introducing errors for
> these constructs (as required by C99) alters the result of autoconf
> configure checks. Quite a few such checks use an implicitly declared
> `exit` function, for instance. These failures are not really related
> to the feature under test. If the build system is well written, the
> build still succeeds, the relevant features are automatically disabled
> in the test suite and removed from reference ABI lists, and it's not
> immediately apparent that feature is gone. Therefore, some care is
> needed that no such alterations happen, and packages need to be ported
> to C99. Various tools for this porting activity are being developed to
> support this proposal. Cross-distribution collaboration will help as
> well, sharing patches and insights.

Good to see it mentions autoconf, as such tests were my immediate
concern upon reading the intro.

I presume the same problem will exist in other build systems that
probe for features, both well known ones like cmake/meson/etc,
but also home grown ones that are package specific (/me glares
at QEMU's 'configure' that merely pretends to look like it is
from autoconf, but is actually just a hand written shell script).

> == Dependencies ==
> To avoid regressing the porting effort, GCC as the system compiler
> needs to reject obsolete constructs by default. This is expected for
> GCC 14, to be released as part of Fedora 40 in Spring 2024.

So this change is talking about a new GCC landing in Fedora 40.

To avoid massive disruption to Fedora though, we need to be doing
work way earlier than the Fedora 40 dev cycle though.

Identifying all the places where autoconf tests quietly change
their result, and silently toggle on/off alternative code paths
is going to be a big job on its own.

Once identified there's the even more work to figure out the right
changes needed. I don't know how many packages rely on autoconf,
but the idea of carrying patches in Fedora and re-running autotools
to re-create configure, isn't that appealing on a large scale.

Obviously the preferred solution is to be able to report the problems
upstream, and get the fixes included in the next upstream release
and then rebase in Fedora. Even better is if a major information
campaign brings this change directly to the attention of upstreams
communities, bypassing the distros where there is an active upstream.

I'd be concerned about the timeframe for getting through this dance
for a non-negligible number of packages.


IOW, this change is talking about something in Fedora 40, but it
feels like the vast majority of work needs to take place in Fedora
38 and Fedora 39.  Fedora 40 neeeds to be nothing more than a "flip
the switch" scenario, otherwise history suggests the change is likely
to end up getting punted to Fedora 41/42.

I feel that this need to start on the prep work in F38/F39 is not
very obvious from the F40 change proposal text.

So shouldn't we have explicit distinct 'Fedora 38/39' change proposal(s)
to describe the prep work that needs to be done across packages in these
two releases as a matter of urgency, in order to make it possible to the
F40 change to actually happen ?


Concretely, as an upstream  maintainer, what should they do to test
the behaviour of their code ?  Is there more to it than just
setting CFLAGS="-std=gnu99", if they want to validate this in their
upstream CI ahead of GCC 14 arriving ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-

[Bug 2137138] perl-DateTime-Locale-1.37 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137138



--- Comment #1 from Fedora Update System  ---
FEDORA-2022-2d3dedadef has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-2d3dedadef


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137138
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137138] perl-DateTime-Locale-1.37 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137138

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-DateTime-Locale-1.37-1
   ||.fc38
   Doc Type|--- |If docs needed, set a value
 Status|NEW |MODIFIED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137138
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Ben Cotton
On Tue, Oct 25, 2022 at 10:05 AM Ben Cotton  wrote:
>
> == Upgrade/compatibility impact ==
> The change is expected to be transparent to those users who do not use
> C compilers. No features are supposed to be added or removed as a
> result. In fact, most of the porting effort focuses on avoiding
> configuration changes.

[deletia]

> == Release Notes ==
> Probably not needed because no user visible impact is intended.

These two sections seem in conflict. Wouldn't this Change affect users
who compile C software? Or is it only a difference in our build
tooling?

-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/PortingToModernC.

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Back in 1999, a new revision of the C standard removed several
backwards compatibility features. However, GCC still accepts these
obsolete constructs by default. Support for these constructs is
confusing to programmers and potentially affect GCC's ability to
implement features from future C standards.

== Owner ==
* Name: [[User:fweimer| Florian Weimer]]
* Email: [mailto:fwei...@redhat.com| fwei...@redhat.com]


== Detailed Description ==
The most important change is the removal of implicit function
declarations. This legacy compatibility feature causes the
compiler to automatically supply a declaration of type `int
function()` if `function` is undeclared, but called as a function.
However, the implicit return type of `int` is incompatible with
pointer-returning functions, which can lead to difficult debugging
sessions if the compiler warning is missed, as described here:

* 
[https://developers.redhat.com/blog/2019/04/22/implicit-function-declarations-flexs-use-of-reallocarray|
Implicit function declarations: flex's use of "reallocarray"]

On x86-64, functions returning `_Bool` called with an implicit
declaration will also not work correctly because the return register
value for `_Bool` functions is partially undefined (not all 32 bits in
the implicitly declared `int` are defined).

Another change for C99 is the removal of implicit `int` type
declarations. For example, in the following fragment, both `i` and
`j` are defined as `int` variables:


static i = 1.0;
auto j = 2.0;


Support for this obsolete constructs is incompatible with adoption of
type inference for `auto` definitions (which are part of C++).

Neither change is trivial to implement because introducing errors for
these constructs (as required by C99) alters the result of autoconf
configure checks. Quite a few such checks use an implicitly declared
`exit` function, for instance. These failures are not really related
to the feature under test. If the build system is well written, the
build still succeeds, the relevant features are automatically disabled
in the test suite and removed from reference ABI lists, and it's not
immediately apparent that feature is gone. Therefore, some care is
needed that no such alterations happen, and packages need to be ported
to C99. Various tools for this porting activity are being developed to
support this proposal. Cross-distribution collaboration will help as
well, sharing patches and insights.

GCC 14 may also make other changes by default, as described below.
These changes will also require extensive testing, and some adoption
of configure checks.

 Removal of old-style function definitions 

An old style function definition looks like this:

int
sum (a, b)
  char *a;
  int b;
{
  return atoi (a) + b;
}

It is equivalent to this definition with a prototype:

int
sum (char *a, int b)
{
  return atoi (a) + b;
}

This legacy feature is very close to being incompatible with the C2X
standard, which introduces unnamed function arguments. But due to a
quirk in GCC's implementation, it should be possible to support both
at the same time.

 New keywords bool, true, false 

Packages which supply their own definitions instead of including
`` (which remains available) might fail to build.

 Change of meaning of () in function declarators 

In earlier C versions, a declaration `int function()` declares
`function` as accepting an unspecified number of arguments of unknown
type. This means that both `function(1)` and `function("one")`
compile, even though they might not work correctly. In a future C
standard, `int function()` will mean that `function` does not accept
any parameters (like in C++, or as if written as `int function(void)`
in current C). Calls that specify parameters will therefore result in
compilation errors.

We believe that this change is ABI-compatible, even on ppc64le (with
its parameter save area), although it comes very close to an implicit
ABI break.

 Rejecting implicit conversions between integers and pointers as errors 

Currently, GCC does not treat conversion between integers at pointers
as errors, so this compiles:


int ptr = "string";


However, this is very unlikely to work on 64-bit architectures (it may
work by accident without PIE/PIC).

== Feedback ==

The transition plan has been discussed at various GNU Tools Cauldrons.
Feedback has been generally positive, except a general worry about the
work required.

Without a deliberate porting effort, a lot of breakage occurs,
[https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/AL3PXQ3HX26PCF5PYDZ5RU7VJZSBZEPQ/|as
seen in 2016 in Fedora with an uncoordinated change], 

F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

2022-10-25 Thread Ben Cotton
https://fedoraproject.org/wiki/Changes/PortingToModernC.

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Back in 1999, a new revision of the C standard removed several
backwards compatibility features. However, GCC still accepts these
obsolete constructs by default. Support for these constructs is
confusing to programmers and potentially affect GCC's ability to
implement features from future C standards.

== Owner ==
* Name: [[User:fweimer| Florian Weimer]]
* Email: [mailto:fwei...@redhat.com| fwei...@redhat.com]


== Detailed Description ==
The most important change is the removal of implicit function
declarations. This legacy compatibility feature causes the
compiler to automatically supply a declaration of type `int
function()` if `function` is undeclared, but called as a function.
However, the implicit return type of `int` is incompatible with
pointer-returning functions, which can lead to difficult debugging
sessions if the compiler warning is missed, as described here:

* 
[https://developers.redhat.com/blog/2019/04/22/implicit-function-declarations-flexs-use-of-reallocarray|
Implicit function declarations: flex's use of "reallocarray"]

On x86-64, functions returning `_Bool` called with an implicit
declaration will also not work correctly because the return register
value for `_Bool` functions is partially undefined (not all 32 bits in
the implicitly declared `int` are defined).

Another change for C99 is the removal of implicit `int` type
declarations. For example, in the following fragment, both `i` and
`j` are defined as `int` variables:


static i = 1.0;
auto j = 2.0;


Support for this obsolete constructs is incompatible with adoption of
type inference for `auto` definitions (which are part of C++).

Neither change is trivial to implement because introducing errors for
these constructs (as required by C99) alters the result of autoconf
configure checks. Quite a few such checks use an implicitly declared
`exit` function, for instance. These failures are not really related
to the feature under test. If the build system is well written, the
build still succeeds, the relevant features are automatically disabled
in the test suite and removed from reference ABI lists, and it's not
immediately apparent that feature is gone. Therefore, some care is
needed that no such alterations happen, and packages need to be ported
to C99. Various tools for this porting activity are being developed to
support this proposal. Cross-distribution collaboration will help as
well, sharing patches and insights.

GCC 14 may also make other changes by default, as described below.
These changes will also require extensive testing, and some adoption
of configure checks.

 Removal of old-style function definitions 

An old style function definition looks like this:

int
sum (a, b)
  char *a;
  int b;
{
  return atoi (a) + b;
}

It is equivalent to this definition with a prototype:

int
sum (char *a, int b)
{
  return atoi (a) + b;
}

This legacy feature is very close to being incompatible with the C2X
standard, which introduces unnamed function arguments. But due to a
quirk in GCC's implementation, it should be possible to support both
at the same time.

 New keywords bool, true, false 

Packages which supply their own definitions instead of including
`` (which remains available) might fail to build.

 Change of meaning of () in function declarators 

In earlier C versions, a declaration `int function()` declares
`function` as accepting an unspecified number of arguments of unknown
type. This means that both `function(1)` and `function("one")`
compile, even though they might not work correctly. In a future C
standard, `int function()` will mean that `function` does not accept
any parameters (like in C++, or as if written as `int function(void)`
in current C). Calls that specify parameters will therefore result in
compilation errors.

We believe that this change is ABI-compatible, even on ppc64le (with
its parameter save area), although it comes very close to an implicit
ABI break.

 Rejecting implicit conversions between integers and pointers as errors 

Currently, GCC does not treat conversion between integers at pointers
as errors, so this compiles:


int ptr = "string";


However, this is very unlikely to work on 64-bit architectures (it may
work by accident without PIE/PIC).

== Feedback ==

The transition plan has been discussed at various GNU Tools Cauldrons.
Feedback has been generally positive, except a general worry about the
work required.

Without a deliberate porting effort, a lot of breakage occurs,
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AL3PXQ3HX26PCF5PYDZ5RU7VJZSBZEPQ/|as
seen in 2016 in Fedora with an uncoordinated change], 

Non-schedule for Tuesday's FESCo Meeting (2022-10-25)

2022-10-25 Thread Zbigniew Jędrzejewski-Szmek
There are no topics to be discussed in the FESCo meeting
Tuesday at 17:00UTC in #fedora-meeting on irc.libera.chat.

Hence I decided to cancel it.

I will chair the next meeting.


= Discussed and Voted in the Ticket =

#2880 Fixing accidental change to format preference in GNOME Software
https://pagure.io/fesco/issue/2880
APPROVED (+7,0,-0)

#2879 Change: Deprecate python-toml
https://pagure.io/fesco/issue/2879
APPROVED (+3, 0, 0)

#2878 Nonresponsive maintainer: Volker Fröhlich 
https://pagure.io/fesco/issue/2878
APPROVED (acked by volter)
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[EPEL-devel] Fedora EPEL 8 updates-testing report

2022-10-25 Thread updates
The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a324bfef02   
strongswan-5.9.8-1.el8
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-6cfebbe90a   
jhead-3.06.0.1-5.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-48a9da6be8   
ipython-7.16.3-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-984ee8bb5b   
exim-4.96-3.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-0b4d1769c1   
glances-3.3.0.1-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e6eed63b43   
kdiskmark-3.1.2-1.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-833c1b943c   
mbedtls-2.28.1-1.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c142c82939   
cacti-1.2.22-1.el8 cacti-spine-1.2.22-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

mimedefang-3.2-1.el8
mingw-libidn2-2.3.4-1.el8

Details about builds:



 mimedefang-3.2-1.el8 (FEDORA-EPEL-2022-0c04c46528)
 E-mail filtering framework using Sendmail's Milter interface

Update Information:

# MIMEDefang 3.2- Skip DNSBL test without network access   - Restore
possibility to use a SpamAssassing config file on different paths   - Add an
hint to help Gentoo find Perl binary   - Improve list of needed Perl modules   -
Use more warnings   - Add missing namespaces   - Change http to https on some
web site links   - Check that the variable is not `NULL`, makes clang(1) happy
- Remove rm(1) tentacles, support has been removed before   - Make sure that
setting `FD_CLOEXEC` will succeed   - Fix `action_replace_with_url()`   - Fix
Postfix support

ChangeLog:

* Mon Oct 24 2022 Robert Scheck  3.2-1
- Upgrade to 3.2 (#2136815)

References:

  [ 1 ] Bug #2136815 - mimedefang-3.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2136815




 mingw-libidn2-2.3.4-1.el8 (FEDORA-EPEL-2022-ec91577ac5)
 MinGW Windows Internationalized Domain Name 2008 support library

Update Information:

# libidn2 2.3.4 (2022-10-23)* Support for Unicode 15.0.0  We now uses
Unicode.org's IDNA2008 tables rather than IANA's.  See
https://gitlab.com/libidn/libidn2/-/issues/112 and
https://lists.gnu.org/archive/html/help-libidn/2022-10/msg0.html for
rationale, which can be summarized into 1) IANA are still on 2019-era Unicode
version 12 and we wish to support Unicode version 12-15, 2) consistency with
some other implementations, 3) the only incompatibility related to `U+19DA` is
deemed to have minor real-world consequences.  Thus we break backwards
compatibility for `U+19DA` in this release compared against libidn2 0.11..2.3.3
thus reverting back to the libidn2 <= 0.11 behaviour.  We decided to not bump
ABI version and believe this is the best choice going forward as well for minor
internal non-API related ABI changes.* Gnulib updated and now libunistring-
optional is used  This allows you to force libidn2 to use internal
libunistring with the following command: `./configure --with-included-
libunistring`

ChangeLog:

* Mon Oct 24 2022 Robert Scheck  2.3.4-1
- Upgrade to 2.3.4 (#2137125)
* Thu Jul 21 2022 Fedora Release Engineering  - 
2.3.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

References:

  [ 1 ] Bug #2137125 - mingw-libidn2-2.3.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2137125


___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137401] perl-Alien-pkgconf-0.19 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137401



--- Comment #7 from Fedora Update System  ---
FEDORA-2022-519fdf2838 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-519fdf2838`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-519fdf2838

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=2137401
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F38 proposal: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)

2022-10-25 Thread Colin Walters


On Mon, Oct 24, 2022, at 11:45 PM, Dusty Mabe wrote:
> There are a lot of things going on in this proposal:
>
> - shipping editions as container images in quay

https://pagure.io/releng/issue/11047

> - migrating existing users to the new container image based updates

(No tracker yet)

> - overriding yum/dnf commands via cliwrap

https://github.com/coreos/rpm-ostree/issues/2883

> - rebranding `rpm-ostree`

https://github.com/coreos/rpm-ostree/issues/405

>
> I feel like we'd have a more cohesive discussion if we tried to break this up
> into smaller pieces so we can have a more focused discussion. 

These links were already mostly in the proposal, but I've added them again here 
for convenience.

> As written this proposal is hard to swallow.

Two things:

- This proposal is explicitly trying to tie everything together.  I think 
without the "bigger picture", it's actually *more* confusing.  For example, 
just pushing the container images does little unless we invest in them as a 
derivation source and build tooling and docs around them.
- At a very practical level, I find context switching in Mediawiki syntax to be 
rather tedious.  I'd prefer to discuss the individual sections in the already 
extant tracker issues that accept Markdown and have a well-understood and used 
discussion mechanism.  (Or of course, email here)

But you're certainly not wrong, it *is* a big proposal.  Happy to make changes, 
I'm mainly just saying there already are dedicated sub-proposal trackers to 
discuss the details of those.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137401] perl-Alien-pkgconf-0.19 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137401



--- Comment #6 from Fedora Update System  ---
FEDORA-2022-b9023cc963 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-b9023cc963`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-b9023cc963

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=2137401
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-HTTP-Daemon] PR #17: Update license to SPDX format

2022-10-25 Thread Michal Josef Špaček

mspacek merged a pull-request against the project: `perl-HTTP-Daemon` that you 
are following.

Merged pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-HTTP-Daemon/pull-request/17
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Fedora 37 compose report: 20221025.n.0 changes

2022-10-25 Thread Fedora Rawhide Report
OLD: Fedora-37-20221024.n.0
NEW: Fedora-37-20221025.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   13
Downgraded packages: 1

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   988.88 MiB
Size of downgraded packages: 2.37 MiB

Size change of upgraded packages:   1.21 MiB
Size change of downgraded packages: 117.49 KiB

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  OpenColorIO-2.1.2-4.fc37
Old package:  OpenColorIO-2.1.2-3.fc37
Summary:  Enables color transforms and image display across graphics apps
RPMs: OpenColorIO OpenColorIO-devel OpenColorIO-doc OpenColorIO-tools
Size: 10.86 MiB
Size change:  -10.04 KiB
Changelog:
  * Fri Oct 07 2022 Richard Shaw  - 2.1.2-4
  - Rebuild for OpenImageIO 2.4.4.2.


Package:  OpenImageIO-2.4.4.2-1.fc37
Old package:  OpenImageIO-2.3.19.0-1.fc37
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 20.73 MiB
Size change:  -1.48 MiB
Changelog:
  * Thu Oct 06 2022 Richard Shaw  - 2.3.20.0-1
  - Update to 2.3.20.0.

  * Fri Oct 07 2022 Richard Shaw  - 2.4.4.2-1
  - Update to 2.4.4.2.


Package:  abrt-2.15.1-6.fc37
Old package:  abrt-2.15.1-5.fc37
Summary:  Automatic bug detection and reporting tool
RPMs: abrt abrt-addon-ccpp abrt-addon-kerneloops abrt-addon-pstoreoops 
abrt-addon-upload-watch abrt-addon-vmcore abrt-addon-xorg abrt-atomic abrt-cli 
abrt-console-notification abrt-dbus abrt-desktop abrt-devel abrt-gui 
abrt-gui-devel abrt-gui-libs abrt-libs abrt-plugin-bodhi abrt-plugin-machine-id 
abrt-retrace-client abrt-tui python3-abrt python3-abrt-addon 
python3-abrt-container-addon python3-abrt-doc
Size: 5.29 MiB
Size change:  4.75 KiB
Changelog:
  * Wed Oct 19 2022 Michal Srb  - 2.15.1-6
  - abrt-journal: First seek the journal tail and then set filters
  - Resolves: rhbz#2128662


Package:  avocado-vt-82.0-3.module_f37+15475+05f2d403
Old package:  avocado-vt-82.0-3.module_f37+14076+b5a6614e
Summary:  Avocado Virt Test Plugin
RPMs: python3-avocado-vt
Size: 8.88 MiB
Size change:  723.00 KiB

Package:  blender-1:3.3.1-1.fc37
Old package:  blender-1:3.3.0-4.fc37
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-rpm-macros
Size: 153.03 MiB
Size change:  148.16 KiB
Changelog:
  * Sat Oct 15 2022 Luya Tshimbalanga  1:3.3.1-1
  - Update to blender 3.1.1


Package:  gnome-control-center-43.0-2.fc37
Old package:  gnome-control-center-43.0-1.fc37
Summary:  Utilities to configure the GNOME desktop
RPMs: gnome-control-center gnome-control-center-filesystem
Size: 19.92 MiB
Size change:  880 B
Changelog:
  * Fri Oct 21 2022 Adam Williamson  43.0-2
  - Backport MR #1478 to fix crash on empty EAP password edit (#2136471)


Package:  gnome-software-43.0-4.fc37
Old package:  gnome-software-43.0-3.fc37
Summary:  A software center for GNOME
RPMs: gnome-software gnome-software-devel gnome-software-rpm-ostree
Size: 10.18 MiB
Size change:  5.64 KiB
Changelog:
  * Mon Oct 17 2022 Tomas Popela  - 43.0-4
  - Resolves: #2135289 (RPM packaged applications are presented in
GNOME Software and preferred over Flatpaks on Silverblue)


Package:  kernel-5.19.16-301.fc37
Old package:  kernel-5.19.15-301.fc37
Summary:  The Linux kernel
RPMs: kernel kernel-core kernel-debug kernel-debug-core 
kernel-debug-devel kernel-debug-devel-matched kernel-debug-modules 
kernel-debug-modules-extra kernel-debug-modules-internal kernel-devel 
kernel-devel-matched kernel-doc kernel-modules kernel-modules-extra 
kernel-modules-internal
Size: 596.72 MiB
Size change:  417.79 KiB
Changelog:
  * Sat Oct 15 2022 Justin M. Forbes  [5.19.16-0]
  - Reset build for version bump (Justin M. Forbes)
  - Linux v5.19.16

  * Fri Oct 21 2022 Justin M. Forbes  [5.19.16-1]
  - Bump for build (Justin M. Forbes)
  - drm/vc4: hdmi: Fix HSM clock too low on Pi4 (max...@cerno.tech)


Package:  luxcorerender-2.6-7.fc37
Old package:  luxcorerender-2.6-6.fc37
Summary:  LuxCore Renderer, an unbiased rendering system
RPMs: blender-luxcorerender luxcorerender luxcorerender-core 
luxcorerender-devel python3-luxcorerender
Size: 27.53 MiB
Size change:  -21.89 KiB
Changelog:
  * Fri Oct 07 2022 Richard Shaw  - 2.6-7
  - Rebuild for OpenImageIO 2.4.4.2.


Package:  openshadinglanguage-1.12.6.2-2.fc37
Old package:  openshadinglanguage-1.11.17.0-4.fc37
Summary:  Advanced shading language for production GI renderers
RPMs: OpenImageIO-plugin-osl openshadinglanguage 
openshadinglanguage-common-headers openshadinglanguage-devel 
openshadinglanguage-doc

[rpms/perl-HTTP-Daemon] PR #17: Update license to SPDX format

2022-10-25 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-HTTP-Daemon` that 
you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTTP-Daemon/pull-request/17
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-25 Thread Rahul Sundaram
Hi


On Tue, Oct 25, 2022 at 7:14 AM Jaroslav Mracek wrote:

>
> DNF team has experience with replacing of YUM in Fedora and RHEL. It give
> us an advantage to not repeat the same mistakes. We already know that
> shipping DNF as YUM was not a good idea.
>

This response really doesn't clarify what the end result is supposed to be.
  Are you planning to maintain a symlink from DNF and Yum to DNF5 after the
transition is complete or not?

Rahul
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2115572] Please build perl-Number-Bytes-Human for EPEL 9

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2115572

Michal Ambroz  changed:

   What|Removed |Added

  Flags|needinfo?(re...@seznam.cz)  |




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2115572
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-25 Thread Jaroslav Mracek
> Are there going to be provided some deprecation warning in current 
> version of DNF, should some commands or option change in DNF5? I think 
> this would help prepare users for the changes in advance and possible 
> make the transition smoother.
> 
> Vít
> 
> 
> 
> Dne 06. 09. 22 v 20:28 Ben Cotton napsal(a):

We will create man page for differences between DNF and DNF5 [WIP].

Jaroslav
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137401] perl-Alien-pkgconf-0.19 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137401

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2022-0f2aa6117a has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-0f2aa6117a`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-0f2aa6117a

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=2137401
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2136929] perl-Log-Log4perl-1.57 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2136929

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-c7abe9199a has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-c7abe9199a`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-c7abe9199a

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=2136929
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-25 Thread Jaroslav Mracek
> Dne 17. 10. 22 v 9:28 Jaroslav Mracek napsal(a):
> 
> 
> So why there is proposed the `/usr/bin/dnf` symlink? To create the 
> confusion again?

For Fedora 38 we cannot ship DNF binary. We also cannot provide dnf, hawkey or 
libdnf in Python bindings, because the those name spaces are already taken by 
DNF, LIBDNF and there is a requirement to keep python3-dnf around (Fedora 39). 
Then we want to unify brand - therefore we do not want to ship product with one 
name, providing different name for bindings and so on. 

 
 
> 
> This ^^ is self-imposed restriction. From practical POV, if DNF5 works 
> and provides all required functionality, there is no need for parallel 
> installability.
> 

Porting to DNF5 API will require some transition period even when all required 
functionality will be in place.

> 
> 
> I am not convinced. Your store is not consistent. On one hand, you want 
> to provide as much compatibility as possible, but on the other hand, you 
> does not hesitate to break the first think you can and that is the name.
> 
> Honestly, if DNF is written in Python or C++ and if there are libraries 
> or bindings or what not is just implementation detail. I understand it 
> matters to you, as a developer. I understand it matters to several other 
> people maintaining some DNF plugins. But it does not matter and should 
> not really matter to end user.
> 
> IOW if we need to update the documentation for DNF in a way that `dnf 
> install --some-option something` does not work DNF5 and `dnf install 
> --new-option something` must be used, that is fine. But if the change 
> was to `dnf5 install --some-option something`, because "we keep the 
> compatibility, the options are the same of course", then this would be 
> ridiculous. Yes, I know "the symlink". But you want to avoid confusion 
> as you said, then why the symlink which will create just confusion.

DNF team has experience with replacing of YUM in Fedora and RHEL. It give us an 
advantage to not repeat the same mistakes. We already know that shipping DNF as 
YUM was not a good idea. There was a lot of confusions therefore in RHEL9 we 
ship DNF as DNF and not YUM. DNF provides great compatibility with YUM but 
anyway it was not the best move that we did. The naming is really tricky and we 
cannot satisfy everyone.

Jaroslav

> 
> 
> Vít
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Fedora rawhide compose report: 20221025.n.0 changes

2022-10-25 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20221024.n.1
NEW: Fedora-Rawhide-20221025.n.0

= SUMMARY =
Added images:4
Dropped images:  1
Added packages:  2
Dropped packages:0
Upgraded packages:   6
Downgraded packages: 0

Size of added packages:  1.40 MiB
Size of dropped packages:0 B
Size of upgraded packages:   278.91 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   375.68 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Cloud_Base vagrant-libvirt x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20221025.n.0.x86_64.vagrant-libvirt.box
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20221025.n.0.ppc64le.tar.xz
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-Rawhide-20221025.n.0.aarch64.tar.xz
Image: Cloud_Base vagrant-virtualbox x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20221025.n.0.x86_64.vagrant-virtualbox.box

= DROPPED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20221024.n.1.ppc64le.tar.xz

= ADDED PACKAGES =
Package: gnome-shell-extension-blur-my-shell-44-1.fc38
Summary: Adds a blur look to different parts of the GNOME Shell
RPMs:gnome-shell-extension-blur-my-shell
Size:100.67 KiB

Package: python-plotnine-0.10.1-3.fc38
Summary: Implementation of a grammar of graphics in Python, based on ggplot2
RPMs:python3-plotnine python3-plotnine+extra
Size:1.30 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  aime-8.20221019-1.fc38
Old package:  aime-8.20221012-1.fc38
Summary:  An application embeddable programming language interpreter
RPMs: aime aime-devel
Size: 3.58 MiB
Size change:  7.33 KiB
Changelog:
  * Mon Oct 24 2022 Filipe Rosset  - 8.20221019-1
  - Update to 8.20221019 fixes rhbz#2136213


Package:  gnome-shell-extension-sound-output-device-chooser-43-4.fc38
Old package:  gnome-shell-extension-sound-output-device-chooser-43-2.fc37
Summary:  GNOME Shell extension for selecting sound devices
RPMs: gnome-shell-extension-sound-output-device-chooser
Size: 57.52 KiB
Size change:  192 B
Changelog:
  * Mon Oct 24 2022 Carl George  43-3
  - Change license field to SPDX identifier

  * Mon Oct 24 2022 Carl George  43-4
  - Change requires from gnome-shell-extension-common to gnome-shell


Package:  home-assistant-cli-0.9.6-1.fc38
Old package:  home-assistant-cli-0.9.5-1.fc38
Summary:  Command-line tool for Home Assistant
RPMs: home-assistant-cli
Size: 120.47 KiB
Size change:  158 B
Changelog:
  * Mon Oct 24 2022 Fabian Affolter  - 0.9.6-1
  - Update to latest upstream release 0.9.6


Package:  parallel-20221022-1.fc38
Old package:  parallel-20220922-1.fc38
Summary:  Shell tool for executing jobs in parallel
RPMs: parallel
Size: 413.17 KiB
Size change:  745 B
Changelog:
  * Mon Oct 24 2022 Filipe Rosset  20221022-1
  - update to 20221022


Package:  python-setuptools-65.5.0-1.fc38
Old package:  python-setuptools-65.3.0-1.fc38
Summary:  Easily build and distribute Python packages
RPMs: python-setuptools-wheel python3-setuptools
Size: 2.35 MiB
Size change:  1.57 KiB
Changelog:
  * Thu Oct 13 2022 Miro Hron??ok  - 65.4.1-1
  - Update to 65.4.1
  - Update the RPM License field to use SPDX expressions

  * Fri Oct 14 2022 Miro Hron??ok  - 65.5.0-1
  - Update to 65.5.0
  - Fixes: rhbz#2129562


Package:  wine-7.19-1.fc38
Old package:  wine-7.18-2.fc38
Summary:  A compatibility layer for windows applications
RPMs: wine wine-alsa wine-arial-fonts wine-cms wine-common wine-core 
wine-courier-fonts wine-desktop wine-devel wine-filesystem wine-fixedsys-fonts 
wine-fonts wine-ldap wine-marlett-fonts wine-ms-sans-serif-fonts wine-openal 
wine-opencl wine-pulseaudio wine-small-fonts wine-symbol-fonts 
wine-system-fonts wine-systemd wine-tahoma-fonts wine-tahoma-fonts-system 
wine-times-new-roman-fonts wine-times-new-roman-fonts-system wine-twain 
wine-webdings-fonts wine-wingdings-fonts wine-wingdings-fonts-system
Size: 272.40 MiB
Size change:  365.70 KiB
Changelog:
  * Mon Oct 24 2022 Michael Cronenworth  - 7.19-1
  - version update



= DOWNGRADED PACKAGES =___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-25 Thread Jaroslav Mracek
I am sorry, `libdnf-devel` and `libdnf5-devel` conflict on file level. We had a 
plan to remove the conflict, but community did not considered it as required, 
therefore we drop that plan. Also the conflict we can take as a feature. The 
code that would use libdnf and libdnf5 at the same time would be a nightmare.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: c99-port branches in dist-git

2022-10-25 Thread Florian Weimer
* Richard W. M. Jones:

> On Wed, Oct 19, 2022 at 11:30:59AM +0200, Florian Weimer wrote:
>> I'm going to push a branch to dist-git for very few packages (so far gcc
>> and redhat-rpm-config) which will be used by COPR builds to port Fedora
>> to C99 and later language standards.
>> 
>> GCC 14 is expected to reject certain constructs that were removed from C
>> in C99:
>
> If we're changing defaults, could we make -fPIC the default and have
> -fno-pic be an explicit choice?

There's no consensus for within Red Hat Platform Tools to build GCC with
--enable-default-pie (which is the closest that exists upstream today),
so no.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


/usr/lib/debug/usr/lib64/libpython3.so-3.11.0-1.fc38.x86_64.debug in python3.11-debuginfo-3.11.0-1.fc38 on x86_64 is missing ELF sections

2022-10-25 Thread Miro Hrončok

Hey,

rpminspect tells me that:

/usr/lib/debug/usr/lib64/libpython3.so-3.11.0-1.fc38.x86_64.debug in 
python3.11-debuginfo-3.11.0-1.fc38 on x86_64 is missing ELF sections


Details: Missing: .debug_info


On rawhide and f37.

Is this something I need to worry about? What do I do about it?

--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-HTTP-Message] PR #22: Update license to SPDX

2022-10-25 Thread Michal Josef Špaček

mspacek merged a pull-request against the project: `perl-HTTP-Message` that you 
are following.

Merged pull-request:

``
Update license to SPDX
``

https://src.fedoraproject.org/rpms/perl-HTTP-Message/pull-request/22
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-HTTP-Message] PR #22: Update license to SPDX

2022-10-25 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-HTTP-Message` that 
you are following:
``
Update license to SPDX
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTTP-Message/pull-request/22
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: c99-port branches in dist-git

2022-10-25 Thread Richard W.M. Jones
On Wed, Oct 19, 2022 at 11:30:59AM +0200, Florian Weimer wrote:
> I'm going to push a branch to dist-git for very few packages (so far gcc
> and redhat-rpm-config) which will be used by COPR builds to port Fedora
> to C99 and later language standards.
> 
> GCC 14 is expected to reject certain constructs that were removed from C
> in C99:

If we're changing defaults, could we make -fPIC the default and have
-fno-pic be an explicit choice?

Finding every place in the OCaml toolchain that passes flags to the
compiler is very tedious, I had another bug filed about it only a few
days ago.  This would all go away if -fPIC was simply the default.
AIUI on x86-64 because of rip-relative addressing there's no serious
penalty.

Rich.

>   * implicit function declarations
>   * implicit ints
>   * implicit conversion between pointers and int
> (that may not have been in C89 even; details still pending)
> 
> It's possible to build with -std=gnu89 or -std=c89 to re-enable these
> constructs, or fix the sources not to use them.  Implicit function
> declarations in particular have wasted countless programmer hours due to
> difficult-to-track-down ABI mismatches, so it's definitely desirable to
> cause them to fail the build.
> 
> We have tooling that identifies these constructs if GCC is used, even if
> they are used in configure check.  Unexpected failures in configure
> checks can be tricky because if the package is well-written, the end
> result is still a consistent build with some expected failures missing,
> corresponding testsuite bits disabled etc.
> 
> We will contribute fixes upstream and to rawhide, either by fixing the
> sources or switch to C89 mode where it is unlikely source changes will
> be acceptable to upstream.  The c99-port dist-git branch will only be
> used for our support tooling that should not be used by production
> builds in the rawhide buildroot.  As this is necessarily a
> cross-distribution effort, there will be some tracking mechanism to
> record and share patches for which no active upstream exists anymore.
> 
> C++ packages are only affected in so far as they use the C compiler in
> configure checks: these constructs haven't been part of C++ for a long,
> long time and may not have been implemented in G++, ever.
> 
> I hope to submit a formal Fedora 40 change proposal after some initial
> experiments.
> 
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137401] perl-Alien-pkgconf-0.19 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137401



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-519fdf2838 has been submitted as an update to Fedora 36.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-519fdf2838


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137401
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137401] perl-Alien-pkgconf-0.19 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137401



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137401
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137401] perl-Alien-pkgconf-0.19 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137401



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-0f2aa6117a has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-0f2aa6117a


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137401
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137401] perl-Alien-pkgconf-0.19 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137401

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-Alien-pkgconf-0.19-1.f
   ||c38
 Status|ASSIGNED|MODIFIED



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137401
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137401] perl-Alien-pkgconf-0.19 is available

2022-10-25 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137401

Petr Pisar  changed:

   What|Removed |Added

 CC|ppi...@redhat.com   |
 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137401
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue