[aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276

[Sérgio Basto]

Hi, 
I'm trying follow this (aarch64 support) but 
https://bugzilla.redhat.com/show_bug.cgi?id=922257#c1

"could/should be closed now, as this is done automatically from %
configure", so no need update it anymore ?

we had updated dpkg some major versions sine bug opened, how I know if
dpkg is now ready for aarch64 ? 

Thanks,
-- 
Sérgio M. B.

[Simone Caronni]

On 17 June 2013 03:13, Sérgio Basto <sergio(a)serjux.com&gt; wrote:

>  we had updated dpkg some major versions sine bug opened, how I know
> if
>  dpkg is now ready for aarch64 ?
>  
I've discovered you can trigger builds for the ARM Koji instance with your
account:

koji --server=http://arm.koji.fedoraproject.org/kojihub build --scratch f19
dpkg.src.rpm

Regards,
--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/

[Dan Horák]

On Mon, 17 Jun 2013 08:44:52 +0200
Simone Caronni <negativo17(a)gmail.com&gt; wrote:

>  On 17 June 2013 03:13, Sérgio Basto <sergio(a)serjux.com&gt; wrote:
>  
>  > we had updated dpkg some major versions sine bug opened, how I know
>  > if dpkg is now ready for aarch64 ?
>  >
>  
>  I've discovered you can trigger builds for the ARM Koji instance with
>  your account:
>  
>  koji --server=http://arm.koji.fedoraproject.org/kojihub build
>  --scratch f19 dpkg.src.rpm 
the fedora-packager package provides wrappers for the koji command for
all secondary architectures in Fedora in the form ${arch}-koji, where
arch can be arm, ppc and s390, so you can use

arm-koji build --scratch f19 your.src.rpm


		Dan

[Simone Caronni]

On 17 June 2013 09:04, Dan Horák <dan(a)danny.cz&gt; wrote:

>  the fedora-packager package provides wrappers for the koji command
> for
>  all secondary architectures in Fedora in the form ${arch}-koji, where
>  arch can be arm, ppc and s390, so you can use
>
>  arm-koji build --scratch f19 your.src.rpm
>  
Oh, thanks, I did not know.

--Simone

-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 17 Jun 2013 09:04:02 +0200
Dan Horák <dan(a)danny.cz&gt; wrote:

>  On Mon, 17 Jun 2013 08:44:52 +0200
>  Simone Caronni <negativo17(a)gmail.com&gt; wrote:
>  
>  > On 17 June 2013 03:13, Sérgio Basto <sergio(a)serjux.com&gt; wrote:
>  > 
>  > > we had updated dpkg some major versions sine bug opened, how I
>  > > know if dpkg is now ready for aarch64 ?
>  > >
>  > 
>  > I've discovered you can trigger builds for the ARM Koji instance
>  > with your account:
>  > 
>  > koji --server=http://arm.koji.fedoraproject.org/kojihub build
>  > --scratch f19 dpkg.src.rpm
>  
>  the fedora-packager package provides wrappers for the koji command for
>  all secondary architectures in Fedora in the form ${arch}-koji, where
>  arch can be arm, ppc and s390, so you can use
>  
>  arm-koji build --scratch f19 your.src.rpm
>  
but you can not yet build aarch64 in koji

Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
>
> iEYEARECAAYFAlG+9SAACgkQkSxm47BaWff1RwCfV7Y8ehblXK/PvqdXWnXi8IfW
> IfYAoK9++/dGMjVCZbzPdMrxHxMyMQax
> =PNg5
> -----END PGP SIGNATURE-----
>

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Oron Peled]

On Monday 17 June 2013 02:13:06 Sérgio Basto wrote:
>  Hi,
>  I'm trying follow this (aarch64 support) but
>  https://bugzilla.redhat.com/show_bug.cgi?id=922257#c1
>  
>  "could/should be closed now, as this is done automatically from %
>  configure", so no need update it anymore ?
>  
>  we had updated dpkg some major versions sine bug opened, how I know if
>  dpkg is now ready for aarch64 ? 
When I fixed one of my packages (libhocr), I chose a different fix:
  * Added: BuildRequires: autoconf, automake, libtool, pkgconfig
  * In "%prep" added: autoreconf --install --force

IMO this is better then the new rpm kludge:
  * In autotools based projects, the tarball contain *many* generated files.
     (e.g: configure, config.h.in, config.{guess,sub}, INSTALL, etc.}

  * The only reason they are in the tarball is to enable build without
     the autotools suite (e.g: on other platforms)

  * As such, these files are not [and should not be] committed to version
    control systems.

  * So although they are packages in the source  tarball, they are no
     part of the package real "source" -- they just happen to
     come from the platform of the one who maintain the source tarball.
     (via "make dist")

  * The "autoreconf" solution let autotools handle this complete problem
     without trying to mess in its internals (rpm replacing only some files).

  * As an example how wrong it is for rpm macros to interfere with the
    internal logic of autotools, you could have a look in %GNUconfigure
    macro in /usr/lib/rpm/macros. This one, tries to second guess
    autoconf behavior, but it still search for "configure.in" files.
    (For those who don't know -- while these files are still supported,
     most modern packages correctly renamed them to "configure.ac").

In the Fedora spirit of "everything buildable from clean sources", I think
the "autoreconf" solution should be globally adopted (regardless of aarch64):
  * It doesn't use generated files as input to the build process.
  * It delegates the actual management to where it belongs.

Bye,

-- 
Oron Peled                                 Voice: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
"In theory, there is no difference between theory and practice. In practice, there
is."
        -- Yogi Berra

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Björn Esser]

Am Montag, den 17.06.2013, 11:39 +0300 schrieb Oron Peled:
>  On Monday 17 June 2013 02:13:06 Sérgio Basto wrote:
>  > Hi,
>  > I'm trying follow this (aarch64 support) but
>  > https://bugzilla.redhat.com/show_bug.cgi?id=922257#c1
>  > 
>  > "could/should be closed now, as this is done automatically from %
>  > configure", so no need update it anymore ?
>  > 
>  > we had updated dpkg some major versions sine bug opened, how I know if
>  > dpkg is now ready for aarch64 ?
>  
>  When I fixed one of my packages (libhocr), I chose a different fix:
>    * Added: BuildRequires: autoconf, automake, libtool, pkgconfig
>    * In "%prep" added: autoreconf --install --force
>  
>  IMO this is better then the new rpm kludge:
>    * In autotools based projects, the tarball contain *many* generated files.
>       (e.g: configure, config.h.in, config.{guess,sub}, INSTALL, etc.}
>  
>    * The only reason they are in the tarball is to enable build without
>       the autotools suite (e.g: on other platforms)
>  
>    * As such, these files are not [and should not be] committed to version
>      control systems.
>  
>    * So although they are packages in the source  tarball, they are no
>       part of the package real "source" -- they just happen to
>       come from the platform of the one who maintain the source tarball.
>       (via "make dist")
>  
>    * The "autoreconf" solution let autotools handle this complete problem
>       without trying to mess in its internals (rpm replacing only some files).
>  
>    * As an example how wrong it is for rpm macros to interfere with the
>      internal logic of autotools, you could have a look in %GNUconfigure
>      macro in /usr/lib/rpm/macros. This one, tries to second guess
>      autoconf behavior, but it still search for "configure.in" files.
>      (For those who don't know -- while these files are still supported,
>       most modern packages correctly renamed them to "configure.ac").
>  
>  In the Fedora spirit of "everything buildable from clean sources", I think
>  the "autoreconf" solution should be globally adopted (regardless of aarch64):
>    * It doesn't use generated files as input to the build process.
>    * It delegates the actual management to where it belongs.
>  
>  Bye,
>  
>  -- 
>  Oron Peled                                 Voice: [phone]
>  oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
>  "In theory, there is no difference between theory and practice. In practice, there
> is."
>          -- Yogi Berra
>   
Hi Oron!

I completely agree to this. Using `autoreconf -fi` in %build or %prep
should be mandatory in packages using autotools. This will surely avoid
lots of possible problems caused by just injecting config.{guess,sub} by
%configure.

Cheers,
  Björn

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Jerry James]

On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser <bjoern.esser(a)gmail.com&gt; wrote:
>  I completely agree to this. Using `autoreconf -fi` in %build or
> %prep
>  should be mandatory in packages using autotools. This will surely avoid
>  lots of possible problems caused by just injecting config.{guess,sub} by
>  %configure. 
That would only work if the autotools had perfect backwards
compatibility.  They don't.  I maintain multiple packages where
"autoreconf -fi" with modern autotools fails due to use of obsolete
macros.
--
Jerry James
http://www.jamezone.org/

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Alec Leamas]

On 2013-06-17 16:43, Jerry James wrote:
>  On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser
> <bjoern.esser(a)gmail.com&gt; wrote:
> > I completely agree to this. Using `autoreconf -fi` in %build or %prep
> > should be mandatory in packages using autotools. This will surely avoid
> > lots of possible problems caused by just injecting config.{guess,sub} by
> > %configure.
>  That would only work if the autotools had perfect backwards
>  compatibility.  They don't.  I maintain multiple packages where
>  "autoreconf -fi" with modern autotools fails due to use of obsolete
>  macros.
>  --
>  Jerry James
>  http://www.jamezone.org/ 
Isn't the proper solution then to patch the config
files to get rid of 
the obsolete macros? Such patches should certainly be acceptable upstream.

That said, this and related questions have been discussed in several 
threads over the years. The sad fact is that it hasn't been possible to 
find an agreement how to cope with autotools and that we thus havn't 
much about them in the guidelines.

  What are the chances finding common ground now?

--alec

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Jerry James]

On Mon, Jun 17, 2013 at 8:57 AM, Alec Leamas <leamas.alec(a)gmail.com&gt; wrote:
>  Isn't the proper solution then to patch the config files to get
> rid of the
>  obsolete macros? Such patches should certainly be acceptable upstream. 
If I have some other reason for needing to touch the configure script,
then sure.  (In fact, I have done just that with several projects.
See what I've had to do to the gcl configure script, for example.)  If
not, I'd rather not spend the small amount of time I can devote to
open source software work messing with a configure script just because
somebody thinks they should be able to run autoreconf with a newer
version of the autotools and get away with it.
--
Jerry James
http://www.jamezone.org/

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Alec Leamas]

On 2013-06-17 21:17, Jerry James wrote:
>  On Mon, Jun 17, 2013 at 8:57 AM, Alec Leamas
> <leamas.alec(a)gmail.com&gt; wrote:
> > Isn't the proper solution then to patch the config files to get rid of the
> > obsolete macros? Such patches should certainly be acceptable upstream.
>  If I have some other reason for needing to touch the configure script,
>  then sure.  (In fact, I have done just that with several projects.
>  See what I've had to do to the gcl configure script, for example.)  If
>  not, I'd rather not spend the small amount of time I can devote to
>  open source software work messing with a configure script just because
>  somebody thinks they should be able to run autoreconf with a newer
>  version of the autotools and get away with it.
>  --
>  Jerry James
>  http://www.jamezone.org/ 
Fair enough.  Hope you did not recognize me as one of
those who "just 
thinks they should be able to run autoreconf with a newer version of the 
autotools and get away with it" - that was not my idea. My question mark 
was for real.

My personal feeling is that the old discussion about keeping these files 
and not running autoreconf vs running autoreconf doesn't have a "one 
size fits all" answer.  If we ever will be able to write GL about it, we 
should keep both doors open. Perhaps with a recommendation about one of 
them being preferred, but nothing more drastic. Not perfect, simple and 
clean. But that's what the world is like from time to time.

--alec

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Oron Peled]

On Monday 17 June 2013 22:58:53 Alec Leamas wrote:
>  On 2013-06-17 21:17, Jerry James wrote:
>  > ... I'd rather not spend the small amount of time I can devote to
>  > open source software work messing with a configure script just because
>  > somebody thinks they should be able to run autoreconf with a newer
>  > version of the autotools and get away with it.
>  
>  Fair enough.  Hope you did not recognize me as one of those who "just
>  thinks they should be able to run autoreconf with a newer version of the
>  autotools and get away with it" - that was not my idea. 
Actually, that was me who *hoped* we could get away with this ;-)

>  ... If we ever will be able to write GL about it, we should keep
> both
>  doors open. Perhaps with a recommendation about one of
>  them being preferred, but nothing more drastic. 
Agreed. Let me be more specific:
 * If upstream uses a modern autotools, than "autoreconf" should be preferred
(IMO).
 * If not, we should advise them to modernize (and if we can, try to help them).

Because using very old autotools version isn't so different than using other
very old development tools (think about compilers, support libraries, etc.).
It is "OK", but not the most advisable practice. Helping upstream to
modernize is helping our ecosystem and helping Fedora being "First".

Again, all of this should be *recommendation*. Like Jerry James mentioned,
it should be weighted by the package maintainer against other tasks
which may be more urgent/important.

-- 
Oron Peled                                 Voice: [phone]
oron(a)actcom.co.il                  http://users.actcom.co.il/~oron
"Without the wind, the grass does not move.
 Without software, hardware is useless."
                        -- Tao of Programming

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Michael Schwendt]

On Tue, 18 Jun 2013 01:37:19 +0300, Oron Peled wrote:

>  Let me be more specific:
>   * If upstream uses a modern autotools, than "autoreconf" should be preferred
> (IMO).
>   * If not, we should advise them to modernize (and if we can, try to help them).
>  
IIRC, that has been suggested in the many aarch64 bz tickets recently as
one of several options to fix the issue.

However, to repeat, often one only "touches" the Autotools files when one
really needs to do that. One doesn't regularly examine them for whether
they contain hacks or other problems that only turn up when regenerating
the files in an env that differs from upstream's. Some contain surprises,
such as but not limited to losing preprocessor definitions or using
conflicting variable names.

-- 
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.5-301.fc19.x86_64
loadavg: 0.62 0.23 0.19

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Sérgio Basto]

On Seg, 2013-06-17 at 16:57 +0200, Alec Leamas wrote: 
>  On 2013-06-17 16:43, Jerry James wrote:
>  > On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser <bjoern.esser(a)gmail.com&gt; wrote:
>  >> I completely agree to this. Using `autoreconf -fi` in %build or %prep
>  >> should be mandatory in packages using autotools. This will surely avoid
>  >> lots of possible problems caused by just injecting config.{guess,sub} by
>  >> %configure.
>  > That would only work if the autotools had perfect backwards
>  > compatibility.  They don't.  I maintain multiple packages where
>  > "autoreconf -fi" with modern autotools fails due to use of obsolete
>  > macros.
>  > --
>  > Jerry James
>  > http://www.jamezone.org/
>  Isn't the proper solution then to patch the config files to get rid of 
>  the obsolete macros? Such patches should certainly be acceptable upstream.
>  
>  That said, this and related questions have been discussed in several 
>  threads over the years. The sad fact is that it hasn't been possible to 
>  find an agreement how to cope with autotools and that we thus havn't 
>  much about them in the guidelines.
>  
>    What are the chances finding common ground now? 
I hope so , some guidelines about this would be nice.

Thanks, 
-- 
Sérgio M. B.

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Mathieu Bridon]

On Mon, 2013-06-17 at 16:57 +0200, Alec Leamas wrote:
>  On 2013-06-17 16:43, Jerry James wrote:
>  > On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser <bjoern.esser(a)gmail.com&gt; wrote:
>  >> I completely agree to this. Using `autoreconf -fi` in %build or %prep
>  >> should be mandatory in packages using autotools. This will surely avoid
>  >> lots of possible problems caused by just injecting config.{guess,sub} by
>  >> %configure.
> >
>  > That would only work if the autotools had perfect backwards
>  > compatibility.  They don't.  I maintain multiple packages where
>  > "autoreconf -fi" with modern autotools fails due to use of obsolete
>  > macros.
>
>  Isn't the proper solution then to patch the config files to get rid of 
>  the obsolete macros? Such patches should certainly be acceptable upstream. 
Not necessarily, or at least not reasonably quickly.

Upstream might be running an older version of the Autotools on their
development machine, and not be interested in upgrading it (e.g they run
Debian Stable or RHEL).

So you'd still have to carry that patch downstream until they finally
upgrade and accept your patch, which can take years.


-- 
Mathieu

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Sérgio Basto]

On Seg, 2013-06-17 at 08:43 -0600, Jerry James wrote: 
>  On Mon, Jun 17, 2013 at 2:59 AM, Björn Esser
> <bjoern.esser(a)gmail.com&gt; wrote:
>  > I completely agree to this. Using `autoreconf -fi` in %build or %prep
>  > should be mandatory in packages using autotools. This will surely avoid
>  > lots of possible problems caused by just injecting config.{guess,sub} by
>  > %configure.
>  
>  That would only work if the autotools had perfect backwards
>  compatibility.  They don't.  I maintain multiple packages where
>  "autoreconf -fi" with modern autotools fails due to use of obsolete
>  macros. 
What you are writing is not much common. In fact some times I had to do
the opposite, which is : run autoreconf because we have errors with
configure .


-- 
Sérgio M. B.

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Michael Schwendt]

On Mon, 17 Jun 2013 10:59:06 +0200, Björn Esser wrote:

>  I completely agree to this. Using `autoreconf -fi` in %build or
> %prep
>  should be mandatory in packages using autotools.  
One problem with that is, one cannot "blindly" run autoreconf -fi and
expect it to be 100% compatible with the multitude of Autotools' based
projects. Typically one will need to update the configure script, m4
macros as well as Makefile.{am,in} templates. And if one doesn't verify
the build framework, one can miss files where regenerating them drops
stuff (as one example, config.h.in files where someone has inserted
stuff the wrong way).

-- 
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.5-301.fc19.x86_64
loadavg: 0.13 0.12 0.08

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Ben Boeckel]

On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
>  One problem with that is, one cannot "blindly" run
> autoreconf -fi and
>  expect it to be 100% compatible with the multitude of Autotools' based
>  projects. Typically one will need to update the configure script, m4
>  macros as well as Makefile.{am,in} templates. And if one doesn't verify
>  the build framework, one can miss files where regenerating them drops
>  stuff (as one example, config.h.in files where someone has inserted
>  stuff the wrong way). 
There are also those rare upstreams which run autoreconf once, commit
the generated files, then make "minor" changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving "back" to editing the .in and .ac files
directly.

--Ben

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Jon Masters]

Indeed. This was a concern I raised when we first began the bootstrap. Blindly rerunning
autoreconf in every case is a really bad idea. But doing it in a discretionary way,
allowing the package maintainer to influence what happens (they in theory know whether
this will work for their package and their upstream) is good.

Sent from my Android phone using TouchDown (www.nitrodesk.com)


-----Original Message-----
From: Ben Boeckel [mathstuf(a)gmail.com]
Received: Thursday, 20 Jun 2013, 7:53
To: devel(a)lists.fedoraproject.org
Subject: Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not	support
aarch64 in f19 and rawhide bug #925276)


On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
>  One problem with that is, one cannot "blindly" run
> autoreconf -fi and
>  expect it to be 100% compatible with the multitude of Autotools' based
>  projects. Typically one will need to update the configure script, m4
>  macros as well as Makefile.{am,in} templates. And if one doesn't verify
>  the build framework, one can miss files where regenerating them drops
>  stuff (as one example, config.h.in files where someone has inserted
>  stuff the wrong way). 
There are also those rare upstreams which run autoreconf once, commit
the generated files, then make "minor" changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving "back" to editing the .in and .ac files
directly.

--Ben

-- 
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Alec Leamas]

On 2013-06-20 14:19, Jonathan Masters wrote:
>  Indeed. This was a concern I raised when we first began the
> bootstrap. Blindly rerunning autoreconf in every case is a really bad idea. But doing it
> in a discretionary way, allowing the package maintainer to influence what happens (they in
> theory know whether this will work for their package and their upstream) is good.
>
>  Sent from my Android phone using TouchDown (www.nitrodesk.com)
>
>
>  -----Original Message-----
>  From: Ben Boeckel [mathstuf(a)gmail.com]
>  Received: Thursday, 20 Jun 2013, 7:53
>  To: devel(a)lists.fedoraproject.org
>  Subject: Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not	support
> aarch64 in f19 and rawhide bug #925276)
>
>
>  On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
> > One problem with that is, one cannot "blindly" run autoreconf -fi and
> > expect it to be 100% compatible with the multitude of Autotools' based
> > projects. Typically one will need to update the configure script, m4
> > macros as well as Makefile.{am,in} templates. And if one doesn't verify
> > the build framework, one can miss files where regenerating them drops
> > stuff (as one example, config.h.in files where someone has inserted
> > stuff the wrong way).
>  There are also those rare upstreams which run autoreconf once, commit
>  the generated files, then make "minor" changes to configure and friends
>  directly. Running autoreconf on these projects is bound to fail and
>  upstream might be unhappy moving "back" to editing the .in and .ac files
>  directly.
>
>  --Ben
>
>
>  
Hm... it actually seems that there is a lot of common ground here, and 
quite different from what a newbie  will find if googling [1]. Yes, it's 
an old draft, but in a sense it't the most official document found, I guess.

We have at least three cases?
- Ben's case: projects running auto(re)conf once, then committing and 
maintaining the generated files (and some years later, in desperation, 
goes for cmake...)
- Projects which intitially had a working autotools setup which have 
become more or less unusable in a modern environment.
- Projects which have a well maintained, working autotools setup - here 
it's natural to run autoreconf as part of the build.

Seems that we all agree that the last situation is the preferred one. In 
the other scenarios, it might make make sense to try to help upstream to 
update the obsolete configure.in/ac and Makefile.am. Or it just might 
not, and it's better to use the generated fiels.

This should really be a fpc ticket before we lose everything. However, 
my fpc quota has expired... ;)

--alec

[1] https://fedoraproject.org/wiki/PackagingDrafts/AutoConf

rpm and config.{guess,sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)

[Sérgio Basto]

On Seg, 2013-06-17 at 11:39 +0300, Oron Peled wrote:
>  In the Fedora spirit of "everything buildable from clean
> sources", I
>  think
>  the "autoreconf" solution should be globally adopted (regardless of
>  aarch64):
>    * It doesn't use generated files as input to the build process.
>    * It delegates the actual management to where it belongs. 
Agreed , I will do that on dpkg 

Thanks,
-- 
Sérgio M. B.