Well, that second mass rebuild made things worse for me. The time between the two was really short - we do need time to fix things (see below). The second rebuild not only forced us to rebase changes which were in QA (and rewrite the changelog because of date order stubbornness) but - what's worse - made the "buildroot" a moving target. I do understand that we want rebuilds against current libraries but this seemed to break more dependencies than before, maybe because the rebuild was still in progress. On the necessary fixes: I remember some system-wide changes that were doen really well (e.g. python setuptools related): e-mailing affected maintainers with clear information what is changing and how to adapt. Not so with cmake: Perfectly working specs were turned into FTBFS without heads-up for affected maintainers (other than on devel). The change description offers no information about what exactly changed (before/after of the macros) but 3 different approaches to adjust, leaving it up to the maintainers to find out which one works (sometimes none of them). Many learned about this just because of the mass rebuild, where a build can fail for many reasons rooted in other packages. This makes it really difficult to fix your own package. Plus LTO ... I think we should test build with changes like cmake or LTO in isolation from the typical mass rebuild which exposes many other problems. _______________________________________________ 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
