https://fedoraproject.org/wiki/Changes/DeprecateOpensslCompat
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 going to deprecate openssl1.1 package, stop shipping the
corresponding devel package, and stop respecting crypto policies in
openssl1.1 package itself.
== Owner ==
* Name: [[User:DmitryBelyavskiy| Dmitry Belyavskiy]]
* Email: dbelyavs(a)redhat.com
== Detailed Description ==
In Fedora 36 we switched to OpenSSL 3.0 branch. This is a brand new
version with new architecture. We left the openssl1.1 package for the
applications that were unable to switch to the new API/architecture,
3rd-party applications, etc. As openssl 1.1 has a predictable EOL, we
want to ensure that no new products relying on it will appear in
Fedora.
== Benefit to Fedora ==
This proposal ensures than no new packages in Fedora will rely on the
deprecated OpenSSL version that will cause an overall increase of
security/stability, and will reduce the amount of old packages relying
on OpenSSL 1.1 series.
It will also reduce the maintenance burden for the OpenSSL
maintainers, especially when new CVEs are published.
== Scope ==
* Proposal owners:
** Remove devel package
** eliminate crypto policy support from the main package
** provide assistance in migration to other developers
* Other developers:
** Patch their packages to work with OpenSSL 3.0
** Fedora/RHEL distributions provide some syntax sugar related to
https://fedoraproject.org/wiki/Packaging:CryptoPolicies. For the
packages still relying to openssl1.1 the syntax provided by crypto
policies will no longer be supported. The changes implemented
according to https://fedoraproject.org/wiki/Packaging:CryptoPolicies
(e.g. using "PROFILE=SYSTEM" as default TLS ciphersuites
configuration) should be removed.
* Release engineering: This feature doesn't require coordination with
release engineering.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
As Crypto Policy support is removed from openssl1.1, applications will
need to adjust the configuration files if they contain the line
"PROFILE=SYSTEM" according to
https://fedoraproject.org/wiki/Packaging:CryptoPolicies
== How To Test ==
Regular application tests should catch the regressions caught by these changes.
== Dependencies ==
No packages should depend on openssl1.1-devel packages that is eliminated.
== Contingency Plan ==
Revert the shipped configuration
Contingency deadline: TBD
== Documentation ==
TBW
== Release Notes ==
TBW
--
Vipul Siddharth
He/His/Him
FPgM team member
Greetings, all!
The elections for the Fedora Linux 36 cycle have completed.
## Fedora Council
Sumantro Mukherjee is elected to the Fedora Council
## Fedora Engineering Steering Committee (FESCo)
The following candidates are elected to FESCo:
* Neal Gompa
* Stephen Gallagher
* Major Hayden
* Benjamin Beasley
## Fedora Mindshare Committee
Madeline Peck is elected to the Fedora Mindshare Committee.
Additionally, David Duncan is elected to a half-term to fill the seat
vacated by Till Maas.
Congratulations to all those elected and thank you to the candidates
and voters. I will process the "paperwork" to update memberships and
documentation.
For more details, visit the Community Blog post:
https://communityblog.fedoraproject.org/fedora-linux-36-election-results/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/golang1.19
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 ==
Rebase of Golang package to upcoming version 1.19 in Fedora 37,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka|
Jakub Čajka]]
* Email: asm(a)redhat.com, jcajka(a)redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.19 in Fedora 37. Golang
1.19 is expected to be released in August 2022.
Due to Go packages' current nature and state, the rebuild of dependent
packages will be required.
== Feedback ==
No feedback yet.
== Benefit to Fedora ==
Up-to-date and latest Go release will be delivered to Fedora users.
Being close to upstream allows us to avoid security issues and provide
more up-to-date features.
Therefore Fedora will be providing a reliable development platform for
Go language and projects written in it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.19
== Scope ==
* Proposal owners: Rebase Golang package in Fedora 37, and help
resolve possible issues found during package rebuilds.
* Other developers: Fix possible issues, with help from Golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild.
* 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 ==
None.
== How To Test ==
;0.
:a) Install golang 1.19 from rawhide and use it to build your
application(s)/package(s).
:b) Scratch build against rawhide.
;1.
:Your application/package built using golang 1.19 should work as expected.
== User Experience ==
None
== Dependencies ==
<pre>
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
</pre>
<pre>
Omitted due to the number of packages listed: ~2000.
</pre>
Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.
== Contingency Plan ==
* Contingency mechanism: Reverting to golang version 1.18.X if
significant issues are discovered.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
https://tip.golang.org/doc/go1.19
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/GettextRuntimeSubpackage
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 ==
Subpackage gettext's runtime programs in a small runtime subpackage,
reducing the default install footprint.
== Owner ==
* Name: [[User:Sundeep|Sundeep ANAND]]
* Email: suanand(a)redhat.com
* Name: [[User:Petersen|Jens Petersen]]
* Email: petersen(a)redhat.com
== Detailed Description ==
Gettext is one of the core packages. Its installed on-disk size is
about ~6.1 MB. Extracting runtime utilities from main gettext package
into a separate sub-package will reduce the default system footprint
by about ~4.7 MB on most normal installations.
After the split this should look like:
<pre>
gettext-runtime subpackage
-----------------------
compressed size: 172 kB
uncompressed size: 749.6 kB
gettext package
------------------------
compressed size: 1.0 MB
uncompressed size: 4.7 MB
As gettext-runtime depends on gettext-libs:
gettext-libs subpackage
-----------------------
compressed size: 322K
uncompressed size: 933.7 kB
</pre>
Grouping of binaries:
<pre>
gettext-runtime:
envsubst gettext gettext.sh ngettext
gettext:
msgattrib msgcat msgcmp msgcomm msgconv msgen msgexec msgfilter msgfmt
msggrep msginit msgmerge msgunfmt msguniq recode-sr-latin xgettext
</pre>
== Feedback ==
* initial [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
devel thread] floating subpackaging idea (April 2022)
== Benefit to Fedora ==
Space saving of about ~4.7 MB for typical installations.
== Scope ==
* Proposal owners:
** Add <code>Provides: gettext-runtime</code> to <code>gettext</code>
[done in rawhide]
** Update the gettext package in rawhide to have the new
gettext-runtime subpackage, pulled in by the gettext base package
([https://src.fedoraproject.org/rpms/gettext/pull-request/15 PR])
** File bugs against packages that could be changed to only need
gettext-runtime at runtime.
** Subpackage envsubst as a mini-subpackage of gettext-runtime
([https://bugzilla.redhat.com/show_bug.cgi?id=2068556 bz])
* Other developers:
** Packagers who own packages that have a direct runtime dependency on
gettext (roughly 30 packages) and that actually only need
gettext-runtime can change their <code>Requires: gettext</code> to the
new <code>gettext-runtime</code> subpackage in Rawhide.
* Release engineering: [https://pagure.io/releng/issue/10836 #10836]
* 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 ==
Impact should be low: on upgrade both packages will get installed on
systems that had gettext installed.
== How To Test ==
* Preview test package is available from:
https://copr.fedorainfracloud.org/coprs/suanand/gettext-runtime
* Test upgrades from F36 to F37
* Test minimal/default installs continue to work as expected
* Packages that depend on gettext continue to rebuild, install, and
function normally
== User Experience ==
User will see a new lighter gettext-runtime package and a gettext
package. <br/>This subpackage separation also corresponds to the
recommended packaging by upstream and Debian's gettext-base and
gettext packages.
== Dependencies ==
Packages which explicitly have a dependency on gettext need to check
if they only need programs provided by gettext-runtime, and if so they
can update their dependency to <code>gettext-runtime</code> from
<code>gettext</code>.
Only about 33 Fedora packages currently require gettext (whereas
almost 1200 packages have a buildtime dependency):
NsCDE backup-manager blivet-gui byobu debootstrap deepin-gettext-tools
ecryptfs-utils fontconfig gambas3 gnome-books gnome-common grub2 ibus
ibus-chewing kf5-ki18n libpst libvirt lokalize mate-common osmo
photocollage playonlinux po-debconf po4a poedit redhat-lsb rpminspect
sensible-utils sugar-toolkit-gtk3 translate-toolkit vdr vim-syntastic
yast2-devtools
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Package owners
to revert relevant packages.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=PACKAGING
== Release Notes ==
A gettext-runtime subpackage has been added to gettext to separate out
the programs needed at runtime, reducing the default install
footprint.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
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
**Planned Outage - Fedora Wiki Upgrade - 2022-06-16 21:00 UTC**
There will be an outage starting at 2022-06-16 21:00 UTC,
which will last approximately 1 hour.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2022-06-16 21:00 UTC'
Reason for outage:
Update host to Fedora 36, bumping the version of MediaWiki to 1.37.1
Affected Services:
https://fedoraproject.org/wiki/ and any service which relies on it
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/10769
Please join #fedora-admin or #fedora-noc on irc.libera.chat
or add comments to the ticket for this outage above.
Voting in the Fedora Linux 36 elections is now open. Go to the
Elections app[1] to cast your vote. Voting closes at 23:59 UTC on
Thursday 16 June. Don't forget to claim your "I Voted" badge when you
cast your ballot. Links to candidate interviews are in the Elections
app and on the Community Blog[2].
[1] https://elections.fedoraproject.org/
[2] https://communityblog.fedoraproject.org/f36-elections-voting-now-open/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis