Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Ian Stakenvicius]

On 11/06/17 04:02 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 11.06.2017 kell 13:08, kirjutas William Hubbs:
>> On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote:
>>> Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William
>>> Hubbs:
 On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand
 wrote:
> On 06/11/2017 05:24 PM, David Seifert wrote:
>>> We can always patch the eclass at that point if that is
>>> still a
>>> big
>>> concern, but I fundamentally agree with William on this,
>>> starting
>>> point
>>> should be fixing it upstream, so can start with a tracking
>>> bug
>>> on
>>> affected packages.
>>>
>>
>> Here's a deal: you can start filing + fixing them.
>>
>
> The [tracker] is already started, it was determined to add QA
> warning
> with info on filing upstream bugs in [bug 426262] and the
> proper
> solution is again iterated in [bug 546614], so its not like
> this is
> a
> new approach that is being suggested, but sure, we should all
> file
> bugs
> when we encounter them.
>
> References:
> [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632
>
> [bug 426262]
> https://bugs.gentoo.org/show_bug.cgi?id=426262
>
> [bug 546614]
> https://bugs.gentoo.org/show_bug.cgi?id=546614

 It seems that the proper fix to this, even for a package that
 won't
 do
 the fix upstream is to use WANT_AUTOCONF in the ebuild to force
 the
 version of autoconf you need.
>>>
>>> No. It appears you don't know how WANT_AUTOCONF works.
>>
>>  
>>  From the eclass:
>>
>> # @ECLASS-VARIABLE: WANT_AUTOCONF
>> # @DESCRIPTION:
>> # The major version of autoconf your package needs
>>
>> That leads me to believe that you can set WANT_AUTOCONF="someversion"
>> in your ebuild and your package will use that version of autoconf.
>>
>> If that's wrong, it needs to be fixed and that's a different bug
>> entirely, but it doesn't change my position on adding this particular
>> change to autotools.eclass.
> 
> It is the major version, as documented. Yes, it could specify what
> these valid versions currently are, as they really are:
> 
> none
> 2.1
> 2.5
> latest
> 
> Currently latest equals 2.5 and is the default.
> 
> In practice, none means not to add an autoconf atom to DEPEND (even
> with the default AUTOTOOLS_AUTO_DEPEND=yes) - if ebuild/eclass
> inheriting autotools.eclass handles its own exact autoconf depend atom
> (eautoconf will get called in eautoreconf regardless). Only main tree 
> consumer of this appears to be gtk-sharp-module.eclass that adds its
> own autoconf/automake atoms when needed, because eautoreconf is
> conditional by variables used by that eclass and it needed autoconf
> 2.61 or newer, not just 2.59.
> 
> 2.1 means autoconf:2.1
> 
> 2.5 and latest currently means >=autoconf-2.59
> 
> Patches welcome to documentation, I suppose.
> 
> 
> It is usually a bad sign if you need to change it away from latest for
> some reason in the ebuild and ideally they'd all be the default
> (latest).
> 
> There was no configure.ac before autoconf-2.50, only configure.in, and
> thus a warning doesn't make sense. The real warning here is the need
> for WANT_AUTOCONF=2.1
> 

I'm not seeing the issue with what William's suggesting -- if the
configure.in is non-trivial to just rename in the ebuild, then setting
WANT_AUTOCONF=2.1 would seem to me to be the correct course of action.
 If there's a package that has a configure.in but also needs
autoconf:2.5, well, that seems messed up and likely should be fixed in
the ebuild (or upstream) too.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Mart Raudsepp]

Ühel kenal päeval, P, 11.06.2017 kell 13:08, kirjutas William Hubbs:
> On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote:
> > Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William
> > Hubbs:
> > > On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand
> > > wrote:
> > > > On 06/11/2017 05:24 PM, David Seifert wrote:
> > > > > > We can always patch the eclass at that point if that is
> > > > > > still a
> > > > > > big
> > > > > > concern, but I fundamentally agree with William on this,
> > > > > > starting
> > > > > > point
> > > > > > should be fixing it upstream, so can start with a tracking
> > > > > > bug
> > > > > > on
> > > > > > affected packages.
> > > > > > 
> > > > > 
> > > > > Here's a deal: you can start filing + fixing them.
> > > > > 
> > > > 
> > > > The [tracker] is already started, it was determined to add QA
> > > > warning
> > > > with info on filing upstream bugs in [bug 426262] and the
> > > > proper
> > > > solution is again iterated in [bug 546614], so its not like
> > > > this is
> > > > a
> > > > new approach that is being suggested, but sure, we should all
> > > > file
> > > > bugs
> > > > when we encounter them.
> > > > 
> > > > References:
> > > > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632
> > > > 
> > > > [bug 426262]
> > > > https://bugs.gentoo.org/show_bug.cgi?id=426262
> > > > 
> > > > [bug 546614]
> > > > https://bugs.gentoo.org/show_bug.cgi?id=546614
> > > 
> > > It seems that the proper fix to this, even for a package that
> > > won't
> > > do
> > > the fix upstream is to use WANT_AUTOCONF in the ebuild to force
> > > the
> > > version of autoconf you need.
> > 
> > No. It appears you don't know how WANT_AUTOCONF works.
> 
>  
>  From the eclass:
> 
> # @ECLASS-VARIABLE: WANT_AUTOCONF
> # @DESCRIPTION:
> # The major version of autoconf your package needs
> 
> That leads me to believe that you can set WANT_AUTOCONF="someversion"
> in your ebuild and your package will use that version of autoconf.
> 
> If that's wrong, it needs to be fixed and that's a different bug
> entirely, but it doesn't change my position on adding this particular
> change to autotools.eclass.

It is the major version, as documented. Yes, it could specify what
these valid versions currently are, as they really are:

none
2.1
2.5
latest

Currently latest equals 2.5 and is the default.

In practice, none means not to add an autoconf atom to DEPEND (even
with the default AUTOTOOLS_AUTO_DEPEND=yes) - if ebuild/eclass
inheriting autotools.eclass handles its own exact autoconf depend atom
(eautoconf will get called in eautoreconf regardless). Only main tree 
consumer of this appears to be gtk-sharp-module.eclass that adds its
own autoconf/automake atoms when needed, because eautoreconf is
conditional by variables used by that eclass and it needed autoconf
2.61 or newer, not just 2.59.

2.1 means autoconf:2.1

2.5 and latest currently means >=autoconf-2.59

Patches welcome to documentation, I suppose.


It is usually a bad sign if you need to change it away from latest for
some reason in the ebuild and ideally they'd all be the default
(latest).

There was no configure.ac before autoconf-2.50, only configure.in, and
thus a warning doesn't make sense. The real warning here is the need
for WANT_AUTOCONF=2.1


HTH,
Mart

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[William Hubbs]

On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William Hubbs:
> > On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand
> > wrote:
> > > On 06/11/2017 05:24 PM, David Seifert wrote:
> > > > > We can always patch the eclass at that point if that is still a
> > > > > big
> > > > > concern, but I fundamentally agree with William on this,
> > > > > starting
> > > > > point
> > > > > should be fixing it upstream, so can start with a tracking bug
> > > > > on
> > > > > affected packages.
> > > > > 
> > > > 
> > > > Here's a deal: you can start filing + fixing them.
> > > > 
> > > 
> > > The [tracker] is already started, it was determined to add QA
> > > warning
> > > with info on filing upstream bugs in [bug 426262] and the proper
> > > solution is again iterated in [bug 546614], so its not like this is
> > > a
> > > new approach that is being suggested, but sure, we should all file
> > > bugs
> > > when we encounter them.
> > > 
> > > References:
> > > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632
> > > 
> > > [bug 426262]
> > > https://bugs.gentoo.org/show_bug.cgi?id=426262
> > > 
> > > [bug 546614]
> > > https://bugs.gentoo.org/show_bug.cgi?id=546614
> > 
> > It seems that the proper fix to this, even for a package that won't
> > do
> > the fix upstream is to use WANT_AUTOCONF in the ebuild to force the
> > version of autoconf you need.
> 
> No. It appears you don't know how WANT_AUTOCONF works.
 
 From the eclass:

# @ECLASS-VARIABLE: WANT_AUTOCONF
# @DESCRIPTION:
# The major version of autoconf your package needs

That leads me to believe that you can set WANT_AUTOCONF="someversion"
in your ebuild and your package will use that version of autoconf.

If that's wrong, it needs to be fixed and that's a different bug
entirely, but it doesn't change my position on adding this particular
change to autotools.eclass.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Mart Raudsepp]

Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William Hubbs:
> On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand
> wrote:
> > On 06/11/2017 05:24 PM, David Seifert wrote:
> > > > We can always patch the eclass at that point if that is still a
> > > > big
> > > > concern, but I fundamentally agree with William on this,
> > > > starting
> > > > point
> > > > should be fixing it upstream, so can start with a tracking bug
> > > > on
> > > > affected packages.
> > > > 
> > > 
> > > Here's a deal: you can start filing + fixing them.
> > > 
> > 
> > The [tracker] is already started, it was determined to add QA
> > warning
> > with info on filing upstream bugs in [bug 426262] and the proper
> > solution is again iterated in [bug 546614], so its not like this is
> > a
> > new approach that is being suggested, but sure, we should all file
> > bugs
> > when we encounter them.
> > 
> > References:
> > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632
> > 
> > [bug 426262]
> > https://bugs.gentoo.org/show_bug.cgi?id=426262
> > 
> > [bug 546614]
> > https://bugs.gentoo.org/show_bug.cgi?id=546614
> 
> It seems that the proper fix to this, even for a package that won't
> do
> the fix upstream is to use WANT_AUTOCONF in the ebuild to force the
> version of autoconf you need.

No. It appears you don't know how WANT_AUTOCONF works.

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[William Hubbs]

On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand wrote:
> On 06/11/2017 05:24 PM, David Seifert wrote:
> >> We can always patch the eclass at that point if that is still a big
> >> concern, but I fundamentally agree with William on this, starting
> >> point
> >> should be fixing it upstream, so can start with a tracking bug on
> >> affected packages.
> >>
> > Here's a deal: you can start filing + fixing them.
> > 
> 
> The [tracker] is already started, it was determined to add QA warning
> with info on filing upstream bugs in [bug 426262] and the proper
> solution is again iterated in [bug 546614], so its not like this is a
> new approach that is being suggested, but sure, we should all file bugs
> when we encounter them.
> 
> References:
> [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632
> 
> [bug 426262]
> https://bugs.gentoo.org/show_bug.cgi?id=426262
> 
> [bug 546614]
> https://bugs.gentoo.org/show_bug.cgi?id=546614

It seems that the proper fix to this, even for a package that won't do
the fix upstream is to use WANT_AUTOCONF in the ebuild to force the
version of autoconf you need.

Thanks,

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Alexis Ballier]

On Sun, 11 Jun 2017 17:20:49 +0200
Kristian Fiskerstrand  wrote:

> On 06/11/2017 05:17 PM, Mart Raudsepp wrote:
> >> We can always patch the eclass at that point if that is still a big
> >> concern, but I fundamentally agree with William on this, starting
> >> point
> >> should be fixing it upstream, so can start with a tracking bug on
> >> affected packages.  
> > That's a complete useless waste of time, to track some ancient
> > packages that don't get any upstream update anyway. The active ones
> > have updated it long ago. And it'd be a joke to propose last riting
> > for the reason of a file being named configure.in instead of
> > configure.ac.
> > 
> >   
> 
> That determination can be made on a package-by-package basis and fixed
> in ebuild if needed.
> 

Funny thing is that packages still using autoconf 2.1* don't get
any warning and packages setting WANT_AUTOCONF to some older version
will never break...

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Kristian Fiskerstrand]

On 06/11/2017 05:24 PM, David Seifert wrote:
>> We can always patch the eclass at that point if that is still a big
>> concern, but I fundamentally agree with William on this, starting
>> point
>> should be fixing it upstream, so can start with a tracking bug on
>> affected packages.
>>
> Here's a deal: you can start filing + fixing them.
> 

The [tracker] is already started, it was determined to add QA warning
with info on filing upstream bugs in [bug 426262] and the proper
solution is again iterated in [bug 546614], so its not like this is a
new approach that is being suggested, but sure, we should all file bugs
when we encounter them.

References:
[tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632

[bug 426262]
https://bugs.gentoo.org/show_bug.cgi?id=426262

[bug 546614]
https://bugs.gentoo.org/show_bug.cgi?id=546614

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[David Seifert]

On Sun, 2017-06-11 at 17:12 +0200, Kristian Fiskerstrand wrote:
> On 06/11/2017 05:07 PM, Mart Raudsepp wrote:
> > Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William
> > Hubbs:
> > > On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich
> > > wrote:
> > > > On Sat, 10 Jun 2017 13:28:19 +0200
> > > > Jeroen Roovers  wrote:
> > > > 
> > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262
> > > > > + mv configure.{in,ac} || die
> > > > 
> > > > Looks good.
> > > > 
> > > > -- 
> > > > 
> > > >   Sergei
> > > 
> > > -1
> > > 
> > > I think this should be handled by the packages, not at the eclass
> > > level.
> > > 
> > > https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
> > > 
> > > The packages should either mv the configure.in to configure.ac
> > > internally, or better yet, the maintainers should ask upstream
> > > for
> > > their
> > > packages to fix it.
> > 
> > +1, otherwise we will never be able to add/unmask a newer autoconf
> > that
> > doesn't look at configure.in anymore, once such a version
> > eventually
> > happens.
> > 
> 
> We can always patch the eclass at that point if that is still a big
> concern, but I fundamentally agree with William on this, starting
> point
> should be fixing it upstream, so can start with a tracking bug on
> affected packages.
> 

Here's a deal: you can start filing + fixing them.

David

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Kristian Fiskerstrand]

On 06/11/2017 05:17 PM, Mart Raudsepp wrote:
>> We can always patch the eclass at that point if that is still a big
>> concern, but I fundamentally agree with William on this, starting
>> point
>> should be fixing it upstream, so can start with a tracking bug on
>> affected packages.
> That's a complete useless waste of time, to track some ancient packages
> that don't get any upstream update anyway. The active ones have updated
> it long ago. And it'd be a joke to propose last riting for the reason
> of a file being named configure.in instead of configure.ac.
> 
> 

That determination can be made on a package-by-package basis and fixed
in ebuild if needed.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Mart Raudsepp]

Ühel kenal päeval, P, 11.06.2017 kell 17:12, kirjutas Kristian
Fiskerstrand:
> On 06/11/2017 05:07 PM, Mart Raudsepp wrote:
> > Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William
> > Hubbs:
> > > On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich
> > > wrote:
> > > > On Sat, 10 Jun 2017 13:28:19 +0200
> > > > Jeroen Roovers  wrote:
> > > > 
> > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262
> > > > > + mv configure.{in,ac} || die
> > > > 
> > > > Looks good.
> > > > 
> > > > -- 
> > > > 
> > > >   Sergei
> > > 
> > > -1
> > > 
> > > I think this should be handled by the packages, not at the eclass
> > > level.
> > > 
> > > https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
> > > 
> > > The packages should either mv the configure.in to configure.ac
> > > internally, or better yet, the maintainers should ask upstream
> > > for
> > > their
> > > packages to fix it.
> > 
> > +1, otherwise we will never be able to add/unmask a newer autoconf
> > that
> > doesn't look at configure.in anymore, once such a version
> > eventually
> > happens.
> > 
> 
> We can always patch the eclass at that point if that is still a big
> concern, but I fundamentally agree with William on this, starting
> point
> should be fixing it upstream, so can start with a tracking bug on
> affected packages.

That's a complete useless waste of time, to track some ancient packages
that don't get any upstream update anyway. The active ones have updated
it long ago. And it'd be a joke to propose last riting for the reason
of a file being named configure.in instead of configure.ac.

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Kristian Fiskerstrand]

On 06/11/2017 05:07 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William Hubbs:
>> On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich wrote:
>>> On Sat, 10 Jun 2017 13:28:19 +0200
>>> Jeroen Roovers  wrote:
>>>
 https://bugs.gentoo.org/show_bug.cgi?id=426262
 +  mv configure.{in,ac} || die
>>>
>>> Looks good.
>>>
>>> -- 
>>>
>>>   Sergei
>>
>> -1
>>
>> I think this should be handled by the packages, not at the eclass
>> level.
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
>>
>> The packages should either mv the configure.in to configure.ac
>> internally, or better yet, the maintainers should ask upstream for
>> their
>> packages to fix it.
> 
> +1, otherwise we will never be able to add/unmask a newer autoconf that
> doesn't look at configure.in anymore, once such a version eventually
> happens.
> 

We can always patch the eclass at that point if that is still a big
concern, but I fundamentally agree with William on this, starting point
should be fixing it upstream, so can start with a tracking bug on
affected packages.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Mart Raudsepp]

Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William Hubbs:
> On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich wrote:
> > On Sat, 10 Jun 2017 13:28:19 +0200
> > Jeroen Roovers  wrote:
> > 
> > > https://bugs.gentoo.org/show_bug.cgi?id=426262
> > > + mv configure.{in,ac} || die
> > 
> > Looks good.
> > 
> > -- 
> > 
> >   Sergei
> 
> -1
> 
> I think this should be handled by the packages, not at the eclass
> level.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=426262#c3
> 
> The packages should either mv the configure.in to configure.ac
> internally, or better yet, the maintainers should ask upstream for
> their
> packages to fix it.

+1, otherwise we will never be able to add/unmask a newer autoconf that
doesn't look at configure.in anymore, once such a version eventually
happens.

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[William Hubbs]

On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich wrote:
> On Sat, 10 Jun 2017 13:28:19 +0200
> Jeroen Roovers  wrote:
> 
> > https://bugs.gentoo.org/show_bug.cgi?id=426262
> 
> > +   mv configure.{in,ac} || die
> 
> Looks good.
> 
> -- 
> 
>   Sergei

-1

I think this should be handled by the packages, not at the eclass level.

https://bugs.gentoo.org/show_bug.cgi?id=426262#c3

The packages should either mv the configure.in to configure.ac
internally, or better yet, the maintainers should ask upstream for their
packages to fix it.

Thanks,

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Sergei Trofimovich]

On Sat, 10 Jun 2017 13:28:19 +0200
Jeroen Roovers  wrote:

> https://bugs.gentoo.org/show_bug.cgi?id=426262

> + mv configure.{in,ac} || die

Looks good.

-- 

  Sergei


pgpWrrfyNhK6s.pgp
Description: Цифровая подпись OpenPGP

[gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Jeroen Roovers]

https://bugs.gentoo.org/show_bug.cgi?id=426262diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 2710bf827b..76a5c2eade 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -341,10 +341,11 @@ eautoconf() {
 		echo
 		die "No configure.{ac,in} present!"
 	fi
-	if [[ ${WANT_AUTOCONF} != "2.1" && -e configure.in ]] ; then
-		eqawarn "This package has a configure.in file which has long been deprecated.  Please"
-		eqawarn "update it to use configure.ac instead as newer versions of autotools will die"
-		eqawarn "when it finds this file.  See https://bugs.gentoo.org/426262 for details."
+	if [[ ${WANT_AUTOCONF} != "2.1" && -e configure.in && ! -e configure.ac ]] ; then
+		eqawarn "This package has a configure.in file which has long been deprecated. Since no"
+		eqawarn "configure.ac is present either, we rename configure.in to configure.ac. If"
+		eqawarn "this causes problems, please file a bug report and make it block bug #426262."
+		mv configure.{in,ac} || die
 	fi
 
 	autotools_run_tool --at-m4flags autoconf "$@"