devel August 2022

devel@lists.fedoraproject.org

196 participants
284 discussions

F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
by Ben Cotton 29 Nov '22

29 Nov '22

https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer 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 == Fedora will add -fno-omit-frame-pointer to the default C/C++ compilation flags, which will improve the effectiveness of profiling and debugging tools. == Owner == * Name: [[User:daandemeyer| Daan De Meyer]], [[User:Dcavalca| Davide Cavalca]], [[ Andrii Nakryiko]] * Email: daandemeyer(a)fb.com, dcavalca(a)fb.com, andriin(a)fb.com == Detailed Description == Credits to Mirek Klimos, whose internal note on stacktrace unwinding formed the basis for this change proposal (myreggg(a)gmail.com) Any performance or efficiency work relies on accurate profiling data. Sampling profilers probe the target program's call stack at regular intervals and store the stack traces. If we collect enough of them, we can closely approximate the real cost of a library or function with minimal runtime overhead. Stack trace capture what’s running on a thread. It should start with clone - if the thread was created via clone syscall - or with _start - if it’s the main thread of the process. The last function in the stack trace is code that CPU is currently executing. If a stack starts with [unknown] or any other symbol, it means it's not complete. === Unwinding === How does the profiler get the list of function names? There are two parts of it: # Unwinding the stack - getting a list of virtual addresses pointing to the executable code # Symbolization - translating virtual addresses into human-readable information, like function name, inlined functions at the address, or file name and line number. Unwinding is what we're interested in for the purpose of this proposal. The important things are: * Data on stack is split into frames, each frame belonging to one function. * Right before each function call, the return address is put on the stack. This is the instruction address in the caller to which we will eventually return — and that's what we care about. * One register, called the "frame pointer" or "base pointer" register (RBP), is traditionally used to point to the beginning of the current frame. Every function should back up RBP onto the stack and set it properly at the very beginning. The “frame pointer” part is achieved by adding push %rbp, mov %rsp,%rbp to the beginning of every function and by adding pop %rbp before returning. Using this knowledge, stack unwinding boils down to traversing a linked list: https://i.imgur.com/P6pFdPD.png === Where’s the catch? === The frame pointer register is not necessary to run a compiled binary. It makes it easy to unwind the stack, and some debugging tools rely on frame pointers, but the compiler knows how much data it put on the stack, so it can generate code that doesn't need the RBP. Not using the frame pointer register can make a program more efficient: * We don’t need to back up the value of the register onto the stack, which saves 3 instructions per function. * We can treat the RBP as a general-purpose register and use it for something else. Whether the compiler sets frame pointer or not is controlled by the -fomit-frame-pointer flag and the default is "omit", meaning we can’t use this method of stack unwinding by default. To make it possible to rely on the frame pointer being available, we'll add -fno-omit-frame-pointer to the default C/C++ compilation flags. This will instruct the compiler to make sure the frame pointer is always available. This will in turn allow profiling tools to provide accurate performance data which can drive performance improvements in core libraries and executables. == Feedback == === Potential performance impact === * Meta builds all its libraries and executables with -fno-omit-frame-pointer by default. Internal benchmarks did not show significant impact on performance when omitting the frame pointer for two of our most performance intensive applications. * Firefox recently landed a change to preserve the frame pointer in all jitted code (https://bugzilla.mozilla.org/show_bug.cgi?id=1426134) No significant decrease in performance was observed. * Kernel 4.8 frame pointer benchmarks by Suse showed 5%-10% regressions in some benchmarks (https://lore.kernel.org/all/20170602104048.jkkzssljsompjdwy@suse.de/T/#u) Should individual libraries or executables notice a significant performance degradation caused by including the frame pointer everywhere, these packages can opt-out on an individual basis as described in https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags. === Alternatives to frame pointers === There are a few alternative ways to unwind stacks instead of using the frame pointer: * [https://dwarfstd.org DWARF] data - The compiler can emit extra information that allows us to find the beginning of the frame without the frame pointer, which means we can walk the stack exactly as before. The problem is that we need to unwind the stack in kernel space which isn't implemented in the kernel. Given that the kernel implemented it's own format (ORC) instead of using DWARF, it's unlikely that we'll see a DWARF unwinder in the kernel any time soon. The perf tool allows you to use the DWARF data with --call-graph=dwarf, but this means that it copies the full stack on every event and unwinds in user space. This has very high overhead. * [https://www.kernel.org/doc/html/v5.3/x86/orc-unwinder.html ORC] (undwarf) - problems with unwinding in kernel led to creation of another format with the same purpose as DWARF, just much simpler. This can only be used to unwind kernel stack traces; it doesn't help us with userspace stacks. More information on ORC can be found [https://lwn.net/Articles/728339 here]. * [https://lwn.net/Articles/680985 LBR] - New Intel CPUs have a feature that gives you source and target addresses for the last 16 (or 32, in newer CPUs) branches with no overhead. It can be configured to record only function calls and to be used as a stack, which means it can be used to get the stack trace. Sadly, you only get the last X calls, and not the full stack trace, so the data can be very incomplete. On top of that, many Fedora users might still be using CPUs without LBR support which means we wouldn't be able to assume working profilers on a Fedora system by default. To summarize, if we want complete stacks with reasonably low overhead (which we do, there's no other way to get accurate profiling data from running services), frame pointers are currently the best option. == Benefit to Fedora == Implementing this change will provide profiling tools with easy access to stacktraces of installed libraries and executables which will lead to more accurate profiling data in general. This in turn can be used to implement optimizations to core libraries and executables which will improve the overall performance of Fedora itself and the wider Linux ecosystem. Various debugging tools can also make use of the frame pointer to access the current stacktrace, although tools like gdb can already do this to some degree via embedded dwarf debugging info. == Scope == * Proposal owners: Put up a PR to change the rpm macros to build packages by default with -fno-omit-frame-pointer by default. * Other developers: Review and merge the PR implementing the Change. * Release engineering: [https://pagure.io/releng/issues #Releng issue number]. A mass rebuild is required. * 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 == This should not impact upgrades in any way. == How To Test == # Build the package with the updated rpm macros # Profile the binary with `perf record -g <binary>` # Inspect the perf data with `perf report -g 'graph,0.5,caller'` # When expanding hot functions in the perf report, perf should show the full call graph of the hot function (at least for all functions that are part of the binary compiled with -fno-omit-frame-pointer) == User Experience == Fedora users will be more likely to have a streamlined experience when trying to debug/profile system executables/libraries. Tools such as perf will work out of the box instead of requiring to users to provide extra options (e.g. --call-graph=dwarf/LBR) or requiring users to recompile all relevant packages with -fno-omit-frame-pointer. == Dependencies == The rpm macros for Fedora need to be adjusted to include -fno-omit-frame-pointer in the default C/C++ compilation flags. == Contingency Plan == * Contingency mechanism: The new version can be released without every package being rebuilt with fno-omit-frame-pointer. Profiling will only work perfectly once all packages have been rebuilt but there will be no regression in behavior if not all packages have been rebuilt by the time of the release. If the Change is found to introduce unacceptable regressions, the PR implementing it can be reverted and affected packages can be rebuilt. * Contingency deadline: Final freeze * Blocks release? No == Documentation == * Original proposal for in-kernel DWARF unwinder (rejected): https://lkml.org/lkml/2017/5/5/571 == Release Notes == Packages are now compiled with frame pointers included by default. This will enable a variety of profiling and debugging tools to show more information out of the box. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

39 142

Updating asio in rawhide (and possibly F37) to 1.24.0
by Julian Sikorski 29 Nov '22

29 Nov '22

Dear maintainers, I have updated Fedora asio package from the current 1.16.1 to 1.24.0. I have rebuilt the seven current dependencies and with the exception of OpenSceneGraph, all build fine against the updated asio package. While OpenSceneGraph failed to build, the failure does not seem to have to do anything with asio. I have created a side tag so that the rebuilds can be coordinated: f38-build-side-56604. I do not have provenpacker privileges which means you have to request the rebuilds yourself. You can start once the asio build [1] finishes. Thank you for your cooperation in advance. Best regards, Julian [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90781633

3 6

fedpkg clone fails with Permission denied (publickey).
by Richard Shaw 26 Nov '22

26 Nov '22

Long story short I lost my home directory where I do all of my packager activities (separate from my main user) so I'm setting things up from scratch. I created new ssh keys and uploaded the public key to admin.fedoraproject.org and pasted into pagure.io. It's been over an hour and I'm still getting: $ fedpkg clone hamlib Cloning into 'hamlib'... hobbes1069(a)pkgs.fedoraproject.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Could not execute clone: Failed to execute command. I've also updated my API tokens, which is STILL not well documented. I pasted them in the appropriate spot in "/etc/rpkg/fedpkg.conf" which isn't real intuitive. Thanks, Richard

5 10

Fedora SCM requests on the weekend
by Robert-André Mauchin 07 Nov '22

07 Nov '22

Hello, I know a lot of you are working on Fedora during the week days, but for some of us, the weekend is the only time we can spend time on it. The problem is, SCM requests are rarely processed during that time, most of them get stuck from Friday afternoon to Monday afternoon (CEST), so it really hampers my work. Would it be possible for a volunteer to agree to do it on the weekend. Best regards, Robert-André

10 12

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

18 Oct '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 5

Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)
by Fabio Valentini 13 Oct '22

13 Oct '22

Hello all, I'm not quite sure how to approach this problem, but as it stands, the packages for the Pantheon DE and associated "elementary" applications will probably be mostly broken when Fedora 37 will be released. Every major GNOME update comes with problems for Pantheon (especially due to mutter API changes), but this time is *much* worse due to the additional libsoup 2 -> 3 transition. Upstream development of the Pantheon / elementary projects is now focused on finally getting elementary OS 7 out the door (which was already supposed to have happened, it will be based on ubuntu 22.04 LTS, after all). Support for things that are in the far-off future (like libsoup3, webkit2gtk-4.1, etc.) are low priority for them, especially given their diminished manpower. (The list of currently broken or "in danger of being broken on Fedora 38+" applications and components is included below, including links to upstream tickets.) I am already at my limit with the time that I can invest into Fedora, and GObject C is the bane of my existence - so I can't really help with these porting efforts, and upstream development is (rightfully so) focused on their own, more important problems right now. I doubt that these problems will be fixed in time for the release of Fedora 37. And because many of these problems result in outdated, crashing, failing-to-install or failing-to-build packages, I don't think this is a good outcome at all, least for my users. Rather than leave the DE available, but in an utterly broken and useless state, I'd rather remove it from Fedora 37 altogether. This set of packages also has at least some sentimental value to me, because they were my first contributions to Fedora - first in COPR, then getting them through package review (my first review request was for the granite GTK widget library for elementary applications, which was reviewed by rathann and ngompa). The Pantheon components and elementary apps are also probably the packages with the biggest number of actual users (the combination of "Pantheon on Fedora" is quite popular for something that's not available as an official Spin), maybe except for Syncthing, among all the packages that I maintain. So, I don't see any "good" way to handle this right now. If somebody can give me any advice for what to do in this situation, I would be grateful (even if the advice is: "yes, retire the packages, rather than leave them broken, they can be added back once they have been fixed"). Thanks, Fabio ------------------------------------------------------------------------ Some critical Pantheon DE components that are currently broken: - gala (window manager): https://github.com/elementary/gala/issues/1447 broken due to mutter API changes between 43.alpha and 43.beta fails to build + fails to install on Fedora 37+ - elementary-greeter (LightDM greeter): https://github.com/elementary/greeter/issues/617 broken due to mutter API changes fails to build + fails to install on Fedora 37+ - wingpanel (top panel, application launcher, indicators, etc.): https://github.com/elementary/wingpanel/issues/462 broken due to broken gala, and also because of mutter API changes fails to build + fails to install on Fedora 37+ Creating a compat package for older versions of mutter has previously worked to work around the worst problems, but it comes with its own can of worms (i.e. you need to backport upstream patches for compatibility with the latest gnome-settings-daemon version, etc.), and this is not something that I can commit to doing again. Additionally, some applications are broken: - elementary-calendar: https://github.com/elementary/calendar/issues/756 broken because it directly links libsoup2, but also evolution-data-server, which has transitioned to libsoup3, and geocode-glib-1.0, which is the libsoup-2 version fails to build / install on Fedora 37+ - elementary-mail: https://github.com/elementary/mail/issues/793 broken because it uses webkit2gtk-4.0, but also evolution-data-server, which has moved to libsoup3 fails to build / install on Fedora 37+ - elementary-tasks: https://github.com/elementary/tasks/issues/340 broken because it uses libsoup2, but also evolution-data-server, and geocode-glib-1.0, which is the libsoup-2 versionfails to build / install on Fedora 37+ fails to build / install on Fedora 37+ Other applications aren't broken *yet*, but they will need to be ported to new library versions at some point (for Fedora 38, or Fedora 39 at the latest, according to current plans for the removal of libsoup2): - elementary-photos: https://github.com/elementary/photos/issues/718 needs to be ported to webkit2gtk-4.1 / rest-1 / libsoup-3 - elementary-capnet-assist: https://github.com/elementary/capnet-assist/issues/84 and 85 needs to be ported to webkit2gtk-4.1 and gcr-4.0 - switchboard-plug-onlineaccounts: https://github.com/elementary/switchboard-plug-onlineaccounts/issues/243 needs to be ported evolution-data-server 3.45+ / libsoup-3

6 7

F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
by Ben Cotton 05 Oct '22

05 Oct '22

https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 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 == Transition from Fedora's short name of licenses to standardized [https://spdx.org/licenses/ SPDX license] [https://spdx.dev/specifications/ formula]. == Owner == * Name: [[User:msuchy| Miroslav Suchý]] * Name: [[User:jlovejoy| Jilayne Lovejoy]] * Name: [[User:ngompa| Neal Gompa]] * Name: [[User:dcantrell| David Cantrell]] * Name: [[User:rfontanaref| Richard Fontana]] * Name: [[User:mattdm| Matthew Miller]]  * Email: msuchy(a)redhat.com, dcantrell(a)redhat.com, jlovejoy(a)redhat.com, ngompa13(a)gmail.com, rfontana(a)redhat.com == Detailed Description == In the past, Fedora decided to use short names for licenses. Although we documented the short names very well. The identifiers were never standard. In the meantime, SPDX identifiers become standard, and [https://wiki.spdx.org/view/Business_Team/Adoption other SW vendors start using it]. In this phase, we want to provide documentation and tooling to allow maintainers to begin using SPDX license ids instead of the old Fedora short names. This move is opt-in. There will be [[Changes/SPDX_Licenses_Phase_2|Phase 2]], where we identify the remaining packages and help them to migrate to the SPDX formula. == Feedback == Ancient [https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org… feedback from SPDX organization]. Summary from [https://lists.fedoraproject.org/archives/search?q=spdx&page=1&mlist=legal%4… fedora-legal mailing list]: we want this to happen, but this is big scope and likely will happen over more than one release. Summary from packaging-committee: * [https://pagure.io/packaging-committee/pull-request/971#] older PR to change packaging guidelines * [https://pagure.io/packaging-committee/pull-request/1142] present PR that needs more updating Summary from devel-list: TBD == Benefit to Fedora == The use of a standardized identifier for license will align Fedora with other distributions. And allows efficient and reliable identification of licenses. == Scope == * Proposal owners (things sorted by done/todo and by priorities): ** Miroslav Suchý: license-fedora2spdx - done ** Jilayne Lovejoy: map rest of Fedora licenses to SPDX ids - done ** David Cantrell: create machine-readable format and new repo - done ** David Cantrell: merge mapping of Fedora licenses to SPDX ids to new data format/repo - done ** Richard Fontana & Jilayne Lovejoy: review update all licensing info and legal pages in wiki - in process ** Jilayne Lovejoy & Richard Fontana: create and populate new Docs pages for legal and licensing info - in process ** Miroslav Suchy - create [https://gitlab.com/fedora/legal/fedora-license-data fedora-license-data package] (with data from rpminspect-data-fedora) - TODO ** David Cantrell: separate licenses from rpminspect-data-fedora [https://bugzilla.redhat.com/show_bug.cgi?id=2077914 BZ 2077914] - TODO ** Miroslav Suchý: allow `license-validate` to use spdx - TODO ** David Cantrell: generate from license data to new Docs page similar to [https://fedoraproject.org/wiki/Licensing:Main#Software_License_List Licensing:Main] ** SOMEBODY: create a webhook that updates Docs page after the merge to fedora-license-data - TODO ** Jilayne Lovejoy: prepare PR for updates to packaging guidelines - in the process [https://pagure.io/packaging-committee/pull-request/1142] ** SOMEBODY: help maintainers who want to change license string to SPDX identifiers proactively. * Out of Scope: In this phase, we do not target to move **all** packages to SPDX identifiers. That will be done in [[Changes/SPDX_Licenses_Phase_2|Phase 2]]. In [[Changes/SPDX_Licenses_Phase_2|Phase 2]] we will identify the remaining packages and open BZ or PR. * Other developers: Early adopters can migrate their License tag to the SPDX identifiers. Proposal owners will gather feedback and will work on potential problems. We want to have all bits ready so that maintainers can start changing the spec files just after Fedora 37 branching (summer 2022). * Release engineering: * Policies and guidelines: Licensing page, packaging guidelines has to be altered. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora. During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula. == How To Test == Users should not need any testing. These steps are for package maintainers: * Fetch your license string from `License` tag in SPEC file. * Test that your current Fedora's short name is correct. E.g. $ license-validate -v 'MIT or GPLv1' Approved license * Convert license string to SPDX formula: $ license-fedora2spdx 'MIT or GPLv1' Warning: more options how to interpret MIT. Possible options: ['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ', 'MIT-enna', 'MIT-feh', 'mpich2'] mpich2 or GPL-1.0-only In this example, the short name `GPLv1` can be converted straight to `GPL-1.0-only`. But short name `MIT` stands for several licenses with different [https://spdx.org/licenses/ SPDX identifiers]. You have to examine what license is package actually using. `license-fedora2spdx` will try to convert the formula and use one of the options but without any heuristics. You need to manually review the license. You can check if SPDX formula is correct using: $ license-validate -v --file FIXME "MIT-CMU or GPL-1.0-only" == User Experience == Users should be able to use standard software tools that audit licenses. E.g. for Software Bills of Materials. == Dependencies == No other dependencies. == Contingency Plan == * Contingency mechanism: In this first phase, if something goes wrong, we can 'git revert' each change in dist-git. It is expected that in the first phase, there will be only a few packages altered. It may be a few hundred, but it is still doable to revert. * Contingency deadline: Beta freeze. But it is expected that not all packages will be converted by that time and the change will continue in the next release. * Blocks release? No. This change has no impact on runtime of any package. == Documentation == N/A (not a System Wide Change) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

17 47

glibc 2.36 and DT_HASH (preserving it for F37+)
by Neal Gompa 27 Sep '22

27 Sep '22

Hey all, It seems that upstream glibc disabled support for generating DT_HASH tables for its libraries and binaries, which breaks Linux games that use Epic Games' Easy Anti-Cheat (EAC). There's a pretty decent write-up about this on LWN: https://lwn.net/Articles/904892/ Can we turn this back on for Fedora glibc until we can get Epic to make fixes for this and roll them out? I'd really like my Linux games to not break on upgrading to Fedora 37... -- 真実はいつも一つ！/ Always, there's only one truth!

14 23

tinyxml2 soname bump
by Rich Mattes 26 Sep '22

26 Sep '22

Hi, I'm planning on upgrading tinyxml2 to version 9 in rawhide in the coming week, which will include a soname bump. Affected packages are: Macaulay2-0:1.19.1-2.fc37.src bullet-0:3.08-3.fc36.src cppcheck-0:2.7.4-1.fc37.src dvblinkremote-0:0.2.0-0.25.beta.fc36.src gazebo-0:10.1.0-27.fc36.src linbox-0:1.6.3-11.fc36.src vdr-epg2vdr-0:1.2.7-1.fc37.src vdr-osd2web-0:0.2.54-12.fc37.src I'll take care of the rebuilds in a side tag. Rich

1 1

F37 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)
by Ben Cotton 20 Sep '22

20 Sep '22

https://fedoraproject.org/wiki/Changes/Anaconda_Web_UI_preview_image 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 == The work on Web UI for the Anaconda installer has advanced enough so that it is possible to create and publish self contained preview images. == Owner == * Name: [[User:m4rtink| Martin Kolman]] * Email: mkolman(a)redhat.com == Detailed Description == Even though still very simple the new Anaconda Web UI is now far enough to support a simple installation workflow from a self-contained image while demonstrating all the main aspects of the new UI, such as: * flexible Wizard layout * responsive PatternFly components * new style built-in help * local and remote access to the Web UI For this we will create a self-contained boot.iso style image with a built-in tar-payload (so that the image can work even without network access) based on the latest Anaconda upstream code. We aim to have the image available for download just after the F37 release (so that the tar-payload can contain final F37 release content) and then updated automatically in regular intervals. That way the rather active Web UI development of the Web UI will be reflected in the up-to-date installation image, as well as any feedback and community PRs. == Benefit to Fedora == The Anaconda Web UI will provide modern responsive user interface based on a well known and widely used toolkit (PatternFly) and backed by proven Cockpit tooling. The screen layout is based on latest UX design guidelines as well as usability testing of the new interface and extensive mockup work. There are improvements in developer experience as well due to the more modern & more mainstream UI technology chosen and powerful Cockpit test tooling (rich unit-test as well as pixel-test framework). The stateless property of the Web UI allows almost live-coding style of UI development. This should make it easier to work on the Anaconda Web UI for not only the Anaconda team, addon developer but also for any interested contributors. Remote Web UI access should also provide a much better experience than the slow and inefficient VNC based remote GUI installation support Anaconda has today. Due to no need for local rendering remotely driven GUI installations on a constrained hardware with minimal installation images should become possible. == Scope == * Proposal owners: The Anaconda team will setup and maintain an automated Web UI preview image creation pipeline, with the image being available via a web server on the Fedora infrastructure. It will be a '''preview image only''', not an official Fedora deliverable and it will not influence Fedora release criteria in any way. * Other developers: Other developers and Fedora users are welcome to try the image once it is released and to provide feedback. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == (not supplied) == How To Test == Download the Anaconda Web UI preview image and boot it on VM or hardware that contains no important data. Install using the Web UI locally, alternatively try using the Web UI remotely. The installed OS should be functional but its testing or any issues with it are currently out of scope for the Anaconda Web UI preview image. To provide feedback use one of the Anaconda team communication channels: * IRC: [https://web.libera.chat/#anaconda #anaconda] on libera.chat * mailing list: anaconda-devel(a)lists.fedoraproject.org - https://lists.fedoraproject.org/archives/list/anaconda-devel@lists.fedorapr… * Github Discussion: https://github.com/rhinstaller/anaconda/discussions == User Experience == Should be improved compared to the current GTK interface. == Dependencies == (not supplied) == Contingency Plan == * Contingency mechanism: If we hit some blocking technical issues, the image will be published later. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No == Documentation == N/A (not a System Wide Change) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

4 6

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

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 August 2022