> The log shows the clean target failing because after calling 'make
> distclean', ./debian went away. This usually happens when
> ./scripts/package/Makefile is not neutered, since that Makefile
> unconditionally removes ./debian.
Hello,
My system has kernel-package_10.067. I've checked 11.001, it seems
the same with regard to what I am about to say.
In debian/ruleset/targets/target.mk we see this snippet:
real_stamp_clean:
$(REASON)
@echo running clean
test ! -f scripts/package/builddeb.kpkg-dist || \
mv -f scripts/package/builddeb.kpkg-dist scripts/package/builddeb
test ! -f scripts/package/Makefile.kpkg-dist || \
mv -f scripts/package/Makefile.kpkg-dist scripts/package/Makefile
ifeq ($(DEB_HOST_GNU_SYSTEM), linux-gnu)
test ! -f .config || cp -pf .config config.precious
test ! -f Makefile || \
$(MAKE) $(FLAV_ARG) $(EXTRAV_ARG) $(CROSS_ARG) ARCH=$(KERNEL_ARCH)
distclean
test ! -f config.precious || mv -f config.precious .config
else
...
Here we see that scripts/package/Makefile gets un-neutered (see earlier
message from Manoj) just prior to invoking the distclean. As Manoj
mentioned previously, this causes the problem because the real
Makefile targets the debian directory for elimination, like so:
clean-dirs += $(objtree)/debian/
I think the reason why this bug has been tagged unreproducible is
because the problem only exhibits itself if patch_the_kernel is set
to YES, which is how I have it configured in my /etc/kernel-pkg.conf.
I believe that because of this snippet that closely follows the above:
ifeq ($(strip $(patch_the_kernel)),YES)
$(run_command) unpatch_now
endif
And we see this in debian/rules:
run_command=$(MAKE) -f $(DEBDIR)/rules
You do not need actual patches to trigger the problem...
So Manoj, can you please try to reproduce the bug with this in your
/etc/kernel-pkg.conf file:
patch_the_kernel := YES
Thanks!
- Tor
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
