> 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]