Messages in this thread | | | Date | Tue, 15 Apr 2014 15:30:15 -0400 (EDT) | From | Vince Weaver <> | Subject | Re: [bisected] broken make-kpkg kernel build in 3.15-rc1 |
| |
On Tue, 15 Apr 2014, Vince Weaver wrote:
> On Tue, 15 Apr 2014, Russell King - ARM Linux wrote: > > > Right, so the thing to do is to run a build with the commit applied, > > without any -j arguments and V=1, logging the output (so that predictable > > output can be generated). > > > > Then run the same thing with the commit reverted, again logging it. Then > > diff the two and see what's different. > > OK, I captured the output. No diffs, as of course reverting things > means one kernel was called 3.15-rc1 and one 3.15-rc1+ which meant more or > less every line changed. > > It seems that on stock 3.15-rc1 (which fails to build) after running > depmod it kicks into > > restore_upstream_debianization > > which goes down a path which causes the file permission failures > > Wheras 3.15-rc1 with the problem commit reverted this doesn't happen. > > This is a really weird bug, I've tried reverting individual hunks of the > problem commit manually and it is not clear at all to me what is > triggering this.
OK, in debian/image.mk we have this:
ifeq ($(strip $(HAVE_INST_PATH)),) test ! -f System.map || cp System.map \ $(TMPTOP)/$(IMAGEDIR)/System.map-$(KERNELRELEASE); test ! -f System.map || chmod 644 \ $(TMPTOP)/$(IMAGEDIR)/System.map-$(KERNELRELEASE); cp $(kimagesrc) $(kimagedest) else $(restore_upstream_debianization) $(MAKE) $(EXTRAV_ARG) INSTALL_MOD_PATH=$(INSTALL_MOD_PATH) \ INSTALL_FW_PATH=$(INSTALL_MOD_PATH)/lib/firmware/$(KERNELRELEASE) \ INSTALL_PATH=$(INT_IMAGE_DESTDIR) $(CROSS_ARG) $(KPKG_KBUILD_INSTALL_TARGET) endif
So in the good case it goes down the if, in the bad case down the else.
I'm assuming that the ($(strip $(HAVE_INST_PATH)),) is being confused by the INSTALL_DTBS_PATH introduced by the changeset.
So I guess that makes this a debian bug?
Vince
| |