-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 You may have noticed that the ports repository has been frozen for nearly 24 hours now, at the time of writing. Our statement regarding the situation and next steps follows. A 150MB binary file was recently committed to the ports tree and, as a result, core@ made the decision to implement a temporary freeze of the ports tree in order to implement some clean up efforts. The commit in question severed our ports tree mirroring to github.com due to their filesize hard limit of 100MB, and introduced a blob of questionable licensing into the repository history. Given the importance of github.com mirroring to our community, we are actively taking steps to remove the offending commits and restore mirroring to the external services. There is no concern that the ports tree has been compromised. The freeze was entirely intended to limit the number of commits that will need to be re-written in order to issue a corrected state. It is important to us that we provide a reproducible and sustainable path for correcting this issue for the community and downstream consumers. As you're well-aware, correcting issues of this nature is not always as straightforward as desired. We are actively working on producing instructions which existing checkouts will need to follow to catch up with these corrections. To provide total transparency, we will also provide a procedure for verifying that the official repository changes enacted are limited to exactly the scope that we claim. We are also implementing server-side hooks to prevent this from happening in the future. Please stay tuned for additional updates from us, and thank you for your time. Thanks, Kyle Evans (on behalf of core@) -----BEGIN PGP SIGNATURE----- iJEEARYKADkWIQTOLDfUSTVFb0n/Wd5KG8EPLdVqEwUCamEskBsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDMACgkQShvBDy3VahPO5wEA+60GiOYCdejKOVJzCr5J fzuEQJxkWt/faQAsa9QlMI8BAMKuUIyRmCqFH99hcoPa4TgvABN3O99J9Mse5U/g chUI =QS8j -----END PGP SIGNATURE----- A copy of this message is available independently for verification at: https://people.freebsd.org/~kevans/core/ports-freeze-20260722.txt.asc
Wednesday, July 22, 2026
F46 Change Proposal: Changes Discussion Only On Devel List
Wiki - https://fedoraproject.org/wiki/Changes/ChangesDiscussionOnlyOnDevelList Discussion thread - https://discussion.fedoraproject.org/t/f46-change-proposal-changes-discussion-only-on-devel-list/197431 == Summary == Starting with Fedora Linux 46, discussion of Fedora Changes as part of the [https://docs.fedoraproject.org/en-US/operations/pgm%20guide/changes/ Changes Process] will happen solely on the devel mailing list and will no longer be simultaneously discussed on Fedora Discussion (the Discourse forum). Changes will continue to be announced on Discourse in read-only topics to provide a bridge between the two platforms. This Change aims to improve communication by avoiding having two separate mediums for the same discussion. == Owner == * Name: [[User:gotmax23| Maxwell G]], [[User:ngompa| Neal Gompa]], [[User:decathorpe| Fabio Valentini]], [[User:salimma | Michel Lind]] * Email: maxwell@gtmx.me, ngompa13@gmail.com, decathorpe@gmail.com, michel@michel-slm.name == Detailed Description == Starting with Fedora Linux 46, discussion of Fedora Changes as part of the [https://docs.fedoraproject.org/en-US/operations/pgm%20guide/changes/ Changes Process] will happen solely on the devel mailing list and will no longer be simultaneously discussed on Fedora Discussion (the Discourse forum). Changes will be announced on Discourse in read-only topics with links to the wiki page and devel discussion for each Change to provide a lightweight bridge between the two platforms. This Change aims to improve communication by avoiding having two separate mediums for the same discussion. The current "split brain" approach has been a significant pain point for Change Owners, FESCo members, and other project contributors attempting to follow Changes feedback discussion. Contributors have noted this as a cause of burnout. If technically feasible to use on read-only Discourse threads, we will keep the bot enabled that creates non-binding polls ("How do you feel about the proposal as written?") to collect community feedback on Changes. We will also adapt the bot to disable the anonymous results option on the Discourse polls so individual voices are better heard. FESCo will consider the polls alongside feedback on the devel list when voting on proposed Changes. == Feedback == There was some pre-Change discussion in "[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q7KX3BDBUPCNOPVALP5GKR2MHTWB6ASD/ How can we improve the Changes Process?]" ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VPQXOLZV3NVUOVTF4VCUEZU2BEFCQVQ5/ Maxwell's summary/takeaways]) on the devel list. This discussion was covered by LWN in [https://lwn.net/Articles/1081557/#:~:text=Changes%20to%20changes Fedora grapples with change § Changes to changes]. Additional feedback was provided in a [https://matrix.to/#/!DMptnKvPTdgoULzUTV:fedoraproject.org/$MuM8JzFoXojgU1x1LJMUO1Vn6kqOzTOjxSaLwqdjvdw?via=fedoraproject.org&via=fedora.im&via=matrix.org&web-instance%5Belement.io%5D%3Dchat.fedoraproject.org discussion in the #devel room on Matrix]. Feedback about Changes Discussion on Discourse was largely negative. Multiple contributors expressed that the current state of Changes discussion led to burnout. '''Q/A:''' * Why not just use Discourse for all Change Proposals and stop discussing them on the mailing list? ** The Change Owners do not wish to alienate or exclude existing contributors who rely on the mailing list workflow to participate in discussion. Other Fedora development discussion takes place on the devel mailing list, so it does not make sense to migrate only Changes discussion. Additionally, we believe that Discourse is an ill-suited platform for long, threaded discussions surrounding Fedora Changes. This position was discussed in more depth in the Matrix and devel list discussions linked above. * What about the email interface for Discourse? ** The email interface for Discourse is not comparable to a mailing list, and it de-prioritizes email users. The Discourse email support delays sending email notifications, makes formatting look out of place on responses sent via email, and email users miss out on reactions and other types of engagement. The ability to reply by email does not solve the issues with Discourse as a platform. == Benefit to Fedora == This Change aims to address a significant pain point in discussion of Fedora Changes. This should also simplify the Change Wrangler's work. == Scope == * Proposal owners: ** Update documentation and FESCo issue templates to clarify that the devel mailing list is the canonical medium for Changes discussion. ** Work with the Change Wrangler to implement the necessary process changes. * Other developers: ** Change wrangler: Announce Changes as usual on the devel-announce list. Stop copying and formatting Changes Proposal wikitext to/for Discourse. Create read-only posts on Discourse with links to the Wiki post and lists.fedoraproject.org discussion thread for each Change. ** Implement the proposed Changes to the Discourse voting poll creation bot. If these Changes are infeasible, disable the bot. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/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 == == User Experience == Users, contributors, Change Owners, and FESCo members will all have one less place to follow for discussion about proposed Fedora Changes. Changes will continue to be announced on Fedora Discussion, and anyone currently subscribed via Discourse can follow links to the corresponding thread on lists.fedoraproject.org, which provides a lightweight web interface (Hyperkitty) to respond to list threads. Additionally, we will no longer post misformatted Change proposal texts on Fedora Discussion, instead providing a link to the canonical proposal on the Fedora Wiki. If technically feasible, the community feedback straw polls will remain enabled on Discourse. == 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 -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
F46 Change Proposal: Deprecate low-memory-monitor package (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/DropLowMemoryMonitorFromDefaultInstallation Discussion thread - https://discussion.fedoraproject.org/t/f46-change-proposal-deprecate-low-memory-monitor-package-system-wide/197427 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 == Modern GLib (GMemoryMonitor) introduces memory monitor backends that run independently without relying on an external daemon to send low-memory signals to applications. Previously, low-memory-daemon was the sole provider of these events. Since GLib no longer requires low-memory-monitor to deliver these notifications and it is an archived project, low-memory-monitor can be deprecated. == Owner == * Name: [[smallorange| Kate Hsuan]] * Email: hpa@redhat.com == Detailed Description == With the introduction of native GMemoryMonitor backends [1-2] in GLib (including Linux kernel Pressure Stall Information (PSI) monitoring and a fallback polling mechanism), GLib can now monitor local memory usage directly. Previously, applications relied on an external background service, low-memory-monitor, via D-Bus to receive low-memory signals. The new Linux PSI backend actively monitors kernel-level resource pressure and emits signals to GMemoryMonitor subscribers when memory limits are reached. If PSI is disabled or unavailable, the fallback backend polls system memory metrics directly. Because GMemoryMonitor no longer requires a dedicated external daemon to function, low-memory-monitor can be deprecated. However, GLib retains the legacy D-Bus backend for low-memory-monitor to ensure backward compatibility with older distributions. [1] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4481 [2] https://systemd.io/PRESSURE/ == Feedback == See https://systemd.io/PRESSURE/ == Benefit to Fedora == Since GMemoryMonitor can run without an external service, low-memory-monitor can be deprecated. The runtime usage is reduced by stopping running low-memory-monitor. == Scope == * Proposal owners: Kate Hsuan * Other developers: * Release engineering: [https://forge.fedoraproject.org/releng/tickets/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 == Glib2 manages all the dependencies and GMemoryMonitor runs independently, so upgrade/compatibility won't be impacted. == Early Testing (Optional) == == How To Test == 1. Make a test code from the example code mentioned in the documents [1].<br> 2. Compile and run the test program in a memory-limited system.<br> 3. Stree the memory until the signal is emitted.<br> [1] https://docs.gtk.org/gio/iface.MemoryMonitor.html == User Experience == == 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) Bring back the low-memory-monitor package since the Dbus backend of GMemoryMonitor is still there. == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: Web Based Remote Installation Support for Atomic Desktops (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Web_Based_Remote_Installation_Support_For_Atomic_Desktops Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-web-based-remote-installation-support-for-atomic-desktops-self-contained/197426 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 == Enable secure remote installation via the Anaconda WebUI on Fedora Atomic Desktop images. Users can boot a target machine with <code>inst.webui.remote</code> and complete the installation from a web browser on another machine over HTTPS with pin-based authentication. This change is scoped to Atomic Desktop images (Silverblue, Kinoite, etc.). == Owner == * Name: [[User:bciconelle| Bruno Ciconelle]] * Email: bciconel@redhat.com == Detailed Description == This change introduces remote installation as a '''tech preview''' for Fedora Atomic Desktop images. Users can boot with <code>inst.webui.remote</code> and complete the installation from a web browser on another machine — no VNC/RDP client needed. The Anaconda WebUI already supports remote access for development via <code>inst.webui.remote</code>, but without authentication, TLS, or configuration isolation. This change adds the production controls needed to ship it as an opt-in feature: * '''Pin-based authentication''' following the <code>inst.rdp</code> pattern, with an opt-out (<code>inst.webui.remote.noauth</code>) for development and trusted networks * '''HTTPS with self-signed certificates''' — cockpit generates these automatically * '''Port 443''' by default so users connect with just <code>https://<ip></code> * '''Isolated cockpit configuration''' under <code>/etc/anaconda/cockpit/</code> to prevent installer settings from leaking to the installed system Remote access is '''not enabled by default''' — it must be explicitly activated by the user via the <code>inst.webui.remote</code> boot option. Without it, behavior is completely unchanged. This change is scoped to Atomic Desktop images (see [[Changes/BuildAtomicDesktopsWithImageBuilder]]). == Feedback == The feature was [https://fedoramagazine.org/web-based-remote-installation-for-fedora-linux-heres-what-were-building/ announced on Fedora Magazine] in June 2026 with a developer preview and proof-of-concept. Community feedback included: * '''mDNS discovery''': Suggestion to advertise the installer via mDNS (e.g., <code>fedora-installer.local</code>) so users can find headless machines without knowing their DHCP-assigned IP. Not in scope for this initial MVP but noted as a valuable future improvement. * '''Tablet/phone support''': Cockpit's PatternFly widgets are responsive — storage configuration may be challenging on small screens but tablets should work well. * '''Lightweight boot ISO''': Interest in a minimal boot ISO without a local browser that defaults to remote installation — a headless/network-only variant. Not in scope for this change, but aligns with the broader [[Changes/ModernizeBootISO]] effort. == Benefit to Fedora == * '''New installation method''': Users can install Fedora Atomic Desktops from any device with a web browser — no VNC/RDP client software needed. This works from phones, tablets, Chromebooks, or any machine on the same network. * '''Better user experience than VNC/RDP''': The WebUI provides copy-paste support, a responsive layout, and runs in a standard web browser. No special client software to install or configure. * '''Secure by default''': Unlike VNC (historically unencrypted, 8-character password limit), remote installation uses HTTPS with TLS and user-set passwords. Authentication is required by default. * '''Practical graphical installation on lightweight ARM SBCs''': Devices like the Raspberry Pi have limited CPU and memory. Running a local browser consumes resources better used by the installer itself. With remote installation, the browser runs on the user's workstation and the target device only serves the lightweight cockpit-ws process. * '''Benefits any future boot.iso/netinst image that adopts the WebUI''': This change lives in <code>anaconda</code> and <code>anaconda-webui</code>, not in image-specific configuration. Any new boot.iso or network install image that migrates from the GTK interface to the WebUI — such as Fedora Server, which currently still uses GTK — will automatically gain remote installation support with no additional work. (Note: remote access on Live images is not supported.) * '''Community testing opportunity''': Landing in Fedora 45 Atomic images gives the community a full release cycle to test, report issues, and provide feedback before the feature is extended to other image types. == Scope == * Proposal owners: ** Modify <code>anaconda</code> to handle new boot options (<code>inst.webui.remote.password</code>, <code>inst.webui.remote.noauth</code>) in <code>argument_parsing.py</code> ** Update <code>CockpitUserInterface</code> and the cockpit startup flow to enable TLS, set port 443, and configure authentication based on boot options ** Modify <code>anaconda-webui</code>'s <code>cockpit-coproc-wrapper.sh</code> to conditionally remove <code>--no-tls</code> and change port when remote is active ** Generate cockpit configuration under <code>/etc/anaconda/cockpit/</code> at startup ** Implement password prompt on local console when password is missing (following <code>inst.rdp</code> pattern) ** All changes are within the <code>anaconda</code> and <code>anaconda-webui</code> packages * Other developers: N/A * Release engineering: N/A (no changes to image generation pipeline — images already include cockpit and anaconda-webui) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: This change aligns with the Fedora strategy of making Fedora easier to install and use, particularly for Atomic Desktops which are a focus area for Fedora's future. == Upgrade/compatibility impact == None. This change only affects the installation environment. No configuration or data is carried to the installed system. Users who do not use <code>inst.webui.remote</code> see no change whatsoever. == How To Test == # Boot a Fedora 45 Atomic Desktop ISO (Silverblue, Kinoite, or similar) # At the boot menu, add kernel options: <code>inst.webui.remote inst.webui.remote.password=testpin</code> # The installer will display the machine's IP address on the local console # From another machine on the same network, open a browser and navigate to <code>https://<ip></code> # Accept the self-signed certificate warning in the browser # Enter <code>testpin</code> at the login prompt # The Anaconda WebUI should load and allow you to proceed with the installation # Test tab close (should reconnect without re-login) and browser close (should require re-login) '''Additional test cases:''' * Boot with <code>inst.webui.remote</code> only (no password) — installer should prompt for a password * Boot with <code>inst.webui.remote inst.webui.remote.noauth</code> — remote access should work without authentication * Boot without <code>inst.webui.remote</code> — remote access should NOT be available (current default behavior preserved) == User Experience == See the [https://fedoramagazine.org/web-based-remote-installation-for-fedora-linux-heres-what-were-building/ Fedora Magazine article] for a detailed overview of the remote installation experience and the ''How To Test'' section above for step-by-step instructions. Users who do not use <code>inst.webui.remote</code> will see no change in their experience. == Dependencies == The [https://github.com/rhinstaller/anaconda-webui anaconda-webui] package is maintained by the installer team and has a dependency on [https://cockpit-project.org/ Cockpit]. There are no unfinished work items blocking this initiative. == Contingency Plan == * Contingency mechanism: No action needed. The feature is opt-in and in tech preview — it is only activated when the user explicitly passes <code>inst.webui.remote</code> on the kernel command line. Without this boot option, the installer behaves identically to previous releases. An incomplete or buggy implementation does not affect normal installation workflows. N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No. The feature is opt-in. If incomplete, remote installation remains in its current development-only state. Local installation and all other installation methods are completely unaffected. == Documentation == * [https://redhat.atlassian.net/browse/INSTALLER-3723 INSTALLER-3723] — Epic tracking all remote installation work == Release Notes == Fedora 45 introduces secure remote installation support for Atomic Desktop images (Silverblue, Kinoite, and others). You can now install Fedora from a web browser on another device by adding <code>inst.webui.remote inst.webui.remote.password=YOURPIN</code> to the kernel boot options. The installer uses HTTPS with a self-signed certificate and listens on port 443, so you can connect by navigating to <code>https://<ip></code> from any web browser. This feature is opt-in and in tech preview — installations without <code>inst.webui.remote</code> are unaffected. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: IBus 1.5.35 (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/IBus_1.5.35 Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-ibus-1-5-35-self-contained/197425 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.35 will enhance the handling of XKB keymaps in Wayland desktop environments == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * IBus now supports the ISO latch and shift states of XKB keymaps in Wayland desktop environments likes KDE, Sway, Hyprland, COSMIC. * IBus now supports the IBus option to use the session keymaps regardless of the keymap of each input method engine. == Feedback == https://bugzilla.redhat.com/show_bug.cgi?id=2444009 == Benefit to Fedora == This change will enhance the usability in the Wayland desktop enviroments with the Wayland input-method protocols when user enables IBus input method framework for some XKB keymaps like "lv(tilde)", "de(T3)", "fr(ergol)". == Scope == * Proposal owners:ibus 1.5.35 * Other developers: * Release engineering: [https://forge.fedoraproject.org/releng/tickets/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 == === XKB keymap === # Configure `"us"` keymap in the system keymap with the `localectl` command and `/etc/vconsole.conf` file # Log into the Wayland desktop environment with the Wayland input-method protocol like KDE, Sway, Hyprland, COSMIC # Run `ibus start` to enable IBus and configure each DE with https://github.com/ibus/ibus/wiki/WaylandDesktop # Run `ibus-setup` utility and configure some XKB keymaps like `"Latvian (tilde)"` and enable one with {{key press|Super|space}} shortcut key # Type some ISO latch keys like {{key press|tilde|e}} or {{key press|AltGr|e}} The IBus XKB keymaps work fine and the system keymap is supported with `"us"` or the same keymap of the IBus keymap. === System keymap option === # Configure `"us"` keymap in the system keymap with the `localectl` command and `/etc/vconsole.conf` file # Log into the Wayland desktop environment with the Wayland input-method protocol like KDE, Sway, Hyprland, COSMIC. # Run `ibus start` to enable IBus and configure each DE with https://github.com/ibus/ibus/wiki/WaylandDesktop # Run `ibus-setup` utility and enable `"Use system keyboard layout"` option # Run `ibus-setup` utility and configure some XKB keymaps or input-method engines and enable one with {{key press|Super|space}} shortcut key Expected result is all keys are based on `"us"` keymap. == User Experience == IBus works with the XKB keymaps with the `ibus-setup` utility whether each DE supports the ISO latch keys or not. == 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 == TBD == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: Encapsule isolated devel containers (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Encapsule_devel_containers Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-encapsule-isolated-devel-containers-self-contained/197423 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 == [https://github.com/juhp/encapsule encapsule] is a new small CLI tool for developers who want to try out "tools installed from the internet" for example (or use them within a project workdir) inside a safer container environment rather than directly in their home directory and host system. == Owner == * Name: [[User:Petersen|Jens Petersen]] * Email: <petersen@redhat.com> == Detailed Description == The CLI tool allows running developer containers, isolating your home directory and host from container side effects: it can "encapsule" a project and/or temp homedir there together with select enabled "capabilities". It uses Podman to run a (derived) container image (which can be generated by Buildah from a toolbox container say). The project [https://github.com/juhp/encapsule#readme readme] file has more details about the specific features and commandline options. In this age developers are frequently asked to install and run all kind of commands or software directly from the internet whether from source or more often now binaries. In recent years `curl https://some.project/install.sh | bash` or `npm/npx install ...` (and many others: pip, cargo, etc) are being normalized and can both pollute one's home directory or system, and also put it at increased security risk. `encapsule` provides a lightweight, somewhat safer environment for installing and running such tools. Note however it is ''not'' intended for running known malicious programs or security testing, etc - though at least it provides some basic separation or system hygiene. Users can also disable sudo or even the network (or potentially DNS) inside the encapsule container. In many ways it makes opposite design choices to toolbox: closed by default rather than open - but one can opt in to sharing specific things from the host. A lot of the original ideas are derived from [https://github.com/swick/toolbox-constrained/ toolbox-constrained] by Sebastian Wick, without which this tool probably wouldn't exist now in its current form. For more hardened isolation it is recommended to look at OpenShell though it is not available yet in Fedora. In the future it may be possible to migrate `encapsule` to wrap `openshell` for instance and use its gateway perhaps, which would enhance network isolation considerably. The alternative is to use a VM of course, but that is much more heavyweight and awkward: though there is the similar [https://github.com/whot/schupfn whot/schupfn] project, which allows exporting specified directories with 9p to a QEMU VM instance, also generated from a toolbox. == Feedback == == Benefit to Fedora == Fedora users will have a simple way to isolate toolbox containers etc from their homedir and host system for running third party tools inside a contained environment, where they control what is shared from their home or host system. == Scope == * Proposal owners: ** Submit `encapsule` for package review and get it approved ** Fix reported issues and improve further * Other developers: N/A * Release engineering: [https://forge.fedoraproject.org/releng/tickets/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 == N/A == Early Testing (Optional) == https://copr.fedorainfracloud.org/coprs/petersen/encapsule/ == How To Test == * `sudo dnf install encapsule` * `encapsule --help` * `encapsule fedora-toolbox:44 -p myproject` * `encapsule fedora-toolbox-44 --home tmphome` * https://github.com/juhp/encapsule#examples == User Experience == Users will have a safer way to run harnesses and other tools grabbed from the internet. == 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 == To be written -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: Disable in Kernel Crypto Userspace API (Phase 1) (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Disable_CRYPTO_USER_API Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-disable-in-kernel-crypto-userspace-api-phase-1-self-contained/197422 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 in kernel Crypto Userspace API (CRYPTO_USER_API) is now deprecated upstream, with some parts of it being actively removed early in the 7.2 cycle, because of the security risk it contains. It is due to be disabled and actively removed from upstream in the near future. Restrict it's use in Fedora to known active users early so we can do a controlled ending of support and can make the community aware of it's pending disappearance and gracefully deal with unknown users. == Owner == * Name: [[User:pbrobinson| Peter Robinson]], [[User:jforbes| Justin Forbes]] * Email: [mailto:pbrobinson@fedoraproject.org pbrobinson@fedoraproject.org], [mailto:jforbes@fedoraproject.org jforbes@fedoraproject.org] == Detailed Description == The in kernel Crypto Userspace API (CRYPTO_USER_API) is now deprecated upstream, with some parts of it being actively removed early in the 7.2 cycle, because of the security risk it contains. It is due to be disabled and actively removed from upstream in the near future. The first phase will restrict it's use in Fedora early so we can do a controlled ending of support and can make the community aware of it's pending disappearance and gracefully deal with unknown users. There's not a lot of known users of the in kernel Crypto Userspace API so the impact should be minimal and there's upstream planning for most of those. The known Fedora users of the Crypto Userspace API are iwd, cryptsetup (just used for [https://www.man7.org/linux/man-pages/man8/cryptsetup.8.html#TCRYPT_(TRUECRYPT_AND_VERACRYPT_COMPATIBLE)_EXTENSION TrueCrypt, tcplay, or VeraCrypt] and some kernel level benchmarking) and libkcapi (used by dracut, kernel build process). These users are unaffected by this phase of the change. The cryptsetup already has the ability to fall back to other mechanisms. The iwd users will continue to function but users likely should migrate to wpa_supplicant (the iwd package is currently unmaintained upstream). The first phase uses the upstream patches due to land shortly, likely in 7.3, to limit the use of the API to the known apps and restricts the use. This allows Fedora to identify unknown users and gracefully deal with them before the active demise of the interface upstream providing users a more graceful process rather than universally pulling the rug without any notice. == Benefit to Fedora == The benefit to Fedora is to allow users of the in kernel crypto API to be aware of the impending disappearance of the interface and to give them some time to gracefully migrate to other userspace interfaces before the API is gone for good. == Scope == * Proposal owners: ** Ensure all the components that use the crypto userspace APIs have migrated to other userspace crypto APIs. ** Document the the replacements * Other developers: ** No impact * Release engineering: [https://pagure.io/releng/issue/XXXX #XXXX] ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|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 == No current known users of the crypto userspace kAPIs are affected and will continue to work. There may be third party users which will be identified as part of this process to allow us to work with them to mitigate/migrate to more suitable interfaces. == How To Test == * Install a Fedora 7.2 kernel build == User Experience == Generally users should not notice. The kernel Crypto Userspace API was never widely used and the in Fedora packages that make use of it will migrate to other mechanisms without users being aware of the change. == Dependencies == No external dependencies. == Contingency Plan == * Contingency mechanism: Re-enable * Contingency deadline: GA * Blocks release? No. * Blocks product? No. == Documentation == There's no specific kernel Crypto Userspace API documentation in Fedora. == Release Notes == Fedora has actively deprecated the in kernel Crypto Userspace API and no longer actively supports it's use. If you currently use the userspace crypto API please migrate to another suitable userspace crypto API. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: Anaconda WebUI Fedora Atomic (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_WebUI_Fedora_Atomic Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-anaconda-webui-fedora-atomic-self-contained/197421 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 installer used by Fedora Atomic ISO images from the legacy GTK-based Anaconda installer to the new WebUI installer. This aligns the installation experience of Atomic media with Fedora Workstation, KDE and Fedora Live Spins. == Owner == * Name: [[User:Kkoukiou | Katerina Koukiou]] * Email: kkoukiou@gmail.com * Name: [[User: supakeen | Simon De Vlieger]] * Email:''' [mailto:cmdr@supakeen.com cmdr at supakeen.com] or [mailto:supakeen@redhat.com supakeen at redhat.com] or [mailto:supakeen@fedoraproject.org supakeen at fedoraproject.org] * Name: [[ User:Siosm | Timothee Ravier ]] * Email: siosm@fedoraproject.org == Detailed Description == The Anaconda WebUI is becoming the standard installer experience across Fedora. This proposal extends that transition to Fedora Atomic installer ISOs, providing a consistent installation experience with current Live installations. Affected installer ISOs: * Fedora Silverblue * Fedora Kinoite * Fedora COSMIC Atomic * Fedora Sway Atomic (Sericea) * Fedora Budgie Atomic (Onyx) == Feedback == == Benefit to Fedora == Reduces maintenance by using a single installer implementation. See also the Change proposal from [https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation#Benefit_to_Fedora WebUI adoption to Workstation]. == Scope == * Proposal owners: - Switch Fedora Atomic installer ISOs to use the Anaconda WebUI. - Complete validation and testing across all affected Atomic variants. * Other developers: * Release engineering: [https://forge.fedoraproject.org/releng/tickets/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: == How To Test == Once the anaconda-webui package is required by `anaconda` main package [1] the affected Rawhide Atomic ISOs can be used for testing. [1]https://github.com/rhinstaller/anaconda/pull/7170 == User Experience == See [https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation#User_Experience Change proposal for WebUI adoption] from different Fedora variants. == Dependencies == The [https://src.fedoraproject.org/rpms/anaconda-webui package] for WebUI installer is maintained by the installer team and has dependency on [https://src.fedoraproject.org/rpms/cockpit Cockpit]. There are not unfinished work items blocking this initiative. == Contingency Plan == * Contingency mechanism: If significant issues are identified before the release, Fedora Atomic installer ISOs will revert to using the GTK-based Anaconda installer * Contingency deadline: We have the contingency plan ready * Blocks release? No. We can revert the change easily if blockers show up == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
Tuesday, July 21, 2026
REMINDER: F45 Self-Contained Change Proposal Submission Closes Today
Hi all, Reminder: You must submit your F45 self-contained change proposal today[1] to be considered for this next release. The Changes template and isntrcutions can be found at the top of this page[2]. If you miss this deadline, please consider proposing your change for F46 instead[3]. [1] https://fedorapeople.org/groups/schedule/f-45/f-45-key-tasks.html [2] https://docs.fedoraproject.org/en-US/operations/changes_policy/ [3] https://fedorapeople.org/groups/schedule/f-46/f-46-key-tasks.html Kind regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
Monday, July 20, 2026
Fedora 45 Mass Rebuild Completed
As per the Fedora 45 release schedule [1], we started a mass rebuild for Fedora 45 on 2026-07-15. This is now completed.
The mass rebuild was run for the changes listed here:
https://fedoraproject.org/wiki/Fedora_45_Mass_Rebuild#Driving_Changes
The rebuild was done in a side tag (`f45-rebuild`) that was merged into the release tag (`f45`).
Failures from the mass rebuild can be found here:
https://kojipkgs.fedoraproject.org/mass-rebuild/f45-failures.html
Packages that still need to be rebuilt can be found here:
https://kojipkgs.fedoraproject.org/mass-rebuild/f45-need-rebuild.html
FTBFS bugs will be filed shortly for the remaining failures.
Discussions related to the Fedora 45 mass rebuild took place in the tracker ticket [2].
Please let Release Engineering know if you notice any issues with the reporting.
You can contact us through the Release Engineering Matrix room [3] or by opening a ticket on our issue tracker [4].
Patrik Polakovic
Fedora Release Engineering
[1] https://fedorapeople.org/groups/schedule/f-45/f-45-all-tasks.html
[2] https://forge.fedoraproject.org/releng/tickets/issues/13406
[3] https://matrix.to/#/#releng:fedoraproject.org
[4] https://forge.fedoraproject.org/releng/tickets/issues
-- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: Authselect: Hardcode nss-altfiles in profiles (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Authselect_Hardcode_Altfiles Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-authselect-hardcode-nss-altfiles-in-profiles-self-contained/197236 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 == Currently, authselect users can enable nss-altfiles in nsswitch.conf using "with-altfiles" feature. This proposal is to remove the feature and hardcode nss-altfiles support in nsswitch.conf in all shipped profiles, making it required. == Owner == * Name: [[User:pbrezina| Pavel Březina]] * Email: pbrezina@redhat.com == Detailed Description == Currently, non-ostree systems (e.g. Fedora Workstation) have nss-altfiles nsswitch.conf module optional in authselect profiles. Users can enable this module by calling "authselect enable-feature with-altfiles" or directly when selecting the profile "authselect select $profile with-altfiles". However, the nss-altfiles nsswitch.conf module is required to be enabled on ostree systems (e.g. Fedora Silverblue) and must not be disabled there to make system users available to the system. This is currently handled by authselect in %post scriptlet that modifies the shipped profiles and hardcodes nss-altfiles in them. This solution, however, makes authselect different on ostree and non-ostree systems. The history also showed that it is quite fragile and easy to break with modifications to the profiles. The intention is to hardcode nss-altfiles on both ostree and non-ostree, making authselect install exactly the same files on both distribution types. == Feedback == None. == Benefit to Fedora == Both ostree and non-ostree Fedora releases will ship exactly the same authselect content. == Scope == * Proposal owners: Do the work in upstream and release it in Fedora. * Other developers: None. * Release engineering: None. [https://forge.fedoraproject.org/releng/tickets/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 == None. Upgrade path will be handled by authselect. == Early Testing (Optional) == == How To Test == 1. Check that with-altfiles is no longer available in the profiles 2. Check that "altfiles" is present in generated /etc/nsswitch.conf == User Experience == User's should not notice the change. == Dependencies == None. == 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 "with-altfiles" feature has been removed from all authselect profiles. The nss-altfiles support is now enabled and can not be disabled. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: Authselect Remove NIS Profile (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Authselect_Remove_NIS_Profile Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-authselect-remove-nis-profile-self-contained/197233 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 == Authselect currently ships four profiles local, sssd, winbind and nis. This change suggest removing the nis profile from authselect - it will no longer be possible to configure nsswitch.conf for NIS with authselect using "authselect select nis" but NIS will still be available on the system and users will be able to configure their nsswitch.conf to use NIS with custom authselect profile or manually. == Owner == * Name: [[User:pbrezina| Pavel Březina]] * Email: pbrezina@redhat.com == Detailed Description == This change will remove the authselect nis profile from the list of shipped profiles. User's will no longer be able to choose this profile to configure their nsswitch.conf for NIS support. They will need to do it manually or with a custom authselect profile. == Feedback == No feedback. == Benefit to Fedora == NIS is an old, outdated technology. This change does not strip NIS support from the system, only from authselect profiles. Vast majority of the Fedora users should not be affected and user's that still require NIS will still be able to use it. Reducing number of profiles will make authselect maintenance easier. == Scope == * Proposal owners: Remove NIS profile from authselect RPM and from authselect upstream. * Other developers: None * Release engineering: None. [https://forge.fedoraproject.org/releng/tickets/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 == User's that have the nis profile selected will still have the system configured correctly after upgrade. But "authselect check" will report issues. == Early Testing (Optional) == == How To Test == check that `authselect list` no longer shows nis == User Experience == Authselect nis profile is no longer available. == Dependencies == == Contingency Plan == Revert changes if needed. * 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 "nis" authselect profile was removed. If you use this profile, make sure to create and select a custom authselect profile that will enable nis support on your system or opt-out from authselect with "authselect opt-out", keeping the current configuration intact. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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://forge.fedoraproject.org/infra/tickets/issues/new