Re: [OE-core] [PATCH 6/6] perf: drop 'include' copy

2019-10-21 Thread Martin Jansa
On Mon, Oct 21, 2019 at 04:16:18PM -0400, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield 
> 
> The copy of the kernel's top level include directory is not
> required to build perf. We have both the linux-libc-headers and
> perf's captured/copied headers for what it requires.
> 
> The copy of the kernel's headers is leading us to multiple smaller
> fixes to ensure that the various .h files are in sync. We can
> remove the copy and all of the sync checks, and perf still builds
> and executes correctly.

Maybe reorder this before "[OE-core] [PATCH 3/6] perf: fix v5.4+ builds"
as it removes most of what was possibly incorrectly added there (see 2nd
review)

> Signed-off-by: Bruce Ashfield 
> ---
>  meta/recipes-kernel/perf/perf.bb | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/meta/recipes-kernel/perf/perf.bb 
> b/meta/recipes-kernel/perf/perf.bb
> index 191305969c..5f0ba7c180 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -106,7 +106,6 @@ EXTRA_OEMAKE += "\
>  EXTRA_OEMAKE_append_task-configure = " JOBS=1"
>  
>  PERF_SRC ?= "Makefile \
> - include \
>   tools/arch \
>   tools/build \
>   tools/include \
> @@ -248,14 +247,6 @@ do_configure_prepend () {
>  # so we copy it from the sysroot unistd.h to the perf unistd.h
>  install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
> ${S}/tools/include/uapi/asm-generic/unistd.h
>  install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
> ${S}/include/uapi/asm-generic/unistd.h
> -
> -# bits.h can have the same issue as unistd.h, so we make the tools 
> variant take precedence
> -[ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644 
> ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
> -
> -[ -e ${S}/tools/perf/util/include/linux/ctype.h ] && install -D -m0644 
> ${S}/include/linux/ctype.h ${S}/tools/perf/util/include/linux/ctype.h
> -
> -[ -e ${S}/include/uapi/linux/kvm.h ] && install -D -m0644 
> ${S}/include/uapi/linux/kvm.h  ${S}/tools/include/uapi/linux/kvm.h
> -[ -e ${S}/include/uapi/linux/sched.h ] && install -D -m0644 
> ${S}/include/uapi/linux/sched.h  ${S}/tools/include/uapi/linux/sched.h
>  }
>  
>  python do_package_prepend() {
> -- 
> 2.19.1
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] [PATCH 3/6] perf: fix v5.4+ builds

2019-10-21 Thread Martin Jansa
On Mon, Oct 21, 2019 at 04:16:15PM -0400, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield 
> 
> When building perf for 5.4+, we have some new files that need to
> be copied (and synchronized) due to structural changes in the
> kernel source tree.
> 
> Some of the issues these fixes are warnings, but none the less,
> they are worth fixing.
> 
>  - We copy arch/${ARCH}/Makefile, since it is source by some perf
>Makefiles
> 
>  - We copy scripts/, since the perf utilities are looking for files
>in that directory stucture.
> 
>  - We have *three* copies of ctypes.h in the tools/* hierarchy
>during the build. If the tools/perf/util/include/linux/ variant
>is used, it will trigger build errors since it is not complete.
>We copy the kernel's main include/linux/ctype.h to ensure they
>are in sync.
> 
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/recipes-kernel/perf/perf.bb | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/meta/recipes-kernel/perf/perf.bb 
> b/meta/recipes-kernel/perf/perf.bb
> index 8201c0cb60..0f5df74f11 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -113,6 +113,8 @@ PERF_SRC ?= "Makefile \
>   tools/Makefile \
>   tools/perf \
>   tools/scripts \
> + scripts/ \
> + arch/${ARCH}/Makefile \
>  "
>  
>  PERF_EXTRA_LDFLAGS = ""
> @@ -246,6 +248,11 @@ do_configure_prepend () {
>  
>  # bits.h can have the same issue as unistd.h, so we make the tools 
> variant take precedence
>  [ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644 
> ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
> +
> +[ -e ${S}/tools/perf/util/include/linux/ctype.h ] && install -D -m0644 
> ${S}/include/linux/ctype.h ${S}/tools/perf/util/include/linux/ctype.h

This one doesn't look right, why are you checking for the destination
existence instead of source?

> +[ -e ${S}/include/uapi/linux/kvm.h ] && install -D -m0644 
> ${S}/include/uapi/linux/kvm.h  ${S}/tools/include/uapi/linux/kvm.h
> +[ -e ${S}/include/uapi/linux/sched.h ] && install -D -m0644 
> ${S}/include/uapi/linux/sched.h  ${S}/tools/include/uapi/linux/sched.h
>  }
>  
>  python do_package_prepend() {
> -- 
> 2.19.1
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] [PATCH][RESEND 0/6] YOCTO #12937 - Consistent naming scheme for deployed artifacts

2019-10-17 Thread Martin Jansa
On Sun, Oct 13, 2019 at 02:44:30PM +0100, Richard Purdie wrote:
> On Sat, 2019-10-12 at 13:03 +0000, Martin Jansa wrote:
> > The following changes since commit
> > 59938780e7e776d87146002ea939b185f8704408:
> > 
> >   build-appliance-image: Update to master head revision (2019-10-09
> > 22:28:44 +0100)
> > 
> > are available in the Git repository at:
> > 
> >   git://git.openembedded.org/openembedded-core-contrib
> > jansa/artifacts
> >   
> > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=jansa/artifacts
> > 
> > Martin Jansa (6):
> >   image-artifact-names: introduce new bbclass and move some variables
> > into it
> >   bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in
> > the _LINK_NAME variables and change it to hard link
> >   kernel-artifact-names.bbclass: use PR instead of PKGR in
> > KERNEL_ARTIFACT_NAME
> >   kernel.bbclass: imageType without {}
> >   kernel.bbclass: drop unnecessary package_get_auto_pr for do_install
> >   *-artifact-names: include version only in the artifact links
> 
> I tried this on the autobuilder and it seems to break several things:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/423
> 
> Looks like do_bootimg fails, as well as the testimage oeqa code being
> unable to find the testdata json files.

I've successfully built this with nodistro and qemux86-64 before sending
the pull request, now I've built core-image-sato-sdk-ptest with poky and
genericx86-64 as well, so I'm still trying to figure out what
autobuilder does differently to break it like this.

> There could well be further issues beyond that but its hard to tell.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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][RESEND 0/6] YOCTO #12937 - Consistent naming scheme for deployed artifacts

2019-10-12 Thread Martin Jansa
2:59 
core-image-minimal-qemux86-64-release-1.ext4
51665615 -rw-r--r--  2 bitbake bitbake  61M Aug 16 12:59 
core-image-minimal-qemux86-64.rootfs.ext4
51665617 -rw-r--r--  2 bitbake bitbake  49M Aug 16 12:59 
core-image-minimal-qemux86-64-release-1.wic.vmdk
51665617 -rw-r--r--  2 bitbake bitbake  49M Aug 16 12:59 
core-image-minimal-qemux86-64.rootfs.wic.vmdk

f) With this PR and IMAGE_VERSION_SUFFIX_forcevariable = "-release-2"
   and IMAGE_INSTALL_append = " zlib" added to force image to be recreated
   while kernel is still reused from sstate
   In this case I haven't removed TMPDIR between e) and f) to show
   that kernel artifacts are identical from previous build release-1 and just
   added another hardlink to the same inode.

$ ls -laih qemux86-64-YOCTO-12937-release-2/ | sort
47054849 drwxr-xr-x 13 bitbake bitbake 4.0K Aug 16 16:37 ..
51665409 -rw-r--r--  2 bitbake bitbake 1.3K Aug 16 13:07 
core-image-minimal-qemux86-64.qemuboot.conf
51665409 -rw-r--r--  2 bitbake bitbake 1.3K Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.qemuboot.conf
51665420 -rw-r--r--  2 bitbake bitbake 161K Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.testdata.json
51665420 -rw-r--r--  2 bitbake bitbake 161K Aug 16 13:07 
core-image-minimal-qemux86-64.testdata.json
51665422 -rw-r--r--  2 bitbake bitbake 2.2K Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.manifest
51665422 -rw-r--r--  2 bitbake bitbake 2.2K Aug 16 13:07 
core-image-minimal-qemux86-64.rootfs.manifest
51665583 -rw-r--r--  1 bitbake bitbake 1.1K Aug 16 13:07 core-image-minimal.env
51665584 -rw-r--r--  2 bitbake bitbake  61M Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.ext4
51665584 -rw-r--r--  2 bitbake bitbake  61M Aug 16 13:07 
core-image-minimal-qemux86-64.rootfs.ext4
51665585 -rw-r--r--  2 bitbake bitbake  49M Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.wic.vmdk
51665585 -rw-r--r--  2 bitbake bitbake  49M Aug 16 13:07 
core-image-minimal-qemux86-64.rootfs.wic.vmdk
51666546 drwxr-xr-x  2 bitbake bitbake 4.0K Aug 16 13:07 .
51666553 -rw-r--r--  1 bitbake bitbake 612K Aug 15 17:16 grub-efi-bootx64.efi
51666554 -rwxr-xr-x  1 bitbake bitbake  95K Aug 15 17:16 systemd-bootx64.efi
51666555 -rw-r--r--  3 bitbake bitbake 7.0M Aug 15 18:44 
modules-qemux86-64-release-1.tgz
51666555 -rw-r--r--  3 bitbake bitbake 7.0M Aug 15 18:44 
modules-qemux86-64-release-2.tgz
51666555 -rw-r--r--  3 bitbake bitbake 7.0M Aug 15 18:44 modules-qemux86-64.tgz
51666556 -rw-r--r--  3 bitbake bitbake 7.6M Aug 15 18:44 bzImage-qemux86-64.bin
51666556 -rw-r--r--  3 bitbake bitbake 7.6M Aug 15 18:44 
bzImage-qemux86-64-release-1.bin
51666556 -rw-r--r--  3 bitbake bitbake 7.6M Aug 15 18:44 
bzImage-qemux86-64-release-2.bin
51666557 lrwxrwxrwx  1 bitbake bitbake   22 Aug 15 18:44 bzImage -> 
bzImage-qemux86-64.bin

The following changes since commit 59938780e7e776d87146002ea939b185f8704408:

  build-appliance-image: Update to master head revision (2019-10-09 22:28:44 
+0100)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib jansa/artifacts
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=jansa/artifacts

Martin Jansa (6):
  image-artifact-names: introduce new bbclass and move some variables
into it
  bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in
the _LINK_NAME variables and change it to hard link
  kernel-artifact-names.bbclass: use PR instead of PKGR in
KERNEL_ARTIFACT_NAME
  kernel.bbclass: imageType without {}
  kernel.bbclass: drop unnecessary package_get_auto_pr for do_install
  *-artifact-names: include version only in the artifact links

 meta/classes/buildhistory.bbclass  |  2 +
 meta/classes/cve-check.bbclass |  4 +-
 meta/classes/image-artifact-names.bbclass  | 15 +++
 meta/classes/image-live.bbclass|  2 +-
 meta/classes/image.bbclass | 10 ++---
 meta/classes/image_types.bbclass   |  9 +---
 meta/classes/kernel-artifact-names.bbclass | 12 +-
 meta/classes/kernel-devicetree.bbclass | 21 --
 meta/classes/kernel.bbclass| 49 +++---
 meta/classes/qemuboot.bbclass  |  4 +-
 meta/classes/rootfs-postcommands.bbclass   |  6 ++-
 meta/classes/testimage.bbclass |  2 +
 meta/conf/bitbake.conf |  5 ---
 13 files changed, 97 insertions(+), 44 deletions(-)
 create mode 100644 meta/classes/image-artifact-names.bbclass

-- 
2.17.1

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


[OE-core] [PATCH][RESEND 2/6] bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in the _LINK_NAME variables and change it to hard link

2019-10-12 Thread Martin Jansa
* just RFC, the part for images isn't finished yet and there is
  still some issue with DATETIME when kernel artifacts are used
  from sstate, this is just to validate the idea behind
  [YOCTO #12937] before finishing the implementation (it's already
  finished and used by various LGE builds, but having simpler
  way of doing it directly in oe-core mighe be useful for others).

* move IMAGE_VERSION_SUFFIX from _NAME variables to _LINK_NAME
  that way e.g. kernel.do_deploy can be reused from sstate to
  provide "version-less" artifacts and then very fast
  do_deploy_links task just adds links with consistent suffixes
  (by default the version from the recipe but could be easily set
  to e.g. some release name when building some products).
* create hard links instead of symlinks, so that whatever version
  the filename says is really there
* some IMAGE_FSTYPES might need the "version-less" IMAGE_NAME file
  to be removed first or they might either append or update the
  content of the image instead of creating new image file from
  scratch - I have seen this only with one proprietary format we
  generate with our own tool, so hopefully this isn't very common
* this is basically the mechanism are using in webOS with
  WEBOS_IMAGE_NAME_SUFFIX which is for official builds set from
  jenkins job and then all artifacts (images as well as corresponding
  kernel files) have the same version string)

* without this, you can still easily set the variables to contain
  the version from jenkins job (excluded from sstate signature like
  DATETIME currently is to prevent rebuilding it everytime even when
  the content didn't change) but then when kernel is reused from sstate
  you can have version 1.0 used on kernel artifacts and 2.0 on image
  artifacts.

* if you don't exclude the version string with vardepsexclude, then
  you get the right version in the filenames but for cost of
  re-executing do_deploy every single time, which with rm_work will
  cause all kernel tasks to be re-executed (together with everything
  which depends on it like external modules etc).

* the implementation "from outside" is a bit tricky as shown in webOS
  OSE, because first you need to reverse the meaning of IMAGE_NAME
  and IMAGE_LINK_NAME like here, but also replace all symlinks with
  hardlinks and then adjust all recipes/bbclasses to depend on our
  do_deploy_fixup task instead of the original do_deploy
  see the variable modifications:
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/conf/distro/include/webos.inc#L65
  and then various bbclasses to hook do_webos_deploy_fixup task creating
  the hardlinks for possible artifacts:
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/webos_deploy.bbclass
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/kernel.bbclass
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/image.bbclass
  so hopefully with all these changes in oe-core other project can
  achieve the same just by setting one variable IMAGE_VERSION_SUFFIX

[YOCTO #12937]

Signed-off-by: Martin Jansa 

kernel
---
 meta/classes/cve-check.bbclass |  4 +-
 meta/classes/image-artifact-names.bbclass  |  4 +-
 meta/classes/image.bbclass | 10 ++---
 meta/classes/kernel-artifact-names.bbclass |  4 +-
 meta/classes/kernel-devicetree.bbclass | 21 +--
 meta/classes/kernel.bbclass| 43 --
 meta/classes/qemuboot.bbclass  |  2 +-
 meta/classes/rootfs-postcommands.bbclass   |  4 +-
 8 files changed, 63 insertions(+), 29 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index c00d2910be..19ef51eb05 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -100,10 +100,10 @@ python cve_check_write_rootfs_manifest () {
 
 if manifest_name and os.path.exists(manifest_name):
 manifest_link = os.path.join(deploy_dir, "%s.cve" % link_name)
-# If we already have another manifest, update symlinks
+# If we already have another manifest, update hardlinks
 if os.path.exists(os.path.realpath(manifest_link)):
 os.remove(manifest_link)
-os.symlink(os.path.basename(manifest_name), manifest_link)
+os.link(manifest_name, manifest_link)
 bb.plain("Image CVE report stored in: %s" % manifest_name)
 }
 
diff --git a/meta/classes/image-artifact-names.bbclass 
b/meta/classes/image-artifact-names.bbclass
index 5ab8f1b7aa..d5ba035f5a 100644
--- a/meta/classes/image-artifact-names.bbclass
+++ b/meta/classes/image-artifact-names.bbclass
@@ -5,8 +5,8 @@
 IMAGE_BASENAME = "${PN}"
 IMAGE_VERSION_SUFFIX = "-${DATETIME}

[OE-core] [PATCH][RESEND 3/6] kernel-artifact-names.bbclass: use PR instead of PKGR in KERNEL_ARTIFACT_NAME

2019-10-12 Thread Martin Jansa
* otherwise PKGR seen in do_install, do_deploy and do_deploy_links will
  have different value in each of them (PRSERV will return different
  value of EXTENDPRAUTO because TASKHASH is different for each of these
  tasks and also cause unnecessary multiple EXTENDPRAUTO increments for
  each build).

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/kernel-artifact-names.bbclass | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-artifact-names.bbclass 
b/meta/classes/kernel-artifact-names.bbclass
index 529e0c565e..41ef6e884d 100644
--- a/meta/classes/kernel-artifact-names.bbclass
+++ b/meta/classes/kernel-artifact-names.bbclass
@@ -6,7 +6,12 @@
 
 inherit image-artifact-names
 
-KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}"
+# Intentionally use PR instead of PKGR, because EXTENDPRAUTO included
+# in PKGR will have different value for do_install/do_deploy/do_deploy_links
+# tasks with different TASKHASH, causing multiple EXTENDPRAUTO increments for
+# each kernel build and more importantly preventing do_deploy_links to
+# reference artifacts created do_deploy task
+KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PR}-${MACHINE}"
 KERNEL_ARTIFACT_LINK_NAME ?= "${KERNEL_ARTIFACT_NAME}${IMAGE_VERSION_SUFFIX}"
 
 KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
-- 
2.17.1

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


[OE-core] [PATCH][RESEND 6/6] *-artifact-names: include version only in the artifact links

2019-10-12 Thread Martin Jansa
* drop ${PKGE}-${PKGV}-${PR} from kernel artifacts names (this is the
  latest build) and add it only in hardlinks created in do_deploy_links
  so that we can use PKGR there again (because these links are generally
  used only by human operators and they don't have their own TASKHASH or
  the IMAGE_VERSION_SUFFIX might be set to some release name which they
  do understand

* this allows to drop package_get_auto_pr from kernel do_deploy as well,
  leaving only 2 EXTENDPRAUTO bumps for each kernel build (do_package
  and do_deploy_links, unfortunatelly these will still have different
  value, so if you're looking for the exact kernel image in deploy
  directory based on kernel image package version seen on the device the
  EXTENDPRAUTO part of PR will be different).

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/image-artifact-names.bbclass  | 2 +-
 meta/classes/kernel-artifact-names.bbclass | 7 +--
 meta/classes/kernel.bbclass| 1 -
 3 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/meta/classes/image-artifact-names.bbclass 
b/meta/classes/image-artifact-names.bbclass
index d5ba035f5a..b23cef22ca 100644
--- a/meta/classes/image-artifact-names.bbclass
+++ b/meta/classes/image-artifact-names.bbclass
@@ -3,7 +3,7 @@
 ##
 
 IMAGE_BASENAME = "${PN}"
-IMAGE_VERSION_SUFFIX = "-${DATETIME}"
+IMAGE_VERSION_SUFFIX = "${PKGE}-${PKGV}-${PKGR}-${DATETIME}"
 IMAGE_VERSION_SUFFIX[vardepsexclude] += "DATETIME"
 IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}"
 IMAGE_LINK_NAME = "${IMAGE_NAME}${IMAGE_VERSION_SUFFIX}"
diff --git a/meta/classes/kernel-artifact-names.bbclass 
b/meta/classes/kernel-artifact-names.bbclass
index 41ef6e884d..92e08297cc 100644
--- a/meta/classes/kernel-artifact-names.bbclass
+++ b/meta/classes/kernel-artifact-names.bbclass
@@ -6,12 +6,7 @@
 
 inherit image-artifact-names
 
-# Intentionally use PR instead of PKGR, because EXTENDPRAUTO included
-# in PKGR will have different value for do_install/do_deploy/do_deploy_links
-# tasks with different TASKHASH, causing multiple EXTENDPRAUTO increments for
-# each kernel build and more importantly preventing do_deploy_links to
-# reference artifacts created do_deploy task
-KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PR}-${MACHINE}"
+KERNEL_ARTIFACT_NAME ?= "${MACHINE}"
 KERNEL_ARTIFACT_LINK_NAME ?= "${KERNEL_ARTIFACT_NAME}${IMAGE_VERSION_SUFFIX}"
 
 KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8003d0a929..c807b88600 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -702,7 +702,6 @@ kernel_do_deploy() {
 }
 do_deploy[cleandirs] = "${DEPLOYDIR}"
 do_deploy[dirs] = "${DEPLOYDIR} ${B}"
-do_deploy[prefuncs] += "package_get_auto_pr"
 
 addtask deploy after do_populate_sysroot do_packagedata
 
-- 
2.17.1

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


[OE-core] [PATCH][RESEND 1/6] image-artifact-names: introduce new bbclass and move some variables into it

2019-10-12 Thread Martin Jansa
* similar to kernel-artifact-names for other recipes/bbclasses which
  need to use some deployed artifacts

* bitbake.conf: move IMAGE_BASENAME, IMAGE_VERSION_SUFFIX, IMAGE_NAME,
  IMAGE_LINK_NAME variables

* image_types.bbclass: move IMAGE_NAME_SUFFIX variable

* currently IMAGE_NAME_SUFFIX is used only by image.bbclass,
  image_types.bbclass and 
meta/recipes-core/images/build-appliance-image_15.0.0.bb
  but if it's needed by some recipe which isn't itself an image, then
  it's useful in bitbake.conf, e.g. we have a recipe for creating
  VirtualBox appliances which combines .wic.vmdk with .ovf file to
  create .zip with appliance, but for that we need the filename of
  .wic.vmdk which now contains IMAGE_NAME_SUFFIX
  
https://github.com/webOS-ports/meta-webos-ports/blob/4980ce52a43ac6897657602810313af359f0b839/meta-luneos/recipes-core/images/luneos-emulator-appliance.inc#L24

* we were hardcoding .rootfs suffix where needed, but for quite long
  time it's configurable with IMAGE_NAME_SUFFIX since:

  commit 380ee36811939d947024bf78de907e3c071b834f
  Author: Patrick Ohly 
  Date:   Mon Mar 7 18:07:52 2016 +0100

image creation: allow overriding .rootfs suffix

  and might not match with hardcoded .rootfs, so make it easier to
  use IMAGE_NAME_SUFFIX where needed even without inheritting whole
  image_types.bbclass

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/buildhistory.bbclass  |  2 ++
 meta/classes/image-artifact-names.bbclass  | 15 +++
 meta/classes/image-live.bbclass|  2 +-
 meta/classes/image_types.bbclass   |  9 ++---
 meta/classes/kernel-artifact-names.bbclass |  8 
 meta/classes/qemuboot.bbclass  |  2 ++
 meta/classes/rootfs-postcommands.bbclass   |  2 ++
 meta/classes/testimage.bbclass |  2 ++
 meta/conf/bitbake.conf |  5 -
 9 files changed, 34 insertions(+), 13 deletions(-)
 create mode 100644 meta/classes/image-artifact-names.bbclass

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index f986f7c794..fb244bc04e 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -7,6 +7,8 @@
 # Copyright (C) 2007-2011 Koen Kooi 
 #
 
+inherit image-artifact-names
+
 BUILDHISTORY_FEATURES ?= "image package sdk"
 BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
 BUILDHISTORY_DIR_IMAGE = 
"${BUILDHISTORY_DIR}/images/${MACHINE_ARCH}/${TCLIBC}/${IMAGE_BASENAME}"
diff --git a/meta/classes/image-artifact-names.bbclass 
b/meta/classes/image-artifact-names.bbclass
new file mode 100644
index 00..5ab8f1b7aa
--- /dev/null
+++ b/meta/classes/image-artifact-names.bbclass
@@ -0,0 +1,15 @@
+##
+# Specific image creation and rootfs population info.
+##
+
+IMAGE_BASENAME = "${PN}"
+IMAGE_VERSION_SUFFIX = "-${DATETIME}"
+IMAGE_VERSION_SUFFIX[vardepsexclude] += "DATETIME"
+IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
+
+# IMAGE_NAME is the base name for everything produced when building images.
+# The actual image that contains the rootfs has an additional suffix (.rootfs
+# by default) followed by additional suffices which describe the format (.ext4,
+# .ext4.xz, etc.).
+IMAGE_NAME_SUFFIX ??= ".rootfs"
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index 54058b350d..9ea5ddc312 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -22,7 +22,7 @@
 # ${HDDIMG_ID} - FAT image volume-id
 # ${ROOTFS} - indicates a filesystem image to include as the root filesystem 
(optional)
 
-inherit live-vm-common
+inherit live-vm-common image-artifact-names
 
 do_bootimg[depends] += "dosfstools-native:do_populate_sysroot \
 mtools-native:do_populate_sysroot \
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2eeffbb366..a6d42c03e4 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -1,9 +1,3 @@
-# IMAGE_NAME is the base name for everything produced when building images.
-# The actual image that contains the rootfs has an additional suffix (.rootfs
-# by default) followed by additional suffices which describe the format (.ext4,
-# .ext4.xz, etc.).
-IMAGE_NAME_SUFFIX ??= ".rootfs"
-
 # The default aligment of the size of the rootfs is set to 1KiB. In case
 # you're using the SD card emulation of a QEMU system simulator you may
 # set this value to 2048 (2MiB alignment).
@@ -229,7 +223,8 @@ IMAGE_CMD_f2fs () {
 
 EXTRA_IMAGECMD = ""
 
-inherit siteinfo kernel-arch
+inherit siteinfo kernel-arch image-artifact-names
+
 JFFS2_ENDIANNESS ?= "${@oe.utils.conditional('SITEINF

[OE-core] [PATCH][RESEND 5/6] kernel.bbclass: drop unnecessary package_get_auto_pr for do_install

2019-10-12 Thread Martin Jansa
* do_install doesn't use whole "version" as do_deploy does, e.g.
  ${PKGE}-${PKGV}-${PKGR}-${MACHINE}
  it installs only the files with only ${KERNEL_VERSION} in filename or
  path, so it doesn't need expanded AUTOINC value in PKGV nor
  EXPANDPRAUTO in PKGR like do_deploy does

* it was introduced in
  
http://git.openembedded.org/openembedded-core/commit/?id=1392f959cb8cd50b5a4492899e54f3ed68ef56d7
  but it's not clear why it was needed back then, but doesn't seem to be
  useful at all currently, only causes multiple EXTENDPRAUTO bumps every
  time different linux-yocto is being built.

* There are currently 4 EXTENDPRAUTO bumps during each build as shown in
  prserv:

  $ sqlite3 cache/prserv.sqlite3
SQLite version 3.27.2 2019-02-25 16:06:06
Enter ".help" for usage hints.
sqlite> select * from PRMAIN_nohist where version like 'linux-yocto-dev%';

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|20601304a6e4fa0b7ac13fa1262040c976c862d177077799dc15492215fa51df|0

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|2820d331b7eba5165943bc016a1c274d42e7605e24244873b15cc1c9c6f657e2|1

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|4f29da98c268aa5bf1c4767bb2bb157fc6077b1d76dfd434028b18bf3252e0c0|2

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|23d8d17b23bc6db1dd7f0f30086f0ec6ade2b2180e787a78d89b6e43b8c4fad6|3

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|2a23d8783f794b3e79b438889ec60661ca635f9ec09d0519176a31d832377f1c|0

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|dafc2a636e7e18357b7efbf99981af45234105c3f46b056edfd2142d5a5d4993|1

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|09798369f303700fb8d42550d959e310a05fb4573b71646df51acc00d3a6fe89|2

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|dab07eb869034df28be59ae13914989ab88bdca5a9a9362ca96b4eb38180afd7|3

  the TASKHASHes correspond to do_install, do_package, do_deploy, 
do_deploy_links tasks:
  $ ls 
tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_*sigdata*{2a23d8783f794b3e79b438889ec60661ca635f9ec09d0519176a31d832377f1c,dafc2a636e7e18357b7efbf99981af45234105c3f46b056edfd2142d5a5d4993,09798369f303700fb8d42550d959e310a05fb4573b71646df51acc00d3a6fe89,dab07eb869034df28be59ae13914989ab88bdca5a9a9362ca96b4eb38180afd7}*

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_install.sigdata.2a23d8783f794b3e79b438889ec60661ca635f9ec09d0519176a31d832377f1c

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_package.sigdata.dafc2a636e7e18357b7efbf99981af45234105c3f46b056edfd2142d5a5d4993

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_deploy.sigdata.09798369f303700fb8d42550d959e310a05fb4573b71646df51acc00d3a6fe89

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_deploy_links.sigdata.dab07eb869034df28be59ae13914989ab88bdca5a9a9362ca96b4eb38180afd7

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/kernel.bbclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e8ee556f93..8003d0a929 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -385,7 +385,6 @@ kernel_do_install() {
install -d ${D}${sysconfdir}/modules-load.d
install -d ${D}${sysconfdir}/modprobe.d
 }
-do_install[prefuncs] += "package_get_auto_pr"
 
 # Must be ran no earlier than after do_kernel_checkout or else Makefile won't 
be in ${S}/Makefile
 do_kernel_version_sanity_check() {
-- 
2.17.1

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


[OE-core] [PATCH][RESEND 4/6] kernel.bbclass: imageType without {}

2019-10-12 Thread Martin Jansa
* just to make sure it looks like bash variable not bitbake variable in
  run.do_* scripts

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/kernel.bbclass | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index beced6fc6e..e8ee556f93 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -373,9 +373,9 @@ kernel_do_install() {
install -d ${D}/${KERNEL_IMAGEDEST}
install -d ${D}/boot
for imageType in ${KERNEL_IMAGETYPES} ; do
-   install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
+   install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType 
${D}/${KERNEL_IMAGEDEST}/$imageType-${KERNEL_VERSION}
if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
-   ln -sf ${imageType}-${KERNEL_VERSION} 
${D}/${KERNEL_IMAGEDEST}/${imageType}
+   ln -sf $imageType-${KERNEL_VERSION} 
${D}/${KERNEL_IMAGEDEST}/$imageType
fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
@@ -683,8 +683,8 @@ kernel_do_deploy() {
fi
 
for imageType in ${KERNEL_IMAGETYPES} ; do
-   install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
$deployDir/${imageType}-${KERNEL_IMAGE_NAME}.bin
-   ln -sf ${imageType}-${KERNEL_IMAGE_NAME}.bin 
$deployDir/${imageType}
+   install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType 
$deployDir/$imageType-${KERNEL_IMAGE_NAME}.bin
+   ln -sf $imageType-${KERNEL_IMAGE_NAME}.bin $deployDir/$imageType
done
 
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e 
'^CONFIG_MODULES=y$' .config); then
@@ -697,7 +697,7 @@ kernel_do_deploy() {
if [ "$imageType" = "fitImage" ] ; then
continue
fi
-   install -m 0644 
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs 
$deployDir/${imageType}-${INITRAMFS_NAME}.bin
+   install -m 0644 
${KERNEL_OUTPUT_DIR}/$imageType.initramfs 
$deployDir/$imageType-${INITRAMFS_NAME}.bin
done
fi
 }
@@ -715,7 +715,7 @@ kernel_do_deploy_links() {
fi
 
for imageType in ${KERNEL_IMAGETYPES} ; do
-   ln -vf $deployDir/${imageType}-${KERNEL_IMAGE_NAME}.bin 
$deployDir/${imageType}-${KERNEL_IMAGE_LINK_NAME}.bin
+   ln -vf $deployDir/$imageType-${KERNEL_IMAGE_NAME}.bin 
$deployDir/$imageType-${KERNEL_IMAGE_LINK_NAME}.bin
done
 
if [ ${MODULE_TARBALL_DEPLOY} = "1" -a -f 
$deployDir/modules-${MODULE_TARBALL_NAME}.tgz ] ; then
@@ -727,7 +727,7 @@ kernel_do_deploy_links() {
if [ "$imageType" = "fitImage" ] ; then
continue
fi
-   ln -vf $deployDir/${imageType}-${INITRAMFS_NAME}.bin 
$deployDir/${imageType}-${INITRAMFS_LINK_NAME}.bin
+   ln -vf $deployDir/$imageType-${INITRAMFS_NAME}.bin 
$deployDir/$imageType-${INITRAMFS_LINK_NAME}.bin
done
fi
 }
-- 
2.17.1

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


Re: [OE-core] [warrior] 0/8] Patch review

2019-10-06 Thread Martin Jansa
Can you please add:
http://git.openembedded.org/openembedded-core/commit/?id=f7a470531d4bcc2888cbb9a7b197b86174f3aba2

it does apply cleanly in warrior.

Thanks

On Sun, Oct 6, 2019 at 5:24 PM Armin Kuster  wrote:

> Next series to review.
>
> Please comment by Monday.
> All these have already been sent to the list so short review period.
>
>
> The following changes since commit
> acc0f4a6a99fe9367e57a5c2a4f995b6f4db4a9f:
>
>   runqemu: Add support for kvm on aarch64 (2019-10-01 10:48:46 +0100)
>
> are available in the git repository at:
>
>   git://git.openembedded.org/openembedded-core-contrib stable/warrior-nmut
>   http://cgit.openembedded.org//log/?h=stable/warrior-nmut
>
> Adrian Bunk (1):
>   json-c: Don't --enable-rdrand
>
> Alexander Kanavin (1):
>   python: update to 3.7.3
>
> Andrii Bordunov via Openembedded-core (1):
>   classes/image-live.bbclass: Don't hardcode cpio.gz
>
> Anuj Mittal (1):
>   python3: upgrade 3.7.3 -> 3.7.4
>
> Armin Kuster (2):
>   qemu: Fix CVE-2019-8934
>   qemu: fix build issue on new hosts with glibc 2.30
>
> Dan Tran (1):
>   unzip: Fix CVE-2019-13232
>
> Jan Klare (1):
>   systemd: update SRCREV for systemd v241-stable
>
>  meta/classes/image-live.bbclass|   2 +-
>  meta/recipes-core/systemd/systemd.inc  |   2 +-
>  meta/recipes-devtools/json-c/json-c_0.13.1.bb  |   2 -
>  ...ysconfig-append-STAGING_LIBDIR-python-sys.patch |   2 +-
>  ...2-distutils-prefix-is-inside-staging-area.patch |   2 +-
>  .../python/python3/CVE-2018-20852.patch| 124 ---
>  .../python/python3/CVE-2019-9636.patch | 154 -
>  .../python/python3/CVE-2019-9740.patch | 151 -
>  .../python/{python3_3.7.2.bb => python3_3.7.4.bb}  |   9 +-
>  meta/recipes-devtools/qemu/qemu.inc|   3 +
>  ...nux-user-assume-__NR_gettid-always-exists.patch |  49 +++
>  ...rename-gettid-to-sys_gettid-to-avoid-clas.patch |  95 ++
>  .../recipes-devtools/qemu/qemu/CVE-2019-8934.patch | 215 +
>  .../unzip/unzip/CVE-2019-13232_p1.patch|  33 ++
>  .../unzip/unzip/CVE-2019-13232_p2.patch| 356
> +
>  .../unzip/unzip/CVE-2019-13232_p3.patch| 121 +++
>  meta/recipes-extended/unzip/unzip_6.0.bb   |   3 +
>  17 files changed, 882 insertions(+), 441 deletions(-)
>  delete mode 100644
> meta/recipes-devtools/python/python3/CVE-2018-20852.patch
>  delete mode 100644
> meta/recipes-devtools/python/python3/CVE-2019-9636.patch
>  delete mode 100644
> meta/recipes-devtools/python/python3/CVE-2019-9740.patch
>  rename meta/recipes-devtools/python/{python3_3.7.2.bb => python3_3.7.4.bb}
> (97%)
>  create mode 100644
> meta/recipes-devtools/qemu/qemu/0001-linux-user-assume-__NR_gettid-always-exists.patch
>  create mode 100644
> meta/recipes-devtools/qemu/qemu/0001-linux-user-rename-gettid-to-sys_gettid-to-avoid-clas.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2019-8934.patch
>  create mode 100644
> meta/recipes-extended/unzip/unzip/CVE-2019-13232_p1.patch
>  create mode 100644
> meta/recipes-extended/unzip/unzip/CVE-2019-13232_p2.patch
>  create mode 100644
> meta/recipes-extended/unzip/unzip/CVE-2019-13232_p3.patch
>
> --
> 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 0/6] YOCTO #12937 - Consistent naming scheme for deployed artifacts

2019-10-03 Thread Martin Jansa
Any feedback on this or does it have to wait for 3.1?

At least the last patch is a fix for regression already included in 3.0.

On Fri, Aug 23, 2019 at 8:01 AM Martin Jansa  wrote:

> Let me explain a bit what these changes do for us in LGE.
>
> We have jenkins jobs for CI as well for official releases.
>
> All built artifacts are moved from jenkins builder to fileserver after
> the build.
>
> Each jobs have some identifier which is then included in the filenames
> of all relevant build artifacts, e.g. CI jobs will add e.g. lgsvl-verf-12
> to show where it was created and what build created it (12 is
> BUILD_NUMBER from jenkins, verf is type of build, lgsvl is location).
>
> To do this you can already use IMAGE_VERSION_SUFFIX variable and add
> this as a suffix to current artifact names. But that has some bad
> limitations.
>
> A) If you keep IMAGE_VERSION_SUFFIX in do_deploy signatures, then
> the artifacts will be rebuilt even when the deploy sstate archive in
> cache is identical except tha filename. We had this for a while, but
> all CI jobs were slow, because of rebuilding kernel every single time.
>
> B) If you vardepexclude IMAGE_VERSION_SUFFIX from the tasks which use
> it, you get faster CI builds, but with inconsistent artifact names when
> kernel deploy sstate is reused, e.g. image will have lgsvl-verf-12
> but all kernel artifacts will end with lgsvl-verf-11, when the kernel
> do_deploy was reused from previously built sstate-cache
>
> It gets even worse with B) when you have some other tooling (like
> runtime testing farm) which is tasked to flash image and kernel from
> lgsvl-verf-12 and it fails to find kernel image to flash, because it's
> named differently.
>
> C) Using version-less artifacts and just storing them in different
> directories might work better, but then it would make sense to include
> IMAGE_VERSION_SUFFIX in DEPLOY_DIR_IMAGE and remove it from the actual
> files inside (with version-less symlinks pointing to them). But this is
> a bit problematic when the individual images are usually downloaded by
> BFUs over http (and they end with various identically named files for
> which they don't remember from where they came).
>
> So this was the motivation why we have this in webOS.
>
> The difference for you (most people shouldn't even notice):
>
> 1) hard links instead of symlinks in DEPLOY_DIR_IMAGE, because now the
>version is in the *_LINK_* variables and you don't want symlink with
>version release-1 pointing to file created with release-2 build.
>
> 2) do_deploy, do_rootfs can still be reused from sstate, it will restore
>the version-less artifact and then just quicky add another hardlink with
>new filename (do_deploy_links task).
>
> 3) we're using this for couple years (badly hacked into OE, because we
> didn't
>want to overlay all relevant .bbclasses, but still needed to inject
> do_deploy_links
>task dependency in multiple places) and the only issue I've noticed was
> with
>one our proprietary IMAGE_FSTYPE format which was appending to image
> file in
>DEPLOY_DIR_IMAGE if it existed before, instead of overwritting it from
> scratch -
>to fix that I've just changed fstype function to remove the file before
> creating
>it again.
>
> 4) Examples:
>All show "ls -laih DEPLOY_DIR_IMAGE | sort" to show the symlinks and
> hardlinks
>
>TMPDIR is removed between each example, except the e) and f), but
> sstate-cache
>is kept in all cases and reused where possible
>
>MODULE_TARBALL_DEPLOY = "1" is added to local.conf to have more than
> just 1
>kernel image as artifact from kernel (e.g. rpi MACHINEs have a lot of
> them with
>all the dtds).
>
> a) Current master with default values:
>
> $ ls -laih qemux86-64-master-default/  | sort
> 47054849 drwxr-xr-x 13 bitbake bitbake 4.0K Aug 16 16:37 ..
> 50735788 -rw-r--r--  1 bitbake bitbake 612K Aug 15 17:16
> grub-efi-bootx64.efi
> 50735796 drwxr-xr-x  2 bitbake bitbake 4.0K Aug 16 14:23 .
> 50741892 -rwxr-xr-x  1 bitbake bitbake  95K Aug 15 17:16
> systemd-bootx64.efi
> 52067796 -rw-r--r--  1 bitbake bitbake 7.6M Aug 16 14:22
> bzImage--5.0.19+git2+c2e34d9ab2_00638cdd8f-r0.17-qemux86-64-20190816141126.bin
> 52067797 lrwxrwxrwx  1 bitbake bitbake   78 Aug 16 14:22
> bzImage-qemux86-64.bin ->
> bzImage--5.0.19+git2+c2e34d9ab2_00638cdd8f-r0.17-qemux86-64-20190816141126.bin
> 52067798 lrwxrwxrwx  1 bitbake bitbake   78 Aug 16 14:22 bzImage ->
> bzImage--5.0.19+git2+c2e34d9ab2_00638cdd8f-r0.17-qemux86-64-20190816141126.bin
> 52067799 -rw-r--r--  1 bitbake bitbake 7.0M Aug 16 14:22
> modules--5.0.19+git2+c2e34d9ab2_00638cdd8f-r0.17-qemux86-64-20190816141126.tgz

Re: [OE-core] [”OE-core][thud][PATCH”] elfutils: CVE fix for elfutils

2019-09-23 Thread Martin Jansa
On Mon, Sep 23, 2019 at 09:14:11PM +, shuag...@gmail.com wrote:
> From: Shubham Agrawal 

Drop the quotes in the e-mail subject.

> 
> CVE: CVE-2019-7664.patch
> CVE: CVE-2019-7665.patch
> 
> Sign off: Shubham Agrawal 
> ---
>  meta/recipes-devtools/elfutils/elfutils_0.175.bb   |   2 +
>  .../elfutils/files/CVE-2019-7664.patch |  65 +
>  .../elfutils/files/CVE-2019-7665.patch | 154 
> +
>  3 files changed, 221 insertions(+)
>  create mode 100644 meta/recipes-devtools/elfutils/files/CVE-2019-7664.patch
>  create mode 100644 meta/recipes-devtools/elfutils/files/CVE-2019-7665.patch



> +diff --git a/libelf/ChangeLog b/libelf/ChangeLog
> +index 68c4fbd..892e6e7 100644
> +--- a/libelf/ChangeLog
>  b/libelf/ChangeLog
> +@@ -1,3 +1,16 @@
> ++<<< HEAD
> ++===
> ++2019-01-16  Mark Wielaard  
> ++
> ++* note_xlate.h (elf_cvt_note): Check n_namesz and n_descsz don't
> ++overflow note_len into note header.
> ++
> ++2018-11-17  Mark Wielaard  
> ++
> ++* elf32_updatefile.c (updatemmap): Make sure to call convert
> ++function on a properly aligned destination.
> ++
> ++>>> e65d91d... libelf: Correct overflow check in note_xlate.

You should resolve these conflicts (or drop the ChangeLog updates
completely from the backports as they will conflict with any other
backport as well.


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


Re: [OE-core] [PATCH] openssl: Enable os option for with-rand-seed as well

2019-09-18 Thread Martin Jansa
Thanks for fix, I was seeing these issues in couple components using
nodejs-native (example bellow) and can confirm that this is now fixed.

internal/crypto/random.js:118
  if (ex) throw ex;
  ^

Error: error:2406C06E:random number generator:RAND_DRBG_instantiate:error
retrieving entropy
at handleError (internal/crypto/random.js:117:14)
at Object.randomBytes (internal/crypto/random.js:52:19)
at
TOPDIR/BUILD/work/x86_64-linux/node-gyp-native/0.12.2+gitAUTOINC+7e98c99ce7-r4/recipe-sysroot-native/usr/lib/node_modules/npm/lib/npm.js:424:32
at Object.
(TOPDIR/BUILD/work/x86_64-linux/node-gyp-native/0.12.2+gitAUTOINC+7e98c99ce7-r4/recipe-sysroot-native/usr/lib/node_modules/npm/lib/npm.js:476:3)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)

On Tue, Sep 17, 2019 at 8:50 PM Khem Raj  wrote:

> with openSSL 1.1.1d we start seeing errors like
>
> Error Generating Key
> 139979727451584:error:2406C06E:random number
> generator:RAND_DRBG_instantiate:error retrieving
> entropy:../openssl-1.1.1d/crypto/rand/drbg_lib.c:342:
>
> when using openssl from openssl-native on build hosts, this is due to
> limiting the random seed to devrandom, to support older hosts, since the
> option allows to have a comma separated list of methods to try, we can
> try the default first and if that fails then fallback to devrandom, this
> will ensure that it keeps working with build systems which dont support
> getrandom()
>
> Signed-off-by: Khem Raj 
> Cc: Adrian Bunk 
> Cc: Alexander Kanavin 
> ---
>  meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> index 080d1a8bb7..072f727e0b 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
> @@ -43,10 +43,10 @@ do_configure[cleandirs] = "${B}"
>  EXTRA_OECONF_append_libc-musl = " no-async"
>  EXTRA_OECONF_append_libc-musl_powerpc64 = " no-asm"
>
> -# This prevents openssl from using getrandom() which is not available on
> older glibc versions
> +# adding devrandom prevents openssl from using getrandom() which is not
> available on older glibc versions
>  # (native versions can be built with newer glibc, but then relocated onto
> a system with older glibc)
> -EXTRA_OECONF_class-native = "--with-rand-seed=devrandom"
> -EXTRA_OECONF_class-nativesdk = "--with-rand-seed=devrandom"
> +EXTRA_OECONF_class-native = "--with-rand-seed=os,devrandom"
> +EXTRA_OECONF_class-nativesdk = "--with-rand-seed=os,devrandom"
>
>  # Relying on hardcoded built-in paths causes openssl-native to not be
> relocateable from sstate.
>  CFLAGS_append_class-native = " -DOPENSSLDIR=/not/builtin
> -DENGINESDIR=/not/builtin"
> --
> 2.23.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


[OE-core] [PATCH] perf: fix build on kernels which don't have ${S}/tools/include/linux/bits.h

2019-09-13 Thread Martin Jansa
* tools/include/linux/bits.h was added in v4.20-rc1 with this commit:
  commit ba4aa02b417f08a0bee5e7b8ed70cac788a7c854
  Author: Arnaldo Carvalho de Melo 
  Date:   Tue Sep 25 10:55:59 2018 -0300

tools include: Adopt linux/bits.h

* also if you're building for such older kernel you will probably see
  do_compile failing with:
  | config/Makefile:448: Missing perl devel files. Disabling perl scripting 
support, please install perl-ExtUtils-Embed/libperl-dev
  | config/Makefile:495: Python 3 is not yet supported; please set
  | config/Makefile:496: PYTHON and/or PYTHON_CONFIG appropriately.

  easiest work around is to disable scripting PACKAGECONFIG, because
  since oe-core commit:

  commit 584af667e129bcb5c9e8108485f2f6590eaf
  Author: Bruce Ashfield 
  Date:   Wed Aug 28 22:14:41 2019 -0400

perf: change dependencies on python to python3

The upstream kernel can now handle python3 for the perf scripts, coupled
with the impending EOL of python2, we switch the dependencies in perf
(scripting) to python3.

  it now uses python3, but the support for that was added in kernel
  v4.17-rc1 with:

  commit 66dfdff03d196e51322c6a85c0d8db8bb2bdd655
  Author: Jaroslav Skarvada 
  Date:   Fri Jan 19 21:56:41 2018 +0100

perf tools: Add Python 3 support

Added Python 3 support while keeping Python 2.7 compatibility.

  if you really need scripting support than either backport the kernel
  patch to your kernel or undo the perf recipe changes.

Signed-off-by: Martin Jansa 
---
 meta/recipes-kernel/perf/perf.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 7f00df0f8e..8201c0cb60 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -244,8 +244,8 @@ do_configure_prepend () {
 install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
${S}/tools/include/uapi/asm-generic/unistd.h
 install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
${S}/include/uapi/asm-generic/unistd.h
 
-# bits.h can have the same issuen as unistd.h, so we make the tools 
variant take precedence
-install -D -m0644 ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
+# bits.h can have the same issue as unistd.h, so we make the tools variant 
take precedence
+[ -e ${S}/tools/include/linux/bits.h ] && install -D -m0644 
${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
 }
 
 python do_package_prepend() {
-- 
2.17.1

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


[OE-core] [PATCH 7/7] kernel-devicetree.bbclass: add missing backslash

2019-09-11 Thread Martin Jansa
* in oe-core commit 1860d9d3c62e2e94cd68a809385873ffd8270b6d I've accidentally
  removed the backshash here

Reported-By: "Hilsdorf, Jan (LAWO)" 
Signed-off-by: Martin Jansa 
---
 meta/classes/kernel-devicetree.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel-devicetree.bbclass 
b/meta/classes/kernel-devicetree.bbclass
index a45a0ce3c8..6028361f80 100644
--- a/meta/classes/kernel-devicetree.bbclass
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -81,7 +81,7 @@ do_deploy_append() {
> 
${DEPLOYDIR}/$type-$dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext.bin
if [ -e 
"${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
cat 
${KERNEL_OUTPUT_DIR}/${type}.initramfs \
-   
${DEPLOYDIR}/$dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext
+   
${DEPLOYDIR}/$dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext \
>  
${DEPLOYDIR}/${type}-${INITRAMFS_NAME}-$dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext.bin
fi
fi
-- 
2.17.1

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


Re: [OE-core] [yocto-docs][PATCH] ref-manual: mention PREPROCESS_RELOCATE_DIRS variable

2019-09-06 Thread Martin Jansa
On Mon, Aug 12, 2019 at 07:51:40PM +, Martin Jansa wrote:
> Signed-off-by: Martin Jansa 

ping

> ---
>  documentation/ref-manual/ref-classes.xml   |  5 -
>  documentation/ref-manual/ref-variables.xml | 21 +
>  2 files changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/documentation/ref-manual/ref-classes.xml 
> b/documentation/ref-manual/ref-classes.xml
> index ece47e757..159efb3b1 100644
> --- a/documentation/ref-manual/ref-classes.xml
> +++ b/documentation/ref-manual/ref-classes.xml
> @@ -413,7 +413,10 @@
>  cross, and
>  cross-canadian recipes to change
>  RPATH records within binaries in order to make
> -them relocatable.
> +them relocatable. To extend the list of directories where it searches
> +for binaries to relocate, you can set
> + linkend='var-PREPROCESS_RELOCATE_DIRS'>PREPROCESS_RELOCATE_DIRS
> +variable in your recipe.
>  
>  
>  
> diff --git a/documentation/ref-manual/ref-variables.xml 
> b/documentation/ref-manual/ref-variables.xml
> index 9470a780a..5ac766658 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -11424,6 +11424,27 @@
>  
>  
>  
> + id='var-PREPROCESS_RELOCATE_DIRS'>PREPROCESS_RELOCATE_DIRS
> +
> +PREPROCESS_RELOCATE_DIRS[doc] = "List of extra directories 
> where to search for binaries which should be relocatable."
> +
> +
> +
> +
> +List of extra directories with binaries.
> +
> +
> +
> +PREPROCESS_RELOCATE_DIRS is used by
> +chrpath.bbclass to allow extending the list where it 
> searches
> +for binaries. By default it searches in:
> +${bindir} ${sbindir} ${base_sbindir} ${base_bindir} 
> ${libdir} ${base_libdir} ${libexecdir}
> +Thus, PREPROCESS_RELOCATE_DIRS 
> usually doesn't
> +need to be set withing recipes.
> +
> +
> +
> +
>  PRIORITY
>  
>  PRIORITY[doc] = "Indicates the importance of a package.  The 
> default value is 'optional'.  Other standard values are 'required', 
> 'standard', and 'extra'."
> -- 
> 2.17.1
> 

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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 4/6] kernel.bbclass: imageType without {}

2019-08-23 Thread Martin Jansa
* just to make sure it looks like bash variable not bitbake variable in
  run.do_* scripts

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/kernel.bbclass | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index bd7f7131a4..8046a69d83 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -371,9 +371,9 @@ kernel_do_install() {
install -d ${D}/${KERNEL_IMAGEDEST}
install -d ${D}/boot
for imageType in ${KERNEL_IMAGETYPES} ; do
-   install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
+   install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType 
${D}/${KERNEL_IMAGEDEST}/$imageType-${KERNEL_VERSION}
if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
-   ln -sf ${imageType}-${KERNEL_VERSION} 
${D}/${KERNEL_IMAGEDEST}/${imageType}
+   ln -sf $imageType-${KERNEL_VERSION} 
${D}/${KERNEL_IMAGEDEST}/$imageType
fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
@@ -681,8 +681,8 @@ kernel_do_deploy() {
fi
 
for imageType in ${KERNEL_IMAGETYPES} ; do
-   install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
$deployDir/${imageType}-${KERNEL_IMAGE_NAME}.bin
-   ln -sf ${imageType}-${KERNEL_IMAGE_NAME}.bin 
$deployDir/${imageType}
+   install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType 
$deployDir/$imageType-${KERNEL_IMAGE_NAME}.bin
+   ln -sf $imageType-${KERNEL_IMAGE_NAME}.bin $deployDir/$imageType
done
 
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e 
'^CONFIG_MODULES=y$' .config); then
@@ -695,7 +695,7 @@ kernel_do_deploy() {
if [ "$imageType" = "fitImage" ] ; then
continue
fi
-   install -m 0644 
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs 
$deployDir/${imageType}-${INITRAMFS_NAME}.bin
+   install -m 0644 
${KERNEL_OUTPUT_DIR}/$imageType.initramfs 
$deployDir/$imageType-${INITRAMFS_NAME}.bin
done
fi
 }
@@ -713,7 +713,7 @@ kernel_do_deploy_links() {
fi
 
for imageType in ${KERNEL_IMAGETYPES} ; do
-   ln -vf $deployDir/${imageType}-${KERNEL_IMAGE_NAME}.bin 
$deployDir/${imageType}-${KERNEL_IMAGE_LINK_NAME}.bin
+   ln -vf $deployDir/$imageType-${KERNEL_IMAGE_NAME}.bin 
$deployDir/$imageType-${KERNEL_IMAGE_LINK_NAME}.bin
done
 
if [ ${MODULE_TARBALL_DEPLOY} = "1" -a -f 
$deployDir/modules-${MODULE_TARBALL_NAME}.tgz ] ; then
@@ -725,7 +725,7 @@ kernel_do_deploy_links() {
if [ "$imageType" = "fitImage" ] ; then
continue
fi
-   ln -vf $deployDir/${imageType}-${INITRAMFS_NAME}.bin 
$deployDir/${imageType}-${INITRAMFS_LINK_NAME}.bin
+   ln -vf $deployDir/$imageType-${INITRAMFS_NAME}.bin 
$deployDir/$imageType-${INITRAMFS_LINK_NAME}.bin
done
fi
 }
-- 
2.17.1

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


[OE-core] [PATCH 6/6] *-artifact-names: include version only in the artifact links

2019-08-23 Thread Martin Jansa
* drop ${PKGE}-${PKGV}-${PR} from kernel artifacts names (this is the
  latest build) and add it only in hardlinks created in do_deploy_links
  so that we can use PKGR there again (because these links are generally
  used only by human operators and they don't have their own TASKHASH or
  the IMAGE_VERSION_SUFFIX might be set to some release name which they
  do understand

* this allows to drop package_get_auto_pr from kernel do_deploy as well,
  leaving only 2 EXTENDPRAUTO bumps for each kernel build (do_package
  and do_deploy_links, unfortunatelly these will still have different
  value, so if you're looking for the exact kernel image in deploy
  directory based on kernel image package version seen on the device the
  EXTENDPRAUTO part of PR will be different).

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/image-artifact-names.bbclass  | 2 +-
 meta/classes/kernel-artifact-names.bbclass | 7 +--
 meta/classes/kernel.bbclass| 1 -
 3 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/meta/classes/image-artifact-names.bbclass 
b/meta/classes/image-artifact-names.bbclass
index d5ba035f5a..b23cef22ca 100644
--- a/meta/classes/image-artifact-names.bbclass
+++ b/meta/classes/image-artifact-names.bbclass
@@ -3,7 +3,7 @@
 ##
 
 IMAGE_BASENAME = "${PN}"
-IMAGE_VERSION_SUFFIX = "-${DATETIME}"
+IMAGE_VERSION_SUFFIX = "${PKGE}-${PKGV}-${PKGR}-${DATETIME}"
 IMAGE_VERSION_SUFFIX[vardepsexclude] += "DATETIME"
 IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}"
 IMAGE_LINK_NAME = "${IMAGE_NAME}${IMAGE_VERSION_SUFFIX}"
diff --git a/meta/classes/kernel-artifact-names.bbclass 
b/meta/classes/kernel-artifact-names.bbclass
index 41ef6e884d..92e08297cc 100644
--- a/meta/classes/kernel-artifact-names.bbclass
+++ b/meta/classes/kernel-artifact-names.bbclass
@@ -6,12 +6,7 @@
 
 inherit image-artifact-names
 
-# Intentionally use PR instead of PKGR, because EXTENDPRAUTO included
-# in PKGR will have different value for do_install/do_deploy/do_deploy_links
-# tasks with different TASKHASH, causing multiple EXTENDPRAUTO increments for
-# each kernel build and more importantly preventing do_deploy_links to
-# reference artifacts created do_deploy task
-KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PR}-${MACHINE}"
+KERNEL_ARTIFACT_NAME ?= "${MACHINE}"
 KERNEL_ARTIFACT_LINK_NAME ?= "${KERNEL_ARTIFACT_NAME}${IMAGE_VERSION_SUFFIX}"
 
 KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index df203d2b4f..3a3400da87 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -700,7 +700,6 @@ kernel_do_deploy() {
 }
 do_deploy[cleandirs] = "${DEPLOYDIR}"
 do_deploy[dirs] = "${DEPLOYDIR} ${B}"
-do_deploy[prefuncs] += "package_get_auto_pr"
 
 addtask deploy after do_populate_sysroot do_packagedata
 
-- 
2.17.1

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


[OE-core] [PATCH 2/6] bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in the _LINK_NAME variables and change it to hard link

2019-08-23 Thread Martin Jansa
* just RFC, the part for images isn't finished yet and there is
  still some issue with DATETIME when kernel artifacts are used
  from sstate, this is just to validate the idea behind
  [YOCTO #12937] before finishing the implementation (it's already
  finished and used by various LGE builds, but having simpler
  way of doing it directly in oe-core mighe be useful for others).

* move IMAGE_VERSION_SUFFIX from _NAME variables to _LINK_NAME
  that way e.g. kernel.do_deploy can be reused from sstate to
  provide "version-less" artifacts and then very fast
  do_deploy_links task just adds links with consistent suffixes
  (by default the version from the recipe but could be easily set
  to e.g. some release name when building some products).
* create hard links instead of symlinks, so that whatever version
  the filename says is really there
* some IMAGE_FSTYPES might need the "version-less" IMAGE_NAME file
  to be removed first or they might either append or update the
  content of the image instead of creating new image file from
  scratch - I have seen this only with one proprietary format we
  generate with our own tool, so hopefully this isn't very common
* this is basically the mechanism are using in webOS with
  WEBOS_IMAGE_NAME_SUFFIX which is for official builds set from
  jenkins job and then all artifacts (images as well as corresponding
  kernel files) have the same version string)

* without this, you can still easily set the variables to contain
  the version from jenkins job (excluded from sstate signature like
  DATETIME currently is to prevent rebuilding it everytime even when
  the content didn't change) but then when kernel is reused from sstate
  you can have version 1.0 used on kernel artifacts and 2.0 on image
  artifacts.

* if you don't exclude the version string with vardepsexclude, then
  you get the right version in the filenames but for cost of
  re-executing do_deploy every single time, which with rm_work will
  cause all kernel tasks to be re-executed (together with everything
  which depends on it like external modules etc).

* the implementation "from outside" is a bit tricky as shown in webOS
  OSE, because first you need to reverse the meaning of IMAGE_NAME
  and IMAGE_LINK_NAME like here, but also replace all symlinks with
  hardlinks and then adjust all recipes/bbclasses to depend on our
  do_deploy_fixup task instead of the original do_deploy
  see the variable modifications:
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/conf/distro/include/webos.inc#L65
  and then various bbclasses to hook do_webos_deploy_fixup task creating
  the hardlinks for possible artifacts:
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/webos_deploy.bbclass
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/kernel.bbclass
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/image.bbclass
  so hopefully with all these changes in oe-core other project can
  achieve the same just by setting one variable IMAGE_VERSION_SUFFIX

[YOCTO #12937]

Signed-off-by: Martin Jansa 

kernel
---
 meta/classes/cve-check.bbclass |  4 +-
 meta/classes/image-artifact-names.bbclass  |  4 +-
 meta/classes/image.bbclass | 10 ++---
 meta/classes/kernel-artifact-names.bbclass |  4 +-
 meta/classes/kernel-devicetree.bbclass | 21 +--
 meta/classes/kernel.bbclass| 43 --
 meta/classes/qemuboot.bbclass  |  2 +-
 meta/classes/rootfs-postcommands.bbclass   |  4 +-
 8 files changed, 63 insertions(+), 29 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index c00d2910be..19ef51eb05 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -100,10 +100,10 @@ python cve_check_write_rootfs_manifest () {
 
 if manifest_name and os.path.exists(manifest_name):
 manifest_link = os.path.join(deploy_dir, "%s.cve" % link_name)
-# If we already have another manifest, update symlinks
+# If we already have another manifest, update hardlinks
 if os.path.exists(os.path.realpath(manifest_link)):
 os.remove(manifest_link)
-os.symlink(os.path.basename(manifest_name), manifest_link)
+os.link(manifest_name, manifest_link)
 bb.plain("Image CVE report stored in: %s" % manifest_name)
 }
 
diff --git a/meta/classes/image-artifact-names.bbclass 
b/meta/classes/image-artifact-names.bbclass
index 5ab8f1b7aa..d5ba035f5a 100644
--- a/meta/classes/image-artifact-names.bbclass
+++ b/meta/classes/image-artifact-names.bbclass
@@ -5,8 +5,8 @@
 IMAGE_BASENAME = "${PN}"
 IMAGE_VERSION_SUFFIX = "-${DATETIME}

[OE-core] [PATCH 5/6] kernel.bbclass: drop unnecessary package_get_auto_pr for do_install

2019-08-23 Thread Martin Jansa
* do_install doesn't use whole "version" as do_deploy does, e.g.
  ${PKGE}-${PKGV}-${PKGR}-${MACHINE}
  it installs only the files with only ${KERNEL_VERSION} in filename or
  path, so it doesn't need expanded AUTOINC value in PKGV nor
  EXPANDPRAUTO in PKGR like do_deploy does

* it was introduced in
  
http://git.openembedded.org/openembedded-core/commit/?id=1392f959cb8cd50b5a4492899e54f3ed68ef56d7
  but it's not clear why it was needed back then, but doesn't seem to be
  useful at all currently, only causes multiple EXTENDPRAUTO bumps every
  time different linux-yocto is being built.

* There are currently 4 EXTENDPRAUTO bumps during each build as shown in
  prserv:

  $ sqlite3 cache/prserv.sqlite3
SQLite version 3.27.2 2019-02-25 16:06:06
Enter ".help" for usage hints.
sqlite> select * from PRMAIN_nohist where version like 'linux-yocto-dev%';

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|20601304a6e4fa0b7ac13fa1262040c976c862d177077799dc15492215fa51df|0

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|2820d331b7eba5165943bc016a1c274d42e7605e24244873b15cc1c9c6f657e2|1

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|4f29da98c268aa5bf1c4767bb2bb157fc6077b1d76dfd434028b18bf3252e0c0|2

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|23d8d17b23bc6db1dd7f0f30086f0ec6ade2b2180e787a78d89b6e43b8c4fad6|3

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|2a23d8783f794b3e79b438889ec60661ca635f9ec09d0519176a31d832377f1c|0

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|dafc2a636e7e18357b7efbf99981af45234105c3f46b056edfd2142d5a5d4993|1

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|09798369f303700fb8d42550d959e310a05fb4573b71646df51acc00d3a6fe89|2

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|dab07eb869034df28be59ae13914989ab88bdca5a9a9362ca96b4eb38180afd7|3

  the TASKHASHes correspond to do_install, do_package, do_deploy, 
do_deploy_links tasks:
  $ ls 
tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_*sigdata*{2a23d8783f794b3e79b438889ec60661ca635f9ec09d0519176a31d832377f1c,dafc2a636e7e18357b7efbf99981af45234105c3f46b056edfd2142d5a5d4993,09798369f303700fb8d42550d959e310a05fb4573b71646df51acc00d3a6fe89,dab07eb869034df28be59ae13914989ab88bdca5a9a9362ca96b4eb38180afd7}*

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_install.sigdata.2a23d8783f794b3e79b438889ec60661ca635f9ec09d0519176a31d832377f1c

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_package.sigdata.dafc2a636e7e18357b7efbf99981af45234105c3f46b056edfd2142d5a5d4993

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_deploy.sigdata.09798369f303700fb8d42550d959e310a05fb4573b71646df51acc00d3a6fe89

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_deploy_links.sigdata.dab07eb869034df28be59ae13914989ab88bdca5a9a9362ca96b4eb38180afd7

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/kernel.bbclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8046a69d83..df203d2b4f 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -383,7 +383,6 @@ kernel_do_install() {
install -d ${D}${sysconfdir}/modules-load.d
install -d ${D}${sysconfdir}/modprobe.d
 }
-do_install[prefuncs] += "package_get_auto_pr"
 
 # Must be ran no earlier than after do_kernel_checkout or else Makefile won't 
be in ${S}/Makefile
 do_kernel_version_sanity_check() {
-- 
2.17.1

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


[OE-core] [PATCH 3/6] kernel-artifact-names.bbclass: use PR instead of PKGR in KERNEL_ARTIFACT_NAME

2019-08-23 Thread Martin Jansa
* otherwise PKGR seen in do_install, do_deploy and do_deploy_links will
  have different value in each of them (PRSERV will return different
  value of EXTENDPRAUTO because TASKHASH is different for each of these
  tasks and also cause unnecessary multiple EXTENDPRAUTO increments for
  each build).

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/kernel-artifact-names.bbclass | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-artifact-names.bbclass 
b/meta/classes/kernel-artifact-names.bbclass
index 529e0c565e..41ef6e884d 100644
--- a/meta/classes/kernel-artifact-names.bbclass
+++ b/meta/classes/kernel-artifact-names.bbclass
@@ -6,7 +6,12 @@
 
 inherit image-artifact-names
 
-KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}"
+# Intentionally use PR instead of PKGR, because EXTENDPRAUTO included
+# in PKGR will have different value for do_install/do_deploy/do_deploy_links
+# tasks with different TASKHASH, causing multiple EXTENDPRAUTO increments for
+# each kernel build and more importantly preventing do_deploy_links to
+# reference artifacts created do_deploy task
+KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PR}-${MACHINE}"
 KERNEL_ARTIFACT_LINK_NAME ?= "${KERNEL_ARTIFACT_NAME}${IMAGE_VERSION_SUFFIX}"
 
 KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
-- 
2.17.1

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


[OE-core] [PATCH 1/6] image-artifact-names: introduce new bbclass and move some variables into it

2019-08-23 Thread Martin Jansa
* similar to kernel-artifact-names for other recipes/bbclasses which
  need to use some deployed artifacts

* bitbake.conf: move IMAGE_BASENAME, IMAGE_VERSION_SUFFIX, IMAGE_NAME,
  IMAGE_LINK_NAME variables

* image_types.bbclass: move IMAGE_NAME_SUFFIX variable

* currently IMAGE_NAME_SUFFIX is used only by image.bbclass,
  image_types.bbclass and 
meta/recipes-core/images/build-appliance-image_15.0.0.bb
  but if it's needed by some recipe which isn't itself an image, then
  it's useful in bitbake.conf, e.g. we have a recipe for creating
  VirtualBox appliances which combines .wic.vmdk with .ovf file to
  create .zip with appliance, but for that we need the filename of
  .wic.vmdk which now contains IMAGE_NAME_SUFFIX
  
https://github.com/webOS-ports/meta-webos-ports/blob/4980ce52a43ac6897657602810313af359f0b839/meta-luneos/recipes-core/images/luneos-emulator-appliance.inc#L24

* we were hardcoding .rootfs suffix where needed, but for quite long
  time it's configurable with IMAGE_NAME_SUFFIX since:

  commit 380ee36811939d947024bf78de907e3c071b834f
  Author: Patrick Ohly 
  Date:   Mon Mar 7 18:07:52 2016 +0100

image creation: allow overriding .rootfs suffix

  and might not match with hardcoded .rootfs, so make it easier to
  use IMAGE_NAME_SUFFIX where needed even without inheritting whole
  image_types.bbclass

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/buildhistory.bbclass  |  2 ++
 meta/classes/image-artifact-names.bbclass  | 15 +++
 meta/classes/image-live.bbclass|  2 +-
 meta/classes/image_types.bbclass   |  9 ++---
 meta/classes/kernel-artifact-names.bbclass |  8 
 meta/classes/qemuboot.bbclass  |  2 ++
 meta/classes/rootfs-postcommands.bbclass   |  2 ++
 meta/classes/testimage.bbclass |  2 ++
 meta/conf/bitbake.conf |  5 -
 9 files changed, 34 insertions(+), 13 deletions(-)
 create mode 100644 meta/classes/image-artifact-names.bbclass

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index f986f7c794..fb244bc04e 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -7,6 +7,8 @@
 # Copyright (C) 2007-2011 Koen Kooi 
 #
 
+inherit image-artifact-names
+
 BUILDHISTORY_FEATURES ?= "image package sdk"
 BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
 BUILDHISTORY_DIR_IMAGE = 
"${BUILDHISTORY_DIR}/images/${MACHINE_ARCH}/${TCLIBC}/${IMAGE_BASENAME}"
diff --git a/meta/classes/image-artifact-names.bbclass 
b/meta/classes/image-artifact-names.bbclass
new file mode 100644
index 00..5ab8f1b7aa
--- /dev/null
+++ b/meta/classes/image-artifact-names.bbclass
@@ -0,0 +1,15 @@
+##
+# Specific image creation and rootfs population info.
+##
+
+IMAGE_BASENAME = "${PN}"
+IMAGE_VERSION_SUFFIX = "-${DATETIME}"
+IMAGE_VERSION_SUFFIX[vardepsexclude] += "DATETIME"
+IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
+
+# IMAGE_NAME is the base name for everything produced when building images.
+# The actual image that contains the rootfs has an additional suffix (.rootfs
+# by default) followed by additional suffices which describe the format (.ext4,
+# .ext4.xz, etc.).
+IMAGE_NAME_SUFFIX ??= ".rootfs"
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index af71be5093..d44573efe8 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -22,7 +22,7 @@
 # ${HDDIMG_ID} - FAT image volume-id
 # ${ROOTFS} - indicates a filesystem image to include as the root filesystem 
(optional)
 
-inherit live-vm-common
+inherit live-vm-common image-artifact-names
 
 do_bootimg[depends] += "dosfstools-native:do_populate_sysroot \
 mtools-native:do_populate_sysroot \
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2eeffbb366..a6d42c03e4 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -1,9 +1,3 @@
-# IMAGE_NAME is the base name for everything produced when building images.
-# The actual image that contains the rootfs has an additional suffix (.rootfs
-# by default) followed by additional suffices which describe the format (.ext4,
-# .ext4.xz, etc.).
-IMAGE_NAME_SUFFIX ??= ".rootfs"
-
 # The default aligment of the size of the rootfs is set to 1KiB. In case
 # you're using the SD card emulation of a QEMU system simulator you may
 # set this value to 2048 (2MiB alignment).
@@ -229,7 +223,8 @@ IMAGE_CMD_f2fs () {
 
 EXTRA_IMAGECMD = ""
 
-inherit siteinfo kernel-arch
+inherit siteinfo kernel-arch image-artifact-names
+
 JFFS2_ENDIANNESS ?= "${@oe.utils.conditional('SITEINF

[OE-core] [PATCH 0/6] YOCTO #12937 - Consistent naming scheme for deployed artifacts

2019-08-23 Thread Martin Jansa
2:59 
core-image-minimal-qemux86-64-release-1.ext4
51665615 -rw-r--r--  2 bitbake bitbake  61M Aug 16 12:59 
core-image-minimal-qemux86-64.rootfs.ext4
51665617 -rw-r--r--  2 bitbake bitbake  49M Aug 16 12:59 
core-image-minimal-qemux86-64-release-1.wic.vmdk
51665617 -rw-r--r--  2 bitbake bitbake  49M Aug 16 12:59 
core-image-minimal-qemux86-64.rootfs.wic.vmdk

f) With this PR and IMAGE_VERSION_SUFFIX_forcevariable = "-release-2"
   and IMAGE_INSTALL_append = " zlib" added to force image to be recreated
   while kernel is still reused from sstate
   In this case I haven't removed TMPDIR between e) and f) to show
   that kernel artifacts are identical from previous build release-1 and just
   added another hardlink to the same inode.

$ ls -laih qemux86-64-YOCTO-12937-release-2/ | sort
47054849 drwxr-xr-x 13 bitbake bitbake 4.0K Aug 16 16:37 ..
51665409 -rw-r--r--  2 bitbake bitbake 1.3K Aug 16 13:07 
core-image-minimal-qemux86-64.qemuboot.conf
51665409 -rw-r--r--  2 bitbake bitbake 1.3K Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.qemuboot.conf
51665420 -rw-r--r--  2 bitbake bitbake 161K Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.testdata.json
51665420 -rw-r--r--  2 bitbake bitbake 161K Aug 16 13:07 
core-image-minimal-qemux86-64.testdata.json
51665422 -rw-r--r--  2 bitbake bitbake 2.2K Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.manifest
51665422 -rw-r--r--  2 bitbake bitbake 2.2K Aug 16 13:07 
core-image-minimal-qemux86-64.rootfs.manifest
51665583 -rw-r--r--  1 bitbake bitbake 1.1K Aug 16 13:07 core-image-minimal.env
51665584 -rw-r--r--  2 bitbake bitbake  61M Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.ext4
51665584 -rw-r--r--  2 bitbake bitbake  61M Aug 16 13:07 
core-image-minimal-qemux86-64.rootfs.ext4
51665585 -rw-r--r--  2 bitbake bitbake  49M Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.wic.vmdk
51665585 -rw-r--r--  2 bitbake bitbake  49M Aug 16 13:07 
core-image-minimal-qemux86-64.rootfs.wic.vmdk
51666546 drwxr-xr-x  2 bitbake bitbake 4.0K Aug 16 13:07 .
51666553 -rw-r--r--  1 bitbake bitbake 612K Aug 15 17:16 grub-efi-bootx64.efi
51666554 -rwxr-xr-x  1 bitbake bitbake  95K Aug 15 17:16 systemd-bootx64.efi
51666555 -rw-r--r--  3 bitbake bitbake 7.0M Aug 15 18:44 
modules-qemux86-64-release-1.tgz
51666555 -rw-r--r--  3 bitbake bitbake 7.0M Aug 15 18:44 
modules-qemux86-64-release-2.tgz
51666555 -rw-r--r--  3 bitbake bitbake 7.0M Aug 15 18:44 modules-qemux86-64.tgz
51666556 -rw-r--r--  3 bitbake bitbake 7.6M Aug 15 18:44 bzImage-qemux86-64.bin
51666556 -rw-r--r--  3 bitbake bitbake 7.6M Aug 15 18:44 
bzImage-qemux86-64-release-1.bin
51666556 -rw-r--r--  3 bitbake bitbake 7.6M Aug 15 18:44 
bzImage-qemux86-64-release-2.bin
51666557 lrwxrwxrwx  1 bitbake bitbake   22 Aug 15 18:44 bzImage -> 
bzImage-qemux86-64.bin

The following changes since commit 64f9fd2a1ebfad102140801f8be8b8be33082d61:

  quilt: added less to RDEPENDS list (2019-08-22 17:36:13 +0100)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib jansa/artifacts
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=jansa/artifacts

Martin Jansa (6):
  image-artifact-names: introduce new bbclass and move some variables
into it
  bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in
the _LINK_NAME variables and change it to hard link
  kernel-artifact-names.bbclass: use PR instead of PKGR in
KERNEL_ARTIFACT_NAME
  kernel.bbclass: imageType without {}
  kernel.bbclass: drop unnecessary package_get_auto_pr for do_install
  *-artifact-names: include version only in the artifact links

 meta/classes/buildhistory.bbclass  |  2 +
 meta/classes/cve-check.bbclass |  4 +-
 meta/classes/image-artifact-names.bbclass  | 15 +++
 meta/classes/image-live.bbclass|  2 +-
 meta/classes/image.bbclass | 10 ++---
 meta/classes/image_types.bbclass   |  9 +---
 meta/classes/kernel-artifact-names.bbclass | 12 +-
 meta/classes/kernel-devicetree.bbclass | 21 --
 meta/classes/kernel.bbclass| 49 +++---
 meta/classes/qemuboot.bbclass  |  4 +-
 meta/classes/rootfs-postcommands.bbclass   |  6 ++-
 meta/classes/testimage.bbclass |  2 +
 meta/conf/bitbake.conf |  5 ---
 13 files changed, 97 insertions(+), 44 deletions(-)
 create mode 100644 meta/classes/image-artifact-names.bbclass

-- 
2.17.1

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


[OE-core] [warrior][PATCH 2/3] meson: backport fix for builds with -Werror=return-type

2019-08-20 Thread Martin Jansa
Signed-off-by: Martin Jansa 
---
 meta/recipes-devtools/meson/meson.inc |  1 +
 ...rn-statements-that-are-seen-with-Wer.patch | 84 +++
 2 files changed, 85 insertions(+)
 create mode 100644 
meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
index 2d18f72c0c..bfe9851e94 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -16,6 +16,7 @@ SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
file://cross-prop-default.patch \
file://many-cross.patch \
file://cross-libdir.patch \
+   
file://0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch \
"
 SRC_URI[sha256sum] = 
"ef9f14326ec1e30d3ba1a26df0f92826ede5a79255ad723af78a2691c37109fd"
 SRC_URI[md5sum] = "0267b0871266056184c484792572c682"
diff --git 
a/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
 
b/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
new file mode 100644
index 00..1f22755e17
--- /dev/null
+++ 
b/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
@@ -0,0 +1,84 @@
+From 7e83cf1edac2a57c08ebb1ce7f21c2a539d5c300 Mon Sep 17 00:00:00 2001
+From: Martin Liska 
+Date: Mon, 15 Jul 2019 10:06:17 +0200
+Subject: [PATCH] Fix missing return statements that are seen with
+ -Werror=return-type.
+
+Error example:
+
+Code:
+
+#include 
+int main () {
+/* If it's not defined as a macro, try to use as a symbol */
+#ifndef LC_MESSAGES
+LC_MESSAGES;
+#endif
+}
+Compiler stdout:
+
+Compiler stderr:
+ In file included from /usr/include/locale.h:25,
+ from /tmp/tmpep_i4iwg/testfile.c:2:
+/usr/include/features.h:382:4: warning: #warning _FORTIFY_SOURCE requires 
compiling with optimization (-O) [-Wcpp]
+  382 | #  warning _FORTIFY_SOURCE requires compiling with optimization (-O)
+  |^~~
+/tmp/tmpep_i4iwg/testfile.c: In function 'main':
+/tmp/tmpep_i4iwg/testfile.c:8:9: error: control reaches end of non-void 
function [-Werror=return-type]
+8 | }
+  | ^
+cc1: some warnings being treated as errors
+
+Upstream-Status: Backport
+Signed-off-by: Martin Jansa 
+---
+ mesonbuild/compilers/c.py | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/mesonbuild/compilers/c.py b/mesonbuild/compilers/c.py
+index b0096459..69cf84a4 100644
+--- a/mesonbuild/compilers/c.py
 b/mesonbuild/compilers/c.py
+@@ -387,6 +387,7 @@ class CCompiler(Compiler):
+ #ifndef {symbol}
+ {symbol};
+ #endif
++return 0;
+ }}'''
+ return self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)
+@@ -563,6 +564,7 @@ class CCompiler(Compiler):
+ {prefix}
+ int main(int argc, char **argv) {{
+ {type} something;
++return 0;
+ }}'''
+ if not self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies):
+@@ -598,6 +600,7 @@ class CCompiler(Compiler):
+ {prefix}
+ int main(int argc, char **argv) {{
+ {type} something;
++return 0;
+ }}'''
+ if not self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies):
+@@ -672,6 +675,7 @@ class CCompiler(Compiler):
+ #include 
+ int main(int argc, char *argv[]) {{
+ printf ("{fmt}", {cast} {f}());
++return 0;
+ }}'''.format(**fargs)
+ res = self.run(code, env, extra_args=extra_args, 
dependencies=dependencies)
+ if not res.compiled:
+@@ -823,6 +827,7 @@ class CCompiler(Compiler):
+ #error "No definition for __builtin_{func} found in the 
prefix"
+ #endif
+ #endif
++return 0;
+ }}'''
+ return self.links(t.format(**fargs), env, extra_args=extra_args,
+   dependencies=dependencies)
+-- 
+2.17.1
+
-- 
2.17.1

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


[OE-core] [warrior][PATCH 3/3] powertop: import a fix from buildroot

2019-08-20 Thread Martin Jansa
From: Martin Jansa 

Signed-off-by: Martin Jansa 
Signed-off-by: Richard Purdie 
---
 .../0001-wakeup_xxx.h-include-limits.h.patch  | 55 +++
 meta/recipes-kernel/powertop/powertop_2.10.bb |  1 +
 2 files changed, 56 insertions(+)
 create mode 100644 
meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch

diff --git 
a/meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch
 
b/meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch
new file mode 100644
index 00..7bfca8abfd
--- /dev/null
+++ 
b/meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch
@@ -0,0 +1,55 @@
+From 4c24fdd8e0a42359df7308155b2d43c28a5e02fd Mon Sep 17 00:00:00 2001
+From: Fabrice Fontaine 
+Date: Mon, 20 May 2019 20:25:00 +0200
+Subject: [PATCH] wakeup_xxx.h: include limits.h
+
+limits.h must be included to define PATH_MAX otherwise build will fail
+on:
+
+In file included from wakeup/wakeup_ethernet.cpp:45:0:
+wakeup/wakeup_ethernet.h:35:16: error: 'PATH_MAX' was not declared in this 
scope
+  char eth_path[PATH_MAX];
+
+In file included from wakeup/wakeup_usb.cpp:45:0:
+wakeup/wakeup_usb.h:35:16: error: 'PATH_MAX' was not declared in this scope
+  char usb_path[PATH_MAX];
+
+Fixes:
+ - 
http://autobuild.buildroot.org/results/a0b3337cf4a827e6566f8b15b6bb180f0dcef7a3
+
+Signed-off-by: Fabrice Fontaine 
+Signed-off-by: Martin Jansa 
+
+Upstream-Status: Submitted 
[https://lists.01.org/pipermail/powertop/2019-May/002052.html]
+---
+ src/wakeup/wakeup_ethernet.h | 1 +
+ src/wakeup/wakeup_usb.h  | 1 +
+ 2 files changed, 2 insertions(+)
+
+diff --git a/src/wakeup/wakeup_ethernet.h b/src/wakeup/wakeup_ethernet.h
+index 682bf95..e0fa628 100644
+--- a/src/wakeup/wakeup_ethernet.h
 b/src/wakeup/wakeup_ethernet.h
+@@ -25,6 +25,7 @@
+ #ifndef _INCLUDE_GUARD_ETHERNET_WAKEUP_H
+ #define _INCLUDE_GUARD_ETHERNET_WAKEUP_H
+ 
++#include 
+ #include 
+ 
+ #include "wakeup.h"
+diff --git a/src/wakeup/wakeup_usb.h b/src/wakeup/wakeup_usb.h
+index f7a1f7e..15898e3 100644
+--- a/src/wakeup/wakeup_usb.h
 b/src/wakeup/wakeup_usb.h
+@@ -25,6 +25,7 @@
+ #ifndef _INCLUDE_GUARD_USB_WAKEUP_H
+ #define _INCLUDE_GUARD_USB_WAKEUP_H
+ 
++#include 
+ #include 
+ 
+ #include "wakeup.h"
+-- 
+2.20.1
+
diff --git a/meta/recipes-kernel/powertop/powertop_2.10.bb 
b/meta/recipes-kernel/powertop/powertop_2.10.bb
index d943ba9f6e..5be8d23111 100644
--- a/meta/recipes-kernel/powertop/powertop_2.10.bb
+++ b/meta/recipes-kernel/powertop/powertop_2.10.bb
@@ -7,6 +7,7 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"
 
 SRC_URI = "http://01.org/sites/default/files/downloads/powertop-v${PV}.tar.gz \
+file://0001-wakeup_xxx.h-include-limits.h.patch \
 "
 
 SRC_URI[md5sum] = "a69bd55901cf919cc564187402ea2c9c"
-- 
2.17.1

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


[OE-core] [warrior][PATCH 1/3] icecc.bbclass: catch subprocess.CalledProcessError

2019-08-20 Thread Martin Jansa
"
if [ "x${ICECC_VERSION}" = "x" ]
then
bbwarn "Cannot use icecc: could not get ICECC_VERSION"
return
fi

ICE_PATH="${@icecc_path(bb, d)}"
if [ "x${ICE_PATH}" = "x" ]
then
bbwarn "Cannot use icecc: could not get ICE_PATH"
return
fi

ICECC_BIN="${@get_icecc(d)}"
if [ -z "${ICECC_BIN}" ]; then
bbwarn "Cannot use icecc: icecc binary not found"
return
fi
if [ -z "$(which patchelf patchelf-uninative)" ]; then
bbwarn "Cannot use icecc: patchelf not found"
return
fi

# Create symlinks to icecc in the recipe-sysroot directory
mkdir -p ${ICE_PATH}
if [ -n "${KERNEL_CC}" ]; then
compilers="${@get_cross_kernel_cc(bb,d)}"
else
compilers="x86_64-oe-linux-gcc x86_64-oe-linux-g++"
fi
for compiler in $compilers; do
ln -sf ${ICECC_BIN} ${ICE_PATH}/$compiler
done

ICECC_CC="${@icecc_get_and_check_tool(bb, d, "gcc")}"
ICECC_CXX="${@icecc_get_and_check_tool(bb, d, "g++")}"
# cannot use icecc_get_and_check_tool here because it assumes as without 
target_sys prefix
ICECC_WHICH_AS="${@bb.utils.which(os.getenv('PATH'), 'as')}"
if [ ! -x "${ICECC_CC}" -o ! -x "${ICECC_CXX}" ]
then
bbwarn "Cannot use icecc: could not get ICECC_CC or ICECC_CXX"
return
fi

ICE_VERSION=`$ICECC_CC -dumpversion`
ICECC_VERSION=`echo ${ICECC_VERSION} | sed -e "s/@VERSION@/$ICE_VERSION/g"`
if [ ! -x 
"/build/BUILD/work/qemux86-oe-linux/python-markupsafe/1.0-r0/recipe-sysroot-native/usr/bin/icecc-create-env"
 ]
then
bbwarn "Cannot use icecc: invalid ICECC_ENV_EXEC"
return
fi

ICECC_AS="`${ICECC_CC} -print-prog-name=as`"
# for target recipes should return something like:
# 
/OE/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/arm920tt-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.8.2/as
# and just "as" for native, if it returns "as" in current directory (for 
whatever reason) use "as" from PATH
if [ "`dirname "${ICECC_AS}"`" = "." ]
then
ICECC_AS="${ICECC_WHICH_AS}"
fi

if [ ! -f "${ICECC_VERSION}.done" ]
then
mkdir -p "`dirname "${ICECC_VERSION}"`"

# the ICECC_VERSION generation step must be locked by a mutex
# in order to prevent race conditions
if flock -n "${ICECC_VERSION}.lock" \

/build/BUILD/work/qemux86-oe-linux/python-markupsafe/1.0-r0/recipe-sysroot-native/usr/bin/icecc-create-env
  "${ICECC_CC}" "${ICECC_CXX}" "${ICECC_AS}" "${ICECC_VERSION}"
then
touch "${ICECC_VERSION}.done"
elif ! wait_for_file "${ICECC_VERSION}.done" 30
then
# locking failed so wait for ${ICECC_VERSION}.done to appear
bbwarn "Timeout waiting for ${ICECC_VERSION}.done"
return
fi
fi

# Don't let ccache find the icecream compiler links that have been created, 
otherwise
# it can end up invoking icecream recursively.
export CCACHE_PATH="$PATH"
export CCACHE_DISABLE="1"

export ICECC_VERSION ICECC_CC ICECC_CXX
export PATH="$ICE_PATH:$PATH"

bbnote "Using icecc path: $ICE_PATH"
bbnote "Using icecc tarball: $ICECC_VERSION"
 which triggered exception CalledProcessError: Command 'readlink -f 
/build/BUILD/work/qemux86-oe-linux/python-markupsafe/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux/x86_64-oe-linux-g++'
 returned non-zero exit status 1.

ERROR: Task 
(virtual:multilib:lib32:/build/meta-oe/meta-python/recipes-devtools/python/python-markupsafe_1.0.bb:do_patch)
 failed with exit code '1'

Signed-off-by: Martin Jansa 
---
 meta/classes/icecc.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index edb0e10434..63d8b4dfee 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -243,7 +243,11 @@ def icecc_get_external_tool(bb, d, tool):
 
 def icecc_get_tool_link(tool, d):
 import subprocess
-return subprocess.check_output("readlink -f %s" % tool, 
shell=True).decode("utf-8")[:-1]
+try:
+return subprocess.check_output("readlink -f %s" % tool, 
shell=True).decode("utf-8")[:-1]
+except subprocess.CalledProcessError as e:
+bb.note("icecc: one of the tools probably disappeared during recipe 
parsing, cmd readlink -f %s returned %d:\n%s" % (tool, e.returncode, 
e.output.decode("utf-8")))
+return tool
 
 def icecc_get_path_tool(tool, d):
 # This is a little ugly, but we want to make sure we add an actual
-- 
2.17.1

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


Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-19 Thread Martin Jansa
On Fri, Aug 16, 2019 at 07:22:55PM +0200, Martin Jansa wrote:
> On Fri, Aug 16, 2019 at 04:54:48PM +0100, richard.pur...@linuxfoundation.org 
> wrote:
> > On Fri, 2019-08-16 at 17:00 +0200, Martin Jansa wrote:
> > > > Will try to bump BB_NUMBER_THREADS from 8 to 72.
> > > 
> > > I've tried to remove icecc.bbclass inherit (because it does things
> > > while parsing and RP probably doesn't have it inherited), but that
> > > didn't save much time.
> > > 
> > > All 3 tests were with bitbake
> > > 18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7
> > > 94m19.081s  8 BB_NUMBER_THREADS and icecc
> > > 82m59.574s  8 BB_NUMBER_THREADS no icecc
> > > 68m3.556s72 BB_NUMBER_THREADS no icecc
> > > 
> > > Still don't know how to get to sub 10min world runs RP was seeing,
> > > but at least it's as slow as it was before runqeueu changes (or even
> > > a bit faster in lastest master).
> > 
> > Just thinking out loud, other things which can influence timings:
> > 
> > Is SSTATE_DIR on NFS or local disk?
> 
> SSTATE_DIR is empty directory on local disk
> /dev/mapper/vg00-jenkins on /jenkins type ext4 
> (rw,noatime,nobarrier,commit=6000,stripe=128,data=ordered)
> 
> > Are sstate mirrors configured?
> 
> None, normally I have SSTATE_MIRRORS over sshfs in this case, but I've
> removed it before any performance testing.
> 
> > Is there an existing build or not, if so, how much is valid?
> 
> Nothing, I remove whole TMPDIR and cache before each run. Then let it
> recreate the cache before starting the profile:
> bitbake -p; time bitbake world -P -n
> 
> > Underlying filesystem of the build?
> 
> ext4, everything is pretty much generic Ubuntu 18.04
> 
> There is plenty of ram, I'll try to test this from tmpfs as well.

I did the same "bitbake -p; time bitbake world -P -n" on the same build with 
thud, warrior and zeus:

thud/profile.log.processed: 2803894450 function calls (2803191143 
primitive calls) in 3340.784 seconds
thud/profile-worker.log.processed: 27005515 function calls (26944030 
primitive calls) in 3243.139 seconds
warrior/profile.log.processed: 2804294486 function calls (2803446296 
primitive calls) in 3604.226 seconds
warrior/profile-worker.log.processed: 27649679 function calls (27591220 
primitive calls) in 3503.772 seconds
zeus/profile.log.processed: 2327031298 function calls (2326396186 
primitive calls) in 4433.851 seconds
zeus/profile-worker.log.processed: 28829453 function calls (28771730 
primitive calls) in 4331.257 seconds

thud/time:real55m41.595s
warrior/time:real60m4.954s
zeus/time:real72m23.053s

with multilib disabled I got
zeus-no-multilib/profile.log.processed: 1232798107 function calls 
(1232447521 primitive calls) in 1773.164 seconds
zeus-no-multilib/profile-worker.log.processed: 15561565 function calls 
(1044 primitive calls) in 1716.234 seconds
real29m33.658s

Which seems reasonable as the number of tasks was cut in half.

Let me know if it's worth uploading these profiles somewhere.

Cheers,

> > Your build seems especially slow at executing through the tasks which
> > is effectively a test on how fast the system can fork() and return in
> > some ways. It would be interesting to block dry-run on the server side,
> > skip the fork and see how the numbers compare.
> 
> As discussed on IRC, it's slower than yours (8 minutes from 68), but the
> most significant chunk of time is lost somewhere else.
> 
> > My build manages some parts of the tasklist faster than others, perhaps
> > because there are more "free" tasks to execute at some points in the
> > task graph than others.
> > 
> > Also, I have some patches which improve performance a bit which I'm
> > still testing.
> 
> Thanks for all the work on this!
> 
> Cheers,
> -- 
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-16 Thread Martin Jansa
On Fri, Aug 16, 2019 at 04:54:48PM +0100, richard.pur...@linuxfoundation.org 
wrote:
> On Fri, 2019-08-16 at 17:00 +0200, Martin Jansa wrote:
> > > Will try to bump BB_NUMBER_THREADS from 8 to 72.
> > 
> > I've tried to remove icecc.bbclass inherit (because it does things
> > while parsing and RP probably doesn't have it inherited), but that
> > didn't save much time.
> > 
> > All 3 tests were with bitbake
> > 18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7
> > 94m19.081s  8 BB_NUMBER_THREADS and icecc
> > 82m59.574s  8 BB_NUMBER_THREADS no icecc
> > 68m3.556s72 BB_NUMBER_THREADS no icecc
> > 
> > Still don't know how to get to sub 10min world runs RP was seeing,
> > but at least it's as slow as it was before runqeueu changes (or even
> > a bit faster in lastest master).
> 
> Just thinking out loud, other things which can influence timings:
> 
> Is SSTATE_DIR on NFS or local disk?

SSTATE_DIR is empty directory on local disk
/dev/mapper/vg00-jenkins on /jenkins type ext4 
(rw,noatime,nobarrier,commit=6000,stripe=128,data=ordered)

> Are sstate mirrors configured?

None, normally I have SSTATE_MIRRORS over sshfs in this case, but I've
removed it before any performance testing.

> Is there an existing build or not, if so, how much is valid?

Nothing, I remove whole TMPDIR and cache before each run. Then let it
recreate the cache before starting the profile:
bitbake -p; time bitbake world -P -n

> Underlying filesystem of the build?

ext4, everything is pretty much generic Ubuntu 18.04

There is plenty of ram, I'll try to test this from tmpfs as well.

> Your build seems especially slow at executing through the tasks which
> is effectively a test on how fast the system can fork() and return in
> some ways. It would be interesting to block dry-run on the server side,
> skip the fork and see how the numbers compare.

As discussed on IRC, it's slower than yours (8 minutes from 68), but the
most significant chunk of time is lost somewhere else.

> My build manages some parts of the tasklist faster than others, perhaps
> because there are more "free" tasks to execute at some points in the
> task graph than others.
> 
> Also, I have some patches which improve performance a bit which I'm
> still testing.

Thanks for all the work on this!

Cheers,
-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


[OE-core] [RFC][PATCH 6/6] *-artifact-names: include version only in the artifact links

2019-08-16 Thread Martin Jansa
* drop ${PKGE}-${PKGV}-${PR} from kernel artifacts names (this is the
  latest build) and add it only in hardlinks created in do_deploy_links
  so that we can use PKGR there again (because these links are generally
  used only by human operators and they don't have their own TASKHASH or
  the IMAGE_VERSION_SUFFIX might be set to some release name which they
  do understand

* this allows to drop package_get_auto_pr from kernel do_deploy as well,
  leaving only 2 EXTENDPRAUTO bumps for each kernel build (do_package
  and do_deploy_links, unfortunatelly these will still have different
  value, so if you're looking for the exact kernel image in deploy
  directory based on kernel image package version seen on the device the
  EXTENDPRAUTO part of PR will be different).

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/image-artifact-names.bbclass  | 2 +-
 meta/classes/kernel-artifact-names.bbclass | 7 +--
 meta/classes/kernel.bbclass| 1 -
 3 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/meta/classes/image-artifact-names.bbclass 
b/meta/classes/image-artifact-names.bbclass
index d5ba035f5a..b23cef22ca 100644
--- a/meta/classes/image-artifact-names.bbclass
+++ b/meta/classes/image-artifact-names.bbclass
@@ -3,7 +3,7 @@
 ##
 
 IMAGE_BASENAME = "${PN}"
-IMAGE_VERSION_SUFFIX = "-${DATETIME}"
+IMAGE_VERSION_SUFFIX = "${PKGE}-${PKGV}-${PKGR}-${DATETIME}"
 IMAGE_VERSION_SUFFIX[vardepsexclude] += "DATETIME"
 IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}"
 IMAGE_LINK_NAME = "${IMAGE_NAME}${IMAGE_VERSION_SUFFIX}"
diff --git a/meta/classes/kernel-artifact-names.bbclass 
b/meta/classes/kernel-artifact-names.bbclass
index 41ef6e884d..92e08297cc 100644
--- a/meta/classes/kernel-artifact-names.bbclass
+++ b/meta/classes/kernel-artifact-names.bbclass
@@ -6,12 +6,7 @@
 
 inherit image-artifact-names
 
-# Intentionally use PR instead of PKGR, because EXTENDPRAUTO included
-# in PKGR will have different value for do_install/do_deploy/do_deploy_links
-# tasks with different TASKHASH, causing multiple EXTENDPRAUTO increments for
-# each kernel build and more importantly preventing do_deploy_links to
-# reference artifacts created do_deploy task
-KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PR}-${MACHINE}"
+KERNEL_ARTIFACT_NAME ?= "${MACHINE}"
 KERNEL_ARTIFACT_LINK_NAME ?= "${KERNEL_ARTIFACT_NAME}${IMAGE_VERSION_SUFFIX}"
 
 KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e41adcbebe..3b8bfd2991 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -700,7 +700,6 @@ kernel_do_deploy() {
 }
 do_deploy[cleandirs] = "${DEPLOYDIR}"
 do_deploy[dirs] = "${DEPLOYDIR} ${B}"
-do_deploy[prefuncs] += "package_get_auto_pr"
 
 addtask deploy after do_populate_sysroot do_packagedata
 
-- 
2.17.1

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


[OE-core] [RFC][PATCH 5/6] kernel.bbclass: drop unnecessary package_get_auto_pr for do_install

2019-08-16 Thread Martin Jansa
* do_install doesn't use whole "version" as do_deploy does, e.g.
  ${PKGE}-${PKGV}-${PKGR}-${MACHINE}
  it installs only the files with only ${KERNEL_VERSION} in filename or
  path, so it doesn't need expanded AUTOINC value in PKGV nor
  EXPANDPRAUTO in PKGR like do_deploy does

* it was introduced in
  
http://git.openembedded.org/openembedded-core/commit/?id=1392f959cb8cd50b5a4492899e54f3ed68ef56d7
  but it's not clear why it was needed back then, but doesn't seem to be
  useful at all currently, only causes multiple EXTENDPRAUTO bumps every
  time different linux-yocto is being built.

* There are currently 4 EXTENDPRAUTO bumps during each build as shown in
  prserv:

  $ sqlite3 cache/prserv.sqlite3
SQLite version 3.27.2 2019-02-25 16:06:06
Enter ".help" for usage hints.
sqlite> select * from PRMAIN_nohist where version like 'linux-yocto-dev%';

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|20601304a6e4fa0b7ac13fa1262040c976c862d177077799dc15492215fa51df|0

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|2820d331b7eba5165943bc016a1c274d42e7605e24244873b15cc1c9c6f657e2|1

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|4f29da98c268aa5bf1c4767bb2bb157fc6077b1d76dfd434028b18bf3252e0c0|2

linux-yocto-dev-4.19+gitAUTOINC+57b791cb9f_122d468967-r0|qemux86|23d8d17b23bc6db1dd7f0f30086f0ec6ade2b2180e787a78d89b6e43b8c4fad6|3

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|2a23d8783f794b3e79b438889ec60661ca635f9ec09d0519176a31d832377f1c|0

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|dafc2a636e7e18357b7efbf99981af45234105c3f46b056edfd2142d5a5d4993|1

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|09798369f303700fb8d42550d959e310a05fb4573b71646df51acc00d3a6fe89|2

linux-yocto-dev-5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0|qemux86|dab07eb869034df28be59ae13914989ab88bdca5a9a9362ca96b4eb38180afd7|3

  the TASKHASHes correspond to do_install, do_package, do_deploy, 
do_deploy_links tasks:
  $ ls 
tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_*sigdata*{2a23d8783f794b3e79b438889ec60661ca635f9ec09d0519176a31d832377f1c,dafc2a636e7e18357b7efbf99981af45234105c3f46b056edfd2142d5a5d4993,09798369f303700fb8d42550d959e310a05fb4573b71646df51acc00d3a6fe89,dab07eb869034df28be59ae13914989ab88bdca5a9a9362ca96b4eb38180afd7}*

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_install.sigdata.2a23d8783f794b3e79b438889ec60661ca635f9ec09d0519176a31d832377f1c

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_package.sigdata.dafc2a636e7e18357b7efbf99981af45234105c3f46b056edfd2142d5a5d4993

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_deploy.sigdata.09798369f303700fb8d42550d959e310a05fb4573b71646df51acc00d3a6fe89

tmp-glibc/stamps/qemux86-webos-linux/linux-yocto-dev/5.0~rc6+gitAUTOINC+e721b5d6ab_8b7d7ef74a-r0.do_deploy_links.sigdata.dab07eb869034df28be59ae13914989ab88bdca5a9a9362ca96b4eb38180afd7

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/kernel.bbclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index bda3af2950..e41adcbebe 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -383,7 +383,6 @@ kernel_do_install() {
install -d ${D}${sysconfdir}/modules-load.d
install -d ${D}${sysconfdir}/modprobe.d
 }
-do_install[prefuncs] += "package_get_auto_pr"
 
 # Must be ran no earlier than after do_kernel_checkout or else Makefile won't 
be in ${S}/Makefile
 do_kernel_version_sanity_check() {
-- 
2.17.1

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


[OE-core] [RFC][PATCH 3/6] kernel-artifact-names.bbclass: use PR instead of PKGR in KERNEL_ARTIFACT_NAME

2019-08-16 Thread Martin Jansa
* otherwise PKGR seen in do_install, do_deploy and do_deploy_links will
  have different value in each of them (PRSERV will return different
  value of EXTENDPRAUTO because TASKHASH is different for each of these
  tasks and also cause unnecessary multiple EXTENDPRAUTO increments for
  each build).

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/kernel-artifact-names.bbclass | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-artifact-names.bbclass 
b/meta/classes/kernel-artifact-names.bbclass
index 529e0c565e..41ef6e884d 100644
--- a/meta/classes/kernel-artifact-names.bbclass
+++ b/meta/classes/kernel-artifact-names.bbclass
@@ -6,7 +6,12 @@
 
 inherit image-artifact-names
 
-KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}"
+# Intentionally use PR instead of PKGR, because EXTENDPRAUTO included
+# in PKGR will have different value for do_install/do_deploy/do_deploy_links
+# tasks with different TASKHASH, causing multiple EXTENDPRAUTO increments for
+# each kernel build and more importantly preventing do_deploy_links to
+# reference artifacts created do_deploy task
+KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PR}-${MACHINE}"
 KERNEL_ARTIFACT_LINK_NAME ?= "${KERNEL_ARTIFACT_NAME}${IMAGE_VERSION_SUFFIX}"
 
 KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
-- 
2.17.1

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


[OE-core] [RFC][PATCH 4/6] kernel.bbclass: imageType without {}

2019-08-16 Thread Martin Jansa
* just to make sure it looks like bash variable not bitbake variable in
  run.do_* scripts

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/kernel.bbclass | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 0c82946fcc..bda3af2950 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -371,9 +371,9 @@ kernel_do_install() {
install -d ${D}/${KERNEL_IMAGEDEST}
install -d ${D}/boot
for imageType in ${KERNEL_IMAGETYPES} ; do
-   install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
+   install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType 
${D}/${KERNEL_IMAGEDEST}/$imageType-${KERNEL_VERSION}
if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then
-   ln -sf ${imageType}-${KERNEL_VERSION} 
${D}/${KERNEL_IMAGEDEST}/${imageType}
+   ln -sf $imageType-${KERNEL_VERSION} 
${D}/${KERNEL_IMAGEDEST}/$imageType
fi
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
@@ -681,8 +681,8 @@ kernel_do_deploy() {
fi
 
for imageType in ${KERNEL_IMAGETYPES} ; do
-   install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
$deployDir/${imageType}-${KERNEL_IMAGE_NAME}.bin
-   ln -sf ${imageType}-${KERNEL_IMAGE_NAME}.bin 
$deployDir/${imageType}
+   install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType 
$deployDir/$imageType-${KERNEL_IMAGE_NAME}.bin
+   ln -sf $imageType-${KERNEL_IMAGE_NAME}.bin $deployDir/$imageType
done
 
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e 
'^CONFIG_MODULES=y$' .config); then
@@ -695,7 +695,7 @@ kernel_do_deploy() {
if [ "$imageType" = "fitImage" ] ; then
continue
fi
-   install -m 0644 
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs 
$deployDir/${imageType}-${INITRAMFS_NAME}.bin
+   install -m 0644 
${KERNEL_OUTPUT_DIR}/$imageType.initramfs 
$deployDir/$imageType-${INITRAMFS_NAME}.bin
done
fi
 }
@@ -713,7 +713,7 @@ kernel_do_deploy_links() {
fi
 
for imageType in ${KERNEL_IMAGETYPES} ; do
-   ln -vf $deployDir/${imageType}-${KERNEL_IMAGE_NAME}.bin 
$deployDir/${imageType}-${KERNEL_IMAGE_LINK_NAME}.bin
+   ln -vf $deployDir/$imageType-${KERNEL_IMAGE_NAME}.bin 
$deployDir/$imageType-${KERNEL_IMAGE_LINK_NAME}.bin
done
 
if [ ${MODULE_TARBALL_DEPLOY} = "1" -a -f 
$deployDir/modules-${MODULE_TARBALL_NAME}.tgz ] ; then
@@ -725,7 +725,7 @@ kernel_do_deploy_links() {
if [ "$imageType" = "fitImage" ] ; then
continue
fi
-   ln -vf ${imageType}-${INITRAMFS_NAME}.bin 
${imageType}-${INITRAMFS_LINK_NAME}.bin
+   ln -vf $imageType-${INITRAMFS_NAME}.bin 
$imageType-${INITRAMFS_LINK_NAME}.bin
done
fi
 }
-- 
2.17.1

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


[OE-core] [RFC][PATCH 2/6] bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in the _LINK_NAME variables and change it to hard link

2019-08-16 Thread Martin Jansa
* just RFC, the part for images isn't finished yet and there is
  still some issue with DATETIME when kernel artifacts are used
  from sstate, this is just to validate the idea behind
  [YOCTO #12937] before finishing the implementation (it's already
  finished and used by various LGE builds, but having simpler
  way of doing it directly in oe-core mighe be useful for others).

* move IMAGE_VERSION_SUFFIX from _NAME variables to _LINK_NAME
  that way e.g. kernel.do_deploy can be reused from sstate to
  provide "version-less" artifacts and then very fast
  do_deploy_links task just adds links with consistent suffixes
  (by default the version from the recipe but could be easily set
  to e.g. some release name when building some products).
* create hard links instead of symlinks, so that whatever version
  the filename says is really there
* some IMAGE_FSTYPES might need the "version-less" IMAGE_NAME file
  to be removed first or they might either append or update the
  content of the image instead of creating new image file from
  scratch - I have seen this only with one proprietary format we
  generate with our own tool, so hopefully this isn't very common
* this is basically the mechanism are using in webOS with
  WEBOS_IMAGE_NAME_SUFFIX which is for official builds set from
  jenkins job and then all artifacts (images as well as corresponding
  kernel files) have the same version string)

* without this, you can still easily set the variables to contain
  the version from jenkins job (excluded from sstate signature like
  DATETIME currently is to prevent rebuilding it everytime even when
  the content didn't change) but then when kernel is reused from sstate
  you can have version 1.0 used on kernel artifacts and 2.0 on image
  artifacts.

* if you don't exclude the version string with vardepsexclude, then
  you get the right version in the filenames but for cost of
  re-executing do_deploy every single time, which with rm_work will
  cause all kernel tasks to be re-executed (together with everything
  which depends on it like external modules etc).

* the implementation "from outside" is a bit tricky as shown in webOS
  OSE, because first you need to reverse the meaning of IMAGE_NAME
  and IMAGE_LINK_NAME like here, but also replace all symlinks with
  hardlinks and then adjust all recipes/bbclasses to depend on our
  do_deploy_fixup task instead of the original do_deploy
  see the variable modifications:
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/conf/distro/include/webos.inc#L65
  and then various bbclasses to hook do_webos_deploy_fixup task creating
  the hardlinks for possible artifacts:
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/webos_deploy.bbclass
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/kernel.bbclass
  
https://github.com/webosose/meta-webosose/blob/a35e81622aae1066591e44a132d01297ff478248/meta-webos/classes/image.bbclass
  so hopefully with all these changes in oe-core other project can
  achieve the same just by setting one variable IMAGE_VERSION_SUFFIX

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/cve-check.bbclass |  4 +-
 meta/classes/image-artifact-names.bbclass  |  4 +-
 meta/classes/image.bbclass | 10 ++---
 meta/classes/kernel-artifact-names.bbclass |  4 +-
 meta/classes/kernel-devicetree.bbclass | 21 +--
 meta/classes/kernel.bbclass| 43 --
 meta/classes/qemuboot.bbclass  |  2 +-
 meta/classes/rootfs-postcommands.bbclass   |  4 +-
 8 files changed, 63 insertions(+), 29 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index c00d2910be..19ef51eb05 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -100,10 +100,10 @@ python cve_check_write_rootfs_manifest () {
 
 if manifest_name and os.path.exists(manifest_name):
 manifest_link = os.path.join(deploy_dir, "%s.cve" % link_name)
-# If we already have another manifest, update symlinks
+# If we already have another manifest, update hardlinks
 if os.path.exists(os.path.realpath(manifest_link)):
 os.remove(manifest_link)
-os.symlink(os.path.basename(manifest_name), manifest_link)
+os.link(manifest_name, manifest_link)
 bb.plain("Image CVE report stored in: %s" % manifest_name)
 }
 
diff --git a/meta/classes/image-artifact-names.bbclass 
b/meta/classes/image-artifact-names.bbclass
index 5ab8f1b7aa..d5ba035f5a 100644
--- a/meta/classes/image-artifact-names.bbclass
+++ b/meta/classes/image-artifact-names.bbclass
@@ -5,8 +5,8 @@
 IMAGE_BASENAME = "${PN}"
 IMAGE_VERSION_SUFFIX = "-${DATETIME}

[OE-core] [RFC][PATCH 1/6] image-artifact-names: introduce new bbclass and move some variables into it

2019-08-16 Thread Martin Jansa
* similar to kernel-artifact-names for other recipes/bbclasses which
  need to use some deployed artifacts

* bitbake.conf: move IMAGE_BASENAME, IMAGE_VERSION_SUFFIX, IMAGE_NAME,
  IMAGE_LINK_NAME variables

* image_types.bbclass: move IMAGE_NAME_SUFFIX variable

* currently IMAGE_NAME_SUFFIX is used only by image.bbclass,
  image_types.bbclass and 
meta/recipes-core/images/build-appliance-image_15.0.0.bb
  but if it's needed by some recipe which isn't itself an image, then
  it's useful in bitbake.conf, e.g. we have a recipe for creating
  VirtualBox appliances which combines .wic.vmdk with .ovf file to
  create .zip with appliance, but for that we need the filename of
  .wic.vmdk which now contains IMAGE_NAME_SUFFIX
  
https://github.com/webOS-ports/meta-webos-ports/blob/4980ce52a43ac6897657602810313af359f0b839/meta-luneos/recipes-core/images/luneos-emulator-appliance.inc#L24

* we were hardcoding .rootfs suffix where needed, but for quite long
  time it's configurable with IMAGE_NAME_SUFFIX since:

  commit 380ee36811939d947024bf78de907e3c071b834f
  Author: Patrick Ohly 
  Date:   Mon Mar 7 18:07:52 2016 +0100

image creation: allow overriding .rootfs suffix

  and might not match with hardcoded .rootfs, so make it easier to
  use IMAGE_NAME_SUFFIX where needed even without inheritting whole
  image_types.bbclass

[YOCTO #12937]

Signed-off-by: Martin Jansa 
---
 meta/classes/buildhistory.bbclass  |  2 ++
 meta/classes/image-artifact-names.bbclass  | 15 +++
 meta/classes/image-live.bbclass|  2 +-
 meta/classes/image_types.bbclass   |  9 ++---
 meta/classes/kernel-artifact-names.bbclass |  8 
 meta/classes/qemuboot.bbclass  |  2 ++
 meta/classes/rootfs-postcommands.bbclass   |  2 ++
 meta/classes/testimage.bbclass |  2 ++
 meta/conf/bitbake.conf |  5 -
 9 files changed, 34 insertions(+), 13 deletions(-)
 create mode 100644 meta/classes/image-artifact-names.bbclass

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index f986f7c794..fb244bc04e 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -7,6 +7,8 @@
 # Copyright (C) 2007-2011 Koen Kooi 
 #
 
+inherit image-artifact-names
+
 BUILDHISTORY_FEATURES ?= "image package sdk"
 BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
 BUILDHISTORY_DIR_IMAGE = 
"${BUILDHISTORY_DIR}/images/${MACHINE_ARCH}/${TCLIBC}/${IMAGE_BASENAME}"
diff --git a/meta/classes/image-artifact-names.bbclass 
b/meta/classes/image-artifact-names.bbclass
new file mode 100644
index 00..5ab8f1b7aa
--- /dev/null
+++ b/meta/classes/image-artifact-names.bbclass
@@ -0,0 +1,15 @@
+##
+# Specific image creation and rootfs population info.
+##
+
+IMAGE_BASENAME = "${PN}"
+IMAGE_VERSION_SUFFIX = "-${DATETIME}"
+IMAGE_VERSION_SUFFIX[vardepsexclude] += "DATETIME"
+IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
+
+# IMAGE_NAME is the base name for everything produced when building images.
+# The actual image that contains the rootfs has an additional suffix (.rootfs
+# by default) followed by additional suffices which describe the format (.ext4,
+# .ext4.xz, etc.).
+IMAGE_NAME_SUFFIX ??= ".rootfs"
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index af71be5093..d44573efe8 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -22,7 +22,7 @@
 # ${HDDIMG_ID} - FAT image volume-id
 # ${ROOTFS} - indicates a filesystem image to include as the root filesystem 
(optional)
 
-inherit live-vm-common
+inherit live-vm-common image-artifact-names
 
 do_bootimg[depends] += "dosfstools-native:do_populate_sysroot \
 mtools-native:do_populate_sysroot \
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 2eeffbb366..a6d42c03e4 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -1,9 +1,3 @@
-# IMAGE_NAME is the base name for everything produced when building images.
-# The actual image that contains the rootfs has an additional suffix (.rootfs
-# by default) followed by additional suffices which describe the format (.ext4,
-# .ext4.xz, etc.).
-IMAGE_NAME_SUFFIX ??= ".rootfs"
-
 # The default aligment of the size of the rootfs is set to 1KiB. In case
 # you're using the SD card emulation of a QEMU system simulator you may
 # set this value to 2048 (2MiB alignment).
@@ -229,7 +223,8 @@ IMAGE_CMD_f2fs () {
 
 EXTRA_IMAGECMD = ""
 
-inherit siteinfo kernel-arch
+inherit siteinfo kernel-arch image-artifact-names
+
 JFFS2_ENDIANNESS ?= "${@oe.utils.conditional('SITEINF

[OE-core] [RFC][PATCH 0/6] YOCTO #12937 - Consistent naming scheme for deployed artifacts

2019-08-16 Thread Martin Jansa
2:59 
core-image-minimal-qemux86-64-release-1.ext4
51665615 -rw-r--r--  2 bitbake bitbake  61M Aug 16 12:59 
core-image-minimal-qemux86-64.rootfs.ext4
51665617 -rw-r--r--  2 bitbake bitbake  49M Aug 16 12:59 
core-image-minimal-qemux86-64-release-1.wic.vmdk
51665617 -rw-r--r--  2 bitbake bitbake  49M Aug 16 12:59 
core-image-minimal-qemux86-64.rootfs.wic.vmdk

f) With this PR and IMAGE_VERSION_SUFFIX_forcevariable = "-release-2"
   and IMAGE_INSTALL_append = " zlib" added to force image to be recreated
   while kernel is still reused from sstate
   In this case I haven't removed TMPDIR between e) and f) to show
   that kernel artifacts are identical from previous build release-1 and just
   added another hardlink to the same inode.

$ ls -laih qemux86-64-YOCTO-12937-release-2/ | sort
47054849 drwxr-xr-x 13 bitbake bitbake 4.0K Aug 16 16:37 ..
51665409 -rw-r--r--  2 bitbake bitbake 1.3K Aug 16 13:07 
core-image-minimal-qemux86-64.qemuboot.conf
51665409 -rw-r--r--  2 bitbake bitbake 1.3K Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.qemuboot.conf
51665420 -rw-r--r--  2 bitbake bitbake 161K Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.testdata.json
51665420 -rw-r--r--  2 bitbake bitbake 161K Aug 16 13:07 
core-image-minimal-qemux86-64.testdata.json
51665422 -rw-r--r--  2 bitbake bitbake 2.2K Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.manifest
51665422 -rw-r--r--  2 bitbake bitbake 2.2K Aug 16 13:07 
core-image-minimal-qemux86-64.rootfs.manifest
51665583 -rw-r--r--  1 bitbake bitbake 1.1K Aug 16 13:07 core-image-minimal.env
51665584 -rw-r--r--  2 bitbake bitbake  61M Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.ext4
51665584 -rw-r--r--  2 bitbake bitbake  61M Aug 16 13:07 
core-image-minimal-qemux86-64.rootfs.ext4
51665585 -rw-r--r--  2 bitbake bitbake  49M Aug 16 13:07 
core-image-minimal-qemux86-64-release-2.wic.vmdk
51665585 -rw-r--r--  2 bitbake bitbake  49M Aug 16 13:07 
core-image-minimal-qemux86-64.rootfs.wic.vmdk
51666546 drwxr-xr-x  2 bitbake bitbake 4.0K Aug 16 13:07 .
51666553 -rw-r--r--  1 bitbake bitbake 612K Aug 15 17:16 grub-efi-bootx64.efi
51666554 -rwxr-xr-x  1 bitbake bitbake  95K Aug 15 17:16 systemd-bootx64.efi
51666555 -rw-r--r--  3 bitbake bitbake 7.0M Aug 15 18:44 
modules-qemux86-64-release-1.tgz
51666555 -rw-r--r--  3 bitbake bitbake 7.0M Aug 15 18:44 
modules-qemux86-64-release-2.tgz
51666555 -rw-r--r--  3 bitbake bitbake 7.0M Aug 15 18:44 modules-qemux86-64.tgz
51666556 -rw-r--r--  3 bitbake bitbake 7.6M Aug 15 18:44 bzImage-qemux86-64.bin
51666556 -rw-r--r--  3 bitbake bitbake 7.6M Aug 15 18:44 
bzImage-qemux86-64-release-1.bin
51666556 -rw-r--r--  3 bitbake bitbake 7.6M Aug 15 18:44 
bzImage-qemux86-64-release-2.bin
51666557 lrwxrwxrwx  1 bitbake bitbake   22 Aug 15 18:44 bzImage -> 
bzImage-qemux86-64.bin

The following changes since commit 6b36db836547a23f43c5f97bf3706d7b210c209c:

  libevent: update to 2.1.11 (2019-08-14 17:32:19 +0100)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib jansa/artifacts
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=jansa/artifacts

Martin Jansa (6):
  image-artifact-names: introduce new bbclass and move some variables
into it
  bitbake.conf, kernel*.bbclass: include IMAGE_VERSION_SUFFIX only in
the _LINK_NAME variables and change it to hard link
  kernel-artifact-names.bbclass: use PR instead of PKGR in
KERNEL_ARTIFACT_NAME
  kernel.bbclass: imageType without {}
  kernel.bbclass: drop unnecessary package_get_auto_pr for do_install
  *-artifact-names: include version only in the artifact links

 meta/classes/buildhistory.bbclass  |  2 +
 meta/classes/cve-check.bbclass |  4 +-
 meta/classes/image-artifact-names.bbclass  | 15 +++
 meta/classes/image-live.bbclass|  2 +-
 meta/classes/image.bbclass | 10 ++---
 meta/classes/image_types.bbclass   |  9 +---
 meta/classes/kernel-artifact-names.bbclass | 12 +-
 meta/classes/kernel-devicetree.bbclass | 21 --
 meta/classes/kernel.bbclass| 49 +++---
 meta/classes/qemuboot.bbclass  |  4 +-
 meta/classes/rootfs-postcommands.bbclass   |  6 ++-
 meta/classes/testimage.bbclass |  2 +
 meta/conf/bitbake.conf |  5 ---
 13 files changed, 97 insertions(+), 44 deletions(-)
 create mode 100644 meta/classes/image-artifact-names.bbclass

-- 
2.17.1

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


Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-16 Thread Martin Jansa
> Will try to bump BB_NUMBER_THREADS from 8 to 72.

I've tried to remove icecc.bbclass inherit (because it does things while
parsing and RP probably doesn't have it inherited), but that didn't save
much time.

All 3 tests were with bitbake 18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7
94m19.081s  8 BB_NUMBER_THREADS and icecc
82m59.574s  8 BB_NUMBER_THREADS no icecc
68m3.556s72 BB_NUMBER_THREADS no icecc

Still don't know how to get to sub 10min world runs RP was seeing, but at
least it's as slow as it was before runqeueu changes (or even a bit faster
in lastest master).

On Fri, Aug 16, 2019 at 12:24 PM Martin Jansa 
wrote:

> On Thu, Aug 15, 2019 at 05:05:48PM +0200, Martin Jansa wrote:
> > On Tue, Aug 13, 2019 at 10:04:08AM +0100, Richard Purdie wrote:
> > > On Mon, 2019-08-12 at 20:26 +, Peter Kjellerstedt wrote:
> > > > Comparing that build to a corresponding do-nothing build with Thud,
> > > > the time difference matches those three minutes where I have no idea
> > > > what bitbake is doing now that it didn’t need to do before…
> > > >
> > > > Hopefully these time degradations can be solved, because the current
> > > > state of bitbake is barely usable. We also need to look into possible
> > > > ways to improve the cooker output when it is running the setscene
> > > > tasks so it makes some kind of sense again.
> > >
> > > We talked on irc and you pointed at the commit things started to go
> > > wrong. Just to summarise things for the benefit of the list, this is
> > > some quick testing I did:
> > >
> > > "bitbake -p; time bitbake core-image-minimal -n"
> > >
> > > 30.0s 6c7c0cefd34067311144a1d4c01986fe0a4aef26
> > > 30.6s a0d941c787cf3ef030d190903279d311bc05d752
> > > 40.3s 7df31ff36892c2f9c65326b06b4c70
> > > 42.2s a0542ed3ff700eca35f9195f743c9e28bcd50f3e
> > > 45.4s 9983b07fffd19082abded7c3f15cc77d306dd69c
> > > 76.9s master-next
> >
> > I know I'm late to the party, but it took really long for the test to
> finish..
> >
> > I'm not using poky, so reproduce this testing on our builds I've used
> > bitbake revisions matching with poky revision RP was testing:
> >
> > + oe-core 18cdc087fd5da30e2b31f3d4e81b153cd36ca844 for older bitbake,
> because current master isn't compatible with old bitbake
> (bb.data_smart.ExpansionError: Failure expanding variable OE_IMPORTED[:=],
> expression was ${@oe_import(d)} which triggered exception AttributeError:
> module 'bb.siggen' has no attribute 'SignatureGeneratorUniHashMixIn')
> > and oe-core 23db236a054ee7a989cdbbcb42ad5c6eefd4a6ae for newer bitbake
> (to possibly eliminate impact of metadata changes)
> >
> > tested on 72core (Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz) with 380GB
> RAM
> >
> > nothing in TMPDIR/SSTATE_DIR, no SSTATE_MIRRO, no Hash Equivalence
> Server configured
> >
> > on a build with few more layers:
> > Parsing of 3238 .bb files complete (0 cached, 3238 parsed). 7632
> targets, 1927 skipped, 54 masked, 0 errors.
> >
> > but first doing just core-image-minimal like RP did:
> >
> > time  pokybitbake
>  oe-core
> > 2m8.191s  6c7c0cefd34067311144a1d4c01986fe0a4aef26
> 18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7
> 18cdc087fd5da30e2b31f3d4e81b153cd36ca844
> > N/A   a0d941c787cf3ef030d190903279d311bc05d752doesn't
> exist in poky/poky-contrib
> 18cdc087fd5da30e2b31f3d4e81b153cd36ca844
> > 2m17.053s 7df31ff36892c2f9c65326b06b4c70
> 1f630fdf0260db08541d3ca9f25f852931c19905
> 18cdc087fd5da30e2b31f3d4e81b153cd36ca844
> > 2m18.515s a0542ed3ff700eca35f9195f743c9e28bcd50f3e
> f43778c2d19e70d4befd483b06aaf247fc65c799
> 23db236a054ee7a989cdbbcb42ad5c6eefd4a6ae
> > 2m22.220s 9983b07fffd19082abded7c3f15cc77d306dd69c
> 8c26b451f22193ef1c544e2017cc84515566c1b8
> > 2m38.185s master-next
>  fbcb89dc3dbabfc80310e9a4ebe72d919300a32e
> > cache.py:446: ResourceWarning: unclosed  family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0,
> laddr=('127.0.0.1', 41117)>
> >   value = pickled.load()
> > started showing with this revision
> > 2m17.991s master-next + fixups
> f7cd14f90463957b3e4be6d3876def98b78f1424
> > 2m9.651s  master-next + "Holding off tasks %s" out
> >
> > now world
> > 253m36.637s   7df31ff36892c2f9c65326b06b4c70
> 1f630fdf0260db08541d3ca9f25f852931c19905
> 18cdc087fd5da30e2b31f3d4e81b153cd36ca844
> > 174m13.324s   a0542ed3ff700eca35f9195f743c9e28bcd50f3e
> f43778c2d19e70d4befd483b06aa

Re: [OE-core] [PATCH V2] gcc-runtime: Move content from gcclibdir into libdir

2019-08-16 Thread Martin Jansa
Hi,

I have an app which includes omp.h from gomp, it used to find it without
adding any -I for that (with just -fopenmp to enable openmp).

Now the header file is included in RSS:
lib32-recipe-sysroot/usr/lib/arm-oemllib32-linux-gnueabi/9.2.0/include/omp.h
but no longer found in default search dirs.

Is this expected or should gcc be adjusted to search for it automatically?

Looking at the default search paths I see:

ignoring nonexistent directory
"BUILD/work/machine-oemllib32-linux-gnueabi/lib32-component/2.0.0-76-r7/recipe-sysroot-native/usr/bin/arm-oemllib32-linux-gnueabi/../../lib/arm-oemllib32-linux-gnueabi/gcc/arm-oemllib32-linux-gnueabi/9.2.0/../../../../../arm-oemllib32-linux-gnueabi/include"
ignoring nonexistent directory "/not/exist/usr/include/c++/9.2.0"
ignoring nonexistent directory
"/not/exist/usr/include/c++/9.2.0/arm-oemllib32-linux-gnueabi"
ignoring nonexistent directory "/not/exist/usr/include/c++/9.2.0/backward"
ignoring duplicate directory
"BUILD/work/machine-oemllib32-linux-gnueabi/lib32-component/2.0.0-76-r7/recipe-sysroot-native/usr/bin/arm-oemllib32-linux-gnueabi/../../lib/arm-oemllib32-linux-gnueabi/gcc/../../../lib/arm-oemllib32-linux-gnueabi/gcc/arm-oemllib32-linux-gnueabi/9.2.0/include"
ignoring nonexistent directory
"/not/exist/usr/lib/gcc/arm-oemllib32-linux-gnueabi/9.2.0/include"
ignoring nonexistent directory "/not/exist/usr/local/include"
ignoring duplicate directory
"BUILD/work/machine-oemllib32-linux-gnueabi/lib32-component/2.0.0-76-r7/recipe-sysroot-native/usr/bin/arm-oemllib32-linux-gnueabi/../../lib/arm-oemllib32-linux-gnueabi/gcc/../../../lib/arm-oemllib32-linux-gnueabi/gcc/arm-oemllib32-linux-gnueabi/9.2.0/include-fixed"
ignoring nonexistent directory
"BUILD/work/machine-oemllib32-linux-gnueabi/lib32-component/2.0.0-76-r7/recipe-sysroot-native/usr/bin/arm-oemllib32-linux-gnueabi/../../lib/arm-oemllib32-linux-gnueabi/gcc/../../../lib/arm-oemllib32-linux-gnueabi/gcc/arm-oemllib32-linux-gnueabi/9.2.0/../../../../../arm-oemllib32-linux-gnueabi/include"
ignoring nonexistent directory "/not/exist/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 
BUILD/work/machine-oemllib32-linux-gnueabi/lib32-component/2.0.0-76-r7/recipe-sysroot-native/usr/bin/arm-oemllib32-linux-gnueabi/../../lib/arm-oemllib32-linux-gnueabi/gcc/arm-oemllib32-linux-gnueabi/9.2.0/include
 
BUILD/work/machine-oemllib32-linux-gnueabi/lib32-component/2.0.0-76-r7/recipe-sysroot-native/usr/bin/arm-oemllib32-linux-gnueabi/../../lib/arm-oemllib32-linux-gnueabi/gcc/arm-oemllib32-linux-gnueabi/9.2.0/include-fixed
End of search list.

On Tue, Aug 13, 2019 at 5:29 PM Khem Raj  wrote:

> OE does not use the traditional /usr/lib/gcc prefix to store gcc-runtime
> it basically is moved into libdir, however some newer files were
> installed by newer versions of gcc especially libgomp ( omp.h openacc.h )
> into gcclibdir, so we have content in both directories, this confuses
> other tools which are trying to guess the gcc installation and its
> runtime location, since now we have two directories, the tools either
> choose one or other and we get inconsistent behavior, e.g. clang for
> aarch64 uses /usr/lib but same clang for riscv64 chose /usr/lib/gcc
>
> This change ensures that OE ends up with single valid location for gcc
> runtime files
>
> Move more common bits into common inc file
>
> Signed-off-by: Khem Raj 
> ---
> v2: Divert packaging to use new path in whole recipe
>
>  meta/recipes-devtools/gcc/gcc-runtime.inc| 18 +++---
>  meta/recipes-devtools/gcc/gcc-runtime_8.3.bb | 10 --
>  meta/recipes-devtools/gcc/gcc-runtime_9.1.bb | 10 --
>  3 files changed, 15 insertions(+), 23 deletions(-)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index a5c2600d7f..22c1d78dd1 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -17,6 +17,12 @@ EXTRA_OECONF_PATHS = "\
>  EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
>  EXTRA_OECONF_append = " --cache-file=${B}/config.cache"
>
> +# Disable ifuncs for libatomic on arm conflicts -march/-mcpu
> +EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
> +
> +# Building with thumb enabled on armv6t fails
> +ARM_INSTRUCTION_SET_armv6 = "arm"
> +
>  RUNTIMELIBITM = "libitm"
>  RUNTIMELIBITM_arc = ""
>  RUNTIMELIBITM_mipsarch = ""
> @@ -77,6 +83,11 @@ do_install () {
> cd ${B}/${TARGET_SYS}/$d/
> oe_runmake 'DESTDIR=${D}'
> MULTIBUILDTOP=${B}/${TARGET_SYS}/$d/ install
> done
> +   if [ -d ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include ]; then
> +   install -d ${D}${libdir}/${TARGET_SYS}/${BINV}/include
> +   mv ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include/*
> ${D}${libdir}/${TARGET_SYS}/${BINV}/include
> +   rmdir --ignore-fail-on-non-empty -p
> ${D}${libdir}/gcc/${TARGET_SYS}/${BINV}/include
> +   fi
>  

Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-16 Thread Martin Jansa
On Thu, Aug 15, 2019 at 05:05:48PM +0200, Martin Jansa wrote:
> On Tue, Aug 13, 2019 at 10:04:08AM +0100, Richard Purdie wrote:
> > On Mon, 2019-08-12 at 20:26 +, Peter Kjellerstedt wrote:
> > > Comparing that build to a corresponding do-nothing build with Thud,
> > > the time difference matches those three minutes where I have no idea
> > > what bitbake is doing now that it didn’t need to do before…
> > >  
> > > Hopefully these time degradations can be solved, because the current
> > > state of bitbake is barely usable. We also need to look into possible
> > > ways to improve the cooker output when it is running the setscene
> > > tasks so it makes some kind of sense again.
> > 
> > We talked on irc and you pointed at the commit things started to go
> > wrong. Just to summarise things for the benefit of the list, this is
> > some quick testing I did:
> > 
> > "bitbake -p; time bitbake core-image-minimal -n"
> > 
> > 30.0s 6c7c0cefd34067311144a1d4c01986fe0a4aef26
> > 30.6s a0d941c787cf3ef030d190903279d311bc05d752
> > 40.3s 7df31ff36892c2f9c65326b06b4c70 
> > 42.2s a0542ed3ff700eca35f9195f743c9e28bcd50f3e 
> > 45.4s 9983b07fffd19082abded7c3f15cc77d306dd69c 
> > 76.9s master-next
> 
> I know I'm late to the party, but it took really long for the test to finish..
> 
> I'm not using poky, so reproduce this testing on our builds I've used
> bitbake revisions matching with poky revision RP was testing:
> 
> + oe-core 18cdc087fd5da30e2b31f3d4e81b153cd36ca844 for older bitbake, because 
> current master isn't compatible with old bitbake 
> (bb.data_smart.ExpansionError: Failure expanding variable OE_IMPORTED[:=], 
> expression was ${@oe_import(d)} which triggered exception AttributeError: 
> module 'bb.siggen' has no attribute 'SignatureGeneratorUniHashMixIn')
> and oe-core 23db236a054ee7a989cdbbcb42ad5c6eefd4a6ae for newer bitbake (to 
> possibly eliminate impact of metadata changes)
> 
> tested on 72core (Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz) with 380GB RAM
> 
> nothing in TMPDIR/SSTATE_DIR, no SSTATE_MIRRO, no Hash Equivalence Server 
> configured
> 
> on a build with few more layers:
> Parsing of 3238 .bb files complete (0 cached, 3238 parsed). 7632 targets, 
> 1927 skipped, 54 masked, 0 errors.
> 
> but first doing just core-image-minimal like RP did:
> 
> time  pokybitbake 
> oe-core
> 2m8.191s  6c7c0cefd34067311144a1d4c01986fe0a4aef26
> 18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7
> 18cdc087fd5da30e2b31f3d4e81b153cd36ca844
> N/A   a0d941c787cf3ef030d190903279d311bc05d752doesn't exist 
> in poky/poky-contrib  18cdc087fd5da30e2b31f3d4e81b153cd36ca844
> 2m17.053s 7df31ff36892c2f9c65326b06b4c70  
> 1f630fdf0260db08541d3ca9f25f852931c19905
> 18cdc087fd5da30e2b31f3d4e81b153cd36ca844
> 2m18.515s a0542ed3ff700eca35f9195f743c9e28bcd50f3e
> f43778c2d19e70d4befd483b06aaf247fc65c799
> 23db236a054ee7a989cdbbcb42ad5c6eefd4a6ae
> 2m22.220s 9983b07fffd19082abded7c3f15cc77d306dd69c
> 8c26b451f22193ef1c544e2017cc84515566c1b8
> 2m38.185s master-next 
> fbcb89dc3dbabfc80310e9a4ebe72d919300a32e
> cache.py:446: ResourceWarning: unclosed  family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, 
> laddr=('127.0.0.1', 41117)>
>   value = pickled.load()
> started showing with this revision
> 2m17.991s master-next + fixups
> f7cd14f90463957b3e4be6d3876def98b78f1424
> 2m9.651s  master-next + "Holding off tasks %s" out
> 
> now world
> 253m36.637s   7df31ff36892c2f9c65326b06b4c70  
> 1f630fdf0260db08541d3ca9f25f852931c19905
> 18cdc087fd5da30e2b31f3d4e81b153cd36ca844
> 174m13.324s   a0542ed3ff700eca35f9195f743c9e28bcd50f3e
> f43778c2d19e70d4befd483b06aaf247fc65c799
> 23db236a054ee7a989cdbbcb42ad5c6eefd4a6ae
>this is time when killed at "NOTE: Executing Tasks" without showing any 
> progress on the tasks (unlike other tests) and only one bitbake process is 
> running
> 633m27.475s   master-next 
> fbcb89dc3dbabfc80310e9a4ebe72d919300a32e
>this is time when killed at (1417 from 71749) - running very slowly unlike 
> other bitbake revisions where the task number changes relatively quickly - 
> about 10 tasks per second
> 89m13.992smaster-next + "Holding off tasks %s" out
> 89m59.201smaster-next updated today   
> 85fe627fdb6510f09

Re: [OE-core] [PATCH 2/3] qemuboot.bbclass: increase the default RAM to 512M

2019-08-15 Thread Martin Jansa
Maybe we should drop x11 from default DISTRO_FEATURES :)

Will resolve the memory consumption and image size.

Well the image size isn't much different, I was just surprised to see
libx11 being included even in core-image-minimal (because systemd -> dbus
-> libx11: "dbus.do_package" -> "libx11.do_packagedata"), but in the end
the difference in ext4 was only 2MB (61MB/63MB), caused by following 4
packages:
libx11-6 core2-64 1:1.6.8-r0.0
libxau6 core2-64 1:1.0.9-r0.15
libxcb1 core2-64 1.13.1-r0.15
libxdmcp6 core2-64 1:1.1.3-r0.15

so I guess embedded no longer have neither small ram nor small flash.



On Thu, Aug 15, 2019 at 6:20 PM Alexander Kanavin 
wrote:

> On Wed, 14 Aug 2019 at 18:42, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
>
>> I'm not sure I agree with this.
>>
>> We are meant to work on embedded systems and 256MB should be enough to
>> let us bring up X under qemu.
>>
>> I'm fine with some sdk/ptest images having more memory, that makes
>> sense but 256MB not allowing X under qemu seems rather poor.
>>
>
> I poked a bit more at this. The main difference between vmware emulated
> hardware and std emulated hardware is that X uses the standard 2D
> framebuffer interface for the former, and the full 3D stack for the latter
> (via use of glamor: https://www.freedesktop.org/wiki/Software/Glamor/).
> The 3D stack (mesa and friends) is what causes the memory usage to swell.
>
> It is possible to disable this behaviour and enforce framebuffer usage
> (see 'man modesetting'), and I have verified that the RAM usage drops to
> similar levels as vmware, but that is not the upstream default; they have
> more or less obsoleted 2D drivers and are defaulting to 3D rendering
> nowadays. I'd rather follow that.
>
> Alex
>
>
> --
> ___
> 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] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-15 Thread Martin Jansa
On Tue, Aug 13, 2019 at 10:04:08AM +0100, Richard Purdie wrote:
> On Mon, 2019-08-12 at 20:26 +, Peter Kjellerstedt wrote:
> > Comparing that build to a corresponding do-nothing build with Thud,
> > the time difference matches those three minutes where I have no idea
> > what bitbake is doing now that it didn’t need to do before…
> >  
> > Hopefully these time degradations can be solved, because the current
> > state of bitbake is barely usable. We also need to look into possible
> > ways to improve the cooker output when it is running the setscene
> > tasks so it makes some kind of sense again.
> 
> We talked on irc and you pointed at the commit things started to go
> wrong. Just to summarise things for the benefit of the list, this is
> some quick testing I did:
> 
> "bitbake -p; time bitbake core-image-minimal -n"
> 
> 30.0s 6c7c0cefd34067311144a1d4c01986fe0a4aef26
> 30.6s a0d941c787cf3ef030d190903279d311bc05d752
> 40.3s 7df31ff36892c2f9c65326b06b4c70 
> 42.2s a0542ed3ff700eca35f9195f743c9e28bcd50f3e 
> 45.4s 9983b07fffd19082abded7c3f15cc77d306dd69c 
> 76.9s master-next

I know I'm late to the party, but it took really long for the test to finish..

I'm not using poky, so reproduce this testing on our builds I've used
bitbake revisions matching with poky revision RP was testing:

+ oe-core 18cdc087fd5da30e2b31f3d4e81b153cd36ca844 for older bitbake, because 
current master isn't compatible with old bitbake (bb.data_smart.ExpansionError: 
Failure expanding variable OE_IMPORTED[:=], expression was ${@oe_import(d)} 
which triggered exception AttributeError: module 'bb.siggen' has no attribute 
'SignatureGeneratorUniHashMixIn')
and oe-core 23db236a054ee7a989cdbbcb42ad5c6eefd4a6ae for newer bitbake (to 
possibly eliminate impact of metadata changes)

tested on 72core (Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz) with 380GB RAM

nothing in TMPDIR/SSTATE_DIR, no SSTATE_MIRRO, no Hash Equivalence Server 
configured

on a build with few more layers:
Parsing of 3238 .bb files complete (0 cached, 3238 parsed). 7632 targets, 1927 
skipped, 54 masked, 0 errors.

but first doing just core-image-minimal like RP did:

timepokybitbake 
oe-core
2m8.191s6c7c0cefd34067311144a1d4c01986fe0a4aef26
18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7
18cdc087fd5da30e2b31f3d4e81b153cd36ca844
N/A a0d941c787cf3ef030d190903279d311bc05d752doesn't exist 
in poky/poky-contrib  18cdc087fd5da30e2b31f3d4e81b153cd36ca844
2m17.053s   7df31ff36892c2f9c65326b06b4c70  
1f630fdf0260db08541d3ca9f25f852931c19905
18cdc087fd5da30e2b31f3d4e81b153cd36ca844
2m18.515s   a0542ed3ff700eca35f9195f743c9e28bcd50f3e
f43778c2d19e70d4befd483b06aaf247fc65c799
23db236a054ee7a989cdbbcb42ad5c6eefd4a6ae
2m22.220s   9983b07fffd19082abded7c3f15cc77d306dd69c
8c26b451f22193ef1c544e2017cc84515566c1b8
2m38.185s   master-next 
fbcb89dc3dbabfc80310e9a4ebe72d919300a32e
cache.py:446: ResourceWarning: unclosed 
  value = pickled.load()
started showing with this revision
2m17.991s   master-next + fixups
f7cd14f90463957b3e4be6d3876def98b78f1424
2m9.651smaster-next + "Holding off tasks %s" out

now world
253m36.637s 7df31ff36892c2f9c65326b06b4c70  
1f630fdf0260db08541d3ca9f25f852931c19905
18cdc087fd5da30e2b31f3d4e81b153cd36ca844
174m13.324s a0542ed3ff700eca35f9195f743c9e28bcd50f3e
f43778c2d19e70d4befd483b06aaf247fc65c799
23db236a054ee7a989cdbbcb42ad5c6eefd4a6ae
   this is time when killed at "NOTE: Executing Tasks" without showing any 
progress on the tasks (unlike other tests) and only one bitbake process is 
running
633m27.475s master-next 
fbcb89dc3dbabfc80310e9a4ebe72d919300a32e
   this is time when killed at (1417 from 71749) - running very slowly unlike 
other bitbake revisions where the task number changes relatively quickly - 
about 10 tasks per second
89m13.992s  master-next + "Holding off tasks %s" out
89m59.201s  master-next updated today   
85fe627fdb6510f0942917964386fad9d8c479c8

Interestingly old 1f630fdf0260db08541d3ca9f25f852931c19905 is 3 times
slower than recent master-next.

I'll send -P output next.

> 
> So basically the original changes showed a 25% hit but the performance
> of -next is dire.
> 
> This is with no hash equiv server configured.
> 
> It will vary depending on the target used (numbers with -sato for the
> above would be interesting for comparision) and how much was or is in
> sstate, they type of sstate mirror configured and so on.
> 
> I really need to focus on getting the new code functioning correctly
> before we attempt to optimise but if nobody tests the new code due to
> performance problems we have a different issue. We also have a scaling
> 

Re: [OE-core] [warrior][PATCH] bitbake.conf: add git-lfs to HOSTTOOLS_NONFATAL

2019-08-15 Thread Martin Jansa
NAK

Yes, the first part was merged in warrior and is correct.

But this second part isn't good (you don't want git-lfs to sometimes work
and sometimes fail) and that's why it was rejected for master and
_shouldn't_ be merged to warrior. If you have recipes which need git-lfs,
then add it to normal HOSTTOOLS in your builds to make sure it's always
present when needed.

On Thu, Aug 15, 2019 at 9:01 AM Saini, Naveen Kumar <
naveen.kumar.sa...@intel.com> wrote:

> The corresponding first patch of this patch series already merged in
> Warrior
>
>
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/bitbake/lib?h=warrior=6e3a4d7926296380da23536c29af35d5702e02fb
>
> So this patch should also go in warrior.
>
>
> On 8/15/19 2:53 PM, Naveen Saini wrote:
> > This provides git large file storage (lfs) extension.
> >
> > Include git-lfs conditionally. If git-lfs is present on host and repo
> > has lfs pointers, then git-lfs will be used. If git-lfs is not present
> > on host, it will be ignored.
> >
> > [YOCTO #13198]
> >
> > (From OE-Core rev: 2968ad8514721ec06e67aaf3fd5ec7b247b3431d)
> >
> > Signed-off-by: Naveen Saini 
> > Signed-off-by: Richard Purdie 
> > ---
> >   meta/conf/bitbake.conf | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index c996301a8b..c5313ccd19 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -514,6 +514,9 @@ HOSTTOOLS_NONFATAL += "bzr"
> >   # Used by ssh fetcher
> >   HOSTTOOLS_NONFATAL += "scp"
> >
> > +# Link to git-lfs if present
> > +HOSTTOOLS_NONFATAL += "git-lfs"
> > +
> >   CCACHE ??= ""
> >
> >   TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TARGET}"
> >
> --
> ___
> 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 v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

2019-08-14 Thread Martin Jansa
"qmake -install qinstall" reproducer from the bugzilla ticket still
reproduces the issues every time even with latest pseudo, but that might be
different root cause than glibc-locale issue.

On Wed, Aug 14, 2019 at 6:02 PM Randy MacLeod 
wrote:

> On 8/6/19 2:51 AM, Martin Jansa wrote:
> > This is the same reproducer I am using in:
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
> > but with this SRCREV I haven't reproduced it yet in first 500
> > iterations, so it's definitely improving for me (used to reproduce it at
> > least once in first 500 iterations)
> >
> > Now I'm testing the reproducer with "qmake -install qinstall".
>
> Any update Martin?
>
>
>
> Using a variation of Juro's script and adding a little stress-ng load,
> it _seems_ that I can make the problem happen more quickly than without
> system stress but it's a shared system so _seems_ is underlined.
>
> Using stress-ng was supposed to be a quick check to see if I could
> get the reproducer down to minutes rather than around an hour.
>
> Results are promising so I'll continue to use this approach as
> I add debugging to pseudo and add an inline, immediate check in
> the context of:
>
>
> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/glibc/glibc-locale.inc?h=master#n72
> to see if the UID/GID are equal to my UID/GID.
>
> Test runs summaries are below.
>
> ../Randy
>
>
>
> cat src/distro/yocto/b/uid-diff/glibc-locale-stress
> #!/bin/bash
>
> fname='glibc-locale_master_august13'
> max=100
> for (( i=1; i <= $max; i++ ))
> do
>  echo "$i/$max  ${fname}_$i.log"
>  bitbake glibc-locale -c cleanall 2>&1 > /dev/null
>  # add some stress
>  stress-ng -t 1000 --switch 8 --switch-freq 5 &
>  bitbake glibc-locale 2>&1 > ${fname}_$i.log
>  # Destress
>  killall -9 stress-ng
>  if grep -q "host-user-contaminated" ${fname}_$i.log; then
>  echo "error !"
>exit 2
>  #else
>#rm ${fname}_$i.log
>  fi
> done
>
>
> On a (shared) system where lscpu shows 128 cores
> and no stress:
>
> Trial   Iteration Error
> 1   44
> 2   19
>
>
> stress-ng -t 1000 --switch 8 --switch-freq 5
>
> 5 was just the frequency that generated a high enough
> but not too high load. On this systems, each process used ~30% of a cpu.
>
> Trial   Iteration Error
> 1   3
> 2   18
>
>
> stress-ng -t 1000 --switch 16 --switch-freq 5
>
> Trial   Iteration Error
> 1   3
> 2   1
> 3   11
>
> stress-ng -t 1000 --switch 32 --switch-freq 5
>
> Trial   Iteration Error
> 1   2
> 2   9
> 3   8
>
>
> stress-ng -t 1000 --switch 64 --switch-freq 5
>
> Trial   Iteration Error
> 1   4
> 2   13
> 3   >6
>
>
> stress-ng -t 1000 --mq 64
>   128 processes using 98% cpu each
>
> Trial   Iteration Error
> 1   14
> 2   NaN
>
> Trial 2 was precluded by other users of the shared system complaining!
> The idea was to cause more rapid context switches. Later, I might try
> this again with say 16 workers. If anyone has a better idea, please
> reply.
>
> EOM
>
> >
> > Regards,
> >
> > On Tue, Aug 6, 2019 at 12:43 AM Bystricky, Juro
> > mailto:juro.bystri...@intel.com>> wrote:
> >
> > I can reproduce the problem fairly easily  (and, sadly even with the
> > latest commits as 060058bb29f70b244e685b3c704eb0641b736f73 ).
> > In my case, it seems easy to reproduce if I have 40+ threads running.
> > The reproducer script (below) fails typically within the first 10
> > iterations.
> >
> >
> > #!/bin/bash
> >
> > fname='glibc-locale_master_august8'
> > max=1000
> > for (( i=1; i <= $max; i++ ))
> > do
> >  echo "$i/$max  ${fname}_$i.log"
> >  bitbake glibc-locale -c cleanall 2>&1 > /dev/null
> >  bitbake glibc-locale 2>&1 > ${fname}_$i.log
> >   if grep -q "host-user-contaminated" ${fname}_$i.log; then
> >  echo "error !"
> >exit 2
> >  #else
> >#rm ${fname}_$i.log
> >  fi
> >
> > done
> >
> > 
> > From: openembedded-core-boun...@lists.openembedded.org
> > <mailto:openembedded-core-boun...@lists.openembedded.org>
> > [openembedded-core-boun...@lists.openembedded.or

[OE-core] [PATCHv2] meson: backport fix for builds with -Werror=return-type

2019-08-13 Thread Martin Jansa
Signed-off-by: Martin Jansa 
---
 meta/recipes-devtools/meson/meson.inc |   1 +
 ...rn-statements-that-are-seen-with-Wer.patch | 100 ++
 2 files changed, 101 insertions(+)
 create mode 100644 
meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
index 662368e219..14e5f8a610 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -16,6 +16,7 @@ SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P

file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \

file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
file://vala-cross-compile.patch \
+   
file://0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch \
"
 SRC_URI[sha256sum] = 
"f27b7a60f339ba66fe4b8f81f0d1072e090a08eabbd6aa287683b2c2b9dd2d82"
 SRC_URI[md5sum] = "48787e391ec5c052799a3dd491f73909"
diff --git 
a/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
 
b/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
new file mode 100644
index 00..16c6d90761
--- /dev/null
+++ 
b/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
@@ -0,0 +1,100 @@
+From 15f44be1c7f71cb0a8c6863917acbbc301c621fe Mon Sep 17 00:00:00 2001
+From: Martin Liska 
+Date: Mon, 15 Jul 2019 10:06:17 +0200
+Subject: [PATCH] Fix missing return statements that are seen with
+ -Werror=return-type.
+
+Error example:
+
+Code:
+
+#include 
+int main () {
+/* If it's not defined as a macro, try to use as a symbol */
+#ifndef LC_MESSAGES
+LC_MESSAGES;
+#endif
+}
+Compiler stdout:
+
+Compiler stderr:
+ In file included from /usr/include/locale.h:25,
+ from /tmp/tmpep_i4iwg/testfile.c:2:
+/usr/include/features.h:382:4: warning: #warning _FORTIFY_SOURCE
+requires compiling with optimization (-O) [-Wcpp]
+  382 | #  warning _FORTIFY_SOURCE requires compiling with optimization
+(-O)
+  |^~~
+/tmp/tmpep_i4iwg/testfile.c: In function 'main':
+/tmp/tmpep_i4iwg/testfile.c:8:9: error: control reaches end of non-void
+function [-Werror=return-type]
+8 | }
+  | ^
+cc1: some warnings being treated as errors
+
+Upstream-Status: Backport
+Signed-off-by: Martin Jansa 
+---
+ mesonbuild/compilers/c.py | 1 +
+ mesonbuild/compilers/clike.py | 5 +
+ 2 files changed, 6 insertions(+)
+
+diff --git a/mesonbuild/compilers/c.py b/mesonbuild/compilers/c.py
+index 3b58a076..9ef92077 100644
+--- a/mesonbuild/compilers/c.py
 b/mesonbuild/compilers/c.py
+@@ -70,6 +70,7 @@ class CCompiler(CLikeCompiler, Compiler):
+ #ifndef {symbol}
+ {symbol};
+ #endif
++return 0;
+ }}'''
+ return self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)
+diff --git a/mesonbuild/compilers/clike.py b/mesonbuild/compilers/clike.py
+index 83f67591..f9cbeabd 100644
+--- a/mesonbuild/compilers/clike.py
 b/mesonbuild/compilers/clike.py
+@@ -375,6 +375,7 @@ class CLikeCompiler:
+ #ifndef {symbol}
+ {symbol};
+ #endif
++return 0;
+ }}'''
+ return self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)
+@@ -554,6 +555,7 @@ class CLikeCompiler:
+ {prefix}
+ int main(int argc, char **argv) {{
+ {type} something;
++return 0;
+ }}'''
+ if not self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)[0]:
+@@ -589,6 +591,7 @@ class CLikeCompiler:
+ {prefix}
+ int main(int argc, char **argv) {{
+ {type} something;
++return 0;
+ }}'''
+ if not self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)[0]:
+@@ -667,6 +670,7 @@ class CLikeCompiler:
+ #include 
+ int main(int argc, char *argv[]) {{
+ printf ("{fmt}", {cast} {f}());
++return 0;
+ }}'''.format(**fargs)
+ res = self.run(code, env, extra_args=extra_args, 
dependencies=dependencies)
+ if not res.compiled:
+@@ -819,6 +823,7 @@ class CLikeCompiler:
+ #error "No definition for __builtin_{func} found in the 
prefix"
+ #endif
+ #endif
++return 0;
+ }}'''
+ return self.links(t.format(**fargs), env, extra_args=extra_args,
+  

[OE-core] [yocto-docs][PATCH] ref-manual: mention PREPROCESS_RELOCATE_DIRS variable

2019-08-12 Thread Martin Jansa
Signed-off-by: Martin Jansa 
---
 documentation/ref-manual/ref-classes.xml   |  5 -
 documentation/ref-manual/ref-variables.xml | 21 +
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/documentation/ref-manual/ref-classes.xml 
b/documentation/ref-manual/ref-classes.xml
index ece47e757..159efb3b1 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -413,7 +413,10 @@
 cross, and
 cross-canadian recipes to change
 RPATH records within binaries in order to make
-them relocatable.
+them relocatable. To extend the list of directories where it searches
+for binaries to relocate, you can set
+PREPROCESS_RELOCATE_DIRS
+variable in your recipe.
 
 
 
diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index 9470a780a..5ac766658 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -11424,6 +11424,27 @@
 
 
 
+PREPROCESS_RELOCATE_DIRS
+
+PREPROCESS_RELOCATE_DIRS[doc] = "List of extra directories 
where to search for binaries which should be relocatable."
+
+
+
+
+List of extra directories with binaries.
+
+
+
+PREPROCESS_RELOCATE_DIRS is used by
+chrpath.bbclass to allow extending the list where it 
searches
+for binaries. By default it searches in:
+${bindir} ${sbindir} ${base_sbindir} ${base_bindir} 
${libdir} ${base_libdir} ${libexecdir}
+Thus, PREPROCESS_RELOCATE_DIRS 
usually doesn't
+need to be set withing recipes.
+
+
+
+
 PRIORITY
 
 PRIORITY[doc] = "Indicates the importance of a package.  The 
default value is 'optional'.  Other standard values are 'required', 'standard', 
and 'extra'."
-- 
2.17.1

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


Re: [OE-core] [oe-core] [BUG] patch linux-firmware: bump to 20190618 breaks package index

2019-08-12 Thread Martin Jansa
PE was dropped, so version definitely went backwards and QA is right to
complain.

On Mon, Aug 12, 2019 at 3:41 PM Oleksandr Kravchuk <
open.sou...@oleksandr-kravchuk.com> wrote:

> Hi Nicola,
>
> How do I reproduce this? It builds fine for me.
>
> On 12/08/2019 15:38, nick83ola wrote:
> > Hi all
> > after this patch I got a ton of errors regarding Package version went
> backwards
> >
> > Cheers
> > Nicola Lunghi
> >
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-src went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-dbg went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-ralink-license went backwards which
> > would break package feeds from (1:0.0+git0+711d3297ba-r0 to
> > 0:20190618-r0) [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-ralink went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-mt7601u-license went backwards
> > which would break package feeds from (1:0.0+git0+711d3297ba-r0 to
> > 0:20190618-r0) [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-mt7601u went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-radeon-license went backwards which
> > would break package feeds from (1:0.0+git0+711d3297ba-r0 to
> > 0:20190618-r0) [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-radeon went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-marvell-license went backwards
> > which would break package feeds from (1:0.0+git0+711d3297ba-r0 to
> > 0:20190618-r0) [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-pcie8897 went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-pcie8997 went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-sd8686 went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-sd8688 went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-sd8787 went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-sd8797 went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-sd8801 went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-sd8887 went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > version for package linux-firmware-sd8897 went backwards which would
> > break package feeds from (1:0.0+git0+711d3297ba-r0 to 0:20190618-r0)
> > [version-going-backwards]
> > ERROR: linux-firmware-20190618-r0 do_packagedata: QA Issue: Package
> > 

[OE-core] [PATCHv2 1/2] icecc.bbclass: catch subprocess.CalledProcessError

2019-08-12 Thread Martin Jansa
"
if [ "x${ICECC_VERSION}" = "x" ]
then
bbwarn "Cannot use icecc: could not get ICECC_VERSION"
return
fi

ICE_PATH="${@icecc_path(bb, d)}"
if [ "x${ICE_PATH}" = "x" ]
then
bbwarn "Cannot use icecc: could not get ICE_PATH"
return
fi

ICECC_BIN="${@get_icecc(d)}"
if [ -z "${ICECC_BIN}" ]; then
bbwarn "Cannot use icecc: icecc binary not found"
return
fi
if [ -z "$(which patchelf patchelf-uninative)" ]; then
bbwarn "Cannot use icecc: patchelf not found"
return
fi

# Create symlinks to icecc in the recipe-sysroot directory
mkdir -p ${ICE_PATH}
if [ -n "${KERNEL_CC}" ]; then
compilers="${@get_cross_kernel_cc(bb,d)}"
else
compilers="x86_64-oe-linux-gcc x86_64-oe-linux-g++"
fi
for compiler in $compilers; do
ln -sf ${ICECC_BIN} ${ICE_PATH}/$compiler
done

ICECC_CC="${@icecc_get_and_check_tool(bb, d, "gcc")}"
ICECC_CXX="${@icecc_get_and_check_tool(bb, d, "g++")}"
# cannot use icecc_get_and_check_tool here because it assumes as without 
target_sys prefix
ICECC_WHICH_AS="${@bb.utils.which(os.getenv('PATH'), 'as')}"
if [ ! -x "${ICECC_CC}" -o ! -x "${ICECC_CXX}" ]
then
bbwarn "Cannot use icecc: could not get ICECC_CC or ICECC_CXX"
return
fi

ICE_VERSION=`$ICECC_CC -dumpversion`
ICECC_VERSION=`echo ${ICECC_VERSION} | sed -e "s/@VERSION@/$ICE_VERSION/g"`
if [ ! -x 
"/build/BUILD/work/qemux86-oe-linux/python-markupsafe/1.0-r0/recipe-sysroot-native/usr/bin/icecc-create-env"
 ]
then
bbwarn "Cannot use icecc: invalid ICECC_ENV_EXEC"
return
fi

ICECC_AS="`${ICECC_CC} -print-prog-name=as`"
# for target recipes should return something like:
# 
/OE/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/arm920tt-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.8.2/as
# and just "as" for native, if it returns "as" in current directory (for 
whatever reason) use "as" from PATH
if [ "`dirname "${ICECC_AS}"`" = "." ]
then
ICECC_AS="${ICECC_WHICH_AS}"
fi

if [ ! -f "${ICECC_VERSION}.done" ]
then
mkdir -p "`dirname "${ICECC_VERSION}"`"

# the ICECC_VERSION generation step must be locked by a mutex
# in order to prevent race conditions
if flock -n "${ICECC_VERSION}.lock" \

/build/BUILD/work/qemux86-oe-linux/python-markupsafe/1.0-r0/recipe-sysroot-native/usr/bin/icecc-create-env
  "${ICECC_CC}" "${ICECC_CXX}" "${ICECC_AS}" "${ICECC_VERSION}"
then
touch "${ICECC_VERSION}.done"
elif ! wait_for_file "${ICECC_VERSION}.done" 30
then
# locking failed so wait for ${ICECC_VERSION}.done to appear
bbwarn "Timeout waiting for ${ICECC_VERSION}.done"
return
fi
fi

# Don't let ccache find the icecream compiler links that have been created, 
otherwise
# it can end up invoking icecream recursively.
export CCACHE_PATH="$PATH"
export CCACHE_DISABLE="1"

export ICECC_VERSION ICECC_CC ICECC_CXX
export PATH="$ICE_PATH:$PATH"

bbnote "Using icecc path: $ICE_PATH"
bbnote "Using icecc tarball: $ICECC_VERSION"
 which triggered exception CalledProcessError: Command 'readlink -f 
/build/BUILD/work/qemux86-oe-linux/python-markupsafe/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux/x86_64-oe-linux-g++'
 returned non-zero exit status 1.

ERROR: Task 
(virtual:multilib:lib32:/build/meta-oe/meta-python/recipes-devtools/python/python-markupsafe_1.0.bb:do_patch)
 failed with exit code '1'

Signed-off-by: Martin Jansa 
---
 meta/classes/icecc.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index 095518115f..78a2f7602d 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -243,7 +243,11 @@ def icecc_get_external_tool(bb, d, tool):
 
 def icecc_get_tool_link(tool, d):
 import subprocess
-return subprocess.check_output("readlink -f %s" % tool, 
shell=True).decode("utf-8")[:-1]
+try:
+return subprocess.check_output("readlink -f %s" % tool, 
shell=True).decode("utf-8")[:-1]
+except subprocess.CalledProcessError as e:
+bb.note("icecc: one of the tools probably disappeared during recipe 
parsing, cmd readlink -f %s returned %d:\n%s" % (tool, e.returncode, 
e.output.decode("utf-8")))
+return tool
 
 def icecc_get_path_tool(tool, d):
 # This is a little ugly, but we want to make sure we add an actual
-- 
2.17.1

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


[OE-core] [PATCHv2 2/2] powertop: import a fix from buildroot

2019-08-12 Thread Martin Jansa
Signed-off-by: Martin Jansa 
---
 .../0001-wakeup_xxx.h-include-limits.h.patch  | 55 +++
 meta/recipes-kernel/powertop/powertop_2.10.bb |  1 +
 2 files changed, 56 insertions(+)
 create mode 100644 
meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch

diff --git 
a/meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch
 
b/meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch
new file mode 100644
index 00..7bfca8abfd
--- /dev/null
+++ 
b/meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch
@@ -0,0 +1,55 @@
+From 4c24fdd8e0a42359df7308155b2d43c28a5e02fd Mon Sep 17 00:00:00 2001
+From: Fabrice Fontaine 
+Date: Mon, 20 May 2019 20:25:00 +0200
+Subject: [PATCH] wakeup_xxx.h: include limits.h
+
+limits.h must be included to define PATH_MAX otherwise build will fail
+on:
+
+In file included from wakeup/wakeup_ethernet.cpp:45:0:
+wakeup/wakeup_ethernet.h:35:16: error: 'PATH_MAX' was not declared in this 
scope
+  char eth_path[PATH_MAX];
+
+In file included from wakeup/wakeup_usb.cpp:45:0:
+wakeup/wakeup_usb.h:35:16: error: 'PATH_MAX' was not declared in this scope
+  char usb_path[PATH_MAX];
+
+Fixes:
+ - 
http://autobuild.buildroot.org/results/a0b3337cf4a827e6566f8b15b6bb180f0dcef7a3
+
+Signed-off-by: Fabrice Fontaine 
+Signed-off-by: Martin Jansa 
+
+Upstream-Status: Submitted 
[https://lists.01.org/pipermail/powertop/2019-May/002052.html]
+---
+ src/wakeup/wakeup_ethernet.h | 1 +
+ src/wakeup/wakeup_usb.h  | 1 +
+ 2 files changed, 2 insertions(+)
+
+diff --git a/src/wakeup/wakeup_ethernet.h b/src/wakeup/wakeup_ethernet.h
+index 682bf95..e0fa628 100644
+--- a/src/wakeup/wakeup_ethernet.h
 b/src/wakeup/wakeup_ethernet.h
+@@ -25,6 +25,7 @@
+ #ifndef _INCLUDE_GUARD_ETHERNET_WAKEUP_H
+ #define _INCLUDE_GUARD_ETHERNET_WAKEUP_H
+ 
++#include 
+ #include 
+ 
+ #include "wakeup.h"
+diff --git a/src/wakeup/wakeup_usb.h b/src/wakeup/wakeup_usb.h
+index f7a1f7e..15898e3 100644
+--- a/src/wakeup/wakeup_usb.h
 b/src/wakeup/wakeup_usb.h
+@@ -25,6 +25,7 @@
+ #ifndef _INCLUDE_GUARD_USB_WAKEUP_H
+ #define _INCLUDE_GUARD_USB_WAKEUP_H
+ 
++#include 
+ #include 
+ 
+ #include "wakeup.h"
+-- 
+2.20.1
+
diff --git a/meta/recipes-kernel/powertop/powertop_2.10.bb 
b/meta/recipes-kernel/powertop/powertop_2.10.bb
index d943ba9f6e..5be8d23111 100644
--- a/meta/recipes-kernel/powertop/powertop_2.10.bb
+++ b/meta/recipes-kernel/powertop/powertop_2.10.bb
@@ -7,6 +7,7 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"
 
 SRC_URI = "http://01.org/sites/default/files/downloads/powertop-v${PV}.tar.gz \
+file://0001-wakeup_xxx.h-include-limits.h.patch \
 "
 
 SRC_URI[md5sum] = "a69bd55901cf919cc564187402ea2c9c"
-- 
2.17.1

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


[OE-core] [PATCH 2/2] meson: backport fix for builds with -Werror=return-type

2019-08-12 Thread Martin Jansa
Signed-off-by: Martin Jansa 
---
 meta/recipes-devtools/meson/meson.inc |   1 +
 ...rn-statements-that-are-seen-with-Wer.patch | 100 ++
 2 files changed, 101 insertions(+)
 create mode 100644 
meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
index 662368e219..14e5f8a610 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -16,6 +16,7 @@ SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P

file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \

file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
file://vala-cross-compile.patch \
+   
file://0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch \
"
 SRC_URI[sha256sum] = 
"f27b7a60f339ba66fe4b8f81f0d1072e090a08eabbd6aa287683b2c2b9dd2d82"
 SRC_URI[md5sum] = "48787e391ec5c052799a3dd491f73909"
diff --git 
a/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
 
b/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
new file mode 100644
index 00..16c6d90761
--- /dev/null
+++ 
b/meta/recipes-devtools/meson/meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
@@ -0,0 +1,100 @@
+From 15f44be1c7f71cb0a8c6863917acbbc301c621fe Mon Sep 17 00:00:00 2001
+From: Martin Liska 
+Date: Mon, 15 Jul 2019 10:06:17 +0200
+Subject: [PATCH] Fix missing return statements that are seen with
+ -Werror=return-type.
+
+Error example:
+
+Code:
+
+#include 
+int main () {
+/* If it's not defined as a macro, try to use as a symbol */
+#ifndef LC_MESSAGES
+LC_MESSAGES;
+#endif
+}
+Compiler stdout:
+
+Compiler stderr:
+ In file included from /usr/include/locale.h:25,
+ from /tmp/tmpep_i4iwg/testfile.c:2:
+/usr/include/features.h:382:4: warning: #warning _FORTIFY_SOURCE
+requires compiling with optimization (-O) [-Wcpp]
+  382 | #  warning _FORTIFY_SOURCE requires compiling with optimization
+(-O)
+  |^~~
+/tmp/tmpep_i4iwg/testfile.c: In function 'main':
+/tmp/tmpep_i4iwg/testfile.c:8:9: error: control reaches end of non-void
+function [-Werror=return-type]
+8 | }
+  | ^
+cc1: some warnings being treated as errors
+
+Upstream-Status: Backport
+Signed-off-by: Martin Jansa 
+---
+ mesonbuild/compilers/c.py | 1 +
+ mesonbuild/compilers/clike.py | 5 +
+ 2 files changed, 6 insertions(+)
+
+diff --git a/mesonbuild/compilers/c.py b/mesonbuild/compilers/c.py
+index 3b58a076..9ef92077 100644
+--- a/mesonbuild/compilers/c.py
 b/mesonbuild/compilers/c.py
+@@ -70,6 +70,7 @@ class CCompiler(CLikeCompiler, Compiler):
+ #ifndef {symbol}
+ {symbol};
+ #endif
++return 0;
+ }}'''
+ return self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)
+diff --git a/mesonbuild/compilers/clike.py b/mesonbuild/compilers/clike.py
+index 83f67591..f9cbeabd 100644
+--- a/mesonbuild/compilers/clike.py
 b/mesonbuild/compilers/clike.py
+@@ -375,6 +375,7 @@ class CLikeCompiler:
+ #ifndef {symbol}
+ {symbol};
+ #endif
++return 0;
+ }}'''
+ return self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)
+@@ -554,6 +555,7 @@ class CLikeCompiler:
+ {prefix}
+ int main(int argc, char **argv) {{
+ {type} something;
++return 0;
+ }}'''
+ if not self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)[0]:
+@@ -589,6 +591,7 @@ class CLikeCompiler:
+ {prefix}
+ int main(int argc, char **argv) {{
+ {type} something;
++return 0;
+ }}'''
+ if not self.compiles(t.format(**fargs), env, extra_args=extra_args,
+  dependencies=dependencies)[0]:
+@@ -667,6 +670,7 @@ class CLikeCompiler:
+ #include 
+ int main(int argc, char *argv[]) {{
+ printf ("{fmt}", {cast} {f}());
++return 0;
+ }}'''.format(**fargs)
+ res = self.run(code, env, extra_args=extra_args, 
dependencies=dependencies)
+ if not res.compiled:
+@@ -819,6 +823,7 @@ class CLikeCompiler:
+ #error "No definition for __builtin_{func} found in the 
prefix"
+ #endif
+ #endif
++return 0;
+ }}'''
+ return self.links(t.format(**fargs), env, extra_args=extra_args,
+  

[OE-core] [PATCH 1/2] powertop: import a fix from buildroot

2019-08-12 Thread Martin Jansa
Signed-off-by: Martin Jansa 
---
 .../0001-wakeup_xxx.h-include-limits.h.patch  | 55 +++
 meta/recipes-kernel/powertop/powertop_2.10.bb |  1 +
 2 files changed, 56 insertions(+)
 create mode 100644 
meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch

diff --git 
a/meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch
 
b/meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch
new file mode 100644
index 00..f1a05fcd75
--- /dev/null
+++ 
b/meta/recipes-kernel/powertop/powertop/0001-wakeup_xxx.h-include-limits.h.patch
@@ -0,0 +1,55 @@
+From 4c24fdd8e0a42359df7308155b2d43c28a5e02fd Mon Sep 17 00:00:00 2001
+From: Fabrice Fontaine 
+Date: Mon, 20 May 2019 20:25:00 +0200
+Subject: [PATCH] wakeup_xxx.h: include limits.h
+
+limits.h must be included to define PATH_MAX otherwise build will fail
+on:
+
+In file included from wakeup/wakeup_ethernet.cpp:45:0:
+wakeup/wakeup_ethernet.h:35:16: error: 'PATH_MAX' was not declared in this 
scope
+  char eth_path[PATH_MAX];
+
+In file included from wakeup/wakeup_usb.cpp:45:0:
+wakeup/wakeup_usb.h:35:16: error: 'PATH_MAX' was not declared in this scope
+  char usb_path[PATH_MAX];
+
+Fixes:
+ - 
http://autobuild.buildroot.org/results/a0b3337cf4a827e6566f8b15b6bb180f0dcef7a3
+
+Signed-off-by: Fabrice Fontaine 
+Signed-off-by: Martin Jansa 
+
+Upstream-Status: Submitted 
https://lists.01.org/pipermail/powertop/2019-May/002052.html]
+---
+ src/wakeup/wakeup_ethernet.h | 1 +
+ src/wakeup/wakeup_usb.h  | 1 +
+ 2 files changed, 2 insertions(+)
+
+diff --git a/src/wakeup/wakeup_ethernet.h b/src/wakeup/wakeup_ethernet.h
+index 682bf95..e0fa628 100644
+--- a/src/wakeup/wakeup_ethernet.h
 b/src/wakeup/wakeup_ethernet.h
+@@ -25,6 +25,7 @@
+ #ifndef _INCLUDE_GUARD_ETHERNET_WAKEUP_H
+ #define _INCLUDE_GUARD_ETHERNET_WAKEUP_H
+ 
++#include 
+ #include 
+ 
+ #include "wakeup.h"
+diff --git a/src/wakeup/wakeup_usb.h b/src/wakeup/wakeup_usb.h
+index f7a1f7e..15898e3 100644
+--- a/src/wakeup/wakeup_usb.h
 b/src/wakeup/wakeup_usb.h
+@@ -25,6 +25,7 @@
+ #ifndef _INCLUDE_GUARD_USB_WAKEUP_H
+ #define _INCLUDE_GUARD_USB_WAKEUP_H
+ 
++#include 
+ #include 
+ 
+ #include "wakeup.h"
+-- 
+2.20.1
+
diff --git a/meta/recipes-kernel/powertop/powertop_2.10.bb 
b/meta/recipes-kernel/powertop/powertop_2.10.bb
index d943ba9f6e..5be8d23111 100644
--- a/meta/recipes-kernel/powertop/powertop_2.10.bb
+++ b/meta/recipes-kernel/powertop/powertop_2.10.bb
@@ -7,6 +7,7 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e"
 
 SRC_URI = "http://01.org/sites/default/files/downloads/powertop-v${PV}.tar.gz \
+file://0001-wakeup_xxx.h-include-limits.h.patch \
 "
 
 SRC_URI[md5sum] = "a69bd55901cf919cc564187402ea2c9c"
-- 
2.17.1

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


Re: [OE-core] [PATCH 1/1] stress-ng: Add bash to DEPENDS

2019-08-06 Thread Martin Jansa
Maybe another case of
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9217#c6 ?

On Tue, Aug 6, 2019 at 1:57 PM Alexander Kanavin 
wrote:

> On Tue, 6 Aug 2019 at 13:18, Ross Burton  wrote:
>
>> > Note that bash-completion files are not executable, and we do not
>> > observe this with other recipes. We might have a false positive here -
>> > can you look at the actual contents of the package please and see why
>> > _qa thinks it needs /bin/bash?
>>
>> Also I don't see this with master.  Do you have some local patches or QA
>> changes?
>>
>
> Actually there is a determinism problem here. I have reproduced it with
> master, and the error happens if and only if bash's do_package task has not
> yet run. If it has already run, then the package_qa for stress-ng passes
> fine. I'll poke at it to see if it's a recent issue.
>
> Alex
> --
> ___
> 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 v2] pseudo: Upgrade to latest to fix openat() with a directory symlink [NAK]

2019-08-06 Thread Martin Jansa
This is the same reproducer I am using in:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
but with this SRCREV I haven't reproduced it yet in first 500 iterations,
so it's definitely improving for me (used to reproduce it at least once in
first 500 iterations)

Now I'm testing the reproducer with "qmake -install qinstall".

Regards,

On Tue, Aug 6, 2019 at 12:43 AM Bystricky, Juro 
wrote:

> I can reproduce the problem fairly easily  (and, sadly even with the
> latest commits as 060058bb29f70b244e685b3c704eb0641b736f73 ).
> In my case, it seems easy to reproduce if I have 40+ threads running.
> The reproducer script (below) fails typically within the first 10
> iterations.
>
>
> #!/bin/bash
>
> fname='glibc-locale_master_august8'
> max=1000
> for (( i=1; i <= $max; i++ ))
> do
> echo "$i/$max  ${fname}_$i.log"
> bitbake glibc-locale -c cleanall 2>&1 > /dev/null
> bitbake glibc-locale 2>&1 > ${fname}_$i.log
>  if grep -q "host-user-contaminated" ${fname}_$i.log; then
> echo "error !"
>   exit 2
> #else
>   #rm ${fname}_$i.log
> fi
>
> done
>
> 
> From: openembedded-core-boun...@lists.openembedded.org [
> openembedded-core-boun...@lists.openembedded.org] on behalf of Seebs [
> se...@seebs.net]
> Sent: Saturday, August 03, 2019 7:23 AM
> To: Khem Raj
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH v2] pseudo: Upgrade to latest to fix
> openat() with a directory symlink [NAK]
>
> On Sat, 3 Aug 2019 05:33:46 -0700
> Khem Raj  wrote:
>
> > Will this fix the file ownership issue that we see with Glibc-locale
> > packages from time to time?
>
> I have no idea. Since I haven't got a reliable reproducer for it, I
> can't test it in a sane way.
>
> -s
> --
> ___
> 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
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] opkg/package/rootfs_ipk: allow overwriting OPKGLIBDIR

2019-07-17 Thread Martin Jansa
On Wed, Jul 17, 2019 at 04:41:01PM +0200, Martin Jansa wrote:
> On Wed, Jul 17, 2019 at 05:17:30PM +0300, Adrian Ratiu wrote:
> > On Wed, 17 Jul 2019, Martin Jansa  wrote:
> > > On Wed, Jul 17, 2019 at 02:52:21PM +0300, Adrian Ratiu wrote: 
> > >> Hi  On Wed, 17 Jul 2019, Martin Jansa  
> > >> wrote: 
> > >> > Why don't you overwrite it with an override? We're doing that 
> > >> > for years without any issues. 
> > >>  You mean a distro-wide override in a .conf? 
> > > 
> > > yes 
> > > 
> > >> Can you please point to an example? 
> > > 
> > > https://github.com/webosose/meta-webosose/blob/master/meta-webos/conf/distro/include/webos.inc#L256
> > >  
> > 
> > Thanks, I didn't know about the _forcevariable override.
> > 
> > Is using _forcevariable the preferred method to do this though 
> > instead of using ??= ?
> > 
> > The reference manual says it's not recommended and a "worst case" 
> > solution...
> 
> You can use any other override from OVERRIDES variables which covers all
> cases you want to cover.
> 
> I was using ${DISTRO} before, but switched to forcevariable later,
> because I needed to cover more DISTROs at the same time.
> 
> https://github.com/openwebos/meta-webos/commit/8c79f89fac09364e5ce494ee5fab133e7734583f#diff-e2b7938279c801074fb285c60acf2228
> 
> forcevariable is OK as long as you know what you're doing, if your
> distro really enforces different OPKGLIBDIR for good reason, then the
> users probably won't ever need to override it again locally.
> 
> Using ??= for every variable, just because someone somewhere might
> prefer different value doesn't look much better IMHO.

Also see first bullet point of the commit referenced above:
http://lists.openembedded.org/pipermail/openembedded-core/2013-February/192720.html
so making it easily to change this variable is just allowing more people
to break u-a more easily.

> Cheers,
> 
> > >
> > >> > On Wed, Jul 17, 2019 at 12:01 AM Adrian Ratiu 
> > >> > 
> > >> > wrote:
> > >> >
> > >> >> Some distributions for various reasons (like for example mounting a
> > >> >> tmpfs over /var at runtime) can't use /var/lib to store the opkg
> > >> >> metadata, so a different path is required to have a functioning
> > >> >> package manager.
> > >> >>
> > >> >> ${localstatedir} can't be modified to something other than the
> > >> >> hardcoded value in bitbake.conf because other recipes depending on it
> > >> >> will fail to install.
> > >> >>
> > >> >> So the only recourse, which is also the least invasive, is to allow
> > >> >> distros to overwrite the OPKGLIBDIR variable just like they are also
> > >> >> allowed to overwrite OPKGBUILDCMD.
> > >> >>
> > >> >> Signed-off-by: Adrian Ratiu 
> > >> >> ---
> > >> >>  meta/classes/package_ipk.bbclass | 2 +-
> > >> >>  meta/classes/rootfs_ipk.bbclass  | 2 +-
> > >> >>  meta/recipes-devtools/opkg/opkg_0.4.1.bb | 2 +-
> > >> >>  3 files changed, 3 insertions(+), 3 deletions(-)
> > >> >>
> > >> >> diff --git a/meta/classes/package_ipk.bbclass
> > >> >> b/meta/classes/package_ipk.bbclass
> > >> >> index d1b317b42b..9f9da2f91d 100644
> > >> >> --- a/meta/classes/package_ipk.bbclass
> > >> >> +++ b/meta/classes/package_ipk.bbclass
> > >> >> @@ -14,7 +14,7 @@ OPKG_ARGS += "--force_postinstall
> > >> >> --prefer-arch-to-version"
> > >> >>  OPKG_ARGS += "${@['',
> > >> >> '--no-install-recommends'][d.getVar("NO_RECOMMENDATIONS") == "1"]}"
> > >> >>  OPKG_ARGS += "${@['', '--add-exclude ' + ' --add-exclude
> > >> >> '.join((d.getVar('PACKAGE_EXCLUDE') or
> > >> >> "").split())][(d.getVar("PACKAGE_EXCLUDE") or "").strip() != ""]}"
> > >> >>
> > >> >> -OPKGLIBDIR = "${localstatedir}/lib"
> > >> >> +OPKGLIBDIR ??= "${localstatedir}/lib"
> > >> >>
> > >> >>  python do_package_ipk () {
> > >> >>  workdir = d.getVar('WORKDIR')
> > >> >> diff --git a/meta/classes/rootfs_ipk.b

Re: [OE-core] [PATCH] opkg/package/rootfs_ipk: allow overwriting OPKGLIBDIR

2019-07-17 Thread Martin Jansa
On Wed, Jul 17, 2019 at 05:17:30PM +0300, Adrian Ratiu wrote:
> On Wed, 17 Jul 2019, Martin Jansa  wrote:
> > On Wed, Jul 17, 2019 at 02:52:21PM +0300, Adrian Ratiu wrote: 
> >> Hi  On Wed, 17 Jul 2019, Martin Jansa  
> >> wrote: 
> >> > Why don't you overwrite it with an override? We're doing that 
> >> > for years without any issues. 
> >>  You mean a distro-wide override in a .conf? 
> > 
> > yes 
> > 
> >> Can you please point to an example? 
> > 
> > https://github.com/webosose/meta-webosose/blob/master/meta-webos/conf/distro/include/webos.inc#L256
> >  
> 
> Thanks, I didn't know about the _forcevariable override.
> 
> Is using _forcevariable the preferred method to do this though 
> instead of using ??= ?
> 
> The reference manual says it's not recommended and a "worst case" 
> solution...

You can use any other override from OVERRIDES variables which covers all
cases you want to cover.

I was using ${DISTRO} before, but switched to forcevariable later,
because I needed to cover more DISTROs at the same time.

https://github.com/openwebos/meta-webos/commit/8c79f89fac09364e5ce494ee5fab133e7734583f#diff-e2b7938279c801074fb285c60acf2228

forcevariable is OK as long as you know what you're doing, if your
distro really enforces different OPKGLIBDIR for good reason, then the
users probably won't ever need to override it again locally.

Using ??= for every variable, just because someone somewhere might
prefer different value doesn't look much better IMHO.

Cheers,

> >
> >> > On Wed, Jul 17, 2019 at 12:01 AM Adrian Ratiu 
> >> > 
> >> > wrote:
> >> >
> >> >> Some distributions for various reasons (like for example mounting a
> >> >> tmpfs over /var at runtime) can't use /var/lib to store the opkg
> >> >> metadata, so a different path is required to have a functioning
> >> >> package manager.
> >> >>
> >> >> ${localstatedir} can't be modified to something other than the
> >> >> hardcoded value in bitbake.conf because other recipes depending on it
> >> >> will fail to install.
> >> >>
> >> >> So the only recourse, which is also the least invasive, is to allow
> >> >> distros to overwrite the OPKGLIBDIR variable just like they are also
> >> >> allowed to overwrite OPKGBUILDCMD.
> >> >>
> >> >> Signed-off-by: Adrian Ratiu 
> >> >> ---
> >> >>  meta/classes/package_ipk.bbclass | 2 +-
> >> >>  meta/classes/rootfs_ipk.bbclass  | 2 +-
> >> >>  meta/recipes-devtools/opkg/opkg_0.4.1.bb | 2 +-
> >> >>  3 files changed, 3 insertions(+), 3 deletions(-)
> >> >>
> >> >> diff --git a/meta/classes/package_ipk.bbclass
> >> >> b/meta/classes/package_ipk.bbclass
> >> >> index d1b317b42b..9f9da2f91d 100644
> >> >> --- a/meta/classes/package_ipk.bbclass
> >> >> +++ b/meta/classes/package_ipk.bbclass
> >> >> @@ -14,7 +14,7 @@ OPKG_ARGS += "--force_postinstall
> >> >> --prefer-arch-to-version"
> >> >>  OPKG_ARGS += "${@['',
> >> >> '--no-install-recommends'][d.getVar("NO_RECOMMENDATIONS") == "1"]}"
> >> >>  OPKG_ARGS += "${@['', '--add-exclude ' + ' --add-exclude
> >> >> '.join((d.getVar('PACKAGE_EXCLUDE') or
> >> >> "").split())][(d.getVar("PACKAGE_EXCLUDE") or "").strip() != ""]}"
> >> >>
> >> >> -OPKGLIBDIR = "${localstatedir}/lib"
> >> >> +OPKGLIBDIR ??= "${localstatedir}/lib"
> >> >>
> >> >>  python do_package_ipk () {
> >> >>  workdir = d.getVar('WORKDIR')
> >> >> diff --git a/meta/classes/rootfs_ipk.bbclass
> >> >> b/meta/classes/rootfs_ipk.bbclass
> >> >> index aabc370cfc..e73d2bfdae 100644
> >> >> --- a/meta/classes/rootfs_ipk.bbclass
> >> >> +++ b/meta/classes/rootfs_ipk.bbclass
> >> >> @@ -21,7 +21,7 @@ OPKG_PREPROCESS_COMMANDS = ""
> >> >>
> >> >>  OPKG_POSTPROCESS_COMMANDS = ""
> >> >>
> >> >> -OPKGLIBDIR = "${localstatedir}/lib"
> >> >> +OPKGLIBDIR ??= "${localstatedir}/lib"
> >> >>
> >> >>  MULTILIBRE_ALLOW_REP = "${OPKGLIBDIR}/opkg|/usr/lib/opkg"
> >> >>
> >> >> diff 

Re: [OE-core] [PATCH] opkg/package/rootfs_ipk: allow overwriting OPKGLIBDIR

2019-07-17 Thread Martin Jansa
On Wed, Jul 17, 2019 at 02:52:21PM +0300, Adrian Ratiu wrote:
> Hi
> 
> On Wed, 17 Jul 2019, Martin Jansa  wrote:
> > Why don't you overwrite it with an override? We're doing that 
> > for years without any issues.
> 
> You mean a distro-wide override in a .conf?

yes

> Can you please point to an example?

https://github.com/webosose/meta-webosose/blob/master/meta-webos/conf/distro/include/webos.inc#L256

> > On Wed, Jul 17, 2019 at 12:01 AM Adrian Ratiu 
> > wrote:
> >
> >> Some distributions for various reasons (like for example mounting a
> >> tmpfs over /var at runtime) can't use /var/lib to store the opkg
> >> metadata, so a different path is required to have a functioning
> >> package manager.
> >>
> >> ${localstatedir} can't be modified to something other than the
> >> hardcoded value in bitbake.conf because other recipes depending on it
> >> will fail to install.
> >>
> >> So the only recourse, which is also the least invasive, is to allow
> >> distros to overwrite the OPKGLIBDIR variable just like they are also
> >> allowed to overwrite OPKGBUILDCMD.
> >>
> >> Signed-off-by: Adrian Ratiu 
> >> ---
> >>  meta/classes/package_ipk.bbclass | 2 +-
> >>  meta/classes/rootfs_ipk.bbclass  | 2 +-
> >>  meta/recipes-devtools/opkg/opkg_0.4.1.bb | 2 +-
> >>  3 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/meta/classes/package_ipk.bbclass
> >> b/meta/classes/package_ipk.bbclass
> >> index d1b317b42b..9f9da2f91d 100644
> >> --- a/meta/classes/package_ipk.bbclass
> >> +++ b/meta/classes/package_ipk.bbclass
> >> @@ -14,7 +14,7 @@ OPKG_ARGS += "--force_postinstall
> >> --prefer-arch-to-version"
> >>  OPKG_ARGS += "${@['',
> >> '--no-install-recommends'][d.getVar("NO_RECOMMENDATIONS") == "1"]}"
> >>  OPKG_ARGS += "${@['', '--add-exclude ' + ' --add-exclude
> >> '.join((d.getVar('PACKAGE_EXCLUDE') or
> >> "").split())][(d.getVar("PACKAGE_EXCLUDE") or "").strip() != ""]}"
> >>
> >> -OPKGLIBDIR = "${localstatedir}/lib"
> >> +OPKGLIBDIR ??= "${localstatedir}/lib"
> >>
> >>  python do_package_ipk () {
> >>  workdir = d.getVar('WORKDIR')
> >> diff --git a/meta/classes/rootfs_ipk.bbclass
> >> b/meta/classes/rootfs_ipk.bbclass
> >> index aabc370cfc..e73d2bfdae 100644
> >> --- a/meta/classes/rootfs_ipk.bbclass
> >> +++ b/meta/classes/rootfs_ipk.bbclass
> >> @@ -21,7 +21,7 @@ OPKG_PREPROCESS_COMMANDS = ""
> >>
> >>  OPKG_POSTPROCESS_COMMANDS = ""
> >>
> >> -OPKGLIBDIR = "${localstatedir}/lib"
> >> +OPKGLIBDIR ??= "${localstatedir}/lib"
> >>
> >>  MULTILIBRE_ALLOW_REP = "${OPKGLIBDIR}/opkg|/usr/lib/opkg"
> >>
> >> diff --git a/meta/recipes-devtools/opkg/opkg_0.4.1.bb
> >> b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
> >> index 8c48d3097c..c663eff13b 100644
> >> --- a/meta/recipes-devtools/opkg/opkg_0.4.1.bb
> >> +++ b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
> >> @@ -28,7 +28,7 @@ PACKAGES =+ "libopkg"
> >>  inherit autotools pkgconfig systemd ptest
> >>
> >>  target_localstatedir := "${localstatedir}"
> >> -OPKGLIBDIR = "${target_localstatedir}/lib"
> >> +OPKGLIBDIR ??= "${target_localstatedir}/lib"
> >>
> >>  PACKAGECONFIG ??= "libsolv"
> >>
> >> --
> >> 2.22.0
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] [PATCH] opkg/package/rootfs_ipk: allow overwriting OPKGLIBDIR

2019-07-17 Thread Martin Jansa
Why don't you overwrite it with an override? We're doing that for years
without any issues.

On Wed, Jul 17, 2019 at 12:01 AM Adrian Ratiu 
wrote:

> Some distributions for various reasons (like for example mounting a
> tmpfs over /var at runtime) can't use /var/lib to store the opkg
> metadata, so a different path is required to have a functioning
> package manager.
>
> ${localstatedir} can't be modified to something other than the
> hardcoded value in bitbake.conf because other recipes depending on it
> will fail to install.
>
> So the only recourse, which is also the least invasive, is to allow
> distros to overwrite the OPKGLIBDIR variable just like they are also
> allowed to overwrite OPKGBUILDCMD.
>
> Signed-off-by: Adrian Ratiu 
> ---
>  meta/classes/package_ipk.bbclass | 2 +-
>  meta/classes/rootfs_ipk.bbclass  | 2 +-
>  meta/recipes-devtools/opkg/opkg_0.4.1.bb | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/classes/package_ipk.bbclass
> b/meta/classes/package_ipk.bbclass
> index d1b317b42b..9f9da2f91d 100644
> --- a/meta/classes/package_ipk.bbclass
> +++ b/meta/classes/package_ipk.bbclass
> @@ -14,7 +14,7 @@ OPKG_ARGS += "--force_postinstall
> --prefer-arch-to-version"
>  OPKG_ARGS += "${@['',
> '--no-install-recommends'][d.getVar("NO_RECOMMENDATIONS") == "1"]}"
>  OPKG_ARGS += "${@['', '--add-exclude ' + ' --add-exclude
> '.join((d.getVar('PACKAGE_EXCLUDE') or
> "").split())][(d.getVar("PACKAGE_EXCLUDE") or "").strip() != ""]}"
>
> -OPKGLIBDIR = "${localstatedir}/lib"
> +OPKGLIBDIR ??= "${localstatedir}/lib"
>
>  python do_package_ipk () {
>  workdir = d.getVar('WORKDIR')
> diff --git a/meta/classes/rootfs_ipk.bbclass
> b/meta/classes/rootfs_ipk.bbclass
> index aabc370cfc..e73d2bfdae 100644
> --- a/meta/classes/rootfs_ipk.bbclass
> +++ b/meta/classes/rootfs_ipk.bbclass
> @@ -21,7 +21,7 @@ OPKG_PREPROCESS_COMMANDS = ""
>
>  OPKG_POSTPROCESS_COMMANDS = ""
>
> -OPKGLIBDIR = "${localstatedir}/lib"
> +OPKGLIBDIR ??= "${localstatedir}/lib"
>
>  MULTILIBRE_ALLOW_REP = "${OPKGLIBDIR}/opkg|/usr/lib/opkg"
>
> diff --git a/meta/recipes-devtools/opkg/opkg_0.4.1.bb
> b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
> index 8c48d3097c..c663eff13b 100644
> --- a/meta/recipes-devtools/opkg/opkg_0.4.1.bb
> +++ b/meta/recipes-devtools/opkg/opkg_0.4.1.bb
> @@ -28,7 +28,7 @@ PACKAGES =+ "libopkg"
>  inherit autotools pkgconfig systemd ptest
>
>  target_localstatedir := "${localstatedir}"
> -OPKGLIBDIR = "${target_localstatedir}/lib"
> +OPKGLIBDIR ??= "${target_localstatedir}/lib"
>
>  PACKAGECONFIG ??= "libsolv"
>
> --
> 2.22.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] [PATCH] Remove remnants of bluez4 support

2019-07-12 Thread Martin Jansa
On Fri, Jul 12, 2019 at 10:48:13AM +0300, Adrian Bunk wrote:
> bluez4 was removed from meta-oe 2 years ago.
> 
> Simplfy the setup of the two level bluetooth and bluez4/bluez5
> distro features by removing the bluez4/bluez5 distro features.
> 
> This also removes the no longer required bluetooth class.
> 
> Signed-off-by: Adrian Bunk 
> ---
> Documentation changes will be sent separately.
> Users in meta-openembedded have already been fixed.
> ---
>  meta/classes/bluetooth.bbclass | 14 --
>  meta/conf/bitbake.conf |  2 +-
>  meta/conf/distro/include/default-providers.inc |  2 +-
>  meta/recipes-connectivity/bluez5/bluez5_5.50.bb|  2 --
>  meta/recipes-connectivity/connman/connman.inc  |  4 ++--
>  meta/recipes-connectivity/libpcap/libpcap_1.9.0.bb |  4 ++--
>  meta/recipes-connectivity/neard/neard_0.16.bb  |  4 ++--
>  meta/recipes-connectivity/ofono/ofono.inc  |  4 ++--
>  .../packagegroups/packagegroup-base.bb |  4 +---
>  meta/recipes-devtools/qemu/qemu.inc|  4 ++--
>  meta/recipes-devtools/strace/strace_4.26.bb|  4 ++--
>  .../gstreamer/gstreamer1.0-plugins-bad_1.16.0.bb   |  4 ++--
>  meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  5 ++---
>  13 files changed, 19 insertions(+), 38 deletions(-)
>  delete mode 100644 meta/classes/bluetooth.bbclass
> 
> diff --git a/meta/classes/bluetooth.bbclass b/meta/classes/bluetooth.bbclass
> deleted file mode 100644
> index f88b4ae5b8..00
> --- a/meta/classes/bluetooth.bbclass
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -# Avoid code duplication in bluetooth-dependent recipes.
> -
> -# Define a variable that expands to the recipe (package) providing core
> -# bluetooth support on the platform:
> -# "" if bluetooth is not in DISTRO_FEATURES
> -# else "bluez5" if bluez5 is in DISTRO_FEATURES
> -# else "bluez4"
> -
> -# Use this with:
> -#  inherit bluetooth
> -#  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 
> '${BLUEZ}', '', d)}
> -#  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
> -
> -BLUEZ ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 
> bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5', 'bluez4', d), '', 
> d)}"
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 5e93f5c223..140f45b895 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -839,7 +839,7 @@ DISTRO_FEATURES_NATIVESDK ?= "x11"
>  DISTRO_FEATURES_FILTER_NATIVE ?= "api-documentation"
>  DISTRO_FEATURES_FILTER_NATIVESDK ?= "api-documentation"
>  
> -DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5 
> gobject-introspection-data ldconfig"
> +DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit gobject-introspection-data 
> ldconfig"
>  MACHINE_FEATURES_BACKFILL = "rtc qemu-usermode"
>  
>  COMBINED_FEATURES = "${@oe.utils.set_intersect('DISTRO_FEATURES', 
> 'MACHINE_FEATURES', d)}"
> diff --git a/meta/conf/distro/include/default-providers.inc 
> b/meta/conf/distro/include/default-providers.inc
> index 2be3378773..7d3be8f4e1 100644
> --- a/meta/conf/distro/include/default-providers.inc
> +++ b/meta/conf/distro/include/default-providers.inc
> @@ -44,7 +44,7 @@ PREFERRED_PROVIDER_nativesdk-opkg ?= "nativesdk-opkg"
>  PREFERRED_PROVIDER_console-tools ?= "kbd"
>  PREFERRED_PROVIDER_gzip-native ?= "pigz-native"
>  PREFERRED_PROVIDER_udev ?= 
> "${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd','eudev',d)}"
> -PREFERRED_RPROVIDER_bluez-hcidump ?= 
> "${@bb.utils.contains('DISTRO_FEATURES','bluetooth 
> bluez5','bluez5','bluez-hcidump',d)}"
> +PREFERRED_RPROVIDER_bluez-hcidump ?= 
> "${@bb.utils.contains('DISTRO_FEATURES','bluetooth','bluez5','bluez-hcidump',d)}"

Is this still needed?

With all remnants of bluez4 gone, bluez-hcidump is probably rprovided
only by bluez5 now.

>  # Alternative is ltp-ddt in meta-oe: 
> meta-oe/recipes-devtools/ltp-ddt/ltp-ddt_0.0.4.bb
>  PREFERRED_PROVIDER_ltp ?= "ltp"
>  PREFERRED_PROVIDER_getopt ?= "util-linux-getopt"
> diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.50.bb 
> b/meta/recipes-connectivity/bluez5/bluez5_5.50.bb
> index 66271432fe..4e443e5fb0 100644
> --- a/meta/recipes-connectivity/bluez5/bluez5_5.50.bb
> +++ b/meta/recipes-connectivity/bluez5/bluez5_5.50.bb
> @@ -1,7 +1,5 @@
>  require bluez5.inc
>  
> -REQUIRED_DISTRO_FEATURES = "bluez5"
> -
>  SRC_URI[md5sum] = "8e35c67c81a55d3ad4c9f22280dae178"
>  SRC_URI[sha256sum] = 
> "5ffcaae18bbb6155f1591be8c24898dc12f062075a40b538b745bfd477481911"
>  
> diff --git a/meta/recipes-connectivity/connman/connman.inc 
> b/meta/recipes-connectivity/connman/connman.inc
> index ae67079c71..ee00479926 100644
> --- a/meta/recipes-connectivity/connman/connman.inc
> +++ b/meta/recipes-connectivity/connman/connman.inc
> @@ -13,7 +13,7 @@ LICENSE  = "GPLv2"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
>  
> 

Re: [OE-core] [RFC][PATCH] icecc.bbclass: catch subprocess.CalledProcessError

2019-07-08 Thread Martin Jansa
Yes, I'm seeing it with thud, warrior and master.

On Mon, Jul 8, 2019 at 6:02 PM akuster808  wrote:

>
>
> On 7/8/19 3:05 AM, Martin Jansa wrote:
> > * this might be related to:
> >   commit d2fcaeb153fdc3f8d7143ea823139f1537055ff1
> >   Author: Douglas Royds 
> >   Date:   Thu Dec 20 11:59:47 2018 +1300
> >
> > icecc: Don't generate recipe-sysroot symlinks at recipe-parsing time
> >
> > * it's still a bit unclear when and why this happends, but I'm seeing
> >   random tasks sometimes failing with:
>
> this commit goes back to thud.  Have you seen this on a stable branch?
>
> - armin
> >
> > WARNING: Exception during build_dependencies for set_icecc_env
> > WARNING: Error during finalise of
> /build/meta-oe/meta-python/recipes-devtools/python/
> python-markupsafe_1.0.bb
> > ERROR: Traceback (most recent call last):
> >   File "/build/bitbake/lib/bb/data_smart.py", line 411, in expandWithRefs
> > s = __expand_python_regexp__.sub(varparse.python_sub, s)
> >   File "/build/bitbake/lib/bb/data_smart.py", line 136, in python_sub
> > value = utils.better_eval(codeobj, DataContext(self.d), {'d' :
> self.d})
> >   File "/build/bitbake/lib/bb/utils.py", line 421, in better_eval
> > return eval(source, ctx, locals)
> >   File "Var ", line 1, in 
> >   File "/build/oe-core/meta/classes/icecc.bbclass", line 287, in
> icecc_get_and_check_tool
> > link_path = icecc_get_tool_link(t, d)
> >   File "/build/oe-core/meta/classes/icecc.bbclass", line 246, in
> icecc_get_tool_link
> > return subprocess.check_output("readlink -f %s" % tool,
> shell=True).decode("utf-8")[:-1]
> >   File "/usr/lib/python3.6/subprocess.py", line 336, in check_output
> > **kwargs).stdout
> >   File "/usr/lib/python3.6/subprocess.py", line 418, in run
> > output=stdout, stderr=stderr)
> > subprocess.CalledProcessError: Command 'readlink -f
> /build/BUILD/work/qemux86-oe-linux/python-markupsafe/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux/x86_64-oe-linux-g++'
> returned non-zero exit status 1.
> >
> > The above exception was the direct cause of the following exception:
> >
> > Traceback (most recent call last):
> >   File "/build/bitbake/bin/bitbake-worker", line 239, in child
> > the_data = bb_cache.loadDataFull(fn, appends)
> >   File "/build/bitbake/lib/bb/cache.py", line 327, in loadDataFull
> > bb_data = self.load_bbfile(virtualfn, appends, virtonly=True)
> >   File "/build/bitbake/lib/bb/cache.py", line 340, in load_bbfile
> > datastores = parse_recipe(bb_data, bbfile, appends, mc)
> >   File "/build/bitbake/lib/bb/cache.py", line 303, in parse_recipe
> > bb_data = bb.parse.handle(bbfile, bb_data)
> >   File "/build/bitbake/lib/bb/parse/__init__.py", line 107, in handle
> > return h['handle'](fn, data, include)
> >   File "/build/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 142, in
> handle
> > return ast.multi_finalize(fn, d)
> >   File "/build/bitbake/lib/bb/parse/ast.py", line 386, in multi_finalize
> > finalize(fn, d)
> >   File "/build/bitbake/lib/bb/parse/ast.py", line 351, in finalize
> > bb.parse.siggen.finalise(fn, d, variant)
> >   File "/build/bitbake/lib/bb/siggen.py", line 147, in finalise
> > taskdeps = self._build_data(fn, d)
> >   File "/build/bitbake/lib/bb/siggen.py", line 118, in _build_data
> > tasklist, gendeps, lookupcache = bb.data.generate_dependencies(d)
> >   File "/build/bitbake/lib/bb/data.py", line 388, in
> generate_dependencies
> > deps[dep], values[dep] = build_dependencies(dep, keys, shelldeps,
> varflagsexcl, d)
> >   File "/build/bitbake/lib/bb/data.py", line 317, in build_dependencies
> > value, parsedvar = d.getVarFlag(key, "_content", False,
> retparser=True)
> >   File "/build/bitbake/lib/bb/data_smart.py", line 802, in getVarFlag
> > parser = self.expandWithRefs(value, cachename)
> >   File "/build/bitbake/lib/bb/data_smart.py", line 424, in expandWithRefs
> > raise ExpansionError(varname, s, exc).with_traceback(tb) from exc
> >   File "/build/bitbake/lib/bb/data_smart.py", line 411, in expandWithRefs
> > s = __expand_python_regexp__.sub(varparse.python_sub, s)
> >   File "/build/bitbake/lib/bb/data_smart.py", line 136, in python_sub
> > value = utils.better_eval(cod

[OE-core] [RFC][PATCH] icecc.bbclass: catch subprocess.CalledProcessError

2019-07-08 Thread Martin Jansa
"
if [ "x${ICECC_VERSION}" = "x" ]
then
bbwarn "Cannot use icecc: could not get ICECC_VERSION"
return
fi

ICE_PATH="${@icecc_path(bb, d)}"
if [ "x${ICE_PATH}" = "x" ]
then
bbwarn "Cannot use icecc: could not get ICE_PATH"
return
fi

ICECC_BIN="${@get_icecc(d)}"
if [ -z "${ICECC_BIN}" ]; then
bbwarn "Cannot use icecc: icecc binary not found"
return
fi
if [ -z "$(which patchelf patchelf-uninative)" ]; then
bbwarn "Cannot use icecc: patchelf not found"
return
fi

# Create symlinks to icecc in the recipe-sysroot directory
mkdir -p ${ICE_PATH}
if [ -n "${KERNEL_CC}" ]; then
compilers="${@get_cross_kernel_cc(bb,d)}"
else
compilers="x86_64-oe-linux-gcc x86_64-oe-linux-g++"
fi
for compiler in $compilers; do
ln -sf ${ICECC_BIN} ${ICE_PATH}/$compiler
done

ICECC_CC="${@icecc_get_and_check_tool(bb, d, "gcc")}"
ICECC_CXX="${@icecc_get_and_check_tool(bb, d, "g++")}"
# cannot use icecc_get_and_check_tool here because it assumes as without 
target_sys prefix
ICECC_WHICH_AS="${@bb.utils.which(os.getenv('PATH'), 'as')}"
if [ ! -x "${ICECC_CC}" -o ! -x "${ICECC_CXX}" ]
then
bbwarn "Cannot use icecc: could not get ICECC_CC or ICECC_CXX"
return
fi

ICE_VERSION=`$ICECC_CC -dumpversion`
ICECC_VERSION=`echo ${ICECC_VERSION} | sed -e "s/@VERSION@/$ICE_VERSION/g"`
if [ ! -x 
"/build/BUILD/work/qemux86-oe-linux/python-markupsafe/1.0-r0/recipe-sysroot-native/usr/bin/icecc-create-env"
 ]
then
bbwarn "Cannot use icecc: invalid ICECC_ENV_EXEC"
return
fi

ICECC_AS="`${ICECC_CC} -print-prog-name=as`"
# for target recipes should return something like:
# 
/OE/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/arm920tt-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.8.2/as
# and just "as" for native, if it returns "as" in current directory (for 
whatever reason) use "as" from PATH
if [ "`dirname "${ICECC_AS}"`" = "." ]
then
ICECC_AS="${ICECC_WHICH_AS}"
fi

if [ ! -f "${ICECC_VERSION}.done" ]
then
mkdir -p "`dirname "${ICECC_VERSION}"`"

# the ICECC_VERSION generation step must be locked by a mutex
# in order to prevent race conditions
if flock -n "${ICECC_VERSION}.lock" \

/build/BUILD/work/qemux86-oe-linux/python-markupsafe/1.0-r0/recipe-sysroot-native/usr/bin/icecc-create-env
  "${ICECC_CC}" "${ICECC_CXX}" "${ICECC_AS}" "${ICECC_VERSION}"
then
touch "${ICECC_VERSION}.done"
elif ! wait_for_file "${ICECC_VERSION}.done" 30
then
# locking failed so wait for ${ICECC_VERSION}.done to appear
bbwarn "Timeout waiting for ${ICECC_VERSION}.done"
return
fi
fi

# Don't let ccache find the icecream compiler links that have been created, 
otherwise
# it can end up invoking icecream recursively.
export CCACHE_PATH="$PATH"
export CCACHE_DISABLE="1"

export ICECC_VERSION ICECC_CC ICECC_CXX
export PATH="$ICE_PATH:$PATH"

bbnote "Using icecc path: $ICE_PATH"
bbnote "Using icecc tarball: $ICECC_VERSION"
 which triggered exception CalledProcessError: Command 'readlink -f 
/build/BUILD/work/qemux86-oe-linux/python-markupsafe/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux/x86_64-oe-linux-g++'
 returned non-zero exit status 1.

ERROR: Task 
(virtual:multilib:lib32:/build/meta-oe/meta-python/recipes-devtools/python/python-markupsafe_1.0.bb:do_patch)
 failed with exit code '1'

Signed-off-by: Martin Jansa 
---
 meta/classes/icecc.bbclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index edb0e10434..63d8b4dfee 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -243,7 +243,11 @@ def icecc_get_external_tool(bb, d, tool):
 
 def icecc_get_tool_link(tool, d):
 import subprocess
-return subprocess.check_output("readlink -f %s" % tool, 
shell=True).decode("utf-8")[:-1]
+try:
+return subprocess.check_output("readlink -f %s" % tool, 
shell=True).decode("utf-8")[:-1]
+except subprocess.CalledProcessError as e:
+bb.note("icecc: one of the tools probably disappeared during recipe 
parsing, cmd readlink -f %s returned %d:\n%s" % (tool, e.returncode, 
e.output.decode("utf-8")))
+return tool
 
 def icecc_get_path_tool(tool, d):
 # This is a little ugly, but we want to make sure we add an actual
-- 
2.17.1

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


Re: [OE-core] [PATCH 3/3] glibc/glibc-locale: Fix do_stash_locale to work with usrmerge and multilibs

2019-07-04 Thread Martin Jansa
I don't see how this change (or the previous glibc-locale one) would cause
that, but since the oe-core upgrade yesterday I'm seeing following
glibc-locale.do_package failure:
http://errors.yoctoproject.org/Errors/Details/250557/

DEBUG: Executing shell function do_prep_locale_tree
tar: i18n: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
gzip:
TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc-locale/2.29-r0/locale-tree//usr/share/i18n/charmaps/*gz.gz:
No such file or directory
WARNING:
TOPDIR/tmp-glibc/work/core2-64-oe-linux/glibc-locale/2.29-r0/temp/run.do_prep_locale_tree.23303:1
exit 1 from 'gunzip $i'

anyone else seeing this?

On Tue, Jul 2, 2019 at 10:16 PM Jason Wessel 
wrote:

> The do_stash_locale was not working consistently across the 4 build
> configurations and the multilib, usrmerge configuration would fail
> entirely with the obscure message:
>
> | DEBUG: Executing shell function do_prep_locale_tree
> | tar: i18n: Cannot stat: No such file or directory
> | tar: Exiting with failure status due to previous errors
> | gzip:
> /poky/build/tmp/work/core2-64-poky-linux/glibc-locale/2.29-r0/locale-tree//usr/share/i18n/charmaps/*gz.gz:
> No such file or directory
> | WARNING:
> /poky/build/tmp/work/core2-64-poky-linux/glibc-locale/2.29-r0/temp/run.do_prep_locale_tree.124690:1
> exit 1 from 'gunzip $i'
>
> Here is the 4 build configurations without the patch applied:
>
> A) x86-64 no multilibs, no usrmerge
> find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v
> nscd.service |wc -l
> 909
> B) x86-64 no multilibs, usrmerge
> find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v
> nscd.service |wc -l
> 909
> C) x86-64 multilibs, no usrmerge
> find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v
> nscd.service |wc -l
> 885
> D) x86-64 multilibs, usrmerge
> find ./tmp/work/*/glibc/2.29-r0/stashed-locale -type f |grep -v
> nscd.service |wc -l
> 864
>
> The issue here is that all the moves should be processed first, then a
> copy should be made of the lib directories, but only in the case they
> are different when using the usrmerge feature.  Even though the build
> worked for the multilib configuration without usrmerge, the content
> was not the same.
>
> After applying the patch the same number of files are in all the
> configurations.  The list of files was also diffed, after normalizing
> the directory names to ensure all the correct files were copied.
>
> Ultimately there are probably additional files that should be pruned
> from what is copied to the stated_locale, but the purpose of this
> patch is make it 100% consistent between the build types and fix the
> builds.
>
> Signed-off-by: Jason Wessel 
> ---
>  meta/recipes-core/glibc/glibc-package.inc | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/meta/recipes-core/glibc/glibc-package.inc
> b/meta/recipes-core/glibc/glibc-package.inc
> index a1d79b3075..ff17a193c3 100644
> --- a/meta/recipes-core/glibc/glibc-package.inc
> +++ b/meta/recipes-core/glibc/glibc-package.inc
> @@ -162,21 +162,28 @@ bashscripts = "mtrace sotruss xtrace"
>  do_stash_locale () {
> dest=${LOCALESTASH}
> install -d ${dest}${base_libdir} ${dest}${bindir} ${dest}${libdir}
> ${dest}${datadir}
> -   if [ "${base_libdir}" != "${libdir}" ]; then
> -   cp -fpPR ${D}${base_libdir}/* ${dest}${base_libdir}
> -   fi
> +   # Hide away the locale data from the deployment
> if [ -e ${D}${bindir}/localedef ]; then
> mv -f ${D}${bindir}/localedef ${dest}${bindir}
> fi
> if [ -e ${D}${libdir}/gconv ]; then
> mv -f ${D}${libdir}/gconv ${dest}${libdir}
> fi
> -   if [ -e ${D}${exec_prefix}/lib ]; then
> -   cp -fpPR ${D}${exec_prefix}/lib ${dest}${exec_prefix}
> -   fi
> if [ -e ${D}${datadir}/i18n ]; then
> mv ${D}${datadir}/i18n ${dest}${datadir}
> fi
> +
> +   # Make a copy of all the libraries into the locale stash
> +   cp -fpPR ${D}${libdir}/* ${dest}${libdir}
> +   if [ "${base_libdir}" != "${libdir}" ]; then
> +   cp -fpPR ${D}${base_libdir}/* ${dest}${base_libdir}
> +   fi
> +   if [ -e ${D}${exec_prefix}/lib ]; then
> +   if [ ${exec_prefix}/lib != ${base_libdir} ] && [
> ${exec_prefix}/lib != ${libdir} ]; then
> +   cp -fpPR ${D}${exec_prefix}/lib
> ${dest}${exec_prefix}
> +   fi
> +   fi
> +
> cp -fpPR ${D}${datadir}/* ${dest}${datadir}
> rm -rf ${D}${datadir}/locale/
> cp -fpPR ${WORKDIR}/SUPPORTED ${dest}
> --
> 2.21.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list

Re: [OE-core] The state of reproducible Builds

2019-07-02 Thread Martin Jansa
On Mon, Jul 01, 2019 at 10:58:04AM -0500, Joshua Watt wrote:
> I'm curious what people thing about all this; How important is 
> reproducibility? How reproducible do we want to be? How hard should it 
> be to have reproducible builds? What trade-offs are willing to be made 
> for reproducible builds? Are there smart ways we can mitigate some of 
> the potential performance impacts of reproducible builds?

For me 100% reproducibility isn't hard requirement, but every
reproducible bit makes it more useful.

Once we upgrade to newer Yocto which includes more of these fixes my
plan is to achieve these milestones.

1) no changes in buildhistory reports (especially files-in-image.txt)
between 2 clean builds on the same host
2) same as above, but on different hosts, but with the same OS (now we use
Ubuntu 18.04 on all LGE builds)
3) same of above but with different OS on host (not important to us, but
interesting to see which host differences cause differences in the
target image).

A) no changes in installed files (not only in their ls -l shown in the
buildhistory reports), again on the same host and after it works on the
same host, than maybe different hosts with the same OS and maybe then
also different OS

B) no changes in the .ipk files (after the packaged bits are identical)

C) with the hash equivalence server we might get rid of .ipk files
having different EXTENDPRAUTO from PRserv when they are rebuilt just
because some dependency changed the signature.

And all these milestones also have another scope axis (it's great to
have everything reproducible in core-image-minimal, but there might be
still a lot of differences in bigger images and our images are really
big) - but again every reproducible bit helps, once the low hanging
fruits are fixed, it will be easier to see what next is causing a lot of
differences or even filter-out the known to be not-reproducible bits
when comparing 2 images.

We don't hide any source code in salt mines, so reproducing some very
old binary (on possibly very different host OS) is less important for
us. Similarly detecting the maliciously modified binaries is less
important for us because we control the whole pipeline from source to
the bits installed on the TVs.

Being able to see that the diff between 2 official builds doesn't contain
any unexpected changes is probably the most important aspect for us.

Also in the opposite direction when QA reports new issue in the latest
build and we need to compare with previous one to find the cause of it
and now there is too many random changes just because the recipes were
rebuilt makes it difficult to spot the significant difference which
caused the new issue.

> Thanks for your time. I know this was a long e-mail.

Thanks for working on this, I believe this issue is really important and
I really like your changes. Once we get closer to master I hope I'll be
able to contribute some fixes back.

Cheers,
-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] [PATCH 1/2] buildhistory: write the contents of the sysroot

2019-06-27 Thread Martin Jansa
> Changes to the sysroot as just as

small typo in commit message if you need to update this commit again for
whatever other reason.

On Thu, Jun 27, 2019 at 2:29 PM Ross Burton  wrote:

> Changes to the sysroot as just as interesting during development, so write
> the
> file listing for the sysroot to buildhistory too.
>
> Signed-off-by: Ross Burton 
> ---
>  meta/classes/buildhistory.bbclass | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/buildhistory.bbclass
> b/meta/classes/buildhistory.bbclass
> index 2e501df24b4..baa7c8e2799 100644
> --- a/meta/classes/buildhistory.bbclass
> +++ b/meta/classes/buildhistory.bbclass
> @@ -60,15 +60,23 @@ SSTATEPOSTUNPACKFUNCS[vardepvalueexclude] .= "|
> buildhistory_emit_outputsigs"
>  # When extending build history, derive your class from
> buildhistory.bbclass
>  # and extend this list here with the additional files created by the
> derived
>  # class.
> -BUILDHISTORY_PRESERVE = "latest latest_srcrev"
> +BUILDHISTORY_PRESERVE = "latest latest_srcrev sysroot"
>
>  PATCH_GIT_USER_EMAIL ?= "buildhistory@oe"
>  PATCH_GIT_USER_NAME ?= "OpenEmbedded"
>
> +buildhistory_emit_sysroot() {
> +   mkdir --parents ${BUILDHISTORY_DIR_PACKAGE}
> +   buildhistory_list_files ${SYSROOT_DESTDIR}
> ${BUILDHISTORY_DIR_PACKAGE}/sysroot
> +}
> +
>  #
>  # Write out metadata about this package for comparison when writing
> future packages
>  #
>  python buildhistory_emit_pkghistory() {
> +if d.getVar('BB_CURRENTTASK') in ['populate_sysroot',
> 'populate_sysroot_setscene']:
> +bb.build.exec_func("buildhistory_emit_sysroot", d)
> +
>  if not d.getVar('BB_CURRENTTASK') in ['packagedata',
> 'packagedata_setscene']:
>  return 0
>
> --
> 2.11.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] [PATCH 2/2] linux-yocto/5.0: make scsci-debug include scsci core configs

2019-06-24 Thread Martin Jansa
On Mon, Jun 24, 2019 at 08:44:42AM -0400, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield 
> 
> Updating the scsci-debug fragment to include the core scsci config
> options. This allows standalone use of the fragment, since all
> supporting options will be enabled simply by including the top
> level config in a BSP.
> 
> This also removes a configuration warning on qemuarm, since we
> will no longer have missing / unavailable options during the
> config audit.

4 typos in commit summary and commit message scsci should probably be
scsi, I didn't check the commit in the meta repository, maybe more
scsci's there :).

> Signed-off-by: Bruce Ashfield 
> ---
>  meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb   | 2 +-
>  meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb | 2 +-
>  meta/recipes-kernel/linux/linux-yocto_5.0.bb  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb 
> b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
> index c5bd342d5b..35f2350d52 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
> @@ -12,7 +12,7 @@ python () {
>  }
>  
>  SRCREV_machine ?= "9c1e84c9b81b6bf1df55f26f2e0517266c37f7eb"
> -SRCREV_meta ?= "97eac3146504a2348543b8b8859f44a7b8f0d590"
> +SRCREV_meta ?= "eb6ef084f987441359145c41cadcbdd768eeb012"
>  
>  SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
> 
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.0;destsuffix=${KMETA}"
> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb 
> b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
> index d6e45c69c0..96cfb3dcd1 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
> @@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
>  
>  SRCREV_machine_qemuarm ?= "fabee455f397ba8054f35a3ad5f2250bbad93bef"
>  SRCREV_machine ?= "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
> -SRCREV_meta ?= "97eac3146504a2348543b8b8859f44a7b8f0d590"
> +SRCREV_meta ?= "eb6ef084f987441359145c41cadcbdd768eeb012"
>  
>  PV = "${LINUX_VERSION}+git${SRCPV}"
>  
> diff --git a/meta/recipes-kernel/linux/linux-yocto_5.0.bb 
> b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
> index 5bc2d54916..d4d30853f0 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_5.0.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
> @@ -21,7 +21,7 @@ SRCREV_machine_qemux86 ?= 
> "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
>  SRCREV_machine_qemux86-64 ?= "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
>  SRCREV_machine_qemumips64 ?= "5a8b27bcc0b16077ab8edfcd3fb25c80dc2c652e"
>  SRCREV_machine ?= "00638cdd8f92869a0f89ebe3289fdbd856ba9458"
> -SRCREV_meta ?= "97eac3146504a2348543b8b8859f44a7b8f0d590"
> +SRCREV_meta ?= "eb6ef084f987441359145c41cadcbdd768eeb012"
>  
>  # remap qemuarm to qemuarma15 for the 5.0 kernel
>  # KMACHINE_qemuarm ?= "qemuarma15"
> -- 
> 2.19.1
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] [Warrior][ 02/19] linux-yocto: Add scsi_debug module when ptest is in DISTRO_FEATURES

2019-06-24 Thread Martin Jansa
Hi,

I think this will backport also this warning:
http://lists.openembedded.org/pipermail/openembedded-core/2019-June/283912.html

can it be backported together with the fix for it from Bruce:
http://lists.openembedded.org/pipermail/openembedded-core/2019-June/283913.html
I haven't noticed the fix itself on ML yet.


On Mon, Jun 24, 2019 at 5:55 AM Armin Kuster  wrote:

> From: Mariano López 
>
> util-linux ptest requires the scsi_debug module to perform eject/mount
> tests. This will conditionally add scsi_debug module when ptest is in
> DISTRO_FEATURES.
>
> This doesn't include linux-yocto-tiny because the resulting image will
> be too big and do_image would complain about this.
>
> [YOCTO #13301]
>
> Signed-off-by: Mariano López 
> Signed-off-by: Richard Purdie 
> Signed-off-by: Armin Kuster 
> ---
>  meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb | 1 +
>  meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb  | 1 +
>  meta/recipes-kernel/linux/linux-yocto_4.19.bb| 1 +
>  meta/recipes-kernel/linux/linux-yocto_5.0.bb | 1 +
>  4 files changed, 4 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> index 6604bdf..0836dc7 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> @@ -41,3 +41,4 @@ KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
>  KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
>  KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
>  KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
> +KERNEL_FEATURES_append = "${@bb.utils.contains("DISTRO_FEATURES",
> "ptest", " features/scsi/scsi-debug.scc", "" ,d)}"
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
> b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
> index 1fe28b1..b5e415f 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
> @@ -41,3 +41,4 @@ KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
>  KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
>  KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
>  KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
> +KERNEL_FEATURES_append = "${@bb.utils.contains("DISTRO_FEATURES",
> "ptest", " features/scsi/scsi-debug.scc", "" ,d)}"
> diff --git a/meta/recipes-kernel/linux/linux-yocto_4.19.bb
> b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
> index a5fdafe..cda4ecf 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_4.19.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
> @@ -47,3 +47,4 @@ KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
>  KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
>  KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
>  KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32",
> " cfg/x32.scc", "" ,d)}"
> +KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES",
> "ptest", " features/scsi/scsi-debug.scc", "" ,d)}"
> diff --git a/meta/recipes-kernel/linux/linux-yocto_5.0.bb
> b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
> index da795d9..8aec315 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_5.0.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
> @@ -50,3 +50,4 @@ KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
>  KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
>  KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
>  KERNEL_FEATURES_append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32",
> " cfg/x32.scc", "" ,d)}"
> +KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES",
> "ptest", " features/scsi/scsi-debug.scc", "" ,d)}"
> --
> 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 V3] gcc-runtime: fix C++ header mapping for n32/x32 tune

2019-06-21 Thread Martin Jansa
Hi,

see the fix here:
http://lists.openembedded.org/pipermail/openembedded-core/2019-June/283928.html

I think it doesn't need additional explanation.

Any aarch64/arm multilib configuration should trigger this (or anything
where TARGET_OS isn't just "linux").

Regards,

On Fri, Jun 21, 2019 at 11:08 AM Changqing Li 
wrote:

>
> On 6/21/19 4:32 PM, Martin Jansa wrote:
> > On Tue, Jun 18, 2019 at 03:46:56PM +0800, changqing...@windriver.com
> wrote:
> >> From: Changqing Li 
> >>
> >> The SDK was unable to find the C++ header pieces correctly since it's
> >> using a generic compiler, not one specifically targeting the multilib
> >> vendor prefix and default tune.  This adds the right mapping to ensure
> >> SDKs work as expected. And fix problem in below configurations:
> >>
> >> multilib configuration 1:
> >> MACHINE="qemumips64"
> >> MULTILIBS ?= "multilib:lib32 multilib:libn32"
> >> DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips"
> >> DEFAULTTUNE_virtclass-multilib-libn32 ?= "mips64-n32"
> >> MULTILIB_GLOBAL_VARIANTS_append = " libn32"
> >> require conf/multilib.conf
> >>
> >> ignoring nonexistent directory
> "/sysroots/mips64-poky-linux/usr/include/c++/8.2.0/mips64-poky-linux/32
> >>
> >> multilib configuration 2:
> >> MACHINE="qemumips64"
> >> MULTILIBS = 'multilib:lib64 multilib:lib32'
> >> DEFAULTTUNE = 'mips64-n32'
> >> DEFAULTTUNE_virtclass-multilib-lib64 = 'mips64'
> >> DEFAULTTUNE_virtclass-multilib-lib32 = 'mips32r2'
> >> require conf/multilib.conf
> >>
> >> For this configuration:
> >> for target gcc-runtime, need to create symlink like mips64-poly-linux
> --> mips64-poky-linux-gnu32
> >> for target lib64-gcc-runtime, need to create symlink like
> mips64-poly-linux/32 --> mips64-pokymllib64-linux
> >> in order to avoid conflict during populate_sdk, create symlink for
> subfoler bits/ext for target gcc-runtime,
> >> this is ugly, but seems no better way to cover all kinds of
> configuration.
> >>
> >> single lib configuration:
> >> MACHINE="qemumips64"
> >> DEFAULTTUNE = "mips64-n32"
> > This seems to be causing:
> >
> > ln: failed to create symbolic link
> 'work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux-gnueabi/bits':
> No such file or directory
> > WARNING: exit code 1 from a shell command.
> > ERROR: Function failed: do_install (log file is located at
> work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/temp/log.do_install.31049)
> >
> > There is only empty directory without the -gnueabi suffix:
> >
> work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux/
> >
> > and
> >
> >
> work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oemllib32-linux-gnueabi/
> > bits  ext
>
> Could you send your configuration like this? Thanks.
>
> MACHINE="qemumips64"
> MULTILIBS = 'multilib:lib64 multilib:lib32'
> DEFAULTTUNE = 'mips64-n32'
> DEFAULTTUNE_virtclass-multilib-lib64 = 'mips64'
> DEFAULTTUNE_virtclass-multilib-lib32 = 'mips32r2'
> require conf/multilib.conf
>
> >> Signed-off-by: Changqing Li 
> >> ---
> >>   meta/recipes-devtools/gcc/gcc-runtime.inc | 29
> +
> >>   1 file changed, 17 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> >> index 3d03d8e..ba767e1 100644
> >> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> >> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> >> @@ -86,10 +86,6 @@ do_install () {
> >>  if [ -d ${D}${infodir} ]; then
> >>  rmdir --ignore-fail-on-non-empty -p ${D}${infodir}
> >>  fi
> >> -if [ "${TARGET_VENDOR_MULTILIB_ORIGINAL}" != "" -a
> "${TARGET_VENDOR}" != "${TARGET_VENDOR_MULTILIB_ORIGINAL}" ]; then
> >> -ln -s ${TARGET_SYS}
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR_MULTILIB_ORIGINAL}-${TARGET_OS}
> >> -fi
> >> -
> >>   }
> >>
> >>   do_install_append_class-target () {
> >> @@ -98,20 +94,29 @@ do_install_append_class-target () {
> >>  fi
> >>
> >>  if [ "${TARGET_OS}" =

[OE-core] [PATCH] gcc-runtime.inc: create the correct directory before creating the symlinks in it

2019-06-21 Thread Martin Jansa
* since
  commit b071a1a209556158bcfcc20e3c8bd4b15373767c
  Author: Changqing Li 
  Date:   Tue Jun 18 15:46:56 2019 +0800

gcc-runtime: fix C++ header mapping for n32/x32 tune

  gcc-runtime.do_install is failing with:

  ln: failed to create symbolic link 
'work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux-gnueabi/bits':
 No such file or directory
  WARNING: exit code 1 from a shell command.
  ERROR: Function failed: do_install (log file is located at 
work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/temp/log.do_install.31049)

  There is only empty directory without the -gnueabi suffix:
  
work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux/

  and

  
work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oemllib32-linux-gnueabi/
  bits  ext

* make sure to create correct directory (with -${TARGET_OS suffix instead of 
-linux suffix)
  before creating the symlinks in it

Signed-off-by: Martin Jansa 
---
 meta/recipes-devtools/gcc/gcc-runtime.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
b/meta/recipes-devtools/gcc/gcc-runtime.inc
index ba767e1a38..a5c2600d7f 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -114,7 +114,7 @@ do_install_append_class-target () {
ln -s ${TARGET_SYS} 
${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR}-linux
fi
elif [ "${TARGET_VENDOR_MULTILIB_ORIGINAL}" != "" -a "${TARGET_VENDOR}" 
!= "${TARGET_VENDOR_MULTILIB_ORIGINAL}" ]; then
-   mkdir 
${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR_MULTILIB_ORIGINAL}-linux
+   mkdir 
${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR_MULTILIB_ORIGINAL}-${TARGET_OS}
ln -s ../${TARGET_SYS}/bits 
${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR_MULTILIB_ORIGINAL}-${TARGET_OS}/bits
ln -s ../${TARGET_SYS}/ext 
${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR_MULTILIB_ORIGINAL}-${TARGET_OS}/ext
fi
-- 
2.17.1

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


Re: [OE-core] [PATCH V3] gcc-runtime: fix C++ header mapping for n32/x32 tune

2019-06-21 Thread Martin Jansa
On Tue, Jun 18, 2019 at 03:46:56PM +0800, changqing...@windriver.com wrote:
> From: Changqing Li 
> 
> The SDK was unable to find the C++ header pieces correctly since it's
> using a generic compiler, not one specifically targeting the multilib
> vendor prefix and default tune.  This adds the right mapping to ensure
> SDKs work as expected. And fix problem in below configurations:
> 
> multilib configuration 1:
> MACHINE="qemumips64"
> MULTILIBS ?= "multilib:lib32 multilib:libn32"
> DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips"
> DEFAULTTUNE_virtclass-multilib-libn32 ?= "mips64-n32"
> MULTILIB_GLOBAL_VARIANTS_append = " libn32"
> require conf/multilib.conf
> 
> ignoring nonexistent directory 
> "/sysroots/mips64-poky-linux/usr/include/c++/8.2.0/mips64-poky-linux/32
> 
> multilib configuration 2:
> MACHINE="qemumips64"
> MULTILIBS = 'multilib:lib64 multilib:lib32'
> DEFAULTTUNE = 'mips64-n32'
> DEFAULTTUNE_virtclass-multilib-lib64 = 'mips64'
> DEFAULTTUNE_virtclass-multilib-lib32 = 'mips32r2'
> require conf/multilib.conf
> 
> For this configuration:
> for target gcc-runtime, need to create symlink like mips64-poly-linux --> 
> mips64-poky-linux-gnu32
> for target lib64-gcc-runtime, need to create symlink like 
> mips64-poly-linux/32 --> mips64-pokymllib64-linux
> in order to avoid conflict during populate_sdk, create symlink for subfoler 
> bits/ext for target gcc-runtime,
> this is ugly, but seems no better way to cover all kinds of configuration.
> 
> single lib configuration:
> MACHINE="qemumips64"
> DEFAULTTUNE = "mips64-n32"

This seems to be causing:

ln: failed to create symbolic link 
'work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux-gnueabi/bits':
 No such file or directory
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_install (log file is located at 
work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/temp/log.do_install.31049)

There is only empty directory without the -gnueabi suffix:
work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux/

and

work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oemllib32-linux-gnueabi/
bits  ext

> Signed-off-by: Changqing Li 
> ---
>  meta/recipes-devtools/gcc/gcc-runtime.inc | 29 +
>  1 file changed, 17 insertions(+), 12 deletions(-)
> 
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index 3d03d8e..ba767e1 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -86,10 +86,6 @@ do_install () {
>   if [ -d ${D}${infodir} ]; then
>   rmdir --ignore-fail-on-non-empty -p ${D}${infodir}
>   fi
> - if [ "${TARGET_VENDOR_MULTILIB_ORIGINAL}" != "" -a "${TARGET_VENDOR}" 
> != "${TARGET_VENDOR_MULTILIB_ORIGINAL}" ]; then
> - ln -s ${TARGET_SYS} 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR_MULTILIB_ORIGINAL}-${TARGET_OS}
> - fi
> -
>  }
>  
>  do_install_append_class-target () {
> @@ -98,20 +94,29 @@ do_install_append_class-target () {
>   fi
>  
>   if [ "${TARGET_OS}" = "linux-gnun32" ]; then
> - if [ "${MULTILIBS}" != "" ]; then
> - mkdir 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}-pokymllib64-linux
> - ln -s ../${TARGET_SYS} 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}-pokymllib64-linux/32
> + if [ "${TARGET_VENDOR_MULTILIB_ORIGINAL}" != "" -a 
> "${TARGET_VENDOR}" != "${TARGET_VENDOR_MULTILIB_ORIGINAL}" ]; then
> + mkdir 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR_MULTILIB_ORIGINAL}-linux
> + ln -s ../${TARGET_SYS} 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR_MULTILIB_ORIGINAL}-linux/32
> + elif [ "${MULTILIB_VARIANTS}" != "" ]; then
> + mkdir 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR}-linux
> + ln -s ../${TARGET_SYS} 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR}-linux/32
>   else
>   ln -s ${TARGET_SYS} 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR}-linux
>   fi
> - fi
> - if [ "${TARGET_OS}" = "linux-gnux32" ]; then
> - if [ "${MULTILIBS}" != "" ]; then
> - mkdir 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}-poky-linux
> - ln -s ../${TARGET_SYS} 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}-poky-linux/x32
> + elif [ "${TARGET_OS}" = "linux-gnux32" ]; then
> + if [ "${TARGET_VENDOR_MULTILIB_ORIGINAL}" != "" -a 
> "${TARGET_VENDOR}" != "${TARGET_VENDOR_MULTILIB_ORIGINAL}" ]; then
> + mkdir 
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR_MULTILIB_ORIGINAL}-linux
> +  

Re: [OE-core] [oe-commits] [openembedded-core] 09/30: linux-yocto/5.0: update to v5.0.19

2019-06-20 Thread Martin Jansa
Hi,


One of these recent updates is causing following WARNING:


-- CONFIG_SCSI_DEBUG -
Config: CONFIG_SCSI_DEBUG
From: 
work-shared/qemuarm/kernel-source/.kernel-meta/configs/v5.0/standard/features/scsi/scsi-debug.cfg
Requested value:  CONFIG_SCSI_DEBUG=m
Actual value:

No reference to SCSI_DEBUG found


On Tue, Jun 18, 2019 at 12:31 PM  wrote:

> This is an automated email from the git hooks/post-receive script.
>
> rpurdie pushed a commit to branch warrior
> in repository openembedded-core.
>
> commit 02ee58ba18a0393ce372f4fe9d4860cc9486
> Author: Bruce Ashfield 
> AuthorDate: Thu May 30 08:44:42 2019 -0400
>
> linux-yocto/5.0: update to v5.0.19
>
> Integrating the korg -stable updates that comprise the following
> commits:
>
>3f7c1cab1a61 Linux 5.0.19
>64d314bd8cc8 fbdev: sm712fb: fix memory frequency by avoiding a
> switch/case fallthrough
>e5c6d75b0f03 bpf, lru: avoid messing with eviction heuristics upon
> syscall lookup
>b5f95aa7a88b bpf: add map_lookup_elem_sys_only for lookups from
> syscall side
>d811930f74ac bpf: relax inode permission check for retrieving bpf
> program
>ca7ef7e3ddfa driver core: Postpone DMA tear-down until after devres
> release for probe failure
>bad4fbe76cfb md/raid: raid5 preserve the writeback action after the
> parity check
>3770eb3721be Revert "Don't jump to compute_result state from
> check_result state"
>07116a6548c8 perf/x86/intel: Fix race in intel_pmu_disable_event()
>58d1e074c742 perf cs-etm: Always allocate memory for
> cs_etm_queue::prev_packet
>cd448c27b08e perf bench numa: Add define for RUSAGE_THREAD if not
> present
>7325696ce261 i2c: designware: ratelimit 'transfer when suspended'
> errors
>8258661858d5 ufs: fix braino in ufs_get_inode_gid() for solaris UFS
> flavour
>5b73764a5d2c KVM: selftests: make hyperv_cpuid test pass on AMD
>fb654d0763c8 KVM: fix KVM_CLEAR_DIRTY_LOG for memory slots of
> unaligned size
>497ce5c7f538 x86/mm/mem_encrypt: Disable all instrumentation for
> early SME setup
>96f0be982c8a sched/cpufreq: Fix kobject memleak
>2a9605f177f8 iwlwifi: mvm: check for length correctness in
> iwl_mvm_create_skb()
>df5eba5f41be qmi_wwan: new Wistron, ZTE and D-Link devices
>bd61ddd3e9fc bpf: Fix preempt_enable_no_resched() abuse
>bd3713424a01 tools: bpftool: fix infinite loop in map create
>1e61a219090f power: supply: sysfs: prevent endless uevent loop with
> CONFIG_POWER_SUPPLY_DEBUG
>e6ae43922897 KVM: arm/arm64: Ensure vcpu target is unset on reset
> failure
>5450811a02f5 net: ieee802154: fix missing checks for
> regmap_update_bits
>15f64f420bae mac80211: Fix kernel panic due to use of txq after free
>eff6d5429bd2 x86: kvm: hyper-v: deal with buggy TLB flush requests
> from WS2012
>48be4d7ced2c PCI: Fix issue with "pci=disable_acs_redir" parameter
> being ignored
>fa42fde1f8e6 apparmorfs: fix use-after-free on symlink traversal
>cf0259f7662a securityfs: fix use-after-free on symlink traversal
>04aa8a51e723 power: supply: cpcap-battery: Fix division by zero
>38a725dd0be7 KVM: PPC: Book3S: Protect memslots while validating
> user address
>eec0c746757b KVM: PPC: Book3S HV: Perserve PSSCR FAKE_SUSPEND bit
> on guest exit
>f3adb80bb243 clk: sunxi-ng: nkmp: Avoid GENMASK(-1, 0)
>791746a758e7 ARC: PAE40: don't panic and instead turn off hw ioc
>30bd4585bf14 xfrm4: Fix uninitialized memory read in
> _decode_session4
>79fad8fd2b76 xfrm: Honor original L3 slave device in xfrmi policy
> lookup
>ff7fa2c801bc esp4: add length check for UDP encapsulation
>4e8ce2680442 xfrm: clean up xfrm protocol checks
>6c0db1cbf772 vti4: ipip tunnel deregistration fixes.
>f8a427ca50d6 xfrm6_tunnel: Fix potential panic when unloading
> xfrm6_tunnel module
>70a87327025a xfrm: Reset secpath in xfrm failure
>9531aac1ee3e xfrm: policy: Fix out-of-bound array accesses in
> __xfrm_policy_unlink
>07a573c046c0 fuse: Add FOPEN_STREAM to use stream_open()
>560c6fd312c9 dm mpath: always free attached_handler_name in
> parse_path()
>96ecf4c59f08 dm integrity: correctly calculate the size of metadata
> area
>ecff1441aa15 dm crypt: move detailed message into debug level
>862a78341ade dm delay: fix a crash when invalid device is specified
>fab2e96c6be0 dm zoned: Fix zone report handling
>ef3f84246954 dm cache metadata: Fix loading discard bitset
>6c412dc3b757 PCI: Work around Pericom PCIe-to-PCI bridge Retrain
> Link erratum
>d06a30b1a957 PCI: Factor out pcie_retrain_link() function
>4f22ec9f0c28 PCI: rcar: Add the initialization of PCIe link in
> resume_noirq()
>fbd9c6ef0dfc PCI/AER: Change pci_aer_init() stub to return void
>

Re: [OE-core] [RFC][PATCH] systemd: Remove clearly incorrect musl patches

2019-06-20 Thread Martin Jansa
On Thu, Jun 20, 2019 at 11:09:39AM -0600, Khem Raj wrote:
> On Thu, Jun 20, 2019 at 1:15 AM Adrian Bunk  wrote:
> >
> > On Wed, Jun 19, 2019 at 12:59:05PM -0700, Khem Raj wrote:
> > > On Fri, Jun 14, 2019 at 4:44 AM Richard Purdie <
> > > richard.pur...@linuxfoundation.org> wrote:
> > >
> > > > On Fri, 2019-06-14 at 10:29 +0300, Adrian Bunk wrote:
> > > > > This removes clearly incorrect musl patches and marks
> > > > > systemd as incompatible with musl until these issues
> > > > > are fixed.
> > > > >
> > > > > The previous status quo where systemd was made compiling
> > > > > with patches that are known to introduce bugs and security
> > > > > vulnerabilities silently delivered a sub-standard package
> > > > > to users, this change makes it clear where work is needed
> > > > > to be done by people interested in systemd on musl.
> > > > >
> > > > > Patches that are merely questionable or not upstreamable
> > > > > are not touched.
> > > >
> > > > I'll be interested to see what others think of this, I can't imagine
> > > > this move being very popular...
> > >
> > > There are real products using this combination
> >
> > An OE-only combination neither upstream supports.
> >
> > > And this is not a good message, eventually we want to either fix or stop
> > > supporting this but I think now is not the time
> >
> > When is the time?
> >
> > In a month?
> > Before the Yocto 2.8 branching?
> > After the Yocto 2.8 branching?
> >
> 
> When users that I know stop using it, and that might be a release or
> two. Meanwhile
> I think it will be good to address the issues with patches, if they
> introduce bugs or secvulns
> that I think will help the user community instead of removing the support.
> 
> meanwhile, I would think that we can still work slowly towards making
> things better
> musl has provided a lot of good cleanup patches for systemd so this is
> not a wasted
> effort even if upstream systemd does not officially support anything
> besides glibc.

I don't use systemd/musl combination myself, but I agree with Khem.

As long as these bad musl related patches are applied to systemd only
when musl is used, then it's no harm to people not using systemd/musl
combo.

We can even PNBLACKLIST systemd when musl is being used with warning
that these patches are wrong and create security issues (more details
would be useful for the user to make educated decisions).

If we just remove them, then people who use this combo (for whatever
reason) will just import them to their layers and either fix them
locally (and never share it back) or use this bad version forever.

Keeping them with blacklist in oe-core will prevent people accidentally
assuming that systemd/musl is well supported combination while allowing
interested people to collaborate on fixing the patches in oe-core.

Regards,

> > The best solution would be if someone would step up to properly maintain
> > the systemd/musl combination, but usually such "either fix or stop" only
> > work with a clear deadline.
> >
> 
> 
> 
> > cu
> > Adrian
> >
> > --
> >
> >"Is there not promise of rain?" Ling Tan asked suddenly out
> > of the darkness. There had been need of rain for many days.
> >"Only a promise," Lao Er said.
> >Pearl S. Buck - Dragon Seed
> >
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


[OE-core] [PATCHv2] serf: stop scons trying to create directories in hosts rootfs

2019-06-18 Thread Martin Jansa
* since 1522f09a4d serf: cleanup recipe
  serf.do_install fails in builds with multilib enabled (with
  libdir=/usr/lib64 on host where /usr/lib64 doesn't exist)

DEBUG: Executing shell function do_install
scons: Reading SConscript files ...
PermissionError: [Errno 13] Permission denied: '/usr/lib64':
  File 
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/serf-1.3.9/SConstruct", 
line 158:
ENV = os.environ,
  File 
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Environment.py",
 line 965:
variables.Update(self)
  File 
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Variables/__init__.py",
 line 227:
option.validator(option.key, env.subst('${%s}'%option.key), env)
  File 
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/serf-1.3.9/SConstruct", 
line 60:
return PathVariable.PathIsDirCreate(key, val, env)
  File 
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Variables/PathVariable.py",
 line 101:
os.makedirs(val)
  File 
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/lib/python3.7/os.py",
 line 221:
mkdir(name, mode)
ERROR: scons install execution failed.

* I don't know how exactly --install-sandbox is supposed to work but
  in this case it's trying to mkdir /usr/lib64 on the host rootfs
  which is clearly wrong and if I set LIBDIR together with
  --install-sandbox then the install paths are prefixed with $D twice
  in some cases (not for includedir and empty libdir at the end).
  So in the end I think it was an issue caused by the custom path
  validator in serf's SConstruct, removing that stops touching host
  and the installed paths (including the paths inside libserf*.pc)
  look correct

Signed-off-by: Martin Jansa 
---
 ...ories.without.sandbox-install.prefix.patch | 71 +++
 meta/recipes-support/serf/serf_1.3.9.bb   |  1 +
 2 files changed, 72 insertions(+)
 create mode 100644 
meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch

diff --git 
a/meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
 
b/meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
new file mode 100644
index 00..91640d6044
--- /dev/null
+++ 
b/meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
@@ -0,0 +1,71 @@
+stop scons trying to create directories in hosts rootfs
+
+* since 1522f09a4d serf: cleanup recipe
+  serf.do_install fails in builds with multilib enabled (with
+  libdir=/usr/lib64 on host where /usr/lib64 doesn't exist)
+
+DEBUG: Executing shell function do_install
+scons: Reading SConscript files ...
+PermissionError: [Errno 13] Permission denied: '/usr/lib64':
+  File 
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/serf-1.3.9/SConstruct", 
line 158:
+ENV = os.environ,
+  File 
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Environment.py",
 line 965:
+variables.Update(self)
+  File 
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Variables/__init__.py",
 line 227:
+option.validator(option.key, env.subst('${%s}'%option.key), env)
+  File 
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/serf-1.3.9/SConstruct", 
line 60:
+return PathVariable.PathIsDirCreate(key, val, env)
+  File 
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Variables/PathVariable.py",
 line 101:
+os.makedirs(val)
+  File 
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/lib/python3.7/os.py",
 line 221:
+mkdir(name, mode)
+ERROR: scons install execution failed.
+
+* I don't know how exactly --install-sandbox is supposed to work but
+  in this case it's trying to mkdir /usr/lib64 on the host rootfs
+  which is clearly wrong and if I set LIBDIR together with
+  --install-sandbox then the install paths are prefixed with $D twice
+  in some cases (not for includedir and empty libdir at the end).
+  So in the end I think it was an issue caused by the custom path
+  validator in serf's SConstruct, removing that stops touching host
+  and the installed paths (including the paths inside libserf*.pc)
+  look correct
+
+Upstream-Status: Pending
+
+Signed-off-by: Martin Jansa 
+
+--- serf-1.3.9/SConstruct  2019-06-18 15:49:19.968961108 +
 serf-1.3.9b/SConstruct 2019-

Re: [OE-core] [PATCH] serf: stop scons trying to create directories in hosts rootfs

2019-06-18 Thread Martin Jansa
oe-core likes to mix them :)

On Tue, Jun 18, 2019 at 9:14 PM Khem Raj  wrote:

> On Tue, Jun 18, 2019 at 12:09 PM Martin Jansa 
> wrote:
> >
> > * since 1522f09a4d serf: cleanup recipe
> >   serf.do_install fails in builds with multilib enabled (with
> >   libdir=/usr/lib64 on host where /usr/lib64 doesn't exist)
> >
> > DEBUG: Executing shell function do_install
> > scons: Reading SConscript files ...
> > PermissionError: [Errno 13] Permission denied: '/usr/lib64':
> >   File
> "TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/serf-1.3.9/SConstruct",
> line 158:
> > ENV = os.environ,
> >   File
> "/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Environment.py",
> line 965:
> > variables.Update(self)
> >   File
> "/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Variables/__init__.py",
> line 227:
> > option.validator(option.key, env.subst('${%s}'%option.key), env)
> >   File
> "TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/serf-1.3.9/SConstruct",
> line 60:
> > return PathVariable.PathIsDirCreate(key, val, env)
> >   File
> "/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Variables/PathVariable.py",
> line 101:
> > os.makedirs(val)
> >   File
> "TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/lib/python3.7/os.py",
> line 221:
> > mkdir(name, mode)
> > ERROR: scons install execution failed.
> >
> > * I don't know how exactly --install-sandbox is supposed to work but
> >   in this case it's trying to mkdir /usr/lib64 on the host rootfs
> >   which is clearly wrong and if I set LIBDIR together with
> >   --install-sandbox then the install paths are prefixed with $D twice
> >   in some cases (not for includedir and empty libdir at the end).
> >   So in the end I think it was an issue caused by the custom path
> >   validator in serf's SConstruct, removing that stops touching host
> >   and the installed paths (including the paths inside libserf*.pc)
> >   look correct
> >
> > Signed-off-by: Martin Jansa 
> > ---
> >  ...ories.without.sandbox-install.prefix.patch | 34 +++
> >  meta/recipes-support/serf/serf_1.3.9.bb   |  1 +
> >  2 files changed, 35 insertions(+)
> >  create mode 100644
> meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
> >
> > diff --git
> a/meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
> b/meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
> > new file mode 100644
> > index 00..bfb2f5a2aa
> > --- /dev/null
> > +++
> b/meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
> > @@ -0,0 +1,34 @@
> > +--- ../1.3.9-r0-bad-double/serf-1.3.9/SConstruct   2019-06-18
> 15:49:19.968961108 +
> >  serf-1.3.9/SConstruct  2019-06-18 18:53:21.412337151 +
> > +@@ -51,17 +51,6 @@
> > + """
> > + return (key, '%s' % (help), default, None, lambda val:
> _converter(val))
> > +
> > +-# Custom path validator, creates directory when a specified option is
> set.
> > +-# To be used to ensure a PREFIX directory is only created when
> installing.
> > +-def createPathIsDirCreateWithTarget(target):
> > +-  def my_validator(key, val, env):
> > +-build_targets = (map(str, BUILD_TARGETS))
> > +-if target in build_targets:
> > +-  return PathVariable.PathIsDirCreate(key, val, env)
> > +-else:
> > +-  return PathVariable.PathAccept(key, val, env)
> > +-  return my_validator
> > +-
> > + # default directories
> > + if sys.platform == 'win32':
> > +   default_incdir='..'
> > +@@ -77,11 +66,11 @@
> > +   PathVariable('PREFIX',
> > +'Directory to install under',
> > +default_prefix,
> > +-   createPathIsDirCreateWithTarget('install')),
> > ++   PathVariable.PathAccept),
> > +   PathVariable('LIBDIR',
> > +'Directory to install architecture dependent libraries
> under',
> > +default_libdir,
> > +-   createPathIsDirCreateWithTarget('install')),
> >

[OE-core] [PATCH] serf: stop scons trying to create directories in hosts rootfs

2019-06-18 Thread Martin Jansa
* since 1522f09a4d serf: cleanup recipe
  serf.do_install fails in builds with multilib enabled (with
  libdir=/usr/lib64 on host where /usr/lib64 doesn't exist)

DEBUG: Executing shell function do_install
scons: Reading SConscript files ...
PermissionError: [Errno 13] Permission denied: '/usr/lib64':
  File 
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/serf-1.3.9/SConstruct", 
line 158:
ENV = os.environ,
  File 
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Environment.py",
 line 965:
variables.Update(self)
  File 
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Variables/__init__.py",
 line 227:
option.validator(option.key, env.subst('${%s}'%option.key), env)
  File 
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/serf-1.3.9/SConstruct", 
line 60:
return PathVariable.PathIsDirCreate(key, val, env)
  File 
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Variables/PathVariable.py",
 line 101:
os.makedirs(val)
  File 
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/lib/python3.7/os.py",
 line 221:
mkdir(name, mode)
ERROR: scons install execution failed.

* I don't know how exactly --install-sandbox is supposed to work but
  in this case it's trying to mkdir /usr/lib64 on the host rootfs
  which is clearly wrong and if I set LIBDIR together with
  --install-sandbox then the install paths are prefixed with $D twice
  in some cases (not for includedir and empty libdir at the end).
  So in the end I think it was an issue caused by the custom path
  validator in serf's SConstruct, removing that stops touching host
  and the installed paths (including the paths inside libserf*.pc)
  look correct

Signed-off-by: Martin Jansa 
---
 ...ories.without.sandbox-install.prefix.patch | 34 +++
 meta/recipes-support/serf/serf_1.3.9.bb   |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 
meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch

diff --git 
a/meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
 
b/meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
new file mode 100644
index 00..bfb2f5a2aa
--- /dev/null
+++ 
b/meta/recipes-support/serf/serf/SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
@@ -0,0 +1,34 @@
+--- ../1.3.9-r0-bad-double/serf-1.3.9/SConstruct   2019-06-18 
15:49:19.968961108 +
 serf-1.3.9/SConstruct  2019-06-18 18:53:21.412337151 +
+@@ -51,17 +51,6 @@
+ """
+ return (key, '%s' % (help), default, None, lambda val: _converter(val))
+ 
+-# Custom path validator, creates directory when a specified option is set.
+-# To be used to ensure a PREFIX directory is only created when installing.
+-def createPathIsDirCreateWithTarget(target):
+-  def my_validator(key, val, env):
+-build_targets = (map(str, BUILD_TARGETS))
+-if target in build_targets:
+-  return PathVariable.PathIsDirCreate(key, val, env)
+-else:
+-  return PathVariable.PathAccept(key, val, env)
+-  return my_validator
+-
+ # default directories
+ if sys.platform == 'win32':
+   default_incdir='..'
+@@ -77,11 +66,11 @@
+   PathVariable('PREFIX',
+'Directory to install under',
+default_prefix,
+-   createPathIsDirCreateWithTarget('install')),
++   PathVariable.PathAccept),
+   PathVariable('LIBDIR',
+'Directory to install architecture dependent libraries under',
+default_libdir,
+-   createPathIsDirCreateWithTarget('install')),
++   PathVariable.PathAccept),
+   PathVariable('APR',
+"Path to apr-1-config, or to APR's install area",
+default_incdir,
diff --git a/meta/recipes-support/serf/serf_1.3.9.bb 
b/meta/recipes-support/serf/serf_1.3.9.bb
index 92cd5ca061..25ccd79e00 100644
--- a/meta/recipes-support/serf/serf_1.3.9.bb
+++ b/meta/recipes-support/serf/serf_1.3.9.bb
@@ -6,6 +6,7 @@ SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://0002-SConstruct-Fix-path-quoting-for-.def-generator.patch \
file://0003-gen_def.patch \

file://0004-Follow-up-to-r1811083-fix-building-with-scons-3.0.0-.patch \
+
file://SConstruct.stop.creating.directories.without.sandbox-install.prefix.patch
 \
"
 
 SRC_URI[md5sum] = "370a6340ff20366ab088012cd13f2b57"
-- 
2.17.1

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


[OE-core] [PATCHv2] base.bbclass: define PACKAGECONFIG_CONFARGS before only sometimes appending to it

2019-06-18 Thread Martin Jansa
* just to make sure it's expaned by bitbake before it gets
  executed in shell
* e.g. with cmake.bbclass and cmake recipe (any recipe without
  PACKAGECONFIG options have this issue) it looks like this:
  bitbake -e cmake | grep EXTRA_OECMAKE=
  EXTRA_OECMAKE=" -DCMAKE_DOC_DIR=share/doc/cmake-3.14
-DCMAKE_USE_SYSTEM_LIBRARIES=1 -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0
-DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=0
-DCMAKE_USE_SYSTEM_LIBRARY_LIBRHASH=0 -DKWSYS_CHAR_IS_SIGNED=1
-DBUILD_CursesDialog=0 -DKWSYS_LFS_WORKS=1
\${PACKAGECONFIG_CONFARGS}"

Signed-off-by: Martin Jansa 
---
 meta/classes/base.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 90af8ba72b..0c8a4b2862 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -15,6 +15,8 @@ OE_EXTRA_IMPORTS ?= ""
 OE_IMPORTS += "os sys time oe.path oe.utils oe.types oe.package 
oe.packagegroup oe.sstatesig oe.lsb oe.cachedpath oe.license 
${OE_EXTRA_IMPORTS}"
 OE_IMPORTS[type] = "list"
 
+PACKAGECONFIG_CONFARGS ??= ""
+
 def oe_import(d):
 import sys
 
-- 
2.17.1

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


[OE-core] [PATCH] buildhistory: show time spent writting buildhistory

2019-06-18 Thread Martin Jansa
* especially when pushing longer history to slow remote git server or when
  it timeouts during the push, it's useful to see where the time was actually
  spent

Signed-off-by: Martin Jansa 
---
 meta/classes/buildhistory.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index 34709f3f88..e4e1897318 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -841,11 +841,15 @@ python buildhistory_eventhandler() {
 if e.data.getVar("BUILDHISTORY_COMMIT") == "1":
 bb.note("Writing buildhistory")
 bb.build.exec_func("buildhistory_write_sigs", d)
+import time
+start=time.time()
 localdata = bb.data.createCopy(e.data)
 localdata.setVar('BUILDHISTORY_BUILD_FAILURES', 
str(e._failures))
 interrupted = getattr(e, '_interrupted', 0)
 localdata.setVar('BUILDHISTORY_BUILD_INTERRUPTED', 
str(interrupted))
 bb.build.exec_func("buildhistory_commit", localdata)
+stop=time.time()
+bb.note("Writing buildhistory took: %s seconds" % 
round(stop-start))
 else:
 bb.note("No commit since BUILDHISTORY_COMMIT != '1'")
 }
-- 
2.17.1

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


Re: [OE-core] [PATCH] serf: cleanup recipe

2019-06-17 Thread Martin Jansa
Hello, now serf is failing to build here:


DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are
['TOPDIR/oe-core/meta/recipes-devtools/gcc/gcc-runtime_9.1.bb:do_populate_sysroot',
'TOPDIR/oe-core/meta/recipes-core/util-linux/util-linux_2.33.2.bb:do_populate_sysroot',
'virtual:native:TOPDIR/oe-core/meta/recipes-devtools/python/python3_3.7.3.bb:do_populate_sysroot',
'TOPDIR/oe-core/meta/recipes-core/expat/expat_2.2.6.bb:do_populate_sysroot',
'TOPDIR/oe-core/meta/recipes-core/glibc/glibc_2.29.bb:do_populate_sysroot',
'TOPDIR/oe-core/meta/recipes-support/apr/apr_1.7.0.bb:do_populate_sysroot',
'virtual:native:TOPDIR/oe-core/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot',
'TOPDIR/oe-core/meta/recipes-devtools/gcc/gcc-cross_9.1.bb:do_populate_sysroot',
'TOPDIR/oe-core/meta/recipes-support/apr/apr-util_1.6.1.bb:do_populate_sysroot',
'TOPDIR/oe-core/meta/recipes-devtools/python/python3-scons-native_3.0.5.bb:do_populate_sysroot',
'TOPDIR/oe-core/meta/recipes-connectivity/openssl/openssl_1.1.1c.bb:do_populate_sysroot',
'TOPDIR/oe-core/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot',
'virtual:native:TOPDIR/oe-core/meta/recipes-devtools/icecc-create-env/icecc-create-env_0.1.bb:
do_populate_sysroot']
NOTE: Installed into sysroot: ['pseudo-native']
NOTE: Skipping as already exists in sysroot: ['gcc-runtime', 'util-linux',
'python3-native', 'expat', 'glibc', 'apr', 'gcc-cross-x86_64', 'apr-util',
'python3-scons-native', 'openssl', 'quilt-native',
'icecc-create-env-native', 'linux-libc-headers', 'libgcc',
'bash-completion', 'zlib', 'opkg-utils', 'libxcrypt', 'ncurses',
'gmp-native', 'libmpc-native', 'autoconf-native', 'zlib-native',
'mpfr-native', 'gnu-config-native', 'automake-native', 'libtool-native',
'xz-native', 'binutils-cross-x86_64', 'texinfo-dummy-native',
'flex-native', 'gdbm', 'libtirpc-native', 'sqlite3-native',
'util-linux-native', 'libffi-native', 'gdbm-native', 'bzip2-native',
'pkgconfig-native', 'readline-native', 'openssl-native', 'libnsl2-native',
'm4-native', 'gettext-minimal-native', 'ncurses-native']
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing shell function do_install
scons: Reading SConscript files ...
PermissionError: [Errno 13] Permission denied: '/usr/lib64':
  File
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/serf-1.3.9/SConstruct",
line 158:
ENV = os.environ,
  File
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Environment.py",
line 965:
variables.Update(self)
  File
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Variables/__init__.py",
line 227:
option.validator(option.key, env.subst('${%s}'%option.key), env)
  File
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/serf-1.3.9/SConstruct",
line 60:
return PathVariable.PathIsDirCreate(key, val, env)
  File
"/TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/bin/../../usr/lib/python3.7/site-packages/SCons/Variables/PathVariable.py",
line 101:
os.makedirs(val)
  File
"TOPDIR/BUILD/work/qemux86-signage-linux/serf/1.3.9-r0/recipe-sysroot-native/usr/lib/python3.7/os.py",
line 221:
mkdir(name, mode)
ERROR: scons install execution failed.
WARNING: exit code 1 from a shell command.

Maybe it fails only with multilib enabled, but it wasn't failing before the
cleanup.

Anyone else seeing this?

On Thu, Jun 13, 2019 at 2:01 AM Anuj Mittal  wrote:

> * Inherit scons bbclass and use the task definitions from there.
> * Remove the DEPENDS on python3-scons-native that is already present in
> scons class.
>
> Signed-off-by: Anuj Mittal 
> ---
>  meta/recipes-support/serf/serf_1.3.9.bb | 23 ---
>  1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/meta/recipes-support/serf/serf_1.3.9.bb
> b/meta/recipes-support/serf/serf_1.3.9.bb
> index 706c86be47..92cd5ca061 100644
> --- a/meta/recipes-support/serf/serf_1.3.9.bb
> +++ b/meta/recipes-support/serf/serf_1.3.9.bb
> @@ -14,18 +14,19 @@ SRC_URI[sha256sum] =
> "549c2d21c577a8a9c0450facb5cca809f26591f048e466552240947bdf
>  LICENSE = "Apache-2.0"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=86d3f3a95c324c9479bd8986968f4327"
>
> -DEPENDS = "python3-scons-native openssl apr apr-util util-linux expat"
> +inherit scons
>
> -do_compile() {
> -   ${STAGING_BINDIR_NATIVE}/scons ${PARALLEL_MAKE} PREFIX=${prefix} \
> -   CC="${CC}" \
> -   APR=`which apr-1-config` APU=`which apu-1-config` \
> -   CFLAGS="${CFLAGS}" LINKFLAGS="${LDFLAGS}" \
> -   OPENSSL="${STAGING_EXECPREFIXDIR}"
> -}
> +DEPENDS += " openssl apr apr-util util-linux expat"
>
> -do_install() {
> -   ${STAGING_BINDIR_NATIVE}/scons PREFIX=${D}${prefix}
> LIBDIR=${D}${libdir} install
> -}
> +EXTRA_OESCONS = " \
> +  LIBDIR=${libdir} \

Re: [OE-core] [PATCH 1/2] mesa: make gallium swrast target optional

2019-06-13 Thread Martin Jansa
Sure, follow-up patch is fine with me.

On Thu, Jun 13, 2019 at 8:38 PM Marco Felsch 
wrote:

> Hi Martin,
>
> On 19-06-13 20:17, Martin Jansa wrote:
> > Looks like nice cleanup, but is someone still using llvm 3.2 or older?
>
> I don't know but I learned to avoid breaking changes.
>
> > With PACKAGECONFIG for almost each gallium driver it might be easier to
> get
> > rid
> > of GALLIUMDRIVERS_LLVM33, GALLIUMDRIVERS_LLVM33_ENABLED,
> GALLIUMDRIVERS_LLVM
> > variables and use just GALLIUMDRIVERS.
>
> Sure that will increase readability and drops unneeded variables :) But
> can we add a follow up patch to address this?
>
> > In worst case scenario people using llvm 3.2 or older will need to
> redefine
> > some of these PACKAGECONFIGs but that shouldn't be big issue considering
> > that they probably have different mesa recipe already.
>
> I'm not that deep inside LLVM just googled it and saw that the current
> version is 8.0.1 so maybe you are right.
>
> > People can then select right list of drivers with or without
> > using gallium-llvm as well.
>
> As I wrote above we should address this by a seperate patch to keep the
> diff as small as possible :)
>
> Regards,
>   Marco
>
> >
> >
> > On Thu, Jun 13, 2019 at 7:54 PM Marco Felsch 
> > wrote:
> >
> > > Most of the time we are compiling for embedded targets which have
> > > dedicated hardware combinations. Enabling swrast by default isn't a
> good
> > > solution for such devices because if the hardware render node has an
> > > issue or doesn't support a special format/request Mesa will fallback to
> > > the software renderer. This will make it harder to debug performance
> > > issues.
> > >
> > > A better way is to let the user decide if a software renderer is
> > > needed e.g. if the system has no hardware renderer or to have such a
> > > fallback device. This way the user knows that the software renderer is
> > > enabled.
> > >
> > > Signed-off-by: Marco Felsch 
> > > ---
> > > v3
> > > - rebased on current master-next branch
> > >
> > >  meta/recipes-graphics/mesa/mesa.inc | 22 +-
> > >  1 file changed, 13 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/meta/recipes-graphics/mesa/mesa.inc
> > > b/meta/recipes-graphics/mesa/mesa.inc
> > > index 3ecfb8506c..a6d36cf21c 100644
> > > --- a/meta/recipes-graphics/mesa/mesa.inc
> > > +++ b/meta/recipes-graphics/mesa/mesa.inc
> > > @@ -90,23 +90,27 @@ PACKAGECONFIG[egl] = "-Degl=true, -Degl=false"
> > >
> > >  PACKAGECONFIG[etnaviv] = ""
> > >  PACKAGECONFIG[kmsro] = ""
> > > +PACKAGECONFIG[swrast] = ""
> > >
> > > -GALLIUMDRIVERS = "swrast"
> > > -GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG',
> 'etnaviv',
> > > ',etnaviv', '', d)}"
> > > -GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'kmsro',
> > > ',kmsro', '', d)}"
> > > +GALLIUMDRIVERS = ""
> > > +GALLIUMDRIVERS +="${@bb.utils.contains('PACKAGECONFIG', 'swrast',
> > > 'swrast', '', d)}"
> > > +GALLIUMDRIVERS +="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv',
> > > 'etnaviv', '', d)}"
> > > +GALLIUMDRIVERS +="${@bb.utils.contains('PACKAGECONFIG', 'kmsro',
> 'kmsro',
> > > '', d)}"
> > >
> > >  # radeonsi requires LLVM
> > > -GALLIUMDRIVERS_LLVM33 = "${@bb.utils.contains('PACKAGECONFIG', 'r600',
> > > ',radeonsi', '', d)}"
> > > +GALLIUMDRIVERS_LLVM33 = "${@bb.utils.contains('PACKAGECONFIG', 'r600',
> > > 'radeonsi', '', d)}"
> > >  GALLIUMDRIVERS_LLVM33_ENABLED =
> > > "${@oe.utils.version_less_or_equal('MESA_LLVM_RELEASE', '3.2', False,
> > > len('${GALLIUMDRIVERS_LLVM33}') > 0, d)}"
> > > -GALLIUMDRIVERS_LLVM =
> "r300,svga,nouveau${@',${GALLIUMDRIVERS_LLVM33}' if
> > > ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
> > > +GALLIUMDRIVERS_LLVM = "r300 svga nouveau
> ${@'${GALLIUMDRIVERS_LLVM33}' if
> > > ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
> > >
> > >  PACKAGECONFIG[r600] = ""
> > >
> > > -GALLIUMDRIVERS_append = "${@bb.utils.contains('PACKAGECONFIG',
> > > 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
> > > -GALLIUMDRIVERS_append = "${@bb.utils.contains

Re: [OE-core] [PATCH 1/2] mesa: make gallium swrast target optional

2019-06-13 Thread Martin Jansa
Looks like nice cleanup, but is someone still using llvm 3.2 or older?

With PACKAGECONFIG for almost each gallium driver it might be easier to get
rid
of GALLIUMDRIVERS_LLVM33, GALLIUMDRIVERS_LLVM33_ENABLED, GALLIUMDRIVERS_LLVM
variables and use just GALLIUMDRIVERS.

In worst case scenario people using llvm 3.2 or older will need to redefine
some of these PACKAGECONFIGs but that shouldn't be big issue considering
that they probably have different mesa recipe already.

People can then select right list of drivers with or without
using gallium-llvm as well.


On Thu, Jun 13, 2019 at 7:54 PM Marco Felsch 
wrote:

> Most of the time we are compiling for embedded targets which have
> dedicated hardware combinations. Enabling swrast by default isn't a good
> solution for such devices because if the hardware render node has an
> issue or doesn't support a special format/request Mesa will fallback to
> the software renderer. This will make it harder to debug performance
> issues.
>
> A better way is to let the user decide if a software renderer is
> needed e.g. if the system has no hardware renderer or to have such a
> fallback device. This way the user knows that the software renderer is
> enabled.
>
> Signed-off-by: Marco Felsch 
> ---
> v3
> - rebased on current master-next branch
>
>  meta/recipes-graphics/mesa/mesa.inc | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index 3ecfb8506c..a6d36cf21c 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -90,23 +90,27 @@ PACKAGECONFIG[egl] = "-Degl=true, -Degl=false"
>
>  PACKAGECONFIG[etnaviv] = ""
>  PACKAGECONFIG[kmsro] = ""
> +PACKAGECONFIG[swrast] = ""
>
> -GALLIUMDRIVERS = "swrast"
> -GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv',
> ',etnaviv', '', d)}"
> -GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'kmsro',
> ',kmsro', '', d)}"
> +GALLIUMDRIVERS = ""
> +GALLIUMDRIVERS +="${@bb.utils.contains('PACKAGECONFIG', 'swrast',
> 'swrast', '', d)}"
> +GALLIUMDRIVERS +="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv',
> 'etnaviv', '', d)}"
> +GALLIUMDRIVERS +="${@bb.utils.contains('PACKAGECONFIG', 'kmsro', 'kmsro',
> '', d)}"
>
>  # radeonsi requires LLVM
> -GALLIUMDRIVERS_LLVM33 = "${@bb.utils.contains('PACKAGECONFIG', 'r600',
> ',radeonsi', '', d)}"
> +GALLIUMDRIVERS_LLVM33 = "${@bb.utils.contains('PACKAGECONFIG', 'r600',
> 'radeonsi', '', d)}"
>  GALLIUMDRIVERS_LLVM33_ENABLED =
> "${@oe.utils.version_less_or_equal('MESA_LLVM_RELEASE', '3.2', False,
> len('${GALLIUMDRIVERS_LLVM33}') > 0, d)}"
> -GALLIUMDRIVERS_LLVM = "r300,svga,nouveau${@',${GALLIUMDRIVERS_LLVM33}' if
> ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
> +GALLIUMDRIVERS_LLVM = "r300 svga nouveau ${@'${GALLIUMDRIVERS_LLVM33}' if
> ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
>
>  PACKAGECONFIG[r600] = ""
>
> -GALLIUMDRIVERS_append = "${@bb.utils.contains('PACKAGECONFIG',
> 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
> -GALLIUMDRIVERS_append = "${@bb.utils.contains('PACKAGECONFIG', 'r600',
> ',r600', '', d)}"
> -GALLIUMDRIVERS_append = ",virgl"
> +GALLIUMDRIVERS += "${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm',
> '${GALLIUMDRIVERS_LLVM}', '', d)}"
> +GALLIUMDRIVERS += "${@bb.utils.contains('PACKAGECONFIG', 'r600', 'r600',
> '', d)}"
> +GALLIUMDRIVERS += "virgl"
> +GALLIUMDRIVERS_MESON = "${@",".join("${GALLIUMDRIVERS}".split())}"
> +
> +PACKAGECONFIG[gallium] = "-Dgallium-drivers=${GALLIUMDRIVERS_MESON},
> -Dgallium-drivers=''"
>
> -PACKAGECONFIG[gallium] = "-Dgallium-drivers=${GALLIUMDRIVERS},
> -Dgallium-drivers=''"
>  MESA_LLVM_RELEASE ?= "8.0.0"
>  PACKAGECONFIG[gallium-llvm] = "-Dllvm=true -Dshared-llvm=true,
> -Dllvm=false, llvm${MESA_LLVM_RELEASE} llvm-native \
> ${@'elfutils' if
> ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
> --
> 2.20.1
>
> --
> ___
> 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] [warrior][PATCH] bc: use u-a for bc as well

2019-06-13 Thread Martin Jansa
From: Martin Jansa 

* bc can be provided by busybox as well (e.g. if you have your own
  defconfig and forget to explicitly disable it:
  ...
  *
  * Miscellaneous Utilities
  *
  adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
  bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
  bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y] (NEW) y
  Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW) Enable 
bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4 kb) (BEEP) 
[N/y/?] n
  chat (6.3 kb) (CHAT) [N/y/?] n
  conspy (10 kb) (CONSPY) [N/y/?] n
  ...
  ), causing conflict in u-a:

  update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid 
since /usr/bin/bc exists and is not a link

  and then whole do_rootfs or do_populate_sdk to fail because busybox postinst 
is failing:

  do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed. If the 
intention is to defer them to first boot,
  then please place them into pkg_postinst_ontarget_${PN} (). Deferring to 
first boot via 'exit 1' is no longer supported.

Signed-off-by: Martin Jansa 
Signed-off-by: Richard Purdie 
---
 meta/recipes-extended/bc/bc_1.07.1.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/bc/bc_1.07.1.bb 
b/meta/recipes-extended/bc/bc_1.07.1.bb
index e80857745e..809b864c1a 100644
--- a/meta/recipes-extended/bc/bc_1.07.1.bb
+++ b/meta/recipes-extended/bc/bc_1.07.1.bb
@@ -27,7 +27,7 @@ do_compile_prepend() {
 cp -f ${WORKDIR}/libmath.h ${B}/bc/libmath.h
 }
 
-ALTERNATIVE_${PN} = "dc"
+ALTERNATIVE_${PN} = "bc dc"
 ALTERNATIVE_PRIORITY = "100"
 
-BBCLASSEXTEND = "native"
\ No newline at end of file
+BBCLASSEXTEND = "native"
-- 
2.17.1

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


[OE-core] [PATCH] pigz: install pigz, unpigz, pigzcat in native and nativesdk builds again

2019-06-12 Thread Martin Jansa
* since this commit:
  commit ad1db93d134db1ec4f6d6598c9741dc13e82e1f3
  Author: Anuj Mittal 
  Date:   Tue May 28 06:32:10 2019 +0800
  Subject: Revert "pigz: pigz is not gzip"

  pigz-native and nativesdk-pigz no longer installs pigz, unpigz, pigzcat,
  so scripts explicitly depending on pigz-native and calling pigz started to 
fail.

* reverse the logic
  - all the builds install pigz, unpigz, pigzcat
  - only the native one installs it as gzip as well

* it could be optimized a bit more to create gzip as just a symlink
  in native case as well, but they are in different directories
  (pigz in base_bindir and gzip in bindir) and it's only 130kB..

Signed-off-by: Martin Jansa 
---
 meta/recipes-extended/pigz/pigz_2.4.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/pigz/pigz_2.4.bb 
b/meta/recipes-extended/pigz/pigz_2.4.bb
index 974c035147..6d62ce6cc5 100644
--- a/meta/recipes-extended/pigz/pigz_2.4.bb
+++ b/meta/recipes-extended/pigz/pigz_2.4.bb
@@ -23,7 +23,7 @@ EXTRA_OEMAKE = "-e MAKEFLAGS="
 
 inherit update-alternatives
 
-do_install_class-target() {
+do_install() {
# Install files into /bin (FHS), which is typical place for gzip
install -d ${D}${base_bindir}
install ${B}/pigz ${D}${base_bindir}/pigz
@@ -31,7 +31,7 @@ do_install_class-target() {
ln -nsf pigz ${D}${base_bindir}/pigzcat
 }
 
-do_install() {
+do_install_append_class-native() {
install -d ${D}${bindir}
install ${B}/pigz ${D}${bindir}/gzip
ln -nsf gzip ${D}${bindir}/gunzip
-- 
2.17.1

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


Re: [OE-core] meta-openembedded git repo in some of the openembedded-core-contrib branches

2019-06-12 Thread Martin Jansa
Thanks!

On Wed, Jun 12, 2019 at 3:35 AM Hongxu Jia  wrote:

> On 6/12/19 4:01 AM, Martin Jansa wrote:
> > Hi,
> >
> > when accidentally checking for some old meta-oe commit in oe-core
> > repository I was surprised that it was found in some of the contrib
> > branches:
>
> Sorry for the mistake
>
> > ~/openembedded-core $ git branch -a --contains 30bbde3d09e
> >remotes/contrib/hongxu/add-recipes-20190215
> >remotes/contrib/hongxu/dbg-split
> >remotes/contrib/hongxu/misc-fixes
> >
> > These branches are actually from meta-oe repo, not oe-core.
> >
> > Please remove old irrelevant branches from -contrib repositories:
> > https://git.openembedded.org/openembedded-core-contrib/
> > https://git.openembedded.org/meta-openembedded-contrib/
> >
> > and make sure you're pushing to the right remote :), it unnecessary
> > almost doubles the repo size.
>
> I 've already cleaned them up on openembedded-core
>
> //Hongxu
>
> > Cheers,
>
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 2/2] Revert "image_types: use pigz to create .gz files"

2019-06-11 Thread Martin Jansa
This is just FYI:

This probably won't happen with most of OE use-cases, but even with pigz
being the drop in replacement, there are some differences, e.g. when I'm
using pigz-2.4 on my Gentoo host as gzip, xmltex-1.9.tar.gz fails to unpack
gzip: warning:
/tmp/tmpfs/portage/dev-tex/xmltex-1.9-r2/distdir/xmltex-1.9.tar.gz:
trailing junk was ignored
ERROR: dev-tex/xmltex-1.9-r2::gentoo failed (unpack phase):
   unpack: failure unpacking xmltex-1.9.tar.gz

yes xmltex-1.9.tar.gz has something strange in the archive and emerge
should ignore the error from gzip (gzip itself shows it only as a warning),
but it doesn't and it's a bit confusing to find out that gzip is actually
pigz for someone who didn't see this commit :).

On Mon, May 27, 2019 at 3:44 PM Anuj Mittal  wrote:

> This reverts commit a559ffab30b7b45849ace023808c1fb20811d43d.
>
> This is not needed now that pigz has been marked as a drop-in
> replacement.
>
> Signed-off-by: Anuj Mittal 
> ---
>  meta/classes/image_types.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/image_types.bbclass
> b/meta/classes/image_types.bbclass
> index 1c44ec4a80..fd98a7d1bd 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -284,7 +284,7 @@ COMPRESSIONTYPES ?= ""
>
>  CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip sum md5sum sha1sum
> sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vdi qcow2 base64
> ${COMPRESSIONTYPES}"
>  CONVERSION_CMD_lzma = "lzma -k -f -7
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
> -CONVERSION_CMD_gz = "pigz -f -9 -n -c
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
> +CONVERSION_CMD_gz = "gzip -f -9 -n -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}"
>  CONVERSION_CMD_xz = "xz -f -k -c ${XZ_COMPRESSION_LEVEL} ${XZ_DEFAULTS}
> --check=${XZ_INTEGRITY_CHECK} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} >
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.xz"
>  CONVERSION_CMD_lz4 = "lz4 -9 -z -l
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}
> ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.lz4"
> --
> 2.20.1
>
> --
> ___
> 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] meta-openembedded git repo in some of the openembedded-core-contrib branches

2019-06-11 Thread Martin Jansa
Hi,

when accidentally checking for some old meta-oe commit in oe-core
repository I was surprised that it was found in some of the contrib
branches:

~/openembedded-core $ git branch -a --contains 30bbde3d09e
  remotes/contrib/hongxu/add-recipes-20190215
  remotes/contrib/hongxu/dbg-split
  remotes/contrib/hongxu/misc-fixes

These branches are actually from meta-oe repo, not oe-core.

Please remove old irrelevant branches from -contrib repositories:
https://git.openembedded.org/openembedded-core-contrib/
https://git.openembedded.org/meta-openembedded-contrib/

and make sure you're pushing to the right remote :), it unnecessary
almost doubles the repo size.

Cheers,


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


Re: [OE-core] [PATCH] json-c: update to current upstream head, with --disable-werror

2019-06-10 Thread Martin Jansa
Also the version went from 0.13.2 to 1.0 which doesn't match with the
sources. Don't forget to set PV when migrating recipes to use git fetcher.

On Tue, Jun 11, 2019 at 3:58 AM Douglas Royds via Openembedded-core <
openembedded-core@lists.openembedded.org> wrote:

> Upstream json-c haven't made a release since March 2018.
> Adopt the current HEAD revision, pulling it directly from git.
>
> icecc preprocesses source files locally before shipping them off to be
> compiled
> on remote hosts. This preprocessing removes comments, including /*
> fallthough */
> comments in switch statements that normally prevent an implicit-fallthrough
> warning, see https://github.com/icecc/icecream/issues/419
>
> Rather than turning off -Werror by patching configure.ac, the upstream
> project
> has implemented a configure option, --disable-werror, in response to Ross's
> https://github.com/json-c/json-c/issues/489
>
> Signed-off-by: Douglas Royds 
> ---
>  meta/recipes-devtools/json-c/json-c_0.13.1.bb | 30 ---
>  meta/recipes-devtools/json-c/json-c_git.bb| 19 
>  2 files changed, 19 insertions(+), 30 deletions(-)
>  delete mode 100644 meta/recipes-devtools/json-c/json-c_0.13.1.bb
>  create mode 100644 meta/recipes-devtools/json-c/json-c_git.bb
>
> diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
> b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
> deleted file mode 100644
> index 5b10e68297..00
> --- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -SUMMARY = "C bindings for apps which will manipulate JSON data"
> -DESCRIPTION = "JSON-C implements a reference counting object model that
> allows you to easily construct JSON objects in C."
> -HOMEPAGE = "https://github.com/json-c/json-c/wiki;
> -LICENSE = "MIT"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"
> -
> -SRC_URI = "https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz
> "
> -SRC_URI[md5sum] = "04969ad59cc37bddd83741a08b98f350"
> -SRC_URI[sha256sum] =
> "b87e608d4d3f7bfdd36ef78d56d53c74e66ab278d318b71e6002a369d36f4873"
> -
> -UPSTREAM_CHECK_REGEX = "json-c-(?P\d+(\.\d+)+).tar"
> -# json-c releases page is fetching the list of releases in some weird XML
> format
> -# from https://s3.amazonaws.com/json-c_releases and processes it with
> javascript :-/
> -#UPSTREAM_CHECK_URI = "
> https://s3.amazonaws.com/json-c_releases/releases/index.html;
> -RECIPE_UPSTREAM_VERSION = "0.13.1"
> -RECIPE_UPSTREAM_DATE = "Mar 04, 2018"
> -CHECK_DATE = "May 02, 2018"
> -
> -RPROVIDES_${PN} = "libjson"
> -
> -inherit autotools
> -
> -EXTRA_OECONF = "--enable-rdrand"
> -
> -do_configure_prepend() {
> -# Clean up autoconf cruft that should not be in the tarball
> -rm -f ${S}/config.status
> -}
> -
> -BBCLASSEXTEND = "native nativesdk"
> diff --git a/meta/recipes-devtools/json-c/json-c_git.bb
> b/meta/recipes-devtools/json-c/json-c_git.bb
> new file mode 100644
> index 00..07daa5ba11
> --- /dev/null
> +++ b/meta/recipes-devtools/json-c/json-c_git.bb
> @@ -0,0 +1,19 @@
> +SUMMARY = "C bindings for apps which will manipulate JSON data"
> +DESCRIPTION = "JSON-C implements a reference counting object model that
> allows you to easily construct JSON objects in C."
> +HOMEPAGE = "https://github.com/json-c/json-c/wiki;
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"
> +
> +SRC_URI = "git://github.com/json-c/json-c.git"
> +SRCREV = "07ea04e65193c3e5c902c5b79421d5fa48ff67c7"
> +S = "${WORKDIR}/git"
> +
> +RPROVIDES_${PN} = "libjson"
> +
> +inherit autotools
> +
> +EXTRA_OECONF = "--disable-werror \
> +--enable-rdrand \
> +"
> +
> +BBCLASSEXTEND = "native nativesdk"
> --
> 2.17.1
>
> --
> ___
> 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] [warrior][PATCH] dbus-test: Improve ptest dependencies dependencies

2019-06-09 Thread Martin Jansa
From: Richard Purdie 

The dbus-test package is empty, move its dependencies to the ${PN}-ptest
package. Also ensure that it doesn't depend on the empty ${PN} package
which is about to start causing image failures in the following commit.
In this case the correct dependency is dbus itself.

Signed-off-by: Richard Purdie 
---
 meta/recipes-core/dbus/dbus-test_1.12.12.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/dbus/dbus-test_1.12.12.bb 
b/meta/recipes-core/dbus/dbus-test_1.12.12.bb
index f4131926c2..486a996879 100644
--- a/meta/recipes-core/dbus/dbus-test_1.12.12.bb
+++ b/meta/recipes-core/dbus/dbus-test_1.12.12.bb
@@ -7,7 +7,6 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
 
 DEPENDS = "dbus glib-2.0"
 
-RDEPENDS_${PN} += "make"
 RDEPENDS_${PN}-dev = ""
 
 SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
@@ -78,6 +77,7 @@ do_install_ptest() {
 sed -i -e 's;@PTEST_PATH@;${PTEST_PATH};g'  ${D}${PTEST_PATH}/run-ptest
 }
 
-RDEPENDS_${PN}-ptest += "bash"
+RDEPENDS_${PN}-ptest += "bash make dbus"
+RDEPENDS_${PN}-ptest_remove = "${PN}"
 
 PRIVATE_LIBS_${PN}-ptest = "libdbus-1.so.3"
-- 
2.17.1

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


Re: [OE-core] [oe-commits] [openembedded-core] 21/35: ptest: Add RDEPENDS frpm PN-ptest to PN package

2019-06-09 Thread Martin Jansa
On Fri, Jun 07, 2019 at 12:58:30PM +, g...@git.openembedded.org wrote:
> This is an automated email from the git hooks/post-receive script.
> 
> rpurdie pushed a commit to branch warrior
> in repository openembedded-core.
> 
> commit 1ad805984c8c9c9a505b6b0e8ad870b8233b13b2
> Author: Richard Purdie 
> AuthorDate: Tue May 14 12:22:14 2019 +0100
> 
> ptest: Add RDEPENDS frpm PN-ptest to PN package

Hi,

this in warrior is causing following do_rootfs error:

nothing provides dbus-test needed by dbus-test-ptest-1.12.12-r0

in images with dbus-test and ptest enabled.

you need to backport:
commit db4ef506b6b86e62a5ee1cbea8f12f97615dd0b8
Author: Richard Purdie 
Date:   Tue May 14 17:28:08 2019 +0100

dbus-test: Improve ptest dependencies dependencies

as well, to resolve this (will send it in separate e-mail).

> 
> Many different ptests are breaking as they assume that ${PN}-ptest
> depends on ${PN}. It doesn't currently but should. If we fix this, many
> different ptests start passing when they previously failed.
> 
> It does depend on fixing an issue in the dbus-test recipe which is done
> in the preceeding patch (mentioned in case this gets backported).
> 
> Signed-off-by: Richard Purdie 
> Signed-off-by: Armin Kuster 
> ---
>  meta/classes/ptest.bbclass | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/classes/ptest.bbclass b/meta/classes/ptest.bbclass
> index 936bf82..fa4c36e 100644
> --- a/meta/classes/ptest.bbclass
> +++ b/meta/classes/ptest.bbclass
> @@ -13,6 +13,7 @@ PTEST_ENABLED = "${@bb.utils.contains('DISTRO_FEATURES', 
> 'ptest', '1', '0', d)}"
>  PTEST_ENABLED_class-native = ""
>  PTEST_ENABLED_class-nativesdk = ""
>  PTEST_ENABLED_class-cross-canadian = ""
> +RDEPENDS_${PN}-ptest += "${PN}"
>  RDEPENDS_${PN}-ptest_class-native = ""
>  RDEPENDS_${PN}-ptest_class-nativesdk = ""
>  RRECOMMENDS_${PN}-ptest += "ptest-runner"
> 
> -- 
> To stop receiving notification emails like this one, please contact
> the administrator of this repository.
> -- 
> ___
> Openembedded-commits mailing list
> openembedded-comm...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-commits

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


[OE-core] [warrior][PATCH] grub-efi-cfg, systemd-boot-cfg: use MACHINE_ARCH

2019-06-08 Thread Martin Jansa
* both use KERNEL_IMAGETYPE variable which is MACHINE specific
* fixes:

  === Comparing signatures for task do_configure.sigdata between hammerhead and 
mako ===
  ERROR: grub-bootconf different signature for task do_configure.sigdata 
between hammerhead and mako
  basehash changed from 
710332f3ec15670302dd690708730c9e418d53790ce36d6a91b049ae4f7069b1 to 
c9a46e58b4634b5fd47d20683f8320e15f5c4cb7628e3a62ed97d8528d7aabd2
  Variable KERNEL_IMAGETYPE value changed from 'zImage-dtb' to 'zImage'

  ERROR: systemd-bootconf different signature for task do_configure.sigdata 
between hammerhead and mako
  basehash changed from 
2abbaf6d7760696fbf1ff5df5705239b475ccbf6f0c831fc4031984c0ce0e9f2 to 
24f1e7886dee02b04bc180acc1c946ad82ce842655e5a5f4a8006f4a8490f985
  Variable KERNEL_IMAGETYPE value changed from 'zImage-dtb' to 'zImage'

  detected with:
  openembedded-core/scripts/sstate-diff-machines.sh --targets=world 
--tmpdir=tmp-glibc/ --analyze --machines="hammerhead mako qemux86"

Signed-off-by: Martin Jansa 
---
 meta/classes/grub-efi-cfg.bbclass | 3 +++
 meta/classes/systemd-boot-cfg.bbclass | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/meta/classes/grub-efi-cfg.bbclass 
b/meta/classes/grub-efi-cfg.bbclass
index 56c2e3..f661a69f83 100644
--- a/meta/classes/grub-efi-cfg.bbclass
+++ b/meta/classes/grub-efi-cfg.bbclass
@@ -27,6 +27,9 @@ EFIDIR = "/EFI/BOOT"
 GRUB_ROOT ?= "${ROOT}"
 APPEND ?= ""
 
+# Uses MACHINE specific KERNEL_IMAGETYPE
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
 # Need UUID utility code.
 inherit fs-uuid
 
diff --git a/meta/classes/systemd-boot-cfg.bbclass 
b/meta/classes/systemd-boot-cfg.bbclass
index 021c9f9331..b3e0e6ad41 100644
--- a/meta/classes/systemd-boot-cfg.bbclass
+++ b/meta/classes/systemd-boot-cfg.bbclass
@@ -2,6 +2,9 @@ SYSTEMD_BOOT_CFG ?= "${S}/loader.conf"
 SYSTEMD_BOOT_ENTRIES ?= ""
 SYSTEMD_BOOT_TIMEOUT ?= "10"
 
+# Uses MACHINE specific KERNEL_IMAGETYPE
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
 # Need UUID utility code.
 inherit fs-uuid
 
-- 
2.17.1

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


Re: [OE-core] [PATCH] lrzsz: Add implicit declaration fixes from Debian

2019-06-05 Thread Martin Jansa
On Mon, Jun 03, 2019 at 09:47:02AM +0300, Adrian Bunk wrote:
> Signed-off-by: Adrian Bunk 
> --

You need one more dash here, now this v2 comment ended in final commit message
which I believe wasn't the intention.

http://git.openembedded.org/openembedded-core/commit/?id=6fa60ac102f6d3977df4236bd5a22680298bdac2

the same with tcp-wrappers change:
http://git.openembedded.org/openembedded-core/commit/?id=cd1dc2334fd3e3d1db9be1d26e888051e3f59c5a

> v2: Add comment in the patch header.
> ---
>  .../lrzsz/lrzsz-0.12.20/include.patch | 25 +++
>  meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb   |  1 +
>  2 files changed, 26 insertions(+)
>  create mode 100644 meta/recipes-bsp/lrzsz/lrzsz-0.12.20/include.patch
> 
> diff --git a/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/include.patch 
> b/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/include.patch
> new file mode 100644
> index 00..5fcb3aa92b
> --- /dev/null
> +++ b/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/include.patch
> @@ -0,0 +1,25 @@
> +Implicit declaration compile warning fixes from Debian
> +
> +Signed-off-by: Adrian Bunk 
> +Upstream-Status: Inappropriate [upstream is dead]
> +
> +--- lrzsz-0.12.21.orig/lib/long-options.c
>  lrzsz-0.12.21/lib/long-options.c
> +@@ -22,6 +22,7 @@
> + #endif
> + 
> + #include 
> ++#include 
> + #include 
> + #include "long-options.h"
> + 
> +--- lrzsz-0.12.21.orig/src/lsyslog.c
>  lrzsz-0.12.21/src/lsyslog.c
> +@@ -22,6 +22,7 @@
> + #ifdef ENABLE_SYSLOG
> + #include "zglobal.h"
> + #include 
> ++#include 
> + #include 
> + #include 
> + #endif
> diff --git a/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb 
> b/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb
> index 002c774c6d..34556b2c29 100644
> --- a/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb
> +++ b/meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb
> @@ -20,6 +20,7 @@ SRC_URI = 
> "http://www.ohse.de/uwe/releases/lrzsz-${PV}.tar.gz \
>  file://lrzsz_fix_for_automake-1.12.patch \
> file://lrzsz-check-locale.h.patch \
> file://cve-2018-10195.patch \
> +   file://include.patch \
> "
>  
>  SRC_URI[md5sum] = "b5ce6a74abc9b9eb2af94dffdfd372a4"
> -- 
> 2.17.1
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


[OE-core] [PATCHv2] opkg-utils: fix opkg-list-fields script

2019-06-04 Thread Martin Jansa
Signed-off-by: Martin Jansa 
---

v2: Upstream-Status changed from Submitted to Backport

 ...fields-fix-to-print-the-fields-again.patch | 41 +++
 .../opkg-utils/opkg-utils_0.4.0.bb|  1 +
 2 files changed, 42 insertions(+)
 create mode 100644 
meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-list-fields-fix-to-print-the-fields-again.patch

diff --git 
a/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-list-fields-fix-to-print-the-fields-again.patch
 
b/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-list-fields-fix-to-print-the-fields-again.patch
new file mode 100644
index 00..deaf561d1e
--- /dev/null
+++ 
b/meta/recipes-devtools/opkg-utils/opkg-utils/0001-opkg-list-fields-fix-to-print-the-fields-again.patch
@@ -0,0 +1,41 @@
+From df675c91f4b33490f0fa831b11162bdb0e2ff550 Mon Sep 17 00:00:00 2001
+From: Martin Jansa 
+Date: Thu, 23 May 2019 20:50:45 +
+Subject: [PATCH] opkg-list-fields: fix to print the fields again
+
+* printing opkg.Package directly doesn't return anything useful now
+  
+
+* we need to call Package.print() function and specify which checksums
+  to print, we can include both md5 and sha256 for opkg-list-fields
+
+* it was changed in this commit:
+  commit 601d691dd80ef494aef069017edc5bf80aa883a1
+  Author: Alejandro del Castillo 
+  Date:   Wed Dec 19 11:40:15 2018 -0600
+
+opkg-make-index: add sha256sum support
+
+  which replaced the modified __str__ function with print(self, checksum)
+
+Upstream-Status: Backport 
[http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/commit/?id=5163a74a59d54b2a8374414435ece9d542dbd5e2]
+
+Signed-off-by: Martin Jansa 
+---
+ opkg-list-fields | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/opkg-list-fields b/opkg-list-fields
+index c14a90f..8a5a588 100755
+--- a/opkg-list-fields
 b/opkg-list-fields
+@@ -11,5 +11,4 @@ def usage():
+ if (len(sys.argv) < 2):
+  usage()
+ 
+-print(opkg.Package(sys.argv[1]))
+-
++print(opkg.Package(sys.argv[1]).print(('md5','sha256')))
+-- 
+2.17.1
+
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.0.bb 
b/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.0.bb
index 9a3e06b92e..b2fb760267 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.0.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.0.bb
@@ -10,6 +10,7 @@ PROVIDES += "${@bb.utils.contains('PACKAGECONFIG', 
'update-alternatives', 'virtu
 SRC_URI = 
"http://git.yoctoproject.org/cgit/cgit.cgi/${BPN}/snapshot/${BPN}-${PV}.tar.gz \
file://0001-Switch-all-scripts-to-use-Python-3.x.patch \
file://0001-opkg-build-do-not-set-mtime-on-data.tar.X.patch \
+file://0001-opkg-list-fields-fix-to-print-the-fields-again.patch \
 "
 UPSTREAM_CHECK_URI = 
"http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/refs/;
 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the sstate hash

2019-05-27 Thread Martin Jansa
Hi Michael,

sorry I wasn't clear in the reply, I meant that it's easy to work around
this issue, but it's error prone.

Your patch does it automatically and I don't see any cases where we
wouldn't want all the SRCREVs included in do_fetch signature, so I like
your patch.

+1 from me.

Cheers,

On Mon, May 27, 2019 at 6:34 PM  wrote:

> Hi Martin,
>
>
>
> It seems a little tricky though to need to know about the sstate hashing
> in order to use named
> source revisions and it could be a bit confusing that using a normal
> SRCREV doesn’t require any
> extra effort but named SRCREVs require additional lines of metadata. As
> you can see in the
> commit message of my patches, the vulkan-demos recipe in poky also has
> this issue so it might
> be quite easy to forget.
>
>
>
> Thanks for the feedback. If the patch idea isn’t good, let me know if you
> think I should instead
> post a patch for the documentation to try to more explicitly note the need
> for the additional vardeps
> statements when using named SRCREVs.
>
>
>
> Thanks.
>
>
>
> Kind regards,
>
> Michael
>
>
>
> --
>
> *BMW Car IT GmbH*
> Michael Ho
> Spezialist Entwicklung – Build and Release Engineering
> Lise-Meitner-Straße 14
> 89081 Ulm
>
> Tel.: ­+49-731-37804-071
>
> Mobil: +49-152-54980-471
> Fax: +49-731-37804-001
> Mail: michael...@bmw-carit.de
> Web: http://www.bmw-carit.de
> -
> BMW Car IT GmbH
> Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
> Sitz und Registergericht: München HRB 134810
> -
>
>
>
>
>
> *From: *Martin Jansa 
> *Date: *Monday, 27 May 2019 at 5:44 pm
> *To: *"Ho Michael, JC-3UL" 
> *Cc: *Chris Larson , Patches and discussions about the
> oe-core layer 
> *Subject: *Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the
> sstate hash
>
>
>
> In those recipes which don't include SRCPV in PV (for whatever reason) we
> usually add them explicitly with:
>
> do_fetch[vardeps] += "SRCREV_common"
>
> it's not ideal as people sometimes forget about this. Good practice is to
> add this next to the SRCREV_FORMAT (if you set one, to clearly show which
> revs are and aren't included).
>
>
>
> On Mon, May 27, 2019 at 5:37 PM  wrote:
>
> Hi Christopher,
>
>
>
> Thank you for the feedback. Since SRCPV is not always enforced (correct me
> if I’m wrong), it seems easy to trip over this bug when just following the
> documentation on multiple named source uri’s (also if you purposely don’t
> want to include the secondary source revisions in the package version).
> I’ll give it another shot to make it more efficient. If it’s not expected
> to be an encounterable bug case you can ignore the patch.
>
>
>
> Thanks.
>
>
>
> Kind regards,
>
> Michael
>
>
>
> --
>
> *BMW Car IT GmbH*
> Michael Ho
> Spezialist Entwicklung – Build and Release Engineering
> Lise-Meitner-Straße 14
> 89081 Ulm
>
> Tel.: ­+49-731-37804-071
>
> Mobil: +49-152-54980-471
> Fax: +49-731-37804-001
> Mail: michael...@bmw-carit.de
> Web: http://www.bmw-carit.de
> -
> BMW Car IT GmbH
> Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
> Sitz und Registergericht: München HRB 134810
> -
>
>
>
>
>
> *From: *Christopher Larson 
> *Date: *Wednesday, 8 May 2019 at 5:17 pm
> *To: *"Ho Michael, JC-3UL" 
> *Cc: *Patches and discussions about the oe-core layer <
> openembedded-core@lists.openembedded.org>
> *Subject: *Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the
> sstate hash
>
>
>
> Does SRCPV not already cover this in the majority of cases? SRCREV_FORMAT
> controls how the multiple revs end up in PV, and the change to PV results
> in rebuilding anyway. And iterating over d.keys() is inefficient, *if*
> you’re going to do this, operate on SRCREV, gather up the name= parameters
> from scm urls, and use that to drive it.
>
>
>
> On Wed, May 8, 2019 at 7:10 AM Michael Ho  wrote:
>
> Several fetchers support named sources that require setting a SRCREV with
> the source name as a suffix. These named SRCREV variables are not captured
> in the sstate hash calculation because they're only referenced within the
> bitbake fetcher function.
>
> Add a snippet to the base.bbclass anonymous python to add all named SRCREV
> variables to the vardeps of do_fetch to capture them in the 

Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the sstate hash

2019-05-27 Thread Martin Jansa
In those recipes which don't include SRCPV in PV (for whatever reason) we
usually add them explicitly with:
do_fetch[vardeps] += "SRCREV_common"
it's not ideal as people sometimes forget about this. Good practice is to
add this next to the SRCREV_FORMAT (if you set one, to clearly show which
revs are and aren't included).

On Mon, May 27, 2019 at 5:37 PM  wrote:

> Hi Christopher,
>
>
>
> Thank you for the feedback. Since SRCPV is not always enforced (correct me
> if I’m wrong), it seems easy to trip over this bug when just following the
> documentation on multiple named source uri’s (also if you purposely don’t
> want to include the secondary source revisions in the package version).
> I’ll give it another shot to make it more efficient. If it’s not expected
> to be an encounterable bug case you can ignore the patch.
>
>
>
> Thanks.
>
>
>
> Kind regards,
>
> Michael
>
>
>
> --
>
> *BMW Car IT GmbH*
> Michael Ho
> Spezialist Entwicklung – Build and Release Engineering
> Lise-Meitner-Straße 14
> 89081 Ulm
>
> Tel.: ­+49-731-37804-071
>
> Mobil: +49-152-54980-471
> Fax: +49-731-37804-001
> Mail: michael...@bmw-carit.de
> Web: http://www.bmw-carit.de
> -
> BMW Car IT GmbH
> Geschäftsführer: Kai-Uwe Balszuweit und Christian Salzmann
> Sitz und Registergericht: München HRB 134810
> -
>
>
>
>
>
> *From: *Christopher Larson 
> *Date: *Wednesday, 8 May 2019 at 5:17 pm
> *To: *"Ho Michael, JC-3UL" 
> *Cc: *Patches and discussions about the oe-core layer <
> openembedded-core@lists.openembedded.org>
> *Subject: *Re: [OE-core] [PATCH] base.bbclass: add named SRCREVs to the
> sstate hash
>
>
>
> Does SRCPV not already cover this in the majority of cases? SRCREV_FORMAT
> controls how the multiple revs end up in PV, and the change to PV results
> in rebuilding anyway. And iterating over d.keys() is inefficient, *if*
> you’re going to do this, operate on SRCREV, gather up the name= parameters
> from scm urls, and use that to drive it.
>
>
>
> On Wed, May 8, 2019 at 7:10 AM Michael Ho  wrote:
>
> Several fetchers support named sources that require setting a SRCREV with
> the source name as a suffix. These named SRCREV variables are not captured
> in the sstate hash calculation because they're only referenced within the
> bitbake fetcher function.
>
> Add a snippet to the base.bbclass anonymous python to add all named SRCREV
> variables to the vardeps of do_fetch to capture them in the sstate hash
> calculation.
>
> Testing of the bug can be shown by running the following bitbake commands
> with this patch set not applied:
>
> bitbake vulkan-demos | tee
> sed -i 's/SRCREV_gli = ".*"/SRCREV_gli = "xxx"/' \
>   ../meta/recipes-graphics/vulkan/vulkan-demos_git.bb
> bitbake vulkan-demos | tee;
>
> Results in no errors despite a broken SRCREV because the vulkan-demos is
> considered unchanged.
>
> After applying this patch the above commands instead result in a fetcher
> error which is correct.
> ---
>  meta/classes/base.bbclass | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index 1636c6e..84a27f5 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -638,6 +638,16 @@ python () {
>
>  if needsrcrev:
>  d.setVar("SRCPV", "${@bb.fetch2.get_srcrev(d)}")
> +# Gather all SRCREV_* references to add to the sstate hash
> calculation
> +# This may capture SRCREVs not used but it's difficult to try to
> restrict it
> +# to only what is needed
> +for dkey in d.keys():
> +if dkey.startswith("SRCREV_"):
> +# This anonymous python snippet is called multiple times
> so we
> +# need to be careful to not double up the appends here
> and cause
> +# the base hash to mismatch the task hash
> +if dkey not in (d.getVarFlag("do_fetch", "vardeps") or
> '').split():
> +d.appendVarFlag("do_fetch", "vardeps", "
> {}".format(dkey))
>
>  set_packagetriplet(d)
>
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
>
> --
>
> Christopher Larson
> kergoth at gmail dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Senior Software Engineer, Mentor Graphics
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 1/1] systemd: avoid musl specific patches affect glibc systems

2019-05-24 Thread Martin Jansa
It's still nicer to have
SRC_URI_append_libc-musl = " ${SRC_URI_MUSL}"
if the intermediate SRC_URI_MUSL variable is useful.

On Fri, May 24, 2019 at 7:59 PM Khem Raj  wrote:

> On Fri, May 24, 2019 at 10:31 AM Richard Purdie
>  wrote:
> >
> > On Fri, 2019-05-24 at 10:17 +0800, Chen Qi wrote:
> > > systemd upstream only care about glibc. We made musl specific
> > > patches so that systemd could work. But currently these patches
> > > contain potential security issues.
> > >
> > > So apply these patches only when the libc is musl.
> > >
> > > Signed-off-by: Chen Qi 
> > > ---
> > >  meta/recipes-core/systemd/systemd_242.bb | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-core/systemd/systemd_242.bb b/meta/recipes-
> > > core/systemd/systemd_242.bb
> > > index 2dda0d0..adb592f 100644
> > > --- a/meta/recipes-core/systemd/systemd_242.bb
> > > +++ b/meta/recipes-core/systemd/systemd_242.bb
> > > @@ -27,7 +27,7 @@ SRC_URI += "file://touchscreen.rules \
> > > "
> > >
> > >  # patches needed by musl
> > > -SRC_URI += "${SRC_URI_MUSL}"
> > > +SRC_URI += "${@d.getVar('SRC_URI_MUSL') if d.getVar('TCLIBC') ==
> > > 'musl' else ''}"
> > >  SRC_URI_MUSL = "file://0001-Use-getenv-when-secure-versions-are-not-
> > > available.patch \
> > > file://0002-don-t-use-glibc-specific-qsort_r.patch \
> > > file://0003-missing_type.h-add-__compare_fn_t-and-
> > > comparison_fn_.patch \
> >
> > Doesn't the usual SRC_URI_append_libc-musl = "X" work?
> >
>
> yes this should be better, SRC_URI_MUSL was introduced so someone
> could override it
> but if we make it optional then using override is better I think
>
> > Cheers,
> >
> > Richard
> >
> > --
> > ___
> > 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
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] autotools, cmake, meson, waf: define PACKAGECONFIG_CONFARGS before appending it

2019-05-23 Thread Martin Jansa
* just to make sure it's expaned by bitbake before it gets executed in shell
* e.g. with cmake.bbclass and cmake recipe (any recipe without
  PACKAGECONFIG options have this issue) it looks like this:
  bitbake -e cmake | grep EXTRA_OECMAKE=
  EXTRA_OECMAKE=" -DCMAKE_DOC_DIR=share/doc/cmake-3.14
-DCMAKE_USE_SYSTEM_LIBRARIES=1 -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0
-DCMAKE_USE_SYSTEM_LIBRARY_LIBUV=0
-DCMAKE_USE_SYSTEM_LIBRARY_LIBRHASH=0 -DKWSYS_CHAR_IS_SIGNED=1
-DBUILD_CursesDialog=0 -DKWSYS_LFS_WORKS=1
\${PACKAGECONFIG_CONFARGS}"

* there are some other places where PACKAGECONFIG_CONFARGS is used, but
  looks like all of them started to use it only after adding
  PACKAGECONFIG options in the recipe

Signed-off-by: Martin Jansa 
---
 meta/classes/autotools.bbclass | 1 +
 meta/classes/cmake.bbclass | 1 +
 meta/classes/meson.bbclass | 1 +
 meta/classes/waf.bbclass   | 1 +
 4 files changed, 4 insertions(+)

diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
index 8768a6ad68..32961320a5 100644
--- a/meta/classes/autotools.bbclass
+++ b/meta/classes/autotools.bbclass
@@ -129,6 +129,7 @@ autotools_postconfigure(){
 
 EXTRACONFFUNCS ??= ""
 
+PACKAGECONFIG_CONFARGS ??= ""
 EXTRA_OECONF_append = " ${PACKAGECONFIG_CONFARGS}"
 
 do_configure[prefuncs] += "autotools_preconfigure autotools_aclocals 
${EXTRACONFFUNCS}"
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index d3f0d70847..b5deb7da70 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -56,6 +56,7 @@ OECMAKE_EXTRA_ROOT_PATH ?= ""
 OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "ONLY"
 OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM_class-native = "BOTH"
 
+PACKAGECONFIG_CONFARGS ??= ""
 EXTRA_OECMAKE_append = " ${PACKAGECONFIG_CONFARGS}"
 
 EXTRA_OECMAKE_BUILD_prepend_task-compile = "${PARALLEL_MAKE} "
diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 115d1aedcb..4f03a51e09 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -35,6 +35,7 @@ MESON_C_ARGS = "${MESON_TOOLCHAIN_ARGS} ${CFLAGS}"
 MESON_CPP_ARGS = "${MESON_TOOLCHAIN_ARGS} ${CXXFLAGS}"
 MESON_LINK_ARGS = "${MESON_TOOLCHAIN_ARGS} ${LDFLAGS}"
 
+PACKAGECONFIG_CONFARGS ??= ""
 EXTRA_OEMESON_append = " ${PACKAGECONFIG_CONFARGS}"
 
 MESON_CROSS_FILE = ""
diff --git a/meta/classes/waf.bbclass b/meta/classes/waf.bbclass
index 900244004e..f7178b28e9 100644
--- a/meta/classes/waf.bbclass
+++ b/meta/classes/waf.bbclass
@@ -3,6 +3,7 @@ DISABLE_STATIC = ""
 
 B = "${WORKDIR}/build"
 
+PACKAGECONFIG_CONFARGS ??= ""
 EXTRA_OECONF_append = " ${PACKAGECONFIG_CONFARGS}"
 
 def waflock_hash(d):
-- 
2.17.1

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


[OE-core] [PATCH] bc: use u-a for bc as well

2019-05-22 Thread Martin Jansa
* bc can be provided by busybox as well (e.g. if you have your own
  defconfig and forget to explicitly disable it:
  ...
  *
  * Miscellaneous Utilities
  *
  adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
  bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
  bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y] (NEW) y
  Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW) Enable 
bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4 kb) (BEEP) 
[N/y/?] n
  chat (6.3 kb) (CHAT) [N/y/?] n
  conspy (10 kb) (CONSPY) [N/y/?] n
  ...
  ), causing conflict in u-a:

  update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid 
since /usr/bin/bc exists and is not a link

  and then whole do_rootfs or do_populate_sdk to fail because busybox postinst 
is failing:

  do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed. If the 
intention is to defer them to first boot,
  then please place them into pkg_postinst_ontarget_${PN} (). Deferring to 
first boot via 'exit 1' is no longer supported.

Signed-off-by: Martin Jansa 
---
 meta/recipes-extended/bc/bc_1.07.1.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/bc/bc_1.07.1.bb 
b/meta/recipes-extended/bc/bc_1.07.1.bb
index e80857745e..809b864c1a 100644
--- a/meta/recipes-extended/bc/bc_1.07.1.bb
+++ b/meta/recipes-extended/bc/bc_1.07.1.bb
@@ -27,7 +27,7 @@ do_compile_prepend() {
 cp -f ${WORKDIR}/libmath.h ${B}/bc/libmath.h
 }
 
-ALTERNATIVE_${PN} = "dc"
+ALTERNATIVE_${PN} = "bc dc"
 ALTERNATIVE_PRIORITY = "100"
 
-BBCLASSEXTEND = "native"
\ No newline at end of file
+BBCLASSEXTEND = "native"
-- 
2.17.1

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


Re: [OE-core] [PATCH 1/1] util-linux: Add missing ptest dependencies

2019-05-22 Thread Martin Jansa
On Wed, May 22, 2019 at 10:09:16PM +0200, Martin Jansa wrote:
> On Wed, May 22, 2019 at 05:18:25PM +0300, Adrian Bunk wrote:
> > On Wed, May 22, 2019 at 01:03:37PM +0200, Martin Jansa wrote:
> > > This pulls bc to many images with busybox, causing busybox postinst to 
> > > fail
> > > with:
> > > 
> > > update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid
> > > since /usr/bin/bc exists and is not a link
> > 
> > Are you enabling CONFIG_BC in your busybox config?
> > It is not enabled in meta/recipes-core/busybox/busybox/defconfig
> 
> It's not disabled in my defconfig like it is in
> meta/recipes-core/busybox/busybox/defconfig, maybe it got auto enabled.
> 
> In log.do_configure I see:
> ...
> *
> * Miscellaneous Utilities
> *
> adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
> bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
> bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
>   Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y] (NEW) y
> Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW) Enable 
> bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4 kb) (BEEP) 
> [N/y/?] n
> chat (6.3 kb) (CHAT) [N/y/?] n
> conspy (10 kb) (CONSPY) [N/y/?] n
> ...
> 
> > > I'll check which busybox defconfig entry enables BC and send patch to use
> > > u-a for bc in ./meta/recipes-extended/bc/bc_1.07.1.bb
> > > 
> > > There already is:
> > > ALTERNATIVE_${PN} = "dc"
> > > ALTERNATIVE_PRIORITY = "100"
> > > but maybe dc is a typo.
> > 
> > bc and dc are two different binaries built from bc.
> > 
> > busybox used to only have dc, bc was added 6 months ago.
> 
> Thanks I've never noticed dc before.
> 
> I see both dc and bc in 1.06 version from meta-gplv2 which was released
> on 2000-11-15
> 
> bc/1.06-r3/image/usr/bin/bc

Ah you were talking about busybox having only dc until 6 months ago.

Makes sense now, thanks.

> As there is already u-a for dc, I will sent u-a for bc as well.
> -- 
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] [PATCH 1/1] util-linux: Add missing ptest dependencies

2019-05-22 Thread Martin Jansa
On Wed, May 22, 2019 at 05:18:25PM +0300, Adrian Bunk wrote:
> On Wed, May 22, 2019 at 01:03:37PM +0200, Martin Jansa wrote:
> > This pulls bc to many images with busybox, causing busybox postinst to fail
> > with:
> > 
> > update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid
> > since /usr/bin/bc exists and is not a link
> 
> Are you enabling CONFIG_BC in your busybox config?
> It is not enabled in meta/recipes-core/busybox/busybox/defconfig

It's not disabled in my defconfig like it is in
meta/recipes-core/busybox/busybox/defconfig, maybe it got auto enabled.

In log.do_configure I see:
...
*
* Miscellaneous Utilities
*
adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
  Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y] (NEW) y
Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW) Enable 
bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4 kb) (BEEP) 
[N/y/?] n
chat (6.3 kb) (CHAT) [N/y/?] n
conspy (10 kb) (CONSPY) [N/y/?] n
...

> > I'll check which busybox defconfig entry enables BC and send patch to use
> > u-a for bc in ./meta/recipes-extended/bc/bc_1.07.1.bb
> > 
> > There already is:
> > ALTERNATIVE_${PN} = "dc"
> > ALTERNATIVE_PRIORITY = "100"
> > but maybe dc is a typo.
> 
> bc and dc are two different binaries built from bc.
> 
> busybox used to only have dc, bc was added 6 months ago.

Thanks I've never noticed dc before.

I see both dc and bc in 1.06 version from meta-gplv2 which was released
on 2000-11-15

bc/1.06-r3/image/usr/bin/bc

As there is already u-a for dc, I will sent u-a for bc as well.
-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] [PATCH v2] insane: add sanity checks to SRC_URI

2019-05-22 Thread Martin Jansa
Can we add an option to skip this with INSANE_SKIP?

It looks like QARECIPETEST doesn't use INSANE_SKIP or I don't see how.

Removing src-uri-bad from ERROR_QA/WARN_QA for some recipes works as well,
is it worth adding INSANE_SKIP for consistency with other checks or not?


On Sat, May 18, 2019 at 1:37 AM Ross Burton  wrote:

> The SRC_URI almost definitely shouldn't be using ${PN}, and GitHub
> */archive/*
> tarballs are dynamically generated so the checksums will change over time.
>
> Detect both of these, and emit a QA warning if found.
>
> Signed-off-by: Ross Burton 
> ---
>  meta/classes/insane.bbclass | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 9ca5aefe544..59bb8be5470 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -25,7 +25,7 @@ QA_SANE = "True"
>  WARN_QA ?= "ldflags useless-rpaths rpaths staticdev libdir
> xorg-driver-abi \
>  textrel already-stripped incompatible-license files-invalid \
>  installed-vs-shipped compile-host-path install-host-path \
> -pn-overrides infodir build-deps \
> +pn-overrides infodir build-deps src-uri-bad \
>  unknown-configure-option symlink-to-sysroot multilib \
>  invalid-packageconfig host-user-contaminated uppercase-pn
> patch-fuzz \
>  "
> @@ -898,6 +898,17 @@ def package_qa_check_host_user(path, name, d, elf,
> messages):
>  return False
>  return True
>
> +QARECIPETEST[src-uri-bad] = "package_qa_check_src_uri"
> +def package_qa_check_src_uri(pn, d, messages):
> +import re
> +
> +if "${PN}" in d.getVar("SRC_URI", False):
> +package_qa_handle_error("src-uri-bad", "%s: SRC_URI uses PN not
> BPN" % pn, d)
> +
> +pn = d.getVar("SRC_URI")
> +if re.search(r"github\.com/.+/.+/archive/.+", pn):
> +package_qa_handle_error("src-uri-bad", "%s: SRC_URI uses unstable
> GitHub archives" % pn, d)
> +
>
>  # The PACKAGE FUNC to scan each package
>  python do_package_qa () {
> --
> 2.20.1 (Apple Git-117)
>
> --
> ___
> 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 1/1] util-linux: Add missing ptest dependencies

2019-05-22 Thread Martin Jansa
This pulls bc to many images with busybox, causing busybox postinst to fail
with:

update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid
since /usr/bin/bc exists and is not a link

I'll check which busybox defconfig entry enables BC and send patch to use
u-a for bc in ./meta/recipes-extended/bc/bc_1.07.1.bb

There already is:
ALTERNATIVE_${PN} = "dc"
ALTERNATIVE_PRIORITY = "100"
but maybe dc is a typo.

On Sun, May 19, 2019 at 11:21 PM Mariano López <
just.another.mari...@gmail.com> wrote:

> There are some missing dependencies for the util-linux-ptest package
> that causes inconsistencies in the package tests run in different images.
>
> The kernel module in RRECOMMENDS is not build at this time, it needs
> more testing and check if the configuration change can be part of the
> yocto-kernel-cache repository.
>
> Signed-off-by: Mariano López 
> ---
>  meta/recipes-core/util-linux/util-linux.inc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/util-linux/util-linux.inc
> b/meta/recipes-core/util-linux/util-linux.inc
> index 34255a2dec..6dfbe0b683 100644
> --- a/meta/recipes-core/util-linux/util-linux.inc
> +++ b/meta/recipes-core/util-linux/util-linux.inc
> @@ -142,7 +142,8 @@ RDEPENDS_${PN}_class-nativesdk = ""
>  RPROVIDES_${PN}-dev = "${PN}-libblkid-dev ${PN}-libmount-dev
> ${PN}-libuuid-dev"
>
>  RDEPENDS_${PN}-bash-completion += "${PN}-lsblk"
> -RDEPENDS_${PN}-ptest = "bash grep coreutils which btrfs-tools ${PN} sed"
> +RDEPENDS_${PN}-ptest = "bash bc btrfs-tools coreutils e2fsprogs grep
> iproute2 kmod mdadm ${PN} procps sed socat which xz"
> +RRECOMMENDS_${PN}-ptest = "kernel-module-scsi-debug"
>  RDEPENDS_${PN}-swaponoff = "${PN}-swapon ${PN}-swapoff"
>  ALLOW_EMPTY_${PN}-swaponoff = "1"
>
> --
> 2.21.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


[OE-core] [warrior][PATCH] Revert "acpica: use update-alternatives for acpidump"

2019-05-21 Thread Martin Jansa
This reverts commit c3a325b5c2d9315629d014e5ebba552fe045171c.

This seems to be causing:
WARNING: acpica-20180508-r0 do_package: acpica: alternative target 
(/usr/bin/acpidump or /usr/bin/acpidump.acpica) does not exist, skipping...
WARNING: acpica-20180508-r0 do_package: acpica: NOT adding alternative provide 
/usr/bin/acpidump: /usr/bin/acpidump.acpica does not exist
WARNING: acpica-20180508-r0 do_package: acpica: alt_link == alt_target: 
/usr/bin/acpidump == /usr/bin/acpidump

because the 20180508 version in warrior unlike the 20190405 in master doesn't 
install acpidump binary.

Signed-off-by: Martin Jansa 
---
 meta/recipes-extended/acpica/acpica_20180508.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/acpica/acpica_20180508.bb 
b/meta/recipes-extended/acpica/acpica_20180508.bb
index cd5f466262..b5c89fafc5 100644
--- a/meta/recipes-extended/acpica/acpica_20180508.bb
+++ b/meta/recipes-extended/acpica/acpica_20180508.bb
@@ -29,7 +29,7 @@ S = "${WORKDIR}/acpica-unix2-${PV}"
 inherit update-alternatives
 
 ALTERNATIVE_PRIORITY = "100"
-ALTERNATIVE_${PN} = "acpixtract acpidump"
+ALTERNATIVE_${PN} = "acpixtract"
 
 EXTRA_OEMAKE = "CC='${CC}' 'OPT_CFLAGS=-Wall'"
 
-- 
2.17.1

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


Re: [OE-core] [oe-commits] [openembedded-core] 19/24: acpica: use update-alternatives for acpidump

2019-05-21 Thread Martin Jansa
This seems to be causing:
WARNING: acpica-20180508-r0 do_package: acpica: alternative target
(/usr/bin/acpidump or /usr/bin/acpidump.acpica) does not exist, skipping...
WARNING: acpica-20180508-r0 do_package: acpica: NOT adding alternative
provide /usr/bin/acpidump: /usr/bin/acpidump.acpica does not exist
WARNING: acpica-20180508-r0 do_package: acpica: alt_link == alt_target:
/usr/bin/acpidump == /usr/bin/acpidump

because the 20180508 version in warrior unlike the 20190405 in master
doesn't install acpidump binary.

Please revert from warrior.

On Mon, May 20, 2019 at 3:39 PM  wrote:

> This is an automated email from the git hooks/post-receive script.
>
> rpurdie pushed a commit to branch warrior
> in repository openembedded-core.
>
> commit c3a325b5c2d9315629d014e5ebba552fe045171c
> Author: Hongxu Jia 
> AuthorDate: Mon May 6 10:37:27 2019 +0800
>
> acpica: use update-alternatives for acpidump
>
> acpidump is both provided by acpica and pmtools, so use
> update-alternatives to fix conflicts:
> ...
> |Error: Transaction check error:
> |  file /usr/bin/acpidump conflicts between attempted installs of
> pmtools-20130209+git0+3ebe0e54c5-r0.i586 and acpica-20190405-r0.i586
> ...
>
> Signed-off-by: Hongxu Jia 
> Signed-off-by: Richard Purdie 
> Signed-off-by: Armin Kuster 
> ---
>  meta/recipes-extended/acpica/acpica_20180508.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-extended/acpica/acpica_20180508.bb
> b/meta/recipes-extended/acpica/acpica_20180508.bb
> index b5c89fa..cd5f466 100644
> --- a/meta/recipes-extended/acpica/acpica_20180508.bb
> +++ b/meta/recipes-extended/acpica/acpica_20180508.bb
> @@ -29,7 +29,7 @@ S = "${WORKDIR}/acpica-unix2-${PV}"
>  inherit update-alternatives
>
>  ALTERNATIVE_PRIORITY = "100"
> -ALTERNATIVE_${PN} = "acpixtract"
> +ALTERNATIVE_${PN} = "acpixtract acpidump"
>
>  EXTRA_OEMAKE = "CC='${CC}' 'OPT_CFLAGS=-Wall'"
>
>
> --
> To stop receiving notification emails like this one, please contact
> the administrator of this repository.
> --
> ___
> Openembedded-commits mailing list
> openembedded-comm...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-commits
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] kexec-tools: refresh patches with devtool

2019-05-21 Thread Martin Jansa
On Sat, May 11, 2019 at 04:16:56PM +, Martin Jansa wrote:
> * to make it easier to rebase

ping?

I know this change alone doesn't look very useful (but it was useful
for me when rebasing other patches in other layers).


> Signed-off-by: Martin Jansa 
> ---
>  ...owerpc-change-the-memory-size-limit.patch} | 12 ++---
>  ...purgatory-Pass-r-directly-to-linker.patch} | 13 ++---
>  ...ix-add_buffer_phys_virt-align-issue.patch} |  7 +--
>  ...t-to-build-kexec-tools-with-x32-ABI.patch} | 47 ++-
>  ...tch => 0005-Disable-PIE-during-link.patch} |  7 +--
>  .../kexec/kexec-tools_2.0.19.bb   | 18 +++
>  6 files changed, 50 insertions(+), 54 deletions(-)
>  rename 
> meta/recipes-kernel/kexec/kexec-tools/{0002-powerpc-change-the-memory-size-limit.patch
>  => 0001-powerpc-change-the-memory-size-limit.patch} (75%)
>  rename 
> meta/recipes-kernel/kexec/kexec-tools/{0001-purgatory-Pass-r-directly-to-linker.patch
>  => 0002-purgatory-Pass-r-directly-to-linker.patch} (83%)
>  rename 
> meta/recipes-kernel/kexec/kexec-tools/{0010-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch
>  => 0003-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch} (94%)
>  rename meta/recipes-kernel/kexec/kexec-tools/{kexec-x32.patch => 
> 0004-x86_64-Add-support-to-build-kexec-tools-with-x32-ABI.patch} (59%)
>  rename 
> meta/recipes-kernel/kexec/kexec-tools/{0001-Disable-PIE-during-link.patch => 
> 0005-Disable-PIE-during-link.patch} (88%)
> 
> diff --git 
> a/meta/recipes-kernel/kexec/kexec-tools/0002-powerpc-change-the-memory-size-limit.patch
>  
> b/meta/recipes-kernel/kexec/kexec-tools/0001-powerpc-change-the-memory-size-limit.patch
> similarity index 75%
> rename from 
> meta/recipes-kernel/kexec/kexec-tools/0002-powerpc-change-the-memory-size-limit.patch
> rename to 
> meta/recipes-kernel/kexec/kexec-tools/0001-powerpc-change-the-memory-size-limit.patch
> index dc97d930e9..029650f35c 100644
> --- 
> a/meta/recipes-kernel/kexec/kexec-tools/0002-powerpc-change-the-memory-size-limit.patch
> +++ 
> b/meta/recipes-kernel/kexec/kexec-tools/0001-powerpc-change-the-memory-size-limit.patch
> @@ -1,4 +1,4 @@
> -From b19b68eab567aa534cf8dec79fe18e3dc0e14043 Mon Sep 17 00:00:00 2001
> +From 211cae4b6a02a4d9d37bfcd76f3702696e095fc3 Mon Sep 17 00:00:00 2001
>  From: Quanyang Wang 
>  Date: Tue, 16 Jun 2015 12:59:57 +0800
>  Subject: [PATCH] powerpc: change the memory size limit
> @@ -20,11 +20,11 @@ Signed-off-by: Quanyang Wang 
>   kexec/arch/ppc/kexec-ppc.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>  
> -Index: kexec-tools-2.0.10/kexec/arch/ppc/kexec-ppc.h
> -===
>  kexec-tools-2.0.10.orig/kexec/arch/ppc/kexec-ppc.h
> -+++ kexec-tools-2.0.10/kexec/arch/ppc/kexec-ppc.h
> -@@ -42,7 +42,7 @@ void dol_ppc_usage(void);
> +diff --git a/kexec/arch/ppc/kexec-ppc.h b/kexec/arch/ppc/kexec-ppc.h
> +index 04e728e..6bae9ec 100644
> +--- a/kexec/arch/ppc/kexec-ppc.h
>  b/kexec/arch/ppc/kexec-ppc.h
> +@@ -44,7 +44,7 @@ void dol_ppc_usage(void);
>* During inital setup the kernel does not map the whole memory but a part 
> of
>* it. On Book-E that is 64MiB, 601 24MiB or 256MiB (if possible).
>*/
> diff --git 
> a/meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-Pass-r-directly-to-linker.patch
>  
> b/meta/recipes-kernel/kexec/kexec-tools/0002-purgatory-Pass-r-directly-to-linker.patch
> similarity index 83%
> rename from 
> meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-Pass-r-directly-to-linker.patch
> rename to 
> meta/recipes-kernel/kexec/kexec-tools/0002-purgatory-Pass-r-directly-to-linker.patch
> index bfd077daf0..363d5da4ae 100644
> --- 
> a/meta/recipes-kernel/kexec/kexec-tools/0001-purgatory-Pass-r-directly-to-linker.patch
> +++ 
> b/meta/recipes-kernel/kexec/kexec-tools/0002-purgatory-Pass-r-directly-to-linker.patch
> @@ -1,4 +1,4 @@
> -From a1135b3170963ba956f2364c1283864c35541295 Mon Sep 17 00:00:00 2001
> +From a04bcf8f683c1a5a7d015920124457ad56fb7cf0 Mon Sep 17 00:00:00 2001
>  From: Khem Raj 
>  Date: Mon, 7 Sep 2015 07:59:45 +
>  Subject: [PATCH] purgatory: Pass -r directly to linker
> @@ -8,17 +8,17 @@ where as gcc knows how to deal with it and passes it down 
> to linker
>  unfiltered
>  
>  Signed-off-by: Khem Raj 
> 
> -Upstream-Status: Pending
>  
> +Upstream-Status: Pending
> +---
>   purgatory/Makefile | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>  
>  diff --git a/purgatory/Makefile b/purgatory/Makefile
> -index 2b5c061..b251353 100644
> +index 2dd6c47..416e6b9 100644
>  --- a/purgatory/Makefile
>  +++ b/purgatory/Makefile
> -@@ -61,7 +61,7 @@ $(PURGAT

  1   2   3   4   5   6   7   8   9   10   >