F37 proposal: Add -fno-omit-frame-pointer to default compilation
flags (System-Wide Change proposal)
by Ben Cotton
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
1 year, 4 months
fedpkg clone fails with Permission denied (publickey).
by Richard Shaw
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
1 year, 4 months
Fedora SCM requests on the weekend
by Robert-André Mauchin
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é
1 year, 5 months
The performance impact of various debug options on Fedora Rawhide
debug kernels
by Richard W.M. Jones
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
1 year, 6 months
F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
by Ben Cotton
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]]
<!-- Include you email address that you can be reached should people
want to contact you about helping with your change, status is
requested, or technical issues need to be resolved. If the change
proposal is owned by a SIG, please also add a primary contact person.
-->
* 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.o...
feedback from SPDX organization].
Summary from [https://lists.fedoraproject.org/archives/search?q=spdx&page=1&mlist=legal...
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
1 year, 6 months
tinyxml2 soname bump
by Rich Mattes
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 year, 6 months
F37 proposal: Public release of the Anaconda Web UI preview image
(Self-Contained Change proposal)
by Ben Cotton
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.fedora...
* 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
1 year, 6 months
Minizip renaming Fedora Change
by Lukas Javorsky
Hi fellow contributors,
Upstream has reported a request for minizip naming change from "minizip" to
"minizip-ng" (minizip-ng is the official name of the upstream package right
now).
As Fedora should match the upstream naming, I believe this change is
necessary.
Another naming change is required for the "minizip-compat" package which is
the subpackage of the "zlib" package. Upstream requests that we should
rename "minizip-compat" to "minizip".
I agree with renaming this package as well, however, this could lead to
multiple confusions maybe even conflicts for the users. The problem with
renaming this package right after renaming the "minizip-ng" could be that
the users may be confused about which package is the right "minizip" for
them.
I believe we could rename the "minizip-compat" to the "minizip" after some
larger time period so every package that requires "minizip" changes the
requirements to "minizip-ng" and there is no confusion anymore.
The first step I want to do is to create a Fedora Change, which contains
this whole process and is well communicated within the community.
This email serves as a heads-up and also opens a possibility for any tips
that you can give me with this change. This is my first time doing a change
like this so it may have some bumps along the way, but I'm willing to learn
and improve, so feel free to give me any advice you think could benefit me
with this process.
Thank you for understanding and sorry for quite a long email.
Lukas
--
S pozdravom/ Best regards
Lukáš Javorský
Software Engineer, Core service - Databases
Red Hat <https://www.redhat.com>
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavorsk(a)redhat.com
<https://www.redhat.com>
1 year, 7 months
F37 proposal: Emacs 28 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Emacs_28
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 ==
https://www.gnu.org/software/emacs/#Releases
* 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 ==
N/A
== 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 ==
* https://www.gnu.org/software/emacs/news/NEWS.28.1
* https://src.fedoraproject.org/rpms/emacs/pull-request/12
== Release Notes ==
The upstream release notes are available at
https://www.gnu.org/software/emacs/news/NEWS.28.1
These can also be accessed from within Emacs by doing `C-h n`.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 7 months
