Openembedded Core Discussions
 help / color / mirror / Atom feed
* [PATCH v3 1/3] arch-arm64.inc: include arch-armv7ve instead of arch-armv7a
From: Herve Jourdain @ 2016-11-20 12:10 UTC (permalink / raw)
  To: openembedded-core
In-Reply-To: <1479643823-11675-1-git-send-email-herve.jourdain@neuf.fr>

Signed-off-by: Herve Jourdain <herve.jourdain@neuf.fr>
---
 meta/conf/machine/include/arm/arch-arm64.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/arm/arch-arm64.inc b/meta/conf/machine/include/arm/arch-arm64.inc
index 9440698..9eeffac 100644
--- a/meta/conf/machine/include/arm/arch-arm64.inc
+++ b/meta/conf/machine/include/arm/arch-arm64.inc
@@ -1,6 +1,6 @@
 DEFAULTTUNE ?= "aarch64"
 
-require conf/machine/include/arm/arch-armv7a.inc
+require conf/machine/include/arm/arch-armv7ve.inc
 
 TUNEVALID[aarch64] = "Enable instructions for aarch64"
 
-- 
2.7.4



^ permalink raw reply related

* [PATCH v3 0/3] Add a tune file for cortexa53, valid for 32 bits and 64 bits
From: Herve Jourdain @ 2016-11-20 12:10 UTC (permalink / raw)
  To: openembedded-core

Add a tune file for cortexa53, valid for 32 bits and 64 bits
It requires adding options in arch-armv8.inc to support 32 bits options

Herve Jourdain (3):
  arch-arm64.inc: include arch-armv7ve instead of arch-armv7a
  arch-armv8.inc: add support for 32bits armv8 options
  Add a tune file for cortexa53, valid for 32 bits and 64 bits

 meta/conf/machine/include/arm/arch-arm64.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv8.inc | 60 ++++++++++++++++++++++++++++
 meta/conf/machine/include/tune-cortexa53.inc | 43 ++++++++++++++++++++
 3 files changed, 104 insertions(+), 1 deletion(-)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.7.4



^ permalink raw reply

* Re: [PATCH v2 0/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits
From: Herve Jourdain @ 2016-11-20  8:07 UTC (permalink / raw)
  To: openembedded-core
In-Reply-To: <1479559833-128256-1-git-send-email-herve.jourdain@neuf.fr>

Please disregard this patch, it's not working fine for 32bits (cortex-a53
must have armv8+crc as arch), v3 coming soon.

Sorry for that.

Herve

-----Original Message-----
From: Herve Jourdain [mailto:herve.jourdain@neuf.fr] 
Sent: samedi 19 novembre 2016 13:51
To: openembedded-core@lists.openembedded.org
Cc: Herve Jourdain <herve.jourdain@neuf.fr>
Subject: [oe-core][PATCH v2 0/1] Add a tune file for cortexa53, valid for 32
bits and 64 bits

Tune file for ARM Cortex-A53, supporting 32 bits and 64 bits configuration

Herve Jourdain (1):
  Add a tune file for cortexa53, valid for 32 bits and 64 bits

 meta/conf/machine/include/tune-cortexa53.inc | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.7.4



^ permalink raw reply

* Re: [PATCH v2 1/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits
From: Herve Jourdain @ 2016-11-20  8:05 UTC (permalink / raw)
  To: 'Khem Raj'
  Cc: 'Patches and discussions about the oe-core layer'
In-Reply-To: <CAMKF1so0YG5cy49tG2Efm-arFfxDbEoZgrP_5JNM9+ch_pr=cg@mail.gmail.com>

Hi Khem,

Unfortunately, it has a few issues in 32bits mode...
Basically, cortex-a53 is an armv8+crc...
I'm sending an updated version - v3 - soon.
But I'll run the tune checker first. At least, the new version I'm coming up with and plan to send soon seems to work fine now with 32bits - and I shouldn't have broken the 64bits support in the process, but I will also compile it.

Herve

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com] 
Sent: samedi 19 novembre 2016 18:51
To: Herve Jourdain <herve.jourdain@neuf.fr>
Cc: Patches and discussions about the oe-core layer <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [oe-core][PATCH v2 1/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits

This seems fine to me. There is a tune checker that Martin has, it would be good to run that and see if this new tune is tested.

http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test


On Sat, Nov 19, 2016 at 4:50 AM, Herve Jourdain <herve.jourdain@neuf.fr> wrote:
> Signed-off-by: Herve Jourdain <herve.jourdain@neuf.fr>
> ---
>  meta/conf/machine/include/tune-cortexa53.inc | 22 
> ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>  create mode 100644 meta/conf/machine/include/tune-cortexa53.inc
>
> diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
> b/meta/conf/machine/include/tune-cortexa53.inc
> new file mode 100644
> index 0000000..ff5edb6
> --- /dev/null
> +++ b/meta/conf/machine/include/tune-cortexa53.inc
> @@ -0,0 +1,22 @@
> +DEFAULTTUNE ?= "cortexa53-32"
> +
> +require conf/machine/include/arm/arch-armv8.inc
> +
> +TUNEVALID[cortexa53] = "Enable Cortex-A53 specific processor optimizations"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', ' -mcpu=cortex-a53 ', '',d)}"
> +
> +# Extra tune selections
> +AVAILTUNES += "cortexa53-32"
> +ARMPKGARCH_tune-cortexa53-32 ?= "cortexa53"
> +TUNE_FEATURES_tune-cortexa53-32 = "${TUNE_FEATURES_tune-armv7ve-neon-vfpv4} cortexa53"
> +BASE_LIB_tune-cortexa53-32 = "lib"
> +TUNE_PKGARCH_tune-cortexa53-32 = "cortexa53-32"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa53-32 = "${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4} cortexa53-32 cortexa53-neon-vfpv4"
> +
> +AVAILTUNES += "cortexa53-64"
> +ARMPKGARCH_tune-cortexa53-64 ?= "cortexa53"
> +TUNE_FEATURES_tune-cortexa53-64 = "${TUNE_FEATURES_tune-aarch64} cortexa53"
> +BASE_LIB_tune-cortexa53-64 = "lib64"
> +TUNE_PKGARCH_tune-cortexa53-64 = "cortexa53-64"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa53-64 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} cortexa53-64"
> +
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



^ permalink raw reply

* Re: [PATCH v2 1/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits
From: Khem Raj @ 2016-11-19 17:50 UTC (permalink / raw)
  To: Herve Jourdain; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <1479559833-128256-2-git-send-email-herve.jourdain@neuf.fr>

This seems fine to me. There is a tune checker that Martin has, it would be good
to run that and see if this new tune is tested.

http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test


On Sat, Nov 19, 2016 at 4:50 AM, Herve Jourdain <herve.jourdain@neuf.fr> wrote:
> Signed-off-by: Herve Jourdain <herve.jourdain@neuf.fr>
> ---
>  meta/conf/machine/include/tune-cortexa53.inc | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>  create mode 100644 meta/conf/machine/include/tune-cortexa53.inc
>
> diff --git a/meta/conf/machine/include/tune-cortexa53.inc b/meta/conf/machine/include/tune-cortexa53.inc
> new file mode 100644
> index 0000000..ff5edb6
> --- /dev/null
> +++ b/meta/conf/machine/include/tune-cortexa53.inc
> @@ -0,0 +1,22 @@
> +DEFAULTTUNE ?= "cortexa53-32"
> +
> +require conf/machine/include/arm/arch-armv8.inc
> +
> +TUNEVALID[cortexa53] = "Enable Cortex-A53 specific processor optimizations"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', ' -mcpu=cortex-a53 ', '',d)}"
> +
> +# Extra tune selections
> +AVAILTUNES += "cortexa53-32"
> +ARMPKGARCH_tune-cortexa53-32 ?= "cortexa53"
> +TUNE_FEATURES_tune-cortexa53-32 = "${TUNE_FEATURES_tune-armv7ve-neon-vfpv4} cortexa53"
> +BASE_LIB_tune-cortexa53-32 = "lib"
> +TUNE_PKGARCH_tune-cortexa53-32 = "cortexa53-32"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa53-32 = "${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4} cortexa53-32 cortexa53-neon-vfpv4"
> +
> +AVAILTUNES += "cortexa53-64"
> +ARMPKGARCH_tune-cortexa53-64 ?= "cortexa53"
> +TUNE_FEATURES_tune-cortexa53-64 = "${TUNE_FEATURES_tune-aarch64} cortexa53"
> +BASE_LIB_tune-cortexa53-64 = "lib64"
> +TUNE_PKGARCH_tune-cortexa53-64 = "cortexa53-64"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa53-64 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} cortexa53-64"
> +
> --
> 2.7.4
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


^ permalink raw reply

* Re: [PATCH] ltp: fix an incorrect macro checking
From: Khem Raj @ 2016-11-19 17:42 UTC (permalink / raw)
  To: jhuang0; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <20161119021100.29350-1-jackie.huang@windriver.com>

On Fri, Nov 18, 2016 at 6:11 PM,  <jackie.huang@windriver.com> wrote:
> From: Jackie Huang <jackie.huang@windriver.com>
>
> The previous patch added a check but incorrectly
> change the elif to if, then it always return 0
> for cpuid if the machine is not __i386__
>
> getcpu01    1  TFAIL  :  getcpu01.c:140: getcpu() returned wrong value expected cpuid:7, returned value cpuid: 0
>
> After this fix:
> getcpu01    1  TPASS  :  getcpu() returned proper cpuid:7, node id:0
>

This is ok.


^ permalink raw reply

* Re: [PATCH] apt-package: Include maintenance scripts
From: Andreas Oberritter @ 2016-11-19 14:06 UTC (permalink / raw)
  To: Aníbal Limón, Linus Wallgren, openembedded-core
In-Reply-To: <582E2C46.9090605@linux.intel.com>

On 17.11.2016 23:16, Aníbal Limón wrote:
> Your patch looks good, only missing one thing you need to conditional
> those lines to only work when systemd is enabled in DISTRO_FEATURES, see
> example:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-support/consolekit/consolekit_0.4.6.bb#n26

No, because systemd.bbclass, which consolekit doesn't inherit, deletes
all files in systemd_unitdir if systemd is not in distro features.

> On 11/16/2016 10:33 AM, Linus Wallgren wrote:
>> Apt can run multiple tasks daily, such as for example clean, update,
>> autoclean, unattended-upgrades etc.
>>
>> [YOCTO #10669]
>>
>> Signed-off-by: Linus Wallgren <linus.wallgren@scypho.com>
>> ---
>>  meta/recipes-devtools/apt/apt-package.inc | 15 ++++++++++++++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-devtools/apt/apt-package.inc b/meta/recipes-devtools/apt/apt-package.inc
>> index a553aa2..38cd558 100644
>> --- a/meta/recipes-devtools/apt/apt-package.inc
>> +++ b/meta/recipes-devtools/apt/apt-package.inc
>> @@ -32,13 +32,19 @@ FILES_${PN} = "${bindir}/apt-cdrom ${bindir}/apt-get \
>>  	       ${bindir}/apt-config ${bindir}/apt-cache \
>>  	       ${libdir}/apt ${libdir}/libapt*.so.* \
>>  	       ${localstatedir} ${sysconfdir} \
>> -	       ${libdir}/dpkg"
>> +	       ${libdir}/dpkg \
>> +	       ${systemd_unitdir}/system \
>> +           "
>>  FILES_${PN}-utils = "${bindir}/apt-sortpkgs ${bindir}/apt-extracttemplates"
>>  FILES_${PN}-doc = "${@get_files_apt_doc(d, bb, d.getVar('apt-manpages', True))} \
>>  		   ${docdir}/apt"
>>  FILES_${PN}-utils-doc = "${@get_files_apt_doc(d, bb, d.getVar('apt-utils-manpages', True))}"
>>  FILES_${PN}-dev = "${libdir}/libapt*.so ${includedir}"
>>  
>> +inherit systemd
>> +
>> +SYSTEMD_SERVICE_${PN} = "apt-daily.timer"
>> +
>>  do_install () {
>>  	set -x
>>  	install -d ${D}${bindir}
>> @@ -75,4 +81,11 @@ do_install () {
>>  
>>  	install -d ${D}${includedir}/apt-pkg/
>>  	install -m 0644 include/apt-pkg/*.h ${D}${includedir}/apt-pkg/
>> +
>> +    install -d ${D}${systemd_unitdir}/system/
>> +    install -m 0644 ${S}/debian/apt.systemd.daily ${D}/usr/lib/apt/
>> +    install -m 0644 ${S}/debian/apt-daily.service ${D}${systemd_unitdir}/system/
>> +    install -m 0644 ${S}/debian/apt-daily.timer ${D}${systemd_unitdir}/system/
>> +    install -d ${D}${sysconfdir}/cron.daily/
>> +    install -m 0755 ${S}/debian/apt.apt-compat.cron.daily ${D}${sysconfdir}/cron.daily/
>>  }
>>

Please consider using tabs for consistency with the rest of the recipe.

Regards,
Andreas



^ permalink raw reply

* [PATCH v2 1/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits
From: Herve Jourdain @ 2016-11-19 12:50 UTC (permalink / raw)
  To: openembedded-core
In-Reply-To: <1479559833-128256-1-git-send-email-herve.jourdain@neuf.fr>

Signed-off-by: Herve Jourdain <herve.jourdain@neuf.fr>
---
 meta/conf/machine/include/tune-cortexa53.inc | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

diff --git a/meta/conf/machine/include/tune-cortexa53.inc b/meta/conf/machine/include/tune-cortexa53.inc
new file mode 100644
index 0000000..ff5edb6
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -0,0 +1,22 @@
+DEFAULTTUNE ?= "cortexa53-32"
+
+require conf/machine/include/arm/arch-armv8.inc
+
+TUNEVALID[cortexa53] = "Enable Cortex-A53 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', ' -mcpu=cortex-a53 ', '',d)}"
+
+# Extra tune selections
+AVAILTUNES += "cortexa53-32"
+ARMPKGARCH_tune-cortexa53-32 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53-32 = "${TUNE_FEATURES_tune-armv7ve-neon-vfpv4} cortexa53"
+BASE_LIB_tune-cortexa53-32 = "lib"
+TUNE_PKGARCH_tune-cortexa53-32 = "cortexa53-32"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-32 = "${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4} cortexa53-32 cortexa53-neon-vfpv4"
+
+AVAILTUNES += "cortexa53-64"
+ARMPKGARCH_tune-cortexa53-64 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53-64 = "${TUNE_FEATURES_tune-aarch64} cortexa53"
+BASE_LIB_tune-cortexa53-64 = "lib64"
+TUNE_PKGARCH_tune-cortexa53-64 = "cortexa53-64"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-64 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} cortexa53-64"
+
-- 
2.7.4



^ permalink raw reply related

* [PATCH v2 0/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits
From: Herve Jourdain @ 2016-11-19 12:50 UTC (permalink / raw)
  To: openembedded-core

Tune file for ARM Cortex-A53, supporting 32 bits and 64 bits configuration

Herve Jourdain (1):
  Add a tune file for cortexa53, valid for 32 bits and 64 bits

 meta/conf/machine/include/tune-cortexa53.inc | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.7.4



^ permalink raw reply

* Re: [PATCH 0/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits
From: Herve Jourdain @ 2016-11-19 12:49 UTC (permalink / raw)
  To: openembedded-core
In-Reply-To: <1479552674-23762-1-git-send-email-herve.jourdain@neuf.fr>

Please disregard this patch, v2 coming...

-----Original Message-----
From: Herve Jourdain [mailto:herve.jourdain@neuf.fr] 
Sent: samedi 19 novembre 2016 11:51
To: openembedded-core@lists.openembedded.org
Cc: Herve Jourdain <herve.jourdain@neuf.fr>
Subject: [oe-core][PATCH 0/1] Add a tune file for cortexa53, valid for 32
bits and 64 bits

Tune file for ARM Cortex-A53, supporting 32 bits and 64 bits configuration

Herve Jourdain (1):
  Add a tune file for cortexa53, valid for 32 bits and 64 bits

 meta/conf/machine/include/tune-cortexa53.inc | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.7.4



^ permalink raw reply

* [PATCH 1/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits
From: Herve Jourdain @ 2016-11-19 10:51 UTC (permalink / raw)
  To: openembedded-core
In-Reply-To: <1479552674-23762-1-git-send-email-herve.jourdain@neuf.fr>

Signed-off-by: Herve Jourdain <herve.jourdain@neuf.fr>
---
 meta/conf/machine/include/tune-cortexa53.inc | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

diff --git a/meta/conf/machine/include/tune-cortexa53.inc b/meta/conf/machine/include/tune-cortexa53.inc
new file mode 100644
index 0000000..d2e2d53
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -0,0 +1,22 @@
+DEFAULTTUNE ?= "cortexa53-32"
+
+require conf/machine/include/arm/arch-armv8.inc
+
+TUNEVALID[cortexa53] = "Enable Cortex-A53 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', ' -mcpu=cortex-a53 ', '',d)}"
+
+# Extra tune selections
+AVAILTUNES += "cortexa53-32"
+ARMPKGARCH_tune-cortexa53-32 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53-32 = "${TUNE_FEATURES_tune-armv7ve-neon-vfpv4} cortexa53"
+BASE_LIB_tune-cortexa53-32 = "lib"
+TUNE_PKGARCH_tune-cortexa53-32 = "cortexa53-32"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-32 = "${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4} cortexa53-32"
+
+AVAILTUNES += "cortexa53-64"
+ARMPKGARCH_tune-cortexa53-64 ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53-64 = "${TUNE_FEATURES_tune-aarch64} cortexa53"
+BASE_LIB_tune-cortexa53-64 = "lib64"
+TUNE_PKGARCH_tune-cortexa53-64 = "cortexa53-64"
+PACKAGE_EXTRA_ARCHS_tune-cortexa53-64 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} cortexa53-64"
+
-- 
2.7.4



^ permalink raw reply related

* [PATCH 0/1] Add a tune file for cortexa53, valid for 32 bits and 64 bits
From: Herve Jourdain @ 2016-11-19 10:51 UTC (permalink / raw)
  To: openembedded-core

Tune file for ARM Cortex-A53, supporting 32 bits and 64 bits configuration

Herve Jourdain (1):
  Add a tune file for cortexa53, valid for 32 bits and 64 bits

 meta/conf/machine/include/tune-cortexa53.inc | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa53.inc

-- 
2.7.4



^ permalink raw reply

* more perl stuff: is "perl-module-rpm" still borked?
From: Robert P. J. Day @ 2016-11-19  9:36 UTC (permalink / raw)
  To: OE Core mailing list


  from recipes-devtools/rpm/rpm_5.4.16.bb:

SUMMARY_perl-module-rpm = "Perl bindings for apps which will manipulate RPM packages"
DESCRIPTION_perl-modules-rpm = "The perl-modules-rpm package contains a module that permits applications \
written in the Perl programming language to use the interface \
supplied by the RPM Package Manager libraries."

... snip ...

# Perl modules are not built, but they could be enabled fairly easily
# the perl module creation and installation would need to be patched.
# (currently has host perl contamination issues)
WITH_PERL = "--with-perl --without-perlembed --without-perl-urpm"
WITHOUT_PERL = "--without-perl --without-perl-urpm"
PACKAGECONFIG[perl] = "${WITH_PERL},${WITHOUT_PERL},perl,"

  so, still broken?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================



^ permalink raw reply

* Re: Loss of a wayland socket by a systemd user session
From: Daniel Díaz @ 2016-11-19  2:47 UTC (permalink / raw)
  To: Tomas Novotny, openembedded-core
In-Reply-To: <20161118191252.43d474b6@tomas.local.tbs-biometrics.cz>

Hello!


On 11/18/2016 12:12 PM, Tomas Novotny wrote:
> I'm using weston and its 'weston-start' script shipped with oe-core (morty).
> It works perfectly until root is logged in. The problematic path is:
[...]

We've seen that [1]. If you have PAM, you can modify weston-start to
pass `-u root' to weston-launch [2].

You can also try this systemd service unit and launch Weston directly:
  https://github.com/mrchapp/meta-96boards/commit/ac3e11e

Greetings!

Daniel Díaz
daniel.diaz@linaro.org


[1] https://bugs.linaro.org/show_bug.cgi?id=2576
[2] https://github.com/mrchapp/meta-96boards/commit/ee71b7e



^ permalink raw reply

* [PATCH] ltp: fix an incorrect macro checking
From: jackie.huang @ 2016-11-19  2:11 UTC (permalink / raw)
  To: openembedded-core

From: Jackie Huang <jackie.huang@windriver.com>

The previous patch added a check but incorrectly
change the elif to if, then it always return 0
for cpuid if the machine is not __i386__

getcpu01    1  TFAIL  :  getcpu01.c:140: getcpu() returned wrong value expected cpuid:7, returned value cpuid: 0

After this fix:
getcpu01    1  TPASS  :  getcpu() returned proper cpuid:7, node id:0

Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
---
 .../0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch  | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch b/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
index d123074..41f2623 100644
--- a/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
+++ b/meta/recipes-extended/ltp/ltp/0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch
@@ -88,22 +88,19 @@ index c927512..921b107 100644
  
  void cleanup(void);
  void setup(void);
-@@ -164,9 +172,14 @@ static inline int getcpu(unsigned *cpu_id, unsigned *node_id,
+@@ -164,7 +172,11 @@ static inline int getcpu(unsigned *cpu_id, unsigned *node_id,
  {
  #if defined(__i386__)
  	return syscall(318, cpu_id, node_id, cache_struct);
 -#elif __GLIBC_PREREQ(2,6)
-+#if defined(__GLIBC__)
++#elif defined(__GLIBC__)
 +#if __GLIBC_PREREQ(2,6)
 +	*cpu_id = sched_getcpu();
 +#endif
 +#else
  	*cpu_id = sched_getcpu();
  #endif
-+#endif
  	return 0;
- }
- 
 @@ -191,15 +204,20 @@ unsigned int set_cpu_affinity(void)
  	cpu_set_t *set;
  	size_t size;
-- 
2.8.3



^ permalink raw reply related

* Re: [Openembedded-architecture] Enabling uninative by default in oe-core?
From: Denys Dmytriyenko @ 2016-11-18 21:17 UTC (permalink / raw)
  To: Koen Kooi; +Cc: OE-core, openembedded-architecture
In-Reply-To: <C693ECD4-7EEE-497B-A937-670B441067D2@dominion.thruhere.net>

On Fri, Nov 18, 2016 at 09:50:08PM +0100, Koen Kooi wrote:
> 
> > Op 18 nov. 2016, om 19:06 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> > 
> > On Fri, 2016-11-18 at 08:28 -0800, akuster808 wrote:
> >> On 11/17/2016 09:31 AM, Burton, Ross wrote:
> >>> Background: uninative is a class that downloads a precompiled host
> >>> glibc for use in the sysroot, thus isolating the native sysroot
> >>> from the host environment.  This means greater sstate reuse, as
> >>> instead of native builds being dependent on the host system they're
> >>> able to be shared between all hosts.  There is a reference tarball
> >>> hosted on www.yoctoproject.org, and the URL can be overridden by
> >>> distros if you would prefer to build your own.
> >>> 
> >>> We enable this in Poky so that we get greater reuse on the
> >>> autobuilders, and due to some issues with the C++ ABI the eSDK
> >>> generation in master now requires uninative to be enabled.  The
> >>> question is: do we now enable uninative by default in oe-core's
> >>> nodistro (pointing at the yoctoproject tarball), or do we keep it
> >>> disabled by default and require the user to enable uninative if
> >>> they wish to build an eSDK?
> >>  
> >> If Poky wants the default to use a prebuilt uninative that is fine,
> >> but it should be not be the default in OE.  In the spirit of Bitbake,
> >> uninative should be a build dependency for eSDK with the option of
> >> using a prebuilt one.
> > 
> > Its not that simple. Using uninative requires certain options passed in
> > when compiling native recipes for example, e.g. to pick particular C++
> > abis. If you start the build without those set (since uninative is
> > disabled), you can't get native sstate built in the right way for it to
> > work with eSDK. We could of course add a new BBCLASSEXTEND, "native2"
> > which is native specially for use in the eSDK but that seems silly.
> > 
> > I guess we could move the configuration uninative requires into global
> > bitbake.conf but not require the actual binary shim to be enabled. That
> > would let eSDK work in OE-Core just not make OE-Core require uninative.
> > It would mean the compiler options for native would be a little
> > different. That might be an acceptable compromise?
> 
> It would be for me.

Agree, sounds like a good compromise.

-- 
Denys


^ permalink raw reply

* Re: [Openembedded-architecture] Enabling uninative by default in oe-core?
From: Koen Kooi @ 2016-11-18 20:50 UTC (permalink / raw)
  To: Richard Purdie; +Cc: openembedded-architecture, OE-core
In-Reply-To: <1479492365.28508.113.camel@linuxfoundation.org>


> Op 18 nov. 2016, om 19:06 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> 
> On Fri, 2016-11-18 at 08:28 -0800, akuster808 wrote:
>> On 11/17/2016 09:31 AM, Burton, Ross wrote:
>>> Background: uninative is a class that downloads a precompiled host
>>> glibc for use in the sysroot, thus isolating the native sysroot
>>> from the host environment.  This means greater sstate reuse, as
>>> instead of native builds being dependent on the host system they're
>>> able to be shared between all hosts.  There is a reference tarball
>>> hosted on www.yoctoproject.org, and the URL can be overridden by
>>> distros if you would prefer to build your own.
>>> 
>>> We enable this in Poky so that we get greater reuse on the
>>> autobuilders, and due to some issues with the C++ ABI the eSDK
>>> generation in master now requires uninative to be enabled.  The
>>> question is: do we now enable uninative by default in oe-core's
>>> nodistro (pointing at the yoctoproject tarball), or do we keep it
>>> disabled by default and require the user to enable uninative if
>>> they wish to build an eSDK?
>>  
>> If Poky wants the default to use a prebuilt uninative that is fine,
>> but it should be not be the default in OE.  In the spirit of Bitbake,
>> uninative should be a build dependency for eSDK with the option of
>> using a prebuilt one.
> 
> Its not that simple. Using uninative requires certain options passed in
> when compiling native recipes for example, e.g. to pick particular C++
> abis. If you start the build without those set (since uninative is
> disabled), you can't get native sstate built in the right way for it to
> work with eSDK. We could of course add a new BBCLASSEXTEND, "native2"
> which is native specially for use in the eSDK but that seems silly.
> 
> I guess we could move the configuration uninative requires into global
> bitbake.conf but not require the actual binary shim to be enabled. That
> would let eSDK work in OE-Core just not make OE-Core require uninative.
> It would mean the compiler options for native would be a little
> different. That might be an acceptable compromise?

It would be for me.

regards,

Koen

^ permalink raw reply

* Re: [PATCH] u-boot: Update to v2016.11 release
From: Marek Vasut @ 2016-11-18 20:30 UTC (permalink / raw)
  To: Denys Dmytriyenko; +Cc: openembedded-core
In-Reply-To: <20161118194439.GF26131@denix.org>

On 11/18/2016 08:44 PM, Denys Dmytriyenko wrote:
> On Fri, Nov 18, 2016 at 08:29:55PM +0100, Marek Vasut wrote:
>> Upgrade U-Boot to the latest version.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
>> Cc: Denys Dmytriyenko <denis@denix.org>
> 
> Acked-by: Denys Dmytriyenko <denys@ti.com>
> 
> 
>> Cc: Ross Burton <ross.burton@intel.com>
>> ---
>>
>> diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
>> similarity index 71%
>> rename from meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
>> rename to meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
>> index f706a6b..84adc1c 100644
>> --- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
>> +++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
>> @@ -7,8 +7,8 @@ PE = "1"
>>  
>>  # We use the revision in order to avoid having to fetch it from the
>>  # repo during parse
>> -SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
>> +SRCREV = "29e0cfb4f77f7aa369136302cee14a91e22dca71"
>>  
>> -SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
>> +SRC_URI = "git://git.denx.de/u-boot.git"
> 
> Will it branch off into own branch eventually?Does master ever get 
> re-written? I guess as long as this commit always stays in master, it should 
> be fine.

Master never gets rewritten and the commit is always in master, unless
we screw something up bad and need to make a fixup release (which
happens almost never :-)), in which case that goes into separate branch.

-- 
Best regards,
Marek Vasut


^ permalink raw reply

* Re: [PATCH] u-boot: Update to v2016.11 release
From: Tom Rini @ 2016-11-18 20:24 UTC (permalink / raw)
  To: Marek Vasut; +Cc: openembedded-core
In-Reply-To: <20161118192955.17284-1-marex@denx.de>

On Fri, Nov 18, 2016 at 08:29:55PM +0100, Marek Vasut wrote:

> Upgrade U-Boot to the latest version.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
> Cc: Denys Dmytriyenko <denis@denix.org>
> Cc: Ross Burton <ross.burton@intel.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom


^ permalink raw reply

* Re: [PATCH] busybox: enable fractional sleep arguments
From: Tom Rini @ 2016-11-18 20:22 UTC (permalink / raw)
  To: Nathan Lynch; +Cc: openembedded-core
In-Reply-To: <1479415791-28938-1-git-send-email-nathan_lynch@mentor.com>

On Thu, Nov 17, 2016 at 02:49:51PM -0600, Nathan Lynch wrote:
> Fractional durations (e.g. 0.5s) for the sleep command are useful and
> not terribly uncommon in practice, especially in scripts associated
> with test cases (e.g. mdadm, lttng-tools).  Enable FEATURE_FLOAT_SLEEP
> by default in order to avoid having to patch every instance of a
> script using a fractional sleep.
> 
> The busybox binary gains a few hundred bytes in text (armv5e shown):
> 
> $ size -x busybox.nosuid.{before,after}
>    text	   data	    bss	    dec	    hex	filename
> 0x89382	  0x71d	 0x2250	 572655	  8bcef	busybox.nosuid.before
> 0x8954e	  0x721	 0x2250	 573119	  8bebf	busybox.nosuid.after
> 
> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>

It's also something I've seen customer use as well in their scripts so
this would remove the need to add it to the local layer.

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
Tom


^ permalink raw reply

* Re: [PATCH] cantarell-fonts: add inherit pkgconfig to get pkgconfig dependency
From: Burton, Ross @ 2016-11-18 20:12 UTC (permalink / raw)
  To: Cody P Schafer; +Cc: OE-core
In-Reply-To: <20161118193748.4850-1-dev@codyps.com>

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

On 18 November 2016 at 19:37, Cody P Schafer <dev@codyps.com> wrote:

> Without this, do_configure can fail with:
>
>         | ../git/configure: line 2381: syntax error near unexpected token
> `0.19'
>         | ../git/configure: line 2381: `PKG_PROG_PKG_CONFIG(0.19)'
>
> If pkgconfig-native happens to be added to the sysroot too late.
>

Looking at upstream's configure there's no reason why it calls that macro,
so you could submit a patch to remove that line upstream and then just bump
the SRCREV.

Ross

[-- Attachment #2: Type: text/html, Size: 955 bytes --]

^ permalink raw reply

* Re: [PATCH] u-boot: Update to v2016.11 release
From: Denys Dmytriyenko @ 2016-11-18 19:44 UTC (permalink / raw)
  To: Marek Vasut; +Cc: openembedded-core
In-Reply-To: <20161118192955.17284-1-marex@denx.de>

On Fri, Nov 18, 2016 at 08:29:55PM +0100, Marek Vasut wrote:
> Upgrade U-Boot to the latest version.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
> Cc: Denys Dmytriyenko <denis@denix.org>

Acked-by: Denys Dmytriyenko <denys@ti.com>


> Cc: Ross Burton <ross.burton@intel.com>
> ---
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> similarity index 71%
> rename from meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> rename to meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> index f706a6b..84adc1c 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
> @@ -7,8 +7,8 @@ PE = "1"
>  
>  # We use the revision in order to avoid having to fetch it from the
>  # repo during parse
> -SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
> +SRCREV = "29e0cfb4f77f7aa369136302cee14a91e22dca71"
>  
> -SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
> +SRC_URI = "git://git.denx.de/u-boot.git"

Will it branch off into own branch eventually? Does master ever get 
re-written? I guess as long as this commit always stays in master, it should 
be fine.


>  S = "${WORKDIR}/git"
> diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
> diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
> diff --git a/meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb b/meta/recipes-bsp/u-boot/u-boot_2016.11.bb
> similarity index 100%
> rename from meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
> rename to meta/recipes-bsp/u-boot/u-boot_2016.11.bb
> -- 
> 2.10.2
> 


^ permalink raw reply

* [PATCH] cantarell-fonts: add inherit pkgconfig to get pkgconfig dependency
From: Cody P Schafer @ 2016-11-18 19:37 UTC (permalink / raw)
  To: openembedded-core

Without this, do_configure can fail with:

	| ../git/configure: line 2381: syntax error near unexpected token `0.19'
	| ../git/configure: line 2381: `PKG_PROG_PKG_CONFIG(0.19)'

If pkgconfig-native happens to be added to the sysroot too late.

Signed-off-by: Cody P Schafer <dev@codyps.com>
---
 meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb b/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb
index e3e4cde..c71ab11 100644
--- a/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb
+++ b/meta/recipes-graphics/cantarell-fonts/cantarell-fonts_git.bb
@@ -18,7 +18,7 @@ UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>(?!0\.13)(?!0\.10\.1)\d+\.\d+(\.\d+)+)"
 
 S = "${WORKDIR}/git"
 
-inherit autotools allarch fontcache
+inherit autotools allarch fontcache pkgconfig
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[fontforge] = "--enable-source-rebuild=yes,--enable-source-rebuild=no,fontforge-native"
-- 
2.10.2



^ permalink raw reply related

* [PATCH] u-boot: Update to v2016.11 release
From: Marek Vasut @ 2016-11-18 19:29 UTC (permalink / raw)
  To: openembedded-core; +Cc: Marek Vasut

Upgrade U-Boot to the latest version.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Denys Dmytriyenko <denis@denix.org>
Cc: Ross Burton <ross.burton@intel.com>
---
 .../{u-boot-common_2016.09.01.inc => u-boot-common_2016.11.inc}       | 4 ++--
 .../{u-boot-fw-utils_2016.09.01.bb => u-boot-fw-utils_2016.11.bb}     | 0
 .../{u-boot-mkimage_2016.09.01.bb => u-boot-mkimage_2016.11.bb}       | 0
 meta/recipes-bsp/u-boot/{u-boot_2016.09.01.bb => u-boot_2016.11.bb}   | 0
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-bsp/u-boot/{u-boot-common_2016.09.01.inc => u-boot-common_2016.11.inc} (71%)
 rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2016.09.01.bb => u-boot-fw-utils_2016.11.bb} (100%)
 rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2016.09.01.bb => u-boot-mkimage_2016.11.bb} (100%)
 rename meta/recipes-bsp/u-boot/{u-boot_2016.09.01.bb => u-boot_2016.11.bb} (100%)

diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
similarity index 71%
rename from meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
rename to meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
index f706a6b..84adc1c 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common_2016.09.01.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common_2016.11.inc
@@ -7,8 +7,8 @@ PE = "1"
 
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = "f3363c060497515ca8b71451cb56f3ec0abacaa9"
+SRCREV = "29e0cfb4f77f7aa369136302cee14a91e22dca71"
 
-SRC_URI = "git://git.denx.de/u-boot.git;branch=u-boot-2016.09.y"
+SRC_URI = "git://git.denx.de/u-boot.git"
 
 S = "${WORKDIR}/git"
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.09.01.bb
rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2016.11.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb b/meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2016.09.01.bb
rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2016.11.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb b/meta/recipes-bsp/u-boot/u-boot_2016.11.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot_2016.09.01.bb
rename to meta/recipes-bsp/u-boot/u-boot_2016.11.bb
-- 
2.10.2



^ permalink raw reply related

* Loss of a wayland socket by a systemd user session
From: Tomas Novotny @ 2016-11-18 18:12 UTC (permalink / raw)
  To: openembedded-core

Hi all,

I'm using weston and its 'weston-start' script shipped with oe-core (morty).
It works perfectly until root is logged in. The problematic path is:

1) 'weston-start' is started during boot. XDG_RUNTIME_DIR for root doesn't
exist so it is created and 'wayland-0' socket is created in that directory.
So far so good.

2) When root is logged in, systemd user session is started via 'systemd
--user'. This replaces original XDG_RUNTIME_DIR (new tmpfs is mounted over
it) and the 'wayland-0' socket is lost. Logout doesn't help, the original
XDG_RUNTIME_DIR is deleted. You can imagine that weston doesn't work properly
without that socket.

Is there any proper way to fix it?

Thanks,

Tomas



^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox