Today I encountered another LLVM-specific bug that affects at least
one Rust package and causes non-working code to be produced, which
prompted this question:
Why are stable releases not getting bugfix releases of LLVM?
Fedora 35 is stuck at LLVM 13.0.0, while 13.0.1 has been released.
Fedora 36 is stuck at LLVM 14.0.0, while 14.0.1 through 14.0.6 have
Even Rawhide is at LLVM 14.0.5, but has not been updated to 14.0.6 yet
(released over 3 weeks ago).
However, the llvm13 compat package that exists on Fedora 36+ *has*
been updated to version 13.0.1, so I'm not sure why this update wasn't
also pushed to Fedora 35, where LLVM 13 is the default, and would
benefit much more from bugfixes provided by 13.0.1.
Given that llvm and the whole llvm ecosystem (clang, lld, rustc, ghc
on some architectures, mesa/llvmpipe) are an important part of our
stack, it seems bad that stable releases are missing out on several
bugfix updates for those critical packages.
I appreciate that updating ~a dozen packages for new LLVM point
releases is work, but I don't think having outdated LLVM components on
stable releases of Fedora is a good idea, either.
What can we do to improve this situation?
As from the pcre-8.45, the upstream stopped supporting this library. The
recommended procedure is to switch onto the new pcre2 library that has full
upstream support. 
As a result of this announcement, the older PCRE library in Fedora will be
Without upstream support, we don't have enough capacity to keep up with the
security and bugs-related issues, and thus we will support only the new
PCRE2 library. 
The retirement procedure will happen in the upcoming weeks, so if you would
like to take over the package let us know.
The list of affected packages:
Thank you for understanding.
S pozdravom/ Best regards
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
I've been trying to update healpix package to latest version, so that I
can submit a PR to the package maintainer. Current version is a couple
of years old.
Unfortunately, the automated build process available in the package
itself isn't suitable for our needs, so each component (currently the
package provides Fortran, C, C++ and Java) must be compiled on its own.
Moreover, a library is bundled (libsharp), which is needed by the C++
component... there are some reasons why not unbundle it, I will not list
them here as they're not related to my request.
I did an heavy rewrite of the spec file to adapt to the new version and
I can build everything fine locally, but when I try a koji scratch build
it fails because the configure script of the C++ component cannot find a
cfitsio header. That's weird, because the C component is able to find
cfitsio and the header, while the C++ component finds cfitsio but not
I'm at a dead end, can someone have a look at the scratch build  and
explain me where's the fault?
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.
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.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Update GNU Emacs to 28.1 release. This release includes a wide variety
of new features, including native compilation of Lisp files.
== Owner ==
* Name: [[User:Bhavin192| Bhavin Gandhi]]
* Email: bhavin192(a)fedoraproject.org
== Detailed Description ==
The Emacs package will be updated to 28.1 release of GNU Emacs. This
will have native compilation feature enabled, and will package
additional natively compiled Lisp files.
== Benefit to Fedora ==
This major version of Emacs has bugfixes and new features which also
improve the overall speed of Emacs.
== Scope ==
* Proposal owners: Upgrade the Emacs package to 28.1
* Other developers: N/A
* Release engineering: 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)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Users might see some warnings while their installed Emacs packages get
natively compiled after first launch post the upgrade. These warnings
won't break any functionality, though the users are encouraged to
update their Emacs packages.
== How To Test ==
# Run dnf update emacs
# Open Emacs and check if inbuilt functionalities and packages work as indented.
== User Experience ==
* Lisp files are natively compiled, this results in speed improvements
for most of the functionalities
* Much improved display of Emoji and Emoji sequences
* New system for documenting groups of functions
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), No
== Documentation ==
== Release Notes ==
The upstream release notes are available at
These can also be accessed from within Emacs by doing `C-h n`.
He / Him / His
Fedora Program Manager
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):
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).
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 , 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.
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
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
CONFIG_PROVE_LOCKING, CONFIG_LOCK_STAT and CONFIG_DEBUG_LOCK_ALLOC
were present and enabled in the kernel when it was imported into git
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.
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
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
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!
libgnome-desktop (gnome-desktop3 rpm package) bumps its soname in
43.alpha release. This breaks the following packages that are currently
FTBFS in rawhide:
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,