[linux-yocto] v3.8 kernel recipes in meta-intel

[Bruce Ashfield]

On 13-03-05 12:56 PM, Kamble, Nitin A wrote:
>
>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield at windriver.com]
>> Sent: Tuesday, March 05, 2013 9:50 AM
>> To: Kamble, Nitin A
>> Cc: linux-yocto at yoctoproject.org
>> Subject: Re: v3.8 kernel recipes in meta-intel
>>
>> On 13-03-05 12:35 PM, Kamble, Nitin A wrote:
>>>>>
>>>>> So the topic branch commit is present much deeper in the branch with
>>>> different commit-id.
>>>>> May be merging of the emgd branch resulted it. Is it issue with the
>>>>> emgd branch rebased to an undesired point?
>>>>
>>>> It shouldn't be. That commit shouldn't be present in the repository
>>>> at all (it isn't in mine). The emgd branches are off master, same
>>>> repo and can't bring in something like this.
>>>
>>> Right. I think it got placed there after merge with the emgd branch
>>> done by the kernel-tools.
>>
>> That doesn't make sense either. The merge of the emgd branch is just the git
>> merge of a locally staged branch in the linux-yocto repository.
>> That commit you reference shouldn't be in the emgd branch, or any branch if
>> a clean linux-yocto-3.8 tree is being used.
>
> Right, so the kernl tools are producing unwanted state of the topic branch when
> emgd branch is considered. And I guess you would know better why kernl tools are doing it.

Not exactly, I must not be understanding what you are describing.
There's no way for the kern-tools to create a commit ID. They can only
work with what's present in the tree.

If you see the SRCREV to "foo", and validate_branches is telling you
that "foo" isn't present in the tree at all, that's not related to
the kern tools at all. It's related to the repository that is cloned
into the WORKDIR for building.

If you can make your recipes and updates public, I can try and do a build
here.

Bruce

>
> Nitin
>
>
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>>>
>>>> So something is getting tied in a knot when the repository is fetched
>>>> into the source dir.
>>>
>>> I don't see any issue with the fetch. As noemgd BSPs are working as
>> expected.
>>>
>>>>
>>>> For your builds that work, do you have that commit present ?
>>>>
>>>
>>> The emenlow-noemgd build sees the right HEAD commit. So the issue is
>>> definitely something to do with the merge with the emgd branch.
>>>
>>> Nitin
>>>
>>>
>