Re: [yocto] Dunfell 3.1.1 gcc-sanitizers build failure

On Tue, Jun 30, 2020 at 5:08 PM Steve Sakoman via lists.yoctoproject.org wrote: > > On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt wrote: > > > > On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt wrote: > > > > > > On Tue, Jun 30, 2020 at 4:56 PM MikeB wrote: > > > > > > > > I recently tried upgrading f

Re: [yocto] Dunfell 3.1.1 gcc-sanitizers build failure

On Tue, Jun 30, 2020 at 4:53 PM Joshua Watt wrote: > > On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt wrote: > > > > On Tue, Jun 30, 2020 at 4:56 PM MikeB wrote: > > > > > > I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is > > > a bug or just my problem. I maintain five di

Re: [yocto] Dunfell 3.1.1 gcc-sanitizers build failure

On Tue, Jun 30, 2020 at 8:08 PM Joshua Watt wrote: > > On Tue, Jun 30, 2020 at 4:56 PM MikeB wrote: > > > > I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a > > bug or just my problem. I maintain five different architectures and all > > five have the same failure in g

Re: [yocto] Dunfell 3.1.1 gcc-sanitizers build failure

On Tue, Jun 30, 2020 at 4:56 PM MikeB wrote: > > I recently tried upgrading from 3.1.0 to 3.1.1. I'm not sure if this is a > bug or just my problem. I maintain five different architectures and all five > have the same failure in gcc-sanitizers as I'm trying to build the SDK. > > | cat: > /dat

[yocto] Enhancements/Bugs closed WW26!

All, The below were the owners of enhancements or bugs closed during the last week! Who Count timothy.t.orl...@intel.com 17 randy.macl...@windriver.com 5 akuster...@gmail.com 4 richard.pur...@linuxfoundation.org 4 david.re...@windriver.com 2 jpewhac...@gmail.com 1 bluelightn

Re: [yocto] Dunfell 3.1.1 gcc-sanitizers build failure

On 6/30/20 2:56 PM, MikeB wrote: I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a bug or just my problem.  I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK. | cat: /data/mabnhdev/exos-yocto

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#N

[yocto] Current high bug count owners for Yocto Project 3.2

All, Below is the list as of top 38 bug owners as of the end of WW26 of who have open medium or higher bugs and enhancements against YP 3.2. There are 86 possible work days left until the final release candidates for YP 3.2 needs to be released. Who Count david.re...@windriver.com 10 mar

[yocto] Dunfell 3.1.1 gcc-sanitizers build failure

I recently tried upgrading from 3.1.0 to 3.1.1.  I'm not sure if this is a bug or just my problem.  I maintain five different architectures and all five have the same failure in gcc-sanitizers as I'm trying to build the SDK. | cat: /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-sha

Re: [yocto] INCOMPATIBLE_LICENSE - how to use it properly?

On 6/30/20 3:07 AM, Mikko Rapeli wrote: Hi, On Tue, Jun 30, 2020 at 09:34:39AM +, John Ernberg wrote: Hi, I have been trying to use INCOMPATIBLE_LICENSE to filter out undesirable licenses for us from our images. I started simple and picked the examples from the manual (AGPL-3.0, GPL-3.0

Re: [yocto] Errors Building openjdk-8 on dunfell

On 6/29/20 10:13 PM, Robert Joslyn wrote: I'm trying to build openjdk-8 on dunfull and am getting some build errors. Using an Ubuntu 18.04 host, I get an error building the openjdk-8 recipe: | g++: error: unrecognized command line option ‘-fmacro-prefix- map=/mnt/yocto/bionic/poky/build/tmp/wo

[yocto][meta-mingw][PATCH] mingw-w64: Upgrade to 7.0.0

Signed-off-by: Joshua Watt --- recipes-devtools/mingw-w64/mingw-w64.inc | 3 +-- ...-headers_6.0.0.bb => nativesdk-mingw-w64-headers_7.0.0.bb} | 4 ...-runtime_6.0.0.bb => nativesdk-mingw-w64-runtime_7.0.0.bb} | 0 ...eads_6.0.0.bb => nativesdk-mingw-w64-winpthreads_7.0.

[yocto] [PATCH yocto-autobuilder-helper] config.json: add meta-arm

From: Ross Burton This builds a small number of images for the N1 SDP and Juno boards. Signed-off-by: Ross Burton --- config.json | 24 1 file changed, 24 insertions(+) diff --git a/config.json b/config.json index b810373..8823c32 100644 --- a/config.json +++ b/config

Re: [yocto] #yocto #python

On 6/26/20 4:15 AM, valentin.d...@weidmueller.com wrote: Hi, if I try to add a layer like this: bitbake-layers add-layer ../layers/meta-openembedded/meta-oe (also for other layers) I get following error: The following required tools (as specified by HOSTTOOLS) appear to be unavailable in PA

[yocto] Yocto Project Status WW26'20

Current Dev Position: YP 3.2 M2 Next Deadline: YP 3.2 M2 build date 2020/7/27 Next Team Meetings: * Bug Triage meeting Thursday July 2nd at 7:30am PDT ( https://zoom.us/j/454367603) * Monthly Project Meeting Tuesday July 7th at 8am PDT (

Re: [yocto] Need help understanding #devtool flow to library

Hi Stephan, On Tue, Jun 30, 2020 at 04:26:01AM -0700, tob...@synopsys.com wrote: > Hello! > > I am new to yocto, so I might be missing something obvious, but I have > trouble getting the devtool flow to work for me. It seems that the library > that ends up in the image is not the one with my mo

Re: [yocto] License reporting for golang (and rust)

Hi, For anyone else having the same problem, here's what I eventually did for my go stuff: I created a bbclass containing a task that gets inherited by all packages, but the task only does some work when it detects that it is inherited by a golang recipe. The task basically sets up GOPATH and cal

[yocto] Need help understanding #devtool flow to library

Hello! I am new to yocto, so I might be missing something obvious, but I have trouble getting the devtool flow to work for me. It seems that the library that ends up in the image is not the one with my modifications but instead the altered one. Here is what I have done: devtool modify This h

Re: [yocto] INCOMPATIBLE_LICENSE - how to use it properly?

It goes over a list of packages installed into their image, and checks their licensing. If something was directly built into something else, it will not produce a separate package, and therefore you need to handle that separately: perhaps by setting the package license appropriately in respective r

Re: [yocto] INCOMPATIBLE_LICENSE - how to use it properly?

Hi, On Tue, Jun 30, 2020 at 09:34:39AM +, John Ernberg wrote: > Hi, > > I have been trying to use INCOMPATIBLE_LICENSE to filter out undesirable > licenses for us from our images. I started simple and picked the > examples from the manual (AGPL-3.0, GPL-3.0 and LGPL-3.0). > > Currently we'

Re: [yocto] INCOMPATIBLE_LICENSE - how to use it properly?

Hi Alex, I will give this a try on master. One question though, will this still catch build-only libraries? (i.e. a library that consists only of headers). I don't think we have such recipes right now, it's more to understand how this feature works. Thank you. Best regards // John Ernberg On

Re: [yocto] INCOMPATIBLE_LICENSE - how to use it properly?

On master, you can set INCOMPATIBLE_LICENSE in the image recipe, rather than globally, then the check would only be performed on items that actually go into that image. Warrior does not have that feature yet, I think, so your only option there is meta-gpl2. Alex On Tue, 30 Jun 2020 at 11:34, Joh

[yocto] INCOMPATIBLE_LICENSE - how to use it properly?

Hi, I have been trying to use INCOMPATIBLE_LICENSE to filter out undesirable licenses for us from our images. I started simple and picked the examples from the manual (AGPL-3.0, GPL-3.0 and LGPL-3.0). Currently we're based on Warrior, but I also did a short test on master (results later in the

Re: [yocto] Error building openjdk-8 on zeus

So here is what I have done so far:. # Added meta-java layer in bblayers.conf and then did a bitbake -c cleanall glibc followed by bitbake glibc. Everything builds successfully. # As soon as I try to build bitbake core-image-full-cmdline, I get the following errors: ERROR: linux-yocto-5.2.17+g

[yocto] [PATCH yocto-autobuilder-helper] auh-config: send AUH update emails to oe-core list as well

Sadly, many maintainers do not act on AUH mails in a timely manner (or do not act at all). Sending these emails to oe-core list as well will allow other people to pick them up, and ease up the path to doing recipe version maintenance. Also, recently the amount of outdate recipes has been greatly r

[yocto] [AUH][PATCH 1/2] emailhandler: actually send messages to cc_list as well

Signed-off-by: Alexander Kanavin --- modules/utils/emailhandler.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/modules/utils/emailhandler.py b/modules/utils/emailhandler.py index 066f013..8c8b85b 100644 --- a/modules/utils/emailhandler.py +++ b/modules/utils/emailhandler.py @@ -103,6 +1

[yocto] [AUH][PATCH 2/2] upgradehelper: use a separate setting for CCing recipe upgrades

Previously it was same as status update recipients. Signed-off-by: Alexander Kanavin --- upgrade-helper.conf | 3 +++ upgradehelper.py| 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/upgrade-helper.conf b/upgrade-helper.conf index 98ef58f..e926300 100644 --- a/upgrade

[yocto] Error building openjdk-8 on zeus

Hello Everyone, When I am trying to add meta-java as a layer on zeus. I get the following error message: ERROR: glibc-2.30-r0 do_package: SYSTEMD_SERVICE_nscd value nscd.service does not exist ERROR: Logfile of failure stored in: /opt/graylog-poky/build/tmp/work/core2-64-poky-linux/glibc/2.30