F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
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 ==
Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
the default approach.
Packaging Guidelines and other documentation are adjusted to describe
this approach first.
Various tools that provide spec file templates are adjusted.
== Owner ==
* Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
* Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec|
The spec file contains:
<pre>
Version: 1.2.3
Release: %autorelease
...
%changelog
%autochangelog
</pre>
Rpmautospec uses git history. Whenever the package is built
(`.src.rpm` is generated), rpmautospec tooling will replace the
`%autorelease` macro with the number of commits since the last commit
that changed the `Version` field, and the `%autochangelog` macro with
a text generated from `git log`.
For details see the
[https://docs.pagure.org/fedora-infra.rpmautospec/principle.html
docs].
}}
Rpmautospec has been deployed in Fedora since F35
([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%).
But it is still a "second-class citizen": most documentation doesn't
mention it, and many packagers know that it exists but don't use it in
their packages. We think that it's reasonable to switch to
`%autorelease`+`%autochangelog` for almost all packages and that
Packaging Guidelines and various packaging howtos should recommend
that approach to packagers. The "traditional" approach of
manually-managed `Release` and `%changelog` will remain valid and will
be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to
all releases. The goal is to update the Packaging Guidelines and other
prominent documentation and tools now, and other docs and tools
possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses
`%autorelease`+`%autochangelog` since a few releases, so most rust
packages have switched. (Generally, rust spec files are recreated
using the generator for each new version, so the switch would happen
whenever a new version is packaged unless the packager opts out.)
== Feedback ==
* Thread on fedora-devel in August 2022:
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
rpmautospec by default]
** open issues: a bunch have been fixed.
** maintenance: Nils will add some co-maintainers.
** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see
Scope section.
== Benefit to Fedora ==
Various packaging workflows become smoother for packagers and contributors:
* packagers don't need to touch the `Release` field on updates
* packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
* patches to the spec file can be cherry-picked between branches
without trivial conflicts
* pull requests on src.fedoraproject.org can be merged without trivial conflicts
* in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over
== Scope ==
* Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to
make `%autorelease`+`%autochangelog` the default
** implement fixes for issues reported by packagers
** make semi-regular releases of rpmautospec
([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
0.3.1 was released on November 17th, and should be deployed to
production in about two weeks])
* Other developers:
** provide pull requests to other docs as appropriate
** accept the changes to documentation
** update other spec file generators (pip2rpm, others?)
* Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641
** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the
command will fail. A replacement workflow that instead restores
`%autorelease`+`%autochangelog` in the file committed to dist-git
needs to be implemented.
* Related work
** https://pagure.io/rpkg/c/3087dd7
** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: a list of places to be updated
** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning
** https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutori...
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Rpmautospec is already used by a decent number of packages, so any
issues are already being seen and need to be fixed anyway.
== How To Test ==
* Convert an existing package: `rpmautospec convert`. Ideally this
step is done right before a version bump so that the release numbers
restart at `-1`.
* Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify
correctness of version-release (`rpm -qpi`) and the changelog (`rpm
-qp --changelog`).
* Do builds in koji. Verify correctness of version-release and the changelog.
* For new packages, use `%autorelease`+`%autochangelog`. Repeat all
the tests listed above.
* Assume you are a newbie packager. Read the packaging docs and check
that the workflow is clear and the intructions are sufficient to use
rpmautospec tooling correctly.
== User Experience ==
No changes visible to end users.
== Dependencies ==
None.
== Contingency Plan ==
If it turns out that the rpmautospec workflows have unknown problems,
we can revert changes to documentation.
* Contingency mechanism: Revert changes to documentation by reverting
the appropriate commits. This can be done easily by FPC.
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
This page and any changes to Packaging Guidelines and other documents.
== Release Notes ==
Not needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
15 hours, 29 minutes
HEADS-UP: Upcoming retirement of long-term-unused packages for Rust crates
by Fabio Valentini
Hi all,
I've been collecting data about the dependency graph of Rust packages
in Fedora for over a year now, and I would like to start the process
of removing some accumulated cruft. In particular, I've been keeping
track of which packages for *library* packages (i.e. they ship only
source code but no binaries) have been leaf packages.
List of Rust library-only packages, which no other package in Fedora
has depended on, for over a year (365 days+):
- rust-compiletest_rs
- rust-constant_time_eq
- rust-conv
- rust-counted-array
- rust-dbus-tokio
- rust-defmac
- rust-dialoguer
- rust-enumset
- rust-failure-tools
- rust-fake-simd
- rust-fbthrift_codegen_includer_proc_macro
- rust-fdlimit
- rust-hamcrest2
- rust-html2pango
- rust-imgref
- rust-ioctl-rs
- rust-lipsum
- rust-listenfd
- rust-loggerv
- rust-lzw
- rust-macro-attr
- rust-mdl
- rust-mktemp
- rust-mnt
- rust-newtype_derive
- rust-odds
- rust-osstrtools
- rust-parse_cfg
- rust-permutate
- rust-piper
- rust-podio
- rust-proc-quote-impl
- rust-process_path
- rust-progress-streams
- rust-protoc-rust
- rust-quickersort
- rust-rand_jitter
- rust-rand_os
- rust-read_input
- rust-relay
- rust-rustc_tools_util
- rust-rustdoc-stripper
- rust-rustfilt
- rust-safe-transmute
- rust-scoped-tls-hkt
- rust-serde-pickle
- rust-serial-core
- rust-sluice
- rust-smallstr
- rust-spinning_top
- rust-spmc
- rust-ssh-key-dir
- rust-stb_truetype
- rust-string_cache_shared
- rust-strings
- rust-sudo_plugin
- rust-sxd-document
- rust-synom
- rust-sysctl
- rust-tabwriter
- rust-take
- rust-timerfd
- rust-tower-test
- rust-tower-util
- rust-ucd-util
- rust-unic-ucd-category
- rust-url_serde
- rust-urlocator
- rust-utf8-ranges
- rust-watchman_client
Some of these packages are dependencies of things that will be worked
on at some point in the future (for example, packaging of GStreamer
plugins that are written in Rust), but others look very much like
accumulated cruft.
If you see a package on this list that you would like to keep for some
reason, please speak up, and I will exclude it from future dependency
graph analysis. Otherwise I will soon start retiring packages that
have been unused for over a year.
The packages that would be in the list above, but which I *know* will
get some use soon, are:
- rust-curve25519-dalek
- rust-gstreamer-audio
- rust-gstreamer-editing-services
- rust-gstreamer-player
I will probably start the cleanup process with packages for crates
that no longer have any dependent crates listed on the crates.io
registry (which is a good indicator that they are indeed obsolete),
and then continue with crates for which the longest amount of time has
passed since the last upstream release (which is "more than 5 years
ago" for some crates ...).
Fabio
2 days, 13 hours
Testing of the New Staging Deployment of MDAPI
by Akashdeep Dhar
Hi folks,
I hope you are doing well. I write this to let you know that I have been
working on the MDAPI project under Pierre-Yves Chibon's guidance for some
time now for
1. Refactoring the code
2. Implementing code quality standards
3. Adding more comprehensive tests
4. Implementing a CLI wrapper
And other major changes
The codebase functionality remains the same in this rewrite for users, but
I have made attempts to ensure that it becomes relatively easier for the
community members to be able to contribute to the project with the addition
of documentation, enhancements in code readability and other miscellaneous
changes that help improve the contributor quality of life. Once the changes
were completed, I moved the repository from my personal GitHub namespace
(now archived)[1] over to Fedora Infra's GitHub namespace[2] and deployed
it on the Fedora's staging environment[3], with David Kirwan's assistance.
Please take it for a spin and test it out so that we can fix as many issues
as we can before we deploy it on the production environment.
Happy holidays! :)
Index
1. https://github.com/t0xic0der/mdapi
2. https://github.com/fedora-infra/mdapi
3. https://mdapi.stg.fedoraproject.org/
Regards,
Akashdeep Dhar (he/him),
Objective Representative, Fedora Council
Red Hat Community Platform Engineering
t0xic0der(a)fedoraproject.org
akashdeep(a)redhat.com
5 days, 17 hours
Re: Self Introduction: Hussein K.
by Sandro Mani
Welcome!
On 16.12.22 15:15, h-k-81(a)hotmail.com wrote:
> Hello everyone
>
>
> This mail should serve as my self introduction to the devel community.
>
> I am a (soon to be) computer science graduate, that has been working
> in the Linux / open source world for about 6 years. I first started
> working
> as a python developer in the GIS (geographic information system) domain.
> After some time I also began to perform some system administration tasks.
> And before I knew I started to do a bit of everything.
> So to describe my current work, I do
>
> - Python development
> - System administration
> - Kubernetes administration (or whatever you want to call it)
> - A little bit of javascript
> - Devops (Automatic deployments via CI / CD pipelines, mainly using
> Gitlab CI)
>
> Oh, I also picked up rust a couple years ago and have been using it
> for Uni and
> private projects.
>
> Now the reason for why I want to get more involved in the Fedora
> package maintainer community
> is because I want to get a better understanding on how applications
> are packaged and
> distributed to end-users in a secure and stable manner.
> And from my experience, the best way to learn, is to get your hands
> dirty.
> Naturally, I also want to give back to the community, that has doing
> amazing
> work at developing Fedora and keeping everything working, and I want
> to become a part of it.
>
>
> In the last week, I have been reading a lot of documentation on RPM
> packaging
> and I have created my first package. I am currently looking for a sponsor
> to help me with my first package review:
> https://bugzilla.redhat.com/show_bug.cgi?id=2154124
>
>
> This concludes my introduction and I hope this was not too much to
> read :D
>
>
> Best wishes
> Hussein K.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
6 days, 6 hours
F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
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 ==
X server implementations (e.g. Xorg and Xwayland) will (by default) no
longer allow clients with different endianess to connect.
== Owner ==
* Name: [[User:whot| Peter Hutterer]]
* Email: peter.hutterer(a)redhat.com
== Detailed Description ==
<!-- Expand on the summary, if appropriate. A couple sentences
suffices to explain the goal, but the more details you can provide the
better. -->
X server implementations (e.g. Xorg and Xwayland) allow clients with
an endianess different to that of the server to connect. Protocol
messages to and from these clients are byte-swapped by the X server.
However, the code in the X server that does this is virtually
untested, providing a large attack surface for malicious clients. One
needs to only look at e.g.
[https://www.x.org/wiki/Development/Security/Advisory-2014-12-09 this
X.Org security advisory] and count the `SProc` mentions for an
indication on how bad this is. A simple solution to remove this attack
surface is to prohibit clients with a different endianess. These
clients will simply fail, in a matter similar to failing to
authenticate against an X server.
The use-case for clients with different endianess is ''very'' niche.
It was common in the 1980s when X was originally developed but at this
point a vanishingly small number of users run clients and X servers on
different machines, let alone on different machines with different
endianess. I'd be surprised if Fedora had ''any'' users requiring this
feature.
Note:
* this only affects use-cases where the server runs on a little endian
host and the client on a Big Endian host (or vice versa).
* this is a change in '''the default behavior''' only and can be
changed via configuration options (for `Xorg`) and/or commandline
arguments (all X servers).
* this is a change in the upstream default behavior that Fedora will
follow along with. This Change is primarily to increase the exposure.
== Benefit to Fedora ==
This change removes a large potential attack surface that can be used
by malicious clients to expose memory locations, crash the X server
and/or do other entertaining things malicious programs like to do.
== Scope ==
* Proposal owners:
# Merge [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029
upstream PR]
# Backport patch to Fedora's `xorg-x11-server` and
`xorg-x11-server-Xwayland` packages
* Other developers: This is labelled as system-wide change simply
because it's a change in Xorg/Xwayland. It is otherwise self-contained
in that no other packages need updating, '''unless''' they want to
opt-out of this default. Which is better left to system-specific
configuration anyway.
* Release engineering: This feature does not require coordination with
release engineering
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
For the ''extremely niche'' use-case of users that run X clients on a
remote machine with a different endianess, these clients will no
longer be able to connect '''by default'''. For Xorg, the following
`xorg.conf.d` snippet will re-enable the old behavior:
<pre>
Section "ServerFlags"
Option "AllowSwappedClients" "on"
EndSection
</pre>
Wayland users (and thus Xwayland) need to employ compositor-specific
configuration to pass the `+byteswappedclients` flag to Xwayland. At
the time of writing, GNOME does not yet provide such a configuration.
== How To Test ==
To test the impact of this change, you need:
* an X server running on a little endian architecture and an X client
running on a Big Endian architecture (or the other way around)
* set up the X server to accept remote connections, either via TCP or
through SSH
* run the X client which will fail to connect
Alternatively, a test client is available in
[https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 the
upstream PR]. This test client pretends to be BigEndian and will fail
to connect when run against a little endian X server.
== User Experience ==
For virtually all users, there is no change in behavior.
Users with X server and client on two different machines must add the
`xorg.conf.d` snippet shown above on affected systems.
== Dependencies ==
No other RPMs depend on this change.
== Contingency Plan ==
This change depends on whether upstream merges this new default
behavior. If upstream does not merged the feature in time, this Change
will be postponed until the next Fedora version to avoid potential
incompatibilities between configurations or commandline options.
* Contingency mechanism: keep current behavior, try again with next
Fedora version
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
6 days, 16 hours
F38 proposal: FPC repackaging (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/F38-FPC-repackaging
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 ==
Split the `fpc` package (the Free Pascal Compiler) into several
sub-packages (built from the same spec file).
== Owner ==
* Name: [[User:suve|Artur Frenszek-Iwicki]]
* Email: <fedora(a)svgames.pl>
== Detailed Description ==
The `fpc` package will be split into three packages:
* `fpc` - the compiler itself, plus utility programs
* `fpc-ide` - the terminal-based TUI IDE (`/usr/bin/fp`)
* `fpc-units-ARCHNAME-linux` - pre-compiled units (think "FPC's
stdlib") for developing programs for Linux
The "units" subpackage will be a shared dependency for both `fpc` and `fpc-ide`.
== Benefit to Fedora ==
The TUI IDE will be moved to a separate package, slightly reducing the
download size for packages requiring FPC to build.
Putting Linux units in an `fpc-units-ARCHNAME-linux` package will
create a precedent which can be used in the future for introducing
cross-compilation packages, like `fpc-units-x86_64-win64` for MS
Windows.
== Scope ==
* Proposal owners:
** Edit `fpc.spec` as required and rebuild the package, preferably
before the Mass Rebuild.
* Other developers: No action required.
* Release engineering: No action required.
* 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 ==
After upgrading to Fedora 38, users interested in the TUI IDE will
need to manually install the `fpc-ide` package. For those not
interested in the TUI IDE, there will be no impact.
== How To Test ==
A copr repository has been created where users can test out the
modified package:
[https://copr.fedorainfracloud.org/coprs/suve/fpc-split/
copr/suve/fpc-split].
This copr repository also modifies the spec to build units for MS
Windows (`x86_64` only), allowing for cross-compilation.
== User Experience ==
For users not interested in the TUI IDE, this Change will slightly
reduce the install size (about 1.5 MiB for the IDE plus another 3.5
MiB for its dependencies).
Since the TUI IDE does not launch the compiler as a sub-process, but
rather contains an embedded copy of the compiler, users who use only
the IDE and not the standalone compiler will benefit in a similar way
- they will be able to install just the IDE, without the main compiler
package.
== Dependencies ==
None.
== Contingency Plan ==
Worst case scenario - give up, revert to an old version of `fpc.spec`
and rebuild the package.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
The `fpc` package no longer includes the terminal-based TUI IDE. Users
interested in the IDE should install the `fpc-ide` package.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 week, 6 days
Web Assembly on Fedora: interested in a Fedora SIG to work on this?
by Michael Dawson
As Web Assembly (WASM) gains momentum we’d like to create a SIG as a place to collaborate to ensure that Fedora is a great platform to both build and run WASM workloads. This includes looking at the toolchains needed to build WASM as a target and the runtimes needed to run WASM. It will provide a place to bring together efforts across different ecosystems (nodejs, rust, compiler toolchains, etc.) as well as a place where people can provide self-help when building and running WASM workloads.
If you are interested in a WASM Sig please let us know.
2 weeks
F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Shorter_Shutdown_Timer
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 ==
A downstream configuration change to reduce the systemd unit timeout
from 2 minutes to 15 seconds.
== Owner ==
* Name: catanzaro
* Email: mcatanzaro at redhat dot com
* Name: aday
* Email: aday at redhat dot com
== Detailed Description ==
Currently, a service that fails to stop at shutdown time can block
shutdown for up to 2 minutes. This is extremely frustrating for our
users - someone goes to shutdown or reboot their system, and then
unexpectedly has to wait for a long time before they can do anything
else.
The most common service to cause this issue is PackageKit, but there are others.
When a service fails to shutdown when it is instructed to do so, it is
not behaving properly, and it is preventing the system from behaving
in an orderly and predictable manner. Desktop APIs exist for cases
when services or apps legitimately need to prevent shutdown, and these
allow the shutdown inhibit to be communicated to admins and users, so
they understand what is happening. When the user decides to shut down
anyway, services must terminate in a timely manner. The Workstation
Working Group feels that 15 seconds is the maximum appropriate time
for both system and user services, and that Fedora should be robust to
buggy and misbehaving services that do not shut down in an appropriate
manner.
=== History ===
The Workstation Working Group has been
[https://pagure.io/fedora-workstation/issue/163 working on this issue
for several years]. Investigations have revealed that it's not
possible to fix every misbehaving service: in some cases the
misbehaviour comes from design flaws that are difficult to resolve.
An attempt has also been
[https://github.com/systemd/systemd/pull/18386 made to have the unit
timeout changed in upstream systemd]. That attempt did not go
anywhere, despite various efforts to move it along. We are no longer
comfortable waiting for upstream changes to land.
To our knowledge, there are no issues that will result from forcing
services to stop after 15 seconds on typical systems. However, system
administrators may need to configure a higher timeout if waiting
longer for a particular service, which may be true for database
services, for example.
== Feedback ==
The relevant [https://pagure.io/fedora-workstation/issue/163
Workstation Working Group ticket] includes some discussion. This
change [https://pagure.io/fesco/issue/2853 was also previously
proposed to FESCo].
== Benefit to Fedora ==
The primary benefit of the change will be to mitigate a very annoying
and - frankly - embarrassing bug. Our users shouldn't have to randomly
sit waiting for their machine to shutdown. It will also encourage the
correct use of shutdown inhibit APIs.
Although this change will "paper over" bugs in services without fixing
them, we emphasize that reducing the timeout is not merely a
workaround for buggy services, but also the desired permanent design.
Of course it is desirable to fix the underlying bugs as well, but it
doesn't make sense to require this before fixing the service timeout
to match our needs.
== Scope ==
* Proposal owners:
** Merge [https://src.fedoraproject.org/rpms/systemd/pull-request/85
the downstream change] to {{package|systemd}}.
* Other developers:
** Test their packages with the new behavior and report issues as necessary.
* Release engineering: [https://pagure.io/releng/issue/11193 #11193]
* Policies and guidelines: No policy or guideline changes required
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
System and user services will be killed with SIGKILL 15 seconds after
receiving SIGTERM, from previously 1 minute 30 seconds for most system
and user services, or 2 minutes for user manager system services (the
system service that runs all user services for a user), so services
will have less time to shut down gracefully by default. These defaults
are configurable and system administrators who require longer timeouts
would need to adjust them before or after upgrade. You may edit the
DefaultTimeoutStopSec= setting in /etc/systemd/user.conf and
/etc/systemd/system.conf. You may also create a drop-in to change the
TimeoutStopSec= setting for user@service.
== How To Test ==
Given the intermittent and unpredictable nature of the bug that is
being targeted, the best way to test is by using the upcoming Fedora
release. Are shutdown delays eliminated as intended? Do system
services experience issues as a result of the change?
== User Experience ==
This change will make the Fedora user experience less annoying. It
will also encourage the use of the existing inhibit APIs, which
provide better feedback for users when system shutdown does need to be
delayed.
== Dependencies ==
No specific changes are required in other packages. However, service
developers may want to take this opportunity to examine the shutdown
behavior of their components.
== Contingency Plan ==
* Contingency mechanism: the change owners will revert the change in systemd.
* Contingency deadline: if we back out the change it would be best to
do it before beta freeze, but this can happen at any point.
* Blocks release? No.
== Documentation ==
Documentation isn't required for this minor configuration change.
Services that legitimately need to prevent system shutdown should use
[https://www.freedesktop.org/wiki/Software/systemd/inhibit/ systemd
inhibit]. Desktop applications can use the
[https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.porta...
XDG inhibit portal].
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 weeks, 6 days
