Hello,
please see attached rebuild of autoconf-dependencies [1]. I would like to ask maintainers of the dependent packages to check if their packages are buildable with autoconf-2.71. It seems that lots of packages are checking for exactly version 2.69, which blocks the build and there might be no problem with version 2.71. Also there are some minor issues (unresolved dependencies, failure in %check phase,...), which can be resolved by a small fix. Please investigate the appropriate copr builds. If your fix is ready, just push it to the rawhide branch and it will be automatically rebuilt with the new autoconf-2.71 in copr. Most of the packages are successfully built with autoconf (~1450 from ~1600), so there are ~150 packages to investigate.
Attaching also results from a tester launched by Jeff Law [2] (accessible only on Red Hat VPN) which shows changes of packages with autoconf-2.69 and autoconf-2.71. This may help to understand the changes better.
Thank you for your cooperation!
Ondrej.
On Fri, Feb 12, 2021 at 11:00 PM David Cantrell <dcantrell@xxxxxxxxxx> wrote:
Sounds good. Just find me on IRC or by email and let me know what you
would like help on. I can help run/monitor scripts of builds and help
script reporting to BZ for things that fail.
Thanks,
On Thu, Feb 11, 2021 at 03:55:41PM +0100, Ondrej Dubaj wrote:
>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
--
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
