date:20170721

Re: [OE-core] [PATCH] kernel: fitimage: deploy real fit-image

2017-07-21 Thread Denys Dmytriyenko

On Mon, Jul 17, 2017 at 08:54:57PM -0400, Gaël PORTAY wrote:
> Currently, do_deploy installs a standard kernel image as an ITB. This
> image is linux.bin and it is prepared by uboot_prep_kimage.
> 
> The real kernel fit-image is build under arch/${ARCH}/boot/fitImage.
> 
> This patch deploys the real fit-image instead of the one prepared by
> u-boot and which is included in the ITB.
> 
> Note: this patch only concerns fit-images which are not signed by u-boot
> or which do not contains initramfs. Only a kernel image with a
> device-tree.
> 
> Signed-off-by: Gaël PORTAY 

Reviewed-by: Denys Dmytriyenko 


> ---
> Hi all,
> 
> This patch is a modified version of the one I wrote on a meta-arago/morty
> build. Thus it is not tested, but it should work.
> 
> In the deploy image directory, I had
> 
>   $ file -L fitImage 
>   fitImage: Linux kernel ARM boot executable zImage (little-endian)
> 
> With the patch, I have
> 
>   $ file -L fitImage 
>   fitImage: data
> 
> Regards,
> Gael
> 
>  meta/classes/kernel-fitimage.bbclass | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/classes/kernel-fitimage.bbclass 
> b/meta/classes/kernel-fitimage.bbclass
> index 2630b47316..a745e873c1 100644
> --- a/meta/classes/kernel-fitimage.bbclass
> +++ b/meta/classes/kernel-fitimage.bbclass
> @@ -453,9 +453,9 @@ kernel_do_deploy_append() {
>   its_base_name="fitImage-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
>   its_symlink_name=fitImage-its-${MACHINE}
>   install -m 0644 fit-image.its ${DEPLOYDIR}/${its_base_name}.its
> - 
> linux_bin_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
> - linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
> - install -m 0644 linux.bin 
> ${DEPLOYDIR}/${linux_bin_base_name}.bin
> + 
> itb_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
> + itb_symlink_name=fitImage-linux.bin-${MACHINE}
> + install -m 0644 arch/${ARCH}/boot/fitImage 
> ${DEPLOYDIR}/${itb_base_name}.bin
>  
>   if [ -n "${INITRAMFS_IMAGE}" ]; then
>   echo "Copying fit-image-${INITRAMFS_IMAGE}.its source 
> file..."
> @@ -469,7 +469,7 @@ kernel_do_deploy_append() {
>  
>   cd ${DEPLOYDIR}
>   ln -sf ${its_base_name}.its ${its_symlink_name}.its
> - ln -sf ${linux_bin_base_name}.bin ${linux_bin_symlink_name}.bin
> + ln -sf ${itb_base_name}.bin ${itb_symlink_name}.bin
>  
>   if [ -n "${INITRAMFS_IMAGE}" ]; then
>   ln -sf ${its_initramfs_base_name}.its 
> ${its_initramfs_symlink_name}.its
> -- 
> 2.13.2
> 
> -- 
> ___
> 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 2/2] image_types.bbclass: Make u-boot signed images more versatile

2017-07-21 Thread Tom Rini

With the introduction of chaining compression/conversion support we can
convert the old image_types_uboot.bbclass code that did a hand-chaining
of a set of ${filesystem}.${compression} into generic and arbitrary
support to sign whatever the user wants to sign for their image.

This, for the record, does remove setting a valid compression type in
the record in favour of just saying none.  This is not a generally
useful feature in U-Boot and I believe being versatile in terms of being
able to pass in arbitrary compressions is more important.

Signed-off-by: Tom Rini 
---
 meta/classes/image.bbclass |  9 -
 meta/classes/image_types.bbclass   |  6 --
 meta/classes/image_types_uboot.bbclass | 29 -
 3 files changed, 4 insertions(+), 40 deletions(-)
 delete mode 100644 meta/classes/image_types_uboot.bbclass

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index bd6a5b7b810a..b095bca7c12a 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -144,15 +144,6 @@ inherit ${IMAGE_TYPE_vm}
 IMAGE_TYPE_container = '${@bb.utils.contains("IMAGE_FSTYPES", "container", 
"image-container", "", d)}'
 inherit ${IMAGE_TYPE_container}
 
-def build_uboot(d):
-if 'u-boot' in (d.getVar('IMAGE_FSTYPES') or ''):
-return "image_types_uboot"
-else:
-return ""
-
-IMAGE_TYPE_uboot = "${@build_uboot(d)}"
-inherit ${IMAGE_TYPE_uboot}
-
 IMAGE_TYPE_wic = "image_types_wic"
 inherit ${IMAGE_TYPE_wic}
 
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 8f8d79cd3d70..4fdcde25b4f5 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -214,7 +214,7 @@ IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o 
${IMGDEPLOYDIR}/${IMAGE_NAME
 
 EXTRA_IMAGECMD = ""
 
-inherit siteinfo
+inherit siteinfo kernel-arch
 JFFS2_ENDIANNESS ?= "${@base_conditional('SITEINFO_ENDIANNESS', 'le', '-l', 
'-b', d)}"
 JFFS2_ERASEBLOCK ?= "0x4"
 EXTRA_IMAGECMD_jffs2 ?= "--pad ${JFFS2_ENDIANNESS} 
--eraseblock=${JFFS2_ERASEBLOCK} --no-cleanmarkers"
@@ -269,7 +269,7 @@ IMAGE_TYPES = " \
 # CONVERSION_CMD/DEPENDS.
 COMPRESSIONTYPES ?= ""
 
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum 
sha256sum sha384sum sha512sum bmap ${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum sha224sum 
sha256sum sha384sum sha512sum bmap u-boot ${COMPRESSIONTYPES}"
 CONVERSION_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
 CONVERSION_CMD_gz = "gzip -f -9 -c ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
 CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -286,6 +286,7 @@ CONVERSION_CMD_sha256sum = "sha256sum 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
 CONVERSION_CMD_sha384sum = "sha384sum 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha384sum"
 CONVERSION_CMD_sha512sum = "sha512sum 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.sha512sum"
 CONVERSION_CMD_bmap = "bmaptool create 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} -o 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.bmap"
+CONVERSION_CMD_u-boot = "mkimage -A ${UBOOT_ARCH} -O linux -T ramdisk -C none 
-n ${IMAGE_NAME} -d ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} 
${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.u-boot"
 CONVERSION_DEPENDS_lzma = "xz-native"
 CONVERSION_DEPENDS_gz = "pigz-native"
 CONVERSION_DEPENDS_bz2 = "pbzip2-native"
@@ -295,6 +296,7 @@ CONVERSION_DEPENDS_lzo = "lzop-native"
 CONVERSION_DEPENDS_zip = "zip-native"
 CONVERSION_DEPENDS_sum = "mtd-utils-native"
 CONVERSION_DEPENDS_bmap = "bmap-tools-native"
+CONVERSION_DEPENDS_u-boot = "u-boot-mkimage-native"
 
 RUNNABLE_IMAGE_TYPES ?= "ext2 ext3 ext4"
 RUNNABLE_MACHINE_PATTERNS ?= "qemu"
diff --git a/meta/classes/image_types_uboot.bbclass 
b/meta/classes/image_types_uboot.bbclass
deleted file mode 100644
index 8db436efb14b..
--- a/meta/classes/image_types_uboot.bbclass
+++ /dev/null
@@ -1,29 +0,0 @@
-inherit image_types kernel-arch
-
-oe_mkimage () {
-mkimage -A ${UBOOT_ARCH} -O linux -T ramdisk -C $2 -n ${IMAGE_NAME} \
--d ${IMGDEPLOYDIR}/$1 ${IMGDEPLOYDIR}/$1.u-boot
-}
-
-CONVERSIONTYPES += "gz.u-boot bz2.u-boot lz4.u-boot lzma.u-boot lzo.u-boot 
u-boot"
-
-CONVERSION_DEPENDS_u-boot = "u-boot-mkimage-native"
-CONVERSION_CMD_u-boot  = "oe_mkimage ${IMAGE_NAME}.rootfs.${type} none"
-
-CONVERSION_DEPENDS_gz.u-boot = "u-boot-mkimage-native"
-CONVERSION_CMD_gz.u-boot  = "${CONVERSION_CMD_gz}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.gz gzip"
-
-CONVERSION_DEPENDS_bz2.u-boot = "u-boot-mkimage-native"
-CONVERSION_CMD_bz2.u-boot  = "${CONVERSION_CMD_bz2}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.bz2 bzip2"
-
-CONVERSION_DEPENDS_lz4.u-boot = "u-boot-mkimage-native"
-CONVERSION_CMD_lz4.u-boot  =

[OE-core] [PATCH 1/2] image.bbclass: Correct chaining compression support

2017-07-21 Thread Tom Rini

When chaining of compression/conversion types was added, we had a new
way to handle doing things like "ext4.bz2.sha256sum" or
"ext2.gz.u-boot".  However, because the U-Boot image class isn't
included normally, it wasn't properly converted at the time.  After the
support was added the "clean" argument that the .u-boot code uses no
longer functions.  The fix for this inadvertently broke chaining
compression/conversion.  First, correct the u-boot conversion code.

Fixes: 46bc438374de ("image.bbclass: do exact match for rootfs type")
Cc: Zhenhua Luo 
Cc: Richard Purdie 
Cc: Patrick Ohly 
Signed-off-by: Tom Rini 
---
This change is fairly important and, imho, innocuous and should be
populated to pyro/etc, once merged to master.  The next part of the
series is clean-up and while with my U-Boot hat on, I would say should
be pushed more widely, I am biased.
---
 meta/classes/image.bbclass |  2 +-
 meta/classes/image_types_uboot.bbclass | 13 +
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index de535ce6fcff..bd6a5b7b810a 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -453,7 +453,7 @@ python () {
 rm_tmp_images = set()
 def gen_conversion_cmds(bt):
 for ctype in ctypes:
-if bt[bt.find('.') + 1:] == ctype:
+if bt.endswith("." + ctype):
 type = bt[0:-len(ctype) - 1]
 if type.startswith("debugfs_"):
 type = type[8:]
diff --git a/meta/classes/image_types_uboot.bbclass 
b/meta/classes/image_types_uboot.bbclass
index 5dfa39287dab..8db436efb14b 100644
--- a/meta/classes/image_types_uboot.bbclass
+++ b/meta/classes/image_types_uboot.bbclass
@@ -3,9 +3,6 @@ inherit image_types kernel-arch
 oe_mkimage () {
 mkimage -A ${UBOOT_ARCH} -O linux -T ramdisk -C $2 -n ${IMAGE_NAME} \
 -d ${IMGDEPLOYDIR}/$1 ${IMGDEPLOYDIR}/$1.u-boot
-if [ x$3 = x"clean" ]; then
-rm $1
-fi
 }
 
 CONVERSIONTYPES += "gz.u-boot bz2.u-boot lz4.u-boot lzma.u-boot lzo.u-boot 
u-boot"
@@ -14,19 +11,19 @@ CONVERSION_DEPENDS_u-boot = "u-boot-mkimage-native"
 CONVERSION_CMD_u-boot  = "oe_mkimage ${IMAGE_NAME}.rootfs.${type} none"
 
 CONVERSION_DEPENDS_gz.u-boot = "u-boot-mkimage-native"
-CONVERSION_CMD_gz.u-boot  = "${CONVERSION_CMD_gz}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.gz gzip clean"
+CONVERSION_CMD_gz.u-boot  = "${CONVERSION_CMD_gz}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.gz gzip"
 
 CONVERSION_DEPENDS_bz2.u-boot = "u-boot-mkimage-native"
-CONVERSION_CMD_bz2.u-boot  = "${CONVERSION_CMD_bz2}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.bz2 bzip2 clean"
+CONVERSION_CMD_bz2.u-boot  = "${CONVERSION_CMD_bz2}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.bz2 bzip2"
 
 CONVERSION_DEPENDS_lz4.u-boot = "u-boot-mkimage-native"
-CONVERSION_CMD_lz4.u-boot  = "${CONVERSION_CMD_lz4_legacy}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.lz4 lz4 clean"
+CONVERSION_CMD_lz4.u-boot  = "${CONVERSION_CMD_lz4_legacy}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.lz4 lz4"
 
 CONVERSION_DEPENDS_lzma.u-boot = "u-boot-mkimage-native"
-CONVERSION_CMD_lzma.u-boot  = "${CONVERSION_CMD_lzma}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.lzma lzma clean"
+CONVERSION_CMD_lzma.u-boot  = "${CONVERSION_CMD_lzma}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.lzma lzma"
 
 CONVERSION_DEPENDS_lzo.u-boot = "u-boot-mkimage-native"
-CONVERSION_CMD_lzo.u-boot  = "${CONVERSION_CMD_lzo}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.lzo lzo clean"
+CONVERSION_CMD_lzo.u-boot  = "${CONVERSION_CMD_lzo}; oe_mkimage 
${IMAGE_NAME}.rootfs.${type}.lzo lzo"
 
 IMAGE_TYPES += "ext2.u-boot ext2.gz.u-boot ext2.bz2.u-boot ext2.lzma.u-boot 
ext3.gz.u-boot ext4.gz.u-boot cpio.gz.u-boot"
 
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [poky][master][PATCH v2 0/1] initramfs-framework: include install-efi module in recipe for installation

2017-07-21 Thread Richard Purdie

Hi,

On Sun, 2017-07-16 at 12:29 -0700, wei.tee...@intel.com wrote:
> From: "Ng, Wei Tee" 
> 
> This patch is to enable the installation mechanism in initramfs-
> framework.
> It used the existing init-install-efi.sh script in the initrdscript
> and 
> install a new module named initramfs-module-install-efi in the
> recipe.
> 
> I put all the changes as a single commit. This version 2 had renamed
> the
> existing init-install-efi.sh to install-efi.sh and package name
> changed
> to install-efi.
> 
> This patch shall encounter a patchtest failure as it is depends on a
> patch which have been sent to the mailing list and waiting for
> acceptance. The dependency patch can be found in here:
> http://lists.openembedded.org/pipermail/openembedded-core/2017-July/1
> 39570.html
> 
> This changes has been verified with build test, boot up test and
> installation test on Minnowboard Max platform.
> 
> Please review and provide feedback if you have any.
> The patches are targeted for merging into poky master branch.

I think the RDEPENDS in this patch cause problems when added to an
allarch recipe. You can see this issue by running:

oe-selftest -r sstatetests.SStateTests.test_sstate_allarch_samesigs

(it failed on the autobuilder:
https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/399/st
eps/Running%20oe-selftest/logs/stdio)

We need to resolve this before the two initramfs-framework patches can
be merged.

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] opkg.py Adds tests for ipk/opkg

2017-07-21 Thread Cruz, Libertad

This tests are made for runtime/cases, I believe it is the format other runtime 
test are script, they only check for return code == 0 . Should we consider 
opening another bug to add opkg testcases to selftest?

Best Regards
Libertad G.

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Monday, July 17, 2017 7:28 AM
To: Cruz, Libertad 
Cc: OE-core 
Subject: Re: [OE-core] [PATCH v2] opkg.py Adds tests for ipk/opkg


On 10 July 2017 at 21:22, 
> wrote:
+class opkgBasicTest(opkgTest):
+@skipIfNotFeature('package-management', 'Test requires package-management 
to be in IMAGE_FEATURES')
+@skipIfNotDataVar('IMAGE_PKGTYPE','ipk', 'IPK is not the primary package 
manager')
+@OEHasPackage(['opkg'])
+
+@OETestDepends(['ssh.SSHTest.test_ssh'])
+@OETestID(1841)
+def test_opkg_list(self):
+   self.opkg('list')
+
+@OETestID(1842)
+def test_opkg_list_installed(self):
+   self.opkg('list-installed')
+
+@OETestID(1843)
+def test_opkg_depends(self):
+   self.opkg('depends opkg')
+
+@OETestID(1837)
+def test_opkg_whatdepends(self):
+  self.opkg('whatdepends opkg')
+
+@OETestID(1838)
+def test_opkg_status(self):
+  self.opkg('status')
+
+@OETestID(1839)
+def test_opkg_info(self):
+self.opkg('info opkg')
+
+@OETestID(1840)
+def test_opkg_print_architecture(self):
+self.opkg('print-architecture')

I'd feel a lot happier that this was a selftest if it was exercising more than 
"opkg doesn't crash".  If opkg is replaced by a script that does "echo haha; 
exit 0" this test case would pass, so can it verify the output too.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] image-vm: Convert vmdk/vdi/qcow2/hdddirect images to IMAGE_CMD

2017-07-21 Thread Tom Rini

On Fri, Jul 21, 2017 at 03:01:33PM +0200, Patrick Ohly wrote:
> On Fri, 2017-07-21 at 07:21 -0400, Tom Rini wrote:
> > On Fri, Jul 21, 2017 at 09:47:21AM +0200, Patrick Ohly wrote:
> > > On Thu, 2017-07-20 at 18:43 -0400, Tom Rini wrote:
> > > > The support for writing vmdk/vdi/qcow2 images has not been converted to 
> > > > make
> > > > use of the IMAGE_CMD infrastructure and instead relies on custom logic 
> > > > for
> > > > adding tasks in the right place.  Convert these images to making use of
> > > > IMAGE_CMD.
> > > 
> > > Thanks for working on this. I still have
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10204 open for
> > > enhancing vmdk/vdi/qcow2.
> > > 
> > > However, your patch doesn't go as far as described in that bug, does it?
> > > Instead of allowing, for example, IMAGE_FSTYPES = "wic.vmdk", it merely
> > > changes how IMAGE_FSTYPES = "vmdk" is implemented.
> > > 
> > > The current patch has its merits as it simplifies the implementation,
> > > but I think it would be worthwhile to go all the way, even if it changes
> > > how images are going to be named.
> > 
> > Ah, interesting.  I guess the first thing I would argue against is
> > saying that hdddirect should be masked.  There are reasons to want to
> > have a raw image created.
> 
> I'm not sure I understand what you mean with "hdddirect should be
> masked" - it's been a while that I looked at the code.
> 
> > I will take a look into using CONVERSIONCMD for vmdk/qcow2/vdi to allow
> > for wic.vmdk to work.  But we also must have vmdk.xz work (and fwiw with
> > my series you can get arbitrary compression that we support done, I did
> > vmdk.xz, qcow2.lzo and vdi.bz2 just for 'fun').
> 
> The same is true with CONVERSIONCMD. They can be chained multiple times.
> 
> > But I'm not 100% sure that I like changing the normal case from "vmdk"
> > to "wic.vmdk" or "hdddirect.vmdk" just to get a disk image to throw at
> > ${VM_TECHNOLOGY}.
> 
> Yes, that's the biggest user-visible change. Basically the internal
> implementation (multiple conversions chained together) becomes visible
> in the end-result.
> 
> That is a good and a bad thing. The good thing is that it is visible how
> the .vmdk image was created. The bad thing is that some users might not
> care and get confused.

So, Patrick, Ed and I talked on IRC a bit about this, and I think
without putting too many words in their mouths, I think it can be
summarized like this.

We all agree that vmdk/qcow2/vdi are a type of conversion.  It would be
quite handy to use these conversions on other things, such as wic.

And at least from my point of view, the contents of "hdddirect" doesn't
matter so much as the overall functionality.

So that here's where I'm at now.  I've found out when Patrick's chaining
compression code (so that you could do silly things like ext3.gz.bz2 or
_useful_ things like wic.vmdk.xz) was broken, and I see the best way to
fix that too.  So I'm going to v2 this series shortly which addresses
the problem of chaining compression types, and then brings the VM stuff
over to using that too.

-- 
Tom


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for remove qemu kernel version overrides and superfluous version settings

2017-07-21 Thread Patchwork

== Series Details ==

Series: remove qemu kernel version overrides and superfluous version settings
Revision: 1
URL   : https://patchwork.openembedded.org/series/7865/
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 119dd0889f)

* 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 p...@yoctoproject.org 
[http://git.yoctoproject.org/cgit/cgit.cgi/poky/]
  Patch's path:meta-yocto-bsp/conf/machine/genericx86-64.conf



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] -> ...).

---
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-core][PATCH 1/1] modules: move creation of some module related tools

2017-07-21 Thread Slater, Joseph

Below, is the error and a heavily edited log file.  For those in Wind River, 
the issue is LIN10-858.  Btw, there is duplicate script building code in my 
patch because I forgot to take it out of do_compile_kernelmodules() which is 
where I first moved it to.

Joe



  LD 
/home/wrlbuild/builds/builds-c23c9015-5785-4a83-8075-2a2fa9401ba3/wrlinux-std-sato_intel-skylake-avx512-64_world_10/tmp/work/intel_skylake_avx512_64-wrs-linux/hello-mod/0.1-r0/built-in.o
   CC [M] 
/home/wrlbuild/builds/builds-c23c9015-5785-4a83-8075-2a2fa9401ba3/wrlinux-std-sato_intel-skylake-avx512-64_world_10/tmp/work/intel_skylake_avx512_64-wrs-linux/hello-mod/0.1-r0/hello.o
   Building modules, stage 2.
   MODPOST 1 modules
 /bin/sh: scripts/mod/modpost: Permission denied
 make
 [3]: *** 
[/home/wrlbuild/builds/builds-c23c9015-5785-4a83-8075-2a2fa9401ba3/wrlinux-std-sato_intel-skylake-avx512-64_world_10/tmp/work-shared/intel-skylake-avx512-64/kernel-source/scripts/Makefile.modpost:91:
 __modpost] Error 126
 make[2]: *** 
[/home/wrlbuild/builds/builds-c23c9015-5785-4a83-8075-2a2fa9401ba3/wrlinux-std-sato_intel-skylake-avx512-64_world_10/tmp/work-shared/intel-skylake-avx512-64/kernel-source/Makefile:1475:
 modules] Error 2

(modpost is under work-shared)





 [2017-07-13 21:02:39.512674040-07:00] NOTE: recipe hello-mod-0.1-r0: task 
do_make_scripts: Started

 [2017-07-13 21:02:39.648216523-07:00] NOTE: recipe 
module-debug-example-0.99-r0: task do_make_scripts: Started

 [2017-07-13 21:02:44.190642236-07:00] NOTE: recipe hello-mod-0.1-r0: task 
do_configure: Started

 [2017-07-13 21:02:44.308167085-07:00] NOTE: recipe hello-mod-0.1-r0: task 
do_configure: Succeeded

 [2017-07-13 21:02:45.074545820-07:00] NOTE: recipe 
module-debug-example-0.99-r0: task do_configure: Started

 [2017-07-13 21:02:45.077889943-07:00] NOTE: recipe 
module-debug-example-0.99-r0: task do_configure: Succeeded

 [2017-07-13 21:02:59.371609194-07:00] NOTE: recipe hello-mod-0.1-r0: task 
do_make_scripts: Succeeded

 [2017-07-13 21:03:00.149468691-07:00] NOTE: recipe hello-mod-0.1-r0: task 
do_compile: Started

 [2017-07-13 21:03:02.840652134-07:00] ERROR: hello-mod-0.1-r0 do_compile: 
oe_runmake failed
 [2017-07-13 21:03:04.406712693-07:00] ERROR: hello-mod-0.1-r0 do_compile: 
Function failed: do_compile (log file is located at 
/home/wrlbuild/builds/builds-c23c9015-5785-4a83-8075-2a2fa9401ba3/wrlinux-std-sato_intel-skylake-avx512-64_world_10/tmp/work/intel_skylake_avx512_64-wrs-linux/hello-mod/0.1-r0/temp/log.do_compile.110776)

 [2017-07-13 21:03:04.407703129-07:00] NOTE: recipe 
module-debug-example-0.99-r0: task do_make_scripts: Succeeded






From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
Sent: Friday, July 21, 2017 10:30 AM
To: Slater, Joseph
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [oe-core][PATCH 1/1] modules: move creation of some 
module related tools



On Fri, Jul 21, 2017 at 1:13 PM, Joe Slater 
> wrote:
Move creation of tools needed by module building recipes into
kernel.bbclass but invoke the task only from the module recipes.
Without this change, one module recipe can fail trying to use the
tools while another is (re-)building them.

You are changing some core code that has been protecting our builds for
quite some time .. yet, you have no example of the errors that are being
seen, and no proof that this actually fixes the problem (and that it doesn't
introduce other issues).

i.e. how are the lock files no protecting this in whatever is breaking for you ?

Looking at the change, I'm not convinced it is the right thing to do.

i.e. putting something in kernel.bbclass that is only used by the modules
is less than ideal, without some sort of justification.

Bruce


Signed-off-by: Joe Slater >
---
 meta/classes/kernel.bbclass  | 15 +++
 meta/classes/module-base.bbclass | 10 ++
 meta/classes/module.bbclass  |  4 
 3 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 7670c71..131387e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -280,6 +280,11 @@ kernel_do_compile() {

 do_compile_kernelmodules() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
+
+   # build modpost, etc
+   make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
+  -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} scripts
+
if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
oe_runmake -C ${B} ${PARALLEL_MAKE} modules CC="${KERNEL_CC}" 
LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS}

@@ -296,6 +301,16 @@ do_compile_kernelmodules() {
 }
 addtask compile_kernelmodules after do_compile before do_strip

+# Task to ensure the kernel scripts are created. Expected to be invoked
+# only by module building recipes. See module.bbclass for an

[OE-core] [PATCH 2/2] poky: Remove machine specific kernel overrides

2017-07-21 Thread brian avery

This patch removes the machine specific overrides in poky.conf for all
the qemu machines.  With this patch, if you set
PREFERRED_VERSION_linux-yocto="X%" then all the qemu machines as well as
the sample hardware boards will use that version. Without this patch,
the hardware boards would have used version X but the qemu machines
would have needed to have a PREFERRED_VERSION_linux-yocto_qemuarm="X%"
for qemuarm to use that version, for example.  If we need to force a
specific machine (hardware or qemu) to a particular default version we
should add it to the machine conf files for that machine, not in the
distro conf.

Signed-off-by: brian avery 
---
 meta-poky/conf/distro/poky.conf | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index c907969..d15e50e 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -22,12 +22,6 @@ POKY_DEFAULT_EXTRA_RRECOMMENDS = "kernel-module-af-packet"
 DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC} 
${POKY_DEFAULT_DISTRO_FEATURES}"
 
 PREFERRED_VERSION_linux-yocto ?= "4.10%"
-PREFERRED_VERSION_linux-yocto_qemux86 ?= "4.10%"
-PREFERRED_VERSION_linux-yocto_qemux86-64 ?= "4.10%"
-PREFERRED_VERSION_linux-yocto_qemuarm ?= "4.10%"
-PREFERRED_VERSION_linux-yocto_qemumips ?= "4.10%"
-PREFERRED_VERSION_linux-yocto_qemumips64 ?= "4.10%"
-PREFERRED_VERSION_linux-yocto_qemuppc ?= "4.10%"
 
 SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
 SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}"
@@ -84,9 +78,9 @@ SANITY_TESTED_DISTROS ?= " \
 opensuse-42.2 \n \
 "
 #
-# OELAYOUT_ABI allows us to notify users when the format of TMPDIR changes in 
+# OELAYOUT_ABI allows us to notify users when the format of TMPDIR changes in
 # an incompatible way. Such changes should usually be detailed in the commit
-# that breaks the format and have been previously discussed on the mailing 
list 
+# that breaks the format and have been previously discussed on the mailing list
 # with general agreement from the core team.
 #
 OELAYOUT_ABI = "12"
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] meta-yocto-bsp: Remove superfluous kernel set

2017-07-21 Thread brian avery

The genericx86 and genericx86-64 machine confs do not need to set the
PREFERRED_PROVIDER_virtual/kernel as they will use the one set by the
distribution. If there needed to be a different version for one of these
machines in the future, we could add it in to the machine.conf.

Signed-off-by: brian avery 
---
 meta-yocto-bsp/conf/machine/genericx86-64.conf | 2 --
 meta-yocto-bsp/conf/machine/genericx86.conf| 2 --
 2 files changed, 4 deletions(-)

diff --git a/meta-yocto-bsp/conf/machine/genericx86-64.conf 
b/meta-yocto-bsp/conf/machine/genericx86-64.conf
index bfedd84..12f7c0d 100644
--- a/meta-yocto-bsp/conf/machine/genericx86-64.conf
+++ b/meta-yocto-bsp/conf/machine/genericx86-64.conf
@@ -7,6 +7,4 @@ DEFAULTTUNE ?= "core2-64"
 require conf/machine/include/tune-core2.inc
 require conf/machine/include/genericx86-common.inc
 
-PREFERRED_VERSION_linux-yocto ?= "4.10%"
-
 SERIAL_CONSOLES_CHECK = "ttyS0"
diff --git a/meta-yocto-bsp/conf/machine/genericx86.conf 
b/meta-yocto-bsp/conf/machine/genericx86.conf
index af03b86..798b62ec 100644
--- a/meta-yocto-bsp/conf/machine/genericx86.conf
+++ b/meta-yocto-bsp/conf/machine/genericx86.conf
@@ -8,5 +8,3 @@ require conf/machine/include/tune-core2.inc
 require conf/machine/include/genericx86-common.inc
 
 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "gma500-gfx-check"
-
-PREFERRED_VERSION_linux-yocto ?= "4.10%"
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/2] remove qemu kernel version overrides and superfluous version settings

2017-07-21 Thread brian avery

Hi,

This removes the extra settings for the default kernel version so that you
can specify PREFERRED_VERSION_linux-yocto="X%" in your local.conf and it will
work for all the default MACHINES poky suports: qemu and hw boards both.

Without this patch, the hardware boards would have used version X but the qemu
machines would have used the default since they had machine specific overrides
in the poky distro conf.

-brian


The following changes since commit b38e8165330f76b422f4ad15aabcf93dd9458360:

  bison: reduce local pending patches (2017-07-21 11:12:44 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib bavery/mv_linux-yocto_into_machineconf
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=bavery/mv_linux-yocto_into_machineconf

brian avery (2):
  meta-yocto-bsp: Remove superfluous kernel set
  poky: Remove machine specific kernel overrides

 meta-poky/conf/distro/poky.conf| 10 ++
 meta-yocto-bsp/conf/machine/genericx86-64.conf |  2 --
 meta-yocto-bsp/conf/machine/genericx86.conf|  2 --
 3 files changed, 2 insertions(+), 12 deletions(-)

--
1.9.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] classes/machine-overrides-extended.bbclass: add

2017-07-21 Thread Denys Dmytriyenko

I haven't seen any conclusions on the Architecture list here:

http://lists.openembedded.org/pipermail/openembedded-architecture/2017-July/000662.html


On Fri, Jul 21, 2017 at 08:47:40AM -0400, Trevor Woerner wrote:
> Copy this class from meta-freescale so all BSPs can use it.
> 
> This class makes it easy for a BSP to specify multiple sets of configurations
> for a given MACHINE. In some cases there are multiple choices for the user.
> For example: for the kernel, the user could choose either the vendor kernel or
> the upstream kernel. However, sometimes these decisions are "locked" together:
> i.e. if you want to use the vendor's binary blob for (say) graphics, then
> you have to use their vendor kernel as well. It's not possible for a user to
> choose, say, the graphics binary blob but want to use the upstream kernel too.
> Therefore the BSP ends up with "sets" of configurations which need to be taken
> collectively instead of piecemeal.
> 
> In the example of meta-freescale, if the user does nothing special,
> they get the vendor options. If they add the following line to their
> configuration, they get the upstream pieces:
> 
>   MACHINEOVERRIDES .= ":use-mainline-bsp"
> 
> Signed-off-by: Trevor Woerner 
> ---
>  meta/classes/machine-overrides-extender.bbclass | 48 
> +
>  1 file changed, 48 insertions(+)
>  create mode 100644 meta/classes/machine-overrides-extender.bbclass
> 
> diff --git a/meta/classes/machine-overrides-extender.bbclass 
> b/meta/classes/machine-overrides-extender.bbclass
> new file mode 100644
> index 00..f333a0fcb7
> --- /dev/null
> +++ b/meta/classes/machine-overrides-extender.bbclass
> @@ -0,0 +1,48 @@
> +# -*- python -*-
> +# Automatically set extend the MACHINEOVERRIDES
> +#
> +# This allow to grouping of different settings for similar platforms.
> +#
> +# To indicate that a SoC contains following set of overrides, you can use:
> +#
> +# MACHINEOVERRIDES_EXTENDER_soc = "group1:group2"
> +#
> +# However to indicate that an override replaces a set of other
> +# overrides, you can use:
> +#
> +# MACHINEOVERRIDES_EXTENDER_FILTER_OUT_override = "group1 group2"
> +#
> +# Copyright 2016-2017 (C) O.S. Systems Software LTDA.
> +
> +def machine_overrides_extender(d):
> +machine_overrides = (d.getVar('MACHINEOVERRIDES', True) or '').split(':')
> +
> +# Gather the list of overrides to filter out
> +machine_overrides_filter_out = []
> +for override in machine_overrides:
> +machine_overrides_filter_out += 
> (d.getVar('MACHINEOVERRIDES_EXTENDER_FILTER_OUT_%s' % override, True) or 
> '').split()
> +
> +# Drop any overrides of filter_out prior extending
> +machine_overrides = [o for o in machine_overrides if o not in 
> machine_overrides_filter_out]
> +
> +for override in machine_overrides:
> +extender = d.getVar('MACHINEOVERRIDES_EXTENDER_%s' % override, True)
> +
> +if extender:
> +extender = extender.split(':')
> +
> +# Drop any extension if in filter_out
> +extender = [e for e in extender if e not in 
> machine_overrides_filter_out]
> +
> +extender.reverse()
> +if not set(extender).issubset(set(machine_overrides)):
> +index = machine_overrides.index(override)
> +for e in extender:
> +machine_overrides.insert(index, e)
> +d.setVar('MACHINEOVERRIDES', ':'.join(machine_overrides))
> +
> +python machine_overrides_extender_handler() {
> +machine_overrides_extender(e.data)
> +}
> +machine_overrides_extender_handler[eventmask] = "bb.event.ConfigParsed"
> +addhandler machine_overrides_extender_handler
> -- 
> 2.13.0
> 
> -- 
> ___
> 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

Re: [OE-core] [oe-core][PATCH 1/1] modules: move creation of some module related tools

2017-07-21 Thread Bruce Ashfield

On Fri, Jul 21, 2017 at 1:13 PM, Joe Slater  wrote:

> Move creation of tools needed by module building recipes into
> kernel.bbclass but invoke the task only from the module recipes.
> Without this change, one module recipe can fail trying to use the
> tools while another is (re-)building them.
>

You are changing some core code that has been protecting our builds for
quite some time .. yet, you have no example of the errors that are being
seen, and no proof that this actually fixes the problem (and that it doesn't
introduce other issues).

i.e. how are the lock files no protecting this in whatever is breaking for
you ?

Looking at the change, I'm not convinced it is the right thing to do.

i.e. putting something in kernel.bbclass that is only used by the modules
is less than ideal, without some sort of justification.

Bruce


>
> Signed-off-by: Joe Slater 
> ---
>  meta/classes/kernel.bbclass  | 15 +++
>  meta/classes/module-base.bbclass | 10 ++
>  meta/classes/module.bbclass  |  4 
>  3 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 7670c71..131387e 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -280,6 +280,11 @@ kernel_do_compile() {
>
>  do_compile_kernelmodules() {
> unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
> +
> +   # build modpost, etc
> +   make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> +  -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
> scripts
> +
> if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
> oe_runmake -C ${B} ${PARALLEL_MAKE} modules
> CC="${KERNEL_CC}" LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS}
>
> @@ -296,6 +301,16 @@ do_compile_kernelmodules() {
>  }
>  addtask compile_kernelmodules after do_compile before do_strip
>
> +# Task to ensure the kernel scripts are created. Expected to be invoked
> +# only by module building recipes. See module.bbclass for an example.
> +do_make_scripts() {
> +   unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> +   make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> +  -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
> scripts
> +}
> +addtask make_scripts after do_compile_kernelmodules
> +do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
> +
>  kernel_do_install() {
> #
> # First install the modules
> diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.
> bbclass
> index 6fe77c0..c1fe191 100644
> --- a/meta/classes/module-base.bbclass
> +++ b/meta/classes/module-base.bbclass
> @@ -1,7 +1,8 @@
>  inherit kernel-arch
>
>  # This is instead of DEPENDS = "virtual/kernel"
> -do_configure[depends] += "virtual/kernel:do_compile_kernelmodules"
> +# do_make_scripts() used to be in here, but is now in kernel.bbclass
> +do_configure[depends] += "virtual/kernel:do_make_scripts"
>
>  export OS = "${TARGET_OS}"
>  export CROSS_COMPILE = "${TARGET_PREFIX}"
> @@ -18,10 +19,3 @@ KERNEL_OBJECT_SUFFIX = ".ko"
>  # kernel modules are generally machine specific
>  PACKAGE_ARCH = "${MACHINE_ARCH}"
>
> -# Function to ensure the kernel scripts are created. Expected to
> -# be called before do_compile. See module.bbclass for an example.
> -do_make_scripts() {
> -   unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> -   make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> -  -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
> scripts
> -}
> diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
> index 391776d..e344960 100644
> --- a/meta/classes/module.bbclass
> +++ b/meta/classes/module.bbclass
> @@ -1,9 +1,5 @@
>  inherit module-base kernel-module-split pkgconfig
>
> -addtask make_scripts after do_prepare_recipe_sysroot before do_compile
> -do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
> -do_make_scripts[depends] += "virtual/kernel:do_shared_workdir"
> -
>  EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
>
>  MODULES_INSTALL_TARGET ?= "modules_install"
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH 1/1] modules: move creation of some module related tools

2017-07-21 Thread Joe Slater

Move creation of tools needed by module building recipes into
kernel.bbclass but invoke the task only from the module recipes.
Without this change, one module recipe can fail trying to use the
tools while another is (re-)building them.

Signed-off-by: Joe Slater 
---
 meta/classes/kernel.bbclass  | 15 +++
 meta/classes/module-base.bbclass | 10 ++
 meta/classes/module.bbclass  |  4 
 3 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 7670c71..131387e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -280,6 +280,11 @@ kernel_do_compile() {
 
 do_compile_kernelmodules() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
+
+   # build modpost, etc
+   make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
+  -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} scripts
+
if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
oe_runmake -C ${B} ${PARALLEL_MAKE} modules CC="${KERNEL_CC}" 
LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS}
 
@@ -296,6 +301,16 @@ do_compile_kernelmodules() {
 }
 addtask compile_kernelmodules after do_compile before do_strip
 
+# Task to ensure the kernel scripts are created. Expected to be invoked
+# only by module building recipes. See module.bbclass for an example.
+do_make_scripts() {
+   unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
+   make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
+  -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} scripts
+}
+addtask make_scripts after do_compile_kernelmodules
+do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
+
 kernel_do_install() {
#
# First install the modules
diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
index 6fe77c0..c1fe191 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -1,7 +1,8 @@
 inherit kernel-arch
 
 # This is instead of DEPENDS = "virtual/kernel"
-do_configure[depends] += "virtual/kernel:do_compile_kernelmodules"
+# do_make_scripts() used to be in here, but is now in kernel.bbclass
+do_configure[depends] += "virtual/kernel:do_make_scripts"
 
 export OS = "${TARGET_OS}"
 export CROSS_COMPILE = "${TARGET_PREFIX}"
@@ -18,10 +19,3 @@ KERNEL_OBJECT_SUFFIX = ".ko"
 # kernel modules are generally machine specific
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 
-# Function to ensure the kernel scripts are created. Expected to
-# be called before do_compile. See module.bbclass for an example.
-do_make_scripts() {
-   unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
-   make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
-  -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} scripts
-}
diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index 391776d..e344960 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -1,9 +1,5 @@
 inherit module-base kernel-module-split pkgconfig
 
-addtask make_scripts after do_prepare_recipe_sysroot before do_compile
-do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
-do_make_scripts[depends] += "virtual/kernel:do_shared_workdir"
-
 EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
 
 MODULES_INSTALL_TARGET ?= "modules_install"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv3 00/30] oeqa core and oe-selftest threaded enablement

2017-07-21 Thread Aníbal Limón



On 07/21/2017 03:11 AM, Richard Purdie wrote:
> On Mon, 2017-07-17 at 16:45 -0500, Aníbal Limón wrote:
>> This v3 makes changes on tinfoil busy status patch and adds an
>> environment variable to oe-seltest script to specify number of
>> threads. 
>> There are patches for bitbake [3] and meta-yocto-bsp [4] that was
>> send
>> to their specific ML.
>>
>> The first 6 patches previous enable support of threads in oeqa core
>> are independent and can be merged first.
>>
>> The v2 address comments did by Patrick about add better explanation
>> on the commit messages and some typos.
>>
>> Other interesting information to add is that with this series we will
>> able to execute oe-selftest in around half [1] of the original time
>> [2], (9406.782s vs 17303.014s).
> 
> I tested this, admittedly on top of the server rework changes and see
> some odd failures on the autobuilder. Things aren't looking very
> deterministic and I'm a little worried about merging them.
> 
> (e.g. https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/
> 397)
> 
> The second issue I'd like to ask questions about is whether the tinfoil
> changes and server rework we've just done remove the need for some of
> this patchset?

Yes if the tinfoil API can work within a thread we can remove the
functionality to run into the main thread, but the end_thread
functionality needs to stay because the devtool test content will need
to be modified to don't touch meta/ folder.

> 
> I ask since now I'm hoping the "main thread" issues might be resolved
> and we truly can have independent tinfoil connections. There were
> issues there but I believe Paul has resolved those.
> 
> For that reason I'm going to defer this patchset from M2 (I did take
> some of the initial patches) and ask that we review the patchset in
> light of the server rework and tinfoil changes that just merged.
> 
> I do know that for example, "oeqa/selftest/case: Support bitbake memres
> mode in per build director" is no obsolete as we removed the memres
> init script and the -t option to bitbake.

Ok, i understand, after merge the patches from Paul and you, i will
rebase and test again searching for remove has much code as i can.

Cheers,
Anibal

> 
> Cheers,
> 
> Richard
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libpcre: upgrade 8.40 -> 8.41

2017-07-21 Thread Andrej Valek

Signed-off-by: Andrej Valek 
---
 meta/recipes-support/libpcre/{libpcre_8.40.bb => libpcre_8.41.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/libpcre/{libpcre_8.40.bb => libpcre_8.41.bb} (95%)

diff --git a/meta/recipes-support/libpcre/libpcre_8.40.bb 
b/meta/recipes-support/libpcre/libpcre_8.41.bb
similarity index 95%
rename from meta/recipes-support/libpcre/libpcre_8.40.bb
rename to meta/recipes-support/libpcre/libpcre_8.41.bb
index 8563cd1..2f6d8c2 100644
--- a/meta/recipes-support/libpcre/libpcre_8.40.bb
+++ b/meta/recipes-support/libpcre/libpcre_8.41.bb
@@ -14,8 +14,8 @@ SRC_URI = "https://ftp.pcre.org/pub/pcre/pcre-${PV}.tar.bz2 \
file://Makefile \
 "
 
-SRC_URI[md5sum] = "41a842bf7dcecd6634219336e2167d1d"
-SRC_URI[sha256sum] = 
"00e27a29ead4267e3de8111fcaa59b132d0533cdfdbdddf4b0604279acbcf4f4"
+SRC_URI[md5sum] = "c160d22723b1670447341b08c58981c1"
+SRC_URI[sha256sum] = 
"e62c7eac5ae7c0e7286db61ff82912e1c0b7a0c13706616e94a7dd729321b530"
 
 S = "${WORKDIR}/pcre-${PV}"
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] expat: Upgrade to 2.2.2

2017-07-21 Thread Khem Raj

Signed-off-by: Khem Raj 
---
 meta/recipes-core/expat/expat.inc   |  1 +
 meta/recipes-core/expat/expat/libtool-tag.patch | 18 ++
 meta/recipes-core/expat/expat_2.2.1.bb  |  5 -
 meta/recipes-core/expat/expat_2.2.2.bb  |  4 
 4 files changed, 23 insertions(+), 5 deletions(-)
 create mode 100644 meta/recipes-core/expat/expat/libtool-tag.patch
 delete mode 100644 meta/recipes-core/expat/expat_2.2.1.bb
 create mode 100644 meta/recipes-core/expat/expat_2.2.2.bb

diff --git a/meta/recipes-core/expat/expat.inc 
b/meta/recipes-core/expat/expat.inc
index 9fa0ca2eb3..067687e44a 100644
--- a/meta/recipes-core/expat/expat.inc
+++ b/meta/recipes-core/expat/expat.inc
@@ -6,6 +6,7 @@ LICENSE = "MIT"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.bz2 \
file://autotools.patch \
+   file://libtool-tag.patch \
  "
 inherit autotools lib_package
 
diff --git a/meta/recipes-core/expat/expat/libtool-tag.patch 
b/meta/recipes-core/expat/expat/libtool-tag.patch
new file mode 100644
index 00..3ef4197ce5
--- /dev/null
+++ b/meta/recipes-core/expat/expat/libtool-tag.patch
@@ -0,0 +1,18 @@
+Add CC tag to build
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+
+Index: expat-2.2.2/Makefile.in
+===
+--- expat-2.2.2.orig/Makefile.in
 expat-2.2.2/Makefile.in
+@@ -109,7 +109,7 @@ mkdir-init:
+ 
+ CC = @CC@
+ CXX = @CXX@
+-LIBTOOL = @LIBTOOL@
++LIBTOOL = @LIBTOOL@ --tag CC
+ 
+ INCLUDES = -I$(srcdir)/lib -I.
+ LDFLAGS = @LDFLAGS@
diff --git a/meta/recipes-core/expat/expat_2.2.1.bb 
b/meta/recipes-core/expat/expat_2.2.1.bb
deleted file mode 100644
index 47827c5576..00
--- a/meta/recipes-core/expat/expat_2.2.1.bb
+++ /dev/null
@@ -1,5 +0,0 @@
-require expat.inc
-LIC_FILES_CHKSUM = "file://COPYING;md5=5b8620d98e49772d95fc1d291c26aa79"
-
-SRC_URI[md5sum] = "d9c3baeab58774cefc2f04faf29f2cf8"
-SRC_URI[sha256sum] = 
"1868cadae4c82a018e361e2b2091de103cd820aaacb0d6cfa49bd2cd83978885"
diff --git a/meta/recipes-core/expat/expat_2.2.2.bb 
b/meta/recipes-core/expat/expat_2.2.2.bb
new file mode 100644
index 00..0e135d70df
--- /dev/null
+++ b/meta/recipes-core/expat/expat_2.2.2.bb
@@ -0,0 +1,4 @@
+require expat.inc
+LIC_FILES_CHKSUM = "file://COPYING;md5=5b8620d98e49772d95fc1d291c26aa79"
+SRC_URI[md5sum] = "1ede9a41223c78528b8c5d23e69a2667"
+SRC_URI[sha256sum] = 
"4376911fcf81a23ebd821bbabc26fd933f3ac74833f74924342c29aad2c86046"
-- 
2.13.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv2 1/4] recipetool: create: disable PREMIRRORS and MIRRORS by default

2017-07-21 Thread Burton, Ross

Sorry, we're conflicting again.  Too many people working on the same bit of
code!  Can you rebase this onto origin/master-next?

Ross

On 20 July 2017 at 11:31, Chang Rebecca Swee Fun <
rebecca.swee.fun.ch...@intel.com> wrote:

> When creating new recipes, we are almost certainly fetching a new
> source rather that something that has already been fetched. I have
> disable PREMIRRORS and MIRRORS settings from datastore while leaving
> an option for users to enable them manually if needed.
>
> Signed-off-by: Chang Rebecca Swee Fun 
> ---
>  scripts/lib/recipetool/create.py | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/
> create.py
> index 8e63580..1015d02 100644
> --- a/scripts/lib/recipetool/create.py
> +++ b/scripts/lib/recipetool/create.py
> @@ -422,6 +422,7 @@ def create_recipe(args):
>  source = args.source
>  srcsubdir = ''
>  srcrev = '${AUTOREV}'
> +mirrors = args.mirrors
>
>  if os.path.isfile(source):
>  source = 'file://%s' % os.path.abspath(source)
> @@ -442,6 +443,13 @@ def create_recipe(args):
>  tempsrc = tempfile.mkdtemp(prefix='recipetool-')
>  srctree = tempsrc
>  d = bb.data.createCopy(tinfoil.config_data)
> +if not mirrors:
> +# We do not need PREMIRRORS since we are almost certainly
> +# fetching new source rather than something that has already
> +# been fetched. Hence, we disable them by default.
> +# However, we provide an option for users to enable it.
> +d.setVar('PREMIRRORS', '')
> +d.setVar('MIRRORS', '')
>  if fetchuri.startswith('npm://'):
>  # Check if npm is available
>  npm_bindir = check_npm(tinfoil, args.devtool)
> @@ -1180,6 +1188,7 @@ def register_commands(subparsers):
>  parser_create.add_argument('--keep-temp', action="store_true",
> help='Keep temporary directory (for debugging)')
>  parser_create.add_argument('--fetch-dev', action="store_true",
> help='For npm, also fetch devDependencies')
>  parser_create.add_argument('--devtool', action="store_true",
> help=argparse.SUPPRESS)
> +parser_create.add_argument('--mirrors', action="store_true",
> help='Enable PREMIRRORS and MIRRORS for source tree fetching (disable by
> default).')
>  # FIXME I really hate having to set parserecipes for this, but given
> we may need
>  # to call into npm (and we don't know in advance if we will or not)
> and in order
>  # to do so we need to know npm's recipe sysroot path, there's not
> much alternative
> --
> 2.7.4
>
> --
> ___
> 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

Re: [OE-core] [PATCH] meta: fix bfd "cannot make copy relocation for protected symbol" issues

2017-07-21 Thread Burton, Ross

On 20 July 2017 at 10:52,  wrote:

> +++ b/meta/classes/bfd-binding-now.bbclass
> @@ -0,0 +1,4 @@
> +# Workaround for some ARCHs do not support bfd lazy binding well
> +# Refer to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11679
> +
> +TARGET_LDFLAGS_append = "${@bb.utils.contains('DISTRO_FEATURES',
> 'ld-is-gold', ' -Wl,-z,relro,-z,now -fuse-ld=bfd ', '', d)}"
>

This is pretty ugly.

Does this tell us that maybe gold should be considered opt-in on a
per-recipe basis instead of used by default?

Can you instead have a .inc file which fiddles the flag for all the recipes
from outside the recipes? See eg security_flags.inc.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] image-vm: Convert vmdk/vdi/qcow2/hdddirect images to IMAGE_CMD

2017-07-21 Thread Patrick Ohly

On Fri, 2017-07-21 at 07:21 -0400, Tom Rini wrote:
> On Fri, Jul 21, 2017 at 09:47:21AM +0200, Patrick Ohly wrote:
> > On Thu, 2017-07-20 at 18:43 -0400, Tom Rini wrote:
> > > The support for writing vmdk/vdi/qcow2 images has not been converted to 
> > > make
> > > use of the IMAGE_CMD infrastructure and instead relies on custom logic for
> > > adding tasks in the right place.  Convert these images to making use of
> > > IMAGE_CMD.
> > 
> > Thanks for working on this. I still have
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10204 open for
> > enhancing vmdk/vdi/qcow2.
> > 
> > However, your patch doesn't go as far as described in that bug, does it?
> > Instead of allowing, for example, IMAGE_FSTYPES = "wic.vmdk", it merely
> > changes how IMAGE_FSTYPES = "vmdk" is implemented.
> > 
> > The current patch has its merits as it simplifies the implementation,
> > but I think it would be worthwhile to go all the way, even if it changes
> > how images are going to be named.
> 
> Ah, interesting.  I guess the first thing I would argue against is
> saying that hdddirect should be masked.  There are reasons to want to
> have a raw image created.

I'm not sure I understand what you mean with "hdddirect should be
masked" - it's been a while that I looked at the code.

> I will take a look into using CONVERSIONCMD for vmdk/qcow2/vdi to allow
> for wic.vmdk to work.  But we also must have vmdk.xz work (and fwiw with
> my series you can get arbitrary compression that we support done, I did
> vmdk.xz, qcow2.lzo and vdi.bz2 just for 'fun').

The same is true with CONVERSIONCMD. They can be chained multiple times.

> But I'm not 100% sure that I like changing the normal case from "vmdk"
> to "wic.vmdk" or "hdddirect.vmdk" just to get a disk image to throw at
> ${VM_TECHNOLOGY}.

Yes, that's the biggest user-visible change. Basically the internal
implementation (multiple conversions chained together) becomes visible
in the end-result.

That is a good and a bad thing. The good thing is that it is visible how
the .vmdk image was created. The bad thing is that some users might not
care and get confused.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] mesa: Upgrade to 17.1.5 release

2017-07-21 Thread Burton, Ross

On 20 July 2017 at 22:34, Burton, Ross  wrote:

> I'll bisect that tomorrow...
>

Richard discovered that this is due to enabling Vulkan, so that change has
been dropped from meta-poky.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] classes/machine-overrides-extended.bbclass: add

2017-07-21 Thread Trevor Woerner

Copy this class from meta-freescale so all BSPs can use it.

This class makes it easy for a BSP to specify multiple sets of configurations
for a given MACHINE. In some cases there are multiple choices for the user.
For example: for the kernel, the user could choose either the vendor kernel or
the upstream kernel. However, sometimes these decisions are "locked" together:
i.e. if you want to use the vendor's binary blob for (say) graphics, then
you have to use their vendor kernel as well. It's not possible for a user to
choose, say, the graphics binary blob but want to use the upstream kernel too.
Therefore the BSP ends up with "sets" of configurations which need to be taken
collectively instead of piecemeal.

In the example of meta-freescale, if the user does nothing special,
they get the vendor options. If they add the following line to their
configuration, they get the upstream pieces:

MACHINEOVERRIDES .= ":use-mainline-bsp"

Signed-off-by: Trevor Woerner 
---
 meta/classes/machine-overrides-extender.bbclass | 48 +
 1 file changed, 48 insertions(+)
 create mode 100644 meta/classes/machine-overrides-extender.bbclass

diff --git a/meta/classes/machine-overrides-extender.bbclass 
b/meta/classes/machine-overrides-extender.bbclass
new file mode 100644
index 00..f333a0fcb7
--- /dev/null
+++ b/meta/classes/machine-overrides-extender.bbclass
@@ -0,0 +1,48 @@
+# -*- python -*-
+# Automatically set extend the MACHINEOVERRIDES
+#
+# This allow to grouping of different settings for similar platforms.
+#
+# To indicate that a SoC contains following set of overrides, you can use:
+#
+# MACHINEOVERRIDES_EXTENDER_soc = "group1:group2"
+#
+# However to indicate that an override replaces a set of other
+# overrides, you can use:
+#
+# MACHINEOVERRIDES_EXTENDER_FILTER_OUT_override = "group1 group2"
+#
+# Copyright 2016-2017 (C) O.S. Systems Software LTDA.
+
+def machine_overrides_extender(d):
+machine_overrides = (d.getVar('MACHINEOVERRIDES', True) or '').split(':')
+
+# Gather the list of overrides to filter out
+machine_overrides_filter_out = []
+for override in machine_overrides:
+machine_overrides_filter_out += 
(d.getVar('MACHINEOVERRIDES_EXTENDER_FILTER_OUT_%s' % override, True) or 
'').split()
+
+# Drop any overrides of filter_out prior extending
+machine_overrides = [o for o in machine_overrides if o not in 
machine_overrides_filter_out]
+
+for override in machine_overrides:
+extender = d.getVar('MACHINEOVERRIDES_EXTENDER_%s' % override, True)
+
+if extender:
+extender = extender.split(':')
+
+# Drop any extension if in filter_out
+extender = [e for e in extender if e not in 
machine_overrides_filter_out]
+
+extender.reverse()
+if not set(extender).issubset(set(machine_overrides)):
+index = machine_overrides.index(override)
+for e in extender:
+machine_overrides.insert(index, e)
+d.setVar('MACHINEOVERRIDES', ':'.join(machine_overrides))
+
+python machine_overrides_extender_handler() {
+machine_overrides_extender(e.data)
+}
+machine_overrides_extender_handler[eventmask] = "bb.event.ConfigParsed"
+addhandler machine_overrides_extender_handler
-- 
2.13.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC PATCH 0/5] revive runtime/cases/_ptest.py

2017-07-21 Thread Richard Purdie

On Thu, 2017-07-20 at 10:09 +0800, Robert Yang wrote:
> 
> On 07/19/2017 04:16 PM, Robert Yang wrote:
> > 
> > Hello,
> > 
> > These patches can make ptest test case work, RP has suggested we
> > write a tool to
> > do the regression check on ptest result, I think that the use case
> > is like:
> > 
> > $ bitbake  -ctestiamge # Suppose we add ptest to default
> > test cases in the future
> > # Upgrade a recipe form V1.0 to V1.1
> > $ bitbake  -ctestiamge # Run the test again
> > 
> > Then the regression check tool can report what's different (passed,
> > failed,
> > skipped) between V1.0 and V1.1.
> > 
> > Currently, I'm not sure about where to save the ptest results, I
> > saved it to
> > ${WORKDIR}/testimage/ptest_log atm, e.g.:
> > tmp/work/qemux86-poky-linux/core-image-minimal/1.0-
> > r0/testimage/ptest_log
> I still have to think about more about where to put the test result.

Would buildhistory make sense for these since we already have a
mechanism to store results there between builds?

> > But it will be removed after -cclean, then no regression check can
> > be made, so
> > I'd like to save the ptest results to DEPLOY_DIR_IMAGE if no
> > objections, and
> > make -cclean not remove them. (Or only keep the latest 2 results).
> > 
> > And I'm not sure where to add the regression check/tool, maybe one
> > of:
> > 1) Add a separate tool in oe-core/scripts, this can make it easy to
> > do regression
> >    check among different build directories, and
> > runtime/cases/_ptest.py can invoke it.
> I'm leaning to add a script called ptest-regression-check which is
> more flexible, the cases/ptest.py or buildhistory (also the user) can
> run it when needed.

I'd either add a script, or perhaps an option to the buildhistory-diff? 
Paul might have some adivce on that. I would like to understand if
there is a good reason we can't use buildhistory to at least help with
some of this?

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] patchelf: change patch status

2017-07-21 Thread Ed Bartosh

The patch has been accepted upstream.
Changed patch status Pending -> Accepted.

Signed-off-by: Ed Bartosh 
---
 meta/recipes-devtools/patchelf/patchelf/avoidholes.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch 
b/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch
index a273688..0b45c39 100644
--- a/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch
+++ b/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch
@@ -31,7 +31,7 @@ was good, the implementation wasn't correct and they've been 
rewritten here.
 RP
 2017/3/7
 
-Upstream-Status: Pending
+Upstream-Status: Accepted
 
 Index: patchelf-0.9/src/patchelf.cc
 ===
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] patchelf: fix segfault for binaries linked by gold

2017-07-21 Thread Ed Bartosh

Due to a bug in calculating adresses of modified program
headers patchelf breaks executables linked by Gold linker
causing them to segfault, e.g.
$ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help
Segmentation fault

This is reproducible only in some cases and only for executables
of ET_DYN type produced by Gold or by ld linked with pie.

This should be solved by fix-adjusting-startPage.patch that
fixes calculation logic.

[YOCTO #11785]

Signed-off-by: Ed Bartosh 
---
 .../patchelf/fix-adjusting-startPage.patch | 38 ++
 meta/recipes-devtools/patchelf/patchelf_0.9.bb |  1 +
 2 files changed, 39 insertions(+)
 create mode 100644 
meta/recipes-devtools/patchelf/patchelf/fix-adjusting-startPage.patch

diff --git 
a/meta/recipes-devtools/patchelf/patchelf/fix-adjusting-startPage.patch 
b/meta/recipes-devtools/patchelf/patchelf/fix-adjusting-startPage.patch
new file mode 100644
index 000..f64cbed
--- /dev/null
+++ b/meta/recipes-devtools/patchelf/patchelf/fix-adjusting-startPage.patch
@@ -0,0 +1,38 @@
+commit 1cc234fea5600190d872329aca60e2365cefc39e
+Author: Ed Bartosh 
+Date:   Fri Jul 21 12:33:53 2017 +0300
+
+fix adjusting startPage
+
+startPage is adjusted unconditionally for all executables.
+This results in incorrect addresses assigned to INTERP and LOAD
+program headers, which breaks patched executable.
+
+Adjusting startPage variable only when startOffset > startPage
+should fix this.
+
+This change is related to the issue NixOS#10
+
+Signed-off-by: Ed Bartosh 
+
+Github PR: https://github.com/NixOS/patchelf/pull/127
+
+Upstream-Status: Submitted
+
+diff --git a/src/patchelf.cc b/src/patchelf.cc
+index cbd36c0..e9d7ea5 100644
+--- a/src/patchelf.cc
 b/src/patchelf.cc
+@@ -720,10 +720,8 @@ void ElfFile::rewriteSectionsLibrary()
+since DYN executables tend to start at virtual address 0, so
+rewriteSectionsExecutable() won't work because it doesn't have
+any virtual address space to grow downwards into. */
+-if (isExecutable) {
+-if (startOffset >= startPage) {
+-debug("shifting new PT_LOAD segment by %d bytes to work around a 
Linux kernel bug\n", startOffset - startPage);
+-}
++if (isExecutable && startOffset > startPage) {
++debug("shifting new PT_LOAD segment by %d bytes to work around a 
Linux kernel bug\n", startOffset - startPage);
+ startPage = startOffset;
+ }
+ 
diff --git a/meta/recipes-devtools/patchelf/patchelf_0.9.bb 
b/meta/recipes-devtools/patchelf/patchelf_0.9.bb
index 01f0e62..d703039 100644
--- a/meta/recipes-devtools/patchelf/patchelf_0.9.bb
+++ b/meta/recipes-devtools/patchelf/patchelf_0.9.bb
@@ -3,6 +3,7 @@ SRC_URI = 
"http://nixos.org/releases/${BPN}/${BPN}-${PV}/${BPN}-${PV}.tar.bz2 \
file://handle-read-only-files.patch \
file://Increase-maxSize-to-64MB.patch \
file://avoidholes.patch \
+   file://fix-adjusting-startPage.patch \
 "
 
 LICENSE = "GPLv3"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] webkitgtk: Upgrade to 2.16.5

2017-07-21 Thread Alexander Kanavin


On 07/13/2017 03:49 PM, Carlos Alberto Lopez Perez wrote:

Adjust some dependencies: libgcrypt is now required (instead of gnutls)
and the following build deps where missing: gettext-native, glib-2.0
and glib-2.0-native.

Also the CMake argument ENABLE_CREDENTIAL_STORAGE has been renamed to
USE_LIBSECRET.

This new upstream release (2.16.4 actually) includes security fixes for
CVE: CVE-2017-2538


Carlos, may I ask that you submit the 'Pending' patches in webkit recipe 
upstream? I have no experience working with them, so maybe it's faster 
and easier that way.


We're trying to reduce the amount of such patches in oe-core in general.

Thanks,
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] bind: 9.10..3-P3 -> 9.10.5-P3

2017-07-21 Thread Alexander Kanavin


On 07/21/2017 09:37 AM, Kang Kai wrote:

It doesn't  mention that api changes in 9.11 from release notes pages of 
9.11.0rc1 and 9.11.0.


https://kb.isc.org/article/AA-01409
https://kb.isc.org/article/AA-01432/81/BIND-9.11.0-Release-Notes.html


But it suggests not to use 9.11 until the second maintenance 
release(9.11.2 if I understand correctly) for production systems:


| We recommend that administrators run one of our older, stable 
branches, such as a 9.9 or 9.10-based release on larger-scale critical 
production systems, while testing the new 9.11 branch until the second 
maintenance release.


https://www.isc.org/downloads/bind/bind-9-11-new-features/


Fair enough, let's stick with 9.10 for now then.

Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] image-vm: Convert vmdk/vdi/qcow2/hdddirect images to IMAGE_CMD

2017-07-21 Thread Tom Rini

On Fri, Jul 21, 2017 at 09:47:21AM +0200, Patrick Ohly wrote:
> On Thu, 2017-07-20 at 18:43 -0400, Tom Rini wrote:
> > The support for writing vmdk/vdi/qcow2 images has not been converted to make
> > use of the IMAGE_CMD infrastructure and instead relies on custom logic for
> > adding tasks in the right place.  Convert these images to making use of
> > IMAGE_CMD.
> 
> Thanks for working on this. I still have
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10204 open for
> enhancing vmdk/vdi/qcow2.
> 
> However, your patch doesn't go as far as described in that bug, does it?
> Instead of allowing, for example, IMAGE_FSTYPES = "wic.vmdk", it merely
> changes how IMAGE_FSTYPES = "vmdk" is implemented.
> 
> The current patch has its merits as it simplifies the implementation,
> but I think it would be worthwhile to go all the way, even if it changes
> how images are going to be named.

Ah, interesting.  I guess the first thing I would argue against is
saying that hdddirect should be masked.  There are reasons to want to
have a raw image created.

I will take a look into using CONVERSIONCMD for vmdk/qcow2/vdi to allow
for wic.vmdk to work.  But we also must have vmdk.xz work (and fwiw with
my series you can get arbitrary compression that we support done, I did
vmdk.xz, qcow2.lzo and vdi.bz2 just for 'fun').

But I'm not 100% sure that I like changing the normal case from "vmdk"
to "wic.vmdk" or "hdddirect.vmdk" just to get a disk image to throw at
${VM_TECHNOLOGY}.

-- 
Tom

signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] patchelf: fix segfault for binaries linked by gold

2017-07-21 Thread Ed Bartosh

Due to a bug in calculating adresses of modified program
headers patchelf breaks executables linked by Gold linker
causing them to segfault, e.g.
$ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help
Segmentation fault

This is reproducible only in some cases and only for executables
of ET_DYN type produced by Gold or by ld linked with pie.

This should be solved by fix-adjusting-startPage.patch that
fixes calculation logic.

[YOCTO #11785]

Signed-off-by: Ed Bartosh 
---
 .../patchelf/fix-adjusting-startPage.patch | 38 ++
 meta/recipes-devtools/patchelf/patchelf_0.9.bb |  1 +
 2 files changed, 39 insertions(+)
 create mode 100644 
meta/recipes-devtools/patchelf/patchelf/fix-adjusting-startPage.patch

diff --git 
a/meta/recipes-devtools/patchelf/patchelf/fix-adjusting-startPage.patch 
b/meta/recipes-devtools/patchelf/patchelf/fix-adjusting-startPage.patch
new file mode 100644
index 000..0e4544f
--- /dev/null
+++ b/meta/recipes-devtools/patchelf/patchelf/fix-adjusting-startPage.patch
@@ -0,0 +1,38 @@
+commit 1cc234fea5600190d872329aca60e2365cefc39e
+Author: Ed Bartosh 
+Date:   Fri Jul 21 12:33:53 2017 +0300
+
+fix adjusting startPage
+
+startPage is adjusted unconditionally for all executables.
+This results in incorrect addresses assigned to INTERP and LOAD
+program headers, which breaks patched executable.
+
+Adjusting startPage variable only when startOffset > startPage
+should fix this.
+
+This change is related to the issue NixOS#10
+
+Signed-off-by: Ed Bartosh 
+
+Github PR: https://github.com/NixOS/patchelf/pull/127
+
+Upstream-Status: Pending
+
+diff --git a/src/patchelf.cc b/src/patchelf.cc
+index cbd36c0..e9d7ea5 100644
+--- a/src/patchelf.cc
 b/src/patchelf.cc
+@@ -720,10 +720,8 @@ void ElfFile::rewriteSectionsLibrary()
+since DYN executables tend to start at virtual address 0, so
+rewriteSectionsExecutable() won't work because it doesn't have
+any virtual address space to grow downwards into. */
+-if (isExecutable) {
+-if (startOffset >= startPage) {
+-debug("shifting new PT_LOAD segment by %d bytes to work around a 
Linux kernel bug\n", startOffset - startPage);
+-}
++if (isExecutable && startOffset > startPage) {
++debug("shifting new PT_LOAD segment by %d bytes to work around a 
Linux kernel bug\n", startOffset - startPage);
+ startPage = startOffset;
+ }
+ 
diff --git a/meta/recipes-devtools/patchelf/patchelf_0.9.bb 
b/meta/recipes-devtools/patchelf/patchelf_0.9.bb
index 01f0e62..d703039 100644
--- a/meta/recipes-devtools/patchelf/patchelf_0.9.bb
+++ b/meta/recipes-devtools/patchelf/patchelf_0.9.bb
@@ -3,6 +3,7 @@ SRC_URI = 
"http://nixos.org/releases/${BPN}/${BPN}-${PV}/${BPN}-${PV}.tar.bz2 \
file://handle-read-only-files.patch \
file://Increase-maxSize-to-64MB.patch \
file://avoidholes.patch \
+   file://fix-adjusting-startPage.patch \
 "
 
 LICENSE = "GPLv3"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] bluez5: update patch status

2017-07-21 Thread Maxin B. John

Update the status of following patch from Pending to Accepted:
a) 0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch

Signed-off-by: Maxin B. John 
---
 .../0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
 
b/meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
index 7bd5bbc..4679438 100644
--- 
a/meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
+++ 
b/meta/recipes-connectivity/bluez5/bluez5/0001-hciattach-bcm43xx-fix-the-delay-timer-for-firmware-d.patch
@@ -9,7 +9,7 @@ From the log in .bcm43xx_load_firmware():
 
 But timespec tm_mode is real is 50us. Correct the delayed timer count.
 
-Upstream-Status: Pending
+Upstream-Status: Accepted 
[https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=76255f732d68aef2b90d36d9c7be51a9e1739ce7]
 
 Signed-off-by: Fugang Duan 
 ---
-- 
2.4.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv3 00/30] oeqa core and oe-selftest threaded enablement

2017-07-21 Thread Richard Purdie

On Mon, 2017-07-17 at 16:45 -0500, Aníbal Limón wrote:
> This v3 makes changes on tinfoil busy status patch and adds an
> environment variable to oe-seltest script to specify number of
> threads. 
> There are patches for bitbake [3] and meta-yocto-bsp [4] that was
> send
> to their specific ML.
> 
> The first 6 patches previous enable support of threads in oeqa core
> are independent and can be merged first.
> 
> The v2 address comments did by Patrick about add better explanation
> on the commit messages and some typos.
> 
> Other interesting information to add is that with this series we will
> able to execute oe-selftest in around half [1] of the original time
> [2], (9406.782s vs 17303.014s).

I tested this, admittedly on top of the server rework changes and see
some odd failures on the autobuilder. Things aren't looking very
deterministic and I'm a little worried about merging them.

(e.g. https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/
397)

The second issue I'd like to ask questions about is whether the tinfoil
changes and server rework we've just done remove the need for some of
this patchset?

I ask since now I'm hoping the "main thread" issues might be resolved
and we truly can have independent tinfoil connections. There were
issues there but I believe Paul has resolved those.

For that reason I'm going to defer this patchset from M2 (I did take
some of the initial patches) and ask that we review the patchset in
light of the server rework and tinfoil changes that just merged.

I do know that for example, "oeqa/selftest/case: Support bitbake memres
mode in per build director" is no obsolete as we removed the memres
init script and the -t option to bitbake.

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv3] vulkan-demos: Add recipe

2017-07-21 Thread Jussi Kukkonen

On 20 July 2017 at 12:01, Kang Kai  wrote:

> On 2017年07月11日 20:26, Jussi Kukkonen wrote:
>
>> Sascha Willems collection of Vulkan demos is useful as a smoke testing
>> tool.
>>
>> * Add patch to install binaries and data.
>> * Add patch to fix build on X86
>> * Use a combination of patch and do_install_append to avoid some 3D
>> models with unclear licensing.
>>
>> Signed-off-by: Jussi Kukkonen 
>>
>
> Hi Jussi,
>
> Did you meet build failure:
>
> | CMake Error at /buildarea3/kkang/WRLX/builds/
> vulkan-amr64/tmp/work/aarch64-wrs-linux/vulkan-demos/git-r0/
> recipe-sysroot-native/usr/share/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:137
> (message):
> |   Could NOT find ASSIMP (missing: ASSIMP_LIBRARIES)
> | Call Stack (most recent call first):
> | /buildarea3/kkang/WRLX/builds/vulkan-amr64/tmp/work/aarch64-
> wrs-linux/vulkan-demos/git-r0/recipe-sysroot-native/usr/shar
> e/cmake-3.8/Modules/FindPackageHandleStandardArgs.cmake:377
> (_FPHSA_FAILURE_MESSAGE)
> |   cmake/FindASSIMP.cmake:50 (find_package_handle_standard_args)
> |   CMakeLists.txt:45 (find_package)
>
> If not, would you please to tell me where or which recipe is module ASSIMP
> from?
>

No, I did not see this. The assimp library comes from assimp_git.bb recipe
in the same directory as vulkan-demos recipe -- it is in DEPENDS for
vulkan-demos.

Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] image-vm: Convert vmdk/vdi/qcow2/hdddirect images to IMAGE_CMD

2017-07-21 Thread Patrick Ohly

On Thu, 2017-07-20 at 18:43 -0400, Tom Rini wrote:
> The support for writing vmdk/vdi/qcow2 images has not been converted to make
> use of the IMAGE_CMD infrastructure and instead relies on custom logic for
> adding tasks in the right place.  Convert these images to making use of
> IMAGE_CMD.

Thanks for working on this. I still have
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10204 open for
enhancing vmdk/vdi/qcow2.

However, your patch doesn't go as far as described in that bug, does it?
Instead of allowing, for example, IMAGE_FSTYPES = "wic.vmdk", it merely
changes how IMAGE_FSTYPES = "vmdk" is implemented.

The current patch has its merits as it simplifies the implementation,
but I think it would be worthwhile to go all the way, even if it changes
how images are going to be named.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/1] bind: 9.10..3-P3 -> 9.10.5-P3

2017-07-21 Thread Kang Kai


On 2017年07月19日 21:05, Alexander Kanavin wrote:

On 07/19/2017 12:08 AM, Khem Raj wrote:

The policy in oe-core master is to update to latest stable upstream
releases, so please provide an update to 9.11.x. If you want to keep 
9.10.x,

you can do that, but please provide a more specific reason.


if there are ABI incompatible changes then we have to scope the impact
and plan the upgrade accordingly, if its backward compatible then yes 
its

the norm.


It doesn't  mention that api changes in 9.11 from release notes pages of 
9.11.0rc1 and 9.11.0.


https://kb.isc.org/article/AA-01409
https://kb.isc.org/article/AA-01432/81/BIND-9.11.0-Release-Notes.html


But it suggests not to use 9.11 until the second maintenance 
release(9.11.2 if I understand correctly) for production systems:


| We recommend that administrators run one of our older, stable 
branches, such as a 9.9 or 9.10-based release on larger-scale critical 
production systems, while testing the new 9.11 branch until the second 
maintenance release.


https://www.isc.org/downloads/bind/bind-9-11-new-features/


--Kai



What I'm saying is that it should not be a "9.10 now, 9.11 maybe 
later" when working with a master branch. The proper way is to 
"investigate and plan the upgrade to 9.11, update to 9.10 only if 
necessary, based on that investigation".



Alex



--
Regards,
Neil | Kai Kang

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for subversion: Upgrade 1.9.5-> 1.9.6

2017-07-21 Thread Patchwork

== Series Details ==

Series: subversion: Upgrade 1.9.5-> 1.9.6
Revision: 1
URL   : https://patchwork.openembedded.org/series/7850/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series cannot be parsed correctly due to malformed diff 
lines [test_mbox_format] 
  Suggested fixCreate the series again using git-format-patch and ensure it 
can be applied using git am
  Diff line diff --git 
a/meta/recipes-devtools/subversion/subversion_1.9.6.bb 
b/meta/recipes-devtools/subversion/subversion_1.9.6.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 c4c2fb3732)



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] -> ...).

---
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] ovmf-shell-image.bb: simplify dependencies

2017-07-21 Thread Patrick Ohly

The image consists only of the EFI system partition, therefore
we can avoid depending on the default wic tools.

Signed-off-by: Patrick Ohly 
---
 meta/recipes-core/ovmf/ovmf-shell-image.bb | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/ovmf/ovmf-shell-image.bb 
b/meta/recipes-core/ovmf/ovmf-shell-image.bb
index 029547b..0d2b8bf 100644
--- a/meta/recipes-core/ovmf/ovmf-shell-image.bb
+++ b/meta/recipes-core/ovmf/ovmf-shell-image.bb
@@ -1,10 +1,13 @@
 DESCRIPTION = "boot image with UEFI shell and tools"
 
 # For this image recipe, only the wic format with a
-# single vfat partition makes sense.
+# single vfat partition makes sense. Because we have no
+# boot loader and no rootfs partition, not additional
+# tools are needed for this .wks file.
 IMAGE_FSTYPES_forcevariable = 'wic'
-
 WKS_FILE = "ovmf/ovmf-shell-image.wks"
+WKS_FILE_DEPENDS = ""
+
 inherit image
 
 # We want a minimal image with just ovmf-shell-efi unpacked in it. We

base-commit: c4c2fb3732dbb290b7f0ca43af2e8662f99e4582
-- 
git-series 0.9.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] subversion: Upgrade 1.9.5-> 1.9.6

2017-07-21 Thread Richard Purdie

Signed-off-by: Richard Purdie 
---
 .../subversion/subversion_1.9.5.bb | 55 --
 .../subversion/subversion_1.9.6.bb | 55 ++
 2 files changed, 55 insertions(+), 55 deletions(-)
 delete mode 100644 meta/recipes-devtools/subversion/subversion_1.9.5.bb
 create mode 100644 meta/recipes-devtools/subversion/subversion_1.9.6.bb

diff --git a/meta/recipes-devtools/subversion/subversion_1.9.5.bb 
b/meta/recipes-devtools/subversion/subversion_1.9.5.bb
deleted file mode 100644
index 05fba67..000
--- a/meta/recipes-devtools/subversion/subversion_1.9.5.bb
+++ /dev/null
@@ -1,55 +0,0 @@
-SUMMARY = "Subversion (svn) version control system client"
-SECTION = "console/network"
-DEPENDS = "apr-util serf sqlite3 file"
-DEPENDS_append_class-native = " file-replacement-native"
-RDEPENDS_${PN} = "serf"
-LICENSE = "Apache-2"
-HOMEPAGE = "http://subversion.tigris.org;
-
-BBCLASSEXTEND = "native"
-
-inherit gettext
-
-SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
-   file://disable_macos.patch \
-   file://serf.m4-Regex-modified-to-allow-D-in-paths.patch \
-   file://0001-Fix-libtool-name-in-configure.ac.patch \
-   file://serfmacro.patch \
-   "
-
-SRC_URI[md5sum] = "9fcbae352a5efe73d46a88c97c6bba14"
-SRC_URI[sha256sum] = 
"8a4fc68aff1d18dcb4dd9e460648d24d9e98657fbed496c582929c6b3ce555e5"
-
-LIC_FILES_CHKSUM = "file://LICENSE;md5=af81ae49ba359e70626c05e9bf313709"
-
-PACKAGECONFIG[sasl] = "--with-sasl,--without-sasl,cyrus-sasl"
-PACKAGECONFIG[gnome-keyring] = 
"--with-gnome-keyring,--without-gnome-keyring,glib-2.0 gnome-keyring"
-
-EXTRA_OECONF = " \
---without-berkeley-db --without-apxs \
---without-swig --with-apr=${STAGING_BINDIR_CROSS} \
---with-apr-util=${STAGING_BINDIR_CROSS} \
---disable-keychain \
-ac_cv_path_RUBY=none"
-
-inherit autotools
-
-export LDFLAGS += " -L${STAGING_LIBDIR} "
-CPPFLAGS += "-P"
-BUILD_CPPFLAGS += "-P"
-
-acpaths = "-I build/ -I build/ac-macros/"
-
-do_configure_prepend () {
-   rm -f ${S}/libtool
-   rm -f ${S}/build/libtool.m4 ${S}/build/ltmain.sh 
${S}/build/ltoptions.m4 ${S}/build/ltsugar.m4 ${S}/build/ltversion.m4 
${S}/build/lt~obsolete.m4
-   rm -f ${S}/aclocal.m4
-   sed -i -e 's:with_sasl="/usr/local":with_sasl="${STAGING_DIR}":' 
${S}/build/ac-macros/sasl.m4
-}
-
-#| x86_64-linux-libtool: install: warning: 
`/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-logrotate/build/build/tmp/work/x86_64-linux/subversion-native/1.8.9-r0/build/subversion/libsvn_ra_local/libsvn_ra_local-1.la'
 has not been installed in 
`/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-logrotate/build/build/tmp/sysroots/x86_64-linux/usr/lib'|
 x86_64-linux-libtool: install: warning: 
`/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-logrotate/build/build/tmp/work/x86_64-linux/subversion-native/1.8.9-r0/build/subversion/libsvn_repos/libsvn_repos-1.la'
 has not been installed in 
`/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-logrotate/build/build/tmp/sysroots/x86_64-linux/usr/lib'|
 /usr/bin/ld: cannot find -lsvn_delta-1| collect2: ld returned 1 exit status| 
x86_64-linux-libtool: install: warning: 
`/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-logrotate/build/build/tmp/work/x86_64-linux/subversion-native/1.8.9-r0/build/su!
 bversion/libsvn_ra_svn/libsvn_ra_svn-1.la' has not been installed in 
`/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-logrotate/build/build/tmp/sysroots/x86_64-linux/usr/lib'|
 x86_64-linux-libtool: install: warning: 
`/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-logrotate/build/build/tmp/work/x86_64-linux/subversion-native/1.8.9-r0/build/subversion/libsvn_ra_serf/libsvn_ra_serf-1.la'
 has not been installed in 
`/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-logrotate/build/build/tmp/sysroots/x86_64-linux/usr/lib'
-#| x86_64-linux-libtool: install: error: relink `libsvn_ra_serf-1.la' with the 
above command before installing it
-#| x86_64-linux-libtool: install: warning: 
`../../subversion/libsvn_repos/libsvn_repos-1.la' has not been installed in 
`/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-logrotate/build/build/tmp/sysroots/x86_64-linux/usr/lib'
-#| 
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-logrotate/build/build/tmp/work/x86_64-linux/subversion-native/1.8.9-r0/subversion-1.8.9/build-outputs.mk:1090:
 recipe for target 'install-serf-lib' failed
-#| make: *** [install-serf-lib] Error 1
-PARALLEL_MAKEINST = ""
diff --git a/meta/recipes-devtools/subversion/subversion_1.9.6.bb 
b/meta/recipes-devtools/subversion/subversion_1.9.6.bb
new file mode 100644
index 000..b27115b
--- /dev/null
+++ b/meta/recipes-devtools/subversion/subversion_1.9.6.bb
@@ -0,0 +1,55 @@
+SUMMARY = "Subversion (svn) version control system client"
+SECTION

37 matches

Mail list logo