[Fedora 38] Call for Test Days
Hi Fedora users, developers, and friends! It's time to start thinking about Test Days for Fedora 38. For anyone who isn't aware, a Test Day is an event usually focused around IRC for interaction and a Wiki page for instructions and results, with the aim being to get a bunch of interested users and developers together to test a specific feature or area of the distribution. You can run a Test Day on just about anything for which it would be useful to do some fairly focused testing in 'real time' with a group of testers; it doesn't have to be code, for instance, we often run Test Days for l10n/i18n topics. For more information on Test Days, see https://fedoraproject.org/wiki/QA/Test_Days . Anyone who wants to can host their own Test Day, or you can request that the QA group helps you out with organization or any combination of the two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's an example https://pagure.io/fedora-qa/issue/624 . For instructions on hosting a Test Day, see https://fedoraproject.org/wiki/QA/SOP_Test_Day_management . You can see the schedule at https://pagure.io/fedora-qa/issues?tags=test+days . There are many slots open right now. Consider the development schedule, though, in deciding when you want to run your Test Day - for some topics you may want to avoid the time before the Beta release or the time after the feature freeze or the Final Freeze. We normally aim to schedule Test Days on Thursdays; however, if you want to run a series of related Test Days, it's often a good idea to do something like Tuesday / Wednesday / Thursday of the same week (this is how we usually run the X Test Week, for instance). If all the Thursday slots fill up but more people want to run Test Days, we will open up Tuesday slots as overflows. And finally, if you really want to run a Test Day in a specific time frame due to the development schedule, but the Thursday slot for that week is full, we can add a slot on another day. We're flexible! Just put in your ticket the date or time frame you'd like, and we'll figure it out from there. If you don't want to run your own Test Day, but you are willing to help with another, feel free to join one or more of already accepted Test Days: GNOME Test Day* i18n Test Day* Kernel Test Week(s)* Upgrade Test Day* IoT Test Week* Cloud Test Day* Fedora CoreOS Test Week* And don't be afraid, there are a lot of more slots available for your own Test Day! [*] These are the test days we run generally to make sure everything is working fine, the dates get announced as we move into the release cycle. If you have any questions about the Test Day process, please don't hesitate to contact me or any member of the Fedora QA team on test at lists.fedoraproject.org or in #fedora-qa on IRC. Thanks! -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 9:37 PM Kevin Kofler via devel wrote: > > Neal Gompa wrote: > > Can we please have gcc-rs also built (even though it's experimental)? > > Will gcc-rs be able to generate usable shared libraries for Rust crates? > If someone were to spend the time to build the functionality into its code generator, sure. I don't think that's high on anyone's list right now, though. -- 真実はいつも一つ！/ 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: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
Neal Gompa wrote: > Can we please have gcc-rs also built (even though it's experimental)? Will gcc-rs be able to generate usable shared libraries for Rust crates? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-65548d9891 w3m-0.5.3-58.git20220429.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing rsnapshot-1.4.5-1.el7 Details about builds: rsnapshot-1.4.5-1.el7 (FEDORA-EPEL-2022-2405b0bf30) Local and remote filesystem snapshot utility Update Information: # rsnapshot 1.4.5 - Fix false directory conflict regression introduced with rsnapshot 1.4.4 - Update HOWTO to talk about 'retain' instead of 'interval' - Remove legacy Docbook files - Correct punctuation - Use `@prefix@` instead of hardcoded value in `rsnapshot.conf.default.in` comment line ChangeLog: * Fri Dec 30 2022 Robert Scheck - 1.4.5-1 - Upgrade to 1.4.5 (#2156839) References: [ 1 ] Bug #2156839 - rsnapshot-1.4.5 is available https://bugzilla.redhat.com/show_bug.cgi?id=2156839 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following builds have been pushed to Fedora EPEL 8 updates-testing NetworkManager-l2tp-1.20.8-1.el8 mlpack-4.0.1-1.el8 nextcloud-client-3.2.4-4.el8 rsnapshot-1.4.5-1.el8 Details about builds: NetworkManager-l2tp-1.20.8-1.el8 (FEDORA-EPEL-2022-339f2029cd) NetworkManager VPN plugin for L2TP and L2TP/IPsec Update Information: Updated to 1.20.8 release ChangeLog: * Fri Dec 30 2022 Douglas Kosovic - 1.20.8-1 - Updated to 1.20.8 release - Added conditional recommends for NetworManager-l2tp-gnome and plasma-nm-l2tp - Added runstatedir=/run mlpack-4.0.1-1.el8 (FEDORA-EPEL-2022-187189673b) Fast, header-only C++ machine learning library Update Information: Update to latest stable version. ChangeLog: * Thu Dec 29 2022 Ryan Curtin - 4.0.1-1 - Update to latest stable version. nextcloud-client-3.2.4-4.el8 (FEDORA-EPEL-2022-ad65068442) The Nextcloud Client Update Information: - rebuild for qt ChangeLog: * Fri Dec 30 2022 Mukundan Ragavan - 3.2.4-4 - rebuild for qt References: [ 1 ] Bug #2142655 - Rebuild nextcloud-client package for RH8.7 and new Qt version https://bugzilla.redhat.com/show_bug.cgi?id=2142655 rsnapshot-1.4.5-1.el8 (FEDORA-EPEL-2022-0fbed28656) Local and remote filesystem snapshot utility Update Information: # rsnapshot 1.4.5 - Fix false directory conflict regression introduced with rsnapshot 1.4.4 - Update HOWTO to talk about 'retain' instead of 'interval' - Remove legacy Docbook files - Correct punctuation - Use `@prefix@` instead of hardcoded value in `rsnapshot.conf.default.in` comment line ChangeLog: * Fri Dec 30 2022 Robert Scheck - 1.4.5-1 - Upgrade to 1.4.5 (#2156839) References: [ 1 ] Bug #2156839 - rsnapshot-1.4.5 is available https://bugzilla.redhat.com/show_bug.cgi?id=2156839 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2155345] perl-CPAN-Perl-Releases-5.20221220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2155345 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0221220-1.fc38 |0221220-1.fc38 |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0221220-1.fc37 |0221220-1.fc37 ||perl-CPAN-Perl-Releases-5.2 ||0221220-1.fc36 --- Comment #6 from Fedora Update System --- FEDORA-2022-bfd926fc14 has been pushed to the Fedora 36 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=2155345 ___ 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 2155351] perl-Module-CoreList-5.20221220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2155351 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Module-CoreList-5.2022 |perl-Module-CoreList-5.2022 |1220-1.fc38 |1220-1.fc38 |perl-Module-CoreList-5.2022 |perl-Module-CoreList-5.2022 |1220-1.fc37 |1220-1.fc37 ||perl-Module-CoreList-5.2022 ||1220-1.fc36 --- Comment #6 from Fedora Update System --- FEDORA-2022-3c99427018 has been pushed to the Fedora 36 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=2155351 ___ 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 2155351] perl-Module-CoreList-5.20221220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2155351 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|ON_QA |CLOSED Fixed In Version|perl-Module-CoreList-5.2022 |perl-Module-CoreList-5.2022 |1220-1.fc38 |1220-1.fc38 ||perl-Module-CoreList-5.2022 ||1220-1.fc37 Last Closed||2022-12-31 01:10:12 --- Comment #5 from Fedora Update System --- FEDORA-2022-d837237b50 has been pushed to the Fedora 37 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=2155351 ___ 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 2155345] perl-CPAN-Perl-Releases-5.20221220 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2155345 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2 |0221220-1.fc38 |0221220-1.fc38 ||perl-CPAN-Perl-Releases-5.2 ||0221220-1.fc37 Last Closed||2022-12-31 01:10:10 --- Comment #5 from Fedora Update System --- FEDORA-2022-441c08c2e6 has been pushed to the Fedora 37 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=2155345 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 7:57 PM Demi Marie Obenour wrote: > > On 12/30/22 14:12, Neal Gompa wrote: > > On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton wrote: > >> > >> https://fedoraproject.org/wiki/Changes/GNUToolchainF38 > >> > >> 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 38 GNU Toolchain to gcc 13.0, binutils 2.39, and glibc > >> 2.37. > >> > >> The existing gdb 12.1 will be used as-is. > >> > >> The set of core GNU Toolchain packages for Fedora 38 are as follows: > >> > >> * GNU C Compiler 13.0 > >> ** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp), > >> Fortran (gfortran), D (phobos), Objective C/C++. > >> * GNU Binary Utilities 2.39 > >> * GNU C Library 2.37 > >> * GNU Debugger 12.1 (immediately available in Fedora 37) > >> > >> The gcc 13.0 change will be tracked in this top-level GNU Toolchain > >> system-wide update. > >> > >> The binutils 2.39 change will be tracked in this top-level GNU > >> Toolchain system-wide update. > >> > >> The glibc 2.37 change will be tracked in this top-level GNU Toolchain > >> system-wide update. > >> > >> == 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 13.0, after > >> the Fedora 38 release. It will contain many new features, documented > >> here: https://gcc.gnu.org/gcc-13/changes.html. The latest release > >> candidate for gcc 13 will be included in Fedora 38 and will be updated > >> when released. > >> > >> The GNU Binutils version 2.39 was released before Fedora 38; and we > >> have already been using this version of binutils in Fedora Rawhide > >> successfully to build the distribution for the last 4 months. Given > >> the present schedule for Fedora 38 we will continue to use Binutils > >> 2.39. > >> > >> The GNU C Library version 2.37 is expected to be release before Fedora > >> 38; we have started closely tracking the glibc 2.37 development code > >> in Fedora Rawhide and are addressing any issues as they arise. Given > >> the present schedule Fedora 38 will branch after the release of glibc > >> 2.37. However, the mass rebuild schedule means Fedora 38 will mass > >> rebuild (if required) before the final release of glibc 2.37, but > >> after the ABI is frozen. > >> > >> The GNU Debugger version 12.1 was released before Fedora 38; and we > >> plan to continue to use this version of the debugger. > >> > >> == 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 38 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/XX #XX] > >> ** Filed after approval. > >> > >> * 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. > >> > >> Some source changes may be required for the gcc 13 update. Please > >> refer to the latest changes here: > >> https://gcc.gnu.org/gcc-13/changes.html > >> > >> Any source level changes required for glibc 2.37 will be noted here: > >> https://sourceware.org/glibc/wiki/Release/2.37#Packaging_Changes > >> > >> == How To Test == > >> The GNU Compiler Collection has its own testsuite which is run during > >> the package build and examined by the gcc developers before being > >> uploaded. > >> > >> The GNU C Library has its own testsuite 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 >
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 4:50 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Dec 30, 2022 at 08:46:46PM -, Leigh Scott wrote: > > -1 for this change. > > I will ignore it if it's accepted. > > That's OK, the idea is to make this opt-in. > Without any specific concerns, that's all I can say. > This Change seems to be about flipping the defaults to make people opt-out. If it's opt-in, this Change is null, since that's the status quo. -- 真実はいつも一つ！/ 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: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
On 12/30/22 14:12, Neal Gompa wrote: > On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton wrote: >> >> https://fedoraproject.org/wiki/Changes/GNUToolchainF38 >> >> 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 38 GNU Toolchain to gcc 13.0, binutils 2.39, and glibc >> 2.37. >> >> The existing gdb 12.1 will be used as-is. >> >> The set of core GNU Toolchain packages for Fedora 38 are as follows: >> >> * GNU C Compiler 13.0 >> ** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp), >> Fortran (gfortran), D (phobos), Objective C/C++. >> * GNU Binary Utilities 2.39 >> * GNU C Library 2.37 >> * GNU Debugger 12.1 (immediately available in Fedora 37) >> >> The gcc 13.0 change will be tracked in this top-level GNU Toolchain >> system-wide update. >> >> The binutils 2.39 change will be tracked in this top-level GNU >> Toolchain system-wide update. >> >> The glibc 2.37 change will be tracked in this top-level GNU Toolchain >> system-wide update. >> >> == 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 13.0, after >> the Fedora 38 release. It will contain many new features, documented >> here: https://gcc.gnu.org/gcc-13/changes.html. The latest release >> candidate for gcc 13 will be included in Fedora 38 and will be updated >> when released. >> >> The GNU Binutils version 2.39 was released before Fedora 38; and we >> have already been using this version of binutils in Fedora Rawhide >> successfully to build the distribution for the last 4 months. Given >> the present schedule for Fedora 38 we will continue to use Binutils >> 2.39. >> >> The GNU C Library version 2.37 is expected to be release before Fedora >> 38; we have started closely tracking the glibc 2.37 development code >> in Fedora Rawhide and are addressing any issues as they arise. Given >> the present schedule Fedora 38 will branch after the release of glibc >> 2.37. However, the mass rebuild schedule means Fedora 38 will mass >> rebuild (if required) before the final release of glibc 2.37, but >> after the ABI is frozen. >> >> The GNU Debugger version 12.1 was released before Fedora 38; and we >> plan to continue to use this version of the debugger. >> >> == 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 38 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/XX #XX] >> ** Filed after approval. >> >> * 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. >> >> Some source changes may be required for the gcc 13 update. Please >> refer to the latest changes here: >> https://gcc.gnu.org/gcc-13/changes.html >> >> Any source level changes required for glibc 2.37 will be noted here: >> https://sourceware.org/glibc/wiki/Release/2.37#Packaging_Changes >> >> == How To Test == >> The GNU Compiler Collection has its own testsuite which is run during >> the package build and examined by the gcc developers before being >> uploaded. >> >> The GNU C Library has its own testsuite 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 testsuite which is run during the package >> build and examined by binutils developers before being uploaded. The >> regression
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 9:50 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Dec 30, 2022 at 08:46:46PM -, Leigh Scott wrote: > > -1 for this change. > > I will ignore it if it's accepted. > > That's OK, the idea is to make this opt-in. So if the change is opt-in how is this an actual change to the process we already have? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
> Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as > the default approach. > Packaging Guidelines and other documentation are adjusted to describe > this approach first. > Various tools that provide spec file templates are adjusted. -1 to this proposal. As I had already written when this was first introduced, autogenerating the changelog from git history is a bad idea, especially in Fedora dist-git where published git history cannot ever be rewritten, so it is impossible to fix typos in the changelog, hide fixup commits if they did not use the proper fixup markup (or even avoid them altogether by amending the previously pushed commit), etc., which all requires to at least be able to edit commit messages, which unfortunately in git means you need to be able to amend the commit altogether and force-push. As long as such force-pushes are by design not allowed in Fedora dist-git, its (effectively immutable) metadata is not a suitable place to maintain the changelog in. In addition, it assumes that the commits in git use the correct format for %autochangelog. In my current commits, I paste the full changelog entry with date and all into the commit details field and add a one-line summary as the commit summary. (Git-Cola automatically turns this into a commit message in the conventional git format summary + blank line (i.e., 2 newlines) + details.) Obviously, I do not want the date line to be pasted back into the changelog below an automatically generated one. (My older commits from pre- git times even had only the full changelog entry pasted with no summary line.) In addition, sometimes, I add details to the git commit message that are too long for the RPM changelog and hence are deliberately only in the git commit message. (More precisely, I append to the pasted changelog entry a blank line and one or more freeform paragraphs with the extra details.) I do not want those to ever be automatically added to the RPM changelog either. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2157115] perl-Excel-Writer-XLSX-1.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157115 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Excel-Writer-XLSX-1.10-1.fc36.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=95687223 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157115 ___ 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 2157115] perl-Excel-Writer-XLSX-1.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157115 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1935028 --> https://bugzilla.redhat.com/attachment.cgi?id=1935028=edit Update to 1.10 (#2157115) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157115 ___ 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 2157115] New: perl-Excel-Writer-XLSX-1.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157115 Bug ID: 2157115 Summary: perl-Excel-Writer-XLSX-1.10 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Excel-Writer-XLSX Keywords: FutureFeature, Triaged Assignee: tjczep...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jakub.jedel...@gmail.com, perl-devel@lists.fedoraproject.org, tjczep...@gmail.com Target Milestone: --- Classification: Fedora Releases retrieved: 1.10 Upstream release that is considered latest: 1.10 Current version/release in rawhide: 1.09-3.fc37 URL: http://search.cpan.org/dist/Excel-Writer-XLSX/ 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/2860/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Excel-Writer-XLSX -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157115 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote: > > On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default > > Have we made sure that when Red Hat forks Fedora packages for RHEL > > that they don't truncate or eliminate the Git history anymore? Because I > > would > > personally be very displeased if my historical attribution went away > > because of broken processes like the one used to fork all the Fedora > > Linux 34 packages for CentOS Stream 9. > > I can't speak for the RH folks who do the forking… It'd be great if > somebody who knows how that's done could answer. > > Fedora is already using rpmautospec widely enough that (if it was to > be problem at all), it must already be a problem. > > At the level of specific solutions, obviously the obvious answer is to > keep the git history. It's in general a great of source of information > and discarding that is just an error. But if somebody were really to do that, > it's fairly trivial to undo the conversion and get a static changelog > again by inserting the output of 'rpmautospec changelog' in the %changelog > section. > As they are the most prominent downstream we have, I would like this resolved before changing Fedora's defaults. At the time we branched from Fedora Linux 34, there were very few packages using rpmautospec and I don't think any that were kept used rpmautospec. Now it is very obvious it would be a problem, so I would like that fixed first. CentOS and RHEL infrastructure needs to account for it properly and not gut the Git history. -- 真実はいつも一つ！/ 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 08:46:46PM -, Leigh Scott wrote: > -1 for this change. > I will ignore it if it's accepted. That's OK, the idea is to make this opt-in. Without any specific concerns, that's all I can say. 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
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote: > On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default > Have we made sure that when Red Hat forks Fedora packages for RHEL > that they don't truncate or eliminate the Git history anymore? Because I would > personally be very displeased if my historical attribution went away > because of broken processes like the one used to fork all the Fedora > Linux 34 packages for CentOS Stream 9. I can't speak for the RH folks who do the forking… It'd be great if somebody who knows how that's done could answer. Fedora is already using rpmautospec widely enough that (if it was to be problem at all), it must already be a problem. At the level of specific solutions, obviously the obvious answer is to keep the git history. It's in general a great of source of information and discarding that is just an error. But if somebody were really to do that, it's fairly trivial to undo the conversion and get a static changelog again by inserting the output of 'rpmautospec changelog' in the %changelog section. 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
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
-1 for this change. I will ignore it if it's accepted. ___ 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 2132181] perl-Net-DNS-1.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2132181 --- Comment #5 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Net-DNS-1.36-1.fc36.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=95685652 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2132181 ___ 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 2132181] perl-Net-DNS-1.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2132181 --- Comment #4 from Upstream Release Monitoring --- Created attachment 1934989 --> https://bugzilla.redhat.com/attachment.cgi?id=1934989=edit Update to 1.36 (#2132181) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2132181 ___ 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 2132181] perl-Net-DNS-1.36 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2132181 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Net-DNS-1.35 is|perl-Net-DNS-1.36 is |available |available --- Comment #3 from Upstream Release Monitoring --- Releases retrieved: 1.36 Upstream release that is considered latest: 1.36 Current version/release in rawhide: 1.34-3.fc38 URL: http://search.cpan.org/dist/Net-DNS/ 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/3147/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Net-DNS -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2132181 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/GNUToolchainF38 > > 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 38 GNU Toolchain to gcc 13.0, binutils 2.39, and glibc 2.37. > > The existing gdb 12.1 will be used as-is. > > The set of core GNU Toolchain packages for Fedora 38 are as follows: > > * GNU C Compiler 13.0 > ** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp), > Fortran (gfortran), D (phobos), Objective C/C++. > * GNU Binary Utilities 2.39 > * GNU C Library 2.37 > * GNU Debugger 12.1 (immediately available in Fedora 37) > > The gcc 13.0 change will be tracked in this top-level GNU Toolchain > system-wide update. > > The binutils 2.39 change will be tracked in this top-level GNU > Toolchain system-wide update. > > The glibc 2.37 change will be tracked in this top-level GNU Toolchain > system-wide update. > > == 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 13.0, after > the Fedora 38 release. It will contain many new features, documented > here: https://gcc.gnu.org/gcc-13/changes.html. The latest release > candidate for gcc 13 will be included in Fedora 38 and will be updated > when released. > > The GNU Binutils version 2.39 was released before Fedora 38; and we > have already been using this version of binutils in Fedora Rawhide > successfully to build the distribution for the last 4 months. Given > the present schedule for Fedora 38 we will continue to use Binutils > 2.39. > > The GNU C Library version 2.37 is expected to be release before Fedora > 38; we have started closely tracking the glibc 2.37 development code > in Fedora Rawhide and are addressing any issues as they arise. Given > the present schedule Fedora 38 will branch after the release of glibc > 2.37. However, the mass rebuild schedule means Fedora 38 will mass > rebuild (if required) before the final release of glibc 2.37, but > after the ABI is frozen. > > The GNU Debugger version 12.1 was released before Fedora 38; and we > plan to continue to use this version of the debugger. > > == 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 38 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/XX #XX] > ** Filed after approval. > > * 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. > > Some source changes may be required for the gcc 13 update. Please > refer to the latest changes here: > https://gcc.gnu.org/gcc-13/changes.html > > Any source level changes required for glibc 2.37 will be noted here: > https://sourceware.org/glibc/wiki/Release/2.37#Packaging_Changes > > == How To Test == > The GNU Compiler Collection has its own testsuite which is run during > the package build and examined by the gcc developers before being > uploaded. > > The GNU C Library has its own testsuite 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 testsuite which is run during the package > build and examined by binutils developers before being uploaded. The > regression testsuite is run to verify the correct operation of the > static linker and attendant utilities. > > The GNU Debugger has its own testsuite which is run during the
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
>
> 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 ==
> Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
> the default approach.
> Packaging Guidelines and other documentation are adjusted to describe
> this approach first.
> Various tools that provide spec file templates are adjusted.
>
> == Owner ==
> * Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
> Jędrzejewski-Szmek]]
> * Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
>
>
> == Detailed Description ==
>
> {{admon/note|Brief reminder about rpmautospec|
> The spec file contains:
>
> Version: 1.2.3
> Release: %autorelease
> ...
> %changelog
> %autochangelog
>
> Rpmautospec uses git history. Whenever the package is built
> (`.src.rpm` is generated), rpmautospec tooling will replace the
> `%autorelease` macro with the number of commits since the last commit
> that changed the `Version` field, and the `%autochangelog` macro with
> a text generated from `git log`.
> For details see the
> [https://docs.pagure.org/fedora-infra.rpmautospec/principle.html
> docs].
> }}
>
> Rpmautospec has been deployed in Fedora since F35
> ([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%).
> But it is still a "second-class citizen": most documentation doesn't
> mention it, and many packagers know that it exists but don't use it in
> their packages. We think that it's reasonable to switch to
> `%autorelease`+`%autochangelog` for almost all packages and that
> Packaging Guidelines and various packaging howtos should recommend
> that approach to packagers. The "traditional" approach of
> manually-managed `Release` and `%changelog` will remain valid and will
> be documented as a fallback.
>
> This change is targeted at Fedora 38, but it will actually apply to
> all releases. The goal is to update the Packaging Guidelines and other
> prominent documentation and tools now, and other docs and tools
> possibly at a later time. Changing packages is out of scope.
>
> It is worth mentioning that `rust2rpm` uses
> `%autorelease`+`%autochangelog` since a few releases, so most rust
> packages have switched. (Generally, rust spec files are recreated
> using the generator for each new version, so the switch would happen
> whenever a new version is packaged unless the packager opts out.)
>
> == Feedback ==
>
> * Thread on fedora-devel in August 2022:
> [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/T6J2WGIMRCTW77QTH4D7HPNS6KUGDQOQ/
> rpmautospec by default]
> ** open issues: a bunch have been fixed.
> ** maintenance: Nils will add some co-maintainers.
> ** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see
> Scope section.
>
> == Benefit to Fedora ==
> Various packaging workflows become smoother for packagers and contributors:
>
> * packagers don't need to touch the `Release` field on updates
> * packagers describe changes just once in the git commit message, the
> `%changelog` entry is autogenerated
> * patches to the spec file can be cherry-picked between branches
> without trivial conflicts
> * pull requests on src.fedoraproject.org can be merged without trivial
> conflicts
> * in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
> `%changelog` section doesn't need to be copied over
>
> == Scope ==
> * Proposal owners:
> ** provide pull requests to Packaging Guidelines and other docs to
> make `%autorelease`+`%autochangelog` the default
> ** implement fixes for issues reported by packagers
> ** make semi-regular releases of rpmautospec
> ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/K5EA5OGRX2BCZ353C7S4MQVZTSH2BH63/
> 0.3.1 was released on November 17th, and should be deployed to
> production in about two weeks])
>
> * Other developers:
> ** provide pull requests to other docs as appropriate
> ** accept the changes to documentation
> ** update other spec file generators (pip2rpm, others?)
>
> * Somebody (TBD):
> ** `fedora-review` — https://pagure.io/rpkg/issue/641
> ** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the
> command will fail. A replacement workflow that instead restores
> `%autorelease`+`%autochangelog` in the file committed to dist-git
> needs to be implemented.
>
> * Related work
> ** https://pagure.io/rpkg/c/3087dd7
> ** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
>
>
> * Release engineering: [https://pagure.io/releng/issues #Releng issue number]
>
> * Policies and guidelines: a list of places to be updated
> ** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
> **
F38 proposal: FPC repackaging (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/F38-FPC-repackaging 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 == Split the `fpc` package (the Free Pascal Compiler) into several sub-packages (built from the same spec file). == Owner == * Name: [[User:suve|Artur Frenszek-Iwicki]] * Email: == Detailed Description == The `fpc` package will be split into three packages: * `fpc` - the compiler itself, plus utility programs * `fpc-ide` - the terminal-based TUI IDE (`/usr/bin/fp`) * `fpc-units-ARCHNAME-linux` - pre-compiled units (think "FPC's stdlib") for developing programs for Linux The "units" subpackage will be a shared dependency for both `fpc` and `fpc-ide`. == Benefit to Fedora == The TUI IDE will be moved to a separate package, slightly reducing the download size for packages requiring FPC to build. Putting Linux units in an `fpc-units-ARCHNAME-linux` package will create a precedent which can be used in the future for introducing cross-compilation packages, like `fpc-units-x86_64-win64` for MS Windows. == Scope == * Proposal owners: ** Edit `fpc.spec` as required and rebuild the package, preferably before the Mass Rebuild. * Other developers: No action required. * Release engineering: No action required. * 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 == After upgrading to Fedora 38, users interested in the TUI IDE will need to manually install the `fpc-ide` package. For those not interested in the TUI IDE, there will be no impact. == How To Test == A copr repository has been created where users can test out the modified package: [https://copr.fedorainfracloud.org/coprs/suve/fpc-split/ copr/suve/fpc-split]. This copr repository also modifies the spec to build units for MS Windows (`x86_64` only), allowing for cross-compilation. == User Experience == For users not interested in the TUI IDE, this Change will slightly reduce the install size (about 1.5 MiB for the IDE plus another 3.5 MiB for its dependencies). Since the TUI IDE does not launch the compiler as a sub-process, but rather contains an embedded copy of the compiler, users who use only the IDE and not the standalone compiler will benefit in a similar way - they will be able to install just the IDE, without the main compiler package. == Dependencies == None. == Contingency Plan == Worst case scenario - give up, revert to an old version of `fpc.spec` and rebuild the package. == Documentation == N/A (not a System Wide Change) == Release Notes == The `fpc` package no longer includes the terminal-based TUI IDE. Users interested in the IDE should install the `fpc-ide` package. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/GNUToolchainF38 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 38 GNU Toolchain to gcc 13.0, binutils 2.39, and glibc 2.37. The existing gdb 12.1 will be used as-is. The set of core GNU Toolchain packages for Fedora 38 are as follows: * GNU C Compiler 13.0 ** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp), Fortran (gfortran), D (phobos), Objective C/C++. * GNU Binary Utilities 2.39 * GNU C Library 2.37 * GNU Debugger 12.1 (immediately available in Fedora 37) The gcc 13.0 change will be tracked in this top-level GNU Toolchain system-wide update. The binutils 2.39 change will be tracked in this top-level GNU Toolchain system-wide update. The glibc 2.37 change will be tracked in this top-level GNU Toolchain system-wide update. == 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 13.0, after the Fedora 38 release. It will contain many new features, documented here: https://gcc.gnu.org/gcc-13/changes.html. The latest release candidate for gcc 13 will be included in Fedora 38 and will be updated when released. The GNU Binutils version 2.39 was released before Fedora 38; and we have already been using this version of binutils in Fedora Rawhide successfully to build the distribution for the last 4 months. Given the present schedule for Fedora 38 we will continue to use Binutils 2.39. The GNU C Library version 2.37 is expected to be release before Fedora 38; we have started closely tracking the glibc 2.37 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 38 will branch after the release of glibc 2.37. However, the mass rebuild schedule means Fedora 38 will mass rebuild (if required) before the final release of glibc 2.37, but after the ABI is frozen. The GNU Debugger version 12.1 was released before Fedora 38; and we plan to continue to use this version of the debugger. == 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 38 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/XX #XX] ** Filed after approval. * 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. Some source changes may be required for the gcc 13 update. Please refer to the latest changes here: https://gcc.gnu.org/gcc-13/changes.html Any source level changes required for glibc 2.37 will be noted here: https://sourceware.org/glibc/wiki/Release/2.37#Packaging_Changes == How To Test == The GNU Compiler Collection has its own testsuite which is run during the package build and examined by the gcc developers before being uploaded. The GNU C Library has its own testsuite 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 testsuite which is run during the package build and examined by binutils developers before being uploaded. The regression testsuite is run to verify the correct operation of the static linker and attendant utilities. The GNU Debugger has its own testsuite which is run during the package build and examined by gdb developers before being uploaded. The regression testsuite is run to verify the correct operation of the debugger. == User Experience == Fedora developers as well as developers using the distribution will be able to use and
F38 proposal: Noto Fonts For More Languages (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/NotoFontsForMoreLang
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 ==
Changes the default font for more languages to Noto Fonts.
== Owner ==
* Name: [[User:Tagoh| Akira TAGOH]]
* Email:
== Detailed Description ==
We have changed our default fonts to Noto in
[[Changes/DefaultToNotoFonts|f36]] though, some languages was still
missing even though Noto Fonts provides fonts for their languages.
This Change continues to accomplish consistent text rendering across
our supported languages as far as possible.
The following languages are targeted in this Change:
* Khmer
* Thai
== Feedback ==
== Benefit to Fedora ==
We would get better text rendering on applications and desktops for
the above languages as well as languages we have already migrated.
Also this change should save about 344kB on the fresh install.
$ rpm -qlv khmer-os-system-fonts thai-scalable-waree-fonts | awk
'BEGIN{a=0}{a+=$5}END{print a}'
504660
$ rpm -qlv google-noto-sans-khmer-vf-fonts
google-noto-sans-thai-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print a}'
160573
== Scope ==
* Proposal owners:
** Update google-noto-fonts and fonts packages currently used as
default, to change the priority of fontconfig config.
** Update langpacks to update dependencies
** Update comps to update default fonts sets
** Update lorax templates
* Other developers: Nothing
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Nothing
== Upgrade/compatibility impact ==
The migration will be done by updating langpacks. after upgrading and
rebooting, the default font will be Noto instead of `Khmer OS
System`/`Waree`.
Since this change aims to switch non-variable fonts to variable fonts,
it may not works with legacy applications as expected such as missing
some variants. in that case, you can install non-variable fonts
packages. the package name will be similar and simply drop -vf from
the variable fonts packages.
== How To Test ==
* This change can be simply tested by fc-match command like `fc-match
sans:lang=`, `fc-match serif:lang=` and
`fc-match monospace:lang=`. `:lang=km` for Khmer and
`:lang=th` for Thai.
* Test the text rendering in your favorite application, which use the
system default font.
== User Experience ==
Khmer/Thai Users will see the default font is changed to Noto by this change.
== Dependencies ==
Only khmer-os-system-fonts, thai-scalable-waree-fonts, langpacks, and
fontconfig are required to update. Other packages which explicitly has
a dependency to above fonts packages are basically optional to update.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the
relevant packages updated.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
None
== Release Notes ==
The default fonts for Khmer and Thai will be Google Noto Fonts to keep
consistency on the text rendering and to provide better quality among
languages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
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 ==
Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
the default approach.
Packaging Guidelines and other documentation are adjusted to describe
this approach first.
Various tools that provide spec file templates are adjusted.
== Owner ==
* Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
* Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec|
The spec file contains:
Version: 1.2.3
Release: %autorelease
...
%changelog
%autochangelog
Rpmautospec uses git history. Whenever the package is built
(`.src.rpm` is generated), rpmautospec tooling will replace the
`%autorelease` macro with the number of commits since the last commit
that changed the `Version` field, and the `%autochangelog` macro with
a text generated from `git log`.
For details see the
[https://docs.pagure.org/fedora-infra.rpmautospec/principle.html
docs].
}}
Rpmautospec has been deployed in Fedora since F35
([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%).
But it is still a "second-class citizen": most documentation doesn't
mention it, and many packagers know that it exists but don't use it in
their packages. We think that it's reasonable to switch to
`%autorelease`+`%autochangelog` for almost all packages and that
Packaging Guidelines and various packaging howtos should recommend
that approach to packagers. The "traditional" approach of
manually-managed `Release` and `%changelog` will remain valid and will
be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to
all releases. The goal is to update the Packaging Guidelines and other
prominent documentation and tools now, and other docs and tools
possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses
`%autorelease`+`%autochangelog` since a few releases, so most rust
packages have switched. (Generally, rust spec files are recreated
using the generator for each new version, so the switch would happen
whenever a new version is packaged unless the packager opts out.)
== Feedback ==
* Thread on fedora-devel in August 2022:
[https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/T6J2WGIMRCTW77QTH4D7HPNS6KUGDQOQ/
rpmautospec by default]
** open issues: a bunch have been fixed.
** maintenance: Nils will add some co-maintainers.
** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see
Scope section.
== Benefit to Fedora ==
Various packaging workflows become smoother for packagers and contributors:
* packagers don't need to touch the `Release` field on updates
* packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
* patches to the spec file can be cherry-picked between branches
without trivial conflicts
* pull requests on src.fedoraproject.org can be merged without trivial conflicts
* in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over
== Scope ==
* Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to
make `%autorelease`+`%autochangelog` the default
** implement fixes for issues reported by packagers
** make semi-regular releases of rpmautospec
([https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/K5EA5OGRX2BCZ353C7S4MQVZTSH2BH63/
0.3.1 was released on November 17th, and should be deployed to
production in about two weeks])
* Other developers:
** provide pull requests to other docs as appropriate
** accept the changes to documentation
** update other spec file generators (pip2rpm, others?)
* Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641
** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the
command will fail. A replacement workflow that instead restores
`%autorelease`+`%autochangelog` in the file committed to dist-git
needs to be implemented.
* Related work
** https://pagure.io/rpkg/c/3087dd7
** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: a list of places to be updated
** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning
**
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Rpmautospec is already used by a decent
F38 proposal: FPC repackaging (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/F38-FPC-repackaging 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 == Split the `fpc` package (the Free Pascal Compiler) into several sub-packages (built from the same spec file). == Owner == * Name: [[User:suve|Artur Frenszek-Iwicki]] * Email: == Detailed Description == The `fpc` package will be split into three packages: * `fpc` - the compiler itself, plus utility programs * `fpc-ide` - the terminal-based TUI IDE (`/usr/bin/fp`) * `fpc-units-ARCHNAME-linux` - pre-compiled units (think "FPC's stdlib") for developing programs for Linux The "units" subpackage will be a shared dependency for both `fpc` and `fpc-ide`. == Benefit to Fedora == The TUI IDE will be moved to a separate package, slightly reducing the download size for packages requiring FPC to build. Putting Linux units in an `fpc-units-ARCHNAME-linux` package will create a precedent which can be used in the future for introducing cross-compilation packages, like `fpc-units-x86_64-win64` for MS Windows. == Scope == * Proposal owners: ** Edit `fpc.spec` as required and rebuild the package, preferably before the Mass Rebuild. * Other developers: No action required. * Release engineering: No action required. * 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 == After upgrading to Fedora 38, users interested in the TUI IDE will need to manually install the `fpc-ide` package. For those not interested in the TUI IDE, there will be no impact. == How To Test == A copr repository has been created where users can test out the modified package: [https://copr.fedorainfracloud.org/coprs/suve/fpc-split/ copr/suve/fpc-split]. This copr repository also modifies the spec to build units for MS Windows (`x86_64` only), allowing for cross-compilation. == User Experience == For users not interested in the TUI IDE, this Change will slightly reduce the install size (about 1.5 MiB for the IDE plus another 3.5 MiB for its dependencies). Since the TUI IDE does not launch the compiler as a sub-process, but rather contains an embedded copy of the compiler, users who use only the IDE and not the standalone compiler will benefit in a similar way - they will be able to install just the IDE, without the main compiler package. == Dependencies == None. == Contingency Plan == Worst case scenario - give up, revert to an old version of `fpc.spec` and rebuild the package. == Documentation == N/A (not a System Wide Change) == Release Notes == The `fpc` package no longer includes the terminal-based TUI IDE. Users interested in the IDE should install the `fpc-ide` package. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/GNUToolchainF38 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 38 GNU Toolchain to gcc 13.0, binutils 2.39, and glibc 2.37. The existing gdb 12.1 will be used as-is. The set of core GNU Toolchain packages for Fedora 38 are as follows: * GNU C Compiler 13.0 ** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp), Fortran (gfortran), D (phobos), Objective C/C++. * GNU Binary Utilities 2.39 * GNU C Library 2.37 * GNU Debugger 12.1 (immediately available in Fedora 37) The gcc 13.0 change will be tracked in this top-level GNU Toolchain system-wide update. The binutils 2.39 change will be tracked in this top-level GNU Toolchain system-wide update. The glibc 2.37 change will be tracked in this top-level GNU Toolchain system-wide update. == 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 13.0, after the Fedora 38 release. It will contain many new features, documented here: https://gcc.gnu.org/gcc-13/changes.html. The latest release candidate for gcc 13 will be included in Fedora 38 and will be updated when released. The GNU Binutils version 2.39 was released before Fedora 38; and we have already been using this version of binutils in Fedora Rawhide successfully to build the distribution for the last 4 months. Given the present schedule for Fedora 38 we will continue to use Binutils 2.39. The GNU C Library version 2.37 is expected to be release before Fedora 38; we have started closely tracking the glibc 2.37 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 38 will branch after the release of glibc 2.37. However, the mass rebuild schedule means Fedora 38 will mass rebuild (if required) before the final release of glibc 2.37, but after the ABI is frozen. The GNU Debugger version 12.1 was released before Fedora 38; and we plan to continue to use this version of the debugger. == 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 38 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/XX #XX] ** Filed after approval. * 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. Some source changes may be required for the gcc 13 update. Please refer to the latest changes here: https://gcc.gnu.org/gcc-13/changes.html Any source level changes required for glibc 2.37 will be noted here: https://sourceware.org/glibc/wiki/Release/2.37#Packaging_Changes == How To Test == The GNU Compiler Collection has its own testsuite which is run during the package build and examined by the gcc developers before being uploaded. The GNU C Library has its own testsuite 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 testsuite which is run during the package build and examined by binutils developers before being uploaded. The regression testsuite is run to verify the correct operation of the static linker and attendant utilities. The GNU Debugger has its own testsuite which is run during the package build and examined by gdb developers before being uploaded. The regression testsuite is run to verify the correct operation of the debugger. == User Experience == Fedora developers as well as developers using the distribution will be able to use and
F38 proposal: Noto Fonts For More Languages (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/NotoFontsForMoreLang
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 ==
Changes the default font for more languages to Noto Fonts.
== Owner ==
* Name: [[User:Tagoh| Akira TAGOH]]
* Email:
== Detailed Description ==
We have changed our default fonts to Noto in
[[Changes/DefaultToNotoFonts|f36]] though, some languages was still
missing even though Noto Fonts provides fonts for their languages.
This Change continues to accomplish consistent text rendering across
our supported languages as far as possible.
The following languages are targeted in this Change:
* Khmer
* Thai
== Feedback ==
== Benefit to Fedora ==
We would get better text rendering on applications and desktops for
the above languages as well as languages we have already migrated.
Also this change should save about 344kB on the fresh install.
$ rpm -qlv khmer-os-system-fonts thai-scalable-waree-fonts | awk
'BEGIN{a=0}{a+=$5}END{print a}'
504660
$ rpm -qlv google-noto-sans-khmer-vf-fonts
google-noto-sans-thai-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print a}'
160573
== Scope ==
* Proposal owners:
** Update google-noto-fonts and fonts packages currently used as
default, to change the priority of fontconfig config.
** Update langpacks to update dependencies
** Update comps to update default fonts sets
** Update lorax templates
* Other developers: Nothing
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Nothing
== Upgrade/compatibility impact ==
The migration will be done by updating langpacks. after upgrading and
rebooting, the default font will be Noto instead of `Khmer OS
System`/`Waree`.
Since this change aims to switch non-variable fonts to variable fonts,
it may not works with legacy applications as expected such as missing
some variants. in that case, you can install non-variable fonts
packages. the package name will be similar and simply drop -vf from
the variable fonts packages.
== How To Test ==
* This change can be simply tested by fc-match command like `fc-match
sans:lang=`, `fc-match serif:lang=` and
`fc-match monospace:lang=`. `:lang=km` for Khmer and
`:lang=th` for Thai.
* Test the text rendering in your favorite application, which use the
system default font.
== User Experience ==
Khmer/Thai Users will see the default font is changed to Noto by this change.
== Dependencies ==
Only khmer-os-system-fonts, thai-scalable-waree-fonts, langpacks, and
fontconfig are required to update. Other packages which explicitly has
a dependency to above fonts packages are basically optional to update.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the
relevant packages updated.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
None
== Release Notes ==
The default fonts for Khmer and Thai will be Google Noto Fonts to keep
consistency on the text rendering and to provide better quality among
languages.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
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 ==
Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
the default approach.
Packaging Guidelines and other documentation are adjusted to describe
this approach first.
Various tools that provide spec file templates are adjusted.
== Owner ==
* Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
* Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec|
The spec file contains:
Version: 1.2.3
Release: %autorelease
...
%changelog
%autochangelog
Rpmautospec uses git history. Whenever the package is built
(`.src.rpm` is generated), rpmautospec tooling will replace the
`%autorelease` macro with the number of commits since the last commit
that changed the `Version` field, and the `%autochangelog` macro with
a text generated from `git log`.
For details see the
[https://docs.pagure.org/fedora-infra.rpmautospec/principle.html
docs].
}}
Rpmautospec has been deployed in Fedora since F35
([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%).
But it is still a "second-class citizen": most documentation doesn't
mention it, and many packagers know that it exists but don't use it in
their packages. We think that it's reasonable to switch to
`%autorelease`+`%autochangelog` for almost all packages and that
Packaging Guidelines and various packaging howtos should recommend
that approach to packagers. The "traditional" approach of
manually-managed `Release` and `%changelog` will remain valid and will
be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to
all releases. The goal is to update the Packaging Guidelines and other
prominent documentation and tools now, and other docs and tools
possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses
`%autorelease`+`%autochangelog` since a few releases, so most rust
packages have switched. (Generally, rust spec files are recreated
using the generator for each new version, so the switch would happen
whenever a new version is packaged unless the packager opts out.)
== Feedback ==
* Thread on fedora-devel in August 2022:
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/T6J2WGIMRCTW77QTH4D7HPNS6KUGDQOQ/
rpmautospec by default]
** open issues: a bunch have been fixed.
** maintenance: Nils will add some co-maintainers.
** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see
Scope section.
== Benefit to Fedora ==
Various packaging workflows become smoother for packagers and contributors:
* packagers don't need to touch the `Release` field on updates
* packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
* patches to the spec file can be cherry-picked between branches
without trivial conflicts
* pull requests on src.fedoraproject.org can be merged without trivial conflicts
* in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over
== Scope ==
* Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to
make `%autorelease`+`%autochangelog` the default
** implement fixes for issues reported by packagers
** make semi-regular releases of rpmautospec
([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/K5EA5OGRX2BCZ353C7S4MQVZTSH2BH63/
0.3.1 was released on November 17th, and should be deployed to
production in about two weeks])
* Other developers:
** provide pull requests to other docs as appropriate
** accept the changes to documentation
** update other spec file generators (pip2rpm, others?)
* Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641
** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the
command will fail. A replacement workflow that instead restores
`%autorelease`+`%autochangelog` in the file committed to dist-git
needs to be implemented.
* Related work
** https://pagure.io/rpkg/c/3087dd7
** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: a list of places to be updated
** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning
**
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Rpmautospec is already used by a decent
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 12:02 PM Tomasz Torcz wrote: > > On Fri, Dec 30, 2022 at 12:59:19AM -0500, Nico Kadel-Garcia wrote: > > On Wed, Dec 28, 2022 at 7:01 AM Ralf Corsépius wrote: > > > > > > Am 28.12.22 um 11:49 schrieb Peter Boy: > > > > > > > > It is a good idea to make the timeout configurable. But the default > > > > timeout for servers must remain unchanged. > > > > > > My problem is not "defined timeouts" it is systemd delaying shutdowns > > > for no obvious reasons. > > > > You've apparently not encountered the corruption of a database under > > heavy load where the cache where swapspace has not yet been propagated > > to disk. Imagine a server running a lot of virtual machines for an > > image of what an overly aggressive shutdown timeout can do to your > > otherwise stable systems. > > This sounds serious, and this is the situation in which default > setting is not correct, no matter if its 15 seconds or 120 seconds. > The database and VM services should define own timeout (it goes from 0 > to infinity, plenty of values to choose from). I didn't mean to give Talf a hard time. systemd has been used to inflict unwelcome timeouts before, so it should be modified only with caution. I'm especially thinking of that infamous "let's make systemd responsible for ending logins" change that broke screen, nohup, tux, and leaving background tasks running. (See https://lwn.net/Articles/690151/ ) We need to be cautious about not being able to personally picture why someone would use an existing default and overriding it casually, and inflicting our new logic on the unsuspecting existing userbase. ___ 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 2157099] New: perl-DateTime-Format-Natural-1.14 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2157099 Bug ID: 2157099 Summary: perl-DateTime-Format-Natural-1.14 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-Format-Natural 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, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 1.14 Upstream release that is considered latest: 1.14 Current version/release in rawhide: 1.13-3.fc37 URL: http://search.cpan.org/dist/DateTime-Format-Natural/ 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/7086/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-DateTime-Format-Natural -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2157099 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Fri, Dec 30, 2022 at 12:59:19AM -0500, Nico Kadel-Garcia wrote: > On Wed, Dec 28, 2022 at 7:01 AM Ralf Corsépius wrote: > > > > Am 28.12.22 um 11:49 schrieb Peter Boy: > > > > > > It is a good idea to make the timeout configurable. But the default > > > timeout for servers must remain unchanged. > > > > My problem is not "defined timeouts" it is systemd delaying shutdowns > > for no obvious reasons. > > You've apparently not encountered the corruption of a database under > heavy load where the cache where swapspace has not yet been propagated > to disk. Imagine a server running a lot of virtual machines for an > image of what an overly aggressive shutdown timeout can do to your > otherwise stable systems. This sounds serious, and this is the situation in which default setting is not correct, no matter if its 15 seconds or 120 seconds. The database and VM services should define own timeout (it goes from 0 to infinity, plenty of values to choose from). -- Tomasz Torcz “If you try to upissue this patchset I shall be seeking to...@pipebreaker.pl an IP-routable hand grenade.” — Andrew Morton (LKML) ___ 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: Web Assembly on Fedora: interested in a Fedora SIG to work on this?
I'm interested in following along with this as well. Just learning about WebAssembly's potential at the moment. It does seem that a currently missing component is to harness fedora's infrastructure to build wasm targets and distribute wasm artifacts. Capturing the steps necessary to build and rebuild libraries is going to be necessary for automation and keeping current with security bugfixes. Distributing those updated artifacts to infrastructure-or-parties building packages which rely on them is going to be necessary to avoid wasteful duplication of effort. I just tried to build proj, which failed because it needed sqlite. I found a fork of a two-year-old release of sqlite that's been adapted to function in a peer to peer network called fluent as well as compile to webassembly. There's been 31 releases of sqlite in the interim, many of them during the year that the author of the fork was committing bugfixes to the frozen original code. As this was an exercise, I quit here because I learned all I needed to. I may go a bit further than just saying that such an effort requires the use of fedora's existing binary artifact infrastructure. You may need to create a centralized place to maintain forks of the upstream repositories which contain branches dedicated to the web assembly ports. The patching strategy currently used by rpmbuild may not be enough--I'd expect you'd need a full DVCS hub. You'll want something you control that facilitates transferring the web assembly support back up to the upstream, hence the "D". Please do add me to the list. I may not have time to do much more than think on problems, but I'm interested in following your progress. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On Fri, Dec 30 2022 at 10:42:29 AM +0100, Peter Boy wrote: But the **default* values must provide the most safe operation possible and not require any intervention from the system administrator to achieve that. I think we need to find some way for Workstation to have different defaults than Server. Unfortunately, as the change is currently implemented, it will apply to all Fedora editions ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
On 12/29/22 20:27, John Reiser wrote: A years-earlier "by-hand" example of related coding in plain-C is scripts/recordmcount.c in the source code for Linux kernel. Yep, functions like htonl have been in use in C for decades. It is sad to see this standardization to little-endian (e.g. ppc64->ppc64le), which weakens the ability to code things right because everything works in the majority of the machines. I would have personally preferred the world to go to big-endian, since it makes memory dumps much more readable and int size errors very fatally evident. Instead, I would expect somebody to soon propose switching the IP protocol to little endian "because, hey, the rest of the world is little-endian, right?". regards. Best -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
On 12/30/22 06:59, Nico Kadel-Garcia wrote: You've apparently not encountered the corruption of a database under heavy load where the cache where swapspace has not yet been propagated to disk. Imagine a server running a lot of virtual machines for an image of what an overly aggressive shutdown timeout can do to your otherwise stable systems. Wait a moment, if you have memory cached data (dirty pages), the stuff will reach the disk whatever you do to the processes; the kernel will absolutely write any dirty page to disk when unmounting the fs. The problem you are describing can only happen if your database is in a VM, which gets killed during operation. But killing a VM is equivalent to suddenly powering off a bare metal, and if your DB becomes corrupted because of this, it is possibly a low quality software, abusing the "DB" name. Additionally, there are options governing how a "sync" in the VM should be handled (e.g. assure data is in host RAM vs assure data is in host disks). Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20221230.n.0 changes
OLD: Fedora-Rawhide-20221229.n.0 NEW: Fedora-Rawhide-20221230.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 6 Dropped packages:1 Upgraded packages: 34 Downgraded packages: 0 Size of added packages: 11.78 MiB Size of dropped packages:236.04 KiB Size of upgraded packages: 886.53 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 51.55 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: ffmpegthumbs-22.12.0-1.fc38 Summary: KDE ffmpegthumbnailer service RPMs:ffmpegthumbs Size:178.93 KiB Package: rust-joinery-3.1.0-1.fc38 Summary: Small crate for generically joining iterators with a separator RPMs:rust-joinery+default-devel rust-joinery+nightly-devel rust-joinery+proc-macro2-devel rust-joinery+quote-devel rust-joinery+token-stream-devel rust-joinery-devel Size:56.91 KiB Package: rust-minidom0.12-0.12.0-1.fc38 Summary: Small, simple DOM implementation on top of quick-xml RPMs:rust-minidom0.12+comments-devel rust-minidom0.12+default-devel rust-minidom0.12-devel Size:41.59 KiB Package: rust-pore-0.1.6-1.fc38 Summary: Performance oriented reimplementation of repo RPMs:pore rust-pore+default-devel rust-pore-devel Size:11.06 MiB Package: rust-quick-xml0.17-0.17.2-1.fc38 Summary: High performance xml reader and writer RPMs:rust-quick-xml0.17+default-devel rust-quick-xml0.17+encoding-devel rust-quick-xml0.17+encoding_rs-devel rust-quick-xml0.17+serde-devel rust-quick-xml0.17+serialize-devel rust-quick-xml0.17-devel Size:146.26 KiB Package: titools-0.2^20160515gcc7dc08-1.fc38 Summary: Command-line programs for communicating with a TI calculator RPMs:titools Size:314.92 KiB = DROPPED PACKAGES = Package: mingw-qwtpolar-1.1.1-13.fc37 Summary: MinGW Windows qwtpolar library RPMs:mingw32-qwtpolar-qt5 mingw64-qwtpolar-qt5 Size:236.04 KiB = UPGRADED PACKAGES = Package: 4ti2-1.6.9-13.fc38 Old package: 4ti2-1.6.9-12.fc38 Summary: Algebraic, geometric and combinatorial problems on linear spaces RPMs: 4ti2 4ti2-devel 4ti2-libs Size: 4.77 MiB Size change: 2.37 KiB Changelog: * Thu Dec 29 2022 Jeff Law - 1.6.9-13 - Add missing #include for gcc-13 Package: GitPython-3.1.30-1.fc38 Old package: GitPython-3.1.27-3.fc37 Summary: Python Git Library RPMs: python3-GitPython Size: 382.86 KiB Size change: 2.72 KiB Changelog: * Thu Dec 29 2022 Lubom??r Sedl - 3.1.30-1 - Rebase to latest version Package: OpenLP-3.0.0-1.fc38 Old package: OpenLP-2.4.6-18.fc37 Summary: Open source Church presentation and lyrics projection application RPMs: OpenLP Size: 4.37 MiB Size change: -603.99 KiB Changelog: * Thu Dec 29 2022 Release 3.0 - 3.0.0-1 - Rebuilt for Release 3.0.0 Package: bear-3.0.21-1.fc38 Old package: bear-3.0.20-5.fc38 Summary: Tool that generates a compilation database for clang tooling RPMs: bear Size: 2.54 MiB Size change: 4.13 KiB Changelog: * Tue Nov 29 2022 Benjamin A. Beasley 3.0.20-6 - Update License to SPDX * Thu Dec 29 2022 Benjamin A. Beasley 3.0.21-1 - Update to 3.0.21 (close RHBZ#2156922) Package: chordpro-6.000-1.fc38 Old package: chordpro-5.990-2.fc38 Summary: Print songbooks (lyrics + chords) RPMs: chordpro chordpro-abc chordpro-gui chordpro-lilypond Size: 1013.66 KiB Size change: -464 B Changelog: * Thu Dec 29 2022 Johan Vromans - 6.000-1 - Upgrade to upstream. Package: freewrl-4.3.0-14.20200221gite99ab4a.fc38 Old package: freewrl-4.3.0-13.20200221gite99ab4a.fc37 Summary: X3D / VRML visualization program RPMs: freewrl freewrl-devel freewrl-java libEAI libEAI-devel Size: 43.01 MiB Size change: 87.80 KiB Changelog: * Thu Dec 29 2022 Tom Callaway - 4.3.0-14.20200221gite99ab4a - disable plugin more completely with a conditional Package: golang-sr-rockorager-tcell-term-0.4.0-1.fc38 Old package: golang-sr-rockorager-tcell-term-0.3.0-1.fc38 Summary: An embeddable terminal widget for tcell RPMs: golang-sr-rockorager-tcell-term-devel Size: 35.33 KiB Size change: 677 B Changelog: * Fri Dec 30 2022 Maxwell G - 0.4.0-1 - Update to 0.4.0. Fixes rhbz#2156426. Package: graphviz-7.0.5-1.fc38 Old package: graphviz-7.0.4-1.fc38 Summary: Graph Visualization Tools RPMs: graphviz graphviz-R graphviz-devel graphviz-devil graphviz-doc graphviz-gd graphviz-go graphviz-graphs graphviz-gtk2 graphviz-guile graphviz-java graphviz-lua graphviz-ocaml graphviz-perl graphviz-python3 graphviz-ruby graphviz-sharp graphviz-smyrna graphviz-tcl Size: 43.04 MiB Size change: 91.39 KiB Changelog: * Thu Dec 29 2022 Tom Callaway - 7.0.5-1 - update to 7.0.5 - patch out distutils usage to build with Python 3.12 Package
Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
> Am 29.12.2022 um 16:29 schrieb David Malcolm : > > On Thu, 2022-12-29 at 13:03 +1000, Peter Hutterer wrote: >> On Thu, Dec 22, 2022 at 09:17:28PM +0100, Björn Persson wrote: >>> Vít Ondruch wrote: Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a): > When the connection fails, the Xserver returns a reason in > plain text. > In that case, the reason for the connection being rejected > would be > „Swapped clients prohibited“. Appreciate that there is at least some explanation, but if I saw this error, I would not be much smarter what is going on and how should I proceed >>> >>> Yes, that's a really bad error message. My reaction would be "What >>> nonsense is that? I haven't swapped any clients." If it had at >>> least >>> said "byte-swapped" it would probably have gotten me searching in >>> the >>> right direction, but if the X server wants to be helpful it should >>> say >>> "big/little-endian mismatch; the option AllowSwappedClients is >>> off". >> >> Thanks, I've changed the error message to say `byte-swapped`, it >> hasn't >> been merged upstream yet after all. This particular message is >> handled >> in the DDX-independent bits though (shared code for Xorg, Xwayland, >> etc.), the option AllowSwappedClients only exists for Xorg since the >> other X server don't have an xorg.conf. > > Could the error message include a URL to documentation about the config > option? That would really help discoverability. I would also strongly advocate / asking to make the (error) message more detailed. So don't just make it "byte-swapped" but refer to the configurability , even if it's just a "see .conf“. Especially if something has worked before, this is very important. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
> Am 30.12.2022 um 06:59 schrieb Nico Kadel-Garcia : > >> Am 28.12.22 um 11:49 schrieb Peter Boy: >>> >>> It is a good idea to make the timeout configurable. But the default >>> timeout for servers must remain unchanged. >> >> My problem is not "defined timeouts" it is systemd delaying shutdowns >> for no obvious reasons. ... >> And as you asked: On my (bare metal) servers, Im am occasionally >> experiencing delayed shutdowns in the order of several minutes. >> >> This is simply inacceptable! If it is not acceptable for you, configure it to your needs. But the **default* values must provide the most safe operation possible and not require any intervention from the system administrator to achieve that. This has been a fundamental and outstanding principle of Fedora since long time ago, maybe even from the beginning. And I still remember very unpleasantly times where I could, of course, go online with a default Fedora installation without worrying, but Debian/Ubuntu to my surprise did not even install a Firewall, let alone safely preconfigured. The current values may be too high. But they have proven themselves at least. And as long as we don't have reliable data for more optimal values, it would be **negligent** to shorten them out of sheer impatience. The long time frames only come into effect anyway when something doesn't run as smoothly as one would like. And it is precisely in such a case that caution is called for. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy p...@fedoraproject.org Timezone: CET (UTC+1) / CEST (UTC+2) Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast ___ 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
