On 07/31/2017 05:08 PM, Florian Weimer wrote:
I rebuilt all immediately problematic packages which use pthread_
clock_ functions and had the ppc64le optimization, except kernel (which
will be fixed by the upgrade to kernel-4.13.0-0.rc3.git0.1.fc27) and
community-mysql (which ran into an apparently known issue related to
unstable test cases and failed to build on x86-64, not ppc64le-specific).
For ceph, I reenabled ppc64le support.
For python3, I had to disable split debuginfo to get it to build, based
on guidance from the RPM debuginfo folks (thanks Igor and Mark).
Beyond the minimal rebuild set, I attempted further rebuilds to avoid
subsequent breakage due to library updates. I think we now have a
package set that is fairly risk-free as far as further uploads and
rebuilds are concerned (for example, I bootstrapped binutils, so that it
would not impacted by future glibc or gcc changes). I did not rebuild
everything affected because I soon ran into hard-to-debug unrelated
build failures (e.g., for couchdb). Some issues I fixed (MariaDB
breakage of lua-sql, s390x build failure of evince, highlight
/usr/share/doc dependency extraction issue).
Nick uploaded a new binutils version with the upstream patches, but as
far as I can tell, the stop-gap patch was sufficient.
We still need to do a new mass rebuild because the issue affected
feature detection. For example perl-Time-HiRes lost its clock_gettime
support because a run-time check at build time failed. I discovered
this only as the result of a build failure; such issues are really hard
to find by other means if everything automatically adjusts to the
Mmph, I forgot to mention two more things:
If you still see localentry:0 build failures after this, please send me
mail with a link to the build log. This should not happen.
And this is the final update for this issue because I consider it resolved.