F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc
2.37, gdb 12.1) (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GNUToolchainF38
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 the Fedora 38 GNU Toolchain to gcc 13.0, binutils 2.39, and glibc 2.37.
The existing gdb 12.1 will be used as-is.
The set of core GNU Toolchain packages for Fedora 38 are as follows:
* GNU C Compiler 13.0
** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp),
Fortran (gfortran), D (phobos), Objective C/C++.
* GNU Binary Utilities 2.39
* GNU C Library 2.37
* GNU Debugger 12.1 (immediately available in Fedora 37)
The gcc 13.0 change will be tracked in this top-level GNU Toolchain
system-wide update.
The binutils 2.39 change will be tracked in this top-level GNU
Toolchain system-wide update.
The glibc 2.37 change will be tracked in this top-level GNU Toolchain
system-wide update.
== Owner ==
* Name: [[User:codonell|Carlos O'Donell]]
* Email: carlos(a)redhat.com
== Detailed Description ==
The GNU Compiler Collection, GNU Binary Utilities, GNU C Library, and
the GNU Debugger make up the core part of the GNU Toolchain and it is
useful for our users to transition these components as a complete
implementation when making a new release of Fedora.
The GNU Compiler Collection is expected to release version 13.0, after
the Fedora 38 release. It will contain many new features, documented
here: https://gcc.gnu.org/gcc-13/changes.html. The latest release
candidate for gcc 13 will be included in Fedora 38 and will be updated
when released.
The GNU Binutils version 2.39 was released before Fedora 38; and we
have already been using this version of binutils in Fedora Rawhide
successfully to build the distribution for the last 4 months. Given
the present schedule for Fedora 38 we will continue to use Binutils
2.39.
The GNU C Library version 2.37 is expected to be release before Fedora
38; we have started closely tracking the glibc 2.37 development code
in Fedora Rawhide and are addressing any issues as they arise. Given
the present schedule Fedora 38 will branch after the release of glibc
2.37. However, the mass rebuild schedule means Fedora 38 will mass
rebuild (if required) before the final release of glibc 2.37, but
after the ABI is frozen.
The GNU Debugger version 12.1 was released before Fedora 38; and we
plan to continue to use this version of the debugger.
== Benefit to Fedora ==
Stays up to date with latest features, improvements, security and bug
fixes from gcc, glibc, binutils, and gdb upstream.
The goal is to track and transition to the latest components of the
GNU Toolchain.
== Scope ==
* Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, gdb,
...) developers need to ensure that gcc, glibc, binutils, and gdb in
rawhide are stable and ready for the Fedora 38 branch.
* Other developers: Given that glibc is backwards compatible and we
have been testing the new glibc in rawhide it should make very little
impact when updated, except for the occasional deprecation warnings
and removal of legacy interfaces from public header files.
* Release engineering: A mass rebuild is strongly encouraged;
[https://pagure.io/releng/issue/XX #XX]
** Filed after approval.
* 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 ==
The compiler, the static linker and the the library are backwards
compatible with the previous version of Fedora.
Some source changes may be required for the gcc 13 update. Please
refer to the latest changes here:
https://gcc.gnu.org/gcc-13/changes.html
Any source level changes required for glibc 2.37 will be noted here:
https://sourceware.org/glibc/wiki/Release/2.37#Packaging_Changes
== How To Test ==
The GNU Compiler Collection has its own testsuite which is run during
the package build and examined by the gcc developers before being
uploaded.
The GNU C Library has its own testsuite which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future we may also run the
microbenchmark to look for performance regressions.
The GNU Binutils has its own testsuite which is run during the package
build and examined by binutils developers before being uploaded. The
regression testsuite is run to verify the correct operation of the
static linker and attendant utilities.
The GNU Debugger has its own testsuite which is run during the package
build and examined by gdb developers before being uploaded. The
regression testsuite is run to verify the correct operation of the
debugger.
== User Experience ==
Fedora developers as well as developers using the distribution will be
able to use and develop using the new features offered by the updated
components. Developers will need to enable specific compiler features
as required e.g. '-mcpu=neoverse-v2'.
== Dependencies ==
All packages do not need to be rebuilt due to backwards compatibility.
However, it is advantageous if a mass rebuild is performed during the
Fedora 38 cycle. The mass rebuild would ensure all packages can be
built with the newer compiler and core runtime.
== Contingency Plan ==
* Contingency mechanism glibc: If glibc 2.37 proves too disruptive to
compiling the distribution we could revert to 2.36, but given that
Rawhide has started tracking glibc 2.37, no show-stopper problems are
expected. At this point we can still revert to upstream version 2.36
if insurmountable problems appear, but to do so may require a mass
rebuild to remove new symbols from the ABI/API.
* Contingency mechanism binutils: If binutils 2.39 proves too
distruptive to assembling and linking the distribution we could revert
to 2.38, but given that Rawhide is using 2.39, no show-stopper
problems are expected. At this point we can still revert if
insurmountable problems appear, but to do so may require a mass
rebuild if the defects involve generated binaries.
* Contingency mechanism for gcc: If gcc 13 proves too disruptive to
compiling the distribution we could revert to gcc 12.
* Contingency mechanism for gdb: The gdb 12.1 release is already in
all the Fedora releases and it would not be reverted. If any gcc,
glibc or binutils changes cause gdb to fail then that would need to be
reviewed on a case-by-case basis.
* Contingency deadline: Fedora mass rebuild on 2023-01-18.
* Blocks release?
** Yes, upgrading to gcc 13.0 does block the release.
** Yes, upgrading to binutils 2.39 does block the release.
** Yes, upgrading to glibc 2.37 does block the release.
** No, upgrading to gdb 12.1 does block the release (already released).
== Documentation ==
The gcc manual contains the documentation for the release and doesn't
need any more additional work.
The binutils manual contains the documentation for the release and
doesn't need any more additional work.
The glibc manual contains the documentation for the release and
doesn't need any more additional work.
The gdb manual contains the documentation for the release and doesn't
need any more additional work.
== Release Notes ==
<!-- Use this text for GCC updates: -->
See https://gcc.gnu.org/gcc-13/changes.html for the GNU Compiler
Collection version 13 release notes.
<!-- Use this text for GLIBC updates: -->
The GNU C Library version 2.37 will be released at the beginning of
February 2023. The current NEWS notes can be seen here as they are
added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
The GNU Binary Utilities version 2.39 was released August 2022. The
current release notes will be sent to the developer mailing list:
https://sourceware.org/pipermail/binutils/2022-August/122246.html.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 3 months
static USERMODEHELPER_PATH
by Steve Grubb
Hello,
I work on RHEL security problems. I have been looking into a number of
exploits and I think we have a problem that has an easy fix. We are not using
the CONFIG_STATIC_USERMODEHELPER_PATH kernel config option. There are a number
of exploits that overwrite the path to modprobe and then pass something weird
that causes modprobe to be invoked. But instead of modprobe, it's their
reverse shell.
If we make the assigment CONFIG_STATIC_USERMODEHELPER_PATH="/usr/" and we
change /proc/sys/kernel/modprobe to sbin/modprobe and /proc/sys/kernel/
core_pattern to lib/systemd/systemd-coredump %P %u %g %s %t %c %h, then it
limits any exploits to programs that are in /usr. Only root can write here,
therefore no escalation. Typically, an exploit changes modprobe path to /tmp/
foo which is shorter than /usr/sbin/modprobe and an area the attacker can
control.
For this mitigation, we'd need to:
1) set the config option in the kernel build
2) update /proc/sys/kernel/modprobe however it's set (CONFIG_MODPROBE_PATH)
3) update /proc/sys/kernel/core_pattern however it's set
If we fix the modprobe path issue, there are a couple other areas that call
usermode helper such as handle_initrd, fork_usermode_driver,
CONFIG_UEVENT_HELPER, and sbin/request-key which would need some touch ups.
The benefit is a lot of privilege escalation attacks are taken away.
Does this sound worthwhile? Would people support this? Does this need to be
filed as a system wide change? Who could help make this happen if approved?
Thanks,
-Steve
1 year, 3 months
Fedora rawhide compose report: 20230109.n.0 changes
by Fedora Rawhide Report
OLD: Fedora-Rawhide-20230108.n.1
NEW: Fedora-Rawhide-20230109.n.0
===== SUMMARY =====
Added images: 0
Dropped images: 4
Added packages: 1
Dropped packages: 1
Upgraded packages: 29
Downgraded packages: 0
Size of added packages: 22.08 KiB
Size of dropped packages: 125.00 KiB
Size of upgraded packages: 234.73 MiB
Size of downgraded packages: 0 B
Size change of upgraded packages: 1.30 MiB
Size change of downgraded packages: 0 B
===== ADDED IMAGES =====
===== DROPPED IMAGES =====
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20230108.n.1.iso
Image: Scientific vagrant-virtualbox x86_64
Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20230108.n.1.x86_64.vagrant-virtualbox.box
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20230108.n.1.iso
Image: Scientific vagrant-libvirt x86_64
Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20230108.n.1.x86_64.vagrant-libvirt.box
===== ADDED PACKAGES =====
Package: rubygem-memoizer-1.0.3-2.fc38
Summary: Memoize your methods
RPMs: rubygem-memoizer rubygem-memoizer-doc
Size: 22.08 KiB
===== DROPPED PACKAGES =====
Package: paper-2.3-6.fc38
Summary: Query paper size database and retrieve the preferred size
RPMs: paper
Size: 125.00 KiB
===== UPGRADED PACKAGES =====
Package: ModemManager-1.20.2-2.fc38
Old package: ModemManager-1.20.2-1.fc38
Summary: Mobile broadband modem management service
RPMs: ModemManager ModemManager-devel ModemManager-glib ModemManager-glib-devel ModemManager-vala
Size: 11.87 MiB
Size change: -51.46 KiB
Changelog:
* Sun Jan 08 2023 Lubomir Rintel <lkundrak(a)v3.sk> - 1.20.2-2
- Switch to build using meson
Package: R-IRkernel-1.3.1-3.fc38
Old package: R-IRkernel-1.3-1.fc38
Summary: Native R Kernel for the 'Jupyter Notebook'
RPMs: R-IRkernel
Size: 245.32 KiB
Size change: 1.72 KiB
Changelog:
* Sun Jan 08 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 1.3-3
- Re-enable tests.
* Sun Jan 08 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 1.3.1-1
- Update to latest version (#2139798)
* Sun Jan 08 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 1.3.1-2
- Upload sources and fix typo
* Sun Jan 08 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 1.3.1-3
- Drop support for i686
Package: ags-3.6.0.40-1.fc38
Old package: ags-3.6.0.39-1.fc38
Summary: Engine for creating and running videogames of adventure (quest) genre
RPMs: ags
Size: 5.49 MiB
Size change: 69.18 KiB
Changelog:
* Sun Jan 08 2023 Dominik Mierzejewski <dominik(a)greysector.net> - 3.6.0.40-1
- update to 3.6.0.40 (#2158889)
Package: at-spi2-core-2.47.1-1.fc38
Old package: at-spi2-core-2.46.0-2.fc38
Summary: Protocol definitions and daemon for D-Bus at-spi
RPMs: at-spi2-atk at-spi2-atk-devel at-spi2-core at-spi2-core-devel atk atk-devel
Size: 6.33 MiB
Size change: 1.44 MiB
Changelog:
* Sun Jan 08 2023 David King <amigadave(a)amigadave.com> - 2.47.1-1
- Update to 2.47.1
Package: candy-icon-theme-0-33.20230107gitc27f6da2.fc38
Old package: candy-icon-theme-0-32.20220919gita14330c7.fc38
Summary: Sweet gradient icon theme
RPMs: candy-icon-theme
Size: 1.04 MiB
Size change: 13.16 KiB
Changelog:
* Mon Jan 09 2023 Artur Frenszek-Iwicki <fedora(a)svgames.pl> - 0-33.20230107gitc27f6da2
- Update to latest upstream snapshot
- Migrate License tag to SPDX
Package: crosswords-0.3.6-4.fc38
Old package: crosswords-0.3.6-3.fc38
Summary: Solve crossword puzzles
RPMs: crossword-editor crosswords crosswords-doc crosswords-puzzle-sets-cats-and-dogs crosswords-puzzle-sets-internal ipuz-convertor
Size: 42.65 MiB
Size change: 5.74 KiB
Changelog:
* Mon Jan 09 2023 Davide Cavalca <dcavalca(a)fedoraproject.org> 0.3.6-4
- Add BR for pkgconfig(iso-codes) and reorder
Package: dosbox-staging-0.80.1-1.fc38
Old package: dosbox-staging-0.80.0-2.fc38
Summary: DOS/x86 emulator focusing on ease of use
RPMs: dosbox-staging
Size: 7.60 MiB
Size change: 50.32 KiB
Changelog:
* Sun Jan 08 2023 Otto Liljalaakso <otto.liljalaakso(a)iki.fi> 0.80.1-1
- Update to 0.80.1 (rhbz#2159057)
Package: embree-3.13.5-2.fc38
Old package: embree-3.13.5-1.fc38
Summary: Collection of high-performance ray tracing kernels
RPMs: embree embree-devel
Size: 6.83 MiB
Size change: 1.75 KiB
Changelog:
* Sun Jan 08 2023 Luya Tshimbalanga <luya(a)fedoraproject.org> 3.13.5-2
- Migrate license to SPDX standard
Package: ffmpegthumbs-22.12.1-1.fc38
Old package: ffmpegthumbs-22.12.0-1.fc38
Summary: KDE ffmpegthumbnailer service
RPMs: ffmpegthumbs
Size: 179.56 KiB
Size change: 651 B
Changelog:
* Wed Jan 04 2023 Justin Zobel <justin(a)1707.io> - 22.12.1-1
- Update to 22.12.1
Package: flatbuffers-22.12.06-6.fc38
Old package: flatbuffers-22.12.06-3.fc38
Summary: FlatBuffers: Memory Efficient Serialization Library
RPMs: flatbuffers flatbuffers-compiler flatbuffers-devel flatbuffers-doc python3-flatbuffers
Size: 4.92 MiB
Size change: 3.65 KiB
Changelog:
* Sun Jan 08 2023 Benjamin A. Beasley <code(a)musicinmybrain.net> 22.12.06-4
- Minor spec file tidying
* Sun Jan 08 2023 Benjamin A. Beasley <code(a)musicinmybrain.net> 22.12.06-5
- Enable Python tests
* Mon Jan 09 2023 Benjamin A. Beasley <code(a)musicinmybrain.net> 22.12.06-6
- Fix Python big-endian (s390x) issues
Package: ghostscript-9.56.1-6.fc38
Old package: ghostscript-9.56.1-5.fc38
Summary: Interpreter for PostScript language & PDF
RPMs: ghostscript ghostscript-doc ghostscript-gtk ghostscript-tools-dvipdf ghostscript-tools-fonts ghostscript-tools-printing ghostscript-x11 libgs libgs-devel
Size: 25.30 MiB
Size change: -48.47 KiB
Changelog:
* Sun Jan 08 2023 Tom Callaway <spot(a)fedoraproject.org> - 9.56.1-6
- rebuild for libpaper v2
Package: gvfs-1.50.3-1.fc38
Old package: gvfs-1.50.2-2.fc37
Summary: Backends for the gio framework in GLib
RPMs: gvfs gvfs-afc gvfs-afp gvfs-archive gvfs-client gvfs-devel gvfs-fuse gvfs-goa gvfs-gphoto2 gvfs-mtp gvfs-nfs gvfs-smb gvfs-tests
Size: 7.39 MiB
Size change: -1.25 KiB
Changelog:
* Sun Jan 08 2023 David King <amigadave(a)amigadave.com> - 1.50.3-1
- Update to 1.50.3
Package: html2ps-1.0-0.45.b7.fc38
Old package: html2ps-1.0-0.44.b7.fc37
Summary: HTML to PostScript converter
RPMs: html2ps xhtml2ps
Size: 118.92 KiB
Size change: 29 B
Changelog:
* Sun Jan 08 2023 Tom Callaway <spot(a)fedoraproject.org> - 1.0-0.45.b7
- update to use "paper" instead of "paperconf"
Package: kpublictransport-22.12.1-1.fc38
Old package: kpublictransport-22.04.3-2.fc37
Summary: Library to assist with accessing public transport timetables and other data
RPMs: kpublictransport kpublictransport-devel
Size: 3.29 MiB
Size change: 6.55 KiB
Changelog:
* Sun Jan 08 2023 Marc Deop <marcdeop(a)fedoraproject.org> - 22.12.1-1
- 22.12.1
Package: latexmk-4.79-1.fc38
Old package: latexmk-4.78-1.fc38
Summary: A make-like utility for LaTeX files
RPMs: latexmk
Size: 405.44 KiB
Size change: 8.22 KiB
Changelog:
* Sat Jan 07 2023 Jerry James <loganjerry(a)gmail.com> - 4.79-1
- Version 4.79
Package: libmbim-1.28.2-2.fc38
Old package: libmbim-1.28.2-1.fc38
Summary: Support library for the Mobile Broadband Interface Model protocol
RPMs: libmbim libmbim-devel libmbim-utils
Size: 3.00 MiB
Size change: 34.75 KiB
Changelog:
* Sun Jan 08 2023 Lubomir Rintel <lkundrak(a)v3.sk> - 1.28.2-2
- Fix location of completions file
- Enable support for Dell DW5931e & DW5823e WWAN 5G
Package: libnma-1.10.6-1.fc38
Old package: libnma-1.10.4-1.fc38
Summary: NetworkManager GUI library
RPMs: libnma libnma-devel libnma-gtk4 libnma-gtk4-devel
Size: 2.51 MiB
Size change: -10.69 KiB
Changelog:
* Sun Jan 08 2023 Lubomir Rintel <lkundrak(a)v3.sk> - 1.10.6-1
- Update to 1.10.6 release
Package: libpaper-1:2.0.4-1.fc38
Old package: libpaper-1.1.28-5.fc37
Summary: Library and tools for handling papersize
RPMs: libpaper libpaper-devel paper
Added RPMs: paper
Size: 275.11 KiB
Size change: -17.86 KiB
Changelog:
* Sun Jan 08 2023 Tom Callaway <spot(a)fedoraproject.org> - 2.0.4-1
- update to 2.0.4
Package: libqmi-1.32.2-2.fc38
Old package: libqmi-1.32.2-1.fc38
Summary: Support library to use the Qualcomm MSM Interface (QMI) protocol
RPMs: libqmi libqmi-devel libqmi-utils
Size: 12.00 MiB
Size change: -374 B
Changelog:
* Mon Jan 02 2023 Lubomir Rintel <lkundrak(a)v3.sk> - 1.32.2-2
- Fix bash completion files path
Package: paperwork-2.1.2-1.fc38
Old package: paperwork-2.1.1-3.fc38
Summary: Using scanner and OCR to grep dead trees the easy way
RPMs: paperwork python3-paperwork
Size: 2.85 MiB
Size change: 1.16 KiB
Changelog:
* Mon Jan 09 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 2.1.2-1
- Update to latest version (#2159153)
Package: python-openpaperwork-core-2.1.2-1.fc38
Old package: python-openpaperwork-core-2.1.1-4.fc38
Summary: OpenPaperwork's core
RPMs: python3-openpaperwork-core
Size: 250.25 KiB
Size change: 2.79 KiB
Changelog:
* Mon Jan 09 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 2.1.2-1
- Update to latest version (#2159151)
Package: python-openpaperwork-gtk-2.1.2-1.fc38
Old package: python-openpaperwork-gtk-2.1.1-4.fc38
Summary: OpenPaperwork GTK plugins
RPMs: python3-openpaperwork-gtk
Size: 181.12 KiB
Size change: 4.23 KiB
Changelog:
* Mon Jan 09 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 2.1.2-1
- Update to latest version (#2159152)
Package: python-paperwork-backend-2.1.2-1.fc38
Old package: python-paperwork-backend-2.1.1-6.fc38
Summary: Paperwork's backend
RPMs: python3-paperwork-backend
Size: 347.95 KiB
Size change: 6.81 KiB
Changelog:
* Mon Jan 09 2023 Elliott Sales de Andrade <quantum.analyst(a)gmail.com> 2.1.2-1
- Update to latest version (#2159154)
Package: python-whois-0.9.22-1.fc38
Old package: python-whois-0.9.21-1.fc38
Summary: Python module for retrieving WHOIS information of domains
RPMs: python3-whois
Size: 64.79 KiB
Size change: 420 B
Changelog:
* Mon Jan 09 2023 Artur Frenszek-Iwicki <fedora(a)svgames.pl> - 0.9.22-1
- Update to v0.9.22
Package: sweet-gtk-theme-3.0-8.20230107.fc38
Old package: sweet-gtk-theme-3.0-7.20220915.fc38
Summary: Light and dark, colorful GTK+ theme
RPMs: sweet-gtk-theme
Size: 3.42 MiB
Size change: 9.60 KiB
Changelog:
* Mon Jan 09 2023 Artur Frenszek-Iwicki <fedora(a)svgames.pl> - 3.0-8.20230107
- Update to latest git snapshots
- Migrate License tag to SPDX
Package: tali-40.9-1.fc38
Old package: tali-40.8-1.fc37
Summary: GNOME Tali game
RPMs: tali
Size: 1.71 MiB
Size change: -581 B
Changelog:
* Sun Jan 08 2023 David King <amigadave(a)amigadave.com> - 40.9-1
- Update to 40.9
Package: tuxpaint-1:0.9.28-5.fc38
Old package: tuxpaint-1:0.9.28-4.fc38
Summary: Drawing program designed for young children
RPMs: tuxpaint tuxpaint-devel
Size: 69.69 MiB
Size change: -255.13 KiB
Changelog:
* Sun Jan 08 2023 Tom Callaway <spot(a)fedoraproject.org> - 1:0.9.28-5
- rebuild for new libpaper v2
Package: ustreamer-5.36-1.fc38
Old package: ustreamer-5.34-1.fc38
Summary: Lightweight and fast MJPG-HTTP streamer
RPMs: python3-ustreamer ustreamer
Added RPMs: python3-ustreamer
Size: 766.72 KiB
Size change: 88.22 KiB
Changelog:
* Sat Jan 07 2023 Tao Jin <tao-j(a)outlook.com> - 5.36-1
- Update to 5.36
- Add python package build
Package: xpdf-1:4.04-3.fc38
Old package: xpdf-1:4.04-2.fc37
Summary: A PDF file viewer for the X Window System
RPMs: xpdf xpdf-devel
Size: 14.06 MiB
Size change: -62.80 KiB
Changelog:
* Sun Jan 08 2023 Tom Callaway <spot(a)fedoraproject.org> - 1:4.04-3
- fix build with libpaper2, rebuild for it
===== DOWNGRADED PACKAGES =====
1 year, 3 months
python-cryptography license fix
by Charalampos Stratakis
The license of python-cryptography was changed to SPDX and also fixed after
clarification from upstream from "ASL 2.0 or BSD" to "(Apache-2.0 OR
BSD-3-Clause) AND PSF-2.0"
--
Regards,
Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
1 year, 3 months
Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal
[was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]
by Daan De Meyer
> I think it would save everyone a bit of time if we restricted the change
> to x86-64. We do not have much experience with the -mbackchain flag
> that was added at the last minute on s390x. The change owners have
> stated that they aren't interested in s390x. IBM doesn't want this.
> Platform Tools does not want it. I doubt the desktop team does GNOME
> performance analysis on s390x on Fedora. I'm not even sure if the tools
> support backchain-based unwinding; it's not a frame pointer after all.
> Maybe -mbackchain won't cause any issues in after all, but we just don't
> have the time to test this before the mass rebuild.
I had a look at the kernel unwinding code for s390 and it seems to use
the backchain if it's available and fall back to the frame pointer otherwise.
So from our end (change proposal authors) we're OK with dropping
mbackchain for s390 and only using fno-omit-frame-pointer for s390.
We'll open a PR to change this in the rpm macros.
> As Jakub and I have repeatedly explained, -fno-omit-frame-pointer on
> i686 is known to break certain packages (although I worked around this
> in glibc last year), simply because the reduced number of registers
> makes it impossible for GCC to compile certain functions with inline
> assembly in them. As with s390x, the concrete impact is not known at
> this point, and we are out of time for test builds.
Given these issues should manifest as compilation failures, we should notice
very clearly once the mass rebuild starts if there's a bigger problem. If there's
only a few packages that run into issues, they can opt-out. If there's larger problems,
we can remove frame pointers from i686.
> Using -mno-omit-leaf-frame-pointer for aarch64 seems to be another
> last-minute addition without any clear justification. (On AArch64, the
> link register allows one to recover the address of the immediate caller
> even if a leaf function does not have a frame pointer. That's not
> possible on x86-64, where the caller's address must be read from the
> stack, and that has to be based on the frame pointer.) Just because the
> compiler option is there to enable doesn't mean it does anything useful
> in this context.
As I mentioned in the fesco ticket, the kernel unwinder looks at the
frame pointer register (x29) first when starting an unwind on aarch64 before looking
at the link register. As such, it seems logical to require frame pointers to be available
in leaf functions so the frame pointer register is available to start unwinding. I'm happy
to be proven wrong here so we can remove mno-omit-leaf-frame-pointer for aarch64.
Cheers,
Daan De Meyer
________________________________________
From: Daan De Meyer <daandemeyer(a)meta.com>
Sent: 09 January 2023 19:21
To: Matthew Miller; Development discussions related to Fedora
Subject: Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]
> I think it would save everyone a bit of time if we restricted the change
> to x86-64. We do not have much experience with the -mbackchain flag
> that was added at the last minute on s390x. The change owners have
> stated that they aren't interested in s390x. IBM doesn't want this.
> Platform Tools does not want it. I doubt the desktop team does GNOME
> performance analysis on s390x on Fedora. I'm not even sure if the tools
> support backchain-based unwinding; it's not a frame pointer after all.
> Maybe -mbackchain won't cause any issues in after all, but we just don't
> have the time to test this before the mass rebuild.
I had a look at the kernel unwinding code for s390 and it seems to use
the backchain if it's available and fall back to the frame pointer otherwise.
So from our end (change proposal authors) we're OK with dropping
mbackchain for s390 and only using fno-omit-frame-pointer for s390.
We'll open a PR to change this in the rpm macros.
> As Jakub and I have repeatedly explained, -fno-omit-frame-pointer on
> i686 is known to break certain packages (although I worked around this
> in glibc last year), simply because the reduced number of registers
> makes it impossible for GCC to compile certain functions with inline
> assembly in them. As with s390x, the concrete impact is not known at
> this point, and we are out of time for test builds.
Given these issues should manifest as compilation failures, we should notice
very clearly once the mass rebuild starts if there's a bigger problem. If there's
only a few packages that run into issues, they can opt-out. If there's larger problems,
we can remove frame pointers from i686.
> Using -mno-omit-leaf-frame-pointer for aarch64 seems to be another
> last-minute addition without any clear justification. (On AArch64, the
> link register allows one to recover the address of the immediate caller
> even if a leaf function does not have a frame pointer. That's not
> possible on x86-64, where the caller's address must be read from the
> stack, and that has to be based on the frame pointer.) Just because the
> compiler option is there to enable doesn't mean it does anything useful
> in this context.
As I mentioned in the fesco ticket, the kernel unwinder looks at the
frame pointer register (x29) first when starting an unwind on aarch64 before looking
at the link register. As such, it seems logical to require frame pointers to be available
in leaf functions so the frame pointer register is available to start unwinding. I'm happy
to be proven wrong here so we can remove mno-omit-leaf-frame-pointer for aarch64.
Cheers,
Daan De Meyer
________________________________________
From: Florian Weimer <fweimer(a)redhat.com>
Sent: 09 January 2023 17:54
To: Matthew Miller
Cc: devel(a)lists.fedoraproject.org
Subject: Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]
!-------------------------------------------------------------------|
This Message Is From an External Sender
|-------------------------------------------------------------------!
* Matthew Miller:
> BUT, I do not think it was done with malice, as "deliberately rigged"
> implies. I don't see that at all -- I see excitement and interest in moving
> forward on something that already has taken a long time, and looming
> practical deadlines.
No one spoke out when the tools team was called untrustworthy on the
FESCo ticket. We can try explain it as an accident that the toolchain
team was sidelined afterwards. But the overall sequence of events
certainly looks rather odd.
There are infrastructure problems as well. Notifications in the Fedora
wiki system are broken (email notifications are spotty, but not
completely defunct; that did not matter here because the new FESCo
ticket was added to the change page only after the second vote), and
missing notifications for label updates on FESCo tickets (so it's hard
to spot that an issue is scheduled for discussion). So unless you are
in the in-group or invited, it's hard to contribute.
All these issues contribute to a work environment that I find very
problematic. The individual aspects are probably not deliberate, but
there's still an impact.
> And, from a practical point of view, since this passed with six +1 votes,
> I'm not sure what benefit canceling and re-voting would really add.
I'm pretty sure no one considered the impact on non-x86-64
architectures, given that the change as voted and submitted as a PR
would have broken the ppc64le and s390x buildroots.
I think it would save everyone a bit of time if we restricted the change
to x86-64. We do not have much experience with the -mbackchain flag
that was added at the last minute on s390x. The change owners have
stated that they aren't interested in s390x. IBM doesn't want this.
Platform Tools does not want it. I doubt the desktop team does GNOME
performance analysis on s390x on Fedora. I'm not even sure if the tools
support backchain-based unwinding; it's not a frame pointer after all.
Maybe -mbackchain won't cause any issues in after all, but we just don't
have the time to test this before the mass rebuild.
As Jakub and I have repeatedly explained, -fno-omit-frame-pointer on
i686 is known to break certain packages (although I worked around this
in glibc last year), simply because the reduced number of registers
makes it impossible for GCC to compile certain functions with inline
assembly in them. As with s390x, the concrete impact is not known at
this point, and we are out of time for test builds.
Using -mno-omit-leaf-frame-pointer for aarch64 seems to be another
last-minute addition without any clear justification. (On AArch64, the
link register allows one to recover the address of the immediate caller
even if a leaf function does not have a frame pointer. That's not
possible on x86-64, where the caller's address must be read from the
stack, and that has to be based on the frame pointer.) Just because the
compiler option is there to enable doesn't mean it does anything useful
in this context.
Thanks,
Florian
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
1 year, 3 months
Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)
by Matthias Clasen
On Sat, Jan 7, 2023 at 9:31 AM Giuseppe Scrivano <gscrivan(a)redhat.com>
wrote:
>
> I've just opened a PR upstream for Podman to kill -9 all the remaining
> exec sessions when the container process terminates, so both --pid=host
> and --pid=private behaves in the same way. It would solve the issue we
> are seeing.
>
>
That is fantastic. Thanks, Giuseppe!
1 year, 3 months
WASM from Ruby - Lightning Chess Web App
by Philip Rhoades
People,
Over the holidays we had our irregular Family Lightning Chess
competition (10 seconds per move) - I have not found an online web site
that will work exactly with our rules and it occurs to me that this
would be a nice project for me to get working via a Ruby2WASM project.
If I could get that project working, it would allow the family to have
at least annual electronic competitions for the times when not all the
relatives can physically make it to the one place at the one time . .
What do you think?
Regards,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
1 year, 3 months
TeXLive 2022 landing in rawhide today
by Tom Callaway
Hi Fedora,
TeXLive 2022 (composed of texlive-base and texlive SRPMs) is landing in
rawhide today. I've done extensive local testing in mock to try to make
sure it doesn't break anything obvious... but the size and scope of TL
means that there are probably still some bugs introduced by this update.
Please let me know if something stops building as a result of the new
texlive packages, either via email, bugzilla, twitter, mastodon, or carrier
pigeon, with as much detail as you can provide.
I do not plan to push this to any stable Fedora, BUT, I have tested with it
installed over Fedora 37 and it seems to work okay for me.
Apologies on the delay in getting this done. I realize TL 2023 is probably
coming out in a few months, hopefully, it will not take a year for me to
get that update in place.
~spot
1 year, 3 months
