from:"Douglas via lists.openembedded.org"

Re: [OE-core] [PATCH 1/1] sanity.bbclass: Update required gcc version to v7.5

2021-11-01 Thread Douglas via lists.openembedded.org


On 2/11/21 4:18 am, Khem Raj wrote:
On Mon, Nov 1, 2021 at 8:05 AM Robert Yang  
wrote:


qemu-native 6.1.0 requires at least gcc v7.5:
ERROR: You need at least GCC v7.5 or Clang v6.0 (or XCode Clang v10.0)


Which supported distros still ship gcc < 7.5



Ubuntu 18.04 is on gcc 7.4

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157735): 
https://lists.openembedded.org/g/openembedded-core/message/157735
Mute This Topic: https://lists.openembedded.org/mt/86742639/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] externalsrc.bbclass: Allow externalsrc to be extended with extra classes

2021-10-20 Thread Douglas via lists.openembedded.org


We do "wrap" classes in our own proprietary layer.

In a layer called meta-abc, we name the wrapper-class 
classname-abc.bbclass. For instance, we wrap cmake.bbclass as follows:


   # cmake-abc.bbclass

   inherit cmake

   # Additions to cmake behaviour go here
   ...

Our meta-abc recipes inherit cmake-abc. In this way, the wrapper-class 
behaves very much like a bbappend.



On 20/10/21 10:09 pm, Peter Kjellerstedt wrote:


I thought of another problem with the wrapper class solution: if we 
need to actually backport a newer version of the class from, e.g., 
Poky master, then there is now no natural place for it since it is 
occupied by the wrapper class. That means we would either have to 
rename the backported class, or put it somewhere else than in 
“classes”. It also means backporting a class requires the wrapper 
class to be modified.


Here is a question for Richard: what do you think of an idea I had to 
add support in bitbake for extending classes? I do not mean to add 
something like bbclassappend, as I know that is troublesome. My idea 
instead is something like the prefuncs/postfuncs that we have for 
functions. I.e., before actually doing the inherit of a class foo, 
bitbake would inherit anything specified in BBCLASS_PRE_INHERIT:foo, 
and after inheriting the class it would automatically inherit anything 
in BBCLASS_POST_INHERIT:foo.  That way one can simply extend a class 
through normal variable operations, making it easy to do, e.g., in the 
distro configuration.


//Peter

*From:*openembedded-core@lists.openembedded.org 
 *On Behalf Of *Peter 
Kjellerstedt

*Sent:* den 20 oktober 2021 03:32
*To:* Jose Quaresma 
*Cc:* OE-core 
*Subject:* Re: [OE-core] [PATCH] externalsrc.bbclass: Allow 
externalsrc to be extended with extra classes


Well, I had not considered that option. I can’t say I am to keen on 
having wrapper classes with the same name as the upstream classes as I 
think it leads to confusion. And the solution doesn’t scale very well 
(what if two layers want to override the same class?). But on the 
positive side it works for any class without requiring changes to 
OE-Core. And I guess the latter wins. I wish there was a more bitbakey 
way to add to classes though (bbclassappend anyone? 😉).


//Peter

*From:*Jose Quaresma 
*Sent:* den 19 oktober 2021 19:15
*To:* Peter Kjellerstedt 
*Cc:* OE-core 
*Subject:* Re: [OE-core] [PATCH] externalsrc.bbclass: Allow 
externalsrc to be extended with extra classes


Hi Peter,

require the class on the new one will do the same

and we don't need any changes for that

but I may not be seeing everything

require ${COREBASE}/meta/classes/externalsrc.bbclass

Jose

Peter Kjellerstedt  escreveu no dia 
terça, 19/10/2021 à(s) 18:03:


The EXTERNALSRC_EXTENSIONS variable holds a list of additional classes
that will be inherited when externalsrc is inherited.

Signed-off-by: Peter Kjellerstedt 
---

We have had a local copy of this class for a long time since we need
to make it suppport a local class when checking BBCLASSEXTEND. And
now we wanted to add some more functionality that should be active
when externalsrc is in use. So instead of forking the class even
more, I thought it would be better to make the upstream class
extendable. The solution was inspired by USERADDEXTENSION in
useradd.bbclass.

 meta/classes/externalsrc.bbclass | 5 +
 meta/conf/documentation.conf     | 1 +
 2 files changed, 6 insertions(+)

diff --git a/meta/classes/externalsrc.bbclass
b/meta/classes/externalsrc.bbclass
index abfe24bace..488d75760f 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -265,3 +265,8 @@ def srctree_configure_hash_files(d):
     return ' '.join(out_items)

 EXPORT_FUNCTIONS do_buildclean
+
+# Use the following to extend externalsrc with custom functionality
+EXTERNALSRC_EXTENSIONS ??= ""
+
+inherit ${EXTERNALSRC_EXTENSIONS}
diff --git a/meta/conf/documentation.conf
b/meta/conf/documentation.conf
index 80ad8e10d5..6d5b734b02 100644
--- a/meta/conf/documentation.conf
+++ b/meta/conf/documentation.conf
@@ -160,6 +160,7 @@ EXTENDPE[doc] = "Used with file and pathnames
to create a prefix for a recipe's
 EXTENDPKGV[doc] = "The full package version specification as it
appears on the final packages produced by a recipe."
 EXTERNALSRC[doc] = "If externalsrc.bbclass is inherited, this
variable points to the source tree, which is outside of the
OpenEmbedded build system."
 EXTERNALSRC_BUILD[doc] = "If externalsrc.bbclass is inherited,
this variable points to the directory in which the recipe's source
code is built, which is outside of the OpenEmbedded build system."
+EXTERNALSRC_EXTENSIONS[doc] = "A list of additional classes that
will be inherited when externalsrc is inherited."
 EXTRA_IMAGE_FEATURES[doc] = "The list of additional features to

Re: [OE-core][PATCH v2 1/2] reproducible_build: Remove BUILD_REPRODUCIBLE_BINARIES checking

2021-09-09 Thread Douglas via lists.openembedded.org


On 10/09/21 1:29 pm, Mark Hatle wrote:

From: Mark Hatle 

Previously if BUILD_REPRODUCIBLE_BINARIES was set to 0, the system would
fall back and select the default epoch (April 2011), but still perform
the reproducible build actions.  This resulted in binaries that had an
unusually old date.

Simplify the functions and remove the anonymous python as no longer
necessary.

Also improve the documentation to better explain what the class is doing
and how a recipe can override the behavior if necessary.

Signed-off-by: Mark Hatle 
Signed-off-by: Mark Hatle 
---
  meta/classes/reproducible_build.bbclass | 53 -
  1 file changed, 34 insertions(+), 19 deletions(-)

diff --git a/meta/classes/reproducible_build.bbclass 
b/meta/classes/reproducible_build.bbclass
index 378121903d..96bb012243 100644
--- a/meta/classes/reproducible_build.bbclass
+++ b/meta/classes/reproducible_build.bbclass
@@ -1,17 +1,38 @@
  # reproducible_build.bbclass
  #
-# Sets SOURCE_DATE_EPOCH in each component's build environment.
+# Sets the default SOURCE_DATE_EPOCH in each component's build environment.
+# The format is number of seconds since the system epoch.
+#
  # Upstream components (generally) respect this environment variable,
  # using it in place of the "current" date and time.
  # See https://reproducible-builds.org/specs/source-date-epoch/
  #
-# After sources are unpacked but before they are patched, we set a 
reproducible value for SOURCE_DATE_EPOCH.
-# This value should be reproducible for anyone who builds the same revision 
from the same sources.
+# The default value of SOURCE_DATE_EPOCH comes from the function
+# get_source_date_epoch_value which reads from the SDE_FILE, or if the file
+# is not available (or set to 0) will use the fallback of
+# SOURCE_DATE_EPOCH_FALLBACK.
+#
+# The SDE_FILE is normally constructed from the function
+# create_source_date_epoch_stamp which is typically added as a postfuncs to
+# the do_unpack task.  If a recipe does NOT have do_unpack, it should be added
+# to a task that runs after the source is available and before the
+# do_deploy_source_date_epoch task is executed.
+#
+# If a recipe wishes to override the default behavior it should set it's own
+# SOURCE_DATE_EPOCH or override the do_deploy_source_date_epoch_stamp task
+# with recipe-specific functionality to write the appropriate
+# SOURCE_DATE_EPOCH into the SDE_FILE.
+#
+# SOURCE_DATE_EPOCH is intended to be a reproducible value.  This value should
+# be reproducible for anyone who builds the same revision from the same
+# sources.
  #
-# There are 4 ways we determine SOURCE_DATE_EPOCH:
+# There are 4 ways the create_source_date_epoch_stamp function determines what
+# becomes SOURCE_DATE_EPOCH:
  #
  # 1. Use the value from __source_date_epoch.txt file if this file exists.
-#This file was most likely created in the previous build by one of the 
following methods 2,3,4.
+#This file was most likely created in the previous build by one of the
+#following methods 2,3,4.
  #Alternatively, it can be provided by a recipe via SRC_URI.
  #
  # If the file does not exist:
@@ -22,20 +43,16 @@
  # 3. Use the mtime of "known" files such as NEWS, CHANGLELOG, ...
  #This works for well-kept repositories distributed via tarball.
  #
-# 4. Use the modification time of the youngest file in the source tree, if 
there is one.
+# 4. Use the modification time of the youngest file in the source tree, if
+#there is one.
  #This will be the newest file from the distribution tarball, if any.
  #
-# 5. Fall back to a fixed timestamp.
+# 5. Fall back to a fixed timestamp (SOURCE_DATE_EPOCH_FALLBACK).
  #
-# Once the value of SOURCE_DATE_EPOCH is determined, it is stored in the 
recipe's SDE_FILE.
-# If none of these mechanisms are suitable, replace the 
do_deploy_source_date_epoch task
-# with recipe-specific functionality to write the appropriate 
SOURCE_DATE_EPOCH into the SDE_FILE.
-#
-# If this file is found by other tasks, the value is exported in the 
SOURCE_DATE_EPOCH variable.
-# SOURCE_DATE_EPOCH is set for all tasks that might use it (do_configure, 
do_compile, do_package, ...)
+# Once the value is determined, it is stored in the recipe's SDE_FILE.
  
  BUILD_REPRODUCIBLE_BINARIES ??= '1'

-inherit ${@oe.utils.ifelse(d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1', 
'reproducible_build_simple', '')}
+inherit reproducible_build_simple
  
  SDE_DIR = "${WORKDIR}/source-date-epoch"

  SDE_FILE = "${SDE_DIR}/__source_date_epoch.txt"
@@ -92,6 +109,9 @@ python create_source_date_epoch_stamp() {
  os.rename(tmp_file, epochfile)
  }
  
+# Generate the stamp after do_unpack runs

+do_unpack[postfuncs] += "create_source_date_epoch_stamp"
+
  def get_source_date_epoch_value(d):
  cached = d.getVar('__CACHED_SOURCE_DATE_EPOCH')
  if cached:
@@ -120,8 +140,3 @@ def get_source_date_epoch_value(d):
  
  export SOURCE_DATE_EPOCH ?= "${@get_source_date_epoch_value(d)}"

  BB_HASHBASE_WHITELIST += "SOURCE_D

Re: [OE-core][PATCH 2/2] reproducible_build: Work with externalsrc

2021-09-09 Thread Douglas via lists.openembedded.org


On 10/09/21 1:05 pm, Mark Hatle wrote:

Unfortunately I'm having problems sending email to the list currently.  But I
can reply directly (feels free to forward this to the list).

On 9/9/21 7:32 PM, Douglas Royds wrote:

On 9/09/21 2:51 pm, Mark Hatle wrote:

From: Mark Hatle 

Externalsrc removes do_fetch, do_unpack, and do_patch.  The system normally
discovers the correct reproducible date as a postfuncs on do_unpack, so this
date is never found, so it goes back to the default epoch.

Instead we can move the discovery function to a prefuncs on the epoch
deploy task.  This task will run before do_configure, and since the source
is already available can run anytime safely.

Signed-off-by: Mark Hatle 
Signed-off-by: Mark Hatle 
---
  meta/classes/reproducible_build.bbclass | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/classes/reproducible_build.bbclass 
b/meta/classes/reproducible_build.bbclass
index a9c117c3b9..ae0723ab21 100644
--- a/meta/classes/reproducible_build.bbclass
+++ b/meta/classes/reproducible_build.bbclass
@@ -128,7 +128,13 @@ BB_HASHBASE_WHITELIST += "SOURCE_DATE_EPOCH"
  python () {
  if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1':
  # Generate the timestamp with create_source_date_epoch_stamp.
-d.appendVarFlag("do_unpack", "postfuncs", " 
create_source_date_epoch_stamp")
+# In most cases this will be a postfuncs of do_unpack.
+# If we're running in external source, add 
create_source_date_epoch_stamp
+# to do_deploy_source_date_epoch instead because there is no do_unpack.
+if d.getVar('EXTERNALSRC') and bb.data.inherits_class('externalsrc', 
d):
+d.appendVarFlag('do_deploy_source_date_epoch', 'prefuncs', ' 
create_source_date_epoch_stamp')
+else:
+d.appendVarFlag("do_unpack", "postfuncs", " 
create_source_date_epoch_stamp")
  d.appendVar('SSTATETASKS', " do_deploy_source_date_epoch")
  bb.build.addtask('do_deploy_source_date_epoch_setscene', None, None, 
d)
  bb.build.addtask('do_deploy_source_date_epoch', 'do_configure', 
'do_patch', d)


Why was create_source_date_epoch_stamp ever added as a do_unpack postfunc in the
first place? Why wasn't it invoked directly from do_deploy_source_date_epoch all
along? This task runs after do_patch and before do_configure anyway. What am I
missing? Are you there, Juro?

It was put in that place to ensure it was based on the original upstream source,
and not the patched source.  As the act of patching the source may change the
dates based on the behavior of patch, filesystem, etc.

So really we do want the date/time from the do_unpack, and before do_patch (or
any random tasks added between do_unpack and do_patch run.)



True. Good point.



If we create_source_date_epoch_stamp (either as a do_deploy_source_date_epoch
prefunc or directly invoked), then it should work either way, for externalsrc or
not.

I've got a new set of patches coming shortly.  (I can send patches, but can't
reply to the list currently.  I've got a configuration problem on my ISP side
which will hopefully be fixed tomorrow.)


As an aside, perhaps do_deploy_source_date_epoch should come after do_unpack as
well, just in case someone has deleted do_patch:

 addtask do_deploy_source_date_epoch before do_configure after do_unpack 
do_patch


The new set will keep things as is, removing the confusing
BUILD_REPRODUCIBLE_BINARIES switching in this class, while moving the special
behavior to the externalsrc class.  So if we remove the do_unpack, we'll move
the function to the prefuncs of the do_deploy_source_date_epoch.



Nice.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155875): 
https://lists.openembedded.org/g/openembedded-core/message/155875
Mute This Topic: https://lists.openembedded.org/mt/85476714/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH 2/2] reproducible_build: Work with externalsrc

2021-09-09 Thread Douglas via lists.openembedded.org


On 9/09/21 2:51 pm, Mark Hatle wrote:

From: Mark Hatle 

Externalsrc removes do_fetch, do_unpack, and do_patch.  The system normally
discovers the correct reproducible date as a postfuncs on do_unpack, so this
date is never found, so it goes back to the default epoch.

Instead we can move the discovery function to a prefuncs on the epoch
deploy task.  This task will run before do_configure, and since the source
is already available can run anytime safely.

Signed-off-by: Mark Hatle 
Signed-off-by: Mark Hatle 
---
  meta/classes/reproducible_build.bbclass | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/classes/reproducible_build.bbclass 
b/meta/classes/reproducible_build.bbclass
index a9c117c3b9..ae0723ab21 100644
--- a/meta/classes/reproducible_build.bbclass
+++ b/meta/classes/reproducible_build.bbclass
@@ -128,7 +128,13 @@ BB_HASHBASE_WHITELIST += "SOURCE_DATE_EPOCH"
  python () {
  if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1':
  # Generate the timestamp with create_source_date_epoch_stamp.
-d.appendVarFlag("do_unpack", "postfuncs", " 
create_source_date_epoch_stamp")
+# In most cases this will be a postfuncs of do_unpack.
+# If we're running in external source, add 
create_source_date_epoch_stamp
+# to do_deploy_source_date_epoch instead because there is no do_unpack.
+if d.getVar('EXTERNALSRC') and bb.data.inherits_class('externalsrc', 
d):
+d.appendVarFlag('do_deploy_source_date_epoch', 'prefuncs', ' 
create_source_date_epoch_stamp')
+else:
+d.appendVarFlag("do_unpack", "postfuncs", " 
create_source_date_epoch_stamp")
  d.appendVar('SSTATETASKS', " do_deploy_source_date_epoch")
  bb.build.addtask('do_deploy_source_date_epoch_setscene', None, None, 
d)
  bb.build.addtask('do_deploy_source_date_epoch', 'do_configure', 
'do_patch', d)



Why was create_source_date_epoch_stamp ever added as a do_unpack 
postfunc in the first place? Why wasn't it invoked directly from 
do_deploy_source_date_epoch all along? This task runs after do_patch and 
before do_configure anyway. What am I missing? Are you there, Juro?


If we create_source_date_epoch_stamp (either as a 
do_deploy_source_date_epoch prefunc or directly invoked), then it should 
work either way, for externalsrc or not.


As an aside, perhaps do_deploy_source_date_epoch should come after 
do_unpack as well, just in case someone has deleted do_patch:


   addtask do_deploy_source_date_epoch before do_configure after
   do_unpack do_patch


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155874): 
https://lists.openembedded.org/g/openembedded-core/message/155874
Mute This Topic: https://lists.openembedded.org/mt/85476714/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH 1/2] reproducible_build: Honor BUILD_REPRODUCIBLE_BINARIES

2021-09-09 Thread Douglas via lists.openembedded.org


On 9/09/21 10:18 pm, Richard Purdie wrote:


On Wed, 2021-09-08 at 21:50 -0500, Mark Hatle wrote:

From: Mark Hatle 

A variable BUILD_REPRODUCIBLE_BINARIES is set to '1' by default and was used
to control if the postfuncs were added.  However, it didn't actually disable
the reproducible_build (date) logic.  This resulted in the program falling
back to the default date.

This change fully honors the variable and disables the various pieces
that discover and configure the SOURCE_DATE_EPOCH if the value if not
set to '1'.

Signed-off-by: Mark Hatle 
Signed-off-by: Mark Hatle 
---
  meta/classes/reproducible_build.bbclass | 17 ++---
  1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/meta/classes/reproducible_build.bbclass 
b/meta/classes/reproducible_build.bbclass
index 378121903d..a9c117c3b9 100644
--- a/meta/classes/reproducible_build.bbclass
+++ b/meta/classes/reproducible_build.bbclass
@@ -47,7 +47,9 @@ TARGET_CC_ARCH:append:class-target = " -Wdate-time"
  # A SOURCE_DATE_EPOCH of '0' might be misinterpreted as no SDE
  export SOURCE_DATE_EPOCH_FALLBACK ??= "1302044400"
  
-SSTATETASKS += "do_deploy_source_date_epoch"

+# The following are preformed in the anonymous python function, only if
+# BUILD_REPRODUCIBLE_BINARIES == 1
+#SSTATETASKS += "do_deploy_source_date_epoch"
  
  do_deploy_source_date_epoch () {

  mkdir -p ${SDE_DEPLOYDIR}
@@ -73,8 +75,10 @@ python do_deploy_source_date_epoch_setscene () {
  
  do_deploy_source_date_epoch[dirs] = "${SDE_DEPLOYDIR}"

  do_deploy_source_date_epoch[sstate-plaindirs] = "${SDE_DEPLOYDIR}"
-addtask do_deploy_source_date_epoch_setscene
-addtask do_deploy_source_date_epoch before do_configure after do_patch
+# The following are preformed in the anonymous python function, only if
+# BUILD_REPRODUCIBLE_BINARIES == 1
+#addtask do_deploy_source_date_epoch_setscene
+#addtask do_deploy_source_date_epoch before do_configure after do_patch
  
  python create_source_date_epoch_stamp() {

  import oe.reproducible
@@ -123,5 +127,12 @@ BB_HASHBASE_WHITELIST += "SOURCE_DATE_EPOCH"
  
  python () {

  if d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1':
+# Generate the timestamp with create_source_date_epoch_stamp.
  d.appendVarFlag("do_unpack", "postfuncs", " 
create_source_date_epoch_stamp")
+d.appendVar('SSTATETASKS', " do_deploy_source_date_epoch")
+bb.build.addtask('do_deploy_source_date_epoch_setscene', None, None, d)
+bb.build.addtask('do_deploy_source_date_epoch', 'do_configure', 
'do_patch', d)
+else:
+# If this is set at all, the system components will attempt to use it
+d.delVar('SOURCE_DATE_EPOCH')
  }

Doing this makes me rather sad. Why? If we keep going down this route, all our
code will just become a mess of python rather than metadata.

A better question here is probably whether we can keep the tasks but correctly
disable changing of the date instead?

I really don't want to just pile up anonymous python.

FWIW I'm also leaning towards moving some of the reproducible code into the main
classes/tasks out the box as I'm not sure we're that interested in having non-
reproducible builds.



The do_deploy_source_date_epoch task is pretty cheap. You're going to 
some trouble here to turn it off, when it only applies to a distro that 
has chosen to inherit reproducible_build in the first place.


I've always been a bit puzzled by the intention of 
BUILD_REPRODUCIBLE_BINARIES, given that it's a distro choice to inherit 
reproducible_build at all. Perhaps the original intention was to avoid 
the get_source_date_epoch() python functionality in the special case of 
a problematic recipe? Are you there, Juro? Can you cast any light on this?


If you really, really do need to turn off the SOURCE_DATE_EPOCH 
variable, perhaps a cleaner approach would be to set it only from within 
the python anonymous function (rather than deleting it in the negative 
case). In this way, this entire patch could perhaps be reduced to one 
line. Note that SOURCE_DATE_EPOCH is already exported by 
reproducible_build_simple.bbclass — which is already inherited only if 
BUILD_REPRODUCIBLE_BINARIES == 1.


I think this all achieves your aim: If your distro inherits 
reproducible_build, but you turn off BUILD_REPRODUCIBLE_BINARIES for one 
recipe (or in your local.conf), the SOURCE_DATE_EPOCH won't be set.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#155873): 
https://lists.openembedded.org/g/openembedded-core/message/155873
Mute This Topic: https://lists.openembedded.org/mt/85476713/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v2] license_image: Use sstate to populate license directory

2021-07-27 Thread Douglas via lists.openembedded.org

On Sat, 3 Jul 2021 at 00:35, Alexandre Belloni
 wrote:
> On 02/07/2021 09:44:37+1200, Douglas via lists.openembedded.org wrote:
> > We were getting an endlessly-growing list of directories in
> > build/tmp/deploy/licenses/ of the form myimage-mymachine-20210629010203.
> > Use the normal sstate behaviour to clean them. Brings license_image in
> > line with the do_populate_lic behaviour in license.bbclass.
> >
> > We must only clean the (new) WORKDIR/license-destdir at do_rootfs time,
> > as the write_package_manifest and license_create_manifest rootfs
> > postprocess commands write the package.manifest and license.manifest
> > files at that time. They get stored in the sstate cache at
> > do_populate_lic_deploy time, alongside the image_license.manifest.
> >
> > Looks like this:
> >
> > license-destdir/
> > ├── myimage-mymachine -> myimage-mymachine-20210629025723/
> > └── myimage-mymachine-20210629025723/
> > ├── image_license.manifest
> > ├── license.manifest
> > └── package.manifest
> >
>
> This ran on the autobuilders and I do believe it is the cause of the
> following failures:
>
> https://autobuilder.yoctoproject.org/typhoon/#builders/79/builds/2269/steps/14/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#builders/86/builds/2247/steps/14/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#builders/87/builds/2282/steps/14/logs/stdio
>
> Those seem to be pseudo aborts because the link is changing.

Why would pseudo abort when the link changes? Replacing a symlink
seems harmless enough ... any ideas?


> > Signed-off-by: Douglas Royds 
> > ---
> >  meta/classes/license_image.bbclass | 38 +-
> >  1 file changed, 22 insertions(+), 16 deletions(-)
> >
> > diff --git a/meta/classes/license_image.bbclass 
> > b/meta/classes/license_image.bbclass
> > index 73cebb4d55e..30204b47b1c 100644
> > --- a/meta/classes/license_image.bbclass
> > +++ b/meta/classes/license_image.bbclass
> > @@ -1,8 +1,9 @@
> >  ROOTFS_LICENSE_DIR = "${IMAGE_ROOTFS}/usr/share/common-licenses"
> > +LICSSTATEDIR = "${WORKDIR}/license-destdir/"
> >
> >  python write_package_manifest() {
> >  # Get list of installed packages
> > -license_image_dir = d.expand('${LICENSE_DIRECTORY}/${IMAGE_NAME}')
> > +license_image_dir = d.expand('${LICSSTATEDIR}/${IMAGE_NAME}')
> >  bb.utils.mkdirhier(license_image_dir)
> >  from oe.rootfs import image_list_installed_packages
> >  from oe.utils import format_pkg_list
> > @@ -32,7 +33,7 @@ python license_create_manifest() {
> >  pkg_lic_name = "LICENSE_" + pkg_name
> >  pkg_dic[pkg_name]["LICENSE"] = pkg_dic[pkg_name][pkg_lic_name]
> >
> > -rootfs_license_manifest = os.path.join(d.getVar('LICENSE_DIRECTORY'),
> > +rootfs_license_manifest = os.path.join(d.getVar('LICSSTATEDIR'),
> >  d.getVar('IMAGE_NAME'), 'license.manifest')
> >  write_license_files(d, rootfs_license_manifest, pkg_dic, rootfs=True)
> >  }
> > @@ -196,23 +197,18 @@ def license_deployed_manifest(d):
> >  key,val = line.split(": ", 1)
> >  man_dic[dep][key] = val[:-1]
> >
> > -lic_manifest_dir = os.path.join(d.getVar('LICENSE_DIRECTORY'),
> > -d.getVar('IMAGE_NAME'))
> > -bb.utils.mkdirhier(lic_manifest_dir)
> > -image_license_manifest = os.path.join(lic_manifest_dir, 
> > 'image_license.manifest')
> > +licsstatedir = d.getVar('LICSSTATEDIR')
> > +image_name = d.getVar('IMAGE_NAME')
> > +image_license_manifest = os.path.join(licsstatedir, image_name, 
> > 'image_license.manifest')
> >  write_license_files(d, image_license_manifest, man_dic, rootfs=False)
> >
> >  link_name = d.getVar('IMAGE_LINK_NAME')
> >  if link_name:
> > -lic_manifest_symlink_dir = 
> > os.path.join(d.getVar('LICENSE_DIRECTORY'),
> > -link_name)
> > -# remove old symlink
> > -if os.path.islink(lic_manifest_symlink_dir):
> > -os.unlink(lic_manifest_symlink_dir)
> > -
> > -# create the image dir symlink
> > -if lic_manifest_dir != lic_manifest_symlink_dir:
> > -os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
> > +

[OE-core] [PATCH v2] license_image: Use sstate to populate license directory

2021-07-01 Thread Douglas via lists.openembedded.org

We were getting an endlessly-growing list of directories in
build/tmp/deploy/licenses/ of the form myimage-mymachine-20210629010203.
Use the normal sstate behaviour to clean them. Brings license_image in
line with the do_populate_lic behaviour in license.bbclass.

We must only clean the (new) WORKDIR/license-destdir at do_rootfs time,
as the write_package_manifest and license_create_manifest rootfs
postprocess commands write the package.manifest and license.manifest
files at that time. They get stored in the sstate cache at
do_populate_lic_deploy time, alongside the image_license.manifest.

Looks like this:

license-destdir/
├── myimage-mymachine -> myimage-mymachine-20210629025723/
└── myimage-mymachine-20210629025723/
├── image_license.manifest
├── license.manifest
└── package.manifest

Signed-off-by: Douglas Royds 
---
 meta/classes/license_image.bbclass | 38 +-
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/meta/classes/license_image.bbclass 
b/meta/classes/license_image.bbclass
index 73cebb4d55e..30204b47b1c 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -1,8 +1,9 @@
 ROOTFS_LICENSE_DIR = "${IMAGE_ROOTFS}/usr/share/common-licenses"
+LICSSTATEDIR = "${WORKDIR}/license-destdir/"
 
 python write_package_manifest() {
 # Get list of installed packages
-license_image_dir = d.expand('${LICENSE_DIRECTORY}/${IMAGE_NAME}')
+license_image_dir = d.expand('${LICSSTATEDIR}/${IMAGE_NAME}')
 bb.utils.mkdirhier(license_image_dir)
 from oe.rootfs import image_list_installed_packages
 from oe.utils import format_pkg_list
@@ -32,7 +33,7 @@ python license_create_manifest() {
 pkg_lic_name = "LICENSE_" + pkg_name
 pkg_dic[pkg_name]["LICENSE"] = pkg_dic[pkg_name][pkg_lic_name]
 
-rootfs_license_manifest = os.path.join(d.getVar('LICENSE_DIRECTORY'),
+rootfs_license_manifest = os.path.join(d.getVar('LICSSTATEDIR'),
 d.getVar('IMAGE_NAME'), 'license.manifest')
 write_license_files(d, rootfs_license_manifest, pkg_dic, rootfs=True)
 }
@@ -196,23 +197,18 @@ def license_deployed_manifest(d):
 key,val = line.split(": ", 1)
 man_dic[dep][key] = val[:-1]
 
-lic_manifest_dir = os.path.join(d.getVar('LICENSE_DIRECTORY'),
-d.getVar('IMAGE_NAME'))
-bb.utils.mkdirhier(lic_manifest_dir)
-image_license_manifest = os.path.join(lic_manifest_dir, 
'image_license.manifest')
+licsstatedir = d.getVar('LICSSTATEDIR')
+image_name = d.getVar('IMAGE_NAME')
+image_license_manifest = os.path.join(licsstatedir, image_name, 
'image_license.manifest')
 write_license_files(d, image_license_manifest, man_dic, rootfs=False)
 
 link_name = d.getVar('IMAGE_LINK_NAME')
 if link_name:
-lic_manifest_symlink_dir = os.path.join(d.getVar('LICENSE_DIRECTORY'),
-link_name)
-# remove old symlink
-if os.path.islink(lic_manifest_symlink_dir):
-os.unlink(lic_manifest_symlink_dir)
-
-# create the image dir symlink
-if lic_manifest_dir != lic_manifest_symlink_dir:
-os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
+if image_name != link_name:
+link_path = os.path.join(licsstatedir, link_name)
+if os.path.lexists(link_path):
+os.remove(link_path)
+os.symlink(image_name, link_path)
 
 def get_deployed_dependencies(d):
 """
@@ -260,14 +256,24 @@ def get_deployed_files(man_file):
 return dep_files
 
 ROOTFS_POSTPROCESS_COMMAND_prepend = "write_package_manifest; 
license_create_manifest; "
+do_rootfs[cleandirs] += "${LICSSTATEDIR}"
 do_rootfs[recrdeptask] += "do_populate_lic"
 
 python do_populate_lic_deploy() {
 license_deployed_manifest(d)
 }
-
 addtask populate_lic_deploy before do_build after do_image_complete
+
+SSTATETASKS += "do_populate_lic_deploy"
+do_populate_lic_deploy[dirs] = "${LICSSTATEDIR}/${IMAGE_NAME}"
 do_populate_lic_deploy[recrdeptask] += "do_populate_lic do_deploy"
+do_populate_lic_deploy[sstate-inputdirs] = "${LICSSTATEDIR}"
+do_populate_lic_deploy[sstate-outputdirs] = "${LICENSE_DIRECTORY}/"
+
+python do_populate_lic_deploy_setscene () {
+sstate_setscene(d)
+}
+addtask do_populate_lic_deploy_setscene
 
 python license_qa_dead_symlink() {
 import os
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153456): 
https://lists.openembedded.org/g/openembedded-core/message/153456
Mute This Topic: https://lists.openembedded.org/mt/83927759/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] license_image: Use sstate to populate license directory

2021-06-28 Thread Douglas via lists.openembedded.org

We were getting an endlessly-growing list of directories in
build/tmp/deploy/licenses/ of the form myimage-mymachine-20210629010203.
Use the normal sstate behaviour to clean them. Brings license_image in
line with the do_populate_lic behaviour in license.bbclass.

We must only clean the (new) WORKDIR/license-destdir at do_rootfs time,
as the write_package_manifest and license_create_manifest rootfs
postprocess commands write the package.manifest and license.manifest
files at that time. They get stored in the sstate cache at
do_populate_lic_deploy time, alongside the image_license.manifest.

Looks like this:

license-destdir/
├── myimage-mymachine -> myimage-mymachine-20210629025723/
└── myimage-mymachine-20210629025723/
├── image_license.manifest
├── license.manifest
└── package.manifest

Signed-off-by: Douglas Royds 
---
 meta/classes/license_image.bbclass | 35 --
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/meta/classes/license_image.bbclass 
b/meta/classes/license_image.bbclass
index 73cebb4d55e..4afbb5ed575 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -1,8 +1,9 @@
 ROOTFS_LICENSE_DIR = "${IMAGE_ROOTFS}/usr/share/common-licenses"
+LICSSTATEDIR = "${WORKDIR}/license-destdir/"
 
 python write_package_manifest() {
 # Get list of installed packages
-license_image_dir = d.expand('${LICENSE_DIRECTORY}/${IMAGE_NAME}')
+license_image_dir = d.expand('${LICSSTATEDIR}/${IMAGE_NAME}')
 bb.utils.mkdirhier(license_image_dir)
 from oe.rootfs import image_list_installed_packages
 from oe.utils import format_pkg_list
@@ -32,7 +33,7 @@ python license_create_manifest() {
 pkg_lic_name = "LICENSE_" + pkg_name
 pkg_dic[pkg_name]["LICENSE"] = pkg_dic[pkg_name][pkg_lic_name]
 
-rootfs_license_manifest = os.path.join(d.getVar('LICENSE_DIRECTORY'),
+rootfs_license_manifest = os.path.join(d.getVar('LICSSTATEDIR'),
 d.getVar('IMAGE_NAME'), 'license.manifest')
 write_license_files(d, rootfs_license_manifest, pkg_dic, rootfs=True)
 }
@@ -196,23 +197,15 @@ def license_deployed_manifest(d):
 key,val = line.split(": ", 1)
 man_dic[dep][key] = val[:-1]
 
-lic_manifest_dir = os.path.join(d.getVar('LICENSE_DIRECTORY'),
-d.getVar('IMAGE_NAME'))
-bb.utils.mkdirhier(lic_manifest_dir)
-image_license_manifest = os.path.join(lic_manifest_dir, 
'image_license.manifest')
+licsstatedir = d.getVar('LICSSTATEDIR')
+image_name = d.getVar('IMAGE_NAME')
+image_license_manifest = os.path.join(licsstatedir, image_name, 
'image_license.manifest')
 write_license_files(d, image_license_manifest, man_dic, rootfs=False)
 
 link_name = d.getVar('IMAGE_LINK_NAME')
 if link_name:
-lic_manifest_symlink_dir = os.path.join(d.getVar('LICENSE_DIRECTORY'),
-link_name)
-# remove old symlink
-if os.path.islink(lic_manifest_symlink_dir):
-os.unlink(lic_manifest_symlink_dir)
-
-# create the image dir symlink
-if lic_manifest_dir != lic_manifest_symlink_dir:
-os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
+if image_name != link_name:
+os.symlink(image_name, os.path.join(licsstatedir, link_name))
 
 def get_deployed_dependencies(d):
 """
@@ -260,14 +253,24 @@ def get_deployed_files(man_file):
 return dep_files
 
 ROOTFS_POSTPROCESS_COMMAND_prepend = "write_package_manifest; 
license_create_manifest; "
+do_rootfs[cleandirs] += "${LICSSTATEDIR}"
 do_rootfs[recrdeptask] += "do_populate_lic"
 
 python do_populate_lic_deploy() {
 license_deployed_manifest(d)
 }
-
 addtask populate_lic_deploy before do_build after do_image_complete
+
+SSTATETASKS += "do_populate_lic_deploy"
+do_populate_lic_deploy[dirs] = "${LICSSTATEDIR}/${IMAGE_NAME}"
 do_populate_lic_deploy[recrdeptask] += "do_populate_lic do_deploy"
+do_populate_lic_deploy[sstate-inputdirs] = "${LICSSTATEDIR}"
+do_populate_lic_deploy[sstate-outputdirs] = "${LICENSE_DIRECTORY}/"
+
+python do_populate_lic_deploy_setscene () {
+sstate_setscene(d)
+}
+addtask do_populate_lic_deploy_setscene
 
 python license_qa_dead_symlink() {
 import os
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153405): 
https://lists.openembedded.org/g/openembedded-core/message/153405
Mute This Topic: https://lists.openembedded.org/mt/83862729/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] Revert "icecc: Don't use icecc when INHIBIT_DEFAULT_DEPS is set"

2021-05-26 Thread Douglas via lists.openembedded.org

Yes, we could, but it's quite a long list, and I'm reluctant to start
naming specific packages.

I only did the INHIBIT_DEFAULT_DEPS test (that I'm reverting here) in
the first place to silence the warnings. I think demoting these
warnings to notes is a better solution.

On Wed, 26 May 2021 at 20:52, Jose Quaresma  wrote:
>
> Hi,
>
> Instead of reverting we can add an exception for the packages you mentioned:
> gcc-cross and friends, binutils-cross, and importantly, the linux kernel.
>
> Douglas via lists.openembedded.org
>  escreveu no dia
> quarta, 26/05/2021 à(s) 01:28:
> >
> > Although this silenced the warnings, it also turned off icecc for
> > gcc-cross and friends, binutils-cross, and importantly, the linux
> > kernel.
> >
> > This reverts commit 0315aabeff8e6483b737d0e23d6841f1394ad3c8.
> >
> > [YOCTO #13863]
> >
> > Signed-off-by: Douglas Royds 
> > ---
> >  meta/classes/icecc.bbclass | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
> > index d095305ed8..0dde960e7a 100644
> > --- a/meta/classes/icecc.bbclass
> > +++ b/meta/classes/icecc.bbclass
> > @@ -138,10 +138,6 @@ def use_icecc(bb,d):
> >  if icecc_is_cross_canadian(bb, d):
> >  return "no"
> >
> > -if d.getVar('INHIBIT_DEFAULT_DEPS', False):
> > -# We don't have a compiler, so no icecc
> > -return "no"
> > -
> >  pn = d.getVar('PN')
> >  bpn = d.getVar('BPN')
> >
> > --
> > 2.25.1
> >
> >
> > 
> >
>
>
> --
> Best regards,
>
> José Quaresma

-- 
This Communication is Confidential. We only send and receive email on the
basis of the terms set out at www.taitradio.com/email_disclaimer 
<http://www.taitradio.com/email_disclaimer>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152289): 
https://lists.openembedded.org/g/openembedded-core/message/152289
Mute This Topic: https://lists.openembedded.org/mt/83090209/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/3] Revert "icecc: Don't use icecc when INHIBIT_DEFAULT_DEPS is set"

2021-05-25 Thread Douglas via lists.openembedded.org

Although this silenced the warnings, it also turned off icecc for
gcc-cross and friends, binutils-cross, and importantly, the linux
kernel.

This reverts commit 0315aabeff8e6483b737d0e23d6841f1394ad3c8.

[YOCTO #13863]

Signed-off-by: Douglas Royds 
---
 meta/classes/icecc.bbclass | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index d095305ed8..0dde960e7a 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -138,10 +138,6 @@ def use_icecc(bb,d):
 if icecc_is_cross_canadian(bb, d):
 return "no"
 
-if d.getVar('INHIBIT_DEFAULT_DEPS', False):
-# We don't have a compiler, so no icecc
-return "no"
-
 pn = d.getVar('PN')
 bpn = d.getVar('BPN')
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152246): 
https://lists.openembedded.org/g/openembedded-core/message/152246
Mute This Topic: https://lists.openembedded.org/mt/83090209/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/3] icecc: Demote "could not get ICECC_CC" warning to note

2021-05-25 Thread Douglas via lists.openembedded.org

For many components, it is perfectly correct not to have gcc or g++ in
the PATH, notably when INHIBIT_DEFAULT_DEPS is set.
We were getting a flood of warnings when icecc was enabled, eg:

WARNING: base-files-3.0.14-r89.tait.8.6 do_configure: Cannot use icecc: 
could not get ICECC_CC or ICECC_CXX
WARNING: base-files-3.0.14-r89.tait.8.6 do_compile: Cannot use icecc: could 
not get ICECC_CC or ICECC_CXX
WARNING: base-files-3.0.14-r89.tait.8.6 do_install: Cannot use icecc: could 
not get ICECC_CC or ICECC_CXX
WARNING: busybox-inittab-1.33.0-r0 do_configure: Cannot use icecc: could 
not get ICECC_CC or ICECC_CXX
WARNING: busybox-inittab-1.33.0-r0 do_compile: Cannot use icecc: could not 
get ICECC_CC or ICECC_CXX
WARNING: busybox-inittab-1.33.0-r0 do_install: Cannot use icecc: could not 
get ICECC_CC or ICECC_CXX
WARNING: linux-libc-headers-3.14-r0 do_configure: Cannot use icecc: could 
not get ICECC_CC or ICECC_CXX
WARNING: linux-libc-headers-3.14-r0 do_compile: Cannot use icecc: could not 
get ICECC_CC or ICECC_CXX
WARNING: linux-libc-headers-3.14-r0 do_install: Cannot use icecc: could not 
get ICECC_CC or ICECC_CXX

Demote this message to a "NOTE".
It still appears in log.do_configure and friends:

NOTE: Cannot use icecc: could not get ICECC_CC or ICECC_CXX

Signed-off-by: Douglas Royds 
---
 meta/classes/icecc.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index 0dde960e7a..80943fcf02 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -358,7 +358,7 @@ set_icecc_env() {
 ICECC_WHICH_AS="${@bb.utils.which(os.getenv('PATH'), 'as')}"
 if [ ! -x "${ICECC_CC}" -o ! -x "${ICECC_CXX}" ]
 then
-bbwarn "Cannot use icecc: could not get ICECC_CC or ICECC_CXX"
+bbnote "Cannot use icecc: could not get ICECC_CC or ICECC_CXX"
 return
 fi
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152248): 
https://lists.openembedded.org/g/openembedded-core/message/152248
Mute This Topic: https://lists.openembedded.org/mt/83090211/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 3/3] icecc-create-env: Silence warning: invalid ICECC_ENV_EXEC

2021-05-25 Thread Douglas via lists.openembedded.org

Signed-off-by: Douglas Royds 
---
 meta/recipes-devtools/icecc-create-env/icecc-create-env_0.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/icecc-create-env/icecc-create-env_0.1.bb 
b/meta/recipes-devtools/icecc-create-env/icecc-create-env_0.1.bb
index 231c1c20ec..61b8487c7e 100644
--- a/meta/recipes-devtools/icecc-create-env/icecc-create-env_0.1.bb
+++ b/meta/recipes-devtools/icecc-create-env/icecc-create-env_0.1.bb
@@ -11,6 +11,7 @@ PR = "r2"
 
 DEPENDS = ""
 INHIBIT_DEFAULT_DEPS = "1"
+ICECC_DISABLED = "1"
 
 # This is needed, because otherwise there is dependency loop from quilt-native
 # Dependency loop #1 found:
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152247): 
https://lists.openembedded.org/g/openembedded-core/message/152247
Mute This Topic: https://lists.openembedded.org/mt/83090210/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 0/3] icecc: Silence warnings

2021-05-25 Thread Douglas via lists.openembedded.org

icecc: Demote "could not get ICECC_CC" warning to note

For many components, it is perfectly correct not to have gcc or g++ in
the PATH, notably when INHIBIT_DEFAULT_DEPS is set.
We were getting a flood of warnings when icecc was enabled, eg:

WARNING: base-files-3.0.14-r89.tait.8.6 do_configure: Cannot use icecc: 
could not get ICECC_CC or ICECC_CXX
WARNING: base-files-3.0.14-r89.tait.8.6 do_compile: Cannot use icecc: could 
not get ICECC_CC or ICECC_CXX
WARNING: base-files-3.0.14-r89.tait.8.6 do_install: Cannot use icecc: could 
not get ICECC_CC or ICECC_CXX
WARNING: busybox-inittab-1.33.0-r0 do_configure: Cannot use icecc: could 
not get ICECC_CC or ICECC_CXX
WARNING: busybox-inittab-1.33.0-r0 do_compile: Cannot use icecc: could not 
get ICECC_CC or ICECC_CXX
WARNING: busybox-inittab-1.33.0-r0 do_install: Cannot use icecc: could not 
get ICECC_CC or ICECC_CXX
WARNING: linux-libc-headers-3.14-r0 do_configure: Cannot use icecc: could 
not get ICECC_CC or ICECC_CXX
WARNING: linux-libc-headers-3.14-r0 do_compile: Cannot use icecc: could not 
get ICECC_CC or ICECC_CXX
WARNING: linux-libc-headers-3.14-r0 do_install: Cannot use icecc: could not 
get ICECC_CC or ICECC_CXX

Demote this message to a "NOTE".
It still appears in log.do_configure and friends:

NOTE: Cannot use icecc: could not get ICECC_CC or ICECC_CXX

Revert "icecc: Don't use icecc when INHIBIT_DEFAULT_DEPS is set".
Although this silenced the warnings, it also turned off icecc for
gcc-cross and friends, binutils-cross, and importantly, the linux
kernel.

[YOCTO #13863]

Douglas Royds (3):
  Revert "icecc: Don't use icecc when INHIBIT_DEFAULT_DEPS is set"
  icecc: Demote "could not get ICECC_CC" warning to note
  icecc-create-env: Silence warning: invalid ICECC_ENV_EXEC

 meta/classes/icecc.bbclass  | 6 +-
 .../icecc-create-env/icecc-create-env_0.1.bb| 1 +
 2 files changed, 2 insertions(+), 5 deletions(-)

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#152245): 
https://lists.openembedded.org/g/openembedded-core/message/152245
Mute This Topic: https://lists.openembedded.org/mt/83090207/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/2] Revert "externalsrc: Detect code changes in submodules"

2021-04-07 Thread Douglas via lists.openembedded.org

This reverts commit 4525310d49d115a37705f04ac5c03d639e5e8f8c.

Signed-off-by: Douglas Royds 
---
 meta/classes/externalsrc.bbclass | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 54cc7edbae0..c7b2bf2f49a 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -217,16 +217,14 @@ def srctree_hash_files(d, srcdir=None):
 env['GIT_INDEX_FILE'] = tmp_index.name
 subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir, 
env=env)
 git_sha1 = subprocess.check_output(['git', 'write-tree'], 
cwd=s_dir, env=env).decode("utf-8")
-submodule_helper = subprocess.check_output(['git', 'submodule', 
'status'], cwd=s_dir, env=env).decode("utf-8")
+submodule_helper = subprocess.check_output(['git', 
'submodule--helper', 'list'], cwd=s_dir, env=env).decode("utf-8")
 for line in submodule_helper.splitlines():
-module_relpath = line.split()[1]
-if not module_relpath.split('/')[0] == '..':
-module_dir = os.path.join(s_dir, module_relpath)
-proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
-proc.communicate()
-proc = subprocess.Popen(['git', 'write-tree'], 
cwd=module_dir, env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
-stdout, _ = proc.communicate()
-git_sha1 += stdout.decode("utf-8")
+module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
+proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
+proc.communicate()
+proc = subprocess.Popen(['git', 'write-tree'], cwd=module_dir, 
env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
+stdout, _ = proc.communicate()
+git_sha1 += stdout.decode("utf-8")
 sha1 = hashlib.sha1(git_sha1.encode("utf-8")).hexdigest()
 with open(oe_hash_file, 'w') as fobj:
 fobj.write(sha1)
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150276): 
https://lists.openembedded.org/g/openembedded-core/message/150276
Mute This Topic: https://lists.openembedded.org/mt/81932011/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 0/2] externalsrc: Detect code changes in submodules

2021-04-07 Thread Douglas via lists.openembedded.org

Further to 50ff9afb39, only detect code changes in submodules that are
subdirectories of the EXTERNALSRC directory.

The (undocumented) git submodule--helper returns a path
for each submodule relative to the top of the repo.
Don't add submodules that are not within our EXTERNALSRC subtree.

If we unpack one git repo inside another, like this:

SRC_URI = "git://${GIT_SERVER}/repo1;name=repo1;destsuffix=repo1 \
   git://${GIT_SERVER}/repo2;name=repo2;destsuffix=repo1/repo2 \
   "

Git status reports, for repo1:

Untracked files:
  (use "git add ..." to include in what will be committed)
repo2/

If we run `devtool modify` on this recipe, do_patch runs with:

PATCHTOOL = "git"
PATCH_COMMIT_FUNCTIONS = "1"

The `patch_task_postfunc` (patch.bbclass, line 82) runs a `git add .` on the
top-level repo1, leaving the checkout in an invalid state. The following git
warning does not appear in the log:

$ git add .
warning: adding embedded git repository: repo2
hint: You've added another git repository inside your current repository.
hint: Clones of the outer repository will not contain the contents of
hint: the embedded repository and will not know how to obtain it.
hint: If you meant to add a submodule, use:
hint:
hint:   git submodule add  repo2
hint:
hint: If you added this path by mistake, you can remove it from the
hint: index with:
hint:
hint:   git rm --cached repo2
hint:
hint: See "git help submodule" for more information.

$ git submodule status
fatal: no submodule mapping found in .gitmodules for path 'repo2'

No further git submodule commands can be run on the checkout.

We could enhance the `patch_task_postfunc` to look for any embedded git
checkouts and add them as submodules, but this seems unnecessary complexity for
an obscure edge-case. Although the git repo is left in an invalid state with
respect to the submodules, it still serves the purpose required by devtool:
To take further commits, and generate patch files from them.

We are still able to run these commands to examine any submodules,
where git submodule--helper reports paths relative to the top of the checkout:

$ git ls-files --stage | grep ^16
16 5feee12d6e974dd8c0614cf5b593380b046439a5 0   repo2

$ git submodule--helper list
16 5feee12d6e974dd8c0614cf5b593380b046439a5 0   repo2

When a recipe sets EXTERNALSRC to a subdirectory of the git checkout, we test
for the existence of the reported submodule paths within the EXTERNALSRC
directory.

The latest versions of git submodule--helper accept a path to a subdirectory and
correctly report no submodules within that subdirectory. Regrettably, we still
support git versions that don't accept a path to a subdirectory.

[YOCTO #14333]

Douglas Royds (2):
  Revert "externalsrc: Detect code changes in submodules"
  externalsrc: Detect code changes in submodules

 meta/classes/externalsrc.bbclass | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150274): 
https://lists.openembedded.org/g/openembedded-core/message/150274
Mute This Topic: https://lists.openembedded.org/mt/81932009/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/2] externalsrc: Detect code changes in submodules

2021-04-07 Thread Douglas via lists.openembedded.org

Further to 50ff9afb39, only detect code changes in submodules that are
subdirectories of the EXTERNALSRC directory.

The (undocumented) git submodule--helper returns a path
for each submodule relative to the top of the repo.
Don't add submodules that are not within our source subtree.

[YOCTO #14333]

Signed-off-by: Douglas Royds 
---
 meta/classes/externalsrc.bbclass | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index c7b2bf2f49a..3d6b80bee2b 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -220,11 +220,12 @@ def srctree_hash_files(d, srcdir=None):
 submodule_helper = subprocess.check_output(['git', 
'submodule--helper', 'list'], cwd=s_dir, env=env).decode("utf-8")
 for line in submodule_helper.splitlines():
 module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
-proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
-proc.communicate()
-proc = subprocess.Popen(['git', 'write-tree'], cwd=module_dir, 
env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
-stdout, _ = proc.communicate()
-git_sha1 += stdout.decode("utf-8")
+if os.path.isdir(module_dir):
+proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
+proc.communicate()
+proc = subprocess.Popen(['git', 'write-tree'], 
cwd=module_dir, env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
+stdout, _ = proc.communicate()
+git_sha1 += stdout.decode("utf-8")
 sha1 = hashlib.sha1(git_sha1.encode("utf-8")).hexdigest()
 with open(oe_hash_file, 'w') as fobj:
 fobj.write(sha1)
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150275): 
https://lists.openembedded.org/g/openembedded-core/message/150275
Mute This Topic: https://lists.openembedded.org/mt/81932010/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2] externalsrc: Detect code changes in submodules

2021-03-17 Thread Douglas via lists.openembedded.org

Further to 50ff9afb39, only detect code changes in submodules that are
subdirectories of the EXTERNALSRC directory.

git submodule status returns a path relative to the cwd for each submodule.
We don't add submodules that are not within our source subtree.

Signed-off-by: Douglas Royds 
---
 meta/classes/externalsrc.bbclass | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 64e94e3301..3c067fbc37 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -216,14 +216,16 @@ def srctree_hash_files(d, srcdir=None):
 env['GIT_INDEX_FILE'] = tmp_index.name
 subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir, 
env=env)
 git_sha1 = subprocess.check_output(['git', 'write-tree'], 
cwd=s_dir, env=env).decode("utf-8")
-submodule_helper = subprocess.check_output(['git', 
'submodule--helper', 'list'], cwd=s_dir, env=env).decode("utf-8")
+submodule_helper = subprocess.check_output(['git', 'submodule', 
'status'], cwd=s_dir, env=env).decode("utf-8")
 for line in submodule_helper.splitlines():
-module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
-proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
-proc.communicate()
-proc = subprocess.Popen(['git', 'write-tree'], cwd=module_dir, 
env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
-stdout, _ = proc.communicate()
-git_sha1 += stdout.decode("utf-8")
+module_relpath = line.split()[1]
+if not module_relpath.split('/')[0] == '..':
+module_dir = os.path.join(s_dir, module_relpath)
+proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
+proc.communicate()
+proc = subprocess.Popen(['git', 'write-tree'], 
cwd=module_dir, env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
+stdout, _ = proc.communicate()
+git_sha1 += stdout.decode("utf-8")
 sha1 = hashlib.sha1(git_sha1.encode("utf-8")).hexdigest()
 with open(oe_hash_file, 'w') as fobj:
 fobj.write(sha1)
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149610): 
https://lists.openembedded.org/g/openembedded-core/message/149610
Mute This Topic: https://lists.openembedded.org/mt/81417814/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] cmake: Fully-qualified path to ar

2021-03-17 Thread Douglas via lists.openembedded.org

We (correctly enough) pass in our AR to cmake via the toolchain file,
but unlike the other cross-compilation tools (CC, CXX, ranlib, etc),
cmake does not then do its own search in the PATH for our AR.

By using cmake's own find_program() to search the PATH,
make works as expected from the commandline, outside of bitbake.

Signed-off-by: Douglas Royds 
---
 meta/classes/cmake.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 70e4f3b6fd0..8876ce5aa56 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -102,7 +102,8 @@ set( CMAKE_CXX_COMPILER ${OECMAKE_CXX_COMPILER} )
 set( CMAKE_C_COMPILER_LAUNCHER ${OECMAKE_C_COMPILER_LAUNCHER} )
 set( CMAKE_CXX_COMPILER_LAUNCHER ${OECMAKE_CXX_COMPILER_LAUNCHER} )
 set( CMAKE_ASM_COMPILER ${OECMAKE_C_COMPILER} )
-set( CMAKE_AR ${OECMAKE_AR} CACHE FILEPATH "Archiver" )
+find_program( CMAKE_AR ${OECMAKE_AR} DOC "Archiver" REQUIRED )
+
 set( CMAKE_C_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "CFLAGS" )
 set( CMAKE_CXX_FLAGS "${OECMAKE_CXX_FLAGS}" CACHE STRING "CXXFLAGS" )
 set( CMAKE_ASM_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "ASM FLAGS" )
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149609): 
https://lists.openembedded.org/g/openembedded-core/message/149609
Mute This Topic: https://lists.openembedded.org/mt/81417537/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] externalsrc: Detect code changes in submodules

2021-02-08 Thread Douglas via lists.openembedded.org


On 6/02/21 1:01 pm, Jon Mason wrote:

On Thu, Feb 4, 2021 at 10:43 PM Douglas via lists.openembedded.org
 wrote:

Further to 50ff9afb39, only detect code changes in submodules that are
subdirectories of the EXTERNALSRC directory.

Signed-off-by: Douglas Royds 
---

I believe this patch is causing errors in the autobuilder.  See
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/1801/steps/14/logs/stdio



Good find by the autobuilder. Earning its money.

This is a git weakness: In this case of a local-files-only recipe, 
devtool creates an empty git repository and `git submodule--helper list 
path/` fails. Add a file (not even committed), and it works just fine.


Updated patch on its way.





  meta/classes/externalsrc.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 64e94e3301..27496bb2db 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -216,7 +216,7 @@ def srctree_hash_files(d, srcdir=None):
  env['GIT_INDEX_FILE'] = tmp_index.name
  subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir, 
env=env)
  git_sha1 = subprocess.check_output(['git', 'write-tree'], cwd=s_dir, 
env=env).decode("utf-8")
-submodule_helper = subprocess.check_output(['git', 'submodule--helper', 
'list'], cwd=s_dir, env=env).decode("utf-8")
+submodule_helper = subprocess.check_output(['git', 'submodule--helper', 
'list', s_dir], cwd=s_dir, env=env).decode("utf-8")
  for line in submodule_helper.splitlines():
  module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
  proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
--
2.25.1






--
This Communication is Confidential. We only send and receive email on the
basis of the terms set out at www.taitradio.com/email_disclaimer 
<http://www.taitradio.com/email_disclaimer>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147849): 
https://lists.openembedded.org/g/openembedded-core/message/147849
Mute This Topic: https://lists.openembedded.org/mt/80398669/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] externalsrc: Detect code changes in submodules

2021-02-04 Thread Douglas via lists.openembedded.org

Further to 50ff9afb39, only detect code changes in submodules that are
subdirectories of the EXTERNALSRC directory.

Signed-off-by: Douglas Royds 
---
 meta/classes/externalsrc.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 64e94e3301..27496bb2db 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -216,7 +216,7 @@ def srctree_hash_files(d, srcdir=None):
 env['GIT_INDEX_FILE'] = tmp_index.name
 subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir, 
env=env)
 git_sha1 = subprocess.check_output(['git', 'write-tree'], 
cwd=s_dir, env=env).decode("utf-8")
-submodule_helper = subprocess.check_output(['git', 
'submodule--helper', 'list'], cwd=s_dir, env=env).decode("utf-8")
+submodule_helper = subprocess.check_output(['git', 
'submodule--helper', 'list', s_dir], cwd=s_dir, env=env).decode("utf-8")
 for line in submodule_helper.splitlines():
 module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
 proc = subprocess.Popen(['git', 'add', '-A', '.'], 
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147679): 
https://lists.openembedded.org/g/openembedded-core/message/147679
Mute This Topic: https://lists.openembedded.org/mt/80398669/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] nativesdk-linux-libc-headers with two different MACHINEs

2020-09-15 Thread Douglas via lists.openembedded.org

Built a core-image-minimal sdk fine, and also our proprietary sdk.

On Tue, 15 Sep 2020 at 13:14, Khem Raj  wrote:
>
> OK please test this patch for full SDK builds and any other testing
> you do and report back if it works in all cases.
>
> On Mon, Sep 14, 2020 at 5:42 PM Douglas Royds
>  wrote:
> >
> > Yes it did, thanks!
> >
> >
> > On 15/09/20 12:31 pm, Khem Raj wrote:
> >
> > > I think MACHINE should not matter for nativesdk packages. Does
> > > something like this work
> > >
> > > diff --git a/meta/classes/nativesdk.bbclass 
> > > b/meta/classes/nativesdk.bbclass
> > > index 7f2692c51a..bb1dfd84c0 100644
> > > --- a/meta/classes/nativesdk.bbclass
> > > +++ b/meta/classes/nativesdk.bbclass
> > > @@ -10,7 +10,7 @@ LIBCOVERRIDE = ":${NATIVESDKLIBC}"
> > >   CLASSOVERRIDE = "class-nativesdk"
> > >   MACHINEOVERRIDES = ""
> > >   MACHINE_FEATURES = ""
> > > -
> > > +MACHINE = "${SDKMACHINE}"
> > >   MULTILIBS = ""
> > >
> > >   # we need consistent staging dir whether or not multilib is enabled
> > >
> > > On Mon, Sep 14, 2020 at 5:13 PM Douglas via lists.openembedded.org
> > >  wrote:
> > >> For the experiment, I wanted to see whether I could achieve no task 
> > >> signature change when building nativesdk-glibc for two different 
> > >> MACHINEs, but I found that the do_install sigdata for 
> > >> nativesdk-linux-libc-headers changed. We're installing the 
> > >> linux-libc-headers for the build machine, so it seems to make sense to 
> > >> take control of the TARGET_CC_KERNEL_ARCH:
> > >>
> > >> diff --git a/meta/classes/nativesdk.bbclass 
> > >> b/meta/classes/nativesdk.bbclass
> > >> index 32c3aa32ad..655439dd73 100644
> > >> --- a/meta/classes/nativesdk.bbclass
> > >> +++ b/meta/classes/nativesdk.bbclass
> > >> @@ -47,6 +47,7 @@ TARGET_VENDOR = "${SDK_VENDOR}"
> > >>   TARGET_OS = "${SDK_OS}"
> > >>   TARGET_PREFIX = "${SDK_PREFIX}"
> > >>   TARGET_CC_ARCH = "${SDK_CC_ARCH}"
> > >> +TARGET_CC_KERNEL_ARCH = "${SDK_CC_ARCH}"
> > >>   TARGET_LD_ARCH = "${SDK_LD_ARCH}"
> > >>
> > >> Which leaves me with:
> > >>
> > >> basehash changed from 42ed3480096bb7ea53b60dc876da0613 to 
> > >> 38ea60bdac041673f2c491d7bbabe17c
> > >> Variable MACHINE value changed from 'qemuarm' to 'qemux86-64'
> > >> runtaskdeps changed:
> > >> linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk
> > >>  with hash cbb186fe33cd69cb0b06384e4d50a244
> > >>   changed to
> > >> linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk
> > >>  with hash 4d34d6981b79d0fccc768566bf2fa533
> > >> Hash for dependent task 
> > >> linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk
> > >>  changed from cbb186fe33cd69cb0b06384e4d50a244 to 
> > >> 4d34d6981b79d0fccc768566bf2fa533
> > >>
> > >> The configure and compile tasks for linux-libc-headers are both set to 
> > >> noexec. For the experiment, I added an empty do_configure task, with 
> > >> this result on the do_configure sigdata:
> > >>
> > >> basehash changed from f13c2a2066fa48f0ccac35c085537c71 to 
> > >> bb13f2b1b1e7e376f3fb5a8ec888
> > >> Variable MACHINE value changed from 'qemux86-64' to 'qemuarm'
> > >>
> > >> What to do? Why is the MACHINE variable included in the task signature 
> > >> (it is unset in run.do_configure)? Adding it to BB_HASHBASE_WHITELIST 
> > >> had no effect. What am I missing here?
> > >>
> > >> 
> >
> >

-- 
This Communication is Confidential. We only send and receive email on the

basis of the terms set out at www.taitradio.com/email_disclaimer 
<http://www.taitradio.com/email_disclaimer>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142597): 
https://lists.openembedded.org/g/openembedded-core/message/142597
Mute This Topic: https://lists.openembedded.org/mt/76855451/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] nativesdk: Set TARGET_CC_KERNEL_ARCH for sdk

2020-09-14 Thread Douglas via lists.openembedded.org

We install the linux-libc-headers for the build machine, so
take control of the TARGET_CC_KERNEL_ARCH.
In this way, we get no task signature changes when we build
nativesdk-linux-libc-headers with different MACHINEs,
avoiding a build-through from glibc up.

Signed-off-by: Douglas Royds 
---
 meta/classes/nativesdk.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index 7f2692c51a..420ee52be2 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -47,6 +47,7 @@ TARGET_VENDOR = "${SDK_VENDOR}"
 TARGET_OS = "${SDK_OS}"
 TARGET_PREFIX = "${SDK_PREFIX}"
 TARGET_CC_ARCH = "${SDK_CC_ARCH}"
+TARGET_CC_KERNEL_ARCH = "${SDK_CC_ARCH}"
 TARGET_LD_ARCH = "${SDK_LD_ARCH}"
 TARGET_AS_ARCH = "${SDK_AS_ARCH}"
 TARGET_CPPFLAGS = "${BUILDSDK_CPPFLAGS}"
-- 
2.17.1

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

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

Re: [OE-core] nativesdk-linux-libc-headers with two different MACHINEs

2020-09-14 Thread Douglas via lists.openembedded.org


Yes it did, thanks!


On 15/09/20 12:31 pm, Khem Raj wrote:


I think MACHINE should not matter for nativesdk packages. Does
something like this work

diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index 7f2692c51a..bb1dfd84c0 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -10,7 +10,7 @@ LIBCOVERRIDE = ":${NATIVESDKLIBC}"
  CLASSOVERRIDE = "class-nativesdk"
  MACHINEOVERRIDES = ""
  MACHINE_FEATURES = ""
-
+MACHINE = "${SDKMACHINE}"
  MULTILIBS = ""

  # we need consistent staging dir whether or not multilib is enabled

On Mon, Sep 14, 2020 at 5:13 PM Douglas via lists.openembedded.org
 wrote:

For the experiment, I wanted to see whether I could achieve no task signature 
change when building nativesdk-glibc for two different MACHINEs, but I found 
that the do_install sigdata for nativesdk-linux-libc-headers changed. We're 
installing the linux-libc-headers for the build machine, so it seems to make 
sense to take control of the TARGET_CC_KERNEL_ARCH:

diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index 32c3aa32ad..655439dd73 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -47,6 +47,7 @@ TARGET_VENDOR = "${SDK_VENDOR}"
  TARGET_OS = "${SDK_OS}"
  TARGET_PREFIX = "${SDK_PREFIX}"
  TARGET_CC_ARCH = "${SDK_CC_ARCH}"
+TARGET_CC_KERNEL_ARCH = "${SDK_CC_ARCH}"
  TARGET_LD_ARCH = "${SDK_LD_ARCH}"

Which leaves me with:

basehash changed from 42ed3480096bb7ea53b60dc876da0613 to 
38ea60bdac041673f2c491d7bbabe17c
Variable MACHINE value changed from 'qemuarm' to 'qemux86-64'
runtaskdeps changed:
linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk with 
hash cbb186fe33cd69cb0b06384e4d50a244
  changed to
linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk with 
hash 4d34d6981b79d0fccc768566bf2fa533
Hash for dependent task 
linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk 
changed from cbb186fe33cd69cb0b06384e4d50a244 to 
4d34d6981b79d0fccc768566bf2fa533

The configure and compile tasks for linux-libc-headers are both set to noexec. 
For the experiment, I added an empty do_configure task, with this result on the 
do_configure sigdata:

basehash changed from f13c2a2066fa48f0ccac35c085537c71 to 
bb13f2b1b1e7e376f3fb5a8ec888
Variable MACHINE value changed from 'qemux86-64' to 'qemuarm'

What to do? Why is the MACHINE variable included in the task signature (it is 
unset in run.do_configure)? Adding it to BB_HASHBASE_WHITELIST had no effect. 
What am I missing here?





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

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

[OE-core] nativesdk-linux-libc-headers with two different MACHINEs

2020-09-14 Thread Douglas via lists.openembedded.org

For the experiment, I wanted to see whether I could achieve no task 
signature change when building nativesdk-glibc for two different 
MACHINEs, but I found that the do_install sigdata for 
nativesdk-linux-libc-headers changed. We're installing the 
linux-libc-headers for the build machine, so it seems to make sense to 
take control of the TARGET_CC_KERNEL_ARCH:


   diff --git a/meta/classes/nativesdk.bbclass
   b/meta/classes/nativesdk.bbclass
   index 32c3aa32ad..655439dd73 100644
   --- a/meta/classes/nativesdk.bbclass
   +++ b/meta/classes/nativesdk.bbclass
   @@ -47,6 +47,7 @@ TARGET_VENDOR = "${SDK_VENDOR}"
 TARGET_OS = "${SDK_OS}"
 TARGET_PREFIX = "${SDK_PREFIX}"
 TARGET_CC_ARCH = "${SDK_CC_ARCH}"
   +TARGET_CC_KERNEL_ARCH = "${SDK_CC_ARCH}"
 TARGET_LD_ARCH = "${SDK_LD_ARCH}"

Which leaves me with:

   basehash changed from 42ed3480096bb7ea53b60dc876da0613 to
   38ea60bdac041673f2c491d7bbabe17c
   Variable MACHINE value changed from 'qemuarm' to 'qemux86-64'
   runtaskdeps changed:
   linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk
   with hash cbb186fe33cd69cb0b06384e4d50a244
 changed to
   linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk
   with hash 4d34d6981b79d0fccc768566bf2fa533
   Hash for dependent task
   linux-libc-headers/linux-libc-headers_4.18.bb.do_compile:virtual:nativesdk
   changed from cbb186fe33cd69cb0b06384e4d50a244 to
   4d34d6981b79d0fccc768566bf2fa533

The configure and compile tasks for linux-libc-headers are both set to 
noexec. For the experiment, I added an empty do_configure task, with 
this result on the do_configure sigdata:


   basehash changed from f13c2a2066fa48f0ccac35c085537c71 to
   bb13f2b1b1e7e376f3fb5a8ec888
   Variable MACHINE value changed from 'qemux86-64' to 'qemuarm'

What to do? Why is the MACHINE variable included in the task signature 
(it is unset in run.do_configure)? Adding it to BB_HASHBASE_WHITELIST 
had no effect. What am I missing here?


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

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

[OE-core] [PATCH v2] tcmode-default: Drop gcc-cross-initial, gcc-crosssdk-initial references

2020-09-13 Thread Douglas via lists.openembedded.org

Further to 5b2fd1c724

Also a few remaining references in comments and in distro_alias.inc

Signed-off-by: Douglas Royds 
---
 meta/conf/distro/include/distro_alias.inc   | 4 
 meta/conf/distro/include/tcmode-default.inc | 2 --
 meta/conf/layer.conf| 2 +-
 3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/meta/conf/distro/include/distro_alias.inc 
b/meta/conf/distro/include/distro_alias.inc
index 56055f7798..b4dfcfc5f5 100644
--- a/meta/conf/distro/include/distro_alias.inc
+++ b/meta/conf/distro/include/distro_alias.inc
@@ -81,10 +81,6 @@ DISTRO_PN_ALIAS_pn-encodings = "Ubuntu=xfonts-encodings 
Mandriva=x11-font-encodi
 DISTRO_PN_ALIAS_pn-font-alias = "Fedora=xorg-x11-fonts-base 
Mandriva=x11-font-alias Meego=xorg-x11-fonts"
 DISTRO_PN_ALIAS_pn-font-util = "Meego=xorg-x11-font-utils 
Fedora=xorg-x11-font-utils Ubuntu=xfonts-utils Mandriva=x11-font-util 
Debian=xfonts-utils"
 DISTRO_PN_ALIAS_pn-formfactor = "OE-Core"
-DISTRO_PN_ALIAS_pn-gcc-cross-initial = "OE-Core"
-DISTRO_PN_ALIAS_pn-gcc-cross-initial-i586 = "OE-Core"
-DISTRO_PN_ALIAS_pn-gcc-crosssdk-initial = "OE-Core"
-DISTRO_PN_ALIAS_pn-gcc-crosssdk-initial-x86_64 = "OE-Core"
 DISTRO_PN_ALIAS_pn-gccmakedep = "Mandriva=gccmakedep Ubuntu=xutils-dev"
 DISTRO_PN_ALIAS_pn-gcc-runtime = "Ubuntu=gcc Fedora=gcc"
 DISTRO_PN_ALIAS_pn-gcc-sanitizers = "Ubuntu=gcc Fedora=gcc"
diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index 1bc95ec675..50e8a20f35 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -30,9 +30,7 @@ LLVMVERSION ?= "10.0.1"
 
 PREFERRED_VERSION_gcc ?= "${GCCVERSION}"
 PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} ?= "${GCCVERSION}"
-PREFERRED_VERSION_gcc-cross-initial-${TARGET_ARCH} ?= "${GCCVERSION}"
 PREFERRED_VERSION_gcc-crosssdk-${SDK_SYS} ?= "${SDKGCCVERSION}"
-PREFERRED_VERSION_gcc-crosssdk-initial-${SDK_SYS} ?= "${SDKGCCVERSION}"
 PREFERRED_VERSION_gcc-cross-canadian-${TRANSLATED_TARGET_ARCH} ?= 
"${GCCVERSION}"
 PREFERRED_VERSION_gcc-runtime ?= "${GCCVERSION}"
 PREFERRED_VERSION_gcc-sanitizers ?= "${GCCVERSION}"
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 1a01d02fef..38df0f3aff 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -91,7 +91,7 @@ SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
 # dependency incidentally. This improves determinism and avoids build
 # failures when people switch to external toolchains.
 SSTATE_EXCLUDEDEPS_SYSROOT += ".*->bison-native"
-# Nothing needs to depend on libc-initial/gcc-cross-initial
+# Nothing needs to depend on libc-initial
 # base-passwd/shadow-sysroot don't need their dependencies
 SSTATE_EXCLUDEDEPS_SYSROOT += "\
 .*->.*-initial.* \
-- 
2.17.1

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

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

[OE-core] [PATCH] tcmode-default: Drop gcc-cross-initial, gcc-crosssdk-initial references

2020-09-10 Thread Douglas via lists.openembedded.org

Further to 5b2fd1c724

Also a few remaining references (DISTRO_PN_ALIAS, RECIPE_MAINTAINER).

Signed-off-by: Douglas Royds 
---
meta/conf/distro/include/distro_alias.inc | 4 
meta/conf/distro/include/tcmode-default.inc | 2 --
meta/conf/layer.conf | 2 +-
3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/meta/conf/distro/include/distro_alias.inc
b/meta/conf/distro/include/distro_alias.inc
index 56055f7798..b4dfcfc5f5 100644
--- a/meta/conf/distro/include/distro_alias.inc
+++ b/meta/conf/distro/include/distro_alias.inc
@@ -81,10 +81,6 @@ DISTRO_PN_ALIAS_pn-encodings =
"Ubuntu=xfonts-encodings Mandriva=x11-font-encodi
DISTRO_PN_ALIAS_pn-font-alias = "Fedora=xorg-x11-fonts-base
Mandriva=x11-font-alias Meego=xorg-x11-fonts"
DISTRO_PN_ALIAS_pn-font-util = "Meego=xorg-x11-font-utils
Fedora=xorg-x11-font-utils Ubuntu=xfonts-utils Mandriva=x11-font-util
Debian=xfonts-utils"
DISTRO_PN_ALIAS_pn-formfactor = "OE-Core"
-DISTRO_PN_ALIAS_pn-gcc-cross-initial = "OE-Core"
-DISTRO_PN_ALIAS_pn-gcc-cross-initial-i586 = "OE-Core"
-DISTRO_PN_ALIAS_pn-gcc-crosssdk-initial = "OE-Core"
-DISTRO_PN_ALIAS_pn-gcc-crosssdk-initial-x86_64 = "OE-Core"
DISTRO_PN_ALIAS_pn-gccmakedep = "Mandriva=gccmakedep Ubuntu=xutils-dev"
DISTRO_PN_ALIAS_pn-gcc-runtime = "Ubuntu=gcc Fedora=gcc"
DISTRO_PN_ALIAS_pn-gcc-sanitizers = "Ubuntu=gcc Fedora=gcc"
diff --git a/meta/conf/distro/include/tcmode-default.inc
b/meta/conf/distro/include/tcmode-default.inc
index 1bc95ec675..50e8a20f35 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -30,9 +30,7 @@ LLVMVERSION ?= "10.0.1"
PREFERRED_VERSION_gcc ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} ?= "${GCCVERSION}"
-PREFERRED_VERSION_gcc-cross-initial-${TARGET_ARCH} ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-crosssdk-${SDK_SYS} ?= "${SDKGCCVERSION}"
-PREFERRED_VERSION_gcc-crosssdk-initial-${SDK_SYS} ?= "${SDKGCCVERSION}"
PREFERRED_VERSION_gcc-cross-canadian-${TRANSLATED_TARGET_ARCH} ?=
"${GCCVERSION}"
PREFERRED_VERSION_gcc-runtime ?= "${GCCVERSION}"
PREFERRED_VERSION_gcc-sanitizers ?= "${GCCVERSION}"
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 1a01d02fef..38df0f3aff 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -91,7 +91,7 @@ SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
# dependency incidentally. This improves determinism and avoids build
# failures when people switch to external toolchains.
SSTATE_EXCLUDEDEPS_SYSROOT += ".*->bison-native"
-# Nothing needs to depend on libc-initial/gcc-cross-initial
+# Nothing needs to depend on libc-initial
# base-passwd/shadow-sysroot don't need their dependencies
SSTATE_EXCLUDEDEPS_SYSROOT += "\
.*->.*-initial.* \

-- 
2.17.1

-- 
This Communication is Confidential. We only send and receive email on the

basis of the terms set out at www.taitradio.com/email_disclaimer 

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

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

[OE-core] sdk package_arch and yum

2020-07-28 Thread Douglas via lists.openembedded.org

I was unable to install my nativesdk packages on CentOS using yum, as 
the package architecture was set to "x86_64_nativesdk". My web-digging 
revealed no work-around I could use for yum.


dnf (available in CentOS 8, I believe) supports a --forcearch 
 option, and also provides an 
ignorearch  configuration 
option, though this seems an unsatisfactory work-around.


For the experiment, I forced the sdk package_arch to simply "x86_64", 
and yum cheerfully installed the resulting rpm packages:


   PACKAGE_ARCH_class-nativesdk = "${SDK_ARCH}"
   SDK_PACKAGE_ARCHS = "all any noarch ${SDK_ARCH}"

I have no familiarity with yum. Am I missing something?

If not, I will propose a patch to create packages with PACKAGE_ARCH = 
x86_64 in the nativesdk case, but I wanted a sanity check before I did 
this work.


For the record, apt did install the corresponding .deb files, cheerfully 
ignoring the architecture.


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

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

[OE-core] [PATCH] nativesdk: clear MACHINE_FEATURES

2020-07-09 Thread Douglas via lists.openembedded.org

Further to 96c20c9df7:
Try to avoid nativesdk recipes accidentally being dependent on MACHINE_FEATURES.

Signed-off-by: Douglas Royds 
---
 meta/classes/nativesdk.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index 7b75710726..cd389c9c77 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -9,6 +9,7 @@ NATIVESDKLIBC ?= "libc-glibc"
 LIBCOVERRIDE = ":${NATIVESDKLIBC}"
 CLASSOVERRIDE = "class-nativesdk"
 MACHINEOVERRIDES = ""
+MACHINE_FEATURES = ""
 
 MULTILIBS = ""
 
-- 
2.17.1

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

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

[OE-core] [PATCH] nativesdk: Set the CXXFLAGS to the BUILDSDK_CXXFLAGS

2020-07-09 Thread Douglas via lists.openembedded.org

... which default to the BUILDSDK_CFLAGS in any case.

Signed-off-by: Douglas Royds 
---
 meta/classes/nativesdk.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index 7b75710726..171ae72be0 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -57,7 +57,7 @@ EXTRA_OECONF_GCC_FLOAT = ""
 
 CPPFLAGS = "${BUILDSDK_CPPFLAGS}"
 CFLAGS = "${BUILDSDK_CFLAGS}"
-CXXFLAGS = "${BUILDSDK_CFLAGS}"
+CXXFLAGS = "${BUILDSDK_CXXFLAGS}"
 LDFLAGS = "${BUILDSDK_LDFLAGS}"
 
 # Change to place files in SDKPATH
-- 
2.17.1

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

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

Re: [OE-core] [PATCH 1/1] sanity.bbclass: Update required gcc version to v7.5

Re: [OE-core] [PATCH] externalsrc.bbclass: Allow externalsrc to be extended with extra classes

Re: [OE-core][PATCH v2 1/2] reproducible_build: Remove BUILD_REPRODUCIBLE_BINARIES checking

Re: [OE-core][PATCH 2/2] reproducible_build: Work with externalsrc

Re: [OE-core][PATCH 2/2] reproducible_build: Work with externalsrc

Re: [OE-core][PATCH 1/2] reproducible_build: Honor BUILD_REPRODUCIBLE_BINARIES

Re: [OE-core] [PATCH v2] license_image: Use sstate to populate license directory

[OE-core] [PATCH v2] license_image: Use sstate to populate license directory

[OE-core] [PATCH] license_image: Use sstate to populate license directory

Re: [OE-core] [PATCH 1/3] Revert "icecc: Don't use icecc when INHIBIT_DEFAULT_DEPS is set"

[OE-core] [PATCH 1/3] Revert "icecc: Don't use icecc when INHIBIT_DEFAULT_DEPS is set"

[OE-core] [PATCH 2/3] icecc: Demote "could not get ICECC_CC" warning to note

[OE-core] [PATCH 3/3] icecc-create-env: Silence warning: invalid ICECC_ENV_EXEC

[OE-core] [PATCH 0/3] icecc: Silence warnings

[OE-core] [PATCH 1/2] Revert "externalsrc: Detect code changes in submodules"

[OE-core] [PATCH 0/2] externalsrc: Detect code changes in submodules

[OE-core] [PATCH 2/2] externalsrc: Detect code changes in submodules

[OE-core] [PATCH v2] externalsrc: Detect code changes in submodules

[OE-core] [PATCH] cmake: Fully-qualified path to ar

Re: [OE-core] [PATCH] externalsrc: Detect code changes in submodules

[OE-core] [PATCH] externalsrc: Detect code changes in submodules

Re: [OE-core] nativesdk-linux-libc-headers with two different MACHINEs

[OE-core] [PATCH] nativesdk: Set TARGET_CC_KERNEL_ARCH for sdk

Re: [OE-core] nativesdk-linux-libc-headers with two different MACHINEs

[OE-core] nativesdk-linux-libc-headers with two different MACHINEs

[OE-core] [PATCH v2] tcmode-default: Drop gcc-cross-initial, gcc-crosssdk-initial references

[OE-core] [PATCH] tcmode-default: Drop gcc-cross-initial, gcc-crosssdk-initial references

[OE-core] sdk package_arch and yum

[OE-core] [PATCH] nativesdk: clear MACHINE_FEATURES

[OE-core] [PATCH] nativesdk: Set the CXXFLAGS to the BUILDSDK_CXXFLAGS

30 matches

Site Navigation

Mail list logo

Footer information