date:20180607

[linux-yocto] [linux-yocto 4.15] crypto: aes-generic - fix aes-generic regression on powerpc

2018-06-07 Thread Kevin Hao

From: Arnd Bergmann 

commit 6e36719fbe90213fbba9f50093fa2d4d69b0e93c upstream

My last bugfix added -Os on the command line, which unfortunately caused
a build regression on powerpc in some configurations.

I've done some more analysis of the original problem and found slightly
different workaround that avoids this regression and also results in
better performance on gcc-7.0: -fcode-hoisting is an optimization step
that got added in gcc-7 and that for all gcc-7 versions causes worse
performance.

This disables -fcode-hoisting on all compilers that understand the option.
For gcc-7.1 and 7.2 I found the same performance as my previous patch
(using -Os), in gcc-7.0 it was even better. On gcc-8 I could see no
change in performance from this patch. In theory, code hoisting should
not be able make things better for the AES cipher, so leaving it
disabled for gcc-8 only serves to simplify the Makefile change.

Reported-by: kbuild test robot 
Link: https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg30418.html
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651
Fixes: 148b974deea9 ("crypto: aes-generic - build with -Os on gcc-7+")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Herbert Xu 
Signed-off-by: Kevin Hao 
---

This fixes the build failure on mpc8315e-rdb board.

 crypto/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/Makefile b/crypto/Makefile
index daa69360e054..cdbc03b35510 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -99,7 +99,7 @@ obj-$(CONFIG_CRYPTO_TWOFISH_COMMON) += twofish_common.o
 obj-$(CONFIG_CRYPTO_SERPENT) += serpent_generic.o
 CFLAGS_serpent_generic.o := $(call cc-option,-fsched-pressure)  # 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
 obj-$(CONFIG_CRYPTO_AES) += aes_generic.o
-CFLAGS_aes_generic.o := $(call cc-ifversion, -ge, 0701, -Os) # 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
+CFLAGS_aes_generic.o := $(call cc-option,-fno-code-hoisting) # 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83356
 obj-$(CONFIG_CRYPTO_AES_TI) += aes_ti.o
 obj-$(CONFIG_CRYPTO_CAMELLIA) += camellia_generic.o
 obj-$(CONFIG_CRYPTO_CAST_COMMON) += cast_common.o
-- 
2.14.3

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

Re: [yocto] mono-native is trying to install files into a shared area...

2018-06-07 Thread Craig McQueen

I wrote:
> 
> Lately, I'm trying to upgrade to a later version of mono, 5.4.1.6. When I try 
> to
> do a build of my Yocto image, bitbake gets to the end of building mono-
> native, and then gets an error:
> 
> 
> ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: The recipe mono-
> native is trying to install files into a shared area when those files already 
> exist.
> Those files and their manifest location are:
>/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> linux/usr/lib/mono/lldb/mono.py
>  Matched in b''
>  /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> linux/usr/lib/mono/4.6.1-api/System.Web.Http.SelfHost.dll
>  Matched in b''
> ...
> /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> linux/usr/lib/mono/xbuild/14.0/bin/MSBuild/Microsoft.Build.CommonTypes.
> xsd
>  Matched in b''
>  /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> linux/usr/lib/mono/xbuild/14.0/bin/MSBuild/Microsoft.Build.Core.xsd
>  Matched in b''
>  /home/craigm/yocto/poky/build/tmp/sysroots/x86_64-
> linux/usr/lib/mono/xbuild/14.0/Microsoft.Common.targets/ImportAfter/Mic
> rosoft.NuGet.ImportAfter.targets
>  Matched in b''
> Please verify which recipe should provide the above files.
> The build has stopped as continuing in this scenario WILL break things, if not
> now, possibly in the future (we've seen builds fail several months later). If
> the system knew how to recover from this automatically it would however
> there are several different scenarios which can result in this and we don't
> know which one this is. It may be you have switched providers of something
> like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case 
> you
> need to execute the clean task for both recipes and it will resolve this 
> error.
> It may be you changed DISTRO_FEATURES from systemd to udev or vice
> versa. Cleaning those recipes should again resolve this error however
> switching DISTRO_FEATURES on an existing build directory is not supported,
> you should really clean out tmp and rebuild (reusing sstate should be safe). 
> It
> could be the overlapping files detected are harmless in which case adding
> them to SSTATE_DUPWHITELIST may be the correct solution. It could also be
> your buil  d is including two different conflicting versions of things (e.g. 
> bluez
> 4 and bluez 5 and the correct solution for that would be to resolve the
> conflict. If in doubt, please ask on the mailing list, sharing the error and 
> filelist
> above.
> ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: If the above message
> is too much, the simpler version is you're advised to wipe out tmp and
> rebuild (reusing sstate is fine). That will likely fix things in most (but 
> not all)
> cases.
> ERROR: mono-native-5.4.1.6-r0 do_populate_sysroot: Function failed:
> sstate_task_postfunc
> ERROR: Logfile of failure stored in:
> /home/craigm/yocto/poky/build/tmp/work/x86_64-linux/mono-
> native/5.4.1.6-r0/temp/log.do_populate_sysroot.108358
> ERROR: Task (/home/craigm/yocto/poky/build/../../meta-mono/recipes-
> mono/mono/mono-native_5.4.1.6.bb:do_populate_sysroot) failed with exit
> code '1'
> NOTE: Tasks Summary: Attempted 670 tasks of which 662 didn't need to be
> rerun and 1 failed.
> 
> Summary: 1 task failed:
>   /home/craigm/yocto/poky/build/../../meta-mono/recipes-
> mono/mono/mono-native_5.4.1.6.bb:do_populate_sysroot
> Summary: There were 3 ERROR messages shown, returning a non-zero exit
> code.
> 
> 
> I'm building with Yocto poky morty branch (currently commit 0e730770a9),
> meta-mono master (commit dced6635ca). I'm building on Ubuntu 16.04.4.
> 
> I have tried deleting the tmp directory, deleting all mono and mono-native
> from sstate, cleaning mono and meta-mono, etc, to no avail.
> 
> It's puzzling why I'm getting these errors, because it says "Matched in b''", 
> so
> the files are not clashing with another recipe. It seems to be somehow trying
> to install its own files twice, or something like that. If I look under
> tmp/work/x86_64-linux/mono-native/5.4.1.6-r0/, then I see the files present
> in both:
> 
> sysroot-destdir/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-linux/
> and image/home/craigm/yocto/poky/build/tmp/sysroots/x86_64-linux/
> 
> Is that part of the problem?


I haven't had any success figuring out what is going on. I tried doing a new 
clean build, and got the same error.

Does anyone else have this problem? Is it an incompatibility with Yocto morty, 
which I'm using? Any pointers on how to narrow down the cause?

-- 
Craig McQueen

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

Re: [yocto] sysroot not being populated

2018-06-07 Thread Khem Raj

Hi Patrick

On Mon, Jun 4, 2018 at 2:01 AM, Patrick Vacek  wrote:
> Hello all,
>
> I have a recipe (aktualizr-hsm-prov) that depends on another (aktualizr)
> to provide an executable and a config file. The former recipe includes
> `DEPENDS = "aktualizr-native"`, and my do_install() for
> aktualizr-hsm-prov has a line something like this:
>
> aktualizr -i ${STAGING_DIR_NATIVE}${libdir}/sota.conf
>
> The binary executable (aktualizr) runs, which tells me that the recipe
> can find that. (Although to be honest, I'm not sure which version it is
> running.) However, it doesn't find the config file, and sure enough,
> ${STAGING_DIR_NATIVE}${libdir} does not have the config file I expect. I
> can see that aktualizr-native is populating its sysroot-destdir, but it
> isn't getting copied to the sysroot for aktualizr-hsm-prov.
>
> I see this problem in sumo and master, although previously this logic
> has worked just fine in morty/pyro/rocko.
>
> Switching to depending on aktualizr (instead of aktualizr-native) and
> using STAGING_DIR_HOST or STAGING_DIR_TARGET does not help, and in fact
> makes it worse, as it can't even find the aktualizr executable in that case.
>
> What am I doing wrong? What changed between rocko and sumo?

is aktualizr recipe installing this .conf file when building native
version. If not may be
add it to do_install

install -D -m 0644  ${D}${libdir}/sota.conf
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Issue when integrating different bsp-layers on a single bblayers.conf

2018-06-07 Thread Trevor Woerner

Hi Iván,

On Thu 2018-06-07 @ 04:39:11 PM, Iván Castell wrote:
> When setting the "build" directory with a bblayers.conf customized for a
> single platform, each platform builds the image recipe properly.
> 
> However, when I have integrated all bsp-layers in a single bblayers.conf,
> the compilation of some platforms has been broken.

This is a problem that comes up fairly often, and is a bug with the BSP layer
itself. All BSP layers are supposed to be created so that they work well when
intermixed with other BSP layers, but often they don't. See Angstrom:

http://www.angstrom-distribution.org/

> The specific problem is this: one bsp layer (meta-rockchip +
> meta-rockchip-extra) defines a recipes-graphics/mesa/mesa_%.bbappend with
> this content inside:

I am the maintainer of the non-vendor meta-rockchip layer:

https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/

The fact you mention this problem and meta-rockchip-extra implies to me that
you're using the vendor-provided meta-rockchip and meta-rockchip-extra:

https://github.com/rockchip-linux/meta-rockchip
https://github.com/rockchip-linux/meta-rockchip-extra

The problem is, the vendor is only interested in their own hardware, so to
them there's no reason to ever mix their BSP layer with any other BSP layer.
There's no interest on their part to "play well" with others or to check
whether their layers comply with community guidelines.

As a person who likes OpenEmbedded as a whole, I try my best to make sure any
layer I'm interested in plays well within the entire OpenEmbedded ecosystem.
However, because mali graphics are currently all binary blobs and projects
like Lima and Panfrost aren't yet ready for prime-time, there isn't much
support yet for _accelerated_ graphics in the non-vendor layer.

> - Can you suggest a fix to solve this issue?

Fix the problem in the layer by using MACHINE-specific OVERRIDES and submit
a pull request to the owners. However, I've noticed there haven't been any
updates to their OE layers in the past 4 months or more, so I can't help
wonder if they've abandoned them.

Out of curiosity, which MACHINE(s) are you interested in?

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH 2/2] Fix build issue for apparmor when systemd is used

2018-06-07 Thread Jinliang Li

When systemd is used as system init manager, there is a build issue complains
"can't found apparmor.service". This patch fix it.

Signed-off-by: Jinliang Li 
---
 recipes-security/AppArmor/apparmor_2.11.0.bb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/recipes-security/AppArmor/apparmor_2.11.0.bb 
b/recipes-security/AppArmor/apparmor_2.11.0.bb
index a83c2c3..fc9b614 100644
--- a/recipes-security/AppArmor/apparmor_2.11.0.bb
+++ b/recipes-security/AppArmor/apparmor_2.11.0.bb
@@ -104,6 +104,11 @@ do_install () {
 
install ${WORKDIR}/apparmor ${D}/${INIT_D_DIR}/apparmor
install ${WORKDIR}/functions ${D}/lib/apparmor
+   if [ "${VIRTUAL-RUNTIME_init_manager}" = "systemd" ]; then
+   install -d ${D}${systemd_system_unitdir}
+   install ${WORKDIR}/apparmor.service \
+   ${D}${systemd_system_unitdir}
+   fi
 }
 
 do_compile_ptest () {
-- 
2.7.4

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

[yocto] [meta-security][PATCH 1/2] Fix build issue for apparmor kernel configuration

2018-06-07 Thread Jinliang Li

Set the correct path of kernel configuration file in linux-yocto_4.%.bbappend
to fix the build issue, which is "Fetcher failure for URL: 
'file://apparmor.cfg'.
Unable to fetch URL from any source."

Signed-off-by: Jinliang Li 
---
 recipes-kernel/linux/linux-yocto_4.%.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/linux/linux-yocto_4.%.bbappend 
b/recipes-kernel/linux/linux-yocto_4.%.bbappend
index 9d68c99..067be8f 100644
--- a/recipes-kernel/linux/linux-yocto_4.%.bbappend
+++ b/recipes-kernel/linux/linux-yocto_4.%.bbappend
@@ -1,4 +1,4 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-4.12:"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
 SRC_URI += "\
 ${@bb.utils.contains('DISTRO_FEATURES', 'apparmor', ' 
file://apparmor.cfg', '', d)} \
-- 
2.7.4

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

[yocto] [meta-security][PATCH 0/2] Fix build issue for apparmor

2018-06-07 Thread Jinliang Li

This patch series fix 2 build issues for apparmor.

Jinliang Li (2):
  Fix build issue for apparmor kernel configuration
  Fix build issue for apparmor when systemd is used

 recipes-kernel/linux/linux-yocto_4.%.bbappend | 2 +-
 recipes-security/AppArmor/apparmor_2.11.0.bb  | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.7.4

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

Re: [yocto] cgroups and iptables problems running docker - maybe my config wrong?

2018-06-07 Thread Jakob Hasse


On 04.06.2018 17:53, Bruce Ashfield wrote:

On 2018-06-01 12:15 PM, Jakob Hasse wrote:

Hello Bruce,

Thank you very much for the quick response. I tried to built in the 
kernel changes. But the iptables error persists.


I double checked over the weekend, and I have no problems with
linux-yocto + the meta-virtualization fragment and docker.

Thanks a lot for the work!


Did you say that you confirmed on target via /proc/config.gz that
all the options you tried to enable are still present in the running
kernel ?
I double checked with /proc/config.gz and all the modules are builting 
except for CONFIG_NF_TABLES, CONFIG_NF_TABLES_IPV4. The last two might 
not even exists, I was so desperate that I put everything into the 
configuration which I could find related to NAT.
Some modules are builtin as modules instead (...=m instead of ...=y), 
however.


Eventually, I tried to enable systemd again and it still breaks my 
build -.-:


test$ bitbake core-image-base
NOTE: Started PRServer with DBfile: 
/home/build/test/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 40169, 
PID: 2335
Loading cache: 100% 
|| 
Time: 0:00:00

Loaded 3023 entries from dependency cache.
Parsing recipes: 100% 
|##| 
Time: 0:00:01
Parsing of 2194 .bb files complete (2193 cached, 1 parsed). 3024 
targets, 146 skipped, 0 masked, 0 errors.

NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.36.0"
BUILD_SYS    = "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "arm-dey-linux-gnueabi"
MACHINE  = "ccimx6ulstarter"
DISTRO   = "dey"
DISTRO_VERSION   = "2.4-r1"
TUNE_FEATURES    = "arm armv7ve vfp thumb neon 
callconvention-hard cortexa7"

TARGET_FPU   = "hard"
meta
meta-poky
meta-yocto-bsp   = "HEAD:3befe6d7b7fa8c8481519aa8dd0cae52207ad339"
meta-oe
meta-python
meta-networking
meta-webserver   = "HEAD:dacfa2b1920e285531bec55cd2f08743390aaf57"
meta-qt5 = "HEAD:cfe02f26de53e5c20e6f9555059cbaaf5ab9b22f"
meta-swupdate    = "HEAD:6e4eab4f475b0129d6510815a3bbc4748c97dbbe"
meta-freescale   = "HEAD:d6141ea291a1ac9ab8fb1dd1110d408f840fda57"
meta-fsl-demos   = "HEAD:0ec6d7e206705702b5b534611754de0787f92b72"
meta-digi-arm
meta-digi-dey    = "HEAD:1246ecff2cecea9247d94f36385608ac844d7abb"

Initialising tasks: 100% 
|###| 
Time: 0:00:04

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: core-image-base-1.0-r0 do_rootfs: Could not invoke dnf. 
Command 
'/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin/dnf 
-y -c 
/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/rootfs/etc/dnf/dnf.conf 
--setopt=reposdir=/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/rootfs/etc/yum.repos.d 
--repofrompath=oe-repo,/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/oe-rootfs-repo 
--installroot=/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/rootfs 
--setopt=logdir=/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/temp 
-x udev-cache --nogpgcheck install locale-base-en-us 
locale-base-en-gb packagegroup-core-boot 
packagegroup-core-eclipse-debug run-postinsts 
packagegroup-dey-bluetooth psplash packagegroup-core-ssh-dropbear 
packagegroup-dey-network packagegroup-base-extended 
packagegroup-dey-audio packagegroup-dey-wireless rpm dnf' returned 1:
Added oe-repo repo from 
/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/oe-rootfs-repo 

Last metadata expiration check: 0:00:00 ago on Fri 01 Jun 2018 
03:49:44 PM UTC.

Error:
  Problem: package packagegroup-base-1.0-r83.0.ccimx6ulstarter 
requires packagegroup-distro-base, but none of the providers can be 
installed
   - package packagegroup-base-extended-1.0-r83.0.ccimx6ulstarter 
requires packagegroup-base, but none of the providers can be installed
   - package packagegroup-distro-base-1.0-r83.0.ccimx6ulstarter 
requires packagegroup-dey-core, but none of the providers can be 
installed

   - conflicting requests
   - nothing provides busybox-hwclock needed by 
packagegroup-dey-core-1.0-r0.0.ccimx6ulstarter


ERROR: core-image-base-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/home/build/test/tmp/work/ccimx6ulstarter-dey-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_rootfs.2380 

ERROR: Task 
(/usr/local/dey-2.4/sources/poky/meta/recipes-core/images/core-image-base.bb:do_rootfs) 
failed with exit code '1'
NOTE: Tasks Summary: Attempted 4106 tasks of which 4105

[yocto] sysroot not being populated

2018-06-07 Thread Patrick Vacek

Hello all,

I have a recipe (aktualizr-hsm-prov) that depends on another (aktualizr)
to provide an executable and a config file. The former recipe includes
`DEPENDS = "aktualizr-native"`, and my do_install() for
aktualizr-hsm-prov has a line something like this:

aktualizr -i ${STAGING_DIR_NATIVE}${libdir}/sota.conf

The binary executable (aktualizr) runs, which tells me that the recipe
can find that. (Although to be honest, I'm not sure which version it is
running.) However, it doesn't find the config file, and sure enough,
${STAGING_DIR_NATIVE}${libdir} does not have the config file I expect. I
can see that aktualizr-native is populating its sysroot-destdir, but it
isn't getting copied to the sysroot for aktualizr-hsm-prov.

I see this problem in sumo and master, although previously this logic
has worked just fine in morty/pyro/rocko.

Switching to depending on aktualizr (instead of aktualizr-native) and
using STAGING_DIR_HOST or STAGING_DIR_TARGET does not help, and in fact
makes it worse, as it can't even find the aktualizr executable in that case.

What am I doing wrong? What changed between rocko and sumo?

Thanks,

Patrick Vacek
HERE Technologies


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

[yocto] Minutes: Yocto Project Weekly Triage Meeting

2018-06-07 Thread Jolley, Stephen K

Attendees: Armin, Stephen, Joshua, Amanda, Anuj, Richard, Ross, Randy, Trevor, 
Tim,
Wiki: 
https://wiki.yoctoproject.org/wiki/Bug_Triage
AR: Joshua - Close 
12771
AR: Anuj – Close 11431

Thanks,

Stephen K. Jolley
Yocto Project Project Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:  (208) 244-4460
• Email:stephen.k.jol...@intel.com

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

[yocto] Issue when integrating different bsp-layers on a single bblayers.conf

2018-06-07 Thread Iván Castell

Hello forum.

I am trying to integrate several BSP-layers for different platforms on a
single Yocto repository to build a Linux Yocto-based distro for all those
platforms easily.

The idea is maintaining a single bblayers.conf with all the layers
available, set PLATFORM and DISTRO on local.conf, call bitbake  and
get the final image for that platform.

When setting the "build" directory with a bblayers.conf customized for a
single platform, each platform builds the image recipe properly.

However, when I have integrated all bsp-layers in a single bblayers.conf,
the compilation of some platforms has been broken.

The specific problem is this: one bsp layer (meta-rockchip +
meta-rockchip-extra) defines a recipes-graphics/mesa/mesa_%.bbappend with
this content inside:

PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl
virtual/libwayland-egl"

That alters gstreamer recipe on the poky layer, getting this error when
building for a meta-intel platform:

ERROR: Nothing PROVIDES 'virtual/egl' (but
/data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/
gstreamer1.0-vaapi_1.12.2.bb,
/data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/
gstreamer1.0-plugins-bad_1.12.2.bb DEPENDS on or otherwise requires it)

My questions:

- Is a good practice to define a custom bblayers.conf depending on the
choosen PLATFORM?
- Is there some any other way to disable a BSP-layer completely when
building for a different one?
- Can you suggest a fix to solve this issue?

Thanks a lot in advance! :)

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

Re: [yocto] [meta-mingw][PATCH] mingw-w64-runtime: Fix build with gcc8

2018-06-07 Thread Khem Raj

On Thu, Jun 7, 2018 at 7:00 AM, Burton, Ross  wrote:
> I've a nigh-on identical patch in master-next running on the AB already:
>
> http://git.yoctoproject.org/cgit.cgi/meta-mingw/commit/?h=master-next=46b1bfd8ef26dd9c778504143d4dea2fbe2ce90f
>
> Don't have the security flags bit though (our mingw builds don't use
> that), can you rebase to master-next and submit that?
>

thanks for doing this. I sent another fix on top as a prize to you.

> Ross
>
>
> On 7 June 2018 at 14:53, Khem Raj  wrote:
>> Signed-off-by: Khem Raj 
>> ---
>>  .../mingw-w64/mingw-w64-headers/gcc8.patch| 30 +++
>>  .../mingw-w64/mingw-w64-headers_5.0.3.bb  |  5 ++--
>>  .../mingw-w64/mingw-w64-runtime_5.0.3.bb  |  2 ++
>>  3 files changed, 35 insertions(+), 2 deletions(-)
>>  create mode 100644 recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch
>>
>> diff --git a/recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch 
>> b/recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch
>> new file mode 100644
>> index 000..2b0eba3
>> --- /dev/null
>> +++ b/recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch
>> @@ -0,0 +1,30 @@
>> +>From revision 248028 in GCC 8 there is defined function _xgetbv:
>> +https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/xsaveintrin.h?r1=248028=248027=248028
>> +
>> +It conflicting with mingw-w64 definition from 
>> mingw-w64-headers/include/psdk_inc/intrin-impl.h
>> +
>> +workaround for mingw-w64:
>> +
>> +Signed-off-by: Khem Raj 
>> +Upstream-Status: Pending 
>> [https://sourceforge.net/p/mingw-w64/mailman/message/35866694/]
>> +
>> +Index: mingw-w64-headers/include/psdk_inc/intrin-impl.h
>> +===
>> +--- mingw-w64-headers.orig/include/psdk_inc/intrin-impl.h
>>  mingw-w64-headers/include/psdk_inc/intrin-impl.h
>> +@@ -1406,6 +1406,7 @@ __buildmov(__movsd, unsigned __LONG32, "
>> + #endif /* __INTRINSIC_PROLOG */
>> +
>> + /* NOTE: This should be in immintrin.h */
>> ++#if __GNUC__ < 8 /* GCC 8 already has _xgetbv defined */
>> + #if __INTRINSIC_PROLOG(_xgetbv)
>> + unsigned __int64 _xgetbv(unsigned int);
>> + __INTRINSICS_USEINLINE
>> +@@ -1426,6 +1427,7 @@ unsigned __int64 _xgetbv(unsigned int in
>> + }
>> + #define __INTRINSIC_DEFINED__xgetbv
>> + #endif /* __INTRINSIC_PROLOG */
>> ++#endif /* __GNUC__ < 8 */
>> +
>> + #endif /* defined(__x86_64__) || defined(_AMD64_) || defined(__i386__) || 
>> defined(_X86_) */
>> +
>> diff --git a/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb 
>> b/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb
>> index 31fa66f..58d7552 100644
>> --- a/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb
>> +++ b/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb
>> @@ -5,8 +5,9 @@ LIC_FILES_CHKSUM = 
>> "file://../COPYING;md5=bb936f0e04d8f1e19ad545100cee9654"
>>  COMPATIBLE_HOST = ".*-mingw.*"
>>
>>  SRC_URI = 
>> "${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2
>>  \
>> -   file://epsilon.patch"
>> -
>> +   file://epsilon.patch \
>> +   file://gcc8.patch \
>> +  "
>>  SRC_URI[md5sum] = "5524c20312560cc8683b7d8ee292cb8c"
>>  SRC_URI[sha256sum] = 
>> "2a601db99ef579b9be69c775218ad956a24a09d7dabc9ff6c5bd60da9ccc9cb4"
>>
>> diff --git a/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb 
>> b/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
>> index 928a464..0884778 100644
>> --- a/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
>> +++ b/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
>> @@ -43,3 +43,5 @@ do_configure() {
>>  FILES_${PN} += "${exec_prefix}/libsrc"
>>
>>  BBCLASSEXTEND = "nativesdk"
>> +
>> +SECURITY_CFLAGS_remove_mingw32 = "-fstack-protector-strong"
>> --
>> 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-mingw][PATCH 2/2] pthreads-win32: Disable ssp for pthreads-win32

2018-06-07 Thread Khem Raj

It compiles before gcc-runtime so ssp is not
yet available

Signed-off-by: Khem Raj 
---
 recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb 
b/recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb
index b462431..d9cd94e 100644
--- a/recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb
+++ b/recipes-devtools/pthreads-win32/pthreads-win32_2.9.1.bb
@@ -49,3 +49,5 @@ do_install() {
 install -m 0644 ${S}/pthreadGC2.dll ${D}${bindir}/libpthread-2.dll
 install -m 0644 ${S}/pthreadGC2.dll ${D}${bindir}/pthreadGC2.dll
 }
+
+SECURITY_CFLAGS_remove_mingw32 = "-fstack-protector-strong"
-- 
2.17.1

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

[yocto] [meta-mingw][PATCH V2 1/2] mingw-w64-runtime: Fix hardened build with gcc8

2018-06-07 Thread Khem Raj

Signed-off-by: Khem Raj 
---
 recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb 
b/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
index d249c79..a33a739 100644
--- a/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
+++ b/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
@@ -42,3 +42,5 @@ do_configure() {
 FILES_${PN} += "${exec_prefix}/libsrc"
 
 BBCLASSEXTEND = "nativesdk"
+
+SECURITY_CFLAGS_remove_mingw32 = "-fstack-protector-strong"
-- 
2.17.1

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

Re: [yocto] [meta-mingw][PATCH] mingw-w64-runtime: Fix build with gcc8

2018-06-07 Thread Burton, Ross

I've a nigh-on identical patch in master-next running on the AB already:

http://git.yoctoproject.org/cgit.cgi/meta-mingw/commit/?h=master-next=46b1bfd8ef26dd9c778504143d4dea2fbe2ce90f

Don't have the security flags bit though (our mingw builds don't use
that), can you rebase to master-next and submit that?

Ross


On 7 June 2018 at 14:53, Khem Raj  wrote:
> Signed-off-by: Khem Raj 
> ---
>  .../mingw-w64/mingw-w64-headers/gcc8.patch| 30 +++
>  .../mingw-w64/mingw-w64-headers_5.0.3.bb  |  5 ++--
>  .../mingw-w64/mingw-w64-runtime_5.0.3.bb  |  2 ++
>  3 files changed, 35 insertions(+), 2 deletions(-)
>  create mode 100644 recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch
>
> diff --git a/recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch 
> b/recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch
> new file mode 100644
> index 000..2b0eba3
> --- /dev/null
> +++ b/recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch
> @@ -0,0 +1,30 @@
> +>From revision 248028 in GCC 8 there is defined function _xgetbv:
> +https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/xsaveintrin.h?r1=248028=248027=248028
> +
> +It conflicting with mingw-w64 definition from 
> mingw-w64-headers/include/psdk_inc/intrin-impl.h
> +
> +workaround for mingw-w64:
> +
> +Signed-off-by: Khem Raj 
> +Upstream-Status: Pending 
> [https://sourceforge.net/p/mingw-w64/mailman/message/35866694/]
> +
> +Index: mingw-w64-headers/include/psdk_inc/intrin-impl.h
> +===
> +--- mingw-w64-headers.orig/include/psdk_inc/intrin-impl.h
>  mingw-w64-headers/include/psdk_inc/intrin-impl.h
> +@@ -1406,6 +1406,7 @@ __buildmov(__movsd, unsigned __LONG32, "
> + #endif /* __INTRINSIC_PROLOG */
> +
> + /* NOTE: This should be in immintrin.h */
> ++#if __GNUC__ < 8 /* GCC 8 already has _xgetbv defined */
> + #if __INTRINSIC_PROLOG(_xgetbv)
> + unsigned __int64 _xgetbv(unsigned int);
> + __INTRINSICS_USEINLINE
> +@@ -1426,6 +1427,7 @@ unsigned __int64 _xgetbv(unsigned int in
> + }
> + #define __INTRINSIC_DEFINED__xgetbv
> + #endif /* __INTRINSIC_PROLOG */
> ++#endif /* __GNUC__ < 8 */
> +
> + #endif /* defined(__x86_64__) || defined(_AMD64_) || defined(__i386__) || 
> defined(_X86_) */
> +
> diff --git a/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb 
> b/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb
> index 31fa66f..58d7552 100644
> --- a/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb
> +++ b/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb
> @@ -5,8 +5,9 @@ LIC_FILES_CHKSUM = 
> "file://../COPYING;md5=bb936f0e04d8f1e19ad545100cee9654"
>  COMPATIBLE_HOST = ".*-mingw.*"
>
>  SRC_URI = 
> "${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2
>  \
> -   file://epsilon.patch"
> -
> +   file://epsilon.patch \
> +   file://gcc8.patch \
> +  "
>  SRC_URI[md5sum] = "5524c20312560cc8683b7d8ee292cb8c"
>  SRC_URI[sha256sum] = 
> "2a601db99ef579b9be69c775218ad956a24a09d7dabc9ff6c5bd60da9ccc9cb4"
>
> diff --git a/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb 
> b/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
> index 928a464..0884778 100644
> --- a/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
> +++ b/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
> @@ -43,3 +43,5 @@ do_configure() {
>  FILES_${PN} += "${exec_prefix}/libsrc"
>
>  BBCLASSEXTEND = "nativesdk"
> +
> +SECURITY_CFLAGS_remove_mingw32 = "-fstack-protector-strong"
> --
> 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-mingw][PATCH] mingw-w64-runtime: Fix build with gcc8

2018-06-07 Thread Khem Raj

Signed-off-by: Khem Raj 
---
 .../mingw-w64/mingw-w64-headers/gcc8.patch| 30 +++
 .../mingw-w64/mingw-w64-headers_5.0.3.bb  |  5 ++--
 .../mingw-w64/mingw-w64-runtime_5.0.3.bb  |  2 ++
 3 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100644 recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch

diff --git a/recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch 
b/recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch
new file mode 100644
index 000..2b0eba3
--- /dev/null
+++ b/recipes-devtools/mingw-w64/mingw-w64-headers/gcc8.patch
@@ -0,0 +1,30 @@
+>From revision 248028 in GCC 8 there is defined function _xgetbv:
+https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/xsaveintrin.h?r1=248028=248027=248028
+
+It conflicting with mingw-w64 definition from 
mingw-w64-headers/include/psdk_inc/intrin-impl.h
+
+workaround for mingw-w64:
+
+Signed-off-by: Khem Raj 
+Upstream-Status: Pending 
[https://sourceforge.net/p/mingw-w64/mailman/message/35866694/]
+
+Index: mingw-w64-headers/include/psdk_inc/intrin-impl.h
+===
+--- mingw-w64-headers.orig/include/psdk_inc/intrin-impl.h
 mingw-w64-headers/include/psdk_inc/intrin-impl.h
+@@ -1406,6 +1406,7 @@ __buildmov(__movsd, unsigned __LONG32, "
+ #endif /* __INTRINSIC_PROLOG */
+ 
+ /* NOTE: This should be in immintrin.h */
++#if __GNUC__ < 8 /* GCC 8 already has _xgetbv defined */
+ #if __INTRINSIC_PROLOG(_xgetbv)
+ unsigned __int64 _xgetbv(unsigned int);
+ __INTRINSICS_USEINLINE
+@@ -1426,6 +1427,7 @@ unsigned __int64 _xgetbv(unsigned int in
+ }
+ #define __INTRINSIC_DEFINED__xgetbv
+ #endif /* __INTRINSIC_PROLOG */
++#endif /* __GNUC__ < 8 */
+ 
+ #endif /* defined(__x86_64__) || defined(_AMD64_) || defined(__i386__) || 
defined(_X86_) */
+ 
diff --git a/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb 
b/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb
index 31fa66f..58d7552 100644
--- a/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb
+++ b/recipes-devtools/mingw-w64/mingw-w64-headers_5.0.3.bb
@@ -5,8 +5,9 @@ LIC_FILES_CHKSUM = 
"file://../COPYING;md5=bb936f0e04d8f1e19ad545100cee9654"
 COMPATIBLE_HOST = ".*-mingw.*"
 
 SRC_URI = 
"${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2
 \
-   file://epsilon.patch"
-
+   file://epsilon.patch \
+   file://gcc8.patch \
+  "
 SRC_URI[md5sum] = "5524c20312560cc8683b7d8ee292cb8c"
 SRC_URI[sha256sum] = 
"2a601db99ef579b9be69c775218ad956a24a09d7dabc9ff6c5bd60da9ccc9cb4"
 
diff --git a/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb 
b/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
index 928a464..0884778 100644
--- a/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
+++ b/recipes-devtools/mingw-w64/mingw-w64-runtime_5.0.3.bb
@@ -43,3 +43,5 @@ do_configure() {
 FILES_${PN} += "${exec_prefix}/libsrc"
 
 BBCLASSEXTEND = "nativesdk"
+
+SECURITY_CFLAGS_remove_mingw32 = "-fstack-protector-strong"
-- 
2.17.1

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

[yocto] Run QEMU from within Eclipse

2018-06-07 Thread Peter Balazovic

Hello All,

I'd like to ask since I am setting uo the Eclipse IDE for Yocot app
development and I got stuck to start the QEMU from within Eclipse.

I got working QEMU image and seems running OK.

*ubuntu@ubuntu:~/work/community/build-x11$ runqemu qemuarm
tmp/deploy/images/qemuarm/zImage-qemuarm.bin
tmp/deploy/images/qemuarm/fsl-image-multimedia-full-qemuarm.ext4 *

Within the Eclipse I follow

https://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html#oxygen-starting-qemu-in-user-space-nfs-mode

But by configuring "External Tools" and tru to run QEMU I got following

*runqemu - INFO - Running MACHINE=qemuarm bitbake -e...*
*ERROR: Unable to find conf/bblayers.conf or conf/bitbake.conf. BBAPTH is
unset and/or not in a build directory?*
*runqemu - WARNING - Couldn't run 'bitbake -e' to gather environment
information:*

*runqemu - WARNING - Can't find qemuboot conf file, DEPLOY_DIR_IMAGE is
NULL!*
*runqemu - INFO - Running MACHINE=qemuarm bitbake -e...*
*ERROR: Unable to find conf/bblayers.conf or conf/bitbake.conf. BBAPTH is
unset and/or not in a build directory?*
*runqemu - WARNING - Couldn't run 'bitbake -e' to gather environment
information:*

*runqemu - INFO - Setting STAGING_DIR_NATIVE to OECORE_NATIVE_SYSROOT
(/home/ubuntu/work/community/build-x11/tmp/work/armv5e-fslc-linux-gnueabi/meta-ide-support/1.0-r3/recipe-sysroot-native)*
*runqemu - INFO - Setting STAGING_BINDIR_NATIVE to
/home/ubuntu/work/community/build-x11/tmp/work/armv5e-fslc-linux-gnueabi/meta-ide-support/1.0-r3/recipe-sysroot-native/usr/bin*
*runqemu - INFO - QB_MEM is not set, use 512M by default*
*runqemu - INFO - Continuing with the following parameters:*

*KERNEL:
[/home/ubuntu/work/community/build-x11/tmp/deploy/images/qemuarm/zImage-qemuarm.bin]*
*MACHINE: [qemuarm]*
*FSTYPE: [nfs]*
*NFS_DIR: [/home/ubuntu/work/community/build-x11/MY_QEMU_ROOTFS]*
*CONFFILE: []*

*/bin/sh: 1: stty: not found*
*Traceback (most recent call last):*
*  File "/home/ubuntu/work/community/sources/poky/scripts/runqemu", line
1270, in main*
*config.setup_network()*
*  File "/home/ubuntu/work/community/sources/poky/scripts/runqemu", line
997, in setup_network*
*self.saved_stty = subprocess.check_output("stty -g",
shell=True).decode('utf-8')*
*  File "/usr/lib/python3.5/subprocess.py", line 626, in check_output*
***kwargs).stdout*
*  File "/usr/lib/python3.5/subprocess.py", line 708, in run*
*output=stdout, stderr=stderr)*
*subprocess.CalledProcessError: Command 'stty -g' returned non-zero exit
status 127*
*Cleanup*
*Command 'lesspipe' is available in the following places*
* * /bin/lesspipe*
* * /usr/bin/lesspipe*
*The command could not be located because '/bin:/usr/bin' is not included
in the PATH environment variable.*
*lesspipe: command not found*
*Command 'dircolors' is available in '/usr/bin/dircolors'*
*The command could not be located because '/usr/bin' is not included in the
PATH environment variable.*
*dircolors: command not found*
*ubuntu@ubuntu:~/eclipse/cpp-oxygen/eclipse$ *


I wonder if any has experience on setting it up or solving similar issue?

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

[yocto] link loop in /tmp (bug in volatile)

2018-06-07 Thread star

I think there is something unintended to create a 
/var/volatile/tmp/tmp

as it links back to /var/volatile/tmp

So if you are in /tmp  and do a cd tmp you keep just where you are.
Does this folder /tmp/tmp does make any sense? I doubt about.

I think this line is not required in initscript/volatile
l root root 1777 /tmp /var/tmp

I now how to append a line to a file in Yocto, but howto write an bbappend to 
remove a certain line?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [linux-yocto 4.15] crypto: aes-generic - fix aes-generic regression on powerpc

Re: [yocto] mono-native is trying to install files into a shared area...

Re: [yocto] sysroot not being populated

Re: [yocto] Issue when integrating different bsp-layers on a single bblayers.conf

[yocto] [meta-security][PATCH 2/2] Fix build issue for apparmor when systemd is used

[yocto] [meta-security][PATCH 1/2] Fix build issue for apparmor kernel configuration

[yocto] [meta-security][PATCH 0/2] Fix build issue for apparmor

Re: [yocto] cgroups and iptables problems running docker - maybe my config wrong?

[yocto] sysroot not being populated

[yocto] Minutes: Yocto Project Weekly Triage Meeting

[yocto] Issue when integrating different bsp-layers on a single bblayers.conf

Re: [yocto] [meta-mingw][PATCH] mingw-w64-runtime: Fix build with gcc8

[yocto] [meta-mingw][PATCH 2/2] pthreads-win32: Disable ssp for pthreads-win32

[yocto] [meta-mingw][PATCH V2 1/2] mingw-w64-runtime: Fix hardened build with gcc8

Re: [yocto] [meta-mingw][PATCH] mingw-w64-runtime: Fix build with gcc8

[yocto] [meta-mingw][PATCH] mingw-w64-runtime: Fix build with gcc8

[yocto] Run QEMU from within Eclipse

[yocto] link loop in /tmp (bug in volatile)

18 matches

Site Navigation

Mail list logo

Footer information