https://fedoraproject.org/wiki/Changes/GNUToolchain
== Summary ==
Switch the Fedora 33 GNU Toolchain to gcc 11, binutils 2.35, and glibc 2.33.
The binutils 2.35 change is being tracked here:
https://fedoraproject.org/wiki/Changes/BINUTILS235
The gcc 11 and glibc 2.33 change will be tracked in this top-level GNU
Toolchain system-wide update.
== Owner ==
* Name: [[User:codonell|Carlos O'Donell]], [[User:law|Jeff Law]]
* Email: carlos(a)redhat.com, law(a)redhat.com
== Detailed Description ==
The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities
make up the core part of the GNU Toolchain and it is useful to
transition these components as a complete implementation when making a
new release of Fedora.
The GNU Compiler Collection will be releasing version 11 containing
many new features documented here:
https://gcc.gnu.org/gcc-11/changes.html. Historically pre-releases of
GCC drop into Fedora in Jan/Feb just prior to the mass rebuild. The
major process change this year is the desire to drop in snapshots of
GCC 11 into rawhide starting in November with updates throughout the
Fedora 34 release process as needed.
The GNU C Library version 2.33 will be released at the beginning of
February 2020; we have started closely tracking the glibc 2.33
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 34 will branch after the
glibc 2.33 upstream release. However, the mass rebuild schedule means
Fedora 34 will mass rebuild (if required) after glibc 2.33 upstream
freezes ABI for release, but before the actual release, so careful
attention must be paid to any last minute ABI changes.
== Benefit to Fedora ==
Stays up to date with latest features, improvements security and bug
fixes from gcc and glibc upstream.
The change to drop GCC 11 snapshots into rawhide earlier is meant to
start more wide scale testing of GCC earlier. This means that package
maintainers will not be faced with a onslaught on FTBFS issues in
Feb/Mar and the GCC maintainers will not be as stressed trying to fix
all Fedora related issues in a short time frame as well.
== Scope ==
The gcc and glibc teams will need to move their respective upstream
projects to a releasable state. For GCC this includes correctly
building Fedora rawhide.
* Other developers: Developers need to ensure that gcc, binutils, and
glibc in rawhide is stable and ready for the Fedora 34 branch. Given
that glibc is backwards compatible and we have been testing the new
glibc in rawhide it should make very little impact when updated,
except for the occasional deprecation warnings and removal of legacy
interfaces from public header files. GCC is currently being tested
weekly against Fedora rawhide and fixes for issues discovered are
continually dropping into rawhide to minimize the impact on package
maintainers. However, we fully expect some issues to arise,
particularly as the GCC team's tests are limited to x86_64.
* Release engineering: [https://pagure.io/releng/issue/9858 9858] A
mass rebuild is strongly encouraged.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of
Fedora installed and are updated to the version containing this
change? Will anything require manual configuration or data migration?
Will any existing functionality be no longer supported? -->
The compiler, and the the library are backwards compatible with the
previous version of Fedora.
Some packaging changes may be required for the glibc 2.33 rebase:
https://sourceware.org/glibc/wiki/Release/2.33#Packaging_Changes
Some source changes may be required for gcc 11 rebase:
https://gcc.gnu.org/gcc-11/changes.html
We fully expect to fix all packaging changes in Fedora Rawhide without
impact to the release.
== How To Test ==
The GNU C compiler collection has its own testsuite which is run
during the package build and examined by the gcc developers before
being uploaded. The GCC team also is also doing continuous testing of
GCC 11 snapshots against Fedora rawhide to identify and resolve issues
prior to new versions of GCC landing in rawhide. This work will
continue, particularly in Nov, Dec, Jan and Feb and we will use it to
help guide decisions about snapshots are stable enough to not cause
major Fedora rawhide disruptions. We expect that by March the pace of
updates will reduce significantly.
The GCC team will likely need some help addressing some of the new
diagnostics that require package specific knowledge to determine if
the code is valid or not. This is not new, but the timing will shift
to earlier points in the Fedora release cycle.
The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future may also run the
microbenchmark to look for performance regressions.
== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, additional locales, etc.
== Dependencies ==
All packages do not need to be rebuilt due to backwards compatibility.
However, it is advantageous if a mass rebuild is performed during the
Fedora 34 cycle.
== Contingency Plan ==
* Contingency mechanism: If gcc 11 proves too disruptive to compiling
the distribution, which is not expected, we could revert to gcc 10 for
the release. If glibc 2.33 provides too disruptive to compiling the
distribution we could revert to 2.32, but given that Rawhide has
started tracking glibc 2.33, no show-stopper problems are expected.
At this point, we can still revert to upstream version 2.32 if
insurmountable problems appear, but to do so may require a mass
rebuild to remove new symbols from the ABI/API.
* Contingency deadline: Upstream glibc ABI freeze deadline of 2021-02-01.
* Blocks release? Yes, upgrading to gcc 11 blocks the release. Yes,
upgrading glibc does block the release. We should not ship without a
newer gcc and glibc, there will be gcc and language features that
depend on glibc being upgraded. Thus without the upgrade some features
will be disabled or fall back to less optimal implementations.
== Documentation ==
The gcc manual contains the documentation for the release and doesn't
need any more additional work.
The glibc manual contains the documentation for the release and
doesn't need any more additional work.
== Release Notes ==
The GNU Compiler Collection version 11 will be released shortly. See
https://gcc.gnu.org/gcc-11/changes.html.
The GNU C Library version 2.32 will be released at the beginning of
August 2020. The current NEWS notes can be seen here as they are
added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== Summary ==
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.
== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taymans(a)gmail.com
== Detailed Description ==
Currently, all desktop audio is handled by the PulseAudio daemon.
Applications make use of the
PulseAudio client library to communicate with the PulseAudio daemon
that mixes and manages the audio streams from the clients.
The desktop shell (gnome-shell) and the control panel
(gnome-control-panel) both use the
Pulseaudio client libraries to manage the volume and configuration of
the PulseAudio daemon.
This proposal is to replace the PulseAudio daemon with a functionally
compatible implementation
based on PipeWire. This means that all existing clients using the
PulseAudio client library
will continue to work as before, as well as applications shipped as Flatpak.
All PRO audio is handled with the JACK client library, which talks to
the JACK server. This
proposal will install a JACK client library replacement that talks
directly to PipeWire. All
existing PRO audio jack applications will then work on top of PipeWire.
For legacy ALSA clients, we will install an ALSA plugin that routes
the audio directly to
PipeWire.
With these 3 changes, all audio will be routed to PipeWire. There will
then be no more need to
install the PulseAudio and JACK daemons.
== Feedback ==
The owner of this proposal has been in context with both the
PulseAudio and JACK maintainers and community.
PipeWire is considered to be the successor of both projects.
== Benefit to Fedora ==
The end goal is to end up with one audio infrastructure for both
Desktop and Pro audio use cases.
This will end the fragmentation of the audio landscape.
Some of the benefits that PipeWire will bring:
* PRO Audio features
PipeWire can support both Desktop and PRO Audio use cases. PRO
Audio application tend to use
the JACK API and JACK daemon, which is hard to setup and integrates
poorly with the rest of
the system (and PulseAudio in particular).
With a replacement libjack library, PRO Audio application can run
directly on PipeWire and
integrate seamlessly with other ALSA and PulseAudio applications.
This would bring Fedora
closer to the experience of other operating systems.
* Flexibility/Integration
PipeWire is designed to be multiprocess. It separates the
processing of the multimedia graph
and the management into separate processes. This makes it possible
to better integrate with
the other system components or swap out the default policy for a
highly customized one (such as
for automotive or embedded). This is in contrast to PulseAudio,
which has all logic embedded
into the daemon with limited configuration options.
In the next phase we expect to greatly expand the user experience
and configuration of the
audio infrastructure with better integration throughout the system.
* Performance
PipeWire was designed for high performance and low-latency, using
much of the same design as
JACK. JACK application should run with comparable performance even
in low-latency situations.
* Security
PipeWire enforces per client security. Object visibility and the
actions on them can be
configured independently per client. This makes it possible to
enforce a security policy for
sandboxed applications (Flatpak) such as denying access to certain
audio capture devices or
block them from interfering with other applications.
* Maintainability
Both PulseAudio and JACK have very slow development cycles with few
new features. The more
flexible and distributed nature of the design of PipeWire should
encourage more new features
and use-cases.
== Scope ==
* Proposal owners:
We would make a pipewire-pulse package that provides the same features
as the pulseaudio (daemon) package.
We would only provide a drop-in replacement daemon, the pulseaudio
client libraries will remain unchanged.
The idea is that when installing pipewire-pulse, only the pulseaudio
package is removed and replaced by the
pipewire-pulse implementation. In the same way, installing the
pulseaudio package would remove the pipewire-pulse
package, making it possible to switch between implementations. This
will also allow for an easy rollback.
We also need to check and correct the dependencies of other packages.
As of this writing, some packages do
not state their dependencies correctly and get removed when pulseaudio
is removed. We also need to check the
JACK to make sure they still install with the replacement JACK client library.
The JACK client libraries will be installed in the same way, removing
the old JACK client libraries.
* Other developers:
The distribution needs to default to the pipewire-pulse package
instead of pulseaudio.
JACK applications need to install the pipewire-libjack client library.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
* Policies and guidelines:
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio
but it is expected that
comparable functionality will be implemented later. Most notable
features that are likely
not going to be available for fedora 34
* avahi network discovery and audio routing. This is not enabled by
default but can be activated
with paprefs. this includes TCP and RTP transport of audio.
* make devices available as UPNP media servers. Not enabled by
default, paprefs can be used.
* easy configuration of combining all sinks. Questionable feature but
possible via paprefs.
User scripts will still work but custom configurations of the
pulseaudio daemon will not be used
anymore.
Most of the JACK workflow of managing the JACK daemon is not going to
be needed anymore as things
will work out-of-the-box. As of this writing, these things are missing
from the JACK implementation,
we hope to implement them before fedora 34:
* latency reporting: useful to align streams
* freewheeling: used when rendering a project
* jackdbus: used by some tools to manage the graph
== How To Test ==
This change needs to be tested on as many different audio cards as
possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which
removes the pulseaudio package).
To test the JACK support, one needs to install pipewire-libjack, which
removes the original
JACK client and server.
After these changes, a restart is needed to make sure the new
pipewire-pulse daemon is running.
Audio functionality should be like it was before with the Pulseaudio
daemon. Some things to verify:
- patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)
- gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug
headphones and observe correct
switch.
- pavucontrol: check volumes in the input devices tabs and check the
microphone volumes
- firefox: check out a website with audio/video such as youtube and
verify that audio works as
usual. Check out a website with a video chat test page
(bluejeans.com/111)
- rhythmbox: check if playback works as expected
- bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.
- Regular system usage and performance should not change.
- JACK tools such as catia, carla should run and can be used to
inspect the graph.
== User Experience ==
In general, users should not be able to see any change when using
PulseAudio applications.
The big change is when using JACK application:
- They will start without having to configure and start the daemon.
this includes
the period size and sample rates.
- All devices will be visible in the graph with meaningful names. Devices will
be automatically slaved when needed without needing any configuration.
- bluetooth devices will be usable as well.
== Dependencies ==
Other packages might need to have their requirements fixed to work
with the replacement packages
but this is under our control.
== Contingency Plan ==
* Contingency mechanism: Keep existing pulseaudio and JACK client
libraries as defaults
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
[https://pipewire.org](PipeWire website)
[https://www.youtube.com/watch?v=8LZt4loZu64&t=14s](Video with Current status)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md](…
guide)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md](h…
to use/test)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
There will be an outage starting at 2020-11-11 21:00UTC,
which will last approximately 6 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2017-05-03 21:00UTC'
Reason for outage:
Apply updates and new kernels for all systems running RHEL7/RHEL8 and
Fedora 32
Affected Services:
Most services in IAD2 will see downtime as we run updates and reboot
systems.
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/NNNN
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
--
Stephen J Smoogen.
Hi everyone,
I hope you enjoyed the F33 release party this weekend! Getting back to
the GitLab topic mail threads, this weeks topic from the GitLab AMA
session on September 10th is on Message Bus. As always, here are some
links to the resources I have been pulling content from as well:
* Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
* Chat log from session
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_w…
* AMA Blog post
https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
* Here is this email in hackmd if you wish to view it there:
https://hackmd.io/tfOqCXNEQtqsGNLAEfZ2zg?view
## Topic: Message Bus
- Question: Fedora uses a message bus to integrate different parts of
its infrastructure. How should we onboard GitLab into this message
bus?
- Answer: Currently we would need to have a service that proxies
GitLab’s events to fedora-messaging something similar to
github2fedmsg.
There were some concerns raised about the order of events sent by
GitLab’s webhooks, these will need to be looked after during a Proof
of Concept stage.
- Question: How would git push over http work with GitLab? (assuming
gitlab does not have Fedora's password since they are stored in FAS)
- Answer: GitLab has a good number of authentication options and
integrations where the "best" solution usually depends on a team's
specific needs and use case. As such, the best way to know and meet
Fedora's needs and use cases is to have a conversation and discuss the
options with GitLab. How does git push over HTTP work with FAS right
now, and what git push (over HTTP) auth requirements/flow would you
like to have for your projects in GitLab?
These are the only two questions and answers I could gather relating
to message bus from the AMA question sheet, however I know there was a
lot of discussion regarding this topic during the AMA session itself,
so if you would like to resume/kick off that conversation again,
please feel free to use this email to discuss.
A personal note and for full transparency: the weeks seem to be
passing in the blink of an eye lately, I assume it's because I'm
busy(?) but it might be just the weird 2020 vibe the world is on
nowadays. I really don't know. Whatever the reason, there has been no
further discussion with GitLab since early October-ish, but we will be
returning to the conversation of how this migration could be
technically possible soon, so sincerely thank you all again for
engaging with us/me here as I found reading the discussion on
permission and access much easier to follow and have been taking notes
on your expectations to use that feedback in conversations with GitLab
when we pick the discussion back up.
I hope you all had a good weekend and will talk to you all next week
when the topic of Namespace & Issue Tracking is sent!
Kindest regards,
Aoife
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
== Summary ==
This change will remove make from the default buildroot in Koji and mock.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com>
== Detailed Description ==
===== Phase 1: Analysis =====
For this change, we will start by creating a list of all packages that
have a build-time dependency on make. This will be done by analyzing
spec files and also by rebuilding all packages in Fedora with make
removed from the buildroot to see which packages fail to build. Once
we have this list, we will remove packages that already have
BuildRequires:make in their spec file, and this final list[1] will be
all the packages that need to be updated in Phase 2.
[1] https://github.com/tstellar/fedora-change-make-buildroot/blob/main/needs_br…
===== Phase 2: Package Updates =====
Once we have the list of packages that need to be updated, we will
proceed with adding BuildRequires: make to all spec files that require
it. This new BuildRequires will be added to the line after the last
BuildRequires in the spec file. The release number for packages will
'''*not*''' be incremented for this change.
The spec file updates will be automated and changes will be pushed
directly to dist-git once they are ready.
===== Phase 3: Update Buildroot =====
Once package spec files have been updated, then we can proceed with
removing make from the BuildRoot. This will be done by removing make
from the build group in Koji and by removing make from the
buildsys-build group in comps (fedora-comps). In order to avoid
issues with Koschei, this change will need to be made as close as
possible to the start of the mass rebuild. If possible, we will try
to first remove make from the mass rebuild side-tag and then remove it
from rawhide after the rebuild completes.
===== Phase 4: Monitor Failures =====
Once all the changes are in place, we will continue to monitor koji
builds to see if there are any failures related to this change. We
expect that the analysis done in Phase 1 would give us the complete
list of packages that need to be updated, but it is always possible
that something will be missed.
== Feedback ==
* Removing make from the Buildroot without rebuilding the packages
first has the potential to cause mass failures in Koschei. This is
because Koschei builds from the latest SRPM and not from dist-git. We
can minimize this problem by removing make from the buildroot as close
as possible to the mass rebuild. The proposal has been updated now to
account for this issue.
== Benefit to Fedora ==
Based on my research[1], Fedora Rawhide has 22,309 packages, and there
are approximately 10,378 packages that either use make explicitly or
fail to build when make is removed form the buildroot. This means
that there are around 11,931 packages that don't need make. Removing
make from the BuildRoot will reduce the network traffic, download
times, and disk usage for these builds in Koji and also for users
doing builds with mock.
Removing make (and its dependencies) will:
* Reduce the BuildRoot download size by: 7.3 MB [2]:
** make: 539k
** gc: 104k
** guile22: 6.6M
** libtool-ltdl: 36k
* Reduce the BuildRoot install size by; 46 MB [2]:
** make: 1.6M
** gc: 229k
** guile22: 44M
** libtool-ltdl: 71k
[1] https://github.com/tstellar/fedora-change-make-buildroot
[2] Package sizes are from the x86_64 packages.
== Scope ==
* '''Proposal owners:''' Tom Stellard
* '''Package Maintainers:''' Fedora package maintainers should report
bugs if they think there is a problem caused by this change, but
otherwise there will be no action required by them.
* '''Proven Packager:''' The proposal owner will need to either apply
for provenpackager status or get the help of someone with
provenpackager status in order to make the spec file changes that are
required.
* '''Release engineering:''' [https://pagure.io/releng/issue/9829
#9829] (a check of an impact with Release Engineering is needed)
* '''Policies and guidelines:''' The packager guidelines will need to
be updated to mention that BuildRequires: make is now required for all
packages that need make.
* '''Trademark approval:''' N/A (not needed for this Change)
* '''Alignment with Objectives:''' This aligns with the Fedora
Minimization [https://pagure.io/minimization/issue/12 objective].
== Upgrade/compatibility impact ==
This should not impact upgrades.
== How To Test ==
This change can be tested by rebuilding affected packages. The goal
is to complete this before the mass rebuild to ensure maximum testing
coverage.
== User Experience ==
Fedora users will not notice any difference with this change. This
will only impact Fedora package maintainers.
== Dependencies ==
gcc < 11 will fail if the -flto=auto option is used when make is not
installed. Phase 3 cannot be completed until gcc 11 lands in rawhide,
but Phase 1 and Phase 2 are not blocked by this.
== Contingency Plan ==
* '''Contingency mechanism:''' If we discover critical issues during
phase 4, then Fedora Release Engineering will need to re-add make into
the buildroot.
* '''Contingency deadline:''' 2021-02-23 (F34 Beta Freeze)
* '''Blocks release?''' No
* '''Blocks product?''' No
== Documentation ==
The packager guidelines will need to be updated to mention that
BuildRequires: make is now required for all packages that need make.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/ModularGnomeKeyring
== Summary ==
The monolithic daemon provided by GNOME Keyring will be split into
dedicated sub-daemons, so that they can be consistently managed by
systemd.
== Owner ==
* Name: [[User:ueno|Daiki Ueno]]
* Email: dueno(a)redhat.com
* Name: [[User:benzea|Benjamin Berg]]
* Email: bberg(a)redhat.com
* Product: Workstation
* Responsible WG: Workstation
== Detailed Description ==
GNOME Keyring provides multiple services from a single daemon program
called gnome-keyring-daemon. This daemon is launched by the session
manager (gnome-session) or PAM, depending on desktop environments.
That design makes troubleshooting hard when any issue arises, as well
as the individual services cannot be easily turned off.
Despite its original goal to be the central cryptographic service on
desktop, the scope of GNOME Keyring has been gradually reduced over
years. Notable examples are
[https://bugzilla.gnome.org/show_bug.cgi?id=750514 gpg-agent removal]
in 2015, [https://bugzilla.gnome.org/show_bug.cgi?id=791401 PKCS #11
module deprecation] and
[https://bugzilla.gnome.org/show_bug.cgi?id=775981 ssh-agent rewrite
to wrap ssh-agent from OpenSSH] in 2018. Now that only the essential
services remaining in gnome-keyring-daemon are D-Bus secret-service
and the ssh-agent wrapper, it would be straightforward to split the
daemon into sub-daemons per functionality.
== Benefit to Fedora ==
This will bring in consistent experience of setting up and managing
the individual services provided by GNOME Keyring, taking advantage of
systemd service manager.
== Scope ==
* Proposal owners: gnome-keyring-daemon currently provides 3 services:
D-Bus secret-service, ssh-agent wrapper, and a control socket for PAM
to automatically unlock the login keyring. Those services are either
split out, or removed in favor of other means, in the following steps:
** Make the D-Bus secret-service D-Bus activatable
** Make the ssh-agent wrapper service socket activatable
** Move the ssh-agent wrapper service to gcr
** Modify the PAM module to use libsecret API to unlock the login
keyring, instead of the control socket
** Install systemd unit files for those services, modify the current
session initialization sequence to use them
** (Stretch goal) move the D-Bus secret-service implementation to libsecret
** (Stretch goal) remove the gnome-keyring package from the default compose
* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Check if the GNOME Keyring services are now managed by systemd, using
systemctl status. Check if the existing applications (Seahorse, SSH
clients, etc.) still work.
== User Experience ==
No visible change should be observed by normal users.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Stratis_2.2.0
Stratis 2.2.0 now places Stratis filesystem symlinks in /dev/stratis,
rather than /stratis. Stratis creates and maintains the symlinks by
means of udev rules, rather than directly via stratisd as previously.
The /stratis directory is neither created nor used by stratisd 2.2.0.
== Owner ==
* Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]],
[[User:jbaublitz|John Baublitz]]
* Email: dkeefe(a)redhat.com, amulhern(a)redhat.com, jbaublitz(a)redhat.com
== Detailed Description ==
=== Stratisd 2.2.0 ===
This release creates and maintains Stratis filesystem symlinks in
/dev/stratis by means of udev rules. It includes a small Rust script,
stratis_uuids_to_names which is invoked by the Stratis udev rule which
sets the Stratis filesystem symlinks.
In the case where stratisd is updated in place, some filesystem
symlinks may remain in /stratis. This release includes a shell script,
stratis_migrate_symlinks.sh which may be used to clean up the /stratis
directory and ensure that the correct symlinks exist in /dev/stratis.
The script removes the /stratis directory once it has completed
without error. The shell script relies on a small Rust script,
stratis_dbusquery_version which is included with this version of
stratisd.
This release also extends the D-Bus interface in a few ways:
It sends org.freedesktop.DBus.ObjectManager.InterfacesAddedand
org.freedesktop.DBus.ObjectManager.InterfacesRemoved signals on the
D-Bus whenever a D-Bus object is added to or removed from the D-Bus
interface.
It adds a new D-Bus property, PhysicalPath, for the
org.storage.stratis2.blockdev.r2 interface. This property is
principally useful for encrypted Stratis block devices; it identifies
the block device on which the Stratis LUKS2 metadata resides.
It adds a new key, LockedPools, to the
org.storage.stratis2.FetchProperties.r2 interface for objects that
implement the org.storage.stratis2.Manager interface. This key returns
a D-Bus object that maps the UUIDs of locked pools to their
corresponding key descriptions.
Please consult the D-Bus API Reference for the precise D-Bus specification.
This release allows the user to specify their preferred log level more
directly and succinctly with the --log-level CLI option.
This release includes management of terminal settings for interactive
encryption-key entry.
This release includes some unsupported scripts which may be built from
the source distribution but are not intended to be released as part of
any package. These scripts depend on the extras feature in Cargo.toml.
This release also includes a number of minor bug fixes.
== Detailed Description ==
=== Stratis-cli 2.2.0 ===
This release requires stratisd 2.2.0. Some commands have been updated
to make use of the new stratisd D-Bus interfaces.
This release drops management of terminal settings for interactive
encryption-key entry; management of terminal settings is now handled
in stratisd 2.2.0.
== Feedback ==
== Benefits to Fedora ==
Users of Fedora will now benefit from Stratis 2.2.0 by:
* Devices being located in an existing and known top level directory.
* Applications that are restricted from using non-default top level
directories can now use Stratis symlinks
* Better integration with udev
== Scope ==
* Proposal owners:
** Update existing stratis-cli package to specify new release
** Update existing stratisd package to specify new release
* Other developers: N/A
* Release engineering: Self Contained
* Policies guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
Stratis symlinks have moved. Existing symlinks in /stratis/<pool
name>/<filesystem name> will need to be migrated to
/dev/stratis/<pool name>/<filesystem name>. This is accomplished by
running the migration script (stratis_migrate_symlinks.sh) that comes
with the
2.2.0 release of Stratis or rebooting the system. Any configurations
that make use of the old symlink locations will
need to be updated to use the new location. So, if there has been
manual changes to systemd unit files or /etc/fstab
for automatically mounting Stratis filesystems, then these will need
to be updated to reflect the change.
== How To Test ==
* Testing new filesystem paths can be done using the CLI provided by
stratis-cli package or D-Bus API provided by stratisd
package.
* Create a pool and filesystem using stratis command
stratis pool create p1 /dev/sdb
stratis fs create p1 fs1
* Check that the new path is in /dev/stratis/<pool name>/<filesystem name>
ls /dev/stratis/<pool name>
stratis fs list
== User Experience ==
Users with existing Stratis filesystems will notice a change in the
filesystem path from /stratis/<pool name>/<filesystem name> to
/dev/stratis/<pool name>/<filesystem name>. Appropriate action will
need to be taken to update system configurations that
make use of the older filesystem paths.
== Dependencies ==
We are not aware of any new dependencies
== Contingency Plan ==
* Contingency mechanism:
* Contingency deadline: N/A
* Blocks release? No
* Blocks product? No
== Documentation ==
Please see https://stratis-storage.github.io/ for design documents and
API reference.
Development and issue tracking is at https://github.com/stratis-storage/
== Release Notes ==
Includes recent version of Stratis
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis