Jeff, thank you for your offer, I will gladly use your tester. What information/RPMs/SRPMs do you need from me?
Miro, maybe it could be a system-wide change. If you think so, I can change it. About the absolute numbers, as you said, not all FTBFS are necessarily caused by autoconf, but I did not have the time to investigate all of them. >From my perspective, lots of failures were caused by upstream/downstream dependency directly on autoconf-2.69, so we have to discuss these changes with package maintainers. Ondrej On Wed, Feb 10, 2021 at 8:32 PM Jeff Law <l...@redhat.com> wrote: > > > On 2/10/21 11:00 AM, Miro Hrončok wrote: > > On 10. 02. 21 18:47, Ben Cotton wrote: > >> == Upgrade/compatibility impact == > >> Problems during build can appear in multiple packages what can lead to > >> build failure, as multiple packages require autoconf-2.69 as their > >> upstream dependency. These problems have to be resolved before adding > >> autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages > >> are having problems during build, which could be caused by a problem > >> with same pattern. > > > > In absolute numbers, what is 20%? I see ~200 failures at > > https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/monitor/ > > (obviously not all of them are necessarily caused by autoconf). > > > > Should this be a system-wide change instead? > Given how many packages use autoconf, I think so. > > -- > > I've already volunteered my tester to help shake out this change. It's > actually a really good fit because of the autoconf/LTO interactions we > had to sort out for F33/LTO. The plan is to spin it up next week. > > In simplest terms autoconf generated code to test for the existence of > certain capabilities can be optimized away completely by LTO. This > results in autoconf incorrectly claiming certain capabilities exist. > This can cause packages to FTBFS or to even mis-behave at runtime. > > Thus it was critical to find these cases and deal with them as part of > the LTO effort. So my tester has the ability to capture generated > config.h files across its control and test builds and will report a > failure if the generated config.h files differ (with an ability to > exclude those where timestamps and such end up in the generated config.h > files). > > In the test I'm going to run the only difference between the control and > test build will be the version of autoconf. So the failures should give > us a highly accurate picture of how autoconf-2.70 will impact the > distribution as a whole. > > 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 >
_______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
