Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

HEADS_UP:

The Change of autoconf to version 2.71 is built and done. F36FTBFS bugs are
created [1] for failed builds of packages. Most of them are caused by minor
issues and not merged pull-requests of fixes regarding autoconf-2.71
change. Hopefully have this done in a short time.

Thanks for cooperation!

Ondrej

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1999424

On Mon, Aug 30, 2021 at 5:32 PM Fabio Valentini 
wrote:

> On Mon, Aug 30, 2021 at 5:29 PM Miro Hrončok  wrote:
> >
> > On 30. 08. 21 17:02, Fabio Valentini wrote:
> > > On Mon, Aug 30, 2021 at 11:49 AM Ondrej Dubaj 
> wrote:
> > >>
> > >> HEADS-UP:
> > >>
> > >> autoconf-2.71 is merged and built in Fedora rawhide together with the
> rest of autotools: automake-1.16-4.1 and libtool-2.4.6-43.
> > >>
> > >> In the next few days, scratch-build for each dependent package will
> be executed and failed packages F36FTBFS trackers will be created.
> > >>
> > >> Thank you all for your cooperation! Hopefully we will manage to bring
> this change to the end.
> > >
> > > Thanks for working on this!
> > >
> > > I wonder why you'll only submit test scratch builds of dependent
> > > packages, instead of "real" rebuilds for autoconf 2.71?
> >
> > That was my advice to Ondrej.
> >
> > My reasoning was that the real rebuild adds no value here, except it
> generates
> > meaningless updates for rawhide users.
>
> Ah, yeah that makes sense, since this change should only affect the
> build itself. Thanks for the explanation.
>
> Fabio
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Fabio Valentini]

On Mon, Aug 30, 2021 at 5:29 PM Miro Hrončok  wrote:
>
> On 30. 08. 21 17:02, Fabio Valentini wrote:
> > On Mon, Aug 30, 2021 at 11:49 AM Ondrej Dubaj  wrote:
> >>
> >> HEADS-UP:
> >>
> >> autoconf-2.71 is merged and built in Fedora rawhide together with the rest 
> >> of autotools: automake-1.16-4.1 and libtool-2.4.6-43.
> >>
> >> In the next few days, scratch-build for each dependent package will be 
> >> executed and failed packages F36FTBFS trackers will be created.
> >>
> >> Thank you all for your cooperation! Hopefully we will manage to bring this 
> >> change to the end.
> >
> > Thanks for working on this!
> >
> > I wonder why you'll only submit test scratch builds of dependent
> > packages, instead of "real" rebuilds for autoconf 2.71?
>
> That was my advice to Ondrej.
>
> My reasoning was that the real rebuild adds no value here, except it generates
> meaningless updates for rawhide users.

Ah, yeah that makes sense, since this change should only affect the
build itself. Thanks for the explanation.

Fabio
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Miro Hrončok]

On 30. 08. 21 17:02, Fabio Valentini wrote:

On Mon, Aug 30, 2021 at 11:49 AM Ondrej Dubaj  wrote:


HEADS-UP:

autoconf-2.71 is merged and built in Fedora rawhide together with the rest of 
autotools: automake-1.16-4.1 and libtool-2.4.6-43.

In the next few days, scratch-build for each dependent package will be executed 
and failed packages F36FTBFS trackers will be created.

Thank you all for your cooperation! Hopefully we will manage to bring this 
change to the end.


Thanks for working on this!

I wonder why you'll only submit test scratch builds of dependent
packages, instead of "real" rebuilds for autoconf 2.71?


That was my advice to Ondrej.

My reasoning was that the real rebuild adds no value here, except it generates 
meaningless updates for rawhide users.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Fabio Valentini]

On Mon, Aug 30, 2021 at 11:49 AM Ondrej Dubaj  wrote:
>
> HEADS-UP:
>
> autoconf-2.71 is merged and built in Fedora rawhide together with the rest of 
> autotools: automake-1.16-4.1 and libtool-2.4.6-43.
>
> In the next few days, scratch-build for each dependent package will be 
> executed and failed packages F36FTBFS trackers will be created.
>
> Thank you all for your cooperation! Hopefully we will manage to bring this 
> change to the end.

Thanks for working on this!

I wonder why you'll only submit test scratch builds of dependent
packages, instead of "real" rebuilds for autoconf 2.71?

Fabio
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

HEADS-UP:

autoconf-2.71 is merged and built in Fedora rawhide together with the rest
of autotools: automake-1.16-4.1 and libtool-2.4.6-43.

In the next few days, scratch-build for each dependent package will be
executed and failed packages F36FTBFS trackers will be created.

Thank you all for your cooperation! Hopefully we will manage to bring this
change to the end.

Ondrej

On Mon, Aug 30, 2021 at 10:45 AM Ian Kent  wrote:

> On Mon, 2021-08-30 at 07:55 +0200, Ondrej Dubaj wrote:
> > Hi,
> >
> > Thank you for the update Ian. It was not meant the way every packager
> > is ignoring the opened issues, we appreciate your work on this
> > autoconf-2.71 issue. Sorry for generalizing this.
>
> And my comment was not meant to sound negative, getting an update
> like this done is very challenging, to say the least, hopefully
> everything will go well, ;)
>
> Truth is I would have liked to get it done earlier but was unable
> to, at least I have managed to get it done now.
>
> >
> > Glad to hear that it will build OK today.
> >
> > HEADS-UP:
> >
> > Starting with merging autoconf-2.71 changes. This week a scratch-
> > build for all dependent packages will be executed. If you want to
> > test your packages by yourself, you can execute your own scratch-
> > build and see if it works properly. I will write here when autoconf-
> > 2.71 will be stable.
> >
> > Thanks for your cooperation and hope to see very few failures this
> > week :)
> >
> > Regards,
> > Ondrej
> >
> > On Fri, Aug 27, 2021 at 2:36 PM Ian Kent  wrote:
> > > On Tue, 2021-08-24 at 10:53 +0200, Ondrej Dubaj wrote:
> > > > Hello,
> > > >
> > > > In the near future, there is a plan to merge autoconf-2.71 to
> > > > rawhide. Due to the size of the change and possible breakage of
> > > > multiple packages going FTBFS. The number of these packages
> > > > should
> > > > not be many, currently we have ~32 opened FTBFS trackers
> > > > according
> > > to
> > > > autoconf-2.71, where the majority of them are just ignored by
> > > > maintainers [1]. This can also be a possibility to remove
> > > unnecessary
> > > > packages from Fedora. After merging the change, there should be a
> > > > mechanism for validating. From my perspective, it is effective to
> > > > rebuild dependent packages (~1700 packages). After the rebuild,
> > > there
> > > > should not be many FTBFS packages, but according to the change
> > > there
> > > > will be some. There was enough time (~6 months) for the
> > > > maintainers
> > > > to prepare for this change.
> > >
> > > Not everyone is ignoring the bugs I have been working on the am-
> > > utils
> > > package for this.
> > >
> > > The package is very old and it utilizes autoconf very heavily.
> > > Most of the autoconf noise is use of obsolete macros and I have
> > > updated
> > > this were I can but there are some things I simply can't fix and
> > > some
> > > things that shouldn't be changed.
> > >
> > > I'll keep coming back to it over time since the changes I have made
> > > or
> > > (rather will be committing over the weekend) do allow the package
> > > to
> > > build and function on F33 and build in the Copr updated autoconf
> > > environment.
> > >
> > > I expect it will build ok on Monday.
> > >
> > > >
> > > > If there are any concerns or other opinions about the steps after
> > > > merging the change, please share your thoughts and we can discuss
> > > > them here.
> > > >
> > > > Thanks very much!
> > > >
> > > > Regards,
> > > > Ondrej
> > > >
> > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967
> > > >
> > > > On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj 
> > > > wrote:
> > > > > Hello, according to the size of this change and the possible
> > > > > breakage of multiple packages before f35 mass rebuild, we
> > > > > decided
> > > > > (team working on this change) to postpone this change to early
> > > > > lifecycle of f36, where we will have enough time to resolve any
> > > > > problems until f36 mass rebuild.
> > > > >
> > > > > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi 
> > > wrote:
> > > > > > On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
> > > > > > > Currently, we are trying to stay away from the compat
> > > > > > > package
> > > > > > > and
> > > > > > with the
> > > > > > > help of other package maintainers trying to fix the
> > > > > > > failures.
> > > > > > > We
> > > > > > will give
> > > > > > > time to react accordingly and see other possible steps in a
> > > few
> > > > > > weeks time.
> > > > > > >
> > > > > > > Currently multiple FTBFS bugs in bugzilla were created
> > > > > > > according
> > > > > > to
> > > > > > > autoconf-2.71. More information available here:
> > > > > > >
> > > > > > > https://fedoraproject.org/wiki/Changes/Autoconf_271
> > > > > >
> > > > > > Whats the current status of this Change?
> > > > > >
> > > > > > It didn't land before mass rebuild. Is it still planned for
> > > f35?
> > > > > >
> > > > > > kevin
> > > > > > 

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ian Kent]

On Mon, 2021-08-30 at 07:55 +0200, Ondrej Dubaj wrote:
> Hi,
> 
> Thank you for the update Ian. It was not meant the way every packager
> is ignoring the opened issues, we appreciate your work on this
> autoconf-2.71 issue. Sorry for generalizing this.

And my comment was not meant to sound negative, getting an update
like this done is very challenging, to say the least, hopefully
everything will go well, ;)

Truth is I would have liked to get it done earlier but was unable
to, at least I have managed to get it done now.

> 
> Glad to hear that it will build OK today.
> 
> HEADS-UP:
> 
> Starting with merging autoconf-2.71 changes. This week a scratch-
> build for all dependent packages will be executed. If you want to
> test your packages by yourself, you can execute your own scratch-
> build and see if it works properly. I will write here when autoconf-
> 2.71 will be stable.
> 
> Thanks for your cooperation and hope to see very few failures this
> week :)
> 
> Regards,
> Ondrej
> 
> On Fri, Aug 27, 2021 at 2:36 PM Ian Kent  wrote:
> > On Tue, 2021-08-24 at 10:53 +0200, Ondrej Dubaj wrote:
> > > Hello,
> > > 
> > > In the near future, there is a plan to merge autoconf-2.71 to
> > > rawhide. Due to the size of the change and possible breakage of
> > > multiple packages going FTBFS. The number of these packages
> > > should
> > > not be many, currently we have ~32 opened FTBFS trackers
> > > according
> > to
> > > autoconf-2.71, where the majority of them are just ignored by
> > > maintainers [1]. This can also be a possibility to remove
> > unnecessary
> > > packages from Fedora. After merging the change, there should be a
> > > mechanism for validating. From my perspective, it is effective to
> > > rebuild dependent packages (~1700 packages). After the rebuild,
> > there
> > > should not be many FTBFS packages, but according to the change
> > there
> > > will be some. There was enough time (~6 months) for the
> > > maintainers
> > > to prepare for this change. 
> > 
> > Not everyone is ignoring the bugs I have been working on the am-
> > utils
> > package for this.
> > 
> > The package is very old and it utilizes autoconf very heavily.
> > Most of the autoconf noise is use of obsolete macros and I have
> > updated
> > this were I can but there are some things I simply can't fix and
> > some
> > things that shouldn't be changed.
> > 
> > I'll keep coming back to it over time since the changes I have made
> > or
> > (rather will be committing over the weekend) do allow the package
> > to
> > build and function on F33 and build in the Copr updated autoconf
> > environment.
> > 
> > I expect it will build ok on Monday.
> > 
> > > 
> > > If there are any concerns or other opinions about the steps after
> > > merging the change, please share your thoughts and we can discuss
> > > them here.
> > > 
> > > Thanks very much!
> > > 
> > > Regards,
> > > Ondrej
> > > 
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967
> > > 
> > > On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj 
> > > wrote:
> > > > Hello, according to the size of this change and the possible
> > > > breakage of multiple packages before f35 mass rebuild, we
> > > > decided
> > > > (team working on this change) to postpone this change to early
> > > > lifecycle of f36, where we will have enough time to resolve any
> > > > problems until f36 mass rebuild.
> > > > 
> > > > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi 
> > wrote:
> > > > > On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
> > > > > > Currently, we are trying to stay away from the compat
> > > > > > package
> > > > > > and
> > > > > with the
> > > > > > help of other package maintainers trying to fix the
> > > > > > failures.
> > > > > > We
> > > > > will give
> > > > > > time to react accordingly and see other possible steps in a
> > few
> > > > > weeks time.
> > > > > > 
> > > > > > Currently multiple FTBFS bugs in bugzilla were created
> > > > > > according
> > > > > to
> > > > > > autoconf-2.71. More information available here:
> > > > > > 
> > > > > > https://fedoraproject.org/wiki/Changes/Autoconf_271
> > > > > 
> > > > > Whats the current status of this Change?
> > > > > 
> > > > > It didn't land before mass rebuild. Is it still planned for
> > f35?
> > > > > 
> > > > > kevin
> > > > > ___
> > > > > 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 

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Hi,

Thank you for the update Ian. It was not meant the way every packager is
ignoring the opened issues, we appreciate your work on this autoconf-2.71
issue. Sorry for generalizing this.

Glad to hear that it will build OK today.

HEADS-UP:

Starting with merging autoconf-2.71 changes. This week a scratch-build for
all dependent packages will be executed. If you want to test your packages
by yourself, you can execute your own scratch-build and see if it works
properly. I will write here when autoconf-2.71 will be stable.

Thanks for your cooperation and hope to see very few failures this week :)

Regards,
Ondrej

On Fri, Aug 27, 2021 at 2:36 PM Ian Kent  wrote:

> On Tue, 2021-08-24 at 10:53 +0200, Ondrej Dubaj wrote:
> > Hello,
> >
> > In the near future, there is a plan to merge autoconf-2.71 to
> > rawhide. Due to the size of the change and possible breakage of
> > multiple packages going FTBFS. The number of these packages should
> > not be many, currently we have ~32 opened FTBFS trackers according to
> > autoconf-2.71, where the majority of them are just ignored by
> > maintainers [1]. This can also be a possibility to remove unnecessary
> > packages from Fedora. After merging the change, there should be a
> > mechanism for validating. From my perspective, it is effective to
> > rebuild dependent packages (~1700 packages). After the rebuild, there
> > should not be many FTBFS packages, but according to the change there
> > will be some. There was enough time (~6 months) for the maintainers
> > to prepare for this change.
>
> Not everyone is ignoring the bugs I have been working on the am-utils
> package for this.
>
> The package is very old and it utilizes autoconf very heavily.
> Most of the autoconf noise is use of obsolete macros and I have updated
> this were I can but there are some things I simply can't fix and some
> things that shouldn't be changed.
>
> I'll keep coming back to it over time since the changes I have made or
> (rather will be committing over the weekend) do allow the package to
> build and function on F33 and build in the Copr updated autoconf
> environment.
>
> I expect it will build ok on Monday.
>
> >
> > If there are any concerns or other opinions about the steps after
> > merging the change, please share your thoughts and we can discuss
> > them here.
> >
> > Thanks very much!
> >
> > Regards,
> > Ondrej
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967
> >
> > On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj 
> > wrote:
> > > Hello, according to the size of this change and the possible
> > > breakage of multiple packages before f35 mass rebuild, we decided
> > > (team working on this change) to postpone this change to early
> > > lifecycle of f36, where we will have enough time to resolve any
> > > problems until f36 mass rebuild.
> > >
> > > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi  wrote:
> > > > On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
> > > > > Currently, we are trying to stay away from the compat package
> > > > > and
> > > > with the
> > > > > help of other package maintainers trying to fix the failures.
> > > > > We
> > > > will give
> > > > > time to react accordingly and see other possible steps in a few
> > > > weeks time.
> > > > >
> > > > > Currently multiple FTBFS bugs in bugzilla were created
> > > > > according
> > > > to
> > > > > autoconf-2.71. More information available here:
> > > > >
> > > > > https://fedoraproject.org/wiki/Changes/Autoconf_271
> > > >
> > > > Whats the current status of this Change?
> > > >
> > > > It didn't land before mass rebuild. Is it still planned for f35?
> > > >
> > > > kevin
> > > > ___
> > > > 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
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of 

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ian Kent]

On Tue, 2021-08-24 at 10:53 +0200, Ondrej Dubaj wrote:
> Hello,
> 
> In the near future, there is a plan to merge autoconf-2.71 to
> rawhide. Due to the size of the change and possible breakage of
> multiple packages going FTBFS. The number of these packages should
> not be many, currently we have ~32 opened FTBFS trackers according to
> autoconf-2.71, where the majority of them are just ignored by
> maintainers [1]. This can also be a possibility to remove unnecessary
> packages from Fedora. After merging the change, there should be a
> mechanism for validating. From my perspective, it is effective to
> rebuild dependent packages (~1700 packages). After the rebuild, there
> should not be many FTBFS packages, but according to the change there
> will be some. There was enough time (~6 months) for the maintainers
> to prepare for this change. 

Not everyone is ignoring the bugs I have been working on the am-utils
package for this.

The package is very old and it utilizes autoconf very heavily.
Most of the autoconf noise is use of obsolete macros and I have updated
this were I can but there are some things I simply can't fix and some
things that shouldn't be changed.

I'll keep coming back to it over time since the changes I have made or
(rather will be committing over the weekend) do allow the package to
build and function on F33 and build in the Copr updated autoconf
environment.

I expect it will build ok on Monday.

> 
> If there are any concerns or other opinions about the steps after
> merging the change, please share your thoughts and we can discuss
> them here.
> 
> Thanks very much!
> 
> Regards,
> Ondrej
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967
> 
> On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj 
> wrote:
> > Hello, according to the size of this change and the possible
> > breakage of multiple packages before f35 mass rebuild, we decided
> > (team working on this change) to postpone this change to early
> > lifecycle of f36, where we will have enough time to resolve any
> > problems until f36 mass rebuild.
> > 
> > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi  wrote:
> > > On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
> > > > Currently, we are trying to stay away from the compat package
> > > > and
> > > with the
> > > > help of other package maintainers trying to fix the failures.
> > > > We
> > > will give
> > > > time to react accordingly and see other possible steps in a few
> > > weeks time.
> > > > 
> > > > Currently multiple FTBFS bugs in bugzilla were created
> > > > according
> > > to
> > > > autoconf-2.71. More information available here:
> > > > 
> > > > https://fedoraproject.org/wiki/Changes/Autoconf_271
> > > 
> > > Whats the current status of this Change?
> > > 
> > > It didn't land before mass rebuild. Is it still planned for f35?
> > > 
> > > kevin
> > > ___
> > > 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

___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Hello,

maybe the bug was not closed by the maintainer, as grep seems to be
building properly

https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/package/grep/

Ondrej

On Fri, Aug 27, 2021 at 8:10 AM Ondrej Dubaj  wrote:

> Thanks, I'll look at it.
>
> Ondrej
>
> On Thu, Aug 26, 2021 at 5:19 PM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Thu, Aug 26, 2021 at 02:39:13PM +0200, Ondrej Dubaj wrote:
>> > Hi,
>> >
>> > thanks for your reply, there should not be any packages on critical
>> path,
>> > which are not building currently.
>>
>> I see grep on the list:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1943083
>> We should probably fix that quickly.
>>
>> Zbyszek
>> ___
>> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Thanks, I'll look at it.

Ondrej

On Thu, Aug 26, 2021 at 5:19 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Thu, Aug 26, 2021 at 02:39:13PM +0200, Ondrej Dubaj wrote:
> > Hi,
> >
> > thanks for your reply, there should not be any packages on critical path,
> > which are not building currently.
>
> I see grep on the list:
> https://bugzilla.redhat.com/show_bug.cgi?id=1943083
> We should probably fix that quickly.
>
> Zbyszek
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 26, 2021 at 02:39:13PM +0200, Ondrej Dubaj wrote:
> Hi,
> 
> thanks for your reply, there should not be any packages on critical path,
> which are not building currently.

I see grep on the list: https://bugzilla.redhat.com/show_bug.cgi?id=1943083
We should probably fix that quickly.

Zbyszek
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Hi,

thanks for your reply, there should not be any packages on critical path,
which are not building currently.

HEADS-UP:
The plan for merging autoconf-2.71 to rawhide is Monday (30th Aug 2021), if
no issues will come up. After that, there is no need to do a regular build
of dependent packages, but we will schedule a scratch-build, which should
be enough to test, if everything works as expected. According to results of
these scratch-builds, F36FTBFS trackers in bugzilla will be created for
each failed package.

I will send a message to this thread after merging and building
autoconf-2.71, to make things clear.

Thanks.

Ondrej

On Wed, Aug 25, 2021 at 7:59 PM Kevin Fenzi  wrote:

> On Tue, Aug 24, 2021 at 10:53:15AM +0200, Ondrej Dubaj wrote:
> > Hello,
> >
> > In the near future, there is a plan to merge autoconf-2.71 to rawhide.
> Due
> > to the size of the change and possible breakage of multiple packages
> going
> > FTBFS. The number of these packages should not be many, currently we have
> > ~32 opened FTBFS trackers according to autoconf-2.71, where the majority
> of
> > them are just ignored by maintainers [1]. This can also be a possibility
> to
> > remove unnecessary packages from Fedora. After merging the change, there
>
> Are any of these on the critical path (ie would cause composes to fail?)
> I don't see any off hand, but if so, I would get those fixed before
> landing if you can at all. Otherwise I would say land as soon as you
> like.
>
> > should be a mechanism for validating. From my perspective, it is
> effective
> > to rebuild dependent packages (~1700 packages). After the rebuild, there
> > should not be many FTBFS packages, but according to the change there will
> > be some. There was enough time (~6 months) for the maintainers to prepare
> > for this change.
> >
> > If there are any concerns or other opinions about the steps after merging
> > the change, please share your thoughts and we can discuss them here.
>
> Thanks for all this work, it's appreciated. ;)
>
> > Thanks very much!
> >
> > Regards,
> > Ondrej
>
> kevin
> --
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967
> >
> > On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj  wrote:
> >
> > > Hello, according to the size of this change and the possible breakage
> of multiple packages before f35 mass rebuild, we decided (team working on
> this change) to postpone this change to early lifecycle of f36, where we
> will have enough time to resolve any problems until f36 mass rebuild.
> > >
> > >
> > > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi  wrote:
> > >
> > >> On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
> > >> > Currently, we are trying to stay away from the compat package and
> with
> > >> the
> > >> > help of other package maintainers trying to fix the failures. We
> will
> > >> give
> > >> > time to react accordingly and see other possible steps in a few
> weeks
> > >> time.
> > >> >
> > >> > Currently multiple FTBFS bugs in bugzilla were created according to
> > >> > autoconf-2.71. More information available here:
> > >> >
> > >> > https://fedoraproject.org/wiki/Changes/Autoconf_271
> > >>
> > >> Whats the current status of this Change?
> > >>
> > >> It didn't land before mass rebuild. Is it still planned for f35?
> > >>
> > >> kevin
> > >> ___
> > >> 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
>
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Kevin Fenzi]

On Tue, Aug 24, 2021 at 10:53:15AM +0200, Ondrej Dubaj wrote:
> Hello,
> 
> In the near future, there is a plan to merge autoconf-2.71 to rawhide. Due
> to the size of the change and possible breakage of multiple packages going
> FTBFS. The number of these packages should not be many, currently we have
> ~32 opened FTBFS trackers according to autoconf-2.71, where the majority of
> them are just ignored by maintainers [1]. This can also be a possibility to
> remove unnecessary packages from Fedora. After merging the change, there

Are any of these on the critical path (ie would cause composes to fail?)
I don't see any off hand, but if so, I would get those fixed before
landing if you can at all. Otherwise I would say land as soon as you
like.

> should be a mechanism for validating. From my perspective, it is effective
> to rebuild dependent packages (~1700 packages). After the rebuild, there
> should not be many FTBFS packages, but according to the change there will
> be some. There was enough time (~6 months) for the maintainers to prepare
> for this change.
> 
> If there are any concerns or other opinions about the steps after merging
> the change, please share your thoughts and we can discuss them here.

Thanks for all this work, it's appreciated. ;) 

> Thanks very much!
> 
> Regards,
> Ondrej

kevin
--
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967
> 
> On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj  wrote:
> 
> > Hello, according to the size of this change and the possible breakage of 
> > multiple packages before f35 mass rebuild, we decided (team working on this 
> > change) to postpone this change to early lifecycle of f36, where we will 
> > have enough time to resolve any problems until f36 mass rebuild.
> >
> >
> > On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi  wrote:
> >
> >> On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
> >> > Currently, we are trying to stay away from the compat package and with
> >> the
> >> > help of other package maintainers trying to fix the failures. We will
> >> give
> >> > time to react accordingly and see other possible steps in a few weeks
> >> time.
> >> >
> >> > Currently multiple FTBFS bugs in bugzilla were created according to
> >> > autoconf-2.71. More information available here:
> >> >
> >> > https://fedoraproject.org/wiki/Changes/Autoconf_271
> >>
> >> Whats the current status of this Change?
> >>
> >> It didn't land before mass rebuild. Is it still planned for f35?
> >>
> >> kevin
> >> ___
> >> 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



signature.asc
Description: PGP signature
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Hello,

In the near future, there is a plan to merge autoconf-2.71 to rawhide. Due
to the size of the change and possible breakage of multiple packages going
FTBFS. The number of these packages should not be many, currently we have
~32 opened FTBFS trackers according to autoconf-2.71, where the majority of
them are just ignored by maintainers [1]. This can also be a possibility to
remove unnecessary packages from Fedora. After merging the change, there
should be a mechanism for validating. From my perspective, it is effective
to rebuild dependent packages (~1700 packages). After the rebuild, there
should not be many FTBFS packages, but according to the change there will
be some. There was enough time (~6 months) for the maintainers to prepare
for this change.

If there are any concerns or other opinions about the steps after merging
the change, please share your thoughts and we can discuss them here.

Thanks very much!

Regards,
Ondrej

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1942967

On Mon, Aug 16, 2021 at 7:52 AM Ondrej Dubaj  wrote:

> Hello, according to the size of this change and the possible breakage of 
> multiple packages before f35 mass rebuild, we decided (team working on this 
> change) to postpone this change to early lifecycle of f36, where we will have 
> enough time to resolve any problems until f36 mass rebuild.
>
>
> On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi  wrote:
>
>> On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
>> > Currently, we are trying to stay away from the compat package and with
>> the
>> > help of other package maintainers trying to fix the failures. We will
>> give
>> > time to react accordingly and see other possible steps in a few weeks
>> time.
>> >
>> > Currently multiple FTBFS bugs in bugzilla were created according to
>> > autoconf-2.71. More information available here:
>> >
>> > https://fedoraproject.org/wiki/Changes/Autoconf_271
>>
>> Whats the current status of this Change?
>>
>> It didn't land before mass rebuild. Is it still planned for f35?
>>
>> kevin
>> ___
>> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Hello, according to the size of this change and the possible breakage
of multiple packages before f35 mass rebuild, we decided (team working
on this change) to postpone this change to early lifecycle of f36,
where we will have enough time to resolve any problems until f36 mass
rebuild.


On Mon, Aug 2, 2021 at 5:18 PM Kevin Fenzi  wrote:

> On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
> > Currently, we are trying to stay away from the compat package and with
> the
> > help of other package maintainers trying to fix the failures. We will
> give
> > time to react accordingly and see other possible steps in a few weeks
> time.
> >
> > Currently multiple FTBFS bugs in bugzilla were created according to
> > autoconf-2.71. More information available here:
> >
> > https://fedoraproject.org/wiki/Changes/Autoconf_271
>
> Whats the current status of this Change?
>
> It didn't land before mass rebuild. Is it still planned for f35?
>
> kevin
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Kevin Fenzi]

On Thu, Mar 25, 2021 at 05:28:07PM +0100, Ondrej Dubaj wrote:
> Currently, we are trying to stay away from the compat package and with the
> help of other package maintainers trying to fix the failures. We will give
> time to react accordingly and see other possible steps in a few weeks time.
> 
> Currently multiple FTBFS bugs in bugzilla were created according to
> autoconf-2.71. More information available here:
> 
> https://fedoraproject.org/wiki/Changes/Autoconf_271

Whats the current status of this Change?

It didn't land before mass rebuild. Is it still planned for f35?

kevin


signature.asc
Description: PGP signature
___
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: question was: What do we think about always autoreconfing? was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))

[Sérgio Basto]

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))

[Ondrej Dubaj]

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? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))

[David Cantrell]

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: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Sérgio Basto]

On Wed, 2021-04-14 at 12:58 +0200, Fabio Valentini wrote:
> On Wed, Apr 14, 2021 at 12:35 PM Sérgio Basto 
> wrote:
> > On Wed, 2021-04-14 at 12:29 +0200, Dominik 'Rathann' Mierzejewski
> > wrote:
> > > On Wednesday, 14 April 2021 at 11:57, Ondrej Dubaj wrote:
> > > > On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto <
> > > > ser...@serjux.com>
> > > > wrote:
> 
> [snip]
> 
> > > It is arguably better to add the new config to local user mock
> > > config
> > > only instead of system-wide. I.e. put the new config in
> > > $HOME/.config/mock .
> > 
> > how ? $HOME/.config/mock directory ?
> 
> Easiest solution: The "mock -r" accepts full paths to .cfg files, as
> well as the .cfg-suffix-less names derived from system-wide
> configuration files.
> So just put the file anywhere you like, and supply the full path to
> it
> (including .cfg suffix) to mock's "-r" argument.
> 
> e.g. "mock -r $HOME/Downloads/odubaj-autoconf-2.70_fedora-34-
> x86_64.cfg
> ./path-to.src.rpm"

ah, ok, Thank you. Indeed mock man page have a good documentation (1)
... 

so option 1:
mkdir $HOME/.config/mock
copr mock-config odubaj/autoconf-2.70 fedora-34-x86_64  > odubaj-
autoconf-2.70_fedora-34-x86_64.cfg
mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg $HOME/.config/mock/

option 2 :
copr mock-config odubaj/autoconf-2.70 fedora-34-x86_64  > odubaj-
autoconf-2.70_fedora-34-x86_64.cfg
mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64.cfg

(1)
-r CONFIG, --root=CONFIG
  Uses  specified chroot configuration as defined in
~/.config/mock/.cfg or /etc/mock/.cfg.  Optionally if
CONFIG ends in '.cfg',
  it is interpreted as full path to config file. If none
specified, uses the chroot config linked to by /etc/mock/default.cfg.

> Fabio
> ___
> 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: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Fabio Valentini]

On Wed, Apr 14, 2021 at 12:35 PM Sérgio Basto  wrote:
>
> On Wed, 2021-04-14 at 12:29 +0200, Dominik 'Rathann' Mierzejewski
> wrote:
> > On Wednesday, 14 April 2021 at 11:57, Ondrej Dubaj wrote:
> > > On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto 
> > > wrote:

[snip]

> > It is arguably better to add the new config to local user mock config
> > only instead of system-wide. I.e. put the new config in
> > $HOME/.config/mock .
>
> how ? $HOME/.config/mock directory ?

Easiest solution: The "mock -r" accepts full paths to .cfg files, as
well as the .cfg-suffix-less names derived from system-wide
configuration files.
So just put the file anywhere you like, and supply the full path to it
(including .cfg suffix) to mock's "-r" argument.

e.g. "mock -r $HOME/Downloads/odubaj-autoconf-2.70_fedora-34-x86_64.cfg
./path-to.src.rpm"

Fabio
___
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: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Sérgio Basto]

On Wed, 2021-04-14 at 12:29 +0200, Dominik 'Rathann' Mierzejewski
wrote:
> On Wednesday, 14 April 2021 at 11:57, Ondrej Dubaj wrote:
> > On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto 
> > wrote:
> > 
> > > https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test
> > > 
> > > As I think this is not trivial we should add to How_To_Test
> > > paragraph :
> > > 
> > > After:
> > > copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64  >
> > > odubaj-autoconf-2.70_fedora-34-x86_64.cfg
> > > mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg /etc/mock
> > > 
> > > we may run:
> > > mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild
> > > ufraw-0.23-0.11.20210413.fc35.src.rpm
> > 
> > Added, thanks!
> 
> It is arguably better to add the new config to local user mock config
> only instead of system-wide. I.e. put the new config in
> $HOME/.config/mock .

how ? $HOME/.config/mock directory ? 

> Regards,
> Dominik
> -- 
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess
> Irulan
> ___
> 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: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 14 April 2021 at 11:57, Ondrej Dubaj wrote:
> On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto  wrote:
> 
> > https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test
> >
> > As I think this is not trivial we should add to How_To_Test paragraph :
> >
> > After:
> > copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64  >
> > odubaj-autoconf-2.70_fedora-34-x86_64.cfg
> > mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg /etc/mock
> >
> > we may run:
> > mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild
> > ufraw-0.23-0.11.20210413.fc35.src.rpm
>
> Added, thanks!

It is arguably better to add the new config to local user mock config
only instead of system-wide. I.e. put the new config in $HOME/.config/mock .

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: #How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Added, thanks!

On Wed, Apr 14, 2021 at 11:43 AM Sérgio Basto  wrote:

> https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test
>
> As I think this is not trivial we should add to How_To_Test paragraph :
>
> After:
> copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64  >
> odubaj-autoconf-2.70_fedora-34-x86_64.cfg
> mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg /etc/mock
>
> we may run:
> mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild
> ufraw-0.23-0.11.20210413.fc35.src.rpm
>
> Than you
> --
> 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

#How_To_Test Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Sérgio Basto]

https://fedoraproject.org/wiki/Changes/Autoconf_271#How_To_Test

As I think this is not trivial we should add to How_To_Test paragraph :

After:
copr mock-config odubaj/autoconf-2.70 fedora-rawhide-x86_64  > 
odubaj-autoconf-2.70_fedora-34-x86_64.cfg
mv odubaj-autoconf-2.70_fedora-34-x86_64.cfg /etc/mock

we may run:
mock -r odubaj-autoconf-2.70_fedora-rawhide-x86_64 --rebuild 
ufraw-0.23-0.11.20210413.fc35.src.rpm 

Than you
-- 
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))

[Tomasz Kłoczko]

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))

[Ralf Corsepius]

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))

[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?

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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Currently, we are trying to stay away from the compat package and with the
help of other package maintainers trying to fix the failures. We will give
time to react accordingly and see other possible steps in a few weeks time.

Currently multiple FTBFS bugs in bugzilla were created according to
autoconf-2.71. More information available here:

https://fedoraproject.org/wiki/Changes/Autoconf_271

Ondrej

On Fri, Mar 19, 2021 at 5:59 PM Patrik Novotny  wrote:

> I'd advocate strongly against a compat package.
>
> The whole point of the change is to push the move to the new autoconf
> upstream release. Not the availability of autoconf 2.71 to the end user.
> For that, we would do much better with providing the end users with a
> modular release, I think.
>
> As for the argument of other distributions, Fedora has always been an
> early adopter. If we will create a compat package providing the 2.69
> version, what's the point of moving to autoconf 2.71 (maybe over providing
> a modular build) anyway?
>
> What I would argue is that we should make an effort to fully move to the
> new version of autoconf, and postpone the change if we find out that it is
> not doable in time for F35. Historically, it took some effort to mitigate
> providing compat packages of autoconf, and experience tells us that when we
> do, the motivation to fix packages incompatible with the new version
> virtually disappears.
>
> IMO, the only scenario, where a compat package would make sense, is if we
> were to push for the removal of this compat package right from the moment
> of it's introduction. In that case, the only real benefit of completing the
> Autoconf 2.71 change, would be *a little* easier process of making
> necessary changes to now incompatible packages in exchange for any real
> motivation to actually do so. If the point of this change is the
> availability of autoconf 2.71 to the end-user, I would argue that a modular
> build would be a much cleaner approach.
>
> We should push for this change to be done the proper way, not for the
> possibility of making a slow progress over long period of time for the
> price of duplicating packages. If we need more time for that, this change
> should be postponed.
>
> On Fri, Mar 12, 2021 at 4:27 PM Jonathan Wakely 
> wrote:
>
>> On 09/03/21 09:15 +, Tomasz Kłoczko wrote:
>> >Some time ago gcc, binutils IIRC received an update for ac 2.71 so at
>> least
>> >those two should be by now off-the-table (Am I right?).
>>
>> No. GCC has a hard requirement on autoconf-2.69, but the Fedora
>> package doesn't need to run autoconf for it (that happens when
>> upstream creates the snapshot tarball).
>>
>> I'm not sure about binutils, but I would be very surprised if it is
>> different from GCC.
>> ___
>> 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
>>
>
>
> --
> Patrik Novotný
> Associate Software Engineer
> Red Hat
> panov...@redhat.com
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Patrik Novotny]

I'd advocate strongly against a compat package.

The whole point of the change is to push the move to the new autoconf
upstream release. Not the availability of autoconf 2.71 to the end user.
For that, we would do much better with providing the end users with a
modular release, I think.

As for the argument of other distributions, Fedora has always been an early
adopter. If we will create a compat package providing the 2.69 version,
what's the point of moving to autoconf 2.71 (maybe over providing a modular
build) anyway?

What I would argue is that we should make an effort to fully move to the
new version of autoconf, and postpone the change if we find out that it is
not doable in time for F35. Historically, it took some effort to mitigate
providing compat packages of autoconf, and experience tells us that when we
do, the motivation to fix packages incompatible with the new version
virtually disappears.

IMO, the only scenario, where a compat package would make sense, is if we
were to push for the removal of this compat package right from the moment
of it's introduction. In that case, the only real benefit of completing the
Autoconf 2.71 change, would be *a little* easier process of making
necessary changes to now incompatible packages in exchange for any real
motivation to actually do so. If the point of this change is the
availability of autoconf 2.71 to the end-user, I would argue that a modular
build would be a much cleaner approach.

We should push for this change to be done the proper way, not for the
possibility of making a slow progress over long period of time for the
price of duplicating packages. If we need more time for that, this change
should be postponed.

On Fri, Mar 12, 2021 at 4:27 PM Jonathan Wakely 
wrote:

> On 09/03/21 09:15 +, Tomasz Kłoczko wrote:
> >Some time ago gcc, binutils IIRC received an update for ac 2.71 so at
> least
> >those two should be by now off-the-table (Am I right?).
>
> No. GCC has a hard requirement on autoconf-2.69, but the Fedora
> package doesn't need to run autoconf for it (that happens when
> upstream creates the snapshot tarball).
>
> I'm not sure about binutils, but I would be very surprised if it is
> different from GCC.
> ___
> 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
>


-- 
Patrik Novotný
Associate Software Engineer
Red Hat
panov...@redhat.com
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Jonathan Wakely]

On 09/03/21 09:15 +, Tomasz Kłoczko wrote:

Some time ago gcc, binutils IIRC received an update for ac 2.71 so at least
those two should be by now off-the-table (Am I right?).


No. GCC has a hard requirement on autoconf-2.69, but the Fedora
package doesn't need to run autoconf for it (that happens when
upstream creates the snapshot tarball).

I'm not sure about binutils, but I would be very surprised if it is
different from GCC.
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Kevin Kofler via devel]

Tomasz Kłoczko wrote:
> Issue is that sometimes people really don't want (first) to understand how
> to use the exact tool (it starts from something like "I'm not going to
> read anything because I want to just use it!!") or look at some already
> working examples (those cases are even worse :)).
> Those people prefer to discover how to use it without reading even a
> single line of necessary documentation.
> I know that .. because I'm one of those and here probably you can find
> much more such people :P

Well, in the case of autoconf, the main issue is that it is so hard to do 
basic things and the documentation is so hard to understand (yes, I have 
tried to actually read it and given up quickly) that only a handful people 
on this planet actually understand what is going on, the rest of us are 
stuck copying something that happens to work from somewhere, 
resulting in cargo-culted broken and/or deprecated snippets everywhere. And 
as a result, a compatibility break often affects not just one single 
package, but dozens that all copied the same boilerplate snippet.

> (most of the time [those new tools] are even worse like scon or waf)

I actually agree with you on that part. :-)

> IMO cmake is one tf he worst recent build tooling because it does not
> introduce good standards of some well known operations

Funny, because that's exactly the main issue I see with autotools. ;-) (See 
my point above about copied boilerplate snippets.)

> and only that opens widely all gates for sometimes freakishly
> implementations of doing NormalThings(tm).

Well, I have indeed seen some upstreams doing weird things with CMake, 
almost inventing their own build system on top of CMake. But that is not how 
CMake is intended to be used.

The main thing magic layers often do is handling bundled dependencies, which 
is NOT what I would call a NormalThing. ;-) (And the autotools do not 
natively handle that either, so I have actually seen magic layers on top of 
the autotools for the same reason.)

> And not only the new autoconf breaks updates of other packages.
> That is an immanent feature of all new versions of all software which
> interact with other software :P

Not necessarily. An upstream that cares about backwards compatibility breaks 
few to no dependent packages, and if it does break something, it is usually 
an accident and upstream will try to fix the regression. On the other hand, 
an upstream like autoconf that does not care causes a trainwreck and blames 
the dependent packages for it. I also complain about this issue when other 
dependencies (libraries, compilers, interpreters, etc.) do it.

> Nevertheless above part is completely off-topic from the subject
> introduction of the ac 2.71 in Fedora.
> 
> I can only repeat that instead of conserving current state and swiping
> some issues under the carpet by introduction of compat-autoconf-2.69 to
> deal with only a handful of packages with some ac 2.71 issues it would be
> better to form a list of those packages.
> Because the new f35 cycle just started now is the best moment to expose
> and sort out all those issues.

The question is, is it at all possible to fix all the affected packages? 
There are autotools-using packages that have not been updated upstream for 
eons, such as kdelibs3 (which is itself a compatibility library that is 
needed to keep applications working that have not been updated upstream for 
even longer).

If there are packages that cannot be made to build with autoconf 2.71, we 
need the compatibility package and we need it to stay.

Kevin Kofler
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[David Cantrell]

On Wed, Mar 03, 2021 at 01:51:42PM +0100, Miro Hrončok wrote:

On 03. 03. 21 13:47, Ondrej Dubaj wrote:



On Wed, Mar 3, 2021 at 1:33 PM Miro Hrončok > wrote:


   On 03. 03. 21 12:49, Ondrej Dubaj wrote:
> Compat package prepared.
>
> Package autoconf269-2.69-1 provides:
>
> /usr/bin/autoconf269
> /usr/bin/autoheader269
> /usr/bin/autom4te269
> /usr/bin/autoreconf269
> /usr/bin/autoscan269
> /usr/bin/autoupdate269
> /usr/bin/ifnames269
> ...
>
> Parallel installation successful.
>
> Any suggestions/concerns are welcome.

   My concerns are:

   1) Why 269 and not 2.69?

Just a naming convention, if needed can be easily changed


There is no need to complicate stuff by removing the dot. The naming 
convention for compat packages is to include the version:


https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple


Agreed, but we do already have precedent in this case with autoconf213
and autoconf268.

I would prefer the installed executable(s) carry a -2.69 suffix.  For
the package name I would say follow the convention we already have for
older autoconf packages.

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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Tomasz Kłoczko]

On Thu, 11 Mar 2021 at 12:04, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
[..]

> I really do not understand why so many upstreams are still using autotools.


Because ItWorks(tm)

A build system that fails so badly at backwards compatibility (This is not
> the first time autoconf has changed incompatibly!) is just a pain for
> everybody.


"Even in perfect language it is possible to write bad/buggy code".
Here is my latest example (only few days old) that proves that this
theorem/statement still holds against all odds ;)
https://github.com/ofiwg/libfabric/issues/6614

Issue is that sometimes people really don't want (first) to understand how
to use the exact tool (it starts from something like "I'm not going to read
anything because I want to just use it!!") or look at some already working
examples (those cases are even worse :)).
Those people prefer to discover how to use it without reading even a
single line of necessary documentation.
I know that .. because I'm one of those and here probably you can find much
more such people :P

That behaviour happens all the time and is older than our technical
civilisation :)
Better .. thanks to those "brave" people, some of them are able to invent
something completely new (because of the "traumatic" experience of using
something without learning it).
Funny (and scarry) thing is that sometimes those new tools are better than
old one :o)
(most of the time are even worse like scon or waf)
In other words it is hard to blame for that anyone here because from exact
angle even something so bad objectively is not 100% bad because time to
time *that pushes forward The Progress* :P

There are alternatives (such as CMake) that handle backwards
> compatibility in a much more graceful way. (In fact, the most incompatible
> CMake-related change so far was actually a change in the %cmake RPM macros
> and not in upstream CMake.) But autoconf still releases breaking updates.
>

IMO cmake is one tf he worst recent build tooling because it does not
introduce good standards of some well known operations and only that opens
widely all gates for sometimes freakishly implementations of doing
NormalThings(tm).
Working on sometimes a few hundreds packages each month most of the
problems on which I'm able accidentally  stump are related to cmake than
probably equally to ac/am/lt and meson. And yes .. some people already
started inventing OwnWays(tm) using meson 8-)

And not only the new autoconf breaks updates of other packages.
That is an immanent feature of all new versions of all software which
interact with other software :P

Nevertheless above part is completely off-topic from the subject
introduction of the ac 2.71 in Fedora.

I can only repeat that instead of conserving current state and swiping some
issues under the carpet by introduction of compat-autoconf-2.69 to deal
with only a handful of packages with some ac 2.71 issues it would be better
to form a list of those packages.
Because the new f35 cycle just started now is the best moment to expose and
sort out all those issues.

Again: IMO in a few days it is possible to properly identify all those
problematic packages by performing test builds with redefined over command
line single macro on all packages with "%configure" used in the spec file.
In this case we are talking about testing ~3.7k packages of all ~21.7k
Fedora packages.
After fixing all those issues it will be possible to close the coffin with
autoconf-2.69 and at least in f35 will have one package less ..

And at the end I would like only gently recall that still it is yet another
(sub)subject of even older autoconf still used by firefox & co :P
Who wants to grind that? :P

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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Kevin Kofler via devel]

Tomasz Kłoczko wrote:
> Really .. instead wasting time on packaging stuff which is ~7 years old it
> would be better to use that time to fix one of those handful packages
> which are still not ac 2.71 compliant

So autoconf upstream dropped 7 years (!) of incompatible changes at us in 
one single update, and you expect all packages in Fedora to instantly adapt 
to this major change (disguised in a minor version number bump, because 
autotools are notorious for their completely non-semantic versioning)?

I really do not understand why so many upstreams are still using autotools. 
A build system that fails so badly at backwards compatibility (This is not 
the first time autoconf has changed incompatibly!) is just a pain for 
everybody. There are alternatives (such as CMake) that handle backwards 
compatibility in a much more graceful way. (In fact, the most incompatible 
CMake-related change so far was actually a change in the %cmake RPM macros 
and not in upstream CMake.) But autoconf still releases breaking updates.

Kevin Kofler
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Neal Gompa]

On Thu, Mar 11, 2021 at 3:26 AM Ondrej Dubaj  wrote:
>
> Thanks for your advice. Already contacted maintainers of redhat-rpm-config to 
> discuss adding the appropriate command and see what their response is.
>

So are we coming back to the idea of (re)adding an %GNUconfigure or
%autoreconfigure macro that regenerates the autofoo *and* runs
configure?

RPM dropped %GNUconfigure back in 2016[1] because the macro had been
broken for years, nobody used it, and there was no interest in making
Autotools builds always regenerate their scripts in Fedora or openSUSE
like other distros do.

I think a good chunk of this pain could have been avoided if we always
mandated the autotools scripts need to be regenerated like PLD and
Debian both do.


[1]: 
https://github.com/rpm-software-management/rpm/commit/bb2cd52cf1067b9d18106f127a5034e2ad50db64




--
真実はいつも一つ！/ 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Thanks for your advice. Already contacted maintainers of redhat-rpm-config
to discuss adding the appropriate command and see what their response is.

Ondrej

On Wed, Mar 10, 2021 at 8:06 PM Brian C. Lane  wrote:

> On Tue, Mar 09, 2021 at 09:15:23AM +, Tomasz Kłoczko wrote:
> > On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj  wrote:
> >
> > > If any concerns about the autoconf2.69-2.69 compat package ? If needed
> it
> > > can be implemented as non-parallelly instalable,
> > >
> >
> > Really .. instead wasting time on packaging stuff which is ~7 years old
> it
> > would be better to use that time to fix one of those handful packages
> which
>
> Well the reason why it is 7 years old is there weren't any updates, so I
> think we should expect a reasonable amount of time to pass before
> upstreams transition.
>
> Like I said earlier, for parted we're not going to change until 2.71 is
> widely available, so I need something that either works with both or a
> compatibility package.
>
> > So .. anyone knows any other packages dist sources trees on which
> something
> > like "autoreconf -fiv" fails?
>
> THIS is what I needed. I hadn't tried -i so I continued to get failures
> when I worked on this a few weeks back. Adding -fiv did the trick and
> parted-3.4-3.fc35 will work with 2.69 or 2.71 so I no longer need the
> compatibility package, thanks.
>
> I still think having 2.69 is necessary though, and we should revisit
> convincing upstreams to use 2.71 after F36 or so.
>
> Brian
>
> --
> Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Brian C. Lane]

On Tue, Mar 09, 2021 at 09:15:23AM +, Tomasz Kłoczko wrote:
> On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj  wrote:
> 
> > If any concerns about the autoconf2.69-2.69 compat package ? If needed it
> > can be implemented as non-parallelly instalable,
> >
> 
> Really .. instead wasting time on packaging stuff which is ~7 years old it
> would be better to use that time to fix one of those handful packages which

Well the reason why it is 7 years old is there weren't any updates, so I
think we should expect a reasonable amount of time to pass before
upstreams transition.

Like I said earlier, for parted we're not going to change until 2.71 is
widely available, so I need something that either works with both or a
compatibility package.

> So .. anyone knows any other packages dist sources trees on which something
> like "autoreconf -fiv" fails?

THIS is what I needed. I hadn't tried -i so I continued to get failures
when I worked on this a few weeks back. Adding -fiv did the trick and
parted-3.4-3.fc35 will work with 2.69 or 2.71 so I no longer need the
compatibility package, thanks.

I still think having 2.69 is necessary though, and we should revisit
convincing upstreams to use 2.71 after F36 or so.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Tomasz Kłoczko]

On Wed, 10 Mar 2021 at 09:28, Ondrej Dubaj  wrote:

> Hello,
>
> Thank you for your suggestions, but as you might understand, I do not have
> the capacity to resolve problems of dependent packages when building with
> autoconf-2.71.
>

As I wrote so far I found only two packages which are not ac 2.71 compliant
which I've not been able to fix by adding a simple patch.
IMO fixing found issues before f35 dev cycle is doable and can be finished
without strain on anyone's capacity.

In most of the cases people are not solving some issues because they don't
know that actually it is some issue.
In other words only pointing to/encircling the issues sometimes (IMO) it
is +95% of success that issue will be solved quickly.

it is another issue with Fedora that detecting such issues on massive scale
could be a bit tricky because for some reasons instead fixing libtool and
automake with explicit calling "autoreconf -fiv" before %configure
JFDI/JFDIN approach has been chosen to fiddle in some ac/am/lt files.
You can see that JFDI on
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_191
However by building all fedora packages only to check is package X still
building or not by executing something like "rpmbuild -bc -D "_configure
`autoreconf -fiv; configure' .spec" should be possible to probe
probably +~98% cases when autoconf 2.71 may fail.
.. ~+98% because in some cases %configure macro is used in spec file and in
reality autoconf is not used in the exact source tree or because in some
spec files %_configure macro is redefined and above commandline
redefinition may collide with that.

Such experiments can be done on copr builders. Probably similar experiments
on the scale of all fedora packages are already done probably more than one
time each month.
So as you may already see *diagnosing *which Fedora packages are not ac
2.71 compliant it is *not *beyond anyone capacity .. because checking the
whole distro against ac 2.71 effectively can be done by executing a single
oneliner.

At least after such a diag test build the exact list of problematic
packages can be formed.
Such list published will put enough/gentle pressure on exact source trees
maintainer to fix such issues ASAP :P

Those two packages which I've mention (gettext and openldap) I found by
testing so far below number of packages:

[tkloczko@barrel SPECS]$ grep "^autoreconf -fiv" *spec | wc -l
862

Initially there were more than two failing packages however only those two
(gettext and openldap) did not end up with submitting MR/PR (in a few cases
in the meantime new versions with merged fixes have been released).

And yet another side comment.
Necessary fix for ac 2.71 only if correctly done definitely will not break
using source tree with ac 2.69.

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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Thanks for advice guys, setting commitish to back rawhide in copr.

Sorry for the bad advice to other maintainers. Please use pull-requests
against rawhide as Miro mentioned.

Ondrej.

On Wed, Mar 10, 2021 at 11:01 AM Miro Hrončok  wrote:

> On 10. 03. 21 10:47, Fabio Valentini wrote:
> > On Wed, Mar 10, 2021 at 10:27 AM Ondrej Dubaj  wrote:
> >>
> >> Hello,
> >>
> >> Thank you for your suggestions, but as you might understand, I do not
> have the capacity to resolve problems of dependent packages when building
> with autoconf-2.71.
> >>
> >> I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69
> for other maintainers, so they are able to make appropriate changes and
> test them in copr. Testing is possible by pushing the changes to a new
> created branch "rawhide-autoconf-2.71", where in your package you can use
> autoconf dependency (autoconf-2.71) or autoconf2.69 dependency (compat
> package for autoconf-2.69). After pushing to the given branch, the package
> will be built automatically in copr and you can test the update of your
> package. You can do this many times until you are certain your package
> works good.
> >>
> >> Thanks for understanding and cooperation.
> >
> > Please don't do branches like this in "official" dist-git
> > repositories. It's a big PITA to clean up such branches.
>
> I concur.
>
> Set the committish of the packages in your copr to "rawhide". Packagers
> can send
> pull requests with changes and the results will appear in your Copr e.g.
> in:
>
>
> https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/builds/?dirname=autoconf-2.70:pr:18
>
> Pull requests, unlike arbitrary branches, can be safely rebased until the
> result
> is good. Once merged, they are "gone" (technically, they remain in your
> fork,
> but that should not bother anybody and can be deleted if needed).
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Miro Hrončok]

On 10. 03. 21 10:47, Fabio Valentini wrote:

On Wed, Mar 10, 2021 at 10:27 AM Ondrej Dubaj  wrote:


Hello,

Thank you for your suggestions, but as you might understand, I do not have the 
capacity to resolve problems of dependent packages when building with 
autoconf-2.71.

I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69 for other 
maintainers, so they are able to make appropriate changes and test them in copr. Testing 
is possible by pushing the changes to a new created branch 
"rawhide-autoconf-2.71", where in your package you can use autoconf dependency 
(autoconf-2.71) or autoconf2.69 dependency (compat package for autoconf-2.69). After 
pushing to the given branch, the package will be built automatically in copr and you can 
test the update of your package. You can do this many times until you are certain your 
package works good.

Thanks for understanding and cooperation.


Please don't do branches like this in "official" dist-git
repositories. It's a big PITA to clean up such branches.


I concur.

Set the committish of the packages in your copr to "rawhide". Packagers can send 
pull requests with changes and the results will appear in your Copr e.g. in:


https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/builds/?dirname=autoconf-2.70:pr:18

Pull requests, unlike arbitrary branches, can be safely rebased until the result 
is good. Once merged, they are "gone" (technically, they remain in your fork, 
but that should not bother anybody and can be deleted if needed).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Fabio Valentini]

On Wed, Mar 10, 2021 at 10:27 AM Ondrej Dubaj  wrote:
>
> Hello,
>
> Thank you for your suggestions, but as you might understand, I do not have 
> the capacity to resolve problems of dependent packages when building with 
> autoconf-2.71.
>
> I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69 for 
> other maintainers, so they are able to make appropriate changes and test them 
> in copr. Testing is possible by pushing the changes to a new created branch 
> "rawhide-autoconf-2.71", where in your package you can use autoconf 
> dependency (autoconf-2.71) or autoconf2.69 dependency (compat package for 
> autoconf-2.69). After pushing to the given branch, the package will be built 
> automatically in copr and you can test the update of your package. You can do 
> this many times until you are certain your package works good.
>
> Thanks for understanding and cooperation.

Please don't do branches like this in "official" dist-git
repositories. It's a big PITA to clean up such branches.

Fabio
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Hello,

Thank you for your suggestions, but as you might understand, I do not have
the capacity to resolve problems of dependent packages when building with
autoconf-2.71.

I can only prepare autoconf-2.71 and compat package autoconf2.69-2.69 for
other maintainers, so they are able to make appropriate changes and test
them in copr. Testing is possible by pushing the changes to a new created
branch "rawhide-autoconf-2.71", where in your package you can use autoconf
dependency (autoconf-2.71) or autoconf2.69 dependency (compat package for
autoconf-2.69). After pushing to the given branch, the package will be
built automatically in copr and you can test the update of your package.
You can do this many times until you are certain your package works good.

Thanks for understanding and cooperation.

Ondrej

On Tue, Mar 9, 2021 at 10:19 AM Tomasz Kłoczko 
wrote:

> On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj  wrote:
>
>> If any concerns about the autoconf2.69-2.69 compat package ? If needed it
>> can be implemented as non-parallelly instalable,
>>
>
> Really .. instead wasting time on packaging stuff which is ~7 years old it
> would be better to use that time to fix one of those handful packages which
> are still not ac 2.71 compliant (like openldap
> https://bugs.openldap.org/show_bug.cgi?id=9485).
> Listing all those failing packages + posting URL from where is possible to
> upload ac 2.71 package would allow more people to work on those few
> remaining packages which still needs to be cleaned/updated.
>
> Otherwise some stuff will end up like the firefox, mozjs, nss, nspr
> packages which still are using even older autoconf :/ (which is in own
> sense ridiculous that one of the most actively maintained source trees
> still is using so old build tooling)
>
> Some time ago gcc, binutils IIRC received an update for ac 2.71 so at
> least those two should be by now off-the-table (Am I right?).
>
> In many cases executing "autoupdate", adding patch out of the changes
> generated by that command to spec and submitting PR/MR against the original
> source tree is all what needs to be done. This is not rocket science ..
>
> So .. anyone knows any other packages dist sources trees on which
> something like "autoreconf -fiv" fails?
> So far I found only two like that: openldap and gettext (in that case most
> of the issues are caused by using gnulib which is another swampy area).
>
> It is still plenty of time before the f35 cycle needs to be finished, and
> still it can be done RightWay(tm) .. no rush.
>
> For now posting ~óne time a week with updates about progress on wiping out
> ac 2.69 should allow IMO final upgrade autoconf to 2.71 relatively soon.
>
> 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
>
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Tomasz Kłoczko]

On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj  wrote:

> If any concerns about the autoconf2.69-2.69 compat package ? If needed it
> can be implemented as non-parallelly instalable,
>

Really .. instead wasting time on packaging stuff which is ~7 years old it
would be better to use that time to fix one of those handful packages which
are still not ac 2.71 compliant (like openldap
https://bugs.openldap.org/show_bug.cgi?id=9485).
Listing all those failing packages + posting URL from where is possible to
upload ac 2.71 package would allow more people to work on those few
remaining packages which still needs to be cleaned/updated.

Otherwise some stuff will end up like the firefox, mozjs, nss, nspr
packages which still are using even older autoconf :/ (which is in own
sense ridiculous that one of the most actively maintained source trees
still is using so old build tooling)

Some time ago gcc, binutils IIRC received an update for ac 2.71 so at least
those two should be by now off-the-table (Am I right?).

In many cases executing "autoupdate", adding patch out of the changes
generated by that command to spec and submitting PR/MR against the original
source tree is all what needs to be done. This is not rocket science ..

So .. anyone knows any other packages dist sources trees on which something
like "autoreconf -fiv" fails?
So far I found only two like that: openldap and gettext (in that case most
of the issues are caused by using gnulib which is another swampy area).

It is still plenty of time before the f35 cycle needs to be finished, and
still it can be done RightWay(tm) .. no rush.

For now posting ~óne time a week with updates about progress on wiping out
ac 2.69 should allow IMO final upgrade autoconf to 2.71 relatively soon.

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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

If any concerns about the autoconf2.69-2.69 compat package ? If needed it
can be implemented as non-parallelly instalable,

Thanks. Regards,

Ondrej

On Fri, Mar 5, 2021 at 8:08 AM Ondrej Dubaj  wrote:

> Thanks for your notes. If wanted, the first version of autoconf2.69-2.69
> compat package is available in copr for testing. This is a version which is
> parallelly installable with autoconf-2.71. Please check/update your
> packages and rebuild them.
>
> Thanks. Regards,
>
> Ondrej
>
> copr:
> https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/
>
> On Wed, Mar 3, 2021 at 2:45 PM Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> Miro Hrončok wrote:
>> > 1) Why 269 and not 2.69?
>>
>> I guess that this is a historical thing: past autoconf compatibility
>> packages always had names such as autoconf213. Back then, dots in package
>> names were considered unusual or harmful, standard practice was to omit
>> them. The rule that the dot should be included was added relatively
>> recently
>> (but already a couple years ago by now) to the packaging guidelines.
>>
>> Kevin Kofler
>> ___
>> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Thanks for your notes. If wanted, the first version of autoconf2.69-2.69
compat package is available in copr for testing. This is a version which is
parallelly installable with autoconf-2.71. Please check/update your
packages and rebuild them.

Thanks. Regards,

Ondrej

copr: https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/

On Wed, Mar 3, 2021 at 2:45 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Miro Hrončok wrote:
> > 1) Why 269 and not 2.69?
>
> I guess that this is a historical thing: past autoconf compatibility
> packages always had names such as autoconf213. Back then, dots in package
> names were considered unusual or harmful, standard practice was to omit
> them. The rule that the dot should be included was added relatively
> recently
> (but already a couple years ago by now) to the packaging guidelines.
>
> Kevin Kofler
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Kevin Kofler via devel]

Miro Hrončok wrote:
> 1) Why 269 and not 2.69?

I guess that this is a historical thing: past autoconf compatibility 
packages always had names such as autoconf213. Back then, dots in package 
names were considered unusual or harmful, standard practice was to omit 
them. The rule that the dot should be included was added relatively recently 
(but already a couple years ago by now) to the packaging guidelines.

Kevin Kofler
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Kevin Kofler via devel]

Miro Hrončok wrote:
> 2) Is the parallel installability worth the trouble of different names?

IMHO, yes. Some projects require developers to run autoconf to pregenerate 
the scripts, so they will need to be able to work with more than one 
version.

Past autoconf compatibility packages in Fedora have always worked like this, 
with suffixed names.

What we could do is adding an additional autoconf2.69-unversioned-commands 
subpackage with unversioned symlinks, Requires: autoconf2.69, and Conflicts: 
autoconf. That would bring us the best of both worlds: parallel 
installability for end users, and an easy porting procedure 
(s/^\(BuildRequires:[ \t]*\)autoconf/\1autoconf2.69-unversioned-commands/g 
*.spec) to get a package to build in Mock/Koji.

Kevin Kofler
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

On Wed, Mar 3, 2021 at 1:51 PM Miro Hrončok  wrote:

> On 03. 03. 21 13:47, Ondrej Dubaj wrote:
> >
> >
> > On Wed, Mar 3, 2021 at 1:33 PM Miro Hrončok  > > wrote:
> >
> > On 03. 03. 21 12:49, Ondrej Dubaj wrote:
> >  > Compat package prepared.
> >  >
> >  > Package autoconf269-2.69-1 provides:
> >  >
> >  > /usr/bin/autoconf269
> >  > /usr/bin/autoheader269
> >  > /usr/bin/autom4te269
> >  > /usr/bin/autoreconf269
> >  > /usr/bin/autoscan269
> >  > /usr/bin/autoupdate269
> >  > /usr/bin/ifnames269
> >  > ...
> >  >
> >  > Parallel installation successful.
> >  >
> >  > Any suggestions/concerns are welcome.
> >
> > My concerns are:
> >
> > 1) Why 269 and not 2.69?
> >
> > Just a naming convention, if needed can be easily changed
>
> There is no need to complicate stuff by removing the dot. The naming
> convention
> for compat packages is to include the version:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple


Ok, will change immediately.

>
>
> > 2) Is the parallel installability worth the trouble of different
> names?
> >
> > It is up to us to discuss this.
>
> How are most of the packages in Fedora using? Is it spelling out
> "autoconf" in
> the spec file, or trough some configure scripts? If it is the second, I
> worry
> that a command will mean patching (or sedding) would be required.
>

Both, actually.

>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Miro Hrončok]

On 03. 03. 21 13:47, Ondrej Dubaj wrote:



On Wed, Mar 3, 2021 at 1:33 PM Miro Hrončok > wrote:


On 03. 03. 21 12:49, Ondrej Dubaj wrote:
 > Compat package prepared.
 >
 > Package autoconf269-2.69-1 provides:
 >
 > /usr/bin/autoconf269
 > /usr/bin/autoheader269
 > /usr/bin/autom4te269
 > /usr/bin/autoreconf269
 > /usr/bin/autoscan269
 > /usr/bin/autoupdate269
 > /usr/bin/ifnames269
 > ...
 >
 > Parallel installation successful.
 >
 > Any suggestions/concerns are welcome.

My concerns are:

1) Why 269 and not 2.69?

Just a naming convention, if needed can be easily changed


There is no need to complicate stuff by removing the dot. The naming convention 
for compat packages is to include the version:


https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple


2) Is the parallel installability worth the trouble of different names?

It is up to us to discuss this.


How are most of the packages in Fedora using? Is it spelling out "autoconf" in 
the spec file, or trough some configure scripts? If it is the second, I worry 
that a command will mean patching (or sedding) would be required.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

On Wed, Mar 3, 2021 at 1:33 PM Miro Hrončok  wrote:

> On 03. 03. 21 12:49, Ondrej Dubaj wrote:
> > Compat package prepared.
> >
> > Package autoconf269-2.69-1 provides:
> >
> > /usr/bin/autoconf269
> > /usr/bin/autoheader269
> > /usr/bin/autom4te269
> > /usr/bin/autoreconf269
> > /usr/bin/autoscan269
> > /usr/bin/autoupdate269
> > /usr/bin/ifnames269
> > ...
> >
> > Parallel installation successful.
> >
> > Any suggestions/concerns are welcome.
>
> My concerns are:
>
> 1) Why 269 and not 2.69?
>
Just a naming convention, if needed can be easily changed

2) Is the parallel installability worth the trouble of different names?
>
It is up to us to discuss this.

>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Miro Hrončok]

On 03. 03. 21 12:49, Ondrej Dubaj wrote:

Compat package prepared.

Package autoconf269-2.69-1 provides:

/usr/bin/autoconf269
/usr/bin/autoheader269
/usr/bin/autom4te269
/usr/bin/autoreconf269
/usr/bin/autoscan269
/usr/bin/autoupdate269
/usr/bin/ifnames269
...

Parallel installation successful.

Any suggestions/concerns are welcome.


My concerns are:

1) Why 269 and not 2.69?
2) Is the parallel installability worth the trouble of different names?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Compat package prepared.

Package autoconf269-2.69-1 provides:

/usr/bin/autoconf269
/usr/bin/autoheader269
/usr/bin/autom4te269
/usr/bin/autoreconf269
/usr/bin/autoscan269
/usr/bin/autoupdate269
/usr/bin/ifnames269
/usr/share/autoconf269
/usr/share/autoconf269/Autom4te
/usr/share/autoconf269/Autom4te/C4che.pm
/usr/share/autoconf269/Autom4te/ChannelDefs.pm
/usr/share/autoconf269/Autom4te/Channels.pm
/usr/share/autoconf269/Autom4te/Configure_ac.pm
/usr/share/autoconf269/Autom4te/FileUtils.pm
/usr/share/autoconf269/Autom4te/General.pm
/usr/share/autoconf269/Autom4te/Getopt.pm
/usr/share/autoconf269/Autom4te/Request.pm
/usr/share/autoconf269/Autom4te/XFile.pm
/usr/share/autoconf269/INSTALL
/usr/share/autoconf269/autoconf
/usr/share/autoconf269/autoconf/autoconf.m4
/usr/share/autoconf269/autoconf/autoconf.m4f
/usr/share/autoconf269/autoconf/autoheader.m4
/usr/share/autoconf269/autoconf/autoscan.m4
/usr/share/autoconf269/autoconf/autotest.m4
/usr/share/autoconf269/autoconf/autoupdate.m4
/usr/share/autoconf269/autoconf/c.m4
/usr/share/autoconf269/autoconf/erlang.m4
/usr/share/autoconf269/autoconf/fortran.m4
/usr/share/autoconf269/autoconf/functions.m4
/usr/share/autoconf269/autoconf/general.m4
/usr/share/autoconf269/autoconf/go.m4
/usr/share/autoconf269/autoconf/headers.m4
/usr/share/autoconf269/autoconf/lang.m4
/usr/share/autoconf269/autoconf/libs.m4
/usr/share/autoconf269/autoconf/oldnames.m4
/usr/share/autoconf269/autoconf/programs.m4
/usr/share/autoconf269/autoconf/specific.m4
/usr/share/autoconf269/autoconf/status.m4
/usr/share/autoconf269/autoconf/types.m4
/usr/share/autoconf269/autom4te.cfg
/usr/share/autoconf269/autoscan
/usr/share/autoconf269/autoscan/autoscan.list
/usr/share/autoconf269/autotest
/usr/share/autoconf269/autotest/autotest.m4
/usr/share/autoconf269/autotest/autotest.m4f
/usr/share/autoconf269/autotest/general.m4
/usr/share/autoconf269/autotest/specific.m4
/usr/share/autoconf269/m4sugar
/usr/share/autoconf269/m4sugar/foreach.m4
/usr/share/autoconf269/m4sugar/m4sh.m4
/usr/share/autoconf269/m4sugar/m4sh.m4f
/usr/share/autoconf269/m4sugar/m4sugar.m4
/usr/share/autoconf269/m4sugar/m4sugar.m4f
/usr/share/autoconf269/m4sugar/version.m4
/usr/share/config.site
/usr/share/doc/autoconf269
/usr/share/doc/autoconf269/AUTHORS
/usr/share/doc/autoconf269/ChangeLog
/usr/share/doc/autoconf269/NEWS
/usr/share/doc/autoconf269/README
/usr/share/doc/autoconf269/THANKS
/usr/share/doc/autoconf269/TODO
/usr/share/emacs/site-lisp/autoconf269
/usr/share/emacs/site-lisp/autoconf269/autoconf-mode.el
/usr/share/emacs/site-lisp/autoconf269/autoconf-mode.elc
/usr/share/emacs/site-lisp/autoconf269/autotest-mode.el
/usr/share/emacs/site-lisp/autoconf269/autotest-mode.elc
/usr/share/emacs/site-lisp/site-start.d
/usr/share/emacs/site-lisp/site-start.d/autoconf-init.el
/usr/share/info/autoconf269.info.gz
/usr/share/licenses/autoconf269
/usr/share/licenses/autoconf269/COPYING
/usr/share/licenses/autoconf269/COPYING.EXCEPTION
/usr/share/licenses/autoconf269/COPYINGv3
/usr/share/man/man1/autoconf269.1.gz
/usr/share/man/man1/autoheader269.1.gz
/usr/share/man/man1/autom4te269.1.gz
/usr/share/man/man1/autoreconf269.1.gz
/usr/share/man/man1/autoscan269.1.gz
/usr/share/man/man1/autoupdate269.1.gz
/usr/share/man/man1/config.guess269.1.gz
/usr/share/man/man1/config.sub269.1.gz
/usr/share/man/man1/ifnames269.1.gz

Package autoconf-2.71-1 provides:

/usr/bin/autoconf
/usr/bin/autoheader
/usr/bin/autom4te
/usr/bin/autoreconf
/usr/bin/autoscan
/usr/bin/autoupdate
/usr/bin/ifnames
/usr/share/autoconf
/usr/share/autoconf/Autom4te
/usr/share/autoconf/Autom4te/C4che.pm
/usr/share/autoconf/Autom4te/ChannelDefs.pm
/usr/share/autoconf/Autom4te/Channels.pm
/usr/share/autoconf/Autom4te/Config.pm
/usr/share/autoconf/Autom4te/Configure_ac.pm
/usr/share/autoconf/Autom4te/FileUtils.pm
/usr/share/autoconf/Autom4te/General.pm
/usr/share/autoconf/Autom4te/Getopt.pm
/usr/share/autoconf/Autom4te/Request.pm
/usr/share/autoconf/Autom4te/XFile.pm
/usr/share/autoconf/INSTALL
/usr/share/autoconf/autoconf
/usr/share/autoconf/autoconf/autoconf.m4
/usr/share/autoconf/autoconf/autoconf.m4f
/usr/share/autoconf/autoconf/autoheader.m4
/usr/share/autoconf/autoconf/autoscan.m4
/usr/share/autoconf/autoconf/autotest.m4
/usr/share/autoconf/autoconf/autoupdate.m4
/usr/share/autoconf/autoconf/c.m4
/usr/share/autoconf/autoconf/erlang.m4
/usr/share/autoconf/autoconf/fortran.m4
/usr/share/autoconf/autoconf/functions.m4
/usr/share/autoconf/autoconf/general.m4
/usr/share/autoconf/autoconf/go.m4
/usr/share/autoconf/autoconf/headers.m4
/usr/share/autoconf/autoconf/lang.m4
/usr/share/autoconf/autoconf/libs.m4
/usr/share/autoconf/autoconf/oldnames.m4
/usr/share/autoconf/autoconf/programs.m4
/usr/share/autoconf/autoconf/specific.m4
/usr/share/autoconf/autoconf/status.m4
/usr/share/autoconf/autoconf/trailer.m4
/usr/share/autoconf/autoconf/types.m4
/usr/share/autoconf/autom4te.cfg
/usr/share/autoconf/autoscan
/usr/share/autoconf/autoscan/autoscan.list
/usr/share/autoconf/autotest

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Actually yes, you are right. Currently all fedora prackages are buildable
with autoconf-2.69 and there is a small part (~190), which are not
buildable with autoconf-2.71 (will use compat package instead).

Thanks for your advice, I didn't realize this at the moment.

Ondrej

On Wed, Mar 3, 2021 at 9:31 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Wed, Mar 03, 2021 at 09:20:48AM +0100, Ondrej Dubaj wrote:
> > Understand, starting to work on delivering autoconf-2.69 compat package.
> > Have to investigate if it would be possible to install autoconf-2.69 and
> > autoconf-2.71 next to each other on the system. Will keep you updated.
>
> Actually, it might not be necessary to have them parallel-installable.
> If that is easy, then that's a nice property to have. But just being
> able to install one or the other in mock is enough.
>
> Zbyszek
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Dominique Martinet]

Zbigniew Jędrzejewski-Szmek wrote on Wed, Mar 03, 2021 at 08:25:30AM +:
> On Wed, Mar 03, 2021 at 09:20:48AM +0100, Ondrej Dubaj wrote:
> > Understand, starting to work on delivering autoconf-2.69 compat package.
> > Have to investigate if it would be possible to install autoconf-2.69 and
> > autoconf-2.71 next to each other on the system. Will keep you updated.
> 
> Actually, it might not be necessary to have them parallel-installable.
> If that is easy, then that's a nice property to have. But just being
> able to install one or the other in mock is enough.

For what it's worth debian has compat packages so it doesn't look too bad:

configure --normal-flags --program-suffix=2.69
make pkgdatadir=/usr/share/autoconf2.69
mv /usr/share/autoconf /usr/share/autoconf2.69 (at install time)

seems to be most of it

(that said I do agree it's not worth spending hours on it)
-- 
Dominique
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 03, 2021 at 09:20:48AM +0100, Ondrej Dubaj wrote:
> Understand, starting to work on delivering autoconf-2.69 compat package.
> Have to investigate if it would be possible to install autoconf-2.69 and
> autoconf-2.71 next to each other on the system. Will keep you updated.

Actually, it might not be necessary to have them parallel-installable.
If that is easy, then that's a nice property to have. But just being
able to install one or the other in mock is enough.

Zbyszek
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Understand, starting to work on delivering autoconf-2.69 compat package.
Have to investigate if it would be possible to install autoconf-2.69 and
autoconf-2.71 next to each other on the system. Will keep you updated.

Ondrej

On Mon, Mar 1, 2021 at 7:35 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Wed, Feb 10, 2021 at 12:47:25PM -0500, Ben Cotton wrote:
> > == Contingency Plan ==
> > * Contingency mechanism: moving this change to Fedora 36, if not
> > successfully finished until Fedora 35 branching from Rawhide
> > * Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
> > * Blocks release? No
>
> What is the final decision wrt. to compat package creation? With 190
> packages failing to build, I think it's very likely that at least some
> of those will still fail to build 5 months from now. The contingency
> mechanism, as described, would be to postpone the update to F36 at that
> point. I think this is not desirable, not least because it doesn't
> guarantee
> that we will not have a very similar situation *12* months from now.
>
> So instead, I'd very much propose to plan that a compat package will
> be created, and that *some* packages will require autoconf-2.69, and
> if they do, switch them over to use the compat package. *If* it turns
> out early enough that the compat package is not needed, we can skip it.
>
> Overall, I think things would go much smoother this way. With the
> current plan, by creating a flag day, we're actually making it harder
> to develop against 2.71, because it'll not be available in Fedora
> until *everything* has been switched over.
>
> Zbyszek
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 10, 2021 at 12:47:25PM -0500, Ben Cotton wrote:
> == Contingency Plan ==
> * Contingency mechanism: moving this change to Fedora 36, if not
> successfully finished until Fedora 35 branching from Rawhide
> * Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
> * Blocks release? No

What is the final decision wrt. to compat package creation? With 190
packages failing to build, I think it's very likely that at least some
of those will still fail to build 5 months from now. The contingency
mechanism, as described, would be to postpone the update to F36 at that
point. I think this is not desirable, not least because it doesn't guarantee
that we will not have a very similar situation *12* months from now.

So instead, I'd very much propose to plan that a compat package will
be created, and that *some* packages will require autoconf-2.69, and
if they do, switch them over to use the compat package. *If* it turns
out early enough that the compat package is not needed, we can skip it.

Overall, I think things would go much smoother this way. With the
current plan, by creating a flag day, we're actually making it harder
to develop against 2.71, because it'll not be available in Fedora
until *everything* has been switched over.

Zbyszek
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

I understand, thanks for the explanation. We will wait to see what other
maintainers and upstreams will say.

This explanation is exactly what we need to have as much information as we
can. Hopefully other maintainers will soonly present their opinions as well.

Thanks.

Ondrej

On Thu, Feb 25, 2021 at 5:51 PM Brian C. Lane  wrote:

> On Thu, Feb 25, 2021 at 07:55:09AM +0100, Ondrej Dubaj wrote:
> > Brian,
> >
> > I understand, but as I already said, compat package can lead to
> > unwillingness to move forward to autoconf-2.71. For example, we can have
> a
> > compat package for f35 to have time to deal with the problems, but
> > certainly not for f36 or f37. After release of autoconf-2.71, I expect
> most
> > of the upstream packages moving to autoconf-2.71 in one year time, so
> > hopefully no compat package will be needed.
>
> I think you are optimistic :)
>
> >
> > Why are you not thinking of moving parted to autoconf-2.71 ? Are there
> any
> > special reasons for not doing this?
>
> Nobody else is using it yet. Ubuntu, Debian, Alpine, and FreeBSD (and I'm
> pretty sure the other *BSD flavors) are still using 2.69. The Gentoo has
> it available, as does the Debian experimental branch but it doesn't look
> like they are ready for general use yet.
>
> We (the parted maintainers) need to make sure that parted remains
> buildable for all the users of it, not just Fedora, so it can't switch
> until 2.71 is widely available and is well tested. I have a big patch
> that seems to work, but that's going to make patching difficult for me
> until upstream is ready to switch so I'd rather just stick with 2.69
>
> There needs to be a period of overlap to allow upstreams to experiment
> with the new version.
>
> Brian
>
> --
> Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
>
>
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Brian C. Lane]

On Thu, Feb 25, 2021 at 07:55:09AM +0100, Ondrej Dubaj wrote:
> Brian,
> 
> I understand, but as I already said, compat package can lead to
> unwillingness to move forward to autoconf-2.71. For example, we can have a
> compat package for f35 to have time to deal with the problems, but
> certainly not for f36 or f37. After release of autoconf-2.71, I expect most
> of the upstream packages moving to autoconf-2.71 in one year time, so
> hopefully no compat package will be needed.

I think you are optimistic :)

> 
> Why are you not thinking of moving parted to autoconf-2.71 ? Are there any
> special reasons for not doing this?

Nobody else is using it yet. Ubuntu, Debian, Alpine, and FreeBSD (and I'm
pretty sure the other *BSD flavors) are still using 2.69. The Gentoo has
it available, as does the Debian experimental branch but it doesn't look
like they are ready for general use yet.

We (the parted maintainers) need to make sure that parted remains
buildable for all the users of it, not just Fedora, so it can't switch
until 2.71 is widely available and is well tested. I have a big patch
that seems to work, but that's going to make patching difficult for me
until upstream is ready to switch so I'd rather just stick with 2.69

There needs to be a period of overlap to allow upstreams to experiment
with the new version.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Brian,

I understand, but as I already said, compat package can lead to
unwillingness to move forward to autoconf-2.71. For example, we can have a
compat package for f35 to have time to deal with the problems, but
certainly not for f36 or f37. After release of autoconf-2.71, I expect most
of the upstream packages moving to autoconf-2.71 in one year time, so
hopefully no compat package will be needed.

Why are you not thinking of moving parted to autoconf-2.71 ? Are there any
special reasons for not doing this?

Thanks.

Ondrej

On Wed, Feb 24, 2021 at 6:36 PM Brian C. Lane  wrote:

> On Wed, Feb 24, 2021 at 08:14:17AM +0100, Ondrej Dubaj wrote:
> > Brian,
> >
> > you are right there are some changes which are now backward compatible.
> > That's the reason why we need cross-component cooperation from other
> > maintainers to detect these pieces and potentially report them to
> upstream
> > and see if they are willing to fix them. Another option is also to
> create a
> > compat package for autoconf-2.69 for f35, but it can lead to a result,
> > where some of the maintainers/upstreams will never use autoconf-2.71.
>
> I think we need to create a 2.69 compat package. I certainly have no
> current plans to switch upstream parted to 2.71 and while I now have a
> wonderful 1.8M patch that fixes it for Fedora I'd rather just use the
> upstream tar release with 2.69 until we're comfortable moving.
>
> Having 2.71 available is valuable, so both should be packaged, but it
> should not be a requirement at this point.
>
> Brian
>
> --
> Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
>
>
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Brian C. Lane]

On Wed, Feb 24, 2021 at 08:14:17AM +0100, Ondrej Dubaj wrote:
> Brian,
> 
> you are right there are some changes which are now backward compatible.
> That's the reason why we need cross-component cooperation from other
> maintainers to detect these pieces and potentially report them to upstream
> and see if they are willing to fix them. Another option is also to create a
> compat package for autoconf-2.69 for f35, but it can lead to a result,
> where some of the maintainers/upstreams will never use autoconf-2.71.

I think we need to create a 2.69 compat package. I certainly have no
current plans to switch upstream parted to 2.71 and while I now have a
wonderful 1.8M patch that fixes it for Fedora I'd rather just use the
upstream tar release with 2.69 until we're comfortable moving.

Having 2.71 available is valuable, so both should be packaged, but it
should not be a requirement at this point.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Brian,

you are right there are some changes which are now backward compatible.
That's the reason why we need cross-component cooperation from other
maintainers to detect these pieces and potentially report them to upstream
and see if they are willing to fix them. Another option is also to create a
compat package for autoconf-2.69 for f35, but it can lead to a result,
where some of the maintainers/upstreams will never use autoconf-2.71.

If there are any packages, which are already orphaned, do not hesitate to
let me know and I will remove them. Also, if you are missing any package
there. Autoconf changes have a huge impact on the whole system, so it needs
to be properly tested and agreed.

Thanks for your cooperation!

Ondrej

On Wed, Feb 24, 2021 at 1:44 AM Jeff Law  wrote:

>
>
> On 2/23/21 4:54 PM, Jerry James wrote:
> > On Tue, Feb 23, 2021 at 4:52 PM Jeff Law  wrote:
> >> On 2/23/21 4:39 PM, Brian C. Lane wrote:
> >>> On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote:
>  [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
> >>> Doesn't work, with or without :8080
> >> Not sure what you're referring to, it just worked fine for me.
> > As Ondrej said: "Attaching also results from a tester launched by Jeff
> > Law [2] (accessible only on Red Hat VPN)".  Those of us without access
> > to the Red Hat VPN cannot see those results.
> But Brian is (or can be) inside the VPN.  That's what I was referring to.
>
> jeff
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Jeff Law]

On 2/23/21 4:54 PM, Jerry James wrote:
> On Tue, Feb 23, 2021 at 4:52 PM Jeff Law  wrote:
>> On 2/23/21 4:39 PM, Brian C. Lane wrote:
>>> On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote:
 [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
>>> Doesn't work, with or without :8080
>> Not sure what you're referring to, it just worked fine for me.
> As Ondrej said: "Attaching also results from a tester launched by Jeff
> Law [2] (accessible only on Red Hat VPN)".  Those of us without access
> to the Red Hat VPN cannot see those results.
But Brian is (or can be) inside the VPN.  That's what I was referring to.

jeff
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Jerry James]

On Tue, Feb 23, 2021 at 4:52 PM Jeff Law  wrote:
> On 2/23/21 4:39 PM, Brian C. Lane wrote:
> > On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote:
> >> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
> > Doesn't work, with or without :8080
> Not sure what you're referring to, it just worked fine for me.

As Ondrej said: "Attaching also results from a tester launched by Jeff
Law [2] (accessible only on Red Hat VPN)".  Those of us without access
to the Red Hat VPN cannot see those results.
-- 
Jerry James
http://www.jamezone.org/
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Jeff Law]

On 2/23/21 4:39 PM, Brian C. Lane wrote:
> On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote:
>> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
> Doesn't work, with or without :8080
Not sure what you're referring to, it just worked fine for me.

>
> parted is failing with a pile of newly obsolete things, and one error
> (as far as I can tell) with a missing build-aux/compile
Yes, partd falls down spectacularly.


http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/view/Failing/job/parted/216/consoleFull

Search for the first "autoreconf" and see all the diagnostics.

Jeff
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Brian C. Lane]

On Tue, Feb 23, 2021 at 11:37:42AM +0100, Ondrej Dubaj wrote:
> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/

Doesn't work, with or without :8080

parted is failing with a pile of newly obsolete things, and one error
(as far as I can tell) with a missing build-aux/compile

I'm guessing I need to bootstrap the whole thing again, which leads me
to:

Are these changes backwards compatible? I am also an upstream maintainer
for parted, and unless the 2.71 changes will also work with 2.69 I won't
be able to apply them upstream until enough users have moved to the new
autoconf.

Thanks,

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

Thanks for your note, I will look at the dependent packages (they were
selected ~1 month ago). But technically, it does not disturb us if some
package does not require on autoconf and builds successfully. We have to
focus on failed builds and investigate where the problem is.

Ondrej

On Tue, Feb 23, 2021 at 12:55 PM Ian McInerney 
wrote:

> On Tue, Feb 23, 2021 at 10:38 AM Ondrej Dubaj  wrote:
>
>> 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.
>>
>> [1]
>> https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/
>> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
>>
>>
> How did you find the dependent packages? I would suggest updating the
> dependent packages list again, since audacity can be removed from the list
> of packages needing a rebuild since you are using 2.4.2. That release
> switched to CMake from autotools because upstream unceremoniously removed
> the entire autotools build system in the patch release.
>
> -Ian
> ___
> 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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ian McInerney]

On Tue, Feb 23, 2021 at 10:38 AM Ondrej Dubaj  wrote:

> 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.
>
> [1] https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/
> [2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/
>
>
How did you find the dependent packages? I would suggest updating the
dependent packages list again, since audacity can be removed from the list
of packages needing a rebuild since you are using 2.4.2. That release
switched to CMake from autotools because upstream unceremoniously removed
the entire autotools build system in the patch release.

-Ian
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

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.

[1] https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/
[2] http://torsion.usersys.redhat.com:8080/job/Fedora-autoconf/

On Fri, Feb 12, 2021 at 11:00 PM David Cantrell 
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 
> 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 

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[David Cantrell]

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  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 
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




___
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



--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

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  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 
> 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
>
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[David Cantrell]

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 
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

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  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@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
>
___
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: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Jeff Law]

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@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

Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Miro Hrončok]

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?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Autoconf_271

== Summary ==
Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora.

== Owner ==
* Name: [[User:odubaj| Ondrej Dubaj]]
* Email: odu...@redhat.com

== Detailed Description ==
Upgrading autoconf from version 2.69 to version 2.71 according to new
upstream release. Version 2.70 is skipped due to multiple ABI
incompatibilities, where some of them were fixed in version 2.71.
Years of development differ these two releases, so problems are
expected.

This change might easily cause fails during builds of multiple
packages, as some of them still require autoconf-2.69. This step must
be properly discussed with maintainers of dependent packages, which
should forward this change proposal to their upstream projects.


== Benefit to Fedora ==
Brings a stable and up-to-date version of autoconf according to
upsteam release. It is expected, that in the future many upstream
development teams will use autoconf-2.71 as their default builder, so
Fedora will be prepared for such a step.

== Scope ==
* Proposal owners:
**Prepare autoconf-2.71 as RPM package for Fedora Rawhide
**Check software that requires `autoconf` or `autoconf-2.69` and
rebuild it with autoconf-2.71
**Build autoconf-2.71 to Rawhide in a side-tag
(https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
**Rebuild depended packages with autoconf-2.71 in the side-tag
**Merge the side-tag to Rawhide

* Other developers:
**Check if their packages can be build with autoconf-2.71
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== 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.

== How To Test ==
Rebuilding your packages with autoconf-2.71 dependency in copr
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/).

Mass rebuild of dependent packages in a side tag.

== User Experience ==
Users will be able to use the newer version (2.71) of autoconf, and
building packages with autoconf-2.69 won't be available, as it won't
be present on the specific fedora version. This can affect 3rd partly
packages, which are not part of Fedora.

== Dependencies ==
Hundreds of packages have build dependency on autoconf, therefore it
is a huge step forward for Fedora, what should be properly discussed
and tested. List of dependent packages with their ability to be built
with autoconf-2.71 can be found in the given copr project
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/)

We should also look at dependent packages of `libtool` and `automake`
(other critical autotools packages), as there might be some
incompatibilities with the new autoconf version.

== Contingency Plan ==
* Contingency mechanism: moving this change to Fedora 36, if not
successfully finished until Fedora 35 branching from Rawhide
* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
* Blocks release? No

== Documentation ==

Latest autoconf documentation:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/index.html

== Release Notes ==
Release notes for autoconf-2.70:
https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg1.html

Release notes for autoconf-2.71:
https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg0.html


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org

Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Autoconf_271

== Summary ==
Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora.

== Owner ==
* Name: [[User:odubaj| Ondrej Dubaj]]
* Email: odu...@redhat.com

== Detailed Description ==
Upgrading autoconf from version 2.69 to version 2.71 according to new
upstream release. Version 2.70 is skipped due to multiple ABI
incompatibilities, where some of them were fixed in version 2.71.
Years of development differ these two releases, so problems are
expected.

This change might easily cause fails during builds of multiple
packages, as some of them still require autoconf-2.69. This step must
be properly discussed with maintainers of dependent packages, which
should forward this change proposal to their upstream projects.


== Benefit to Fedora ==
Brings a stable and up-to-date version of autoconf according to
upsteam release. It is expected, that in the future many upstream
development teams will use autoconf-2.71 as their default builder, so
Fedora will be prepared for such a step.

== Scope ==
* Proposal owners:
**Prepare autoconf-2.71 as RPM package for Fedora Rawhide
**Check software that requires `autoconf` or `autoconf-2.69` and
rebuild it with autoconf-2.71
**Build autoconf-2.71 to Rawhide in a side-tag
(https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
**Rebuild depended packages with autoconf-2.71 in the side-tag
**Merge the side-tag to Rawhide

* Other developers:
**Check if their packages can be build with autoconf-2.71
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== 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.

== How To Test ==
Rebuilding your packages with autoconf-2.71 dependency in copr
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/).

Mass rebuild of dependent packages in a side tag.

== User Experience ==
Users will be able to use the newer version (2.71) of autoconf, and
building packages with autoconf-2.69 won't be available, as it won't
be present on the specific fedora version. This can affect 3rd partly
packages, which are not part of Fedora.

== Dependencies ==
Hundreds of packages have build dependency on autoconf, therefore it
is a huge step forward for Fedora, what should be properly discussed
and tested. List of dependent packages with their ability to be built
with autoconf-2.71 can be found in the given copr project
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/)

We should also look at dependent packages of `libtool` and `automake`
(other critical autotools packages), as there might be some
incompatibilities with the new autoconf version.

== Contingency Plan ==
* Contingency mechanism: moving this change to Fedora 36, if not
successfully finished until Fedora 35 branching from Rawhide
* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
* Blocks release? No

== Documentation ==

Latest autoconf documentation:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/index.html

== Release Notes ==
Release notes for autoconf-2.70:
https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg1.html

Release notes for autoconf-2.71:
https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg0.html


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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