[OE-core] [PATCH 3/4] compatlayer/__init__.py: Allow add_layer to process recursive deps

[Mark Hatle]

When processing a layer for dependencies, you have to process the layer
itself, it's dependencies, the dependencies dependencies and so forth until
all items have been processed.

i.e.:  LayerA requires LayerB requires LayerC requires layerD

The end result should be LayerB, LayerC and LayerD are all dependencies of
LayerA.

Signed-off-by: Mark Hatle 
---
 scripts/lib/compatlayer/__init__.py | 40 -
 1 file changed, 35 insertions(+), 5 deletions(-)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index 58f94b7..24edc88 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -142,10 +142,9 @@ def _find_layer_depends(depend, layers):
 def add_layer(bblayersconf, layer, layers, logger):
 logger.info('Adding layer %s' % layer['name'])
 
-for collection in layer['collections']:
-depends = layer['collections'][collection]['depends']
-if not depends:
-continue
+def recurse_dependencies(depends, layer, layers, logger, ret = []):
+logger.debug('Processing dependencies %s for layer %s.' % \
+(depends, layer['name']))
 
 for depend in depends.split():
 # core (oe-core) is suppose to be provided
@@ -156,8 +155,39 @@ def add_layer(bblayersconf, layer, layers, logger):
 if not layer_depend:
 logger.error('Layer %s depends on %s and isn\'t found.' % \
 (layer['name'], depend))
-return False
+ret = None
+continue
+
+# We keep processing, even if ret is None, this allows us to report
+# multiple errors at once
+if ret is not None and layer_depend not in ret:
+ret.append(layer_depend)
+
+# Recursively process...
+if 'collections' not in layer_depend:
+continue
+
+for collection in layer_depend['collections']:
+collect_deps = 
layer_depend['collections'][collection]['depends']
+if not collect_deps:
+continue
+ret = recurse_dependencies(collect_deps, layer_depend, layers, 
logger, ret)
+
+return ret
 
+layer_depends = []
+for collection in layer['collections']:
+depends = layer['collections'][collection]['depends']
+if not depends:
+continue
+
+layer_depends = recurse_dependencies(depends, layer, layers, logger, 
layer_depends)
+
+# Note: [] (empty) is allowed, None is not!
+if layer_depends is None:
+return False
+else:
+for layer_depend in layer_depends:
 logger.info('Adding layer dependency %s' % layer_depend['name'])
 with open(bblayersconf, 'a+') as f:
 f.write("\nBBLAYERS += \"%s\"\n" % layer_depend['path'])
-- 
1.8.3.1

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

[OE-core] [PATCH 2/4] yocto-compat-layer.py: Add --dependency argument

[Mark Hatle]

When processing a large number of items, there are times that it would be
nice to be able to pass in a series of layers that can be used as dependencies
for the layer that is being scanned.  This avoids the significant overhead
of processing all of the layers to compatibility.

Signed-off-by: Mark Hatle 
---
 scripts/yocto-compat-layer.py | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index d13d8c0..f8a1ac7 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -47,6 +47,8 @@ def main():
 help='Layer to test compatibility with Yocto Project')
 parser.add_argument('-o', '--output-log',
 help='File to output log (optional)', action='store')
+parser.add_argument('--dependency', nargs="+",
+help='Layers to process for dependencies', action='store')
 parser.add_argument('-n', '--no-auto', help='Disable auto layer discovery',
 action='store_true')
 parser.add_argument('-d', '--debug', help='Enable debug output',
@@ -80,6 +82,11 @@ def main():
 if not layers:
 logger.error("Fail to detect layers")
 return 1
+if args.dependency:
+dep_layers = detect_layers(args.dependency, args.no_auto)
+dep_layers = dep_layers + layers
+else:
+dep_layers = layers
 
 logger.info("Detected layers:")
 for layer in layers:
@@ -125,7 +132,8 @@ def main():
 
 shutil.copyfile(bblayersconf + '.backup', bblayersconf)
 
-if not add_layer(bblayersconf, layer, layers, logger):
+if not add_layer(bblayersconf, layer, dep_layers, logger):
+logger.info('Skipping %s due to missing dependencies.' % 
layer['name'])
 results[layer['name']] = None
 results_status[layer['name']] = 'SKIPPED (Missing dependencies)'
 layers_tested = layers_tested + 1
-- 
1.8.3.1

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

[OE-core] [PATCH 4/4] yocto-compat-layer.py: Fix the signature validation

[Mark Hatle]

The initial signatures need to be collected -after- the dependency layers have
been added to the system.  Otherwise changes that happen due to dependencies,
outside of the layer being scanned, will show up as signature problems.

The add_layer function was split into two pieces so that we can process
the dependencies first, and then add the layer itself for the comparison.

Signed-off-by: Mark Hatle 
---
 scripts/lib/compatlayer/__init__.py |  7 ---
 scripts/yocto-compat-layer.py   | 29 +++--
 2 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index 24edc88..06c84f4 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -139,9 +139,7 @@ def _find_layer_depends(depend, layers):
 return layer
 return None
 
-def add_layer(bblayersconf, layer, layers, logger):
-logger.info('Adding layer %s' % layer['name'])
-
+def add_layer_dependencies(bblayersconf, layer, layers, logger):
 def recurse_dependencies(depends, layer, layers, logger, ret = []):
 logger.debug('Processing dependencies %s for layer %s.' % \
 (depends, layer['name']))
@@ -191,7 +189,10 @@ def add_layer(bblayersconf, layer, layers, logger):
 logger.info('Adding layer dependency %s' % layer_depend['name'])
 with open(bblayersconf, 'a+') as f:
 f.write("\nBBLAYERS += \"%s\"\n" % layer_depend['path'])
+return True
 
+def add_layer(bblayersconf, layer, layers, logger):
+logger.info('Adding layer %s' % layer['name'])
 with open(bblayersconf, 'a+') as f:
 f.write("\nBBLAYERS += \"%s\"\n" % layer['path'])
 
diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index f8a1ac7..22c0c2d 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -22,7 +22,7 @@ import scriptpath
 scriptpath.add_oe_lib_path()
 scriptpath.add_bitbake_lib_path()
 
-from compatlayer import LayerType, detect_layers, add_layer, get_signatures
+from compatlayer import LayerType, detect_layers, add_layer, 
add_layer_dependencies, get_signatures
 from oeqa.utils.commands import get_bb_vars
 
 PROGNAME = 'yocto-compat-layer'
@@ -116,29 +116,38 @@ def main():
 results = collections.OrderedDict()
 results_status = collections.OrderedDict()
 
-logger.info('')
-logger.info('Getting initial bitbake variables ...')
-td['bbvars'] = get_bb_vars()
-logger.info('Getting initial signatures ...')
-td['builddir'] = builddir
-td['sigs'] = get_signatures(td['builddir'])
-logger.info('')
-
 layers_tested = 0
 for layer in layers:
 if layer['type'] == LayerType.ERROR_NO_LAYER_CONF or \
 layer['type'] == LayerType.ERROR_BSP_DISTRO:
 continue
 
+logger.info('')
+logger.info("Setting up for %s(%s), %s" % (layer['name'], 
layer['type'],
+layer['path']))
+
 shutil.copyfile(bblayersconf + '.backup', bblayersconf)
 
-if not add_layer(bblayersconf, layer, dep_layers, logger):
+if not add_layer_dependencies(bblayersconf, layer, dep_layers, logger):
 logger.info('Skipping %s due to missing dependencies.' % 
layer['name'])
 results[layer['name']] = None
 results_status[layer['name']] = 'SKIPPED (Missing dependencies)'
 layers_tested = layers_tested + 1
 continue
 
+logger.info('Getting initial bitbake variables ...')
+td['bbvars'] = get_bb_vars()
+logger.info('Getting initial signatures ...')
+td['builddir'] = builddir
+td['sigs'] = get_signatures(td['builddir'])
+
+if not add_layer(bblayersconf, layer, dep_layers, logger):
+logger.info('Skipping %s ???.' % layer['name'])
+results[layer['name']] = None
+results_status[layer['name']] = 'SKIPPED (Unknown)'
+layers_tested = layers_tested + 1
+continue
+
 result = test_layer_compatibility(td, layer)
 results[layer['name']] = result
 results_status[layer['name']] = 'PASS' if 
results[layer['name']].wasSuccessful() else 'FAIL'
-- 
1.8.3.1

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

[OE-core] [PATCH 1/4] yocto-compat-layer.py: Add status for skipped items

[Mark Hatle]

If items were skipped because the dependencies could not be found, we
want to record this was skipped so we can display it later.

Signed-off-by: Mark Hatle 
---
 scripts/yocto-compat-layer.py | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/scripts/yocto-compat-layer.py b/scripts/yocto-compat-layer.py
index 9e74033..d13d8c0 100755
--- a/scripts/yocto-compat-layer.py
+++ b/scripts/yocto-compat-layer.py
@@ -107,6 +107,7 @@ def main():
 
 td = {}
 results = collections.OrderedDict()
+results_status = collections.OrderedDict()
 
 logger.info('')
 logger.info('Getting initial bitbake variables ...')
@@ -125,19 +126,22 @@ def main():
 shutil.copyfile(bblayersconf + '.backup', bblayersconf)
 
 if not add_layer(bblayersconf, layer, layers, logger):
+results[layer['name']] = None
+results_status[layer['name']] = 'SKIPPED (Missing dependencies)'
+layers_tested = layers_tested + 1
 continue
 
 result = test_layer_compatibility(td, layer)
 results[layer['name']] = result
+results_status[layer['name']] = 'PASS' if 
results[layer['name']].wasSuccessful() else 'FAIL'
 layers_tested = layers_tested + 1
 
 if layers_tested:
 logger.info('')
 logger.info('Summary of results:')
 logger.info('')
-for layer_name in results:
-logger.info('%s ... %s' % (layer_name, 'PASS' if \
-results[layer_name].wasSuccessful() else 'FAIL'))
+for layer_name in results_status:
+logger.info('%s ... %s' % (layer_name, results_status[layer_name]))
 
 cleanup_bblayers(None, None)
 
-- 
1.8.3.1

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

[OE-core] [PATCH 0/4] yocto-compat-layer.py updates

[Mark Hatle]

The changes in this series fix a number of issues with the yocto-compat-layer
script.

- When a layer is skipped due to missing dependencies, it was difficult to
  see this without inspecting the whole log.

- There needs to be a way to pass in a list of layers that can be used
  for dependencies, but should not be evaluated in this pass.  The overall
  evaluation is very time consuming and having to parse/validate 15
  dependent layers to see if the layer you are working on passes is not
  useful!

- The dependency processing was not working properly.  It was only processing
  dependencies at one level.  Move this to a recursive process so we're
  sure that all needed dependencies are present.

- Change how the initial signatures are stored to be compared to the layers
  signatures for distro/BSP checks.  Before the signatures were stored very
  early (before any dependencies were calculated), causing the dependencies
  for a BSP layer to trigger a failure in signature validation.

Mark Hatle (4):
  yocto-compat-layer.py: Add status for skipped items
  yocto-compat-layer.py: Add --dependency argument
  compatlayer/__init__.py: Allow add_layer to process recursive deps
  yocto-compat-layer.py: Fix the signature validation

 scripts/lib/compatlayer/__init__.py | 47 ++---
 scripts/yocto-compat-layer.py   | 47 +++--
 2 files changed, 73 insertions(+), 21 deletions(-)

-- 
1.8.3.1

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

Re: [OE-core] [PATCH] busybox: drop unmaintained _git recipe

[ChenQi]

On 03/31/2017 02:06 AM, Andre McCurdy wrote:

The busybox _git recipe is not formally tested or kept up to date.
The gstreamer _git recipes were recently removed from oe-core and the
justifications for that change apply to the busybox _git recipe too.

Signed-off-by: Andre McCurdy 
---
  meta/recipes-core/busybox/busybox_git.bb | 52 
  1 file changed, 52 deletions(-)
  delete mode 100644 meta/recipes-core/busybox/busybox_git.bb

diff --git a/meta/recipes-core/busybox/busybox_git.bb 
b/meta/recipes-core/busybox/busybox_git.bb
deleted file mode 100644
index c2ee3e6..000
--- a/meta/recipes-core/busybox/busybox_git.bb
+++ /dev/null
@@ -1,52 +0,0 @@
-require busybox.inc
-
-SRCREV = "1b7c17391de66502dd7a97c866e0a33681edbb1f"
-# Lookout for PV bump too when SRCREV is changed
-PV = "1.25.0+git${SRCPV}"
-
-S = "${WORKDIR}/git"
-
-SRC_URI = "git://busybox.net/busybox.git \
-   file://busybox-udhcpc-no_deconfig.patch \
-   file://find-touchscreen.sh \
-   file://busybox-cron \
-   file://busybox-httpd \
-   file://busybox-udhcpd \
-   file://default.script \
-   file://simple.script \
-   file://hwclock.sh \
-   file://mount.busybox \
-   file://syslog \
-   file://syslog-startup.conf \
-   file://syslog.conf \
-   file://busybox-syslog.default \
-   file://mdev \
-   file://mdev.conf \
-   file://mdev-mount.sh \
-   file://umount.busybox \
-   file://defconfig \
-   file://busybox-syslog.service.in \
-   file://busybox-klogd.service.in \
-   file://fail_on_no_media.patch \
-   file://run-ptest \
-   file://inetd.conf \
-   file://inetd \
-   file://login-utilities.cfg \
-   file://recognize_connmand.patch \
-   file://busybox-cross-menuconfig.patch \
-   
file://0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch \
-   file://mount-via-label.cfg \
-   file://sha1sum.cfg \
-   file://sha256sum.cfg \
-   file://getopts.cfg \
-   file://resize.cfg \
-   ${@["", 
"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 'busybox')]} \
-   ${@["", "file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager') 
== 'busybox-mdev')]} \
-   file://inittab \
-   file://rcS \
-   file://rcK \
-   file://runlevel \
-"
-SRC_URI_append_libc-musl = " file://musl.cfg "
-
-DEFAULT_PREFERENCE = "-1"


Hi Andre,

This git recipe is maintained as far as I know. It was added so that it 
would be easier to hack with busybox. As busybox is broadly used in our 
project, an easier way to hack with it seems reasonable.


Best Regards,

Chen Qi


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

[OE-core] [oe-core][PATCH 1/1] volatile-binds: correct some errors reported by systemd

[Joe Slater]

systemd-tmpfiles-setup will fail at boot, so we suppress
the default versions of etc.conf and home.conf.

We also make sure that /var/{cache,spool} and /srv are writeable
if they exist.

Signed-off-by: Joe Slater 
---
 meta/recipes-core/volatile-binds/volatile-binds.bb |9 +
 1 file changed, 9 insertions(+)

diff --git a/meta/recipes-core/volatile-binds/volatile-binds.bb 
b/meta/recipes-core/volatile-binds/volatile-binds.bb
index f07458a..a6e3254 100644
--- a/meta/recipes-core/volatile-binds/volatile-binds.bb
+++ b/meta/recipes-core/volatile-binds/volatile-binds.bb
@@ -17,6 +17,9 @@ REQUIRED_DISTRO_FEATURES = "systemd"
 
 VOLATILE_BINDS ?= "\
 /var/volatile/lib /var/lib\n\
+/var/volatile/cache /var/cache\n\
+/var/volatile/spool /var/spool\n\
+/var/volatile/srv /srv\n\
 "
 VOLATILE_BINDS[type] = "list"
 VOLATILE_BINDS[separator] = "\n"
@@ -67,5 +70,11 @@ do_install () {
 for service in ${SYSTEMD_SERVICE_volatile-binds}; do
 install -m 0644 $service ${D}${systemd_unitdir}/system/
 done
+
+# Suppress attempts to process some tmpfiles that are not temporary.
+#
+install -d ${D}${sysconfdir}/tmpfiles.d ${D}/var/cache
+ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/etc.conf
+ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/home.conf
 }
 do_install[dirs] = "${WORKDIR}"
-- 
1.7.9.5

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

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

[Martin Kelly]

On 03/30/2017 12:31 PM, Khem Raj wrote:



On 3/30/17 12:20 PM, Martin Kelly wrote:

Hi,

I'm trying to integrate the meta-clang version of LLVM 4.0 (used for
recipes that need a newer LLVM version) alongside the oe-core version of
LLVM 3.3 (used for mesa). I'd like some recipes to use LLVM 4.0 and some
to use LLVM 3.3 and for them not to collide with each other.

Right now, once the meta-clang layer is enabled, the recipes collide
because they both provide llvm-common.bb. I tried explicitly versioning
llvm-common, which makes them no longer collide. However, mesa then
fails to build because the meta-clang version of LLVM installs
llvm-config into the native common sysroot in


merging all llvm-common into a single recipe might be good


I agree that this would be a good idea. However, at this point the two 
llvm-configs have diverged and return very different sets of flags, so 
they are basically incompatible. Specifically, the oe-core version of 
LLVM returns a set of flags that are not the same as the native 
CPPFLAGS, CFLAGS, etc, while the meta-clang version of llvm-config 
returns a set of flags that are the exact same as CPPFLAGS, CFLAGS, etc. 
See below for the full flag settings in both versions.


Clearly, using CPPFLAGS, CFLAGS, etc. directly breaks cross-compilation. 
For this reason, I added wrapper logic to return TARGET_CPPFLAGS, 
TARGET_CFLAGS, etc. in the meta-clang script, which allowed it to 
properly cross-compile. However, this wrapper logic, and the set of 
flags that the meta-clang llvm-config returns, is incompatible with what 
mesa expects when it calls llvm-config.


AFAICT, this difference in flags boils down to differences between the 
LLVM autotools-based build and the CMake build. For example, in LLVM 
3.3, the autotools build set LLVM_LDFLAGS like this:


./tools/llvm-config/Makefile:50:	$(Verb) $(ECHO) 
's/@LLVM_LDFLAGS@/$(subst /,\/,$(SUB_LDFLAGS))/' \


and SUB_LDFLAGS is empty:

./tools/llvm-config/Makefile:36:SUB_LDFLAGS :=

As a result, in the autotools-based LLVM 3.3, we get:

#define LLVM_LDFLAGS ""

... while the CMake LLVM 4.0 returns the host LDFLAGS, thus 
necessitating the wrapper logic for proper cross-compilation.


In short, (this is just a guess), it appears that the CMake LLVM build 
doesn't do cross-compilation properly, while the autotools-based build does.


I think that's the problem. Fixing it is harder :). We can always 
version both libraries rather than merging llvm-config, but that's ugly 
and not a great long-term strategy.


Can you think of a cleaner way to do this?

Flags:
---

LLVM 3.3 oe-core BuildVariables.inc, after configure step:

#define LLVM_CPPFLAGS " -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS"
#define LLVM_CFLAGS " -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O3 -fomit-frame-pointer -fPIC"

#define LLVM_LDFLAGS ""
#define LLVM_CXXFLAGS " -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O3 -fomit-frame-pointer 
-fvisibility-inlines-hidden -fno-exceptions -fPIC -Woverloaded-virtual 
-Wcast-qual"

---

LLVM 4.0 meta-clang BuildVariables.inc, after configure step:

---
#define LLVM_CPPFLAGS "  -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS"
#define LLVM_CFLAGS " 
-isystem[snip]/build/qemux86-64/tmp/sysroots/x86_64-linux/usr/include 
-O2 -pipe -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings 
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-comment 
-Werror=date-time -ffunction-sections -fdata-sections -DNDEBUG 
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS"
#define LLVM_LDFLAGS " 
-isystem[snip]/build/qemux86-64/tmp/sysroots/x86_64-linux/usr/include 
-O2 -pipe -D_GLIBCXX_USE_CXX11_ABI=0 
-L[snip]/build/qemux86-64/tmp/sysroots/x86_64-linux/usr/lib 
-L[snip]/build/qemux86-64/tmp/sysroots/x86_64-linux/lib 
-Wl,-rpath-link,[snip]/build/qemux86-64/tmp/sysroots/x86_64-linux/usr/lib 
-Wl,-rpath-link,[snip]/build/qemux86-64/tmp/sysroots/x86_64-linux/lib 
-Wl,-rpath,[snip]/build/qemux86-64/tmp/sysroots/x86_64-linux/usr/lib 
-Wl,-rpath,[snip]/build/qemux86-64/tmp/sysroots/x86_64-linux/lib -Wl,-O1"
#define LLVM_CXXFLAGS " 
-isystem[snip]/build/qemux86-64/tmp/sysroots/x86_64-linux/usr/include 
-O2 -pipe -D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -fvisibility-inlines-hidden 
-Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wno-missing-field-initializers -pedantic -Wno-long-long 
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment 
-Werror=date-time -std=c++11 -ffunction-sections -fdata-sections 
-DNDEBUG  -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MAC

[OE-core] [PATCH 1/1] oeqa/runtime/cases: Migrate underscore cases

[mariano . lopez]

From: Mariano Lopez 

There were two missing cases to be migrated to the new framework: _qemutiny and
_ptest.

qemutiny was straightforward.

ptest on the other hand wasn't working even in previous releases; it has been
migrated from smart to dnf, and how ptest packages are gathered to be
installed, adapted to use unicode, and removed a lot of code that wasn't needed
anymore.

Signed-off-by: Mariano Lopez 
---
 meta/lib/oeqa/runtime/cases/_ptest.py| 130 +--
 meta/lib/oeqa/runtime/cases/_qemutiny.py |  11 ++-
 2 files changed, 59 insertions(+), 82 deletions(-)

diff --git a/meta/lib/oeqa/runtime/cases/_ptest.py 
b/meta/lib/oeqa/runtime/cases/_ptest.py
index a243251..aaed9a5 100644
--- a/meta/lib/oeqa/runtime/cases/_ptest.py
+++ b/meta/lib/oeqa/runtime/cases/_ptest.py
@@ -1,30 +1,39 @@
-import unittest, os, shutil
-from oeqa.oetest import oeRuntimeTest, skipModule
-from oeqa.utils.decorators import *
+import os
+import shutil
+import subprocess
+
+from oeqa.runtime.case import OERuntimeTestCase
+from oeqa.core.decorator.depends import OETestDepends
+from oeqa.core.decorator.oeid import OETestID
+from oeqa.core.decorator.data import skipIfNotDataVar, skipIfNotFeature
+from oeqa.runtime.decorator.package import OEHasPackage
+
+from oeqa.runtime.cases.dnf import DnfTest
 from oeqa.utils.logparser import *
 from oeqa.utils.httpserver import HTTPService
-import bb
-import glob
-from oe.package_manager import RpmPkgsList
-import subprocess
 
-def setUpModule():
-if not oeRuntimeTest.hasFeature("package-management"):
-skipModule("Image doesn't have package management feature")
-if not oeRuntimeTest.hasPackage("smartpm"):
-skipModule("Image doesn't have smart installed")
-if "package_rpm" != 
oeRuntimeTest.tc.d.getVar("PACKAGE_CLASSES").split()[0]:
-skipModule("Rpm is not the primary package manager")
+class PtestRunnerTest(DnfTest):
+
+@classmethod
+def setUpClass(cls):
+rpm_deploy = os.path.join(cls.tc.td['DEPLOY_DIR'], 'rpm')
+cls.repo_server = HTTPService(rpm_deploy, cls.tc.target.server_ip)
+cls.repo_server.start()
 
-class PtestRunnerTest(oeRuntimeTest):
+@classmethod
+def tearDownClass(cls):
+cls.repo_server.stop()
 
 # a ptest log parser
 def parse_ptest(self, logfile):
-parser = Lparser(test_0_pass_regex="^PASS:(.+)", 
test_0_fail_regex="^FAIL:(.+)", section_0_begin_regex="^BEGIN: .*/(.+)/ptest", 
section_0_end_regex="^END: .*/(.+)/ptest")
+parser = Lparser(test_0_pass_regex="^PASS:(.+)",
+ test_0_fail_regex="^FAIL:(.+)",
+ section_0_begin_regex="^BEGIN: .*/(.+)/ptest",
+ section_0_end_regex="^END: .*/(.+)/ptest")
 parser.init()
 result = Result()
 
-with open(logfile) as f:
+with open(logfile, errors='replace') as f:
 for line in f:
 result_tuple = parser.parse_line(line)
 if not result_tuple:
@@ -50,70 +59,39 @@ class PtestRunnerTest(oeRuntimeTest):
 result.sort_tests()
 return result
 
-@classmethod
-def setUpClass(self):
-#note the existing channels that are on the board before creating new 
ones
-#self.existingchannels = set()
-#(status, result) = oeRuntimeTest.tc.target.run('smart channel --show 
| grep "\["', 0)
-#for x in result.split("\n"):
-#self.existingchannels.add(x)
-self.repo_server = 
HTTPService(oeRuntimeTest.tc.d.getVar('DEPLOY_DIR'), 
oeRuntimeTest.tc.target.server_ip)
-self.repo_server.start()
-
-@classmethod
-def tearDownClass(self):
-self.repo_server.stop()
-#remove created channels to be able to repeat the tests on same image
-#(status, result) = oeRuntimeTest.tc.target.run('smart channel --show 
| grep "\["', 0)
-#for x in result.split("\n"):
-#if x not in self.existingchannels:
-#oeRuntimeTest.tc.target.run('smart channel --remove 
'+x[1:-1]+' -y', 0)
-
-def add_smart_channel(self):
-image_pkgtype = self.tc.d.getVar('IMAGE_PKGTYPE')
-deploy_url = 'http://%s:%s/%s' %(self.target.server_ip, 
self.repo_server.port, image_pkgtype)
-pkgarchs = self.tc.d.getVar('PACKAGE_ARCHS').replace("-","_").split()
-for arch in os.listdir('%s/%s' % (self.repo_server.root_dir, 
image_pkgtype)):
-if arch in pkgarchs:
-self.target.run('smart channel -y --add {a} type=rpm-md 
baseurl={u}/{a}'.format(a=arch, u=deploy_url), 0)
-self.target.run('smart update', 0)
-
-def install_complementary(self, globs=None):
-installed_pkgs_file = 
os.path.join(oeRuntimeTest.tc.d.getVar('WORKDIR'),
-   "installed_pkgs.txt")
-self.pkgs_list = RpmPkgsList(oeRuntimeTest.tc.d, 
oeRuntimeTest.tc.d.getVar('IMAGE_ROOTFS'), 
oeRuntimeTest.tc.d.getVar('arch_var'), oeRunt

Re: [OE-core] [PATCH] net-tools: enable native and nativesdk variant

[Richard Purdie]

On Thu, 2017-03-30 at 14:47 -0700, Stephano Cetola wrote:
> This won't work, and it is failing on the ab.
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/bui
> lds/449/steps/BuildImages/logs/stdio
> 
> Just add a 'return' to your empty bash function and it'll work fine.

I tweaked the empty function to contain ":" and have updated -next
since I could do with a retest with minimal delta.

Cheers,

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

Re: [OE-core] [PATCH] net-tools: enable native and nativesdk variant

[Stephano Cetola]

This won't work, and it is failing on the ab.

https://autobuilder.yoctoproject.org/main/builders/nightly-no-x11/builds/449/steps/BuildImages/logs/stdio

Just add a 'return' to your empty bash function and it'll work fine.

Cheers,
Stephano

On 03/30, Patrick Ohly wrote:
> net-tools-native is needed by swtpm-wrappers (in meta-security)
> because swtpm_setup.sh calls netstat, which cannot be assumed to be
> present in all Linux installations (for example, it is not in OpenSUSE
> minimal base).
> 
> Signed-off-by: Patrick Ohly 
> ---
>  meta/recipes-extended/net-tools/net-tools_1.60-26.bb | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb 
> b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
> index be26735..4152a4f 100644
> --- a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
> +++ b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
> @@ -70,11 +70,20 @@ python do_patch() {
>  bb.build.exec_func('patch_do_patch', d)
>  }
>  
> +# i18n only enabled for the target, doesn't build for native
> +# and isn't needed there.
> +disable_i18n() {
> + sed -i -e 's/^I18N=1/# I18N=1/' ${S}/config.make
> +}
> +disable_i18n_class-target () {
> +}
> +
>  do_configure() {
>   # net-tools has its own config mechanism requiring "make config"
>   # we pre-generate desired options and copy to source directory instead
>   cp ${WORKDIR}/net-tools-config.h${S}/config.h
>   cp ${WORKDIR}/net-tools-config.make ${S}/config.make
> + disable_i18n
>  }
>  
>  do_compile() {
> @@ -125,3 +134,4 @@ python __anonymous() {
>  }
>  ALTERNATIVE_PRIORITY = "100"
>  
> +BBCLASSEXTEND = "native nativesdk"
> 
> base-commit: e4f5d88b8e69964c40e7011c1e7f33f6484b9090
> -- 
> git-series 0.9.1
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][morty][PATCH 1/1] volatile-binds: correct some errors reported by systemd

[Joe Slater]

systemd-tmpfiles-setup will fail at boot, so we suppress
the default versions of etc.conf and home.conf.

We also make sure that /var/{cache,spool} and /srv are writeable
if they exist.

Signed-off-by: Joe Slater 
---
 meta/recipes-core/volatile-binds/volatile-binds.bb |9 +
 1 file changed, 9 insertions(+)

diff --git a/meta/recipes-core/volatile-binds/volatile-binds.bb 
b/meta/recipes-core/volatile-binds/volatile-binds.bb
index fee7275..130ab55 100644
--- a/meta/recipes-core/volatile-binds/volatile-binds.bb
+++ b/meta/recipes-core/volatile-binds/volatile-binds.bb
@@ -17,6 +17,9 @@ REQUIRED_DISTRO_FEATURES = "systemd"
 
 VOLATILE_BINDS ?= "\
 /var/volatile/lib /var/lib\n\
+/var/volatile/cache /var/cache\n\
+/var/volatile/spool /var/spool\n\
+/var/volatile/srv /srv\n\
 "
 VOLATILE_BINDS[type] = "list"
 VOLATILE_BINDS[separator] = "\n"
@@ -67,5 +70,11 @@ do_install () {
 for service in ${SYSTEMD_SERVICE_volatile-binds}; do
 install -m 0644 $service ${D}${systemd_unitdir}/system/
 done
+
+# Suppress attempts to process some tmpfiles that are not temporary.
+#
+install -d ${D}${sysconfdir}/tmpfiles.d ${D}/var/cache
+ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/etc.conf
+ln -s /dev/null ${D}${sysconfdir}/tmpfiles.d/home.conf
 }
 do_install[dirs] = "${WORKDIR}"
-- 
1.7.9.5

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

[OE-core] [PATCH] selftest/pkgdata: replace the glibc recipe allowing execution on non-poky distros

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval 

Replace the glibc recipe for zlib on unit tests, otherwise tests are restricted
to glibc distros (poky).

[YOCTO #10890]

Signed-off-by: Leonardo Sandoval 
---
 meta/lib/oeqa/selftest/pkgdata.py | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/meta/lib/oeqa/selftest/pkgdata.py 
b/meta/lib/oeqa/selftest/pkgdata.py
index 36d8b34..d69c3c8 100644
--- a/meta/lib/oeqa/selftest/pkgdata.py
+++ b/meta/lib/oeqa/selftest/pkgdata.py
@@ -16,21 +16,21 @@ class OePkgdataUtilTests(oeSelfTest):
 # Ensure we have the right data in pkgdata
 logger = logging.getLogger("selftest")
 logger.info('Running bitbake to generate pkgdata')
-bitbake('glibc busybox zlib m4')
+bitbake('busybox zlib m4')
 
 @testcase(1203)
 def test_lookup_pkg(self):
 # Forward tests
-result = runCmd('oe-pkgdata-util lookup-pkg "glibc busybox"')
-self.assertEqual(result.output, 'libc6\nbusybox')
+result = runCmd('oe-pkgdata-util lookup-pkg "zlib busybox"')
+self.assertEqual(result.output, 'libz1\nbusybox')
 result = runCmd('oe-pkgdata-util lookup-pkg zlib-dev')
 self.assertEqual(result.output, 'libz-dev')
 result = runCmd('oe-pkgdata-util lookup-pkg nonexistentpkg', 
ignore_status=True)
 self.assertEqual(result.status, 1, "Status different than 1. output: 
%s" % result.output)
 self.assertEqual(result.output, 'ERROR: The following packages could 
not be found: nonexistentpkg')
 # Reverse tests
-result = runCmd('oe-pkgdata-util lookup-pkg -r "libc6 busybox"')
-self.assertEqual(result.output, 'glibc\nbusybox')
+result = runCmd('oe-pkgdata-util lookup-pkg -r "libz1 busybox"')
+self.assertEqual(result.output, 'zlib\nbusybox')
 result = runCmd('oe-pkgdata-util lookup-pkg -r libz-dev')
 self.assertEqual(result.output, 'zlib-dev')
 result = runCmd('oe-pkgdata-util lookup-pkg -r nonexistentpkg', 
ignore_status=True)
@@ -49,8 +49,8 @@ class OePkgdataUtilTests(oeSelfTest):
 
 @testcase(1198)
 def test_find_path(self):
-result = runCmd('oe-pkgdata-util find-path /lib/libc.so.6')
-self.assertEqual(result.output, 'glibc: /lib/libc.so.6')
+result = runCmd('oe-pkgdata-util find-path /lib/libz.so.1')
+self.assertEqual(result.output, 'zlib: /lib/libz.so.1')
 result = runCmd('oe-pkgdata-util find-path /usr/bin/m4')
 self.assertEqual(result.output, 'm4: /usr/bin/m4')
 result = runCmd('oe-pkgdata-util find-path /not/exist', 
ignore_status=True)
@@ -59,8 +59,8 @@ class OePkgdataUtilTests(oeSelfTest):
 
 @testcase(1204)
 def test_lookup_recipe(self):
-result = runCmd('oe-pkgdata-util lookup-recipe "libc6-staticdev 
busybox"')
-self.assertEqual(result.output, 'glibc\nbusybox')
+result = runCmd('oe-pkgdata-util lookup-recipe "libz-staticdev 
busybox"')
+self.assertEqual(result.output, 'zlib\nbusybox')
 result = runCmd('oe-pkgdata-util lookup-recipe libz-dbg')
 self.assertEqual(result.output, 'zlib')
 result = runCmd('oe-pkgdata-util lookup-recipe nonexistentpkg', 
ignore_status=True)
@@ -72,12 +72,11 @@ class OePkgdataUtilTests(oeSelfTest):
 # No arguments
 result = runCmd('oe-pkgdata-util list-pkgs')
 pkglist = result.output.split()
-self.assertIn('glibc-utils', pkglist, "Listed packages: %s" % 
result.output)
+self.assertIn('zlib', pkglist, "Listed packages: %s" % result.output)
 self.assertIn('zlib-dev', pkglist, "Listed packages: %s" % 
result.output)
 # No pkgspec, runtime
 result = runCmd('oe-pkgdata-util list-pkgs -r')
 pkglist = result.output.split()
-self.assertIn('libc6-utils', pkglist, "Listed packages: %s" % 
result.output)
 self.assertIn('libz-dev', pkglist, "Listed packages: %s" % 
result.output)
 # With recipe specified
 result = runCmd('oe-pkgdata-util list-pkgs -p zlib')
@@ -208,11 +207,10 @@ class OePkgdataUtilTests(oeSelfTest):
 self.track_for_cleanup(tempdir)
 pkglistfile = os.path.join(tempdir, 'pkglist')
 with open(pkglistfile, 'w') as f:
-f.write('libc6\n')
 f.write('libz1\n')
 f.write('busybox\n')
 result = runCmd('oe-pkgdata-util glob %s "*-dev"' % pkglistfile)
-desiredresult = ['libc6-dev', 'libz-dev', 'busybox-dev']
+desiredresult = ['libz-dev', 'busybox-dev']
 self.assertEqual(sorted(result.output.split()), sorted(desiredresult))
 # The following should not error (because when we use this during 
rootfs construction, sometimes the complementary package won't exist)
 result = runCmd('oe-pkgdata-util glob %s "*-nonexistent"' % 
pkglistfile)
@@ -225,5 +223,5 @@ class OePkgdataUtilTests(oeSelfTest):
 
 @testcase(1206)
 def test_specify_pkgdatadir(self

[OE-core] [PATCHv2 2/2] scripts: Add yocto-compat-layer-wrapper

[Aníbal Limón]

This script will be used to create it's own build directory to make
runs of yocto-compat-layer.py againts layers isolated.

Example:

$ source oe-init-build-env
$ yocto-compat-layer-wrapper LAYER_DIR LAYER_DIR_N

[YOCTO #11164]

Signed-off-by: Aníbal Limón 
---
 scripts/yocto-compat-layer-wrapper | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100755 scripts/yocto-compat-layer-wrapper

diff --git a/scripts/yocto-compat-layer-wrapper 
b/scripts/yocto-compat-layer-wrapper
new file mode 100755
index 000..db4b687
--- /dev/null
+++ b/scripts/yocto-compat-layer-wrapper
@@ -0,0 +1,27 @@
+#!/usr/bin/env bash
+
+# Yocto Project compatibility layer tool wrapper
+#
+# Creates a temprary build directory to run Yocto Project Compatible
+# script to avoid a contaminated environment.
+#
+# Copyright (C) 2017 Intel Corporation
+# Released under the MIT license (see COPYING.MIT)
+
+if [ -z "$BUILDDIR" ]; then
+   echo "Please source oe-init-build-env before run this script."
+   exit 2
+fi
+
+base_dir=$(realpath $BUILDDIR/../)
+cd $base_dir
+
+build_dir=$(mktemp -p $base_dir -d -t build-)
+
+source oe-init-build-env $build_dir
+yocto-compat-layer.py "$@"
+retcode=$?
+
+rm -rf $build_dir
+
+exit $retcode
-- 
2.1.4

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

[OE-core] [PATCHv2 1/2] scripts/lib/compatlayer: detect_layers always use realpath's

[Aníbal Limón]

If you are using relative paths and change to other folder for
execution it will fail, so use realpaths always.

[YOCTO #11164]

Signed-off-by: Aníbal Limón 
---
 scripts/lib/compatlayer/__init__.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/lib/compatlayer/__init__.py 
b/scripts/lib/compatlayer/__init__.py
index 58f94b7..087ac14 100644
--- a/scripts/lib/compatlayer/__init__.py
+++ b/scripts/lib/compatlayer/__init__.py
@@ -112,6 +112,7 @@ def detect_layers(layer_directories, no_auto):
 layers = []
 
 for directory in layer_directories:
+directory = os.path.realpath(directory)
 if directory[-1] == '/':
 directory = directory[0:-1]
 
-- 
2.1.4

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

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

[Khem Raj]

On 3/30/17 12:20 PM, Martin Kelly wrote:
> Hi,
> 
> I'm trying to integrate the meta-clang version of LLVM 4.0 (used for
> recipes that need a newer LLVM version) alongside the oe-core version of
> LLVM 3.3 (used for mesa). I'd like some recipes to use LLVM 4.0 and some
> to use LLVM 3.3 and for them not to collide with each other.
> 
> Right now, once the meta-clang layer is enabled, the recipes collide
> because they both provide llvm-common.bb. I tried explicitly versioning
> llvm-common, which makes them no longer collide. However, mesa then
> fails to build because the meta-clang version of LLVM installs
> llvm-config into the native common sysroot in

merging all llvm-common into a single recipe might be good

> tmp/sysroots/x86_64-linux/usr/bin/llvm-config . This llvm-config is
> based on LLVM 4.0, so when mesa picks it up, it gets confused and fails
> to build.
> 

rename llvm-config to something like llvm-config

> I'm trying to figure out the right way to fix this and get around it. Do
> you have any suggestions? I imagine there might be a quick-and-dirty way
> to do this and a nicer, long-term way to do it. I'm interested in
> hearing both.
> 
> Thanks,
> Martin



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

[Martin Kelly]

Hi,

I'm trying to integrate the meta-clang version of LLVM 4.0 (used for 
recipes that need a newer LLVM version) alongside the oe-core version of 
LLVM 3.3 (used for mesa). I'd like some recipes to use LLVM 4.0 and some 
to use LLVM 3.3 and for them not to collide with each other.


Right now, once the meta-clang layer is enabled, the recipes collide 
because they both provide llvm-common.bb. I tried explicitly versioning 
llvm-common, which makes them no longer collide. However, mesa then 
fails to build because the meta-clang version of LLVM installs 
llvm-config into the native common sysroot in 
tmp/sysroots/x86_64-linux/usr/bin/llvm-config . This llvm-config is 
based on LLVM 4.0, so when mesa picks it up, it gets confused and fails 
to build.


I'm trying to figure out the right way to fix this and get around it. Do 
you have any suggestions? I imagine there might be a quick-and-dirty way 
to do this and a nicer, long-term way to do it. I'm interested in 
hearing both.


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

Re: [OE-core] [PATCH] u-boot: Update to 2017.03 release

[Otavio Salvador]

On Thu, Mar 30, 2017 at 4:12 PM, Philip Balister  wrote:
> I've got a machine under development that boots from the 2013.01 recipe
> and a bbappend. I don't think it is a problem moving to .03, but I don't
> know. I'm not sure how many other BSP's have done the same.

If it is a full mainline machine it should be smooth; otherwise
sending the patch to enable it in mainline is the best long term
solution. Keeping a patch on top a recipe is a decision which ends
with the maintenance burden at the developer adding the patch.

External layers should not delay the additions or upgrades of recipes
of OE-Core. If maintenance is a concern, upstreaming is the best
choice or fork the U-Boot and keep the fork with an independent cycle.

> Meanwhile, I understand the desire of others who have work upstreamed in
> u-boot they like to use with the next release.

And it has been a way to endorse the upstreaming effort to reduce the
maintenance work.

> How many u-boot releases are there a year? How do they line up with YP
> releases? Should we carry two u-boot versions, similar to what happens
> with the kernel?

Every two months now. I see no reason to carry two versions. OE-Core
provides the basis and every BSP layers can maintain their own
versions.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] u-boot: Update to 2017.03 release

[Philip Balister]

On 03/30/2017 02:06 PM, Denys Dmytriyenko wrote:
> On Thu, Mar 30, 2017 at 04:12:08PM +0200, Marek Vasut wrote:
>> On 03/30/2017 03:24 PM, Denys Dmytriyenko wrote:
>>> On Thu, Mar 30, 2017 at 10:21:31AM +0200, Marek Vasut wrote:
 On 03/29/2017 11:56 PM, Denys Dmytriyenko wrote:
> On Mon, Mar 27, 2017 at 04:31:16PM +0200, Marek Vasut wrote:
>> On 03/27/2017 04:25 PM, Richard Purdie wrote:
>>> On Mon, 2017-03-27 at 16:22 +0200, Marek Vasut wrote:
 Upgrade U-Boot to the latest version.
>>>
>>> Wrong list and how does this compare to Ovatio's patch?
>>
>> I was not CCed on Otavio's patch :(
>
> Yeah, me neither, unfortunately - people just ignore maintainers file now.
>
> Good thing Ross copied me on the other discussion!
>
 Which other discussion ? :-(
>>>
>>> http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134682.html
>>>
>> I see. I'm all for updating to 2017.03 , since it fixes the OMAP serial
>> bug too :)
> 
> "Known devil is better than unknown angel"? :)
> 

I've got a machine under development that boots from the 2013.01 recipe
and a bbappend. I don't think it is a problem moving to .03, but I don't
know. I'm not sure how many other BSP's have done the same.

Meanwhile, I understand the desire of others who have work upstreamed in
u-boot they like to use with the next release.

How many u-boot releases are there a year? How do they line up with YP
releases? Should we carry two u-boot versions, similar to what happens
with the kernel?

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

[OE-core] ✗ patchtest: failure for wic: Fix fstype handling

[Patchwork]

== Series Details ==

Series: wic: Fix fstype handling
Revision: 1
URL   : https://patchwork.openembedded.org/series/6091/
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 6d6d0737a2)



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] ca-certificates: Fix symlinks to the certificates in nativesdk

[Christopher Larson]

On Thu, Mar 30, 2017 at 11:30 AM, Serhii Popovych 
wrote:

> >
> > On 29 March 2017 at 13:51, Serhii Popovych  > > wrote:
> >
> > That's great. What the subject of this change in openembedded-core?
> > I wish to test it.
> >
> > Because with current *master* I see problem is still here.
> >
> >
> > "sysroot-relativelinks: also consider links to dirs on the host"
> > oe-core c5b522378fff13962a5187d9d09979866f805cb5, now in master.
>
> Tested, works for SDK, but does not work for buildtools-tarball
> (e.g. bitbake buildtools-tarball).


Ah, that makes sense, sysroot-relativelinks being run is handled by
image.bbclass at this time, which wouldn’t be inherited for that recipe.
Perhaps add this to the recipe:

POPULATE_SDK_POST_TARGET_COMMAND += “rootfs_sysroot_relativelinks;"
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 7/9] wic: fix list of supported fstypes in help content

[Ed Bartosh]

Added vfat and msdos to the list of supported fstypes in
'wic help kickstart' output.

[YOCTO #11137]

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/help.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
index 148da89..aee2451 100644
--- a/scripts/lib/wic/help.py
+++ b/scripts/lib/wic/help.py
@@ -687,6 +687,8 @@ DESCRIPTION
apply to partitions created using '--source rootfs' (see
--source above).  Valid values are:
 
+ vfat
+ msdos
  ext2
  ext3
  ext4
-- 
2.1.4

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

[OE-core] [PATCH 6/9] wic: set correct system id for msdos partitions

[Ed Bartosh]

Explicitly set system id 0x6(FAT16) for msdos partitions.

Removed old code that attempts to achieve the same result
using 'parted ... lba off'.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/plugins/imager/direct.py | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py
index 79b948a..f2e6127 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -487,6 +487,8 @@ class PartitionedImage():
 parted_fs_type = "fat32"
 elif part.fstype == "msdos":
 parted_fs_type = "fat16"
+if not part.system_id:
+part.system_id = '0x6' # FAT16
 else:
 # Type for ext2/ext3/ext4/btrfs
 parted_fs_type = "ext2"
@@ -536,17 +538,6 @@ class PartitionedImage():
 (self.path, part.num, part.system_id),
 self.native_sysroot)
 
-# Parted defaults to enabling the lba flag for fat16 partitions,
-# which causes compatibility issues with some firmware (and really
-# isn't necessary).
-if parted_fs_type == "fat16":
-if self.ptable_format == 'msdos':
-logger.debug("Disable 'lba' flag for partition '%s' on 
disk '%s'",
- part.num, self.path)
-exec_native_cmd("parted -s %s set %d lba off" % \
-(self.path, part.num),
-self.native_sysroot)
-
 def cleanup(self):
 # remove partition images
 for image in set(self.partimages):
-- 
2.1.4

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

[OE-core] [PATCH 9/9] wic: remove prepare_empty_partition_squashfs

[Ed Bartosh]

There is not much sense in creation of empty squashfs
partition. It's also not possible to create empty squashfs
partition of specified size.

Even more, prepare_empty_partition_squashfs method is
absolutely broken. It raises exception when called and
even its signature differs from the rest of of similar
methods. It means that nobody uses it and it's safe
to remove it.

Removed prepare_empty_partition_squashfs method and
testing of empty squashfs partition.

Signed-off-by: Ed Bartosh 
---
 meta/lib/oeqa/selftest/wic.py |  3 +--
 scripts/lib/wic/partition.py  | 33 -
 2 files changed, 5 insertions(+), 31 deletions(-)

diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
index c160f5f..df5e060 100644
--- a/meta/lib/oeqa/selftest/wic.py
+++ b/meta/lib/oeqa/selftest/wic.py
@@ -729,8 +729,7 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
--exclude-path bin/ --r
 'part emptyvfat   --fstype vfat   --size 1M\n',
 'part emptymsdos  --fstype msdos  --size 1M\n',
 'part emptyext2   --fstype ext2   --size 1M\n',
-'part emptybtrfs  --fstype btrfs  --size 100M\n',
-'part emptysquash --fstype squashfs --size 1M\n'])
+'part emptybtrfs  --fstype btrfs  --size 100M\n'])
 wks.flush()
 cmd = "wic create %s -e %s -o %s" % (wks.name, img, self.resultdir)
 self.assertEqual(0, runCmd(cmd).status)
diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 6f324ad..5edb340 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -141,6 +141,10 @@ class Partition():
 native_sysroot)
 self.source_file = "%s/fs.%s" % (cr_workdir, self.fstype)
 else:
+if self.fstype == 'squashfs':
+raise WicError("It's not possible to create empty squashfs 
"
+   "partition '%s'" % (self.mountpoint))
+
 rootfs = "%s/fs_%s.%s.%s" % (cr_workdir, self.label,
  self.lineno, self.fstype)
 if os.path.isfile(rootfs):
@@ -390,35 +394,6 @@ class Partition():
 
 prepare_empty_partition_vfat = prepare_empty_partition_msdos
 
-def prepare_empty_partition_squashfs(self, cr_workdir, oe_builddir,
- native_sysroot):
-"""
-Prepare an empty squashfs partition.
-"""
-logger.warning("Creating of an empty squashfs %s partition was 
attempted. "
-   "Proceeding as requested.", self.mountpoint)
-
-path = "%s/fs_%s.%s" % (cr_workdir, self.label, self.fstype)
-if os.path.isfile(path):
-os.remove(path)
-
-# it is not possible to create a squashfs without source data,
-# thus prepare an empty temp dir that is used as source
-tmpdir = tempfile.mkdtemp()
-
-squashfs_cmd = "mksquashfs %s %s -noappend" % \
-   (tmpdir, path)
-exec_native_cmd(squashfs_cmd, native_sysroot)
-
-os.rmdir(tmpdir)
-
-# get the rootfs size in the right units for kickstart (kB)
-du_cmd = "du -Lbks %s" % path
-out = exec_cmd(du_cmd)
-fs_size = out.split()[0]
-
-self.size = int(fs_size)
-
 def prepare_swap_partition(self, cr_workdir, oe_builddir, native_sysroot):
 """
 Prepare a swap partition.
-- 
2.1.4

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

[OE-core] [PATCH 8/9] oe-selftest: test creation of msdos partition

[Ed Bartosh]

Added msdos partition to the .wks file in test_fs_types
wic test case.

[YOCTO #11137]

Signed-off-by: Ed Bartosh 
---
 meta/lib/oeqa/selftest/wic.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
index ff13eb8..c160f5f 100644
--- a/meta/lib/oeqa/selftest/wic.py
+++ b/meta/lib/oeqa/selftest/wic.py
@@ -727,6 +727,7 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
--exclude-path bin/ --r
 'part squash --fstype squashfs --source rootfs\n',
 'part swap   --fstype swap --size 1M\n',
 'part emptyvfat   --fstype vfat   --size 1M\n',
+'part emptymsdos  --fstype msdos  --size 1M\n',
 'part emptyext2   --fstype ext2   --size 1M\n',
 'part emptybtrfs  --fstype btrfs  --size 100M\n',
 'part emptysquash --fstype squashfs --size 1M\n'])
-- 
2.1.4

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

[OE-core] [PATCH 4/9] wic: support 'msdos' fstype

[Ed Bartosh]

Added prepare_empty_partition_msdos and prepare_rootfs_msdos
methods to support 'msdos' filesystem type.

Created aliases prepare_empty_partition_vfat and prepare_rootfs_vfat
to continue supporting creation of vfat patitiions.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/partition.py | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 28ad3e6..d59351c 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -290,10 +290,10 @@ class Partition():
 (self.fstype, rootfs_size * 1024, rootfs_dir, label_str, rootfs)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
 
-def prepare_rootfs_vfat(self, rootfs, oe_builddir, rootfs_dir,
-native_sysroot, pseudo):
+def prepare_rootfs_msdos(self, rootfs, oe_builddir, rootfs_dir,
+ native_sysroot, pseudo):
 """
-Prepare content for a vfat rootfs partition.
+Prepare content for a msdos/vfat rootfs partition.
 """
 du_cmd = "du -bks %s" % rootfs_dir
 out = exec_cmd(du_cmd)
@@ -314,6 +314,8 @@ class Partition():
 chmod_cmd = "chmod 644 %s" % rootfs
 exec_cmd(chmod_cmd)
 
+prepare_rootfs_vfat = prepare_rootfs_msdos
+
 def prepare_rootfs_squashfs(self, rootfs, oe_builddir, rootfs_dir,
 native_sysroot, pseudo):
 """
@@ -359,8 +361,8 @@ class Partition():
 (self.fstype, self.size * 1024, label_str, rootfs)
 exec_native_cmd(mkfs_cmd, native_sysroot)
 
-def prepare_empty_partition_vfat(self, rootfs, oe_builddir,
- native_sysroot):
+def prepare_empty_partition_msdos(self, rootfs, oe_builddir,
+  native_sysroot):
 """
 Prepare an empty vfat partition.
 """
@@ -376,6 +378,8 @@ class Partition():
 chmod_cmd = "chmod 644 %s" % rootfs
 exec_cmd(chmod_cmd)
 
+prepare_empty_partition_vfat = prepare_empty_partition_msdos
+
 def prepare_empty_partition_squashfs(self, cr_workdir, oe_builddir,
  native_sysroot):
 """
-- 
2.1.4

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

[OE-core] [PATCH 5/9] wic: set FAT 16 for msdos partitions

[Ed Bartosh]

Used '-F 16' parameter for mkdosfs to create FAT16 partitions for
'msdos' partition type.

[YOCTO #11137]

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/partition.py | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index d59351c..6f324ad 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -305,7 +305,12 @@ class Partition():
 if self.label:
 label_str = "-n %s" % self.label
 
-dosfs_cmd = "mkdosfs %s -S 512 -C %s %d" % (label_str, rootfs, 
rootfs_size)
+size_str = ""
+if self.fstype == 'msdos':
+size_str = "-F 16" # FAT 16
+
+dosfs_cmd = "mkdosfs %s -S 512 %s -C %s %d" % (label_str, size_str,
+   rootfs, rootfs_size)
 exec_native_cmd(dosfs_cmd, native_sysroot)
 
 mcopy_cmd = "mcopy -i %s -s %s/* ::/" % (rootfs, rootfs_dir)
@@ -372,7 +377,12 @@ class Partition():
 if self.label:
 label_str = "-n %s" % self.label
 
-dosfs_cmd = "mkdosfs %s -S 512 -C %s %d" % (label_str, rootfs, blocks)
+size_str = ""
+if self.fstype == 'msdos':
+size_str = "-F 16" # FAT 16
+
+dosfs_cmd = "mkdosfs %s -S 512 %s -C %s %d" % (label_str, size_str,
+   rootfs, blocks)
 exec_native_cmd(dosfs_cmd, native_sysroot)
 
 chmod_cmd = "chmod 644 %s" % rootfs
-- 
2.1.4

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

[OE-core] [PATCH 3/9] wic: don't silently skip unknown fstypes

[Ed Bartosh]

Fixed wic code that loops through hard-coded list of known fstypes
to find prepare_rootfs_ or prepare_empty_partition_
methods and silently skipping unknown fstypes.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/partition.py | 32 +---
 1 file changed, 13 insertions(+), 19 deletions(-)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index f0e88fb..28ad3e6 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -145,13 +145,11 @@ class Partition():
  self.lineno, self.fstype)
 if os.path.isfile(rootfs):
 os.remove(rootfs)
-for prefix in ("ext", "btrfs", "vfat", "squashfs"):
-if self.fstype.startswith(prefix):
-method = getattr(self,
- "prepare_empty_partition_" + prefix)
-method(rootfs, oe_builddir, native_sysroot)
-self.source_file = rootfs
-break
+
+prefix = "ext" if self.fstype.startswith("ext") else 
self.fstype
+method = getattr(self, "prepare_empty_partition_" + prefix)
+method(rootfs, oe_builddir, native_sysroot)
+self.source_file = rootfs
 return
 
 plugins = PluginMgr.get_plugins('source')
@@ -231,19 +229,15 @@ class Partition():
'--overhead-factor will be applied')
 self.size = int(round(float(rsize_bb)))
 
-for prefix in ("ext", "btrfs", "vfat", "squashfs"):
-if self.fstype.startswith(prefix):
-method = getattr(self, "prepare_rootfs_" + prefix)
-method(rootfs, oe_builddir, rootfs_dir, native_sysroot, pseudo)
-
-self.source_file = rootfs
+prefix = "ext" if self.fstype.startswith("ext") else self.fstype
+method = getattr(self, "prepare_rootfs_" + prefix)
+method(rootfs, oe_builddir, rootfs_dir, native_sysroot, pseudo)
+self.source_file = rootfs
 
-# get the rootfs size in the right units for kickstart (kB)
-du_cmd = "du -Lbks %s" % rootfs
-out = exec_cmd(du_cmd)
-self.size = int(out.split()[0])
-
-break
+# get the rootfs size in the right units for kickstart (kB)
+du_cmd = "du -Lbks %s" % rootfs
+out = exec_cmd(du_cmd)
+self.size = int(out.split()[0])
 
 def prepare_rootfs_ext(self, rootfs, oe_builddir, rootfs_dir,
native_sysroot, pseudo):
-- 
2.1.4

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

[OE-core] [PATCH 1/9] oe-selftest: fix incorrect fstype

[Ed Bartosh]

Fixed typo in wks content: squash->squashfs

Signed-off-by: Ed Bartosh 
---
 meta/lib/oeqa/selftest/wic.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
index 2401aaa..ff13eb8 100644
--- a/meta/lib/oeqa/selftest/wic.py
+++ b/meta/lib/oeqa/selftest/wic.py
@@ -729,7 +729,7 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
--exclude-path bin/ --r
 'part emptyvfat   --fstype vfat   --size 1M\n',
 'part emptyext2   --fstype ext2   --size 1M\n',
 'part emptybtrfs  --fstype btrfs  --size 100M\n',
-'part emptysquash --fstype squash --size 1M\n'])
+'part emptysquash --fstype squashfs --size 1M\n'])
 wks.flush()
 cmd = "wic create %s -e %s -o %s" % (wks.name, img, self.resultdir)
 self.assertEqual(0, runCmd(cmd).status)
-- 
2.1.4

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

[OE-core] [PATCH 2/9] wic: allow only supported fstypes

[Ed Bartosh]

Restricted possible values of --fstype to the list of
supported types. This should catch incorrect values
when .wks file is being parsed.

Removed checks for empty fstype and mentioning of
unsupported fstype 'ontrackdm6aux3'.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/ksparser.py  | 4 +++-
 scripts/lib/wic/partition.py | 8 ++--
 scripts/lib/wic/plugins/imager/direct.py | 2 --
 3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
index a039300..d026caa 100644
--- a/scripts/lib/wic/ksparser.py
+++ b/scripts/lib/wic/ksparser.py
@@ -136,7 +136,9 @@ class KickStart():
 part.add_argument('--exclude-path', nargs='+')
 part.add_argument("--extra-space", type=sizetype)
 part.add_argument('--fsoptions', dest='fsopts')
-part.add_argument('--fstype')
+part.add_argument('--fstype', default='vfat',
+  choices=('ext2', 'ext3', 'ext4', 'btrfs',
+   'squashfs', 'vfat', 'msdos', 'swap'))
 part.add_argument('--label')
 part.add_argument('--no-table', action='store_true')
 part.add_argument('--ondisk', '--ondrive', dest='disk', default='sda')
diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 647a6fb..f0e88fb 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -136,11 +136,11 @@ class Partition():
"specify a non-zero --size/--fixed-size for 
that "
"partition." % self.mountpoint)
 
-if self.fstype and self.fstype == "swap":
+if self.fstype == "swap":
 self.prepare_swap_partition(cr_workdir, oe_builddir,
 native_sysroot)
 self.source_file = "%s/fs.%s" % (cr_workdir, self.fstype)
-elif self.fstype:
+else:
 rootfs = "%s/fs_%s.%s.%s" % (cr_workdir, self.label,
  self.lineno, self.fstype)
 if os.path.isfile(rootfs):
@@ -217,10 +217,6 @@ class Partition():
 if os.path.isfile(rootfs):
 os.remove(rootfs)
 
-if not self.fstype:
-raise WicError("File system for partition %s not specified in "
-   "kickstart, use --fstype option" % self.mountpoint)
-
 # Get rootfs size from bitbake variable if it's not set in .ks file
 if not self.size:
 # Bitbake variable ROOTFS_SIZE is calculated in
diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py
index 67fd183..79b948a 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -487,8 +487,6 @@ class PartitionedImage():
 parted_fs_type = "fat32"
 elif part.fstype == "msdos":
 parted_fs_type = "fat16"
-elif part.fstype == "ontrackdm6aux3":
-parted_fs_type = "ontrackdm6aux3"
 else:
 # Type for ext2/ext3/ext4/btrfs
 parted_fs_type = "ext2"
-- 
2.1.4

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

[OE-core] [PATCH 0/9] wic: Fix fstype handling

[Ed Bartosh]

Hi,

This patchset adds support for msdos(FAT16) fstype (#11137) and fixes number of 
issues
in handling fstypes in wic code:
   - restricted supported fstypes in wks parser code
   - fixed the code that creates partitions of certain fstypes
   - removed support of empty squashfs partitions

The following changes since commit 6bbf3176fe227712a478f5b4b1fdcf9417a89568:

  oe-selftest: add test_image_bootpart_globbed test for wic (2017-03-30 
13:27:19 +0300)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ed/wic/wip
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ed/wic/wip

Ed Bartosh (9):
  oe-selftest: fix incorrect fstype
  wic: allow only supported fstypes
  wic: don't silently skip unknown fstypes
  wic: support 'msdos' fstype
  wic: set FAT 16 for msdos partitions
  wic: set correct system id for msdos partitions
  wic: fix list of supported fstypes in help content
  oe-selftest: test creation of msdos partition
  wic: remove prepare_empty_partition_squashfs

 meta/lib/oeqa/selftest/wic.py|  4 +-
 scripts/lib/wic/help.py  |  2 +
 scripts/lib/wic/ksparser.py  |  4 +-
 scripts/lib/wic/partition.py | 99 +---
 scripts/lib/wic/plugins/imager/direct.py | 15 +
 5 files changed, 48 insertions(+), 76 deletions(-)

--
Regards,
Ed

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

Re: [OE-core] [PATCH] ca-certificates: Fix symlinks to the certificates in nativesdk

[Serhii Popovych]

> 
> On 29 March 2017 at 13:51, Serhii Popovych  > wrote:
> 
> That's great. What the subject of this change in openembedded-core?
> I wish to test it.
> 
> Because with current *master* I see problem is still here.
> 
> 
> "sysroot-relativelinks: also consider links to dirs on the host"
> oe-core c5b522378fff13962a5187d9d09979866f805cb5, now in master.

Tested, works for SDK, but does not work for buildtools-tarball
(e.g. bitbake buildtools-tarball).

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

Re: [OE-core] Subscribing to openembedded-architecture list

[Philip Balister]

You should be able to join. Did you get any messages at all?

On 03/30/2017 06:32 AM, Konopelko, Pavel (P.) wrote:
> Hello everybody,
> 
> I wonder if openembedded-architecture list is closed, invitation-only or 
> something.  The OE wiki [1] does not mention any restrictions.  Nevertheless 
> I seem to be unable to subscribe via the web interface or via an e-mail 
> request (tried several times over the last couple of weeks).
> 
> What am I missing?
> 
> 
> Thanks,
> --Pavel Konopelko
> 
> [1] http://openembedded.org/wiki/Mailing_lists
> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Subscribing to openembedded-architecture list

[Konopelko, Pavel (P.)]

Hello everybody,

I wonder if openembedded-architecture list is closed, invitation-only or 
something.  The OE wiki [1] does not mention any restrictions.  Nevertheless I 
seem to be unable to subscribe via the web interface or via an e-mail request 
(tried several times over the last couple of weeks).

What am I missing?


Thanks,
--Pavel Konopelko

[1] http://openembedded.org/wiki/Mailing_lists


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

Re: [OE-core] [PATCH] u-boot: Update to 2017.03 release

[Denys Dmytriyenko]

On Thu, Mar 30, 2017 at 04:12:08PM +0200, Marek Vasut wrote:
> On 03/30/2017 03:24 PM, Denys Dmytriyenko wrote:
> > On Thu, Mar 30, 2017 at 10:21:31AM +0200, Marek Vasut wrote:
> >> On 03/29/2017 11:56 PM, Denys Dmytriyenko wrote:
> >>> On Mon, Mar 27, 2017 at 04:31:16PM +0200, Marek Vasut wrote:
>  On 03/27/2017 04:25 PM, Richard Purdie wrote:
> > On Mon, 2017-03-27 at 16:22 +0200, Marek Vasut wrote:
> >> Upgrade U-Boot to the latest version.
> >
> > Wrong list and how does this compare to Ovatio's patch?
> 
>  I was not CCed on Otavio's patch :(
> >>>
> >>> Yeah, me neither, unfortunately - people just ignore maintainers file now.
> >>>
> >>> Good thing Ross copied me on the other discussion!
> >>>
> >> Which other discussion ? :-(
> > 
> > http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134682.html
> > 
> I see. I'm all for updating to 2017.03 , since it fixes the OMAP serial
> bug too :)

"Known devil is better than unknown angel"? :)

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

[OE-core] [PATCH] busybox: drop unmaintained _git recipe

[Andre McCurdy]

The busybox _git recipe is not formally tested or kept up to date.
The gstreamer _git recipes were recently removed from oe-core and the
justifications for that change apply to the busybox _git recipe too.

Signed-off-by: Andre McCurdy 
---
 meta/recipes-core/busybox/busybox_git.bb | 52 
 1 file changed, 52 deletions(-)
 delete mode 100644 meta/recipes-core/busybox/busybox_git.bb

diff --git a/meta/recipes-core/busybox/busybox_git.bb 
b/meta/recipes-core/busybox/busybox_git.bb
deleted file mode 100644
index c2ee3e6..000
--- a/meta/recipes-core/busybox/busybox_git.bb
+++ /dev/null
@@ -1,52 +0,0 @@
-require busybox.inc
-
-SRCREV = "1b7c17391de66502dd7a97c866e0a33681edbb1f"
-# Lookout for PV bump too when SRCREV is changed
-PV = "1.25.0+git${SRCPV}"
-
-S = "${WORKDIR}/git"
-
-SRC_URI = "git://busybox.net/busybox.git \
-   file://busybox-udhcpc-no_deconfig.patch \
-   file://find-touchscreen.sh \
-   file://busybox-cron \
-   file://busybox-httpd \
-   file://busybox-udhcpd \
-   file://default.script \
-   file://simple.script \
-   file://hwclock.sh \
-   file://mount.busybox \
-   file://syslog \
-   file://syslog-startup.conf \
-   file://syslog.conf \
-   file://busybox-syslog.default \
-   file://mdev \
-   file://mdev.conf \
-   file://mdev-mount.sh \
-   file://umount.busybox \
-   file://defconfig \
-   file://busybox-syslog.service.in \
-   file://busybox-klogd.service.in \
-   file://fail_on_no_media.patch \
-   file://run-ptest \
-   file://inetd.conf \
-   file://inetd \
-   file://login-utilities.cfg \
-   file://recognize_connmand.patch \
-   file://busybox-cross-menuconfig.patch \
-   
file://0001-Use-CC-when-linking-instead-of-LD-and-use-CFLAGS-and.patch \
-   file://mount-via-label.cfg \
-   file://sha1sum.cfg \
-   file://sha256sum.cfg \
-   file://getopts.cfg \
-   file://resize.cfg \
-   ${@["", 
"file://init.cfg"][(d.getVar('VIRTUAL-RUNTIME_init_manager') == 'busybox')]} \
-   ${@["", "file://mdev.cfg"][(d.getVar('VIRTUAL-RUNTIME_dev_manager') 
== 'busybox-mdev')]} \
-   file://inittab \
-   file://rcS \
-   file://rcK \
-   file://runlevel \
-"
-SRC_URI_append_libc-musl = " file://musl.cfg "
-
-DEFAULT_PREFERENCE = "-1"
-- 
1.9.1

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

Re: [OE-core] [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper

[Aníbal Limón]

On 03/30/2017 10:58 AM, Joshua Lock wrote:
> On Thu, 2017-03-30 at 10:43 -0600, Aníbal Limón wrote:
>>
>> On 03/30/2017 10:13 AM, Patrick Ohly wrote:
>>> On Thu, 2017-03-30 at 10:03 -0600, Aníbal Limón wrote:

 On 03/30/2017 12:02 AM, Patrick Ohly wrote:
> On Wed, 2017-03-29 at 15:44 -0600, Aníbal Limón wrote:
> ...
>> +show_help() {
>> +printf "Usage: %s [-o output_log] [-h] LAYER_DIR
>> ...\n" $0
>> +}
>> +
>
> ...
>> +env_dir=$(mktemp -d -t yocto-compat-)
>> +echo "The environment will be setup at $env_dir"
>> +echo ""
>
> The directory gets created, but not removed.

 I didn't remove the temp directory because may be the user wants
 to
 access the dir after the check.
>>>
>>> I think that this should be something that the user explicitly
>>> needs to
>>> request. As it is now, accumulating directories in /tmp when
>>> invoking
>>> the script is just unexpected and not the normal behavior of tools
>>> creating something in /tmp.
>>
>> Ok, i will add an option to don't delete and change the default
>> behavior
>> to delete after check.
>>
>>
>>>
>> +echo "Cloning oe-core..."
>> +git clone $oe_core_repo $env_dir
>> +if [ $? -ne 0 ]; then
>> +echo "Failed to clone oe-core repository"
>> +exit 1
>> +fi
>> +
>> +echo "Cloning bitbake..."
>> +git clone $bitbake_repo $env_dir/bitbake
>> +if [ $? -ne 0 ]; then
>> +echo "Failed to clone bitbake repository"
>> +exit 1
>> +fi
>
> Cloning bitbake and OE-core each time the script runs will be
> fairly
> slow. There's also a chicken-and-egg problem: if you don't have
> bitbake,
> where's the script?
>
> I'd prefer to use an existing checkout of both, just as for the
> layers
> which are to be tested.

 I choose to clone the oe-core/bitbake to ensure there are a clean
 environment, without any previous layer added.
>>>
>>> I don't quite get that argument. When using existing bitbake and
>>> OE-core
>>> directories, how can they have layers added to them? I understand
>>> that
>>> the existing checkout might contain additional modifications and/or
>>> might not match current master, but I consider that a feature. As
>>> it
>>> stands now, the caller of the script cannot test against Yocto 2.3
>>> once
>>> it is released, because the script will always check out master.
>>>
>>> Control over that can of course also be added to the script, but I
>>> just
>>> don't see the need for all this additional complexity. Just my 2
>>> cents.
>>
>> That's the original issue to create this script, if a user tries to
>> validate a layer and has modifications in configuration (bblayers,
>> local, auto), the check will be contaminated in some how.
> 
> Those are all build-directory state, not items which are tracked in the
> git repository.
> 
> Rather than cloning repositories to ensure clean state your script
> could ensure a unique/new build directory by sourcing oe-init-build-env 
> with a non-standard build directory, perhaps checking whether the
> directory exists first and adding random characters until you get
> something new?

That's a very good idea, i can generate tmp build directory and in this
way we can delete the logic for clone a new repository, so if anyone
reject, i'll do that.

Anibal

> 
> Joshua
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper

[Joshua Lock]

On Thu, 2017-03-30 at 10:43 -0600, Aníbal Limón wrote:
> 
> On 03/30/2017 10:13 AM, Patrick Ohly wrote:
> > On Thu, 2017-03-30 at 10:03 -0600, Aníbal Limón wrote:
> > > 
> > > On 03/30/2017 12:02 AM, Patrick Ohly wrote:
> > > > On Wed, 2017-03-29 at 15:44 -0600, Aníbal Limón wrote:
> > > > ...
> > > > > +show_help() {
> > > > > + printf "Usage: %s [-o output_log] [-h] LAYER_DIR
> > > > > ...\n" $0
> > > > > +}
> > > > > +
> > > > 
> > > > ...
> > > > > +env_dir=$(mktemp -d -t yocto-compat-)
> > > > > +echo "The environment will be setup at $env_dir"
> > > > > +echo ""
> > > > 
> > > > The directory gets created, but not removed.
> > > 
> > > I didn't remove the temp directory because may be the user wants
> > > to
> > > access the dir after the check.
> > 
> > I think that this should be something that the user explicitly
> > needs to
> > request. As it is now, accumulating directories in /tmp when
> > invoking
> > the script is just unexpected and not the normal behavior of tools
> > creating something in /tmp.
> 
> Ok, i will add an option to don't delete and change the default
> behavior
> to delete after check.
> 
> 
> > 
> > > > > +echo "Cloning oe-core..."
> > > > > +git clone $oe_core_repo $env_dir
> > > > > +if [ $? -ne 0 ]; then
> > > > > + echo "Failed to clone oe-core repository"
> > > > > + exit 1
> > > > > +fi
> > > > > +
> > > > > +echo "Cloning bitbake..."
> > > > > +git clone $bitbake_repo $env_dir/bitbake
> > > > > +if [ $? -ne 0 ]; then
> > > > > + echo "Failed to clone bitbake repository"
> > > > > + exit 1
> > > > > +fi
> > > > 
> > > > Cloning bitbake and OE-core each time the script runs will be
> > > > fairly
> > > > slow. There's also a chicken-and-egg problem: if you don't have
> > > > bitbake,
> > > > where's the script?
> > > > 
> > > > I'd prefer to use an existing checkout of both, just as for the
> > > > layers
> > > > which are to be tested.
> > > 
> > > I choose to clone the oe-core/bitbake to ensure there are a clean
> > > environment, without any previous layer added.
> > 
> > I don't quite get that argument. When using existing bitbake and
> > OE-core
> > directories, how can they have layers added to them? I understand
> > that
> > the existing checkout might contain additional modifications and/or
> > might not match current master, but I consider that a feature. As
> > it
> > stands now, the caller of the script cannot test against Yocto 2.3
> > once
> > it is released, because the script will always check out master.
> > 
> > Control over that can of course also be added to the script, but I
> > just
> > don't see the need for all this additional complexity. Just my 2
> > cents.
> 
> That's the original issue to create this script, if a user tries to
> validate a layer and has modifications in configuration (bblayers,
> local, auto), the check will be contaminated in some how.

Those are all build-directory state, not items which are tracked in the
git repository.

Rather than cloning repositories to ensure clean state your script
could ensure a unique/new build directory by sourcing oe-init-build-env 
with a non-standard build directory, perhaps checking whether the
directory exists first and adding random characters until you get
something new?

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

Re: [OE-core] [PATCH v5] oeqa/sdk/cases:Adds validation for SDK compatibility tests

[Burton, Ross]

On 30 March 2017 at 00:12, Francisco Pedraza <
francisco.j.pedraza.gonza...@intel.com> wrote:

> @@ -9,7 +9,9 @@ class GalculatorTest(OESDKTestCase):
>  @classmethod
>  def setUpClass(self):
>  if not (self.tc.hasTargetPackage("gtk+3") or\
> -self.tc.hasTargetPackage("libgtk-3.0")):
> +self.tc.hasTargetPackage("libgtk-3.0") or
> +self.tc.hasTargetPackage("gtk") or
> +self.tc.hasTargetPackage("matchbox-config-gtk")):
>  raise unittest.SkipTest("GalculatorTest class: SDK don't
> support gtk+3")
>

Why is this checking for what appears to be gtk+v2 ("gtk") or
matchbox-config-gtk (an application that shouldn't be in a SDK)?


> @@ -17,7 +17,9 @@ class BuildIptablesTest(OESDKTestCase):
>
>  machine = self.td.get("MACHINE")
>
> -if not self.tc.hasHostPackage("packagegroup-cross-canadian-%s" %
> machine):
> +if not (self.tc.hasTargetPackage("packagegroup-cross-canadian-%s"
> % machine) or
> +self.tc.hasTargetPackage("gcc-runtime") or
> +self.tc.hasTargetPackage("libgcc")):
>  raise unittest.SkipTest("SDK doesn't contain a cross-canadian
> toolchain")
>

Seems a very long-winded way of checking that a compiler is present...

@@ -8,7 +8,10 @@ from oeqa.sdk.case import OESDKTestCase
>  class PerlTest(OESDKTestCase):
>  @classmethod
>  def setUpClass(self):
> -if not self.tc.hasHostPackage("nativesdk-perl"):
> +if not (self.tc.hasHostPackage("nativesdk-perl") or
> +self.tc.hasHostPackage("perl-native") or
> +self.tc.hasHostPackage("libperl5") or
> +self.tc.hasHostPackage("perl")):
>  raise unittest.SkipTest("No perl package in the SDK")
>

As this is a test for the nativesdk part of the SDK, why does it care about
target (perl) or native (perl-native) packages?

 for f in ['test.pl']:
> diff --git a/meta/lib/oeqa/sdk/cases/python.py b/meta/lib/oeqa/sdk/cases/
> python.py
> index 94a296f..29705bf 100644
> --- a/meta/lib/oeqa/sdk/cases/python.py
> +++ b/meta/lib/oeqa/sdk/cases/python.py
> @@ -8,7 +8,10 @@ from oeqa.sdk.case import OESDKTestCase
>  class PythonTest(OESDKTestCase):
>  @classmethod
>  def setUpClass(self):
> -if not self.tc.hasHostPackage("nativesdk-python"):
> +if not (self.tc.hasHostPackage("nativesdk-python") or
> +self.tc.hasHostPackage("python-smartpm-native") or
> +self.tc.hasHostPackage("nativesdk-python3")):



Aside from the fact that oe-core master has recently moved from smart to
DNF, and Python2 to Python3, why does a test that just runs a basic Python
command care about smartpm?

Also the test also now checks for nativesdk-python3 but executes python,
which is python v2.

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

[OE-core] [PATCHv3] quilt: Fix paths for patch and perl

[Jussi Kukkonen]

Currently some shebang lines end up as
#! /usr/bin/env perl -w
env does not like the argument. Also the current sed to insert env
does not cover the copies ptests use. Fix these issues by:
 - using --with-perl to insert "env"
 - Replacing "-w" in shebang lines with a new "use warning;" line

Remove a EXTRA_OECONF_append_class_target from the native recipe.
Don't overwrite EXTRA_OECONF in native: the values should be correct
for native as well.

--with-patch is used within the gnu patch wrapper only: before this
commit the wrapper contained a (build host) path to native patch.

Also tweak one test so busybox mv output is accepted.

All ptests should now pass: Fixes [YOCTO #11221].

Signed-off-by: Jussi Kukkonen 
---

changes since v2:
 * Added missing leading space in EXTRA_OECONF_append


 meta/recipes-devtools/quilt/quilt-native.inc   |  3 +--
 meta/recipes-devtools/quilt/quilt.inc  |  9 ++-
 ...0001-tests-Allow-different-output-from-mv.patch | 29 ++
 meta/recipes-devtools/quilt/quilt_0.65.bb  | 10 
 4 files changed, 38 insertions(+), 13 deletions(-)
 create mode 100644 
meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch

diff --git a/meta/recipes-devtools/quilt/quilt-native.inc 
b/meta/recipes-devtools/quilt/quilt-native.inc
index fce5fa1..c706704 100644
--- a/meta/recipes-devtools/quilt/quilt-native.inc
+++ b/meta/recipes-devtools/quilt/quilt-native.inc
@@ -5,8 +5,7 @@ INHIBIT_AUTOTOOLS_DEPS = "1"
 inherit native
 
 PATCHTOOL = "patch"
-EXTRA_OECONF = "--disable-nls"
-EXTRA_OECONF_append_class-target = "--with-perl=perl"
+EXTRA_OECONF_append = " --disable-nls"
 
 do_configure () {
oe_runconf
diff --git a/meta/recipes-devtools/quilt/quilt.inc 
b/meta/recipes-devtools/quilt/quilt.inc
index 57e2a14..c7bb741 100644
--- a/meta/recipes-devtools/quilt/quilt.inc
+++ b/meta/recipes-devtools/quilt/quilt.inc
@@ -8,6 +8,7 @@ SRC_URI = "${SAVANNAH_GNU_MIRROR}/quilt/quilt-${PV}.tar.gz \
 file://run-ptest \
 file://Makefile \
 file://test.sh \
+file://0001-tests-Allow-different-output-from-mv.patch \
 "
 
 SRC_URI[md5sum] = "c67ba0228f5b7b8bbe469474661f92d6"
@@ -33,10 +34,16 @@ RDEPENDS_${PN} = "bash"
 EXTRA_OE_MAKE_ARGS_darwin ?= ""
 EXTRA_OE_MAKE_ARGS ?= "BUILD_ROOT=${D}"
 
-EXTRA_OECONF = "--with-perl=perl"
+EXTRA_OECONF = "--with-perl='${USRBINPATH}/env perl' --with-patch=patch"
 
 CACHED_CONFIGUREVARS += "ac_cv_path_BASH=/bin/bash"
 
+# Make sure we don't have "-w" in shebang lines: it breaks using
+# "/usr/bin/env perl" as parser
+do_configure_prepend () {
+   find ${S} -name "*.in" -exec sed -i -e "1s,^#\!.*@PERL@ -w$,#\! 
@PERL@\nuse warnings;," {} \;
+}
+
 # Don't setup symlinks to host utilities, we don't need them
 do_configure_append () {
sed -e 's,^COMPAT_SYMLINKS.*:=.*,COMPAT_SYMLINKS:=,' -i 
${S}/Makefile
diff --git 
a/meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch
 
b/meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch
new file mode 100644
index 000..21219a0
--- /dev/null
+++ 
b/meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch
@@ -0,0 +1,29 @@
+From 1530138960cfafbeefb95f2a760954c00b4d0ef0 Mon Sep 17 00:00:00 2001
+From: Jussi Kukkonen 
+Date: Wed, 29 Mar 2017 15:11:59 +0300
+Subject: [PATCH] tests: Allow different output from mv
+
+busybox mv has different error messages: fix the test
+
+Upstream-Status: Inappropriate [embedded]
+Signed-off-by: Jussi Kukkonen 
+---
+ test/failbackup.test | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/test/failbackup.test b/test/failbackup.test
+index 37046f7..fce6725 100644
+--- a/test/failbackup.test
 b/test/failbackup.test
+@@ -16,7 +16,7 @@ What happens when refresh fails because of a permission 
error?
+   $ cat > test.txt
+   < This is updated test.txt.
+   $ quilt refresh --backup
+-  >~ mv: cannot move [`']?%{P}test.diff'? to [`']?%{P}test.diff~'?: 
Permission denied
++  >~ mv: .*: Permission denied
+   $ echo %{?}
+   > 1
+ 
+-- 
+2.1.4
+
diff --git a/meta/recipes-devtools/quilt/quilt_0.65.bb 
b/meta/recipes-devtools/quilt/quilt_0.65.bb
index 00f900a..12859f0 100644
--- a/meta/recipes-devtools/quilt/quilt_0.65.bb
+++ b/meta/recipes-devtools/quilt/quilt_0.65.bb
@@ -4,13 +4,3 @@ RDEPENDS_${PN} += "patch diffstat bzip2 util-linux"
 SRC_URI += "file://aclocal.patch \
 file://gnu_patch_test_fix_target.patch \
"
-
-# fix build-distro specific perl path in the target perl scripts
-do_install_append() {
-   for perlscript in ${D}${datadir}/quilt/scripts/remove-trailing-ws 
${D}${datadir}/quilt/scripts/dependency-graph 
${D}${datadir}/quilt/scripts/edmail ${D}${bindir}/guards
-   do
-   if [ -f $perlscript ]; then
-   sed -i -e '1s,#!.*perl,#! ${USRBINPATH}/env perl,' 
$perlscript
-   fi
-  

Re: [OE-core] [PATCH v2 2/2] automake: Adjust shebang lines to remove interpreter path hardcode

[Richard Purdie]

On Tue, 2017-03-28 at 19:25 +, Serhii Popovych wrote:
> If build host perl (and other tools) is old and we use some kind
> of toolchain to provide recent perl/python/etc to the OE build
> we still locked to use build host perl due to hardcoded shebang
> lines in automake scripts.
> 
> Behaviour was observed with Enterprise Linux 6 and devtoolset
> toolchain from SCL (Software Collections) used to provide recent
> version of perl (not provided with default buildtools-tarball).
> 
> Pass /usr/bin/env perl in ac_cv_path_PERL configuration variables
> for class-native and class-nativesdk. Use patch to automake to
> replace
> -w option in shebang line with modern way to enable warnings on perl
> (i.e. "use warnings").
> 
> Note that ac_cv_path_PERL must be valid perl interpreter path
> since configure will check perl version and Flock implementation.
> It is not possible currently to use nativeperl from native
> sysroot because automake does not DEPENDS on perl-native (and
> doing so fails due to circular dependencies). Only possible
> solution is to overwrite shebangs with nativeperl somewhere at
> do_install() and update RDEPENDS for class-native. Or add perl
> symlinks to nativeperl in sysroot.
> 
> For now it seems good to use perl found by /usr/bin/env from
> automake-native.
> 
> Also add RDEPENDS for class-nativesdk and add nativesdk-perl to
> them.
> 
> v2: Corrected Upstream-Status tag.
> 
> Cc: XE-Linux 
> Signed-off-by: Serhii Popovych 

Again, the patch description and what it actually does don't match
(RDEPENDS)...

Cheers,

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

Re: [OE-core] [PATCH v3 1/2] autoconf: Adjust shebang lines to remove interpreter path hardcode

[Richard Purdie]

On Tue, 2017-03-28 at 19:25 +, Serhii Popovych wrote:
> If build host perl (and other tools) is old and we use some kind
> of toolchain to provide recent perl/python/etc to the OE build
> we still locked to use build host perl due to hardcoded shebang
> lines in autoconf scripts.
> 
> Behaviour was observed with Enterprise Linux 6 and devtoolset
> toolchain from SCL (Software Collections) used to provide recent
> version of perl (not provided with default buildtools-tarball).
> 
> Pass /usr/bin/env perl in ac_cv_path_PERL configuration variables
> for class-native and class-nativesdk. Use patch to autoconf to
> replace
> -w option in shebang line with modern way to enable warnings on perl
> (i.e. "use warnings").
> 
> Note that ac_cv_path_PERL must be valid perl interpreter path
> since configure will check perl version and Flock implementation.
> It is not possible currently to use nativeperl from native
> sysroot because autoconf does not DE
> OBPENDS on perl-native (and

Typo above.

> doing so fails due to circular dependencies). Only possible
> solution is to overwrite shebangs with nativeperl somewhere at
> do_install() and update RDEPENDS for class-native. Or add perl
> symlinks to nativeperl in sysroot.
> 
> For now it seems good to use perl found by /usr/bin/env from
> autoconf-native.
> 
> Also add RDEPENDS for class-nativesdk and add nativesdk-perl
> to them.
> 
> v3: Corrected Upstream-Status tag.
> v2: Just realized that files in quilt directory (.pc) patched
> unnecessarily.

Revision history should go under --- below.

> Cc: XE-Linux 
> Signed-off-by: Serhii Popovych 
> ---
>  meta/recipes-devtools/autoconf/autoconf.inc|   7 +-
>  ...tion-in-shebangs-with-modern-use-warnings.patch | 120
> +
>  meta/recipes-devtools/autoconf/autoconf_2.69.bb|   1 +
>  3 files changed, 127 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-devtools/autoconf/autoconf/autoconf-
> replace-w-option-in-shebangs-with-modern-use-warnings.patch
> 
> diff --git a/meta/recipes-devtools/autoconf/autoconf.inc
> b/meta/recipes-devtools/autoconf/autoconf.inc
> index b4e3356..408c5c9 100644
> --- a/meta/recipes-devtools/autoconf/autoconf.inc
> +++ b/meta/recipes-devtools/autoconf/autoconf.inc
> @@ -27,13 +27,18 @@ RDEPENDS_${PN} = "m4 gnu-config \
>     perl-module-data-dumper \
>    "
>  RDEPENDS_${PN}_class-native = "m4-native gnu-config-native"
> +RDEPENDS_${PN}_class-nativesdk = "nativesdk-m4 nativesdk-gnu-config
> nativesdk-perl"

This RDEPENDS change is not mentioned in the commit message. Does this
mean we suddenly start including perl in our SDKs or buildtools
tarballs? This should be a separate patch an include impact information
if you're really proposing this.

Cheers,

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

[OE-core] [PATCHv2] quilt: Fix paths for patch and perl

[Jussi Kukkonen]

Currently some shebang lines end up as
#! /usr/bin/env perl -w
env does not like the argument. Also the current sed to insert env
does not cover the copies ptests use. Fix these issues by:
 - using --with-perl to insert "env"
 - Replacing "-w" in shebang lines with a new "use warning;" line
   before configure

Remove a EXTRA_OECONF_append_class_target from the native recipe.
Don't overwrite EXTRA_OECONF in native: the values should be correct
for native as well.

--with-patch is used within the gnu patch wrapper only: before this
commit the wrapper contained a (build host) path to native patch.

Also tweak one test so busybox mv output is accepted.

All ptests should now pass: Fixes [YOCTO #11221].

Signed-off-by: Jussi Kukkonen 
---

nativesdk-quilt does not actually exist but using env to find perl
is still good form... So changes in v2:
 * Use --with-perl="${USRBINPATH}/env perl"
 * Instead of "-w" use "use warning;"
 * Use EXTRA_OECONF from .inc for native as well

Thanks,
  Jussi


 meta/recipes-devtools/quilt/quilt-native.inc   |  3 +--
 meta/recipes-devtools/quilt/quilt.inc  |  9 ++-
 ...0001-tests-Allow-different-output-from-mv.patch | 29 ++
 meta/recipes-devtools/quilt/quilt_0.65.bb  | 10 
 4 files changed, 38 insertions(+), 13 deletions(-)
 create mode 100644 
meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch

diff --git a/meta/recipes-devtools/quilt/quilt-native.inc 
b/meta/recipes-devtools/quilt/quilt-native.inc
index fce5fa1..adbd77a 100644
--- a/meta/recipes-devtools/quilt/quilt-native.inc
+++ b/meta/recipes-devtools/quilt/quilt-native.inc
@@ -5,8 +5,7 @@ INHIBIT_AUTOTOOLS_DEPS = "1"
 inherit native
 
 PATCHTOOL = "patch"
-EXTRA_OECONF = "--disable-nls"
-EXTRA_OECONF_append_class-target = "--with-perl=perl"
+EXTRA_OECONF_append = "--disable-nls"
 
 do_configure () {
oe_runconf
diff --git a/meta/recipes-devtools/quilt/quilt.inc 
b/meta/recipes-devtools/quilt/quilt.inc
index 57e2a14..c7bb741 100644
--- a/meta/recipes-devtools/quilt/quilt.inc
+++ b/meta/recipes-devtools/quilt/quilt.inc
@@ -8,6 +8,7 @@ SRC_URI = "${SAVANNAH_GNU_MIRROR}/quilt/quilt-${PV}.tar.gz \
 file://run-ptest \
 file://Makefile \
 file://test.sh \
+file://0001-tests-Allow-different-output-from-mv.patch \
 "
 
 SRC_URI[md5sum] = "c67ba0228f5b7b8bbe469474661f92d6"
@@ -33,10 +34,16 @@ RDEPENDS_${PN} = "bash"
 EXTRA_OE_MAKE_ARGS_darwin ?= ""
 EXTRA_OE_MAKE_ARGS ?= "BUILD_ROOT=${D}"
 
-EXTRA_OECONF = "--with-perl=perl"
+EXTRA_OECONF = "--with-perl='${USRBINPATH}/env perl' --with-patch=patch"
 
 CACHED_CONFIGUREVARS += "ac_cv_path_BASH=/bin/bash"
 
+# Make sure we don't have "-w" in shebang lines: it breaks using
+# "/usr/bin/env perl" as parser
+do_configure_prepend () {
+   find ${S} -name "*.in" -exec sed -i -e "1s,^#\!.*@PERL@ -w$,#\! 
@PERL@\nuse warnings;," {} \;
+}
+
 # Don't setup symlinks to host utilities, we don't need them
 do_configure_append () {
sed -e 's,^COMPAT_SYMLINKS.*:=.*,COMPAT_SYMLINKS:=,' -i 
${S}/Makefile
diff --git 
a/meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch
 
b/meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch
new file mode 100644
index 000..21219a0
--- /dev/null
+++ 
b/meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch
@@ -0,0 +1,29 @@
+From 1530138960cfafbeefb95f2a760954c00b4d0ef0 Mon Sep 17 00:00:00 2001
+From: Jussi Kukkonen 
+Date: Wed, 29 Mar 2017 15:11:59 +0300
+Subject: [PATCH] tests: Allow different output from mv
+
+busybox mv has different error messages: fix the test
+
+Upstream-Status: Inappropriate [embedded]
+Signed-off-by: Jussi Kukkonen 
+---
+ test/failbackup.test | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/test/failbackup.test b/test/failbackup.test
+index 37046f7..fce6725 100644
+--- a/test/failbackup.test
 b/test/failbackup.test
+@@ -16,7 +16,7 @@ What happens when refresh fails because of a permission 
error?
+   $ cat > test.txt
+   < This is updated test.txt.
+   $ quilt refresh --backup
+-  >~ mv: cannot move [`']?%{P}test.diff'? to [`']?%{P}test.diff~'?: 
Permission denied
++  >~ mv: .*: Permission denied
+   $ echo %{?}
+   > 1
+ 
+-- 
+2.1.4
+
diff --git a/meta/recipes-devtools/quilt/quilt_0.65.bb 
b/meta/recipes-devtools/quilt/quilt_0.65.bb
index 00f900a..12859f0 100644
--- a/meta/recipes-devtools/quilt/quilt_0.65.bb
+++ b/meta/recipes-devtools/quilt/quilt_0.65.bb
@@ -4,13 +4,3 @@ RDEPENDS_${PN} += "patch diffstat bzip2 util-linux"
 SRC_URI += "file://aclocal.patch \
 file://gnu_patch_test_fix_target.patch \
"
-
-# fix build-distro specific perl path in the target perl scripts
-do_install_append() {
-   for perlscript in ${D}${datadir}/quilt/scripts/remove-trailing-ws 
${D}${datadir}/quilt/scripts/dependency-graph 
${D}${datadir}/quilt

Re: [OE-core] [PATCH] ca-certificates: Fix symlinks to the certificates in nativesdk

[Burton, Ross]

On 29 March 2017 at 13:51, Serhii Popovych  wrote:

> That's great. What the subject of this change in openembedded-core?
> I wish to test it.
>
> Because with current *master* I see problem is still here.
>

"sysroot-relativelinks: also consider links to dirs on the host"
oe-core c5b522378fff13962a5187d9d09979866f805cb5, now in master.

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

Re: [OE-core] [PATCH] meta: define REAL_MULTIMACH_TARGET_SYS/SDKTARGETSYSROOT in bitbake.conf

[Ming Liu]

Hi, Richard:

No, it's not about multilib, but just some special requirement from my
company, we have 2 IMX5 machines and we want to separate the sdk install
path for them, so it's decided we append the ${MACHINE} to
REAL_MULTIMACH_TARGET_SYS, but in current poky, to achieve it, I need
extend two recipes, meta-environment.bbappend and populate_sdk_base
inheritor, since I can not override it in a conf file, otherwise some other
"REAL_MULTIMACH_TARGET_SYS = "none"" setting will be overriden as well.

BTW, do you mean this patch: "multilib_header: Update wrapper to handle arm
32/64 bit"?

//Ming Liu


2017-03-30 17:34 GMT+02:00 Richard Purdie <
richard.pur...@linuxfoundation.org>:

> On Thu, 2017-03-30 at 09:57 +0200, liu.min...@gmail.com wrote:
> > From: Ming Liu 
> >
> > REAL_MULTIMACH_TARGET_SYS is being defined and referred in several
> > recipes, which is redundant and not easy to be overriden, and
> > SDKTARGETSYSROOT is also defined in two recipes.
> >
> > So move their definitions to bitbake.conf.
>
> I have been wondering why you're needing to customise
> REAL_MULTIMACH_TARGET_SYS? Are you having trouble with arm multilibs?
> If so, the patches I just sent out might be useful...
>
> Cheers,
>
> Richard
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper

[Aníbal Limón]

On 03/30/2017 10:13 AM, Patrick Ohly wrote:
> On Thu, 2017-03-30 at 10:03 -0600, Aníbal Limón wrote:
>>
>> On 03/30/2017 12:02 AM, Patrick Ohly wrote:
>>> On Wed, 2017-03-29 at 15:44 -0600, Aníbal Limón wrote:
>>> ...
 +show_help() {
 +  printf "Usage: %s [-o output_log] [-h] LAYER_DIR ...\n" $0
 +}
 +
>>> ...
 +env_dir=$(mktemp -d -t yocto-compat-)
 +echo "The environment will be setup at $env_dir"
 +echo ""
>>>
>>> The directory gets created, but not removed.
>>
>> I didn't remove the temp directory because may be the user wants to
>> access the dir after the check.
> 
> I think that this should be something that the user explicitly needs to
> request. As it is now, accumulating directories in /tmp when invoking
> the script is just unexpected and not the normal behavior of tools
> creating something in /tmp.

Ok, i will add an option to don't delete and change the default behavior
to delete after check.


> 
 +echo "Cloning oe-core..."
 +git clone $oe_core_repo $env_dir
 +if [ $? -ne 0 ]; then
 +  echo "Failed to clone oe-core repository"
 +  exit 1
 +fi
 +
 +echo "Cloning bitbake..."
 +git clone $bitbake_repo $env_dir/bitbake
 +if [ $? -ne 0 ]; then
 +  echo "Failed to clone bitbake repository"
 +  exit 1
 +fi
>>>
>>> Cloning bitbake and OE-core each time the script runs will be fairly
>>> slow. There's also a chicken-and-egg problem: if you don't have bitbake,
>>> where's the script?
>>>
>>> I'd prefer to use an existing checkout of both, just as for the layers
>>> which are to be tested.
>>
>> I choose to clone the oe-core/bitbake to ensure there are a clean
>> environment, without any previous layer added.
> 
> I don't quite get that argument. When using existing bitbake and OE-core
> directories, how can they have layers added to them? I understand that
> the existing checkout might contain additional modifications and/or
> might not match current master, but I consider that a feature. As it
> stands now, the caller of the script cannot test against Yocto 2.3 once
> it is released, because the script will always check out master.
> 
> Control over that can of course also be added to the script, but I just
> don't see the need for all this additional complexity. Just my 2 cents.

That's the original issue to create this script, if a user tries to
validate a layer and has modifications in configuration (bblayers,
local, auto), the check will be contaminated in some how.

If you want to run in some previous cloned repository you can use
directly the yocto-compat-layer.py without the wrapper.

> 
>> I could add an option to
>> specify a oe-core/bitbake dir if isn't set then clone.
> 
> At the very least please do that.

Yes i will do.

Anibal
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for i386 machine.cfg: Explicitly disable 64BIT

[Patchwork]

== Series Details ==

Series: i386 machine.cfg: Explicitly disable 64BIT
Revision: 1
URL   : https://patchwork.openembedded.org/series/6088/
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 6d6d0737a2)



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] i386 machine.cfg: Explicitly disable 64BIT

[Saul Wold]

Since we do not set the 64 bit flags, newer kernels seem to build 64bit
config files by default. This is due to a hard-coded uname -m check that
selects the KBUILD_DEFCONFIG based on the host, not the cross target.

Similar to e9ec769926b2378e63380bd7762ce7ce201af151 in the yocto-kernel-cache 
repo

Signed-off-by: Saul Wold 
---
 .../substrate/target/arch/i386/recipes-kernel/linux/files/machine.cfg  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine.cfg
 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine.cfg
index 3b168b7..fe5b882 100644
--- 
a/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine.cfg
+++ 
b/scripts/lib/bsp/substrate/target/arch/i386/recipes-kernel/linux/files/machine.cfg
@@ -1,5 +1,8 @@
 # yocto-bsp-filename {{=machine}}.cfg
 CONFIG_X86_32=y
+# Must explicitly disable 64BIT
+# CONFIG_64BIT is not set
+
 CONFIG_MATOM=y
 CONFIG_PRINTK=y
 
-- 
2.7.4

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

Re: [OE-core] [PATCH] systemd: check 'efi' in MACHINE_FEATURES

[Burton, Ross]

On 30 March 2017 at 07:59, Mikko Ylinen 
wrote:

> I'm fine. Perhaps 'efi' should not be a PACKAGECONFIG at all (and
> unconditionally disabled here) and
> the functionality (just bootctl?) is moved in systemd-boot. Thoughts?
>

I'm not fully aware of the details here but this seems like a good idea.
Can you prepare a patch?

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

Re: [OE-core] [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper

[Patrick Ohly]

On Thu, 2017-03-30 at 10:03 -0600, Aníbal Limón wrote:
> 
> On 03/30/2017 12:02 AM, Patrick Ohly wrote:
> > On Wed, 2017-03-29 at 15:44 -0600, Aníbal Limón wrote:
> > ...
> >> +show_help() {
> >> +  printf "Usage: %s [-o output_log] [-h] LAYER_DIR ...\n" $0
> >> +}
> >> +
> > ...
> >> +env_dir=$(mktemp -d -t yocto-compat-)
> >> +echo "The environment will be setup at $env_dir"
> >> +echo ""
> > 
> > The directory gets created, but not removed.
> 
> I didn't remove the temp directory because may be the user wants to
> access the dir after the check.

I think that this should be something that the user explicitly needs to
request. As it is now, accumulating directories in /tmp when invoking
the script is just unexpected and not the normal behavior of tools
creating something in /tmp.

> >> +echo "Cloning oe-core..."
> >> +git clone $oe_core_repo $env_dir
> >> +if [ $? -ne 0 ]; then
> >> +  echo "Failed to clone oe-core repository"
> >> +  exit 1
> >> +fi
> >> +
> >> +echo "Cloning bitbake..."
> >> +git clone $bitbake_repo $env_dir/bitbake
> >> +if [ $? -ne 0 ]; then
> >> +  echo "Failed to clone bitbake repository"
> >> +  exit 1
> >> +fi
> > 
> > Cloning bitbake and OE-core each time the script runs will be fairly
> > slow. There's also a chicken-and-egg problem: if you don't have bitbake,
> > where's the script?
> > 
> > I'd prefer to use an existing checkout of both, just as for the layers
> > which are to be tested.
> 
> I choose to clone the oe-core/bitbake to ensure there are a clean
> environment, without any previous layer added.

I don't quite get that argument. When using existing bitbake and OE-core
directories, how can they have layers added to them? I understand that
the existing checkout might contain additional modifications and/or
might not match current master, but I consider that a feature. As it
stands now, the caller of the script cannot test against Yocto 2.3 once
it is released, because the script will always check out master.

Control over that can of course also be added to the script, but I just
don't see the need for all this additional complexity. Just my 2 cents.

> I could add an option to
> specify a oe-core/bitbake dir if isn't set then clone.

At the very least please do that.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [OE-core] [PATCH v4 2/2] meta/classes/populate_sdk: Adds support for generating eSDK manifest files

[Richard Purdie]

On Wed, 2017-03-29 at 10:12 -0700, Francisco Pedraza wrote:
> The functionalities to generate SDK and eSDK manifest files are
> different,
> the SDK comes from package information and the eSDK comes from sstate
> artifacts.
> Only execute write_sdk_{host, target}_manifest when is on
> populate_sdk class.
> 
> Adds new functions write_sdk{host, target}_ext_manifest to execute on
> postprocess
> in populate_sdk_ext because at the end we have all the sstate
> artifacts to generate the manifest.
> [YOCTO #9038]
> 
> Signed-off-by: Francisco Pedraza
> 

Whilst this works to a point, the minimal eSDK doesn't contain sstate
objects so I'm not sure this is actually going to work in that case? We
could always used the locked-sigs.inc file to act as an idea of what
the eSDK contains?

Also, your patch only considers MULTIMACH_TARGET_SYS and TARGET_SYS
architectures and we also have allarch and machine specific packages it
would miss.

Cheers,

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

Re: [OE-core] [PATCH v2 1/2] grub_git: extend recipe for proper target deployment

[Richard Purdie]

On Thu, 2017-03-30 at 13:02 +, Belal, Awais wrote:
> ping!

Sorry, these appear to have gotten lost in the system. The patches
don't apply any more, could you rebase and resend please?

Cheers,

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

Re: [OE-core] [PATCH 2/2] scripts: Add yocto-compat-layer-wrapper

[Aníbal Limón]

Sending to oe-core ml, i used wrong oe-core mail address, :/,

Anibal



On 03/30/2017 10:03 AM, Aníbal Limón wrote:
> 
> 
> On 03/30/2017 12:02 AM, Patrick Ohly wrote:
>> On Wed, 2017-03-29 at 15:44 -0600, Aníbal Limón wrote:
>> ...
>>> +show_help() {
>>> +   printf "Usage: %s [-o output_log] [-h] LAYER_DIR ...\n" $0
>>> +}
>>> +
>> ...
>>> +env_dir=$(mktemp -d -t yocto-compat-)
>>> +echo "The environment will be setup at $env_dir"
>>> +echo ""
>>
>> The directory gets created, but not removed.
> 
> I didn't remove the temp directory because may be the user wants to
> access the dir after the check.
> 
>>
>>> +echo "Cloning oe-core..."
>>> +git clone $oe_core_repo $env_dir
>>> +if [ $? -ne 0 ]; then
>>> +   echo "Failed to clone oe-core repository"
>>> +   exit 1
>>> +fi
>>> +
>>> +echo "Cloning bitbake..."
>>> +git clone $bitbake_repo $env_dir/bitbake
>>> +if [ $? -ne 0 ]; then
>>> +   echo "Failed to clone bitbake repository"
>>> +   exit 1
>>> +fi
>>
>> Cloning bitbake and OE-core each time the script runs will be fairly
>> slow. There's also a chicken-and-egg problem: if you don't have bitbake,
>> where's the script?
>>
>> I'd prefer to use an existing checkout of both, just as for the layers
>> which are to be tested.
> 
> I choose to clone the oe-core/bitbake to ensure there are a clean
> environment, without any previous layer added. I could add an option to
> specify a oe-core/bitbake dir if isn't set then clone.
> 
>>
>>> +cd $env_dir
>>> +source oe-init-build-env
>>> +if [[ -z $output_log ]]; then
>>> +   echo "Running yocto-compat-layer.py $layer_dirs"
>>> +   yocto-compat-layer.py $layer_dirs
>>> +else
>>> +   echo "Running yocto-compat-layer.py -o $output_log $layer_dirs"
>>> +   yocto-compat-layer.py -o $output_log $layer_dirs
>>> +fi
>>
>> It would be useful to accept and pass through all yocto-compat-layer.py
>> parameters, ideally without having to repeat a full list of them in the
>> argument parsing of the wrapper.
> 
> Agree,
> 
>   Anibal
>>
> 



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] meta: define REAL_MULTIMACH_TARGET_SYS/SDKTARGETSYSROOT in bitbake.conf

[Richard Purdie]

On Thu, 2017-03-30 at 09:57 +0200, liu.min...@gmail.com wrote:
> From: Ming Liu 
> 
> REAL_MULTIMACH_TARGET_SYS is being defined and referred in several
> recipes, which is redundant and not easy to be overriden, and
> SDKTARGETSYSROOT is also defined in two recipes.
> 
> So move their definitions to bitbake.conf.

I have been wondering why you're needing to customise 
REAL_MULTIMACH_TARGET_SYS? Are you having trouble with arm multilibs?
If so, the patches I just sent out might be useful...

Cheers,

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

[OE-core] [PATCH 2/5] linux-libc-headers: Allow arm kernel headers to coexist on 32/64 bit

[Richard Purdie]

Its rather sad we need to do this but in order to make combined 32 and 64 bit
SDKs work, we need a common set of headers and this is the delta that
allows things to work. It only applies on arm.

Signed-off-by: Richard Purdie 
---
 .../linux-libc-headers/linux-libc-headers.inc | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index 653a470..bb9a669 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -42,7 +42,7 @@ python __anonymous () {
 d.setVar("HEADER_FETCH_VER", "2.6")
 }
 
-inherit kernel-arch pkgconfig
+inherit kernel-arch pkgconfig multilib_header
 
 KORG_ARCHIVE_COMPRESSION ?= "xz"
 
@@ -68,6 +68,19 @@ do_install() {
find ${D}${includedir} -name ..install.cmd | xargs rm -f
 }
 
+do_install_append_aarch64 () {
+do_install_armmultilib
+}
+
+do_install_append_arm () {
+   do_install_armmultilib
+}
+
+do_install_armmultilib () {
+   oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h 
asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/mman.h asm/param.h 
asm/perf_regs.h
+   oe_multilib_header asm/posix_types.h asm/ptrace.h  asm/setup.h  
asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h  asm/statfs.h asm/swab.h 
 asm/types.h asm/unistd.h
+}
+
 BBCLASSEXTEND = "nativesdk"
 
 #DEPENDS = "cross-linkage"
-- 
2.7.4

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

[OE-core] [PATCH 4/5] linux-libc-headers: Drop 4.4

[Richard Purdie]

We've been using 4.10 for a while now, I think 4.4 was accidentally left
behind so clean it up.

Signed-off-by: Richard Purdie 
---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.4.bb | 9 -
 1 file changed, 9 deletions(-)
 delete mode 100644 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.4.bb

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.4.bb 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.4.bb
deleted file mode 100644
index 3763dc0..000
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.4.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-require linux-libc-headers.inc
-
-SRC_URI_append_libc-musl = "\
-file://0001-libc-compat.h-fix-some-issues-arising-from-in6.h.patch \
-file://0002-libc-compat.h-prevent-redefinition-of-struct-ethhdr.patch \
-file://0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch \
-   "
-SRC_URI[md5sum] = "9a78fa2eb6c68ca5a40ed5af08142599"
-SRC_URI[sha256sum] = 
"401d7c8fef594999a460d10c72c5a94e9c2e1022f16795ec51746b0d165418b2"
-- 
2.7.4

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

[OE-core] [PATCH 5/5] linux-libc-headers: Remove reference to cross-linkage

[Richard Purdie]

This is long dead (thankfully), remove stale reference/comment.

Signed-off-by: Richard Purdie 
---
 meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
index bb9a669..1b01741 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -83,7 +83,6 @@ do_install_armmultilib () {
 
 BBCLASSEXTEND = "nativesdk"
 
-#DEPENDS = "cross-linkage"
 RDEPENDS_${PN}-dev = ""
 RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPKGV})"
 
-- 
2.7.4

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

[OE-core] [PATCH 3/5] glibc-package: Allow 32 and 64 bit headers to exist on arm

[Richard Purdie]

With this change (combined with the previous linux-libc-header fix), a
combined sysroot for 32 and 64 bit arm works meaning our SDK works
correctly for that multilib setup.

Signed-off-by: Richard Purdie 
---
 meta/recipes-core/glibc/glibc-package.inc | 17 +
 1 file changed, 17 insertions(+)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 6e548cb..2ca5666 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -140,8 +140,25 @@ do_install_append_aarch64 () {
${D}/lib/ld-linux-aarch64_be.so.1
fi
fi
+   do_install_armmultilib
 }
 
+do_install_append_arm () {
+   do_install_armmultilib
+}
+
+do_install_armmultilib () {
+
+   oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h 
bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h bits/wordsize.h
+   oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h 
bits/pthreadtypes.h  bits/sem.h  bits/semaphore.h bits/setjmp.h
+   oe_multilib_header bits/shm.h bits/sigstack.h bits/stat.h bits/statfs.h 
bits/string.h bits/typesizes.h
+
+   oe_multilib_header fpu_control.h gnu/lib-names.h gnu/stubs.h ieee754.h
+
+   oe_multilib_header sys/elf.h sys/procfs.h sys/ptrace.h sys/ucontext.h 
sys/user.h
+}
+
+
 LOCALESTASH = "${WORKDIR}/stashed-locale"
 bashscripts = "mtrace sotruss xtrace"
 
-- 
2.7.4

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

[OE-core] [PATCH 1/5] multilib_header: Update wrapper to handle arm 32/64 bit

[Richard Purdie]

Having arm 32/64 bit headers coexisting turns out to be tricky. Unfortunately
our wrapper works using wordsize.h and this differs on arm so we can't use it.

Therefore replicate the logic here for arm. I did look into writing our
own wordsize.h but we also need to remap kernel headers on arm and
since wordsize.h comes from libc, that doesn't work for kernel headers.

Signed-off-by: Richard Purdie 
---
 meta/classes/multilib_header.bbclass |  7 ---
 scripts/multilib_header_wrapper.h| 26 --
 2 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/meta/classes/multilib_header.bbclass 
b/meta/classes/multilib_header.bbclass
index 304c28e..e03f5b1 100644
--- a/meta/classes/multilib_header.bbclass
+++ b/meta/classes/multilib_header.bbclass
@@ -13,13 +13,9 @@ oe_multilib_header() {
;;
*)
esac
-# We use
-# For ARM: We don't support multilib builds.
 # For MIPS: "n32" is a special case, which needs to be
 # distinct from both 64-bit and 32-bit.
 case ${TARGET_ARCH} in
-arm*)   return
-;;
 mips*)  case "${MIPSPKGSFX_ABI}" in
 "-n32")
ident=n32   
@@ -31,9 +27,6 @@ oe_multilib_header() {
 ;;
 *)  ident=${SITEINFO_BITS}
 esac
-   if echo ${TARGET_ARCH} | grep -q arm; then
-   return
-   fi
for each_header in "$@" ; do
   if [ ! -f "${D}/${includedir}/$each_header" ]; then
  bberror "oe_multilib_header: Unable to find header $each_header."
diff --git a/scripts/multilib_header_wrapper.h 
b/scripts/multilib_header_wrapper.h
index 5a87540..f516673 100644
--- a/scripts/multilib_header_wrapper.h
+++ b/scripts/multilib_header_wrapper.h
@@ -21,11 +21,23 @@
  * 
  */
 
-#include 
 
-#ifdef __WORDSIZE
+#if defined (__arm__)
+#define __MHWORDSIZE   32
+#elif defined (__aarch64__) && defined ( __LP64__)
+#define __MHWORDSIZE   64
+#elif defined (__aarch64__)
+#define __MHWORDSIZE   32
+#else
+#include 
+#if defined (__WORDSIZE)
+#define __MHWORDSIZE   __WORDSIZE
+#else
+#error "__WORDSIZE is not defined"
+#endif
+#endif
 
-#if __WORDSIZE == 32
+#if __MHWORDSIZE == 32
 
 #ifdef _MIPS_SIM
 
@@ -41,15 +53,9 @@
 #include 
 #endif
 
-#elif __WORDSIZE == 64
+#elif __MHWORDSIZE == 64
 #include 
 #else
 #error "Unknown __WORDSIZE detected"
 #endif /* matches #if __WORDSIZE == 32 */
-
-#else /* __WORDSIZE is not defined */
-
-#error "__WORDSIZE is not defined"
-
-#endif
   
-- 
2.7.4

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

Re: [OE-core] [PATCH] base.bbclass: ensure HOSTTOOLS links point to executables

[Burton, Ross]

On 30 March 2017 at 16:14, Martin Jansa  wrote:

> Shouldn't this bump required bitbake version?
>

Yes, there needs to be a corresponding version bump.

I'm hoping that we can re-order/stall to avoid bumping too many times
during M4.

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

Re: [OE-core] [PATCH] base.bbclass: ensure HOSTTOOLS links point to executables

[Martin Jansa]

Shouldn't this bump required bitbake version?

On Thu, Mar 30, 2017 at 3:34 PM, Ross Burton  wrote:

> Use the new executable argument to bb.utils.which() to ensure that the
> symlinks
> point to executable files and not for example directories with the right
> name
> which happened to be on $PATH.
>
> [ YOCTO #11256 ]
>
> Signed-off-by: Ross Burton 
> ---
>  meta/classes/base.bbclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index cf8748a..e29821f 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -128,9 +128,9 @@ def setup_hosttools_dir(dest, toolsvar, d, fatal=True):
>  for tool in tools:
>  desttool = os.path.join(dest, tool)
>  if not os.path.exists(desttool):
> -srctool = bb.utils.which(path, tool)
> +srctool = bb.utils.which(path, tool, executable=True)
>  if "ccache" in srctool:
> -srctool = bb.utils.which(path, tool, direction=1)
> +srctool = bb.utils.which(path, tool, executable=True,
> direction=1)
>  if srctool:
>  os.symlink(srctool, desttool)
>  else:
> --
> 2.8.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] net-tools: enable native and nativesdk variant

[Patrick Ohly]

net-tools-native is needed by swtpm-wrappers (in meta-security)
because swtpm_setup.sh calls netstat, which cannot be assumed to be
present in all Linux installations (for example, it is not in OpenSUSE
minimal base).

Signed-off-by: Patrick Ohly 
---
 meta/recipes-extended/net-tools/net-tools_1.60-26.bb | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb 
b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
index be26735..4152a4f 100644
--- a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
+++ b/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
@@ -70,11 +70,20 @@ python do_patch() {
 bb.build.exec_func('patch_do_patch', d)
 }
 
+# i18n only enabled for the target, doesn't build for native
+# and isn't needed there.
+disable_i18n() {
+   sed -i -e 's/^I18N=1/# I18N=1/' ${S}/config.make
+}
+disable_i18n_class-target () {
+}
+
 do_configure() {
# net-tools has its own config mechanism requiring "make config"
# we pre-generate desired options and copy to source directory instead
cp ${WORKDIR}/net-tools-config.h${S}/config.h
cp ${WORKDIR}/net-tools-config.make ${S}/config.make
+   disable_i18n
 }
 
 do_compile() {
@@ -125,3 +134,4 @@ python __anonymous() {
 }
 ALTERNATIVE_PRIORITY = "100"
 
+BBCLASSEXTEND = "native nativesdk"

base-commit: e4f5d88b8e69964c40e7011c1e7f33f6484b9090
-- 
git-series 0.9.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] selftest/pkgdata: support musl on unit tests

[Leonardo Sandoval]

On Thu, 2017-03-30 at 12:45 +0100, Burton, Ross wrote:
> 
> On 30 March 2017 at 07:39,
>  wrote:
> +# recipe-runtime-package relation for virtual/libc
> provider
> +Libc = collections.namedtuple('Libc', ['recipe',
> 'runtime_pkg', 'libpath', 'staticdev', 'utils', 'rutils'])
> +cls.libc = Libc('glibc', 'libc6', '/lib/libc.so.6',
> 'libc6-staticdev', 'glibc-utils', 'lib6-utils')
> +if get_bb_var('TCLIBC') == 'musl':
> +cls.libc = Libc('musl', 'musl',
> '/usr/lib/libc.so', 'musl-staticdev', None, None)
> 
> 
> Instead of all of this, why not just change the tests to use a
> different package?  The bulk of them were just using glibc as it's
> going to be built, but we've built zlib too so the tests could use
> that instead.

If you consider that replacing the libc for another recipe/package is
fine, I go that way.

Leo
> 
> 
> Ross


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

Re: [OE-core] [PATCH] u-boot: Update to 2017.03 release

[Marek Vasut]

On 03/30/2017 03:24 PM, Denys Dmytriyenko wrote:
> On Thu, Mar 30, 2017 at 10:21:31AM +0200, Marek Vasut wrote:
>> On 03/29/2017 11:56 PM, Denys Dmytriyenko wrote:
>>> On Mon, Mar 27, 2017 at 04:31:16PM +0200, Marek Vasut wrote:
 On 03/27/2017 04:25 PM, Richard Purdie wrote:
> On Mon, 2017-03-27 at 16:22 +0200, Marek Vasut wrote:
>> Upgrade U-Boot to the latest version.
>
> Wrong list and how does this compare to Ovatio's patch?

 I was not CCed on Otavio's patch :(
>>>
>>> Yeah, me neither, unfortunately - people just ignore maintainers file now.
>>>
>>> Good thing Ross copied me on the other discussion!
>>>
>> Which other discussion ? :-(
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134682.html
> 
I see. I'm all for updating to 2017.03 , since it fixes the OMAP serial
bug too :)

-- 
Best regards,
Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] base.bbclass: ensure HOSTTOOLS links point to executables

[Ross Burton]

Use the new executable argument to bb.utils.which() to ensure that the symlinks
point to executable files and not for example directories with the right name
which happened to be on $PATH.

[ YOCTO #11256 ]

Signed-off-by: Ross Burton 
---
 meta/classes/base.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index cf8748a..e29821f 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -128,9 +128,9 @@ def setup_hosttools_dir(dest, toolsvar, d, fatal=True):
 for tool in tools:
 desttool = os.path.join(dest, tool)
 if not os.path.exists(desttool):
-srctool = bb.utils.which(path, tool)
+srctool = bb.utils.which(path, tool, executable=True)
 if "ccache" in srctool:
-srctool = bb.utils.which(path, tool, direction=1)
+srctool = bb.utils.which(path, tool, executable=True, 
direction=1)
 if srctool:
 os.symlink(srctool, desttool)
 else:
-- 
2.8.1

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

Re: [OE-core] [PATCH morty] wic: partition: Add fsck to avoid corrupt EXT file systems

[Enrico Joerns]

Hi Daniel,

On 03/30/2017 02:30 PM, Daniel Schultz wrote:

This patch avoids the creation of a corrupt EXT file system.

Since there are no checks if a EXT file system was successfully created,
this should add to prevent possible system failures.

Signed-off-by: Daniel Schultz 
---
 scripts/lib/wic/partition.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 3b3bd2d..152eb7b 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -239,6 +239,9 @@ class Partition():
 (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)

+mkfs_cmd = "fsck.%s -pvfD %s" % (self.fstype, rootfs)
+exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
+
 def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
  native_sysroot, pseudo):
 """



maybe it's worth noting this check should not primary target fixing a 
corrupt ext4 (bad if mkfs created on!) but performs some directory 
optimization on the build host that otherwise would be performed on the 
target the next time something triggers an fsck.
Performing those optimizations on the target will also make fsck trigger 
a reboot!


As the options as provided will not fix a real corrupted EXT it might 
also be useful to change the patch description to not confuse about the 
impact of the change.


Regards, Enrico

--
Pengutronix e.K.   | Enrico Jörns|
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5080 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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

Re: [OE-core] [PATCH] u-boot: Update to 2017.03 release

[Denys Dmytriyenko]

On Thu, Mar 30, 2017 at 10:21:31AM +0200, Marek Vasut wrote:
> On 03/29/2017 11:56 PM, Denys Dmytriyenko wrote:
> > On Mon, Mar 27, 2017 at 04:31:16PM +0200, Marek Vasut wrote:
> >> On 03/27/2017 04:25 PM, Richard Purdie wrote:
> >>> On Mon, 2017-03-27 at 16:22 +0200, Marek Vasut wrote:
>  Upgrade U-Boot to the latest version.
> >>>
> >>> Wrong list and how does this compare to Ovatio's patch?
> >>
> >> I was not CCed on Otavio's patch :(
> > 
> > Yeah, me neither, unfortunately - people just ignore maintainers file now.
> > 
> > Good thing Ross copied me on the other discussion!
> > 
> Which other discussion ? :-(

http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134682.html

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

[OE-core] [PATCH V2] kernel.bbclass: move in addtask kernel_link_images statement from linux-yocto.inc

[liu . ming50]

From: Ming Liu 

Add kernel_link_images task in kernel.bbclass instead of adding it in
linux-yocto.inc, or else the recipes inheriting kernel.bbclass might
run into implicit dependency issues.

Signed-off-by: Ming Liu 
---
 meta/classes/kernel.bbclass   | 1 +
 meta/recipes-kernel/linux/linux-yocto.inc | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 244087a..bc09fba 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -538,6 +538,7 @@ do_kernel_link_images() {
ln -sf ../../../vmlinuz.bin
fi
 }
+addtask kernel_link_images after do_compile before do_strip
 
 do_strip() {
if [ -n "${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}" ]; then
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc 
b/meta/recipes-kernel/linux/linux-yocto.inc
index 556546f..637506a 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -65,6 +65,5 @@ do_install_append(){
 
 # extra tasks
 addtask kernel_version_sanity_check after do_kernel_metadata 
do_kernel_checkout before do_compile
-addtask kernel_link_images after do_compile before do_strip
 addtask validate_branches before do_patch after do_kernel_checkout
 addtask kernel_configcheck after do_configure before do_compile
-- 
2.7.4

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

[OE-core] [PATCH V2] kernel.bbclass: fix a typo

[liu . ming50]

From: Ming Liu 

In a addtask statement, do_strip should be strip.

Signed-off-by: Ming Liu 
---
 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 244087a..91c260a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -566,7 +566,7 @@ do_strip() {
 }
 do_strip[dirs] = "${B}"
 
-addtask do_strip before do_sizecheck after do_kernel_link_images
+addtask strip before do_sizecheck after do_kernel_link_images
 
 # Support checking the kernel size since some kernels need to reside in 
partitions
 # with a fixed length or there is a limit in transferring the kernel to memory
-- 
2.7.4

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

Re: [OE-core] [PATCH v2 2/2] grub-efi/live-vm-common: allow grub as EFI_PROVIDER

[Belal, Awais]

ping!

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Monday, January 30, 2017 6:25 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2 2/2]   grub-efi/live-vm-common:allow   
grubas  EFI_PROVIDER

ping!

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Tuesday, January 10, 2017 5:19 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2 2/2] grub-efi/live-vm-common:  allow   grub
as  EFI_PROVIDER

ping!

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Tuesday, January 3, 2017 5:34 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2 2/2] grub-efi/live-vm-common: allowgrub
as  EFI_PROVIDER

ping!

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Tuesday, December 27, 2016 5:15 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2 2/2] grub-efi/live-vm-common: allow grub   
as  EFI_PROVIDER

Ping!

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Friday, December 16, 2016 5:19 PM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH v2 2/2] grub-efi/live-vm-common: allow grub as
EFI_PROVIDER

This allows grub to be used as EFI_PROVIDER and
extends the grub-efi class so it can be used as is
when EFI_PROVIDER is grub.
Currently this can only be leveraged if you are
using the grub_git recipe and GRUBPLATFORM plus
EFI_PROVIDER are set correctly.

Signed-off-by: Awais Belal 
---
 meta/classes/grub-efi.bbclass   | 23 +--
 meta/classes/live-vm-common.bbclass |  2 +-
 2 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index 17417ba..c847645 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -16,8 +16,8 @@
 # ${GRUB_TIMEOUT} - timeout before executing the deault label (optional)
 # ${GRUB_ROOT} - grub's root device.

-do_bootimg[depends] += "${MLPREFIX}grub-efi:do_deploy"
-do_bootdirectdisk[depends] += "${MLPREFIX}grub-efi:do_deploy"
+do_bootimg[depends] += "${MLPREFIX}${EFI_PROVIDER}:do_deploy"
+do_bootdirectdisk[depends] += "${MLPREFIX}${EFI_PROVIDER}:do_deploy"

 GRUB_SERIAL ?= "console=ttyS0,115200"
 GRUB_CFG_VM = "${S}/grub_vm.cfg"
@@ -40,10 +40,21 @@ efi_populate() {

install -d ${DEST}${EFIDIR}

-   GRUB_IMAGE="bootia32.efi"
-   if [ "${TARGET_ARCH}" = "x86_64" ]; then
-   GRUB_IMAGE="bootx64.efi"
-   fi
+if [ "${EFI_PROVIDER}" = "grub" ]; then
+   GRUB_IMAGE="bootia32.${GRUBPLATFORM}"
+   if [ "${TARGET_ARCH}" = "x86_64" ]; then
+   GRUB_IMAGE="bootx64.${GRUBPLATFORM}"
+   elif [ "${TARGET_ARCH}" = "arm" ]; then
+grubimage = "bootarm.${GRUBPLATFORM}"
+   elif [ "${TARGET_ARCH}" = "aarch64" ]; then
+grubimage = "bootaa64.${GRUBPLATFORM}"
+fi
+else
+GRUB_IMAGE="bootia32.efi"
+   if [ "${TARGET_ARCH}" = "x86_64" ]; then
+   GRUB_IMAGE="bootx64.efi"
+fi
+fi
install -m 0644 ${DEPLOY_DIR_IMAGE}/${GRUB_IMAGE} ${DEST}${EFIDIR}
EFIPATH=$(echo "${EFIDIR}" | sed 's/\//\\/g')
printf 'fs0:%s\%s\n' "$EFIPATH" "$GRUB_IMAGE" >${DEST}/startup.nsh
diff --git a/meta/classes/live-vm-common.bbclass 
b/meta/classes/live-vm-common.bbclass
index 734697f..0af228b 100644
--- a/meta/classes/live-vm-common.bbclass
+++ b/meta/classes/live-vm-common.bbclass
@@ -13,7 +13,7 @@ def set_live_vm_vars(d, suffix):

 EFI = "${@bb.utils.contains("MACHINE_FEATURES", "efi", "1", "0", d)}"
 EFI_PROVIDER ?= "grub-efi"
-EFI_CLASS = "${@bb.utils.contains("MACHINE_FEATURES", "efi", 
"${EFI_PROVIDER}", "", d)}"
+EFI_CLASS = "${@bb.utils.contains("EFI_PROVIDER", "grub", "grub-efi", 
"${EFI_PROVIDER}", d)}"

 # Include legacy boot if MACHINE_FEATURES includes "pcbios" or if it does not
 # contain "efi". This way legacy is supported by default if neither is
--
1.9.1

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

Re: [OE-core] [PATCH v2 1/2] grub_git: extend recipe for proper target deployment

[Belal, Awais]

ping!

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Monday, January 30, 2017 6:25 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2 1/2] grub_git: extend recipe for proper target 
deployment

ping!

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Tuesday, January 10, 2017 3:14 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2 1/2] grub_git: extend recipe for proper target 
deployment

ping!

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Tuesday, January 3, 2017 5:34 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2 1/2] grub_git: extend recipe for proper target 
deployment

ping!

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Tuesday, December 27, 2016 5:15 PM
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH v2 1/2] grub_git: extend recipe for proper target 
deployment

ping!

BR,
Awais


From: openembedded-core-boun...@lists.openembedded.org 
 on behalf of Belal, Awais
Sent: Friday, December 16, 2016 5:19 PM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH v2 1/2] grub_git: extend recipe for proper target 
deployment

This extends the grub_git recipe so it can deploy grub
on the target boot disk just like grub-efi. Mainly
this copies stuff from the grub-efi recipe and then
adjusts some bits accordingly. This would allow
using the latest and greatest versions of grub
on the target.

Signed-off-by: Awais Belal 
---
 meta/recipes-bsp/grub/grub_git.bb | 60 +++
 1 file changed, 54 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-bsp/grub/grub_git.bb 
b/meta/recipes-bsp/grub/grub_git.bb
index eb824cc..13c48c7 100644
--- a/meta/recipes-bsp/grub/grub_git.bb
+++ b/meta/recipes-bsp/grub/grub_git.bb
@@ -3,11 +3,15 @@ require grub2.inc
 DEFAULT_PREFERENCE = "-1"
 DEFAULT_PREFERENCE_arm = "1"

+DEPENDS += "grub-native"
+RDEPENDS_${PN}_class-target = "diffutils freetype"
+
 FILESEXTRAPATHS =. "${FILE_DIRNAME}/grub-git:"

 PV = "2.00+${SRCPV}"
 SRCREV = "7a5b301e3adb8e054288518a325135a1883c1c6c"
 SRC_URI = "git://git.savannah.gnu.org/grub.git \
+   file://cfg \
file://0001-Disable-mfpmath-sse-as-well-when-SSE-is-disabled.patch \
file://autogen.sh-exclude-pc.patch \
file://0001-grub.d-10_linux.in-add-oe-s-kernel-name.patch \
@@ -19,29 +23,73 @@ COMPATIBLE_HOST = 
'(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
 COMPATIBLE_HOST_armv7a = 'null'
 COMPATIBLE_HOST_armv7ve = 'null'

-inherit autotools gettext texinfo
+inherit autotools gettext texinfo deploy

 # configure.ac has code to set this automagically from the target tuple
 # but the OE freeform one (core2-foo-bar-linux) don't work with that.
-
 GRUBPLATFORM_arm = "uboot"
 GRUBPLATFORM_aarch64 = "efi"
 GRUBPLATFORM ??= "pc"

+CACHED_CONFIGUREVARS += "ac_cv_path_HELP2MAN="
 EXTRA_OECONF = "--with-platform=${GRUBPLATFORM} --disable-grub-mkfont 
--program-prefix="" \
 --enable-liblzma=no --enable-device-mapper=no 
--enable-libzfs=no"
-
+EXTRA_OECONF += "${@bb.utils.contains('GRUBPLATFORM', 'efi', 
'--enable-efiemu=no', '', d)}"
 EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile', 
'--enable-largefile', '--disable-largefile', d)}"

-do_install_append () {
+# Determine the target arch for the grub modules
+python __anonymous () {
+import re
+target = d.getVar('TARGET_ARCH', True)
+platform = d.getVar('GRUBPLATFORM', True)
+if target == "x86_64":
+grubtarget = 'x86_64'
+grubimage = "bootx64." + platform
+elif re.match('i.86', target):
+grubtarget = 'i386'
+grubimage = "bootia32." + platform
+elif re.match('arm', target):
+grubtarget = 'arm'
+grubimage = "bootarm." + platform
+elif re.match('aarch64', target):
+grubtarget = 'arm64'
+grubimage = "bootaa64." + platform
+else:
+raise bb.parse.SkipPackage("grub is incompatible with target %s" % 
target)
+d.setVar("GRUB_TARGET", grubtarget)
+d.setVar("GRUB_IMAGE", grubimage)
+}
+
+do_install_class-native() {
+install -d ${D}${bindir}
+install -m 755 grub-mkimage ${D}${bindir}
+}
+
+do_install_append() {
 install -d ${D}${sysconfdir}/grub.d
 rm -rf ${D}${libdir}/charset.alias
 }

+GRUB_BUILDIN ?= "boot linux ext2 fat serial part_msdos part_gpt normal efi_gop 
iso9660 search"
+do_deploy() {
+# Search for the grub.cfg on the local boot media by using the
+# built in cfg file provided via this recipe
+grub-mkimage -c

Re: [OE-core] [PATCH] kernel.bbclass: fix some incorrect inter-task dependencies

[Ming Liu]

Hi, Bruce:

Got your meaning, will send a V2 soon.

//Ming Liu

2017-03-30 14:38 GMT+02:00 Bruce Ashfield :

>
>
> On Thu, Mar 30, 2017 at 3:58 AM,  wrote:
>
>> From: Ming Liu 
>>
>> - Move the addtask statment that kernel_link_images needs run after
>>   do_compile from linux-yocto.inc to kernel.bbclass. Or else the recipes
>>   that inheriting kernel.bbclass might run into implicit dependency
>>   issues.
>> - Fix a typo, "addtask do_strip" should be "addtask strip".
>> - Remove some redundant addtask statments, when "addtask A after B" is
>>   set, then "addtask B before A" is not needed.
>>
>
> These should be multiple commits. Whenever you find yourself listing
> changes in
> a single commit header, it should really be multiple commits. Even if the
> changes
> are small.
>
>
>>
>> Signed-off-by: Ming Liu 
>> ---
>>  meta/classes/kernel.bbclass   | 5 +++--
>>  meta/recipes-kernel/linux/linux-yocto.inc | 1 -
>>  2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 244087a..d175f1d 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -538,6 +538,7 @@ do_kernel_link_images() {
>> ln -sf ../../../vmlinuz.bin
>> fi
>>  }
>> +addtask kernel_link_images after do_compile
>>
>>  do_strip() {
>> if [ -n "${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}" ]; then
>> @@ -566,7 +567,7 @@ do_strip() {
>>  }
>>  do_strip[dirs] = "${B}"
>>
>> -addtask do_strip before do_sizecheck after do_kernel_link_images
>> +addtask strip before do_sizecheck after do_kernel_link_images
>>
>>  # Support checking the kernel size since some kernels need to reside in
>> partitions
>>  # with a fixed length or there is a limit in transferring the kernel to
>> memory
>> @@ -586,7 +587,7 @@ do_sizecheck() {
>>  }
>>  do_sizecheck[dirs] = "${B}"
>>
>> -addtask sizecheck before do_install after do_strip
>> +addtask sizecheck before do_install
>>
>
> Although possibly redundant, I don't see the problem with leaving this in
> place.
> When we have the before and after here, it is self documenting when this
> should
> run.
>
> With this removed, the reader must track down all the task dependencies
> themselves
> if they are to come to the same conclusion. Also, if that other task
> dependency changes,
> this will change.
>
> So I prefer that this stay completely defined and self documenting.
>
> Bruce
>
>
>>
>>  KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MAC
>> HINE}-${DATETIME}"
>>  # Don't include the DATETIME variable in the sstate package signatures
>> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
>> b/meta/recipes-kernel/linux/linux-yocto.inc
>> index 556546f..637506a 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto.inc
>> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
>> @@ -65,6 +65,5 @@ do_install_append(){
>>
>>  # extra tasks
>>  addtask kernel_version_sanity_check after do_kernel_metadata
>> do_kernel_checkout before do_compile
>> -addtask kernel_link_images after do_compile before do_strip
>>  addtask validate_branches before do_patch after do_kernel_checkout
>>  addtask kernel_configcheck after do_configure before do_compile
>> --
>> 2.7.4
>>
>> --
>> ___
>> 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

Re: [OE-core] [PATCH] kernel.bbclass: fix some incorrect inter-task dependencies

[Bruce Ashfield]

On Thu, Mar 30, 2017 at 3:58 AM,  wrote:

> From: Ming Liu 
>
> - Move the addtask statment that kernel_link_images needs run after
>   do_compile from linux-yocto.inc to kernel.bbclass. Or else the recipes
>   that inheriting kernel.bbclass might run into implicit dependency
>   issues.
> - Fix a typo, "addtask do_strip" should be "addtask strip".
> - Remove some redundant addtask statments, when "addtask A after B" is
>   set, then "addtask B before A" is not needed.
>

These should be multiple commits. Whenever you find yourself listing
changes in
a single commit header, it should really be multiple commits. Even if the
changes
are small.


>
> Signed-off-by: Ming Liu 
> ---
>  meta/classes/kernel.bbclass   | 5 +++--
>  meta/recipes-kernel/linux/linux-yocto.inc | 1 -
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 244087a..d175f1d 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -538,6 +538,7 @@ do_kernel_link_images() {
> ln -sf ../../../vmlinuz.bin
> fi
>  }
> +addtask kernel_link_images after do_compile
>
>  do_strip() {
> if [ -n "${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}" ]; then
> @@ -566,7 +567,7 @@ do_strip() {
>  }
>  do_strip[dirs] = "${B}"
>
> -addtask do_strip before do_sizecheck after do_kernel_link_images
> +addtask strip before do_sizecheck after do_kernel_link_images
>
>  # Support checking the kernel size since some kernels need to reside in
> partitions
>  # with a fixed length or there is a limit in transferring the kernel to
> memory
> @@ -586,7 +587,7 @@ do_sizecheck() {
>  }
>  do_sizecheck[dirs] = "${B}"
>
> -addtask sizecheck before do_install after do_strip
> +addtask sizecheck before do_install
>

Although possibly redundant, I don't see the problem with leaving this in
place.
When we have the before and after here, it is self documenting when this
should
run.

With this removed, the reader must track down all the task dependencies
themselves
if they are to come to the same conclusion. Also, if that other task
dependency changes,
this will change.

So I prefer that this stay completely defined and self documenting.

Bruce


>
>  KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${
> MACHINE}-${DATETIME}"
>  # Don't include the DATETIME variable in the sstate package signatures
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 556546f..637506a 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -65,6 +65,5 @@ do_install_append(){
>
>  # extra tasks
>  addtask kernel_version_sanity_check after do_kernel_metadata
> do_kernel_checkout before do_compile
> -addtask kernel_link_images after do_compile before do_strip
>  addtask validate_branches before do_patch after do_kernel_checkout
>  addtask kernel_configcheck after do_configure before do_compile
> --
> 2.7.4
>
> --
> ___
> 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 morty] wic: partition: Add fsck to avoid corrupt EXT file systems

[Daniel Schultz]

This patch avoids the creation of a corrupt EXT file system.

Since there are no checks if a EXT file system was successfully created,
this should add to prevent possible system failures.

Signed-off-by: Daniel Schultz 
---
 scripts/lib/wic/partition.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 3b3bd2d..152eb7b 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -239,6 +239,9 @@ class Partition():
 (self.fstype, extra_imagecmd, rootfs, label_str, rootfs_dir)
 exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
 
+mkfs_cmd = "fsck.%s -pvfD %s" % (self.fstype, rootfs)
+exec_native_cmd(mkfs_cmd, native_sysroot, pseudo=pseudo)
+
 def prepare_rootfs_btrfs(self, rootfs, oe_builddir, rootfs_dir,
  native_sysroot, pseudo):
 """
-- 
1.9.1

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

Re: [OE-core] [PATCH 1/3] update_gio_module_cache: fix host user contamination

[Patrick Ohly]

On Wed, 2017-03-29 at 23:54 +, Peter Kjellerstedt wrote:
> One thing that confuses me though is the “(Output: b'')” part in the
> warning below:
> 
>  
> 
> WARNING: core-image-base-1.0-r0 do_rootfs: The postinstall intercept
> hook 'update_gio_module_cache' failed (exit code: 1)! See log for
> details! (Output: b'')
> 
>  
> 
> What does that b'' mean?

A empty binary string - that's what Python 3 uses when it deals with raw
bytes instead of text with a known encoding.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [OE-core] [PATCH] selftest/pkgdata: support musl on unit tests

[Burton, Ross]

On 30 March 2017 at 07:39, 
wrote:

> +# recipe-runtime-package relation for virtual/libc provider
> +Libc = collections.namedtuple('Libc', ['recipe', 'runtime_pkg',
> 'libpath', 'staticdev', 'utils', 'rutils'])
> +cls.libc = Libc('glibc', 'libc6', '/lib/libc.so.6',
> 'libc6-staticdev', 'glibc-utils', 'lib6-utils')
> +if get_bb_var('TCLIBC') == 'musl':
> +cls.libc = Libc('musl', 'musl', '/usr/lib/libc.so',
> 'musl-staticdev', None, None)
>

Instead of all of this, why not just change the tests to use a different
package?  The bulk of them were just using glibc as it's going to be built,
but we've built zlib too so the tests could use that instead.

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

[OE-core] [PATCH] nasm: remove COMPATIBLE_HOST

[Ross Burton]

nasm can build on every architecture, it just can't generate anything but X86
code.  As we can't know what the user intends to do with nasm, remove the
COMPATIBLE_HOST line.

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/nasm/nasm_2.12.02.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-devtools/nasm/nasm_2.12.02.bb 
b/meta/recipes-devtools/nasm/nasm_2.12.02.bb
index 9c4b60f..3280b84 100644
--- a/meta/recipes-devtools/nasm/nasm_2.12.02.bb
+++ b/meta/recipes-devtools/nasm/nasm_2.12.02.bb
@@ -2,7 +2,6 @@ SUMMARY = "General-purpose x86 assembler"
 SECTION = "devel"
 LICENSE = "BSD-2-Clause"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=90904486f8fbf1861cf42752e1a39efe"
-COMPATIBLE_HOST = '(x86_64|i.86).*-(linux|freebsd.*)'
 
 SRC_URI = "http://www.nasm.us/pub/nasm/releasebuilds/${PV}/nasm-${PV}.tar.bz2 "
 
-- 
2.8.1

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

Re: [OE-core] [PATCH] libjpeg-turbo: fix build on aarch64 or non-intel build hosts

[Burton, Ross]

On 30 March 2017 at 09:09, Maxin B. John  wrote:
>
> Agree with Andre here. I would suggest to update nasm recipe to support
> build for other archs as well (tested on arm and it works as expected. Will
> require more testing on other archs).
>

Yes.  Simply deleting the COMPATIBLE_HOST in nasm.bb should be sufficient,
Debian builds nasm for every architecture so that demonstrates that it
builds just fine.

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

Re: [OE-core] [PATCH] update_gio_module_cache: Do not chown a non-existing file

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Alexander Kanavin
> Sent: den 30 mars 2017 11:39
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] update_gio_module_cache: Do not chown a
> non-existing file
> 
> On 03/30/2017 02:16 AM, Peter Kjellerstedt wrote:
> > Only change the ownership of ${libdir}/gio/modules/giomodule.cache if
> > it exists.
> >
> > Signed-off-by: Peter Kjellerstedt 
> > ---
> >  scripts/postinst-intercepts/update_gio_module_cache | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/scripts/postinst-intercepts/update_gio_module_cache
> b/scripts/postinst-intercepts/update_gio_module_cache
> > index 92092f2144..fc3f9d0d6c 100644
> > --- a/scripts/postinst-intercepts/update_gio_module_cache
> > +++ b/scripts/postinst-intercepts/update_gio_module_cache
> > @@ -3,7 +3,7 @@
> >  set -e
> >
> >  PSEUDO_UNLOAD=1 qemuwrapper -L $D -E
> LD_LIBRARY_PATH=$D${libdir}:$D${base_libdir} \
> > -$D${libexecdir}/${binprefix}gio-querymodules
> $D${libdir}/gio/modules/
> > -
> > -chown root:root $D${libdir}/gio/modules/giomodule.cache
> > +   $D${libexecdir}/${binprefix}gio-querymodules
> $D${libdir}/gio/modules/
> >
> > +[ ! -e $D${libdir}/gio/modules/giomodule.cache ] ||
> > +   chown root:root $D${libdir}/gio/modules/giomodule.cache
> >
> 
> Nope. The postinst-intercept scirpts are allowed to fail, and if they
> are, they are deferred to first boot. If giomodule.cache file does not
> exist, that means that qemu does not work for the target machine, which
> is not a bug, and is handled by detecting script failure and taking the
> same action at first boot time - which your change breaks.
> 
> Alex

No, the script will still fail if running gio-querymodules fails since 
`set -e` is in effect. But it will no longer fail if gio-querymodules 
succeeds without producing a cache file, which is the case for us.

I do not know under what circumstances gio-querymodules will or will 
not produce a cache file, but I have tried running it on our target 
and it does not produce a cache file there either, so I assume the 
build time job is doing the right thing in not creating a file.

//Peter

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

Re: [OE-core] [PATCH] busybox: move default config fragments to defconfig

[Richard Purdie]

On Wed, 2017-03-29 at 19:19 +0200, Peter Bergin wrote:
> Thanks for your suggestion. I think this is one step better than
> what's  in master today as it can more easily be overridden. But I
> don't think  this is a better solution to the problem than moving the
> defaults to the defconfig. Probably I have a bit different view of
> grouping the config features. I think that the grouping in .cfg
> fragments is a good design if you have features that you enable for
> example via DISTRO_FEATURE or VIRTUAL-RUNTIME_init_manager or some
> other feature option that is present in the build system. As in the
> examples with mbox.cfg and init.cfg.
> 
> I think grouping of configurations because they belong together is a 
> task for busybox's Kconfig. In the Kconfig system for busybox you can
> see the options you have and their relations. If you start a project
> and want to tune busybox the natural place to do it is in the
> defconfig file. And modifying the defconfig file with help of
> menuconfig.
> 
> What pros do you see of having standard feature .cfg files in SRC_URI
> that are (default) always added instead of having them in the
> defconfig? How does it help the developer/maintainer?

I can see cases where there is a logic group of features (such as
login-utilities) where there isn't a corresponding DISTRO_FEATURE or
VIRTUAL-RUNTIME yet we do want the developer/maintainer being able to
turn that group of things on/off, depending on the rest of their system
/distro setup.

I do agree that some of the smaller configs are a little unusual, but
even those do actually have uses since for example people have security
policies which may "ban" sha1 due to its vulnerabilities. With your
proposal they'd be forced into providing their own complete defconfig
which I don't think does anyone any favours where as today, they can
control that single thing but inherit our defaults.

I'd like to encourage more inheritance, not less. Equally, you do have
a valid problem in wanting to control things entirely and I'm trying to
give you a solution which can work for everyone.

Cheers,

Richard





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

Re: [OE-core] [PATCH] bitbake.conf: add whoami to HOSTTOOLS

[Richard Purdie]

On Thu, 2017-03-30 at 00:52 +0200, Andrea Adami wrote:
> On Thu, Mar 30, 2017 at 12:24 AM, Richard Purdie
>  wrote:
> > 
> > On Wed, 2017-03-29 at 23:09 +0200, Andreas Oberritter wrote:
> > > 
> > > On Wed, 29 Mar 2017 22:45:17 +0200
> > > Andrea Adami  wrote:
> > > 
> > > > 
> > > > 
> > > > Spotted in log do_compile of linux:
> > > > 
> > > >  /tmp/build/tmp-glibc/work-shared/c7x0/kernel-
> > > > source/scripts/mkcompile_h:
> > > >  line 46: whoami: command not found
> > > As an alternative, we could set KBUILD_BUILD_USER (and possibly
> > > KBUILD_BUILD_HOST) to a fixed or machine-based value in
> > > kernel.bbclass'
> > > EXTRA_OEMAKE variable, which could also improve the
> > > reproducibility
> > > of
> > > builds.
> > Agreed, I already suggested we should figure out how to pass in a
> > deterministic value and said I would not accept a patch to add
> > whoami
> > to HOSTTOOLS.
> > 
> > Cheers,
> > 
> > Richard
> Hello,
> 
> well, I'm all for reproducible builds.
> But there is the fact that this is the standard kernel behavior and
> we
> never limited the user choices about how to build/configure a kernel.

Just because this is the standard kernel behaviour, it doesn't mean its
"right" for us.

There are multiple issues here:

a) Builds are not deterministic
b) Builds leak "host" information about the user that built it

So we've identified an issue which I believe is something our general
userbase (who are asking for reproducibility) will want us to fix, even
if its not the upstream default kernel behaviour.

The fact there is a kconfig option for this and a way to override it
suggest even the upstream kernel people accept this is something people
will want to configure.

Cheers,

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

Re: [OE-core] [PATCH] update_gio_module_cache: Do not chown a non-existing file

[Alexander Kanavin]

On 03/30/2017 02:16 AM, Peter Kjellerstedt wrote:

Only change the ownership of ${libdir}/gio/modules/giomodule.cache if
it exists.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/postinst-intercepts/update_gio_module_cache | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/postinst-intercepts/update_gio_module_cache 
b/scripts/postinst-intercepts/update_gio_module_cache
index 92092f2144..fc3f9d0d6c 100644
--- a/scripts/postinst-intercepts/update_gio_module_cache
+++ b/scripts/postinst-intercepts/update_gio_module_cache
@@ -3,7 +3,7 @@
 set -e

 PSEUDO_UNLOAD=1 qemuwrapper -L $D -E 
LD_LIBRARY_PATH=$D${libdir}:$D${base_libdir} \
-$D${libexecdir}/${binprefix}gio-querymodules $D${libdir}/gio/modules/
-
-chown root:root $D${libdir}/gio/modules/giomodule.cache
+   $D${libexecdir}/${binprefix}gio-querymodules $D${libdir}/gio/modules/

+[ ! -e $D${libdir}/gio/modules/giomodule.cache ] ||
+   chown root:root $D${libdir}/gio/modules/giomodule.cache



Nope. The postinst-intercept scirpts are allowed to fail, and if they 
are, they are deferred to first boot. If giomodule.cache file does not 
exist, that means that qemu does not work for the target machine, which 
is not a bug, and is handled by detecting script failure and taking the 
same action at first boot time - which your change breaks.


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

[OE-core] [PATCH 1/4] bitbake.conf: Add DEPLOY_DIR to BB_HASHBASE_WHITELIST

[Richard Purdie]

Users should be able to locally choose DEPLOY_DIR without impacting
the reuse of sstate, this change allows that.

[YOCTO #0]

Signed-off-by: Richard Purdie 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d95e39d..d756af4 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -834,7 +834,7 @@ BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH 
BBPATH BBSERVER DL_DI
 PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
 CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH 
SDKPKGSUFFIX \
 WARN_QA ERROR_QA WORKDIR STAMPCLEAN PKGDATA_DIR BUILD_ARCH SSTATE_PKGARCH \
-BB_WORKERCONTEXT BB_LIMITEDDEPS extend_recipe_sysroot"
+BB_WORKERCONTEXT BB_LIMITEDDEPS extend_recipe_sysroot DEPLOY_DIR"
 BB_HASHCONFIG_WHITELIST ?= "${BB_HASHBASE_WHITELIST} DATE TIME SSH_AGENT_PID \
 SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS \
 PARALLEL_MAKE BB_NUMBER_THREADS BB_ORIGENV BB_INVALIDCONF BBINCLUDED \
-- 
2.7.4

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

[OE-core] [PATCH 4/4] bitbake.conf: Drop MULTIMACH_HOST_SYS

[Richard Purdie]

There are no users of this left after recipe specfic sysroots was implemented,
drop the variable as it no longer makes sense or is useful.

Signed-off-by: Richard Purdie 
---
 meta/conf/bitbake.conf | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d756af4..5e98d45 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -150,7 +150,6 @@ PACKAGE_ARCHS = "all any noarch ${PACKAGE_EXTRA_ARCHS} 
${MACHINE_ARCH}"
 PACKAGE_ARCHS[vardepsexclude] = "MACHINE_ARCH"
 
 MULTIMACH_TARGET_SYS = "${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}"
-MULTIMACH_HOST_SYS = "${PACKAGE_ARCH}${HOST_VENDOR}-${HOST_OS}"
 
 ##
 # Date/time variables.
-- 
2.7.4

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

[OE-core] [PATCH 2/4] sanity: Drop obsolete TMPDIR ABI conversions

[Richard Purdie]

When we get to version 12 we have a hard break as we can't convert to newer
versions. There is no point in running the old conversions on an old tmpdir
only to hit that block. Remove all the old conversions to avoid that and
make things clearer.

Signed-off-by: Richard Purdie 
---
 meta/classes/sanity.bbclass | 43 +--
 1 file changed, 1 insertion(+), 42 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index e3be40b..94c78b5 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -588,48 +588,7 @@ def sanity_handle_abichanges(status, d):
 if not abi.isdigit():
 with open(abifile, "w") as f:
 f.write(current_abi)
-elif abi == "2" and current_abi == "3":
-bb.note("Converting staging from layout version 2 to layout 
version 3")
-subprocess.call(d.expand("mv ${TMPDIR}/staging 
${TMPDIR}/sysroots"), shell=True)
-subprocess.call(d.expand("ln -s sysroots ${TMPDIR}/staging"), 
shell=True)
-subprocess.call(d.expand("cd ${TMPDIR}/stamps; for i in 
*/*do_populate_staging; do new=`echo $i | sed -e 
's/do_populate_staging/do_populate_sysroot/'`; mv $i $new; done"), shell=True)
-with open(abifile, "w") as f:
-f.write(current_abi)
-elif abi == "3" and current_abi == "4":
-bb.note("Converting staging layout from version 3 to layout 
version 4")
-if 
os.path.exists(d.expand("${STAGING_DIR_NATIVE}${bindir_native}/${MULTIMACH_HOST_SYS}")):
-subprocess.call(d.expand("mv 
${STAGING_DIR_NATIVE}${bindir_native}/${MULTIMACH_HOST_SYS} 
${STAGING_BINDIR_CROSS}"), shell=True)
-subprocess.call(d.expand("ln -s ${STAGING_BINDIR_CROSS} 
${STAGING_DIR_NATIVE}${bindir_native}/${MULTIMACH_HOST_SYS}"), shell=True)
-with open(abifile, "w") as f:
-f.write(current_abi)
-elif abi == "4":
-status.addresult("Staging layout has changed. The cross directory 
has been deprecated and cross packages are now built under the native 
sysroot.\nThis requires a rebuild.\n")
-elif abi == "5" and current_abi == "6":
-bb.note("Converting staging layout from version 5 to layout 
version 6")
-subprocess.call(d.expand("mv ${TMPDIR}/pstagelogs 
${SSTATE_MANIFESTS}"), shell=True)
-with open(abifile, "w") as f:
-f.write(current_abi)
-elif abi == "7" and current_abi == "8":
-status.addresult("Your configuration is using stamp files 
including the sstate hash but your build directory was built with stamp files 
that do not include this.\nTo continue, either rebuild or switch back to the 
OEBasic signature handler with BB_SIGNATURE_HANDLER = 'OEBasic'.\n")
-elif (abi != current_abi and current_abi == "9"):
-status.addresult("The layout of the TMPDIR STAMPS directory has 
changed. Please clean out TMPDIR and rebuild (sstate will be still be valid and 
reused)\n")
-elif (abi != current_abi and current_abi == "10" and (abi == "8" or 
abi == "9")):
-bb.note("Converting staging layout from version 8/9 to layout 
version 10")
-cmd = d.expand("grep -r -l sysroot-providers/virtual_kernel 
${SSTATE_MANIFESTS}")
-ret, result = oe.utils.getstatusoutput(cmd)
-result = result.split()
-for f in result:
-bb.note("Uninstalling manifest file %s" % f)
-sstate_clean_manifest(f, d)
-with open(abifile, "w") as f:
-f.write(current_abi)
-elif abi == "10" and current_abi == "11":
-bb.note("Converting staging layout from version 10 to layout 
version 11")
-# Files in xf86-video-modesetting moved to xserver-xorg and 
bitbake can't currently handle that:
-subprocess.call(d.expand("rm 
${TMPDIR}/sysroots/*/usr/lib/xorg/modules/drivers/modesetting_drv.so 
${TMPDIR}/sysroots/*/pkgdata/runtime/xf86-video-modesetting* 
${TMPDIR}/sysroots/*/pkgdata/runtime-reverse/xf86-video-modesetting* 
${TMPDIR}/sysroots/*/pkgdata/shlibs2/xf86-video-modesetting*"), shell=True)
-with open(abifile, "w") as f:
-f.write(current_abi)
-elif abi == "11" and current_abi == "12":
+elif int(abi) <= 11 and current_abi == "12":
 status.addresult("The layout of TMPDIR changed for Recipe Specific 
Sysroots.\nConversion doesn't make sense and this change will rebuild 
everything so please start with a clean TMPDIR.\n")
 elif (abi != current_abi):
 # Code to convert from one ABI to another could go here if 
possible.
-- 
2.7.4

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

[OE-core] [PATCH 3/4] ccache: Use MULTIMACH_TARGET_SYS not HOST_SYS

[Richard Purdie]

I suspect this was a typo and that TARGET_SYS makes more sense here. Its
also the only remaining user of MULTIMACH_HOST_SYS in OE-Core. Change it.

Signed-off-by: Richard Purdie 
---
 meta/classes/ccache.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/ccache.bbclass b/meta/classes/ccache.bbclass
index 9713fea..d58c8f6 100644
--- a/meta/classes/ccache.bbclass
+++ b/meta/classes/ccache.bbclass
@@ -1,5 +1,5 @@
 CCACHE = "${@bb.utils.which(d.getVar('PATH'), 'ccache') and 'ccache '}"
-export CCACHE_DIR ?= "${TMPDIR}/ccache/${MULTIMACH_HOST_SYS}/${PN}"
+export CCACHE_DIR ?= "${TMPDIR}/ccache/${MULTIMACH_TARGET_SYS}/${PN}"
 CCACHE_DISABLE[unexport] = "1"
 
 # We need to stop ccache considering the current directory or the
-- 
2.7.4

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

Re: [OE-core] [PATCH] update_gio_module_cache: Do not chown a non-existing file

[Alexander Kanavin]

On 03/30/2017 12:31 PM, Richard Purdie wrote:

Only change the ownership of ${libdir}/gio/modules/giomodule.cache
if
it exists.

Why do we need to change the owndership in the first place?


The qemu call in the line above is made under PSEUDO_UNLOAD, see the
original patch from Chris.


With this change, if the qemu call fails (which it is allowed to), will 
the entire script fail, and be deferred to first boot as it should?


Alex

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

Re: [OE-core] [PATCH] update_gio_module_cache: Do not chown a non-existing file

[Richard Purdie]

On Thu, 2017-03-30 at 12:29 +0300, Alexander Kanavin wrote:
> On 03/30/2017 02:16 AM, Peter Kjellerstedt wrote:
> > 
> > Only change the ownership of ${libdir}/gio/modules/giomodule.cache
> > if
> > it exists.
> Why do we need to change the owndership in the first place?

The qemu call in the line above is made under PSEUDO_UNLOAD, see the
original patch from Chris.

Cheers,

Richard

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

Re: [OE-core] [PATCH] update_gio_module_cache: Do not chown a non-existing file

[Alexander Kanavin]

On 03/30/2017 02:16 AM, Peter Kjellerstedt wrote:

Only change the ownership of ${libdir}/gio/modules/giomodule.cache if
it exists.


Why do we need to change the owndership in the first place?

Alex

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

Re: [OE-core] [PATCH 1/3] update_gio_module_cache: fix host user contamination

[Alexander Kanavin]

On 03/28/2017 07:14 PM, Christopher Larson wrote:

update_gio_module_cache intercept creates file:
$D${libdir}/gio/modules/giomodule.cache

Change ownership of this file to root:root to avoid user contamination
by host.


I don't understand how one is related to another, can you explain 
please? What is happening, and why chown is fixing the problem?



Alex

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

Re: [OE-core] [PATCH 1/1] wic: improve error message

[ChenQi]

On 03/30/2017 04:54 PM, Gary Thomas wrote:

On 2017-03-30 10:37, Chen Qi wrote:

When using `wic create mkefidisk -e core-image-minimal', the following
error message appeared.

  Please bake it with 'bitbake parted-native' and try again.

However, following this command doesn't do any help. The same problem
still appeared.

The problem is that when we 'bitbake parted-native', it doesn't have
anything to do with core-image-minimal. And the required tool 'parted'
is not under core-image-minimal's recipe-sysroot-native directory.

Improve the error message so that following it could get things done.


Why not just fix the wic-tools recipe directly and not push it off 
onto the user?




wic-tools does have 'parted-native' in its DEPENDS.
I met this error when I used wic command before I executed `bitbake 
wic-tools'.


What's important here is, when an error message suggests the user to do 
something, the suggestion should at least have some chance to work. But 
following the current error message has no chance to fix things.


Best Regards,
Chen Qi



Signed-off-by: Chen Qi 
---
 scripts/lib/wic/utils/misc.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/utils/misc.py 
b/scripts/lib/wic/utils/misc.py

index c941112..1b0ab3b 100644
--- a/scripts/lib/wic/utils/misc.py
+++ b/scripts/lib/wic/utils/misc.py
@@ -131,7 +131,7 @@ def exec_native_cmd(cmd_and_args, native_sysroot, 
catch=3, pseudo=""):

   "was not found (see details above).\n\n" % prog
 recipe = NATIVE_RECIPES.get(prog)
 if recipe:
-msg += "Please bake it with 'bitbake %s-native' "\
+msg += "Please make sure wic-tools have %s-native in its 
DEPENDS, bake it with 'bitbake wic-tools' "\

"and try again.\n" % recipe
 else:
 msg += "Wic failed to find a recipe to build native %s. 
Please "\







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

Re: [OE-core] [PATCH] quilt: Fix paths for patch and perl

[Richard Purdie]

On Wed, 2017-03-29 at 17:44 +0300, Jussi Kukkonen wrote:
> --with-perl value is used as part of shebang lines: the previous
> do_install_append hack did not work as it was often used as
> #! /usr/bin/env perl -w
> Env does not support arguments, set --with-perl instead. Native
> recipe already overrides this so should not break.
> 
> --with-patch is used within the gnu patch wrapper only: before this
> commit the wrapper contained a path to (build host) native patch.
> 
> Also tweak one test so busybox mv output is accepted.
> 
> All ptests should now pass: Fixes [YOCTO #11221].
> 
> Signed-off-by: Jussi Kukkonen 
> ---
>  meta/recipes-devtools/quilt/quilt.inc  |  3 ++-
>  ...0001-tests-Allow-different-output-from-mv.patch | 29
> ++
>  meta/recipes-devtools/quilt/quilt_0.65.bb  | 10 
>  3 files changed, 31 insertions(+), 11 deletions(-)
>  create mode 100644 meta/recipes-devtools/quilt/quilt/0001-tests-
> Allow-different-output-from-mv.patch
> 
> diff --git a/meta/recipes-devtools/quilt/quilt.inc b/meta/recipes-
> devtools/quilt/quilt.inc
> index 57e2a14..e6a63ce 100644
> --- a/meta/recipes-devtools/quilt/quilt.inc
> +++ b/meta/recipes-devtools/quilt/quilt.inc
> @@ -8,6 +8,7 @@ SRC_URI = "${SAVANNAH_GNU_MIRROR}/quilt/quilt-
> ${PV}.tar.gz \
>  file://run-ptest \
>  file://Makefile \
>  file://test.sh \
> +file://0001-tests-Allow-different-output-from-mv.patch \
>  "
>  
>  SRC_URI[md5sum] = "c67ba0228f5b7b8bbe469474661f92d6"
> @@ -33,7 +34,7 @@ RDEPENDS_${PN} = "bash"
>  EXTRA_OE_MAKE_ARGS_darwin ?= ""
>  EXTRA_OE_MAKE_ARGS ?= "BUILD_ROOT=${D}"
>  
> -EXTRA_OECONF = "--with-perl=perl"
> +EXTRA_OECONF = "--with-perl=${bindir}/perl --with-patch=patch"

Unfortunately I think this would break nativesdk-quilt since we'd no
longer be using env and hence would require the buildtools tarball and
sdks contained perl?

Cheers,

Richard


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

Re: [OE-core] [PATCH 1/3] update_gio_module_cache: fix host user contamination

[Richard Purdie]

On Wed, 2017-03-29 at 23:54 +, Peter Kjellerstedt wrote:
> I have sent a patch to fix this. The interesting part from the log
> was:
>  
> chown: cannot access
> `${WORKDIR}/rootfs/usr/lib/gio/modules/giomodule.cache': No such file
> or directory

Does this fix this or workaround the issue? I think the bigger worry is
why the cache file doesn't exist when the previous command should have
created it?

Cheers,

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

Re: [OE-core] [PATCH 1/3] update_gio_module_cache: fix host user contamination

[Jussi Kukkonen]

On 30 March 2017 at 00:08, Andrea Adami  wrote:

> On Wed, Mar 29, 2017 at 10:40 PM, Christopher Larson 
> wrote:
> >
> > On Wed, Mar 29, 2017 at 1:33 PM, Andrea Adami 
> > wrote:
> >>
> >> On Tue, Mar 28, 2017 at 6:14 PM, Christopher Larson 
> >> wrote:
> >> > From: Abdur Rehman 
> >> >
> >> > update_gio_module_cache intercept creates file:
> >> > $D${libdir}/gio/modules/giomodule.cache
> >> >
> >> > Change ownership of this file to root:root to avoid user contamination
> >> > by host.
> >> >
> >> > Signed-off-by: Abdur Rehman 
> >> > Signed-off-by: Christopher Larson 
> >> > ---
> >> >  scripts/postinst-intercepts/update_gio_module_cache | 2 ++
> >> >  1 file changed, 2 insertions(+)
> >> >
> >> > diff --git a/scripts/postinst-intercepts/update_gio_module_cache
> >> > b/scripts/postinst-intercepts/update_gio_module_cache
> >> > index fe468092cf..92092f2144 100644
> >> > --- a/scripts/postinst-intercepts/update_gio_module_cache
> >> > +++ b/scripts/postinst-intercepts/update_gio_module_cache
> >> > @@ -5,3 +5,5 @@ set -e
> >> >  PSEUDO_UNLOAD=1 qemuwrapper -L $D -E
> >> > LD_LIBRARY_PATH=$D${libdir}:$D${base_libdir} \
> >> >  $D${libexecdir}/${binprefix}gio-querymodules
> >> > $D${libdir}/gio/modules/
> >> >
> >> > +chown root:root $D${libdir}/gio/modules/giomodule.cache
> >> > +
> >> > --
> >> > 2.11.1
> >> >
> >> > --
> >> > ___
> >> > Openembedded-core mailing list
> >> > Openembedded-core@lists.openembedded.org
> >> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>
> >>
> >> Hello,
> >> There must be something wrong with this patch.
> >> After fresh pull of an hour ago I git:
> >>
> >> andrea@ThinkPad-T520:/oe/oe-core/build$ bitbake core-image-base
> >> Loading cache: 100% ||
> Time:
> >> 0:00:00
> >> Loaded 2095 entries from dependency cache.
> >> NOTE: Resolving any missing task queue dependencies
> >>
> >> Build Configuration:
> >> BB_VERSION= "1.33.2"
> >> BUILD_SYS = "x86_64-linux"
> >> NATIVELSBSTRING   = "ubuntu-16.04"
> >> TARGET_SYS= "arm-oe-linux-gnueabi"
> >> MACHINE   = "c7x0"
> >> DISTRO= "nodistro"
> >> DISTRO_VERSION= "nodistro.0"
> >> TUNE_FEATURES = "arm armv5 thumb dsp"
> >> TARGET_FPU= "soft"
> >> meta  = "master:c187326afcf1e9d781c1bd0923e1362a6f50f613"
> >> meta-handheld = "master:f88f5bc546ec18de232a91dc1c8185ad242c45f7"
> >> meta-oe
> >> meta-initramfs= "master:225e64d95bc41077782815f3dceb6f2d1a42b167"
> >>
> >> Initialising tasks: 100% |###|
> Time:
> >> 0:00:08
> >> NOTE: Executing SetScene Tasks
> >> NOTE: Executing RunQueue Tasks
> >> WARNING: core-image-base-1.0-r0 do_rootfs: The postinstall intercept
> >> hook 'update_gio_module_cache' failed (exit code: 1)! See log for
> >> details! (Output: b'')
> >> WARNING: core-image-base-1.0-r0 do_rootfs: The postinstalls for the
> >> following packages will be postponed for first boot: libglib-2.0-0
> >> NOTE: Tasks Summary: Attempted 3440 tasks of which 3427 didn't need to
> >> be rerun and all succeeded.
> >
> >
> > Odd, we’ve been running with this applied for ages. Is there anything
> useful
> > in do_rootfs? I’ll attempt to repro here. Thanks, and sorry for the
> hassle.
> > --
>
> There is just a laconical message:
>
> NOTE: Running intercept scripts:
> NOTE: > Executing update_gio_module_cache intercept ...
> chown: cannot access
> '/tmp/build/tmp-glibc/work/c7x0-oe-linux-gnueabi/core-
> image-base/1.0-r0/rootfs/usr/lib/gio/modules/giomodule.cache':
> No such file or directory
>
> Here the permissions:
> andrea@ThinkPad-T520:/tmp/build/tmp-glibc/work/c7x0-oe-
> linux-gnueabi/core-image-base/1.0-r0/rootfs/usr/lib/gio$
> ls -al
> total 0
> drwxr-xr-x 3 andrea andrea   60 mar 29 21:33 .
> drwxr-xr-x 6 andrea andrea 1660 mar 29 22:51 ..
> drwxr-xr-x 2 andrea andrea   40 mar 29 21:33 modules
>

Can you check if usr/lib/gio/modules/giomodule.cache really exists or not?
And if it does not, what the gio-querymodules call looks like in
temp/run.do_rootfs?

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

Re: [OE-core] [PATCH 1/1] wic: improve error message

[Gary Thomas]

On 2017-03-30 10:37, Chen Qi wrote:

When using `wic create mkefidisk -e core-image-minimal', the following
error message appeared.

  Please bake it with 'bitbake parted-native' and try again.

However, following this command doesn't do any help. The same problem
still appeared.

The problem is that when we 'bitbake parted-native', it doesn't have
anything to do with core-image-minimal. And the required tool 'parted'
is not under core-image-minimal's recipe-sysroot-native directory.

Improve the error message so that following it could get things done.


Why not just fix the wic-tools recipe directly and not push it off onto the 
user?



Signed-off-by: Chen Qi 
---
 scripts/lib/wic/utils/misc.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/utils/misc.py b/scripts/lib/wic/utils/misc.py
index c941112..1b0ab3b 100644
--- a/scripts/lib/wic/utils/misc.py
+++ b/scripts/lib/wic/utils/misc.py
@@ -131,7 +131,7 @@ def exec_native_cmd(cmd_and_args, native_sysroot, catch=3, 
pseudo=""):
   "was not found (see details above).\n\n" % prog
 recipe = NATIVE_RECIPES.get(prog)
 if recipe:
-msg += "Please bake it with 'bitbake %s-native' "\
+msg += "Please make sure wic-tools have %s-native in its DEPENDS, bake 
it with 'bitbake wic-tools' "\
"and try again.\n" % recipe
 else:
 msg += "Wic failed to find a recipe to build native %s. Please "\




--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] [PATCH] meta: define REAL_MULTIMACH_TARGET_SYS/SDKTARGETSYSROOT in bitbake.conf

[Richard Purdie]

On Thu, 2017-03-30 at 09:57 +0200, liu.min...@gmail.com wrote:
> From: Ming Liu 
> 
> REAL_MULTIMACH_TARGET_SYS is being defined and referred in several
> recipes, which is redundant and not easy to be overriden, and
> SDKTARGETSYSROOT is also defined in two recipes.
> 
> So move their definitions to bitbake.conf.
> 
> Signed-off-by: Ming Liu 
> ---
>  meta/classes/populate_sdk_base.bbclass | 6 --
>  meta/classes/toolchain-scripts.bbclass | 3 ---
>  meta/conf/bitbake.conf | 2 ++
>  meta/recipes-core/meta/meta-environment.bb | 3 ---
>  4 files changed, 2 insertions(+), 12 deletions(-)

To be honest, REAL_MULTIMACH_TARGET_SYS is a hack and I'd prefer to
find ways to remove the need for it (and perhaps the other MULTIMACH*
variables). I'd therefore prefer not to move this to bitbake.conf which
would give the impression its something we want to encourage (we
don't).

Cheers,

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

[OE-core] [PATCH 1/1] wic: improve error message

[Chen Qi]

When using `wic create mkefidisk -e core-image-minimal', the following
error message appeared.

  Please bake it with 'bitbake parted-native' and try again.

However, following this command doesn't do any help. The same problem
still appeared.

The problem is that when we 'bitbake parted-native', it doesn't have
anything to do with core-image-minimal. And the required tool 'parted'
is not under core-image-minimal's recipe-sysroot-native directory.

Improve the error message so that following it could get things done.

Signed-off-by: Chen Qi 
---
 scripts/lib/wic/utils/misc.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/utils/misc.py b/scripts/lib/wic/utils/misc.py
index c941112..1b0ab3b 100644
--- a/scripts/lib/wic/utils/misc.py
+++ b/scripts/lib/wic/utils/misc.py
@@ -131,7 +131,7 @@ def exec_native_cmd(cmd_and_args, native_sysroot, catch=3, 
pseudo=""):
   "was not found (see details above).\n\n" % prog
 recipe = NATIVE_RECIPES.get(prog)
 if recipe:
-msg += "Please bake it with 'bitbake %s-native' "\
+msg += "Please make sure wic-tools have %s-native in its DEPENDS, 
bake it with 'bitbake wic-tools' "\
"and try again.\n" % recipe
 else:
 msg += "Wic failed to find a recipe to build native %s. Please "\
-- 
1.9.1

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

[OE-core] [PATCH 0/1] wic: improve error message

[Chen Qi]

The following changes since commit 2acc741dd02cd796b396484a8676250a8f97c975:

  maintainers.inc: Add maintainers to go-native and vulkan software package 
recipes (2017-03-29 16:37:28 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib ChenQi/wic-error-msg
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/wic-error-msg

Chen Qi (1):
  wic: improve error message

 scripts/lib/wic/utils/misc.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
1.9.1

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

Re: [OE-core] [PATCH v2] util-linux: make blkdiscard a separate package

[Jussi Kukkonen]

On 29 March 2017 at 20:42, Stefan Agner  wrote:

> On 2017-03-29 08:41, Burton, Ross wrote:
>
>
> On 28 March 2017 at 23:45, Stefan Agner  wrote:
>
>> @@ -30,8 +30,8 @@ PACKAGES =+ "util-linux-agetty util-linux-fdisk
>> util-linux-cfdisk util-linux-sfd
>>   util-linux-swaponoff util-linux-losetup util-linux-umount \
>>   util-linux-mount util-linux-readprofile util-linux-uuidd \
>>   util-linux-uuidgen util-linux-lscpu util-linux-fsck.cramfs
>> util-linux-fsck \
>> - util-linux-blkid util-linux-mkfs util-linux-mcookie
>> util-linux-reset \
>> - util-linux-lsblk util-linux-mkfs.cramfs util-linux-fstrim \
>> + util-linux-blkdiscard util-linux-blkid util-linux-mkfs
>> util-linux-mcookie \
>> + util-linux-reset util-linux-lsblk util-linux-mkfs.cramfs
>> util-linux-fstrim \
>>   util-linux-partx util-linux-hwclock util-linux-mountpoint \
>>   util-linux-findfs util-linux-getopt util-linux-sulogin
>> util-linux-prlimit"
>>
>
> We're growing a lot of packages containing a single binary.  Would it be
> sensible to group them into "file system tools", "process tools", etc?
>
> Not sure if such a high level grouping is helpful. Just because an
> image uses one fs utility, does not mean the others are used too. There
> might be some potential on a lower level (e.g. util-linux-mkfs.cramfs and
> util-linux-fsck.cramfs).
>
> Is having lots of single binary packages an issue? I guess package
> management data adds some space overhead? In my case, I build a image
> without package metadata, so I guess there is no overhead for the final
> image (for the final image).
>

I have no hard data on this but we are struggling with oe-selftests taking
too long (we're talking 4-10 hour runs and personally I think we should be
running many more tests than we currently do).

The time it takes to boot an image and run the test won't be affected by
this patch, but I'm guessing it does increase the packaging and rootfs
generation time by a little bit. Multiply that by the number of images we
build and add it to all the other "little bits" of time...

Would be nice to have some hard data on this though -- I don't really know
if this is the place to optimize.

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

Re: [OE-core] [PATCH] u-boot: Update to 2017.03 release

[Marek Vasut]

On 03/29/2017 11:56 PM, Denys Dmytriyenko wrote:
> On Mon, Mar 27, 2017 at 04:31:16PM +0200, Marek Vasut wrote:
>> On 03/27/2017 04:25 PM, Richard Purdie wrote:
>>> On Mon, 2017-03-27 at 16:22 +0200, Marek Vasut wrote:
 Upgrade U-Boot to the latest version.
>>>
>>> Wrong list and how does this compare to Ovatio's patch?
>>
>> I was not CCed on Otavio's patch :(
> 
> Yeah, me neither, unfortunately - people just ignore maintainers file now.
> 
> Good thing Ross copied me on the other discussion!
> 
Which other discussion ? :-(

-- 
Best regards,
Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core