Am Montag, den 21.01.2019, 15:16 -0500 schrieb Ben Cotton:
* Proposal owners:
Build gcc in f30, rebuild packages that have direct dependencies on
exact gcc version (libtool, annobin, gcc-python-plugin).
Did not happen. Rawhide buildroot was broken yesterday around 9:50 UTC.
I was doing the rebuilds about one hour *after* GCC-9 was build, just to
have a working buildroot on Koji again [1].
gcc-python-plugin wasn't rebuilt until I triggered the build this
morning and the package actually is FTBFS due to GCC-9 [2].
This should have been done in a proper chain-build. If the change owner
does not have the needed powers for rebuilding other packages, help and
coordination from a provenpackager should have been requested *prior* to
just dropping in a new major version of GCC.
Anyways, the intention to build a new major version of GCC should have
been announced at least one week *before* silently dropping it into
Rawhide.
== 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.
Where are the results of that test mass-rebuild to be found? How much
is the fallout in these rebuilds?
At least one of my critpath packages (libxcrypt) would have been FTBFS
due to GCC-9, if I wouldn't have pushed an immediate fix [3].
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[2]
https://bugzilla.redhat.com/show_bug.cgi?id=1668175
[3]
https://github.com/besser82/libxcrypt/issues/76