Re: trouble using a local kernel repo

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 12-02-16 06:52 PM, Hollis Blanchard wrote:
> On 02/16/2012 03:25 PM, Bruce Ashfield wrote:
>> The point is that the tree is local to your machine, but it doesn't
>> have to be. You may only have push, not direct commit access. It's
>> really not asking for anything that isn't already common practice.
>
> Hmm, I'm not at all a git expert, but I thought common practice was to
> clone the upstream git tree, then create local branches that track the
> upstream ones. I've never seen any directions say "first create a bare
> clone, then clone that again, then create local branches."

It's a build system thing, what can I say ? When you are working with
the raw tree, and your own cross compiler, that's absolutely the
workflow. It's the same as having to write recipes versus Makefiles
and python versus shell. I had to switch to recipes and bitbake constructs
when that didn't match anything I had previously had or used as
best practices.

>
>>> I'm just trying to test a small kernel/meta patch, and the poorly
>>> documented list of setup requirements is growing longer and longer. All
>>> this stuff may be good practice for a more complicated scenario, but so
>>> far it seems like enormous overkill for my use case...
>>
>> So why are you trying to use the technique ? Maybe the answer is that the
>> docs made it sound like this was the best/right way .. and that's a
>> problem in itself.
>
> The docs don't cover "how do I add a kernel patch?" at all, AFAICS.
>
> ... oh wow, now I see
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html.
> This actually does talk about bare clones.
> http://www.yoctoproject.org/docs/current/kernel-manual/kernel-manual.html,
> which is what I had been reading, does not.

Argh. We are working a brand new organization for this, with the important
information clearly and concisely stated as the first thing you see.
I feel your pain on this.

>
>> If you do have a single patch, toss it on the end of the SRC_URI and
>> everything just works like any other package
>
> The reason I'm even bothering is to try to be a good person. I could
> have stuck this in a private collection 2 days ago... but I figured this
> is going to bite plenty of other people, so I should try to submit a
> patch that would fix it for everybody. I could tell the kernel
> configuration system is complicated, but I really didn't expect this
> many barriers.

Absolutely. I'm glad to hear this. The first contact information let
us down a bit. There IS complexity in the system, but for the easy
straight forward, first patch sort of use case, it is supposed to be
completely hidden and just work like any other package.

I hate hearing about anyone have trouble, or things not working, and
I've been knocking off things that break for over a year now. For example,
someone else hit the bare clone (first time in over two years!), and I
wrote a patch to fix that case .. but I failed to get it out in time
to save you the same trouble :(

Cheers,

Bruce

>
> Hollis Blanchard
> Mentor Graphics, Embedded Systems Division
>