devel-announce June 2020

devel-announce@lists.fedoraproject.org

11 participants
47 discussions

Upcoming Fedora 33 Change proposal deadlines
by Ben Cotton 17 Jul '20

17 Jul '20

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

1 2

Packagers with no corresponding valid bugzilla accounts
by Pierre-Yves Chibon 06 Jul '20

06 Jul '20

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…

1 2

IBus 1.5.23 - Fedora 33 System-Wide Change proposal
by Ben Cotton 30 Jun '20

30 Jun '20

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

1 0

Patches in Forge macros - Auto macros - Detached rpm changelogs - Fedora 33 System-Wide Change proposal
by Ben Cotton 30 Jun '20

30 Jun '20

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)  == 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

1 0

RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
by Ben Cotton 30 Jun '20

30 Jun '20

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

1 0

Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal
by Ben Cotton 30 Jun '20

30 Jun '20

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

1 0

Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal
by Ben Cotton 30 Jun '20

30 Jun '20

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

1 0

OpenLDAP without Non-threaded Libraries - Fedora 33 System-Wide Change proposal
by Ben Cotton 30 Jun '20

30 Jun '20

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

1 0

Make the unversioned %{__python} macro error by default - Fedora 33 Self-Contained Change proposal
by Ben Cotton 30 Jun '20

30 Jun '20

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

1 0

Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal
by Ben Cotton 30 Jun '20

30 Jun '20

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce June 2020