From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6478538670852800512 X-Received: by 10.31.61.6 with SMTP id k6mr1997445vka.15.1508489514189; Fri, 20 Oct 2017 01:51:54 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 10.176.27.91 with SMTP id n27ls2371852uai.5.gmail; Fri, 20 Oct 2017 01:51:53 -0700 (PDT) X-Received: by 10.176.16.217 with SMTP id x25mr2142433uab.27.1508489513917; Fri, 20 Oct 2017 01:51:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508489513; cv=none; d=google.com; s=arc-20160816; b=c5QyQMIjG2rDHmvs2yYWV+qEqXQ97ykPffADBVcWxE0Zpd1s1q9xqKSGEPX9rHTR6+ xG8KOKMwNKDwGUWwmleDwvphfXNy2Uq0/y+6qCNN9nqXVOc3RamR8BBXuD2LwUTOxsy6 VJA7+ARiRWMPh0rnf4Tl3cmbjJZlyMjKZ0JMGXDCoq5qA/4GQxowa/5A1ytCKANc5854 AJ8I2ny1PvvzQ3VRvbaI2V36eYZeXb/HmP5CxNiBcDK3k0pVDEouWKtIvJpYrVOHPDRg Wp1emx+HK1xVi/76S5VUUIKkIxFpy69RInCHSApnF2hRAvCTVS8kRnaAd62tiKyJ+3ni lSIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; bh=3J06zkrTeX1e6VuWRmuEfGjvsktMA0/x5EGgwpg6eMI=; b=US6N/HEEIT0I03rp1lcgH6nqrevaU/7QpKrTRa0voiGlMzbeuL3NLHRoy/CCuPVO/h d2/Fucgp/0yHMOjeb4Qeft8J2RFc5/17HpZEQH8/Ph9CjVDKaEjbNCAOyZMza/AM2kdM jmWOxtDDHaTDG654E5Dx1QUHVmFhXq4+UlnjkkLKqes0D7FsdZQ92OlZNO6/iS+ey34D qjXS+ygqAFqWA8qjJxBwMus/G4srLN5GmcbZHKq2yaXMYZgvRFmN9DxJHeJm1A72hBuO OugKUZn/1IRgik+wIOT3qnbkB9XfY34zkCeelTzO2dUFWZRePzTW1JyYe5n2+6V7e/ul F7BA== ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=cuz/IFIn; spf=pass (google.com: domain of benbrenson89@googlemail.com designates 2607:f8b0:4001:c06::22e as permitted sender) smtp.mailfrom=benbrenson89@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Return-Path: Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com. [2607:f8b0:4001:c06::22e]) by gmr-mx.google.com with ESMTPS id t48si22733uad.5.2017.10.20.01.51.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 01:51:53 -0700 (PDT) Received-SPF: pass (google.com: domain of benbrenson89@googlemail.com designates 2607:f8b0:4001:c06::22e as permitted sender) client-ip=2607:f8b0:4001:c06::22e; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=cuz/IFIn; spf=pass (google.com: domain of benbrenson89@googlemail.com designates 2607:f8b0:4001:c06::22e as permitted sender) smtp.mailfrom=benbrenson89@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Received: by mail-io0-x22e.google.com with SMTP id 101so12540918ioj.3 for ; Fri, 20 Oct 2017 01:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3J06zkrTeX1e6VuWRmuEfGjvsktMA0/x5EGgwpg6eMI=; b=cuz/IFInUR+I297ELGhsiJFFPwGGv7DWgiCfa73ID+f2xcqY5cFxgAtwG8NUPwYyo9 fbW49tui0B3dn+uaSg1/CkPQ6TUXDuhdd3zQeIVKlIpxRHUbYC3hBsblRzec3Jtunb8X VE+T82JgZggTLynamJlNtCMTRPizd0vk0P6EFyGppA6BwooapL+T6GNX0eh7s0HLEg6b 0QW3EvRFBjLrpYuhq6PFZNfqSV+gOnOadUFJOZIgNM6xH44h1rvpNd8e975MZqOewK/l dq2qQ3wEaQTW3+hZDqrlFXHBZxAEVJMVg7DhTKibvmf1F+uQnX2C4ga0NqpGfndVPp6O 1xDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3J06zkrTeX1e6VuWRmuEfGjvsktMA0/x5EGgwpg6eMI=; b=sgTGyKDTcJbU8NvMB3+rGSdPjRoNtVYtwwmwlPc7ywPtDVGwNm30vokz9u9sHGbOFa mOnzEJ36b18+m9yLG83pX7WvpPn4fAMbTerr27J3mHR+CvsfCc3tq4uKFeDoTo0VqLoK k/NTBJTAD35CR9TxWwYCNSvbyWYkpegiiu9ZKEZLpIxDKKOfVGfV0MfJxhbN8VeOWEiL 5nUL7xK48uGFD7jrYcbxLFVgkUtqImRJtTxfg4Rl6d2cNac3CDHJT4zbX6P6ci5vBTs2 MmzQNBvKn+YGZOUoI5Ns1ncYjEtdlE96kd7HeCZcGQdUUfU6/shdUlmT9vR1rpuDWdOz G99A== X-Gm-Message-State: AMCzsaW7iVyTDu1l06r8BGIdepTkfnhds9exK0JhOyZGHHWY/fE7Kf9T yheofOzHePQqh6STlvwYpM3nHNj2X3KPOVOgA+Y= X-Google-Smtp-Source: ABhQp+TnM0AThsLYvB63qi9SlyTo/80bogueNoULrXl7vqO3eF/fGodDm/M5WzgSEJyq67SXeOFqju/6oi4n6Xmp9mY= X-Received: by 10.107.173.71 with SMTP id w68mr5540626ioe.57.1508489513617; Fri, 20 Oct 2017 01:51:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.155.106 with HTTP; Fri, 20 Oct 2017 01:51:53 -0700 (PDT) In-Reply-To: <0f1cc8e0-5c6c-9e35-7426-4e1380bf54e1@siemens.com> References: <81c9592a-74df-25d8-70ac-978f6ef1694e@siemens.com> <20171019111500.44f150f0@md1em3qc> <0f1cc8e0-5c6c-9e35-7426-4e1380bf54e1@siemens.com> From: Ben Brenson Date: Fri, 20 Oct 2017 10:51:53 +0200 Message-ID: Subject: Re: Introducing chroot tasks To: Claudius Heine Cc: Henning Schild , isar-users Content-Type: multipart/alternative; boundary="001a114467d69b4e08055bf69527" X-TUID: GtK8j5z4uU9f --001a114467d69b4e08055bf69527 Content-Type: text/plain; charset="UTF-8" In my opinion I think when introducing these feature, this may change Isars' architecture and further development. Maybe no scripts are copied into the chroot and executed inside it anymore. Instead those taks (setupscript.sh, build.sh, setup.sh) will directly be defined within the recipes. That would gave us the possibility of reusing all parts of the core isar layer and also overwrite them if needed. I think, creating scripts copying them somewhere and then execute them, is not for what bitbake was made for. It's much more powerfull and we should make use of it. So when it is possible to integrate this feature, we should think about of integrating it know. Maybe we can patch those 100 lines of code, a try to get it upstream meanwhile. Regards, Benedikt 2017-10-19 14:00 GMT+02:00 Claudius Heine : > Hi, > > > On 10/19/2017 12:24 PM, Ben Brenson wrote: > >> 2017-10-19 11:15 GMT+02:00 Henning Schild : >> >> On Thu, 19 Oct 2017 11:01:28 +0200 >>> "[ext] Claudius Heine" 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. >>> >> >> > >> 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.... >> > > A version that is independent of the chroot implementation might be more > useful upstream maybe. Call it a 'execution context' then you can specify > if a specific task should be run in a chroot environment, in a ssh shell. > Some repl or a programming language or the serial tty session might a bit > to much though but maybe possible. > > Cheers, > > Claudius > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de > --001a114467d69b4e08055bf69527 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my opinion I think when introducing these fea= ture, this may change Isars' architecture and further development.
<= /div>Maybe no scripts are copied into the chroot and executed inside it any= more.

Instead those taks (setupscript.sh, build.sh, setup.sh) will = directly be defined within the recipes.
That would gave us th= e possibility of reusing all parts of the core isar layer and also overwrit= e them if needed.

I think, creating scripts copying them = somewhere and then execute them, is not for what bitbake was made for.
<= /div>
It's much more powerfull and we should make use of it.

So when it is possible to integrate this feature, we should thi= nk about of integrating it know.

Maybe we can patch those= 100 lines of code, a try to get it upstream meanwhile.

<= br>
Regards,
Benedikt



2= 017-10-19 14:00 GMT+02:00 Claudius Heine <claudius.heine.ext@= siemens.com>:
Hi,


On 10/19/2017 12:24 PM, Ben Brenson wrote:
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> w= rote:

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 re= cipe.bb:

do_foo() {
=C2=A0 =C2=A0 =C2=A0 # Do something within chroot
}
do_foo[chroot] =3D "1"
do_foo[id] =3D "${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.
>>
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....

A version that is independent of the chroot implementation might be more us= eful upstream maybe. Call it a 'execution context' then you can spe= cify if a specific task should be run in a chroot environment, in a ssh she= ll. Some repl or a programming language or the serial tty session might a b= it to much though but maybe possible.

Cheers,

Claudius

--
DENX Software Engineering GmbH,=C2=A0 =C2=A0 =C2=A0 Managing Director: Wolf= gang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80= Email: ch@denx.de<= br>

--001a114467d69b4e08055bf69527--