All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Fabien Parent" <fparent@baylibre.com>
To: Jon Mason <jdmason@kudzu.us>
Cc: Ross Burton <ross@burtonini.com>,
	Denys Dmytriyenko <denis@denix.org>,
	 Gabor Abonyi <Gabor.Abonyi@arm.com>,
	"JPEWhacker@gmail.com" <JPEWhacker@gmail.com>,
	 "meta-arm@lists.yoctoproject.org"
	<meta-arm@lists.yoctoproject.org>, nd <nd@arm.com>
Subject: Re: [meta-arm] [PATCH 4/6] arm: trusted-firmware-m: Add recipe
Date: Thu, 16 Jul 2020 08:14:33 +0200	[thread overview]
Message-ID: <CAOwMV_wBTPWEz=c_8SnLo4uf5x9vFu4vyfSJEwkFEToU2Fxp0A@mail.gmail.com> (raw)
In-Reply-To: <20200702153948.GB21456@kudzu.us>

Hi,

I'm using meta-arm for the OP-TEE recipe (and soon I will replace our
TF-A recipe to be based on the one from meta-arm). I just discovered
this change today by receiving multiple report of the following error
when trying to build an image based on our layer:
    ERROR: Layer 'meta-arm' depends on layer 'arm-toolchain', but this
layer is not enabled in your configuration
    Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Usually the stable branches (dunfell in this case) don't add change
that could break other people's setup like adding a new hard
dependency. Most of the time the changes are bug-fixes, or minor
upgrades to packages.

Shall I consider meta-arm to not follow this rule, and in order to
never have breakage, pull a specific commit hash instead of pulling
the current release branch?

Thanks,
Fabien

On Thu, Jul 2, 2020 at 5:39 PM Jon Mason <jdmason@kudzu.us> wrote:
>
> On Thu, Jul 02, 2020 at 10:14:55AM +0100, Ross Burton wrote:
> > On Wed, 1 Jul 2020 at 19:08, Denys Dmytriyenko <denis@denix.org> wrote:
> > > meta-arm is meant to be a central place for shared components to be used by
> > > other BSPs. Kind of a community layer, if you like. And arm-toolchain is kind
> > > of a special layer and may not be desirable by all BSPs, so that would reduce
> > > overall usefulness of meta-arm layer. Each individual BSP (and meta-arm-bsp is
> > > one of those) is free to depend on arm-toolchain layer directly, if needed.
> >
> > Arguably, tfm should be in meta-arm for the same reasons that tfa is:
> > it's a shared component and not specific to a single BSP.
> >
> > The need for a binary toolchain is not ideal but simply adding the
> > layer doesn't cause it to be used by all recipes.  I propose that we
> > add this series now and evaluate the use of multiconfig to build a
> > second cross compiler in the future (sooner rather than later).
>
> To be clear, this is not a perminent requirement.  I would LOVE for it
> to be removed, and I am hoping it will be done within the next month
> or so.  IMHO, having TF-M available with this detriment is superior to
> not having it due to this issue.
>
> If this is a dealbreaker, please let me know.
>
> Thanks,
> Jon
>
> >
> > Ross
> 

  reply	other threads:[~2020-07-16  6:14 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-22  7:13 [PATCH 0/6] arm, arm-bsp, arm-toolchain: Add Trusted-Firmware-M recipe gabor.abonyi
2020-06-22  7:13 ` [PATCH 1/6] arm-toolchain: external-arm-toolchain: Rename Gabor Abonyi
2020-06-22  7:13 ` [PATCH 2/6] arm-toolchain: armcompiler: Add Arm Clang recipe Gabor Abonyi
2020-06-22 14:23   ` [meta-arm] " Jon Mason
2020-06-22 18:22   ` Ross Burton
2020-06-23  7:47     ` Gabor Abonyi
2020-06-26 10:05       ` Ross Burton
2020-06-22  7:13 ` [PATCH 3/6] arm: python3-cbor: Add recipe Gabor Abonyi
2020-06-22  7:13 ` [PATCH 4/6] arm: trusted-firmware-m: " Gabor Abonyi
2020-06-22 16:49   ` [meta-arm] " Denys Dmytriyenko
2020-06-22 17:26     ` Jon Mason
2020-06-22 17:36       ` Denys Dmytriyenko
2020-06-22 18:04         ` Joshua Watt
2020-06-23  8:59           ` Gabor Abonyi
2020-07-01 18:08             ` Denys Dmytriyenko
2020-07-02  9:14               ` Ross Burton
2020-07-02 15:39                 ` Jon Mason
2020-07-16  6:14                   ` Fabien Parent [this message]
2020-07-17 13:32                     ` Jon Mason
2020-06-22 18:23   ` Ross Burton
2020-06-22 18:43     ` Denys Dmytriyenko
2020-06-22 19:29       ` Ross Burton
2020-06-22 19:48         ` Denys Dmytriyenko
2020-06-23  7:06           ` Diego Sueiro
2020-07-01 18:10             ` [meta-arm] " Denys Dmytriyenko
2020-07-02 15:33               ` Jon Mason
2020-06-22  7:14 ` [PATCH 5/6] arm-bsp: musca_b1: Add machine Gabor Abonyi
2020-06-22  7:14 ` [PATCH 6/6] arm-bsp: musca_s1: " Gabor Abonyi

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='CAOwMV_wBTPWEz=c_8SnLo4uf5x9vFu4vyfSJEwkFEToU2Fxp0A@mail.gmail.com' \
    --to=fparent@baylibre.com \
    --cc=Gabor.Abonyi@arm.com \
    --cc=JPEWhacker@gmail.com \
    --cc=denis@denix.org \
    --cc=jdmason@kudzu.us \
    --cc=meta-arm@lists.yoctoproject.org \
    --cc=nd@arm.com \
    --cc=ross@burtonini.com \
    /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.