[OE-core][kirkstone][PATCH 1/1] perl: ignore CVE-2023-47100
CVE-2023-47100 is a duplicate of CVE-2023-47038. They have the same
advertised fix commit, which has already been merged into the
perl_5.34.3 sources used in kirkstone.
Signed-off-by: Alex Stewart
---
meta/recipes-devtools/perl/perl_5.34.3.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-devtools/perl/perl_5.34.3.bb
b/meta/recipes-devtools/perl/perl_5.34.3.bb
index e8b518adc9..215990c8fa 100644
--- a/meta/recipes-devtools/perl/perl_5.34.3.bb
+++ b/meta/recipes-devtools/perl/perl_5.34.3.bb
@@ -48,6 +48,9 @@ PACKAGECONFIG[gdbm] = ",-Ui_gdbm,gdbm"
# Don't generate comments in enc2xs output files. They are not reproducible
export ENC2XS_NO_COMMENTS = "1"
+# Duplicate of CVE-2023-47038, which has already been patched as of perl_5.34.3
+CVE_CHECK_IGNORE:append = " CVE-2023-47100"
+
do_configure:prepend() {
cp -rfp ${STAGING_DATADIR_NATIVE}/perl-cross/* ${S}
}
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197942):
https://lists.openembedded.org/g/openembedded-core/message/197942
Mute This Topic: https://lists.openembedded.org/mt/105316085/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][PATCH 0/1] Ignore CVE-2023-47100
CVE-2023-47100 is an NVD 9.8 vulnerability filed against perl 5.30.0, through 5.38.2 - which includes the 5.34.3 version used in OE-core kirkstone. But the issue and reported fix are the same as CVE-2023-47038, whose fix has already been merged into the 5.34.3 source. Further, both CVEs have inaccurate configuration ranges reported on NVD. NI filed several requests to MITRE to correct the duplication weeks ago, but there hasn't been any action. I manually checked the kirkstone perl sources and confirmed that the common fix for both CVEs is in place. -47038 is already correctly-reported as 'patched' (due to the erroneous configuration string). This patchset further ignores the duplicate -47100 filing. Alex Stewart (1): perl: ignore CVE-2023-47100 meta/recipes-devtools/perl/perl_5.34.3.bb | 3 +++ 1 file changed, 3 insertions(+) -- 2.43.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197941): https://lists.openembedded.org/g/openembedded-core/message/197941 Mute This Topic: https://lists.openembedded.org/mt/105316082/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [dunfell][PATCH] opkg: Fix bad memory acces error observe in file_read_line_alloc
ACK. This is a valid bug fix backport from just after opkg_0.4.2's release.
On 1/23/24 00:28, virendra thakur wrote:
[You don't often get email from thakur.virendra1...@gmail.com. Learn why this
is important at https://aka.ms/LearnAboutSenderIdentification ]
In the case of a zero length string being returned by fgets(), the condition
checking for a trailing new line would perform a bad memory access outside
of `buf`. This might happen when line with a leading null byte is read.
Avoid this case by checking that the string has a length of at least one
byte.
Link:
https://github.com/ndmsystems/opkg/commit/8b45a3c4cab95382beea1ecdddeb2e4a9ed14aba
Signed-off-by: virendra thakur
---
...possible-bad-memory-access-in-file_r.patch | 50 +++
meta/recipes-devtools/opkg/opkg_0.4.2.bb | 1 +
2 files changed, 51 insertions(+)
create mode 100644
meta/recipes-devtools/opkg/opkg/0001-file_util.c-fix-possible-bad-memory-access-in-file_r.patch
diff --git
a/meta/recipes-devtools/opkg/opkg/0001-file_util.c-fix-possible-bad-memory-access-in-file_r.patch
b/meta/recipes-devtools/opkg/opkg/0001-file_util.c-fix-possible-bad-memory-access-in-file_r.patch
new file mode 100644
index 00..bec21e67f4
--- /dev/null
+++
b/meta/recipes-devtools/opkg/opkg/0001-file_util.c-fix-possible-bad-memory-access-in-file_r.patch
@@ -0,0 +1,50 @@
+From 8b45a3c4cab95382beea1ecdddeb2e4a9ed14aba Mon Sep 17 00:00:00 2001
+From: Jo-Philipp Wich
+Date: Wed, 1 Apr 2020 21:47:40 +0200
+Subject: [PATCH 001/104] file_util.c: fix possible bad memory access in
+ file_read_line_alloc()
+
+In the case of a zero length string being returned by fgets(), the condition
+checking for a trailing new line would perform a bad memory access outside
+of `buf`. This might happen when line with a leading null byte is read.
+
+Avoid this case by checking that the string has a length of at least one
+byte. Also change the unsigned int types to size_t to store length values
+while we're at it.
+
+Upstream-Status: Backport
[https://github.com/ndmsystems/opkg/commit/8b45a3c4cab95382beea1ecdddeb2e4a9ed14aba]
+
+Signed-off-by: Jo-Philipp Wich
+Signed-off-by: Alejandro del Castillo
+Signed-off-by: virendra thakur
+---
+ libopkg/file_util.c | 7 ++-
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+diff --git a/libopkg/file_util.c b/libopkg/file_util.c
+index fbed7b4..ee9f59d 100644
+--- a/libopkg/file_util.c
b/libopkg/file_util.c
+@@ -127,17 +127,14 @@ char *file_readlink_alloc(const char *file_name)
+ */
+ char *file_read_line_alloc(FILE * fp)
+ {
++size_t buf_len, line_size;
+ char buf[BUFSIZ];
+-unsigned int buf_len;
+ char *line = NULL;
+-unsigned int line_size = 0;
+ int got_nl = 0;
+
+-buf[0] = '\0';
+-
+ while (fgets(buf, BUFSIZ, fp)) {
+ buf_len = strlen(buf);
+-if (buf[buf_len - 1] == '\n') {
++if (buf_len > 0 && buf[buf_len - 1] == '\n') {
+ buf_len--;
+ buf[buf_len] = '\0';
+ got_nl = 1;
+--
+2.25.1
+
diff --git a/meta/recipes-devtools/opkg/opkg_0.4.2.bb
b/meta/recipes-devtools/opkg/opkg_0.4.2.bb
index 55be6547c0..3ebc27c8ee 100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.2.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.4.2.bb
@@ -16,6 +16,7 @@ SRC_URI =
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz
file://opkg.conf \
file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \
file://sourcedateepoch.patch \
+
file://0001-file_util.c-fix-possible-bad-memory-access-in-file_r.patch \
file://run-ptest \
"
--
2.25.1
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194299):
https://lists.openembedded.org/g/openembedded-core/message/194299
Mute This Topic: https://lists.openembedded.org/mt/103904427/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3 0/8] Add new packagefeed recipe class - RETRACTED
Sure. I've pushed the patchset here. https://github.com/amstewart/openembedded-core/tree/dev/packagefeed On 12/8/23 14:28, Alexander Kanavin wrote: Perhaps you can publish the final version somewhere like github so we can easily refer to it, should someone express interest in it? Alex On Fri, 8 Dec 2023 at 17:56, Alex Stewart wrote: Hopefully, the reply-to has worked here. This patchset was originally submitted by Charlie Johnston while he worked at NI, and was then adopted by me after he left. Now adjustments within NI have left me with much less bandwidth and I cannot continue to support getting this patchset upstreamed. https://lists.openembedded.org/g/openembedded-core/message/186383 So unfortunately, I'm retracting this patchset indefinitely. Thank you to everyone who has helped along the way. Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192084): https://lists.openembedded.org/g/openembedded-core/message/192084 Mute This Topic: https://lists.openembedded.org/mt/103058646/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v3 0/8] Add new packagefeed recipe class - RETRACTED
Hopefully, the reply-to has worked here. This patchset was originally submitted by Charlie Johnston while he worked at NI, and was then adopted by me after he left. Now adjustments within NI have left me with much less bandwidth and I cannot continue to support getting this patchset upstreamed. https://lists.openembedded.org/g/openembedded-core/message/186383 So unfortunately, I'm retracting this patchset indefinitely. Thank you to everyone who has helped along the way. Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192079): https://lists.openembedded.org/g/openembedded-core/message/192079 Mute This Topic: https://lists.openembedded.org/mt/103058646/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] libsndfile1: fix CVE-2022-33065
Signed-off-by: Alex Stewart
---
.../libsndfile1/cve-2022-33065.patch | 739 ++
.../libsndfile/libsndfile1_1.2.2.bb | 1 +
2 files changed, 740 insertions(+)
create mode 100644
meta/recipes-multimedia/libsndfile/libsndfile1/cve-2022-33065.patch
diff --git
a/meta/recipes-multimedia/libsndfile/libsndfile1/cve-2022-33065.patch
b/meta/recipes-multimedia/libsndfile/libsndfile1/cve-2022-33065.patch
new file mode 100644
index 00..fa4b2fc08b
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/cve-2022-33065.patch
@@ -0,0 +1,739 @@
+From c7ce5b0ebeeb58934825077d1324960aa0747718 Mon Sep 17 00:00:00 2001
+From: Alex Stewart
+Date: Tue, 10 Oct 2023 16:10:34 -0400
+Subject: [PATCH] mat4/mat5: fix int overflow in dataend calculation
+
+The clang sanitizer warns of a possible signed integer overflow when
+calculating the `dataend` value in `mat4_read_header()`.
+
+```
+src/mat4.c:323:41: runtime error: signed integer overflow: 205 * -100663296
cannot be represented in type 'int'
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/mat4.c:323:41 in
+src/mat4.c:323:48: runtime error: signed integer overflow: 838860800 * 4
cannot be represented in type 'int'
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/mat4.c:323:48 in
+```
+
+Cast the offending `rows` and `cols` ints to `sf_count_t` (the type of
+`dataend` before performing the calculation, to avoid the issue.
+
+CVE: CVE-2022-33065
+Fixes: https://github.com/libsndfile/libsndfile/issues/789
+Fixes: https://github.com/libsndfile/libsndfile/issues/833
+
+Upstream-Status: Backport [9a829113c88a51e57c1e46473e90609e4b7df151]
+
+Signed-off-by: Alex Stewart
+---
+ src/mat4.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/mat4.c b/src/mat4.c
+index 0b1b414b..575683ba 100644
+--- a/src/mat4.c
b/src/mat4.c
+@@ -320,7 +320,7 @@ mat4_read_header (SF_PRIVATE *psf)
+ psf->filelength - psf->dataoffset,
psf->sf.channels * psf->sf.frames * psf->bytewidth) ;
+ }
+ else if ((psf->filelength - psf->dataoffset) > psf->sf.channels *
psf->sf.frames * psf->bytewidth)
+- psf->dataend = psf->dataoffset + rows * cols * psf->bytewidth ;
++ psf->dataend = psf->dataoffset + (sf_count_t) rows *
(sf_count_t) cols * psf->bytewidth ;
+
+ psf->datalength = psf->filelength - psf->dataoffset - psf->dataend ;
+
+From 842303f984b2081481e74cb84a9a24ecbe3dec1a Mon Sep 17 00:00:00 2001
+From: Alex Stewart
+Date: Wed, 11 Oct 2023 16:36:02 -0400
+Subject: [PATCH] au: avoid int overflow while calculating data_end
+
+At several points in au_read_header(), we calculate the functional end
+of the data segment by adding the (int)au_fmt.dataoffset and the
+(int)au_fmt.datasize. This can overflow the implicit int_32 return value
+and cause undefined behavior.
+
+Instead, precalculate the value and assign it to a 64-bit
+(sf_count_t)data_end variable.
+
+CVE: CVE-2022-33065
+Fixes: https://github.com/libsndfile/libsndfile/issues/833
+
+Signed-off-by: Alex Stewart
+---
+ src/au.c | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/src/au.c b/src/au.c
+index 62bd691d..f68f2587 100644
+--- a/src/au.c
b/src/au.c
+@@ -291,6 +291,7 @@ static int
+ au_read_header (SF_PRIVATE *psf)
+ { AU_FMT au_fmt ;
+ int marker, dword ;
++ sf_count_t data_end ;
+
+ memset (_fmt, 0, sizeof (au_fmt)) ;
+ psf_binheader_readf (psf, "pm", 0, ) ;
+@@ -317,14 +318,15 @@ au_read_header (SF_PRIVATE *psf)
+ return SFE_AU_EMBED_BAD_LEN ;
+ } ;
+
++ data_end = (sf_count_t) au_fmt.dataoffset + (sf_count_t)
au_fmt.datasize ;
+ if (psf->fileoffset > 0)
+- { psf->filelength = au_fmt.dataoffset + au_fmt.datasize ;
++ { psf->filelength = data_end ;
+ psf_log_printf (psf, " Data Size : %d\n", au_fmt.datasize) ;
+ }
+- else if (au_fmt.datasize == -1 || au_fmt.dataoffset + au_fmt.datasize
== psf->filelength)
++ else if (au_fmt.datasize == -1 || data_end == psf->filelength)
+ psf_log_printf (psf, " Data Size : %d\n", au_fmt.datasize) ;
+- else if (au_fmt.dataoffset + au_fmt.datasize < psf->filelength)
+- { psf->filelength = au_fmt.dataoffset + au_fmt.datasize ;
++ else if (data_end < psf->filelength)
++ { psf->filelength = data_end ;
+ psf_log_printf (psf, " Data Size : %d\n", au_fmt.datasize) ;
+ }
+ else
+From 0754d3380a54e3fbdde0f684b88955c80c79f58f Mon Sep 17 00:00:00 2001
+From: Alex Stewart
+Date: Wed, 11 Oct 2023 16:46:29 -0400
+Subject: [PATCH] avr: fix int overflow in avr_read_header()
+
+Pre-cast hdr.frames to sf_count_t, to provide the calc
Re: [OE-core] [Openembedded-architecture] Security processes: YP needs
urity team, and a track of excellent security record. * Becoming a CNA (be able to assign CVEs) Needed if we want to assign CVEs to the software of the YP, like autobuilder, Toaster etc. I'm also interested in this, as the maintainer of our opkg fork. So far, I haven't had to respond to a CVE against the project, but that won't last forever. Kind regards, Marta -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187610): https://lists.openembedded.org/g/openembedded-core/message/187610 Mute This Topic: https://lists.openembedded.org/mt/101340097/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-Core][PATCH v5 1/5] bitbake.conf: add acl and xattr distro native features support
ACK this patchset, assuming the other maintainers are happy with how
we're handling the DISTO_FEATURES.
I chose not to include Piotr's opkg and opkg-utils ACL/xattr changes
into the 0.6.2 release, which I have just pushed. They've been merged
afterward, and can still be applied atop 0.6.2, and they'll be merged
into the December opkg release.
I have a branch ready to upgrade the opkg and opkg-utils recipes, but
I'd like to wait for this patchset to clear, because they will otherwise
conflict.
On 7/12/23 15:04, Piotr Łobacz via lists.openembedded.org wrote:
Include support for ACLs and extended file attributes for native
builds, by default.
Signed-off-by: Piotr Łobacz
---
meta/conf/bitbake.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9625a6fef4..8dd615 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -904,7 +904,7 @@ IMAGE_FEATURES += "${EXTRA_IMAGE_FEATURES}"
# Native distro features (will always be used for -native, even if they
# are not enabled for target)
-DISTRO_FEATURES_NATIVE ?= "x11 ipv6 xattr"
+DISTRO_FEATURES_NATIVE ?= "acl x11 ipv6 xattr"
DISTRO_FEATURES_NATIVESDK ?= "x11"
# Normally target distro features will not be applied to native builds:
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184228):
https://lists.openembedded.org/g/openembedded-core/message/184228
Mute This Topic: https://lists.openembedded.org/mt/100106217/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] SPDX 3 and OE-core CycloneDX support
Thanks for the context; I'll feed this back into our internal discussions. Looks like I just missed the general meeting for this month. I've joined the ML and I'll try to attend in the future. On 2/5/23 05:08, Joshua Watt wrote: On Fri, Feb 3, 2023 at 12:26 PM Alex Stewart wrote: Hey Josh, I have been roadmapping SBOM generation for NI's yocto distro and have a few open questions about the future of SPDX and the create-spdx bbclass. Since your name seems to be attached to both of those, I figure you might have the best insight here. Also posting to the OE-core ML so that this discussion can help other members. 1. SPDX 3 timeline. I hear that SPDX 3 is going to be a complete rewrite of the spec, with more support for modern SBOM discussion topics like VEX and more comprehensive vulnerability tracking. And it also seems to me that the timeline for its release is very behind schedule [1], but still in active development. Can you give a SWAG for how close that new spec is to completion? Are we months away or years? Our goal is to provide SPDX 3.0 with "example" SPDX 3.0 documents before the initial release. This should benefit both projects, since it means that we can give SPDX real examples of comprehensive SBoMs before they release the 3.0 spec, and also means that Yocto project SPDX output should be of high quality. SPDX 3.0 is moving along and it's getting closer to release, but I can't say exactly when the release will be. If you have serious interest in this, I would recommend joining the SPDX meetings: https://urldefense.com/v3/__https://github.com/spdx/meetings/blob/main/README.md__;!!FbZ0ZwI3Qg!ofUCTG3cuMma5YvThWEwqKVzFJ2AWeMpZT8faPH4PrT-1fujpKm0yyXwYU9fcuvDPHNI0DnNjVqJWLTVF84$ 2. If/when SPDX 3 support is released, is it to be assumed that the SPDX facilities in OE core are going to be upgraded to handle it? Yes. We should have support for generating either the current SPDX 2.2, or SPDX 3.0 3. The rest of my org is interested in CycloneDX as our common SBOM format. Have there been any discussions about supporting CDX SBOMs in OE-core? Any blockers there; or is it something that my org could author and upstream if we decide to go that route? As stated, we don't really think supporting CycloneDX is worth our effort in the project. That effort would probably be better spent making the conversion tools better. There's not really any documentation why we made this choice, I just decided to do it this way when I wrote the implementation. TBH I think both formats are technically fine, but SPDX had an edge because of the LF connection between the two projects. Gvien that there are conversion tools between them, I wasn't really concerned that choosing one format of the other would cause problems. [1] https://urldefense.com/v3/__https://github.com/spdx/spdx-spec/milestone/3__;!!FbZ0ZwI3Qg!ofUCTG3cuMma5YvThWEwqKVzFJ2AWeMpZT8faPH4PrT-1fujpKm0yyXwYU9fcuvDPHNI0DnNjVqJbtlx0Hc$ Appreciate the input, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176796): https://lists.openembedded.org/g/openembedded-core/message/176796 Mute This Topic: https://lists.openembedded.org/mt/96729387/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] SPDX 3 and OE-core CycloneDX support
On 2/5/23 08:11, Richard Purdie wrote: On Sat, 2023-02-04 at 15:47 -0600, Alex Stewart wrote: On 2/3/23 17:06, Richard Purdie wrote: On Fri, 2023-02-03 at 12:26 -0600, Alex Stewart wrote: Hey Josh, I have been roadmapping SBOM generation for NI's yocto distro and have a few open questions about the future of SPDX and the create-spdx bbclass. Since your name seems to be attached to both of those, I figure you might have the best insight here. Also posting to the OE-core ML so that this discussion can help other members. 1. SPDX 3 timeline. I hear that SPDX 3 is going to be a complete rewrite of the spec, with more support for modern SBOM discussion topics like VEX and more comprehensive vulnerability tracking. And it also seems to me that the timeline for its release is very behind schedule [1], but still in active development. Can you give a SWAG for how close that new spec is to completion? Are we months away or years? 2. If/when SPDX 3 support is released, is it to be assumed that the SPDX facilities in OE core are going to be upgraded to handle it? Assuming someone does the work, which is likely, yes. We did namespace the class in master to prepare for that. 3. The rest of my org is interested in CycloneDX as our common SBOM format. Have there been any discussions about supporting CDX SBOMs in OE-core? Any blockers there; or is it something that my org could author and upstream if we decide to go that route? At this point OpenEmbedded/Yocto Project has decided to go the SPDX route for various reasons. Are those reasons documented somewhere? Something about CDX rubs me the wrong way (besides it being named like an off-brand printer company), but I can't put my finger on what. So if there are technical reasons that it is less desirable for the OE usecase, I'd like to know about them. I think I share that same feeling but it is hard to put a finger on why. I'm not sure anything was documented but there was a discussion by the TSC when we made the decision. Some rough random thoughts: * SPDX did go the extra step of becoming an ISO standard * We (as a community) have much better contacts with the SPDX community. It is a fellow Linux Foundation project. * We already were using SPDX license identifiers so this is a natural progression/alignment. * Looking at the CDX repositories and mailing lists, the discussions and contributions do look to be from a much smaller ecosystem * SPDX are interested in engaging with us, which as Joshua mentions, does have benefits. If we run into challenges, we can likely seek help. We're actively involved with 3.0 which means we can hopefully ensure it works well for us. Both specifications do encode roughly the same information so the project alignment with SPDX and the "social" aspects likely tipped the balance. That's good context. Thanks. My understanding is that CDX has better support for embedding vulnerability (+VEX) and attestation elements into its DOM, which is something that our Aero-Def customers will be interested in. I suppose I can build workflows to add that information after converting the OE-SPDX document to CDX, but I'd like to integrate the whole thing into an OE build, if possible. I think CDX added VEX information in the last year or so and SPDX plans to do so in their 3.0. I have had the feeling it is due soon. I'm not sure I want to see two formats being added directly to the core, the better solution would likely be to translate the SPDX output into CycloneDX if/as needed. I'm concerned about the lossiness of that conversion. Based on the CDX-SPDX mapping document in the cdx2spdx tool repo [1], they seem roughly compatible. But I haven't been able to find a clean tool which converts the other direction, nor a mapping document for the SPDX->CDX pathway. You could take that different ways but it could mean people aren't finding a need to convert SPDX to CDX, meaning SPDX is working for them. From what I've seen, I think the SBOM ecosystem is too immature to say whether one is preferred over the other. It seems like most folks are just working with whatever falls out of their static dep analysis tooling, or gets handed to them by their security auditor. I haven't yet seen evidence that any of our customers have an SBOM *pipeline* such that they would need to pick a common spec; but I suspect that is coming. I don't really want to have two partially implemented SBoM mechanisms in YP/OE so I'd probably suggest any CDX code was a separate layer at this point. If there is actual missing capability, I'd be asking SPDX to resolve it :) Understood. I'll assume that we'll have to maintain our own layer, if we go that route. Cheers, Richard (copying Kate Stewart to the discussion) -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17
Re: [OE-core] SPDX 3 and OE-core CycloneDX support
On 2/3/23 17:06, Richard Purdie wrote: On Fri, 2023-02-03 at 12:26 -0600, Alex Stewart wrote: Hey Josh, I have been roadmapping SBOM generation for NI's yocto distro and have a few open questions about the future of SPDX and the create-spdx bbclass. Since your name seems to be attached to both of those, I figure you might have the best insight here. Also posting to the OE-core ML so that this discussion can help other members. 1. SPDX 3 timeline. I hear that SPDX 3 is going to be a complete rewrite of the spec, with more support for modern SBOM discussion topics like VEX and more comprehensive vulnerability tracking. And it also seems to me that the timeline for its release is very behind schedule [1], but still in active development. Can you give a SWAG for how close that new spec is to completion? Are we months away or years? 2. If/when SPDX 3 support is released, is it to be assumed that the SPDX facilities in OE core are going to be upgraded to handle it? Assuming someone does the work, which is likely, yes. We did namespace the class in master to prepare for that. 3. The rest of my org is interested in CycloneDX as our common SBOM format. Have there been any discussions about supporting CDX SBOMs in OE-core? Any blockers there; or is it something that my org could author and upstream if we decide to go that route? At this point OpenEmbedded/Yocto Project has decided to go the SPDX route for various reasons. Are those reasons documented somewhere? Something about CDX rubs me the wrong way (besides it being named like an off-brand printer company), but I can't put my finger on what. So if there are technical reasons that it is less desirable for the OE usecase, I'd like to know about them. My understanding is that CDX has better support for embedding vulnerability (+VEX) and attestation elements into its DOM, which is something that our Aero-Def customers will be interested in. I suppose I can build workflows to add that information after converting the OE-SPDX document to CDX, but I'd like to integrate the whole thing into an OE build, if possible. I'm not sure I want to see two formats being added directly to the core, the better solution would likely be to translate the SPDX output into CycloneDX if/as needed. I'm concerned about the lossiness of that conversion. Based on the CDX-SPDX mapping document in the cdx2spdx tool repo [1], they seem roughly compatible. But I haven't been able to find a clean tool which converts the other direction, nor a mapping document for the SPDX->CDX pathway. Is anyone watching this thread doing SPDX to CDX conversions as a part of their pipelines today? If so, what tools are you using and are there any hazards to that approach? [1] https://docs.google.com/spreadsheets/d/1PIiSYLJHlt8djG5OoOYniy_I-J31UMhBKQ62UUBHKVA/edit?usp=sharing I appreciate the feedback, everyone. -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176767): https://lists.openembedded.org/g/openembedded-core/message/176767 Mute This Topic: https://lists.openembedded.org/mt/96729387/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] SPDX 3 and OE-core CycloneDX support
Hey Josh, I have been roadmapping SBOM generation for NI's yocto distro and have a few open questions about the future of SPDX and the create-spdx bbclass. Since your name seems to be attached to both of those, I figure you might have the best insight here. Also posting to the OE-core ML so that this discussion can help other members. 1. SPDX 3 timeline. I hear that SPDX 3 is going to be a complete rewrite of the spec, with more support for modern SBOM discussion topics like VEX and more comprehensive vulnerability tracking. And it also seems to me that the timeline for its release is very behind schedule [1], but still in active development. Can you give a SWAG for how close that new spec is to completion? Are we months away or years? 2. If/when SPDX 3 support is released, is it to be assumed that the SPDX facilities in OE core are going to be upgraded to handle it? 3. The rest of my org is interested in CycloneDX as our common SBOM format. Have there been any discussions about supporting CDX SBOMs in OE-core? Any blockers there; or is it something that my org could author and upstream if we decide to go that route? [1] https://github.com/spdx/spdx-spec/milestone/3 Appreciate the input, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#176750): https://lists.openembedded.org/g/openembedded-core/message/176750 Mute This Topic: https://lists.openembedded.org/mt/96729387/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [oe-core][PATCH] opkg: ensure opkg uses private gpg.conf when applying keys.
ACK. We'll ingest this change naturally in the June opkg release, but it
is reasonable to pull the .patch now.
On 1/9/23 15:22, Charlie Johnston wrote:
Currently, the opkg-key utility calls gpg with --no-options,
which uses /dev/null as the configuration file. This means
any configurations in /etc/opkg/gpg/gpg.conf were being
ignored. This change applies a patch to remove the
--no-options flag.
Signed-off-by: Charlie Johnston
---
...emove-no-options-flag-from-gpg-calls.patch | 34 +++
meta/recipes-devtools/opkg/opkg_0.6.1.bb | 1 +
2 files changed, 35 insertions(+)
create mode 100644
meta/recipes-devtools/opkg/opkg/0002-opkg-key-remove-no-options-flag-from-gpg-calls.patch
diff --git
a/meta/recipes-devtools/opkg/opkg/0002-opkg-key-remove-no-options-flag-from-gpg-calls.patch
b/meta/recipes-devtools/opkg/opkg/0002-opkg-key-remove-no-options-flag-from-gpg-calls.patch
new file mode 100644
index 00..f216950002
--- /dev/null
+++
b/meta/recipes-devtools/opkg/opkg/0002-opkg-key-remove-no-options-flag-from-gpg-calls.patch
@@ -0,0 +1,34 @@
+From a658e6402382250f0164c5b47b744740e04f3611 Mon Sep 17 00:00:00 2001
+From: Charlie Johnston
+Date: Fri, 30 Dec 2022 15:21:14 -0600
+Subject: [PATCH] opkg-key: Remove --no-options flag from gpg calls.
+
+The opkg-key script was always passing the --no-options
+flag to gpg, which uses /dev/null as the options file.
+As a result, the opkg gpg.conf file was not getting
+used. This change removes that flag so that gpg.conf
+in the GPGHOMEDIR for opkg (currently /etc/opkg/gpg/)
+will be used if present.
+
+Upstream-Status: Accepted
[https://urldefense.com/v3/__https://git.yoctoproject.org/opkg/commit/?id=cee294e72d257417b5e55ef7a76a0fd15313e46b__;!!FbZ0ZwI3Qg!uX10EXcajL9EJS2NNmNl-z9VLeBT_HgjQJ4VJ50BN5lRXJeOM8sdVBZomrkIauJ3ufVPp8ogpBgNKQwCGuVlotE$
]
+Signed-off-by: Charlie Johnston
+---
+ utils/opkg-key | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/utils/opkg-key b/utils/opkg-key
+index e395a59..8645ebc 100755
+--- a/utils/opkg-key
b/utils/opkg-key
+@@ -53,7 +53,7 @@ else
+ exit 1
+ fi
+
+-GPG="$GPGCMD --no-options --homedir $GPGHOMEDIR"
++GPG="$GPGCMD --homedir $GPGHOMEDIR"
+
+ # Gpg home dir isn't created automatically when --homedir option is used
+ if [ ! -e "$GPGHOMEDIR" ]; then
+--
+2.30.2
+
diff --git a/meta/recipes-devtools/opkg/opkg_0.6.1.bb
b/meta/recipes-devtools/opkg/opkg_0.6.1.bb
index 50c9451a57..712f066f0e 100644
--- a/meta/recipes-devtools/opkg/opkg_0.6.1.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.1.bb
@@ -15,6 +15,7 @@ PE = "1"
SRC_URI =
"https://urldefense.com/v3/__http://downloads.yoctoproject.org/releases/$*7BBPN*7D/$*7BBPN*7D-$*7BPV*7D.tar.gz__;JSUlJSUl!!FbZ0ZwI3Qg!uX10EXcajL9EJS2NNmNl-z9VLeBT_HgjQJ4VJ50BN5lRXJeOM8sdVBZomrkIauJ3ufVPp8ogpBgNKQwCyEuKCuY$
\
file://opkg.conf \
file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \
+ file://0002-opkg-key-remove-no-options-flag-from-gpg-calls.patch \
file://run-ptest \
"
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175701):
https://lists.openembedded.org/g/openembedded-core/message/175701
Mute This Topic: https://lists.openembedded.org/mt/96163153/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] opkg: upgrade to version 0.6.1
Opkg 0.6.1 Changes:
- Opkg will no longer complain when trying to clean up the temporary
directory, if the directory does not exist.
- Fixed a SEGFAULT when parsing package indexes with invalid `Size` or
`Installed-Size` fields. These indexes will now produce a
comprehensible error.
- Fixed an inconsistecy in .list generation where files would sometimes
be entered with/without a trailing slash. The trailng slash should now
always be removed.
- Fixed [a bug](https://bugzilla.yoctoproject.org/show_bug.cgi?id=10461)
in package removal, where empty common directories would be left on
disk, even after all owning packages were removed.
Signed-off-by: Alex Stewart
---
meta/recipes-devtools/opkg/{opkg_0.6.0.bb => opkg_0.6.1.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/opkg/{opkg_0.6.0.bb => opkg_0.6.1.bb} (97%)
diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
b/meta/recipes-devtools/opkg/opkg_0.6.1.bb
similarity index 97%
rename from meta/recipes-devtools/opkg/opkg_0.6.0.bb
rename to meta/recipes-devtools/opkg/opkg_0.6.1.bb
index 53c7399929..50c9451a57 100644
--- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.1.bb
@@ -18,7 +18,7 @@ SRC_URI =
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz
file://run-ptest \
"
-SRC_URI[sha256sum] =
"56844722eff237daf14aa6e681436f3245213c5590ed0cda37a79df637ff3a4c"
+SRC_URI[sha256sum] =
"e87fccb575c64d3ac0559444016a2795f12125986a0da896bab97c4a1a2f1b2a"
# This needs to be before ptest inherit, otherwise all ptest files end packaged
# in libopkg package if OPKGLIBDIR == libdir, because default
--
2.38.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174369):
https://lists.openembedded.org/g/openembedded-core/message/174369
Mute This Topic: https://lists.openembedded.org/mt/95526671/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] lsof: add update-alternatives logic
Some distributions (NI LinuxRT) provide both busybox-lsof and
full-featured lsof implementations. When users install the full-featured
lsof package, the full-binary fails to replace the bbox-binary in PATH,
because `lsof` contains no update-alternatives logic.
Inherit the update-alternatives bbclass and assert that the
full-featured lsof package has higher priority than the busybox
implementation.
Co-Authored-By: Kyle Roeschley
Signed-off-by: Alex Stewart
---
meta/recipes-extended/lsof/lsof_4.96.4.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-extended/lsof/lsof_4.96.4.bb
b/meta/recipes-extended/lsof/lsof_4.96.4.bb
index bdd883d0ce..11de535a0f 100644
--- a/meta/recipes-extended/lsof/lsof_4.96.4.bb
+++ b/meta/recipes-extended/lsof/lsof_4.96.4.bb
@@ -12,6 +12,15 @@ SRCREV = "669c33a253e414feb60fbbcf2984c25dc413cd75"
S = "${WORKDIR}/git"
+
+inherit update-alternatives
+
+ALTERNATIVE_${PN} = "lsof"
+ALTERNATIVE_LINK_NAME[lsof] = "${sbindir}/lsof"
+# Make our priority higher than busybox
+ALTERNATIVE_PRIORITY = "100"
+
+
export LSOF_INCLUDE = "${STAGING_INCDIR}"
do_configure () {
--
2.38.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#174245):
https://lists.openembedded.org/g/openembedded-core/message/174245
Mute This Topic: https://lists.openembedded.org/mt/95415473/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] opkg: use a git clone, not a dynamic snapshot
NACK.
The downloads.yoctoproject.org fileserver isn't a dynamic cgit snapshot.
Those are static tarballs that I manually create every opkg release. [1]
[1] https://git.yoctoproject.org/opkg/tree/scripts/make-dist.sh
On 10/6/22 08:31, Ross Burton wrote:
opkg fetches using a cgit snapshot of a tag, which is not reproducible as
the tag could move, not reliable as a future dynamic snapshot could have
a different checksum, and a waste of CPU load as these tarballs are built
on demand.
Switch opkg to use a proper git clone of the relevant SHA.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/opkg/opkg_0.6.0.bb | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
index 4cd589cd29e..f9e5073ba5d 100644
--- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
@@ -12,13 +12,15 @@ DEPENDS = "libarchive"
PE = "1"
-SRC_URI = "https://urldefense.com/v3/__http://downloads.yoctoproject.org/releases/$*7BBPN*7D/$*7BBPN*7D-$*7BPV*7D.tar.gz__;JSUlJSUl!!FbZ0ZwI3Qg!pyuHI_PMGrZ2NigEUgUanIZNHVUAWoJRWYY0JDL6RQzMmoQPyN-WSs9wjjW7a9E1qPmn22PazWgh2nsmLQ$ \
+SRC_URI = "git://git.yoctoproject.org/opkg;protocol=https;branch=master \
file://opkg.conf \
file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \
file://run-ptest \
"
-SRC_URI[sha256sum] = "56844722eff237daf14aa6e681436f3245213c5590ed0cda37a79df637ff3a4c"
+SRCREV = "9007789c18f70bc9f315a566c589231ef0a2e6fa"
+
+S = "${WORKDIR}/git"
# This needs to be before ptest inherit, otherwise all ptest files end packaged
# in libopkg package if OPKGLIBDIR == libdir, because default
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171509):
https://lists.openembedded.org/g/openembedded-core/message/171509
Mute This Topic: https://lists.openembedded.org/mt/94157332/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: enable zstd support
Thanks for doing the research.
What was the build time on the zstd L19 compression vs. xz? Was there
still an improvement?
On 9/28/22 11:50, Etienne Cordonnier wrote:
I tested it a bit more today. I used the standard poky's local.conf
and added those lines. You can see that at zstd level 9 there is still
a significant difference in the compression ratio with xz for gcc-dbg
which is a big file. At zstd level 19, gcc-dbg is 241MB big instead of
214MB with xz (12.6% more).
PACKAGE_CLASSES = "package_ipk"
ZSTD_DEFAULTS = "-T0 -19"
PACKAGECONFIG:append:pn-opkg-native = " zstd"
OPKGBUILDCMD = "opkg-build -Z zstd -a ${ZSTD_DEFAULTS}"
Zstd at level 9:
build$ ls -lh tmp-zstd-level9/deploy/ipk/core2-64/ --sort=size | head
-n10
total 1.5G
-rw-r--r-- 3 ecordonnier ecordonnier 302M Sep 28 18:33
gcc-dbg_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 249M Sep 28 18:33
openssl-dbg_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 106M Sep 28 18:33
openssl-ptest_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 44M Sep 28 18:33
binutils-dbg_2.39-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 26M Sep 28 18:33
perl-ptest_5.36.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 23M Sep 28 18:33
gcc_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 15M Sep 28 18:32
elfutils-ptest_0.187-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 15M Sep 28 18:33
gcc-src_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 13M Sep 28 18:33
coreutils-dbg_9.1-r0_core2-64.ipk
zstd at level 19:
build$ ls -lh tmp-zstd-level19/deploy/ipk/core2-64/ --sort=size |
head -n10
total 1.1G
-rw-r--r-- 3 ecordonnier ecordonnier 241M Sep 28 18:04
gcc-dbg_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 213M Sep 28 18:03
openssl-dbg_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 36M Sep 28 17:58
binutils-dbg_2.39-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 30M Sep 28 18:00
openssl-ptest_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 22M Sep 28 17:59
perl-ptest_5.36.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 20M Sep 28 17:58
gcc_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 14M Sep 28 17:57
elfutils-ptest_0.187-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 12M Sep 28 17:58
gcc-src_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 12M Sep 28 17:57
g++_12.2.0-r0_core2-64.ipk
xz at level 9 (the default):
build$ ls -lh tmp-xz/deploy/ipk/core2-64/ --sort=size | head -n10
total 963M
-rw-r--r-- 3 ecordonnier ecordonnier 214M Sep 14 10:44
gcc-dbg_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 193M Sep 14 10:44
openssl-dbg_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 35M Sep 14 10:44
openssl-ptest_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 32M Sep 14 10:44
binutils-dbg_2.39-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 20M Sep 14 10:44
perl-ptest_5.36.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 19M Sep 14 10:44
gcc_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 13M Sep 14 10:44
elfutils-ptest_0.187-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 12M Sep 14 10:44
gcc-src_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 11M Sep 14 10:44
g++_12.2.0-r0_core2-64.ipk
On Wed, Sep 14, 2022 at 5:42 PM Khem Raj wrote:
On Wed, Sep 14, 2022 at 8:37 AM Alex Stewart
wrote:
>
> Thanks for checking.
>
> I'd be interested to know if setting a higher compression level
for zstd
> can get us to a similar compression ratio to xz. If so, then I
think it
> could be some real value to distro maintainers to be able to *tune*
> their compression.
yeah it will be interesting to say try something like level 9 but
I think times
might regress with that but it might be good to know the balance
and perhaps
suggest size mode and performance mode of zstd instead of xz
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171152):
https://lists.openembedded.org/g/openembedded-core/message/171152
Mute This Topic: https://lists.openembedded.org/mt/93654146/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: enable zstd support
Thanks for checking. I'd be interested to know if setting a higher compression level for zstd can get us to a similar compression ratio to xz. If so, then I think it could be some real value to distro maintainers to be able to *tune* their compression. That's not blocking for your new PR though. On 9/14/22 05:08, Etienne Cordonnier wrote: Also note that zstd's default compression level is 3 per default (from a 1 to 19 scale). I did not test other compression levels. On Wed, Sep 14, 2022 at 11:58 AM Etienne Cordonnier wrote: I ran a build of core-image-full-cmdline using xz and zstd, using pre-populated downloads and sstate-cache directories but with empty tmp directory. Here are the numbers: zstd: bitbake core-image-full-cmdline took 2m52.768s (real), the resulting directory tmp/deploy/ipk is 1.6GB big. xz: bitbake core-image-full-cmdline took 4m14.214s (real), the resulting directory tmp/deploy/ipk/ is 996M big So the build with xz is 47% slower (254/172) than with zstd for this "incremental build" use-case. See the 5 biggest packages, the difference in compression-ratio increases with big files: build$ ls -lh tmp-zstd/deploy/ipk/core2-64/ --sort=size | head -n5 total 1.6G -rw-r--r-- 3 ecordonnier ecordonnier 331M Sep 14 10:39 gcc-dbg_12.2.0-r0_core2-64.ipk -rw-r--r-- 3 ecordonnier ecordonnier 264M Sep 14 10:39 openssl-dbg_3.0.5-r0_core2-64.ipk -rw-r--r-- 3 ecordonnier ecordonnier 113M Sep 14 10:39 openssl-ptest_3.0.5-r0_core2-64.ipk -rw-r--r-- 3 ecordonnier ecordonnier 47M Sep 14 10:39 binutils-dbg_2.39-r0_core2-64.ipk build$ ls -lh tmp-xz/deploy/ipk/core2-64/ --sort=size | head -n5 total 963M -rw-r--r-- 3 ecordonnier ecordonnier 214M Sep 14 10:44 gcc-dbg_12.2.0-r0_core2-64.ipk -rw-r--r-- 3 ecordonnier ecordonnier 193M Sep 14 10:44 openssl-dbg_3.0.5-r0_core2-64.ipk -rw-r--r-- 3 ecordonnier ecordonnier 35M Sep 14 10:44 openssl-ptest_3.0.5-r0_core2-64.ipk -rw-r--r-- 3 ecordonnier ecordonnier 32M Sep 14 10:44 binutils-dbg_2.39-r0_core2-64.ipk ... I think for use-cases where the size of the ipk packages matters, xz is better. For use-cases where it does not matter (ipk packages not deployed), build-time matters more than compression-ratio and zstd is better. Regarding the enablement of zstd in opkg per default, I'll send a new version of the patch without this line. My thinking for enabling zstd per default in opkg was that zstd is already enabled per default in libarchive's PACKAGECONFIG, and disabling zstd in opkg's PACKAGECONFIG removes only a few lines of code from opkg (opkg uses libarchive for doing the actual compression/decompression). On Tue, Sep 13, 2022 at 11:57 PM Alex Stewart wrote: On 9/13/22 15:20, Alex Feinman wrote: > I do have some numbers. When I was selling this change internally, I > did a comparison on our internal build. > Combined write IPK times (Σ t do_package_write_ipk) > xz 162m 35s > gz 52m 13s > zstd 33m 49s > Compression rate for zstd was closer to xz than to gz but not as good > as xz. For systems that have to cache packages on the device with > limited storage xz might be a better option, but for the bulk of > projects zstd is the best choice > Additionally, zstd offers much faster decompression than xz so the > rootfs build step that includes unpacking all of the ipks, takes 3m > 58s with xz and 2m 44s with zstd. > One other thing of note - if your build includes debug packages, some > may be quite large. E.g. one of our components produces a 2.2 GB debug > package (uncompressed). On large files xz requires a disproportionally > large amount of time resulting in 15 minutes needed to simply write > ipk for the abovementioned packages, whereas zstd took about 45 sec. > For frequent tasks like bitbaking a single package this translates in > a lot of saved time. Those are certainly compelling performance improvements. Assuming that the final data-segment size is within 5%-ish of xz, then I would agree with the rest of the thread that it should probably be the contemporary default. And if we make it the default compressor for OE IPKs, then obviously my criticism in the original PR is satisfied. > Bottom line - I think making xz a default package compressor was not > entirely thought through. gzip or zstd is what the default should be. ZStandard support was only added to
Re: [OE-core] [PATCH v2] opkg: add option for zstd support
ACK from me.
On 9/14/22 04:59, Etienne Cordonnier via lists.openembedded.org wrote:
This allows the use of zstd for opkg packages by using OPKGBUILDCMD:
OPKGBUILDCMD = "opkg-build -Z zstd"
Signed-off-by: Alex Feinman
Signed-off-by: Etienne Cordonnier
---
meta/recipes-devtools/opkg/opkg_0.6.0.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
index 7b351e8123..4cd589cd29 100644
--- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
@@ -39,6 +39,7 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl openssl"
PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
+PACKAGECONFIG[zstd] = "--enable-zstd,--disable-zstd,zstd"
PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
EXTRA_OECONF:class-native = "--localstatedir=/${@os.path.relpath('${localstatedir}', '${STAGING_DIR_NATIVE}')} --sysconfdir=/${@os.path.relpath('${sysconfdir}', '${STAGING_DIR_NATIVE}')}"
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170663):
https://lists.openembedded.org/g/openembedded-core/message/170663
Mute This Topic: https://lists.openembedded.org/mt/93674358/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: enable zstd support
On 9/13/22 15:20, Alex Feinman wrote:
I do have some numbers. When I was selling this change internally, I
did a comparison on our internal build.
Combined write IPK times (Σ t do_package_write_ipk)
xz 162m 35s
gz 52m 13s
zstd 33m 49s
Compression rate for zstd was closer to xz than to gz but not as good
as xz. For systems that have to cache packages on the device with
limited storage xz might be a better option, but for the bulk of
projects zstd is the best choice
Additionally, zstd offers much faster decompression than xz so the
rootfs build step that includes unpacking all of the ipks, takes 3m
58s with xz and 2m 44s with zstd.
One other thing of note - if your build includes debug packages, some
may be quite large. E.g. one of our components produces a 2.2 GB debug
package (uncompressed). On large files xz requires a disproportionally
large amount of time resulting in 15 minutes needed to simply write
ipk for the abovementioned packages, whereas zstd took about 45 sec.
For frequent tasks like bitbaking a single package this translates in
a lot of saved time.
Those are certainly compelling performance improvements. Assuming that
the final data-segment size is within 5%-ish of xz, then I would agree
with the rest of the thread that it should probably be the contemporary
default.
And if we make it the default compressor for OE IPKs, then obviously my
criticism in the original PR is satisfied.
Bottom line - I think making xz a default package compressor was not
entirely thought through. gzip or zstd is what the default should be.
ZStandard support was only added to opkg last September [1]. Before
that, xz was the new hotness that replaced gzip. :)
[1]
https://git.yoctoproject.org/opkg/commit/?id=5dead419e94bce2e6b743ad786c1daec0e1aa294
One final note: I could not find a reasonable explanation for why
opkg-tools require code changes to support a different compressor. BSD
tar and GNU tar both can easily accept compressors that they have no
idea about (via -I option) because all of them provide a unified
command line interface for use in pipes. If this were done similar to
tar, we could have used any compressor we wanted, including the
multithreaded versions (zstdmt)
Well, presumably IPK creation tools can only support the matrix of
compression algorithms which your opkg binary can decompress. I suppose
someone could try to implement a plugable compression module system for
opkg. But given that nearly everyone uses opkg in an embedded context,
I'm not sure it would get much use.
On Tue, Sep 13, 2022 at 12:43 PM Khem Raj wrote:
On Tue, Sep 13, 2022 at 12:19 PM Alex Stewart
wrote:
>
> ACK from me - apart from enabling zstd by default.
>
> On 9/13/22 07:37, Etienne Cordonnier via lists.openembedded.org
<https://urldefense.com/v3/__http://lists.openembedded.org__;!!FbZ0ZwI3Qg!u0KgIth5yNSO1tok49C5_xo0QPHIFLa4kZBl3vVZwB-2Ui1uYBW7nt85fKXXM_VAHZ2LdFx_bxrNjvo$>
wrote:
> > This allows the use of zstd for opkg packages by using
OPKGBUILDCMD:
> > OPKGBUILDCMD = "opkg-build -Z zstd"
> >
> > Signed-off-by: Alex Feinman
> > Signed-off-by: Etienne Cordonnier
> > ---
> > meta/recipes-devtools/opkg/opkg_0.6.0.bb
<https://urldefense.com/v3/__http://opkg_0.6.0.bb__;!!FbZ0ZwI3Qg!u0KgIth5yNSO1tok49C5_xo0QPHIFLa4kZBl3vVZwB-2Ui1uYBW7nt85fKXXM_VAHZ2LdFx_-65pBFo$>
| 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
<https://urldefense.com/v3/__http://opkg_0.6.0.bb__;!!FbZ0ZwI3Qg!u0KgIth5yNSO1tok49C5_xo0QPHIFLa4kZBl3vVZwB-2Ui1uYBW7nt85fKXXM_VAHZ2LdFx_-65pBFo$>
b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
<https://urldefense.com/v3/__http://opkg_0.6.0.bb__;!!FbZ0ZwI3Qg!u0KgIth5yNSO1tok49C5_xo0QPHIFLa4kZBl3vVZwB-2Ui1uYBW7nt85fKXXM_VAHZ2LdFx_-65pBFo$>
> > index 7b351e8123..e38d9d6f3f 100644
> > --- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
<https://urldefense.com/v3/__http://opkg_0.6.0.bb__;!!FbZ0ZwI3Qg!u0KgIth5yNSO1tok49C5_xo0QPHIFLa4kZBl3vVZwB-2Ui1uYBW7nt85fKXXM_VAHZ2LdFx_-65pBFo$>
> > +++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
<https://urldefense.com/v3/__http://opkg_0.6.0.bb__;!!FbZ0ZwI3Qg!u0KgIth5yNSO1tok49C5_xo0QPHIFLa4kZBl3vVZwB-2Ui1uYBW7nt85fKXXM_VAHZ2LdFx_-65pBFo$>
> > @@ -30,7 +30,7 @@ inherit autotools pkgconfig ptest
> > target_localstatedir := "${localstatedir}"
> > OPKGLIBDIR ??= "${target_localstatedir}/lib"
> >
> > -PACKAGECONFIG ??= "libsolv"
> > +PACKAGECONFIG ??= "libsolv zstd"
>
> Building in zstd support by default is a little suspect to me.
>
> Unless I'm
Re: [OE-core] [PATCH] opkg: enable zstd support
ACK from me - apart from enabling zstd by default.
On 9/13/22 07:37, Etienne Cordonnier via lists.openembedded.org wrote:
This allows the use of zstd for opkg packages by using OPKGBUILDCMD:
OPKGBUILDCMD = "opkg-build -Z zstd"
Signed-off-by: Alex Feinman
Signed-off-by: Etienne Cordonnier
---
meta/recipes-devtools/opkg/opkg_0.6.0.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
index 7b351e8123..e38d9d6f3f 100644
--- a/meta/recipes-devtools/opkg/opkg_0.6.0.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
@@ -30,7 +30,7 @@ inherit autotools pkgconfig ptest
target_localstatedir := "${localstatedir}"
OPKGLIBDIR ??= "${target_localstatedir}/lib"
-PACKAGECONFIG ??= "libsolv"
+PACKAGECONFIG ??= "libsolv zstd"
Building in zstd support by default is a little suspect to me.
Unless I'm mistaken, OE-core will only build xz-compressed IPKs by
default. So zstd support would be unnecessary for a distro integrator
who just uses upstream OE-core.
For distros which use zstd compression in their packages, I think it
would be more appropriate to overwrite the opkg PACKAGECONFIG in a
.bbappend.
Is there something I'm not considering here?
PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
gnupg gpgme libgpg-error,\
@@ -39,6 +39,7 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl openssl"
PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
+PACKAGECONFIG[zstd] = "--enable-zstd,--disable-zstd,zstd"
PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
EXTRA_OECONF:class-native = "--localstatedir=/${@os.path.relpath('${localstatedir}', '${STAGING_DIR_NATIVE}')} --sysconfdir=/${@os.path.relpath('${sysconfdir}', '${STAGING_DIR_NATIVE}')}"
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#170608):
https://lists.openembedded.org/g/openembedded-core/message/170608
Mute This Topic: https://lists.openembedded.org/mt/93654146/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] maintainers: update opkg maintainer
Alex Stewart assumed maintainership of the yocto project's opkg fork, and opkg recipes, from Alejandro Del Castilo back in Q1 of 2020. Update maintainership of the opkg recipes. Signed-off-by: Alex Stewart --- meta/conf/distro/include/maintainers.inc | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index c0c38dfc165f6a7e9b465a49f57c7cbe928974bb..98e18a1e3469cdecd88b6e09a4676707fa212d00 100644 --- a/meta/conf/distro/include/maintainers.inc +++ b/meta/conf/distro/include/maintainers.inc @@ -544,10 +544,10 @@ RECIPE_MAINTAINER:pn-ofono = "Ross Burton " RECIPE_MAINTAINER:pn-opensbi = "Alistair Francis " RECIPE_MAINTAINER:pn-openssh = "Unassigned " RECIPE_MAINTAINER:pn-openssl = "Alexander Kanavin " -RECIPE_MAINTAINER:pn-opkg = "Alejandro del Castillo " -RECIPE_MAINTAINER:pn-opkg-arch-config = "Alejandro del Castillo " -RECIPE_MAINTAINER:pn-opkg-keyrings = "Alejandro del Castillo " -RECIPE_MAINTAINER:pn-opkg-utils = "Alejandro del Castillo " +RECIPE_MAINTAINER:pn-opkg = "Alex Stewart " +RECIPE_MAINTAINER:pn-opkg-arch-config = "Alex Stewart " +RECIPE_MAINTAINER:pn-opkg-keyrings = "Alex Stewart " +RECIPE_MAINTAINER:pn-opkg-utils = "Alex Stewart " RECIPE_MAINTAINER:pn-orc = "Anuj Mittal " RECIPE_MAINTAINER:pn-os-release = "Ross Burton " RECIPE_MAINTAINER:pn-ovmf = "Ricardo Neri " -- 2.36.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#169830): https://lists.openembedded.org/g/openembedded-core/message/169830 Mute This Topic: https://lists.openembedded.org/mt/93242538/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2] opkg: upgrade to version 0.6.0
Release Notes for 0.6.0:
http://downloads.yoctoproject.org/releases/opkg/opkg-0.6.0.release-notes
Signed-off-by: Alex Stewart
---
meta/recipes-devtools/opkg/{opkg_0.5.0.bb => opkg_0.6.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/opkg/{opkg_0.5.0.bb => opkg_0.6.0.bb} (96%)
diff --git a/meta/recipes-devtools/opkg/opkg_0.5.0.bb
b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
similarity index 96%
rename from meta/recipes-devtools/opkg/opkg_0.5.0.bb
rename to meta/recipes-devtools/opkg/opkg_0.6.0.bb
index
e91d7250bc9f7fde73395335f008108578515b77..7b351e81231df48b2c493542a00d95911606248f
100644
--- a/meta/recipes-devtools/opkg/opkg_0.5.0.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
@@ -18,7 +18,7 @@ SRC_URI =
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz
file://run-ptest \
"
-SRC_URI[sha256sum] =
"559c3e1b893abaa1dd473ce3a9a5f7dd3f60ceb6cd14caaef76ddf0f7721ad1c"
+SRC_URI[sha256sum] =
"56844722eff237daf14aa6e681436f3245213c5590ed0cda37a79df637ff3a4c"
# This needs to be before ptest inherit, otherwise all ptest files end packaged
# in libopkg package if OPKGLIBDIR == libdir, because default
--
2.36.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#166528):
https://lists.openembedded.org/g/openembedded-core/message/166528
Mute This Topic: https://lists.openembedded.org/mt/91529965/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: upgrade to version 0.6.0
I'm not sure I'm on-board with embedding markdown into the commit. But I can definitely link to the release notes from within the commit body. Patch V2 incoming. On 6/3/22 15:52, Khem Raj wrote: thanks may be add this info into commit msg too. -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#166527): https://lists.openembedded.org/g/openembedded-core/message/166527 Mute This Topic: https://lists.openembedded.org/mt/91528903/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: upgrade to version 0.6.0
Here are the release notes from 0.5.0 -> 0.6.0.
http://downloads.yoctoproject.org/releases/opkg/opkg-0.6.0.release-notes
```
Release Notes for opkg-0.6.0
### Changed
- When using package signature verification, the signature file is now
only downloaded when (a) it is not present in the local cache or (b) the
package file must be downloaded again. This makes signature verification
more reliable in cases where the connection to the package feed is
unreliable, or stored on a removable device that is not always connected.
- Package `pre-depends` are now recorded in the opkg `status` file.
- Package `pre-depends` are now considered when removing packages. Opkg
will now (correctly) fail, when the user asks to remove a package which
is a pre-depends of another installed package.
- libsolv will now return a solver error if the user asks to install a
package which does not exist in the feeds.
- The `opkg search` command now prints a newline character at the end of
its output when the search path cannot be found - which looks a little
nicer when using opkg interactively.
```
I don't expect these changes to directly impact the normal OE build
workflows. But they do resolve some corner-cases that yocto community
members have brought up in the previous 6 months.
On 6/3/22 15:30, Khem Raj wrote:
What major changes does this change bring
On Fri, Jun 3, 2022 at 1:04 PM Alex Stewart wrote:
Signed-off-by: Alex Stewart
---
meta/recipes-devtools/opkg/{opkg_0.5.0.bb
<https://urldefense.com/v3/__http://opkg_0.5.0.bb__;!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrkyGRaxSW$>
=> opkg_0.6.0.bb
<https://urldefense.com/v3/__http://opkg_0.6.0.bb__;!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrk519KcS6$>}
| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/opkg/{opkg_0.5.0.bb
<https://urldefense.com/v3/__http://opkg_0.5.0.bb__;!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrkyGRaxSW$>
=> opkg_0.6.0.bb
<https://urldefense.com/v3/__http://opkg_0.6.0.bb__;!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrk519KcS6$>}
(96%)
diff --git a/meta/recipes-devtools/opkg/opkg_0.5.0.bb
<https://urldefense.com/v3/__http://opkg_0.5.0.bb__;!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrkyGRaxSW$>
b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
<https://urldefense.com/v3/__http://opkg_0.6.0.bb__;!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrk519KcS6$>
similarity index 96%
rename from meta/recipes-devtools/opkg/opkg_0.5.0.bb
<https://urldefense.com/v3/__http://opkg_0.5.0.bb__;!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrkyGRaxSW$>
rename to meta/recipes-devtools/opkg/opkg_0.6.0.bb
<https://urldefense.com/v3/__http://opkg_0.6.0.bb__;!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrk519KcS6$>
index
e91d7250bc9f7fde73395335f008108578515b77..7b351e81231df48b2c493542a00d95911606248f
100644
--- a/meta/recipes-devtools/opkg/opkg_0.5.0.bb
<https://urldefense.com/v3/__http://opkg_0.5.0.bb__;!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrkyGRaxSW$>
+++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
<https://urldefense.com/v3/__http://opkg_0.6.0.bb__;!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrk519KcS6$>
@@ -18,7 +18,7 @@ SRC_URI =
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz
<https://urldefense.com/v3/__http://downloads.yoctoproject.org/releases/$*7BBPN*7D/$*7BBPN*7D-$*7BPV*7D.tar.gz__;JSUlJSUl!!FbZ0ZwI3Qg!t7LQ5Tn2xfZcGCBb9Lo82Js_VL1kRRFZT1SGzcnDNu6rwrB6gpBuMnECUpqAP96zc8Kg8tRrkxvKubIz$>
file://run-ptest \
"
-SRC_URI[sha256sum] =
"559c3e1b893abaa1dd473ce3a9a5f7dd3f60ceb6cd14caaef76ddf0f7721ad1c"
+SRC_URI[sha256sum] =
"56844722eff237daf14aa6e681436f3245213c5590ed0cda37a79df637ff3a4c"
# This needs to be before ptest inherit, otherwise all ptest
files end packaged
# in libopkg package if OPKGLIBDIR == libdir, because default
--
2.36.1
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#166525):
https://lists.openembedded.org/g/openembedded-core/message/166525
Mute This Topic: https://lists.openembedded.org/mt/91528903/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] opkg: upgrade to version 0.6.0
Signed-off-by: Alex Stewart
---
meta/recipes-devtools/opkg/{opkg_0.5.0.bb => opkg_0.6.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/opkg/{opkg_0.5.0.bb => opkg_0.6.0.bb} (96%)
diff --git a/meta/recipes-devtools/opkg/opkg_0.5.0.bb
b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
similarity index 96%
rename from meta/recipes-devtools/opkg/opkg_0.5.0.bb
rename to meta/recipes-devtools/opkg/opkg_0.6.0.bb
index
e91d7250bc9f7fde73395335f008108578515b77..7b351e81231df48b2c493542a00d95911606248f
100644
--- a/meta/recipes-devtools/opkg/opkg_0.5.0.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.0.bb
@@ -18,7 +18,7 @@ SRC_URI =
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz
file://run-ptest \
"
-SRC_URI[sha256sum] =
"559c3e1b893abaa1dd473ce3a9a5f7dd3f60ceb6cd14caaef76ddf0f7721ad1c"
+SRC_URI[sha256sum] =
"56844722eff237daf14aa6e681436f3245213c5590ed0cda37a79df637ff3a4c"
# This needs to be before ptest inherit, otherwise all ptest files end packaged
# in libopkg package if OPKGLIBDIR == libdir, because default
--
2.36.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#166522):
https://lists.openembedded.org/g/openembedded-core/message/166522
Mute This Topic: https://lists.openembedded.org/mt/91528903/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] sudo: add /etc/sudoers to sudo-lib conffiles
When OE-core commit 788c95c3bb8ede0d3d6a8f125743ac47c0b3f00e created the
`sudo-lib` subpackage, /etc/sudoers was moved from `sudo` to `sudo-lib`.
The commit didn't update the `CONFFILES:${PN}` assignment in sudo.inc,
however. So the `sudo` base package continued to advertise conffile
ownership of /etc/sudoers, though it did not contain it.
Move the CONFFILES assignment to the sudo.bb file, since it is
packaging-related. Change the package owner to the `sudo-lib`
subpackage, since it is the rightful file-owner.
Signed-off-by: Alex Stewart
---
meta/recipes-extended/sudo/sudo.inc | 2 --
meta/recipes-extended/sudo/sudo_1.9.9.bb | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/sudo/sudo.inc
b/meta/recipes-extended/sudo/sudo.inc
index
05d030c2e9f176d63f3f5c5d44321db9729b7983..8947c46129f53e819f62ca6a27fba238babce88f
100644
--- a/meta/recipes-extended/sudo/sudo.inc
+++ b/meta/recipes-extended/sudo/sudo.inc
@@ -24,8 +24,6 @@ PACKAGECONFIG ??= ""
PACKAGECONFIG[zlib] = "--enable-zlib,--disable-zlib,zlib"
PACKAGECONFIG[pam-wheel] = ",,,pam-plugin-wheel"
-CONFFILES:${PN} = "${sysconfdir}/sudoers"
-
EXTRA_OECONF = "--with-editor=${base_bindir}/vi --with-env-editor"
EXTRA_OECONF:append:libc-musl = " --disable-hardening "
diff --git a/meta/recipes-extended/sudo/sudo_1.9.9.bb
b/meta/recipes-extended/sudo/sudo_1.9.9.bb
index
f1c0339bb3be7fd48798ceb65a0dbcb0f2da63ea..d7d71bb3643ed94f5e4a5d2a2d9f4d2ff68a8f70
100644
--- a/meta/recipes-extended/sudo/sudo_1.9.9.bb
+++ b/meta/recipes-extended/sudo/sudo_1.9.9.bb
@@ -48,6 +48,8 @@ do_install:append () {
FILES:${PN}-dev += "${libdir}/${BPN}/lib*${SOLIBSDEV} ${libdir}/${BPN}/*.la \
${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la"
+CONFFILES:${PN}-lib = "${sysconfdir}/sudoers"
+
SUDO_PACKAGES = "${PN}-sudo\
${PN}-lib"
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162231):
https://lists.openembedded.org/g/openembedded-core/message/162231
Mute This Topic: https://lists.openembedded.org/mt/89330256/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] The state of DKMS in the Yocto community
Converging threads. Thanks all for the feedback. It sounds like there's no appetite for a DKMS recipe, and I agree with the rationale for rejection. I'll motion to have NI's DKMS recipe migrated to our meta-nilrt layer and independently maintained until such a time as we can deprecate it. Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159694): https://lists.openembedded.org/g/openembedded-core/message/159694 Mute This Topic: https://lists.openembedded.org/mt/87645999/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] The state of DKMS in the Yocto community
On 12/11/21 09:24, Bruce Ashfield wrote: On Fri, Dec 10, 2021 at 3:58 PM Alex Stewart wrote: Hey List, I'm trying to work out the mysterious state of DKMS in OE-Core. Our (NI) OE distributions rely heavily on DKMS to (un)install our ecosystem of kernel drivers at runtime across our product lines. To facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017, which we have carried out-of-stream since. We tried to upstream it, and the patched rev'ed a couple of times [2]; but it seems to have never made it into a yocto release. Though some other recipes mention DKMS passingly, I don't see anywhere that OE-Core officially supports it. Nor does my googling reveal anyone else who uses DKMS. I find that a little hard to believe, though I understand that it's probably relatively rare in the embedded space. @all So does anyone else on the list use DKMS in their yocto distribution? Are you maintaining a DKMS recipe out-of-stream as well? @maintainers If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and submitted it again to OE-Core, would you accept it? If not, we will move it to our own meta layer and accept that we are unique in this regard. I used to have a DKMS recipe myself (at my previous employer), but never submitted it, because generally speaking, there are better ways to do things in OE. DKMS tends to avoid proper cross compilation (which of course we already do), or is often used to distribute proprietary code (which we don't want to encourage), or is avoiding the need to upstream the module code (which we also don't want to encourage). It also only tends to be used on a subset of the architectures that have enough memory/cpu to build on target, so by definition it is a bit more niche. Yeah; I agree. In our case, we have several dozen drivers split across many product teams and largely distributing internally-controlled source. At this stage, it isn't feasible for us to build them all within OE - which is unfortunate. Many of those drivers are also required to support both our OE distribution, as well as a small matrix of supported generic Linux desktop OSes. So having them manage their own DKMS packages reduces the surface area for packaging errors. I don't expect that either of those considerations is common in the OE community. We of course already have the ability to build modules on the target (we have a test case in core that does just that), so what is in core can support what DKMS needs to build on target. I'm not sure which test case you're referencing, do you have a link or could you expand on what you mean? I don't see this as something that makes sense in oe-core (but maybe I'm not fully understanding the case, and where the current support is failing), but could of course be contributed to another layer. That's fair. Our use case is motivated more by an organizational failure than a failure of the OE tooling. @Khem You're maintaining the meta-oe layer; correct? Do you have any interest in a DKMS recipe? Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159618): https://lists.openembedded.org/g/openembedded-core/message/159618 Mute This Topic: https://lists.openembedded.org/mt/87645999/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] The state of DKMS in the Yocto community
Hey List, I'm trying to work out the mysterious state of DKMS in OE-Core. Our (NI) OE distributions rely heavily on DKMS to (un)install our ecosystem of kernel drivers at runtime across our product lines. To facilitate that, we authored a dkms_2.4.0.bb recipe [1] back in 2017, which we have carried out-of-stream since. We tried to upstream it, and the patched rev'ed a couple of times [2]; but it seems to have never made it into a yocto release. Though some other recipes mention DKMS passingly, I don't see anywhere that OE-Core officially supports it. Nor does my googling reveal anyone else who uses DKMS. I find that a little hard to believe, though I understand that it's probably relatively rare in the embedded space. @all So does anyone else on the list use DKMS in their yocto distribution? Are you maintaining a DKMS recipe out-of-stream as well? @maintainers If NI upgraded our DKMS recipe to a more recent version than 2.4.0 and submitted it again to OE-Core, would you accept it? If not, we will move it to our own meta layer and accept that we are unique in this regard. [1] https://github.com/ni/openembedded-core/commit/5789a27b68d95f3840bb8c4cb0d7b28d538c9a50 [2] https://lists.openembedded.org/g/openembedded-core/message/100680 Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159558): https://lists.openembedded.org/g/openembedded-core/message/159558 Mute This Topic: https://lists.openembedded.org/mt/87645999/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg-utils: upgrade 0.4.5 -> 0.5.0
Patch looks good to me! ACK all. Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159268): https://lists.openembedded.org/g/openembedded-core/message/159268 Mute This Topic: https://lists.openembedded.org/mt/87541534/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: upgrade 0.4.5 -> 0.5.0
You beat me to posting my own recipe upgrade commit. :)
Toward the bottom of the opkg_*.bb recipe file is a
`package_qa_check_openssl_deprecation` function which I added in the
0.4.5 release to warn BB users when they are building opkg with the
openssl options. Could you amend your patchset to remove that function
in its entirety, since it is no longer needed.
On 12/6/21 18:05, zhengruoqin wrote:
Remove unsupported openssl and option --disable-pathfinder
Signed-off-by: Zheng Ruoqin
---
meta/recipes-devtools/opkg/{opkg_0.4.5.bb => opkg_0.5.0.bb} | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
rename meta/recipes-devtools/opkg/{opkg_0.4.5.bb => opkg_0.5.0.bb} (92%)
diff --git a/meta/recipes-devtools/opkg/opkg_0.4.5.bb
b/meta/recipes-devtools/opkg/opkg_0.5.0.bb
similarity index 92%
rename from meta/recipes-devtools/opkg/opkg_0.4.5.bb
rename to meta/recipes-devtools/opkg/opkg_0.5.0.bb
index 1fe6ed5ecb..bc2ee9728b 100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.5.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.5.0.bb
@@ -18,8 +18,7 @@ SRC_URI =
"https://urldefense.com/v3/__http://downloads.yoctoproject.org/releases/$*7BBPN*7D/$*7BBPN*7D-$*7BPV*7D.tar.gz__;JSUlJSUl!!FbZ0ZwI3Qg!7tN48q7yAANgWzzpMBAysrcbhsbWEdwp0sXfb2Hl7bFTyNxbtdOuRQFN01Y06ns$
file://run-ptest \
"
-SRC_URI[md5sum] = "5dc41ad37d88803b5e0f456a9c5a0811"
-SRC_URI[sha256sum] =
"a1214a75fa34fb9228db8da47308e0e711b1c93fd8938cf164c10fd28eb50f1e"
+SRC_URI[sha256sum] =
"559c3e1b893abaa1dd473ce3a9a5f7dd3f60ceb6cd14caaef76ddf0f7721ad1c"
# This needs to be before ptest inherit, otherwise all ptest files end packaged
# in libopkg package if OPKGLIBDIR == libdir, because default
@@ -39,11 +38,9 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
"
PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl openssl"
-PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
-EXTRA_OECONF += " --disable-pathfinder"
EXTRA_OECONF:class-native =
"--localstatedir=/${@os.path.relpath('${localstatedir}', '${STAGING_DIR_NATIVE}')}
--sysconfdir=/${@os.path.relpath('${sysconfdir}', '${STAGING_DIR_NATIVE}')}"
do_install:append () {
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159267):
https://lists.openembedded.org/g/openembedded-core/message/159267
Mute This Topic: https://lists.openembedded.org/mt/87541521/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: Fix poor operator combination choice
On 11/4/21 09:35, Mikko Rapeli wrote:
On Thu, Nov 04, 2021 at 02:02:57PM +, Richard Purdie wrote:
Combining :append with += rarely makes sense. Improve it to use the standard
format (and tweak the implied spacing).
Maybe I'm silly but I find :append with += safer to do than manually remembring
to add the space character.
I tend to agree; hence why I wrote it that way in the original patch.
But I'm not going to defend the practice in this case, so ACK from me
either way.
I'm intending to drop this recipe warning after the opkg_0.5.0 release
in December. So the recipe-as-written will only exist in the mainline
for another few months.
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/opkg/opkg_0.4.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/opkg/opkg_0.4.5.bb
b/meta/recipes-devtools/opkg/opkg_0.4.5.bb
index 2760fc58786..8af047a51ff 100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.5.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.4.5.bb
@@ -60,7 +60,7 @@ do_install_ptest () {
sed -i -e '/@PYTHONPATH=. $(PYTHON) $^/a\\t@if [ "$$?" != "0" ];then echo
"FAIL:"$^;else echo "PASS:"$^;fi' ${D}${PTEST_PATH}/tests/Makefile
}
-WARN_QA:append += "openssl-deprecation"
+WARN_QA:append = " openssl-deprecation"
QAPKGTEST[openssl-deprecation] = "package_qa_check_openssl_deprecation"
def package_qa_check_openssl_deprecation (package, d, messages):
sane = True
--
2.32.0
Thanks,
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157877):
https://lists.openembedded.org/g/openembedded-core/message/157877
Mute This Topic: https://lists.openembedded.org/mt/86816265/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On 7/26/21 8:48 AM, Rasmus Villemoes wrote: Looking at log.do_rootfs, it seems that opkg gets invoked in exactly the same way with and without the RRECOMMENDS in play: With RRECOMMENDS, where the build succeeds: NOTE: Installing the following packages: [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] NOTE: [...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-ignore-recommends busybox-syslog --add-ignore-recommends busybox-udhcpc --add-ignore-recommends kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] And no further mention of kernel-module-abcd. Without the RRECOMMENDS: NOTE: Installing the following packages: [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] NOTE: [...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-ignore-recommends busybox-syslog --add-ignore-recommends busybox-udhcpc --add-ignore-recommends kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...] ERROR: Unable to install packages. Command '[...]/recipe-sysroot-native/usr/bin/opkg --volatile-cache -f [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/opkg.conf -t [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/temp/ipktemp/ -o [...]/work/rpi3-oe-linux/pil-rootfs/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-ignore-recommends busybox-syslog --add-ignore-recommends busybox-udhcpc --add-ignore-recommends kernel-vmlinux --add-ignore-recommends udev-cache install [...] glib-2.0 iproute2 kernel-image kernel-module-abcd less libgettextlib [...]' returned 255: * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'kernel-module-abcd'. That's helpful info; thanks. I'll paste it to the bug in the opkg bugzilla and we can continue tracking there. -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#154216): https://lists.openembedded.org/g/openembedded-core/message/154216 Mute This Topic: https://lists.openembedded.org/mt/83779506/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
On 7/6/21 3:12 PM, Richard Purdie wrote: Kernel modules can be: a) not built at all b) built into the kernel3 c) built as separate packages For OE, where something needs a kernel module, we suggest people: RRECOMMEND_XXX += "kernel-module-xxx" and the kernel recipe has PACKAGES_DYNAMIC = "kernel-module-*". From bitbake's perspective, it builds the kernel (since the PACKAGES_DYNAMIC covers kernel-modules-xxx) and then hands off to the package manager. In the case it was built in, the Recommends will be passed over by the package manager since it is just a suggestion. If the module is present, it would be included in the image. The issue as described is that if someone has IMAGE_INSTALL containing kernel-module-xxx *and* some other package in the image RRECOMMENDS that module, it doesn't error if the package doesn't exist. I have to admit I don't remember how IMAGE_INSTALL is being passed into opkg but the change in behaviour due to the addition of a RRECOMMENDS does not sound right to me. The rpm backend does not do that but errors consistently. Yep; I understand all of that and agree. My goal here is just to make sure that the bug is filed to the correct location. As it stands, the only description of the error is from OE's perspective, and I'd like to get some understanding of the interface between OE and opkg, for this special case. It sounds like the "Depends" from IMAGE_INSTALL is somehow being overruled by the Recommends from some sub package dependency. I know that IMAGE_INSTALL gets consumed into PACKAGE_INSTALL, which gets pass off to the PM modules (iirc.) And I also recall there being a PACKAGE_INSTALL_ATTEMPTONLY variable[1]. I wonder if RRECOMMENDS are being ATTEMPTed (either through that variable, or a similar one), and the failed attempt is pre-empting the mandatory install attempt. Worth looking into. [1] https://git.openembedded.org/openembedded-core/tree/meta/classes/image.bbclass#n79 If we're driving opkg incorrectly, we should fix that but I'm not sure where the issue is, I suspect opkg... Why do you suspect opkg? The situation from its perspective is only that `kernel-module-xxx` is recommended by another package, but not available in the feeds. There's nothing invalid about that state that would cause opkg to throw an error. Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153626): https://lists.openembedded.org/g/openembedded-core/message/153626 Mute This Topic: https://lists.openembedded.org/mt/83779506/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL
Hey Rasmus, Sorry for the delay; I was OOO for the holidays and I'm just now working through my inbox. On 6/28/21 4:17 AM, Rasmus Villemoes wrote: On 25/06/2021 18.13, Richard Purdie wrote: That is probably a bug that needs opening against opkg in bugzilla then. Added Alex to Cc: (opkg maintainer). Indeed, thanks. Alex, do you have enough context from the above, or do I need to do anything explicitly to file a bug? Rasmus Could you expand a bit on how OE is supposed to fail when the kernel module package is unsatisfiable? Does it propagate a opkg satisfaction error, or is the misconfiguration caught in the OE python modules? I ask because it seems most likely to me that the inconsistency here is in the OE opkg interface modules, rather than opkg itself - which obviously has no concept of IMAGE_INSTALL or the kernel configuration. Can you identify the set of packages that OE is requesting opkg to install, with and without the RRECOMMENDS? That would help to distinguish between an inconsistency in the OE PackageManager modules and a bug in opkg itself. Thanks, -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153624): https://lists.openembedded.org/g/openembedded-core/message/153624 Mute This Topic: https://lists.openembedded.org/mt/83779506/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/3] opkg: add QA check for openssl feed verification
Feed signature checking with OpenSSL will be deprecated in the next
release of opkg.
Upstream ML Announcement:
https://groups.google.com/g/opkg-devel/c/drqw5_HuXuU
The opkg-0.4.5 configure.ac already throws a warning when
`--enable-openssl` is requested.
Add a temporary QA check to the opkg recipe, which will throw a warning
to the builder when they have `openssl` enabled in their opkg
PACKAGECONFIG. This will give builders some time to either change their
feed verification mechanism, or raise their use-case with upstream.
Signed-off-by: Alex Stewart
---
meta/recipes-devtools/opkg/opkg_0.4.5.bb | 13 +
1 file changed, 13 insertions(+)
diff --git a/meta/recipes-devtools/opkg/opkg_0.4.5.bb
b/meta/recipes-devtools/opkg/opkg_0.4.5.bb
index
bc948647c804f3f24800275289ef3fd7dee9335f..56d6211a8a8112b4ae1afcd8987f950fcbcb
100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.5.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.4.5.bb
@@ -60,6 +60,19 @@ do_install_ptest () {
sed -i -e '/@PYTHONPATH=. $(PYTHON) $^/a\\t@if [ "$$?" != "0" ];then
echo "FAIL:"$^;else echo "PASS:"$^;fi' ${D}${PTEST_PATH}/tests/Makefile
}
+WARN_QA_append += "openssl-deprecation"
+QAPKGTEST[openssl-deprecation] = "package_qa_check_openssl_deprecation"
+def package_qa_check_openssl_deprecation (package, d, messages):
+sane = True
+
+pkgconfig = (d.getVar("PACKAGECONFIG") or "").split()
+if pkgconfig and 'openssl' in pkgconfig:
+package_qa_add_message(messages, 'openssl-deprecation', '"openssl" in
opkg.bb PACKAGECONFIG. Feed signature checking with OpenSSL will be deprecated
in the next opkg release. Consider using GPG checking instead.')
+sane = False
+
+return sane
+
+
RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} opkg-arch-config
libarchive"
RDEPENDS_${PN}_class-native = ""
RDEPENDS_${PN}_class-nativesdk = ""
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152816):
https://lists.openembedded.org/g/openembedded-core/message/152816
Mute This Topic: https://lists.openembedded.org/mt/83431242/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/3] opkg: upgrade to version 0.4.5
Drop patches which have been accepted upstream.
Signed-off-by: Alex Stewart
---
...e-OS-negotiate-relative-package-dirs.patch | 43 ---
.../opkg/opkg/sourcedateepoch.patch | 24 ---
.../opkg/{opkg_0.4.4.bb => opkg_0.4.5.bb} | 6 +--
3 files changed, 2 insertions(+), 71 deletions(-)
delete mode 100644
meta/recipes-devtools/opkg/opkg/0001-tests-let-the-OS-negotiate-relative-package-dirs.patch
delete mode 100644 meta/recipes-devtools/opkg/opkg/sourcedateepoch.patch
rename meta/recipes-devtools/opkg/{opkg_0.4.4.bb => opkg_0.4.5.bb} (91%)
diff --git
a/meta/recipes-devtools/opkg/opkg/0001-tests-let-the-OS-negotiate-relative-package-dirs.patch
b/meta/recipes-devtools/opkg/opkg/0001-tests-let-the-OS-negotiate-relative-package-dirs.patch
deleted file mode 100644
index
33b7280e5a1d171400e0765c7d66072e3a718d17..
---
a/meta/recipes-devtools/opkg/opkg/0001-tests-let-the-OS-negotiate-relative-package-dirs.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From 4acda6d01c5abd33f1a1a3275fd695363f59473f Mon Sep 17 00:00:00 2001
-From: Alex Stewart
-Date: Tue, 15 Dec 2020 15:17:54 -0600
-Subject: [opkg][opkg-0.4.4 PATCH] tests: let the OS negotiate relative package
- dirs
-
-In cases where a regression test requires that a package be installed to
-a subdirectory in the test feed, the opk.py module will attempt to
-resolve the subdirectory and rebase it to the root of the test feed.
-
-This is unnecessary, since all operations which make use of the
-subdirectory path do so from the perspective of the test feed already.
-Further, the rebase implementation breaks in cases where the test feed
-is beyond a symlink.
-
-Remove the resolve-and-rebase logic, and allow the OS to negotiate the
-relative path.
-
-Upstream-Status: Submitted
[https://groups.google.com/g/opkg-devel/c/dE1o7_OVQSY]
-
-Signed-off-by: Alex Stewart
- tests/opk.py | 4 +---
- 1 file changed, 1 insertion(+), 3 deletions(-)
-
-diff --git a/tests/opk.py b/tests/opk.py
-index
692339567f72441766c8e658edc5bdf6a339f77d..711abacaeb328283e31524f6a49305fc7d39696a
100644
a/tests/opk.py
-+++ b/tests/opk.py
-@@ -58,9 +58,7 @@ class Opk:
- if 'Version' not in control.keys():
- control['Version'] = '1.0'
- if subdirectory is not None:
--subdir = Path(subdirectory).resolve()
--opkdir = Path(cfg.opkdir)
--self._relative_dir = subdir.relative_to(opkdir)
-+self._relative_dir = Path(subdirectory)
- else:
- self._relative_dir = None
- self.control = control
---
-2.29.2
-
diff --git a/meta/recipes-devtools/opkg/opkg/sourcedateepoch.patch
b/meta/recipes-devtools/opkg/opkg/sourcedateepoch.patch
deleted file mode 100644
index
4578fa33be2cdb7de509796b43ffa96f6ab291dc..
--- a/meta/recipes-devtools/opkg/opkg/sourcedateepoch.patch
+++ /dev/null
@@ -1,24 +0,0 @@
-Having CLEAN_DATE come from the current date doesn't allow for build
-reproducibility. Add the option of using SOURCE_DATE_EPOCH if set
-which for OE, it will be.
-
-Upstream-Status: Pending
-RP 2021/2/2
-
-Index: opkg-0.4.4/configure.ac
-===
opkg-0.4.4.orig/configure.ac
-+++ opkg-0.4.4/configure.ac
-@@ -281,7 +281,11 @@ AC_FUNC_UTIME_NULL
- AC_FUNC_VPRINTF
- AC_CHECK_FUNCS([memmove memset mkdir regcomp strchr strcspn strdup strerror
strndup strrchr strstr strtol strtoul sysinfo utime])
-
--CLEAN_DATE=`date +"%B %Y" | tr -d '\n'`
-+if ! test -z "$SOURCE_DATE_EPOCH" ; then
-+CLEAN_DATE=`LC_ALL=C date -d @$SOURCE_DATE_EPOCH +"%B %Y" | tr -d '\n'`
-+else
-+CLEAN_DATE=`date +"%B %Y" | tr -d '\n'`
-+fi
-
- AC_SUBST([CLEAN_DATE])
-
diff --git a/meta/recipes-devtools/opkg/opkg_0.4.4.bb
b/meta/recipes-devtools/opkg/opkg_0.4.5.bb
similarity index 91%
rename from meta/recipes-devtools/opkg/opkg_0.4.4.bb
rename to meta/recipes-devtools/opkg/opkg_0.4.5.bb
index
9eca61be2aa581ecdb1bb38a6af858899c31203e..bc948647c804f3f24800275289ef3fd7dee9335f
100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.4.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.4.5.bb
@@ -15,13 +15,11 @@ PE = "1"
SRC_URI =
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz \
file://opkg.conf \
file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \
- file://0001-tests-let-the-OS-negotiate-relative-package-dirs.patch \
- file://sourcedateepoch.patch \
file://run-ptest \
"
-SRC_URI[md5sum] = "345900c1d4747d58455867f9fe88ca43"
-SRC_URI[sha256sum] =
"2217acc58b8eb31300631ebae75e222ebc700c9c1cf6408088705d19a472c839"
+SRC_URI[md5sum] = "5dc41ad37d88803b5e0f456a9c5a0811"
+SRC_URI[sha256sum] =
"a1214a75fa34fb9228db8da47308e0e711b1c93fd8938cf164c10fd28eb50f1e"
# This ne
[OE-core] [PATCH 1/3] opkg-utils: upgrade to version 0.4.5
Signed-off-by: Alex Stewart
---
.../opkg-utils/{opkg-utils_0.4.3.bb => opkg-utils_0.4.5.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/opkg-utils/{opkg-utils_0.4.3.bb =>
opkg-utils_0.4.5.bb} (94%)
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.3.bb
b/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.5.bb
similarity index 94%
rename from meta/recipes-devtools/opkg-utils/opkg-utils_0.4.3.bb
rename to meta/recipes-devtools/opkg-utils/opkg-utils_0.4.5.bb
index
ce299d6b6358a037973cceabe2f343a0daec24f8..93d291110444211990c4c204fc23a84ec86b417e
100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.3.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.5.bb
@@ -12,8 +12,8 @@ SRC_URI =
"http://git.yoctoproject.org/cgit/cgit.cgi/${BPN}/snapshot/${BPN}-${PV
"
UPSTREAM_CHECK_URI =
"http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/refs/;
-SRC_URI[md5sum] = "7bbadb3c381f3ea935b21d3bb8cc4671"
-SRC_URI[sha256sum] =
"046517600fb0aed6c4645edefe02281f4fa2f1c02f71596152d93172452c0b01"
+SRC_URI[md5sum] = "025b19744e5c7fc1c8380e17df1fcc64"
+SRC_URI[sha256sum] =
"528635e674addea5c2b3a3268404ad04a952c4f410d17c3d754f5dd5529770c9"
TARGET_CC_ARCH += "${LDFLAGS}"
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152814):
https://lists.openembedded.org/g/openembedded-core/message/152814
Mute This Topic: https://lists.openembedded.org/mt/83431239/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: Fix patch glitches
Hey Richard, On 2/9/21 9:23 AM, Richard Purdie wrote: Well spotted. I somehow grabbed a half complete version, trying to juggle too many things at once I think. I've fixed it on the branch, third time lucky :/. The new patch on master-next looks good. Could you submit it to the opkg-devel ML, so that I can pull it from there? Thanks! -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147908): https://lists.openembedded.org/g/openembedded-core/message/147908 Mute This Topic: https://lists.openembedded.org/mt/80505499/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: Fix build reproducibility issue
On 2/2/21 5:48 PM, Richard Purdie wrote: A build date was leaking into the generated docs and makefile used for ptests leading to reproducibility issues each time the month changed. Add a patch to use SOURCE_DATE_EPOCH to derive it if available. ACK the objective, but I have a couple concerns about the patch below. +--- opkg-0.4.4.orig/configure.ac opkg-0.4.4/configure.ac +@@ -281,7 +281,12 @@ AC_FUNC_UTIME_NULL + AC_FUNC_VPRINTF + AC_CHECK_FUNCS([memmove memset mkdir regcomp strchr strcspn strdup strerror strndup strrchr strstr strtol strtoul sysinfo utime]) + +-CLEAN_DATE=`date +"%B %Y" | tr -d '\n'` ++1607446883 Is this `1607...` timestamp just some leftover pollution in the configure.ac file or does it serve some purpose? ++if [ ! -z "$SOURCE_DATE_EPOCH" ]; then AutoConf doesn't have the shell interpretation of `[`; right? At least on my system, AutoConf drops the brackets in this statement and writes the ./configure file as: if ! -z "$SOURCE_DATE_EPOCH" ; then which obviously fails when executed. Can you use `if test ! -z ...` instead? ++CLEAN_DATE=`LC_ALL=C date -d @$SOURCE_DATE_EPOCH +"%B %Y" | tr -d '\n'` ++else ++CLEAN_DATE=`date +"%B %Y" | tr -d '\n'` ++fi + + AC_SUBST([CLEAN_DATE]) + diff --git a/meta/recipes-devtools/opkg/opkg_0.4.4.bb b/meta/recipes-devtools/opkg/opkg_0.4.4.bb index f8034ca5fa5..548e81962d7 100644 --- a/meta/recipes-devtools/opkg/opkg_0.4.4.bb +++ b/meta/recipes-devtools/opkg/opkg_0.4.4.bb @@ -15,6 +15,7 @@ SRC_URI = "https://urldefense.com/v3/__http://downloads.yoctoproject.org/releases/$*7BBPN*7D/$*7BBPN*7D-$*7BPV*7D.tar.gz__;JSUlJSUl!!FbZ0ZwI3Qg!-TBdy64CfATG4aDXNwLs-F_1Ucyiha1TiiAh_Q51F5iWdo4LWw-X9cnExOGco7s$ file://opkg.conf \ file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \ file://0001-tests-let-the-OS-negotiate-relative-package-dirs.patch \ + file://sourcedateepoch.patch \ file://run-ptest \ " -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147836): https://lists.openembedded.org/g/openembedded-core/message/147836 Mute This Topic: https://lists.openembedded.org/mt/80341753/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v2 1/1] opkg: upgrade to version 0.4.4
Include an upstream patch for 0.4.4 which fixes a test framework error
that occurs on host systems with symlinked /tmp directories (like OE).
Signed-off-by: Alex Stewart
---
...e-OS-negotiate-relative-package-dirs.patch | 43 +++
.../opkg/{opkg_0.4.3.bb => opkg_0.4.4.bb} | 5 ++-
2 files changed, 46 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-devtools/opkg/opkg/0001-tests-let-the-OS-negotiate-relative-package-dirs.patch
rename meta/recipes-devtools/opkg/{opkg_0.4.3.bb => opkg_0.4.4.bb} (92%)
diff --git
a/meta/recipes-devtools/opkg/opkg/0001-tests-let-the-OS-negotiate-relative-package-dirs.patch
b/meta/recipes-devtools/opkg/opkg/0001-tests-let-the-OS-negotiate-relative-package-dirs.patch
new file mode 100644
index
..33b7280e5a1d171400e0765c7d66072e3a718d17
--- /dev/null
+++
b/meta/recipes-devtools/opkg/opkg/0001-tests-let-the-OS-negotiate-relative-package-dirs.patch
@@ -0,0 +1,43 @@
+From 4acda6d01c5abd33f1a1a3275fd695363f59473f Mon Sep 17 00:00:00 2001
+From: Alex Stewart
+Date: Tue, 15 Dec 2020 15:17:54 -0600
+Subject: [opkg][opkg-0.4.4 PATCH] tests: let the OS negotiate relative package
+ dirs
+
+In cases where a regression test requires that a package be installed to
+a subdirectory in the test feed, the opk.py module will attempt to
+resolve the subdirectory and rebase it to the root of the test feed.
+
+This is unnecessary, since all operations which make use of the
+subdirectory path do so from the perspective of the test feed already.
+Further, the rebase implementation breaks in cases where the test feed
+is beyond a symlink.
+
+Remove the resolve-and-rebase logic, and allow the OS to negotiate the
+relative path.
+
+Upstream-Status: Submitted
[https://groups.google.com/g/opkg-devel/c/dE1o7_OVQSY]
+
+Signed-off-by: Alex Stewart
+---
+ tests/opk.py | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/tests/opk.py b/tests/opk.py
+index
692339567f72441766c8e658edc5bdf6a339f77d..711abacaeb328283e31524f6a49305fc7d39696a
100644
+--- a/tests/opk.py
b/tests/opk.py
+@@ -58,9 +58,7 @@ class Opk:
+ if 'Version' not in control.keys():
+ control['Version'] = '1.0'
+ if subdirectory is not None:
+-subdir = Path(subdirectory).resolve()
+-opkdir = Path(cfg.opkdir)
+-self._relative_dir = subdir.relative_to(opkdir)
++self._relative_dir = Path(subdirectory)
+ else:
+ self._relative_dir = None
+ self.control = control
+--
+2.29.2
+
diff --git a/meta/recipes-devtools/opkg/opkg_0.4.3.bb
b/meta/recipes-devtools/opkg/opkg_0.4.4.bb
similarity index 92%
rename from meta/recipes-devtools/opkg/opkg_0.4.3.bb
rename to meta/recipes-devtools/opkg/opkg_0.4.4.bb
index
46b7aa25231e49b3e800dabac1e516f6c741e574..f8034ca5fa591bce73e5bf6b0ce70bb6a681a18b
100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.3.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.4.4.bb
@@ -14,11 +14,12 @@ PE = "1"
SRC_URI =
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz \
file://opkg.conf \
file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \
+ file://0001-tests-let-the-OS-negotiate-relative-package-dirs.patch \
file://run-ptest \
"
-SRC_URI[md5sum] = "86ec5eee9362aca0990994a402e077e9"
-SRC_URI[sha256sum] =
"dda452854bc0cd1334f7ba18a66003d1c12a98600c894111b56919b1ea434718"
+SRC_URI[md5sum] = "345900c1d4747d58455867f9fe88ca43"
+SRC_URI[sha256sum] =
"2217acc58b8eb31300631ebae75e222ebc700c9c1cf6408088705d19a472c839"
# This needs to be before ptest inherit, otherwise all ptest files end packaged
# in libopkg package if OPKGLIBDIR == libdir, because default
--
2.29.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145788):
https://lists.openembedded.org/g/openembedded-core/message/145788
Mute This Topic: https://lists.openembedded.org/mt/79020734/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v2 0/1] opkg: upgrade to 0.4.4
Adopting Alejandro del Castillo's original upgrade patch.
Patch V2:
* Added a .patch from the 0.4.4 upstream which should resolve the ptest
framework error which Alex Kanavin observed in his OE-core tests. I've
verified this change on a local build of the OE-core minimal QEMU image.
Alex Stewart (1):
opkg: upgrade to version 0.4.4
...e-OS-negotiate-relative-package-dirs.patch | 43 +++
.../opkg/{opkg_0.4.3.bb => opkg_0.4.4.bb} | 5 ++-
2 files changed, 46 insertions(+), 2 deletions(-)
create mode 100644
meta/recipes-devtools/opkg/opkg/0001-tests-let-the-OS-negotiate-relative-package-dirs.patch
rename meta/recipes-devtools/opkg/{opkg_0.4.3.bb => opkg_0.4.4.bb} (92%)
--
2.29.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145787):
https://lists.openembedded.org/g/openembedded-core/message/145787
Mute This Topic: https://lists.openembedded.org/mt/79020726/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] opkg: upgrade to version 0.4.4
Hey Alex, Thanks for bringing this up. One of the opkg test framework changes introduced in 0.4.4 doesn't play well with hosts that symlink their `/tmp` directory. I have a fix for it which I'll post to the opkg mainline soon. Since Alejandro is OOO for the holidays, I don't think he'll mind me adopting this patchset. I'll backport the test framework fix into a `.patch` for OE to consume with the 0.4.4 recipe upgrade. Thanks, On 12/14/20 1:52 PM, Alexander Kanavin wrote: opkg ptests regress with this change: https://autobuilder.yocto.io/pub/non-release/20201214-1/testresults/qemux86-64-ptest/opkg.log <https://urldefense.com/v3/__https://autobuilder.yocto.io/pub/non-release/20201214-1/testresults/qemux86-64-ptest/opkg.log__;!!FbZ0ZwI3Qg!-nKzjywoAri9TTtGVweycYs2SB9nawYzY5wxthFeo-gExQXFZ_yDeIt5ijJVDbI$> Do not merge please, as this undoes my work to reach 100% pass rate in ptests :) Alex -- Alex Stewart Software Engineer - NI Real-Time OS NI (National Instruments) alex.stew...@ni.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145757): https://lists.openembedded.org/g/openembedded-core/message/145757 Mute This Topic: https://lists.openembedded.org/mt/78790833/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Add package managers as a plugin
Hey Fredrik, On 6/30/20 1:38 PM, Fredrik Gustafsson wrote: I added apk to your script and then ran That is not supportive of my statement of ipk being the slowest package manager. That statement come from timing tests done with our proprietary version of poky that is somewhat extended when it comes to the do_rootfs task. We're generating a bit more artifacts than poky. Ah; good to know. Thanks for checking again! Sounds like it could be related to extant opkg bugs which degrade performance when you have many (read: thousands) of packages in the feed. https://bugzilla.yoctoproject.org/show_bug.cgi?id=13593 So I tried your script with core-image-sato-sdk-ptest instead that is a bigger image. The results where more mixed. There is a huge difference between different package managers: But yeah, I should probably rephrase my cover letter. You'll find a layer for APK that will apply on top of my patch serie attached to this email. Thanks for sending that; I'm interested to take a look at it. Those new performance numbers look impressive. Good luck with the patchset. -- Alex Stewart Software Engineer - LabVIEW Real-Time OS National Instruments alex.stew...@ni.com office: +1(512)683-8522 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140150): https://lists.openembedded.org/g/openembedded-core/message/140150 Mute This Topic: https://lists.openembedded.org/mt/75057633/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Add package managers as a plugin
On 6/23/20 6:13 AM, Fredrik Gustafsson wrote:
When building and having a good cache hit, a significant amount of time is
spent in the phase of generating a rootfs, which is really about the
performance of the package manager. ipkg is way slower than deb or rpm.
I was interested enough in your comment here to collect a small sampling
of comparative do_rootfs runs on one of my dev machines.
I used a virgin poky clone and tried to replicate the steps you provided
in your OP, timing only the execution of `bitbake -c do_rootfs
core-image-minimal`. I used the debian `time` package for timing. Here's
what I got:
# Summary
PM Avg do_rootfs time (s)
-- --
deb 33.89
ipk 33.35
rpm 31.85
# Raw Data
deb 00:33.54
deb 00:34.66
deb 00:33.55
deb 00:33.23
deb 00:34.46
ipk 00:33.96
ipk 00:34.43
ipk 00:33.99
ipk 00:32.17
ipk 00:32.22
rpm 00:29.92
rpm 00:32.31
rpm 00:31.90
rpm 00:33.31
rpm 00:31.80
Based on those results, it seems like all the current PMs are similar in
terms of execution time. Are there major differences between my test
setup and yours? And do you already have a layer with APK available that
I could compare against on my hardware?
This is the crude script I used to automate the test runs:
```
#!/bin/bash
set -euxo pipefail
TIME=/usr/bin/time
recipe=core-image-minimal
# Options are:
# - 'package_deb' for debian style deb files
# - 'package_ipk' for ipk files are used by opkg (a debian style
embedded package manager)
# - 'package_rpm' for rpm style packages
function set_pkg_man() {
pkg_man=${1}
sed -i "s/\(^PACKAGE_CLASSES ?= \)\"\(.*\)\"/\1\"$pkg_man\"/"
conf/local.conf
}
function rebuild_recipe() {
bitbake -c cleanall $recipe
bitbake $recipe
}
function test_recipe() {
local name=${1}
bitbake -c cleansstate $recipe
bitbake -c clean $recipe
$TIME bitbake -c do_rootfs -f $recipe 2>&1 | tee outs/out.$name
}
# rpm
set_pkg_man package_rpm
rebuild_recipe
test_recipe rpm.1
test_recipe rpm.2
test_recipe rpm.3
test_recipe rpm.4
test_recipe rpm.5
# ipk
set_pkg_man package_ipk
rebuild_recipe
test_recipe ipk.1
test_recipe ipk.2
test_recipe ipk.3
test_recipe ipk.4
test_recipe ipk.5
# deb
set_pkg_man package_deb
rebuild_recipe
test_recipe deb.1
test_recipe deb.2
test_recipe deb.3
test_recipe deb.4
test_recipe deb.5
```
Thanks,
--
Alex Stewart
Software Engineer - LabVIEW Real-Time OS
National Instruments
alex.stew...@ni.com
office: +1(512)683-8522
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139891):
https://lists.openembedded.org/g/openembedded-core/message/139891
Mute This Topic: https://lists.openembedded.org/mt/75057633/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 1/1] recipes-core: breakout hwclock.sh from busybox
Bump x2.
On 04/09/2018 02:57 PM, Alex Stewart wrote:
Bump.
Did this patch get blacklisted for inclusion or does anyone have any
outstanding concerns about it?
On 03/21/2018 01:55 PM, Alex Stewart wrote:
* Move the hwclock.sh initscript from busybox into its own package and
recipe (hwclock-init). This script is generally useful for distros
that get their hwclock implementation from sources other than
busybox (like util-linux).
:busybox/*
* Remove the busybox-hwclock package, as it no longer has a purpose.
* If busybox is configured to include hwclock, the busybox package will
RDEPEND on hwclock-init.
:util-linux/*
* util-linux-hwclock RDEPENDS on hwclock-init for its initscript.
Signed-off-by: Alex Stewart <alex.stew...@ni.com>
---
meta/recipes-core/busybox/busybox.inc | 16 +++--
meta/recipes-core/busybox/busybox_1.27.2.bb | 1 -
meta/recipes-core/busybox/files/hwclock.sh | 83
--
meta/recipes-core/hwclock-init/files/hwclock.sh | 83
++
meta/recipes-core/hwclock-init/hwclock-init_1.0.bb | 31
meta/recipes-core/util-linux/util-linux.inc | 1 +
6 files changed, 124 insertions(+), 91 deletions(-)
delete mode 100644 meta/recipes-core/busybox/files/hwclock.sh
create mode 100644 meta/recipes-core/hwclock-init/files/hwclock.sh
create mode 100644 meta/recipes-core/hwclock-init/hwclock-init_1.0.bb
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index d1675c37aa..50cc837335 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -20,19 +20,17 @@ export EXTRA_LDFLAGS = "${LDFLAGS}"
EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH}
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}'
HOSTCPP='${BUILD_CPP}'"
-PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog
${PN}-mdev ${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog
${PN}-mdev"
FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf*
${systemd_unitdir}/system/syslog.service
${sysconfdir}/default/busybox-syslog"
FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev
${sysconfdir}/mdev.conf ${sysconfdir}/mdev/*"
FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
-FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
-INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd
${PN}-mdev ${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd
${PN}-mdev"
INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
-INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
INITSCRIPT_NAME_${PN}-mdev = "mdev"
INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
INITSCRIPT_NAME_${PN}-syslog = "syslog"
@@ -284,9 +282,6 @@ do_install () {
if grep "CONFIG_UDHCPD=y" ${B}/.config; then
install -m 0755 ${WORKDIR}/busybox-udhcpd
${D}${sysconfdir}/init.d/
fi
- if grep "CONFIG_HWCLOCK=y" ${B}/.config; then
- install -m 0755 ${WORKDIR}/hwclock.sh ${D}${sysconfdir}/init.d/
- fi
if grep "CONFIG_UDHCPC=y" ${B}/.config; then
install -d ${D}${sysconfdir}/udhcpc.d
install -d ${D}${datadir}/udhcpc
@@ -375,6 +370,13 @@ python do_package_prepend () {
else:
set_alternative_vars("${sysconfdir}/busybox.links.nosuid",
"${base_bindir}/busybox.nosuid")
set_alternative_vars("${sysconfdir}/busybox.links.suid",
"${base_bindir}/busybox.suid")
+
+ # If busybox is configured to provide a hwclock implementation,
add a
+ # package dependency on hwclock-init for the /etc/init.d/hwclock.sh
+ # initscript.
+ with open(d.getVar('B') + '/.config', 'r') as fp_conf:
+ if 'CONFIG_HWCLOCK=y' in fp_conf.read():
+ d.appendVar('RDEPENDS_busybox', ' hwclock-init ')
}
pkg_postinst_${PN} () {
diff --git a/meta/recipes-core/busybox/busybox_1.27.2.bb
b/meta/recipes-core/busybox/busybox_1.27.2.bb
index 36a6342aaf..78d8e14a6b 100644
--- a/meta/recipes-core/busybox/busybox_1.27.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.27.2.bb
@@ -8,7 +8,6 @@ SRC_URI =
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-udhcpd \
file://default.script \
file://simple.script \
- file://hwclock.sh \
file://mount.busybox \
file://syslog \
file://syslog-startup.conf \
diff --git a/meta/recipes-core/busybox/files/hwclock.sh
b/meta/recipes-core/busybox/files/hwclock
Re: [OE-core] [PATCH v2 1/1] recipes-core: breakout hwclock.sh from busybox
Bump.
Did this patch get blacklisted for inclusion or does anyone have any
outstanding concerns about it?
On 03/21/2018 01:55 PM, Alex Stewart wrote:
* Move the hwclock.sh initscript from busybox into its own package and
recipe (hwclock-init). This script is generally useful for distros
that get their hwclock implementation from sources other than
busybox (like util-linux).
:busybox/*
* Remove the busybox-hwclock package, as it no longer has a purpose.
* If busybox is configured to include hwclock, the busybox package will
RDEPEND on hwclock-init.
:util-linux/*
* util-linux-hwclock RDEPENDS on hwclock-init for its initscript.
Signed-off-by: Alex Stewart <alex.stew...@ni.com>
---
meta/recipes-core/busybox/busybox.inc | 16 +++--
meta/recipes-core/busybox/busybox_1.27.2.bb| 1 -
meta/recipes-core/busybox/files/hwclock.sh | 83 --
meta/recipes-core/hwclock-init/files/hwclock.sh| 83 ++
meta/recipes-core/hwclock-init/hwclock-init_1.0.bb | 31
meta/recipes-core/util-linux/util-linux.inc| 1 +
6 files changed, 124 insertions(+), 91 deletions(-)
delete mode 100644 meta/recipes-core/busybox/files/hwclock.sh
create mode 100644 meta/recipes-core/hwclock-init/files/hwclock.sh
create mode 100644 meta/recipes-core/hwclock-init/hwclock-init_1.0.bb
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index d1675c37aa..50cc837335 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -20,19 +20,17 @@ export EXTRA_LDFLAGS = "${LDFLAGS}"
EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH} CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}' HOSTCPP='${BUILD_CPP}'"
-PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev ${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev"
FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf*
${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog"
FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf
${sysconfdir}/mdev/*"
FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
-FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
-INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev ${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev"
INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
-INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
INITSCRIPT_NAME_${PN}-mdev = "mdev"
INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
INITSCRIPT_NAME_${PN}-syslog = "syslog"
@@ -284,9 +282,6 @@ do_install () {
if grep "CONFIG_UDHCPD=y" ${B}/.config; then
install -m 0755 ${WORKDIR}/busybox-udhcpd
${D}${sysconfdir}/init.d/
fi
- if grep "CONFIG_HWCLOCK=y" ${B}/.config; then
- install -m 0755 ${WORKDIR}/hwclock.sh ${D}${sysconfdir}/init.d/
- fi
if grep "CONFIG_UDHCPC=y" ${B}/.config; then
install -d ${D}${sysconfdir}/udhcpc.d
install -d ${D}${datadir}/udhcpc
@@ -375,6 +370,13 @@ python do_package_prepend () {
else:
set_alternative_vars("${sysconfdir}/busybox.links.nosuid",
"${base_bindir}/busybox.nosuid")
set_alternative_vars("${sysconfdir}/busybox.links.suid",
"${base_bindir}/busybox.suid")
+
+# If busybox is configured to provide a hwclock implementation, add a
+# package dependency on hwclock-init for the /etc/init.d/hwclock.sh
+# initscript.
+with open(d.getVar('B') + '/.config', 'r') as fp_conf:
+if 'CONFIG_HWCLOCK=y' in fp_conf.read():
+d.appendVar('RDEPENDS_busybox', ' hwclock-init ')
}
pkg_postinst_${PN} () {
diff --git a/meta/recipes-core/busybox/busybox_1.27.2.bb
b/meta/recipes-core/busybox/busybox_1.27.2.bb
index 36a6342aaf..78d8e14a6b 100644
--- a/meta/recipes-core/busybox/busybox_1.27.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.27.2.bb
@@ -8,7 +8,6 @@ SRC_URI =
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-udhcpd \
file://default.script \
file://simple.script \
- file://hwclock.sh \
file://mount.busybox \
file://syslog \
file://syslog-startup.conf \
diff --git a/meta/recipes-core/busybox/files/hwclock.sh
b/meta/recipes-core/busybox/files/hwclock.sh
delete
[OE-core] [PATCH v2 1/1] recipes-core: breakout hwclock.sh from busybox
* Move the hwclock.sh initscript from busybox into its own package and
recipe (hwclock-init). This script is generally useful for distros
that get their hwclock implementation from sources other than
busybox (like util-linux).
:busybox/*
* Remove the busybox-hwclock package, as it no longer has a purpose.
* If busybox is configured to include hwclock, the busybox package will
RDEPEND on hwclock-init.
:util-linux/*
* util-linux-hwclock RDEPENDS on hwclock-init for its initscript.
Signed-off-by: Alex Stewart <alex.stew...@ni.com>
---
meta/recipes-core/busybox/busybox.inc | 16 +++--
meta/recipes-core/busybox/busybox_1.27.2.bb| 1 -
meta/recipes-core/busybox/files/hwclock.sh | 83 --
meta/recipes-core/hwclock-init/files/hwclock.sh| 83 ++
meta/recipes-core/hwclock-init/hwclock-init_1.0.bb | 31
meta/recipes-core/util-linux/util-linux.inc| 1 +
6 files changed, 124 insertions(+), 91 deletions(-)
delete mode 100644 meta/recipes-core/busybox/files/hwclock.sh
create mode 100644 meta/recipes-core/hwclock-init/files/hwclock.sh
create mode 100644 meta/recipes-core/hwclock-init/hwclock-init_1.0.bb
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index d1675c37aa..50cc837335 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -20,19 +20,17 @@ export EXTRA_LDFLAGS = "${LDFLAGS}"
EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH}
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}'
HOSTCPP='${BUILD_CPP}'"
-PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev"
FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf*
${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog"
FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf
${sysconfdir}/mdev/*"
FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
-FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
-INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev"
INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
-INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
INITSCRIPT_NAME_${PN}-mdev = "mdev"
INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
INITSCRIPT_NAME_${PN}-syslog = "syslog"
@@ -284,9 +282,6 @@ do_install () {
if grep "CONFIG_UDHCPD=y" ${B}/.config; then
install -m 0755 ${WORKDIR}/busybox-udhcpd
${D}${sysconfdir}/init.d/
fi
- if grep "CONFIG_HWCLOCK=y" ${B}/.config; then
- install -m 0755 ${WORKDIR}/hwclock.sh ${D}${sysconfdir}/init.d/
- fi
if grep "CONFIG_UDHCPC=y" ${B}/.config; then
install -d ${D}${sysconfdir}/udhcpc.d
install -d ${D}${datadir}/udhcpc
@@ -375,6 +370,13 @@ python do_package_prepend () {
else:
set_alternative_vars("${sysconfdir}/busybox.links.nosuid",
"${base_bindir}/busybox.nosuid")
set_alternative_vars("${sysconfdir}/busybox.links.suid",
"${base_bindir}/busybox.suid")
+
+# If busybox is configured to provide a hwclock implementation, add a
+# package dependency on hwclock-init for the /etc/init.d/hwclock.sh
+# initscript.
+with open(d.getVar('B') + '/.config', 'r') as fp_conf:
+if 'CONFIG_HWCLOCK=y' in fp_conf.read():
+d.appendVar('RDEPENDS_busybox', ' hwclock-init ')
}
pkg_postinst_${PN} () {
diff --git a/meta/recipes-core/busybox/busybox_1.27.2.bb
b/meta/recipes-core/busybox/busybox_1.27.2.bb
index 36a6342aaf..78d8e14a6b 100644
--- a/meta/recipes-core/busybox/busybox_1.27.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.27.2.bb
@@ -8,7 +8,6 @@ SRC_URI =
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-udhcpd \
file://default.script \
file://simple.script \
- file://hwclock.sh \
file://mount.busybox \
file://syslog \
file://syslog-startup.conf \
diff --git a/meta/recipes-core/busybox/files/hwclock.sh
b/meta/recipes-core/busybox/files/hwclock.sh
deleted file mode 100644
index be5f94d86c..00
--- a/meta/recipes-core/busybox/files/hwclock.sh
+++ /dev/null
@@ -1,83 +0,0 @@
-#!/bin/sh
-### BEGIN INIT INFO
-# Provides: hwclock
-# Requir
[OE-core] [PATCH v2 0/1] recipes-core: breakout hwclock.sh from busybox
This is a resubmission of the previous patch by the same name submitted ~1 month ago, plus a fixup suggested by Andre McCurdy (calling getVar without `expand=True`). Otherwise, I have rebased to the latest master and revalidated that hwclock-init, busybox, and util-linux build as expected from the OE-core project and our internal derivative (NI Linux RT). Alex Stewart (1): recipes-core: breakout hwclock.sh from busybox meta/recipes-core/busybox/busybox.inc | 16 +++-- meta/recipes-core/busybox/busybox_1.27.2.bb| 1 - meta/recipes-core/busybox/files/hwclock.sh | 83 -- meta/recipes-core/hwclock-init/files/hwclock.sh| 83 ++ meta/recipes-core/hwclock-init/hwclock-init_1.0.bb | 31 meta/recipes-core/util-linux/util-linux.inc| 1 + 6 files changed, 124 insertions(+), 91 deletions(-) delete mode 100644 meta/recipes-core/busybox/files/hwclock.sh create mode 100644 meta/recipes-core/hwclock-init/files/hwclock.sh create mode 100644 meta/recipes-core/hwclock-init/hwclock-init_1.0.bb -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] recipes-core: move hwclock.sh to util-linux
On 01/25/2018 12:43 PM, Khem Raj wrote: On 1/12/18 7:45 PM, Christopher Larson wrote: On Fri, Jan 12, 2018 at 6:06 AM, Alex Stewart <alex.stew...@ni.com <mailto:alex.stew...@ni.com>> wrote: * Move the hwclock.sh initscript from the busybox recipe to util-linux. This script is generally useful for distros that get their hwclock implementation from sources other than busybox and we follow debian's example by providing it in util-linux. :busybox/* * Remove the busybox-hwclock package, as it no longer has a purpose. * If busybox is configured to include hwclock, the busybox package will RDEPEND on util-linux-hwclock-init. :util-linux/* * Provide the hwclock.sh script in util-linux-hwclock-init, which can be pulled by any packages that depend on its functionality. * util-linux-hwclock RDEPENDS on util-linux-hwclock-init for its initscript. Signed-off-by: Alex Stewart <alex.stew...@ni.com <mailto:alex.stew...@ni.com>> Acked-by: Haris Okanovic <haris.okano...@ni.com <mailto:haris.okano...@ni.com>> Acked-by: Adrian Ratiu <adrian.ra...@ni.com <mailto:adrian.ra...@ni.com>> Acked-by: Ken Sharp <ken.sh...@ni.com <mailto:ken.sh...@ni.com>> Natinst-ReviewBoard-ID: 214983, 215755 Just a note that this will slow down the build for targets that wouldn’t otherwise build the util-linux recipe. there is initscripts recipes, perhaps thats a better place for this. I guess that depends on our rationale for what belongs in `initscripts`. Other distros seem to assert that `initscripts` is a minimum set of scripts to bring up a system (especially a sysvinit system) and they generally don't include the equivalent of our `hwclock.sh`. Including it in `initscripts` for us would mean that embedded devices without an RTC (but which use initscripts) and which otherwise have no use for hwclock implementations either get a broken script or end up building a package that they can't use. That being said, this patch is actually deprecated in favor of [OE-core][PATCH] recipes-core: breakout hwclock.sh from busybox (18-01-23) which moves hwclock.sh into it's own hwclock-init recipe and package, that is DEPENDED by busybox (conditionally, if built with hwclock capability) and util-linux. So further discussion should be attached to that patch. Sorry for the confusion. -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -- Alex Stewart Software Engineer - LabVIEW Real-Time National Instruments alex.stew...@ni.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] recipes-core: breakout hwclock.sh from busybox
* Move the hwclock.sh initscript from busybox into its own package and
recipe (hwclock-init). This script is generally useful for distros
that get their hwclock implementation from sources other than
busybox (like util-linux).
:busybox/*
* Remove the busybox-hwclock package, as it no longer has a purpose.
* If busybox is configured to include hwclock, the busybox package will
RDEPEND on hwclock-init.
:util-linux/*
* util-linux-hwclock RDEPENDS on hwclock-init for its initscript.
Signed-off-by: Alex Stewart <alex.stew...@ni.com>
---
meta/recipes-core/busybox/busybox.inc | 16 +++--
meta/recipes-core/busybox/busybox_1.27.2.bb| 1 -
meta/recipes-core/busybox/files/hwclock.sh | 83 --
meta/recipes-core/hwclock-init/files/hwclock.sh| 83 ++
meta/recipes-core/hwclock-init/hwclock-init_1.0.bb | 31
meta/recipes-core/util-linux/util-linux.inc| 1 +
6 files changed, 124 insertions(+), 91 deletions(-)
delete mode 100644 meta/recipes-core/busybox/files/hwclock.sh
create mode 100644 meta/recipes-core/hwclock-init/files/hwclock.sh
create mode 100644 meta/recipes-core/hwclock-init/hwclock-init_1.0.bb
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 4012f921c6..bfcc6ba31a 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -20,19 +20,17 @@ export EXTRA_LDFLAGS = "${LDFLAGS}"
EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH}
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}'
HOSTCPP='${BUILD_CPP}'"
-PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev"
FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf*
${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog"
FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf
${sysconfdir}/mdev/*"
FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
-FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
-INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev"
INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
-INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
INITSCRIPT_NAME_${PN}-mdev = "mdev"
INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
INITSCRIPT_NAME_${PN}-syslog = "syslog"
@@ -276,9 +274,6 @@ do_install () {
if grep "CONFIG_UDHCPD=y" ${B}/.config; then
install -m 0755 ${WORKDIR}/busybox-udhcpd
${D}${sysconfdir}/init.d/
fi
- if grep "CONFIG_HWCLOCK=y" ${B}/.config; then
- install -m 0755 ${WORKDIR}/hwclock.sh ${D}${sysconfdir}/init.d/
- fi
if grep "CONFIG_UDHCPC=y" ${B}/.config; then
install -d ${D}${sysconfdir}/udhcpc.d
install -d ${D}${datadir}/udhcpc
@@ -377,6 +372,13 @@ python do_package_prepend () {
else:
set_alternative_vars("${sysconfdir}/busybox.links.nosuid",
"${base_bindir}/busybox.nosuid")
set_alternative_vars("${sysconfdir}/busybox.links.suid",
"${base_bindir}/busybox.suid")
+
+# If busybox is configured to provide a hwclock implementation, add a
+# package dependency on hwclock-init for the /etc/init.d/hwclock.sh
+# initscript.
+with open(d.getVar('B', expand=True) + '/.config', 'r') as fp_conf:
+if 'CONFIG_HWCLOCK=y' in fp_conf.read():
+d.appendVar('RDEPENDS_busybox', ' hwclock-init ')
}
pkg_postinst_${PN} () {
diff --git a/meta/recipes-core/busybox/busybox_1.27.2.bb
b/meta/recipes-core/busybox/busybox_1.27.2.bb
index 6c1f4888cf..af2abadc5e 100644
--- a/meta/recipes-core/busybox/busybox_1.27.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.27.2.bb
@@ -8,7 +8,6 @@ SRC_URI =
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-udhcpd \
file://default.script \
file://simple.script \
- file://hwclock.sh \
file://mount.busybox \
file://syslog \
file://syslog-startup.conf \
diff --git a/meta/recipes-core/busybox/files/hwclock.sh
b/meta/recipes-core/busybox/files/hwclock.sh
deleted file mode 100644
index be5f94d86c..00
--- a/meta/recipes-core/busybox/files/hwclock.sh
+++ /dev/null
@@ -1,83 +0,0 @@
-#!/bin/sh
-### BEGIN INIT INFO
-
[OE-core] [PATCH v3] recipes-core: move hwclock.sh to util-linux
* Move the hwclock.sh initscript from the busybox recipe to util-linux.
This script is generally useful for distros that get their hwclock
implementation from sources other than busybox and we follow debian's
example by providing it in util-linux.
:busybox/*
* Remove the busybox-hwclock package, as it no longer has a purpose.
* If busybox is configured to include hwclock, the busybox package will
RDEPEND on util-linux-hwclock-init.
:util-linux/*
* Add util-linux-hwclock-init as its own recipe so that distros which
exclusively use busybox do not have to build the entire util-linux
recipe to get the hwclock.sh initscript.
* Provide the hwclock.sh script in util-linux-hwclock-init, which can be
pulled by any packages that depend on its functionality.
* util-linux-hwclock RDEPENDS on util-linux-hwclock-init for its
initscript.
Signed-off-by: Alex Stewart <alex.stew...@ni.com>
---
meta/recipes-core/busybox/busybox.inc | 16 +++--
meta/recipes-core/busybox/busybox_1.27.2.bb| 1 -
meta/recipes-core/busybox/files/hwclock.sh | 83 --
.../util-linux/util-linux-hwclock-init_1.0.bb | 33 +
meta/recipes-core/util-linux/util-linux.inc| 1 +
meta/recipes-core/util-linux/util-linux/hwclock.sh | 83 ++
6 files changed, 126 insertions(+), 91 deletions(-)
delete mode 100644 meta/recipes-core/busybox/files/hwclock.sh
create mode 100644 meta/recipes-core/util-linux/util-linux-hwclock-init_1.0.bb
create mode 100644 meta/recipes-core/util-linux/util-linux/hwclock.sh
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 4012f921c6..d9c3c2793b 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -20,19 +20,17 @@ export EXTRA_LDFLAGS = "${LDFLAGS}"
EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH}
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}'
HOSTCPP='${BUILD_CPP}'"
-PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev"
FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf*
${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog"
FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf
${sysconfdir}/mdev/*"
FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
-FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
-INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev"
INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
-INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
INITSCRIPT_NAME_${PN}-mdev = "mdev"
INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
INITSCRIPT_NAME_${PN}-syslog = "syslog"
@@ -276,9 +274,6 @@ do_install () {
if grep "CONFIG_UDHCPD=y" ${B}/.config; then
install -m 0755 ${WORKDIR}/busybox-udhcpd
${D}${sysconfdir}/init.d/
fi
- if grep "CONFIG_HWCLOCK=y" ${B}/.config; then
- install -m 0755 ${WORKDIR}/hwclock.sh ${D}${sysconfdir}/init.d/
- fi
if grep "CONFIG_UDHCPC=y" ${B}/.config; then
install -d ${D}${sysconfdir}/udhcpc.d
install -d ${D}${datadir}/udhcpc
@@ -377,6 +372,13 @@ python do_package_prepend () {
else:
set_alternative_vars("${sysconfdir}/busybox.links.nosuid",
"${base_bindir}/busybox.nosuid")
set_alternative_vars("${sysconfdir}/busybox.links.suid",
"${base_bindir}/busybox.suid")
+
+# If busybox is configured to provide a hwclock implementation, add a
+# package dependency on util-linux-hwclock-init for the
+# /etc/init.d/hwclock.sh initscript.
+with open(d.getVar('B', expand=True) + '/.config', 'r') as fp_conf:
+if 'CONFIG_HWCLOCK=y' in fp_conf.read():
+d.appendVar('RDEPENDS_busybox', ' util-linux-hwclock-init ')
}
pkg_postinst_${PN} () {
diff --git a/meta/recipes-core/busybox/busybox_1.27.2.bb
b/meta/recipes-core/busybox/busybox_1.27.2.bb
index 6c1f4888cf..af2abadc5e 100644
--- a/meta/recipes-core/busybox/busybox_1.27.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.27.2.bb
@@ -8,7 +8,6 @@ SRC_URI =
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-udhcpd \
file://default.script \
file://simple.script \
- file://hwclock.s
Re: [OE-core] [PATCH v2] recipes-core: move hwclock.sh to util-linux
On 01/13/2018 05:48 AM, Otavio Salvador wrote: On Fri, Jan 12, 2018 at 11:06 AM, Alex Stewart <alex.stew...@ni.com> wrote: * Move the hwclock.sh initscript from the busybox recipe to util-linux. This script is generally useful for distros that get their hwclock implementation from sources other than busybox and we follow debian's example by providing it in util-linux. :busybox/* * Remove the busybox-hwclock package, as it no longer has a purpose. * If busybox is configured to include hwclock, the busybox package will RDEPEND on util-linux-hwclock-init. :util-linux/* * Provide the hwclock.sh script in util-linux-hwclock-init, which can be pulled by any packages that depend on its functionality. * util-linux-hwclock RDEPENDS on util-linux-hwclock-init for its initscript. Signed-off-by: Alex Stewart <alex.stew...@ni.com> Acked-by: Haris Okanovic <haris.okano...@ni.com> Acked-by: Adrian Ratiu <adrian.ra...@ni.com> Acked-by: Ken Sharp <ken.sh...@ni.com> Natinst-ReviewBoard-ID: 214983, 215755 As mentioned by Christopher, it will increase the build time for everyone and there is real gain in this this change. If you want to disable the busybox dependency then move hwclock.sh to a hwclock-init package that has no standard dependencies and is allarch and make busybox and util-linux to depends on it. Either solution works for my purposes, so I'm fine breaking hwclock.sh out as its own recipe. It seems degenerative to break such a small piece of common-code into its own recipe, but I suppose there isn't a better solution if util-linux isn't commonly built. -- Alex Stewart Software Engineer - LabVIEW Real-Time National Instruments alex.stew...@ni.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] recipes-core: move hwclock.sh to util-linux
* Move the hwclock.sh initscript from the busybox recipe to util-linux.
This script is generally useful for distros that get their hwclock
implementation from sources other than busybox and we follow debian's
example by providing it in util-linux.
:busybox/*
* Remove the busybox-hwclock package, as it no longer has a purpose.
* If busybox is configured to include hwclock, the busybox package will
RDEPEND on util-linux-hwclock-init.
:util-linux/*
* Provide the hwclock.sh script in util-linux-hwclock-init, which can be
pulled by any packages that depend on its functionality.
* util-linux-hwclock RDEPENDS on util-linux-hwclock-init for its
initscript.
Signed-off-by: Alex Stewart <alex.stew...@ni.com>
Acked-by: Haris Okanovic <haris.okano...@ni.com>
Acked-by: Adrian Ratiu <adrian.ra...@ni.com>
Acked-by: Ken Sharp <ken.sh...@ni.com>
Natinst-ReviewBoard-ID: 214983, 215755
---
meta/recipes-core/busybox/busybox.inc | 16 +++--
meta/recipes-core/busybox/busybox_1.27.2.bb| 1 -
meta/recipes-core/busybox/files/hwclock.sh | 83 --
meta/recipes-core/util-linux/util-linux.inc| 14 +++-
meta/recipes-core/util-linux/util-linux/hwclock.sh | 83 ++
meta/recipes-core/util-linux/util-linux_2.31.bb| 1 +
6 files changed, 105 insertions(+), 93 deletions(-)
delete mode 100644 meta/recipes-core/busybox/files/hwclock.sh
create mode 100644 meta/recipes-core/util-linux/util-linux/hwclock.sh
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 4012f921c6..d9c3c2793b 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -20,19 +20,17 @@ export EXTRA_LDFLAGS = "${LDFLAGS}"
EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH}
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}'
HOSTCPP='${BUILD_CPP}'"
-PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev"
FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf*
${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog"
FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf
${sysconfdir}/mdev/*"
FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
-FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
-INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev"
INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
-INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
INITSCRIPT_NAME_${PN}-mdev = "mdev"
INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
INITSCRIPT_NAME_${PN}-syslog = "syslog"
@@ -276,9 +274,6 @@ do_install () {
if grep "CONFIG_UDHCPD=y" ${B}/.config; then
install -m 0755 ${WORKDIR}/busybox-udhcpd
${D}${sysconfdir}/init.d/
fi
- if grep "CONFIG_HWCLOCK=y" ${B}/.config; then
- install -m 0755 ${WORKDIR}/hwclock.sh ${D}${sysconfdir}/init.d/
- fi
if grep "CONFIG_UDHCPC=y" ${B}/.config; then
install -d ${D}${sysconfdir}/udhcpc.d
install -d ${D}${datadir}/udhcpc
@@ -377,6 +372,13 @@ python do_package_prepend () {
else:
set_alternative_vars("${sysconfdir}/busybox.links.nosuid",
"${base_bindir}/busybox.nosuid")
set_alternative_vars("${sysconfdir}/busybox.links.suid",
"${base_bindir}/busybox.suid")
+
+# If busybox is configured to provide a hwclock implementation, add a
+# package dependency on util-linux-hwclock-init for the
+# /etc/init.d/hwclock.sh initscript.
+with open(d.getVar('B', expand=True) + '/.config', 'r') as fp_conf:
+if 'CONFIG_HWCLOCK=y' in fp_conf.read():
+d.appendVar('RDEPENDS_busybox', ' util-linux-hwclock-init ')
}
pkg_postinst_${PN} () {
diff --git a/meta/recipes-core/busybox/busybox_1.27.2.bb
b/meta/recipes-core/busybox/busybox_1.27.2.bb
index 6c1f4888cf..af2abadc5e 100644
--- a/meta/recipes-core/busybox/busybox_1.27.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.27.2.bb
@@ -8,7 +8,6 @@ SRC_URI =
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-udhcpd \
file://default.script \
file://simple.script \
- file://hwclock.sh \
file://mount.busybox \
file://syslog \
file:/
[OE-core] [PATCH] recipes-core: move hwclock.sh to util-linux
* Move the hwclock.sh initscript from the busybox recipe to util-linux.
This script is generally useful for distros that get their hwclock
implementation from sources other than busybox and we follow debian's
example by providing it in util-linux.
:busybox/*
* Remove the busybox-hwclock package, as it no longer has a purpose.
* If busybox is configured to include hwclock, the busybox package will
RDEPEND on util-linux-hwclock-init.
:util-linux/*
* Provide the hwclock.sh script in util-linux-hwclock-init, which can be
pulled by any packages that depend on its functionality.
* util-linux-hwclock RDEPENDS on util-linux-hwclock-init for its
initscript.
Signed-off-by: Alex Stewart <alex.stew...@ni.com>
Acked-by: Haris Okanovic <haris.okano...@ni.com>
Acked-by: Adrian Ratiu <adrian.ra...@ni.com>
Acked-by: Ken Sharp <ken.sh...@ni.com>
Natinst-ReviewBoard-ID: 214983, 215755
---
meta/recipes-core/busybox/busybox.inc| 16 +---
meta/recipes-core/busybox/busybox_1.27.2.bb | 1 -
meta/recipes-core/util-linux/util-linux.inc | 14 --
.../{busybox/files => util-linux/util-linux}/hwclock.sh | 0
meta/recipes-core/util-linux/util-linux_2.31.bb | 1 +
5 files changed, 22 insertions(+), 10 deletions(-)
rename meta/recipes-core/{busybox/files => util-linux/util-linux}/hwclock.sh
(100%)
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 4012f921c6..d9c3c2793b 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -20,19 +20,17 @@ export EXTRA_LDFLAGS = "${LDFLAGS}"
EXTRA_OEMAKE = "CC='${CC}' LD='${CCLD}' V=1 ARCH=${TARGET_ARCH}
CROSS_COMPILE=${TARGET_PREFIX} SKIP_STRIP=y HOSTCC='${BUILD_CC}'
HOSTCPP='${BUILD_CPP}'"
-PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev
${PN}-hwclock"
+PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev"
FILES_${PN}-httpd = "${sysconfdir}/init.d/busybox-httpd /srv/www"
FILES_${PN}-syslog = "${sysconfdir}/init.d/syslog*
${sysconfdir}/syslog-startup.conf* ${sysconfdir}/syslog.conf*
${systemd_unitdir}/system/syslog.service ${sysconfdir}/default/busybox-syslog"
FILES_${PN}-mdev = "${sysconfdir}/init.d/mdev ${sysconfdir}/mdev.conf
${sysconfdir}/mdev/*"
FILES_${PN}-udhcpd = "${sysconfdir}/init.d/busybox-udhcpd"
FILES_${PN}-udhcpc = "${sysconfdir}/udhcpc.d ${datadir}/udhcpc"
-FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
-INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev
${PN}-hwclock"
+INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev"
INITSCRIPT_NAME_${PN}-httpd = "busybox-httpd"
-INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
INITSCRIPT_NAME_${PN}-mdev = "mdev"
INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
INITSCRIPT_NAME_${PN}-syslog = "syslog"
@@ -276,9 +274,6 @@ do_install () {
if grep "CONFIG_UDHCPD=y" ${B}/.config; then
install -m 0755 ${WORKDIR}/busybox-udhcpd
${D}${sysconfdir}/init.d/
fi
- if grep "CONFIG_HWCLOCK=y" ${B}/.config; then
- install -m 0755 ${WORKDIR}/hwclock.sh ${D}${sysconfdir}/init.d/
- fi
if grep "CONFIG_UDHCPC=y" ${B}/.config; then
install -d ${D}${sysconfdir}/udhcpc.d
install -d ${D}${datadir}/udhcpc
@@ -377,6 +372,13 @@ python do_package_prepend () {
else:
set_alternative_vars("${sysconfdir}/busybox.links.nosuid",
"${base_bindir}/busybox.nosuid")
set_alternative_vars("${sysconfdir}/busybox.links.suid",
"${base_bindir}/busybox.suid")
+
+# If busybox is configured to provide a hwclock implementation, add a
+# package dependency on util-linux-hwclock-init for the
+# /etc/init.d/hwclock.sh initscript.
+with open(d.getVar('B', expand=True) + '/.config', 'r') as fp_conf:
+if 'CONFIG_HWCLOCK=y' in fp_conf.read():
+d.appendVar('RDEPENDS_busybox', ' util-linux-hwclock-init ')
}
pkg_postinst_${PN} () {
diff --git a/meta/recipes-core/busybox/busybox_1.27.2.bb
b/meta/recipes-core/busybox/busybox_1.27.2.bb
index 6c1f4888cf..af2abadc5e 100644
--- a/meta/recipes-core/busybox/busybox_1.27.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.27.2.bb
@@ -8,7 +8,6 @@ SRC_URI =
"http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://busybox-udhcpd \
file://default.script \
file://simple.script \
- file://hwclock.sh \
file://mount.busybox \
file://syslog \
file://syslog-startup.conf \
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/r
