* [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds
2024-08-14 12:02 [OE-core][scarthgap 0/9] Patch review Steve Sakoman
@ 2024-08-14 12:02 ` Steve Sakoman
2024-08-14 14:25 ` Marta Rybczynska
2024-08-14 12:02 ` [OE-core][scarthgap 2/9] libyaml: ignore CVE-2024-35326 Steve Sakoman
` (7 subsequent siblings)
8 siblings, 1 reply; 22+ messages in thread
From: Steve Sakoman @ 2024-08-14 12:02 UTC (permalink / raw)
To: openembedded-core
From: Richard Purdie <richard.purdie@linuxfoundation.org>
Rtaher than trying to use a sqlite database over NFS from DL_DIR, work from
a local copy in STAGING DIR after fetching.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 03596904392d257572a905a182b92c780d636744)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
meta/classes/cve-check.bbclass | 7 ++++---
.../meta/cve-update-nvd2-native.bb | 18 +++++++++++++-----
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 93a2a1413d..c946de29a4 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -31,8 +31,9 @@
CVE_PRODUCT ??= "${BPN}"
CVE_VERSION ??= "${PV}"
-CVE_CHECK_DB_DIR ?= "${DL_DIR}/CVE_CHECK"
-CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_2-1.db"
+CVE_CHECK_DB_FILENAME ?= "nvdcve_2-1.db"
+CVE_CHECK_DB_DIR ?= "${STAGING_DIR}/CVE_CHECK"
+CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/${CVE_CHECK_DB_FILENAME}"
CVE_CHECK_DB_FILE_LOCK ?= "${CVE_CHECK_DB_FILE}.lock"
CVE_CHECK_LOG ?= "${T}/cve.log"
@@ -198,7 +199,7 @@ python do_cve_check () {
}
addtask cve_check before do_build
-do_cve_check[depends] = "cve-update-nvd2-native:do_fetch"
+do_cve_check[depends] = "cve-update-nvd2-native:do_unpack"
do_cve_check[nostamp] = "1"
python cve_check_cleanup () {
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb b/meta/recipes-core/meta/cve-update-nvd2-native.bb
index 1901641965..2d23d28c3e 100644
--- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -8,7 +8,6 @@ INHIBIT_DEFAULT_DEPS = "1"
inherit native
-deltask do_unpack
deltask do_patch
deltask do_configure
deltask do_compile
@@ -35,7 +34,9 @@ CVE_DB_INCR_UPDATE_AGE_THRES ?= "10368000"
# Number of attempts for each http query to nvd server before giving up
CVE_DB_UPDATE_ATTEMPTS ?= "5"
-CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_2.db"
+CVE_CHECK_DB_DLDIR_FILE ?= "${DL_DIR}/CVE_CHECK/${CVE_CHECK_DB_FILENAME}"
+CVE_CHECK_DB_DLDIR_LOCK ?= "${CVE_CHECK_DB_DLDIR_FILE}.lock"
+CVE_CHECK_DB_TEMP_FILE ?= "${CVE_CHECK_DB_FILE}.tmp"
python () {
if not bb.data.inherits_class("cve-check", d):
@@ -52,9 +53,9 @@ python do_fetch() {
bb.utils.export_proxies(d)
- db_file = d.getVar("CVE_CHECK_DB_FILE")
+ db_file = d.getVar("CVE_CHECK_DB_DLDIR_FILE")
db_dir = os.path.dirname(db_file)
- db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
+ db_tmp_file = d.getVar("CVE_CHECK_DB_TEMP_FILE")
cleanup_db_download(db_file, db_tmp_file)
# By default let's update the whole database (since time 0)
@@ -77,6 +78,7 @@ python do_fetch() {
pass
bb.utils.mkdirhier(db_dir)
+ bb.utils.mkdirhier(os.path.dirname(db_tmp_file))
if os.path.exists(db_file):
shutil.copy2(db_file, db_tmp_file)
@@ -89,10 +91,16 @@ python do_fetch() {
os.remove(db_tmp_file)
}
-do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
+do_fetch[lockfiles] += "${CVE_CHECK_DB_DLDIR_LOCK}"
do_fetch[file-checksums] = ""
do_fetch[vardeps] = ""
+python do_unpack() {
+ import shutil
+ shutil.copyfile(d.getVar("CVE_CHECK_DB_DLDIR_FILE"), d.getVar("CVE_CHECK_DB_FILE"))
+}
+do_unpack[lockfiles] += "${CVE_CHECK_DB_DLDIR_LOCK} ${CVE_CHECK_DB_FILE_LOCK}"
+
def cleanup_db_download(db_file, db_tmp_file):
"""
Cleanup the download space from possible failed downloads
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds
2024-08-14 12:02 ` [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds Steve Sakoman
@ 2024-08-14 14:25 ` Marta Rybczynska
2024-08-14 14:33 ` Steve Sakoman
[not found] ` <17EB9EED917D6CD6.10903@lists.openembedded.org>
0 siblings, 2 replies; 22+ messages in thread
From: Marta Rybczynska @ 2024-08-14 14:25 UTC (permalink / raw)
To: steve; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
On Wed, Aug 14, 2024 at 2:02 PM Steve Sakoman via lists.openembedded.org
<steve=sakoman.com@lists.openembedded.org> wrote:
> From: Richard Purdie <richard.purdie@linuxfoundation.org>
>
> Rtaher than trying to use a sqlite database over NFS from DL_DIR, work from
> a local copy in STAGING DIR after fetching.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> (cherry picked from commit 03596904392d257572a905a182b92c780d636744)
> Signed-off-by: Steve Sakoman <steve@sakoman.com>
>
This patch is changing the ABI (well... variables). I think we should come
back to the old naming
for the downloaded copy before backporting.
Regards,
Marta
[-- Attachment #2: Type: text/html, Size: 1358 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds
2024-08-14 14:25 ` Marta Rybczynska
@ 2024-08-14 14:33 ` Steve Sakoman
[not found] ` <17EB9EED917D6CD6.10903@lists.openembedded.org>
1 sibling, 0 replies; 22+ messages in thread
From: Steve Sakoman @ 2024-08-14 14:33 UTC (permalink / raw)
To: Marta Rybczynska; +Cc: openembedded-core
Thanks for reviewing Marta!
I'll drop this backported patch for both scarthgap and kirkstone and
wait for appropriate versions of the patch to be submitted.
Steve
On Wed, Aug 14, 2024 at 7:25 AM Marta Rybczynska <rybczynska@gmail.com> wrote:
>
>
>
> On Wed, Aug 14, 2024 at 2:02 PM Steve Sakoman via lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> wrote:
>>
>> From: Richard Purdie <richard.purdie@linuxfoundation.org>
>>
>> Rtaher than trying to use a sqlite database over NFS from DL_DIR, work from
>> a local copy in STAGING DIR after fetching.
>>
>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>> (cherry picked from commit 03596904392d257572a905a182b92c780d636744)
>> Signed-off-by: Steve Sakoman <steve@sakoman.com>
>
>
>
> This patch is changing the ABI (well... variables). I think we should come back to the old naming
> for the downloaded copy before backporting.
>
> Regards,
> Marta
^ permalink raw reply [flat|nested] 22+ messages in thread[parent not found: <17EB9EED917D6CD6.10903@lists.openembedded.org>]
* Re: [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds
[not found] ` <17EB9EED917D6CD6.10903@lists.openembedded.org>
@ 2024-10-22 12:59 ` Steve Sakoman
2024-10-22 13:09 ` Richard Purdie
0 siblings, 1 reply; 22+ messages in thread
From: Steve Sakoman @ 2024-10-22 12:59 UTC (permalink / raw)
To: Marta Rybczynska; +Cc: steve, openembedded-core
Hi Marta,
We are still getting database errors on scarthgap (and occasionally on
kirkstone if memory serves), so I think we need to reconsider
backporting this patch.
Can you suggest changes that would make it acceptable to you?
Steve
On Wed, Aug 14, 2024 at 7:33 AM Steve Sakoman via
lists.openembedded.org <steve=sakoman.com@lists.openembedded.org>
wrote:
>
> Thanks for reviewing Marta!
>
> I'll drop this backported patch for both scarthgap and kirkstone and
> wait for appropriate versions of the patch to be submitted.
>
> Steve
>
> On Wed, Aug 14, 2024 at 7:25 AM Marta Rybczynska <rybczynska@gmail.com> wrote:
> >
> >
> >
> > On Wed, Aug 14, 2024 at 2:02 PM Steve Sakoman via lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> wrote:
> >>
> >> From: Richard Purdie <richard.purdie@linuxfoundation.org>
> >>
> >> Rtaher than trying to use a sqlite database over NFS from DL_DIR, work from
> >> a local copy in STAGING DIR after fetching.
> >>
> >> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> >> (cherry picked from commit 03596904392d257572a905a182b92c780d636744)
> >> Signed-off-by: Steve Sakoman <steve@sakoman.com>
> >
> >
> >
> > This patch is changing the ABI (well... variables). I think we should come back to the old naming
> > for the downloaded copy before backporting.
> >
> > Regards,
> > Marta
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#203323): https://lists.openembedded.org/g/openembedded-core/message/203323
> Mute This Topic: https://lists.openembedded.org/mt/107893246/3620601
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [steve@sakoman.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds
2024-10-22 12:59 ` Steve Sakoman
@ 2024-10-22 13:09 ` Richard Purdie
2024-10-25 5:08 ` Marta Rybczynska
0 siblings, 1 reply; 22+ messages in thread
From: Richard Purdie @ 2024-10-22 13:09 UTC (permalink / raw)
To: steve, Marta Rybczynska; +Cc: openembedded-core
On Tue, 2024-10-22 at 05:59 -0700, Steve Sakoman via lists.openembedded.org wrote:
> Hi Marta,
>
> We are still getting database errors on scarthgap (and occasionally on
> kirkstone if memory serves), so I think we need to reconsider
> backporting this patch.
>
> Can you suggest changes that would make it acceptable to you?
Just for complete context, moving the database on master did isolate the database issues to scarthgap so the problem is in the older branches at this point.
Cheers,
Richard
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds
2024-10-22 13:09 ` Richard Purdie
@ 2024-10-25 5:08 ` Marta Rybczynska
2024-10-29 22:40 ` Richard Purdie
0 siblings, 1 reply; 22+ messages in thread
From: Marta Rybczynska @ 2024-10-25 5:08 UTC (permalink / raw)
To: Richard Purdie; +Cc: steve, openembedded-core
[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]
On Tue, Oct 22, 2024 at 3:09 PM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2024-10-22 at 05:59 -0700, Steve Sakoman via
> lists.openembedded.org wrote:
> > Hi Marta,
> >
> > We are still getting database errors on scarthgap (and occasionally on
> > kirkstone if memory serves), so I think we need to reconsider
> > backporting this patch.
> >
> > Can you suggest changes that would make it acceptable to you?
>
> Just for complete context, moving the database on master did isolate the
> database issues to scarthgap so the problem is in the older branches at
> this point.
>
>
Hello all,
To make a summary, this patch did not solve the issue on master, it was the
change of the database path that did. Is this correct? And we still do not
know what the cause is? So, when we change the path on all branches, the
issue is likely to come back ?
My problem with this patch is that it changes names of variables that are
in use. It should at least not fail silently for people who decide to use a
pinned database.
Do you see another solution than renaming the _DLDIR_ version to the old
name?
Kind regards,
Marta
[-- Attachment #2: Type: text/html, Size: 1718 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds
2024-10-25 5:08 ` Marta Rybczynska
@ 2024-10-29 22:40 ` Richard Purdie
2024-11-05 11:55 ` Marta Rybczynska
0 siblings, 1 reply; 22+ messages in thread
From: Richard Purdie @ 2024-10-29 22:40 UTC (permalink / raw)
To: Marta Rybczynska; +Cc: steve, openembedded-core
On Fri, 2024-10-25 at 07:08 +0200, Marta Rybczynska wrote:
> To make a summary, this patch did not solve the issue on master, it
> was the change of the database path that did.
Originally, I couldn't isolate the change to tell or not. Now, by
changing the database path we've shown the issue is occurring on the
branches without the patch.
> Is this correct? And we still do not know what the cause is? So,
> when we change the path on all branches, the issue is likely to come
> back ?
I think if we move the database operations to the local filesystem and
out of DL_DIR, we're likely to stop seeing the issues. We know they're
isolated to something about the older releases.
> My problem with this patch is that it changes names of variables that
> are in use. It should at least not fail silently for people who
> decide to use a pinned database.
>
> Do you see another solution than renaming the _DLDIR_ version to the
> old name?
We either backport the patch as is and have the same functionality
across the branches, or we do some special version of the patch for the
LTS branches. In many ways I think it might be better to have things
consistent rather than doing something special with all the confusion
that can cause, even if people do have to actively adapt to the change.
Cheers,
Richard
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds
2024-10-29 22:40 ` Richard Purdie
@ 2024-11-05 11:55 ` Marta Rybczynska
2024-11-05 13:53 ` Steve Sakoman
0 siblings, 1 reply; 22+ messages in thread
From: Marta Rybczynska @ 2024-11-05 11:55 UTC (permalink / raw)
To: Richard Purdie; +Cc: Steve Sakoman, OE-core
[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]
On Wed, 30 Oct 2024, 07:40 Richard Purdie, <
richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2024-10-25 at 07:08 +0200, Marta Rybczynska wrote:
> > To make a summary, this patch did not solve the issue on master, it
> > was the change of the database path that did.
>
> Originally, I couldn't isolate the change to tell or not. Now, by
> changing the database path we've shown the issue is occurring on the
> branches without the patch.
>
> > Is this correct? And we still do not know what the cause is? So,
> > when we change the path on all branches, the issue is likely to come
> > back ?
>
> I think if we move the database operations to the local filesystem and
> out of DL_DIR, we're likely to stop seeing the issues. We know they're
> isolated to something about the older releases.
>
> > My problem with this patch is that it changes names of variables that
> > are in use. It should at least not fail silently for people who
> > decide to use a pinned database.
> >
> > Do you see another solution than renaming the _DLDIR_ version to the
> > old name?
>
> We either backport the patch as is and have the same functionality
> across the branches, or we do some special version of the patch for the
> LTS branches. In many ways I think it might be better to have things
> consistent rather than doing something special with all the confusion
> that can cause, even if people do have to actively adapt to the change.
>
Well, I'm not happy with a change of variables in existing releases.
However the split would be complicated either way.
And as a bonus, I'm not able to reproduce on my systems (the lack of NFS
might be a factor).
So, I'll say go for this backport even if unhappy with it.
Kind regards,
Marta
>
>
[-- Attachment #2: Type: text/html, Size: 2553 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds
2024-11-05 11:55 ` Marta Rybczynska
@ 2024-11-05 13:53 ` Steve Sakoman
0 siblings, 0 replies; 22+ messages in thread
From: Steve Sakoman @ 2024-11-05 13:53 UTC (permalink / raw)
To: Marta Rybczynska; +Cc: Richard Purdie, OE-core
On Tue, Nov 5, 2024 at 3:55 AM Marta Rybczynska <rybczynska@gmail.com> wrote:
>
>
>
> On Wed, 30 Oct 2024, 07:40 Richard Purdie, <richard.purdie@linuxfoundation.org> wrote:
>>
>> On Fri, 2024-10-25 at 07:08 +0200, Marta Rybczynska wrote:
>> > To make a summary, this patch did not solve the issue on master, it
>> > was the change of the database path that did.
>>
>> Originally, I couldn't isolate the change to tell or not. Now, by
>> changing the database path we've shown the issue is occurring on the
>> branches without the patch.
>>
>> > Is this correct? And we still do not know what the cause is? So,
>> > when we change the path on all branches, the issue is likely to come
>> > back ?
>>
>> I think if we move the database operations to the local filesystem and
>> out of DL_DIR, we're likely to stop seeing the issues. We know they're
>> isolated to something about the older releases.
>>
>> > My problem with this patch is that it changes names of variables that
>> > are in use. It should at least not fail silently for people who
>> > decide to use a pinned database.
>> >
>> > Do you see another solution than renaming the _DLDIR_ version to the
>> > old name?
>>
>> We either backport the patch as is and have the same functionality
>> across the branches, or we do some special version of the patch for the
>> LTS branches. In many ways I think it might be better to have things
>> consistent rather than doing something special with all the confusion
>> that can cause, even if people do have to actively adapt to the change.
>
>
> Well, I'm not happy with a change of variables in existing releases. However the split would be complicated either way.
>
> And as a bonus, I'm not able to reproduce on my systems (the lack of NFS might be a factor).
>
> So, I'll say go for this backport even if unhappy with it.
Thanks Marta, I will proceed with that.
Steve4
^ permalink raw reply [flat|nested] 22+ messages in thread
* [OE-core][scarthgap 2/9] libyaml: ignore CVE-2024-35326
2024-08-14 12:02 [OE-core][scarthgap 0/9] Patch review Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds Steve Sakoman
@ 2024-08-14 12:02 ` Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 3/9] python3-certifi: Fix CVE-2024-39689 Steve Sakoman
` (6 subsequent siblings)
8 siblings, 0 replies; 22+ messages in thread
From: Steve Sakoman @ 2024-08-14 12:02 UTC (permalink / raw)
To: openembedded-core
From: Peter Marko <peter.marko@siemens.com>
This is the same problem as already ignored CVE-2024-35328.
See laso this comment in addition:
https://github.com/yaml/libyaml/issues/298#issuecomment-2167684233
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
meta/recipes-support/libyaml/libyaml_0.2.5.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-support/libyaml/libyaml_0.2.5.bb b/meta/recipes-support/libyaml/libyaml_0.2.5.bb
index 1c6a5fcb45..334d9113d2 100644
--- a/meta/recipes-support/libyaml/libyaml_0.2.5.bb
+++ b/meta/recipes-support/libyaml/libyaml_0.2.5.bb
@@ -18,6 +18,7 @@ inherit autotools
DISABLE_STATIC:class-nativesdk = ""
DISABLE_STATIC:class-native = ""
+CVE_STATUS[CVE-2024-35326] = "upstream-wontfix: Upstream thinks there is no working code that is exploitable - https://github.com/yaml/libyaml/issues/302"
CVE_STATUS[CVE-2024-35328] = "upstream-wontfix: Upstream thinks there is no working code that is exploitable - https://github.com/yaml/libyaml/issues/302"
BBCLASSEXTEND = "native nativesdk"
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [OE-core][scarthgap 3/9] python3-certifi: Fix CVE-2024-39689
2024-08-14 12:02 [OE-core][scarthgap 0/9] Patch review Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 1/9] cve_check: Use a local copy of the database during builds Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 2/9] libyaml: ignore CVE-2024-35326 Steve Sakoman
@ 2024-08-14 12:02 ` Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 4/9] ffmpeg: fix CVE-2023-50008 Steve Sakoman
` (5 subsequent siblings)
8 siblings, 0 replies; 22+ messages in thread
From: Steve Sakoman @ 2024-08-14 12:02 UTC (permalink / raw)
To: openembedded-core
From: Soumya Sambu <soumya.sambu@windriver.com>
Certifi is a curated collection of Root Certificates for validating the
trustworthiness of SSL certificates while verifying the identity of TLS
hosts. Certifi starting in 2021.05.30 and prior to 2024.07.4 recognized
root certificates from `GLOBALTRUST`. Certifi 2024.07.04 removes root
certificates from `GLOBALTRUST` from the root store. These are in the
process of being removed from Mozilla's trust store. `GLOBALTRUST`'s root
certificates are being removed pursuant to an investigation which
identified "long-running and unresolved compliance issues."Certifi is a
curated collection of Root Certificates for validating the trustworthiness
of SSL certificates while verifying the identity of TLS hosts. Certifi
starting in 2021.05.30 and prior to 2024.07.4 recognized root certificates
from `GLOBALTRUST`. Certifi 2024.07.04 removes root certificates from
`GLOBALTRUST` from the root store. These are in the process of being removed
from Mozilla's trust store. `GLOBALTRUST`'s root certificates are being
removed pursuant to an investigation which identified "long-running and
unresolved compliance issues."
References:
https://nvd.nist.gov/vuln/detail/CVE-2024-39689
Upstream-patch:
https://github.com/certifi/python-certifi/commit/bd8153872e9c6fc98f4023df9c2deaffea2fa463
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
.../python3-certifi/CVE-2024-39689.patch | 69 +++++++++++++++++++
.../python/python3-certifi_2024.2.2.bb | 3 +
2 files changed, 72 insertions(+)
create mode 100644 meta/recipes-devtools/python/python3-certifi/CVE-2024-39689.patch
diff --git a/meta/recipes-devtools/python/python3-certifi/CVE-2024-39689.patch b/meta/recipes-devtools/python/python3-certifi/CVE-2024-39689.patch
new file mode 100644
index 0000000000..a2ecc15d2c
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-certifi/CVE-2024-39689.patch
@@ -0,0 +1,69 @@
+From bd8153872e9c6fc98f4023df9c2deaffea2fa463 Mon Sep 17 00:00:00 2001
+From: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
+Date: Wed, 3 Jul 2024 21:34:29 -0400
+Subject: [PATCH] 2024.07.04 (#295)
+
+Co-authored-by: alex <772+alex@users.noreply.github.com>
+
+CVE: CVE-2024-39689
+
+Upstream-Status: Backport [https://github.com/certifi/python-certifi/commit/bd8153872e9c6fc98f4023df9c2deaffea2fa463]
+
+Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
+---
+ certifi/cacert.pem | 40 ----------------------------------------
+ 1 file changed, 40 deletions(-)
+
+diff --git a/certifi/cacert.pem b/certifi/cacert.pem
+index 1bec256..6bb8cf8 100644
+--- a/certifi/cacert.pem
++++ b/certifi/cacert.pem
+@@ -3857,46 +3857,6 @@ DgQWBBQxCpCPtsad0kRLgLWi5h+xEk8blTAKBggqhkjOPQQDAwNoADBlAjEA31SQ
+ +RHUjE7AwWHCFUyqqx0LMV87HOIAl0Qx5v5zli/altP+CAezNIm8BZ/3Hobui3A=
+ -----END CERTIFICATE-----
+
+-# Issuer: CN=GLOBALTRUST 2020 O=e-commerce monitoring GmbH
+-# Subject: CN=GLOBALTRUST 2020 O=e-commerce monitoring GmbH
+-# Label: "GLOBALTRUST 2020"
+-# Serial: 109160994242082918454945253
+-# MD5 Fingerprint: 8a:c7:6f:cb:6d:e3:cc:a2:f1:7c:83:fa:0e:78:d7:e8
+-# SHA1 Fingerprint: d0:67:c1:13:51:01:0c:aa:d0:c7:6a:65:37:31:16:26:4f:53:71:a2
+-# SHA256 Fingerprint: 9a:29:6a:51:82:d1:d4:51:a2:e3:7f:43:9b:74:da:af:a2:67:52:33:29:f9:0f:9a:0d:20:07:c3:34:e2:3c:9a
+------BEGIN CERTIFICATE-----
+-MIIFgjCCA2qgAwIBAgILWku9WvtPilv6ZeUwDQYJKoZIhvcNAQELBQAwTTELMAkG
+-A1UEBhMCQVQxIzAhBgNVBAoTGmUtY29tbWVyY2UgbW9uaXRvcmluZyBHbWJIMRkw
+-FwYDVQQDExBHTE9CQUxUUlVTVCAyMDIwMB4XDTIwMDIxMDAwMDAwMFoXDTQwMDYx
+-MDAwMDAwMFowTTELMAkGA1UEBhMCQVQxIzAhBgNVBAoTGmUtY29tbWVyY2UgbW9u
+-aXRvcmluZyBHbWJIMRkwFwYDVQQDExBHTE9CQUxUUlVTVCAyMDIwMIICIjANBgkq
+-hkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAri5WrRsc7/aVj6B3GyvTY4+ETUWiD59b
+-RatZe1E0+eyLinjF3WuvvcTfk0Uev5E4C64OFudBc/jbu9G4UeDLgztzOG53ig9Z
+-YybNpyrOVPu44sB8R85gfD+yc/LAGbaKkoc1DZAoouQVBGM+uq/ufF7MpotQsjj3
+-QWPKzv9pj2gOlTblzLmMCcpL3TGQlsjMH/1WljTbjhzqLL6FLmPdqqmV0/0plRPw
+-yJiT2S0WR5ARg6I6IqIoV6Lr/sCMKKCmfecqQjuCgGOlYx8ZzHyyZqjC0203b+J+
+-BlHZRYQfEs4kUmSFC0iAToexIiIwquuuvuAC4EDosEKAA1GqtH6qRNdDYfOiaxaJ
+-SaSjpCuKAsR49GiKweR6NrFvG5Ybd0mN1MkGco/PU+PcF4UgStyYJ9ORJitHHmkH
+-r96i5OTUawuzXnzUJIBHKWk7buis/UDr2O1xcSvy6Fgd60GXIsUf1DnQJ4+H4xj0
+-4KlGDfV0OoIu0G4skaMxXDtG6nsEEFZegB31pWXogvziB4xiRfUg3kZwhqG8k9Me
+-dKZssCz3AwyIDMvUclOGvGBG85hqwvG/Q/lwIHfKN0F5VVJjjVsSn8VoxIidrPIw
+-q7ejMZdnrY8XD2zHc+0klGvIg5rQmjdJBKuxFshsSUktq6HQjJLyQUp5ISXbY9e2
+-nKd+Qmn7OmMCAwEAAaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC
+-AQYwHQYDVR0OBBYEFNwuH9FhN3nkq9XVsxJxaD1qaJwiMB8GA1UdIwQYMBaAFNwu
+-H9FhN3nkq9XVsxJxaD1qaJwiMA0GCSqGSIb3DQEBCwUAA4ICAQCR8EICaEDuw2jA
+-VC/f7GLDw56KoDEoqoOOpFaWEhCGVrqXctJUMHytGdUdaG/7FELYjQ7ztdGl4wJC
+-XtzoRlgHNQIw4Lx0SsFDKv/bGtCwr2zD/cuz9X9tAy5ZVp0tLTWMstZDFyySCstd
+-6IwPS3BD0IL/qMy/pJTAvoe9iuOTe8aPmxadJ2W8esVCgmxcB9CpwYhgROmYhRZf
+-+I/KARDOJcP5YBugxZfD0yyIMaK9MOzQ0MAS8cE54+X1+NZK3TTN+2/BT+MAi1bi
+-kvcoskJ3ciNnxz8RFbLEAwW+uxF7Cr+obuf/WEPPm2eggAe2HcqtbepBEX4tdJP7
+-wry+UUTF72glJ4DjyKDUEuzZpTcdN3y0kcra1LGWge9oXHYQSa9+pTeAsRxSvTOB
+-TI/53WXZFM2KJVj04sWDpQmQ1GwUY7VA3+vA/MRYfg0UFodUJ25W5HCEuGwyEn6C
+-MUO+1918oa2u1qsgEu8KwxCMSZY13At1XrFP1U80DhEgB3VDRemjEdqso5nCtnkn
+-4rnvyOL2NSl6dPrFf4IFYqYK6miyeUcGbvJXqBUzxvd4Sj1Ce2t+/vdG6tHrju+I
+-aFvowdlxfv1k7/9nR4hYJS8+hge9+6jlgqispdNpQ80xiEmEU5LAsTkbOYMBMMTy
+-qfrQA71yN2BWHzZ8vTmR9W0Nv3vXkg==
+------END CERTIFICATE-----
+-
+ # Issuer: CN=ANF Secure Server Root CA O=ANF Autoridad de Certificacion OU=ANF CA Raiz
+ # Subject: CN=ANF Secure Server Root CA O=ANF Autoridad de Certificacion OU=ANF CA Raiz
+ # Label: "ANF Secure Server Root CA"
+--
+2.40.0
diff --git a/meta/recipes-devtools/python/python3-certifi_2024.2.2.bb b/meta/recipes-devtools/python/python3-certifi_2024.2.2.bb
index 4e61b8d9d4..116add2079 100644
--- a/meta/recipes-devtools/python/python3-certifi_2024.2.2.bb
+++ b/meta/recipes-devtools/python/python3-certifi_2024.2.2.bb
@@ -7,6 +7,9 @@ HOMEPAGE = " http://certifi.io/"
LICENSE = "ISC"
LIC_FILES_CHKSUM = "file://LICENSE;md5=11618cb6a975948679286b1211bd573c"
+SRC_URI += "file://CVE-2024-39689.patch \
+ "
+
SRC_URI[sha256sum] = "0569859f95fc761b18b45ef421b1290a0f65f147e92a1e5eb3e635f9a5e4e66f"
inherit pypi setuptools3
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [OE-core][scarthgap 4/9] ffmpeg: fix CVE-2023-50008
2024-08-14 12:02 [OE-core][scarthgap 0/9] Patch review Steve Sakoman
` (2 preceding siblings ...)
2024-08-14 12:02 ` [OE-core][scarthgap 3/9] python3-certifi: Fix CVE-2024-39689 Steve Sakoman
@ 2024-08-14 12:02 ` Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 5/9] python3-pycryptodome(x): use python_setuptools_build_meta build class Steve Sakoman
` (4 subsequent siblings)
8 siblings, 0 replies; 22+ messages in thread
From: Steve Sakoman @ 2024-08-14 12:02 UTC (permalink / raw)
To: openembedded-core
From: Archana Polampalli <archana.polampalli@windriver.com>
Buffer Overflow vulnerability in Ffmpeg v.n6.1-3-g466799d4f5 allows a local attacker
to execute arbitrary code via the av_malloc function in libavutil/mem.c:105:9 component.
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
.../ffmpeg/ffmpeg/CVE-2023-50008.patch | 29 +++++++++++++++++++
.../recipes-multimedia/ffmpeg/ffmpeg_6.1.1.bb | 1 +
2 files changed, 30 insertions(+)
create mode 100644 meta/recipes-multimedia/ffmpeg/ffmpeg/CVE-2023-50008.patch
diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg/CVE-2023-50008.patch b/meta/recipes-multimedia/ffmpeg/ffmpeg/CVE-2023-50008.patch
new file mode 100644
index 0000000000..4b8935628f
--- /dev/null
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg/CVE-2023-50008.patch
@@ -0,0 +1,29 @@
+From 5f87a68cf70dafeab2fb89b42e41a4c29053b89b Mon Sep 17 00:00:00 2001
+From: Paul B Mahol <onemda@gmail.com>
+Date: Mon, 27 Nov 2023 12:08:20 +0100
+Subject: [PATCH] avfilter/vf_colorcorrect: fix memory leaks
+
+CVE: CVE-2023-50008
+
+Upstream-Status: Backport [https://github.com/FFmpeg/FFmpeg/commit/5f87a68cf70dafeab2fb89b42e41a4c29053b89b]
+
+Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
+---
+ libavfilter/vf_colorcorrect.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/libavfilter/vf_colorcorrect.c b/libavfilter/vf_colorcorrect.c
+index 1c4dea5..6bdec2c 100644
+--- a/libavfilter/vf_colorcorrect.c
++++ b/libavfilter/vf_colorcorrect.c
+@@ -497,6 +497,8 @@ static av_cold void uninit(AVFilterContext *ctx)
+ ColorCorrectContext *s = ctx->priv;
+
+ av_freep(&s->analyzeret);
++ av_freep(&s->uhistogram);
++ av_freep(&s->vhistogram);
+ }
+
+ static const AVFilterPad colorcorrect_inputs[] = {
+--
+2.40.0
diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_6.1.1.bb b/meta/recipes-multimedia/ffmpeg/ffmpeg_6.1.1.bb
index 05919e6ffd..9b74d78fb1 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_6.1.1.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_6.1.1.bb
@@ -30,6 +30,7 @@ SRC_URI = " \
file://CVE-2023-49502.patch \
file://CVE-2024-31578.patch \
file://CVE-2024-31582.patch \
+ file://CVE-2023-50008.patch \
"
SRC_URI[sha256sum] = "8684f4b00f94b85461884c3719382f1261f0d9eb3d59640a1f4ac0873616f968"
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [OE-core][scarthgap 5/9] python3-pycryptodome(x): use python_setuptools_build_meta build class
2024-08-14 12:02 [OE-core][scarthgap 0/9] Patch review Steve Sakoman
` (3 preceding siblings ...)
2024-08-14 12:02 ` [OE-core][scarthgap 4/9] ffmpeg: fix CVE-2023-50008 Steve Sakoman
@ 2024-08-14 12:02 ` Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 6/9] systemd: Mitigate /var/log type mismatch issue Steve Sakoman
` (3 subsequent siblings)
8 siblings, 0 replies; 22+ messages in thread
From: Steve Sakoman @ 2024-08-14 12:02 UTC (permalink / raw)
To: openembedded-core
From: Ross Burton <ross.burton@arm.com>
This package can be built using pep517 classes now.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit a32fa3e64d1daf5846c29403e9f258aea42212d3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
meta/recipes-devtools/python/python3-pycryptodome_3.20.0.bb | 2 +-
meta/recipes-devtools/python/python3-pycryptodomex_3.20.0.bb | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/python/python3-pycryptodome_3.20.0.bb b/meta/recipes-devtools/python/python3-pycryptodome_3.20.0.bb
index d24fa58d43..6c93c205ac 100644
--- a/meta/recipes-devtools/python/python3-pycryptodome_3.20.0.bb
+++ b/meta/recipes-devtools/python/python3-pycryptodome_3.20.0.bb
@@ -1,5 +1,5 @@
require python-pycryptodome.inc
-inherit setuptools3
+inherit python_setuptools_build_meta
SRC_URI[sha256sum] = "09609209ed7de61c2b560cc5c8c4fbf892f8b15b1faf7e4cbffac97db1fffda7"
diff --git a/meta/recipes-devtools/python/python3-pycryptodomex_3.20.0.bb b/meta/recipes-devtools/python/python3-pycryptodomex_3.20.0.bb
index 2673ea8326..54578d2850 100644
--- a/meta/recipes-devtools/python/python3-pycryptodomex_3.20.0.bb
+++ b/meta/recipes-devtools/python/python3-pycryptodomex_3.20.0.bb
@@ -1,5 +1,5 @@
require python-pycryptodome.inc
-inherit setuptools3
+inherit python_setuptools_build_meta
SRC_URI[sha256sum] = "7a710b79baddd65b806402e14766c721aee8fb83381769c27920f26476276c1e"
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [OE-core][scarthgap 6/9] systemd: Mitigate /var/log type mismatch issue
2024-08-14 12:02 [OE-core][scarthgap 0/9] Patch review Steve Sakoman
` (4 preceding siblings ...)
2024-08-14 12:02 ` [OE-core][scarthgap 5/9] python3-pycryptodome(x): use python_setuptools_build_meta build class Steve Sakoman
@ 2024-08-14 12:02 ` Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 7/9] systemd: Mitigate /var/tmp " Steve Sakoman
` (2 subsequent siblings)
8 siblings, 0 replies; 22+ messages in thread
From: Steve Sakoman @ 2024-08-14 12:02 UTC (permalink / raw)
To: openembedded-core
From: Niko Mauno <niko.mauno@vaisala.com>
When VOLATILE_LOG_DIR evaluates as True, the base-files recipe provides
/var/log -> /var/volatile/log symlink which is in conflict with systemd
upstream tmpfiles.d/var.conf.in which defines it as a directory.
This generates following error in journal:
Jul 03 14:28:00 qemux86-64 systemd-tmpfiles[165]: "/var/log" already exists and is not a directory.
Mitigate the issue by defining /var/log as symlink corresponding to
the one created by base-files, when appropriate.
(From OE-Core rev: 711ee36e88c8968e3c45ea787b3adcf64352adf9)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
meta/recipes-core/systemd/systemd_255.4.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd_255.4.bb b/meta/recipes-core/systemd/systemd_255.4.bb
index f58a1bc2b6..0ccca8a567 100644
--- a/meta/recipes-core/systemd/systemd_255.4.bb
+++ b/meta/recipes-core/systemd/systemd_255.4.bb
@@ -307,9 +307,10 @@ do_install() {
fi
if "${@'true' if oe.types.boolean(d.getVar('VOLATILE_LOG_DIR')) else 'false'}"; then
- # /var/log is typically a symbolic link to inside /var/volatile,
- # which is expected to be empty.
+ # base-files recipe provides /var/log which is a symlink to /var/volatile/log
rm -rf ${D}${localstatedir}/log
+ printf 'L\t\t%s/log\t\t-\t-\t-\t-\t%s/volatile/log\n' "${localstatedir}" \
+ "${localstatedir}" >>${D}${nonarch_libdir}/tmpfiles.d/00-create-volatile.conf
elif [ -e ${D}${localstatedir}/log/journal ]; then
chown root:systemd-journal ${D}${localstatedir}/log/journal
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [OE-core][scarthgap 7/9] systemd: Mitigate /var/tmp type mismatch issue
2024-08-14 12:02 [OE-core][scarthgap 0/9] Patch review Steve Sakoman
` (5 preceding siblings ...)
2024-08-14 12:02 ` [OE-core][scarthgap 6/9] systemd: Mitigate /var/log type mismatch issue Steve Sakoman
@ 2024-08-14 12:02 ` Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 8/9] image_types.bbclass: Use --force also with lz4,lzop Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 9/9] u-boot.inc: Refactor do_* steps into functions that can be overridden Steve Sakoman
8 siblings, 0 replies; 22+ messages in thread
From: Steve Sakoman @ 2024-08-14 12:02 UTC (permalink / raw)
To: openembedded-core
From: Niko Mauno <niko.mauno@vaisala.com>
The base-files recipe provides /var/tmp -> /var/volatile/tmp symlink
which is in conflict with systemd upstream tmpfiles.d/tmp.conf which
defines it as a directory (or subvolume on btrfs).
This generates following error in journal:
Jul 03 15:37:21 qemux86-64 systemd-tmpfiles[158]: "/var/tmp" already exists and is not a directory.
Mitigate the issue by defining /var/tmp as symlink corresponding to
the one created by base-files.
(From OE-Core rev: 1f1f6f45e3cfe24dfee8a09d01a5d32f3080e381)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
meta/recipes-core/systemd/systemd/00-create-volatile.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/systemd/systemd/00-create-volatile.conf b/meta/recipes-core/systemd/systemd/00-create-volatile.conf
index c4277221a2..043b2ef1d8 100644
--- a/meta/recipes-core/systemd/systemd/00-create-volatile.conf
+++ b/meta/recipes-core/systemd/systemd/00-create-volatile.conf
@@ -6,3 +6,4 @@
d /run/lock 1777 - - -
d /var/volatile/log - - - -
d /var/volatile/tmp 1777 - -
+L /var/tmp - - - - /var/volatile/tmp
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [OE-core][scarthgap 8/9] image_types.bbclass: Use --force also with lz4,lzop
2024-08-14 12:02 [OE-core][scarthgap 0/9] Patch review Steve Sakoman
` (6 preceding siblings ...)
2024-08-14 12:02 ` [OE-core][scarthgap 7/9] systemd: Mitigate /var/tmp " Steve Sakoman
@ 2024-08-14 12:02 ` Steve Sakoman
2024-08-14 12:02 ` [OE-core][scarthgap 9/9] u-boot.inc: Refactor do_* steps into functions that can be overridden Steve Sakoman
8 siblings, 0 replies; 22+ messages in thread
From: Steve Sakoman @ 2024-08-14 12:02 UTC (permalink / raw)
To: openembedded-core
From: Niko Mauno <niko.mauno@vaisala.com>
Several conversion commands already make use of 'force' option in the
compression, which enables overwriting existing files without
prompting.
Since occasionally an existing residual destination file from a
previously aborted or failed task can prevent the re-execution of the
conversion command task, by enabling the 'force' option also for lz4
and lzop compression commands we can avoid following kind of BitBake
failures with these compressors:
| DEBUG: Executing shell function do_image_cpio
| 117685 blocks
| 2 blocks
| example-image.cpio.lz4 already exists; do you want to overwrite (y/N) ? not overwritten
| Error 20 : example-image.cpio : open file error
| WARNING: exit code 20 from a shell command.
ERROR: Task (.../recipes-core/images/example-image.bb:do_image_cpio) failed with exit code '1'
(From OE-Core rev: 623ab22434909f10aaf613cd3032cc2a2c6e3ff9)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
meta/classes-recipe/image_types.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes-recipe/image_types.bbclass b/meta/classes-recipe/image_types.bbclass
index 2f948ecbf8..28afff4571 100644
--- a/meta/classes-recipe/image_types.bbclass
+++ b/meta/classes-recipe/image_types.bbclass
@@ -335,8 +335,8 @@ CONVERSION_CMD:lzma = "lzma -k -f -7 ${IMAGE_NAME}.${type}"
CONVERSION_CMD:gz = "gzip -f -9 -n -c --rsyncable ${IMAGE_NAME}.${type} > ${IMAGE_NAME}.${type}.gz"
CONVERSION_CMD:bz2 = "pbzip2 -f -k ${IMAGE_NAME}.${type}"
CONVERSION_CMD:xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_DEFAULTS} --check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}.${type} > ${IMAGE_NAME}.${type}.xz"
-CONVERSION_CMD:lz4 = "lz4 -9 -z -l ${IMAGE_NAME}.${type} ${IMAGE_NAME}.${type}.lz4"
-CONVERSION_CMD:lzo = "lzop -9 ${IMAGE_NAME}.${type}"
+CONVERSION_CMD:lz4 = "lz4 -f -9 -z -l ${IMAGE_NAME}.${type} ${IMAGE_NAME}.${type}.lz4"
+CONVERSION_CMD:lzo = "lzop -f -9 ${IMAGE_NAME}.${type}"
CONVERSION_CMD:zip = "zip ${ZIP_COMPRESSION_LEVEL} ${IMAGE_NAME}.${type}.zip ${IMAGE_NAME}.${type}"
CONVERSION_CMD:7zip = "7za a -mx=${7ZIP_COMPRESSION_LEVEL} -mm=${7ZIP_COMPRESSION_METHOD} ${IMAGE_NAME}.${type}.${7ZIP_EXTENSION} ${IMAGE_NAME}.${type}"
CONVERSION_CMD:zst = "zstd -f -k -c ${ZSTD_DEFAULTS} ${IMAGE_NAME}.${type} > ${IMAGE_NAME}.${type}.zst"
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [OE-core][scarthgap 9/9] u-boot.inc: Refactor do_* steps into functions that can be overridden
2024-08-14 12:02 [OE-core][scarthgap 0/9] Patch review Steve Sakoman
` (7 preceding siblings ...)
2024-08-14 12:02 ` [OE-core][scarthgap 8/9] image_types.bbclass: Use --force also with lz4,lzop Steve Sakoman
@ 2024-08-14 12:02 ` Steve Sakoman
8 siblings, 0 replies; 22+ messages in thread
From: Steve Sakoman @ 2024-08-14 12:02 UTC (permalink / raw)
To: openembedded-core
From: Ryan Eatmon <reatmon@ti.com>
The looping logic for handling (and not handling) UBOOT_CONFIG has led
to the various do_* functions to be large and unwieldy. In order to
modify one of the functional blocks inside of a loop (or in the else
condition) means you either have to replace the function entirely, or
append the function and undo something it did and then do what you need
for your change.
This refactor breaks out all of the inner loops and else clauses into
new functions that themselves can be overridden without needing to
worry about the bulk of the looping logic.
It should not break any existing recipes doing prepends, appends, or
overrides. None of the functional blocks were changed, just refactored
out into new functions.
Backport from master: https://git.openembedded.org/openembedded-core/commit/?id=937bcc229502fcc154cc676b4fcc93c561873def
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
meta/recipes-bsp/u-boot/u-boot-configure.inc | 36 ++-
meta/recipes-bsp/u-boot/u-boot.inc | 281 ++++++++++++-------
2 files changed, 208 insertions(+), 109 deletions(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-configure.inc b/meta/recipes-bsp/u-boot/u-boot-configure.inc
index 378d675364..a15511f8b2 100644
--- a/meta/recipes-bsp/u-boot/u-boot-configure.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-configure.inc
@@ -18,23 +18,35 @@ do_configure () {
for type in ${UBOOT_CONFIG}; do
j=$(expr $j + 1);
if [ $j -eq $i ]; then
- oe_runmake -C ${S} O=${B}/${config} ${config}
- if [ -n "${@' '.join(find_cfgs(d))}" ]; then
- merge_config.sh -m -O ${B}/${config} ${B}/${config}/.config ${@" ".join(find_cfgs(d))}
- oe_runmake -C ${S} O=${B}/${config} oldconfig
- fi
+ uboot_configure_config $config $type
fi
done
unset j
done
unset i
else
- if [ -n "${UBOOT_MACHINE}" ]; then
- oe_runmake -C ${S} O=${B} ${UBOOT_MACHINE}
- else
- oe_runmake -C ${S} O=${B} oldconfig
- fi
- merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
- cml1_do_configure
+ uboot_configure
fi
}
+
+uboot_configure_config () {
+ config=$1
+ type=$2
+
+ oe_runmake -C ${S} O=${B}/${config} ${config}
+ if [ -n "${@' '.join(find_cfgs(d))}" ]; then
+ merge_config.sh -m -O ${B}/${config} ${B}/${config}/.config ${@" ".join(find_cfgs(d))}
+ oe_runmake -C ${S} O=${B}/${config} oldconfig
+ fi
+}
+
+uboot_configure () {
+ if [ -n "${UBOOT_MACHINE}" ]; then
+ oe_runmake -C ${S} O=${B} ${UBOOT_MACHINE}
+ else
+ oe_runmake -C ${S} O=${B} oldconfig
+ fi
+ merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
+ cml1_do_configure
+}
+
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc b/meta/recipes-bsp/u-boot/u-boot.inc
index f5b43f6e36..3c01720192 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -54,40 +54,21 @@ do_compile () {
if [ -n "${UBOOT_CONFIG}" -o -n "${UBOOT_DELTA_CONFIG}" ]
then
- unset i j k
+ unset i j
for config in ${UBOOT_MACHINE}; do
i=$(expr $i + 1);
for type in ${UBOOT_CONFIG}; do
j=$(expr $j + 1);
if [ $j -eq $i ]
then
- oe_runmake -C ${S} O=${B}/${config} ${UBOOT_MAKE_TARGET}
- for binary in ${UBOOT_BINARIES}; do
- k=$(expr $k + 1);
- if [ $k -eq $i ]; then
- cp ${B}/${config}/${binary} ${B}/${config}/${UBOOT_BINARYNAME}-${type}.${UBOOT_SUFFIX}
- fi
- done
-
- # Generate the uboot-initial-env
- if [ -n "${UBOOT_INITIAL_ENV}" ]; then
- oe_runmake -C ${S} O=${B}/${config} u-boot-initial-env
- cp ${B}/${config}/u-boot-initial-env ${B}/${config}/u-boot-initial-env-${type}
- fi
-
- unset k
+ uboot_compile_config $i $config $type
fi
done
unset j
done
unset i
else
- oe_runmake -C ${S} O=${B} ${UBOOT_MAKE_TARGET}
-
- # Generate the uboot-initial-env
- if [ -n "${UBOOT_INITIAL_ENV}" ]; then
- oe_runmake -C ${S} O=${B} u-boot-initial-env
- fi
+ uboot_compile
fi
if [ -n "${UBOOT_ENV}" ] && [ "${UBOOT_ENV_SUFFIX}" = "scr" ]
@@ -96,6 +77,46 @@ do_compile () {
fi
}
+uboot_compile_config () {
+ i=$1
+ config=$2
+ type=$3
+
+ oe_runmake -C ${S} O=${B}/${config} ${UBOOT_MAKE_TARGET}
+
+ unset k
+ for binary in ${UBOOT_BINARIES}; do
+ k=$(expr $k + 1);
+ if [ $k -eq $i ]; then
+ uboot_compile_config_copy_binary $config $type $binary
+ fi
+ done
+ unset k
+
+ # Generate the uboot-initial-env
+ if [ -n "${UBOOT_INITIAL_ENV}" ]; then
+ oe_runmake -C ${S} O=${B}/${config} u-boot-initial-env
+ cp ${B}/${config}/u-boot-initial-env ${B}/${config}/u-boot-initial-env-${type}
+ fi
+}
+
+uboot_compile_config_copy_binary () {
+ config=$1
+ type=$2
+ binary=$3
+
+ cp ${B}/${config}/${binary} ${B}/${config}/${UBOOT_BINARYNAME}-${type}.${UBOOT_SUFFIX}
+}
+
+uboot_compile () {
+ oe_runmake -C ${S} O=${B} ${UBOOT_MAKE_TARGET}
+
+ # Generate the uboot-initial-env
+ if [ -n "${UBOOT_INITIAL_ENV}" ]; then
+ oe_runmake -C ${S} O=${B} u-boot-initial-env
+ fi
+}
+
do_install () {
if [ -n "${UBOOT_CONFIG}" ]
then
@@ -105,32 +126,14 @@ do_install () {
j=$(expr $j + 1);
if [ $j -eq $i ]
then
- install -D -m 644 ${B}/${config}/${UBOOT_BINARYNAME}-${type}.${UBOOT_SUFFIX} ${D}/boot/${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
- ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${D}/boot/${UBOOT_BINARY}-${type}
- ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${D}/boot/${UBOOT_BINARY}
-
- # Install the uboot-initial-env
- if [ -n "${UBOOT_INITIAL_ENV}" ]; then
- install -D -m 644 ${B}/${config}/u-boot-initial-env-${type} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
- ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}
- ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${type}
- ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}
- fi
+ uboot_install_config $config $type
fi
done
unset j
done
unset i
else
- install -D -m 644 ${B}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
- ln -sf ${UBOOT_IMAGE} ${D}/boot/${UBOOT_BINARY}
-
- # Install the uboot-initial-env
- if [ -n "${UBOOT_INITIAL_ENV}" ]; then
- install -D -m 644 ${B}/u-boot-initial-env ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR}
- ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}
- ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}
- fi
+ uboot_install
fi
if [ -n "${UBOOT_ELF}" ]
@@ -143,17 +146,14 @@ do_install () {
j=$(expr $j + 1);
if [ $j -eq $i ]
then
- install -m 644 ${B}/${config}/${UBOOT_ELF} ${D}/boot/u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX}
- ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${D}/boot/${UBOOT_BINARY}-${type}
- ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${D}/boot/${UBOOT_BINARY}
+ uboot_install_elf_config $config $type
fi
done
unset j
done
unset i
else
- install -m 644 ${B}/${UBOOT_ELF} ${D}/boot/${UBOOT_ELF_IMAGE}
- ln -sf ${UBOOT_ELF_IMAGE} ${D}/boot/${UBOOT_ELF_BINARY}
+ uboot_install_elf
fi
fi
@@ -172,17 +172,14 @@ do_install () {
j=$(expr $j + 1);
if [ $j -eq $i ]
then
- install -m 644 ${B}/${config}/${SPL_BINARY} ${D}/boot/${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX}
- ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${D}/boot/${SPL_BINARYFILE}-${type}
- ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${D}/boot/${SPL_BINARYFILE}
+ uboot_install_spl_config $config $type
fi
done
unset j
done
unset i
else
- install -m 644 ${B}/${SPL_BINARY} ${D}/boot/${SPL_IMAGE}
- ln -sf ${SPL_IMAGE} ${D}/boot/${SPL_BINARYFILE}
+ uboot_install_spl
fi
fi
@@ -198,6 +195,63 @@ do_install () {
fi
}
+uboot_install_config () {
+ config=$1
+ type=$2
+
+ install -D -m 644 ${B}/${config}/${UBOOT_BINARYNAME}-${type}.${UBOOT_SUFFIX} ${D}/boot/${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
+ ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${D}/boot/${UBOOT_BINARY}-${type}
+ ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${D}/boot/${UBOOT_BINARY}
+
+ # Install the uboot-initial-env
+ if [ -n "${UBOOT_INITIAL_ENV}" ]; then
+ install -D -m 644 ${B}/${config}/u-boot-initial-env-${type} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
+ ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}
+ ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${type}
+ ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}
+ fi
+}
+
+uboot_install () {
+ install -D -m 644 ${B}/${UBOOT_BINARY} ${D}/boot/${UBOOT_IMAGE}
+ ln -sf ${UBOOT_IMAGE} ${D}/boot/${UBOOT_BINARY}
+
+ # Install the uboot-initial-env
+ if [ -n "${UBOOT_INITIAL_ENV}" ]; then
+ install -D -m 644 ${B}/u-boot-initial-env ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR}
+ ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}-${MACHINE}
+ ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR} ${D}/${sysconfdir}/${UBOOT_INITIAL_ENV}
+ fi
+}
+
+uboot_install_elf_config () {
+ config=$1
+ type=$2
+
+ install -m 644 ${B}/${config}/${UBOOT_ELF} ${D}/boot/u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX}
+ ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${D}/boot/${UBOOT_BINARY}-${type}
+ ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${D}/boot/${UBOOT_BINARY}
+}
+
+uboot_install_elf () {
+ install -m 644 ${B}/${UBOOT_ELF} ${D}/boot/${UBOOT_ELF_IMAGE}
+ ln -sf ${UBOOT_ELF_IMAGE} ${D}/boot/${UBOOT_ELF_BINARY}
+}
+
+uboot_install_spl_config () {
+ config=$1
+ type=$2
+
+ install -m 644 ${B}/${config}/${SPL_BINARY} ${D}/boot/${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX}
+ ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${D}/boot/${SPL_BINARYFILE}-${type}
+ ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${D}/boot/${SPL_BINARYFILE}
+}
+
+uboot_install_spl () {
+ install -m 644 ${B}/${SPL_BINARY} ${D}/boot/${SPL_IMAGE}
+ ln -sf ${SPL_IMAGE} ${D}/boot/${SPL_BINARYFILE}
+}
+
PACKAGE_BEFORE_PN += "${PN}-env ${PN}-extlinux"
RPROVIDES:${PN}-env += "u-boot-default-env"
@@ -223,40 +277,14 @@ do_deploy () {
j=$(expr $j + 1);
if [ $j -eq $i ]
then
- install -D -m 644 ${B}/${config}/${UBOOT_BINARYNAME}-${type}.${UBOOT_SUFFIX} ${DEPLOYDIR}/${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
- cd ${DEPLOYDIR}
- ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${UBOOT_SYMLINK}-${type}
- ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${UBOOT_SYMLINK}
- ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${UBOOT_BINARY}-${type}
- ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${UBOOT_BINARY}
-
- # Deploy the uboot-initial-env
- if [ -n "${UBOOT_INITIAL_ENV}" ]; then
- install -D -m 644 ${B}/${config}/u-boot-initial-env-${type} ${DEPLOYDIR}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
- cd ${DEPLOYDIR}
- ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR} ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}
- ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR} ${UBOOT_INITIAL_ENV}-${type}
- fi
+ uboot_deploy_config $config $type
fi
done
unset j
done
unset i
else
- install -D -m 644 ${B}/${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
-
- cd ${DEPLOYDIR}
- rm -f ${UBOOT_BINARY} ${UBOOT_SYMLINK}
- ln -sf ${UBOOT_IMAGE} ${UBOOT_SYMLINK}
- ln -sf ${UBOOT_IMAGE} ${UBOOT_BINARY}
-
- # Deploy the uboot-initial-env
- if [ -n "${UBOOT_INITIAL_ENV}" ]; then
- install -D -m 644 ${B}/u-boot-initial-env ${DEPLOYDIR}/${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR}
- cd ${DEPLOYDIR}
- ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR} ${UBOOT_INITIAL_ENV}-${MACHINE}
- ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR} ${UBOOT_INITIAL_ENV}
- fi
+ uboot_deploy
fi
if [ -e ${WORKDIR}/fw_env.config ] ; then
@@ -276,20 +304,14 @@ do_deploy () {
j=$(expr $j + 1);
if [ $j -eq $i ]
then
- install -m 644 ${B}/${config}/${UBOOT_ELF} ${DEPLOYDIR}/u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX}
- ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${DEPLOYDIR}/${UBOOT_ELF_BINARY}-${type}
- ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${DEPLOYDIR}/${UBOOT_ELF_BINARY}
- ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${DEPLOYDIR}/${UBOOT_ELF_SYMLINK}-${type}
- ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${DEPLOYDIR}/${UBOOT_ELF_SYMLINK}
+ uboot_deploy_elf_config $config $type
fi
done
unset j
done
unset i
else
- install -m 644 ${B}/${UBOOT_ELF} ${DEPLOYDIR}/${UBOOT_ELF_IMAGE}
- ln -sf ${UBOOT_ELF_IMAGE} ${DEPLOYDIR}/${UBOOT_ELF_BINARY}
- ln -sf ${UBOOT_ELF_IMAGE} ${DEPLOYDIR}/${UBOOT_ELF_SYMLINK}
+ uboot_deploy_elf
fi
fi
@@ -304,21 +326,14 @@ do_deploy () {
j=$(expr $j + 1);
if [ $j -eq $i ]
then
- install -m 644 ${B}/${config}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX}
- rm -f ${DEPLOYDIR}/${SPL_BINARYFILE} ${DEPLOYDIR}/${SPL_SYMLINK}
- ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${DEPLOYDIR}/${SPL_BINARYFILE}-${type}
- ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${DEPLOYDIR}/${SPL_BINARYFILE}
- ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${DEPLOYDIR}/${SPL_SYMLINK}-${type}
- ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${DEPLOYDIR}/${SPL_SYMLINK}
+ uboot_deploy_spl_config $config $type
fi
done
unset j
done
unset i
else
- install -m 644 ${B}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_IMAGE}
- ln -sf ${SPL_IMAGE} ${DEPLOYDIR}/${SPL_BINARYNAME}
- ln -sf ${SPL_IMAGE} ${DEPLOYDIR}/${SPL_SYMLINK}
+ uboot_deploy_spl
fi
fi
@@ -342,4 +357,76 @@ do_deploy () {
fi
}
+uboot_deploy_config () {
+ config=$1
+ type=$2
+
+ install -D -m 644 ${B}/${config}/${UBOOT_BINARYNAME}-${type}.${UBOOT_SUFFIX} ${DEPLOYDIR}/${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX}
+ cd ${DEPLOYDIR}
+ ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${UBOOT_SYMLINK}-${type}
+ ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${UBOOT_SYMLINK}
+ ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${UBOOT_BINARY}-${type}
+ ln -sf ${UBOOT_BINARYNAME}-${type}-${PV}-${PR}.${UBOOT_SUFFIX} ${UBOOT_BINARY}
+
+ # Deploy the uboot-initial-env
+ if [ -n "${UBOOT_INITIAL_ENV}" ]; then
+ install -D -m 644 ${B}/${config}/u-boot-initial-env-${type} ${DEPLOYDIR}/${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR}
+ cd ${DEPLOYDIR}
+ ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR} ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}
+ ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${type}-${PV}-${PR} ${UBOOT_INITIAL_ENV}-${type}
+ fi
+}
+
+uboot_deploy () {
+ install -D -m 644 ${B}/${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE}
+
+ cd ${DEPLOYDIR}
+ rm -f ${UBOOT_BINARY} ${UBOOT_SYMLINK}
+ ln -sf ${UBOOT_IMAGE} ${UBOOT_SYMLINK}
+ ln -sf ${UBOOT_IMAGE} ${UBOOT_BINARY}
+
+ # Deploy the uboot-initial-env
+ if [ -n "${UBOOT_INITIAL_ENV}" ]; then
+ install -D -m 644 ${B}/u-boot-initial-env ${DEPLOYDIR}/${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR}
+ cd ${DEPLOYDIR}
+ ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR} ${UBOOT_INITIAL_ENV}-${MACHINE}
+ ln -sf ${UBOOT_INITIAL_ENV}-${MACHINE}-${PV}-${PR} ${UBOOT_INITIAL_ENV}
+ fi
+}
+
+uboot_deploy_elf_config () {
+ config=$1
+ type=$2
+
+ install -m 644 ${B}/${config}/${UBOOT_ELF} ${DEPLOYDIR}/u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX}
+ ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${DEPLOYDIR}/${UBOOT_ELF_BINARY}-${type}
+ ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${DEPLOYDIR}/${UBOOT_ELF_BINARY}
+ ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${DEPLOYDIR}/${UBOOT_ELF_SYMLINK}-${type}
+ ln -sf u-boot-${type}-${PV}-${PR}.${UBOOT_ELF_SUFFIX} ${DEPLOYDIR}/${UBOOT_ELF_SYMLINK}
+}
+
+uboot_deploy_elf () {
+ install -m 644 ${B}/${UBOOT_ELF} ${DEPLOYDIR}/${UBOOT_ELF_IMAGE}
+ ln -sf ${UBOOT_ELF_IMAGE} ${DEPLOYDIR}/${UBOOT_ELF_BINARY}
+ ln -sf ${UBOOT_ELF_IMAGE} ${DEPLOYDIR}/${UBOOT_ELF_SYMLINK}
+}
+
+uboot_deploy_spl_config () {
+ config=$1
+ type=$2
+
+ install -m 644 ${B}/${config}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX}
+ rm -f ${DEPLOYDIR}/${SPL_BINARYFILE} ${DEPLOYDIR}/${SPL_SYMLINK}
+ ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${DEPLOYDIR}/${SPL_BINARYFILE}-${type}
+ ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${DEPLOYDIR}/${SPL_BINARYFILE}
+ ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${DEPLOYDIR}/${SPL_SYMLINK}-${type}
+ ln -sf ${SPL_BINARYNAME}-${type}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX} ${DEPLOYDIR}/${SPL_SYMLINK}
+}
+
+uboot_deploy_spl () {
+ install -m 644 ${B}/${SPL_BINARY} ${DEPLOYDIR}/${SPL_IMAGE}
+ ln -sf ${SPL_IMAGE} ${DEPLOYDIR}/${SPL_BINARYNAME}
+ ln -sf ${SPL_IMAGE} ${DEPLOYDIR}/${SPL_SYMLINK}
+}
+
addtask deploy before do_build after do_compile
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread