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 <dcantrell@xxxxxxxxxx> 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 <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
