Patches in Forge macros - Auto macros - Detached rpm changelogs - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
== 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:
== 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.
%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
=== 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
IBus 1.5.23 - Fedora 33 System-Wide Change proposal
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 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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-announce@lists.fedoraproject.org
RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping == 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: == 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-call-bump-changelog-fonts/builds/ 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 %buildsys_name Your name %buildsys_email Your email 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_macros_-_Detached_rpm_changelogs 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 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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-announce@lists.fedoraproject.org
Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
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: bb...@redhat.com * Name: [[User:ckellner| Christian J. Kellner]] * Email: ckell...@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.html). 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-daemon 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 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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-announce@lists.fedoraproject.org
OpenLDAP without Non-threaded Libraries - Fedora 33 System-Wide Change proposal
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: mho...@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 ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@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-announce@lists.fedoraproject.org
Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
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: bcot...@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.preset}}
to include:
# enable earlyoom by default on KDE
enable earlyoom.service
* 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
Make the unversioned %{__python} macro error by default - Fedora 33 Self-Contained Change proposal
https://fedoraproject.org/wiki/Changes/PythonMacroError
== Summary ==
The %{__python} RPM macro (currently defined to
/usr/bin/python for backwards compatibility reasons) will be
defined to raise an error when used. Any derived macros
(%{python}, %{python_version},
%{python_sitleib} 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 /usr/bin/python in
Fedora packages remains forbidden.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email:
== Detailed Description ==
For years, the unversioned /usr/bin/python Python interpreter
MUST not be used when building RPM packages in Fedora. However, for
backwards compatibility reasons, the %{__python} macro was
defined to /usr/bin/python. As a direct consequence, all
derived macros:
* %{python}
* %{python_version}
* %{python_version_nodots}
* %{python_sitelib}
* %{python_sitearch}
* %py_shebang_fix
* %py_build variants
* %py_install variants
used /usr/bin/python as well, unless redefined to custom value
different than /usr/bin/python. Some of the macros
unfortunately evaluated to empty string when /usr/bin/python
was not installed in the buildroot.
We wanted to define %{__python} 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 %{python} to %{__python} (we
will drop the current Lua logic that is designed to prevent
%{python} usage when %{__python} is
/usr/bin/python).
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 /usr/bin/python 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 /usr/bin/python is not
present and macros like %{python_sitelib} are used.
* Doing the wrong thing is not the easiest default any more.
== Scope ==
* Proposal owners:
** Redefine %__python and %python
* Other developers: nothing, AFAIK packages in Fedora already dropped this
construct, however when not, packagers will need to define
%__python 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
___
