On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
> > I'd like to get this package reviewed please:
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> > Would anyone like to swap reviews?
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
Time zone: Europe/London
I would like to draw some attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: startx unsets DBUS_SESSION_BUS_ADDRESS, which result in launching another D-Bus session which breaks communicating with user systemd services (and any D-Bus services started before launching X) from X session via D-Bus, since they use two different D-Bus daemons. I would really like this bug to be fixed.
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