This is your reminder that several Change proposal deadlines for
Fedora 33 are approaching.
* 2020-06-24: Proposal deadline for Changes requiring infrastructure changes
* 2020-06-30: Proposal deadline for Changes requiring mass rebuild
* 2020-06-30: Proposal deadline for System-Wide Changes
* 2020-07-21: Proposal deadline for Self-Contained Changes
For the full schedule, see
https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Good Morning Everyone,
If you are a packagers or are watching tickets on dist-git (ie: asked to be
cc'ed on tickets on bugzilla for a given package), you must have a valid
bugzilla account associated with the email address you have set in FAS.
There are currently 66 users and groups who do not satisfy this requirement.
This has a direct impact as the script syncing from dist-git to bugzilla the
information about the default assignee and the CC list updates components in
bugzilla in a single request to reduce the load on the server.
So if someone in the CC list does not have a valid bugzilla account, the
entire request will fail to update both the CC list and the default assignee.
Accounts in this state may at some point be removed from packages/cc, so it's
important to correct your account soon!
So, if your name is listed here, please take a minute and create a bugzilla
for the email you have associated with your FAS account:
aarondmarasco
adsllc
affix
ajeetdsouza
alen
amitshah
andreyma
avesh
bpereto
@certbot-sig
csomh
darkdragon001
dcantrel
digimer
dmsimard
doug1
edwintorok
etingof
fepitre
gnikandrov
@graphics-sig
ignotusp
itsbill
jefferson2z
jkratoch
jkreuzer
karsten
kir
klausdevwalker
labbott
lamm
luismartingil
marcdeop
mathstuf
mbartos
mhabrnal
mildew
mmahut
moisesguimaraes
mzidek
nguzman
njohnston
omejzlik
pgibson
portante
proski
rbtr
robled
romal
rpitonak
rspanton
sakalosj
squallbayu
sspreitz
sturivnyi
svahl
tnorth
trasher
tstclair
usercont
vbatts
vicodan
vpolasek
@weldr-sig
yuwata
zmc
If you really to have two distinct email addresses, we keep a mapping of FAS
emails to bugzilla account in [1], which you can update via a pull-request if
you wish to use this.
Thanks for your help,
Pierre
[1]
https://pagure.io/fedora-infra/ansible/blob/master/f/roles/openshift-apps/d…
https://fedoraproject.org/wiki/Changes/IBus_1.5.23
== Summary ==
IBus 1.5.23 will replace the allowlist of XKB engines with the
blocklist of XKB ones.
== Owner ==
* Name: [[User:Fujiwara| Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com
== Detailed Description ==
IBus currently provides the allowlist of XKB engines in
`/usr/share/ibus/component/simple.xml` and `ibus-setup` utility can
show the XKB engines indicated in only that file in most desktops.
(gnome-control-center shows XKB list from gnome-desktop3 in GNOME
desktop instead.) The allowlist includes the limited XKB layouts and
variants. E.g. 'gb(dvorak)' is included but 'gb' is not. And the
allowlist has been supported to customize by sysadmin localy since the
simple.xml is a simple text file and the default list has been updated
upon the request.
IBus 1.5.23 will replace the allowlist with the blocklist which
includes the disabled XKB engines and `ibus-setup` will shows all the
XKB engines which are '''not''' indicated in that file. The blocklist
will includes 'cn' layout, 'cn' layout + any variants, 'nec_vndr/jp'
layouts at the moment.
I.e. the change won't effect GNOME desktop.
== Benefit to Fedora ==
The users don't have to request the desired XKB layouts and variants
in IBus upstream and most XKB keymaps will be shown in ibus-setup.
== Scope ==
* Proposal owners:
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/9563 #9563]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
If a keymap is shown in ibus-setup in the previous version, it will be
shown in the new one.
== How To Test ==
# Log into XFCE desktop
# Run ibus-setup
It will show 'English (UK)' keymap by default.
== User Experience ==
If a user customize `/usr/share/ibus/component/simple.xml` in the
previous version, the file will be replaced with new one.
== Dependencies ==
The change effects XKB engines only but does not input method engines
(E.g. libpinyin, hangul, and so on.)
== Contingency Plan ==
* Contingency mechanism: Drop the feature in Fedora 33 and postpone it
to Fedora 34
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
TBD
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macro…
== Summary ==
redhat-rpm-config will be updated to add patching support to forge
macros, a plug-able framework to register macros to execute in
specific sections, and rpm changelogs in detached files.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email: <nicolas.mailhot at laposte.net>
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (users of forge, fonts and go macros).
It was driven first, by the need to make the underlying macro
infrastructure robust enough to package Go modules, and second, by an
unfortunate rpm 4.15 regression that proved it was foolish to depend
on rpmbuild to parse Tags in anything except canonical order.
=== Forge ===
* forge macro now process patches, including in multi-source spec
files, in a natural way
* all dependencies on source/patch numbering were eradicated, you can
write a whole multi-source/multi-patch spec without worrying about
source or patch numbers
* zero suffix is no longer special (à la Source/Source0 way), you can
declare forge blocks starting at 42 if that‘s your preference
=== Fully automated packaging ===
A framework was added so macro subsystems can register execution
blocks in specific parts or the spec file. Execution blocks are
orchestrated (using KISS rules) so for example the forge part of %prep
is executed before the go parts that depend on forge archives being
unpacked and patched, and macros that want to create srpm headers are
executed before macros that want to create subpackage headers.
Such a framework is a requirement to control the generation order
within the spec file and make sure rpm maintainers are not cross with
you.
That means a spec with no special custom processing is reduced to a
set of %global control variables that activate specific execution
blocks, and everything bellow those control variable is short and
unchanging boilerplate.
A packager that needs custom processing can add custom code above or
bellow the various `%auto_foo` calls, and check with `rpmspec -P` that
the result does what he wants it to do. For obvious reliability
reasons injecting custom code in the middle of an `%auto_foo` sequence
is not allowed.
<pre>
%global source_name …
%global source_release …
%global source_post_release …
%global forge_url0 …
%global forge_commit0 …
%global forge_url1 …
%global forge_tag1 …
%global go_module33 …
%global go_description33 …
%global font_family22 …
%global font_conf22 …
%auto_init
%auto_pkg
%sourcelist
%auto_sources
%patchlist
%auto_patches
%prep
%auto_prep
%generate_buildrequires
%auto_generate_buildrequires
%build
%auto_build
%install
%auto_install
%check
%auto_check
%auto_files
%changelog
%auto_changelog
</pre>
=== Detached changelogs ===
This framework was used to implement detached rpm changelogs in a reliable way.
=== Generic -doc creation ===
This framework was used to implement automated -doc subpackage
creation, because creating them by hand gets annoying after the nth
upstream that wants you do distribute heavy PDF documentation files.
=== Huge refactoring and fleshing out of the lua library ===
Writing high-level features like the above required defining a library
of lua routines like an expand that expands fully, an unset that
actually undefines, a read that tells you if a variable exists or is
set to "", a `fedora.echo()` wrapper around
`rpm.expand("%{echo:%{expand:" .. text .. "}}")`, etc. Those are now
available for others to use should they want to.
My coding skills are not up to navigating the upstream low level rpm
lua API without blowing up on the landmines it is littered with.
Therefore, I abstracted landmine avoidance in a single place.
=== Drawbacks ===
Nothing is free, and a higher level of automation required using rigid
naming for control variables. Because software is a lot less tolerant
of fuzzy naming than human beings.
So, all forge control variables are renamed, fonts control variables
have been renamed too, and go control variables will need renaming (in
that last case, that’s not a problem because moving to go modules
requires reworking variables anyway, so it will be done as part of the
module effort in F34).
To ease the transition a compatibility layer was added to forge macros
so old variables and new variables are aliased both ways (this will
eventually go away because it’s quite a lot of compatibility code to
maintain). Mixing syntaxes (old and new) is not supported, you need to
convert your spec file to new forge variables or not at all (if not at
all, do not try to use new features like patching).
== Benefit to Fedora ==
Spec files that do more with less manual expensive to maintain spec code.
Without this productivity win, complex efforts like converting Fedora
Go packages to Go modules, or draining the Font packages swamp given
that legacy formats are no longer supported by apps, are not possible
with the current level of Fedora manpower.
== Scope ==
* Proposal owners:
The core of the feature is done and tested (and retested). It may
evolve during the redhat-rpm-config merge process.
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/95
* Other developers:
The way current forge macros call forge macros will need a little
patching once the change lands. For other packagers, there should be
no change except a warning in rpm build logs to switch to the new
syntax before the compatibility layer is removed.
* Release engineering: https://pagure.io/releng/issue/9565
* FPC: https://pagure.io/packaging-committee/issue/997
* Policies and guidelines:
Forge guidelines will need some rework (mostly simplification,
because the new syntax is both more powerful and more regular).
For the average packager, the new syntax is the same old syntax with
little naming adjustments (for example, %{forgeurl} becomes
%{forge_url}, %forgemeta is subsumed into %auto_init, etc)
* Trademark approval: N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it
is a new Spin), file a ticket ( https://fedorahosted.org/council/ )
requesting trademark approval from the Fedora Council. This approval
will be done via the Council's consensus-based process. -->
== Upgrade/compatibility impact ==
This is a pure build tooling update, it changes how things are built
not what is built.
== How To Test ==
A redhat-rpm-config packages with the changes and some example
packages are available in
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-…
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change depends on a redhat-rpm-config merge by redhat-rpm-config maintainers
== Contingency Plan ==
There is no contingency plan because the redhat-rpm-config merge will
happen or not. If it does not happen, i18n, fonts and Go Changes that
are/were envisioned for F33 or F34 will be postponed indefinitely.
== Documentation ==
There is as much documentation as the average redhat-rpm-config change
(ie comments in the macro files themselves)
== Release Notes ==
N/A Packager productivity change only
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog…
== Summary ==
redhat-rpm-config will be updated so users of the auto framework get
automated release and changelog bumping.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email: <nicolas.mailhot at laposte.net>
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (auto framework).
The change will make those packages auto-bump and auto-changelog at
the rpm level, in an infrastructure-independent way.
== Benefit to Fedora ==
Autobumping removes a huge packager shore and makes timestamping in
changelogs more reliable.
== Scope ==
* Proposal owners: The feature is coded and works at the rpm level.
Unfortunately, mock filters away the srpms containing the bump state,
so it does not work in upper layers.
* Other developers: The feature requires buy-in by mock developers
(and probably koji developers) to lift the restrictions that block it
above the rpm level. Also, it requires a mechanism to pass the user
name and email that will be used in bumped changelogs (defining two
variables in ~/.rpmmacros is sufficient at rpm level)
* Mock issue: https://github.com/rpm-software-management/mock/issues/599
* Release engineering: https://pagure.io/releng/issue/9567
* Policies and guidelines: maybe eventually if things work out on the
technical level
* FPC issue: https://pagure.io/packaging-committee/issue/998
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This is a pure build tooling update, it changes how things are built
not what is built.
== How To Test ==
A redhat-rpm-config packages with the changes and some example
packages are available in
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-…
Since the mock/copr layer is currently blocking the feature, you need
to install the redhat-rpm-config and forge macro packages available in
this repo locally. Afterwards you can take any of the example packages
in the repo and rebuild them with rpmbuild -ba to your heart content,
and see the releases bump and the changelogs being updated
accordingly.
To get beautiful changelogs, you also need to add
<pre>
%buildsys_name Your name
%buildsys_email Your email
</pre>
in ~/.rpmmacros
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change is a spin-off of
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macro…
Therefore, it depends on the success of that other change and will
probably need rebasing if the code in this other change evolves during
the redhat-rpm-config merge.
It also depends on mock / copr/ koji buy-in and changes, that may add
their own requirements.
== Contingency Plan ==
There is no contingency plan because the change will happen or not at all.
== Documentation ==
There is as much documentation as the average redhat-rpm-config change
(ie comments in the macro files themselves)
== Release Notes ==
N/A Packager productivity change only
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/SID
== Summary ==
Introduce Storage Instantiation Daemon (SID) that aims to provide a
central event-driven engine to write modules for identifying specific
Linux storage devices, their dependencies, collecting information and
state tracking while
being aware of device groups forming layers and layers forming whole
stacks or simply creating custom groups of enumerated devices. SID
will provide mechanisms to retrieve and query collected information
and a possibility to bind predefined or custom triggers with actions
for each group.
== Owner ==
* Name: [[User:prajnoha | Peter Rajnoha]]
* Email: prajnoha(a)redhat.com
== Detailed Description ==
Over the years, various storage subsystems have been installing hooks
within udev rules and calling out numerous external commands for them
to be able to react on events like device presence, removal or a
change in general. However, this approach ended up with very complex
rules that are hard to maintain and debug if we are considering
storage setups where we build layers consisting of several underlying
devices (horizontal scope) and where we can stack one layer on top of
another (vertical scope), building up diverse storage stacks where we
also need to track progression of states either at device level or
group level.
SID extends udevd functionality here in a way that it incorporates a
notion of device grouping directly in its core which helps with
tracking devices in storage subsystems like LVM, multipath, MD...
Also, it provides its own database where records are separated into
per-device, per-module, global or udev namespace. The udev namespace
keeps per-device records that are imported and/or exported to/from
udev environment and this is used as compatible communication channel
with udevd. The records can be marked with restriction flags that aid
record separation and it prevents other modules to read, write or
create a record with the same key, hence making sure that only a
single module can create the records with certain keys (reserving a
key).
Currently, SID project provides a companion command called 'usid'
which is used for communication between udev and SID itself. After
calling the usid command in a udev rule, device processing is
transferred to SID and SID strictly separates the processing into
discrete phases (device identificaton, pre-scan, device scan,
post-scan). Within these phases, it is possible to decide whether the
next phase is executed and it is possible to schedule delayed actions
or set records in the database that can fire triggers with associated
actions or records which are then exported to udev environment (mainly
for backwards compatibility and for other udev rules to have a chance
to react). The scheduled actions and triggers are executed out of udev
context and hence not delaying the udev processing itself and
improving issues with udev timeouts where unnecessary work is done.
A module writer can hook into the processing phases and use SID's API
to access the database as well as set the triggers with actions or
schedule separate actions and mark devices as ready or not for use in
next layers. The database can be used within any phase to retrieve and
store key-value records (where value could be any binary value in
general) and the records can be marked as transient (only available
during processing phases for current event) or persistent so they can
be accessed while processing subsequent events.
== Benefit to Fedora ==
The main benefit is all about centralizing the solution to solve
issues that storage subsystem maintainers have been hitting with udev,
that is:
* providing a central infrastructure for storage event processing,
currently targeted at udev events
* improving the way storage events and their sequences are recognized
and for which complex udev rules were applied before
* single notion of device readiness shared among various storage
subsystems (single API to set the state instead of setting various
variables by different subsystems)
* providing more enhanced possibilities to store and retrieve
storage-device-related records when compared to udev database
* direct support for generic device grouping (matching
subsystem-related groups like LVM, multipath, MD... or creating
arbitrary groups of devices)
* centralized solution for scheduling triggers with associated actions
defined on groups of storage devices
* adding a centralized solution for delayed actions on storage devices
and groups of devices (avoiding unnecessary work done within udev
context and hence avoiding frequent udev timeouts when processing
events for such devices)
== Scope ==
* Proposal owners:
** complete SID's infrastructure to fully support stabilized API for
other developers to start writing modules for SID;
** document all of current SID's functionality, including the module
API and explain the difference (extension) to udev, write and complete
man pages;
** provide udev rules responsible for communication with SID and
possibly importing records which were marked for export to udev in
SID.
* Other developers:
** first version will make use of a module to handle
device-mapper-multipath devices (device-mapper-multipath package)
** consult in more detail possibility of adding an LVM module even for
this release (if not feasible at this moment, then postpone
development of this module to next release)
* Release engineering: [https://pagure.io/releng/issue/9568 #9568]
* Policies and guidelines: no changes needed at this moment
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
We are introducing SID in this release and it will be disabled by
default so an upgrade has no impact here - all existing udev rules for
various storage subsystems will still be installed as previously.
Subsystems for which a module will be already available in this
release will contain a switch in their udev rules to either use the
old udev rules (if SID is not active) or skip the rules appropriately
(if SID is active and related processing is handled within the SID
module instead).
== How To Test ==
* Basic testing involves (considering we have at least multipath
and/or LVM module present as well):
** installing new 'sid' package
** installing device-mapper-multipath and/or lvm module (presumably
named device-mapper-multipath-sid-module and lvm2-sid-module)
** creating a device stack including device-mapper-multipath and/or LVM volumes
** booting with 'sid.enabled=1' kernel command line
** checking device-mapper-multipath and/or LVM volumes are correctly activated
* More thorough testing:
** (TBD)
== User Experience ==
Regular users shouldn't notice any change. SID is providing a
system-level infrastructure for convenient handling of
storage-device-related events through modules provided by other
developers.
== Dependencies ==
* a module to handle device-mapper-multipath is in cooperative
development with this change, the module will land in
device-mapper-multipath package (or its subpackage)
* the same applies for the LVM module (but that may be postponed as
described earlier)
== Contingency Plan ==
If SID is not complete in time, there's no need to execute any special
backup plans. The distribution still contains all the original udev
rules to handle events for storage devices. If device-mapper-multipath
and/or LVM provides the SID modules, these won't be built and
distributed.
SID is not enabled by default so to start using it, one needs to
enable it explicitly. If enabling SID causes problems, it can be
disabled. For this purpose, there will be a kernel command line to
enable/disable SID so we avoid possible issues even at early boot
sequence if the device handled by SID is on critical path within boot
sequence.
== Documentation ==
* documentation (will be completed): https://sid-project.github.io/*
upstream repository: https://github.com/sid-project/sid-mvp
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/ThermalManagementWS
== Summary ==
Better thermal management and peak performance on Intel CPUs by including
thermald in the default install.
== Owner ==
* Name: [[User:benzea| Benjamin Berg]]
* Email: bberg(a)redhat.com
* Name: [[User:ckellner| Christian J. Kellner]]
* Email: ckellner(a)redhat.com
* Product: Workstation
* Responsible WG: Workstation
== Detailed Description ==
Modern Intel-based systems provide sensors and methods to monitor and
control temperature of its CPUs. The Thermal daemon will use those sensors
to monitor the temperature and use the best available method to keep the
CPU in the right temperature envelop. On certain systems this is needed to
reach the maximal performance. thermald will for example use the PPCC power
table to set power limits (when available, see for example
https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg411614.…)
This is for example the case on Ice Lake, where thermald can increase the
performance of the out-of-the-box behaviour of Fedora.
Not strictly necessary, but *further* improvements can be achieved by using
per-model thermald configurations. The most straight forward way of using
those is for the user to install dptfxtract (available from rpmfusion). At
least parts of what dptfxtract can already do may be integrated into
thermald in the future thanks to the reverse engineering work done by
Matthew Garret (see
https://github.com/intel/thermal_daemon/tree/mg_patches_test,
https://github.com/intel/thermal_daemon/pull/224) Should the reverse
engineering effort be merged, or if the user installs dptfxtract, then they
can expect a performance boost on some machines.
Theoretically one could ship appropriate per-machine configurations as a
separate package (or inside thermald). However, this is not part of the
proposal for a number of reasons:
1. It is not clear how the configuration data can be collected
2. We do not currently have an implementation to load such configuration
data
3. This may become obsolete with if the reverse-engineering effort
continues and is merged (or picked up by Fedora)
For a more details explanation please consult Intel's [
https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daem…
introduction] to thermald.
== Benefit to Fedora ==
Better out-of-the-box experience due to improved cooling methods and
performance on Intel systems. This affects many modern laptops (e.g. the
Ice Lake platform). On affected machines, Fedora would continue to have
poorer performance compared to other distributions.
== Scope ==
* Proposal owners:
- Include the thermald package in the default Workstation install
* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Install the packages and use e.g. turbostat to monitor the performance.
Improvements may only be visible if the non-free dptfxtract package is also
installed.
== User Experience ==
- Better performance on certain hardware
- Better cooling of CPUs on certain hardware
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Don't ship package by default
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries
== Summary ==
OpenLDAP will not ship non-threaded version of libldap. Instead, symlinks
will be provided for runtime libraries to keep working, and all software
built with libldap will be effectively built with libldap_r.
== Owner ==
* Name: [[User:mhonek|Matus Honek]]
* Email: mhonek(a)redhat.com
== Detailed Description ==
For historical reasons OpenLDAP is currently shipped with two libraries
which provide the very same functionality, differing only in support for
multi-threading. If these are both loaded in the same runtime this may lead
to unpredictable behaviour due to identical symbol naming. Upstream ceased
from supporting the non-threaded variant in the next major release, however
in the current stable version it is still supported as it might be used on
processors where threads are not supported.
After this change the non-threaded version of the library (`libldap`) will
not be shipped any more. Instead, this library will rather be linked to its
threaded counterpart (`libldap_r`). The runtime symlinks will be moved to a
separate `openldap-compat` subpackage so that any package linked with
`libldap` (i.e. not `libldap_r`) will be clearly indentifiable by this
"new" dependency. The `openldap-devel` package will provide `libldap.so` as
a symlink to `libldap_r.so` so that all rebuilt packages are linked to the
same library. Initial mass rebuild is anticipated to discover potential
build issues as well as to eliminate the actual issues caused by both
libraries being loaded at the same time.
== Benefit to Fedora ==
No potential unexpected issues caused by symbol overlap.
== Scope ==
* Proposal owners: update SPEC file as described in the Detailed
Description.
* Other developers: None. Issues should not occur.
* Release engineering: [https://pagure.io/releng/issue/7253]
* Policies and guidelines: None
* Trademark approval: (not needed for this Change)
== Upgrade/compatibility impact ==
No issues should occur.
== How To Test ==
libldap and libldap_r should export the same symbols. Any applications
linking to OpenLDAP libraries may test that their LDAP related
functionality works.
== User Experience ==
User should not notice anything.
== Dependencies ==
None.
== Contingency Plan ==
* Contingency mechanism: Revert the change in OpenLDAP's SPEC file and
rebuild it. Any packages succesfully rebuilt after the SPEC change are
expected to be working properly, and if not they shall be rebuilt after the
SPEC revert.
* Contingency deadline: beta freeze.
* Blocks release? No.
== Documentation ==
Please, follow [[https://bugzilla.redhat.com/show_bug.cgi?id=1370065 this
bug]] for more insights.
== Release Notes ==
OpenLDAP does not ship non-threaded version of libldap any more, and it is
seamlessly replaced by the threaded libldap_r. No additional action from
development should be required.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/PythonMacroError
== Summary ==
The <code>%{__python}</code> RPM macro (currently defined to
<code>/usr/bin/python</code> for backwards compatibility reasons) will be
defined to raise an error when used. Any derived macros
(<code>%{python}</code>, <code>%{python_version}</code>,
<code>%{python_sitleib}</code> etc.) will propagate the error. Packagers
can redefine the macro to any actual value to suppress the error. This is
consistent with RHEL 8 behavior. Using <code>/usr/bin/python</code> in
Fedora packages remains forbidden.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: <mhroncok(a)redhat.com>
== Detailed Description ==
For years, the unversioned <code>/usr/bin/python</code> Python interpreter
MUST not be used when building RPM packages in Fedora. However, for
backwards compatibility reasons, the <code>%{__python}</code> macro was
defined to <code>/usr/bin/python</code>. As a direct consequence, all
derived macros:
* <code>%{python}</code>
* <code>%{python_version}</code>
* <code>%{python_version_nodots}</code>
* <code>%{python_sitelib}</code>
* <code>%{python_sitearch}</code>
* <code>%py_shebang_fix</code>
* <code>%py_build</code> variants
* <code>%py_install</code> variants
used <code>/usr/bin/python</code> as well, unless redefined to custom value
different than <code>/usr/bin/python</code>. Some of the macros
unfortunately evaluated to empty string when <code>/usr/bin/python</code>
was not installed in the buildroot.
We wanted to define <code>%{__python}</code> to an error previously, but
unfortunately, this was not yet possible due to backwards compatibility wrt
automagic byte-compilation. Hence we have done:
* [[Changes/No_more_automagic_Python_bytecompilation]]
* [[Changes/No_more_automagic_Python_bytecompilation_phase_2]]
* [[Changes/No_more_automagic_Python_bytecompilation_phase_3]]
Now, we can define the macro to an error by default. Packagers can still
define it to any custom value.
We will define the macro as follows:
%__python %{error:attempt to use unversioned python, define %%__python to
%{__python2} or %{__python3} explicitly}
This is technically consistent with RHEL 8.
We will also define <code>%{python}</code> to <code>%{__python}</code> (we
will drop the current Lua logic that is designed to prevent
<code>%{python}</code> usage when <code>%{__python}</code> is
<code>/usr/bin/python</code>).
The default behavior will be an error:
$ rpm --eval '%__python'
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
$ rpm --eval '%python'
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
$ rpm --eval '%python_version'
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
$ rpm --eval '%python_sitelib'
error: attempt to use unversioned python, define %__python to
/usr/bin/python2 or /usr/bin/python3 explicitly
As advised, when redefined, the macros continue to work as currently:
$ rpm --define '__python %__python3' --eval '%python'
/usr/bin/python3
$ rpm --define '__python %__python3' --eval '%python_version'
3.9
Despite the error message not actually promoting this, packagers can even
explicitly define the macro to <code>/usr/bin/python</code> to mimic the
previous behavior. However, this remains forbidden in Fedora.
$ rpm --define '__python /usr/bin/python' --eval '%python'
/usr/bin/python
$ rpm --define '__python /usr/bin/python' --eval '%python_sitelib'
/usr/lib/python3.9/site-packages
== Feedback ==
* More consistent behavior between RHEL and Fedora.
* Avoids hard to debug mistakes when <code>/usr/bin/python</code> is not
present and macros like <code>%{python_sitelib}</code> are used.
* Doing the wrong thing is not the easiest default any more.
== Scope ==
* Proposal owners:
** Redefine <code>%__python</code> and <code>%python</code>
* Other developers: nothing, AFAIK packages in Fedora already dropped this
construct, however when not, packagers will need to define
<code>%__python</code> in spec to make it work. We believe the error
message is self-explanatory.
* Release engineering: no impact
* Policies and guidelines: Mostly already exist. The [
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_macros
macro definition] will need to be updated in the Python guidelines to match
reality.
* Trademark approval: not needed
== Upgrade/compatibility impact ==
No user impact. Some spec files might start to fail to build with this
change, but the error is self-explanatory.
== How To Test ==
See examples in Detailed Description.
== User Experience ==
No user impact. Some spec files might start to fail to build with this
change, but the error is self-explanatory.
== Dependencies ==
[[Changes/No_more_automagic_Python_bytecompilation_phase_3]]
== Contingency Plan ==
* Contingency mechanism: the change owners can revert the changes
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
This page is the documentation. The updated [
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_macros
macro list] will also serve as documentation.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/KDEEarlyOOM
== Summary ==
As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install
earlyoom package, and enable it by default. If both RAM and swap go below
10% free, earlyoom issues SIGTERM to the process with the largest
oom_score. If both RAM and swap go below 5% free, earlyoom issues SIGKILL
to the process with the largest oom_score. The idea is to recover from out
of memory situations sooner, rather than the typical complete system hang
in which the user has no other choice but to force power off.
== Owner ==
* Name: [[User:bcotton|Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
Shamelessly copied from Workstation, which did it in the last release:
Certain workloads have heavy memory demands, quickly consume all of RAM,
and start to heavily page out to swap. (Heavy paging, is often called "swap
thrashing" for added descriptive effect, probably because it's noticeable
and annoying). Incidental swap usage is a good thing, it frees up memory
for active pages used by a process. Heavy swap usage quickly leads to a
very negative UX, because it's slow, even on modern SSDs. Due to installer
defaults, the swap partition is made the same size as available memory (at
install time), which can be huge. This just extends swap thrashing time.
On the one hand, we want this resource hungry job to complete. On the other
hand, we want our system to be responsive while that other work is going
on. But once the GUI stutters or even comes to an apparent stand still
(hang), we're really wishing the kernel oom-killer would kick in and free
up memory, so we can start over (maybe using memory or thread limiting
options - which arguably should be more intelligently figured out, and that
too is a work in progress but beyond the scope of this feature).
However, once in a heavy swap scenario, it's relatively common the system
gets stuck in it, where GUI interactivity is terrible to non-existent, and
also the kernel oom-killer doesn't trigger. From a certain point of view,
this is working as intended. The kernel oom-killer is concerned about
keeping the kernel running. It's not at all concerned about user space
responsiveness.
Instead of the system becoming completely unresponsive for tens of minutes,
hours or days, this feature expects that an offending process (determined
by oom_score, same as the kernel oom-killer) will be killed off within
seconds or a few minutes.
== Benefit to Fedora ==
KDE users will be able to take advantage of the benefits Workstation users
got from enabling earlyOOM in Fedora 32:
* improved user experience by more quickly regaining control over one's
system, rather than having to force power off in low-memory situations
where there's aggressive swapping. Once a system becomes unresponsive, it's
completely reasonable for the user to assume the system is lost, but that
includes high potential for data loss.
* reducing forced poweroff as the main work around will increase data
collection, improving understanding of low memory situations and how to
handle them better
* earlyoom first sends SIGTERM to the chosen process, so it has a chance of
a proper shutdown, unlike the kernel's oom-killer
== Scope ==
* Proposal owners:
** Modify {{code|
https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in}} to include
earlyoom package for in {{code|kde-desktop}} section.
** Add {{code|
https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-kde.pres…
to include:
<pre>
# enable earlyoom by default on KDE
enable earlyoom.service
</pre>
* Other developers: None, unless KDE-based Spins/Labs want to opt out
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
earlyoom.service will be enabled on upgrade. An upgraded system should
exhibit the same behaviors as a newly-installed system.
== How To Test ==
* Fedora 31/32 KDE users can test today:
** {{code|sudo dnf install earlyoom}}
** {{code|sudo systemctl enable --now earlyoom}}
And then attempt to cause an out of memory situation. Examples:
** {{code|tail /dev/zero}}
** https://lkml.org/lkml/2019/8/4/15
== User Experience ==
earlyoom sends SIGTERM to processes based on oom_score when both memory and
swap have less than 10% free and SIGKILL when below 5%.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Owner reverts
changes
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
* {{code|man earlyoom}}
* https://github.com/rfjakob/earlyoom
* https://www.kernel.org/doc/gorman/html/understand/understand016.html
== Release Notes ==
The earlyoom service is now enabled by default in Fedora KDE.
The earlyoom service monitors system memory usage. If free memory falls
below a set limit, earlyoom terminates an appropriate process to free up
memory. As a result, the system does not become unresponsive for long
periods of time in low-memory situations.
The following is the default earlyoom configuration:
* If both RAM and swap go below 10% free, earlyoom sends the SIGTERM signal
to the process with the largest oom_score.
* If both RAM and swap go below 5% free, earlyoom sends the SIGKILL signal
to the process with the largest oom_score.
For more information, see the earlyoom man page.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis