First of all, can we come up with a hook in util-macros which will verify that the version of automake is correct and bail during configure if it's not? This would prevent future problems (assuming the packager has the latest util-macros... which they should).

As far as what to do about released packages:

1) Re-releasing *every* tarball is certainly out of the question.

2) Re-releasing with the same version number is out of the question as that is one of the big packager nightmares (don't change checksums on us).

3) Bumping (maybe as a sub-tiny version bump... eg: 1.0 -> 1.0.0.1) the latest version is an option I'd consider, but I personally believe we have too many repos and too few people to do this effectively. Unless Alan came up with some friendly script for mass releases during the last katamari, I'd vote for skipping this option.

4) Making an announcement seems to be the best bet. Packagers can autoreconf, and the quantity of users building from sources and not using something like pkgsrc, portage, etc is probably limited in scope and not worth the effort of a mass re-release.

On Dec 8, 2009, at 15:48, Alan Coopersmith wrote:

The GNU automake maintainers today issued patches and a security advisory for a problem when running 'make dist*' on projects which had Makefile.in
generated by versions of automake prior to the patch:
 http://lists.gnu.org/archive/html/autotools-announce/2009-12/msg00002.html

This pretty much covers every X.Org modular release tarball ever made.
Clearly X.Org will not be rebuilding all our past tarballs with new
automake releases, as we simply don't have the people-power.

It's unclear to me if we need to rebuild any releases at all, or just
tell end users that if they're running 'make dist*' on a previously
released tarball, on a system in which untrusted users could login or
access the filesystem, they should run "autoreconf" first with a patched
local automake install.   Any opinions?

X.Org developers/maintainers should move to patched versions of automake
when possible for generating release tarballs going forward.

--
        -Alan Coopersmith-           [email protected]
         Sun Microsystems, Inc. - X Window System Engineering

_______________________________________________
xorg-devel mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-devel

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
xorg-devel mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to