devel July 2022

devel@lists.stg.fedoraproject.org

213 participants
271 discussions

future of dual booting Windows and Fedora, redux
by Chris Murphy 16 Aug '22

16 Aug '22

Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result: 1. Fedora's installer, Anaconda, can't resize Bitlocker volumes. We could use better documentation to help the user perform the volume resize in Windows, before proceeding to booting our installation media. The documentation probably should be explicitly referenced by the Windows version of Fedora Media Writer. 2. The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR. When shim+GRUB are in the boot chain, as is the case in our default dual boot installation, the measurements are wrong, and this means the GRUB menu entry to boot Windows won't work. The user is dropped to a Windows Bitlocker recovery page. If they have their backup encryption key handy, it will work but to say the least this condition is unexpected and not user friendly - not least of which is many users won't have this backup key handy since they didn't take the action to enable Bitlocker in the first place. The bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=2049849 It was a Fedora 36 final release blocking bug, but considered a "difficult to fix" exceptional case, moving it to Fedora 37 final. Some of the options for consideration: a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it. b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader. And also remove the Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.) c. Change the release criterion. https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dua… Current: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora. Replacement: The installer must be able to install into free space alongside an existing clean Windows installation, install and configure a bootloader that will boot Fedora. d. Consider the problem sufficiently difficult to fix that we need an extension to the exceptional case allowance, and wave the bug for another release. Thoughts? -- Chris Murphy

28 92

[HEADS UP] wxGTK 3.2.0 in Rawhide
by Scott Talbert 09 Aug '22

09 Aug '22

At long last wxWidgets 3.2.0 has been released and I'm getting it into Rawhide. This comes with an soname bump (but this should be the last one as 3.2.x should now be ABI stable). NOTE: users of wxWidgets 3.0 (wxGTK3 package) are now strongly encouraged to move their packages to use wxWidgets 3.2. I've rebuilt these existing users in a side tag (f37-build-side-55557): - CubicSDR - audacity - wxmacmolplot I see that erlang also snuck in as a user recently. :) @Peter, can you please rebuild erlang in side tag f37-build-side-55557? It should rebuild fine without any changes (I tested in copr). Thanks, Scott

3 5

The performance impact of various debug options on Fedora Rawhide debug kernels
by Richard W.M. Jones 09 Aug '22

09 Aug '22

The current Fedora Rawhide kernels are too slow to run libguestfs tests when doing Koji builds. These run in a qemu VM, running the Rawhide kernel, emulated using software virtualization (ie. TCG). They now time out because these kernels are so slow. Until fairly recently they were slow but working. I wondered if particular debug options had a greater effect on performance, so I compiled many kernels (v5.19-rc7 from upstream) using the baseline "no debug" config, then adding each debug option that we use in turn, and measuring the performance using [1], using qemu software virtualization (TCG). The tests were run many times with warmups discarded to get the mean and standard deviation, using the hyperfine program[2]. The results are below, and not very conclusive, but some options do have a very large performance impact. NO_DEBUG is the kernel compiled with no debug options enabled (ie. the baseline). In the actual debug kernel I expect the slow downs to be multiplied together. To test that I did an extra run with all debug options enabled (ALL_DEBUG). CONFIG_PROVE_LOCKING, CONFIG_LOCK_STAT and CONFIG_DEBUG_LOCK_ALLOC were present and enabled in the kernel when it was imported into git in 2010. CONFIG_DEBUG_WW_MUTEX_SLOWPATH was turned off in the past (RHBZ#1114160). It seems to have been switched on again in 2020. CONFIG_DEBUG_KMEMLEAK seems like it was enabled in 2012. It's also possible that an existing debug option has got slower in the upstream kernel, that is, it's not that we've recently changed something in Fedora. Rich. [1] https://libguestfs.org/libguestfs-test-tool.1.html [2] https://github.com/sharkdp/hyperfine NO_DEBUG: 12.362 s ± 0.093 s ALL_DEBUG: 30.134 s ± 0.402 s (+143%) CONFIG_PROVE_LOCKING=y: 23.435 s ± 0.526 s (+ 88%) CONFIG_LOCK_STAT=y: 17.707 s ± 0.254 s (+ 43%) CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y: 15.804 s ± 0.161 s (+ 27%) CONFIG_DEBUG_KMEMLEAK=y: 15.794 s ± 0.261 s (+ 27%) CONFIG_DEBUG_LOCK_ALLOC=y: 15.696 s ± 0.116 s (+ 27%) CONFIG_PAGE_TABLE_CHECK_ENFORCED=y: 12.694 s ± 0.104 s (+ 2%) CONFIG_FAILSLAB=y: 12.679 s ± 0.122 s CONFIG_NOUVEAU_DEBUG_MMU=y: 12.657 s ± 0.156 s CONFIG_FAULT_INJECTION_DEBUG_FS=y: 12.630 s ± 0.158 s CONFIG_DMA_API_DEBUG=y: 12.624 s ± 0.148 s CONFIG_PERF_USE_VMALLOC=y: 12.611 s ± 0.125 s CONFIG_NOUVEAU_DEBUG_PUSH=y: 12.608 s ± 0.165 s CONFIG_DEBUG_SPINLOCK=y: 12.600 s ± 0.132 s CONFIG_PM_ADVANCED_DEBUG=y: 12.586 s ± 0.132 s CONFIG_FAIL_IO_TIMEOUT=y: 12.580 s ± 0.131 s CONFIG_FAIL_MMC_REQUEST=y: 12.571 s ± 0.103 s CONFIG_INTEL_IOMMU_DEBUGFS=y: 12.569 s ± 0.111 s CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y: 12.564 s ± 0.111 s CONFIG_SYNTH_EVENT_GEN_TEST=m: 12.552 s ± 0.082 s CONFIG_LOCK_EVENT_COUNTS=y: 12.551 s ± 0.118 s CONFIG_FAIL_MAKE_REQUEST=y: 12.550 s ± 0.098 s CONFIG_TEST_MIN_HEAP=m: 12.545 s ± 0.071 s CONFIG_DEBUG_RWSEMS=y: 12.543 s ± 0.117 s CONFIG_FAULT_INJECTION=y: 12.541 s ± 0.153 s CONFIG_LOCKDEP_BITS=16: 12.532 s ± 0.161 s CONFIG_FAIL_PAGE_ALLOC=y: 12.532 s ± 0.136 s CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12: 12.526 s ± 0.068 s CONFIG_KDB_DEFAULT_ENABLE=0x0: 12.523 s ± 0.143 s CONFIG_TEST_LIST_SORT=m: 12.522 s ± 0.062 s CONFIG_SND_VERBOSE_PRINTK=y: 12.522 s ± 0.120 s CONFIG_WQ_WATCHDOG=y: 12.518 s ± 0.141 s CONFIG_RTW89_DEBUG=y: 12.517 s ± 0.099 s CONFIG_KDB_KEYBOARD=y: 12.517 s ± 0.183 s CONFIG_DETECT_HUNG_TASK=y: 12.517 s ± 0.123 s CONFIG_TEST_LOCKUP=m: 12.514 s ± 0.080 s CONFIG_IWLWIFI_DEVICE_TRACING=y: 12.514 s ± 0.139 s CONFIG_QUOTA_DEBUG=y: 12.511 s ± 0.114 s CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120: 12.511 s ± 0.159 s CONFIG_DEBUG_RT_MUTEXES=y: 12.511 s ± 0.116 s CONFIG_EFI_PGT_DUMP=y: 12.507 s ± 0.130 s CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14: 12.506 s ± 0.095 s CONFIG_PAGE_TABLE_CHECK=y: 12.504 s ± 0.102 s CONFIG_DEBUG_VM_PGFLAGS=y: 12.500 s ± 0.106 s CONFIG_XFS_WARN=y: 12.497 s ± 0.168 s CONFIG_SND_JACK_INJECTION_DEBUG=y: 12.495 s ± 0.098 s CONFIG_FAIL_FUNCTION=y: 12.495 s ± 0.127 s CONFIG_DMAR_DEBUG=y: 12.486 s ± 0.145 s CONFIG_RTW88_DEBUG=y: 12.484 s ± 0.050 s CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=4096: 12.483 s ± 0.075 s CONFIG_DEBUG_PERF_USE_VMALLOC=y: 12.481 s ± 0.107 s CONFIG_KPROBE_EVENT_GEN_TEST=m: 12.478 s ± 0.148 s CONFIG_LOCKDEP=y: 12.475 s ± 0.095 s CONFIG_KDB_CONTINUE_CATASTROPHIC=0: 12.474 s ± 0.136 s CONFIG_DEBUG_ATOMIC_SLEEP=y: 12.469 s ± 0.125 s CONFIG_SND_PCM_XRUN_DEBUG=y: 12.467 s ± 0.073 s CONFIG_DEBUG_VM_PGTABLE=y: 12.466 s ± 0.099 s CONFIG_LOCKDEP_CHAINS_BITS=17: 12.460 s ± 0.148 s CONFIG_DEBUG_SG=y: 12.456 s ± 0.177 s CONFIG_MODULE_FORCE_UNLOAD=y: 12.453 s ± 0.150 s CONFIG_DEBUG_MISC=y: 12.453 s ± 0.133 s CONFIG_DMADEVICES_DEBUG=y: 12.450 s ± 0.135 s CONFIG_DEBUG_NET=y: 12.450 s ± 0.088 s CONFIG_PERCPU_STATS=y: 12.448 s ± 0.097 s CONFIG_CEPH_LIB_PRETTYDEBUG=y: 12.447 s ± 0.086 s CONFIG_DMAR_PERF=y: 12.445 s ± 0.146 s CONFIG_DMABUF_DEBUG=y: 12.445 s ± 0.178 s CONFIG_TRACE_IRQFLAGS_NMI=y: 12.444 s ± 0.196 s CONFIG_CAN_DEBUG_DEVICES=y: 12.440 s ± 0.100 s CONFIG_DMA_API_DEBUG_SG=y: 12.437 s ± 0.159 s CONFIG_CRYPTO_DEV_CCP_DEBUGFS=y: 12.433 s ± 0.139 s CONFIG_PTDUMP_DEBUGFS=y: 12.432 s ± 0.129 s CONFIG_EXT4_DEBUG=y: 12.431 s ± 0.124 s CONFIG_DEBUG_NOTIFIERS=y: 12.424 s ± 0.140 s CONFIG_PROVE_RCU=y: 12.420 s ± 0.183 s CONFIG_SND_CTL_VALIDATION=y: 12.417 s ± 0.152 s CONFIG_IOMMU_DEBUGFS=y: 12.415 s ± 0.149 s CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y: 12.414 s ± 0.135 s CONFIG_DEBUG_STACK_USAGE=y: 12.412 s ± 0.170 s CONFIG_DEBUG_OBJECTS_RCU_HEAD=y: 12.410 s ± 0.119 s CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION=y: 12.409 s ± 0.089 s CONFIG_DEBUG_OBJECTS_WORK=y: 12.408 s ± 0.162 s CONFIG_CARL9170_DEBUGFS=y: 12.408 s ± 0.054 s CONFIG_SND_DEBUG=y: 12.406 s ± 0.103 s CONFIG_RTW89_DEBUGMSG=y: 12.406 s ± 0.144 s CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y: 12.406 s ± 0.081 s CONFIG_DEBUG_OBJECTS_TIMERS=y: 12.403 s ± 0.177 s CONFIG_RTW88_DEBUGFS=y: 12.395 s ± 0.177 s CONFIG_B43_DEBUG=y: 12.392 s ± 0.127 s CONFIG_B43LEGACY_DEBUG=y: 12.390 s ± 0.135 s CONFIG_ACPI_APEI_ERST_DEBUG=m: 12.389 s ± 0.124 s CONFIG_DEBUG_OBJECTS_FREE=y: 12.387 s ± 0.136 s CONFIG_RTW89_DEBUGFS=y: 12.381 s ± 0.143 s CONFIG_LOCKDEP_STACK_TRACE_BITS=19: 12.372 s ± 0.136 s CONFIG_RCU_REF_SCALE_TEST=m: 12.367 s ± 0.102 s CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y: 12.363 s ± 0.180 s CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1: 12.362 s ± 0.160 s CONFIG_JBD2_DEBUG=y: 12.361 s ± 0.120 s CONFIG_TRACE_IRQFLAGS=y: 12.359 s ± 0.121 s CONFIG_ACPI_CUSTOM_METHOD=m: 12.353 s ± 0.115 s CONFIG_PREEMPTIRQ_TRACEPOINTS=y: 12.349 s ± 0.099 s CONFIG_DEBUG_CREDENTIALS=y: 12.346 s ± 0.103 s CONFIG_DEBUG_OBJECTS=y: 12.344 s ± 0.120 s CONFIG_ATH_DEBUG=y: 12.328 s ± 0.104 s CONFIG_ACPI_DEBUGGER=y: 12.326 s ± 0.146 s CONFIG_DRBD_FAULT_INJECTION=y: 12.314 s ± 0.130 s CONFIG_BPF_KPROBE_OVERRIDE=y: 12.314 s ± 0.093 s CONFIG_ACPI_DEBUGGER_USER=m: 12.312 s ± 0.142 s CONFIG_KGDB_KDB=y: 12.309 s ± 0.131 s CONFIG_DEBUG_MUTEXES=y: 12.287 s ± 0.109 s CONFIG_DEBUG_PER_CPU_MAPS=y: 12.286 s ± 0.131 s CONFIG_ACPI_EC_DEBUGFS=m: 12.285 s ± 0.117 s CONFIG_ACPI_CONFIGFS=m: 12.280 s ± 0.110 s CONFIG_ACPI_DEBUG=y: 12.277 s ± 0.101 s CONFIG_BTRFS_ASSERT=y: 12.268 s ± 0.130 s -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

4 3

Submit your questions and vote: Fedora on the Framework Laptop
by Jun Aruga (he / him) 07 Aug '22

07 Aug '22

Hi Fedora devel people, I am sending this email, as I think that you might be interested in this topic. We are going to have a talk session below at an event, Nest with Fedora on 4-6th August after around 2 weeks.[1] The topic is to give the community an idea of what Fedora people have done to support Fedora Linux on the Framework Laptop[2][3]. We collect questions in advance. You can check the link below to submit your questions or/and vote. I am looking forward to seeing your questions. [Talk-50] Behind supporting Fedora on the Framework Laptop - Ask Me Anything A guide to submit and vote: https://pagure.io/flock/issue/389#comment-807190 Thanks! Note I sent a similar email to <test(a)lists.fedoraproject.org> too,[4] but I wanted to share the info to wider people in the Fedora project. [1] Nest with Fedora - Registration Hopin: https://hopin.com/events/nest-with-fedora-2022/registration [2] Framework Laptop: https://frame.work/ [3] Framework Computer - Wikipedia: https://en.wikipedia.org/wiki/Framework_Computer [4] https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/… -- Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic See <https://www.worldtimebuddy.com/czech-republic-prague-to-utc> for the timezone.

1 1

GNOME 43.alpha builds in rawhide
by Kalev Lember 03 Aug '22

03 Aug '22

Hi all, I'm back from my vacation and taking over GNOME builds and coordination again this cycle (David King handled GNOME 42 builds during the last cycle). Upstream is busily releasing 43.alpha and we need to get our downstream builds done as well. We have a f37-gnome side tag for builds, which should help make sure we keep rawhide breakage minimum (we can verify that things roughly work before merging it). This cycle the complicating elements seem to be: - continued porting from gtk 3 to gtk 4 - libsoup to libsoup3 transition - gnome-desktop3 and gnome-desktop4 soname bumps The last two in particular affect much more consumers than just GNOME so we need to be a bit careful here. Michael already filed a Change Proposal for libsoup3 and it should hopefully get approved by FESCo soon: https://pagure.io/fesco/issue/2829 Once we have FESCo approval for libsoup3 transition, I intend to go full steam ahead with GNOME 43.alpha and libsoup3 builds. I have already done a few in the side tag, but the rest is so tangled up that I think it's easier to wait a bit. If you are helping with builds, please use 'fedpkg build --target f37-gnome'. There's no need to use it if the update really is stand alone, but if it's tangled up in the rest of the GNOME update in some way, please use the side tag so we can ensure we don't break rawhide. Thanks for attention and thanks for the help! Kalev

4 4

Heads-up: libgnome-desktop soname bump
by Kalev Lember 03 Aug '22

03 Aug '22

Hi all, libgnome-desktop (gnome-desktop3 rpm package) bumps its soname in 43.alpha release. This breaks the following packages that are currently FTBFS in rawhide: budgie-control-center-1.0.2-3.fc37.src.rpm chatty-0.6.7-1.fc37.src.rpm gala-6.3.1-3.fc37.src.rpm gnome-flashback-3.44.0-1.fc37.src.rpm phosh-0.20.0~beta2-1.fc37.src.rpm These all already failed to build in the F37 mass rebuild last week. I briefly looked at the build logs and most of these are failing due to changed gnome_desktop_thumbnail_factory_generate_thumbnail() API that now has grown GCancellable and GError out params. It should be fairly straightforward to patch. The gnome-desktop3 43.alpha update is already in rawhide, however it currently has an ugly-ugly hack in place that provides the old soname so that the packages that aren't rebuilt don't (yet) fail to install. My plan is to remove that hack in 1 week's time which is going to properly break the packages above. Thanks for understanding and sorry for the trouble, Kalev

2 3

Important changes to software license information in Fedora packages (SPDX and more!)
by Matthew Miller 03 Aug '22

03 Aug '22

On behalf of all of the folks working on Fedora licensing improvements, I have a few things to announce! New docs site for licensing and other legal topics -------------------------------------------------- All documentation related to Fedora licensing has moved to a new section in Fedora Docs, which you can find at: https://docs.fedoraproject.org/en-US/legal/ Other legal documentation will follow. This follows the overall Fedora goal of moving active user and contributor documentation away from the wiki. Fedora license information in a structured format ------------------------------------------------- The “good” (allowed) and “bad” (not-allowed) licenses for Fedora are now stored in a repository, using a simple structured file format for each license (it’s TOML). You can find this at: https://gitlab.com/fedora/legal/fedora-license-data This data is then presented in easy tabular format in the documentation, at: https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ New policy for the License field in packages — SPDX identifiers! ---------------------------------------------------------------- We’re changing the policy for the "License" field in package spec files to use SPDX license identifiers. Historically, Fedora has represented licenses using short abbreviations specific to Fedora. In the meantime, SPDX license identifiers have emerged as a standard, and other projects, vendors, and developers have started using them. Adopting SPDX license identifiers provides greater accuracy as to what license applies, and will make it easier for us to collaborate with other projects. Updated licensing policies and processes ---------------------------------------- Fedora licensing policies and processes have been updated to reflect the above changes. In some cases, this forced deeper thought as to how these things are decided and why, which led to various discussion on Fedora mailing lists. In other cases, it prompted better articulation of guidance that was implicitly understood but not necessarily explicitly stated. New guidance on “effective license” analysis -------------------------------------------- Many software packages consist of code with different free and open source licenses. Previous practice often involved “simplification” of the package license field when the packager believed that one license subsumed the other — for example, using just “GPL” when the source code includes parts licensed under a BSD-style license as well. Going forward, packagers and reviewers should not make this kind of analysis, and rather use (for example) “GPL-2.0-or-later AND MIT”. This approach is easier for packagers to apply in a consistent way. When do these changes take effect? ---------------------------------- The resulting changes in practice will be applied to new packages and licenses going forward. It is not necessary to revise existing packages at this time, although we have provided some guidance for package maintainers who want to get started. We’re in the process of planning a path for updating existing packages at a larger scale — stay tuned for more on that! Thank you everyone! ------------------- A huge thanks to some key people who have worked tirelessly to make this happen: David Cantrell, Richard Fontana, Jilayne Lovejoy, Miroslav Suchý. Behind the scenes support was also provided by David Levine, Bryan Sutula, and Beatriz Couto. Thank you as well for the valuable feedback from Fedora community members in various Fedora forums. Please have a look at the updated information. If you have questions, please post them to the Fedora Legal mailing list: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

19 39

Fedora 37 mass rebuild complete
by Kevin Fenzi 02 Aug '22

02 Aug '22

Hi all, Per the Fedora 37 schedule[1] we started a mass rebuild for Fedora 37 on 2022/07/20. We did a mass rebuild for Fedora 37 for: https://pagure.io/releng/issues?status=Open&tags=mass+rebuild The mass rebuild was done in a side tag (f37-rebuild) and moved over to f37. Failures can be seen https://kojipkgs.fedoraproject.org/mass-rebuild/f37-failures.html Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f37-need-rebuild.html 21713 builds have been tagged into f37, there is currently 1144 failed builds that need to be addressed by the package maintainers. FTBFS bugs will be filed shortly. Please be sure to let releng know if you see any bugs in the reporting. You can contact releng in #fedora-releng on libera.chat, by dropping an email to our list[2], joining #releng:fedoraproject.org on Matrix, or filing an issue in pagure[3] Regards, Fedora Release Engineering [1] https://fedorapeople.org/groups/schedule/f-N/f-N-key-tasks.html [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [3] https://pagure.io/releng/ _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)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.fedorapr… Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

7 15

dnf makecache memory usage increase
by Paul Wouters 02 Aug '22

02 Aug '22

Looks like dnf makecache is uses a lot more memory, causing issues on smaller systems/containers. F34: Metadata cache created. 1.51user 0.15system 0:12.01elapsed 13%CPU (0avgtext+0avgdata 162440maxresident)k 144inputs+56outputs (0major+46906minor)pagefaults 0swaps F35: Metadata cache created. 29.28user 2.15system 0:49.94elapsed 62%CPU (0avgtext+0avgdata 841704maxresident)k 184160inputs+497320outputs (181major+425900minor)pagefaults 0swaps Is this a known issue? Paul

6 5

Announcing fmt library soversion bump
by Vitaly Zaitsev 01 Aug '22

01 Aug '22

Hello. fmt 9.0.x update will include a soversion bump from .8 to .9. It has both API and ABI changes. Changelog: https://github.com/fmtlib/fmt/releases/tag/9.0.0 The list of affected packages in Rawhide: 0ad OpenImageIO cantera ceph dolphin-emu domoticz folly libsonata mkvtoolnix sdrpp spdlog vcpkg zswap-cli I can rebuild only spdlog, vcpkg and zswap-cli. For others, I will need proven-packagers assistance. Please use the f37-build-side-54844 side tag. I will merge it into Rawhide later. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

19 47

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel July 2022