devel-announce January 2025

devel-announce@lists.fedoraproject.org

6 participants
36 discussions

F42 Change Proposal: Replace cockpit-navigator with cockpit-files (self-contained)
by Aoife Moloney 15 Jan '25

15 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/Replace_Cockpit_Navigator_With_Cockp… Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-replace-cockpit-… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Obsolete cockpit-navigator for cockpit-files due to the availability of a modern, maintained file system browser for Cockpit. == Owner == * Name: [[User:jelly| Jelle van der Waa]] * Email: jvanderw(a)redhat.com == Detailed Description == Last year the Cockpit project released a new officially supported [https://cockpit-project.org/blog/first-cockpit-files-release.html Cockpit Files] plugin intended to provide a modern alternative to the existing [https://github.com/45Drives/cockpit-navigator Cockpit navigator] plugin. The latest release (14) supports everything which Cockpit navigator did except the creation of symlinks which is planned to be implemented. == Feedback == == Benefit to Fedora == Cockpit navigator users will be upgraded to Cockpit files which is actively developed, automated tested and maintained by the Cockpit team. == Scope == * Proposal owners: Add "Obsoletes: cockpit-navigator" to cockpit-files and retire cockpit-navigator. * 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 the Fedora Strategy: == Upgrade/compatibility impact == When upgrading to Fedora 42, systems with `cockpit-navigator` installed will be switched to `cockpit-files`. == How To Test == `cockpit-files` is available in Fedora 40 and higher. == User Experience == Replacing `cockpit-navigator` with `cockpit-files` leads to a visual change within Cockpit the `Navigator` menu entry will be replaced with a new `File browser` menu entry under Tools. The UI of `cockpit-files` is different from `cockpit-navigator` but offers the same functionality with the exception symlink creation. `cockpit-files` like Cockpit uses PatternFly as UI toolkit making the user experience more consistent. == 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 == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F42 Change Proposal: X86 MIPI camera HW-enablement (self-contained)
by Aoife Moloney 15 Jan '25

15 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/X86_MIPI_CameraHwEnablement Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-ibus-libpinyin-1… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Add support for more MIPI (non USB) cameras found on x86 laptops and tablets. == Owner == * Name: [[User:jwrdegoede| Hans de Goede]] * Email: hdegoede(a)redhat.com == Detailed Description == The [[Changes/IPU6_Camera_support | initial IPU6 camera support]] landed in Fedora 41 only works on a limited set of laptops. The reason for this is that with MIPI cameras every different sensor and glue-chip like IO-expanders needs to be supported separately. This change is about the ongoing work to get the camera working on more laptop models. This is being tracked on a per sensor and/or laptop-model basis. Currently the following issues are being either actively being worked on, or are being tracked to be fixed in the future: * [https://bugzilla.redhat.com/show_bug.cgi?id=2333385 IPU6 camera on TERRA PAD 1262 V2 not working], fix has been [https://git.linuxtv.org/sailus/media_tree.git/commit/?h=devel&id=fa3772f390… accepted upstream]. * [https://bugzilla.redhat.com/show_bug.cgi?id=2333347 IPU6 camera on Dell XPS 9x40 models with ov02c10 sensor not working], sensor driver has been [https://lore.kernel.org/linux-media/20241219175128.40871-1-heimir.sverrisso… submitted upstream]. * [https://bugzilla.redhat.com/show_bug.cgi?id=2332997 IPU6 camera on Dell Latitude 7450 laptop not working] * [https://bugzilla.redhat.com/show_bug.cgi?id=2333331 IPU6 camera on HP Spectre x360 14-eu0xxx / Spectre 16 MeteorLake with ov08x40 not working ] * [https://bugzilla.redhat.com/show_bug.cgi?id=2333647 IPU6 camera on HP Spectre x360 2-in-1 16-f1xxx/891D with hi556 sensor not working] * [https://bugzilla.redhat.com/show_bug.cgi?id=2333387 IPU6 camera on Lenovo ThinkPad X1 Carbon Gen 12 not working] * [https://bugzilla.redhat.com/show_bug.cgi?id=2333299 Lattice MIPI Aggregator support for IPU6 cameras] * [https://bugzilla.redhat.com/show_bug.cgi?id=2333383 Lunar Lake MIPI camera / IPU7 CSI receiver support] * [https://bugzilla.redhat.com/show_bug.cgi?id=2337593 ov01a10 camera sensor driver lacks 1296x816 mode support] * [https://bugzilla.redhat.com/show_bug.cgi?id=2337595 No driver for ov01a1s camera sensor] * [https://bugzilla.redhat.com/show_bug.cgi?id=2316918 iVSC fails to probe with ETIMEDOUT] * [https://bugzilla.redhat.com/show_bug.cgi?id=2324683 iVSC fails to probe with EINVAL on XPS 9315] == Feedback == == Benefit to Fedora == Currently on many new laptop models the camera does not work OOTB in Fedora, the goal of this change is to get the camera to work OOTB on more laptop models. == Scope == * Proposal owners: ** This mainly requires kernel changes, most of this work is being done upstream. Depending on the timing some changes accepted upstream may be backported to the Fedora kernel used for the Fedora 42 release. ** Some libcamera changes may be necessary * Other developers: N/A (not a System Wide Change) * 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 the Fedora Strategy: Yes (better hw-support should help getting more users) == Upgrade/compatibility impact == Since the improvements will be part of the kernel and libcamera all users will get these as part of the Fedora 42 upgrade. == How To Test == * See [[IPU6_Camera_support#How_To_Test]] * If things do not work please file a bug: ** Before gathering information, please enable some extra debugging by running: *** `sudo grubby --update-kernel=ALL --args="intel_skl_int3472_discrete.dyndbg"` ** Reboot so that the new kernel commandline takes effect ** Run the following commands to gather information: *** `journalctl -b 0 -k > kernel.txt` *** `lsusb > lsusb.txt` *** `ls -l /sys/bus/i2c/devices/ > i2c-devices.txt` *** `ls -l /sys/bus/spi/devices/ > spi-devices.txt` ** File a bug in [https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=kernel bugzilla] ** Attach all the generated "*.txt" files to the bug == User Experience == The camera on X86 laptops with MIPI cameras should work OOTB on more laptop models. == Dependencies == None == Contingency Plan == ATM IPU6 cameras do not work at all on many laptop models. Except for the changes actually causing regressions no contingency plan is necessary. As always with kernel changes any known regressions will be fixes ASAP or the change causing the regression will be reverted. == Documentation == N/A (not a System Wide Change) == Release Notes == To be written... -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F42 Change Proposal: Promote KDE Plasma Desktop variant to Edition (self-contained)
by Aoife Moloney 15 Jan '25

15 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/Promote_KDE_Plasma_Desktop_variant_t… Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-ibus-libpinyin-1… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This Change is about promoting the Fedora KDE Desktop deliverables to Edition status. == Owner == * Name: [[User:Ngompa| Neal Gompa]], [[User:Dcavalca| Davide Cavalca]], [[User:Carlschwan| Carl Schwan]], [[User:Marcdeop| Marc Deop]], [[User:Tdawson| Troy Dawson]], [[User:Farchord| Steve Cossette]] * Email: ngompa13(a)gmail.com, davide(a)cavalca.name, carl(a)carlschwan.eu, marcdeop(a)fedoraproject.org, tdawson(a)redhat.com, farchord(a)gmail.com == Detailed Description == As [https://pagure.io/Fedora-Council/tickets/issue/504 approved by Fedora Council], this promotes the Fedora KDE Plasma Desktop variant to full Edition status. As the variant is already release-blocking, this is mainly a change for adjusting how the KDE Desktop variant is presented and promoted. We have identified the following focus areas to market the KDE Plasma Desktop Edition: * Multimedia enthusiasts (AV and gaming particularly see: [https://invent.kde.org/plasma/kwin/-/merge_requests/718 VRR on Wayland] or [https://invent.kde.org/plasma/kwin/-/merge_requests/662 DRM Leasing]) * Content [https://kde.org/for/creators/ creators] (aligning with KDE/Qt software in this space such as Kdenlive, Krita, and [https://obsproject.com/ OBS Studio]) * Accessibility (aligning with upstream work to make the Linux desktop friendlier to folks of various impairments such as [color]blindness, limited dexterity, and limited motor control) * Personalization (aligning with KDE Plasma features for customizing the desktop experience) The details of how this will be done are in the process of being fleshed out. == Feedback == == Benefit to Fedora == This makes Fedora stand out among the major Linux distributions by promoting the KDE Plasma Desktop as a flagship experience and signals a strong commitment to the KDE community by rewarding the current success of the Fedora KDE community and supporting its continued growth. == Scope == * Proposal owners: ** Split KDE Desktop variant out of Spins section in pungi-fedora ** Work with websites team to introduce KDE Plasma Desktop Edition information on the main site ** Bring online initial Personal Systems WG documentation site * Other developers: N/A (not needed for this Change) * Release engineering: [https://pagure.io/releng/issue/12533 #12533] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: Done. * Alignment with the Fedora Strategy: Yes ** This aligns with broadening our success with Editions (Fedora.next) and establishing a story around Fedora KDE to market more broadly. == Upgrade/compatibility impact == None. This is mainly a marketing change. == How To Test == Nothing to test as this is mainly a marketing change. == User Experience == The main change will be the Fedora website showing the KDE Plasma Desktop Edition alongside Workstation and others. == Dependencies == N/A. == Contingency Plan == * Contingency mechanism: Defer to next release * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora Linux 42 promotes the Fedora KDE Plasma Desktop variant to full Edition status. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 1

F42 Change Proposal: Plymouth: Use simpledrm by default (self-contained)
by Aoife Moloney 15 Jan '25

15 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-ibus-libpinyin-1… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Make plymouth use the simpledrm kernel mode setting (kms) device by default instead of waiting for the GPU driver to initialize. == Owner == * Name: [[User:jwrdegoede| Hans de Goede]] * Email: hdegoede(a)redhat.com == Detailed Description == GPU drivers can take a long time to load and probe all the connectors on some machines, causing plymouth to timeout after waiting 8 seconds and falling back to the ugly text splashscreen instead. Also see [https://hansdegoede.dreamwidth.org/28552.html this blogpost] On UEFI systems the EFI framebuffer will become available as simpledrm kms device much earlier during boot. Plymouth defaults to [https://gitlab.freedesktop.org/plymouth/plymouth/-/commit/83b385061ccbf5a46… ignoring simpledrm kms devices] for 2 reasons: # These kms devices [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/d… lack panel rotation information] # These kms devices [https://gitlab.freedesktop.org/plymouth/plymouth/-/commit/01702de71a93d9a0a… lack physical size information] Both of these issues have been fixed now (click on the issues to see the fixes). Since both issues have been fixed now we can switch to using the simpledrm kms device by default, showing the splash earlier instead of letting the user look at a static screen and avoiding the issue of the textmode fallback if the GPU driver takes a long time to initialize. Using simpledrm may lead to some changes in the splash appearance: # With simpledrm plymouth will fallback to [https://gitlab.freedesktop.org/plymouth/plymouth/-/commit/01702de71a93d9a0a… heuristics] on the resolution instead of DPI info to decide whether or not to use hidpi (e.g. 2x size) rendering. This may result in a different scaling factor for some setups, but I do not expect this really to be an issue. # On old UEFI systems the efifb will not come up in native mode, but rather in 800x600 or 1024x768. This will lead to a pretty significant discontinuity in the boot experience when switching from say 800x600 to 1920x1080 while plymouth was already showing the spinner at 800x600. # On systems where a full modeset is done the monitor going briefly black from the modeset will move from being just before plymouth starts to the switch from simpledrm drm to the real driver. This change is only about changing the default, it will still be possible to switch plymouth back to ignoring simpledrm kms devices for systems where using the simpledrm kms device leads to a significantly worse boot experience. == Feedback ==  == Benefit to Fedora == On UEFI systems this will improve the boot experience in 2 ways: # This avoids the textmode fallback if the GPU driver takes a long time to initialize. # This shows the splash earlier instead of letting the user look at a static screen == Scope == * Proposal owners: Write and upstream a plymouth patch to make ignoring simpledrm kms devices configurable from the plymouth config file and modify Fedora's config to not ignore it. * Other developers: N/A (not needed for this Change) * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Yes (cleaner boot should help getting more users) == Upgrade/compatibility impact == New and updated systems will automatically switch to the new default. This can be overridden by the user if desired. == How To Test == Users can already test this with Fedora 41 on any hardware which has a video output connected. First boot the system once without any changes and take a good look at the boot splash (Fedora logo with spinner below it) looks. Now enable the planned Fedora 42 behavior by passing "plymouth.use-simpledrm" to the kernel commandline. This can be done by running the following command: `sudo grubby --update-kernel=ALL --args="plymouth.use-simpledrm"` After this reboot and take a good look at the boot splash (Fedora logo with spinner below it). If anything looks off which was not there before please report this. == Dependencies == None == Contingency Plan == Flip plymouth's default back to ignoring simpedrm kms devices. == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F42 Change Proposal: Idris 2 (self-contained)
by Aoife Moloney 15 Jan '25

15 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/Idris2 Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-ibus-libpinyin-1… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Idris 2 is a dependently typed practical functional programming language. == Owner == * Name: [[User:Petersen| Jens Petersen]] * Email: <petersen(a)redhat.com> == Detailed Description == [https://www.idris-lang.org/ Idris] is a dependently typed functional programming language with first-class types. Idris 1 (written in Haskell) has been [https://src.fedoraproject.org/rpms/idris included] in Fedora for many years, but is no longer maintained and increasingly hard to build with newer GHC versions. Idris 2 is a complete rewrite on top of a Scheme compiler (either [https://src.fedoraproject.org/rpms/chez-scheme chez-scheme] (preferred and added to Fedora for F41) or [https://src.fedoraproject.org/rpms/racket racket]), which replaced idris-1. == Feedback == == Benefit to Fedora == Continue to provide an easy way to install the Idris programming language. == Scope == * Proposal owners: ** complete the package review of idris2 ([https://bugzilla.redhat.com/show_bug.cgi?id=2314358 review]) ** build idris2 for Fedora == Upgrade/compatibility impact == If idris-1 can no longer build with [[Changes/Haskell_GHC_9.8_and_Stackage_23]] then idris2 can obsolete it. == How To Test == * install idris2 * try examples from [https://www.idris-lang.org/pages/example.html tutorial] etc == User Experience == Users will be able to use the latest major version of the Idris programming language easily. == 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://www.idris-lang.org/pages/documentation.html * https://idris2.readthedocs.io/en/latest/ == Release Notes == * idris2 has been added to Fedora -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F42 Change Proposal: ibus-libpinyin 1.16 (self-contained)
by Aoife Moloney 15 Jan '25

15 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/ibus-libpinyin_1.16 Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-ibus-libpinyin-1… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The ibus-libpinyin 1.16 package provides some more features for the pinyin users. == Owner == * Name: [[User:Pwu|Peng Wu]] * Email: pwu(a)redhat.com == Detailed Description == The ibus-libpinyin 1.16 package provides several features. Here are the list of the features: # Support punctuation candidates # Support custom keyboard layout option # Support [ ] keys for candidate page up/down # Display Lua converters in the input method menu # Notify user when import pinyin or table file finished == Feedback == == Benefit to Fedora == These features will improve the user experience when using the pinyin input method. == Scope == * Proposal owners: libpinyin 2.10 and ibus-libpinyin 1.16 * 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 the Fedora Strategy: == Upgrade/compatibility impact == == How To Test == For these features in ibus-libpinyin 1.16, please test the following options: # Change the Keyboard Layout option to check whether it takes effects. # Enable the [ ] flip page option to check whether it takes effects. == User Experience == The ibus-libpinyin 1.16 will provide more convenient features for users. == 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 == The ibus-libpinyin 1.16 package provides some convenient features for the pinyin users. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F42 Change Proposal: Ibus 1.5.32 (self-contained)
by Aoife Moloney 15 Jan '25

15 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/IBus_1.5.32 Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-ibus-1-5-32-self… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == IBus 1.5.32 will support the Wayland input-method protocol version 2. == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * IBus now supports the Wayland input-method protocol version 2 which is allowed by some Wayland desktop sessions likes Sway, Hyprland, COSMIC desktop sessions. * IBus now can show the candidate popup for non-Wayland applications of XIM and GTK2 in the Wayland desktop sessions. * `ibus start` command is now enhanced to work for the Wayland input-method protocol version 2. == Feedback == * https://github.com/ibus/ibus/issues/2182 == Benefit to Fedora == This change will provide the input-method features in some Wayland desktop environments likes Sway, Hyprland, COSMIC desktop environments. == Scope == * Proposal owners: ibus 1.5.32 * 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 the Fedora Strategy: == Upgrade/compatibility impact == == Early Testing (Optional) == == How To Test == === Start IBus === 1. Log into a Wayland desktop session which allows the Wayland input-method protocol version 2 likes Sway, Hyprland, COSMIC desktop sessions. 2. Run an input-method protocol 2 application likes foot (You should not export GTK_IM_MODULE or QT_IM_MODULE.) 2. Run `ibus start --type wayland` option === Wayland supported aplications (You should not export GTK_IM_MODULE or QT_IM_MODULE.) === 1. Run foot, ptyxis or konsole === XIM application with the Wayland input-method protocol version 2 === 1. Run `env XMODIFIERS=@im=ibus xterm` === GTK2 application with the Wayland input-method protocol version 2 === 1. Run `env GTK_IM_MODULE=ibus foo` == User Experience == `ibus start` command is a brief tool for users to start the IBus input-method framework and `ibus start --help` command shows the help messages. == Dependencies == IBus panel needs the waybar in Sway desktop environment since the default swaybar does not support StatusNotifier. == Contingency Plan == * Contingency mechanism: Revert the change to ibus. * Contingency deadline: Beta release * Blocks release? No == Documentation == https://desktopi18n.wordpress.com/2025/01/13/ibus-1-5-32-plan/ == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F42 Change Proposal: Haskell GHC 9.8 and Stackage 23 (self-contained)
by Aoife Moloney 15 Jan '25

15 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/Haskell_GHC_9.8_and_Stackage_23 Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-haskell-ghc-9-8-… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the GHC Haskell compiler from major version 9.6 to 9.8 and Haskell packages from Stackage LTS 22 to LTS 23 versions. == Owner == * Name: [[User:Petersen|Jens Petersen]] * Email: <petersen(a)redhat.com> == Detailed Description == For Fedora 42, the main [https://www.haskell.org/ghc/ GHC] Haskell compiler package will be updated from version [https://www.haskell.org/ghc/download_ghc_9_6_6.html 9.6.6] to the latest stable [https://www.haskell.org/ghc/download_ghc_9_8_4.html 9.8.4] release (rebasing the [https://src.fedoraproject.org/rpms/ghc/ ghc] package from the [https://src.fedoraproject.org/rpms/ghc9.8/ ghc9.8] package). Along with this, Haskell packages in [https://www.stackage.org Stackage] (the stable Haskell source package distribution) will be updated from the versions in [https://www.stackage.org/lts-22 LTS 22] to latest [https://www.stackage.org/lts-23 LTS 23] release. Haskell packages not in Stackage will be updated to the latest appropriate version in the upstream [https://hackage.haskell.org Hackage] package repository. == Feedback == == Benefit to Fedora == Fedora users will have the latest stable Haskell compiler release, package tools, and current Haskell packages from latest Stackage LTS. GHC 9.8.4 is the latest current stable version of GHC with various enhancements and fixes (see the release notes linked in the Documentation section for more details about new features and improvements in 9.8). == Scope == * Proposal owners: ** update rawhide ghc9.6 is build against itself ** rebase ghc to 9.8.4 and obsolete ghc9.8 ** refresh packagings with the latest cabal-rpm release ** update packages to latest [https://www.stackage.org/lts-23 Stackage LTS 23] versions using cabal-rpm ** build all the packages in a Koji sidetag repo in dependency order using fbrnch ** push the sidetag through Bodhi to rawhide ** obsolete deprecated packages ** check that hedgewars server still builds * Other developers: no actions should be needed * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: will check if any refresh needed for Haskell Packaging policy * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == Any dropped packages will have obsoletes added. Otherwise there should not be any direct upgrade impact. User's own Haskell projects might need some minor code tweaks in order to rebuild (see the release notes linked below). == Early Testing (Optional) == == How To Test == * install ghc and cabal-install * install pandoc, ShellCheck, ghcid, git-annex, hadolint, stack, xmonad, Agda * install ghc-*-devel or ghc-*-prof or ghc-*-doc * cabal-rpm builddep <favouritepackage>; cabal install <favouritepackage> * install ghc8.10, ghc9.0, ghc9.2, ghc9.4, ghc9.6, or ghc*devel * test upgrades of F41 Haskell packages to F42 == User Experience == Users will have the current stable major version of `ghc` and Haskell tools and libraries available to them. This makes it easier to build the latest versions of Haskell projects. In particular `pandoc` will be updated to 3.6, and `stack` to 3.1. == Dependencies == == Contingency Plan == * Contingency mechanism: Change owner will drop the new builds and revert dist-git back to the versions in F41 * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * https://downloads.haskell.org/~ghc/9.8.4/docs/users_guide/9.8.1-notes.html * https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.8 == Release Notes == GHC has been updated to major version 9.8 and Haskell packages to Stackage LTS 23 versions. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F42 Change Proposal: Switch to EROFS for Live Media (self-contained)
by Aoife Moloney 15 Jan '25

15 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/EROFSforLiveMedia Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-switch-to-erofs-… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Switch the read-only filesystem image format from SquashFS to EROFS for Fedora live media. == Owner = * Name: [[User:Ngompa| Neal Gompa]] for kiwi produced media * Email: ngompa13(a)gmail.com * Name: [[User:Dustymabe| Dusty Mabe]] for CoreOS produced media * Email: dusty(a)dustymabe.com == Detailed Description == In recent years, there has been increasing adoption of a new, more advanced read-only filesystem for a variety of use-cases called the [https://erofs.docs.kernel.org/en/latest/ Enhanced Read-Only FileSystem (EROFS)]. Support for EROFS as the backing read-only filesystem for live environments was introduced in Dracut v103. This change switches over the following live media to use EROFS instead of SquashFS: * all kiwi-produced live media. Currently: ** KDE Desktop ** KDE Mobile ** LXQt ** MiracleWM ** COSMIC ** Xfce ** Budgie * Fedora CoreOS Live media ** i.e. fedora-coreos-42.2025XXXX.91.0-live-iso.x86_64.iso Note: When future editions/spins get moved to kiwi they will inherit this change. == Feedback == == Benefit to Fedora == EROFS is considerably more actively developed than SquashFS, and offers more modern file system features that can be utilized in the future. == Scope == * Proposal owners: ** Kiwi: Merge [https://pagure.io/fedora-kiwi-descriptions/pull-request/105 fedora-kiwi-descriptions#105] ** CoreOS: Implement [https://github.com/coreos/fedora-coreos-tracker/issues/1852 fedora-coreos-tracker#1852]. This will require work in OSBuild, since OSBuild builds the Fedora CoreOS Live ISO now. * Other developers: * Release engineering: [https://pagure.io/releng/issue/12520 #12520] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: N/A (not needed for this Change) == Upgrade/compatibility impact == There should be no visible impact. This only affects live media used to make fresh installations. == How To Test == Once the change is applied, users can grab nightly Fedora live images that fall in scope (such as the KDE and LXQt images) to test it. Simply booting the images in a VM and installing the environment is a sufficient test. For Fedora CoreOS, nightly [https://builds.coreos.fedoraproject.org/browser?stream=rawhide&arch=x86_64 rawhide installation media] can be used to perform an [https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/#_installing_… install]. == User Experience == There should be no visible impact to users. Live installations continue to work as expected, and live environments may be slightly faster. == Dependencies == N/A. Everything has been in place and supported since Fedora Linux 41. == Contingency Plan == * Contingency mechanism: Revert back to SquashFS. * Contingency deadline: Final Freeze. * Blocks release? Yes. == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora Linux live environments now use the Enhanced Read-Only FileSystem (EROFS), a modern, feature-rich read-only filesystem. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F42 Change Proposal: Improve edk2 security (self-contained)
by Aoife Moloney 15 Jan '25

15 Jan '25

Wiki - https://fedoraproject.org/wiki/Changes/Edk2Security Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-improve-edk2-sec… This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Turn on a few security-related build time options to improve edk2 security. == Owner == * Name: [[User:kraxel| Gerd Hoffmann]] * Email: kraxel(a)redhat.com == Detailed Description == === Turn on strict NX checking === PcdDxeNxMemoryProtectionPolicy = 0xC000000000007FD5 PcdSetNxForStack = TRUE PcdImageProtectionPolicy = 0x03 This will partly enforce the NX requirements for secure boot binaries which are in place since 2022, see https://techcommunity.microsoft.com/blog/hardwaredevcenter/updated-uefi-sig… === Unmap zero page === PcdNullPointerDetectionPropert yMask = 0x03 This will catch NULL pointer dereferences. === edk2 documentation === Detailed description of these PCDs (aka edk2 config options) is here: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/MdeModulePkg.dec === some background information === The big linux NX mess (https://www.kraxel.org/blog/2023/12/uefi-nx-linux-boot/) was finally sorted roughly one year ago, so linux kernels and boot loaders released in 2024 should work without any problems with the new firmware builds. Given we had security updates due to a bug in shim versions older than 15.8 all linux distros which are supplied with (security) updates still should have package updates released for shim + grub in 2024. So fully updated linux installs should continue to work fine even with the NX bar raised. Same applies to fully updated windows installs. The changes will be applied to the edk2 builds which have secure boot support enabled. Using secure boot on a system which is not fully updated is not very useful from a security point of view. Trying to run outdated boot loaders which are not NX clean might lead to page faults like this: !!!! X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - 00000000 !!!! === backward compatibility === The edk2 builds without secure boot support will NOT be changed and will continue to use the less strict configuration which is used in fedora 41 and older for better compatibility with old guests. So if there is a need to run outdated guests this is possible by picking these firmware builds. The libvirt xml for this is: <os firmware='efi'> <type arch='x86_64' machine='q35'>hvm</type> <firmware> <feature enabled='no' name='secure-boot'/> </firmware> </os> == Feedback == == Benefit to Fedora == Improves security of UEFI virtual machines. == Scope == * Proposal owners: ** Update edk2 build configuration accordingly. * 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 the Fedora Strategy: == Upgrade/compatibility impact == For the most part this should be an unnoticed change. Running outdated guests might require a VM config update, see https://fedoraproject.org/wiki/Changes/Edk2Security#backward_compatibility == Early Testing (Optional) == == How To Test == Test builds are available from https://copr.fedorainfracloud.org/coprs/kraxel/edk2.testbuilds/ == 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) == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce January 2025