[OE-core] [PATCH] kernel.bbclass: improve reproducibility

2018-04-02 Thread Jonathan Liu
Set KBUILD_BUILD_VERSION=1 to avoid build version being incremented on
every build. It is visible in the output of "cat /proc/version" after
the hash character.

Signed-off-by: Jonathan Liu 
---
 meta/classes/kernel.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4877965af0..78d6c30b07 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -151,6 +151,7 @@ PACKAGES_DYNAMIC += "^${KERNEL_PACKAGE_NAME}-firmware-.*"
 
 export OS = "${TARGET_OS}"
 export CROSS_COMPILE = "${TARGET_PREFIX}"
+export KBUILD_BUILD_VERSION = "1"
 export KBUILD_BUILD_USER = "oe-user"
 export KBUILD_BUILD_HOST = "oe-host"
 
-- 
2.16.3

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


[OE-core] [PATCH v2] initrdscripts: init-install(-efi).sh: don't assume 20M boot partition

2018-04-02 Thread California Sullivan
With multi kernel support in the installer we can exceed this limit.
Calculate a sane size by checking the size of the original boot
partition minus some objects we know won't be installed, plus some extra
space for users.

In addition, in the common case where only one small kernel is present
to be installed, we actually get a smaller boot partition with less
wasted space.

Also add VIRTUAL-RUNTIME_base-utils to RDEPENDS where these scripts are
used, as they're needed for the du command.

[YOCTO #12583].

Signed-off-by: California Sullivan 
---
* v2: add VIRTUAL-RUNTIME_base-utils to RDEPENDS

 meta/recipes-core/initrdscripts/files/init-install-efi.sh | 15 +--
 meta/recipes-core/initrdscripts/files/init-install.sh | 15 +--
 .../initrdscripts/initramfs-live-install-efi_1.0.bb   |  2 +-
 .../initrdscripts/initramfs-live-install_1.0.bb   |  2 +-
 .../initrdscripts/initramfs-module-install-efi_1.0.bb |  2 +-
 .../initrdscripts/initramfs-module-install_1.0.bb |  2 +-
 6 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
index 43b75b01751..82b0aa819e3 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -8,8 +8,19 @@
 
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
 
-# We need 20 Mb for the boot partition
-boot_size=20
+# figure out how big of a boot partition we need
+boot_size=$(du -ms /run/media/$1/ | awk '{print $1}')
+# remove rootfs.img ($2) from the size if it exists, as its not installed to 
/boot
+if [ -e /run/media/$1/$2 ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/$2 | awk '{print $1}') ))
+fi
+# remove initrd from size since its not currently installed
+if [ -e /run/media/$1/initrd ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/initrd | awk '{print 
$1}') ))
+fi
+# add 10M to provide some extra space for users and account
+# for rounding in the above subtractions
+boot_size=$(( boot_size + 10 ))
 
 # 5% for swap
 swap_ratio=5
diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
b/meta/recipes-core/initrdscripts/files/init-install.sh
index aa9476660ba..28e8f09d19d 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -7,8 +7,19 @@
 
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
 
-# We need 20 Mb for the boot partition
-boot_size=20
+# figure out how big of a boot partition we need
+boot_size=$(du -ms /run/media/$1/ | awk '{print $1}')
+# remove rootfs.img ($2) from the size if it exists, as its not installed to 
/boot
+if [ -e /run/media/$1/$2 ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/$2 | awk '{print $1}') ))
+fi
+# remove initrd from size since its not currently installed
+if [ -e /run/media/$1/initrd ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/initrd | awk '{print 
$1}') ))
+fi
+# add 10M to provide some extra space for users and account
+# for rounding in the above subtractions
+boot_size=$(( boot_size + 10 ))
 
 # 5% for the swap
 swap_ratio=5
diff --git a/meta/recipes-core/initrdscripts/initramfs-live-install-efi_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-live-install-efi_1.0.bb
index 2a7f84ddc8f..f588a1077bf 100644
--- a/meta/recipes-core/initrdscripts/initramfs-live-install-efi_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-live-install-efi_1.0.bb
@@ -5,7 +5,7 @@ SRC_URI = "file://init-install-efi.sh"
 
 PR = "r1"
 
-RDEPENDS_${PN} = "parted e2fsprogs-mke2fs dosfstools util-linux-blkid"
+RDEPENDS_${PN} = "parted e2fsprogs-mke2fs dosfstools util-linux-blkid 
${VIRTUAL-RUNTIME_base-utils}"
 
 S = "${WORKDIR}"
 
diff --git a/meta/recipes-core/initrdscripts/initramfs-live-install_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-live-install_1.0.bb
index a553a0d8ba5..9222d57c1ae 100644
--- a/meta/recipes-core/initrdscripts/initramfs-live-install_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-live-install_1.0.bb
@@ -7,7 +7,7 @@ PR = "r9"
 
 S = "${WORKDIR}"
 
-RDEPENDS_${PN} = "grub parted e2fsprogs-mke2fs util-linux-blkid"
+RDEPENDS_${PN} = "grub parted e2fsprogs-mke2fs util-linux-blkid 
${VIRTUAL-RUNTIME_base-utils}"
 
 do_install() {
 install -m 0755 ${WORKDIR}/init-install.sh ${D}/install.sh
diff --git 
a/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb
index 1e7f76fd565..78a61cde25f 100644
--- a/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb
@@ -1,7 +1,7 @@
 SUMMARY = "initramfs-framework module for EFI installation option"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
-RDEPENDS_${PN} = "initramfs-framewor

Re: [OE-core] [PATCH] initrdscripts: init-install(-efi).sh: don't assume 20M boot partition

2018-04-02 Thread Cal Sullivan
I forgot to deal with RDEPENDS here. With the addition of du the script 
will depend on ${VIRTUAL-RUNTIME_base-utils}. This happens to be present 
in core-image-minimal-initramfs, so it worked for me, but could fail for 
others using their own initramfs.


I'll send a v2 adding to RDEPENDS on the recipes that use this.

Thanks,
Cal

On 04/02/2018 06:15 PM, California Sullivan wrote:

With multi kernel support in the installer we can exceed this limit.
Calculate a sane size by checking the size of the original boot
partition minus some objects we know won't be installed, plus some extra
space for users.

In addition, in the common case where only one small kernel is present
to be installed, we actually get a smaller boot partition with less
wasted space.

[YOCTO #12583].

Signed-off-by: California Sullivan 
---
  meta/recipes-core/initrdscripts/files/init-install-efi.sh | 15 +--
  meta/recipes-core/initrdscripts/files/init-install.sh | 15 +--
  2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
index 43b75b01751..82b0aa819e3 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -8,8 +8,19 @@
  
  PATH=/sbin:/bin:/usr/sbin:/usr/bin
  
-# We need 20 Mb for the boot partition

-boot_size=20
+# figure out how big of a boot partition we need
+boot_size=$(du -ms /run/media/$1/ | awk '{print $1}')
+# remove rootfs.img ($2) from the size if it exists, as its not installed to 
/boot
+if [ -e /run/media/$1/$2 ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/$2 | awk '{print $1}') ))
+fi
+# remove initrd from size since its not currently installed
+if [ -e /run/media/$1/initrd ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/initrd | awk '{print 
$1}') ))
+fi
+# add 10M to provide some extra space for users and account
+# for rounding in the above subtractions
+boot_size=$(( boot_size + 10 ))
  
  # 5% for swap

  swap_ratio=5
diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
b/meta/recipes-core/initrdscripts/files/init-install.sh
index aa9476660ba..28e8f09d19d 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -7,8 +7,19 @@
  
  PATH=/sbin:/bin:/usr/sbin:/usr/bin
  
-# We need 20 Mb for the boot partition

-boot_size=20
+# figure out how big of a boot partition we need
+boot_size=$(du -ms /run/media/$1/ | awk '{print $1}')
+# remove rootfs.img ($2) from the size if it exists, as its not installed to 
/boot
+if [ -e /run/media/$1/$2 ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/$2 | awk '{print $1}') ))
+fi
+# remove initrd from size since its not currently installed
+if [ -e /run/media/$1/initrd ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/initrd | awk '{print 
$1}') ))
+fi
+# add 10M to provide some extra space for users and account
+# for rounding in the above subtractions
+boot_size=$(( boot_size + 10 ))
  
  # 5% for the swap

  swap_ratio=5


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


[OE-core] [PATCH] initrdscripts: init-install(-efi).sh: don't assume 20M boot partition

2018-04-02 Thread California Sullivan
With multi kernel support in the installer we can exceed this limit.
Calculate a sane size by checking the size of the original boot
partition minus some objects we know won't be installed, plus some extra
space for users.

In addition, in the common case where only one small kernel is present
to be installed, we actually get a smaller boot partition with less
wasted space.

[YOCTO #12583].

Signed-off-by: California Sullivan 
---
 meta/recipes-core/initrdscripts/files/init-install-efi.sh | 15 +--
 meta/recipes-core/initrdscripts/files/init-install.sh | 15 +--
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
index 43b75b01751..82b0aa819e3 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -8,8 +8,19 @@
 
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
 
-# We need 20 Mb for the boot partition
-boot_size=20
+# figure out how big of a boot partition we need
+boot_size=$(du -ms /run/media/$1/ | awk '{print $1}')
+# remove rootfs.img ($2) from the size if it exists, as its not installed to 
/boot
+if [ -e /run/media/$1/$2 ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/$2 | awk '{print $1}') ))
+fi
+# remove initrd from size since its not currently installed
+if [ -e /run/media/$1/initrd ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/initrd | awk '{print 
$1}') ))
+fi
+# add 10M to provide some extra space for users and account
+# for rounding in the above subtractions
+boot_size=$(( boot_size + 10 ))
 
 # 5% for swap
 swap_ratio=5
diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
b/meta/recipes-core/initrdscripts/files/init-install.sh
index aa9476660ba..28e8f09d19d 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -7,8 +7,19 @@
 
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
 
-# We need 20 Mb for the boot partition
-boot_size=20
+# figure out how big of a boot partition we need
+boot_size=$(du -ms /run/media/$1/ | awk '{print $1}')
+# remove rootfs.img ($2) from the size if it exists, as its not installed to 
/boot
+if [ -e /run/media/$1/$2 ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/$2 | awk '{print $1}') ))
+fi
+# remove initrd from size since its not currently installed
+if [ -e /run/media/$1/initrd ]; then
+boot_size=$(( boot_size - $( du -ms /run/media/$1/initrd | awk '{print 
$1}') ))
+fi
+# add 10M to provide some extra space for users and account
+# for rounding in the above subtractions
+boot_size=$(( boot_size + 10 ))
 
 # 5% for the swap
 swap_ratio=5
-- 
2.14.3

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


[OE-core] [PATCH V2] logrotate: update to 3.14.0

2018-04-02 Thread Yi Zhao
Since the wtmp and btmp definitions had been moved from logrotate.conf
to logrotate.d in this release, we also need to install them to
/etc/logrotate.d/.

Also update oeqa runtime logrotate test case.

Signed-off-by: Yi Zhao 
---
 meta/lib/oeqa/runtime/cases/logrotate.py   |  4 ++--
 .../logrotate/{logrotate_3.13.0.bb => logrotate_3.14.0.bb} | 10 +++---
 2 files changed, 9 insertions(+), 5 deletions(-)
 rename meta/recipes-extended/logrotate/{logrotate_3.13.0.bb => 
logrotate_3.14.0.bb} (88%)

diff --git a/meta/lib/oeqa/runtime/cases/logrotate.py 
b/meta/lib/oeqa/runtime/cases/logrotate.py
index 992fef2..db6e695 100644
--- a/meta/lib/oeqa/runtime/cases/logrotate.py
+++ b/meta/lib/oeqa/runtime/cases/logrotate.py
@@ -21,9 +21,9 @@ class LogrotateTest(OERuntimeTestCase):
 self.assertEqual(status, 0, msg = msg)
 
 cmd = ('sed -i "s#wtmp {#wtmp {\\nolddir $HOME/logrotate_dir#"'
-   ' /etc/logrotate.conf')
+   ' /etc/logrotate.d/wtmp')
 status, output = self.target.run(cmd)
-msg = ('Could not write to logrotate.conf file. Status and output: '
+msg = ('Could not write to logrotate.d/wtmp file. Status and output: '
' %s and %s' % (status, output))
 self.assertEqual(status, 0, msg = msg)
 
diff --git a/meta/recipes-extended/logrotate/logrotate_3.13.0.bb 
b/meta/recipes-extended/logrotate/logrotate_3.14.0.bb
similarity index 88%
rename from meta/recipes-extended/logrotate/logrotate_3.13.0.bb
rename to meta/recipes-extended/logrotate/logrotate_3.14.0.bb
index 990cf91..d48539f 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.13.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.14.0.bb
@@ -25,8 +25,8 @@ SRC_URI = 
"https://github.com/${BPN}/${BPN}/releases/download/${PV}/${BP}.tar.xz
 file://disable-check-different-filesystems.patch \
 "
 
-SRC_URI[md5sum] = "78ef24d6fddcc4df8e412dd75c551b4c"
-SRC_URI[sha256sum] = 
"3222ca032f99be8d7a4a8c6ad69f3dcc49b9511bfe384bd5a271ebcd9bd3e52c"
+SRC_URI[md5sum] = "1c0f6e6e490c4bcac0a1e77ad1310683"
+SRC_URI[sha256sum] = 
"4703bdc0e2df3b322f9dff0aafc99aa9172c9e4acae28b7c924cc7d4e5b29d55"
 
 PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
 
@@ -34,7 +34,9 @@ PACKAGECONFIG[acl] = ",,acl"
 PACKAGECONFIG[selinux] = ",,libselinux"
 
 CONFFILES_${PN} += "${localstatedir}/lib/logrotate.status \
-   ${sysconfdir}/logrotate.conf"
+   ${sysconfdir}/logrotate.conf \
+   ${sysconfdir}/logrotate.d/btmp \
+   ${sysconfdir}/logrotate.d/wtmp"
 
 # If RPM_OPT_FLAGS is unset, it adds -g itself rather than obeying our
 # optimization variables, so use it rather than EXTRA_CFLAGS.
@@ -68,6 +70,8 @@ do_install(){
 mkdir -p ${D}${sysconfdir}/logrotate.d
 mkdir -p ${D}${localstatedir}/lib
 install -p -m 644 ${S}/examples/logrotate-default 
${D}${sysconfdir}/logrotate.conf
+install -p -m 644 ${S}/examples/btmp ${D}${sysconfdir}/logrotate.d/btmp
+install -p -m 644 ${S}/examples/wtmp ${D}${sysconfdir}/logrotate.d/wtmp
 touch ${D}${localstatedir}/lib/logrotate.status
 
 if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', 
d)}; then
-- 
2.7.4

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


Re: [OE-core] [PATCH][RFC] pseudo: intercept syscall() and return ENOTSUP for renameat2

2018-04-02 Thread Richard Purdie
And on a happier note this time, pseudo master appears much happier and
19f18124f16c4c85405b140a1fb8cb3b31d865bf seems to pass on the
autobuilders. I'll do some specific checks on f27 but things are
looking good, thanks everyone who's helped with this.

Cheers,

Richard


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


Re: [OE-core] [PATCH 0/1] buildhistory_analysis.py: Check if RPROVIDES changed order

2018-04-02 Thread Stephano Cetola
On 3/15/18 2:04 PM, Amanda Brindle wrote:
> The following changes since commit 0fd6d0dd0041929d60111868ca3575d9d9bf9ac3:
> 
>   linux-yocto/4.12: backport bugfixes for x86 (2018-03-15 06:27:20 -0700)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib abrindle/buildhistory-diff4
>   
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=abrindle/buildhistory-diff4
> 
> Amanda Brindle (1):
>   buildhistory_analysis.py: Check if RPROVIDES changed order
> 
>  meta/lib/oe/buildhistory_analysis.py | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
Ack'd.

Sorry I lost track of this. Any chance this can make M4?

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


Re: [OE-core] kernel menuconfig broken?

2018-04-02 Thread Trevor Woerner
On Sun 2018-04-01 @ 11:49:58 PM, Andreas Müller wrote:
> When running bitbake -cmenuconfig virtual/kernel I get a flood of
> undefined reference errors. Am I alone here?

Sadly, I think you might be.

$ bitbake virtual/kernel -c menuconfig

works fine for me.

I assume you're doing this for something RaspberryPi-ish?

Build Configuration:
BB_VERSION   = "1.37.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "opensuse-42.3"
TARGET_SYS   = "arm-oe-linux-gnueabi"
MACHINE  = "raspberrypi3"
DISTRO   = "nodistro"
DISTRO_VERSION   = "nodistro.0"
TUNE_FEATURES= "arm armv7ve vfp thumb neon vfpv4 
callconvention-hard cortexa7"
TARGET_FPU   = "hard"
meta-raspberrypi = "master:63e53f919089027259a513dc2cd4b140789bf1a3"
meta = "master:4cedddb83623c79980b354642dfeaf78218ca4b7"
meta-oe  
meta-gnome   
meta-python  
meta-networking  
meta-multimedia  = "master:b9d1d8718834f7287e5a65373b952cbfe9ce83fe"
meta-qt5 = "master:e60e849de1158c879bd2c150fe79b207cdac031a"
meta-qt5-extra   = "master:a0cf057b2f335e8d2be9180f20770773334ec209"
meta-realtime= "master:250bc6eaa47e550c1db5e2b0ebd42d86ee43650e"
meta-browser = "master:d1c902440cba26a9d1271cfb914633c68ee3791c"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] ✗ patchtest: failure for python3: Improve logging capabilities for do_create_manifest

2018-04-02 Thread Patchwork
== Series Details ==

Series: python3: Improve logging capabilities for do_create_manifest
Revision: 1
URL   : https://patchwork.openembedded.org/series/11647/
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 4cedddb836)



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] python3: Improve logging capabilities for do_create_manifest

2018-04-02 Thread Alejandro Enedino Hernandez Samaniego
Adds a couple of prints to get a nicer log, and creates a
small summary or report after checking every module, it
makes it more feasible for adoption, easier to debug why
a module ended at a certain package and see how the
manifest was created.

Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 .../python/python3/create_manifest3.py | 34 +-
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-devtools/python/python3/create_manifest3.py 
b/meta/recipes-devtools/python/python3/create_manifest3.py
index 212ddd4..44f3454 100644
--- a/meta/recipes-devtools/python/python3/create_manifest3.py
+++ b/meta/recipes-devtools/python/python3/create_manifest3.py
@@ -80,7 +80,7 @@ with open('python3-manifest.json') as manifest:

 # First pass to get core-package functionality, because we base everything on 
the fact that core is actually working
 # Not exactly the same so it should not be a function
-print ('Getting dependencies for core package:')
+print ('Getting dependencies for package: core')

 # Special call to check for core package
 output = subprocess.check_output([sys.executable, 'get_module_deps3.py', 
'python-core-package']).decode('utf8')
@@ -128,6 +128,7 @@ for value in old_manifest['core']['files']:
   # Each module will only import what is necessary for it to work in specific
   print ('Getting dependencies for module: %s' % value)
   output = subprocess.check_output([sys.executable, 'get_module_deps3.py', 
'%s' % value]).decode('utf8')
+  print ('The following dependencies were found for module %s:\n' % value)
   print (output)
   for item in output.split():
 # We append it so it doesnt hurt what we currently have:
@@ -170,7 +171,10 @@ for key in old_manifest:

 # Handle special cases, we assume that when they were manually added
 # to the manifest we knew what we were doing.
+print('\n')
+print('--')
 print ('Handling package %s' % key)
+print('--')
 special_packages=['misc', 'modules', 'dev']
 if key in special_packages or 'staticdev' in key:
 print('Passing %s package directly' % key)
@@ -219,11 +223,16 @@ for key in old_manifest:

 # Launch separate task for each module for deterministic behavior
 # Each module will only import what is necessary for it to work in 
specific
-print ('Getting dependencies for module: %s' % value)
+print ('\nGetting dependencies for module: %s' % value)
 output = subprocess.check_output([sys.executable, 
'get_module_deps3.py', '%s' % value]).decode('utf8')
 # We can print dependencies for debugging purposes
+print ('The following dependencies were found for module %s:\n' % 
value)
 print (output)
 # Output will have all dependencies
+
+reportFILES = []
+reportRDEPS = []
+
 for item in output.split():

 # Warning: This first part is ugly
@@ -255,7 +264,7 @@ for key in old_manifest:
 #print('Checking folder %s on package %s' % 
(item,keyfolder))
 for file_folder in 
old_manifest[keyfolder]['files'] or file_folder in 
old_manifest[keyfolder]['cached']:
 if file_folder==folder:
-print ('%s found in %s' % (folder, 
keyfolder))
+print ('%s folder found in %s' % (folder, 
keyfolder))
 folderFound = True
 if keyfolder not in 
new_manifest[key]['rdepends'] and keyfolder != key:
 
new_manifest[key]['rdepends'].append(keyfolder)
@@ -267,6 +276,7 @@ for key in old_manifest:
 if inFolders:
 continue

+
 # We might already have it on the dictionary since it could depend 
on a (previously checked) module
 if item not in new_manifest[key]['files'] and item not in 
new_manifest[key]['cached']:
 # Handle core as a special package, we already did it so we 
pass it to NEW data structure directly
@@ -287,6 +297,7 @@ for key in old_manifest:

 else:

+
 # Check if this dependency is already contained on another 
package, so we add it
 # as an RDEPENDS, or if its not, it means it should be 
contained on the current
 # package, so we should add it to FILES
@@ -298,19 +309,19 @@ for key in old_manifest:
 if(newkey!=key):
 if newkey not in 
new_manifest[key]['rdepends']:
# Add it to the new manifest data struct
-   # Debug
-   print('Adding %s to %s RDEPENDS, 
because it contains %s' % (newkey, key, item))
+   reportR

[OE-core] [PATCH V2 2/2] mesa: Prefer dri3 for x11/opengl

2018-04-02 Thread Andreas Müller
Adresses [1]

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12642

Signed-off-by: Andreas Müller 
---
 meta/recipes-graphics/mesa/mesa.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 9e4da81f7f..639eb35f6b 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -40,7 +40,7 @@ EXTRA_OECONF = "--enable-shared-glapi \
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland vulkan', d)} 
\
${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl 
egl gles gbm dri', '', d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 
'x11', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'x11 
dri3', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan', 
'dri3', '', d)} \
   "
 
-- 
2.14.3

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


[OE-core] [PATCH V2 1/2] mesa: fix unitialized modifier for DRI2

2018-04-02 Thread Andreas Müller
This came up whith disabled DRI3 on Raspi/VC4 [1] but might be important for 
other
drivers: It fixes an improper initialization.

[1] https://lists.freedesktop.org/archives/mesa-dev/2018-March/190562.html

Signed-off-by: Andreas Müller 
---
 ...i-Initialise-modifier-to-INVALID-for-DRI2.patch | 43 ++
 meta/recipes-graphics/mesa/mesa_17.3.7.bb  |  1 +
 2 files changed, 44 insertions(+)
 create mode 100644 
meta/recipes-graphics/mesa/files/0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch

diff --git 
a/meta/recipes-graphics/mesa/files/0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch
 
b/meta/recipes-graphics/mesa/files/0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch
new file mode 100644
index 00..6aba7859ee
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/files/0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch
@@ -0,0 +1,43 @@
+From 4cbecb61682a0ee426faaa03d824fc8fd7aef826 Mon Sep 17 00:00:00 2001
+From: Daniel Stone 
+Date: Mon, 2 Apr 2018 13:20:34 +0100
+Subject: [PATCH] st/dri: Initialise modifier to INVALID for DRI2
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When allocating a buffer for DRI2, set the modifier to INVALID to inform
+the backend that we have no supplied modifiers and it should do its own
+thing. The missed initialisation forced linear, even if the
+implementation had made other decisions.
+
+This resulted in VC4 DRI2 clients failing with:
+  Modifier 0x0 vs. tiling (0x701) mismatch
+
+Signed-off-by: Daniel Stone 
+Reported-by: Andreas Müller 
+Reviewed-by: Eric Anholt 
+Fixes: 3f8513172ff6 ("gallium/winsys/drm: introduce modifier field to 
winsys_handle")
+
+Upstream-Status: Backport [1]
+
+[1] 
https://cgit.freedesktop.org/mesa/mesa/commit/?id=4cbecb61682a0ee426faaa03d824fc8fd7aef826
+---
+ src/gallium/state_trackers/dri/dri2.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
+index 31d17d46c2..58a6757f03 100644
+--- a/src/gallium/state_trackers/dri/dri2.c
 b/src/gallium/state_trackers/dri/dri2.c
+@@ -806,6 +806,7 @@ dri2_allocate_textures(struct dri_context *ctx,
+  whandle.handle = buf->name;
+  whandle.stride = buf->pitch;
+  whandle.offset = 0;
++ whandle.modifier = DRM_FORMAT_MOD_INVALID;
+  if (screen->can_share_buffer)
+ whandle.type = DRM_API_HANDLE_TYPE_SHARED;
+  else
+-- 
+2.14.3
+
diff --git a/meta/recipes-graphics/mesa/mesa_17.3.7.bb 
b/meta/recipes-graphics/mesa/mesa_17.3.7.bb
index fe09a2988d..9c75d6c693 100644
--- a/meta/recipes-graphics/mesa/mesa_17.3.7.bb
+++ b/meta/recipes-graphics/mesa/mesa_17.3.7.bb
@@ -9,6 +9,7 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://llvm-config-version.patch \
file://0001-winsys-svga-drm-Include-sys-types.h.patch \

file://0001-Makefile.vulkan.am-explictly-add-lib-expat-to-intel-.patch \
+   file://0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch \
"
 
 SRC_URI[md5sum] = "769137f2538562c300c4b76bcb097377"
-- 
2.14.3

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


[OE-core] ✗ patchtest: failure for "mesa: fix unitialized modifier..." and 1 more

2018-04-02 Thread Patchwork
== Series Details ==

Series: "mesa: fix unitialized modifier..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/11645/
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 Upstream-Status is in incorrect format 
[test_upstream_status_presence_format] 
  Suggested fixFix Upstream-Status format in 
0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch
  Current  Upstream-Status: Applied [1]
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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


[OE-core] [PATCH 2/2] mesa: Prefer dri3 for x11/opengl

2018-04-02 Thread Andreas Müller
Adresses [1]

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12642

Signed-off-by: Andreas Müller 
---
 meta/recipes-graphics/mesa/mesa.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 9e4da81f7f..639eb35f6b 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -40,7 +40,7 @@ EXTRA_OECONF = "--enable-shared-glapi \
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland vulkan', d)} 
\
${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl 
egl gles gbm dri', '', d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 
'x11', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'x11 
dri3', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan', 
'dri3', '', d)} \
   "
 
-- 
2.14.3

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


[OE-core] [PATCH 1/2] mesa: fix unitialized modifier for DRI2

2018-04-02 Thread Andreas Müller
This came up whith disabled DRI3 on Raspi/VC4 [1] but might be important for 
other
drivers: It fixes an improper initialization.

[1] https://lists.freedesktop.org/archives/mesa-dev/2018-March/190562.html

Signed-off-by: Andreas Müller 
---
 ...i-Initialise-modifier-to-INVALID-for-DRI2.patch | 43 ++
 meta/recipes-graphics/mesa/mesa_17.3.7.bb  |  1 +
 2 files changed, 44 insertions(+)
 create mode 100644 
meta/recipes-graphics/mesa/files/0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch

diff --git 
a/meta/recipes-graphics/mesa/files/0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch
 
b/meta/recipes-graphics/mesa/files/0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch
new file mode 100644
index 00..126f14f784
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/files/0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch
@@ -0,0 +1,43 @@
+From 4cbecb61682a0ee426faaa03d824fc8fd7aef826 Mon Sep 17 00:00:00 2001
+From: Daniel Stone 
+Date: Mon, 2 Apr 2018 13:20:34 +0100
+Subject: [PATCH] st/dri: Initialise modifier to INVALID for DRI2
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When allocating a buffer for DRI2, set the modifier to INVALID to inform
+the backend that we have no supplied modifiers and it should do its own
+thing. The missed initialisation forced linear, even if the
+implementation had made other decisions.
+
+This resulted in VC4 DRI2 clients failing with:
+  Modifier 0x0 vs. tiling (0x701) mismatch
+
+Signed-off-by: Daniel Stone 
+Reported-by: Andreas Müller 
+Reviewed-by: Eric Anholt 
+Fixes: 3f8513172ff6 ("gallium/winsys/drm: introduce modifier field to 
winsys_handle")
+
+Upstream-Status: Applied [1]
+
+[1] 
https://cgit.freedesktop.org/mesa/mesa/commit/?id=4cbecb61682a0ee426faaa03d824fc8fd7aef826
+---
+ src/gallium/state_trackers/dri/dri2.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/src/gallium/state_trackers/dri/dri2.c 
b/src/gallium/state_trackers/dri/dri2.c
+index 31d17d46c2..58a6757f03 100644
+--- a/src/gallium/state_trackers/dri/dri2.c
 b/src/gallium/state_trackers/dri/dri2.c
+@@ -806,6 +806,7 @@ dri2_allocate_textures(struct dri_context *ctx,
+  whandle.handle = buf->name;
+  whandle.stride = buf->pitch;
+  whandle.offset = 0;
++ whandle.modifier = DRM_FORMAT_MOD_INVALID;
+  if (screen->can_share_buffer)
+ whandle.type = DRM_API_HANDLE_TYPE_SHARED;
+  else
+-- 
+2.14.3
+
diff --git a/meta/recipes-graphics/mesa/mesa_17.3.7.bb 
b/meta/recipes-graphics/mesa/mesa_17.3.7.bb
index fe09a2988d..9c75d6c693 100644
--- a/meta/recipes-graphics/mesa/mesa_17.3.7.bb
+++ b/meta/recipes-graphics/mesa/mesa_17.3.7.bb
@@ -9,6 +9,7 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://llvm-config-version.patch \
file://0001-winsys-svga-drm-Include-sys-types.h.patch \

file://0001-Makefile.vulkan.am-explictly-add-lib-expat-to-intel-.patch \
+   file://0001-st-dri-Initialise-modifier-to-INVALID-for-DRI2.patch \
"
 
 SRC_URI[md5sum] = "769137f2538562c300c4b76bcb097377"
-- 
2.14.3

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


Re: [OE-core] [PATCH] oeqa/runtime/stap.py: add runtime test for systemtap

2018-04-02 Thread Victor Kamensky



On Mon, 26 Mar 2018, Burton, Ross wrote:


On the autobuilder:

| NOTE: FAIL [15.139s]: test_stap (stap.StapTest)
| NOTE: --
| NOTE: Traceback (most recent call last):
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-rpm-non-rpm/build/meta/lib/oeqa/core/decorator/__init__.py",
line 32, in wrapped_f
| return func(*args, **kwargs)
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-rpm-non-rpm/build/meta/lib/oeqa/core/decorator/__init__.py",
line 32, in wrapped_f
| return func(*args, **kwargs)
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-rpm-non-rpm/build/meta/lib/oeqa/core/decorator/__init__.py",
line 32, in wrapped_f
| return func(*args, **kwargs)
|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-rpm-non-rpm/build/meta/lib/oeqa/runtime/cases/stap.py",
line 33, in test_stap
| self.assertEqual(status, 0, msg='\n'.join([cmd, output]))
| AssertionError: 1 != 0 : stap --disable-cache /tmp/hello.stp
| ERROR: module version mismatch (#1 SMP PREEMPT Mon Mar 26 14:41:21
UTC 2018 vs #1 SMP PREEMPT Mon Mar 26 14:03:27 GMT 2018), release
4.14.24-yocto-standard
| WARNING: /usr/bin/staprun exited with status: 1
| Pass 5: run failed.  [man error::pass5]

Is this systemtap-uprobes not being rebuilt when it should?


systemtap-uprobes should not be used nowdays.

Does anyone have pointer to what autobuilder is executing?

Above message indicates that version of kernel that is running
'uname -v' does not match version string recorded in
/usr/src/kernel/include/generated/compile.h (which is part of
kernel-devsrc package). Usually such version check is performed
by kernel CONFIG_MODVERSIONS, which is not enabled in OE build.
SystemTap specifically adds its own kernel version check (the
one firing above) and it could be disabled through command
line parameter.

It is easy to reproduce above error by building core-image-lsb-sdk,
then running 'bitbake -c cleansstate linux-yocto' and rebuilding
core-image-lsb-sdk image again. In resulting image 'uname -v'
will not match UTS_VERSION from
/usr/src/kernel/include/generated/compile.h.

I.e now even kernel-devsrc is pulling information from virtual/kernel,
kernel-devsrc is not rebuilt even if virtual/kernel is
rebuilt. IMHO it should be rebuilt. But is it by design or something
does not work, I cannot tell. In kernel-devsrc there are statements like
'do_install[depends] += "virtual/kernel:do_install"', but whether
those just build ordering statement or whether they should
trigger rebuild if "virtual/kernel:do_install" is newer is not clear.

For now I'll modify stap test patch and call stap with kernel version
check disabled assuming that running kernel and kernel-devsrc always
would be close enough to run without problems. But it would be great if
folks could clarify rebuild dependency rule between virtual/kernel
and kernel-devsrc.

Thanks,
Victor


Ross

On 22 March 2018 at 17:53, Victor Kamensky  wrote:

Add runtime test for stap to test basic SystemTap
operations: can compile very basic module and run on
target device.

Signed-off-by: Victor Kamensky 
---
 meta/lib/oeqa/runtime/cases/stap.py   | 33 +
 meta/lib/oeqa/runtime/files/hello.stp |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 meta/lib/oeqa/runtime/cases/stap.py
 create mode 100644 meta/lib/oeqa/runtime/files/hello.stp

diff --git a/meta/lib/oeqa/runtime/cases/stap.py 
b/meta/lib/oeqa/runtime/cases/stap.py
new file mode 100644
index 000..005da71
--- /dev/null
+++ b/meta/lib/oeqa/runtime/cases/stap.py
@@ -0,0 +1,33 @@
+import os
+
+from oeqa.runtime.case import OERuntimeTestCase
+from oeqa.core.decorator.depends import OETestDepends
+from oeqa.core.decorator.oeid import OETestID
+from oeqa.core.decorator.data import skipIfNotFeature
+
+class StapTest(OERuntimeTestCase):
+
+@classmethod
+def setUpClass(cls):
+src = os.path.join(cls.tc.runtime_files_dir, 'hello.stp')
+dst = '/tmp/hello.stp'
+cls.tc.target.copyTo(src, dst)
+
+@classmethod
+def tearDownClass(cls):
+files = '/tmp/hello.stp'
+cls.tc.target.run('rm %s' % files)
+
+@OETestID(1652)
+@skipIfNotFeature('tools-profile',
+  'Test requires tools-profile to be in IMAGE_FEATURES')
+@OETestDepends(['kernelmodule.KernelModuleTest.test_kernel_module'])
+def test_stap(self):
+cmds = [
+'cd /usr/src/kernel && make scripts',
+'cd /lib/modules/* && (if [ ! -L build ]; then ln -s 
/usr/src/kernel build; fi)',
+'stap --disable-cache /tmp/hello.stp'
+]
+for cmd in cmds:
+status, output = self.target.run(cmd, 900)
+self.assertEqual(status, 0, msg='\n'.join([cmd, output]))
diff --git a/meta/lib/oeqa/runtime/files/hello.stp 
b/meta/lib/oeqa/runtime/files/hello.stp
new file mode 100644
index 000..3677147

[OE-core] Yocto Project Status WW14’18

2018-04-02 Thread Jordan, Robin L
Current Dev Position: YP 2.5 M3 final close out.

Next Deadline: YP 2.5 M4 stabilization is 4/2/18

SWAT Team Rotation:

SWAT lead is currently Juro.

SWAT team rotation: Juro -> Paul on April 6, 2018

SWAT team rotation: Paul -> Tracy on April 13, 2018

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

  *   Two issues have so far been identified in the M3 rc1 build. One is due to 
differences in build-appliance srcrev between the new and old buildbot 
autobuilder codebases. The second is an issue with the particular stable kernel 
version causing problems on 32bit IA which we believe is fixed in current 
master due to kernel version changes there.
  *   We continue to be blocked with morty on the glibc 2.27 and the sdk locale 
issues.  Armin has been looking into it.
  *   The pseudo issue with newer versions of coreutils as used in fedora27 
continues to cause problems, but thanks to some work by several people we do 
look close to a solution.  The help from everyone is much appreciated.
  *   We are now well into the stabilization period and are seeing a number of 
good patches both to fix current issues and future proof the release, 
foreseeing potential problems with versions and heading those issues off.  
Thanks to everyone helping with these.
  *   The codename for 2.6 (after sumo) will be ‘thud’.
  *   As a reminder, general recipe upgrades will not be merged during this 
period unless there is a pressing reason.  Those will be held for 2.6.


Planned upcoming dot releases:

YP 2.3.4 (Pyro) will be built after 2.5 M3

YP 2.2.4 (Morty) will be built after 2.5 M3 once the glibc 2.27 issue is fixed

YP 2.4.3 (Rocko) is planned for post YP 2.5.


Key YP 2.5 Dates are:

YP 2.5 M3 is in QA.  See status above.

YP 2.5 M3 was scheduled for release 3/2/18

YP 2.5 M4 cut off of 4/2/18

YP 2.5 M4 release of 4/27/18


Tracking Metrics:

WDD 2594 (last week 2673)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

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


[OE-core] [PATCH 1/2] qemu: do not hardcode python2.7 path

2018-04-02 Thread Ruslan Ruslichenko
It can be installed to some non standard path in which
case build will be broken.
As python2.7 is specified in HOSTTOOLS we can rely
that it is present in the PATH, so no need to hardcode
it to /usr/bin.

Signed-off-by: Ruslan Ruslichenko 
---
 meta/recipes-devtools/qemu/qemu.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 2a1d14b..dc73df8 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -28,7 +28,7 @@ EXTRA_OECONF = " \
 --target-list=${@get_qemu_target_list(d)} \
 --extra-cflags='${CFLAGS}' \
 "
-EXTRA_OECONF_append_class-native = " --python=${USRBINPATH}/python2.7"
+EXTRA_OECONF_append_class-native = " --python=python2.7"
 
 EXTRA_OEMAKE_append_class-native = " LD='${LD}' AR='${AR}' 
OBJCOPY='${OBJCOPY}' LDFLAGS='${LDFLAGS}'"
 
-- 
1.9.1

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


[OE-core] [PATCH 2/2] tune-core2.inc: add cpu type for qemu

2018-04-02 Thread Ruslan Ruslichenko
Define cpu type for Qemu in QEMU_EXTRAOPTIONS.
Otherways Qemu will emulate some virtual qemu32/64 processor,
which has very basic set of features, and programs built
for later CPU may crash, due to lack of new features (e.g. SSSE3).

Signed-off-by: Ruslan Ruslichenko 
---
 meta/conf/machine/include/tune-core2.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/conf/machine/include/tune-core2.inc 
b/meta/conf/machine/include/tune-core2.inc
index 6a03466..c686bb4 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -21,15 +21,18 @@ TUNE_FEATURES_tune-core2-32 = "${TUNE_FEATURES_tune-x86} 
core2"
 BASE_LIB_tune-core2-32 = "lib"
 TUNE_PKGARCH_tune-core2-32 = "core2-32"
 PACKAGE_EXTRA_ARCHS_tune-core2-32 = "${PACKAGE_EXTRA_ARCHS_tune-i686} core2-32"
+QEMU_EXTRAOPTIONS_core2-32 = " -cpu core2duo"
 
 AVAILTUNES += "core2-64"
 TUNE_FEATURES_tune-core2-64 = "${TUNE_FEATURES_tune-x86-64} core2"
 BASE_LIB_tune-core2-64 = "lib64"
 TUNE_PKGARCH_tune-core2-64 = "core2-64"
 PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64} 
core2-64"
+QEMU_EXTRAOPTIONS_core2-64 = " -cpu core2duo"
 
 AVAILTUNES += "core2-64-x32"
 TUNE_FEATURES_tune-core2-64-x32 = "${TUNE_FEATURES_tune-x86-64-x32} core2"
 BASE_LIB_tune-core2-64-x32 = "libx32"
 TUNE_PKGARCH_tune-core2-64-x32 = "core2-64-x32"
 PACKAGE_EXTRA_ARCHS_tune-core2-64-x32 = 
"${PACKAGE_EXTRA_ARCHS_tune-x86-64-x32} core2-64-x32"
+QEMU_EXTRAOPTIONS_core2-64-x32 = " -cpu core2duo"
-- 
1.9.1

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