Tarball of 1.3.3 has object files and .svn directories; impossible to build without clean on MacPro

[xander]

What steps will reproduce the problem?

1. Download the tarball for postgis 1.3.3 at

​http://postgis.refractions.net/download/ .

2. Unpack the tarball.
3. Notice that there are .svn directories. cd to lwgeom. Notice that

there are .o files.

4. Attempt to build on a new Xeon MacPro; the linker will complain that .o

files are not built for the correct architecture.

What is the expected output? What do you see instead?

I see compiled .o files in the source tarball and .svn directories. I expect these not to exist. Note that they do not exist in the 1.2.* tarballs.

What version of the product are you using? On what operating system?

Postgis 1.3.3 on new MacPro.

Please provide any additional information below.

Note that I think that the tarball changed suddenly and without incrementing the version number, which led to macports bug #16691: ​https://trac.macports.org/ticket/16691 . I am moderately worried that this could be an attack on PostGIS's site and that the new tarball, since it doesn't match the sha of the old tarball, could in fact have malicious content.

Note also that there is a workaround for this issue. make clean all instead of make will suffice.

[xander]

FYI, the exact error from the OS X linker is: file is not of required architecture

[kneufeld]

Fixed. (For this tagged release as well as the branch and trunk tarballs).

A ./configure and make is required to build the documentation that's included in the tarball. This script was recently integrated into a new autobuild process, which is now cleaning up via a make clean before packaging up the tarball.

Note: The PostGIS has not been under attack and the postgis-1.3.3.tar.gz does not have malicious content. This file was updated to include a generated PDF of the documentation when the autobuild process went online a month ago.

Perhaps we should include MD5 checksums on the download website?

[xander]

Awesome. Thanks for fixing.

As to whether to include MD5s, it's probably a good idea, though obviously your call.

I was using MacPorts, which puts a SHA or MD5 in every port file to check against the source tarball. Since the tarball changed with the new autobuild process, MacPorts threw an error when it tried to pull down the new tarball.