CentOS Errata and Bugfix Advisory 2020:2659
Upstream details at : https://access.redhat.com/errata/RHBA-2020:2659
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
308539b57a0114a416b08951260b3004a47eea3f0428a9f7e7facf056b58fd53 libgudev1-219-73.el7_8.8.i686.rpm
32ddfd836f86b19e1d7aaa1d4c3a9ce5febefde1fc3d97d333290de0da348c36 libgudev1-219-73.el7_8.8.x86_64.rpm
963ef1a3d5e79721a0e098a83becbe088b1fc3a651b677ba3132cef1fe0d94f9 libgudev1-devel-219-73.el7_8.8.i686.rpm
10206d79be9585d77ec804594b0b9b7ee1a98c88e6ccc9cdbb97f77b3e28b12a libgudev1-devel-219-73.el7_8.8.x86_64.rpm
86125d34008aa7e84ef19e51da544bbad7a1b76660fe24e5563fe5dc3069dff1 systemd-219-73.el7_8.8.x86_64.rpm
a371370c6fdaee61698cf6414e70496ff41cca58847d27a25de9864859ae9685 systemd-devel-219-73.el7_8.8.i686.rpm
7034ef244407efdc1c17a14363e50eaa9c589c84bbf886139b9fad7e7a6922d0 systemd-devel-219-73.el7_8.8.x86_64.rpm
4b420cdb7274ca935f3d283d5808d55c20396930a0765f6d938cf811dc2ba909 systemd-journal-gateway-219-73.el7_8.8.x86_64.rpm
f7940bca479a5a6710d95dcd9e2f5d688caabc3046f9db25dbd56b16fda54d46 systemd-libs-219-73.el7_8.8.i686.rpm
ac9cbb53bbc1915e7c6b2d8a08db6e87e2104bb4f2b708d9590ea6430872b9b6 systemd-libs-219-73.el7_8.8.x86_64.rpm
95feec5d6656b6eaf7802c9ee7be76e019588e7e453b88925738fa2339f5a892 systemd-networkd-219-73.el7_8.8.x86_64.rpm
5119f092a7841e1ffdffdaffcdc8c33c888df2cef7dab0ef3dc9da9c13b9dd34 systemd-python-219-73.el7_8.8.x86_64.rpm
9f5887416fd66523d3961064be9b692b5084d028f1bfde7d28ff55dc9a0bad53 systemd-resolved-219-73.el7_8.8.i686.rpm
f66fbfc873e73ba8a9679658bff997c549b9bdb807d798f57856a45eee7199cf systemd-resolved-219-73.el7_8.8.x86_64.rpm
08ae1f4a8af88f1d744999d2c11c6aebff0125abbaf899e7e1067241c3756373 systemd-sysv-219-73.el7_8.8.x86_64.rpm
Source:
5f51c2e9b139106137743c153bc1820ec88963eb5f638e4424c109da6465f320 systemd-219-73.el7_8.8.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@irc.freenode.net
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
Tuesday, June 30, 2020
[CentOS-announce] CEBA-2020:2662 CentOS 7 selinux-policy BugFix Update
CentOS Errata and Bugfix Advisory 2020:2662
Upstream details at : https://access.redhat.com/errata/RHBA-2020:2662
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
7565ffd1f3418c04442b5eb731eeccc4cc52f2089938035d4dc04e777568b2b0 selinux-policy-3.13.1-266.el7_8.1.noarch.rpm
f2dacc5e31de8fa35d3ceb452c4d5203a9cbb96e0aa8f56b599c63f1019cd8b5 selinux-policy-devel-3.13.1-266.el7_8.1.noarch.rpm
2fb36e1a13c028ecc1c286681c25e1b1c425c4496493d62e3b764a873120e8ab selinux-policy-doc-3.13.1-266.el7_8.1.noarch.rpm
afaa647d4aec875a206806a35bc776f8861fa3430e194adddaa342b70883afa2 selinux-policy-minimum-3.13.1-266.el7_8.1.noarch.rpm
bd3c1accb03bd25d3af8839896c75d2a892ce485713437fda2f249fa00c9f04b selinux-policy-mls-3.13.1-266.el7_8.1.noarch.rpm
26d654fb629b24814ed5776e478cc6e9c0b7edb24b3bde1adc0995421da07293 selinux-policy-sandbox-3.13.1-266.el7_8.1.noarch.rpm
75493cf7ada339fe000804c858943eed597295053e9164726dc0424986931344 selinux-policy-targeted-3.13.1-266.el7_8.1.noarch.rpm
Source:
7012c0fedb27556b513cb7d18d1ed0f7c3480febd4f4d016176f16331e1bc01e selinux-policy-3.13.1-266.el7_8.1.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@irc.freenode.net
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
Upstream details at : https://access.redhat.com/errata/RHBA-2020:2662
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
7565ffd1f3418c04442b5eb731eeccc4cc52f2089938035d4dc04e777568b2b0 selinux-policy-3.13.1-266.el7_8.1.noarch.rpm
f2dacc5e31de8fa35d3ceb452c4d5203a9cbb96e0aa8f56b599c63f1019cd8b5 selinux-policy-devel-3.13.1-266.el7_8.1.noarch.rpm
2fb36e1a13c028ecc1c286681c25e1b1c425c4496493d62e3b764a873120e8ab selinux-policy-doc-3.13.1-266.el7_8.1.noarch.rpm
afaa647d4aec875a206806a35bc776f8861fa3430e194adddaa342b70883afa2 selinux-policy-minimum-3.13.1-266.el7_8.1.noarch.rpm
bd3c1accb03bd25d3af8839896c75d2a892ce485713437fda2f249fa00c9f04b selinux-policy-mls-3.13.1-266.el7_8.1.noarch.rpm
26d654fb629b24814ed5776e478cc6e9c0b7edb24b3bde1adc0995421da07293 selinux-policy-sandbox-3.13.1-266.el7_8.1.noarch.rpm
75493cf7ada339fe000804c858943eed597295053e9164726dc0424986931344 selinux-policy-targeted-3.13.1-266.el7_8.1.noarch.rpm
Source:
7012c0fedb27556b513cb7d18d1ed0f7c3480febd4f4d016176f16331e1bc01e selinux-policy-3.13.1-266.el7_8.1.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #centos@irc.freenode.net
Twitter: @JohnnyCentOS
_______________________________________________
CentOS-announce mailing list
CentOS-announce@centos.org
https://lists.centos.org/mailman/listinfo/centos-announce
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-leave@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
== 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-leave@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
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: <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-call-changelog-fonts/builds/
== 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
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
== 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-call-changelog-fonts/builds/
== 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
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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: <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-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
<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_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-leave@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
== 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-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
<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_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-leave@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
Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal
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@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
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
== 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@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
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
== 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@redhat.com
* Name: [[User:ckellner| Christian J. Kellner]]
* Email: ckellner@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
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
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: bcotton@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:
<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.
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@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:
<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
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
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: mhonek@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.
--
== 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@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
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Make the unversioned %{__python} macro error by default - Fedora 33 Self-Contained Change proposal
== 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@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.
-- 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@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
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Monday, June 29, 2020
Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
== Summary ==
The Fedora workstation livecd is the default Fedora variant getfedora.org advices people to download.
As such most Fedora workstation installs will be done from the livecd. This means that any package which is part of the livecd will be part of the default install for most users.
Dmraid is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service, which waits for all device-detection to be done + some extra waiting just to be sure. This significantly slows down booting on various systems.
Fedora only support these RAID sets when they are already configured in the BIOS at installation time. So we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede@redhat.com
== Detailed Description ==
Dmraid is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service. The other package is device-mapper-multipath see [[Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD|Remove device-mapper-multipath from the Fedora workstation livecd]].
Dmraid is necessary to support firmware-raid (motherboard BIOS built-in RAID support) for non Intel firmware RAID sets. These RAID sets are quite rare and we have never supported configuring these RAID sets after the installation without manually setting it up. Since we only support these sets when they are already configured in the BIOS at installation time, we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run.
Note then when installing from the server or everything netboot isos, dmraid depending on the obsolete udev-settle service is not a problem, because then it will not be installed at all. Anaconda (the installer) adds storage related packages such as dmraid to the installation package-set as necessary for the storage found at installation time. This means that for such installs, if a dmraid set is later configured, the user manually needs to install dmraid to be able to use the RAID set. This change adds a similar requirement to livecd installs, there the user will now need to do a "systemctl enable dmraid.service" if a dmraid set is added to the system later.
There has been [https://bugzilla.redhat.com/show_bug.cgi?id=1795014 a bug] open against dmraid for this issue for a while now. As pointed out there, this change can easily be implemented with some small changes to the shell script which gets started by the dmraid service.
== Benefit to Fedora ==
systemd-udev-settle.service causes a significant and sometimes quite long delay during boot. Removing / disabling the last 2 services depending on this long obsolete helper service will remove the unnecessary boot delay.
== Scope ==
* Proposal owners:
** Prepare the suggested dmraid activation script changes and push out a new dmraid package with these changes added
** Coordinate this with the dmraid maintainers
* Other developers:
** I will make sure that the dmraid maintainers are aware of and agree with these changes. I will take care of these changes myself.
* Release engineering: [https://pagure.io/releng/issue/9559 #9559] (a check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
After upgrading, if no dmraid sets are found on the first boot with the new package, the dmraid service will disable itself, just as it will on new F33 installs.
== How To Test ==
# Install F33 on a machine / VM without dmraid
# Boot the installed system
# Reboot the installed system
# Do "systemctl status dmraid.service", the output should be "loaded (...; disabled; ...)" and "inactive (dead)"
== User Experience ==
Faster booting Fedora when installed from the livecd.
== Dependencies ==
There are no other changes / package updates this Change depends on; or which this change impacts.
== Contingency Plan ==
* Contingency mechanism: Revert the activation script changes if they cause problems
* Blocks release? No
== Documentation ==
This change does not require any documentation.
The Fedora workstation livecd is the default Fedora variant getfedora.org advices people to download.
As such most Fedora workstation installs will be done from the livecd. This means that any package which is part of the livecd will be part of the default install for most users.
Dmraid is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service, which waits for all device-detection to be done + some extra waiting just to be sure. This significantly slows down booting on various systems.
Fedora only support these RAID sets when they are already configured in the BIOS at installation time. So we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede@redhat.com
== Detailed Description ==
Dmraid is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service. The other package is device-mapper-multipath see [[Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD|Remove device-mapper-multipath from the Fedora workstation livecd]].
Dmraid is necessary to support firmware-raid (motherboard BIOS built-in RAID support) for non Intel firmware RAID sets. These RAID sets are quite rare and we have never supported configuring these RAID sets after the installation without manually setting it up. Since we only support these sets when they are already configured in the BIOS at installation time, we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run.
Note then when installing from the server or everything netboot isos, dmraid depending on the obsolete udev-settle service is not a problem, because then it will not be installed at all. Anaconda (the installer) adds storage related packages such as dmraid to the installation package-set as necessary for the storage found at installation time. This means that for such installs, if a dmraid set is later configured, the user manually needs to install dmraid to be able to use the RAID set. This change adds a similar requirement to livecd installs, there the user will now need to do a "systemctl enable dmraid.service" if a dmraid set is added to the system later.
There has been [https://bugzilla.redhat.com/show_bug.cgi?id=1795014 a bug] open against dmraid for this issue for a while now. As pointed out there, this change can easily be implemented with some small changes to the shell script which gets started by the dmraid service.
== Benefit to Fedora ==
systemd-udev-settle.service causes a significant and sometimes quite long delay during boot. Removing / disabling the last 2 services depending on this long obsolete helper service will remove the unnecessary boot delay.
== Scope ==
* Proposal owners:
** Prepare the suggested dmraid activation script changes and push out a new dmraid package with these changes added
** Coordinate this with the dmraid maintainers
* Other developers:
** I will make sure that the dmraid maintainers are aware of and agree with these changes. I will take care of these changes myself.
* Release engineering: [https://pagure.io/releng/issue/9559 #9559] (a check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
After upgrading, if no dmraid sets are found on the first boot with the new package, the dmraid service will disable itself, just as it will on new F33 installs.
== How To Test ==
# Install F33 on a machine / VM without dmraid
# Boot the installed system
# Reboot the installed system
# Do "systemctl status dmraid.service", the output should be "loaded (...; disabled; ...)" and "inactive (dead)"
== User Experience ==
Faster booting Fedora when installed from the livecd.
== Dependencies ==
There are no other changes / package updates this Change depends on; or which this change impacts.
== Contingency Plan ==
* Contingency mechanism: Revert the activation script changes if they cause problems
* Blocks release? No
== Documentation ==
This change does not require any documentation.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
Remove device-mapper-multipath from the Fedora workstation livecd - Fedora 33 System-Wide Change proposal
== Summary ==
The Fedora workstation livecd is the default Fedora variant getfedora.org advices people to download.
As such most Fedora workstation installs will be done from the livecd. This means that any package which is part of the livecd will be part of the default install for most users.
device-mapper-multipath is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service, which waits for all device-detection to be done + some extra waiting just to be sure. This significantly slows down booting on various systems.
Multipath support is only necessary for installations in data-centers or other enterprise setups, as such having device-mapper-multipath on the livecd is not really necessary. For installations which do actually need this device-mapper-multipath the server installation iso can be used and this is a better fit for such installations.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede@redhat.com
== Detailed Description ==
device-mapper-multipath is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service. The other package is dmraid see [[Changes/DisableDmraidOnFirstRun|Disable dmraid.service on first run]].
Multipath support is only necessary for installations in data-centers or other enterprise setups, as such having device-mapper-multipath on the livecd is not really necessary. For installations which do actually need this device-mapper-multipath the server installation iso can be used and this is a better fit for such installations.
Note then when installing from the server or everything netboot isos, device-mapper-multipath depending on the obsolete udev-settle service is not a problem, because then it will not be installed at all. Anaconda (the installer) adds storage related packages such as device-mapper-multipath to the installation package-set as necessary for the storage found at installation time. So any installs done through the netinst isos already will not have device-mapper-multipath installed.
== Feedback ==
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
== Benefit to Fedora ==
systemd-udev-settle.service causes a significant and sometimes quite long delay during boot. Removing / disabling the last 2 services depending on this long obsolete helper service will remove the unnecessary boot delay.
== Scope ==
* Proposal owners:
** Change the livecd packagelist (comps) to no longer include the device-mapper-multipath package
* Other developers:
** No action is required by other developers
** Except if another package still brings in device-mapper-multipath through dependencies, then this needs to be solved / coordinated with that other packages maintainers
* Release engineering: [https://pagure.io/releng/issue/9560 #9560] (a check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This only affects new installs, upgrades of installs which have device-mapper-multipath installed will still have it installed after the upgrade.
== How To Test ==
# Install F33 on a machine / VM
# Do "rpm -q device-mapper-multipath", the output should be "device-mapper-multipath" is not installed
== User Experience ==
Faster booting Fedora when installed from the livecd.
== Dependencies ==
There are no other changes / package updates this Change depends on; or which this change impacts.
== Contingency Plan ==
* Contingency mechanism: Re-add device-mapper-multipath to the livecd if the dropping of it causes problems.
* Blocks release? No
== Documentation ==
This change does not require any documentation.
-- The Fedora workstation livecd is the default Fedora variant getfedora.org advices people to download.
As such most Fedora workstation installs will be done from the livecd. This means that any package which is part of the livecd will be part of the default install for most users.
device-mapper-multipath is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service, which waits for all device-detection to be done + some extra waiting just to be sure. This significantly slows down booting on various systems.
Multipath support is only necessary for installations in data-centers or other enterprise setups, as such having device-mapper-multipath on the livecd is not really necessary. For installations which do actually need this device-mapper-multipath the server installation iso can be used and this is a better fit for such installations.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede@redhat.com
== Detailed Description ==
device-mapper-multipath is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service. The other package is dmraid see [[Changes/DisableDmraidOnFirstRun|Disable dmraid.service on first run]].
Multipath support is only necessary for installations in data-centers or other enterprise setups, as such having device-mapper-multipath on the livecd is not really necessary. For installations which do actually need this device-mapper-multipath the server installation iso can be used and this is a better fit for such installations.
Note then when installing from the server or everything netboot isos, device-mapper-multipath depending on the obsolete udev-settle service is not a problem, because then it will not be installed at all. Anaconda (the installer) adds storage related packages such as device-mapper-multipath to the installation package-set as necessary for the storage found at installation time. So any installs done through the netinst isos already will not have device-mapper-multipath installed.
== Feedback ==
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->
== Benefit to Fedora ==
systemd-udev-settle.service causes a significant and sometimes quite long delay during boot. Removing / disabling the last 2 services depending on this long obsolete helper service will remove the unnecessary boot delay.
== Scope ==
* Proposal owners:
** Change the livecd packagelist (comps) to no longer include the device-mapper-multipath package
* Other developers:
** No action is required by other developers
** Except if another package still brings in device-mapper-multipath through dependencies, then this needs to be solved / coordinated with that other packages maintainers
* Release engineering: [https://pagure.io/releng/issue/9560 #9560] (a check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This only affects new installs, upgrades of installs which have device-mapper-multipath installed will still have it installed after the upgrade.
== How To Test ==
# Install F33 on a machine / VM
# Do "rpm -q device-mapper-multipath", the output should be "device-mapper-multipath" is not installed
== User Experience ==
Faster booting Fedora when installed from the livecd.
== Dependencies ==
There are no other changes / package updates this Change depends on; or which this change impacts.
== Contingency Plan ==
* Contingency mechanism: Re-add device-mapper-multipath to the livecd if the dropping of it causes problems.
* Blocks release? No
== Documentation ==
This change does not require any documentation.
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
[FreeBSD-Announce] Virtual Bug Squash, Saturday 11th July 1400-2100UTC
Hello Everyone,
On the 11th July 2020 from 1400-2100 UTC we will be running a coordinated
virtual Bug Squash. FreeBSD has a Problem Report (PR) database[1] where users
and developers are encouraged to file issues and regressions they find in both
the base system and ports tree.
A Bug Squash is a focused session where we try to triage, process, fix and
close as many reports as we can from the PR database. This July 11th Bug Squash
we will focus on closing as many PRs with patches as we can, some rationale for
this is written up here[4].
While we do process and close issues there are a large number of PRs with
patches attached that should be processed. At the time of writing there are:
- all base system PRs with patches (639)[2]
- all base system PRs with patches, but assigned to no one (277)[3]
We will host a google meet at the start of the Bug Squash to provide an
introduction to the process and will use the #freebsd-bugs irc channel on
freenode to coordinate work, triage and discuss PRs and patches.
https://meet.google.com/dfp-fsou-pwi
We look forward to joining you to squash bugs and commit fixes.
- Tom and Allan
Some other links:
https://wiki.freebsd.org/OfficeHours
https://wiki.freebsd.org/MarkLinimon/BugbustingOfficeHours
https://wiki.freebsd.org/Bugathons
https://wiki.freebsd.org/MarkLinimon/KitchenerNotes
https://wiki.freebsd.org/BugBusting
https://adventurist.me/posts/00301
[1]: https://bugs.freebsd.org
[2]: https://bugs.freebsd.org/bugzilla/buglist.cgi?keywords=patch%2C%20&keywords_type=allwords&limit=0&list_id=296749&order=bug_id%20DESC&product=Base%20System&query_format=advanced&resolution=---
[3]: https://bugs.freebsd.org/bugzilla/buglist.cgi?email1=bugs%40FreeBSD.org&emailassigned_to1=1&emailtype1=substring&keywords=patch%2C%20&keywords_type=allwords&list_id=296748&product=Base%20System&query_format=advanced&resolution=---
[4]: https://wiki.freebsd.org/Bugathons/PRsWithPatches
_______________________________________________
freebsd-announce@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-announce
To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org"
On the 11th July 2020 from 1400-2100 UTC we will be running a coordinated
virtual Bug Squash. FreeBSD has a Problem Report (PR) database[1] where users
and developers are encouraged to file issues and regressions they find in both
the base system and ports tree.
A Bug Squash is a focused session where we try to triage, process, fix and
close as many reports as we can from the PR database. This July 11th Bug Squash
we will focus on closing as many PRs with patches as we can, some rationale for
this is written up here[4].
While we do process and close issues there are a large number of PRs with
patches attached that should be processed. At the time of writing there are:
- all base system PRs with patches (639)[2]
- all base system PRs with patches, but assigned to no one (277)[3]
We will host a google meet at the start of the Bug Squash to provide an
introduction to the process and will use the #freebsd-bugs irc channel on
freenode to coordinate work, triage and discuss PRs and patches.
https://meet.google.com/dfp-fsou-pwi
We look forward to joining you to squash bugs and commit fixes.
- Tom and Allan
Some other links:
https://wiki.freebsd.org/OfficeHours
https://wiki.freebsd.org/MarkLinimon/BugbustingOfficeHours
https://wiki.freebsd.org/Bugathons
https://wiki.freebsd.org/MarkLinimon/KitchenerNotes
https://wiki.freebsd.org/BugBusting
https://adventurist.me/posts/00301
[1]: https://bugs.freebsd.org
[2]: https://bugs.freebsd.org/bugzilla/buglist.cgi?keywords=patch%2C%20&keywords_type=allwords&limit=0&list_id=296749&order=bug_id%20DESC&product=Base%20System&query_format=advanced&resolution=---
[3]: https://bugs.freebsd.org/bugzilla/buglist.cgi?email1=bugs%40FreeBSD.org&emailassigned_to1=1&emailtype1=substring&keywords=patch%2C%20&keywords_type=allwords&list_id=296748&product=Base%20System&query_format=advanced&resolution=---
[4]: https://wiki.freebsd.org/Bugathons/PRsWithPatches
_______________________________________________
freebsd-announce@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-announce
To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org"
NetworkManager keyfile instead of ifcfg-rh - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh
== Summary ==
Change the default settings plugin of NetworkManager so that new
profiles will be created in keyfile format instead of ifcfg-rh format.
== Owner ==
* Name: [[User:Thaller| Thomas Haller]]
* Email: <thaller@redhat.com>
== Detailed Description ==
NetworkManager supports settings plugins to persist connection
profiles to disk. There is the native ''keyfile'' format and the
Fedora/RHEL specific ''ifcfg-rh'' format originally from initscripts.
The keyfile plugin is always enabled in NetworkManager and can handle
any supported type of profile. It stores profiles under
`/{etc,usr/lib,run}/NetworkManager/system-connections` and is
documented in [https://developer.gnome.org/NetworkManager/stable/nm-settings-keyfile.html
nm-settings-keyfile manual]. The ifcfg-rh format is in part compatible
with the network-scripts package from initscripts, however both
network-scripts and NetworkManager define their own extensions
([https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html
[1]]). Since network-scripts and NetworkManager are fundamentally
different, the same ifcfg file is not treated exactly the same by both
systems. In the past, having the ifcfg-rh format made it easier for
users familiar with initscripts to migrate to/from NetworkManager.
The settings plugins are configurable in
[https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html
NetworkManager.conf] via the `"main.plugins"` option. Multiple plugins
can be configured and on Fedora 32 and older, the compile time default
for the option is `"ifcfg-rh,keyfile"`. This means, that when
NetworkManager stores a new profile to disk, it will first try to
persist it in ifcfg-rh format before falling back to keyfile format,
if the ifcfg-rh plugin doesn't support the profile type. When reading
profiles from disk, NetworkManager will read and expose profiles from
both settings plugins and when modifying an existing profile, it will
update the existing file and preserve the settings plugin.
This Change is about to change the default for `"main.plugins"` from
`"ifcfg-rh,keyfile"` to `"keyfile,ifcfg-rh"`.
== Feedback ==
This was brought up on the NetworkManager mailing list
([https://mail.gnome.org/archives/networkmanager-list/2020-May/msg00002.html
[1]]]).
Fedora CoreOS doesn't use ifcfg-rh files at all, only keyfile. Also,
RHEL CoreOS uses the `"main.plugins=ifcfg-rh,keyfile"` configuration
too. For CoreOS this of course is simpler, because they don't deal
with existing user configurations and tools that would break during
upgrade.
== Benefit to Fedora ==
The long term goal of NetworkManager is to move away from ifcfg-rh
files. That will be difficult as it affects existing installations and
will require migration of existing configurations. This change is only
a first step and affects how NetworkManager by default persists new
profiles to disk.
The ifcfg-rh format arguably has an uglier syntax and, contrary to
keyfile, does not support all profile types. Also, keyfile plugin is
available on every NetworkManager installation because that is the
only plugin that supports all profiles. Having multiple plugins and
file formats is confusing. By now, initscripts' `network-script`
package is deprecated in Fedora and upstream wants to move away from
that format in the long term. Also maintaining multiple settings
plugins is a maintainance burden, and in the past there were subtle
bugs where ifcfg-rh did not implement all settings (e.g.
[https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10754
CVE-2020-10754]). On other Linux distributions NetworkManager uses the
keyfile format by default. It is a general goal that NetworkManager
works similar on all distributions.
== Scope ==
* Proposal owners: The default settings for `"main.plugins"` can
already be selected at compile time. This only requires building the
package with a different default
([https://src.fedoraproject.org/rpms/NetworkManager/blob/a06b38bcbe8f9a38badab4f37e8c6fae240428b7/f/NetworkManager.spec#_759
[3]]).
* Other developers: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This affects most users, unless they explicitly set the option in
NetworkManager.conf configuration. The biggest effect of this change
is that new profiles will now preferably be persisted in keyfile
format. This changes behavior for users who expect NetworkManager to
write ifcfg-rh files, or who have scripts or tools that expect that.
What will still work is that existing ifcfg files are loaded after
upgrade. Users who only use the D-Bus API (via one of the client
applications like nmcli or the GUI), shouldn't notice the difference.
As before, users still can explicitly configure the settings plugins
in NetworkManager.conf. This only affects the default, but it affects
existing installations if the user didn't explicitly configure
NetworkManager's `"main.plugins"` option.
The Change will be implemented by changing the compile time default,
instead of dropping a configuration snippet. The reason is that it is
preferably that the installation of NetworkManager avoids extra
configuration. The default behavior should be achived without any
configuration. During package update there would be the possibility to
drop a file `/etc/NetworkManager/02-update-plugins-ifcfg-rh.conf` that
preserves the previous behavior. However, I don't think that is
necessary. After upgrading NetworkManager, it will still read ifcfg-rh
file so for the user it is less necessary to preserve the previous
behavior. Also, dropping configuration snippets during package upgrade
has its own downsides because new installations behave different than
upgraded systems.
== How To Test ==
You can already test the effect by explicitly configuring the setting
which will become the default. For example, add a file
`/etc/NetworkManager/conf.d/99-main-plugins.conf` with content
[main]
plugins=keyfile,ifcfg-rh
== User Experience ==
NetworkManager now preferably uses the keyfile format (INI files).
This format is probably easier to understand to users and also has a
closer resemblance to how the profile is presented in nmcli.
If the user is using NetworkManager tools that use the D-Bus API (like
nmcli or the GUI), then the used storage plugin and format is usually
of no concern for the user.
== Dependencies ==
None
== Contingency Plan ==
The `"main.plugins"` option exists for a long time in NetworkManager.
All that changes here is the default of this option.
* Contingency mechanism: revert the change
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
I am not aware of documentation that gets affected by this.
== Release Notes ==
NetworkManager now prefers the keyfile settings plugin over ifcfg-rh
plugin when writing new connection profiles to disk. Existing ifcfg-rh
files are still handled as before.
--
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-leave@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
== Summary ==
Change the default settings plugin of NetworkManager so that new
profiles will be created in keyfile format instead of ifcfg-rh format.
== Owner ==
* Name: [[User:Thaller| Thomas Haller]]
* Email: <thaller@redhat.com>
== Detailed Description ==
NetworkManager supports settings plugins to persist connection
profiles to disk. There is the native ''keyfile'' format and the
Fedora/RHEL specific ''ifcfg-rh'' format originally from initscripts.
The keyfile plugin is always enabled in NetworkManager and can handle
any supported type of profile. It stores profiles under
`/{etc,usr/lib,run}/NetworkManager/system-connections` and is
documented in [https://developer.gnome.org/NetworkManager/stable/nm-settings-keyfile.html
nm-settings-keyfile manual]. The ifcfg-rh format is in part compatible
with the network-scripts package from initscripts, however both
network-scripts and NetworkManager define their own extensions
([https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html
[1]]). Since network-scripts and NetworkManager are fundamentally
different, the same ifcfg file is not treated exactly the same by both
systems. In the past, having the ifcfg-rh format made it easier for
users familiar with initscripts to migrate to/from NetworkManager.
The settings plugins are configurable in
[https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html
NetworkManager.conf] via the `"main.plugins"` option. Multiple plugins
can be configured and on Fedora 32 and older, the compile time default
for the option is `"ifcfg-rh,keyfile"`. This means, that when
NetworkManager stores a new profile to disk, it will first try to
persist it in ifcfg-rh format before falling back to keyfile format,
if the ifcfg-rh plugin doesn't support the profile type. When reading
profiles from disk, NetworkManager will read and expose profiles from
both settings plugins and when modifying an existing profile, it will
update the existing file and preserve the settings plugin.
This Change is about to change the default for `"main.plugins"` from
`"ifcfg-rh,keyfile"` to `"keyfile,ifcfg-rh"`.
== Feedback ==
This was brought up on the NetworkManager mailing list
([https://mail.gnome.org/archives/networkmanager-list/2020-May/msg00002.html
[1]]]).
Fedora CoreOS doesn't use ifcfg-rh files at all, only keyfile. Also,
RHEL CoreOS uses the `"main.plugins=ifcfg-rh,keyfile"` configuration
too. For CoreOS this of course is simpler, because they don't deal
with existing user configurations and tools that would break during
upgrade.
== Benefit to Fedora ==
The long term goal of NetworkManager is to move away from ifcfg-rh
files. That will be difficult as it affects existing installations and
will require migration of existing configurations. This change is only
a first step and affects how NetworkManager by default persists new
profiles to disk.
The ifcfg-rh format arguably has an uglier syntax and, contrary to
keyfile, does not support all profile types. Also, keyfile plugin is
available on every NetworkManager installation because that is the
only plugin that supports all profiles. Having multiple plugins and
file formats is confusing. By now, initscripts' `network-script`
package is deprecated in Fedora and upstream wants to move away from
that format in the long term. Also maintaining multiple settings
plugins is a maintainance burden, and in the past there were subtle
bugs where ifcfg-rh did not implement all settings (e.g.
[https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10754
CVE-2020-10754]). On other Linux distributions NetworkManager uses the
keyfile format by default. It is a general goal that NetworkManager
works similar on all distributions.
== Scope ==
* Proposal owners: The default settings for `"main.plugins"` can
already be selected at compile time. This only requires building the
package with a different default
([https://src.fedoraproject.org/rpms/NetworkManager/blob/a06b38bcbe8f9a38badab4f37e8c6fae240428b7/f/NetworkManager.spec#_759
[3]]).
* Other developers: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This affects most users, unless they explicitly set the option in
NetworkManager.conf configuration. The biggest effect of this change
is that new profiles will now preferably be persisted in keyfile
format. This changes behavior for users who expect NetworkManager to
write ifcfg-rh files, or who have scripts or tools that expect that.
What will still work is that existing ifcfg files are loaded after
upgrade. Users who only use the D-Bus API (via one of the client
applications like nmcli or the GUI), shouldn't notice the difference.
As before, users still can explicitly configure the settings plugins
in NetworkManager.conf. This only affects the default, but it affects
existing installations if the user didn't explicitly configure
NetworkManager's `"main.plugins"` option.
The Change will be implemented by changing the compile time default,
instead of dropping a configuration snippet. The reason is that it is
preferably that the installation of NetworkManager avoids extra
configuration. The default behavior should be achived without any
configuration. During package update there would be the possibility to
drop a file `/etc/NetworkManager/02-update-plugins-ifcfg-rh.conf` that
preserves the previous behavior. However, I don't think that is
necessary. After upgrading NetworkManager, it will still read ifcfg-rh
file so for the user it is less necessary to preserve the previous
behavior. Also, dropping configuration snippets during package upgrade
has its own downsides because new installations behave different than
upgraded systems.
== How To Test ==
You can already test the effect by explicitly configuring the setting
which will become the default. For example, add a file
`/etc/NetworkManager/conf.d/99-main-plugins.conf` with content
[main]
plugins=keyfile,ifcfg-rh
== User Experience ==
NetworkManager now preferably uses the keyfile format (INI files).
This format is probably easier to understand to users and also has a
closer resemblance to how the profile is presented in nmcli.
If the user is using NetworkManager tools that use the D-Bus API (like
nmcli or the GUI), then the used storage plugin and format is usually
of no concern for the user.
== Dependencies ==
None
== Contingency Plan ==
The `"main.plugins"` option exists for a long time in NetworkManager.
All that changes here is the default of this option.
* Contingency mechanism: revert the change
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
I am not aware of documentation that gets affected by this.
== Release Notes ==
NetworkManager now prefers the keyfile settings plugin over ifcfg-rh
plugin when writing new connection profiles to disk. Existing ifcfg-rh
files are still handled as before.
--
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-leave@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
Cleanup GNOME Hidden Boot Menu Integration - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
== Summary ==
GNOME integrates with Fedora's [[Changes/HiddenGrubMenu|hidden boot
menu feature]] to signal to the bootloader that boot was successful
and to request the menu to be shown the next boot when "Boot Options"
is selected in the Shutdown/Reboot dialog. Currently Fedora carries
downstream patches for this, which directly call the Fedora specific
grub2-set-bootflag helper. The goal of this change is to replace these
downstream patches with a clean bootloader agnostic solution which can
be submitted upstream.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede@redhat.com
== Detailed Description ==
GNOME has 2 integration points with the
[[Changes/HiddenGrubMenu|hidden boot menu feature]]:
# Requesting the menu to be shown the next boot when "Boot Options" is
selected in the Shutdown/Reboot dialog.
# Signalling the bootloader that the boot was successful.
To replace our downstream patches for 1. we can use the new(ish)
systemd DBUS API used by "systemctl reboot --boot-loader-menu=60".
This currently only works with sd-boot, but systemd has hooks to allow
integration with other bootloaders, see the
[https://github.com/systemd/systemd/blob/master/docs/ENVIRONMENT.md
SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU env. variable documentation]. So we
can support this in grub2 with some relatively simply changes and then
replace our downstream patches for this with new patches using the
systemd DBUS API for this.
Replacing our downstream patches for 2. with an upstreamable
bootloader agnostic solution is somewhat involved. systemd has its
[https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ Automatic Boot
Assessment] feature, which is somewhat similar in that it to deals
with boot success detection, but its behavior on failure is different
(auto fallback to an older kernel) and it is a sd-boot specific
feature. Still we can use some parts of this. The boot-complete.target
and the concept of having a systemd-bless-boot.service which Requires
that target to be reached before it runs. So replacing out downstream
patches for 2. will consists of 2 parts:
# grub2 changes: Add a grub2-bless-boot.service which Requires
boot-complete.target and which does the equivalent of
"grub2-set-bootflag boot_success" when that target is reached
# GNOME changes: Add a oneshot gnome-wait-for-boot-success.service to
boot-complete.target, this will start a simple helper which listens on
a unix socket until signalled, thus delaying the completion of
boot-complete.target until it is signalled; and in the places where
the downstream patches are currently directly calling
"grub2-set-bootflag boot_success" signal (write a byte) this unix
socket instead.
Also see this [https://lists.freedesktop.org/archives/systemd-devel/2020-June/044800.html
mailinglist discussion].
== Benefit to Fedora ==
This change will remove some technical-debt in the form of a couple of
quick-and-dirty downstream patches from Fedora and will align GNOME's
integration with the [[Changes/HiddenGrubMenu|hidden boot menu
feature]] with our upstream first policy.
== Scope ==
* Proposal owners:
Create the necessary changes ASAP and submit these to Fedora's
[https://github.com/rhboot/grub2/ grub2] and
[https://gitlab.gnome.org/GNOME/ GNOME] upstreams.
* Other developers:
The bootloader team needs to do a new grub2 build with the changes
added and the desktop team needs to add the GNOME changes to the GNOME
packages. I will coordinate this with both teams.
* Release engineering: [https://pagure.io/releng/issue/9557 #9557] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change does not impact upgrades, the interface between the OS and
grub2 still goes through the same unmodified grubenv settings. The
only changes are in how we make the grubenv changes and all parts
involved in that will be updated together.
== How To Test ==
# Tests
## Install Fedora Workstation in a fresh vm or select reclaim
diskspace -> delete all in the installer (do a single os install).
## Boot the system the grub menu should NOT show
## Login, wait 2 minutes then presss "CTRL + ALT + F6" followed by
"CTRL + ALT + DEL" to do a reboot from the text-console without going
through the GNOME reboot dialog. The grub menu should NOT show on the
new boot.
## Reboot from the GNOME reboot dialog inside gdm. The grub menu
should NOT show on the new boot.
## Open the GNOME reboot dialog, then press alt to change the "Reboot"
button into "Boot Options" and click the "Boot Options" button (while
keeping alt pressed). You should now get the grub menu, with a
countdown of 60 seconds.
## Boot the system and then press "CTRL + ALT + F6" followed by "CTRL
+ ALT + DEL" to do a reboot from the text-console without logging in,
this counts as a failed boot, so the menu should now show.
# EFI vs Classic PC BIOS boot
## All above tests should be done twice, once on an EFI system and
once on a system using Classic PC BIOS boot
== User Experience ==
The user experience will be unchanged, the goal of this change is to
remove some technical debt and reduce the number of downstream changes
Fedora carries.
== Dependencies ==
There are no dependencies outside of the grub2 and GNOME changes.
== Contingency Plan ==
* Contingency mechanism: If this is not ready / complete when we near
the beta freeze, then revert to using our downstream patches
* Blocks release? No (assuming we do the revert so we do not regress)
== Documentation ==
There are no functional changes, so no documentation changes are necessary.
--
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-leave@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
== Summary ==
GNOME integrates with Fedora's [[Changes/HiddenGrubMenu|hidden boot
menu feature]] to signal to the bootloader that boot was successful
and to request the menu to be shown the next boot when "Boot Options"
is selected in the Shutdown/Reboot dialog. Currently Fedora carries
downstream patches for this, which directly call the Fedora specific
grub2-set-bootflag helper. The goal of this change is to replace these
downstream patches with a clean bootloader agnostic solution which can
be submitted upstream.
== Owner ==
* Name: [[User:jwrdegoede| Hans de Goede]]
* Email: hdegoede@redhat.com
== Detailed Description ==
GNOME has 2 integration points with the
[[Changes/HiddenGrubMenu|hidden boot menu feature]]:
# Requesting the menu to be shown the next boot when "Boot Options" is
selected in the Shutdown/Reboot dialog.
# Signalling the bootloader that the boot was successful.
To replace our downstream patches for 1. we can use the new(ish)
systemd DBUS API used by "systemctl reboot --boot-loader-menu=60".
This currently only works with sd-boot, but systemd has hooks to allow
integration with other bootloaders, see the
[https://github.com/systemd/systemd/blob/master/docs/ENVIRONMENT.md
SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU env. variable documentation]. So we
can support this in grub2 with some relatively simply changes and then
replace our downstream patches for this with new patches using the
systemd DBUS API for this.
Replacing our downstream patches for 2. with an upstreamable
bootloader agnostic solution is somewhat involved. systemd has its
[https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ Automatic Boot
Assessment] feature, which is somewhat similar in that it to deals
with boot success detection, but its behavior on failure is different
(auto fallback to an older kernel) and it is a sd-boot specific
feature. Still we can use some parts of this. The boot-complete.target
and the concept of having a systemd-bless-boot.service which Requires
that target to be reached before it runs. So replacing out downstream
patches for 2. will consists of 2 parts:
# grub2 changes: Add a grub2-bless-boot.service which Requires
boot-complete.target and which does the equivalent of
"grub2-set-bootflag boot_success" when that target is reached
# GNOME changes: Add a oneshot gnome-wait-for-boot-success.service to
boot-complete.target, this will start a simple helper which listens on
a unix socket until signalled, thus delaying the completion of
boot-complete.target until it is signalled; and in the places where
the downstream patches are currently directly calling
"grub2-set-bootflag boot_success" signal (write a byte) this unix
socket instead.
Also see this [https://lists.freedesktop.org/archives/systemd-devel/2020-June/044800.html
mailinglist discussion].
== Benefit to Fedora ==
This change will remove some technical-debt in the form of a couple of
quick-and-dirty downstream patches from Fedora and will align GNOME's
integration with the [[Changes/HiddenGrubMenu|hidden boot menu
feature]] with our upstream first policy.
== Scope ==
* Proposal owners:
Create the necessary changes ASAP and submit these to Fedora's
[https://github.com/rhboot/grub2/ grub2] and
[https://gitlab.gnome.org/GNOME/ GNOME] upstreams.
* Other developers:
The bootloader team needs to do a new grub2 build with the changes
added and the desktop team needs to add the GNOME changes to the GNOME
packages. I will coordinate this with both teams.
* Release engineering: [https://pagure.io/releng/issue/9557 #9557] (a
check of an impact with Release Engineering is needed)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change does not impact upgrades, the interface between the OS and
grub2 still goes through the same unmodified grubenv settings. The
only changes are in how we make the grubenv changes and all parts
involved in that will be updated together.
== How To Test ==
# Tests
## Install Fedora Workstation in a fresh vm or select reclaim
diskspace -> delete all in the installer (do a single os install).
## Boot the system the grub menu should NOT show
## Login, wait 2 minutes then presss "CTRL + ALT + F6" followed by
"CTRL + ALT + DEL" to do a reboot from the text-console without going
through the GNOME reboot dialog. The grub menu should NOT show on the
new boot.
## Reboot from the GNOME reboot dialog inside gdm. The grub menu
should NOT show on the new boot.
## Open the GNOME reboot dialog, then press alt to change the "Reboot"
button into "Boot Options" and click the "Boot Options" button (while
keeping alt pressed). You should now get the grub menu, with a
countdown of 60 seconds.
## Boot the system and then press "CTRL + ALT + F6" followed by "CTRL
+ ALT + DEL" to do a reboot from the text-console without logging in,
this counts as a failed boot, so the menu should now show.
# EFI vs Classic PC BIOS boot
## All above tests should be done twice, once on an EFI system and
once on a system using Classic PC BIOS boot
== User Experience ==
The user experience will be unchanged, the goal of this change is to
remove some technical debt and reduce the number of downstream changes
Fedora carries.
== Dependencies ==
There are no dependencies outside of the grub2 and GNOME changes.
== Contingency Plan ==
* Contingency mechanism: If this is not ready / complete when we near
the beta freeze, then revert to using our downstream patches
* Blocks release? No (assuming we do the revert so we do not regress)
== Documentation ==
There are no functional changes, so no documentation changes are necessary.
--
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-leave@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
List of long term FTBFS packages to be retired in August
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 33 approximately one week before branching (August
2020).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
Note that some listed packages are orphaned and hence may be retired even sooner.
The packages in rawhide were not successfully built at least since Fedora 31.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
====================================================================
OpenCoarrays jussilehtola Fedora 30
gpscorrelate till Fedora 30
js-jquery-jqplot xavierb Fedora 30
js-jquery1 nodejs-sig, patches, vondruch Fedora 30
js-jquery2 vondruch Fedora 30
js-sizzle nodejs-sig, patches, vondruch Fedora 30
nodejs-path-type jsmith, nodejs-sig Fedora 30
nodejs-temp-write jsmith Fedora 30
nodejs-unique-stream jsmith, nodejs-sig Fedora 30
ocaml-pxp orphan Fedora 30
ocaml-ulex orphan Fedora 30
orpie bowlofeggs, jaredwallace Fedora 30
rubygem-ruby-hmac humaton, mmorsi Fedora 30
xvarstar orphan Fedora 30
The following packages require above mentioned packages:
Depending on: gpscorrelate (1)
foxtrotgps (maintained by: bubeck)
foxtrotgps-1.2.2-5.fc33.x86_64 requires gpscorrelate = 1.6.1-27.fc30
Depending on: js-jquery-jqplot (1)
sympa (maintained by: xavierb)
sympa-6.2.56-1.fc33.src requires js-jquery-jqplot = 1.0.9-3.fc30
sympa-6.2.56-1.fc33.x86_64 requires js-jquery-jqplot = 1.0.9-3.fc30
Depending on: js-jquery1 (69)
R-profvis (maintained by: qulogic)
R-profvis-0.3.6-3.fc33.src requires js-jquery1 = 1.12.4-7.fc30
R-profvis-0.3.6-3.fc33.x86_64 requires js-jquery1 = 1.12.4-7.fc30
R-rmarkdown (maintained by: qulogic)
R-rmarkdown-2.2-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30
R-rmarkdown-2.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30
copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, msuchy, praiskup)
copr-frontend-1.166-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30
ghc-pretty-show (maintained by: mathstuf)
ghc-pretty-show-1.9.5-3.fc32.x86_64 requires js-jquery1 = 1.12.4-7.fc30
mkdocs (maintained by: cheeselee)
mkdocs-1.1.2-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30
mkdocs-1.1.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30
python-XStatic-jQuery (maintained by: mrunge, openstack-sig, rdopiera)
python3-XStatic-jQuery-3.4.1.0-2.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30
python-sphinx-bootstrap-theme (maintained by: besser82, sic)
python3-sphinx-bootstrap-theme-0.8.0-3.fc33.noarch requires js-jquery1 =
1.12.4-7.fc30
rubygem-apipie-rails (maintained by: jaruga, ruby-packagers-sig, vondruch)
rubygem-apipie-rails-0.5.5-6.fc32.noarch requires js-jquery1 = 1.12.4-7.fc30
R-BiocFileCache (maintained by: spot)
R-BiocFileCache-1.12.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-DBItest (maintained by: qulogic)
R-DBItest-1.7.0-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-V8 (maintained by: qulogic)
R-V8-3.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-broom (maintained by: qulogic)
R-broom-0.5.6-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-cellranger (maintained by: qulogic)
R-cellranger-1.1.0-6.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-clipr (maintained by: qulogic)
R-clipr-0.7.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-dbplyr (maintained by: qulogic)
R-dbplyr-1.4.3-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-devtools (maintained by: qulogic)
R-devtools-2.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-diffobj (maintained by: qulogic)
R-diffobj-0.3.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-dplyr (maintained by: qulogic)
R-dplyr-0.8.5-2.fc33~bootstrap.src requires R-rmarkdown = 2.2-1.fc33
R-dtplyr (maintained by: qulogic)
R-dtplyr-1.0.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-foghorn (maintained by: qulogic)
R-foghorn-1.1.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-forcats (maintained by: qulogic)
R-forcats-0.5.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-formatR (maintained by: qulogic)
R-formatR-1.7-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-fs (maintained by: qulogic)
R-fs-1.4.1-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-gargle (maintained by: qulogic)
R-gargle-0.5.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-ggplot2 (maintained by: qulogic)
R-ggplot2-3.2.1-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-gmailr (maintained by: qulogic)
R-gmailr-1.0.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-haven (maintained by: qulogic)
R-haven-2.3.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-httr (maintained by: qulogic)
R-httr-1.4.1-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-hunspell (maintained by: qulogic)
R-hunspell-3.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-jose (maintained by: qulogic)
R-jose-1.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-jqr (maintained by: qulogic)
R-jqr-1.1.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-later (maintained by: qulogic)
R-later-1.1.0.1-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-lazyeval (maintained by: qulogic)
R-lazyeval-0.2.2-4.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-lifecycle (maintained by: qulogic)
R-lifecycle-0.2.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-lintr (maintained by: qulogic)
R-lintr-2.0.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-packrat (maintained by: qulogic)
R-packrat-0.5.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-pkgdown (maintained by: qulogic)
R-pkgdown-1.5.1-2.fc33.noarch requires R(rmarkdown) = 2.2
R-pkgdown-1.5.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-polynom (maintained by: qulogic)
R-polynom-1.4.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-prettydoc (maintained by: qulogic)
R-prettydoc-0.3.1-3.fc33.noarch requires R(rmarkdown) = 2.2
R-prettydoc-0.3.1-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-promises (maintained by: qulogic)
R-promises-1.1.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-purrr (maintained by: qulogic)
R-purrr-0.3.4-2.fc33~bootstrap.src requires R-rmarkdown = 2.2-1.fc33
R-qcc (maintained by: jjmcd)
R-qcc-2.7-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rcmdcheck (maintained by: qulogic)
R-rcmdcheck-1.3.3-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-readr (maintained by: qulogic)
R-readr-1.3.1-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-readxl (maintained by: qulogic)
R-readxl-1.3.1-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-remotes (maintained by: qulogic)
R-remotes-2.1.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-reprex (maintained by: qulogic)
R-reprex-0.3.0-5.fc33.noarch requires R(rmarkdown) = 2.2
R-reprex-0.3.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-reticulate (maintained by: qulogic)
R-reticulate-1.16-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rex (maintained by: qulogic)
R-rex-1.2.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rhub (maintained by: qulogic)
R-rhub-1.1.1-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rlang (maintained by: qulogic)
R-rlang-0.4.6-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-roxygen2 (maintained by: qulogic)
R-roxygen2-7.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rsconnect (maintained by: qulogic)
R-rsconnect-0.8.16-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rvest (maintained by: qulogic)
R-rvest-0.3.5-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-servr (maintained by: qulogic)
R-servr-0.17-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-shiny (maintained by: qulogic)
R-shiny-1.4.0.2-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-showtext (maintained by: qulogic)
R-showtext-0.8.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-sodium (maintained by: qulogic)
R-sodium-1.1-4.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-styler (maintained by: qulogic)
R-styler-1.3.2-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-svglite (maintained by: qulogic)
R-svglite-1.2.3-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-systemfonts (maintained by: qulogic)
R-systemfonts-0.2.2-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-tibble (maintained by: qulogic)
R-tibble-3.0.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-tidyr (maintained by: qulogic)
R-tidyr-1.1.0-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-tidyselect (maintained by: qulogic)
R-tidyselect-1.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-tufte (maintained by: qulogic)
R-tufte-0.6-2.fc33.noarch requires R(rmarkdown) = 2.2
R-tufte-0.6-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-unitizer (maintained by: qulogic)
R-unitizer-1.4.10-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-usethis (maintained by: qulogic)
R-usethis-1.5.1-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-websocket (maintained by: qulogic)
R-websocket-1.1.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-zeallot (maintained by: qulogic)
R-zeallot-0.1.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
Too many dependencies for js-jquery1, not all listed here
Depending on: nodejs-path-type (1)
nodejs-read-pkg (maintained by: jsmith, nodejs-sig)
nodejs-read-pkg-2.0.0-7.fc32.noarch requires npm(path-type) = 2.0.0
Affected (co)maintainers (directly and indirectly):
besser82: js-jquery1
bowlofeggs: orpie
bubeck: gpscorrelate
cheeselee: js-jquery1
clime: js-jquery1
copr-sig: js-jquery1
dturecek: js-jquery1
frostyx: js-jquery1
humaton: rubygem-ruby-hmac
jaredwallace: orpie
jaruga: js-jquery1
jjmcd: js-jquery1
jsmith: nodejs-temp-write, nodejs-path-type, nodejs-unique-stream
jussilehtola: OpenCoarrays
mathstuf: js-jquery1
mmorsi: rubygem-ruby-hmac
mrunge: js-jquery1
msuchy: js-jquery1
nodejs-sig: js-sizzle, js-jquery1, nodejs-path-type, nodejs-unique-stream
openstack-sig: js-jquery1
patches: js-sizzle, js-jquery1
praiskup: js-jquery1
qulogic: js-jquery1
rdopiera: js-jquery1
ruby-packagers-sig: js-jquery1
sic: js-jquery1
spot: js-jquery1
till: gpscorrelate
vondruch: js-sizzle, js-jquery1, js-jquery2
xavierb: js-jquery-jqplot
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 33 approximately one week before branching (August
2020).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
Note that some listed packages are orphaned and hence may be retired even sooner.
The packages in rawhide were not successfully built at least since Fedora 31.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
====================================================================
OpenCoarrays jussilehtola Fedora 30
gpscorrelate till Fedora 30
js-jquery-jqplot xavierb Fedora 30
js-jquery1 nodejs-sig, patches, vondruch Fedora 30
js-jquery2 vondruch Fedora 30
js-sizzle nodejs-sig, patches, vondruch Fedora 30
nodejs-path-type jsmith, nodejs-sig Fedora 30
nodejs-temp-write jsmith Fedora 30
nodejs-unique-stream jsmith, nodejs-sig Fedora 30
ocaml-pxp orphan Fedora 30
ocaml-ulex orphan Fedora 30
orpie bowlofeggs, jaredwallace Fedora 30
rubygem-ruby-hmac humaton, mmorsi Fedora 30
xvarstar orphan Fedora 30
The following packages require above mentioned packages:
Depending on: gpscorrelate (1)
foxtrotgps (maintained by: bubeck)
foxtrotgps-1.2.2-5.fc33.x86_64 requires gpscorrelate = 1.6.1-27.fc30
Depending on: js-jquery-jqplot (1)
sympa (maintained by: xavierb)
sympa-6.2.56-1.fc33.src requires js-jquery-jqplot = 1.0.9-3.fc30
sympa-6.2.56-1.fc33.x86_64 requires js-jquery-jqplot = 1.0.9-3.fc30
Depending on: js-jquery1 (69)
R-profvis (maintained by: qulogic)
R-profvis-0.3.6-3.fc33.src requires js-jquery1 = 1.12.4-7.fc30
R-profvis-0.3.6-3.fc33.x86_64 requires js-jquery1 = 1.12.4-7.fc30
R-rmarkdown (maintained by: qulogic)
R-rmarkdown-2.2-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30
R-rmarkdown-2.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30
copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, msuchy, praiskup)
copr-frontend-1.166-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30
ghc-pretty-show (maintained by: mathstuf)
ghc-pretty-show-1.9.5-3.fc32.x86_64 requires js-jquery1 = 1.12.4-7.fc30
mkdocs (maintained by: cheeselee)
mkdocs-1.1.2-1.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30
mkdocs-1.1.2-1.fc33.src requires js-jquery1 = 1.12.4-7.fc30
python-XStatic-jQuery (maintained by: mrunge, openstack-sig, rdopiera)
python3-XStatic-jQuery-3.4.1.0-2.fc33.noarch requires js-jquery1 = 1.12.4-7.fc30
python-sphinx-bootstrap-theme (maintained by: besser82, sic)
python3-sphinx-bootstrap-theme-0.8.0-3.fc33.noarch requires js-jquery1 =
1.12.4-7.fc30
rubygem-apipie-rails (maintained by: jaruga, ruby-packagers-sig, vondruch)
rubygem-apipie-rails-0.5.5-6.fc32.noarch requires js-jquery1 = 1.12.4-7.fc30
R-BiocFileCache (maintained by: spot)
R-BiocFileCache-1.12.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-DBItest (maintained by: qulogic)
R-DBItest-1.7.0-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-V8 (maintained by: qulogic)
R-V8-3.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-broom (maintained by: qulogic)
R-broom-0.5.6-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-cellranger (maintained by: qulogic)
R-cellranger-1.1.0-6.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-clipr (maintained by: qulogic)
R-clipr-0.7.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-dbplyr (maintained by: qulogic)
R-dbplyr-1.4.3-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-devtools (maintained by: qulogic)
R-devtools-2.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-diffobj (maintained by: qulogic)
R-diffobj-0.3.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-dplyr (maintained by: qulogic)
R-dplyr-0.8.5-2.fc33~bootstrap.src requires R-rmarkdown = 2.2-1.fc33
R-dtplyr (maintained by: qulogic)
R-dtplyr-1.0.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-foghorn (maintained by: qulogic)
R-foghorn-1.1.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-forcats (maintained by: qulogic)
R-forcats-0.5.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-formatR (maintained by: qulogic)
R-formatR-1.7-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-fs (maintained by: qulogic)
R-fs-1.4.1-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-gargle (maintained by: qulogic)
R-gargle-0.5.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-ggplot2 (maintained by: qulogic)
R-ggplot2-3.2.1-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-gmailr (maintained by: qulogic)
R-gmailr-1.0.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-haven (maintained by: qulogic)
R-haven-2.3.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-httr (maintained by: qulogic)
R-httr-1.4.1-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-hunspell (maintained by: qulogic)
R-hunspell-3.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-jose (maintained by: qulogic)
R-jose-1.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-jqr (maintained by: qulogic)
R-jqr-1.1.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-later (maintained by: qulogic)
R-later-1.1.0.1-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-lazyeval (maintained by: qulogic)
R-lazyeval-0.2.2-4.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-lifecycle (maintained by: qulogic)
R-lifecycle-0.2.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-lintr (maintained by: qulogic)
R-lintr-2.0.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-packrat (maintained by: qulogic)
R-packrat-0.5.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-pkgdown (maintained by: qulogic)
R-pkgdown-1.5.1-2.fc33.noarch requires R(rmarkdown) = 2.2
R-pkgdown-1.5.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-polynom (maintained by: qulogic)
R-polynom-1.4.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-prettydoc (maintained by: qulogic)
R-prettydoc-0.3.1-3.fc33.noarch requires R(rmarkdown) = 2.2
R-prettydoc-0.3.1-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-promises (maintained by: qulogic)
R-promises-1.1.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-purrr (maintained by: qulogic)
R-purrr-0.3.4-2.fc33~bootstrap.src requires R-rmarkdown = 2.2-1.fc33
R-qcc (maintained by: jjmcd)
R-qcc-2.7-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rcmdcheck (maintained by: qulogic)
R-rcmdcheck-1.3.3-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-readr (maintained by: qulogic)
R-readr-1.3.1-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-readxl (maintained by: qulogic)
R-readxl-1.3.1-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-remotes (maintained by: qulogic)
R-remotes-2.1.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-reprex (maintained by: qulogic)
R-reprex-0.3.0-5.fc33.noarch requires R(rmarkdown) = 2.2
R-reprex-0.3.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-reticulate (maintained by: qulogic)
R-reticulate-1.16-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rex (maintained by: qulogic)
R-rex-1.2.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rhub (maintained by: qulogic)
R-rhub-1.1.1-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rlang (maintained by: qulogic)
R-rlang-0.4.6-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-roxygen2 (maintained by: qulogic)
R-roxygen2-7.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rsconnect (maintained by: qulogic)
R-rsconnect-0.8.16-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-rvest (maintained by: qulogic)
R-rvest-0.3.5-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-servr (maintained by: qulogic)
R-servr-0.17-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-shiny (maintained by: qulogic)
R-shiny-1.4.0.2-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-showtext (maintained by: qulogic)
R-showtext-0.8.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-sodium (maintained by: qulogic)
R-sodium-1.1-4.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-styler (maintained by: qulogic)
R-styler-1.3.2-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-svglite (maintained by: qulogic)
R-svglite-1.2.3-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-systemfonts (maintained by: qulogic)
R-systemfonts-0.2.2-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-tibble (maintained by: qulogic)
R-tibble-3.0.1-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-tidyr (maintained by: qulogic)
R-tidyr-1.1.0-1.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-tidyselect (maintained by: qulogic)
R-tidyselect-1.1.0-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-tufte (maintained by: qulogic)
R-tufte-0.6-2.fc33.noarch requires R(rmarkdown) = 2.2
R-tufte-0.6-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-unitizer (maintained by: qulogic)
R-unitizer-1.4.10-2.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-usethis (maintained by: qulogic)
R-usethis-1.5.1-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-websocket (maintained by: qulogic)
R-websocket-1.1.0-3.fc33.src requires R-rmarkdown = 2.2-1.fc33
R-zeallot (maintained by: qulogic)
R-zeallot-0.1.0-5.fc33.src requires R-rmarkdown = 2.2-1.fc33
Too many dependencies for js-jquery1, not all listed here
Depending on: nodejs-path-type (1)
nodejs-read-pkg (maintained by: jsmith, nodejs-sig)
nodejs-read-pkg-2.0.0-7.fc32.noarch requires npm(path-type) = 2.0.0
Affected (co)maintainers (directly and indirectly):
besser82: js-jquery1
bowlofeggs: orpie
bubeck: gpscorrelate
cheeselee: js-jquery1
clime: js-jquery1
copr-sig: js-jquery1
dturecek: js-jquery1
frostyx: js-jquery1
humaton: rubygem-ruby-hmac
jaredwallace: orpie
jaruga: js-jquery1
jjmcd: js-jquery1
jsmith: nodejs-temp-write, nodejs-path-type, nodejs-unique-stream
jussilehtola: OpenCoarrays
mathstuf: js-jquery1
mmorsi: rubygem-ruby-hmac
mrunge: js-jquery1
msuchy: js-jquery1
nodejs-sig: js-sizzle, js-jquery1, nodejs-path-type, nodejs-unique-stream
openstack-sig: js-jquery1
patches: js-sizzle, js-jquery1
praiskup: js-jquery1
qulogic: js-jquery1
rdopiera: js-jquery1
ruby-packagers-sig: js-jquery1
sic: js-jquery1
spot: js-jquery1
till: gpscorrelate
vondruch: js-sizzle, js-jquery1, js-jquery2
xavierb: js-jquery-jqplot
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
[USN-4406-1] Mailman vulnerability
==========================================================================
Ubuntu Security Notice USN-4406-1
June 29, 2020
mailman vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 18.04 LTS
- Ubuntu 16.04 LTS
Summary:
Mailman could be made to inject arbitrary content in the login page if it
received a specially crafted input.
Software Description:
- mailman: Web-based mailing list manager (legacy branch)
Details:
It was discovered that Mailman incorrectly handled certain inputs.
An attacker could possibly use this issue to inject arbitrary content
in the login page.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 18.04 LTS:
mailman 1:2.1.26-1ubuntu0.3
Ubuntu 16.04 LTS:
mailman 1:2.1.20-1ubuntu0.6
In general, a standard system update will make all the necessary changes.
References:
https://usn.ubuntu.com/4406-1
CVE-2020-15011
Package Information:
https://launchpad.net/ubuntu/+source/mailman/1:2.1.26-1ubuntu0.3
https://launchpad.net/ubuntu/+source/mailman/1:2.1.20-1ubuntu0.6
Ubuntu Security Notice USN-4406-1
June 29, 2020
mailman vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 18.04 LTS
- Ubuntu 16.04 LTS
Summary:
Mailman could be made to inject arbitrary content in the login page if it
received a specially crafted input.
Software Description:
- mailman: Web-based mailing list manager (legacy branch)
Details:
It was discovered that Mailman incorrectly handled certain inputs.
An attacker could possibly use this issue to inject arbitrary content
in the login page.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 18.04 LTS:
mailman 1:2.1.26-1ubuntu0.3
Ubuntu 16.04 LTS:
mailman 1:2.1.20-1ubuntu0.6
In general, a standard system update will make all the necessary changes.
References:
https://usn.ubuntu.com/4406-1
CVE-2020-15011
Package Information:
https://launchpad.net/ubuntu/+source/mailman/1:2.1.26-1ubuntu0.3
https://launchpad.net/ubuntu/+source/mailman/1:2.1.20-1ubuntu0.6
Subscribe to:
Posts (Atom)