[OE-core] [PATCH] oeqa/runtime/locales.py:added runtime test locales

2018-04-17 Thread Pravin Patil 
Add runtime test for locales packages to test that is it
installed or not.

Signed-off-by: Pravin Patil 
---
 meta/lib/oeqa/runtime/cases/locales.py | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100755 meta/lib/oeqa/runtime/cases/locales.py

diff --git a/meta/lib/oeqa/runtime/cases/locales.py 
b/meta/lib/oeqa/runtime/cases/locales.py
new file mode 100755
index 000..251bd04
--- /dev/null
+++ b/meta/lib/oeqa/runtime/cases/locales.py
@@ -0,0 +1,11 @@
+import os
+
+from oeqa.runtime.case import OERuntimeTestCase
+from oeqa.core.decorator.depends import OETestDepends
+from oeqa.runtime.decorator.package import OEHasPackage
+
+class LocaleTest(OERuntimeTestCase):
+  def test_locale(self):
+cmd = "locale -a | grep -w 'fr_FR'"
+(status,output) = self.target.run(cmd)
+self.assertEqual(status, 0, output)
-- 
2.7.4

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

[OE-core] [PATCH v2] grub-efi: add grub target and image for aarch64

2018-04-17 Thread Ricardo Salveti 
Add missing target and image for aarch64, as the current revision is
already fully compatible with ARMv8.

Signed-off-by: Ricardo Salveti 
---
 meta/recipes-bsp/grub/grub-efi_2.02.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-bsp/grub/grub-efi_2.02.bb 
b/meta/recipes-bsp/grub/grub-efi_2.02.bb
index ed27b90..7bfc8ee 100644
--- a/meta/recipes-bsp/grub/grub-efi_2.02.bb
+++ b/meta/recipes-bsp/grub/grub-efi_2.02.bb
@@ -22,6 +22,9 @@ python __anonymous () {
 elif re.match('i.86', target):
 grubtarget = 'i386'
 grubimage = prefix + "bootia32.efi"
+elif re.match('aarch64', target):
+grubtarget = 'arm64'
+grubimage = prefix + "bootaa64.efi"
 else:
 raise bb.parse.SkipRecipe("grub-efi is incompatible with target %s" % 
target)
 d.setVar("GRUB_TARGET", grubtarget)
-- 
2.7.4

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

[OE-core] [PATCH] usbutils: use update-alternatives for lsusb

2018-04-17 Thread Ricardo Salveti 
lsusb can also be provided by busybox (CONFIG_LSUSB), so use
update-alternatives to handle the conflict.

Signed-off-by: Ricardo Salveti 
---
 meta/recipes-bsp/usbutils/usbutils_009.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/usbutils/usbutils_009.bb 
b/meta/recipes-bsp/usbutils/usbutils_009.bb
index 88c24bd..3ffc0dd 100644
--- a/meta/recipes-bsp/usbutils/usbutils_009.bb
+++ b/meta/recipes-bsp/usbutils/usbutils_009.bb
@@ -15,7 +15,10 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/usb/usbutils/usbutils-${PV}.tar.gz \
 SRC_URI[md5sum] = "b5dbc498b2eb5058f7a57fc6532d0aad"
 SRC_URI[sha256sum] = 
"e73543293a17c7803994eac97a49e58b377e08e6299ba11aad09794b91340e8b"
 
-inherit autotools pkgconfig distro_features_check
+inherit autotools pkgconfig distro_features_check update-alternatives
+
+ALTERNATIVE_${PN} = "lsusb"
+ALTERNATIVE_PRIORITY = "100"
 
 FILES_${PN}-dev += "${datadir}/pkgconfig"
 
-- 
2.7.4

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

Re: [OE-core] [PATCH] [PATCH] wayland: 1.14.0 -> 1.15.0

2018-04-17 Thread Denys Dmytriyenko 
Duplicate and incomplete!


On Mon, Apr 16, 2018 at 07:23:07PM +0800, Zheng Ruoqin wrote:
> Upgrade wayland from 1.14.0 to 1.15.0.
> 
> Signed-off-by: Zheng Ruoqin 
> ---
>  .../recipes-graphics/wayland/{wayland_1.14.0.bb => wayland_1.15.0.bb} | 4 
> ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-graphics/wayland/{wayland_1.14.0.bb => 
> wayland_1.15.0.bb} (92%)
> 
> diff --git a/meta/recipes-graphics/wayland/wayland_1.14.0.bb 
> b/meta/recipes-graphics/wayland/wayland_1.15.0.bb
> similarity index 92%
> rename from meta/recipes-graphics/wayland/wayland_1.14.0.bb
> rename to meta/recipes-graphics/wayland/wayland_1.15.0.bb
> index 1a9ff98..788105b 100644
> --- a/meta/recipes-graphics/wayland/wayland_1.14.0.bb
> +++ b/meta/recipes-graphics/wayland/wayland_1.15.0.bb
> @@ -15,8 +15,8 @@ DEPENDS = "expat libxml2 libffi wayland-native"
>  SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
>  file://fixpathinpcfiles.patch \
> "
> -SRC_URI[md5sum] = "0235f6075c32c3be61cff94fa0b9f108"
> -SRC_URI[sha256sum] = 
> "ed80cabc0961a759a42092e2c39aabfc1ec9a13c86c98bbe2b812f008da27ab8"
> +SRC_URI[md5sum] = "b7393c17fdce9a8d383edab656c92fd2"
> +SRC_URI[sha256sum] = 
> "eb3fbebb8559d56a80ad3753ec3db800f587329067962dbf65e14488b4b7aeb0"
>  
>  inherit autotools pkgconfig
>  
> -- 
> 2.7.4
> 
> 
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3

2018-04-17 Thread Davis, Michael 
I have a strange luck in hitting those things that work, but aren't the correct 
way of doing it.
They always seem to last about 1 version update.  I will make the proper 
changes on my side.

Thanks,
Mike

-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] 
Sent: Tuesday, April 17, 2018 3:22 PM
To: Davis, Michael
Cc: openembedded-core@lists.openembedded.org; Alejandro Enedino Hernandez 
Samaniego; Burton, Ross
Subject: Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3

Hi Michael,

On Wednesday, 18 April 2018 8:03:43 AM NZST Davis, Michael wrote:
> Actually just recreated it without all my custom cruft in there to 
> confuse things.
> 
> I had oe-init-build-env generate a new build dir:
> "source oe-init-build-env  ~/build/test"
> 
> Added the following to the bottom of the local.conf 
> TOOLCHAIN_HOST_TASK += " nativesdk-cmake \
>  nativesdk-python3"
> 
> Create the sdk:
> " bitbake core-image-minimal -c do_populate_sdk_ext"

I'm afraid this is not the correct way to add items to the eSDK. See:

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

I think at the moment what you need is:

SDK_TARGETS += "cmake-native:do_populate_sysroot \
   python3-native:do_populate_sysroot"


Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [OE-core] [PATCH] uninative: Add allow-shlib-undefined to BUILD_LDFLAGS and drop other workarounds

2018-04-17 Thread Burton, Ross 
The dbus-glib-native one hits a few times but the only other place it
has broken so far is in cmake-native:

bin/cmake: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not
found (required by
TOPDIR/tmp/work/x86_64-linux/cmake-native/3.10.3-r0/recipe-sysroot-native/usr/lib/libexpat.so.1)

Is expat using rpaths or something and picking the wrong libc?

Ross

On 17 April 2018 at 21:52, Burton, Ross  wrote:
> On 17 April 2018 at 17:44, Richard Purdie
>  wrote:
>> We have a problem when for example, a glibc 2.27 based system builds some
>> library like libpopt-native and puts it into sstate then it is reused
>> on a pre glibc-2.27 system to build something which depends on popt like
>> rpm-native. This results in an error like:
>>
>> recipe-sysroot-native/usr/lib/libpopt.so: undefined reference to 
>> `glob@GLIBC_2.27'
>
> dbus-glib-native is failing on a few builders like this:
>
> | 
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/work/x86_64-linux/dbus-glib-native/0.108-r0/build/dbus/.libs/lt-dbus-binding-tool:
> /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found
> (required by 
> /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/work/x86_64-linux/dbus-glib-native/0.108-r0/recipe-sysroot-native/usr/lib/libexpat.so.1)
>
> Using the host libc doesn't seem right surely?
>
> Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] recipes-kernel/linux: Enable NUMA Kconfig from DISTRO_FEATURES

2018-04-17 Thread Andre McCurdy 
On Mon, Apr 16, 2018 at 1:02 PM, Alistair Francis
 wrote:
> If the user has set numa as a distro feature enable NUMA support in the
> kernel config.

Isn't NUMA something which would be machine specific rather than
distro specific?

> Signed-off-by: Alistair Francis 
> ---
>  meta/recipes-kernel/linux/files/numa.cfg  | 4 
>  meta/recipes-kernel/linux/linux-yocto.inc | 3 +++
>  2 files changed, 7 insertions(+)
>  create mode 100644 meta/recipes-kernel/linux/files/numa.cfg
>
> diff --git a/meta/recipes-kernel/linux/files/numa.cfg 
> b/meta/recipes-kernel/linux/files/numa.cfg
> new file mode 100644
> index 000..bb0f9ab
> --- /dev/null
> +++ b/meta/recipes-kernel/linux/files/numa.cfg
> @@ -0,0 +1,4 @@
> +CONFIG_NUMA=y
> +CONFIG_ACPI_NUMA=y
> +CONFIG_NUMA_BALANCING=y
> +CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc 
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 3bb872a..cf97cd1 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -28,6 +28,9 @@ KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
>
>  KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc"
>
> +SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'numa', ' 
> file://numa.cfg', '', d)}"
> +KERNEL_FEATURES_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'numa', 
> 'features/numa/numa.scc', '', d)}"
> +
>  # A KMACHINE is the mapping of a yocto $MACHINE to what is built
>  # by the kernel. This is typically the branch that should be built,
>  # and it can be specific to the machine or shared
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] uninative: Add allow-shlib-undefined to BUILD_LDFLAGS and drop other workarounds

2018-04-17 Thread Burton, Ross 
On 17 April 2018 at 17:44, Richard Purdie
 wrote:
> We have a problem when for example, a glibc 2.27 based system builds some
> library like libpopt-native and puts it into sstate then it is reused
> on a pre glibc-2.27 system to build something which depends on popt like
> rpm-native. This results in an error like:
>
> recipe-sysroot-native/usr/lib/libpopt.so: undefined reference to 
> `glob@GLIBC_2.27'

dbus-glib-native is failing on a few builders like this:

| 
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/work/x86_64-linux/dbus-glib-native/0.108-r0/build/dbus/.libs/lt-dbus-binding-tool:
/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found
(required by 
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/work/x86_64-linux/dbus-glib-native/0.108-r0/recipe-sysroot-native/usr/lib/libexpat.so.1)

Using the host libc doesn't seem right surely?

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

Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3

2018-04-17 Thread Paul Eggleton 
Hi Michael,

On Wednesday, 18 April 2018 8:03:43 AM NZST Davis, Michael wrote:
> Actually just recreated it without all my custom cruft in there to confuse
> things.
> 
> I had oe-init-build-env generate a new build dir:
> "source oe-init-build-env  ~/build/test"
> 
> Added the following to the bottom of the local.conf
> TOOLCHAIN_HOST_TASK += " nativesdk-cmake \
>  nativesdk-python3"
> 
> Create the sdk:
> " bitbake core-image-minimal -c do_populate_sdk_ext"

I'm afraid this is not the correct way to add items to the eSDK. See:

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

I think at the moment what you need is:

SDK_TARGETS += "cmake-native:do_populate_sysroot \
   python3-native:do_populate_sysroot"


Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3

2018-04-17 Thread Davis, Michael 
Actually just recreated it without all my custom cruft in there to confuse 
things.

I had oe-init-build-env generate a new build dir:
"source oe-init-build-env  ~/build/test"

Added the following to the bottom of the local.conf
TOOLCHAIN_HOST_TASK += " nativesdk-cmake \
 nativesdk-python3"

Create the sdk:
" bitbake core-image-minimal -c do_populate_sdk_ext"

The install of that sdk breaks 
[mdavis@localhost test]$ 
tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-2.4+snapshot.sh
 
Poky (Yocto Project Reference Distro) Extensible SDK installer version 
2.4+snapshot
===
Enter target directory for SDK (default: ~/poky_sdk): ~/test
You are about to install the SDK to "/home/mdavis/test". Proceed[Y/n]? y
Extracting SDKdone
Setting it up...
Extracting buildtools...
Preparing build system...
Traceback (most recent call last):
  File "/home/mdavis/test/layers/core/bitbake/bin/bitbake", line 31, in 
import bb
  File "/home/mdavis/test/layers/core/bitbake/lib/bb/__init__.py", line 79, in 

from bb import fetch2 as fetch
  File "/home/mdavis/test/layers/core/bitbake/lib/bb/fetch2/__init__.py", line 
39, in 
import bb.persist_data, bb.utils
  File "/home/mdavis/test/layers/core/bitbake/lib/bb/persist_data.py", line 33, 
in 
sqlversion = sqlite3.sqlite_version_info
AttributeError: module 'sqlite3' has no attribute 'sqlite_version_info'
ERROR: SDK preparation failed: error log written to 
/home/mdavis/test/preparing_build_system.log


Mike


-Original Message-
From: Alejandro Enedino Hernandez Samaniego 
[mailto:alejandro.enedino.hernandez-samani...@xilinx.com] 
Sent: Tuesday, April 17, 2018 2:41 PM
To: Burton, Ross; Davis, Michael
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3

Hey Mike,

It does make a little sense that you're not getting "sqlite_version_info" from 
sqlite3, the python3-sqlite3 is missing the __init__.py file (on purpose) for 
that module, and the only thing that does is

from sqlite3.dbapi2 import *

and sqlite_version_info comes from sqilte3.dbapi2, hence why you might not be 
getting it, but I would still like to know the steps you're following to 
reproduce this, since I couldn't do that either.


Alejandro

On 04/17/2018 09:27 AM, Burton, Ross wrote:
> Work for me with plain oe-core:
>
> $ 
> ./poky-glibc-x86_64-core-image-minimal-corei7-64-toolchain-ext-2.4+sna
> pshot.sh Poky (Yocto Project Reference Distro) Extensible SDK 
> installer version 2.4+snapshot 
> ==
> = Enter target directory for SDK (default: ~/poky_sdk):
> You are about to install the SDK to "/home/ross/poky_sdk". 
> Proceed[Y/n]? y Extracting 
> SDK...
> done
> Setting it up...
> Extracting buildtools...
> Preparing build system...
> Parsing recipes: 100%
> |#
> |#|
> Time: 0:00:10
> Initialising tasks: 100%
> |#
> |##|
> Time: 0:00:07
> Checking sstate mirror object availability: 100%
> |###| Time: 0:00:00
> Loading cache: 100%
> |#
> |###|
> Time: 0:00:00
> Initialising tasks: 100%
> |#
> |##|
> Time: 0:00:00
> done
> SDK has been successfully set up and is ready to be used.
> Each time you wish to use the SDK in a new shell session, you need to 
> source the environment setup script e.g.
>   $ . /home/ross/poky_sdk/environment-setup-corei7-64-poky-linux
>
> Obviously something is different, how are you reproducing this?
>
> Ross
>
> On 17 April 2018 at 14:50, Davis, Michael  wrote:
>> I was on the HEAD of sumo(commit 
>> d012a9acdc3dce014705224a1261145628e75931)
>> so that commit was already included when I had the issue.  Just 
>> generated another test today and the issue was still there.  If I 
>> remove native-python3-misc from TOOLCHAIN_HOST_TASK it fails on installing 
>> the SDK.
>> With it there it succeeds.
>>
>>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>>
>> From: Alejandro Enedino Hernandez Samaniego 
>> [mailto:aleja...@xilinx.com]
>> Sent: Monday, April 16, 2018 8:07 PM
>> To: Davis, Michael; openembedded-core@lists.openembedded.org
>> Subject: RE: [OE-CORE][sumo][python3] Generated SDK missing sqlite3
>>
>>
>>
>> Which commit are you using?
>>
>>
>>
>> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4379b29e7e
>> ede727993ee68c9eba2bdebace5108
>>
>>
>>
>> In any case, that one should’ve solved it.
>>
>>
>>
>> Alejandro
>>
>>
>>
>> From:

Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3

2018-04-17 Thread Alejandro Enedino Hernandez Samaniego 

Hey Mike,

It does make a little sense that you're not getting 
"sqlite_version_info" from sqlite3, the python3-sqlite3 is missing the 
__init__.py file (on purpose) for that module, and the only thing that 
does is


from sqlite3.dbapi2 import *

and sqlite_version_info comes from sqilte3.dbapi2, hence why you might 
not be getting it, but I would still like to know the steps you're 
following to reproduce this, since I couldn't do that either.



Alejandro

On 04/17/2018 09:27 AM, Burton, Ross wrote:

Work for me with plain oe-core:

$ ./poky-glibc-x86_64-core-image-minimal-corei7-64-toolchain-ext-2.4+snapshot.sh
Poky (Yocto Project Reference Distro) Extensible SDK installer version
2.4+snapshot
===
Enter target directory for SDK (default: ~/poky_sdk):
You are about to install the SDK to "/home/ross/poky_sdk". Proceed[Y/n]? y
Extracting 
SDK...done
Setting it up...
Extracting buildtools...
Preparing build system...
Parsing recipes: 100%
|##|
Time: 0:00:10
Initialising tasks: 100%
|###|
Time: 0:00:07
Checking sstate mirror object availability: 100%
|###| Time: 0:00:00
Loading cache: 100%
||
Time: 0:00:00
Initialising tasks: 100%
|###|
Time: 0:00:00
done
SDK has been successfully set up and is ready to be used.
Each time you wish to use the SDK in a new shell session, you need to
source the environment setup script e.g.
  $ . /home/ross/poky_sdk/environment-setup-corei7-64-poky-linux

Obviously something is different, how are you reproducing this?

Ross

On 17 April 2018 at 14:50, Davis, Michael  wrote:

I was on the HEAD of sumo(commit d012a9acdc3dce014705224a1261145628e75931)
so that commit was already included when I had the issue.  Just generated
another test today and the issue was still there.  If I remove
native-python3-misc from TOOLCHAIN_HOST_TASK it fails on installing the SDK.
With it there it succeeds.



Mike







From: Alejandro Enedino Hernandez Samaniego [mailto:aleja...@xilinx.com]
Sent: Monday, April 16, 2018 8:07 PM
To: Davis, Michael; openembedded-core@lists.openembedded.org
Subject: RE: [OE-CORE][sumo][python3] Generated SDK missing sqlite3



Which commit are you using?



https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4379b29e7eede727993ee68c9eba2bdebace5108



In any case, that one should’ve solved it.



Alejandro



From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Davis, Michael
Sent: Monday, April 16, 2018 11:19 AM
To: Davis, Michael ;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing
sqlite3



Adding python3-misc to the SDK seems to have solved the issue.

I saw some commits about separating the two so perhaps this is a side
effect?



From: Davis, Michael
Sent: Monday, April 16, 2018 11:04 AM
To: 'openembedded-core@lists.openembedded.org'
Subject: [OE-CORE][sumo][python3] Generated SDK missing sqlite3



Testing out the upcoming sumo release and ran into an issue.  Whenever I
attempt to generate an sdk-ext with sumo I get a failure about missing
sqlite3.

Traceback (most recent call last):
  File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool",
line 344, in 
ret = main()
  File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool",
line 285, in main
scriptutils.logger_setup_color(logger, global_args.color)
  File "/home/mdavis/core_sdk/layers/core/scripts/lib/scriptutils.py", line
38, in logger_setup_color
from bb.msg import BBLogFormatter
  File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/__init__.py", line
79, in 
from bb import fetch2 as fetch
  File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/fetch2/__init__.py",
line 39, in 
import bb.persist_data, bb.utils
  File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/persist_data.py",
line 33, in 
sqlversion = sqlite3.sqlite_version_info
AttributeError: module 'sqlite3' has no attribute 'sqlite_version_info'



The issue seems to be isolated only to python3. The sdk partially installs
and I am able to source it.  I created a small python sqlite app and was
able to run it properly with python2, but not 3.




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



--
___
Openembedded-core

Re: [OE-core] [PATCH] uninative: Add allow-shlib-undefined to BUILD_LDFLAGS and drop other workarounds

2018-04-17 Thread Andre McCurdy 
On Tue, Apr 17, 2018 at 9:44 AM, Richard Purdie
 wrote:
> We have a problem when for example, a glibc 2.27 based system builds some
> library like libpopt-native and puts it into sstate then it is reused
> on a pre glibc-2.27 system to build something which depends on popt like
> rpm-native. This results in an error like:
>
> recipe-sysroot-native/usr/lib/libpopt.so: undefined reference to 
> `glob@GLIBC_2.27'
>
> In the past we've had this problem with new symbols like getrandom and
> getentropy, here its with a more complex symbol where there is an old
> version and a newer version.
>
> We've looked into various options, basically we cannot link against our
> uninative libc/ld.so since we don't have the right headers or compiler
> link libraries. The compiler doesn't allow you to switch in a new set
> either, even if we did want to ship them. Shipping a complete compiler,
> dev headers and libs also isn't an option.

Maybe not an option now, but in theory wouldn't a set of native tools
statically linked with musl and downloadable from a public sstate
server solve all these kinds of issues?

> On the other hand if we follow the ld man page, it does say:
>
> """
> The reasons for allowing undefined symbol references in shared libraries
> specified at link time are that:
>
> - A shared library specified at link time may not be the same as the one
>   that is available at load time, so the symbol might actually be
>   resolvable at load time.
> """
>
> which is exactly this case. By the time the binary runs, it will use
> our uninative loader and libc and the symbol will be available.
>
> Therefore we basically have a choice, we get weird intermittent bugs,
> we drop uninative entirely, or we pass this option.
>
> If we pass the option, we can drop the other workarounds too.
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/classes/uninative.bbclass |  4 +++-
>  meta/recipes-core/expat/expat/no_getrandom.patch   | 23 
> --
>  meta/recipes-core/expat/expat_2.2.5.bb |  2 --
>  .../util-linux/util-linux/no_getrandom.patch   | 21 
>  meta/recipes-core/util-linux/util-linux_2.31.bb|  1 -
>  .../python/python3-native_3.5.5.bb |  3 +--
>  6 files changed, 4 insertions(+), 50 deletions(-)
>  delete mode 100644 meta/recipes-core/expat/expat/no_getrandom.patch
>  delete mode 100644 meta/recipes-core/util-linux/util-linux/no_getrandom.patch
>
> diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
> index 0501dde..23c5314 100644
> --- a/meta/classes/uninative.bbclass
> +++ b/meta/classes/uninative.bbclass
> @@ -9,7 +9,7 @@ UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc.tar.bz2"
>  UNINATIVE_DLDIR ?= "${DL_DIR}/uninative/"
>
>  # Enabling uninative will change the following variables so they need to go 
> the parsing white list to prevent multiple recipe parsing
> -BB_HASHCONFIG_WHITELIST += "NATIVELSBSTRING SSTATEPOSTUNPACKFUNCS"
> +BB_HASHCONFIG_WHITELIST += "NATIVELSBSTRING SSTATEPOSTUNPACKFUNCS 
> BUILD_LDFLAGS"
>
>  addhandler uninative_event_fetchloader
>  uninative_event_fetchloader[eventmask] = "bb.event.BuildStarted"
> @@ -129,6 +129,8 @@ def enable_uninative(d):
>  d.setVar("NATIVELSBSTRING", "universal%s" % 
> oe.utils.host_gcc_version(d))
>  d.appendVar("SSTATEPOSTUNPACKFUNCS", " uninative_changeinterp")
>  d.appendVarFlag("SSTATEPOSTUNPACKFUNCS", "vardepvalueexclude", "| 
> uninative_changeinterp")
> +d.appendVar("BUILD_LDFLAGS", " -Wl,--allow-shlib-undefined")
> +d.appendVarFlag("BUILD_LDFLAGS", "vardepvalueexclude", "| 
> -Wl,--allow-shlib-undefined")
>  d.prependVar("PATH", 
> "${STAGING_DIR}-uninative/${BUILD_ARCH}-linux${bindir_native}:")
>
>  python uninative_changeinterp () {
> diff --git a/meta/recipes-core/expat/expat/no_getrandom.patch 
> b/meta/recipes-core/expat/expat/no_getrandom.patch
> deleted file mode 100644
> index d64f1bf..000
> --- a/meta/recipes-core/expat/expat/no_getrandom.patch
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -The native version of expat may be used on older systems which dont have 
> glibc 2.25
> -and hence don't have getrandom() thanks to uninative. Disable the libc call 
> and
> -use the syscall instead to avoid a compatibility issue until we have 2.25 
> everywhere
> -we support with uninative.
> -
> -RP
> -2017/8/14
> -
> -Upstream-Status: Inappropriate
> -
> -Index: expat-2.2.3/configure.ac
> -===
>  expat-2.2.3.orig/configure.ac
> -+++ expat-2.2.3/configure.ac
> -@@ -151,7 +151,7 @@ AC_LINK_IFELSE([AC_LANG_SOURCE([
> -   #include   /* for NULL */
> -   #include 
> -   int main() {
> --return getrandom(NULL, 0U, 0U);
> -+return getrandomBREAKME(NULL, 0U, 0U);
> -   }
> - ])], [
> - AC_DEFINE([HAVE_GETRANDOM], [1],
> diff --git

[OE-core] [PATCH] uninative: Add allow-shlib-undefined to BUILD_LDFLAGS and drop other workarounds

2018-04-17 Thread Richard Purdie 
We have a problem when for example, a glibc 2.27 based system builds some
library like libpopt-native and puts it into sstate then it is reused
on a pre glibc-2.27 system to build something which depends on popt like
rpm-native. This results in an error like:

recipe-sysroot-native/usr/lib/libpopt.so: undefined reference to 
`glob@GLIBC_2.27'

In the past we've had this problem with new symbols like getrandom and
getentropy, here its with a more complex symbol where there is an old
version and a newer version.

We've looked into various options, basically we cannot link against our
uninative libc/ld.so since we don't have the right headers or compiler
link libraries. The compiler doesn't allow you to switch in a new set
either, even if we did want to ship them. Shipping a complete compiler,
dev headers and libs also isn't an option.

On the other hand if we follow the ld man page, it does say:

"""
The reasons for allowing undefined symbol references in shared libraries
specified at link time are that:

- A shared library specified at link time may not be the same as the one
  that is available at load time, so the symbol might actually be
  resolvable at load time.
"""

which is exactly this case. By the time the binary runs, it will use
our uninative loader and libc and the symbol will be available.

Therefore we basically have a choice, we get weird intermittent bugs,
we drop uninative entirely, or we pass this option.

If we pass the option, we can drop the other workarounds too.

Signed-off-by: Richard Purdie 
---
 meta/classes/uninative.bbclass |  4 +++-
 meta/recipes-core/expat/expat/no_getrandom.patch   | 23 --
 meta/recipes-core/expat/expat_2.2.5.bb |  2 --
 .../util-linux/util-linux/no_getrandom.patch   | 21 
 meta/recipes-core/util-linux/util-linux_2.31.bb|  1 -
 .../python/python3-native_3.5.5.bb |  3 +--
 6 files changed, 4 insertions(+), 50 deletions(-)
 delete mode 100644 meta/recipes-core/expat/expat/no_getrandom.patch
 delete mode 100644 meta/recipes-core/util-linux/util-linux/no_getrandom.patch

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 0501dde..23c5314 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -9,7 +9,7 @@ UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc.tar.bz2"
 UNINATIVE_DLDIR ?= "${DL_DIR}/uninative/"
 
 # Enabling uninative will change the following variables so they need to go 
the parsing white list to prevent multiple recipe parsing
-BB_HASHCONFIG_WHITELIST += "NATIVELSBSTRING SSTATEPOSTUNPACKFUNCS"
+BB_HASHCONFIG_WHITELIST += "NATIVELSBSTRING SSTATEPOSTUNPACKFUNCS 
BUILD_LDFLAGS"
 
 addhandler uninative_event_fetchloader
 uninative_event_fetchloader[eventmask] = "bb.event.BuildStarted"
@@ -129,6 +129,8 @@ def enable_uninative(d):
 d.setVar("NATIVELSBSTRING", "universal%s" % 
oe.utils.host_gcc_version(d))
 d.appendVar("SSTATEPOSTUNPACKFUNCS", " uninative_changeinterp")
 d.appendVarFlag("SSTATEPOSTUNPACKFUNCS", "vardepvalueexclude", "| 
uninative_changeinterp")
+d.appendVar("BUILD_LDFLAGS", " -Wl,--allow-shlib-undefined")
+d.appendVarFlag("BUILD_LDFLAGS", "vardepvalueexclude", "| 
-Wl,--allow-shlib-undefined")
 d.prependVar("PATH", 
"${STAGING_DIR}-uninative/${BUILD_ARCH}-linux${bindir_native}:")
 
 python uninative_changeinterp () {
diff --git a/meta/recipes-core/expat/expat/no_getrandom.patch 
b/meta/recipes-core/expat/expat/no_getrandom.patch
deleted file mode 100644
index d64f1bf..000
--- a/meta/recipes-core/expat/expat/no_getrandom.patch
+++ /dev/null
@@ -1,23 +0,0 @@
-The native version of expat may be used on older systems which dont have glibc 
2.25
-and hence don't have getrandom() thanks to uninative. Disable the libc call and
-use the syscall instead to avoid a compatibility issue until we have 2.25 
everywhere
-we support with uninative.
-
-RP
-2017/8/14
-
-Upstream-Status: Inappropriate
-
-Index: expat-2.2.3/configure.ac
-===
 expat-2.2.3.orig/configure.ac
-+++ expat-2.2.3/configure.ac
-@@ -151,7 +151,7 @@ AC_LINK_IFELSE([AC_LANG_SOURCE([
-   #include   /* for NULL */
-   #include 
-   int main() {
--return getrandom(NULL, 0U, 0U);
-+return getrandomBREAKME(NULL, 0U, 0U);
-   }
- ])], [
- AC_DEFINE([HAVE_GETRANDOM], [1],
diff --git a/meta/recipes-core/expat/expat_2.2.5.bb 
b/meta/recipes-core/expat/expat_2.2.5.bb
index bce5929..c68a2ef 100644
--- a/meta/recipes-core/expat/expat_2.2.5.bb
+++ b/meta/recipes-core/expat/expat_2.2.5.bb
@@ -11,8 +11,6 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.bz2 \
file://libtool-tag.patch \
  "
 
-SRC_URI_append_class-native = " file://no_getrandom.patch"
-
 SRC_URI[md5sum] = "789e297f547980fc9ecc036f9a070d49"
 SRC_URI[sha256sum] =

Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3

2018-04-17 Thread Burton, Ross 
Work for me with plain oe-core:

$ ./poky-glibc-x86_64-core-image-minimal-corei7-64-toolchain-ext-2.4+snapshot.sh
Poky (Yocto Project Reference Distro) Extensible SDK installer version
2.4+snapshot
===
Enter target directory for SDK (default: ~/poky_sdk):
You are about to install the SDK to "/home/ross/poky_sdk". Proceed[Y/n]? y
Extracting 
SDK...done
Setting it up...
Extracting buildtools...
Preparing build system...
Parsing recipes: 100%
|##|
Time: 0:00:10
Initialising tasks: 100%
|###|
Time: 0:00:07
Checking sstate mirror object availability: 100%
|###| Time: 0:00:00
Loading cache: 100%
||
Time: 0:00:00
Initialising tasks: 100%
|###|
Time: 0:00:00
done
SDK has been successfully set up and is ready to be used.
Each time you wish to use the SDK in a new shell session, you need to
source the environment setup script e.g.
 $ . /home/ross/poky_sdk/environment-setup-corei7-64-poky-linux

Obviously something is different, how are you reproducing this?

Ross

On 17 April 2018 at 14:50, Davis, Michael  wrote:
> I was on the HEAD of sumo(commit d012a9acdc3dce014705224a1261145628e75931)
> so that commit was already included when I had the issue.  Just generated
> another test today and the issue was still there.  If I remove
> native-python3-misc from TOOLCHAIN_HOST_TASK it fails on installing the SDK.
> With it there it succeeds.
>
>
>
> Mike
>
>
>
>
>
>
>
> From: Alejandro Enedino Hernandez Samaniego [mailto:aleja...@xilinx.com]
> Sent: Monday, April 16, 2018 8:07 PM
> To: Davis, Michael; openembedded-core@lists.openembedded.org
> Subject: RE: [OE-CORE][sumo][python3] Generated SDK missing sqlite3
>
>
>
> Which commit are you using?
>
>
>
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4379b29e7eede727993ee68c9eba2bdebace5108
>
>
>
> In any case, that one should’ve solved it.
>
>
>
> Alejandro
>
>
>
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Davis, Michael
> Sent: Monday, April 16, 2018 11:19 AM
> To: Davis, Michael ;
> openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing
> sqlite3
>
>
>
> Adding python3-misc to the SDK seems to have solved the issue.
>
> I saw some commits about separating the two so perhaps this is a side
> effect?
>
>
>
> From: Davis, Michael
> Sent: Monday, April 16, 2018 11:04 AM
> To: 'openembedded-core@lists.openembedded.org'
> Subject: [OE-CORE][sumo][python3] Generated SDK missing sqlite3
>
>
>
> Testing out the upcoming sumo release and ran into an issue.  Whenever I
> attempt to generate an sdk-ext with sumo I get a failure about missing
> sqlite3.
>
> Traceback (most recent call last):
>  File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool",
> line 344, in 
>ret = main()
>  File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool",
> line 285, in main
>scriptutils.logger_setup_color(logger, global_args.color)
>  File "/home/mdavis/core_sdk/layers/core/scripts/lib/scriptutils.py", line
> 38, in logger_setup_color
>from bb.msg import BBLogFormatter
>  File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/__init__.py", line
> 79, in 
>from bb import fetch2 as fetch
>  File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/fetch2/__init__.py",
> line 39, in 
>import bb.persist_data, bb.utils
>  File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/persist_data.py",
> line 33, in 
>sqlversion = sqlite3.sqlite_version_info
> AttributeError: module 'sqlite3' has no attribute 'sqlite_version_info'
>
>
>
> The issue seems to be isolated only to python3. The sdk partially installs
> and I am able to source it.  I created a small python sqlite app and was
> able to run it properly with python2, but not 3.
>
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] package.bbclass: Add '-b' option to file call in isELF

2018-04-17 Thread Burton, Ross 
On 16 April 2018 at 21:49, Peter Kjellerstedt
 wrote:
> There was a discussion last year at the beginning of December related
> to this, triggered by a patch series to improve isELF that Olof Johansson
> sent:
>
> http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145160.html
>
> It also included a patch that added -b to the file call:
>
> http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145158.html

Whoops, must have missed that.  Sorry about this, this is now in my sumo queue.

> However, the discussion then turned to replace the isELF implementation
> with a new one that Ross Burton was working on:
>
> http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145205.html
>
> Whatever became of that? Is that still in progress?

Yes, it's still in progress.  I was hacking on it a bit more thing
morning in fact, as a proof-of-concept to extract the linkage from a
binary during QA and warn if a 32-bit executable is linking to the
non-largefile functions.  Obviously its 2.6 material now but I hope
I'll get around to finishing it off.

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

Re: [OE-core] [PATCH 3/4] gcc-runtime: Disable gcc version of libssp

2018-04-17 Thread Khem Raj 
On Tue, Apr 17, 2018 at 3:42 AM, Richard Purdie
 wrote:
> On Sun, 2018-04-15 at 23:50 -0700, Khem Raj wrote:
>> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
>> b/meta/recipes-devtools/gcc/gcc-runtime.inc
>> index 97365a21dc..b4e5539575 100644
>> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
>> @@ -24,8 +24,10 @@ RUNTIMELIBITM_nios2 = ""
>>  RUNTIMELIBITM_microblaze = ""
>>  RUNTIMELIBITM_riscv32 = ""
>>  RUNTIMELIBITM_riscv64 = ""
>> +RUNTIMELIBSSP ?= ""
>> +RUNTIMELIBSSP_mingw ?= "libssp"
>>
>> -RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic
>> ${RUNTIMELIBITM} \
>> +RUNTIMETARGET = "libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
>>  ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'],
>> 'libquadmath', '', d)} \
>>  "
>>  RUNTIMETARGET_append_x86 = " libmpx"
>
> This last piece looks like you removed libssp for everywhere, glibc
> included except mingw?
>

yes, since the needed bits for ssp are already provided via libc.so there should
not be a need for it needing libssp on glibc based systems, I think
its due to the libssp
patch we are carrying in gcc, I will take a look at that and limit it
to just musl tuples

> Is the source file you included in the new recipe the same as the one
> in the gcc source but linked differently? If so, I'd be tempted to
> build that gcc-runtime with a musl specific do_compile addition...
>
> I assume this is post 2.5 material as its fairly invasive changes at
> the tail end of a release...
>

yes this is for 2.6 we may backport it later if needed.

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

Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3

2018-04-17 Thread Davis, Michael 
I was on the HEAD of sumo(commit d012a9acdc3dce014705224a1261145628e75931) so 
that commit was already included when I had the issue.  Just generated another 
test today and the issue was still there.  If I remove native-python3-misc from 
TOOLCHAIN_HOST_TASK it fails on installing the SDK.  With it there it succeeds.

Mike



From: Alejandro Enedino Hernandez Samaniego [mailto:aleja...@xilinx.com]
Sent: Monday, April 16, 2018 8:07 PM
To: Davis, Michael; openembedded-core@lists.openembedded.org
Subject: RE: [OE-CORE][sumo][python3] Generated SDK missing sqlite3

Which commit are you using?

https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4379b29e7eede727993ee68c9eba2bdebace5108

In any case, that one should've solved it.

Alejandro

From: 
openembedded-core-boun...@lists.openembedded.org
 
[mailto:openembedded-core-boun...@lists.openembedded.org]
 On Behalf Of Davis, Michael
Sent: Monday, April 16, 2018 11:19 AM
To: Davis, Michael 
>; 
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3

Adding python3-misc to the SDK seems to have solved the issue.
I saw some commits about separating the two so perhaps this is a side effect?

From: Davis, Michael
Sent: Monday, April 16, 2018 11:04 AM
To: 'openembedded-core@lists.openembedded.org'
Subject: [OE-CORE][sumo][python3] Generated SDK missing sqlite3

Testing out the upcoming sumo release and ran into an issue.  Whenever I 
attempt to generate an sdk-ext with sumo I get a failure about missing sqlite3.
Traceback (most recent call last):
 File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool", 
line 344, in 
   ret = main()
 File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool", 
line 285, in main
   scriptutils.logger_setup_color(logger, global_args.color)
 File "/home/mdavis/core_sdk/layers/core/scripts/lib/scriptutils.py", line 38, 
in logger_setup_color
   from bb.msg import BBLogFormatter
 File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/__init__.py", line 79, 
in 
   from bb import fetch2 as fetch
 File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/fetch2/__init__.py", 
line 39, in 
   import bb.persist_data, bb.utils
 File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/persist_data.py", line 
33, in 
   sqlversion = sqlite3.sqlite_version_info
AttributeError: module 'sqlite3' has no attribute 'sqlite_version_info'

The issue seems to be isolated only to python3. The sdk partially installs and 
I am able to source it.  I created a small python sqlite app and was able to 
run it properly with python2, but not 3.

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

Re: [OE-core] musl patches

2018-04-17 Thread Andreas Müller 
On Tue, Apr 17, 2018 at 4:53 AM, Khem Raj  wrote:
>
> On Mon, Apr 16, 2018 at 7:02 PM ChenQi  wrote:
>>
>> On 04/16/2018 07:05 PM, Andreas Müller wrote:
>> > Hi,
>> >
>> > I am not happy plastering patches around for musl. This gets even
>> > worse when I see patches like this [1]: Just wipe away security checks
>> > unconditionally - the developers did introduce this check not just for
>> > fun I guess...
>> >
>> > I have seen this already elsewhere so: musl maintainers please take
>> > care not to modify code for glibc!
>
>
> The idea of musl is not to create a cocoon and live in it but on the
> contrary it’s about fixing the packages such that they work on any posix
> complaint libc regardless having said that there are packages which are
> coded for glibc and we
> Might have to keep trying to fix them upstream
>
> So in the spirit we are making changes such that
> They work across the board and then also push
> These patches to respective upstreams so far we
> Have done good job and upstreamed a whole bunch of patches this would not
> have been possible if we did the conditional approach
>
> We would not like to introduce regressions for sure and if you see
> regressions please report them ASAP and if you have fixes even better
>
> I am hoping that in the end applications will
> Become more portable and we will also see
> The cruft clearly that has gone into glibc over the years and be able to
> address it as you can see  there is lot of cleanup happening in glibc
> already as a result
>>
>>
>> >
>> > [1]
>> > https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch
Let's talk about this patch (same in meta-network/networkmanager):
Without further wisdom I cannot see the 'spirit' of this. It just
opens the chance of vulnerabilities for glibc builds and this for
components as systemd and networkmanager. I wonder what upstream would
say about this patch...

So as long as musl (or clean for posix) patches are not upstreamed I
would ask to keep glibc builds as are designed and tested upstream
either by

* SRC_URI_append_libc-musl or
* #if defined(__GLIBC__) in the code

My 2ct...

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

Re: [OE-core] [PATCH 3/4] gcc-runtime: Disable gcc version of libssp

2018-04-17 Thread Richard Purdie 
On Sun, 2018-04-15 at 23:50 -0700, Khem Raj wrote:
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index 97365a21dc..b4e5539575 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -24,8 +24,10 @@ RUNTIMELIBITM_nios2 = ""
>  RUNTIMELIBITM_microblaze = ""
>  RUNTIMELIBITM_riscv32 = ""
>  RUNTIMELIBITM_riscv64 = ""
> +RUNTIMELIBSSP ?= ""
> +RUNTIMELIBSSP_mingw ?= "libssp"
>  
> -RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic
> ${RUNTIMELIBITM} \
> +RUNTIMETARGET = "libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
>  ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'],
> 'libquadmath', '', d)} \
>  "
>  RUNTIMETARGET_append_x86 = " libmpx"

This last piece looks like you removed libssp for everywhere, glibc
included except mingw?

Is the source file you included in the new recipe the same as the one
in the gcc source but linked differently? If so, I'd be tempted to
build that gcc-runtime with a musl specific do_compile addition...

I assume this is post 2.5 material as its fairly invasive changes at
the tail end of a release...

Cheers,

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

Re: [OE-core] [PATCH 3/4] gcc-runtime: Disable gcc version of libssp

2018-04-17 Thread Burton, Ross 
This is, I suspect, the cause of nativesdk-perl failing on the autobuilder:

TOPDIR/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-perl/5.24.1-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/../../libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/7.3.0/ld:
cannot find -lssp_nonshared
TOPDIR/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-perl/5.24.1-r0/recipe-sysroot-native/usr/bin/x86_64-pokysdk-linux/../../libexec/x86_64-pokysdk-linux/gcc/x86_64-pokysdk-linux/7.3.0/ld:
cannot find -lssp
collect2: error: ld returned 1 exit status
makefile:391: recipe for target 'lib/buildcustomize.pl' failed

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

Ross

On 16 April 2018 at 07:50, Khem Raj  wrote:
> libssp is implemented fully in glibc as well as in musl
> so we really do not need the gcc version of this library
> except may be for mingw, where we keep it enabled anyway
> gcc in OE is built with the knowledge that C library
> already provides libssp implementation, we should therefore
> not need the gcc implementation of same.
>
> libssp_nonshared piece is a detail which is needed when gcc
> is the compiler, in glibc this is part of libc_nonshared.a
> already and libc_nonshared.a is linked always when linking
> with -lc becuase libc.so in glibc is actually a linker script
>
> GROUP ( /usr/lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( 
> /usr/lib/ld-linux-x86-64.so.2 ) )
>
> which automatically links in the needed runtime bits, this however
> is not the case for musl, where core SSP APIs are implemented in full
> but compiler specific runtime isn't, for this we add a new package
> called libssp_nonshared which generate the needed runtime stub
> and gcc is already carrying patch to link to libssp_nonshared.a
> on musl
>
> This should fix a long standing problem where static PIE executable
> were not buildable with OE since it was conflicting SSP implementation
> one from C library and the other one from gcc and we end up with
> duplicate symbol errors during linking.
>
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-devtools/gcc/gcc-7.3.inc | 4 +++-
>  meta/recipes-devtools/gcc/gcc-runtime.inc | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-7.3.inc 
> b/meta/recipes-devtools/gcc/gcc-7.3.inc
> index d968c322d2..7e52afc643 100644
> --- a/meta/recipes-devtools/gcc/gcc-7.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-7.3.inc
> @@ -93,10 +93,12 @@ FORTRAN = ""
>  JAVA = ""
>
>  LTO = "--enable-lto"
> +SSP ?= "--disable-libssp"
> +SSP_mingw = "--enable-libssp"
>
>  EXTRA_OECONF_BASE = "\
>  ${LTO} \
> ---enable-libssp \
> +${SSP} \
>  --enable-libitm \
>  --disable-bootstrap \
>  --disable-libmudflap \
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc 
> b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index 97365a21dc..b4e5539575 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -24,8 +24,10 @@ RUNTIMELIBITM_nios2 = ""
>  RUNTIMELIBITM_microblaze = ""
>  RUNTIMELIBITM_riscv32 = ""
>  RUNTIMELIBITM_riscv64 = ""
> +RUNTIMELIBSSP ?= ""
> +RUNTIMELIBSSP_mingw ?= "libssp"
>
> -RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
> +RUNTIMETARGET = "libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM} \
>  ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', 
> '', d)} \
>  "
>  RUNTIMETARGET_append_x86 = " libmpx"
> --
> 2.17.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3] udev-extraconf: Add systemd-mount to udev-extraconf/mount.sh

2018-04-17 Thread Hongzhi.Song 
Udev-extraconf works correctly with sysvinit in the aspect of automounting
block devices. But it has a serious problem in case of systemd. Block devices
automounted by udev is unaccessible to host space(out of udevd's private
namespace). For example, we cannot format those block devices.

e.g.
root@qemux86:~# mkfs.ext4 /dev/sda1
mke2fs 1.43.8 (1-Jan-2018)
/dev/sda1 contains a ext4 file system
last mounted on Tue Apr  3 06:22:41 2018
Proceed anyway? (y,N) y
/dev/sda1 is apparently in use by the system; will not make a filesystem 
here!

Other distributions has no such problem, because they use a series of rules to
manager block devices. Different types of block devices match different rules.
But udev-extraconf just use one rule, automount.rules, which results in this
problem.

The 'systemd-mount' command is recommended by the systemd community to solve 
such
problems.

This patch makes use of 'systemd-mount' to solve the above problem.

[YOCTO #12644]

Signed-off-by: Hongzhi.Song 
---
 meta/recipes-core/udev/udev-extraconf/mount.sh | 83 --
 meta/recipes-core/udev/udev-extraconf_1.1.bb   |  3 +
 2 files changed, 69 insertions(+), 17 deletions(-)

diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index d760328..067d4e2 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -4,10 +4,28 @@
 #
 # Attempt to mount any added block devices and umount any removed devices
 
+BASE_INIT="`readlink "@base_sbindir@/init"`"
+INIT_SYSTEMD="@systemd_unitdir@/systemd"
+
+if [ "x$BASE_INIT" = "x$INIT_SYSTEMD" ];then
+# systemd as init uses systemd-mount to mount block devices
+MOUNT="/usr/bin/systemd-mount"
+UMOUNT="/usr/bin/systemd-umount"
+
+if [ -x $MOUNT ] && [ -x $UMOUNT ];
+then
+logger "Using systemd-mount to finish mount"
+else
+logger "Linux init is using systemd, so please install systemd-mount 
to finish mount"
+exit 1
+fi
+else
+MOUNT="/bin/mount"
+UMOUNT="/bin/umount"
+fi
 
-MOUNT="/bin/mount"
 PMOUNT="/usr/bin/pmount"
-UMOUNT="/bin/umount"
+
 for line in `grep -h -v ^# /etc/udev/mount.blacklist 
/etc/udev/mount.blacklist.d/*`
 do
if [ ` expr match "$DEVNAME" "$line" ` -gt 0 ];
@@ -17,7 +35,35 @@ do
fi
 done
 
-automount() {  
+automount_systemd() {
+name="`basename "$DEVNAME"`"
+
+[ -d "/run/media/$name" ] || mkdir -p "/run/media/$name"
+
+MOUNT="$MOUNT -o silent"
+
+# If filesystemtype is vfat, change the ownership group to 'disk', and
+# grant it with  w/r/x permissions.
+case $ID_FS_TYPE in
+vfat|fat)
+MOUNT="$MOUNT -o umask=007,gid=`awk -F':' '/^disk/{print $3}' 
/etc/group`"
+;;
+# TODO
+*)
+;;
+esac
+
+if ! $MOUNT --no-block -t auto $DEVNAME "/run/media/$name"
+then
+#logger "mount.sh/automount" "$MOUNT -t auto $DEVNAME 
\"/run/media/$name\" failed!"
+rm_dir "/run/media/$name"
+else
+logger "mount.sh/automount" "Auto-mount of [/run/media/$name] 
successful"
+touch "/tmp/.automount-$name"
+fi
+}
+
+automount() {
name="`basename "$DEVNAME"`"
 
! test -d "/run/media/$name" && mkdir -p "/run/media/$name"
@@ -26,7 +72,7 @@ automount() {
then
MOUNT="$MOUNT -o silent"
fi
-   
+
# If filesystem type is vfat, change the ownership group to 'disk', and
# grant it with  w/r/x permissions.
case $ID_FS_TYPE in
@@ -68,23 +114,26 @@ if [ "$ACTION" = "add" ] && [ -n "$DEVNAME" ] && [ -n 
"$ID_FS_TYPE" -o "$media_t
elif [ -x $MOUNT ]; then
$MOUNT $DEVNAME 2> /dev/null
fi
-   
+
# If the device isn't mounted at this point, it isn't
# configured in fstab (note the root filesystem can show up as
# /dev/root in /proc/mounts, so check the device number too)
-   if expr $MAJOR "*" 256 + $MINOR != `stat -c %d /`; then
-   grep -q "^$DEVNAME " /proc/mounts || automount
-   fi
+if expr $MAJOR "*" 256 + $MINOR != `stat -c %d /`; then
+if [ "`basename $MOUNT`" = "systemd-mount" ];then
+grep -q "^$DEVNAME " /proc/mounts || automount_systemd
+else
+grep -q "^$DEVNAME " /proc/mounts || automount
+fi
+fi
 fi
 
-
 if [ "$ACTION" = "remove" ] || [ "$ACTION" = "change" ] && [ -x "$UMOUNT" ] && 
[ -n "$DEVNAME" ]; then
-   for mnt in `cat /proc/mounts | grep "$DEVNAME" | cut -f 2 -d " " `
-   do
-   $UMOUNT $mnt
-   done
-   
-   # Remove empty directories from auto-mounter
-   name="`basename "$DEVNAME"`"
-   test -e "/tmp/.automount-$name" && rm_dir "/run/media/$name"
+for mnt in `cat /proc/mounts | grep "$DEVNAME" | cut -f 2 -d " " `
+do
+$UMOUNT $mnt
+done
+
+# Remove empty directories