[yocto] Are Windows SDKs (mingw layer) supposed to work?

Hi all, I am trying to enable a customer for using YP SDKs on Windows. It apparently is supposed to work, but I am unable to get past fatal errors. I have looked for documentation at the YP site and the meta-mingw repo, but to no avail. 1) My project is a simple default "qemux86-64" with

Re: [yocto] [meta-java][PATCH 00/14] openjdk-8 updates

On Mon, Mar 5, 2018 at 1:30 AM, André Draszik wrote: > Hi, > > OpenJDK8 in yocto is a bit outdated, so these patches > - update openjdk-8 from the 1.5 year old version 102b14 to the > current 162b12 > - modernize the recipe using bitbake variable overrides > - enable building

Re: [yocto] [meta-intel] [PATCH] systemd-boot: fix bbappend file to suit latest version

On 03/06/2018 05:51 AM, Cal Sullivan wrote: Thanks for the patch. I assume this is needed when OE-core merges the update to v236? Thanks, Cal Yes. It's needed when OE-core merges the update to v237. Best Regards, Chen Qi On 03/04/2018 06:03 PM, Chen Qi wrote: Fix the bbappend file to

Re: [yocto] Adding custom scripts to home directory and /etc/init.d/*

On 03/06/2018 05:18 AM, Giordon Stark wrote: > Hi all, > > I am wondering if there's a nice pattern or workflow within Yocto where > I can add a custom shell script to /etc/init.d for the purposes of > running it on OS boot (which also requires running update.rc I believe) You can inherit

Re: [yocto] [meta-intel] [PATCH] systemd-boot: fix bbappend file to suit latest version

Thanks for the patch. I assume this is needed when OE-core merges the update to v236? Thanks, Cal On 03/04/2018 06:03 PM, Chen Qi wrote: Fix the bbappend file to suit the latest systemd version. As systemd has now dropped autotools support, using ninja instead of make in do_compile.

[yocto] Adding custom scripts to home directory and /etc/init.d/*

Hi all, I am wondering if there's a nice pattern or workflow within Yocto where I can add a custom shell script to /etc/init.d for the purposes of running it on OS boot (which also requires running update.rc I believe) as well as prepopulating the home directory with some files of my choosing.

Re: [linux-yocto] [4.12][PATCH] drm/i915/cfl: Coffee Lake works on Kaby Lake PCH.

On 2018-03-05 4:01 AM, Liwei Song wrote: For linux-yocto-4.12 merged to standard/base -> BSPs. Bruce Thanks, Liwei. On 03/05/2018 04:53 PM, Liwei Song wrote: From: Rodrigo Vivi commit eb371933cf4d3495d0899880b2e0e252ce9db517 upstream. Coffee Lake CPU on Kaby

Re: [linux-yocto] [yocto-kernel-cache][PATCH] features/systemtap/systemtap.cfg: enable CONFIG_KERNEL_DEBUG

merged. Bruce On 2018-03-03 9:03 PM, Victor Kamensky wrote: Need to enable CONFIG_KERNEL_DEBUG in systemtap feature, otherwise CONFIG_DEBUG_INFO set by systemtap.cfg does not have any effect since it depends on CONFIG_KERNEL_DEBUG and is set off in resulting config. So systemtap cannot find

Re: [linux-yocto] [PATCH] aufs: fix compile warning

This is now merged. Given the description, I merged it to 4.12, 4.14 and 4.15. If the 4.14/4.15 merge is invalid, let me know so I can revert. Bruce On 2018-02-28 8:44 PM, Dengke Du wrote: From: "Kexin(Casey) Chen" Forward port linux-yocto-4.8's patch to fix the

Re: [linux-yocto] [Yocto kernel 4.1 pull request]

On 03/05/2018 10:51 AM, Bruce Ashfield wrote: > On 2018-03-04 7:34 PM, Armin Kuster wrote: >> This series includes the lsb runqemu kvm boot issue [ Yocto #12570 ], >> Spectre v1 and misc bug fixes 4.4 backports. >> >> The following changes since commit >>

Re: [linux-yocto] [Yocto kernel 4.1 pull request]

On 2018-03-04 7:34 PM, Armin Kuster wrote: This series includes the lsb runqemu kvm boot issue [ Yocto #12570 ], Spectre v1 and misc bug fixes 4.4 backports. The following changes since commit 1368b7448d693cedb384f6e0b9a0237adb1b8259: kaiser: x86: Fix NMI handling (2018-02-22 12:18:09

[yocto] Strange filesystem problem using docker on a pyro based system

I am building docker on a pyro based system. I'm using the overlay storage driver, and I am getting a strange result: When I add a file to a container, any files in the same directory that come from the base image disappear... Here is a short script that highlights what I mean: docker build

Re: [yocto] [OE-core] Subject: Yocto Project Status WW10’18

On 5 March 2018 at 16:30, akuster808 wrote: > >- Performance metrics indicate that a recent merge has caused a >slowdown in build times. > > Is this data publicly available? > https://lists.yoctoproject.org/pipermail/yocto-perf/2018-March/thread.html The HTML

Re: [yocto] Subject: Yocto Project Status WW10’18

On 03/05/2018 08:03 AM, Jordan, Robin L wrote: > > Subject: Yocto Project Status WW10’18 > >   > > Current Dev Position: YP 2.5 M3 final close out. > > Next Deadline: YP 2.5 M3 cut off was 2/19/18 > > *** FEATURE FREEZE for 2.5 has passed *** > >   > > SWAT team rotation: Rebecca -> Cal on March

Re: [yocto] RREPLACE is not applied do_package_qa() ?

That isn't what replaces is for: RREPLACES is used to hint to the package manager what package should be removed when there are conflicts. It won't have any impact on package dependencies at any other time. Ross On 1 March 2018 at 03:29, ikjn wrote: > Hi. > > I'm building

[yocto] Yocto plugin java null pointer exception issue.

Hello, We are currently building windows SDK using Yocto 2.4. So far we are able to generate SDK for windows but getting "java null pointer exception". We found there was bug raised for same issue but, we are still facing same issue in

Re: [yocto] [dev] [meta-oic] Question about Iotivity 1.3.0/1 and fixes status

On Fri, Jan 12, 2018 at 3:26 AM, Chanho Park wrote: > Hi Philippe, > > On Thu, 11 Jan 2018 at 7:11 PM Philippe Coval com> wrote: > >> >> On 11/01/18 02:30, Chanho Park wrote: >> > Hi Philippe, >> > > > > Okay. I’ll test them when you resend

[yocto] RREPLACE is not applied do_package_qa() ?

Hi. I'm building mali userspace libraries using meta-mali layer + rocko but I got errors like these: ERROR: cogl-1.0-1.22.2-r0 do_package_qa: QA Issue: /usr/lib/libcogl-pango.so.20.4.2 contained in package libcogl-pango requires libwayland-egl.so, but no providers found in

[yocto] Unable to generate licenses

I'm using bitbake version 1.28 and trying to get the license manifest for my project. I've made the changes described in "Maintaining Open Source License Compliance During Your Product's Lifecycle" of the Mega-Manual and also tried adding "inherit license" to my recipe, but while I do get the

[yocto] Subject: Yocto Project Status WW10’18

Subject: Yocto Project Status WW10’18 Current Dev Position: YP 2.5 M3 final close out. Next Deadline: YP 2.5 M3 cut off was 2/19/18 *** FEATURE FREEZE for 2.5 has passed *** SWAT team rotation: Rebecca -> Cal on March 9, 2018 SWAT team rotation: Cal -> Armin on March 16, 2018

Re: [yocto] Connecting AutoBuilder output to GitLab for meta-mono CI

On 05/03/2018 10:35, Paul Barker wrote: On Mon, Mar 5, 2018 at 9:52 AM, Alex Lennon wrote: Hi all, I've been running an autobuilder locally for a while now to automate testing of meta-mono commits. I see recently saw GitLab seems to support CI workers

Re: [yocto] bitbake: git and patch problem

> -Original Message- > From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] > Sent: maandag 5 maart 2018 15:09 > Subject: Re: [yocto] bitbake: git and patch problem > > Out of curiosity .. why is that unexpected, or inconvenient ? I never want a > git > repository to have

Re: [yocto] bitbake: git and patch problem

On 2018-03-05 5:33 AM, EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1) wrote: I'm experiencing strange (at least to my eyes) behaviour from bitbake. My recipe specifies a git repository as the main SRC_URI, then, in a variant created using an append file adds a patch like this:

Re: [yocto] bitbake: git and patch problem

> From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > Sent: maandag 5 maart 2018 12:13 > Subject: Re: [yocto] bitbake: git and patch problem > > On Mon, 5 Mar 2018, EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1) wrote: > > > I'm experiencing strange (at least to my eyes) behaviour from bitbake.

Re: [yocto] bitbake: git and patch problem

On Mon, 5 Mar 2018, EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1) wrote: > I'm experiencing strange (at least to my eyes) behaviour from > bitbake. My recipe specifies a git repository as the main SRC_URI, > then, in a variant created using an append file adds a patch like > this: > >

[yocto] bitbake: git and patch problem

I'm experiencing strange (at least to my eyes) behaviour from bitbake. My recipe specifies a git repository as the main SRC_URI, then, in a variant created using an append file adds a patch like this: SRC_URI_append_mystuff += "file://mystuff.patch" As expected, this grabs the sources from the

Re: [yocto] Connecting AutoBuilder output to GitLab for meta-mono CI

On Mon, Mar 5, 2018 at 9:52 AM, Alex Lennon wrote: > Hi all, > > I've been running an autobuilder locally for a while now to automate testing > of meta-mono commits. > > I see recently saw GitLab seems to support CI workers publishing logs and > artifacts to the

[yocto] QA cycle report for 2.4.2 RC2

Hello All, This is the full report for 2.4.2 RC2: https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2 === Summary The QA cycle for release 2.4.2 RC2 was completed including the performance test.  Team had not discovered any new bug. Performance

[yocto] Connecting AutoBuilder output to GitLab for meta-mono CI

Hi all, I've been running an autobuilder locally for a while now to automate testing of meta-mono commits. I see recently saw GitLab seems to support CI workers publishing logs and artifacts to the site and this seems a useful thing to me. Does anybody have any pointers on where to go look

[yocto] [meta-java][PATCH 13/14] openjdk-8: fix musl build

From: André Draszik Add various patches to make it work in musl. Some of them are generic enough to be applied for all builds, some need to be specific to musl. Signed-off-by: André Draszik --- recipes-core/openjdk/openjdk-8-release-162b12.inc |

[yocto] [meta-java][PATCH 14/14] openjdk-8: add aarch64 support

From: André Draszik This is using the aarch64 port to make it work, which is at version u161b15. We also add one patch to make this work with musl, too. Because the aarch64 port is fetched from a different repository, the version specific include has been split so as to

[yocto] [meta-java][PATCH 08/14] openjdk-8: add patches to support building against system libpng & libjpeg

From: André Draszik This didn't actually before. Patches taken from Debian / OpenJDK-9. Signed-off-by: André Draszik --- recipes-core/openjdk/openjdk-8-cross.inc | 5 +- recipes-core/openjdk/openjdk-8-native.inc | 6 +-

[yocto] [meta-java][PATCH 09/14] openjdk-8-native: really use system libgif & zlib

From: André Draszik The intention seems to be to build against above system libraries, but configure still picked the bundled versions, even though the libraries are in the sysroot. Make it deterministic and force use of the system libraries using PACKAGECONFIG and the

[yocto] [meta-java][PATCH 12/14] openjdk-8: stop passing obsolete make variables (freetype)

From: André Draszik OpenJDK's build system complains about passing in obsolete ALT_ variables. Stop passing in those for freetype, as pkg-config is used to figure out the correct compiler and linker flags. Signed-off-by: André Draszik ---

[yocto] [meta-java][PATCH 11/14] openjdk-8: rename PACKAGECONFIG zip -> zlib

From: André Draszik The existing PACKAGECONFIG option 'zip' affects OpenJDK's usage of zlib, not zip, so this option is a bit inconsistent and confusing. Rename to zlib. Signed-off-by: André Draszik --- recipes-core/openjdk/openjdk-8-cross.inc |

[yocto] [meta-java][PATCH 10/14] openjdk-8: build against system libgif & zlib by default

From: André Draszik This should really be the default so as to benefit from CVE fixes etc. Signed-off-by: André Draszik --- recipes-core/openjdk/openjdk-8-cross.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[yocto] [meta-java][PATCH 07/14] openjdk-8: add patch for compiling with enabled security flags

From: André Draszik Rather than carrying an OE specific patch that just silences the warning on some platform only, backport the upstream patch to actually fix the issue. Signed-off-by: André Draszik ---

[yocto] [meta-java][PATCH 06/14] openjdk-8: fix a compiler warning

From: André Draszik As per the patch Signed-off-by: André Draszik --- recipes-core/openjdk/openjdk-8-release-162b12.inc | 1 + ...dk-comparison-between-pointer-and-integer.patch | 144 + 2 files changed, 145 insertions(+)

[yocto] [meta-java][PATCH 02/14] openjdk-8: doesn't compile on aarch64

From: André Draszik OpenJDK's build system just doesn't support it (it somehow picks compiler flags for am64 builds, which are invalid for aarch64). Signed-off-by: André Draszik --- recipes-core/openjdk/openjdk-8-common.inc | 2 ++ 1 file changed,

[yocto] [meta-java][PATCH 01/14] openjdk-8: clarify a bitbake warning

From: André Draszik We get a bitbake warning during recipe building complaining about unsupported architectures unconditionally. That check is relevant only for shark builds, so it is quite confusing for non-shark builds. Make the warning conditional on whether shark

[yocto] [meta-java][PATCH 00/14] openjdk-8 updates

Hi, OpenJDK8 in yocto is a bit outdated, so these patches - update openjdk-8 from the 1.5 year old version 102b14 to the current 162b12 - modernize the recipe using bitbake variable overrides - enable building with 'security' flags enabled - fix the aarch64 build (by using the aarch64 port,

Re: [yocto] Run application at system boot

Hi , On 12/05/2017 07:51 PM, Laurentiu-Cristian Duca wrote: Hello yocto community, I want to know a few things about how to configure yocto such that - a simple application (let's say a hello world C program from a new recipe) is run at boot time. use update-rc.d class INITSCRIPT_NAME =

Re: [linux-yocto] [4.12][PATCH] drm/i915/cfl: Coffee Lake works on Kaby Lake PCH.

For linux-yocto-4.12 Thanks, Liwei. On 03/05/2018 04:53 PM, Liwei Song wrote: > From: Rodrigo Vivi > > commit eb371933cf4d3495d0899880b2e0e252ce9db517 upstream. > > Coffee Lake CPU on Kaby Lake PCH is possible. > It does exist, and it does work. > > The only missed

[linux-yocto] [PATCH] drm/i915/cfl: Coffee Lake works on Kaby Lake PCH.

From: Rodrigo Vivi commit eb371933cf4d3495d0899880b2e0e252ce9db517 upstream. Coffee Lake CPU on Kaby Lake PCH is possible. It does exist, and it does work. The only missed case was this warning here noticed by Wendy who could get one system with this configuration and

[linux-yocto] [PATCH] Fix kernel warnning on cfl-s(KBL PCH) board

Backport an upstream patch, fix the following kernel warnning on CoffeeLake + KabyLake PCH board: [3.689176] WARN_ON(!((dev_priv)->info.platform == INTEL_SKYLAKE) && !((dev_priv)->info.platform == INTEL_KABYLAKE)) [3.689191] [ cut here ] [3.690301] WARNING: