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@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 <dcantrell@redhat.com>
>> Red Hat, Inc. | Boston, MA | EST5EDT
>> _______________________________________________
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave@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-leave@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
--
David Cantrell <dcantrell@redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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