Re: [yocto] [meta-qt5] How to contribute patches for qtwebengine in meta-qt5?

[Martin Jansa]

This patch is already included in 5.13.2 upgrade (ready in zeus-next and
master-next branches), so you don't need to do anything.

Otherwise like Khem says, submit the change for meta-qt5 repository like
any other layer.

The meta-qt5/qt* repositories are used to maintain the patches, but usually
only me is updating them to keep in sync with meta-qt5 and then syncing
from them to meta-qt5 with git format-patch --no-numbered --no-signature
when doing bigger rebase like when upgrading to newer Qt version.

Regards,

On Fri, Nov 1, 2019 at 11:02 AM Tanu Kaskinen  wrote:

> Hi all!
>
> The meta-qt5 readme says that contributions should be made by forking
> the meta-qt5 repository on GitHub, but when I look at the qtwebengine
> recipe, it looks like patches are pulled from
> https://github.com/meta-qt5/qtwebengine-chromium, and that repository
> looks like the patches are kept in a particular order so adding a patch
> at the top is perhaps not what I should do.
>
> It's not clear to me how I should submit a patch in this case. The
> patch in question would be a simple backport of this upstream commit:
>
> https://codereview.qt-project.org/gitweb?p=qt/qtwebengine-chromium.git;a=commitdiff;h=b84e8682b312fb16b16ffb9591415067ceae69f8
>
> It's needed for not breaking qtwebengine when upgrading PulseAudio to
> 13.0.
>
> --
> Tanu
>
> https://www.patreon.com/tanuk
> https://liberapay.com/tanuk
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] systemd Version Going Backwards on Warrior

[Martin Jansa]

PR server never knows which one is really newer (in git).

It just returns max(LOCALCOUNT)+1 when it gets query for hash which isn't
stored in the database yet.

Either the build in question didn't use PRserv at all or PRserv's cache was
deleted between builds or the builds were using the same buildhistory but
different PRserv's or the first systemd SRCREV was reused from sstate
created on another server which doesn't share the PRserv (so it didn't
build it locally to query local PRserv to store 511646b8ac as LOCALCOUNT).

e.g. I've just built systemd with 511646b8ac hash as:
systemd_241+0+511646b8ac-r0.0webos4_qemux86.ipk
but reusing it from sstate created on another jenkins server as shown by
buildstats-summary:

NOTE: Build completion summary:
NOTE:   do_populate_sysroot: 100.0% sstate reuse(124 setscene, 0 scratch)
NOTE:   do_package_qa: 100.0% sstate reuse(10 setscene, 0 scratch)
NOTE:   do_packagedata: 100.0% sstate reuse(51 setscene, 0 scratch)
NOTE:   do_package_write_ipk: 100.0% sstate reuse(10 setscene, 0 scratch)
NOTE:   do_populate_lic: 100.0% sstate reuse(17 setscene, 0 scratch)

Then I've reverted oe-core commit 8b9703454cb2a8a0aa6b7942498f191935d547ea
to go back to c1f8ff8d0de7e303b8004b02a0a47d4cc103a7f8 systemd revision.

This time it haven't found valid sstate archive for it:
NOTE: Build completion summary:
NOTE:   do_populate_sysroot: 0.0% sstate reuse(0 setscene, 16 scratch)
NOTE:   do_package_qa: 0.0% sstate reuse(0 setscene, 19 scratch)
NOTE:   do_package: 15.8% sstate reuse(3 setscene, 16 scratch)
NOTE:   do_packagedata: 0.0% sstate reuse(0 setscene, 16 scratch)
NOTE:   do_package_write_ipk: 0.0% sstate reuse(0 setscene, 19 scratch)
NOTE:   do_populate_lic: 100.0% sstate reuse(2 setscene, 0 scratch)

and resulting .ipk has also +0:
systemd_241+0+c1f8ff8d0d-r0.0webos4_qemux86.ipk
but no warning is shown, because in this case it went from 511 to c1f.

Removing the revert again, doesn't trigger the warning again, because it
will be again reused from sstate (and QA checks won't get executed):
NOTE: Build completion summary:
NOTE:   do_populate_sysroot: 100.0% sstate reuse(16 setscene, 0 scratch)
NOTE:   do_package_qa: 100.0% sstate reuse(19 setscene, 0 scratch)
NOTE:   do_packagedata: 100.0% sstate reuse(16 setscene, 0 scratch)
NOTE:   do_package_write_ipk: 100.0% sstate reuse(19 setscene, 0 scratch)
NOTE:   do_populate_lic: 100.0% sstate reuse(2 setscene, 0 scratch)

And the local PRserv database still has only the c1f8ff8d0d hash,
because 511646b8ac was never really queried against this local PRserv.

cache$ sqlite3 prserv.sqlite3 "select * from PRMAIN_nohist where version
like 'AUTOINC-systemd-1%'"
AUTOINC-systemd-1_241+|qemux86|AUTOINC+c1f8ff8d0d|0

Also systemd recipe is using strange format with:
PV_append = "+${SRCPV}"

most recipes use "+git${SRCPV}" or "+gitr${SRCPV} to make it more clear
where this +0+hash came from.

So long story short: the change is correct, PRserv should handle this, but
there are many cases where it will fail (e.g.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5399), but that's not a
reason to start PE bumps everywhere.

Cheers,

On Tue, Oct 29, 2019 at 12:57 PM akuster  wrote:

>
>
> On 10/29/19 11:50 AM, Ross Burton wrote:
> > On 29/10/2019 04:41, Robert Joslyn wrote:
> >> On Mon, 2019-10-28 at 19:06 +, Ross Burton wrote:
> >>> On 28/10/2019 16:25, robert.jos...@redrectangle.org wrote:
>  I'm using buildhistory in one of my builds that creates a package
>  feed, and a recent update to systemd on warrior triggered version-
>  going-backwards errors:
> 
>  ERROR: systemd-conf-241+AUTOINC+511646b8ac-r0 do_packagedata: QA
>  Issue: Package version for package systemd-conf-src went backwards
>  which would break package feeds from (0:241+0+c1f8ff8d0d-r0 to
>  0:241+0+511646b8ac-r0) [version-going-backwards]
>
> Isn't this do to the hashes being different and the PR server can't
> really tell which one is newer?
>
>
> 
>  Should PE have been updated at the same time due to the hash making
>  the version number go backwards? I can send a patch if that's all
>  that's missing. Or is a PR server enough to prevent this? My debug
>  builds do not use a PR server, but my production builds do use a PR
>  server.
> >>>
> >>> If you're using feeds, you need to use a PR server.  This is *exactly*
> >>> what they are for.
> > >
> >
> >> The part I wasn't sure about was if the PR server helped in the case
> >> where
> >> PV went backwards. I know it works when PV stays the same but the
> >> package
> >> was rebuilt. But if it keeps the versions going forward no matter how PV
> >> changes, then I should be good. I should probably setup a separate PR
> >> server on my debug builds to avoid this kind of error.
> >
> > If the PV actually goes backwards then the PR service isn't useful, as
> > PV sorts before PR.
> >
> > However in this case the problem is that SRCREV should have a
> > incrementing counter (the 

Re: [yocto] [meta-security][PATCH] layer.conf: Update for zeus series

[Martin Jansa]

Acked-by: Martin Jansa 

Please merge this to unblock CI.

On Wed, Oct 9, 2019 at 12:55 AM Armin Kuster  wrote:

> Signed-off-by: Armin Kuster 
> ---
>  conf/layer.conf  | 2 +-
>  meta-integrity/conf/layer.conf   | 2 +-
>  meta-security-compliance/conf/layer.conf | 2 +-
>  meta-tpm/conf/layer.conf | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/conf/layer.conf b/conf/layer.conf
> index b9a4f25..3e890e1 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -9,6 +9,6 @@ BBFILE_COLLECTIONS += "security"
>  BBFILE_PATTERN_security = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_security = "8"
>
> -LAYERSERIES_COMPAT_security = "warrior"
> +LAYERSERIES_COMPAT_security = "zeus"
>
>  LAYERDEPENDS_security = "core openembedded-layer perl-layer
> networking-layer meta-python"
> diff --git a/meta-integrity/conf/layer.conf
> b/meta-integrity/conf/layer.conf
> index 41989da..962424c 100644
> --- a/meta-integrity/conf/layer.conf
> +++ b/meta-integrity/conf/layer.conf
> @@ -21,6 +21,6 @@ INTEGRITY_BASE := '${LAYERDIR}'
>  # interactive shell is enough.
>  OE_TERMINAL_EXPORTS += "INTEGRITY_BASE"
>
> -LAYERSERIES_COMPAT_integrity = "warrior"
> +LAYERSERIES_COMPAT_integrity = "zeus"
>  # ima-evm-utils depends on keyutils from meta-oe
>  LAYERDEPENDS_integrity = "core openembedded-layer"
> diff --git a/meta-security-compliance/conf/layer.conf
> b/meta-security-compliance/conf/layer.conf
> index 9ccadab..0e93bd0 100644
> --- a/meta-security-compliance/conf/layer.conf
> +++ b/meta-security-compliance/conf/layer.conf
> @@ -8,6 +8,6 @@ BBFILE_COLLECTIONS += "scanners-layer"
>  BBFILE_PATTERN_scanners-layer = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_scanners-layer = "10"
>
> -LAYERSERIES_COMPAT_scanners-layer = "warrior"
> +LAYERSERIES_COMPAT_scanners-layer = "zeus"
>
>  LAYERDEPENDS_scanners-layer = "core openembedded-layer meta-python"
> diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
> index cdccc55..3af2d95 100644
> --- a/meta-tpm/conf/layer.conf
> +++ b/meta-tpm/conf/layer.conf
> @@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "tpm-layer"
>  BBFILE_PATTERN_tpm-layer = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_tpm-layer = "10"
>
> -LAYERSERIES_COMPAT_tpm-layer = "warrior"
> +LAYERSERIES_COMPAT_tpm-layer = "zeus"
>
>  LAYERDEPENDS_tpm-layer = " \
>  core \
> --
> 2.17.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_fetch_append: syntax error

[Martin Jansa]

On Tue, Oct 01, 2019 at 11:35:21AM +0300, Damien LEFEVRE wrote:
> Hi,
> 
> I have the following bbappend
> 
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI += " \
> file://tegra186_cti_defconfig \
> "
> 
> do_fetch_append(){
> mv ${WORKDIR}/tegra186_cti_defconfig ${WORKDIR}/defconfig
> }
> 
> For this I get an error:
>   File "autogenerated", line 3
> mv ${WORKDIR}/tegra186_cti_defconfig ${WORKDIR}/defconfig
>   ^
> SyntaxError: invalid syntax
> 
> Can someone explain why? I get the same in do_fetch_append. Starts working
> with do_configure_append but that's too late in case of rebuild.

do_fetch is python task, you cannot append shell code to it.

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Alternative to _git.bb convention for unstable versions?

[Martin Jansa]

You can easily add .inc file which will set all the PREFERRED_VERSIONs for
all components you need and then the users will just add an "require" of
this .inc files to their local.conf.

"somepackage-unstable.bb" or "somepackage-devel.bb" this will make it 2
different components - not 2 different versions of the same component -
which makes this much more complicated, you'll need PREFERRED_PROVIDERs for
every dependency and in the end you will need to make sure that whole build
is using the same set of providers, because if

A depends on somepackage-unstable
B depends on A and somepackage-devel

then building B will fail in prepare-recipe-sysrooot, because A will pull
somepackage-unstable which will probably conflict with somepackage-devel by
providing the same files (in just different version). You can see how
openssl10 and openssl "worked" if you build didn't use the same one for all
the recipes.

Cheers,

On Fri, Sep 13, 2019 at 5:27 PM keith.derrick  wrote:

> I am currently creating a new layer (which will eventually be made
> generally available). I need to provide both a versioned recipe, and an
> "unstable"  one.
>
>
> Currently I have somepackage_1.0.bb and somepackage_git.bb which are
> working fine.
>
>
> However, using the "_git" approach (with DEFAULT_PREFERENCE = "-1")
> requires the use of PREFERRED_VERSION in either local.conf or
> a distro.conf. I've tried putting it in the image files, and that doesn't
> work.
>
>
> If you are not creating your own DISTRO, and instead just adding the layer
> to a straight poky/meta build, you seem to be pretty much stuck with adding
> 3 PREFERRED_VERSION statements (target, -native, and nativesdk- variants)
> to local.conf. I'd rather not require that of users of the layer.
>
>
> I'm considering instead using either "somepackage-unstable.bb" or "
> somepackage-devel.bb" instead of "sompackage_git.bb". This allows a
> simple selection of either  RDEPENDS = "somepackage" or RDEPENDS =
> "somepackage-devel" to add the desired one to an image.
>
>
> However, neither "-devel" or "-unstable" have the right feel for the
> suffix. If, for example, you are picking up an older commit (between
> versions  say) it might well be completely stable.
>
>
> Does the community have a naming convention for this type of recipe?
> Failing that, is there somewhere else in the met-data the PREFERRED_VERSION
> statement can go other than a configuration file?
>
>
> Thanks
>
> Keith Derrick
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] package_qa fails on copy openssl

[Martin Jansa]

On Tue, Sep 10, 2019 at 08:49:35AM -0400, William Durocher wrote:
> Currently updating a sumo build to warrior. One of our recipe called config
> server uses nodejs which was updated from 8.9 in sumo to 10.5 in warrior.
> As an interim solution we decided to keep the version of nodejs to 8.90.
> However I am getting the following exception in the package_qa step:
> 
> "File:
> '/home/wdurocher/work/gammaip/warrior/sources/meta/meta/classes/staging.bbclass',
> lineno: 151, function: staging_copyfile
>  0147:os.symlink(linkto, dest)
>  0148:#bb.warn(c)
>  0149:else:
>  0150:try:
>  *** 0151:os.link(c, dest)
>  0152:except OSError as err:
>  0153:if err.errno == errno.EXDEV:
>  0154:bb.utils.copyfile(c, dest)
>  0155:else:
> Exception: FileExistsError: [Errno 17] File exists:
> '/home/wdurocher/work/gammaip/warrior/build/tmp/sysroots-components/x86_64/openssl-native/usr/bin/openssl.real'
> ->
> '/home/wdurocher/work/gammaip/warrior/build/tmp/work/cortexa8hf-neon-schneider-linux-gnueabi/config-server/0.0.2-r0/recipe-sysroot-native/usr/bin/openssl.real'"
> 
> Which apparently is related to nodejs(sumo) using openssl 1.0.2p while a
> few packages use openssl 1.1.0. Hacking staging.bbclass to remove the file
> did allow package_qa to complete but that is not really a satisfactory
> solution as 1) I would rather not hack the meta repo directly and

> 2) there
> has to be a better way to have both openssl 1.0 and openssl 1.1 coexist
> with the recipes using the correct version.

Unfortunately there isn't, pick one version (preferably 1.1) and use it
for everything.

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] In Yocto 2.7 powertop package is broken.

[Martin Jansa]

See
https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg126436.html

On Mon, Aug 19, 2019 at 11:35 AM Kaz Kylheku  wrote:

> Hi all,
>
> Via a .bbappend file in my own layers, I added the following patch to
> build powertop, which is enabled when tools-profile is added to
> EXTRA_IMAGE_FEATURES.
>
> * recipes-profiling/powertop/files/posix-path-max-not-defined.patch:
> Patch for build issue. The C++ code needs to including  which
> defines the POSIX PATH_MAX preprocessor symbol.
>
> Index: powertop-v2.10/src/wakeup/wakeup_ethernet.h
> ===
> --- powertop-v2.10.orig/src/wakeup/wakeup_ethernet.h
> +++ powertop-v2.10/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"
> Index: powertop-v2.10/src/wakeup/wakeup_usb.h
> ===
> --- powertop-v2.10.orig/src/wakeup/wakeup_usb.h
> +++ powertop-v2.10/src/wakeup/wakeup_usb.h
> @@ -26,6 +26,7 @@
>   #define _INCLUDE_GUARD_USB_WAKEUP_H
>
>   #include 
> +#include 
>
>   #include "wakeup.h"
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH] smack: add runtime dependency on python3-core

[Martin Jansa]

* fixes:
  ERROR: QA Issue: /usr/share/smack/smack_rules_gen contained in package smack 
requires /usr/bin/python3, but no providers found in RDEPENDS_smack? 
[file-rdeps]

Signed-off-by: Martin Jansa 
---
 recipes-mac/smack/smack_1.3.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mac/smack/smack_1.3.1.bb b/recipes-mac/smack/smack_1.3.1.bb
index 246562a..f32d91b 100644
--- a/recipes-mac/smack/smack_1.3.1.bb
+++ b/recipes-mac/smack/smack_1.3.1.bb
@@ -48,7 +48,7 @@ INITSCRIPT_PARAMS = "start 16 2 3 4 5 . stop 35 0 1 6 ."
 FILES_${PN} += "${sysconfdir}/init.d/smack"
 FILES_${PN}-ptest += "generator"
 
-RDEPENDS_${PN} += "coreutils"
+RDEPENDS_${PN} += "coreutils python3-core"
 RDEPENDS_${PN}-ptest += "make bash bc"
 
 BBCLASSEXTEND = "native"
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[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

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-integrity][PATCH 1/3] layer.conf: add dependency on meta-security

[Martin Jansa]

On Wed, Jul 24, 2019 at 02:23:24PM +0300, Dmitry Eremin-Solenikov wrote:
> ima-evm-utils recipe depends on keyutils recipe which is a part of
> meta-security layer.
> 
> Signed-off-by: Dmitry Eremin-Solenikov 
> ---
>  meta-integrity/conf/layer.conf | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta-integrity/conf/layer.conf b/meta-integrity/conf/layer.conf
> index 2f696cf7c332..917aa86e11d7 100644
> --- a/meta-integrity/conf/layer.conf
> +++ b/meta-integrity/conf/layer.conf
> @@ -22,3 +22,5 @@ IMA_EVM_BASE := '${LAYERDIR}'
>  OE_TERMINAL_EXPORTS += "IMA_EVM_BASE"
>  
>  LAYERSERIES_COMPAT_integrity = "warrior"
> +# ima-evm-utils depends on keyutils from meta-security
> +LAYERDEPENDS_integrity = "core security"

keyutils are now in meta-oe:
http://git.openembedded.org/meta-openembedded/commit/?id=415e213ad75ec9a93171c963395a1c4b92c6233b

> -- 
> 2.20.1
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Dealing with line endings

[Martin Jansa]

Hi Keith,

you can use dos2unix.bbclass:
http://git.openembedded.org/openembedded-core/tree/meta/classes/dos2unix.bbclass
to convert them before do_patch.

Cheers,

On Tue, Jun 25, 2019 at 4:57 AM keith.derrick  wrote:

> I am using an upstream repo with a mix of line endings.
>
>
> In my recipe, I'm applying a patch with normalized line endings, as our
> meta layer repo has a .gitattributes with "text=auto" set.
>
>
> The patch is failing due to "different line endings".
>
>
> Can the git fetcher be configured to normalize line endings on unpack? I
> tried setting core.autocrlf in my global .gitconfig, but the
> fetcher/unpacker seems to ignore it.
>
>
> Thanks
>
> Keith
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-gplv2][warrior][PATCH] bc: use u-a for bc as well

[Martin Jansa]

No problem, thanks for quick response.

Looks like this patch wasn't merged in master as well (I thought it was),
can you please push it as well.

Thanks

On Fri, Jun 21, 2019 at 2:59 PM Burton, Ross  wrote:

> Done, sorry.
>
> Ross
>
> On Fri, 21 Jun 2019 at 13:53, Martin Jansa  wrote:
> >
> > ping for warrior
> >
> > On Tue, Jun 11, 2019 at 9:08 AM Martin Jansa 
> wrote:
> >>
> >> * 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 
> >> ---
> >>  recipes-extended/bc/bc_1.06.bb | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/
> bc_1.06.bb
> >> index d8c8a86..3de1b24 100644
> >> --- a/recipes-extended/bc/bc_1.06.bb
> >> +++ b/recipes-extended/bc/bc_1.06.bb
> >> @@ -20,7 +20,7 @@ SRC_URI[sha256sum] =
> "4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
> >>
> >>  inherit autotools texinfo update-alternatives
> >>
> >> -ALTERNATIVE_${PN} = "dc"
> >> +ALTERNATIVE_${PN} = "bc dc"
> >>  ALTERNATIVE_PRIORITY = "100"
> >>
> >>  BBCLASSEXTEND = "native"
> >> --
> >> 2.17.1
> >>
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-gplv2][warrior][PATCH] bc: use u-a for bc as well

[Martin Jansa]

ping for warrior

On Tue, Jun 11, 2019 at 9:08 AM Martin Jansa  wrote:

> * 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 
> ---
>  recipes-extended/bc/bc_1.06.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/
> bc_1.06.bb
> index d8c8a86..3de1b24 100644
> --- a/recipes-extended/bc/bc_1.06.bb
> +++ b/recipes-extended/bc/bc_1.06.bb
> @@ -20,7 +20,7 @@ SRC_URI[sha256sum] =
> "4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
>
>  inherit autotools texinfo update-alternatives
>
> -ALTERNATIVE_${PN} = "dc"
> +ALTERNATIVE_${PN} = "bc dc"
>  ALTERNATIVE_PRIORITY = "100"
>
>  BBCLASSEXTEND = "native"
> --
> 2.17.1
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cortexa9t2hf instead of cortexa9hf

[Martin Jansa]

On Tue, Jun 18, 2019 at 08:47:32PM +0200, Zoran Stojsavljevic wrote:
> > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > (not "armv7a").
> 
> I think this is impossible for the current state of YOCTO affairs. I
> do not think bitbake is able to determine type of arm silicon, since

Have you read the commit which enabled thumb by default for MACHINEs
which support it?

bitbake is still just a parser of the metadata and executor of our
tasks, it doesn't (and shouldn't) need to know anything about arm silicons.

DEFAULTTUNE is still set in the MACHINE config (through one of the .inc
files) and ARM_INSTRUCTION_SET is just another variable which says if
it should include -mthumb or -marm by default in TUNE_CCARGS, read
conf/machine/include/arm/feature-arm-thumb.inc

Cheers,

> it needs to implement the following instruction somewhere beneath (in
> privileged mode):
> asm volatile("mrc p15, 0, r0, c0, c0, 0" : "=r"(reg_value) );
> 
> But according to the variable MACHINE (example: MACHINE ??=
> "beaglebone"), it is able to determine that the platform is a type of
> armv7a.
> 
> My two cent worth thinking,
> Zoran
> ___
> 
> 
> On Tue, Jun 18, 2019 at 7:13 PM Martin Jansa  wrote:
> >
> > On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> > > Thanks for explaining this.
> > > I take some time to read about thumb/thumb2. The feedback is mixed. It 
> > > seems to generate more compact code, but some say it speeds up, others it 
> > > slows down because of reduced function set - and it can cause strange 
> > > effects.
> > > And mixing this causes time to switch processor mode. So, as I am not an 
> > > expert in this and can't decide what ist best on per function base and 
> > > speed is of highest priority, I think I better should use not thumb(2).
> > >
> > > So, do I get it right that with this cortexa9t2hf I just have the option 
> > > to compile it for thumb2? But without using a dedicated compiler option 
> > > it generates same "standard" arm code and the difference is just to adapt 
> > > all the Makefiles for this suffix.
> > >
> > > According to Martin I can get the previous setting by just set 
> > > ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that 
> > > I lose other kinds of optimisation. (I am just a user not an expert in 
> > > arm architecture).
> >
> > I didn't say anything about changing the DEFAULTTUNE.
> >
> > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > (not "armv7a").
> >
> > > On the other hand for those like me it is better go the standard way. 
> > > Once I am sure compiler results will not become worse (see above) I go 
> > > for the pain and renaming my toolchain/makefiles/stuff.
> >
> > The results should be almost the same, maybe slightly better, depends on
> > the actual code as Khem mentioned.
> >
> > But if this causes you a lot of pain "renaming my toolchain/makefiles/stuff"
> > then you should probably spend the time on your tooling instead of
> > replacing one hardcoded value with another.
> >
> > Cheers,
> >
> > >
> > > Thanks for you taking the time.
> > > Arno
> > >
> > > > Hello Arno,
> > > >
> > > > Let me try to explain my point of view. Since here (my best guess) we
> > > > have some asynchronous bitbake code which went South upon introducing
> > > > T2 HW extension.
> > > >
> > > > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > > > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > > > media coprocessor) exists in both of them. In other words:
> > > > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> > > >
> > > > Point [2]:
> > > > > bitbake gives me in 2.5:
> > > > > TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> > > > > cortexa9"
> > > > > TARGET_FPU   = "hard"
> > > > >
> > > > > and in 2.7:
> > > > > TUNE_FEATURES= "arm vfp cortexa9 neon thumb 
> > > > > callconvention-hard"
> > > > > TARGET_FPU   = "hard"
> > > >
> > > > These two lines are the same: you are able to use 32b arm mode, 16bit
> > > > thumb mode,

Re: [yocto] cortexa9t2hf instead of cortexa9hf

[Martin Jansa]

On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> Thanks for explaining this.
> I take some time to read about thumb/thumb2. The feedback is mixed. It seems 
> to generate more compact code, but some say it speeds up, others it slows 
> down because of reduced function set - and it can cause strange effects.
> And mixing this causes time to switch processor mode. So, as I am not an 
> expert in this and can't decide what ist best on per function base and speed 
> is of highest priority, I think I better should use not thumb(2).
> 
> So, do I get it right that with this cortexa9t2hf I just have the option to 
> compile it for thumb2? But without using a dedicated compiler option it 
> generates same "standard" arm code and the difference is just to adapt all 
> the Makefiles for this suffix.
> 
> According to Martin I can get the previous setting by just set 
> ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I 
> lose other kinds of optimisation. (I am just a user not an expert in arm 
> architecture).

I didn't say anything about changing the DEFAULTTUNE.

Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
(not "armv7a").

> On the other hand for those like me it is better go the standard way. Once I 
> am sure compiler results will not become worse (see above) I go for the pain 
> and renaming my toolchain/makefiles/stuff.

The results should be almost the same, maybe slightly better, depends on
the actual code as Khem mentioned.

But if this causes you a lot of pain "renaming my toolchain/makefiles/stuff"
then you should probably spend the time on your tooling instead of
replacing one hardcoded value with another.

Cheers,

> 
> Thanks for you taking the time.
> Arno
> 
> > Hello Arno,
> >
> > Let me try to explain my point of view. Since here (my best guess) we
> > have some asynchronous bitbake code which went South upon introducing
> > T2 HW extension.
> >
> > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > media coprocessor) exists in both of them. In other words:
> > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> >
> > Point [2]:
> > > bitbake gives me in 2.5:
> > > TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> > > cortexa9"
> > > TARGET_FPU   = "hard"
> > >
> > > and in 2.7:
> > > TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
> > > TARGET_FPU   = "hard"
> >
> > These two lines are the same: you are able to use 32b arm mode, 16bit
> > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > extension as well. The Cortex in both cases is A9.
> >
> > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > and I have no idea if this is done intentionally or not.
> >
> > Because of that I copied Alex and Ross to CC: into email, so they
> > should unveil this mystery (I would prefer "armv7" to stay in bitbake
> > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
> >
> > Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> > should return "armv7" as TUNE FEATURE.
> >
> > Best Regards,
> > Zoran
> > ___
> >
> >
> > On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens  wrote:
> > >
> > > Hello Zoran,
> > > thanks. As far as I understand is thumb2 another mode of coding, that 
> > > might create more compact code.
> > > But I want to keep all compatible to my previous tool-chain and settings.
> > > The only file where I can found this "cortexa9t2hf" is
> > > ./meta/conf/machine/include/tune-cortexa9.inc
> > > but I can't see how I can control Yocto to generate "cortexa9hf-neon" as 
> > > before.
> > > Or have I been wrong the time before?
> > >
> > > bitbake gives me in 2.5:
> > >
> > > TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> > > cortexa9"
> > > TARGET_FPU   = "hard"
> > >
> > > and in 2.7:
> > > TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
> > > TARGET_FPU   = "hard"
> > >
> > > so armv7a seem to be missing. In terms of thumb both is same. But is that 
> > > the reason? Where to set it?
> > > Arno
> > >
> > > >
> > > > Hello Arno,
> > > >
> > > > Your question, per say, has little to do with YOCTO forum. But I'll
> > > > try (as my best) to answer your question.
> > > >
> > > > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> > > >
> > > > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > > > question is what is T2? T2 is addition to the previous architecture
> > > > Cortexa9hf, and addition is Thumb-2 mode.
> > > >
> > > > Hope this helps,
> > > >
> > > > Zoran
> > > > ___
> > > >
> > > > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens  wrote:
> > > > >
> > > > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure 

Re: [yocto] cortexa9t2hf instead of cortexa9hf

[Martin Jansa]

See this oe-core commit (from 2.6 Thud):

commit c88304a78e528596ca481cabe273749c286c352a
Author: Andre McCurdy 
Date:   Fri May 18 15:50:40 2018 -0700

arch-armv7a.inc: default to Thumb2 instruction set for armv7a and above

which enabled Thumb2 by default, if you want to disable it as it was before
set ARM_INSTRUCTION_SET to "arm".

On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens  wrote:

> I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something
> wrong or what exactly does this t2 mean?
> Target system is a Zynq7020 system.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] YP sstate example conf file

[Martin Jansa]

Good question.

I've one related to this as well.

It would be also good to document (if it isn't somewhere already) what
builds populate this mirror.

I assume it will be some autobuilder job with DISTRO = poky, but without
file listing enabled over http I cannot even guess which MACHINEs were
included.

It would be useful to provide one tarball with all sigdata files, which
could be manually downloaded to check what's available there and to debug
why the sstate cache from this mirror wasn't reused in local build.

Cheers,

On Thu, Jun 13, 2019 at 4:32 PM William Mills  wrote:

> Hello,
>
> From poky warrior tip, file meta-poky/conf/local.conf.sample
> """
> #
> #SSTATE_MIRRORS ?= "file://.*
> http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH;
> """
>
> Should that be 2.7??  Or are you relying on the intelligence of the user
> to fix this up?
>
> If the former then it needs to go on a checklist.
> If the later then perhaps it would be better to use X.Y or something
> that does not appear to work.  Some verbage to suggest the edit would
> probably be good as well.
>
> (and no, I did not run it like that. I'm slightly smarted than that.)
>
>
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample?h=warrior#n235
>
> Thanks,
> Bill
>
> 
> William A. Mills
> Chief Technologist, Open Solutions, SDO
> Texas Instruments, Inc.
> 20450 Century Blvd
> Germantown MD 20878
> 240-643-0836
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][warrior][PATCH] bc: use u-a for bc as well

[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 
---
 recipes-extended/bc/bc_1.06.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/bc_1.06.bb
index d8c8a86..3de1b24 100644
--- a/recipes-extended/bc/bc_1.06.bb
+++ b/recipes-extended/bc/bc_1.06.bb
@@ -20,7 +20,7 @@ SRC_URI[sha256sum] = 
"4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
 
 inherit autotools texinfo update-alternatives
 
-ALTERNATIVE_${PN} = "dc"
+ALTERNATIVE_${PN} = "bc dc"
 ALTERNATIVE_PRIORITY = "100"
 
 BBCLASSEXTEND = "native"
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH] bc: use u-a for bc as well

[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 
---
 recipes-extended/bc/bc_1.06.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/bc_1.06.bb
index d8c8a86..3de1b24 100644
--- a/recipes-extended/bc/bc_1.06.bb
+++ b/recipes-extended/bc/bc_1.06.bb
@@ -20,7 +20,7 @@ SRC_URI[sha256sum] = 
"4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
 
 inherit autotools texinfo update-alternatives
 
-ALTERNATIVE_${PN} = "dc"
+ALTERNATIVE_${PN} = "bc dc"
 ALTERNATIVE_PRIORITY = "100"
 
 BBCLASSEXTEND = "native"
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH] elfutils: ignore new error from gcc-9

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 recipes-devtools/elfutils/elfutils_0.148.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb 
b/recipes-devtools/elfutils/elfutils_0.148.bb
index a03b74e..1f07a28 100644
--- a/recipes-devtools/elfutils/elfutils_0.148.bb
+++ b/recipes-devtools/elfutils/elfutils_0.148.bb
@@ -57,6 +57,10 @@ SRC_URI += "\
 "
 inherit autotools gettext
 
+# There is a fix in 0.175 version 
(https://sourceware.org/bugzilla/show_bug.cgi?id=23884)
+# but 0.175 has different license, so to be safe don't backport the fix, just 
ignore the issue
+CFLAGS += "-Wno-error=missing-attributes"
+
 EXTRA_OECONF = "--program-prefix=eu- --without-lzma"
 EXTRA_OECONF_append_class-native = " --without-bzlib"
 EXTRA_OECONF_append_libc-uclibc = " --enable-uclibc"
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils][PATCH] opkg-list-fields: fix to print the fields again

[Martin Jansa]

* 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)

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

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH] bc: use u-a for bc as well

[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 
---
 recipes-extended/bc/bc_1.06.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/bc_1.06.bb
index d8c8a86..3de1b24 100644
--- a/recipes-extended/bc/bc_1.06.bb
+++ b/recipes-extended/bc/bc_1.06.bb
@@ -20,7 +20,7 @@ SRC_URI[sha256sum] = 
"4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
 
 inherit autotools texinfo update-alternatives
 
-ALTERNATIVE_${PN} = "dc"
+ALTERNATIVE_${PN} = "bc dc"
 ALTERNATIVE_PRIORITY = "100"
 
 BBCLASSEXTEND = "native"
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-security][PATCH] keyutils: fix library install path

[Martin Jansa]

When you're on it, can you please check if it works with multilib?

I think $(USRLIBDIR) doesn't respect ${libdir} from OE, so it always
installs the library to /usr/lib instead of e.g. /usr/lib64 with multlilib.

e.g. recipes-security/ccs-tools/ccs-tools_1.8.4.bb is
setting USRLIBDIR=${libdir}, I guess keyutils needs the same.

On Fri, May 17, 2019 at 6:46 PM Armin Kuster  wrote:

> Signed-off-by: Armin Kuster 
> ---
>  .../files/fix_library_install_path.patch  | 28 +++
>  recipes-security/keyutils/keyutils_1.6.bb |  1 +
>  2 files changed, 29 insertions(+)
>  create mode 100644
> recipes-security/keyutils/files/fix_library_install_path.patch
>
> diff --git
> a/recipes-security/keyutils/files/fix_library_install_path.patch
> b/recipes-security/keyutils/files/fix_library_install_path.patch
> new file mode 100644
> index 000..938fe2e
> --- /dev/null
> +++ b/recipes-security/keyutils/files/fix_library_install_path.patch
> @@ -0,0 +1,28 @@
> +From b0355cc205543ffd33752874295139d57c4fbc3e Mon Sep 17 00:00:00 2001
> +From: Wenzong Fan 
> +Date: Tue, 26 Sep 2017 07:59:51 +
> +Subject: [PATCH] Subject: [PATCH] keyutils: use relative path for link
> +
> +The absolute path of the symlink will be invalid
> +when populated in sysroot, so use relative path instead.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Jackie Huang 
> +Signed-off-by: Wenzong Fan 
> +{rebased for 1.6]
> +Signed-off-by: Armin Kuster 
> +
> +Index: keyutils-1.6/Makefile
> +===
> +--- keyutils-1.6.orig/Makefile
>  keyutils-1.6/Makefile
> +@@ -184,7 +184,7 @@ ifeq ($(NO_SOLIB),0)
> +   $(INSTALL) -D $(LIBNAME) $(DESTDIR)$(LIBDIR)/$(LIBNAME)
> +   $(LNS) $(LIBNAME) $(DESTDIR)$(LIBDIR)/$(SONAME)
> +   mkdir -p $(DESTDIR)$(USRLIBDIR)
> +-  $(LNS) $(LIBDIR)/$(SONAME) $(DESTDIR)$(USRLIBDIR)/$(DEVELLIB)
> ++  $(LNS) $(SONAME) $(DESTDIR)$(USRLIBDIR)/$(DEVELLIB)
> +   sed \
> +   -e 's,@VERSION\@,$(VERSION),g' \
> +   -e 's,@prefix\@,$(PREFIX),g' \
> diff --git a/recipes-security/keyutils/keyutils_1.6.bb
> b/recipes-security/keyutils/keyutils_1.6.bb
> index c961fa2..2968a24 100644
> --- a/recipes-security/keyutils/keyutils_1.6.bb
> +++ b/recipes-security/keyutils/keyutils_1.6.bb
> @@ -19,6 +19,7 @@ SRC_URI = "
> http://people.redhat.com/dhowells/keyutils/${BP}.tar.bz2 \
> file://keyutils-test-fix-output-format.patch \
>
> file://keyutils-fix-error-report-by-adding-default-message.patch \
> file://run-ptest \
> +   file://fix_library_install_path.patch \
> "
>
>  SRC_URI[md5sum] = "191987b0ab46bb5b50efd70a6e6ce808"
> --
> 2.17.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][warrior][master][PATCH] licenses: restore Elfutils-Exception from oe-core

[Martin Jansa]

* it's still used by:
  recipes-devtools/elfutils/elfutils_0.148.bb:LICENSE = "(GPL-2+ & 
Elfutils-Exception)"
* was removed in oe-core with:
  
http://git.openembedded.org/openembedded-core/commit/?id=88188807a6ac9bab738a69f6b4caba9ed092d78f
* causing:
  do_rootfs: The license listed Elfutils-Exception was not in the licenses 
collected for recipe elfutils

Signed-off-by: Martin Jansa 
---
 conf/layer.conf |  2 ++
 licenses/Elfutils-Exception | 12 
 2 files changed, 14 insertions(+)
 create mode 100644 licenses/Elfutils-Exception

diff --git a/conf/layer.conf b/conf/layer.conf
index 59f6a89..44c6712 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,3 +15,5 @@ LAYERVERSION_gplv2 = "1"
 LAYERDEPENDS_gplv2 = "core"
 
 LAYERSERIES_COMPAT_gplv2 = "warrior"
+
+LICENSE_PATH += "${LAYERDIR}/licenses"
diff --git a/licenses/Elfutils-Exception b/licenses/Elfutils-Exception
new file mode 100644
index 000..627d769
--- /dev/null
+++ b/licenses/Elfutils-Exception
@@ -0,0 +1,12 @@
+   This file describes the limits of the Exception under which you are allowed
+   to distribute Non-GPL Code in linked combination with Red Hat elfutils.
+   For the full text of the license, please see one of the header files
+   included with the source distribution or the file COPYING found in the
+   top level directory of the source.
+
+   The Approved Interfaces are the functions declared in the files:
+
+   libelf.h
+   libdw.h
+   libdwfl.h
+
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH] layer.conf: Update to warrior release name series

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 43d578b..59f6a89 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,4 +14,4 @@ LAYERVERSION_gplv2 = "1"
 
 LAYERDEPENDS_gplv2 = "core"
 
-LAYERSERIES_COMPAT_gplv2 = "thud"
+LAYERSERIES_COMPAT_gplv2 = "warrior"
-- 
2.17.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] failed to compile php_7.2.10.bb

[Martin Jansa]

On Wed, Oct 10, 2018 at 04:03:55PM -0400, Simon Chamlian wrote:
> Hi,
> 
> I tried to bitbake php_7.2.10.bb and I am getting the following error.
> 
> Did anyone tried to compile php_7.2.10.bb ?
> 
> Any clue on what the issue can be ?
> 
> bb.data_smart.ExpansionError: Failure expanding variable PACKAGECONFIG,
> expression was mysql sqlite3 imap opcache openssl
> ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6 pam', d)}  apache2 sqlite3
> pgsql  which triggered exception AttributeError: module 'bb.utils' has no
> attribute 'filter'

You're missing different versions of oe-core and meta-oe, use both from
the same branch and it will work.

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [pseudo] Pseudo 1.8+ xattr sqlite corruption

[Martin Jansa]

I did the same SRCREV bump locally and can confirm that
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 pseudo: Incorrect
UID/GID in packaged files
is still reproducible:
ERROR: glibc-locale-2.24-r0 do_package_qa: QA Issue: glibc-locale:
/glibc-binary-localedata-sw-ke/usr/lib/locale/sw_KE/LC_NUMERIC is owned by
uid 1101, which is the same as the user running bitbake. This may be due to
host contamination [host-user-contaminated]

On Fri, Sep 21, 2018 at 2:51 PM Burton, Ross  wrote:

> Wired: I've just sent a patch to update oe-core to use the current
> HEAD of pseudo.
> Tired: WARNING: glibc-locale-2.28-r0 do_package_qa: QA Issue:
> glibc-locale:
> /glibc-binary-localedata-en-za.iso-8859-1/usr/lib/locale/en_ZA.ISO-8859-1/LC_PAPER
> is owned by uid 1000, which is the same as the user running bitbake.
> This may be due to host contamination [host-user-contaminated]
>
> I was *really* hoping this would solve the problem.
>
> Ross
>
> On Thu, 20 Sep 2018 at 21:51, Seebs  wrote:
> >
> > Nice catch. Merged a patch that applies this also.
> >
> > -s
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] coreutils postinstall warning

[Martin Jansa]

On Fri, Sep 14, 2018 at 07:38:49AM -0500, Seth Bollinger wrote:
> On Mon, Aug 20, 2018 at 8:16 AM Seth Bollinger  wrote:
> 
> > Hello All,
> >
> > We've been seeing the following warning for a while now.  Is this expected?
> >
> > WARNING: manuf-image-1.0-r0 do_rootfs: Intentionally failing postinstall
> > scriptlets of ['coreutils'] to defer them to first boot is deprecated.
> > Please place them into pkg_postinst_ontarget_${PN} ().
> >
> > From what I can see, it's being caused by update-alternatives.  Is there a
> > workaround for this?
> >
> 
> I'll answer my own question since it may be of value to someone else.
> 
> coreutils, util-linux and busybox all provide overlapping utilities.  Most
> are covered by update alternatives, some are not.  If you have enabled one
> of those in busybox, then update alternatives will fail trying to make the
> symbolic link.  As I understand it (from the warning message) is that
> failing the postinst step used to be a way to ask to be executed at target
> runtime.  The solution is to have only one package provide the conflicting
> utility (or add alternatives to all packages that provide the utility).

Using u-a for all conflicting binaries is the preferred option.

For example there was fix for nice provided by coreutils merged
recently:
http://git.openembedded.org/openembedded-core/commit/?id=57b1b20abca7d6821e99802147b93f4f577cfad0
or setfattr in attr:
http://git.openembedded.org/openembedded-core/commit/?id=d633633f3d83467fe1f946c57e2e75e0e774ec7e

busybox have a lot of available applets and people tend to
enable/disable them in their own defconfigs quite often, removing
something from util-linux or coreutils would break it for people who
disabled the same in busybox defconfig and vice versa, u-a on the other
hand will work reasonably for everybody.

If you have conflict with unshare, just send a patch. I will do the same
with printenv for coreutils which I have in .bbappend for way too long.

Regards,


> 
> Here's an example error message:
> update-alternatives: Error: not linking
> /home/seth/projects/awusb/build/tmp/work/awusb1012-awusb-linux/awusb-image/1.0-r0/rootfs/usr/bin/unshare
> to /bin/busybox.nosuid since
> /home/seth/projects/awusb/build/tmp/work/awusb1012-awusb-linux/awusb-image/1.0-r0/rootfs/usr/bin/unshare
> exists and is not a link
> 
> Seth

> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Postinstall scriptlets of ['coreutils'] have failed

[Martin Jansa]

pn-buildlist isn't really useful in this case, building both coreutils and
busybox doesn't imply that both will be actually included in the image..

If you compare installed-package-names.txt in buildhistory you'll see that
only the core-image-minimal-dev has coreutils installed.

docker-shr qemux86-64@ ~/build/oe-core/buildhistory/images/qemux86_64/glibc
$ grep busybox core-image-minimal*/installed-package-names.txt
core-image-minimal-dev/installed-package-names.txt:busybox
core-image-minimal-dev/installed-package-names.txt:busybox-dev
core-image-minimal-dev/installed-package-names.txt:busybox-syslog
core-image-minimal-dev/installed-package-names.txt:busybox-udhcpc
core-image-minimal/installed-package-names.txt:busybox
core-image-minimal/installed-package-names.txt:busybox-syslog
core-image-minimal/installed-package-names.txt:busybox-udhcpc
docker-shr qemux86-64@ ~/build/oe-core/buildhistory/images/qemux86_64/glibc
$ grep coreutils core-image-minimal*/installed-package-names.txt
core-image-minimal-dev/installed-package-names.txt:coreutils
core-image-minimal-dev/installed-package-names.txt:coreutils-dev

That's why the issue is shown only in core-image-minimal-dev.

Do you have custom busybox defconfig which enables nice applet? It's not
enabled in default config:
meta/recipes-core/busybox/busybox/defconfig:# CONFIG_NICE is not set




On Mon, Sep 10, 2018 at 8:15 PM Jens Rehsack  wrote:

>
>
> Am 09.09.2018 um 20:56 schrieb Martin Jansa :
>
> Does core-image-minimal include both busybox and coreutils? Maybe only
> -dev include both.
>
>
> Unfortunately both include coreutils, see attached pn-buildlist (I can
> send you the recipe-depends and the task-depends, either if you need them).
>
> I'll send fix for attr soon, waiting for some builds to finish testing it.
>
>
> Seems similar to my kind of soon :-)
>
> On Sun, Sep 9, 2018 at 8:47 PM Jens Rehsack  wrote:
>
>> So far, so good.
>>
>> They way to fix that seems either to check why busybox uses
>> ${base_bindir} nowadays in favor of ${bindir} and fix either busybox or
>> coreutils or attr.
>>
>> What drives me nuts is not only the failure after the busybox update -
>> why does core-image-minimal builds successful while core-image-minimal-dev
>> fails?
>>
>> Cheers,
>> Jens
>>
>> Am 09.09.2018 um 19:27 schrieb Martin Jansa :
>>
>> busybox is most likely the one providing it in ${base_bindir}
>>
>> Recent busybox upgrade probably moved this file.
>>
>> There is also conflict on /usr/bin/setfattr between busybox and attr now.
>>
>> On Sun, Sep 9, 2018 at 7:22 PM Martin Jansa 
>> wrote:
>>
>>> There are 2 packages using u-a for nice, but one is using {bindir} and
>>> 2nd one is using {base_bindir}
>>>
>>> coreutils is using bindir, find what's using ${base_bindir} and change
>>> one of them to use the same u-a link as the other one.
>>>
>>> On Sun, Sep 9, 2018 at 5:59 PM Jens Rehsack  wrote:
>>>
>>>>
>>>>
>>>> Am 09.09.2018 um 13:15 schrieb Alexander Kanavin <
>>>> alex.kana...@gmail.com>:
>>>>
>>>> It's right in the message?
>>>>
>>>> ERROR: Logfile of failure stored in:
>>>>
>>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/temp/log.do_rootfs.27709
>>>>
>>>> Alex
>>>>
>>>>
>>>>
>>>> It's not much what stands there:
>>>>
>>>> Downloading
>>>> file:/home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/oe-rootfs-repo/core2-64/libcap-dev_2.25-r0_core2-64.ipk.
>>>> Installing coreutils-dev (8.30) on root
>>>> [...]
>>>> Configuring update-rc.d-deupdate-alternatives: Linking
>>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/diff
>>>> to /usr/bin/diff.diffutils
>>>> update-alternatives: Linking
>>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/cmp
>>>> to /usr/bin/cmp.diffutils
>>>> update-alternatives: Linking
>>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/bin/umount
>>>> to /bin/umount.util-linux
>>>> update-alternatives: Linking
>>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/[
>>>> to /usr/

Re: [yocto] Postinstall scriptlets of ['coreutils'] have failed

[Martin Jansa]

Does core-image-minimal include both busybox and coreutils? Maybe only -dev
include both.

I'll send fix for attr soon, waiting for some builds to finish testing it.

On Sun, Sep 9, 2018 at 8:47 PM Jens Rehsack  wrote:

> So far, so good.
>
> They way to fix that seems either to check why busybox uses ${base_bindir}
> nowadays in favor of ${bindir} and fix either busybox or coreutils or attr.
>
> What drives me nuts is not only the failure after the busybox update - why
> does core-image-minimal builds successful while core-image-minimal-dev
> fails?
>
> Cheers,
> Jens
>
> Am 09.09.2018 um 19:27 schrieb Martin Jansa :
>
> busybox is most likely the one providing it in ${base_bindir}
>
> Recent busybox upgrade probably moved this file.
>
> There is also conflict on /usr/bin/setfattr between busybox and attr now.
>
> On Sun, Sep 9, 2018 at 7:22 PM Martin Jansa 
> wrote:
>
>> There are 2 packages using u-a for nice, but one is using {bindir} and
>> 2nd one is using {base_bindir}
>>
>> coreutils is using bindir, find what's using ${base_bindir} and change
>> one of them to use the same u-a link as the other one.
>>
>> On Sun, Sep 9, 2018 at 5:59 PM Jens Rehsack  wrote:
>>
>>>
>>>
>>> Am 09.09.2018 um 13:15 schrieb Alexander Kanavin >> >:
>>>
>>> It's right in the message?
>>>
>>> ERROR: Logfile of failure stored in:
>>>
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/temp/log.do_rootfs.27709
>>>
>>> Alex
>>>
>>>
>>>
>>> It's not much what stands there:
>>>
>>> Downloading
>>> file:/home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/oe-rootfs-repo/core2-64/libcap-dev_2.25-r0_core2-64.ipk.
>>> Installing coreutils-dev (8.30) on root
>>> [...]
>>> Configuring update-rc.d-deupdate-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/diff
>>> to /usr/bin/diff.diffutils
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/cmp
>>> to /usr/bin/cmp.diffutils
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/bin/umount
>>> to /bin/umount.util-linux
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/[
>>> to /usr/bin/lbracket.coreutils
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/arch
>>> to /usr/bin/arch.coreutils
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/basename
>>> to /usr/bin/basename.coreutils
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/chcon
>>> to /usr/bin/chcon.coreutils
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/cksum
>>> to /usr/bin/cksum.coreutils
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/comm
>>> to /usr/bin/comm.coreutils
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/csplit
>>> to /usr/bin/csplit.coreutils
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/cut
>>> to /usr/bin/cut.coreutils
>>> [...]
>>> update-alternatives: Linking
>>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/mkfifo
>>> to /usr/bin/mkfifo.coreutils
>>> update-alternatives: renaming nice link from /bin/nice to /usr/bin/nice
>>> mv: cannot stat '/bin/nice': No such file or directory
>>> update-alternatives: Linking
>&

Re: [yocto] Postinstall scriptlets of ['coreutils'] have failed

[Martin Jansa]

busybox is most likely the one providing it in ${base_bindir}

Recent busybox upgrade probably moved this file.

There is also conflict on /usr/bin/setfattr between busybox and attr now.

On Sun, Sep 9, 2018 at 7:22 PM Martin Jansa  wrote:

> There are 2 packages using u-a for nice, but one is using {bindir} and 2nd
> one is using {base_bindir}
>
> coreutils is using bindir, find what's using ${base_bindir} and change one
> of them to use the same u-a link as the other one.
>
> On Sun, Sep 9, 2018 at 5:59 PM Jens Rehsack  wrote:
>
>>
>>
>> Am 09.09.2018 um 13:15 schrieb Alexander Kanavin > >:
>>
>> It's right in the message?
>>
>> ERROR: Logfile of failure stored in:
>>
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/temp/log.do_rootfs.27709
>>
>> Alex
>>
>>
>>
>> It's not much what stands there:
>>
>> Downloading
>> file:/home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/oe-rootfs-repo/core2-64/libcap-dev_2.25-r0_core2-64.ipk.
>> Installing coreutils-dev (8.30) on root
>> [...]
>> Configuring update-rc.d-deupdate-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/diff
>> to /usr/bin/diff.diffutils
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/cmp
>> to /usr/bin/cmp.diffutils
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/bin/umount
>> to /bin/umount.util-linux
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/[
>> to /usr/bin/lbracket.coreutils
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/arch
>> to /usr/bin/arch.coreutils
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/basename
>> to /usr/bin/basename.coreutils
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/chcon
>> to /usr/bin/chcon.coreutils
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/cksum
>> to /usr/bin/cksum.coreutils
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/comm
>> to /usr/bin/comm.coreutils
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/csplit
>> to /usr/bin/csplit.coreutils
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/cut
>> to /usr/bin/cut.coreutils
>> [...]
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/mkfifo
>> to /usr/bin/mkfifo.coreutils
>> update-alternatives: renaming nice link from /bin/nice to /usr/bin/nice
>> mv: cannot stat '/bin/nice': No such file or directory
>> update-alternatives: Linking
>> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/bin/bash
>> to /bin/bash.bash
>> [...]
>> Configuring libgmp10.
>> Configuring coreutils.
>> coreutils.postinst returned 1, marking as unpacked only, configuration
>> required on target.
>> Configuring acl.
>> [...]
>>
>> The postinst file of coreutils contains only a long list of
>> update-alternatives, as many other packages do either.
>>
>> core-image-minimal contains coreutils as well, but it doesn't fail the
>> same way.
>>
>> Any ideas?
>>
>> 2018-09-09 10:58 GMT+02:00 Jens Rehsack :
>>
>> Hi,
>>
>> I got following issue when building an image for live-debugging:
>>
>> ERROR: updatable-app-dev-image-1.0-r0 do_rootfs: Postinstall scriptlets
>> of ['coreutils'] have failed. If the intention is to defer the

Re: [yocto] Postinstall scriptlets of ['coreutils'] have failed

[Martin Jansa]

There are 2 packages using u-a for nice, but one is using {bindir} and 2nd
one is using {base_bindir}

coreutils is using bindir, find what's using ${base_bindir} and change one
of them to use the same u-a link as the other one.

On Sun, Sep 9, 2018 at 5:59 PM Jens Rehsack  wrote:

>
>
> Am 09.09.2018 um 13:15 schrieb Alexander Kanavin :
>
> It's right in the message?
>
> ERROR: Logfile of failure stored in:
>
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/temp/log.do_rootfs.27709
>
> Alex
>
>
>
> It's not much what stands there:
>
> Downloading
> file:/home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/oe-rootfs-repo/core2-64/libcap-dev_2.25-r0_core2-64.ipk.
> Installing coreutils-dev (8.30) on root
> [...]
> Configuring update-rc.d-deupdate-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/diff
> to /usr/bin/diff.diffutils
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/cmp
> to /usr/bin/cmp.diffutils
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/bin/umount
> to /bin/umount.util-linux
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/[
> to /usr/bin/lbracket.coreutils
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/arch
> to /usr/bin/arch.coreutils
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/basename
> to /usr/bin/basename.coreutils
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/chcon
> to /usr/bin/chcon.coreutils
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/cksum
> to /usr/bin/cksum.coreutils
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/comm
> to /usr/bin/comm.coreutils
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/csplit
> to /usr/bin/csplit.coreutils
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/cut
> to /usr/bin/cut.coreutils
> [...]
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/usr/bin/mkfifo
> to /usr/bin/mkfifo.coreutils
> update-alternatives: renaming nice link from /bin/nice to /usr/bin/nice
> mv: cannot stat '/bin/nice': No such file or directory
> update-alternatives: Linking
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/rootfs/bin/bash
> to /bin/bash.bash
> [...]
> Configuring libgmp10.
> Configuring coreutils.
> coreutils.postinst returned 1, marking as unpacked only, configuration
> required on target.
> Configuring acl.
> [...]
>
> The postinst file of coreutils contains only a long list of
> update-alternatives, as many other packages do either.
>
> core-image-minimal contains coreutils as well, but it doesn't fail the
> same way.
>
> Any ideas?
>
> 2018-09-09 10:58 GMT+02:00 Jens Rehsack :
>
> Hi,
>
> I got following issue when building an image for live-debugging:
>
> ERROR: updatable-app-dev-image-1.0-r0 do_rootfs: Postinstall scriptlets of
> ['coreutils'] 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.
> Details of the failure are in
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/updatable-app-dev-image/1.0-r0/temp/log.do_rootfs.
> ERROR: updatable-app-dev-image-1.0-r0 do_rootfs: Function failed: do_rootfs
> ERROR: Logfile of failure stored in:
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/updatable-app-dev-image/1.0-r0/temp/log.do_rootfs.14358
> ERROR: Task
> (/home/sno/gpw-community-bsp/sources/meta-jens/recipes-images/images/updatable-app-dev-image.bb:do_rootfs)
> failed with exit code '1'
>
> I can reproduce it using core-image-minimal-dev
>
> WARNING: core-image-minimal-dev-1.0-r0 do_rootfs: coreutils.postinst
> returned 1, marking as unpacked only, configuration 

Re: [yocto] net-snmp_5.8.bb failed to compile

[Martin Jansa]

Follow the READMEs and don't mix layers from different branches.

You need to checkout all repositories with layers from the same branch to
be compatible. Now you're mixing newer meta-oe branch with older oe-core
branch which doesn't have bb.utils.filter function yet.

On Tue, Aug 28, 2018 at 5:17 PM Simon Chamlian 
wrote:

>
> Hi,
>
> Just download  net-snmp_5.8.bb but it failed to compile:
>
>
> $ bitbake net-snmp
> Loading cache: 100%
> ||
> Time: 0:00:01
> Loaded 3093 entries from dependency cache.
> *ERROR:* ExpansionError during parsing
> /opt/PHYTEC_BSPs/yocto_imx7/sources/meta-openembedded/meta-networking/recipes-protocols/net-snmp/
> net-snmp_5.8.bb   | ETA:
> --:--:--
> Traceback (most recent call last):
>   File
> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/classes/base.bbclass", line
> 375, in
> __anon_656__opt_PHYTEC_BSPs_yocto_imx7_sources_poky_meta_classes_base_bbclass(d= object at 0x7fe0ee311be0>):
>  pkgconfig = (d.getVar('PACKAGECONFIG', True) or "").split()
> >pn = d.getVar("PN", True)
>
>   File
> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
> line 569, in DataSmart.getVar(var='PACKAGECONFIG', expand=True,
> noweakdefault=False, parsing=False):
>  def getVar(self, var, expand, noweakdefault=False, parsing=False):
> >return self.getVarFlag(var, "_content", expand,
> noweakdefault, parsing)
>
>   File
> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
> line 737, in DataSmart.getVarFlag(var='PACKAGECONFIG', flag='_content',
> expand=True, noweakdefault=False, parsing=False):
>  cachename = var + "[" + flag + "]"
> >value = self.expand(value, cachename)
>
>   File
> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
> line 410, in DataSmart.expand(s="${@bb.utils.filter('DISTRO_FEATURES',
> 'ipv6', d)}", varname='PACKAGECONFIG'):
>  def expand(self, s, varname = None):
> >return self.expandWithRefs(s, varname).value
>
>   File
> "/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/bitbake/lib/bb/data_smart.py",
> line 400, in
> DataSmart.expandWithRefs(s="${@bb.utils.filter('DISTRO_FEATURES', 'ipv6',
> d)}", varname='PACKAGECONFIG'):
>  except Exception as exc:
> >raise ExpansionError(varname, s, exc) from exc
>
> bb.data_smart.ExpansionError: Failure expanding variable PACKAGECONFIG,
> expression was ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} which
> triggered exception AttributeError: module 'bb.utils' has no attribute
> 'filter'
>
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> $
>
> Any hints would be greatly appreciated.
>
> S
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Intel machine with 64 Bit kernel and 32 Bit user space

[Martin Jansa]

Check with bitbake -g what's pulling gcc-runtime into the image, if your
whole userspace should be 32bit, then lib32-gcc-runtime will be enough.

My multilib builds contain only following 64bit builds:
defaultpkgname  depmodwrapper-cross  linux-yocto  lttng-modules
make-mod-scripts  qemuwrapper-cross  vboxguestdrivers
the rest is 32bit

On Fri, Jul 27, 2018 at 12:23 PM Ayoub Zaki 
wrote:

> Hello all,
>
> thanks for the suggestions: I tried the multilib concept of yocto but as
> Martin already wrote is not that simple, my build is breaking during wic
> image generation as follow:
>
> zaki@xps:/opt/build/poky/build$ MACHINE=nx bitbake  lib32-my-image
> Loading cache: 100%
> ||
> Time: 0:00:00
> Loaded 4968 entries from dependency cache.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION   = "1.38.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal"
> TARGET_SYS   = "x86_64-poky-linux"
> MACHINE  = "nx"
> DISTRO   = "poky"
> DISTRO_VERSION   = "V00.00.00.00+20180727100935"
> TUNE_FEATURES= "m64 core2"
> TARGET_FPU   = ""
> meta
> meta-poky
> meta-yocto-bsp   = "sumo:90f7edb32ac2500d93bb7ca5045a9d048f551223"
> meta-intel   = "sumo:2430f73ee06f3315ebebe69899f1977f9a09e29f"
> meta-oe
> meta-networking
> meta-webserver
> meta-python  = "sumo:b0950aeff5b630256bb5e25ca15f4d59c115e7c1"
>
> Initialising tasks: 100%
> |###|
> Time: 0:00:02
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> WARNING: lib32-my-image-1.0-r0 do_rootfs: lib32-systemd.postinst returned
> 1, marking as unpacked only, configuration required on target.
> WARNING: lib32-my-image-1.0-r0 do_rootfs: Intentionally failing
> postinstall scriptlets of ['lib32-systemd'] to defer them to first boot is
> deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
> If deferring to first boot wasn't the intent, then scriptlet failure may
> mean an issue in the recipe, or a regression elsewhere.
> Details of the failure are in
> /opt/build/poky/build/tmp/work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_rootfs.
> WARNING: lib32-my-image-1.0-r0 do_rootfs: [log_check] lib32-my-image:
> found 1 warning message in the logfile:
> [log_check] WARNING: Intentionally failing postinstall scriptlets of
> ['lib32-systemd'] to defer them to first boot is deprecated. Please place
> them into pkg_postinst_ontarget_${PN} ().
> ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
> lib32-gcc-runtime and gcc-runtime, aborting
> ERROR: lib32-my-image-1.0-r0 do_image_wic: Function failed:
> extend_recipe_sysroot
> ERROR: Logfile of failure stored in:
> /opt/build/poky/build/tmp/work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_image_wic.16922
> ERROR: Task
> (virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-core/images/my-image.bb:do_image_wic)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 3460 tasks of which 3445 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-core/images/my-image.bb:
> do_image_wic
> Summary: There were 3 WARNING messages shown.
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>
>
> The ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
> lib32-gcc-runtime and gcc-runtime, aborting is not self-explanatory!
>
> gcc-runtime is anyway not part of the image ?!
>
> any suggestions ?
>
>
> thank you
>
>
> Best regards
>
> On Thu, Jul 26, 2018 at 8:12 PM, Martin Jansa 
> wrote:
>
>> It's not as simple as that in some cases, there are some components which
>> are pulled in 64bit version even when building lib32-foo-image.
>>
>> Some are easy to override from the config e.g.:
>> ROOTFS_PKGMANAGE = "${LIB32_PREFIX}opkg"
>> SPLASH = "${LIB32_PREFIX}psplash"
>>
>> but to prevent building e.g. syslinux in 64bit version is a bit more
>> tricky.
>>
>> syslinux.bbclass was fixed long time ago:
>> c

Re: [yocto] Intel machine with 64 Bit kernel and 32 Bit user space

[Martin Jansa]

It's not as simple as that in some cases, there are some components which
are pulled in 64bit version even when building lib32-foo-image.

Some are easy to override from the config e.g.:
ROOTFS_PKGMANAGE = "${LIB32_PREFIX}opkg"
SPLASH = "${LIB32_PREFIX}psplash"

but to prevent building e.g. syslinux in 64bit version is a bit more tricky.

syslinux.bbclass was fixed long time ago:
commit c8dc421ea18bb7a810501ab6d07efa9c8f6d6eb9
Author: Ming Liu 
Date:   Thu Jun 19 16:42:58 2014 +0800

syslinux.bbclass: Ensure MLPREFIX is applied to depends flag

Add MLPREFIX to depends flag to ensure the correct syslinux is
dependended upon.

-do_bootimg[depends] += "syslinux:do_populate_sysroot \
+do_bootimg[depends] += "${MLPREFIX}syslinux:do_populate_sysroot \

but wic still depends on syslinux without MLPREFIX:

meta/conf/machine/qemux86-64.conf:do_image_wic[depends] +=
"syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
mtools-native:do_populate_sysroot dosfstools-nat...
meta/conf/machine/qemux86.conf:do_image_wic[depends] +=
"syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
mtools-native:do_populate_sysroot dosfstools-native...

similarly opkg-utils and some other components are pulled in the
not-prefixed version even when building image with a prefix. I've
eventually got it working with morty (that it was really building only
couple 64bit recipes, mostly kernel and recipes providing external modules
and e.g. depmodwrapper-cross), but it's kind of shaky and error prone, I'll
send fixes for some of these issues, but as we're using morty it's more
complicated to find out what is still needed and what was resolved in newer
OE already.

And there are the issues with allarch recipes mentioned in the other
multilib thread.

Regards,


On Thu, Jul 26, 2018 at 5:59 PM Mark Hatle  wrote:

> On 7/26/18 10:19 AM, Alexander Kanavin wrote:
> > 2018-07-26 14:56 GMT+02:00 Ayoub Zaki :
> >> Is it possible to define a MACHINE configuration with a 64 Bit kernel
> and 32
> >> Bit user space ?
> >>
> >> The user space should not be using a  x32 ABI.
> >
> > I think (but I am not sure), that you can do it with multilib. Define
> > a configuration like this:
> >
> https://github.com/openembedded/openembedded-core/blob/master/meta-skeleton/conf/multilib-example.conf
> >
> > Then build lib32-core-image-minimal. That image should include only 32
> > bit user space, but the kernel will be 64 bit.
>
> Yes this is the typical approach.  Enable multilibs, and then build the
> image
> you you want with the approach multilib prefix.
>
> This works in any multilib configurations, 64-bit, 32-bit, x32, etc..
>
> --Mark
>
> > Alex
> >
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error Report Tool Purge

[Martin Jansa]

OK, so it's only visited links, not linked from ML or wiki or whatever,
right?

How huge the database is? I've checked our internal instance and on
relatively slow VM we have:
47 472 724 Post_buildstatstask
2 715 091 Post_build
559 655 Post_buildfailure

we use postgresql, the db currently has 20GB, which is quite big for VM
with 10GB RAM and 12 E5-2699 cores so it's slow as well, but not terribly
slow, individual builds or build-failures are really fast, there are some
bad queries in django which are terrible, but we're not using those usually.

Cheers,


On Thu, Jul 19, 2018 at 9:01 PM Brindle, Amanda R <
amanda.r.brin...@intel.com> wrote:

> Every time a specific report is visited (with the end of the URL being
> /Errors/Details/), we are tracking if the referrer is another website,
> the reporting tool itself, or unknown. If the referrer is another website
> or unknown, then we won’t delete it.
>
>
>
> The purge script does not look at links to whole builds, so as it is right
> now, those would get deleted. If it’s common to link to whole builds,
> though, I can add something to the script to save reports from a visited or
> linked build.
>
>
>
> -Amanda Brindle
>
>
>
> *From:* Martin Jansa [mailto:martin.ja...@gmail.com]
> *Sent:* Thursday, July 19, 2018 11:38 AM
> *To:* Brindle, Amanda R 
> *Cc:* Yocto Project 
> *Subject:* Re: [yocto] Error Report Tool Purge
>
>
>
> I'm just curious, how are you tracking which reports were viewed or linked
> to (and linked from where)? I often use a link to
> http://errors.yoctoproject.org in the mailing list or the recipes/commit
> message instead of copy pasting whole build error, because it already
> shortens the build paths and shows useful additional information about the
> error.
>
>
>
> The links to whole builds on http://errors.yoctoproject.org were also
> often linked from "bitbake world status" e-mails and wiki like:
>
> https://www.openembedded.org/wiki/Bitbake_World_Status_Rocko
>
> and on many of them nobody clicked yet - should I expect that these will
> mostly get broken?
>
>
>
> Regards
>
>
>
>
>
>
>
> On Thu, Jul 19, 2018 at 8:30 PM Brindle, Amanda R <
> amanda.r.brin...@intel.com> wrote:
>
> Hello,
>
>
>
> The Error Reporting Tool’s database (
> http://errors.yoctoproject.org/Errors/Latest/Autobuilder/)  has grown to
> a huge size, and this is affecting the performance of the application. We
> are planning to run a purge to get rid of reports that we don’t need. We
> will keep reports from the last thirty days, as well as reports that have
> been viewed or linked to. If you have a specific report that you don’t want
> purged, please let me know by the end of the month.
>
>
>
> Amanda Brindle, Software Engineer
>
> 503-264-3970
>
> amanda.r.brin...@intel.com
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error Report Tool Purge

[Martin Jansa]

I'm just curious, how are you tracking which reports were viewed or linked
to (and linked from where)? I often use a link to
http://errors.yoctoproject.org in the mailing list or the recipes/commit
message instead of copy pasting whole build error, because it already
shortens the build paths and shows useful additional information about the
error.

The links to whole builds on http://errors.yoctoproject.org were also often
linked from "bitbake world status" e-mails and wiki like:
https://www.openembedded.org/wiki/Bitbake_World_Status_Rocko
and on many of them nobody clicked yet - should I expect that these will
mostly get broken?

Regards



On Thu, Jul 19, 2018 at 8:30 PM Brindle, Amanda R <
amanda.r.brin...@intel.com> wrote:

> Hello,
>
>
>
> The Error Reporting Tool’s database (
> http://errors.yoctoproject.org/Errors/Latest/Autobuilder/)  has grown to
> a huge size, and this is affecting the performance of the application. We
> are planning to run a purge to get rid of reports that we don’t need. We
> will keep reports from the last thirty days, as well as reports that have
> been viewed or linked to. If you have a specific report that you don’t want
> purged, please let me know by the end of the month.
>
>
>
> Amanda Brindle, Software Engineer
>
> 503-264-3970
>
> amanda.r.brin...@intel.com
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bbappend extra SRC_URI ignored

[Martin Jansa]

See ./recipes-bsp/tegra-binaries/tegra-shared-binaries.inc

It's disabling standard do_fetch, do_unpack, do_patch and replacing them
with tegra-binaries:do_unpack tegra-binaries:do_preconfigure which populates
S directory in work-shared
S = "${TMPDIR}/work-shared/L4T-${SOC_FAMILY}-${PV}-${PR}/Linux_for_Tegra"

so basically you need to add it in tegra-binaries recipe (not tegra-tools).

On Thu, Jun 14, 2018 at 3:22 PM Damien LEFEVRE  wrote:

>
> Thanks
>
> Here are some interesting parts of bitbake -e. It seems my syntax is
> correct
>
>
> # $FILESEXTRAPATHS [3 operations]
> #   set? /home/damien/procbox-pyro/sources/poky/meta/conf/bitbake.conf:325
> # "__default:"
> #   set
> /home/damien/procbox-pyro/sources/poky/meta/conf/documentation.conf:173
> # [doc] "Extends the search path the OpenEmbedded build system uses
> when looking for files and patches as it processes recipes and append
> files."
> #   _prepend[tegra186]
> /home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bbappend:1
> #
>  
> "/home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186:"
> # pre-expansion value:
> #
> "/home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186
> :__default:"
> FILESEXTRAPATHS="
> /home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0/tegra186
> :__default:"
>
> #
> # $SRC_URI [10 operations]
> .
> # "file://nvcamera-daemon.init file://nvcamera-daemon.service
>file://argus-daemon.init file://argus-daemon.service
>  file://nvstartup.init file://nvstartup.service "
> #   _append[tegra186]
> /home/damien/procbox-pyro/sources/meta-tegra/recipes-bsp/tegra-binaries/tegra-binaries-28.2.0.inc:19
> # " file://tegra186-flash-helper.sh file://nvpmodel.init
>  file://nvpmodel.service "
> #   set
> /home/damien/procbox-pyro/sources/meta-tegra/recipes-bsp/tegra-binaries/tegra-shared-binaries.inc:8
> # ""
> #   _prepend[tegra186]
> /home/damien/procbox-pyro/sources/meta-procbox/meta-tegra/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bbappend:2
> # "file://nvpmodel.conf "
> #   set tegra-binaries-28.2.0.inc:42
> [__anon_46__home_damien_procbox_pyro_sources_meta_tegra_recipes_bsp_tegra_binaries_tegra_binaries_28_2_0_inc]
> # [md5sum] "22bbd0002db06bb26bf5de2d17cea8eb"
> #   set tegra-binaries-28.2.0.inc:43
> [__anon_46__home_damien_procbox_pyro_sources_meta_tegra_recipes_bsp_tegra_binaries_tegra_binaries_28_2_0_inc]
> # [sha256sum]
> "62f57b4c03fedde1fe0a1635bd0828b334308eca71bd21f25ae5757f48fb3a76"
> # pre-expansion value:
> #   "file://nvpmodel.conf  file://tegra186-flash-helper.sh
>  file://nvpmodel.init file://nvpmodel.service "
> SRC_URI="file://nvpmodel.conf  file://tegra186-flash-helper.sh
>  file://nvpmodel.init file://nvpmodel.service "
>
> Then no other mentions until the do_install
>
> Yet the nvpmodel.conf is never copied to ${WORKDIR} which
> is 
> /home/damien/procbox-pyro/build-jetson-tx2/tmp/work/aarch64_tegra186-poky-linux/tegra-tools/28.2.0-r0
> in my case.
>
> Could some bitbake options disable this standard behavior?
>
> On Thu, Jun 14, 2018 at 3:33 PM, Martin Jansa 
> wrote:
>
>> On Thu, Jun 14, 2018 at 03:16:00PM +0300, Damien LEFEVRE wrote:
>> > HI,
>> >
>> > I'm working on meta-tegra layer and I'd like to append a recipe. The
>> > original recipe looks like this:
>> >
>> https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb
>> > <
>> https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb
>> >
>> >
>> > I've made a tegra-tools_28.2.0.bbappend to change the default PM_CONFIG
>> > DEFAULT from 2 to 3 to get max performance in nvpmodel.conf
>> configuration
>> > file.
>> >
>> > ```
>> > FILESEXTRAPATHS_prepend := "${THISDIR}/files/tegra186:"
>> > SRC_URI_prepend_tegra186 += "file://nvpmodel.conf "
>> >
>> > do_install_append_tegra186() {
>> > install -d ${D}${sysconfdir}
>> > install -m 0755 ${B}/usr/sbin/nvpmodel ${D}${sbindir}/
>> > install -m 0644 ${WORKDIR}/nvpmodel.conf
>> ${D}${sysconfdir}/nvpmodel.conf
>> > install -d ${D}${sysconfdir}/init.d
>> > install -m 0644 ${S}/nvpmodel.init ${D}${sysconfd

Re: [yocto] bbappend extra SRC_URI ignored

[Martin Jansa]

On Thu, Jun 14, 2018 at 03:16:00PM +0300, Damien LEFEVRE wrote:
> HI,
> 
> I'm working on meta-tegra layer and I'd like to append a recipe. The
> original recipe looks like this:
> https://github.com/madisongh/meta-tegra/blob/rocko-l4t-r28.2/recipes-bsp/tegra-binaries/tegra-tools_28.2.0.bb
> 
> 
> I've made a tegra-tools_28.2.0.bbappend to change the default PM_CONFIG
> DEFAULT from 2 to 3 to get max performance in nvpmodel.conf configuration
> file.
> 
> ```
> FILESEXTRAPATHS_prepend := "${THISDIR}/files/tegra186:"
> SRC_URI_prepend_tegra186 += "file://nvpmodel.conf "
> 
> do_install_append_tegra186() {
> install -d ${D}${sysconfdir}
> install -m 0755 ${B}/usr/sbin/nvpmodel ${D}${sbindir}/
> install -m 0644 ${WORKDIR}/nvpmodel.conf ${D}${sysconfdir}/nvpmodel.conf
> install -d ${D}${sysconfdir}/init.d
> install -m 0644 ${S}/nvpmodel.init ${D}${sysconfdir}/init.d/nvpmodel
> install -d ${D}${systemd_system_unitdir}
> install -m 0644 ${S}/nvpmodel.service ${D}${systemd_system_unitdir}
> }
> ```
> Would you have any idea why the nvpmodel.conf prepend is ignored and the
> file never ends up in ${WORKDIR}.
> 
> I've made sure the paths are correct. nvpmodel.conf exists and if I put a
> typo like nvpmodel.conf_blabla bitbake throws a warning that it cannot find
> the file. So I'm sure the file is found but somehow bitbake ignores it.
> 
> I'm having this issue with this one single recipe only, none of the others
> in my build system so I'm a bit puzzled.

Always use bitbake -e to verify that the file://nvpmodel.conf ends where
you expect it to end (and if it doesn't the history will show you why
not).

> 
> Thanks,
> -Damien

> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

> That leaves only few issues in our internal components and strange failure 
> with perf which fails to include various header files:
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal 
> error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal 
> error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal 
> error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal 
> error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal 
> error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal 
> error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal 
> error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal 
> error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal 
> error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal 
> error: ../../../../include/uapi/linux/swab.h: No such file or directory
> perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56:
>  error: #include nested too deeply
> perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include/../../../../include/asm-generic/bitops/fls.h:1:56:
>  error: #include nested too deeply
> ...

This issue wasn't caused by gcc upgrade, it was caused by:
https://patchwork.openembedded.org/patch/150269/
which was included in the same batch of updates when I've included
these RFT changes.

I've sent separate fix for perf with slightly longer explanation what
was wrong:
https://patchwork.openembedded.org/patch/151017/

Now I got a bit further with testing again, remaining 3 issues in public
recipes:

gcc-sanitizers/8.1.0-r0 fails to build with qemuarm (with thumb
enabled):
{standard input}: Assembler messages:
{standard input}:5724: Error: lo register required -- `ldr ip,[sp],#8'
make[2]: *** [sanitizer_linux.lo] Error 1

qtbase/5.6.3+gitAUTOINC+e6f8b072d2-r0 fails to build with qemuarm (with
thumb
enabled):
{standard input}: Assembler messages:
{standard input}: Error: unaligned opcodes detected in executable segment
make[2]: *** [.obj/qdrawhelper.o] Error 1

lib32-glibc-initial/2.27-r0 fails to build with multilib
checking installed Linux kernel header files... missing or too old!
configure: error: GNU libc requires kernel header files from
Linux 3.2.0 or later to be installed before configuring.
The kernel header files are found 

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Thu, May 10, 2018 at 09:11:45PM +0200, Martin Jansa wrote:
> > > 5) nativesdk-libxcrypt fails to build (not sure which change caused 
> > > this, it build OK with sumo since the -std=gnu99 addition.
> > > ../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated 
> > > before the last format character [-Werror=format-truncation=]
> > >               "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
> > >               ^~~
> > > 
> > 
> > something new, I will look into reproducing this.

The fix from you worked for me, thanks!

> > > I didn't get very far in testing, because our old kernel fails to build 
> > > with gcc8 and there are some other issues caused by other master 
> > > changes. But it doesn't look too bad (in my small test, lets see what 
> > > bitbake world will show), thanks a lot for new gcc.
> > > 
> > 
> > yes, older kernel needs fixes, especially to disable new warnings.
> > the mips/ppc fixes that I put out there might be helpful to cook up 
> > fixes for older kernels if running into same issues.
> 
> In this case it fails with Error: .err encountered for many drivers. It's not 
> the same case as in:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325615.html
> nor arm version of this change, both are already applied in our
> 4.4.3 based kernel.
> 
> I've tried to reproduce with vanilla 4.4.143 and it doesn't fail like this, 
> vanilla 4.4.3 doesn't
> fail, so it's caused by one of our 1 commits on top of 4.4.3 or the 
> config, need to dig a bit more.

Just FYI if someone needs similar fix, backporting this:
https://patchwork.kernel.org/patch/9170055/

fixed the issue for me, now I have successful kernel build.

The failing code was always in put_user calls, e.g. kernel/exit.s was showing:
@ 1581 "kernel-source/kernel/exit.c" 1
.ifnc r0,r0; .ifnc r0r0,fpr11; .ifnc r0r0,r11fp; .ifnc r0r0,ipr12; 
.ifnc r0r0,r12ip; .err; .endif; .endif; .endif; .endif; .endif
.ifnc r5,r2; .ifnc r5r2,fpr11; .ifnc r5r2,r11fp; .ifnc r5r2,ipr12; 
.ifnc r5r2,r12ip; .err; .endif; .endif; .endif; .endif; .endif
.ifnc r1,r1; .ifnc r1r1,fpr11; .ifnc r1r1,r11fp; .ifnc r1r1,ipr12; 
.ifnc r1r1,r12ip; .err; .endif; .endif; .endif; .endif; .endif
bl  __put_user_4
@ 0 "" 2

with the error triggered on the middle line.
/tmp/ccHq8ugv.s: Assembler messages:
/tmp/ccHq8ugv.s:1179: Error: .err encountered
/tmp/ccHq8ugv.s:1331: Error: .err encountered
/tmp/ccHq8ugv.s:4617: Error: .err encountered
/tmp/ccHq8ugv.s:6222: Error: .err encountered
/tmp/ccHq8ugv.s:8705: Error: .err encountered
/tmp/ccHq8ugv.s:14486: Error: .err encountered
/tmp/ccHq8ugv.s:14646: Error: .err encountered
/tmp/ccHq8ugv.s:14806: Error: .err encountered
/tmp/ccHq8ugv.s:14966: Error: .err encountered
/tmp/ccHq8ugv.s:15126: Error: .err encountered
/tmp/ccHq8ugv.s:15286: Error: .err encountered

That leaves only few issues in our internal components and strange failure with 
perf which fails to include various header files:
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: 
../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: 
../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: 
../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28:
 error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26:
 error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25:
 error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41:
 error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: 
../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/asm/byteorder.h:2:10: fatal error: 
../../../../include/uapi/linux/swab.h: No such file or directory
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28:
 error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:2:26:
 error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:3:25:
 error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:5:41:
 error: #include nested too deeply
perf/1.0-r9/perf-1.0/tools/perf/util/include/../../../include/linux/list.h:1:28:
 error: #include nested too deep

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Mon, May 14, 2018 at 10:33:41AM -0600, Dan McGregor wrote:
> On 10 May 2018 at 12:53, Khem Raj  wrote:
> > Hi Dan,
> >
> > Thanks for testing
> >
> > On 5/10/18 7:34 AM, Dan McGregor wrote:
> >>
> >> On 4 May 2018 at 18:26, Khem Raj  wrote:
> >>>
> >>> Hi All
> >>>
> >>> As you might have noticed that gcc 8.1 was released this week, I am
> >>> calling out for some testing help on testing branch so we can weed out
> >>> issues you might see in your setups. so if you have your
> >>> builders idling over weekend, then you know what they can do this weekend
> >>> :)
> >>>
> >>
> >> Thanks for this. The only two issues I noticed are that the
> >> Wandboard's kernel doesn't compile with gcc 8.1,
> >
> >
> >
> > what errors do you see ?
> 
> I expect the standard "Linux 4.1" errors. A bunch of ignored
> attributes and incompatible type aliases:
> 
> tmp-glibc/work-shared/wandboard/kernel-source/include/linux/log2.h:22:1:
> warning: ignoring attribute 'noreturn' because it conflicts with
> attribute 'const' [-Wattributes]
>  int ilog2_NaN(void)

Try backporting this change:
https://github.com/torvalds/linux/commit/474c90156c8dcc2fa815e6716cc9394d7930cb9c

> tmp-glibc/work-shared/wandboard/kernel-source/include/linux/syscalls.h:195:18:
> warning: 'sys_clone' alias between functions of incompatible types
> 'long int(long unsigned int,  long unsigned int,  int *, int,  int *)'
> and 'long int(long int,  long int,  long int,  long int,  long int)'
> [-Wattribute-alias]
>   asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
> 
> I can give you the full compile log if you'd like, but I think others
> want it kept off the list.
> 
> >
> >  and gcc-sanitizers
> >>
> >> now throws a packaging error on (at least) x86_64.
> >> ${libdir}/liblsan_preinit.o is a new file that should go into
> >> liblsan-dev.
> >
> >
> > That seems to be the case, I wonder why my world build for qemux86_64 did
> > not find this error. I would like to reproduce this and the fix is then
> > simple.
> 
> My x86_64 build was multilib enabled. I doubt that had anything to do
> with it, but I suppose it's possible.
> 
> >
> >
> >>
> >>> Highlighted changes are
> >>>
> >>> https://gcc.gnu.org/gcc-8/changes.html
> >>>
> >>> and porting doc is
> >>>
> >>> https://gcc.gnu.org/gcc-8/porting_to.html
> >>>
> >>> The branch is here
> >>>
> >>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
> >>>
> >>> Its uptodate on top of current master oe-core
> >>>
> >>> May fourth be with you !!
> >>>
> >>> Cheers!
> >>>
> >>> -Khem
> >>> --
> >>> ___
> >>> Openembedded-core mailing list
> >>> openembedded-c...@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -- 
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
> > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
> >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.ja...@gmail.com> 
> >> wrote:
> >> > see
> >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
> >>
> >> Removing -fno-omit-frame-pointer isn't the same as adding
> >> -fomit-frame-pointer. Frame pointers may get enabled depending on the
> >> optimisation level etc (ie not only by -fno-omit-frame-pointer).
> >
> > Should I send v2 adding -fomit-frame-pointer instead of removing
> > -fno-omit-frame-pointer?
> >
> > The v1 fixes the issue for me with default config + DEBUG_BUILD.
> 
> The v1 patch isn't wrong, it's just incomplete (the problem could come
> back if someone changes optimisation level or switches gcc to clang,
> etc).
> 
> My choice would be a v2 patch which adds -fomit-frame-pointer to
> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
> should fix the problem for all optimisation levels etc and avoids
> building the main strace binary differently depending on whether or
> not ptest is enabled.

Only for thumb? makes me a bit sad that thumb override was dropped by
you in
351443d71eb246a946b41f12b54d57b36fe1574e

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
> > see
> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
> 
> Removing -fno-omit-frame-pointer isn't the same as adding
> -fomit-frame-pointer. Frame pointers may get enabled depending on the
> optimisation level etc (ie not only by -fno-omit-frame-pointer).

Should I send v2 adding -fomit-frame-pointer instead of removing
-fno-omit-frame-pointer?

The v1 fixes the issue for me with default config + DEBUG_BUILD.

> > On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccu...@gmail.com> wrote:
> >>
> >> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.ja...@gmail.com>
> >> wrote:
> >> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
> >> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> >> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa
> >> >> > <martin.ja...@gmail.com> wrote:
> >> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> >> >> > >> Hi Martin
> >> >> > >>
> >> >> > >> Thanks for testing and reporting back
> >> >> > >>
> >> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> >> >> > >> > My initial tests show couple issues, but usually caused by other
> >> >> > >> > changes
> >> >> > >> > in that branch, not the gcc-8 itself.
> >> >> > >> >
> >> >> > >> > 1) strace-4.22 from
> >> >> > >> >
> >> >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=af33a8b721cc9caebd3f5226b4c5903f666ab654
> >> >> > >> > fails to build with ptest enabled (it builds with 4.20 version
> >> >> > >> > if I
> >> >> > >> > revert this change)
> >> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> >> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be
> >> >> > >> > used in
> >> >> > >> > asm here
> >> >> > >> >   }
> >> >> > >> >   ^
> >> >> > >>
> >> >> > >> are you targeting thumb1 ? how can I reproduce it ?
> >> >> > >
> >> >> > > I'm trying to find out what's different in the builds where it was
> >> >> > > failing, will provide more info later.
> >> >> >
> >> >> > This is probably due to making an inline syscall from Thumb (doesn't
> >> >> > a
> >> >> > matter Thumb1 or Thumb2) with frame pointers enabled.
> >> >> >
> >> >> > Does adding -fomit-frame-pointer to CFLAGS fix it?
> >> >>
> >> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
> >> >> already -fno-omit-frame-pointer in the default command line for it,
> >> >> adding -fomit-frame-pointer at the end fixes it:
> >> >>
> >> >> docker-lge @
> >> >> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
> >> >> $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4
> >> >> -mfloat-abi=hard -mcpu=cortex-a7
> >> >> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
> >> >> -DHAVE_CONFIG_H-I. -I../linux/arm -I../../strace-4.22/linux/arm
> >> >> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22
> >> >> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body
> >> >> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 
> >> >> -Winit-self
> >> >> -Wlogical-op -Wmissing-parameter-type -Wnested-externs
> >> >> -Wold-style-declaration -Wold-style-definition -Wsign-compare 
> >> >> -Wtype-limits
> >> >> -Wwrite-strings -O -fno-omit-frame-pointer -g 
> >> >> -feliminate-unused-debug-types
> >> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
> >> 

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

see
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccu...@gmail.com> wrote:

> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.ja...@gmail.com>
> wrote:
> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <
> martin.ja...@gmail.com> wrote:
> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> >> > >> Hi Martin
> >> > >>
> >> > >> Thanks for testing and reporting back
> >> > >>
> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> >> > >> > My initial tests show couple issues, but usually caused by other
> changes
> >> > >> > in that branch, not the gcc-8 itself.
> >> > >> >
> >> > >> > 1) strace-4.22 from
> >> > >> >
> http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=af33a8b721cc9caebd3f5226b4c5903f666ab654
> >> > >> > fails to build with ptest enabled (it builds with 4.20 version
> if I
> >> > >> > revert this change)
> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be
> used in
> >> > >> > asm here
> >> > >> >   }
> >> > >> >   ^
> >> > >>
> >> > >> are you targeting thumb1 ? how can I reproduce it ?
> >> > >
> >> > > I'm trying to find out what's different in the builds where it was
> >> > > failing, will provide more info later.
> >> >
> >> > This is probably due to making an inline syscall from Thumb (doesn't a
> >> > matter Thumb1 or Thumb2) with frame pointers enabled.
> >> >
> >> > Does adding -fomit-frame-pointer to CFLAGS fix it?
> >>
> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
> >> already -fno-omit-frame-pointer in the default command line for it,
> >> adding -fomit-frame-pointer at the end fixes it:
> >>
> >> docker-lge @
> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
> $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4
> -mfloat-abi=hard -mcpu=cortex-a7
> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
> -DHAVE_CONFIG_H-I. -I../linux/arm -I../../strace-4.22/linux/arm
> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22
> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body
> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self
> -Wlogical-op -Wmissing-parameter-type -Wnested-externs
> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits
> -Wwrite-strings -O -fno-omit-frame-pointer -g
> -feliminate-unused-debug-types
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
> -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c
> -fomit-frame-pointer
> >>
> >> This might come from:
> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer
> ${DEBUG_FLAGS} -pipe"
> >> because in this build I had DEBUG_BUILD enabled.
> >>
> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as
> well now.
> >
> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> > 4.22:
> >
> >
> https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
> >
> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> > when ptest is in DISTRO_FEATURES acceptable solution?
>
> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
> all builds is OK (strace is a debug tool - not something that
> generally needs to be debugged and frame pointers aren't essential for
> debugging anyway).
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.ja...@gmail.com> 
> > wrote:
> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> > >> Hi Martin
> > >>
> > >> Thanks for testing and reporting back
> > >>
> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> > >> > My initial tests show couple issues, but usually caused by other 
> > >> > changes
> > >> > in that branch, not the gcc-8 itself.
> > >> >
> > >> > 1) strace-4.22 from
> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=af33a8b721cc9caebd3f5226b4c5903f666ab654
> > >> > fails to build with ptest enabled (it builds with 4.20 version if I
> > >> > revert this change)
> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
> > >> > asm here
> > >> >   }
> > >> >   ^
> > >>
> > >> are you targeting thumb1 ? how can I reproduce it ?
> > >
> > > I'm trying to find out what's different in the builds where it was
> > > failing, will provide more info later.
> > 
> > This is probably due to making an inline syscall from Thumb (doesn't a
> > matter Thumb1 or Thumb2) with frame pointers enabled.
> > 
> > Does adding -fomit-frame-pointer to CFLAGS fix it?
> 
> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
> already -fno-omit-frame-pointer in the default command line for it,
> adding -fomit-frame-pointer at the end fixes it:
> 
> docker-lge @ 
> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
>  $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 
> -mfloat-abi=hard -mcpu=cortex-a7 
> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
>  -DHAVE_CONFIG_H-I. -I../linux/arm -I../../strace-4.22/linux/arm 
> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 
> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body 
> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self 
> -Wlogical-op -Wmissing-parameter-type -Wnested-externs 
> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits 
> -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types 
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
>  
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
>  
> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
>   -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c 
> -fomit-frame-pointer
> 
> This might come from:
> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer 
> ${DEBUG_FLAGS} -pipe"
> because in this build I had DEBUG_BUILD enabled.
> 
> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well 
> now.

4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
4.22:

https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1

What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
when ptest is in DISTRO_FEATURES acceptable solution?

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
> On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
> > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> >> Hi Martin
> >>
> >> Thanks for testing and reporting back
> >>
> >> On 5/9/18 2:38 AM, Martin Jansa wrote:
> >> > My initial tests show couple issues, but usually caused by other changes
> >> > in that branch, not the gcc-8 itself.
> >> >
> >> > 1) strace-4.22 from
> >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=af33a8b721cc9caebd3f5226b4c5903f666ab654
> >> > fails to build with ptest enabled (it builds with 4.20 version if I
> >> > revert this change)
> >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
> >> > asm here
> >> >   }
> >> >   ^
> >>
> >> are you targeting thumb1 ? how can I reproduce it ?
> >
> > I'm trying to find out what's different in the builds where it was
> > failing, will provide more info later.
> 
> This is probably due to making an inline syscall from Thumb (doesn't a
> matter Thumb1 or Thumb2) with frame pointers enabled.
> 
> Does adding -fomit-frame-pointer to CFLAGS fix it?

It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
already -fno-omit-frame-pointer in the default command line for it,
adding -fomit-frame-pointer at the end fixes it:

docker-lge @ 
~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
 $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 
-mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
 -DHAVE_CONFIG_H-I. -I../linux/arm -I../../strace-4.22/linux/arm -I../linux 
-I../../strace-4.22/linux -I.. -I../../strace-4.22 
-DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body 
-Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self 
-Wlogical-op -Wmissing-parameter-type -Wnested-externs -Wold-style-declaration 
-Wold-style-definition -Wsign-compare -Wtype-limits -Wwrite-strings -O 
-fno-omit-frame-pointer -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
 
-fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
 
-fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
  -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c 
-fomit-frame-pointer

This might come from:
meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer 
${DEBUG_FLAGS} -pipe"
because in this build I had DEBUG_BUILD enabled.

Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well 
now.

Thanks for pointers.

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
> Hi Martin
> 
> Thanks for testing and reporting back
> 
> On 5/9/18 2:38 AM, Martin Jansa wrote:
> > My initial tests show couple issues, but usually caused by other changes 
> > in that branch, not the gcc-8 itself.
> > 
> > 1) strace-4.22 from 
> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=af33a8b721cc9caebd3f5226b4c5903f666ab654
> > fails to build with ptest enabled (it builds with 4.20 version if I 
> > revert this change)
> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in 
> > asm here
> >   }
> >   ^
> 
> are you targeting thumb1 ? how can I reproduce it ?

I'm trying to find out what's different in the builds where it was
failing, will provide more info later.

> > Makefile:6313: recipe for target 'inject-nf.o' failed
> > make: *** [inject-nf.o] Error 1
> > make: Leaving directory 'strace/4.22-r0/build/tests'
> > 
> > 2) glibc with obsolete rpc disabled from: 
> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=0cd820424d4bdb5cc68e7503e09a0359fd21150a
> > causes busybox's mount applet to fail building:
> > util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
> >   # include 
> >             ^~~
> > compilation terminated.
> > make[1]: *** [util-linux/mount.o] Error 1
> > make: *** [util-linux] Error 2
> 
> I think you sent a patch already for this so discussion for fix are on 
> going.
> 
> > 
> > 3) grub and grub-efi fails to build with gcc8:
> > In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
> > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
> > ../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of 
> > 'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > ..
> > ../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct 
> > grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
> >   } GRUB_PACKED;
> >   ^
> > 
> 
> I think we need to align end of these structs here, can you try
> https://src.fedoraproject.org/rpms/grub2/raw/master/f/0198-align-struct-efi_variable-better.patch

I've sent fix as well:
http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150587.html
it's in master-next already.

> > 4) iotivity fails to build with gcc8:
> > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:
> >  
> > In lambda function:
> > service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30:
> >  
> > error: 'value' is not captured
> >                   ocRep[KEY] = value;
> >                                ^
> > 
> 
> this needs more investigation. May be move
> https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L160
> 
> just above
> https://github.com/iotivity/iotivity/blob/master/service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp#L165

There are more issues in iotivity:
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 
'void* memcpy(void*, const void*, size_t)' writing to an object of type 
'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct 
rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use 
copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635:24: error: 
'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class 
rapidjson::GenericValue<rapidjson::UTF8<> >' with no trivial copy-assignment; 
use copy-assignment or copy-initi
alization instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1647:24: error: 
'void* memcpy(void*, const void*, size_t)' writing to an object of type 
'rapidjson::GenericValue<rapidjson::UTF8<> >::Member' {aka 'struct 
rapidjson::GenericMember<rapidjson::UTF8<>, rapidjs
on::MemoryPoolAllocator<> >'} with no trivial copy-assignment; use 
copy-assignment instead [-Werror=class-memaccess]
+extlibs/rapidjson/rapidjson/include/rapidjson/document.h:1635

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Martin Jansa]

My initial tests show couple issues, but usually caused by other changes in
that branch, not the gcc-8 itself.

1) strace-4.22 from
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=af33a8b721cc9caebd3f5226b4c5903f666ab654
fails to build with ptest enabled (it builds with 4.20 version if I revert
this change)
../../strace-4.22/tests/inject-nf.c: In function 'main':
../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in asm
here
 }
 ^
Makefile:6313: recipe for target 'inject-nf.o' failed
make: *** [inject-nf.o] Error 1
make: Leaving directory 'strace/4.22-r0/build/tests'

2) glibc with obsolete rpc disabled from:
http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=0cd820424d4bdb5cc68e7503e09a0359fd21150a
causes busybox's mount applet to fail building:
util-linux/mount.c:252:11: fatal error: rpc/rpc.h: No such file or directory
 # include 
   ^~~
compilation terminated.
make[1]: *** [util-linux/mount.o] Error 1
make: *** [util-linux] Error 2

3) grub and grub-efi fails to build with gcc8:
In file included from ../grub-2.02/grub-core/partmap/gpt.c:26:
../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of
'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
In file included from ../grub-2.02/grub-core/disk/ldm.c:26:
../grub-2.02/include/grub/gpt_partition.h:79:1: error: alignment 1 of
'struct grub_gpt_partentry' is less than 8 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^
..
../grub-2.02/grub-core/fs/btrfs.c:186:1: error: alignment 1 of 'struct
grub_btrfs_inode' is less than 4 [-Werror=packed-not-aligned]
 } GRUB_PACKED;
 ^

4) iotivity fails to build with gcc8:
service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:
In lambda function:
service/resource-encapsulation/src/common/primitiveResource/unittests/PrimitiveResourceTest.cpp:164:30:
error: 'value' is not captured
 ocRep[KEY] = value;
  ^

5) nativesdk-libxcrypt fails to build (not sure which change caused this,
it build OK with sumo since the -std=gnu99 addition.
../git/crypt-sunmd5.c:189:13: error: 'snprintf' output may be truncated
before the last format character [-Werror=format-truncation=]
 "$" CRYPT_ALGNAME "," ROUNDS "%u$%s$",
 ^~~

6) couple internal components which usually fail to build with gcc8,
because of more strict warnings + Werror.

I didn't get very far in testing, because our old kernel fails to build
with gcc8 and there are some other issues caused by other master changes.
But it doesn't look too bad (in my small test, lets see what bitbake world
will show), thanks a lot for new gcc.

Cheers,





On Sat, May 5, 2018 at 2:26 AM, Khem Raj  wrote:

> Hi All
>
> As you might have noticed that gcc 8.1 was released this week, I am
> calling out for some testing help on testing branch so we can weed out
> issues you might see in your setups. so if you have your
> builders idling over weekend, then you know what they can do this weekend
> :)
>
> Highlighted changes are
>
> https://gcc.gnu.org/gcc-8/changes.html
>
> and porting doc is
>
> https://gcc.gnu.org/gcc-8/porting_to.html
>
> The branch is here
>
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/gcc-8
>
> Its uptodate on top of current master oe-core
>
> May fourth be with you !!
>
> Cheers!
>
> -Khem
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Is the a reason for adding the + to SRCPV?

[Martin Jansa]

This might help you:
https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-core/glib-2.0/glib-2.0/0002-gdbus-codegen-also-replace-character-with-underscore.patch

On Wed, Apr 11, 2018 at 5:59 PM, Måns Zigher  wrote:

> Hi,
>
> Thanks for your help. It is a cmake project in which they have specified a
> custom command calling gdbus-codegen. It definitely looks like they are
> passing the absolute path to it thanks for the help I think I can solve
> that.
>
> Br
> Mans Zigher
>
> On Apr 11, 2018 15:50, "Burton, Ross"  wrote:
>
> There is no "dbus codegen".  dbus-glib has a code generator but that
> doesn't write include guards like that, so it must be something else.
> gdbus-codegen appears to be doing the right thing to unless it breaks
> if you pass it an absolute path?
>
>
> Ross
>
>
> On 11 April 2018 at 10:12, Måns Zigher  wrote:
> > I believe dbus codegen is the tools generating the code.
> >
> > Br
> > Mans Zigher
> >
> > On Tue, Apr 10, 2018, 14:44 Burton, Ross  wrote:
> >>
> >> What tool is generating the code?  It probably shouldn't be using the
> >> full path of the header...
> >>
> >> Ross
> >>
> >> On 10 April 2018 at 09:29, Måns Zigher  wrote:
> >> > Hi,
> >> >
> >> > I am having some problems with one of my recipes when using the SRCPV
> >> > the
> >> > get_srcrev is returning "AUTOINC+" + rev. This will cause problem in
> my
> >> > compile because I am using dbus codegen and it looks like the
> >> > auto-generated
> >> > code cannot handle the + sign in the paths. Is there a reason for
> this +
> >> > sign. The generated code that causes my build to fail looks like this
> >> >
> >> > #ifndef
> >> >
> >> > ___HOME_EXTZIG_WORKSPACE_MOZART_MOZART_WORKSPACE_
> BUILDS_MOZART_RASPBERRYPI_BUILD_TMP_WORK_CORTEXA7HF_
> NEON_VFPV4_MOZART_LINUX_GNUEABI_MOZART_DAEMON_1_0_
> GITAUTOINC+8FD4C803AE_R3_GIT_SRC_LIBS_MOZART_BLE_SETUP_
> CODEGEN_ORG_BLUEZ_LE_ADVERTISEMENT_INTERFACE_H__
> >> >
> >> > Currently the only way for me to get the build to work is not use the
> >> > SRCPV.
> >> > Could it actually be a better way then using the + sign or is there a
> >> > logical requirement for it?
> >> >
> >> > BR
> >> > Mans Zigher
> >> >
> >> > --
> >> > ___
> >> > yocto mailing list
> >> > yocto@yoctoproject.org
> >> > https://lists.yoctoproject.org/listinfo/yocto
> >> >
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-qt3][PATCH 1/2] layer: add LAYERSERIES_COMPAT

[Martin Jansa]

On Fri, Apr 13, 2018 at 03:41:26PM -0700, Armin Kuster wrote:
> Signed-off-by: Armin Kuster 
> ---
>  conf/layer.conf | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/conf/layer.conf b/conf/layer.conf
> index 84ab5f7..2100ffb 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -8,3 +8,4 @@ BBFILE_COLLECTIONS += "qt3"
>  BBFILE_PATTERN_qt3 = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_qt3 = "6"
>  
> +LAYERSERIES_COMPAT_qt3-layer = "rocko"

Shouldn't this be just qt3 like BBFILE_* variables above?

Regards,

> -- 
> 2.7.4
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Getting the version of Yocto that is being used.

[Martin Jansa]

Cannot LAYERSERIES_CORENAMES added in rocko be used for that?

On Thu, Apr 12, 2018 at 2:47 PM, Burton, Ross  wrote:

> I think the message here is that we need to embed the oe-core version
> in the metadata somewhere...
>
> On 12 April 2018 at 13:11, Richard Collins
>  wrote:
> > I get the following for DISTRO.
> >
> > DISTRO= "yogurt"
> > DISTRO_VERSION= "BSP-Yocto-RK3288-PD17.1.1"
> >
> > Can't find any reference to yogurt so I assume this is something the
> > supplier of our SOM's has done. Looking on their Wiki it seems to be
> based
> > on 2.1.2 (Krogoth)
> >
> >
> > Thanks for the help. :)
> >
> > On 12 April 2018 at 11:21, Alexander Kanavin
> >  wrote:
> >>
> >> On 04/12/2018 12:44 PM, Richard Collins wrote:
> >>>
> >>> I've inherited a Yocto project that I know to be an old version. So one
> >>> of my tasks is to update to the latest version. Before I do this I
> would
> >>> like to know what version I have. The only information I can find is
> the
> >>> bitbake version, BB_VERSION= "1.32.0".
> >>
> >>
> >> When you run bitbake, it should also print the values of DISTRO and
> >> DISTRO_VERSION. Those should give a clue where you are at.
> >>
> >> Alex
> >
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH] layer.conf: add LAYERSERIES_COMPAT

[Martin Jansa]

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 conf/layer.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/conf/layer.conf b/conf/layer.conf
index f5601bb..3d614dc 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -13,3 +13,5 @@ BBFILE_PRIORITY_gplv2 = "1"
 LAYERVERSION_gplv2 = "1"
 
 LAYERDEPENDS_gplv2 = "core"
+
+LAYERSERIES_COMPAT_gplv2 = "sumo"
-- 
2.15.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to disable module auto-loading

[Martin Jansa]

On Tue, Mar 27, 2018 at 10:18:28AM +0200, Nicolas Salmin wrote:
> Hello all,
> 
> I would like to know the better way to disable module auto-loading ?
> 
> I tried to create /etc/modprobe.d/blacklist.conf but as /etc/modprobe.d
> doesn't exist on my rootfs i think is not a good solution.
> 
> I have tested also with  *KERNEL_MODULE_AUTOLOAD -= "module.name
> "* and
> *KERNEL_MODULE_AUTOLOAD_remove = "module.name "*
> 
> Last solution will be pass *modprobe.blacklist=module.name
> * in cmd line.
> 
> So in your opinion, which is the better way to do that ?

KERNEL_MODULE_AUTOLOAD_remove should work, check with bitbake -e to
confirm that it was correctly applied.

It's also possible to blacklist it with:

module_conf_ = "blacklist "

Cheers,

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH] nettle: refresh the patches

[Martin Jansa]

From: Martin Jansa <martin.ja...@gmail.com>

* fixes:
WARNING: nettle-2.7.1-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly 
applied patches.
The context lines in the patches can be updated with devtool:

devtool modify 
devtool finish --force-patch-refresh  

Then the updated patches and the source tree (in devtool's workspace)
should be reviewed to make sure the patches apply in the correct place
and don't introduce duplicate lines (which can, and does happen
when some of the context is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch Add-target-to-only-build-tests-not-run-them.patch
patching file Makefile.in
Hunk #1 succeeded at 53 (offset -2 lines).
patching file testsuite/Makefile.in
Hunk #1 succeeded at 105 with fuzz 2 (offset -11 lines).

Now at patch Add-target-to-only-build-tests-not-run-them.patch

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 ...d-target-to-only-build-tests-not-run-them.patch | 18 +++
 .../nettle/nettle-2.7.1/CVE-2015-8803_8805.patch   | 59 +-
 .../nettle/nettle-2.7.1/CVE-2015-8804.patch| 26 +++---
 ...k-header-files-of-openssl-only-if-enable_.patch |  6 +--
 4 files changed, 63 insertions(+), 46 deletions(-)

diff --git 
a/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
 
b/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
index 23da777..af77aec 100644
--- 
a/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
+++ 
b/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
@@ -1,4 +1,4 @@
-From 46edf01cc98db9f9feec984897836dfdd26bdc8d Mon Sep 17 00:00:00 2001
+From 9225dfb91b6b5617cf2dff32d370cf027237d4c8 Mon Sep 17 00:00:00 2001
 From: Jussi Kukkonen <jussi.kukko...@intel.com>
 Date: Wed, 12 Aug 2015 23:27:27 +0300
 Subject: [PATCH] Add target to only build tests (not run them)
@@ -9,16 +9,17 @@ installable tests: It's useful for us already as is.
 Upstream-Status: Inappropriate [not a complete solution]
 
 Signed-off-by: Jussi Kukkonen <jussi.kukko...@intel.com>
+
 ---
  Makefile.in   | 3 +++
  testsuite/Makefile.in | 2 ++
  2 files changed, 5 insertions(+)
 
 diff --git a/Makefile.in b/Makefile.in
-index 08efb7d..7909342 100644
+index 2c25007..ef21b1b 100644
 --- a/Makefile.in
 +++ b/Makefile.in
-@@ -55,6 +55,9 @@ clean distclean mostlyclean maintainer-clean tags:
+@@ -53,6 +53,9 @@ clean distclean mostlyclean maintainer-clean tags:
  echo "Making $@ in $$d" ; (cd $$d && $(MAKE) $@); done
$(MAKE) $@-here
  
@@ -29,18 +30,15 @@ index 08efb7d..7909342 100644
true
  
 diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in
-index 6bc1907..bb65bf0 100644
+index 91f6e2a..52f5c29 100644
 --- a/testsuite/Makefile.in
 +++ b/testsuite/Makefile.in
-@@ -116,6 +116,8 @@ $(TARGETS) $(EXTRA_TARGETS): testutils.$(OBJEXT) 
../nettle-internal.$(OBJEXT) \
- # data.
- VALGRIND = valgrind --error-exitcode=1 --leak-check=full --show-reachable=yes 
@IF_ASM@ --partial-loads-ok=yes
+@@ -105,6 +105,8 @@ $(TARGETS) $(EXTRA_TARGETS): testutils.$(OBJEXT) 
../nettle-internal.$(OBJEXT) \
+ 
+ VALGRIND = valgrind --error-exitcode=1 --leak-check=full --show-reachable=yes
  
 +buildtest: $(TS_ALL)
 +
  # The PATH update is for locating dlls on w*ndows.
  check: $(TS_ALL)
LD_LIBRARY_PATH=../.lib PATH="../.lib:$$PATH" srcdir="$(srcdir)" \
--- 
-2.1.4
-
diff --git a/recipes-support/nettle/nettle-2.7.1/CVE-2015-8803_8805.patch 
b/recipes-support/nettle/nettle-2.7.1/CVE-2015-8803_8805.patch
index a956f42..988f39e 100644
--- a/recipes-support/nettle/nettle-2.7.1/CVE-2015-8803_8805.patch
+++ b/recipes-support/nettle/nettle-2.7.1/CVE-2015-8803_8805.patch
@@ -1,3 +1,8 @@
+From f21b9f7b21067fa3630607cdc1663141b2735ae5 Mon Sep 17 00:00:00 2001
+From: Armin Kuster <akus...@mvista.com>
+Date: Thu, 2 Mar 2017 12:24:31 +
+Subject: [PATCH] Create meta-gplv2 from files from OE-Core
+
 Upstream-Status: Backport
 
https://git.lysator.liu.se/nettle/nettle/commit/c71d2c9d20eeebb985e3872e4550137209e3ce4d
 
@@ -8,14 +13,36 @@ Same fix for both.
 
 Signed-off-by: Armin Kuster <akus...@mvista.com>
 
-Index: nettle-2.7.1/ecc-256.c
-===
 nettle-2.7.1.orig/ecc-256.c
-+++ nettle-2.7.1/ecc-256.c
-@@ -96,9 +96,19 @@ ecc_256_modp (const struct ecc_curve *ec
+---
+ ChangeLog |  6 ++
+ ecc-256.c | 23 ++-
+ 2 files changed, 24 insertions(+), 5 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index 7b7854d..abdd974 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,9 @@
++2015-12-10  Niels Möller  <ni...@lysator.liu.se>
++
++   * ecc-256.c (ecc_256_modp): Fixed carry propagat

Re: [yocto] Does PACKAGECONFIG only apply to autotools recipes

[Martin Jansa]

It's applied in PACKAGECONFIG_CONFARGS variable and various bbclasses (and
also various recipes) use this variable where needed, see git grep:

meta/classes/base.bbclass:appendVar('PACKAGECONFIG_CONFARGS',
extraconf)

meta/classes/autotools.bbclass:EXTRA_OECONF_append = "
${PACKAGECONFIG_CONFARGS}"
meta/classes/cmake.bbclass:EXTRA_OECMAKE_append = "
${PACKAGECONFIG_CONFARGS}"
meta/classes/meson.bbclass:EXTRA_OEMESON += "${PACKAGECONFIG_CONFARGS}"
meta/classes/waf.bbclass:EXTRA_OECONF_append = " ${PACKAGECONFIG_CONFARGS}"

meta/recipes-graphics/glew/glew_2.1.0.bb:EXTRA_OEMAKE =
"${PACKAGECONFIG_CONFARGS} \

It used to be included in EXTRA_OECONF by default, before:
http://git.openembedded.org/openembedded-core/commit/?id=c98fb5f5129e71829ffab4449b3d28082bc95ab4

On Thu, Mar 15, 2018 at 6:22 PM, Alan Martinovic 
wrote:

> Hi,
> is it true that that PACKAGECONFIG is only used
>  for recipes that inherit autoconf?
>
> Was trying to understand what they do in a recipe:
> https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/
> recipes-connectivity/bluez5/bluez5.inc
> and didn't really get what this was about until found
> the autoconf reference mentioned in a book.
>
> So "features" as referenced in the mega manual:
> https://www.yoctoproject.org/docs/2.4/mega-manual/mega-
> manual.html#var-PACKAGECONFIG
> are the flags that will end up being passed to ./configure?
>
> However later in the recipe it's used to populate other variables
>
> NOINST_TOOLS = " \
> ${@bb.utils.contains('PACKAGECONFIG', 'readline',
> '${NOINST_TOOLS_READLINE}', '', d)} \
> ${@bb.utils.contains('PACKAGECONFIG', 'testing',
> '${NOINST_TOOLS_TESTING}', '', d)} \
> ${@bb.utils.contains('PACKAGECONFIG', 'tools',
> '${NOINST_TOOLS_BT}', '', d)} \
> "
>
> Is the original assumption true (that it's an autoconf only thing)?
> Is there a way to test that by grepping the code (didn't found
> autoconf references when greping for PACKAGECONFIG in
> bitbake -e bluez5)?
>
> Be Well :)
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] recipes: use oe.utils.conditional instead of deprecated base_conditional

[Martin Jansa]

https://github.com/agherzan/meta-raspberrypi/pull/188

On Wed, Jan 31, 2018 at 8:23 AM, Andrea Galbusera <giz...@gmail.com> wrote:

> On Wed, Jan 31, 2018 at 8:19 AM, Andrea Galbusera <giz...@gmail.com>
> wrote:
> > On Wed, Jan 31, 2018 at 8:05 AM, Andrea Galbusera <giz...@gmail.com>
> wrote:
> >> Hi Martin,
> >>
> >> On Tue, Jan 30, 2018 at 2:31 PM, Martin Jansa <martin.ja...@gmail.com>
> wrote:
> >>> Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
> >>> ---
> >>>  recipes-kernel/linux/linux-raspberrypi.inc | 6 +++---
> >>>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc
> b/recipes-kernel/linux/linux-raspberrypi.inc
> >>> index df3a3d7..a1c4e52 100644
> >>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> >>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> >>> @@ -22,10 +22,10 @@ KBUILD_DEFCONFIG_raspberrypi3-64 ?=
> "bcmrpi3_defconfig"
> >>>  CMDLINE ?= "dwc_otg.lpm_enable=0 console=serial0,115200
> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
> >>>
> >>>  # Add the kernel debugger over console kernel command line option if
> enabled
> >>> -CMDLINE_append = ' ${@base_conditional("ENABLE_KGDB", "1",
> "kgdboc=serial0,115200", "", d)}'
> >>> +CMDLINE_append = ' ${@oe.utils.conditional("ENABLE_KGDB", "1",
> "kgdboc=serial0,115200", "", d)}'
> >>>
> >>>  # Disable rpi logo on boot
> >>> -CMDLINE_append += ' ${@base_conditional("DISABLE_RPI_BOOT_LOGO",
> "1", "logo.nologo", "", d)}'
> >>> +CMDLINE_append += ' ${@oe.utils.conditional("DISABLE_RPI_BOOT_LOGO",
> "1", "logo.nologo", "", d)}'
> >>>
> >>>  # You can define CMDLINE_DEBUG as "debug" in your local.conf or
> distro.conf
> >>>  # to enable kernel debugging.
> >>> @@ -124,7 +124,7 @@ do_configure_prepend() {
> >>>  kernel_configure_variable ROOT_NFS y
> >>>  kernel_configure_variable CMDLINE "\"${CMDLINE_NFSROOT_USB}\""
> >>>  fi
> >>> -if [ "${@base_conditional('INITRAMFS_IMAGE_BUNDLE', '1', 'True',
> 'False', d)}" ]; then
> >>> +if [ "${@oe.utils.conditional('INITRAMFS_IMAGE_BUNDLE', '1',
> 'True', 'False', d)}" ]; then
> >>>  kernel_configure_variable BLK_DEV_INITRD y
> >>>  kernel_configure_variable INITRAMFS_SOURCE ""
> >>>  kernel_configure_variable RD_GZIP y
> >>> --
> >>> 2.15.1
> >>>
> >>> --
> >>> ___
> >>> yocto mailing list
> >>> yocto@yoctoproject.org
> >>> https://lists.yoctoproject.org/listinfo/yocto
> >>
> >> Although it's trivial, this one doesn't look to apply neither to
> >> current master nor to any object in the index of meta-raspberrypi
> >> repo...
> >>
> >> $ git show df3a3d7
> >> fatal: ambiguous argument 'df3a3d7': unknown revision or path not in
> >> the working tree.
> >
> > Also consider that, according to [1] patches should be submitted as
> > pull request on github, being the mailing list only a
> >
> > [1] https://github.com/agherzan/meta-raspberrypi/blob/master/
> docs/contributing.md#patches-and-pull-requests
>
> Sorry! Hit "send" too early on my previous one... Well you know what I
> meant: "...being the mailing list only an additional place for
> discussion".
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] recipes: use oe.utils.conditional instead of deprecated base_conditional

[Martin Jansa]

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 recipes-kernel/linux/linux-raspberrypi.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
b/recipes-kernel/linux/linux-raspberrypi.inc
index df3a3d7..a1c4e52 100644
--- a/recipes-kernel/linux/linux-raspberrypi.inc
+++ b/recipes-kernel/linux/linux-raspberrypi.inc
@@ -22,10 +22,10 @@ KBUILD_DEFCONFIG_raspberrypi3-64 ?= "bcmrpi3_defconfig"
 CMDLINE ?= "dwc_otg.lpm_enable=0 console=serial0,115200 root=/dev/mmcblk0p2 
rootfstype=ext4 rootwait"
 
 # Add the kernel debugger over console kernel command line option if enabled
-CMDLINE_append = ' ${@base_conditional("ENABLE_KGDB", "1", 
"kgdboc=serial0,115200", "", d)}'
+CMDLINE_append = ' ${@oe.utils.conditional("ENABLE_KGDB", "1", 
"kgdboc=serial0,115200", "", d)}'
 
 # Disable rpi logo on boot
-CMDLINE_append += ' ${@base_conditional("DISABLE_RPI_BOOT_LOGO", "1", 
"logo.nologo", "", d)}'
+CMDLINE_append += ' ${@oe.utils.conditional("DISABLE_RPI_BOOT_LOGO", "1", 
"logo.nologo", "", d)}'
 
 # You can define CMDLINE_DEBUG as "debug" in your local.conf or distro.conf
 # to enable kernel debugging.
@@ -124,7 +124,7 @@ do_configure_prepend() {
 kernel_configure_variable ROOT_NFS y
 kernel_configure_variable CMDLINE "\"${CMDLINE_NFSROOT_USB}\""
 fi
-if [ "${@base_conditional('INITRAMFS_IMAGE_BUNDLE', '1', 'True', 'False', 
d)}" ]; then
+if [ "${@oe.utils.conditional('INITRAMFS_IMAGE_BUNDLE', '1', 'True', 
'False', d)}" ]; then
 kernel_configure_variable BLK_DEV_INITRD y
 kernel_configure_variable INITRAMFS_SOURCE ""
 kernel_configure_variable RD_GZIP y
-- 
2.15.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error do_compile libepoxy

[Martin Jansa]

FWIW: here nativesdk-libepoxy fails in do_configure already since meson
conversion

FileNotFoundError: [Errno 2] No such file or directory:
'TOPDIR/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-libepoxy/1.4.3-r0/build/meson-private/sanitycheckc.exe'

http://errors.yoctoproject.org/Errors/Details/164799/

libepoxy in master doesn't support nativesdk yet (it's part of my changes
to support virtglrenderer and spice in qemu). Is there some magic
combination of settings meson needs to work for nativesdk?

On Thu, Jan 18, 2018 at 10:05 AM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 01/18/2018 10:58 AM, Andrea Galbusera wrote:
>
>>
>> Looks like my first guess was not that bad. Reverting below commit,
>> which switched to meson build system brought my build back to green.
>> Also CC-ing the patch author who might suggest further investigations.
>>
>>  libepoxy: convert to meson build
>>
>>
> There's probably a missing header include - carefully compare do_compile
> logs in both cases and see how they differ for the failing file. Also
> inspect the file for any conditional define macros and see if they're
> enabled or not in both cases.
>
>
> Alex
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Debugging sstate-cache

[Martin Jansa]

I'm using oe-core/scripts/sstate-diff-machines.sh script (which calls
bitbake -S) to generate "snapshots" of sstate signatures for interesting
builds (in our case daily official builds) and then every time I notice
something unexpectedly being rebuilt, I can use the same script to create
snapshot of my local build and then compare these 2.

Once it helps you find which recipes were changed, use bitbake-diffsigs to
compare sigdata files from the "snapshots" to see what change in metadata
caused the difference, often it's change in some other dependency, so you
need to traverse the dependency tree a bit until you find the real root
cause of the difference.

On Tue, Dec 19, 2017 at 2:25 PM, Alan Martinovic 
wrote:

> Hi,
> we have a build server set that is used by multiple
> people all working on the same yocto project each
> having a clone in their working dir.
>
> The core packages (those coming from meta-openembedded)
>  are same of every image we build.
>
> We all share a sstate-cache and a downloads cache.
> The download cache works as expected, I only notice
> new things being fetched when there were actual changes in
> the recipes.
>
> However, all other steps (do_configure, do_compile, do_package)
> seem to be executed arbitrarily without a specific order or cause.
> Lot of things are reused from the sstate-cache, some get redone
> on random, and a few are always build from the ground.
>
> I have synced with everyone and confirmed that we're not stepping
> on each others toes by cleaning package caches.
>
> Is there a way to see on what grounds does bitbake chooses
> to repeat the steps?
>
> Be Well,
> Alan
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] .kernel-meta/configs folder missing make linux-raspberrypi to fail

[Martin Jansa]

I'm seeing the same build errors in linux-raspberrypi with various versions
of Gentoo and Ubuntu (mostly tested with 14.04 and 16.04), I doubt that
this issue is specific for Fedora 27.

On Thu, Dec 14, 2017 at 2:31 PM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > Also is worth noting that I'm running Fedora 27 which wasn't tested...
>
> You should start from here your investigation, since you are on not tested
> YOCTO host distribution. And Fedoras are
> different from release to release, certainly!
>
> So either you should downgrade your fedora 27 to 26 (which I doubt it is
> possible), better to build brand new Fedora 26
> using exactly the same packages.
>
> Here is a bit of help: to port all the packages to fresh installed Fedora
> 26, use the following command to retrieve
> packages from Fedora 27: rpm -qa --qf "%{name}.%{arch}\n" >
> packages-list.txt
>
> Zoran
>
> On Mon, Dec 11, 2017 at 12:34 PM, Daniel.  wrote:
>
>> I can anticipate some info for you. I'm on version 2.4 Rocko. Building
>> rpi-hwup-image for MACHINE=rasbiberrypi3-64. Also is worth noting that I'm
>> running Fedora 27 which wasn't tested...
>>
>> I'll try to get the full log tonight and let you know
>>
>> Regards
>>
>> On Dec 11, 2017 9:26 AM, "Daniel."  wrote:
>>
>>> Yeah but I got to face the error again, maybe tonight when I get home :)
>>>
>>> On Dec 11, 2017 9:17 AM, "Paul Barker"  wrote:
>>>
 On Sun, Dec 10, 2017 at 5:14 PM, Daniel.  wrote:
 > Hi everybody,
 >
 > I'm building a vanilla image for MACHINE=raspberrypi3-64. I'm doing
 the
 > build for the first time and faced an error at
 > linux-raspberrypi:do_kernel_configme. I found that
 .kernel-meta/configs
 > folder was missing, so I fired a devshell and created it. After that
 > everything works as expected and linux-raspberrypi build fines.
 >
 > The solution I got is palliative, what would be the real solution and
 what
 > is this .kernel-meta folder? I had never seem this folder before.

 I have seen this issue occasionally when the do_kernel_configme task
 is re-executed. A "bitbake virtual/kernel -c clean" has always
 resolved this for me, allowing the next build to succeed. It doesn't
 occur on my autobuild systems though so I figure it's an edge case I'm
 hitting when building locally as I'm hacking around on recipes.

 I've never seen this on the first build of the kernel though.

 Which version of Yocto are you using? Could you send us the build
 configuration summary and the full error messages printed by bitbake?

 Thanks,

 --
 Paul Barker
 Togán Labs Ltd

>>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Build error: "u-boot-imx_2017.03.bb:do_compile" failed ( freescale I.MX 6 on Ubuntu 16.04) ?

[Martin Jansa]

I don't know what version of Yocto you're using, but if it's older than 2.3
(which does filter what binaries are seen from the host system with
HOSTTOOLS), then your build is probably autodetecting swig from host and
you can easily disable that with:

do_compile_prepend () {
sed 's@\(^always += $(if $(shell which swig 2>
/dev/null),_libfdt.so)$\)@# do not autodetect swig, there is no swig-native
dependency \1@g' -i ${S}/tools/Makefile
}

Then it won't try to rebuild libfdt python library and it won't fail.

On Thu, Dec 7, 2017 at 8:21 AM, Eric Schwarz 
wrote:

> Hello Jerry,
>
> U-Boot depends on Python but the dependency is not included in the U-Boot
> recipe AFAIK.
> I have already sent a patchset which was not complete at that time to the
> yocto mailinglist. Ross meant one needs to inherit from Python U-Boot class
> in the recipe not just include a dependency o/w it will not be in path.
> The error only comes up because you do not have Python installed on your
> system I think.
>
> Cheers
> Eric
>
> Am 06.12.2017 18:13, schrieb Jerry Lian:
>
> I got an error when trying to build for freescale I.MX6 on Ubuntu
>> 16.04.(see below)
>> (I just follow the guide from http://freescale.github.io)
>>
>> Anybody got hints?
>>
>> Thanks!
>>
>> Jerry
>>
>> ===
>> 
>> | tools/libfdt_wrap.c:147:21: fatal error: Python.h: No such file or
>> directory
>> | compilation terminated.
>> | error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
>> | /home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-
>> poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/tools/Makefile:123: recipe
>> for target 'tools/_libfdt.so' failed
>> | make[2]: *** [tools/_libfdt.so] Error 1
>> | /home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-
>> poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/Makefile:1229: recipe for
>> target 'tools' failed
>> | make[1]: *** [tools] Error 2
>> | make[1]: Leaving directory '/home/jerry/fsl-release-bsp/b
>> uild-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-
>> imx/2017.03-r0/build/mx6qsabresd_config'
>> | Makefile:150: recipe for target 'sub-make' failed
>> | make: *** [sub-make] Error 2
>> | make: Leaving directory '/home/jerry/fsl-release-bsp/b
>> uild-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-
>> imx/2017.03-r0/git'
>> | WARNING: exit code 1 from a shell command.
>> | ERROR: Function failed: do_compile (log file is located at
>> /home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-
>> poky-linux-gnueabi/u-boot-imx/2017.03-r0/temp/log.do_compile.9339)
>> ERROR: Task (/home/jerry/fsl-release-bsp/sources/meta-fsl-bsp-release/im
>> x/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb:do_compile) failed
>> with exit code '1'
>> NOTE: Tasks Summary: Attempted 4851 tasks of which 3009 didn't need to be
>> rerun and 1 failed.
>>
>> Summary: 1 task failed:
>> /home/jerry/fsl-release-bsp/sources/meta-fsl-bsp-release/imx
>> /meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb:do_compile
>> ..
>> 
>>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] buildhistory.bbclass "version-going-backwards" for AUTOINC

[Martin Jansa]

I think you can disable version-going-backwards check as any other QA check
by removing it from WARN_QA and ERROR_QA variables.

Even with AUTOINC you should use PR service to get increasing AUTOINC
numbers, so the warning is correct, if you want working upgrade paths on
the device then you need to fix your setup to use PR service.

On Wed, Nov 29, 2017 at 9:50 PM, Paul Knopf  wrote:

> I am getting these errors during builds.
>
> clear-app-gitAUTOINC+4d250a7fe4-r0 do_packagedata: QA Issue: Package
> version for package clear-app-locale-es went backwards which would break
> pack
> age feeds from (0:git0+66636e50ea-r0 to 0:git0+4d250a7fe4-r0)
> [version-going-backwards]
>
> I think buildhistory.bbclass should ignore recipes that are using AUTOINC.
>
> Or, a way to disable the version-going-backwards check.
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] rocko: QA issue with glibc-locale

[Martin Jansa]

Similar QA issue is shown when you use:
LOCALE_GENERATION_WITH_CROSS-LOCALEDEF_forcevariable = "0"

which is needed to build glibc-locale with pyro on hosts with glibc-2.26
(with ENABLE_BINARY_LOCALE_GENERATION = "1").

On Fri, Oct 20, 2017 at 11:44 AM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 10/19/2017 10:15 PM, Burton, Ross wrote:
>
>> On 19 October 2017 at 12:10, Belisko Marek > > wrote:
>>
>> I'm using latest origin/rocko
>> (65d23bd7986615fdfb0f1717b615534a2a14ab80) with no change to build
>> beaglebone core-image-minimal. While build I got this QA error:
>>
>> ERROR: glibc-locale-2.26-r0 do_package: QA Issue: glibc-locale:
>> Files/directories were installed but not shipped in any package:
>>/usr/share/i18n
>>
>>
>> I've seen this (and some other weird ones) in glibc-locales, and they've
>> always been resolved by just rebuilding the recipe. bitbake glibc-locale
>> -cclean && bitbake glibc-locale might well make it go away.
>>
>
> I'm beginning to wonder if the best way to resolve these elusive
> glibc-locale issues (also the notorious host contamination one) is to throw
> away the existing, extremely convoluted recipe, and do a clean rewrite.
>
> Alex
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [pyro][bitbake][PATCH] bitbake: Replace deprecated git branch parameter "--set-upstream"

[Martin Jansa]

It should go to bitbake-devel ML and the subject should say bitbake branch
(which is 1.34 not pyro).

On Tue, Oct 17, 2017 at 3:31 PM, André Draszik <g...@andred.net> wrote:

> From: Andre Rosa <andre.r...@lge.com>
>
> Since 2017-08-17 (git version 2.14.1.473.g3ec7d702a) using deprecated
> git branch parameter "--set-upstream" causes a fetcher error. Replace
> it by "--set-upstream-to".
>
> https://git.kernel.org/pub/scm/git/git.git/commit/?id=
> 52668846ea2d41ffbd87cda7cb8e492dea9f2c4d
> says, it's deprecated since 2012-08-30 so hopefully all still supported
> host distributions have new enough git to support "--set-upstream-to".
>
> ERROR: PACKAGE do_unpack: Fetcher failure: ...;
> git -c core.fsyncobjectfiles=0 branch --set-upstream master origin/master
> failed with exit code 128, output:
> fatal: the '--set-upstream' option is no longer supported. Please use
> '--track' or '--set-upstream-to' instead.
>
> ERROR: PACKAGE do_unpack: Function failed: base_do_unpack
>
> (Bitbake rev: 2ab50074c1a6c56a8a178755de108447d7b7acaf)
>
> Signed-off-by: Andre Rosa <andre.r...@lge.com>
> Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
> Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
>
> (cherry picked from commit 20d0282c6048fe11b303e538dbf9109ccb0c467d)
> Signed-off-by: André Draszik <adras...@tycoint.com>
> ---
>  bitbake/lib/bb/fetch2/git.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bitbake/lib/bb/fetch2/git.py b/bitbake/lib/bb/fetch2/git.py
> index 2550bde838..7442f84414 100644
> --- a/bitbake/lib/bb/fetch2/git.py
> +++ b/bitbake/lib/bb/fetch2/git.py
> @@ -326,7 +326,7 @@ class Git(FetchMethod):
>  branchname =  ud.branches[ud.names[0]]
>  runfetchcmd("%s checkout -B %s %s" % (ud.basecmd,
> branchname, \
>  ud.revisions[ud.names[0]]), d,
> workdir=destdir)
> -runfetchcmd("%s branch --set-upstream %s origin/%s" %
> (ud.basecmd, branchname, \
> +runfetchcmd("%s branch %s --set-upstream-to origin/%s" %
> (ud.basecmd, branchname, \
>  branchname), d, workdir=destdir)
>  else:
>  runfetchcmd("%s checkout %s" % (ud.basecmd,
> ud.revisions[ud.names[0]]), d, workdir=destdir)
> --
> 2.15.0.rc1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] u-boot recipe: Missing dependencies

[Martin Jansa]

Be aware that when you provide python-native, it's more likely that
swig-native will be detected in sysroot as well and then u-boot will fail
to build libfdt python library.

To prevent this autodetection you can use something like this:

do_compile_prepend () {
sed 's@\(^always += $(if $(shell which swig 2>
/dev/null),_libfdt.so)$\)@# do not autodetect swig, there is no swig-native
dependency \1@g' -i ${S}/tools/Makefile
}

which isn't needed in Yocto 2.3 Pyro and newer thanks to RSS and HOSTTOOLs
filtering.


On Mon, Oct 9, 2017 at 12:30 PM, Burton, Ross  wrote:

> On 8 October 2017 at 18:04, Eric Schwarz  wrote:
>
>> Don't _append when you can just extend the assignment above.
>>>
>>
>> I just did it that way for the moment since I wanted to circumvent merge
>> conflicts when I upgrade the underlying recipes from openembedded.
>
>
> Well it's ugly, so if you want a patch in oe-core then don't introduce
> ugly for your convenience.
>
>
>> Depending on python-native does nothing as the binary isn't in $PATH
>>> still.
>>>
>>
>> I thought any Yocto native binaries built are in the PATH automatically.
>> - How
>> to fix this/do it correctly?
>>
>
> You need to inherit python3native, as python (and some others) are opt-in.
>
>
>> Can you provide a configuration to make U-Boot build on x86 for testing?
>>>
>>
>> I put now some patches in ordered manner on top of the original recipes
>> from
>> openembedded.
>> However, before sending I would like to fix two issues so the recipes can
>> go
>> into mainline immediately.
>>
>> 1.) I am working w/ -morty Yocto branch at the moment. The 'u-boot.inc'
>> from
>> openembedded does not work w/ -morty.
>> I get the following error "AttributeError: module 'bb.utils' has no
>> attribute 'filter'". Building w/ the original -morty 'u-boot.inc'
>> works.
>>
>
> Yes, bb.utils.filter() is a new function that isn't in morty.
>
> Ross
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] Revert "qtbase: Enable EGLFS support"

[Martin Jansa]

* this reverts commit 04b37dbdb79638b17a670280058400ffaf1b6ccb.
* this makes qtbase and everything which depends on some qt* recipe to
  be effectivelly MACHINE_ARCH

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend | 3 ---
 1 file changed, 3 deletions(-)
 delete mode 100644 dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend

diff --git a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend 
b/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
deleted file mode 100644
index ae3f1d3..000
--- a/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
+++ /dev/null
@@ -1,3 +0,0 @@
-# Copyright (C) 2017 O.S. Systems Software LTDA.
-
-PACKAGECONFIG_GL_rpi   = "gles2 eglfs"
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] "(-)"??

[Martin Jansa]

null and nothing can also be matched in MACHINE names, so to make sure
people should use:

COMPATIBLE_MACHINE = "(^$)"

On Thu, Sep 21, 2017 at 8:41 AM, Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> > -Original Message-
> > From: yocto-boun...@yoctoproject.org [mailto:yocto-
> > boun...@yoctoproject.org] On Behalf Of Khem Raj
> > Sent: den 21 september 2017 07:15
> > To: Takashi Matsuzawa ; yocto@yoctoproject.org
> > Subject: Re: [yocto] "(-)"??
> >
> > On 9/20/17 8:18 PM, Takashi Matsuzawa wrote:
> > > Hello.
> > > I am seeing some of the recipes contains lines like below.
> > >
> > >> COMPATIBLE_MACHINE = "(-)"
> > >
> > > Sorry being novice, but what is the intended effect of this line?
> > > I can see submit comments that this is for blacklisting but I am not
> > > sure how it works.  It simply means a '-' letter?
> >
> > COMAPTIBLE_MACHINE uses regexp syntax
>
> Which actually makes that a pretty weird COMPATIBLE_MACHINE,
> especially if it is intended for blacklisting. Given that it would
> match any machine with a dash in it, it would match, e.g., qemux86-64
> but not qemux86. It would also happen to match about half of our
> machines which happen to have dashes in their names.
>
> A more appropriate way to blacklist machines using COMPATIBLE_MACHINE
> would be something like:
>
> COMPATIBLE_MACHINE = "null"
>
> or:
>
> COMPATIBLE_MACHINE = "nothing"
>
> I found two occurrences of "(-)" being used as COMPATIBLE_MACHINE in
> meta-openembedded for Morty and Pyro, but they have been removed for
> Rocko. If you see them anywhere else, consider changing them.
>
> //Peter
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 1/3] linux-raspberrypi_4.9.bb: Upgrade to 4.9.50

[Martin Jansa]

Yes,

GNU gold (GNU Binutils 2.29.0.20170912) 1.14

On Tue, Sep 19, 2017 at 4:01 PM, Khem Raj <raj.k...@gmail.com> wrote:

> is
> /OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_
> 64-webos-linux/linux-raspberrypi/1_4.9.50+gitAUTOINC+46e2d4d1bd-r0/
> recipe-sysroot-native/usr/bin/aarch64-webos-linux/../../
> libexec/aarch64-webos-linux/gcc/aarch64-webos-linux/7.2.0/ld
>
> gold ?
>
> On Tue, Sep 19, 2017 at 6:58 AM, Martin Jansa <martin.ja...@gmail.com>
> wrote:
> > On Mon, Sep 18, 2017 at 12:29:44PM -0700, Khem Raj wrote:
> >> On Mon, Sep 18, 2017 at 11:48 AM, Martin Jansa <martin.ja...@gmail.com>
> wrote:
> >> > With these 3 changes included I see following failure with
> raspberrypi3-64,
> >> > it might be something caused by last oe-core upgrade, but I haven't
> noticed
> >> > anything suspicious there.
> >> >
> >> > Looks familiar?
> >>
> >> havent seen it here. I would say unbolt these changes and try out see
> >> if it goes away or not.
> >
> > The last one "linux-raspberrypi: Build dtbs with dtbs make target for
> > rpi64" is causing this error.
> >
> >>
> >> >
> >> > |   VDSOL   arch/arm64/kernel/vdso/vdso.so.dbg
> >> > |
> >> > /OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_
> 64-webos-linux/linux-raspberrypi/1_4.9.50+gitAUTOINC+46e2d4d1bd-r0/
> recipe-sysroot-native/usr/bin/aarch64-webos-linux/../../
> libexec/aarch64-webos-linux/gcc/aarch64-webos-linux/7.2.0/ld:
> >> > fatal error: -shared and -static are incompatible
> >> > | collect2: error: ld returned 1 exit status
> >> > | make[3]: ***
> >> > [/OE/build/owpb/webos-ports/tmp-glibc/work-shared/
> raspberrypi3-64/kernel-source/arch/arm64/kernel/vdso/Makefile:34:
> >> > arch/arm64/kernel/vdso/vdso.so.dbg] Error 1
> >> > | make[2]: *** [arch/arm64/Makefile:144: vdso_prepare] Error 2
> >> > | make[1]: *** [Makefile:150: sub-make] Error 2
> >> > | make: *** [Makefile:24: __sub-make] Error 2
> >> > | ERROR: oe_runmake failed
> >> > | WARNING:
> >> > /OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_
> 64-webos-linux/linux-raspberrypi/1_4.9.50+gitAUTOINC+46e2d4d1bd-r0/temp/
> run.do_compile.29341:1
> >> > exit 1 from 'exit 1'
> >> >
> >> >
> >> > On Mon, Sep 18, 2017 at 7:41 AM, Khem Raj <raj.k...@gmail.com> wrote:
> >> >>
> >> >> Signed-off-by: Khem Raj <raj.k...@gmail.com>
> >> >> ---
> >> >>  recipes-kernel/linux/linux-raspberrypi_4.9.bb | 4 ++--
> >> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >> >>
> >> >> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> >> >> b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> >> >> index ba17020..068965f 100644
> >> >> --- a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> >> >> +++ b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> >> >> @@ -1,8 +1,8 @@
> >> >>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> >> >>
> >> >> -LINUX_VERSION ?= "4.9.41"
> >> >> +LINUX_VERSION ?= "4.9.50"
> >> >>
> >> >> -SRCREV = "4153f509b449f1c1c816cf124c314975c3daa824"
> >> >> +SRCREV = "46e2d4d1bd2c17e2f84dd90768321ee0bbaa6b8a"
> >> >>  SRC_URI = "git://github.com/raspberrypi/linux.git;branch=rpi-4.9.y"
> >> >>
> >> >>  require linux-raspberrypi.inc
> >> >> --
> >> >> 2.14.1
> >> >>
> >> >> --
> >> >> ___
> >> >> yocto mailing list
> >> >> yocto@yoctoproject.org
> >> >> https://lists.yoctoproject.org/listinfo/yocto
> >> >
> >> >
> >
> > --
> > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 1/3] linux-raspberrypi_4.9.bb: Upgrade to 4.9.50

[Martin Jansa]

On Mon, Sep 18, 2017 at 12:29:44PM -0700, Khem Raj wrote:
> On Mon, Sep 18, 2017 at 11:48 AM, Martin Jansa <martin.ja...@gmail.com> wrote:
> > With these 3 changes included I see following failure with raspberrypi3-64,
> > it might be something caused by last oe-core upgrade, but I haven't noticed
> > anything suspicious there.
> >
> > Looks familiar?
> 
> havent seen it here. I would say unbolt these changes and try out see
> if it goes away or not.

The last one "linux-raspberrypi: Build dtbs with dtbs make target for
rpi64" is causing this error.

> 
> >
> > |   VDSOL   arch/arm64/kernel/vdso/vdso.so.dbg
> > |
> > /OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_64-webos-linux/linux-raspberrypi/1_4.9.50+gitAUTOINC+46e2d4d1bd-r0/recipe-sysroot-native/usr/bin/aarch64-webos-linux/../../libexec/aarch64-webos-linux/gcc/aarch64-webos-linux/7.2.0/ld:
> > fatal error: -shared and -static are incompatible
> > | collect2: error: ld returned 1 exit status
> > | make[3]: ***
> > [/OE/build/owpb/webos-ports/tmp-glibc/work-shared/raspberrypi3-64/kernel-source/arch/arm64/kernel/vdso/Makefile:34:
> > arch/arm64/kernel/vdso/vdso.so.dbg] Error 1
> > | make[2]: *** [arch/arm64/Makefile:144: vdso_prepare] Error 2
> > | make[1]: *** [Makefile:150: sub-make] Error 2
> > | make: *** [Makefile:24: __sub-make] Error 2
> > | ERROR: oe_runmake failed
> > | WARNING:
> > /OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_64-webos-linux/linux-raspberrypi/1_4.9.50+gitAUTOINC+46e2d4d1bd-r0/temp/run.do_compile.29341:1
> > exit 1 from 'exit 1'
> >
> >
> > On Mon, Sep 18, 2017 at 7:41 AM, Khem Raj <raj.k...@gmail.com> wrote:
> >>
> >> Signed-off-by: Khem Raj <raj.k...@gmail.com>
> >> ---
> >>  recipes-kernel/linux/linux-raspberrypi_4.9.bb | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> >> b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> >> index ba17020..068965f 100644
> >> --- a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> >> +++ b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> >> @@ -1,8 +1,8 @@
> >>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> >>
> >> -LINUX_VERSION ?= "4.9.41"
> >> +LINUX_VERSION ?= "4.9.50"
> >>
> >> -SRCREV = "4153f509b449f1c1c816cf124c314975c3daa824"
> >> +SRCREV = "46e2d4d1bd2c17e2f84dd90768321ee0bbaa6b8a"
> >>  SRC_URI = "git://github.com/raspberrypi/linux.git;branch=rpi-4.9.y"
> >>
> >>  require linux-raspberrypi.inc
> >> --
> >> 2.14.1
> >>
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >
> >

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH 1/3] linux-raspberrypi_4.9.bb: Upgrade to 4.9.50

[Martin Jansa]

With these 3 changes included I see following failure with raspberrypi3-64,
it might be something caused by last oe-core upgrade, but I haven't noticed
anything suspicious there.

Looks familiar?

|   VDSOL   arch/arm64/kernel/vdso/vdso.so.dbg
|
/OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_64-webos-linux/linux-raspberrypi/1_4.9.50+gitAUTOINC+46e2d4d1bd-r0/recipe-sysroot-native/usr/bin/aarch64-webos-linux/../../libexec/aarch64-webos-linux/gcc/aarch64-webos-linux/7.2.0/ld:
fatal error: -shared and -static are incompatible
| collect2: error: ld returned 1 exit status
| make[3]: ***
[/OE/build/owpb/webos-ports/tmp-glibc/work-shared/raspberrypi3-64/kernel-source/arch/arm64/kernel/vdso/Makefile:34:
arch/arm64/kernel/vdso/vdso.so.dbg] Error 1
| make[2]: *** [arch/arm64/Makefile:144: vdso_prepare] Error 2
| make[1]: *** [Makefile:150: sub-make] Error 2
| make: *** [Makefile:24: __sub-make] Error 2
| ERROR: oe_runmake failed
| WARNING:
/OE/build/owpb/webos-ports/tmp-glibc/work/raspberrypi3_64-webos-linux/linux-raspberrypi/1_4.9.50+gitAUTOINC+46e2d4d1bd-r0/temp/run.do_compile.29341:1
exit 1 from 'exit 1'


On Mon, Sep 18, 2017 at 7:41 AM, Khem Raj  wrote:

> Signed-off-by: Khem Raj 
> ---
>  recipes-kernel/linux/linux-raspberrypi_4.9.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> index ba17020..068965f 100644
> --- a/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> +++ b/recipes-kernel/linux/linux-raspberrypi_4.9.bb
> @@ -1,8 +1,8 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> -LINUX_VERSION ?= "4.9.41"
> +LINUX_VERSION ?= "4.9.50"
>
> -SRCREV = "4153f509b449f1c1c816cf124c314975c3daa824"
> +SRCREV = "46e2d4d1bd2c17e2f84dd90768321ee0bbaa6b8a"
>  SRC_URI = "git://github.com/raspberrypi/linux.git;branch=rpi-4.9.y"
>
>  require linux-raspberrypi.inc
> --
> 2.14.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] ERROR: No recipes available for gstreamer

[Martin Jansa]

You're missing incompatible branches, use the same branch for all 3 and it
will work.

On Wed, Sep 13, 2017 at 4:48 PM, yahia farghaly 
wrote:

> Minutes ago, i pulled the recent commits for poky,meta-oe, meta-raspberry
> pi
> and when i build this comes. there are actually another errors but as i
> started taking one by one error. this was the first.
>
> *ERROR: No recipes available for:*
> *
> /yocto/poky/meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.12%.bbappend*
>
>
> --
> Yahia Farghaly
> Graduated from Faculty of Engineering - Electronics and Communications
> Department at Cairo University.
> Linkedin  - GitHub
> 
>
>
>
> ‌
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cannot re-use shared state cache between build hosts

[Martin Jansa]

Why do you use:

";downloadfilename=PATH
"

?

On Fri, Sep 1, 2017 at 3:54 PM, Andrea Galbusera  wrote:

> Hi!
>
> I was trying to share sstate between different hosts, but the consumer
> build system seems to be unable to use re-use any sstate object. My
> scenario is setup as follows:
>
> * The cache was populated by a pristine qemux86 core-image-minimal build
> of morty. This was done in a crops/poky container (running in docker on Mac)
> * The cache was then served via HTTP
> * The second host is a VM running Ubuntu 16.04 where I set SSTATE_MIRRORS
> to point to the hosted sstate cache like this:
>
> SSTATE_MIRRORS ?= "\
> file://.* http://192.168.33.1:8000/sstate-cache/PATH;downloadfilename=PATH
> "
>
> * I checked with curl that the VM can successfully get sstate objects from
> the server.
> * Then I start a new build (same metadata revisions, default configuration
> for core-image-minimal) and each and every task run from scratch with no
> sstate cache re-use.
>
> Here are the two configurations from bitbake and /etc/lsb-release files:
>
> On the container used to seed sstate cache:
>
> Build Configuration:
> BB_VERSION= "1.32.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "i586-poky-linux"
> MACHINE   = "qemux86"
> DISTRO= "poky"
> DISTRO_VERSION= "2.2.2"
> TUNE_FEATURES = "m32 i586"
> TARGET_FPU= ""
> meta
> meta-poky
> meta-yocto-bsp= "morty:2a70e84643381eca0e7bf7928d4a3d56f9651128"
>
> $ cat /etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
>
> On the VM that should consume the cache:
>
> Build Configuration:
> BB_VERSION= "1.32.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-16.04"
> TARGET_SYS= "i586-poky-linux"
> MACHINE   = "qemux86"
> DISTRO= "poky"
> DISTRO_VERSION= "2.2.2"
> TUNE_FEATURES = "m32 i586"
> TARGET_FPU= ""
> meta
> meta-poky
> meta-yocto-bsp= "morty:2a70e84643381eca0e7bf7928d4a3d56f9651128"
>
> $ cat /etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"
>
>
> To me, the only differing bit that in my understanding can lead to sstate
> cache objects invalidation is the value of NATIVELSBSTRING which is
> "universal" inside the container and "Ubuntu-16.04". This sounds strange to
> me, since both underlying systems are Ubuntu 16.04 (although not exactly
> the same dot release) as confirmed by /etc/lsb-release contents.
>
> Is the different NATIVELSBSTRING the root cause for everything being
> re-built? If so, what's causing them being different in the end and what
> does "universal" exactly mean (to me it looks like a more generic and
> incluse term than any distro label, so I'm confused...)?
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] layer.conf on openembedded-core ?

[Martin Jansa]

On Wed, Aug 16, 2017 at 07:40:10AM +0800, Riko Ho wrote:
> I see, so I must use all layers within the same branch.
> Could you tell me where I can download those layers in the sma branch?
> I didn't see the branch when I clone the layers.

This might help you:
https://git-scm.com/documentation

> On Aug 15, 2017 10:11 PM, "Martin Jansa" <martin.ja...@gmail.com> wrote:
> 
> > But it's related to it, in this thread he added oe-core/meta in master
> > branch to BBLAYERS in poky build (already including poky/meta) from pyro
> > branch.
> >
> > That's why he is seeing 3 strange issues reported in couple threads
> > already (and this is also 3rd time someone telling him that he shouldn't
> > include oe-core meta twice and to use the same branch across all layers).
> >
> > On Tue, Aug 15, 2017 at 4:12 PM, Leonardo Sandoval <
> > leonardo.sandoval.gonza...@linux.intel.com> wrote:
> >
> >> On Tue, 2017-08-15 at 09:09 +0800, Riko wrote:
> >> > Dear Team Yocto Members,
> >> >
> >> > I continue compiling, and got :
> >> >
> >> > ERROR: /home/bianchi/poky/openembedded-core/meta/recipes-core/images/
> >> build-appliance-image_15.0.0.bb: No IMAGE_CMD defined for IMAGE_FSTYPES
> >> entry 'wic.vmdk' - possibly invalid type name or missing support class
> >> > ERROR: Failed to parse
> >> > recipe: /home/bianchi/poky/openembedded-core/meta/recipes-core/images/
> >> build-appliance-image_15.0.0.bb
> >> >
> >>
> >> would be better if you start another thread with this issue. BTW, I just
> >> built a build-appliance without any change at local.conf and all went
> >> fine so you may have included something that you are not referring to
> >> (IMAGE_FILES?)
> >>
> >>
> >>
> >> > How can I fix it ?
> >> >
> >> > regards,
> >> >
> >> > Riko
> >> >
> >> >
> >> >
> >> > On 14/08/17 23:56, Christopher Larson wrote:
> >> >
> >> > > The openembedded-core root isn’t a layer, openembedded-core/meta is.
> >> > >
> >> > > On Mon, Aug 14, 2017 at 8:49 AM, Leonardo Sandoval
> >> > > <leonardo.sandoval.gonza...@linux.intel.com> wrote:
> >> > > On Mon, 2017-08-14 at 15:11 +0800, Riko wrote:
> >> > > > Dear Yocto Members,
> >> > > >
> >> > > > How can I find this file ?
> >> > >
> >> > >
> >> > > this is a pretty general question. are you running bitbake
> >> > > from the
> >> > > build directory? double check your conf/bblayers.conf and
> >> > > make sure
> >> > > paths there are pointing correctly.
> >> > >
> >> > >
> >> > > >
> >> > > > ==
> >> > > >
> >> > > > ERROR: Unable to parse
> >> > > > /home/bianchi/poky/openembedded-core/conf/layer.conf:
> >> > > [Errno 2] file
> >> > > > /home/bianchi/poky/openembedded-core/conf/layer.conf not
> >> > > found
> >> > > >
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Riko
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > ___
> >> > > yocto mailing list
> >> > > yocto@yoctoproject.org
> >> > > https://lists.yoctoproject.org/listinfo/yocto
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Christopher Larson
> >> > > kergoth at gmail dot com
> >> > > Founder - BitBake, OpenEmbedded, OpenZaurus
> >> > > Senior Software Engineer, Mentor Graphics
> >> >
> >>
> >>
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >>
> >
> >

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: gcc-source-6.3.0-6.3.0-r0 do_fetch: Fetcher failure for URL: 'file://0002-uclibc-conf.patch'. Unable to fetch URL from any source.

[Martin Jansa]

He is mixing poky/pyro with oe-core/master. All recent issues reported by
Riko are caused by that.

On Tue, Aug 15, 2017 at 5:49 PM, Khem Raj  wrote:

>
> Thanks for sharing your build configuration. It says you are on
> pyro release and I see this patch is there. So something else is
> triggering it. Do you have any local changes ?
>
> On 8/14/17 10:35 PM, Riko wrote:
> > Do you mean this one ?
> >
> > Build Configuration:
> > BB_VERSION= "1.34.0"
> > BUILD_SYS = "x86_64-linux"
> > NATIVELSBSTRING   = "universal"
> > TARGET_SYS= "arm-poky-linux-gnueabi"
> > MACHINE   = "beaglebone"
> > DISTRO= "poky"
> > DISTRO_VERSION= "2.3.1"
> > TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard cortexa8"
> > TARGET_FPU= "hard"
> > meta
> > meta-poky
> > meta-yocto-bsp= "pyro:4a39979c8d1e560fa54240e99734a651dfbaa63a"
> > meta  = "master:5a25ed1071f0d9b7d95edcc2b5b4545f960d5f95"
> > meta-oe
> > meta-xfce
> > meta-gnome
> > meta-python
> > meta-multimedia
> > meta-networking   = "master:a8b54e300be027fefe8a774ca1861d0fb8e80d99"
> > meta-browser  = "master:e3c3aa0591506672245904227a46519a276957e0"
> >
> >
> > On 15/08/17 13:30, Khem Raj wrote:
> >> On Mon, Aug 14, 2017 at 9:42 PM, Riko  wrote:
> >>> Dear Team Yocto Member,
> >>>
> >>> How can I get gcc6.30 ?
> >>>
> >>> I got error :
> >>>
> >>> ERROR: gcc-source-6.3.0-6.3.0-r0 do_fetch: Fetcher failure for URL:
> >>> 'file://0002-uclibc-conf.patch'. Unable to fetch URL from any source.
> >>>
> >> what branch are you using and if you are using additonal layers which
> >> ones
> >> are those and what branches are they on.
> >>
> >>> Here's the log :
> >>>
> >>> ===
> >>>
> >>> DEBUG: Executing python function clean_recipe_sysroot
> >>> DEBUG: Python function clean_recipe_sysroot finished
> >>> DEBUG: Executing python function extend_recipe_sysroot
> >>> NOTE: Direct dependencies are []
> >>> NOTE:
> >>> DEBUG: Python function extend_recipe_sysroot finished
> >>> DEBUG: Executing python function do_fetch
> >>> DEBUG: Executing python function base_do_fetch
> >>> DEBUG: Searching for 0001-gcc-4.3.1-ARCH_FLAGS_FOR_TARGET.patch in
> >>> paths:
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/poky
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/backport/poky
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3.0/poky
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc/poky
> >>> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
> poky
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/beaglebone
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/backport/beaglebone
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3.0/beaglebone
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/
> beaglebone
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
> beaglebone
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/armv7a
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/backport/armv7a
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3.0/armv7a
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/
> armv7a
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
> armv7a
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/arm
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/backport/arm
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3.0/arm
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/arm
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/files/arm
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/backport/
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3.0/
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/gcc/
> >>> /home/bianchi/poky/openembedded-core/meta/recipes-devtools/gcc/files/
> >>> DEBUG: Searching for 0002-uclibc-conf.patch in paths:
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/poky
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3/backport/poky
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc-6.3.0/poky
> >>>
> >>> /home/bianchi/poky/openembedded-core/meta/
> recipes-devtools/gcc/gcc/poky
> >>> 

Re: [yocto] layer.conf on openembedded-core ?

[Martin Jansa]

But it's related to it, in this thread he added oe-core/meta in master
branch to BBLAYERS in poky build (already including poky/meta) from pyro
branch.

That's why he is seeing 3 strange issues reported in couple threads already
(and this is also 3rd time someone telling him that he shouldn't include
oe-core meta twice and to use the same branch across all layers).

On Tue, Aug 15, 2017 at 4:12 PM, Leonardo Sandoval <
leonardo.sandoval.gonza...@linux.intel.com> wrote:

> On Tue, 2017-08-15 at 09:09 +0800, Riko wrote:
> > Dear Team Yocto Members,
> >
> > I continue compiling, and got :
> >
> > ERROR: /home/bianchi/poky/openembedded-core/meta/recipes-core/images/
> build-appliance-image_15.0.0.bb: No IMAGE_CMD defined for IMAGE_FSTYPES
> entry 'wic.vmdk' - possibly invalid type name or missing support class
> > ERROR: Failed to parse
> > recipe: /home/bianchi/poky/openembedded-core/meta/recipes-core/images/
> build-appliance-image_15.0.0.bb
> >
>
> would be better if you start another thread with this issue. BTW, I just
> built a build-appliance without any change at local.conf and all went
> fine so you may have included something that you are not referring to
> (IMAGE_FILES?)
>
>
>
> > How can I fix it ?
> >
> > regards,
> >
> > Riko
> >
> >
> >
> > On 14/08/17 23:56, Christopher Larson wrote:
> >
> > > The openembedded-core root isn’t a layer, openembedded-core/meta is.
> > >
> > > On Mon, Aug 14, 2017 at 8:49 AM, Leonardo Sandoval
> > >  wrote:
> > > On Mon, 2017-08-14 at 15:11 +0800, Riko wrote:
> > > > Dear Yocto Members,
> > > >
> > > > How can I find this file ?
> > >
> > >
> > > this is a pretty general question. are you running bitbake
> > > from the
> > > build directory? double check your conf/bblayers.conf and
> > > make sure
> > > paths there are pointing correctly.
> > >
> > >
> > > >
> > > > ==
> > > >
> > > > ERROR: Unable to parse
> > > > /home/bianchi/poky/openembedded-core/conf/layer.conf:
> > > [Errno 2] file
> > > > /home/bianchi/poky/openembedded-core/conf/layer.conf not
> > > found
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Riko
> > > >
> > >
> > >
> > > --
> > > ___
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Christopher Larson
> > > kergoth at gmail dot com
> > > Founder - BitBake, OpenEmbedded, OpenZaurus
> > > Senior Software Engineer, Mentor Graphics
> >
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How can I use PREFERRED_VERSION_ ?

[Martin Jansa]

and you should start by not including 2 different versions of
openembedded-core/meta in your builds.

Then you won't need PREFERRED_VERSION for openssl and the issue with
wic.vmdk you reported elsewhere will also probably disappear.

On Tue, Aug 15, 2017 at 7:31 AM, Khem Raj  wrote:

> On Mon, Aug 14, 2017 at 7:15 PM, Riko  wrote:
> > Dear Yocto Team Members,
> >
> > How can I use PREFERRED_VERSION_ ?
> >
> >
>
> read through
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-
> manual.html#var-PREFERRED_VERSION
>
> > ERROR: Multiple versions of openssl are due to be built
> > (/home/bianchi/poky/openembedded-core/meta/recipes-connectivity/openssl/
> openssl_1.1.0f.bb
> > /home/bianchi/poky/meta/recipes-connectivity/openssl/openssl_1.0.2k.bb).
> > Only one version of a given PN should be built in any given build. You
> > likely need to set PREFERRED_VERSION_openssl to select the correct
> version
> > or don't depend on multiple versions.
> >
> >
> > Regards,
> >
> > Riko
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

[Martin Jansa]

I haven't tried the patches, but I really like this idea (I was suggesting
something like that since 2011
http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/10327)
and I'm glad you weren't discouraged attempting to do this.

It also implements 3) b) idea from
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970 , you might be
interested read that ticket.

Thanks

On Fri, Jun 30, 2017 at 11:48 AM, Michael Ho 
wrote:

> Hi, at BMW Car IT we are working on an experimental feature to improve
> sstate
> cache hits and we are looking for comments on the approach who might have
> some
> insights to the problem and seeing if anyone is interested in the feature
> for
> mainline.
>
> The sstate-cache of a recipe is tied closely to its build dependencies, as
> the
> signature generated for a task includes all parent task's signatures as
> part of
> the signature information. This means that when changes occur in the parent
> recipes, even if insignificant, all children recipes that have valid sstate
> cache must invalidate their sstate cache objects.
>
> What this patchset does is propose to add another optional variable to
> recipes,
> CDEPENDS, which acts like DEPENDS for all RunQueue purposes but for
> signature
> generation it excludes any parent tasks that come from dependencies listed
> in
> it. This is to break the signature change domino effect.
>
> This patchset also proposes modifying RunQueue to then be able to run a
> compatibility checker during task execution phase for recipes and tasks
> that use
> CDEPENDS and allow for deciding to re-execute a task despite being covered
> by
> sstate-cache.
>
> The patchset is based on the jethro branch for the poky repository, as
> this is
> the branch that we are using.  If the general idea sounds good, we can
> consider
> porting it to master.
>
> Included is an patch that adds an example recipe and compatibility checker,
> where compatibility is based on the file checksums of the parent recipes
> packages. An example recipe, cdepends-test1, generates a compatibility
> report
> containing the file checksums of all files that it packages and which file
> paths
> they are at. Another recipe, cdepends-test2, can then strip this
> compatibility
> report to the minimal files it needs to be consistent and can compare the
> latest
> checksums it used to configure/compile/install with and if they have
> changed,
> trigger a rebuild. If not, the previous version restored from sstate-cache
> is
> used.
>
> We are still experimenting with the usages of this, including the use of
> having
> abi-compliance-checker to compare the ABI of shared libraries as a
> compatibility
> checker during RunQueue and using the results to avoid rebuilding child
> recipes
> when the .so files they depend on are still compatible. Example use cases
> of
> this are allowing recipes which provide multiple shared libraries to
> change a
> single .so file without rebuilding all its children that depend on the
> other
> shared libraries but not the one that changed.
>
> We're aware of the SIGGEN_EXCLUDERECIPES_ABISAFE feature but feel it
> didn't meet
> the feature requirements of what this compatibility checker callback is
> doing,
> although maybe when porting to master we could refactor to make better use
> of
> the work already done there. The current implementation is a bit hacky but
> comments would be appreciated in regards to if the concept is feasible and
> if
> people are interested in making use of it and their use cases.
>
> Kind regards,
> Michael Ho
>
> --
> BMW Car IT GmbH
> Michael Ho
> Spezialist Entwicklung - Linux Software Integration
> Lise-Meitner-Str. 14
> 89081 Ulm
>
> Tel.: +49 731 3780 4071
> Mobil: +49 152 5498 0471
> Fax: +49-731-37804-001
> Mail: michael...@bmw-carit.de
> Web: http://www.bmw-carit.de
> 
> BMW Car IT GmbH
> Gechäftsführer: Kai-Uwe Balszuweit und Alexis Trolin
> Sitz und Registergericht: München HRB 134810
> 
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][meta-gplv2] gnutls: make it independent on gnutls.inc from oe-core

[Martin Jansa]

* also remove correct_rpl_gettimeofday_signature.patch like in
  commit e01e7c543a559c8926d72159b5cd55db0c661434
  Author: Richard Purdie <richard.pur...@linuxfoundation.org>
  Date:   Thu Jun 15 23:15:00 2017 +0100
  meta: Remove further uclibc remnants (inc. patches and site files)

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 recipes-support/gnutls/gnutls.inc   | 57 +
 recipes-support/gnutls/gnutls_3.3.27.bb |  8 +
 2 files changed, 58 insertions(+), 7 deletions(-)
 create mode 100644 recipes-support/gnutls/gnutls.inc

diff --git a/recipes-support/gnutls/gnutls.inc 
b/recipes-support/gnutls/gnutls.inc
new file mode 100644
index 000..4a5c3df
--- /dev/null
+++ b/recipes-support/gnutls/gnutls.inc
@@ -0,0 +1,57 @@
+SUMMARY = "GNU Transport Layer Security Library"
+HOMEPAGE = "http://www.gnu.org/software/gnutls/;
+BUGTRACKER = "https://savannah.gnu.org/support/?group=gnutls;
+
+LICENSE = "GPLv3+ & LGPLv2.1+"
+LICENSE_${PN} = "LGPLv2.1+"
+LICENSE_${PN}-xx = "LGPLv2.1+"
+LICENSE_${PN}-bin = "GPLv3+"
+LICENSE_${PN}-openssl = "GPLv3+"
+
+LIC_FILES_CHKSUM = "file://LICENSE;md5=71391c8e0c1cfe68077e7fce3b586283 \
+file://doc/COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+
file://doc/COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
+
+DEPENDS = "nettle gmp virtual/libiconv"
+DEPENDS_append_libc-musl = " argp-standalone"
+
+SHRT_VER = "${@d.getVar('PV').split('.')[0]}.${@d.getVar('PV').split('.')[1]}"
+
+SRC_URI = "ftp://ftp.gnutls.org/gcrypt/gnutls/v${SHRT_VER}/gnutls-${PV}.tar.xz;
+
+inherit autotools texinfo binconfig pkgconfig gettext lib_package gtk-doc
+
+PACKAGECONFIG ??= "libidn zlib"
+
+PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn"
+PACKAGECONFIG[libtasn1] = 
"--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
+PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
+PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
+PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
+
+EXTRA_OECONF = " \
+--enable-doc \
+--disable-libdane \
+--disable-guile \
+--disable-rpath \
+--enable-local-libopts \
+--enable-openssl-compatibility \
+--with-libpthread-prefix=${STAGING_DIR_HOST}${prefix} \
+"
+
+LDFLAGS_append_libc-musl = " -largp"
+LDFLAGS_append_libc-uclibc = " -luargp -pthread"
+
+do_configure_prepend() {
+   for dir in . lib; do
+   rm -f ${dir}/aclocal.m4 ${dir}/m4/libtool.m4 ${dir}/m4/lt*.m4
+   done
+}
+
+PACKAGES =+ "${PN}-openssl ${PN}-xx"
+
+FILES_${PN}-dev += "${bindir}/gnutls-cli-debug"
+FILES_${PN}-openssl = "${libdir}/libgnutls-openssl.so.*"
+FILES_${PN}-xx = "${libdir}/libgnutlsxx.so.*"
+
+BBCLASSEXTEND = "native nativesdk"
diff --git a/recipes-support/gnutls/gnutls_3.3.27.bb 
b/recipes-support/gnutls/gnutls_3.3.27.bb
index 9a8cd40..a1dcdb5 100644
--- a/recipes-support/gnutls/gnutls_3.3.27.bb
+++ b/recipes-support/gnutls/gnutls_3.3.27.bb
@@ -1,12 +1,9 @@
-require recipes-support/gnutls/gnutls.inc
+require gnutls.inc
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
 file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
 
-FILESEXTRAPATHS_prepend = 
"${THISDIR}/${BPN}:${COREBASE}/meta/recipes-support/${BPN}/${BPN}:"
-
 SRC_URI += " \
-file://correct_rpl_gettimeofday_signature.patch \
 file://configure.ac-fix-sed-command.patch \
 file://use-pkg-config-to-locate-zlib.patch \
 "
@@ -18,6 +15,3 @@ SRC_URI[sha256sum] = 
"8dfda16c158ef5c134010d51d1a91d02aa5d43b8cb711b1572650a7ffb
 PACKAGECONFIG[libidn] = ""
 # but it still has the libidn dependency, without this option
 EXTRA_OECONF += "--disable-crywrap"
-
-# This version doesn't support this option added in newer gnutls
-EXTRA_OECONF_remove = "--without-libunistring-prefix"
-- 
2.13.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-gplv2] gnutls: add use-pkg-config-to-locate-zlib.patch

[Martin Jansa]

ERROR: gnutls-3.3.27-r0 do_fetch: Fetcher failure for URL:
'file://correct_rpl_gettimeofday_signature.patch'. Unable to fetch URL
from any source.


On Fri, Jun 23, 2017 at 11:25 AM, Martin Jansa <martin.ja...@gmail.com>
wrote:

> Probably yes as it got broken again yesterday:
>
>
> On Mon, Jun 12, 2017 at 9:13 PM, Burton, Ross <ross.bur...@intel.com>
> wrote:
>
>>
>> On 12 June 2017 at 20:04, Andre McCurdy <armccu...@gmail.com> wrote:
>>
>>> Would it be better to just make the meta-gplv2 gnutls recipe self
>>> contained and stop trying to share a .inc file and patches with
>>> oe-core?
>>>
>>
>> Yes.
>>
>> Ross
>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-gplv2] gnutls: add use-pkg-config-to-locate-zlib.patch

[Martin Jansa]

Probably yes as it got broken again yesterday:


On Mon, Jun 12, 2017 at 9:13 PM, Burton, Ross  wrote:

>
> On 12 June 2017 at 20:04, Andre McCurdy  wrote:
>
>> Would it be better to just make the meta-gplv2 gnutls recipe self
>> contained and stop trying to share a .inc file and patches with
>> oe-core?
>>
>
> Yes.
>
> Ross
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Compiling meta-browser ==>chromium ? cleaning ?

[Martin Jansa]

You didn't say which versions you're using.

If you're using latest oe-core with gcc7 then you will need v3 version of
this change:
http://lists.openembedded.org/pipermail/openembedded-devel/2017-June/113247.html
I'll send it later today.

> And how can I clean after building it ? It took about 70Gb of my drive

Like any other recipe:
bitbake -c clean foo

On Sun, Jun 18, 2017 at 1:41 AM, Riko Ho  wrote:

> Hello Everyone,
>
> I tried to compile chromium but never succeeded, took me already 12 hours
> and stopped on 99%,
> I used bitbake for doing it,
>
> Is chromium not compatible with arm CPU ? it was working with X86_64
> before.
> And how can I clean after building it ? It took about 70Gb of my drive
>
> Thanks
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][meta-gplv2] gnutls: add use-pkg-config-to-locate-zlib.patch

[Martin Jansa]

* it was modified in oe-core/master in this commit:
commit ba7e5f51327d9833776aa066f30c5e46606be374
Author: Fan Xin <fan@jp.fujitsu.com>
Date:   Fri Jun 9 15:49:18 2017 +0900

gnutls: Upgrade to 3.5.13

1. Upgrade gnutls from 3.5.9 to 3.5.13

2. Rebase the following patch file.
   use-pkg-config-to-locate-zlib.patch

Signed-off-by: Fan Xin <fan@jp.fujitsu.com>
Signed-off-by: Ross Burton <ross.bur...@intel.com>

and no longer applies for this version.

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 .../gnutls/use-pkg-config-to-locate-zlib.patch | 67 ++
 recipes-support/gnutls/gnutls_3.3.27.bb|  2 +-
 2 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 
recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch

diff --git a/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch 
b/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch
new file mode 100644
index 000..0e1b7c8
--- /dev/null
+++ b/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch
@@ -0,0 +1,67 @@
+From cee80af1fe93f5b76765afeebfcc3b902768f5d6 Mon Sep 17 00:00:00 2001
+From: Andre McCurdy <armccu...@gmail.com>
+Date: Tue, 26 May 2015 21:41:24 -0700
+Subject: [PATCH] use pkg-config to locate zlib
+
+AC_LIB_HAVE_LINKFLAGS can sometimes find host libs and is therefore not
+robust when cross-compiling. Remove it for zlib and use PKG_CHECK_MODULES
+instead.
+
+Removing AC_LIB_HAVE_LINKFLAGS for zlib also removes the --with-libz-prefix
+configure option. If zlib support is enabled, then failure to find zlib via
+pkg-config is now treated as a fatal error.
+
+Change based on ChromeOS gnutls 2.12.23 cross-compile fixes patch:
+
+  https://chromium-review.googlesource.com/#/c/271661/
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Andre McCurdy <armccu...@gmail.com>
+---
+ configure.ac | 24 ++--
+ 1 file changed, 10 insertions(+), 14 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 1b561d5..0c787dc 100644
+--- a/configure.ac
 b/configure.ac
+@@ -508,25 +508,21 @@ AC_ARG_WITH(zlib, AS_HELP_STRING([--without-zlib],
+ AC_MSG_CHECKING([whether to include zlib compression support])
+ if test x$ac_zlib != xno; then
+  AC_MSG_RESULT(yes)
+- AC_LIB_HAVE_LINKFLAGS(z,, [#include ], [compress (0, 0, 0, 0);])
+- if test x$ac_cv_libz != xyes; then
+-   AC_MSG_WARN(
+-*** 
+-*** ZLIB was not found. You will not be able to use ZLIB compression.)
+- fi
+ else
+  AC_MSG_RESULT(no)
+ fi
+ 
+-PKG_CHECK_EXISTS(zlib, ZLIB_HAS_PKGCONFIG=y, ZLIB_HAS_PKGCONFIG=n)
+-
+ if test x$ac_zlib != xno; then
+-  if test "$ZLIB_HAS_PKGCONFIG" = "y" ; then
+-if test "x$GNUTLS_REQUIRES_PRIVATE" = x; then
+-  GNUTLS_REQUIRES_PRIVATE="Requires.private: zlib"
+-else
+-  GNUTLS_REQUIRES_PRIVATE="$GNUTLS_REQUIRES_PRIVATE, zlib"
+-fi
++  PKG_CHECK_MODULES(ZLIB, zlib)
++  HAVE_LIBZ=yes
++  AC_DEFINE([HAVE_LIBZ], [1], [zlib is enabled])
++  AC_SUBST(HAVE_LIBZ)
++  LTLIBZ=$ZLIB_LIBS
++  AC_SUBST(LTLIBZ)
++  if test "x$GNUTLS_REQUIRES_PRIVATE" = x; then
++GNUTLS_REQUIRES_PRIVATE="Requires.private: zlib"
++  else
++GNUTLS_REQUIRES_PRIVATE="$GNUTLS_REQUIRES_PRIVATE, zlib"
+   fi
+ fi
+ AC_SUBST(GNUTLS_REQUIRES_PRIVATE)
+-- 
+1.9.1
+
diff --git a/recipes-support/gnutls/gnutls_3.3.27.bb 
b/recipes-support/gnutls/gnutls_3.3.27.bb
index c98da34..9a8cd40 100644
--- a/recipes-support/gnutls/gnutls_3.3.27.bb
+++ b/recipes-support/gnutls/gnutls_3.3.27.bb
@@ -3,7 +3,7 @@ require recipes-support/gnutls/gnutls.inc
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
 file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
 
-FILESEXTRAPATHS_prepend = "${COREBASE}/meta/recipes-support/${BPN}/${BPN}:"
+FILESEXTRAPATHS_prepend = 
"${THISDIR}/${BPN}:${COREBASE}/meta/recipes-support/${BPN}/${BPN}:"
 
 SRC_URI += " \
 file://correct_rpl_gettimeofday_signature.patch \
-- 
2.13.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-raspberrypi] linux-raspberrypi_dev: don't use AUTOREV

[Martin Jansa]

And it's not clear from the diff you send, but like linux-yocto-dev.bb
example above, the recipe needs to be renamed from linux-raspberrypi_dev.bb
to linux-raspberrypi-dev.bb to make it different provider.

On Thu, Jun 1, 2017 at 9:08 AM, Martin Jansa <martin.ja...@gmail.com> wrote:

> Yes, Paul approach looks good to me, I think it was what was suggested in
> first replies to my SRCREV change and I agree with that, I just haven't had
> time to send updated patch.
>
> Paul if you have the patch ready please send it, thanks!.
>
> On Thu, Jun 1, 2017 at 8:10 AM, Paul Barker <pbar...@toganlabs.com> wrote:
>
>> On Thu, Jun 1, 2017 at 1:17 AM, Khem Raj <raj.k...@gmail.com> wrote:
>> > On Wed, May 31, 2017 at 5:00 PM, Andrei Gherzan <and...@gherzan.ro>
>> wrote:
>> >>
>> >> On Tue, May 30, 2017 at 6:29 PM, Khem Raj <raj.k...@gmail.com> wrote:
>> >>>
>> >>> On Tue, May 30, 2017 at 10:25 AM, Andre McCurdy <armccu...@gmail.com>
>> >>> wrote:
>> >>> > On Tue, May 30, 2017 at 10:15 AM, Paul Barker <
>> pbar...@toganlabs.com>
>> >>> > wrote:
>> >>> >> On 30 May 2017 5:08 p.m., "Khem Raj" <raj.k...@gmail.com> wrote:
>> >>> >>
>> >>> >> On Tue, May 30, 2017 at 12:57 AM, Martin Jansa <
>> martin.ja...@gmail.com>
>> >>> >> wrote:
>> >>> >>> * use latest revision in rpi-4.11.y branch
>> >>> >>> * using AUTOREV causes bitbake to run git ls-remote on the
>> github.com
>> >>> >>> repository in order
>> >>> >>>   to convert AUTOREV to currently latest SRCREV even when you
>> don't
>> >>> >>> use
>> >>> >>> linux-raspberrypi_dev
>> >>> >>>   at all, just happen to have meta-raspberrypi layer in your
>> >>> >>> bblayers.conf, that's bad for
>> >>> >>>   people who want to be able to build without network access
>> >>> >>> (completely
>> >>> >>> from premirror)
>> >>> >>>
>> >>> >>
>> >>> >> These branches get rebased often so locking SRCREV caused another
>> >>> >> kind of problem. what we can do is.
>> >>> >>
>> >>> >> 1. Let user like you override the SRCREC via a bbappend or conf
>> file.
>> >>> >> so change the assignment to ?=
>> >>> >> 2. Delete the recipe completely. We lose some of upstream testing.
>> >>> >>
>> >>> >> We should be able to skip the recipe if it isn't selected as the
>> >>> >> preferred
>> >>> >> version and/or provider of "virtual/kernel". I'm out at the minute
>> so
>> >>> >> can't
>> >>> >> look at it now but will try to take a look later this week.
>> >>> >
>> >>> > The linux-yocto-dev.bb recipe contains an example of doing that.
>> >>> >
>> >>>
>> >>> ah perfect. Thats what we need here
>> >>>
>> >>>
>> >>> http://cgit.openembedded.org/openembedded-core/tree/meta/rec
>> ipes-kernel/linux/linux-yocto-dev.bb?h=master#n28
>> >>>
>> >>> please rename the recipe to be linux-raspberrypi-dev.bb and add the
>> magic
>> >>> above and send a v2
>> >>>
>> >>
>> >> Using the magic above we still hardcode a revision there. So if a user
>> wants
>> >> to compile the recipe without setting the preferred provider it will
>> fail.
>> >
>> > what will be the usecase ? when you have a different kernel selected but
>> > woould like to compile yet another kernel
>> >
>> > that rev can be a well known rev like branchpoint. Moreover, I think
>> > if someone wants to use the dev recipe then its expected that they
>> > switch
>> > to using AUTOREV or some other local mechanism for pinning if needed.
>> >
>>
>> I was thinking of a different approach entirerly. We can add the
>> following at the top of the recipe file:
>>
>> python __anonymous() {
>> if "linux-raspberrypi-dev" not in
>> d.getVar("PREFERRED_PROVIDER_virtual/kernel"):
>> msg = "Skipping linux-raspberrypi-dev as it is not the preferred
>> " + \
>>   "provider of virtual/kernel."
>> raise bb.parse.SkipRecipe(msg)
>> }
>>
>> (Hopefully gmail won't mangle that too much)
>>
>> I've just tested it and it works fine as long as it's before the use
>> of ${AUTOREV}. If there's no objections to this approach I'll submit a
>> patch.
>>
>> Cheers,
>>
>> --
>> Paul Barker
>> Co-Founder & Principal Engineer
>> Togán Labs Ltd
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-raspberrypi] linux-raspberrypi_dev: don't use AUTOREV

[Martin Jansa]

Yes, Paul approach looks good to me, I think it was what was suggested in
first replies to my SRCREV change and I agree with that, I just haven't had
time to send updated patch.

Paul if you have the patch ready please send it, thanks!.

On Thu, Jun 1, 2017 at 8:10 AM, Paul Barker <pbar...@toganlabs.com> wrote:

> On Thu, Jun 1, 2017 at 1:17 AM, Khem Raj <raj.k...@gmail.com> wrote:
> > On Wed, May 31, 2017 at 5:00 PM, Andrei Gherzan <and...@gherzan.ro>
> wrote:
> >>
> >> On Tue, May 30, 2017 at 6:29 PM, Khem Raj <raj.k...@gmail.com> wrote:
> >>>
> >>> On Tue, May 30, 2017 at 10:25 AM, Andre McCurdy <armccu...@gmail.com>
> >>> wrote:
> >>> > On Tue, May 30, 2017 at 10:15 AM, Paul Barker <pbar...@toganlabs.com
> >
> >>> > wrote:
> >>> >> On 30 May 2017 5:08 p.m., "Khem Raj" <raj.k...@gmail.com> wrote:
> >>> >>
> >>> >> On Tue, May 30, 2017 at 12:57 AM, Martin Jansa <
> martin.ja...@gmail.com>
> >>> >> wrote:
> >>> >>> * use latest revision in rpi-4.11.y branch
> >>> >>> * using AUTOREV causes bitbake to run git ls-remote on the
> github.com
> >>> >>> repository in order
> >>> >>>   to convert AUTOREV to currently latest SRCREV even when you don't
> >>> >>> use
> >>> >>> linux-raspberrypi_dev
> >>> >>>   at all, just happen to have meta-raspberrypi layer in your
> >>> >>> bblayers.conf, that's bad for
> >>> >>>   people who want to be able to build without network access
> >>> >>> (completely
> >>> >>> from premirror)
> >>> >>>
> >>> >>
> >>> >> These branches get rebased often so locking SRCREV caused another
> >>> >> kind of problem. what we can do is.
> >>> >>
> >>> >> 1. Let user like you override the SRCREC via a bbappend or conf
> file.
> >>> >> so change the assignment to ?=
> >>> >> 2. Delete the recipe completely. We lose some of upstream testing.
> >>> >>
> >>> >> We should be able to skip the recipe if it isn't selected as the
> >>> >> preferred
> >>> >> version and/or provider of "virtual/kernel". I'm out at the minute
> so
> >>> >> can't
> >>> >> look at it now but will try to take a look later this week.
> >>> >
> >>> > The linux-yocto-dev.bb recipe contains an example of doing that.
> >>> >
> >>>
> >>> ah perfect. Thats what we need here
> >>>
> >>>
> >>> http://cgit.openembedded.org/openembedded-core/tree/meta/
> recipes-kernel/linux/linux-yocto-dev.bb?h=master#n28
> >>>
> >>> please rename the recipe to be linux-raspberrypi-dev.bb and add the
> magic
> >>> above and send a v2
> >>>
> >>
> >> Using the magic above we still hardcode a revision there. So if a user
> wants
> >> to compile the recipe without setting the preferred provider it will
> fail.
> >
> > what will be the usecase ? when you have a different kernel selected but
> > woould like to compile yet another kernel
> >
> > that rev can be a well known rev like branchpoint. Moreover, I think
> > if someone wants to use the dev recipe then its expected that they
> > switch
> > to using AUTOREV or some other local mechanism for pinning if needed.
> >
>
> I was thinking of a different approach entirerly. We can add the
> following at the top of the recipe file:
>
> python __anonymous() {
> if "linux-raspberrypi-dev" not in
> d.getVar("PREFERRED_PROVIDER_virtual/kernel"):
> msg = "Skipping linux-raspberrypi-dev as it is not the preferred "
> + \
>   "provider of virtual/kernel."
> raise bb.parse.SkipRecipe(msg)
> }
>
> (Hopefully gmail won't mangle that too much)
>
> I've just tested it and it works fine as long as it's before the use
> of ${AUTOREV}. If there's no objections to this approach I'll submit a
> patch.
>
> Cheers,
>
> --
> Paul Barker
> Co-Founder & Principal Engineer
> Togán Labs Ltd
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][meta-raspberrypi] linux-raspberrypi_dev: don't use AUTOREV

[Martin Jansa]

* use latest revision in rpi-4.11.y branch
* using AUTOREV causes bitbake to run git ls-remote on the github.com 
repository in order
  to convert AUTOREV to currently latest SRCREV even when you don't use 
linux-raspberrypi_dev
  at all, just happen to have meta-raspberrypi layer in your bblayers.conf, 
that's bad for
  people who want to be able to build without network access (completely from 
premirror)

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 recipes-kernel/linux/linux-raspberrypi_dev.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-raspberrypi_dev.bb 
b/recipes-kernel/linux/linux-raspberrypi_dev.bb
index 239d630..06771b9 100644
--- a/recipes-kernel/linux/linux-raspberrypi_dev.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_dev.bb
@@ -3,7 +3,7 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-dev:"
 LINUX_VERSION ?= "4.11"
 LINUX_RPI_DEV_BRANCH ?= "rpi-4.11.y"
 
-SRCREV = "${AUTOREV}"
+SRCREV = "3b3178eb6c0ddea0a6856f16f52b5d2c21ed9299"
 SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=${LINUX_RPI_DEV_BRANCH}
 \

file://0001-build-arm64-Add-rules-for-.dtbo-files-for-dts-overla.patch \
 "
-- 
2.13.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] webkitgtk2 progress bar

[Martin Jansa]

> I have 22 cores here, and it is not a luxury, but an absolute necessity
to get anything done as far as oe-core maintenance goes. Webkit's
do_compile takes about half an hour - I can almost see that progress bar
move :)

Heh, you're lucky with "oe-core maintenance".

My "bitbake world" builds have few components like this, webkitgtk (used to
have webkit1, webkit2 and webkit2-efl as separate builds), 2 chromiums (x11
and wayland), cef (luckily broken and whitelisted for a while), firefox,
qtwebengine, qtwebkit. Each taking usually even more time than "simplest"
webkitgtk2.

Building world with just oe-core takes just hour(s), add few layers like me
and it's day(s).

So progress bars are nice, but I still hate looking at them.

On Wed, May 24, 2017 at 6:43 PM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 05/24/2017 05:23 PM, Gary Thomas wrote:
>
>> Now [tongue-in-cheek], can someone do something about the horrendous
>> build times for such packages (webkitgtk2 can take up to 3 hours on
>> my [no so slow] build host!)?
>>
>
> In order of decreasing tongue in cheekiness.
>
> 1. Rewrite webkit in something that is not C++ - by far the most awful
> language when it comes to compile times.
>
> 2. Use icecc.bbclass to 'borrow' computing power from colleagues
> (untested, unproven).
>
> 3. Invest into a serious CPU. I have 22 cores here, and it is not a
> luxury, but an absolute necessity to get anything done as far as oe-core
> maintenance goes. Webkit's do_compile takes about half an hour - I can
> almost see that progress bar move :)
>
> Alex
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] webkitgtk2 progress bar

[Martin Jansa]

You can try to use gold to save a bit of time linking the beast.

On Wed, May 24, 2017 at 4:46 PM, Leonardo Sandoval <
leonardo.sandoval.gonza...@linux.intel.com> wrote:

> On Wed, 2017-05-24 at 16:23 +0200, Gary Thomas wrote:
> > I see that the latest master update has brought a progress bar
> > for this (and presumably other 'cmake' based packages) - very nice :-)
> >
> > Now [tongue-in-cheek], can someone do something about the horrendous
> > build times for such packages (webkitgtk2 can take up to 3 hours on
> > my [no so slow] build host!)?
>
>
> this is not easy and from my side what I have done some profiling based
> on the buildstats to figure out the top consumers recipes/tasks. As you
> mentioned, webkitgtk is the winner, at least for utimes!
>
> https://wiki.yoctoproject.org/wiki/MortyBuildstats
> https://wiki.yoctoproject.org/wiki/TipsAndTricks/InvestigatingBuildTime
>
> Leo
>
>
>
> >
> > --
> > 
> > Gary Thomas |  Consulting for the
> > MLB Associates  |Embedded world
> > 
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Qt 5.8: do_rootfs: File 'qtdeclarative-plugins' not found

[Martin Jansa]

No, this won't be added to meta-qt5 layer, because it's not the right fix.

If you're happy with empty packages, then you don't need meta-qt5 at all.

Empty packages are useless and bitbake is right not to create them.

My guess is that you don't have all necessary PACKAGECONFIGs enabled for
qtbase.

On Wed, Apr 26, 2017 at 8:27 AM, Malte Thiel  wrote:

> Hey,
>
> thanks, that solved my problem! Should probably added to the qt5 layer?
>
> Best
>
>
> On Tue, Apr 25, 2017 at 9:51 PM, Martin Kelly  wrote:
>
>> On 04/25/2017 07:41 AM, Malte Thiel wrote:
>>
>>> Hello,
>>>
>>> I am trying to compile a Qt 5.8 application using the master branch
>>> of meta-qt5/recipes-qt/qt5/ (For 5.8 support).
>>>
>>> Within my recipe I have:
>>>
>>> RDEPENDS_${PN} = "libgcc glibc qtbase [...] qtdeclarative"
>>>
>>> My recipe (and therefore the application) compiles fine. However, in
>>> do_rootfs I get the following error:
>>>
>>> 
>>> ERROR: my-image-1.0-r0 do_rootfs: Error executing a python function in
>>> exec_python_func() autogenerated:
>>>
>>> [...]
>>>
>>> Exception: FileNotFoundError: [Errno 2] No such file or directory:
>>> '/home/sec/sdk/build/0101301/tmp/sysroots/sm2-imx6/pkgdata/r
>>> untime-reverse/qtdeclarative-plugins'
>>>
>>> ERROR: my-image-1.0-r0 do_rootfs: Function failed:
>>> license_create_manifest
>>> 
>>>
>>> It's true, there is no file 'qtdeclarative-plugins'.
>>> However, qtdeclarative RPROVIDES qtdeclarative-plugins, so I expect that
>>> this file should be generated somehow?
>>>
>>> Any help is appreciated
>>>
>>>
>>>
>>>
>> Hi,
>>
>> I actually hit this issue as well. I discovered that
>> qtdeclarative-plugins wasn't being generated because it was empty, and by
>> default, bitbake won't generate an empty package. You can fix it by adding:
>>
>> ALLOW_EMPTY_${PN}-plugins = "1"
>>
>> to the qtdeclarative_git.bb file. That said, I'm not sure if this is the
>> right fix, or if there is some other reason why qtdeclarative-plugins is
>> not being generated.
>>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCHv2][meta-gplv2] gnutls: add older gnutls compatible with nettle

[Martin Jansa]

* gnutls depends on nettle-3.1* since 3.4.0:
  The requirement for nettle was bumped from 3.0 to 3.1 in gnutls_3_4_0
  
https://gitlab.com/gnutls/gnutls/commit/c84129af91b21d33ffe086e507632771b0e76498
  and from 2.7 to 3.0 a bit earlier also in gnutls_3_4_0
  
https://gitlab.com/gnutls/gnutls/commit/3fa80cf68919f07b3351b2722278ba463d6e731c
* add recipe for last release in 3.3 branch which is compatible
  with nettle 2.7.1 used in meta-gplv2

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 .../gnutls/configure.ac-fix-sed-command.patch  | 31 ++
 recipes-support/gnutls/gnutls_3.3.27.bb| 23 
 2 files changed, 54 insertions(+)
 create mode 100644 
recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
 create mode 100644 recipes-support/gnutls/gnutls_3.3.27.bb

diff --git a/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch 
b/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
new file mode 100644
index 000..44a9934
--- /dev/null
+++ b/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
@@ -0,0 +1,31 @@
+From eb93aa7b986c84da60a3db40afb29d1a70c50223 Mon Sep 17 00:00:00 2001
+From: Robert Yang <liezhi.y...@windriver.com>
+Date: Sat, 17 Jan 2015 17:02:15 +
+Subject: [PATCH] configure.ac: fix sed command
+
+The "sed 's/.bak//g'" matchs "bitbake", which would cause strange errors
+when the S contains "bitbake", fix to "sed 's/\.bak$//'`"
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang <liezhi.y...@windriver.com>
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index c6818a0..1c4582d 100644
+--- a/configure.ac
 b/configure.ac
+@@ -466,7 +466,7 @@ if test "$NEED_LIBOPTS_DIR" = "true";then
+   dnl replace libopts-generated files with distributed backups, if present
+   missing_baks=
+   for i in ${srcdir}/src/*-args.c.bak ${srcdir}/src/*-args.h.bak; do
+-  nam=`echo $i|sed 's/.bak//g'`
++  nam=`echo $i|sed 's/\.bak$//'`
+   if test -f $i;then
+   cp -f $i $nam
+   else
+-- 
+2.0.1
+
diff --git a/recipes-support/gnutls/gnutls_3.3.27.bb 
b/recipes-support/gnutls/gnutls_3.3.27.bb
new file mode 100644
index 000..c98da34
--- /dev/null
+++ b/recipes-support/gnutls/gnutls_3.3.27.bb
@@ -0,0 +1,23 @@
+require recipes-support/gnutls/gnutls.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
+
+FILESEXTRAPATHS_prepend = "${COREBASE}/meta/recipes-support/${BPN}/${BPN}:"
+
+SRC_URI += " \
+file://correct_rpl_gettimeofday_signature.patch \
+file://configure.ac-fix-sed-command.patch \
+file://use-pkg-config-to-locate-zlib.patch \
+"
+SRC_URI[md5sum] = "8ee8cebd7f7575b11f232766a21c31d3"
+SRC_URI[sha256sum] = 
"8dfda16c158ef5c134010d51d1a91d02aa5d43b8cb711b1572650a7ffb56b17f"
+
+# This version doesn't support this option added in newer gnutls
+# ERROR: gnutls-3.3.27-r0 do_configure: QA Issue: gnutls: configure was passed 
unrecognised options: --with-idn [unknown-configure-option]
+PACKAGECONFIG[libidn] = ""
+# but it still has the libidn dependency, without this option
+EXTRA_OECONF += "--disable-crywrap"
+
+# This version doesn't support this option added in newer gnutls
+EXTRA_OECONF_remove = "--without-libunistring-prefix"
-- 
2.12.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFC][meta-gplv2] layer priority and worth creating branch compatible with morty?

[Martin Jansa]

You're right, after fixing our tooling to correctly override
BBFILE_PRIORITY based on priorities in layer list I'm seeing such
issue.e.g. gstreamer failing with:

| autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac
  file requires the infrastructure from gettext-0.17 but this
version   is older. Please upgrade to gettext-0.17 or newer.
| autopoint: *** Stop.
|
| autopoint failed
| WARNING: exit code 1 from a shell command.

and similar issues in apt, grub, netcf, rrdtool.

There is quite a few native BBCLASSEXTENDs in meta-gplv2:
OE @ ~/meta-gplv2 $ git grep BBCLASSEXTEND
recipes-core/gettext/gettext_0.16.1.bb:BBCLASSEXTEND = "native nativesdk"
recipes-core/readline/readline_5.2.bb:BBCLASSEXTEND = "native nativesdk"
recipes-devtools/elfutils/elfutils_0.148.bb:BBCLASSEXTEND = "native
nativesdk"
recipes-devtools/m4/m4_1.4.9.bb:BBCLASSEXTEND = "nativesdk"
recipes-devtools/mtools/mtools_3.9.9.bb:BBCLASSEXTEND = "native nativesdk"
recipes-extended/cpio/cpio_v2.inc:BBCLASSEXTEND = "native"
recipes-extended/findutils/findutils.inc:BBCLASSEXTEND = "native nativesdk"
recipes-extended/gperf/gperf.inc:BBCLASSEXTEND = "native"
recipes-extended/libidn/libidn_0.6.14.bb:BBCLASSEXTEND = "native nativesdk"
recipes-extended/tar/tar.inc:BBCLASSEXTEND = "native nativesdk"
recipes-extended/texinfo/texinfo_4.8.bb:BBCLASSEXTEND = "native"
recipes-support/gdbm/gdbm_1.8.3.bb:BBCLASSEXTEND = "native nativesdk"
recipes-support/nettle/nettle.inc:BBCLASSEXTEND = "native nativesdk"





On Fri, Apr 21, 2017 at 11:19 PM, Andre McCurdy <armccu...@gmail.com> wrote:

> On Fri, Apr 21, 2017 at 1:59 PM, Martin Jansa <martin.ja...@gmail.com>
> wrote:
> > 1) layer priority, currently it has:
> >BBFILE_PRIORITY_gplv2 = "1"
> >which is lower than oe-core with:
> >BBFILE_PRIORITY_core = "5"
> >so in order to use recipes from meta-gplv2 layer, user has to add
> >couple PREFERRED_VERSIONS. Was this intended use for meta-gplv2?
>
> I guess the intention is that if you blacklist GPLv3 etc then only the
> recipes in meta-gplv2 will be considered.
>
> >I can see some advantages of this (that the layer can be included
> >without immediate side effects), but on the other hand why would
> >anyone include this layer if he isn't deeply scared from (L)GPLv3
> >versions sneaking into the build?
> >In our local builds I'm bumping the priority to 6 to resolve this.
>
> If any of the recipes in meta-gplv2 still contain BBCLASSEXTEND =
> "native" then that could cause problems (generally you only want to
> use the older recipes for the target, not for -native).
>
> >Alternatively we can add some conf/distro/gplv2-versions.inc file
> >in meta-gplv2 so that people who want to use all available recipes
> >in gplv2 compatible version can include it in their DISTRO.
> >
> > 2) branch for morty, currently the recipes aren't compatible with morty
> >but with e.g. gnutls version added there it might be better option
> >to share the gplv2 work there even when oe-core/morty contains most
> >of these recipes as well.
> >The recipes I had to modify to be compatible with morty are:
> >https://github.com/shr-project/meta-gplv2/commits/jansa/morty
> >88d1052 coreutils: make it compatible with Yocto 2.2 Morty
> >5e08ac2 rsync: make it compatible with Yocto 2.2 Morty
> >b33037f libiconv: make it compatible with Yocto 2.2 Morty
> >
> > --
> > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [RFC][meta-gplv2] layer priority and worth creating branch compatible with morty?

[Martin Jansa]

1) layer priority, currently it has:
   BBFILE_PRIORITY_gplv2 = "1"
   which is lower than oe-core with:
   BBFILE_PRIORITY_core = "5"
   so in order to use recipes from meta-gplv2 layer, user has to add
   couple PREFERRED_VERSIONS. Was this intended use for meta-gplv2?
   I can see some advantages of this (that the layer can be included
   without immediate side effects), but on the other hand why would
   anyone include this layer if he isn't deeply scared from (L)GPLv3
   versions sneaking into the build?
   In our local builds I'm bumping the priority to 6 to resolve this.
   Alternatively we can add some conf/distro/gplv2-versions.inc file
   in meta-gplv2 so that people who want to use all available recipes
   in gplv2 compatible version can include it in their DISTRO.

2) branch for morty, currently the recipes aren't compatible with morty
   but with e.g. gnutls version added there it might be better option
   to share the gplv2 work there even when oe-core/morty contains most
   of these recipes as well.
   The recipes I had to modify to be compatible with morty are:
   https://github.com/shr-project/meta-gplv2/commits/jansa/morty
   88d1052 coreutils: make it compatible with Yocto 2.2 Morty
   5e08ac2 rsync: make it compatible with Yocto 2.2 Morty
   b33037f libiconv: make it compatible with Yocto 2.2 Morty

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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][meta-gplv2] gnutls: add older gnutls compatible with nettle

[Martin Jansa]

I'll check the exact error message, but do_configure was failing for me
when I did first build without this dependency.

Most likely because this option was removed with 3.5.1 upgrade in:
commit e8ef5912aac0104d9a47d6d10a95e64426d8840e
Author: Alexander Kanavin <alexander.kana...@linux.intel.com>
Date:   Tue Jun 28 11:06:16 2016 +0300

gnutls: update to 3.5.1

Remove no longer supported --disable-crywrap option.
Add a checksum for the LICENSE file with licensing overview.

Signed-off-by: Alexander Kanavin <alexander.kana...@linux.intel.com>
Signed-off-by: Ross Burton <ross.bur...@intel.com>


I've verified that even with this build dependency the main libgnutls
package doesn't runtime depend on libidn, which is enough for us, if you
have strong opinion about --disable-crywrap then we can return it in the
recipes-support/gnutls/gnutls_3.3.27.bb

On Thu, Apr 20, 2017 at 7:59 PM, Andre McCurdy <armccu...@gmail.com> wrote:

> On Thu, Apr 20, 2017 at 9:20 AM, Martin Jansa <martin.ja...@gmail.com>
> wrote:
> > * gnutls depends on nettle-3.1* since 3.4.0:
> >   The requirement for nettle was bumped from 3.0 to 3.1 in gnutls_3_4_0
> >   https://gitlab.com/gnutls/gnutls/commit/c84129af91b21d33ffe086e5076327
> 71b0e76498
> >   and from 2.7 to 3.0 a bit earlier also in gnutls_3_4_0
> >   https://gitlab.com/gnutls/gnutls/commit/3fa80cf68919f07b3351b2722278ba
> 463d6e731c
> > * add recipe for last release in 3.3 branch which is compatible
> >   with nettle 2.7.1 used in meta-gplv2
> >
> > Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
> > ---
> >  .../gnutls/configure.ac-fix-sed-command.patch  | 31
> ++
> >  recipes-support/gnutls/gnutls_3.3.27.bb| 23
> 
> >  2 files changed, 54 insertions(+)
> >  create mode 100644 recipes-support/gnutls/gnutls/
> configure.ac-fix-sed-command.patch
> >  create mode 100644 recipes-support/gnutls/gnutls_3.3.27.bb
> >
> > diff --git 
> > a/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
> b/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
> > new file mode 100644
> > index 000..44a9934
> > --- /dev/null
> > +++ b/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
> > @@ -0,0 +1,31 @@
> > +From eb93aa7b986c84da60a3db40afb29d1a70c50223 Mon Sep 17 00:00:00 2001
> > +From: Robert Yang <liezhi.y...@windriver.com>
> > +Date: Sat, 17 Jan 2015 17:02:15 +
> > +Subject: [PATCH] configure.ac: fix sed command
> > +
> > +The "sed 's/.bak//g'" matchs "bitbake", which would cause strange errors
> > +when the S contains "bitbake", fix to "sed 's/\.bak$//'`"
> > +
> > +Upstream-Status: Pending
> > +
> > +Signed-off-by: Robert Yang <liezhi.y...@windriver.com>
> > +---
> > + configure.ac | 2 +-
> > + 1 file changed, 1 insertion(+), 1 deletion(-)
> > +
> > +diff --git a/configure.ac b/configure.ac
> > +index c6818a0..1c4582d 100644
> > +--- a/configure.ac
> >  b/configure.ac
> > +@@ -466,7 +466,7 @@ if test "$NEED_LIBOPTS_DIR" = "true";then
> > +   dnl replace libopts-generated files with distributed backups, if
> present
> > +   missing_baks=
> > +   for i in ${srcdir}/src/*-args.c.bak ${srcdir}/src/*-args.h.bak;
> do
> > +-  nam=`echo $i|sed 's/.bak//g'`
> > ++  nam=`echo $i|sed 's/\.bak$//'`
> > +   if test -f $i;then
> > +   cp -f $i $nam
> > +   else
> > +--
> > +2.0.1
> > +
> > diff --git a/recipes-support/gnutls/gnutls_3.3.27.bb
> b/recipes-support/gnutls/gnutls_3.3.27.bb
> > new file mode 100644
> > index 000..2828581
> > --- /dev/null
> > +++ b/recipes-support/gnutls/gnutls_3.3.27.bb
> > @@ -0,0 +1,23 @@
> > +require recipes-support/gnutls/gnutls.inc
> > +
> > +LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504
> \
> > +file://COPYING.LESSER;md5=
> a6f89e2100d9b6cdffcea4f398e37343"
> > +
> > +FILESEXTRAPATHS_prepend = "${COREBASE}/meta/recipes-
> support/${BPN}/${BPN}:"
> > +
> > +SRC_URI += " \
> > +file://correct_rpl_gettimeofday_signature.patch \
> > +file://configure.ac-fix-sed-command.patch \
> > +file://use-pkg-config-to-locate-zlib.patch \
> > +"
> > +SRC_URI[md5sum] = "8ee8cebd7f7575b11f232766a21c31d3"
> > +SRC_URI[sha256sum] = "8dfda16c158ef5c134010d51d1a91d
> 02aa5d43b8cb71

[yocto] [PATCH][meta-gplv2] gnutls: add older gnutls compatible with nettle

[Martin Jansa]

* gnutls depends on nettle-3.1* since 3.4.0:
  The requirement for nettle was bumped from 3.0 to 3.1 in gnutls_3_4_0
  
https://gitlab.com/gnutls/gnutls/commit/c84129af91b21d33ffe086e507632771b0e76498
  and from 2.7 to 3.0 a bit earlier also in gnutls_3_4_0
  
https://gitlab.com/gnutls/gnutls/commit/3fa80cf68919f07b3351b2722278ba463d6e731c
* add recipe for last release in 3.3 branch which is compatible
  with nettle 2.7.1 used in meta-gplv2

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 .../gnutls/configure.ac-fix-sed-command.patch  | 31 ++
 recipes-support/gnutls/gnutls_3.3.27.bb| 23 
 2 files changed, 54 insertions(+)
 create mode 100644 
recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
 create mode 100644 recipes-support/gnutls/gnutls_3.3.27.bb

diff --git a/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch 
b/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
new file mode 100644
index 000..44a9934
--- /dev/null
+++ b/recipes-support/gnutls/gnutls/configure.ac-fix-sed-command.patch
@@ -0,0 +1,31 @@
+From eb93aa7b986c84da60a3db40afb29d1a70c50223 Mon Sep 17 00:00:00 2001
+From: Robert Yang <liezhi.y...@windriver.com>
+Date: Sat, 17 Jan 2015 17:02:15 +
+Subject: [PATCH] configure.ac: fix sed command
+
+The "sed 's/.bak//g'" matchs "bitbake", which would cause strange errors
+when the S contains "bitbake", fix to "sed 's/\.bak$//'`"
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang <liezhi.y...@windriver.com>
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index c6818a0..1c4582d 100644
+--- a/configure.ac
 b/configure.ac
+@@ -466,7 +466,7 @@ if test "$NEED_LIBOPTS_DIR" = "true";then
+   dnl replace libopts-generated files with distributed backups, if present
+   missing_baks=
+   for i in ${srcdir}/src/*-args.c.bak ${srcdir}/src/*-args.h.bak; do
+-  nam=`echo $i|sed 's/.bak//g'`
++  nam=`echo $i|sed 's/\.bak$//'`
+   if test -f $i;then
+   cp -f $i $nam
+   else
+-- 
+2.0.1
+
diff --git a/recipes-support/gnutls/gnutls_3.3.27.bb 
b/recipes-support/gnutls/gnutls_3.3.27.bb
new file mode 100644
index 000..2828581
--- /dev/null
+++ b/recipes-support/gnutls/gnutls_3.3.27.bb
@@ -0,0 +1,23 @@
+require recipes-support/gnutls/gnutls.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
+
+FILESEXTRAPATHS_prepend = "${COREBASE}/meta/recipes-support/${BPN}/${BPN}:"
+
+SRC_URI += " \
+file://correct_rpl_gettimeofday_signature.patch \
+file://configure.ac-fix-sed-command.patch \
+file://use-pkg-config-to-locate-zlib.patch \
+"
+SRC_URI[md5sum] = "8ee8cebd7f7575b11f232766a21c31d3"
+SRC_URI[sha256sum] = 
"8dfda16c158ef5c134010d51d1a91d02aa5d43b8cb711b1572650a7ffb56b17f"
+
+# This version doesn't support this option added in newer gnutls
+# ERROR: gnutls-3.3.27-r0 do_configure: QA Issue: gnutls: configure was passed 
unrecognised options: --with-idn [unknown-configure-option]
+PACKAGECONFIG[libidn] = ""
+# but it has the dependency
+DEPENDS += "libidn"
+
+# This version doesn't support this option added in newer gnutls
+EXTRA_OECONF_remove = "--without-libunistring-prefix"
-- 
2.12.2

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][meta-gplv2] bison: add missing patch from oe-core

[Martin Jansa]

* meta-gplv2/recipes-devtools/bison/bison_2.3.bb: Unable to get checksum for 
bison SRC_URI entry bison-2.3_m4.patch: file
 could not be found

Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
---
 recipes-devtools/bison/bison/bison-2.3_m4.patch | 591 
 1 file changed, 591 insertions(+)
 create mode 100644 recipes-devtools/bison/bison/bison-2.3_m4.patch

diff --git a/recipes-devtools/bison/bison/bison-2.3_m4.patch 
b/recipes-devtools/bison/bison/bison-2.3_m4.patch
new file mode 100644
index 000..348ce1d
--- /dev/null
+++ b/recipes-devtools/bison/bison/bison-2.3_m4.patch
@@ -0,0 +1,591 @@
+Upstream-Status: Pending
+
+#
+# Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher
+#
+
+--- /dev/null
 bison-1.875/m4/inttypes-pri.m4
+@@ -0,0 +1,32 @@
++# inttypes-pri.m4 serial 1 (gettext-0.11.4)
++dnl Copyright (C) 1997-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU
++dnl General Public License.  As a special exception to the GNU General
++dnl Public License, this file may be distributed as part of a program
++dnl that contains a configuration script generated by Autoconf, under
++dnl the same distribution terms as the rest of that program.
++
++dnl From Bruno Haible.
++
++# Define PRI_MACROS_BROKEN if  exists and defines the PRI*
++# macros to non-string values.  This is the case on AIX 4.3.3.
++
++AC_DEFUN([gt_INTTYPES_PRI],
++[
++  AC_REQUIRE([gt_HEADER_INTTYPES_H])
++  if test $gt_cv_header_inttypes_h = yes; then
++AC_CACHE_CHECK([whether the inttypes.h PRIxNN macros are broken],
++  gt_cv_inttypes_pri_broken,
++  [
++AC_TRY_COMPILE([#include 
++#ifdef PRId32
++char *p = PRId32;
++#endif
++], [], gt_cv_inttypes_pri_broken=no, gt_cv_inttypes_pri_broken=yes)
++  ])
++  fi
++  if test "$gt_cv_inttypes_pri_broken" = yes; then
++AC_DEFINE_UNQUOTED(PRI_MACROS_BROKEN, 1,
++  [Define if  exists and defines unusable PRI* macros.])
++  fi
++])
+--- /dev/null
 bison-1.875/m4/lcmessage.m4
+@@ -0,0 +1,32 @@
++# lcmessage.m4 serial 3 (gettext-0.11.3)
++dnl Copyright (C) 1995-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU
++dnl General Public License.  As a special exception to the GNU General
++dnl Public License, this file may be distributed as part of a program
++dnl that contains a configuration script generated by Autoconf, under
++dnl the same distribution terms as the rest of that program.
++dnl
++dnl This file can can be used in projects which are not available under
++dnl the GNU General Public License or the GNU Library General Public
++dnl License but which still want to provide support for the GNU gettext
++dnl functionality.
++dnl Please note that the actual code of the GNU gettext library is covered
++dnl by the GNU Library General Public License, and the rest of the GNU
++dnl gettext package package is covered by the GNU General Public License.
++dnl They are *not* in the public domain.
++
++dnl Authors:
++dnl   Ulrich Drepper <drep...@cygnus.com>, 1995.
++
++# Check whether LC_MESSAGES is available in .
++
++AC_DEFUN([AM_LC_MESSAGES],
++[
++  AC_CACHE_CHECK([for LC_MESSAGES], am_cv_val_LC_MESSAGES,
++[AC_TRY_LINK([#include ], [return LC_MESSAGES],
++   am_cv_val_LC_MESSAGES=yes, am_cv_val_LC_MESSAGES=no)])
++  if test $am_cv_val_LC_MESSAGES = yes; then
++AC_DEFINE(HAVE_LC_MESSAGES, 1,
++  [Define if your  file defines LC_MESSAGES.])
++  fi
++])
+--- /dev/null
 bison-1.875/m4/uintmax_t.m4
+@@ -0,0 +1,29 @@
++# uintmax_t.m4 serial 6 (gettext-0.11)
++dnl Copyright (C) 1997-2002 Free Software Foundation, Inc.
++dnl This file is free software, distributed under the terms of the GNU
++dnl General Public License.  As a special exception to the GNU General
++dnl Public License, this file may be distributed as part of a program
++dnl that contains a configuration script generated by Autoconf, under
++dnl the same distribution terms as the rest of that program.
++
++dnl From Paul Eggert.
++
++AC_PREREQ(2.13)
++
++# Define uintmax_t to `unsigned long' or `unsigned long long'
++# if  does not exist.
++
++AC_DEFUN([jm_AC_TYPE_UINTMAX_T],
++[
++  AC_REQUIRE([jm_AC_HEADER_INTTYPES_H])
++  AC_REQUIRE([jm_AC_HEADER_STDINT_H])
++  if test $jm_ac_cv_header_inttypes_h = no && test $jm_ac_cv_header_stdint_h 
= no; then
++AC_REQUIRE([jm_AC_TYPE_UNSIGNED_LONG_LONG])
++test $ac_cv_type_unsigned_long_long = yes \
++  && ac_type='unsigned long long' \
++  || ac_type='unsigned long'
++AC_DEFINE_UNQUOTED(uintmax_t, $ac_type,
++  [Define to unsigned long or unsigned long long
++   if  and  don't define.])
++  fi
++])
+--- /dev/null
 bison-1.875/m4/glibc21.m4
+@@ -0,0 +1,32 @@
++# glibc21.m4 serial 2 (fileutils-4.1.3, gettext-0.10.40)
++dnl Copyright (C) 2000-2002 Free Software Foundation, Inc.
++dnl This file is free software, 

Re: [yocto] meta-efl build?

[Martin Jansa]

On Thu, Feb 16, 2017 at 07:48:33AM +, Takashi Matsuzawa wrote:
> Hello.
> 
> Thank you very much for the pointer, but I think this image is x11 based..
> 
> I can see EFL project has some pages mentioning about booting EFL on 
> wayland-only environment, but it is not yocto (or oe) based instruction.

I was always using meta-efl only in x11 builds.

There is wayland PACKAGECONFIG for efl:
recipes-efl/efl/efl.inc:PACKAGECONFIG ?= "egl opengl-es gstreamer1
pulseaudio luajit ${@bb.utils.contains('DISTRO_FEATURES', 'wayland',
'wayland', '', d)}"
recipes-efl/efl/efl.inc:PACKAGECONFIG[wayland] = "--enable-wayland
--enable-wayland-ivi-shell,--disable-wayland
--disable-wayland-ivi-shell,wayland"

but in e-wm which you were probably trying to build (it's not clear what
exactly you meant with "build EFL") there is indeed dependency on
libxcb.

So it will need few more changes and lot more testing to make it work on
wayland-only, patches are welcome, but EFL is in sad state in current
master branch and I'm not planing to spend much time on it now, because
I don't use it anymore (we officially let SHR distribution die last
month by stopping the build server) and with the switch to CMake in
upcoming release there will be again more work needed to build/package
new version.

Patches from people who are still using it (and able to test it
properly) are of course welcome.

Regards,

> 
> From: Khem Raj 
> Sent: Thursday, February 16, 2017 11:53 AM
> To: Takashi Matsuzawa
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] meta-efl build?
> 
> Takashi-san
> 
> On Wed, Feb 15, 2017 at 6:35 PM, Takashi Matsuzawa  
> wrote:
> > Hello, Yocto.
> >
> >
> > I am trying to build EFL on top of my mayland environment (krogoth based).
> >
> > I thought it would be easy since there is meta-openembedded/meta-efl
> > recipes, but now I am stuck.
> >
> >
> > Specifically, I am experiencing x11 dependency (the recipes erquire x11 to
> > be in DISTRO_FEATURES here and elsewhere), but for my target I am settting
> > wayland only, no x11.
> >
> > (e.g. it says it needs libxcb, etc.)
> >
> >
> > Is it normal and I am failing to configure it properly?
> >
> >
> > I found below, but it does not talk much about the build errors I am facing,
> > and if the targets I am specifying is correct, etc.
> >
> >
> > https://www.enlightenment.org/distros/yocto-start
> Yocto - Enlightenment Main
> www.enlightenment.org
> In Yocto, a meta-efl layer is provided by the meta-openembedded layer. It 
> contains EFL, Elementary, Enlightenment, Terminology and other recipes.
> 
> 
> 
> >
> > If you are aware of any previous attempt, or, guide that I just overlooked
> > for my laziness - I highly appreciate your pointers.
> >
> 
> Using some preexisting image like angstrom one would be a good start
> for you e.g.
> 
> https://github.com/Angstrom-distribution/meta-angstrom/blob/master/recipes-images/angstrom/efl-nodm-image.bb
> meta-angstrom/efl-nodm-image.bb at master · 
> Angstrom-distribution/meta-angstrom · 
> GitHub
> github.com
> meta-angstrom - MIrror of Angstrom metadata layer
> 
> 
> 
> 
> it should work if you were to use angstrom distribution but if you
> dont it should serve a good jump start.

> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [bitbake-devel] [oe] Infra Full Stop 12/26-12/29

[Martin Jansa]

On Sun, Dec 25, 2016 at 08:06:50PM -0800, Michael Halstead wrote:
> In preparation for the scheduled maintenance I have moved
> git.openembedded.org to a new server temporarily. E-mail and Patchwork
> hooks may not work correctly. All other git operations as well as
> listings at http://git.openembedded.org/ should continue working.
> 
> If you have a git remote pointed directly at openembedded.org it will
> fail. Please update your remote to point at git.openembedded.org and try
> again.

It doesn't seem to be working here:

error: Could not fetch origin
fatal: unable to connect to git.openembedded.org:
git.openembedded.org[0: 104.236.212.160]: errno=Connection refused
git.openembedded.org[1: 2604:a880:800:10::2127:2001]: errno=Network is 
unreachable

But that's OK for me, I was prepared to do some holiday celebrations
thanks to planned downtime :). And I have some local mirrors in case
I got tired of celebrations before the downtime is over.

> Other services that will stay up during the maintenance are:
> 
> Layerindex https://layers.openembedded.org/
> Mailman http://lists.openembedded.org/
> Patchwork https://patchwork.openembedded.org/
> 
> I'd like the share my appreciation for the OpenEmbedded volunteer
> sysadmins who are taking time away from their holiday celebrations to
> make this downtime as convenient for the rest of us as possible.
> 
> 
> On 12/22/2016 09:19 AM, Tom King wrote:
> > Schedule is  06:00UTC 27DEC16 for the full stop.  Things will start coming
> > back (estimated) about 48hrs later.
> >
> > Tom
> >
> > On Tue, Dec 20, 2016 at 11:16 AM, Khem Raj  wrote:
> >
> >>> On Dec 20, 2016, at 10:50 AM, Tom King  wrote:
> >>>
> >>> Hi All,
> >>>
> >>> We have been looking for a time when we could do a full stop of the infra
> >>> to upgrade some bits and clear out some faults.
> >>>
> >>> This will involve shutting down the main machine that we use for *most*
> >> of
> >>> the OE infra.
> >>>
> >>> Our goal is to put up a backup git master but other services such as:
> >> wiki,
> >>> patches, etc will be offline for some or all of that period.
> >>>
> >>> We have delayed doing this much needed maintenance to try to work around
> >>> Yocto and OE release schedules and it is necessary that we take this time
> >>> to do the work.
> >>>
> >> I guess, you need to come up with a tentative down-time schedule.
> >>
> >>> Tom
> >>> (for the OE Infra Team)
> >>> --
> >>> ___
> >>> Openembedded-devel mailing list
> >>> openembedded-de...@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >> --
> >> ___
> >> Openembedded-devel mailing list
> >> openembedded-de...@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >>
> 
> -- 
> Michael Halstead
> Linux Foundation / SysAdmin
> 
> 




> -- 
> ___
> bitbake-devel mailing list
> bitbake-de...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/bitbake-devel


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


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't set march=armv5te

[Martin Jansa]

The package architecture was change to match with compiler flags used in
build.

Most people were assuming that they are using thumb when they have seen "t"
in package arch, but because default value of ARM_INSTRUCTION_SET is "arm"
they in most cases weren't actually building with -mthumb.

On Thu, Dec 1, 2016 at 8:54 PM, Bryan Evenson <beven...@melinkcorp.com>
wrote:

> Martin,
>
>
>
> OK, so regardless of what the arch was finally getting set at, in this
> case since “-marm” was in the GCC compiler options it was always compiling
> all the code in ARM mode and never in Thumb mode, correct?
>
>
>
> It still bugs me why the architecture name changed (I’ve traced through
> the machine include path several times), but if at the end of the day it’ll
> be compiling the same code then I’ll move on to some more productive tasks.
>
>
>
> Thanks,
>
> Bryan
>
>
>
> *From:* Martin Jansa [mailto:martin.ja...@gmail.com]
> *Sent:* Thursday, December 01, 2016 2:06 PM
> *To:* Bryan Evenson <beven...@melinkcorp.com>
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Can't set march=armv5te
>
>
>
> Using and not using thumb was also controlled not only by TUNE_FEATURES
> (MACHINE defines that) but also by ARM_INSTRUCTION_SET (DISTRO defines
> that).
>
>
>
> So you weren't building with thumb enabled even when you were seeing
> armv5te before.
>
>
>
> On Thu, Dec 1, 2016 at 5:26 PM, Bryan Evenson <beven...@melinkcorp.com>
> wrote:
>
> I'm in the process of upgrading from the dizzy branch to the fido branch,
> and I'm still a little confused about some tune changes that I'm seeing.
> I'm using an Atmel AT91SAM9G25 processor.  The meta-atmel layer that I am
> using had incorrectly set DEFAULTTUNE = "arm926ejs" which had been setting
> the architecture to "arm926ejste".  They fixed that here:
> https://github.com/linux4sam/meta-atmel/commit/
> 47238062c04ca97c2ea0570576072ad5b46ce261 and according to the commit
> message it should now be building with DEFAULTTUNE (and the resulting
> architecture) set to "armv5te".  However, when I build using my autobuilder
> I am getting an architecture of "armv5e".  From my understanding, this
> means the compiler thinks the processor does not have Thumb support.  I've
> tried "arm926ejs" and "armv5te" for DEFAULTTUNE settings and it hasn't made
> any difference.
>
> I've checked the working directories for a few packages, and previously
> the relevant gcc options were being set to: "-march=armv5te -marm
> -mthumb-interwork -mtune=arm926ej-s".  Now they are being set to:
> "-march=armv5e -marm  -mthumb-interwork".  How do I get it back to building
> with march=armv5te?
>
> Here is the autobuilder configuration that I am using:
>
> [nightly-atmel-demo-fido]
> builders: 'builder1'
> repos: [{'poky':
> {'repourl':'git://git.yoctoproject.org/poky',
>  'layerversion':{'core':'meta',
> 'yoctobsp':'meta-yocto-bsp', 'yocto':'meta-yocto', 'poky':'meta-poky'},
>  'branch':'fido'}},
> {'meta-atmel':
> {'repourl':'git://github.com/linux4sam/meta-atmel.git',
>  'branch':'fido'}},
> {'meta-openembedded':
> {'autoinclude':False, 'repourl':'git://git.
> openembedded.org/meta-openembedded',
>  'branch':'fido'}},
> {'meta-qt5':
> {'repourl':'git://github.com/meta-qt5/meta-qt5.git',
>  'branch':'fido'}}]
> steps: [{'SetDest':{}},
> {'CheckOutLayers': {}},
> {'RunPreamble': {}},
> {'GetDistroVersion' : {'distro': 'poky'}},
> {'CreateAutoConf': {'machine': 'at91sam9x5ek', 'SDKMACHINE':
> 'i686', 'distro': 'poky-atmel', 'buildhistory': True, 'packages': 'ipk',
> 'atextappend': 'EXTRA_IMAGE_FEATURES = ""\nDEFAULTTUNE = "armv5te"\n'}},
> {'CreateBBLayersConf': {'buildprovider' : 'yocto', 'layerdirs':
> ['meta-atmel', 'meta-qt5', 'meta-openembedded/meta-oe',
> 'meta-openembedded/meta-networking', 'meta-openembedded/meta-python']}},
> {'BuildImages': {'images': 'atmel-demo-image'}},
> {'SyncPersistDB' : {'commit' : True, 'distro':'poky'}},
> {'PublishLayerTarballs':{}},
> {'PublishArtifacts': {'artifacts': ['at91sam9x5ek', 'ipk']}}]
> scheduler: [{'nightly-scheduler-atmel-fido' :
> {'type':'Nightly',
>  'hour':'1',
>  'minute':'15',}}]
>
> The resulting build configuration:
> Build Configuration:
> BB_VERSION= "1.26.0"
> BUILD_SYS = "x86_64-linux"
> NATIVE

Re: [yocto] Shared state doesn't live up to its name?

[Martin Jansa]

Compare the signatures of these 2 native builds.

I'm still using sstate-diff-machines.sh to create archives of sstate
signatures for interesting builds, so that I can easily compare them with
other builds or the same build performed on different builder to see why
something wasn't reused form sstate.

On Thu, Dec 1, 2016 at 10:27 AM, Gary Thomas  wrote:

> I have a build machine where I build for lots of targets.  On
> all of these targets (save a primary), I set the SSTATE_MIRROR
> to point to the sstate-cache of the primary target.  I always build
> for the primary target first, then later the secondary ones.
>
> For the most part, the sstate mechanism works pretty well, but I
> see some anomalies.  For example, why on the same host, built back
> to back, would a secondary build target (which uses the primary
> as it's SSTATE_MIRROR and that build is complete) need to rebuild
> from scratch such NATIVE packages as openssl?  Note that these are
> native packages I'm asking about, so in my mind they should always
> be sharable.
>
> Any ideas?  Is there something I can look at to investigate this?
>
> Thanks
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto