date:20170823

[OE-core] [PATCH] libinput: remove obsolete touchpad patch

2017-08-23 Thread Jose Alarcon

This patch was a temporal workaround needed with 4.1 kernels.
Remove it.

Signed-off-by: Jose Alarcon 
---
 ...ics-need-to-fake-new-touches-on-TRIPLETAP.patch | 72 --
 meta/recipes-graphics/wayland/libinput_1.8.1.bb|  1 -
 2 files changed, 73 deletions(-)
 delete mode 100644 
meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch

diff --git 
a/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
 
b/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
deleted file mode 100644
index b52b496..000
--- 
a/meta/recipes-graphics/wayland/libinput/touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch
+++ /dev/null
@@ -1,72 +0,0 @@
-This is a workaround upstream suggests for use with kernel 4.1.
-
-Upstream-Status: Inappropriate [temporary work-around]
-Signed-off-by: Jussi Kukkonen 
-
-
-
-From: Peter Hutterer 
-Date: Mon Aug 3 18:23:12 PDT 2015
-Subject: [PATCH v3 libinput] touchpad: serial synaptics need to fake new 
touches on TRIPLETAP
-
-On the 4.1 kernels synaptics pretends to have 3 slots (the serial fw only does
-2). This was added to avoid cursor jumps but has since been reverted for 4.2
-(kernel commit dbf3c37086, 4.1.3 is still buggy). In some cases a TRIPLETAP
-may be triggered without slot 2 ever activating.
-
-While there are still those kernels out there, work around this bug by opening
-a new touch point where none exists if the fake finger count exceeds the slot
-count.
-
-Reported-by: Jan Alexander Steffens 
-Signed-off-by: Peter Hutterer 
-Tested-by: Jan Alexander Steffens 
-Reviewed-by: Hans de Goede 

-Changes to v2:
-- split out the handling instead of having a tmp state variable, see Hans'
-  comments from v2
-
-Mainly sending this to the list again so I have a link to point people to.
-If you're on 4.1.x add this patch to your distribution package.
-
- src/evdev-mt-touchpad.c | 22 --
- 1 file changed, 16 insertions(+), 6 deletions(-)
-
-diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
-index a683d9a..5ef03d5 100644
 a/src/evdev-mt-touchpad.c
-+++ b/src/evdev-mt-touchpad.c
-@@ -369,13 +369,23 @@ tp_restore_synaptics_touches(struct tp_dispatch *tp,
-   for (i = 0; i < tp->num_slots; i++) {
-   struct tp_touch *t = tp_get_touch(tp, i);
- 
--  if (t->state != TOUCH_END)
-+  switch(t->state) {
-+  case TOUCH_HOVERING:
-+  case TOUCH_BEGIN:
-+  case TOUCH_UPDATE:
-   continue;
--
--  /* new touch, move it through begin to update immediately */
--  tp_new_touch(tp, t, time);
--  tp_begin_touch(tp, t, time);
--  t->state = TOUCH_UPDATE;
-+  case TOUCH_NONE:
-+  /* new touch, move it through to begin immediately */
-+  tp_new_touch(tp, t, time);
-+  tp_begin_touch(tp, t, time);
-+  break;
-+  case TOUCH_END:
-+  /* touch just ended ,we need need to restore it to 
update */
-+  tp_new_touch(tp, t, time);
-+  tp_begin_touch(tp, t, time);
-+  t->state = TOUCH_UPDATE;
-+  break;
-+  }
-   }
- }
- 
--- 
-2.4.3
-
diff --git a/meta/recipes-graphics/wayland/libinput_1.8.1.bb 
b/meta/recipes-graphics/wayland/libinput_1.8.1.bb
index f75298b..a21babe 100644
--- a/meta/recipes-graphics/wayland/libinput_1.8.1.bb
+++ b/meta/recipes-graphics/wayland/libinput_1.8.1.bb
@@ -8,7 +8,6 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=2184aef38ff137ed33ce9a63b9d1eb8f"
 DEPENDS = "libevdev udev mtdev"
 
 SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \
-   
file://touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch \
file://0001-tools-Fix-race-in-autotools-install.patch \
 "
 
-- 
2.10.1

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

[OE-core] [PATCH] gpg_sign: depress the owership warnings on homedir

2017-08-23 Thread Jia Zhang

A gpg command, e.g, called by get_gpg_version(), may trigger such a warning:
gpg: WARNING: unsafe ownership on homedir '/home/user/.gnupg'

This sort of warning is harmless so it can be depressed through specifying
--no-permission-warning.

Signed-off-by: Jia Zhang 
---
 meta/lib/oe/gpg_sign.py | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 008478dfeb..9cc88f020c 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -15,7 +15,7 @@ class LocalSigner(object):
 
 def export_pubkey(self, output_file, keyid, armor=True):
 """Export GPG public key to a file"""
-cmd = '%s --batch --yes --export -o %s ' % \
+cmd = '%s --no-permission-warning --batch --yes --export -o %s ' % \
 (self.gpg_bin, output_file)
 if self.gpg_path:
 cmd += "--homedir %s " % self.gpg_path
@@ -31,7 +31,7 @@ class LocalSigner(object):
 """Sign RPM files"""
 
 cmd = self.rpm_bin + " --addsign --define '_gpg_name %s'  " % keyid
-gpg_args = '--batch --passphrase=%s' % passphrase
+gpg_args = '--no-permission-warning --batch --passphrase=%s' % 
passphrase
 if self.gpg_version > (2,1,):
 gpg_args += ' --pinentry-mode=loopback'
 cmd += "--define '_gpg_sign_cmd_extra_args %s' " % gpg_args
@@ -58,8 +58,8 @@ class LocalSigner(object):
 if passphrase_file and passphrase:
 raise Exception("You should use either passphrase_file of 
passphrase, not both")
 
-cmd = [self.gpg_bin, '--detach-sign', '--batch', '--no-tty', '--yes',
-   '--passphrase-fd', '0', '-u', keyid]
+cmd = [self.gpg_bin, '--detach-sign', '--no-permission-warning', 
'--batch',
+   '--no-tty', '--yes', '--passphrase-fd', '0', '-u', keyid]
 
 if self.gpg_path:
 cmd += ['--homedir', self.gpg_path]
@@ -98,7 +98,7 @@ class LocalSigner(object):
 """Return the gpg version as a tuple of ints"""
 import subprocess
 try:
-ver_str = subprocess.check_output((self.gpg_bin, 
"--version")).split()[2].decode("utf-8")
+ver_str = subprocess.check_output((self.gpg_bin, "--version", 
"--no-permission-warning")).split()[2].decode("utf-8")
 return tuple([int(i) for i in ver_str.split('.')])
 except subprocess.CalledProcessError as e:
 raise bb.build.FuncFailed("Could not get gpg version: %s" % e)
@@ -106,7 +106,7 @@ class LocalSigner(object):
 
 def verify(self, sig_file):
 """Verify signature"""
-cmd = self.gpg_bin + " --verify "
+cmd = self.gpg_bin + " --verify --no-permission-warning "
 if self.gpg_path:
 cmd += "--homedir %s " % self.gpg_path
 cmd += sig_file
-- 
2.14.1

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

Re: [OE-core] [PATCH] gpg_sign: depress the owership warnings on homedir

2017-08-23 Thread Jia Zhang


Sorry plz ignore this patch. I will send a new one.

Jia


On 08/24/2017 11:19 AM, Jia Zhang wrote:

A gpg command, e.g, called by get_gpg_version(), may trigger such a warning:
gpg: WARNING: unsafe ownership on homedir '/home/user/.gnupg'

This sort of warning is harmless so it can be depressed through specifying
--no-permission-warning.

Signed-off-by: Jia Zhang 
---
  meta/lib/oe/gpg_sign.py | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 008478dfeb..7d58f93888 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -98,7 +98,7 @@ class LocalSigner(object):
  """Return the gpg version as a tuple of ints"""
  import subprocess
  try:
-ver_str = subprocess.check_output((self.gpg_bin, 
"--version")).split()[2].decode("utf-8")
+ver_str = subprocess.check_output((self.gpg_bin, "--version", "--homedir", 
self.gpg_path)).split()[2].decode("utf-8")
  return tuple([int(i) for i in ver_str.split('.')])
  except subprocess.CalledProcessError as e:
  raise bb.build.FuncFailed("Could not get gpg version: %s" % e)


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

[OE-core] [PATCH] gpg_sign: depress the owership warnings on homedir

2017-08-23 Thread Jia Zhang

A gpg command, e.g, called by get_gpg_version(), may trigger such a warning:
gpg: WARNING: unsafe ownership on homedir '/home/user/.gnupg'

This sort of warning is harmless so it can be depressed through specifying
--no-permission-warning.

Signed-off-by: Jia Zhang 
---
 meta/lib/oe/gpg_sign.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 008478dfeb..7d58f93888 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -98,7 +98,7 @@ class LocalSigner(object):
 """Return the gpg version as a tuple of ints"""
 import subprocess
 try:
-ver_str = subprocess.check_output((self.gpg_bin, 
"--version")).split()[2].decode("utf-8")
+ver_str = subprocess.check_output((self.gpg_bin, "--version", 
"--homedir", self.gpg_path)).split()[2].decode("utf-8")
 return tuple([int(i) for i in ver_str.split('.')])
 except subprocess.CalledProcessError as e:
 raise bb.build.FuncFailed("Could not get gpg version: %s" % e)
-- 
2.14.1

-- 
___
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-08-19

2017-08-23 Thread Huang, Jie (Jackie)



> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org
> [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: Tuesday, August 22, 2017 21:20
> To: Patches and discussions about the oe-core layer; openembedded-devel
> Subject: [oe] State of bitbake world, Failed tasks 2017-08-19
> 
> Openssl was reverted back to 1.0 version being default, so there is
> fewer errors now, but there was also a fix for package.bbclass:
> http://lists.openembedded.org/pipermail/openembedded-core/2017-
> August/141127.html
> which causes many do_package_qa tasks to fail.
> 
> Please help by sending fixes for issues it found.
> 
> http://www.openembedded.org/wiki/Bitbake_World_Status
> 
> == Number of issues - stats ==
> {| class='wikitable'
> !|Date !!colspan='3'|Failed tasks
>   !!|Signatures !!colspan='14'|QA !!Comment
> |-
> ||||qemuarm   ||qemux86   ||qemux86_64||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   ||ldflags   
> ||compile-
> host-path ||
> |-
> ||2017-08-19  ||17||21||21||0 ||0 ||0
>   ||5 ||0 ||25||28485
>   ||2 ||0 ||0 ||0 ||0
>   ||0 ||0 ||0 ||
> |}
> 
> == Failed tasks 2017-08-19 ==
> 
> INFO: jenkins-job.sh-1.8.25 Complete log available at http://logs.nslu2-
> linux.org/buildlogs/oe/world/rocko/log.report.20170822_023550.log
> 
> === common (15) ===
> * meta-browser/recipes-mozilla/firefox/firefox_45.9.0esr.bb:do_compile
> * meta-openembedded/meta-filesystems/recipes-
> utils/udevil/udevil_0.4.4.bb:do_package_qa
> * meta-openembedded/meta-gnome/recipes-
> gnome/bonobo/libbonobo_2.32.1.bb:do_package_qa
> * meta-openembedded/meta-networking/recipes-
> daemons/squid/squid_3.5.26.bb:do_package_qa
> * meta-openembedded/meta-networking/recipes-
> kernel/wireguard/wireguard-tools_0.0.20170517.bb:do_package_qa
> * meta-openembedded/meta-networking/recipes-
> support/ndisc6/ndisc6_1.0.3.bb:do_package_qa
> * meta-openembedded/meta-oe/recipes-core/glib-
> 2.0/glibmm_2.50.1.bb:do_package_qa
> * meta-openembedded/meta-oe/recipes-
> devtools/mpich/mpich_3.2.bb:do_package_qa


> * meta-openembedded/meta-oe/recipes-
> extended/corosync/corosync_2.4.2.bb:do_package_qa
> * meta-openembedded/meta-oe/recipes-
> extended/enscript/enscript_1.6.6.bb:do_package_qa
> * meta-openembedded/meta-oe/recipes-
> support/logwarn/logwarn_1.0.14.bb:do_package_qa

I will take these three.

> * meta-openembedded/meta-perl/recipes-perl/libmodule/libmodule-build-
> perl_0.31.bb:do_package_qa
> * meta-openembedded/meta-python/recipes-devtools/python/python3-
> pylint_1.6.5.bb:do_package_qa
> * meta-openembedded/meta-python/recipes-devtools/python/python-
> matplotlib_1.1.0.bb:do_compile
> * meta-smartphone/meta-shr/recipes-shr/3rdparty/ubx-
> utils_git.bb:do_package_qa
> 
> === common-x86 (5) ===
> * meta-openembedded/meta-oe/recipes-devtools/xmlrpc-c/xmlrpc-
> c_1.31.0.bb:do_package_qa
> * meta-openembedded/meta-oe/recipes-support/multipath-tools/multipath-
> tools_0.7.1.bb:do_package_qa

I will take this.

Thanks,
Jackie

> * meta-openembedded/meta-python/recipes-extended/python-
> pykickstart/python3-pykickstart_2.35.bb:do_package_qa
> * meta-qt5/recipes-qt/qt5/qtwebengine_git.bb:do_compile
> * meta-smartphone/meta-shr/recipes-
> shr/3rdparty/numptyphysics_svn.bb:do_package_qa
> 
> === qemuarm (2) ===
> * meta-openembedded/meta-oe/recipes-
> support/mysql/mariadb_5.5.57.bb:do_compile
> * meta-webos-ports/meta-luneui/recipes-luneui/luna-next/luna-
> next.bb:do_compile
> 
> === qemux86 (1) ===
> * meta-openembedded/meta-oe/recipes-
> support/mongodb/mongodb_git.bb:do_compile
> 
> === qemux86_64 (1) ===
> * meta-openembedded/meta-gnome/recipes-gnome/eds/evolution-data-
> server_git.bb:do_compile
> 
> === Number of failed tasks (59) ===
> {| class=wikitable
> |-
> || qemuarm|| 17|| http://logs.nslu2-
> linux.org/buildlogs/oe/world/rocko/log.world.qemuarm.20170820_231852.log/
> || http://errors.yoctoproject.org/Errors/Build/45276/
> |-
> || qemux86|| 21|| http://logs.nslu2-
> linux.org/buildlogs/oe/world/rocko/log.world.qemux86.20170820_161131.log/
> || http://errors.yoctoproject.org/Errors/Build/45273/
> |-
> || qemux86_64 || 21|| http://logs.nslu2-
> linux.org/buildlogs/oe/world/rocko/log.world.qemux86-
> 64.20170819_113439.log/ ||
> http://errors.yoctoproject.org/Errors/Build/44950/
> |}
> 
> === PNBLACKLISTs (1) ===
> 
> === QA issues (28517) ===
> {| class=wikitable

[OE-core] [PATCH v2] webkitgtk: disable gobject-introspection on armv7a

2017-08-23 Thread jackie.huang

From: Jackie Huang 

Disable gobject-introspection on armv7a and armv7ve
to avoid do_compile failure:

| qemu: uncaught target signal 11 (Segmentation fault) - core dumped
| Segmentation fault

Signed-off-by: Jackie Huang 
---
 meta/recipes-sato/webkit/webkitgtk_2.16.6.bb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb
index df355d29ba..0f126cba81 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb
@@ -112,3 +112,8 @@ ARM_INSTRUCTION_SET_armv6 = "arm"
 ARM_INSTRUCTION_SET_armv7a = "thumb"
 ARM_INSTRUCTION_SET_armv7r = "thumb"
 ARM_INSTRUCTION_SET_armv7ve = "thumb"
+
+# qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+# Segmentation fault
+GI_DATA_ENABLED_armv7a = "False"
+GI_DATA_ENABLED_armv7ve = "False"
-- 
2.11.0

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

[OE-core] [PATCH v3] devtool/standard: set a preferred provider when adding a new recipe with devtool

2017-08-23 Thread juan . m . cruz . alcaraz

From: Juan M Cruz Alcaraz 

A recipe added with "devtool add" requires to be able to take precedence on 
recipes
previously defined with PREFERRED_PROVIDER.

By adding the parameter "--provides" to "devtool add" it is possible to specify
an element to be provided by the recipe. A devtool recipe can override a 
previous
PREFERRED_PROVIDER using the layer configuration file in the workspace.

E.g.
devtool add my-libgl git@git://my-libgl-repository --provides virtual/libgl

[YOCTO #10415]

Signed-off-by: Juan M Cruz Alcaraz 
---
 scripts/lib/devtool/standard.py  | 20 
 scripts/lib/recipetool/create.py |  3 +++
 2 files changed, 23 insertions(+)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index ec192238ed..b3d857bbd9 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -151,6 +151,8 @@ def add(args, config, basepath, workspace):
 extracmdopts += ' --fetch-dev'
 if args.mirrors:
 extracmdopts += ' --mirrors'
+if args.provides:
+extracmdopts += ' --provides %s' % args.provides
 
 tempdir = tempfile.mkdtemp(prefix='devtool')
 try:
@@ -266,6 +268,23 @@ def add(args, config, basepath, workspace):
 f.write('done\n')
 f.write('}\n')
 
+# Check if the new layer provides recipes whose priorities have been
+# overriden by PREFERRED_PROVIDER.
+recipe_name = rd.getVar('PN')
+provides = rd.getVar('PROVIDES')
+# Search every item defined in PROVIDES
+for recipe_provided in provides.split():
+preferred_provider = 'PREFERRED_PROVIDER_' + recipe_provided
+if rd.getVar(preferred_provider):
+if args.fixed_setup:
+#if we are inside the eSDK add the new PREFERRED_PROVIDER 
in the workspace layer.conf
+layerconf_file = os.path.join(config.workspace_path, 
"conf", "layer.conf")
+with open(layerconf_file, 'a') as f:
+f.write('%s="%s"\n' % (preferred_provider, 
recipe_name))
+else:
+logger.warn('Set \'%s\' in order to use the recipe' % 
preferred_provider)
+break
+
 _add_md5(config, recipename, appendfile)
 
 logger.info('Recipe %s has been automatically created; further editing 
may be required to make it fully functional' % recipefile)
@@ -1810,6 +1829,7 @@ def register_commands(subparsers, context):
 parser_add.add_argument('--also-native', help='Also add native variant 
(i.e. support building recipe for the build host as well as the target 
machine)', action='store_true')
 parser_add.add_argument('--src-subdir', help='Specify subdirectory within 
source tree to use', metavar='SUBDIR')
 parser_add.add_argument('--mirrors', help='Enable PREMIRRORS and MIRRORS 
for source tree fetching (disable by default).', action="store_true")
+parser_add.add_argument('--provides', '-p', help='Specify an alias for the 
item provided by the recipe. E.g. virtual/libgl')
 parser_add.set_defaults(func=add, fixed_setup=context.fixed_setup)
 
 parser_modify = subparsers.add_parser('modify', help='Modify the source 
for an existing recipe',
diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index e21e2bf298..83c8e4f7b7 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -607,6 +607,8 @@ def create_recipe(args):
 (stdout, _) = bb.process.run('git rev-parse HEAD', cwd=srctree)
 srcrev = stdout.rstrip()
 lines_before.append('SRCREV = "%s"' % srcrev)
+if args.provides:
+lines_before.append('PROVIDES = "%s"' % args.provides)
 lines_before.append('')
 
 if srcsubdir and not args.binary:
@@ -1158,6 +1160,7 @@ def register_commands(subparsers):
   description='Creates a new recipe 
from a source tree')
 parser_create.add_argument('source', help='Path or URL to source')
 parser_create.add_argument('-o', '--outfile', help='Specify filename for 
recipe to create')
+parser_create.add_argument('-p', '--provides', help='Specify an alias for 
the item provided by the recipe')
 parser_create.add_argument('-m', '--machine', help='Make recipe 
machine-specific as opposed to architecture-specific', action='store_true')
 parser_create.add_argument('-x', '--extract-to', metavar='EXTRACTPATH', 
help='Assuming source is a URL, fetch it and extract it to the directory 
specified as %(metavar)s')
 parser_create.add_argument('-N', '--name', help='Name to use within recipe 
(PN)')
-- 
2.12.3

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

[OE-core] [PATCH] initramfs-framework/setup-live: quote bootparam_root variable

2017-08-23 Thread California Sullivan

When bootparam_root was empty the if statement would resolve into
invalid syntax instead of short circuiting after the -z, causing a boot
failure.

Signed-off-by: California Sullivan 
---
I stupidly didn't test an empty root parameter with my previous patch
and just assumed the -z $bootparam_root would still work. I was wrong.

Rest assured this patch was tested with all three cases: an empty root
parameter, root=/dev/ram0, and a valid PARTUUID.

 meta/recipes-core/initrdscripts/initramfs-framework/setup-live | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/setup-live 
b/meta/recipes-core/initrdscripts/initramfs-framework/setup-live
index b98a321..4c79f41 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework/setup-live
+++ b/meta/recipes-core/initrdscripts/initramfs-framework/setup-live
@@ -12,7 +12,7 @@ ISOLINUX=""
 ROOT_DISK=""
 shelltimeout=30
 
-   if [ -z $bootparam_root -o $bootparam_root = "/dev/ram0" ]; then
+   if [ -z "$bootparam_root" -o "$bootparam_root" = "/dev/ram0" ]; then
echo "Waiting for removable media..."
C=0
while true
-- 
2.9.5

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

Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG options

2017-08-23 Thread Philip Balister

On 08/22/2017 09:26 PM, Randy MacLeod wrote:
> On 2017-08-22 03:55 PM, Richard Purdie wrote:
>> On Tue, 2017-08-22 at 12:51 -0700, Andre McCurdy wrote:
>>> On Tue, Aug 22, 2017 at 12:42 AM,  
>>> wrote:

 From: Jackie Huang 

 We want to provide python libs by default, and some other
 popular Linux distributions like redhat/fedora does the same.
>>> Has something changed? Is there anything in oe-core or meta-oe which
>>> now needs boost python support enabled?

I'm aware of a package in meta-sdr that will need boost python support.
So there is need for this feature.

Philip

>>
>> Does it even actually build on all arches? >
>> I'm rather behind with patch review right now as people are putting so
>> many patches out there with what seems like minimal testing and
>> expecting me/Ross and the autobuilder to figure out the problems for
>> them.
>>
>> Each time one fails, it blocks the queue with the rest of them in and I
>> have to retest until I get something clean.
>>
>> Testing this change is quite a way down my priority list I'm afraid.
>>
> 
> Maybe this is better done in our distro configuration.
> 
> We're trying to minimize differences with oe-core and
> the boost python support doesn't seem to be much of an
> impact based on looking at logs rather than a having a
> detailed understanding of boost.
> 
> We've had this commit in our local branch since before:
> 
> CommitDate: Wed Dec 21 22:16:31 2016 -0800
> 
> boost: add python to default PACKAGECONFIG options
> 
> We want to provide python libs by default, and some other
> popular Linux distributions like redhat/fedora does the same.
> 
> (LOCAL REV: NOT UPSTREAM) -- sent to oe-core on 20160930
> 
> so it certainly builds for all qemu* for glibc configurations.
> 
> I'll see if we can add musl builds to our automated builds tonight.
> 
> Jackie,
> 
> Did/Can you build for musl?
> Do you have any idea of the impact of this config on users that are not
> interested in the python interface with boost?
> What's the additional cost in compile time?
> 
> 
> 
> There certainly are a rush of package updates and other changes
> coming in; apologies for the lack of warning and late arrivals.
> Other than doing more testing and explaining what tests were done,
> what else can we do to help?
> 
> 
> ../Randy
> 
> 
>> Cheers,
>>
>> Richard
>>
>>
> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/7] json-glib: convert to meson build

2017-08-23 Thread Leonardo Sandoval


> -inherit gnomebase gettext lib_package gobject-introspection gtk-doc manpages
> +inherit gnomebase-meson lib_package gobject-introspection gtk-doc manpages

gettext is dropped, does it mean that it was not needed?

>  
> -PACKAGECONFIG[manpages] = "--enable-man 
> --with-xml-catalog=${STAGING_ETCDIR_NATIVE}/xml/catalog.xml, --disable-man, 
> libxslt-native xmlto-native"
> +GTKDOC_ENABLE_FLAG = "-Denable-gtk-doc=true"
> +GTKDOC_DISABLE_FLAG = "-Denable-gtk-doc=false"
> +
> +GI_ENABLE_FLAG = "-Ddisable_introspection=false"
> +GI_DISABLE_FLAG = "-Ddisable_introspection=true"
> +
> +EXTRA_OEMESON_append_class-target = " ${@bb.utils.contains('GTKDOC_ENABLED', 
> 'True', '${GTKDOC_ENABLE_FLAG}', \
> + 
>'${GTKDOC_DISABLE_FLAG}', d)} "
> +EXTRA_OEMESON_append_class-target = " 
> ${@bb.utils.contains('GI_DATA_ENABLED', 'True', '${GI_ENABLE_FLAG}', \
> + 
>'${GI_DISABLE_FLAG}', d)} "
> +
> +PACKAGECONFIG[manpages] = "-Denable-man=true, -Denable-man=false, 
> libxslt-native xmlto-native"
> +
> +do_install_append() {
> +# FIXME: these need to be provided via ptest
> +rm -rf ${D}${datadir}/installed-tests ${D}${libexecdir}
> +}
>  
>  BBCLASSEXTEND = "native nativesdk"
> -- 
> 2.14.1
> 


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

[OE-core] [PATCH] acl_2.25: improve reproducibility

2017-08-23 Thread Juro Bystricky

Remove all host build references from the acl-ptest package.

Signed-off-by: Juro Bystricky 
---
 meta/recipes-support/attr/acl_2.2.52.bb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-support/attr/acl_2.2.52.bb 
b/meta/recipes-support/attr/acl_2.2.52.bb
index 306c7b5..8f3dc45 100644
--- a/meta/recipes-support/attr/acl_2.2.52.bb
+++ b/meta/recipes-support/attr/acl_2.2.52.bb
@@ -43,6 +43,11 @@ do_install_ptest() {
tar -c --exclude=nfs test/ | ( cd ${D}${PTEST_PATH} && tar -xf - )
mkdir ${D}${PTEST_PATH}/include
cp ${S}/include/builddefs ${S}/include/buildmacros 
${S}/include/buildrules ${D}${PTEST_PATH}/include/
+   # Remove any build host references
+   sed -e "s:--sysroot=${STAGING_DIR_TARGET}::g" \
+   -e 's:${HOSTTOOLS_DIR}/::g' \
+   -e 's:${RECIPE_SYSROOT_NATIVE}::g' \
+   -i ${D}${PTEST_PATH}/include/builddefs
 }
 
 RDEPENDS_${PN}-ptest = "acl bash coreutils perl perl-module-filehandle 
perl-module-getopt-std perl-module-posix shadow"
-- 
2.7.4

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

[OE-core] [PATCH] attr: improve reproducibility

2017-08-23 Thread Juro Bystricky

Remove all host build references from the attr-ptest package.

Signed-off-by: Juro Bystricky 
---
 meta/recipes-support/attr/attr.inc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-support/attr/attr.inc 
b/meta/recipes-support/attr/attr.inc
index e8b5d05..24ef5ad 100644
--- a/meta/recipes-support/attr/attr.inc
+++ b/meta/recipes-support/attr/attr.inc
@@ -32,6 +32,12 @@ do_install_ptest() {
  do cp ${S}/include/$i ${D}${PTEST_PATH}/include/; \
done
sed -e 's|; @echo|; echo|' -i ${D}${PTEST_PATH}/test/Makefile
+
+   # Remove any build host references
+   sed -e "s:--sysroot=${STAGING_DIR_TARGET}::g" \
+   -e 's:${HOSTTOOLS_DIR}/::g' \
+   -e 's:${RECIPE_SYSROOT_NATIVE}::g' \
+   -i ${D}${PTEST_PATH}/include/builddefs
 }
 
 RDEPENDS_${PN}-ptest = "attr coreutils perl-module-filehandle 
perl-module-getopt-std perl-module-posix"
-- 
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] kernel-yocto: relax BSP definition test

2017-08-23 Thread Andrei Gherzan

On Wed, Aug 23, 2017 at 8:20 PM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> commit 44aea7b873 [kernel-yocto: ensure that only valid BSPs are built]
> introduced a new check to ensure that a valid BSP definition was found,
> rather than building something that 'closely' matched the current
> MACHINE.
>
> This check breaks valid configurations which do not have a bsp
> definition but are otherwise completely configured machines.
>
> To allow both elements to co-exist (and not add warnings or errors
> to otherwise valid builds), we first check to see if an empty bsp
> definition was found, but then check to see if a defconfig was
> provided.
>
> If a defconfig has been provided, that is a sign that the board
> configuration is complete and we should continue the build without
> otherwise bothering the user.
>
> Tested on meta-raspberrypi and linux-yocto*
>
> Signed-off-by: Bruce Ashfield 
> ---
>
> v2: fixed the badly placed -q
>
>  meta/classes/kernel-yocto.bbclass | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/kernel-yocto.bbclass
> b/meta/classes/kernel-yocto.bbclass
> index 3c6df92131bc..20b4942320d6 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -143,8 +143,11 @@ do_kernel_metadata() {
>
> # expand kernel features into their full path equivalents
> bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
> -DKTYPE=${LINUX_KERNEL_TYPE})
> -   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
> -   bbfatal_log "Could not locate BSP definiton for
> ${KMACHINE}/${LINUX_KERNEL_TYPE}."
> +   if [ -z "$bsp_definition" ]; then
> +   echo "$sccs" | grep -q defconfig
> +   if [ $? -ne 0 ]; then
> +   bberror "Could not locate BSP definition for
> ${KMACHINE}/${LINUX_KERNEL_TYPE} and no defconfig was provided"
> +   fi
> fi
> meta_dir=$(kgit --meta)
>
>
Looks good.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] poky: update default kernel to 4.12 and lsb to 4.9

2017-08-23 Thread Bruce Ashfield

ignore this!

misfire of my script to send the updated BSP test.

Bruce

On Wed, Aug 23, 2017 at 2:54 PM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> Hi all,
>
> To match the pull request to oe-core that adds the 4.12 kernel and removes
> the 4.1 kernel these two patches bump the default kernel to 4.12 and also
> update LSB to use the 4.9 kernel.
>
> Build and boot testing was performed on all qemu architectures.
>
> Cheers,
>
> Bruce
>
> The following changes since commit 847d9000180cafedb23c60a6673adc
> ec62ca67a1:
>
>   linux-yocto/4.10: CVE & misc fixes (2017-08-20 22:38:46 -0400)
>
> are available in the git repository at:
>
>   git://git.pokylinux.org/poky-contrib zedd/kernel-yocto
>   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto
>
> Bruce Ashfield (2):
>   poky: bump preferred version of linux-yocto to 4.12
>   poky: bump poky lsb to linux 4.9
>
>  meta-poky/conf/distro/poky-lsb.conf | 2 +-
>  meta-poky/conf/distro/poky.conf | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> --
> 2.5.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] kernel-yocto: relax BSP definition test

2017-08-23 Thread Bruce Ashfield

commit 44aea7b873 [kernel-yocto: ensure that only valid BSPs are built]
introduced a new check to ensure that a valid BSP definition was found,
rather than building something that 'closely' matched the current
MACHINE.

This check breaks valid configurations which do not have a bsp
definition but are otherwise completely configured machines.

To allow both elements to co-exist (and not add warnings or errors
to otherwise valid builds), we first check to see if an empty bsp
definition was found, but then check to see if a defconfig was
provided.

If a defconfig has been provided, that is a sign that the board
configuration is complete and we should continue the build without
otherwise bothering the user.

Tested on meta-raspberrypi and linux-yocto*

Signed-off-by: Bruce Ashfield 
---

v2: fixed the badly placed -q

 meta/classes/kernel-yocto.bbclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 3c6df92131bc..20b4942320d6 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -143,8 +143,11 @@ do_kernel_metadata() {
 
# expand kernel features into their full path equivalents
bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} 
-DKTYPE=${LINUX_KERNEL_TYPE})
-   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
-   bbfatal_log "Could not locate BSP definiton for 
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+   if [ -z "$bsp_definition" ]; then
+   echo "$sccs" | grep -q defconfig
+   if [ $? -ne 0 ]; then
+   bberror "Could not locate BSP definition for 
${KMACHINE}/${LINUX_KERNEL_TYPE} and no defconfig was provided"
+   fi
fi
meta_dir=$(kgit --meta)
 
-- 
2.5.0

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

Re: [OE-core] [PATCH] kernel-yocto: relax BSP definition test

2017-08-23 Thread Bruce Ashfield


On 08/23/2017 03:07 PM, Andre McCurdy wrote:

On Wed, Aug 23, 2017 at 11:54 AM, Bruce Ashfield
 wrote:

commit 44aea7b873 [kernel-yocto: ensure that only valid BSPs are built]
introduced a new check to ensure that a valid BSP definition was found,
rather than building something that 'closely' matched the current
MACHINE.

This check breaks valid configurations which do not have a bsp
definition but are otherwise completely configured machines.

To allow both elements to co-exist (and not add warnings or errors
to otherwise valid builds), we first check to see if an empty bsp
definition was found, but then check to see if a defconfig was
provided.

If a defconfig has been provided, that is a sign that the board
configuration is complete and we should continue the build without
otherwise bothering the user.

Tested on meta-raspberrypi and linux-yocto*

Signed-off-by: Bruce Ashfield 
---
  meta/classes/kernel-yocto.bbclass | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 3c6df92131bc..d68e720589dc 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -143,8 +143,11 @@ do_kernel_metadata() {

 # expand kernel features into their full path equivalents
 bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} 
-DKTYPE=${LINUX_KERNEL_TYPE})
-   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
-   bbfatal_log "Could not locate BSP definiton for 
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+   if [ -z "$bsp_definition" ]; then
+   echo -q "$sccs" | grep defconfig


echo -q ?


gah!

v2 coming. that should be grep -q ...

Thanks for catching that :D

Bruce




+   if [ $? -ne 0 ]; then
+   bberror "Could not locate BSP definition for 
${KMACHINE}/${LINUX_KERNEL_TYPE} and no defconfig was provided"
+   fi
 fi
 meta_dir=$(kgit --meta)

--
2.5.0

--
___
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/7] meson: add a recipe and class from meta-oe

2017-08-23 Thread Leonardo Sandoval

> +
> +inherit setuptools3
> +
> +RDEPENDS_${PN} = "ninja python3-core python3-modules"
> +

if (python3) modules depends on core, I believe core can be dropped from
RDEPENDS

> +BBCLASSEXTEND = "native"
> -- 
> 2.14.1
> 


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

Re: [OE-core] [PATCH] kernel-yocto: relax BSP definition test

2017-08-23 Thread Andre McCurdy

On Wed, Aug 23, 2017 at 11:54 AM, Bruce Ashfield
 wrote:
> commit 44aea7b873 [kernel-yocto: ensure that only valid BSPs are built]
> introduced a new check to ensure that a valid BSP definition was found,
> rather than building something that 'closely' matched the current
> MACHINE.
>
> This check breaks valid configurations which do not have a bsp
> definition but are otherwise completely configured machines.
>
> To allow both elements to co-exist (and not add warnings or errors
> to otherwise valid builds), we first check to see if an empty bsp
> definition was found, but then check to see if a defconfig was
> provided.
>
> If a defconfig has been provided, that is a sign that the board
> configuration is complete and we should continue the build without
> otherwise bothering the user.
>
> Tested on meta-raspberrypi and linux-yocto*
>
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/classes/kernel-yocto.bbclass | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/kernel-yocto.bbclass 
> b/meta/classes/kernel-yocto.bbclass
> index 3c6df92131bc..d68e720589dc 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -143,8 +143,11 @@ do_kernel_metadata() {
>
> # expand kernel features into their full path equivalents
> bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} 
> -DKTYPE=${LINUX_KERNEL_TYPE})
> -   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
> -   bbfatal_log "Could not locate BSP definiton for 
> ${KMACHINE}/${LINUX_KERNEL_TYPE}."
> +   if [ -z "$bsp_definition" ]; then
> +   echo -q "$sccs" | grep defconfig

echo -q ?

> +   if [ $? -ne 0 ]; then
> +   bberror "Could not locate BSP definition for 
> ${KMACHINE}/${LINUX_KERNEL_TYPE} and no defconfig was provided"
> +   fi
> fi
> meta_dir=$(kgit --meta)
>
> --
> 2.5.0
>
> --
> ___
> 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] ca-certificates: prevent executing update-ca-certificates from host system

2017-08-23 Thread Khem Raj

On 8/23/17 5:44 AM, Richard Purdie wrote:
> On Wed, 2017-08-23 at 14:07 +0200, Andrej Valek wrote:
>> I have found out that even master with HOSTTOOLS does not fix my
>> problem.
>> We use ASSUME_PROVIDED for ca-certificates-native due to corporate
>> environment CAs.
>> Since nativesdk-ca-certificates depends on ca-certificates-native
>> whichis not built, so it could not be found. Unfortunately adding
>> update-ca-certificates to HOSTTOOLS is not working, since build user
>> does not have permissions to modify system CAs and also is in
>> /usr/sbin/ which is not in usual system path.
>>
>> Therefore I think that this patch applies for master branch, too.
>> Possible improvement would be also removing ca-certificates-native
>> from DEPENDS of class-nativesdk.
>>
>> Solution of installing corporate CAs within OE recipe does not seem
>> to be ideal, because the CAs have short expiration date. So using
>> system CAs assures reachability of resources over https.
>> We had to do this because svn fetcher uses https without option to
>> ignore errors (unlike wget which ignores certificates by default).
> 
> Reading this made me realise this is a pretty complex issue. In general
> we cannot assume that we can execute nativesdk binaries. Since ca-
> certificates is allarch and we're executing an sh script, this is less
> of an issue in this very specific case. There is a binary involved,
> c_rehash and we do need to make sure there are the right -native
> dependencies to get that.


c_rehash comes from openssl-native in this case.

> 
> There is a further complication with regard to the paths used, ca-
> certificates-native will use one set of paths, nativesdk-ca-
> certificates will use a different set and target ca-certificates a
> differnt set again.
> 
> I suspect you're right and the ca-certificates-native dependency may be
> incorrect and the certs installed into sdks may be broken too. If the
> native sysroot and target sysroot layouts don't match, that would cause
> an additional source of errors.
> 
> So some changes in this area does appear to be needed...
> 
> Cheers,
> 
> Richard
> 
> 

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

Re: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built

2017-08-23 Thread Bruce Ashfield


On 08/23/2017 02:31 PM, Denys Dmytriyenko wrote:

On Sun, Aug 20, 2017 at 10:58:21PM -0400, Bruce Ashfield wrote:

There was a bug in the search routines responsible for locating
BSP definitions which returned a valid match if only the ktype
matched.

This meant that someone looking for "qemux86foo" (which is an
invalid definition) would potentially end up building "qemuarm"
and be none the wiser (until it didn't boot).

With this fix to the tools search routine, and improved return
code testing, we will now stop the build and report and error to
the user.

[YOCTO: #11878]

Signed-off-by: Bruce Ashfield 
---
  meta/classes/kernel-yocto.bbclass   | 3 +++
  meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
  2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 1ca0756c4959..3c6df92131bc 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -143,6 +143,9 @@ do_kernel_metadata() {
  
  	# expand kernel features into their full path equivalents

bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} 
-DKTYPE=${LINUX_KERNEL_TYPE})
+   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
+   bbfatal_log "Could not locate BSP definiton for 
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+   fi
meta_dir=$(kgit --meta)
  
  	# run1: pull all the configuration fragments, no matter where they come from

diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb 
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 2217a31076a2..4a78b897d34f 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = 
"file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
  
  DEPENDS = "git-native"
  
-SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c"

+SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83"


My builds last night of poky+meta-ti all failed with:

DEBUG: Running ... git -c core.fsyncobjectfiles=0 clone -s -n 
/OE/poky-master/downloads/git2/git.yoctoproject.org.yocto-kernel-tools.git/ 
/OE/poky-master/build/tmp/work/x86_64-linux/kern-tools-native/0.2+gitAUTOINC+0571411cc0-r12/git/
DEBUG: Running ... git -c core.fsyncobjectfiles=0 remote set-url origin 
git://git.yoctoproject.org/yocto-kernel-tools.git
DEBUG: Running ... git -c core.fsyncobjectfiles=0 checkout -B master 
0571411cc033c11df7827508dd786876ce2f8c83
ERROR: Fetcher failure: Fetch command ... git -c core.fsyncobjectfiles=0 
checkout -B master 0571411cc033c11df7827508dd786876ce2f8c83 failed with exit 
code 128, output:
fatal: reference is not a tree: 0571411cc033c11df7827508dd786876ce2f8c83


I haven't seen this one, but I did just confirm manually that that
SRCREV is in the upstream repo.

Did some sort of mirroring get in the way ?

Bruce





  PR = "r12"
  PV = "0.2+git${SRCPV}"
  
--

2.5.0

--
___
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] kernel-yocto: relax BSP definition test

2017-08-23 Thread Bruce Ashfield

commit 44aea7b873 [kernel-yocto: ensure that only valid BSPs are built]
introduced a new check to ensure that a valid BSP definition was found,
rather than building something that 'closely' matched the current
MACHINE.

This check breaks valid configurations which do not have a bsp
definition but are otherwise completely configured machines.

To allow both elements to co-exist (and not add warnings or errors
to otherwise valid builds), we first check to see if an empty bsp
definition was found, but then check to see if a defconfig was
provided.

If a defconfig has been provided, that is a sign that the board
configuration is complete and we should continue the build without
otherwise bothering the user.

Tested on meta-raspberrypi and linux-yocto*

Signed-off-by: Bruce Ashfield 
---
 meta/classes/kernel-yocto.bbclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 3c6df92131bc..d68e720589dc 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -143,8 +143,11 @@ do_kernel_metadata() {
 
# expand kernel features into their full path equivalents
bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} 
-DKTYPE=${LINUX_KERNEL_TYPE})
-   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
-   bbfatal_log "Could not locate BSP definiton for 
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+   if [ -z "$bsp_definition" ]; then
+   echo -q "$sccs" | grep defconfig
+   if [ $? -ne 0 ]; then
+   bberror "Could not locate BSP definition for 
${KMACHINE}/${LINUX_KERNEL_TYPE} and no defconfig was provided"
+   fi
fi
meta_dir=$(kgit --meta)
 
-- 
2.5.0

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

[OE-core] [PATCH 0/2] poky: update default kernel to 4.12 and lsb to 4.9

2017-08-23 Thread Bruce Ashfield

Hi all,

To match the pull request to oe-core that adds the 4.12 kernel and removes
the 4.1 kernel these two patches bump the default kernel to 4.12 and also
update LSB to use the 4.9 kernel.

Build and boot testing was performed on all qemu architectures.

Cheers,

Bruce

The following changes since commit 847d9000180cafedb23c60a6673adcec62ca67a1:

  linux-yocto/4.10: CVE & misc fixes (2017-08-20 22:38:46 -0400)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel-yocto
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-yocto

Bruce Ashfield (2):
  poky: bump preferred version of linux-yocto to 4.12
  poky: bump poky lsb to linux 4.9

 meta-poky/conf/distro/poky-lsb.conf | 2 +-
 meta-poky/conf/distro/poky.conf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.5.0

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

Re: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built

2017-08-23 Thread Denys Dmytriyenko

On Sun, Aug 20, 2017 at 10:58:21PM -0400, Bruce Ashfield wrote:
> There was a bug in the search routines responsible for locating
> BSP definitions which returned a valid match if only the ktype
> matched.
> 
> This meant that someone looking for "qemux86foo" (which is an
> invalid definition) would potentially end up building "qemuarm"
> and be none the wiser (until it didn't boot).
> 
> With this fix to the tools search routine, and improved return
> code testing, we will now stop the build and report and error to
> the user.
> 
> [YOCTO: #11878]
> 
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/classes/kernel-yocto.bbclass   | 3 +++
>  meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/kernel-yocto.bbclass 
> b/meta/classes/kernel-yocto.bbclass
> index 1ca0756c4959..3c6df92131bc 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -143,6 +143,9 @@ do_kernel_metadata() {
>  
>   # expand kernel features into their full path equivalents
>   bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} 
> -DKTYPE=${LINUX_KERNEL_TYPE})
> + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
> + bbfatal_log "Could not locate BSP definiton for 
> ${KMACHINE}/${LINUX_KERNEL_TYPE}."
> + fi
>   meta_dir=$(kgit --meta)
>  
>   # run1: pull all the configuration fragments, no matter where they come 
> from
> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb 
> b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> index 2217a31076a2..4a78b897d34f 100644
> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = 
> "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
>  
>  DEPENDS = "git-native"
>  
> -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c"
> +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83"

My builds last night of poky+meta-ti all failed with:

DEBUG: Running ... git -c core.fsyncobjectfiles=0 clone -s -n 
/OE/poky-master/downloads/git2/git.yoctoproject.org.yocto-kernel-tools.git/ 
/OE/poky-master/build/tmp/work/x86_64-linux/kern-tools-native/0.2+gitAUTOINC+0571411cc0-r12/git/
DEBUG: Running ... git -c core.fsyncobjectfiles=0 remote set-url origin 
git://git.yoctoproject.org/yocto-kernel-tools.git
DEBUG: Running ... git -c core.fsyncobjectfiles=0 checkout -B master 
0571411cc033c11df7827508dd786876ce2f8c83
ERROR: Fetcher failure: Fetch command ... git -c core.fsyncobjectfiles=0 
checkout -B master 0571411cc033c11df7827508dd786876ce2f8c83 failed with exit 
code 128, output:
fatal: reference is not a tree: 0571411cc033c11df7827508dd786876ce2f8c83

   


>  PR = "r12"
>  PV = "0.2+git${SRCPV}"
>  
> -- 
> 2.5.0
> 
> -- 
> ___
> 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 7/7] sysprof: convert to meson build

2017-08-23 Thread Andre McCurdy

On Wed, Aug 23, 2017 at 10:06 AM, Alexander Kanavin
 wrote:
> Drop autotools-specific patches.
>
> Rename polkit packageconfig option to sysprofd as 'polkit' does not
> at all match what is happening.
>
> Remove --enable-compiler-warnings, as the equivalent in meson
> could not be found.
>
> Signed-off-by: Alexander Kanavin 
> ---
>  .../sysprof/files/0001-Avoid-building-docs.patch   | 42 
> --
>  .../0001-Disable-check-for-polkit-for-UI.patch | 32 -
>  ...d-anything-in-help-as-it-requires-itstool.patch | 26 ++
>  ...igure-Add-option-to-enable-disable-polkit.patch | 41 -
>  ...-not-prepend-the-current-dir-path-to-util.patch | 30 
>  meta/recipes-kernel/sysprof/sysprof_3.24.1.bb  | 22 ++--
>  6 files changed, 68 insertions(+), 125 deletions(-)
>  delete mode 100644 
> meta/recipes-kernel/sysprof/files/0001-Avoid-building-docs.patch
>  delete mode 100644 
> meta/recipes-kernel/sysprof/files/0001-Disable-check-for-polkit-for-UI.patch
>  create mode 100644 
> meta/recipes-kernel/sysprof/files/0001-Do-not-build-anything-in-help-as-it-requires-itstool.patch
>  delete mode 100644 
> meta/recipes-kernel/sysprof/files/0001-configure-Add-option-to-enable-disable-polkit.patch
>  create mode 100644 
> meta/recipes-kernel/sysprof/files/0002-Do-not-prepend-the-current-dir-path-to-util.patch
>
> diff --git a/meta/recipes-kernel/sysprof/files/0001-Avoid-building-docs.patch 
> b/meta/recipes-kernel/sysprof/files/0001-Avoid-building-docs.patch
> deleted file mode 100644
> index 202f354d29c..000
> --- a/meta/recipes-kernel/sysprof/files/0001-Avoid-building-docs.patch
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -From 27df521c68e7c8b5b050dab15f40aa15fd03623a Mon Sep 17 00:00:00 2001
> -From: Jussi Kukkonen 
> -Date: Wed, 4 May 2016 14:58:24 +0300
> -Subject: [PATCH] Avoid building docs
> -
> -Upstream-Status: Inappropriate
> -Signed-off-by: Jussi Kukkonen 
> 
> - Makefile.am | 2 +-
> - m4/yelp.m4  | 6 --
> - 2 files changed, 1 insertion(+), 7 deletions(-)
> -
> -diff --git a/Makefile.am b/Makefile.am
> -index b919a3f..3a3851d 100644
>  a/Makefile.am
> -+++ b/Makefile.am
> -@@ -1,4 +1,4 @@
> --SUBDIRS = daemon data help lib po src tools tests
> -+SUBDIRS = daemon data lib po src tools tests
> -
> - EXTRA_DIST = AUTHORS tap-test COPYING.gpl-2
> -
> -diff --git a/m4/yelp.m4 b/m4/yelp.m4
> -index 5db847f..1b6ede4 100644
>  a/m4/yelp.m4
> -+++ b/m4/yelp.m4
> -@@ -27,12 +27,6 @@ AC_ARG_WITH([help-dir],
> - HELP_DIR="$with_help_dir"
> - AC_SUBST(HELP_DIR)
> -
> --AC_ARG_VAR([ITSTOOL], [Path to the `itstool` command])
> --AC_CHECK_PROG([ITSTOOL], [itstool], [itstool])
> --if test x"$ITSTOOL" = x; then
> --  AC_MSG_ERROR([itstool not found])
> --fi
> --
> - AC_ARG_VAR([XMLLINT], [Path to the `xmllint` command])
> - AC_CHECK_PROG([XMLLINT], [xmllint], [xmllint])
> - if test x"$XMLLINT" = x; then
> ---
> -2.1.4
> -
> diff --git 
> a/meta/recipes-kernel/sysprof/files/0001-Disable-check-for-polkit-for-UI.patch
>  
> b/meta/recipes-kernel/sysprof/files/0001-Disable-check-for-polkit-for-UI.patch
> deleted file mode 100644
> index 608523272ad..000
> --- 
> a/meta/recipes-kernel/sysprof/files/0001-Disable-check-for-polkit-for-UI.patch
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -From 765d578145e31ddc9495adfab8037ade33c6a9cc Mon Sep 17 00:00:00 2001
> -From: Jussi Kukkonen 
> -Date: Wed, 4 May 2016 10:59:36 +0300
> -Subject: [PATCH] Disable check for polkit for UI
> -
> -The check is not technically required: sysprof just needs
> -to be able to access system perf counters at runtime.
> -
> -Upstream-Status: Pending
> -Signed-off-by: Jussi Kukkonen 
> 
> - configure.ac | 4 ++--
> - 1 file changed, 2 insertions(+), 2 deletions(-)
> -
> -diff --git a/configure.ac b/configure.ac
> -index 8559597..ecf93ad 100644
>  a/configure.ac
> -+++ b/configure.ac
> -@@ -131,8 +131,8 @@ AS_IF([test "$enable_gtk" = auto],[
> -   AS_IF([test "$have_gtk" = "yes" && test "$have_polkit" = 
> "yes"],[enable_gtk=yes],[enable_gtk=no])
> - ])
> - AS_IF([test "$enable_gtk" = "yes"],[
> --  AS_IF([test "$have_gtk" = "yes" && test "$have_polkit" = "yes"],[],[
> --  AC_MSG_ERROR([--enable-gtk requires gtk+-3.0 >= 
> gtk_required_version and polkit-gobject-1])
> -+  AS_IF([test "$have_gtk" = "yes"],[],[
> -+  AC_MSG_ERROR([--enable-gtk requires gtk+-3.0 >= 
> gtk_required_version])
> -   ])
> - ])
> - AM_CONDITIONAL(ENABLE_GTK, test "$enable_gtk" = "yes")
> ---
> -2.8.1
> -
> diff --git 
> a/meta/recipes-kernel/sysprof/files/0001-Do-not-build-anything-in-help-as-it-requires-itstool.patch
>  
> b/meta/recipes-kernel/sysprof/files/0001-Do-not-build-anything-in-help-as-it-requires-itstool.patch
> new file mode 100644
> index

Re: [OE-core] Fwd: kernel-yocto class requires BSP definition now

2017-08-23 Thread Bruce Ashfield

On Wed, Aug 23, 2017 at 1:18 PM, Andrei Gherzan  wrote:

> On Wed, Aug 23, 2017 at 6:08 PM, Bruce Ashfield 
> wrote:
>
>>
>>
>> On Wed, Aug 23, 2017 at 1:01 PM, Andrei Gherzan 
>> wrote:
>>
>>> On Wed, Aug 23, 2017 at 5:54 PM, Bruce Ashfield <
>>> bruce.ashfi...@windriver.com> wrote:
>>>
 Already discussed with Khem and Richard in the original
 thread.

 I'm sending another patch shortly to back this off to a note/warning.


>>> That is nice but wouldn't that clutter the build logs for no reason? For
>>> people who don't take advantage of scc definitions that is. Could you point
>>> me to the initial discussion? Just want to understand and maybe vote to
>>> remove it altogether.
>>>
>>
>> It's a yocto bug. We need to flag BSP definitions that aren't valid,
>> otherwise the tools
>> will end up building things like qemuarm for someone that has a
>> misconfigured BSP.
>>
>> If you don't have a defconfig (as someone won't have if they are using a
>> fully defined
>> BSP, but with the wrong name) and the wrong entry point, or no entry
>> point, is returned
>> we have to flag it.
>>
>> The actual bug is: 11878, and there's a related fallout of that bad
>> definition.
>>
>> So no, it won't be deleted, but I will make it check for a few more
>> parameters before
>> erroring or logging.
>>
>
> That makes sense. Thanks for clarifying. I'll keep an eye on the ml for
> the fix.
>

It'll arrive shortly, testing it now.

It shouldn't put anything in your logs during the build now, I'm just
building the rpi3 to
confirm and re-testing a case that I want to fail :D

Bruce


>
> --
> Andrei Gherzan
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Fwd: kernel-yocto class requires BSP definition now

2017-08-23 Thread Andrei Gherzan

On Wed, Aug 23, 2017 at 6:08 PM, Bruce Ashfield 
wrote:

>
>
> On Wed, Aug 23, 2017 at 1:01 PM, Andrei Gherzan  wrote:
>
>> On Wed, Aug 23, 2017 at 5:54 PM, Bruce Ashfield <
>> bruce.ashfi...@windriver.com> wrote:
>>
>>> Already discussed with Khem and Richard in the original
>>> thread.
>>>
>>> I'm sending another patch shortly to back this off to a note/warning.
>>>
>>>
>> That is nice but wouldn't that clutter the build logs for no reason? For
>> people who don't take advantage of scc definitions that is. Could you point
>> me to the initial discussion? Just want to understand and maybe vote to
>> remove it altogether.
>>
>
> It's a yocto bug. We need to flag BSP definitions that aren't valid,
> otherwise the tools
> will end up building things like qemuarm for someone that has a
> misconfigured BSP.
>
> If you don't have a defconfig (as someone won't have if they are using a
> fully defined
> BSP, but with the wrong name) and the wrong entry point, or no entry
> point, is returned
> we have to flag it.
>
> The actual bug is: 11878, and there's a related fallout of that bad
> definition.
>
> So no, it won't be deleted, but I will make it check for a few more
> parameters before
> erroring or logging.
>

That makes sense. Thanks for clarifying. I'll keep an eye on the ml for the
fix.

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

Re: [OE-core] pkgconfig vs pkgconf

2017-08-23 Thread Mark Hatle

On 8/23/17 11:57 AM, Khem Raj wrote:
> 
> On Wed, Aug 23, 2017 at 9:19 AM Mark Hatle  > wrote:
> 
> On 8/23/17 10:46 AM, Mark Hatle wrote:
> > As of this morning, I'm not getting a warning about a preferred 
> provider being
> 
> typo.. 'I'm -NOW- getting a warning'
> 
> sorry for the confusion...
> 
> > necessary to differentiate between pkgconfig and pkgconf.
> >
> > I've set the following to make it "go away".  But I assume we need to 
> set a
> > default somewhere in the system...
> >
> > PREFERRED_PROVIDER_pkconfig = "pkgconfig"
> > PREFERRED_PROVIDER_pkgconfig-native = "pkgconfig-native"
> >
> > PREFERRED_RPROVIDER_pkgconfig = "pkgconfig"
> >
> 
> 
> How about nativesdk ? I filed a bug for this earlier 

didn't show up in my specific use-case, but I wasn't building an SDK.

--Mark

> 
> --
> ___
> 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 5/7] libepoxy: convert to meson build

2017-08-23 Thread Alexander Kanavin

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb 
b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
index c8b398f1766..5ec96b1c663 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
@@ -10,12 +10,12 @@ SRC_URI[md5sum] = "af4c3ce0fb1143bdc4e43f85695a9bed"
 SRC_URI[sha256sum] = 
"0b808a06c9685a62fca34b680abb8bc7fb2fda074478e329b063c1f872b826f6"
 UPSTREAM_CHECK_URI = "https://github.com/anholt/libepoxy/releases;
 
-inherit autotools pkgconfig distro_features_check
+inherit meson pkgconfig distro_features_check
 
 REQUIRED_DISTRO_FEATURES = "opengl"
 
 DEPENDS = "util-macros"
 
-PACKAGECONFIG[egl] = "--enable-egl, --disable-egl, virtual/egl"
-PACKAGECONFIG[x11] = "--enable-glx, --disable-glx, virtual/libx11"
+PACKAGECONFIG[egl] = "-Denable-egl=yes, -Denable-egl=no, virtual/egl"
+PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
-- 
2.14.1

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

[OE-core] [PATCH 6/7] libinput: convert to meson build

2017-08-23 Thread Alexander Kanavin

Drop autotools-specific patch.

Drop libunwind option, as it is only used if tests are enabled
(and they're unconditionally not enabled).

Signed-off-by: Alexander Kanavin 
---
 .../0001-tools-Fix-race-in-autotools-install.patch | 37 --
 meta/recipes-graphics/wayland/libinput_1.8.1.bb| 10 +++---
 2 files changed, 4 insertions(+), 43 deletions(-)
 delete mode 100644 
meta/recipes-graphics/wayland/libinput/0001-tools-Fix-race-in-autotools-install.patch

diff --git 
a/meta/recipes-graphics/wayland/libinput/0001-tools-Fix-race-in-autotools-install.patch
 
b/meta/recipes-graphics/wayland/libinput/0001-tools-Fix-race-in-autotools-install.patch
deleted file mode 100644
index 4667538c5eb..000
--- 
a/meta/recipes-graphics/wayland/libinput/0001-tools-Fix-race-in-autotools-install.patch
+++ /dev/null
@@ -1,37 +0,0 @@
-From 5e8864c5b7a2e258eea041b0ef66dac7fcab9b7f Mon Sep 17 00:00:00 2001
-From: Jussi Kukkonen 
-Date: Wed, 9 Aug 2017 09:47:14 +0300
-Subject: [PATCH] tools: Fix race in (autotools) install
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-exec/data distinction is done based on install dir so compat scripts
-must be moved in exec hook.
-
-This should fix this occasional failure:
-| install: cannot change permissions of
-| ‘/usr/bin/libinput-debug-events.compat’: No such file or directory
-
-Signed-off-by: Jussi Kukkonen 
-Upstream-Status: Submitted

- tools/Makefile.am | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/tools/Makefile.am b/tools/Makefile.am
-index 2c8660b..7ee8b90 100644
 a/tools/Makefile.am
-+++ b/tools/Makefile.am
-@@ -63,7 +63,7 @@ endif
- 
- EXTRA_DIST = make-ptraccel-graphs.sh install-compat-scripts.sh $(bin_SCRIPTS)
- 
--install-data-hook:
-+install-exec-hook:
-   (cd $(DESTDIR)$(bindir) && mv libinput-list-devices.compat 
libinput-list-devices)
-   (cd $(DESTDIR)$(bindir) && mv libinput-debug-events.compat 
libinput-debug-events)
- 
--- 
-2.13.3
-
diff --git a/meta/recipes-graphics/wayland/libinput_1.8.1.bb 
b/meta/recipes-graphics/wayland/libinput_1.8.1.bb
index f75298b899d..3217cc74375 100644
--- a/meta/recipes-graphics/wayland/libinput_1.8.1.bb
+++ b/meta/recipes-graphics/wayland/libinput_1.8.1.bb
@@ -9,22 +9,20 @@ DEPENDS = "libevdev udev mtdev"
 
 SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \

file://touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch \
-   file://0001-tools-Fix-race-in-autotools-install.patch \
 "
 
 SRC_URI[md5sum] = "8247f0bb67052ffb272c50c3cb9c5998"
 SRC_URI[sha256sum] = 
"e3590a9037e561a5791c8bd3b34bfd30fad5cacd8cbefc0d75fafe3a41d07147"
 
-inherit autotools pkgconfig lib_package
+inherit meson pkgconfig lib_package
 
 PACKAGECONFIG ??= ""
-PACKAGECONFIG[libunwind] = "--with-libunwind,--without-libunwind,libunwind"
-PACKAGECONFIG[libwacom] = "--enable-libwacom,--disable-libwacom,libwacom"
-PACKAGECONFIG[gui] = "--enable-debug-gui,--disable-debug-gui,cairo gtk+3"
+PACKAGECONFIG[libwacom] = "-Dlibwacom=true,-Dlibwacom=false,libwacom"
+PACKAGECONFIG[gui] = "-Ddebug-gui=true,-Ddebug-gui=false,cairo gtk+3"
 
 UDEVDIR = "`pkg-config --variable=udevdir udev`"
 
-EXTRA_OECONF += "--with-udev-dir=${UDEVDIR} --disable-documentation 
--disable-tests"
+EXTRA_OEMESON += "-Dudev-dir=${UDEVDIR} -Ddocumentation=false -Dtests=false"
 
 # package name changed in 1.8.1 upgrade: make sure package upgrades work
 RPROVIDES_${PN} = "libinput"
-- 
2.14.1

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

[OE-core] [PATCH 4/7] json-glib: convert to meson build

2017-08-23 Thread Alexander Kanavin

Note that meson flags for gobject introspection and gtk-doc
appear to be non-standardized; going forward we should devise
a common way to deal with it.

Signed-off-by: Alexander Kanavin 
---
 ...ble-gobject-introspection-when-cross-comp.patch | 32 ++
 meta/recipes-gnome/json-glib/json-glib_1.2.8.bb| 23 ++--
 2 files changed, 53 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-gnome/json-glib/json-glib/0001-Do-not-disable-gobject-introspection-when-cross-comp.patch

diff --git 
a/meta/recipes-gnome/json-glib/json-glib/0001-Do-not-disable-gobject-introspection-when-cross-comp.patch
 
b/meta/recipes-gnome/json-glib/json-glib/0001-Do-not-disable-gobject-introspection-when-cross-comp.patch
new file mode 100644
index 000..849bb9d3165
--- /dev/null
+++ 
b/meta/recipes-gnome/json-glib/json-glib/0001-Do-not-disable-gobject-introspection-when-cross-comp.patch
@@ -0,0 +1,32 @@
+From 293452c963188666dae99521294f09a0cf9582e2 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Fri, 4 Aug 2017 16:01:11 +0300
+Subject: [PATCH] Do not disable gobject introspection when cross-compiling.
+
+Introspection does work fine for instance in Open Embedded,
+one of the most prominent cross-compilation frameworks
+(through qemu emulating target hardware), so let the user
+decide if he wants the feature or not.
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin 
+---
+ meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index 43cbfd9..8a32f26 100644
+--- a/meson.build
 b/meson.build
+@@ -147,7 +147,7 @@ root_dir = include_directories('.')
+ 
+ gnome = import('gnome')
+ gir = find_program('g-ir-scanner', required: false)
+-build_gir = gir.found() and not meson.is_cross_build() and not 
get_option('disable_introspection')
++build_gir = gir.found() and not get_option('disable_introspection')
+ 
+ subdir('json-glib')
+ 
+-- 
+2.13.2
+
diff --git a/meta/recipes-gnome/json-glib/json-glib_1.2.8.bb 
b/meta/recipes-gnome/json-glib/json-glib_1.2.8.bb
index 2c5d3817ba7..bf37015b03f 100644
--- a/meta/recipes-gnome/json-glib/json-glib_1.2.8.bb
+++ b/meta/recipes-gnome/json-glib/json-glib_1.2.8.bb
@@ -10,11 +10,30 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34"
 
 DEPENDS = "glib-2.0"
 
+SRC_URI += " \
+   
file://0001-Do-not-disable-gobject-introspection-when-cross-comp.patch \
+   "
 SRC_URI[archive.md5sum] = "ff31e7d0594df44318e12facda3d086e"
 SRC_URI[archive.sha256sum] = 
"fd55a9037d39e7a10f0db64309f5f0265fa32ec962bf85066087b83a2807f40a"
 
-inherit gnomebase gettext lib_package gobject-introspection gtk-doc manpages
+inherit gnomebase-meson lib_package gobject-introspection gtk-doc manpages
 
-PACKAGECONFIG[manpages] = "--enable-man 
--with-xml-catalog=${STAGING_ETCDIR_NATIVE}/xml/catalog.xml, --disable-man, 
libxslt-native xmlto-native"
+GTKDOC_ENABLE_FLAG = "-Denable-gtk-doc=true"
+GTKDOC_DISABLE_FLAG = "-Denable-gtk-doc=false"
+
+GI_ENABLE_FLAG = "-Ddisable_introspection=false"
+GI_DISABLE_FLAG = "-Ddisable_introspection=true"
+
+EXTRA_OEMESON_append_class-target = " ${@bb.utils.contains('GTKDOC_ENABLED', 
'True', '${GTKDOC_ENABLE_FLAG}', \
+   
 '${GTKDOC_DISABLE_FLAG}', d)} "
+EXTRA_OEMESON_append_class-target = " ${@bb.utils.contains('GI_DATA_ENABLED', 
'True', '${GI_ENABLE_FLAG}', \
+   
 '${GI_DISABLE_FLAG}', d)} "
+
+PACKAGECONFIG[manpages] = "-Denable-man=true, -Denable-man=false, 
libxslt-native xmlto-native"
+
+do_install_append() {
+# FIXME: these need to be provided via ptest
+rm -rf ${D}${datadir}/installed-tests ${D}${libexecdir}
+}
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.14.1

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

[OE-core] [PATCH 2/7] gnomebase.bbclass: split into autotools and meson versions

2017-08-23 Thread Alexander Kanavin

gnomebase.bbclass unfortunately hardcodes the autotools inherit,
so we have to introduce gnomebase-nobuildsystem.bbclass where
the common bits between autotools and meson classes can be placed.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/gnomebase-meson.bbclass |  1 +
 meta/classes/gnomebase-nobuildsystem.bbclass | 27 +
 meta/classes/gnomebase.bbclass   | 30 +---
 3 files changed, 29 insertions(+), 29 deletions(-)
 create mode 100644 meta/classes/gnomebase-meson.bbclass
 create mode 100644 meta/classes/gnomebase-nobuildsystem.bbclass

diff --git a/meta/classes/gnomebase-meson.bbclass 
b/meta/classes/gnomebase-meson.bbclass
new file mode 100644
index 000..6cb97397572
--- /dev/null
+++ b/meta/classes/gnomebase-meson.bbclass
@@ -0,0 +1 @@
+inherit meson gnomebase-nobuildsystem
diff --git a/meta/classes/gnomebase-nobuildsystem.bbclass 
b/meta/classes/gnomebase-nobuildsystem.bbclass
new file mode 100644
index 000..2ea7367a83a
--- /dev/null
+++ b/meta/classes/gnomebase-nobuildsystem.bbclass
@@ -0,0 +1,27 @@
+def gnome_verdir(v):
+return oe.utils.trim_version(v, 2)
+
+GNOME_COMPRESS_TYPE ?= "xz"
+SECTION ?= "x11/gnome"
+GNOMEBN ?= "${BPN}"
+SRC_URI = 
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive"
+
+FILES_${PN} += "${datadir}/application-registry  \
+${datadir}/mime-info \
+${datadir}/mime/packages \
+${datadir}/mime/application \
+${datadir}/gnome-2.0 \
+${datadir}/polkit* \
+${datadir}/GConf \
+${datadir}/glib-2.0/schemas \
+${datadir}/appdata \
+${datadir}/icons \
+"
+
+FILES_${PN}-doc += "${datadir}/devhelp"
+
+do_install_append() {
+   rm -rf ${D}${localstatedir}/lib/scrollkeeper/*
+   rm -rf ${D}${localstatedir}/scrollkeeper/*
+   rm -f ${D}${datadir}/applications/*.cache
+}
diff --git a/meta/classes/gnomebase.bbclass b/meta/classes/gnomebase.bbclass
index 4ccc8e07814..84756aea1ec 100644
--- a/meta/classes/gnomebase.bbclass
+++ b/meta/classes/gnomebase.bbclass
@@ -1,29 +1 @@
-def gnome_verdir(v):
-return oe.utils.trim_version(v, 2)
-
-GNOME_COMPRESS_TYPE ?= "xz"
-SECTION ?= "x11/gnome"
-GNOMEBN ?= "${BPN}"
-SRC_URI = 
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive"
-
-FILES_${PN} += "${datadir}/application-registry  \
-${datadir}/mime-info \
-${datadir}/mime/packages \
-${datadir}/mime/application \
-${datadir}/gnome-2.0 \
-${datadir}/polkit* \
-${datadir}/GConf \
-${datadir}/glib-2.0/schemas \
-${datadir}/appdata \
-${datadir}/icons \
-"
-
-FILES_${PN}-doc += "${datadir}/devhelp"
-
-inherit autotools pkgconfig
-
-do_install_append() {
-   rm -rf ${D}${localstatedir}/lib/scrollkeeper/*
-   rm -rf ${D}${localstatedir}/scrollkeeper/*
-   rm -f ${D}${datadir}/applications/*.cache
-}
+inherit autotools pkgconfig gnomebase-nobuildsystem
-- 
2.14.1

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

[OE-core] [PATCH 3/7] gtk-doc.bbclass: add all directories where .so files are found to library search path

2017-08-23 Thread Alexander Kanavin

This should reduce the need to manually specify the path in recipes.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/gtk-doc.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/gtk-doc.bbclass b/meta/classes/gtk-doc.bbclass
index 0ae2729c0a0..906ce7854a9 100644
--- a/meta/classes/gtk-doc.bbclass
+++ b/meta/classes/gtk-doc.bbclass
@@ -48,6 +48,7 @@ do_compile_prepend_class-target () {
 # which may then get deleted (or their dependencies) and potentially segfault
 export GIO_MODULE_DIR=${STAGING_LIBDIR}/gio/modules-dummy
 
+GIR_EXTRA_LIBS_PATH=\`find ${B} -name *.so -printf %h| tr '\n' 
':'\`\$GIR_EXTRA_LIBS_PATH
 GIR_EXTRA_LIBS_PATH=\`find ${B} -name .libs| tr '\n' ':'\`\$GIR_EXTRA_LIBS_PATH
 
 if [ -d ".libs" ]; then
-- 
2.14.1

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

[OE-core] [PATCH 1/7] meson: add a recipe and class from meta-oe

2017-08-23 Thread Alexander Kanavin

The original recipe has been provided and improved by:

Ross Burton 
Ricardo Ribalda Delgado 
Adam C. Foltzer 
Peter Kjellerstedt 
Linus Svensson 

I have added a couple patches to fix up gtk-doc and
gobject-introspection in cross-compilation environments.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/meson.bbclass | 103 +++
 ...ix-issues-that-arise-when-cross-compiling.patch | 113 +
 ...rospection-determine-g-ir-scanner-and-g-i.patch |  41 
 meta/recipes-devtools/meson/meson_0.42.0.bb|  18 
 4 files changed, 275 insertions(+)
 create mode 100644 meta/classes/meson.bbclass
 create mode 100644 
meta/recipes-devtools/meson/meson/0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0002-gobject-introspection-determine-g-ir-scanner-and-g-i.patch
 create mode 100644 meta/recipes-devtools/meson/meson_0.42.0.bb

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
new file mode 100644
index 000..f6cf24c33a7
--- /dev/null
+++ b/meta/classes/meson.bbclass
@@ -0,0 +1,103 @@
+inherit python3native
+
+DEPENDS_append = " meson-native ninja-native"
+
+# As Meson enforces out-of-tree builds we can just use cleandirs
+B = "${WORKDIR}/build"
+do_configure[cleandirs] = "${B}"
+
+# Where the meson.build build configuration is
+MESON_SOURCEPATH = "${S}"
+
+# These variables in the environment override meson's *native* tools settings.
+# We have to unset them, so that meson doesn't pick up the cross tools and
+# use them for native builds.
+unset CC
+unset CXX
+unset AR
+
+def noprefix(var, d):
+return d.getVar(var, True).replace(d.getVar('prefix', True) + '/', '', 1)
+
+MESONOPTS = " --prefix ${prefix} \
+  --bindir ${@noprefix('bindir', d)} \
+  --sbindir ${@noprefix('sbindir', d)} \
+  --datadir ${@noprefix('datadir', d)} \
+  --libdir ${@noprefix('libdir', d)} \
+  --libexecdir ${@noprefix('libexecdir', d)} \
+  --includedir ${@noprefix('includedir', d)} \
+  --mandir ${@noprefix('mandir', d)} \
+  --infodir ${@noprefix('infodir', d)} \
+  --sysconfdir ${sysconfdir} \
+  --localstatedir ${localstatedir} \
+  --sharedstatedir ${sharedstatedir}"
+
+MESON_C_ARGS = "${TARGET_CC_ARCH}${TOOLCHAIN_OPTIONS}"
+MESON_LINK_ARGS = "${MESON_C_ARGS} ${LDFLAGS}"
+
+MESON_HOST_ENDIAN = "${@bb.utils.contains('SITEINFO_ENDIANNESS', 'be', 'big', 
'little', d)}"
+MESON_TARGET_ENDIAN = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 
'big', 'little', d)}"
+
+EXTRA_OEMESON += "${PACKAGECONFIG_CONFARGS}"
+
+MESON_CROSS_FILE = ""
+MESON_CROSS_FILE_class-target = "--cross-file ${WORKDIR}/meson.cross"
+
+def meson_array(var, d):
+return "', '".join(d.getVar(var, True).split()).join(("'", "'"))
+
+addtask write_config before do_configure
+do_write_config[vardeps] += "MESON_C_ARGS TOOLCHAIN_OPTIONS"
+do_write_config() {
+# This needs to be Py to split the args into single-element lists
+cat >${WORKDIR}/meson.cross <
+Date: Fri, 4 Aug 2017 16:16:41 +0300
+Subject: [PATCH 1/3] gtkdoc: fix issues that arise when cross-compiling
+
+Specifically:
+1) Make it possible to specify a wrapper for executing binaries
+(usually, some kind of target hardware emulator, such as qemu)
+2) Explicitly provide CC and LD via command line, as otherwise gtk-doc will
+try to guess them, incorrectly.
+3) If things break down, print the full command with arguments,
+not just the binary name.
+4) Correctly determine the compiler/linker executables and cross-options when 
cross-compiling
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin 
+
+---
+ mesonbuild/modules/gnome.py| 18 +++---
+ mesonbuild/scripts/gtkdochelper.py |  9 +++--
+ 2 files changed, 22 insertions(+), 5 deletions(-)
+
+diff --git a/mesonbuild/modules/gnome.py b/mesonbuild/modules/gnome.py
+index 6ec7040..4cfaefd 100644
+--- a/mesonbuild/modules/gnome.py
 b/mesonbuild/modules/gnome.py
+@@ -713,6 +713,10 @@ class GnomeModule(ExtensionModule):
+ '--mode=' + mode]
+ if namespace:
+ args.append('--namespace=' + namespace)
++gtkdoc_exe_wrapper = 
state.environment.cross_info.config["properties"].get('gtkdoc_exe_wrapper', 
None)
++if gtkdoc_exe_wrapper is not None:
++args.append('--gtkdoc-exe-wrapper=' + gtkdoc_exe_wrapper)
++
+ args += self._unpack_args('--htmlargs=', 'html_args', kwargs)
+ args += self._unpack_args('--scanargs=', 'scan_args', kwargs)
+ args += self._unpack_args('--scanobjsargs=', 'scanobjs_args', kwargs)
+@@ -741,14 +745,22 @@ class GnomeModule(ExtensionModule):
+

[OE-core] [PATCH 0/7] Introduce meson build system

2017-08-23 Thread Alexander Kanavin

This patch series introduces meson recipe and class (that recipes
should inherit in order to be built with meson).

It also converts a few recipes from autotools to meson to establish
that things basically work. Note that I haven't tackled the bigger
items: gstreamer family of recipes, systed and gdk-pixbuf. I'd like
to request that maintainers of these recipes start looking into
the conversion, based on this patchset.

I also didn't test this super-well; there might well be corner cases
where things break down.

The following changes since commit 5f6945f5031e1a4ca116cc1eccf4c2f9dc228547:

  buildhistory.bbclass: add ptest (2017-08-23 14:16:01 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib akanavin/meson
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/meson

Alexander Kanavin (7):
  meson: add a recipe and class from meta-oe
  gnomebase.bbclass: split into autotools and meson versions
  gtk-doc.bbclass: add all directories where .so files are found to
library search path
  json-glib: convert to meson build
  libepoxy: convert to meson build
  libinput: convert to meson build
  sysprof: convert to meson build

 meta/classes/gnomebase-meson.bbclass   |   1 +
 meta/classes/gnomebase-nobuildsystem.bbclass   |  27 +
 meta/classes/gnomebase.bbclass |  30 +-
 meta/classes/gtk-doc.bbclass   |   1 +
 meta/classes/meson.bbclass | 103 +++
 ...ix-issues-that-arise-when-cross-compiling.patch | 113 +
 ...rospection-determine-g-ir-scanner-and-g-i.patch |  41 
 meta/recipes-devtools/meson/meson_0.42.0.bb|  18 
 ...ble-gobject-introspection-when-cross-comp.patch |  32 ++
 meta/recipes-gnome/json-glib/json-glib_1.2.8.bb|  23 -
 meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb   |   6 +-
 .../0001-tools-Fix-race-in-autotools-install.patch |  37 ---
 meta/recipes-graphics/wayland/libinput_1.8.1.bb|  10 +-
 .../sysprof/files/0001-Avoid-building-docs.patch   |  42 
 .../0001-Disable-check-for-polkit-for-UI.patch |  32 --
 ...d-anything-in-help-as-it-requires-itstool.patch |  26 +
 ...igure-Add-option-to-enable-disable-polkit.patch |  41 
 ...-not-prepend-the-current-dir-path-to-util.patch |  30 ++
 meta/recipes-kernel/sysprof/sysprof_3.24.1.bb  |  22 ++--
 19 files changed, 433 insertions(+), 202 deletions(-)
 create mode 100644 meta/classes/gnomebase-meson.bbclass
 create mode 100644 meta/classes/gnomebase-nobuildsystem.bbclass
 create mode 100644 meta/classes/meson.bbclass
 create mode 100644 
meta/recipes-devtools/meson/meson/0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch
 create mode 100644 
meta/recipes-devtools/meson/meson/0002-gobject-introspection-determine-g-ir-scanner-and-g-i.patch
 create mode 100644 meta/recipes-devtools/meson/meson_0.42.0.bb
 create mode 100644 
meta/recipes-gnome/json-glib/json-glib/0001-Do-not-disable-gobject-introspection-when-cross-comp.patch
 delete mode 100644 
meta/recipes-graphics/wayland/libinput/0001-tools-Fix-race-in-autotools-install.patch
 delete mode 100644 
meta/recipes-kernel/sysprof/files/0001-Avoid-building-docs.patch
 delete mode 100644 
meta/recipes-kernel/sysprof/files/0001-Disable-check-for-polkit-for-UI.patch
 create mode 100644 
meta/recipes-kernel/sysprof/files/0001-Do-not-build-anything-in-help-as-it-requires-itstool.patch
 delete mode 100644 
meta/recipes-kernel/sysprof/files/0001-configure-Add-option-to-enable-disable-polkit.patch
 create mode 100644 
meta/recipes-kernel/sysprof/files/0002-Do-not-prepend-the-current-dir-path-to-util.patch

-- 
2.14.1

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

Re: [OE-core] Fwd: kernel-yocto class requires BSP definition now

2017-08-23 Thread Bruce Ashfield

On Wed, Aug 23, 2017 at 1:01 PM, Andrei Gherzan  wrote:

> On Wed, Aug 23, 2017 at 5:54 PM, Bruce Ashfield <
> bruce.ashfi...@windriver.com> wrote:
>
>> Already discussed with Khem and Richard in the original
>> thread.
>>
>> I'm sending another patch shortly to back this off to a note/warning.
>>
>>
> That is nice but wouldn't that clutter the build logs for no reason? For
> people who don't take advantage of scc definitions that is. Could you point
> me to the initial discussion? Just want to understand and maybe vote to
> remove it altogether.
>

It's a yocto bug. We need to flag BSP definitions that aren't valid,
otherwise the tools
will end up building things like qemuarm for someone that has a
misconfigured BSP.

If you don't have a defconfig (as someone won't have if they are using a
fully defined
BSP, but with the wrong name) and the wrong entry point, or no entry point,
is returned
we have to flag it.

The actual bug is: 11878, and there's a related fallout of that bad
definition.

So no, it won't be deleted, but I will make it check for a few more
parameters before
erroring or logging.

Bruce

-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Fwd: kernel-yocto class requires BSP definition now

2017-08-23 Thread Andrei Gherzan

On Wed, Aug 23, 2017 at 5:54 PM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> Already discussed with Khem and Richard in the original
> thread.
>
> I'm sending another patch shortly to back this off to a note/warning.
>
>
That is nice but wouldn't that clutter the build logs for no reason? For
people who don't take advantage of scc definitions that is. Could you point
me to the initial discussion? Just want to understand and maybe vote to
remove it altogether.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] pkgconfig vs pkgconf

2017-08-23 Thread Khem Raj

On Wed, Aug 23, 2017 at 9:19 AM Mark Hatle  wrote:

> On 8/23/17 10:46 AM, Mark Hatle wrote:
> > As of this morning, I'm not getting a warning about a preferred provider
> being
>
> typo.. 'I'm -NOW- getting a warning'
>
> sorry for the confusion...
>
> > necessary to differentiate between pkgconfig and pkgconf.
> >
> > I've set the following to make it "go away".  But I assume we need to
> set a
> > default somewhere in the system...
> >
> > PREFERRED_PROVIDER_pkconfig = "pkgconfig"
> > PREFERRED_PROVIDER_pkgconfig-native = "pkgconfig-native"
> >
> > PREFERRED_RPROVIDER_pkgconfig = "pkgconfig"
> >
>

How about nativesdk ? I filed a bug for this earlier

>
> --
> ___
> 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] Fwd: kernel-yocto class requires BSP definition now

2017-08-23 Thread Bruce Ashfield


Already discussed with Khem and Richard in the original
thread.

I'm sending another patch shortly to back this off to a note/warning.

Bruce

On 08/23/2017 12:48 PM, Andrei Gherzan wrote:

(Resending this from the yocto mailing list)

Hello all,

Since...

commit b6f78c7a27d6d3acae63cf1fdb7b56c11c919830
Author: Bruce Ashfield >

Date:   Sun Aug 20 22:58:21 2017 -0400

 kernel-yocto: ensure that only valid BSPs are built
 There was a bug in the search routines responsible for locating
 BSP definitions which returned a valid match if only the ktype
 matched.
 This meant that someone looking for "qemux86foo" (which is an
 invalid definition) would potentially end up building "qemuarm"
 and be none the wiser (until it didn't boot).
 With this fix to the tools search routine, and improved return
 code testing, we will now stop the build and report and error to
 the user.
 [YOCTO: #11878]
 (From OE-Core rev: 44aea7b87307795fe4e089c51d45afccaa2f6525)
 Signed-off-by: Bruce Ashfield >
 Signed-off-by: Richard Purdie >



... the build fails for cases where there is no scc definition used. 
meta-raspberrypi was using this for configuration fragments feature but 
without defining any scc or using any feature branches etc. This got 
broken now since finding BSP definition files is a requirement in the class.


--
Andrei Gherzan



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

[OE-core] Fwd: kernel-yocto class requires BSP definition now

2017-08-23 Thread Andrei Gherzan

(Resending this from the yocto mailing list)

Hello all,

Since...

commit b6f78c7a27d6d3acae63cf1fdb7b56c11c919830
Author: Bruce Ashfield 
Date:   Sun Aug 20 22:58:21 2017 -0400

kernel-yocto: ensure that only valid BSPs are built

There was a bug in the search routines responsible for locating
BSP definitions which returned a valid match if only the ktype
matched.

This meant that someone looking for "qemux86foo" (which is an
invalid definition) would potentially end up building "qemuarm"
and be none the wiser (until it didn't boot).

With this fix to the tools search routine, and improved return
code testing, we will now stop the build and report and error to
the user.

[YOCTO: #11878]

(From OE-Core rev: 44aea7b87307795fe4e089c51d45afccaa2f6525)

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie 


... the build fails for cases where there is no scc definition used.
meta-raspberrypi was using this for configuration fragments feature but
without defining any scc or using any feature branches etc. This got broken
now since finding BSP definition files is a requirement in the class.

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

Re: [OE-core] pkgconfig vs pkgconf

2017-08-23 Thread Mark Hatle

On 8/23/17 10:46 AM, Mark Hatle wrote:
> As of this morning, I'm not getting a warning about a preferred provider being

typo.. 'I'm -NOW- getting a warning'

sorry for the confusion...

> necessary to differentiate between pkgconfig and pkgconf.
> 
> I've set the following to make it "go away".  But I assume we need to set a
> default somewhere in the system...
> 
> PREFERRED_PROVIDER_pkconfig = "pkgconfig"
> PREFERRED_PROVIDER_pkgconfig-native = "pkgconfig-native"
> 
> PREFERRED_RPROVIDER_pkgconfig = "pkgconfig"
> 

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

Re: [OE-core] Change to kernel.bbclass broke kernel build when gcc does not support -ffile-prefix-map

2017-08-23 Thread Andrew Goodbody

> From: Bystricky, Juro [mailto:juro.bystri...@intel.com]
> 
> Yes, the issue was reported by others as well, it should be fixed by this 
> patch:
> 
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-
> next=2b7646a113cca7698d8484fe14bdbb8683a5f8ab
> 
> > From: Andrew Goodbody [mailto:andrew.goodb...@cambrionix.com]
> >
> > My build uses a version of gcc that does not support -ffile-prefix-map and
> > this is now broken after I updated the tree to include the latest commit to
> > kernel.bbclass "improve reproducibility" 012a70da7ae0617 by Juro
> Bystricky.
> >
> > The patch introduces the line
> > cc_option_supported=`${KERNEL_CC} -Q --help=joined | grep ffile-prefix-
> map`
> > When gcc does not support -ffile-prefix-map, the grep will exit with a non-
> > zero return code which is caught and causes the do_compile step to fail.
> >
> > Thanks,
> > Andrew

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

[OE-core] [PATCH] vulkan: Only build when 'vulkan' distro flag is set

2017-08-23 Thread Mark Hatle

Only build with the vulkan distro flag is set.  (References to this flag
were found in the mesa recipe.)

In addition, only set the RRECOMEMND to mesa, if 'opengl' flag is set.  Mesa
required opengl distro flag to build.

Signed-off-by: Mark Hatle 
---
 meta/recipes-graphics/vulkan/vulkan-demos_git.bb | 2 ++
 meta/recipes-graphics/vulkan/vulkan_1.0.51.0.bb  | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/vulkan/vulkan-demos_git.bb 
b/meta/recipes-graphics/vulkan/vulkan-demos_git.bb
index 828ef50..0b89435 100644
--- a/meta/recipes-graphics/vulkan/vulkan-demos_git.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-demos_git.bb
@@ -15,6 +15,8 @@ SRCREV = "18df00c7b4677b0889486e16977857aa987947e2"
 UPSTREAM_CHECK_GITTAGREGEX = "These are not the releases you're looking for"
 S = "${WORKDIR}/git"
 
+REQUIRED_DISTRO_FEATURES = 'vulkan'
+
 inherit cmake distro_features_check
 DEPENDS = "vulkan assimp"
 
diff --git a/meta/recipes-graphics/vulkan/vulkan_1.0.51.0.bb 
b/meta/recipes-graphics/vulkan/vulkan_1.0.51.0.bb
index 555d741..1893269 100644
--- a/meta/recipes-graphics/vulkan/vulkan_1.0.51.0.bb
+++ b/meta/recipes-graphics/vulkan/vulkan_1.0.51.0.bb
@@ -18,6 +18,7 @@ UPSTREAM_CHECK_GITTAGREGEX = "sdk-(?P\d+(\.\d+)+)"
 
 S = "${WORKDIR}/git"
 
+REQUIRED_DISTRO_FEATURES = "vulkan"
 
 inherit cmake python3native lib_package distro_features_check
 ANY_OF_DISTRO_FEATURES = "x11 wayland"
@@ -32,4 +33,5 @@ PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 
'x11', 'x11', '' ,d)}
 PACKAGECONFIG[x11] = "-DBUILD_WSI_XLIB_SUPPORT=ON -DBUILD_WSI_XCB_SUPPORT=ON 
-DDEMOS_WSI_SELECTION=XCB, -DBUILD_WSI_XLIB_SUPPORT=OFF 
-DBUILD_WSI_XCB_SUPPORT=OFF -DDEMOS_WSI_SELECTION=WAYLAND, libxcb libx11 
libxrandr"
 PACKAGECONFIG[wayland] = "-DBUILD_WSI_WAYLAND_SUPPORT=ON, 
-DBUILD_WSI_WAYLAND_SUPPORT=OFF, wayland"
 
-RRECOMMENDS_${PN} = "mesa-vulkan-drivers"
+# mesa requires opengl
+RRECOMMENDS_${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 
'mesa-vulkan-drivers', '', d)}"
-- 
1.8.3.1

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

[OE-core] [PATCH] vulkan distro flag update

2017-08-23 Thread Mark Hatle

I'm not sure if this is right or not, but it resolves the failures I was
getting after updating oe this morning.

I was attempting to run the yocto project compliant script, which runs
bitbake -S none world.  The results of this were an error that vulkan
needed 'mesa-vulkan-drivers'.  Looking at mesa, it was clear that these
are only built in the 'vulkan' distro flag is set.  (and mesa is only
built in the opengl flag is set.)

So I've added these checks to the vulkan recipe, and resolved the check.


Mark Hatle (1):
  vulkan: Only build when 'vulkan' distro flag is set

 meta/recipes-graphics/vulkan/vulkan-demos_git.bb | 2 ++
 meta/recipes-graphics/vulkan/vulkan_1.0.51.0.bb  | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

-- 
1.8.3.1

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

[OE-core] pkgconfig vs pkgconf

2017-08-23 Thread Mark Hatle

As of this morning, I'm not getting a warning about a preferred provider being
necessary to differentiate between pkgconfig and pkgconf.

I've set the following to make it "go away".  But I assume we need to set a
default somewhere in the system...

PREFERRED_PROVIDER_pkconfig = "pkgconfig"
PREFERRED_PROVIDER_pkgconfig-native = "pkgconfig-native"

PREFERRED_RPROVIDER_pkgconfig = "pkgconfig"

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

Re: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built

2017-08-23 Thread Khem Raj

On Wed, Aug 23, 2017 at 7:58 AM, Richard Purdie
 wrote:
> On Wed, 2017-08-23 at 10:42 -0400, Bruce Ashfield wrote:
>> On 08/23/2017 10:40 AM, Khem Raj wrote:
>> >
>> > On Wed, Aug 23, 2017 at 5:37 AM, Bruce Ashfield
>> >  wrote:
>> > >
>> > > On 08/22/2017 11:40 PM, Khem Raj wrote:
>> > > >
>> > > >
>> > > > On Sun, Aug 20, 2017 at 7:58 PM, Bruce Ashfield
>> > > >  wrote:
>> > > > >
>> > > > >
>> > > > > There was a bug in the search routines responsible for
>> > > > > locating
>> > > > > BSP definitions which returned a valid match if only the
>> > > > > ktype
>> > > > > matched.
>> > > > >
>> > > > > This meant that someone looking for "qemux86foo" (which is an
>> > > > > invalid definition) would potentially end up building
>> > > > > "qemuarm"
>> > > > > and be none the wiser (until it didn't boot).
>> > > > >
>> > > > > With this fix to the tools search routine, and improved
>> > > > > return
>> > > > > code testing, we will now stop the build and report and error
>> > > > > to
>> > > > > the user.
>> > > > >
>> > > > > [YOCTO: #11878]
>> > > > >
>> > > > > Signed-off-by: Bruce Ashfield 
>> > > > > ---
>> > > > >meta/classes/kernel-yocto.bbclass   |
>> > > > > 3 +++
>> > > > >meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |
>> > > > > 2 +-
>> > > > >2 files changed, 4 insertions(+), 1 deletion(-)
>> > > > >
>> > > > > diff --git a/meta/classes/kernel-yocto.bbclass
>> > > > > b/meta/classes/kernel-yocto.bbclass
>> > > > > index 1ca0756c4959..3c6df92131bc 100644
>> > > > > --- a/meta/classes/kernel-yocto.bbclass
>> > > > > +++ b/meta/classes/kernel-yocto.bbclass
>> > > > > @@ -143,6 +143,9 @@ do_kernel_metadata() {
>> > > > >
>> > > > >   # expand kernel features into their full path
>> > > > > equivalents
>> > > > >   bsp_definition=$(spp ${includes} --find
>> > > > > -DKMACHINE=${KMACHINE}
>> > > > > -DKTYPE=${LINUX_KERNEL_TYPE})
>> > > > > +   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
>> > > > > +   bbfatal_log "Could not locate BSP definiton
>> > > > > for
>> > > > > ${KMACHINE}/${LINUX_KERNEL_TYPE}."
>> > > > > +   fi
>> > > >
>> > > > this breaks non linux-yocto kernels which are using the kernel
>> > > > infra
>> > > > from OE-Core
>> > > > since they may not have kmeta structure and bsp_definition may
>> > > > be empty
>> > > > for them
>> > > > so either provide a way to override bsp_definition to something
>> > > > dummy or
>> > > > infact
>> > > > fall back to dummy by default with a warning or note during
>> > > > parse
>> > > > time. fatal is a bit harsh here.
>> > >
>> > > Fair enough. I can make it a warning versus fatal, or only make
>> > > it
>> > > fatal if I detect a defconfig.
>> > >
>> > > The issue is that the tools haven't found a configuration entry
>> > > point
>> > > and could end up building a garbage/invalid configuration. A
>> > > defconfig
>> > > could stand in as a 'valid entry' point, since it signifies a
>> > > baseline
>> > > configuration.
>> > >
>> > > Also, I do have completed code to move fragment merging into a
>> > > common
>> > > location and avoid things like this .. once it goes through some
>> > > more
>> > > compatibility testing, I'll post it to the list.
>> >
>> > Irrespective this was merged today into master, can you send a
>> > followup
>> > quickly so we can unbreak meta-raspberrypi
>> I hadn't pulled today, and yes, I'll send something by end of day,
>> since
>> I don't want this to stay broken!
>
> Thanks, I merged this as the discussion was happening not realising
> there was this issue.
>
> I did at least hopefully get all the other 4.12 issues addressed,
> thanks for the help there.

No worries, its a simple thing to fix I believe.

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

Re: [OE-core] ✗ patchtest: failure for do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature. (rev6)

2017-08-23 Thread Leonardo Sandoval

On Wed, 2017-08-23 at 13:04 +, Patchwork wrote:
> == Series Details ==
> 
> Series: do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature. (rev6)
> Revision: 6
> URL   : https://patchwork.openembedded.org/series/6525/
> State : failure
> 
> == Summary ==
> 
> 
> Thank you for submitting this patch series to OpenEmbedded Core. This is
> an automated response. Several tests have been executed on the proposed
> series by patchtest resulting in the following failures:
> 
> 
> 
> * Issue Series does not apply on top of target branch 
> [test_series_merge_on_head] 
>   Suggested fixRebase your series on top of targeted branch
>   Targeted branch  master (currently at b1e482ae20)
> 

it is not pretty clear what the problem is with your patch with the
message above but the problem is that your are changing documentation on
your series and the latter goes into another mailing list.

Check poky's README for more info.


> 
> 
> If you believe any of these test results are incorrect, please reply to the
> mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
> Otherwise we would appreciate you correcting the issues and submitting a new
> version of the patchset if applicable. Please ensure you add/increment the
> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
> 
> ---
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
> 


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

Re: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built

2017-08-23 Thread Bruce Ashfield


On 08/23/2017 10:58 AM, Richard Purdie wrote:

On Wed, 2017-08-23 at 10:42 -0400, Bruce Ashfield wrote:

On 08/23/2017 10:40 AM, Khem Raj wrote:


On Wed, Aug 23, 2017 at 5:37 AM, Bruce Ashfield
 wrote:


On 08/22/2017 11:40 PM, Khem Raj wrote:



On Sun, Aug 20, 2017 at 7:58 PM, Bruce Ashfield
 wrote:



There was a bug in the search routines responsible for
locating
BSP definitions which returned a valid match if only the
ktype
matched.

This meant that someone looking for "qemux86foo" (which is an
invalid definition) would potentially end up building
"qemuarm"
and be none the wiser (until it didn't boot).

With this fix to the tools search routine, and improved
return
code testing, we will now stop the build and report and error
to
the user.

[YOCTO: #11878]

Signed-off-by: Bruce Ashfield 
---
meta/classes/kernel-yocto.bbclass   |
3 +++
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |
2 +-
2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 1ca0756c4959..3c6df92131bc 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -143,6 +143,9 @@ do_kernel_metadata() {

   # expand kernel features into their full path
equivalents
   bsp_definition=$(spp ${includes} --find
-DKMACHINE=${KMACHINE}
-DKTYPE=${LINUX_KERNEL_TYPE})
+   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
+   bbfatal_log "Could not locate BSP definiton
for
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+   fi


this breaks non linux-yocto kernels which are using the kernel
infra
from OE-Core
since they may not have kmeta structure and bsp_definition may
be empty
for them
so either provide a way to override bsp_definition to something
dummy or
infact
fall back to dummy by default with a warning or note during
parse
time. fatal is a bit harsh here.


Fair enough. I can make it a warning versus fatal, or only make
it
fatal if I detect a defconfig.

The issue is that the tools haven't found a configuration entry
point
and could end up building a garbage/invalid configuration. A
defconfig
could stand in as a 'valid entry' point, since it signifies a
baseline
configuration.

Also, I do have completed code to move fragment merging into a
common
location and avoid things like this .. once it goes through some
more
compatibility testing, I'll post it to the list.


Irrespective this was merged today into master, can you send a
followup
quickly so we can unbreak meta-raspberrypi

I hadn't pulled today, and yes, I'll send something by end of day,
since
I don't want this to stay broken!


Thanks, I merged this as the discussion was happening not realising
there was this issue.

I did at least hopefully get all the other 4.12 issues addressed,
thanks for the help there.


Sounds good. This is an easy thing for me to tweak, having the
original series go in as-is was the easiest way to keep things
straight. My patch will be out shortly.

Bruce



Cheers,

Richard



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

Re: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built

2017-08-23 Thread Richard Purdie

On Wed, 2017-08-23 at 10:42 -0400, Bruce Ashfield wrote:
> On 08/23/2017 10:40 AM, Khem Raj wrote:
> > 
> > On Wed, Aug 23, 2017 at 5:37 AM, Bruce Ashfield
> >  wrote:
> > > 
> > > On 08/22/2017 11:40 PM, Khem Raj wrote:
> > > > 
> > > > 
> > > > On Sun, Aug 20, 2017 at 7:58 PM, Bruce Ashfield
> > > >  wrote:
> > > > > 
> > > > > 
> > > > > There was a bug in the search routines responsible for
> > > > > locating
> > > > > BSP definitions which returned a valid match if only the
> > > > > ktype
> > > > > matched.
> > > > > 
> > > > > This meant that someone looking for "qemux86foo" (which is an
> > > > > invalid definition) would potentially end up building
> > > > > "qemuarm"
> > > > > and be none the wiser (until it didn't boot).
> > > > > 
> > > > > With this fix to the tools search routine, and improved
> > > > > return
> > > > > code testing, we will now stop the build and report and error
> > > > > to
> > > > > the user.
> > > > > 
> > > > > [YOCTO: #11878]
> > > > > 
> > > > > Signed-off-by: Bruce Ashfield 
> > > > > ---
> > > > >    meta/classes/kernel-yocto.bbclass   |
> > > > > 3 +++
> > > > >    meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |
> > > > > 2 +-
> > > > >    2 files changed, 4 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/meta/classes/kernel-yocto.bbclass
> > > > > b/meta/classes/kernel-yocto.bbclass
> > > > > index 1ca0756c4959..3c6df92131bc 100644
> > > > > --- a/meta/classes/kernel-yocto.bbclass
> > > > > +++ b/meta/classes/kernel-yocto.bbclass
> > > > > @@ -143,6 +143,9 @@ do_kernel_metadata() {
> > > > > 
> > > > >   # expand kernel features into their full path
> > > > > equivalents
> > > > >   bsp_definition=$(spp ${includes} --find
> > > > > -DKMACHINE=${KMACHINE}
> > > > > -DKTYPE=${LINUX_KERNEL_TYPE})
> > > > > +   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
> > > > > +   bbfatal_log "Could not locate BSP definiton
> > > > > for
> > > > > ${KMACHINE}/${LINUX_KERNEL_TYPE}."
> > > > > +   fi
> > > > 
> > > > this breaks non linux-yocto kernels which are using the kernel
> > > > infra
> > > > from OE-Core
> > > > since they may not have kmeta structure and bsp_definition may
> > > > be empty
> > > > for them
> > > > so either provide a way to override bsp_definition to something
> > > > dummy or
> > > > infact
> > > > fall back to dummy by default with a warning or note during
> > > > parse
> > > > time. fatal is a bit harsh here.
> > > 
> > > Fair enough. I can make it a warning versus fatal, or only make
> > > it
> > > fatal if I detect a defconfig.
> > > 
> > > The issue is that the tools haven't found a configuration entry
> > > point
> > > and could end up building a garbage/invalid configuration. A
> > > defconfig
> > > could stand in as a 'valid entry' point, since it signifies a
> > > baseline
> > > configuration.
> > > 
> > > Also, I do have completed code to move fragment merging into a
> > > common
> > > location and avoid things like this .. once it goes through some
> > > more
> > > compatibility testing, I'll post it to the list.
> > 
> > Irrespective this was merged today into master, can you send a
> > followup
> > quickly so we can unbreak meta-raspberrypi
> I hadn't pulled today, and yes, I'll send something by end of day,
> since
> I don't want this to stay broken!

Thanks, I merged this as the discussion was happening not realising
there was this issue.

I did at least hopefully get all the other 4.12 issues addressed,
thanks for the help there.

Cheers,

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

Re: [OE-core] ✗ patchtest: failure for staging: add missing import errno to staging_populate_sysroot_dir

2017-08-23 Thread Leonardo Sandoval

On Wed, 2017-08-23 at 14:03 +, Marko, Peter wrote:
> >* Issue Series does not apply on top of target branch 
> >[test_series_merge_on_head] 
> >  Suggested fixRebase your series on top of targeted branch
> >  Targeted branch  master (currently at b1e482ae20)
> 
> Richie is faster than patchwork :-)

He is. So, in less that half hour (which is where the patchtest cron
does it job) RP merged your patch!


> Master head commit b1e482ae20 is actually patch submitted in this email 
> (which naturally conflicts with itself)...
> 
> Peter


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

Re: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built

2017-08-23 Thread Bruce Ashfield


On 08/23/2017 10:40 AM, Khem Raj wrote:

On Wed, Aug 23, 2017 at 5:37 AM, Bruce Ashfield
 wrote:

On 08/22/2017 11:40 PM, Khem Raj wrote:


On Sun, Aug 20, 2017 at 7:58 PM, Bruce Ashfield
 wrote:


There was a bug in the search routines responsible for locating
BSP definitions which returned a valid match if only the ktype
matched.

This meant that someone looking for "qemux86foo" (which is an
invalid definition) would potentially end up building "qemuarm"
and be none the wiser (until it didn't boot).

With this fix to the tools search routine, and improved return
code testing, we will now stop the build and report and error to
the user.

[YOCTO: #11878]

Signed-off-by: Bruce Ashfield 
---
   meta/classes/kernel-yocto.bbclass   | 3 +++
   meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
   2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 1ca0756c4959..3c6df92131bc 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -143,6 +143,9 @@ do_kernel_metadata() {

  # expand kernel features into their full path equivalents
  bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
-DKTYPE=${LINUX_KERNEL_TYPE})
+   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
+   bbfatal_log "Could not locate BSP definiton for
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+   fi



this breaks non linux-yocto kernels which are using the kernel infra
from OE-Core
since they may not have kmeta structure and bsp_definition may be empty
for them
so either provide a way to override bsp_definition to something dummy or
infact
fall back to dummy by default with a warning or note during parse
time. fatal is a bit harsh here.



Fair enough. I can make it a warning versus fatal, or only make it
fatal if I detect a defconfig.

The issue is that the tools haven't found a configuration entry point
and could end up building a garbage/invalid configuration. A defconfig
could stand in as a 'valid entry' point, since it signifies a baseline
configuration.

Also, I do have completed code to move fragment merging into a common
location and avoid things like this .. once it goes through some more
compatibility testing, I'll post it to the list.



Irrespective this was merged today into master, can you send a followup
quickly so we can unbreak meta-raspberrypi


I hadn't pulled today, and yes, I'll send something by end of day, since
I don't want this to stay broken!

Cheers,

Bruce





Bruce





  meta_dir=$(kgit --meta)

  # run1: pull all the configuration fragments, no matter where
they come from
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 2217a31076a2..4a78b897d34f 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
"file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b

   DEPENDS = "git-native"

-SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c"
+SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83"
   PR = "r12"
   PV = "0.2+git${SRCPV}"

--
2.5.0

--
___
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 8/9] kernel-yocto: ensure that only valid BSPs are built

2017-08-23 Thread Khem Raj

On Wed, Aug 23, 2017 at 5:37 AM, Bruce Ashfield
 wrote:
> On 08/22/2017 11:40 PM, Khem Raj wrote:
>>
>> On Sun, Aug 20, 2017 at 7:58 PM, Bruce Ashfield
>>  wrote:
>>>
>>> There was a bug in the search routines responsible for locating
>>> BSP definitions which returned a valid match if only the ktype
>>> matched.
>>>
>>> This meant that someone looking for "qemux86foo" (which is an
>>> invalid definition) would potentially end up building "qemuarm"
>>> and be none the wiser (until it didn't boot).
>>>
>>> With this fix to the tools search routine, and improved return
>>> code testing, we will now stop the build and report and error to
>>> the user.
>>>
>>> [YOCTO: #11878]
>>>
>>> Signed-off-by: Bruce Ashfield 
>>> ---
>>>   meta/classes/kernel-yocto.bbclass   | 3 +++
>>>   meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
>>>   2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/meta/classes/kernel-yocto.bbclass
>>> b/meta/classes/kernel-yocto.bbclass
>>> index 1ca0756c4959..3c6df92131bc 100644
>>> --- a/meta/classes/kernel-yocto.bbclass
>>> +++ b/meta/classes/kernel-yocto.bbclass
>>> @@ -143,6 +143,9 @@ do_kernel_metadata() {
>>>
>>>  # expand kernel features into their full path equivalents
>>>  bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}
>>> -DKTYPE=${LINUX_KERNEL_TYPE})
>>> +   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
>>> +   bbfatal_log "Could not locate BSP definiton for
>>> ${KMACHINE}/${LINUX_KERNEL_TYPE}."
>>> +   fi
>>
>>
>> this breaks non linux-yocto kernels which are using the kernel infra
>> from OE-Core
>> since they may not have kmeta structure and bsp_definition may be empty
>> for them
>> so either provide a way to override bsp_definition to something dummy or
>> infact
>> fall back to dummy by default with a warning or note during parse
>> time. fatal is a bit harsh here.
>
>
> Fair enough. I can make it a warning versus fatal, or only make it
> fatal if I detect a defconfig.
>
> The issue is that the tools haven't found a configuration entry point
> and could end up building a garbage/invalid configuration. A defconfig
> could stand in as a 'valid entry' point, since it signifies a baseline
> configuration.
>
> Also, I do have completed code to move fragment merging into a common
> location and avoid things like this .. once it goes through some more
> compatibility testing, I'll post it to the list.


Irrespective this was merged today into master, can you send a followup
quickly so we can unbreak meta-raspberrypi

>
> Bruce
>
>
>>
>>>  meta_dir=$(kgit --meta)
>>>
>>>  # run1: pull all the configuration fragments, no matter where
>>> they come from
>>> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>>> b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>>> index 2217a31076a2..4a78b897d34f 100644
>>> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>>> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>>> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM =
>>> "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
>>>
>>>   DEPENDS = "git-native"
>>>
>>> -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c"
>>> +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83"
>>>   PR = "r12"
>>>   PV = "0.2+git${SRCPV}"
>>>
>>> --
>>> 2.5.0
>>>
>>> --
>>> ___
>>> 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] ✗ patchtest: failure for staging: add missing import errno to staging_populate_sysroot_dir

2017-08-23 Thread Marko, Peter

>* Issue Series does not apply on top of target branch 
>[test_series_merge_on_head] 
>  Suggested fixRebase your series on top of targeted branch
>  Targeted branch  master (currently at b1e482ae20)

Richie is faster than patchwork :-)
Master head commit b1e482ae20 is actually patch submitted in this email (which 
naturally conflicts with itself)...

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

Re: [OE-core] [PATCH 0/3] Restructure python2 and python3 packaging system

2017-08-23 Thread Richard Purdie

On Thu, 2017-08-17 at 10:11 -0700, Alejandro Hernandez wrote:
> Alejandro Hernandez (3):
>   python: Restructure python packaging and replace it with
> autopackaging
>   python3: fix RDEPENDS on several recipes, due to non-existent
> python3
> packages
>   python3: Restructure python3 packaging and replace it with
> autopackaging

There was an issue exposed on the autobuilder from this patchset which
then highlighted problems with the incorrect PACKAGES_DYNAMIC use and
issues with the lack of a native manifest.

With M3 being now and this change potentially causing issues for other
layers, I've deferred this patch series for now as I don't think its
ready yet and I don't think it will be ready in a timeframe that can
make it into M3.

Cheers,

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

Re: [OE-core] do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature.

2017-08-23 Thread Kristian Amlie

On 23/08/17 14:46, Richard Purdie wrote:
> On Wed, 2017-08-23 at 14:39 +0200, Kristian Amlie wrote:
>> I don't understand why I'm getting patch failures. This is rebased to
>> cutting edge master. Trying one more time...
> 
> Its because you're patching documentation which is maintained in a
> separate repository. Separating that from the patch will avoid that
> error.

Aaah, right, this is from poky. Thanks for explaining, I'll fix that!

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

Re: [OE-core] [PATCH v5] do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature.

2017-08-23 Thread Kristian Amlie

On 23/08/17 14:47, Richard Purdie wrote:
> On Wed, 2017-08-23 at 14:39 +0200, Kristian Amlie wrote:
>> From: Kristian Amlie 
>>
>> This is a direct followup from the earlier f6a064d969f414 commit in
>> wic. It works more or less the same way: The variable specifies a
>> list
>> of directories relative to the root of the rootfs, and these
>> directories will be excluded from the resulting rootfs image. If an
>> entry ends with a slash, only the contents are omitted, not the
>> directory itself.
>>
>> Since the intended use of the variable is to exclude certain
>> directories from the rootfs, and then include said directories in
>> other partitions, it is not natural for this variable to be respected
>> for image creators that create multi partition images. Therefore the
>> default is to ignore the variable, and image creators that create
>> single root filesystems need to set
>>
>>   do_image_myfs[respect_exclude_path] = "1"
>>
>> in order to honor it. Specifically, "wic" and "multiubi" have not
>> received this variable flag, while others have.
> 
> I have to wonder if this is implemented the correct way around. Would
> it not be better to mark multiubi and wic as not wanting this feature,
> rather than requiring every other image creation method (which may even
> be in other layers) to set this?

The idea was that people in downstream repositories (other layers) are
more likely to have their own complete image creators than to have
filesystem creators. So rather than requiring all of the downstream
repositories to opt out of the feature, we opt in in the filesystem
creators which are mostly contained in OE.

Or so was the thinking. Not sure if it's a good reason though. I can
invert the behavior if you think it's better!

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

Re: [OE-core] [PATCH V2 6/9] core/target/ssh.py: replace decode errors

2017-08-23 Thread Richard Purdie

On Tue, 2017-08-22 at 22:55 +1200, Paul Eggleton wrote:
> On Tuesday, 22 August 2017 1:23:10 PM NZST Robert Yang wrote:
> > 
> > There might be wild strings when read from target (especially when
> > reading ptest results), replace the errors to avoid breaking the
> > test.
> > 
> > Fixed: (Not always happen)
> > $ bitbake core-image-sato -ctestimage
> > [snip]
> > status, output = self.target.run('ptest-runner', 0)
> >   File "/buildarea/lyang1/poky/meta/lib/oeqa/core/target/ssh.py",
> > line 84, in run
> > status, output = self._run(sshCmd, processTimeout, True)
> >   File "/buildarea/lyang1/poky/meta/lib/oeqa/core/target/ssh.py",
> > line 55, in _run
> > status, output = SSHCall(command, self.logger, timeout)
> >   File "/buildarea/lyang1/poky/meta/lib/oeqa/core/target/ssh.py",
> > line 258, in SSHCall
> > run()
> >   File "/buildarea/lyang1/poky/meta/lib/oeqa/core/target/ssh.py",
> > line 236, in run
> > output = process.communicate()[0].decode("utf-8")
> > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3 in
> > position 4906: invalid continuation byte
> > 
> > [YOCTO #11547]
> > 
> > Signed-off-by: Robert Yang 
> > ---
> >  meta/lib/oeqa/core/target/ssh.py | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/lib/oeqa/core/target/ssh.py
> > b/meta/lib/oeqa/core/target/ssh.py
> > index b80939c..a2eafcd 100644
> > --- a/meta/lib/oeqa/core/target/ssh.py
> > +++ b/meta/lib/oeqa/core/target/ssh.py
> > @@ -211,7 +211,7 @@ def SSHCall(command, logger, timeout=None,
> > **opts):
> >  process.stdout.close()
> >  eof = True
> >  else:
> > -data = data.decode("utf-8")
> > +data = data.decode("utf-8",
> > errors='replace')
> >  output += data
> >  logger.debug('Partial data from SSH
> > call: %s' % data)
> Since we're dealing with partial data here, shouldn't we be using a
> reader object? e.g.:
> 
>   http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=bfd8c35c3
> f917e3806c8dfe36c98c70fbccbb3c9


I've decided to merge this series as it improves the ptest support
substantially however I am expecting a follow up with the tweaks Paul
suggests here please.

Cheers,

Richard

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

[OE-core] ✗ patchtest: failure for staging: add missing import errno to staging_populate_sysroot_dir

2017-08-23 Thread Patchwork

== Series Details ==

Series: staging: add missing import errno to staging_populate_sysroot_dir
Revision: 1
URL   : https://patchwork.openembedded.org/series/8447/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at b1e482ae20)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] ✗ patchtest: failure for do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature. (rev6)

2017-08-23 Thread Patchwork

== Series Details ==

Series: do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature. (rev6)
Revision: 6
URL   : https://patchwork.openembedded.org/series/6525/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at b1e482ae20)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

Re: [OE-core] long (never ending?) do_install for adwaita-icon-theme

2017-08-23 Thread Alexander Kanavin


On 08/22/2017 09:46 PM, Trevor Woerner wrote:

Do you have any kind of logs for when it happens?



Unfortunately not, I'll try to keep some the next time it happens.

But I have a suspicion it might be related to a build failure. Earlier
today I was doing a build which failed in a recipe that wasn't
adwaita-icon-theme, nor related to it. When I checked on my build
later I could see the tail of the error message from the failed
recipe, but the overall build was still waiting for
adwaita-icon-theme's do_install to finish (hours after the failure).

Maybe adwaita-icon-theme's do_install would have succeeded if
everything had gone well? Maybe to reproduce, it might be necessary to
time it such that another recipe fails while adwaita-icon-theme is
building?


We can certainly revert my patch that speeds up the do_install(), but I 
would prefer not to do it blindly: it's much better to first firmly 
establish that the patch is indeed the reason for the never ending 
do_install (I can't imagine why, but it certainly could be). So please 
do try to get some logs, or a stable way to reproduce.


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

Re: [OE-core] [PATCH v5] do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature.

2017-08-23 Thread Richard Purdie

On Wed, 2017-08-23 at 14:39 +0200, Kristian Amlie wrote:
> From: Kristian Amlie 
> 
> This is a direct followup from the earlier f6a064d969f414 commit in
> wic. It works more or less the same way: The variable specifies a
> list
> of directories relative to the root of the rootfs, and these
> directories will be excluded from the resulting rootfs image. If an
> entry ends with a slash, only the contents are omitted, not the
> directory itself.
> 
> Since the intended use of the variable is to exclude certain
> directories from the rootfs, and then include said directories in
> other partitions, it is not natural for this variable to be respected
> for image creators that create multi partition images. Therefore the
> default is to ignore the variable, and image creators that create
> single root filesystems need to set
> 
>   do_image_myfs[respect_exclude_path] = "1"
> 
> in order to honor it. Specifically, "wic" and "multiubi" have not
> received this variable flag, while others have.

I have to wonder if this is implemented the correct way around. Would
it not be better to mark multiubi and wic as not wanting this feature,
rather than requiring every other image creation method (which may even
be in other layers) to set this?

Cheers,

Richard

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

Re: [OE-core] do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature.

2017-08-23 Thread Richard Purdie

On Wed, 2017-08-23 at 14:39 +0200, Kristian Amlie wrote:
> I don't understand why I'm getting patch failures. This is rebased to
> cutting edge master. Trying one more time...

Its because you're patching documentation which is maintained in a
separate repository. Separating that from the patch will avoid that
error.

Cheers,

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

Re: [OE-core] [PATCH] ca-certificates: prevent executing update-ca-certificates from host system

2017-08-23 Thread Richard Purdie

On Wed, 2017-08-23 at 14:07 +0200, Andrej Valek wrote:
> I have found out that even master with HOSTTOOLS does not fix my
> problem.
> We use ASSUME_PROVIDED for ca-certificates-native due to corporate
> environment CAs.
> Since nativesdk-ca-certificates depends on ca-certificates-native
> whichis not built, so it could not be found. Unfortunately adding
> update-ca-certificates to HOSTTOOLS is not working, since build user
> does not have permissions to modify system CAs and also is in
> /usr/sbin/ which is not in usual system path.
> 
> Therefore I think that this patch applies for master branch, too.
> Possible improvement would be also removing ca-certificates-native
> from DEPENDS of class-nativesdk.
> 
> Solution of installing corporate CAs within OE recipe does not seem
> to be ideal, because the CAs have short expiration date. So using
> system CAs assures reachability of resources over https.
> We had to do this because svn fetcher uses https without option to
> ignore errors (unlike wget which ignores certificates by default).

Reading this made me realise this is a pretty complex issue. In general
we cannot assume that we can execute nativesdk binaries. Since ca-
certificates is allarch and we're executing an sh script, this is less
of an issue in this very specific case. There is a binary involved,
c_rehash and we do need to make sure there are the right -native
dependencies to get that.

There is a further complication with regard to the paths used, ca-
certificates-native will use one set of paths, nativesdk-ca-
certificates will use a different set and target ca-certificates a
differnt set again.

I suspect you're right and the ca-certificates-native dependency may be
incorrect and the certs installed into sdks may be broken too. If the
native sysroot and target sysroot layouts don't match, that would cause
an additional source of errors.

So some changes in this area does appear to be needed...

Cheers,

Richard

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

[OE-core] [PATCH] staging: add missing import errno to staging_populate_sysroot_dir

2017-08-23 Thread Marko, Peter

Fixes error "Exception: NameError: name 'errno' is not defined"
during build-sysroots.bb:do_build_target_sysroot

Signed-off-by: Marko, Peter 
---
 meta/classes/staging.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 162c8e9..9d3d2ad 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -177,6 +177,7 @@ def staging_processfixme(fixme, target, recipesysroot, 
recipesysrootnative, d):
 def staging_populate_sysroot_dir(targetsysroot, nativesysroot, native, d):
 import glob
 import subprocess
+import errno
 
 fixme = []
 postinsts = []
-- 
2.1.4

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

Re: [OE-core] do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature.

2017-08-23 Thread Kristian Amlie


I don't understand why I'm getting patch failures. This is rebased to
cutting edge master. Trying one more time...

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

[OE-core] [PATCH v5] do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature.

2017-08-23 Thread Kristian Amlie

From: Kristian Amlie 

This is a direct followup from the earlier f6a064d969f414 commit in
wic. It works more or less the same way: The variable specifies a list
of directories relative to the root of the rootfs, and these
directories will be excluded from the resulting rootfs image. If an
entry ends with a slash, only the contents are omitted, not the
directory itself.

Since the intended use of the variable is to exclude certain
directories from the rootfs, and then include said directories in
other partitions, it is not natural for this variable to be respected
for image creators that create multi partition images. Therefore the
default is to ignore the variable, and image creators that create
single root filesystems need to set

  do_image_myfs[respect_exclude_path] = "1"

in order to honor it. Specifically, "wic" and "multiubi" have not
received this variable flag, while others have.

Signed-off-by: Kristian Amlie 
---
 documentation/ref-manual/ref-variables.xml | 35 +
 meta/classes/image.bbclass | 83 +-
 meta/classes/image_types.bbclass   | 13 +
 3 files changed, 129 insertions(+), 2 deletions(-)

diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index ff8f4e7..a4f2de5 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -6043,6 +6043,41 @@
 
 
 
+IMAGE_ROOTFS_EXCLUDE_PATH
+
+IMAGE_ROOTFS_EXCLUDE_PATH[doc] = "Specifies paths to omit from 
the rootfs."
+
+
+
+
+Specifies paths that should be omitted from the root 
filesystem, separated by
+spaces. The paths must be relative to the root of the 
filesystem (for example
+"usr"). Single root filesystem images will not include the 
path in the
+filesystem, except if the path ends with a slash, then the 
directory will be
+included, but without any content.
+
+ # Omit /usr completely from rootfs.
+ IMAGE_ROOTFS_EXCLUDE_PATH += "usr ..."
+ # Include the directory /usr in rootfs, but not its content.
+ IMAGE_ROOTFS_EXCLUDE_PATH += "usr/ ..."
+
+
+
+Image creators that create multi partition images 
typically do not honor this
+variable, and must provide their own method to split the 
directory
+structure. For example, wic has
+--exclude-path and 
--rootfs-dir.
+
+
+The default for custom image creators is to ignore this 
variable. Those that
+need to honor it must set:
+
+ do_image_custom[respect_exclude_path] = "1"
+
+
+
+
+
 IMAGE_ROOTFS_EXTRA_SPACE
 
 IMAGE_ROOTFS_EXTRA_SPACE[doc] = "Defines additional free disk 
space created in the image in Kbytes. By default, this variable is set to '0'."
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 3639aa4..e215541 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -117,7 +117,8 @@ def rootfs_variables(d):
  
'IMAGE_ROOTFS_MAXSIZE','IMAGE_NAME','IMAGE_LINK_NAME','IMAGE_MANIFEST','DEPLOY_DIR_IMAGE','IMAGE_FSTYPES','IMAGE_INSTALL_COMPLEMENTARY','IMAGE_LINGUAS',
  
'MULTILIBRE_ALLOW_REP','MULTILIB_TEMP_ROOTFS','MULTILIB_VARIANTS','MULTILIBS','ALL_MULTILIB_PACKAGE_ARCHS','MULTILIB_GLOBAL_VARIANTS','BAD_RECOMMENDATIONS','NO_RECOMMENDATIONS',
  
'PACKAGE_ARCHS','PACKAGE_CLASSES','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','USE_DEVFS',
- 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED', 
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY', 
'REPRODUCIBLE_TIMESTAMP_ROOTFS']
+ 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED', 
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY', 
'REPRODUCIBLE_TIMESTAMP_ROOTFS',
+ 'IMAGE_ROOTFS_EXCLUDE_PATH']
 variables.extend(rootfs_command_variables(d))
 variables.extend(variable_depends(d))
 return " ".join(variables)
@@ -496,8 +497,9 @@ python () {
 d.setVarFlag(task, 'func', '1')
 d.setVarFlag(task, 'fakeroot', '1')
 
-d.appendVarFlag(task, 'prefuncs', ' ' + debug + ' set_image_size')
+d.appendVarFlag(task, 'prefuncs', ' ' + debug + ' set_image_size 
prepare_excluded_directories')
 d.prependVarFlag(task, 'postfuncs', ' create_symlinks')
+d.appendVarFlag(task, 'postfuncs', ' cleanup_excluded_directories')

Re: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built

2017-08-23 Thread Bruce Ashfield


On 08/22/2017 11:40 PM, Khem Raj wrote:

On Sun, Aug 20, 2017 at 7:58 PM, Bruce Ashfield
 wrote:

There was a bug in the search routines responsible for locating
BSP definitions which returned a valid match if only the ktype
matched.

This meant that someone looking for "qemux86foo" (which is an
invalid definition) would potentially end up building "qemuarm"
and be none the wiser (until it didn't boot).

With this fix to the tools search routine, and improved return
code testing, we will now stop the build and report and error to
the user.

[YOCTO: #11878]

Signed-off-by: Bruce Ashfield 
---
  meta/classes/kernel-yocto.bbclass   | 3 +++
  meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
  2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 1ca0756c4959..3c6df92131bc 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -143,6 +143,9 @@ do_kernel_metadata() {

 # expand kernel features into their full path equivalents
 bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} 
-DKTYPE=${LINUX_KERNEL_TYPE})
+   if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
+   bbfatal_log "Could not locate BSP definiton for 
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+   fi


this breaks non linux-yocto kernels which are using the kernel infra
from OE-Core
since they may not have kmeta structure and bsp_definition may be empty for them
so either provide a way to override bsp_definition to something dummy or infact
fall back to dummy by default with a warning or note during parse
time. fatal is a bit harsh here.


Fair enough. I can make it a warning versus fatal, or only make it
fatal if I detect a defconfig.

The issue is that the tools haven't found a configuration entry point
and could end up building a garbage/invalid configuration. A defconfig
could stand in as a 'valid entry' point, since it signifies a baseline
configuration.

Also, I do have completed code to move fragment merging into a common
location and avoid things like this .. once it goes through some more
compatibility testing, I'll post it to the list.

Bruce




 meta_dir=$(kgit --meta)

 # run1: pull all the configuration fragments, no matter where they 
come from
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb 
b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 2217a31076a2..4a78b897d34f 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = 
"file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b

  DEPENDS = "git-native"

-SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c"
+SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83"
  PR = "r12"
  PV = "0.2+git${SRCPV}"

--
2.5.0

--
___
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] recipetool: create: fix broken import in npm module

2017-08-23 Thread Paul Eggleton

With "import oe" in create_npm.py you get "AttributeError: module 'oe'
has no attribute 'package'" when it tries to call
oe.package.npm_split_package_dirs().

Signed-off-by: Paul Eggleton 
---
 scripts/lib/recipetool/create_npm.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/recipetool/create_npm.py 
b/scripts/lib/recipetool/create_npm.py
index 07fcf4d..6252e91 100644
--- a/scripts/lib/recipetool/create_npm.py
+++ b/scripts/lib/recipetool/create_npm.py
@@ -166,7 +166,7 @@ class NpmRecipeHandler(RecipeHandler):
 
 def process(self, srctree, classes, lines_before, lines_after, handled, 
extravalues):
 import bb.utils
-import oe
+import oe.package
 from collections import OrderedDict
 
 if 'buildsystem' in handled:
-- 
2.9.5

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

[OE-core] [PATCH 2/2] recipetool: create: fix npm license code regression

2017-08-23 Thread Paul Eggleton

OE-Core commit 1df60b09f7a60427795ec828c9c7180e4e52f98c caused a
regression in npm handling since it still expected to be able to get the
results of the license handling, but this no longer happens until after
the npm plugin is called. Thus, call the license handling function
ourselves here (which will record this as having been handled so it
doesn't get done again later).

Signed-off-by: Paul Eggleton 
---
 scripts/lib/recipetool/create_npm.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/recipetool/create_npm.py 
b/scripts/lib/recipetool/create_npm.py
index 6252e91..ae53972 100644
--- a/scripts/lib/recipetool/create_npm.py
+++ b/scripts/lib/recipetool/create_npm.py
@@ -208,11 +208,14 @@ class NpmRecipeHandler(RecipeHandler):
 
 # Split each npm module out to is own package
 npmpackages = oe.package.npm_split_package_dirs(srctree)
+licvalues = None
 for item in handled:
 if isinstance(item, tuple):
 if item[0] == 'license':
 licvalues = item[1]
 break
+if not licvalues:
+licvalues = handle_license_vars(srctree, lines_before, 
handled, extravalues, d)
 if licvalues:
 # Augment the license list with information we have in the 
packages
 licenses = {}
-- 
2.9.5

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

[OE-core] [PATCH 0/2] recipetool npm regression fixes

2017-08-23 Thread Paul Eggleton

Fixes for a couple of regressions caused by recent patches to
recipetool.


The following changes since commit f59e729f98ef9b506b0cfdc415567e03ec87f2a9:

  runqemu: Use virtio to mount cdrom drives (2017-08-23 12:06:46 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib 
paule/recipetool-npm-fixes2
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=paule/recipetool-npm-fixes2

Paul Eggleton (2):
  recipetool: create: fix broken import in npm module
  recipetool: create: fix npm license code regression

 scripts/lib/recipetool/create_npm.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.9.5

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

Re: [OE-core] [PATCH] ca-certificates: prevent executing update-ca-certificates from host system

2017-08-23 Thread Andrej Valek

Hello Richard,

I have found out that even master with HOSTTOOLS does not fix my problem.
We use ASSUME_PROVIDED for ca-certificates-native due to corporate
environment CAs.
Since nativesdk-ca-certificates depends on ca-certificates-native which
is not built, so it could not be found.
Unfortunately adding update-ca-certificates to HOSTTOOLS is not working,
since build user does not have permissions to modify system CAs and also
is in /usr/sbin/ which is not in usual system path.

Therefore I think that this patch applies for master branch, too.
Possible improvement would be also removing ca-certificates-native from
DEPENDS of class-nativesdk.

Solution of installing corporate CAs within OE recipe does not seem to
be ideal, because the CAs have short expiration date. So using system
CAs assures reachability of resources over https.
We had to do this because svn fetcher uses https without option to
ignore errors (unlike wget which ignores certificates by default).

Regards,
Andrej

On 08/21/2017 08:12 AM, [ext] Andrej Valek wrote:
> Hello Armin,
> 
> Could You please merge it into krogoth and morty branch?
> 
> @Randy: last commit into those branches was ~5weeks ago, so they are
> still maintained.
> 
> Regards,
> Andrej
> 
> On 08/18/2017 05:46 PM, Randy MacLeod wrote:
>> On 2017-08-18 06:05 AM, Andrej Valek wrote:
>>> OK thank You, so please merge it into these branches.
>>
>> Add Armin, who maintains those branches:
>> https://wiki.yoctoproject.org/wiki/Releases
>> Is Krogoth still maintained? It's listed at Stable in the link above.
>>
>> ../Randy
>>
>>
>>
>>>
>>> Regards,
>>> Andrej
>>>
>>> On 08/18/2017 11:35 AM, Richard Purdie wrote:
 On Fri, 2017-08-18 at 08:26 +0200, Andrej Valek wrote:
> Yes, for actual branch is not required. But for branches like krogoth
> and morty, where HOSTTOOLS is not implemented, is this necessary.

 Lets just apply this to krogoth/morty then...

 Cheers,

 Richard

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

[OE-core] ✗ patchtest: failure for do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature. (rev5)

2017-08-23 Thread Patchwork

== Series Details ==

Series: do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature. (rev5)
Revision: 5
URL   : https://patchwork.openembedded.org/series/6525/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at f59e729f98)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] ✗ patchtest: failure for do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature. (rev4)

2017-08-23 Thread Patchwork

== Series Details ==

Series: do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature. (rev4)
Revision: 4
URL   : https://patchwork.openembedded.org/series/6525/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at f59e729f98)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH v4] do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature.

2017-08-23 Thread Kristian Amlie

From: Kristian Amlie 

This is a direct followup from the earlier f6a064d969f414 commit in
wic. It works more or less the same way: The variable specifies a list
of directories relative to the root of the rootfs, and these
directories will be excluded from the resulting rootfs image. If an
entry ends with a slash, only the contents are omitted, not the
directory itself.

Since the intended use of the variable is to exclude certain
directories from the rootfs, and then include said directories in
other partitions, it is not natural for this variable to be respected
for image creators that create multi partition images. Therefore the
default is to ignore the variable, and image creators that create
single root filesystems need to set

  do_image_myfs[respect_exclude_path] = "1"

in order to honor it. Specifically, "wic" and "multiubi" have not
received this variable flag, while others have.

Signed-off-by: Kristian Amlie 
---
 documentation/ref-manual/ref-variables.xml | 35 +
 meta/classes/image.bbclass | 83 +-
 meta/classes/image_types.bbclass   | 13 +
 3 files changed, 129 insertions(+), 2 deletions(-)

diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index ff8f4e7..a4f2de5 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -6043,6 +6043,41 @@
 
 
 
+IMAGE_ROOTFS_EXCLUDE_PATH
+
+IMAGE_ROOTFS_EXCLUDE_PATH[doc] = "Specifies paths to omit from 
the rootfs."
+
+
+
+
+Specifies paths that should be omitted from the root 
filesystem, separated by
+spaces. The paths must be relative to the root of the 
filesystem (for example
+"usr"). Single root filesystem images will not include the 
path in the
+filesystem, except if the path ends with a slash, then the 
directory will be
+included, but without any content.
+
+ # Omit /usr completely from rootfs.
+ IMAGE_ROOTFS_EXCLUDE_PATH += "usr ..."
+ # Include the directory /usr in rootfs, but not its content.
+ IMAGE_ROOTFS_EXCLUDE_PATH += "usr/ ..."
+
+
+
+Image creators that create multi partition images 
typically do not honor this
+variable, and must provide their own method to split the 
directory
+structure. For example, wic has
+--exclude-path and 
--rootfs-dir.
+
+
+The default for custom image creators is to ignore this 
variable. Those that
+need to honor it must set:
+
+ do_image_custom[respect_exclude_path] = "1"
+
+
+
+
+
 IMAGE_ROOTFS_EXTRA_SPACE
 
 IMAGE_ROOTFS_EXTRA_SPACE[doc] = "Defines additional free disk 
space created in the image in Kbytes. By default, this variable is set to '0'."
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 3639aa4..e215541 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -117,7 +117,8 @@ def rootfs_variables(d):
  
'IMAGE_ROOTFS_MAXSIZE','IMAGE_NAME','IMAGE_LINK_NAME','IMAGE_MANIFEST','DEPLOY_DIR_IMAGE','IMAGE_FSTYPES','IMAGE_INSTALL_COMPLEMENTARY','IMAGE_LINGUAS',
  
'MULTILIBRE_ALLOW_REP','MULTILIB_TEMP_ROOTFS','MULTILIB_VARIANTS','MULTILIBS','ALL_MULTILIB_PACKAGE_ARCHS','MULTILIB_GLOBAL_VARIANTS','BAD_RECOMMENDATIONS','NO_RECOMMENDATIONS',
  
'PACKAGE_ARCHS','PACKAGE_CLASSES','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','USE_DEVFS',
- 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED', 
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY', 
'REPRODUCIBLE_TIMESTAMP_ROOTFS']
+ 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED', 
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY', 
'REPRODUCIBLE_TIMESTAMP_ROOTFS',
+ 'IMAGE_ROOTFS_EXCLUDE_PATH']
 variables.extend(rootfs_command_variables(d))
 variables.extend(variable_depends(d))
 return " ".join(variables)
@@ -496,8 +497,9 @@ python () {
 d.setVarFlag(task, 'func', '1')
 d.setVarFlag(task, 'fakeroot', '1')
 
-d.appendVarFlag(task, 'prefuncs', ' ' + debug + ' set_image_size')
+d.appendVarFlag(task, 'prefuncs', ' ' + debug + ' set_image_size 
prepare_excluded_directories')
 d.prependVarFlag(task, 'postfuncs', ' create_symlinks')
+d.appendVarFlag(task, 'postfuncs', ' cleanup_excluded_directories')

Re: [OE-core] do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature.

2017-08-23 Thread Kristian Amlie


Ping, third rebase now! This is related to
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11688.

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

[OE-core] [PATCH v4] do_image: Implement IMAGE_ROOTFS_EXCLUDE_PATH feature.

2017-08-23 Thread Kristian Amlie

From: Kristian Amlie 

This is a direct followup from the earlier f6a064d969f414 commit in
wic. It works more or less the same way: The variable specifies a list
of directories relative to the root of the rootfs, and these
directories will be excluded from the resulting rootfs image. If an
entry ends with a slash, only the contents are omitted, not the
directory itself.

Since the intended use of the variable is to exclude certain
directories from the rootfs, and then include said directories in
other partitions, it is not natural for this variable to be respected
for image creators that create multi partition images. Therefore the
default is to ignore the variable, and image creators that create
single root filesystems need to set

  do_image_myfs[respect_exclude_path] = "1"

in order to honor it. Specifically, "wic" and "multiubi" have not
received this variable flag, while others have.

Signed-off-by: Kristian Amlie 
---
 documentation/ref-manual/ref-variables.xml | 35 +
 meta/classes/image.bbclass | 83 +-
 meta/classes/image_types.bbclass   | 13 +
 3 files changed, 129 insertions(+), 2 deletions(-)

diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index ff8f4e7..a4f2de5 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -6043,6 +6043,41 @@
 
 
 
+IMAGE_ROOTFS_EXCLUDE_PATH
+
+IMAGE_ROOTFS_EXCLUDE_PATH[doc] = "Specifies paths to omit from 
the rootfs."
+
+
+
+
+Specifies paths that should be omitted from the root 
filesystem, separated by
+spaces. The paths must be relative to the root of the 
filesystem (for example
+"usr"). Single root filesystem images will not include the 
path in the
+filesystem, except if the path ends with a slash, then the 
directory will be
+included, but without any content.
+
+ # Omit /usr completely from rootfs.
+ IMAGE_ROOTFS_EXCLUDE_PATH += "usr ..."
+ # Include the directory /usr in rootfs, but not its content.
+ IMAGE_ROOTFS_EXCLUDE_PATH += "usr/ ..."
+
+
+
+Image creators that create multi partition images 
typically do not honor this
+variable, and must provide their own method to split the 
directory
+structure. For example, wic has
+--exclude-path and 
--rootfs-dir.
+
+
+The default for custom image creators is to ignore this 
variable. Those that
+need to honor it must set:
+
+ do_image_custom[respect_exclude_path] = "1"
+
+
+
+
+
 IMAGE_ROOTFS_EXTRA_SPACE
 
 IMAGE_ROOTFS_EXTRA_SPACE[doc] = "Defines additional free disk 
space created in the image in Kbytes. By default, this variable is set to '0'."
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 3639aa4..e215541 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -117,7 +117,8 @@ def rootfs_variables(d):
  
'IMAGE_ROOTFS_MAXSIZE','IMAGE_NAME','IMAGE_LINK_NAME','IMAGE_MANIFEST','DEPLOY_DIR_IMAGE','IMAGE_FSTYPES','IMAGE_INSTALL_COMPLEMENTARY','IMAGE_LINGUAS',
  
'MULTILIBRE_ALLOW_REP','MULTILIB_TEMP_ROOTFS','MULTILIB_VARIANTS','MULTILIBS','ALL_MULTILIB_PACKAGE_ARCHS','MULTILIB_GLOBAL_VARIANTS','BAD_RECOMMENDATIONS','NO_RECOMMENDATIONS',
  
'PACKAGE_ARCHS','PACKAGE_CLASSES','TARGET_VENDOR','TARGET_ARCH','TARGET_OS','OVERRIDES','BBEXTENDVARIANT','FEED_DEPLOYDIR_BASE_URI','INTERCEPT_DIR','USE_DEVFS',
- 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED', 
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY', 
'REPRODUCIBLE_TIMESTAMP_ROOTFS']
+ 'CONVERSIONTYPES', 'IMAGE_GEN_DEBUGFS', 'ROOTFS_RO_UNNEEDED', 
'IMGDEPLOYDIR', 'PACKAGE_EXCLUDE_COMPLEMENTARY', 
'REPRODUCIBLE_TIMESTAMP_ROOTFS',
+ 'IMAGE_ROOTFS_EXCLUDE_PATH']
 variables.extend(rootfs_command_variables(d))
 variables.extend(variable_depends(d))
 return " ".join(variables)
@@ -496,8 +497,9 @@ python () {
 d.setVarFlag(task, 'func', '1')
 d.setVarFlag(task, 'fakeroot', '1')
 
-d.appendVarFlag(task, 'prefuncs', ' ' + debug + ' set_image_size')
+d.appendVarFlag(task, 'prefuncs', ' ' + debug + ' set_image_size 
prepare_excluded_directories')
 d.prependVarFlag(task, 'postfuncs', ' create_symlinks')
+d.appendVarFlag(task, 'postfuncs', ' cleanup_excluded_directories')

[OE-core] ✗ patchtest: failure for libxml2: Fix CVE-2017-8872 (rev2)

2017-08-23 Thread Patchwork

== Series Details ==

Series: libxml2: Fix CVE-2017-8872 (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/7105/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[V2] libxml2: Fix CVE-2017-8872
 Issue Missing or incorrectly formatted CVE tag in included patch 
file [test_cve_tag_format] 
  Suggested fixCorrect or include the CVE tag on cve patch with format: 
"CVE: CVE--"



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH V2] libxml2: Fix CVE-2017-8872

2017-08-23 Thread Hongxu Jia

fix global-buffer-overflow in htmlParseTryOrFinish (HTMLparser.c:5403)

https://bugzilla.gnome.org/show_bug.cgi?id=775200

Here is the reproduce steps on ubuntu 16.04, use clang with "-fsanitize=address"
...
export CC="clang"
export CFLAGS="-fsanitize=address"

./configure --disable-shared

make clean all -j

wget https://bugzilla.gnome.org/attachment.cgi?id=340871 -O poc

./xmllint --html --push poc
==2785==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00a0de21 at pc 0x006a7f6e bp 0x7ffdfe940c10 sp 0x7ffdfe940c08
READ of size 1 at 0x00a0de21 thread T0#0 0x6a7f6d
(/home/jiahongxu/Downloads/libxml2-2.9.4/xmllint+0x6a7f6d)#1 0x6a7356
(/home/jiahongxu/Downloads/libxml2-2.9.4/xmllint+0x6a7356)#2 0x4f4504
(/home/jiahongxu/Downloads/libxml2-2.9.4/xmllint+0x4f4504)#3 0x4f045e
(/home/jiahongxu/Downloads/libxml2-2.9.4/xmllint+0x4f045e)#4 0x7f81977d682f
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)#5 0x419ad8
(/home/jiahongxu/Downloads/libxml2-2.9.4/xmllint+0x419ad8)
...

Signed-off-by: Hongxu Jia 
---
 .../libxml/libxml2/libxml2-CVE-2017-8872.patch | 37 ++
 meta/recipes-core/libxml/libxml2_2.9.4.bb  |  1 +
 2 files changed, 38 insertions(+)
 create mode 100644 meta/recipes-core/libxml/libxml2/libxml2-CVE-2017-8872.patch

diff --git a/meta/recipes-core/libxml/libxml2/libxml2-CVE-2017-8872.patch 
b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2017-8872.patch
new file mode 100644
index 000..26779aa
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/libxml2-CVE-2017-8872.patch
@@ -0,0 +1,37 @@
+From d2f873a541c72b0f67e15562819bf98b884b30b7 Mon Sep 17 00:00:00 2001
+From: Hongxu Jia 
+Date: Wed, 23 Aug 2017 16:04:49 +0800
+Subject: [PATCH] fix CVE-2017-8872
+
+this makes xmlHaltParser "empty" the buffer, as it resets cur and ava
+il too here.
+
+this seems to cure this specific issue, and also passes the testsuite
+
+Signed-off-by: Marcus Meissner 
+
+https://bugzilla.gnome.org/show_bug.cgi?id=775200
+Upstream-Status: Backport 
[https://bugzilla.gnome.org/attachment.cgi?id=355527=diff]
+Signed-off-by: Hongxu Jia 
+---
+ parser.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/parser.c b/parser.c
+index 9506ead..6c07ffd 100644
+--- a/parser.c
 b/parser.c
+@@ -12664,6 +12664,10 @@ xmlHaltParser(xmlParserCtxtPtr ctxt) {
+   }
+   ctxt->input->cur = BAD_CAST"";
+   ctxt->input->base = ctxt->input->cur;
++  if (ctxt->input->buf) {
++  xmlBufEmpty (ctxt->input->buf->buffer);
++  } else
++  ctxt->input->length = 0;
+ }
+ }
+ 
+-- 
+2.7.4
+
diff --git a/meta/recipes-core/libxml/libxml2_2.9.4.bb 
b/meta/recipes-core/libxml/libxml2_2.9.4.bb
index f67c47d..107539b 100644
--- a/meta/recipes-core/libxml/libxml2_2.9.4.bb
+++ b/meta/recipes-core/libxml/libxml2_2.9.4.bb
@@ -28,6 +28,7 @@ SRC_URI = 
"ftp://xmlsoft.org/libxml2/libxml2-${PV}.tar.gz;name=libtar \
file://libxml2-CVE-2017-9049_CVE-2017-9050.patch \
file://libxml2-CVE-2017-5969.patch \
file://libxml2-CVE-2017-0663.patch \
+   file://libxml2-CVE-2017-8872.patch \

file://0001-Make-ptest-run-the-python-tests-if-python-is-enabled.patch \
"
 
-- 
2.8.1

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

Re: [OE-core] [PATCH] base.bbclass: trim duplicated whitespaces from BUILDCFG_VARS

2017-08-23 Thread Ming Liu

Hi, Richard:

OK, understood.

So for this kind of issues, the BSP developers should pay attention by
themselves not to introduce any duplicated whitespaces in their meta-xxx
layers?

//Ming Liu

2017-08-23 9:59 GMT+02:00 Richard Purdie :

> On Wed, 2017-08-23 at 09:57 +0200, Ming Liu wrote:
> > Yes, it's in master-next not in master branch, but wouldn't that mean
> > it's accepted as a proper fix, or?
>
> It means it was queued for testing, I've dropped it from master-next
> now as the comments from Chris still apply from last time.
>
> Cheers,
>
> Richard
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG options

2017-08-23 Thread Huang, Jie (Jackie)



> -Original Message-
> From: MacLeod, Randy
> Sent: Wednesday, August 23, 2017 09:27
> To: Richard Purdie; Andre McCurdy; Huang, Jie (Jackie)
> Cc: OE Core mailing list
> Subject: Re: [OE-core] [PATCH] boost: add python to default PACKAGECONFIG
> options
> 
> On 2017-08-22 03:55 PM, Richard Purdie wrote:
> > On Tue, 2017-08-22 at 12:51 -0700, Andre McCurdy wrote:
> >> On Tue, Aug 22, 2017 at 12:42 AM,  
> >> wrote:
> >>>
> >>> From: Jackie Huang 
> >>>
> >>> We want to provide python libs by default, and some other
> >>> popular Linux distributions like redhat/fedora does the same.
> >> Has something changed? Is there anything in oe-core or meta-oe which
> >> now needs boost python support enabled?
> >
> > Does it even actually build on all arches? >
> > I'm rather behind with patch review right now as people are putting so
> > many patches out there with what seems like minimal testing and
> > expecting me/Ross and the autobuilder to figure out the problems for
> > them.
> >
> > Each time one fails, it blocks the queue with the rest of them in and I
> > have to retest until I get something clean.
> >
> > Testing this change is quite a way down my priority list I'm afraid.
> >
> 
> Maybe this is better done in our distro configuration.
> 
> We're trying to minimize differences with oe-core and
> the boost python support doesn't seem to be much of an
> impact based on looking at logs rather than a having a
> detailed understanding of boost.
> 
> We've had this commit in our local branch since before:
> 
> CommitDate: Wed Dec 21 22:16:31 2016 -0800
> 
>  boost: add python to default PACKAGECONFIG options
> 
>  We want to provide python libs by default, and some other
>  popular Linux distributions like redhat/fedora does the same.
> 
>  (LOCAL REV: NOT UPSTREAM) -- sent to oe-core on 20160930
> 
> so it certainly builds for all qemu* for glibc configurations.
> 
> I'll see if we can add musl builds to our automated builds tonight.
> 
> Jackie,
> 
> Did/Can you build for musl?

No, I didn't build for musl yet, but yes, I can and will do the test with musl
and fix issues as needed.

> Do you have any idea of the impact of this config on users that are not
> interested in the python interface with boost?

I don't think there is any impact, each library is packaged into a separate
package named with boost-

> What's the additional cost in compile time?

A quick test indicates that it's less than 1 second:

$ grep -r 'Elapsed time:' 20170823073306/boost-1.64.0-r0/do_compile 
20170823075302/boost-1.64.0-r0/do_compile
20170823073306/boost-1.64.0-r0/do_compile:Elapsed time: 50.96 seconds
20170823075302/boost-1.64.0-r0/do_compile:Elapsed time: 51.63 seconds

Thanks,
Jackie

> 
> 
> 
> There certainly are a rush of package updates and other changes
> coming in; apologies for the lack of warning and late arrivals.
> Other than doing more testing and explaining what tests were done,
> what else can we do to help?
> 
> 
> ../Randy
> 
> 
> > Cheers,
> >
> > Richard
> >
> >
> 
> 
> --
> # Randy MacLeod. SMTS, Linux, Wind River
> Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON,
> Canada, K2K 2W5
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base.bbclass: trim duplicated whitespaces from BUILDCFG_VARS

2017-08-23 Thread Richard Purdie

On Wed, 2017-08-23 at 09:57 +0200, Ming Liu wrote:
> Yes, it's in master-next not in master branch, but wouldn't that mean
> it's accepted as a proper fix, or?

It means it was queued for testing, I've dropped it from master-next
now as the comments from Chris still apply from last time.

Cheers,

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

Re: [OE-core] [PATCH] base.bbclass: trim duplicated whitespaces from BUILDCFG_VARS

2017-08-23 Thread Ming Liu

Hi,

Yes, it's in master-next not in master branch, but wouldn't that mean it's
accepted as a proper fix, or?

//Ming Liu

2017-08-23 9:50 GMT+02:00 Richard Purdie :

> On Wed, 2017-08-23 at 04:33 +0200, Ming Liu wrote:
> > Hi, Andre:
> >
> > Arha, I did not know that when I was submitting the patch, may I know
> > why it's rejected at that moment? Since even with the alternative
> > fixes, the developers still could introduce duplicated whitespaces in
> > their BSP layers if they do not know the rules, since it's quite
> > common in recipes to assign variables with duplicated whitespcaces.
> >
> > BTW: i just checked, it's been merged to master already.
>
> No, it hasn't.
>
> Cheers,
>
> Richard
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base.bbclass: trim duplicated whitespaces from BUILDCFG_VARS

2017-08-23 Thread Richard Purdie

On Wed, 2017-08-23 at 04:33 +0200, Ming Liu wrote:
> Hi, Andre:
> 
> Arha, I did not know that when I was submitting the patch, may I know
> why it's rejected at that moment? Since even with the alternative
> fixes, the developers still could introduce duplicated whitespaces in
> their BSP layers if they do not know the rules, since it's quite
> common in recipes to assign variables with duplicated whitespcaces.
> 
> BTW: i just checked, it's been merged to master already.

No, it hasn't.

Cheers,

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

[OE-core] [PATCH 1/2] oeqa/parselogs: Ignore device node warnings on mips

2017-08-23 Thread Richard Purdie

THe newner kernels have ope firmware support enabled which leads to warnings
during boot on mips. These aren't interesting and we should ignore them.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/runtime/cases/parselogs.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py 
b/meta/lib/oeqa/runtime/cases/parselogs.py
index c4d347d..1f36c61 100644
--- a/meta/lib/oeqa/runtime/cases/parselogs.py
+++ b/meta/lib/oeqa/runtime/cases/parselogs.py
@@ -86,9 +86,11 @@ ignore_errors = {
 'qemumips' : [
 'Failed to load module "glx"',
 'pci :00:00.0: [Firmware Bug]: reg 0x..: invalid BAR (can\'t 
size)',
+'cacheinfo: Failed to find cpu0 device node',
 ] + common_errors,
 'qemumips64' : [
 'pci :00:00.0: [Firmware Bug]: reg 0x..: invalid BAR (can\'t 
size)',
+'cacheinfo: Failed to find cpu0 device node',
  ] + common_errors,
 'qemuppc' : [
 'PCI :00 Cannot reserve Legacy IO [io  0x-0x0fff]',
-- 
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] runqemu: Use virtio to mount cdrom drives

2017-08-23 Thread Richard Purdie

The IDE driver in the kernel is fragile and in 4.12 is causing backtraces.
To unblock 4.12 kernel merging use the virtio CD driver instead to mount
iso images which should be faster and more stable.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/cases/runqemu.py | 2 +-
 scripts/runqemu | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/runqemu.py 
b/meta/lib/oeqa/selftest/cases/runqemu.py
index 8805a38..1991be7 100644
--- a/meta/lib/oeqa/selftest/cases/runqemu.py
+++ b/meta/lib/oeqa/selftest/cases/runqemu.py
@@ -62,7 +62,7 @@ SYSLINUX_TIMEOUT = "10"
 cmd = "%s %s iso" % (self.cmd_common, self.machine)
 with runqemu(self.recipe, ssh=False, launch_cmd=cmd) as qemu:
 with open(qemu.qemurunnerlog) as f:
-self.assertTrue(' -cdrom ' in f.read(), "Failed: %s" % cmd)
+self.assertTrue('media=cdrom' in f.read(), "Failed: %s" % cmd)
 
 @OETestID(2004)
 def test_boot_recipe_image(self):
diff --git a/scripts/runqemu b/scripts/runqemu
index fd2717e..1131324 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1005,7 +1005,7 @@ class BaseConfig(object):
 vm_drive = ''
 if self.fstype in self.vmtypes:
 if self.fstype == 'iso':
-vm_drive = '-cdrom %s' % self.rootfs
+vm_drive = '-drive file=%s,if=virtio,media=cdrom' % 
self.rootfs
 elif self.get('QB_DRIVE_TYPE'):
 drive_type = self.get('QB_DRIVE_TYPE')
 if drive_type.startswith("/dev/sd"):
-- 
2.7.4

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

84 matches

Mail list logo