[OE-core] [PATCH] python3-psutil: fix-up -tests runtime dependencies

[Mark Asselstine]

The psutil.tests module makes use of gcc, other tools and a minimal
set of headers and build tools. If these are missing you will see

==
ERROR: psutil.tests.test_process.TestProcess.test_weird_environ
--
Traceback (most recent call last):
 File "./psutil/tests/test_process.py", line 1452, in test_weird_environ
   create_exe(path, c_code=code)
 File "./psutil/tests/__init__.py", line 831, in create_exe
   raise ValueError("gcc is not installed")
ValueError: gcc is not installed

along with other errors related to the missing tools and headers.

Add the missing RDEPENDS for the -tests package such that simply
adding the -tests package to an image will be all that is needed.

Signed-off-by: Mark Asselstine 
---
 .../python/python3-psutil_5.9.4.bb | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-psutil_5.9.4.bb 
b/meta/recipes-devtools/python/python3-psutil_5.9.4.bb
index 54d5784a0d..c0977c74d3 100644
--- a/meta/recipes-devtools/python/python3-psutil_5.9.4.bb
+++ b/meta/recipes-devtools/python/python3-psutil_5.9.4.bb
@@ -24,4 +24,18 @@ RDEPENDS:${PN} += " \
 ${PYTHON_PN}-resource \
 "
 
+RDEPENDS:${PN}-tests += " \
+ ${PN} \
+ ${PYTHON_PN} \
+ coreutils \
+ procps \
+ binutils \
+ gcc \
+ gcc-symlinks \
+ libstdc++ \
+ libstdc++-dev \
+"
+
+INSANE_SKIP:${PN}-tests += "dev-deps"
+
 BBCLASSEXTEND = "native nativesdk"
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179828): 
https://lists.openembedded.org/g/openembedded-core/message/179828
Mute This Topic: https://lists.openembedded.org/mt/98135556/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] oeqa/selftest/bblogging: uncomment python stdout checks

[Mark Asselstine]

Since bitbake commit 81a58647b2f4fc0a2589b2978fc9d81b2bfe6aec
[bitbake: build: Make python output print to stdout when running with
-v (verbose)] we no longer need to comment out the python stdout
checks.

Signed-off-by: Mark Asselstine 
---
 meta/lib/oeqa/selftest/cases/bblogging.py | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/bblogging.py 
b/meta/lib/oeqa/selftest/cases/bblogging.py
index 1534a36a85..040c6db089 100644
--- a/meta/lib/oeqa/selftest/cases/bblogging.py
+++ b/meta/lib/oeqa/selftest/cases/bblogging.py
@@ -105,16 +105,14 @@ class BitBakeLogging(OESelftestTestCase):
 self.write_config('BBINCLUDELOGS = ""')
 result = bitbake("logging-test -c pythontest_exit -f -v", 
ignore_status = True)
 self.assertIn("ERROR: Logfile of failure stored in:", result.output)
-# python tasks don't log output with -v currently
-#self.assertCount(result.output, "This is python stdout", 1)
+self.assertCount(result.output, "This is python stdout", 1)
 
 def test_python_exit_loggingD(self):
 # logs, verbose
 self.write_config('BBINCLUDELOGS = "yes"')
 result = bitbake("logging-test -c pythontest_exit -f -v", 
ignore_status = True)
 self.assertIn("ERROR: Logfile of failure stored in:", result.output)
-# python tasks don't log output with -v currently
-#self.assertCount(result.output, "This is python stdout", 1)
+self.assertCount(result.output, "This is python stdout", 1)
 
 def test_python_exec_func_python_loggingA(self):
 # no logs, no verbose
@@ -139,8 +137,7 @@ class BitBakeLogging(OESelftestTestCase):
 result = bitbake("logging-test -c pythontest_exec_func_python -f -v",
  ignore_status = True)
 self.assertIn("ERROR: Logfile of failure stored in:", result.output)
-# python tasks don't log output with -v currently
-#self.assertCount(result.output, "This is python stdout", 1)
+self.assertCount(result.output, "This is python stdout", 1)
 
 def test_python_exec_func_python_loggingD(self):
 # logs, verbose
@@ -148,8 +145,7 @@ class BitBakeLogging(OESelftestTestCase):
 result = bitbake("logging-test -c pythontest_exec_func_python -f -v",
  ignore_status = True)
 self.assertIn("ERROR: Logfile of failure stored in:", result.output)
-# python tasks don't log output with -v currently
-#self.assertCount(result.output, "This is python stdout", 1)
+self.assertCount(result.output, "This is python stdout", 1)
 
 def test_python_fatal_loggingA(self):
 # no logs, no verbose
@@ -173,8 +169,7 @@ class BitBakeLogging(OESelftestTestCase):
 self.write_config('BBINCLUDELOGS = ""')
 result = bitbake("logging-test -c pythontest_fatal -f -v", 
ignore_status = True)
 self.assertIn("ERROR: Logfile of failure stored in:", result.output)
-# python tasks don't log output with -v currently
-#self.assertCount(result.output, "This is python fatal test stdout", 1)
+self.assertCount(result.output, "This is python fatal test stdout", 1)
 self.assertCount(result.output, "This is a fatal error", 1)
 
 def test_python_fatal_loggingD(self):
@@ -182,7 +177,6 @@ class BitBakeLogging(OESelftestTestCase):
 self.write_config('BBINCLUDELOGS = "yes"')
 result = bitbake("logging-test -c pythontest_fatal -f -v", 
ignore_status = True)
 self.assertIn("ERROR: Logfile of failure stored in:", result.output)
-# python tasks don't log output with -v currently
-#self.assertCount(result.output, "This is python fatal test stdout", 1)
+self.assertCount(result.output, "This is python fatal test stdout", 1)
 self.assertCount(result.output, "This is a fatal error", 1)
 
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179708): 
https://lists.openembedded.org/g/openembedded-core/message/179708
Mute This Topic: https://lists.openembedded.org/mt/98067603/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 3/5] poky-meta: add go vendor class for offline builds

[Mark Asselstine]

On 2022-05-06 02:59, Stefan Herbrechtsmeier wrote:

From: Lukas Funke 

Signed-off-by: Lukas Funke 
Signed-off-by: Stefan Herbrechtsmeier 
---

  meta/classes/go-vendor.bbclass | 68 ++
  1 file changed, 68 insertions(+)
  create mode 100644 meta/classes/go-vendor.bbclass

diff --git a/meta/classes/go-vendor.bbclass b/meta/classes/go-vendor.bbclass
new file mode 100644
index 00..a1a740a1fc
--- /dev/null
+++ b/meta/classes/go-vendor.bbclass
@@ -0,0 +1,68 @@
+# Copyright 2022 (C) Weidmueller GmbH & Co KG
+# Author: Lukas Funke 
+#
+# Handle Go vendor support for offline builds
+#
+# When importing Go modules, Go downloads the imported module using
+# a network (proxy) connection ahead of the compile stage. This contradicts
+# the yocto build concept of fetching every source ahead of build-time
+# and supporting offline builds.
+#
+# To support offline builds, we use Go 'vendoring': module dependencies are
+# downloaded during the fetch-phase and unpacked into the modules 'vendor'
+# folder. Additinally a manifest file is generated for the 'vendor' folder
+#
+


Several instances of trailing whitespace in the file header.


+inherit go-mod
+
+def go_src_uri(repo, path=None, subdir=None, vcs='git', destsuffix_prefix = 
'git/src/import/vendor.fetch'):
+module_path = repo if not path else path
+src_uri = "{}://{};name={};destsuffix={}/{}".format(vcs, repo, \
+module_path.replace('/', '.'), \
+destsuffix_prefix, module_path)
+
+src_uri += ";subdir={}".format(subdir) if subdir else ""
+src_uri += ";nobranch=1;protocol=https" if vcs == "git" else ""
+
+return src_uri
+
+def go_generate_vendor_manifest(d):
+
+vendor_dir = os.path.join(os.path.basename(d.getVar('S')),
+'src', d.getVar('GO_IMPORT'), "vendor")
+dst = os.path.join(vendor_dir, "modules.txt")
+
+go_modules = d.getVarFlags("GO_MODULE_PATH")
+with open(dst, "w") as manifest:
+for go_module in go_modules:
+module_path = d.getVarFlag("GO_MODULE_PATH", go_module)
+module_version = d.getVarFlag("GO_MODULE_VERSION", go_module)
+if module_path and module_version:
+manifest.write("# %s %s\n" % (module_path, module_version))
+manifest.write("## explicit\n")
+exclude = set(['vendor'])
+for subdir, dirs, files in os.walk(os.path.join(vendor_dir, 
module_path), topdown=True):
+dirs[:] = [d for d in dirs if d not in exclude]
+for file in files:


I am not sure what other folks think but I tend not to like to see 
python builtins reused as variable names. Too easy to screw up and 
messes with sytax highlighting in editors.


MarkA


+if file.endswith(".go"):
+manifest.write(subdir[len(vendor_dir)+1:] + "\n")
+break
+
+python go_do_unpack:append() {
+src_uri = (d.getVar('SRC_URI') or "").split()
+if len(src_uri) == 0:
+return
+
+try:
+fetcher = bb.fetch2.Fetch(src_uri, d)
+src_folder = os.path.join(os.path.basename(d.getVar('S')),
+'src', d.getVar('GO_IMPORT'))
+vendor_src = os.path.join(src_folder, "vendor")
+vendor_dst = os.path.join(d.getVar('S'), "src", "import", 
"vendor.fetch")
+
+os.symlink(os.path.relpath(vendor_dst, src_folder), vendor_src)
+go_generate_vendor_manifest(d)
+
+except bb.fetch2.BBFetchException as e:
+raise bb.build.FuncFailed(e)
+}






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165529): 
https://lists.openembedded.org/g/openembedded-core/message/165529
Mute This Topic: https://lists.openembedded.org/mt/90928683/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 4/5] recipetool: add go recipe generator

[Mark Asselstine]

On 2022-05-06 03:15, Alexander Kanavin wrote:

This is a lot of code. Can you add some documentation for it, what it
does and how it works? If someone would want to understand it, how
would they go about it?

Alex

On Fri, 6 May 2022 at 09:00, Stefan Herbrechtsmeier
 wrote:


From: Lukas Funke 

Signed-off-by: Lukas Funke 
Signed-off-by: Stefan Herbrechtsmeier 
---

  scripts/lib/recipetool/create_go.py | 394 
  1 file changed, 394 insertions(+)
  create mode 100644 scripts/lib/recipetool/create_go.py

diff --git a/scripts/lib/recipetool/create_go.py 
b/scripts/lib/recipetool/create_go.py
new file mode 100644
index 00..4552e9b470
--- /dev/null
+++ b/scripts/lib/recipetool/create_go.py
@@ -0,0 +1,394 @@
+# Recipe creation tool - go support plugin
+#
+# Copyright (C) 2022 Weidmueller GmbH & Co KG
+# Author: Lukas Funke 
+#
+# Copyright (c) 2009 The Go Authors. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-3-Clause AND GPL-2.0-only
+#
+import bb.utils
+from collections import namedtuple
+from enum import Enum
+from html.parser import HTMLParser
+import json
+import logging
+import os
+import re
+import subprocess
+import sys
+import tempfile
+import shutil
+from urllib.error import URLError, HTTPError
+import urllib.parse
+import urllib.request
+
+from recipetool.create import RecipeHandler, handle_license_vars, 
ensure_native_cmd
+
+GoImport = namedtuple('GoImport', 'reporoot vcs repourl suffix')
+logger = logging.getLogger('recipetool')
+
+tinfoil = None
+
+re_pseudo_semver = 
re.compile(r"v([0-9]+)\.([0-9]+).([0-9]+|\([0-9]+\+1\))-(pre\.[0-9]+\.)?([0-9]+\.)?(?P[0-9]+)-(?P[0-9Aa-zA-Z]+)")
+re_semver = 
re.compile(r"^v(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$")
+
+def tinfoil_init(instance):
+global tinfoil
+tinfoil = instance
+
+class GoRecipeHandler(RecipeHandler):
+
+def _resolve_repository_static(self, modulepath):
+_rootpath = None
+_vcs = None
+_repourl = None
+_suffix = None
+
+host, _, path = modulepath.partition('/')
+
+class vcs(Enum):
+pathprefix = "pathprefix"
+regexp = "regexp"
+vcs = "vcs"
+repo = "repo"
+check = "check"
+schemelessRepo = "schemelessRepo"
+
+# GitHub
+vcsGitHub = {}
+vcsGitHub[vcs.pathprefix] = "github.com"
+vcsGitHub[vcs.regexp] = 
re.compile(r'^(?Pgithub\.com/[A-Za-z0-9_.\-]+/[A-Za-z0-9_.\-]+)(/(?P[A-Za-z0-9_.\-]+))*$')
+vcsGitHub[vcs.vcs] = "git"
+vcsGitHub[vcs.repo] = "https://\g"
+
+# Bitbucket
+vcsBitbucket = {}
+vcsBitbucket[vcs.pathprefix] = "bitbucket.org"
+vcsBitbucket[vcs.regexp] = 
re.compile(r'^(?Pbitbucket\.org/(?P[A-Za-z0-9_.\-]+/[A-Za-z0-9_.\-]+))(/(?P[A-Za-z0-9_.\-]+))*$')
+vcsBitbucket[vcs.vcs] = "git"
+vcsBitbucket[vcs.repo] = "https://\g"
+
+# IBM DevOps Services (JazzHub)
+vcsIBMDevOps = {}
+vcsIBMDevOps[vcs.pathprefix] = "hub.jazz.net/git"
+vcsIBMDevOps[vcs.regexp] = 
re.compile(r'^(?Phub\.jazz\.net/git/[a-z0-9]+/[A-Za-z0-9_.\-]+)(/(?P[A-Za-z0-9_.\-]+))*$')
+vcsIBMDevOps[vcs.vcs] = "git"
+vcsIBMDevOps[vcs.repo] = "https://\g"
+
+# Git at Apache
+vcsApacheGit = {}
+vcsApacheGit[vcs.pathprefix] = "git.apache.org"
+vcsApacheGit[vcs.regexp] = 
re.compile(r'^(?Pgit\.apache\.org/[a-z0-9_.\-]+\.git)(/(?P[A-Za-z0-9_.\-]+))*$')
+vcsApacheGit[vcs.vcs] = "git"
+vcsApacheGit[vcs.repo] = "https://\g"
+
+# Git at OpenStack
+vcsOpenStackGit = {}
+vcsOpenStackGit[vcs.pathprefix] = "git.openstack.org"
+vcsOpenStackGit[vcs.regexp] = 
re.compile(r'^(?Pgit\.openstack\.org/[A-Za-z0-9_.\-]+/[A-Za-z0-9_.\-]+)(\.git)?(/(?P[A-Za-z0-9_.\-]+))*$')
+vcsOpenStackGit[vcs.vcs] = "git"
+vcsOpenStackGit[vcs.repo] = "https://\g"
+
+# chiselapp.com for fossil
+vcsChiselapp = {}
+vcsChiselapp[vcs.pathprefix] = "chiselapp.com"
+vcsChiselapp[vcs.regexp] = 
re.compile(r'^(?Pchiselapp\.com/user/[A-Za-z0-9]+/repository/[A-Za-z0-9_.\-]+)$')
+vcsChiselapp[vcs.vcs] = "fossil"
+vcsChiselapp[vcs.repo] = "https://\g"
+
+# General syntax for any server.
+# Must be last.
+vcsGeneralServer = {}
+vcsGeneralServer[vcs.regexp] = 
re.compile("(?P(?P([a-z0-9.\-]+\.)+[a-z0-9.\-]+(:[0-9]+)?(/~?[A-Za-z0-9_.\-]+)+?)\.(?Pbzr|fossil|git|hg|svn))(/~?(?P[A-Za-z0-9_.\-]+))*$")
+vcsGeneralServer[vcs.schemelessRepo] = True
+
+vcsPaths = [vcsGitHub, vcsBitbucket, vcsIBMDevOps, vcsApacheGit, 
vcsOpenStackGit, vcsChiselapp, vcsGeneralServer]
+
+if modulepath.startswith("example.net") or modulepath == "rsc.io":
+logger.warning("Suspicious module path %s

Re: [OE-core] [PATCH 5/5] oe-selftest: add go recipe create selftest

[Mark Asselstine]

On 2022-05-06 03:16, Alexander Kanavin wrote:

Also here an explanation of what the test does would be useful.

Please keep in mind: writing code is only half the job. You need to
explain it to non-specialists too, we're already struggling with items
which are understood by few people, or in some cases only one person.

Alex

On Fri, 6 May 2022 at 09:00, Stefan Herbrechtsmeier
 wrote:


From: Lukas Funke 

Signed-off-by: Lukas Funke 

Signed-off-by: Stefan Herbrechtsmeier 
---

  meta/lib/oeqa/selftest/cases/recipetool.py | 88 ++
  1 file changed, 88 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py 
b/meta/lib/oeqa/selftest/cases/recipetool.py
index 510dae6bad..bb36e7b6d5 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -530,6 +530,94 @@ class RecipetoolTests(RecipetoolBase):
  libpath = os.path.join(get_bb_var('COREBASE'), 'scripts', 'lib', 
'recipetool')
  sys.path.insert(0, libpath)

+def test_recipetool_create_go(self):
+# Basic test to check go recipe generation
+def urifiy(url, version, path = None, subdir = None):
+path = ",path='%s'" % path if path else ''
+subdir = ",subdir='%s'" % subdir if subdir else ''
+return "${@go_src_uri('%s','%s'%s%s)}" % (url, path, subdir)
+
+temprecipe = os.path.join(self.tempdir, 'recipe')
+os.makedirs(temprecipe)


I hate anything that has the potential to generate a python splat 
existing. At any rate you have matched what the other tests do so no 
change required (maybe the test framework catches splats, I am not 
familiar enough with the test framework to know). Typically I would want 
to see this call in a try block.



+recipefile = os.path.join(temprecipe, 'edgex-go_git.bb')
+srcuri = 'https://github.com/edgexfoundry/edgex-go.git'
+srcrev = "v2.2.0-dev.54"
+result = runCmd('recipetool create -o %s %s -S %s' % (temprecipe, 
srcuri, srcrev))
+self.assertTrue(os.path.isfile(recipefile))
+checkvars = {}
+src_uri = ['git://${GO_IMPORT};nobranch=1;name=${BPN}']
+checkvars['LIC_FILES_CHKSUM'] = 
set(['file://src/${GO_IMPORT}/LICENSE;md5=71a6955f3cd81a809549da266346dc59'])
+checkvars['GO_IMPORT'] = "github.com/edgexfoundry/edgex-go"
+inherits = ['go-vendor']
+dependencies = \
+[
+('bitbucket.org/bertimus9/systemstat'),
+
('github.com/edgexfoundry/go-mod-bootstrap','github.com/edgexfoundry/go-mod-bootstrap/v2'),
+
('github.com/edgexfoundry/go-mod-core-contracts''github.com/edgexfoundry/go-mod-core-contracts/v2'),
+
('github.com/edgexfoundry/go-mod-messaging','github.com/edgexfoundry/go-mod-messaging/v2'),
+
('github.com/edgexfoundry/go-mod-registry','github.com/edgexfoundry/go-mod-registry/v2'),
+
('github.com/edgexfoundry/go-mod-secrets','github.com/edgexfoundry/go-mod-secrets/v2'),
+('github.com/fxamacker/cbor','github.com/fxamacker/cbor/v2'),
+('github.com/golang-jwt/jwt','github.com/golang-jwt/jwt/v4'),
+('github.com/gomodule/redigo'),
+('github.com/google/uuid'),
+('github.com/gorilla/mux'),
+('github.com/lib/pq'),
+('github.com/pelletier/go-toml'),
+
('github.com/spiffe/go-spiffe','github.com/spiffe/go-spiffe/v2'),
+('github.com/stretchr/testify'),
+('go.googlesource.com/crypto','golang.org/x/crypto'),
+('gopkg.in/eapache/queue.v1'),
+('gopkg.in/yaml.v3'),
+('github.com/armon/go-metrics'),
+('github.com/cenkalti/backoff'),
+('github.com/davecgh/go-spew'),
+('github.com/eclipse/paho.mqtt.golang'),
+
('github.com/edgexfoundry/go-mod-configuration','github.com/edgexfoundry/go-mod-configuration/v2'),
+('github.com/fatih/color'),
+('github.com/go-kit/log'),
+('github.com/go-logfmt/logfmt'),
+('github.com/go-playground/locales'),
+('github.com/go-playground/universal-translator'),
+
('github.com/go-playground/validator','github.com/go-playground/validator/v10'),
+('github.com/go-redis/redis','github.com/go-redis/redis/v7'),
+('github.com/golang/protobuf'),
+('github.com/gorilla/websocket'),
+('github.com/hashicorp/consul','api'),
+('github.com/hashicorp/errwrap'),
+('github.com/hashicorp/go-cleanhttp'),
+('github.com/hashicorp/go-hclog'),
+('github.com/hashicorp/go-immutable-radix'),
+('github.com/hashicorp/go-multierror'),
+('github.com/hashicorp/go-rootcerts'),
+   

Re: [OE-core] [PATCH 1/5] recipetool-create: add ensure_native_cmd function

[Mark Asselstine]

On 2022-05-11 15:45, Mark Asselstine wrote:



On 2022-05-06 03:09, Alexander Kanavin wrote:

I think the terminology is a bit confused here, instead of 'command'
it should say 'recipe'. Also:
"""Check if the command is available in the recipes""" is not
everything it does, it also builds the recipe.

And please write a commit message that explains what and why.


Additionally, I would squash commits 1/5 and 2/5. Most people, including 
myself, will review the commits in order, in doing so commit 1/5 is 
reviewed as original work, only to find in 2/5 that it was an existing 
function, just made generic. Combining these also makes it easier when 
mining history.




I suspect this will need rework as the assumption that a command and 
package name are 1:1 might have only been valid with NPM but definitely 
won't be the case for many commands.


MarkA



MarkA




Alex

On Fri, 6 May 2022 at 09:00, Stefan Herbrechtsmeier
 wrote:


From: Lukas Funke 

Signed-off-by: Lukas Funke 
Signed-off-by: Stefan Herbrechtsmeier 


---

  scripts/lib/recipetool/create.py | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/scripts/lib/recipetool/create.py 
b/scripts/lib/recipetool/create.py

index 824ac6350d..efcb82173e 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -1375,6 +1375,29 @@ def convert_rpm_xml(xmlfile):
  values[varname] = child[0].text
  return values

+def ensure_native_cmd(tinfoil, cmd):
+    """Check if the command is available in the recipes"""
+    if not tinfoil.recipes_parsed:
+    tinfoil.parse_recipes()
+
+    try:
+    d = tinfoil.parse_recipe("%s-native" % cmd)
+    except bb.providers.NoProvider:
+    bb.error("Nothing provides '%s-native' which is required for 
the build" % cmd)
+    bb.note("You will likely need to add a layer that provides 
%s" % cmd)

+    sys.exit(14)
+
+    bindir = d.getVar("STAGING_BINDIR_NATIVE")
+    cmdpath = os.path.join(bindir, cmd)
+
+    if not os.path.exists(cmdpath):
+    tinfoil.build_targets("%s-native" % cmd, 
"addto_recipe_sysroot")

+
+    if not os.path.exists(cmdpath):
+    bb.error("Failed to add '%s' to sysroot" % cmd)
+    sys.exit(14)
+
+    return bindir

  def register_commands(subparsers):
  parser_create = subparsers.add_parser('create',
--
2.30.2









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165524): 
https://lists.openembedded.org/g/openembedded-core/message/165524
Mute This Topic: https://lists.openembedded.org/mt/90928682/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/5] recipetool-create: add ensure_native_cmd function

[Mark Asselstine]

On 2022-05-06 03:09, Alexander Kanavin wrote:

I think the terminology is a bit confused here, instead of 'command'
it should say 'recipe'. Also:
"""Check if the command is available in the recipes""" is not
everything it does, it also builds the recipe.

And please write a commit message that explains what and why.


Additionally, I would squash commits 1/5 and 2/5. Most people, including 
myself, will review the commits in order, in doing so commit 1/5 is 
reviewed as original work, only to find in 2/5 that it was an existing 
function, just made generic. Combining these also makes it easier when 
mining history.


MarkA




Alex

On Fri, 6 May 2022 at 09:00, Stefan Herbrechtsmeier
 wrote:


From: Lukas Funke 

Signed-off-by: Lukas Funke 
Signed-off-by: Stefan Herbrechtsmeier 
---

  scripts/lib/recipetool/create.py | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index 824ac6350d..efcb82173e 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -1375,6 +1375,29 @@ def convert_rpm_xml(xmlfile):
  values[varname] = child[0].text
  return values

+def ensure_native_cmd(tinfoil, cmd):
+"""Check if the command is available in the recipes"""
+if not tinfoil.recipes_parsed:
+tinfoil.parse_recipes()
+
+try:
+d = tinfoil.parse_recipe("%s-native" % cmd)
+except bb.providers.NoProvider:
+bb.error("Nothing provides '%s-native' which is required for the 
build" % cmd)
+bb.note("You will likely need to add a layer that provides %s" % cmd)
+sys.exit(14)
+
+bindir = d.getVar("STAGING_BINDIR_NATIVE")
+cmdpath = os.path.join(bindir, cmd)
+
+if not os.path.exists(cmdpath):
+tinfoil.build_targets("%s-native" % cmd, "addto_recipe_sysroot")
+
+if not os.path.exists(cmdpath):
+bb.error("Failed to add '%s' to sysroot" % cmd)
+sys.exit(14)
+
+return bindir

  def register_commands(subparsers):
  parser_create = subparsers.add_parser('create',
--
2.30.2









-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#165523): 
https://lists.openembedded.org/g/openembedded-core/message/165523
Mute This Topic: https://lists.openembedded.org/mt/90928682/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 1/2] xinput-calibrator: avoid defunct process

[Mark Asselstine]

On Tuesday, September 1, 2020 11:30:23 A.M. EDT Richard Purdie wrote:
> On Fri, 2020-08-28 at 17:29 -0400, Mark Asselstine wrote:
> > The xinput_calibrator_once.sh script produces output on stdout and
> > stderr which the current 'Exec' doesn't consume. This results in a
> > [xinput_calibrator_once.sh] defunct process which will remain around
> > until we exit the X11 session.
> > 
> > Add a redirect to the Exec which will consume this output and avoid
> > the defunct process.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> > V2: * no changes
> > 
> >  .../recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git
> > a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
> > b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb index
> > 4f831932e7..c59f97895c 100644
> > --- a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
> > +++ b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
> > @@ -31,7 +31,7 @@ do_install_append() {
> > 
> >  install -m 0755 ${WORKDIR}/30xinput_calibrate.sh
> >  ${D}${sysconfdir}/X11/Xsession.d/
> >  
> >  install -d ${D}${sysconfdir}/xdg/autostart
> > 
> > -sed -e 's,^Exec=.*,Exec=${bindir}/xinput_calibrator_once.sh,'
> > ${S}/scripts/xinput_calibrator.desktop >
> > ${D}${sysconfdir}/xdg/autostart/xinput_calibrator.desktop +sed -e
> > 's,^Exec=.*,Exec=${bindir}/sh -c "${bindir}/xinput_calibrator_once.sh
> > 2>\&1 > /dev/null",' ${S}/scripts/xinput_calibrator.desktop >
> > ${D}${sysconfdir}/xdg/autostart/xinput_calibrator.desktop> 
> >  }
> >  
> >  FILES_${PN} += "${sysconfdir}/xdg/autostart"
> 
> That appears to fail in testing:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/110/builds/1281/step
> s/8/logs/step1c
> 
> Presumably it should be base_bindir?

Sorry about that Richard. The configuration I tested with had no issue but 
obviously this wasn't universal. As you should have seen when I was looking 
into another XFCE startup issue it made me question my fix and so we should 
hold off on this change regardless, until I have dug in further to the bigger 
root cause.

Thanks,
Mark

> 
> Cheers,
> 
> Richard




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

View/Reply Online (#142119): 
https://lists.openembedded.org/g/openembedded-core/message/142119
Mute This Topic: https://lists.openembedded.org/mt/76483813/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 1/2] xinput-calibrator: avoid defunct process

[Mark Asselstine]

On Friday, August 28, 2020 5:29:19 P.M. EDT Mark Asselstine wrote:
> The xinput_calibrator_once.sh script produces output on stdout and
> stderr which the current 'Exec' doesn't consume. This results in a
> [xinput_calibrator_once.sh] defunct process which will remain around
> until we exit the X11 session.
> 
> Add a redirect to the Exec which will consume this output and avoid
> the defunct process.

Hold off on reviewing or merging this. Looking into another .desktop file 
which is causing yet another zombie process we are pretty sure there is a 
deeper issue at play here. I want to confirm and address what we are seeing 
before this is merged as it may not be needed.

Sorry about the churn. Things were only clear once the multiple issues were 
looked at.

2/2 is still valid, so if you want to take that one on its own, then go for 
it.

Thanks,
Mark Asselstine

> 
> Signed-off-by: Mark Asselstine 
> ---
> 
> V2: * no changes
> 
>  .../recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
> b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb index
> 4f831932e7..c59f97895c 100644
> --- a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
> +++ b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
> @@ -31,7 +31,7 @@ do_install_append() {
>  install -m 0755 ${WORKDIR}/30xinput_calibrate.sh
> ${D}${sysconfdir}/X11/Xsession.d/
> 
>  install -d ${D}${sysconfdir}/xdg/autostart
> -sed -e 's,^Exec=.*,Exec=${bindir}/xinput_calibrator_once.sh,'
> ${S}/scripts/xinput_calibrator.desktop >
> ${D}${sysconfdir}/xdg/autostart/xinput_calibrator.desktop +sed -e
> 's,^Exec=.*,Exec=${bindir}/sh -c "${bindir}/xinput_calibrator_once.sh 2>\&1
> > /dev/null",' ${S}/scripts/xinput_calibrator.desktop >
> ${D}${sysconfdir}/xdg/autostart/xinput_calibrator.desktop }
> 
>  FILES_${PN} += "${sysconfdir}/xdg/autostart"




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

View/Reply Online (#142081): 
https://lists.openembedded.org/g/openembedded-core/message/142081
Mute This Topic: https://lists.openembedded.org/mt/76483813/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 1/2] xinput-calibrator: avoid defunct process

[Mark Asselstine]

The xinput_calibrator_once.sh script produces output on stdout and
stderr which the current 'Exec' doesn't consume. This results in a
[xinput_calibrator_once.sh] defunct process which will remain around
until we exit the X11 session.

Add a redirect to the Exec which will consume this output and avoid
the defunct process.

Signed-off-by: Mark Asselstine 
---

V2: * no changes

 .../recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb 
b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
index 4f831932e7..c59f97895c 100644
--- a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
+++ b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
@@ -31,7 +31,7 @@ do_install_append() {
 install -m 0755 ${WORKDIR}/30xinput_calibrate.sh 
${D}${sysconfdir}/X11/Xsession.d/
 
 install -d ${D}${sysconfdir}/xdg/autostart
-sed -e 's,^Exec=.*,Exec=${bindir}/xinput_calibrator_once.sh,' 
${S}/scripts/xinput_calibrator.desktop > 
${D}${sysconfdir}/xdg/autostart/xinput_calibrator.desktop
+sed -e 's,^Exec=.*,Exec=${bindir}/sh -c 
"${bindir}/xinput_calibrator_once.sh 2>\&1 > /dev/null",' 
${S}/scripts/xinput_calibrator.desktop > 
${D}${sysconfdir}/xdg/autostart/xinput_calibrator.desktop
 }
 
 FILES_${PN} += "${sysconfdir}/xdg/autostart"
-- 
2.27.0

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

View/Reply Online (#141938): 
https://lists.openembedded.org/g/openembedded-core/message/141938
Mute This Topic: https://lists.openembedded.org/mt/76483813/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 2/2] xinput-calibrator: make _once run only once

[Mark Asselstine]

If no calibratable devices are found then no calibration is
written. With no configuration file created each and every login will
result in a fresh attempt to perform calibrations, which is
undesirable for many reasons. Since HW doesn't change often we are
better off writing an 'empty' calibration file to avoid further
attempts to perform calibration. If new HW is added the file can
simply be removed to force a new calibration attempt.

Signed-off-by: Mark Asselstine 
---

V2: * add Upstream-status to the patch

 ...r_pointercal.sh-allow-skipping-calib.patch | 34 +++
 .../xinput-calibrator_git.bb  |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 
meta/recipes-graphics/xinput-calibrator/xinput-calibrator/xinput_calibrator_pointercal.sh-allow-skipping-calib.patch

diff --git 
a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator/xinput_calibrator_pointercal.sh-allow-skipping-calib.patch
 
b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator/xinput_calibrator_pointercal.sh-allow-skipping-calib.patch
new file mode 100644
index 00..d28b623313
--- /dev/null
+++ 
b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator/xinput_calibrator_pointercal.sh-allow-skipping-calib.patch
@@ -0,0 +1,34 @@
+From d89d5e25a805d5ccc6d9fb2245da45cdc6b5ac33 Mon Sep 17 00:00:00 2001
+From: Mark Asselstine 
+Date: Fri, 28 Aug 2020 14:48:40 -0400
+Subject: [PATCH] xinput_calibrator_pointercal.sh: allow skipping calibration
+
+If no suitable devices are found then no configuration file will be
+written. This results in a new attempt to perform calibration on every
+login. Instead we write an "empty" file with just some brief
+instructions on how to force a new calibration. This will result in a
+calibration attempt only being run on the first login (future logins
+have things end with the sourcing of an empty config only).
+
+Upstream-Status: Inappropriate as only Yocto uses this as a 'once' script
+
+Signed-off-by: Mark Asselstine 
+---
+ scripts/xinput_calibrator_pointercal.sh | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/scripts/xinput_calibrator_pointercal.sh 
b/scripts/xinput_calibrator_pointercal.sh
+index 0ada7da..a331af1 100755
+--- a/scripts/xinput_calibrator_pointercal.sh
 b/scripts/xinput_calibrator_pointercal.sh
+@@ -41,4 +41,7 @@ CALDATA=`$BINARY --output-type xinput -v | tee $LOGFILE | 
grep 'xinput set'
+ if [ ! -z "$CALDATA" ] ; then
+   echo $CALDATA > $CALFILE
+   echo "Calibration data stored in $CALFILE (log in $LOGFILE)"
++else
++  echo "# Delete this file to force xinput_calibrator to redo calibration" > 
$CALFILE
++  echo "Created $CALFILE as an empty calibration file, no devices found."
+ fi
+-- 
+2.27.0
+
diff --git a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb 
b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
index c59f97895c..6f4ea03958 100644
--- a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
+++ b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
@@ -16,6 +16,7 @@ SRC_URI = "git://github.com/tias/xinput_calibrator.git \
file://30xinput_calibrate.sh \
file://Allow-xinput_calibrator_pointercal.sh-to-be-run-as-n.patch \
file://0001-calibrator.hh-Include-string-to-get-std-string.patch \
+   file://xinput_calibrator_pointercal.sh-allow-skipping-calib.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.27.0

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

View/Reply Online (#141937): 
https://lists.openembedded.org/g/openembedded-core/message/141937
Mute This Topic: https://lists.openembedded.org/mt/76483807/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] xinput-calibrator: avoid defunct process

[Mark Asselstine]

The xinput_calibrator_once.sh script produces output on stdout and
stderr which the current 'Exec' doesn't consume. This results in a
[xinput_calibrator_once.sh] defunct process which will remain around
until we exit the X11 session.

Add a redirect to the Exec which will consume this output and avoid
the defunct process.

Signed-off-by: Mark Asselstine 
---
 .../recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb 
b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
index 4f831932e7..c59f97895c 100644
--- a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
+++ b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
@@ -31,7 +31,7 @@ do_install_append() {
 install -m 0755 ${WORKDIR}/30xinput_calibrate.sh 
${D}${sysconfdir}/X11/Xsession.d/
 
 install -d ${D}${sysconfdir}/xdg/autostart
-sed -e 's,^Exec=.*,Exec=${bindir}/xinput_calibrator_once.sh,' 
${S}/scripts/xinput_calibrator.desktop > 
${D}${sysconfdir}/xdg/autostart/xinput_calibrator.desktop
+sed -e 's,^Exec=.*,Exec=${bindir}/sh -c 
"${bindir}/xinput_calibrator_once.sh 2>\&1 > /dev/null",' 
${S}/scripts/xinput_calibrator.desktop > 
${D}${sysconfdir}/xdg/autostart/xinput_calibrator.desktop
 }
 
 FILES_${PN} += "${sysconfdir}/xdg/autostart"
-- 
2.27.0

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

View/Reply Online (#141932): 
https://lists.openembedded.org/g/openembedded-core/message/141932
Mute This Topic: https://lists.openembedded.org/mt/76482285/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] xinput-calibrator: make _once run only once

[Mark Asselstine]

If no calibratable devices are found then no calibration is
written. With no configuration file created each and every login will
result in a fresh attempt to perform calibrations, which is
undesirable for many reasons. Since HW doesn't change often we are
better off writing an 'empty' calibration file to avoid further
attempts to perform calibration. If new HW is added the file can
simply be removed to force a new calibration attempt.

Signed-off-by: Mark Asselstine 
---
 ...r_pointercal.sh-allow-skipping-calib.patch | 32 +++
 .../xinput-calibrator_git.bb  |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 
meta/recipes-graphics/xinput-calibrator/xinput-calibrator/xinput_calibrator_pointercal.sh-allow-skipping-calib.patch

diff --git 
a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator/xinput_calibrator_pointercal.sh-allow-skipping-calib.patch
 
b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator/xinput_calibrator_pointercal.sh-allow-skipping-calib.patch
new file mode 100644
index 00..a7fade3428
--- /dev/null
+++ 
b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator/xinput_calibrator_pointercal.sh-allow-skipping-calib.patch
@@ -0,0 +1,32 @@
+From d89d5e25a805d5ccc6d9fb2245da45cdc6b5ac33 Mon Sep 17 00:00:00 2001
+From: Mark Asselstine 
+Date: Fri, 28 Aug 2020 14:48:40 -0400
+Subject: [PATCH] xinput_calibrator_pointercal.sh: allow skipping calibration
+
+If no suitable devices are found then no configuration file will be
+written. This results in a new attempt to perform calibration on every
+login. Instead we write an "empty" file with just some brief
+instructions on how to force a new calibration. This will result in a
+calibration attempt only being run on the first login (future logins
+have things end with the sourcing of an empty config only).
+
+Signed-off-by: Mark Asselstine 
+---
+ scripts/xinput_calibrator_pointercal.sh | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/scripts/xinput_calibrator_pointercal.sh 
b/scripts/xinput_calibrator_pointercal.sh
+index 0ada7da..a331af1 100755
+--- a/scripts/xinput_calibrator_pointercal.sh
 b/scripts/xinput_calibrator_pointercal.sh
+@@ -41,4 +41,7 @@ CALDATA=`$BINARY --output-type xinput -v | tee $LOGFILE | 
grep 'xinput set'
+ if [ ! -z "$CALDATA" ] ; then
+   echo $CALDATA > $CALFILE
+   echo "Calibration data stored in $CALFILE (log in $LOGFILE)"
++else
++  echo "# Delete this file to force xinput_calibrator to redo calibration" > 
$CALFILE
++  echo "Created $CALFILE as an empty calibration file, no devices found."
+ fi
+-- 
+2.27.0
+
diff --git a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb 
b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
index c59f97895c..6f4ea03958 100644
--- a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
+++ b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
@@ -16,6 +16,7 @@ SRC_URI = "git://github.com/tias/xinput_calibrator.git \
file://30xinput_calibrate.sh \
file://Allow-xinput_calibrator_pointercal.sh-to-be-run-as-n.patch \
file://0001-calibrator.hh-Include-string-to-get-std-string.patch \
+   file://xinput_calibrator_pointercal.sh-allow-skipping-calib.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.27.0

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

View/Reply Online (#141933): 
https://lists.openembedded.org/g/openembedded-core/message/141933
Mute This Topic: https://lists.openembedded.org/mt/76482286/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] sdkext: use simpler kernel module for devtool test

[Mark Asselstine]

On Friday, September 6, 2019 6:56:26 A.M. EDT 
richard.pur...@linuxfoundation.org wrote:
> On Thu, 2019-09-05 at 17:10 -0700, Michael Halstead wrote:
> > On 9/5/19 2:27 PM, richard.pur...@linuxfoundation.org wrote:
> > > On Thu, 2019-09-05 at 13:54 -0400, Mark Asselstine wrote:
> > > > Richard, are you thinking we need to figure out the
> > > > git.yoctoproject.org repo
> > > > before we can move ahead with merging this?
> > > 
> > > I would like to fix that, yes. I could ask Michael for help but I
> > > do
> > > have access to sort it myself too.
> > > 
> > > I'm also trying to sort out a few other issues before -next can
> > > merge.
> > > 
> > > Since I'm failing to get to it,
> > > 
> > > Michael,
> > > 
> > > Could you clone:
> > > 
> > > https://github.com/masselstine/kernel-module-hello-world.git
> > > 
> > > onto git.yp.org as a new repo and give write access to it for Mark,
> > > myself, Bruce and Ross please?
> > 
> > This repo is ready at
> > g...@push.yoctoproject.org:kernel-module-hello-world for the four of
> > you.
> > 
> > It is available read-only for anyone at,
> > 
> > git://git.yoctoproject.org/kernel-module-hello-world
> > 
> > and
> > 
> > https://git.yoctoproject.org/git/pokykernel-module-hello-world
> 
> Thanks Michael.
> 
> Mark: I tweaked your patch and its now merged (avoiding the typo
> above!)

Great, thanks Michael and RP for following through on this.

MarkA

> 
> Cheers,
> 
> Richard




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

Re: [OE-core] [PATCH][V2] sdkext: use simpler kernel module for devtool test

[Mark Asselstine]

On Thursday, August 22, 2019 11:56:16 A.M. EDT Mark Asselstine wrote:
> The current devtool test for the building of an out-of-tree kernel
> module uses something which requires several "high order" kconfigs to
> be set. This results in the test failing, not for expected reasons,
> but rather because it depends on specific kernel configuration.
> 
> You will get error messages such as
> 
>   ERROR: "video_ioctl2"
>  
> [.../1.0-r5/testsdkext/workspace/sources/v4l2loopback-driver/v4l2loopback.k
> o] undefined!
>   ERROR: "video_unregister_device"
>  
> [.../1.0-r5/testsdkext/workspace/sources/v4l2loopback-driver/v4l2loopback.k
> o] undefined!
> 
> Using a simpler hello-world kernel module example will only require
> that CONFIG_MODULE is enabled, thus avoiding a false positive.
> 
> Signed-off-by: Mark Asselstine 
> ---
> 
> **V2**
>  - also updated the CROPS manual test json file
>(I have no idea how to run this so untested but this is a straight
> substition)
>  - continue to use github until we can move the sample to somewhere
>like git.yoctoproject.org

Richard, are you thinking we need to figure out the git.yoctoproject.org repo 
before we can move ahead with merging this?

MarkA

> 
>  meta/lib/oeqa/manual/crops.json   | 12 ++--
>  meta/lib/oeqa/sdkext/cases/devtool.py |  4 ++--
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/meta/lib/oeqa/manual/crops.json
> b/meta/lib/oeqa/manual/crops.json index 1cf3c8f30c..071d35b661 100644
> --- a/meta/lib/oeqa/manual/crops.json
> +++ b/meta/lib/oeqa/manual/crops.json
> @@ -234,16 +234,16 @@
>  "expected_results": "this should output the directory
> of the devtool script and it should be within the sdk workdir you are
> working in.   \n\n" },
>  "5": {
> -"action": "devtool add v4l2loopback-driver 
> https://github.com/umlaeute/v4l2loopback.git   \n\n", -   
> "expected_results": "This should automatically create the recipe
> v4l2loopback-driver.bb under
> /recipes/v4l2loopback-driver/v4l2loopback-dri
> ver.bb " +"action": "devtool add
> kernel-module-hello-world 
> https://github.com/masselstine/kernel-module-hello-world.git   \n\n", +
>"expected_results": "This should automatically create the
> recipe kernel-module-hello-world.bb under
> /recipes/kernel-module-hello-world/kernel-mod
> ule-hello-world.bb " },
>  "6": {
> -"action": "devtool build v4l2loopback-driver   \n\n",
> +"action": "devtool build kernel-module-hello-world  
> \n\n", "expected_results": "This should compile an image   \n\n" },
>  "7": {
> -"action": "devtool reset v4l2loopback-driver   ",
> -"expected_results": "This cleans sysroot of the
> v4l2loopback-driver recipe, but it leaves the source tree intact. meaning
> it does not erase." +"action": "devtool reset
> kernel-module-hello-world   ", +"expected_results":
> "This cleans sysroot of the kernel-module-hello-world recipe, but it leaves
> the source tree intact. meaning it does not erase." }
>  },
>  "summary": "sdkext_devtool_kernelmodule"
> @@ -291,4 +291,4 @@
>  "summary": "sdkext_recipes_for_nodejs"
>  }
>  }
> -]
> \ No newline at end of file
> +]
> diff --git a/meta/lib/oeqa/sdkext/cases/devtool.py
> b/meta/lib/oeqa/sdkext/cases/devtool.py index 5a02add764..fad98fbb36 100644
> --- a/meta/lib/oeqa/sdkext/cases/devtool.py
> +++ b/meta/lib/oeqa/sdkext/cases/devtool.py
> @@ -73,8 +73,8 @@ class DevtoolTest(OESDKExtTestCase):
>  self._run('devtool reset %s' % recipe)
> 
>  def test_devtool_kernelmodule(self):
> -docfile = 'https://github.com/umlaeute/v4l2loopback.git'
> -recipe = 'v4l2loopback-driver'
> +docfile =
> 'https://github.com/masselstine/kernel-module-hello-world.git' +   
> recipe = 'kernel-module-hello-world'
>  self._run('devtool add %s %s' % (recipe, docfile) )
>  try:
>  self._run('devtool build %s' % recipe)




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

[OE-core] [PATCH][V2] sdkext: use simpler kernel module for devtool test

[Mark Asselstine]

The current devtool test for the building of an out-of-tree kernel
module uses something which requires several "high order" kconfigs to
be set. This results in the test failing, not for expected reasons,
but rather because it depends on specific kernel configuration.

You will get error messages such as

  ERROR: "video_ioctl2"
  [.../1.0-r5/testsdkext/workspace/sources/v4l2loopback-driver/v4l2loopback.ko]
  undefined!
  ERROR: "video_unregister_device"
  [.../1.0-r5/testsdkext/workspace/sources/v4l2loopback-driver/v4l2loopback.ko]
  undefined!

Using a simpler hello-world kernel module example will only require
that CONFIG_MODULE is enabled, thus avoiding a false positive.

Signed-off-by: Mark Asselstine 
---

**V2**
 - also updated the CROPS manual test json file
   (I have no idea how to run this so untested but this is a straight
substition)
 - continue to use github until we can move the sample to somewhere
   like git.yoctoproject.org

 meta/lib/oeqa/manual/crops.json   | 12 ++--
 meta/lib/oeqa/sdkext/cases/devtool.py |  4 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/meta/lib/oeqa/manual/crops.json b/meta/lib/oeqa/manual/crops.json
index 1cf3c8f30c..071d35b661 100644
--- a/meta/lib/oeqa/manual/crops.json
+++ b/meta/lib/oeqa/manual/crops.json
@@ -234,16 +234,16 @@
 "expected_results": "this should output the directory of 
the devtool script and it should be within the sdk workdir you are working in.  
 \n\n"
 },
 "5": {
-"action": "devtool add v4l2loopback-driver  
https://github.com/umlaeute/v4l2loopback.git   \n\n",
-"expected_results": "This should automatically create the 
recipe v4l2loopback-driver.bb under 
/recipes/v4l2loopback-driver/v4l2loopback-driver.bb
 "
+"action": "devtool add kernel-module-hello-world  
https://github.com/masselstine/kernel-module-hello-world.git   \n\n",
+"expected_results": "This should automatically create the 
recipe kernel-module-hello-world.bb under 
/recipes/kernel-module-hello-world/kernel-module-hello-world.bb
 "
 },
 "6": {
-"action": "devtool build v4l2loopback-driver   \n\n",
+"action": "devtool build kernel-module-hello-world   \n\n",
 "expected_results": "This should compile an image   \n\n"
 },
 "7": {
-"action": "devtool reset v4l2loopback-driver   ",
-"expected_results": "This cleans sysroot of the 
v4l2loopback-driver recipe, but it leaves the source tree intact. meaning it 
does not erase."
+"action": "devtool reset kernel-module-hello-world   ",
+"expected_results": "This cleans sysroot of the 
kernel-module-hello-world recipe, but it leaves the source tree intact. meaning 
it does not erase."
 }
 },
 "summary": "sdkext_devtool_kernelmodule"
@@ -291,4 +291,4 @@
 "summary": "sdkext_recipes_for_nodejs"
 }
 }
-]
\ No newline at end of file
+]
diff --git a/meta/lib/oeqa/sdkext/cases/devtool.py 
b/meta/lib/oeqa/sdkext/cases/devtool.py
index 5a02add764..fad98fbb36 100644
--- a/meta/lib/oeqa/sdkext/cases/devtool.py
+++ b/meta/lib/oeqa/sdkext/cases/devtool.py
@@ -73,8 +73,8 @@ class DevtoolTest(OESDKExtTestCase):
 self._run('devtool reset %s' % recipe)
 
 def test_devtool_kernelmodule(self):
-docfile = 'https://github.com/umlaeute/v4l2loopback.git'
-recipe = 'v4l2loopback-driver'
+docfile = 
'https://github.com/masselstine/kernel-module-hello-world.git'
+recipe = 'kernel-module-hello-world'
 self._run('devtool add %s %s' % (recipe, docfile) )
 try:
 self._run('devtool build %s' % recipe)
-- 
2.21.0

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

Re: [OE-core] [PATCH] sdkext: use simpler kernel module for devtool test

[Mark Asselstine]

On Wednesday, August 21, 2019 4:57:40 P.M. EDT Richard Purdie wrote:
> On Tue, 2019-08-20 at 13:52 -0400, Mark Asselstine wrote:
> > The current devtool test for the building of an out-of-tree kernel
> > module uses something which requires several "high order" kconfigs to
> > be set. This results in the test failing, not for expected reasons,
> > but rather because it depends on specific kernel configuration.
> > 
> > You will get error messages such as
> > 
> >   ERROR: "video_ioctl2"
> >   [.../1.0-r5/testsdkext/workspace/sources/v4l2loopback-
> > 
> > driver/v4l2loopback.ko]
> > 
> >   undefined!
> >   ERROR: "video_unregister_device"
> >   [.../1.0-r5/testsdkext/workspace/sources/v4l2loopback-
> > 
> > driver/v4l2loopback.ko]
> > 
> >   undefined!
> > 
> > Using a simpler hello-world kernel module example will only require
> > that CONFIG_MODULE is enabled, thus avoiding a false positive.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> > Richard, it is unclear if I need to match this change in
> > meta/lib/oeqa/manual/crops.json.
> 
> Those are manual tests for crops. They probably do also need this
> change as it would make them more reliable if/as anyone every automates
> them, or runs them manually.

I will affect the change there then too in the V2.

> 
> >  Please let me know and I
> > 
> > send a V2 which does this. I am not fond of pointing at
> > my own github but it was the best option to ensure it will
> > exist and not be messed with.
> 
> The best option may be to put that repo onto git.yoctoproject.org?

Not sure I get a vote but as far as the content goes I have no issue with it 
being elsewhere, like git.yoctoproject.org.

Mark

> 
> Cheers,
> 
> Richard




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

[OE-core] [PATCH] sdkext: use simpler kernel module for devtool test

[Mark Asselstine]

The current devtool test for the building of an out-of-tree kernel
module uses something which requires several "high order" kconfigs to
be set. This results in the test failing, not for expected reasons,
but rather because it depends on specific kernel configuration.

You will get error messages such as

  ERROR: "video_ioctl2"
  [.../1.0-r5/testsdkext/workspace/sources/v4l2loopback-driver/v4l2loopback.ko]
  undefined!
  ERROR: "video_unregister_device"
  [.../1.0-r5/testsdkext/workspace/sources/v4l2loopback-driver/v4l2loopback.ko]
  undefined!

Using a simpler hello-world kernel module example will only require
that CONFIG_MODULE is enabled, thus avoiding a false positive.

Signed-off-by: Mark Asselstine 
---

Richard, it is unclear if I need to match this change in
meta/lib/oeqa/manual/crops.json. Please let me know and I
send a V2 which does this. I am not fond of pointing at
my own github but it was the best option to ensure it will
exist and not be messed with.

 meta/lib/oeqa/sdkext/cases/devtool.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/sdkext/cases/devtool.py 
b/meta/lib/oeqa/sdkext/cases/devtool.py
index 5a02add764..fad98fbb36 100644
--- a/meta/lib/oeqa/sdkext/cases/devtool.py
+++ b/meta/lib/oeqa/sdkext/cases/devtool.py
@@ -73,8 +73,8 @@ class DevtoolTest(OESDKExtTestCase):
 self._run('devtool reset %s' % recipe)
 
 def test_devtool_kernelmodule(self):
-docfile = 'https://github.com/umlaeute/v4l2loopback.git'
-recipe = 'v4l2loopback-driver'
+docfile = 
'https://github.com/masselstine/kernel-module-hello-world.git'
+recipe = 'kernel-module-hello-world'
 self._run('devtool add %s %s' % (recipe, docfile) )
 try:
 self._run('devtool build %s' % recipe)
-- 
2.21.0

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

[OE-core] [PATCH] xfconf: fix 'Failed to get connection to xfconfd' during do_rootfs

[Mark Asselstine]

Packages such as gdk-pixbuf can result in the following error during
the rootfs construction:
  CRITICAL **: 16:51:57.223: Failed to get connection to xfconfd: Cannot 
autolaunch D-Bus without X11 $DISPLAY

This is hit during the postinst-intercepts/update_pixbuf_cache.

Based on discussions upstream this appears to be an issue for xfconf
and has an upstream update

https://git.xfce.org/xfce/xfconf/commit?id=6f11cc65a2213f424728b5a0d25b1b63c19e773e

Drawing from this change we can go ahead and use PACKAGECONFIG to
emulate it.

Signed-off-by: Mark Asselstine 
---

Guys,

This is still broken in Yocto and I would like to see it fixed. I haven't
dug into the issue as much as you two so I wanted to float this fix
out there but hold back from calling it a proper fix. Please let
me know what you think or feel free to take this, evaluate it and
modify it into a full fledged fix.

MarkA


 meta-xfce/recipes-xfce/xfconf/xfconf_4.13.6.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-xfce/recipes-xfce/xfconf/xfconf_4.13.6.bb 
b/meta-xfce/recipes-xfce/xfconf/xfconf_4.13.6.bb
index 2667ff9..22a7bc1 100644
--- a/meta-xfce/recipes-xfce/xfconf/xfconf_4.13.6.bb
+++ b/meta-xfce/recipes-xfce/xfconf/xfconf_4.13.6.bb
@@ -16,3 +16,5 @@ FILES_${PN} += "${libdir}/xfce4/xfconf/xfconfd \
 ${datadir}/dbus-1/services/org.xfce.Xfconf.service"
 
 FILES_${PN}-dev += "${libdir}/gio/modules/libxfconfgsettingsbackend.la"
+
+PACKAGECONFIG[gsettings-backend] = ",--disable-gsettings-backend,"
-- 
2.7.4

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

[OE-core] [v4][PATCH 1/2] go.bbclass: Export more GO* environment variables

[Mark Asselstine]

Currently we are not doing a good job of consolidating GO environment
variables used by the go build system in the go.bbclass, instead we
are relying on the individual GO recipe authors to perform the
exports. This can result in inconsistent build results and often
binaries that are not properly cross compiled, resulting in segfaults
when the applications are run on the target.

For example the GO documentation recommends that the environment
include a value assigned to GOARM when cross building for ARMv5, ARMv6
and ARMv7 (https://github.com/golang/go/wiki/GoArm).

In order to avoid polluting the build scripts with unnecessary
exports, such as run.do_compile, we attempt to only export variables
when they apply to a specific arch.

Signed-off-by: Mark Asselstine 
---

V2
* Avoid potential undefined situations

V3
* Add more exports to cover the basics
* Tested on all qemu* variants, -native and build test other BSPs

V4
* Drop i586 since x86 is already also in the overrides

 meta/classes/go.bbclass | 17 +
 1 file changed, 17 insertions(+)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index 7069c5f..7f5e8b9 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -8,6 +8,23 @@ GOROOT = "${STAGING_LIBDIR}/go"
 export GOROOT
 export GOROOT_FINAL = "${libdir}/go"
 
+export GOARCH = "${TARGET_GOARCH}"
+export GOOS = "${TARGET_GOOS}"
+export GOHOSTARCH="${BUILD_GOARCH}"
+export GOHOSTOS="${BUILD_GOOS}"
+
+GOARM[export] = "0"
+GOARM_arm_class-target = "${TARGET_GOARM}"
+GOARM_arm_class-target[export] = "1"
+
+GO386[export] = "0"
+GO386_x86_class-target = "${TARGET_GO386}"
+GO386_x86_class-target[export] = "1"
+
+GOMIPS[export] = "0"
+GOMIPS_mips_class-target = "${TARGET_GOMIPS}"
+GOMIPS_mips_class-target[export] = "1"
+
 DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go 
virtual/${TARGET_PREFIX}go-runtime"
 DEPENDS_GOLANG_class-native = "go-native"
 DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk 
virtual/${TARGET_PREFIX}go-runtime"
-- 
2.7.4

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

[OE-core] [v4][PATCH 2/2] goarch.bbclass: use MACHINEOVERRIDES and simplify go_map_arm()

[Mark Asselstine]

Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
cross building for ARMv5, ARMv6 and ARMv7. The current approach of
using TUNE_FEATURES can be error prone, as we can see today when
attempting to build for Cortex-A7 which results in GOARM=''.

Since the value of MACHINEOVERRIDES already consolidates the values of
TUNE_FEATURES into something more consistent we can use the overrides
mechanism to set GOARM, leaving just a little bit of logic in
go_map_arm() to trigger off the arch (basically target vs host)
for the setting of GOARM.

Signed-off-by: Mark Asselstine 
---

V2
* Cover all ARMv7 Cortex* variants

V3
* Switch to using MACHINEOVERRIDES/overrides mechanism

V4
* Access BASE_GOARM directly instead of as a func param
* Avoid using a slow regex


 meta/classes/goarch.bbclass | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 7aaf26a..166dea9 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -3,18 +3,26 @@ BUILD_GOARCH = "${@go_map_arch(d.getVar('BUILD_ARCH'), d)}"
 BUILD_GOTUPLE = "${BUILD_GOOS}_${BUILD_GOARCH}"
 HOST_GOOS = "${@go_map_os(d.getVar('HOST_OS'), d)}"
 HOST_GOARCH = "${@go_map_arch(d.getVar('HOST_ARCH'), d)}"
-HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), 
d)}"
+HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), d)}"
 HOST_GO386 = "${@go_map_386(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), 
d)}"
 HOST_GOMIPS = "${@go_map_mips(d.getVar('HOST_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 HOST_GOTUPLE = "${HOST_GOOS}_${HOST_GOARCH}"
 TARGET_GOOS = "${@go_map_os(d.getVar('TARGET_OS'), d)}"
 TARGET_GOARCH = "${@go_map_arch(d.getVar('TARGET_ARCH'), d)}"
-TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
+TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), d)}"
 TARGET_GO386 = "${@go_map_386(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 TARGET_GOMIPS = "${@go_map_mips(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 TARGET_GOTUPLE = "${TARGET_GOOS}_${TARGET_GOARCH}"
 GO_BUILD_BINDIR = "${@['bin/${HOST_GOTUPLE}','bin'][d.getVar('BUILD_GOTUPLE') 
== d.getVar('HOST_GOTUPLE')]}"
 
+# Use the MACHINEOVERRIDES to map ARM CPU architecture passed to GO via GOARM.
+# This is combined with *_ARCH to set HOST_GOARM and TARGET_GOARM.
+BASE_GOARM = ''
+BASE_GOARM_armv7ve = '7'
+BASE_GOARM_armv7a = '7'
+BASE_GOARM_armv6 = '6'
+BASE_GOARM_armv5 = '5'
+
 # Go supports dynamic linking on a limited set of architectures.
 # See the supportsDynlink function in go/src/cmd/compile/internal/gc/main.go
 GO_DYNLINK = ""
@@ -73,15 +81,9 @@ def go_map_arch(a, d):
 else:
 raise bb.parse.SkipRecipe("Unsupported CPU architecture: %s" % a)
 
-def go_map_arm(a, f, d):
-import re
-if re.match('arm.*', a):
-if 'armv7' in f:
-return '7'
-elif 'armv6' in f:
-return '6'
-elif 'armv5' in f:
-return '5'
+def go_map_arm(a, d):
+if a.startswith("arm"):
+return d.getVar('BASE_GOARM')
 return ''
 
 def go_map_386(a, f, d):
-- 
2.7.4

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

Re: [OE-core] [v3][PATCH 2/2] goarch.bbclass: use MACHINEOVERRIDES and simplify go_map_arm()

[Mark Asselstine]

On Monday, March 18, 2019 12:40:28 PM EDT Martin Jansa wrote:
> On Mon, Mar 18, 2019 at 11:21:53AM -0400, Mark Asselstine wrote:
> > Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
> > cross building for ARMv5, ARMv6 and ARMv7. The current approach of
> > using TUNE_FEATURES can be error prone, as we can see today when
> > attempting to build for Cortex-A7 which results in GOARM=''.
> > 
> > Since the value of MACHINEOVERRIDES already consolidates the values of
> > TUNE_FEATURES into something more consistent we can use the overrides
> > mechanism to set GOARM, leaving just a little bit of logic in
> > go_map_arm() to trigger off the arch (basically target vs host)
> > for the setting of GOARM.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> > V2
> > * Cover all ARMv7 Cortex* variants
> > 
> > V3
> > * Switch to using MACHINEOVERRIDES/overrides mechanism
> > 
> >  meta/classes/goarch.bbclass | 19 +++
> >  1 file changed, 11 insertions(+), 8 deletions(-)
> > 
> > diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> > index 39fea5e..8fdb443 100644
> > --- a/meta/classes/goarch.bbclass
> > +++ b/meta/classes/goarch.bbclass
> > @@ -3,18 +3,26 @@ BUILD_GOARCH = "${@go_map_arch(d.getVar('BUILD_ARCH'),
> > d)}"> 
> >  BUILD_GOTUPLE = "${BUILD_GOOS}_${BUILD_GOARCH}"
> >  HOST_GOOS = "${@go_map_os(d.getVar('HOST_OS'), d)}"
> >  HOST_GOARCH = "${@go_map_arch(d.getVar('HOST_ARCH'), d)}"
> > 
> > -HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'),
> > d.getVar('TUNE_FEATURES'), d)}" +HOST_GOARM =
> > "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('BASE_GOARM'), d)}"> 
> >  HOST_GO386 = "${@go_map_386(d.getVar('HOST_ARCH'),
> >  d.getVar('TUNE_FEATURES'), d)}" HOST_GOMIPS =
> >  "${@go_map_mips(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
> >  HOST_GOTUPLE = "${HOST_GOOS}_${HOST_GOARCH}"
> >  TARGET_GOOS = "${@go_map_os(d.getVar('TARGET_OS'), d)}"
> >  TARGET_GOARCH = "${@go_map_arch(d.getVar('TARGET_ARCH'), d)}"
> > 
> > -TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'),
> > d.getVar('TUNE_FEATURES'), d)}" +TARGET_GOARM =
> > "${@go_map_arm(d.getVar('TARGET_ARCH'), d.getVar('BASE_GOARM'), d)}"> 
> >  TARGET_GO386 = "${@go_map_386(d.getVar('TARGET_ARCH'),
> >  d.getVar('TUNE_FEATURES'), d)}" TARGET_GOMIPS =
> >  "${@go_map_mips(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}"
> >  TARGET_GOTUPLE = "${TARGET_GOOS}_${TARGET_GOARCH}"
> >  GO_BUILD_BINDIR =
> >  "${@['bin/${HOST_GOTUPLE}','bin'][d.getVar('BUILD_GOTUPLE') ==
> >  d.getVar('HOST_GOTUPLE')]}"> 
> > +# Use the MACHINEOVERRIDES to map ARM CPU architecture passed to GO via
> > GOARM. +# This is combined with *_ARCH to set HOST_GOARM and
> > TARGET_GOARM. +BASE_GOARM = ''
> > +BASE_GOARM_armv7ve = '7'
> > +BASE_GOARM_armv7a = '7'
> > +BASE_GOARM_armv6 = '6'
> > +BASE_GOARM_armv5 = '5'
> > +
> > 
> >  # Go supports dynamic linking on a limited set of architectures.
> >  # See the supportsDynlink function in
> >  go/src/cmd/compile/internal/gc/main.go GO_DYNLINK = ""
> > 
> > @@ -74,12 +82,7 @@ def go_map_arch(a, d):
> >  def go_map_arm(a, f, d):
> >  import re
> > 
> >  if re.match('arm.*', a):
> > -if 'armv7' in f:
> > -return '7'
> > -elif 'armv6' in f:
> > -return '6'
> > -elif 'armv5' in f:
> > -return '5'
> > +return f
> > 
> >  return ''
> 
> Is this function still useful? Cannot you set TARGET_GOARM and
> HOST_GOARM with arm override (to simulate the effect of "re.match('arm.*',
> a)")?

No. Attempting to use the override will not result in the same result for 
HOST_GOARM. The overrides will represent the target and not the host. Unless 
you have an implementation to backup your suggestion and I am just not seeing 
it.

MarkA

> 
> Regards,
> 
> >  def go_map_386(a, f, d):




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

[OE-core] [v3][PATCH 1/2] go.bbclass: Export more GO* environment variables

[Mark Asselstine]

Currently we are not doing a good job of consolidating GO environment
variables used by the go build system in the go.bbclass, instead we
are relying on the individual GO recipe authors to perform the
exports. This can result in inconsistent build results and often
binaries that are not properly cross compiled, resulting in segfaults
when the applications are run on the target.

For example the GO documentation recommends that the environment
include a value assigned to GOARM when cross building for ARMv5, ARMv6
and ARMv7 (https://github.com/golang/go/wiki/GoArm).

In order to avoid polluting the build scripts with unnecessary
exports, such as run.do_compile, we attempt to only export variables
when they apply to a specific arch.

Signed-off-by: Mark Asselstine 
---

V2
* Avoid potential undefined situations

V3
* Add more exports to cover the basics
* Tested on all qemu* variants, -native and build test other BSPs

 meta/classes/go.bbclass | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index 7069c5f..78c2d68 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -8,6 +8,25 @@ GOROOT = "${STAGING_LIBDIR}/go"
 export GOROOT
 export GOROOT_FINAL = "${libdir}/go"
 
+export GOARCH = "${TARGET_GOARCH}"
+export GOOS = "${TARGET_GOOS}"
+export GOHOSTARCH="${BUILD_GOARCH}"
+export GOHOSTOS="${BUILD_GOOS}"
+
+GOARM[export] = "0"
+GOARM_arm_class-target = "${TARGET_GOARM}"
+GOARM_arm_class-target[export] = "1"
+
+GO386[export] = "0"
+GO386_x86_class-target = "${TARGET_GO386}"
+GO386_x86_class-target[export] = "1"
+GO386_i586_class-target = "${TARGET_GO386}"
+GO386_i586_class-target[export] = "1"
+
+GOMIPS[export] = "0"
+GOMIPS_mips_class-target = "${TARGET_GOMIPS}"
+GOMIPS_mips_class-target[export] = "1"
+
 DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go 
virtual/${TARGET_PREFIX}go-runtime"
 DEPENDS_GOLANG_class-native = "go-native"
 DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk 
virtual/${TARGET_PREFIX}go-runtime"
-- 
2.7.4

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

[OE-core] [v3][PATCH 2/2] goarch.bbclass: use MACHINEOVERRIDES and simplify go_map_arm()

[Mark Asselstine]

Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
cross building for ARMv5, ARMv6 and ARMv7. The current approach of
using TUNE_FEATURES can be error prone, as we can see today when
attempting to build for Cortex-A7 which results in GOARM=''.

Since the value of MACHINEOVERRIDES already consolidates the values of
TUNE_FEATURES into something more consistent we can use the overrides
mechanism to set GOARM, leaving just a little bit of logic in
go_map_arm() to trigger off the arch (basically target vs host)
for the setting of GOARM.

Signed-off-by: Mark Asselstine 
---

V2
* Cover all ARMv7 Cortex* variants

V3
* Switch to using MACHINEOVERRIDES/overrides mechanism

 meta/classes/goarch.bbclass | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 39fea5e..8fdb443 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -3,18 +3,26 @@ BUILD_GOARCH = "${@go_map_arch(d.getVar('BUILD_ARCH'), d)}"
 BUILD_GOTUPLE = "${BUILD_GOOS}_${BUILD_GOARCH}"
 HOST_GOOS = "${@go_map_os(d.getVar('HOST_OS'), d)}"
 HOST_GOARCH = "${@go_map_arch(d.getVar('HOST_ARCH'), d)}"
-HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), 
d)}"
+HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('BASE_GOARM'), d)}"
 HOST_GO386 = "${@go_map_386(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), 
d)}"
 HOST_GOMIPS = "${@go_map_mips(d.getVar('HOST_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 HOST_GOTUPLE = "${HOST_GOOS}_${HOST_GOARCH}"
 TARGET_GOOS = "${@go_map_os(d.getVar('TARGET_OS'), d)}"
 TARGET_GOARCH = "${@go_map_arch(d.getVar('TARGET_ARCH'), d)}"
-TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
+TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), d.getVar('BASE_GOARM'), 
d)}"
 TARGET_GO386 = "${@go_map_386(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 TARGET_GOMIPS = "${@go_map_mips(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 TARGET_GOTUPLE = "${TARGET_GOOS}_${TARGET_GOARCH}"
 GO_BUILD_BINDIR = "${@['bin/${HOST_GOTUPLE}','bin'][d.getVar('BUILD_GOTUPLE') 
== d.getVar('HOST_GOTUPLE')]}"
 
+# Use the MACHINEOVERRIDES to map ARM CPU architecture passed to GO via GOARM.
+# This is combined with *_ARCH to set HOST_GOARM and TARGET_GOARM.
+BASE_GOARM = ''
+BASE_GOARM_armv7ve = '7'
+BASE_GOARM_armv7a = '7'
+BASE_GOARM_armv6 = '6'
+BASE_GOARM_armv5 = '5'
+
 # Go supports dynamic linking on a limited set of architectures.
 # See the supportsDynlink function in go/src/cmd/compile/internal/gc/main.go
 GO_DYNLINK = ""
@@ -74,12 +82,7 @@ def go_map_arch(a, d):
 def go_map_arm(a, f, d):
 import re
 if re.match('arm.*', a):
-if 'armv7' in f:
-return '7'
-elif 'armv6' in f:
-return '6'
-elif 'armv5' in f:
-return '5'
+return f
 return ''
 
 def go_map_386(a, f, d):
-- 
2.7.4

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

Re: [OE-core] [v2][PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for valid cortexa* targets

[Mark Asselstine]

On Friday, March 15, 2019 9:28:16 AM EDT Mark Asselstine wrote:
> On Thursday, March 14, 2019 7:44:36 PM EDT Andre McCurdy wrote:
> > On Thu, Mar 14, 2019 at 1:05 PM Mark Asselstine
> > 
> >  wrote:
> > > Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
> > > building for ARMv5, ARMv6 and ARMv7. The current code in go_map_arm()
> > > does not account for the Cortex* TUNINGs and as such misses several
> > > Cortex variants which implement ARMv7. Here we add an additional check
> > > that will include Cortex-A5 through Cortex-A17 as ARMv7 variants
> > > (ie. GOARM='7'). The Cortex-R and Cortex-M variants are also captured
> > > even though there are no tunings for these currently (lack MMU support
> > > so not supported).
> > > 
> > > Signed-off-by: Mark Asselstine 
> > > ---
> > > 
> > > V2
> > > * Cover all ARMv7 Cortex* variants
> > 
> > Still worried this might not be complete. It's basically fixing the
> > fallout from Khem's patches to remove -march options from the CPU
> > specific ARM machine includes, right?
> 
> Although this came in via meta-virtualization, which I usually review most
> changes, I wasn't involved in the original implementation or discussion of
> go_map_arm() and since I was simply extending the existing framework I
> didn't go back and look into the history.
> 
> Looking now I don't see any specific discussions as to why TUNE_FEATURES
> were used instead of something else, such as the overrides. My guess is it
> had to be something and the original implementation was incorrectly
> oversimplified so the level of complexity was equivalent to any other
> choice.
> 
> At any rate I will review if changing to something else such as overrides
> would simplify the now more complex logic but until I investigate I would
> hesitate to say that the approach will be any less prone to breaking.
> 
> > If so then any ARM machine with
> > CPU specific tuning (other than cortex) is still going to be affected.
> > 
> > What's the reason for parsing TUNE_FEATURES to detect the ARM
> > architecture level?
> 
> That's just what was in place when I started to work on this.
> 
> > Couldn't GOARM be set correctly just by using of
> > the _armv5, _armv6, _armv7a and _armv7ve over-rides?
> 
> At a quick glance I would say yes, but again I need to poke around to see if
> this is just swapping one thing for another with no real gains.

The MACHINEOVERRIDES do already distill down the TUNE_FEATURES so yes we could 
potentially use this to the logic from getting more complex. After digging 
around the various tuning/maching/arch files I don't see any exceptions (at 
least none are immediately visible). Would you be happier with the following:

---
 HOST_GOARCH = "${@go_map_arch(d.getVar('HOST_ARCH'), d)}"
-HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), 
d)}"
+HOST_GOARM = "${@go_map_arm(d.getVar('HOST_ARCH'), d.getVar('BASE_GOARM'), d)}"
 HOST_GO386 = "${@go_map_386(d.getVar('HOST_ARCH'), d.getVar('TUNE_FEATURES'), 
d)}"
 HOST_GOMIPS = "${@go_map_mips(d.getVar('HOST_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 HOST_GOTUPLE = "${HOST_GOOS}_${HOST_GOARCH}"
 TARGET_GOOS = "${@go_map_os(d.getVar('TARGET_OS'), d)}"
 TARGET_GOARCH = "${@go_map_arch(d.getVar('TARGET_ARCH'), d)}"
-TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
+TARGET_GOARM = "${@go_map_arm(d.getVar('TARGET_ARCH'), d.getVar('BASE_GOARM'), 
d)}"
 TARGET_GO386 = "${@go_map_386(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 TARGET_GOMIPS = "${@go_map_mips(d.getVar('TARGET_ARCH'), 
d.getVar('TUNE_FEATURES'), d)}"
 TARGET_GOTUPLE = "${TARGET_GOOS}_${TARGET_GOARCH}"
 GO_BUILD_BINDIR = "${@['bin/${HOST_GOTUPLE}','bin'][d.getVar('BUILD_GOTUPLE') 
== d.getVar('HOST_GOTUPLE')]}"
 
+# Use the MACHINEOVERRIDES to map ARM CPU architecture passed to GO via GOARM.
+# This is combined with *_ARCH to set HOST_GOARM and TARGET_GOARM.
+BASE_GOARM = ''
+BASE_GOARM_armv7ve = '7'
+BASE_GOARM_armv7a = '7'
+BASE_GOARM_armv6 = '6'
+BASE_GOARM_armv5 = '5'
+
 # Go supports dynamic linking on a limited set of architectures.
 # See the supportsDynlink function in go/src/cmd/compile/internal/gc/main.go
 GO_DYNLINK = ""
@@ -74,

Re: [OE-core] [v2][PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for valid cortexa* targets

[Mark Asselstine]

On Thursday, March 14, 2019 7:44:36 PM EDT Andre McCurdy wrote:
> On Thu, Mar 14, 2019 at 1:05 PM Mark Asselstine
> 
>  wrote:
> > Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
> > building for ARMv5, ARMv6 and ARMv7. The current code in go_map_arm()
> > does not account for the Cortex* TUNINGs and as such misses several
> > Cortex variants which implement ARMv7. Here we add an additional check
> > that will include Cortex-A5 through Cortex-A17 as ARMv7 variants
> > (ie. GOARM='7'). The Cortex-R and Cortex-M variants are also captured
> > even though there are no tunings for these currently (lack MMU support
> > so not supported).
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> > V2
> > * Cover all ARMv7 Cortex* variants
> 
> Still worried this might not be complete. It's basically fixing the
> fallout from Khem's patches to remove -march options from the CPU
> specific ARM machine includes, right? 

Although this came in via meta-virtualization, which I usually review most 
changes, I wasn't involved in the original implementation or discussion of 
go_map_arm() and since I was simply extending the existing framework I didn't 
go back and look into the history.

Looking now I don't see any specific discussions as to why TUNE_FEATURES were 
used instead of something else, such as the overrides. My guess is it had to 
be something and the original implementation was incorrectly oversimplified so 
the level of complexity was equivalent to any other choice.

At any rate I will review if changing to something else such as overrides 
would simplify the now more complex logic but until I investigate I would 
hesitate to say that the approach will be any less prone to breaking.

> If so then any ARM machine with
> CPU specific tuning (other than cortex) is still going to be affected.
> 
> What's the reason for parsing TUNE_FEATURES to detect the ARM
> architecture level?

That's just what was in place when I started to work on this.

> Couldn't GOARM be set correctly just by using of
> the _armv5, _armv6, _armv7a and _armv7ve over-rides?

At a quick glance I would say yes, but again I need to poke around to see if 
this is just swapping one thing for another with no real gains.

> 
>   https://github.com/golang/go/wiki/GoArm

I already reference this in my commit log. Is there a reason you are 
highlighting this again?

MarkA

> 
> >  meta/classes/goarch.bbclass | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> > index 39fea5e..84977a5 100644
> > --- a/meta/classes/goarch.bbclass
> > +++ b/meta/classes/goarch.bbclass
> > 
> > @@ -74,6 +74,10 @@ def go_map_arch(a, d):
> >  def go_map_arm(a, f, d):
> >  import re
> > 
> >  if re.match('arm.*', a):
> > +for el in f.split():
> > +m = re.match("cortex[arm](\d.*)", el)
> > +if m and int(m.group(1)) < 32:
> > +   return '7'
> > 
> >  if 'armv7' in f:
> >  return '7'
> >  
> >  elif 'armv6' in f:
> > --
> > 2.7.4
> > 
> > --
> > ___
> > 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] [v2][PATCH 1/2] go.bbclass: Export GOARM

[Mark Asselstine]

On Friday, March 15, 2019 12:39:26 AM EDT Khem Raj wrote:
> On Thu, Mar 14, 2019 at 1:05 PM Mark Asselstine
> 
>  wrote:
> > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > GOARM env variable is set during the build. Not having GOARM exported
> > will result in GO binaries which can't be executed on the target
> > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > 
> > We already have the logic in goarch.bbclass to determine the correct
> > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > GOARM = "${TARGET_GOARM}").
> > 
> > Here we export GOARM but we do it such that it is only exported if we
> > are building for 'arm' and only when recipes requiring/inheriting
> > go.bbclass are be used to build for the target.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> > V2
> > * Avoid potential undefined situations
> > 
> >  meta/classes/go.bbclass | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > index af331f8..5af4c3e 100644
> > --- a/meta/classes/go.bbclass
> > +++ b/meta/classes/go.bbclass
> > @@ -8,6 +8,10 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > 
> >  export GOROOT
> >  export GOROOT_FINAL = "${libdir}/go"
> > 
> > +GOARM[export] = "0"
> > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > +GOARM_arm_class-target[export] = "1"
> > +
> 
> while this works, I think it would be nicer to handle it for all
> 
> export GOHOSTOS = "${BUILD_GOOS}"
> export GOHOSTARCH = "${BUILD_GOARCH}"
> export GOOS = "${TARGET_GOOS}"
> export GOARCH = "${TARGET_GOARCH}"
> export GOARM = "${TARGET_GOARM}"
> export GO386 = "${TARGET_GO386}"
> export GOMIPS = "${TARGET_GOMIPS}"
> 
> these should all be replicated into bbclass.

I had thought about doing this but was using GOARM as a trial balloon as I had 
a suitable build and testcase handy to sort through any issues. I will come 
back around to these as I get time, if that's OK with folks.

MarkA

> 
> >  DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> >  virtual/${TARGET_PREFIX}go-runtime" DEPENDS_GOLANG_class-native =
> >  "go-native"
> >  DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> >  virtual/${TARGET_PREFIX}go-runtime"> 
> > --
> > 2.7.4
> > 
> > --
> > ___
> > 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 2/2] goarch.bbclass: set TARGET_GOARM as '7' for cortexa7

[Mark Asselstine]

On Friday, March 15, 2019 1:42:55 AM EDT Khem Raj wrote:
> On Wed, Mar 13, 2019 at 1:04 PM Mark Asselstine
> 
>  wrote:
> > On Wednesday, March 13, 2019 3:56:10 PM EDT Andre McCurdy wrote:
> > > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine
> > > 
> > >  wrote:
> > > > The cortexa7 tunings use 'cortexa7' in their tunings and do not
> > > > include 'arm7' so we need to look for both when setting TARGET_GOARM.
> > > 
> > > Is cortexa7 a special case? Or will the same issue be there for
> > > cortexa5, cortexa9, cortexa15, etc?
> > 
> > Damn, was too fucused on the 1/2 patch of this RR I had my blinders on.
> > Yes I should be looking for cortexa* as I believe they all fall in to the
> > "7"
> keep in mind we might have cortex-a53 etc which are v8

GOARM is not applicable to ARMv8, only v5, v6 and v7. I added the link to the 
documentation in the V2 along with additional notes to make this clear.

MarkA

> 
> > bucket. I will redo this and after we sort out 1/2 I will send a v2.
> > 
> > MarkA
> > 
> > > > Signed-off-by: Mark Asselstine 
> > > > ---
> > > > 
> > > >  meta/classes/goarch.bbclass | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> > > > index 39fea5e..077c967 100644
> > > > --- a/meta/classes/goarch.bbclass
> > > > +++ b/meta/classes/goarch.bbclass
> > > > 
> > > > @@ -74,7 +74,7 @@ def go_map_arch(a, d):
> > > >  def go_map_arm(a, f, d):
> > > >  import re
> > > > 
> > > >  if re.match('arm.*', a):
> > > > -if 'armv7' in f:
> > > > 
> > > > +if 'armv7' or 'cortexa7' in f:
> > > >  return '7'
> > > >  
> > > >  elif 'armv6' in f:
> > > >  return '6'
> > > > 
> > > > --
> > > > 2.7.4
> > > > 
> > > > --
> > > > ___
> > > > 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




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

[OE-core] [v2][PATCH 1/2] go.bbclass: Export GOARM

[Mark Asselstine]

When building GO packages for ARM (v5, v6, v7) it is expected that the
GOARM env variable is set during the build. Not having GOARM exported
will result in GO binaries which can't be executed on the target
(terminate with segfault). Per https://github.com/golang/go/wiki/GoArm

We already have the logic in goarch.bbclass to determine the correct
value of GOARM (see GOARM_TARGET), but currently this is only used to
build go itself (go-cross_1.*.bb requires go-cross.inc --> export
GOARM = "${TARGET_GOARM}").

Here we export GOARM but we do it such that it is only exported if we
are building for 'arm' and only when recipes requiring/inheriting
go.bbclass are be used to build for the target.

Signed-off-by: Mark Asselstine 
---

V2
* Avoid potential undefined situations

 meta/classes/go.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index af331f8..5af4c3e 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -8,6 +8,10 @@ GOROOT = "${STAGING_LIBDIR}/go"
 export GOROOT
 export GOROOT_FINAL = "${libdir}/go"
 
+GOARM[export] = "0"
+GOARM_arm_class-target = "${TARGET_GOARM}"
+GOARM_arm_class-target[export] = "1"
+
 DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go 
virtual/${TARGET_PREFIX}go-runtime"
 DEPENDS_GOLANG_class-native = "go-native"
 DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk 
virtual/${TARGET_PREFIX}go-runtime"
-- 
2.7.4

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

[OE-core] [v2][PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for valid cortexa* targets

[Mark Asselstine]

Per https://github.com/golang/go/wiki/GoArm we need to set GOARM when
building for ARMv5, ARMv6 and ARMv7. The current code in go_map_arm()
does not account for the Cortex* TUNINGs and as such misses several
Cortex variants which implement ARMv7. Here we add an additional check
that will include Cortex-A5 through Cortex-A17 as ARMv7 variants
(ie. GOARM='7'). The Cortex-R and Cortex-M variants are also captured
even though there are no tunings for these currently (lack MMU support
so not supported).

Signed-off-by: Mark Asselstine 
---

V2
* Cover all ARMv7 Cortex* variants


 meta/classes/goarch.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 39fea5e..84977a5 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -74,6 +74,10 @@ def go_map_arch(a, d):
 def go_map_arm(a, f, d):
 import re
 if re.match('arm.*', a):
+for el in f.split():
+m = re.match("cortex[arm](\d.*)", el)
+if m and int(m.group(1)) < 32:
+   return '7'
 if 'armv7' in f:
 return '7'
 elif 'armv6' in f:
-- 
2.7.4

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

Re: [OE-core] [PATCH 1/2] go.bbclass: Export GOARM

[Mark Asselstine]

On Thursday, March 14, 2019 2:44:35 PM EDT Christopher Larson wrote:
> Good to know, thanks. Possibly something to improve in bitbake at some
> point in the future.

This is what I am preparing to send out

---
GOARM[export] = "0"
GOARM_arm_class-target = "${TARGET_GOARM}"  

  
GOARM_arm_class-target[export] = "1"

  
---

This should address Mark Hatle's concerns about GOARM being undefined/have 
deterministic behavior. For non-'arm' the export simply won't be present so it 
doesn't matter what GOARM is, for 'arm' we get what we want. And I get what I 
was aiming for, no environment pollution in run.do_compile and friends for 
non-'arm'.

I know it isn't really used elsewhere but I don't believe I am making any 
assumptions or using things in a way they shouldn't be used. At any rate I 
will send this out in 20 minutes or so and we'll see how it stands up.

MarkA

> 
> On Thu, Mar 14, 2019 at 11:32 AM Mark Asselstine <
> 
> mark.asselst...@windriver.com> wrote:
> > On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> > > How would bitbake respond to an ‘export’ line with the empty string?
> > > I.e.
> > > can you do an actual conditional export the way we do conditional
> > 
> > inherits,
> > 
> > > so it still is only exported for arm, even if the value is set to the
> > 
> > empty
> > 
> > > string for others?
> > 
> > Unfortunately no. It is a parsing error.
> > 
> > I am working on alternatives and will hopefully have something out
> > shortly.
> > 
> > MarkA
> > 
> > > On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
> > > 
> > > mark.asselst...@windriver.com> wrote:
> > > > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > > > GOARM env variable is set during the build. Not having GOARM exported
> > > > will result in GO binaries which can't be executed on the target
> > > > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > > > 
> > > > We already have the logic in goarch.bbclass to determine the correct
> > > > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > > > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > > > GOARM = "${TARGET_GOARM}").
> > > > 
> > > > Here we export GOARM but we do it such that it is only exported if we
> > > > are building for 'arm' and only when recipes requiring/inheriting
> > > > go.bbclass are be used to build for the target.
> > > > 
> > > > Signed-off-by: Mark Asselstine 
> > > > ---
> > > > 
> > > > Richard,
> > > > 
> > > > MarkH and I were debating this one some. He was suggesting I add
> > > > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > > > builds. I however, like the behavior of this as submitted here as
> > > > non-arm target builds don't get polluted with a useless export in
> > > > their do_compile scripts and such. The question is as presented here
> > > > is the behavior deterministic?
> > > > 
> > > > 
> > > > meta/classes/go.bbclass | 3 +++
> > > > 
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > > > index af331f8..72e2c29 100644
> > > > --- a/meta/classes/go.bbclass
> > > > +++ b/meta/classes/go.bbclass
> > > > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > > > 
> > > >  export GOROOT
> > > >  export GOROOT_FINAL = "${libdir}/go"
> > > > 
> > > > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > > > +export GOARM
> > > > +
> > > > 
> > > >  DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> > > > 
> > > > virtual/${TARGET_PREFIX}go-runtime"
> > > > 
> > > >  DEPENDS_GOLANG_class-native = "go-native"
> > > >  DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> > > > 
> > > > virtual/${TARGET_PREFIX}go-runtime"
> > > > --
> > > > 2.7.4
> > > > 
> > > > --
> > > > ___
> > > > 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 1/2] go.bbclass: Export GOARM

[Mark Asselstine]

On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> How would bitbake respond to an ‘export’ line with the empty string? I.e.
> can you do an actual conditional export the way we do conditional inherits,
> so it still is only exported for arm, even if the value is set to the empty
> string for others?

Unfortunately no. It is a parsing error.

I am working on alternatives and will hopefully have something out shortly.

MarkA

> 
> On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
> 
> mark.asselst...@windriver.com> wrote:
> > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > GOARM env variable is set during the build. Not having GOARM exported
> > will result in GO binaries which can't be executed on the target
> > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > 
> > We already have the logic in goarch.bbclass to determine the correct
> > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > GOARM = "${TARGET_GOARM}").
> > 
> > Here we export GOARM but we do it such that it is only exported if we
> > are building for 'arm' and only when recipes requiring/inheriting
> > go.bbclass are be used to build for the target.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> > Richard,
> > 
> > MarkH and I were debating this one some. He was suggesting I add
> > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > builds. I however, like the behavior of this as submitted here as
> > non-arm target builds don't get polluted with a useless export in
> > their do_compile scripts and such. The question is as presented here
> > is the behavior deterministic?
> > 
> > 
> > meta/classes/go.bbclass | 3 +++
> > 
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > index af331f8..72e2c29 100644
> > --- a/meta/classes/go.bbclass
> > +++ b/meta/classes/go.bbclass
> > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > 
> >  export GOROOT
> >  export GOROOT_FINAL = "${libdir}/go"
> > 
> > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > +export GOARM
> > +
> > 
> >  DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> > 
> > virtual/${TARGET_PREFIX}go-runtime"
> > 
> >  DEPENDS_GOLANG_class-native = "go-native"
> >  DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> > 
> > virtual/${TARGET_PREFIX}go-runtime"
> > --
> > 2.7.4
> > 
> > --
> > ___
> > 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 1/2] go.bbclass: Export GOARM

[Mark Asselstine]

On Wednesday, March 13, 2019 3:40:18 PM EDT Christopher Larson wrote:
> How would bitbake respond to an ‘export’ line with the empty string? I.e.
> can you do an actual conditional export the way we do conditional inherits,
> so it still is only exported for arm, even if the value is set to the empty
> string for others?

I thought about doing this but did not attempt it. I will give it a go and see 
how it looks and works. I am still curious to hear from Richard on this as if 
it is deterministic it is the simplistic and easiest to read approach.

MarkA

> 
> On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine <
> 
> mark.asselst...@windriver.com> wrote:
> > When building GO packages for ARM (v5, v6, v7) it is expected that the
> > GOARM env variable is set during the build. Not having GOARM exported
> > will result in GO binaries which can't be executed on the target
> > (terminate with segfault). Per https://github.com/golang/go/wiki/GoArm
> > 
> > We already have the logic in goarch.bbclass to determine the correct
> > value of GOARM (see GOARM_TARGET), but currently this is only used to
> > build go itself (go-cross_1.*.bb requires go-cross.inc --> export
> > GOARM = "${TARGET_GOARM}").
> > 
> > Here we export GOARM but we do it such that it is only exported if we
> > are building for 'arm' and only when recipes requiring/inheriting
> > go.bbclass are be used to build for the target.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> > Richard,
> > 
> > MarkH and I were debating this one some. He was suggesting I add
> > 'GOARM ?= ""' so as not to leave things undefined for non-arm target
> > builds. I however, like the behavior of this as submitted here as
> > non-arm target builds don't get polluted with a useless export in
> > their do_compile scripts and such. The question is as presented here
> > is the behavior deterministic?
> > 
> > 
> > meta/classes/go.bbclass | 3 +++
> > 
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
> > index af331f8..72e2c29 100644
> > --- a/meta/classes/go.bbclass
> > +++ b/meta/classes/go.bbclass
> > @@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
> > 
> >  export GOROOT
> >  export GOROOT_FINAL = "${libdir}/go"
> > 
> > +GOARM_arm_class-target = "${TARGET_GOARM}"
> > +export GOARM
> > +
> > 
> >  DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go
> > 
> > virtual/${TARGET_PREFIX}go-runtime"
> > 
> >  DEPENDS_GOLANG_class-native = "go-native"
> >  DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk
> > 
> > virtual/${TARGET_PREFIX}go-runtime"
> > --
> > 2.7.4
> > 
> > --
> > ___
> > 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 2/2] goarch.bbclass: set TARGET_GOARM as '7' for cortexa7

[Mark Asselstine]

On Wednesday, March 13, 2019 3:56:10 PM EDT Andre McCurdy wrote:
> On Wed, Mar 13, 2019 at 10:57 AM Mark Asselstine
> 
>  wrote:
> > The cortexa7 tunings use 'cortexa7' in their tunings and do not
> > include 'arm7' so we need to look for both when setting TARGET_GOARM.
> 
> Is cortexa7 a special case? Or will the same issue be there for
> cortexa5, cortexa9, cortexa15, etc?

Damn, was too fucused on the 1/2 patch of this RR I had my blinders on. Yes I 
should be looking for cortexa* as I believe they all fall in to the "7" 
bucket. I will redo this and after we sort out 1/2 I will send a v2.

MarkA

> 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> >  meta/classes/goarch.bbclass | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
> > index 39fea5e..077c967 100644
> > --- a/meta/classes/goarch.bbclass
> > +++ b/meta/classes/goarch.bbclass
> > 
> > @@ -74,7 +74,7 @@ def go_map_arch(a, d):
> >  def go_map_arm(a, f, d):
> >  import re
> > 
> >  if re.match('arm.*', a):
> > -if 'armv7' in f:
> > 
> > +if 'armv7' or 'cortexa7' in f:
> >  return '7'
> >  
> >  elif 'armv6' in f:
> >  return '6'
> > 
> > --
> > 2.7.4
> > 
> > --
> > ___
> > 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

[OE-core] [PATCH 1/2] go.bbclass: Export GOARM

[Mark Asselstine]

When building GO packages for ARM (v5, v6, v7) it is expected that the
GOARM env variable is set during the build. Not having GOARM exported
will result in GO binaries which can't be executed on the target
(terminate with segfault). Per https://github.com/golang/go/wiki/GoArm

We already have the logic in goarch.bbclass to determine the correct
value of GOARM (see GOARM_TARGET), but currently this is only used to
build go itself (go-cross_1.*.bb requires go-cross.inc --> export
GOARM = "${TARGET_GOARM}").

Here we export GOARM but we do it such that it is only exported if we
are building for 'arm' and only when recipes requiring/inheriting
go.bbclass are be used to build for the target.

Signed-off-by: Mark Asselstine 
---

Richard,

MarkH and I were debating this one some. He was suggesting I add
'GOARM ?= ""' so as not to leave things undefined for non-arm target
builds. I however, like the behavior of this as submitted here as
non-arm target builds don't get polluted with a useless export in
their do_compile scripts and such. The question is as presented here
is the behavior deterministic?


meta/classes/go.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index af331f8..72e2c29 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -8,6 +8,9 @@ GOROOT = "${STAGING_LIBDIR}/go"
 export GOROOT
 export GOROOT_FINAL = "${libdir}/go"
 
+GOARM_arm_class-target = "${TARGET_GOARM}"
+export GOARM
+
 DEPENDS_GOLANG_class-target = "virtual/${TUNE_PKGARCH}-go 
virtual/${TARGET_PREFIX}go-runtime"
 DEPENDS_GOLANG_class-native = "go-native"
 DEPENDS_GOLANG_class-nativesdk = "virtual/${TARGET_PREFIX}go-crosssdk 
virtual/${TARGET_PREFIX}go-runtime"
-- 
2.7.4

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

[OE-core] [PATCH 2/2] goarch.bbclass: set TARGET_GOARM as '7' for cortexa7

[Mark Asselstine]

The cortexa7 tunings use 'cortexa7' in their tunings and do not
include 'arm7' so we need to look for both when setting TARGET_GOARM.

Signed-off-by: Mark Asselstine 
---
 meta/classes/goarch.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 39fea5e..077c967 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -74,7 +74,7 @@ def go_map_arch(a, d):
 def go_map_arm(a, f, d):
 import re
 if re.match('arm.*', a):
-if 'armv7' in f:
+if 'armv7' or 'cortexa7' in f:
 return '7'
 elif 'armv6' in f:
 return '6'
-- 
2.7.4

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

[OE-core] [PATCH] cpio: avoid conflict with tar-doc and rmt.8

[Mark Asselstine]

This fixes:
Error: Transaction check error:
  file /usr/share/man/man8/rmt.8 conflicts between attempted installs of
  cpio-doc-2.12-r0.core2_64 and tar-doc-1.31-r0.core2_64

Prior to commit 348a96a5b401 [tar: upgrade to 1.31] the copies of
rmt.8 found in the tar(-doc) and cpio(-doc) packages were the same and
thus no conflict was seen. After the upgrade there were small changes
in the manpage header which results in the conflict quoted above. The
applications themselves make use of the 'update-alternatives'
mechanism to allow a user to select which version of 'rmt' to use but
since the man pages are essentially the same we disambiguate the
source of the man pages and make them both available should both
cpio-doc and tar-doc are both installed. And as such we avoid the
conflict.

Signed-off-by: Mark Asselstine 
---
 meta/recipes-extended/cpio/cpio_2.12.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-extended/cpio/cpio_2.12.bb 
b/meta/recipes-extended/cpio/cpio_2.12.bb
index 6ba8337..cb845c3 100644
--- a/meta/recipes-extended/cpio/cpio_2.12.bb
+++ b/meta/recipes-extended/cpio/cpio_2.12.bb
@@ -27,6 +27,9 @@ do_install () {
 mv "${D}${bindir}/cpio" "${D}${base_bindir}/cpio"
 rmdir ${D}${bindir}/
 fi
+
+# Avoid conflicts with the version from tar
+mv "${D}${mandir}/man8/rmt.8" "${D}${mandir}/man8/rmt-cpio.8"
 }
 
 PACKAGES =+ "${PN}-rmt"
-- 
2.7.4

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

Re: [OE-core] [PATCH] man-pages: use alternatives to resolve crypt.3 conflict

[Mark Asselstine]

On Wednesday, January 2, 2019 4:23:58 PM EST 
richard.pur...@linuxfoundation.org wrote:
> On Wed, 2019-01-02 at 13:39 -0500, Mark Asselstine wrote:
> > On Thursday, December 20, 2018 10:34:54 AM EST Mark Asselstine wrote:
> > > From: mark asselstine 
> > > 
> > > To fix:
> > >   Error: Transaction check error:
> > > file /usr/share/man/man3/crypt.3 conflicts between attempted
> > > 
> > > installs
> > > 
> > > of libcrypt-doc-4.4.1-r0.core2_64 and man-pages-4.16-
> > > 
> > > r0.core2_64
> > > 
> > > This issue came about after commit 59be9254df9f [libxcrypt: Upgrade
> > > to
> > > 4.4.1 release].
> > > 
> > > Signed-off-by: Mark Asselstine 
> > > ---
> > 
> > This issue is still persisting. Any reason for this not being picked
> > up yet?
> 
> Vacation and being human :)
> 
> Its queued in -next, I thought I'd picked it up previously...

Thanks Richard. I knew that it was getting close to the holidays when I sent 
it out, I guess I cut it too close

MarkA

> 
> Cheers,
> 
> Richard




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

Re: [OE-core] [PATCH] man-pages: use alternatives to resolve crypt.3 conflict

[Mark Asselstine]

On Thursday, December 20, 2018 10:34:54 AM EST Mark Asselstine wrote:
> From: mark asselstine 
> 
> To fix:
> 
>   Error: Transaction check error:
> file /usr/share/man/man3/crypt.3 conflicts between attempted installs
> of libcrypt-doc-4.4.1-r0.core2_64 and man-pages-4.16-r0.core2_64
> 
> This issue came about after commit 59be9254df9f [libxcrypt: Upgrade to
> 4.4.1 release].
> 
> Signed-off-by: Mark Asselstine 
> ---

This issue is still persisting. Any reason for this not being picked up yet?

Mark

>  meta/recipes-extended/man-pages/man-pages_4.16.bb | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-extended/man-pages/man-pages_4.16.bb
> b/meta/recipes-extended/man-pages/man-pages_4.16.bb index a64587c..1f14c89
> 100644
> --- a/meta/recipes-extended/man-pages/man-pages_4.16.bb
> +++ b/meta/recipes-extended/man-pages/man-pages_4.16.bb
> @@ -31,6 +31,7 @@ FILES_${PN} = "${mandir}/*"
>  inherit update-alternatives
> 
>  ALTERNATIVE_PRIORITY = "100"
> -ALTERNATIVE_${PN} = "passwd.5 getspnam.3"
> +ALTERNATIVE_${PN} = "passwd.5 getspnam.3 crypt.3"
>  ALTERNATIVE_LINK_NAME[passwd.5] = "${mandir}/man5/passwd.5"
>  ALTERNATIVE_LINK_NAME[getspnam.3] = "${mandir}/man3/getspnam.3"
> +ALTERNATIVE_LINK_NAME[crypt.3] = "${mandir}/man3/crypt.3"




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

[OE-core] [PATCH] man-pages: use alternatives to resolve crypt.3 conflict

[Mark Asselstine]

From: mark asselstine 

To fix:

  Error: Transaction check error:
file /usr/share/man/man3/crypt.3 conflicts between attempted installs
of libcrypt-doc-4.4.1-r0.core2_64 and man-pages-4.16-r0.core2_64

This issue came about after commit 59be9254df9f [libxcrypt: Upgrade to
4.4.1 release].

Signed-off-by: Mark Asselstine 
---
 meta/recipes-extended/man-pages/man-pages_4.16.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/man-pages/man-pages_4.16.bb 
b/meta/recipes-extended/man-pages/man-pages_4.16.bb
index a64587c..1f14c89 100644
--- a/meta/recipes-extended/man-pages/man-pages_4.16.bb
+++ b/meta/recipes-extended/man-pages/man-pages_4.16.bb
@@ -31,6 +31,7 @@ FILES_${PN} = "${mandir}/*"
 inherit update-alternatives
 
 ALTERNATIVE_PRIORITY = "100"
-ALTERNATIVE_${PN} = "passwd.5 getspnam.3"
+ALTERNATIVE_${PN} = "passwd.5 getspnam.3 crypt.3"
 ALTERNATIVE_LINK_NAME[passwd.5] = "${mandir}/man5/passwd.5"
 ALTERNATIVE_LINK_NAME[getspnam.3] = "${mandir}/man3/getspnam.3"
+ALTERNATIVE_LINK_NAME[crypt.3] = "${mandir}/man3/crypt.3"
-- 
2.7.4

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

Re: [OE-core] [PATCH] meson.bbclass: Fix build issues with /tmp mounted with noexec

[Mark Asselstine]

On Wednesday, October 10, 2018 4:32:56 PM EDT Nirbheek Chauhan wrote:
> On Thu, Oct 11, 2018 at 1:50 AM Mark Asselstine
> 
>  wrote:
> > Definitely a bug in that it doesn't propogate as an error.
> 
> Note that compiler checks currently never raise an exception, and -1
> is the all-inclusive "error condition" for when the size of a variable
> could not be determined. Perhaps we should add a kwarg to sizeof()
> that forces it to error out if the size could not be determined, or if
> an unexpected error occurs.

I can only speak from my perspective as a user here, and that is a "silent" 
fail such as this is evil.

Firstly because this took some time to dig up. Understandably in this instance 
the build failure was only taking place in automated build infra which made it 
difficult to inspect logs and such to narrow in on the issue. Even if I had 
easier access to a failed build this would have taken time to uncover, btw.

Secondly and more importantly had it not been for a coding issue causing a 
build failure this would have gone unnoticed and the code built on systems 
with noexec-tmp vs not would have be completely different.

Regardless of the "-1" potentially aligning with some known default the fact 
that meson had an obvious failure attempting to run code and didn't return a 
failure return code is wrong. This is host contamination.

> 
> > On the need to
> > always use meson-private, I am 50/50 on that. Since meson respects
> > TMPDIR/TMP/ TEMP does it really need to handle this directly?
> 
> The main advantage of using tmpfs for temporary files is obvious,

Sorry, are you concerned about dirs/files being improperly cleaned up? Disk 
IO? Whenever I see "obvious" in an email I get a bit worried as I don't trust 
that what I am thinking is the same as what others might be.

> which is why we try to avoid writing that to meson-private inside the
> builddir. As I just commented on the issue, `XDG_RUNTIME_DIR` might be
> a good candidate for an exec tmpfs location.

I am not familiar with XDG_RUNTIME_DIR. On paper it does read like it could be 
used but it does seem to have a varying levels of support especially on 
systems which use sysvinit where pam is not always present.

Mark




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

Re: [OE-core] [PATCH] meson.bbclass: Fix build issues with /tmp mounted with noexec

[Mark Asselstine]

On Wednesday, October 10, 2018 3:54:10 PM EDT Khem Raj wrote:
> On Wed, Oct 10, 2018 at 12:36 PM Mark Asselstine
> 
>  wrote:
> > Since commit d297f7ebf3f6 [fribidi: use Meson instead of autotools]
> > build failures have been observed with this package. The immediate
> > issue was related to improperly named #defines per
> > https://github.com/fribidi/fribidi/commit/46f52d588ab5, however, the
> > root cause was FRIBIDI_SIZEOF_INT getting a value of "-1".
> > 
> > After searching the meson logs the following was found:
> >   Could not run: /tmp/tmp2fxe6ha1/output.exe (error: [Errno 13] Permission
> >   denied) Checking for size of "int": -1
> > 
> > Which pointed to the real root cause being /tmp mounted with noexec, a
> > common configuration on Redhat and other distros. This issues has been
> > raised in the meson community:
> > https://github.com/mesonbuild/meson/issues/2972 but is yet to be
> > addressed.
> > 
> > Using the discussion from issue#2972 and the fact that the underlying
> > code makes use of python 'tempfile' we can simply create a 'tmp'
> > directory and make use of TMPDIR to avoid this issue.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> >  meta/classes/meson.bbclass | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
> > index ed08a40..7e63e12 100644
> > --- a/meta/classes/meson.bbclass
> > +++ b/meta/classes/meson.bbclass
> > @@ -109,6 +109,9 @@ EOF
> > 
> >  CONFIGURE_FILES = "meson.build"
> >  
> >  meson_do_configure() {
> > 
> > +# Work around "Meson fails if /tmp is mounted with noexec #2972"
> 
> I would call it a bug in meson not a workaround.

Definitely a bug in that it doesn't propogate as an error. On the need to 
always use meson-private, I am 50/50 on that. Since meson respects TMPDIR/TMP/
TEMP does it really need to handle this directly?

Anyway, not sure if Mark Hatle and the other build system experts will like my 
fix, I will adjust as needed if/when they weigh in.

MarkA

> 
> > +mkdir -p "${B}/meson-private/tmp"
> > +export TMPDIR="${B}/meson-private/tmp"
> > 
> >  bbnote Executing meson ${EXTRA_OEMESON}...
> >  if ! meson ${MESONOPTS} "${MESON_SOURCEPATH}" "${B}"
> >  ${MESON_CROSS_FILE} ${EXTRA_OEMESON}; then>  
> >  bbfatal_log meson failed
> > 
> > --
> > 2.7.4
> > 
> > --
> > ___
> > 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

[OE-core] [PATCH] meson.bbclass: Fix build issues with /tmp mounted with noexec

[Mark Asselstine]

Since commit d297f7ebf3f6 [fribidi: use Meson instead of autotools]
build failures have been observed with this package. The immediate
issue was related to improperly named #defines per
https://github.com/fribidi/fribidi/commit/46f52d588ab5, however, the
root cause was FRIBIDI_SIZEOF_INT getting a value of "-1".

After searching the meson logs the following was found:

  Could not run: /tmp/tmp2fxe6ha1/output.exe (error: [Errno 13] Permission 
denied)
  Checking for size of "int": -1

Which pointed to the real root cause being /tmp mounted with noexec, a
common configuration on Redhat and other distros. This issues has been
raised in the meson community:
https://github.com/mesonbuild/meson/issues/2972 but is yet to be
addressed.

Using the discussion from issue#2972 and the fact that the underlying
code makes use of python 'tempfile' we can simply create a 'tmp'
directory and make use of TMPDIR to avoid this issue.

Signed-off-by: Mark Asselstine 
---
 meta/classes/meson.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index ed08a40..7e63e12 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -109,6 +109,9 @@ EOF
 CONFIGURE_FILES = "meson.build"
 
 meson_do_configure() {
+# Work around "Meson fails if /tmp is mounted with noexec #2972"
+mkdir -p "${B}/meson-private/tmp"
+export TMPDIR="${B}/meson-private/tmp"
 bbnote Executing meson ${EXTRA_OEMESON}...
 if ! meson ${MESONOPTS} "${MESON_SOURCEPATH}" "${B}" ${MESON_CROSS_FILE} 
${EXTRA_OEMESON}; then
 bbfatal_log meson failed
-- 
2.7.4

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

Re: [OE-core] [PATCH] recipe_links.bbclass: introduction

[Mark Asselstine]

On Tuesday, May 29, 2018 3:22:54 PM EDT Khem Raj wrote:
> On Mon, May 28, 2018 at 6:38 AM, Mark Asselstine
> 
>  wrote:
> > This is a new class which can be used (for example via USER_CLASSES in
> > local.conf) to make your build more development friendly. When
> > included this class will create symlinks to the various bb and
> > bbappend files in WORKDIR.
> > 
> > Normally when you are debugging or extending a package's recipe files
> > a developer will employ one of a few indirect techniques to determine
> > where bb and bbappends files associated with a recipe exist. For
> > example they might use bitbake-layers show-recipes or similar, or
> > simply rely on their experience to guide them. Even after working with
> > openembedded for serveral years now I find these techniques tedious
> > and time consuming, and sometimes even hit and miss.
> > 
> > Since the whereabouts of these files are already stored in various
> > files at parse time we can create symlinks to simplify the task of
> > finding these files, making them available in WORKDIR for easy
> > inpsection and in a convenient location if using devshel for instance.
> > 
> > For now this work is completely optional but we could conceivable make
> > this the default behavior if folks find it is convenient and the cost
> > of performing these operations across all builds is minimal enough.
> > 
> > recipe_links can safely be added to USER_CLASSES for existing builds,
> > care has been taken to avoid this action causing anything to be
> > rebuilt. After this has been added you can either 'bitbake  -C
> > unpack' or 'bitbake  -c create_recipe_links' to cause the
> > links to be created in the WORKDIR for the specified recipe.
> 
> I think this is not complementing devtool workflow, even though its
> not going to hurt it.
> however, devtool workflow is what we should be targeting as primary
> workflow for OE
> and I do not see a benefit of this in that regard.

I agree that this is unrelated to devtool. My only comment was in response to 
the question that this will play nice with the devtool workspaces, and it 
does.

As to its usefulness, I think there is plenty of room for small improvements 
like this without having to push people towards devtool workflows. I have been 
using it for a while now and I can say with certainty it has saved me time and 
grief, enough so I wanted to share and not hoard. If others agree and it is 
merged, great, if not oh well.

Mark

> 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> >  meta/classes/recipe_links.bbclass | 79
> >  +++ meta/conf/documentation.conf
> >   |  1 +
> >  2 files changed, 80 insertions(+)
> >  create mode 100644 meta/classes/recipe_links.bbclass
> > 
> > diff --git a/meta/classes/recipe_links.bbclass
> > b/meta/classes/recipe_links.bbclass new file mode 100644
> > index 000..ea97605
> > --- /dev/null
> > +++ b/meta/classes/recipe_links.bbclass
> > @@ -0,0 +1,79 @@
> > +# Create symlink in WORKDIR to the various bb and
> > +# bbappend files used to define the package ops
> > +
> > +# Create a symlink given src and dst paths
> > +def create_link(d, src, dst):
> > +if os.path.islink(dst):
> > +try:
> > +os.unlink(dst)
> > +except OSError as err:
> > +bb.error("  Failed to cleanup old link %s: %s"
> > + % (os.path.basename(dst),
> > os.strerror(err.errno))) +return False
> > +
> > +
> > +try:
> > +os.symlink(src, dst)
> > +except OSError as err:
> > +bb.error("  Failed to create file link for %s: %s"
> > + % (src, os.strerror(err.errno)))
> > +return False
> > +
> > +return True
> > +
> > +# Ensure the work is scheduled. We do this as a func
> > +# to avoid sig changes causing things to be rebuilt
> > +# when the class is added/removed after the fact.
> > +do_unpack[postfuncs] += "create_recipe_links "
> > +do_unpack[vardepsexclude] += "create_recipe_links "
> > +python create_recipe_links() {
> > +import re
> > +import glob
> > +
> > +workdir = d.getVar('WORKDIR')
> > +
> > +# Main recipe file
> > +bb.note("Add main recipe file link:")
> > +bb_path = d.getVar('FILE')
> > +bb_filename = os.path.basename(bb_path)
> > +bb_destname = "%s/%s" % (workdir, bb_filename)
> &

Re: [OE-core] [PATCH] recipe_links.bbclass: introduction

[Mark Asselstine]

On Monday, May 28, 2018 9:52:16 AM EDT Alexander Kanavin wrote:
> (don't forget devtool also has 'edit/find/update-recipe' commands).

Since it keys off the FILE and BBINCLUDED as parsed it follows along with the 
devtool workspaces just fine. There should be no confusion added and if 
anything seeing the link to the bbappend in the devtool workspace being 
included in the links should add a level of comfort.

This was sent for RFC quite a while ago, I am only now getting around to 
pushing for proper inclusion.

Mark

> 
> Alex
> 
> 2018-05-28 16:50 GMT+03:00 Alexander Kanavin :
> > 2018-05-28 16:38 GMT+03:00 Mark Asselstine 
:
> >> This is a new class which can be used (for example via USER_CLASSES in
> >> local.conf) to make your build more development friendly. When
> >> included this class will create symlinks to the various bb and
> >> bbappend files in WORKDIR.
> > 
> > I do think this is a great idea, I only want to ask, how well this
> > integrates with devtool workflows?
> > Particularly, 'devtool add/modify/upgrade' do their own recipe copying
> > and manipulation, so we should make sure this does not increase the
> > confusion.
> > 
> > Alex




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

[OE-core] [PATCH] recipe_links.bbclass: introduction

[Mark Asselstine]

This is a new class which can be used (for example via USER_CLASSES in
local.conf) to make your build more development friendly. When
included this class will create symlinks to the various bb and
bbappend files in WORKDIR.

Normally when you are debugging or extending a package's recipe files
a developer will employ one of a few indirect techniques to determine
where bb and bbappends files associated with a recipe exist. For
example they might use bitbake-layers show-recipes or similar, or
simply rely on their experience to guide them. Even after working with
openembedded for serveral years now I find these techniques tedious
and time consuming, and sometimes even hit and miss.

Since the whereabouts of these files are already stored in various
files at parse time we can create symlinks to simplify the task of
finding these files, making them available in WORKDIR for easy
inpsection and in a convenient location if using devshel for instance.

For now this work is completely optional but we could conceivable make
this the default behavior if folks find it is convenient and the cost
of performing these operations across all builds is minimal enough.

recipe_links can safely be added to USER_CLASSES for existing builds,
care has been taken to avoid this action causing anything to be
rebuilt. After this has been added you can either 'bitbake  -C
unpack' or 'bitbake  -c create_recipe_links' to cause the
links to be created in the WORKDIR for the specified recipe.

Signed-off-by: Mark Asselstine 
---
 meta/classes/recipe_links.bbclass | 79 +++
 meta/conf/documentation.conf  |  1 +
 2 files changed, 80 insertions(+)
 create mode 100644 meta/classes/recipe_links.bbclass

diff --git a/meta/classes/recipe_links.bbclass 
b/meta/classes/recipe_links.bbclass
new file mode 100644
index 000..ea97605
--- /dev/null
+++ b/meta/classes/recipe_links.bbclass
@@ -0,0 +1,79 @@
+# Create symlink in WORKDIR to the various bb and
+# bbappend files used to define the package ops
+
+# Create a symlink given src and dst paths
+def create_link(d, src, dst):
+if os.path.islink(dst):
+try:
+os.unlink(dst)
+except OSError as err:
+bb.error("  Failed to cleanup old link %s: %s"
+ % (os.path.basename(dst), os.strerror(err.errno)))
+return False
+
+
+try:
+os.symlink(src, dst)
+except OSError as err:
+bb.error("  Failed to create file link for %s: %s"
+ % (src, os.strerror(err.errno)))
+return False
+
+return True
+
+# Ensure the work is scheduled. We do this as a func
+# to avoid sig changes causing things to be rebuilt
+# when the class is added/removed after the fact.
+do_unpack[postfuncs] += "create_recipe_links "
+do_unpack[vardepsexclude] += "create_recipe_links "
+python create_recipe_links() {
+import re
+import glob
+
+workdir = d.getVar('WORKDIR')
+
+# Main recipe file
+bb.note("Add main recipe file link:")
+bb_path = d.getVar('FILE')
+bb_filename = os.path.basename(bb_path)
+bb_destname = "%s/%s" % (workdir, bb_filename)
+bb.note("  Linking %s" % bb_path)
+if not create_link(d, bb_path, bb_destname):
+return False
+
+# Cleanup old bbappends links
+bb.note("Removing old bbappend links:")
+pn = d.getVar('PN')
+files = glob.glob('%s/[0-9][0-9]_%s.bbappend' % (workdir,pn))
+files += glob.glob('%s/[0-9][0-9]_%s_*.bbappend' % (workdir, pn))
+for filename in files:
+bb.note("  Removing: %s" % filename)
+try:
+os.unlink(filename)
+except OSError as err:
+bb.error("  Failed to cleanup old link %s: %s" %
+ (os.path.basename(filename), os.strerror(err.errno)))
+return False
+
+# Add bbappends links
+bb.note("Adding bbappend links:")
+included_files = d.getVar('BBINCLUDED').split()
+bbappend_re = re.compile( r".*/%s(_[^/]*)?\.bbappend$" % re.escape(pn))
+for filename in included_files:
+if bbappend_re.match(filename):
+bb.note("  Linking %s" % filename)
+destname = "00_%s" % (os.path.basename(filename))
+while os.path.exists("%s/%s" % (workdir, destname)):
+ destname = str(int(destname[:2]) + 1).zfill(2) + destname[2:]
+if not create_link(d, filename, "%s/%s" % (workdir, destname)):
+return False
+
+return True
+}
+
+# In addition to the func we want to make things able to be (re)run
+# easily by the user so ensure it is available as a task.
+addtask do_create_recipe_links
+python do_create_recipe_links() {
+bb.build.exec_func("create_recipe_links

Re: [OE-core] [PATCH 1/2] wayland: upgrade to 1.15.0

[Mark Asselstine]

On Wednesday, May 9, 2018 12:16:30 PM EDT Burton, Ross wrote:
> Good news: Denys beat you.

I need to take long lunches more often. Thanks Denys for taking care of this.

Mark

> 
> Ross
> 
> On 9 May 2018 at 17:09, Mark Asselstine 
> 
> wrote:
> > On Wednesday, May 9, 2018 12:03:26 PM EDT Burton, Ross wrote:
> > > On 9 May 2018 at 17:00, Mark Asselstine 
> > > 
> > > wrote:
> > > > I am also seeing build failures due to this conflict:
> > > > 
> > > > ERROR: libglu-2_9.0.0-0 do_prepare_recipe_sysroot: The file
> > > > /usr/lib64/
> > > > libwayland-egl.la is installed by both wayland and mesa, aborting
> > > > ..
> > > > ERROR: mesa-2_18.0.2-r0 do_package: QA Issue: mesa: Files/directories
> > 
> > were
> > 
> > > > installed but not shipped in any package:
> > > >   /usr/lib64/libwayland-egl.la
> > > > 
> > > > Please set FILES such that these items are packaged. Alternatively if
> > 
> > they
> > 
> > > > are
> > > > unneeded, avoid installing them or delete them within do_install.
> > > > mesa: 1 installed and not shipped files. [installed-vs-shipped]
> > > > 
> > > > is someone working on a fix or should I take some time to put
> > > > something
> > > > together?
> > > 
> > > As it appears you can test quickly then I think you just drew the short
> > > straw.  Should be a trivial patch...
> > 
> > I knew that this had a 50/50 chance of going this way :). Lunch then a
> > fix. I
> > assume then we will go with Martin's suggestion of an explicit remove in
> > mesa.inc?
> > 
> > Mark
> > 
> > > Ross




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

Re: [OE-core] [PATCH 1/2] wayland: upgrade to 1.15.0

[Mark Asselstine]

On Wednesday, May 9, 2018 12:03:26 PM EDT Burton, Ross wrote:
> On 9 May 2018 at 17:00, Mark Asselstine 
> 
> wrote:
> > I am also seeing build failures due to this conflict:
> > 
> > ERROR: libglu-2_9.0.0-0 do_prepare_recipe_sysroot: The file /usr/lib64/
> > libwayland-egl.la is installed by both wayland and mesa, aborting
> > ..
> > ERROR: mesa-2_18.0.2-r0 do_package: QA Issue: mesa: Files/directories were
> > 
> > installed but not shipped in any package:
> >   /usr/lib64/libwayland-egl.la
> > 
> > Please set FILES such that these items are packaged. Alternatively if they
> > are
> > unneeded, avoid installing them or delete them within do_install.
> > mesa: 1 installed and not shipped files. [installed-vs-shipped]
> > 
> > is someone working on a fix or should I take some time to put something
> > together?
> 
> As it appears you can test quickly then I think you just drew the short
> straw.  Should be a trivial patch...

I knew that this had a 50/50 chance of going this way :). Lunch then a fix. I 
assume then we will go with Martin's suggestion of an explicit remove in 
mesa.inc?

Mark

> 
> Ross




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

Re: [OE-core] [PATCH 1/2] wayland: upgrade to 1.15.0

[Mark Asselstine]

On Tuesday, May 8, 2018 5:18:44 PM EDT Martin Jansa wrote:
> On Tue, Apr 10, 2018 at 03:06:09PM -0400, Denys Dmytriyenko wrote:
> > From: Denys Dmytriyenko 
> > 
> > Official announcement:
> > https://lists.freedesktop.org/archives/wayland-devel/2018-April/037767.htm
> > l
> > 
> > | libwayland-egl is now part of libwayland, and will presumably be removed
> > | from mesa in the not too distant future.
> > 
> > Update mesa recipe by removing corresponding libwayland-egl entries.
> > 
> > Signed-off-by: Denys Dmytriyenko 
> > ---
> > 
> >  meta/recipes-graphics/mesa/mesa.inc| 7
> >  --- .../wayland/{wayland_1.14.0.bb => wayland_1.15.0.bb}
> >| 4 ++-- 2 files changed, 6 insertions(+), 5 deletions(-)
> >  rename meta/recipes-graphics/wayland/{wayland_1.14.0.bb =>
> >  wayland_1.15.0.bb} (92%)> 
> > diff --git a/meta/recipes-graphics/mesa/mesa.inc
> > b/meta/recipes-graphics/mesa/mesa.inc index b501b7e..c3a8e76 100644
> > --- a/meta/recipes-graphics/mesa/mesa.inc
> > +++ b/meta/recipes-graphics/mesa/mesa.inc
> > @@ -119,7 +119,6 @@ PACKAGES =+ "libegl-mesa libegl-mesa-dev \
> > 
> >   libgles1-mesa libgles1-mesa-dev \
> >   libgles2-mesa libgles2-mesa-dev \
> >   libgles3-mesa libgles3-mesa-dev \
> > 
> > - libwayland-egl libwayland-egl-dev \
> > 
> >   libxatracker libxatracker-dev \
> >   mesa-megadriver mesa-vulkan-drivers \
> >  
> >  "
> > 
> > @@ -134,6 +133,10 @@ do_install_append () {
> > 
> >  # it was packaged in libdricore9.1.3-1 and preventing upgrades when
> >  debian.bbclass was used rm -f ${D}${sysconfdir}/drirc
> >  chrpath --delete ${D}${libdir}/dri/*_dri.so || true
> > 
> > +
> > +# libwayland-egl has been moved to wayland 1.15+
> > +rm -f ${D}${libdir}/libwayland-egl.so*
> > +rm -f ${D}${libdir}/pkgconfig/wayland-egl.pc
> 
> Shouldn't /usr/lib/libwayland-egl.la be removed as well? Now I'm getting
> many do_prepare_recipe_sysroot failures because both mesa and wayland
> provide this file.

I am also seeing build failures due to this conflict:

ERROR: libglu-2_9.0.0-0 do_prepare_recipe_sysroot: The file /usr/lib64/
libwayland-egl.la is installed by both wayland and mesa, aborting
..
ERROR: mesa-2_18.0.2-r0 do_package: QA Issue: mesa: Files/directories were 
installed but not shipped in any package:
  /usr/lib64/libwayland-egl.la
Please set FILES such that these items are packaged. Alternatively if they are 
unneeded, avoid installing them or delete them within do_install.
mesa: 1 installed and not shipped files. [installed-vs-shipped]

is someone working on a fix or should I take some time to put something 
together?

Mark


> 
> >  }
> >  
> >  # For the packages that make up the OpenGL interfaces, inject variables
> >  so that> 
> > @@ -204,7 +207,6 @@ FILES_libgles2-mesa = "${libdir}/libGLESv2.so.*"
> > 
> >  FILES_libgl-mesa = "${libdir}/libGL.so.*"
> >  FILES_libglapi = "${libdir}/libglapi.so.*"
> >  FILES_libosmesa = "${libdir}/libOSMesa.so.*"
> > 
> > -FILES_libwayland-egl = "${libdir}/libwayland-egl.so.*"
> > 
> >  FILES_libxatracker = "${libdir}/libxatracker.so.*"
> >  
> >  FILES_${PN}-dev = "${libdir}/pkgconfig/dri.pc ${includedir}/vulkan"
> > 
> > @@ -216,7 +218,6 @@ FILES_libgles1-mesa-dev = "${libdir}/libGLESv1*.*
> > ${includedir}/GLES ${libdir}/p> 
> >  FILES_libgles2-mesa-dev = "${libdir}/libGLESv2.* ${includedir}/GLES2
> >  ${libdir}/pkgconfig/glesv2.pc" FILES_libgles3-mesa-dev =
> >  "${includedir}/GLES3"
> >  FILES_libosmesa-dev = "${libdir}/libOSMesa.* ${includedir}/GL/osmesa.h
> >  ${libdir}/pkgconfig/osmesa.pc"> 
> > -FILES_libwayland-egl-dev = "${libdir}/pkgconfig/wayland-egl.pc
> > ${libdir}/libwayland-egl.*"> 
> >  FILES_libxatracker-dev = "${libdir}/libxatracker.so
> >  ${libdir}/libxatracker.la \>  
> >${includedir}/xa_tracker.h
> >${includedir}/xa_composite.h
> >${includedir}/xa_context.h \
> >${libdir}/pkgconfig/xatracker.pc"
> > 
> > diff --git a/meta/recipes-graphics/wayland/wayland_1.14.0.bb
> > b/meta/recipes-graphics/wayland/wayland_1.15.0.bb similarity index 92%
> > rename from meta/recipes-graphics/wayland/wayland_1.14.0.bb
> > rename to meta/recipes-graphics/wayland/wayland_1.15.0.bb
> > index 1a9ff98..788105b 100644
> > --- a/meta/recipes-graphics/wayland/wayland_1.14.0.bb
> > +++ b/meta/recipes-graphics/wayland/wayland_1.15.0.bb
> > @@ -15,8 +15,8 @@ DEPENDS = "expat libxml2 libffi wayland-native"
> > 
> >  SRC_URI = "https://wayland.freedesktop.org/releases/${BPN}-${PV}.tar.xz \
> >  
> >file://fixpathinpcfiles.patch \
> >
> > "
> > 
> > -SRC_URI[md5sum] = "0235f6075c32c3be61cff94fa0b9f108"
> > -SRC_URI[sha256sum] =
> > "ed80cabc0961a759a42092e2c39aabfc1ec9a13c86c98bbe2b812f008da27ab8"
> > +SRC_URI[md5sum] = "b7393c17fdce9a8d383edab656c92fd2"
> > +

Re: [OE-core] [PATCH] systemd: backport patch to fix build when gcrypt is enabled

[Mark Asselstine]

On Wednesday, May 9, 2018 10:36:17 AM EDT Andrea Galbusera wrote:
> Hi Mark!
> 
> Il mer 9 mag 2018, 15:56 Mark Asselstine  ha
> 
> scritto:
> > On Wednesday, May 9, 2018 8:16:08 AM EDT Andrea Galbusera wrote:
> > > When gcrypt support is present in PACKAGECONFIG, build fails due to the
> > 
> > bug
> > 
> > > reported in [1]. Since this is already solved upstream, this commit
> > > backports the corresponding patch.
> > > 
> > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893602
> > > 
> > > Signed-off-by: Andrea Galbusera 
> > 
> > Thanks Andrea, I can confirm this fixes a build failure we were seeing as
> > well.
> 
> Thanks for further testing the patch so quickly!

No problem. I had a build going with the same upstream patch in place when I 
saw your email.

> 
> Out of curiosity... Are you also enabling gcrypt support to workaround the
> implict dependency resolved used to have upon gcrypt in the past? 

We have been enabling gcrypt since 2016 when building systemd. We found that 
there was upstream work which meant that gcrypt was necessary and not optional 
(as it appeared). I don't think we ever revisited this since that initial 
discovery.

> It took
> me a few hours to figure out what was specific in my configuration, since
> this bug was obviously not exposed in configurations currently built by the
> autobuilders!

We do nightly builds of meta-overc (https://github.com/OverC/meta-overc) where 
we often catch things the autobuilds miss. You most likely don't care about 
the content of meta-overc but it might be worthwhile to keep an eye on commits 
we do there since we often stage systemd and other fixes there while they are 
pending for other oe/yocto repos.

> 
> As a side note, I know there is a newer released version of systemd (238),
> but upgrading such a complex recipe was not an option for me in the short.
> I'm CC-ing the recipe's maintainer here, in case there's already an effort
> to upgrade to 238...

Makes sense, it's the "smart thing to do". Since meta-overc does lots of work 
around containers we can be sensitive to systemd uprev's but are usually quick 
to address any issues the uprev might cause.

Mark

> 
> > Mark
> > 
> > > ---
> > > 
> > >  ...rename-noreturn-into-_noreturn_-8456.patch | 203 ++
> > >  meta/recipes-core/systemd/systemd_237.bb  |   1 +
> > >  2 files changed, 204 insertions(+)
> > >  create mode 100644
> > > 
> > > meta/recipes-core/systemd/systemd/0033-basic-macros-
> > 
> > rename-noreturn-into-_n
> > 
> > > oreturn_-8456.patch
> > > 
> > > diff --git
> > > a/meta/recipes-core/systemd/systemd/0033-basic-macros-
> > 
> > rename-noreturn-into-
> > 
> > > _noreturn_-8456.patch
> > > b/meta/recipes-core/systemd/systemd/0033-basic-macros-
> > 
> > rename-noreturn-into-
> > 
> > > _noreturn_-8456.patch new file mode 100644
> > > index 00..59647b22f8
> > > --- /dev/null
> > > +++
> > > b/meta/recipes-core/systemd/systemd/0033-basic-macros-
> > 
> > rename-noreturn-into-
> > 
> > > _noreturn_-8456.patch @@ -0,0 +1,203 @@
> > > +From 848e863acc51ecfb0f3955c498874588201d9130 Mon Sep 17 00:00:00 2001
> > > +From: Franck Bui 
> > > +Date: Thu, 15 Mar 2018 06:23:46 +0100
> > > +Subject: [PATCH] basic/macros: rename noreturn into _noreturn_ (#8456)
> > > +MIME-Version: 1.0
> > > +Content-Type: text/plain; charset=UTF-8
> > > +Content-Transfer-Encoding: 8bit
> > > +
> > > +"noreturn" is reserved and can be used in other header files we
> > > include:
> > > +
> > > +  [   16s] In file included from /usr/include/gcrypt.h:30:0,
> > > +  [   16s]  from ../src/journal/journal-file.h:26,
> > > +  [   16s]  from ../src/journal/journal-vacuum.c:31:
> > > +  [   16s] /usr/include/gpg-error.h:1544:46: error: expected ‘,’ or ‘;’
> > > before ‘)’ token +  [   16s]  void gpgrt_log_bug (const char *fmt, ...)
> > > 
> > > GPGRT_ATTR_NR_PRINTF(1,2); +
> > > +Here we include grcrypt.h (which in turns include gpg-error.h) *after*
> > 
> > we
> > 
> > > +"noreturn" was defined in macro.h.
> > > +---
> > > + src/basic/log.c |  4 ++--
> > > + src/basic/log.h |  4 ++--
> > > + src/basic/macro.h   | 19 +--
> > > + src/

Re: [OE-core] [PATCH] systemd: backport patch to fix build when gcrypt is enabled

[Mark Asselstine]

On Wednesday, May 9, 2018 8:16:08 AM EDT Andrea Galbusera wrote:
> When gcrypt support is present in PACKAGECONFIG, build fails due to the bug
> reported in [1]. Since this is already solved upstream, this commit
> backports the corresponding patch.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893602
> 
> Signed-off-by: Andrea Galbusera 

Thanks Andrea, I can confirm this fixes a build failure we were seeing as 
well.

Mark

> ---
>  ...rename-noreturn-into-_noreturn_-8456.patch | 203 ++
>  meta/recipes-core/systemd/systemd_237.bb  |   1 +
>  2 files changed, 204 insertions(+)
>  create mode 100644
> meta/recipes-core/systemd/systemd/0033-basic-macros-rename-noreturn-into-_n
> oreturn_-8456.patch
> 
> diff --git
> a/meta/recipes-core/systemd/systemd/0033-basic-macros-rename-noreturn-into-
> _noreturn_-8456.patch
> b/meta/recipes-core/systemd/systemd/0033-basic-macros-rename-noreturn-into-
> _noreturn_-8456.patch new file mode 100644
> index 00..59647b22f8
> --- /dev/null
> +++
> b/meta/recipes-core/systemd/systemd/0033-basic-macros-rename-noreturn-into-
> _noreturn_-8456.patch @@ -0,0 +1,203 @@
> +From 848e863acc51ecfb0f3955c498874588201d9130 Mon Sep 17 00:00:00 2001
> +From: Franck Bui 
> +Date: Thu, 15 Mar 2018 06:23:46 +0100
> +Subject: [PATCH] basic/macros: rename noreturn into _noreturn_ (#8456)
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +"noreturn" is reserved and can be used in other header files we include:
> +
> +  [   16s] In file included from /usr/include/gcrypt.h:30:0,
> +  [   16s]  from ../src/journal/journal-file.h:26,
> +  [   16s]  from ../src/journal/journal-vacuum.c:31:
> +  [   16s] /usr/include/gpg-error.h:1544:46: error: expected ‘,’ or ‘;’
> before ‘)’ token +  [   16s]  void gpgrt_log_bug (const char *fmt, ...)   
> GPGRT_ATTR_NR_PRINTF(1,2); +
> +Here we include grcrypt.h (which in turns include gpg-error.h) *after* we
> +"noreturn" was defined in macro.h.
> +---
> + src/basic/log.c |  4 ++--
> + src/basic/log.h |  4 ++--
> + src/basic/macro.h   | 19 +--
> + src/basic/process-util.c|  2 +-
> + src/basic/process-util.h|  2 +-
> + src/core/main.c |  4 ++--
> + src/journal/test-journal-interleaving.c |  2 +-
> + src/shared/pager.c  |  2 +-
> + src/udev/collect/collect.c  |  2 +-
> + 9 files changed, 20 insertions(+), 21 deletions(-)
> +
> +Upstream-Status: Backport [https://github.com/systemd/systemd/pull/8456]
> +
> +diff --git a/src/basic/log.c b/src/basic/log.c
> +index 7a7f2cbec..16a2431c5 100644
> +--- a/src/basic/log.c
>  b/src/basic/log.c
> +@@ -814,7 +814,7 @@ static void log_assert(
> + log_dispatch_internal(level, 0, file, line, func, NULL, NULL,
> NULL, NULL, buffer); + }
> +
> +-noreturn void log_assert_failed_realm(
> ++_noreturn_ void log_assert_failed_realm(
> + LogRealm realm,
> + const char *text,
> + const char *file,
> +@@ -826,7 +826,7 @@ noreturn void log_assert_failed_realm(
> + abort();
> + }
> +
> +-noreturn void log_assert_failed_unreachable_realm(
> ++_noreturn_ void log_assert_failed_unreachable_realm(
> + LogRealm realm,
> + const char *text,
> + const char *file,
> +diff --git a/src/basic/log.h b/src/basic/log.h
> +index efcf0f1bf..314be128a 100644
> +--- a/src/basic/log.h
>  b/src/basic/log.h
> +@@ -186,7 +186,7 @@ int log_dump_internal(
> + char *buffer);
> +
> + /* Logging for various assertions */
> +-noreturn void log_assert_failed_realm(
> ++_noreturn_ void log_assert_failed_realm(
> + LogRealm realm,
> + const char *text,
> + const char *file,
> +@@ -195,7 +195,7 @@ noreturn void log_assert_failed_realm(
> + #define log_assert_failed(text, ...) \
> + log_assert_failed_realm(LOG_REALM, (text), __VA_ARGS__)
> +
> +-noreturn void log_assert_failed_unreachable_realm(
> ++_noreturn_ void log_assert_failed_unreachable_realm(
> + LogRealm realm,
> + const char *text,
> + const char *file,
> +diff --git a/src/basic/macro.h b/src/basic/macro.h
> +index 95be63a20..8911edfc4 100644
> +--- a/src/basic/macro.h
>  b/src/basic/macro.h
> +@@ -53,6 +53,15 @@
> + #else
> + #define _fallthrough_
> + #endif
> ++/* Define C11 noreturn without  and even on older gcc
> ++ * compiler versions */
> ++#ifndef _noreturn_
> ++#if __STDC_VERSION__ >= 201112L
> ++#define _noreturn_ _Noreturn
> ++#else
> ++#define _noreturn_ __attribute__((noreturn))
> ++#endif
> ++#endif
> +
> + /* Temporarily disable some warnings */
> + #define DISABLE_WARNING_DECLARATION_AFTER_STATEMENT \
> +@@ -414,16 +423,6 @@ static inline unsi

[OE-core] [PATCH] libcap: fix -native and usrmerge builds

[Mark Asselstine]

When attempting to build a -native package which DEPENDS on
libcap-native the libcap libraries are not found and the build will
fail (for example attempting to build qemu-native with
'PACKAGECONFIG_append = " virtfs"').

It turns out commit 2c9c4a406a0f [libcap: fix (base_)libdir usage]
breaks builds of libcap(-native) when $root_prefix is not "". This is
because the variables which define $root_prefix are also part of
$prefix so you end up with part of the path being used twice, first as
part of 'lib=' in do_compile, and secondly as part of 'prefix=' in
do_install. When $root_prefix is "" this isn't noticed.

By using $baselib we should not re-break the issue which commit
2c9c4a406a0f was fixing but we should avoid doubling down on the
paths thus fixing the -native and usrmerge builds.

Signed-off-by: Mark Asselstine 
---
 meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/libcap/libcap_2.25.bb 
b/meta/recipes-support/libcap/libcap_2.25.bb
index 47ecf34..6df6745 100644
--- a/meta/recipes-support/libcap/libcap_2.25.bb
+++ b/meta/recipes-support/libcap/libcap_2.25.bb
@@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
 
 EXTRA_OEMAKE = " \
   INDENT=  \
-  lib='${base_libdir}' \
+  lib='${baselib}' \
   RAISE_SETFCAP=no \
   DYNAMIC=yes \
   BUILD_GPERF=yes \
-- 
2.7.4

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

Re: [OE-core] [PATCH v2 2/4] libcap: fix (base_)libdir usage

[Mark Asselstine]

On Tuesday, May 8, 2018 2:26:47 PM EDT Mark Asselstine wrote:
> On Tuesday, May 8, 2018 1:46:43 PM EDT Ricardo Salveti wrote:
> > On Mon, Apr 16, 2018 at 10:00 AM, Koen Kooi 
> 
> wrote:
> > > The recipe wants to install libs into base_libdir, but uses "basename
> > > $libdir" to derive that. That breaks in a multiarch setup. Use the
> > > proper
> > > variable and remove the inline python usage.
> > > 
> > > Signed-off-by: Koen Kooi 
> > > ---
> > > 
> > >  meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/meta/recipes-support/libcap/libcap_2.25.bb
> > > b/meta/recipes-support/libcap/libcap_2.25.bb index d619a2e..47ecf34
> > > 100644
> > > --- a/meta/recipes-support/libcap/libcap_2.25.bb
> > > +++ b/meta/recipes-support/libcap/libcap_2.25.bb
> > > @@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
> > > 
> > >  EXTRA_OEMAKE = " \
> > >  
> > >INDENT=  \
> > > 
> > > -  lib=${@os.path.basename('${libdir}')} \
> > > +  lib='${base_libdir}' \
> > > 
> > >RAISE_SETFCAP=no \
> > >DYNAMIC=yes \
> > >BUILD_GPERF=yes \
> > 
> > This creates a build failure when usrmerge is used, as libcap expects
> > only the lib folder name and not the lib path (and when usrmerge is
> > enabled base_libdir gets set to /usr/lib instead of /lib).
> > 
> > Since base_libdir and libdir are all based out baselib, can you
> > provide more details about how that broke your multiarch setup?
> > 
> > The failure when usrmerge is used:
> > WARNING: libcap-2.25-r0 do_package: QA Issue: libcap:
> > 
> > Files/directories were installed but not shipped in any package:
> >   /usr/lib
> >   /usr/usr/lib/libcap.so
> >   /usr/usr/lib/libcap.so.2
> >   /usr/usr/lib/libcap.so.2.25
> >   /usr/usr/lib/libcap.a
> >   /usr/usr/lib/pkgconfig
> >   /usr/usr/lib/pkgconfig/libcap.pc
> >   /usr/usr/lib/security/pam_cap.so
> 
> Agreed. I just started to determine how this is breaking qemu-native (with
> virtfs enabled in the PACKAGECONFIG) and found that this change drops
> several files from being installed in the native-sysroot.
> 
> Before this change:
> ⟫ cat .../tmp/work/x86_64-linux/qemu-native/2.11.1-r0/recipe-sysroot-native/
> installeddeps/libcap-native.39df7fd64afdeb62b13bb47b7969532b
> recipe-sysroot-native/sysroot-providers/libcap-native
> recipe-sysroot-native/usr/include/sys/capability.h
> recipe-sysroot-native/usr/sbin/getpcaps
> recipe-sysroot-native/usr/sbin/capsh
> recipe-sysroot-native/usr/sbin/getcap
> recipe-sysroot-native/usr/sbin/setcap
> recipe-sysroot-native/usr/lib/libcap.so
> recipe-sysroot-native/usr/lib/libcap.so.2.25
> recipe-sysroot-native/usr/lib/libcap.a
> recipe-sysroot-native/usr/lib/libcap.so.2
> recipe-sysroot-native/usr/lib/pkgconfig/libcap.pc
> recipe-sysroot-native/usr/lib/pkgconfig/
> recipe-sysroot-native/sysroot-providers/
> recipe-sysroot-native/usr/include/sys/
> recipe-sysroot-native/usr/include/
> recipe-sysroot-native/usr/share/
> recipe-sysroot-native/usr/sbin/
> recipe-sysroot-native/usr/lib/
> recipe-sysroot-native/usr/
> 
> After the change:
> ⟫ cat .../tmp/work/x86_64-linux/qemu-native/2.11.1-r0/recipe-sysroot-native/
> installeddeps/libcap-native.2d12ea82cbd6eeaf25251caae2dce487
> recipe-sysroot-native/sysroot-providers/libcap-native
> recipe-sysroot-native/usr/include/sys/capability.h
> recipe-sysroot-native/usr/sbin/getpcaps
> recipe-sysroot-native/usr/sbin/capsh
> recipe-sysroot-native/usr/sbin/getcap
> recipe-sysroot-native/usr/sbin/setcap
> recipe-sysroot-native/sysroot-providers/
> recipe-sysroot-native/usr/include/sys/
> recipe-sysroot-native/usr/include/
> recipe-sysroot-native/usr/share/
> recipe-sysroot-native/usr/sbin/
> recipe-sysroot-native/usr/lib/
> recipe-sysroot-native/usr/
> 
> I also believe that the old inline python was also not functioning correctly
> which is why it was believed that the change was non-consequential for non-
> multilib builds. I am looking at putting together a fix but would be more
> than happy if someone else came up with something first.

Sorry, I stand corrected the python is functional, I was getting confused with 
the interplay between 'lib' used during make and 'prefix' used during install. 

The issue wtih the -native build is that $base_libdir is influenced by 
additions made in native.bbclase, specifically:

# Path prefixes
base_prefix = "

Re: [OE-core] [PATCH v2 2/4] libcap: fix (base_)libdir usage

[Mark Asselstine]

On Tuesday, May 8, 2018 1:46:43 PM EDT Ricardo Salveti wrote:
> On Mon, Apr 16, 2018 at 10:00 AM, Koen Kooi  
wrote:
> > The recipe wants to install libs into base_libdir, but uses "basename
> > $libdir" to derive that. That breaks in a multiarch setup. Use the proper
> > variable and remove the inline python usage.
> > 
> > Signed-off-by: Koen Kooi 
> > ---
> > 
> >  meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-support/libcap/libcap_2.25.bb
> > b/meta/recipes-support/libcap/libcap_2.25.bb index d619a2e..47ecf34
> > 100644
> > --- a/meta/recipes-support/libcap/libcap_2.25.bb
> > +++ b/meta/recipes-support/libcap/libcap_2.25.bb
> > @@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
> > 
> >  EXTRA_OEMAKE = " \
> >  
> >INDENT=  \
> > 
> > -  lib=${@os.path.basename('${libdir}')} \
> > +  lib='${base_libdir}' \
> > 
> >RAISE_SETFCAP=no \
> >DYNAMIC=yes \
> >BUILD_GPERF=yes \
> 
> This creates a build failure when usrmerge is used, as libcap expects
> only the lib folder name and not the lib path (and when usrmerge is
> enabled base_libdir gets set to /usr/lib instead of /lib).
> 
> Since base_libdir and libdir are all based out baselib, can you
> provide more details about how that broke your multiarch setup?
> 
> The failure when usrmerge is used:
> WARNING: libcap-2.25-r0 do_package: QA Issue: libcap:
> Files/directories were installed but not shipped in any package:
>   /usr/lib
>   /usr/usr/lib/libcap.so
>   /usr/usr/lib/libcap.so.2
>   /usr/usr/lib/libcap.so.2.25
>   /usr/usr/lib/libcap.a
>   /usr/usr/lib/pkgconfig
>   /usr/usr/lib/pkgconfig/libcap.pc
>   /usr/usr/lib/security/pam_cap.so

Agreed. I just started to determine how this is breaking qemu-native (with 
virtfs enabled in the PACKAGECONFIG) and found that this change drops several 
files from being installed in the native-sysroot.

Before this change:
⟫ cat .../tmp/work/x86_64-linux/qemu-native/2.11.1-r0/recipe-sysroot-native/
installeddeps/libcap-native.39df7fd64afdeb62b13bb47b7969532b 
recipe-sysroot-native/sysroot-providers/libcap-native
recipe-sysroot-native/usr/include/sys/capability.h
recipe-sysroot-native/usr/sbin/getpcaps
recipe-sysroot-native/usr/sbin/capsh
recipe-sysroot-native/usr/sbin/getcap
recipe-sysroot-native/usr/sbin/setcap
recipe-sysroot-native/usr/lib/libcap.so
recipe-sysroot-native/usr/lib/libcap.so.2.25
recipe-sysroot-native/usr/lib/libcap.a
recipe-sysroot-native/usr/lib/libcap.so.2
recipe-sysroot-native/usr/lib/pkgconfig/libcap.pc
recipe-sysroot-native/usr/lib/pkgconfig/
recipe-sysroot-native/sysroot-providers/
recipe-sysroot-native/usr/include/sys/
recipe-sysroot-native/usr/include/
recipe-sysroot-native/usr/share/
recipe-sysroot-native/usr/sbin/
recipe-sysroot-native/usr/lib/
recipe-sysroot-native/usr/

After the change:
⟫ cat .../tmp/work/x86_64-linux/qemu-native/2.11.1-r0/recipe-sysroot-native/
installeddeps/libcap-native.2d12ea82cbd6eeaf25251caae2dce487
recipe-sysroot-native/sysroot-providers/libcap-native
recipe-sysroot-native/usr/include/sys/capability.h
recipe-sysroot-native/usr/sbin/getpcaps
recipe-sysroot-native/usr/sbin/capsh
recipe-sysroot-native/usr/sbin/getcap
recipe-sysroot-native/usr/sbin/setcap
recipe-sysroot-native/sysroot-providers/
recipe-sysroot-native/usr/include/sys/
recipe-sysroot-native/usr/include/
recipe-sysroot-native/usr/share/
recipe-sysroot-native/usr/sbin/
recipe-sysroot-native/usr/lib/
recipe-sysroot-native/usr/

I also believe that the old inline python was also not functioning correctly 
which is why it was believed that the change was non-consequential for non-
multilib builds. I am looking at putting together a fix but would be more than 
happy if someone else came up with something first.

Mark


> 
> Thanks,




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

Re: [OE-core] [PATCH 1/3] latencytop: remove recipe

[Mark Asselstine]

On Tuesday, February 13, 2018 2:27:49 PM EST Randy MacLeod wrote:
> On 2018-02-08 03:22 PM, Alexander Kanavin wrote:
> > Last commit and release were in 2009; website is down; it's a dead
> > project.
> 
> Add MarkA who might care/know more about latencytop than I do.

I believe Bruce had already identified LatencyTop as a dead end by the time we 
even did our first release of OVP (I have no recollection of ever including it 
and there are 0 user stories in Rally which would validate my memories on this 
subject). Just in case I have added Bruce to the list. We already had LTTng 
and FTrace, including a mostly dead Intel project was not a priority if I 
recall correctly.

MarkA

> 
> 
> Is there another package that makes use of the kernel feature?
> The kernel Kconfig has been tweaked in 2017:
> 
> commit a34a766ff96d9e88572e35a45066279e40a85d84
> Author: Josh Poimboeuf 
> Date:   Mon Jul 24 18:36:58 2017 -0500
> 
>   x86/kconfig: Make it easier to switch to the new ORC unwinder
> 
> and there are people updating latencytop on github last year:
> https://github.com/namhyung/latencytop/commits/master
> commits on some random github page. That's shocking I know but it
> does indicate that there's still interest in the tool even if the
> original authors haven't been maintaining it.
> 
> ../Randy
> 
> 
> 


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

Re: [OE-core] [PATCH 1/2] gtk-doc: update to 1.27

[Mark Asselstine]

On Friday, February 9, 2018 2:03:01 AM EST Alexander Kanavin wrote:
> On 02/09/2018 12:13 AM, Mark Asselstine wrote:
> > The use of libunique is non-consequential here. The issue is that the
> > gtk-doc package has imports which are not going to be present via direct
> > runtime dependencies. Any sw which attempts to run the python scripts
> > found in gtk-doc will fail in the same way unless the python3-six is
> > installed via an indirect dependency. I didn't have a chance to dig in to
> > this deeper today so I don't have more to add than this but the "import
> > six" is pretty explicit and will fail unless this script is not meant to
> > actually be run anytime, anywhere.
> gtk-doc recipe does have a direct dependency on python3-six, subject to
> 'api-documentation' in DISTRO_FEATURES. The reason it's conditional is
> that we don't want to build a ton of gtk-doc dependencies in the default
> case that used by almost everyone. Yes, this produces gtk-doc scripts
> that are not working, but they will not be run anyway, if gtk-doc
> capable recipes inherit the gtk-doc class, which will disable the
> gtk-doc feature. libunique was missing that inherit, the patch to fix
> that is now on oe-devl list. Take it and the issue will go away.

Thanks for sending out the updates, I am giving them a go. I wasn't clear 
about the intention based on your initial change so glad I reached out to you 
and that this will move on.

Thanks again,
Mark

> 
> Alex


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

Re: [OE-core] [PATCH 1/2] gtk-doc: update to 1.27

[Mark Asselstine]

On Thursday, February 8, 2018 1:44:02 AM EST Alexander Kanavin wrote:
> On 02/07/2018 11:34 PM, Mark Asselstine wrote:
> > Alexander. When things move to python you can almost always bet on them
> > requiring additional libraries and as such the lack of RDEPENDS here is a
> > bit surprising. As you can see from the top of some of the py files in
> > gtk-doc we have:
> > 
> > import logging
> > import os
> > import re
> > import subprocess
> > import sys
> > import six
> > import codecs
> > 
> > Some of which are python stdlibs but others are external modules, such as
> > 
> > 'six'. As such I am now getting a build failure:
> >   -- Installing ../../../libunique-1.1.6/doc/reference/html/up.png
> >   
> >   Traceback (most recent call last):
> >File
> >"/home/mark/build/overc/tmp/work/core2-64-overc-linux/libunique/
> >1.1.6-r7/recipe-sysroot-native/usr/bin/gtkdoc-rebase", line 28, in
> >
> > 
> >   
> >   from gtkdoc import common, config, rebase
> >   File
> >   "/home/mark/build/overc/tmp/work/core2-64-overc-linux/libunique/
> >   1.1.6-r7/recipe-sysroot-native/usr/share/gtk-doc/python/gtkdoc/
> >   common.py", line 31, in 
> >   import six
> >   
> >   ImportError: No module named 'six'
> > 
> > So we need to RDEPENDS on "python-six" here for starters. We do have a
> > recipe for python-six but it is in meta-openembedded. So we either need
> > to move this recipe there or the python-six recipe to oe-core or...
> 
> Thanks for the failure report Mark, but the diagnosis is way off :-)
> 
> First of all, for what purpose are you even building libunique? It's a
> very old, unmaintained library for gtk 2.x apps from gnome stack (last
> release: 2011), and here's what gnome has to say about it: "Unique is
> now in maintenance mode and its usage is strongly discouraged".
> 

The use of libunique is non-consequential here. The issue is that the gtk-doc 
package has imports which are not going to be present via direct runtime 
dependencies. Any sw which attempts to run the python scripts found in gtk-doc 
will fail in the same way unless the python3-six is installed via an indirect 
dependency. I didn't have a chance to dig in to this deeper today so I don't 
have more to add than this but the "import six" is pretty explicit and will 
fail unless this script is not meant to actually be run anytime, anywhere.

Mark

> It's coming from the gnome section of meta-oe, which is badly suffering
> from lack of maintenance and general bitrot. I think much of it was
> about to be removed a few months ago at last, but for some reason it
> hasn't happened.
> 
> This specific failure is because libunique recipe neither inherits
> gtk-doc class (which correctly sets things up) nor explicitly disables
> gtk-doc. I'm now building the rest of meta-oe to check if anything else
> needs to be fixed up, and will send a patch in a moment.
> 
> Alex


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

Re: [OE-core] [PATCH 1/2] gtk-doc: update to 1.27

[Mark Asselstine]

On Friday, February 2, 2018 12:38:14 PM EST Alexander Kanavin wrote:
> Gtk-doc has been rewritten in Python, so drop perl dependencies (good
> riddance!), and adjust patches to reflect that.
> 
> Signed-off-by: Alexander Kanavin 
> ---

Alexander. When things move to python you can almost always bet on them 
requiring additional libraries and as such the lack of RDEPENDS here is a bit 
surprising. As you can see from the top of some of the py files in gtk-doc we 
have:

import logging
import os
import re
import subprocess
import sys
import six
import codecs

Some of which are python stdlibs but others are external modules, such as 
'six'. As such I am now getting a build failure:

 -- Installing ../../../libunique-1.1.6/doc/reference/html/up.png
 Traceback (most recent call last):
  File "/home/mark/build/overc/tmp/work/core2-64-overc-linux/libunique/
  1.1.6-r7/recipe-sysroot-native/usr/bin/gtkdoc-rebase", line 28, in 
   
 from gtkdoc import common, config, rebase
 File "/home/mark/build/overc/tmp/work/core2-64-overc-linux/libunique/
 1.1.6-r7/recipe-sysroot-native/usr/share/gtk-doc/python/gtkdoc/
 common.py", line 31, in 
 import six
 ImportError: No module named 'six'

So we need to RDEPENDS on "python-six" here for starters. We do have a recipe 
for python-six but it is in meta-openembedded. So we either need to move this 
recipe there or the python-six recipe to oe-core or...

I have added Derek to the CC as he is being a good sport and working hard on 
python recipes and might have thoughts on the best solution here.

Mark Asselstine

>  ...r-out-if-perl-is-not-found-or-its-version.patch |  40 --
>  ...hardocode-paths-to-perl-python-in-scripts.patch | 155
> +++-- .../gtk-doc/files/conditionaltests.patch   | 
> 26 +++-
>  .../gtk-doc/files/pkg-config-native.patch  |  22 ++-
>  .../gtk-doc/{gtk-doc_1.25.bb => gtk-doc_1.27.bb}   |  15 +-
>  5 files changed, 119 insertions(+), 139 deletions(-)
>  delete mode 100644
> meta/recipes-gnome/gtk-doc/files/0001-Do-not-error-out-if-perl-is-not-found
> -or-its-version.patch rename meta/recipes-gnome/gtk-doc/{gtk-doc_1.25.bb =>
> gtk-doc_1.27.bb} (81%)
> 
> diff --git
> a/meta/recipes-gnome/gtk-doc/files/0001-Do-not-error-out-if-perl-is-not-fou
> nd-or-its-version.patch
> b/meta/recipes-gnome/gtk-doc/files/0001-Do-not-error-out-if-perl-is-not-fou
> nd-or-its-version.patch deleted file mode 100644
> index 4a9028742ca..000
> ---
> a/meta/recipes-gnome/gtk-doc/files/0001-Do-not-error-out-if-perl-is-not-fou
> nd-or-its-version.patch +++ /dev/null
> @@ -1,40 +0,0 @@
> -From e733241fb580f032efbbe684ec35d4c9d27f1595 Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin 
> -Date: Thu, 8 Sep 2016 13:38:39 +0300
> -Subject: [PATCH] Do not error out if perl is not found or its version is
> too - old.
> -
> -This allows use to avoid depending on perl-native if we're not going
> -to use it (when api-docs are disabled).
> -
> -Upstream-Status: Inappropriate [oe-core specific]
> -Signed-off-by: Alexander Kanavin 
> 
> - configure.ac | 4 ++--
> - 1 file changed, 2 insertions(+), 2 deletions(-)
> -
> -diff --git a/configure.ac b/configure.ac
> -index 2a61d6e..29415bd 100644
>  a/configure.ac
> -+++ b/configure.ac
> -@@ -36,7 +36,7 @@ dnl Check for Perl.
> - dnl
> - AC_PATH_PROG([PERL], [perl])
> - if test -z "$PERL"; then
> --AC_MSG_ERROR([perl not found])
> -+AC_MSG_WARN([perl not found])
> - fi
> -
> - AC_MSG_CHECKING([if Perl version >= 5.18.0])
> -@@ -44,7 +44,7 @@ if "$PERL" -e "require v5.18.0"; then
> - AC_MSG_RESULT([yes])
> - else
> - AC_MSG_RESULT([no])
> --AC_MSG_ERROR([perl >= 5.18.0 is required for gtk-doc])
> -+AC_MSG_WARN([perl >= 5.18.0 is required for gtk-doc])
> - fi
> -
> - dnl
> ---
> -2.9.3
> -
> diff --git
> a/meta/recipes-gnome/gtk-doc/files/0001-Do-not-hardocode-paths-to-perl-pyth
> on-in-scripts.patch
> b/meta/recipes-gnome/gtk-doc/files/0001-Do-not-hardocode-paths-to-perl-pyth
> on-in-scripts.patch index 477fc9ae8c1..2fe3ab9221f 100644
> ---
> a/meta/recipes-gnome/gtk-doc/files/0001-Do-not-hardocode-paths-to-perl-pyth
> on-in-scripts.patch +++
> b/meta/recipes-gnome/gtk-doc/files/0001-Do-not-hardocode-paths-to-perl-pyth
> on-in-scripts.patch @@ -1,7 +1,7 @@
> -From 6fab82b93c7bd301eb42448515b02f7cb3306897 Mon Sep 17 00:00:00 2001
> +From 928102874bc2339a1d57c6b178877e0c6002cb3a Mon Sep 17 00:00:00 2001
>  From: Alexander Kanavin 
>  Date: Wed, 31 Aug 2016 16:44:46 +0300
> -Subject: [PATCH] Do not hardocode paths to perl/python in scripts.
> +Subject: [PATCH 1/3] Do not hardocode paths to

Re: [OE-core] [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22)

[Mark Asselstine]

On Monday, December 18, 2017 4:07:44 PM EST Derek Straka wrote:
> I also need to look at the UPSTREAM_CHECK_URI for this recipe since it
> isn't finding the latest version and telling me to update the package.

Odd. Let me know how it goes. If it is easier for you to make the changes 
locally and complete the merge go for it.

Mark

> 
> On Mon, Dec 18, 2017 at 4:02 PM, S. Lockwood-Childs  wrote:
> > On Mon, Dec 18, 2017 at 03:17:25PM -0500, Derek Straka wrote:
> > > I have several customers who have optimized for space and would like to
> > 
> > see
> > 
> > > the capability maintained unless core removes the ability to split
> > > python
> > > packages out.  They also remove the *.py files in favor of *.pyo files
> > 
> > (via
> > 
> > > a custom packaging mechanism).  I have automated tests that go through
> > 
> > the
> > 
> > > module importing on each of the meta-python packages to ensure it works
> > 
> > on
> > 
> > > minimal python installations.  When other contributors don't do provide
> > > that functionality, I either catch it when I do package update or when
> > > it
> > > breaks for one of my customers.  I'm fine if you don't want to perform
> > 
> > the
> > 
> > > checks yourself and it breaks my use case with missing dependencies, but
> > 
> > I
> > 
> > > would prefer that you don't remove the dependencies that are currently
> > > in
> > > place.  Thanks.
> > 
> > Me too -- some of my projects still use NAND for rootfs, where space is
> > tight and
> > ability to split out python modules is very useful. Thus it is not an
> > unused
> > feature, though many projects have SD/eMMC for rootfs and those ones
> > generally
> > will not care about it.


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

Re: [OE-core] [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22)

[Mark Asselstine]

On Mon, Dec 18, 2017 at 3:17 PM, Derek Straka  wrote:
> I have several customers who have optimized for space and would like to see
> the capability maintained unless core removes the ability to split python
> packages out.  They also remove the *.py files in favor of *.pyo files (via
> a custom packaging mechanism).  I have automated tests that go through the
> module importing on each of the meta-python packages to ensure it works on
> minimal python installations.  When other contributors don't do provide
> that functionality, I either catch it when I do package update or when it
> breaks for one of my customers.  I'm fine if you don't want to perform the
> checks yourself and it breaks my use case with missing dependencies, but I
> would prefer that you don't remove the dependencies that are currently in
> place.  Thanks.

I can respect this approach. I will put the RDEPENDS back and send out a V2.

As for the overall approach being applied to all python recipes, my
opinion still stands that this is such a small subset that we are
devoting time better spent elsewhere to service the few.

Mark

>
> -Derek
>
> On Mon, Dec 18, 2017 at 11:56 AM, Mark Asselstine <
> mark.asselst...@windriver.com> wrote:
>
>> On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin
>>  wrote:
>> > On 12/18/2017 06:15 PM, Mark Asselstine wrote:
>> >>
>> >> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson > >
>> >> wrote:
>> >>>
>> >>> All our python recipes should be explicitly listing the python module
>> >>> packages they require. No python module recipes should be depending on
>> >>> python-modules or python3-modules, but explicitly what they require.
>> >>
>> >>
>> >> This is a giant PITA for little gain in my opinion. The typical python
>> >> 'vehicles' to define dependencies, things like setup.py, requires.txt,
>> >> requirements.txt..., never bother to list stdlibs. These are standard
>> >> libs that are just expected to be there. If a system is being
>> >> installed with only select python modules it will behave differently
>> >> than python found on any other system violating the rule of least
>> >> surprise. On top of this most of these modules are ~40K in size and
>> >> there are roughly 60 in the stdlib so the size gain in installing a
>> >> few vs. all of them is extremely negligible. All of this seems to add
>> >> way more work and churn that outweighs any real benefit.
>> >
>> >
>> > I tend to agree with this. Add also the situation that the yocto project
>> > needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7
>> soon
>> > after, no one has enough time to do this rather non-trivial job, and I'm
>> > beginning to wonder if the best way out is to remove the module splitting
>> > altogether, and write a clean, simple and maintainable python3 recipe
>> from
>> > scratch with minimal amount of custom patching and hopefully no
>> write-only
>> > hacks.
>> >
>> > Alex
>>
>> Thanks Alex for the support. To get a better idea as to what the size
>> delta is I took the installed sizes from a rootfs logfile and the
>> total size for all modules (python2.7) is 6.5M python-misc is almost
>> 2M of this and python-codecs contributing over 0.5M. The savings will
>> never be the full 6.5M as there will always be python-lang and some
>> other modules needed. There was a time where 32M restrictions existed
>> are some systems but are we really seeing devices with these
>> restrictions any more? what about exploring not shipping the pyc
>> files? I would much rather see this than imposing so much work and
>> churn for very little gain. Anyways, maybe this isn't the best forum
>> for this and it should be brought up to the architecture group.
>>
>> Mark
>>
>> >
>> > --
>> > ___
>> > Openembedded-devel mailing list
>> > openembedded-de...@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>> --
>> ___
>> Openembedded-devel mailing list
>> openembedded-de...@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
> --
> ___
> Openembedded-devel mailing list
> openembedded-de...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] [meta-python][PATCH] python-pyroute2: uprev to v0.4.21 (from 0.3.22)

[Mark Asselstine]

On Mon, Dec 18, 2017 at 11:37 AM, Alexander Kanavin
 wrote:
> On 12/18/2017 06:15 PM, Mark Asselstine wrote:
>>
>> On Mon, Dec 18, 2017 at 10:36 AM, Christopher Larson 
>> wrote:
>>>
>>> All our python recipes should be explicitly listing the python module
>>> packages they require. No python module recipes should be depending on
>>> python-modules or python3-modules, but explicitly what they require.
>>
>>
>> This is a giant PITA for little gain in my opinion. The typical python
>> 'vehicles' to define dependencies, things like setup.py, requires.txt,
>> requirements.txt..., never bother to list stdlibs. These are standard
>> libs that are just expected to be there. If a system is being
>> installed with only select python modules it will behave differently
>> than python found on any other system violating the rule of least
>> surprise. On top of this most of these modules are ~40K in size and
>> there are roughly 60 in the stdlib so the size gain in installing a
>> few vs. all of them is extremely negligible. All of this seems to add
>> way more work and churn that outweighs any real benefit.
>
>
> I tend to agree with this. Add also the situation that the yocto project
> needs to upgrade oe-core to python 3.6 as soon as possible, and to 3.7 soon
> after, no one has enough time to do this rather non-trivial job, and I'm
> beginning to wonder if the best way out is to remove the module splitting
> altogether, and write a clean, simple and maintainable python3 recipe from
> scratch with minimal amount of custom patching and hopefully no write-only
> hacks.
>
> Alex

Thanks Alex for the support. To get a better idea as to what the size
delta is I took the installed sizes from a rootfs logfile and the
total size for all modules (python2.7) is 6.5M python-misc is almost
2M of this and python-codecs contributing over 0.5M. The savings will
never be the full 6.5M as there will always be python-lang and some
other modules needed. There was a time where 32M restrictions existed
are some systems but are we really seeing devices with these
restrictions any more? what about exploring not shipping the pyc
files? I would much rather see this than imposing so much work and
churn for very little gain. Anyways, maybe this isn't the best forum
for this and it should be brought up to the architecture group.

Mark

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

[OE-core] [PATCH 3/3] utils: qemurunner.py: cleanup grammar and ensure consistency

[Mark Asselstine]

Minor grammar correction along with making the term 'login banner'
consistent throughout to make searching logs easier.

Signed-off-by: Mark Asselstine 
---
 meta/lib/oeqa/utils/qemurunner.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index dfcd63e..c962602 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -317,7 +317,7 @@ class QemuRunner:
 
 if not reachedlogin:
 if time.time() >= endtime:
-self.logger.debug("Target didn't reached login boot in %d 
seconds (%s)" %
+self.logger.debug("Target didn't reach login banner in %d 
seconds (%s)" %
   (self.boottime, time.strftime("%D 
%H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
 # in case bootlog is empty, use tail qemu log store at self.msg
-- 
2.7.4

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

[OE-core] [PATCH 2/3] utils: qemurunner.py: Log both 'failed to reach login banner" reasons

[Mark Asselstine]

The current logging always assumes the boot timeout has expired yet
there is a second reason we might have ended up in a position where no
login banner was found, that being a socket disconnect. Add logging
for the disconnect case and make the timeout expiration conditional on
the timeout being exhausted.

Signed-off-by: Mark Asselstine 
---
 meta/lib/oeqa/utils/qemurunner.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 8296e98..dfcd63e 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -307,14 +307,18 @@ class QemuRunner:
   (time.time() - (endtime - 
self.boottime),
   time.strftime("%D %H:%M:%S")))
 else:
+# no need to check if reachedlogin unless we support 
multiple connections
+self.logger.debug("QEMU socket disconnected before 
login banner reached. (%s)" %
+  time.strftime("%D %H:%M:%S"))
 socklist.remove(sock)
 sock.close()
 stopread = True
 
 
 if not reachedlogin:
-self.logger.debug("Target didn't reached login boot in %d seconds 
(%s)" %
-  (self.boottime, time.strftime("%D %H:%M:%S")))
+if time.time() >= endtime:
+self.logger.debug("Target didn't reached login boot in %d 
seconds (%s)" %
+  (self.boottime, time.strftime("%D 
%H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
 # in case bootlog is empty, use tail qemu log store at self.msg
 lines = tail(bootlog if bootlog else self.msg)
-- 
2.7.4

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

[OE-core] [PATCH 1/3] utils: qemurunner.py: Add wall clock to 'timeout' logging

[Mark Asselstine]

When debugging issues when timeouts are involved it is always best to
have wall clock times included. This helps give confidence that the
timeout is in fact run down at the right rate and that no unexpected
events were the true cause of a premature running down of the
timeout. Having these times in old logs also helps when debugging
issues as we have a historic record as to what is a 'typical' time to
complete an action.

In addition to adding the wall clock times the time to 'login' is now
printed making it consistent with the time to 'qemu pid'.

Signed-off-by: Mark Asselstine 
---
 meta/lib/oeqa/utils/qemurunner.py | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 0631d43..8296e98 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -194,7 +194,8 @@ class QemuRunner:
 sys.exit(0)
 
 self.logger.debug("runqemu started, pid is %s" % self.runqemu.pid)
-self.logger.debug("waiting at most %s seconds for qemu pid" % 
self.runqemutime)
+self.logger.debug("waiting at most %s seconds for qemu pid (%s)" %
+  (self.runqemutime, time.strftime("%D %H:%M:%S")))
 endtime = time.time() + self.runqemutime
 while not self.is_alive() and time.time() < endtime:
 if self.runqemu.poll():
@@ -208,7 +209,8 @@ class QemuRunner:
 time.sleep(0.5)
 
 if not self.is_alive():
-self.logger.error("Qemu pid didn't appear in %s seconds" % 
self.runqemutime)
+self.logger.error("Qemu pid didn't appear in %s seconds (%s)" %
+  (self.runqemutime, time.strftime("%D %H:%M:%S")))
 # Dump all processes to help us to figure out what is going on...
 ps = subprocess.Popen(['ps', 'axww', '-o', 'pid,ppid,command '], 
stdout=subprocess.PIPE).communicate()[0]
 processes = ps.decode("utf-8")
@@ -225,7 +227,9 @@ class QemuRunner:
 # We are alive: qemu is running
 out = self.getOutput(output)
 netconf = False # network configuration is not required by default
-self.logger.debug("qemu started in %s seconds - qemu procces pid is 
%s" % (time.time() - (endtime - self.runqemutime), self.qemupid))
+self.logger.debug("qemu started in %s seconds - qemu procces pid is %s 
(%s)" %
+  (time.time() - (endtime - self.runqemutime),
+   self.qemupid, time.strftime("%D %H:%M:%S")))
 if get_ip:
 cmdline = ''
 with open('/proc/%s/cmdline' % self.qemupid) as p:
@@ -269,7 +273,8 @@ class QemuRunner:
 return False
 
 self.logger.debug("Output from runqemu:\n%s", out)
-self.logger.debug("Waiting at most %d seconds for login banner" % 
self.boottime)
+self.logger.debug("Waiting at most %d seconds for login banner (%s)" %
+  (self.boottime, time.strftime("%D %H:%M:%S")))
 endtime = time.time() + self.boottime
 socklist = [self.server_socket]
 reachedlogin = False
@@ -298,7 +303,9 @@ class QemuRunner:
 self.server_socket = qemusock
 stopread = True
 reachedlogin = True
-self.logger.debug("Reached login banner")
+self.logger.debug("Reached login banner in %s 
seconds (%s)" %
+  (time.time() - (endtime - 
self.boottime),
+  time.strftime("%D %H:%M:%S")))
 else:
 socklist.remove(sock)
 sock.close()
@@ -306,7 +313,8 @@ class QemuRunner:
 
 
 if not reachedlogin:
-self.logger.debug("Target didn't reached login boot in %d seconds" 
% self.boottime)
+self.logger.debug("Target didn't reached login boot in %d seconds 
(%s)" %
+  (self.boottime, time.strftime("%D %H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
 # in case bootlog is empty, use tail qemu log store at self.msg
 lines = tail(bootlog if bootlog else self.msg)
-- 
2.7.4

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

[OE-core] [PATCH 2/3] utils: qemurunner.py: Log both 'failed to reach login banner" reasons

[Mark Asselstine]

The current logging always assumes the boot timeout has expired yet
there is a second reason we might have ended up in a position where no
login banner was found, that being a socket disconnect. Add logging
for the disconnect case and make the timeout expiration conditional on
the timeout being exhausted.

Signed-off-by: Mark Asselstine 
---
 meta/lib/oeqa/utils/qemurunner.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 2121a0d..f31c2ca 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -311,14 +311,18 @@ class QemuRunner:
 except UnicodeDecodeError:
 continue
 else:
+# no need to check if reachedlogin unless we support 
multiple connections
+self.logger.debug("QEMU socket disconnected before 
login banner reached. (%s)" %
+  time.strftime("%D %H:%M:%S"))
 socklist.remove(sock)
 sock.close()
 stopread = True
 
 
 if not reachedlogin:
-self.logger.debug("Target didn't reached login boot in %d seconds 
(%s)" %
-  (self.boottime, time.strftime("%D %H:%M:%S")))
+if time.time() >= endtime:
+self.logger.debug("Target didn't reached login boot in %d 
seconds (%s)" %
+  (self.boottime, time.strftime("%D 
%H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
 # in case bootlog is empty, use tail qemu log store at self.msg
 lines = tail(bootlog if bootlog else self.msg)
-- 
2.7.4

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

[OE-core] [PATCH 3/3] utils: qemurunner.py: cleanup grammar and ensure consistency

[Mark Asselstine]

Minor grammar correction along with making the term 'login banner'
consistent throughout to make searching logs easier.

Signed-off-by: Mark Asselstine 
---
 meta/lib/oeqa/utils/qemurunner.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index f31c2ca..180086d 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -321,7 +321,7 @@ class QemuRunner:
 
 if not reachedlogin:
 if time.time() >= endtime:
-self.logger.debug("Target didn't reached login boot in %d 
seconds (%s)" %
+self.logger.debug("Target didn't reach login banner in %d 
seconds (%s)" %
   (self.boottime, time.strftime("%D 
%H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
 # in case bootlog is empty, use tail qemu log store at self.msg
-- 
2.7.4

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

[OE-core] [PATCH 1/3] utils: qemurunner.py: Add wall clock to 'timeout' logging

[Mark Asselstine]

When debugging issues when timeouts are involved it is always best to
have wall clock times included. This helps give confidence that the
timeout is in fact run down at the right rate and that no unexpected
events were the true cause of a premature running down of the
timeout. Having these times in old logs also helps when debugging
issues as we have a historic record as to what is a 'typical' time to
complete an action.

In addition to adding the wall clock times the time to 'login' is now
printed making it consistent with the time to 'qemu pid'.

Signed-off-by: Mark Asselstine 
---
 meta/lib/oeqa/utils/qemurunner.py | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 82335d8..2121a0d 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -194,7 +194,8 @@ class QemuRunner:
 sys.exit(0)
 
 self.logger.debug("runqemu started, pid is %s" % self.runqemu.pid)
-self.logger.debug("waiting at most %s seconds for qemu pid" % 
self.runqemutime)
+self.logger.debug("waiting at most %s seconds for qemu pid (%s)" %
+  (self.runqemutime, time.strftime("%D %H:%M:%S")))
 endtime = time.time() + self.runqemutime
 while not self.is_alive() and time.time() < endtime:
 if self.runqemu.poll():
@@ -208,7 +209,8 @@ class QemuRunner:
 time.sleep(0.5)
 
 if not self.is_alive():
-self.logger.error("Qemu pid didn't appear in %s seconds" % 
self.runqemutime)
+self.logger.error("Qemu pid didn't appear in %s seconds (%s)" %
+  (self.runqemutime, time.strftime("%D %H:%M:%S")))
 # Dump all processes to help us to figure out what is going on...
 ps = subprocess.Popen(['ps', 'axww', '-o', 'pid,ppid,command '], 
stdout=subprocess.PIPE).communicate()[0]
 processes = ps.decode("utf-8")
@@ -225,7 +227,9 @@ class QemuRunner:
 # We are alive: qemu is running
 out = self.getOutput(output)
 netconf = False # network configuration is not required by default
-self.logger.debug("qemu started in %s seconds - qemu procces pid is 
%s" % (time.time() - (endtime - self.runqemutime), self.qemupid))
+self.logger.debug("qemu started in %s seconds - qemu procces pid is %s 
(%s)" %
+  (time.time() - (endtime - self.runqemutime),
+   self.qemupid, time.strftime("%D %H:%M:%S")))
 if get_ip:
 cmdline = ''
 with open('/proc/%s/cmdline' % self.qemupid) as p:
@@ -269,7 +273,8 @@ class QemuRunner:
 return False
 
 self.logger.debug("Output from runqemu:\n%s", out)
-self.logger.debug("Waiting at most %d seconds for login banner" % 
self.boottime)
+self.logger.debug("Waiting at most %d seconds for login banner (%s)" %
+  (self.boottime, time.strftime("%D %H:%M:%S")))
 endtime = time.time() + self.boottime
 socklist = [self.server_socket]
 reachedlogin = False
@@ -300,7 +305,9 @@ class QemuRunner:
 self.server_socket = qemusock
 stopread = True
 reachedlogin = True
-self.logger.debug("Reached login banner")
+self.logger.debug("Reached login banner in %s 
seconds (%s)" %
+  (time.time() - (endtime - 
self.boottime),
+  time.strftime("%D 
%H:%M:%S")))
 except UnicodeDecodeError:
 continue
 else:
@@ -310,7 +317,8 @@ class QemuRunner:
 
 
 if not reachedlogin:
-self.logger.debug("Target didn't reached login boot in %d seconds" 
% self.boottime)
+self.logger.debug("Target didn't reached login boot in %d seconds 
(%s)" %
+  (self.boottime, time.strftime("%D %H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
 # in case bootlog is empty, use tail qemu log store at self.msg
 lines = tail(bootlog if bootlog else self.msg)
-- 
2.7.4

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

Re: [OE-core] [IGNORE][PATCH] linux-yocto_4.12.bb: Use AUTOREV for qemu* BSPs

[Mark Asselstine]

On Tuesday, October 24, 2017 5:21:35 PM EDT Bruce Ashfield wrote:
> On Tue, Oct 24, 2017 at 5:17 PM, Mark Asselstine
> 
>  wrote:
> > The kernel we ship as part of product may have newer commits beyond
> > any SRCREV captured in this recipe. Since the assignment operator used
> > here is an early assiignment it could be argued that we could simply
> > overwrite these in a bbappend, however, between layer order and
> > priority and our desire to allow folks to set their own assignment it
> > is most prudent to change these to AUTOREV here.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> > Richard, Bruce,
> > 
> > This is being sent only to conform with YP compliance and I don't
> > expect or want this applied. No need to respond in any form.
> 
> .. but I can't help myself.
> 
> I find that patch, really, really odd. Compliance or not.

Its been a long day. There is an internal mail on the subject if you want to 
discuss details. I don't think we need to bore Richard and others with the 
details. I am sure there exists alternatives but given all the fun that today 
was this is what we came up with.

Mark

> 
> Bruce
> 
> > Mark
> > 
> >  meta/recipes-kernel/linux/linux-yocto_4.12.bb | 9 +
> >  1 file changed, 1 insertion(+), 8 deletions(-)
> > 
> > diff --git a/meta/recipes-kernel/linux/linux-yocto_4.12.bb
> > b/meta/recipes-kernel/linux/linux-yocto_4.12.bb index a262409..919bf31
> > 100644
> > --- a/meta/recipes-kernel/linux/linux-yocto_4.12.bb
> > +++ b/meta/recipes-kernel/linux/linux-yocto_4.12.bb
> > @@ -11,14 +11,7 @@ KBRANCH_qemux86  ?= "standard/base"
> > 
> >  KBRANCH_qemux86-64 ?= "standard/base"
> >  KBRANCH_qemumips64 ?= "standard/mti-malta64"
> > 
> > -SRCREV_machine_qemuarm ?= "67b62d8d7bd9f19f0f4fad044787d947ebc4ec25"
> > -SRCREV_machine_qemuarm64 ?= "16de0149674ed12d983b77a453852ac2e64584b4"
> > -SRCREV_machine_qemumips ?= "371926551d44c140a0fb869cec34762b40bdf1a6"
> > -SRCREV_machine_qemuppc ?= "16de0149674ed12d983b77a453852ac2e64584b4"
> > -SRCREV_machine_qemux86 ?= "16de0149674ed12d983b77a453852ac2e64584b4"
> > -SRCREV_machine_qemux86-64 ?= "16de0149674ed12d983b77a453852ac2e64584b4"
> > -SRCREV_machine_qemumips64 ?= "9d63d9c11c44ceabd452d7ee49cf55a88c39383f"
> > -SRCREV_machine ?= "16de0149674ed12d983b77a453852ac2e64584b4"
> > +SRCREV_machine ?= "${AUTOREV}"
> > 
> >  SRCREV_meta ?= "eda4d18ce4b259c84ccd5c249c3dc5958c16928c"
> >  
> >  SRC_URI =
> >  "git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${K
> >  BRANCH}; \> 
> > --
> > 2.7.4
> > 
> > --
> > ___
> > 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

[OE-core] [IGNORE][PATCH] linux-yocto_4.12.bb: Use AUTOREV for qemu* BSPs

[Mark Asselstine]

The kernel we ship as part of product may have newer commits beyond
any SRCREV captured in this recipe. Since the assignment operator used
here is an early assiignment it could be argued that we could simply
overwrite these in a bbappend, however, between layer order and
priority and our desire to allow folks to set their own assignment it
is most prudent to change these to AUTOREV here.

Signed-off-by: Mark Asselstine 
---

Richard, Bruce,

This is being sent only to conform with YP compliance and I don't
expect or want this applied. No need to respond in any form.

Mark


 meta/recipes-kernel/linux/linux-yocto_4.12.bb | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto_4.12.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.12.bb
index a262409..919bf31 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.12.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.12.bb
@@ -11,14 +11,7 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "67b62d8d7bd9f19f0f4fad044787d947ebc4ec25"
-SRCREV_machine_qemuarm64 ?= "16de0149674ed12d983b77a453852ac2e64584b4"
-SRCREV_machine_qemumips ?= "371926551d44c140a0fb869cec34762b40bdf1a6"
-SRCREV_machine_qemuppc ?= "16de0149674ed12d983b77a453852ac2e64584b4"
-SRCREV_machine_qemux86 ?= "16de0149674ed12d983b77a453852ac2e64584b4"
-SRCREV_machine_qemux86-64 ?= "16de0149674ed12d983b77a453852ac2e64584b4"
-SRCREV_machine_qemumips64 ?= "9d63d9c11c44ceabd452d7ee49cf55a88c39383f"
-SRCREV_machine ?= "16de0149674ed12d983b77a453852ac2e64584b4"
+SRCREV_machine ?= "${AUTOREV}"
 SRCREV_meta ?= "eda4d18ce4b259c84ccd5c249c3dc5958c16928c"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.12.git;name=machine;branch=${KBRANCH};
 \
-- 
2.7.4

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

[OE-core] [PATCH] gnome-themes-standard: drop .la file as unused

[Mark Asselstine]

oe-core commit 51b3ee298635b11d5784caaa0ac1c8f4034c25a5
[gnome-themes-standard: Fix packages so dev-pkgs image generation
works] disabled generation of the -dev pkg. Since a libtool archive
file was no longer being picked up by the -dev pkg the build will fail
with a QA issue (if ERROR_QA includes installed-vs-shipped):

ERROR: gnome-themes-standard-3.22.3-r0 do_package: QA Issue:
gnome-themes-standard: Files/directories were installed but not
shipped in any package:
/usr/lib64/gtk-2.0/2.10.0/engines/libadwaita.la

The libtool archive file is mostly useless in modern Linux with a
single shared library file so instead of including this in the -dev
pkg we simply drop it.

Signed-off-by: Mark Asselstine 
---
 meta/recipes-gnome/gnome/gnome-themes-standard_3.22.3.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-gnome/gnome/gnome-themes-standard_3.22.3.bb 
b/meta/recipes-gnome/gnome/gnome-themes-standard_3.22.3.bb
index 3b41328..55ee277 100644
--- a/meta/recipes-gnome/gnome/gnome-themes-standard_3.22.3.bb
+++ b/meta/recipes-gnome/gnome/gnome-themes-standard_3.22.3.bb
@@ -25,6 +25,9 @@ do_install_append() {
 # Only building Adwaita, remove highcontrast files
 rm -rf ${D}${prefix}/share/themes/HighContrast \
${D}${prefix}/share/icons
+
+   # The libtool archive file is unneeded with shared libs on modern Linux
+   rm -rf ${D}${libdir}/gtk-2.0/2.10.0/engines/libadwaita.la
 }
 
 # There could be gnome-theme-highcontrast as well but that requires
-- 
2.7.4

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

Re: [OE-core] [RFC] recipe_links.bbclass: introduction

[Mark Asselstine]

On Friday, August 18, 2017 10:58:30 AM EDT Andre McCurdy wrote:
> On Fri, Aug 18, 2017 at 8:44 AM, Mark Asselstine
> 
>  wrote:
> > This is a new class which can be used (for example via USER_CLASSES in
> > local.conf) to make your build more development friendly. When
> > included this class will create symlinks to the various bb and
> > bbappend files in WORKDIR.
> > 
> > Normally when you are debugging or extending a package's recipe files
> > a developer will employ one of a few indirect techniques to determine
> > where bb and bbappends files associated with a recipe exist. For
> > example they might use bitbake-layers show-recipes or similar, or
> > simply rely on their experience to guide them. Even after working with
> > openembedded for serveral years now I find these techniques tedious
> > and time consuming, and sometimes even hit and miss.
> > 
> > Since the whereabouts of these files are already stored in various
> > files at parse time we can create symlinks to simplify the task of
> > finding these files, making them available in WORKDIR for easy
> > inpsection and in a convenient location if using devshel for instance.
> > 
> > For now this work is completely optional but we could conceivable make
> > this the default behavior if folks find it is convenient and the cost
> > of performing these operations across all builds is minimal enough.
> > 
> > recipe_links can safely be added to USER_CLASSES for existing builds,
> > care has been taken to avoid this action causing anything to be
> > rebuilt. After this has been added you can either 'bitbake  -C
> > unpack' or 'bitbake  -c create_recipe_links' to cause the
> > links to be created in the WORKDIR for the specified recipe.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > 
> >  meta/classes/recipe_links.bbclass | 79
> >  +++ meta/conf/documentation.conf
> >   |  1 +
> >  2 files changed, 80 insertions(+)
> >  create mode 100644 meta/classes/recipe_links.bbclass
> > 
> > diff --git a/meta/classes/recipe_links.bbclass
> > b/meta/classes/recipe_links.bbclass new file mode 100644
> > index 000..ea97605
> > --- /dev/null
> > +++ b/meta/classes/recipe_links.bbclass
> > @@ -0,0 +1,79 @@
> > +# Create symlink in WORKDIR to the various bb and
> > +# bbappend files used to define the package ops
> > +
> > +# Create a symlink given src and dst paths
> > +def create_link(d, src, dst):
> > +if os.path.islink(dst):
> > +try:
> > +os.unlink(dst)
> > +except OSError as err:
> > +bb.error("  Failed to cleanup old link %s: %s"
> > + % (os.path.basename(dst),
> > os.strerror(err.errno))) +return False
> > +
> > +
> > +try:
> > +os.symlink(src, dst)
> > +except OSError as err:
> > +bb.error("  Failed to create file link for %s: %s"
> > + % (src, os.strerror(err.errno)))
> > +return False
> > +
> > +return True
> > +
> > +# Ensure the work is scheduled. We do this as a func
> > +# to avoid sig changes causing things to be rebuilt
> > +# when the class is added/removed after the fact.
> > +do_unpack[postfuncs] += "create_recipe_links "
> > +do_unpack[vardepsexclude] += "create_recipe_links "
> > +python create_recipe_links() {
> > +import re
> > +import glob
> > +
> > +workdir = d.getVar('WORKDIR')
> > +
> > +# Main recipe file
> > +bb.note("Add main recipe file link:")
> > +bb_path = d.getVar('FILE')
> > +bb_filename = os.path.basename(bb_path)
> > +bb_destname = "%s/%s" % (workdir, bb_filename)
> > +bb.note("  Linking %s" % bb_path)
> > +if not create_link(d, bb_path, bb_destname):
> > +return False
> > +
> > +# Cleanup old bbappends links
> > +bb.note("Removing old bbappend links:")
> > +pn = d.getVar('PN')
> > +files = glob.glob('%s/[0-9][0-9]_%s.bbappend' % (workdir,pn))
> > +files += glob.glob('%s/[0-9][0-9]_%s_*.bbappend' % (workdir, pn))
> > +for filename in files:
> > +bb.note("  Removing: %s" % filename)
> > +try:
> > +os.unlink(filename)
> > +except OSError as err:
> > +bb.error("  Failed to cleanup old 

[OE-core] [RFC] recipe_links.bbclass: introduction

[Mark Asselstine]

This is a new class which can be used (for example via USER_CLASSES in
local.conf) to make your build more development friendly. When
included this class will create symlinks to the various bb and
bbappend files in WORKDIR.

Normally when you are debugging or extending a package's recipe files
a developer will employ one of a few indirect techniques to determine
where bb and bbappends files associated with a recipe exist. For
example they might use bitbake-layers show-recipes or similar, or
simply rely on their experience to guide them. Even after working with
openembedded for serveral years now I find these techniques tedious
and time consuming, and sometimes even hit and miss.

Since the whereabouts of these files are already stored in various
files at parse time we can create symlinks to simplify the task of
finding these files, making them available in WORKDIR for easy
inpsection and in a convenient location if using devshel for instance.

For now this work is completely optional but we could conceivable make
this the default behavior if folks find it is convenient and the cost
of performing these operations across all builds is minimal enough.

recipe_links can safely be added to USER_CLASSES for existing builds,
care has been taken to avoid this action causing anything to be
rebuilt. After this has been added you can either 'bitbake  -C
unpack' or 'bitbake  -c create_recipe_links' to cause the
links to be created in the WORKDIR for the specified recipe.

Signed-off-by: Mark Asselstine 
---
 meta/classes/recipe_links.bbclass | 79 +++
 meta/conf/documentation.conf  |  1 +
 2 files changed, 80 insertions(+)
 create mode 100644 meta/classes/recipe_links.bbclass

diff --git a/meta/classes/recipe_links.bbclass 
b/meta/classes/recipe_links.bbclass
new file mode 100644
index 000..ea97605
--- /dev/null
+++ b/meta/classes/recipe_links.bbclass
@@ -0,0 +1,79 @@
+# Create symlink in WORKDIR to the various bb and
+# bbappend files used to define the package ops
+
+# Create a symlink given src and dst paths
+def create_link(d, src, dst):
+if os.path.islink(dst):
+try:
+os.unlink(dst)
+except OSError as err:
+bb.error("  Failed to cleanup old link %s: %s"
+ % (os.path.basename(dst), os.strerror(err.errno)))
+return False
+
+
+try:
+os.symlink(src, dst)
+except OSError as err:
+bb.error("  Failed to create file link for %s: %s"
+ % (src, os.strerror(err.errno)))
+return False
+
+return True
+
+# Ensure the work is scheduled. We do this as a func
+# to avoid sig changes causing things to be rebuilt
+# when the class is added/removed after the fact.
+do_unpack[postfuncs] += "create_recipe_links "
+do_unpack[vardepsexclude] += "create_recipe_links "
+python create_recipe_links() {
+import re
+import glob
+
+workdir = d.getVar('WORKDIR')
+
+# Main recipe file
+bb.note("Add main recipe file link:")
+bb_path = d.getVar('FILE')
+bb_filename = os.path.basename(bb_path)
+bb_destname = "%s/%s" % (workdir, bb_filename)
+bb.note("  Linking %s" % bb_path)
+if not create_link(d, bb_path, bb_destname):
+return False
+
+# Cleanup old bbappends links
+bb.note("Removing old bbappend links:")
+pn = d.getVar('PN')
+files = glob.glob('%s/[0-9][0-9]_%s.bbappend' % (workdir,pn))
+files += glob.glob('%s/[0-9][0-9]_%s_*.bbappend' % (workdir, pn))
+for filename in files:
+bb.note("  Removing: %s" % filename)
+try:
+os.unlink(filename)
+except OSError as err:
+bb.error("  Failed to cleanup old link %s: %s" %
+ (os.path.basename(filename), os.strerror(err.errno)))
+return False
+
+# Add bbappends links
+bb.note("Adding bbappend links:")
+included_files = d.getVar('BBINCLUDED').split()
+bbappend_re = re.compile( r".*/%s(_[^/]*)?\.bbappend$" % re.escape(pn))
+for filename in included_files:
+if bbappend_re.match(filename):
+bb.note("  Linking %s" % filename)
+destname = "00_%s" % (os.path.basename(filename))
+while os.path.exists("%s/%s" % (workdir, destname)):
+ destname = str(int(destname[:2]) + 1).zfill(2) + destname[2:]
+if not create_link(d, filename, "%s/%s" % (workdir, destname)):
+return False
+
+return True
+}
+
+# In addition to the func we want to make things able to be (re)run
+# easily by the user so ensure it is available as a task.
+addtask do_create_recipe_links
+python do_create_recipe_links() {
+bb.build.exec_func("create_recipe_links"

[OE-core] [PATCH v2] python: don't include -tests with modules

[Mark Asselstine]

Although 'test' is listed in the python module list
(https://docs.python.org/3/py-modindex.html) it is meant only to be
used 'internally' by folks developing python itself. Per the
documentation:

  Note The test package is meant for internal use by Python only. It
  is documented for the benefit of the core developers of Python. Any
  use of this package outside of Python’s standard library is
  discouraged as code mentioned here can change or be removed without
  notice between releases of Python.

Per the above it is best not to include this module to discourage
folks who might not head the above warnings. Additionally this module
is one of the largest py modules going, by dropping this unneeded
module from the 'modules' package we can reduce overall image size,
something which is important for many embedded deployments.

The generator scripts as well as the manifests have thus been modified
accordingly, providing a generic mechanism to exclude modules from the
'all modules' package.

Signed-off-by: Mark Asselstine 
---

*** v2 
Updated the generator script missed in the v1 and pointed out
by RP.

 meta/recipes-devtools/python/python-2.7-manifest.inc | 2 +-
 meta/recipes-devtools/python/python-3.5-manifest.inc | 2 +-
 scripts/contrib/python/generate-manifest-2.7.py  | 9 ++---
 scripts/contrib/python/generate-manifest-3.5.py  | 9 ++---
 4 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-devtools/python/python-2.7-manifest.inc 
b/meta/recipes-devtools/python/python-2.7-manifest.inc
index 7ed254b..57d4834 100644
--- a/meta/recipes-devtools/python/python-2.7-manifest.inc
+++ b/meta/recipes-devtools/python/python-2.7-manifest.inc
@@ -281,7 +281,7 @@ RDEPENDS_${PN}-zlib="${PN}-core"
 FILES_${PN}-zlib="${libdir}/python2.7/lib-dynload/zlib.so "
 
 SUMMARY_${PN}-modules="All Python modules"
-RDEPENDS_${PN}-modules="${PN}-2to3 ${PN}-argparse ${PN}-audio ${PN}-bsddb 
${PN}-codecs ${PN}-compile ${PN}-compiler ${PN}-compression ${PN}-contextlib 
${PN}-core ${PN}-crypt ${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db 
${PN}-debugger ${PN}-difflib ${PN}-distutils ${PN}-doctest ${PN}-email 
${PN}-fcntl ${PN}-gdbm ${PN}-hotshot ${PN}-html ${PN}-idle ${PN}-image 
${PN}-importlib ${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox 
${PN}-math ${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient 
${PN}-netserver ${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-plistlib 
${PN}-pprint ${PN}-profile ${PN}-pydoc ${PN}-re ${PN}-readline ${PN}-resource 
${PN}-robotparser ${PN}-shell ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests 
${PN}-stringold ${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-tests 
${PN}-textutils ${PN}-threading ${PN}-tkinter ${PN}-unittest ${PN}-unixadmin 
${PN}-xml ${PN}-xmlrpc ${PN}-zlib  "
+RDEPENDS_${PN}-modules="${PN}-2to3 ${PN}-argparse ${PN}-audio ${PN}-bsddb 
${PN}-codecs ${PN}-compile ${PN}-compiler ${PN}-compression ${PN}-contextlib 
${PN}-core ${PN}-crypt ${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db 
${PN}-debugger ${PN}-difflib ${PN}-distutils ${PN}-doctest ${PN}-email 
${PN}-fcntl ${PN}-gdbm ${PN}-hotshot ${PN}-html ${PN}-idle ${PN}-image 
${PN}-importlib ${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox 
${PN}-math ${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient 
${PN}-netserver ${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-plistlib 
${PN}-pprint ${PN}-profile ${PN}-pydoc ${PN}-re ${PN}-readline ${PN}-resource 
${PN}-robotparser ${PN}-shell ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests 
${PN}-stringold ${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-textutils 
${PN}-threading ${PN}-tkinter ${PN}-unittest ${PN}-unixadmin ${PN}-xml 
${PN}-xmlrpc ${PN}-zlib  "
 ALLOW_EMPTY_${PN}-modules = "1"
 
 
diff --git a/meta/recipes-devtools/python/python-3.5-manifest.inc 
b/meta/recipes-devtools/python/python-3.5-manifest.inc
index 65db7e8..0260e87 100644
--- a/meta/recipes-devtools/python/python-3.5-manifest.inc
+++ b/meta/recipes-devtools/python/python-3.5-manifest.inc
@@ -277,7 +277,7 @@ RDEPENDS_${PN}-xmlrpc="${PN}-core ${PN}-xml ${PN}-netserver 
${PN}-lang ${PN}-pyd
 FILES_${PN}-xmlrpc="${libdir}/python3.5/xmlrpclib.* 
${libdir}/python3.5/__pycache__/xmlrpclib.* 
${libdir}/python3.5/SimpleXMLRPCServer.* 
${libdir}/python3.5/__pycache__/SimpleXMLRPCServer.* 
${libdir}/python3.5/DocXMLRPCServer.* 
${libdir}/python3.5/__pycache__/DocXMLRPCServer.* ${libdir}/python3.5/xmlrpc 
${libdir}/python3.5/xmlrpc/__pycache__ "
 
 SUMMARY_${PN}-modules="All Python modules"
-RDEPENDS_${PN}-modules="${PN}-2to3 ${PN}-argparse ${PN}-asyncio ${PN}-audio 
${PN}-codecs ${PN}-compile ${PN}-compression ${PN}-core ${PN}-crypt 
${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-difflib 
${PN}-distutils ${PN}-doctest ${PN}-email ${PN}-enum ${PN}-fcntl ${PN}-gdbm 
${PN}-html ${PN}-i

Re: [OE-core] [PATCH] python: don't include -tests with modules

[Mark Asselstine]

On Thursday, July 27, 2017 10:39:07 PM EDT Richard Purdie wrote:
> On Mon, 2017-07-24 at 12:10 -0400, Mark Asselstine wrote:
> > Although 'test' is listed in the python module list
> > (https://docs.python.org/3/py-modindex.html) it is meant only to be
> > used 'internally' by folks developing python itself. Per the
> > documentation:
> > 
> >   Note The test package is meant for internal use by Python only. It
> >   is documented for the benefit of the core developers of Python. Any
> >   use of this package outside of Python’s standard library is
> >   discouraged as code mentioned here can change or be removed without
> >   notice between releases of Python.
> > 
> > Per the above it is best not to include this module to discourage
> > folks who might not head the above warnings. Additionally this module
> > is one of the largest py modules going, by dropping this unneeded
> > module from the 'modules' package we can reduce overall image size,
> > something which is important for many embedded deployments.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> >  meta/recipes-devtools/python/python-2.7-manifest.inc | 2 +-
> >  meta/recipes-devtools/python/python-3.5-manifest.inc | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> As per the comments at the top of these files, the generator scripts
> need to be fixed too?

I am just about to head into the wild with no internet access. I will have a 
closer look at this on Monday. I have to admit I did not see the comment.

MarkA

> 
> Cheers,
> 
> Richard


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

[OE-core] [PATCH] python: don't include -tests with modules

[Mark Asselstine]

Although 'test' is listed in the python module list
(https://docs.python.org/3/py-modindex.html) it is meant only to be
used 'internally' by folks developing python itself. Per the
documentation:

  Note The test package is meant for internal use by Python only. It
  is documented for the benefit of the core developers of Python. Any
  use of this package outside of Python’s standard library is
  discouraged as code mentioned here can change or be removed without
  notice between releases of Python.

Per the above it is best not to include this module to discourage
folks who might not head the above warnings. Additionally this module
is one of the largest py modules going, by dropping this unneeded
module from the 'modules' package we can reduce overall image size,
something which is important for many embedded deployments.

Signed-off-by: Mark Asselstine 
---
 meta/recipes-devtools/python/python-2.7-manifest.inc | 2 +-
 meta/recipes-devtools/python/python-3.5-manifest.inc | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/python/python-2.7-manifest.inc 
b/meta/recipes-devtools/python/python-2.7-manifest.inc
index 7ed254b..57d4834 100644
--- a/meta/recipes-devtools/python/python-2.7-manifest.inc
+++ b/meta/recipes-devtools/python/python-2.7-manifest.inc
@@ -281,7 +281,7 @@ RDEPENDS_${PN}-zlib="${PN}-core"
 FILES_${PN}-zlib="${libdir}/python2.7/lib-dynload/zlib.so "
 
 SUMMARY_${PN}-modules="All Python modules"
-RDEPENDS_${PN}-modules="${PN}-2to3 ${PN}-argparse ${PN}-audio ${PN}-bsddb 
${PN}-codecs ${PN}-compile ${PN}-compiler ${PN}-compression ${PN}-contextlib 
${PN}-core ${PN}-crypt ${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db 
${PN}-debugger ${PN}-difflib ${PN}-distutils ${PN}-doctest ${PN}-email 
${PN}-fcntl ${PN}-gdbm ${PN}-hotshot ${PN}-html ${PN}-idle ${PN}-image 
${PN}-importlib ${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox 
${PN}-math ${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient 
${PN}-netserver ${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-plistlib 
${PN}-pprint ${PN}-profile ${PN}-pydoc ${PN}-re ${PN}-readline ${PN}-resource 
${PN}-robotparser ${PN}-shell ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests 
${PN}-stringold ${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-tests 
${PN}-textutils ${PN}-threading ${PN}-tkinter ${PN}-unittest ${PN}-unixadmin 
${PN}-xml ${PN}-xmlrpc ${PN}-zlib  "
+RDEPENDS_${PN}-modules="${PN}-2to3 ${PN}-argparse ${PN}-audio ${PN}-bsddb 
${PN}-codecs ${PN}-compile ${PN}-compiler ${PN}-compression ${PN}-contextlib 
${PN}-core ${PN}-crypt ${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db 
${PN}-debugger ${PN}-difflib ${PN}-distutils ${PN}-doctest ${PN}-email 
${PN}-fcntl ${PN}-gdbm ${PN}-hotshot ${PN}-html ${PN}-idle ${PN}-image 
${PN}-importlib ${PN}-io ${PN}-json ${PN}-lang ${PN}-logging ${PN}-mailbox 
${PN}-math ${PN}-mime ${PN}-mmap ${PN}-multiprocessing ${PN}-netclient 
${PN}-netserver ${PN}-numbers ${PN}-pickle ${PN}-pkgutil ${PN}-plistlib 
${PN}-pprint ${PN}-profile ${PN}-pydoc ${PN}-re ${PN}-readline ${PN}-resource 
${PN}-robotparser ${PN}-shell ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests 
${PN}-stringold ${PN}-subprocess ${PN}-syslog ${PN}-terminal ${PN}-textutils 
${PN}-threading ${PN}-tkinter ${PN}-unittest ${PN}-unixadmin ${PN}-xml 
${PN}-xmlrpc ${PN}-zlib  "
 ALLOW_EMPTY_${PN}-modules = "1"
 
 
diff --git a/meta/recipes-devtools/python/python-3.5-manifest.inc 
b/meta/recipes-devtools/python/python-3.5-manifest.inc
index 65db7e8..0260e87 100644
--- a/meta/recipes-devtools/python/python-3.5-manifest.inc
+++ b/meta/recipes-devtools/python/python-3.5-manifest.inc
@@ -277,7 +277,7 @@ RDEPENDS_${PN}-xmlrpc="${PN}-core ${PN}-xml ${PN}-netserver 
${PN}-lang ${PN}-pyd
 FILES_${PN}-xmlrpc="${libdir}/python3.5/xmlrpclib.* 
${libdir}/python3.5/__pycache__/xmlrpclib.* 
${libdir}/python3.5/SimpleXMLRPCServer.* 
${libdir}/python3.5/__pycache__/SimpleXMLRPCServer.* 
${libdir}/python3.5/DocXMLRPCServer.* 
${libdir}/python3.5/__pycache__/DocXMLRPCServer.* ${libdir}/python3.5/xmlrpc 
${libdir}/python3.5/xmlrpc/__pycache__ "
 
 SUMMARY_${PN}-modules="All Python modules"
-RDEPENDS_${PN}-modules="${PN}-2to3 ${PN}-argparse ${PN}-asyncio ${PN}-audio 
${PN}-codecs ${PN}-compile ${PN}-compression ${PN}-core ${PN}-crypt 
${PN}-ctypes ${PN}-curses ${PN}-datetime ${PN}-db ${PN}-debugger ${PN}-difflib 
${PN}-distutils ${PN}-doctest ${PN}-email ${PN}-enum ${PN}-fcntl ${PN}-gdbm 
${PN}-html ${PN}-idle ${PN}-image ${PN}-importlib ${PN}-io ${PN}-json 
${PN}-lang ${PN}-logging ${PN}-mailbox ${PN}-math ${PN}-mime ${PN}-mmap 
${PN}-multiprocessing ${PN}-netclient ${PN}-netserver ${PN}-numbers 
${PN}-pickle ${PN}-pkgutil ${PN}-pprint ${PN}-profile ${PN}-pydoc ${PN}-re 
${PN}-readline ${PN}-reprlib ${PN}-resource ${PN}-selectors ${PN}-shell 
${PN}-signal ${PN}-smtpd ${PN}-sqlite3 ${PN}-sqlite3-tests ${PN}

[OE-core] [PATCH v2] python3: fix weakref spewing exceptions during interp finalization

[Mark Asselstine]

When py3 applications are exiting we often see errors similar to the
following:

Exception ignored in: .remove at 
0x7fcb56b09400>
Traceback (most recent call last):
  File "/usr/lib64/python3.5/weakref.py", line 117, in remove
  TypeError: 'NoneType' object is not callable

After a quick search this was found to be a well reported issue
upstream and had an appropriate fix which is backported here.

Signed-off-by: Mark Asselstine 
---
v2: Add patch author SOB to embedded patch after
failing Patchwork's patchtest.

 ...eakref-spewing-exceptions-during-interp-f.patch | 56 ++
 meta/recipes-devtools/python/python3_3.5.3.bb  |  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3/Fix-29519-weakref-spewing-exceptions-during-interp-f.patch

diff --git 
a/meta/recipes-devtools/python/python3/Fix-29519-weakref-spewing-exceptions-during-interp-f.patch
 
b/meta/recipes-devtools/python/python3/Fix-29519-weakref-spewing-exceptions-during-interp-f.patch
new file mode 100644
index 000..7217c6e
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3/Fix-29519-weakref-spewing-exceptions-during-interp-f.patch
@@ -0,0 +1,56 @@
+From 62dcf34987b680e95873eb947b3f4d802199c667 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?=C5=81ukasz=20Langa?= 
+Date: Fri, 10 Feb 2017 00:14:55 -0800
+Subject: [PATCH] Fix #29519: weakref spewing exceptions during interp
+ finalization
+
+commit 9cd7e17640a49635d1c1f8c2989578a8fc2c1de6
+from https://github.com/python/cpython
+
+Upstream-Status: Backport
+
+Signed-off-by: Lukasz Langa 
+---
+ Lib/weakref.py | 4 ++--
+ Misc/NEWS  | 3 +++
+ 2 files changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/Lib/weakref.py b/Lib/weakref.py
+index aaebd0c..787e33a 100644
+--- a/Lib/weakref.py
 b/Lib/weakref.py
+@@ -106,7 +106,7 @@ class WeakValueDictionary(collections.MutableMapping):
+ self, *args = args
+ if len(args) > 1:
+ raise TypeError('expected at most 1 arguments, got %d' % 
len(args))
+-def remove(wr, selfref=ref(self)):
++def remove(wr, selfref=ref(self), 
_atomic_removal=_remove_dead_weakref):
+ self = selfref()
+ if self is not None:
+ if self._iterating:
+@@ -114,7 +114,7 @@ class WeakValueDictionary(collections.MutableMapping):
+ else:
+ # Atomic removal is necessary since this function
+ # can be called asynchronously by the GC
+-_remove_dead_weakref(d, wr.key)
++_atomic_removal(d, wr.key)
+ self._remove = remove
+ # A list of keys to be removed
+ self._pending_removals = []
+diff --git a/Misc/NEWS b/Misc/NEWS
+index 41cfdba..6d89f52 100644
+--- a/Misc/NEWS
 b/Misc/NEWS
+@@ -5719,6 +5719,9 @@ Core and Builtins
+ Library
+ ---
+ 
++- Issue #29519: Fix weakref spewing exceptions during interpreter shutdown
++  when used with a rare combination of multiprocessing and custom codecs.
++
+ - Issue #20154: Deadlock in asyncio.StreamReader.readexactly().
+ 
+ - Issue #16113: Remove sha3 module again.
+-- 
+2.7.4
+
diff --git a/meta/recipes-devtools/python/python3_3.5.3.bb 
b/meta/recipes-devtools/python/python3_3.5.3.bb
index d7c29f2..7419c71 100644
--- a/meta/recipes-devtools/python/python3_3.5.3.bb
+++ b/meta/recipes-devtools/python/python3_3.5.3.bb
@@ -37,6 +37,7 @@ SRC_URI += "\
 file://configure.ac-fix-LIBPL.patch \
 file://upstream-random-fixes.patch \
 
file://0001-Issue-21272-Use-_sysconfigdata.py-to-initialize-dist.patch \
+file://Fix-29519-weakref-spewing-exceptions-during-interp-f.patch \
"
 SRC_URI[md5sum] = "57d1f8bfbabf4f2500273fb0706e6f21"
 SRC_URI[sha256sum] = 
"eefe2ad6575855423ab630f5b51a8ef6e5556f774584c06beab4926f930ddbb0"
-- 
2.7.4

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

[OE-core] [PATCH] python3: fix weakref spewing exceptions during interp finalization

[Mark Asselstine]

When py3 applications are exiting we often see errors similar to the
following:

Exception ignored in: .remove at 
0x7fcb56b09400>
Traceback (most recent call last):
  File "/usr/lib64/python3.5/weakref.py", line 117, in remove
  TypeError: 'NoneType' object is not callable

After a quick search this was found to be a well reported issue
upstream and had an appropriate fix which is backported here.

Signed-off-by: Mark Asselstine 
---
 ...eakref-spewing-exceptions-during-interp-f.patch | 55 ++
 meta/recipes-devtools/python/python3_3.5.3.bb  |  1 +
 2 files changed, 56 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3/Fix-29519-weakref-spewing-exceptions-during-interp-f.patch

diff --git 
a/meta/recipes-devtools/python/python3/Fix-29519-weakref-spewing-exceptions-during-interp-f.patch
 
b/meta/recipes-devtools/python/python3/Fix-29519-weakref-spewing-exceptions-during-interp-f.patch
new file mode 100644
index 000..52ecb8c
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3/Fix-29519-weakref-spewing-exceptions-during-interp-f.patch
@@ -0,0 +1,55 @@
+From 62dcf34987b680e95873eb947b3f4d802199c667 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?=C5=81ukasz=20Langa?= 
+Date: Fri, 10 Feb 2017 00:14:55 -0800
+Subject: [PATCH] Fix #29519: weakref spewing exceptions during interp
+ finalization
+
+commit 9cd7e17640a49635d1c1f8c2989578a8fc2c1de6
+from https://github.com/python/cpython
+
+Upstream-Status: Backport
+
+---
+ Lib/weakref.py | 4 ++--
+ Misc/NEWS  | 3 +++
+ 2 files changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/Lib/weakref.py b/Lib/weakref.py
+index aaebd0c..787e33a 100644
+--- a/Lib/weakref.py
 b/Lib/weakref.py
+@@ -106,7 +106,7 @@ class WeakValueDictionary(collections.MutableMapping):
+ self, *args = args
+ if len(args) > 1:
+ raise TypeError('expected at most 1 arguments, got %d' % 
len(args))
+-def remove(wr, selfref=ref(self)):
++def remove(wr, selfref=ref(self), 
_atomic_removal=_remove_dead_weakref):
+ self = selfref()
+ if self is not None:
+ if self._iterating:
+@@ -114,7 +114,7 @@ class WeakValueDictionary(collections.MutableMapping):
+ else:
+ # Atomic removal is necessary since this function
+ # can be called asynchronously by the GC
+-_remove_dead_weakref(d, wr.key)
++_atomic_removal(d, wr.key)
+ self._remove = remove
+ # A list of keys to be removed
+ self._pending_removals = []
+diff --git a/Misc/NEWS b/Misc/NEWS
+index 41cfdba..6d89f52 100644
+--- a/Misc/NEWS
 b/Misc/NEWS
+@@ -5719,6 +5719,9 @@ Core and Builtins
+ Library
+ ---
+ 
++- Issue #29519: Fix weakref spewing exceptions during interpreter shutdown
++  when used with a rare combination of multiprocessing and custom codecs.
++
+ - Issue #20154: Deadlock in asyncio.StreamReader.readexactly().
+ 
+ - Issue #16113: Remove sha3 module again.
+-- 
+2.7.4
+
diff --git a/meta/recipes-devtools/python/python3_3.5.3.bb 
b/meta/recipes-devtools/python/python3_3.5.3.bb
index d7c29f2..7419c71 100644
--- a/meta/recipes-devtools/python/python3_3.5.3.bb
+++ b/meta/recipes-devtools/python/python3_3.5.3.bb
@@ -37,6 +37,7 @@ SRC_URI += "\
 file://configure.ac-fix-LIBPL.patch \
 file://upstream-random-fixes.patch \
 
file://0001-Issue-21272-Use-_sysconfigdata.py-to-initialize-dist.patch \
+file://Fix-29519-weakref-spewing-exceptions-during-interp-f.patch \
"
 SRC_URI[md5sum] = "57d1f8bfbabf4f2500273fb0706e6f21"
 SRC_URI[sha256sum] = 
"eefe2ad6575855423ab630f5b51a8ef6e5556f774584c06beab4926f930ddbb0"
-- 
2.7.4

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

[OE-core] [PATCH v2] attr: Fix build failure when image includes man-pages pkg

[Mark Asselstine]

If you attempt to build an image with both attr(-doc) and man-pages
packages your rootfs might fail to assemble. The error will be
something like:

Error: Transaction check error:
  file /usr/share/man/man2/fgetxattr.2 from install of \
attr-doc-2.4.47-r0.core2_64 conflicts with file from \
package man-pages-4.11-r0.core2_64

(the error is usually only seen on builders which don't have manpages
installed, if you have /usr/share/man/man1/man.1.gz your build will
complete but you will have duplicate manpages, just one zipped and one
not)

Backporting changes from upstream attr removes the conflicted files in
favour of those in the man-pages package.

Signed-off-by: Mark Asselstine 
---

v2: Fixed case in Upstream-Status

 meta/recipes-support/attr/attr_2.4.47.bb   |   2 +
 ...ve-the-attr.5-man-page-moved-to-man-pages.patch | 240 
 .../files/Remove-the-section-2-man-pages.patch | 666 +
 3 files changed, 908 insertions(+)
 create mode 100644 
meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-pages.patch
 create mode 100644 
meta/recipes-support/attr/files/Remove-the-section-2-man-pages.patch

diff --git a/meta/recipes-support/attr/attr_2.4.47.bb 
b/meta/recipes-support/attr/attr_2.4.47.bb
index 556c8e4..2dada7a 100644
--- a/meta/recipes-support/attr/attr_2.4.47.bb
+++ b/meta/recipes-support/attr/attr_2.4.47.bb
@@ -4,6 +4,8 @@ require attr.inc
 # future releases of attr, remove this when updating the recipe.
 SRC_URI += "file://attr-Missing-configure.ac.patch \
 file://dont-use-decl-macros.patch \
+file://Remove-the-section-2-man-pages.patch \
+file://Remove-the-attr.5-man-page-moved-to-man-pages.patch \
"
 
 SRC_URI[md5sum] = "84f58dec00b60f2dc8fd1c9709291cc7"
diff --git 
a/meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-pages.patch
 
b/meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-pages.patch
new file mode 100644
index 000..d5ab83d
--- /dev/null
+++ 
b/meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-pages.patch
@@ -0,0 +1,240 @@
+From 6047c8522b91235ad1e835f44f5e36472d9d49b2 Mon Sep 17 00:00:00 2001
+From: Andreas Gruenbacher 
+Date: Wed, 22 Apr 2015 11:46:59 +0200
+Subject: [PATCH 2/2] Remove the attr.5 man page (moved to man-pages)
+
+Commit dce9b4448c7f2b22bd206cd068fb05cb2f3255b9 from
+https://git.savannah.nongnu.org/git/attr.git
+
+The attr.5 page is part of the extended attribute system call documentation,
+which has been moved into the man-pages package. Move the attr.5 page there
+as well.
+
+Upstream-Status: Backport
+
+[MA: updated to apply directly to v2.4.47]
+Signed-off-by: Mark Asselstine 
+---
+ man/Makefile  |   2 +-
+ man/man5/Makefile |  35 -
+ man/man5/attr.5   | 153 --
+ 3 files changed, 1 insertion(+), 189 deletions(-)
+ delete mode 100644 man/man5/Makefile
+ delete mode 100644 man/man5/attr.5
+
+diff --git a/man/Makefile b/man/Makefile
+index 755daed..9301f09 100644
+--- a/man/Makefile
 b/man/Makefile
+@@ -19,7 +19,7 @@
+ TOPDIR = ..
+ include $(TOPDIR)/include/builddefs
+ 
+-SUBDIRS = man1 man3 man5
++SUBDIRS = man1 man3
+ 
+ default : $(SUBDIRS)
+ 
+diff --git a/man/man5/Makefile b/man/man5/Makefile
+deleted file mode 100644
+index 6b70d3d..000
+--- a/man/man5/Makefile
 /dev/null
+@@ -1,35 +0,0 @@
+-#
+-# Copyright (c) 2000, 2002 Silicon Graphics, Inc.  All Rights Reserved.
+-# Copyright (C) 2009  Andreas Gruenbacher 
+-#
+-# This program is free software: you can redistribute it and/or modify it
+-# under the terms of the GNU General Public License as published by
+-# the Free Software Foundation, either version 2 of the License, or
+-# (at your option) any later version.
+-#
+-# This program is distributed in the hope that it will be useful,
+-# but WITHOUT ANY WARRANTY; without even the implied warranty of
+-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+-# GNU General Public License for more details.
+-#
+-# You should have received a copy of the GNU General Public License
+-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+-#
+-
+-TOPDIR = ../..
+-include $(TOPDIR)/include/builddefs
+-
+-MAN_SECTION   = 5
+-
+-MAN_PAGES = $(shell echo *.$(MAN_SECTION))
+-MAN_DEST  = $(PKG_MAN_DIR)/man$(MAN_SECTION)
+-LSRCFILES = $(MAN_PAGES)
+-
+-default : $(MAN_PAGES)
+-
+-include $(BUILDRULES)
+-
+-install : default
+-  $(INSTALL) -m 755 -d $(MAN_DEST)
+-  $(INSTALL_MAN)
+-install-dev install-lib:
+diff --git a/man/man5/attr.5 b/man/man5/attr.5
+deleted file mode 100644
+index a02757d..000
+--- a/man/man5/attr.5
 /dev/null
+@@ -1,153 +0,0 @@
+-.\" Extended attributes manual page
+-.\"
+-.\" Copyright (C) 2000, 2002, 2007  Andreas Gruenbacher 
+-.\" Copyright (C) 2001, 2002, 2004, 2007 Silicon Graphics, 

Re: [OE-core] [PATCH] attr: Fix build failure when image includes man-pages pkg

[Mark Asselstine]

On Tuesday, June 13, 2017 9:13:28 PM EDT Burton, Ross wrote:
> On 13 June 2017 at 19:46, Mark Asselstine 
> 
> wrote:
> > Yet the 'Upstream-status' is marked in the same way for both patches. So I
> > am
> > ingnoring this unless someone is able to see the issue which I can not.
> 
> The test is picky:
> 
> +Upstream-status: Backport
> 
> The correct string (as machines are stupid) is Upstream-Status.

I notice the case on the wiki pages now. I will send along a v2.

Mark

> 
> Ross


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

Re: [OE-core] [PATCH] attr: Fix build failure when image includes man-pages pkg

[Mark Asselstine]

On Tuesday, June 13, 2017 2:08:11 PM EDT Mark Asselstine wrote:
> If you attempt to build an image with both attr(-doc) and man-pages
> packages your rootfs might fail to assemble. The error will be
> something like:
> 
> Error: Transaction check error:
>   file /usr/share/man/man2/fgetxattr.2 from install of \
> attr-doc-2.4.47-r0.core2_64 conflicts with file from \
> package man-pages-4.11-r0.core2_64
> 
> (the error is usually only seen on builders which don't have manpages
> installed, if you have /usr/share/man/man1/man.1.gz your build will
> complete but you will have duplicate manpages, just one zipped and one
> not)
> 
> Backporting changes from upstream attr removes the conflicted files in
> favour of those in the man-pages package.
> 
> Signed-off-by: Mark Asselstine 
> ---

The patchwork bot mailed me to complain that
---
 Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence] 
  Suggested fixAdd Upstream-Status:  to the header of meta/
recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-pages.patch 
(possible values: Pending, Submitted, Accepted, Backport, Denied, 
Inappropriate)
---
Yet the 'Upstream-status' is marked in the same way for both patches. So I am 
ingnoring this unless someone is able to see the issue which I can not.

Mark

>  meta/recipes-support/attr/attr_2.4.47.bb   |   2 +
>  ...ve-the-attr.5-man-page-moved-to-man-pages.patch | 240 
>  .../files/Remove-the-section-2-man-pages.patch | 666
> + 3 files changed, 908 insertions(+)
>  create mode 100644
> meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-pag
> es.patch create mode 100644
> meta/recipes-support/attr/files/Remove-the-section-2-man-pages.patch
> 
> diff --git a/meta/recipes-support/attr/attr_2.4.47.bb
> b/meta/recipes-support/attr/attr_2.4.47.bb index 556c8e4..2dada7a 100644
> --- a/meta/recipes-support/attr/attr_2.4.47.bb
> +++ b/meta/recipes-support/attr/attr_2.4.47.bb
> @@ -4,6 +4,8 @@ require attr.inc
>  # future releases of attr, remove this when updating the recipe.
>  SRC_URI += "file://attr-Missing-configure.ac.patch \
>  file://dont-use-decl-macros.patch \
> +file://Remove-the-section-2-man-pages.patch \
> +file://Remove-the-attr.5-man-page-moved-to-man-pages.patch \
> "
> 
>  SRC_URI[md5sum] = "84f58dec00b60f2dc8fd1c9709291cc7"
> diff --git
> a/meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-p
> ages.patch
> b/meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-p
> ages.patch new file mode 100644
> index 000..7fcb310
> --- /dev/null
> +++
> b/meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-p
> ages.patch @@ -0,0 +1,240 @@
> +From 6047c8522b91235ad1e835f44f5e36472d9d49b2 Mon Sep 17 00:00:00 2001
> +From: Andreas Gruenbacher 
> +Date: Wed, 22 Apr 2015 11:46:59 +0200
> +Subject: [PATCH 2/2] Remove the attr.5 man page (moved to man-pages)
> +
> +Commit dce9b4448c7f2b22bd206cd068fb05cb2f3255b9 from
> +https://git.savannah.nongnu.org/git/attr.git
> +
> +The attr.5 page is part of the extended attribute system call
> documentation, +which has been moved into the man-pages package. Move the
> attr.5 page there +as well.
> +
> +Upstream-status: Backport
> +
> +[MA: updated to apply directly to v2.4.47]
> +Signed-off-by: Mark Asselstine 
> +---
> + man/Makefile  |   2 +-
> + man/man5/Makefile |  35 -
> + man/man5/attr.5   | 153
> -- + 3 files changed, 1
> insertion(+), 189 deletions(-)
> + delete mode 100644 man/man5/Makefile
> + delete mode 100644 man/man5/attr.5
> +
> +diff --git a/man/Makefile b/man/Makefile
> +index 755daed..9301f09 100644
> +--- a/man/Makefile
>  b/man/Makefile
> +@@ -19,7 +19,7 @@
> + TOPDIR = ..
> + include $(TOPDIR)/include/builddefs
> +
> +-SUBDIRS = man1 man3 man5
> ++SUBDIRS = man1 man3
> +
> + default : $(SUBDIRS)
> +
> +diff --git a/man/man5/Makefile b/man/man5/Makefile
> +deleted file mode 100644
> +index 6b70d3d..000
> +--- a/man/man5/Makefile
>  /dev/null
> +@@ -1,35 +0,0 @@
> +-#
> +-# Copyright (c) 2000, 2002 Silicon Graphics, Inc.  All Rights Reserved.
> +-# Copyright (C) 2009  Andreas Gruenbacher 
> +-#
> +-# This program is free software: you can redistribute it and/or modify it
> +-# under the terms of the GNU General Public License as published by
> +-# the Free Software Foundation, either version 2 of the License, or
> +-# (at your option) any later version.
> +-#
> +-# This program is distrib

[OE-core] [PATCH] attr: Fix build failure when image includes man-pages pkg

[Mark Asselstine]

If you attempt to build an image with both attr(-doc) and man-pages
packages your rootfs might fail to assemble. The error will be
something like:

Error: Transaction check error:
  file /usr/share/man/man2/fgetxattr.2 from install of \
attr-doc-2.4.47-r0.core2_64 conflicts with file from \
package man-pages-4.11-r0.core2_64

(the error is usually only seen on builders which don't have manpages
installed, if you have /usr/share/man/man1/man.1.gz your build will
complete but you will have duplicate manpages, just one zipped and one
not)

Backporting changes from upstream attr removes the conflicted files in
favour of those in the man-pages package.

Signed-off-by: Mark Asselstine 
---
 meta/recipes-support/attr/attr_2.4.47.bb   |   2 +
 ...ve-the-attr.5-man-page-moved-to-man-pages.patch | 240 
 .../files/Remove-the-section-2-man-pages.patch | 666 +
 3 files changed, 908 insertions(+)
 create mode 100644 
meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-pages.patch
 create mode 100644 
meta/recipes-support/attr/files/Remove-the-section-2-man-pages.patch

diff --git a/meta/recipes-support/attr/attr_2.4.47.bb 
b/meta/recipes-support/attr/attr_2.4.47.bb
index 556c8e4..2dada7a 100644
--- a/meta/recipes-support/attr/attr_2.4.47.bb
+++ b/meta/recipes-support/attr/attr_2.4.47.bb
@@ -4,6 +4,8 @@ require attr.inc
 # future releases of attr, remove this when updating the recipe.
 SRC_URI += "file://attr-Missing-configure.ac.patch \
 file://dont-use-decl-macros.patch \
+file://Remove-the-section-2-man-pages.patch \
+file://Remove-the-attr.5-man-page-moved-to-man-pages.patch \
"
 
 SRC_URI[md5sum] = "84f58dec00b60f2dc8fd1c9709291cc7"
diff --git 
a/meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-pages.patch
 
b/meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-pages.patch
new file mode 100644
index 000..7fcb310
--- /dev/null
+++ 
b/meta/recipes-support/attr/files/Remove-the-attr.5-man-page-moved-to-man-pages.patch
@@ -0,0 +1,240 @@
+From 6047c8522b91235ad1e835f44f5e36472d9d49b2 Mon Sep 17 00:00:00 2001
+From: Andreas Gruenbacher 
+Date: Wed, 22 Apr 2015 11:46:59 +0200
+Subject: [PATCH 2/2] Remove the attr.5 man page (moved to man-pages)
+
+Commit dce9b4448c7f2b22bd206cd068fb05cb2f3255b9 from
+https://git.savannah.nongnu.org/git/attr.git
+
+The attr.5 page is part of the extended attribute system call documentation,
+which has been moved into the man-pages package. Move the attr.5 page there
+as well.
+
+Upstream-status: Backport
+
+[MA: updated to apply directly to v2.4.47]
+Signed-off-by: Mark Asselstine 
+---
+ man/Makefile  |   2 +-
+ man/man5/Makefile |  35 -
+ man/man5/attr.5   | 153 --
+ 3 files changed, 1 insertion(+), 189 deletions(-)
+ delete mode 100644 man/man5/Makefile
+ delete mode 100644 man/man5/attr.5
+
+diff --git a/man/Makefile b/man/Makefile
+index 755daed..9301f09 100644
+--- a/man/Makefile
 b/man/Makefile
+@@ -19,7 +19,7 @@
+ TOPDIR = ..
+ include $(TOPDIR)/include/builddefs
+ 
+-SUBDIRS = man1 man3 man5
++SUBDIRS = man1 man3
+ 
+ default : $(SUBDIRS)
+ 
+diff --git a/man/man5/Makefile b/man/man5/Makefile
+deleted file mode 100644
+index 6b70d3d..000
+--- a/man/man5/Makefile
 /dev/null
+@@ -1,35 +0,0 @@
+-#
+-# Copyright (c) 2000, 2002 Silicon Graphics, Inc.  All Rights Reserved.
+-# Copyright (C) 2009  Andreas Gruenbacher 
+-#
+-# This program is free software: you can redistribute it and/or modify it
+-# under the terms of the GNU General Public License as published by
+-# the Free Software Foundation, either version 2 of the License, or
+-# (at your option) any later version.
+-#
+-# This program is distributed in the hope that it will be useful,
+-# but WITHOUT ANY WARRANTY; without even the implied warranty of
+-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+-# GNU General Public License for more details.
+-#
+-# You should have received a copy of the GNU General Public License
+-# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+-#
+-
+-TOPDIR = ../..
+-include $(TOPDIR)/include/builddefs
+-
+-MAN_SECTION   = 5
+-
+-MAN_PAGES = $(shell echo *.$(MAN_SECTION))
+-MAN_DEST  = $(PKG_MAN_DIR)/man$(MAN_SECTION)
+-LSRCFILES = $(MAN_PAGES)
+-
+-default : $(MAN_PAGES)
+-
+-include $(BUILDRULES)
+-
+-install : default
+-  $(INSTALL) -m 755 -d $(MAN_DEST)
+-  $(INSTALL_MAN)
+-install-dev install-lib:
+diff --git a/man/man5/attr.5 b/man/man5/attr.5
+deleted file mode 100644
+index a02757d..000
+--- a/man/man5/attr.5
 /dev/null
+@@ -1,153 +0,0 @@
+-.\" Extended attributes manual page
+-.\"
+-.\" Copyright (C) 2000, 2002, 2007  Andreas Gruenbacher 
+-.\" Copyright (C) 2001, 2002, 2004, 2007 Silicon Graphics, Inc.
+-.\" All rights r

Re: [OE-core] [meta-oe][resend][PATCH] sysstat: fixup pkg_postinst to allow SYSTEMD_AUTO_ENABLE to work

[Mark Asselstine]

On Tuesday, May 9, 2017 4:51:37 PM EDT Mark Asselstine wrote:
> The logic added to the pkg_postinst in commit 6bf82c26f953 has the
> side effect of rendering SYSTEMD_AUTO_ENABLE ineffective. The systemd
> service will not be configured as 'enabled' either offline(do_rootfs)
> or during first boot. Since the volatiles, as used, in the
> pkg_postinst are unused with systemd we can simply skip the
> pkg_postinst when not using sysvinit.
> 
> Signed-off-by: Mark Asselstine 
> ---

Is there a reason this change is again sitting without any comments or being 
merged. The recipe as-is is broken in a way that might frustrate people and I 
am attempting to aliviate this frustration with this change.

Mark

>  meta/recipes-extended/sysstat/sysstat.inc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-extended/sysstat/sysstat.inc
> b/meta/recipes-extended/sysstat/sysstat.inc index bb5629d..fce2804 100644
> --- a/meta/recipes-extended/sysstat/sysstat.inc
> +++ b/meta/recipes-extended/sysstat/sysstat.inc
> @@ -42,7 +42,9 @@ do_install() {
>   sed -i -e 's#@LIBDIR@#${libdir}#g'
> ${D}${systemd_unitdir}/system/sysstat.service }
> 
> -pkg_postinst_${PN} () {
> +OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit',
> ':sysvinit', '', d)}" +
> +pkg_postinst_${PN}_sysvinit () {
>  if [ -n "$D" ]; then
>  exit 0
>  fi




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

[OE-core] [meta-oe][resend][PATCH] sysstat: fixup pkg_postinst to allow SYSTEMD_AUTO_ENABLE to work

[Mark Asselstine]

The logic added to the pkg_postinst in commit 6bf82c26f953 has the
side effect of rendering SYSTEMD_AUTO_ENABLE ineffective. The systemd
service will not be configured as 'enabled' either offline(do_rootfs)
or during first boot. Since the volatiles, as used, in the
pkg_postinst are unused with systemd we can simply skip the
pkg_postinst when not using sysvinit.

Signed-off-by: Mark Asselstine 
---
 meta/recipes-extended/sysstat/sysstat.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/sysstat/sysstat.inc 
b/meta/recipes-extended/sysstat/sysstat.inc
index bb5629d..fce2804 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -42,7 +42,9 @@ do_install() {
sed -i -e 's#@LIBDIR@#${libdir}#g' 
${D}${systemd_unitdir}/system/sysstat.service
 }
 
-pkg_postinst_${PN} () {
+OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 
':sysvinit', '', d)}"
+
+pkg_postinst_${PN}_sysvinit () {
 if [ -n "$D" ]; then
 exit 0
 fi
-- 
2.7.4

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

Re: [OE-core] [oe] State of bitbake world, Failed tasks 2017-03-11

[Mark Asselstine]

On Sat, Mar 11, 2017 at 1:02 PM, Martin Jansa  wrote:
> This time the results are very inconsistent across different MACHINEs
> because they were using significantly different metadata.
>
> qemuarm is oldest 3 from 4 failures were causes by pending meta-oe
> changes which I've removed from master-next before qemux86* builds were
> restarted (after they failed badly few times).


You can add aufs-util to this list

| make: cc: Command not found

Regards,
Mark

>
> qemux86-64 is latest and contains HOSTTOOLS changes from
> oe-core/master-next that's why there is so many failures.
>
> From the failures I see following tools which we need to either add
> to HOSTTOOLS or provide with added -native dependency:
> cc  - tcsh- 
> http://errors.yoctoproject.org/Errors/Details/135201/
> cc  - u-boot-mkimage  - 
> http://errors.yoctoproject.org/Errors/Details/135203/
> cc  - toybox  - 
> http://errors.yoctoproject.org/Errors/Details/135210/
> cc  - yasm- 
> http://errors.yoctoproject.org/Errors/Details/135214/
> cpp - mkelfimage  - 
> http://errors.yoctoproject.org/Errors/Details/135211/
> clear   - lprng   - 
> http://errors.yoctoproject.org/Errors/Details/135207/
> gcc-ar  - ovmf- 
> http://errors.yoctoproject.org/Errors/Details/135202/
> join- netcf   - 
> http://errors.yoctoproject.org/Errors/Details/135208/
> join- fontforge   - 
> http://errors.yoctoproject.org/Errors/Details/135209/
> mknod   - initramfs-live-boot - 
> http://errors.yoctoproject.org/Errors/Details/135213/
> nl  - dash- 
> http://errors.yoctoproject.org/Errors/Details/135215/
> nl  - klibc   - 
> http://errors.yoctoproject.org/Errors/Details/135198/
> openssl - openflow- 
> http://errors.yoctoproject.org/Errors/Details/135216/
> readelf - firefox - 
> http://errors.yoctoproject.org/Errors/Details/135212/
> size- iptraf  - 
> http://errors.yoctoproject.org/Errors/Details/135204/
> yes - libnet-ssleay-perl  - 
> http://errors.yoctoproject.org/Errors/Details/135197/
> zcat- scsirastools- 
> http://errors.yoctoproject.org/Errors/Details/135205/
>
> Some of these were already merged in newer HOSTTOOLS patch currently
> in oe-core/master:
> mknod cpp readelf split gcc-ar gpg sftp
> and u-boot-mkimage should be fixed in master as well
>
> I'll merge most meta-oe changes and retrigger new round of testing,
> next time the failures should be a bit more consistent again.
>
> == Number of issues - stats ==
> {| class='wikitable'
> !|Date   !!colspan='3'|Failed tasks 
> !!colspan='6'|Failed depencencies!!|Signatures
> !!colspan='12'|QA !!Comment
> |-
> ||  ||qemuarm   ||qemux86   ||qemux86_64
> ||qemuarm||max||min ||qemux86||max||min ||all   ||already-stripped
>   ||libdir||textrel   ||build-deps||file-rdeps
> ||version-going-backwards   ||host-user-contaminated
> ||installed-vs-shipped  ||unknown-configure-option  ||symlink-to-sysroot  
>   ||invalid-pkgconfig ||pkgname   ||
> |-
> ||2017-03-11||4 ||1 ||20||N/A   ||N/A   ||N/A   ||N/A   ||N/A 
>   ||N/A   ||0 ||0 ||0 ||0 ||0 
> ||3 ||0 ||1 ||0 ||0   
>   ||0 ||0 ||0 ||
> |}
>
> http://www.openembedded.org/wiki/Bitbake_World_Status
>
> == Failed tasks 2017-03-11 ==
>
> INFO: jenkins-job.sh-1.8.18 Complete log available at 
> http://logs.nslu2-linux.org/buildlogs/oe/world/pyro/log.report.20170311_062851.log
>
> === common () ===
>
> === common-x86 (1) ===
> * 
> meta-openembedded/meta-oe/recipes-support/vboxguestdrivers/vboxguestdrivers_5.1.14.bb:do_install
>
> === qemuarm (4) ===
> * 
> meta-openembedded/meta-oe/recipes-connectivity/libtorrent/libtorrent_0.13.6.bb:do_compile
> * 
> meta-openembedded/meta-oe/recipes-devtools/rapidjson/rapidjson_1.1.0.bb:do_compile
> * meta-openembedded/meta-oe/recipes-support/gpm/gpm_1.99.7.bb:do_install
> * meta-qt5/recipes-connectivity/libqofono/libqofono_git.bb:do_compile
>
> === qemux86 (0) ===
>
> === qemux86_64 (19) ===
> * meta-browser/recipes-mozilla/firefox/firefox_45.6.0esr.bb:do_compile
> * meta-openembedded/meta-efl/recipes-efl/efl/efl_1.15.1.bb:do_compile
> * 
> meta-openembedded/meta-initramfs/recipes-devtools/klibc/klibc_2.0.4.bb:do_compile
> * 
> meta-openembedded/meta-initramfs/recipes-devtools/klibc/klibc-static-utils_2.0.4.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-protocols/openflow/openflow_git.bb:do_compile
> * 
> meta-openembedded/meta-networking/recipes-support/netcf/netcf_git.bb:do_configure
> * 
> meta-openembedded/meta-oe/recipes-core/toybox/toybox_0.7.2.bb:do_con

Re: [OE-core] [PATCH 1/3] go: Add recipes for golang compilers and tools

[Mark Asselstine]

On Wednesday, February 8, 2017 9:17:48 AM EST Paul Eggleton wrote:
> On Tuesday, 7 February 2017 9:44:46 AM NZDT Khem Raj wrote:
> > On Tue, Feb 7, 2017 at 9:35 AM, Burton, Ross  
wrote:
> > > On 7 February 2017 at 04:24, Khem Raj  wrote:
> > >> This is converging the recipes for go from
> > >> meta-virtualization and oe-meta-go
> > > 
> > > I'm still of the opinion that this should be in meta-go, not oe-core...
> > 
> > I think we have to make multiple layers agree on using one layer
> > I find atleast 3 which carry go recipes along with, if its in OE-Core
> > either these layers become redundant or layers which are housing go
> > recipes for
> > different purpose like meta-virtualization can then drop the compiler
> > recipes it will be easier from consolidation point of view.
> > 
> > if we dont want to take it into OE-Core, we should create a new layer
> > meta-golang on yp git and then help request community to converge to
> > it, it still can be ignored by layers.
> 
> Have we tried asking all of the various people involved if they'd mind
> working together? If not, I have my doubts as to whether putting it in
> OE-Core is going to entirely resolve the situation.

I have done a bunch of the work for go support in meta-virtualization. I am 
currently doing some updates around issues which per recipe sysroots 
uncovered. I think we would be fine moving our support out of meta-virt if 
support was somewhere where our changes would be taken/considered and merges 
would be done in a timely manner, something that hasn't always been the case 
with the previous attempts to centralize go.

Feel free to ping me on this, I will try to find time to try it out and will 
work to get it to the point where we can consider removing parts/all from 
meta-virt.

MarkA 

> 
> Cheers,
> Paul


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

[OE-core] [V2][PATCH] sysklogd: do more to properly work with systemd

[Mark Asselstine]

It was noticed that syslogd and klogd were no longer running on system
startup, meaning no /var/log/messages etc.. It appears as though
sysklogd has never been updated to follow the expected logging
requirement for systemd as described here:
https://www.freedesktop.org/wiki/Software/systemd/syslog/

As such no service was started and no logging present. Using the above
guidelines we create two new service files syslogd.service and
klogd.service. We make use of tmpfiles.d in order to ensure the
xconsole device node exists and do other minor recipe cleanup to
ensure peaceful coexistence with sysvinit and systemd implementations.

The systemd documentation also asks that for a logger which is not
rsyslog that we also enable 'ForwardToSyslog=' in journald.conf, but
this is already the case so no action is required.

With this change in place syslogd and klogd are started at system
startup and the expected logs are available.

Unfortunately I was not able to find any work done on this upstream or
in other distros so this is my best effort at making this work.

Signed-off-by: Mark Asselstine 
---

** V2 **
* update to not break sysvinit builds


 meta/recipes-extended/sysklogd/files/klogd.service  | 13 +
 .../recipes-extended/sysklogd/files/syslogd.service | 14 ++
 .../sysklogd/files/tmpfiles.sysklogd.conf   |  1 +
 meta/recipes-extended/sysklogd/sysklogd.inc | 21 +++--
 4 files changed, 47 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-extended/sysklogd/files/klogd.service
 create mode 100644 meta/recipes-extended/sysklogd/files/syslogd.service
 create mode 100644 meta/recipes-extended/sysklogd/files/tmpfiles.sysklogd.conf

diff --git a/meta/recipes-extended/sysklogd/files/klogd.service 
b/meta/recipes-extended/sysklogd/files/klogd.service
new file mode 100644
index 000..0c888c4
--- /dev/null
+++ b/meta/recipes-extended/sysklogd/files/klogd.service
@@ -0,0 +1,13 @@
+[Unit]
+Description=Kernel Logging Service
+After=syslogd.service
+
+[Service]
+Type=forking
+ExecStart=/sbin/klogd
+PIDFile=/var/run/klogd.pid
+StandardOutput=null
+Restart=on-failure
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta/recipes-extended/sysklogd/files/syslogd.service 
b/meta/recipes-extended/sysklogd/files/syslogd.service
new file mode 100644
index 000..eeaff3d
--- /dev/null
+++ b/meta/recipes-extended/sysklogd/files/syslogd.service
@@ -0,0 +1,14 @@
+[Unit]
+Description=System Logging Service
+Requires=syslog.socket
+
+[Service]
+Type=forking
+ExecStart=/sbin/syslogd
+PIDFile=/var/run/syslogd.pid
+StandardOutput=null
+Restart=on-failure
+
+[Install]
+WantedBy=multi-user.target
+Alias=syslog.service
diff --git a/meta/recipes-extended/sysklogd/files/tmpfiles.sysklogd.conf 
b/meta/recipes-extended/sysklogd/files/tmpfiles.sysklogd.conf
new file mode 100644
index 000..f4aecd3
--- /dev/null
+++ b/meta/recipes-extended/sysklogd/files/tmpfiles.sysklogd.conf
@@ -0,0 +1 @@
+p /dev/xconsole 0640 root adm
diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc 
b/meta/recipes-extended/sysklogd/sysklogd.inc
index 5c15ffe..f9af0a4 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -11,17 +11,24 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
 
file://klogd.c;beginline=2;endline=19;md5=7e87ed0ae6142de079bce738c10c899d \
"
 
-inherit update-rc.d update-alternatives
+inherit update-rc.d update-alternatives systemd
 
 SRC_URI = 
"http://www.infodrom.org/projects/sysklogd/download/sysklogd-${PV}.tar.gz \
file://no-strip-install.patch \
file://0001-Fix-build-with-musl.patch \
file://sysklogd \
file://syslog.conf \
+   file://syslogd.service \
+   file://klogd.service \
+   file://tmpfiles.sysklogd.conf \
"
 
 SRC_URI_append_e500v2 = " file://no-vectorization.patch"
 
+SYSTEMD_PACKAGES = "${PN}"
+SYSTEMD_SERVICE_${PN} = "syslogd.service klogd.service"
+SYSTEMD_AUTO_ENABLE = "enable"
+
 INITSCRIPT_NAME = "syslog"
 CONFFILES_${PN} = "${sysconfdir}/syslog.conf.${BPN}"
 
@@ -39,13 +46,23 @@ do_install () {
install -m 644 ${WORKDIR}/syslog.conf ${D}${sysconfdir}/syslog.conf
install -d ${D}${sysconfdir}/init.d
install -m 755 ${WORKDIR}/sysklogd ${D}${sysconfdir}/init.d/syslog
+   install -d ${D}${systemd_unitdir}/system
+   install -m 644 ${WORKDIR}/syslogd.service ${D}${systemd_unitdir}/system
+   install -m 644 ${WORKDIR}/klogd.service ${D}${systemd_unitdir}/system
+   if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true', 'false', 
d)}; then
+   install -d ${D}${exec_prefix}/lib/tmpfiles.d
+   install -m 644 ${WORKDIR}/tmpfiles.sysklogd.conf 
${D}${exec_pref

Re: [OE-core] [PATCH] systemd: disable 'libdir' QA check

[Mark Asselstine]

On Monday, December 12, 2016 9:17:14 PM EST Burton, Ross wrote:
> On 12 December 2016 at 20:51, Mark Asselstine  > wrote:
> > 
> > I think the discussion I pointed to in the commit log closes the door on
> > any
> > such change. Specific the comment from Lennart --
> > https://github.com/systemd/systemd/issues/3810#issuecomment-235290526
> > 
> > They don't want the library to be found in the default search path, they
> > want
> > to maintain this as a "hidden, internal resource".
> 
> Oh if it's an implementation detail of systemd and not a user-facing
> library then I can see their argument I guess.
> 
> Don't agree with it though.  But, the point is that as long as the parts of
> systemd that could realistically be multilibd are in $libdir then this
> isn't a problem.

It is definitely an internal infra item for systemd and not seen as a 'public' 
library so I think we are best to run with it. I am with you that I don't 
necessarily agree with it. Khem, does this satisfy your concerns?

Mark

> 
> Ross


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

Re: [OE-core] [PATCH] systemd: disable 'libdir' QA check

[Mark Asselstine]

On Monday, December 12, 2016 11:59:04 AM EST Khem Raj wrote:
> > On Dec 12, 2016, at 11:36 AM, Mark Asselstine
> >  wrote:
> > 
> > When building systemd with multilib support enabled in your build you
> > will get the following QA warnings (if the 'libdir' QA check is
> > enabled.)
> > 
> > WARNING: systemd-1_232-r0 do_package_qa: QA Issue: systemd-dbg: found \
> > library in wrong location: /lib/systemd/.debug/libsystemd-shared-232.so
> > systemd: found library in wrong location:
> > /lib/systemd/libsystemd-shared.so
> > systemd: found library in wrong location:
> > /lib/systemd/libsystemd-shared-232.so [libdir]
> Can we check if systemd can be a bit more flexible and accept it to go into
> multilib libdir ? this patch can be then applied if its not acceptable to
> systemd community.

I think the discussion I pointed to in the commit log closes the door on any 
such change. Specific the comment from Lennart --
https://github.com/systemd/systemd/issues/3810#issuecomment-235290526

They don't want the library to be found in the default search path, they want 
to maintain this as a "hidden, internal resource".

Being on the record that I am aware of this discussion/conclusion if I send a 
patch now I would look like a bit of ass for wasting their time. If someone 
else wants to push the issue, feel free. Unless there is a suitable 
recommendation that would satisfy their wishes and ours that I am missing.

Mark


> > Since systemd 231 upstream has included an 'internal' library which
> > they explicitly place in the application specific /lib/systemd
> > directory. You can see some of the discussion about this placement
> > here https://github.com/systemd/systemd/issues/3810
> > 
> > This placement is being picked up by the QA checker since when
> > multilibs are enabled it expects all libraries to be in lib32 or
> > lib64. Since the systemd and systemd-dbg packages don't contain any
> > other libraries we can respect the upstream placement and skip this QA
> > check for these packages. Unfortunately the QA mechanism doesn't allow
> > us to specify individual files so this approach is the best we can do.
> > 
> > Signed-off-by: Mark Asselstine 
> > ---
> > meta/recipes-core/systemd/systemd_232.bb | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-core/systemd/systemd_232.bb
> > b/meta/recipes-core/systemd/systemd_232.bb index baee02e..c86badb 100644
> > --- a/meta/recipes-core/systemd/systemd_232.bb
> > +++ b/meta/recipes-core/systemd/systemd_232.bb
> > @@ -485,7 +485,8 @@ RRECOMMENDS_${PN} +=
> > "${@bb.utils.contains('PACKAGECONFIG', 'serial-getty-genera> 
> >   os-release \
> > 
> > "
> > 
> > -INSANE_SKIP_${PN} += "dev-so"
> > +INSANE_SKIP_${PN} += "dev-so libdir"
> > +INSANE_SKIP_${PN}-dbg += "libdir"
> > INSANE_SKIP_${PN}-doc += " libdir"
> > 
> > PACKAGES =+ "udev udev-hwdb"


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

[OE-core] [PATCH] systemd: disable 'libdir' QA check

[Mark Asselstine]

When building systemd with multilib support enabled in your build you
will get the following QA warnings (if the 'libdir' QA check is
enabled.)

WARNING: systemd-1_232-r0 do_package_qa: QA Issue: systemd-dbg: found \
 library in wrong location: /lib/systemd/.debug/libsystemd-shared-232.so
systemd: found library in wrong location: /lib/systemd/libsystemd-shared.so
systemd: found library in wrong location: /lib/systemd/libsystemd-shared-232.so 
[libdir]

Since systemd 231 upstream has included an 'internal' library which
they explicitly place in the application specific /lib/systemd
directory. You can see some of the discussion about this placement
here https://github.com/systemd/systemd/issues/3810

This placement is being picked up by the QA checker since when
multilibs are enabled it expects all libraries to be in lib32 or
lib64. Since the systemd and systemd-dbg packages don't contain any
other libraries we can respect the upstream placement and skip this QA
check for these packages. Unfortunately the QA mechanism doesn't allow
us to specify individual files so this approach is the best we can do.

Signed-off-by: Mark Asselstine 
---
 meta/recipes-core/systemd/systemd_232.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_232.bb 
b/meta/recipes-core/systemd/systemd_232.bb
index baee02e..c86badb 100644
--- a/meta/recipes-core/systemd/systemd_232.bb
+++ b/meta/recipes-core/systemd/systemd_232.bb
@@ -485,7 +485,8 @@ RRECOMMENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 
'serial-getty-genera
   os-release \
 "
 
-INSANE_SKIP_${PN} += "dev-so"
+INSANE_SKIP_${PN} += "dev-so libdir"
+INSANE_SKIP_${PN}-dbg += "libdir"
 INSANE_SKIP_${PN}-doc += " libdir"
 
 PACKAGES =+ "udev udev-hwdb"
-- 
2.7.4

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

[OE-core] [PATCH] sysklogd: do more to properly work with systemd

[Mark Asselstine]

It was noticed that syslogd and klogd were no longer running on system
startup, meaning no /var/log/messages etc.. It appears as though
sysklogd has never been updated to follow the expected logging
requirement for systemd as described here:
https://www.freedesktop.org/wiki/Software/systemd/syslog/

As such no service was started and no logging present. Using the above
guidelines we create two new service files syslogd.service and
klogd.service. We make use of tmpfiles.d in order to ensure the
xconsole device node exists and do other minor recipe cleanup to
ensure peaceful coexistence with sysvinit and systemd implementations.

The systemd documentation also asks that for a logger which is not
rsyslog that we also enable 'ForwardToSyslog=' in journald.conf, but
this is already the case so no action is required.

With this change in place syslogd and klogd are started at system
startup and the expected logs are available.

Unfortunately I was not able to find any work done on this upstream or
in other distros so this is my best effort at making this work.

Signed-off-by: Mark Asselstine 
---
 meta/recipes-extended/sysklogd/files/klogd.service| 13 +
 meta/recipes-extended/sysklogd/files/syslogd.service  | 14 ++
 .../sysklogd/files/tmpfiles.sysklogd.conf |  1 +
 meta/recipes-extended/sysklogd/sysklogd.inc   | 19 +--
 4 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-extended/sysklogd/files/klogd.service
 create mode 100644 meta/recipes-extended/sysklogd/files/syslogd.service
 create mode 100644 meta/recipes-extended/sysklogd/files/tmpfiles.sysklogd.conf

diff --git a/meta/recipes-extended/sysklogd/files/klogd.service 
b/meta/recipes-extended/sysklogd/files/klogd.service
new file mode 100644
index 000..0c888c4
--- /dev/null
+++ b/meta/recipes-extended/sysklogd/files/klogd.service
@@ -0,0 +1,13 @@
+[Unit]
+Description=Kernel Logging Service
+After=syslogd.service
+
+[Service]
+Type=forking
+ExecStart=/sbin/klogd
+PIDFile=/var/run/klogd.pid
+StandardOutput=null
+Restart=on-failure
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta/recipes-extended/sysklogd/files/syslogd.service 
b/meta/recipes-extended/sysklogd/files/syslogd.service
new file mode 100644
index 000..eeaff3d
--- /dev/null
+++ b/meta/recipes-extended/sysklogd/files/syslogd.service
@@ -0,0 +1,14 @@
+[Unit]
+Description=System Logging Service
+Requires=syslog.socket
+
+[Service]
+Type=forking
+ExecStart=/sbin/syslogd
+PIDFile=/var/run/syslogd.pid
+StandardOutput=null
+Restart=on-failure
+
+[Install]
+WantedBy=multi-user.target
+Alias=syslog.service
diff --git a/meta/recipes-extended/sysklogd/files/tmpfiles.sysklogd.conf 
b/meta/recipes-extended/sysklogd/files/tmpfiles.sysklogd.conf
new file mode 100644
index 000..f4aecd3
--- /dev/null
+++ b/meta/recipes-extended/sysklogd/files/tmpfiles.sysklogd.conf
@@ -0,0 +1 @@
+p /dev/xconsole 0640 root adm
diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc 
b/meta/recipes-extended/sysklogd/sysklogd.inc
index 5c15ffe..092b922 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -11,17 +11,24 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
 
file://klogd.c;beginline=2;endline=19;md5=7e87ed0ae6142de079bce738c10c899d \
"
 
-inherit update-rc.d update-alternatives
+inherit update-rc.d update-alternatives systemd
 
 SRC_URI = 
"http://www.infodrom.org/projects/sysklogd/download/sysklogd-${PV}.tar.gz \
file://no-strip-install.patch \
file://0001-Fix-build-with-musl.patch \
file://sysklogd \
file://syslog.conf \
+   file://syslogd.service \
+   file://klogd.service \
+   file://tmpfiles.sysklogd.conf \
"
 
 SRC_URI_append_e500v2 = " file://no-vectorization.patch"
 
+SYSTEMD_PACKAGES = "${PN}"
+SYSTEMD_SERVICE_${PN} = "syslogd.service klogd.service"
+SYSTEMD_AUTO_ENABLE = "enable"
+
 INITSCRIPT_NAME = "syslog"
 CONFFILES_${PN} = "${sysconfdir}/syslog.conf.${BPN}"
 
@@ -39,13 +46,21 @@ do_install () {
install -m 644 ${WORKDIR}/syslog.conf ${D}${sysconfdir}/syslog.conf
install -d ${D}${sysconfdir}/init.d
install -m 755 ${WORKDIR}/sysklogd ${D}${sysconfdir}/init.d/syslog
+   install -d ${D}${systemd_unitdir}/system
+   install -m 644 ${WORKDIR}/syslogd.service ${D}${systemd_unitdir}/system
+   install -m 644 ${WORKDIR}/klogd.service ${D}${systemd_unitdir}/system
+   install -d ${D}${exec_prefix}/lib/tmpfiles.d
+   install -m 644 ${WORKDIR}/tmpfiles.sysklogd.conf 
${D}${exec_prefix}/lib/tmpfiles.d/sysklogd.conf
 }
 
+FILES_${PN} += 
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${exec_prefix}/lib/tmpfiles.d/sysklogd.conf',

[OE-core] [PATCH] sysstat: fixup pkg_postinst to allow SYSTEMD_AUTO_ENABLE to work

[Mark Asselstine]

The logic added to the pkg_postinst in commit 6bf82c26f953 has the
side effect of rendering SYSTEMD_AUTO_ENABLE ineffective. The systemd
service will not be configured as 'enabled' either offline(do_rootfs)
or during first boot. Since the volatiles, as used, in the
pkg_postinst are unused with systemd we can simply skip the
pkg_postinst when not using sysvinit.

Signed-off-by: Mark Asselstine 
---
 meta/recipes-extended/sysstat/sysstat.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/sysstat/sysstat.inc 
b/meta/recipes-extended/sysstat/sysstat.inc
index bb5629d..fce2804 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -42,7 +42,9 @@ do_install() {
sed -i -e 's#@LIBDIR@#${libdir}#g' 
${D}${systemd_unitdir}/system/sysstat.service
 }
 
-pkg_postinst_${PN} () {
+OVERRIDES_append = "${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 
':sysvinit', '', d)}"
+
+pkg_postinst_${PN}_sysvinit () {
 if [ -n "$D" ]; then
 exit 0
 fi
-- 
2.7.4

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

[OE-core] [PATCH] systemd.bbclass: don't block on service restart

[Mark Asselstine]

The current class works fine when a recipe uses SYSTEMD_AUTO_ENABLE
'enable' and has no on device pkg_postinst(), ie when the postinst is
run as part of rootfs creation.  However, when there is a component of
pkg_postinst() that is run on device the 'systemctl restart' is run as
part of the run_postinsts.service at boot. This results in the boot
spinning indefinitely with:

[ *** ] A start job is running for Run pending postinsts (7s / no limit)

The issue could potentially be that the packages service has an
'After' clause which comes later in the boot, beyond
run_postinsts.service, creating a chicken before the egg
scenario. Even service files without an 'After' clause cause this
situation however. Despite this not being the cause of the issue this
fix will prevent this scenario from happenning.

Using strace we are able to find that during boot, when
run_postinsts.service is running attempting to start or restart any
service will result in the call get stuck on poll(). Since the
run_postinsts.service does not monitor the outcome of the call to
restart we can work around this by using '--no-block'.

Signed-off-by: Mark Asselstine 
---
 meta/classes/systemd.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
index 7e51ed6..99a08a0 100644
--- a/meta/classes/systemd.bbclass
+++ b/meta/classes/systemd.bbclass
@@ -36,7 +36,7 @@ if type systemctl >/dev/null 2>/dev/null; then
systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
 
if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
-   systemctl restart ${SYSTEMD_SERVICE}
+   systemctl --no-block restart ${SYSTEMD_SERVICE}
fi
 fi
 }
-- 
2.7.4

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

Re: [OE-core] [PATCHv3 10/30] vte: Upgrade to 0.44.1

[Mark Asselstine]

On Wednesday, June 22, 2016 9:18:10 PM EDT Burton, Ross wrote:
> On 22 June 2016 at 19:24, Andreas Müller 
> 
> wrote:
> > Could we move vte to meta-oe to avoid further world blacklisting?
> 
> This was the agreement in the other thread - Mark was going to restore the
> old version with a new PN for meta-xfce.

Jussi got to it first and has a review out for this on for meta-oe.

Mark

> 
> Ross


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

Re: [OE-core] [RFC][PATCH] vte: bring back old version to support xfce4-terminal

[Mark Asselstine]

On June 17, 2016 20:43:06 Jussi Kukkonen wrote:
> On 17 June 2016 at 16:33, Mark Asselstine 
> 
> wrote:
> > On June 16, 2016 18:10:09 Andre McCurdy wrote:
> > > On Thu, Jun 16, 2016 at 2:47 PM, Burton, Ross 
> > 
> > wrote:
> > > > On 16 June 2016 at 21:49, Mark Asselstine <
> > 
> > mark.asselst...@windriver.com>
> > 
> > > > wrote:
> > > >> While waiting to hear back about my inquiry I did take some
> > > >> time to put together this patch that allows things that
> > > >> require the older vte to continue to build. Since xfce4-terminal
> > > >> lives in meta-openembedded this might make more sense to carry
> > > >> over there. I am sure folks will have an opinion so sending this
> > > >> out as an RFC.
> > > > 
> > > > That's certainly a good argument for putting the old vte in meta-oe.
> > > 
> > > The meta-oe layers generally have a higher priority than oe-core, so
> > > having an older version in meta-oe and a newer version in oe-core can
> > > lead to unexpected results.
> > 
> > This should not be an issue. My change has the old recipe renamed with the
> > API
> > version so the old version becomes referenced by 'vte-0.0' (per the commit
> > log
> > the 0.0 is consistent with the API versioning upstream). So recipes which
> > require the old version, like xfce4-terminal, have to have their DEPENDS
> > adjusted accordingly. There should be no surprises.
> > 
> > I will have a closer look today to ensure nothing in oe-core is requiring
> > the
> > old version and if not I will prepare a patch for meta-oe since that seems
> > to
> > be the general agreement for a home for this. I need to do some further
> > checks
> > and runtime tests but I will get this out shortly. In the meantime anyone
> > else
> > running in to the build failure can exploit the RFC patch.
> 
> Thanks Mark. I can confirm that nothing in oe-core needs the old vte.
> 
> As a sidenote in case you're looking at the vte users in oe-core: I notice
> I didn't include a  patch for qemu yet. The situation there is that our
> qemu version works fine with the new vte but might still need a small
> configure.ac patch in addition to updated PACKAGECONFIG line. I'll include
> this in my next patchset.

Since I work quite a bit with meta-virtualization and thus QEMU that will be 
nice to avoid any potential issues in that area.

Thanks for the heads up regarding other vte users in oe-core. This will allow 
me to focus on some runtime testing in meta-oe prior to me sending a patch 
that way.

This should wrap up the discussions around vte for oe-core at least for now.

Mark

> 
> - Jussi
> 
> 
> Mark
> 
> > > > Ross
> > > > 
> > > > --
> > > > ___
> > > > 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

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

Re: [OE-core] [RFC][PATCH] vte: bring back old version to support xfce4-terminal

[Mark Asselstine]

On June 16, 2016 18:10:09 Andre McCurdy wrote:
> On Thu, Jun 16, 2016 at 2:47 PM, Burton, Ross  wrote:
> > On 16 June 2016 at 21:49, Mark Asselstine 
> > 
> > wrote:
> >> While waiting to hear back about my inquiry I did take some
> >> time to put together this patch that allows things that
> >> require the older vte to continue to build. Since xfce4-terminal
> >> lives in meta-openembedded this might make more sense to carry
> >> over there. I am sure folks will have an opinion so sending this
> >> out as an RFC.
> > 
> > That's certainly a good argument for putting the old vte in meta-oe.
> 
> The meta-oe layers generally have a higher priority than oe-core, so
> having an older version in meta-oe and a newer version in oe-core can
> lead to unexpected results.

This should not be an issue. My change has the old recipe renamed with the API 
version so the old version becomes referenced by 'vte-0.0' (per the commit log 
the 0.0 is consistent with the API versioning upstream). So recipes which 
require the old version, like xfce4-terminal, have to have their DEPENDS 
adjusted accordingly. There should be no surprises.

I will have a closer look today to ensure nothing in oe-core is requiring the 
old version and if not I will prepare a patch for meta-oe since that seems to 
be the general agreement for a home for this. I need to do some further checks 
and runtime tests but I will get this out shortly. In the meantime anyone else 
running in to the build failure can exploit the RFC patch.

Mark

> 
> > Ross
> > 
> > --
> > ___
> > 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

[OE-core] [RFC][PATCH] vte: bring back old version to support xfce4-terminal

[Mark Asselstine]

The recent uprev to vte version 0.44.1 as part of commit
commit dc21182ada418cf3917ae8319494d219462c5bfd [vte: Upgrade to 0.44.1]
brought with it an jump in api version, leaving any packages, such as
xfce4-terminal, failing to configure/build. The commit log indicated
that it was a possibility to support the two versions (more
specifically the two api versions) side by side but that this option
was not taken.

Since we now know that this uprev does have fairly significant impact
on some other packages bring back the old version and have it live
side by side with the new. The appended version '0.0' was selected to
match the api version string used by the the upstream vte project.

Signed-off-by: Mark Asselstine 
---

While waiting to hear back about my inquiry I did take some
time to put together this patch that allows things that
require the older vte to continue to build. Since xfce4-terminal
lives in meta-openembedded this might make more sense to carry
over there. I am sure folks will have an opinion so sending this
out as an RFC.

Mark


 .../vte/vte-0.0/cve-2012-2738.patch| 136 +
 .../vte/vte-0.0/obsolete_automake_macros.patch |  14 +++
 meta/recipes-support/vte/vte-0.0_0.28.2.bb |  31 +
 3 files changed, 181 insertions(+)
 create mode 100644 meta/recipes-support/vte/vte-0.0/cve-2012-2738.patch
 create mode 100644 
meta/recipes-support/vte/vte-0.0/obsolete_automake_macros.patch
 create mode 100644 meta/recipes-support/vte/vte-0.0_0.28.2.bb

diff --git a/meta/recipes-support/vte/vte-0.0/cve-2012-2738.patch 
b/meta/recipes-support/vte/vte-0.0/cve-2012-2738.patch
new file mode 100644
index 000..9b99803
--- /dev/null
+++ b/meta/recipes-support/vte/vte-0.0/cve-2012-2738.patch
@@ -0,0 +1,136 @@
+Upstream-Status: Backport
+CVE: CVE-2012-2738
+Signed-off-by: Ross Burton 
+
+From e524b0b3bd8fad844ffa73927c199545b892cdbd Mon Sep 17 00:00:00 2001
+From: Christian Persch 
+Date: Sat, 19 May 2012 19:36:09 +0200
+Subject: [PATCH 1/2] emulation: Limit integer arguments to 65535
+
+To guard against malicious sequences containing excessively big numbers,
+limit all parsed numbers to 16 bit range. Doing this here in the parsing
+routine is a catch-all guard; this doesn't preclude enforcing
+more stringent limits in the handlers themselves.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=676090
+---
+ src/table.c  | 2 +-
+ src/vteseq.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/table.c b/src/table.c
+index 140e8c8..85cf631 100644
+--- a/src/table.c
 b/src/table.c
+@@ -550,7 +550,7 @@ _vte_table_extract_numbers(GValueArray **array,
+   if (G_UNLIKELY (*array == NULL)) {
+   *array = g_value_array_new(1);
+   }
+-  g_value_set_long(&value, total);
++  g_value_set_long(&value, CLAMP (total, 0, G_MAXUSHORT));
+   g_value_array_append(*array, &value);
+   } while (i++ < arginfo->length);
+   g_value_unset(&value);
+diff --git a/src/vteseq.c b/src/vteseq.c
+index 7ef4c8c..10991db 100644
+--- a/src/vteseq.c
 b/src/vteseq.c
+@@ -557,7 +557,7 @@ vte_sequence_handler_multiple(VteTerminal *terminal,
+   GValueArray *params,
+   VteTerminalSequenceHandler handler)
+ {
+-vte_sequence_handler_multiple_limited(terminal, params, handler, 
G_MAXLONG);
++vte_sequence_handler_multiple_limited(terminal, params, handler, 
G_MAXUSHORT);
+ }
+ 
+ static void
+-- 
+2.4.9 (Apple Git-60)
+
+
+From cf1ad453a8def873c49cf6d88162593402f32bb2 Mon Sep 17 00:00:00 2001
+From: Christian Persch 
+Date: Sat, 19 May 2012 20:04:12 +0200
+Subject: [PATCH 2/2] emulation: Limit repetitions
+
+Don't allow malicious sequences to cause excessive repetitions.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=676090
+---
+ src/vteseq.c | 25 ++---
+ 1 file changed, 18 insertions(+), 7 deletions(-)
+
+diff --git a/src/vteseq.c b/src/vteseq.c
+index 10991db..209522f 100644
+--- a/src/vteseq.c
 b/src/vteseq.c
+@@ -1392,7 +1392,7 @@ vte_sequence_handler_dc (VteTerminal *terminal, 
GValueArray *params)
+ static void
+ vte_sequence_handler_DC (VteTerminal *terminal, GValueArray *params)
+ {
+-  vte_sequence_handler_multiple(terminal, params, 
vte_sequence_handler_dc);
++  vte_sequence_handler_multiple_r(terminal, params, 
vte_sequence_handler_dc);
+ }
+ 
+ /* Delete a line at the current cursor position. */
+@@ -1785,7 +1785,7 @@ vte_sequence_handler_reverse_index (VteTerminal 
*terminal, GValueArray *params)
+ static void
+ vte_sequence_handler_RI (VteTerminal *terminal, GValueArray *params)
+ {
+-  vte_sequence_handler_multiple(terminal, params, 
vte_sequence_handler_nd);
++  vte_sequence_handler_multiple_r(terminal, params, 
vte_sequence_handler_nd);
+ }
+ 
+ /* Save cursor (position). */
+@@ -2777,8 +2777,7 @@ vte_sequence_handler_insert_

Re: [OE-core] [PATCHv3 10/30] vte: Upgrade to 0.44.1

[Mark Asselstine]

On 14 June 2016 at 11:14, Jussi Kukkonen  > wrote:
> 
> * License change LGPL 2.0 -> LGPL 2.1+
> * vte-termcap is no more
> * API break: current version seems to be parallel installable
>with old one, but I did not opt for that.
> * Add patch to avoid stack protection by default
> * Add SECURITY_NO_PIE_CFLAGS exception until linking failure with
>libc_nonshared.a is resolved (undefined reference to
>__init_array_start)
> 
> 
> Just found out Khem has worked around a similar problem with
> libtool-cross already: I've modified this patch so
> that SECURITY_NO_PIE_CFLAGS is no longer used, but instead libtool-cross
> is used:
> 
> +# libtool adds "-nostdlib" when g++ is used. This breaks PIE builds.
> +# Use libtool-cross (which has a hack to prevent that) instead.
> +EXTRA_OEMAKE_class-target =
> "LIBTOOL=${STAGING_BINDIR_CROSS}/${HOST_SYS}-libtool"
> 
>   - Jussi

Just a heads up this this breaks xfce4-terminal. There is currently no
xfce4-terminal release which will function with vte api 2.91, only
ongoing work on their master branch as far as I can tell. I have no
idea how far reaching the effects of this change will be on
xfce. Before I spend any time on this is this something which folks
are aware of and is there a plan in place? Is there a possibility to
keep the older vte around?

Thanks,
Mark


> 
> 
> Signed-off-by: Jussi Kukkonen  >
> ---
>   meta/conf/distro/include/security_flags.inc|   2 +
>   .../vte/vte-0.28.2/cve-2012-2738.patch | 136
> -
>   .../vte/vte-0.28.2/obsolete_automake_macros.patch  |  14 ---
>   meta/recipes-support/vte/vte.inc   |  15 ---
>   ...-Don-t-enable-stack-protection-by-default.patch |  29 +
>   meta/recipes-support/vte/vte_0.28.2.bb 
> 
>   |  16 ---
> 
>   meta/recipes-support/vte/vte_0.44.1.bb 
> 
>   |  24 
> 
>   7 files changed, 55 insertions(+), 181 deletions(-)
>   delete mode 100644
> meta/recipes-support/vte/vte-0.28.2/cve-2012-2738.patch
>   delete mode 100644
> meta/recipes-support/vte/vte-0.28.2/obsolete_automake_macros.patch
>   delete mode 100644 meta/recipes-support/vte/vte.inc
>   create mode 100644
>
> meta/recipes-support/vte/vte/0001-Don-t-enable-stack-protection-by-default.
> patch delete mode 100644 meta/recipes-support/vte/vte_0.28.2.bb
> 
>   create mode 100644 meta/recipes-support/vte/vte_0.44.1.bb
> 
> 
> diff --git a/meta/conf/distro/include/security_flags.inc
> b/meta/conf/distro/include/security_flags.inc
> index ea1d4e5..0df65e0 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -95,6 +95,8 @@ SECURITY_CFLAGS_pn-zlib = "${SECURITY_NO_PIE_CFLAGS}"
>   SECURITY_CFLAGS_pn-ltp = "${SECURITY_NO_PIE_CFLAGS}"
>   SECURITY_CFLAGS_pn-pulseaudio = "${SECURITY_NO_PIE_CFLAGS}"
> 
> +SECURITY_CFLAGS_pn-vte = "${SECURITY_NO_PIE_CFLAGS}"
> +
>   # Recipes which fail to compile when elevating -Wformat-security
> to an error
>   SECURITY_STRINGFORMAT_pn-busybox = ""
>   SECURITY_STRINGFORMAT_pn-console-tools = ""
> diff --git a/meta/recipes-support/vte/vte-0.28.2/cve-2012-2738.patch
> b/meta/recipes-support/vte/vte-0.28.2/cve-2012-2738.patch
> deleted file mode 100644
> index 9b99803..000
> --- a/meta/recipes-support/vte/vte-0.28.2/cve-2012-2738.patch
> +++ /dev/null
> @@ -1,136 +0,0 @@
> -Upstream-Status: Backport
> -CVE: CVE-2012-2738
> -Signed-off-by: Ross Burton  >
> -
> -From e524b0b3bd8fad844ffa73927c199545b892cdbd Mon Sep 17 00:00:00 2001
> -From: Christian Persch http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] useradd_base.bbclass: prevent variable expansion in $opts

[Mark Asselstine]

Many user/group operations will involve hashes which will include '$'
followed by a number or even possibly an env. variable name. Passing
$opts to flock requires that we take additional precautions to prevent
the unexpected expansion of these instances.

This was found by an image which used usermod operations to set the
password hash for root. The image could not be logged-in to and
examining /etc/shadow clearly showed that $0 and other $* variables
had been expanded unexpectedly. This change returnes the behavior to
what existed prior to commit 2ebf697b46c42cee8bfa6d2e6087397f8cce385c
[useradd_base.bbclass: replace retry logic with flock].

Signed-off-by: Mark Asselstine 
---
 meta/classes/useradd_base.bbclass | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/classes/useradd_base.bbclass 
b/meta/classes/useradd_base.bbclass
index 9b8f5c2..e7081d9 100644
--- a/meta/classes/useradd_base.bbclass
+++ b/meta/classes/useradd_base.bbclass
@@ -18,7 +18,7 @@ perform_groupadd () {
local group_exists="`grep "^$groupname:" $rootdir/etc/group || true`"
if test "x$group_exists" = "x"; then
opts=`echo $opts | sed s/\'/\"/g`
-   eval flock -x -w 100 $rootdir${sysconfdir} -c \'$PSEUDO 
groupadd $opts\' || true
+   eval flock -x -w 100 $rootdir${sysconfdir} -c \"$PSEUDO 
groupadd \$opts\" || true
group_exists="`grep "^$groupname:" $rootdir/etc/group || true`"
if test "x$group_exists" = "x"; then
bbfatal "${PN}: groupadd command did not succeed."
@@ -36,7 +36,7 @@ perform_useradd () {
local user_exists="`grep "^$username:" $rootdir/etc/passwd || true`"
if test "x$user_exists" = "x"; then
opts=`echo $opts | sed s/\'/\"/g`
-   eval flock -x -w 100 $rootdir${sysconfdir} -c  \'$PSEUDO 
useradd $opts\' || true
+   eval flock -x -w 100 $rootdir${sysconfdir} -c  \"$PSEUDO 
useradd \$opts\" || true
user_exists="`grep "^$username:" $rootdir/etc/passwd || true`"
if test "x$user_exists" = "x"; then
bbfatal "${PN}: useradd command did not succeed."
@@ -63,7 +63,7 @@ perform_groupmems () {
fi
local mem_exists="`grep 
"^$groupname:[^:]*:[^:]*:\([^,]*,\)*$username\(,[^,]*\)*" $rootdir/etc/group || 
true`"
if test "x$mem_exists" = "x"; then
-   eval flock -x -w 100 $rootdir${sysconfdir} -c \'$PSEUDO 
groupmems $opts\' || true
+   eval flock -x -w 100 $rootdir${sysconfdir} -c \"$PSEUDO 
groupmems \$opts\" || true
mem_exists="`grep 
"^$groupname:[^:]*:[^:]*:\([^,]*,\)*$username\(,[^,]*\)*" $rootdir/etc/group || 
true`"
if test "x$mem_exists" = "x"; then
bbfatal "${PN}: groupmems command did not succeed."
@@ -84,7 +84,7 @@ perform_groupdel () {
local groupname=`echo "$opts" | awk '{ print $NF }'`
local group_exists="`grep "^$groupname:" $rootdir/etc/group || true`"
if test "x$group_exists" != "x"; then
-   eval flock -x -w 100 $rootdir${sysconfdir} -c \'$PSEUDO 
groupdel $opts\' || true
+   eval flock -x -w 100 $rootdir${sysconfdir} -c \"$PSEUDO 
groupdel \$opts\" || true
group_exists="`grep "^$groupname:" $rootdir/etc/group || true`"
if test "x$group_exists" != "x"; then
bbfatal "${PN}: groupdel command did not succeed."
@@ -101,7 +101,7 @@ perform_userdel () {
local username=`echo "$opts" | awk '{ print $NF }'`
local user_exists="`grep "^$username:" $rootdir/etc/passwd || true`"
if test "x$user_exists" != "x"; then
-   eval flock -x -w 100 $rootdir${sysconfdir} -c \'$PSEUDO userdel 
$opts\' || true
+   eval flock -x -w 100 $rootdir${sysconfdir} -c \"$PSEUDO userdel 
\$opts\" || true
user_exists="`grep "^$username:" $rootdir/etc/passwd || true`"
if test "x$user_exists" != "x"; then
bbfatal "${PN}: userdel command did not succeed."
@@ -121,7 +121,7 @@ perform_groupmod () {
local groupname=`echo "$opts" | awk '{ print $NF }'`
local group_exists="`grep "^$groupname:" $rootdir/etc/group || true`"
   

[OE-core] [PATCH 1/2] extrausers.bbclass: drop retry count for perform_user/group* calls

[Mark Asselstine]

Commit 2ebf697b46c42cee8bfa6d2e6087397f8cce385c [useradd_base.bbclass:
replace retry logic with flock] dropped the 3rd (retry) parameter for
these functions. These are simply being ignored now but we should
remove the retry count to avoid confusion.

Signed-off-by: Mark Asselstine 
---
 meta/classes/extrausers.bbclass | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/classes/extrausers.bbclass b/meta/classes/extrausers.bbclass
index faf57b1..43900f3 100644
--- a/meta/classes/extrausers.bbclass
+++ b/meta/classes/extrausers.bbclass
@@ -33,22 +33,22 @@ set_user_group () {
# this setting is actually a serial process. So we only retry 
once.
case $cmd in
useradd)
-   perform_useradd "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts" 1
+   perform_useradd "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts"
;;
groupadd)
-   perform_groupadd "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts" 1
+   perform_groupadd "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts"
;;
userdel)
-   perform_userdel "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts" 1
+   perform_userdel "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts"
;;
groupdel)
-   perform_groupdel "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts" 1
+   perform_groupdel "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts"
;;
usermod)
-   perform_usermod "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts" 1
+   perform_usermod "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts"
;;
groupmod)
-   perform_groupmod "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts" 1
+   perform_groupmod "${IMAGE_ROOTFS}" "-R 
${IMAGE_ROOTFS} $opts"
;;
*)
bbfatal "Invalid command in EXTRA_USERS_PARAMS: 
$cmd"
-- 
2.1.4

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

Re: [OE-core] [PATCH] openssl: add a vardeps for configure on libdir

[Mark Asselstine]

On March 25, 2015 20:37:51 Mark Asselstine wrote:
> On March 25, 2015 20:44:57 Burton, Ross wrote:
> > On 25 March 2015 at 16:28, Mark Asselstine 
> > 
> > wrote:
> > > For target builds libdir is not something that changes and for -native
> > > builds unless you move your builds around you will see no issue with
> > > the current implementation. If you do update libdir or if you move
> > > your build or reuse sstate by copying it to a new build you will start
> > > to see errors. These will be seen when you use the 'openssl' tool and
> > > look like the following:
> > > 
> > > WARNING: can't open config file: /home/build/bitbake_build/tmp/
> > > 
> > > sysroots/x86_64-linux/usr/lib/ssl/openssl.cnf
> > 
> > We don't generally require that native sstate is rebuilt when the build
> > directory changes, as otherwise you wouldn't be able to share native
> > sstate
> > between builds and users.  Instead, paths are munged where possible when
> > using sstate and wrapper scripts used to "fix" binaries.  Indeed
> > openssl.inc does this:
> > 
> > do_install_append_virtclass-native() {
> > 
> > create_wrapper ${D}${bindir}/openssl \
> > 
> > OPENSSL_CONF=${libdir}/ssl/openssl.cnf \
> > SSL_CERT_DIR=${libdir}/ssl/certs \
> > SSL_CERT_FILE=${libdir}/ssl/cert.pem \
> > OPENSSL_ENGINES=${libdir}/ssl/engines
> > 
> > }
> > 
> > Is it possible that the binary isn't respecting the OPENSSL_CONF
> > environment variable since that wrapper was written? (or the wrapper
> > wasn't
> > tested well enough)
> 
> Interesting. Thanks for the heads up Ross I can definitely look at the
> wrapper for possible issues.

Ross,

This is exactly the clue I needed. With this I was able to determine the flaw 
in my analysis. Things are working as expected, my patch is not needed.

Sorry for the noise. Thanks Ross and Christopher for the guidance,
Mark

> 
> Mark
> 
> > Ross

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