From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.windriver.com (mail1.windriver.com [147.11.146.13]) by mail.openembedded.org (Postfix) with ESMTP id 330F77318D for ; Fri, 2 Sep 2016 04:38:01 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.15.2/8.15.1) with ESMTPS id u824bngI004149 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Sep 2016 21:37:50 -0700 (PDT) Received: from server.local (147.11.117.43) by ALA-HCA.corp.ad.wrs.com (147.11.189.40) with Microsoft SMTP Server id 14.3.248.2; Thu, 1 Sep 2016 21:37:49 -0700 To: =?UTF-8?Q?Andr=c3=a9_Draszik?= References: <1472547914.8449.25.camel@andred.net> <94a7387f-cc88-2e7f-21b6-57970dfdbb04@windriver.com> <1472566766.8449.29.camel@andred.net> <78886c10-2951-9a57-31dd-0e1e78d19815@windriver.com> <1472633650.12967.15.camel@andred.net> <81c8d462-9f65-cd7c-7dfe-f3acd2e21e18@windriver.com> <1472746455.27417.57.camel@andred.net> <27e6e15a-a78d-dafc-ecab-4a5c58fba529@windriver.com> From: Bruce Ashfield Message-ID: Date: Fri, 2 Sep 2016 00:37:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <27e6e15a-a78d-dafc-ecab-4a5c58fba529@windriver.com> Cc: openembedded-core@lists.openembedded.org Subject: Re: [PATCH 5/6] kernel-yocto: streamline patch, configuration and audit phases X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 04:38:03 -0000 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit On 2016-09-01 11:18 PM, Bruce Ashfield wrote: > On 2016-09-01 12:14 PM, André Draszik wrote: >> On Mi, 2016-08-31 at 16:17 -0400, Bruce Ashfield wrote: >>> On 2016-08-31 4:54 AM, André Draszik wrote: >>>> >>>> On Di, 2016-08-30 at 14:35 -0400, Bruce Ashfield wrote: >>>>> >>>>> Can you clarify for me if you are are using SRC_URI items tagged with >>>>> 'kmeta', i.e. a directory of fragments, or are you just adding >>>>> .cfg/.scc >>>>> items directly to the SRC_URI ? >>>> >>>> I do both: >>>> >>>> in the 1st layer, my kernel recipe boils down to: >>>> >>>> SRC_URI = "\ >>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux- >>>> stable.git;protocol=git;nocheckout=1;branch=${KBRANCH} \ >>>> file://0001-a-patch.patch \ >>>> file://kernel-meta;type=kmeta;destsuffix=${KMETA} \ >>>> " >>>> >>>> KERNEL_FEATURES_append = " patches/some-patches.scc" >>>> KERNEL_FEATURES_append = " patches/more-patches.scc" >>>> KERNEL_FEATURES_append = " patches/even-more-patches.scc" >>>> >>>> some of the above in turn include additional .scc items recursively. >>>> >>>> >>>> In the 2nd layer, my .bbappend boils down to: >>>> >>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}-4.4:" >>>> >>>> KERNEL_FEATURES_append_tgm = " patches/tgm.scc" >>>> >>>> 2nd-layer.scc is located in ${THISDIR}/kernel-meta/patches/ in the 2nd >>>> layer. I don't specifically add another SRC_URI item tagged with >>>> 'kmeta' >>>> (or >>>> any other explicit SRC_URI item for that matter). >>> >>> One more clarification. From our problem description, are you saying >>> that in your runs, only the meta data from layer2 is getting copied >>> and not that from layer1 ? >> >> That is what I had inferred from the error message: >> >> | DEBUG: Executing shell function do_kernel_metadata >> | ERROR. input file "patches/some-patches.scc" does not exist >> | ERROR: could not process input files: >> <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig >> <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch >> patches/some-patches.scc patches/more-patches.scc >> patches/even-more-patches.scc patches/tgm.scc >> | See /tmp/tmp.mPP1jtatxm for details >> | ERROR. input file "patches/some-patches.scc" does not exist >> | ERROR: could not process input files: >> <2nd_layer>/recipes-kernel/linux/linux-ramips-4.4/tgm/defconfig >> <1st_layer>/recipes-kernel/linux/linux-ramips-4.4/0001-a-patch.patch >> patches/some-patches.scc patches/more-patches.scc >> patches/even-more-patches.scc patches/tgm.scc >> | See /tmp/tmp.v9LU9ccpbl for details >> | WARNING: exit code 1 from a shell command. >> >> >>> I ran my sanity test, and saw meta data from both my layers copied .. >>> so I'm worried that I misunderstood the issue you are seeing. >> >> I can see that they are actually copied indeed, but it doesn't find >> them... >> The file /tmp/tmp.v9LU9ccpbl mentioned above is empty. >> >>> But looking at the code, I can definitely do some minor tweaks in this >>> area .. I'm just trying to get the reproducer nailed down. >> >> I can try to create one for you if you prefer tomorrow, rather than >> wasting >> your time with this, if you don't get any further? > > I was able to trigger a similar trap to the above. And yes, it was sort > of working by luck before. I spoke too soon. The error that I was able to trigger was valid, and in fact, when I tried the same test on krogoth it also failed there as well. So there is something I still don't have right in the two layers to trigger the same scenario you are seeing. If you could do that mock up, it would help immensely. Also, if you are open to changing the layer structure a bit, I could always suggest a new way to organize things. Cheers, Bruce > > I need to stare at this for a few hours and figure out the right way to > restore similar behaviour. But now .. sleep. > > Cheers, > > Bruce > >> >> >> Andre' >> >