Re: [OE-core] [pseudo][PATCH] pseudo_ipc.h: Fix enum typedef
Hi Peter,
On 5/3/20 6:26 PM, Seebs wrote:
On Sun, 3 May 2020 17:49:09 +0200
"Jacob Kroon" wrote:
The type has never been used, so an alternative fix would be to get
rid of it altogether, and just keep the enum identifiers.
I think I anticipated the type being used for something but it did
indeed not happen. It could also just be changed to 'enum [type]
{ ... }', I guess.
But I think your fix is the simplest and closest to what I probably
thought I was doing at the time.
Do you have any plans on merging this, and also the pending patches in
oe-core, anytime soon ? Then we could bump the pseudo git rev in oe-core
and remove those patches, if not then I can add the patch to the pseudo
recipe. Any way you'd prefer ?
/Jacob
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138050):
https://lists.openembedded.org/g/openembedded-core/message/138050
Mute This Topic: https://lists.openembedded.org/mt/73948932/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][zeus][PATCH] populate_sdk_base.bbclass: fix warning: name not matched
On 2020/5/8 上午11:04, Mittal, Anuj wrote:
Hi,
On Wed, 2020-05-06 at 01:46 -0700, wenlin.k...@windriver.com wrote:
Fix below warning:
zip warning: name not matched: sysroots/aarch64-wrs-
linux/etc/udev/rules.d/80-net-setup-link.rules
zip warning: name not matched: sysroots/aarch64-wrs-
linux/etc/tmpfiles.d/etc.conf
zip warning: name not matched: sysroots/aarch64-wrs-
linux/etc/tmpfiles.d/home.conf
zip warning: name not matched: sysroots/aarch64-wrs-
linux/etc/systemd/network/80-wired.network
zip warning: name not matched: sysroots/aarch64-wrs-
linux/etc/resolv.conf
zip warning: name not matched: sysroots/aarch64-wrs-linux/etc/mtab
zip warning: name not matched: sysroots/aarch64-wrs-linux/etc/resolv-
conf.systemd
zip warning: name not matched: sysroots/aarch64-wrs-linux/var/lock
Is this specific to zeus? I don't see this change in master/dunfell.
It'd be great if you could include more details in commit message
explaining what is happening.
No, this issue can be seen in master too, but this patch is only to
zeus, for master, I have sent patch too.
Steps:
1. Setup poky[zeus]project
2. In local.conf, add:
SDK_ARCHIVE_TYPE = "zip"
3. bitbake core-image-minimal -c populate_sdk
4. check log file log.do_populate_sdk
Thanks,
Anuj
Signed-off-by: Wenlin Kang
---
meta/classes/populate_sdk_base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index d03465b6fc..b5c004d832 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -55,7 +55,7 @@ python () {
d.setVar('SDK_ARCHIVE_DEPENDS', 'zip-native')
# SDK_ARCHIVE_CMD used to generate archived sdk
${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} from input dir
${SDK_OUTPUT}/${SDKPATH} to output dir ${SDKDEPLOYDIR}
# recommand to cd into input dir first to avoid archive with
buildpath
- d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip
-r ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .')
+ d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip
-r -y ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .')
else:
d.setVar('SDK_ARCHIVE_DEPENDS', 'xz-native')
d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar
${SDKTAROPTS} -cf - . | xz -T 0 -9 >
${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
--
Thanks,
Wenlin Kang
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138049):
https://lists.openembedded.org/g/openembedded-core/message/138049
Mute This Topic: https://lists.openembedded.org/mt/74024894/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] iproute2.inc: clean .o before do_configure
On 5/7/20 2:19 PM, Jacob Kroon wrote:
On 5/7/20 8:10 AM, Changqing Li wrote:
On 5/7/20 1:56 PM, Jacob Kroon wrote:
On 5/7/20 4:05 AM, Changqing Li wrote:
From: Changqing Li
Reproduce steps:
1. add 'DISTRO_FEATURES_append = ' usrmerge'' in local.conf
2. bitbake iproute2
3. remove 'DISTRO_FEATURES_append = ' usrmerge'' from local.conf
4. bitbake iproute2
In step4, since CLEANBROKEN is set, files generated in step2 is not
cleaned and rebuilded. Check after step4:
file /sbin/ip.iproute2
/sbin/ip.iproute2: ELF 64-bit LSB pie executable, x86-64, version 1
(SYSV), dynamically linked, interpreter
/usr/lib64/ld-linux-x86-64.so.2,
interpreter path is wrong, it should be /lib64/ld-linux-x86-64.so.2
This will make run ip.iproute2 report error:
-sh: /sbin/ip.iproute2: No such file or directory
Signed-off-by: Changqing Li
---
meta/recipes-connectivity/iproute2/iproute2.inc | 4
1 file changed, 4 insertions(+)
Isn't this a general problem, and not specific to just iproute2 ?
For those recipe ${B} != ${S} , ${B} will be cleaned, will not
have this problem.
and by default, CLEANBROKEN is not set, make clean will be executed.
but for this specific recipe, both condition not matched.
btrfs-tools inherits autotools-brokensep and sets CLEANBROKEN = "1",
will it also require a similar fix ?
In theory， btrfs-tools and other recipes like this will met similar
problem.
But I tested on btrfs-tools, it don't met problem even without clean,
since some dependency changed, so
binary btrfs also recompiled. so this is also related to respective
makefile.
And your suggestion to make it commons also make sense, in this way,
we need to
handle condition (${B} and ${S} is same,and CLEANBROKEN = "1")
in base.bbclass and autotools-brokensep.bbclass. But one problem here
is that
we have kinds of recipes, not all Intermediate file are *.o, how to
handle this, any suggestion?
or still handle this in seperate recipes?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138048):
https://lists.openembedded.org/g/openembedded-core/message/138048
Mute This Topic: https://lists.openembedded.org/mt/74043158/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][zeus][PATCH] populate_sdk_base.bbclass: fix warning: name not matched
Hi,
On Wed, 2020-05-06 at 01:46 -0700, wenlin.k...@windriver.com wrote:
> Fix below warning:
> zip warning: name not matched: sysroots/aarch64-wrs-
> linux/etc/udev/rules.d/80-net-setup-link.rules
> zip warning: name not matched: sysroots/aarch64-wrs-
> linux/etc/tmpfiles.d/etc.conf
> zip warning: name not matched: sysroots/aarch64-wrs-
> linux/etc/tmpfiles.d/home.conf
> zip warning: name not matched: sysroots/aarch64-wrs-
> linux/etc/systemd/network/80-wired.network
> zip warning: name not matched: sysroots/aarch64-wrs-
> linux/etc/resolv.conf
> zip warning: name not matched: sysroots/aarch64-wrs-linux/etc/mtab
> zip warning: name not matched: sysroots/aarch64-wrs-linux/etc/resolv-
> conf.systemd
> zip warning: name not matched: sysroots/aarch64-wrs-linux/var/lock
>
Is this specific to zeus? I don't see this change in master/dunfell.
It'd be great if you could include more details in commit message
explaining what is happening.
Thanks,
Anuj
> Signed-off-by: Wenlin Kang
> ---
> meta/classes/populate_sdk_base.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/populate_sdk_base.bbclass
> b/meta/classes/populate_sdk_base.bbclass
> index d03465b6fc..b5c004d832 100644
> --- a/meta/classes/populate_sdk_base.bbclass
> +++ b/meta/classes/populate_sdk_base.bbclass
> @@ -55,7 +55,7 @@ python () {
> d.setVar('SDK_ARCHIVE_DEPENDS', 'zip-native')
> # SDK_ARCHIVE_CMD used to generate archived sdk
> ${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} from input dir
> ${SDK_OUTPUT}/${SDKPATH} to output dir ${SDKDEPLOYDIR}
> # recommand to cd into input dir first to avoid archive with
> buildpath
> - d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip
> -r ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .')
> + d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip
> -r -y ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .')
> else:
> d.setVar('SDK_ARCHIVE_DEPENDS', 'xz-native')
> d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar
> ${SDKTAROPTS} -cf - . | xz -T 0 -9 >
> ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138047):
https://lists.openembedded.org/g/openembedded-core/message/138047
Mute This Topic: https://lists.openembedded.org/mt/74024894/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] ✗ patchtest: failure for update default rpm prefer_color
== Series Details == Series: update default rpm prefer_color Revision: 1 URL : https://patchwork.openembedded.org/series/24018/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at e604e9d234) * Issue Added patch file is missing Upstream-Status in the header [test_upstream_status_presence_format] Suggested fixAdd Upstream-Status: to the header of meta/recipes-devtools/rpm/files/0001-lib-transaction.c-fix-file-conflicts-for-MIPS64-N32.patch Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138046): https://lists.openembedded.org/g/openembedded-core/message/138046 Mute This Topic: https://lists.openembedded.org/mt/74065675/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/2] rpm: fix file conflicts for MIPS64 N32
From: Changqing Li
The following error occurred when prefer_color set to 2:
Error: Transaction check error:
file /sbin/ldconfig conflicts between attempted installs of
ldconfig-2.31+git0+71f2b249a2-r0.mips64_n32 and
lib32-ldconfig-2.31+git0+71f2b249a2-r0.mips32r2
file /usr/bin/gencat conflicts between attempted installs of
lib32-libc6-utils-2.31+git0+71f2b249a2-r0.mips32r2
...
This was because:
transactions_color = 001 (ELF32) & 010 (ELF64) & 100 (ELF32 N32 MIPS64)
FColor = Current file color (001) & transaction_color (111)
oFcolor = Previous file color (100) & transaction_color (111)
when "neither preferred" happened, handled as conflicts. this is too
restrictive for three way conflicts(mips64/mips64 n32/mips(32)).
Fixed by perform a 'last-in-wins' resolution when "neither is preferred".
refer:
https://github.com/rpm-software-management/rpm/issues/193
https://git.openembedded.org/openembedded-core/commit/meta/recipes-devtools/rpm?id=36c225704daa58b98a4b7f2ef315eb944d8628b5
Signed-off-by: Changqing Li
---
...ction.c-fix-file-conflicts-for-MIPS64-N32.patch | 58 ++
meta/recipes-devtools/rpm/rpm_4.14.2.1.bb | 1 +
2 files changed, 59 insertions(+)
create mode 100644
meta/recipes-devtools/rpm/files/0001-lib-transaction.c-fix-file-conflicts-for-MIPS64-N32.patch
diff --git
a/meta/recipes-devtools/rpm/files/0001-lib-transaction.c-fix-file-conflicts-for-MIPS64-N32.patch
b/meta/recipes-devtools/rpm/files/0001-lib-transaction.c-fix-file-conflicts-for-MIPS64-N32.patch
new file mode 100644
index 000..b515075
--- /dev/null
+++
b/meta/recipes-devtools/rpm/files/0001-lib-transaction.c-fix-file-conflicts-for-MIPS64-N32.patch
@@ -0,0 +1,58 @@
+From 1ed066fc6fa7d7afffe3545c4e3ea937529e6c49 Mon Sep 17 00:00:00 2001
+From: Changqing Li
+Date: Thu, 7 May 2020 17:40:58 +0800
+Subject: [PATCH] lib/transaction.c: fix file conflicts for MIPS64 N32
+
+This patch is from:
+https://github.com/rpm-software-management/rpm/issues/193
+
+Error: Transaction check error:
+ file /sbin/ldconfig conflicts between attempted installs of
+ldconfig-2.31+git0+71f2b249a2-r0.mips64_n32 and
+lib32-ldconfig-2.31+git0+71f2b249a2-r0.mips32r2
+...
+
+This was because:
+transactions_color = 001 (ELF32) & 010 (ELF64) & 100 (ELF32 N32 MIPS64)
+FColor = Current file color (001) & transaction_color (111)
+oFcolor = Previous file color (100) & transaction_color (111)
+
+In handleColorConflict, it only deal with conditons "new preferred" or
+"old preferred". But not deal with the situation where neither is the
+preferred type. so for tri-lib system, like mips64/mips64 n32/mips(32),
+"Transaction check error" occurred.
+
+Fixed by performing a 'last-in-wins' resolution when "neither is preferred".
+
+Signed-off-by: Changqing Li
+---
+ lib/transaction.c | 13 -
+ 1 file changed, 12 insertions(+), 1 deletion(-)
+
+diff --git a/lib/transaction.c b/lib/transaction.c
+index 67b9db5..82386b8 100644
+--- a/lib/transaction.c
b/lib/transaction.c
+@@ -391,7 +391,18 @@ static int handleColorConflict(rpmts ts,
+ rpmfsSetAction(ofs, ofx, FA_CREATE);
+ rpmfsSetAction(fs, fx, FA_SKIPCOLOR);
+ rConflicts = 0;
+- }
++ }else {
++/*
++ * If neither is already skipped, we skip the old one, and
++ * install the new one (last in wins).
++ */
++if (ofs && !XFA_SKIPPING(rpmfsGetAction(ofs, ofx)) &&
++fs && !XFA_SKIPPING(rpmfsGetAction(fs, fx))) {
++rpmfsSetAction(ofs, ofx, FA_SKIPCOLOR);
++rpmfsSetAction(fs, fx, FA_CREATE);
++}
++rConflicts = 0;
++}
+ }
+ }
+
+--
+2.7.4
+
diff --git a/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
b/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
index 17255dc..3e2c6d1 100644
--- a/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
@@ -44,6 +44,7 @@ SRC_URI =
"git://github.com/rpm-software-management/rpm;branch=rpm-4.14.x \
file://0001-mono-find-provides-requires-do-not-use-monodis-from-.patch \
file://0001-Rip-out-partial-support-for-unused-MD2-and-RIPEMD160.patch \
file://0001-rpmplugins.c-call-dlerror-prior-to-dlsym.patch \
+
file://0001-lib-transaction.c-fix-file-conflicts-for-MIPS64-N32.patch \
"
PE = "1"
--
2.7.4
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138045):
https://lists.openembedded.org/g/openembedded-core/message/138045
Mute This Topic: https://lists.openembedded.org/mt/74065313/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [V2][PATCH 0/2] update default rpm prefer_color
From: Changqing Li * 0001-lib-oe-package_manager-update-default-rpm-config-_pr.patch update prefer_color to rpm default value 2 * 0002-rpm-fix-file-conflicts-for-MIPS64-N32.patch handle 3 ways conflicts when prefer_color is updated to 2 Changqing Li (2): lib/oe/package_manager: update default rpm config %_prefer_color rpm: fix file conflicts for MIPS64 N32 meta/lib/oe/package_manager.py | 2 - ...ction.c-fix-file-conflicts-for-MIPS64-N32.patch | 58 ++ meta/recipes-devtools/rpm/rpm_4.14.2.1.bb | 1 + 3 files changed, 59 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/rpm/files/0001-lib-transaction.c-fix-file-conflicts-for-MIPS64-N32.patch -- 2.7.4 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138043): https://lists.openembedded.org/g/openembedded-core/message/138043 Mute This Topic: https://lists.openembedded.org/mt/74065305/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 1/2] lib/oe/package_manager: update default rpm config %_prefer_color
From: Changqing Li
* %_prefer_color is used by rpm to determine which color's ELF file
is preferred to be installed.
Here are file colors:
0 is unknown or other
1 is Elf32
2 is Elf64
4 is MIPS64 n32 (this color is added by oe-core's patch)
if default value set to 7, all colors are preferred color, always
be last-in-wins.
For this scenario, when we have 64bits python3 installed first,
then install 32bits python3 later, 64bits python3 will be overwrited,
and sys.path will point to /usr/lib, not /usr/lib64, this may cause
some python3 modules not work. so fixed by remove setting of default
value 7, and use default value 2 of rpm
* other distro like fedora also use the default %_prefer_color 2
Signed-off-by: Changqing Li
---
meta/lib/oe/package_manager.py | 2 --
1 file changed, 2 deletions(-)
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index b066041..c055d2b 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -805,8 +805,6 @@ class RpmPM(PackageManager):
open(platformconfdir + "macros", 'w').write("%_transaction_color 7\n")
if self.d.getVar('RPM_PREFER_ELF_ARCH'):
open(platformconfdir + "macros", 'a').write("%%_prefer_color %s" %
(self.d.getVar('RPM_PREFER_ELF_ARCH')))
-else:
-open(platformconfdir + "macros", 'a').write("%_prefer_color 7")
if self.d.getVar('RPM_SIGN_PACKAGES') == '1':
signer = get_signer(self.d, self.d.getVar('RPM_GPG_BACKEND'))
--
2.7.4
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138044):
https://lists.openembedded.org/g/openembedded-core/message/138044
Mute This Topic: https://lists.openembedded.org/mt/74065306/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 2/2] encodings: RDEPEND on mkfontdir mkfontscale
On 5/7/20 6:43 PM, Richard Purdie wrote:
On Thu, 2020-05-07 at 15:45 +0800, Yi Zhao wrote:
Fix pkg_postinst error when install encodings via online repo:
$ opkg install encodings
Installing encodings (1.0.5) on root
Configuring encodings.
/var/lib/opkg/info/encodings.postinst: line 7: mkfontdir: not found
Collected errors:
* pkg_run_script: package "encodings" postinst script returned status 127.
* opkg_configure: encodings.postinst returned 127.
Signed-off-by: Yi Zhao
---
meta/recipes-graphics/xorg-font/encodings_1.0.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
b/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
index a39609b5da..b161a46982 100644
--- a/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
+++ b/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
@@ -10,7 +10,7 @@ PE = "1"
PR = "${INC_PR}.1"
DEPENDS = "mkfontscale-native mkfontdir-native font-util-native"
-RDEPENDS_${PN} = ""
+RDEPENDS_${PN} = "mkfontdir mkfontscale"
SRC_URI += "file://nocompiler.patch"
SRC_URI[md5sum] = "bbae4f247b88ccde0e85ed6a403da22a"
I don't think these two patches are correct. encodings doesn't install
these things so perhaps it shouldn't be running these postinst at all?
Yes, encdings doesn't need postinst at all.
//Yi
I thought I remembered something about this change:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b8f089512f65a4a131c8096c281c4f3d9cf23718
from 2013! Sadly the commit log is a bit sparse.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138042):
https://lists.openembedded.org/g/openembedded-core/message/138042
Mute This Topic: https://lists.openembedded.org/mt/74046130/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] populate_sdk_base: Add ld.so.conf for nativesdk-binutils
On Thu, May 7, 2020 at 4:02 PM Steve Sakoman wrote: > > On Thu, May 7, 2020 at 10:30 AM Denys Dmytriyenko wrote: > > > > On Thu, May 07, 2020 at 01:20:40PM -0700, Khem Raj wrote: > > > > > > > > > On 5/7/20 12:57 PM, Denys Dmytriyenko wrote: > > > > On Thu, May 07, 2020 at 12:44:15PM -0700, Khem Raj wrote: > > > >> > > > >> > > > >> On 5/3/20 3:51 PM, Steve Sakoman wrote: > > > >>> Should I consider these two patches for dunfell LTS? > > > >>> > > > >> > > > >> Yes I think they are fixing a problem and are safe. > > > > > > > > I don't think it is safe though! > > > > > > > > The code has been moved to create_sdk_files() which is a POSTPROCESS > > > > command > > > > for SDK creation. What if SDK already provides own /etc/ld.so.conf? The > > > > code > > > > just simply overwrites it. > > > > > > > > > > but are there such usecases ? looking closely if SDK is extending the > > > ld.so.conf then they should be appending to it instead of overwriting > > > and same is true for this patch for master. > > > > Exactly my point - should probably append, not overwrite. > > As of usecases - I can think of a non-standard nativesdk tool that adjusts > > /etc/ld.so.conf during install... > > I think you've convinced me to pass on this for dunfell (at least in > the short term) > > If a patch is submitted that appends rather than overwrites I'll > consider the series again once it makes it into master. > yes, I think that will be right thing to do although I think it fills in a good gap in dunfell but as it is might not work as expected. > If you submit such a patch please tag it with [dunfell] too. > > Thanks for the comments! > > Steve > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138041): https://lists.openembedded.org/g/openembedded-core/message/138041 Mute This Topic: https://lists.openembedded.org/mt/73326300/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] populate_sdk_base: Add ld.so.conf for nativesdk-binutils
On Thu, May 7, 2020 at 10:30 AM Denys Dmytriyenko wrote: > > On Thu, May 07, 2020 at 01:20:40PM -0700, Khem Raj wrote: > > > > > > On 5/7/20 12:57 PM, Denys Dmytriyenko wrote: > > > On Thu, May 07, 2020 at 12:44:15PM -0700, Khem Raj wrote: > > >> > > >> > > >> On 5/3/20 3:51 PM, Steve Sakoman wrote: > > >>> Should I consider these two patches for dunfell LTS? > > >>> > > >> > > >> Yes I think they are fixing a problem and are safe. > > > > > > I don't think it is safe though! > > > > > > The code has been moved to create_sdk_files() which is a POSTPROCESS > > > command > > > for SDK creation. What if SDK already provides own /etc/ld.so.conf? The > > > code > > > just simply overwrites it. > > > > > > > but are there such usecases ? looking closely if SDK is extending the > > ld.so.conf then they should be appending to it instead of overwriting > > and same is true for this patch for master. > > Exactly my point - should probably append, not overwrite. > As of usecases - I can think of a non-standard nativesdk tool that adjusts > /etc/ld.so.conf during install... I think you've convinced me to pass on this for dunfell (at least in the short term) If a patch is submitted that appends rather than overwrites I'll consider the series again once it makes it into master. If you submit such a patch please tag it with [dunfell] too. Thanks for the comments! Steve > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138040): https://lists.openembedded.org/g/openembedded-core/message/138040 Mute This Topic: https://lists.openembedded.org/mt/73326300/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] populate_sdk_base: Add ld.so.conf for nativesdk-binutils
On Thu, May 07, 2020 at 01:20:40PM -0700, Khem Raj wrote: > > > On 5/7/20 12:57 PM, Denys Dmytriyenko wrote: > > On Thu, May 07, 2020 at 12:44:15PM -0700, Khem Raj wrote: > >> > >> > >> On 5/3/20 3:51 PM, Steve Sakoman wrote: > >>> Should I consider these two patches for dunfell LTS? > >>> > >> > >> Yes I think they are fixing a problem and are safe. > > > > I don't think it is safe though! > > > > The code has been moved to create_sdk_files() which is a POSTPROCESS > > command > > for SDK creation. What if SDK already provides own /etc/ld.so.conf? The > > code > > just simply overwrites it. > > > > but are there such usecases ? looking closely if SDK is extending the > ld.so.conf then they should be appending to it instead of overwriting > and same is true for this patch for master. Exactly my point - should probably append, not overwrite. As of usecases - I can think of a non-standard nativesdk tool that adjusts /etc/ld.so.conf during install... -- Denys -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138039): https://lists.openembedded.org/g/openembedded-core/message/138039 Mute This Topic: https://lists.openembedded.org/mt/73326300/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] populate_sdk_base: Add ld.so.conf for nativesdk-binutils
On 5/7/20 12:57 PM, Denys Dmytriyenko wrote: > On Thu, May 07, 2020 at 12:44:15PM -0700, Khem Raj wrote: >> >> >> On 5/3/20 3:51 PM, Steve Sakoman wrote: >>> Should I consider these two patches for dunfell LTS? >>> >> >> Yes I think they are fixing a problem and are safe. > > I don't think it is safe though! > > The code has been moved to create_sdk_files() which is a POSTPROCESS command > for SDK creation. What if SDK already provides own /etc/ld.so.conf? The code > just simply overwrites it. > but are there such usecases ? looking closely if SDK is extending the ld.so.conf then they should be appending to it instead of overwriting and same is true for this patch for master. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138038): https://lists.openembedded.org/g/openembedded-core/message/138038 Mute This Topic: https://lists.openembedded.org/mt/73326300/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] insane: Promote warnings into errors
On 5/6/20 6:40 AM, Richard Purdie wrote:
> There are several warnings the build can emit which show real problems
> in the way recipes are being built. Some distros like poky and the Yocto
> Project autobuilder have been fixing the issues these show for some time.
>
> OE-Core has therefore been clean of these errors and warnings for some time.
> Promote warnings into errors to match the defaults in poky to encourage
> people to fix these real issue and reduce confusion when people switch
> distros or customise.
This is a good change, and I think all settings used in poky in this
regard are worth for OE-core.
>
> Signed-off-by: Richard Purdie
> ---
> meta/classes/insane.bbclass | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 7fc8f33a982..8b19f445f9b 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -22,11 +22,9 @@ QA_SANE = "True"
>
> # Elect whether a given type of error is a warning or error, they may
> # have been set by other files.
> -WARN_QA ?= "ldflags useless-rpaths rpaths staticdev libdir xorg-driver-abi \
> -textrel already-stripped incompatible-license files-invalid \
> -installed-vs-shipped compile-host-path install-host-path \
> -pn-overrides infodir build-deps src-uri-bad \
> -unknown-configure-option symlink-to-sysroot multilib \
> +WARN_QA ?= " libdir xorg-driver-abi \
> +textrel incompatible-license files-invalid \
> +infodir build-deps src-uri-bad symlink-to-sysroot multilib \
> invalid-packageconfig host-user-contaminated uppercase-pn
> patch-fuzz \
> mime mime-xdg \
> "
> @@ -36,6 +34,9 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch
> pkgconfig la \
> version-going-backwards expanded-d invalid-chars \
> license-checksum dev-elf file-rdeps configure-unsafe \
> configure-gettext perllocalpod shebang-size \
> +already-stripped installed-vs-shipped ldflags compile-host-path \
> +install-host-path pn-overrides unknown-configure-option \
> +useless-rpaths rpaths staticdev \
> "
> # Add usrmerge QA check based on distro feature
> ERROR_QA_append = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '
> usrmerge', '', d)}"
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138037):
https://lists.openembedded.org/g/openembedded-core/message/138037
Mute This Topic: https://lists.openembedded.org/mt/74028466/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] dtc: update to 1.6.0
On 5/6/20 12:10 AM, Adrian Bunk wrote:
> On Tue, May 05, 2020 at 01:55:35PM +0200, Richard Leitner wrote:
>> ...
>> --- a/meta/recipes-kernel/dtc/dtc_1.5.1.bb
>> +++ b/meta/recipes-kernel/dtc/dtc_1.6.0.bb
>> @@ -3,7 +3,7 @@ require dtc.inc
>> LIC_FILES_CHKSUM = "file://GPL;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
>>
>> file://libfdt/libfdt.h;beginline=4;endline=7;md5=05bb357cfb75cae7d2b01d2ee8d76407"
>>
>> -SRCREV = "60e0db3d65a1218b0d5a29474e769f28a18e3ca6"
>> +SRCREV = "v${PV}"
>> ...
>
> It is tempting to use tags, but it is a bad idea.
> Upstream might move a tag to a different commit.
> Someone might do a man-in-the-middle attack on a specific user,
> and there is no other verification of the sources apart from
> the commit hash.
>
moreover bitbake will still need to enquire the repository since tags
are floating revisions. and this might fail to work if network does not
allow access to internet etc. This is a good document describing the problem
https://pelux.io/software-factory/PELUX-3.0/swf-blueprint/docs/articles/baseplatform/reproducible-yocto-builds.html
> cu
> Adrian
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138036):
https://lists.openembedded.org/g/openembedded-core/message/138036
Mute This Topic: https://lists.openembedded.org/mt/73995755/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] populate_sdk_base: Add ld.so.conf for nativesdk-binutils
On Thu, May 07, 2020 at 12:44:15PM -0700, Khem Raj wrote:
>
>
> On 5/3/20 3:51 PM, Steve Sakoman wrote:
> > Should I consider these two patches for dunfell LTS?
> >
>
> Yes I think they are fixing a problem and are safe.
I don't think it is safe though!
The code has been moved to create_sdk_files() which is a POSTPROCESS command
for SDK creation. What if SDK already provides own /etc/ld.so.conf? The code
just simply overwrites it.
--
Denys
> > Thanks!
> >
> > Steve
> >
> > On Tue, Apr 28, 2020 at 2:59 AM Ovidiu Panait
> > wrote:
> >>
> >> Extend the functionality provided by commit [1] to the SDK as well. This
> >> way we
> >> can make sure that nativesdk-binutils finds SDK libraries first rather than
> >> host ones.
> >>
> >> This is useful for example when trying to build the linux kernel using
> >> nativesdk-gcc. This scenario currently fails because it tries to link to
> >> host
> >> libraries rather than SDK host ones:
> >>
> >> make x86_64_defconfig
> >> make bzImage
> >> ...
> >> error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please
> >> install libelf-dev, libelf-devel or elfutils-libelf-devel
> >> Makefile:1101: recipe for target 'prepare-objtool' failed
> >> make: *** [prepare-objtool] Error 1
> >>
> >> /../../../../x86_64-wrlinuxsdk-linux/bin/ld:
> >> /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to
> >> `__libc_vfork@GLIBC_PRIVATE'
> >> ...
> >>
> >> [1] 15049c610b [buildtools-tarball: Add an ld.so.conf for
> >> nativesdk-binutils]
> >>
> >> Signed-off-by: Ovidiu Panait
> >> ---
> >> meta/classes/populate_sdk_base.bbclass | 5 +
> >> meta/recipes-core/meta/buildtools-tarball.bb | 4
> >> 2 files changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/meta/classes/populate_sdk_base.bbclass
> >> b/meta/classes/populate_sdk_base.bbclass
> >> index ef0d8bef58..6a1ebc8c02 100644
> >> --- a/meta/classes/populate_sdk_base.bbclass
> >> +++ b/meta/classes/populate_sdk_base.bbclass
> >> @@ -185,6 +185,11 @@ fakeroot create_sdk_files() {
> >> # Escape special characters like '+' and '.' in the SDKPATH
> >> escaped_sdkpath=$(echo ${SDKPATH} |sed -e "s:[\+\.]:\0:g")
> >> sed -i -e "s:##DEFAULT_INSTALL_DIR##:$escaped_sdkpath:"
> >> ${SDK_OUTPUT}/${SDKPATH}/relocate_sdk.py
> >> +
> >> + mkdir -p ${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/
> >> + echo '${SDKPATHNATIVE}${libdir}
> >> +${SDKPATHNATIVE}${base_libdir}
> >> +include /etc/ld.so.conf' >
> >> ${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/ld.so.conf
> >> }
> >>
> >> python check_sdk_sysroots() {
> >> diff --git a/meta/recipes-core/meta/buildtools-tarball.bb
> >> b/meta/recipes-core/meta/buildtools-tarball.bb
> >> index 977b6a5e1d..c49802eef8 100644
> >> --- a/meta/recipes-core/meta/buildtools-tarball.bb
> >> +++ b/meta/recipes-core/meta/buildtools-tarball.bb
> >> @@ -76,10 +76,6 @@ create_sdk_files_append () {
> >> echo 'export
> >> GIT_SSL_CAINFO="${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt"'
> >> >>$script
> >> echo 'export
> >> OPENSSL_CONF="${SDKPATHNATIVE}${sysconfdir}/ssl/openssl.cnf"' >>$script
> >>
> >> - mkdir -p ${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/
> >> - echo '${SDKPATHNATIVE}${libdir}
> >> -${SDKPATHNATIVE}${base_libdir}
> >> -include /etc/ld.so.conf' >
> >> ${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/ld.so.conf
> >> if [ "${SDKMACHINE}" = "i686" ]; then
> >> echo 'export NO32LIBS="0"' >>$script
> >> echo 'echo "$BB_ENV_EXTRAWHITE" | grep -q "NO32LIBS"'
> >> >>$script
> >> --
> >> 2.17.1
> >>
> >>
> >>
> >>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138035):
https://lists.openembedded.org/g/openembedded-core/message/138035
Mute This Topic: https://lists.openembedded.org/mt/73326300/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] populate_sdk_base: Add ld.so.conf for nativesdk-binutils
On 5/3/20 3:51 PM, Steve Sakoman wrote:
> Should I consider these two patches for dunfell LTS?
>
Yes I think they are fixing a problem and are safe.
> Thanks!
>
> Steve
>
> On Tue, Apr 28, 2020 at 2:59 AM Ovidiu Panait
> wrote:
>>
>> Extend the functionality provided by commit [1] to the SDK as well. This way
>> we
>> can make sure that nativesdk-binutils finds SDK libraries first rather than
>> host ones.
>>
>> This is useful for example when trying to build the linux kernel using
>> nativesdk-gcc. This scenario currently fails because it tries to link to host
>> libraries rather than SDK host ones:
>>
>> make x86_64_defconfig
>> make bzImage
>> ...
>> error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please
>> install libelf-dev, libelf-devel or elfutils-libelf-devel
>> Makefile:1101: recipe for target 'prepare-objtool' failed
>> make: *** [prepare-objtool] Error 1
>>
>> /../../../../x86_64-wrlinuxsdk-linux/bin/ld:
>> /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to
>> `__libc_vfork@GLIBC_PRIVATE'
>> ...
>>
>> [1] 15049c610b [buildtools-tarball: Add an ld.so.conf for nativesdk-binutils]
>>
>> Signed-off-by: Ovidiu Panait
>> ---
>> meta/classes/populate_sdk_base.bbclass | 5 +
>> meta/recipes-core/meta/buildtools-tarball.bb | 4
>> 2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/meta/classes/populate_sdk_base.bbclass
>> b/meta/classes/populate_sdk_base.bbclass
>> index ef0d8bef58..6a1ebc8c02 100644
>> --- a/meta/classes/populate_sdk_base.bbclass
>> +++ b/meta/classes/populate_sdk_base.bbclass
>> @@ -185,6 +185,11 @@ fakeroot create_sdk_files() {
>> # Escape special characters like '+' and '.' in the SDKPATH
>> escaped_sdkpath=$(echo ${SDKPATH} |sed -e "s:[\+\.]:\0:g")
>> sed -i -e "s:##DEFAULT_INSTALL_DIR##:$escaped_sdkpath:"
>> ${SDK_OUTPUT}/${SDKPATH}/relocate_sdk.py
>> +
>> + mkdir -p ${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/
>> + echo '${SDKPATHNATIVE}${libdir}
>> +${SDKPATHNATIVE}${base_libdir}
>> +include /etc/ld.so.conf' >
>> ${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/ld.so.conf
>> }
>>
>> python check_sdk_sysroots() {
>> diff --git a/meta/recipes-core/meta/buildtools-tarball.bb
>> b/meta/recipes-core/meta/buildtools-tarball.bb
>> index 977b6a5e1d..c49802eef8 100644
>> --- a/meta/recipes-core/meta/buildtools-tarball.bb
>> +++ b/meta/recipes-core/meta/buildtools-tarball.bb
>> @@ -76,10 +76,6 @@ create_sdk_files_append () {
>> echo 'export
>> GIT_SSL_CAINFO="${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt"'
>> >>$script
>> echo 'export
>> OPENSSL_CONF="${SDKPATHNATIVE}${sysconfdir}/ssl/openssl.cnf"' >>$script
>>
>> - mkdir -p ${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/
>> - echo '${SDKPATHNATIVE}${libdir}
>> -${SDKPATHNATIVE}${base_libdir}
>> -include /etc/ld.so.conf' >
>> ${SDK_OUTPUT}/${SDKPATHNATIVE}${sysconfdir}/ld.so.conf
>> if [ "${SDKMACHINE}" = "i686" ]; then
>> echo 'export NO32LIBS="0"' >>$script
>> echo 'echo "$BB_ENV_EXTRAWHITE" | grep -q "NO32LIBS"'
>> >>$script
>> --
>> 2.17.1
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138034):
https://lists.openembedded.org/g/openembedded-core/message/138034
Mute This Topic: https://lists.openembedded.org/mt/73326300/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 0/5] linux-yocto: consolidated pull request
On Thu, May 7, 2020 at 2:15 PM Steve Sakoman wrote: > > From the discussion to this point it seems that these patches aren't > quite ready for dunfell. Let me know if/when that changes, or if I'm > mistaken in that assumption! Richard merged 3 of the 4 kernel updates (up to v5.4.34), so they are ok for dunfell. There's just a reproducible issue that we have to look into more (there's no runtime issues with any of them). Bruce > > Steve > > On Mon, May 4, 2020 at 3:34 AM Bruce Ashfield > wrote: > > > > On Mon, May 4, 2020 at 9:24 AM Richard Purdie > > wrote: > > > > > > On Mon, 2020-05-04 at 09:06 -0400, Bruce Ashfield wrote: > > > > On Mon, May 4, 2020 at 8:56 AM Bruce Ashfield via > > > > lists.openembedded.org > > > > wrote: > > > > > On Mon, May 4, 2020 at 4:31 AM Richard Purdie > > > > > wrote: > > > > > > Hi Bruce, > > > > > > > > > > > > On Sun, 2020-05-03 at 11:44 -0400, bruce.ashfi...@gmail.com wrote: > > > > > > > From: Bruce Ashfield > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > Here are the -stable updates I've collected since m3 of dunfell. I > > > > > > > ran things through the autobuilder, and no new kernel issues were > > > > > > > picked up. > > > > > > > > > > > > > > The -dev bump is good for master, while all of the 5.4-stable > > > > > > > bumps > > > > > > > are good for both master and dunfell. > > > > > > > > > > > > I pulled these into master-next and saw reproducibility issues. I > > > > > > wondered why your test build didn't show it, turns out it also did: > > > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/1024 > > > > > > > > > > > > 2020-05-04 05:18:46,863 - oe-selftest - INFO - > > > > > > == > > > > > > 2020-05-04 05:18:46,863 - oe-selftest - INFO - FAIL: > > > > > > reproducible.ReproducibleTests.test_reproducible_builds > > > > > > (subunit.RemotedTestCase) > > > > > > 2020-05-04 05:18:46,863 - oe-selftest - INFO - > > > > > > -- > > > > > > 2020-05-04 05:18:46,864 - oe-selftest - INFO - > > > > > > testtools.testresult.real._StringException: > > > > > > > > > > > > AssertionError: The following deb packages are missing or > > > > > > different: > > > > > > /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-36044/reproducibleB/tmp/deploy/deb/./qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38+git0+f405543442_6cb5b11e83-r0_amd64.deb > > > > > > The following ipk packages are missing or different: > > > > > > /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-36044/reproducibleB/tmp/deploy/ipk/./qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38+git0+f405543442_6cb5b11e83-r0_qemux86_64.ipk > > > > > > > > > > > > > > > > I don't see any changes in the kernels that would have triggered it, > > > > > but they never are obvious. > > > > > > > > I am working on some kernel reproducibility changes that were > > > > discussed about three weeks ago. > > > > > > > > Is the default for reproducible builds in master-next different from > > > > what it was before dunfell was releases ? If so, that might explain > > > > why I'm not seeing a change that would have triggered it (i.e. this is > > > > unrelated to my -stable changes). > > > > > > There are no reproducibility changes between master-next and dunfell. > > > > interesting. I'll take a closer look at the changes again and see what > > might pop up as a culprit. > > > > > > > > > Like I was mentioning before, if there's a document or pastebin of > > > > steps I can follow, I can run the tests against my pending changes and > > > > finish them for master. They of course would not necessarily be > > > > suitable for dunfell. > > > > > > The good news is the autobuilder has some debugging built in for this > > > kind of problem. You can see the diffoscope output here: > > > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200504-vhr0o_t9/packages/diff-html/ > > > > > > which tells us its kheaders.ko in .rodata by the looks of it. Some > > > changes are cause, some are effect, e.g. the build ID is different as > > > the sections are different so that isn't the issue but an effect of it. > > > It looks like diffoscope doesn't know how to decode the .rodata which > > > could be compressed? > > > > > > The raw data is also there (the packages that differ), e.g.: > > > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200504-vhr0o_t9/packages/reproducibleA/tmp/deploy/deb/qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38%2Bgit0%2Bf405543442_6cb5b11e83-r0_amd64.deb > > > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200504-vhr0o_t9/packages/reproducibleB/tmp/deploy/deb/qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38%2Bgit0%2Bf405543442_6cb5b11e83-r0_amd64.debe > > > > > > > cool. That's definitely
Re: [OE-core] [PATCH v3 2/4] libva-initial: New bootstrap recipe
On 5/7/20 6:32 AM, Zoltan Boszormenyi via lists.openembedded.org wrote:
> Mesa needs libva.pc and libva headers to enable the VAAPI
> state tracker and drivers.
>
> This recipe is a variant of the full libva package build as in:
> * it only depends on libdrm to build so it doesn't introduce
> the circular dependency between mesa and libva, and
> * it doesn't include the libraries in the final package.
>
> However, there is another issue with build dependency handling
> in Yocto. libva depends on mesa and mesa depends on this package.
> Any package that depends on libva therefore would pull in libva
> and this package resulting in an error in the prepare-sysroot
> phase because they would install identical files into the
> per-recipe sysroot.
>
> Using the package name "*-initial" avoids this because of the
> interaction between sstate.bbclass and staging.bbclass: any
> package with the pattern "*-initial" in the name is excluded
> from the dependency list unless explicitly added to DEPENDS.
>
> Signed-off-by: Böszörményi Zoltán
> ---
> v2: The include file is not versioned, more verbose commit message
> v3: Rebased to current master
>
> meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 9 +
> meta/recipes-graphics/libva/libva.inc | 4 +++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
> create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>
> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> new file mode 100644
> index 00..a3b04eb02a
> --- /dev/null
> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
> @@ -0,0 +1,9 @@
> +require libva-${PV}.inc
this require seems should be just libva.inc
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
> +SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
> +SRC_URI[sha256sum] =
> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
> +
> +do_install_append () {
> + rm -f ${D}${libdir}/*.so*
> +}
> diff --git a/meta/recipes-graphics/libva/libva.inc
> b/meta/recipes-graphics/libva/libva.inc
> index e03451240c..ac39e92de7 100644
> --- a/meta/recipes-graphics/libva/libva.inc
> +++ b/meta/recipes-graphics/libva/libva.inc
> @@ -16,7 +16,9 @@ BUGTRACKER = "https://github.com/intel/libva/issues";
> SECTION = "x11"
> LICENSE = "MIT"
>
> -SRC_URI =
> "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2";
> +SRC_URI =
> "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2";
> +
> +S = "${WORKDIR}/libva-${PV}"
>
> UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases";
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138032):
https://lists.openembedded.org/g/openembedded-core/message/138032
Mute This Topic: https://lists.openembedded.org/mt/74050176/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 0/5] linux-yocto: consolidated pull request
>From the discussion to this point it seems that these patches aren't quite ready for dunfell. Let me know if/when that changes, or if I'm mistaken in that assumption! Steve On Mon, May 4, 2020 at 3:34 AM Bruce Ashfield wrote: > > On Mon, May 4, 2020 at 9:24 AM Richard Purdie > wrote: > > > > On Mon, 2020-05-04 at 09:06 -0400, Bruce Ashfield wrote: > > > On Mon, May 4, 2020 at 8:56 AM Bruce Ashfield via > > > lists.openembedded.org > > > wrote: > > > > On Mon, May 4, 2020 at 4:31 AM Richard Purdie > > > > wrote: > > > > > Hi Bruce, > > > > > > > > > > On Sun, 2020-05-03 at 11:44 -0400, bruce.ashfi...@gmail.com wrote: > > > > > > From: Bruce Ashfield > > > > > > > > > > > > Hi all, > > > > > > > > > > > > Here are the -stable updates I've collected since m3 of dunfell. I > > > > > > ran things through the autobuilder, and no new kernel issues were > > > > > > picked up. > > > > > > > > > > > > The -dev bump is good for master, while all of the 5.4-stable bumps > > > > > > are good for both master and dunfell. > > > > > > > > > > I pulled these into master-next and saw reproducibility issues. I > > > > > wondered why your test build didn't show it, turns out it also did: > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/1024 > > > > > > > > > > 2020-05-04 05:18:46,863 - oe-selftest - INFO - > > > > > == > > > > > 2020-05-04 05:18:46,863 - oe-selftest - INFO - FAIL: > > > > > reproducible.ReproducibleTests.test_reproducible_builds > > > > > (subunit.RemotedTestCase) > > > > > 2020-05-04 05:18:46,863 - oe-selftest - INFO - > > > > > -- > > > > > 2020-05-04 05:18:46,864 - oe-selftest - INFO - > > > > > testtools.testresult.real._StringException: > > > > > > > > > > AssertionError: The following deb packages are missing or different: > > > > > /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-36044/reproducibleB/tmp/deploy/deb/./qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38+git0+f405543442_6cb5b11e83-r0_amd64.deb > > > > > The following ipk packages are missing or different: > > > > > /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-36044/reproducibleB/tmp/deploy/ipk/./qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38+git0+f405543442_6cb5b11e83-r0_qemux86_64.ipk > > > > > > > > > > > > > I don't see any changes in the kernels that would have triggered it, > > > > but they never are obvious. > > > > > > I am working on some kernel reproducibility changes that were > > > discussed about three weeks ago. > > > > > > Is the default for reproducible builds in master-next different from > > > what it was before dunfell was releases ? If so, that might explain > > > why I'm not seeing a change that would have triggered it (i.e. this is > > > unrelated to my -stable changes). > > > > There are no reproducibility changes between master-next and dunfell. > > interesting. I'll take a closer look at the changes again and see what > might pop up as a culprit. > > > > > > Like I was mentioning before, if there's a document or pastebin of > > > steps I can follow, I can run the tests against my pending changes and > > > finish them for master. They of course would not necessarily be > > > suitable for dunfell. > > > > The good news is the autobuilder has some debugging built in for this > > kind of problem. You can see the diffoscope output here: > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200504-vhr0o_t9/packages/diff-html/ > > > > which tells us its kheaders.ko in .rodata by the looks of it. Some > > changes are cause, some are effect, e.g. the build ID is different as > > the sections are different so that isn't the issue but an effect of it. > > It looks like diffoscope doesn't know how to decode the .rodata which > > could be compressed? > > > > The raw data is also there (the packages that differ), e.g.: > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200504-vhr0o_t9/packages/reproducibleA/tmp/deploy/deb/qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38%2Bgit0%2Bf405543442_6cb5b11e83-r0_amd64.deb > > > > https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20200504-vhr0o_t9/packages/reproducibleB/tmp/deploy/deb/qemux86_64/kernel-module-kheaders-5.4.38-yocto-standard_5.4.38%2Bgit0%2Bf405543442_6cb5b11e83-r0_amd64.debe > > > > cool. That's definitely useful, I'll have a look. > > At the same time, I'll try and clean up the documented kernel > reproducible changes and trigger another run to see if they help. > > > which would allow you to look further at them by hand. > > > > You can manually run this test locally with: > > > > oe-selftest -r reproducible.ReproducibleTests.test_reproducible_builds > > > > but it will take a while to run as it has to run two builds and compare > > them and only uses sstate for one of t
[oe-core][PATCH 1/1] wget: improve reproducible build
Modify DEBUG_PREFIX_MAP as used by sed to handle whitespace correctly. This modifies an existing patch. Signed-off-by: Joe Slater --- .../wget/wget/0002-improve-reproducibility.patch | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/meta/recipes-extended/wget/wget/0002-improve-reproducibility.patch b/meta/recipes-extended/wget/wget/0002-improve-reproducibility.patch index 8781df2..050fc2c 100644 --- a/meta/recipes-extended/wget/wget/0002-improve-reproducibility.patch +++ b/meta/recipes-extended/wget/wget/0002-improve-reproducibility.patch @@ -34,6 +34,11 @@ Link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions Upstream-Status: Inappropriate [oe-core specific] Signed-off-by: Hongxu Jia + +sed use of DEBUG_PREFIX_MAP must treat whitespace the same as the +echo command building version.c or the expression match will fail. + +Signed-off-by: Joe Slater --- src/Makefile.am | 4 1 file changed, 4 insertions(+) @@ -47,12 +52,12 @@ index 28c0be2..44084a3 100644 echo 'const char *version_string = "@VERSION@";' >> $@ echo 'const char *compilation_string = "'$(COMPILE)'";' \ + | sed -e "s,$(TOOLCHAIN_OPTIONS),,g" \ -+-e "s,$(DEBUG_PREFIX_MAP),,g" \ ++-e "s,$$(echo $(DEBUG_PREFIX_MAP)),,g" \ | $(ESCAPEQUOTE) >> $@ echo 'const char *link_string = "'$(CCLD) $(AM_CFLAGS) $(CFLAGS) \ $(AM_LDFLAGS) $(LDFLAGS) $(LIBS) $(wget_LDADD)'";' \ + | sed -e "s,$(TOOLCHAIN_OPTIONS),,g" \ -+-e "s,$(DEBUG_PREFIX_MAP),,g" \ ++-e "s,$$(echo $(DEBUG_PREFIX_MAP)),,g" \ | $(ESCAPEQUOTE) >> $@ css.c: $(srcdir)/css.l -- 2.7.4 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138030): https://lists.openembedded.org/g/openembedded-core/message/138030 Mute This Topic: https://lists.openembedded.org/mt/74054509/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][zeus 00/18] zeus pull request - cover letter only
Please merge these changes in zeus. Clean a-full on autobuilder.
Thanks,
Anuj
The following changes since commit bd3e0d724004a346921a25defa6d812d48d6108a:
openssl: update to 1.1.1f (2020-04-20 19:26:57 -0700)
are available in the git repository at:
git://push.openembedded.org/openembedded-core-contrib stable/zeus-next
Adrian Bunk (1):
python: Upgrade 2.7.17 -> 2.17.18
Alex Kiernan (1):
gnutls: upgrade 3.6.8 -> 3.6.11.1
Alexander Kanavin (1):
gnutls: upgrade 3.6.11.1 -> 3.6.12
Changqing Li (1):
qemu: fix CVE-2020-7039
Chee Yang Lee (1):
qemu/slirp: fix CVE-2020-7211
Jan Luebbe (2):
apt-native: don't let dpkg overwrite files by default
openssl: upgrade 1.1.1f -> 1.1.1g
Jeremy Puhlman (1):
python3-native: Should not search the system for headers/libraries.
Khem Raj (1):
qemu: Replace stime() API with clock_settime
Lee Chee Yang (1):
cve-update-db-native: clean DB if temporary file exist
Li Zhou (2):
git: Security Advisory - git - CVE-2020-5260
git: Security Advisory - git - CVE-2020-11008
Martin Jansa (1):
prservice.py: fix do_package with newer Python in Ubuntu 20.04
Wang Mingyu (2):
gnupg: upgrade 2.2.17 -> 2.2.19
gnutls: upgrade 3.6.12 -> 3.6.13
Zhixiong Chi (1):
glibc: CVE-2020-1751
haiqing (1):
qemu: Add PACKAGECONFIG for glusterfs
wenlin.k...@windriver.com (1):
systemd: Fix CVE-2020-1712
meta/lib/oe/prservice.py | 4 +
.../{openssl_1.1.1f.bb => openssl_1.1.1g.bb} | 2 +-
meta/recipes-core/glibc/glibc/CVE-2020-1751.patch | 70 +++
meta/recipes-core/glibc/glibc_2.30.bb | 1 +
meta/recipes-core/meta/cve-update-db-native.bb | 9 +-
.../0001-Merge-branch-polkit-ref-count.patch | 520 +
meta/recipes-core/systemd/systemd_243.2.bb | 1 +
meta/recipes-devtools/apt/files/apt.conf | 2 +-
meta/recipes-devtools/git/git.inc | 16 +-
...edential-use-test_i18ncmp-to-check-stderr.patch | 35 ++
...detect-unrepresentable-values-when-parsin.patch | 156 +++
...ct-gitmodules-URLs-with-embedded-newlines.patch | 103
.../git/git/CVE-2020-11008-1.patch | 70 +++
.../git/git/CVE-2020-11008-2.patch | 292
.../git/git/CVE-2020-11008-3.patch | 97
.../git/git/CVE-2020-11008-4.patch | 173 +++
.../git/git/CVE-2020-11008-5.patch | 211 +
.../git/git/CVE-2020-11008-6.patch | 84
.../git/git/CVE-2020-11008-7.patch | 206
.../git/git/CVE-2020-11008-8.patch | 114 +
.../git/git/CVE-2020-11008-9.patch | 114 +
meta/recipes-devtools/git/git/CVE-2020-5260.patch | 65 +++
...on-native_2.7.17.bb => python-native_2.7.18.bb} | 0
meta/recipes-devtools/python/python.inc| 6 +-
...Don-t-search-system-for-headers-libraries.patch | 29 ++
meta/recipes-devtools/python/python3_3.7.7.bb | 1 +
.../python/{python_2.7.17.bb => python_2.7.18.bb} | 0
meta/recipes-devtools/qemu/qemu.inc| 6 +
...0011-linux-user-remove-host-stime-syscall.patch | 61 +++
.../qemu/qemu/CVE-2020-7039-1.patch| 44 ++
.../qemu/qemu/CVE-2020-7039-2.patch| 59 +++
.../qemu/qemu/CVE-2020-7039-3.patch| 64 +++
.../recipes-devtools/qemu/qemu/CVE-2020-7211.patch | 46 ++
.../gnupg/{gnupg_2.2.17.bb => gnupg_2.2.19.bb} | 4 +-
.../gnutls/gnutls/posix-shell.patch| 39 --
.../gnutls/{gnutls_3.6.8.bb => gnutls_3.6.13.bb} | 5 +-
36 files changed, 2658 insertions(+), 51 deletions(-)
rename meta/recipes-connectivity/openssl/{openssl_1.1.1f.bb =>
openssl_1.1.1g.bb} (98%)
create mode 100644 meta/recipes-core/glibc/glibc/CVE-2020-1751.patch
create mode 100644
meta/recipes-core/systemd/systemd/0001-Merge-branch-polkit-ref-count.patch
create mode 100644
meta/recipes-devtools/git/git/0001-t-lib-credential-use-test_i18ncmp-to-check-stderr.patch
create mode 100644
meta/recipes-devtools/git/git/0002-credential-detect-unrepresentable-values-when-parsin.patch
create mode 100644
meta/recipes-devtools/git/git/0003-fsck-detect-gitmodules-URLs-with-embedded-newlines.patch
create mode 100644 meta/recipes-devtools/git/git/CVE-2020-11008-1.patch
create mode 100644 meta/recipes-devtools/git/git/CVE-2020-11008-2.patch
create mode 100644 meta/recipes-devtools/git/git/CVE-2020-11008-3.patch
create mode 100644 meta/recipes-devtools/git/git/CVE-2020-11008-4.patch
create mode 100644 meta/recipes-devtools/git/git/CVE-2020-11008-5.patch
create mode 100644 meta/recipes-devtools/git/git/CVE-2020-11008-6.patch
create mode 100644 meta/recipes-devtools/git/git/CVE-2020-11008-7.patch
create mode 100644 meta/recipes-devtools/git/git/CVE-2020-11008-8.patch
create mode 100644 meta/recipes-devtools/git/git/CVE-2020-11008-9.patch
create mode 100644 meta/recipes-devtools/git/git/CVE-2020-526
[OE-core] [PATCH v3 2/4] libva-initial: New bootstrap recipe
Mesa needs libva.pc and libva headers to enable the VAAPI
state tracker and drivers.
This recipe is a variant of the full libva package build as in:
* it only depends on libdrm to build so it doesn't introduce
the circular dependency between mesa and libva, and
* it doesn't include the libraries in the final package.
However, there is another issue with build dependency handling
in Yocto. libva depends on mesa and mesa depends on this package.
Any package that depends on libva therefore would pull in libva
and this package resulting in an error in the prepare-sysroot
phase because they would install identical files into the
per-recipe sysroot.
Using the package name "*-initial" avoids this because of the
interaction between sstate.bbclass and staging.bbclass: any
package with the pattern "*-initial" in the name is excluded
from the dependency list unless explicitly added to DEPENDS.
Signed-off-by: Böszörményi Zoltán
---
v2: The include file is not versioned, more verbose commit message
v3: Rebased to current master
meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 9 +
meta/recipes-graphics/libva/libva.inc | 4 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-graphics/libva/libva-initial_2.6.1.bb
diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
new file mode 100644
index 00..a3b04eb02a
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
@@ -0,0 +1,9 @@
+require libva-${PV}.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
+SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
+SRC_URI[sha256sum] =
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
+
+do_install_append () {
+ rm -f ${D}${libdir}/*.so*
+}
diff --git a/meta/recipes-graphics/libva/libva.inc
b/meta/recipes-graphics/libva/libva.inc
index e03451240c..ac39e92de7 100644
--- a/meta/recipes-graphics/libva/libva.inc
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -16,7 +16,9 @@ BUGTRACKER = "https://github.com/intel/libva/issues";
SECTION = "x11"
LICENSE = "MIT"
-SRC_URI =
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2";
+SRC_URI =
"https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2";
+
+S = "${WORKDIR}/libva-${PV}"
UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases";
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138026):
https://lists.openembedded.org/g/openembedded-core/message/138026
Mute This Topic: https://lists.openembedded.org/mt/74050176/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 1/4] libva: Factor out base parts into an include file
To enable the VAAPI state tracker and drivers in mesa, it needs
libva.pc and the libva headers. To enable GLX support in libva,
it needs mesa to be compiled first. At the recipe level, this
would create a circular dependency between libva and mesa.
This is a preparation step before introducing a new libva recipe
variant to break the circular dependency.
Signed-off-by: Böszörményi Zoltán
---
v2: The include file is not versioned, verbose commit message
v3: Rebased to current master
meta/recipes-graphics/libva/libva.inc | 25 ++
meta/recipes-graphics/libva/libva_2.6.1.bb | 25 +-
2 files changed, 26 insertions(+), 24 deletions(-)
create mode 100644 meta/recipes-graphics/libva/libva.inc
diff --git a/meta/recipes-graphics/libva/libva.inc
b/meta/recipes-graphics/libva/libva.inc
new file mode 100644
index 00..e03451240c
--- /dev/null
+++ b/meta/recipes-graphics/libva/libva.inc
@@ -0,0 +1,25 @@
+SUMMARY = "Video Acceleration (VA) API for Linux"
+DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
+and API specification which enables and provides access to graphics \
+hardware (GPU) acceleration for video processing on Linux and UNIX \
+based operating systems. Accelerated processing includes video \
+decoding, video encoding, subpicture blending and rendering. The \
+specification was originally designed by Intel for its GMA (Graphics \
+Media Accelerator) series of GPU hardware, the API is however not \
+limited to GPUs or Intel specific hardware, as other hardware and \
+manufacturers can also freely use this API for hardware accelerated \
+video decoding."
+
+HOMEPAGE = "https://01.org/linuxmedia/vaapi";
+BUGTRACKER = "https://github.com/intel/libva/issues";
+
+SECTION = "x11"
+LICENSE = "MIT"
+
+SRC_URI =
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2";
+
+UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases";
+
+DEPENDS = "libdrm"
+
+inherit meson pkgconfig features_check
diff --git a/meta/recipes-graphics/libva/libva_2.6.1.bb
b/meta/recipes-graphics/libva/libva_2.6.1.bb
index 071be345d2..e8cb8678bc 100644
--- a/meta/recipes-graphics/libva/libva_2.6.1.bb
+++ b/meta/recipes-graphics/libva/libva_2.6.1.bb
@@ -1,32 +1,9 @@
-SUMMARY = "Video Acceleration (VA) API for Linux"
-DESCRIPTION = "Video Acceleration API (VA API) is a library (libVA) \
-and API specification which enables and provides access to graphics \
-hardware (GPU) acceleration for video processing on Linux and UNIX \
-based operating systems. Accelerated processing includes video \
-decoding, video encoding, subpicture blending and rendering. The \
-specification was originally designed by Intel for its GMA (Graphics \
-Media Accelerator) series of GPU hardware, the API is however not \
-limited to GPUs or Intel specific hardware, as other hardware and \
-manufacturers can also freely use this API for hardware accelerated \
-video decoding."
+require libva.inc
-HOMEPAGE = "https://01.org/linuxmedia/vaapi";
-BUGTRACKER = "https://github.com/intel/libva/issues";
-
-SECTION = "x11"
-LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
-
-SRC_URI =
"https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2";
SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
SRC_URI[sha256sum] =
"6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
-UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases";
-
-DEPENDS = "libdrm"
-
-inherit meson pkgconfig features_check
-
PACKAGECONFIG ??= " \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx', '', d)} \
${@bb.utils.filter('DISTRO_FEATURES', 'x11 wayland', d)} \
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138025):
https://lists.openembedded.org/g/openembedded-core/message/138025
Mute This Topic: https://lists.openembedded.org/mt/74050174/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 3/4] mesa: Add PACKAGECONFIG knob to enable VAAPI
The previously added libva-initial recipe makes it possible and
trivial.
Signed-off-by: Böszörményi Zoltán
---
v2: Small explanation in the commit message
v3: Rebased to current master
meta/recipes-graphics/mesa/mesa.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index f59503bf14..7a889a5b11 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -142,6 +142,7 @@ PACKAGECONFIG[gallium] =
"-Dgallium-drivers=${GALLIUMDRIVERS}, -Dgallium-drivers
PACKAGECONFIG[gallium-llvm] = "-Dllvm=true -Dshared-llvm=true, -Dllvm=false,
llvm${MESA_LLVM_RELEASE} llvm-native \
${@'elfutils' if
${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
PACKAGECONFIG[xa] = "-Dgallium-xa=true, -Dgallium-xa=false"
+PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-initial"
PACKAGECONFIG[lima] = ""
GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima',
'', d)}"
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138027):
https://lists.openembedded.org/g/openembedded-core/message/138027
Mute This Topic: https://lists.openembedded.org/mt/74050178/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 4/4] mesa: Add PACKAGECONFIG knob to enable VDPAU state tracker and drivers
Signed-off-by: Böszörményi Zoltán
---
v2: Replaced FILES_${PN}-vdpau-drivers with FILES_mesa-vdpau-drivers
to match the name in PACKAGES.
v3: Rebased to current master
meta/recipes-graphics/mesa/mesa.inc | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 7a889a5b11..fede691d6f 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -144,6 +144,8 @@ PACKAGECONFIG[gallium-llvm] = "-Dllvm=true
-Dshared-llvm=true, -Dllvm=false, llv
PACKAGECONFIG[xa] = "-Dgallium-xa=true, -Dgallium-xa=false"
PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-initial"
+PACKAGECONFIG[vdpau] = "-Dgallium-vdpau=true,-Dgallium-vdpau=false,libvdpau"
+
PACKAGECONFIG[lima] = ""
GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'lima', ',lima',
'', d)}"
@@ -180,6 +182,7 @@ PACKAGES =+ "libegl-mesa libegl-mesa-dev \
libgles3-mesa libgles3-mesa-dev \
libxatracker libxatracker-dev \
mesa-megadriver mesa-vulkan-drivers \
+ mesa-vdpau-drivers \
"
do_install_append () {
@@ -257,6 +260,7 @@ PACKAGES_DYNAMIC += "^mesa-driver-.*"
FILES_mesa-megadriver = "${libdir}/dri/*
${datadir}/drirc.d/00-mesa-defaults.conf"
FILES_mesa-vulkan-drivers = "${libdir}/libvulkan_*.so ${datadir}/vulkan"
+FILES_${PN}-vdpau-drivers = "${libdir}/vdpau/*.so.*"
FILES_libegl-mesa = "${libdir}/libEGL.so.*"
FILES_libgbm = "${libdir}/libgbm.so.*"
FILES_libgles1-mesa = "${libdir}/libGLESv1*.so.*"
@@ -266,7 +270,7 @@ FILES_libglapi = "${libdir}/libglapi.so.*"
FILES_libosmesa = "${libdir}/libOSMesa.so.*"
FILES_libxatracker = "${libdir}/libxatracker.so.*"
-FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan"
+FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan
${libdir}/vdpau/*.so"
FILES_libegl-mesa-dev = "${libdir}/libEGL.* ${includedir}/EGL
${includedir}/KHR ${libdir}/pkgconfig/egl.pc"
FILES_libgbm-dev = "${libdir}/libgbm.* ${libdir}/pkgconfig/gbm.pc
${includedir}/gbm.h"
FILES_libgl-mesa-dev = "${libdir}/libGL.* ${includedir}/GL
${libdir}/pkgconfig/gl.pc"
--
2.26.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138028):
https://lists.openembedded.org/g/openembedded-core/message/138028
Mute This Topic: https://lists.openembedded.org/mt/74050180/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/4] Enable VAAPI and VDPAU video drivers in Mesa
Mesa needs libva to enable VAAPI state tracker and drivers. libva needs Mesa to enable its GLX part. This is a circular dependency that can be solved by introducing a new libva recipe variant that doesn't enable GLX. Actually, the presence of Mesa/OpenGL headers is autodetected in libva so it's enough to leave out Mesa from DEPENDS in the new libva recipe variant. With magic already existing in sstate.bbclass and staging.bbclass, naming the new libva recipe variant "libva-initial" avoids an error for every other recipe that pulls in libva as dependency, including libva-utils and intel-vaapi-driver. The error (if not naming the recipe as "*-initial") is that the prepare-sysroot phase of a package would pull in the files rom both libva build variants that would obviously install identical files. Enabling the VDPAU state tracker and libraries is trivial, it was just missing from the recipe. [PATCH v3 1/4] libva: Factor out base parts into an include file [PATCH v3 2/4] libva-initial: New bootstrap recipe [PATCH v3 3/4] mesa: Add PACKAGECONFIG knob to enable VAAPI [PATCH v3 4/4] mesa: Add PACKAGECONFIG knob to enable VDPAU state Signed-off-by: Böszörményi Zoltán -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138024): https://lists.openembedded.org/g/openembedded-core/message/138024 Mute This Topic: https://lists.openembedded.org/mt/74050173/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] ✗ patchtest: failure for In the past the file was named 'built-in.o'. Nowadays it is 'built-in.a'.
== Series Details == Series: In the past the file was named 'built-in.o'. Nowadays it is 'built-in.a'. Revision: 1 URL : https://patchwork.openembedded.org/series/24010/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Patch[scripts, v2] In the past the file was named 'built-in.o'. Nowadays it is 'built-in.a'. Issue Shortlog does not follow expected format [test_shortlog_format] Suggested fixCommit shortlog (first line of commit message) should follow the format ": " If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138023): https://lists.openembedded.org/g/openembedded-core/message/138023 Mute This Topic: https://lists.openembedded.org/mt/74050164/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] [Openembedded-architecture] Proposal: community maintained recipes in oe-core
On Thu, 2020-05-07 at 15:24 +0200, Alexander Kanavin wrote: > On Thu, 7 May 2020 at 14:38, Jens Rehsack wrote: > > > I agree there should be a way to update maintainers e-main once > > we determine they are not longer willing to take part in that > > program or absent. I believe this an issue in general for > > OpenSource has had to address over the years. > > > > > > My plan is to experiment with this for the python3* recipes in > > oe-core for a start: they've been bouncing between various people > > over the past couple of years, but no active maintainer has > > emerged. > > > > I'd like to see 'non-systemd init' in, either :) > > On a technical level this means updating maintainers.inc entries to > list oe-core list as the email address; the next AUH round (in a week > or so) will go as usual (because it's the first post-release one), > and depending on how maintainers react, and who hasn't sent anything > at all for a long time, I will propose something specific. I agree we do need to do something and it was briefly discussed by the YP TSC who basically agreed we need to tweak things. Firstly though, we could do with digging out Ross' original emails and properly documenting "maintainers" on the wiki. I thought we'd done that but none of us could find it with a quick search which is bad if it does exist. Is anyone willing to summarise the current process on the wiki based on those emails? (or point at the page if it does exist!) Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138022): https://lists.openembedded.org/g/openembedded-core/message/138022 Mute This Topic: https://lists.openembedded.org/mt/73964484/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [scripts][PATCH v2] In the past the file was named 'built-in.o'. Nowadays it is 'built-in.a'.
The script is modified to work with both. I expect
it will not happen that there are built-in.a and built-in.o
files in the same kernel.
Signed-off-by: Jan Vermaete
---
scripts/tiny/ksize.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/tiny/ksize.py b/scripts/tiny/ksize.py
index 8316b85cb1..db2b9ec39f 100755
--- a/scripts/tiny/ksize.py
+++ b/scripts/tiny/ksize.py
@@ -4,7 +4,7 @@
#
# SPDX-License-Identifier: GPL-2.0-or-later
#
-# Display details of the kernel build size, broken up by built-in.o. Sort
+# Display details of the kernel build size, broken up by built-in.[o,a]. Sort
# the objects by size. Run from the top level kernel build directory.
#
# Author: Darren Hart
@@ -59,7 +59,7 @@ class Report:
p = Popen("ls " + subglob, shell=True, stdout=PIPE, stderr=PIPE,
universal_newlines=True)
for f in p.communicate()[0].splitlines():
path = os.path.dirname(f)
-r.parts.append(Report.create(f, path, str(path) +
"/*/built-in.o"))
+r.parts.append(Report.create(f, path, str(path) +
"/*/built-in.[o,a]"))
r.parts.sort(reverse=True)
for b in r.parts:
@@ -139,7 +139,7 @@ def main():
else:
assert False, "unhandled option"
-glob = "arch/*/built-in.o */built-in.o"
+glob = "arch/*/built-in.[o,a] */built-in.[o,a]"
vmlinux = Report.create("vmlinux", "Linux Kernel", glob)
vmlinux.show()
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138021):
https://lists.openembedded.org/g/openembedded-core/message/138021
Mute This Topic: https://lists.openembedded.org/mt/74050043/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] [Openembedded-architecture] Proposal: community maintained recipes in oe-core
On Thu, 7 May 2020 at 14:38, Jens Rehsack wrote: > > I agree there should be a way to update maintainers e-main once we > determine they are not longer willing to take part in that program or > absent. I believe this an issue in general for OpenSource has had to > address over the years. > > > > My plan is to experiment with this for the python3* recipes in oe-core > for a start: they've been bouncing between various people over the past > couple of years, but no active maintainer has emerged. > > I'd like to see 'non-systemd init' in, either :) > On a technical level this means updating maintainers.inc entries to list oe-core list as the email address; the next AUH round (in a week or so) will go as usual (because it's the first post-release one), and depending on how maintainers react, and who hasn't sent anything at all for a long time, I will propose something specific. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138020): https://lists.openembedded.org/g/openembedded-core/message/138020 Mute This Topic: https://lists.openembedded.org/mt/73964484/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] libsdl2: enable opengl option for native/nativesdk, subject to 'opengl' in DISTRO_FEATURES
This allows virgl support in qemu with the SDL frontend
Signed-off-by: Alexander Kanavin
---
meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb
b/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb
index c1c941e452..83dce86801 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb
@@ -45,8 +45,8 @@ EXTRA_OECONF = "--disable-oss --disable-esd --disable-arts \
# and BSP layers to pick either (desktop) opengl, gles2, or no GL
PACKAGECONFIG_GL ?= "${@bb.utils.filter('DISTRO_FEATURES', 'opengl', d)}"
-PACKAGECONFIG_class-native = "x11"
-PACKAGECONFIG_class-nativesdk = "${@bb.utils.filter('DISTRO_FEATURES', 'x11',
d)}"
+PACKAGECONFIG_class-native = "x11 ${PACKAGECONFIG_GL}"
+PACKAGECONFIG_class-nativesdk = "${@bb.utils.filter('DISTRO_FEATURES', 'x11',
d)} ${PACKAGECONFIG_GL}"
PACKAGECONFIG ??= " \
${PACKAGECONFIG_GL} \
${@bb.utils.filter('DISTRO_FEATURES', 'alsa directfb pulseaudio x11', d)} \
--
2.26.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138018):
https://lists.openembedded.org/g/openembedded-core/message/138018
Mute This Topic: https://lists.openembedded.org/mt/74049264/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 1/3] bitbake.conf: propagate 'opengl' DISTRO_FEATURE to native/nativesdk from target
This will allow better control over native virgl/qemu configurations.
Adjust gtk+3/cairo native configurations to actually ignore opengl
when building for -native: we do not need it, and it would cause build
failures as only a limited subset of mesa-native is currently built.
Drop native/nativesdk overrides from virglrenderer/libepoxy recipes
as opengl feature is now correctly set for those variants.
Signed-off-by: Alexander Kanavin
---
meta/conf/bitbake.conf | 4 ++--
meta/recipes-gnome/gtk+/gtk+3.inc | 2 ++
meta/recipes-graphics/cairo/cairo_1.16.0.bb| 2 ++
meta/recipes-graphics/libepoxy/libepoxy_1.5.4.bb | 2 --
meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb | 2 --
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 4b544a22cd..6f3536eff4 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -829,8 +829,8 @@ DISTRO_FEATURES_NATIVESDK ?= "x11"
# Normally target distro features will not be applied to native builds:
# Native distro features on this list will use the target feature value
-DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation"
-DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation"
+DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation opengl"
+DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation opengl"
DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit gobject-introspection-data
ldconfig"
MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode"
diff --git a/meta/recipes-gnome/gtk+/gtk+3.inc
b/meta/recipes-gnome/gtk+/gtk+3.inc
index 5d1f59ea1a..6154154004 100644
--- a/meta/recipes-gnome/gtk+/gtk+3.inc
+++ b/meta/recipes-gnome/gtk+/gtk+3.inc
@@ -46,6 +46,8 @@ do_compile_prepend() {
PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'opengl wayland x11',
d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl x11',
'glx', '', d)}"
+PACKAGECONFIG_class-native = "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
+PACKAGECONFIG_class-nativesdk = "${@bb.utils.filter('DISTRO_FEATURES', 'x11',
d)}"
PACKAGECONFIG[x11] = "--enable-x11-backend,--disable-x11-backend,at-spi2-atk
fontconfig libx11 libxext libxcursor libxi libxdamage libxrandr libxrender
libxcomposite libxfixes"
# this is provided by oe-core patch that removes epoxy/gl dependency from a
X11 build
diff --git a/meta/recipes-graphics/cairo/cairo_1.16.0.bb
b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
index b772c2ece2..092c77b826 100644
--- a/meta/recipes-graphics/cairo/cairo_1.16.0.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.16.0.bb
@@ -42,6 +42,8 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES',
'directfb', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11 xcb',
'', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl',
'opengl', '', d)} \
trace"
+PACKAGECONFIG_class-native = "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
'x11 xcb', '', d)}"
+PACKAGECONFIG_class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES',
'x11', 'x11 xcb', '', d)}"
PACKAGECONFIG[x11] = "--with-x=yes -enable-xlib,--with-x=no
--disable-xlib,${X11DEPENDS}"
PACKAGECONFIG[xcb] = "--enable-xcb,--disable-xcb,libxcb"
diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.5.4.bb
b/meta/recipes-graphics/libepoxy/libepoxy_1.5.4.bb
index 0782c6ce35..6646ef79fe 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.5.4.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.5.4.bb
@@ -19,8 +19,6 @@ UPSTREAM_CHECK_URI =
"https://github.com/anholt/libepoxy/releases";
inherit meson pkgconfig features_check
REQUIRED_DISTRO_FEATURES = "opengl"
-REQUIRED_DISTRO_FEATURES_class-native = ""
-REQUIRED_DISTRO_FEATURES_class-nativesdk = ""
PACKAGECONFIG[egl] = "-Degl=yes, -Degl=no, virtual/egl"
PACKAGECONFIG[x11] = "-Dglx=yes, -Dglx=no -Dx11=false, virtual/libx11
virtual/libgl"
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
index 1046b8504f..29b12628d0 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.8.2.bb
@@ -22,5 +22,3 @@ inherit meson pkgconfig features_check
BBCLASSEXTEND = "native nativesdk"
REQUIRED_DISTRO_FEATURES = "opengl"
-REQUIRED_DISTRO_FEATURES_class-native = ""
-REQUIRED_DISTRO_FEATURES_class-nativesdk = ""
--
2.26.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138016):
https://lists.openembedded.org/g/openembedded-core/message/138016
Mute This Topic: https://lists.openembedded.org/mt/74049262/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] [meta-oe][PATCH] libva: Removed virtual/mesa dependency
2020. 05. 07. 13:48 keltezéssel, Richard Purdie írta: On Wed, 2020-05-06 at 14:41 +0200, Zoltan Boszormenyi via lists.openembedded.org wrote: 2020. 04. 24. 17:01 keltezéssel, Bartłomiej Burdukiewicz írta: Mesa can be compiled with libva support, in order to avoid recursive dependency between mesa and libva, virtual/mesa must be removed from libva recipe. This is why this patch series was created, to break the circular dependency in a clean way: https://patchwork.openembedded.org/series/22976/# The libva-initial recipe was introduced that doesn't need mesa, then mesa can be built with vaapi state tracker enabled, finally libva can be built with dependency on mesa so its GLX support is enabled. What happened to it? I think it came in late during the release and was a bit too risky to be taken at the time. I didn't get that impression after the response from Khem Raj: >> OK, I guess, we should give it a test. It think it is a good solution to the problem, would you be able to rebase the patches and we can queue them for testing? Its a much better time now to merge a change like that. I will rebase them, thanks. Does it have a chance to be backported to 3.1? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138019): https://lists.openembedded.org/g/openembedded-core/message/138019 Mute This Topic: https://lists.openembedded.org/mt/73242971/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] qemu: enable virglrenderer and glx options subject to 'opengl' DISTRO_FEATURE
Note that to actually use accelerated GL passthrough, there are two options
1) a suitable frontend need to be also enabled - gtk+ and SDL both seem to work
well.
Previously I struggled to make SDL work, but now it seems fine.
2) it is also possible to render off-screen with -display egl-headless option,
and see the output with a VNC viewer (for which, qemu needs to be started
with a VNC server):
$ runqemu kvm egl-headless publicvnc
Signed-off-by: Alexander Kanavin
---
meta/lib/oeqa/selftest/cases/runtime_test.py | 18 ++
.../qemu/qemu-system-native_4.2.0.bb | 4 +++-
meta/recipes-devtools/qemu/qemu_4.2.0.bb | 5 -
3 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index 09d3de7aea..793c98a335 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -188,18 +188,14 @@ class TestImage(OESelftestTestCase):
self.skipTest('virgl isn\'t working with Opensuse 15.0')
qemu_packageconfig = get_bb_var('PACKAGECONFIG', 'qemu-system-native')
-sdl_packageconfig = get_bb_var('PACKAGECONFIG', 'libsdl2-native')
+qemu_distrofeatures = get_bb_var('DISTRO_FEATURES',
'qemu-system-native')
features = 'INHERIT += "testimage"\n'
if 'gtk+' not in qemu_packageconfig:
features += 'PACKAGECONFIG_append_pn-qemu-system-native = "
gtk+"\n'
if 'sdl' not in qemu_packageconfig:
features += 'PACKAGECONFIG_append_pn-qemu-system-native = " sdl"\n'
-if 'virglrenderer' not in qemu_packageconfig:
-features += 'PACKAGECONFIG_append_pn-qemu-system-native = "
virglrenderer"\n'
-if 'glx' not in qemu_packageconfig:
-features += 'PACKAGECONFIG_append_pn-qemu-system-native = " glx"\n'
-if 'opengl' not in sdl_packageconfig:
-features += 'PACKAGECONFIG_append_pn-libsdl2-native = " opengl"\n'
+if 'opengl' not in qemu_distrofeatures:
+features += 'DISTRO_FEATURES_append = " opengl"\n'
features += 'TEST_SUITES = "ping ssh virgl"\n'
features += 'IMAGE_FEATURES_append = " ssh-server-dropbear"\n'
features += 'IMAGE_INSTALL_append = " kmscube"\n'
@@ -231,12 +227,10 @@ class TestImage(OESelftestTestCase):
dripath = subprocess.check_output("pkg-config
--variable=dridriverdir dri", shell=True)
except subprocess.CalledProcessError as e:
self.skipTest("Could not determine the path to dri drivers on the
host via pkg-config.\nPlease install Mesa development files (particularly,
dri.pc) on the host machine.")
-qemu_packageconfig = get_bb_var('PACKAGECONFIG', 'qemu-system-native')
+qemu_distrofeatures = get_bb_var('DISTRO_FEATURES',
'qemu-system-native')
features = 'INHERIT += "testimage"\n'
-if 'virglrenderer' not in qemu_packageconfig:
-features += 'PACKAGECONFIG_append_pn-qemu-system-native = "
virglrenderer"\n'
-if 'glx' not in qemu_packageconfig:
-features += 'PACKAGECONFIG_append_pn-qemu-system-native = " glx"\n'
+if 'opengl' not in qemu_distrofeatures:
+features += 'DISTRO_FEATURES_append = " opengl"\n'
features += 'TEST_SUITES = "ping ssh virgl"\n'
features += 'IMAGE_FEATURES_append = " ssh-server-dropbear"\n'
features += 'IMAGE_INSTALL_append = " kmscube"\n'
diff --git a/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb
b/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb
index d83ee59375..7394385d30 100644
--- a/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb
+++ b/meta/recipes-devtools/qemu/qemu-system-native_4.2.0.bb
@@ -9,7 +9,9 @@ DEPENDS = "glib-2.0-native zlib-native pixman-native
qemu-native bison-native"
EXTRA_OECONF_append = " --target-list=${@get_qemu_system_target_list(d)}"
-PACKAGECONFIG ??= "fdt alsa kvm"
+PACKAGECONFIG ??= "fdt alsa kvm \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx', ''
,d)} \
+"
# Handle distros such as CentOS 5 32-bit that do not have kvm support
PACKAGECONFIG_remove = "${@'kvm' if not
os.path.exists('/usr/include/linux/kvm.h') else ''}"
diff --git a/meta/recipes-devtools/qemu/qemu_4.2.0.bb
b/meta/recipes-devtools/qemu/qemu_4.2.0.bb
index f0c1daabe1..a4018cc448 100644
--- a/meta/recipes-devtools/qemu/qemu_4.2.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_4.2.0.bb
@@ -21,5 +21,8 @@ do_install_append_class-nativesdk() {
PACKAGECONFIG ??= " \
fdt sdl kvm \
${@bb.utils.filter('DISTRO_FEATURES', 'alsa xen', d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx', ''
,d)} \
+"
+PACKAGECONFIG_class-nativesdk ??= "fdt sdl kvm \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx', ''
,d)} \
"
-PACKAGECONFIG_class-nativesdk ??= "fdt sdl kvm"
--
2.26.1
-=-=-=-=-=-=-=
Re: [OE-core] [Openembedded-architecture] Proposal: community maintained recipes in oe-core
> Am 05.05.2020 um 13:48 schrieb Alexander Kanavin : > > On Mon, 4 May 2020 at 00:16, akuster wrote: > the current maintenance model in openembedded-core is problematic due to lack > of well-working process of finding maintainers, and replacing them when > they're no longer able to contribute. This becomes especially frustrating > when maintainers silently disappear, and perfectly fine patches produced by > Auto Upgrade Helper and sent to them via private mail go wasted. > > Can you clarify what you mean by silently disappear. By the time I have time > to process an update, someone else has sent the patches. > > That means: a) not sending any patches, despite AUH reminders, for months; b) > not otherwise active or visible on the lists. You wouldn't qualify, so no > worries. Jepp - happens often: people switch responsibilities / projects and even with best intensions to spend effort in spare time more and more things fall down. >> >> I'm proposing that some of the recipes in oe-core - those that are known to >> lack an active maintainer - would be transitioned to 'community maintenance'. > Define active > > The reverse of the above: sending patches OR otherwise active on the lists. > > > Well that is one of the problems of putting tooling into the community's > hands. It is made it easy to send updates to the list. Is not uncommon to > accept "Update" as the only information, do you expect the submmiter to deal > with stable or the Package Maintainer? > > We can certainly ask anyone who sends a patch to try and provide more > information about the update. The reason I'm not doing it is that I have too > many updates to handle; but someone with only a few recipes should be better > able to find time for it. The process should be better described and developed than "sending the patch again" ... > I agree there should be a way to update maintainers e-main once we determine > they are not longer willing to take part in that program or absent. I believe > this an issue in general for OpenSource has had to address over the years. > > My plan is to experiment with this for the python3* recipes in oe-core for a > start: they've been bouncing between various people over the past couple of > years, but no active maintainer has emerged. I'd like to see 'non-systemd init' in, either :) Cheers -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138015): https://lists.openembedded.org/g/openembedded-core/message/138015 Mute This Topic: https://lists.openembedded.org/mt/73964484/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] [meta-oe][PATCH] libva: Removed virtual/mesa dependency
On Wed, 2020-05-06 at 14:41 +0200, Zoltan Boszormenyi via lists.openembedded.org wrote: > 2020. 04. 24. 17:01 keltezéssel, Bartłomiej Burdukiewicz írta: > > Mesa can be compiled with libva support, in order to avoid > > recursive > > dependency between mesa and libva, virtual/mesa must be removed > > from libva recipe. > > This is why this patch series was created, to break the > circular dependency in a clean way: > https://patchwork.openembedded.org/series/22976/# > > The libva-initial recipe was introduced that doesn't need > mesa, then mesa can be built with vaapi state tracker enabled, > finally libva can be built with dependency on mesa so its > GLX support is enabled. > > What happened to it? I think it came in late during the release and was a bit too risky to be taken at the time. It think it is a good solution to the problem, would you be able to rebase the patches and we can queue them for testing? Its a much better time now to merge a change like that. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138014): https://lists.openembedded.org/g/openembedded-core/message/138014 Mute This Topic: https://lists.openembedded.org/mt/73242971/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] [meta-oe][PATCH] libva: Removed virtual/mesa dependency
On Wednesday, 6 May 2020 14:41:25 CEST Böszörményi Zoltán wrote: > 2020. 04. 24. 17:01 keltezéssel, Bartłomiej Burdukiewicz írta: > > Mesa can be compiled with libva support, in order to avoid recursive > > dependency between mesa and libva, virtual/mesa must be removed > > from libva recipe. > > This is why this patch series was created, to break the > circular dependency in a clean way: > https://patchwork.openembedded.org/series/22976/# > > The libva-initial recipe was introduced that doesn't need > mesa, then mesa can be built with vaapi state tracker enabled, > finally libva can be built with dependency on mesa so its > GLX support is enabled. > > What happened to it? > > Best regards, > Zoltán Böszörményi Was those patches merged upstream? Never seen them before. Cheers, Bartłomiej Burdukiewicz signature.asc Description: This is a digitally signed message part. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138013): https://lists.openembedded.org/g/openembedded-core/message/138013 Mute This Topic: https://lists.openembedded.org/mt/73242971/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 2/2] encodings: RDEPEND on mkfontdir mkfontscale
On Thu, 2020-05-07 at 15:45 +0800, Yi Zhao wrote:
> Fix pkg_postinst error when install encodings via online repo:
>
> $ opkg install encodings
> Installing encodings (1.0.5) on root
> Configuring encodings.
> /var/lib/opkg/info/encodings.postinst: line 7: mkfontdir: not found
> Collected errors:
> * pkg_run_script: package "encodings" postinst script returned status 127.
> * opkg_configure: encodings.postinst returned 127.
>
> Signed-off-by: Yi Zhao
> ---
> meta/recipes-graphics/xorg-font/encodings_1.0.5.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
> b/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
> index a39609b5da..b161a46982 100644
> --- a/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
> +++ b/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
> @@ -10,7 +10,7 @@ PE = "1"
> PR = "${INC_PR}.1"
>
> DEPENDS = "mkfontscale-native mkfontdir-native font-util-native"
> -RDEPENDS_${PN} = ""
> +RDEPENDS_${PN} = "mkfontdir mkfontscale"
>
> SRC_URI += "file://nocompiler.patch"
> SRC_URI[md5sum] = "bbae4f247b88ccde0e85ed6a403da22a"
I don't think these two patches are correct. encodings doesn't install
these things so perhaps it shouldn't be running these postinst at all?
I thought I remembered something about this change:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b8f089512f65a4a131c8096c281c4f3d9cf23718
from 2013! Sadly the commit log is a bit sparse.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138012):
https://lists.openembedded.org/g/openembedded-core/message/138012
Mute This Topic: https://lists.openembedded.org/mt/74046130/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] virgl: skip test on Debian 9
Debian 9 has an older version of mesa, where dri drivers do not link
against glapi explicitly, which causes problems when they are loaded
by newer mesa-native:
pokybuild@debian9-ty-2:~$ ldd -d /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
|grep undefined
undefined symbol: _glapi_tls_Dispatch
(/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
undefined symbol: _glapi_tls_Context
(/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
compared to Debian 10:
pokybuild@debian10-ty-2:~$ ldd -d
/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so|grep undefined
pokybuild@debian10-ty-2:~$
Signed-off-by: Alexander Kanavin
---
meta/lib/oeqa/selftest/cases/runtime_test.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index 60cb2e01a6..09d3de7aea 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -180,6 +180,8 @@ class TestImage(OESelftestTestCase):
distro = oe.lsb.distro_identifier()
if distro and distro == 'debian-8':
self.skipTest('virgl isn\'t working with Debian 8')
+if distro and distro == 'debian-9':
+self.skipTest('virgl isn\'t working with Debian 9')
if distro and distro == 'centos-7':
self.skipTest('virgl isn\'t working with Centos 7')
if distro and distro == 'opensuseleap-15.0':
--
2.26.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138011):
https://lists.openembedded.org/g/openembedded-core/message/138011
Mute This Topic: https://lists.openembedded.org/mt/74047054/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 1/2] xorg-font-common: redirect stderr to /dev/null in pkg_postinst
Redirect stderr to /dev/null to avoid the error:
$ opkg install encodings
Installing encodings (1.0.5) on root
Configuring encodings.
find: /usr/lib/X11/fonts: No such file or directory
Signed-off-by: Yi Zhao
---
meta/recipes-graphics/xorg-font/xorg-font-common.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/xorg-font/xorg-font-common.inc
b/meta/recipes-graphics/xorg-font/xorg-font-common.inc
index f18c8aefc2..85bc0f72a8 100644
--- a/meta/recipes-graphics/xorg-font/xorg-font-common.inc
+++ b/meta/recipes-graphics/xorg-font/xorg-font-common.inc
@@ -32,11 +32,11 @@ FILES_${PN} += " ${libdir}/X11/fonts ${datadir}"
PACKAGE_WRITE_DEPS += "mkfontdir-native mkfontscale-native"
pkg_postinst_${PN} () {
-for fontdir in `find $D/usr/lib/X11/fonts -type d`; do
+for fontdir in `find $D/usr/lib/X11/fonts -type d 2>/dev/null`; do
mkfontdir $fontdir
mkfontscale $fontdir
done
-for fontdir in `find $D/usr/share/fonts/X11 -type d`; do
+for fontdir in `find $D/usr/share/fonts/X11 -type d 2>/dev/null`; do
mkfontdir $fontdir
mkfontscale $fontdir
done
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138009):
https://lists.openembedded.org/g/openembedded-core/message/138009
Mute This Topic: https://lists.openembedded.org/mt/74046128/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/2] encodings: RDEPEND on mkfontdir mkfontscale
Fix pkg_postinst error when install encodings via online repo:
$ opkg install encodings
Installing encodings (1.0.5) on root
Configuring encodings.
/var/lib/opkg/info/encodings.postinst: line 7: mkfontdir: not found
Collected errors:
* pkg_run_script: package "encodings" postinst script returned status 127.
* opkg_configure: encodings.postinst returned 127.
Signed-off-by: Yi Zhao
---
meta/recipes-graphics/xorg-font/encodings_1.0.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
b/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
index a39609b5da..b161a46982 100644
--- a/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
+++ b/meta/recipes-graphics/xorg-font/encodings_1.0.5.bb
@@ -10,7 +10,7 @@ PE = "1"
PR = "${INC_PR}.1"
DEPENDS = "mkfontscale-native mkfontdir-native font-util-native"
-RDEPENDS_${PN} = ""
+RDEPENDS_${PN} = "mkfontdir mkfontscale"
SRC_URI += "file://nocompiler.patch"
SRC_URI[md5sum] = "bbae4f247b88ccde0e85ed6a403da22a"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138010):
https://lists.openembedded.org/g/openembedded-core/message/138010
Mute This Topic: https://lists.openembedded.org/mt/74046130/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] ✗ patchtest: failure for cve-check: add option to format reports as comma seperated values
== Series Details == Series: cve-check: add option to format reports as comma seperated values Revision: 1 URL : https://patchwork.openembedded.org/series/24000/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series cannot be parsed correctly due to malformed diff lines [test_mbox_format] Suggested fixCreate the series again using git-format-patch and ensure it can be applied using git am Diff lineHunk is longer than expected * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at a1353cc923) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138008): https://lists.openembedded.org/g/openembedded-core/message/138008 Mute This Topic: https://lists.openembedded.org/mt/74046054/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] cve-check: add option to format reports as comma seperated values
cve-check will check if CVE_CHECK_FORMAT_CSV is set and format the outputs
(manifest etc.) as CSV for use in spreadsheets.
Signed-off-by: Timon Ulrich
---
meta/classes/cve-check.bbclass | 49 +-
1 file changed, 37 insertions(+), 12 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 2a530a0489..a7803c7aba 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -35,6 +35,7 @@ CVE_CHECK_DIR ??= "${DEPLOY_DIR}/cve"
CVE_CHECK_MANIFEST ?=
"${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cve"
CVE_CHECK_COPY_FILES ??= "1"
CVE_CHECK_CREATE_MANIFEST ??= "1"
+CVE_CHECK_FORMAT_CSV ??= "0"
# Whitelist for packages (PN)
CVE_CHECK_PN_WHITELIST ?= ""
@@ -98,10 +99,24 @@ python cve_check_write_rootfs_manifest () {
manifest_name = d.getVar("CVE_CHECK_MANIFEST")
cve_tmp_file = d.getVar("CVE_CHECK_TMP_FILE")
+if d.getVar("CVE_CHECK_FORMAT_CSV") == "1":
+manifest_name += ".csv"
+
+with open(cve_tmp_file, "r") as f:
+db_update_timestamp = f.readline()
+orig_tmp_file = f.readlines()[1:]
+with open(cve_tmp_file, "w") as f:
+f.write(db_update_timestamp+'\n')
+f.write("PACKAGE NAME;PACKAGE VERSION;CVE;CVE STATUS;"
+ "CVE SUMMARY;CVSS v2 BASE SCORE;CVSS v3 BASE SCORE;"
+ "VECTOR;MORE INFORMATION\n")
+with open(cve_tmp_file, "a") as f:
+f.writelines(orig_tmp_file)
+
shutil.copyfile(cve_tmp_file, manifest_name)
if manifest_name and os.path.exists(manifest_name):
-manifest_link = os.path.join(deploy_dir, "%s.cve" % link_name)
+manifest_link = os.path.join(deploy_dir, "%s.cve%s" %
+ (link_name, ".csv" if d.getVar("CVE_CHECK_FORMAT_CSV") == "1" else
+ ""))
# If we already have another manifest, update symlinks
if os.path.exists(os.path.realpath(manifest_link)):
os.remove(manifest_link) @@ -295,26 +310,32 @@ def
cve_write_data(d, patched, unpatched, whitelisted, cve_data):
cve_file = d.getVar("CVE_CHECK_LOG")
nvd_link = "https://web.nvd.nist.gov/view/vuln/detail?vulnId=";
+eol_char = '\n' if d.getVar("CVE_CHECK_FORMAT_CSV") != "1" else ';'
write_string = ""
unpatched_cves = []
bb.utils.mkdirhier(os.path.dirname(cve_file))
for cve in sorted(cve_data):
-write_string += "PACKAGE NAME: %s\n" % d.getVar("PN")
-write_string += "PACKAGE VERSION: %s\n" % d.getVar("PV")
-write_string += "CVE: %s\n" % cve
+write_string += "%s%s%c" % ("PACKAGE NAME: " if
d.getVar("CVE_CHECK_FORMAT_CSV") != "1" else "", d.getVar("PN"), eol_char)
+write_string += "%s%s%c" % ("PACKAGE VERSION: " if
d.getVar("CVE_CHECK_FORMAT_CSV") != "1" else "", d.getVar("PV"), eol_char)
+write_string += "%s%s%c" % ("CVE: " if
d.getVar("CVE_CHECK_FORMAT_CSV") != "1" else "", cve, eol_char)
+if d.getVar("CVE_CHECK_FORMAT_CSV") != "1":
+write_string += "CVE STATUS: "
if cve in whitelisted:
-write_string += "CVE STATUS: Whitelisted\n"
+write_string += "Whitelisted"
elif cve in patched:
-write_string += "CVE STATUS: Patched\n"
+write_string += "Patched"
else:
unpatched_cves.append(cve)
-write_string += "CVE STATUS: Unpatched\n"
-write_string += "CVE SUMMARY: %s\n" % cve_data[cve]["summary"]
-write_string += "CVSS v2 BASE SCORE: %s\n" % cve_data[cve]["scorev2"]
-write_string += "CVSS v3 BASE SCORE: %s\n" % cve_data[cve]["scorev3"]
-write_string += "VECTOR: %s\n" % cve_data[cve]["vector"]
-write_string += "MORE INFORMATION: %s%s\n\n" % (nvd_link, cve)
+write_string += "Unpatched"
+write_string += eol_char
+write_string += "%s\"%s\"%c" % ("CVE SUMMARY: " if
d.getVar("CVE_CHECK_FORMAT_CSV") != "1" else "", cve_data[cve]["summary"],
eol_char)
+write_string += "%s%s%c" % ("CVSS v2 BASE SCORE: " if
d.getVar("CVE_CHECK_FORMAT_CSV") != "1" else "", cve_data[cve]["scorev2"],
eol_char)
+write_string += "%s%s%c" % ("CVSS v3 BASE SCORE: " if
d.getVar("CVE_CHECK_FORMAT_CSV") != "1" else "", cve_data[cve]["scorev3"],
eol_char)
+write_string += "%s%s%c" % ("VECTOR: " if
d.getVar("CVE_CHECK_FORMAT_CSV") != "1" else "", cve_data[cve]["vector"],
eol_char)
+write_string += "%s%s%s\n" % ("MORE INFORMATION: " if
d.getVar("CVE_CHECK_FORMAT_CSV") != "1" else "", nvd_link, cve)
+if d.getVar("CVE_CHECK_FORMAT_CSV") != "1":
+write_string += '\n'
if unpatched_cves:
bb.warn("Found unpatched CVE (%s), for more information check %s" % ("
".join(unpatched_cves),cve_file)) @@ -328,6 +349,10 @@ def cve_write_data(d,
patched, unpatched, whitelisted, cve_d
