devel January 2022

devel@lists.fedoraproject.org

269 participants
383 discussions

mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?
by Robert-André Mauchin 12 Feb '22

12 Feb '22

Hi, So I have an annoying bug that started near the beginnings of F35. My papirus-icon-theme became very slow to install: https://bugzilla.redhat.com/show_bug.cgi?id=2029709#c18 During the installation, all the files are copied, then renamed by rpm (no idea why it works like this). It works fast in a Mock chroot but incredibly slow on bare metal. I've done a small test of moving files: [root@cassini icons]# mkdir test [root@cassini icons]# for (( i = 0; i < 10000; i++ )) do > test/file_$i; done [root@cassini icons]# cd test On host: time $(for f in *; do mv "$f" "${f%}.txt"; done) real 2m3,500s user 0m3,966s sys 2m0,431s In nspawn container: <mock-chroot> sh-5.1# time $(for f in *; do mv "$f" "${f%}.txt"; done) real 0m6.702s user 0m4.237s sys 0m3.344s Since papirus-icon-theme contains more than 100,000 (small) files, it is a problem. One minute of waiting is ok, 20 mn is not. What can cause this? I read that nspawn virtualizes the file system, could it be file system related on the host? (I use btrfs btw) Any input welcome! Best regards, Robert-André

7 15

Bodhi and "update ejected from the push" errors
by Mattia Verga 11 Feb '22

11 Feb '22

Recently we're having some (a lot) of errors about updates stuck in Bodhi with errors like "update ejected from the push because Cannot find relevant tag...". I tried to fix some of them myself, and relengs folks are also on this. But since there are so many, I'll post here how to fix yourself. If your Bodhi update is stuck in the "Pending" state, please make sure that all the builds inside the update are tagged in the release candidate tag (which is typically something like 'f35-updates-candidate'). You can check that by clicking on the build(s) name(s) in the right column on the update page. If any build in the update is not properly tagged, you must manually tag it with something like: koji tag-build f35-updates-candidate build-0.1.2-1.fc35 (obviously you need koji cli to be installed on your system and you need to be authenticated with kerberos) After all the builds in the update are tagged you can push the update to testing. If you just push the update without all the builds properly tagged, you'll get another "update ejected from the push" the next Bodhi composer run. For updates stuck in the "Testing" state, the quickest solution is to unpush the update with the button in Bodhi web interface and then re-submit it to testing. Mattia

3 3

Mock v2.16 release, mock-core-configs v36.4
by Pavel Raiskup 11 Feb '22

11 Feb '22

Hello! I'm glad I can announce that we have a new release of Mock. See the full release notes [1]. The major change that happened is the removal of 'epel-8' config files, as a follow-up for [2] discussion (and of course on *devel lists, big thanks to everyone for the discussion). Note that this is is the last v2 release being shipped to all supported Fedora/EPEL versions. From now on, we'll move to v3 with development (in 'main' branch) and EPEL 7 stays on v2 (in 'mock-2' branch, bugfix only). [1] https://rpm-software-management.github.io/mock/Release-Notes-2.16 [2] https://pagure.io/epel/issue/133 [Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7d4aaa6fe [Fedora 34]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0947974f0a [EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2d0f959e00 [EPEL 7]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-82ccb8f2b7 Happy building! Pavel

9 27

libcurl-minimal
by Zbigniew Jędrzejewski-Szmek 10 Feb '22

10 Feb '22

Hi Kamil and everyone, what is the plan with introduction of libcurl-minimal in Fedora? IIUC, libcurl and libcurl-minimal both have the same Provides, so libcurl-minimal can be used to satisfy automatically generated dependencies: $ dnf repoquery --provides libcurl-minimal libcurl = 7.78.0-3.fc35 libcurl(x86-32) = 7.78.0-3.fc35 libcurl(x86-64) = 7.78.0-3.fc35 libcurl-minimal = 7.78.0-3.fc35 libcurl-minimal(x86-32) = 7.78.0-3.fc35 libcurl-minimal(x86-64) = 7.78.0-3.fc35 libcurl.so.4 libcurl.so.4()(64bit) $ dnf repoquery --provides libcurl libcurl = 7.78.0-3.fc35 libcurl(x86-32) = 7.78.0-3.fc35 libcurl(x86-64) = 7.78.0-3.fc35 libcurl-full = 7.78.0-3.fc35 libcurl-full(x86-32) = 7.78.0-3.fc35 libcurl-full(x86-64) = 7.78.0-3.fc35 libcurl.so.4 libcurl.so.4()(64bit) AFAICS, no other package makes use of libcurl-{full,minimal}. In systemd we only care about a narrow subset of protocols, so libcurl-minimal is perfect. I considered adding Suggests:libcurl-minimal%{_isa} in systemd. IIUC, that'd bias dnf towards the installation of libcurl-minimal. But the problem is that if some other package expects libcurl in the full version, it'll be disappointed. Hence my question: how to proceed with pulling in libcurl-minimal where it'd be useful? Should I just add Suggests:libcurl-minimal%{_isa} in systemd and let the maintainers of other packages add Recommends:libcurl-minimal%{_isa} or Requires:libcurl-minimal%{_isa} if they need it? What packages would that be? Another option would be do not do any of this at package level, but instead pull in libcurl-minimal through comps or kickstart or equivalent when doing installations. (Sorry if this is all documented somewhere… I looked around, but didn't see anything relevant.) Zbyszek

11 23

F37 Change: MinGW UCRT target (Self-Contained Change proposal)
by Ben Cotton 10 Feb '22

10 Feb '22

https://fedoraproject.org/wiki/Changes/F37MingwUCRT == Summary == This proposal is to add the UCRT target & support from Fedora to the MinGW cross-toolchains. == Owner == * Name: [[User:elmarco| Marc-André Lureau]] * Email: marcandre.lureau(a)redhat.com == Detailed Description == The current mingw32 and mingw64 cross-toolchains provided by Fedora target the MSVCRT (Microsoft Visual C++ Runtime). Since Visual Studio 15 & Windows 10, the default and recommended runtime is UCRT. See also [https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt MSVCRT vs UCRT]. A new toolchain target triple `x86_64-w64-mingw32ucrt` and associated binaries will be added. Fedora MinGW macros will be provided to target UCRT, with ucrt64-* prefix (ex: `ucrt64-meson`) mingw-* libraries will be progressively adjusted to add the produced ucrt64-* binaries. Since mingw-*.spec are very repetitive and cumbersome to modify (each mingw32, mingw64, ucrt package has to be defined manually, and this is tedious and error-prone), a custom MinGW/Fedora tool or solution will be proposed. In the meantime, packages can be modified to add manually the new target. [https://lists.fedoraproject.org/archives/list/mingw@lists.fedoraproject.org… UCRT plans on mingw(a)lists.fedoraproject.org ] == Benefit to Fedora == This change will allow to cross-compile projects to Windows with the up to date C runtime & headers, and better c99 support. This should allow to more easily mix binaries produced from different versions or compilers as well. == Scope == * Proposal owners: ** update the mingw filesystem, binutils, headers, gcc & winpthreads packages ** bootstrap the new toolchain ** propose a solution to simplify library packaging with the different targets ** update some common library packages, such as mingw-zlib * Other developers: ** Progressively adjust the mingw-* packages to produce ucrt64- packages, following the updated guidelines. * Release engineering: * Policies and guidelines: https://fedoraproject.org/wiki/Packaging:MinGW packaging guideline will be adjusted. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == None == How To Test == <pre> $ x86_64-w64-mingw32ucrt-gcc test.c $ /usr/bin/mingw-objdump -p a.exe | grep DLL vma: Hint Time Forward DLL First DLL Name: KERNEL32.dll DLL Name: api-ms-win-crt-time-l1-1-0.dll DLL Name: api-ms-win-crt-math-l1-1-0.dll DLL Name: api-ms-win-crt-runtime-l1-1-0.dll DLL Name: api-ms-win-crt-environment-l1-1-0.dll DLL Name: api-ms-win-crt-private-l1-1-0.dll DLL Name: api-ms-win-crt-heap-l1-1-0.dll DLL Name: api-ms-win-crt-locale-l1-1-0.dll DLL Name: api-ms-win-crt-stdio-l1-1-0.dll DLL Name: api-ms-win-crt-string-l1-1-0.dll </pre> == User Experience == Windows binaries produced by Fedora cross-toolchain will target a more modern and compatible C runtime, bringing hopefully better compatibility & safety. == Dependencies == None == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == The new MinGW toolchain and tools are available to compile binaries targeting the Windows UCRT. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

13 43

F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
by Ben Cotton 10 Feb '22

10 Feb '22

https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM = Wayland by Default for SDDM = == Summary == Change the default display server mode for SDDM to use a Wayland-based greeter rather than an X11-based one. == Owner == * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]], [[User:Jgrulich|Jan Grulich]] * Email: ngompa13(a)gmail.com, rdieter(a)gmail.com, jgrulich(a)redhat.com * Product: KDE Spin, Kinoite * Responsible WG: KDE SIG == Detailed Description == With [https://github.com/sddm/sddm/pull/1393 the work done upstream in SDDM to support using a Wayland based greeter] and [[Changes/ReplaceFbdevDrivers|the introduction of SimpleDRM to fix the broken fallback when platform drivers are unavailable]], it is now possible for the Fedora KDE variants (the regular spin and Kinoite) to move to Wayland for the login manager, which effectively completes the switch to Wayland for these variants. == Benefit to Fedora == As originally detailed in [[Changes/WaylandByDefaultForPlasma|the Change to switch Plasma to Wayland by default]], Fedora is a leader in advancing the adoption of the Wayland protocol as part of the overall strategy to improve the Linux graphical software stack. We have been successful in helping drive Wayland forward in the Plasma Desktop, and we intend to do the same for SDDM. == Scope == * Proposal owners: ** Upgrade {{package|sddm}} to the latest snapshot and introduce mutually exclusive <code>sddm-wayland-generic</code> and <code>sddm-x11</code> greeter configuration packages. ** Modify {{package|plasma-workspace}} to switch SDDM to Wayland *** Enable installation of the SDDM Wayland configuration snippet and ship as <code>sddm-wayland-plasma</code> that is mutually exclusive with the other sddm greeter configuration packages. This package will supplement {{package|sddm}} and <code>plasma-workspace-wayland</code> to be automatically installed together. ** Modify <code>@kde-desktop</code> comps group for Fedora Linux 36 to include <code>sddm-wayland-plasma</code> for the media. * Other developers: N/A (not needed for this Change) * Release engineering: [https://pagure.io/releng/issue/10536 #10536] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == On upgrade to Fedora Linux 36, SDDM will be transparently switched from the X11 greeter to the Wayland one leveraging kwin. In order to override this, the user can do one of the following: * Drop in a configuration file in <code>/etc/sddm.conf.d</code> to set the display server back to X11 * Swap back to X11 with the configuration package: <code>dnf swap sddm-wayland-plasma sddm-x11</code> == How To Test == Once the SDDM and Plasma Wayland changes are made, Rawhide users can try this by using nightly KDE ISOs and using them normally to install and run a Rawhide KDE Plasma environment. == User Experience == Ideally, there should be no noticeable impact on the user experience, though users may notice that things operate more smoothly and with slightly lower resources. == Dependencies == This change is dependent on [[Changes/ReplaceFbdevDrivers|the Change to replace fbdev with SimpleDRM]]. Without that Change, we will need to keep SDDM using X11 because otherwise the fallbacks are broken when drivers do not work. == Contingency Plan == * Contingency mechanism: Update comps and {{package|plasma-workspace}} so that <code>sddm-x11</code> is shipped instead. * Contingency deadline: beta freeze * Blocks release? Yes == Documentation == N/A (not a System Wide Change) == Release Notes == SDDM, the login manager for the Fedora variants using the KDE Plasma Desktop, now uses the Wayland display system. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

6 8

F37 Change: RetireARMv7 (System-Wide Change proposal)
by Ben Cotton 08 Feb '22

08 Feb '22

https://fedoraproject.org/wiki/Changes/RetireARMv7 == Owner == * Name: [[User:pbrobinson| Peter Robinson]] * Email: <pbrobinson(a)fedoraproject.org> == Detailed Description == The ARMv7 arm architecture was the second variant of the arm architecture that Fedora has supported, the first was ARMv5, the third is aarch64. The proposal is to retire ARMv7 as part of the Fedora 37 release. This will allow ARMv7/armhfp to be supported until the Fedora 36 end of life in around June 2023. Overall arm32 is generally waning with generally few new ARMv7 devices added to Fedora in recent releases. To add to that a number of newer Fedora features designed to improve speed and security of the Fedora release are causing 32 bit architectures in general primarily due to the process memory limit when linking large applications. The ARMv7/armhfp is the last fully supported 32 bit architecture, we still currently build i686 packages, but it's not shipped as artefacts. == Benefit to Fedora == The primary benefit is to maintainers of the ARM architecture, the various toolchain teams and package maintainers in general. == Scope == * Proposal owners: Work with rel-eng to disable the architecture in koji, remove all the various pungi pieces and clean up any other release detritus. * Other developers: No action required. * Release engineering: [https://pagure.io/releng/issue/10387 Releng issue #10387] Disable a bunch of stuff, it's really just one koji admin command and a PR for pungi config changes * Policies and guidelines: No initial updates to policies and guidelines as ARMv7 won't completely disappear until F-36 EOL. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Any current users of Fedora on ARMv7 devices won't be able to upgrade to Fedora 37, they will have to stay on Fedora 36 until it's EOL. == How To Test == There's not really anything to test as it's removing the support for an architecture. == User Experience == Any current users of Fedora on ARMv7 devices won't be able to upgrade to Fedora 37, they will have to stay on Fedora 36 until it's EOL. == Dependencies == N/A. == Contingency Plan == Continue on as before with the added advantage of the people that protested the removal of the architecture will be actively contributing to the maintenance of the architecture * Contingency mechanism: Leave enabled. We basically won't get to this if FESCo doesn't approve the change. * Contingency deadline: Mass rebuild. * Blocks release? Yes * Blocks product? Yes == Documentation == N/A == Release Notes == Fedora Linux 37 with the ARMv7 architecture is retired into the sunset. There will definitely be celebrations, there will likely be some that shed some tears! Overall for the maintainers it will likely be seen as a net win, for the few, generally shrinking, users it's probably a net loss but they can probably just go and buy a Raspberry Pi Zero 2W for US$15. ¯\_(ツ)_/¯ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

23 30

F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)
by Ben Cotton 07 Feb '22

07 Feb '22

https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect == Summary == exclude_from_weak_autodetect enables autodetection of unmet weak dependencies (Recommends or Supplements) of installed packages and blocks installation of packages satisfying already unmet dependencies. In other words: When you don't have the recommended package installed, it won't be automatically installed with future upgrades of the recommending package. == Owner == * Name: [[User:jmracek| Jaroslav Mracek]] * Email: jmracek(a)redhat.com == Detailed Description == The feature is designed to prevent an install of removed weak dependencies from the system by users and to not install weak dependencies missing after system deployment. It will change the behavior of DNF, microdnf, and PackageKit. The feature will be backported to all Fedoras, but in default, the feature will be off. Additional information: https://bugzilla.redhat.com/show_bug.cgi?id=1699672 The default value for exclude_from_weak_autodetect configuration can be overridden in `/etc/dnf/dnf.conf` == Feedback == The feature was requested by [[User:Churchyard|Miro Hrončok]] and supported by many others: See [https://bugzilla.redhat.com/show_bug.cgi?id=1699672 rhbz#1699672] for more feedback. == Benefit to Fedora == After the installation of a fresh system, the first upgrade will not install a lot of weak dependencies. Some of them were excluded from the kick-start installation set for good reasons (security, image size, minimal functional set, ...), but after the first update, all weak dependencies are installed, therefore some features of deployment simply disappear. == Scope == * Proposal owners: ** The feature is ready in Pull Request - https://github.com/rpm-software-management/libdnf/pull/1279 ** PRs only wait for a release of libsolv ** The Feature will be enabled in upstream as default, therefore from Fedora 36, we start to release libdnf without a revert patch of default in comparison to upstream. * Other developers: The change requires a new release of libsolv. * Release engineering: * Policies and guidelines: A packaging guideline should be added that discourages or forbids weak dependencies on fully versioned (sub)packages (see [https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c44 the details]). * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == No manual changes will be required. After the libdnf update, this feature will be on by default. == How To Test == 1. Install package without satisfied weak dependencies 2. Upgrade the upgrade. With exclude_from_weak_autodetect=true, it will not install weak dependencies of already installed packages. With exclude_from_weak_autodetect=false, weak dependencies will be installed during upgrades. == User Experience == The change in default will help to keep some values for particular deployments (a minimal system will be still minimal without disabling weak dependencies). Users will be able to remove particular weak dependencies and they will be not installed on the first upgrade. In case when the feature will not work according to the user expectation it can be switched off in the dnf configuration file. == Dependencies == libsolv - Required code changes are already in the libsolv upstream. We only wait for the next libsolv release. == Contingency Plan == There are no external dependencies, therefore we can easily postpone the feature and the change of default behavior. * Contingency mechanism: (What to do? Who will do it?) * Contingency deadline: beta freeze * Blocks release? No == Documentation == The feature will be documented in dnf man pages. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

13 35

Weirdness with clang and stdatomic.h on Rawhide
by Ron Olson 05 Feb '22

05 Feb '22

Hey all, I’m troubleshooting an issue and came up with this sample program: https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 13, on Rawhide, won’t compile that program, while on Fedora 35 it does. The reason why is that on Rawhide, stdatomic.h exists under /usr/include/c++/12 while it does not exist on 35, so clang uses its built-in stdatomic per https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations. If it uses its internal version, the sample program compiles fine. Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > 202002L”, so that means C++2b or later, not C++20. This seems to create a problem for clang which, since the file is present, wants to use it, but since it’s effectively empty due to the #ifdef, compiling of the sample program fails. Is it possible to disable clang’s use of the header file as a flag? I’ve been unable to find anything like that, and obviously renaming the header is out of the question. Also, is it correct to the setting stdatomic.h to only be used by c++2b? Thanks for any info, Ron

2 10

Why was node_exporter.service renamed to prometheus-node-exporter.service?
by Barry Scott 04 Feb '22

04 Feb '22

I just had to fix a number of my servers that use node exporter. The service name has been changed. Why was this done and did no one think about the impact on users? In the worst case I had a server fail to reboot because I had Requires=node_exporter.service in the default target. Barry

3 5

← Newer
1
2
3
4
5
6
7
8
...
39
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2022