Your message dated Mon, 31 Mar 2008 15:27:46 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#434781: buildcore.mk doesn't clean all those
*.cdbs-config_list
has caused the Debian Bug report #434781,
regarding buildcore.mk doesn't clean all those *.cdbs-config_list
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
434781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434781
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: cdbs
Version: 0.4.49
Severity: normal
When setting DEB_TARBALL, one ends up with some *.cdbs-config_list that
aren't removed at any point. Seems like something should be added to
one of the clean targets to take care of that. (Which means that
calling make clean on an already-clean package would create these files
only to delete them immediately afterwards. Oh well.)
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-1-k7 (SMP w/1 CPU core)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
cdbs depends on no packages.
Versions of packages cdbs recommends:
ii autotools-dev 20070306.1 Update infrastructure for config.{
ii debhelper 5.0.53 helper programs for debian/rules
-- no debconf information
--- End Message ---
--- Begin Message ---
I'm not the author of the tarball.mk feature, so I admit that I was initially
confused by these files as well. It turns out they are necessary and are not
supposed to be deleted. They store a list of candidates for
config.guess/config.sub replacement. The alternative is that the complete
tarball must be unpacked and parsed (tar tzf etc.) at each call, which would
be very slow. So the feature works as designed. Perhaps there is a better
way to do it, but someone would need to design something very clever.
--- End Message ---
