Nonresponsive maintainer check for Scott Tsai
Hello, Does anyone know how to contact Scott Tsai? He appears to still be listed as the maintainer for verilator despite not being active (from what I can see) for years. Does anyone know how to contact him? Non-responsive maintainer bug for scottt: https://bugzilla.redhat.com/show_bug.cgi?id=2268651 Other seemingly unmaintained packages: https://src.fedoraproject.org/rpms/udis86 https://src.fedoraproject.org/rpms/urjtag This is listed the first step of the Fedora Non-responsive package maintainer policy: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/#steps -- ___ 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 2268649] New: perl-Perl-Version-1.017 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268649 Bug ID: 2268649 Summary: perl-Perl-Version-1.017 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Perl-Version Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.017 Upstream release that is considered latest: 1.017 Current version/release in rawhide: 1.016-3.fc40 URL: https://metacpan.org/dist/Perl-Version/ 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/12552/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Perl-Version -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268649 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268649%23c0 -- ___ 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 2265725] perl-CPAN-Perl-Releases-5.20240223 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2265725 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0240223-1.fc41 |0240223-1.fc41 |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0240223-1.fc38 |0240223-1.fc38 ||perl-CPAN-Perl-Releases-5.2 ||0240223-1.fc39 --- Comment #10 from Fedora Update System --- FEDORA-2024-c6077a7811 (perl-CPAN-Perl-Releases-5.20240223-1.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2265725 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202265725%23c10 -- ___ 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 2268556] perl-Business-ISBN-Data-20240308.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268556 --- Comment #4 from Fedora Update System --- FEDORA-2024-0c2cd6ba0f has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-0c2cd6ba0f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-0c2cd6ba0f 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=2268556 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268556%23c4 -- ___ 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 2268603] perl-Locale-Codes-3.78 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268603 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-2024-c4f7fa0b66 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-c4f7fa0b66` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-c4f7fa0b66 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=2268603 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268603%23c3 -- ___ 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
2024-03-11 @ ** 16:00 ** UTC - Fedora 40 Blocker Review Meeting
# F40 Blocker Review meeting # Date: 2024-03-11 # Time: ** 16:00 ** UTC # Location: https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org Hi folks! It's time for another blocker review meeting. We have 2 proposed blockers and 5 proposed freeze exceptions for Beta, and 4 proposed blockers for Final. Please note that summer time starts in most of North America on Sunday, and we follow that time for these meetings, so the meeting time in UTC has changed. If you put your clocks forward this Sunday, the meeting will be at the same local time as it was last week. If you do not, the meeting will be one hour *earlier* than it was last week. You can always run `date -u` to see the current UTC time and check, if you're not sure. Here is a handy link which should show you the meeting time in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+40+Blocker+review+meeting=20240311T16=1440=2 The meeting will be on Matrix. Click the link above to join in a web client - you can authenticate with your FAS account - or use a dedicated client of your choosing. If you have time this weekend, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . Remember, you can also now vote on bugs outside of review meetings! If you look at the bug list in the blockerbugs app, you'll see links labeled "Vote!" next to all proposed blockers and freeze exceptions. Those links take you to tickets where you can vote. https://pagure.io/fedora-qa/blocker-review has instructions on how exactly you do it. We usually go through the tickets shortly before the meeting and apply any clear votes, so the meeting will just cover bugs where there wasn't a clear outcome in the ticket voting yet. **THIS MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!** We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F40 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good weekend and see you on Monday! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org 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
[Bug 2175807] perl-Git-Repository-1.325-7.fc39 FTBFS: t/20-simple.t fails EDITOR tests
https://bugzilla.redhat.com/show_bug.cgi?id=2175807 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Git-Repository-1.325-8 ||.fc38 Resolution|RAWHIDE |ERRATA --- Comment #4 from Fedora Update System --- FEDORA-2024-3cd7522ef5 (perl-Git-Repository-1.325-8.fc38) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2175807 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202175807%23c4 -- ___ 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 2265725] perl-CPAN-Perl-Releases-5.20240223 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2265725 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0240223-1.fc41 |0240223-1.fc41 ||perl-CPAN-Perl-Releases-5.2 ||0240223-1.fc38 --- Comment #9 from Fedora Update System --- FEDORA-2024-06af83d4e1 (perl-CPAN-Perl-Releases-5.20240223-1.fc38) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2265725 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202265725%23c9 -- ___ 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 rawhide compose report: 20240308.n.1 changes
OLD: Fedora-Rawhide-20240307.n.0 NEW: Fedora-Rawhide-20240308.n.1 = SUMMARY = Added images:4 Dropped images: 37 Added packages: 7 Dropped packages:0 Upgraded packages: 137 Downgraded packages: 0 Size of added packages: 70.81 MiB Size of dropped packages:0 B Size of upgraded packages: 5.05 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 36.46 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Workstation live-osbuild x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20240308.n.1.x86_64.iso Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20240308.n.1.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20240308.n.1.iso Image: Workstation live-osbuild aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20240308.n.1.aarch64.iso = DROPPED IMAGES = Image: Kinoite ociarchive x86_64 Path: Kinoite/x86_64/images/Fedora-Kinoite-Rawhide.20240307.n.0.ociarchive Image: Container_Toolbox docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Toolbox-Rawhide-20240307.n.0.ppc64le.tar.xz Image: Container_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Base-Rawhide-20240307.n.0.x86_64.tar.xz Image: Cloud_Base qcow2 x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-20240307.n.0.x86_64.qcow2 Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20240307.n.0.iso Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20240307.n.0.ppc64le.tar.xz Image: Sericea ociarchive x86_64 Path: Sericea/x86_64/images/Fedora-Sericea-Rawhide.20240307.n.0.ociarchive Image: Cloud_Base raw-xz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-20240307.n.0.x86_64.raw.xz Image: Container_Toolbox docker s390x Path: Container/s390x/images/Fedora-Container-Toolbox-Rawhide-20240307.n.0.s390x.tar.xz Image: Onyx ociarchive x86_64 Path: Onyx/x86_64/images/Fedora-Onyx-Rawhide.20240307.n.0.ociarchive Image: Silverblue ociarchive x86_64 Path: Silverblue/x86_64/images/Fedora-Silverblue-Rawhide.20240307.n.0.ociarchive Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20240307.n.0.x86_64.vagrant-libvirt.box Image: Cloud_Base vpc x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Azure-Rawhide-20240307.n.0.x86_64.vhd Image: Container_Toolbox docker x86_64 Path: Container/x86_64/images/Fedora-Container-Toolbox-Rawhide-20240307.n.0.x86_64.tar.xz Image: Container_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Base-Rawhide-20240307.n.0.aarch64.tar.xz Image: Cloud_Base qcow2 aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20240307.n.0.aarch64.qcow2 Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20240307.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20240307.n.0.s390x.tar.xz Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20240307.n.0.x86_64.vagrant-virtualbox.box Image: Kinoite ociarchive aarch64 Path: Kinoite/aarch64/images/Fedora-Kinoite-Rawhide.20240307.n.0.ociarchive Image: Container_Minimal_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20240307.n.0.x86_64.tar.xz Image: Sericea ociarchive aarch64 Path: Sericea/aarch64/images/Fedora-Sericea-Rawhide.20240307.n.0.ociarchive Image: Cloud_Base raw-xz aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20240307.n.0.aarch64.raw.xz Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20240307.n.0.iso Image: Kinoite ociarchive ppc64le Path: Kinoite/ppc64le/images/Fedora-Kinoite-Rawhide.20240307.n.0.ociarchive Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20240307.n.0.iso Image: Silverblue ociarchive aarch64 Path: Silverblue/aarch64/images/Fedora-Silverblue-Rawhide.20240307.n.0.ociarchive Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20240307.n.0.ppc64le.tar.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20240307.n.0.ppc64le.qcow2 Image: Cloud_Base vpc aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-Azure-Rawhide-20240307.n.0.aarch64.vhd Image: Container_Toolbox docker aarch64 Path: Container/aarch64/images/Fedora-Container-Toolbox-Rawhide-20240307.n.0.aarch64.tar.xz Image: Cloud_Base tar-gz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-Rawhide-20240307.n.0.x86_64.tar.gz Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20240307.n.0.ppc64le.raw.xz Image: Container_Minimal_Base docker aarch64 Path
[Bug 2268634] New: perl-Mojolicious-9.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268634 Bug ID: 2268634 Summary: perl-Mojolicious-9.36 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Mojolicious Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org, robinlee.s...@gmail.com, yan...@declera.com Target Milestone: --- Classification: Fedora Releases retrieved: 9.36 Upstream release that is considered latest: 9.36 Current version/release in rawhide: 9.35-3.fc40 URL: https://metacpan.org/release/Mojolicious 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/5966/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Mojolicious -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268634 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268634%23c0 -- ___ 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
F41 Change Proposal: SPDX License Phase 4 (The last one)(system wide)
Wiki - https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 This is a proposed Change for Fedora Linux. 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 == The fourth phase of transition from using Fedora's short names for licenses to [https://spdx.org/licenses/ SPDX identifiers] in the License: field of Fedora package spec files. This phase focuses on migrating the remaining packages. == Owner == * Name: [[User:msuchy| Miroslav Suchý]], [[User:jlovejoy| Jilayne Lovejoy]], [[User:dcantrell| David Cantrell]], [[User:ref| Richard Fontana]] * Email: msu...@redhat.com, dcantr...@redhat.com, jlove...@redhat.com, rfont...@redhat.com == Current status == * [https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit#gid=0 Burndow chart] == Detailed Description == This is follow-up of [[Changes/SPDX_Licenses_Phase_3|Phase 3]]. During this phase, all remaining packages should be migrated to use SPDX license identifiers in the License: field of the package spec file. So far, package maintainers have been updating their packages in accordance with the guidance provided at https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ and filing issues in the [https://gitlab.com/fedora/legal/fedora-license-data fedora-license-data repo]. Miroslav has been tracking how many packages that have been updated. Given the large number of packages in Fedora, this progress is good, but slow. In this phase, all remaining packages will be converted automatically when possible. When human analysis is required then Bugzilla entry will be created. All these Bugzillas will block tracking bug to easily find these issues. == Feedback == See [[Changes/SPDX_Licenses_Phase_1#Feedback|feedback section of Phase 1]] Discussions on mailing list: * [https://lists.fedoraproject.org/archives/search?q=SPDX+statistics=1=devel%40lists.fedoraproject.org=date-desc regular SPDX Statistics] * [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3TGCSROJTSX5PXZLKOHCOMVIBTZDORNS/ SPDX - How to handle MIT and BSD] Challenges: * license-fedora2spdx tool uses mapping of legacy Fedora short names to SPDX identifiers using the [https://gitlab.com/fedora/legal/fedora-license-data/-/tree/main fedora-license-data] to suggest SPDX identifiers. Where there is an apparent one-to-one mapping, the package maintainer could simply update the License field: and move on. * for many packages, particularly packages that use "umbrella" legacy short names that may refer to a large set of unrelated or loosely-related licenses, further inspection will be needed. Currently, Fedora documentation provides sparse advice on how to do this inspection and thus, a range of methods are used. == Benefit to Fedora == The use of standardized identifiers for licenses will align Fedora with other distributions and facilitate efficient and reliable identification of licenses. Depending on the level of diligence done in this transition, Fedora could be positioned as a leader and contributor to better license information upstream (of Fedora). == Scope == * Change Owners: ** Continue adding newly found licenses to fedora-license-data and to SPDX.org list. ** Continue to report progress ** Automatically convert packages in several bulks using proven packager rights. These changes will be announced in advance on the devel mailing list. ** When the automatic conversion is impossible, Change Owners will create a Bugzilla entry asking package maintainers to migrate the package. * Other developers: ** All packages (during the package review) should use the SPDX expression. - this is redundant as this has already been approved since Phase 1, but it should be reminded. ** Migrate the existing License tag from a short name to an SPDX expression. * Release engineering: nothing * Policies and guidelines: all done in previous phases * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora. During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula. == How To Test == See [[Changes/SPDX_Licenses_Phase_1#How_To_Test|How to test section of Phase 1]] == User Experience == Users should be able to use standard software tools that audit licenses. E.g. for Software Bills of Materials. == Dependencies == No other dependencies. == Contingency Plan == * Contingency mechanism: There will be no way back. We are already beyond of point to return. We are heading to explore strange new
F41 Change Proposal: SPDX License Phase 4 (The last one)(system wide)
Wiki - https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 This is a proposed Change for Fedora Linux. 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 == The fourth phase of transition from using Fedora's short names for licenses to [https://spdx.org/licenses/ SPDX identifiers] in the License: field of Fedora package spec files. This phase focuses on migrating the remaining packages. == Owner == * Name: [[User:msuchy| Miroslav Suchý]], [[User:jlovejoy| Jilayne Lovejoy]], [[User:dcantrell| David Cantrell]], [[User:ref| Richard Fontana]] * Email: msu...@redhat.com, dcantr...@redhat.com, jlove...@redhat.com, rfont...@redhat.com == Current status == * [https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit#gid=0 Burndow chart] == Detailed Description == This is follow-up of [[Changes/SPDX_Licenses_Phase_3|Phase 3]]. During this phase, all remaining packages should be migrated to use SPDX license identifiers in the License: field of the package spec file. So far, package maintainers have been updating their packages in accordance with the guidance provided at https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ and filing issues in the [https://gitlab.com/fedora/legal/fedora-license-data fedora-license-data repo]. Miroslav has been tracking how many packages that have been updated. Given the large number of packages in Fedora, this progress is good, but slow. In this phase, all remaining packages will be converted automatically when possible. When human analysis is required then Bugzilla entry will be created. All these Bugzillas will block tracking bug to easily find these issues. == Feedback == See [[Changes/SPDX_Licenses_Phase_1#Feedback|feedback section of Phase 1]] Discussions on mailing list: * [https://lists.fedoraproject.org/archives/search?q=SPDX+statistics=1=devel%40lists.fedoraproject.org=date-desc regular SPDX Statistics] * [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3TGCSROJTSX5PXZLKOHCOMVIBTZDORNS/ SPDX - How to handle MIT and BSD] Challenges: * license-fedora2spdx tool uses mapping of legacy Fedora short names to SPDX identifiers using the [https://gitlab.com/fedora/legal/fedora-license-data/-/tree/main fedora-license-data] to suggest SPDX identifiers. Where there is an apparent one-to-one mapping, the package maintainer could simply update the License field: and move on. * for many packages, particularly packages that use "umbrella" legacy short names that may refer to a large set of unrelated or loosely-related licenses, further inspection will be needed. Currently, Fedora documentation provides sparse advice on how to do this inspection and thus, a range of methods are used. == Benefit to Fedora == The use of standardized identifiers for licenses will align Fedora with other distributions and facilitate efficient and reliable identification of licenses. Depending on the level of diligence done in this transition, Fedora could be positioned as a leader and contributor to better license information upstream (of Fedora). == Scope == * Change Owners: ** Continue adding newly found licenses to fedora-license-data and to SPDX.org list. ** Continue to report progress ** Automatically convert packages in several bulks using proven packager rights. These changes will be announced in advance on the devel mailing list. ** When the automatic conversion is impossible, Change Owners will create a Bugzilla entry asking package maintainers to migrate the package. * Other developers: ** All packages (during the package review) should use the SPDX expression. - this is redundant as this has already been approved since Phase 1, but it should be reminded. ** Migrate the existing License tag from a short name to an SPDX expression. * Release engineering: nothing * Policies and guidelines: all done in previous phases * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora. During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula. == How To Test == See [[Changes/SPDX_Licenses_Phase_1#How_To_Test|How to test section of Phase 1]] == User Experience == Users should be able to use standard software tools that audit licenses. E.g. for Software Bills of Materials. == Dependencies == No other dependencies. == Contingency Plan == * Contingency mechanism: There will be no way back. We are already beyond of point to return. We are heading to explore strange new
z3 soname bump
In about a week, I will update the z3 package to version 4.13, which bumps the soname for the z3 library. No packages in Fedora consume z3-libs, other than some built from the z3 source RPM, so no other builds are necessary. -- Jerry James http://www.jamezone.org/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: PHP no 32 bit / PHP 64-bit only (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/php_no_32_bit
This is a proposed Change for Fedora Linux.
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 ==
Drop support for 32-bit builds
== Owner ==
* Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]]
* Email: remi at fedoraproject dot org
== Detailed Description ==
PHP is not a library, so is not multilib.
32-bit consumes builder CPU/time, but nothing is shipped in the repositories.
A lot of projects don't have 32-bit CI, so this may raise FTBFS (10 in
F40 Mass Rebuild)
Add for all extension packages:
'''ExcludeArch: %{ix86}'''
== Benefit to Fedora ==
Save developer and builder time.
== Scope ==
* Proposal owners: Mass rebuild.
* Other developers: N/A (not a System Wide Change)
* Release engineering:[https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
* N/A (no change in the repository)
== User Experience ==
* N/A (no change in available packages)
== Dependencies ==
All php-* packages (and some *-php)
== Contingency Plan ==
* Contingency mechanism: Drop not compatible packages.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
* N/A
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
___
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
F41 Change Proposal: PHP no 32 bit / PHP 64-bit only (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/php_no_32_bit
This is a proposed Change for Fedora Linux.
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 ==
Drop support for 32-bit builds
== Owner ==
* Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]]
* Email: remi at fedoraproject dot org
== Detailed Description ==
PHP is not a library, so is not multilib.
32-bit consumes builder CPU/time, but nothing is shipped in the repositories.
A lot of projects don't have 32-bit CI, so this may raise FTBFS (10 in
F40 Mass Rebuild)
Add for all extension packages:
'''ExcludeArch: %{ix86}'''
== Benefit to Fedora ==
Save developer and builder time.
== Scope ==
* Proposal owners: Mass rebuild.
* Other developers: N/A (not a System Wide Change)
* Release engineering:[https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
* N/A (no change in the repository)
== User Experience ==
* N/A (no change in available packages)
== Dependencies ==
All php-* packages (and some *-php)
== Contingency Plan ==
* Contingency mechanism: Drop not compatible packages.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
* N/A
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine This is a proposed Change for Fedora Linux. 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 == We disable support of engines in OpenSSL == Owner == * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] * Email: dbely...@redhat.com == Detailed Description == We are going to build OpenSSL without engine support. Engines are not FIPS compatible and corresponding API is deprecated since OpenSSL 3.0. The engine functionality we are aware of (PKCS#11, TPM) is either covered by providers or will be covered soon. == Feedback == == Benefit to Fedora == We get rid of deprecated functionality and enforce using up-to-date API. Engine support is deprecated in OpenSSL upstream, and after provider migration caused some deficiencies with engine support. No new features will be added to the engine. So we reduce the maintenance burden and potentially attack surface. It follows the approach planned for CentOS 10. == Scope == * Proposal owners: maintainers of packages enumerated here: https://clang.fedorapeople.org/c10s-engine-users/ plus probably owners of some Fedora-only packages For most of the packages the maintainers will just have to rebuild their packages after the OpenSSL change lands in compose. For several packages some patches should be implemented to prevent compilation errors. * Other developers: - * Release engineering: [https://pagure.io/releng/issues #Releng issue number] This change probably requires mass-rebuild. * Policies and guidelines: We need reject/modify packages providing OpenSSL engines * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == OpenSSL engines will no longer be supported. Engines will not be supported in openssl configuration files (presumably silently ignored). Users will have to reconfigure systems to providers if they use engines. == How To Test == OpenSSL libcrypto.so doesn't export any ENGINE_* symbols (~120 lines). Application is normally built. == User Experience == Users will have to reconfigure systems to providers if they use engines. No other changes are expected. == Dependencies == In theory, all OpenSSL-dependent packages. In practice, only those that explicitly use ENGINE api. == Contingency Plan == Reenable engine support but remove engine header file to allow old applications work preventing appearing new ones. * Contingency mechanism: (What to do? Who will do it?) rebuild OpenSSL and dependent packages * Contingency deadline: beta freeze? * Blocks release? Yes == Documentation == TBD == Release Notes == TBD -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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
F41 Change Proposal: Disable openSSL Engine Support (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoEngine This is a proposed Change for Fedora Linux. 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 == We disable support of engines in OpenSSL == Owner == * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] * Email: dbely...@redhat.com == Detailed Description == We are going to build OpenSSL without engine support. Engines are not FIPS compatible and corresponding API is deprecated since OpenSSL 3.0. The engine functionality we are aware of (PKCS#11, TPM) is either covered by providers or will be covered soon. == Feedback == == Benefit to Fedora == We get rid of deprecated functionality and enforce using up-to-date API. Engine support is deprecated in OpenSSL upstream, and after provider migration caused some deficiencies with engine support. No new features will be added to the engine. So we reduce the maintenance burden and potentially attack surface. It follows the approach planned for CentOS 10. == Scope == * Proposal owners: maintainers of packages enumerated here: https://clang.fedorapeople.org/c10s-engine-users/ plus probably owners of some Fedora-only packages For most of the packages the maintainers will just have to rebuild their packages after the OpenSSL change lands in compose. For several packages some patches should be implemented to prevent compilation errors. * Other developers: - * Release engineering: [https://pagure.io/releng/issues #Releng issue number] This change probably requires mass-rebuild. * Policies and guidelines: We need reject/modify packages providing OpenSSL engines * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == OpenSSL engines will no longer be supported. Engines will not be supported in openssl configuration files (presumably silently ignored). Users will have to reconfigure systems to providers if they use engines. == How To Test == OpenSSL libcrypto.so doesn't export any ENGINE_* symbols (~120 lines). Application is normally built. == User Experience == Users will have to reconfigure systems to providers if they use engines. No other changes are expected. == Dependencies == In theory, all OpenSSL-dependent packages. In practice, only those that explicitly use ENGINE api. == Contingency Plan == Reenable engine support but remove engine header file to allow old applications work preventing appearing new ones. * Contingency mechanism: (What to do? Who will do it?) rebuild OpenSSL and dependent packages * Contingency deadline: beta freeze? * Blocks release? Yes == Documentation == TBD == Release Notes == TBD -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: GNUToolchain (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/GNUToolchainF41 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 Fedora 41 GNU Toolchain to gcc 14.1+, binutils 2.42+, glibc 2.40 and gdb 14+. The set of core GNU Toolchain packages for Fedora 41 are as follows: * GNU C Compiler 14.1+ ** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp), Fortran (gfortran), D (phobos), Objective C/C++. * GNU Binary Utilities 2.42+ * GNU C Library 2.40 * GNU Debugger 14+ (immediately available in Fedora 40) The gcc 14.1+ change will be tracked in this top-level GNU Toolchain system-wide update. The binutils 2.42+ change will be tracked in this top-level GNU Toolchain system-wide update. The glibc 2.40 change will be tracked in this top-level GNU Toolchain system-wide update. The gdb 14+ update was rolled out across all Fedora releases and the move to 14+ will be handled in the same fashion. The debugger is capable of debugging the binary artifacts produced by the rest of the system toolchain. == Owner == * Name: [[User:codonell|Carlos O'Donell]] * Email: car...@redhat.com == Detailed Description == The GNU Compiler Collection, GNU Binary Utilities, GNU C Library, and the GNU Debugger make up the core part of the GNU Toolchain and it is useful for our users to transition these components as a complete implementation when making a new release of Fedora. The GNU Compiler Collection is expected to release version 14.1+ (point release), before the Fedora 41 release. It will contain many new features, documented here: https://gcc.gnu.org/gcc-14/changes.html. The latest point release for gcc 14.1+ will be included in Fedora 41, this will most probably be 14.2 or later. The GNU Binutils version 2.42 was released before Fedora 41; and we have already been using this version of binutils in Fedora Rawhide successfully to build the distribution. Given the present schedule for Fedora 41 we will continue to use Binutils 2.42 or 2.43 if deemed stable enough. As an experiment we will be trying out more frequent updates to the rawhide binutils, so that it remains closer to the upstream master sources. Currently rawhide binutils is synced twice a year, bu the plan is to try syncing monthly or maybe every fortnight. The GNU C Library version 2.40 is expected to be release before Fedora 41; we have started closely tracking the glibc 2.40 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 41 will branch after the release of glibc 2.40. However, the mass rebuild schedule means Fedora 41 will mass rebuild (if required) before the final release of glibc 2.40, but after the ABI is frozen. The GNU Debugger version 14+ has already been rolled out across all Fedora releases at the same time. == Benefit to Fedora == Stays up to date with latest features, improvements, security and bug fixes from gcc, glibc, binutils, and gdb upstream. The goal is to track and transition to the latest components of the GNU Toolchain. == Scope == * Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, gdb, ...) developers need to ensure that gcc, glibc, binutils, and gdb in rawhide are stable and ready for the Fedora 41 branch. * Other developers: Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files * Release engineering: A mass rebuild is strongly encouraged; [https://pagure.io/releng/issue/11898 #11898] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change * Alignment with Objectives: N/A == Upgrade/compatibility impact == The compiler, the static linker and the the library are backwards compatible with the previous version of Fedora. Any source level changes required for glibc 2.40 will be noted here: https://sourceware.org/glibc/wiki/Release/2.40#Packaging_Changes == How To Test == The GNU Compiler Collection has its own test suite which is run during the package build and examined by the gcc developers before being uploaded. The GNU C Library has its own test suite which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future we may also run the microbenchmark to look for performance regressions. The GNU Binutils has its own test suite which is run during the package build and examined by binutils developers before being uploaded. The regression test suite is run to verify the correct operation of the static linker and attendant
F41 Change Proposal: GNUToolchain (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/GNUToolchainF41 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 Fedora 41 GNU Toolchain to gcc 14.1+, binutils 2.42+, glibc 2.40 and gdb 14+. The set of core GNU Toolchain packages for Fedora 41 are as follows: * GNU C Compiler 14.1+ ** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp), Fortran (gfortran), D (phobos), Objective C/C++. * GNU Binary Utilities 2.42+ * GNU C Library 2.40 * GNU Debugger 14+ (immediately available in Fedora 40) The gcc 14.1+ change will be tracked in this top-level GNU Toolchain system-wide update. The binutils 2.42+ change will be tracked in this top-level GNU Toolchain system-wide update. The glibc 2.40 change will be tracked in this top-level GNU Toolchain system-wide update. The gdb 14+ update was rolled out across all Fedora releases and the move to 14+ will be handled in the same fashion. The debugger is capable of debugging the binary artifacts produced by the rest of the system toolchain. == Owner == * Name: [[User:codonell|Carlos O'Donell]] * Email: car...@redhat.com == Detailed Description == The GNU Compiler Collection, GNU Binary Utilities, GNU C Library, and the GNU Debugger make up the core part of the GNU Toolchain and it is useful for our users to transition these components as a complete implementation when making a new release of Fedora. The GNU Compiler Collection is expected to release version 14.1+ (point release), before the Fedora 41 release. It will contain many new features, documented here: https://gcc.gnu.org/gcc-14/changes.html. The latest point release for gcc 14.1+ will be included in Fedora 41, this will most probably be 14.2 or later. The GNU Binutils version 2.42 was released before Fedora 41; and we have already been using this version of binutils in Fedora Rawhide successfully to build the distribution. Given the present schedule for Fedora 41 we will continue to use Binutils 2.42 or 2.43 if deemed stable enough. As an experiment we will be trying out more frequent updates to the rawhide binutils, so that it remains closer to the upstream master sources. Currently rawhide binutils is synced twice a year, bu the plan is to try syncing monthly or maybe every fortnight. The GNU C Library version 2.40 is expected to be release before Fedora 41; we have started closely tracking the glibc 2.40 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 41 will branch after the release of glibc 2.40. However, the mass rebuild schedule means Fedora 41 will mass rebuild (if required) before the final release of glibc 2.40, but after the ABI is frozen. The GNU Debugger version 14+ has already been rolled out across all Fedora releases at the same time. == Benefit to Fedora == Stays up to date with latest features, improvements, security and bug fixes from gcc, glibc, binutils, and gdb upstream. The goal is to track and transition to the latest components of the GNU Toolchain. == Scope == * Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, gdb, ...) developers need to ensure that gcc, glibc, binutils, and gdb in rawhide are stable and ready for the Fedora 41 branch. * Other developers: Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files * Release engineering: A mass rebuild is strongly encouraged; [https://pagure.io/releng/issue/11898 #11898] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change * Alignment with Objectives: N/A == Upgrade/compatibility impact == The compiler, the static linker and the the library are backwards compatible with the previous version of Fedora. Any source level changes required for glibc 2.40 will be noted here: https://sourceware.org/glibc/wiki/Release/2.40#Packaging_Changes == How To Test == The GNU Compiler Collection has its own test suite which is run during the package build and examined by the gcc developers before being uploaded. The GNU C Library has its own test suite which is run during the package build and examined by the glibc developers before being uploaded. This test suite has over 6200 tests that run to verify the correct operation of the library. In the future we may also run the microbenchmark to look for performance regressions. The GNU Binutils has its own test suite which is run during the package build and examined by binutils developers before being uploaded. The regression test suite is run to verify the correct operation of the static linker and attendant
[Bug 2268603] perl-Locale-Codes-3.78 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268603 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #2 from Fedora Update System --- FEDORA-2024-c4f7fa0b66 (perl-Locale-Codes-3.78-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-c4f7fa0b66 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268603 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268603%23c2 -- ___ 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-Locale-Codes] PR #31: 3.78 bump
mspacek merged a pull-request against the project: `perl-Locale-Codes` that you are following. Merged pull-request: `` 3.78 bump `` https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/31 -- ___ 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-Locale-Codes] PR #31: 3.78 bump
mspacek opened a new pull-request against the project: `perl-Locale-Codes` that you are following: `` 3.78 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/31 -- ___ 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-Locale-Codes] PR #30: 3.78 bump
mspacek merged a pull-request against the project: `perl-Locale-Codes` that you are following. Merged pull-request: `` 3.78 bump `` https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/30 -- ___ 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-Locale-Codes] PR #30: 3.78 bump
mspacek opened a new pull-request against the project: `perl-Locale-Codes` that you are following: `` 3.78 bump `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/30 -- ___ 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 2268603] perl-Locale-Codes-3.78 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268603 Michal Josef Spacek changed: What|Removed |Added Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED --- Comment #1 from Michal Josef Spacek --- Changes: 3.78 2024-03-08 sbeck - NEW CODE(s) for rawhide and F40 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268603 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268603%23c1 -- ___ 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: reprodubible builds (re)introduction
On Fri, Mar 08, 2024 at 04:54:04PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Mar 08, 2024 at 09:07:30AM +0100, Petr Pisar wrote:
> > (2) Both perl-Alien-pkgconf NEVRAs reports a differing
> > /usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-pkgconf/status.json
> > content. That content looks likes this:
> >
> >
> > {"libs":"-lpkgconf","version":"2.1.0","install_type":"system","cflags":"-I/usr/include/pkgconf","dll":"/lib64/libpkgconf.so.4.0.0"}
> >
> > That means you had to perform rebuilds of the same NEVRA with different
> > libpkgconf-devel packages in the build roots. That looks like a bug in your
> > mini rebuild scheduler.
>
> Diffoscope says:
>
> ├── ./usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-pkgconf/status.json
> │ ├── Pretty-printed
> │ │┄ Ordering differences only
> │ │ @@ -1,7 +1,7 @@
> │ │ {
> │ │ "libs": "-lpkgconf",
> │ │ +"dll": "/lib64/libpkgconf.so.4.0.0",
> │ │ "version": "2.1.0",
> │ │ -"install_type": "system",
> │ │ "cflags": "-I/usr/include/pkgconf",
> │ │ -"dll": "/lib64/libpkgconf.so.4.0.0"
> │ │ +"install_type": "system"
> │ │ }
>
> It would be great to sort the dictionary to avoid this randomness.
And perl-Module-Build has:
├── ./usr/libexec/perl-Module-Build/_build/magicnum
│ @@ -1 +1 @@
│ -1016
│ +697476
It's generated via
$self->_write_data('magicnum', $self->magic_number(int rand 1_000_000));
It seems strange to fix the seed for tests like this…
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[CANCELED] Re: [Fedocal] Reminder meeting : ELN SIG
No agenda, no meeting. See you next time. On Thu, Mar 7, 2024 at 7:00 AM wrote: > > Dear all, > > You are kindly invited to the meeting: >ELN SIG on 2024-03-08 from 12:00:00 to 13:00:00 US/Eastern >At fedora-meet...@irc.libera.chat > > The meeting will be about: > > > > Source: https://calendar.fedoraproject.org//meeting/10568/ > > -- > ___ > 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 -- ___ 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: reprodubible builds (re)introduction
On Fri, Mar 08, 2024 at 09:07:30AM +0100, Petr Pisar wrote:
> V Thu, Mar 07, 2024 at 12:39:37PM +, Zbigniew Jędrzejewski-Szmek
> napsal(a):
> > The effort to make package builds in Fedora reproducible has picked up
> > steam again.
> > We now have a new website:
> > https://docs.fedoraproject.org/en-US/reproducible-builds
> > and an issue tracker: https://pagure.io/fedora-reproducible-builds/project
> > and a matrix room: https://matrix.to/#/#reproducible-builds:fedora.im
> >
> > We've done a mini rebuild using [1] for the package list [2] and results
> > are at [3].
> > (The result is a json dump of rpmdiff output by package. Generally, "" means
> > the rebuild was identical except for variable metadata, and non-empty
> > output else means that the rebuild was different.)
> >
> > [1] https://github.com/keszybz/fedora-repro-build
> > [2] https://fedorapeople.org/~zbyszek/builds-2024-02-fc41-filtered.txt
> > [3]
> > https://fedorapeople.org/~zbyszek/builds-2024-02-fc41-filtered.results.txt
> >
> Is this mini rebuild a one-shot thing, or are are you going to rebuild the
> packages repeatedly or use the results for something significant? I ask
> because I spotted some discrepancies in those text files:
Both ;) I'm working on the tooling to do the rebuilds, and the code is
still a bit rough, but also I'm still figuring out the design. Once
that done, we hope to hook this up to rebuilderd to get a continous
rebuild with a nice dashboard (https://wiki.archlinux.org/title/Rebuilderd).
For now, the results are being used to figure out a list of things to fix.
> (1) Some packages are listed twice, with different NEVRAs. E.g.
> perl-Alien-pkgconf or perl-RDF-RDFa-Generator.
This is because they were built multiple times in koji.
> (2) Both perl-Alien-pkgconf NEVRAs reports a differing
> /usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-pkgconf/status.json
> content. That content looks likes this:
>
>
> {"libs":"-lpkgconf","version":"2.1.0","install_type":"system","cflags":"-I/usr/include/pkgconf","dll":"/lib64/libpkgconf.so.4.0.0"}
>
> That means you had to perform rebuilds of the same NEVRA with different
> libpkgconf-devel packages in the build roots. That looks like a bug in your
> mini rebuild scheduler.
Diffoscope says:
├── ./usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-pkgconf/status.json
│ ├── Pretty-printed
│ │┄ Ordering differences only
│ │ @@ -1,7 +1,7 @@
│ │ {
│ │ "libs": "-lpkgconf",
│ │ +"dll": "/lib64/libpkgconf.so.4.0.0",
│ │ "version": "2.1.0",
│ │ -"install_type": "system",
│ │ "cflags": "-I/usr/include/pkgconf",
│ │ -"dll": "/lib64/libpkgconf.so.4.0.0"
│ │ +"install_type": "system"
│ │ }
It would be great to sort the dictionary to avoid this randomness.
> (3) Some packages listed in builds-2024-02-fc41-filtered.txt are missing from
> builds-2024-02-fc41-filtered.results.txt. E.g.
> perl-CPAN-Plugin-Sysdeps-0.73-1.fc41 is listed as COMPLETE, yet results are
> missing.
Yes. Some packages failed to build, and then I finished the build
early because there were already enough interesting results.
(The few failures I looked at were caused by differences in BR between
architectures. This is currently a corner case that I'm not sure how
to deal with. Most of the time, using a srpm from a different
architecture works fine, but in some cases the set of installed
packages would differ, and then I can't figure out which version of
the rpm for the local architecture would have been used and buildroot
creation fails. I would be happy to describe the problem in more
detail. It's also possible that other packages FTBFS, I didn't look
into this and I didn't save the logs.)
> (4) dnf5-5.1.13-1.fc41.src reports changes in Requires (e.g. "removed
> REQUIRES createrepo_c"). That again looks like you built the same NEVRA in
> different build roots (for some reason "%bcond_without tests" flipped).
Yes, the build root is different. I install the package set that was
used for the main package build and just call mock with that and it
does both srpm and the binary rpms there. But koji does the srpm build
in a separate buildroot that is smaller.
It would be fairly easy to get the buildroot listing for the srpm and
build the srpm separately. This wouldn't actually doesn't solve the
problem fully, because koji will use a random build architecture, so
we may potentially hit the problem that was described above for noarch
builds.
For now, I'm taking the pragmatic approach of ignoring changes in
PROVIDES/REQUIRES for the srpm. We know that those are not important.
OTOH, for example changes in the source files are unexpected.
I filed https://src.fedoraproject.org/rpms/stratisd/pull-request/6
for stratisd to stop rewriting the source tarballs (it was done
irreproducibly, but I think it's better to not do this at all).
> All that means you might hunting ghosts instead of real bugs.
The rebuild process is surprisingly reliable. Per the discussion
above, we
Re: So you can't just copy 'sources' from one package to another?
On Fri, Mar 08, 2024 at 04:19:11PM +, Richard W.M. Jones wrote: > For mingw-* packages we (sometimes) have a separate package from the > native package, eg. libgcrypt vs mingw-libgcrypt. Therefore two > different packages are sometimes built with the exact same sources. > > However I discovered copying 'sources' (ie the file) from libgcrypt > dist-git to mingw-libgcrypt dist-git alone isn't sufficient to get the > package to build. You still have to download the source tarballs in > libgcrypt, copy them to mingw-libgcrypt, and 'fedpkg new-sources > ' to upload them again. > > Isn't the lookaside cache shared across the whole of Fedora? > > (This doesn't matter, I was just wondering aloud.) Yeah, it's not really designed for easy sharing accross packages. It looks up things like: https://src.fedoraproject.org/repo/pkgs/rpms So, since the package name is in there if you just move it the archive isn't under that and it doesn't work. ;( It would likely need a redesign to support that use case sadly. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: So you can't just copy 'sources' from one package to another?
On Fri, Mar 8, 2024 at 5:19 PM Richard W.M. Jones wrote: > > For mingw-* packages we (sometimes) have a separate package from the > native package, eg. libgcrypt vs mingw-libgcrypt. Therefore two > different packages are sometimes built with the exact same sources. > > However I discovered copying 'sources' (ie the file) from libgcrypt > dist-git to mingw-libgcrypt dist-git alone isn't sufficient to get the > package to build. You still have to download the source tarballs in > libgcrypt, copy them to mingw-libgcrypt, and 'fedpkg new-sources > ' to upload them again. > > Isn't the lookaside cache shared across the whole of Fedora? Fedora's lookaside schema seems to be https://src.fedoraproject.org/repo/pkgs/rpms/$pkgname/$filename/$hashtype/$hash/$filename, so it far from being a content-addressed storage that'd reuse data across different $pkgnames. -- ___ 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 2268454] Upgrade perl-Carp-Assert-More to 2.4.0
https://bugzilla.redhat.com/show_bug.cgi?id=2268454 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Fixed In Version||perl-Carp-Assert-More-2.4.0 ||-1.fc41 Status|MODIFIED|CLOSED Last Closed||2024-03-08 16:20:19 --- Comment #2 from Fedora Update System --- FEDORA-2024-a756e8b0be (perl-Carp-Assert-More-2.4.0-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268454 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268454%23c2 -- ___ 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
So you can't just copy 'sources' from one package to another?
For mingw-* packages we (sometimes) have a separate package from the native package, eg. libgcrypt vs mingw-libgcrypt. Therefore two different packages are sometimes built with the exact same sources. However I discovered copying 'sources' (ie the file) from libgcrypt dist-git to mingw-libgcrypt dist-git alone isn't sufficient to get the package to build. You still have to download the source tarballs in libgcrypt, copy them to mingw-libgcrypt, and 'fedpkg new-sources ' to upload them again. Isn't the lookaside cache shared across the whole of Fedora? (This doesn't matter, I was just wondering aloud.) Rich. -- 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 2268454] Upgrade perl-Carp-Assert-More to 2.4.0
https://bugzilla.redhat.com/show_bug.cgi?id=2268454 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2024-a756e8b0be (perl-Carp-Assert-More-2.4.0-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-a756e8b0be -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268454 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268454%23c1 -- ___ 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 2268603] New: perl-Locale-Codes-3.78 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268603 Bug ID: 2268603 Summary: perl-Locale-Codes-3.78 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Locale-Codes Keywords: FutureFeature, Triaged Assignee: mspa...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mspa...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 3.78 Upstream release that is considered latest: 3.78 Current version/release in rawhide: 3.77-3.fc40 URL: http://search.cpan.org/dist/Locale-Codes/ 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/3033/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Locale-Codes -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268603 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268603%23c0 -- ___ 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
openclonk: undefined reference to `zmemcpy'
Hi, when compiling openclonk [1] on rawhide it fails with this error message [2]: /usr/bin/cmake -E cmake_link_script CMakeFiles/c4group.dir/link.txt --verbose=1 /usr/bin/g++ -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Wno-error=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wall -Wextra -Wredundant-decls -Wendif-labels -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Winit-self -Wsign-promo -Wno-reorder -Wno-unused-parameter -Wnon-virtual-dtor -Woverloaded-virtual -Wformat-security -Werror=delete-incomplete -DNDEBUG -flto=auto -fno-fat-lto-objects -Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -W l,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes CMakeFiles/c4group.dir/c4group_autogen/mocs_compilation.cpp.o CMakeFiles/c4group.dir/src/c4group/C4GroupMain.cpp.o -o c4group liblibmisc.a /usr/lib64/libz.so -lpthread -lrt make[2]: Leaving directory '/builddir/build/BUILD/openclonk-701bcf38c9f3c4877e1b4a8651b9ce922b15969e/build' /usr/bin/ld: /tmp/ccgvFyfu.ltrans1.ltrans.o: in function `c4_gzread': /builddir/build/BUILD/openclonk-701bcf38c9f3c4877e1b4a8651b9ce922b15969e/src/zlib/gzio.c:450:(.text+0x3fd0): undefined reference to `zmemcpy' collect2: error: ld returned 1 exit status How can this be fixed ?? [1] https://martinkg.fedorapeople.org/ErrorReports/openclonk/openclonk-8.1-24.20210103git701bcf3.fc39.src.rpm [2] https://kojipkgs.fedoraproject.org//work/tasks/5278/114665278/build.log Thanks Martin -- ___ 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
gloox soname bump
Hi Fedorians, I intend to update gloox to 1.0.28 which comes with a soname bump. 0ad and uwsgi depend on gloox [0]. I have successfully rebuild both in copr [1]. I will rebuild gloox in the following side tags: fedpkg build --target=f41-build-side-85385 fedpkg build --target=f40-build-side-85387 Help with the rebuilds would be greatly appreciated, as I do not have permission for those two packages. Best, David [0] fedrq wrsrc gloox -X -F source [1] https://copr.fedorainfracloud.org/coprs/davidsch/testing/builds/ -- ___ 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
Review requests: mingw-directxmath, python-jsonformatter
Hi I'd apprechiate a review of the following two packages: - mingw-directxmath: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2268585 (required for mingw-gstreamer1-plugins-bad-free 1.24.0) - python-jsonformatter: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2268579 (required for pgadmin4 8.4) Both are very simple packages. Happy to review in exchange. Thanks Sandro -- ___ 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: Guiding co-dependent RPM packages to swap nicely
On Fri, Mar 8, 2024 at 5:51 AM Miro Hrončok wrote: > > On 08. 03. 24 11:43, Florian Weimer wrote: > > * Miro Hrončok: > > > >> On my system, I have postgresql16 and postgresql16-plugin installed > >> and I want to "upgrade" to postgresql20*. > >> > >> Using my distribution package manager, I would want to run something like: > >>dnf swap postgresql16 postgresql20 > >> > >> However that will fail, as the package manager does not know I want to > >> also swap postgresql16-plugin with postgresql20-plugin. > >> > >> Is there something I can do as a package maintainer to "guide" the > >> co-dependent swap case? > > > > Have you tried using “dnf shell” and entering both swap commands there/ > > I am actually looking for a metadata solution that would guide the package > manager to do it for me, not for a way to swap them manually. > There isn't one right now. It's something that could be added, but we don't have any in DNF currently. It might also require plumbing in libsolv, I'm not sure. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ 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: Guiding co-dependent RPM packages to swap nicely
On 08. 03. 24 11:43, Florian Weimer wrote: * Miro Hrončok: On my system, I have postgresql16 and postgresql16-plugin installed and I want to "upgrade" to postgresql20*. Using my distribution package manager, I would want to run something like: dnf swap postgresql16 postgresql20 However that will fail, as the package manager does not know I want to also swap postgresql16-plugin with postgresql20-plugin. Is there something I can do as a package maintainer to "guide" the co-dependent swap case? Have you tried using “dnf shell” and entering both swap commands there/ I am actually looking for a metadata solution that would guide the package manager to do it for me, not for a way to swap them manually. -- 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: Guiding co-dependent RPM packages to swap nicely
* Miro Hrončok: > On my system, I have postgresql16 and postgresql16-plugin installed > and I want to "upgrade" to postgresql20*. > > Using my distribution package manager, I would want to run something like: > dnf swap postgresql16 postgresql20 > > However that will fail, as the package manager does not know I want to > also swap postgresql16-plugin with postgresql20-plugin. > > Is there something I can do as a package maintainer to "guide" the > co-dependent swap case? Have you tried using “dnf shell” and entering both swap commands there/ 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
[Bug 2268556] perl-Business-ISBN-Data-20240308.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268556 --- Comment #3 from Fedora Update System --- FEDORA-2024-0c2cd6ba0f (perl-Business-ISBN-Data-20240308.001-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-0c2cd6ba0f -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268556 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268556%23c3 -- ___ 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 2268556] perl-Business-ISBN-Data-20240308.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268556 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Fixed In Version||perl-Business-ISBN-Data-202 ||40308.001-1.fc41 Status|MODIFIED|CLOSED Last Closed||2024-03-08 10:20:27 --- Comment #2 from Fedora Update System --- FEDORA-2024-ba0eb7e6d9 (perl-Business-ISBN-Data-20240308.001-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268556 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268556%23c2 -- ___ 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 2268556] perl-Business-ISBN-Data-20240308.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268556 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2024-ba0eb7e6d9 (perl-Business-ISBN-Data-20240308.001-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-ba0eb7e6d9 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268556 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268556%23c1 -- ___ 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 2268556] New: perl-Business-ISBN-Data-20240308.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2268556 Bug ID: 2268556 Summary: perl-Business-ISBN-Data-20240308.001 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Business-ISBN-Data Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 20240308.001 Upstream release that is considered latest: 20240308.001 Current version/release in rawhide: 20240302.001-1.fc41 URL: https://metacpan.org/dist/Business-ISBN-Data/ 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/2674/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Business-ISBN-Data -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2268556 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202268556%23c0 -- ___ 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: reprodubible builds (re)introduction
V Thu, Mar 07, 2024 at 12:39:37PM +, Zbigniew Jędrzejewski-Szmek napsal(a):
> The effort to make package builds in Fedora reproducible has picked up steam
> again.
> We now have a new website:
> https://docs.fedoraproject.org/en-US/reproducible-builds
> and an issue tracker: https://pagure.io/fedora-reproducible-builds/project
> and a matrix room: https://matrix.to/#/#reproducible-builds:fedora.im
>
> We've done a mini rebuild using [1] for the package list [2] and results are
> at [3].
> (The result is a json dump of rpmdiff output by package. Generally, "" means
> the rebuild was identical except for variable metadata, and non-empty
> output else means that the rebuild was different.)
>
> [1] https://github.com/keszybz/fedora-repro-build
> [2] https://fedorapeople.org/~zbyszek/builds-2024-02-fc41-filtered.txt
> [3] https://fedorapeople.org/~zbyszek/builds-2024-02-fc41-filtered.results.txt
>
Is this mini rebuild a one-shot thing, or are are you going to rebuild the
packages repeatedly or use the results for something significant? I ask
because I spotted some discrepancies in those text files:
(1) Some packages are listed twice, with different NEVRAs. E.g.
perl-Alien-pkgconf or perl-RDF-RDFa-Generator.
(2) Both perl-Alien-pkgconf NEVRAs reports a differing
/usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-pkgconf/status.json
content. That content looks likes this:
{"libs":"-lpkgconf","version":"2.1.0","install_type":"system","cflags":"-I/usr/include/pkgconf","dll":"/lib64/libpkgconf.so.4.0.0"}
That means you had to perform rebuilds of the same NEVRA with different
libpkgconf-devel packages in the build roots. That looks like a bug in your
mini rebuild scheduler.
(3) Some packages listed in builds-2024-02-fc41-filtered.txt are missing from
builds-2024-02-fc41-filtered.results.txt. E.g.
perl-CPAN-Plugin-Sysdeps-0.73-1.fc41 is listed as COMPLETE, yet results are
missing.
(4) dnf5-5.1.13-1.fc41.src reports changes in Requires (e.g. "removed
REQUIRES createrepo_c"). That again looks like you built the same NEVRA in
different build roots (for some reason "%bcond_without tests" flipped).
All that means you might hunting ghosts instead of real bugs.
-- Petr
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
