Important process note: we are experimenting with using Fedora
Discussion as part of the Changes process. Change announcements (like
the one you are reading right now) will still be sent to the
devel-announce mailing list, but the conversation about each change
will take place on Fedora Discussion at
https://discussion.fedoraproject.org/t/f40-change-request-privacy-preservin…
This will follow the same process as before, just with discussion in a
different format
https://docs.fedoraproject.org/en-US/program_management/changes_policy/
You can subscribe to and interact with these conversations by email.
See https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-…
for detailed instructions. To make sure you do not miss anything, make
sure that you have the Change Proposal category set to “Watching” —
or, if you just want to get notified about new changes but not every
reply in the conversation, to “Watching First Post”. (Click on the
little bell icon at the top right of the category page.)
The below 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 Red Hat Display Systems Team (which develops the desktop) proposes
to enable limited data collection of anonymous Fedora Workstation
usage metrics.
Fedora is an open source community project, and nobody is interested
in violating user privacy. We do not want to collect data about
individual users. We want to collect only aggregate usage metrics that
are actually needed to achieve specific Fedora improvement objectives,
and no more. We understand that if we violate our users' trust, then
we won't have many users left, so if metrics collection is approved,
we will need to be very careful to roll this out in a way that
respects our users at all times. (For example, we should not collect
users' search queries, because that would be creepy.)
We believe an open source community can ethically collect limited
aggregate data on how its software is used without involving big data
companies or building creepy tracking profiles that are not in the
best interests of users. Users will have the option to disable data
upload before any data is sent for the first time. Our service will be
operated by Fedora on Fedora infrastructure, and will not depend on
Google Analytics or any other controversial third-party services. And
in contrast to proprietary software operating systems, you can
redirect the data collection to your own private metrics server
instead of Fedora's to see precisely what data is being collected from
you, because the server components are open source too.
Keep in mind this Fedora change proposal is just that: a proposal. It
must undergo community review and must be approved by the
community-elected Fedora Engineering Steering Committee (FESCo) before
it can be implemented, just like any other Fedora change proposal. We
welcome community participation and fully expect this proposal may
need to be modified significantly depending on Fedora community
feedback.
== Owner ==
* Name: [[User:catanzaro|Michael Catanzaro]]
* Email: <mcatanzaro(a)redhat.com>
== Detailed Description ==
We intend to deploy the Endless OS metrics system.
[https://blogs.gnome.org/wjjt/2023/07/05/endless-oss-privacy-preserving-metr…
This blog post] contains a description of how the system works. We do
not plan to deploy the eos-phone-home component in Fedora.
=== How will data collection be approved? ===
The proposal owners feel it is essential to ensure the Fedora
community has ultimate oversight over metrics collection. Community
control is required to maintain user trust. If this change proposal is
approved, then we'll need new policies and procedures to ensure
community oversight over metrics collection and ensure Fedora users
can be confident that our metrics collection does not violate their
privacy.
We can say "we would never collect personally-identifiable data" and
write software that really doesn't collect any such data, but this
alone will never be enough to ensure user confidence. We will need a
metrics collection policy that describes what sort of data may be
collected by Fedora (anonymous, non-invasive), and what sort of data
may not be collected. Such a policy does not exist currently. We will
also want to ensure the Fedora community has ultimate control over
which particular metrics are collected. One option is that each metric
to be collected should be separately approved by FESCo. Collection of
particular metrics in a particular data format is ultimately an
engineering decision, and therefore FESCo seems like an appropriate
approval point. Because FESCo members are elected regularly by the
Fedora community, this also provides the community with ultimate
control over metrics collection via the election process. But other
oversight and approval structures would work too.
=== What data might we collect? ===
We are not proposing to collect any of these particular metrics just
yet, because a process for Fedora community approval of metrics to be
collected does not yet exist. That said, in the interests of maximum
transparency, we wish to give you an idea of what sorts of metrics we
might propose to collect in the future.
One of the main goals of metrics collection is to analyze whether Red
Hat is achieving its goal to make Fedora Workstation the premier
developer platform for cloud software development. Accordingly, we
want to know things like which IDEs are most popular among our users,
and which runtimes are used to create containers using Toolbx.
Metrics can also be used to inform user interface design decisions.
For example, we want to collect the clickthrough rate of the
recommended software banners in GNOME Software to assess which banners
are actually useful to users. We also want to know how frequently
panels in gnome-control-center are visited to determine which panels
could be consolidated or removed, because there are other settings we
want to add, but our usability research indicates that the current
high quantity of settings panels already makes it difficult for users
to find commonly-used settings.
Metrics can help us understand the hardware we should be optimizing
Fedora for. For example, our boot performance on hard drives dropped
drastically when systemd-readahead was removed. Ubuntu has maintained
its own readahead implementation, but Fedora does not because we
assume that not many users use Fedora on hard drives. It would be nice
to collect a metric that indicates whether primary storage is a solid
state drive or a hard disk, so we can see actual hard drive usage
instead of guessing. We would also want to collect hardware
information that would be useful for collaboration with hardware
vendors (such as Lenovo), such as laptop model ID.
Other Fedora teams may have other metrics they wish to collect. For
example, Fedora localization wishes to count users of particular
locales to evaluate which locales are in poorer shape relative to
their usage.
This is only a small sample of what we might want to know; no doubt
other community members can think of many more interesting data points
to collect. But note the purpose of all of the above metrics is to
inform specific design decisions, not to build tracking profiles. We
only need to collect data in aggregate, and have no need to associate
the data we collect with particular users.
=== Metrics transparency ===
Transparency is required to provide confidence that Fedora metrics
collection is not creepy or invasive. Since Fedora is open source, a
developer can review the source code to verify exactly what it is
doing and what data is being collected. But most Fedora users are not
software developers, and few software developers have time or
inclination to review the source code of the operating system to see
what it is doing. To retain user trust, we need an easy way for users
to understand exactly what data we are collecting. We propose to
maintain a documentation page showing the current metrics database
schema, so users can see exactly which fields are in the database and
what example data looks like.
Experienced users may gain additional confidence by building and
running their own metrics collection server; all of the components of
the server (discussed below) are open source, and we will provide
instructions for how to run a simple server yourself and view its
metrics database. You can redirect metrics from Fedora's server to
your own by changing a URL in a configuration file.
=== User control ===
A new metrics collection setting will be added to the privacy page in
gnome-initial-setup and also to the privacy page in
gnome-control-center. This setting will be a toggle that will enable
or disable metrics collection for the entire system. We want to ensure
that metrics are never submitted to Fedora without the user's
knowledge and consent, so the underlying setting will be off by
default in order to ensure metrics upload is not unexpectedly turned
on when upgrading from an older version of Fedora. However, we also
want to ensure that the data we collect is meaningful, so
gnome-initial-setup will default to displaying the toggle as enabled,
even though the underlying setting will initially be disabled. (The
underlying setting will not actually be enabled until the user
finishes the privacy page, to ensure users have the opportunity to
disable the setting before any data is uploaded.) This is to ensure
the system is opt-out, not opt-in. This is essential because we know
that opt-in metrics are not very useful. Few users would opt in, and
these users would not be representative of Fedora users as a whole. We
are not interested in opt-in metrics.
To make this a little more confusing, metrics collection is actually
separate from uploading. Collection is always initially enabled, while
uploading is always initially disabled. The graphical toggle enables
or disables both at the same time. That is, a newly-installed Fedora
system will always collect metrics locally at first, but the collected
metrics will be deleted and never submitted to Fedora if the user
disables the metrics collection toggle on the privacy page. If the
user leaves the toggle enabled, then the collected metrics may be
submitted only after finishing the privacy page.
Metrics uploading will be opt-in for users who upgrade from previous
versions of Fedora Workstation, because we don't yet have a mechanism
to ask the user to consent to data collection after a system upgrade
like we do for new installations, but metrics collection will be
opt-out. That is, your upgraded system will collect metrics locally
but will never submit them to Fedora. If you visit the privacy page in
gnome-control-center, then both collection and uploading will be
either enabled or disabled depending on the user's selection. Unlike
gnome-initial-setup, the switch in gnome-control-center will default
to off if the user has not seen the switch in gnome-initial-setup and
has not previously selected a value for the setting.
This might sound complicated, but it is consistent. If the user has
not yet made a decision whether to allow telemetry, we collect it
locally so that it's ready to submit if the user approves telemetry in
the future, but we never upload it. Once the user makes a decision,
then we either upload it or delete it and stop collecting.
=== GDPR ===
It is Fedora Legal's obligation to ensure our data collection complies
with legal requirements in the jurisdictions in which Red Hat
operates. This is not an obligation of the Fedora community, so there
is no need to discuss GDPR rules on our mailing lists. The proposal
owners will not respond to mailing list posts that discuss GDPR or
similar legal obligations during this change proposal discussion. In
short, let's keep discussion focused on what Fedora SHOULD or SHOULD
NOT do, rather than what we MUST or MUST NOT do.
That said, Fedora Legal has determined that if we collect any
personally-identifiable data, the entire metrics system must be
opt-in. Since we are only interested in opt-out metrics due to the low
value of opt-in metrics, we must accordingly never collect any
personally-identifiable data. We must also not collect any data that
could become personally-identifiable if combined with other data,
which notably means IP addresses must not be stored. We only want to
collect anonymous data anyway, but we need to be especially mindful of
the possibility that combining two "anonymous" data points could
result in the data no longer being anonymous.
=== Fedora data collection policy ===
Fedora Legal requires that we publish a Fedora data collection policy
separate from the existing
[https://fedoraproject.org/wiki/Legal:PrivacyPolicy Fedora Privacy
Policy], which is designed to address usage of Fedora websites. This
is currently a work in progress that we're not quite ready to share
yet. You can expect it to be very short and very generic.
=== Metrics server infrastructure ===
We propose to deploy Azafea, the open source metrics collection server
used by Endless OS. An Azafea deployment consists of five components:
an nginx proxy server,
[https://github.com/endlessm/azafea-metrics-proxy
azafea-metrics-proxy], redis, [https://github.com/endlessm/azafea
azafea itself], and a Postgres database. nginx proxies HTTP requests
to azafea-metrics-proxy, which is itself a simple HTTP server that
adds metrics into the redis database, where they will be fetched by
Azafea and stored into Postgres. We will provide instructions on how
to set up your own server and see for yourself what data gets
collected.
=== Metrics client infrastructure ===
The client side consists of [https://github.com/endlessm/eos-metrics
eos-metrics], [https://github.com/endlessm/eos-event-recorder-daemon
eos-event-recorder-daemon], and
[https://github.com/endlessm/eos-metrics-instrumentation
eos-metrics-instrumentation]. eos-metrics is a D-Bus interface that
applications and services may use to record events, plus a GObject
library that provides a simple API around the D-Bus interface.
eos-event-recorder-daemon is the service that actually implements this
interface: it collects incoming metrics, batches them together, and
sends them to the metrics server at predefined intervals.
eos-metrics-instrumentation is the component that actually collects
specific metrics. Originally, we had planned to not use this component
and instead write our own fedora-metrics-instrumentation that would
collect only a few particular metrics that are approved via Fedora
community process. However, currently we are planning to ship
eos-metrics-instrumentation and instead ensure that it is not
collecting more metrics than would be acceptable to the Fedora
community. A review process to decide which metrics to collect and
which metrics to disable will be required.
=== Data set considerations ===
Although we assume the metrics server administrator is not malicious
and will not actively attempt to deanonymize users, we will still take
reasonable precautions to make it difficult to correlate metrics to a
particular user, starting by not storing any IP address information in
the metrics database. Additionally, each metric that we collect will
be considered individual, non-correlatable data by default, unless
approved to be correlated with particular other metrics via future
Fedora community process. That is, if a user submits two data points,
we usually don't want the ability to know that these data points were
both submitted by the same user.
Each metric is stored in the database with a Unix timestamp indicating
when it was generated on the client. If abused, this timestamp could
allow correlation of data points that are collected at the same time
as each other, or at a fixed time offset to other events. For example,
if the system were designed to collect two metrics exactly 300 seconds
after the system were booted, then just looking at the timestamps
would be enough to determine that both metrics recorded at the same
time were submitted by the same user. Accordingly, we should consider
modifying the metrics server to reduce timestamp granularity at least
somewhat.
=== History ===
Currently Fedora's only form of metrics collection is
[https://fedoraproject.org/wiki/Changes/DNF_Better_Counting DNF Better
Counting], but this only counts Fedora installations. That is useful,
but we want to count more than just how many users we have.
Fedora's first metrics collection attempt was
[https://en.wikipedia.org/wiki/Smolt_(Linux) Smolt], a precursor to
hw-probe which collected data on user hardware. The current proposal
is different from Smolt because it will collect more than just
hardware data, and also because Smolt collected only opt-in data. The
current proposal would be opt-out, not opt-in.
This change proposal will likely be compared to the Ubuntu spyware
complaints from a decade ago, when Ubuntu desktop users' search
queries were sent to Amazon by default. Let's not do that.
== Feedback ==
We will endeavor to update this section of the change proposal to
include a summary of Fedora community discussion of this proposal.
== Benefit to Fedora ==
The main benefit to Fedora is that we will be able to use collected
metrics to inform design decisions. It is very common for developers
to wish to know something about how Fedora software is used, and we
will finally have a way to answer such questions.
Occasionally, Red Hat might need to collect specific metrics to
justify additional time spent on contributing to Fedora or additional
investment in Fedora.
== Scope ==
* Proposal owners:
This change requires substantial technical and nontechnical work from
the change owners. Most notably, we will need to package eos-metrics,
eos-event-recorder-daemon, and eos-metrics-instrumentation properly
for Fedora; they are currently packaged in a copr. We also still need
to modify eos-metrics-instrumentation so that it does not send events
not approved for use in Fedora, as we expect to collect less data than
Endless OS.
* Other developers:
This proposal will require substantial effort by Community Platform
Engineering (CPE) to host the metrics server infrastructure.
* Release engineering: [https://pagure.io/releng/issues/11514 #11514]
* Policies and guidelines: New processes and guidelines are proposed
above under the section "How will data collection be approved?"
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: This change does not align with any
current [https://docs.fedoraproject.org/en-US/project/initiatives/
Fedora Initiatives], which are very limited in scope. That said, one
of the main purposes of metrics collection is to determine whether we
are achieving other objectives not listed on the wiki page. For
example, we want Fedora Workstation to become the premier developer
workstation operating system. To that end, we want to know how many of
our users are using particular IDEs.
== Upgrade/compatibility impact ==
We would like to enable metrics upload for upgraded systems, but this
isn't trivial because we want to obtain user consent before enabling
metrics upload. This would require us to design a user interface that
would run on upgraded systems and present the setting to users. We
have not yet created such a user interface, so for now metrics upload
will need to default to disabled for systems upgraded from older
versions of Fedora. Since the underlying setting will be off by
default, we don't need to do anything special to achieve this.
== How To Test ==
The ultimate goal is to see metrics appear in the Postgres database of
a metrics server, but configuring and running the server is not
trivial. Accordingly, we propose to publish a separate document
detailing how to set up and configure a metrics server for testing
purposes, how to redirect metrics to the custom server, and how to
force the client to immediately submit metrics to ease testing.
Although we don't actually expect many community members to seriously
run their own metrics servers, we still want to document the steps
involved so that interested developers can see exactly how it works.
== User Experience ==
A new metrics collection setting will be added to the privacy page in
gnome-initial-setup and also to the privacy page in
gnome-control-center. This setting will be a simple toggle that will
enable or disable all metrics upload for the entire system. Users who
do not want any metrics upload should feel confident that uploading
can be disabled with a simple toggle.
Fedora users should be confident that Fedora metrics collection
respects their privacy and collects only limited, anonymous usage
data.
== Dependencies ==
Any package that wishes to collect a metric would need to depend on
eos-metrics. For example, if we were to collect statistics on which
system settings panels are used most frequently, then the
gnome-control-center package would need to depend on eos-metrics in
order to send a metric to eos-event-recorder-daemon.
== Contingency Plan ==
* Contingency mechanism: We would need to remove the eos-metrics,
eos-event-recorder-daemon, and eos-metrics-instrumentation packages
from the workstation-product comps group, and rebuild any packages
that gained a dependency on eos-metrics.
* Contingency deadline: Beta freeze
* Blocks release? Yes, if the change is incomplete, it will need to be
reverted before release.
== Documentation ==
This feature will depend on several different upstream projects with
varying amounts of documentation.
The client side consists of eos-metrics, eos-event-recorder-daemon,
and eos-metrics-instrumentation. The best documentation of eos-metrics
available online is its
[https://github.com/endlessm/eos-metrics/blob/master/data/com.endlessm.Metri…
D-Bus interface XML]. eos-metrics also contains normal API
documentation that will be built and installed in a docs subpackage,
but this is not currently available online. The
eos-event-recorder-daemon and eos-metrics-instrumentation components
do not appear to have any online documentation.
On the server end, the metrics server consists of azafea-metrics-proxy
feeding metrics into redis, where they will be pulled by azafea and
then added to a Postgres database. Documentation for
[https://github.com/endlessm/azafea-metrics-proxy/tree/master/docs/source
azafea-metrics-proxy] and
[https://github.com/endlessm/azafea/tree/master/docs/source azafea]
can be reviewed online.
[https://azafea.readthedocs.io/en/latest/events.html Events recognized
by the server are documented here.] Note that this documentation is
currently focused on use by Endless OS rather than by Fedora, and
includes documentation of many events that are no longer sent by
Endless OS. This change proposal does not propose to enable sending
any particular events in Fedora.
== Release Notes ==
Release Notes are not required for initial proposal. We need to write
the release notes before change freeze.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/Indic_Noto_fonts
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee
== Summary ==
Google Noto fonts for Indic (Indian) languages replace the default Lohit fonts
== Owner ==
* Name: [[User:Petersen| Jens Petersen]]
* Email: <petersen(a)redhat.com>
* Name: Sudip Shill
* Email: <sshil(a)redhat.com>
== Detailed Description ==
Currently the Lohit fonts are installed and used by default for Indian
languages (Indic scripts).
However the Lohit project is essentially inactive and at best in
maintenance mode now.
So we will change the default to Google's Noto Indic fonts, which are
available in both Sans and Serif faces with multiple weights and as
variable fonts.
This should provide a more flexible modern maintained set of fonts for
Indic language scripts.
== Feedback ==
There was some [https://lists.fedoraproject.org/archives/list/fonts@lists.fedoraproject.org…
initial discussion on fonts list, etc], which was generally positive.
This started with:
* comparison screenshots:
https://sshil.fedorapeople.org/lohit-vs-noto-comparison.html
* a copr repo for testing:
http://copr.fedorainfracloud.org/coprs/sshil/indic-fonts-test
== Benefit to Fedora ==
Wider range of Indic (Indian) fonts will be available by default as
variable fonts in both sans and serif faces with various weight
styles.
== Scope ==
* Proposal owners:
** update Indic langpacks (default-fonts) to use Noto fonts
** update the Noto and Lohit fonts packages so that Noto Indic fonts
have higher priority
** change comps @fonts (through default-fonts) from Lohit to the
corresponding Noto Indic fonts
** update ostree desktops to use Noto Indic
** update lorax to use Noto for Indic fonts
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/11502 #11502]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
Lohit fonts will continue to be available, but assuming the
[https://fedoraproject.org/wiki/Changes/ImproveDefaultFontHandling
default-fonts] Change is implemented
users will be moved to use Noto Indic fonts by default on upgrade.
Nevertheless advanced users can use `fonts-tweak-tool` to change the
priority of one or more Lohit fonts to be higher than Noto if they so
wish.
== How To Test ==
* install/test default/Noto fonts on various desktops and their applications
* test Noto Indic with and without Lohit fonts installed
* test rendering of Indic scripts in applications/websites
* test upgrades from Fedora 38
* test if removing Noto Indic (and (re-)installing Lohit) still allows
using Lohit as a second default.
* (advanced) revert the font priorities using the user fonts-tweak-tool.
== User Experience ==
== Dependencies ==
Not really a direct dependency, but we currently plan to implement
this using the new `default-fonts` metapackages.
== Contingency Plan ==
* Contingency mechanism: Change owners will revert the changes back to
using Lohit by default
* Contingency deadline: before final freeze
* Blocks release? Yes
== Documentation ==
https://sshil.fedorapeople.org/lohit-vs-noto-comparison.html
== Release Notes ==
Google Noto fonts are now installed and used for Indic scripts (Indian
language) by default instead of Lohit fonts.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/IBus_1.5.29
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.29 will work with Plasma Wayland more closely using the
Wayland protocol.
== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com
== Detailed Description ==
* IBus will be able to switch the keyboard layouts with the panel icon
menu in Plasma Wayland.
* IBus will be able to show the candidate popup window near the input
cursor in Plasma Wayland.
* IBus will be able to switch the keyboard layouts with the shortcut
key in Plasma Wayland.
== Feedback ==
== Benefit to Fedora ==
IBus will use Wayland input-method protocol in Plasma Wayland and
handle the key events and switch keyboard layouts and the position the
candidate popup window.
== Scope ==
* Proposal owners: ibus 1.5.29
* Other developers: [[AkiraTagoh| Akira TAGOH]]
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
You need to unset QT_IM_MODULE and GTK_IM_MODULE environment variables
in Plasma Wayland desktop only but not Plasma Xorg desktop and follow
the Setup section below.
== How To Test ==
=== Setup ===
# Install Plasma Wayland desktop and Log into the desktop session.
# Run konsole and type `env` and if you find `QT_IM_MODULE=ibus` or
`GTK_IM_MODULE=ibus`, you need to run im-chooser and select "No Input
Method" and make sure `QT_IM_MODULE` and `GTK_IM_MODULE` environment
variables are not set on konsole.
# Run systemsettings5 and open "Input Devices" -> "Virtual Keyboard"
and select "IBus Wayland" and press "Apply" button.
# Focus on the konsole input context and IBus panel icon will be shown.
=== Panel Menu ===
# Run kwrite and open a new document.
# Focus on the input context in kwrite and click IBus panel icon to
show the panel menu.(May need to click kwrite again to open the menu)
# Select a keyboad layout on the panel menu and IBus can switch the
keyboard layouts.
=== Input Method List with Shortcut Key ===
# Run kwrite and open a new document.
# Focus on the input context in kwrite and type Super-space to show
the input method engine popup window.(May need to click kwrite again
to open the popup)
# Select a keyboad layout on the popup window with some space keys
pressing Super key and IBus can switch the keyboard layouts.
== User Experience ==
IBus had not supported to switch the keyboard layouts since Plasma
Wayland has been integrated in Fedora but now IBus can switch both the
keyboard layouts and input method engines and IBus candidate window is
now shown near the input cursor and those are useful for the users.
== Dependencies ==
Other IBus packages and KDE packages don't need to be rebuilt.
We use systemsettings5 to enable IBus in Plasma wayland as the first
implementation. The configuration with imsettings is nice to have in
Fedora 39 GA but will be implemented later.
== Contingency Plan ==
* Contingency mechanism: Revert the change to ibus.
* Contingency deadline: Beta release
* Blocks release? No
== Documentation ==
TBD
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/MigrateIfcfgToKeyfile
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 ==
Migrate NetworkManager network connection profiles stored in ifcfg
format to the keyfile format.
== Owner ==
* Name: [[User:bengal| Beniamino Galvani]], [[User:ffmancera| Fernando
Fernández Mancera]], [[User:Till| Till Maas]]
* Email: <bgalvani(a)redhat.com>, <ferferna(a)redhat.com>, <till(a)fedoraproject.org>
== Detailed Description ==
NetworkManager supports different formats to persist connection
profiles to disk. On Fedora the two formats used are ''keyfile'' and
''ifcfg''. The former stores connections in
`{/etc,/usr/lib,/run}/NetworkManager/system-connections` in a format
similar to INI files. Connections in ifcfg format are compatible with
the legacy network scripts and are saved in
`/etc/sysconfig/network-scripts` as a collection of shell variables.
Not all connection types are supported by ifcfg, and NetworkManager
always uses the keyfile format for unsupported types.
Since [https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_if…
Fedora Linux 33], NetworkManager writes profiles by default in the
keyfile format. Also, since
[https://fedoraproject.org/wiki/Changes/NoIfcfgFiles Fedora Linux 36]
the plugin to persist ifcfg files is included in a separate package
(`NetworkManager-initscripts-ifcfg-rh`) and is not shipped in new
installations.
The upstream NetworkManager project has recently declared the ifcfg
plugin as [https://lists.freedesktop.org/archives/networkmanager/2023-May/000103.html
deprecated]. This means that the code will only receive bug fixes,
and will not get new functionality such as supporting new properties.
With this change, existing profiles in ifcfg format will be
automatically migrated to the native keyfile format via a migration
service shipped with the `NetworkManager-initscripts-ifcfg-rh`
package. In Fedora, we plan to drop the plugin by Fedora Linux 41.
== Benefit to Fedora ==
Until recently, both keyfile and ifcfg supported the same set of
properties. With the ifcfg deprecation, new properties are only
implemented for the keyfile plugin and not for ifcfg. When users try
to set an unsupported property on a ifcfg profile, they get an error:
$ nmcli connection modify ethernet-enp1s0 link.tx-queue-length 1234
Error: Failed to modify connection 'ethernet-enp1s0': failed to
update connection: The ifcfg-rh plugin doesn't support setting 'link'.
If you are modifying an existing connection profile saved in ifcfg-rh
format, please migrate the connection to keyfile using 'nmcli
connection migrate c3f6f067-e1d5-4bb1-8d67-e09109253a79' or via the
Update2() D-Bus API and try again.
At the moment there are only 4 unsupported properties but the list is
going to increase with time. Furthermore, ifcfg support will be
dropped in future versions of NetworkManager.
The benefit of this change is that users having ifcfg files will be
migrated to the more modern and future-proof format supporting all the
functionalities offered by NetworkManager.
== Scope ==
* Proposal owners: introduce a migration service and ship it with the
`NetworkManager-initscripts-ifcfg-rh` package
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
The majority of users will not be impacted by the change. Only users
that meet all the following criteria will be affected:
* the user is upgrading from a previous Fedora version
* the user has the the NetworkManager-initscripts-ifcfg-rh package installed
* the user has at least one connection profile stored in ifcfg format
Since keyfile was made the default in Fedora 33, and ifcfg was dropped
from new installations in Fedora 36, the only scenarios in which users
meet those criteria are:
* the user originally installed Fedora 32 or a previous version
* the user installed Fedora 33 or later, then manually switched the
default plugin to “ifcfg-rh” in the configuration and then added new
connections
* the user installed Fedora 36 or later, explicitly installed the
NetworkManager-initscripts-ifcfg-rh package, manually switched the
default plugin to “ifcfg-rh” in the configuration and then added new
connections
== How To Test ==
* Install the NetworkManager-initscripts-ifcfg-rh package
* Restart NetworkManager
* Migrate a connection to ifcfg-rh via nmcli: `nmcli connection
migrate --plugin ifcfg-rh $NAME`
* Check that the migration had effect with `nmcli -f name,filename
connection`: the profile should now be stored in
`/etc/sysconfig/network-scripts`
* Upgrade to Fedora 39
* Check that all profiles are now stored in
`/etc/NetworkManager/system-connections` in keyfile format.
== User Experience ==
For users that are affected by the migration, there should not be any
observable change in behavior. The keyfile format supports a superset
of the features supported by ifcfg. Furthermore, the migration is done
by the NetworkManager daemon using the same code path used to store
new connections in keyfile format. Any bug in the migration would also
affect the creation of new connections.
If users have custom scripts or tools that parse the ifcfg files,
those will break and need to be adjusted. One notable example of such
tools is in package `initscripts-rename-device`, which provides a udev
helper to rename interfaces based on the MAC and interface name found
in ifcfg files. Users relying on this mechanism will need to switch to
systemd .link files (or udev rules) to perform the renaming.
The release notes for the Fedora version shipping this change will
mention these aspects.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Revert the change, try again the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? no
== Documentation ==
No doc change required.
== Release Notes ==
The change will be mentioned in the Release Notes.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/KDEKinoiteAutoUpdateByDefault
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 ==
On Fedora Kinoite, Plasma Discover supports automatically updating the
system in a safe fashion via rpm-ostree staged updates. We want users
to benefit from bug fixes and updates in general by default thus we
want to enable auto-updates by default. Users will still have the
option of disabling that or tuning the frequency at which updates
happen.
== Owner ==
* Name: [[User:Siosm|Timothée Ravier]], [[User:Ngompa|Neal Gompa]]
* Email: <siosm(a)fedoraproject.org>, <ngompa(a)fedoraproject.org>
== Detailed Description ==
We will enable a setting named "Unattended Updates" in Plasma Discover
that will enable background updates by default in new installations
and existing installations. This process uses rpm-ostree staged
updates support to download and prepare the new version of the system
in the background, which is then used on reboot.
The user will only be notified to reboot their system once the updates
have been applied and once a given amount of time has passed before
the last time an update was applied.
Pull request for the change:
https://pagure.io/workstation-ostree-config/pull-request/393
Bugs related to the change (that the change owner will fix):
* https://bugs.kde.org/show_bug.cgi?id=471548
* https://bugs.kde.org/show_bug.cgi?id=454422
== Feedback ==
None so far.
== Benefit to Fedora ==
Users benefit from updates quickly and by default. Users don't have to
worry about updating their system anymore.
== Scope ==
* Proposal owners: Implement and test the change
(https://pagure.io/workstation-ostree-config/pull-request/393)
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: N/A
== Upgrade/compatibility impact ==
All Kinoite systems updated to Fedora 39 will have this setting set by
default if the options have not been changed manually before.
== How To Test ==
Run `echo -e "[Global]\nUseUnattendedUpdates=true\n" >
/etc/xdg/PlasmaDiscoverUpdates` as `root` and reset the Update setting
page to the defaults. The system should now download updates
automatically and asks for a reboot once a week.
== User Experience ==
User will not have to manually check for updates, they will be applied
automatically in the background. After a week without a reboot, they
will be offered to reboot to apply system updates.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Push the change to the next release or undo the change.
* Contingency deadline: N/A. Any time before we GA
* Blocks release? No
== Documentation ==
None needed.
== Release Notes ==
Update on Fedora Kinoite are now downloaded automatically and applied
on the next reboot.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/GNUToolchainF39
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
=== Update core components ===
Update the Fedora 39 GNU Toolchain to gcc 13.2, binutils 2.40, glibc
2.38 and gdb 13.2.
The set of core GNU Toolchain packages for Fedora 39 are as follows:
* GNU C Compiler 13.2 (Expected in August 2023)
** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp),
Fortran (gfortran), D (phobos), Objective C/C++.
* GNU Binary Utilities 2.40 (Released February 2023)
* GNU C Library 2.38 (Expected August 2023)
* GNU Debugger 13.2 (Released May 2023)
** Note: Already available in Fedora 38.
The gcc 13.2 change will be tracked in this top-level GNU Toolchain
system-wide update. Currently Fedora Rawhide and 38 are already using
gcc 13.1, and 13.2 is expected to release in August 2023 with
additional fixes.
The binutils 2.40 change will be tracked in this top-level GNU
Toolchain system-wide update. Currently Fedora Rawhide has been
testing binutils 2.40 since Feburary 13th, 2023.
The glibc 2.38 change will be tracked in this top-level GNU Toolchain
system-wide update. Currently Fedora Rawhide has been testing glibc
2.38 since Feburary 20th 2023.
The gdb 13.2 update was rolled out across all Fedora releases and the
move to 13+ will be handled in the same fashion. The debugger is
capable of debugging the binary artifacts produced by the rest of the
system toolchain.
=== Enable DT_RELR ===
Enable DT_RELR (all architectures) to allow packing of relative
relocations in a binary. The current glibc binary rpms are already
built this way e.g. `GLIBC_ABI_DT_RELR`, and tooling must support it
already. Some bootloaders etc. may need adjustment due to missing
DT_RELR support in self-relocation.
In general the benefit to Fedora is faster startup times for applications.
This work adds code in redhat-rpm-config and documentation in buildflags.md.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2218018
=== Enable warnings ===
Early work for Fedora 40's
[https://fedoraproject.org/wiki/Changes/PortingToModernC Port to
Modern C] is complete ahead of schedule, and it would be good to avoid
regressing the progress that has been made by a limited enabling of
`-Werror=implicit-function-declaration` and `-Werror=implicit-int` by
default (to stop regressions).
This work has some dependent changes in redhat-rpm-config and some
build flag refactoring.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2218019
== Owner ==
* Name: [[User:codonell|Carlos O'Donell]]
* Email: carlos(a)redhat.com
== Detailed Description ==
The GNU Compiler Collection, GNU Binary Utilities, GNU C Library, and
the GNU Debugger make up the core part of the GNU Toolchain and it is
useful for our users to transition these components as a complete
implementation when making a new release of Fedora.
The GNU Compiler Collection is expected to release version 13.2,
before the Fedora 39 release. It contains many new features,
documented here: https://gcc.gnu.org/gcc-13/changes.html. The latest
point release for gcc 13 will be included in Fedora 39, this will most
probably be 13.2.
The GNU Binutils version 2.40 was released before Fedora 39; and we
have already been using this version of binutils in Fedora Rawhide
successfully to build the distribution. Given the present schedule for
Fedora 39 we will continue to use Binutils 2.40.
The GNU C Library version 2.38 is expected to be release before Fedora
39; we have started closely tracking the glibc 2.38 development code
in Fedora Rawhide and are addressing any issues as they arise. Given
the present schedule Fedora 39 will branch after the release of glibc
2.38. However, the mass rebuild schedule means Fedora 39 will mass
rebuild (if required) before the final release of glibc 2.38, but
after the ABI is frozen.
The GNU Debugger version 13.2 has already been rolled out across all
Fedora releases at the same time.
== Benefit to Fedora ==
Stays up to date with latest features, improvements, security and bug
fixes from gcc, glibc, binutils, and gdb upstream.
The goal is to track and transition to the latest components of the
GNU Toolchain.
== Scope ==
* Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, gdb,
...) developers need to ensure that gcc, glibc, binutils, and gdb in
rawhide are stable and ready for the Fedora 39 branch. <!-- What work
do the feature owners have to accomplish to complete the feature in
time for release? Is it a large change affecting many parts of the
distribution or is it a very isolated change? What are those
changes?-->
* Other developers: 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.
* Release engineering: A mass rebuild is strongly encouraged;
[https://pagure.io/releng/issue/11504 #11504]
* 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 ==
Any source level changes required for glibc 2.38 will be noted here:
https://sourceware.org/glibc/wiki/Release/2.38#Packaging_Changes
== How To Test ==
The GNU Compiler Collection has its own test suite which is run during
the package build and examined by the gcc developers before being
uploaded.
The GNU C Library has its own test suite 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 we may also run the
microbenchmark to look for performance regressions.
The GNU Binutils has its own test suite which is run during the
package build and examined by binutils developers before being
uploaded. The regression test suite is run to verify the correct
operation of the static linker and attendant utilities.
The GNU Debugger has its own test suite which is run during the
package build and examined by gdb developers before being uploaded.
The regression test suite is run to verify the correct operation of
the debugger.
== User Experience ==
<!-- TODO: Talk about any new GNU Toolchain user experience updates. -->
== 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 39 cycle. The mass rebuild would ensure all packages can be
built with the newer compiler and core runtime.
== Contingency Plan ==
* Contingency mechanism glibc: If glibc 2.38 proves too disruptive to
compiling the distribution we could revert to 2.37, but given that
Rawhide has started tracking glibc 2.38, no show-stopper problems are
expected. At this point we can still revert to upstream version 2.37
if insurmountable problems appear, but to do so may require a mass
rebuild to remove new symbols from the ABI/API.
* Contingency mechanism binutils: If binutils 2.40 proves too
distruptive to assembling and linking the distribution we could revert
to 2.39, but given that Rawhide is using 2.40, no show-stopper
problems are expected. At this point we can still revert if
insurmountable problems appear, but to do so may require a mass
rebuild if the defects involve generated binaries.
* Contingency mechanism for gcc: If gcc 13.2 proves too disruptive to
compiling the distribution we could revert to gcc 13.1.
* Contingency mechanism for gdb: If gdb 13.2 proves too disruptive to
debugging the distribution we could revert to gdb 13.1.
* Blocks release?
** No, upgrading to gcc 13.2 does not block the release.
** Yes, upgrading to binutils 2.40 does block the release.
** Yes, upgrading to glibc 2.38 does block the release.
** No, upgrading to gdb 13.2 does block the release.
== Documentation ==
The gcc manual contains the documentation for the release and doesn't
need any more additional work.
The binutils manual contains the documentation for the release and
doesn't need any more additional work.
The glibc manual contains the documentation for the release and
doesn't need any more additional work.
The gdb manual contains the documentation for the release and doesn't
need any more additional work.
== Release Notes ==
See https://gcc.gnu.org/gcc-13/changes.html for the GNU Compiler
Collection version 13 release notes.
The GNU C Library version 2.38 will be released at the beginning of
August 2023. The current NEWS notes can be seen here as they are
added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
The GNU Binary Utilities version X.Y was released February 2023. The
current release notes will be sent to the developer mailing list.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
https://fedoraproject.org/wiki/Changes/Color_Bash_Prompt
== Summary ==
Introduce a default colored prompt for Fedora's default shell bash.
== Owner ==
* Name: [[User:Petersen| Jens Petersen]]
* Email: <petersen(a)redhat.com>
== Detailed Description ==
For a long time the Fedora default shell prompt has been monochrome,
which makes it difficult to find shell prompt commands between long
command outputs when scrolling through terminal shell output.
This Change introduces a simple default colored shell prompt, which
users can also easily theme themselves.
[https://petersen.fedorapeople.org/color-bash-prompt.png screenshot of
color bash prompt in gnome-terminal]
== Feedback ==
Initial [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
devel list discussion thread]
There seems to be a general desire to have a colored prompt like other
popular distros, which commonly use green etc, though some concerns
were raised about colorblind users. However given that the original
prompt was black & white, and the new one while colored will still be
essentially monochromatic, it should be less of a problem and users
will easily be able to turn off or change any color introduced.
== Benefit to Fedora ==
Fedora will have a more modern and distinct default shell prompt.
== Scope ==
* Proposal owners:
** update the default bash PS1 to a simple essentially monochromatic
prompt (restricted to interactive color terminals).
** like the old default prompt, no external commands or processes will
be run by PS1 by default
* Other developers: bash and/or setup package maintainers to be
consulted on the preferred implementation file location
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No impact for rpm editions, ostree editions may gain the default color
prompt if they include its package.
== How To Test ==
* install Fedora and test the new PS1 prompt in various terminals and scenarios
** desktop default terminals should be expected to render the new prompt well
* try customizing the prompt theme by setting for example
`PROMPT_COLOR='1;33'` (bright/bold yellow), etc
A proof of concept can be tested today with
https://copr.fedorainfracloud.org/coprs/petersen/bash-color-prompt/
([https://copr-dist-git.fedorainfracloud.org/cgit/petersen/bash-color-prompt/…
source git repo])
== User Experience ==
Fedora users will now benefit from a clear self-colored shell prompt,
which should make the separation between command outputs and shell
prompts much clearer and they can also easily change the prompt
coloring in real-time as they desire.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Change owner will revert PS1 back to monochrome prompt
* Contingency deadline: Beta freeze
* Blocks release? Yes
== Documentation ==
[https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Renditio…
ANSI color attributes] (Wikipedia)
== Release Notes ==
The default shell prompt is now in a distinct color for increased
clarity and the theme can be customized.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford