> Hi Viktor,
>
> On Thursday 27 August 2015 08:25:38 Lenivyy Viktor wrote:
> > > In your kernel recipe are you using SRC_URI to fetch from a git
> > > repository (e.g. git:// URI) or from a local directory?
> >
> > This kernel is fetched from local directory.
> >
> > > I guess that if you're using a local path, there can be either
> > > some uncommitted changes, or a stale git index.
> >
> > No, because kernel built from sources in local directory doesn’t
> > have “-dirty” in version string.
> > > You can try just for the experiment to add your current kernel
> > > sources to a test git repo and point the SRC_URI to it, so bitbake
> > > can clone the repo by git revision (SRCREV = "${AUTOREV}" will
> > > skip the need to update the recipe revision constantly during
> > > development). This should work fine, without the "-dirty" version suffix.
> >
> > I can try this, but it doesn't answer main question:
> > how can I recreate rootfs image starting from the point after
> > fetching Linux sources, so Yocto’s copy will remain intact?
>
> Well one way would be:
>
> bitbake -C compile virtual/kernel <imagename>
>
> (note the capital -C, not -c).
>
Hi, Paul. And thank you.
Looks like the most relevant answer.
IMO this "-C" flag is poorly documented. Thus if you don't know what it's
doing, you can't figure out to use it.
Only some info in maillists found by Google can give a clue what
"--clear-stamp" is intended for.
> In the near future "devtool modify" should support the kind of
> workflow that it looks like you're attempting to get (where you want
> to modify the kernel sources locally and then build them and/or
> incorporate them in an image) - it already works well for non-kernel recipes.
I think this workflow is useful for many things, not only for workaround
"-dirty", as in my case. It's not very convenient to wait for fetching sources
every time you do some little modification.
Why we need separate command i.e. "devtool modify" if we can go without it?
--
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
