devel-announce January 2020

devel-announce@lists.fedoraproject.org

8 participants
39 discussions

Fedora 33 System-Wide Change proposal: binutils 2.34
by Ben Cotton 03 Jan '20

03 Jan '20

https://fedoraproject.org/wiki/Changes/BINUTILS234 == Summary == Rebase the binutils package from version 2.33 to version 2.34. == Owner == * Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc] * Email: nickc(a)redhat.com == Detailed Description == Switch the binutils package from being based on the 2.33 release of the GNU binutils to being based on the 2.34 release. This release will bring in numerous bug fixes, as well as coloured ascii art annotation for the disassembler output! == Benefit to Fedora == The main benefit will be the bug fixes and the improvement to the linker and assembler. In addition users who look at disassemblies will find the new ascii art output quite helpful. == Scope == * Proposal owners: Change the source parameter in the binutils.spec rpm and adjust the local patches to take account of the bugs that are now already fixed. This is a significant change to the underlying tools used to build Fedora and so there should be a mass rebuild in order for the changes to be noticed across the system. * Other developers: No other work should be necessary. Once the rebase is in place and the buildroot contains the new binutils its use should be automatic. * Release engineering: [https://pagure.io/releng/issues/9111] A mass rebuild will be required. * Policies and guidelines: No documents need to be updated. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The binutils are backwards compatible with previous releases, so no changes should be necessary. == How To Test == The binutils package does include its own set of testsuites which check basic functionality. The real test however is by rebuilding other packages which depend upon the binutils, or more likely, upon gcc. If these packages continue to work then the binutils update has not broken anything. == User Experience == The change should not be noticeable to the user. == Dependencies == This update has no hard dependencies on any other package. There are other packages that do depend upon the binutils however. Most notably gcc and redhat-rpm-config. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Revert to the 2.33 binutils as currently used in rawhide. This work can be done by me, should it prove necessary. * Contingency deadline: Beta freeze. * Blocks release? No * Blocks product? None == Documentation == Documentation is not currently available, due to the fact that the 2.34 release has not yet been created. (It is hoped that the release will happen before the Fedora 33 mass rebuild). -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 32 Self-Contained Change proposal: Mono 6.6
by Ben Cotton 03 Jan '20

03 Jan '20

https://fedoraproject.org/wiki/Changes/Mono_6_6 == Summary == Update the Mono stack in Fedora from 5.20 to 6.6. We need to do again a bootstrap build. == Owner == * Name: [[User:tpokorra|Timotheus Pokorra]] * Email: tpokorra(a)fedoraproject.org == Detailed Description == Even between minor releases, we need to build Mono by doing a bootstrap. I have successfully built Mono 6.6 without bootstrap, once I have Mono 6.6 installed which was built with bootstrapping enabled. I would like to request permission to make a one time exception of the rule for building mono 6.6.0-1 using monolite and the reference assemblies, later make mono depend again on itself and rebuild mono 6.6.0-2 using mono-6.6.0-1. Steps for bootstrapping: * The Monolite binaries are included in the Mono tarball which is provided by upstream. See also http://www.mono-project.com/docs/advanced/monolite/ ** Monolite is a minimal binary distribution of mcs. This is the compiler that is able to build the rest of Mono. * The binary reference assemblies are included in the Mono tarball which is provided by upstream. The tarball also includes the sources of the reference assemblies, which are maintained here: https://github.com/dotnet/source-build * In the spec file, we usually delete all dlls and executables before the build section. * For the bootstrap, we would once keep the monolite binaries and some binary reference assemblies. * In the bootstrap, we rebuild the reference assemblies and include them in the mono-devel package, as well as the mono compiler. * After Mono has been built for all primary and secondary architectures, we enable the deletion of the binaries again in the spec file. == Benefit to Fedora == Fedora aims to showcase the latest in free and open source software - we should have the most recent release of Mono 6.x == Scope == * Proposal owners: Update mono spec and build in koji until it is ready. Members of the Mono SIG can rebuild their packages with Mono 6.6. Rebuild of all packages depending on Mono can happen during the regular mass rebuild. * Other developers: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Dependencies == This is not a system wide change, but only affects packages depending on Mono, and should be managed by the members of the [[SIGs/Mono|Mono SIG]]. == Documentation == * https://fedoraproject.org/wiki/Packaging:Mono * https://github.com/mono/mono * https://copr.fedorainfracloud.org/coprs/tpokorra/mono-6.6/ * https://github.com/tpokorra/mono-6.x-fedora/tree/master/mono-6.6 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
by Ben Cotton 03 Jan '20

03 Jan '20

https://fedoraproject.org/wiki/Changes/EnableEarlyoom == Summary == Install earlyoom package, and enable it by default. This will cause the kernel oomkiller to trigger sooner, but will not affect which process it chooses to kill off. 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:chrismurphy| Chris Murphy]] * Email: bugzilla(a)colorremedies.com == Detailed Description == Workstation working group has discussed "better interactivity in low-memory situations" for some months. In certain use cases, typically compiling, if all RAM and swap are completely consumed, system responsiveness becomes so abysmal that a reasonable user can consider the system "lost", and resorts to forcing a power off. This is objective a very bad UX. The broad discussion of this problem, and some ideas for near term and long term solutions, is located here: Recent long discussions on "Better interactivity in low-memory situations" https://pagure.io/fedora-workstation/issue/98 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Fedora editions and spins, have the in-kernel OOM (out-of-memory) manager enabled. The manager's concern is keeping the kernel itself functioning. It has no concern about user space function or interactivity. This proposed change attempts to improve the user experience, in the short term, by triggering the in-kernel process killing mechanism, sooner. Instead of the system becoming completely unresponsive for tens of minutes, hours or days, the expectation is an offending process (determined by oom_score, same as now) will be killed off within seconds or a few minutes. This is an incremental improvement in user experience, but admittedly still suboptimal. There is additional work on-going to improve the user experience further. Workstation working group discussion specific to enabling earlyoom by default https://pagure.io/fedora-workstation/issue/119 Other in-progress solutions: https://gitlab.freedesktop.org/hadess/low-memory-monitor Background information on this complicated problem: https://www.kernel.org/doc/gorman/html/understand/understand016.html https://lwn.net/Articles/317814/ == Benefit to Fedora == There are two major benefits to Fedora: * 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 == Scope == * Proposal owners: a. Modify {{code|https://pagure.io/fedora-comps/blob/master/f/comps-f32.xml.in}} to include earlyoom package for Workstation. b. Modify {{code|https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-workstation.preset}} to include: <pre> # enable earlyoom by default on workstation enable earlyoom.service </pre> * Other developers: Restricted to Workstation edition, unless other editions/spins want to opt-in. * Release engineering: [https://pagure.io/releng/issues #9141] (a check of an impact with Release Engineering is needed)  * 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 clean installed system. == How To Test == * Fedora 30/31 users can test today, any edition or spin: {{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}} {{code|https://lkml.org/lkml/2019/8/4/15}} * Fedora Workstation 32 (and Rawhide) users will see this service is already enabled. It can be toggled with {{code|sudo systemctl start/stop earlyoom}} where start means earlyoom is running, and stop means earlyoom is not running. == User Experience == The most egregious instances this change is trying to mitigate: a. RAM is completely used b. Swap is completely used c. System becomes unresponsive to the user as swap thrashing has ensued --> earlyoom disabled, the user often gives up and forces power off (in my own testing this condition lasts >30 minutes with no kernel triggered oom killer and no recovery) --> earlyoom enabled, the system likely still becomes unresponsive but oom killer is triggered in much less time (seconds or a few minutes, in my testing, after less than 10% RAM and 10% swap is remaining) earlyoom starts sending SIGTERM once both memory and swap are below their respective PERCENT setting, default 10%. It sends SIGKILL once both are below their respective KILL_PERCENT setting, default 5%. The package includes configuration file /etc/default/earlyoom which sets option {{code|-r 60}} causing a memory report to be entered into the journal every minute. == Dependencies == earlyoom package has no dependencies == Contingency Plan == * Contingency mechanism: Owner will revert all changes * Contingency deadline: Final freeze * Blocks release? No * Blocks product? No == Documentation == {{code|man earlyoom}} https://www.kernel.org/doc/gorman/html/understand/understand016.html == Release Notes == Earlyoom service is enabled by default, which will cause kernel oom-killer to trigger sooner. To revert to previous behavior: {{code|sudo systemctl disable earlyoom.service}} And to customize see {{code|man earlyoom}}. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 32 System-Wide Change proposal: Adopting sysusers.d format
by Ben Cotton 02 Jan '20

02 Jan '20

https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format == Summary == Files in sysusers.d format will be used to declare systems users so it will be possible to introspect system users. Users will still be created using old-style useradd calls. == Owner == * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: zbyszek at in waw pl == Detailed Description == Many packages define their own user. Right now, those users are created in %pre by calling getent, useradd, and groupadd ([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_… guidelines]). This will be changed to define users in the [https://www.freedesktop.org/software/systemd/man/sysusers.d.html sysusers.d format]. A macro will be provided to generate a %pre scriptlet that will call useradd and groupadd similarly to the scriptlets that are currently required by the packaging guidelines. In this proposal, systemd-sysusers will not be used to create the user. Using the sysusers.d format makes it easy to switch to systemd-sysusers as the implementation, and to experiment with different way to actually create the users based on the declarative syntax. This approach is heavily based on OpenSUSE's ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups guidelines]), but does not use separate rpm packages. I think using a %pre macro is good enough. == Benefit to Fedora == System users are declared by packages using a uniform syntax. The scriptlet part is standardized. Current implementation of creating users and groups is not changed, but may be switched easily in the future. For example, for container images, the macro may be replaced by a noop implementation, and the users created externally without installing the user creation tools in the container. Admins may easily introspect the system user list and which packages require users. Admins may easily override definitions of system users by providing appropriate sysusers.d files with higher priority. The difference between Fedora and other distros like OpenSUSE is reduced. == Scope == * Proposal owners: ** provide the macro and any helper tools ** submit a proposal to FPC ** convert a subset of packages * Other developers: ** FPC: review (and accept ;)) the guidelines changes ** other maintainers: convert other packages * Release engineering: n/a * Policies and guidelines: a pull request will be submitted * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == None. This change should be backwards and forwards compatible, i.e. unconverted packages can be still installed on new systems, and converted packages can be installed on older systems. == How To Test == This change should be mostly invisible to users. During installation, users should be created as appropriate before packages are installed. For packages that carry files owned by the user, check that the files are created with appropriate ownership by rpm. == User Experience == <code>systemd-analyze cat-config sysusers.d/</code> shows the definitions of system users (incl. local overrides). == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert to previous mechanism. This will require a revert of changes to the spec file and a rebuild of the package. * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No == Documentation == TBD. == Release Notes == Not needed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 32 System-Wide Change proposal: Move fonts language Provides to Langpacks
by Ben Cotton 02 Jan '20

02 Jan '20

https://fedoraproject.org/wiki/Changes/FontLanguageProvidesToLangpacks == Summary == Move `Provides: font(:lang=...)` from fonts packages into the `langpacks` package, giving predictable default fonts for language scripts. === Motivation === Currently fonts packages has auto-generated `font(:lang=...)` provides, which can be used as a dependency identifier to satisfy font coverage required for a certain language requirement. This is used by GTK application to install missing fonts via PackageKit for example. However in practice it has not been very useful since usually there are assorted multiple fonts that provide the language coverage and so an arbitrary fonts of unknown quality would get selected, so the mechanism is not unreliable. This change uses instead the default fonts chosen in `langpacks` for each language, to give reliable predictable default fonts for each language and improve the user application experience around fonts. == Owner == * Name: [[User:Tagoh| Akira TAGOH]], [[User:Pnemade| Parag Nemade]] * Email: tagoh(a)redhat.com, pnemade(a)redhat.com == Detailed Description == The language based metadata for fonts packages was introduced in Fedora 11. The idea being to provide a mechanism to find and install a font for missing glyphs through PackageKit and was useful for minority languages which might be missing default installed fonts packages. But the user experience was generally not terribly good. Users cannot predict which fonts will be installed. This often leads to poor fonts choices installed, particularly for languages with too many available fonts such as English, since the first font found lexically will be arbitrarily chosen with gurantee of quality or expected style. This random dependency resolution sometimes introduces highly unexpected results too - for example a font from an external repository may get chosen by chance. This would be particularly problematic when composing ISOs, eg when including EPEL. So this Changes proposal aims to improve the user experience around font dependencies by moving the meta-provides the `langpacks` package instead. Langpacks contains various dependencies to use for certain languages, including dependencies for default fonts. so it will resolve the above issues. Specifically speaking, currently font provides are generated like this: <pre> $ fc-query -f %{=pkgkit} /usr/share/fonts/dejavu/DejaVuSans.ttf font(dejavusans) font(:lang=aa) font(:lang=ab) ... </pre> and at the build time, it is transformed to: <pre> Provides: font(dejavusans) Provides: font(:lang=aa) Provides: font(:lang=ab) ... </pre> After this proposal, the above result will be: <pre> Provides: font(dejavusans) </pre> and then add `Provides: font(:lang=...)` line to corresponding sub-packages langpacks-core-*. So asking for a font for a certain language through PackageKit will be achieved by langpacks-core-* instead of a random font package. == Benefit to Fedora == This proposal will provide reliable, predictable, and consistent font dependencies. == Scope == * Proposal owners: ** Update fontconfig to drop `font(:lang=...)` from the alias of the formatter for `%{=pkgkit}` ** Add a line of `Provides: font(:lang=...)` to each `langpacks-core-...`. For instance, `Provides: font(:lang=hi)` needs to be added to `langpacks-core-hi`. * Other developers: Release Engineers needs to rebuild all fonts packages with the updated fontconfig package. * Release engineering: [https://pagure.io/releng/issue/9132 #9132] * Policies and guidelines: None * Trademark approval: None == Upgrade/compatibility impact == Some packages may be installed after upgrading if corresponding langpacks-core-* packages isn't yet installed. == How To Test == # Check that langpacks-core-* provide corresponding `font(:lang=...)` using `rpm -q --provides`. # Check that fonts packages no longer provide `font(:lang=...)`. # Check that langpacks-core-* pulls in the default expected font for the language. == User Experience == Users should see better fonts chosen for languages when they install a font to cover a certain language script through PackageKit or through font meta dependencies of other packages. == Dependencies == All fonts packages == Contingency Plan == * Contingency mechanism: proposal owners will revert all the changes and rebuild all fonts packages to add back the provides. * Contingency deadline: the beta freeze * Blocks release? No * Blocks product? N/A == Documentation == N/A -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 32 System-Wide Change proposal: GCC10
by Ben Cotton 02 Jan '20

02 Jan '20

https://fedoraproject.org/wiki/Changes/GCC10 == Summary == Switch GCC in Fedora 32 to 10.x.y, rebuild all packages with it, or optionally rebuild just some packages with it and rebuild all packages only in Fedora 33. == Owner == * Name: [[User:Jakub|Jakub Jelínek]] * Email: jakub(a)redhat.com == Detailed Description == GCC 10 is currently in stage3, switching to stage4 in January, at which point it will be in a prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. rpms will be built in early January, but Jeff Law has been testing x86_64 Fedora test mass rebuilds with GCC 10 snapshots for a while. == Benefit to Fedora == See http://gcc.gnu.org/gcc-10/changes.html for the list of changes. == Scope == * Proposal owners: Prepare rpms for the new compiler, push them into rawhide, watch voluntary rebuilds, fix bugs as they are reported, watch fallout from mass rebuild. * Other developers: N/A (not a System Wide Change) Adjust for what will be written in https://gcc.gnu.org/gcc-10/porting_to.html , fix bugs in packages that will show up after rebuild or report if there are bugs on the compiler side. * Release engineering: Perform a mass rebuild, which will be needed for the LTO System Wide change too. * Policies and guidelines: N/A (not a System Wide Change) I don't think so, this is a usual system compiler update that is being done every year. I think we have skipped GCC 4.2, so in Fedora this is likely the 15th such System Wide change. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No impact == How To Test == GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc. == User Experience == Users will be able to see compiled code improvements and use the newly added features. Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-10/porting_to.html, or, if they detect a GCC bug, report it. == Dependencies == libtool, annobin, gcc-python-plugin depend on exact gcc version, those need to be rebuilt. == Contingency Plan == If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in 12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past, but worst case we can mass rebuild everything with older gcc again. Jeff Law has performed test mass rebuild on x86_64. * Contingency mechanism: (What to do? Who will do it?) Revert to older gcc, mass rebuild everything again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No == Documentation == http://gcc.gnu.org/gcc-10/ == Release Notes == Fedora 32 comes with GCC 10.1 as primary compiler, see http://gcc.gnu.org/gcc-10/changes.html for user visible changes in it. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 32 System-Wide Change proposal: Golang 1.14
by Ben Cotton 02 Jan '20

02 Jan '20

https://fedoraproject.org/wiki/Changes/golang1.14 == Summary == Rebase of Golang package to upcoming version 1.14 in Fedora 32, including rebuild of all dependent packages(pre-release version of Go will be used for rebuild, if released version will not be available at the time of the mass rebuild). == Owner == * Name: [[User:Jcajka| Jakub Čajka]] * Email: jcajka(a)redhat.com == Detailed Description == Rebase of Golang package to upcoming version 1.14 in Fedora 32. Golang 1.14 is schedule to be released in Feb 2020. Due to current nature and state of Go packages, rebuild of dependent package will be required to pick up the changes. == Benefit to Fedora == Staying closely behind upstream by providing latest release of golang, which includes performance improvements and improvements in support for currently supported platforms among other bug fixes and new features. For complete list of changes see upstream change notes at https://tip.golang.org/doc/go1.14 . In result Fedora will be providing solid development platform for Go language. == Scope == * Proposal owners: Rebase golang package in f32, help with resolving possible issues found during package rebuilds. * Other developers: Fix possible issues, with help from golang maintainers. * Release engineering: Rebuild of dependent packages as part of planned mass-rebuild. Tracking ticket https://pagure.io/releng/issue/9136 * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == None == How To Test == ;0. :a)Install golang 1.14 from rawhide and use it to build your application(s)/package(s). :b)Scratch build against rawhide. ;1. :Your application/package built using golang 1.14 should work as expected. == User Experience == None == Dependencies == <pre> dnf repoquery -q --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'golang' dnf repoquery -q --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'compiler(go-compiler)' dnf repoquery -q --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'compiler(golang)' dnf repoquery -q --releasever=rawhide --disablerepo='*' --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source --enablerepo=updates-testing-source --archlist=src --whatrequires 'go-rpm-macros' </pre> <pre> Omitted due to the number of packages listed ~1100. </pre> Not all of listed require re-build as they might not ship binaries and/or do not use golang compiler during build, but only use Go rpm macros that pull it in to every build root. == Contingency Plan == * Contingency mechanism:Reverting to golang version 1.13.X if significatnt issues are discovered. * Contingency deadline: Beta Freeze(?) * Blocks release? No * Blocks product? No == Documentation == https://tip.golang.org/doc/go1.14 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction
by Ben Cotton 02 Jan '20

02 Jan '20

https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_trans… == Summary == Scriptlets to restart each service that should be restarted in each rpm package will be replaced by a declaration in the unit file and an rpm transaction trigger that fires at the end and restarts all services. == Owner == * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: zbyszek at in waw pl == Detailed Description == Currently, when packages containing systemd services are upgraded, they are restarted through %post scriptlets in each package. In other words, the scriptlets specify which services should be restarted and actually run the command to restart the service. An alternative mechanism will be provided, whereby the unit file contains a setting which specifies that the service should be restarted on upgrade, and a %transfiletrigger in the systemd package will restart all services marked so in upgraded packages at the end of transaction. To mark a services as "restart on upgrade" the unit file should contain an option to mark it so. This can be either in the main .service file, or e.g. in a drop-in file in <code>/usr/lib/systemd/system/<service>.service.d/needs-restart.conf</code>. The exact name of the option should be something like <code>X-restart-on-upgrade=true|false</code>. I'll take the proposal for discussion in systemd upstream, since this is something that could be used across distributions, and then the "X-" prefix could be dropped and/or the name changed. == Benefit to Fedora == Which services should be restarted is specified declaratively and the number of scriptlets is reduced. Admins may easily override this by providing appropriate drop-ins of their own of higher priority. Services are restarted after the transaction is finished, all libraries have been upgraded, and systemd configuration reloaded. This solves https://bugzilla.redhat.com/show_bug.cgi?id=1614751, but also a more general problem: a service may be restarted before any of its dependencies (files and static content and whatnot) have been upgraded, and while some contents from the old rpm are still on disk. Restarting after all packages have been upgraded avoids this issue. In the future, restarting of services shall also be extended to user managers (i.e. to restart all user services after the packages providing those services have been upgraded). This is not part of this proposal, but moving the information what to restart into systemd units makes this much easier. == Scope == * Proposal owners: ** implement the relevant bits in the systemd package ** submit a proposal to FPC ** convert a subset of packages * Other developers: ** FPC: review (and accept ;)) the guidelines changes ** other maintainers: convert other packages * Release engineering: n/a * Policies and guidelines: a pull request will be submitted * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This change should be backwards compatible, i.e. unconverted packages can be still installed on new systems, and services will be restarted on upgrade like before. Converted packages may be installed on older systems but will not get restarted on upgrades. == How To Test == This change should be mostly invisible to users. Check that during upgrades services are restarted and that no warnings are emitted. == User Experience == N/A == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert to previous mechanism. This will require a revert of changes to the spec file and a rebuild of the package. * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No == Documentation == TBD. == Release Notes == Not needed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora 32 System-Wide Change proposal: Systemd presets for user units
by Ben Cotton 02 Jan '20

02 Jan '20

https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units == Summary == System units are managed through presets [https://fedoraproject.org/wiki/Features/PackagePresets since F18] and by policy, presets are carried by the fedora-release package. This policy is now extended to user units. == Owner == * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: zbyszek at in waw pl == Detailed Description == The preset mechanism for user units was already in place, but we were missing the actual preset files, and the default was "enable *" instead of "disable *" as for system services. Systemd will now provide a /usr/lib/systemd/user-preset/99-default-disable.preset that marks user services as disabled by default. Any user services which should be enabled will be to get an appropriate preset in /usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific file. Most packages already call into the preset mechanism, but those which don't will be adjusted to do that. This is essentially a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good reason to treat user services different than system services in this regard. On the systemd side this change is very simple, but all packages that provide user units need to be reviewed to check if they are enabled after the change if appropriate. == Benefit to Fedora == User and system services are handled in the same way. Local configuration may be used to override which services should be enabled after upgrade. In particular, "local" in this context may mean "per-spin" or "per-user". == Scope == * Proposal owners: ** review all packages that provide user services in Fedora and submit PRs when changes are needed ** add a new presets file to the fedora-release package for user units ** submit a proposal to FPC to update the guidelines (essentially to say "... and the same for user services."). * Other developers: ** FPC: review (and accept ;)) the guidelines changes ** other maintainers: verify that units in their packages are enabled or not as appropriate after package installation * Release engineering: n/a * Policies and guidelines: a pull request will be submitted * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Should not be user visible. Some units which are are currently enabled by mistake will not be enabled anymore on new installations. == How To Test == Install a new system (or uninstall and reinstall some packages). Verify that the appropriate units are enabled for the user session. == User Experience == N/A == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert the changes. * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No == Documentation == A pull request for the packaging guidelines will be submitted. == Release Notes == Not needed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce January 2020