Re: GNU Automake 1.16 released
ed and some 'foo_SOURCES' definition > contains unexpanded references to make variables, as in, e.g.: > > a_src = sources/libs/aaa > b_src = sources/bbb > foo_SOURCES = $(a_src)/bar.c $(b_src)/baz.c > > With such a setup, the created makefile fragment containing dependency > tracking information will be correctly placed under the directories > named 'sources/libs/aaa/.deps' and 'sources/bbb/.deps', rather than > mistakenly under directories named (literally!) '$(src_a)/.deps' and > '$(src_b)/.deps' (this was the first part of automake bug#13928). > > Notice that in order to fix this bug we had to slightly change the > semantics of how config.status bootstraps the makefile fragments > required for the dependency tracking to work: rather than attempting > to parse the Makefiles via grep and sed trickeries only, we actually > invoke 'make' on a slightly preprocessed version of those Makefiles, > using a private target that is only meant to bootstrap the required > makefile fragments. > > - The 'subdir-object' option no longer causes object files corresponding > to source files specified with an explicit '$(srcdir)' component to be > placed in the source tree rather than in the build tree. > > For example, if Makefile.am contains: > > AUTOMAKE_OPTIONS = subdir-objects > foo_SOURCES = $(srcdir)/foo.c $(srcdir)/s/bar.c $(top_srcdir)/baz.c > > then "make all" will create 'foo.o' and 's/bar.o' in $(builddir) rather > than in $(srcdir), and will create 'baz.o' in $(top_builddir) rather > than in $(top_srcdir). > > This was the second part of automake bug#13928. > > - Installed 'aclocal' m4 macros can now accept installation directories > containing '@' characters (automake bug#20903) > > - "./configure && make dist" no longer fails when a distributed file depends > on one from BUILT_SOURCES. > > - When combining AC_LIBOBJ or AC_FUNC_ALLOCA with the > "--disable-dependency-tracking" configure option in an out of source > build, the build sub-directory defined by AC_CONFIG_LIBOBJ_DIR is now > properly created. (automake bug#27781) > > - The time printed by 'mdate-sh' is now using the UTC time zone to support > the reproducible build effort. (automake bug#20314) > > - The elisp byte-compilation rule now uses byte-compile-dest-file-function, > rather than byte-compile-dest-file, which was obsoleted in 2009. We expect > that Emacs-26 will continue to support the old function, but will complain > loudly, and that Emacs-27 will remove support for it altogether. > > * New features added > > - A custom testsuite driver for the Guile Scheme SRFI-64 API has been added > to the "contrib" section. This allows a more convenient way to test Guile > code without having to use low primitives such as exit status. See > SRFI-64 API specification for more details: > <https://srfi.schemers.org/srfi-64/srfi-64.html> > > -- Eric Dorland <e...@kuroneko.ca> 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
bug#20314: [PATCH] Make output of mdate-sh deterministic
This is a good change but it's not enough unfortunately to make it reproducible. mdate-sh also needs to support SOURCE_DATE_EPOCH. I'm working on a patch for that. * Mathieu Lirzin (m...@gnu.org) wrote: > Hello, > > Reiner Herrmann <rei...@reiner-h.de> writes: > > > mdate-sh pretty-prints the modification time of a file. > > But it's output can vary depending on the timezone of > > the caller. Someone in timezone GMT-12 will get a different > > result (day) than someone in timezone GMT+12. > > > > As this output is also used to create/update stamp files, > > which influence the further build process, the build result > > can vary. > > To enable reproducible builds and to have a more deterministic > > build behavior, this change fixes the timezone to UTC. > > > > Signed-off-by: Reiner Herrmann <rei...@reiner-h.de> > > --- > > lib/mdate-sh | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > Applied with slight modifications in commit > 7c25c996d1c7c212a5981aa0e9c4434b6f33f7b8 > > Thanks. > -- Eric Dorland <e...@kuroneko.ca> 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: PGP signature
bug#20314: Bug#782345: automake: mdate-sh has undeterministic output
* Reiner Herrmann (rei...@reiner-h.de) wrote: Source: automake-1.14 Version: 1:1.14.1-4 Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain Tags: upstream X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org Hi! While working on Debian's “reproducible builds” effort [1], we have noticed that the output of mdate-sh (which is part of automake, and shipped by some upstream source tarballs) can produce different output depending on the timezone. Different output of mdate-sh can then lead to further differences in the build process [2]. We already forwarded a patch to automake-patc...@gnu.org, but it hasn't appeared yet in their mailing list archive (which looks a little dead with no new mails since January). The patch [3] fixes the timezone used by mdate-sh to UTC, which will always produce the same output independent of the timezone of the caller. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds [2]: https://wiki.debian.org/ReproducibleBuilds/TimezoneVarianceBecauseOfAutomakeMdate [3]: https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150406/001380.html -- Eric Dorland e...@kuroneko.ca 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
bug#20314: Bug#782345: automake: mdate-sh has undeterministic output
Control: tags -1 patch Patch forwarded upstream. * Reiner Herrmann (rei...@reiner-h.de) wrote: Source: automake-1.14 Version: 1:1.14.1-4 Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain Tags: upstream X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org Hi! While working on Debian's “reproducible builds” effort [1], we have noticed that the output of mdate-sh (which is part of automake, and shipped by some upstream source tarballs) can produce different output depending on the timezone. Different output of mdate-sh can then lead to further differences in the build process [2]. We already forwarded a patch to automake-patc...@gnu.org, but it hasn't appeared yet in their mailing list archive (which looks a little dead with no new mails since January). The patch [3] fixes the timezone used by mdate-sh to UTC, which will always produce the same output independent of the timezone of the caller. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds [2]: https://wiki.debian.org/ReproducibleBuilds/TimezoneVarianceBecauseOfAutomakeMdate [3]: https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150406/001380.html -- Eric Dorland e...@kuroneko.ca 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
[PATCH] Fix typo in README, from http://bugs.debian.org/710400.
--- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index fdf25fa..8f6f928 100644 --- a/README +++ b/README @@ -48,7 +48,7 @@ be informed, subscribe to that list by following the instructions at http://lists.gnu.org/mailman/listinfo/autotools-announce. For any copyright year range specified as - in this package, -that the range specifies every single year in that closed interval. +note that the range specifies every single year in that closed interval. - -- 2.1.4 -- Eric Dorland e...@kuroneko.ca 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93 signature.asc Description: Digital signature
bug#16841: Bug#738716: automake: Generates syntax error in configure script
* Hilko Bengen (ben...@debian.org) wrote: Source: automake-1.14 Version: 1:1.14.1-2 Severity: critical Tags: patch While trying to build a new version of nbdkit, I fonud that a freshly generated configure script contains a syntax error: , | $ curl -O http://libguestfs.org/download/nbdkit/nbdkit-1.1.4.tar.gz | [...] | $ tar xzf nbdkit-1.1.4.tar.gz | $ cd nbdkit-1.1.4/ | $ autoreconf | $ ./configure | [...] | checking for style of include used by make... GNU | checking whether make supports nested variables... yes | checking dependency style of gcc... gcc3 | ./configure: line 4820: syntax error near unexpected token `case' | ./configure: line 4820: `fi case `pwd` in' ` To me, this looks like a missing newline at the end of AM_INIT_AUTOMAKE in /usr/share/aclocal-1.14/init.m4. At least the attached patch fixes the problem for me. It looks like the problem is the dnl on your AM_INIT_AUTOMAKE line: AM_INIT_AUTOMAKE(foreign) dnl NB: Do not [quote] this parameter. That's suppressing the natural new line that would be there. But I think the patch is legitimate so forwarding it along. --- /usr/share/aclocal-1.14/init.m4.orig2014-02-12 09:45:22.883382346 +0100 +++ /usr/share/aclocal-1.14/init.m4 2014-02-12 09:45:40.758921507 +0100 @@ -164,7 +164,8 @@ END AC_MSG_ERROR([Your 'rm' program is bad, sorry.]) fi -fi]) +fi +]) dnl Hook into '_AC_COMPILER_EXEEXT' early to learn its expansion. Do not dnl add the conditional right here, as _AC_COMPILER_EXEEXT may be further -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: GNU Automake 1.14 released
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote: [Re-adding the list, sorry for the confusion] On 08/12/2013 06:16 AM, Eric Dorland wrote: * Stefano Lattarini (stefano.lattar...@gmail.com) wrote: Hi everybody. (You didn't reply to the list, did you mean that?) No, thanks for noticing. I'm re-adding the list. Sorry for the delay, Ditto. but real life is being quite intrusive these days (so expect similar delays in the near future as well; sorry!) On 09/08/13 07:55, Eric Dorland wrote: * Dan Kegel (d...@kegel.com) wrote: On Thu, Aug 8, 2013 at 4:43 PM, Eric Dorland e...@debian.org wrote: That sounds kind of risky, promises of compatibility notwithstanding. Can you elaborate why? No. I'm just being paranoid. But there is good precedent for paranoia being the right setting in matters of backwards compatibility. If the promise of compatibility is real, what's the downside? I can think of two: 1) users wanting to check to see if their code is compatible with automake-1.13 2) users wanting to regenerate the same data file as automake-1.13 did, to avoid unneeded diffs While I can sympathize with these use cases, Debian isn't there to provide every version of automake. The vast majority of packages do not get multiple versioned in Debian and when we do it's almost always the minimum number of versions necessary. If these are the only use cases I don't think that justifies carrying the extra version. Well, we now promise to be *mostly* compatible between minor releases, but also explicitly state that we might break such compatibility in corner case if that is done to fix bugs or broken behaviours (while between micro releases, not even that form of compatibility breakage is acceptable). This is not merely theoretical -- here is an example of such a bugfix: http://comments.gmane.org/gmane.comp.sysutils.automake.bugs/6367 Or, for a more recent example, take a look at the C compilation, and the AC_PROG_CC and AM_PROG_CC_C_O macros section of the Automake 1.14 announcement: http://lists.gnu.org/archive/html/automake/2013-06/msg00040.html As long as the number of users affected as small, ie it affects a very small percentage of Makefile.am's then I don't really see this as a problem. The author of those Makefiles might disagree. I'm sure they would, but as long as they're a small enough minority I think this is still justifiable. For example I hope you would be unwilling to break 25% of Makefile.am's even if they're relying on some undocumented behavior in a minor release. Yes, I would be unwilling. But I've also learned that it's often difficult to estimate which percentage of Makefiles can be broken by an apparently minor incompatibility... I'm sure it is. But as long as you're willing to roll back that sort of breakage once you learn about it I'm not *too* concerned. Another point is that we feel free to introduce new non-fatal deprecation warnings in new minor release, so a Makefile.am that was perfectly valid with Automake 1.13 could cause Automake 1.14 to spew tons of warnings (albeit the generated makefile should keep working as expected). I don't really see that as a problem or a good reason to keep lots of versions of automake in Debian. Well, you being the maintainer for the Automake Debian package, that decision is up to you. I'm just offering my opinion; then we can agree to disagree, without problem. Indeed, that's why we're having this conversation :) I just want to make sure I understand what you're promising with the new version scheme so that expectations can be met. In the end, I'd like for APIVERSION to remain based on the minor version number. It seems less risky that way. It's safer I suppose but it doesn't really seem correct. Sometimes safer is better IMHO. If I were sticking my neck out, I'd keep on with the old scheme, where automake-1.13 means automake 1.13. It would surprise people less. This is what I'd prefer as well. I'm still not convinced it's necessary. There's a lot of cost and confusion to keeping so many versions. There is a trade-off, sure. Deciding whether or not this cost is worth paying in Debian is up to you (my opinion is that it is worth, as you might have surmised). So I've upgraded the automake pacakage in unstable to 1.14. In a future upload I'm planning to make that package provide automake1.13 so that if anyone wants automake1.13 they'll get automake 1.14. If there's any complaining this is easy enough to undo, where we provide a dedicated automake1.13 package and drop the provides from the 1.14 version. Sounds acceptable? Well I think if it doesn't work it shouldn't be difficult to down the road provide an automake1.13 package. So the risk doesn't seem that high. But you will still surprise users in the two categories I mentioned
Re: GNU Automake 1.14 released
* Dan Kegel (d...@kegel.com) wrote: On Thu, Aug 8, 2013 at 4:43 PM, Eric Dorland e...@debian.org wrote: That sounds kind of risky, promises of compatibility notwithstanding. Can you elaborate why? No. I'm just being paranoid. But there is good precedent for paranoia being the right setting in matters of backwards compatibility. If the promise of compatibility is real, what's the downside? I can think of two: 1) users wanting to check to see if their code is compatible with automake-1.13 2) users wanting to regenerate the same data file as automake-1.13 did, to avoid unneeded diffs While I can sympathize with these use cases, Debian isn't there to provide every version of automake. The vast majority of packages do not get multiple versioned in Debian and when we do it's almost always the minimum number of versions necessary. If these are the only use cases I don't think that justifies carrying the extra version. If I were sticking my neck out, I'd keep on with the old scheme, where automake-1.13 means automake 1.13. It would surprise people less. Well I think if it doesn't work it shouldn't be difficult to down the road provide an automake1.13 package. So the risk doesn't seem that high. But you will still surprise users in the two categories I mentioned. - Dan -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: GNU Automake 1.14 released
* Eric Dorland (e...@debian.org) wrote: Hi Stefano, I was just getting around to packaging this for Debian and I have a question. Given the new versioning scheme shouldn't the APIVERSION (as defined in configure.ac) be 1.13 and not 1.14? Or more precisely, does it make sense for the binary to be renamed given that this release should have no backwards incompatibility with 1.13? OK given the lack of response I'll just describe my plan for Debian for 1.14 and people can yell if they think I'm doing it wrong. Previously I would upgrade the automake package to the latest version and add a new binary package for the previous version. So, for example, if automake was at version 1.10 and 1.11 was released upstream I would update the automake package to 1.11 and create a new automake1.10 package for people who couldn't deal with the backwards incompatibility. Given the new version scheme, 1.14 should be backwards compatible with 1.13. So my plan is to upgrade the automake package to 1.14, have it Provides: automake1.13 and add symlinks from /usr/bin/automake-1.13 to /usr/bin/automake-1.14 (since 1.14 creates only the automake-1.14 binary). I will not provide an automake1.13 package with the older version since that doesn't make sense if 1.14 is properly backwards compatible. Makes sense? Any questions, comments or concerns? -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: GNU Automake 1.14 released
* Dan Kegel (d...@kegel.com) wrote: On Thu, Aug 8, 2013 at 2:39 PM, Eric Dorland e...@debian.org wrote: Previously I would upgrade the automake package to the latest version and add a new binary package for the previous version. So, for example, if automake was at version 1.10 and 1.11 was released upstream I would update the automake package to 1.11 and create a new automake1.10 package for people who couldn't deal with the backwards incompatibility. Given the new version scheme, 1.14 should be backwards compatible with 1.13. So my plan is to upgrade the automake package to 1.14, have it Provides: automake1.13 and add symlinks from /usr/bin/automake-1.13 to /usr/bin/automake-1.14 (since 1.14 creates only the automake-1.14 binary). I will not provide an automake1.13 package with the older version since that doesn't make sense if 1.14 is properly backwards compatible. That sounds kind of risky, promises of compatibility notwithstanding. Can you elaborate why? If the promise of compatibility is real, what's the downside? If I were sticking my neck out, I'd keep on with the old scheme, where automake-1.13 means automake 1.13. It would surprise people less. Well I think if it doesn't work it shouldn't be difficult to down the road provide an automake1.13 package. So the risk doesn't seem that high. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: GNU Automake 1.14 released
' variable, and not in a 'ac_cv_prog_cc_*_c_o' variable whose exact name is dynamically computed only at configure runtime (really!) from the content of the '$CC' variable. 3. It no longer automatically AC_DEFINE the C preprocessor symbol 'NO_MINUS_C_MINUS_O'. * Texinfo support: - Automake can now be instructed to place '.info' files generated from Texinfo input in the builddir rather than in the srcdir; this is done specifying the new automake option 'info-in-builddir'. This feature was requested by the developers of GCC, GDB, GNU binutils and the GNU bfd library. See the extensive discussion about automake bug#11034 for more details. - For quite a long time, Automake has been implementing an undocumented hack which ensured that '.info' files which appeared to be cleaned (by being listed in the CLEANFILES or DISTCLEANFILES variables) were built in the builddir rather than in the srcdir; this hack was introduced to ensure better backward-compatibility with package such as Texinfo, which do things like: info_TEXINFOS = texinfo.txi info-stnd.texi info.texi DISTCLEANFILES = texinfo texinfo-* info*.info* # Do not create info files for distribution. dist-info: @: in order not to distribute generated '.info' files. Now that we have the 'info-in-builddir' option that explicitly causes generated '.info' files to be placed in the builddir, this hack should be longer necessary, so we deprecate it with runtime warnings. It will likely be removed altogether in Automake 2.0. * Relative directory in Makefile fragments: - The special Automake-time substitutions '%reldir%' and '%canon_reldir%' (and their short versions, '%D%' and '%C%' respectively) can now be used in an included Makefile fragment. The former is substituted with the relative directory of the included fragment (compared to the top-level including Makefile), and the latter with the canonicalized version of the same relative directory. # in 'Makefile.am': bin_PROGRAMS = # will be updated by included Makefile fragments include src/Makefile.inc # in 'src/Makefile.inc': bin_PROGRAMS += %reldir%/foo %canon_reldir%_foo_SOURCES = %reldir%/bar.c This should be especially useful for packages using a non-recursive build system. * Deprecated distribution formats: - The 'shar' and 'compress' distribution formats are deprecated, and scheduled for removal in Automake 2.0. Accordingly, the use of the 'dist-shar' and 'dist-tarZ' will cause warnings at automake runtime (in the 'obsolete' category), and the recipes of the Automake-generated targets 'dist-shar' and 'dist-tarZ' will unconditionally display (non-fatal) warnings at make runtime. * New configure runtime warnings about rm -f support: - To simplify transition to Automake 2.0, the shell code expanded by AM_INIT_AUTOMAKE now checks (at configure runtime) that the default 'rm' program in PATH doesn't complain when called without any non-option argument if the '-f' option is given (so that commands like rm -f and rm -rf act as a no-op, instead of raising usage errors). If this is not the case, the configure script is aborted, to call the attention of the user on the issue, and invite him to fix his PATH. The checked 'rm' behavior is very widespread in the wild, and will be required by future POSIX versions: http://austingroupbugs.net/view.php?id=542 The user can still force the configure process to complete even in the presence of a broken 'rm' by defining the ACCEPT_INFERIOR_RM_PROGRAM environment variable to yes. And the generated Makefiles should still work correctly even when such broken 'rm' is used. But note that this will no longer be the case with Automake 2.0 though, so, if you encounter the warning, please report it to us ASAP (and try to fix your environment as well). -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: [IMPORTANT] A new versioning scheme for automake releases, and a new branching scheme for the Git repository
, or documentation issues, and no active development whatsoever. * The 'master' branch will be where the development of the next minor release will take place; that is, a sort of middle-ground between the roles so far fulfilled by the 'maint' and 'master' branches in the current branching scheme. * The (new) 'next' branch will be reserved for the development of the next major release; it will basically take over the rule that is currently fulfilled by the 'master' branch. * 'maint' will be kept regularly merged into 'master', and 'master' into 'next' (and 'next' into the 'ng/master', which is where the Automake-NG codebase currently live). * Feature branches should typically be based off of 'master', and we can decide later whether to eventually merge them into 'master' or into 'next'. * None of 'maint', 'master' and 'next' should be rewindable. If you agree with my proposal, I think the new schemes could be implemented right after the 1.13.2 release; so that the planned Automake 1.13.3 will be released as 1.14, and the planned Automake 1.14 will be released as Automake 2.0. I think it would be better to start with the planned 1.14 (aka 2.0) rather than with 1.13.3. It makes it a cleaner break for people (aka Debian to some degree) who were relying on the old versioning scheme. And of course, we'll have to publicize the new versioning scheme ASAP, and with quite high visibility. I propose the following avenues: - A news item in the savannah AUtomake page; - A message to autotools-announce; - An entry in the NEWS file of 1.13.2. - ??? (suggestions welcome) -*-*- Feedback, opinions, objections? Regards, Stefano -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote: On 07/13/2012 12:51 PM, Diego Elio Pettenò wrote: Il 13/07/2012 10:50, Stefano Lattarini ha scritto: Well, I'm really disappointed that nobody reported this upstream to us; our non-Debian users would have been saved from two and a half years of potential vulnerability :-/ It's worth noting that I just checked and Gentoo also applies the same patch, for us started by https://bugs.gentoo.org/show_bug.cgi?id=295357 The report quoted there refers to Jim who, if I'm not mistaken, works for RedHat, so I guess RHEL/Fedora/Centos are covered as well. Ah but *that* bug (CVE-2009-4029, which affected not only make distcheck but also make dist) was fixed in Automake proper as well. However, a stray chmod a+w $(distdir) in the distcheck target was somehow missed in the fix, and that caused CVE-2012-3386. So these are two different issues, not to be confused. So as much as I'd like to blame Debian, it's not really their fault :) Looking more carefully, they fixed the (equivalent of CVE-2012-3386) for Automake 1.4 (probably because they had to manually backport the patch anyway, so looked for all the occurrences of chmod 777), but they did *not* fix it for the more modern versions (e.g., Automake 1.11), probably being convinced it had been solved as part of the fix for CVE-2009-4029; so I spoke too fast and inconsiderately by accusing them so somehow withold a security fix from upstream. I didn't write the patch but I expect that's what happened. So, Debian developers: sorry for the confusion, and please accept my apologies. No worries. Thanks, Stefano -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote: On 07/10/2012 12:14 AM, Eric Dorland wrote: Are older versions of automake also vulnerable? Yes, all those back to 1.4 (at least). Sorry for not stating that explicitly. So I'm not obviously finding this vulnerability in automake 1.4. The code has changed a lot clearly since then, but I'm not even finding a chmod that looks similar. Can anyone confirm this problem is present in automake 1.4? -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote:
On 07/12/2012 08:23 PM, Eric Dorland wrote:
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote:
On 07/10/2012 12:14 AM, Eric Dorland wrote:
Are older versions of automake also vulnerable?
Yes, all those back to 1.4 (at least). Sorry for not stating that
explicitly.
So I'm not obviously finding this vulnerability in automake 1.4. The
code has changed a lot clearly since then, but I'm not even finding a
chmod that looks similar. Can anyone confirm this problem is present
in automake 1.4?
--
Git Repository
--
$ git clone git://git.savannah.gnu.org/automake.git
$ cd automake
$ git checkout Release-1-4-p6
$ git grep -C3 'chmod 777.*distdir'
Makefile.in-distdir: $(DISTFILES)
Makefile.in--rm -rf $(distdir)
Makefile.in-mkdir $(distdir)
Makefile.in:-chmod 777 $(distdir)
Makefile.in-here=`cd $(top_builddir) pwd`; \
Makefile.in-top_distdir=`cd $(distdir) pwd`; \
Makefile.in-distdir=`cd $(distdir) pwd`; \
Thanks! It looks like this was actually fixed in Debian a few years
ago as part of the CVE-2009-4029
(http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4029)
fix. Patch attached. You can see the source for the package at
http://anonscm.debian.org/gitweb/?p=users/eric/automake.git;a=summary. Looks
good?
--
Eric Dorland e...@kuroneko.ca
ICQ: #61138586, Jabber: ho...@jabber.com
commit 1b276fa9a29e624d19745581f37ab6f516329964
Author: Eric Dorland e...@debian.org
Date: Sat May 26 23:06:59 2012 -0400
Non-maintainer upload by the Security Team.
* Non-maintainer upload by the Security Team.
* Fixed CVE-2009-4029: do not assign insecure permissions to directories in
build tree.
diff --git a/Makefile.in b/Makefile.in
index 73f4cf3..b38b279 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -457,7 +457,7 @@ dist-all: distdir
distdir: $(DISTFILES)
-rm -rf $(distdir)
mkdir $(distdir)
- -chmod 777 $(distdir)
+ -chmod 755 $(distdir)
here=`cd $(top_builddir) pwd`; \
top_distdir=`cd $(distdir) pwd`; \
distdir=`cd $(distdir) pwd`; \
@@ -478,7 +478,7 @@ distdir: $(DISTFILES)
test -d $(distdir)/$$subdir \
|| mkdir $(distdir)/$$subdir \
|| exit 1; \
- chmod 777 $(distdir)/$$subdir; \
+ chmod 755 $(distdir)/$$subdir; \
(cd $$subdir $(MAKE) $(AM_MAKEFLAGS) top_distdir=../$(distdir) distdir=../$(distdir)/$$subdir distdir) \
|| exit 1; \
fi; \
diff --git a/automake.in b/automake.in
index 059a034..741a086 100755
--- a/automake.in
+++ b/automake.in
@@ -2336,7 +2336,7 @@ sub handle_dist_worker
# Create dist directory.
$output_rules .= (\t-rm -rf \$(distdir)\n
. \tmkdir \$(distdir)\n
- . \t-chmod 777 \$(distdir)\n);
+ . \t-chmod 755 \$(distdir)\n);
}
# Only run automake in `dist' target if --include-deps and
@@ -2468,7 +2468,7 @@ sub handle_dist_worker
. \t . 'test -d $(distdir)/$$subdir ' . \\\n
. \t . '|| mkdir $(distdir)/$$subdir ' . \\\n
. \t . '|| exit 1; ' . \\\n
- . \t . 'chmod 777 $(distdir)/$$subdir; ' . \\\n
+ . \t . 'chmod 755 $(distdir)/$$subdir; ' . \\\n
. \t . '(cd $$subdir'
. ' $(MAKE) $(AM_MAKEFLAGS) top_distdir=../$('
. (($relative_dir eq '.') ? 'distdir' : 'top_distdir')
diff --git a/debian/changelog b/debian/changelog
index b9316b8..7b9d82e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+automake (1:1.4-p6-13.1) unstable; urgency=high
+
+ * Non-maintainer upload by the Security Team.
+ * Fixed CVE-2009-4029: do not assign insecure permissions to directories in
+build tree.
+
+ -- Giuseppe Iuculano iucul...@debian.org Mon, 08 Mar 2010 23:10:11 +0100
+
automake (1:1.4-p6-13) unstable; urgency=low
* debian/rules:
signature.asc
Description: Digital signature
Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote: On 07/10/2012 12:40 AM, Eric Dorland wrote: * Stefano Lattarini (stefano.lattar...@gmail.com) wrote: On 07/10/2012 12:14 AM, Eric Dorland wrote: Are older versions of automake also vulnerable? Yes, all those back to 1.4 (at least). Sorry for not stating that explicitly. Awesome :) Is there a diff or git commit I can look at to start the backporting. See the attachment to: http://lists.gnu.org/archive/html/automake/2012-07/msg00023.html Not sure how well that will work with older Automake releases though; while ploughing through the 1.4 and 1.5 releases, I remember seeing several scary chmod -R a+w ... as well as chmod 777 ... commands. You might want to do a more sweeping audit of those older releases if you want to actually (try to) secure them. I'll probably spend my time instead trying to remove automake 1.4 from Debian at this point since it's super old. I just happen to be at DebConf this week so the timing is pretty good. Well, good work then (and as an happy Debian user I might add: keep up the good work :-) Thanks! -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
Re: GNU Automake 1.11.6 released (fixes a SECURITY VULNERABILITY!)
* Stefano Lattarini (stefano.lattar...@gmail.com) wrote: On 07/10/2012 12:14 AM, Eric Dorland wrote: Are older versions of automake also vulnerable? Yes, all those back to 1.4 (at least). Sorry for not stating that explicitly. Awesome :) Is there a diff or git commit I can look at to start the backporting. I just happen to be at DebConf this week so the timing is pretty good. -- Eric Dorland e...@kuroneko.ca ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
(forw) Bug#402727: config.status generates directories with '$(top_srcdir)' in them
A debian user reported this bug. I'm not certain if this a bug in
automake or autoconf, but I would like your thoughts on it. Thanks.
--
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
---BeginMessage---
Package: automake
Version: 1:1.10+nogfdl-1
Severity: normal
Hello,
Thanks for packaging automake.
In some of my Makefile.am I have entries like this:
tut_test_SOURCES = \
tests/aliases.cc \
tests/error.cc \
tests/fast.cc \
tests/file.cc \
tests/rawmsg.cc \
tests/record.cc \
tests/var.cc \
tests/vartable.cc \
$(top_srcdir)/extra/test-utils-core.cc \
$(top_srcdir)/extra/tut-main.cc
if I just run ./configure, then running config.status creates
directories like these:
dballe/bench/$(top_srcdir)
dballe/bufrex/$(top_srcdir)
dballe/core/$(top_srcdir)
dballe/db/$(top_srcdir)
dballe/msg/$(top_srcdir)
fortran/$(top_srcdir)
tools/$(top_srcdir)
I traced this to this piece of code in the generated config.status:
for file in `sed -n
s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote'$/\1/p' $mf | \
sed -e 's/\$(DEPDIR)/'$DEPDIR'/g' -e 's/\$U/'$U'/g'`; do
# Make sure the directory exists.
[...]
The possible values of files are obtained by grepping include lines from
generated 'Makefile's. Here's a sample of what I have:
include $(top_srcdir)/extra/$(DEPDIR)/test-utils-core.Po
include $(top_srcdir)/extra/$(DEPDIR)/tut-main.Po
include ./$(DEPDIR)/aliases.Plo
include ./$(DEPDIR)/conv.Plo
include ./$(DEPDIR)/csv.Plo
include ./$(DEPDIR)/error.Plo
include ./$(DEPDIR)/file.Plo
Therefore, config.status picks up that '$(top_srcdir)/extra/' prefix and
ensures that it exists, without expanding $(top_srcdir).
I'll now rewrite my Makefile.am files differently, however this looks
like an automake (or autoconf?) bug, so I'm reporting it.
Ciao,
Enrico
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Versions of packages automake depends on:
ii autoconf 2.61-2 automatic configure script builder
ii autotools-dev 20060920.1 Update infrastructure for config.{
automake recommends no packages.
-- no debconf information
---End Message---
signature.asc
Description: Digital signature
Re: [automake] Debian and its alternatives' system.
* Benoit Perrot ([EMAIL PROTECTED]) wrote: Hello, I am facing an issue with the AM_INIT_AUTOMAKE macro -- I don't know if it is more an autoconf or an automake problem. On debian, several version of the same package may be installed, and the default, prefered one is selected by providing a symbolic link pointing to it. Let's imagine I have automake-1.7 and automake-1.9 on my system, and the `automake' symbolicaly links to automake-1.7. The `configure.ac' of my project contains the statement: AM_INIT_AUTOMAKE([1.9]) As `automake' (ie automake-1.7) is searched, autoconf fails. What is sad is that automake-1.9 _is_ present on my system, it is simply not the default one. Of course, I could use the update-alternatives utility of debian to modify it, but for this I need root access to the system. So, I was wondering if there was a way to select the automake path or exe to use, or if patching AM_INIT_AUTOMAKE could be the solution. What do you think? Since now by default the automake symlink will automatically point to the latest version of automake installed on the system. So that situation when the administrator has explicitly set the alternative to something else, and should probably live with the consequences. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Patch to allow optional building of the documentation
Hello,
As I pointed out in [0], the Debian Project has voted GFDL documents
with Invariant Sections not free according to the DFSG. I will shortly
be removing the documentation from the package in main and moving it
to non-free. Just stripping the doc directory from the tarball doesn't
leave it in a very nice state however. So attached is a patch to allow
automake to build cleanly with the doc directory removed. It also
provides a configure switch to disable building of the
documentation. I believe it to be it to generic enough to be
applicable outside Debian. I hope you agree.
[0] http://lists.gnu.org/archive/html/automake/2006-03/msg00063.html
--
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6
Index: configure.ac
===
--- configure.ac(revision 46977)
+++ configure.ac(working copy)
@@ -145,9 +145,31 @@
AC_PROG_EGREP
AC_PROG_FGREP
+AC_ARG_ENABLE([documentation], AS_HELP_STRING([--disable-documentation],
+ [Disble building of the documentation]),
+ [case ${enableval} in
+yes) cond_doc=true ;;
+no) cond_doc=false ;;
+*) AC_MSG_ERROR(bad value ${enableval}
+ for --enable-documentation) ;;
+esac], [cond_doc=unset])
+if test ! -d doc ; then
+ if test $cond_doc = 'true' ; then
+ AC_MSG_ERROR([--enable-documentation specified, but doc dir does not
exist])
+ fi
+else
+ if test $cond_doc = 'unset' ; then
+ cond_doc='yes'
+ fi
+fi
+AM_CONDITIONAL([DOC], [test $cond_doc = 'true'])
+
+if test $cond_doc = 'true' ; then
+ AC_CONFIG_FILES([doc/Makefile])
+fi
+
AC_CONFIG_FILES([
Makefile
- doc/Makefile
lib/Automake/Makefile
lib/Automake/tests/Makefile
lib/Makefile
Index: Makefile.am
===
--- Makefile.am (revision 46977)
+++ Makefile.am (working copy)
@@ -20,9 +20,13 @@
## Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
## 02110-1301, USA.
+if DOC
+ MAYBE_DOC = doc
+endif
+
## We need `.' in SUBDIRS because we want `check' to build `.' before
## tests.
-SUBDIRS = . doc m4 lib tests
+SUBDIRS = . m4 lib tests $(MAYBE_DOC)
bin_SCRIPTS = automake aclocal
signature.asc
Description: Digital signature
Patch to better match file extensions
Ran into the error:
doc/automake.texi:3: output `automake-1.9.info' has unrecognized
extension
This patch fixes it:
--- automake.in (revision 46977)
+++ automake.in (working copy)
@@ -2752,7 +2752,7 @@
next if $outfile;
$outfile = $1;
- if ($outfile =~ /\.(.+)$/ $1 ne 'info')
+ if ($outfile =~ /\.([^.]+)$/ $1 ne 'info')
{
error ($filename:$.,
output `$outfile' has unrecognized extension);
--
Eric Dorland [EMAIL PROTECTED]
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6
signature.asc
Description: Digital signature
Re: Cover Texts in the automake documentation
* Russ Allbery ([EMAIL PROTECTED]) wrote: Alexandre Duret-Lutz [EMAIL PROTECTED] writes: Eric: | Is there any way you might consider dropping the | Front and Back Cover Texts requirements from the manual? Sorry, this is the FSF policy. Not my call. There are other GNU packages with GFDL manuals that do not have Front and Back Cover Texts, so it's clearly not a mandatory policy. Unfortunately, Can you point out specific examples of this? the rest of us aren't really in a position to talk to the right people to get this changed, whereas the official Automake maintainers would be. Could you try? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Cover Texts in the automake documentation
* Alexandre Duret-Lutz ([EMAIL PROTECTED]) wrote: Eric: | Is there any way you might consider dropping the | Front and Back Cover Texts requirements from the manual? Sorry, this is the FSF policy. Not my call. I am unable to find this policy. Looking here: http://www.gnu.org/prep/standards/html_node/License-for-Manuals.html#License-for-Manuals, it states manuals should use GFDL but does not say there need be invariant sections. Looking at the GFDL howto (http://www.gnu.org/copyleft/fdl-howto.html), it states: Is it required for the document to have invariant sections? No. It is perfectly acceptable for a document to have no invariant sections. Could you please point out where the FSF have made this policy? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Cover Texts in the automake documentation
* Ben Pfaff ([EMAIL PROTECTED]) wrote: Eric Dorland [EMAIL PROTECTED] writes: * Alexandre Duret-Lutz ([EMAIL PROTECTED]) wrote: Eric: | Is there any way you might consider dropping the | Front and Back Cover Texts requirements from the manual? Sorry, this is the FSF policy. Not my call. Could you please point out where the FSF have made this policy? http://www.gnu.org/prep/maintain/maintain.html#License-Notices Documentation files should have license notices also. Manuals should use the GNU Free Documentation License. Here is an example of the license notice to use after the copyright notice. Please adjust the list of invariant sections as appropriate for your manual. (If there are none, then say with no invariant sections.) See GNU Sample Texts, for a full example in a Texinfo manual. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being GNU General Public License, with the Front-Cover Texts being ``A GNU Manual,'' and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled GNU Free Documentation License. (a) The FSF's Back-Cover Text is: ``You are free to copy and modify this GNU Manual. Buying copies from GNU Press supports the FSF in developing GNU and promoting software freedom.'' If the FSF does not publish this manual on paper, then omit the last sentence in (a) that talks about copies from GNU Press. If the FSF is not the copyright holder, then replace FSF with the appropriate name. Darn. That is a *should* and not a *must*. But I'm guessing that since the copyright holder is listed as the FSF, getting this changed will basically be impossible. *Sigh*. Ok, time to pull this sucker apart. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Cover Texts in the automake documentation
Hello, Recently, after long deliberations and talks with the FSF, the Debian project voted that GFDL documents containing unmodifiable sections were non-free according to the DFSG (http://www.debian.org/vote/2006/vote_001). Please see http://people.debian.org/~srivasta/Position_Statement.xhtml to understand why Debian objects to parts of the GFDL. Unfortunately, the license for the automake manual contains looks like this: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being ``A GNU Manual,'' and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled ``GNU Free Documentation License.'' (a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development.'' So as it stands now, I will have to move the documentation into the non-free archive. Is there any way you might consider dropping the Front and Back Cover Texts requirements from the manual? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Duplicated macro's argh
* Simon Waters ([EMAIL PROTECTED]) wrote: Simon Waters wrote: My Debian box has stopped playing ball with packaging gnu chess. Attempts to use aclocal now fail with the above error. I note that Deian unstable has two autoconf packages installed autoconf autoconf2.13, however if I force the old 2.13 version (rename configure.a configure.in ad comment out any AC _PREREQ bad things happen so I assume 2.13 is ancient history as far as I'm concerned. Okay - Debian packages exist for specific versions of automake. The package called automake is incompatible with the package called autoconf in unstable (as of a few days back - 2.57). Upgrading to automake1.7 from automake solved my problem, and several other ones at the same time, whilst telling me how to rewrite my makefiles the right way. I suspect this is a dependency bug in the Debian packaging system, which ony people who don't know enough about autotools (like me) will experience, as everyone who knows will have upgraded automake already. There is no more automake package in debian unstable. It has been renamed automake1.4. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK--
Re: Automake 1.7 released
--h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Alexandre Duret-Lutz ([EMAIL PROTECTED]) wrote: Eric =3D=3D Eric Dorland [EMAIL PROTECTED] writes: =20 Eric Is this version backwards compatible with 1.6? Or will it break on Eric some Makefile.am's that worked with automake 1.6?=20 =20 The day we receive such a bug report we can answer this question. Otherwise we will never know... =20 Eric Just wanting to know if i'll need to make an automake1.7 Eric package in debian. =20 Since both versions can be installed alongside I suggest you keep both packages until the dust settle down. =20 (I haven't followed Debian's lists recently. What's up with the plan of changing all packages to depend on an explicit automake version, so that `automake' can become the latest release?) I still need to figure out all the packages that build-depend on automake incorrectly, and file bugs on them. I'm not sure I will ever make the latest release of automake in the package named automake, since if something similar to the 1.4-1.5 transition happens again, people will be pissed off. But I hope to have all the automake packages Provides: automake so that people can depend on automake if they need just some version of it. =20 --=20 Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+=20 O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+=20 G e h! r- y+=20 --END GEEK CODE BLOCK-- --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9k4LpYemOzxbZcMYRAhJvAJ9dbI9UfC79hrc0cHIf5t5MefgqAQCeJe5p FZFCPfPOLfiP44ZA0urC7rM= =9zMI -END PGP SIGNATURE- --h31gzZEtNLTqOjlF--
Re: Automake 1.7 released
--ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Great Alexandre :) Is this version backwards compatible with 1.6? Or will it break on some Makefile.am's that worked with automake 1.6? Just wanting to know if i'll need to make an automake1.7 package in debian. * Alexandre Duret-Lutz ([EMAIL PROTECTED]) wrote: We're pleased to announce the release of Automake 1.7. This release contains many bug fixes and improvements. The NEWS entry is appended. =20 You can find the new release here: =20 ftp://sources.redhat.com/pub/automake/automake-1.7.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.7.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.7.tar.bz2 =20 (Note that the files might not be already available at ftp.gnu.org by the time you read this.) =20 Soon it will also appear on the sources and GNU mirrors. Follow these links for a list of them: =20 http://sources.redhat.com/mirrors.html http://www.gnu.org/order/ftp.html =20 Please report bugs by mail to [EMAIL PROTECTED], or (preferred) at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=3Dautomake =20 - Akim, Alexandre, and Tom =20 New in 1.7: * Autoconf 2.54 is required. * `aclocal' and `automake' will no longer warn about obsolete configure macros. This is done by `autoconf -Wobsolete'. * AM_CONFIG_HEADER, AM_SYS_POSIX_TERMIOS and AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL are obsolete (although still supported). You should use AC_CONFIG_HEADERS, AC_SYS_POSIX_TERMIOS, and AC_HEADER_TIOCGWINSZ instead. `autoupdate' can upgrade `configure.ac' for you. * Support for per-program and per-library `_CPPFLAGS'. * New `ctags' target (builds CTAGS files). * Support for -Wmumble and -Wno-mumble, where mumble is a warning category (see `automake --help' or the manual for a list of them). * Honor the WARNINGS environment variable. * Omit the call to depcomp when using gcc3: call the compiler directly. * A new option, std-options, tests that programs support --help and --ver= sion when `make installcheck' is run. This is enabled by --gnits. * Texinfo rules now support the `ps' and `pdf' targets. * Info files are now created in the build directory, not the source direc= tory. * info_TEXINFOS supports files in subdirectories (this requires Texinfo 4= .1 or greater). * `make distcheck' will enforce DESTDIR support by attempting a DESTDIR install. * `+=3D' can be used in conditionals, even if the augmented variable was defined for another condition. * Makefile fragments (inserted with `include') are always distributed. * Use Autoconf's --trace interface to inspect configure.ac and get a more accurate view of it. * Add support for extending aclocal's default macro search path using a `dirlist' file within the aclocal directory. * automake --output-dir is deprecated. * The part of the distcheck target that checks whether uninstall actually removes all installed files has been moved in a separate target, distuninstallcheck, so it can be overridden easily. * Many bug fixes. =20 =20 =20 --=20 Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+=20 O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+=20 G e h! r- y+=20 --END GEEK CODE BLOCK-- --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9kijoYemOzxbZcMYRAn9NAJ9Qi2dAOqf4QDefPKZD4hkWDVkJ7wCgtyJa oWWGvf3v7VKk0WEvpY7fDTY= =p5Xw -END PGP SIGNATURE- --ReaqsoxgOBHFXBhH--
Re: Automake 1.6 info files
* Alexandre Duret-Lutz ([EMAIL PROTECTED]) wrote: Eric == Eric Dorland [EMAIL PROTECTED] writes: [...] Eric I've packaged automake-1.6, and the versioned binaries and Eric directories were a big help. But I'm a bit confused why the info files Eric are not versioned as well. Was this intentional, or were they Eric forgotten about? I believe it was not intentional, but simply that nobody really cares. The `*-1.6' binaries are here to help the people doing the transition to Automake 1.7 when it come out; not to help people stick to Automake 1.6 ad vitam aeternam. So it doesn't make much sense documenting them. Well is automake 1.7 special in some way? Or well it have versioned binaries as well? [...] Eric Because right now I either have to split them out into Eric their own tiny package, or hack them myself to make them Eric versioned. Any ideas? What about renaming the info files from the old versions? If it were that simple I wouldn't even complain :) But its a bit more involved then that. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- msg05493/pgp0.pgp Description: PGP signature
Automake 1.6 info files
Hello everyone, I'm taking over the automake packages for debian after a long period of neglect. I've packaged automake-1.6, and the versioned binaries and directories were a big help. But I'm a bit confused why the info files are not versioned as well. Was this intentional, or were they forgotten about? Because right now I either have to split them out into their own tiny package, or hack them myself to make them versioned. Any ideas? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- msg05463/pgp0.pgp Description: PGP signature
