Re: FESCo election nominations are now open
As a reminder, nominations are open through 10 May. There are currently four candidates for four open seats. On Wed, Apr 19, 2023 at 12:43 PM Ben Cotton wrote: > > Now through 10 May, you may nominate candidates for the Fedora > Engineering Steering Committee (FESCo). > > To nominate yourself (or others, if you check with them first), visit > https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations > > For more information, see the Community Blog post: > https://communityblog.fedoraproject.org/f38-election-nominations-now-open/ -- 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
F39 proposal: Fedora Onyx (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Fedora_Onyx 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 == Creation of an official Fedora immutable variant with a Budgie Desktop environment, complementing Fedora Budgie Spin and expanding the immutable offerings of Fedora. == Owner == * Name: [[User:joshstrobl| Joshua Strobl]] * Primary Contact Person: [[User:joshstrobl| Joshua Strobl]] * Email: joshstr...@fedoraproject.org * SIG: [[SIGs/Budgie|Budgie]] == Detailed Description == Fedora Onyx is an immutable desktop operating system, featuring the Budgie Desktop environment. Fedora Onyx leverages the same foundational technologies as other Fedora immutable variants such as Fedora Silverblue, Fedora Kinoite, and Fedora Sericea (flatpak, rpm-ostree, podman, toolbx). Fedora Onyx is built for people that are attracted to / find value in the Fedora computing platform and Budgie Desktop environment, but need the robust immutability and atomic capabilities that rpm-ostree provides, which are not be offered through traditional Fedora spins (e.g. Fedora Budgie Spin). Original change proposal for Fedora Budgie Spin: [[Changes/FedoraBudgie]] == Feedback == No specific feedback received so far. == Benefit to Fedora == Fedora Onyx will expand Fedora’s existing attractive offerings of immutable operating systems, providing an on-ramp for potential users to the Fedora platform, as well as a desired experience among current Fedora Budgie Spin users that wish to experiment with rpm-ostree or dive into tooling that pairs well with the immutable experience. By actively building on and leveraging technologies adopted by similar immutable variants from Fedora (Kinoite, Sericea, and Silverblue), Fedora Onyx may help to strengthen those variants by putting more contributors behind building and maturing our shared technologies. == Scope == * Proposal owners: ** The Budgie SIG will submit Pungi changes needed to add this new variant to the compose. ** The Budgie SIG will submit the changes to add a new sub-package to fedora-release. ** The Budgie SIG will maintain the Onyx specific rpm-ostree config in the workstation-ostree-config repo. * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/11411 #11411] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: Submitted as [https://pagure.io/Fedora-Council/tickets/issue/451 #451] * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == N/A. Not a System Wide Change. ostree installations will be able to seamlessly rebase to onyx in the same way they would any other variant. == How To Test == TBA. Instructions will be posted on Fedora Discussion upon landing of the required components such as rpm-ostree config. These instructions will follow similar steps as rebasing for any other rpm-ostree variant. == User Experience == N/A. No changes for existing Fedora users, including those using Fedora Budgie Spin. Users of Fedora Onyx will receive a similar user experience to Fedora Budgie Spin, with a smaller package set to encourage users to more heavily leverage flatpak to curate their own desired experience. == Dependencies == N/A. Not a System Wide Change. == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == There may be known issues with other Fedora immutable variants which may be addressed by existing documentation such as the [https://docs.fedoraproject.org/en-US/fedora-silverblue/troubleshooting/ Fedora Silverblue Troubleshooting document]. == Release Notes == Fedora Onyx has been introduced as a new immutable variant of Fedora Linux / Fedora Budgie Spin, featuring the Budgie Desktop environment and the same robust technologies as our other variants such as Kinoite, Sericia, and Silverblue (flatpak, rpm-ostree, podman, toolbx). -- 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
F39 proposal: Man-pages-ru Retirement (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/ManPagesRuRetirement 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 == Retiring man-pages-ru because it is already part of the man-pages-l10n. == Owner == * Name: [[User:ljavorsk| Lukas Javorsky]] * Email: ljavo...@redhat.com == Detailed Description == Upstream (man-pages-l10n) has integrated Russian translations for man-pages. It means we no longer need to have a specific (man-pages-ru) package for it. [https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/37b44f5a8ad3999501c79a20b67a27e17cc65630 Upstream commit containing the change] The plan is simple: 1) Deprecate man-pages-ru package 2) Enable 'ru' translations for man-pages-l10n (temporary disabled due to conflicts). [https://src.fedoraproject.org/rpms/man-pages-l10n/c/00a88c237e1fd7cdef9c52665128b155cf14243c?branch=rawhide Commit disabling it] Also add Obsolete and Provides for man-pages-ru package. == Feedback == Early feedback from the community is positive, the feedback is located in this ([https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/WGLMJ7XXB5JUER57GEOZQBFMNKHD5FSZ/ Devel list announce]) == Benefit to Fedora == Fedora shouldn't maintain a redundant package. This change would make it easier for the maintainer as well as for the packages that requires man-pages-l10n and man-pages-ru. == Scope == * Proposal owners: Package man-pages-ru will be retired, and the man-pages-l10n will contain the Russian translations. * Other developers: Change the names of their BuildRequires/Requires accordingly. * 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: == Upgrade/compatibility impact == When following the plan in Detailed Description there will be no need for manual action. Everything will be handled by the automated dnf upgrade. == How To Test == == User Experience == == Dependencies == List of the packages from Fedora 39 === man-pages-ru === dnf repoquery --whatrequires man-pages-ru | pkgname dnf repoquery --whatrequires '/usr/share/man/ru/*' | pkgname == Contingency Plan == * Contingency mechanism: Remove the man-pages-l10n build with Russian translation enabled. Revert deprecation of the man-pages-ru package. * Contingency deadline: Beta freeze * Blocks release? No ''NOTE: If we don't finish this change by the deadline, it is possible to just complete this change with the next release.'' == Documentation == [https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/commit/37b44f5a8ad3999501c79a20b67a27e17cc65630 Upstream issue] [https://bugzilla.redhat.com/show_bug.cgi?id=2163421 Bugzilla tracker] [https://sourceforge.net/p/man-pages-ru/discussion/1102373/thread/7dda92a232/ man-pages-l10n upstream discussion with man-pages-ru upstream about this] == Release Notes == -- 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
F39 proposal: mkosi-initrd (Self-Contained Change proposal)
redhat.com/show_bug.cgi?id=2189633) ** verify (and fix if necessary) `mkosi-initrd`/`systemd`/other packages to work with: *** root on a plain partition *** root on LVM2 *** root on LUKS *** root on RAID *** root on NFS *** hibernation ** provide a `kernel-install` plugin that builds an initrd locally ** provide a `kernel-install` plugin that combines this initrd with a kernel binary into a Unified Kernel Image locally ** make dracut not interfere with mkosi-initrd (merge https://github.com/dracutdevs/dracut/pull/1825 or carry downstream patch) ** work with koji developers to allow `mkosi-initrd` to run in koji (stretch goal 1). This requires changing koji to allow access to downloaded rpms during build. ** add a `mkosi-initrd-initrd` (name TBD) package that builds a set of subpackages with initrds (stretch goal 2). (Out of scope: support for root on iSCSI is not planned currently. Our experiments with iSCSI show that the existing tooling is a bunch of terrible scripts that don't work at all outside of dracut.) More items may be added to Scope or listed as not planned based on feedback. * Other developers: ** koji developers: help with the rpms-in-buildroot functionality and ** koji maintainers and releng: deploy changes in koji in Fedora infra ** anyone: Install the new packages to opt-in into testing the new initrds. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == This is new functionality that will only impact people who opt-in. == How To Test == * Right now: ** enable the copr and install `mkosi-initrd` (see [https://github.com/systemd/mkosi-initrd/#mkosi-initrd--build-initrd-images-using-distro-packages instructions]) ** adjust configuration:echo 'initrd_generator=mkosi-initrd' >>/etc/kernel/install.conf# Until https://github.com/dracutdevs/dracut/pull/1825 is mergedmkdir -p /etc/kernel/install.dln -s /dev/null /etc/kernel/install.d/50-dracut.install ** Upgrade or reinstall kernel package and reboot * After `mkosi-initrd` has an official build: ** disable the copr and update to the distro package ** Upgrade or reinstall kernel package and reboot * After stretch goal 2: ** Install `mkosi-initrd-initrd-` ** Upgrade or reinstall kernel package and reboot == User Experience == Ideally, there should be no visible change for users. Obviously, when text logs are shown the console, the output is a bit different. After stretch goals 2, installation will be quicker. == Dependencies == Support for UKIs in grub2 was implemented in [[Changes/Unified_Kernel_Support_Phase_1]], but the support for UKIs in grub2 was not merged. This support is a requirement for people who want to use mkosi-initrd UKIs with grub2. == Contingency Plan == * Contingency mechanism: Postpone introduction of features to a later release. If it turns out that initrds are faulty, users who installed them will need to manually switch back to dracut initrds. * Contingency deadline: Any time. * Blocks release? No. == Documentation == https://github.com/systemd/mkosi-initrd/blob/main/docs/fedora.md == Release Notes == Simplified initrds built with `mkosi-initrd` are available for testing. -- 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
F39 proposal: Lazarus repackaging (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/F39-Lazarus-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 `lazarus` package (the Lazarus IDE for Free Pascal) into several sub-packages (built from the same spec file) and enable building the Lazarus Component Library for multiple widget sets, instead of just the default GTK2. == Owner == * Name: [[User:suve|Artur Frenszek-Iwicki]] * Email: == Detailed Description == The `lazarus` package will be split into multiple packages: * `lazarus-doc` - documentation * `lazarus-ide` - the IDE itself * `lazarus-lcl` - base package for the LCL (Lazarus Component Library), containing common LCL parts * `lazarus-lcl-nogui` - components for building non-graphical applications * `lazarus-lcl-gtk` - components for building programs using the GTK2 widget library * `lazarus-tools` - command-line tools shipped with Lazarus, e.g. `lazbuild` The `lazarus` package will become a metapackage - it will not contain any files itself, instead pulling in all the packages mentioned above. Several new packages will also be introduced: * `lazarus-lcl-gtk3` - support for building programs using the GTK3 widget library * `lazarus-lcl-qt` - ditto, for Qt4 * `lazarus-lcl-qt5` - ditto, for Qt5 == Benefit to Fedora == Currently, Lazarus in Fedora only supports building programs with the GTK2 widget set. With this change, Lazarus will gain support for additional widget sets, allowing users to build their applications using GTK3, Qt4 and Qt5. Maintainers of packages depending on Lazarus can switch from BuildRequiring `lazarus` to the following set: * `lazarus-lcl-nogui` (may not be needed, depending on the program) * `lazarus-lcl-gtk2` (or a different widget set, if the maintainer so wishes) * `lazarus-tools` This minimal package set is about ~60MiB smaller than the current Lazarus package. This should make builds slightly faster. == Scope == * Proposal owners: ** Edit `lazarus.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 == When upgrading Fedora 39, users who have the `lazarus` package installed should see the following sub-packages pulled in during the process: * `lazarus-doc` * `lazarus-ide` * `lazarus-lcl` * `lazarus-lcl-nogui` * `lazarus-lcl-gtk2` * `lazarus-tools` This set of packages should provide the same files and functionality as the current monolithic `lazarus` package. == How To Test == A copr repository has been created where users can test out the modified package: [https://copr.fedorainfracloud.org/coprs/suve/lazarus-split/ copr/suve/lazarus-split]. == User Experience == For users not interested in different widget sets, this Change should not affect their experience. Those wanting to build their programs using GTK3, Qt4 or Qt5 will gain the ability to do so. == Dependencies == None. == Contingency Plan == Worst case scenario - give up, revert to an old version of `lazarus.spec` and rebuild the package. == Documentation == N/A (not a System Wide Change) == Release Notes == The `lazarus` package has been split into multiple sub-packages. Apart from GTK2, the IDE now supports building programs using the GTK3, Qt4 and Qt5 widget sets - available by installing `lazarus-lcl-*` packages. -- 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
F39 proposal: Perl 5.38 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/perl5.38
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 ==
A new ''perl 5.38'' version brings a lot of changes done over a year
of development. Perl 5.38 will be released in May 20th 2023. See
[https://metacpan.org/release/SHAY/perl-5.37.11/view/pod/perldelta.pod
perldelta for 5.37.11] for more details about new release.
== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]], [[User:Mspacek| Michal
Josef Špaček]]
* Email: ,
== Current status ==
=== Completed Items ===
=== Items in Progress ===
=== Items to Be Done ===
* Get dedicated build-root from rel-engs (''f39-perl'')
* Upstream to release Perl 5.38
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.38.0
* Rebuild all dual-lived packages (83) - otherwise dnf recommends
--skip-broken and fails
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Rebuild packages requiring ''libperl.so'' or versioned
''perl(MODULE_COMPAT)'': Use Fedora::Rebuild dependency solver
* Undefine perl_bootstrap
* Rebuild packages having perl_bootstrap condition in spec file (XX packages)
* Rebuild all updated packages
* [https://jplesnik.fedorapeople.org/5.38/ Final lists of results]
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f39'' build root
* Rebuild Perl packages: 0 of 600 done (0 %)
* Failed packages (0):
* Rebuild Fedora modules: 0 of 0 (0 %)
* Create module perl:5.38 and rebuild dependencies
== Detailed Description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.38.0 version is stable release
this year.
== Benefit to Fedora ==
Up-to-date and latest perl release will be delivered to Fedora users.
== Scope ==
Every Perl package will be rebuilt in a dedicated ''f39-perl''
build-root against perl 5.38.0 and then if no major problem emerges
the packages will be merged back to ''f39'' build-root.
* Proposal owners: New perl and all packages requiring ''libperl.so''
or versioned ''perl(MODULE_COMPAT)'' will be rebuilt into ''f39-perl''
build-root.
* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number]
Release engineers will be asked for new ''f39-perl'' build-root
inheriting from ''f39'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f39-perl'' packages back to
''f39'' build-root.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.38 will be removed from the
distribution. That will require to remove those packages from the
existing systems otherwise a package manager will encounter
unsatisfied dependencies. The developers in Perl language are advised
to install ''perl-doc'' and ''perl-debugger'' packages.
== How To Test ==
Try upgrading from Fedora 38 to 39. Try some Perl application to
verify they work as expected. Try embedded perl in
[https://src.fedoraproject.org/rpms/openldap slapd] or
[https://src.fedoraproject.org/rpms/net-snmp snmpd].
== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstallation.
== Dependencies ==
There is more than 3500 packages depending on perl. It is the first
rebuild where we will rebuild only all dual-lived packages and
packages which require ''libperl.so'' or versioned
''perl(MODULE_COMPAT)''. It means only about 600 packages needs to
rebuild. Most of them are expected not to break. Finishing this change
can be endangered only by critical changes in a toolchain.
''noarch'' packages don't need to be rebuilt now.
== Contingency Plan ==
* Contingency mechanism: If we find perl 5.38 is not suitable for
Fedora 39, we will revert back to perl 5.36 and we drop the temporary
build-root with already rebuilt packages.
* Contingency deadline: branching Fedora 39 from Rawhide.
* Blocks release? No.
== Documentation ==
* 5.38.0 perldelta
* An announcement on perl-devel mailing list
* An announcement on fedora-devel mailing list
== Release Notes ==
TBD
--
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
F39 proposal: BiggerESP (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/BiggerESP This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The Fedora installer includes an EFI System Partition of between 200MB and 600MB by default, of which the lower size is much too small for firmware updates on modern hardware and also for future bootloader features like UKI. This change will increase the minimum size of the ESP to be 500MB, which is also the same value used by Microsoft for Windows 10 and newer. == Owner == * Name: [[User:rhughes| Richard Hughes]] * Email: rich...@hughsie.com == Detailed Description == Modern hardware has UEFI firmware updates that are more than 64MB in size. The OEMs recommend a ESP free space of double the flash size plus 20MB and fwupd now enforces this requirement to ensure flash success. As the ESP is often shared between Windows and Linux, and also used for firmware updates, and soon to be used by UKIs it's not enough to just allocate a few hundreds of megabytes. Windows 10 and 11 allocates an ESP of at least 500MiB. Arch also specifies a minimum of 512 MiB. == Feedback == There is no alternative -- the ESP has to scale up if we want firmware updates to continue to work and to support UKIs for next-generation bootloaders. == Benefit to Fedora == Firmware updates will work on future hardware, and we can boot the kernel using UKIs using next-generation bootloaders. == Scope == * Proposal owners: We need to change a number in Anaconda: https://github.com/rhinstaller/anaconda/pull/4711 == Upgrade/compatibility impact == We can't grow the ESP in size, and so this change will only affect new installs. This is fine, as this will affect new hardware more than old hardware. == How To Test == Install Fedora and observe that /boot/efi has at least 276MB free space, even when installed alongside Windows. == Dependencies == Anaconda would need to be modified, and Fedora would have a / or /home partition that's ~300MB smaller by default than it is now. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora now defaults to a larger EFI System Partition which allows firmware updates to work on newer hardware, and allows future bootloader and kernel modernizations. -- 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
F39 proposal: Increase vm.max_map_count value (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/IncreaseVmMaxMapCount 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 == This change aims at increasing the default value of the `vm.max_map_count` sysctl == Owner == * Name: [[User:aleasto| Alessandro Astone]] * Email: ales.ast...@gmail.com == Detailed Description == Increase the vm.max_map_count sysctl default value. The goal is to improve compatibility with Windows games through wine or steam. Read on "Benefit to Fedora" for examples. Steam Deck is shipping with a default of `2147483642` (MAX_INT - 5) up from `65530` of Fedora; it makes sense to follow their lead and set the same value. == Feedback == This was briefly discussed in #fedora-devel and received positively. Concerns over possible downsides were raised. I am not aware of any, but more input here is desired. == Benefit to Fedora == The following Windows games will work out of the box (through wine or steam): * DayZ: https://steamcommunity.com/app/221100/discussions/0/3199241400256965913/ * Hogwarts Legacy: https://github.com/ValveSoftware/Proton/issues/6510 * Counter Strike 2 (Beta Windows build): https://www.youtube.com/watch?v=i02n_Ak98TA * Any other software that might be invoking a lot of mmaps == Scope == * Proposal owners: Add the new default to `/usr/lib/sysctl.d/` * Other developers: No work will be necessary unless the new default is found breaking some software * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A == Upgrade/compatibility impact == Upgrading to the new Fedora release will seamlessly update the default. No manual intervention is necessary. == How To Test == Temporarily set the new value with `sudo sysctl -w vm.max_map_count=2147483642` Run any of the software listed above to verify that it now works. Or run any other software to verify the change causes no regression. == User Experience == More Windows games will work out-of-the-box (through wine or steam) == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert the shipped configuration * Contingency deadline: Final Freeze * Blocks release? No == Documentation == The default value is currently hard-coded in the kernel, at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/mm.h?h=v6.2.12#n203 . It cannot be changed through the kernel defconfig, instead it must be set through sysctl. == Release Notes == The default value of the vm.max_map_count sysctl is increased -- 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
F39 proposal: Fedora Images on Azure (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Fedora_Images_On_Azure
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 ==
Azure is a massive public cloud and offering an official Fedora Cloud
image there would expand Fedora's user base. It also gives Fedora
Cloud users more options when selecting public clouds.
== Owner ==
* Name: [[User:mhayden| Major Hayden]], [[User:davdunc| David Duncan]]
* Email: ma...@redhat.com, davd...@amazon.com
== Detailed Description ==
We want to:
* Get Azure images built via the existing Pungi processes
* Publish Azure images via Azure's image gallery
* Test these images during regularly scheduled Fedora Cloud test days
before final release
* Ensure that the Azure URN is linked on the Fedora website in the
cloud downloads section (similar to how AWS images are listed today)
== Feedback ==
Another alternative would be to offer a VHD download option from a
mirror, but that
would require users to download the image and upload it to Azure on
their own. This
could be challenging for users without technical skills to complete
these steps or for
users with slow network connectivity.
== Benefit to Fedora ==
* Expands Fedora's official image public cloud footprint to Azure
(currently just AWS and GCP)
* Allows Azure customers to launch official Fedora images which were
tested before launch
* Raises awareness around Fedora Cloud images
== Scope ==
* Proposal owners: Isolated change that does not affect the OS itself
but does improve its availability in public clouds.
* Other developers: Does not affect other developers or features in Fedora.
* Release engineering: [https://pagure.io/releng/issue/11398 #11398]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
This is a net new offering in a cloud where Fedora was not previously offered.
== How To Test ==
* Verify that the Fedora image appears in Azure's image gallery
* Launch an Azure VM with the new Fedora image
* Complete the usual verification that is done on other clouds during
[https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230418.n.1_Cloud
test days]
== User Experience ==
Customers on Azure will notice that a new Fedora official images is
available to them.
Users of other platforms, such as workstation and server, will not see a change.
Customers of other clouds, such as AWS, will not see a change either.
== Dependencies ==
All dependencies are already packaged and tested. One of the biggest
is the Azure Linux
agent ({{package|WALinuxAgent}}), but it has been packaged in Fedora
for multiple releases and is
verified to work on Azure.
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora Cloud Edition is now available for use in Microsoft Azure.
--
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
FESCo election nominations are now open
Now through 10 May, you may nominate candidates for the Fedora Engineering Steering Committee (FESCo). To nominate yourself (or others, if you check with them first), visit https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations For more information, see the Community Blog post: https://communityblog.fedoraproject.org/f38-election-nominations-now-open/ -- 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
F39 proposal: Remove webkit2gtk-4.0 API Version (System-Wide Change proposal)
:2.0.2-17.hg2084299dffb6.fc38.1.noarch gthumb-1:3.12.2-7.fc38.x86_64 liferea-1:1.14.1-1.fc38.x86_64 lutris-0:0.5.12-3.fc38.x86_64 marker-0:0.0.2020.04.04-10.fc38.x86_64 meteo-0:0.9.9.1-4.fc38.x86_64 midori-0:9.0-12.fc38.x86_64 minigalaxy-0:1.2.2-3.fc38.noarch notes-up-0:2.0.6-4.fc38.x86_64 osmo-0:0.4.4-2.fc38.x86_64 pdfpc-0:4.6.0-1.fc38.x86_64 perl-Gtk3-WebKit-0:0.06-27.fc38.noarch rednotebook-0:2.29.3-2.fc38.noarch rubygem-webkit2-gtk-0:4.1.2-1.fc38.noarch setzer-0:0.4.8-2.fc38.noarch sugar-0:0.120-2.fc38.noarch sugar-browse-0:207-6.fc38.noarch sugar-toolkit-gtk3-0:0.120-2.fc38.x86_64 surf-0:2.0-15.fc38.x86_64 ulauncher-0:5.15.2-1.fc38.noarch vfrnav-0:20201231-38.fc38.x86_64 webkit2-sharp-0:0-0.17.20170219gita59fd76.fc38.x86_64 webkit2gtk4.0-devel-0:2.40.0-2.fc38.x86_64 webkit2gtk4.0-doc-0:2.40.0-2.fc38.noarch wxGTK-webview-0:3.2.1-5.fc38.x86_64 wxGTK3-webview-0:3.0.5.1-10.fc38.x86_64 xiphos-0:4.2.1-18.fc38.x86_64 xreader-libs-0:3.6.3-1.fc38.x86_64 yad-0:9.3-5.fc38.x86_6 == Contingency Plan == * Contingency mechanism: Bring back the removed subpackages * Contingency deadline: F39 beta freeze * Blocks release? No == Documentation == * [https://webkitgtk.org/reference/webkit2gtk/stable/index.html WebKit2 - 4.1] * [https://webkitgtk.org/reference/webkit2gtk-web-extension/stable/index.html WebKit2WebExtension - 4.1] * [https://webkitgtk.org/reference/jsc-glib/stable/index.html JavaScriptCore - 4.1] * [https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html Soup - 3.0: Migrating from libsoup 2] == Release Notes == The webkit2gtk4.0 and javascriptcoregtk4.0 packages providing WebKitGTK for GTK 3 and libsoup 2 applications have been removed. Use the webkit2gtk4.1 and javascriptcoregtk4.1 packages instead, providing WebKitGTK for GTK 3 and libsoup 3 applications. -- 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
F39 proposal: Remove standard storage option from Fedora EC2 images (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2ImagesNoStandardStorage 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 == AWS offers multiple [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html types of block storage] depending on the needs of the individual user. Fedora images are uploaded with `standard` and `gp2` currently (`gp3` will replace `gp2` very soon with another [https://fedoraproject.org/wiki/Changes/CloudEC2gp3 approved change]). The `standard` storage is a previous generation storage option with less performance and less consistent performance than the other storage types. It also causes some confusion when AWS customers look through the list of Fedora cloud images in the EC2 console because now they see '''four''' images (aarch64 + x86_64, both with `standard` and `gp2` storage). Removing the `standard` storage option would reduce the amount of images that appear in the console, but AWS customers could still provision Fedora on standard storage during the instance creation process if they really want that storage option. == Owner == * Name: [[User:mhayden| Major Hayden]] * Email: ma...@redhat.com == Detailed Description == The scripts that upload images to AWS will be adjusted so that they do not include the creation of an AMI with standard storage. AWS customers could still choose that option at instance creation time if needed. == Feedback == No alternatives have been proposed yet. == Benefit to Fedora == This would reduce the amount of Fedora AMIs that appear in the EC2 console by half and it would ensure that Fedora lands on AWS' best performing storage (soon to be `gp3`) by default. It avoids a situation where an AWS customer (without a strong knowledge in block storage types) starts a Fedora instance on standard storage and gets a low performance experience. It would have no effect on running instances or existing AMIs. == Scope == * Proposal owners: This is an isolated change that should be made within `fedimg` and it affects only the AMI creation process. * Other developers: Should not require work from other developers. * Release engineering: No work should be required from releng for this change. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: Should make it easier to display Fedora AWS images on the Fedora Cloud page. == Upgrade/compatibility impact == Existing systems will not be affected by this change. Customers launching new instances will get better performing storage by default but will still have the option to select standard storage if they really need it. == How To Test == 1. The updated version of fedimg should create only `gp2` (soon to be `gp3`) AMIs. 2. We can verify that the latest image upload from rawhide (after the fedimg change is made) will only include a gp2/gp3-backed image. == User Experience == AWS customers who are not familiar with different block storage types should always land on high performance storage. They still have the option to choose other storage types at instance creation time. == Dependencies == Only fedimg needs to be updated. There are no other dependencies. == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora AMIs for EC2 now default to the latest `gp2/3` storage option. -- 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
Fedora Linux 38 Final Go/No-Go meeting next week
The Fedora Linux 38 Final Go/No-Go[1] meeting is scheduled for Thursday 13 April at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F38 Final for the 18 April early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10487/ [2] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- 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
F39 proposal: RPM 4.19 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/RPM-4.19 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 RPM to the [https://rpm.org/wiki/Releases/4.19.0 4.19] release. == Owner == * Name: [[User:ffesti| Florian Festi]] * Email: ffe...@redhat.com == Detailed Description == RPM 4.19 contains various improvements over previous versions. Many of them are internal in nature such as moving from automake to cmake, improvements to the test suite, stripping copies of system functions, splitting translations into a separate project and more. There are still several user facing changes: * New rpmsort(8) utility for sorting RPM versions * x86-64 architecture levels (v2-v4) as architectures * Support for %preuntrans and %postuntrans scriptlets * Creating User and Groups from sysusers.d files including Provides and Requires or Recommends ([https://github.com/rpm-software-management/rpm/pull/2432 PR], [https://github.com/rpm-software-management/rpm/discussions/2277 Discussion]) * [https://rpm-software-management.github.io/rpm/manual/dynamic_specs.html Dynamic Spec generation] ** find_lang now being able to generate language sub packages The 4.19 alpha release is expected in April and the final release is expected in time for the Fedora 39 release cycle as usual. == Feedback == == Benefit to Fedora == This release comes with many improvements. It opens the possibility for Fedora to adopt the new major features mentioned above. == Scope == * Proposal owners: ** Release RPM 4.19 alpha ** Rebase RPM ** Assist with dealing with incompatibilities ** Integrate new User/Group handling *** Conflicts with the current one including the Provides generation in ''systemd-rpm-macros'' * Other developers: ** Test new release, report issues and bugs * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == * %patch without arguments and options is an error * %patchN syntax is deprecated * File globbing is now more consistent == How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation. == User Experience == There are no major differences in the normal user experience. == Dependencies == * Deprecated APIs are removed. This may require adjustments to software still using them. * so-name of librpm changes. Packages depending on it are expected to need a re-build * Packages running in the changes mentioned in the ''Upgrade/compatibility impact'' section might need adjusting. This should be relatively rare, though. == Contingency Plan == * Contingency mechanism: Revert back to RPM 4.18 * Contingency deadline: Beta freeze * Blocks release? No == Documentation == Release notes at https://rpm.org/wiki/Releases/4.19.0 and reference manual at https://rpm-software-management.github.io/rpm/manual/ == Release Notes == https://rpm.org/wiki/Releases/4.19.0 (still work in progress) -- 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
F39 proposal: Register EC2 Cloud Images with uefi-preferred AMI flag (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2UEFIPreferred 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 == A new feature of EC2 is to be able to register AMIs with a boot mode of `uefi-preferred` rather than picking one of `bios` or `uefi`. In EC2, aarch64 has always been UEFI, while x86-64 started out as BIOS only and some instance types have recently begun to support booting in UEFI mode. Previously, an AMI had to pick if it was UEFI or BIOS. With `uefi-preferred` it allows an AMI to launch with whatever firmware stack is available for the instance type, preferring UEFI when UEFI is an option. This proposal is to register the Fedora EC2 images with `uefi-preferred`, having the effect of switching to booting in UEFI mode on x86-64 in EC2 where available. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: traw...@amazon.com == Detailed Description == Some features of some EC2 instance types (such as secure boot) are only available in UEFI mode. There is also the standard set of advantages of UEFI over BIOS. All aarch64 instance types in EC2 have always been UEFI, while all x86-64 instance types were historically all BIOS. Recently, some x86-64 instance types have started to support UEFI mode. This was originally implemented as an option for instance launches and AMI registration. An AMI could state that it should be booted in UEFI mode. An AMI registered for UEFI would *not* boot on BIOS-only instance types. This meant that if you wanted to make available an OS that could boot on all instance types, you'd need a trio of AMIs: aarch64 UEFI, x86-64 BIOS, and x86-64 UEFI. With the `uefi-preferred` boot mode, one AMI registered for x86-64 will boot on UEFI where possible, but also boot BIOS if the instance type doesn't support UEFI. By registering Fedora AMIs with this boot mode, EC2 features that require UEFI (such as Secure Boot and NitroTPM) will be able to be used in Fedora, while still maintaining compatibility with BIOS only instance types. == Feedback == We have started registering Amazon Linux 2023 AMIs with this boot mode, albeit quite late in the development cycle of AL2023 due to the timing of when the `uefi-preferred` boot mode flag was added to EC2. == Benefit to Fedora == UEFI is becoming more ubiquitous amongst hardware, and operating under UEFI inside EC2 unlocks an increasing number of features such as Secure Boot and NitroTPM. The benefit for Fedora is a more uniform experience across cloud and non-cloud environments, simplifying the boot and runtime software stack. == Scope == * Proposal owners: * Modify the AMI registration call to include `uefi-preferred`, verifying that Fedora AMIs are assembled correctly for booting under UEFI. * Other developers: No changes needed by other developers * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == == How To Test == Once the AMI is registered, verify that the parameter is set, and that instances can be launched for each instance type. Normal testing should cover this. == User Experience == Users will be able to use features in EC2 that require UEFI such as Secure Boot and NitroTPM. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html * https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html == Release Notes == EC2 images are now registered with the `uefi-preferred` boot mode, thus boot in UEFI mode where possible. -- 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
F39 proposal: Changes of defaults in createrepo_c-1.0.0 (System-Wide Change proposal)
with the changes we can revert them in createrepo_c. * Contingency deadline: 2023-08-01 * Blocks release? No == Documentation == Createrepo_c documentation will be updated accordingly. == Release Notes == -- 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
F39 proposal: Register EC2 Cloud Images with IMDSv2-only AMI flag (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2IMDSv2Only 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 == In November 2019, AWS launched IMDSv2 (Instance Meta-Data Store version 2 - see https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ ) which provides "belt and suspenders" protections for four types of vulnerabilities that could be used to try to access the Instance Meta-Data Store available to EC2 instances. In that announcement, AWS recommended adopting IMDSv2 and restricting access to IMDSv2 only for added security. This can be done at instance launch time, or ([https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-machine-images-support-instance-metadata-service-version-2-default/ more recently in October 2022]) by providing a flag when registering an AMI to indicate that the AMI should by default launch with IMDSv1 disabled, and thus require IMDSv2. By enabling this flag for Fedora, we provide a better security posture for Fedora users running in EC2. When an AMI is registered for IMDSv2 it is still possible to launch instances with IMDSv1 enabled by providing the right option to the RunInstances EC2 API call. The flag merely switches the default. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: traw...@amazon.com == Detailed Description == Attached locally to every EC2 instance, the Instance Meta-Data Service runs on a special "link local" IP address of 169.254.169.254 that means only software running on the instance can access it. For applications with access to IMDS, it makes available metadata about the instance, its network, and its storage. The IMDS also makes the AWS credentials available for any IAM role that is attached to the instance. IMDS is the primary data source for `cloud-init` on EC2, and various other utilities will also access it. The [https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/ IMDSv2 announcement] gives more details as to the "belt and suspenders" protections it brings for four types of vulnerabilities that could be used to try to access the IMDS. By default, registering and then launching an AMI will launch an EC2 instance where both IMDSv1 and IMDSv2 is enabled. A recent addition to the EC2 API is the ability to register an AMI with a flag that indicates that the default behavior when launching an instance should be to have IMDSv2 enabled, and disable IMDSv1. The proposal is to (starting with Fedora 39), [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-new-instances.html#configure-IMDS-new-instances-ami-configuration register EC2 AMIs with this flag set as documented in the EC2 User Guide]. == Feedback == While Amazon Linux 2023 (then called AL2022) was in Tech Preview, its AMIs have been registered with this flag the [https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-machine-images-support-instance-metadata-service-version-2-default/ flag was announced in October 2022]. During this time, we have not received any negative feedback about this change. The only user of IMDSv1 calls that we have so far had to migrate to IMDSv2 calls has been some internal test cases run by a service team. == Benefit to Fedora == This change will provide Fedora users on EC2 with an enhanced security posture by default. == Scope == * Proposal owners: Modify AMI registration to include the flag. No other technical work is required. * Other developers: Any remaining code that talks to IMDS that does not use IMDSv2 will need to be adapted to continue to work by default. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == No impact for existing EC2 Instances. The AMI flag only affects new instance launches. == How To Test == Testing will not change from any regular Fedora EC2 AMI. The only additional check will need to be that the parameter is set correctly. == User Experience == This change should be transparent to users. == Dependencies == No dependencies. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A * Contingency deadline: N/A * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == -- 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
F39 proposal: EC2 AMIs default to the gp3 EBS volume type (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2gp3 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 == In Amazon EC2, Elastic Block Store (EBS) volumes can be one of several types. These can be specified at volume creation time, including for the default volumes that are created on instance launch. An AMI will have default volumes and volume types configured. Fedora currently defaults to the gp2 volume type. This proposal is to switch to gp3 as the default volume type for Fedora. The gp3 volume type is both more flexible than gp2, and can be up to 20% cheaper per GB. == Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: traw...@amazon.com == Detailed Description == According to https://aws.amazon.com/ebs/general-purpose/ : : Amazon EBS gp3 volumes are the latest generation of general-purpose SSD-based EBS volumes that enable customers to provision performance independent of storage capacity, while providing up to 20% lower price per GB than existing gp2 volumes. With gp3 volumes, customers can scale IOPS (input/output operations per second) and throughput without needing to provision additional block storage capacity. This means customers only pay for the storage they need. For the default configuration of Fedora 37 AMIs, this means the price per-GB-per-month for the default root volume would be $0.08 rather than $0.10. The default number of provisioned IOPs would increase from 100 with gp2, to 3000 with gp3. For gp2 volumes less than 1TB, they can burst up to 3000 IOPs (see [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html#gp2-performance GP2 volume performance]), while gp3 volumes provide a constant 3000 IOPs rather than only being able to burst to that number before running out of IO credits. == Feedback == Amazon Linux 2023 has switched to gp3 over the Amazon Linux 2 default of gp2, and we have not received any negative feedback on that change. == Benefit to Fedora == The benefit for Fedora users in EC2 is that of cheaper, more predictable, higher base-IOP, and more flexible IO performance by default. Fedora will also be switching to use the latest generation in general purpose EBS volume, fitting the desire of being First. == Scope == * Proposal owners: * Change gp2 to gp3 in AMI registration. * Other developers: N/A * Release engineering: * Policies and guidelines: N/A (not needed for this Change) --> * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == No affect on upgrades. Existing volumes remain gp2, and the volume type can be set on instance launch if gp3 is not preferred. == How To Test == No additional testing required beyond normal Fedora testing. == User Experience == This change will be largely transparent to users who take the default configuration, and do not run into IO limits on gp2 volumes today. The change for those users will be purely in reduced costs. For users who hit the burst limits of gp2, this change will improve IOP throughput to a constant 3000 IOPS. With the default volume size there is a slight throughput change when going from gp2 to gp3 (128MB/sec to 125MB/sec). == Dependencies == No dependencies == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == EC2 documentation details differences between gp2 and gp3: - https://aws.amazon.com/ebs/general-purpose/ - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/general-purpose.html == Release Notes == -- 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
F39 proposal: SPDX License Phase 2 (System-Wide Change proposal)
es/list/de...@lists.fedoraproject.org/thread/EXGT34EJPG3G4FJZ4R2SRAI342QDHFOF/ SPDX Statistics] * [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/NZIFT62REORSNS6MMES446PMCOOSEPSA/ SPDX Change Update] * [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3TGCSROJTSX5PXZLKOHCOMVIBTZDORNS/ SPDX - How to handle MIT and BSD] Challenges: * license-fedora2spdx tool uses mapping of legacy Fedora short names to SPDX identifiers using the [https://gitlab.com/fedora/legal/fedora-license-data/-/tree/main|fedora-license-data] to suggest SPDX identifiers. Where there is an apparent one-to-one mapping, the package maintainer could simply update the License field: and move on. * for many packages, particularly packages that use "umbrella" legacy short names that may refer to a large set of unrelated or loosely-related licenses, further inspection will be needed. Currently, Fedora documentation provides sparse advice on how to do this inspection and thus, a range of methods are used. == Benefit to Fedora == The use of standardized identifiers for licenses will align Fedora with other distributions and facilitates efficient and reliable identification of licenses. Depending on the level of diligence done in this transition, Fedora could be positioned as a leader and contributor to better license information upstream (of Fedora). == Scope == * Prep work: ** poll package maintainers on methods and tools used for license inspection ** create additional guidance (using info from above) ** planning/brainstorming on most efficient way to update packages, especially those that do not have one-to-one identifier update and will need closer inspection * Proposal owners (things sorted by done/todo and by priorities): ** Identify all remaining packages. ** Notify owners of these packages. ** After a grace period, submit PR to a package where the transition is easy. ** Create tracking BZ for packages with unclear transition path ** Submit BZ for packages that cannot migrate in time. * Other developers: ** All packages (during the package review) should use the SPDX expression. - this is redundant as this is already approved since Phase 1, but should be reminded. ** Migrate the existing License tag from a short name to an SPDX expression. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: Licensing page will need to be altered. But almost all the work has been done in Phase 1. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora. During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula. == How To Test == See [[Changes/SPDX_Licenses_Phase_1#How_To_Test|How to test section of Phase 1]] == User Experience == Users should be able to use standard software tools that audit licenses. E.g. for Software Bills of Materials. == Dependencies == No other dependencies. == Contingency Plan == * Contingency mechanism: There will be no way back. We either rollback in Phase 1. Once we will start Phase 2 we will be beyond of point with no return. * Contingency deadline: Beta freeze. But it is expected that not all packages will be converted by that time and the change will continue in the next release. * Blocks release? No. This change has no impact on runtime of any package == Documentation == [https://docs.fedoraproject.org/en-US/legal/allowed-licenses/|Allowed Licenses] [https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_process_used Update existing packages] == Release Notes == In Fedora 39, RPM packages use SPDX identifiers as a standard. Almost all packages have been migrated to SPDX identifiers. The remaining packages are tracked in this tracking Bugzilla issue. LINK TO BE ADDED -- 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 Beta is GO
The Fedora Linux 38 Beta RC1,3 compose[1] is GO and will be shipped live on Tuesday, 14 March. The F38 Final freeze begins Tuesday 4 April. For more information please check the Go/No-Go meeting minutes[2] or log[3]. [1] https://download.fedoraproject.org/pub/alt/stage/38_Beta-1.3/ [2] https://meetbot.fedoraproject.org/fedora-meeting/2023-03-09/f38-beta-go_no_go-meeting.2023-03-09-17.00.html [3] https://meetbot.fedoraproject.org/fedora-meeting/2023-03-09/f38-beta-go_no_go-meeting.2023-03-09-17.00.log.html -- 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
F39 proposal: FontAwesome6 (Self-Contained Change proposal)
-guidelines/FontsPolicy/#_dependencies_to_font_packages_in_other_packages the font guidelines]. *** coq *** libgpuarray *** libsemigroups *** python-BTrees *** python-primecountpy *** python-sphinx_rtd_theme * Other developers: Maintainers of the packages listed above will need to review the proposed changes and merge them if they are acceptable. Afterwards, I will build all packages in a side tag and merge to Rawhide once all builds are complete. * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Initiatives: == Upgrade/compatibility impact == Users should not notice this change, except for having fewer bundled copies of the FontAwesome icons on disk. == How To Test == Install packages from the [https://copr.fedorainfracloud.org/coprs/jjames/FontAwesome6 the FontAwesome6 COPR]. Launch each one and verify that it displays the expected icons. == User Experience == Users should not see any changes, except for a disk space savings if they have more than one affected package installed. == Dependencies == All dependencies are listed above and will be updated together. If maintainers do not respond to pull requests in a timely manner, then provenpackager privileges can be used to merge the pull requests and do the builds together. The definition of "timely manner" is up for debate. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), == Documentation == N/A (not a System Wide Change) == Release Notes == The fontawesome-fonts package has been upgraded to version 6.3.0, and a compatibility fontawesome4-fonts package has been introduced for applications that still require FontAwesome 4.7.0. For packages that can use the FontAwesome 6.x icons, the changes described in [https://fontawesome.com/docs/changelog/ the FontAwesome changelog] are now available. Packages that use the FontAwesome 4.x icons do not have any user-visible changes. -- 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
Upcoming summer time changes
As a reminder to the community, we've reached the point in the year where jurisdictions around the world begin or end summer time. Be sure to check your recurring meetings on Fedocal[1] to make sure you know when you're meeting. Some meetings are set to a fixed time UTC and others are set to a particular time zone. A global list of time changes is available by country[2] and by date[3], but here are a few highlights: 13 Mar — summer time begins in Canada, parts of Mexico, and the US 27 Mar — summer time begins in the EU and UK 3 Apr — summer time begins in most of Mexico, summer time ends in Australia [1] https://calendar.fedoraproject.org/ [2] https://www.timeanddate.com/time/dst/2023.html [3] https://www.timeanddate.com/time/dst/2023a.html -- 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
Fedora Linux 38 Beta Go/No-Go meeting next week
The Fedora Linux 38 Beta Go/No-Go[1] meeting is scheduled for Thursday 9 March at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F38 Beta for the 14 March early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10456/ [2] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- 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
Changes to Bugzilla API key requirements
If you did not see the bugzilla-announce-list post[1], there are new requirements for API keys in Red Hat Bugzilla: Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You must replace your API keys at least once a year. Additionally, any API key that is not used for 30 days will be suspended but can be re-enabled on the account's preferences tab. All existing API keys have had their creation date set to 2023-02-19. For more details, see the announcement[1]. [1] https://listman.redhat.com/archives/bugzilla-announce-list/2023-February/000101.html -- 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 Change complete (100% complete) deadline today
As of today, F38 Changes should be 100% complete. Change owners can indicate this by setting the Bugzilla tracker to the ON_QA state. F38 enters beta freeze today. Any updates that need to land in the beta release will require an approved freeze exception or beta blocker. The current beta target is the early target date of 14 March. More schedule details are available at https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html -- 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
F39 proposal: MinGW toolchain update (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/F39MingwEnvToolchainUpdate 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 MinGW toolchain to the latest upstream stable releases. == Owner == * Name: [[User:smani|Sandro Mani]] * Email: manisan...@gmail.com == Detailed Description == The following packages will be updated * mingw-gcc to version 13.x * mingw-binutils to version 2.40 == Benefit to Fedora == Ship the latest available GNU toolchain for MinGW. == Scope == * Proposal owners: The above mentioned packages will be updated. Build failures following the mass rebuild will be inspected. * Other developers: Help with build failures may be requested. * Release engineering: Impact check [https://pagure.io/releng/issue/11299] * Release engineering: Mass rebuild requested * Policies and guidelines: No policies need to be changed == Upgrade/compatibility impact == No impact == How To Test == Update the system once the updated packages land, look out for new build failures etc. == User Experience == The features of the newest GNU Toolchain will be available to MinGW users. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert to older versions of environment / toolchain, mass rebuild mingw packages again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No == Release Notes == Fedora 39 comes with the mingw-gcc-13 and mingw-binutils-2.40. -- 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
Inactive packager check for F38
In accordance with FESCo's Inactive Packager Policy[1], packagers that have been identified as inactive have a ticket in the find-inactive-packagers repo[2]. One week after the final release, packagers who remain inactive will be removed from the packager group. (Note that pagure.io is one of the systems checked for activity, so commenting on your ticket that you're still around will prevent you from showing up in the second round.) If you have suggestions for improvement, look for the open feature issues[3] and file an issue in the find-inactive-packagers repo[4] if it's not there already. For the curious, here are the stats from today's run: ### Found 2129 users in the packager group. ### ### Found 914 users with no activity in pagure/src.fp.org over the last year. ### ### Found 845 users which also show no activity in Bodhi over the last year. ### ### Found 812 users which show also no activity in mailing lists over the last year. ### ### Found 812 users which also show no activity in Bugzilla over the last year. ### As we approach [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ [2] https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager=Open [3] https://pagure.io/find-inactive-packagers/issues?tags=feature [4] https://pagure.io/find-inactive-packagers/new_issue -- 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
F39 proposal: Modernize Thread Building Blocks for Fedora 39 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/F39ModernizeTBB 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 == Fedora is currently shipping version 2020.3 (released July 10, 2020) of the Thread Building Blocks library. The current upstream version is 2021.8 (released December 22, 2022). The Fedora community has expressed [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 interest] in moving the TBB package to track a more modern version of the upstream. == Owner == * Name: [[User:trodgers| Thomas Rodgers]] * Email: trodg...@redhat.com == Detailed Description == Fedora has shipped with version 2020.3 of the Thread Building Blocks library since Fedora 33. The upstream project made a decision to break backward compatibility after that version was released. As packages move to match the upstream's changes it becomes more difficult to defer updating the Fedora packaging for TBB. The situation is further complicated as there are currently a majority of TBB dependent packages which have not been updated to track a new upstream release, as detailed in this [https://bugzilla.redhat.com/show_bug.cgi?id=2036372#c1 analysis] on the tracking issue. This proposal aims to provide a way to modernize the TBB packge version for Fedora while providing stability for those packages which continue to depend on the older TBB library version. It will be possible to install both devel and runtime versions of both TBB packages, however the devel compat package for version 2020.3 will require clients to point to a new include path where the legacy headers will be found. == Feedback == == Benefit to Fedora == Fedora 39 will include a current version of Thread Building Blocks (version 2021.8) while continuing to support clients dependent on an older version of TBB (version 2020.3). Fedora will stay relevant as far as Thread Building Blocks clients are concerned. == Scope == * Proposal owners: ** A compat package based on the current 2020.3 version of the existing TBB package will be created. ** Evaluate TBB dependent packages to identify those which need to move to the compat version of the TBB package. An initial analysis suggests the majority of current TBB clients will need to move to the compat package. ** Post a request for rebuilds to fedora-devel ** Create patches for those packages affected by this change to adjust their includes to point the compat package's headers as necessary, work with affected package owners to update package specs to account for the change. ** When most packages are done, re-tag all the packages in rawhide. ** Watch fedora-devel and assist in rebuilding broken TBB clients. * Other developers: ** Those who depend on Thread Building Blocks will have to rebuild their packages. Feature owners will alleviate some of this work as indicated above, and will assist those whose packages fail to build in debugging them. * Release engineering: TODO * Policies and guidelines: N/A (not needed for this Change) ** Apart from scope, this is business as usual, so no new policies, no new guidelines. == Upgrade/compatibility impact == * No manual configuration or data migration needed. * Some impact on other packages needing code changes to rebuild. == How To Test == * No special hardware is needed. * Parallel install of the 2020.3 TBB compat packages and the updated TBB packages and checking that it does not break other packages. == User Experience == * Expected to remain largely the same. * Developers building third-party software on Fedora may need to rebuild against the new TBB packages, and may need to adjust their code to either remain on the compat TBB version or move to the new version supplied by the updated TBB package. == Dependencies == Packages that must be rebuilt: & dnf repoquery -s --releasever=rawhide --whatrequires libtbb\* --enablerepo=fedora | sort -u The tracking [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 issue's] analysis suggests that only the following packages will be able to move to a newer TBB - * fawkes * gazebo * opencascade * pmemkv * root While the remaining clients of TBB will need to have their spec's include paths adjusted to use the 2020.3 compat package. == Contingency Plan == * Contingency mechanism: Worst case scenario is to abandon the update and simply ship F39 with the existing TBB package, which is already in rawhide. == Documentation == * Notes on the scope of change, motivation, and likely impacts are in the comments on the tracking [https://bugzilla.redhat.com/show_bug.cgi?id=2036372 issue]. * https://github.com/oneapi-src/oneTBB/releases/tag/v2021.7.0 (Released 2nd October 2022) * https://github.com/oneapi-src/oneTBB/releases/tag/v2020.3 (Released 10th July 2020) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Man
F38 Change complete (100% complete) deadline in one week
As a reminder, F38 Changes should be 100% complete by Tuesday 21 February. Change owners can indicate this by setting the Bugzilla tracker to the ON_QA state. F38 will enter beta freeze on that date. More schedule details are available at https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html -- 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
Inactive provenpackagers to be removed from group
In accordance with FESCo policy[1], the following provenpackagers will be submitted for removal in two weeks based on a lack of Koji builds submitted in the last six months. If you received this directly, you can reply off-list to indicate you should still be in the provenpackager group. Note that removal from this group is not a "punishment" or a lack of appreciation for the work you have done. The intent of the process is to ensure contributors with distro-wide package privileges are still active and responsive. This process is done regularly at the branch point in each release. [1] https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status Checked 134 provenpackagers The following 15 provenpackagers have not submitted a Koji build since at least 2022-08-03 00:00:00: abompard mohanboddu jamatos jwboyer till laxathom torsava dwmw2 oget otaylor jwilson oliver wtogami steve bruno -- 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
F39 proposal: Mass Retire Golang Leaves (Self-Contained Change proposal)
ssue/11253 #11253] ** After we preform the mass retirement, releng will allow any Go SIG member to unretire a ''leaf'' within eight weeks even if they're not the main admin. ** The change owners will mass retire the packages themselves using go-sig/provenpackager membership. ** Ensure that the packages are properly blocked/retired in Koji and PDC. == Upgrade/compatibility impact == There should be none. These library packages are not meant for end users. We will not Obsolete these packages, so they won't be removed from existing systems. == Contingency Plan == The change can be deferred if the prep work isn't completed in time. The change owners are taking multiple measures to avoid retiring packages that are not actually ''leaves'' (i.e. false positives). In the event of unforeseen issues, some or all of the packages can be unretired and rebuilt. Retagging builds from F38 is also possible, as Golang library packages only contain source code and are architecture independent. == Documentation == The current draft of the package leaves script [https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/go-sig/go_leaves.py is available]. == Release Notes == Remove unused Golang libraries from the repositories. These packages are not meant for end user consumption to begin with. We will not Obsolete these packages, so they won't be removed from existing systems. -- 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 Change complete (testable) deadline in one week
As a reminder, F38 Changes should be testably complete by Tuesday 7 February. Change owners can indicate this by setting the Bugzilla tracker to the MODIFIED state. (If it is 100% complete, you can set the tracker it ON_QA). In addition, F38 branches from Rawhide on 7 February. At that point, Rawhide begins development of F39. More schedule details are available at https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html -- 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
Late F38 proposal: Packaging 22+ (Self-Contained Change proposal)
cided to write this Change proposal for better transparency. We believe there is enough time to complete this Change in time for the Completion deadline. We are prepared to postpone this Change to Fedora 39 if FESCo decides so. == Benefit to Fedora == Packaging 22+ contains a handwritten parser for parsing requirements and markers. Thanks to this, packaging has dropped a runtime dependency on pyparsing and from now on is not depending on any package on runtime. This will simplify bootstrapping of the next Python. == Scope == * Proposal owners: update python-packaging to 23.x.x, provide help * Other developers: report problems to the upstream and backport patch to the affected packages. The impact can be tested using [https://copr.fedorainfracloud.org/coprs/thrnciar/python-packaging/packages/ COPR repository] where Packaging 23+ has been built. * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == == How To Test == # Find the package you want to fix in this [https://copr.fedorainfracloud.org/coprs/thrnciar/python-packaging/packages/ COPR repository] and check the build logs to determine the failure cause. # Patch package so Provides() provides correct version. # When patching the package, you can test it using the same copr repository where the latest version of python-packaging has been built. == User Experience == Regular distro users shouldn't notice any change in python-packaging behaviour, except for packages that use `LegacyVersion` or `LegacySpecifier`. Such packages will fail with `packaging.version.InvalidVersion: Invalid version: 'This is a completely random string'` and should be fixed by their maintainers. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) revert the update and bump epoch * Contingency deadline: beta freeze * Blocks release? No == Documentation == https://github.com/pypa/packaging/blob/main/CHANGELOG.rst == Release Notes == -- 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: IoT Simplified Installer (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/IoTSimplifiedInstaller 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 == Offer Fedora IoT users a new method to create and deploy customized Fedora IoT disk images using a new installer called Simplified Installer. == Owner == * Name: [[User:runcom| Antonio Murdaca]], [[User:pwhalen| Paul Whalen]] * Email: amurd...@redhat.com, pwha...@fedoraproject.org == Detailed Description == The Fedora IoT Simplified Installer will use coreos-installer to write an OStree raw image straight to a disk specified in a kernel argument, without the need for a kickstart or user interaction. This type of installation is ideal for devices connected at the edge where connectivity can be slow or intermittent. It offers the ability to configure the system via osbuild itself, FDO and Ignition. == Feedback == == Benefit to Fedora == The addition of the Fedora IoT Simplified Installer will benefit IoT users by allowing them to create customized disk images for use on their edge devices. This feature is already available downstream, adding it to Fedora will once again bring Fedora back to the true upstream of RHEL for edge and allows testing and adoption of new functionality like FIDO Device Onboarding. == Scope == * Proposal owners: ** Test building Fedora IoT Simplified Installer with `osbuild-composer` ** Update Fedora IoT documentation with usage instructions. * Other developers: * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == * Not applicable to this change. == How To Test == Testable by installing `osbuild-composer` in Fedora 38 and using the command line tool or the Cockpit web interface to create a Fedora IoT Simplified Installer iso to deploy a UEFI enabled edge device. == User Experience == This change will greatly enhance the Fedora IoT user experience by allowing users to utilize `osbuild-composer` and blueprints to create customized Fedora IoT deployments and leverage new features like FIDO Device Onboarding for secure zero touch device onboarding of edge devices as well as Ignition to configure the device once it starts. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency deadline: Beta * Blocks release? No. * Blocks product? No. == Documentation == * Usage documentation to be written and included in the [https://docs.fedoraproject.org/en-US/iot/user-guide/ Fedora IoT user guide]. == Release Notes == -- 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
Upcoming F38 Changes deadlines
As a reminder, the deadline for submitting Self-Contained F38 Change proposals is Tuesday, 17 January 2023. The F38 mass rebuild is scheduled to begin on Wednesday, 18 January. Any approved Changes that require a mass rebuild must be ready by then. If you will not be ready, please notify Release Engineering as soon as possible. More schedule milestones are available at https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html -- 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: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
ed [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-problems/#_cups_generic_issue here]), :* in case of problem with scanning output do report the issue to `sane-airscan` bugzilla component together with additional info acquired by following steps from this [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-problems/#_debugging_sane_airscan link], * once you disable the device or backend for scanning, check whether one scanner's disappeared from scanner application's dialog (`simple-scan`, `xsane`, `scanimage`) In case user chooses to have classic driver support instead of driverless because driverless support does not work or it misses some options which user requires, it would be great if the user reported such case by filing an issue to `golang-github-openprinting-ipp-usb` bugzilla component, explaining which required options are missing or whether driverless does not print/scan at all and it will reviewed by the component's maintainer. If the model has the driverless support broken in general, the model can be disabled in `ipp-usb` on system level by quirk, which is located in `/usr/share/ipp-usb/quirks`. Once the quirk is set and `ipp-usb` restarted, previously installed printers and scanners will work as before - the printing/scanning/fax will end with error otherwise. == User Experience == A new printer and a new scanner will appear in applications and settings for IPP-over-USB devices by default. Previously installed printer and discovered scanner for the device will stop working and manual intervention is required to remove the broken instances, or to create a quirk for `ipp-usb`. == Dependencies == == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * Printing and scanning [https://docs.fedoraproject.org/en-US/quick-docs/cups-terminology/ terminology] * [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-problems/ Printing] debugging * [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-problems/ Scanning] debugging * [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/ Tips and tricks] * [https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/ Known issues] == Release Notes == Driverless USB printing/scanning/fax support is present by default with printing and scanning packages, providing the support for devices capable of using IPP-over-USB. The manual intervention is required after upgrade, which is described [https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency#Upgrade/compatibility_impact here]. -- 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: Unfiltered Flathub (System-Wide Change proposal)
le software from Flathub, turn on third-party software in GNOME Initial Setup or GNOME Software. -- 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: Noto CJK Variable Fonts (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Noto_CJK_Variable_Fonts
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 ==
Switch the default Noto CJK fonts for Chinese, Japanese and Korean
from static to variable fonts.
== Owner ==
* Name: [[User:pwu| Peng Wu]]
* Email: p...@redhat.com
== Detailed Description ==
In order to reduce the font size in Noto CJK fonts, we plan to switch
to use the variable fonts by default.
# Split the google-noto-cjk-fonts package into
google-noto-sans-cjk-fonts and google-noto-serif-cjk-fonts, and
provide the variable fonts in google-noto-sans-cjk-vf-fonts and
google-noto-serif-cjk-vf-fonts.
# Drop several sub packages which are not installed by default from
the google-noto-cjk-fonts package.
## Like google-noto-sans-cjk-*-fonts, google-noto-sans-*-fonts,
google-noto-sans-mono-cjk-*-fonts, google-noto-serif-cjk-*-fonts and
google-noto-serif-*-fonts
# Install the Noto CJK Variable Fonts by default.
Fedora Copr for testing: https://copr.fedorainfracloud.org/coprs/pwu/noto-cjk/
== Feedback ==
== Benefit to Fedora ==
The variable fonts will reduce the disk space usage and live image
size compared to the static fonts.
{| class="wikitable"
|+ RPM Size
|-
! Size (bytes) !! Noto Sans CJK !! Noto Serif CJK
|-
| Static Fonts || 130674365 || 181621033
|-
| Variable Fonts || 64613100 || 56924710
|}
== Scope ==
* Proposal owners:
** Package four font packages for Noto CJK fonts
** Retire google-noto-cjk-fonts in Fedora rawhide
** Switch to install variable fonts by default in fedora-comps and langpacks
** Submit pull request to lorax templates to use
google-noto-sans-cjk-fonts in the boot.iso
* Other developers:
* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
When upgrade, the variable fonts will be installed by default.
== How To Test ==
* Please upgrade to Fedora 38 or rawhide to get the latest fonts
* Install the variable fonts: google-noto-sans-cjk-vf-fonts and
google-noto-serif-cjk-vf-fonts
** Check the google-noto-sans-cjk-ttc-fonts and
google-noto-serif-cjk-ttc-fonts packages are replaced
* Then use CJK locales to check if the new fonts have any problem
== User Experience ==
This new variable fonts will reduce the disk space usage and live image size.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Use the static fonts by default -
google-noto-sans-cjk-fonts and google-noto-serif-cjk-fonts
* Contingency deadline: N/A
* Blocks release? N/A
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
This new variable fonts will reduce the disk space usage and live image size.
--
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: TeXLive2022 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/TeXLive2022 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 TeXLive engines and components in Fedora to the 2022 version. This will improve TeX document processing, conversion, and internationalization, which is used by some Fedora packages (and users). == Owner == * Name: [[User:spot| Tom Callaway]] * Email: spo...@gmail.com == Detailed Description == The goal is to update Fedora to the latest available version of TeXLive (2022), including its large number of associated components. This will resolve outstanding bugs in the existing TeXLive (2021) packages, add new features, improve performance, and expand internationalization support. == Benefit to Fedora == Updating to TeXLive 2022 brings the latest versions of the TeX engines and components into Fedora, which improves document rendering and conversion. A number of Fedora packages include TeX support, which depend on the TeXLive utilities. In each TeXLive release, a large (hundreds) number of TeX components are updated, a significant (~100) number of new TeX components are added, and core functionality is enhanced and optimized. Documents should render properly and export into various formats without issues. == Scope == * Proposal owners: The necessary changes are contained to the texlive and texlive-base packages. These changes have already landed in rawhide. * Other developers No changes should be necessary for other packagers/developers. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: It does not align with any current Objectives. == Upgrade/compatibility impact == Users will need to delete old TexLive 2021 cache in order to properly use TeXLive 2022 upon an upgrade. To do this, a user simply (and carefully) needs to run: rm -rf ~/.texlive2021 A new ~/.texlive2022 directory will be generated and used when the user invokes TeXLive related functionality, but TeXLive will attempt to use the older cache directory and it will not work properly. == How To Test == Packagers who have packages that use TeX to generate documentation should simply attempt to rebuild their package in rawhide with the TeXLive 2022 packages. If it succeeds and the documents generated are correct, nothing further is necessary. If it fails or the documents generated are corrupted/damaged, please open a bug against the texlive component. == User Experience == The way that the user interacts with TeX/TeXLive does not change in this release. A very small number of components (~10) in TeXLive have been obsoleted and removed, but they have either been silently replaced by other functionality or they were outdated documentation. == Dependencies == While other packages in Fedora do depend on texlive component packages, this is almost always for build-time generation of documentation, and not in a traditional "linking to library" approach. Packages with tex() or texlive dependencies should not need to make any changes to use TeXLive 2022. == Contingency Plan == * Contingency mechanism: Roll back to latest texlive/texlive-base 2021 packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A == Documentation == https://tug.org/texlive/bugs.html == Release Notes == Fedora 38 has updated its TeXLive support to 2022. Users who upgrade from older versions of Fedora and who have used TeXLive previously may need to delete the ~/.texlive2021 cache directory in order to have a working TeXLive environment. A new ~/.texlive2022 cache directory will be generated on first use of TeXLive 2022, but TeX will attempt to use older cache directories if they exist. -- 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: 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)
and develop using the new features offered by the updated components. Developers will need to enable specific compiler features as required e.g. '-mcpu=neoverse-v2'. == Dependencies == All packages do not need to be rebuilt due to backwards compatibility. However, it is advantageous if a mass rebuild is performed during the Fedora 38 cycle. The mass rebuild would ensure all packages can be built with the newer compiler and core runtime. == Contingency Plan == * Contingency mechanism glibc: If glibc 2.37 proves too disruptive to compiling the distribution we could revert to 2.36, but given that Rawhide has started tracking glibc 2.37, no show-stopper problems are expected. At this point we can still revert to upstream version 2.36 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency mechanism binutils: If binutils 2.39 proves too distruptive to assembling and linking the distribution we could revert to 2.38, but given that Rawhide is using 2.39, no show-stopper problems are expected. At this point we can still revert if insurmountable problems appear, but to do so may require a mass rebuild if the defects involve generated binaries. * Contingency mechanism for gcc: If gcc 13 proves too disruptive to compiling the distribution we could revert to gcc 12. * Contingency mechanism for gdb: The gdb 12.1 release is already in all the Fedora releases and it would not be reverted. If any gcc, glibc or binutils changes cause gdb to fail then that would need to be reviewed on a case-by-case basis. * Contingency deadline: Fedora mass rebuild on 2023-01-18. * Blocks release? ** Yes, upgrading to gcc 13.0 does block the release. ** Yes, upgrading to binutils 2.39 does block the release. ** Yes, upgrading to glibc 2.37 does block the release. ** No, upgrading to gdb 12.1 does block the release (already released). == Documentation == The gcc manual contains the documentation for the release and doesn't need any more additional work. The binutils manual contains the documentation for the release and doesn't need any more additional work. The glibc manual contains the documentation for the release and doesn't need any more additional work. The gdb manual contains the documentation for the release and doesn't need any more additional work. == Release Notes == See https://gcc.gnu.org/gcc-13/changes.html for the GNU Compiler Collection version 13 release notes. The GNU C Library version 2.37 will be released at the beginning of February 2023. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD The GNU Binary Utilities version 2.39 was released August 2022. The current release notes will be sent to the developer mailing list: https://sourceware.org/pipermail/binutils/2022-August/122246.html. -- 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: 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)
ady used by a decent number of packages, so any issues are already being seen and need to be fixed anyway. == How To Test == * Convert an existing package: `rpmautospec convert`. Ideally this step is done right before a version bump so that the release numbers restart at `-1`. * Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify correctness of version-release (`rpm -qpi`) and the changelog (`rpm -qp --changelog`). * Do builds in koji. Verify correctness of version-release and the changelog. * For new packages, use `%autorelease`+`%autochangelog`. Repeat all the tests listed above. * Assume you are a newbie packager. Read the packaging docs and check that the workflow is clear and the intructions are sufficient to use rpmautospec tooling correctly. == User Experience == No changes visible to end users. == Dependencies == None. == Contingency Plan == If it turns out that the rpmautospec workflows have unknown problems, we can revert changes to documentation. * Contingency mechanism: Revert changes to documentation by reverting the appropriate commits. This can be done easily by FPC. * Contingency deadline: Any time. * Blocks release? No. == Documentation == This page and any changes to Packaging Guidelines and other documents. == Release Notes == Not needed. -- 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
F37 election results
Greetings, all! The elections for the Fedora Linux 37 cycle have completed. ## Fedora Council Aleksandra Fedorova is elected to the Fedora Council ## Fedora Engineering Steering Committee (FESCo) The following candidates are elected to FESCo: * Kevin Fenzi * Miro Hrončok * Zbigniew Jędrzejewski-Szmek * David Cantrell * Fabio Valentini ## Fedora Mindshare Committee Fernando F. Mancera is elected to the Fedora Mindshare Committee. Congratulations to all those elected and thank you to the candidates and voters. For more details, see the Community Blog post: https://communityblog.fedoraproject.org/fedora-linux-37-election-results/ -- 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: Shorter Shutdown Timer (System-Wide Change proposal)
for users when system shutdown does need to be delayed. == Dependencies == No specific changes are required in other packages. However, service developers may want to take this opportunity to examine the shutdown behavior of their components. == Contingency Plan == * Contingency mechanism: the change owners will revert the change in systemd. * Contingency deadline: if we back out the change it would be best to do it before beta freeze, but this can happen at any point. * Blocks release? No. == Documentation == Documentation isn't required for this minor configuration change. Services that legitimately need to prevent system shutdown should use [https://www.freedesktop.org/wiki/Software/systemd/inhibit/ systemd inhibit]. Desktop applications can use the [https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Inhibit XDG inhibit portal]. == Release Notes == -- 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: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients 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 == X server implementations (e.g. Xorg and Xwayland) will (by default) no longer allow clients with different endianess to connect. == Owner == * Name: [[User:whot| Peter Hutterer]] * Email: peter.hutte...@redhat.com == Detailed Description == X server implementations (e.g. Xorg and Xwayland) allow clients with an endianess different to that of the server to connect. Protocol messages to and from these clients are byte-swapped by the X server. However, the code in the X server that does this is virtually untested, providing a large attack surface for malicious clients. One needs to only look at e.g. [https://www.x.org/wiki/Development/Security/Advisory-2014-12-09 this X.Org security advisory] and count the `SProc` mentions for an indication on how bad this is. A simple solution to remove this attack surface is to prohibit clients with a different endianess. These clients will simply fail, in a matter similar to failing to authenticate against an X server. The use-case for clients with different endianess is ''very'' niche. It was common in the 1980s when X was originally developed but at this point a vanishingly small number of users run clients and X servers on different machines, let alone on different machines with different endianess. I'd be surprised if Fedora had ''any'' users requiring this feature. Note: * this only affects use-cases where the server runs on a little endian host and the client on a Big Endian host (or vice versa). * this is a change in '''the default behavior''' only and can be changed via configuration options (for `Xorg`) and/or commandline arguments (all X servers). * this is a change in the upstream default behavior that Fedora will follow along with. This Change is primarily to increase the exposure. == Benefit to Fedora == This change removes a large potential attack surface that can be used by malicious clients to expose memory locations, crash the X server and/or do other entertaining things malicious programs like to do. == Scope == * Proposal owners: # Merge [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 upstream PR] # Backport patch to Fedora's `xorg-x11-server` and `xorg-x11-server-Xwayland` packages * Other developers: This is labelled as system-wide change simply because it's a change in Xorg/Xwayland. It is otherwise self-contained in that no other packages need updating, '''unless''' they want to opt-out of this default. Which is better left to system-specific configuration anyway. * Release engineering: This feature does not require coordination with release engineering * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == For the ''extremely niche'' use-case of users that run X clients on a remote machine with a different endianess, these clients will no longer be able to connect '''by default'''. For Xorg, the following `xorg.conf.d` snippet will re-enable the old behavior: Section "ServerFlags" Option "AllowSwappedClients" "on" EndSection Wayland users (and thus Xwayland) need to employ compositor-specific configuration to pass the `+byteswappedclients` flag to Xwayland. At the time of writing, GNOME does not yet provide such a configuration. == How To Test == To test the impact of this change, you need: * an X server running on a little endian architecture and an X client running on a Big Endian architecture (or the other way around) * set up the X server to accept remote connections, either via TCP or through SSH * run the X client which will fail to connect Alternatively, a test client is available in [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 the upstream PR]. This test client pretends to be BigEndian and will fail to connect when run against a little endian X server. == User Experience == For virtually all users, there is no change in behavior. Users with X server and client on two different machines must add the `xorg.conf.d` snippet shown above on affected systems. == Dependencies == No other RPMs depend on this change. == Contingency Plan == This change depends on whether upstream merges this new default behavior. If upstream does not merged the feature in time, this Change will be postponed until the next Fedora version to avoid potential incompatibilities between configurations or commandline options. * Contingency mechanism: keep current behavior, try again with next Fedora version * Contingency deadline: beta freeze * Blocks release? No == Documentation == == Release Notes == -- Be
F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)
/]
** installer(s): add support for discoverable partitions.
*** [https://bugzilla.redhat.com/show_bug.cgi?id=1075288 Bug#1075288]
* 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:
== Upgrade/compatibility impact ==
None (using unified kernel is opt-in for Phase 1).
== How To Test ==
Try on a existing (uefi) system:
* make sure you are running fedora 37 or rawhide.
* make sure your root filesystem has type "Linux root (x86-64)" (use
`fdisk -l` to check).
** should that not be the case use the fdisk tag command ('t') to
change the partition type.
* when using btrfs: make sure the 'root' subvolume is set as default volume.
* `dnf copr enable kraxel/unified.kernel`
* `dnf update "grub2*"`
* `dnf install kernel-unified-virt`
* `reboot`
You should find two entries in the grub2 boot menu, one for classing
kernel with separate initrd and one for the unified kernel image.
Both should boot fine.
The https://gitlab.com/kraxel/fedora-uki project has kickstart files
and helper scripts for generating virtual machine images.
* image using grub2-efi:
https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-grub2.ks
* image using systemd-boot:
https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-sdboot.ks
Prebuilt virtual machine images are available from
https://www.kraxel.org/fedora-uki/.
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism:
** Probably none (unified kernel images are opt-in for Phase 1).
** In case we tried switching the cloud images to unified kernels:
revert the kickstart config changes.
* Contingency deadline:
* Blocks release? No
== Documentation ==
== Release Notes ==
--
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: Xfce-4.18 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/xfce-4.18
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 ==
Xfce 4.18 is a stable release with proven components, provide features
to both new and power users alike. This change proposal is submitted
to sync fedora packages with the latest upstream release.
== Owners ==
* Name: [[User:nonamedotc| Mukundan Ragavan]], [[User:kevin| Kevin Fenzi]]
* Email: nonamed...@fedoraproject.org, ke...@scrye.com
== Current status ==
[[Category:ChangeReadyForWrangler]]
[[Category:SelfContainedChange]]
* Targeted release: [[Releases/38 | Fedora 38 ]]
* Last updated:
{{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* FESCo issue:
* Tracker bug:
* Release notes tracker:
== Detailed Description ==
This change migrates Xfce desktop environment (DE) to the latest
version provided by upstream developers. This release brings, amongst
others, the following features
* client-side decorations
* fractional scaling
* new status tray plugins
* Streamlined application chooser (i.e. merged "mime type editor" and
"default applications")
Full feature list can be viewed at
[https://mail.xfce.org/pipermail/xfce-announce/2022-December/001208.html]
and [https://www.xfce.org/about/tour418]
== Benefit to Fedora ==
Updating Xfce to 4.18 will provide Fedora Xfce users stable but latest
versions of upstream software. We will also be able to provide timely
bug fixes.
== Scope ==
* Proposal owners:
** Update core xfce packages to 4.18
** Rebuild plugins once core packages are build
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues] (a check of
an impact with Release Engineering is needed) -->
** List of deliverables: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
* A fresh install should have fully functional Xfce DE
* Upgrade from Fedora 37 or older should be mostly seamless
No special configuration or hardware needed.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
* Blocks product? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora 38 ships with Xfce 4.18.
--
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: Pyramid 2.0 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Pyramid2.0 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 Pyramid (package `python-pyramid` within Fedora) to latest major version. == Owner == * Name: [[User:mattia| Mattia Verga]] * Email: mattia.ve...@fedoraproject.org == Detailed Description == Pyramid 2.0 has been available since March 2021. We would like to update Fedora package (`python-pyramid`) to this new major version (we're now still shipping 1.10.5). == Feedback == == Benefit to Fedora == Provide the latest available version of Pyramid framework instead of the outdated one we're shipping. == Scope == * Proposal owners: Pyramid will be rebuilt to 2.0 in a side-tag together with dependent packages. Affected packages are owned by nirik and abompard and usually co-maintained by infra-sig. I will contact them and offer me to rebuild/upgrade affected packages. Note that rebuilding dependencies is not strictly necessary, but I'll do to ensure compatibility with Pyramid 2.0. About bodhi-server, we've been always running tests against pypi packages, so I do not expect anything to be broken by the update. * Other developers: * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == == How To Test == A COPR repository has been set up to rebuild all dependencies: https://copr.fedorainfracloud.org/coprs/mattia/Pyramid2/ == User Experience == This will not impact end user experience. == Dependencies == * bodhi-server * python-cornice * python-pyramid-fas-openid * python-pyramid-mako <-- needs to be updated to the latest git snapshot * python-pyramid-tm * python-pyramid_sawing == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == -- 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
Re: Fedora elections voting now open
Remember that voting in the Fedora Linux 37 elections is open through 23:59 UTC on Thursday 22 December. Go to the Elections app[1] to cast your vote. Voting closes at 23:59 UTC on Thursday 22 December. Don't forget to claim your "I Voted" badge when you cast your ballot. Links to candidate interviews are in the Elections app and on the Community Blog[2]. [1] https://elections.fedoraproject.org/ [2] https://communityblog.fedoraproject.org/f37-elections-voting-now-open/ -- 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: Use mdadm for BIOS RAID Support in Anaconda (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/UseMdadmForBIOSRAIDInAnaconda 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 == Use mdadm instead of dmraid to support BIOS RAID (Firmware RAID or Fake RAID) during the Fedora installation process. == Owner == * Name: [[User:vtrefny| Vojtech Trefny]] (Blivet) * Email: vtrefny AT redhat.com * Name: [[User:vponcova|Vendula Poncova]] (Anaconda) * Email: vponcova AT redhat.com == Detailed Description == [[Anaconda]] (or to be more precise [[Blivet]], the storage library Anaconda uses) is currently using dmraid to support the BIOS RAID devices (sometimes also called Firmware or BIOS RAID) during installation. We plan to replace dmraid by mdadm, which we are currently using for software RAID management. The main reason is that dmraid is no longer actively maintained. mdadm supports the two major BIOS RAID technologies: Common RAID Disk Data Format (DDF) [https://www.snia.org/tech_activities/standards/curr_standards/ddf standard by SNIA] and [https://www.intel.com/content/www/us/en/support/products/122484/memory-and-storage/datacenter-storage-solutions/intel-virtual-raid-on-cpu-intel-vroc.html Intel Matrix Storage Manager] format. mdadm is missing support for some older BIOS RAID formats that existed before DDF and are still supported by dmraid so by implementing this change, we will remove support for some BIOS RAID formats from the installer. == Feedback == We tried to [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/A6G5HTBXXIDQUMYBCILU264ZLEWF75ND/ get feedback from the community] to find out how many users use BIOS RAID and would be affected by this change (especially by removing support for the older formats). The only response was from the Fedora QA which has an Intel Matrix machine for testing which should be supported by mdadm. == Benefit to Fedora == Replacing a tool/library that is no longer being actively developed and maintained. Because we are replacing it with a tool that is currently used for software RAID management in the installer, this also means removing one dependency from the installer environment and remove the dmraid startup service from the installed system. == Scope == * Proposal owners: Changes to Blivet (replacing dmraid with mdadm for the specified BIOS RAID formats) and Anaconda (removing the `inst.nodmraid` flag) * Other developers: * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == This change will affect only new installations (the change only changes behaviour of the installer). == How To Test == A hardware with BIOS RAID support (DDF or IMSM) is required. (Creating a "fake" BIOS RAID with mdadm might be possible for testing, we'll add steps for testing without the hardware later (if possible).) Follow the test case for installing on BIOS/Firmware RAID: [[QA:Testcase_install_to_firmware_RAID]]. == User Experience == Users with supported BIOS RAIDs shouldn't notice a change, the installation should work the same for them. Users with older unsupported BIOS RAID formats won't be able to install Fedora on these arrays. For these users we'll recommend switching to software RAID. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert the changes and keep using dmraid for all BIOS RAID formats. * Contingency deadline: Beta * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes == -- 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: Fedora Budgie Spin (Self-Contained Change proposal)
ovide a better initial experience for Fedora users that is more aligned with the “stock” or “promoted defaults” experience by Budgie Desktop. Currently, end users that wish to use Budgie Desktop on Fedora must install Fedora Workstation (due to the extensive overlap between the GNOME “Stack” components offered in Workstation and that of Budgie) and apply changes to get an experience more aligned with the recommendations offered by the [https://github.com/BuddiesOfBudgie/budgie-desktop/wiki/Budgie-Desktop-on-Fedora external documentation]. A Fedora Budgie Spin would reduce the extraneous packages that come with Fedora Workstation that are not needed as part of the Budgie Desktop experience, provide consistent iconography and desktop theming, and reduce potential headaches associated with the multi-step process of getting Budgie Desktop on Fedora. == Scope == * Proposal owners: ** SIG request: [https://pagure.io/fedora-infrastructure/issue/11049 #11049] ** comps: [https://pagure.io/fedora-comps/pull-request/787 #787] ** fedora-release-budgie: [https://src.fedoraproject.org/rpms/fedora-release/pull-request/240 #240] ** kickstart: [https://pagure.io/fedora-kickstarts/pull-request/929 #929] ** livesys-scripts: [https://pagure.io/livesys-scripts/pull-request/6 #6] * Other developers: N/A * Release engineering: [https://pagure.io/releng/issue/11184 #11184] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: [https://pagure.io/Fedora-Council/tickets/issue/428 #428] * Alignment with Objectives: N/A (not needed for this Change) == Upgrade/compatibility impact == There is no upgrade / compatibility impact from the Spin. == How To Test == To test the Budgie Spin: # Boot the Fedora Budgie ISO image either on bare-metal or in a virtual machine. # Confirm successful boot into the Budgie Desktop environment. # Launch Anaconda installer from the Budgie Menu (accessible in the left corner of the bottom panel or pressing Super / Windows key) or from the desktop icon. # Confirm no issues with Budgie Desktop Settings (used for personalizing Budgie Desktop). Budgie Desktop should have consistent iconography through Papirus Icon Theme and “legacy GTK applications” should be using Materia GTK Theme. Confirm functional Budgie Control Center (display configuration panel for example). # Confirm functional system tray. # Confirm functional and accessible Raven (pressing Super / Windows key + A or Super / Windows key + N). == User Experience == Users are able to consume Budgie Desktop from https://spins.fedoraproject.org instead of installing another desktop environment and manually installing and configuring Budgie Desktop. The Fedora Budgie Spin will be as minimal as possible, offering the following: * A core set of applications e.g. GNOME Software for updates and package management, file manager, text editor, terminal, and web browser. * Consistent GTK theming through Materia GTK Theme and iconography through Papirus Icon Theme - facilitated by gschema overrides. * Recommended Budgie Desktop components (Budgie Desktop itself, Budgie Desktop View for desktop icon support, Budgie Control Center, and Budgie Screensaver for locking) * lightdm + slick-gtk-greeter for a more refined greeter experience == Dependencies == TBD == Contingency Plan == * Contingency Mechanism: If a blocker bug comes up that breaks composes of the Budgie Spin for Fedora 38, the Change can be bumped to a future Fedora release (e.g. F39). * Contingency Deadline: 2023-02-21 * Blocks release? No == Documentation == None N/A (not a System Wide Change) == Release Notes == This release introduces the Fedora Budgie Spin. The Fedora Budgie Spin aims to provide the premiere Budgie Desktop experience on top of Fedora Linux, the leading edge platform for developers and users alike. -- 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: Upgrade ImageMagick to version 7 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/ImageMagick7
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 ==
Upgrade {{package|ImageMagick}} to the latest 7.x version.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]], [[User:Sergiomb| Sérgio Basto]],
[[User:Carlwgeorge| Carl George]]
* Email: ngomp...@gmail.com, ser...@serjux.com, c...@redhat.com
== Detailed Description ==
{{package|ImageMagick}} in Fedora is currently on the 6.x version
series. The latest version series is 7.x, and
[https://legacy.imagemagick.org/ upstream now recommends upgrading to
it]. Some of this work has been verified ahead of time in
[https://copr.fedorainfracloud.org/coprs/ngompa/ImageMagick7-dev/ a
COPR project], which will be the starting point for the transition.
We will attempt to avoid introducing an ImageMagick6
compatibility package, but if it is needed, it will be introduced.
== Feedback ==
This was
[https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/OO2IBDMPNSKAHCJF5QY27CNAJYAFPZBY/
discussed on the development mailing list prior to this Change] with
most commentators agreeing that upgrading the default package
("ImageMagick") and creating a compatibility package if needed of the
legacy version ("ImageMagick6") is the right approach for Fedora.
The Change Owners privately discussed and came to the conclusion we
should try this and proceed forward.
== Benefit to Fedora ==
This brings us in line with upstream recommendations on how to ship
ImageMagick, and gives users and developers access to the latest
features and fixes being made available in the ImageMagick software.
== Scope ==
* Proposal owners:
** Update {{package|ImageMagick}} to version 7:
https://src.fedoraproject.org/rpms/ImageMagick/pull-request/10
** Rebuild reverse dependencies to link to v7 libraries
** Any packages that cannot build or be adapted to build for v7 will
need to switch to {{package|GraphicsMagick}} or an ImageMagick6
compatibility package will be introduced for them
** As much as possible will be done in a side-tag to merge into Rawhide
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/11185 #11185]
* 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 main compatibility impact will be that third party packages will
need to adapt to ImageMagick v7 or use alternatives instead. Within
Fedora itself, these choices will be handled already.
== How To Test ==
Install and use any of the packages
== User Experience ==
This is largely an invisible change, so as long as applications using
ImageMagick still work.
== Dependencies ==
Reverse dependencies of the ImageMagick libraries.
== Contingency Plan ==
* Contingency mechanism: In the event not everything can be migrated
to ImageMagick 7, then the ImageMagick6 compatibility package will be
introduced for them and they will be switched to that.
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The ImageMagick package is now based on the latest version 7 series.
This brings new enhancements, including support for more image formats
and features like HDR.
--
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
Fedora elections voting now open
Voting in the Fedora Linux 37 elections is now open. Go to the Elections app[1] to cast your vote. Voting closes at 23:59 UTC on Thursday 22 December. Don't forget to claim your "I Voted" badge when you cast your ballot. Links to candidate interviews are in the Elections app and on the Community Blog[2]. [1] https://elections.fedoraproject.org/ [2] https://communityblog.fedoraproject.org/f37-elections-voting-now-open/ -- 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: Restore stricter SSH hostkeys permissions (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/SSHKeySignSuidBit This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == We want to - drop a downstream-only patch to ssh permitting group-readable ssh host keys - drop a ssh_keys group - restore suid bit instead of sgid on a helper utility ssh-keysign == Owner == * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] * Email: dbely...@redhat.com == Detailed Description == Many years ago we implemented the patch https://src.fedoraproject.org/rpms/openssh/c/1ddd0ee5 Unfortunately, as it was 11 years ago, we can't find the exact explanation where did the requirement come from. We think that we intended to increase security, but it probably caused more confusion than gain of the security over the years. The patch allows have more relaxed permissions for the private keys than upstream OpenSSH permits - 0640 instead of 0600, and the key file must belong to the ssh_keys group. The ssh_keysign utility was simultaneously changed from suid root to sgid ssh_keys. The side effect of this solution is that ssh with hostbased auth (HBA) started to fail after changing group ID ( with newgrp, etc.). In case of HBA ssh invokes ssh-keysign that does a lot of sanity checks including groups checks. The workaround is returning setuid bit instead of sgid, and we recommend it to our clients. Some more information is available in https://bugzilla.redhat.com/show_bug.cgi?id=1498845 As this problem affects several clients, and it is a deviation from upstream (the similar patch was rejected by upstream), we want to drop this downstream patch in Fedora. We also can get rid of a designated ssh_keys group The proposed changes are available https://src.fedoraproject.org/rpms/openssh/pull-request/37 == Benefit to Fedora == We reduce deviation from upstream and reduce maintenance cost for customers. == Scope == * Proposal owners: * Other developers: https://src.fedoraproject.org/rpms/openssh/pull-request/37 is a patch, and there should be a some RN item describing the change in details. == Release Notes == TBD -- 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
F39 proposal: Boost 1.81 upgrade (System-Wide Change proposal)
== * https://www.boost.org/users/history/version_1_81_0.html (expected release mid December 2022) * https://www.boost.org/users/history/version_1_79_0.html (released on 10th August 2022) * https://www.boost.org/users/history/version_1_79_0.html (released on 13th April 2022) * https://www.boost.org/development/index.html == Release Notes == -- 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: Perl: Replace versioned MODULE_COMPAT_ requires by RPM dependency generator (System-Wide Change proposal)
''Detailed Description'''. The other packages should run-require ''perl-libs'' only. == User Experience == There should not be any remarkable change in user experience. == Dependencies == This change will affect 3259 source packages and all binary noarch packages. The rebuild of affected packages will be done by mass rebuild of Fedora 38. There is no dependency on other Fedora changes. == Contingency Plan == * Contingency mechanism: The change will be reverted. * Contingency deadline: Before Mass Rebuild. * Blocks release? No. == Documentation == == Release Notes == -- 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
Upcoming Fedora Linux 38 deadlines
Hi everyone, As you prepare for the end of the year, it's time to be thinking about your F38 plans. Here are the upcoming F38 Change proposal deadlines: * 2022-12-21: Deadline for Changes requiring infrastructure changes * 2022-12-27: Deadline for System-Wide Changes and Changes requiring a mass rebuild * 2023-01-17: Deadline for Self-Contained Changes The full schedule is at https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html -- 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: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags 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 == Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to improve mitigation of security issues arising from buffer overflows in packages in Fedora. == Owner == * Name: [[User:siddhesh| Siddhesh Poyarekar]] * Email: sipoy...@redhat.com == Detailed Description == Default C and C++ compiler flags to build packages in Fedora currently includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of some functions in glibc, thus providing some mitigation against buffer overflows. Since glibc 2.34 and GCC 12, there has been a new fortification level (`_FORTIFY_SOURCE=3`) which improves the coverage of this mitigation. The core change to bring in this mitigation is to change the default build flags in `redhat-rpm-config` so that packages build by default with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`) that do not interact well with `_FORTIFY_SOURCE` and will also need a workaround to downgrade fortification to level 2. The change will also include this override. == Benefit to Fedora == [https://docs.google.com/spreadsheets/d/1nPSmbEf3HVB91zI8yBraMqVry3_ILmlV2Z5K7FZeHZg/edit?usp=sharing Analysis of packages] in Fedora rawhide indicate that the improvement of mitigation coverage is on average over 2.4x, in some cases protecting more than half of the fortified glibc calls in the target application. This change will thus harden Fedora to a significant extent, thus making it a more secure distribution out of the box. == Scope == * Proposal owners: Post a merge request to redhat-rpm-config with the actual change to build flags. * Other developers: Resolve bugs filed for build failures, either by fixing the bug exposed by `_FORTIFY_SOURCE=3` or by disabling `_FORTIFY_SOURCE=3` for the package if it is a false positive or if the package is unable to adapt to the change. * Release engineering: Mass rebuild required * Policies and guidelines: Guidelines should include workaround for packages that fail to build with `-Wp,-D_FORTIFY_SOURCE=3` due to a false positive. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No ABI change, so there should be no impact on compatibility in a mixed environment. == How To Test == * Smoke testing of packages to ensure that they continue to work correctly. Some packages may have overflows exposed at runtime, which may need to be fixed. == User Experience == No noticeable change to users. == Dependencies == None. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) If too many packages are found to be broken at runtime, the default for fortification will be left at `_FORTIFY_SOURCE=2` for Fedora 38. Change owner will do this in `redhat-rpm-config` * Contingency deadline: Beta freeze * Blocks release? Yes * Blocks product? No == Documentation == [https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level# More context on `_FORTIFY_SOURCE=3` improvements]. == Release Notes == -- 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 Make version 4.4 (System-Wide Change proposal)
from the original environment is used. To detect this change search for 'shell-export' in the .FEATURES variable. == How To Test == GNU make has its own testsuite and does not require specific hardware or testing outside of building the RPM. == User Experience == Users will get all bugfixes included in make 4.4 as well as any new features therein. The make 4.4 NEWS update will include more details. == Dependencies == Updating GNU make does not require any other change requests to complete first. There are 9115 packages which explicitly BuildRequires "make". None of those packages will require a rebuild because of this update. == Contingency Plan == * Contingency mechanism: Revert to make 4.3 * Contingency deadline: Beta freeze. If there is a mass rebuild, preferably before then. * Blocks release? No == Documentation == GNU Make includes its own documentation. No additional documentation work is required. https://www.gnu.org/software/make/manual/ == Release Notes == Full release notes can be found in make's NEWS file: http://git.savannah.gnu.org/cgit/make.git/tree/NEWS -- 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: libpinyin 2.8 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/libpinyin_2.8 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The libpinyin 2.8 will provide phrase suggestion candidate and longer pinyin candidate features. == Owner == * Name: [[User:pwu| Peng Wu]] * Email: p...@redhat.com == Detailed Description == The phrase suggestion candidate feature will provide some candidates which will following the previous input. The longer pinyin candidate feature will provide one phrase candidate which is longer than the pinyin input. == Feedback == == Benefit to Fedora == By speeding up the Chinese characters input, the features will improve the user experience for Chinese users when using Pinyin input method. == Scope == * Proposal owners: ** Release libpinyin 2.8 and ibus-libpinyin 1.15 ** Update the Fedora libpinyin package to version 2.8.0 ** Update the Fedora ibus-libpinyin package to version 1.15.0 * Other developers: * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == == How To Test == For longer pinyin candidate feature, when user input "baiyun", one candidate longer than the pinyin input like "白云岩" will appear in the candidate list. For phrase suggestion candidate feature, when user input "baiyun", and choose the "白云" candidate, the input method will switch to suggestion mode, and several suggestion candidates will appear, like "机场", "孤飞", "亲舍", etc. == User Experience == The longer pinyin candidate and phrase suggestion candidate features will speed up the pinyin input when using the "Intelligent Pinyin" input method. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert the libpinyin and ibus-libpinyin package to the last stable version. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes == The libpinyin 2.8 package will make the pinyin input faster in the "Intelligent Pinyin" input method. -- 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: Fedora Sway Spin (Self-Contained Change proposal)
essing Windows+d). 4. Confirm no major issues with windows and display. The installed system uses `greetd-gtkgreet` as the login manager and comes preinstalled with Sway as the default desktop environment and with default applications present for most use cases. Install `sericea` on fresh install: 1. Use rpm-ostree to rebase to Fedora Sway or download a ostree variant ISO image either on bare-metal or in a virtual machine (V.M.). 2. Confirm successful boot into a configured Sway environment with basic packages available. 3. TBD 4. Confirm no major issues with windows and display. The installed system uses `greetd-gtkgreet` as the login manager and comes preinstalled with Sway as the default desktop environment and with default applications present for most use cases. == User Experience == Users are able to consume Sway from https://spins.fedoraproject.org instead of installing another desktop and then manually installing Sway after the initial installation. This reduces the number of steps needed to start using Sway. The Spin should remain as minimal as possible and only include small supplements on top of making the default configuration workable. For example, integrate sway-systemd and a login manager. We should make the user experience as easy and simple as possible without defining too many opinions. == Dependencies == TBD == Contingency Plan == * Contingency mechanism: If a blocker bug comes up that breaks composes of the Sway Spin in time for Fedora 38, the Change can be bumped to a future Fedora release (e.g. F39). * Contingency deadline: Change Checkpoint: Tue 2023-02-21 100% Code Complete Deadline * Blocks release? No == Documentation == * https://fedoraproject.org/wiki/SIGs/Sway == Release Notes == -- 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: Golang 1.20 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/golang1.20
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 of Go (golang package) to the upcoming version 1.20 in Fedora 38.
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]]
* Email: a...@redhat.com
== Detailed Description ==
Update of Go (golang package) to the upcoming version 1.20 in Fedora
38. Go 1.20 is expected to be released in February 2023. A mass
rebuild of all of the dependent packages is required.
== Feedback ==
No feedback yet.
== Benefit to Fedora ==
Up-to-date and latest Go release will be delivered to Fedora users.
Being close to upstream allows us to avoid security issues and provide
more up-to-date features.
Therefore Fedora will be providing a reliable development platform for
Go language and projects written in it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.20
== Scope ==
* Proposal owners: Rebase Golang package in Fedora 38, and help
resolve possible issues found during package rebuilds.
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: [https://pagure.io/releng/issues 11160] Rebuild
of dependent packages as part of planned mass-rebuild.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
# Install golang 1.20 from rawhide and use it to build your
application(s)/package(s).
# Scratch build against rawhide.
# Your application/package built using golang 1.20 should work as expected.
== User Experience ==
Users will have a newer version of Go, with new features described in
the release notes and security fixes
== Dependencies ==
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
Omitted due to the number of packages listed: ~2000.
== Contingency Plan ==
* Contingency mechanism: Revert to Go 1.19.X if significant issues are
discovered
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
https://tip.golang.org/doc/go1.20
== Release Notes ==
--
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: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/AutoFirstBootServices
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 ==
Add {{package|fedora-autofirstboot}} to desktop variants to run a
predetermined set of tasks on first boot after post installation,
notably installing codecs and cleaning up installer packages from the
installed system.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngomp...@gmail.com
== Detailed Description ==
{{package|fedora-autofirstboot}} is a collection of scripts that
invoke on firstboot of a freshly installed system to run a set of
predetermined tasks. It also provides a framework for third-parties to
introduce their own firstboot tasks to run through this framework. The
initial services included are to install OpenH264 and remove Anaconda.
== Benefit to Fedora ==
The main benefit is to smooth out the new user experience for new
Fedora Linux installations. In particular, we can deal with a
long-standing sticking point that Anaconda remains installed on the
user's machine when it is not useful to do so.
== Scope ==
* Proposal owners:
** Add {{package|fedora-autofirstboot}} to the desktop kickstarts
** Add a preset to {{package|fedora-release}} for
fedora-autofirstboot.service
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/11148 #11148]
* 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 ==
This will have no impact on upgraded systems, since the firstboot
condition is not true in that case.
== How To Test ==
# Install Fedora Workstation, KDE, etc.
# Reboot into installed environment
# Check to see openh264 is installed and
anaconda-core is not.
== User Experience ==
The first boot will be slightly slower because of these tasks running,
though they should happily run in the background as other services
start up, so it should not be noticeable.
== Dependencies ==
The main dependency is {{package|fedora-release}}, though we will need
to ensure all {{package|udisks2}} plugins get pulled in as
dependencies for {{package|gnome-disks}} and {{package|blivet-gui}} so
they don't get uninstalled when Anaconda is.
== Contingency Plan ==
* Contingency mechanism: Remove {{package|fedora-autofirstboot}} from
the kickstarts
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
There is not currently much documentation in
[https://pagure.io/fedora-autofirstboot the upstream project], though
contributions are welcome.
== Release Notes ==
Fedora Linux now ships with a framework for setting up first-boot
services and uses this to install multimedia software and remove the
installer software from the system after installation.
--
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: LLVM 16 (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/LLVM-16 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 all llvm sub-projects in Fedora Linux to version 16. == Owner == * Name: [[User:tstellar| Tom Stellard]] * Email: == Detailed Description == All llvm sub-projects in Fedora will be updated to version 16, and there will be a soname version change for the llvm libraries. Compatibility packages clang15 and llvm15 will be added to ensure that packages that currently depend on clang and llvm version 15 libraries will continue to work. In addition, the default LTO mode for Fedora packages compiling with clang will be changed from "Full LTO" to "Thin LTO". "Thin LTO" uses much less compiler resources than "Full LTO", and is better tested and supported by upstream. Note that this will not be a change to clang itself, but rather a change to the compiler flags for clang in redhat-rpm-config. == Benefit to Fedora == New features and bug fixes provided by the latest version of LLVM. == Scope == * Proposal owners: ** Review existing llvm and clang compatibility packages and orphan any packages that are no longer used. ** Build release candidates into @fedora-llvm-team/llvm16 COPR. ** Build final release (March 2023) into Rawhide and F38 branches. * Other developers: ** Maintainers of packages that depend on clang-libs or llvm-libs will need to update their spec files to depend on the clang15 and llvm15 compatibility packages if they want to rebuild their package and it does not work with LLVM 16 yet. The key point here is that spec file changes are only needed if a package is going to be rebuilt after LLVM 16 is added to Fedora. The compatibility packages will ensure that already built packages continue to work. * Release engineering: [https://pagure.io/releng/issues/11150] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == == How To Test == == User Experience == == Dependencies == This change can be made without updating any other packages. However, as mention before, packages that need to use LLVM 15 will need to update their spec file on their first rebuild after this change. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Contingency mechanism: (What to do? Who will do it?): If there are major problems with LLVM 16, the compatibility package provide a way for other packages to continue using LLVM 15. * Contingency deadline: Final Freeze * Blocks release? No == Documentation == Release notes will be added for this change. == Release Notes == LLVM sub-projects in Fedora have been updated to version 16: llvm clang lld lldb compiler-rt libomp llvm-test-suite libcxx libcxxabi python-lit flang mlir polly libclc llvm-unwind llvm-bolt -- 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: Remove Guile Support from GDB (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/RemoveGuileFromGdb 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 == Remove Guile extension language support from the GDB package in favor of the widely tested and feature-rich Python support == Owner == * Name: [[User:keiths| Keith Seitz]] * Email: kei...@redhat.com == Detailed Description == The GDB package supports Python and Guile for writing extensions to the debugger. The Python extensions are actively used by many developers including the glibc developers for printing detailed POSIX Thread information and by libstdc++ (gcc) developers for printing developer friendly views of the standard library data structures. The current Guile extension support is less actively used and this change request proposes to remove that support from GDB. == Feedback == Red Hat's Platform Tools team supports this change. == Benefit to Fedora == GDB already supports a much more widely tested and feature-rich Python interface1, and the GDB maintainers would like to remove the maintenance burden imposed by supporting multiple scripting interfaces. The Guile interface has already been disabled in RHEL9 and onwards. This would align Fedora and RHEL and standardize the community more directly on the Python interface for extension development. 1 The GDB User Manual states, “[https://sourceware.org/gdb/current/onlinedocs/gdb/Multiple-Extension-Languages.html#Multiple-Extension-Languages python comes first].” The Manual’s [https://sourceware.org/gdb/current/onlinedocs/gdb/Python-API.html#Python-API Python] and [https://sourceware.org/gdb/current/onlinedocs/gdb/Guile-API.html#Guile-API Guile] API pages demonstrate the disparity of support between these two extension languages. == Scope == * Proposal owners: Update gdb spec file. * Other developers: Update GDB scripting files if using Guile. Repository queries show no packages which rely on GDB that contain any Guile source files. * 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: == Upgrade/compatibility impact == Users with Guile scripts will need to update and/or rewrite their scripts in Python. == How To Test == == User Experience == Guile scripts that extend the functionality of GDB will stop working when users upgrade. Users are encouraged to use GDB's Python interface instead. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == == Release Notes == Release notes should mention the removal of Guile support in GDB and suggest alternatives. -- 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
FESCo election nominations are now open
Now through 30 November, you may nominate candidates for the open seats on the Fedora Engineering Steering Committee (FESCo). To nominate yourself (or others, if you check with them first), visit: https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations FESCo is currently selecting the questions for the interview questionnaire, which will be finalized before the beginning of the interview period. For more information, see the Community Blog post: https://communityblog.fedoraproject.org/f37-election-nominations-now-open/ -- 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: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/KDERemoveInitialSetup This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == We currently don't use the initial-setup application in the main KDE Spin and Kinoite installation ISOs as everything gets configured at installation time via Anaconda. We thus want to remove this package from the installation ISOs while keeping it where we currently need it (pre-installed disk images, etc.). Note that an "initial setup" app is still needed to enable OEM-style installations (https://askubuntu.com/questions/1386806/what-is-oem-installation-regarding-linux-distributions) of the KDE Spin/Kinoite (like Fedora Workstation/Silverblue) so we're planning on introducing a more KDE native application as a replacement once it is ready, but that may not not happen as part of this change. == Owner == * Name: [[User:Siosm| Timothée Ravier]], [[User:Ngompa| Neal Gompa]] * Email: si...@fedoraproject.org, ngo...@fedoraproject.org == Detailed Description == We'll remove the initial-setup package from the KDE Spin & Fedora Kinoite. This will fix a bug that is only visible on Kinoite (where the user gets a warning on first boot because / is read only) and will let us work on replacing it by another more KDE native application instead. OEM installations are installations where only the minimum is configured by the vendor (hardware provider) and everything else is done by the user on first boot. This is the default experience on Fedora Workstation and other major operating systems. See also: https://askubuntu.com/questions/1386806/what-is-oem-installation-regarding-linux-distributions. Note that this is not about removing Anaconda as an installer or from the Live ISO, but removing initial-setup. For Fedora Kinoite where we don't have a Live ISO but a separate installer ISO that includes Anaconda, this will effectively also remove Anaconda from the final system. See also the discussion in https://pagure.io/fedora-kde/SIG/issue/243 for potential alternatives. == Feedback == None so far. == Benefit to Fedora == * Smaller image * One less UX bug on Kinoite * Work in the direction of OEM installations for the KDE based variants == Scope == * Proposal owners: ** Remove the packages and test the change. Work on packaging alternatives and potential integration. ** OpenQA tests to update if we successfully enable the OEM installation mode. * Other developers: N/A * Release engineering: N/A * 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 == Only impacts the first boot after installation. Should not impact updates. == How To Test == Once the change has landed in Rawhide, downloading the ISO and performing an installation should behave the same as currently. If we successfully have a replacement then folks will be able to test OEM installations. == User Experience == No change initially. If we successfully have a replacement then we can enable OEM installations. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Revert the change. * Contingency deadline: Anytime, probably before Beta * Blocks release? No == Documentation == N/A == Release Notes == N/A. If we add OEM installation support then we can mention that. -- 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: Prevent from building RPM packages providing python3dist(...) = 0 (Self-Contained Change proposal)
es: [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source_files_from_pypi Python Packaging Guidelines] cover the topic of creating the version string. This will be valid even when we change the Python RPM generators behavior * Trademark approval: not needed for this Change * Alignment with Objectives: No == Upgrade/compatibility impact == None. == How To Test == * Prepare a Python package, set the version to `0` or * Use one of the known packages that provide version `0`. * Try to build an RPM package in a regular way (eg. mockbuild) * The build should fail. == User Experience == The actual users should notice no difference. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert * Contingency deadline: Beta freeze * Blocks release? No == Documentation == This page is the documentation of this change. == Release Notes == -- 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 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd 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 == By design, ostree does not manage bootloader updates as they can not (yet) happen in a transactional, atomic and safe fashion. Thus bootupd (https://github.com/coreos/bootupd) was created to solve this issue and enable admin-lead bootloader updates. This change is about enabling bootupd integration in Fedora Silverblue and Fedora Kinoite to make bootloader updates easier. == Owner == * [[User:Siosm| Timothée Ravier]] * [[User:Tpopela| Tomáš Popela]] * [[User:Walters| Colin Walters]] == Detailed Description == Adding bootupd full bootupd support has two immediate benefits: * User will be able to easily update the bootloader on their system. This will let them apply Secure Boot dbx updates that block old bootloaders with known vulnerabilities from loading. See: ** https://github.com/fedora-silverblue/issue-tracker/issues/355 ** https://bugzilla.redhat.com/show_bug.cgi?id=2127995 * We can start planning for the removal of the ostree-grub2 package from the images to solve the "all deployments are shown twice in GRUB" issue. This bug comes from the fact that old GRUB versions that do not have BLS support and we thus can not only rely on BLS support in ostree to generate boot and have to also update the grub configuration for every updates via the scripts in the ostree-grub2 package. This has already (indirectly) caused a major upgrade issue on Silverblue/Kinoite requiring manual interventions from all users. See: ** https://fedoramagazine.org/manual-action-required-to-update-fedora-silverblue-kinoite-and-iot-version-36/ ** https://github.com/fedora-silverblue/issue-tracker/issues/120 Note that we can not yet enable unattended bootloader updates as even though bootupd tries hard hard to make those updates as safe as possible, it is currently not possible that they are safe if the system crashes (or loses power) at the wrong time. The following change in shim (https://github.com/rhboot/shim/pull/502) should help with that. Thus bootloaders updates will remain a manually user triggered operation for now. Also note that this change currently relies on the image being composed via rpm-ostree in unified core, which is the subject of the following change also proposed for Fedora 38: https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore == Feedback == None so far. == Benefit to Fedora == Fedora Silverblue and Fedora Kinoite users can easily do bootloaders updates (that includes security fixes) and we can remove support for legacy GRUB versions thus simplify the upgrade process and making it more reliable. == Scope == * Proposal owners: Testing of the integration and new builds. The code changes are mostly done and the integration changes are mostly already ready as bootupd has already been integrated in a similar fashion in Fedora CoreOS. * Other developers: N/A * Release engineering: N/A * 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 == There should be not visible change for users when upgrading. The change only impacts the way the images are composed on the server. == How To Test == We will extend the test instructions once the unified core changes have landed. You can follow: https://github.com/fedora-silverblue/issue-tracker/issues/120 and https://github.com/fedora-silverblue/issue-tracker/issues/355. == User Experience == For now, users will have to update their bootloader manually via the command line. Integration to GNOME Software and Plasma Discover might be interesting to make that easier. Once the fallback EFI feature is available in shim (and support implemented in bootupd), we can consider implementing automated updates. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert the change in the rpm-ostree manifests. Owners will do it. Nothing to do for users. * Contingency deadline: Can happen anytime. * Blocks release? No == Documentation == We will write docs to let users update their bootloaders manually. They will look very similar to https://docs.fedoraproject.org/en-US/fedora-coreos/bootloader-updates/. == Release Notes == Will have to be written. -- 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://fedoraprojec
F38 proposal: Build Fedora Silverblue & Kinoite using rpm-ostree unified core mode (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore 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 == rpm-ostree upstream development is focusing on the "unified core" mode and the previous mode is being deprecated. Fedora Silverblue and Fedora Kinoite are currently building using the old mode and we've wanted to move over for a while. The main advantage of the unified core mode is that it is stricter and safer, while enabling some post processing steps to happen during or after the image build. == Owner == * Name: [[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš Popela]], [[User:Walters| Colin Walters]] * Email: . , == Detailed Description == For more details about the difference between the two mode, you can read the upstream issue: https://github.com/coreos/rpm-ostree/issues/729. See also the history in https://pagure.io/workstation-ostree-config/issue/137. On top of the advantages listed above, we need unified core support to be able to add bootupd integration to Fedora Silverblue & Kinoite. See: * https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd * https://github.com/fedora-silverblue/issue-tracker/issues/120 * https://pagure.io/workstation-ostree-config/pull-request/313 The in-progress changes are in: * Support in Pungi: https://pagure.io/pungi/pull-request/1626 & https://pagure.io/pungi/pull-request/1629 * Fedora Pungi configuration change: https://pagure.io/pungi-fedora/pull-request/1115 * Fedora Silverblue & Kinoite changes in progress in: https://pagure.io/workstation-ostree-config/pull-request/296 GitHub issue used to track this work and testing: https://github.com/fedora-silverblue/issue-tracker/issues/333 == Feedback == None yet. == Benefit to Fedora == The old mode in rpm-ostree is not maintained anymore and less tested thus more prone to bugs. Moving to the new mode will unify Silverblue & Kinoite to the same code that is used to build Fedora CoreOS and that receives a lot of testing. This will remove maintenance burden on the rpm-ostree project as they will thus be able to remove the old code. The new mode also makes composes work the same on the server side and the client side and makes them safer by more strictly confining scriptlets execution. == Scope == * Proposal owners: Testing of builds with the new mode to make sure there is not regression. The infra & configurations changes for Pungi should be ready. * Other developers: N/A * Release engineering: N/A * 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 == There should be not visible change for users when upgrading. The change only impacts the way the images are composed on the server. == How To Test == Use the commands from the justfile in https://pagure.io/workstation-ostree-config/pull-request/296 to test building in unified core mode. Update an existing installation and verify that everything works as expected. Once we merge that in Rawhide, updating will be enough (no need to rebuild). == User Experience == N/A == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert to non unified core build mode (single change in Fedora's Pungi configuration). Owners will do it. Nothing to do for users. * Contingency deadline: Can happen anytime. * Blocks release? No == Documentation == N/A == Release Notes == N/A -- 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: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
broken by this new behavior can unset
`%clamp_mtime_to_source_date_epoch` but packagers are encouraged to
fix the problem instead.
== Feedback ==
Enabling this RPM feature was
[https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/126
proposed as a pull request] to {{package|redhat-rpm-config}} in April
2021. It received good feedback with the exception of the following:
* it was said the change needs to be coordinated with the Python maintainers
* it was said the change should be done via a change process for
better coordination and exposure
We believe that by proposing this via the change process and planning
for the changes needed in Python, both issues are addressed.
== Benefit to Fedora ==
We believe that many RPM packages will become reproducible and others
will be more reproducible than before. The benefits of reproducible
builds are better explained at https://reproducible-builds.org/
== Scope ==
* Proposal owners:
** Propose a PR for {{package|redhat-rpm-config}} (set
`%clamp_mtime_to_source_date_epoch` to `1`, possibly only when
`%source_date_epoch_from_changelog` is set)
** Propose a PR for {{package|python-rpm-macros}} (unset
`$SOURCE_DATE_EPOCH` while creating `.pyc` files iff
`%clamp_mtime_to_source_date_epoch` is not `1`)
** Propose a PR for
[https://src.fedoraproject.org/rpms/python3.11/blob/b2d80045f9/f/00328-pyc-timestamp-invalidation-mode.patch
the Python's bytecode invalidation mode patch] for all Python versions
that have it
** Backport (the new portion of) the patch to older Pythons
({{package|python2.7}}, {{package|python3.6}} and PyPys)
** Test everything together in Copr and deploy it if it works.
** Optional: Run some reproducibility tests before and after this
change and produce some statistics.
* Other developers:
** Test their packages with the new behavior, report problems, and
opt-out if really needed.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Nothing anticipated.
== How To Test ==
The change owners plan to perform a mass rebuild in Copr to see if
this breaks anything significantly.
If it actually works as anticipated, they also plan to run some
reproducibility tests and hopefully produce some statistics before and
after this change.
Other packages can test by building their packages and verifying they
still work as expected and no packaged files have higher mtimes than
the last `%changelog` entry.
To verify if this change has landed, run: `rpm --eval
'%clamp_mtime_to_source_date_epoch'` on Fedora 38. The result should
be `1`.
== User Experience ==
Users of Fedora Linux on their machines should not be impacted at all.
Users who build RPM packages atop Fedora will be impacted by this
change the same way Fedora is.
== Dependencies ==
* RPM needs to support this (it already does)
* RPM needs to set `$SOURCE_DATE_EPOCH` (it already does)
== Contingency Plan ==
* Contingency mechanism: The change owners or
{{package|redhat-rpm-config}} maintainers or proven packagers will
revert the change in {{package|redhat-rpm-config}}. That should be
enough to undo anything as the changes in Python should be dependent
on that. If not enough, revert everything.
* Contingency deadline: Ideally, we should do this before the Mass
Rebuild. Technically, we can land it any time before the Beta Freeze,
but it would not change all the packages, which is a bit messy. *
Blocks release? No <
== Documentation ==
This page is the documentation.
== Release Notes ==
--
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: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)
hange will affect 3259 source packages and all binary noarch packages. The rebuild of affected packages will be done by mass rebuild of Fedora 38. There is no dependency on other Fedora changes. == Contingency Plan == * Contingency mechanism: The change will be reverted. * Contingency deadline: Before Mass Rebuild. * Blocks release? No. == Documentation == == Release Notes == -- 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
Fedora Linux 37 Final is GO
The Fedora Linux 37 Final RC 1.7 compose is GO and will be shipped live on Tuesday, 15 November. For more information please check the Go/No-Go meeting minutes[1] or log[2]. [1] https://meetbot.fedoraproject.org/fedora-meeting/2022-11-10/f37-final-go_no_go-meeting.2022-11-10-17.02.html [2] https://meetbot.fedoraproject.org/fedora-meeting/2022-11-10/f37-final-go_no_go-meeting.2022-11-10-17.02.log.html -- 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
Reminder: F37 Final Go/No-Go meeting tomorrow
The Fedora Linux 37 Final Go/No-Go[1] meeting is scheduled for Thursday 10 November at 1700 UTC in #fedora-meeting. Note that depending on your time zone, this may be an hour earlier in your local time than you're used to. At this time, we will determine the status of the F37 Final for the 15 November target date #3[2]. For more information about the Go/No-Go meeting, see the wiki[3]. Currently, we have 1 proposed release blocker bug[4]. [1] https://calendar.fedoraproject.org/meeting/10360/ [2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting [4] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist -- 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: MobilityPhoshImage (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/MobilityPhoshImage 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 == Phosh is a wayland shell for mobile devices based on Gnome. The mobility SIG has packaged up Phosh and related packages into a 'phosh-desktop' package group and would like to start making x86_64 and aarch64 images for mobile devices. == Owner == * Name: [[User:Kevin| Kevin Fenzi]], [[User:Torbuntu| Torrey Sorensen]] == Detailed Description == There's a number of x86_64 and aarch64 tablets and other mobile devices that could use a more mobile centric interface/desktop than traditional Fedora desktops/labs/spins. Having Fedora images for these devices will make it easier to install and use them. Having a image will also help remix efforts, allowing them to reuse userspace packages and metadata (kickstarts, etc) with a modified kernel. Note: Plasma Mobile is also being packaged and will be requested in another change Note: Pinephone and Pinephone Pro are eventual targets for these images, but more kernel patches must be upstreamed before these devices will boot and function. == Benefit to Fedora == These images will spread Fedora to mobile devices and bring more users into the Fedora community as well as showcasing upstream work to provide a 100% open source phone interface for devices once they are workable from vanilla kernels. == Scope == * Proposal owners: Create kickstarts and other configuration needed to produce aarch64 and x86_64 images. Fix bugs related to phosh-desktop group and associated packages. * Other developers: Help test images and groups * Release engineering: Review kickstarts and pungi configutation, produce images. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == == How To Test == Install the produced image to a suitable x86_64 or aarch64 device with arm-image-installer or dd Boot the image and confirm it comes up to a phosh desktop Use various desktop functions and report issues. == User Experience == == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No == Documentation == N/A (not a System Wide Change) == Release Notes == Initial images are produced for x86_64 and aarch64 mobile devices using the Phosh desktop. -- 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: Ruby 3.2 (System-Wide Change proposal)
== How To Test == * No special hardware is needed. * To test, install Ruby 3.2. The test builds are published in PR or on Ruby-SIG ML * Try to locally rebuild your packages using Ruby 3.2. * Use the packages with your applications previously written in Ruby. * If something doesn't work as it should, let us know. == User Experience == The Ruby programs/scripts should behave as they were used to. == Dependencies == $ dnf repoquery --disablerepo=* --enablerepo=rawhide --enablerepo=rawhide-source --arch=src --whatrequires 'ruby-devel' | sort | uniq | wc -l 130 == Contingency Plan == * Contingency mechanism: We would like to get a special buildroot tag to be able to rebuild necessary the packages with Ruby 3.2. If anything goes wrong, the tag could be easily dropped and previous version of Ruby 3.1 and its dependencies stays intact. The tag would be merged into F38 after everything is rebuild * Contingency deadline: Mass Rebuild * Blocks release? No == Documentation == * [http://www.ruby-doc.org/ Help and documentation for the Ruby programming language] * [https://github.com/ruby/ruby/blob/master/NEWS.md Ruby 3.2.0 NEWS] * [https://www.ruby-lang.org/en/news/2022/09/09/ruby-3-2-0-preview2-released/ Ruby 3.2 Preview 2 release announcement] == Release Notes == * The Ruby 3.2 bumps soname, therefore Ruby packages, which use binary extensions, should be rebuilt. Nevertheless, since upstream paid great attention to source compatibility, no changes to your code are needed. https://github.com/ruby/ruby/blob/master/NEWS.md -- 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
Fedora Linux 37 Final is NO-GO
Due to outstanding blocker bugs[1], F37 Final release candidate 3 was declared NO-GO. Because of the upcoming OpenSSL critical vulnerability disclosure, we are pushing the next target date out a week. See the Fedora Magazine article[2] for more information. The next Fedora Linux 37 Final Go/No-Go meeting[3] will be held at 1700 UTC on Thursday 10 November in #fedora-meeting. We will aim for the "target date #3" milestone of 15 November. The release schedule[4] has been updated accordingly. Minutes[5] and full logs[6] are available on Meetbot. [1] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist [2] https://fedoramagazine.org/fedora-linux-37-update/ [3] https://calendar.fedoraproject.org/meeting/10360/ [4] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [5] https://meetbot.fedoraproject.org/fedora-meeting/2022-10-27/f37-final-go_no_go-meeting.2022-10-27-17.01.html [6] https://meetbot.fedoraproject.org/fedora-meeting/2022-10-27/f37-final-go_no_go-meeting.2022-10-27-17.01.log.html -- 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
F39 proposal: Python 3.12 (System-Wide Change proposal)
ution. If any issues appear,
they should be solvable either by communicating with the respective
upstreams first and/or applying downstream patches. Also, the package
maintainers should have a look at:
[https://docs.python.org/3.12/whatsnew/3.12.html#porting-to-python-3-12
Porting to Python 3.12]. The python-maint team will be available to
help with fixing issues.
* Release engineering: [TBD]
* Policies and guidelines: nope
* Trademark approval: nope
== Upgrade/compatibility impact ==
All the packages that depend on Python 3 must be rebuilt. User written
Python 3 scripts/applications may require a small amount of porting,
but mostly Python 3.11 is forward compatible with Python 3.12.
=== The Python standard library distutils module will be removed ===
For many years distutils module was providing support for building and
installing additional modules into a Python installation.
Since Python 3.10 distutils package is deprecated, and will be removed
in Python 3.12. Its functionality for specifying package builds has
already been completely replaced by third-party packages setuptools
and packaging, and most other commonly used APIs are available
elsewhere in the standard library (such as platform, shutil,
subprocess or sysconfig).
Affected packages will be failing with `ModuleNotFoundError: No module
named 'distutils'`.
The python3-setutpools package provides a distutils module, so
sometimes "simply" adding BuildRequires: python3-setuptools might
workaround the problem. Unfortunately, it is not 100 % compatible with
the removed standard library one distutils:
https://github.com/pypa/setuptools/issues/3532
Fedora packagers can check if their packages build without distutils
by removing it form Python 3.11:
# `fedpkg clone && cd `
# `mock -r fedora-rawhide-x86_64 init`
# `mock -r fedora-rawhide-x86_64 install python3-devel`
# `sudo rm -rf
/var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/python3.11/distutils/`
# `fedpkg mockbuild -N`
Later, when [https://copr.fedorainfracloud.org/coprs/g/python/python3.12/
Python 3.12 COPR] is available, you can use it for testing.
See
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/N6ITYHLRWIDNYNXGPYG2ZHF3ZLQWZN7L/
for known Fedora packages that'll need changes.
== How To Test ==
Interested testers do not need special hardware. If you have a
favourite Python 3 script, module, or application, please test it with
Python 3.12 and verify that it still works as you would expect. If the
application you are testing does not require any other modules, you
can test it using {{package|python3.12}} even before this change is
implemented, in Fedora 36, 37 or 38.
In case your application requires other modules, or if you are testing
an rpm package, it is necessary to install the 3.12 version of the
python3 rpm. Right now that rpm is available in copr, along with all
other python packages that build successfully with python 3.12. See
https://copr.fedorainfracloud.org/coprs/g/python/python3.12/ for
detailed instructions on how to enable Python 3.12 copr for mock.
Once the change is in place, test if your favourite Python apps are
working as they were before. File bugs if they don't.
== User Experience ==
Regular distro users shouldn't notice any change in system behaviour
other than the Python 3 interpreter will be in version 3.12.
== Dependencies ==
4000+ packages depend on Python 3 and ~3900 packages need rebuilding
when Python is upgraded. See scope section.
== Contingency Plan ==
* Contingency mechanism: Do not merge the side tag with rawhide. If
the side tag has been merged and issues arise, that will justify a
downgrade, then use an epoch tag to revert to 3.11 version (never
needed before) * Contingency deadline: TBD
* Blocks release? Yes, we'd like to block Fedora 39 release on at
least 3.12.0rc1
* Blocks product? See above
== Documentation ==
[https://peps.python.org/pep-0693/ Python 3.12 Release Schedule]
[https://peps.python.org/pep-0693/#features-for-3-12 Features for 3.12]
[https://docs.python.org/3.12/whatsnew/3.12.html What's new in 3.12]
[https://docs.python.org/3.12/whatsnew/3.12.html#porting-to-python-3-12
Porting to Python 3.12]
== Release Notes ==
* Migrating user installed packages -
https://pagure.io/fedora-docs/release-notes/issue/503
--
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
F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)
a with an uncoordinated change], and more recently [https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213/32|with an uncoordinated Clang update]. == Benefit to Fedora == Programmers will no longer waste time tracking down things that look eerily like compiler or ABI bugs because in several cases, builds will fail with a clear error message, instead of producing a warning that is easily missed. Potential blockers to adoption of further C language changes are removed. == Scope == * Proposal owners: Update rawhide over time to be compatible with strict C99 compilers. * Other developers: Help out with non-obvious porting issues, and with upstreaming patches in case active upstreams cannot be easily identified. Tolerate early backports of upstream-submitted fixes in Fedora dist-git. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: Fedora compiler policy will likely change due to the adoption of GCC 14 in Fedora 40. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == The change is expected to be transparent to those users who do not use C compilers. No features are supposed to be added or removed as a result. In fact, most of the porting effort focuses on avoiding configuration changes. == How To Test == General regression testing is sufficient. == User Experience == User experience does not change. == Dependencies == To avoid regressing the porting effort, GCC as the system compiler needs to reject obsolete constructs by default. This is expected for GCC 14, to be released as part of Fedora 40 in Spring 2024. == Contingency Plan == * Contingency mechanism: Upstream GCC will probably accept obsolete constructs longer in case distributions like Fedora cannot port to modern C in time. * Blocks release? No if GCC doesn't switch. If GCC switches, we have to complete the port. == Documentation == This section will be updated once more documentation of the porting effort will become available. == Release Notes == Probably not needed because no user visible impact is intended. -- 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
Fedora Linux 37 Final is NO-GO
Due to outstanding blocker bugs[1], F37 Final release candidate 2 was declared NO-GO. The next Fedora Linux 37 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 27 October in #fedora-meeting. We will aim for the "target date #2" milestone of 1 November. The release schedule[3] has been updated accordingly. Logs and minutes are not available in Meetbot because Zodbot failed halfway through, but I have uploaded my local logs to the Internet Archive[4]. [1] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist [2] https://calendar.fedoraproject.org/meeting/10352/ [3] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [4] https://archive.org/download/37-final-go-no-go-meeting.-2022-10-20-17.13.log/37-final-go_no_go-meeting.2022-10-20-17.13.log.txt -- 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
Reminder: F37 Final G/No-Go meeting Thursday
The Fedora Linux 37 Final Go/No-Go[1] meeting is scheduled for Thursday 20 October at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F37 Final for the 25 October target date #1[2]. For more information about the Go/No-Go meeting, see the wiki[3]. Currently, we have 2 accepted and 1 proposed release blocker bugs[4]. [1] https://calendar.fedoraproject.org/meeting/10352/ [2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting [4] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist -- 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: Modernize Live Media (System-Wide Change proposal)
orax to go back to previous behavior * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == Information on the persistent overlay functionality is included in the Dracut documentation. == Release Notes == By default, Fedora Linux live environments flashed to writable USB media with sufficient free space will maintain user changes to the environment. This "persistence" can be reset at boot time through the boot menu. -- 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: LXQt image for aarch64 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/LXQt_image_for_aarch64 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 == Generate LXQt image (both iso and disk image) for aarch64 architecture. == Owner == * Name: [[User:Zsun|Zamir SUN]] * Email: zsun#AT#fedoraproject.org == Detailed Description == LXQt has moved out of 0.x version and is now 1.1.0, so I consider it to be a pretty stable desktop environment. Recently, 64bit ARM architecture is becoming more and more popular in laptops and workstations. By generating a LXQt image for aarch64 will offer aarch64 another easier option to evaluate and use Fedora. == Benefit to Fedora == Offers users of 64bit ARM architecture another desktop option that works out-of-the-box. == Scope == * Proposal owners: Nothing. The LXQt packages are already in the distribution. And the kickstart for generating LXQt image on x86_64 can be directly used. * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issue/11086 11086] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == Install using the ISO or the disk image on aarch64 system. The system should work as it should be by manually installing on top of any existing aarch64 system. == User Experience == Users of aarch64 systems should be able to directly install from LXQt ISO or disk image if they want to use LXQt. == Dependencies == We need to ask release engineering team to generate the image. == Contingency Plan == * Contingency mechanism: Just do not ship the newly generated image. * Contingency deadline: Fedora 38 Beta Freeze * Blocks release? N/A (not a System Wide Change) * Blocks product? N/A == Documentation == N/A (not a System Wide Change) == Release Notes == -- 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: Ostree Native Container (Phase 2, stable) (System-Wide Change proposal)
y!) - this would just be supporting that in a clear external way too. One likely target for this is [https://github.com/osbuild osbuild] and [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/composing_a_customized_rhel_system_image/index RHEL Image Builder]. == Feedback == == Benefit to Fedora == The need to understand ostree goes away for most users; they understand RPMs and containers. While retaining all the current (rpm-)ostree features. == Scope == * Proposal owners: * Other developers: May affect e.g. gnome-software and similar tools that talk to rpm-ostree. * Release engineering: [https://pagure.io/releng/issue/11047] * Policies and guidelines: None. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: None == Upgrade/compatibility impact == We will ship a systemd unit that transitions systems currently using OSTree on the wire over to tracking the corresponding container images. Note again, all features of rpm-ostree continue to work! For example, if you have layered packages, that will continue to be applied. == How To Test == Build container images, boot them. == User Experience == Users will not need to understand ostree (at least at a superficial level), only container images. == Dependencies == Needs improvements in Anaconda in some cases, also would like to increase alignment with dnf. Fetching container images uses `skopeo`, maintained by containers team. == Contingency Plan == * Contingency mechanism: Continue to ship things the way we ship them today * Contingency deadline: Dunno * Blocks release? No == Documentation == https://coreos.github.io/rpm-ostree/container/ and https://github.com/coreos/coreos-layering-examples etc. == Release Notes == -- 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
Fedora Linux 37 Final is NO-GO
Due to outstanding blocker bugs[1], we do not have a current release candidate. As a result, Fedora Linux 37 Final is NO-GO. The next Fedora Linux 37 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 20 October in #fedora-meeting. We will aim for the "target date #1" milestone of 25 October. The release schedule[3] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist [2] https://calendar.fedoraproject.org/meeting/10352/ [3] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html -- 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: PostgreSQL 15 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/PostgreSQL_15 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. == Owner == * Name: [[User:osloup| Ondřej Sloup]] * Email: osl...@redhat.com == Detailed Description == Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora from version 14 to version 15 in the non-modular (main) builds. This also involves moving the postgresql-static subpackage to libpq creating the libpq-static subpackage. === Plan === * Prepare PostgreSQL 15 in Copr (TBD) * Rebuild important dependencies in Copr (TBD) * Debug and fix compatibility issues found in dependencies (a reasonable amount of non-critical in FTBFS state might be tolerable) * Build in a "side tag" to prevent dependencies from failing and rollout once stable * Prepare Pull requests in Rawhide * Merge and build into a "side tag" * Once stable merge into Rawhide == Feedback == == Benefit to Fedora == The latest stable software is used by Fedora users, providing additional features and fixes. == Scope == * Proposal owners: **Prepare PostgreSQL 15 **Prepare PostgreSQL 14 as a module for Rawhide **Check software that requires or depends on `postgresql-server` or `libpq` packages for incompatibilities **Build PostgreSQL 15 (postgresql and libpq) to Rawhide **Rebuild depended on packages against PostgreSQL 15 **Gather user input on the changes between PostgreSQL 14 and PostgreSQL 15 * Other developers: N/A * Release engineering: * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The PostgreSQL client library (libpq component) is compatible. So, there shouldn't be any compatibility issues, but rebuilding the dependent components is recommended. Server plugins might require a newer version update because they sometimes have explicit server requirements. PostgreSQL maintainer will help fix/rebuild any issues in the plugins. How to upgrade your database data from one PostgreSQL release to a newer one is described in [https://www.postgresql.org/docs/15/upgrading.html Upgrading a PostgreSQL Cluster] == How To Test == Usual testing when upgrading between major PostgreSQL versions is running `postgresql-setup --upgrade` necessary between major versions. Test that all other software runs well with PostgreSQL 15. == User Experience == The users will have to upgrade their databases the same way as major PostgreSQL versions, aka `postgresql-setup --upgrade` after installing PostgreSQL 15 server packages. If users want to stick with PostgreSQL 14 for a little longer, there will be PostgreSQL 14 module. == Dependencies == Some packages (mostly server plugins) build on top of PostgreSQL. Since the separation of the PostgreSQL client library (libpq component), only packages that build server plugins should use postgresql package in BuildRequires; others should use libpq. In the case of Postgresql-server, a rebuild should be done to make sure all potential binary incompatibilities are handled. * PostgreSQL server dependencies ** perl-DBD-Pg ** pgaudit ** qt ** qt3 ** qt5-qtbase ** postgres-decoderbufs ** gambas3 ** kdb ** kea ** libpqxx ** openvas-manager ** orafce ** pg-semver ** pgRouting ** pgadmin3 ** pgsphere ** postgis ** postgresql-ip4r ** postgresql-pgpool-II ** qt3 ** rdkit ** rhdb-utils ** timescaledb ** pg_repack == Contingency Plan == Revert changes in the non-modular packages and provide PostgreSQL 15 as a module stream only. == Documentation == Upgrade strategy: https://www.postgresql.org/docs/15/upgrading.html == Release Notes == Release notes for PostgreSQL 15 release: https://www.postgresql.org/docs/15/index.html Overall overview of the changes and improvements: https://www.postgresql.org/docs/15/release-15.html -- 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: RPM Sequoia (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/RpmSequoia 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 == Change RPM to use [https://sequoia-pgp.org/ Sequoia] based OpenPGP parser instead of it's own, flawed and limited implementation. == Owner == * Name: [[User:pmatilai| Panu Matilainen]] * Email: pmati...@redhat.com == Detailed Description == For the last 20 years or so, RPM has used a home-grown OpenPGP parser for dealing with keys and signatures. That parser is rather infamous for its limitations and flaws, and especially in recent years has proven a significant burden to RPM development. In order to improve security and free developer resources for dealing with RPM's "core business" instead, RPM upstream is in the process of deprecating the internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP] based solution written in Rust. At this point the change is mostly invisible in normal daily use. == Feedback == == Benefit to Fedora == The main, direct benefit to Fedora is improved security and standards-compliance (RFC-4880) in one of the corner-stones of the whole distribution. Longer term, we can expect better error messages and other functional improvements regarding key and signature handling. == Scope == * Proposal owners: ** Help [https://bugzilla.redhat.com/show_bug.cgi?id=2087499 package/review rpm-sequoia] ** Build rpm with --with-crypto=sequoia ** Watch out for the unexpected * Other developers: ** Help [https://bugzilla.redhat.com/show_bug.cgi?id=2087499 package/review rpm-sequoia] * Release engineering: [https://pagure.io/releng/issue/11077 #11077] * 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 == Within Fedora package set, this has no impact as everything is already using sufficiently strong crypto. Third party repositories / packages could be signed with insecure crypto, and those may require working around with --nosignature. However this incidentally overlaps with https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 which has effectively the same effect on rpm. == How To Test == In general, normal rpm/dnf use provides sufficient test coverage. For more advanced testers: try signing and verifying with different keys and their subkeys, using different algorithms etc. == User Experience == For normal usage, the change is quite invisible. The notable exceptions are - Some old, insecure (MD5/SHA1 based) signatures are rejected (this is in line with the stronger crypto settings proposed elsewhere for F38) - Key import may accept some previously rejected keys, in part due to limitations of old parser etc but in particular, the old implementation verifies self-signatures at import time whereas Sequoia verifies them at time of use. - Key import may reject some previously accepted keys due to better validation. == Dependencies == The change introduces one new direct dependency: [https://github.com/rpm-software-management/rpm-sequoia/ rpm-sequoia]. The rpm-sequoia package also takes over other crypto besides OpenPGP, currently Sequoia uses nettle as its low-level crypto provider, but work is underway to [https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1361 support openssl in Sequoia], and the plan is to have Sequoia in Fedora use that once it becomes available. This plan [https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/EY5VVR2VPKSISHRANZTK2HYA6RP6345L/ has support of the crypto team]. == Contingency Plan == * Contingency mechanism: Revert back to the internal PGP parser * Contingency deadline: Beta release * Blocks release? No == Documentation == There's not much in the way of documentation as there's not much to document, except for the deprecation of the internal parser: https://github.com/rpm-software-management/rpm/issues/1935 rpm-sequoia build instructions can be found in https://github.com/rpm-software-management/rpm-sequoia/ == Release Notes == -- 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
Fedora Linux 37 Final Go/No-Go meeting next week
The Fedora Linux 37 Final Go/No-Go[1] meeting is scheduled for Thursday 13 October at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F37 Final for the 18 October early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. Currently, we have 9 accepted and 7 proposed release blocker bugs[4]. [1] https://calendar.fedoraproject.org/meeting/10352/ [2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting [4] https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist -- 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: Deprecate python-toml (Self-Contained Change proposal)
eam, it exists in EPEL 8,
unlike `tomli` (currently).
Some Fedora-upstream projects might need to migrate to `tomllib` but
keep using `toml` on older Pythons.
* Change any `toml` requirements in upstream metadata to
`toml;python_version<"3.11"`.
* Change all `toml` imports to `sys.version_info`-conditional or `try:
except ImportError:` `tomli`/`tomllib` imports.
* Change all references of `TomlDecodeError` to `TOMLDecodeError`
depending on what was imported.
* Open files in binary/text mode depending on what was imported.
try:
import tomllib as toml_module
toml_mode = "rb"
toml_exception = toml_module.TOMLDecodeError
except ImportError:
import toml as toml_module
toml_mode = "r"
toml_exception = toml_module.TomlDecodeError
with open(..., toml_mode) as f:
try:
_ = toml_module.load(f)
except toml_exception as e:
...
Example upstream PR: https://github.com/fedora-infra/fedora-messaging/pull/274
=== Migrating to tomli-w ===
* Change any `toml` requirements in upstream metadata to `tomli-w`.
* Change all `toml` imports to `tomli_w` imports.
* Open files in binary mode, if passing file objects to `tomli_w.dump()`.
A more complex example that migrates to `tomli`, `tomllib` and
`tomli-w`: https://github.com/rpm-software-management/rpmlint/pull/905
== Feedback ==
== Benefit to Fedora ==
An upstream dead package will not be depended upon by new packages.
== Scope ==
* Proposal owners: Deprecate `python3-toml`. Work with packagers and
upstream developers to remove the dependency. Monitor the remaining
dependent packages and eventually retire {{package|python-toml}}
(unlikely in Fedora 38).
* Other developers: No action needed. Don't add new dependencies on
`python3-toml`.
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The package will remain available. Only new packages cannot depend on it.
Once retired, we don't plan to provide python3-toml from
`python3-libs` or `python3-tomli`, because it cannot work as a drop-in
replacement (the Python module has a different name and slightly
different API). The package will eventually be obsoleted by
{{package|fedora-obsolete-packages}} once retired, but that is
unlikely to happen soon.
== How To Test ==
$ repoquery --repo=rawhide --provides python3-toml
...
deprecated()
...
== User Experience ==
No changes.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: revert the deprecation
* Contingency deadline: Final Freeze
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
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: SWIG 4.1.0 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/swig410 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 SWIG in Fedora to the latest version 4.1.0. New version should be released in [https://github.com/swig/swig/milestone/3 October 2nd 2022]. See [https://github.com/swig/swig/blob/master/CHANGES.current CHANGES.current] for more details about new release. == Owner == * Name: [[User:Jplesnik| Jitka Plesníková]] * Email: == Current status == * [https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/ Copr repository] with the latest version of SWIG 4.1.0 * [https://copr.fedorainfracloud.org/coprs/jplesnik/swig-rebuild/monitor/ Current status] of SWIG's dependencies * I checked the errors and reported them to SWIG upstream/package upstream/fedora maintainers. * Issues related to SWIG 4.1.0 ** [https://bugzilla.redhat.com/show_bug.cgi?id=2128029 COPASI BZ] - upstream fix ** [https://gitlab.com/graphviz/graphviz/-/issues/2277 graphviz] - related to PHP wrapper change ** [https://bugzilla.redhat.com/show_bug.cgi?id=2128661 kicad BZ] - upstream fix ** [https://bugzilla.redhat.com/show_bug.cgi?id=2127964 libCombine BZ] - upstream fix ** libkolabxml - related to PHP wrapper change ** [https://bugzilla.redhat.com/show_bug.cgi?id=2127978 libnuml BZ] - upstream fix ** [https://bugzilla.redhat.com/show_bug.cgi?id=2128592 libsbml BZ] - patch attached ** [https://bugzilla.redhat.com/show_bug.cgi?id=2127982 libsedml BZ] - upstream fix ** [https://bugzilla.redhat.com/show_bug.cgi?id=2128646 lldb BZ] - patch attached ** [https://github.com/mltframework/mlt/issues/820 mlt] - related to PHP wrapper change ** [https://bugzilla.redhat.com/show_bug.cgi?id=2128189 nordugrid-arc BZ] - patch attached ** [https://bugzilla.redhat.com/show_bug.cgi?id=2128024 subversion BZ] - upstream fix == Detailed Description == SWIG-4.1.0 summary: * Add PHP 8 support. * PHP wrapping is now done entirely via PHP's C API - no more .php wrapper. ** the change breaks build of graphviz, libkolabxml and mlt - it requires update of code and spec file to not install *.php files * Perl 5.8.0 is now the oldest version SWIG supports. * Python 3.3 is now the oldest Python 3 version SWIG supports. * Common cases of `<` and `>` comparisons in constant expressions are now supported. * The "XML" target language has been reclassified as "Experimental". == Benefit to Fedora == Provides the latest SWIG version to developers. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. * Other developers: N/A (not a System Wide Change) * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == The SWIG dependencies are monitored by Koschei, see the [https://koschei.fedoraproject.org/groups/swig Koschei SWIG group] == User Experience == Developers will have the benefit of using the latest SWIG version. == Dependencies == [https://jplesnik.fedorapeople.org/swig-4.1.0/swig-deps The list of packages] which are using SWIG for build. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No == Documentation == N/A (not a System Wide Change) == Release Notes == SWIG-4.1.0 summary: * Add PHP 8 support. * PHP wrapping is now done entirely via PHP's C API - no more .php wrapper. * Perl 5.8.0 is now the oldest version SWIG supports. * Python 3.3 is now the oldest Python 3 version SWIG supports. * Common cases of < and > comparisons in constant expressions are now supported. * The "XML" target language has been reclassified as "Experimental". -- 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: PHP 8.2 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/php82 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 PHP stack in Fedora to the latest version 8.2.x == Owner == * Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]] * Email: remi at fedoraproject dot org == Detailed Description == Update the PHP stack in Fedora to latest version 8.2.x. Fedora has a 6 months cycle, PHP a 1 year cycle, our common practice for some years: * 2 Fedora cycles for each PHP minor release (exceptions below) * 3 Fedora cycles for latest minor (e.g. 5.6 or 7.4) to give more time before next major * 1 Fedora cycle for first major (e.g. 7.0 or 8.0) == Benefit to Fedora == Provides the latest PHP version to developers and system administrators. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. Needed mass rebuild (C extensions) done by change owner. * Other developers: N/A (not a System Wide Change) * Release engineering: * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == * The PHP stack (extensions and libraries) are monitored by Koschei, see the [https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started Koschei PHP group] * install and play with your web applications == User Experience == Developers and system administrators will have the great benefit or running the latest PHP version. == Dependencies == All php-* packages (and some *-php) == Contingency Plan == * Contingency mechanism: Drop not compatible packages. Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A * Blocks product? == Documentation == * [https://raw.githubusercontent.com/php/php-src/PHP-8.2/UPGRADING UPGRADING] * [https://raw.githubusercontent.com/php/php-src/PHP-8.2/UPGRADING.INTERNALS UPGRADING.INTERNALS] == Release Notes == -- 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
Fedora Linux 37 Beta Released
The Fedora Project is pleased to announce the immediate availability of Fedora Linux 37 Beta, the next step towards our planned Fedora Linux 37 release at the end of October. Download the prerelease from our Get Fedora site: * Get Fedora 37 Beta Workstation: https://getfedora.org/workstation/download/ * Get Fedora 37 Beta Server: https://getfedora.org/server/download/ * Get Fedora 37 IoT: https://getfedora.org/iot/download/ Or, check out one of our popular variants, including KDE Plasma, Xfce, and other desktop environments: * Get Fedora 37 Beta Spins: https://spins.fedoraproject.org/prerelease * Get Fedora 37 Beta Labs: https://labs.fedoraproject.org/prerelease ## Beta Release Highlights # Gnome 43 # Retire ARMv7 # Python 3.11, Perl 5.36, Golang 1.19 # RPM content is now signed with IMA signatures For more details about the release, read the full announcement at * https://fedoramagazine.org/announcing-fedora-37-beta/ or look for the prerelease pages in the download sections at * https://getfedora.org/ Since this is a Beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the t...@lists.fedoraproject.org mailing list or in #fedora-qa on Libera Chat or the #qa:fedoraproject.org Matrix room. -- 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
Fedora Linux 37 Beta is GO
The Fedora Linux 37 Beta RC5 compose[1] is GO and will be shipped live on Tuesday, 13 September 2022. For more information please check the Go/No-Go meeting minutes[2] or logs[3]. Thank you to everyone who has and still is working on this release! The Final Freeze begins on Tuesday 4 October. [1] https://dl.fedoraproject.org/pub/alt/stage/37_Beta-1.5/ [2] https://meetbot.fedoraproject.org/fedora-meeting/2022-09-08/f37-beta-go_no_go-meeting.2022-09-08-17.00.html [3] https://meetbot.fedoraproject.org/fedora-meeting/2022-09-08/f37-beta-go_no_go-meeting.2022-09-08-17.00.log.html -- 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
Reminder: F37 Beta Go/No-Go Thursday
This is your reminder that the Fedora Linux 37 Beta Go/No-Go[1] meeting is scheduled for Thursday 8 September at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F37 Beta for the 13 September early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. For information on the current release candidate, see the test-announce post[4]. [1] https://calendar.fedoraproject.org/meeting/10321/ [2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting [4] https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org/thread/C5L2ATTWX3ALCF3SFDKCLMLNGSB6IKYC/ -- 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
F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
github repository is here - https://github.com/rpm-software-management/dnf5/ * Other developers: * 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: == Upgrade/compatibility impact == The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`, and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`, `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`. === Compatibility === The new DNF5 will provide a symlink to `/usr/bin/dnf` therefore users will see the replacement as an upgrade of DNF with limited but documented syntax changes. The DNF5 will provide some compatible aliases of commands and options to improve adoption of the DNF5. == How To Test == Install `dnf5` package from https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/ == User Experience == * Improved progress bars * Improved transaction table * Transaction progress reports including scriptlets reports * Support of local rpm for transaction operation * Great bash completion (better then DNF has) * New commands and options that are only available with `DNF` == Dependencies == There is a long list of dependent packages === dnf === auter calamares copr-builder cpanspec dnf-plugin-diff dnfdragora etckeeper-dnf fedora-review fedora-upgrade kiwi-systemdeps-core libdnf-plugin-subscription-manager lpf mock osbuild perl-CPAN-Plugin-Sysdeps policycoreutils-devel rbm subscription-manager supermin system-config-language === python3-dnf === anaconda-core dnf-plugin-ovl dnfdaemon fedora-easy-karma fedora-review lorax mock-core-configs module-build-service modulemd-tools needrestart pungi python3-bodhi-client python3-dnf-plugin-cow python3-dnf-plugin-flunk_dependent_remove python3-imgcreate python3-libreport retrace-server system-config-language === libdnf === PackageKit copr-builder gnome-software-rpm-ostree libdnf-plugin-subscription-manager libdnf-plugin-swidtags libdnf-plugin-txnupd === python3-hawkey === mock-core-configs modulemd-tools python3-rpmdeplint retrace-server == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) * Contingency deadline: * Blocks release? == Documentation == none == Release Notes == -- 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: Node.js Repackaging (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/NodejsRepackaging This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages. == Owner == * Name: [[User:SGallagh| Stephen Gallagher]] * Email: sgall...@redhat.com == Detailed Description == We will be creating the packages nodejs-16, nodejs-18 and (in April) nodejs-20. These packages will be parallel-installable (with the exception of the -devel subpackages) and provide `/usr/bin/node-$MAJOR`. We will also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed, the highest currently-installed version. Notes: * The default in Fedora 38 will be Node.js 18. If a user was to install Node.js 16 and Node.js 20, but not Node.js 18, then Node.js 20 would provide `/usr/bin/node` * The policy going forward will be to have the most recently-released version of Node.js at the time of Fedora's expected Beta release date be the default for that release throughout its lifetime. == Feedback == [https://lists.fedoraproject.org/archives/list/nod...@lists.fedoraproject.org/thread/NLZXYISZPBAU3VXLUZCYSJJ66YH4ALSG/ Mailing list thread] Neal Gompa raised the question of using a subpackage to own `/usr/bin/node` instead of using the `alternatives` subsystem, citing python as an example. My response was that the problem with this is that I want `/usr/bin/node` to always be available so long as any `nodejs-$MAJOR` version is installed. It also ensures that the `node(1)` manpage always matches the `/usr/bin/node` executable. == Benefit to Fedora == === User Benefits === * Provides a simple way to have a different (or multiple) Node.js interpreters on their system. No dealing with Modularity. * Enables multiple versions of Node.js on the system (can test code against different versions without using containers) === Packager Benefits === * No more modules to maintain. * Availability of multiple Node.js versions in the buildroot means that other `nodejs-*` packages can test against multiple supported options. == Scope == * Proposal owners: The packaging work is done and can be played with at https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ today. * Other developers: There should be no need to change any dependent packages, though packagers of Node.js software may wish to take advantage of the testing opportunities afforded. * Release engineering: * Policies and guidelines: We will be updating the Node.js Packaging Guidelines with the new best practices. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Systems using the existing nodejs RPM package will be upgraded to the matching `nodejs-$MAJOR` version. Work is pending on how to migrate users of Modular Node.js to the new packages. == How To Test == == User Experience == Done correctly, this should be handled entirely without the user's need to know about it. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == https://lists.fedoraproject.org/archives/list/nod...@lists.fedoraproject.org/thread/NLZXYISZPBAU3VXLUZCYSJJ66YH4ALSG/ == Release Notes == Multiple releases of Node.js may now be installed in parallel from the Fedora repositories. -- 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
Fedora Linux 37 Beta Go/No-Go meeting next week
Hi everyone, It's that time already! The Fedora Linux 37 Beta Go/No-Go[1] meeting is scheduled for Thursday 8 September at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F37 Beta for the 13 September early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10321/ [2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- 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: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
ures specifically is expected to trigger a topical distribution-wide crackdown on [https://eprint.iacr.org/2020/014 weak] cryptography, raising the security of the distribution moving forward. == Scope == * Proposal owners: implement changes described in Summary and Dependencies sections * Other developers: Test your applications with TEST-FEDORA39 policy. Move away from trusting SHA-1 signatures; ideally in time for F38 branch-off, for F39 release at the latest. Follow [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]: 1. move away from trusting SHA-1 signatures entirely, or 2. distrust them by default and require explicit user opt-in to use a workaround * Release engineering: Not sure if mass-rebuild is required if we land the change right after f38 branch-off. Maybe a "preview" mass-rebuild can be done with a special build in the F37 timeframe to cut down on F38 FTBFS. * Policies and guidelines: update needed CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default and provide guidance for openssl and gnutls. Components using workaround APIs must not use them without explicit user opt-in and must be added to a list of applications using a workaround API. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: not with Fedora 37-era ones == Upgrade/compatibility impact == See "User experience". Upgrade-time issues aren't specifically anticipated; if any were to arise, testing should find them in ''Fedora 38''-times, to be fixed by Fedora 39 release at the latest. Administrators willing to sacrifice security can apply LEGACY or FEDORA38 policies. == How To Test == === Testing actively === On a ''Fedora 38 rawhide'' system, install crypto-policies-scripts package and switch to a more restrictive policy with `update-crypto-policies --set TEST-FEDORA39`. Proceed to use the system as usual, identify the workflows which are broken by this change. Verify that the broken functionality works again if you the policy is relaxed back with, e.g., `update-crypto-policies --set TEST-FEDORA39:SHA1`, file bug reports against the affected components if not filed already. Please start your ticket title with `StrongCryptoSettings3: `, mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work. Especially brave souls can dare to try `update-crypto-policies --set FUTURE` instead, though this policy is more aggressive than the upcoming defaults. === Testing passively === On a ''Fedora 38 released'' system, install a special logging tool from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer Run it and proceed to use your system. Once the tool notifies you about about soon-to-be-blocked SHA-1 signature operations, identify the component and actions leading to these operations, verify that repeating them leads to logging more entries. Ideally also verify that switching to a stricter policy breaks the workflow. File bug reports against the affected components if not filed already. Please start your ticket title with `StrongCryptoSettings3: ` and link to this change page. == User Experience == Things will break. All kinds of things depending on SHA-1 signatures, openly and secretly. * On Fedora 36-37 they'll break opt-in. * '''On Fedora 38 rawhide they'll break by default.''' * '''On Fedora 38 released they'll behave like in Fedora 37.''' * On Fedora 39 they'll break by default again, including the released version. == Dependencies == A small coordinated change with openssl is required. In Fedora 38, openssl should start distrusting SHA-1 signatures when used with no configuration file. This does not affect the majority of scenarios, only applications that do not follow system-wide cryptographic policies. All reverse dependencies of core cryptographic libraries are affected, especially openssl ones relying on SHA-1 signatures. == Contingency Plan == * Contingency mechanism: not needed for F38, change will be reverted before Beta anyway * Contingency deadline: not needed for F38, change will be reverted before Beta anyway * Blocks release? No == Documentation == Workaround API should be added to [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]. Packaging guidelines should be modified accordingly. == Release Notes == To be done, similarly to https://pagure.io/fedora-docs/release-notes/issue/829 -- 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.fedoraproje
F39 proposal: libsoup 3: Part two (System-Wide Change proposal)
.x86_64 gamehub-0:0.16.3.2-5.fc37.x86_64 geany-plugins-geniuspaste-0:1.38-5.fc37.x86_64 geany-plugins-markdown-0:1.38-5.fc37.x86_64 geany-plugins-updatechecker-0:1.38-5.fc37.x86_64 geoclue2-0:2.6.0-3.fc37.x86_64 geocode-glib-0:3.26.4-1.fc37.x86_64 gfbgraph-0:0.2.5-2.fc37.x86_64 gnome-calculator-0:43~alpha-2.fc37.x86_64 gnome-games-0:40.0-3.fc36.x86_64 gnome-music-0:42.1-3.fc37.noarch gnome-software-0:43.beta-3.fc38.x86_64 gnome-video-arcade-0:0.8.8-13.fc37.x86_64 goodvibes-0:0.7.4-2.fc37.x86_64 grilo-0:0.3.15-2.fc38.x86_64 grilo-plugins-0:0.3.15-1.fc38.x86_64 gssdp-0:1.4.0.1-3.fc37.x86_64 gssdp-utils-0:1.4.0.1-3.fc37.x86_64 gupnp-0:1.4.3-3.fc37.x86_64 gupnp-tools-0:0.10.3-2.fc37.x86_64 homebank-0:5.5.6-2.fc37.x86_64 libabiword-1:3.0.5-4.fc37.x86_64 libchamplain-0:0.12.20-7.fc37.x86_64 libdmapsharing-0:2.9.41-8.fc37.x86_64 libdmapsharing4-0:3.9.10-6.fc37.x86_64 libepc-0:0.4.0-23.fc37.x86_64 libepc-ui-0:0.4.0-23.fc37.x86_64 libgda5-tools-1:5.2.10-12.fc38.x86_64 libgda5-web-1:5.2.10-12.fc38.x86_64 libgdata-0:0.18.1-6.fc37.x86_64 libgepub-0:0.6.0-10.fc37.x86_64 libgovirt-0:0.3.8-5.fc37.x86_64 libgrss-0:0.7.0-15.fc37.x86_64 libgweather-0:40.0-4.fc37.x86_64 libmateweather-0:1.26.0-3.fc37.x86_64 libsoup-devel-0:2.74.2-3.fc37.x86_64 libtimezonemap-0:0.4.5.2-1.fc38.x86_64 libtranslate-0:0.99-113.fc37.x86_64 liferea-1:1.13.9-1.fc37.x86_64 linphone-0:3.6.1-49.fc37.x86_64 logjam-1:4.6.2-28.fc37.x86_64 meteo-0:0.9.9.1-3.fc37.x86_64 midori-0:9.0-11.fc37.x86_64 mmsd-tng-0:1.9-2.fc37.x86_64 mpdscribble-0:0.22-25.fc37.x86_64 osinfo-db-tools-0:1.10.0-4.fc37.x86_64 osm-gps-map-0:1.1.0-11.fc37.x86_64 ostree-tests-0:2022.5-2.fc37.x86_64 perl-HTTP-Soup-0:0.01-28.fc37.x86_64 polari-0:42.1-2.fc37.x86_64 pragha-0:1.3.3-23.fc37.x86_64 purple-chime-0:1.4.1-7.fc37.x86_64 python3-nbxmpp-0:3.1.1-1.fc37.noarch remmina-0:1.4.27-5.fc37.x86_64 rest0.7-0:0.8.1-2.fc37.x86_64 rhythmbox-0:3.4.6-2.fc37.x86_64 rygel-0:0.40.4-2.fc37.x86_64 seahorse-0:42.0-2.fc37.x86_64 snapd-glib-0:1.58-5.fc37.x86_64 snapd-glib-tests-0:1.58-5.fc37.x86_64 snapd-qt-tests-0:1.58-5.fc37.x86_64 soup-sharp-0:2.42.2-7.20190810git0f36d10.fc37.x86_64 srain-0:1.4.0-3.fc37.x86_64 surf-0:2.0-14.fc37.x86_64 switchboard-plug-onlineaccounts-0:6.5.0-1.fc37.x86_64 taxi-0:2.0.1-3.fc37.x86_64 telepathy-gabble-0:0.18.4-19.fc37.x86_64 telepathy-salut-0:0.8.1-28.fc37.x86_64 uhttpmock-0:0.5.5-2.fc37.x86_64 vfrnav-0:20201231-30.fc37.x86_64 webkit2gtk4.0-0:2.37.90-1.fc38.x86_64 webkit2gtk4.0-devel-0:2.37.90-1.fc38.x86_64 xfce4-screenshooter-0:1.9.11-1.fc38.x86_64 xfce4-screenshooter-plugin-0:1.9.11-1.fc38.x86_64 xfce4-weather-plugin-0:0.11.0-4.fc37.x86_64 == Contingency Plan == * Contingency mechanism: restore libsoup 2 package * Contingency deadline: beta freeze * Blocks release? possibly, it will depend on which packages successfully make the transition == Documentation == [https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html Migrating from libsoup 2] == Release Notes == To-do -- 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
