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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
