Thank you for your advice and willingness to help with testing. There is a plan to create a side tag and test appropriate changes there.
Changed category to system-wide change. Ondrej On Thu, Feb 11, 2021 at 3:42 PM David Cantrell <dcantr...@redhat.com> wrote: > On Wed, Feb 10, 2021 at 12:30:20PM -0700, Jeff Law 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. > > +1 > > autoconf changes are a big build impact and [most?] maintainers like > to avoid surprises here. > > >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. > > This is a good idea. But really, I would like to see packages that > run autoconf during build to be checked. I do not think it is > sufficient to just check a subset of packages or even one particular > use case. I think to do this with minimal impact, we kind of need to > make sure everything using autoconf has incorporated the necessary > changes for autoconf-2.71. In many cases, things may be ready to go. > But I don't think we can assume that. > > The approach mhroncok@ and others have used for major Python changes I > think could be applied here. As an autoconf user [under duress, but > still, I have to rely on it], I would like the opportunity to have an > autoconf-2.71 side tag to verify my packages build there before we > update rawhide with 2.71. We could automate builds to test things out > and file bugs for package maintainers for failures. I know this is a > lot of work, but I think the proactive approach is better than > throwing it in to rawhide and fixing the fallout. > > I am volunteering to help perform these test builds and file bugs > and/or PRs for packages since what I am suggesting is a lot of work. > > Thanks, > > -- > David Cantrell <dcantr...@redhat.com> > Red Hat, Inc. | Boston, MA | EST5EDT > _______________________________________________ > 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 >
_______________________________________________ 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
