Re: question was: What do we think about always autoreconfing? was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On Mon, 2021-04-19 at 09:27 +0200, Ondrej Dubaj wrote: > > > On Fri, Apr 16, 2021 at 3:30 PM David Cantrell > wrote: > > On Tue, Apr 13, 2021 at 11:26:24AM +0100, Richard W.M. Jones wrote: > > >Hijacking this thread originally about > > >https://fedoraproject.org/wiki/Changes/Autoconf_271 > > > > > >What is the current thinking in Fedora about always running > > >"autoreconf -i" during builds that use autotools? > > > > I think we are likely to see the least problems for projects that > > created their configure.ac files using autoscan. For projects that > > constructed them manually or in other ways, we'll likely see some > > fallout. I would encourage maintainers to work towards fixing > > these > > things and contributing them back upstream. Still, we would need > > to > > provide a way to disable the autoreconf step for particular > > problematic packages. > > > > Some projects provide their own autotools macros and wrappers > > around > > autoreconf. For example, Xfce either provides or provided xdt- > > autogen > > as a wrapper to run autoreconf with the Xfce-specific macros and > > other > > defines available. If it's best to rerun xdt-autogen in these > > cases, > > how could we handle that in the spec file so it runs the correct > > 'autoreconf' command? > > > > >The cons of always autoreconfing are that it slows down builds, > > >sometimes considerably. It also could fail - I noticed that > > autoconf > > >2.71 has several incompatibilities with the most widely used > > autoconf > > >(2.69). > > > > I think the failures will be the most frustrating part of this > > rather > > than the build time. An FAQ or something of how to fix common > > failures for 2.71 would be useful for contributors. > > > > > Document with common failures and fixes already exists [1]. Also > multiple ways of testing are documented in the change proposal [2], > where the link to the document [1] is present. > > Updating autoconf to version 2.71 is a hard process, we are doing our > best to make it as fluent as possible. There is a copr created for > testing, bugs in bugzilla created (with link to change proposal) for > failing components and we are actively moving things forward. > > Hopefully it will be enough to make this possible. > > [1] > https://docs.google.com/document/d/1SAGTJZEF9z_nkHMbXTF-YTTvKRja7ygfOOMzl-DYBSk/edit > I almost missed this precious document, in my opinion it should go to the fedoraproject wiki pages along [2] The document covers almost all the problems that I found "if test "$ac_test_CFLAGS" = set" , stopped to work what is the correct replacement ? "if test -z $CFLAGS; then" or "if test $ac_test_CFLAGS; then" this second option was found here [3] [3] https://chromium.googlesource.com/external/github.com/Distrotech/autoconf/+/76754e04fce5f6a7701bec57b057020585df2ae3%5E%21/ > [2] https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test > > > > > > Thanks, > > > > ___ > > 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 -- Sérgio M. B. ___ 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
Re: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On Fri, Apr 16, 2021 at 3:30 PM David Cantrell wrote: > On Tue, Apr 13, 2021 at 11:26:24AM +0100, Richard W.M. Jones wrote: > >Hijacking this thread originally about > >https://fedoraproject.org/wiki/Changes/Autoconf_271 > > > >What is the current thinking in Fedora about always running > >"autoreconf -i" during builds that use autotools? > > I think we are likely to see the least problems for projects that > created their configure.ac files using autoscan. For projects that > constructed them manually or in other ways, we'll likely see some > fallout. I would encourage maintainers to work towards fixing these > things and contributing them back upstream. Still, we would need to > provide a way to disable the autoreconf step for particular > problematic packages. > > Some projects provide their own autotools macros and wrappers around > autoreconf. For example, Xfce either provides or provided xdt-autogen > as a wrapper to run autoreconf with the Xfce-specific macros and other > defines available. If it's best to rerun xdt-autogen in these cases, > how could we handle that in the spec file so it runs the correct > 'autoreconf' command? > > >The cons of always autoreconfing are that it slows down builds, > >sometimes considerably. It also could fail - I noticed that autoconf > >2.71 has several incompatibilities with the most widely used autoconf > >(2.69). > > I think the failures will be the most frustrating part of this rather > than the build time. An FAQ or something of how to fix common > failures for 2.71 would be useful for contributors. > Document with common failures and fixes already exists [1]. Also multiple ways of testing are documented in the change proposal [2], where the link to the document [1] is present. Updating autoconf to version 2.71 is a hard process, we are doing our best to make it as fluent as possible. There is a copr created for testing, bugs in bugzilla created (with link to change proposal) for failing components and we are actively moving things forward. Hopefully it will be enough to make this possible. [1] https://docs.google.com/document/d/1SAGTJZEF9z_nkHMbXTF-YTTvKRja7ygfOOMzl-DYBSk/edit [2] https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test > Thanks, > > -- > David Cantrell > 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
Re: What do we think about always autoreconfing?
On Tuesday, April 13, 2021 3:50:18 PM CEST Florian Weimer wrote: > * Neal Gompa: > > > As I said previously[1], I think doing autoconf upgrades would be less > > painful if we always did that. > > > > [1]: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZG3SNLFS7BSXQ3JFJDOWUS3WWGTGLR2/ > > I think that's not actually true: If we do not build from source, it > doesn't matter if the compiler produces a working executable program > from the old sources. This is interesting perspective, but I doubt that changing the status quo would bring much practical difference. As long as there are no problems, people don't review the generated files like configure, config.status, ... no matter if autoreconfed in Fedora, or upstream. Doing so may also bring an additional level of non-determinism. For packages that don't patch auto* inputs nowadays it can bring significant build-time problems. The problem is that autoconf macros are hard, often misunderstood, some things change, older auto* versions are more tolerant, ... and fixing FTBFSs is non-trivial for many package maintainers. Btw., the fact that there are even now so many packages BuildRequiring autotools brings the significant fear from actually updating autotools in distributions (contrary to what I would wish, e.g. in EL). > Apart from the build-from-source principle, there are other advantages. > It may be easier to adopt new architectures and toolchain versions. At least config.sub and config.guess are automatically replaced by %configure even now. Pavel > Thanks, > Florian > ___ > 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
Re: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On Tue, Apr 13, 2021 at 11:26:24AM +0100, Richard W.M. Jones wrote: Hijacking this thread originally about https://fedoraproject.org/wiki/Changes/Autoconf_271 What is the current thinking in Fedora about always running "autoreconf -i" during builds that use autotools? I think we are likely to see the least problems for projects that created their configure.ac files using autoscan. For projects that constructed them manually or in other ways, we'll likely see some fallout. I would encourage maintainers to work towards fixing these things and contributing them back upstream. Still, we would need to provide a way to disable the autoreconf step for particular problematic packages. Some projects provide their own autotools macros and wrappers around autoreconf. For example, Xfce either provides or provided xdt-autogen as a wrapper to run autoreconf with the Xfce-specific macros and other defines available. If it's best to rerun xdt-autogen in these cases, how could we handle that in the spec file so it runs the correct 'autoreconf' command? The cons of always autoreconfing are that it slows down builds, sometimes considerably. It also could fail - I noticed that autoconf 2.71 has several incompatibilities with the most widely used autoconf (2.69). I think the failures will be the most frustrating part of this rather than the build time. An FAQ or something of how to fix common failures for 2.71 would be useful for contributors. Thanks, -- David Cantrell 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
Re: What do we think about always autoreconfing?
* Neal Gompa: > As I said previously[1], I think doing autoconf upgrades would be less > painful if we always did that. > > [1]: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZG3SNLFS7BSXQ3JFJDOWUS3WWGTGLR2/ I think that's not actually true: If we do not build from source, it doesn't matter if the compiler produces a working executable program from the old sources. Apart from the build-from-source principle, there are other advantages. It may be easier to adopt new architectures and toolchain versions. Thanks, Florian ___ 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
Re: What do we think about always autoreconfing?
On Tue, 2021-04-13 at 08:33 -0400, Neal Gompa wrote: > On Tue, Apr 13, 2021 at 8:24 AM Florian Weimer > wrote: > > * Richard W. M. Jones: > > > > > Hijacking this thread originally about > > > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > > > > > What is the current thinking in Fedora about always running > > > "autoreconf -i" during builds that use autotools? > > > > I would prefer to do it because it aligns with Fedora's goal to > > build > > from sources. But I expect it to be quite a bit of work. Maybe > > not for > > each package on its own, but certainly across the entire > > distribution. > > > > I'd advocate for that as well. It brings us in-line with other build > scripts and guarantees that everything actually works. I'd advocate for that also, just add that sometimes we may have bootstrap or autogen.sh script in upstream source and IMO we should use it. For example: https://github.com/twaugh/patchutils/blob/master/bootstrap https://github.com/sergiomb2/ufraw/blob/master/autogen.sh > As I said previously[1], I think doing autoconf upgrades would be > less > painful if we always did that. > > [1]: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZG3SNLFS7BSXQ3JFJDOWUS3WWGTGLR2/ > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > 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 -- Sérgio M. B. ___ 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
Re: What do we think about always autoreconfing?
On Tue, Apr 13, 2021 at 02:24:20PM +0200, Florian Weimer wrote: > * Richard W. M. Jones: > > > Hijacking this thread originally about > > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > > > What is the current thinking in Fedora about always running > > "autoreconf -i" during builds that use autotools? > > I would prefer to do it because it aligns with Fedora's goal to build > from sources. But I expect it to be quite a bit of work. Maybe not for > each package on its own, but certainly across the entire distribution. (I believe ...) For Debian it's a recommendation rather than a requirement. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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
Re: What do we think about always autoreconfing?
On Tue, Apr 13, 2021 at 8:24 AM Florian Weimer wrote: > > * Richard W. M. Jones: > > > Hijacking this thread originally about > > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > > > What is the current thinking in Fedora about always running > > "autoreconf -i" during builds that use autotools? > > I would prefer to do it because it aligns with Fedora's goal to build > from sources. But I expect it to be quite a bit of work. Maybe not for > each package on its own, but certainly across the entire distribution. > I'd advocate for that as well. It brings us in-line with other build scripts and guarantees that everything actually works. As I said previously[1], I think doing autoconf upgrades would be less painful if we always did that. [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZG3SNLFS7BSXQ3JFJDOWUS3WWGTGLR2/ -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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
Re: What do we think about always autoreconfing?
* Richard W. M. Jones: > Hijacking this thread originally about > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > What is the current thinking in Fedora about always running > "autoreconf -i" during builds that use autotools? I would prefer to do it because it aligns with Fedora's goal to build from sources. But I expect it to be quite a bit of work. Maybe not for each package on its own, but certainly across the entire distribution. Thanks, Florian ___ 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
Re: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On Tue, 13 Apr 2021 at 11:27, Richard W.M. Jones wrote: > Hijacking this thread originally about > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > What is the current thinking in Fedora about always running > "autoreconf -i" during builds that use autotools? > 1) "autoreconf -i" is not enough. It needs to be executed "autoreconf -fi" and to have proper visibility reconfigure issues should be executed "autoreconf -fiv" 2) Looks like still no one performed experiment of rebuilding all existing packages with %configure macro in spec by execute: $ for i in *.src.rpm; do rpmbuild --rebuild -D "_configure 'autoreconf -fiv; configure'" $i; done To check which Fedora packages are failing in the build environment with autoconf 2.71. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > > ___ 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
Re: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On 4/13/21 12:26 PM, Richard W.M. Jones wrote: Hijacking this thread originally about https://fedoraproject.org/wiki/Changes/Autoconf_271 What is the current thinking in Fedora about always running "autoreconf -i" during builds that use autotools? IMO, it's naive wishful thinking, applicable to trivial packages. Most non-trivial packages require specific versions. Also, in general, it's not advisable to regenerate auto*tools generated sources at all. I am aware, this thought has become unpopular, because the autotools have been mostly "dormant" in recent years, so people are not used to face such problems, anymore. In Debian it's been recommended for a long time: https://wiki.debian.org/Autoreconf Well, ... Debian's mistake. It also could fail - I noticed that autoconf 2.71 has several incompatibilities with the most widely used autoconf (2.69). This is only the tip of the proverbial "iceberg". autoconf > 2.69 is pretty imcompatible and bugged. Ralf ___ 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
What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
Hijacking this thread originally about
https://fedoraproject.org/wiki/Changes/Autoconf_271
What is the current thinking in Fedora about always running
"autoreconf -i" during builds that use autotools?
In Debian it's been recommended for a long time:
https://wiki.debian.org/Autoreconf
I maintain a few packages where I attempt to toggle autoreconfing
based on whether patches touch build files. If a downstream patch is
applied which touches any of configure.ac, Makefile.am, or several
other files, then the build will attempt to run autoconf/automake and
usually fail. These packages have:
# If there are patches which touch autotools files, set this to 1.
%global patches_touch_autotools %{nil}
%if 0%{patches_touch_autotools}
BuildRequires: autoconf, automake, libtool
%endif
%prep
...
%if 0%{patches_touch_autotools}
autoreconf -i
%endif
This is a kind of optimal solution, but also hard to get right - I
often find myself forgetting to set the %global correctly after
applying or removing downstream patches.
The cons of always autoreconfing are that it slows down builds,
sometimes considerably. It also could fail - I noticed that autoconf
2.71 has several incompatibilities with the most widely used autoconf
(2.69).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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
