A few years ago, I packaged up glibc-arm-linux-gnu, so that Fedora could
have a packaged arm cross-toolchain that was useful (with glibc, it
cannot build anything in userspace). It worked for a while, but lately,
all builds have been failing with this error:
/usr/bin/arm-linux-gnu-ld: skipping incompatible
/usr/lib/gcc/arm-linux-gnueabi/8/libgcc_eh.a when searching for -lgcc_eh
I've looked at it and poked it quite a bit locally, but I can't seem to
get around that. I could really use some help to get this building
again, ideally, updated to 2.28.
All my work is committed to git, no help will be refused.
Thanks in advance,
[This proposal was submitted after the deadline. I am announcing it
for community discussion and will leave the decision on whether or not
to grant an exception to FESCo]
== Summary ==
Switch GCC in Fedora 30 to 9.x.y, rebuild all packages with it, or
optionally rebuild just some packages with it and rebuild all packages
only in Fedora 31.
== Owner ==
* Name: [[User:jakub| Jakub Jelínek]]
* Email: jakub(a)redhat.com
== Detailed Description ==
GCC 9 is currently in stage4 since January 7th, in prerelease state
with only regression bugfixes and documentation fixes allowed. The
release will happen probably in the middle of April.
rpms have been built are since today in rawhide.
== Benefit to Fedora ==
See http://gcc.gnu.org/gcc-9/changes.html for the list of changes.
== Scope ==
All packages should be rebuilt with the new gcc once it hits f30, or,
if there is not enough time for that, just all packages built after
the new gcc hits the buildroots.
* Proposal owners:
Build gcc in f30, rebuild packages that have direct dependencies on
exact gcc version (libtool, annobin, gcc-python-plugin).
* Other developers: First few days/weeks just voluntary rebuilds using
the new system gcc, if things fail, look at
http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or,
if there is a gcc bug or suspected gcc bug, analyze and report.
* Release engineering: . Mass rebuild requested for F30.
* Policies and guidelines: No policies need to be changed
== Upgrade/compatibility impact ==
== How To Test ==
GCC has its own testsuite, which is run during the package build, plus
many other packages with automated tests also help to test the new
== User Experience ==
Users will be able to see compiled code improvements and use the newly
Developers will notice a newer compiler, and might need to adjust
their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html,
or, if they detect a GCC bug, report it.
== Dependencies ==
libtool, annobin, gcc-python-plugin depend on exact gcc version, those
need to be rebuilt.
== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in
preparing self-contained testcases to speed up analysis and fixing the
bugs. Don't have time to debug issues in
12000+ packages, especially when in many cases it could be caused by
undefined code in the packages etc. I don't expect we'll have to fall
back to the older gcc, we've never had to do it in the past,
but worst case we can mass rebuild everything with older gcc again.
Jeff Law has performed test mass rebuild on x86_64.
* Contingency mechanism: Revert to older gcc, mass rebuild everything again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No
== Documentation ==
== Release Notes ==
Fedora 30 comes with GCC 9.1 as primary compiler, see
http://gcc.gnu.org/gcc-9/changes.html for user visible changes in it.
Fedora Program Manager
sorry for a slightly off-topic post, but I've noticed that a significant
number of posters is sending HTML e-mail to this list (not to mention
top-replying), which generates unnecessary network traffic. Some people
pay for every bit downloaded, so they're paying for the same information
twice, because the e-mails are sent with multipart/alternative format,
which contains BOTH text/plain and text/html. One thing I noticed those
senders have in common is that they use Gmail.
So, a plea to Gmail users: please stop sending HTML e-mail to Fedora
Dominik (who still reads e-mail in text mode in a terminal)
Fedora https://getfedora.org | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
The message about Ceph  reminded me that we should probably make the
same notification for Eclipse Platform.
The Eclipse Platform upstream is in the process of dropping all support for
The current state is that upstream are no longer building for 32bit arches
upstream for 4.10 (release 2018-12) onwards. I expect them to start
actively removing 32bit specific code in future releases.
You can read more about the decision on the upstream bug 
In Fedora, Eclipse 4.10 which I am building for Rawhide and F29 right now,
still builds for 32bit arches, but this will not last long. I expect in a
future release (4.11 or later) Eclipse will no longer build on x86/arm and
at that time I will no longer be able to support these architectures in
Fedora -- I expect to exclude those arches from Fedora builds.
If you depend on the ECJ batch compiler, this will continue to be available
on all arches as a noarch package. (It is packaged as a discrete SRPM and
has no build or runtime dependency on the Eclipse Platform itself.)
As some of you know, I've been involved with the OpenVPN packages for some
time as well as being an upstream OpenVPN developer and maintainer. Now we
have released the third beta release of OpenVPN 3 Linux.
This new client shares the same code base the OpenVPN Connect (proprietary)
clients uses as well as the OpenVPN for Android when switching to use the
OpenVPN 3 backend. The OpenVPN 3 code base is a rewrite in C++ and makes use
of the more modern features of C++11.
The Linux version is also very different from the OpenVPN 2.x generation, as
it is now D-Bus based. We have done this to allow easier integration with
other users and front-ends on Linux as well as having a better privilege
separation. Once all the backend pieces of OpenVPN 3 Linux has settled non of
them runs with more privileges than absolutely needed and there are several
services running which is responsible for only a subset of the features. This
is probably the least privileged OpenVPN implementation available today. On
top of that, we have also tried to make DNS configuration work out-of-the-box
as well (but here we need much more work to be really complete).
Part of this project we're also trying to get some kind of equivalent of the
Android VPN API in place on Linux. We have our own D-Bus service which
provides the needed functionality and can hopefully work as a stepping stone
towards something which can also be used outside OpenVPN alone too. The
current implementation should already provide all the needed features to
create and configure TUN devices (including IP addresses, routing and DNS) for
I'm announcing this here now as we also have Fedora Copr builds available for
EPEL-7, Fedora 28, Fedora 29 and Rawhide. In not too far future I would like
to get the process running to get the openvpn3 package into the mainline
Fedora repositories as well.
Our main source repositories can be found here:
We would be very much interested to get more users to try this out and to move
this project forward. The current codebase is in a reasonably good shape. It
is a bit rough around the edges when it comes to the DNS configuration and
/etc/resolv.conf handling, but otherwise it is fairly production ready.
This project aims to have good and reasonable documentation. I'm not saying
we're perfect in this regards, and we're open to improve here too. All D-Bus
services should be fairly well documented and we should have man pages for
most of the binaries we provide.
* D-Bus details
* man pages:
Feel free to reach out if you have some questions or good ideas.
There was a bug filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.
I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.
I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)
and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected