All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Marc Ferland <ferlandm@sonatest.com>
Cc: yocto@yoctoproject.org
Subject: Re: linux-yocto and private topic branches
Date: Fri, 17 Aug 2012 16:35:32 -0400	[thread overview]
Message-ID: <502EAB14.2070109@windriver.com> (raw)
In-Reply-To: <871uj51d87.fsf@sonatest.com>

On 12-08-17 04:21 PM, Marc Ferland wrote:
> Hi,
>
> I'm maintaining a BSP based on crownbay and I would like to change my
> current kernel recipe from a custom one to linux-yocto_3.2.bb.

I'm just heading out for the weekend, but I can pick this up in more
detail layer.

>
> Reading the kernel-yocto.bbclass, I see that it is possible to provide a
> list of patches and configuration fragments but also (not sure about
> that) to provide an "external branch".

In the denzil (3.2 kernel) that is the case, in the yocto 1.3 (3.4)
kernel, it isn't even called an external branch, since the tools
are more tolerant of a branch not being present at validation time.

>
> Since we maintain several private topic branches in-house this would be
> the perfect solution. I could "inherit" from crownbay (available on
> linux-yocto) and just merge my topic branches to produce the final
> kernel source tree.
>
> My question:
> Is this currently possible? If so, are there any examples available?

You can do this, but you do need to host your own kernel repository
that is based off linux-yocto. In that repository, you can have
your own branches, that are easily referenced from the recipes.

Is this what you are currently doing with your custom recipe ?

I'm stating the obvious, since if you want to clone a tree with your
branch .. there must be a tree somewhere with that branch :)

The yocto-bsp tools are using the external branches to manage new
BSPs that aren't already in linux-yocto.

There are other tricks that can be played where smaller, pruned git
trees are used, and they are cloned and have their alternates pointed
at the main kernel tree repository, gluing the two together. But there's
nothing within the current models that supports it directly (you need
reference clones, scripts, etc).

> Can these changes be kept in "recipe-space"?

Most everything that can be done in a tree, with branches and meta data
can also happen in recipe space. The yocto-bsp scripts are again a
good example of this.

>
> If not possible, am I stuck with managing patches?

If you don't have a kernel tree somewhere that you are fetching ..
perhaps.

Cheers,

Bruce

>
> Regards,
>
> Marc
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



  reply	other threads:[~2012-08-17 20:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-17 20:21 linux-yocto and private topic branches Marc Ferland
2012-08-17 20:35 ` Bruce Ashfield [this message]
2012-08-17 21:33   ` Marc Ferland
2012-08-20  4:30     ` Bruce Ashfield

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=502EAB14.2070109@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=ferlandm@sonatest.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.