lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 1 Jul 2014 10:55:51 +0100
From:	"Burton, Ross" <ross.burton@...el.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: Generated files in e2fsprogs git repo

On 1 July 2014 02:02, Theodore Ts'o <tytso@....edu> wrote:
> I don't trust autoreconf.  Different versions of autoconf can end up
> with different incompatible versions of autoconf macros, and I have
> seen some rather disastrous failures as a result.  That's why I update
> autoconf under my control, and if you run autoreconf as a user, and it
> breaks because the "archaic macros" work, and the "new shiny" macros
> fail, that's your problem, and I will laugh at you....

I disagree with this position: if you're the one releasing the
tarballs then you have this control anyway - people building from git
have a higher level of technical competence assumed and using the
right versions of autoconf isn't rocket science.

My context is that we're building distributions and for every package
that uses autotools we forcibly autoreconf because the
upstream-provided configure is generally insufficient: for example
upstream libtool needs patches to cross-compile correctly, and there's
a long lag (several years) between a new architecture being developed
(two recent examples: x32 and aarch64) and it being wide-spread enough
to be in every generated configure script.

e2fsprogs is one of the handful that breaks when we do this, because
aclocal.m4 contains macros that don't come from the system (AX_TLS and
CHECK_GNU_MAKE).  Simply moving these macros to acinclude.m4 should
solve this problem for us: autoconf defines that aclocal.m4 contains
copies of macros from the system, but acinclude.m4 contains
project-specific macros.  I'll send a patch shortly to implement this
split.

Ross
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists