So I've done two passes over the F33 build failures here:
https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html
For any package which was failing and LTO appeared to be a factor, I've assigned
the package's associated FTBFS BZ to me to address the LTO component. Some of
those I've already fixed and either closed the BZ or handed it back to the
default assignee for non-LTO issues that need to be resolved.
Thus if you have a package on the failing packages list and its still failing,
it's unlikely to be an LTO issue. I don't mind if you reach out, but start from
the assumption LTO isn't the triggering event. You can use %define _lto_cflags
%{nil} in your .spec file to disable LTO for testing purposes.
Having said that, I do expect some LTO issues to still pop up. For example it's
likely we'll continue to see the cmake issues get resolved in various packages
and I wouldn't be surprised if after fixing a package to work with the new cmake
macros that a small number will trip LTO issues. I'm obviously here to help
with
those too.
It's also possible there are packages that are failing and which are not on that
list. One was passed along to me yesterday (libaio). Again, happy to help with
analyzing those too.
Anyway, the immediate actions are to find a near term resolution for the LTO
issues which I've assigned to myself in BZ. There aren't that many and I'm
confident we'll be able to close them out in a reasonable timeframe.
After that I'll be reviewing all the opt-outs to see which we can move forward,
which require upstream GCC bug reports, etc.
Jeff
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
