From: Denys Dmytriyenko <denis@denix.org>
To: Ryan Eatmon <reatmon@ti.com>
Cc: meta-ti@lists.yoctoproject.org, Denys Dmytriyenko <denys@konsulko.com>
Subject: Re: [meta-ti] [master][PATCH] optee-client: remove patch that got accepted upstream
Date: Tue, 8 Apr 2025 11:00:46 -0400 [thread overview]
Message-ID: <20250408150045.GF13634@denix.org> (raw)
In-Reply-To: <a07bcf18-88a2-4eb4-b1f6-d0bad9fcf96f@ti.com>
On Tue, Apr 08, 2025 at 08:41:20AM -0500, Ryan Eatmon wrote:
>
> I was unsure about doing this...
>
> meta-arm added a second optee recipe version. So both exist:
> optee-client_4.3.0.bb
> optee-client_4.4.0.bb
>
> So "theoretically" the build should prefer the newer version, right?
No, that's not how it works. Our bbappend in version-agnostic and hence gets
applied to both base recipes. And then bbappend bumps the PV and they are now
matching and neither is newer than the other.
> But for some reason, our builds keep loading the 4.3.0 recipe and
> then our bbappend bumps the version to 4.4.0. The 4.3.0 recipe has
> this offending patch, but the 4.4.0 version does not.
>
> I've been trying to figure out why our builds keep locking into
> 4.3.0 when the 4.4.0 is sitting right there...
It is a downside of version-agnostic bbappends with PV changes - we've been
in this situation before. And we used some version-specific tricks to make it
work. Another solution is to make bbappend match a specific version, e.g.
rename it to optee-client_4.4%.bbappend for a while, until 4.5 is out...
> I agree that this patch is a good work around, but I'm not 100% sure
> it's the final best fix.
This way is more generic - below :remove would be no-op if such patch is not
in the SRC_URI.
> On 4/7/2025 10:08 PM, Denys Dmytriyenko wrote:
> >From: Denys Dmytriyenko <denys@konsulko.com>
> >
> >meta-arm adds a patch that was sent and accepted upstream, remove
> >it since mta-ti pulls a more recent verstion.
> >
> >Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
> >---
> > .../recipes-security/optee/optee-client-ti-version.inc | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> >diff --git a/meta-ti-bsp/recipes-security/optee/optee-client-ti-version.inc b/meta-ti-bsp/recipes-security/optee/optee-client-ti-version.inc
> >index 2c8977dd..a628e446 100644
> >--- a/meta-ti-bsp/recipes-security/optee/optee-client-ti-version.inc
> >+++ b/meta-ti-bsp/recipes-security/optee/optee-client-ti-version.inc
> >@@ -1,2 +1,6 @@
> > PV = "4.4.0+git"
> > SRCREV = "d221676a58b305bddbf97db00395205b3038de8e"
> >+
> >+SRC_URI:remove = " \
> >+ file://0001-tee-supplicant-add-udev-rule-and-systemd-service-fil.patch \
> >+"
next prev parent reply other threads:[~2025-04-08 15:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 3:08 [master][PATCH] optee-client: remove patch that got accepted upstream Denys Dmytriyenko
2025-04-08 13:41 ` [meta-ti] " Ryan Eatmon
2025-04-08 15:00 ` Denys Dmytriyenko [this message]
[not found] ` <18345B9CD58296A9.21691@lists.yoctoproject.org>
2025-04-08 14:09 ` Ryan Eatmon
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=20250408150045.GF13634@denix.org \
--to=denis@denix.org \
--cc=denys@konsulko.com \
--cc=meta-ti@lists.yoctoproject.org \
--cc=reatmon@ti.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.