Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754738AbaDOTdv (ORCPT ); Tue, 15 Apr 2014 15:33:51 -0400 Received: from mail-vc0-f180.google.com ([209.85.220.180]:35476 "EHLO mail-vc0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753551AbaDOTdt (ORCPT ); Tue, 15 Apr 2014 15:33:49 -0400 Date: Tue, 15 Apr 2014 15:37:03 -0400 (EDT) From: Vince Weaver To: Vince Weaver cc: Russell King - ARM Linux , Christoph Lameter , Michal Marek , linux-kernel@vger.kernel.org, Jason Cooper , Grant Likely , Rob Herring , srivasta@debian.org Subject: Re: [bisected] broken make-kpkg kernel build in 3.15-rc1 In-Reply-To: Message-ID: References: <534D4A59.6080401@suse.cz> <534D6510.3070509@suse.cz> <20140415182653.GR24070@n2100.arm.linux.org.uk> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 15 Apr 2014, Vince Weaver wrote: > 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? And it looks like this was reported to the list earlier and I somehow missed it :( https://lkml.org/lkml/2014/4/3/333 Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/