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 <law@xxxxxxxxxx> 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@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
_______________________________________________ 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
