F36 Change: Silverblue and Kinoite will have /var on its own Btrfs subvolume (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/VarSubvol4SilverblueKinoite == Summary == Silverblue and Kinoite: For new clean automatic (guided) installations, create a "var" subvolume to be mounted at /var. == Owner == * Name: [[User:chrismurphy| Chris Murphy]] * Email: bugzi...@colorremedies.com == Detailed Description == Currently, Silverblue and Kinoite mimic other Fedora desktops. There is a "root" subvolume mounted at `/` and a "home" subvolume mounted at `/home`. This proposal adds a "var" subvolume to be mounted at `/var`. The "var" subvolume will be located at the top-level of the Btrfs file system, along-side the "root" and "home" subvolumes. An entry in `/etc/fstab` will mount it at `/var` during startup. == Benefit to Fedora == Users who opt into Btrfs features like snapshots and rollbacks. * By moving /var into its own subvolume, it will be excluded from snapshots and rollbacks of the "root" subvolume, which contains `/etc` and `/usr`. * Users will find it straightforward to rollback "root" while not rolling back "var": including logs, VMs, databases, flatpaks, etc. * The ability to snapshot only "var" and use Btrfs send/receive to replicate only "var" permits for an efficient way of backing up the variable system data. ** A clean install can restore the "root", therefore it doesn't strictly need to be backed up. Meanwhile "var" and "home" can be restored using snapshot replication via send/receive. == Scope == * Proposal owners: ** changes to lorax and anaconda as needed so that Silverblue and Kinoite variants have their own installation kickstart, such that automatic/guided installation automatically creates "var". *** possible liability, determine whether the the addition of /var mount point for Btrfs scheme results in /var mount point for other schemes (and inhibit) == Upgrade/compatibility impact == Change will not be applied to upgrades. But we can document steps to apply the change to existing installations. == How To Test == * Do a clean installation and check `df` and `/etc/fstab` for an explicitly listed `/var` mount point. == User Experience == * The change won't generally be noticeable to users * Users will see an additional `/var` mount point in /etc/fstab, and `df` * Some utilities, notably backup programs like borg backup, and rsync with -x option, will treat Btrfs subvolumes as separate file systems and may not descend (recursively) into them. == Dependencies == * Anaconda/blivet, lorax, and possibly kickstarts == Contingency Plan == * Contingency deadline: beta freeze * Blocks release? No == Documentation == No significant documentation is planned other than this change proposal. == 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 on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Authselect_Move_State_Files_To_Etc == Summary == Authselect will move several files that are currently stored at /var/lib/authselect to /etc/authselect/.state. This does not affect configuration backup, that will be kept at /var/lib/authselect/backups. The files that will be moved are: * /var/lib/authselect/dconf-db -> /etc/authselect/.state/dconf-db * /var/lib/authselect/dconf-locks /etc/authselect/.state/dconf-locks * /var/lib/authselect/fingerprint-auth /etc/authselect/.state/fingerprint-auth * /var/lib/authselect/nsswitch.conf /etc/authselect/.state/nsswitch.conf * /var/lib/authselect/password-auth /etc/authselect/.state/password-auth * /var/lib/authselect/postlogin /etc/authselect/.state/postlogin * /var/lib/authselect/smartcard-auth /etc/authselect/.state/smartcard-auth * /var/lib/authselect/system-auth /etc/authselect/.state/system-auth == Owner == * Name: [[User:pbrezina| Pavel Březina]] * Email: pbrez...@redhat.com == Detailed Description == These files are used by authselect to detect changes to the system nsswitch and PAM configurations when the configuration is updated with an updated profile using 'authselect apply-changes'. There are two reasons for the move: 1. The current location conflicts with ostree model where /var is not writable during rpm transaction and this currently blocks compose of ostree systems. [https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360] 2. Removing these files would reduce authselect functionality, user would need to run 'authselect select --force' to restore it. Since /var should contain only files that can be safely removed, /etc is a better place for them. == Feedback == This change is accepted by ostree system maintainers, see [https://bugzilla.redhat.com/show_bug.cgi?id=2034360 BZ#2034360]. == Benefit to Fedora == This makes authselect more compatible with ostree model. == Scope == * Proposal owners: Build authselect with --statedir=/etc/authselect/.state and move files from /var/lib/authselect to the new location. Spec file changes only. * Other developers: N/A (not needed for this Change) * Release engineering: [https://pagure.io/releng/issue/10544 #10544] * 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 == No impact. Files will be moved automatically during update and everything will keep working as prior. == How To Test == 1. Authselect keeps working as expected after the upgrade == User Experience == This change is only under the hood, it does not affect user experience. == Dependencies == No 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 == Authselect state files moved from /var/lib/authselect to /etc/authselect/.state. -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM
= Wayland by Default for SDDM =
== Summary ==
Change the default display server mode for SDDM to use a Wayland-based
greeter rather than an X11-based one.
== Owner ==
* Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
[[User:Jgrulich|Jan Grulich]]
* Email: ngomp...@gmail.com, rdie...@gmail.com, jgrul...@redhat.com
* Product: KDE Spin, Kinoite
* Responsible WG: KDE SIG
== Detailed Description ==
With [https://github.com/sddm/sddm/pull/1393 the work done upstream in
SDDM to support using a Wayland based greeter] and
[[Changes/ReplaceFbdevDrivers|the introduction of SimpleDRM to fix the
broken fallback when platform drivers are unavailable]], it is now
possible for the Fedora KDE variants (the regular spin and Kinoite) to
move to Wayland for the login manager, which effectively completes the
switch to Wayland for these variants.
== Benefit to Fedora ==
As originally detailed in [[Changes/WaylandByDefaultForPlasma|the
Change to switch Plasma to Wayland by default]], Fedora is a leader in
advancing the adoption of the Wayland protocol as part of the overall
strategy to improve the Linux graphical software stack. We have been
successful in helping drive Wayland forward in the Plasma Desktop, and
we intend to do the same for SDDM.
== Scope ==
* Proposal owners:
** Upgrade {{package|sddm}} to the latest snapshot and introduce
mutually exclusive sddm-wayland-generic and
sddm-x11 greeter configuration packages.
** Modify {{package|plasma-workspace}} to switch SDDM to Wayland
*** Enable installation of the SDDM Wayland configuration snippet and
ship as sddm-wayland-plasma that is mutually exclusive
with the other sddm greeter configuration packages. This package will
supplement {{package|sddm}} and plasma-workspace-wayland
to be automatically installed together.
** Modify @kde-desktop comps group for Fedora Linux 36 to
include sddm-wayland-plasma for the media.
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://pagure.io/releng/issue/10536 #10536]
* 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 ==
On upgrade to Fedora Linux 36, SDDM will be transparently switched
from the X11 greeter to the Wayland one leveraging kwin. In order to
override this, the user can do one of the following:
* Drop in a configuration file in /etc/sddm.conf.d to set
the display server back to X11
* Swap back to X11 with the configuration package: dnf swap
sddm-wayland-plasma sddm-x11
== How To Test ==
Once the SDDM and Plasma Wayland changes are made, Rawhide users can
try this by using nightly KDE ISOs and using them normally to install
and run a Rawhide KDE Plasma environment.
== User Experience ==
Ideally, there should be no noticeable impact on the user experience,
though users may notice that things operate more smoothly and with
slightly lower resources.
== Dependencies ==
This change is dependent on [[Changes/ReplaceFbdevDrivers|the Change
to replace fbdev with SimpleDRM]]. Without that Change, we will need
to keep SDDM using X11 because otherwise the fallbacks are broken when
drivers do not work.
== Contingency Plan ==
* Contingency mechanism: Update comps and {{package|plasma-workspace}}
so that sddm-x11 is shipped instead.
* Contingency deadline: beta freeze
* Blocks release? Yes
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
SDDM, the login manager for the Fedora variants using the KDE Plasma
Desktop, now uses the Wayland display system.
--
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 on the list, report it:
https://pagure.io/fedora-infrastructure
F36 Change: Ruby on Rails 7.0 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_7.0 == Summary == Ruby on Rails 7.0 is the latest version of well known web framework written in Ruby. == Owner == * Name: [[User:pvalena| Pavel Valena]], [[User:jprokop| Jarek Prokop]] * Email: pval...@redhat.com, jpro...@redhat.com, ruby-...@lists.fedoraproject.org == Detailed Description == The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace with it. Therefore the whole Ruby on Rails stack should be updated from 6.1 in Fedora 35 to 7.0 (latest version) in Fedora 36. This will ensure that all the Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on Rails. == Benefit to Fedora == This update will keep Fedora up-to-date and will ensure that the current Ruby on Rails developers stay with us as they will get support for system-packaged Ruby on Rails of the latest version. Update to Rails 7.0 contains hundreds of fixes and improvements across all the frameworks. For new features, please see [#User_Experience User Experience]. == Scope == * Proposal owners: ** The whole Rails stack has to be updated. ** Some dependencies of the Rails stack will need update. === Packages need to be created/updated === * Rails bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2032639 #2032639] ** Specific changes: (see wiki) * Current development state can be observed in [https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/ pvalena/ruby-on-rails] COPR repository. ** Current status: '''version 7.0.0''' built and tested * Other developers: Update Rails dependent packages to be working with Ruby on Rails 7.0 * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Web applications build above Ruby on Rails framework might need to be updated. Official upstream upgrade guide might come handy: http://guides.rubyonrails.org/upgrading_ruby_on_rails.html == How To Test == * No special hardware is needed. * Some additional adjustments to dependencies are needed to start the default app. Example: ** https://github.com/pvalena/theprototype/blob/main/rails/test.sh === To test only Rails itself === dnf install rubygem-rails rails new app cd app && rails s * Go to http://127.0.0.1:3000/ and make sure you are running Rails 7.0.x === To test the complete feature including generating a new Rails app using RPM === dnf group install 'Ruby on Rails' rails new app --skip-bundle && cd app rails s * Go to http://127.0.0.1:3000/ and make sure you are running Rails 7.0.x == User Experience == * New version of Ruby on Rails (7.0) available * The most significant Rails 7.0 features: ** No-Node default approach to the front end ** Hotwire’s combination of Turbo and Stimulus ** Easily use any JavaScript bundler ** Encrypted attributes in Active Record ** Asynchronous Query Loading ** Zeitwerk autoloader is used exclusively == Dependencies == * There are several packages, which depends on Ruby on Rails framework. * These needs to be surely updated: ** (none) * Following gems don't support Rails 7.0 right now and would be broken by the update: ** (none) * As Rails requires Ruby >= 2.7, the platform less than the version can not use Rails 7.0. == Contingency Plan == * Contingency mechanism: None needed. Rails stack won't be updated until all its dependencies are in Rawhide. After that, it will be a simple matter of updating the core packages (and their dependencies) via side-tag. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No * Blocks product? No == Documentation == * http://api.rubyonrails.org/ == Release Notes == * https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-vision * https://edgeguides.rubyonrails.org/7_0_release_notes.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 on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: MLT-7 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/F36MLT-7 == Summary == update MLT to version 7.4 (latest version) == Owner == * Name: [[User:sergiomb| Sérgio Basto]] * Email: sergi...@fedoraproject.org == Detailed Description == Update of MLT from v6 to v7 breaks the builds, binaries changed the name and devel files changed the location [1], authors argue that facilitates have 2 versions of MLT at same time, but I personally don't want keep to versions of MLT because MLT just 3 or 5 projects that use it, [1] https://github.com/mltframework/mlt/issues/713 == Benefit to Fedora == Up-to-date and latest MLT release will be delivered to Fedora users. == Scope == * Proposal owners: [[User:Sergiomb | Sérgio Basto]] [[https://accounts.fedoraproject.org/user/martinkg/ | Martin Gansser]] * Other developers: [[User:Kwizart | Nicolas Chauvet]] * 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 == We need update ETL , synfig and synfigstudio from version 1.40 to version 1.5.1 . webvfx (THE PROJECT IS DEPRECATED BY THE MLT TEAM AND NO LONGER MAINTAINED) we may retire it or build it without MLT support. == How To Test == Run the new synfigstudio and work with it, testing the tasks that user already did with the previous version == User Experience == They will have updated tools == Dependencies == Already explained on Upgrade/compatibility impact == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) (not a System Wide Change) report upstream and apply fixes ASAP * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No == Documentation == https://www.mltframework.org/docs/ == Release Notes == post https://www.mltframework.org/blog/v7.0.0_released/ and blog it self https://www.mltframework.org/blog/ -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
