Re: [OE-core] Overriding SDE_FILE

[Douglas Royds via Openembedded-core]

On 28/02/20 11:34 am, Joshua Watt wrote:



On 2/27/20 4:29 PM, Douglas Royds wrote:


On 28/02/20 10:49 am, Joshua Watt wrote:



On 2/27/20 3:22 PM, Douglas Royds wrote:


On 28/02/20 5:45 am, Joshua Watt wrote:


On 2/27/20 9:01 AM, Joshua Watt wrote:

On 2/26/20 11:46 PM, Douglas Royds wrote:


On 26/02/20 4:53 am, Jacob Kroon wrote:


On 2/24/20 8:25 AM, Jacob Kroon wrote:

Hi Douglas,

You updated a comment in reproducible_build.bbclass, commit 
e7b891b76954c784f5a93bd0a1c91315673ce40d:


-# Once the value of SOURCE_DATE_EPOCH is determined, it is 
stored in the recipe's ${SDE_FILE}.
+# 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.

+#


But I can't really get this to work. What did work for me was 
to replace "do_create_source_date_epoch_stamp()" in my recipe:


do_create_source_date_epoch_stamp() {
 mkdir -p ${SDE_DIR}
 date -d "1981-03-03" "+%s" > ${SDE_FILE}
}

What is the intended way to achieve the thing I'm trying to do 
here ?




FYI, JPEW has a proposed patch here

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible=d091d2aa53ea417f70c10f5ce89151820c3db9ce 



for allowing a recipe to just set SOURCE_DATE_EPOCH directly.

But maybe that currently is at odds with SOURCE_DATE_EPOCH 
being in BB_HASHBASE_WHITELIST ?


/Jacob



On the surface of it, my comment appears to be just wrong: It 
does make sense to replace do_create_source_date_epoch_stamp() 
as you suggest.


Joshua's proposed patch looks promising:

  * Should the new function not be called first, so that it
takes priority over the git, known files, and youngest file
functions? If someone has explicitly set SOURCE_DATE_EPOCH,
then they want it to take priority.

Having that be the first option makes sense. The only case in 
which that might not work, is if a recipe does something like:


 SOURCE_DATE_EPOCH = "${@my_awesome_sde_calculation(d)}"

e.g. uses a function to get the SDE instead of setting to a fixed 
value, but that's probably going to be extremely rare.




 *



  * As you observe, SOURCE_DATE_EPOCH would need to be removed
from BB_HASHBASE_WHITELIST. I'm not sure why it was in the
whitelist in the first place.

I'm not sure why exactly it is whitelisted; I didn't write the 
original code that whitelisted it, but I've CC'd Juro in case he 
happens to remember.


After a discussion with Richard, we figured out why 
SOURCE_DATE_EPOCH has to be whitelisted. The value of the variable 
*must* be calculable at parse time before any task is ran, but in 
practice it's value is only available once the 
__source_date_epoch.txt file is present, which is after parsing. 
This causes the taskhash to be calculated differently during 
parsing and task execution which causes taskhash mismatch errors.




True.

What to do? Would it work to use a different non-whitelisted 
variable in the recipe, eg. SOURCE_DATE_EPOCH_FIXED?




Ya, that would work. You'd have to figure out how to get the 
variable to be included in each taskhash even though it's not 
directly referenced, but I'm sure that's possible.



Another option that's at lot more "magic" would be something like 
this: 
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible=2b524916cf35238ff3deea34017e8a4cd73926cd 



That's really weird, and I'm not sure I like it, but worth a thought.

If it works, it's good. I like the fact that the user can just set 
SOURCE_DATE_EPOCH directly in their recipe.


How about ...

BB_HASHBASE_WHITELIST += "${@'SOURCE_DATE_EPOCH' if not
source_date_epoch_var(d) else ''}"

Ya, that works. The only reason I chose "is None" was in case a user 
really wanted to do


  SOURCE_DATE_EPOCH = "0"


True, best to allow for that.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Overriding SDE_FILE

[Douglas Royds via Openembedded-core]

On 28/02/20 10:49 am, Joshua Watt wrote:



On 2/27/20 3:22 PM, Douglas Royds wrote:


On 28/02/20 5:45 am, Joshua Watt wrote:


On 2/27/20 9:01 AM, Joshua Watt wrote:

On 2/26/20 11:46 PM, Douglas Royds wrote:


On 26/02/20 4:53 am, Jacob Kroon wrote:


On 2/24/20 8:25 AM, Jacob Kroon wrote:

Hi Douglas,

You updated a comment in reproducible_build.bbclass, commit 
e7b891b76954c784f5a93bd0a1c91315673ce40d:


-# Once the value of SOURCE_DATE_EPOCH is determined, it is 
stored in the recipe's ${SDE_FILE}.
+# 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.

+#


But I can't really get this to work. What did work for me was to 
replace "do_create_source_date_epoch_stamp()" in my recipe:


do_create_source_date_epoch_stamp() {
 mkdir -p ${SDE_DIR}
 date -d "1981-03-03" "+%s" > ${SDE_FILE}
}

What is the intended way to achieve the thing I'm trying to do 
here ?




FYI, JPEW has a proposed patch here

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible=d091d2aa53ea417f70c10f5ce89151820c3db9ce 



for allowing a recipe to just set SOURCE_DATE_EPOCH directly.

But maybe that currently is at odds with SOURCE_DATE_EPOCH being 
in BB_HASHBASE_WHITELIST ?


/Jacob



On the surface of it, my comment appears to be just wrong: It does 
make sense to replace do_create_source_date_epoch_stamp() as you 
suggest.


Joshua's proposed patch looks promising:

  * Should the new function not be called first, so that it takes
priority over the git, known files, and youngest file
functions? If someone has explicitly set SOURCE_DATE_EPOCH,
then they want it to take priority.

Having that be the first option makes sense. The only case in which 
that might not work, is if a recipe does something like:


 SOURCE_DATE_EPOCH = "${@my_awesome_sde_calculation(d)}"

e.g. uses a function to get the SDE instead of setting to a fixed 
value, but that's probably going to be extremely rare.




 *



  * As you observe, SOURCE_DATE_EPOCH would need to be removed
from BB_HASHBASE_WHITELIST. I'm not sure why it was in the
whitelist in the first place.

I'm not sure why exactly it is whitelisted; I didn't write the 
original code that whitelisted it, but I've CC'd Juro in case he 
happens to remember.


After a discussion with Richard, we figured out why 
SOURCE_DATE_EPOCH has to be whitelisted. The value of the variable 
*must* be calculable at parse time before any task is ran, but in 
practice it's value is only available once the 
__source_date_epoch.txt file is present, which is after parsing. 
This causes the taskhash to be calculated differently during parsing 
and task execution which causes taskhash mismatch errors.




True.

What to do? Would it work to use a different non-whitelisted variable 
in the recipe, eg. SOURCE_DATE_EPOCH_FIXED?




Ya, that would work. You'd have to figure out how to get the variable 
to be included in each taskhash even though it's not directly 
referenced, but I'm sure that's possible.



Another option that's at lot more "magic" would be something like 
this: 
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible=2b524916cf35238ff3deea34017e8a4cd73926cd 



That's really weird, and I'm not sure I like it, but worth a thought.

If it works, it's good. I like the fact that the user can just set 
SOURCE_DATE_EPOCH directly in their recipe.


How about ...

   BB_HASHBASE_WHITELIST += "${@'SOURCE_DATE_EPOCH' if not
   source_date_epoch_var(d) else ''}"

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Overriding SDE_FILE

[Douglas Royds via Openembedded-core]

On 28/02/20 5:45 am, Joshua Watt wrote:


On 2/27/20 9:01 AM, Joshua Watt wrote:

On 2/26/20 11:46 PM, Douglas Royds wrote:


On 26/02/20 4:53 am, Jacob Kroon wrote:


On 2/24/20 8:25 AM, Jacob Kroon wrote:

Hi Douglas,

You updated a comment in reproducible_build.bbclass, commit 
e7b891b76954c784f5a93bd0a1c91315673ce40d:


-# Once the value of SOURCE_DATE_EPOCH is determined, it is 
stored in the recipe's ${SDE_FILE}.
+# 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.

+#


But I can't really get this to work. What did work for me was to 
replace "do_create_source_date_epoch_stamp()" in my recipe:


do_create_source_date_epoch_stamp() {
 mkdir -p ${SDE_DIR}
 date -d "1981-03-03" "+%s" > ${SDE_FILE}
}

What is the intended way to achieve the thing I'm trying to do here ?



FYI, JPEW has a proposed patch here

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible=d091d2aa53ea417f70c10f5ce89151820c3db9ce 



for allowing a recipe to just set SOURCE_DATE_EPOCH directly.

But maybe that currently is at odds with SOURCE_DATE_EPOCH being in 
BB_HASHBASE_WHITELIST ?


/Jacob



On the surface of it, my comment appears to be just wrong: It does 
make sense to replace do_create_source_date_epoch_stamp() as you 
suggest.


Joshua's proposed patch looks promising:

  * Should the new function not be called first, so that it takes
priority over the git, known files, and youngest file functions?
If someone has explicitly set SOURCE_DATE_EPOCH, then they want
it to take priority.

Having that be the first option makes sense. The only case in which 
that might not work, is if a recipe does something like:


 SOURCE_DATE_EPOCH = "${@my_awesome_sde_calculation(d)}"

e.g. uses a function to get the SDE instead of setting to a fixed 
value, but that's probably going to be extremely rare.




 *



  * As you observe, SOURCE_DATE_EPOCH would need to be removed from
BB_HASHBASE_WHITELIST. I'm not sure why it was in the whitelist
in the first place.

I'm not sure why exactly it is whitelisted; I didn't write the 
original code that whitelisted it, but I've CC'd Juro in case he 
happens to remember.


After a discussion with Richard, we figured out why SOURCE_DATE_EPOCH 
has to be whitelisted. The value of the variable *must* be calculable 
at parse time before any task is ran, but in practice it's value is 
only available once the __source_date_epoch.txt file is present, which 
is after parsing. This causes the taskhash to be calculated 
differently during parsing and task execution which causes taskhash 
mismatch errors.




True.

What to do? Would it work to use a different non-whitelisted variable in 
the recipe, eg. SOURCE_DATE_EPOCH_FIXED?


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Overriding SDE_FILE

[Douglas Royds via Openembedded-core]

On 26/02/20 4:53 am, Jacob Kroon wrote:


On 2/24/20 8:25 AM, Jacob Kroon wrote:

Hi Douglas,

You updated a comment in reproducible_build.bbclass, commit 
e7b891b76954c784f5a93bd0a1c91315673ce40d:


-# Once the value of SOURCE_DATE_EPOCH is determined, it is stored 
in the recipe's ${SDE_FILE}.
+# 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.

+#


But I can't really get this to work. What did work for me was to 
replace "do_create_source_date_epoch_stamp()" in my recipe:


do_create_source_date_epoch_stamp() {
 mkdir -p ${SDE_DIR}
 date -d "1981-03-03" "+%s" > ${SDE_FILE}
}

What is the intended way to achieve the thing I'm trying to do here ?



FYI, JPEW has a proposed patch here

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible=d091d2aa53ea417f70c10f5ce89151820c3db9ce 



for allowing a recipe to just set SOURCE_DATE_EPOCH directly.

But maybe that currently is at odds with SOURCE_DATE_EPOCH being in 
BB_HASHBASE_WHITELIST ?


/Jacob



On the surface of it, my comment appears to be just wrong: It does make 
sense to replace do_create_source_date_epoch_stamp() as you suggest.


Joshua's proposed patch looks promising:

 * Should the new function not be called first, so that it takes
   priority over the git, known files, and youngest file functions? If
   someone has explicitly set SOURCE_DATE_EPOCH, then they want it to
   take priority.
 * As you observe, SOURCE_DATE_EPOCH would need to be removed from
   BB_HASHBASE_WHITELIST. I'm not sure why it was in the whitelist in
   the first place.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] insane: file-rdeps: Readability only

[Douglas Royds via Openembedded-core]

On 4/11/19 11:29 PM, Richard Purdie wrote:


On Mon, 2019-11-04 at 17:52 +1300, Douglas Royds via Openembedded-core
wrote:

Mostly just longer (and hopefully more meaningful) variable names.

"Mostly" - what else is in there?



Readability changes only.

 * Longer variable names
 * Reworded some comments
 * Some extra blank lines (as visual paragraph breaks)

I replaced this comment + hard-coded string-length:

   # We already know it starts with FILERDEPENDS_
   filerdepends[subkey] = key[13:]

With this one-liner:

   unsatisfied_rdepends[target_dependency] =
   executable_that_rdepends[len('FILERDEPENDS_'):]


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] insane: file-rdeps: Readability only

[Douglas Royds via Openembedded-core]

Mostly just longer (and hopefully more meaningful) variable names.

Signed-off-by: Douglas Royds 
---
 meta/classes/insane.bbclass | 81 +++--
 1 file changed, 42 insertions(+), 39 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 9605ac2bae..f80abebbac 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -707,57 +707,60 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, 
taskdeps, packages, d):
 package_qa_handle_error("build-deps", error_msg, d)
 
 if "file-rdeps" not in skip:
-ignored_file_rdeps = set(['/bin/sh', '/usr/bin/env', 
'rtld(GNU_HASH)'])
+ignored_executable_rdeps = set(['/bin/sh', '/usr/bin/env', 
'rtld(GNU_HASH)'])
 if bb.data.inherits_class('nativesdk', d):
-ignored_file_rdeps |= set(['/bin/bash', '/usr/bin/perl', 
'perl'])
-# For Saving the FILERDEPENDS
-filerdepends = {}
-rdep_data = oe.packagedata.read_subpkgdata(pkg, d)
-for key in rdep_data:
-if key.startswith("FILERDEPENDS_"):
-for subkey in bb.utils.explode_deps(rdep_data[key]):
-if subkey not in ignored_file_rdeps and \
-not subkey.startswith('perl('):
-# We already know it starts with FILERDEPENDS_
-filerdepends[subkey] = key[13:]
-
-if filerdepends:
-done = rdepends[:]
-# Add the rprovides of itself
-if pkg not in done:
-done.insert(0, pkg)
+ignored_executable_rdeps |= set(['/bin/bash', '/usr/bin/perl', 
'perl'])
+
+# A dictionary of libs (or other providers) and one executable 
that depends on each
+unsatisfied_rdepends = {}
+current_pkg_rdep_data = oe.packagedata.read_subpkgdata(pkg, d)
+for executable_that_rdepends in current_pkg_rdep_data:
+if executable_that_rdepends.startswith("FILERDEPENDS_"):
+for target_dependency in 
bb.utils.explode_deps(current_pkg_rdep_data[executable_that_rdepends]):
+if target_dependency not in ignored_executable_rdeps \
+   and not target_dependency.startswith('perl('):
+unsatisfied_rdepends[target_dependency] = 
executable_that_rdepends[len('FILERDEPENDS_'):]
+
+if unsatisfied_rdepends:
+rdep_packages_to_consider = rdepends[:]
+# Each package effectively rprovides itself
+if pkg not in rdep_packages_to_consider:
+rdep_packages_to_consider.insert(0, pkg)
 
 # The python is not a package, but python-core provides it, so
 # skip checking /usr/bin/python if python is in the rdeps, in
 # case there is a RDEPENDS_pkg = "python" in the recipe.
-for py in [ d.getVar('MLPREFIX') + "python", "python" ]:
-if py in done:
-filerdepends.pop("/usr/bin/python",None)
-done.remove(py)
-for rdep in done:
-# The file dependencies may contain package names, e.g.,
-# perl
-filerdepends.pop(rdep,None)
-
-# For Saving the FILERPROVIDES, RPROVIDES and FILES_INFO
-rdep_data = oe.packagedata.read_subpkgdata(rdep, d)
-for key in rdep_data:
+for python_package in [ d.getVar('MLPREFIX') + "python", 
"python" ]:
+if python_package in rdep_packages_to_consider:
+unsatisfied_rdepends.pop("/usr/bin/python",None)
+rdep_packages_to_consider.remove(python_package)
+
+for dependent_package in rdep_packages_to_consider:
+# Dependencies might contain package names, e.g. perl
+unsatisfied_rdepends.pop(dependent_package,None)
+
+dependent_pkg_rdep_data = 
oe.packagedata.read_subpkgdata(dependent_package, d)
+for key in dependent_pkg_rdep_data:
 if key.startswith("FILERPROVIDES_") or 
key.startswith("RPROVIDES_"):
-for subkey in 
bb.utils.explode_deps(rdep_data[key]):
-filerdepends.pop(subkey,None)
-# Add the files list to the rprovides
+for satisfied_lib_or_provider in 
bb.utils.explode_deps(dependent_pkg_rdep_data[key]):
+
unsatisfied_rdepends.pop(satisfied_lib_or_provider,None)
+
+# FILES_INFO lists all files this dependent package 
provides
 if key == "FILES_INFO":
  

[OE-core] [PATCH] insane: file-rdeps: Readability only

[Douglas Royds via Openembedded-core]

Mostly just longer (and hopefully more meaningful) variable names.

Signed-off-by: Douglas Royds 
---
 meta/classes/insane.bbclass | 84 -
 1 file changed, 45 insertions(+), 39 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 9605ac2bae..b72740e5d4 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -707,57 +707,60 @@ def package_qa_check_rdepends(pkg, pkgdest, skip, 
taskdeps, packages, d):
 package_qa_handle_error("build-deps", error_msg, d)
 
 if "file-rdeps" not in skip:
-ignored_file_rdeps = set(['/bin/sh', '/usr/bin/env', 
'rtld(GNU_HASH)'])
+ignored_executable_rdeps = set(['/bin/sh', '/usr/bin/env', 
'rtld(GNU_HASH)'])
 if bb.data.inherits_class('nativesdk', d):
-ignored_file_rdeps |= set(['/bin/bash', '/usr/bin/perl', 
'perl'])
-# For Saving the FILERDEPENDS
-filerdepends = {}
-rdep_data = oe.packagedata.read_subpkgdata(pkg, d)
-for key in rdep_data:
-if key.startswith("FILERDEPENDS_"):
-for subkey in bb.utils.explode_deps(rdep_data[key]):
-if subkey not in ignored_file_rdeps and \
-not subkey.startswith('perl('):
-# We already know it starts with FILERDEPENDS_
-filerdepends[subkey] = key[13:]
-
-if filerdepends:
-done = rdepends[:]
-# Add the rprovides of itself
-if pkg not in done:
-done.insert(0, pkg)
+ignored_executable_rdeps |= set(['/bin/bash', '/usr/bin/perl', 
'perl'])
+
+# A dictionary of libs (or other providers) and one executable 
that depends on each
+unsatisfied_rdepends = {}
+current_pkg_rdep_data = oe.packagedata.read_subpkgdata(pkg, d)
+for executable_that_rdepends in current_pkg_rdep_data:
+if executable_that_rdepends.startswith("FILERDEPENDS_"):
+for target_dependency in 
bb.utils.explode_deps(current_pkg_rdep_data[executable_that_rdepends]):
+if target_dependency not in ignored_executable_rdeps \
+   and not target_dependency.startswith('perl('):
+unsatisfied_rdepends[target_dependency] = 
executable_that_rdepends[len('FILERDEPENDS_'):]
+
+if unsatisfied_rdepends:
+rdep_packages_to_consider = rdepends[:]
+# Each package effectively rprovides itself
+if pkg not in rdep_packages_to_consider:
+rdep_packages_to_consider.insert(0, pkg)
 
 # The python is not a package, but python-core provides it, so
 # skip checking /usr/bin/python if python is in the rdeps, in
 # case there is a RDEPENDS_pkg = "python" in the recipe.
-for py in [ d.getVar('MLPREFIX') + "python", "python" ]:
-if py in done:
-filerdepends.pop("/usr/bin/python",None)
-done.remove(py)
-for rdep in done:
-# The file dependencies may contain package names, e.g.,
-# perl
-filerdepends.pop(rdep,None)
-
-# For Saving the FILERPROVIDES, RPROVIDES and FILES_INFO
-rdep_data = oe.packagedata.read_subpkgdata(rdep, d)
-for key in rdep_data:
+for python_package in [ d.getVar('MLPREFIX') + "python", 
"python" ]:
+if python_package in rdep_packages_to_consider:
+unsatisfied_rdepends.pop("/usr/bin/python",None)
+rdep_packages_to_consider.remove(python_package)
+
+for dependent_package in rdep_packages_to_consider:
+# Dependencies might contain package names, e.g. perl
+unsatisfied_rdepends.pop(dependent_package,None)
+
+dependent_pkg_rdep_data = 
oe.packagedata.read_subpkgdata(dependent_package, d)
+for key in dependent_pkg_rdep_data:
 if key.startswith("FILERPROVIDES_") or 
key.startswith("RPROVIDES_"):
-for subkey in 
bb.utils.explode_deps(rdep_data[key]):
-filerdepends.pop(subkey,None)
-# Add the files list to the rprovides
+for satisfied_lib_or_provider in 
bb.utils.explode_deps(dependent_pkg_rdep_data[key]):
+
unsatisfied_rdepends.pop(satisfied_lib_or_provider,None)
+
+# FILES_INFO lists all files this dependent package 
provides
 if key == "FILES_INFO":
  

[OE-core] [PATCH] icecc: Don't use icecc when INHIBIT_DEFAULT_DEPS is set

[Douglas Royds via Openembedded-core]

We don't have a compiler, so no icecc.
Silences a spew of warnings of the form:

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

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

diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index e74d798fd0..bc3d6f4cc8 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -138,6 +138,10 @@ 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.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] icecc: Export ICECC_CC and friends via wrapper-script

[Douglas Royds via Openembedded-core]

By exporting ICECC_CC, ICECC_CXX, and ICECC_VERSION in a wrapper-script,
and putting this wrapper-script in the PATH, the Makefiles generated by CMake or
the autotools are able to function correctly outside of bitbake.
This provides a convenient developer workflow in which the
modify-compile-unittest cycle can happen directly in the ${B} directory.

The `rm -f $ICE_PATH/$compiler` line is transitional,
and can go at some later date (October 2020 or later, perhaps).

Signed-off-by: Douglas Royds 
---
 meta/classes/icecc.bbclass | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index 9dbb4b1559..e74d798fd0 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -352,17 +352,6 @@ set_icecc_env() {
 return
 fi
 
-# Create symlinks to icecc in the recipe-sysroot directory
-mkdir -p ${ICE_PATH}
-if [ -n "${KERNEL_CC}" ]; then
-compilers="${@get_cross_kernel_cc(bb,d)}"
-else
-compilers="${HOST_PREFIX}gcc ${HOST_PREFIX}g++"
-fi
-for compiler in $compilers; do
-ln -sf ${ICECC_BIN} ${ICE_PATH}/$compiler
-done
-
 ICECC_CC="${@icecc_get_and_check_tool(bb, d, "gcc")}"
 ICECC_CXX="${@icecc_get_and_check_tool(bb, d, "g++")}"
 # cannot use icecc_get_and_check_tool here because it assumes as without 
target_sys prefix
@@ -381,6 +370,26 @@ set_icecc_env() {
 return
 fi
 
+# Create symlinks to icecc and wrapper-scripts in the recipe-sysroot 
directory
+mkdir -p $ICE_PATH/symlinks
+if [ -n "${KERNEL_CC}" ]; then
+compilers="${@get_cross_kernel_cc(bb,d)}"
+else
+compilers="${HOST_PREFIX}gcc ${HOST_PREFIX}g++"
+fi
+for compiler in $compilers; do
+ln -sf $ICECC_BIN $ICE_PATH/symlinks/$compiler
+rm -f $ICE_PATH/$compiler
+cat <<-__EOF__ > $ICE_PATH/$compiler
+   #!/bin/sh -e
+   export ICECC_VERSION=$ICECC_VERSION
+   export ICECC_CC=$ICECC_CC
+   export ICECC_CXX=$ICECC_CXX
+   $ICE_PATH/symlinks/$compiler "\$@"
+   __EOF__
+chmod 775 $ICE_PATH/$compiler
+done
+
 ICECC_AS="`${ICECC_CC} -print-prog-name=as`"
 # for target recipes should return something like:
 # 
/OE/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/arm920tt-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.8.2/as
@@ -413,7 +422,6 @@ set_icecc_env() {
 export CCACHE_PATH="$PATH"
 export CCACHE_DISABLE="1"
 
-export ICECC_VERSION ICECC_CC ICECC_CXX
 export PATH="$ICE_PATH:$PATH"
 
 bbnote "Using icecc path: $ICE_PATH"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/5] cmake.bbclass: append includedir to implicit include dirs

[Douglas Royds via Openembedded-core]

An error in my analysis below: We *do* delete the dependency files in 
the in-tree build case as well. The side-effect is masked in both 
in-tree and out-of-tree build cases except here at Tait, where we don't 
delete the entire build at configure time, due to a 20min+ rebuild time, 
even with the benefit of icecc.


The rest of my concern still applies: This setting has no effect in the 
target case, and only an unfortunate side effect in the -native case. 
I'm not clear what the benefit is.



On 11/07/19 2:51 PM, Douglas Royds wrote:

This commit is having an unintended side-effect in the -native (and 
probably nativesdk) case.


In the target build, $includedir is normally /usr/include, 
fully-qualified. This path is already in CMake's list of implicit 
include directories, and we don't include any header files from the 
build PC's /usr/include in a target build in any case. This addition 
to CMAKE_C/CXX_IMPLICIT_INCLUDE_DIRECTORIES has no effect.


In the -native case, the $includedir is set to STAGING_INCDIR_NATIVE, 
but this path has already been added to the BUILD_CPPFLAGS as a system 
include directory, so there will already be no warnings for any header 
file in the STAGING_INCDIR_NATIVE.


There is a nasty side-effect in the -native case: CMake excludes 
headers in the CMAKE_C/CXX_IMPLICIT_INCLUDE_DIRECTORIES from its 
generated dependency files, meaning that a change in any library 
header file will not trigger a recompile of affected source files in 
the dependent CMake component. In out-of-tree builds this isn't a 
problem, as cmake.bbclass deletes the *entire* ${B} directory at 
configure time, but where this is not the case, the build breaks with 
any change in library headers.


I haven't examined the nativesdk case. The $includedir is set off to 
$SDKPATHNATIVE/usr/include, but this path is not added as a system 
include dir. The same problem will apply as in the -native case, that 
CMake will not generate dependencies for headers staged in the 
SDKPATHNATIVE.


Was nativesdk perhaps the intended case for this commit? Is there a 
better way to silence warnings in this case? Do we need to silence 
library header warnings at all? Should we instead add 
$SDKPATHNATIVE/usr/include as a system include dir via the 
BUILDSDK_CPPFLAGS?


I examined this problem using the Unix Makefiles generator. CMake 
appears to equally exclude these headers from the ninja *.o.d 
dependency files, though I haven't examined it closely.



On 30/11/18 1:21 AM, Mikko Rapeli wrote:


From: Michael Ho 

This resolves issues with paths being marked as system includes that
differ from /usr/include but are considered implicit by the toolchain.
This enables developers to add directories to system includes
to supress compiler compiler warnings from them.

Signed-off-by: Michael Ho 
Cc: Pascal Bach 
---
  meta/classes/cmake.bbclass | 4 
  1 file changed, 4 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a98..485aea6 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,6 +108,10 @@ list(APPEND CMAKE_MODULE_PATH 
"${STAGING_DATADIR}/cmake/Modules/")

  # add for non /usr/lib libdir, e.g. /usr/lib64
  set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
  +# add include dir to implicit includes in case it differs from 
/usr/include

+list(APPEND CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
+list(APPEND CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
+
  EOF
  }





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/5] cmake.bbclass: append includedir to implicit include dirs

[Douglas Royds via Openembedded-core]

This commit is having an unintended side-effect in the -native (and 
probably nativesdk) case.


In the target build, $includedir is normally /usr/include, 
fully-qualified. This path is already in CMake's list of implicit 
include directories, and we don't include any header files from the 
build PC's /usr/include in a target build in any case. This addition to 
CMAKE_C/CXX_IMPLICIT_INCLUDE_DIRECTORIES has no effect.


In the -native case, the $includedir is set to STAGING_INCDIR_NATIVE, 
but this path has already been added to the BUILD_CPPFLAGS as a system 
include directory, so there will already be no warnings for any header 
file in the STAGING_INCDIR_NATIVE.


There is a nasty side-effect in the -native case: CMake excludes headers 
in the CMAKE_C/CXX_IMPLICIT_INCLUDE_DIRECTORIES from its generated 
dependency files, meaning that a change in any library header file will 
not trigger a recompile of affected source files in the dependent CMake 
component. In out-of-tree builds this isn't a problem, as cmake.bbclass 
deletes the *entire* ${B} directory at configure time, but where this is 
not the case, the build breaks with any change in library headers.


I haven't examined the nativesdk case. The $includedir is set off to 
$SDKPATHNATIVE/usr/include, but this path is not added as a system 
include dir. The same problem will apply as in the -native case, that 
CMake will not generate dependencies for headers staged in the 
SDKPATHNATIVE.


Was nativesdk perhaps the intended case for this commit? Is there a 
better way to silence warnings in this case? Do we need to silence 
library header warnings at all? Should we instead add 
$SDKPATHNATIVE/usr/include as a system include dir via the 
BUILDSDK_CPPFLAGS?


I examined this problem using the Unix Makefiles generator. CMake 
appears to equally exclude these headers from the ninja *.o.d dependency 
files, though I haven't examined it closely.



On 30/11/18 1:21 AM, Mikko Rapeli wrote:


From: Michael Ho 

This resolves issues with paths being marked as system includes that
differ from /usr/include but are considered implicit by the toolchain.
This enables developers to add directories to system includes
to supress compiler compiler warnings from them.

Signed-off-by: Michael Ho 
Cc: Pascal Bach 
---
  meta/classes/cmake.bbclass | 4 
  1 file changed, 4 insertions(+)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fd40a98..485aea6 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,6 +108,10 @@ list(APPEND CMAKE_MODULE_PATH 
"${STAGING_DATADIR}/cmake/Modules/")
  # add for non /usr/lib libdir, e.g. /usr/lib64
  set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
  
+# add include dir to implicit includes in case it differs from /usr/include

+list(APPEND CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
+list(APPEND CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES ${includedir})
+
  EOF
  }
  



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] The state of reproducible Builds

[Douglas Royds via Openembedded-core]

On 2/07/19 3:58 AM, Joshua Watt wrote:

1. Testing RPM and IPK package formats. I think RPMs will be pretty 
easy; IPKs might be more challenging since AFAIK the tools that make 
them don't generate reproducible output to begin with.



This has not been my experience. I have been building reproducible ipks, 
indeed, it is the hashsums of the ipks that I've been examining. In most 
cases, the correct SOURCE_DATE_EPOCH is enough, but there have been 
cases where I've had to correct upstream projects to cope with the 
SOURCE_DATE_EPOCH or avoid the effect of differing uname settings.



1. HOSTTOOLS differences. There are a lot of tools listed in 
HOSTTOOLS, and unfortunately some of them have version dependent 
output and are used for target builds (the one I've currently stumbled 
upon is pod2man, but I'm sure there are others). Unfortunately, one 
could probably argue that HOSTTOOLS is somewhat antithetical to the 
above statement, at least in regard to target builds. Any host tool 
output that "leaks" into the target build output can result in a 
non-reproducible build across hosts, and possibly should be avoided; 
the alternative is to use (or mandate) the corresponding -native 
recipe that provides that tool as a DEPENDS so that the controlled 
internally built version is used instead. Note that this only really 
applies target builds, not -native (or nativesdk right now). -native 
recipes would obviously need more HOSTTOOLS to help bootstrap the 
system. I suspect this would require reworking how HOSTOOLS works so 
that they can be split into two categories somehow; the tools that 
have "ubiquitous and stable" interfaces and are fine for all recipes 
(e.g. cat, sed, true, rm, etc.) and those that are variable and should 
only be used for -native builds (e.g. pod2man, rpcgen(?), chrpath(?), 
tar(?)... others?). Anyone have thoughts on this?



Perhaps reproducibility is the decision-point for adding a tool to the 
HOSTTOOLS: If the precise version of the tool has no impact on 
reproducibility (eg. cat, sed, and even gawk), it is a good candidate 
for the HOSTTOOLS. pod2man shouldn't be in the HOSTTOOLS, because we 
need to control the version.


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] json-c: Backport --disable-werror patch to allow compilation under icecc

[Douglas Royds via Openembedded-core]

icecc preprocesses source files locally before shipping them off to be compiled
on remote hosts. This preprocessing removes comments, including /* fallthough */
comments in switch statements that normally prevent an implicit-fallthrough
warning, see https://github.com/icecc/icecream/issues/419

Rather than turning off -Werror, the upstream project has implemented a
configure option, --disable-werror, in response to Ross's
https://github.com/json-c/json-c/issues/489

This patch from
https://github.com/json-c/json-c/commit/21c886534f8927fdc0fb5f8647394f3e0e0874b8

Upstream-Status: Backport [Not yet released]
Signed-off-by: Douglas Royds 
---
 ...d-disable-werror-option-to-configure.patch | 45 +++
 meta/recipes-devtools/json-c/json-c_0.13.1.bb |  8 +++-
 2 files changed, 51 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-devtools/json-c/json-c/add-disable-werror-option-to-configure.patch

diff --git 
a/meta/recipes-devtools/json-c/json-c/add-disable-werror-option-to-configure.patch
 
b/meta/recipes-devtools/json-c/json-c/add-disable-werror-option-to-configure.patch
new file mode 100644
index 00..0c20c8458a
--- /dev/null
+++ 
b/meta/recipes-devtools/json-c/json-c/add-disable-werror-option-to-configure.patch
@@ -0,0 +1,45 @@
+json-c: Backport --disable-werror patch to allow compilation under icecc
+
+icecc preprocesses source files locally before shipping them off to be compiled
+on remote hosts. This preprocessing removes comments, including /* fallthough 
*/
+comments in switch statements that normally prevent an implicit-fallthrough
+warning, see https://github.com/icecc/icecream/issues/419
+
+Rather than turning off -Werror, the upstream project has implemented a
+configure option, --disable-werror, in response to Ross's
+https://github.com/json-c/json-c/issues/489
+
+This patch from
+https://github.com/json-c/json-c/commit/21c886534f8927fdc0fb5f8647394f3e0e0874b8
+
+Upstream-Status: Backport [Not yet released]
+Signed-off-by: Douglas Royds 
+
+From 21c886534f8927fdc0fb5f8647394f3e0e0874b8 Mon Sep 17 00:00:00 2001
+From: Pierce Lopez 
+Date: Sun, 9 Jun 2019 10:52:08 -0400
+Subject: [PATCH] build: add --disable-werror option to configure
+
+to omit -Werror compiler option
+---
+ configure.ac | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 272ea6af9c..798fd5b747 100644
+--- a/configure.ac
 b/configure.ac
+@@ -165,7 +165,12 @@ AS_IF([test "x$enable_Bsymbolic" = "xcheck"],
+ AS_IF([test "x$enable_Bsymbolic" = "xyes"], 
[JSON_BSYMBOLIC_LDFLAGS=-Wl[,]-Bsymbolic-functions])
+ AC_SUBST(JSON_BSYMBOLIC_LDFLAGS)
+ 
+-AX_APPEND_COMPILE_FLAGS([-Wall -Werror -Wcast-qual 
-Wno-error=deprecated-declarations])
++AC_ARG_ENABLE([werror],
++AS_HELP_STRING([--disable-werror], [avoid treating compiler warnings as 
fatal errors]))
++
++AS_IF([test "x$enable_werror" != "xno"], [AX_APPEND_COMPILE_FLAGS([-Werror])])
++
++AX_APPEND_COMPILE_FLAGS([-Wall -Wcast-qual 
-Wno-error=deprecated-declarations])
+ AX_APPEND_COMPILE_FLAGS([-Wextra -Wwrite-string -Wno-unused-parameter])
+ AX_APPEND_COMPILE_FLAGS([-D_GNU_SOURCE])
+ 
diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
index 5b10e68297..9d8f2e7870 100644
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
@@ -4,7 +4,9 @@ HOMEPAGE = "https://github.com/json-c/json-c/wiki;
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"
 
-SRC_URI = "https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;
+SRC_URI = "https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz \
+   file://add-disable-werror-option-to-configure.patch \
+   "
 SRC_URI[md5sum] = "04969ad59cc37bddd83741a08b98f350"
 SRC_URI[sha256sum] = 
"b87e608d4d3f7bfdd36ef78d56d53c74e66ab278d318b71e6002a369d36f4873"
 
@@ -20,7 +22,9 @@ RPROVIDES_${PN} = "libjson"
 
 inherit autotools
 
-EXTRA_OECONF = "--enable-rdrand"
+EXTRA_OECONF = "--disable-werror \
+--enable-rdrand \
+"
 
 do_configure_prepend() {
 # Clean up autoconf cruft that should not be in the tarball
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] json-c: update to current upstream head, with --disable-werror

[Douglas Royds via Openembedded-core]

On 11/06/19 4:57 PM, Adrian Bunk wrote:


On Tue, Jun 11, 2019 at 03:12:09PM +1200, Douglas Royds via Openembedded-core 
wrote:

On 11/06/19 3:05 PM, Kang Kai wrote:


On 2019/6/11 上午11:04, Douglas Royds wrote:

On 11/06/19 2:46 PM, Kang Kai wrote:

...

Use option '-M' of git format-patch may make the patch more
clear. And why not just backport the 'disable-werror' commit?


Re '-M': True, fair point.

Re the backport: There hasn't been a release in over a year, they
don't seem to have any plans to do so (see
https://github.com/json-c/json-c/issues/487), and this was easier.
If you have a substantial objection, yes, I could submit it again
with a patch instead of the update.

Just consider footprint, git repo will take more space than tar ball.
But no substantial objection.


We do also lose the RECIPE_UPSTREAM_VERSION functionality by switching to
the git HEAD, ie. there'll be no notification when they do (eventually)
release a new version.

I'm in two minds. Opinions?

The biggest worry is actually whether some random git snapshot is as
stable as a release.

Unless there is a good reason why a git snapshot is better than
release plus backported patch, the default should be to not switch
to using a git snapshot.

Starting to follow git snapshots brings the risk of frequent regressions
since it follows the latest upstream development.



Fair enough, patch it is. Watch this space.

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] json-c: update to current upstream head, with --disable-werror

[Douglas Royds via Openembedded-core]

On 11/06/19 3:05 PM, Kang Kai wrote:


On 2019/6/11 上午11:04, Douglas Royds wrote:

On 11/06/19 2:46 PM, Kang Kai wrote:


On 2019/6/11 上午9:57, Douglas Royds via Openembedded-core wrote:

Upstream json-c haven't made a release since March 2018.
Adopt the current HEAD revision, pulling it directly from git.

icecc preprocesses source files locally before shipping them off to 
be compiled
on remote hosts. This preprocessing removes comments, including /* 
fallthough */
comments in switch statements that normally prevent an 
implicit-fallthrough

warning, see https://github.com/icecc/icecream/issues/419

Rather than turning off -Werror by patching configure.ac, the 
upstream project
has implemented a configure option, --disable-werror, in response 
to Ross's

https://github.com/json-c/json-c/issues/489

Signed-off-by: Douglas Royds 
---
  meta/recipes-devtools/json-c/json-c_0.13.1.bb | 30 
---

  meta/recipes-devtools/json-c/json-c_git.bb    | 19 


Use option '-M' of git format-patch may make the patch more clear. 
And why not just backport the 'disable-werror' commit?



Re '-M': True, fair point.

Re the backport: There hasn't been a release in over a year, they 
don't seem to have any plans to do so (see 
https://github.com/json-c/json-c/issues/487), and this was easier. If 
you have a substantial objection, yes, I could submit it again with a 
patch instead of the update.


Just consider footprint, git repo will take more space than tar ball. 
But no substantial objection.



We do also lose the RECIPE_UPSTREAM_VERSION functionality by switching 
to the git HEAD, ie. there'll be no notification when they do 
(eventually) release a new version.


I'm in two minds. Opinions?




Kai






Regards,
Kai



  2 files changed, 19 insertions(+), 30 deletions(-)
  delete mode 100644 meta/recipes-devtools/json-c/json-c_0.13.1.bb
  create mode 100644 meta/recipes-devtools/json-c/json-c_git.bb

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb

deleted file mode 100644
index 5b10e68297..00
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-SUMMARY = "C bindings for apps which will manipulate JSON data"
-DESCRIPTION = "JSON-C implements a reference counting object model 
that allows you to easily construct JSON objects in C."

-HOMEPAGE = "https://github.com/json-c/json-c/wiki;
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"

-
-SRC_URI = 
"https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;

-SRC_URI[md5sum] = "04969ad59cc37bddd83741a08b98f350"
-SRC_URI[sha256sum] = 
"b87e608d4d3f7bfdd36ef78d56d53c74e66ab278d318b71e6002a369d36f4873"

-
-UPSTREAM_CHECK_REGEX = "json-c-(?P\d+(\.\d+)+).tar"
-# json-c releases page is fetching the list of releases in some 
weird XML format
-# from https://s3.amazonaws.com/json-c_releases and processes it 
with javascript :-/
-#UPSTREAM_CHECK_URI = 
"https://s3.amazonaws.com/json-c_releases/releases/index.html;

-RECIPE_UPSTREAM_VERSION = "0.13.1"
-RECIPE_UPSTREAM_DATE = "Mar 04, 2018"
-CHECK_DATE = "May 02, 2018"
-
-RPROVIDES_${PN} = "libjson"
-
-inherit autotools
-
-EXTRA_OECONF = "--enable-rdrand"
-
-do_configure_prepend() {
-    # Clean up autoconf cruft that should not be in the tarball
-    rm -f ${S}/config.status
-}
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/json-c/json-c_git.bb 
b/meta/recipes-devtools/json-c/json-c_git.bb

new file mode 100644
index 00..07daa5ba11
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_git.bb
@@ -0,0 +1,19 @@
+SUMMARY = "C bindings for apps which will manipulate JSON data"
+DESCRIPTION = "JSON-C implements a reference counting object model 
that allows you to easily construct JSON objects in C."

+HOMEPAGE = "https://github.com/json-c/json-c/wiki;
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"

+
+SRC_URI = "git://github.com/json-c/json-c.git"
+SRCREV = "07ea04e65193c3e5c902c5b79421d5fa48ff67c7"
+S = "${WORKDIR}/git"
+
+RPROVIDES_${PN} = "libjson"
+
+inherit autotools
+
+EXTRA_OECONF = "--disable-werror \
+    --enable-rdrand \
+    "
+
+BBCLASSEXTEND = "native nativesdk"










--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] json-c: update to current upstream head, with --disable-werror

[Douglas Royds via Openembedded-core]

On 11/06/19 2:46 PM, Kang Kai wrote:


On 2019/6/11 上午9:57, Douglas Royds via Openembedded-core wrote:

Upstream json-c haven't made a release since March 2018.
Adopt the current HEAD revision, pulling it directly from git.

icecc preprocesses source files locally before shipping them off to 
be compiled
on remote hosts. This preprocessing removes comments, including /* 
fallthough */
comments in switch statements that normally prevent an 
implicit-fallthrough

warning, see https://github.com/icecc/icecream/issues/419

Rather than turning off -Werror by patching configure.ac, the 
upstream project
has implemented a configure option, --disable-werror, in response to 
Ross's

https://github.com/json-c/json-c/issues/489

Signed-off-by: Douglas Royds 
---
  meta/recipes-devtools/json-c/json-c_0.13.1.bb | 30 ---
  meta/recipes-devtools/json-c/json-c_git.bb    | 19 


Use option '-M' of git format-patch may make the patch more clear. And 
why not just backport the 'disable-werror' commit?



Re '-M': True, fair point.

Re the backport: There hasn't been a release in over a year, they don't 
seem to have any plans to do so (see 
https://github.com/json-c/json-c/issues/487), and this was easier. If 
you have a substantial objection, yes, I could submit it again with a 
patch instead of the update.





Regards,
Kai



  2 files changed, 19 insertions(+), 30 deletions(-)
  delete mode 100644 meta/recipes-devtools/json-c/json-c_0.13.1.bb
  create mode 100644 meta/recipes-devtools/json-c/json-c_git.bb

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb

deleted file mode 100644
index 5b10e68297..00
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-SUMMARY = "C bindings for apps which will manipulate JSON data"
-DESCRIPTION = "JSON-C implements a reference counting object model 
that allows you to easily construct JSON objects in C."

-HOMEPAGE = "https://github.com/json-c/json-c/wiki;
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"

-
-SRC_URI = 
"https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;

-SRC_URI[md5sum] = "04969ad59cc37bddd83741a08b98f350"
-SRC_URI[sha256sum] = 
"b87e608d4d3f7bfdd36ef78d56d53c74e66ab278d318b71e6002a369d36f4873"

-
-UPSTREAM_CHECK_REGEX = "json-c-(?P\d+(\.\d+)+).tar"
-# json-c releases page is fetching the list of releases in some 
weird XML format
-# from https://s3.amazonaws.com/json-c_releases and processes it 
with javascript :-/
-#UPSTREAM_CHECK_URI = 
"https://s3.amazonaws.com/json-c_releases/releases/index.html;

-RECIPE_UPSTREAM_VERSION = "0.13.1"
-RECIPE_UPSTREAM_DATE = "Mar 04, 2018"
-CHECK_DATE = "May 02, 2018"
-
-RPROVIDES_${PN} = "libjson"
-
-inherit autotools
-
-EXTRA_OECONF = "--enable-rdrand"
-
-do_configure_prepend() {
-    # Clean up autoconf cruft that should not be in the tarball
-    rm -f ${S}/config.status
-}
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/json-c/json-c_git.bb 
b/meta/recipes-devtools/json-c/json-c_git.bb

new file mode 100644
index 00..07daa5ba11
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_git.bb
@@ -0,0 +1,19 @@
+SUMMARY = "C bindings for apps which will manipulate JSON data"
+DESCRIPTION = "JSON-C implements a reference counting object model 
that allows you to easily construct JSON objects in C."

+HOMEPAGE = "https://github.com/json-c/json-c/wiki;
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"

+
+SRC_URI = "git://github.com/json-c/json-c.git"
+SRCREV = "07ea04e65193c3e5c902c5b79421d5fa48ff67c7"
+S = "${WORKDIR}/git"
+
+RPROVIDES_${PN} = "libjson"
+
+inherit autotools
+
+EXTRA_OECONF = "--disable-werror \
+    --enable-rdrand \
+    "
+
+BBCLASSEXTEND = "native nativesdk"





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] json-c: Disable icecc to avoid implicit-fallthrough warning as error

[Douglas Royds via Openembedded-core]

Please disregard this one, I've sent a recipe update to pick up the new 
--disable-werror configure option.


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] json-c: update to current upstream head, with --disable-werror

[Douglas Royds via Openembedded-core]

Upstream json-c haven't made a release since March 2018.
Adopt the current HEAD revision, pulling it directly from git.

icecc preprocesses source files locally before shipping them off to be compiled
on remote hosts. This preprocessing removes comments, including /* fallthough */
comments in switch statements that normally prevent an implicit-fallthrough
warning, see https://github.com/icecc/icecream/issues/419

Rather than turning off -Werror by patching configure.ac, the upstream project
has implemented a configure option, --disable-werror, in response to Ross's
https://github.com/json-c/json-c/issues/489

Signed-off-by: Douglas Royds 
---
 meta/recipes-devtools/json-c/json-c_0.13.1.bb | 30 ---
 meta/recipes-devtools/json-c/json-c_git.bb| 19 
 2 files changed, 19 insertions(+), 30 deletions(-)
 delete mode 100644 meta/recipes-devtools/json-c/json-c_0.13.1.bb
 create mode 100644 meta/recipes-devtools/json-c/json-c_git.bb

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
deleted file mode 100644
index 5b10e68297..00
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-SUMMARY = "C bindings for apps which will manipulate JSON data"
-DESCRIPTION = "JSON-C implements a reference counting object model that allows 
you to easily construct JSON objects in C."
-HOMEPAGE = "https://github.com/json-c/json-c/wiki;
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"
-
-SRC_URI = "https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;
-SRC_URI[md5sum] = "04969ad59cc37bddd83741a08b98f350"
-SRC_URI[sha256sum] = 
"b87e608d4d3f7bfdd36ef78d56d53c74e66ab278d318b71e6002a369d36f4873"
-
-UPSTREAM_CHECK_REGEX = "json-c-(?P\d+(\.\d+)+).tar"
-# json-c releases page is fetching the list of releases in some weird XML 
format
-# from https://s3.amazonaws.com/json-c_releases and processes it with 
javascript :-/
-#UPSTREAM_CHECK_URI = 
"https://s3.amazonaws.com/json-c_releases/releases/index.html;
-RECIPE_UPSTREAM_VERSION = "0.13.1"
-RECIPE_UPSTREAM_DATE = "Mar 04, 2018"
-CHECK_DATE = "May 02, 2018"
-
-RPROVIDES_${PN} = "libjson"
-
-inherit autotools
-
-EXTRA_OECONF = "--enable-rdrand"
-
-do_configure_prepend() {
-# Clean up autoconf cruft that should not be in the tarball
-rm -f ${S}/config.status
-}
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/json-c/json-c_git.bb 
b/meta/recipes-devtools/json-c/json-c_git.bb
new file mode 100644
index 00..07daa5ba11
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_git.bb
@@ -0,0 +1,19 @@
+SUMMARY = "C bindings for apps which will manipulate JSON data"
+DESCRIPTION = "JSON-C implements a reference counting object model that allows 
you to easily construct JSON objects in C."
+HOMEPAGE = "https://github.com/json-c/json-c/wiki;
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"
+
+SRC_URI = "git://github.com/json-c/json-c.git"
+SRCREV = "07ea04e65193c3e5c902c5b79421d5fa48ff67c7"
+S = "${WORKDIR}/git"
+
+RPROVIDES_${PN} = "libjson"
+
+inherit autotools
+
+EXTRA_OECONF = "--disable-werror \
+--enable-rdrand \
+"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] json-c: Disable icecc to avoid implicit-fallthrough warning as error

[Douglas Royds via Openembedded-core]

icecc preprocesses source files locally before shipping them off to be compiled
on remote hosts. This preprocessing removes comments, including /* fallthrough 
*/
comments in switch statements that normally prevent the implicit-fallthrough
warning.

Rather than turning off -Werror by patching configure.ac, it is simpler to
disable icecc completely for json-c. There are very few source files to compile,
so the compilation is quick even without icecc.

See https://github.com/icecc/icecream/issues/419

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

diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
index edb0e10434..c0f21bdbfd 100644
--- a/meta/classes/icecc.bbclass
+++ b/meta/classes/icecc.bbclass
@@ -76,6 +76,7 @@ ICECC_ENV_DEBUG ??= ""
 # target-sdk-provides-dummy - ${HOST_PREFIX} is empty which triggers the "NULL
 # prefix" error.
 ICECC_SYSTEM_PACKAGE_BL += "\
+json-c \
 libgcc-initial \
 target-sdk-provides-dummy \
 "
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] json-c: Disable icecc to avoid implicit-fallthrough warning as error

[Douglas Royds via Openembedded-core]

__attribute__((fallthrough)) wouldn't help us with gcc 5.4 in the 
-native case, of course.


I'll resubmit the patch using ICECC_SYSTEM_PACKAGE_BL


On 7/06/19 9:15 AM, Joshua Watt wrote:

FWIW: I've fixed a few upstream recipes that were doing this to use 
the __attribute__((fallthrough)) instead of a comment.


Anyway, usually the correct fix is to add the package to 
ICECC_SYSTEM_PACKAGE_BL in icecc.bbclass; it is maybe not ideal but 
ICECC_DISABLED is the user control for enabling and disabling icecream 
globally, not a per-recipe flag.


The current blacklist is woefully outdated, I really need to get 
around to updating it


On 6/6/19 4:03 PM, Douglas Royds via Openembedded-core wrote:
I struggled to find a solution that would work in the -native case, 
as we need to support gcc as old as 5.4 (Ubuntu 16.04).


The problem is somewhat specific to json-c, as -Werror is hard-coded 
into configure.ac in this package.



On 6/06/19 9:45 PM, Burton, Ross wrote:


Considering the pain that the gcc upgrade introducing that warning
caused I'll be *very* surprised if this problem is limited to json-c.
Could the icecc class forcibly disable that warning instead?

Ross

On Thu, 6 Jun 2019 at 03:06, Douglas Royds via Openembedded-core
 wrote:
icecc preprocesses source files locally before shipping them off to 
be compiled
on remote hosts. This preprocessing removes comments, including /* 
fallthrough */
comments in switch statements that normally prevent the 
implicit-fallthrough

warning.

Rather than turning off -Werror by patching configure.ac, it is 
simpler to
disable icecc completely for json-c. There are very few source 
files to compile,

so the compilation is quick even without icecc.

See https://github.com/icecc/icecream/issues/419

Signed-off-by: Douglas Royds 
---
  meta/recipes-devtools/json-c/json-c_0.13.1.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb

index 5b10e68297..8d2a20352d 100644
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
@@ -21,6 +21,7 @@ RPROVIDES_${PN} = "libjson"
  inherit autotools

  EXTRA_OECONF = "--enable-rdrand"
+ICECC_DISABLED = "1"

  do_configure_prepend() {
  # Clean up autoconf cruft that should not be in the tarball
--
2.17.1

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] json-c: Disable icecc to avoid implicit-fallthrough warning as error

[Douglas Royds via Openembedded-core]

I struggled to find a solution that would work in the -native case, as 
we need to support gcc as old as 5.4 (Ubuntu 16.04).


The problem is somewhat specific to json-c, as -Werror is hard-coded 
into configure.ac in this package.



On 6/06/19 9:45 PM, Burton, Ross wrote:


Considering the pain that the gcc upgrade introducing that warning
caused I'll be *very* surprised if this problem is limited to json-c.
Could the icecc class forcibly disable that warning instead?

Ross

On Thu, 6 Jun 2019 at 03:06, Douglas Royds via Openembedded-core
 wrote:

icecc preprocesses source files locally before shipping them off to be compiled
on remote hosts. This preprocessing removes comments, including /* fallthrough 
*/
comments in switch statements that normally prevent the implicit-fallthrough
warning.

Rather than turning off -Werror by patching configure.ac, it is simpler to
disable icecc completely for json-c. There are very few source files to compile,
so the compilation is quick even without icecc.

See https://github.com/icecc/icecream/issues/419

Signed-off-by: Douglas Royds 
---
  meta/recipes-devtools/json-c/json-c_0.13.1.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
index 5b10e68297..8d2a20352d 100644
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
@@ -21,6 +21,7 @@ RPROVIDES_${PN} = "libjson"
  inherit autotools

  EXTRA_OECONF = "--enable-rdrand"
+ICECC_DISABLED = "1"

  do_configure_prepend() {
  # Clean up autoconf cruft that should not be in the tarball
--
2.17.1

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] json-c: Make implicit-fallthrough only a warning for compilation under icecc

[Douglas Royds via Openembedded-core]

Please disregard this one, I have submitted a newer patch under a new 
subject-line:


   json-c: Disable icecc to avoid implicit-fallthrough warning as error


On 6/06/19 1:13 PM, Douglas Royds wrote:


icecc preprocesses source files locally before shipping them off to be compiled
on remote hosts. This preprocessing removes comments, including /* fallthrough 
*/
comments in switch statements that normally prevent the implicit-fallthrough
warning. Rather than turning off -Werror completely, just reduce
implicit-fallthrough to a warning only.

In the -native case, we might be building on an earlier gcc, eg. gcc 5.4
under Ubuntu 16.04, so we do disable -Werror completely.

See https://github.com/icecc/icecream/issues/419

Signed-off-by: Douglas Royds 
---
  meta/recipes-devtools/json-c/json-c_0.13.1.bb | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
index 5b10e68297..87a87aec44 100644
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
@@ -22,6 +22,9 @@ inherit autotools
  
  EXTRA_OECONF = "--enable-rdrand"
  
+TARGET_CPPFLAGS =+ "-Wno-error=implicit-fallthrough"

+BUILD_CPPFLAGS =+ "-Wno-error"
+
  do_configure_prepend() {
  # Clean up autoconf cruft that should not be in the tarball
  rm -f ${S}/config.status



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] json-c: Disable icecc to avoid implicit-fallthrough warning as error

[Douglas Royds via Openembedded-core]

icecc preprocesses source files locally before shipping them off to be compiled
on remote hosts. This preprocessing removes comments, including /* fallthrough 
*/
comments in switch statements that normally prevent the implicit-fallthrough
warning.

Rather than turning off -Werror by patching configure.ac, it is simpler to
disable icecc completely for json-c. There are very few source files to compile,
so the compilation is quick even without icecc.

See https://github.com/icecc/icecream/issues/419

Signed-off-by: Douglas Royds 
---
 meta/recipes-devtools/json-c/json-c_0.13.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
index 5b10e68297..8d2a20352d 100644
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
@@ -21,6 +21,7 @@ RPROVIDES_${PN} = "libjson"
 inherit autotools
 
 EXTRA_OECONF = "--enable-rdrand"
+ICECC_DISABLED = "1"
 
 do_configure_prepend() {
 # Clean up autoconf cruft that should not be in the tarball
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] json-c: Make implicit-fallthrough only a warning for compilation under icecc

[Douglas Royds via Openembedded-core]

icecc preprocesses source files locally before shipping them off to be compiled
on remote hosts. This preprocessing removes comments, including /* fallthrough 
*/
comments in switch statements that normally prevent the implicit-fallthrough
warning. Rather than turning off -Werror completely, just reduce
implicit-fallthrough to a warning only.

In the -native case, we might be building on an earlier gcc, eg. gcc 5.4
under Ubuntu 16.04, so we do disable -Werror completely.

See https://github.com/icecc/icecream/issues/419

Signed-off-by: Douglas Royds 
---
 meta/recipes-devtools/json-c/json-c_0.13.1.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
index 5b10e68297..87a87aec44 100644
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
@@ -22,6 +22,9 @@ inherit autotools
 
 EXTRA_OECONF = "--enable-rdrand"
 
+TARGET_CPPFLAGS =+ "-Wno-error=implicit-fallthrough"
+BUILD_CPPFLAGS =+ "-Wno-error"
+
 do_configure_prepend() {
 # Clean up autoconf cruft that should not be in the tarball
 rm -f ${S}/config.status
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] json-c: Make implicit-fallthrough only a warning for compilation under icecc

[Douglas Royds via Openembedded-core]

icecc preprocesses source files locally before shipping them off to be compiled
on remote hosts. This preprocessing removes comments, including /* fallthough */
comments in switch statements that normally prevent the implicit-fallthrough
warning. Rather than turning off -Werror completely, just reduce
implicit-fallthrough to a warning only.

See https://github.com/icecc/icecream/issues/419

Signed-off-by: Douglas Royds 
---
 meta/recipes-devtools/json-c/json-c_0.13.1.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
index 5b10e68297..ddda7375d3 100644
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
@@ -22,6 +22,9 @@ inherit autotools
 
 EXTRA_OECONF = "--enable-rdrand"
 
+TARGET_CPPFLAGS =+ "-Wno-error=implicit-fallthrough"
+BUILD_CPPFLAGS =+ "-Wno-error=implicit-fallthrough"
+
 do_configure_prepend() {
 # Clean up autoconf cruft that should not be in the tarball
 rm -f ${S}/config.status
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] distutils: Tidy and simplify for readability

[Douglas Royds via Openembedded-core]

On 14/05/19 6:41 PM, Martin Hundebøll wrote:


On 14/05/2019 08.16, Douglas Royds via Openembedded-core wrote:
Can anyone explain why I appear on patchwork as "Andrii Bordunov via 
Openembedded-core"?


Yes.

Because the DMARC policy for your domain is "quarantine":

  % dig _dmarc.taitradio.com TXT | grep -oE 'p=(reject|quarantine|none)'
  p=quarantine

If the mailing list simply forwards your mails, they will fail 
validation, and thus be held back by the receiving mail servers. To 
avoid this, Mailman changes the "From:" header to "Douglas Royds via 
Openembedded-core ".


Now the email address seen by patchwork is the same for everyone with 
either "reject" or "quarantine" as DMARC policy. I guess patchwork has 
that address associated with Andrii (maybe he came first).


More info from mailman: https://wiki.list.org/DEV/DMARC



Great, thanks for that.

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] distutils: Tidy and simplify for readability

[Douglas Royds via Openembedded-core]

Can anyone explain why I appear on patchwork as "Andrii Bordunov via 
Openembedded-core"?


See https://patchwork.openembedded.org/series/17604/

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] distutils: Tidy and simplify for readability

[Douglas Royds via Openembedded-core]

Line lengths, remove duplication, and use the PYTHON variable provided by
pythonnative.bbclass.

Coincidentally fixes a dormant defect in distutils3.bbclass in which we were
sedding for STAGING_BINDIR_NATIVE/python-python3/python3.

Signed-off-by: Douglas Royds 
---
 meta/classes/distutils.bbclass  | 26 +++---
 meta/classes/distutils3.bbclass | 22 --
 2 files changed, 19 insertions(+), 29 deletions(-)

diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index b5c9c2fbbd..3759b58263 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -52,25 +52,20 @@ distutils_do_install() {
 
 # support filenames with *spaces*
 # only modify file if it contains path  and recompile it
-find ${D} -name "*.py" -exec grep -q ${D} {} \; -exec sed -i -e 
s:${D}::g {} \; -exec ${STAGING_BINDIR_NATIVE}/python-native/python 
-mcompileall {} \;
+find ${D} -name "*.py" -exec grep -q ${D} {} \; \
+   -exec sed -i -e s:${D}::g {} \; \
+   -exec 
${STAGING_BINDIR_NATIVE}/python-native/python -mcompileall {} \;
 
-if test -e ${D}${bindir} ; then
-for i in ${D}${bindir}/* ; do \
-sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
+for i in ${D}${bindir}/* ${D}${sbindir}/*; do
+if [ -f "$i" ]; then
+sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g 
$i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
-done
-fi
-
-if [ -e ${D}${sbindir} ]; then
-for i in ${D}${sbindir}/* ; do \
-sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
-sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
-done
-fi
+fi
+done
 
 rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth
 rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/site.py*
-
+
 #
 # FIXME: Bandaid against wrong datadir computation
 #
@@ -80,7 +75,8 @@ distutils_do_install() {
 fi
 
# Fix backport modules
-   if [ -e 
${STAGING_LIBDIR}/${PYTHON_DIR}/site-packages/backports/__init__.py ] && [ -e 
${D}${PYTHON_SITEPACKAGES_DIR}/backports/__init__.py ]; then
+   if [ -e 
${STAGING_LIBDIR}/${PYTHON_DIR}/site-packages/backports/__init__.py ] && 
+   [ -e ${D}${PYTHON_SITEPACKAGES_DIR}/backports/__init__.py ]; then
   rm ${D}${PYTHON_SITEPACKAGES_DIR}/backports/__init__.py;
   rm ${D}${PYTHON_SITEPACKAGES_DIR}/backports/__init__.pyc;
fi
diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index 42e7f5ae53..05a24bfe26 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -56,24 +56,18 @@ distutils3_do_install() {
 bbfatal_log "'${PYTHON_PN} setup.py install ${DISTUTILS_INSTALL_ARGS}' 
execution failed."
 
 # support filenames with *spaces*
-find ${D} -name "*.py" -exec grep -q ${D} {} \; -exec sed -i -e 
s:${D}::g {} \;
+find ${D} -name "*.py" -exec grep -q ${D} {} \; \
+   -exec sed -i -e s:${D}::g {} \;
 
-if test -e ${D}${bindir} ; then
-for i in ${D}${bindir}/* ; do \
-sed -i -e 
s:${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
+for i in ${D}${bindir}/* ${D}${sbindir}/*; do
+if [ -f "$i" ]; then
+sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g 
$i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
-done
-fi
-
-if test -e ${D}${sbindir}; then
-for i in ${D}${sbindir}/* ; do \
-sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-${PYTHON_PN}/${PYTHON_PN}:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
-sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
-done
-fi
+fi
+done
 
 rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth
-
+
 #
 # FIXME: Bandaid against wrong datadir computation
 #
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3] distutils: Run python from the PATH in the -native case as well

[Douglas Royds via Openembedded-core]

The python distutils generate a python wrapper script for each package,
containing shebang lines pointing to the python executable.
In our case, this is a fully-qualified path to python-native in the
recipe-sysroot-native.

Ubuntu 18.04 restricts the useful length of the shebang line to 125
characters, and Ubuntu 16.04 restricts it to 77. In both cases, the
staged python script fails to run due to the length of the path to
the python-native executable.

Replace the shebang line with nativepython or nativepython3 as appropriate.
The nativepython symlink is installed by the python-native recipe:

#!/usr/bin/env nativepython

We were already doing this for on-target distutils components.
This change applies the sed-line to -native distutils components as well.
In this way, -native clients of these components can invoke the wrapper scripts
directly, without themselves needing to inherit pythonnative.

This works around a known setuptools issue:
https://github.com/pypa/setuptools/issues/494
Even once this issue has been resolved upstream,
we will still need to replace `python` with `nativepython`

Signed-off-by: Douglas Royds 
---
 meta/classes/distutils.bbclass  | 11 +--
 meta/classes/distutils3.bbclass |  7 +--
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 9862731493..b5c9c2fbbd 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -9,6 +9,9 @@ DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
 --install-lib=${PYTHON_SITEPACKAGES_DIR} \
 --install-data=${datadir}"
 
+DISTUTILS_PYTHON = "python"
+DISTUTILS_PYTHON_class-native = "nativepython"
+
 distutils_do_configure() {
 if [ "${CLEANBROKEN}" != "1" ] ; then
 NO_FETCH_BUILD=1 \
@@ -53,18 +56,14 @@ distutils_do_install() {
 
 if test -e ${D}${bindir} ; then
 for i in ${D}${bindir}/* ; do \
-if [ ${PN} != "${BPN}-native" ]; then
-   sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ python:g $i
-   fi
+sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
 done
 fi
 
 if [ -e ${D}${sbindir} ]; then
 for i in ${D}${sbindir}/* ; do \
-if [ ${PN} != "${BPN}-native" ]; then
-   sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ python:g $i
-   fi
+sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
 done
 fi
diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index 834e322474..42e7f5ae53 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -10,6 +10,9 @@ DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
 --install-lib=${PYTHON_SITEPACKAGES_DIR} \
 --install-data=${datadir}"
 
+DISTUTILS_PYTHON = "python3"
+DISTUTILS_PYTHON_class-native = "nativepython3"
+
 distutils3_do_configure() {
if [ "${CLEANBROKEN}" != "1" ] ; then
NO_FETCH_BUILD=1 \
@@ -57,14 +60,14 @@ distutils3_do_install() {
 
 if test -e ${D}${bindir} ; then
 for i in ${D}${bindir}/* ; do \
-sed -i -e 
s:${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}:${USRBINPATH}/env\ 
${PYTHON_PN}:g $i
+sed -i -e 
s:${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
 done
 fi
 
 if test -e ${D}${sbindir}; then
 for i in ${D}${sbindir}/* ; do \
-sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-${PYTHON_PN}/${PYTHON_PN}:${USRBINPATH}/env\ 
${PYTHON_PN}:g $i
+sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-${PYTHON_PN}/${PYTHON_PN}:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
 done
 fi
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] distutils: Run python from the PATH in the -native case as well

[Douglas Royds via Openembedded-core]

The python distutils generate a python wrapper script for each package,
containing shebang lines pointing to the python executable.
In our case, this is a fully-qualified path to python-native in the
recipe-sysroot-native.

Ubuntu 18.04 restricts the useful length of the shebang line to 125
characters, and Ubuntu 16.04 restricts it to 77. In both cases, the
staged python script fails to run due to the length of the path to
the python-native executable.

Replace the shebang line with nativepython or nativepython3 as appropriate.
The nativepython symlink is installed by the python-native recipe:

#!/usr/bin/env nativepython

We were already doing this for on-target distutils components.
This change applies the sed-line to -native distutils components as well.
In this way, -native clients of these components can invoke the wrapper scripts
directly, without themselves needing to inherit pythonnative.

This works around a known setuptools issue:
https://github.com/pypa/setuptools/issues/494
Even once this issue has been resolved upstream,
we will still need to replace `python` with `nativepython`

Signed-off-by: Douglas Royds 
---
 meta/classes/distutils.bbclass  | 11 +--
 meta/classes/distutils3.bbclass |  7 +--
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 9862731493..8d258daea4 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -9,6 +9,9 @@ DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
 --install-lib=${PYTHON_SITEPACKAGES_DIR} \
 --install-data=${datadir}"
 
+DISTUTILS_PYTHON = "${PYTHON_PN}"
+DISTUTILS_PYTHON_class-native = "native${PYTHON_PN}"
+
 distutils_do_configure() {
 if [ "${CLEANBROKEN}" != "1" ] ; then
 NO_FETCH_BUILD=1 \
@@ -53,18 +56,14 @@ distutils_do_install() {
 
 if test -e ${D}${bindir} ; then
 for i in ${D}${bindir}/* ; do \
-if [ ${PN} != "${BPN}-native" ]; then
-   sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ python:g $i
-   fi
+sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
 done
 fi
 
 if [ -e ${D}${sbindir} ]; then
 for i in ${D}${sbindir}/* ; do \
-if [ ${PN} != "${BPN}-native" ]; then
-   sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ python:g $i
-   fi
+sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
 done
 fi
diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index 834e322474..bae536d343 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -10,6 +10,9 @@ DISTUTILS_INSTALL_ARGS ?= "--root=${D} \
 --install-lib=${PYTHON_SITEPACKAGES_DIR} \
 --install-data=${datadir}"
 
+DISTUTILS_PYTHON = "${PYTHON_PN}"
+DISTUTILS_PYTHON_class-native = "native${PYTHON_PN}"
+
 distutils3_do_configure() {
if [ "${CLEANBROKEN}" != "1" ] ; then
NO_FETCH_BUILD=1 \
@@ -57,14 +60,14 @@ distutils3_do_install() {
 
 if test -e ${D}${bindir} ; then
 for i in ${D}${bindir}/* ; do \
-sed -i -e 
s:${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}:${USRBINPATH}/env\ 
${PYTHON_PN}:g $i
+sed -i -e 
s:${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
 done
 fi
 
 if test -e ${D}${sbindir}; then
 for i in ${D}${sbindir}/* ; do \
-sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-${PYTHON_PN}/${PYTHON_PN}:${USRBINPATH}/env\ 
${PYTHON_PN}:g $i
+sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-${PYTHON_PN}/${PYTHON_PN}:${USRBINPATH}/env\ 
${DISTUTILS_PYTHON}:g $i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
 done
 fi
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] distutils: Run python from the PATH in the -native case as well

[Douglas Royds via Openembedded-core]

The python distutils generate a python wrapper script for each package.
These python scripts have shebang lines pointing to the python executable.
In our case, this is a fully-qualified path to python-native in the
recipe-sysroot-native.

Ubuntu 18.04 restricts the useful length of the shebang line to 125
characters, and Ubuntu 16.04 restricts it to 77. In both cases, the
staged python script fails to run due to the length of the path to
the python-native executable.

Replace the shebang line with:

#!/usr/bin/env python

We were already doing this for on-target distutils components.
This change applies the sed-line to -native distutils components as
well.

The python executable must be in the PATH.
Client components must inherit pythonnative.

Signed-off-by: Douglas Royds 
---
 meta/classes/distutils.bbclass | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta/classes/distutils.bbclass b/meta/classes/distutils.bbclass
index 9862731493..e7d79271e3 100644
--- a/meta/classes/distutils.bbclass
+++ b/meta/classes/distutils.bbclass
@@ -53,18 +53,14 @@ distutils_do_install() {
 
 if test -e ${D}${bindir} ; then
 for i in ${D}${bindir}/* ; do \
-if [ ${PN} != "${BPN}-native" ]; then
-   sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ python:g $i
-   fi
+sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ python:g $i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
 done
 fi
 
 if [ -e ${D}${sbindir} ]; then
 for i in ${D}${sbindir}/* ; do \
-if [ ${PN} != "${BPN}-native" ]; then
-   sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ python:g $i
-   fi
+sed -i -e 
s:${STAGING_BINDIR_NATIVE}/python-native/python:${USRBINPATH}/env\ python:g $i
 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
 done
 fi
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core