Yeah I know, but using chroot tasks was never a use case for bitbake and maybe will never be, I think.
I've never thought about using chroot tasks when running Yocto builds, but that has changed very fast when switching to Isar.
So maybe within Isar we have a more reasoned use case for chroot tasks, and if this feature works in isar, may be I have more chances to get those
changes upstream to bitbake?

I can try to get those changes upstream first....

Regards,
Benedikt





2017-10-19 11:15 GMT+02:00 Henning Schild <henning.schild@siemens.com>:
On Thu, 19 Oct 2017 11:01:28 +0200
"[ext] Claudius Heine" <claudius.heine.ext@siemens.com> wrote:

> Hi Ben,
>
> On 10/19/2017 10:38 AM, 'Ben Brenson' via isar-users wrote:
> > Hi,
> >
> > I want to submit some patches for defining and running chroot tasks
> > within bitbake recipes.
> > The following short example should show what I mean:
> >
> > Exampe recipe.bb:
> >
> > do_foo() {
> >      # Do something within chroot
> > }
> > do_foo[chroot] = "1"
> > do_foo[id] = "${BUILDCHROOT_ID}"
> > addtask do_foo after ... before ...
> >
> >
> > By setting the chroot flag the task automatically will be executed
> > within the chroot specified by the id flag.
> > My isar (https://github.com/benbrenson/isar) fork already supports
> > this feature, by using schroot.
> >
> > This will give much more flexibility and modularity to Isar. You
> > will be able to append/prepend things to those tasks
> > between layers easily.
> >
> > I have already seen, that there is another and better approach than
> > schroot -> proot.
> > I saw Alexander has already experimented with this feature, which
> > seems to work.
> >
> > So before posting some patches here, maybe changing this feature to
> > proot first would a better first-step?
>
> Yes. Since proot solves some more problems than schroot.
>
> Your implementation requires patching the bitbake code, so maybe we
> should try to get those changes upstream to bitbake?

IMHO, touching our copy of bitbake is an absolute NoGo! Such changes
need to go upstream first.

Henning

> Isar has currently has no own changes to upstream bitbake and I am
> not in favor of forking bitbake.
>
> Claudius
>