[Debian GNUstep maintainers] Bug#646840: fails to build from source twice in a row

[Peter Eisentraut]

On tor, 2011-11-03 at 21:05 +0200, Yavor Doganov wrote:
> At Thu, 27 Oct 2011 20:25:42 +0300,
> Peter Eisentraut wrote:
> > Package: gnustep-base
> > Version: 1.22.1-1
> > Severity: important
> 
> > dpkg-source: error: cannot represent change to gnustep-base-1.22.1/Tests/base/NSException/core.basic.825: binary file contents changed
> > dpkg-source: error: cannot represent change to gnustep-base-1.22.1/Tests/base/NSTask/core.NSZombie.6814: binary file contents changed
> 
> > Are these core files expected test output, or should I analyze
> > further why I get them?
> 
> Yes, some test programs are expected to dump core, but the files
> should be named `core', which the `clean' rule will subsequently
> delete.  As I can't reproduce, I'd appreciate if you investigate why
> they end up (apparently) `core.$program.$pid'.  Thanks.

I have my kernel configured to do that.  (See core(5) man page if you
are interested.)  Now I'm wondering how a package is supposed to handle
that.  Note that many non-Linux kernels are configured by default to
name their core files something other than just "core" (see for example
http://en.wikipedia.org/wiki/Core_file#References), so gnustep upstream
should not assume that just deleting "core" is sufficient.

Here is what an Autoconf-generated configure script does:

rm -f core *.core core.conftest.*

I assume they have tested this a bit, and it also matches the references
I found via Wikipedia.