Bugzilla (bugzilla.redhat.com) will be under maintenance for
infrastructure upgrades and will be unavailable on Saturday July 31
from 0030–0530 UTC. Status updates will be available at
https://status.redhat.com/incidents/7cn1j5k5qsgw
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi Fedora Friends,
As you may have noticed, Nest with Fedora 2021 is coming up quick. Our
annual contributor conference is next week August 5th-7th, virtual, and we
would love for you to attend!
Make sure to register here:
https://hopin.com/events/nest-with-fedora-2021
Check out the schedule here:
https://fedoraproject.org/wiki/Nest_with_Fedora_2021_Schedule#
Our schedule is packed full of sessions on all things Fedora. The sessions
range from technical, to how to get started on different teams, to a
variety of collaborative panels & more- the Fedora community showed up with
great topics! There is also a *fancy & fedorable* Fedora Museum themed
custom WorkAdventure map in the works that we will be using for our social
sessions.
Of course, there will be a Nest Attendee Fedora Badge to earn.
Additionally, there is a unique swag pack created specially for Nest with
Fedora 2021. The swag pack will include items with the new Fedora logo,
surprise items from our sponsors and a ton of stickers! You will receive
updates about claiming your Nest attendee swag pack via the email you use
to register in Hopin.
Cheers, and I can't wait to see you there!
--
Marie Nordin
Fedora Community Action and Impact Coordinator
Red Hat <https://www.redhat.com/> • Fedora Project <https://getfedora.org/>
She/Her/Hers
T: +1.973.800.4967
IRC: riecatnor
<https://red.ht/sig>
Note from the change owner: I'm submitting this as very-very-late
change for F35. The implementation in systemd is mostly done, so it'll
become available in rawhide pretty soon. To actually make use of the
new functionality, individual packages should be changed to use
_with_restart in their scriptlets and rebuilt. This will happen over
time, and it's fine if each package does that on its own schedule. We
still do not have that many user services, and restarting from
packaging scriptlets will be possible and appropriate only for some of
them. I think it's important to make the functionality available,
without trying to use it everywhere immediately.
https://fedoraproject.org/wiki/Changes/Restart_User_Service_after_Upgrade
== Summary ==
User services (services running under systemd user instances) will be
restarted as part of the rpm upgrade. This mirrors what is done for
system services.
== Owner ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek AT in.waw.pl
== Detailed Description ==
We have rpm packaging scriptlets to reexecute systemd and restart
system services as part of the rpm update transaction. But we didn't
have equivalent services for the user manager. With this change,
individual system managers will be reexecuted, and various packages
can mark their user services to be restarted. The restart of services,
similarly to the restart of system services, is done after all
packages have been installed, using a transfiletrigger.
== Benefit to Fedora ==
This fixes a long-standing missing feature. We certainly wanted to
have this, but the technical implementation is not trivial, because we
need to (safely and robustly) reach from the a privileged context into
unprivileged user manager instances. Such functionality has been added
in systemd, so finally we are able to do this in a fairly clean
manner.
User services are becoming more and more important. In particular, we
want to be able to restart services such as `pipewire.service` during
upgrades, without requiring a restart of the machine for the upgrade
to take effect. Systemd only provides the general functionality.
Package maintainers will need to mark their services for restart using
`%systemd_postun_with_restart` if appropriate.
== Scope ==
* Proposal owners:
** implement appropriate functionality
(https://github.com/systemd/systemd/pull/17967,
https://github.com/systemd/systemd/pull/20157,
https://github.com/systemd/systemd/pull/20276,
https://github.com/systemd/systemd/pull/20334)
** make a pull request to adjust the packaging guidelines
(https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scri…)
* Other developers:
** Switch from `%systemd_user_postun` to
`%systemd_user_postun_with_restart` if appropriate.
** Make sure that their user services behave properly during restart.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change, all the
relevant policies were already in place, but the implementation was
missing)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: no
== Upgrade/compatibility impact ==
This makes upgrades better in general. Various updates can take effect
immediately without requiring a restart. There should be no noticeable
effect on upgrades, barring bugs.
== How To Test ==
Upgrade packages with user services that should be restarted. Look at
logs or otherwise verify that the new version is running.
== User Experience ==
Updates of user services take effect immediately (if so configured in
the providing packages).
== Dependencies ==
None.
== Contingency Plan ==
Status quo is that various services are not restarted. Actually I
don't expect this to be fully implemented at any point in time. If
some service need to not be restarted, e.g. because the restart does
not work, change `%systemd_user_postun_with_restart` to
`%systemd_user_postun` and rebuild the package. If the whole system is
broken, the command that actually does the restart in the systemd
transfiletrigger can be disabled.
* Contingency deadline: any time
* Blocks release? No.
== Documentation ==
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_scri…
(TBD)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 35 approximately one week before branching (i.e. in
1 week).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails…
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf…
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know ASAP and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
==============================================================================
cardpeek kalev Fedora 32
percona-xtrabackup slaanesh, slankes Fedora 32
sugar-view-slides callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
The following packages require above mentioned packages:
Depending on: percona-xtrabackup (1)
holland (maintained by: immanetize, jeffreyness, survient)
holland-xtrabackup.noarch requires /usr/bin/xtrabackup
Affected (co)maintainers
callkalpa: sugar-view-slides
chimosky: sugar-view-slides
immanetize: percona-xtrabackup
jeffreyness: percona-xtrabackup
kalev: cardpeek
pbrobinson: sugar-view-slides
slaanesh: percona-xtrabackup
slankes: percona-xtrabackup
survient: percona-xtrabackup
tuxbrewr: sugar-view-slides
https://fedoraproject.org/wiki/Changes/Power_Profiles_Daemon
== Summary ==
We will install power-profiles-daemon in Fedora Workstation and enable
it by default. power-profiles-daemon allows the user to choose between
optimizing for system performance or battery life.
== Owner ==
* Name: [[User:Hadess| Bastien Nocera]]
* Email: bnocera(a)redhat.com
* Name: [[User:Catanzaro|Michael Catanzaro]]
* Email: mcatanzaro(a)redhat.com
* Name: [[User:Ngompa|Neal Gompa]]
* Email: ngompa13(a)gmail.com
== Detailed Description ==
From the upstream README:
power-profiles-daemon offers to modify system behaviour based upon
user-selected power profiles. There are 3 different power profiles, a
"balanced" default mode, a "power-saver" mode, as well as a
"performance" mode. The first 2 of those are available on every
system. The "performance" mode is only available on select systems and
is implemented by different "drivers" based on the system or systems
it targets.
In addition to those 2 or 3 modes (depending on the system), "actions"
can be hooked up to change the behaviour of a particular device. For
example, this can be used to disable the fast-charging for some USB
devices when in power-saver mode.
GNOME's Settings and shell both include interfaces to select the
current mode, but they are also expected to adjust the behaviour of
the desktop depending on the mode, such as turning the screen off
after inaction more aggressively when in power-saver mode.
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
Shipping power-profiles-daemon enables GNOME to display and offer
users the ability to adjust configuration related to power management
similar to other operating systems, which can improve the quality of
the on-battery experience (with respect to longevity of operating on
battery power).
== Scope ==
* Proposal owners: Add Recommends: power-profiles-daemon to
gnome-control-center package. Add systemd preset to fedora-release.
* Other developers: N/A (not needed for this Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Nope.
== Upgrade/compatibility impact ==
power-profiles-daemon will be installed on upgrade to Fedora 35 if
gnome-control-center is installed. Since the default power profile is
the balanced mode, users should not notice performance changes (sans
bugs), but the option to manually select either performance or power
saving mode will now be present.
== How To Test ==
Visit the Power settings panel in gnome-control-center and switch
between performance, balanced, and power save mode. Look for
unexpected behavior changes over long periods of time. For example,
selecting Performance mode should improve system performance but
reduce battery life. Selecting power save mode should reduce
performance but increase battery life. Selecting balanced mode should
not change anything.
The selected power save mode should persist across system reboots.
== User Experience ==
GNOME Control Center will show a new section in the Power page giving
users the option to select power modes:
* Balanced (the default)
* Performance (to maximize performance)
* Power saver (to maximize battery life)
User selection of these profiles will set various tunables to meet the
needs as described in the profiles.
== Dependencies ==
gnome-control-center depends on power-profiles-daemon to offer power
saving options. If not installed, these options will not be present in
the power panel.
== Contingency Plan ==
* Contingency mechanism: we can easily remove the Recommends: in
gnome-control-center or the preset in fedora-release if necessary.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
The only documentation is the upstream project README:
https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/blob/main/REA…
== Release Notes ==
Fedora Workstation now ships with power-profiles-daemon installed and enabled.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 35 approximately one week before branching (August
2021).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails…
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf…
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
==============================================================================
cardpeek kalev Fedora 32
percona-xtrabackup slaanesh, slankes Fedora 32
sugar-view-slides callkalpa, chimosky, pbrobinson, tuxbrewr Fedora 31
The following packages require above mentioned packages:
Depending on: percona-xtrabackup (1)
holland (maintained by: immanetize, jeffreyness, survient)
holland-xtrabackup.noarch requires /usr/bin/xtrabackup
Affected (co)maintainers
callkalpa: sugar-view-slides
chimosky: sugar-view-slides
immanetize: percona-xtrabackup
jeffreyness: percona-xtrabackup
kalev: cardpeek
pbrobinson: sugar-view-slides
slaanesh: percona-xtrabackup
slankes: percona-xtrabackup
survient: percona-xtrabackup
tuxbrewr: sugar-view-slides
https://fedoraproject.org/wiki/Changes/WirePlumber
== Summary ==
PipeWire currently uses a simple example session manager. This
proposal is to move to the more powerful WirePlumber session manager.
== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taymans(a)gmail.com
== Detailed Description ==
PipeWire requires a session manager that at least needs to implements
the following features:
* create and configure detected devices in the system. This includes
audio cards, video and bluetooth devices.
* configure applications and route audio/video to/from them to the
devices and filters.
* keep track of prefered devices and volumes.
* move audio/video streams when devices appear and disappear.
PipeWire uses a simple example session manager with limited features
and configuration options. The proposal is to
move to WirePlumber.
WirePlumber is built on GNOME (GObject) technologies and has bindings
for most languages using GObject introspection.
WirePlumber allows one to implement many of the rules for setup and
configuration using small LUA scripts, which are
easier to maintain and customize. These are some of the functions that
are scriptable in LUA:
* setup and configuration of the devices and streams. This includes
deciding if devices and streams need to operate in 5.1 or stereo mode,
depending on the available devices.
* routing of the streams based on metadata of the streams (Roles) and
overall state of the system.
* volume/mute restore of devices and streams
== Benefit to Fedora ==
PipeWire currently uses a simple example session manager with mostly
hardcoded logic and rules. This proposal wants to replace the session
manager with a more advanced session manager, called WirePlumber.
WirePlumber brings to following improvements
* Drop-in replacement session manager for PipeWire, implements the
exact same features as the example session manager
* built with GObject, which provides a richer development experience
and adds bindings for most languages
* extensible with loadable modules
* scriptable policy using small lua scripts
* better integration with desktop settings
The main benefits will be that this session manager would allow for
more customization of the policy
and rules. Initially we aim for feature parity with the current
solution and work on more features
in the next releases.
== Scope ==
* Proposal owners:
This is a rather isolated changed. Instead of starting the
pipewire-media-session executable we would need to package
and start WirePlumber instead.
WirePlumber has been kept up to data with the features in the example
session manager and would need testing.
* Other developers: None. This is an isolated PipeWire change.
* Release engineering: A new systemd service will need to be activated
in the default install.
* 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 ==
Should not cause any change.
== How To Test ==
Experience should be the same as before. Retest all audio testcases.
== User Experience ==
Should not cause any visible change.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?): If the
feature can not be completed we continue using the existing
pipewire-media-session.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
[WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis