rawhide no longer recognizing autotool macros

[Philip Kovacs]

I'm getting new build failures on the autotools macros that had been working for
years.  rpmbuild doesn't likethem anymore in rawhide.  The macros are (or were) in the
file `/usr/lib/rpm/macros`.   The relevant portion of my spec is here:
-- spec -- %build%{__aclocal} -I auxdir%{__autoconf}%{__automake} --no-force
Is there a new dependency I need to add or is something just broken?
Thanks,Phil

[Neal Gompa]

On Tue, Jun 18, 2019 at 10:48 PM Philip Kovacs via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  I'm getting new build failures on the autotools macros that had been working for
> years.  rpmbuild doesn't like
>  them anymore in rawhide.  The macros are (or were) in the file `/usr/lib/rpm/macros`.  
> The relevant portion
>  of my spec is here:
>
>  -- spec --
>  %build
>  %{__aclocal} -I auxdir
>  %{__autoconf}
>  %{__automake} --no-force
>
>  Is there a new dependency I need to add or is something just broken?
>  
Panu ripped them out for rpm 4.15:
https://github.com/rpm-software-management/rpm/pull/691

You can trivially switch to just calling the commands...




--
真実はいつも一つ！/ Always, there's only one truth!

[Philip Kovacs]

 OK, my builds are back in order having removed those macros and replaced them with
commands.
I expect that many package maintainers will be hit with this.
    On Wednesday, June 19, 2019, 12:01:31 AM EDT, Neal Gompa <ngompa13(a)gmail.com&gt;
wrote:  
 
 On Tue, Jun 18, 2019 at 10:48 PM Philip Kovacs via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  I'm getting new build failures on the autotools macros that had been working for
> years.  rpmbuild doesn't like
>  them anymore in rawhide.  The macros are (or were) in the file `/usr/lib/rpm/macros`. 
> The relevant portion
>  of my spec is here:
>
>  -- spec --
>  %build
>  %{__aclocal} -I auxdir
>  %{__autoconf}
>  %{__automake} --no-force
>
>  Is there a new dependency I need to add or is something just broken?
>  
Panu ripped them out for rpm 4.15:
https://github.com/rpm-software-management/rpm/pull/691

You can trivially switch to just calling the commands...




--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Elliott Sales de Andrade]

On Wed, 19 Jun 2019 at 01:18, Philip Kovacs via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  OK, my builds are back in order having removed those macros and replaced them with
> commands.
>
>  I expect that many package maintainers will be hit with this. 
There are in fact only 10 packages using these macros:

$ rg '__(aclocal|auto(conf|make))'
slurm.spec
228:%{__aclocal} -I auxdir
229:%{__autoconf}
230:%{__automake} --no-force

iperf.spec
21:%{__autoconf}

vtun.spec
42:%{__autoconf}

fastbit.spec
87:%{__aclocal} -I tests/m4
88:%{__autoconf}
89:%{__automake} --copy --no-force

libticonv.spec
48:%{__aclocal}
50:%{__automake} --add-missing
51:%{__autoconf}

iec16022.spec
45:%{__autoconf}

OpenIPMI.spec
93:%{__aclocal}
95:%{__automake} --add-missing --copy --foreign --force-missing
96:%{__autoconf}

lucidlife.spec
37:%{__autoconf}

trafshow.spec
44:%__autoconf

qrencode.spec
45:%{__autoconf}

>  On Wednesday, June 19, 2019, 12:01:31 AM EDT, Neal Gompa <ngompa13(a)gmail.com&gt;
> wrote:
>
>
>  On Tue, Jun 18, 2019 at 10:48 PM Philip Kovacs via devel
>
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  >
>  > I'm getting new build failures on the autotools macros that had been working for
> years.  rpmbuild doesn't like
>  > them anymore in rawhide.  The macros are (or were) in the file
> `/usr/lib/rpm/macros`.  The relevant portion
>  > of my spec is here:
>  >
>  > -- spec --
>  > %build
>  > %{__aclocal} -I auxdir
>  > %{__autoconf}
>  > %{__automake} --no-force
>  >
>  > Is there a new dependency I need to add or is something just broken?
>
>  >
>
>  Panu ripped them out for rpm 4.15:
>  https://github.com/rpm-software-management/rpm/pull/691
>
>  You can trivially switch to just calling the commands...
>
>
>
>
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 


-- 
Elliott

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jun 19, 2019 at 01:21:38AM -0400, Elliott Sales de Andrade wrote:
>  On Wed, 19 Jun 2019 at 01:18, Philip Kovacs via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  >
>  > OK, my builds are back in order having removed those macros and replaced them with
> commands.
>  >
>  > I expect that many package maintainers will be hit with this. 
Yes. Let's change the expectation here: if you are a maintainer
introducing a change in your package that will impact many other
packages, please either
a) (preferably) just fix the dependent packages if easy
or
b) communicate widely at fedora-devel *in advance*.

We don't want to have confused packagers on fedora-devel, and we certainly
don't want packages failing in the mass rebuilds because of things that
are easily avoided.

In this case option a) is trivial, so I went ahead an run 'sed -r -i' over the
specs Elliot listed, removing __aclocal, __autoconf, __automake, __autoheader,
__libtoolize.
I pushed the changes directly to git. 8 packages build OK with rpm-4.14.90, OpenIMPI fails
for
unrelated reasons. slurm was already fixed.

Zbyszek

[Panu Matilainen]

On 6/19/19 11:40 AM, Zbigniew Jędrzejewski-Szmek wrote:
>  On Wed, Jun 19, 2019 at 01:21:38AM -0400, Elliott Sales de Andrade
> wrote:
> > On Wed, 19 Jun 2019 at 01:18, Philip Kovacs via devel
> > <devel(a)lists.fedoraproject.org&gt; wrote:
> >>
> >> OK, my builds are back in order having removed those macros and replaced them
> with commands.
> >>
> >> I expect that many package maintainers will be hit with this.
>  
>  Yes. Let's change the expectation here:  
I don't see there's any change in expectation involved...

>  if you are a maintainer
>  introducing a change in your package that will impact many other
>  packages, please either
>  a) (preferably) just fix the dependent packages if easy
>  or
>  b) communicate widely at fedora-devel *in advance*.
>  
>  We don't want to have confused packagers on fedora-devel, and we certainly
>  don't want packages failing in the mass rebuilds because of things that
>  are easily avoided. 
Of course. But "many" is such a relative term. The __auto* macro (ab)use 
is such a tiny minority that I frankly didn't even remember removing 
them, much less think of "announcing" that we removed some internal 
cruft (which it is from rpm POV). The perl and python changes were
an entirely different matter, and were communicated and coordinated 
although clearly mistakes were made there too and it could've gone 
smoother. Too long since the last major update, routines get rusty.

>  In this case option a) is trivial, so I went ahead an run 'sed -r
> -i' over the
>  specs Elliot listed, removing __aclocal, __autoconf, __automake, __autoheader,
> __libtoolize.
>  I pushed the changes directly to git. 8 packages build OK with rpm-4.14.90, OpenIMPI
> fails for
>  unrelated reasons. slurm was already fixed. 
Yes, a) is trivial ... if you're a provenpackager. I'm not ;)

Anyway, thanks.

	- Panu -

>  Zbyszek
>

[Philip Kovacs]

I notice I am still using the `__make` macro in my specs.  While they still work, should
we proactively replace them with `make` ?
The additional message I am getting here is that the under-under macros might be subject
to removal.
ThanksPhil

[Christophe de Dinechin]

>  On 19 Jun 2019, at 17:28, Philip Kovacs via devel
> <devel(a)lists.fedoraproject.org&gt; wrote:
>  
>  I notice I am still using the `__make` macro in my specs.  While they still work, should
> we proactively replace them with `make` ? 
Is there any downside in replacing it?

>  
>  The additional message I am getting here is that the under-under macros might be subject
> to removal.
>  
>  Thanks
>  Phil
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Vitaly Zaitsev]

Hello, Philip Kovacs via devel.

Wed, 19 Jun 2019 15:28:10 +0000 (UTC) you wrote:

>  I notice I am still using the `__make` macro in my specs.  While
> they
>  still work, should we proactively replace them with `make` ? 
You can use %make_build and %make_install instead.

--
Sincerely,
 Vitaly Zaitsev (vitaly(a)easycoding.org)

[Philip Kovacs]

 I use those macros wherever possible, but sometimes I need a raw `make`in order to
specify uncommon targets.
I'll just replace `__make` with `make` for now.   No harm there.    On Wednesday, June
19, 2019, 12:06:44 PM EDT, Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org&gt;
wrote:  
 
 Hello, Philip Kovacs via devel.

Wed, 19 Jun 2019 15:28:10 +0000 (UTC) you wrote:

>  I notice I am still using the `__make` macro in my specs.  While
> they
>  still work, should we proactively replace them with `make` ? 
You can use %make_build and %make_install instead.

--
Sincerely,
 Vitaly Zaitsev (vitaly(a)easycoding.org)
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Pavel Raiskup]

On Wednesday, June 19, 2019 6:27:31 PM CEST Philip Kovacs via devel wrote:
>   I use those macros wherever possible, but sometimes I need a raw
> `make`in
>   order to specify uncommon targets.  I'll just replace `__make` with `make`
>   for now.   No harm there.  
$ rpm --eval %make_build
/usr/bin/make -O -j8

So you can simply do `%make_build uncommon-target`.

Pavel

[Panu Matilainen]

On 6/19/19 6:59 AM, Neal Gompa wrote:
>  On Tue, Jun 18, 2019 at 10:48 PM Philip Kovacs via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
> >
> > I'm getting new build failures on the autotools macros that had been working for
> years.  rpmbuild doesn't like
> > them anymore in rawhide.  The macros are (or were) in the file `/usr/lib/rpm/macros`.
>   The relevant portion
> > of my spec is here:
> >
> > -- spec --
> > %build
> > %{__aclocal} -I auxdir
> > %{__autoconf}
> > %{__automake} --no-force
> >
> > Is there a new dependency I need to add or is something just broken?
> >
>  
>  Panu ripped them out for rpm 4.15:
>  https://github.com/rpm-software-management/rpm/pull/691
>  
>  You can trivially switch to just calling the commands...
>   
...which is what those packages should've been using in the first place.

This goes to ALL those %__foo macros on random utilities: their raison 
d'être is to allow users to change rpm behavior without recompiling.

They're not really intended to be directly used, never were. The two 
leading underscores are a hint of that, although one leading underscore 
is so widely used for non-internal purposes too that the meaning has 
become obscured. Unfortunately.

	- Panu -