devel September 2022

devel@lists.fedoraproject.org

212 participants
267 discussions

F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
by Ben Cotton 11 Jan '23

11 Jan '23

https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5 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 == Make DNF5 the new default packaging tool. The change will replace DNF, LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library. It is a second step after https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf. == Owner == * Name: [[User:jmracek| Jaroslav Mracek]] * Email: jmracek(a)redhat.com == Detailed Description == The new DNF5 will provide a significant improvement in user experiences and performance. The replacement is the second step in upgrade of Fedora Software Management stack. Without the change there will be multiple software management tool (DNF5, old Microdnf, PackageKit, and DNF) based on different libraries (libdnf, libdnf5), providing a different behavior, and not sharing a history. We can also expect that DNF will have only limited support from upstream. The DNF5 development was announced on [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Fedora-Devel] list in 2020. === New DNF5 Features === * Fully featured package manager without requirement of Python ** Smaller system ** Faster ** Replace DNF and Microdnf * Unified behavior of in the software management stack ** New Libdnf5 plugins (C++, Python) will be applicable to DNF5, Dnf5Daemon *** DNF4 plugins were not applicable for PackageKit and Microdnf (e.g. versionlock, subscription-manager), therefore PackageKit behaves differently in comparison to DNF ** Shared configurations *** In DNF4 not all configuration is honored by PackageKit and Microdnf ** DNF/YUM was developed for decades with impact of multiple styles and naming conventions (options, configuration, options, commands) * New Daemon ** The new daemon can provide an alternative to PackageKit for RPMs (only one backend of PackageKit) if it will be integrated into Desktop ** Support of Modularity and Comps group * Performance improvement ** Loading of repositories ** Advisory operations ** RPM queries *** Name filters with a case-insensitive search (the `repoquery` command) ** Smart sharing of metadata between dnf5 and daemon *** Reduce disk and downloads requirements *** Currently, DNF, Microdnf, and PackageKit use their own cache *** Optional, may be not available for Fedora 39 * Decrease of a maintenance cost in the long term ** Shared plugins ** Removal of functional duplicates * Fully integrated Modularity in LIBDNF5 workflows ** The Modularity is supported in DNF and LIBDNF but it is not fully integrated. Integration was not possible due to limitation of compatibility with other tools (PackageKit) ** Fully integrated Modularity required changes in the library workflow === Major codebase improvements === *Reports in structure ** DNF reports a lot of important information only in logs * Removal of duplicated implementation ** LIBDNF evolved from LIBHIF (PackageKit library) and HAWKEY (DNF library). The integration was never finished, therefore LIBDNF still contains duplicated functionality. ** decrease of the code maintenance cost in future * Unify Python bindings ** Formal Libdnf provides two types of Python bindings *** CPython (hawkey) *** SWIG (libdnf) ** Maintaining and communication between both bindings requires a lot of resources ** Binding unification was not possible without breaking API compatibility * SWIG bindings ** With SWIG we can generate additional bindings without spending huge resources ** Code in particular languages will be very similar to each other * Separation of system state from history DB and `/etc/dnf/module.d` ** In dnf-4 the list of userinstalled packages and list of installed groups along with the lists of packages installed from them is computed as an aggregation of transaction history. In dnf5 it will be stored separately, having multiple benefits, among them that the history database will serve for informational purposes only and will not define the state of the system (it gets corrupted occasionally etc.). ** Data stored in `/etc/dnf/module.d` were not supposed to be user modifiable and their format is not sufficient (missing information about installed packages with installed profiles) *** Content of `/etc/dnf/module.d` will be moved into the System State == Feedback == == Benefit to Fedora == == Scope == * Proposal owners: DNF5 is still in the development and some of the features or options are not yet available. We still have to finish the implementation of Modularity, storing internal data related to History and System State, and also documentation and man pages. DNF5 can be tested from repository with upstream nightly builds - https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/. The project's github repository is here - https://github.com/rpm-software-management/dnf5/ * Other developers: * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * 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 == The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`, and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`, `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`. === Compatibility === The new DNF5 will provide a symlink to `/usr/bin/dnf` therefore users will see the replacement as an upgrade of DNF with limited but documented syntax changes. The DNF5 will provide some compatible aliases of commands and options to improve adoption of the DNF5. == How To Test == Install `dnf5` package from https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/ == User Experience == * Improved progress bars * Improved transaction table * Transaction progress reports including scriptlets reports * Support of local rpm for transaction operation * Great bash completion (better then DNF has) * New commands and options that are only available with `DNF` == Dependencies == There is a long list of dependent packages === dnf === auter calamares copr-builder cpanspec dnf-plugin-diff dnfdragora etckeeper-dnf fedora-review fedora-upgrade kiwi-systemdeps-core libdnf-plugin-subscription-manager lpf mock osbuild perl-CPAN-Plugin-Sysdeps policycoreutils-devel rbm subscription-manager supermin system-config-language === python3-dnf === anaconda-core dnf-plugin-ovl dnfdaemon fedora-easy-karma fedora-review lorax mock-core-configs module-build-service modulemd-tools needrestart pungi python3-bodhi-client python3-dnf-plugin-cow python3-dnf-plugin-flunk_dependent_remove python3-imgcreate python3-libreport retrace-server system-config-language === libdnf === PackageKit copr-builder gnome-software-rpm-ostree libdnf-plugin-subscription-manager libdnf-plugin-swidtags libdnf-plugin-txnupd === python3-hawkey === mock-core-configs modulemd-tools python3-rpmdeplint retrace-server == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) * Contingency deadline: * Blocks release? == Documentation == none == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

34 88

Donate 1 minute of your time to test upgrades from F36 to F37
by Miroslav Suchý 10 Jan '23

10 Jan '23

Do you want to make Fedora 37 better? Please spend 1 minute of your time and try to run: # Run this only if you use default Fedora modules # next time you run any DNF command default modules will be enabled again sudo dnf module reset '*' dnf --releasever=37 --setopt=module_platform_id=platform:f37 \ --enablerepo=updates-testing \ $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \ --assumeno distro-sync This command does not replace `dnf system-upgrade`, but it will reveal potential problems. You may also run `dnf upgrade` before running this command. The `--assumeno` will just test the transaction, but does not make the actual upgrade. In case you hit dependency issues, please report it against the appropriate package. Or against fedora-obsolete-packages if that package should be removed in Fedora 37. Please check existing reports against fedora-obsolete-packages first: https://red.ht/2kuBDPu and also there is already bunch of "Fails to install" (F37FailsToInstall) reports: https://bugzilla.redhat.com/buglist.cgi?bug_id=2045109&bug_id_type=anddepen… Thank you Miroslav

51 65

"rescue" boot entry files are not updated on OS upgrades
by Chris Murphy 04 Jan '23

04 Jan '23

Summary---------- Most all Fedora variants (except Cloud) have a GRUB menu entry containing the word "rescue". This kernel+initramfs pair are never updated for the life of a Fedora installation. And they quickly become stale as a Fedora installation ages. This kernel's modules are eventually deleted, and if selected at boot time, the typical user experience is a dracut shell. Basic background------------- (skip this section if you know how it works) During a new installation, a single kernel version is installed. e.g. vmlinuz-5.17.0-0.rc4.96.fc36.x86_64 which is then duplicated as e.g. vmlinuz-0-rescue-3a86878de5d649a983916543ece7bb7e. Each of those (identical) kernels has an initramfs file: initramfs-5.17.0-0.rc4.96.fc36.x86_64.img initramfs-0-rescue-3a86878de5d649a983916543ece7bb7e.img The sole difference is the first one is a smaller host-only initramfs, the second one is a larger no host-only initramfs created with `dracut -N`. The bigger one just contains a bunch of extra kernel modules and dracut scripts, ostensibly to make it more likely to boot a system with some change in hardware that the host-only initramfs doesn't contain. The size of this rescue initramfs is around 100 MiB, with the common day to day "host only" initramfs being around 33 MiB. [1] As the system is updated, additional kernel versions are installed. dnf.conf contains installonly_limit=3, which results in a maximum of three kernel versions being installed at a time. Once a fourth kernel is installed, the first kernel and its modules are removed from /usr/lib/modules. The rescue kernel+initramfs pair are never updated or upgraded, even during system upgrades. Observations------------ This has been discussed by the Workstation working group [2] but since this functionality is present in all of Fedora, we're moving the discussion for greater visibility. There's two separate complaints, if you will: (a) that the kernel+initramfs pair are never update or upgraded for the life of the installation; and (b) that even during one release cycle, the user experience when booting the rescue entry, changes, i.e. when the matching /usr/lib/modules for the rescue entry are present early on, you do get a full runtime behavior, you will get to a graphical environment. But then once the version matched /usr/lib/modules are removed, you get a completely different behavior when booting the rescue entry. An important note from that ticket from Justin Forbes, the Fedora kernel maintainer: " Remember, the only real purpose of the rescue kernel is to get your system out of something completely unusable. It isn't meant to be a full runtime." Questions------------ * Considering the very narrow purpose of the entry, maybe the current behavior is adequate? * Does the rescue entry reliably get users to a dracut prompt, rather than indefinite hang? I don't know whether it does. * Is there any way to improve the situation without increasing the risk that the rescue entry becomes totally non-functional? * The chosen kernel version needs to be based on one that is known to boot. Currently we know the kernel+initramfs pair work because it's the same version used to boot the installation media when doing the initial provisioning. We don't actually know an updated replacement "no host-only" initramfs will work until it's tried. Is it possible to automate this? And is it worth the risk, or even figuring out how to assess the risk? * At Flock 2021, Zbyszek proposed "Building Initrd Images from RPMs" to reduce the complexity of building initramfs, maybe there's a role for it here? More: https://www.youtube.com/watch?v=GATg_bqmASc * What happens if we accept some scope creep, and go for many improvements that make the extra work worth it? * What about the unsigned nature of the initramfs? Should we be creating initramfs's in Fedora infra and signing them? * Stuff a graphical rescue environment into the initramfs? (This might be ten leaps too far, but it's intended to encourage thinking with a vivid imagination.) [1] both values from a recent Fedora 36 Workstation installation [2] https://pagure.io/fedora-workstation/issue/259 -- Chris Murphy

6 7

Orphaned X11 packages
by Adam Jackson 24 Dec '22

24 Dec '22

The following packages, previously owned by xgl-maint, are now up for grabs: xorg-x11-xfs xorg-sgml-doctools xorg-x11-drv-v4l xorg-x11-xsm xorg-x11-twm xorg-x11-drv-sisusb xorg-x11-xdm xorg-x11-docs Upstream development on all of these is pretty much nil, so if you're serious about picking up any of these you may also wish to take on the module upstream: https://gitlab.freedesktop.org/xorg - ajax

3 2

[apt-cacher-ng] Resurrect dead package
by Frédéric Pierret 23 Dec '22

23 Dec '22

Hi, I've resurrected `apt-cacher-ng` on my fork: https://src.fedoraproject.org/fork/fepitre/rpms/apt-cacher-ng/c/06340bafbb2… with successful builds on my testing COPR repository for F32+ and EPEL8: https://copr.fedorainfracloud.org/coprs/fepitre/fedora/build/1879178/. I plan to (already) use this package for my current work on reproducible builds. Is the procedure described in https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers?r… still available for such case? Thank you. Best regards, Frédéric Pierret

3 3

F38 proposal: Node.js Repackaging (Self-Contained Change proposal)
by Ben Cotton 12 Dec '22

12 Dec '22

https://fedoraproject.org/wiki/Changes/NodejsRepackaging 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 == We are reworking the Node.js packaging to make Node.js versions available as parallel-installable packages. == Owner == * Name: [[User:SGallagh| Stephen Gallagher]] * Email: sgallagh(a)redhat.com == Detailed Description == We will be creating the packages nodejs-16, nodejs-18 and (in April) nodejs-20. These packages will be parallel-installable (with the exception of the -devel subpackages) and provide `/usr/bin/node-$MAJOR`. We will also take advantage of the `alternatives` subsystem to populate `/usr/bin/node` from the default Node.js version for that release, or if the default is not installed, the highest currently-installed version. Notes: * The default in Fedora 38 will be Node.js 18. If a user was to install Node.js 16 and Node.js 20, but not Node.js 18, then Node.js 20 would provide `/usr/bin/node` * The policy going forward will be to have the most recently-released version of Node.js at the time of Fedora's expected Beta release date be the default for that release throughout its lifetime. == Feedback == [https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.or… Mailing list thread] Neal Gompa raised the question of using a subpackage to own `/usr/bin/node` instead of using the `alternatives` subsystem, citing python as an example. My response was that the problem with this is that I want `/usr/bin/node` to always be available so long as any `nodejs-$MAJOR` version is installed. It also ensures that the `node(1)` manpage always matches the `/usr/bin/node` executable. == Benefit to Fedora == === User Benefits === * Provides a simple way to have a different (or multiple) Node.js interpreters on their system. No dealing with Modularity. * Enables multiple versions of Node.js on the system (can test code against different versions without using containers) === Packager Benefits === * No more modules to maintain. * Availability of multiple Node.js versions in the buildroot means that other `nodejs-*` packages can test against multiple supported options. == Scope == * Proposal owners: The packaging work is done and can be played with at https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ today. * Other developers: There should be no need to change any dependent packages, though packagers of Node.js software may wish to take advantage of the testing opportunities afforded. * Release engineering: * Policies and guidelines: We will be updating the Node.js Packaging Guidelines with the new best practices. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Systems using the existing nodejs RPM package will be upgraded to the matching `nodejs-$MAJOR` version. Work is pending on how to migrate users of Modular Node.js to the new packages. == How To Test == == User Experience == Done correctly, this should be handled entirely without the user's need to know about it. == 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) == Documentation == https://lists.fedoraproject.org/archives/list/nodejs@lists.fedoraproject.or… == Release Notes == Multiple releases of Node.js may now be installed in parallel from the Fedora repositories. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

14 35

Inactive packagers to be removed after the F37 release
by Ben Cotton 02 Dec '22

02 Dec '22

Hello everyone! I just completed the first run of FESCo's newly approved Inactive Packager Policy[1]. Packagers that have been identified as inactive have a ticket in the find-inactive-packagers repo[2]. One week after the F37 final release, packagers who remain inactive will be removed from the packager group. (Note that pagure.io is one of the systems checked for activity, so commenting on your ticket that you're still around will prevent you from showing up in the second round.) Since this is the first time we've done something like this, it could be a little rough. I appreciate your patience and understanding. If you have suggestions for improvement, look for the open feature issues[3] and file an issue in the find-inactive-packagers repo[4] if it's not there already. For the curious, here are the stats from today's run: 2550 users checked 913 of those had no activity on src.fedoraproject.org or pagure.io 835 of those had no activity in Bodhi 812 of those had no activity on the mailing lists 606 of those (~24% of packagers) had no activity in Bugzilla. The script took a little under three hours to run. [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ [2] https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager&sta… [3] https://pagure.io/find-inactive-packagers/issues?tags=feature [4] https://pagure.io/find-inactive-packagers/new_issue -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue

47 166

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

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

Jump to page:

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