Re: [yocto] [PATCH 00/12] [auh] make it easy to use by recipe maintainer

2017-12-06 Thread Robert Yang

I had added alexander.kana...@linux.intel.com in the cc list, but it was gone,
looks strange, now add him again.

// Robert

On 12/07/2017 03:37 PM, Robert Yang wrote:

* Usages: (No settings is required by default)
   - Upgrade one recipe:
 $ upgradehelper.py less

   - Upgrade multiple recipes:
 $ upgradehelper.py less bash

 The commit will be kept in the repo when *succeed*.
 No commit when *failed* by default unless -f is used.

   - Upgrade recipes and apply failed patches after the upgrade is done:
 $ upgradehelper.py less bash -f

   - Upgrade all recipes and send emails:
 $ upgradehelper.py all -e

* Next:
   - Auto fix do_fetch error when thera are more than one checksums, e.g., git 
repo.
   - Add it into oe-core and suggest maintainer uses it ?

// Robert

The following changes since commit ccf93239c7def7b475fe20f8fcd91043bc59bd61:

   upgradehelper.py: Layer mode do a full cleanup of poky (2017-06-05 16:14:23 
-0500)

are available in the git repository at:

   git://git.pokylinux.org/poky-contrib rbt/auh
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rbt/auh

Robert Yang (12):
   upgradehelper.py: fix checking for do_checkpkg
   upgradehelper.py: support upgrade multiple recipes
   upgradehelper.py: use UniverseUpdater for all cases
   modules/steps.py: fix warn when skip compilation
   modules/steps.py: fix warn when skip compilation
   upgradehelper.py: only check email settings when -e is specified
   upgradehelper.py: always do upgrade when recipes are specified
   upgradehelper.py: clean repo only once when recipes are specified
   upgradehelper.py: use git user in commit when recipes are specified
   upgradehelper.py: add --apply-failed option
   upgradehelper.py: print info when recipe is skipped to upgrade
   upgradehelper.py: don't build gcc-runtime when --skip-compilation

  modules/steps.py |   4 --
  upgradehelper.py | 118 ++-
  2 files changed, 73 insertions(+), 49 deletions(-)


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 11/12] upgradehelper.py: print info when recipe is skipped to upgrade

2017-12-06 Thread Robert Yang
This makes debug easier.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 3ad33ae..c099445 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -826,11 +826,11 @@ class UniverseUpdater(Updater):
 pkgs_list.append((pn, next_ver, maintainer))
 else:
 if no_upgrade_reason:
-D(" Skip package %s (status = %s, current version = 
%s," \
+I(" Skip package %s (status = %s, current version = 
%s," \
 " next version = %s, no upgrade reason = %s)" %
 (pn, status, cur_ver, next_ver, no_upgrade_reason))
 else:
-D(" Skip package %s (status = %s, current version = 
%s," \
+I(" Skip package %s (status = %s, current version = 
%s," \
 " next version = %s)" %
 (pn, status, cur_ver, next_ver))
 return pkgs_list
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 10/12] upgradehelper.py: add --apply-failed option

2017-12-06 Thread Robert Yang
  -f, --apply-failedApply failed patch in the repo after upgrade is done

And add "FAILED:" in subject when failed. So that the user can go on
working based on the commit.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 0678c58..3ad33ae 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -94,6 +94,8 @@ def parse_cmdline():
 help="do not compile, just change the checksums, 
remove PR, and commit")
 parser.add_argument("-c", "--config-file", default=None,
 help="Path to the configuration file. Default is 
$BUILDDIR/upgrade-helper/upgrade-helper.conf")
+parser.add_argument("-f", "--apply-failed", action="store_true", 
default=False,
+help="Apply failed patch in the repo after upgrade is 
done")
 return parser.parse_args()
 
 def parse_config_file(config_file):
@@ -407,7 +409,10 @@ class Updater(object):
 
 if 'recipe' in pkg_ctx:
 I(" %s: Auto commit changes ..." % pkg_ctx['PN'])
-commit_msg = pkg_ctx['recipe'].commit_msg
+if pkg_ctx['error']:
+commit_msg = "FAILED: %s" % pkg_ctx['recipe'].commit_msg
+else:
+commit_msg = pkg_ctx['recipe'].commit_msg
 if self.recipes:
 self.git.commit(commit_msg)
 else:
@@ -655,6 +660,11 @@ class Updater(object):
 pkg_ctx['MAINTAINER'], pkg_ctx['error'])
 self.pkg_upgrade_handler(pkg_ctx)
 
+if self.args.apply_failed and pkg_ctx in failed_pkgs_ctx:
+if pkg_ctx['patch_file']:
+I(" %s: Applying failed patch" % pn)
+self.git.apply_patch(pkg_ctx['patch_file'])
+
 if attempted_pkgs > 0:
 publish_work_url = settings.get('publish_work_url', '')
 work_tarball = os.path.join(self.uh_base_work_dir,
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 09/12] upgradehelper.py: use git user in commit when recipes are specified

2017-12-06 Thread Robert Yang
E.g.,:
$ upgradehelper.py less

commit d9b551438037e105eebabbbcb2da6d8b8cae7504
Author: Robert Yang 
Date:   Wed Dec 6 16:38:55 2017 +0800

less: upgrade to 529

Signed-off-by: Robert Yang 

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index ff27b97..0678c58 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -407,7 +407,11 @@ class Updater(object):
 
 if 'recipe' in pkg_ctx:
 I(" %s: Auto commit changes ..." % pkg_ctx['PN'])
-self.git.commit(pkg_ctx['recipe'].commit_msg, 
self.opts['author'])
+commit_msg = pkg_ctx['recipe'].commit_msg
+if self.recipes:
+self.git.commit(commit_msg)
+else:
+self.git.commit(commit_msg, self.opts['author'])
 
 stdout = self.git.create_patch(pkg_ctx['workdir'])
 pkg_ctx['patch_file'] = stdout.strip()
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 08/12] upgradehelper.py: clean repo only once when recipes are specified

2017-12-06 Thread Robert Yang
E.g.:
$ upgradehelper.py less strace bash git

The commit is removed when failed, and kept when succeed, but it would be
removed when next recipe runs, so only run clean_repo once can keep the commit,
which is helpful for the user.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 12 
 1 file changed, 12 insertions(+)

diff --git a/upgradehelper.py b/upgradehelper.py
index e38a281..ff27b97 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -57,6 +57,7 @@ from utils.emailhandler import Email
 from statistics import Statistics
 from steps import upgrade_steps
 from steps import compile
+from steps import clean_repo
 from testimage import TestImage
 
 help_text = """Usage examples:
@@ -419,6 +420,10 @@ class Updater(object):
 else:
 I(" %s: Save patch in directory: %s." %
 (pkg_ctx['PN'], pkg_ctx['workdir']))
+if pkg_ctx['error']:
+I(" %s: Remove it from repo since failed!" % 
pkg_ctx['PN'])
+self.git.reset_hard(1)
+
 except Error as e:
 msg = ''
 
@@ -569,6 +574,7 @@ class Updater(object):
 succeeded_pkgs_ctx = []
 failed_pkgs_ctx = []
 attempted_pkgs = 0
+repo_cleaned = False
 for pn, _, _ in pkgs_to_upgrade:
 pkg_ctx = pkgs_ctx[pn]
 pkg_ctx['error'] = None
@@ -581,6 +587,12 @@ class Updater(object):
 if step == compile and self.args.skip_compilation:
 W(" %s: Skipping compile by user choice" % 
pkg_ctx['PN'])
 continue
+if step == clean_repo and self.recipes:
+if repo_cleaned:
+I(" %s: Skipping clean_repo since it had been run 
by previous recipe" % pkg_ctx['PN'])
+continue
+else:
+repo_cleaned = True
 if msg is not None:
 I(" %s: %s" % (pkg_ctx['PN'], msg))
 step(self.bb, self.git, self.opts, pkg_ctx)
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 07/12] upgradehelper.py: always do upgrade when recipes are specified

2017-12-06 Thread Robert Yang
For example, first run:
$ upgradehelper.py less -d 5
It did the upgrade

Second run:
$ upgradehelper.py less -d 5
DEBUG: Skipping upgrade of less: is in history and not 30 days passed

Let it always do the upgrade makes it easier to use when do upgrade locally.
It will still do the check when the recipe is all.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 70b9e8d..e38a281 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -879,7 +879,7 @@ class UniverseUpdater(Updater):
 if not os.path.exists(last_checkpkg_file):
 last_checkpkg_file = None
 
-if last_master_commit != cur_master_commit or last_date_checked != 
current_date or \
+if self.recipes or last_master_commit != cur_master_commit or 
last_date_checked != current_date or \
 last_checkpkg_file is None:
 self._check_upstream_versions()
 last_checkpkg_file = os.path.realpath(get_build_dir() + 
"/tmp/log/checkpkg.csv")
@@ -889,7 +889,10 @@ class UniverseUpdater(Updater):
 
 pkgs_list = []
 for pkg in self._parse_checkpkg_file(last_checkpkg_file):
-if self._pkg_upgradable(pkg[0], pkg[1], pkg[2]):
+# Always do the upgrade if recipes are specified
+if self.recipes and pkg[0] in self.recipes:
+pkgs_list.append(pkg)
+elif self._pkg_upgradable(pkg[0], pkg[1], pkg[2]):
 pkgs_list.append(pkg)
 
 # Update last_checkpkg_run only after the version check has been 
completed
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 03/12] upgradehelper.py: use UniverseUpdater for all cases

2017-12-06 Thread Robert Yang
* Use UniverseUpdater() for the following 3 cases:
  + Upgrade all recipes
  + Upgrade 1 recipe
- '--maintainer' is not a must when any more when use --send-emails, the
  maintainer be got from distrodata.
  + Upgrade multiple recipes

* Use "args" as the parameter of UniverseUpdater() and Updater(), this can make
  the parameters simple, and easy for extending.

* Make upgrade "all" recipes respect the args, it didn't care --send-emails or
  --maintainer which would suprise the user.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 68 +---
 1 file changed, 30 insertions(+), 38 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 220e459..4a3f3f0 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -128,10 +128,11 @@ def parse_config_file(config_file):
 return (settings, maintainer_override)
 
 class Updater(object):
-def __init__(self, auto_mode=False, send_email=False, 
skip_compilation=False):
+def __init__(self, args):
 build_dir = get_build_dir()
 
 self.bb = Bitbake(build_dir)
+self.args = args
 
 try:
 self.base_env = self.bb.env()
@@ -141,7 +142,7 @@ class Updater(object):
 E( " Bitbake output:\n%s" % (e.stdout))
 exit(1)
 
-self._set_options(auto_mode, send_email, skip_compilation)
+self._set_options()
 
 self._make_dirs(build_dir)
 
@@ -150,7 +151,7 @@ class Updater(object):
 self.email_handler = Email(settings)
 self.statistics = Statistics()
 
-def _set_options(self, auto_mode, send_email, skip_compilation):
+def _set_options(self):
 self.opts = {}
 self.opts['layer_mode'] = settings.get('layer_mode', '')
 if self.opts['layer_mode'] == 'yes':
@@ -174,11 +175,11 @@ class Updater(object):
 self.opts['machines'] = settings.get('machines',
 'qemux86 qemux86-64 qemuarm qemumips qemuppc').split()
 
-self.opts['interactive'] = not auto_mode
-self.opts['send_email'] = send_email
+self.opts['interactive'] = not self.args.auto_mode
+self.opts['send_email'] = self.args.send_emails
 self.opts['author'] = "Upgrade Helper <%s>" % \
 settings.get('from', 'u...@not.set')
-self.opts['skip_compilation'] = skip_compilation
+self.opts['skip_compilation'] = self.args.skip_compilation
 self.opts['buildhistory'] = self._buildhistory_is_enabled()
 self.opts['testimage'] = self._testimage_is_enabled()
 
@@ -659,17 +660,25 @@ class Updater(object):
 self.send_status_mail(statistics_summary)
 
 class UniverseUpdater(Updater):
-def __init__(self, recipes=None):
-Updater.__init__(self, True, True)
+def __init__(self, args):
+Updater.__init__(self, args)
+
+if len(args.recipe) == 1 and args.recipe[0] == "all":
+self.recipes = []
+else:
+self.recipes = args.recipe
 
 # to filter recipes in upgrade
-if not recipes and self.opts['layer_mode'] == 'yes':
+if not self.recipes and self.opts['layer_mode'] == 'yes':
 # when layer mode is enabled and no recipes are specified
 # we need to figure out what recipes are provided by the
 # layer to try upgrade
 self.recipes = self._get_recipes_by_layer()
-else:
-self.recipes = recipes
+
+if args.to_version:
+if len(self.recipes) != 1:
+E(" -t is only supported when upgrade one recipe\n")
+exit(1)
 
 # read history file
 self.history_file = os.path.join(get_build_dir(), "upgrade-helper", 
"history.uh")
@@ -772,9 +781,15 @@ class UniverseUpdater(Updater):
 
 pn = row[0]
 cur_ver = row[1]
-next_ver = row[2]
+if self.args.to_version:
+next_ver = self.args.to_version
+else:
+next_ver = row[2]
 status = row[11]
-maintainer = row[14]
+if self.args.maintainer:
+maintainer = self.args.maintainer
+else:
+maintainer = row[14]
 no_upgrade_reason = row[15]
 
 if status == 'UPDATE' and not no_upgrade_reason:
@@ -928,28 +943,5 @@ if __name__ == "__main__":
 level=debug_levels[args.debug_level - 1])
 settings, maintainer_override = parse_config_file(args.config_file)
 
-recipes = args.recipe
-
-if len(recipes) == 1 and recipes[0] == "all":
-updater = UniverseUpdater()
-updater.run()
-elif len(recipes) == 1 and args.to_version:
-if not args.maintainer and args.send_emails:
-E(" For upgrade one recipe and send email you must specify 
--maintainer\n")
-exit(1)
-
-

[yocto] [PATCH 05/12] modules/steps.py: fix warn when skip compilation

2017-12-06 Thread Robert Yang
* The previous code lacks a "% var" in the end:
  W(" %s: Compilation was skipped by user choice!")

* Move the skipping steps to upgradehelper.py rather than
  modules/steps.py, do not run compile is more straight-forward  than
  return early from it when skipping.

Signed-off-by: Robert Yang 
---
 modules/steps.py | 4 
 upgradehelper.py | 7 +--
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/modules/steps.py b/modules/steps.py
index 677d101..c78cabc 100644
--- a/modules/steps.py
+++ b/modules/steps.py
@@ -136,10 +136,6 @@ def unpack_original_workdir(bb, git, opts, pkg_ctx):
 pass
 
 def compile(bb, git, opts, pkg_ctx):
-if opts['skip_compilation']:
-W(" %s: Compilation was skipped by user choice!" % pkg_ctx['PN'])
-return
-
 for machine in opts['machines']:
 I(" %s: compiling for %s ..." % (pkg_ctx['PN'], machine))
 pkg_ctx['recipe'].compile(machine)
diff --git a/upgradehelper.py b/upgradehelper.py
index 4a3f3f0..605114b 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -56,6 +56,7 @@ from utils.emailhandler import Email
 
 from statistics import Statistics
 from steps import upgrade_steps
+from steps import compile
 from testimage import TestImage
 
 help_text = """Usage examples:
@@ -179,7 +180,6 @@ class Updater(object):
 self.opts['send_email'] = self.args.send_emails
 self.opts['author'] = "Upgrade Helper <%s>" % \
 settings.get('from', 'u...@not.set')
-self.opts['skip_compilation'] = self.args.skip_compilation
 self.opts['buildhistory'] = self._buildhistory_is_enabled()
 self.opts['testimage'] = self._testimage_is_enabled()
 
@@ -231,7 +231,7 @@ class Updater(object):
   " but need BUILDHISTORY_COMMIT=1 please set.")
 exit(1)
 
-if self.opts['skip_compilation']:
+if self.args.skip_compilation:
 W(" Buildhistory disabled because user" \
 " skip compilation!")
 else:
@@ -577,6 +577,9 @@ class Updater(object):
 try:
 I(" %s: Upgrading to %s" % (pkg_ctx['PN'], pkg_ctx['NPV']))
 for step, msg in upgrade_steps:
+if step == compile and self.args.skip_compilation:
+W(" %s: Skipping compile by user choice" % 
pkg_ctx['PN'])
+continue
 if msg is not None:
 I(" %s: %s" % (pkg_ctx['PN'], msg))
 step(self.bb, self.git, self.opts, pkg_ctx)
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 06/12] upgradehelper.py: only check email settings when -e is specified

2017-12-06 Thread Robert Yang
Fixed:
$ upgradehelper.py less
ERROR: smtp host not set! Sending emails disabled!
ERROR: 'From' address not set! Sending emails disabled!

Only check email settings when "-e" is specified can fix the problem.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 605114b..70b9e8d 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -149,7 +149,8 @@ class Updater(object):
 
 self._add_file_logger()
 
-self.email_handler = Email(settings)
+if self.args.send_emails:
+self.email_handler = Email(settings)
 self.statistics = Statistics()
 
 def _set_options(self):
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 04/12] modules/steps.py: fix warn when skip compilation

2017-12-06 Thread Robert Yang
Signed-off-by: Robert Yang 
---
 modules/steps.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/steps.py b/modules/steps.py
index 0c527a4..677d101 100644
--- a/modules/steps.py
+++ b/modules/steps.py
@@ -137,7 +137,7 @@ def unpack_original_workdir(bb, git, opts, pkg_ctx):
 
 def compile(bb, git, opts, pkg_ctx):
 if opts['skip_compilation']:
-W(" %s: Compilation was skipped by user choice!")
+W(" %s: Compilation was skipped by user choice!" % pkg_ctx['PN'])
 return
 
 for machine in opts['machines']:
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 02/12] upgradehelper.py: support upgrade multiple recipes

2017-12-06 Thread Robert Yang
Now we can use:
$ upgradehelper.py recipe1 recipe2

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index d439a4c..220e459 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -74,7 +74,7 @@ def parse_cmdline():
 parser = argparse.ArgumentParser(description='Package Upgrade Helper',
  
formatter_class=argparse.RawTextHelpFormatter,
  epilog=help_text)
-parser.add_argument("recipe", help="recipe to be upgraded")
+parser.add_argument("recipe", nargs = '+', action='store', default='', 
help="recipe to be upgraded")
 
 parser.add_argument("-t", "--to_version",
 help="version to upgrade the recipe to")
@@ -928,7 +928,7 @@ if __name__ == "__main__":
 level=debug_levels[args.debug_level - 1])
 settings, maintainer_override = parse_config_file(args.config_file)
 
-recipes = args.recipe.split()
+recipes = args.recipe
 
 if len(recipes) == 1 and recipes[0] == "all":
 updater = UniverseUpdater()
@@ -942,9 +942,12 @@ if __name__ == "__main__":
 args.maintainer = "Upgrade Helper <%s>" % \
 settings.get('from', 'u...@not.set')
 
-pkg_list = [(args.recipe, args.to_version, args.maintainer)]
+pkg_list = [(recipes[0], args.to_version, args.maintainer)]
 updater = Updater(args.auto_mode, args.send_emails, 
args.skip_compilation)
 updater.run(pkg_list)
+elif len(recipes) > 1 and args.to_version:
+E(" -t is only supported when upgrade one recipe\n")
+exit(1)
 else:
 updater = UniverseUpdater(recipes)
 updater.run()
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 01/12] upgradehelper.py: fix checking for do_checkpkg

2017-12-06 Thread Robert Yang
The error message in the log is:
Initialising tasks...ERROR: Task do_checkpkg does not exist for target strace 
[snip]

So line.find("ERROR: Task do_checkpkg does not exist") == 0 doesn't
work, use != -1 to fix the problem.

Signed-off-by: Robert Yang 
---
 upgradehelper.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 8e5466e..d439a4c 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -753,7 +753,7 @@ class UniverseUpdater(Updater):
 self.bb.checkpkg(recipe)
 except Error as e:
 for line in e.stdout.split('\n'):
-if line.find("ERROR: Task do_checkpkg does not exist") == 0:
+if line.find("ERROR: Task do_checkpkg does not exist") != -1:
 C(" \"distrodata.bbclass\" not inherited. Consider adding "
   "the following to your local.conf:\n\n"
   "INHERIT =+ \"distrodata\"\n")
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [PATCH 00/12] [auh] make it easy to use by recipe maintainer

2017-12-06 Thread Robert Yang
* Usages: (No settings is required by default)
  - Upgrade one recipe:
$ upgradehelper.py less

  - Upgrade multiple recipes:
$ upgradehelper.py less bash

The commit will be kept in the repo when *succeed*.
No commit when *failed* by default unless -f is used.

  - Upgrade recipes and apply failed patches after the upgrade is done:
$ upgradehelper.py less bash -f

  - Upgrade all recipes and send emails:
$ upgradehelper.py all -e

* Next:
  - Auto fix do_fetch error when thera are more than one checksums, e.g., git 
repo.
  - Add it into oe-core and suggest maintainer uses it ?

// Robert

The following changes since commit ccf93239c7def7b475fe20f8fcd91043bc59bd61:

  upgradehelper.py: Layer mode do a full cleanup of poky (2017-06-05 16:14:23 
-0500)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib rbt/auh
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rbt/auh

Robert Yang (12):
  upgradehelper.py: fix checking for do_checkpkg
  upgradehelper.py: support upgrade multiple recipes
  upgradehelper.py: use UniverseUpdater for all cases
  modules/steps.py: fix warn when skip compilation
  modules/steps.py: fix warn when skip compilation
  upgradehelper.py: only check email settings when -e is specified
  upgradehelper.py: always do upgrade when recipes are specified
  upgradehelper.py: clean repo only once when recipes are specified
  upgradehelper.py: use git user in commit when recipes are specified
  upgradehelper.py: add --apply-failed option
  upgradehelper.py: print info when recipe is skipped to upgrade
  upgradehelper.py: don't build gcc-runtime when --skip-compilation

 modules/steps.py |   4 --
 upgradehelper.py | 118 ++-
 2 files changed, 73 insertions(+), 49 deletions(-)

-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Build error: "u-boot-imx_2017.03.bb:do_compile" failed ( freescale I.MX 6 on Ubuntu 16.04) ?

2017-12-06 Thread Martin Jansa
I don't know what version of Yocto you're using, but if it's older than 2.3
(which does filter what binaries are seen from the host system with
HOSTTOOLS), then your build is probably autodetecting swig from host and
you can easily disable that with:

do_compile_prepend () {
sed 's@\(^always += $(if $(shell which swig 2>
/dev/null),_libfdt.so)$\)@# do not autodetect swig, there is no swig-native
dependency \1@g' -i ${S}/tools/Makefile
}

Then it won't try to rebuild libfdt python library and it won't fail.

On Thu, Dec 7, 2017 at 8:21 AM, Eric Schwarz 
wrote:

> Hello Jerry,
>
> U-Boot depends on Python but the dependency is not included in the U-Boot
> recipe AFAIK.
> I have already sent a patchset which was not complete at that time to the
> yocto mailinglist. Ross meant one needs to inherit from Python U-Boot class
> in the recipe not just include a dependency o/w it will not be in path.
> The error only comes up because you do not have Python installed on your
> system I think.
>
> Cheers
> Eric
>
> Am 06.12.2017 18:13, schrieb Jerry Lian:
>
> I got an error when trying to build for freescale I.MX6 on Ubuntu
>> 16.04.(see below)
>> (I just follow the guide from http://freescale.github.io)
>>
>> Anybody got hints?
>>
>> Thanks!
>>
>> Jerry
>>
>> ===
>> 
>> | tools/libfdt_wrap.c:147:21: fatal error: Python.h: No such file or
>> directory
>> | compilation terminated.
>> | error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
>> | /home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-
>> poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/tools/Makefile:123: recipe
>> for target 'tools/_libfdt.so' failed
>> | make[2]: *** [tools/_libfdt.so] Error 1
>> | /home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-
>> poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/Makefile:1229: recipe for
>> target 'tools' failed
>> | make[1]: *** [tools] Error 2
>> | make[1]: Leaving directory '/home/jerry/fsl-release-bsp/b
>> uild-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-
>> imx/2017.03-r0/build/mx6qsabresd_config'
>> | Makefile:150: recipe for target 'sub-make' failed
>> | make: *** [sub-make] Error 2
>> | make: Leaving directory '/home/jerry/fsl-release-bsp/b
>> uild-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-
>> imx/2017.03-r0/git'
>> | WARNING: exit code 1 from a shell command.
>> | ERROR: Function failed: do_compile (log file is located at
>> /home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-
>> poky-linux-gnueabi/u-boot-imx/2017.03-r0/temp/log.do_compile.9339)
>> ERROR: Task (/home/jerry/fsl-release-bsp/sources/meta-fsl-bsp-release/im
>> x/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb:do_compile) failed
>> with exit code '1'
>> NOTE: Tasks Summary: Attempted 4851 tasks of which 3009 didn't need to be
>> rerun and 1 failed.
>>
>> Summary: 1 task failed:
>> /home/jerry/fsl-release-bsp/sources/meta-fsl-bsp-release/imx
>> /meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb:do_compile
>> ..
>> 
>>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Build error: "u-boot-imx_2017.03.bb:do_compile" failed ( freescale I.MX 6 on Ubuntu 16.04) ?

2017-12-06 Thread Eric Schwarz

Hello Jerry,

U-Boot depends on Python but the dependency is not included in the 
U-Boot recipe AFAIK.
I have already sent a patchset which was not complete at that time to 
the yocto mailinglist. Ross meant one needs to inherit from Python 
U-Boot class in the recipe not just include a dependency o/w it will not 
be in path.
The error only comes up because you do not have Python installed on your 
system I think.


Cheers
Eric

Am 06.12.2017 18:13, schrieb Jerry Lian:

I got an error when trying to build for freescale I.MX6 on Ubuntu 
16.04.(see below)

(I just follow the guide from http://freescale.github.io)

Anybody got hints?

Thanks!

Jerry

===

| tools/libfdt_wrap.c:147:21: fatal error: Python.h: No such file or 
directory

| compilation terminated.
| error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
| 
/home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/tools/Makefile:123: 
recipe for target 'tools/_libfdt.so' failed

| make[2]: *** [tools/_libfdt.so] Error 1
| 
/home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/Makefile:1229: 
recipe for target 'tools' failed

| make[1]: *** [tools] Error 2
| make[1]: Leaving directory 
'/home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/build/mx6qsabresd_config'

| Makefile:150: recipe for target 'sub-make' failed
| make: *** [sub-make] Error 2
| make: Leaving directory 
'/home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git'

| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at 
/home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/temp/log.do_compile.9339)
ERROR: Task 
(/home/jerry/fsl-release-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb:do_compile) 
failed with exit code '1'
NOTE: Tasks Summary: Attempted 4851 tasks of which 3009 didn't need to 
be rerun and 1 failed.


Summary: 1 task failed:
/home/jerry/fsl-release-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb:do_compile
..


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[linux-yocto] [PATCH] common-pc*.scc: Add igb to common-pc drivers

2017-12-06 Thread Saul Wold
The IGB driver is showing up on some general hardware (like MinnowBoard)
which is one of the Yocto Project Reference Platforms.

Signed-off-by: Saul Wold 
---

Bruce, this is for 4.9 and newer.  Thanks!

 bsp/common-pc-64/common-pc-64.scc | 1 +
 bsp/common-pc/common-pc.scc   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/bsp/common-pc-64/common-pc-64.scc 
b/bsp/common-pc-64/common-pc-64.scc
index d9d41c1c..5d30c731 100644
--- a/bsp/common-pc-64/common-pc-64.scc
+++ b/bsp/common-pc-64/common-pc-64.scc
@@ -20,6 +20,7 @@ include features/usb/touchscreen-composite.scc
 include features/usb-net/usb-net.scc
 include features/intel-e1/intel-e100.scc
 include features/intel-e1/intel-e1.scc
+include features/igb/igb.scc
 include features/scsi/cdrom.scc
 
 # generic Bluetooth support
diff --git a/bsp/common-pc/common-pc.scc b/bsp/common-pc/common-pc.scc
index 384ffbad..cd947b0f 100644
--- a/bsp/common-pc/common-pc.scc
+++ b/bsp/common-pc/common-pc.scc
@@ -21,11 +21,11 @@ include features/usb/xhci-hcd.scc
 include features/usb/touchscreen-composite.scc
 
 include features/usb-net/usb-net.scc
-
 include features/intel-e1/intel-e100.scc
 include features/intel-e1/intel-e1.scc
 include features/iwlwifi/iwlwifi.scc
 include features/iwlegacy/iwlegacy.scc
+include features/igb/igb.scc
 
 include features/i915/i915.scc
 include features/drm-gma500/drm-gma500.scc
-- 
2.13.6

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [yocto] tiny-linux distribution with raspberrypi error

2017-12-06 Thread Sherif Omran
i tried the following
bitbake -c clean rpi-basic-image (to clean the build)

added the following to the local


IMAGE_FSTYPES_append = " rpi-sdimg" => when i copied the text from the
email, it gave class unavailable and then i found that there is a hidden
character before the end quotes from another language. By writing it, it
worked.

thank you






On Thu, Dec 7, 2017 at 6:45 AM, Sherif Omran 
wrote:

> I trid the rpi-sdimg as mentioned but i get IMAGE_CMD defined for
> IMAGE_FSTYOE entry 'rpi-sdimg' possibly invalid type name or missing
> support class.
> any idea how to create the rpi image.
>
> On Sun, Nov 19, 2017 at 2:59 AM, Khem Raj  wrote:
>
>> I think you can generate a SD card image which can be dd’ed into a sd card
>> ​poky tiny by default generates an initramfs image only. ​
>> ​
>> ​you can add
>>
>> IMAGE_FSTYPES_append = " rpi-sdimg​"
>>
>> ​in local.conf and see if you get a rpi-sdimag​
>>
>>
>>
>> On Sat, Nov 18, 2017 at 10:47 AM Sherif Omran 
>> wrote:
>>
>>> I have it now being compiled and created a file called
>>> rpi-basic-image-raspberrypi0-wifi-20171118102213.rootfs.cpio.gz
>>> but how can i burn it? it is not an img file.
>>> Any clue is appreciated.
>>>
>>> On Sat, Nov 18, 2017 at 12:21 PM, Sherif Omran <
>>> sherifomran2...@gmail.com> wrote:
>>>
 it worked well with

 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tini"

 in local.conf. However i don't know if it will work with real time
 kernel .. to be tested later

  thank you

 On Sat, Nov 18, 2017 at 10:19 AM, Khem Raj  wrote:

> On Fri, Nov 17, 2017 at 5:34 PM, Michael Gloff 
> wrote:
> > This looks to be because poky-tiny.conf does not allow overriding of
> the
> > kernel provider. You could try the below patch to use a different
> kernel.
> >
> > Michael Gloff
> >
> > diff --git a/meta-poky/conf/distro/poky-tiny.conf
> > b/meta-poky/conf/distro/poky-tiny.conf
> > index 2032bfde32..acafd9fef4 100644
> > --- a/meta-poky/conf/distro/poky-tiny.conf
> > +++ b/meta-poky/conf/distro/poky-tiny.conf
> > @@ -37,7 +37,7 @@ TCLIBC = "musl"
> >
> >  # Distro config is evaluated after the machine config, so we have to
> > explicitly
> >  # set the kernel provider to override a machine config.
> > -PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
> > +PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-tiny"
> >  PREFERRED_VERSION_linux-yocto-tiny ?= "4.12%"
> >
>
> please submit this patch with sign off and git format, its good for
> inclusion upstream
>
> >  # We can use packagegroup-core-boot, but in the future we may need
> a new
> > packagegroup-core-tiny
> >
> >
> > On Thu, Nov 16, 2017 at 7:05 PM, Sherif Omran <
> sherifomran2...@gmail.com>
> > wrote:
> >>
> >> hi
> >>
> >> i am trying to compile the yocto-tiny for raspberry pi by adding the
> >> distro to my local.conf
> >>
> >> DISTRO = "poky-tiny"  and i  get the following
> >>
> >>
> >> ERROR: nothing provides 'virtual/kernel'
> >> ERROR: linux-yocto-tiny Provides virtual/kernel but was skipped:
> >> incompatible with machine raspberrypi0-wifi (not in
> compatible_machine)
> >> ERROR: linux-yocto-rt Provides virtual/kernel but was skipped:
> >> incompatible with machine raspberrypi0-wifi (not in
> compatible_machine)
> >> ERROR: linux-yocto Provides virtual/kernel but was skipped:
> incompatible
> >> with machine raspberrypi0-wifi (not in compatible_machine)
> >> ERROR: linux-yocto-dev Provides virtual/kernel but was skipped:
> >> incompatible with machine raspberrypi0-wifi (not in
> compatible_machine)
> >> ERROR: required build target 'rpi-basic-image' has no buildable
> providers.
> >> Missing or unbuildable depency chain was: 'rpi-basic-image',
> >> 'virtual/kernel'
> >>
> >>
> >> any body has a clue to solve it?
> >>
> >> thanks
> >>
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >>
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>


>>>
>>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] tiny-linux distribution with raspberrypi error

2017-12-06 Thread Sherif Omran
I trid the rpi-sdimg as mentioned but i get IMAGE_CMD defined for
IMAGE_FSTYOE entry 'rpi-sdimg' possibly invalid type name or missing
support class.
any idea how to create the rpi image.

On Sun, Nov 19, 2017 at 2:59 AM, Khem Raj  wrote:

> I think you can generate a SD card image which can be dd’ed into a sd card
> ​poky tiny by default generates an initramfs image only. ​
> ​
> ​you can add
>
> IMAGE_FSTYPES_append = " rpi-sdimg​"
>
> ​in local.conf and see if you get a rpi-sdimag​
>
>
>
> On Sat, Nov 18, 2017 at 10:47 AM Sherif Omran 
> wrote:
>
>> I have it now being compiled and created a file called
>> rpi-basic-image-raspberrypi0-wifi-20171118102213.rootfs.cpio.gz
>> but how can i burn it? it is not an img file.
>> Any clue is appreciated.
>>
>> On Sat, Nov 18, 2017 at 12:21 PM, Sherif Omran > > wrote:
>>
>>> it worked well with
>>>
>>> PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tini"
>>>
>>> in local.conf. However i don't know if it will work with real time
>>> kernel .. to be tested later
>>>
>>>  thank you
>>>
>>> On Sat, Nov 18, 2017 at 10:19 AM, Khem Raj  wrote:
>>>
 On Fri, Nov 17, 2017 at 5:34 PM, Michael Gloff 
 wrote:
 > This looks to be because poky-tiny.conf does not allow overriding of
 the
 > kernel provider. You could try the below patch to use a different
 kernel.
 >
 > Michael Gloff
 >
 > diff --git a/meta-poky/conf/distro/poky-tiny.conf
 > b/meta-poky/conf/distro/poky-tiny.conf
 > index 2032bfde32..acafd9fef4 100644
 > --- a/meta-poky/conf/distro/poky-tiny.conf
 > +++ b/meta-poky/conf/distro/poky-tiny.conf
 > @@ -37,7 +37,7 @@ TCLIBC = "musl"
 >
 >  # Distro config is evaluated after the machine config, so we have to
 > explicitly
 >  # set the kernel provider to override a machine config.
 > -PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
 > +PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-tiny"
 >  PREFERRED_VERSION_linux-yocto-tiny ?= "4.12%"
 >

 please submit this patch with sign off and git format, its good for
 inclusion upstream

 >  # We can use packagegroup-core-boot, but in the future we may need a
 new
 > packagegroup-core-tiny
 >
 >
 > On Thu, Nov 16, 2017 at 7:05 PM, Sherif Omran <
 sherifomran2...@gmail.com>
 > wrote:
 >>
 >> hi
 >>
 >> i am trying to compile the yocto-tiny for raspberry pi by adding the
 >> distro to my local.conf
 >>
 >> DISTRO = "poky-tiny"  and i  get the following
 >>
 >>
 >> ERROR: nothing provides 'virtual/kernel'
 >> ERROR: linux-yocto-tiny Provides virtual/kernel but was skipped:
 >> incompatible with machine raspberrypi0-wifi (not in
 compatible_machine)
 >> ERROR: linux-yocto-rt Provides virtual/kernel but was skipped:
 >> incompatible with machine raspberrypi0-wifi (not in
 compatible_machine)
 >> ERROR: linux-yocto Provides virtual/kernel but was skipped:
 incompatible
 >> with machine raspberrypi0-wifi (not in compatible_machine)
 >> ERROR: linux-yocto-dev Provides virtual/kernel but was skipped:
 >> incompatible with machine raspberrypi0-wifi (not in
 compatible_machine)
 >> ERROR: required build target 'rpi-basic-image' has no buildable
 providers.
 >> Missing or unbuildable depency chain was: 'rpi-basic-image',
 >> 'virtual/kernel'
 >>
 >>
 >> any body has a clue to solve it?
 >>
 >> thanks
 >>
 >> --
 >> ___
 >> yocto mailing list
 >> yocto@yoctoproject.org
 >> https://lists.yoctoproject.org/listinfo/yocto
 >>
 >
 >
 > --
 > ___
 > yocto mailing list
 > yocto@yoctoproject.org
 > https://lists.yoctoproject.org/listinfo/yocto
 >

>>>
>>>
>>
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[linux-yocto] [kernel-cache][yocto-4.12][V2][PATCH 1/1] features/i915/i915.cfg: compile i915 as a module

2017-12-06 Thread Liwei Song
Set i915 as a module to trigger the firmware load
at the same time the module is loaded.

This can avoid a timing problem between the driver starting
and it triggering a firmware load, after compile it as module
i915 driver will start after the rootfs is ready, then the
firmware store in /lib/firmware/ can be load successful by
i915 driver.

Signed-off-by: Liwei Song 
---
 features/i915/i915.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/features/i915/i915.cfg b/features/i915/i915.cfg
index 6dcc60f2dfc7..60cb963e014b 100644
--- a/features/i915/i915.cfg
+++ b/features/i915/i915.cfg
@@ -8,6 +8,6 @@ CONFIG_AGP=y
 CONFIG_AGP_INTEL=y
 CONFIG_DRM=y
 CONFIG_DRM_KMS_HELPER=y
-CONFIG_DRM_I915=y
+CONFIG_DRM_I915=m
 CONFIG_DRM_KMS_FB_HELPER=y
 CONFIG_DRM_I915_ALPHA_SUPPORT=y
-- 
2.7.4

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [linux-yocto] [kernel-cache][yocto-4.12][PATCH] features/i915/i915.cfg: compile i915 as a module

2017-12-06 Thread Liwei Song


On 12/06/2017 09:03 PM, Bruce Ashfield wrote:
> On 12/05/2017 09:10 PM, Liwei Song wrote:
>>
>>
>> On 12/06/2017 06:26 AM, Bruce Ashfield wrote:
>>> On 12/04/2017 08:16 PM, Liwei Song wrote:
 Set i915 as a moudle to trigger the firmware load
>>>
>>> typo: module
>>>
 at the same time the module is loaded.

 This can aviod i915 driver load rootfs's firmware before
 rootfs was mounted error.
>>>
>>> I'm not following this problem description, can you rephrase ?
>>> Is it a timing problem between the driving starting (as the
>>> built in) and it triggering a firmware load (that fails due
>>> to the rootfs not being ready) ?
>>
>> Yes, it is a timing problem, how about rephrase it as following:
>>
>> This can aviod a timing problem between the driver starting
> 
> s/aviod/avoid/
> 
>> and it triggering a firmware load, after compile it as module
>> i915 driver will start after the rootfs is ready, then the
>> firmware store in /lib/firmware/ can be load successful by
>> i915 driver.
>>
> 
> But yes, that log is good for a v2.
> 
>>  
>>>
>>> presumably the i915 was built in for a reason, i.e. so it
>>> is available in early boot without the need to load a module.
>>> And this change would break that functionality. Also, are
>>> there any other build settings that need to arrange for the
>>> module autoload ?
>>
>> I suppose no during my test on board.
> 
> So the device is likely triggering the module auto-load
> via the helper ? It would be good to fully understand this part,
> since it also means that any initramfs needs the module.
> 
> What type of boot are you doing for the test ? Is there an
> initramfs/initrd involved ?

I have test the hdd image before you ask, but did not test initramfs/initrd.
But now I also test it with initramfs, the i915 module also can be auto-load
by device trigger it. If we do not have i915 device, the module won't be loaded 
either.


Thanks,
Liwei.

> 
> Bruce
> 
>>
>> Thanks,
>> Liwei.
>>
>>
>>>
>>> Since there is that possibility, restating the problem you are
>>> trying to fix would be good.
>>>
>>> Bruce
>>>

 Signed-off-by: Liwei Song 
 ---
features/i915/i915.cfg | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/features/i915/i915.cfg b/features/i915/i915.cfg
 index 6dcc60f2dfc7..60cb963e014b 100644
 --- a/features/i915/i915.cfg
 +++ b/features/i915/i915.cfg
 @@ -8,6 +8,6 @@ CONFIG_AGP=y
CONFIG_AGP_INTEL=y
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
 -CONFIG_DRM_I915=y
 +CONFIG_DRM_I915=m
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_I915_ALPHA_SUPPORT=y

>>>
>>>
>>>
> 
> 
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


[yocto] Q: Kernel SCC files: shouldn't a changed patch trigger a rebuild?

2017-12-06 Thread Erwin Rieger

Hello list,

i have written a kernel recipe derived from linux-yocto-custom. The
SRC_URI includes a SCC file that in turn includes a kernel patch.

First of all, this works as expected, the patch is applied to the kernel
source and my custom kernel is built.

But the kernel is NOT rebuilt if i modify the kernel patch (without
touching the SCC file). In other words: changed files that are directly
named in the SRC_URI variable trigger a rebuild, but indirectly included
changed input files (through a SCC file) do not.

Is this the intended behaviour?


PS: 
I can provide more info and my test files if needed.






-- 
Mit freundlichen Gruessen Erwin Rieger


| Ingenieurbuero Rieger, Software Entwicklung
| EMail: erwin.rie...@ibrieger.de



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [poky-tiny] [meta-raspberry] Create rpi-img from generated cpio archive

2017-12-06 Thread Sherif Omran
hi yocto community,

i have been testing the poky-tiny with meta-raspberry pi, i successfully
compiled the kernel and all the underlying components, but the output is a
cpio archive.

However, the rpi-image has 2 partitions, a windows and linux partition. I
am now stopping at this point, where i need to generate the rpi-image
instead of the cpio.

any help is apprecitated, thanks in advance

regards,
Sherif
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] externalsrc + sstate why is not compatible?

2017-12-06 Thread Marcelo E. Magallon
On Wed, Dec 06, 2017 at 10:59:37AM -0600, Koehler, Yannick wrote:
> Ok, will try that.  If that works, I may see if I can alter the file
> fetcher to use symlinks, not sure if sstate subsystem will like that
> or not.

That was my idea, but I've never tried it. I'm sure the devil is in the
details. If you can elide the copy and simply replace it with a symlink,
you'd get faster builds.

> If we do so, and someone change the file in /src/somedir will yocto
> redo the fetch/unpack pattern to recopy over the original content by
> itself?

Yes, it does. You change a file, and the fetcher runs again. This means
S and B are deleted (if split), do_fetch runs again and S is populated
fresh. do_configure and do_compile populate B again.

Once you get that working, people will complain as to why the system is
rebuilding everything instead of just the file that changed :-) It might
work "as expected" if S = B, and your build system in the module is
smart enough to produce the correct dependencies (e.g. cmake or bazel).

Marcelo
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] externalsrc + sstate why is not compatible?

2017-12-06 Thread Koehler, Yannick
Ok, will try this...

In our case, we are using CMake for most user space app, and when developing 
purely app related stuff we can use cmake directly thru command-line or eclipse 
without actually having a need for yocto.  Yocto in this context only serve to 
build the final image artefact.  As such, CMake ensure that only the correct 
files gets generated and use its own build folder as well.  We also get the 
nice benefit of Live Debug with eclipse using the yocto sdk.

Based on that, the file fetcher copy (if recursive) may be enough for us, even 
more so when combining with ccache, which we also uses.

--
Yannick Koehler

-Message d'origine-
De : Magallon, Marcelo 
Envoyé : 6 décembre 2017 13:46
À : Koehler, Yannick 
Cc : Alexander Kanavin ; 
yocto@yoctoproject.org
Objet : Re: [yocto] externalsrc + sstate why is not compatible?

On Wed, Dec 06, 2017 at 10:59:37AM -0600, Koehler, Yannick wrote:
> Ok, will try that.  If that works, I may see if I can alter the file 
> fetcher to use symlinks, not sure if sstate subsystem will like that 
> or not.

That was my idea, but I've never tried it. I'm sure the devil is in the 
details. If you can elide the copy and simply replace it with a symlink, you'd 
get faster builds.

> If we do so, and someone change the file in /src/somedir will yocto 
> redo the fetch/unpack pattern to recopy over the original content by 
> itself?

Yes, it does. You change a file, and the fetcher runs again. This means S and B 
are deleted (if split), do_fetch runs again and S is populated fresh. 
do_configure and do_compile populate B again.

Once you get that working, people will complain as to why the system is 
rebuilding everything instead of just the file that changed :-) It might work 
"as expected" if S = B, and your build system in the module is smart enough to 
produce the correct dependencies (e.g. cmake or bazel).

Marcelo
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Allowing a local command to be executed in a recipe.

2017-12-06 Thread Alexander Kanavin

On 12/06/2017 07:55 PM, Paul Knopf wrote:

I have a local utility that is manually installed on our dev/build machines.

How do I configure Yocto to let me use this local command? It is located 
in /usr/local/bin.


Lets say the command is "my-command".



Write a recipe for the command, and include a "my-command-native" 
dependency into recipes that need it. Then no one has to manually 
install it.


(yes, yocto has a whitelist for host commands somewhere, but changing it 
is wrong)


Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Allowing a local command to be executed in a recipe.

2017-12-06 Thread Paul Knopf
I have a local utility that is manually installed on our dev/build machines.

How do I configure Yocto to let me use this local command? It is located in
/usr/local/bin.

Lets say the command is "my-command".
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] externalsrc + sstate why is not compatible?

2017-12-06 Thread Alexander Kanavin

On 12/06/2017 04:13 PM, Koehler, Yannick wrote:

When you say "subdirs", are you referring to submodules or something along 
those line?  We have used attempted to use submodules and it still required 20 + 1 repo 
and the overhead is similar to yocto + 20 repo but then you have yocto + 20 repos + 1 
main repos, as such, this is not acceptable for us.  We also looked at other combination 
of multiple repos supported or in work for git and none are satisfying or supported in a 
way I could propose to use it in our project.

If you mean 1 repo, which subdirs representing each package, I would be 
interested, but how would it work with yocto SRC_URI?


The latter. It's simple: you set SRC_URI in each recipe to the same 
value, but set S differently:


S = "${WORKDIR}/git/module-1"

S = "${WORKDIR}/git/module-2"

etc.

Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Build error: "u-boot-imx_2017.03.bb:do_compile" failed ( freescale I.MX 6 on Ubuntu 16.04) ?

2017-12-06 Thread Jerry Lian
I got an error when trying to build for freescale I.MX6 on Ubuntu
16.04.(see below)
(I just follow the guide from http://freescale.github.io)

Anybody got hints?

Thanks!
Jerry

===

| tools/libfdt_wrap.c:147:21: fatal error: Python.h: No such file or
directory
| compilation terminated.
| error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
|
/home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/tools/Makefile:123:
recipe for target 'tools/_libfdt.so' failed
| make[2]: *** [tools/_libfdt.so] Error 1
|
/home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git/Makefile:1229:
recipe for target 'tools' failed
| make[1]: *** [tools] Error 2
| make[1]: Leaving directory
'/home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/build/mx6qsabresd_config'
| Makefile:150: recipe for target 'sub-make' failed
| make: *** [sub-make] Error 2
| make: Leaving directory
'/home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/git'
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/home/jerry/fsl-release-bsp/build-x11/tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-imx/2017.03-r0/temp/log.do_compile.9339)
ERROR: Task
(/home/jerry/fsl-release-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb:do_compile)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 4851 tasks of which 3009 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:

/home/jerry/fsl-release-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb:
do_compile
..

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] externalsrc + sstate why is not compatible?

2017-12-06 Thread Koehler, Yannick
Ok, will try that.  If that works, I may see if I can alter the file fetcher to 
use symlinks, not sure if sstate subsystem will like that or not.

If we do so, and someone change the file in /src/somedir will yocto redo the 
fetch/unpack pattern to recopy over the original content by itself?

--
Yannick Koehler

-Message d'origine-
De : Magallon, Marcelo 
Envoyé : 6 décembre 2017 09:47
À : Koehler, Yannick 
Cc : Alexander Kanavin ; 
yocto@yoctoproject.org
Objet : Re: [yocto] externalsrc + sstate why is not compatible?

On Wed, Dec 06, 2017 at 02:13:26PM +, Koehler, Yannick wrote:

> In regards to file fetcher, I will go check the code, I thought the 
> unpack would only occurs for tarball, not subdir.

If you have:

SRC_URI := "file://some-dir/"

and your tree looks somewhat like this:

.git
poky
src/some-dir

and you set things up so that bitbake will look in src/ (set FILESPATH), then 
it will copy "some-dir" to $WORKDIR/some-dir, and you can point S there.

This satisfies your requirement as I understand it (single repo, all the source 
code is there, including poky).

The huge downside of this is that some-dir is copied and this confuses people.

I know the bitbake version in 2.4 has some differences that might help here, 
but I haven't had the chance to investigate further.

Marcelo
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [PATCH] yocto: matchbox-window-manager-2: Makefile with spaces instead of a tab refuses to compile

2017-12-06 Thread Burton, Ross
This patch was corrupted because you copied/pasted it into Thunderbird
instead of using git-send-email, but I applied it by hand.

Ross

On 19 November 2017 at 19:58, Petr Cvek  wrote:

> A wrong spacing in Makefile.am generates a Makefile which will refuse
> to compile. This patch fixes it.
>
> Signed-off-by: Petr Cvek 
> ---
>  Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index c95ea0a..7d2f517 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -3,6 +3,6 @@ SUBDIRS = matchbox data doc util
>  # Extra clean files so that maintainer-clean removes *everything*
>   snapshot:
> -$(MAKE) dist distdir=$(PACKAGE)-snapshot-`date +"%Y%m%d"`
> +   $(MAKE) dist distdir=$(PACKAGE)-snapshot-`date +"%Y%m%d"`
>   MAINTAINERCLEANFILES = aclocal.m4 compile config.guess config.sub
> configure depcomp install-sh ltmain.sh Makefile.in missing
> --
> 2.14.2
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] externalsrc + sstate why is not compatible?

2017-12-06 Thread Marcelo E. Magallon
On Wed, Dec 06, 2017 at 02:13:26PM +, Koehler, Yannick wrote:

> In regards to file fetcher, I will go check the code, I thought the
> unpack would only occurs for tarball, not subdir.

If you have:

SRC_URI := "file://some-dir/"

and your tree looks somewhat like this:

.git
poky
src/some-dir

and you set things up so that bitbake will look in src/ (set FILESPATH),
then it will copy "some-dir" to $WORKDIR/some-dir, and you can point S
there.

This satisfies your requirement as I understand it (single repo, all the
source code is there, including poky).

The huge downside of this is that some-dir is copied and this confuses
people.

I know the bitbake version in 2.4 has some differences that might help
here, but I haven't had the chance to investigate further.

Marcelo
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] externalsrc + sstate why is not compatible?

2017-12-06 Thread Koehler, Yannick
When you say "subdirs", are you referring to submodules or something along 
those line?  We have used attempted to use submodules and it still required 20 
+ 1 repo and the overhead is similar to yocto + 20 repo but then you have yocto 
+ 20 repos + 1 main repos, as such, this is not acceptable for us.  We also 
looked at other combination of multiple repos supported or in work for git and 
none are satisfying or supported in a way I could propose to use it in our 
project.

If you mean 1 repo, which subdirs representing each package, I would be 
interested, but how would it work with yocto SRC_URI?

In regards to file fetcher, I will go check the code, I thought the unpack 
would only occurs for tarball, not subdir.

--
Yannick Koehler

-Message d'origine-
De : Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] 
Envoyé : 6 décembre 2017 03:47
À : Koehler, Yannick ; yocto@yoctoproject.org
Objet : Re: [yocto] externalsrc + sstate why is not compatible?

On 12/06/2017 04:15 AM, Koehler, Yannick wrote:
> In our situation, we have many packages that are in-house, as such we  
> use a local folder for the several in-house modules.  To do so, we 
> need to use externalsrc to point to the local code so that the git 
> repo contains both the code + recipe, instead of 20 repos (1 per
> packages) and 1 more for yocto recipe which complicates things when 
> you want to submit a change.

You don't have to have 20 repos. You can place the modules into a single repo 
with subdirs.

> Yet, the externalsrc disable the setscene tasks and set the 
> BB_DONTCACHE variable.  I altered the script to remove those but then 
> a change to the externalsrc folder is not detected. I wonder if it is 
> because the S variable is set past the sstate algorithm and is then 
> unable to consider the externalsrc folder as the real source location.  
> Any expert on this matter that can guide me to either make sstate 
> works for external src or teach me how to have code + recipe in a 
> single git repo.  I am certainly not the only case using such a 
> pattern.

The bitbake documentation claims you can specify a directory in the
file: fetcher, and then all of it will be unpacked to workdir. I've never seen 
or tried it myself, but maybe you can investigate in that direction, and make 
it work if it doesn't.

Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] How to append to image, not machine?

2017-12-06 Thread Vincent Prince
Hi,

One solution is to add a custom action with ROOTFS_POSTPROCESS_COMMAND in
one of the image, that will change interfaces file (with sed for example,
or symlink, etc ...).

Best Regards,
Vincent

2017-12-06 14:43 GMT+01:00 Marek Słomiany :

> Hi,
>
> I'm building system that has 2 cpu's which communicate via CSLIP over
> serial. On both ends it looks similar but the IP's has to be swapped for
> point-to-point communication. For example one will have:
> address 10.10.10.1
> pointopoint 10.10.10.2
>
> and the other one:
> address 10.10.10.2
> pointopoint 10.10.10.1
>
> to replace /etc/network/interfaces file with my own, I have created
> a init-ifupdown_%.bbappend file which contains:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> SRC_URI_append = "\
> file://interfaces \
> "
>
> I could make two interfaces files in separate directories and add to
> SRC_URI_append_machine1 for each one, but I'm using same machine for both
> cpu's, but different images (one with qt, one without). Is there a similar
> method but binding append with image not a machine?
>
> Regards,
> Marek Slomiany
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [linux-yocto] [kernel-cache][yocto-4.12][PATCH] features/i915/i915.cfg: compile i915 as a module

2017-12-06 Thread Bruce Ashfield

On 12/05/2017 09:10 PM, Liwei Song wrote:



On 12/06/2017 06:26 AM, Bruce Ashfield wrote:

On 12/04/2017 08:16 PM, Liwei Song wrote:

Set i915 as a moudle to trigger the firmware load


typo: module


at the same time the module is loaded.

This can aviod i915 driver load rootfs's firmware before
rootfs was mounted error.


I'm not following this problem description, can you rephrase ?
Is it a timing problem between the driving starting (as the
built in) and it triggering a firmware load (that fails due
to the rootfs not being ready) ?


Yes, it is a timing problem, how about rephrase it as following:

This can aviod a timing problem between the driver starting


s/aviod/avoid/


and it triggering a firmware load, after compile it as module
i915 driver will start after the rootfs is ready, then the
firmware store in /lib/firmware/ can be load successful by
i915 driver.



But yes, that log is good for a v2.

  



presumably the i915 was built in for a reason, i.e. so it
is available in early boot without the need to load a module.
And this change would break that functionality. Also, are
there any other build settings that need to arrange for the
module autoload ?


I suppose no during my test on board.


So the device is likely triggering the module auto-load
via the helper ? It would be good to fully understand this part,
since it also means that any initramfs needs the module.

What type of boot are you doing for the test ? Is there an
initramfs/initrd involved ?

Bruce



Thanks,
Liwei.




Since there is that possibility, restating the problem you are
trying to fix would be good.

Bruce



Signed-off-by: Liwei Song 
---
   features/i915/i915.cfg | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/features/i915/i915.cfg b/features/i915/i915.cfg
index 6dcc60f2dfc7..60cb963e014b 100644
--- a/features/i915/i915.cfg
+++ b/features/i915/i915.cfg
@@ -8,6 +8,6 @@ CONFIG_AGP=y
   CONFIG_AGP_INTEL=y
   CONFIG_DRM=y
   CONFIG_DRM_KMS_HELPER=y
-CONFIG_DRM_I915=y
+CONFIG_DRM_I915=m
   CONFIG_DRM_KMS_FB_HELPER=y
   CONFIG_DRM_I915_ALPHA_SUPPORT=y







--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto


Re: [yocto] bitbake menuconfig fails

2017-12-06 Thread Mircea Gliga

Thanks Zoran
What you say makes perfect sense.
I also got the feeling that something doesn't match between the new 
kernel and yocto.

Maybe I should also upgrade yocto.

Thanks again.

On 06/12/17 09:22, Zoran Stojsavljevic wrote:

Hello Mircea,

From my point of view:

/_> /usr/bin/ld: cannot find -lncursesw_/
> collect2: error: ld returned 1 exit status
> scripts/Makefile.host:111: recipe for target 'scripts/kconfig/mconf' failed

The first line explains it all. You could not configure 4.14, since 
for this you should have ncurses package. I would further say, the
YOCTO ncurses version you have, which is used for 4.8 is outdated, so 
you need newer (matching) YOCTO version for 4.14.


Why you are able to configure 4.14 outside of yocto? Because you use 
another version of ncurses, one which is host native to
Debian 8. YOCTO probably uses some other host based ncurses inside 
YOCTO (in Open Embedded/meta layer, my best guess).


Zoran

On Wed, Dec 6, 2017 at 7:31 AM, Mircea Gliga > wrote:


Hello

We are using in our layer a kernel 4.8 recipe (linux-stable_4.8.bb
)- everything ok.
I'm trying to upgrade to 4.14, I created a new recipe
linux-stable_4.14.bb . They live side
by side, for now.
But with the 4.14 kernel when running `bitbake -c menuconfig
linux-stable`, the new terminal comes up and I get the following
error:

  HOSTCC  scripts/basic/fixdep
  GEN ./Makefile
  HOSTCC  scripts/kconfig/mconf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTCC  scripts/kconfig/lxdialog/checklist.o
  HOSTCC  scripts/kconfig/lxdialog/util.o
  HOSTCC  scripts/kconfig/lxdialog/inputbox.o
  HOSTCC  scripts/kconfig/lxdialog/textbox.o
  HOSTCC  scripts/kconfig/lxdialog/yesno.o
  HOSTCC  scripts/kconfig/lxdialog/menubox.o
  HOSTLD  scripts/kconfig/mconf
/usr/bin/ld: cannot find -lncursesw
collect2: error: ld returned 1 exit status
scripts/Makefile.host:111: recipe for target
'scripts/kconfig/mconf' failed
make[3]: *** [scripts/kconfig/mconf] Error 1

/media/mircea/ExtLinux/Adventure/testBuildServer/product-sama5-kernel/yocto/build/tmp/work-shared/cuxe/kernel-source/Makefile:548:
recipe for target 'menuconfig' failed
make[2]: *** [menuconfig] Error 2
Makefile:146: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make: *** [__sub-make] Error 2
Command failed.


If I rename linux-stable_4.14.bb  to
linux-stable_4.14.bb___, then run bitbake again (now the build
system is working with the 4.8 kernel again) => menuconfig starts
and works as expected.

I'm using krogoth, 2.1.2, Debian 8 (jessie)

I also tried to config the kernel outside of yocto, downloaded
https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.4.tar.xz
,
extracted and run make menuconfig => works as expected

Any hints are appreciated.

Thanks
-- 
___

yocto mailing list
yocto@yoctoproject.org 
https://lists.yoctoproject.org/listinfo/yocto





-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] variable override syntax, where is it documented?

2017-12-06 Thread Alexander Kanavin

On 12/06/2017 10:58 AM, Bernd wrote:

I just found out that I can ovverride the line

hostname = "${MACHINE}"

in base-files simply by assigning a value to

hostname_pn-base-files

in my configuration file and it will re-assign it with a higher
priority than "=".

Now I wonder where this kind of black magic is documented, I don't
seem to be able to locate any document that explains the "_pn-" syntax
and I wonder if there are even more such tricks that could be useful
and am looking for a document that explains them all. Is there such a
thing?


Yes, of course. This:

http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-OVERRIDES

and this:

http://www.yoctoproject.org/docs/2.5/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides


Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] variable override syntax, where is it documented?

2017-12-06 Thread Bernd
I just found out that I can ovverride the line

hostname = "${MACHINE}"

in base-files simply by assigning a value to

hostname_pn-base-files

in my configuration file and it will re-assign it with a higher
priority than "=".

Now I wonder where this kind of black magic is documented, I don't
seem to be able to locate any document that explains the "_pn-" syntax
and I wonder if there are even more such tricks that could be useful
and am looking for a document that explains them all. Is there such a
thing?

- Bernd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] externalsrc + sstate why is not compatible?

2017-12-06 Thread Alexander Kanavin

On 12/06/2017 04:15 AM, Koehler, Yannick wrote:

In our situation, we have many packages that are in-house, as such we
 use a local folder for the several in-house modules.  To do so, we
need to use externalsrc to point to the local code so that the git
repo contains both the code + recipe, instead of 20 repos (1 per
packages) and 1 more for yocto recipe which complicates things when
you want to submit a change.


You don't have to have 20 repos. You can place the modules into a single
repo with subdirs.


Yet, the externalsrc disable the setscene tasks and set the
BB_DONTCACHE variable.  I altered the script to remove those but then
a change to the externalsrc folder is not detected. I wonder if it is
because the S variable is set past the sstate algorithm and is then
unable to consider the externalsrc folder as the real source
location.  Any expert on this matter that can guide me to either make
sstate works for external src or teach me how to have code + recipe
in a single git repo.  I am certainly not the only case using such a
pattern.


The bitbake documentation claims you can specify a directory in the 
file: fetcher, and then all of it will be unpacked to workdir. I've 
never seen or tried it myself, but maybe you can investigate in that 
direction, and make it work if it doesn't.


Alex
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [meta-security][PATCH 1/1] swtpm/libtpm: update to latest master

2017-12-06 Thread Patrick Ohly
This allows dropping some patches for issues that were addressed
upstream. It also brings in support for connecting swtpm to qemu
without relying on CUSE.

Signed-off-by: Patrick Ohly 
---
 meta-tpm/recipes-tpm/libtpm/libtpm_1.0.bb  |  4 +-
 meta-tpm/recipes-tpm/swtpm/files/fix_fcntl_h.patch | 24 +++
 .../swtpm/files/fix_lib_search_path.patch  | 20 +
 .../recipes-tpm/swtpm/files/fix_signed_issue.patch | 48 --
 meta-tpm/recipes-tpm/swtpm/swtpm_1.0.bb| 14 +++
 5 files changed, 35 insertions(+), 75 deletions(-)
 delete mode 100644 meta-tpm/recipes-tpm/swtpm/files/fix_signed_issue.patch

diff --git a/meta-tpm/recipes-tpm/libtpm/libtpm_1.0.bb 
b/meta-tpm/recipes-tpm/libtpm/libtpm_1.0.bb
index f9624f6..b29ec6b 100644
--- a/meta-tpm/recipes-tpm/libtpm/libtpm_1.0.bb
+++ b/meta-tpm/recipes-tpm/libtpm/libtpm_1.0.bb
@@ -2,11 +2,9 @@ SUMMARY = "LIBPM - Software TPM Library"
 LICENSE = "BSD-3-Clause"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=97e5eea8d700d76b3ddfd35c4c96485f"
 
-SRCREV = "ad44846dda5a96e269ad2f78a532e01e9a2f02a1"
+SRCREV = "3388d45082bdc588c6fc0672f44d6d7d0aaa86ff"
 SRC_URI = " \
git://github.com/stefanberger/libtpms.git \
-   file://Convert-another-vdprintf-to-dprintf.patch \
-   file://Use-format-s-for-call-to-dprintf.patch \
"
 
 S = "${WORKDIR}/git"
diff --git a/meta-tpm/recipes-tpm/swtpm/files/fix_fcntl_h.patch 
b/meta-tpm/recipes-tpm/swtpm/files/fix_fcntl_h.patch
index e844045..3d16431 100644
--- a/meta-tpm/recipes-tpm/swtpm/files/fix_fcntl_h.patch
+++ b/meta-tpm/recipes-tpm/swtpm/files/fix_fcntl_h.patch
@@ -1,4 +1,7 @@
-logging: Fix musl build issue with fcntl
+From 8750a6c3f0b4d9e7e45b4079150d29eb44774e9c Mon Sep 17 00:00:00 2001
+From: Armin Kuster 
+Date: Tue, 14 Mar 2017 22:59:36 -0700
+Subject: [PATCH 2/4] logging: Fix musl build issue with fcntl
 
  error: #warning redirecting incorrect #include  to  
[-Werror=cpp]
  #warning redirecting incorrect #include  to 
 
-Index: git/src/swtpm/logging.c
-===
 git.orig/src/swtpm/logging.c
-+++ git/src/swtpm/logging.c
-@@ -43,7 +43,7 @@
+---
+ src/swtpm/logging.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/swtpm/logging.c b/src/swtpm/logging.c
+index f16cab6..7da8606 100644
+--- a/src/swtpm/logging.c
 b/src/swtpm/logging.c
+@@ -45,7 +45,7 @@
  #include 
  #include 
  #include 
 -#include 
 +#include 
+ #include 
  #include 
  #include 
- #include 
+-- 
+2.11.0
+
diff --git a/meta-tpm/recipes-tpm/swtpm/files/fix_lib_search_path.patch 
b/meta-tpm/recipes-tpm/swtpm/files/fix_lib_search_path.patch
index 28aca4a..60958f7 100644
--- a/meta-tpm/recipes-tpm/swtpm/files/fix_lib_search_path.patch
+++ b/meta-tpm/recipes-tpm/swtpm/files/fix_lib_search_path.patch
@@ -1,7 +1,7 @@
-From 85706ceb6877ade3b589d3c390abf5b3492bb718 Mon Sep 17 00:00:00 2001
+From 672bb4ee625da3141ba6cecb0601c7563de4c483 Mon Sep 17 00:00:00 2001
 From: Armin Kuster 
 Date: Thu, 13 Oct 2016 02:03:56 -0700
-Subject: [PATCH] swtpm: add new package
+Subject: [PATCH 1/4] swtpm: add new package
 
 Upstream-Status: Inappropriate [OE config]
 
@@ -12,20 +12,21 @@ Rebased to current tip.
 Signed-off-by: Patrick Ohly 
 
 ---
- configure.ac | 32 ++--
- 1 file changed, 10 insertions(+), 22 deletions(-)
+ configure.ac | 34 ++
+ 1 file changed, 10 insertions(+), 24 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index c4a9c6d..6267f64 100644
+index abf5be1..85ed6ac 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -395,29 +395,17 @@ CFLAGS="$CFLAGS -Wformat -Wformat-security"
+@@ -395,31 +395,17 @@ CFLAGS="$CFLAGS -Wformat -Wformat-security"
  dnl We have to make sure libtpms is using the same crypto library
  dnl to avoid problems
  AC_MSG_CHECKING([the crypto library libtpms is using])
 -dirs=$($CC $CFLAGS -Xlinker --verbose 2>/dev/null | \
 -   sed -n '/SEARCH_DIR/p' | \
--   sed 's/SEARCH_DIR("=\?\(@<:@^"@:>@\+\)"); */\1\n/g')
+-   sed 's/SEARCH_DIR("\(@<:@^"@:>@*\)"); */\1 /g' | \
+-   sed 's|=/|/|g')
 -for dir in $dirs $LIBRARY_PATH; do
 -  if test -r $dir/libtpms.so; then
 -if test -n "`ldd $dir/libtpms.so | grep libcrypto.so`"; then
@@ -43,12 +44,13 @@ index c4a9c6d..6267f64 100644
 +break
fi
 -  case $host_os in
--  cygwin)
+-  cygwin|openbsd*)
 -if test -r $dir/libtpms.a; then
 -  if test -n "$(nm $dir/libtpms.a | grep "U AES_encrypt")"; then
 -libtpms_cryptolib="openssl"
 -  fi
 -fi
+-;;
 -  esac
 -done
 +  if test -n "`ldd $dir/libtpms.so | grep libnss3.so`"; then
@@ -60,5 +62,5 @@ index c4a9c6d..6267f64 100644
  if test -z "$libtpms_cryptolib"; then
AC_MSG_ERROR([Could not determine libtpms crypto library.])
 -- 
-2.1.4
+2.11.0
 
diff --git