Re: [PATCH 1/1] busybox: add config fragments

Richard Purdie
2013-02-12T13:38:12Z

On Tue, 2013-02-05 at 11:29 -0500, Bruce Ashfield wrote:
> On Tue, Feb 5, 2013 at 1:42 AM, ChenQi <Qi.Chen@windriver.com> wrote:
> On 02/02/2013 03:08 AM, Bruce Ashfield wrote:
> > On Fri, Feb 1, 2013 at 1:56 PM, Saul Wold
> > <sgw@linux.intel.com> wrote:
> > On 02/01/2013 06:18 AM, Bruce Ashfield wrote:
> > On Fri, Feb 1, 2013 at 4:00 AM,
> > <Qi.Chen@windriver.com
> > <mailto:Qi.Chen@windriver.com>> wrote:
> > <mailto:Qi.Chen@windriver.com>>
> > Both the implementation and the use case
> > are similar to yocto kernel's
> > configuration fragments.
> > I can fairly easily tweak the configuration
> > parts of the kern-tools to
> > handle this
> > use case as well. That would allow us to
> > re-use the kernel's merge_config.sh
> > script (with a minor dependency change) and
> > save some duplicated code. It
> > also gets you the advantage that you can
> > consolidate configuration fragments
> > outside of any build system, which isn't as
> > critical here, but something
> > that
> > is used quite a bit during kernel testing.
> > Bruce,
> >
> > Where is the merge_config.sh script today? Would
> > you propose moving it to the scripts dir and have
> > the busybox recipe call it?
> >
> >
> > It's part of the mainline kernel, hence why grabbing the
> > guts out of it reproducing
> > it here isn't the best idea, we'll have a need to keep them
> > in sync. In fact, I have
> > 2 or 3 pending patches for it in the kern-tools repository
> > that I need to get upstream
> > (as an example).
> >
> >
> > I'd propose either creating a separate recipe for it (i.e.
> > like kconfig-frontends) or I could
> > keep it in kern-tools (badly named, but we can work on
> > that ;) and maintain / coordinate
> > changes to it.
> >
> >
> > I just don't want to see the effort happen twice, we are
> > busy enough!
> >
> >
> > What would be your timing on making such a change,
> > ie hold this patch until your get it merge or merge
> > this and then fix it when you merge your changes?
>
> > I could feasibly get it done in the next few weeks, the
> > changes aren't bug, I just
> > have to avoid regressions on either side (kernel or busy
> > box).
>
> > That being said, the interface to the SRC_URI is the same
> > for the two, so if we are
> > ok with me arriving and removing the in-recipe support, I
> > guess I can't object too
> > much :) The only risk is that if anyone starts using this
> > first support immediately,
> > I do risk regressing their use case, where if it never goes
> > in, that won't happen.
>
> > Cheers,
> > Bruce
>
> Hi Bruce,
>
> I just tried to reuse the kernel's merge_config.sh script, and
> it turned out well.
> The patch is in attachment.
>
> Is it enough for now?
>
> Yep, this is enough for now. It re-uses the significant part of the
> infrastructure, which
> is the important part. Once it is in tree, I can refine the dependency
> and some other
> minor modifications.
>
> Feel free to add my Signed-off-by: to the patch as well.

This patch triggers a failure on the autobuilder:

http://autobuilder.yoctoproject.org:8010/builders/p1022ds/builds/246/steps/shell_59/logs/stdio

(its reproducible, this is the second one now)

I suspect there is a missing DEPENDS += "kern-tools-native".

You'd be able to reproduce this with a:

bitbake busybox kern-tools-native; bitbake busybox kern-tools-native -c clean; bitbake busybox

Cheers,

Richard