[OE-core] [PATCH] gstreamer1.0-vaapi: downgrade vaapisink to marginal rank
Using vaapisink (which doesn't supports DRI3 [1] and uses DRI2) with
default poky configuration currently results in an unresponsive display
because DRI2 rendering doesn't work (as of xserver 1.20.3) in non-composited
environments [2].
Downgrade vaapisink to marginal for now so playbin (and in turn gst-play
and gtk-play examples) uses next best sink element and works out of box.
[1] https://github.com/intel/libva/issues/122
[2] https://gitlab.freedesktop.org/xorg/xserver/issues/13
Signed-off-by: Anuj Mittal
---
.../0001-vaapsink-downgrade-to-marginal.patch | 46 +++
.../gstreamer/gstreamer1.0-vaapi_1.14.4.bb| 3 +-
2 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-vaapsink-downgrade-to-marginal.patch
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-vaapsink-downgrade-to-marginal.patch
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-vaapsink-downgrade-to-marginal.patch
new file mode 100644
index 00..c861f3bed2
--- /dev/null
+++
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi/0001-vaapsink-downgrade-to-marginal.patch
@@ -0,0 +1,46 @@
+From 0c28cf7bfa90f8947833722cddf23d513490c6c3 Mon Sep 17 00:00:00 2001
+From: Anuj Mittal
+Date: Wed, 28 Nov 2018 15:08:48 +0800
+Subject: [PATCH] vaapsink: downgrade to marginal
+
+Using vaapisink with default poky configuration results in an
+unresponsive display as of today because DRI2 rendering is currently broken
+in non composited environments [1] and libva doesn't support DRI3 [2].
+
+Downgrade vaapisink to marginal for now so playbin (and in turn gst-play
+and gtk-play examples) use xvimagesink or others out of box.
+
+[1] https://gitlab.freedesktop.org/xorg/xserver/issues/13
+[2] https://github.com/intel/libva/issues/122
+
+Upstream-Status: Pending
+
+Signed-off-by: Anuj Mittal
+---
+ gst/vaapi/gstvaapi.c | 6 +-
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+diff --git a/gst/vaapi/gstvaapi.c b/gst/vaapi/gstvaapi.c
+index 9a82454..4d94f2b 100644
+--- a/gst/vaapi/gstvaapi.c
b/gst/vaapi/gstvaapi.c
+@@ -210,7 +210,6 @@ plugin_init (GstPlugin * plugin)
+ {
+ GstVaapiDisplay *display;
+ GArray *decoders;
+- guint rank;
+
+ plugin_add_dependencies (plugin);
+
+@@ -235,10 +234,7 @@ plugin_init (GstPlugin * plugin)
+ gst_element_register (plugin, "vaapidecodebin",
+ GST_RANK_PRIMARY + 2, GST_TYPE_VAAPI_DECODE_BIN);
+
+- rank = GST_RANK_PRIMARY;
+- if (g_getenv ("WAYLAND_DISPLAY"))
+-rank = GST_RANK_MARGINAL;
+- gst_element_register (plugin, "vaapisink", rank, GST_TYPE_VAAPISINK);
++ gst_element_register (plugin, "vaapisink", GST_RANK_MARGINAL,
GST_TYPE_VAAPISINK);
+
+ #if USE_ENCODERS
+ gst_vaapiencode_register (plugin, display);
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.4.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.4.bb
index fdca0b9565..3896434104 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.4.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.14.4.bb
@@ -10,7 +10,8 @@ LIC_FILES_CHKSUM =
"file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c"
SRC_URI =
"https://gstreamer.freedesktop.org/src/${REALPN}/${REALPN}-${PV}.tar.xz \
file://0001-gst-vaapi-Makefile.am-Add-EGL_CFLAGS-to-libgstvaapi-.patch \
- "
+ file://0001-vaapsink-downgrade-to-marginal.patch \
+ "
SRC_URI[md5sum] = "2fae3442f5f23e7354a0c592bc7b9065"
SRC_URI[sha256sum] =
"ce18dbfe961c6a8d31270231686075586bf7a7df62b778c8e7f5ec148251d0a3"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for cooker: simplify BB_DANGLINGAPPENDS_WARNONLY
== Series Details == Series: cooker: simplify BB_DANGLINGAPPENDS_WARNONLY Revision: 1 URL : https://patchwork.openembedded.org/series/15147/ 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 sent to the wrong mailing list or some patches from the series correspond to different mailing lists [test_target_mailing_list] Suggested fixSend the series again to the correct mailing list (ML) Suggested ML bitbake-de...@lists.openembedded.org [http://git.openembedded.org/bitbake/] Patch's path:bitbake/lib/bb/cooker.py * 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 21387613fe) 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
Re: [OE-core] [PATCH 0/1] cooker: simplify BB_DANGLINGAPPENDS_WARNONLY
Sorry, wrong post, it should go to bitbake mailing list. // Robert On 11/30/18 11:39 AM, Robert Yang wrote: Hi RP, I'd like to change the fatal message to be an event, the benefits are: - Things like report-error.bbclass can catch the error - It's easier to get bbappends list from an event message than from console log. What's your opinion, please ? // Robert The following changes since commit 41d89552620bfbc94031d314e6b3d0324f7a330e: bitbake: fetch2: Avoid warning about incorrect character escaping in regex (2018-11-27 22:15:34 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib rbt/append http://git.pokylinux.org/cgit.cgi//log/?h=rbt/append Robert Yang (1): cooker: simplify BB_DANGLINGAPPENDS_WARNONLY bitbake/lib/bb/cooker.py | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for uboot-sign.bbclass: fix signature and deployment (rev2)
This patch is for master-next, not master, so I think that we can ignore this issue. // Robert On 11/30/18 10:33 AM, Patchwork wrote: == Series Details == Series: uboot-sign.bbclass: fix signature and deployment (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/15013/ 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 21387613fe) 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] [PATCH 1/1] cooker: simplify BB_DANGLINGAPPENDS_WARNONLY
- d.getVar('BB_DANGLINGAPPENDS_WARNONLY', False) ->
d.getVar('BB_DANGLINGAPPENDS_WARNONLY')
There is no reason to use 'False'.
- Use bb.utils.to_boolean for warn_only.
Signed-off-by: Robert Yang
---
bitbake/lib/bb/cooker.py | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py
index 16681ba..28a16c5 100644
--- a/bitbake/lib/bb/cooker.py
+++ b/bitbake/lib/bb/cooker.py
@@ -928,9 +928,8 @@ class BBCooker:
if appends_without_recipes:
msg = 'No recipes available for:\n %s' % '\n
'.join(appends_without_recipes)
-warn_only = self.data.getVar("BB_DANGLINGAPPENDS_WARNONLY", \
- False) or "no"
-if warn_only.lower() in ("1", "yes", "true"):
+warn_only = self.data.getVar("BB_DANGLINGAPPENDS_WARNONLY")
+if bb.utils.to_boolean(warn_only):
bb.warn(msg)
else:
bb.fatal(msg)
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] cooker: simplify BB_DANGLINGAPPENDS_WARNONLY
Hi RP, I'd like to change the fatal message to be an event, the benefits are: - Things like report-error.bbclass can catch the error - It's easier to get bbappends list from an event message than from console log. What's your opinion, please ? // Robert The following changes since commit 41d89552620bfbc94031d314e6b3d0324f7a330e: bitbake: fetch2: Avoid warning about incorrect character escaping in regex (2018-11-27 22:15:34 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib rbt/append http://git.pokylinux.org/cgit.cgi//log/?h=rbt/append Robert Yang (1): cooker: simplify BB_DANGLINGAPPENDS_WARNONLY bitbake/lib/bb/cooker.py | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for uboot-sign.bbclass: fix signature and deployment (rev2)
== Series Details == Series: uboot-sign.bbclass: fix signature and deployment (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/15013/ 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 21387613fe) 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
Re: [OE-core] [oe] Github pull requests
On Thu, Nov 29, 2018 at 5:26 PM Paul Eggleton wrote: > > Hi folks > > Someone pointed out that there are quite a few pull requests on github under > https://github.com/openembedded/. I know we don't accept these, but it seems > to me we ought to clean up the ones that are there in order to avoid people > thinking that they might be (and probably comment on the ones where we haven't > done so or the submitter hasn't sent them to the mailing list already). I'll > volunteer to clean them up, but I don't currently have access - can someone > grant that to me? I think that will be good. I have taken care of meta-oe ones but I can not close them > > Thanks, > Paul > > -- > Paul Eggleton > Intel Open Source Technology Centre > > > -- > ___ > Openembedded-devel mailing list > openembedded-de...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1 V2] uboot-sign.bbclass: fix signature and deployment
* V2 Rebase to master-next and resend. * V1 Initial version The following changes since commit e821100b1ee2a023b813adb20e56fe1ccc352d42: musl: Update to latest trunk (2018-11-29 23:34:46 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/uboot http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/uboot Robert Yang (1): uboot-sign.bbclass: fix signature and deployment meta/classes/kernel-fitimage.bbclass | 17 ++- meta/classes/uboot-sign.bbclass | 95 meta/recipes-bsp/u-boot/u-boot.inc | 2 +- 3 files changed, 69 insertions(+), 45 deletions(-) -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] uboot-sign.bbclass: fix signature and deployment
Fixed:
MACHINE = "beaglebone-yocto"
KERNEL_CLASSES += "kernel-fitimage"
KERNEL_IMAGETYPE_beaglebone-yocto = "fitImage"
UBOOT_MACHINE_beaglebone-yocto = "am335x_boneblack_vboot_config"
UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
UBOOT_SIGN_KEYDIR = "${TOPDIR}/conf"
UBOOT_SIGN_KEYNAME = "dev"
UBOOT_SIGN_ENABLE = "1"
IMAGE_INSTALL_remove = "kernel-image-zimage"
$ cd conf
$ openssl genrsa -F4 -out dev.key 2048
$ openssl req -batch -new -x509 -key dev.key -out dev.crt
$ cd ../
$ bitbake u-boot linux-yocto
$ grep signature tmp/deploy/images/beaglebone-yocto/*.dtb
Binary file
tmp/deploy/images/beaglebone-yocto/u-boot-beaglebone-yocto-2018.07-r0.dtb
matches
Binary file tmp/deploy/images/beaglebone-yocto/u-boot-beaglebone-yocto.dtb
matches
Binary file tmp/deploy/images/beaglebone-yocto/u-boot.dtb matches
And there would be no signature info when rebuild from sstate:
$ bitbake u-boot linux-yocto -cclean
$ bitbake u-boot linux-yocto
$ grep signature tmp/deploy/images/beaglebone-yocto/*.dtb
No result
This s because kernel directly edit ${DEPLOY_DIR_IMAGE}/u-boot.dtb, (Note, it
is global ${DEPLOY_DIR_IMAGE}, not recipe's DEPLOYDIR), so that the modified
info is not in sstate, and would be lost when rebuild from sstate.
There are other problems in previouse code:
- The u-boot.dtb is provided by u-boot, but edited by kernel during signing, so
it should be deployed by kernel rather than u-boot.
- The u-boot.do_concat_dtb directly install files to global ${DEPLOY_DIR_IMAGE},
this is incorrect, the ${DEPLOY_DIR_IMAGE} should be installed by do_deploy.
- It seems that it assumes do_deploy depends on do_install according the
comments,
but they have no relationships:
# do_concat_dtb is scheduled _before_ do_install as it overwrite the
# u-boot.bin in both DEPLOYDIR and DEPLOY_IMAGE_DIR.
- The do_concat_dtb should be run after do_compile, but it doesn't have this
dependency.
Make u-boot install u-boot.dtb to ${datadir}, kernel copies u-boot.dtb from
${STAGING_DATADIR} to ${B} and deploy it can fix the problem.
[YOCTO #12112]
Reported-by: Christian Andersen
Signed-off-by: Robert Yang
---
meta/classes/kernel-fitimage.bbclass | 17 ++-
meta/classes/uboot-sign.bbclass | 95
meta/recipes-bsp/u-boot/u-boot.inc | 2 +-
3 files changed, 69 insertions(+), 45 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 328bef4..5f6380f 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -35,7 +35,7 @@ python __anonymous () {
# the fitImage:
if d.getVar('UBOOT_SIGN_ENABLE') == "1":
uboot_pn = d.getVar('PREFERRED_PROVIDER_u-boot') or 'u-boot'
-d.appendVarFlag('do_assemble_fitimage', 'depends', ' %s:do_deploy'
% uboot_pn)
+d.appendVarFlag('do_assemble_fitimage', 'depends', '
%s:do_populate_sysroot' % uboot_pn)
}
# Options for the device tree compiler passed to mkimage '-D' feature:
@@ -456,10 +456,17 @@ fitimage_assemble() {
# Step 7: Sign the image and add public key to U-Boot dtb
#
if [ "x${UBOOT_SIGN_ENABLE}" = "x1" ] ; then
+ add_key_to_u_boot=""
+ if [ -n "${UBOOT_DTB_BINARY}" ]; then
+ # The u-boot.dtb is a symlink to UBOOT_DTB_IMAGE, so we
need copy
+ # both of them, and don't dereference the symlink.
+ cp -P ${STAGING_DATADIR}/u-boot*.dtb ${B}
+ add_key_to_u_boot="-K ${B}/${UBOOT_DTB_BINARY}"
+ fi
uboot-mkimage \
${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if
len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
-F -k "${UBOOT_SIGN_KEYDIR}" \
- ${@'-K "${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_BINARY}"' if
len('${UBOOT_DTB_BINARY}') else ''} \
+ $add_key_to_u_boot \
-r arch/${ARCH}/boot/${2}
fi
}
@@ -505,5 +512,11 @@ kernel_do_deploy_append() {
install -m 0644
${B}/arch/${ARCH}/boot/fitImage-${INITRAMFS_IMAGE}
${DEPLOYDIR}/fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_NAME}.bin
ln -snf
fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_NAME}.bin
${DEPLOYDIR}/fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_LINK_NAME}
fi
+ if [ "${UBOOT_SIGN_ENABLE}" = "1" -a -n "${UBOOT_DTB_BINARY}" ]
; then
+ # UBOOT_DTB_IMAGE is a realfile, but we can't use
+ # ${UBOOT_DTB_IMAGE} since it contains ${PV} which is
aimed
+ # for u-boot, but we are in kernel env now.
+ install -m 0644 ${B}/u-boot-${MACHINE}*.dtb
${DEPLOYDIR}/
+ fi
fi
}
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index afaf46f..03100b8 100644
--- a/meta/classes/uboot-sign.
Re: [OE-core] [PATCH 1/1] uboot-sign.bbclass: fix signature and deployment
Hi Ross,
On 11/29/18 9:15 PM, Burton, Ross wrote:
This didn't get merged before other pieces did, so can you please
rebase and resend?
Thanks, I will rebase to master-next and resend. BTW, the Christian Andersen
(the reporter) has replied that the patch works for him:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12112
// Robert
Ross
On Thu, 22 Nov 2018 at 01:43, Robert Yang wrote:
On 11/22/18 1:20 AM, Otavio Salvador wrote:
Hello,
On Wed, Nov 21, 2018 at 4:08 AM Robert Yang wrote:
Fixed:
MACHINE = "beaglebone-yocto"
KERNEL_CLASSES += "kernel-fitimage"
KERNEL_IMAGETYPE_beaglebone-yocto = "fitImage"
UBOOT_MACHINE_beaglebone-yocto = "am335x_boneblack_vboot_config"
UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
UBOOT_SIGN_KEYDIR = "${TOPDIR}/conf"
UBOOT_SIGN_KEYNAME = "dev"
UBOOT_SIGN_ENABLE = "1"
IMAGE_INSTALL_remove = "kernel-image-zimage"
$ cd conf
$ openssl genrsa -F4 -out dev.key 2048
$ openssl req -batch -new -x509 -key dev.key -out dev.crt
$ cd ../
$ bitbake u-boot linux-yocto
$ grep signature tmp/deploy/images/beaglebone-yocto/*.dtb
Binary file
tmp/deploy/images/beaglebone-yocto/u-boot-beaglebone-yocto-2018.07-r0.dtb
matches
Binary file tmp/deploy/images/beaglebone-yocto/u-boot-beaglebone-yocto.dtb
matches
Binary file tmp/deploy/images/beaglebone-yocto/u-boot.dtb matches
And there would be no signature info when rebuild from sstate:
$ bitbake u-boot linux-yocto -cclean
$ bitbake u-boot linux-yocto
$ grep signature tmp/deploy/images/beaglebone-yocto/*.dtb
No result
This s because kernel directly edit ${DEPLOY_DIR_IMAGE}/u-boot.dtb, (Note, it
is global ${DEPLOY_DIR_IMAGE}, not recipe's DEPLOYDIR), so that the modified
info is not in sstate, and would be lost when rebuild from sstate.
There are other problems in previouse code:
- The u-boot.dtb is provided by u-boot, but edited by kernel during signing, so
it should be deployed by kernel rather than u-boot.
- The u-boot.do_concat_dtb directly install files to global ${DEPLOY_DIR_IMAGE},
this is incorrect, the ${DEPLOY_DIR_IMAGE} should be installed by do_deploy.
- It seems that it assumes do_deploy depends on do_install according the
comments,
but they have no relationships:
# do_concat_dtb is scheduled _before_ do_install as it overwrite the
# u-boot.bin in both DEPLOYDIR and DEPLOY_IMAGE_DIR.
- The do_concat_dtb should be run after do_compile, but it doesn't have this
dependency.
Make u-boot install u-boot.dtb to ${datadir}, kernel copies u-boot.dtb from
${STAGING_DATADIR} to ${B} and deploy it can fix the problem.
[YOCTO #12112]
Reported-by: Christian Andersen
Signed-off-by: Robert Yang
The change itself looks good, I noticed that the script part is not
using 4 spaces for indenting and as this is being changed, it might
make sense to address this as well.
Thanks, sounds good to me, I will make another patch for it after this is
merged.
// Robert
Acked-by: Otavio Salvador
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] u-boot-tools: fix compile error
From: Kai Kang
It uses sandbox_defconfig to produce u-boot tools. But EFI is only
supported by arm and x86, then it fails to run task do_compile on other
arches:
| include/config_distro_bootcmd.h:267:3: error: #error "sandbox EFI
| support is only supported on ARM and x86"
Only enable EFI support for u-boot-tools on x86 and arm to fix the issue.
Signed-off-by: Kai Kang
---
meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb
b/meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb
index 127c4c15d1..7893d2aebc 100644
--- a/meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb
@@ -17,13 +17,20 @@ EXTRA_OEMAKE_class-target =
'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} ${CFLAGS
EXTRA_OEMAKE_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" STRIP=true V=1'
EXTRA_OEMAKE_class-nativesdk = 'CROSS_COMPILE="${HOST_PREFIX}" CC="${CC}
${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
STRIP=true V=1'
+SED_CONFIG_EFI = '-e "s/CONFIG_EFI_LOADER=.*/# CONFIG_EFI_LOADER is not set/"'
+SED_CONFIG_EFI_x86 = ''
+SED_CONFIG_EFI_x86-64 = ''
+SED_CONFIG_EFI_arm = ''
+SED_CONFIG_EFI_armeb = ''
+SED_CONFIG_EFI_aarch64 = ''
+
do_compile () {
oe_runmake sandbox_defconfig
# Disable CONFIG_CMD_LICENSE, license.h is not used by tools and
# generating it requires bin2header tool, which for target build
# is built with target tools and thus cannot be executed on host.
- sed -i "s/CONFIG_CMD_LICENSE=.*/# CONFIG_CMD_LICENSE is not set/"
.config
+ sed -i -e "s/CONFIG_CMD_LICENSE=.*/# CONFIG_CMD_LICENSE is not set/"
${SED_CONFIG_EFI} .config
oe_runmake cross_tools NO_SDL=1
}
--
2.19.0.rc2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] u-boot-tools: fix compile error
From: Kai Kang The following changes since commit 41d89552620bfbc94031d314e6b3d0324f7a330e: bitbake: fetch2: Avoid warning about incorrect character escaping in regex (2018-11-27 22:15:34 +) are available in the Git repository at: git://git.pokylinux.org/poky-contrib kangkai/uboot http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/uboot Kai Kang (1): u-boot-tools: fix compile error meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) -- 2.19.0.rc2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Github pull requests
Hi folks Someone pointed out that there are quite a few pull requests on github under https://github.com/openembedded/. I know we don't accept these, but it seems to me we ought to clean up the ones that are there in order to avoid people thinking that they might be (and probably comment on the ones where we haven't done so or the submitter hasn't sent them to the mailing list already). I'll volunteer to clean them up, but I don't currently have access - can someone grant that to me? Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for nano: upgrade to 3.2
== Series Details == Series: nano: upgrade to 3.2 Revision: 1 URL : https://patchwork.openembedded.org/series/15143/ 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 sent to the wrong mailing list or some patches from the series correspond to different mailing lists [test_target_mailing_list] Suggested fixSend the series again to the correct mailing list (ML) Suggested ML openembedded-de...@lists.openembedded.org [http://git.openembedded.org/meta-openembedded/] Patch's path:meta-oe/recipes-support/nano/nano_3.0.bb * 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 21387613fe) 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] [PATCH] nano: upgrade to 3.2
Signed-off-by: Oleksandr Kravchuk
---
meta-oe/recipes-support/nano/{nano_3.0.bb => nano_3.2.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta-oe/recipes-support/nano/{nano_3.0.bb => nano_3.2.bb} (79%)
diff --git a/meta-oe/recipes-support/nano/nano_3.0.bb
b/meta-oe/recipes-support/nano/nano_3.2.bb
similarity index 79%
rename from meta-oe/recipes-support/nano/nano_3.0.bb
rename to meta-oe/recipes-support/nano/nano_3.2.bb
index 2c7fbd549..b96a79fd0 100644
--- a/meta-oe/recipes-support/nano/nano_3.0.bb
+++ b/meta-oe/recipes-support/nano/nano_3.2.bb
@@ -12,8 +12,8 @@ PV_MAJOR = "${@d.getVar('PV').split('.')[0]}"
SRC_URI = "https://nano-editor.org/dist/v${PV_MAJOR}/nano-${PV}.tar.xz";
-SRC_URI[md5sum] = "74196427a09ec2f82a88facd220d2787"
-SRC_URI[sha256sum] =
"e0a5bca354514e64762c987c200a8758b05e7bcced3b00b3e48ea0a2d383c8a0"
+SRC_URI[md5sum] = "2606dc0dc31a088f16c7d603b42d23d0"
+SRC_URI[sha256sum] =
"d12773af3589994b2e4982c5792b07c6240da5b86c5aef2103ab13b401fe6349"
inherit autotools gettext pkgconfig
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 4/4] oe-selftest: add some tests for recipeutils module
On Friday, 30 November 2018 12:09:58 PM NZDT richard.pur...@linuxfoundation.org wrote: > On Fri, 2018-11-30 at 08:35 +1300, Paul Eggleton wrote: > > On Friday, 30 November 2018 3:06:32 AM NZDT Richard Purdie wrote: > > > On Thu, 2018-11-29 at 22:21 +1300, Paul Eggleton wrote: > > > > Add some tests for functions in meta/lib/oe/recipeutils.py, in > > > > particular for a few issues I've just fixed. I haven't added > > > > tests > > > > for > > > > all of the functions - some of them are already being tested via > > > > devtool > > > > in any case. > > > > > > Hate to say it but this still isn't working: > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/28/steps/7/logs/step2d > > > > > > probably due to it not working with the -j option :/ > > > > Right, so it seems that COREBASE isn't pointing where I'd expect it > > to > > here - instead of the copy of the core metadata that's made for the > > test, it's > > pointing to the original layer. Is that a bug? > > I put > > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=74b7df6ff73764e108bd81e05835c8a7d134c187 > > together to fix this. Its not a bug since the tests modify meta- > selftest and therefore when running in parallel, we create copies of > that layer per build directory. OK, I've sent a fix - I discussed with RP on IRC but for others' benefit there's already a function in oeqa.utils.commands that gets the path to meta-selftest from BBLAYERS so I used that in v4 that I just sent. I also tested this one with -j which I hadn't with the previous versions. > I do think we should start using the separate build directory always > for oe-selftest for consistency though. It would also make ensuring > some things like rm_work disabled easier. Probably since there are gotchas like this one. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 4/4] oe-selftest: add some tests for recipeutils module
Add some tests for functions in meta/lib/oe/recipeutils.py, in
particular for a few issues I've just fixed. I haven't added tests for
all of the functions - some of them are already being tested via devtool
in any case.
Signed-off-by: Paul Eggleton
---
.../python/python-async-test.inc | 16 ++
.../python/python3-async-test_0.6.2.bb| 2 +
.../recipeutils/recipeutils-test.inc | 5 +
.../recipeutils/recipeutils-test/anotherfile | 0
.../recipeutils/recipeutils-test/somefile | 0
.../recipeutils/recipeutils-test_1.2.bb | 13 ++
meta/lib/oeqa/selftest/cases/recipeutils.py | 137 ++
7 files changed, 173 insertions(+)
create mode 100644 meta-selftest/recipes-devtools/python/python-async-test.inc
create mode 100644
meta-selftest/recipes-devtools/python/python3-async-test_0.6.2.bb
create mode 100644 meta-selftest/recipes-test/recipeutils/recipeutils-test.inc
create mode 100644
meta-selftest/recipes-test/recipeutils/recipeutils-test/anotherfile
create mode 100644
meta-selftest/recipes-test/recipeutils/recipeutils-test/somefile
create mode 100644
meta-selftest/recipes-test/recipeutils/recipeutils-test_1.2.bb
create mode 100644 meta/lib/oeqa/selftest/cases/recipeutils.py
diff --git a/meta-selftest/recipes-devtools/python/python-async-test.inc
b/meta-selftest/recipes-devtools/python/python-async-test.inc
new file mode 100644
index 000..c9602e8e52d
--- /dev/null
+++ b/meta-selftest/recipes-devtools/python/python-async-test.inc
@@ -0,0 +1,16 @@
+SUMMARY = "Python framework to process interdependent tasks in a pool of
workers"
+HOMEPAGE = "http://github.com/gitpython-developers/async";
+SECTION = "devel/python"
+LICENSE = "BSD"
+LIC_FILES_CHKSUM =
"file://PKG-INFO;beginline=8;endline=8;md5=88df8e78b9edfd744953862179f2d14e"
+
+inherit pypi
+
+PYPI_PACKAGE = "async"
+
+SRC_URI[md5sum] = "9b06b5997de2154f3bc0273f80bcef6b"
+SRC_URI[sha256sum] =
"ac6894d876e45878faae493b0cf61d0e28ec417334448ac0a6ea2229d8343051"
+
+RDEPENDS_${PN} += "${PYTHON_PN}-threading"
+
+BBCLASSEXTEND = "nativesdk"
diff --git a/meta-selftest/recipes-devtools/python/python3-async-test_0.6.2.bb
b/meta-selftest/recipes-devtools/python/python3-async-test_0.6.2.bb
new file mode 100644
index 000..22e241afb3c
--- /dev/null
+++ b/meta-selftest/recipes-devtools/python/python3-async-test_0.6.2.bb
@@ -0,0 +1,2 @@
+inherit setuptools3
+require python-async-test.inc
diff --git a/meta-selftest/recipes-test/recipeutils/recipeutils-test.inc
b/meta-selftest/recipes-test/recipeutils/recipeutils-test.inc
new file mode 100644
index 000..8490b902d75
--- /dev/null
+++ b/meta-selftest/recipes-test/recipeutils/recipeutils-test.inc
@@ -0,0 +1,5 @@
+SRC_URI =
"http://xorg.freedesktop.org/releases/individual/lib/libxshmfence-${PV}.tar.bz2";
+
+SRC_URI[md5sum] = "2e76899112c0f99e22f2fc775a7e"
+SRC_URI[sha256sum] =
"d21b2d1fd78c1efbe1f2c16dae1cb23f8fd231dcf891465b8debe636a9054b0c"
+
diff --git
a/meta-selftest/recipes-test/recipeutils/recipeutils-test/anotherfile
b/meta-selftest/recipes-test/recipeutils/recipeutils-test/anotherfile
new file mode 100644
index 000..e69de29bb2d
diff --git a/meta-selftest/recipes-test/recipeutils/recipeutils-test/somefile
b/meta-selftest/recipes-test/recipeutils/recipeutils-test/somefile
new file mode 100644
index 000..e69de29bb2d
diff --git a/meta-selftest/recipes-test/recipeutils/recipeutils-test_1.2.bb
b/meta-selftest/recipes-test/recipeutils/recipeutils-test_1.2.bb
new file mode 100644
index 000..f6da97b2d43
--- /dev/null
+++ b/meta-selftest/recipes-test/recipeutils/recipeutils-test_1.2.bb
@@ -0,0 +1,13 @@
+SUMMARY = "Test recipe for recipeutils.patch_recipe()"
+
+require recipeutils-test.inc
+
+LICENSE = "Proprietary"
+
+DEPENDS += "virtual/libx11"
+
+BBCLASSEXTEND = "native nativesdk"
+
+SRC_URI += "file://somefile"
+
+SRC_URI_append = " file://anotherfile"
diff --git a/meta/lib/oeqa/selftest/cases/recipeutils.py
b/meta/lib/oeqa/selftest/cases/recipeutils.py
new file mode 100644
index 000..dd2f55839ae
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/recipeutils.py
@@ -0,0 +1,137 @@
+import os
+import re
+import time
+import logging
+import bb.tinfoil
+
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import runCmd, get_test_layer
+from oeqa.core.decorator.oeid import OETestID
+
+
+def setUpModule():
+global tinfoil
+global metaselftestpath
+metaselftestpath = get_test_layer()
+tinfoil = bb.tinfoil.Tinfoil(tracking=True)
+tinfoil.prepare(config_only=False, quiet=2)
+
+
+def tearDownModule():
+tinfoil.shutdown()
+
+
+class RecipeUtilsTests(OESelftestTestCase):
+""" Tests for the recipeutils module functions """
+
+def test_patch_recipe_varflag(self):
+import oe.recipeutils
+rd = tinfoil.parse_recipe('python3-async-test')
+vals = {'SRC_URI[md5sum]': 'aa', 'LICENSE': 'something'}
+patches = oe.recipeutils
Re: [OE-core] [PATCH v3 4/4] oe-selftest: add some tests for recipeutils module
On Fri, 2018-11-30 at 08:35 +1300, Paul Eggleton wrote: > On Friday, 30 November 2018 3:06:32 AM NZDT Richard Purdie wrote: > > On Thu, 2018-11-29 at 22:21 +1300, Paul Eggleton wrote: > > > Add some tests for functions in meta/lib/oe/recipeutils.py, in > > > particular for a few issues I've just fixed. I haven't added > > > tests > > > for > > > all of the functions - some of them are already being tested via > > > devtool > > > in any case. > > > > Hate to say it but this still isn't working: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/28/steps/7/logs/step2d > > > > probably due to it not working with the -j option :/ > > Right, so it seems that COREBASE isn't pointing where I'd expect it > to > here - instead of the copy of the core metadata that's made for the > test, it's > pointing to the original layer. Is that a bug? I put http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=74b7df6ff73764e108bd81e05835c8a7d134c187 together to fix this. Its not a bug since the tests modify meta- selftest and therefore when running in parallel, we create copies of that layer per build directory. I do think we should start using the separate build directory always for oe-selftest for consistency though. It would also make ensuring some things like rm_work disabled easier. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 4/4] oe-selftest: add some tests for recipeutils module
On Friday, 30 November 2018 3:06:32 AM NZDT Richard Purdie wrote: > On Thu, 2018-11-29 at 22:21 +1300, Paul Eggleton wrote: > > Add some tests for functions in meta/lib/oe/recipeutils.py, in > > particular for a few issues I've just fixed. I haven't added tests > > for > > all of the functions - some of them are already being tested via > > devtool > > in any case. > > Hate to say it but this still isn't working: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/28/steps/7/logs/step2d > > probably due to it not working with the -j option :/ Right, so it seems that COREBASE isn't pointing where I'd expect it to here - instead of the copy of the core metadata that's made for the test, it's pointing to the original layer. Is that a bug? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] musl: Update to latest trunk
Complete changelogs are here
https://git.musl-libc.org/cgit/musl/log/?qt=range&q=c50985d5c8e316c5c464f352e79eeebfed1121a9..39ef612aa193cc6e954ac5a01574300ccd4b7ef9
Signed-off-by: Khem Raj
---
V2: move to latest master ( 3 more commits for regressions )
meta/recipes-core/musl/musl_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/musl/musl_git.bb
b/meta/recipes-core/musl/musl_git.bb
index 0d8f8eb2a4..b416ec45bf 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -4,7 +4,7 @@
require musl.inc
inherit linuxloader
-SRCREV = "c50985d5c8e316c5c464f352e79eeebfed1121a9"
+SRCREV = "39ef612aa193cc6e954ac5a01574300ccd4b7ef9"
PV = "1.1.20+git${SRCPV}"
--
2.19.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/sdk/python: add Python 2 and fix detection
Add a Python 2 form to exercise that if present, and fix the setUp() so it
actually looks for a package that exists (nativesdk-python3 is a virtual
package, the interpretter is in nativesdk-python3-core).
Signed-off-by: Ross Burton
---
meta/lib/oeqa/sdk/cases/python.py | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oeqa/sdk/cases/python.py
b/meta/lib/oeqa/sdk/cases/python.py
index 7c1d183e529..8b871414033 100644
--- a/meta/lib/oeqa/sdk/cases/python.py
+++ b/meta/lib/oeqa/sdk/cases/python.py
@@ -1,14 +1,28 @@
import subprocess, unittest
from oeqa.sdk.case import OESDKTestCase
-class PythonTest(OESDKTestCase):
+class Python2Test(OESDKTestCase):
def setUp(self):
-if not (self.tc.hasHostPackage("nativesdk-python3") or
-self.tc.hasHostPackage("python3-native")):
+if not (self.tc.hasHostPackage("nativesdk-python-core") or
+self.tc.hasHostPackage("python-core-native")):
raise unittest.SkipTest("No python package in the SDK")
def test_python3(self):
try:
+cmd = "python -c \"import codecs; print(codecs.encode('Uryyb,
jbeyq', 'rot13'))\""
+output = self._run(cmd)
+self.assertEqual(output, "Hello, world\n")
+except subprocess.CalledProcessError as e:
+self.fail("Unexpected exit %d (output %s)" % (e.returncode,
e.output))
+
+class Python3Test(OESDKTestCase):
+def setUp(self):
+if not (self.tc.hasHostPackage("nativesdk-python3-core") or
+self.tc.hasHostPackage("python3-core-native")):
+raise unittest.SkipTest("No python3 package in the SDK")
+
+def test_python3(self):
+try:
cmd = "python3 -c \"import codecs; print(codecs.encode('Uryyb,
jbeyq', 'rot13'))\""
output = self._run(cmd)
self.assertEqual(output, "Hello, world\n")
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] RFC image_types.bbclass: add image size limit for tar image type
On Thu, 2018-11-29 at 14:17 +, mikko.rap...@bmw.de wrote: > On Thu, Nov 29, 2018 at 02:04:14PM +, Richard Purdie wrote: > > On Thu, 2018-11-29 at 14:21 +0200, Mikko Rapeli wrote: > > > If IMAGE_ROOTFS_SIZE_LIMIT is defined in image configuration, > > > then > > > build will fail if for tar image type the uncompressed tar ball > > > size > > > exceeds the value, as reported by 'du -ks'. > > > > > > This check could be extended to other image types as well. > > > > > > There already exists a check with IMAGE_ROOTFS_SIZE variable > > > but I could not figure out how to actually use it. It does > > > some quite complex overhead calculations which did not seem > > > to work for me on sumo. > > > > > > When the image size is exceeded, build fails like this: > > > > > > ERROR: image-1.0-r0 do_image_tar: Image size 170712 of > > > /home/builder/src/base/build/tmp/work/linux/image/1.0-r0/deploy- > > > image-complete/image.rootfs.tar reported by 'du -ks' is larger > > > than > > > limit IMAGE_ROOTFS_SIZE_LIMIT 17 > > > > What about IMAGE_ROOTFS_MAXSIZE? > > > > I think IMAGE_ROOTFS_SIZE is about adding extra space to the image, > > not > > limiting its size... > > Yea, forgot to mention that I tried that too but got inconsisten > results. > I know it's bad but it was easier for me to add this new test than to > figure out what's wrong with current yocto image size checks. Hence > RFC. How would we document this new variable? Recommend users to set both and hope for the best? :) Seriously, we need one good way of doing this which works. That means either you debug the IMAGE_ROOTFS_MAXSIZE option or at least file a bug with as much information as you can about the problems you're seeing... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libc-package: fix postinst error when ENABLE_BINARY_LOCALE_GENERATION = "0"
[YOCTO #13028]
Signed-off-by: Alexander Kanavin
---
meta/classes/libc-package.bbclass | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index 4c694ab5e2b..6b1e84ef7e3 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -49,13 +49,7 @@ python __anonymous () {
OVERRIDES_append = ":${TARGET_ARCH}-${TARGET_OS}"
-locale_base_postinst() {
-#!/bin/sh
-
-if [ "x$D" != "x" ]; then
- exit 1
-fi
-
+locale_base_postinst_ontarget() {
localedef --inputfile=${datadir}/i18n/locales/%s --charmap=%s %s
}
@@ -215,7 +209,7 @@ python package_do_split_gconvs () {
def output_locale_source(name, pkgname, locale, encoding):
d.setVar('RDEPENDS_%s' % pkgname, '%slocaledef %s-localedata-%s
%s-charmap-%s' % \
(mlprefix, mlprefix+bpn, legitimize_package_name(locale),
mlprefix+bpn, legitimize_package_name(encoding)))
-d.setVar('pkg_postinst_%s' % pkgname, d.getVar('locale_base_postinst')
\
+d.setVar('pkg_postinst_ontarget_%s' % pkgname,
d.getVar('locale_base_postinst_ontarget') \
% (locale, encoding, locale))
d.setVar('pkg_postrm_%s' % pkgname, d.getVar('locale_base_postrm') % \
(locale, encoding, locale))
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] RFC image_types.bbclass: add image size limit for tar image type
This seems like it’d make a good general image qa check instead, rather than being part of do_image_tar. On Thu, Nov 29, 2018 at 7:29 AM wrote: > On Thu, Nov 29, 2018 at 02:04:14PM +, Richard Purdie wrote: > > On Thu, 2018-11-29 at 14:21 +0200, Mikko Rapeli wrote: > > > If IMAGE_ROOTFS_SIZE_LIMIT is defined in image configuration, then > > > build will fail if for tar image type the uncompressed tar ball size > > > exceeds the value, as reported by 'du -ks'. > > > > > > This check could be extended to other image types as well. > > > > > > There already exists a check with IMAGE_ROOTFS_SIZE variable > > > but I could not figure out how to actually use it. It does > > > some quite complex overhead calculations which did not seem > > > to work for me on sumo. > > > > > > When the image size is exceeded, build fails like this: > > > > > > ERROR: image-1.0-r0 do_image_tar: Image size 170712 of > > > /home/builder/src/base/build/tmp/work/linux/image/1.0-r0/deploy- > > > image-complete/image.rootfs.tar reported by 'du -ks' is larger than > > > limit IMAGE_ROOTFS_SIZE_LIMIT 17 > > > > What about IMAGE_ROOTFS_MAXSIZE? > > > > I think IMAGE_ROOTFS_SIZE is about adding extra space to the image, not > > limiting its size... > > Yea, forgot to mention that I tried that too but got inconsisten results. > I know it's bad but it was easier for me to add this new test than to > figure > out what's wrong with current yocto image size checks. Hence RFC. > > -Mikko > > > Cheers, > > > > Richard > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] classes/update-alternatives: Skip alternatives when disabled
Skips the update alternative steps for recipes that shouldn't have them
enabled.
Fixes errors like:
nativesdk-bzip2-1.0.6-r5 do_package: bzip2: alternative target
(/opt/poky/2.5+snapshot/sysroots/i686-pokysdk-mingw32/usr/bin/bunzip2
or
/opt/poky/2.5+snapshot/sysroots/i686-pokysdk-mingw32/usr/bin/bunzip2.bzip2)
does not exist, skipping...
When building mingw SDKs
[YOCTO #12962]
Signed-off-by: Joshua Watt
---
meta/classes/update-alternatives.bbclass | 27 +++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/meta/classes/update-alternatives.bbclass
b/meta/classes/update-alternatives.bbclass
index aa01058cf99..ee663799332 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -89,15 +89,21 @@ def ua_extend_depends(d):
if not 'virtual/update-alternatives' in d.getVar('PROVIDES'):
d.appendVar('DEPENDS', ' virtual/${MLPREFIX}update-alternatives')
-python __anonymous() {
+def update_alternatives_enabled(d):
# Update Alternatives only works on target packages...
if bb.data.inherits_class('native', d) or \
bb.data.inherits_class('cross', d) or
bb.data.inherits_class('crosssdk', d) or \
bb.data.inherits_class('cross-canadian', d):
-return
+return False
# Disable when targeting mingw32 (no target support)
if d.getVar("TARGET_OS") == "mingw32":
+return False
+
+return True
+
+python __anonymous() {
+if not update_alternatives_enabled(d):
return
# compute special vardeps
@@ -128,6 +134,11 @@ populate_packages[vardeps] += "${UPDALTVARS}
${@gen_updatealternativesvars(d)}"
# the split and strip steps.. packagecopy seems to be the earliest reasonable
# place.
python perform_packagecopy_append () {
+if update_alternatives_enabled(d):
+apply_update_alternative_renames(d)
+}
+
+def apply_update_alternative_renames(d):
# Check for deprecated usage...
pn = d.getVar('BPN')
if d.getVar('ALTERNATIVE_LINKS') != None:
@@ -194,11 +205,13 @@ python perform_packagecopy_append () {
os.unlink(src)
else:
bb.warn('%s: Unable to resolve dangling symlink: %s' %
(pn, alt_target))
-}
PACKAGESPLITFUNCS_prepend = "populate_packages_updatealternatives "
python populate_packages_updatealternatives () {
+if not update_alternatives_enabled(d):
+return
+
pn = d.getVar('BPN')
# Do actual update alternatives processing
@@ -252,10 +265,15 @@ python populate_packages_updatealternatives () {
}
python package_do_filedeps_append () {
+if update_alternatives_enabled(d):
+apply_update_alternative_provides(d)
+}
+
+def apply_update_alternative_provides(d):
pn = d.getVar('BPN')
pkgdest = d.getVar('PKGDEST')
-for pkg in packages.split():
+for pkg in d.getVar('PACKAGES').split():
for alt_name in (d.getVar('ALTERNATIVE_%s' % pkg) or "").split():
alt_link = d.getVarFlag('ALTERNATIVE_LINK_NAME', alt_name)
alt_target = d.getVarFlag('ALTERNATIVE_TARGET_%s' % pkg,
alt_name) or d.getVarFlag('ALTERNATIVE_TARGET', alt_name)
@@ -273,5 +291,4 @@ python package_do_filedeps_append () {
d.appendVar('FILERPROVIDES_%s_%s' % (trans_target, pkg), " " +
alt_link)
if not trans_target in (d.getVar('FILERPROVIDESFLIST_%s' % pkg) or
""):
d.appendVar('FILERPROVIDESFLIST_%s' % pkg, " " + trans_target)
-}
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] RFC image_types.bbclass: add image size limit for tar image type
On Thu, Nov 29, 2018 at 02:04:14PM +, Richard Purdie wrote: > On Thu, 2018-11-29 at 14:21 +0200, Mikko Rapeli wrote: > > If IMAGE_ROOTFS_SIZE_LIMIT is defined in image configuration, then > > build will fail if for tar image type the uncompressed tar ball size > > exceeds the value, as reported by 'du -ks'. > > > > This check could be extended to other image types as well. > > > > There already exists a check with IMAGE_ROOTFS_SIZE variable > > but I could not figure out how to actually use it. It does > > some quite complex overhead calculations which did not seem > > to work for me on sumo. > > > > When the image size is exceeded, build fails like this: > > > > ERROR: image-1.0-r0 do_image_tar: Image size 170712 of > > /home/builder/src/base/build/tmp/work/linux/image/1.0-r0/deploy- > > image-complete/image.rootfs.tar reported by 'du -ks' is larger than > > limit IMAGE_ROOTFS_SIZE_LIMIT 17 > > What about IMAGE_ROOTFS_MAXSIZE? > > I think IMAGE_ROOTFS_SIZE is about adding extra space to the image, not > limiting its size... Yea, forgot to mention that I tried that too but got inconsisten results. I know it's bad but it was easier for me to add this new test than to figure out what's wrong with current yocto image size checks. Hence RFC. -Mikko > Cheers, > > Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 4/4] oe-selftest: add some tests for recipeutils module
On Thu, 2018-11-29 at 22:21 +1300, Paul Eggleton wrote: > Add some tests for functions in meta/lib/oe/recipeutils.py, in > particular for a few issues I've just fixed. I haven't added tests > for > all of the functions - some of them are already being tested via > devtool > in any case. Hate to say it but this still isn't working: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/28/steps/7/logs/step2d probably due to it not working with the -j option :/ Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/5] RFC image_types.bbclass: add image size limit for tar image type
On Thu, 2018-11-29 at 14:21 +0200, Mikko Rapeli wrote: > If IMAGE_ROOTFS_SIZE_LIMIT is defined in image configuration, then > build will fail if for tar image type the uncompressed tar ball size > exceeds the value, as reported by 'du -ks'. > > This check could be extended to other image types as well. > > There already exists a check with IMAGE_ROOTFS_SIZE variable > but I could not figure out how to actually use it. It does > some quite complex overhead calculations which did not seem > to work for me on sumo. > > When the image size is exceeded, build fails like this: > > ERROR: image-1.0-r0 do_image_tar: Image size 170712 of > /home/builder/src/base/build/tmp/work/linux/image/1.0-r0/deploy- > image-complete/image.rootfs.tar reported by 'du -ks' is larger than > limit IMAGE_ROOTFS_SIZE_LIMIT 17 What about IMAGE_ROOTFS_MAXSIZE? I think IMAGE_ROOTFS_SIZE is about adding extra space to the image, not limiting its size... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for various fixes
== Series Details == Series: various fixes Revision: 1 URL : https://patchwork.openembedded.org/series/15136/ 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 sent to the wrong mailing list or some patches from the series correspond to different mailing lists [test_target_mailing_list] Suggested fixSend the series again to the correct mailing list (ML) Suggested ML bitbake-de...@lists.openembedded.org [http://git.openembedded.org/bitbake/] Patch's path:bitbake/lib/bb/fetch2/svn.py * 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 21387613fe) * Patch[5/5] insane.bbclass: add package specific skips to sstate hash Issue Patch is missing Signed-off-by [test_signed_off_by_presence] Suggested fixSign off the patch (either manually or with "git commit --amend -s") 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
Re: [OE-core] [PATCH 1/1] uboot-sign.bbclass: fix signature and deployment
This didn't get merged before other pieces did, so can you please
rebase and resend?
Ross
On Thu, 22 Nov 2018 at 01:43, Robert Yang wrote:
>
>
>
> On 11/22/18 1:20 AM, Otavio Salvador wrote:
> > Hello,
> >
> > On Wed, Nov 21, 2018 at 4:08 AM Robert Yang
> > wrote:
> >>
> >> Fixed:
> >> MACHINE = "beaglebone-yocto"
> >> KERNEL_CLASSES += "kernel-fitimage"
> >> KERNEL_IMAGETYPE_beaglebone-yocto = "fitImage"
> >> UBOOT_MACHINE_beaglebone-yocto = "am335x_boneblack_vboot_config"
> >> UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
> >> UBOOT_SIGN_KEYDIR = "${TOPDIR}/conf"
> >> UBOOT_SIGN_KEYNAME = "dev"
> >> UBOOT_SIGN_ENABLE = "1"
> >> IMAGE_INSTALL_remove = "kernel-image-zimage"
> >>
> >> $ cd conf
> >> $ openssl genrsa -F4 -out dev.key 2048
> >> $ openssl req -batch -new -x509 -key dev.key -out dev.crt
> >> $ cd ../
> >> $ bitbake u-boot linux-yocto
> >> $ grep signature tmp/deploy/images/beaglebone-yocto/*.dtb
> >> Binary file
> >> tmp/deploy/images/beaglebone-yocto/u-boot-beaglebone-yocto-2018.07-r0.dtb
> >> matches
> >> Binary file tmp/deploy/images/beaglebone-yocto/u-boot-beaglebone-yocto.dtb
> >> matches
> >> Binary file tmp/deploy/images/beaglebone-yocto/u-boot.dtb matches
> >>
> >> And there would be no signature info when rebuild from sstate:
> >> $ bitbake u-boot linux-yocto -cclean
> >> $ bitbake u-boot linux-yocto
> >> $ grep signature tmp/deploy/images/beaglebone-yocto/*.dtb
> >> No result
> >>
> >> This s because kernel directly edit ${DEPLOY_DIR_IMAGE}/u-boot.dtb, (Note,
> >> it
> >> is global ${DEPLOY_DIR_IMAGE}, not recipe's DEPLOYDIR), so that the
> >> modified
> >> info is not in sstate, and would be lost when rebuild from sstate.
> >>
> >> There are other problems in previouse code:
> >> - The u-boot.dtb is provided by u-boot, but edited by kernel during
> >> signing, so
> >>it should be deployed by kernel rather than u-boot.
> >>
> >> - The u-boot.do_concat_dtb directly install files to global
> >> ${DEPLOY_DIR_IMAGE},
> >>this is incorrect, the ${DEPLOY_DIR_IMAGE} should be installed by
> >> do_deploy.
> >>
> >> - It seems that it assumes do_deploy depends on do_install according the
> >> comments,
> >>but they have no relationships:
> >># do_concat_dtb is scheduled _before_ do_install as it overwrite the
> >># u-boot.bin in both DEPLOYDIR and DEPLOY_IMAGE_DIR.
> >>
> >> - The do_concat_dtb should be run after do_compile, but it doesn't have
> >> this
> >>dependency.
> >>
> >> Make u-boot install u-boot.dtb to ${datadir}, kernel copies u-boot.dtb from
> >> ${STAGING_DATADIR} to ${B} and deploy it can fix the problem.
> >>
> >> [YOCTO #12112]
> >>
> >> Reported-by: Christian Andersen
> >> Signed-off-by: Robert Yang
> >
> > The change itself looks good, I noticed that the script part is not
> > using 4 spaces for indenting and as this is being changed, it might
> > make sense to address this as well.
>
> Thanks, sounds good to me, I will make another patch for it after this is
> merged.
>
> // Robert
>
> >
> > Acked-by: Otavio Salvador
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] RFC image_types.bbclass: add image size limit for tar image type
If IMAGE_ROOTFS_SIZE_LIMIT is defined in image configuration, then
build will fail if for tar image type the uncompressed tar ball size
exceeds the value, as reported by 'du -ks'.
This check could be extended to other image types as well.
There already exists a check with IMAGE_ROOTFS_SIZE variable
but I could not figure out how to actually use it. It does
some quite complex overhead calculations which did not seem
to work for me on sumo.
When the image size is exceeded, build fails like this:
ERROR: image-1.0-r0 do_image_tar: Image size 170712 of
/home/builder/src/base/build/tmp/work/linux/image/1.0-r0/deploy-image-complete/image.rootfs.tar
reported by 'du -ks' is larger than limit IMAGE_ROOTFS_SIZE_LIMIT 17
Signed-off-by: Mikko Rapeli
---
meta/classes/image.bbclass | 2 +-
meta/classes/image_types.bbclass | 11 ++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 276d0d3..34a567f 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -127,7 +127,7 @@ def rootfs_variables(d):
'IMAGE_ROOTFS_MAXSIZE','IMAGE_NAME','IMAGE_LINK_NAME','IMAGE_MANIFEST','DEPLOY_DIR_IMAGE','IMAGE_FSTYPES','IMAGE_INSTALL_COMPLEMENTARY','IMAGE_LINGUAS',
'MULTILIBRE_ALLOW_REP','MULTILIB_TEMP_ROOTFS','MULTILIB_VARIANTS','MULTILIBS','ALL_MULTILIB_PACKAGE_ARCHS','MULTILIB_GLOBAL_VARIANTS','BAD_RECOMMENDATIONS','NO_RECOMMENDATIONS',
'PACKAGE_ARCHS','PACKAGE_CLASSES','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','USE_DEVFS',
- 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED',
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY',
'REPRODUCIBLE_TIMESTAMP_ROOTFS', 'IMAGE_INSTALL_DEBUGFS']
+ 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED',
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY',
'REPRODUCIBLE_TIMESTAMP_ROOTFS', 'IMAGE_INSTALL_DEBUGFS',
'IMAGE_ROOTFS_SIZE_LIMIT']
variables.extend(rootfs_command_variables(d))
variables.extend(variable_depends(d))
return " ".join(variables)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 5c40648..0481703 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -125,7 +125,16 @@ IMAGE_CMD_squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS}
${IMGDEPLOYDIR}/${IMAGE_NAM
# required when extracting, but it seems prudent to use it in both cases.
IMAGE_CMD_TAR ?= "tar"
# ignore return code 1 "file changed as we read it" as other tasks(e.g.
do_image_wic) may be hardlinking rootfs
-IMAGE_CMD_tar = "${IMAGE_CMD_TAR} --numeric-owner -cf
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar -C ${IMAGE_ROOTFS} . || [
$? -eq 1 ]"
+IMAGE_CMD_tar() {
+ set -ex
+ "${IMAGE_CMD_TAR}" --numeric-owner -cf
"${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar" -C "${IMAGE_ROOTFS}" .
|| [ $? -eq 1 ]
+ # fail build if IMAGE_ROOTFS_SIZE_LIMIT is exceeded
+ if [ -n "${IMAGE_ROOTFS_SIZE_LIMIT}" ]; then
+ imagesize=$( du -ks
"${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar" | awk '{ print $1 }' )
+ [ "${imagesize}" -gt "${IMAGE_ROOTFS_SIZE_LIMIT}" ] && \
+ bberror "Image size ${imagesize} of
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar reported by 'du -ks' is
larger than limit IMAGE_ROOTFS_SIZE_LIMIT ${IMAGE_ROOTFS_SIZE_LIMIT}"
+ fi
+}
do_image_cpio[cleandirs] += "${WORKDIR}/cpio_append"
IMAGE_CMD_cpio () {
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] sstate: add support for caching shared workdir tasks
From: Michael Ho
The sstate bbclass uses workdir as a hardcoded string in path
manipulations. This means that the sstate caching mechanism does
not work for the work-shared directory which the kernel uses to
share its build configuration and source files for out of tree
kernel modules.
This commit modifies the path manipulation mechanism to use the
work-shared directory if detected in the paths when handling the
sstate cache packages.
Signed-off-by: Michael Ho
---
meta/classes/sstate.bbclass | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 8b48ab4..c856007 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -362,7 +362,10 @@ def sstate_installpkgdir(ss, d):
for plain in ss['plaindirs']:
workdir = d.getVar('WORKDIR')
+sharedworkdir = os.path.join(d.getVar('TMPDIR', True), "work-shared")
src = sstateinst + "/" + plain.replace(workdir, '')
+if sharedworkdir in plain:
+src = sstateinst + "/" + plain.replace(sharedworkdir, '')
dest = plain
bb.utils.mkdirhier(src)
prepdir(dest)
@@ -620,8 +623,11 @@ def sstate_package(ss, d):
os.rename(state[1], sstatebuild + state[0])
workdir = d.getVar('WORKDIR')
+sharedworkdir = os.path.join(d.getVar('TMPDIR', True), "work-shared")
for plain in ss['plaindirs']:
pdir = plain.replace(workdir, sstatebuild)
+if sharedworkdir in plain:
+pdir = plain.replace(sharedworkdir, sstatebuild)
bb.utils.mkdirhier(plain)
bb.utils.mkdirhier(pdir)
os.rename(plain, pdir)
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] various fixes
Hi, Here are some patches we have to use on sumo. Developed and tested heavily on sumo and only compile tested with core-image-minimal on top of master branch. Michael Ho (3): cmake.bbclass: append includedir to implicit include dirs sstate: add support for caching shared workdir tasks insane.bbclass: add package specific skips to sstate hash Mikko Rapeli (1): RFC image_types.bbclass: add image size limit for tar image type Ulf Magnusson (1): bitbake: fetch2/svn: Fix SVN repository concurrent update race bitbake/lib/bb/fetch2/svn.py | 64 ++-- meta/classes/cmake.bbclass | 4 +++ meta/classes/image.bbclass | 2 +- meta/classes/image_types.bbclass | 11 ++- meta/classes/insane.bbclass | 7 + meta/classes/sstate.bbclass | 6 6 files changed, 64 insertions(+), 30 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] insane.bbclass: add package specific skips to sstate hash
From: Michael Ho
The bbclass currently adds INSANE_SKIP to the sstate hash dependencies
however the package specific skips such as INSANE_SKIP_${PN} are
not added automatically because of how the class references them.
This causes the problem that modifying INSANE_SKIP_${PN} does not
invalidate the sstate cache and can mask build breaking warnings.
Add an anonymous python snippet to explicitly include these additional
relevant skips to the sstate hash.
Singed-off-by: Michael Ho
---
meta/classes/insane.bbclass | 7 +++
1 file changed, 7 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 4644221..e015c94 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1017,6 +1017,13 @@ do_package_qa[vardepsexclude] = "BB_TASKDEPDATA"
do_package_qa[rdeptask] = "do_packagedata"
addtask do_package_qa after do_packagedata do_package before do_build
+# Add the package specific INSANE_SKIPs to the sstate dependencies
+python() {
+pkgs = (d.getVar('PACKAGES') or '').split()
+for pkg in pkgs:
+d.appendVarFlag("do_package_qa", "vardeps", "
INSANE_SKIP_{}".format(pkg))
+}
+
SSTATETASKS += "do_package_qa"
do_package_qa[sstate-inputdirs] = ""
do_package_qa[sstate-outputdirs] = ""
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] bitbake: fetch2/svn: Fix SVN repository concurrent update race
From: Ulf Magnusson
The ${DL_DIR}/svn directory is used by BitBake to keep checked-out SVN
repositories from which tarballs are generated. These repositories were
protected from concurrent update with a lock on the tarballs. However,
the tarballs are specific to the SRCREV and module checked out (many
tarballs can come from the same repository), meaning a repository could
be modified concurrently if two recipes checked out two different
SRCREVs or modules from it in parallel. This caused errors like the
following:
ERROR: Fetcher failure: Fetch command failed with exit code 1, output:
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)
svn: E155004: Working copy '/home/foo/downloads/svn/repo/trunk' locked.
svn: E155004: '/home/foo/downloads/svn/repo/trunk' is already locked.
Fix it by adding a per-repository lock that's independent of the module
and SRCREV.
Signed-off-by: Ulf Magnusson
Signed-off-by: Michael Ho
---
bitbake/lib/bb/fetch2/svn.py | 64 +---
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git a/bitbake/lib/bb/fetch2/svn.py b/bitbake/lib/bb/fetch2/svn.py
index ed70bcf..9dcf3eb 100644
--- a/bitbake/lib/bb/fetch2/svn.py
+++ b/bitbake/lib/bb/fetch2/svn.py
@@ -63,6 +63,9 @@ class Svn(FetchMethod):
relpath = self._strip_leading_slashes(ud.path)
ud.pkgdir = os.path.join(svndir, ud.host, relpath)
ud.moddir = os.path.join(ud.pkgdir, ud.module)
+# Protects the repository from concurrent updates, e.g. from two
+# recipes fetching different revisions at the same time
+ud.svnlock = os.path.join(ud.pkgdir, "svn.lock")
ud.setup_revisions(d)
@@ -123,35 +126,40 @@ class Svn(FetchMethod):
logger.debug(2, "Fetch: checking for module directory '" + ud.moddir +
"'")
-if os.access(os.path.join(ud.moddir, '.svn'), os.R_OK):
-svnupdatecmd = self._buildsvncommand(ud, d, "update")
-logger.info("Update " + ud.url)
-# We need to attempt to run svn upgrade first in case its an older
working format
-try:
-runfetchcmd(ud.basecmd + " upgrade", d, workdir=ud.moddir)
-except FetchError:
-pass
-logger.debug(1, "Running %s", svnupdatecmd)
-bb.fetch2.check_network_access(d, svnupdatecmd, ud.url)
-runfetchcmd(svnupdatecmd, d, workdir=ud.moddir)
-else:
-svnfetchcmd = self._buildsvncommand(ud, d, "fetch")
-logger.info("Fetch " + ud.url)
-# check out sources there
-bb.utils.mkdirhier(ud.pkgdir)
-logger.debug(1, "Running %s", svnfetchcmd)
-bb.fetch2.check_network_access(d, svnfetchcmd, ud.url)
-runfetchcmd(svnfetchcmd, d, workdir=ud.pkgdir)
-
-scmdata = ud.parm.get("scmdata", "")
-if scmdata == "keep":
-tar_flags = ""
-else:
-tar_flags = "--exclude='.svn'"
+lf = bb.utils.lockfile(ud.svnlock)
+
+try:
+if os.access(os.path.join(ud.moddir, '.svn'), os.R_OK):
+svnupdatecmd = self._buildsvncommand(ud, d, "update")
+logger.info("Update " + ud.url)
+# We need to attempt to run svn upgrade first in case its an
older working format
+try:
+runfetchcmd(ud.basecmd + " upgrade", d, workdir=ud.moddir)
+except FetchError:
+pass
+logger.debug(1, "Running %s", svnupdatecmd)
+bb.fetch2.check_network_access(d, svnupdatecmd, ud.url)
+runfetchcmd(svnupdatecmd, d, workdir=ud.moddir)
+else:
+svnfetchcmd = self._buildsvncommand(ud, d, "fetch")
+logger.info("Fetch " + ud.url)
+# check out sources there
+bb.utils.mkdirhier(ud.pkgdir)
+logger.debug(1, "Running %s", svnfetchcmd)
+bb.fetch2.check_network_access(d, svnfetchcmd, ud.url)
+runfetchcmd(svnfetchcmd, d, workdir=ud.pkgdir)
+
+scmdata = ud.parm.get("scmdata", "")
+if scmdata == "keep":
+tar_flags = ""
+else:
+tar_flags = "--exclude='.svn'"
-# tar them up to a defined filename
-runfetchcmd("tar %s -czf %s %s" % (tar_flags, ud.localpath,
ud.path_spec), d,
-cleanup=[ud.localpath], workdir=ud.pkgdir)
+# tar them up to a defined filename
+runfetchcmd("tar %s -czf %s %s" % (tar_flags, ud.localpath,
ud.path_spec), d,
+cleanup=[ud.localpath], workdir=ud.pkgdir)
+finally:
+bb.utils.unlockfile(lf)
def clean(self, ud, d):
""" Clean SVN specific files and dirs """
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@l
[OE-core] [PATCH 3/5] cmake.bbclass: append includedir to implicit include dirs
From: Michael Ho
This resolves issues with paths being marked as system includes that
differ from /usr/include but are considered implicit by the toolchain.
This enables developers to add directories to system includes
to supress compiler compiler warnings from them.
Signed-off-by: Michael Ho
Cc: Pascal Bach
---
meta/classes/cmake.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a98..485aea6 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,6 +108,10 @@ list(APPEND CMAKE_MODULE_PATH
"${STAGING_DATADIR}/cmake/Modules/")
# add for non /usr/lib libdir, e.g. /usr/lib64
set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
+# add include dir to implicit includes in case it differs from /usr/include
+list(APPEND CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
+list(APPEND CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
+
EOF
}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] oeqa/selftest/buildoptions: Ensure diskmon tests run consistently
Heartbeat events default to once a second and we need to ensure we have
enough time in the task to see them.
Add a nostamp delay task 5s long so we can have a consistently timed
task which doesn't need cleanup or have unneeded dependencies. This
ensures we should deterministically see the disk moinitor events
regardless of the state of the build. This is done in a way which
doesn't corrupt build state or need cleanup and is efficient.
Signed-off-by: Richard Purdie
---
meta-selftest/recipes-test/delay/delay.bb| 12
meta/lib/oeqa/selftest/cases/buildoptions.py | 6 +++---
2 files changed, 15 insertions(+), 3 deletions(-)
create mode 100644 meta-selftest/recipes-test/delay/delay.bb
diff --git a/meta-selftest/recipes-test/delay/delay.bb
b/meta-selftest/recipes-test/delay/delay.bb
new file mode 100644
index 000..f92d3d99e28
--- /dev/null
+++ b/meta-selftest/recipes-test/delay/delay.bb
@@ -0,0 +1,12 @@
+SUMMARY = "Recipe with a fixed delay task"
+DESCRIPTION = "Contains a delay task to be used to for testing."
+LICENSE = "MIT"
+
+INHIBIT_DEFAULT_DEPS = "1"
+EXCLUDE_FROM_WORLD = "1"
+
+do_delay() {
+ sleep 5
+}
+do_delay[nostamp] = "1"
+addtask delay
\ No newline at end of file
diff --git a/meta/lib/oeqa/selftest/cases/buildoptions.py
b/meta/lib/oeqa/selftest/cases/buildoptions.py
index c3c90a0b0dc..f234bac0510 100644
--- a/meta/lib/oeqa/selftest/cases/buildoptions.py
+++ b/meta/lib/oeqa/selftest/cases/buildoptions.py
@@ -59,15 +59,15 @@ class DiskMonTest(OESelftestTestCase):
@OETestID(277)
def test_stoptask_behavior(self):
self.write_config('BB_DISKMON_DIRS =
"STOPTASKS,${TMPDIR},10G,100K"')
-res = bitbake("m4", ignore_status = True)
+res = bitbake("delay -c delay", ignore_status = True)
self.assertTrue('ERROR: No new tasks can be executed since the disk
space monitor action is "STOPTASKS"!' in res.output, msg = "Tasks should have
stopped. Disk monitor is set to STOPTASK: %s" % res.output)
self.assertEqual(res.status, 1, msg = "bitbake reported exit code %s.
It should have been 1. Bitbake output: %s" % (str(res.status), res.output))
self.write_config('BB_DISKMON_DIRS = "ABORT,${TMPDIR},10G,100K"')
-res = bitbake("m4", ignore_status = True)
+res = bitbake("delay -c delay", ignore_status = True)
self.assertTrue('ERROR: Immediately abort since the disk space monitor
action is "ABORT"!' in res.output, "Tasks should have been aborted
immediatelly. Disk monitor is set to ABORT: %s" % res.output)
self.assertEqual(res.status, 1, msg = "bitbake reported exit code %s.
It should have been 1. Bitbake output: %s" % (str(res.status), res.output))
self.write_config('BB_DISKMON_DIRS = "WARN,${TMPDIR},10G,100K"')
-res = bitbake("m4")
+res = bitbake("delay -c delay")
self.assertTrue('WARNING: The free space' in res.output, msg = "A
warning should have been displayed for disk monitor is set to WARN: %s"
%res.output)
class SanityOptionsTest(OESelftestTestCase):
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] oeqa/selftest/context: Improve log file handling
The existing logfile is simply placed in the current directory. Since the test
changes cwd to BUILDDIR, the symlink to the log can be placed in an invalid
directory. We also see trackbacks if the symlink is invalid.
Improve things by:
* Placing logs in LOG_DIR (or BUILDDIR if unset).
* Using a full path to the log meaning the log and link are placed in the same
directory.
* Using lexists instead of exists so invalid symlinks are handled correctly.
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/context.py | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oeqa/selftest/context.py
b/meta/lib/oeqa/selftest/context.py
index dab72688299..c5212903276 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -101,10 +101,15 @@ class
OESelftestTestContextExecutor(OETestContextExecutor):
def _process_args(self, logger, args):
args.test_start_time = time.strftime("%Y%m%d%H%M%S")
-args.output_log = '%s-results-%s.log' % (self.name,
args.test_start_time)
args.test_data_file = None
args.CASES_PATHS = None
+bbvars = get_bb_vars()
+logdir = os.environ.get("BUILDDIR")
+if 'LOG_DIR' in bbvars:
+logdir = bbvars['LOG_DIR']
+args.output_log = logdir + '/%s-results-%s.log' % (self.name,
args.test_start_time)
+
super(OESelftestTestContextExecutor, self)._process_args(logger, args)
if args.list_modules:
@@ -114,7 +119,7 @@ class OESelftestTestContextExecutor(OETestContextExecutor):
elif args.list_tests:
args.list_tests = 'name'
-self.tc_kwargs['init']['td'] = get_bb_vars()
+self.tc_kwargs['init']['td'] = bbvars
self.tc_kwargs['init']['machines'] = self._get_available_machines()
builddir = os.environ.get("BUILDDIR")
@@ -304,7 +309,7 @@ class OESelftestTestContextExecutor(OETestContextExecutor):
output_link = os.path.join(os.path.dirname(args.output_log),
"%s-results.log" % self.name)
-if os.path.exists(output_link):
+if os.path.lexists(output_link):
os.remove(output_link)
os.symlink(args.output_log, output_link)
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] meta-selftest/error: Cleanup large trailing whitespace
Signed-off-by: Richard Purdie
---
meta-selftest/recipes-test/error/error.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-selftest/recipes-test/error/error.bb
b/meta-selftest/recipes-test/error/error.bb
index 3c22e7cbebb..65d00a46d99 100644
--- a/meta-selftest/recipes-test/error/error.bb
+++ b/meta-selftest/recipes-test/error/error.bb
@@ -2,7 +2,7 @@ SUMMARY = "Error Test case that fails on do_compile"
DESCRIPTION = "This generates a compile time error to be used to for testing."
LICENSE = "MIT"
-INHIBIT_DEFAULT_DEPS = "1"
+INHIBIT_DEFAULT_DEPS = "1"
EXCLUDE_FROM_WORLD = "1"
do_compile() {
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] oeqa/selftest/runcmd: Increase timeout delta
Expecting 1s accuracy on a 2s timeout on a heavily loaded system has proven to be unreliable. Update this to a 5s timeout with a 3s delta which should be achievable. Signed-off-by: Richard Purdie --- meta/lib/oeqa/selftest/cases/runcmd.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/lib/oeqa/selftest/cases/runcmd.py b/meta/lib/oeqa/selftest/cases/runcmd.py index d76d7063c69..a1615cfd20b 100644 --- a/meta/lib/oeqa/selftest/cases/runcmd.py +++ b/meta/lib/oeqa/selftest/cases/runcmd.py @@ -24,8 +24,8 @@ class RunCmdTests(OESelftestTestCase): # The delta is intentionally smaller than the timeout, to detect cases where # we incorrectly apply the timeout more than once. -TIMEOUT = 2 -DELTA = 1 +TIMEOUT = 5 +DELTA = 3 @OETestID(1916) def test_result_okay(self): -- 2.19.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] oeqa/selftest/buildoptions: Improve ccache test
This test occisionally fails as m4 doesn't recompile, meaning the logfile test
then doesn't find mention of ccache.
To ensure m4 does recompile, clean m4 before force compiling it.
(Reading the test is confusing due to the test cleanup also involving a clean)
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/buildoptions.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/lib/oeqa/selftest/cases/buildoptions.py
b/meta/lib/oeqa/selftest/cases/buildoptions.py
index 9b87e7fcfcc..c3c90a0b0dc 100644
--- a/meta/lib/oeqa/selftest/cases/buildoptions.py
+++ b/meta/lib/oeqa/selftest/cases/buildoptions.py
@@ -38,6 +38,7 @@ class ImageOptionsTests(OESelftestTestCase):
self.assertTrue(os.path.isfile(p), msg = "No ccache found (%s)" % p)
self.write_config('INHERIT += "ccache"')
self.add_command_to_tearDown('bitbake -c clean m4')
+bitbake("m4 -c clean")
bitbake("m4 -f -c compile")
log_compile = os.path.join(get_bb_var("WORKDIR","m4"),
"temp/log.do_compile")
with open(log_compile, "r") as f:
--
2.19.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] libtasn1: no need to inherit binconfig
This recipe doesn't ship a *-config binary, so don't inherit binconfig. Signed-off-by: Ross Burton --- meta/recipes-support/gnutls/libtasn1_4.13.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-support/gnutls/libtasn1_4.13.bb b/meta/recipes-support/gnutls/libtasn1_4.13.bb index 2d223861c71..9ee19130916 100644 --- a/meta/recipes-support/gnutls/libtasn1_4.13.bb +++ b/meta/recipes-support/gnutls/libtasn1_4.13.bb @@ -18,6 +18,6 @@ DEPENDS = "bison-native" SRC_URI[md5sum] = "ce2ba4d3088119b48e7531a703669c52" SRC_URI[sha256sum] = "7e528e8c317ddd156230c4e31d082cd13e7ddeb7a54824be82632209550c8cca" -inherit autotools texinfo binconfig lib_package gtk-doc +inherit autotools texinfo lib_package gtk-doc BBCLASSEXTEND = "native" -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for "cpio: fix crash when appending..." and 1 more
== Series Details == Series: "cpio: fix crash when appending..." and 1 more Revision: 1 URL : https://patchwork.openembedded.org/series/15132/ 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[1/2] cpio: fix crash when appending to archives Issue Missing or incorrectly formatted CVE tag in included patch file [test_cve_tag_format] Suggested fixCorrect or include the CVE tag on cve patch with format: "CVE: CVE--" 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] [PATCH 2/2] image_types: use cpio-native to build cpio images
As per the previous commit, upstream cpio has a bug which means it crashes on append. If the image being built has already had testimage ran then cpio-native will be in the sysroot. It's also possible that some distributions are shipping this broken CVE patch too. Now that our cpio-native is fixed, until we can be sure that the host cpio isn't broken depend on cpio-native if building a cpio image. [ YOCTO #13042 ] Signed-off-by: Ross Burton --- meta/classes/image_types.bbclass | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass index 5c406481ef0..70bd3153067 100644 --- a/meta/classes/image_types.bbclass +++ b/meta/classes/image_types.bbclass @@ -239,6 +239,7 @@ EXTRA_IMAGECMD_ext4 ?= "-i 4096" EXTRA_IMAGECMD_btrfs ?= "-n 4096" EXTRA_IMAGECMD_f2fs ?= "" +do_image_cpio[depends] += "cpio-native:do_populate_sysroot" do_image_jffs2[depends] += "mtd-utils-native:do_populate_sysroot" do_image_cramfs[depends] += "util-linux-native:do_populate_sysroot" do_image_ext2[depends] += "e2fsprogs-native:do_populate_sysroot" -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] cpio: fix crash when appending to archives
The upstream fix for CVE-2016-2037 introduced a read from uninitialized memory
bug when appending to an existing archive, which is an operation we perform when
building an image.
Signed-off-by: Ross Burton
---
.../cpio-2.12/0001-Fix-segfault-with-append.patch | 87 ++
meta/recipes-extended/cpio/cpio_2.12.bb| 1 +
2 files changed, 88 insertions(+)
create mode 100644
meta/recipes-extended/cpio/cpio-2.12/0001-Fix-segfault-with-append.patch
diff --git
a/meta/recipes-extended/cpio/cpio-2.12/0001-Fix-segfault-with-append.patch
b/meta/recipes-extended/cpio/cpio-2.12/0001-Fix-segfault-with-append.patch
new file mode 100644
index 000..2043c890cde
--- /dev/null
+++ b/meta/recipes-extended/cpio/cpio-2.12/0001-Fix-segfault-with-append.patch
@@ -0,0 +1,87 @@
+Upstream-Status: Submitted [bugs-cpio]
+Signed-off-by: Ross Burton
+
+From 3f0bd5a40ad0ceaee78c74a52a7166ed7f08db81 Mon Sep 17 00:00:00 2001
+From: Pavel Raiskup
+Date: Thu, 29 Nov 2018 07:03:48 +0100
+Subject: [PATCH] Fix segfault with --append
+
+The --append mode combines both process_copy_in() and
+process_copy_out() methods, each of them working with different
+(local) file_hdr->c_name buffers. So ensure that
+cpio_set_c_name() isn't using the same static variable for
+maintaining length of different buffers.
+
+Complements d36ec5f4e93130efb24fb9. Thanks to Ross Burton.
+
+* src/copyin.c (process_copy_in): Always initialize file_hdr.
+* src/copyout.c (process_copy_out): Likewise.
+* src/cpiohdr.h (cpio_file_stat): Add c_name_buflen variable.
+* src/util.c (cpio_set_c_name): Use file_hdr->c_name_buflen.
+---
+ src/copyin.c | 1 +
+ src/copyout.c | 1 +
+ src/cpiohdr.h | 1 +
+ src/util.c| 3 ++-
+ 4 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/src/copyin.c b/src/copyin.c
+index ba887ae..767c2f8 100644
+--- a/src/copyin.c
b/src/copyin.c
+@@ -1213,6 +1213,7 @@ process_copy_in ()
+
+ newdir_umask = umask (0); /* Reset umask to preserve modes of
+ created files */
++ memset (&file_hdr, 0, sizeof (struct cpio_file_stat));
+
+ /* Initialize the copy in. */
+ if (pattern_file_name)
+diff --git a/src/copyout.c b/src/copyout.c
+index 7532dac..fb890cb 100644
+--- a/src/copyout.c
b/src/copyout.c
+@@ -594,6 +594,7 @@ process_copy_out ()
+
+ /* Initialize the copy out. */
+ ds_init (&input_name, 128);
++ memset (&file_hdr, 0, sizeof (struct cpio_file_stat));
+ file_hdr.c_magic = 070707;
+
+ /* Check whether the output file might be a tape. */
+diff --git a/src/cpiohdr.h b/src/cpiohdr.h
+index 588135b..cf64f3e 100644
+--- a/src/cpiohdr.h
b/src/cpiohdr.h
+@@ -127,6 +127,7 @@ struct cpio_file_stat /* Internal representation of a CPIO
header */
+ uint32_t c_chksum;
+ char *c_name;
+ char *c_tar_linkname;
++ size_t c_name_buflen;
+ };
+
+ void cpio_set_c_name(struct cpio_file_stat *file_hdr, char *name);
+diff --git a/src/util.c b/src/util.c
+index 10486dc..1256469 100644
+--- a/src/util.c
b/src/util.c
+@@ -1413,7 +1413,7 @@ set_file_times (int fd,
+ void
+ cpio_set_c_name (struct cpio_file_stat *file_hdr, char *name)
+ {
+- static size_t buflen = 0;
++ size_t buflen = file_hdr->c_name_buflen;
+ size_t len = strlen (name) + 1;
+
+ if (buflen == 0)
+@@ -1430,6 +1430,7 @@ cpio_set_c_name (struct cpio_file_stat *file_hdr, char
*name)
+ }
+
+ file_hdr->c_namesize = len;
++ file_hdr->c_name_buflen = buflen;
+ memmove (file_hdr->c_name, name, len);
+ }
+
+--
+2.11.0
+
diff --git a/meta/recipes-extended/cpio/cpio_2.12.bb
b/meta/recipes-extended/cpio/cpio_2.12.bb
index 69d36983e39..6ba8337e5d9 100644
--- a/meta/recipes-extended/cpio/cpio_2.12.bb
+++ b/meta/recipes-extended/cpio/cpio_2.12.bb
@@ -10,6 +10,7 @@ SRC_URI = "${GNU_MIRROR}/cpio/cpio-${PV}.tar.gz \
file://0001-Unset-need_charset_alias-when-building-for-musl.patch \
file://0001-Fix-CVE-2015-1197.patch \
file://0001-CVE-2016-2037-1-byte-out-of-bounds-write.patch \
+ file://0001-Fix-segfault-with-append.patch \
"
SRC_URI[md5sum] = "fc207561a86b63862eea4b8300313e86"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] netbase: add entry to /etc/hosts according to /etc/hostname
We default hostname to ${MACHINE}, but it's not in /etc/hosts,
resulting in commands like `hostname -f' failing due to lack
of entry.
So add entry to /etc/hosts according to /etc/hostname. We do
this via pkg_postinst because hostname is set in base-files
recipe.
Signed-off-by: Chen Qi
---
meta/recipes-core/netbase/netbase_5.4.bb | 11 +++
1 file changed, 11 insertions(+)
diff --git a/meta/recipes-core/netbase/netbase_5.4.bb
b/meta/recipes-core/netbase/netbase_5.4.bb
index 5ab0c58..da9255a 100644
--- a/meta/recipes-core/netbase/netbase_5.4.bb
+++ b/meta/recipes-core/netbase/netbase_5.4.bb
@@ -23,3 +23,14 @@ do_install () {
}
CONFFILES_${PN} = "${sysconfdir}/hosts"
+
+RDEPENDS_${PN} += "base-files"
+
+pkg_postinst_${PN} () {
+ if [ -s $D${sysconfdir}/hostname ]; then
+ hostname=`cat $D${sysconfdir}/hostname`
+ if ! grep -q "[[:space:]]$hostname[[:space:]]*"
$D${sysconfdir}/hosts; then
+ echo "127.0.1.1 $hostname" >> $D${sysconfdir}/hosts
+ fi
+ fi
+}
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] netbase: add entry to /etc/hosts according to /etc/hostname
Changes in V2:
* use ${sysconfdir} instead of /etc
* check the existence of entry before adding it
The following changes since commit 41d89552620bfbc94031d314e6b3d0324f7a330e:
bitbake: fetch2: Avoid warning about incorrect character escaping in regex
(2018-11-27 22:15:34 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib ChenQi/netbase-hosts
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/netbase-hosts
Chen Qi (1):
netbase: add entry to /etc/hosts according to /etc/hostname
meta/recipes-core/netbase/netbase_5.4.bb | 11 +++
1 file changed, 11 insertions(+)
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3 4/4] oe-selftest: add some tests for recipeutils module
Add some tests for functions in meta/lib/oe/recipeutils.py, in
particular for a few issues I've just fixed. I haven't added tests for
all of the functions - some of them are already being tested via devtool
in any case.
Signed-off-by: Paul Eggleton
---
.../python/python-async-test.inc | 16 ++
.../python/python3-async-test_0.6.2.bb| 2 +
.../recipeutils/recipeutils-test.inc | 5 +
.../recipeutils/recipeutils-test/anotherfile | 0
.../recipeutils/recipeutils-test/somefile | 0
.../recipeutils/recipeutils-test_1.2.bb | 13 ++
meta/lib/oeqa/selftest/cases/recipeutils.py | 138 ++
7 files changed, 174 insertions(+)
create mode 100644 meta-selftest/recipes-devtools/python/python-async-test.inc
create mode 100644
meta-selftest/recipes-devtools/python/python3-async-test_0.6.2.bb
create mode 100644 meta-selftest/recipes-test/recipeutils/recipeutils-test.inc
create mode 100644
meta-selftest/recipes-test/recipeutils/recipeutils-test/anotherfile
create mode 100644
meta-selftest/recipes-test/recipeutils/recipeutils-test/somefile
create mode 100644
meta-selftest/recipes-test/recipeutils/recipeutils-test_1.2.bb
create mode 100644 meta/lib/oeqa/selftest/cases/recipeutils.py
diff --git a/meta-selftest/recipes-devtools/python/python-async-test.inc
b/meta-selftest/recipes-devtools/python/python-async-test.inc
new file mode 100644
index 000..c9602e8e52d
--- /dev/null
+++ b/meta-selftest/recipes-devtools/python/python-async-test.inc
@@ -0,0 +1,16 @@
+SUMMARY = "Python framework to process interdependent tasks in a pool of
workers"
+HOMEPAGE = "http://github.com/gitpython-developers/async";
+SECTION = "devel/python"
+LICENSE = "BSD"
+LIC_FILES_CHKSUM =
"file://PKG-INFO;beginline=8;endline=8;md5=88df8e78b9edfd744953862179f2d14e"
+
+inherit pypi
+
+PYPI_PACKAGE = "async"
+
+SRC_URI[md5sum] = "9b06b5997de2154f3bc0273f80bcef6b"
+SRC_URI[sha256sum] =
"ac6894d876e45878faae493b0cf61d0e28ec417334448ac0a6ea2229d8343051"
+
+RDEPENDS_${PN} += "${PYTHON_PN}-threading"
+
+BBCLASSEXTEND = "nativesdk"
diff --git a/meta-selftest/recipes-devtools/python/python3-async-test_0.6.2.bb
b/meta-selftest/recipes-devtools/python/python3-async-test_0.6.2.bb
new file mode 100644
index 000..22e241afb3c
--- /dev/null
+++ b/meta-selftest/recipes-devtools/python/python3-async-test_0.6.2.bb
@@ -0,0 +1,2 @@
+inherit setuptools3
+require python-async-test.inc
diff --git a/meta-selftest/recipes-test/recipeutils/recipeutils-test.inc
b/meta-selftest/recipes-test/recipeutils/recipeutils-test.inc
new file mode 100644
index 000..8490b902d75
--- /dev/null
+++ b/meta-selftest/recipes-test/recipeutils/recipeutils-test.inc
@@ -0,0 +1,5 @@
+SRC_URI =
"http://xorg.freedesktop.org/releases/individual/lib/libxshmfence-${PV}.tar.bz2";
+
+SRC_URI[md5sum] = "2e76899112c0f99e22f2fc775a7e"
+SRC_URI[sha256sum] =
"d21b2d1fd78c1efbe1f2c16dae1cb23f8fd231dcf891465b8debe636a9054b0c"
+
diff --git
a/meta-selftest/recipes-test/recipeutils/recipeutils-test/anotherfile
b/meta-selftest/recipes-test/recipeutils/recipeutils-test/anotherfile
new file mode 100644
index 000..e69de29bb2d
diff --git a/meta-selftest/recipes-test/recipeutils/recipeutils-test/somefile
b/meta-selftest/recipes-test/recipeutils/recipeutils-test/somefile
new file mode 100644
index 000..e69de29bb2d
diff --git a/meta-selftest/recipes-test/recipeutils/recipeutils-test_1.2.bb
b/meta-selftest/recipes-test/recipeutils/recipeutils-test_1.2.bb
new file mode 100644
index 000..f6da97b2d43
--- /dev/null
+++ b/meta-selftest/recipes-test/recipeutils/recipeutils-test_1.2.bb
@@ -0,0 +1,13 @@
+SUMMARY = "Test recipe for recipeutils.patch_recipe()"
+
+require recipeutils-test.inc
+
+LICENSE = "Proprietary"
+
+DEPENDS += "virtual/libx11"
+
+BBCLASSEXTEND = "native nativesdk"
+
+SRC_URI += "file://somefile"
+
+SRC_URI_append = " file://anotherfile"
diff --git a/meta/lib/oeqa/selftest/cases/recipeutils.py
b/meta/lib/oeqa/selftest/cases/recipeutils.py
new file mode 100644
index 000..b7cb55baae1
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/recipeutils.py
@@ -0,0 +1,138 @@
+import os
+import re
+import time
+import logging
+import bb.tinfoil
+
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import runCmd
+from oeqa.core.decorator.oeid import OETestID
+
+
+def setUpModule():
+global tinfoil
+tinfoil = bb.tinfoil.Tinfoil(tracking=True)
+tinfoil.prepare(config_only=False, quiet=2)
+
+
+def tearDownModule():
+tinfoil.shutdown()
+
+
+class RecipeUtilsTests(OESelftestTestCase):
+""" Tests for the recipeutils module functions """
+
+def test_patch_recipe_varflag(self):
+import oe.recipeutils
+rd = tinfoil.parse_recipe('python3-async-test')
+vals = {'SRC_URI[md5sum]': 'aa', 'LICENSE': 'something'}
+corebase = rd.getVar('COREBASE')
+patches = oe.recipeutils.patch_recipe(rd, rd.getVar('FILE'), vals,
