Re: [Audacity-devel] Unnecessary files in tarball WAS Re: Releasing 2.0.2!

[David T. <dt...@ii...>]

On 06/09/12 20:35, Richard Ash wrote:
> I did the 2.0.0 tarballs and always used a separate SVN working copy
> which I didn't build from to do so. David relied upon cleaning his
> working copy, and didn't succeed. I could modify the script to check the
> status of every file in the tree against SVN, and eliminate any files
> not under version control, but this would slow things down quite a lot,
> and I'm not sure it's worth the bother.

Me too, into audacity-read-only. Seems it occurred for:
audacity-fullsrc-2.0.1.tar.bz2
audacity-fullsrc-2.0.2.tar.bz2
audacity-minsrc-2.0.1.tar.bz2
audacity-minsrc-2.0.2.tar.bz2


; if I:
$ locate conftest.c
/home/davidt/dev/packaging/rpmfusion/audacity-freeworld/audacity/conftest.c
/home/davidt/dev/packaging/rpmfusion/audacity-freeworld/audacity-src-2.0.2/conftest.c

$ locate confdefs.h
/home/davidt/dev/packaging/rpmfusion/audacity-freeworld/audacity/confdefs.h
/home/davidt/dev/packaging/rpmfusion/audacity-freeworld/audacity-src-2.0.2/confdefs.h

The svn readonly checkout is at:
/home/davidt/dev/packaging/rpmfusion/audacity-freeworld/audacity-read-only

On the surface, it looks like audacity-read-only is clean (it's still as
left by the svn update/status process).
It's the copy (2.0.2) that is made by running the script that has the
confdefs.h and conftest.c files.

Seems the make tarballs script might be the culprit ?

Do you want me to do the process from scratch to see if it reoccurs (i'm
pretty low on monthly internet usage and I'll be capped till mid-month)?

David.