[yocto] Error building openjdk-8 on zeus

[srijan . nandi]

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-r0/temp/log.do_package.28895

ERROR: Task 
(/opt/graylog-poky/meta/recipes-core/glibc/glibc_2.30.bb:do_package) failed 
with exit code '1'

Thanks,
-=Srijan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49774): https://lists.yoctoproject.org/g/yocto/message/49774
Mute This Topic: https://lists.yoctoproject.org/mt/75209521/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Alexander Kanavin]

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 +103,8 @@ class Email(object):
 try:
 smtp = SMTP(self.smtp_host, self.smtp_port)
 smtp.sendmail(self.from_addr, to_addr, msg_text)
+if cc_addr is not None:
+smtp.sendmail(self.from_addr, cc_addr, msg_text)
 smtp.close()
 except Exception as e:
 E("Could not send email: %s" % str(e))
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49775): https://lists.yoctoproject.org/g/yocto/message/49775
Mute This Topic: https://lists.yoctoproject.org/mt/75210261/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Alexander Kanavin]

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-helper.conf
+++ b/upgrade-helper.conf
@@ -31,6 +31,9 @@
 # except when recipes are owned by specific maintainer_override entries above.
 #global_maintainer_override=john@doe.com
 
+# who should be CCd with all upgrade emails (optional)
+#cc_recipients=john@doe.com
+
 # who should get the status mail with statistics, at the end (optional)
 #status_recipients=john@doe.com
 
diff --git a/upgradehelper.py b/upgradehelper.py
index 061d18d..c2480f1 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -321,8 +321,8 @@ class Updater(object):
 to_addr = pkg_ctx['MAINTAINER']
 
 cc_addr = None
-if "status_recipients" in settings:
-cc_addr = settings["status_recipients"].split()
+if "cc_recipients" in settings:
+cc_addr = settings["cc_recipients"].split()
 
 newversion = pkg_ctx['NPV'] if not 
pkg_ctx['NPV'].endswith("new-commits-available") else pkg_ctx['NSRCREV']
 subject = "[AUH] " + pkg_ctx['PN'] + ": upgrading to " + newversion
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49776): https://lists.yoctoproject.org/g/yocto/message/49776
Mute This Topic: https://lists.yoctoproject.org/mt/75210262/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Alexander Kanavin]

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 reduced,
so there should not be too many of those emails each month.

Signed-off-by: Alexander Kanavin 
---
 scripts/auh-config/upgrade-helper.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/auh-config/upgrade-helper.conf 
b/scripts/auh-config/upgrade-helper.conf
index fbf5d8a..b012600 100644
--- a/scripts/auh-config/upgrade-helper.conf
+++ b/scripts/auh-config/upgrade-helper.conf
@@ -14,6 +14,8 @@ smtp=smtp1.yoctoproject.org:25
 from=a...@auh.yoctoproject.org
 # who should get the status mail with statistics, at the end
 status_recipients=openembedded-c...@lists.openembedded.org
+# who should be CCd with upgrade emails
+cc_recipients=openembedded-c...@lists.openembedded.org
 # clean sstate directory before upgrading
 #clean_sstate=yes
 # clean tmp directory before upgrading
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49777): https://lists.yoctoproject.org/g/yocto/message/49777
Mute This Topic: https://lists.yoctoproject.org/mt/75210378/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[srijan . nandi]

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+gitAUTOINC+bb2776d6be_25b14cdf96-r0 do_package: Error 
executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
0001:
*** 0002:split_kernel_module_packages(d)
0003:
File: '/opt/graylog-poky/meta/classes/kernel-module-split.bbclass', lineno: 
171, function: split_kernel_module_packages
0167:    # avoid warnings. removedirs only raises an OSError if an empty
0168:    # directory cannot be removed.
0169:    dvar = d.getVar('PKGD')
0170:    for dir in ["%s/etc/modprobe.d" % (dvar), "%s/etc/modules-load.d" % 
(dvar), "%s/etc" % (dvar)]:
*** 0171:        if len(os.listdir(dir)) == 0:
0172:            os.rmdir(dir)
0173:}
0174:
0175:do_package[vardeps] += '${@" ".join(map(lambda s: "module_conf_" + s, 
(d.getVar("KERNEL_MODULE_PROBECONF") or "").split()))}'
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'/opt/graylog-poky/build/tmp/work/genericx86_64-poky-linux/linux-yocto/5.2.17+gitAUTOINC+bb2776d6be_25b14cdf96-r0/package/etc/modprobe.d'

ERROR: Logfile of failure stored in: 
/opt/graylog-poky/build/tmp/work/genericx86_64-poky-linux/linux-yocto/5.2.17+gitAUTOINC+bb2776d6be_25b14cdf96-r0/temp/log.do_package.29306
ERROR: Task 
(/opt/graylog-poky/meta/recipes-kernel/linux/linux-yocto_5.2.bb:do_package) 
failed with exit code '1'
ERROR: volatile-binds-1.0-r0 do_package: SYSTEMD_SERVICE_volatile-binds value 
var-volatile-lib.service does not exist
ERROR: Logfile of failure stored in: 
/opt/graylog-poky/build/tmp/work/all-poky-linux/volatile-binds/1.0-r0/temp/log.do_package.29309
ERROR: Task 
(/opt/graylog-poky/meta/recipes-core/volatile-binds/volatile-binds.bb:do_package)
 failed with exit code '1'
ERROR: run-postinsts-1.0-r10 do_package: SYSTEMD_SERVICE_run-postinsts value 
run-postinsts.service does not exist
ERROR: Logfile of failure stored in: 
/opt/graylog-poky/build/tmp/work/all-poky-linux/run-postinsts/1.0-r10/temp/log.do_package.29316
ERROR: Task 
(/opt/graylog-poky/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb:do_package)
 failed with exit code '1'

# If I remove the meta-java layer from bblayers.conf, everything builds 
successfully.

-=Srijan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49778): https://lists.yoctoproject.org/g/yocto/message/49778
Mute This Topic: https://lists.yoctoproject.org/mt/75209521/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] INCOMPATIBLE_LICENSE - how to use it properly?

[John Ernberg]

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 message)

Our images use systemd as init system. We use busybox ash as shell on 
these images for now.

When setting the INCOMPATIBLE_LICENSE according to the manual example, 
systemd cannot be built anymore because bash is being skipped due to 
license.

Turns out that because systemd-bash-completion and 
systemd-kernel-install both rdepend on bash, we can't build systemd at 
all, because bash is not buildable. Even if we're not installing those 
features of systemd.

A dive into TaskData suggests that all the rdepends of all packages 
provided by a recipe are flattened into depends of the recipe when 
testing buildability.

A quick test on master from about 2 weeks ago show the same behavior.

For the test on master all I did was change the DISTRO_FEATURES of 
core-image-minimal to include systemd.


Am I using ICOMPATIBLE_LICENSE properly so far?
If so, is being unable to fulfill an rdepend for an unused package meant 
to fail the whole build, and how can I avoid it short of including 
meta-gplv2 or writing lots of .bbappends to remove the dependencies?
Otherwise, where did I go wrong, and what should I be trying instead?

Thank you.

Best regards // John Ernberg
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49779): https://lists.yoctoproject.org/g/yocto/message/49779
Mute This Topic: https://lists.yoctoproject.org/mt/75210517/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Alexander Kanavin]

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, 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 based on Warrior, but I also did a short test on master
> (results later in the message)
>
> Our images use systemd as init system. We use busybox ash as shell on
> these images for now.
>
> When setting the INCOMPATIBLE_LICENSE according to the manual example,
> systemd cannot be built anymore because bash is being skipped due to
> license.
>
> Turns out that because systemd-bash-completion and
> systemd-kernel-install both rdepend on bash, we can't build systemd at
> all, because bash is not buildable. Even if we're not installing those
> features of systemd.
>
> A dive into TaskData suggests that all the rdepends of all packages
> provided by a recipe are flattened into depends of the recipe when
> testing buildability.
>
> A quick test on master from about 2 weeks ago show the same behavior.
>
> For the test on master all I did was change the DISTRO_FEATURES of
> core-image-minimal to include systemd.
>
>
> Am I using ICOMPATIBLE_LICENSE properly so far?
> If so, is being unable to fulfill an rdepend for an unused package meant
> to fail the whole build, and how can I avoid it short of including
> meta-gplv2 or writing lots of .bbappends to remove the dependencies?
> Otherwise, where did I go wrong, and what should I be trying instead?
>
> Thank you.
>
> Best regards // John Ernberg
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49780): https://lists.yoctoproject.org/g/yocto/message/49780
Mute This Topic: https://lists.yoctoproject.org/mt/75210517/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[John Ernberg]

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 6/30/20 11:55 AM, Alexander Kanavin wrote:
> 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, 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 based on Warrior, but I also did a short test on master
> (results later in the message)
> 
> Our images use systemd as init system. We use busybox ash as shell on
> these images for now.
> 
> When setting the INCOMPATIBLE_LICENSE according to the manual example,
> systemd cannot be built anymore because bash is being skipped due to
> license.
> 
> Turns out that because systemd-bash-completion and
> systemd-kernel-install both rdepend on bash, we can't build systemd at
> all, because bash is not buildable. Even if we're not installing those
> features of systemd.
> 
> A dive into TaskData suggests that all the rdepends of all packages
> provided by a recipe are flattened into depends of the recipe when
> testing buildability.
> 
> A quick test on master from about 2 weeks ago show the same behavior.
> 
> For the test on master all I did was change the DISTRO_FEATURES of
> core-image-minimal to include systemd.
> 
> 
> Am I using ICOMPATIBLE_LICENSE properly so far?
> If so, is being unable to fulfill an rdepend for an unused package
> meant
> to fail the whole build, and how can I avoid it short of including
> meta-gplv2 or writing lots of .bbappends to remove the dependencies?
> Otherwise, where did I go wrong, and what should I be trying instead?
> 
> Thank you.
> 
> Best regards // John Ernberg
> 
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49781): https://lists.yoctoproject.org/g/yocto/message/49781
Mute This Topic: https://lists.yoctoproject.org/mt/75210517/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Mikko Rapeli]

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 based on Warrior, but I also did a short test on master 
> (results later in the message)
> 
> Our images use systemd as init system. We use busybox ash as shell on 
> these images for now.
> 
> When setting the INCOMPATIBLE_LICENSE according to the manual example, 
> systemd cannot be built anymore because bash is being skipped due to 
> license.
> 
> Turns out that because systemd-bash-completion and 
> systemd-kernel-install both rdepend on bash, we can't build systemd at 
> all, because bash is not buildable. Even if we're not installing those 
> features of systemd.
> 
> A dive into TaskData suggests that all the rdepends of all packages 
> provided by a recipe are flattened into depends of the recipe when 
> testing buildability.
> 
> A quick test on master from about 2 weeks ago show the same behavior.
> 
> For the test on master all I did was change the DISTRO_FEATURES of 
> core-image-minimal to include systemd.
> 
> 
> Am I using ICOMPATIBLE_LICENSE properly so far?
> If so, is being unable to fulfill an rdepend for an unused package meant 
> to fail the whole build, and how can I avoid it short of including 
> meta-gplv2 or writing lots of .bbappends to remove the dependencies?
> Otherwise, where did I go wrong, and what should I be trying instead?

You need to add exceptions to build a lot GPLv3 components but not let them
be part of product images.

In distro config:

INCOMPATIBLE_LICENSE += "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
...
WHITELIST_GPL-3.0 += "bash"
PACKAGE_EXCLUDE += "bash-ptest bash-dbg bash-staticdev bash-dev bash-doc 
bash-locale bashbug bash"
...

The PACKAGE_EXCLUDE must be complete list of binary packages produced by the 
recipe.

I end up enabling a large set of GPLv3 tools for use as development tooling at 
build
time or in SDK:

$ grep WHITELIST_ distro.conf
WHITELIST_GPL-3.0 += "autoconf"
WHITELIST_GPL-3.0 += "bash"
WHITELIST_GPL-3.0 += "bc"
WHITELIST_GPL-3.0 += "binutils"
WHITELIST_GPL-3.0 += "bison"
WHITELIST_GPL-3.0 += "ccache"
WHITELIST_GPL-3.0 += "coreutils"
WHITELIST_GPL-3.0 += "diffutils"
WHITELIST_GPL-3.0 += "elfutils"
WHITELIST_GPL-3.0 += "findutils"
WHITELIST_GPL-3.0 += "gawk"
WHITELIST_GPL-3.0 += "gdb"
WHITELIST_GPL-3.0 += "gdbm"
WHITELIST_GPL-3.0 += "gettext"
WHITELIST_GPL-3.0 += "gnutls"
WHITELIST_GPL-3.0 += "grep"
WHITELIST_GPL-3.0 += "libevent"
WHITELIST_GPL-3.0 += "libpipeline"
WHITELIST_GPL-3.0 += "libunistring"
WHITELIST_GPL-3.0 += "m4"
WHITELIST_GPL-3.0 += "make"
WHITELIST_GPL-3.0 += "readline"
WHITELIST_GPL-3.0 += "rsync"
WHITELIST_GPL-3.0 += "sed"
WHITELIST_GPL-3.0 += "which"

If one does not do this, alternative is to use a bunch of old and deprecated 
tool
versions from meta-gplv2.

Hope this helps,

-Mikko-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49782): https://lists.yoctoproject.org/g/yocto/message/49782
Mute This Topic: https://lists.yoctoproject.org/mt/75210517/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Alexander Kanavin]

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 recipes (they needs to carry the licenses of items coming
directly as headers from other recipes).

Alex

On Tue, 30 Jun 2020 at 12:01, John Ernberg  wrote:

> 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 6/30/20 11:55 AM, Alexander Kanavin wrote:
> > 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, 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 based on Warrior, but I also did a short test on
> master
> > (results later in the message)
> >
> > Our images use systemd as init system. We use busybox ash as shell on
> > these images for now.
> >
> > When setting the INCOMPATIBLE_LICENSE according to the manual
> example,
> > systemd cannot be built anymore because bash is being skipped due to
> > license.
> >
> > Turns out that because systemd-bash-completion and
> > systemd-kernel-install both rdepend on bash, we can't build systemd
> at
> > all, because bash is not buildable. Even if we're not installing
> those
> > features of systemd.
> >
> > A dive into TaskData suggests that all the rdepends of all packages
> > provided by a recipe are flattened into depends of the recipe when
> > testing buildability.
> >
> > A quick test on master from about 2 weeks ago show the same behavior.
> >
> > For the test on master all I did was change the DISTRO_FEATURES of
> > core-image-minimal to include systemd.
> >
> >
> > Am I using ICOMPATIBLE_LICENSE properly so far?
> > If so, is being unable to fulfill an rdepend for an unused package
> > meant
> > to fail the whole build, and how can I avoid it short of including
> > meta-gplv2 or writing lots of .bbappends to remove the dependencies?
> > Otherwise, where did I go wrong, and what should I be trying instead?
> >
> > Thank you.
> >
> > Best regards // John Ernberg
> > 
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49783): https://lists.yoctoproject.org/g/yocto/message/49783
Mute This Topic: https://lists.yoctoproject.org/mt/75210517/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Need help understanding #devtool flow to library

[tobies]

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 has successfully checked out the sources of the library that I want to 
modify and I could make my modifications and build the changed version with 
"devtool build vsomeip" . Now when I build an image with "devtool build-image 
", devtool reports that it would build the image with addtional 
package "vsomeip".

But the library that ends up in the generated image does not seem to have the 
modified code. I do not find my additional symbols when I do an objdump on the 
library in

./tmp/work/qemux86-poky-linux//1.0-r0/rootfs/usr/lib/libvsomeip...

On the other hand, the library built in 
./tmp/work/i586-poky-linux/vsomeip/2.10.21-r0/vsomeip-2.10.21/libvsomeip.so.2.10.21
 does have these symbols.

The disconnect seems to happen already within the vsomeip library build 
process. The library present at 
./tmp/work/i586-poky-linux/vsomeip/2.10.21-r0/package/usr/lib/libvsomeip.so.2.10.21
 is one _without_ my changes present (and identical in size to the one on the 
rootfs folder of the image).

It feels like I am missing a step of the devtool flow, or at least the starting 
point to debug the deployment process.

Any hints of pointers to relevant documentation would be very appreciated!

Thanks a lot!

Stephan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49784): https://lists.yoctoproject.org/g/yocto/message/49784
Mute This Topic: https://lists.yoctoproject.org/mt/75211655/21656
Mute #devtool: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/devtool
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Irving ST]

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 calls
https://github.com/rancher/trash - this tool populates all the source
dependencies and generate a trash.lock file in the repository.
Then I used https://github.com/pivotal/LicenseFinder to generate a
json report that can be postprocessed with python.

To me it seems that Go used the vendor directory approach in the past,
and there are multiple tools that can be used for this; and nowadays
go seems to have switched to a different approach called go modules.
With this multiple tools and methods of managing dependencies, I am
not sure whether it is feasible to integrate this in Yocto at all -
though I think I have seen mailing list posts on meta-virtualization
adding vendor information to their recipes, so maybe some progress is
happening there.

Best regards,
Irving Tjiptowarsono

On Tue, Jun 30, 2020 at 7:32 AM Robert ber...@yocto.user
 wrote:
>
> Hi,
>
> My comments are in-line
>
> On 22/06/2020 11:53, Irving ST wrote:
> > Hello,
> >
> > I am building a device that uses some Go (and Rust) dependencies. This
> > is on Yocto 2.7 / Warrior.
> >
> > I noticed that after building an image, the generated license.manifest
> > and package.manifest (in tmp/deploy/licenses/) does not contain any
> > mention of go packages or rust crates. The go packages seem to
> > generate directories in tmp/deploy/licenses/ but they do not seem to
> > be reported in the final image.
>
> On dunfell 3.1.1 I see this:
>
> licenses/
> └── github.com-influxdata-influxdb
>  ├── generic_MIT
>  ├── LICENSE
>  └── recipeinfo
>
> which is wrong, since I would need to add all the licenses of all the
> dependencies golang pulls in as well to the recipe. It's shows only the
> top level license.
>
> In my license manifest I do have the influxdb:
>
> tmp/deploy/licenses/image-influxdb-from-source-container-x86-64-20200629205620/license.manifest
>
> PACKAGE NAME: github.com-influxdata-influxdb
> PACKAGE VERSION: 1.8.0
> RECIPE NAME: github.com-influxdata-influxdb
> LICENSE: MIT
>
> Regards,
>
> Robert
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49785): https://lists.yoctoproject.org/g/yocto/message/49785
Mute This Topic: https://lists.yoctoproject.org/mt/75034537/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Quentin Schulz]

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 modifications but instead 
> the altered one.
> 
> Here is what I have done:
> 
> devtool modify 
> 
> This has successfully checked out the sources of the library that I want to 
> modify and I could make my modifications and build the changed version with 
> "devtool build vsomeip" . Now when I build an image with "devtool build-image 
> ", devtool reports that it would build the image with addtional 
> package "vsomeip".
> 
> But the library that ends up in the generated image does not seem to have the 
> modified code. I do not find my additional symbols when I do an objdump on 
> the library in
> 
> ./tmp/work/qemux86-poky-linux//1.0-r0/rootfs/usr/lib/libvsomeip...
> 
> On the other hand, the library built in 
> ./tmp/work/i586-poky-linux/vsomeip/2.10.21-r0/vsomeip-2.10.21/libvsomeip.so.2.10.21
>  does have these symbols.
> 
> The disconnect seems to happen already within the vsomeip library build 
> process. The library present at 
> ./tmp/work/i586-poky-linux/vsomeip/2.10.21-r0/package/usr/lib/libvsomeip.so.2.10.21
>  is one _without_ my changes present (and identical in size to the one on the 
> rootfs folder of the image).
> 
> It feels like I am missing a step of the devtool flow, or at least the 
> starting point to debug the deployment process.
> 
> Any hints of pointers to relevant documentation would be very appreciated!
> 

Libraries and binaries are stripped of the debug symbols before adding
them to the "normal" package. The version with the debug symbols are
usually in the -dbg package of your recipe.

You can disable this behavior with INHIBIT_PACKAGE_STRIP in your recipe (c.f.
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-INHIBIT_PACKAGE_STRIP)

This is Yocto's default behavior, not sure if there is anything specific
to devtool in what you described.

(BTW, until you have run devtool reset , bitbake takes the
 sources from your devtool workspace. I don't know exactly what's the
 difference with bitbake build-image  and bitbake )

Let us know if that helps,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49786): https://lists.yoctoproject.org/g/yocto/message/49786
Mute This Topic: https://lists.yoctoproject.org/mt/75211655/21656
Mute #devtool: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/devtool
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Yocto Project Status WW26'20

[Stephen Jolley]

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 (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday July 14th  at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 3.2 M1 was released.
*   We've updated to a new version of the buildtools tarball for master
and dunfell
*   We continue to be concerned about autobuilder stability, we're
continuing to see high numbers of intermittent failures. You can see the
list of failures we're seeing by searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

Help is urgently needed to bring these to a manageable level.

*   We are struggling with maintainers for some key components of the
system/infrastructure such as devtool, wic, buildhistory and
patchwork/patchtest. If anyone can help in these areas please contact
Richard.
*   If anyone has thoughts on attracting and recognising project
contributors and contributions, we would be interested in ideas and
assistance in that area.
*   It is ELC this week, please stop by the booth and/or ELC
#2-track-yocto-project slack channel and say hi. There are still places
available on our virtual Developer Day:

https://events.linuxfoundation.org/yocto-dev-day-north-america/
*   Another way to help the project is to help us with bugs that are
currently unassigned but ideally needed during 3.2. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhan
cements.2FBugs
*   We're pleased to announce we have a new manual in the Yocto Project
documentation 'bookshelf' which covers the project's testing processes and
infrastructure including the autobuilder and resulttool. A work-in-progress
version of this can be viewed here:

https://www.yoctoproject.org/docs/docs_temp/test-manual/test-manual.html. So
far, it contains basic information in key areas, we're happy to take
feedback on areas that are missing or need more information and/or take
contributions to further extend this work.

 

YP 3.2 Milestone Dates:

*   YP 3.2 M1 is released.
*   YP 3.2 M2 build date 2020/7/27
*   YP 3.2 M2 Release date 2020/8/7
*   YP 3.2 M3 build date 2020/8/31
*   YP 3.2 M3 Release date 2020/9/11
*   YP 3.2 M4 build date 2020/10/5
*   YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

*   YP 3.0.4 build date 2020/8/10
*   YP 3.0.4 release date 2020/8/21
*   YP 3.1.2 build date 2020/9/14
*   YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

*   WDD 2470 (last week 2545) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1272 (last week 1298)
*   Patches in the Pending State: 498 (39%) [last week 518 (40%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49787): https://lists.yoctoproject.org/g/yocto/message/49787
Mute This Topic: https://lists.yoctoproject.org/mt/75214990/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #python

[Khem Raj]

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 PATH, please install them in order to proceed:

   python

But I do have installed python in all possible versions. I don't know 
what to do currently and would appreciate your help a lot. Thanks in 
Advance.




which release of yocto are you on ? secondly which OS is on the host?
you might want to install python2 perhaps on it.


BR



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49788): https://lists.yoctoproject.org/g/yocto/message/49788
Mute This Topic: https://lists.yoctoproject.org/mt/75122080/21656
Mute #yocto: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/yocto
Mute #python: https://lists.yoctoproject.org/g/yocto+yocto/mutehashtag/python
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Ross Burton]

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.json
@@ -273,6 +273,24 @@
 "MACHINE" : "qemuarm64",
 "TEMPLATE" : "ltp-qemu"
 },
+"meta-arm" : {
+"NEEDREPOS" : ["poky", "meta-arm"],
+"ADDLAYER" : [
+"${BUILDDIR}/../meta-arm/meta-arm",
+"${BUILDDIR}/../meta-arm/meta-arm-bsp",
+"${BUILDDIR}/../meta-arm/meta-arm-toolchain"
+],
+"step1": {
+"MACHINE": "n1sdp",
+"BBTARGETS": "core-image-minimal core-image-sato 
core-image-sato:do_populate_sdk",
+"SANITYTARGETS" : "core-image-sato:do_testsdk"
+},
+"step2": {
+"MACHINE": "juno",
+"BBTARGETS": "core-image-minimal core-image-sato 
core-image-sato:do_populate_sdk",
+"SANITYTARGETS" : "core-image-sato:do_testsdk"
+}
+},
"bringup" : {
 "BUILDINFO" : true,
 "SSTATEDIR" : ["SSTATE_DIR ?= '${HELPERBUILDDIR}/sstate'"],
@@ -964,6 +982,12 @@
 "branch" : "master",
 "revision" : "HEAD",
 "no-layer-add" : true
+},
+"meta-arm" : {
+"url" : "git://git.yoctoproject.org/meta-arm",
+"branch" : "master",
+"revision" : "HEAD",
+"no-layer-add" : true
 }
 
 },
-- 
2.24.3 (Apple Git-128)

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49789): https://lists.yoctoproject.org/g/yocto/message/49789
Mute This Topic: https://lists.yoctoproject.org/mt/75217238/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Joshua Watt]

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.0.bb} | 0
 4 files changed, 1 insertion(+), 6 deletions(-)
 rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-headers_6.0.0.bb => 
nativesdk-mingw-w64-headers_7.0.0.bb} (82%)
 rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-runtime_6.0.0.bb => 
nativesdk-mingw-w64-runtime_7.0.0.bb} (100%)
 rename recipes-devtools/mingw-w64/{nativesdk-mingw-w64-winpthreads_6.0.0.bb => 
nativesdk-mingw-w64-winpthreads_7.0.0.bb} (100%)

diff --git a/recipes-devtools/mingw-w64/mingw-w64.inc 
b/recipes-devtools/mingw-w64/mingw-w64.inc
index 8c68bcc..a435dea 100644
--- a/recipes-devtools/mingw-w64/mingw-w64.inc
+++ b/recipes-devtools/mingw-w64/mingw-w64.inc
@@ -5,8 +5,7 @@ COMPATIBLE_HOST = ".*-mingw.*"
 
 SRC_URI = 
"${SOURCEFORGE_MIRROR}/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v${PV}.tar.bz2"
 
-SRC_URI[md5sum] = "cf5673f6d689bb5e02863e6284cc3d03"
-SRC_URI[sha256sum] = 
"805e11101e26d7897fce7d49cbb140d7bac15f3e085a91e0001e80b2adaf48f0"
+SRC_URI[sha256sum] = 
"aa20dfff3596f08a7f427aab74315a6cb80c2b086b4a107ed35af02f9496b628"
 
 UPSTREAM_CHECK_URI = 
"http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/";
 UPSTREAM_CHECK_REGEX = "mingw-w64-v(?P(\d+[\.\-_]*)+)\.tar"
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_6.0.0.bb 
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_7.0.0.bb
similarity index 82%
rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_6.0.0.bb
rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_7.0.0.bb
index 58073d6..292d22b 100644
--- a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_6.0.0.bb
+++ b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-headers_7.0.0.bb
@@ -10,10 +10,6 @@ inherit autotools nativesdk
 INHIBIT_DEFAULT_DEPS = "1"
 DEPENDS = ""
 
-PACKAGECONFIG ??= "secure-api"
-
-PACKAGECONFIG[secure-api] = "--enable-secure-api,--disable-secure-api"
-
 do_configure() {
oe_runconf
 }
diff --git a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_6.0.0.bb 
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
similarity index 100%
rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_6.0.0.bb
rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-runtime_7.0.0.bb
diff --git 
a/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_6.0.0.bb 
b/recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_7.0.0.bb
similarity index 100%
rename from recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_6.0.0.bb
rename to recipes-devtools/mingw-w64/nativesdk-mingw-w64-winpthreads_7.0.0.bb
-- 
2.27.0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49790): https://lists.yoctoproject.org/g/yocto/message/49790
Mute This Topic: https://lists.yoctoproject.org/mt/75223283/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Khem Raj]

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/work/core2-64-poky-linux/openjdk-
8/252-r0=/usr/src/debug/openjdk-8/252-r0’

This seems to imply I need a newer gcc which supports the -fmacro-prefix-
map option. The README says I need gcc 6 or later on the host, but 18.04
has gcc 7.5.0. Maybe the README is outdated?

I then tried building in an Ubuntu 20.04 container to see if that makes
any difference. It fails in a different way while building icedtea7-
native:

| /usr/include/x86_64-linux-gnu/bits/stdio2.h:100:24: error: ‘%s’
directive argument is null [-Werror=format-overflow=]


I guess compiler on your host is too new for openjdk-8, perhaps you 
might get through by disabling Werror option to host cflags. You might 
have to dig the appropriate place to stick the option in.




I'm doing clean builds with both my 18.04 and 20.04 setups starting with
separate, empty sstate-cache directories. Both builds are using poky
defaults:

Build Configuration:
BB_VERSION   = "1.46.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "qemux86-64"
DISTRO   = "poky"
DISTRO_VERSION   = "3.1.1"
TUNE_FEATURES= "m64 core2"
TARGET_FPU   = ""
meta
meta-poky
meta-yocto-bsp   = "dunfell:93ef4736915090ac9a2402916df8924ac4439490"
meta-oe  = "dunfell:8a72d29e0876830ffd96b85d7d0308302eb07a5d"
meta-java= "dunfell:cf9604a4789801d9dfb0cb8ca134ff04b42ae161"

Is there some trick I'm missing to get clean builds out of the box? I can
fix the 20.04 build by adding -Wno-error for that specific warning (and
can send a patch if desired), but has anyone else had these issues? Any
thoughts would be appreciated.

Thanks,
Robert




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49791): https://lists.yoctoproject.org/g/yocto/message/49791
Mute This Topic: https://lists.yoctoproject.org/mt/75208574/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Khem Raj]

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 and LGPL-3.0).

Currently we're based on Warrior, but I also did a short test on master
(results later in the message)

Our images use systemd as init system. We use busybox ash as shell on
these images for now.

When setting the INCOMPATIBLE_LICENSE according to the manual example,
systemd cannot be built anymore because bash is being skipped due to
license.

Turns out that because systemd-bash-completion and
systemd-kernel-install both rdepend on bash, we can't build systemd at
all, because bash is not buildable. Even if we're not installing those
features of systemd.

A dive into TaskData suggests that all the rdepends of all packages
provided by a recipe are flattened into depends of the recipe when
testing buildability.

A quick test on master from about 2 weeks ago show the same behavior.

For the test on master all I did was change the DISTRO_FEATURES of
core-image-minimal to include systemd.


Am I using ICOMPATIBLE_LICENSE properly so far?
If so, is being unable to fulfill an rdepend for an unused package meant
to fail the whole build, and how can I avoid it short of including
meta-gplv2 or writing lots of .bbappends to remove the dependencies?
Otherwise, where did I go wrong, and what should I be trying instead?


You need to add exceptions to build a lot GPLv3 components but not let them
be part of product images.

In distro config:

INCOMPATIBLE_LICENSE += "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
...
WHITELIST_GPL-3.0 += "bash"
PACKAGE_EXCLUDE += "bash-ptest bash-dbg bash-staticdev bash-dev bash-doc bash-locale 
bashbug bash"
...

The PACKAGE_EXCLUDE must be complete list of binary packages produced by the 
recipe.




I think having two different distro configs is a reliable approach here, 
we keep adding more refined packaging which means you have to be on your 
toes all the time in the allowed list above.



I end up enabling a large set of GPLv3 tools for use as development tooling at 
build
time or in SDK:

$ grep WHITELIST_ distro.conf
WHITELIST_GPL-3.0 += "autoconf"
WHITELIST_GPL-3.0 += "bash"
WHITELIST_GPL-3.0 += "bc"
WHITELIST_GPL-3.0 += "binutils"
WHITELIST_GPL-3.0 += "bison"
WHITELIST_GPL-3.0 += "ccache"
WHITELIST_GPL-3.0 += "coreutils"
WHITELIST_GPL-3.0 += "diffutils"
WHITELIST_GPL-3.0 += "elfutils"
WHITELIST_GPL-3.0 += "findutils"
WHITELIST_GPL-3.0 += "gawk"
WHITELIST_GPL-3.0 += "gdb"
WHITELIST_GPL-3.0 += "gdbm"
WHITELIST_GPL-3.0 += "gettext"
WHITELIST_GPL-3.0 += "gnutls"
WHITELIST_GPL-3.0 += "grep"
WHITELIST_GPL-3.0 += "libevent"
WHITELIST_GPL-3.0 += "libpipeline"
WHITELIST_GPL-3.0 += "libunistring"
WHITELIST_GPL-3.0 += "m4"
WHITELIST_GPL-3.0 += "make"
WHITELIST_GPL-3.0 += "readline"
WHITELIST_GPL-3.0 += "rsync"
WHITELIST_GPL-3.0 += "sed"
WHITELIST_GPL-3.0 += "which"

If one does not do this, alternative is to use a bunch of old and deprecated 
tool
versions from meta-gplv2.

Hope this helps,

-Mikko




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49792): https://lists.yoctoproject.org/g/yocto/message/49792
Mute This Topic: https://lists.yoctoproject.org/mt/75210517/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Dunfell 3.1.1 gcc-sanitizers build failure

[MikeB]

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-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
 No such file or directory
| WARNING: 
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of 
'/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505'
 failed with exit code 1:
| cat: 
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
 No such file or directory
| WARNING: 
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
 exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'

At first, I thought this may be a dependency issue because I inherit "rm_work" 
to tidy up; but I tried a build without it - i.e. keeping all work around - and 
got the same failure.

I've attached the full error log.  Any troubleshooting advice would be 
appreciated.


log.do_configure.31505
Description: Binary data
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49793): https://lists.yoctoproject.org/g/yocto/message/49793
Mute This Topic: https://lists.yoctoproject.org/mt/75223575/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Stephen Jolley]

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


mark.mor...@windriver.com

9


bluelightn...@bluelightning.org

7


r...@burtonini.com

7


richard.pur...@linuxfoundation.org

6


qi.c...@windriver.com

5


mich...@yoctoproject.org

5


jon.ma...@arm.com

3


yi.z...@windriver.com

3


raj.k...@gmail.com

3


rpj...@crashcourse.ca

3


trevor.gamb...@windriver.com

2


alejan...@enedino.org

2


ycnakaj...@gmail.com

2


kai.k...@windriver.com

2


sakib.sa...@windriver.com

2


dl...@gmx.de

2


mark.ha...@kernel.crashing.org

2


randy.macl...@windriver.com

2


mostthings...@gmail.com

2


timothy.t.orl...@intel.com

2


jpewhac...@gmail.com

2


chee.yang@intel.com

2


kerg...@gmail.com

2


jae...@xilinx.com

2


matthew.z...@windriver.com

1


bruce.ashfi...@gmail.com

1


hongxu@windriver.com

1


martin.ja...@gmail.com

1


maxime.roussinbelan...@gmail.com

1


b...@stusta.de

1


naveen.kumar.sa...@intel.com

1


kai.ruh...@live.com

1


liu.min...@gmail.com

1


limon.ani...@gmail.com

1


de...@denix.org

1


jpuhl...@mvista.com

1


changqing...@windriver.com

1


Grand Total

102

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49794): https://lists.yoctoproject.org/g/yocto/message/49794
Mute This Topic: https://lists.yoctoproject.org/mt/75225066/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Stephen Jolley]

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#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 342
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "3.1", "3.2, "3.99" and "Future", the more pressing/urgent issues
being in "3.1" and then "3.2".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49795): https://lists.yoctoproject.org/g/yocto/message/49795
Mute This Topic: https://lists.yoctoproject.org/mt/75225071/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Khem Raj]

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-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: 
No such file or directory
| WARNING: 
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 
exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
| ERROR: Execution of 
'/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505' 
failed with exit code 1:
| cat: 
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h: 
No such file or directory
| WARNING: 
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1 
exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
At first, I thought this may be a dependency issue because I inherit 
"rm_work" to tidy up; but I tried a build without it - i.e. keeping all 
work around - and got the same failure.


I've attached the full error log.  Any troubleshooting advice would be 
appreciated.


try to do a bitbake -ccleansstate on gcc-source-9.3.0





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49796): https://lists.yoctoproject.org/g/yocto/message/49796
Mute This Topic: https://lists.yoctoproject.org/mt/75223575/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Enhancements/Bugs closed WW26!

[Stephen Jolley]

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...@bluelightning.org

1


jpuhl...@mvista.com

1


ricardo.riba...@gmail.com

1


Grand Total

36

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49797): https://lists.yoctoproject.org/g/yocto/message/49797
Mute This Topic: https://lists.yoctoproject.org/mt/75225191/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Joshua Watt]

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: 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
>  No such file or directory
> | WARNING: 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
>  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> | ERROR: Execution of 
> '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505'
>  failed with exit code 1:
> | cat: 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
>  No such file or directory
> | WARNING: 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
>  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
>
> At first, I thought this may be a dependency issue because I inherit 
> "rm_work" to tidy up; but I tried a build without it - i.e. keeping all work 
> around - and got the same failure.

I've encountered a similar error just today when switching SDKMACHINE.
Are you using archive.bbclass by any chance (INHERIT += "archive")? I
just recently fixed a bug in archive.bbclass
(7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
gcc-source raced with do_preconfigure and I'm wondering if it's
related

>
> I've attached the full error log.  Any troubleshooting advice would be 
> appreciated. 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49800): https://lists.yoctoproject.org/g/yocto/message/49800
Mute This Topic: https://lists.yoctoproject.org/mt/75223575/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Joshua Watt]

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 gcc-sanitizers as I'm trying to build the SDK.
> >
> > | cat: 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
> >  No such file or directory
> > | WARNING: 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
> >  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > | ERROR: Execution of 
> > '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505'
> >  failed with exit code 1:
> > | cat: 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
> >  No such file or directory
> > | WARNING: 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
> >  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> >
> > At first, I thought this may be a dependency issue because I inherit 
> > "rm_work" to tidy up; but I tried a build without it - i.e. keeping all 
> > work around - and got the same failure.
>
> I've encountered a similar error just today when switching SDKMACHINE.
> Are you using archive.bbclass by any chance (INHERIT += "archive")? I
> just recently fixed a bug in archive.bbclass
> (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
> gcc-source raced with do_preconfigure and I'm wondering if it's
> related

I believe I have fixed this in
https://lists.openembedded.org/g/openembedded-core/message/140161,
please try it out to make sure it solves your issue as well.

>
> >
> > I've attached the full error log.  Any troubleshooting advice would be 
> > appreciated. 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49801): https://lists.yoctoproject.org/g/yocto/message/49801
Mute This Topic: https://lists.yoctoproject.org/mt/75223575/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Steve Sakoman]

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 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-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
> > >  No such file or directory
> > > | WARNING: 
> > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
> > >  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > | ERROR: Execution of 
> > > '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505'
> > >  failed with exit code 1:
> > > | cat: 
> > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
> > >  No such file or directory
> > > | WARNING: 
> > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
> > >  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > >
> > > At first, I thought this may be a dependency issue because I inherit 
> > > "rm_work" to tidy up; but I tried a build without it - i.e. keeping all 
> > > work around - and got the same failure.
> >
> > I've encountered a similar error just today when switching SDKMACHINE.
> > Are you using archive.bbclass by any chance (INHERIT += "archive")? I
> > just recently fixed a bug in archive.bbclass
> > (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
> > gcc-source raced with do_preconfigure and I'm wondering if it's
> > related
>
> I believe I have fixed this in
> https://lists.openembedded.org/g/openembedded-core/message/140161,
> please try it out to make sure it solves your issue as well.

That patch came in after the 3.1.1 release, but it is present in the
dunfell branch so it will make it into 3.1.2

Steve
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49802): https://lists.yoctoproject.org/g/yocto/message/49802
Mute This Topic: https://lists.yoctoproject.org/mt/75223575/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Steve Sakoman]

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 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-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
> > > >  No such file or directory
> > > > | WARNING: 
> > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
> > > >  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > > | ERROR: Execution of 
> > > > '/data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505'
> > > >  failed with exit code 1:
> > > > | cat: 
> > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work-shared/gcc-9.3.0-r0/gcc-9.3.0/gcc/defaults.h:
> > > >  No such file or directory
> > > > | WARNING: 
> > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/temp/run.do_configure.31505:1
> > > >  exit 1 from 'grep -v "\#endif.*GCC_DEFAULTS_H" > 
> > > > /data/mabnhdev/exos-yocto-dunfell/build/exos-arm64/tmp/work/aarch64-poky-linux/gcc-sanitizers/9.3.0-r0/gcc-9.3.0/build.aarch64-poky-linux.aarch64-poky-linux/gcc/defaults.h.new'
> > > >
> > > > At first, I thought this may be a dependency issue because I inherit 
> > > > "rm_work" to tidy up; but I tried a build without it - i.e. keeping all 
> > > > work around - and got the same failure.
> > >
> > > I've encountered a similar error just today when switching SDKMACHINE.
> > > Are you using archive.bbclass by any chance (INHERIT += "archive")? I
> > > just recently fixed a bug in archive.bbclass
> > > (7a57e777597d7f66d065582cfb83cd8f9468f4af) where the archiving of
> > > gcc-source raced with do_preconfigure and I'm wondering if it's
> > > related
> >
> > I believe I have fixed this in
> > https://lists.openembedded.org/g/openembedded-core/message/140161,
> > please try it out to make sure it solves your issue as well.
>
> That patch came in after the 3.1.1 release, but it is present in the
> dunfell branch so it will make it into 3.1.2

Doh, I'm getting ahead of myself! I was thinking of another
classes/archiver patch that Joshua sent :-)

Steve
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49803): https://lists.yoctoproject.org/g/yocto/message/49803
Mute This Topic: https://lists.yoctoproject.org/mt/75223575/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-