[OE-core] [PATCH 0/1] xmlcatalog.bbclass: execute xmlcatalog only if it's available
*** BLURB HERE *** The following changes since commit 4fd9ee4670293632cc0ca1e64b8833eb6014435d: bitbake: bitbake: Add --skip-setscene option (2019-07-03 17:00:57 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/xmlcatalog-esdk http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/xmlcatalog-esdk Chen Qi (1): xmlcatalog.bbclass: execute xmlcatalog only if it's available meta/classes/xmlcatalog.bbclass | 2 ++ 1 file changed, 2 insertions(+) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] xmlcatalog.bbclass: execute xmlcatalog only if it's available
For build-sysroots.bb, the xmlcatalog would not be in its
staging directory. Causing the following error for eSDK.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command
'/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xml-dtd4-native-xmlcatalog'
returned non-zero exit status 127.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function failed:
do_build_native_sysroot
The problem could be reproduced by the following steps.
1. Add in local.conf:
IMAGE_INSTALL_append = " btrfs-tools"
DISTRO_FEATURES_append = " api-documentation"
INHERIT += "testsdk"
2. bitbake core-image-minimal -c populate_sdk_ext
3. bitbake core-image-minimal -c testsdkext
Signed-off-by: Chen Qi
---
meta/classes/xmlcatalog.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/xmlcatalog.bbclass b/meta/classes/xmlcatalog.bbclass
index 075aef8..e805e7b 100644
--- a/meta/classes/xmlcatalog.bbclass
+++ b/meta/classes/xmlcatalog.bbclass
@@ -5,6 +5,8 @@ XMLCATALOGS ?= ""
SYSROOT_PREPROCESS_FUNCS_append = " xmlcatalog_sstate_postinst"
xmlcatalog_complete() {
+ # In case of eSDK, build-sysroot does not have xmlcatalog in its
staging directory.
+ [ "`which xmlcatalog`" = "" ] && exit 0
ROOTCATALOG="${STAGING_ETCDIR_NATIVE}/xml/catalog"
if [ ! -f $ROOTCATALOG ]; then
mkdir --parents $(dirname $ROOTCATALOG)
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-poky][PATCH 2/2] poky.conf: make systemd as default init manager
On Thu, 2019-07-04 at 21:45 +0800, kai.k...@windriver.com wrote: > From: Kai Kang > > Make systemd as default init manager for distro poky. And set > sysvinit > as default value for musl considering security. > > Update poky-tiny.conf to use new introduced variable INIT_MANGER. > > [YOCTO #13031] > > Signed-off-by: Kai Kang > --- > meta-poky/conf/distro/poky-tiny.conf | 8 ++-- > meta-poky/conf/distro/poky.conf | 5 + > 2 files changed, 7 insertions(+), 6 deletions(-) I tested this in a build: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/259 and there are a number of failures in there which look related to this and will need to be resolved before we can make this switch. I'll still aim to get patch 1 in since we should be able to do that and at least clean up poky to use it, then its just the switch ti systemd we need to do. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] build failures due to pigz host tool
On Thu, 2019-07-04 at 16:57 +0100, Richard Purdie wrote: > On Thu, 2019-07-04 at 10:27 -0400, Trevor Woerner wrote: > > On Wed 2019-07-03 @ 05:10:14 PM, Richard Purdie wrote: > > > Is there any way you could try pigz 2.4 on your machine, see if > > > the > > > problem still occurred there? If you do rebuild pigz, could you > > > apply > > > the debug patch in master-next? > > > > I've updated the pigz in the $PATH jenkins sees to pigz-2.4. > > > > However, my builds are always updated automatically and always > > build > > from master; there's no way to insert ad-hoc patches into a build. > > That is fine, even just the PATH adjustment will be interesting to > see > the results with, thanks! > > Was that version of pigz patched? FWIW I've patched the one on our > opensuse151 worker so we'll see if that helps shed any light on > things. and it did: http://errors.yoctoproject.org/Errors/Details/250609/ pigz: abort: internal threads error (16, 10) which means from: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next=110ccb56b88af177c0153741a31a9d34b1f75abf + if ((ret = pthread_cond_destroy(&(bolt->cond))) || + (ret = pthread_mutex_destroy(&(bolt->mutex +-fail(ret); ++fail(ret, 10); + my_free(bolt); so pthread_cond_destroy or pthread_mutex_destroy returned EBUSY. Further digging required but at least we know which code path we're on. I wonder if suse did something odd to libpthread... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] i2c-tools: Add alternative for i2ctransfer
i2ctransfer is now also provided by busybox.
Signed-off-by: Adrian Bunk
---
meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
b/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
index 2b4563d4f0..dcbd05aed4 100644
--- a/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
+++ b/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
@@ -34,8 +34,9 @@ RDEPENDS_${PN}-misc = "${PN} perl perl-module-posix \
"
ALTERNATIVE_PRIORITY = "100"
-ALTERNATIVE_${PN} = "i2cdetect i2cdump i2cget i2cset"
+ALTERNATIVE_${PN} = "i2cdetect i2cdump i2cget i2cset i2ctransfer"
ALTERNATIVE_LINK_NAME[i2cdetect] = "${sbindir}/i2cdetect"
ALTERNATIVE_LINK_NAME[i2cdump] = "${sbindir}/i2cdump"
ALTERNATIVE_LINK_NAME[i2cget] = "${sbindir}/i2cget"
ALTERNATIVE_LINK_NAME[i2cset] = "${sbindir}/i2cset"
+ALTERNATIVE_LINK_NAME[i2ctransfer] = "${sbindir}/i2ctransfer"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libdrm: update to 2.4.99
Signed-off-by: Oleksandr Kravchuk
---
.../drm/{libdrm_2.4.98.bb => libdrm_2.4.99.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/drm/{libdrm_2.4.98.bb => libdrm_2.4.99.bb} (95%)
diff --git a/meta/recipes-graphics/drm/libdrm_2.4.98.bb
b/meta/recipes-graphics/drm/libdrm_2.4.99.bb
similarity index 95%
rename from meta/recipes-graphics/drm/libdrm_2.4.98.bb
rename to meta/recipes-graphics/drm/libdrm_2.4.99.bb
index bed542ba05..3cb30a4173 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.98.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.99.bb
@@ -12,8 +12,8 @@ DEPENDS = "libpthread-stubs"
SRC_URI = "http://dri.freedesktop.org/libdrm/${BP}.tar.bz2 \
file://musl-ioctl.patch"
-SRC_URI[md5sum] = "1320b43c4bdb8846c308ec2610b62b64"
-SRC_URI[sha256sum] =
"8be0edccaca3abde8b6bb1431b46354c7fab46e9b91cc6946ba65b51f56f1894"
+SRC_URI[md5sum] = "72539626815b35159a63d45bc4c14ee6"
+SRC_URI[sha256sum] =
"4dbf539c7ed25dbb2055090b77ab87508fc46be39a9379d15fed4b5517e1da5e"
inherit meson pkgconfig manpages
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH 1/3] cve-check: Depends on cve-update-db-native
On Thu, 2019-07-04 at 17:19 +0200, Pierre Le Magourou wrote: > From: Pierre Le Magourou > > do_populate_cve_db is a native task. > > Signed-off-by: Pierre Le Magourou < > pierre.lemagou...@softbankrobotics.com> > --- > meta/classes/cve-check.bbclass | 2 +- > meta/recipes-core/meta/cve-update-db.bb | 1 + > 2 files changed, 2 insertions(+), 1 deletion(-) https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/1015 :( Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-yocto: checksum indirect cfg and scc files
On Thu, Jul 4, 2019 at 12:36 PM wrote: > > On Thu, 2019-07-04 at 12:29 -0400, Bruce Ashfield wrote: > > On Thu, Jul 4, 2019 at 11:18 AM Richard Purdie > > wrote: > > > On Thu, 2019-07-04 at 08:48 -0400, Bruce Ashfield wrote: > > > > On Thu, Jul 4, 2019 at 7:02 AM Zhaolong Zhang < > > > > zhangzl2...@126.com> > > > > wrote: > > > > > Currently, Yocto can not realize the modification of the > > > > > cfg/scc > > > > > files indirectly > > > > > introduced by scc files in custom layers. > > > > > > > > > > Instead of introducing complicated scc parser code, this patch > > > > > walks though > > > > > FILESEXTRAPATHS and takes all the cfg/scc files into account > > > > > when > > > > > calculating > > > > > checksums. > > > > > > > > There used to be a bugzilla around for this .. but I can't find > > > > it > > > > now. > > > > > > > > While the approach isn't wrong, I think it is too heavy, since it > > > > is > > > > looking at *all* the .scc and .cfg files that can be located in > > > > the > > > > search paths, not just the ones that are actually used. > > > > > > That isn't quite right. With the checksums its important to know if > > > a > > > new file appears at location X, we should reparse as it could > > > change > > > the outcome. > > > > > > We therefore have to account for files which doesn't exist as much > > > as > > > the ones that do. > > > > Maybe I'm misunderstanding what you are saying here, but these are > > just sitting around (like unused patch files). They are not on the > > SRC_URI and they are not necessarily used at all. Just because > > someone > > drops a new file in those locations, we should not be re-running the > > meta data task. > > > > What that routine is currently doing is just wrong. > > Agreed, it is. > > I'm just saying that this situation isn't as simple as files exist, we > also need to look at which files don't exist, but that would influence > the build if they did. Aha. > > The patch doesn't do that either! > > > > > This doesn't work since we need to be able to predict the task hash > > > checksum at parse time. We don't have the kern-tools available then > > > to > > > be able to know which ones it would actually use... > > > > So there's only python code allowed in those hash routines ? If so, > > what is there is still wrong, and needs to be reworked. > > It has to be able to work on the information available to it at parse > time. In reality that does mean python code. There are performance > implications to anything too complex. Understood. I'll think on this for a bit. This has been something that I looked into several times, and didn't come up with anything I really liked. Maybe now is the time to solve the issue :) Bruce > > Cheers, > > Richard > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-yocto: checksum indirect cfg and scc files
On Thu, 2019-07-04 at 12:29 -0400, Bruce Ashfield wrote: > On Thu, Jul 4, 2019 at 11:18 AM Richard Purdie > wrote: > > On Thu, 2019-07-04 at 08:48 -0400, Bruce Ashfield wrote: > > > On Thu, Jul 4, 2019 at 7:02 AM Zhaolong Zhang < > > > zhangzl2...@126.com> > > > wrote: > > > > Currently, Yocto can not realize the modification of the > > > > cfg/scc > > > > files indirectly > > > > introduced by scc files in custom layers. > > > > > > > > Instead of introducing complicated scc parser code, this patch > > > > walks though > > > > FILESEXTRAPATHS and takes all the cfg/scc files into account > > > > when > > > > calculating > > > > checksums. > > > > > > There used to be a bugzilla around for this .. but I can't find > > > it > > > now. > > > > > > While the approach isn't wrong, I think it is too heavy, since it > > > is > > > looking at *all* the .scc and .cfg files that can be located in > > > the > > > search paths, not just the ones that are actually used. > > > > That isn't quite right. With the checksums its important to know if > > a > > new file appears at location X, we should reparse as it could > > change > > the outcome. > > > > We therefore have to account for files which doesn't exist as much > > as > > the ones that do. > > Maybe I'm misunderstanding what you are saying here, but these are > just sitting around (like unused patch files). They are not on the > SRC_URI and they are not necessarily used at all. Just because > someone > drops a new file in those locations, we should not be re-running the > meta data task. > > What that routine is currently doing is just wrong. Agreed, it is. I'm just saying that this situation isn't as simple as files exist, we also need to look at which files don't exist, but that would influence the build if they did. The patch doesn't do that either! > > This doesn't work since we need to be able to predict the task hash > > checksum at parse time. We don't have the kern-tools available then > > to > > be able to know which ones it would actually use... > > So there's only python code allowed in those hash routines ? If so, > what is there is still wrong, and needs to be reworked. It has to be able to work on the information available to it at parse time. In reality that does mean python code. There are performance implications to anything too complex. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-yocto: checksum indirect cfg and scc files
On Thu, Jul 4, 2019 at 11:18 AM Richard Purdie wrote: > > On Thu, 2019-07-04 at 08:48 -0400, Bruce Ashfield wrote: > > On Thu, Jul 4, 2019 at 7:02 AM Zhaolong Zhang > > wrote: > > > Currently, Yocto can not realize the modification of the cfg/scc > > > files indirectly > > > introduced by scc files in custom layers. > > > > > > Instead of introducing complicated scc parser code, this patch > > > walks though > > > FILESEXTRAPATHS and takes all the cfg/scc files into account when > > > calculating > > > checksums. > > > > There used to be a bugzilla around for this .. but I can't find it > > now. > > > > While the approach isn't wrong, I think it is too heavy, since it is > > looking at *all* the .scc and .cfg files that can be located in the > > search paths, not just the ones that are actually used. > > That isn't quite right. With the checksums its important to know if a > new file appears at location X, we should reparse as it could change > the outcome. > > We therefore have to account for files which doesn't exist as much as > the ones that do. Maybe I'm misunderstanding what you are saying here, but these are just sitting around (like unused patch files). They are not on the SRC_URI and they are not necessarily used at all. Just because someone drops a new file in those locations, we should not be re-running the meta data task. What that routine is currently doing is just wrong. > > > I do have some old code from the existing bugzilla that I can try and > > locate. The right approach is to have the kern-tools emit the list of > > files, since that's where we know the includes, etc, and what is > > actually going to be used. What you have will also conflict a bit > > with > > some changes that I'm making to tweak the config handling. > > > > Since I can't find the old bugzilla, can you open a new one, put the > > patch there and I can find the code to dump the list of files from > > the tools. > > This doesn't work since we need to be able to predict the task hash > checksum at parse time. We don't have the kern-tools available then to > be able to know which ones it would actually use... So there's only python code allowed in those hash routines ? If so, what is there is still wrong, and needs to be reworked. Bruce > > Cheers, > > Richard > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for wic/plugins: Source that support both EFI and BIOS
On Wed, Jul 3, 2019 at 3:51 AM Richard Purdie wrote: > > On Tue, 2019-07-02 at 15:22 -0400, William Bourque wrote: > > Hi, > > > > The error "scripts/lib/wic/plugins/source/bootimg-biosplusefi.py does > > not exist" is a bit puzzling : this is the new file my patch is > > adding. > > Is this test failure expected for new files? > > > > I sent this using git-sendmail; should I submit using a different way > > (pull request, ...)? > > I think the test is broken so we can ignore that. I've cc'd Sandy so > she might be able to look into this issue if possible as we've seen it > a few times. > > What I did wonder is whether we should be adding some tests to wic for > this new plugin though? > > The existing tests are in meta/lib/oeqa/selftest/cases/wic.py and can > be run with "oe-selftest -r wic", would it make sense to add something > to this as part of this change? > > Cheers, > > Richard > You are right, some tests would be a good idea. That said, I am a bit confused on how to integrate in meta/lib/oeqa/selftest/cases/wic.py Most tests in there check generic functionnalities, I'm not quite sure how to use it to tests the new SourcePlugin() specific functionnalities, instead of just the generic. I will come up with something but it might not be great... but "not great" is better than "nothing" I suppose. Do you want me to resubmit the SourcePlugin code and the tests together? Or would you rather have me submit the tests separately? Thanks - William -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] build failures due to pigz host tool
On Thu, 2019-07-04 at 10:27 -0400, Trevor Woerner wrote: > On Wed 2019-07-03 @ 05:10:14 PM, Richard Purdie wrote: > > Is there any way you could try pigz 2.4 on your machine, see if the > > problem still occurred there? If you do rebuild pigz, could you > > apply > > the debug patch in master-next? > > I've updated the pigz in the $PATH jenkins sees to pigz-2.4. > > However, my builds are always updated automatically and always build > from master; there's no way to insert ad-hoc patches into a build. That is fine, even just the PATH adjustment will be interesting to see the results with, thanks! Was that version of pigz patched? FWIW I've patched the one on our opensuse151 worker so we'll see if that helps shed any light on things. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for "[meta-oe] cve-check: Depends o..." and 2 more
== Series Details == Series: "[meta-oe] cve-check: Depends o..." and 2 more Revision: 1 URL : https://patchwork.openembedded.org/series/18529/ 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[meta-oe,1/3] cve-check: Depends on cve-update-db-native Issue Series sent to the wrong mailing list [test_target_mailing_list] Suggested fixCheck the project's README (meta-oe,1/3) and send the patch to the indicated list * 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 a0a96db236) 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-oe][PATCH 1/3] cve-check: Depends on cve-update-db-native
From: Pierre Le Magourou
do_populate_cve_db is a native task.
Signed-off-by: Pierre Le Magourou
---
meta/classes/cve-check.bbclass | 2 +-
meta/recipes-core/meta/cve-update-db.bb | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 81071e3f19..6ffa0c4688 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -63,7 +63,7 @@ python do_cve_check () {
}
addtask cve_check after do_unpack before do_build
-do_cve_check[depends] = "cve-update-db:do_populate_cve_db"
+do_cve_check[depends] = "cve-update-db-native:do_populate_cve_db"
do_cve_check[nostamp] = "1"
python cve_check_cleanup () {
diff --git a/meta/recipes-core/meta/cve-update-db.bb
b/meta/recipes-core/meta/cve-update-db.bb
index ae8f1a958b..8e553b4f9b 100644
--- a/meta/recipes-core/meta/cve-update-db.bb
+++ b/meta/recipes-core/meta/cve-update-db.bb
@@ -141,3 +141,4 @@ addtask do_populate_cve_db before do_fetch
do_populate_cve_db[nostamp] = "1"
EXCLUDE_FROM_WORLD = "1"
+BBCLASSEXTEND =+ "native"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-oe][PATCH 2/3] cve-update-db: Use NVD CPE data to populate PRODUCTS table
From: Pierre Le Magourou
Instead of using expanded list of affected versions that is not
reliable, use the 'cpe_match' node in the 'configurations' json node.
For cve-check to correctly match affected CVE, the sqlite database need to
contain operator_start, operator_end and the corresponding versions fields.
Signed-off-by: Pierre Le Magourou
---
meta/recipes-core/meta/cve-update-db.bb | 88 +++--
1 file changed, 74 insertions(+), 14 deletions(-)
diff --git a/meta/recipes-core/meta/cve-update-db.bb
b/meta/recipes-core/meta/cve-update-db.bb
index 8e553b4f9b..3ba80a0d28 100644
--- a/meta/recipes-core/meta/cve-update-db.bb
+++ b/meta/recipes-core/meta/cve-update-db.bb
@@ -25,7 +25,7 @@ python do_populate_cve_db() {
YEAR_START = 2002
db_dir = d.getVar("DL_DIR") + '/CVE_CHECK'
-db_file = db_dir + '/nvd-json.db'
+db_file = db_dir + '/nvdcve.db'
json_tmpfile = db_dir + '/nvd.json.gz'
proxy = d.getVar("https_proxy")
cve_f = open(d.getVar("TMPDIR") + '/cve_check', 'a')
@@ -99,9 +99,76 @@ def initialize_db(c):
c.execute("CREATE TABLE IF NOT EXISTS NVD (ID TEXT UNIQUE, SUMMARY TEXT, \
SCOREV2 TEXT, SCOREV3 TEXT, MODIFIED INTEGER, VECTOR TEXT)")
c.execute("CREATE TABLE IF NOT EXISTS PRODUCTS (HASH INTEGER UNIQUE, ID
TEXT, \
-VENDOR TEXT, PRODUCT TEXT, VERSION TEXT, OPERATOR TEXT)")
-c.execute("CREATE INDEX IF NOT EXISTS PRODUCT_IDX ON PRODUCTS \
-(PRODUCT, VERSION)")
+VENDOR TEXT, PRODUCT TEXT, VERSION_START TEXT, OPERATOR_START TEXT, \
+VERSION_END TEXT, OPERATOR_END TEXT)")
+
+def insert_elt(c, db_values):
+product_str = db_values[0] + db_values[1] + db_values[2] + db_values[3]
+hashstr = hash_djb2(product_str)
+db_values.insert(0, hashstr)
+query = "insert or replace into PRODUCTS values (?, ?, ?, ?, ?, ?, ?, ?)"
+c.execute(query, db_values)
+
+def parse_node_and_insert(c, node, cveId):
+# Parse children node if needed
+try:
+for child in node['children']:
+parse_node_and_insert(c, child, cveId)
+except:
+pass
+
+# Exit if the cpe_match node does not exists
+try:
+cpe_match = node['cpe_match']
+except:
+return
+
+for cpe in cpe_match:
+if not cpe['vulnerable']:
+return
+cpe23 = cpe['cpe23Uri'].split(':')
+vendor = cpe23[3]
+product = cpe23[4]
+version = cpe23[5]
+
+if version != '*':
+# Version is defined, this is a '=' match
+db_values = [cveId, vendor, product, version, '=', '', '']
+insert_elt(c, db_values)
+else:
+# Parse start version, end version and operators
+op_start = ''
+op_end = ''
+v_start = ''
+v_end = ''
+
+try:
+if cpe['versionStartIncluding']:
+op_start = '>='
+v_start = cpe['versionStartIncluding']
+except:
+pass
+try:
+if cpe['versionStartExcluding']:
+op_start = '>'
+v_start = cpe['versionStartExcluding']
+except:
+pass
+try:
+if cpe['versionEndIncluding']:
+op_end = '<='
+v_end = cpe['versionEndIncluding']
+except:
+pass
+try:
+if cpe['versionEndExcluding']:
+op_end = '<'
+v_end = cpe['versionEndExcluding']
+except:
+pass
+
+db_values = [cveId, vendor, product, v_start, op_start, v_end,
op_end]
+insert_elt(c, db_values)
def update_db(c, json_filename):
import json
@@ -125,16 +192,9 @@ def update_db(c, json_filename):
c.execute("insert or replace into NVD values (?, ?, ?, ?, ?, ?)",
[cveId, cveDesc, cvssv2, cvssv3, date, accessVector])
-for vendor in elt['cve']['affects']['vendor']['vendor_data']:
-for product in vendor['product']['product_data']:
-for version in product['version']['version_data']:
-product_str =
cveId+vendor['vendor_name']+product['product_name']+version['version_value']
-hashstr = hash_djb2(product_str)
-c.execute("insert or replace into PRODUCTS values (?, ?,
?, ?, ?, ?)",
-[ hashstr, cveId, vendor['vendor_name'],
-product['product_name'],
version['version_value'],
-version['version_affected']])
-
+configurations = elt['configurations']['nodes']
+for config in configurations:
+parse_node_and_insert(c, config, cveId)
addtask do_populate_cve_db before do_fetch
--
2.11.0
--
___
Openembedded-core
[OE-core] [meta-oe][PATCH 3/3] cve-check: Update unpatched CVE matching
From: Pierre Le Magourou
Now that cve-update-db added CPE information to NVD database. We can
check for unpatched versions with operators '<', '<=', '>', and '>='.
Signed-off-by: Pierre Le Magourou
---
meta/classes/cve-check.bbclass | 54 +++---
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 6ffa0c4688..ffd624333f 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -26,7 +26,7 @@ CVE_PRODUCT ??= "${BPN}"
CVE_VERSION ??= "${PV}"
CVE_CHECK_DB_DIR ?= "${DL_DIR}/CVE_CHECK"
-CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvd-json.db"
+CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve.db"
CVE_CHECK_LOG ?= "${T}/cve.log"
CVE_CHECK_TMP_FILE ?= "${TMPDIR}/cve_check"
@@ -189,27 +189,53 @@ def check_cves(d, patched_cves):
conn = sqlite3.connect(db_file)
c = conn.cursor()
-query = """SELECT * FROM PRODUCTS WHERE
- (PRODUCT IS '{0}' AND VERSION = '{1}' AND OPERATOR IS '=') OR
- (PRODUCT IS '{0}' AND OPERATOR IS '<=');"""
+query = "SELECT * FROM PRODUCTS WHERE PRODUCT IS '{0}';"
+
for product in products:
for row in c.execute(query.format(product, pv)):
cve = row[1]
-version = row[4]
-
-try:
-discardVersion = LooseVersion(version) < LooseVersion(pv)
-except:
-discardVersion = True
+version_start = row[4]
+operator_start = row[5]
+version_end = row[6]
+operator_end = row[7]
if pv in cve_whitelist.get(cve, []):
bb.note("%s-%s has been whitelisted for %s" % (product, pv,
cve))
elif cve in patched_cves:
bb.note("%s has been patched" % (cve))
-elif discardVersion:
-bb.debug(2, "Do not consider version %s " % (version))
else:
-cves_unpatched.append(cve)
+if (operator_start == '=' and pv == version_start):
+cves_unpatched.append(cve)
+else:
+if operator_start:
+try:
+to_append_start = (operator_start == '>=' and
LooseVersion(pv) >= LooseVersion(version_start))
+to_append_start |= (operator_start == '>' and
LooseVersion(pv) > LooseVersion(version_start))
+except:
+bb.note("%s: Failed to compare %s %s %s for %s" %
+(product, pv, operator_start,
version_start, cve))
+to_append_start = False
+else:
+to_append_start = False
+
+if operator_end:
+try:
+to_append_end = (operator_end == '<=' and
LooseVersion(pv) <= LooseVersion(version_end))
+to_append_end |= (operator_end == '<' and
LooseVersion(pv) < LooseVersion(version_end))
+except:
+bb.note("%s: Failed to compare %s %s %s for %s" %
+(product, pv, operator_end, version_end,
cve))
+to_append_end = False
+else:
+to_append_end = False
+
+if operator_start and operator_end:
+to_append = to_append_start and to_append_end
+else:
+to_append = to_append_start or to_append_end
+
+if to_append:
+cves_unpatched.append(cve)
bb.debug(2, "%s-%s is not patched for %s" % (product, pv, cve))
conn.close()
@@ -217,7 +243,7 @@ def check_cves(d, patched_cves):
def get_cve_info(d, cves):
"""
-Get CVE information from the database used by cve-check-tool.
+Get CVE information from the database.
Unfortunately the only way to get CVE info is set the output to
html (hard to parse) or query directly the database.
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-yocto: checksum indirect cfg and scc files
On Thu, 2019-07-04 at 08:48 -0400, Bruce Ashfield wrote: > On Thu, Jul 4, 2019 at 7:02 AM Zhaolong Zhang > wrote: > > Currently, Yocto can not realize the modification of the cfg/scc > > files indirectly > > introduced by scc files in custom layers. > > > > Instead of introducing complicated scc parser code, this patch > > walks though > > FILESEXTRAPATHS and takes all the cfg/scc files into account when > > calculating > > checksums. > > There used to be a bugzilla around for this .. but I can't find it > now. > > While the approach isn't wrong, I think it is too heavy, since it is > looking at *all* the .scc and .cfg files that can be located in the > search paths, not just the ones that are actually used. That isn't quite right. With the checksums its important to know if a new file appears at location X, we should reparse as it could change the outcome. We therefore have to account for files which doesn't exist as much as the ones that do. > I do have some old code from the existing bugzilla that I can try and > locate. The right approach is to have the kern-tools emit the list of > files, since that's where we know the includes, etc, and what is > actually going to be used. What you have will also conflict a bit > with > some changes that I'm making to tweak the config handling. > > Since I can't find the old bugzilla, can you open a new one, put the > patch there and I can find the code to dump the list of files from > the tools. This doesn't work since we need to be able to predict the task hash checksum at parse time. We don't have the kern-tools available then to be able to know which ones it would actually use... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for Make systemd as default init manager
== Series Details == Series: Make systemd as default init manager Revision: 1 URL : https://patchwork.openembedded.org/series/18528/ 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[meta-poky,2/2] poky.conf: make systemd as default init manager Issue Series sent to the wrong mailing list [test_target_mailing_list] Suggested fixCheck the project's README (meta-poky,2/2) and send the patch to the indicated list * 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 a0a96db236) 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 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-poky][PATCH 2/2] poky.conf: make systemd as default init manager
From: Kai Kang
Make systemd as default init manager for distro poky. And set sysvinit
as default value for musl considering security.
Update poky-tiny.conf to use new introduced variable INIT_MANGER.
[YOCTO #13031]
Signed-off-by: Kai Kang
---
meta-poky/conf/distro/poky-tiny.conf | 8 ++--
meta-poky/conf/distro/poky.conf | 5 +
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/meta-poky/conf/distro/poky-tiny.conf
b/meta-poky/conf/distro/poky-tiny.conf
index 1f8b6e8ff3..e847c59676 100644
--- a/meta-poky/conf/distro/poky-tiny.conf
+++ b/meta-poky/conf/distro/poky-tiny.conf
@@ -82,12 +82,8 @@ DISTRO_FEATURES_class-native = "${DISTRO_FEATURES_DEFAULT}
${POKY_DEFAULT_DISTRO
DISTRO_FEATURES_class-nativesdk = "${DISTRO_FEATURES_DEFAULT}
${POKY_DEFAULT_DISTRO_FEATURES}"
# enable mdev/busybox for init
-VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
-VIRTUAL-RUNTIME_login_manager = "busybox"
-VIRTUAL-RUNTIME_init_manager = "busybox"
-VIRTUAL-RUNTIME_initscripts = "initscripts"
-VIRTUAL-RUNTIME_keymaps = "keymaps"
-DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
+# because poky-tiny uses musl, set with override libc-musl
+INIT_MANAGER_libc-musl = "mdev-busybox"
# FIXME: Consider adding "modules" to MACHINE_FEATURES and using that in
# packagegroup-core-base to select modutils-initscripts or not. Similar with
"net" and
diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index 78621e6dbf..20ea5637d3 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -84,3 +84,8 @@ require conf/distro/include/no-static-libs.inc
require conf/distro/include/yocto-uninative.inc
require conf/distro/include/security_flags.inc
INHERIT += "uninative"
+
+# Make systemd as default init manager for poky
+# and set sysvinit for musl consider security
+INIT_MANAGER ?= "systemd"
+INIT_MANAGER_libc-musl ?= "sysvinit"
--
2.18.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v7 0/2] Make systemd as default init manager
From: Kai Kang
v7:
* move the main logical to oe-core that not only poky could use it
* rename POKY_INIT_MANAGER with INIT_MANAGER
* remove init-manager-systemd-compat.inc which is not a real separated init
manager
Tested with
1
for arch in qemux86 qemux86-64 qemuarm qemuarm64 qemuppc qemumips qemumips64; do
MACHINE=$arch bitbake core-image-minimal
done
2 run
bitbake core-image-full-cmdline -c testimage
without error with the auto.conf from Yocto autobuilder:
$ cat conf/auto.conf
MACHINE = "qemux86"
DISTRO = "poky"
SDKMACHINE = "x86_64"
PACKAGE_CLASSES = "package_rpm package_deb package_ipk"
#DL_DIR =
'/srv/autobuilder/autobuilder.yoctoproject.org/current_sources'
PRSERV_HOST = 'localhost:0'
#SSTATE_DIR ?=
'/srv/autobuilder/autobuilder.yoctoproject.org/pub/sstate'
TCLIBC = 'musl'
QEMU_USE_KVM = 'True'
INHERIT += 'report-error'
PREMIRRORS = ''
BB_GENERATE_MIRROR_TARBALLS = '1'
#BB_NUMBER_THREADS = '16'
#PARALLEL_MAKE = '-j 16'
BB_TASK_NICE_LEVEL = '5'
BB_TASK_NICE_LEVEL_task-testimage = '0'
BB_TASK_IONICE_LEVEL = '2.7'
BB_TASK_IONICE_LEVEL_task-testimage = '2.1'
INHERIT += 'testimage'
TEST_QEMUBOOT_TIMEOUT = '1500'
SANITY_TESTED_DISTROS = ''
SDK_EXT_TYPE = 'minimal'
SDK_INCLUDE_TOOLCHAIN = '1'
BB_DISKMON_DIRS = 'STOPTASKS,${TMPDIR},1G,100K STOPTASKS,${DL_DIR},1G
STOPTASKS,${SSTATE_DIR},1G STOPTASKS,/tmp,100M,100K
ABORT,${TMPDIR},100M,1K ABORT,${DL_DIR},100M ABORT,${SSTATE_DIR},100M
ABORT,/tmp,10M,1K'
Kai Kang (2):
defaultsetup.conf: enable select init manager
poky.conf: make systemd as default init manager
meta-poky/conf/distro/poky-tiny.conf | 8 ++--
meta-poky/conf/distro/poky.conf| 5 +
meta/conf/distro/defaultsetup.conf | 3 +++
meta/conf/distro/include/init-manager-mdev-busybox.inc | 7 +++
meta/conf/distro/include/init-manager-systemd.inc | 6 ++
meta/conf/distro/include/init-manager-sysvinit.inc | 6 ++
6 files changed, 29 insertions(+), 6 deletions(-)
create mode 100644 meta/conf/distro/include/init-manager-mdev-busybox.inc
create mode 100644 meta/conf/distro/include/init-manager-systemd.inc
create mode 100644 meta/conf/distro/include/init-manager-sysvinit.inc
--
2.18.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH 1/2] defaultsetup.conf: enable select init manager
From: Kai Kang
Introduce a new variable INIT_MANAGER and create 3 init-manager-*.inc
files to configure init manager settings. Available values of
INIT_MANAGER are sysvinit, systemd and mdev-busybox. 'sysvinit' is set
by default for compatibility.
[YOCTO #13031]
Signed-off-by: Kai Kang
---
meta/conf/distro/defaultsetup.conf | 3 +++
meta/conf/distro/include/init-manager-mdev-busybox.inc | 7 +++
meta/conf/distro/include/init-manager-systemd.inc | 6 ++
meta/conf/distro/include/init-manager-sysvinit.inc | 6 ++
4 files changed, 22 insertions(+)
create mode 100644 meta/conf/distro/include/init-manager-mdev-busybox.inc
create mode 100644 meta/conf/distro/include/init-manager-systemd.inc
create mode 100644 meta/conf/distro/include/init-manager-sysvinit.inc
diff --git a/meta/conf/distro/defaultsetup.conf
b/meta/conf/distro/defaultsetup.conf
index 20e61232e9..057e2f761f 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -23,3 +23,6 @@ PACKAGE_CLASSES ?= "package_ipk"
INHERIT_BLACKLIST = "blacklist"
INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
${INHERIT_BLACKLIST}"
+
+INIT_MANAGER ??= "sysvinit"
+require conf/distro/include/init-manager-${INIT_MANAGER}.inc
diff --git a/meta/conf/distro/include/init-manager-mdev-busybox.inc
b/meta/conf/distro/include/init-manager-mdev-busybox.inc
new file mode 100644
index 00..b07d9de5b4
--- /dev/null
+++ b/meta/conf/distro/include/init-manager-mdev-busybox.inc
@@ -0,0 +1,7 @@
+# enable mdev/busybox for init
+DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " systemd sysvinit"
+VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
+VIRTUAL-RUNTIME_init_manager = "busybox"
+VIRTUAL-RUNTIME_initscripts = "initscripts"
+VIRTUAL-RUNTIME_keymaps = "keymaps"
+VIRTUAL-RUNTIME_login_manager = "busybox"
diff --git a/meta/conf/distro/include/init-manager-systemd.inc
b/meta/conf/distro/include/init-manager-systemd.inc
new file mode 100644
index 00..6542e29cfd
--- /dev/null
+++ b/meta/conf/distro/include/init-manager-systemd.inc
@@ -0,0 +1,6 @@
+# Use systemd for system initialization
+DISTRO_FEATURES_append = " systemd"
+DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"
+VIRTUAL-RUNTIME_init_manager = "systemd"
+VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
+VIRTUAL-RUNTIME_login_manager = "shadow-base"
diff --git a/meta/conf/distro/include/init-manager-sysvinit.inc
b/meta/conf/distro/include/init-manager-sysvinit.inc
new file mode 100644
index 00..7725b30e1e
--- /dev/null
+++ b/meta/conf/distro/include/init-manager-sysvinit.inc
@@ -0,0 +1,6 @@
+# Use sysvinit for system initialization
+DISTRO_FEATURES_append = " sysvinit"
+DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " systemd"
+VIRTUAL-RUNTIME_init_manager = "sysvinit"
+VIRTUAL-RUNTIME_initscripts = "initscripts"
+VIRTUAL-RUNTIME_login_manager = "busybox"
--
2.18.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] build failures due to pigz host tool
On Wed 2019-07-03 @ 05:10:14 PM, Richard Purdie wrote: > Is there any way you could try pigz 2.4 on your machine, see if the > problem still occurred there? If you do rebuild pigz, could you apply > the debug patch in master-next? I've updated the pigz in the $PATH jenkins sees to pigz-2.4. However, my builds are always updated automatically and always build from master; there's no way to insert ad-hoc patches into a build. The job of my overnight builds is to keep tabs on master branches and ensure they continue to build, not to test groups of patches in anticipation of pushing new things into the repository. Therefore my Jenkins build flow has been structured this specific way on purpose. Since these failures only occur for me from builds kicked off by Jenkins, I won't be able to easily help test patches unless I were to create a new Jenkins workflow. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] kernel-yocto: checksum indirect cfg and scc files
On Thu, Jul 4, 2019 at 7:02 AM Zhaolong Zhang wrote:
>
> Currently, Yocto can not realize the modification of the cfg/scc files
> indirectly
> introduced by scc files in custom layers.
>
> Instead of introducing complicated scc parser code, this patch walks though
> FILESEXTRAPATHS and takes all the cfg/scc files into account when calculating
> checksums.
There used to be a bugzilla around for this .. but I can't find it now.
While the approach isn't wrong, I think it is too heavy, since it is
looking at *all* the .scc and .cfg files that can be located in the
search paths, not just the ones that are actually used.
I do have some old code from the existing bugzilla that I can try and
locate. The right approach is to have the kern-tools emit the list of
files, since that's where we know the includes, etc, and what is
actually going to be used. What you have will also conflict a bit with
some changes that I'm making to tweak the config handling.
Since I can't find the old bugzilla, can you open a new one, put the
patch there and I can find the code to dump the list of files from the
tools.
Bruce
>
> Signed-off-by: Zhaolong Zhang
> ---
> meta/classes/kernel-yocto.bbclass | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/meta/classes/kernel-yocto.bbclass
> b/meta/classes/kernel-yocto.bbclass
> index ed9bcfa57c..a9aac8a9d9 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -69,6 +69,24 @@ def get_machine_branch(d, default):
>
> return default
>
> +def get_files_in_filesextrapaths(d):
> +extrapaths = []
> +extrafiles = []
> +extrapathsvalue = (d.getVar("FILESEXTRAPATHS") or "")
> +# Remove default flag which was used for checking
> +extrapathsvalue = extrapathsvalue.replace("__default:", "")
> +extrapaths = extrapathsvalue.split(":")
> +for path in extrapaths:
> +for root, dirs, files in os.walk(path):
> +for name in files:
> +base, ext = os.path.splitext(name)
> +if ext and ext in [".scc", ".cfg"]:
> +filepath = os.path.join(root, name)
> +extrafiles.append(filepath + ":" +
> str(os.path.exists(filepath)))
> +return " ".join(extrafiles)
> +
> +
> +
> do_kernel_metadata() {
> set +e
> cd ${S}
> @@ -296,6 +314,7 @@ do_kernel_checkout[dirs] = "${S}"
> addtask kernel_checkout before do_kernel_metadata after do_unpack
> addtask kernel_metadata after do_validate_branches do_unpack before do_patch
> do_kernel_metadata[depends] = "kern-tools-native:do_populate_sysroot"
> +do_kernel_metadata[file-checksums] = " ${@get_files_in_filesextrapaths(d)}"
> do_validate_branches[depends] = "kern-tools-native:do_populate_sysroot"
>
> do_kernel_configme[depends] +=
> "virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
> --
> 2.19.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] go.bbclass: remove ptest inherit
On Wed, Jul 3, 2019 at 2:25 AM wrote:
>
> From: Mingli Yu
>
> Remove the ptest bbclass inherit logic to let
> each recipe inherit ptest individually if the
> specified recipe wants to support ptest to avoid
> the recipe which inherits go bblcass inheriting
> ptest automatically.
Recipes will have to inherit ptest before inheriting go, which seems
counter-intuitive; with ptest after go, the compile_ptest and
install_ptest functions will be the null ones from ptest.bbclass.
Ross's suggestion of breaking out the ptest-related functions from
go.bbclass into a separate bbclass would be better. Perhaps called
ptest-go.bbclass, similar to the ones already there for gnome and
perl.
Thanks,
-Matt
> Signed-off-by: Mingli Yu
> ---
> meta/classes/go.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> index e05a5c641c..424d869540 100644
> --- a/meta/classes/go.bbclass
> +++ b/meta/classes/go.bbclass
> @@ -1,4 +1,4 @@
> -inherit goarch ptest
> +inherit goarch
>
> GO_PARALLEL_BUILD ?= "${@oe.utils.parallel_make_argument(d, '-p %d')}"
>
> --
> 2.21.0
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] glibc/glibc-locale: Fix do_stash_locale to work with usrmerge and multilibs
On 7/4/19 5:57 AM, Adrian Bunk wrote: On Thu, Jul 04, 2019 at 11:13:18AM +0200, Martin Jansa wrote: I don't see how this change (or the previous glibc-locale one) would cause that, but since the oe-core upgrade yesterday I'm seeing following glibc-locale.do_package failure: http://errors.yoctoproject.org/Errors/Details/250557/ DEBUG: Executing shell function do_prep_locale_tree tar: i18n: Cannot stat: No such file or directory tar: Exiting with failure status due to previous errors gzip: TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc-locale/2.29-r0/locale-tree//usr/share/i18n/charmaps/*gz.gz: No such file or directory WARNING: TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc-locale/2.29-r0/temp/run.do_prep_locale_tree.23303:1 exit 1 from 'gunzip $i' anyone else seeing this? Yes. I don't know that it was specifically this change that causes the problem but rather any change to this function. If that is not the case can either of you send me your local.conf file, and I'll try to reproduce it. If the following doesn't work around the problem, there is clearly another corner case that is not well understood. bitbake -c cleansstate glibc glibc-locale I believe that any change to the .inc file which has locale stash function will cause the problem due to the fact it performs and "mv" operation to move the files. When it runs a second time, there are no more files to move and you will not have them for use later on. When I was experimenting earlier, I tried running the glibc temp/run.do_install script to put the files back, but then hit a problem with localdef being missing, because it comes from the temp/run.do_compile functions. My conclusion thus far has been is that the ties between the glibc and glibc-locale are very subtle and break easily. This is a separate problem than what I was attempting to fix, where the usrmerge + multilibs didn't even get the correct files in the first place. Cheers, Jason. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel-yocto: checksum indirect cfg and scc files
Currently, Yocto can not realize the modification of the cfg/scc files
indirectly
introduced by scc files in custom layers.
Instead of introducing complicated scc parser code, this patch walks though
FILESEXTRAPATHS and takes all the cfg/scc files into account when calculating
checksums.
Signed-off-by: Zhaolong Zhang
---
meta/classes/kernel-yocto.bbclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index ed9bcfa57c..a9aac8a9d9 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -69,6 +69,24 @@ def get_machine_branch(d, default):
return default
+def get_files_in_filesextrapaths(d):
+extrapaths = []
+extrafiles = []
+extrapathsvalue = (d.getVar("FILESEXTRAPATHS") or "")
+# Remove default flag which was used for checking
+extrapathsvalue = extrapathsvalue.replace("__default:", "")
+extrapaths = extrapathsvalue.split(":")
+for path in extrapaths:
+for root, dirs, files in os.walk(path):
+for name in files:
+base, ext = os.path.splitext(name)
+if ext and ext in [".scc", ".cfg"]:
+filepath = os.path.join(root, name)
+extrafiles.append(filepath + ":" +
str(os.path.exists(filepath)))
+return " ".join(extrafiles)
+
+
+
do_kernel_metadata() {
set +e
cd ${S}
@@ -296,6 +314,7 @@ do_kernel_checkout[dirs] = "${S}"
addtask kernel_checkout before do_kernel_metadata after do_unpack
addtask kernel_metadata after do_validate_branches do_unpack before do_patch
do_kernel_metadata[depends] = "kern-tools-native:do_populate_sysroot"
+do_kernel_metadata[file-checksums] = " ${@get_files_in_filesextrapaths(d)}"
do_validate_branches[depends] = "kern-tools-native:do_populate_sysroot"
do_kernel_configme[depends] +=
"virtual/${TARGET_PREFIX}binutils:do_populate_sysroot"
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] glibc/glibc-locale: Fix do_stash_locale to work with usrmerge and multilibs
On Thu, Jul 04, 2019 at 11:13:18AM +0200, Martin Jansa wrote: > I don't see how this change (or the previous glibc-locale one) would cause > that, but since the oe-core upgrade yesterday I'm seeing following > glibc-locale.do_package failure: > http://errors.yoctoproject.org/Errors/Details/250557/ > > DEBUG: Executing shell function do_prep_locale_tree > tar: i18n: Cannot stat: No such file or directory > tar: Exiting with failure status due to previous errors > gzip: > TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc-locale/2.29-r0/locale-tree//usr/share/i18n/charmaps/*gz.gz: > No such file or directory > WARNING: > TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc-locale/2.29-r0/temp/run.do_prep_locale_tree.23303:1 > exit 1 from 'gunzip $i' > > anyone else seeing this? Yes. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] buildhistory_analysis: ignore ownership for sysroot diffs
The sysroot isn't populated under pseudo, so ownership differences should be
ignored.
Signed-off-by: Ross Burton
---
meta/lib/oe/buildhistory_analysis.py | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oe/buildhistory_analysis.py
b/meta/lib/oe/buildhistory_analysis.py
index 8af76c6b3a3..708e1b388e2 100644
--- a/meta/lib/oe/buildhistory_analysis.py
+++ b/meta/lib/oe/buildhistory_analysis.py
@@ -282,7 +282,7 @@ def file_list_to_dict(lines):
return adict
-def compare_file_lists(alines, blines):
+def compare_file_lists(alines, blines, compare_ownership=True):
adict = file_list_to_dict(alines)
bdict = file_list_to_dict(blines)
filechanges = []
@@ -294,16 +294,20 @@ def compare_file_lists(alines, blines):
newvalue = newsplitv[0][0]
if oldvalue != newvalue:
filechanges.append(FileChange(path,
FileChange.changetype_type, oldvalue, newvalue))
+
# Check permissions
oldvalue = splitv[0][1:]
newvalue = newsplitv[0][1:]
if oldvalue != newvalue:
filechanges.append(FileChange(path,
FileChange.changetype_perms, oldvalue, newvalue))
-# Check owner/group
-oldvalue = '%s/%s' % (splitv[1], splitv[2])
-newvalue = '%s/%s' % (newsplitv[1], newsplitv[2])
-if oldvalue != newvalue:
-filechanges.append(FileChange(path,
FileChange.changetype_ownergroup, oldvalue, newvalue))
+
+if compare_ownership:
+# Check owner/group
+oldvalue = '%s/%s' % (splitv[1], splitv[2])
+newvalue = '%s/%s' % (newsplitv[1], newsplitv[2])
+if oldvalue != newvalue:
+filechanges.append(FileChange(path,
FileChange.changetype_ownergroup, oldvalue, newvalue))
+
# Check symlink target
if newsplitv[0][0] == 'l':
if len(splitv) > 3:
@@ -574,7 +578,7 @@ def process_changes(repopath, revision1, revision2='HEAD',
report_all=False, rep
elif filename == 'sysroot':
alines =
d.a_blob.data_stream.read().decode('utf-8').splitlines()
blines =
d.b_blob.data_stream.read().decode('utf-8').splitlines()
-filechanges = compare_file_lists(alines,blines)
+filechanges = compare_file_lists(alines,blines,
compare_ownership=False)
if filechanges:
chg = ChangeRecord(path, filename, None, None, True)
chg.filechanges = filechanges
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix systemd_preset_all
> -Original Message-
> From: ChenQi
> Sent: den 3 juli 2019 03:49
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix
> systemd_preset_all
>
> On 07/03/2019 05:04 AM, Peter Kjellerstedt wrote:
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
> >> core-boun...@lists.openembedded.org> On Behalf Of ChenQi
> >> Sent: den 2 juli 2019 03:39
> >> To: Peter Kjellerstedt ; openembedded-
> >> c...@lists.openembedded.org
> >> Subject: Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix
> >> systemd_preset_all
> >>
> >> On 07/02/2019 07:34 AM, Peter Kjellerstedt wrote:
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> >> core-boun...@lists.openembedded.org> On Behalf Of Chen Qi
> Sent: den 1 juli 2019 06:16
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH V2 1/1] image.bbclass: fix
> >> systemd_preset_all
> Check the existence of systemd before using systemctl to preset
> >> units.
> This is because even if 'systemd' is in DISTRO_FEATURES, it's
> >> possible
> that systemd is not even installed. e.g. container-test-image in
> meta-selftest layer.
>
> As systemd DEPENDS on systemd-systemctl-native, the existence of
> >> systemd
> also ensures the existence of systemd-systemctl-native.
>
> This would fix the following test case when using systemd as the
> >> init
> manager.
>
> containerimage.ContainerImageTests.test_expected_files
>
> Also remove the IMAGE_EXTRADEPENDS setting, as nothing references
> >> this
> variable.
>
> Signed-off-by: Chen Qi
> ---
> meta/classes/image.bbclass | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/image.bbclass
> b/meta/classes/image.bbclass
> index d2b2fb9..7daa97e 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -666,10 +666,11 @@ reproducible_final_image_task () {
> }
>
> systemd_preset_all () {
> -systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only
> >> preset-all
> +if [ -e ${IMAGE_ROOTFS}${root_prefix}/lib/systemd/systemd ];
> >> then
> >>> ^^
> >>> That should be ${systemd_system_unitdir}, which will also use the
> >> correct path
> >>> (it is /lib/systemd/system, not /lib/systemd/systemd).
> >> I'm checking the systemd binary under ${root_prefix}/lib/systemd,
> not
> >> the directory holding units.
> > Right, my bad. Still, then the path above should be
> > "${IMAGE_ROOTFS}${systemd_unitdir}/systemd".
>
> In current OE, ${systemd_unitdir} = ${root_prefix}/lib/systemd.
> And in systemd recipe, we have:
> [ ! -e ${D}/init ] && ln -s ${rootlibexecdir}/systemd/systemd ${D}/init
> It does not write as `ln -s ${systemd_unitdir}/systemd/systemd'.
> I don't want to use a directory whose name indicates 'unit' when
> checking a binary.
Well, the name of the systemd_unitdir variable is misleading, as it
does not in fact refer to a unit directory. The corresponding name in
the systemd.pc file is systemdutildir, which I guess would have been
a better name for the variable too (albeit a bit late to change it now).
Anyway, it is not very likely that the path to the systemd binary will
change, so if you prefer to use the ${root_prefix}/lib/systemd path
instead of ${systemd_unitdir}, then go ahead.
> Regards,
> Chen Qi
>
> >> Regards,
> >> Chen Qi
> >>
> +systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only
> >> preset-all
> +fi
> }
>
> -IMAGE_EXTRADEPENDS += "${@ 'systemd-systemctl-native' if
> >> bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and
> not
> >> bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False,
> d)
> >> else ''}"
> IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_preset_all;'
> if
> >> bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and
> not
> >> bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False,
> d)
> >> else ''} reproducible_final_image_task; "
> CVE_PRODUCT = ""
> --
> 1.9.1
> >>> //Peter
> > //Peter
//Peter
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/3] glibc/glibc-locale: Fix do_stash_locale to work with usrmerge and multilibs
I don't see how this change (or the previous glibc-locale one) would cause
that, but since the oe-core upgrade yesterday I'm seeing following
glibc-locale.do_package failure:
http://errors.yoctoproject.org/Errors/Details/250557/
DEBUG: Executing shell function do_prep_locale_tree
tar: i18n: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
gzip:
TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc-locale/2.29-r0/locale-tree//usr/share/i18n/charmaps/*gz.gz:
No such file or directory
WARNING:
TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc-locale/2.29-r0/temp/run.do_prep_locale_tree.23303:1
exit 1 from 'gunzip $i'
anyone else seeing this?
On Tue, Jul 2, 2019 at 10:16 PM Jason Wessel
wrote:
> The do_stash_locale was not working consistently across the 4 build
> configurations and the multilib, usrmerge configuration would fail
> entirely with the obscure message:
>
> | DEBUG: Executing shell function do_prep_locale_tree
> | tar: i18n: Cannot stat: No such file or directory
> | tar: Exiting with failure status due to previous errors
> | gzip:
> /poky/build/tmp/work/core2-64-poky-linux/glibc-locale/2.29-r0/locale-tree//usr/share/i18n/charmaps/*gz.gz:
> No such file or directory
> | WARNING:
> /poky/build/tmp/work/core2-64-poky-linux/glibc-locale/2.29-r0/temp/run.do_prep_locale_tree.124690:1
> exit 1 from 'gunzip $i'
>
> Here is the 4 build configurations without the patch applied:
>
> A) x86-64 no multilibs, no usrmerge
> find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v
> nscd.service |wc -l
> 909
> B) x86-64 no multilibs, usrmerge
> find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v
> nscd.service |wc -l
> 909
> C) x86-64 multilibs, no usrmerge
> find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v
> nscd.service |wc -l
> 885
> D) x86-64 multilibs, usrmerge
> find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v
> nscd.service |wc -l
> 864
>
> The issue here is that all the moves should be processed first, then a
> copy should be made of the lib directories, but only in the case they
> are different when using the usrmerge feature. Even though the build
> worked for the multilib configuration without usrmerge, the content
> was not the same.
>
> After applying the patch the same number of files are in all the
> configurations. The list of files was also diffed, after normalizing
> the directory names to ensure all the correct files were copied.
>
> Ultimately there are probably additional files that should be pruned
> from what is copied to the stated_locale, but the purpose of this
> patch is make it 100% consistent between the build types and fix the
> builds.
>
> Signed-off-by: Jason Wessel
> ---
> meta/recipes-core/glibc/glibc-package.inc | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/meta/recipes-core/glibc/glibc-package.inc
> b/meta/recipes-core/glibc/glibc-package.inc
> index a1d79b3075..ff17a193c3 100644
> --- a/meta/recipes-core/glibc/glibc-package.inc
> +++ b/meta/recipes-core/glibc/glibc-package.inc
> @@ -162,21 +162,28 @@ bashscripts = "mtrace sotruss xtrace"
> do_stash_locale () {
> dest=${LOCALESTASH}
> install -d ${dest}${base_libdir} ${dest}${bindir} ${dest}${libdir}
> ${dest}${datadir}
> - if [ "${base_libdir}" != "${libdir}" ]; then
> - cp -fpPR ${D}${base_libdir}/* ${dest}${base_libdir}
> - fi
> + # Hide away the locale data from the deployment
> if [ -e ${D}${bindir}/localedef ]; then
> mv -f ${D}${bindir}/localedef ${dest}${bindir}
> fi
> if [ -e ${D}${libdir}/gconv ]; then
> mv -f ${D}${libdir}/gconv ${dest}${libdir}
> fi
> - if [ -e ${D}${exec_prefix}/lib ]; then
> - cp -fpPR ${D}${exec_prefix}/lib ${dest}${exec_prefix}
> - fi
> if [ -e ${D}${datadir}/i18n ]; then
> mv ${D}${datadir}/i18n ${dest}${datadir}
> fi
> +
> + # Make a copy of all the libraries into the locale stash
> + cp -fpPR ${D}${libdir}/* ${dest}${libdir}
> + if [ "${base_libdir}" != "${libdir}" ]; then
> + cp -fpPR ${D}${base_libdir}/* ${dest}${base_libdir}
> + fi
> + if [ -e ${D}${exec_prefix}/lib ]; then
> + if [ ${exec_prefix}/lib != ${base_libdir} ] && [
> ${exec_prefix}/lib != ${libdir} ]; then
> + cp -fpPR ${D}${exec_prefix}/lib
> ${dest}${exec_prefix}
> + fi
> + fi
> +
> cp -fpPR ${D}${datadir}/* ${dest}${datadir}
> rm -rf ${D}${datadir}/locale/
> cp -fpPR ${WORKDIR}/SUPPORTED ${dest}
> --
> 2.21.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
___
Openembedded-core mailing list
Re: [OE-core] ✗ patchtest: failure for wic/plugins: Source that support both EFI and BIOS
On 7/3/19 3:51 PM, Richard Purdie wrote: On Tue, 2019-07-02 at 15:22 -0400, William Bourque wrote: Hi, The error "scripts/lib/wic/plugins/source/bootimg-biosplusefi.py does not exist" is a bit puzzling : this is the new file my patch is adding. Is this test failure expected for new files? I sent this using git-sendmail; should I submit using a different way (pull request, ...)? I think the test is broken so we can ignore that. I've cc'd Sandy so she might be able to look into this issue if possible as we've seen it a few times. I checked the test case, and current test only support modified file well, for new add file, enhancement is needed, I have file a bug in bugzilla, I will fix this when have time. What I did wonder is whether we should be adding some tests to wic for this new plugin though? The existing tests are in meta/lib/oeqa/selftest/cases/wic.py and can be run with "oe-selftest -r wic", would it make sense to add something to this as part of this change? Cheers, Richard -- BRs Sandy(Li Changqing) -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for wic/plugins: Source that support both EFI and BIOS
On 7/3/19 3:51 PM, Richard Purdie wrote: On Tue, 2019-07-02 at 15:22 -0400, William Bourque wrote: Hi, The error "scripts/lib/wic/plugins/source/bootimg-biosplusefi.py does not exist" is a bit puzzling : this is the new file my patch is adding. Is this test failure expected for new files? I sent this using git-sendmail; should I submit using a different way (pull request, ...)? I think the test is broken so we can ignore that. I've cc'd Sandy so she might be able to look into this issue if possible as we've seen it a few times. I checked the test case, and current test only support modified file well, for new add file, enhancement is needed, I have file a bug in bugzilla, I will fix this when have time. What I did wonder is whether we should be adding some tests to wic for this new plugin though? The existing tests are in meta/lib/oeqa/selftest/cases/wic.py and can be run with "oe-selftest -r wic", would it make sense to add something to this as part of this change? Cheers, Richard -- BRs Sandy(Li Changqing) -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [warrior][PATCH] gstreamer1.0-vaapi: backport jpeg encode/decode fixes
Backport patches from 1.15 to fix JPEG encode/decode issues when
using VAAPI with Intel media-driver. See for details:
https://bugzilla.gnome.org/show_bug.cgi?id=796705
https://bugzilla.gnome.org/show_bug.cgi?id=796505
Signed-off-by: Anuj Mittal
---
...der-release-VA-buffers-after-vaEndPicture.patch | 45 +++
...ibs-encoder-jpeg-set-component-id-and-Tqi.patch | 65 ++
.../gstreamer/gstreamer1.0-vaapi_1.14.4.bb | 2 +
3 files changed, 112 insertions(+)
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-libs-decoder-release-VA-buffers-after-vaEndPicture.patch
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-libs-encoder-jpeg-set-component-id-and-Tqi.patch
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-libs-decoder-release-VA-buffers-after-vaEndPicture.patch
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-libs-decoder-release-VA-buffers-after-vaEndPicture.patch
new file mode 100644
index 000..b52e61b
--- /dev/null
+++
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-libs-decoder-release-VA-buffers-after-vaEndPicture.patch
@@ -0,0 +1,45 @@
+From bb8894aaf934b3af4d44cf54e860510fe4d615b3 Mon Sep 17 00:00:00 2001
+From: Tianhao Liu
+Date: Thu, 7 Jun 2018 09:34:11 +0800
+Subject: [PATCH] libs: decoder: release VA buffers after vaEndPicture
+
+This change is due a problem decoding JPEGs with Intel's media-driver:
+no image was generated.
+
+This patch relases the VA buffers after vaEndPicture() is called,
+and not before (after vaRenderPicture()).
+
+https://bugzilla.gnome.org/show_bug.cgi?id=796505
+
+Upstream-Status: Backport
[https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/commit/bb8894aaf934b3af4d44cf54e860510fe4d615b3]
+Signed-off-by: Anuj Mittal
+---
+ gst-libs/gst/vaapi/gstvaapidecoder_objects.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/gst-libs/gst/vaapi/gstvaapidecoder_objects.c
b/gst-libs/gst/vaapi/gstvaapidecoder_objects.c
+index 20d4f55..2dd4c27 100644
+--- a/gst-libs/gst/vaapi/gstvaapidecoder_objects.c
b/gst-libs/gst/vaapi/gstvaapidecoder_objects.c
+@@ -304,12 +304,17 @@ gst_vaapi_picture_decode (GstVaapiPicture * picture)
+ status = vaRenderPicture (va_display, va_context, va_buffers, 2);
+ if (!vaapi_check_status (status, "vaRenderPicture()"))
+ return FALSE;
++ }
++
++ status = vaEndPicture (va_display, va_context);
++
++ for (i = 0; i < picture->slices->len; i++) {
++GstVaapiSlice *const slice = g_ptr_array_index (picture->slices, i);
+
+ vaapi_destroy_buffer (va_display, >param_id);
+ vaapi_destroy_buffer (va_display, >data_id);
+ }
+
+- status = vaEndPicture (va_display, va_context);
+ if (!vaapi_check_status (status, "vaEndPicture()"))
+ return FALSE;
+ return TRUE;
+--
+2.7.4
+
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-libs-encoder-jpeg-set-component-id-and-Tqi.patch
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-libs-encoder-jpeg-set-component-id-and-Tqi.patch
new file mode 100644
index 000..eb1228b
--- /dev/null
+++
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-libs-encoder-jpeg-set-component-id-and-Tqi.patch
@@ -0,0 +1,65 @@
+From f5eb4faa5914f3745820e557ac2401a7d738be66 Mon Sep 17 00:00:00 2001
+From: Tianhao Liu
+Date: Wed, 4 Jul 2018 12:51:10 +0800
+Subject: [PATCH] libs: encoder: jpeg: set component id and Tqi
+
+This change is due a problem encoding JPEGs with Intel's
+media-driver: green/black image when playback jpeg
+
+This patch sets component identifier and quantization table
+destination selector in frame header to support packing headers
+by Intel's media-driver that does not accept packed header
+in AP level.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=796705
+
+Upstream-Status: Backport
[https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/commit/f5eb4faa5914f3745820e557ac2401a7d738be66]
+Signed-off-by: Anuj Mittal
+---
+ gst-libs/gst/vaapi/gstvaapiencoder_jpeg.c | 14 +-
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+diff --git a/gst-libs/gst/vaapi/gstvaapiencoder_jpeg.c
b/gst-libs/gst/vaapi/gstvaapiencoder_jpeg.c
+index b3f409d..8491fbc 100644
+--- a/gst-libs/gst/vaapi/gstvaapiencoder_jpeg.c
b/gst-libs/gst/vaapi/gstvaapiencoder_jpeg.c
+@@ -205,6 +205,7 @@ fill_picture (GstVaapiEncoderJpeg * encoder,
+ GstVaapiEncPicture * picture,
+ GstVaapiCodedBuffer * codedbuf, GstVaapiSurfaceProxy * surface)
+ {
++ guint i;
+ VAEncPictureParameterBufferJPEG *const pic_param = picture->param;
+
+ memset (pic_param, 0, sizeof (VAEncPictureParameterBufferJPEG));
+@@ -224,6 +225,11 @@ fill_picture (GstVaapiEncoderJpeg * encoder,
+ pic_param->num_scan = 1;
+ pic_param->num_components = encoder->n_components;
+ pic_param->quality = encoder->quality;
++ for (i = 0; i < pic_param->num_components; i++) {
++
