Release tarball includes useless ".DS_Store" files

[Chris Lamb]

The 1.1 RC1 tarball contains a few MacOS resource fork files:

$ wget -q http://media.djangoproject.com/releases/1.1/Django-1.1-rc-1.tar.gz
$ tar xfz Django-1.1-rc-1.tar.gz
$ find -name "*.DS_Store"
./Django-1.1-rc-1/django/contrib/admin/media/js/._.DS_Store
./Django-1.1-rc-1/django/contrib/admin/media/js/.DS_Store
$

Such files are generally useless and I (with Debian maintainer hat on) have to strip them out.

[anonymous]

They're not resource fork files. They hold view information for the Finder (and happen to have a resource fork, the ._DS_Store file). Still useless in this context, of course. ;)

[anonymous]

make dist should whack those.

[Jacob]

There's no reason to re-roll the rc tarball, but we'll be sure to get this worked out when we push the final.

[Chris Lamb]

Back in the 1.2~alpha release tarball:

./docs/._.DS_Store
./docs/.DS_Store
./django/contrib/admin/media/js/._.DS_Store
./django/contrib/admin/media/js/.DS_Store

Whilst I understand that final releases may not have these files, it would seem to make sense to either not have a seperate release process for "final" vs. "non-final" tarballs.

[Russell Keith-Magee]

The issue here is making sure ubernostrum's packaging script clears out these files (or that he packages a clean checkout). Marking for milestone 1.2 so that it isn't forgotten, but it's a procedural issue, not a code fix that is required.

[James Bennett]

This is fixed with the 1.2 beta package. The problem was with one tool ignoring the files while others didn't, and so I've just added another step to the process to guarantee that the tree which generates the release package is clean.

[Jacob]

Milestone 1.2 deleted