Re: [OE-core] [warrior][PATCH 7/8] devtool: finish: Add suppport for the --no-clean option

2019-10-17 Thread Peter Kjellerstedt
> -Original Message-
> From: akuster808 
> Sent: den 16 oktober 2019 22:25
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [warrior][PATCH 7/8] devtool: finish: Add
> suppport for the --no-clean option
> 
> On 10/16/19 9:30 AM, Peter Kjellerstedt wrote:
> > From: Peter Kjellerstedt 
> >
> > This works just like the already existing --no-clean option to the
> > `devtool reset` command.
> what problem is this solving in warrior?
> -a rmin

Keeping the development tools in sync with master so one can use the 
same options when working regardless of if one is working with Warrior 
or Zeus. Since it does not affect what is built and goes into the rootfs, 
it should not be a problem that it technically is a new feature.

//Peter

> >
> > Signed-off-by: Peter Kjellerstedt 
> > Signed-off-by: Richard Purdie 
> > ---
> >  scripts/lib/devtool/standard.py | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/lib/devtool/standard.py
> b/scripts/lib/devtool/standard.py
> > index b944ec3966..aeb9452a8a 100644
> > --- a/scripts/lib/devtool/standard.py
> > +++ b/scripts/lib/devtool/standard.py
> > @@ -1895,7 +1895,7 @@ def finish(args, config, basepath, workspace):
> >  else:
> >  raise DevtoolError('Source tree is not
> clean:\n\n%s\nEnsure you have committed your changes or use -f/--force
> if you are sure there\'s nothing that needs to be committed' % dirty)
> >
> > -no_clean = False
> > +no_clean = args.no_clean
> >  tinfoil = setup_tinfoil(basepath=basepath, tracking=True)
> >  try:
> >  rd = parse_recipe(config, tinfoil, args.recipename, True)
> > @@ -2169,6 +2169,7 @@ def register_commands(subparsers, context):
> >  parser_finish.add_argument('--mode', '-m', choices=['patch',
> 'srcrev', 'auto'], default='auto', help='Update mode (where %(metavar)s
> is %(choices)s; default is %(default)s)', metavar='MODE')
> >  parser_finish.add_argument('--initial-rev', help='Override
> starting revision for patches')
> >  parser_finish.add_argument('--force', '-f', action="store_true",
> help='Force continuing even if there are uncommitted changes in the
> source tree repository')
> > +parser_finish.add_argument('--no-clean', '-n',
> action="store_true", help='Don\'t clean the sysroot to remove recipe
> output')
> >  parser_finish.add_argument('--no-overrides', '-O',
> action="store_true", help='Do not handle other override branches (if
> they exist)')
> >  parser_finish.add_argument('--dry-run', '-N',
> action="store_true", help='Dry-run (just report changes instead of
> writing them)')
> >  parser_finish.add_argument('--force-patch-refresh',
> action="store_true", help='Update patches in the layer even if they
> have not been modified (useful for refreshing patch context)')

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


[OE-core] [warrior][PATCH 6/8] devtool: finish: Keep patches ordered when updating bbappend

2019-10-16 Thread Peter Kjellerstedt
From: Niclas Svensson 

The _get_patchset_revs() function returns the patches in an
OrderedDict to keep them ordered. However, this information was lost
when the patches were added to the bbappend file.

Signed-off-by: Niclas Svensson 
Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---
 scripts/lib/devtool/standard.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index dcb6bf9540..b944ec3966 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -1520,17 +1520,17 @@ def _update_recipe_patch(recipename, workspace, 
srctree, rd, appendlayerdir, wil
   patches_dir, changed_revs)
 logger.debug('Pre-filtering: update: %s, new: %s' % (dict(upd_p), 
dict(new_p)))
 if filter_patches:
-new_p = {}
-upd_p = {k:v for k,v in upd_p.items() if k in filter_patches}
+new_p = OrderedDict()
+upd_p = OrderedDict((k,v) for k,v in upd_p.items() if k in 
filter_patches)
 remove_files = [f for f in remove_files if f in filter_patches]
 updatefiles = False
 updaterecipe = False
 destpath = None
 srcuri = (rd.getVar('SRC_URI', False) or '').split()
 if appendlayerdir:
-files = dict((os.path.join(local_files_dir, key), val) for
+files = OrderedDict((os.path.join(local_files_dir, key), val) for
  key, val in list(upd_f.items()) + list(new_f.items()))
-files.update(dict((os.path.join(patches_dir, key), val) for
+files.update(OrderedDict((os.path.join(patches_dir, key), val) for
   key, val in list(upd_p.items()) + 
list(new_p.items(
 if files or remove_files:
 removevalues = None
-- 
2.21.0

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


[OE-core] [warrior][PATCH 3/8] devtool: Avoid failure for recipes with S == WORKDIR and no local files

2019-10-16 Thread Peter Kjellerstedt
From: Peter Kjellerstedt 

When extracting the sources for a recipe that has S == WORKDIR and no
local files in the SRC_URI (which, e.g., can happen for a recipe with
a URI that has the unpack=false attribute), the extraction fails with
the following backtrace:

  Traceback (most recent call last):
File ".../scripts/devtool", line 344, in 
  ret = main()
File ".../scripts/devtool", line 331, in main
  ret = args.func(args, config, basepath, workspace)
File ".../poky/scripts/lib/devtool/standard.py", line 762, in
modify
  initial_rev, _ = _extract_source(srctree, args.keep_temp,
  args.branch, False, config, basepath, workspace,
  args.fixed_setup, rd, tinfoil, no_overrides=args.no_overrides)
File ".../poky/scripts/lib/devtool/standard.py", line 647, in
_extract_source
  bb.process.run('git %s commit -a -m "Committing local file
  symlinks\n\n%s"' % (' '.join(useroptions),
  oe.patch.GitApplyTree.ignore_commit_prefix), cwd=srctree)
File ".../poky/bitbake/lib/bb/process.py", line 178, in run
  raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
  bb.process.ExecutionError: Execution of 'git commit -a -m
  "Committing local file symlinks

  %% ignore"' failed with exit code 1:
  On branch devtool
  nothing to commit, working tree clean

This is because no files were found in the oe-local-files directory
and consequently no symbolic links were added using `git add`, but the
`git commit` command was still executed.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---
 scripts/lib/devtool/standard.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index aca74b1fc6..dcb6bf9540 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -637,9 +637,9 @@ def _extract_source(srctree, keep_temp, devbranch, sync, 
config, basepath, works
 addfiles.append(os.path.join(relpth, fn))
 if addfiles:
 bb.process.run('git add %s' % ' '.join(addfiles), 
cwd=srctree)
-useroptions = []
-oe.patch.GitApplyTree.gitCommandUserOptions(useroptions, d=d)
-bb.process.run('git %s commit -a -m "Committing local file 
symlinks\n\n%s"' % (' '.join(useroptions), 
oe.patch.GitApplyTree.ignore_commit_prefix), cwd=srctree)
+useroptions = []
+oe.patch.GitApplyTree.gitCommandUserOptions(useroptions, 
d=d)
+bb.process.run('git %s commit -m "Committing local file 
symlinks\n\n%s"' % (' '.join(useroptions), 
oe.patch.GitApplyTree.ignore_commit_prefix), cwd=srctree)
 
 if is_kernel_yocto:
 logger.info('Copying kernel config to srctree')
-- 
2.21.0

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


[OE-core] [warrior][PATCH 8/8] lib/oe/lsb: Make sure the distro ID is always lowercased

2019-10-16 Thread Peter Kjellerstedt
From: Peter Kjellerstedt 

In commit 8689e561 (lib/oe/lsb: attempt to ensure consistent distro id
regardless of source), the distro ID returned by
oe.lsb.distro_identifier() was lowercased, but only if a release
version is also present.

This changes the code to always lowercase the distro ID, including the
default distro ID "unknown", which is used if no other ID can be
identified.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---
 meta/lib/oe/lsb.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/lsb.py b/meta/lib/oe/lsb.py
index 4f2b419edc..43e46380d7 100644
--- a/meta/lib/oe/lsb.py
+++ b/meta/lib/oe/lsb.py
@@ -110,12 +110,12 @@ def distro_identifier(adjust_hook=None):
 if adjust_hook:
 distro_id, release = adjust_hook(distro_id, release)
 if not distro_id:
-return "Unknown"
-# Filter out any non-alphanumerics
-distro_id = re.sub(r'\W', '', distro_id)
+return "unknown"
+# Filter out any non-alphanumerics and convert to lowercase
+distro_id = re.sub(r'\W', '', distro_id).lower()
 
 if release:
-id_str = '{0}-{1}'.format(distro_id.lower(), release)
+id_str = '{0}-{1}'.format(distro_id, release)
 else:
 id_str = distro_id
 return id_str.replace(' ','-').replace('/','-')
-- 
2.21.0

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


[OE-core] [warrior][PATCH 7/8] devtool: finish: Add suppport for the --no-clean option

2019-10-16 Thread Peter Kjellerstedt
From: Peter Kjellerstedt 

This works just like the already existing --no-clean option to the
`devtool reset` command.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---
 scripts/lib/devtool/standard.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index b944ec3966..aeb9452a8a 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -1895,7 +1895,7 @@ def finish(args, config, basepath, workspace):
 else:
 raise DevtoolError('Source tree is not clean:\n\n%s\nEnsure you 
have committed your changes or use -f/--force if you are sure there\'s nothing 
that needs to be committed' % dirty)
 
-no_clean = False
+no_clean = args.no_clean
 tinfoil = setup_tinfoil(basepath=basepath, tracking=True)
 try:
 rd = parse_recipe(config, tinfoil, args.recipename, True)
@@ -2169,6 +2169,7 @@ def register_commands(subparsers, context):
 parser_finish.add_argument('--mode', '-m', choices=['patch', 'srcrev', 
'auto'], default='auto', help='Update mode (where %(metavar)s is %(choices)s; 
default is %(default)s)', metavar='MODE')
 parser_finish.add_argument('--initial-rev', help='Override starting 
revision for patches')
 parser_finish.add_argument('--force', '-f', action="store_true", 
help='Force continuing even if there are uncommitted changes in the source tree 
repository')
+parser_finish.add_argument('--no-clean', '-n', action="store_true", 
help='Don\'t clean the sysroot to remove recipe output')
 parser_finish.add_argument('--no-overrides', '-O', action="store_true", 
help='Do not handle other override branches (if they exist)')
 parser_finish.add_argument('--dry-run', '-N', action="store_true", 
help='Dry-run (just report changes instead of writing them)')
 parser_finish.add_argument('--force-patch-refresh', action="store_true", 
help='Update patches in the layer even if they have not been modified (useful 
for refreshing patch context)')
-- 
2.21.0

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


[OE-core] [warrior][PATCH 5/8] tzdata: Correct the packaging of /etc/localtime and /etc/timezone

2019-10-16 Thread Peter Kjellerstedt
From: Peter Kjellerstedt 

During restructuring of the packaging in 2af4d6eb (tzdata: Install
everything by default), these two files remained in the tzdata
package, which is supposed to be empty. Move them to tzdata-core where
they belong.

Also simplify the definition of CONFFILES_tzdata-core. As its value
only takes effect for files that actually exist, there is no need to
complicate its definition by checking if a file is created before
adding it to the list of configuration files.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---
 meta/recipes-extended/timezone/tzdata.bb | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/timezone/tzdata.bb 
b/meta/recipes-extended/timezone/tzdata.bb
index 82fe369baa..1e2d9bd1b9 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -147,6 +147,8 @@ FILES_tzdata-misc += "${datadir}/zoneinfo/Cuba   \
 RPROVIDES_tzdata-misc = "tzdata-misc"
 
 FILES_tzdata-core += " \
+${sysconfdir}/localtime  \
+${sysconfdir}/timezone   \
 ${datadir}/zoneinfo/Pacific/Honolulu \
 ${datadir}/zoneinfo/America/Anchorage\
 ${datadir}/zoneinfo/America/Los_Angeles  \
@@ -202,8 +204,7 @@ FILES_tzdata-core += " \
 ${datadir}/zoneinfo/iso3166.tab  \
 ${datadir}/zoneinfo/Etc/*"
 
-CONFFILES_tzdata-core += "${@ "${sysconfdir}/timezone" if 
bb.utils.to_boolean(d.getVar('INSTALL_TIMEZONE_FILE')) else "" }"
-CONFFILES_tzdata-core += "${sysconfdir}/localtime"
+CONFFILES_tzdata-core = "${sysconfdir}/localtime ${sysconfdir}/timezone"
 
 ALLOW_EMPTY_${PN} = "1"
 RDEPENDS_${PN} = "${TZ_PACKAGES}"
-- 
2.21.0

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


[OE-core] [warrior][PATCH 4/8] package_rpm.bbclass: Remove a misleading bb.note()

2019-10-16 Thread Peter Kjellerstedt
From: Peter Kjellerstedt 

It should have been removed in 3db9d865 (classes/package_rpm.bbclass:
Enhance diagnostic messages) when it was split in two new notes.

Also change the casing of two other notes to align them with the other
notes.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---
 meta/classes/package_rpm.bbclass | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 1a64cb271a..b1b13e2a5a 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -409,7 +409,6 @@ python write_specfile () {
 if not file_list and localdata.getVar('ALLOW_EMPTY', False) != "1":
 bb.note("Not creating empty RPM package for %s" % splitname)
 else:
-bb.note("Creating RPM package for %s" % splitname)
 spec_files_top.append('%files')
 if extra_pkgdata:
 package_rpm_extra_pkgdata(splitname, spec_files_top, 
localdata)
@@ -418,7 +417,7 @@ python write_specfile () {
 bb.note("Creating RPM package for %s" % splitname)
 spec_files_top.extend(file_list)
 else:
-bb.note("Creating EMPTY RPM Package for %s" % splitname)
+bb.note("Creating empty RPM package for %s" % splitname)
 spec_files_top.append('')
 continue
 
@@ -510,7 +509,7 @@ python write_specfile () {
 bb.note("Creating RPM package for %s" % splitname)
 spec_files_bottom.extend(file_list)
 else:
-bb.note("Creating EMPTY RPM Package for %s" % splitname)
+bb.note("Creating empty RPM package for %s" % splitname)
 spec_files_bottom.append('')
 
 del localdata
-- 
2.21.0

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


[OE-core] [warrior][PATCH 0/8] Backport relevant changes from Zeus

2019-10-16 Thread Peter Kjellerstedt
This patch set contains backports of our changes from Zeus that are
relevant for Warrior.

//Peter

The following changes since commit 79a850a10a4b88a6d20d607b322542f947874323:

  conf/poky: add Fedora 30 and Opensuse Leap 15.1 to supported distributions 
(2019-10-14 09:49:27 +0100)

are available in the Git repository at:

  git://push.yoctoproject.org/poky-contrib pkj/warrior_sync

Niclas Svensson (1):
  devtool: finish: Keep patches ordered when updating bbappend

Peter Kjellerstedt (7):
  meson.bbclass: Remove the MESON_*_ARGS variables
  nativesdk-meson: Remove some unused variables
  devtool: Avoid failure for recipes with S == WORKDIR and no local
files
  package_rpm.bbclass: Remove a misleading bb.note()
  tzdata: Correct the packaging of /etc/localtime and /etc/timezone
  devtool: finish: Add suppport for the --no-clean option
  lib/oe/lsb: Make sure the distro ID is always lowercased

 meta/classes/meson.bbclass  | 15 +--
 meta/classes/package_rpm.bbclass|  5 ++---
 meta/lib/oe/lsb.py  |  8 
 .../meson/nativesdk-meson_0.49.2.bb |  5 -
 meta/recipes-extended/timezone/tzdata.bb|  5 +++--
 scripts/lib/devtool/standard.py | 17 +
 6 files changed, 23 insertions(+), 32 deletions(-)

-- 
2.21.0

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


[OE-core] [warrior][PATCH 2/8] nativesdk-meson: Remove some unused variables

2019-10-16 Thread Peter Kjellerstedt
From: Peter Kjellerstedt 

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/meson/nativesdk-meson_0.49.2.bb | 5 -
 1 file changed, 5 deletions(-)

diff --git a/meta/recipes-devtools/meson/nativesdk-meson_0.49.2.bb 
b/meta/recipes-devtools/meson/nativesdk-meson_0.49.2.bb
index 1549357a55..1756f342ce 100644
--- a/meta/recipes-devtools/meson/nativesdk-meson_0.49.2.bb
+++ b/meta/recipes-devtools/meson/nativesdk-meson_0.49.2.bb
@@ -16,11 +16,6 @@ def meson_endian(prefix, d):
 else:
 bb.fatal("Cannot determine endianism for %s-%s" % (arch, os))
 
-MESON_TOOLCHAIN_ARGS = "${BUILDSDK_CC_ARCH}${TOOLCHAIN_OPTIONS}"
-MESON_C_ARGS = "${MESON_TOOLCHAIN_ARGS} ${BUILDSDK_CFLAGS}"
-MESON_CPP_ARGS = "${MESON_TOOLCHAIN_ARGS} ${BUILDSDK_CXXFLAGS}"
-MESON_LINK_ARGS = "${MESON_TOOLCHAIN_ARGS} ${BUILDSDK_LDFLAGS}"
-
 # The cross file logic is similar but not identical to that in meson.bbclass,
 # since it's generating for an SDK rather than a cross-compile. Important
 # differences are:
-- 
2.21.0

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


[OE-core] [warrior][PATCH 1/8] meson.bbclass: Remove the MESON_*_ARGS variables

2019-10-16 Thread Peter Kjellerstedt
From: Peter Kjellerstedt 

The options in ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} are already passed
via ${CC}/${CXX} and there is no reason to pass them a second time. Thus
we can remove MESON_TOOLCHAIN_ARGS. And when it is removed, the other
MESON_*_ARGS variables revert to the standard CFLAGS, CXXFLAGS and
LDFLAGS, so just use them directly instead.

Apart from the obvious improvement with not passing a lot of options
twice, this also solves a problem where -pie would be passed on the
command line in a way that it would prevent building any dynamic
libraries using meson if using a toolchain that is not built with
--enable-default-pie and if security_flags.inc is used.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---
 meta/classes/meson.bbclass | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 115d1aedcb..5c0139f02a 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -30,11 +30,6 @@ MESONOPTS = " --prefix ${prefix} \
   -Dcpp_args='${BUILD_CPPFLAGS} ${BUILD_CXXFLAGS}' \
   -Dcpp_link_args='${BUILD_LDFLAGS}'"
 
-MESON_TOOLCHAIN_ARGS = "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
-MESON_C_ARGS = "${MESON_TOOLCHAIN_ARGS} ${CFLAGS}"
-MESON_CPP_ARGS = "${MESON_TOOLCHAIN_ARGS} ${CXXFLAGS}"
-MESON_LINK_ARGS = "${MESON_TOOLCHAIN_ARGS} ${LDFLAGS}"
-
 EXTRA_OEMESON_append = " ${PACKAGECONFIG_CONFARGS}"
 
 MESON_CROSS_FILE = ""
@@ -76,7 +71,7 @@ def meson_endian(prefix, d):
 bb.fatal("Cannot determine endianism for %s-%s" % (arch, os))
 
 addtask write_config before do_configure
-do_write_config[vardeps] += "MESON_C_ARGS MESON_CPP_ARGS MESON_LINK_ARGS CC 
CXX LD AR NM STRIP READELF"
+do_write_config[vardeps] += "CC CXX LD AR NM STRIP READELF CFLAGS CXXFLAGS 
LDFLAGS"
 do_write_config() {
 # This needs to be Py to split the args into single-element lists
 cat >${WORKDIR}/meson.cross <http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] systemd.bbclass: enable all services specified in ${SYSTEMD_SERVICE}

2019-10-16 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Mikko Rapeli
> Sent: den 16 oktober 2019 14:32
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] systemd.bbclass: enable all services
> specified in ${SYSTEMD_SERVICE}
> 
> This has been the traditional way of enabling systemd services.
> It may conflict with presets feature, but other layers, image classes
> and recipes add services to be enabled using SYSTEMD_SERVICE
> variable also with read-only rootfs, e.g. IMAGE_FEATURES has
> stateless-rootfs and systemd_preset_all task is not executed.
> 
> Fixes startup of custom services from our recipes using custom
> image classes with various BSP layers. In the worst case even
> serial console getty service wasn't starting due to dependency
> no not enabled services.
> 
> Signed-off-by: Mikko Rapeli 
> ---
>  meta/classes/systemd.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/systemd.bbclass
> b/meta/classes/systemd.bbclass
> index 1dca099..ae03c6f 100644
> --- a/meta/classes/systemd.bbclass
> +++ b/meta/classes/systemd.bbclass
> @@ -33,7 +33,7 @@ if type systemctl >/dev/null 2>/dev/null; then
>   if [ "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
>   for service in ${SYSTEMD_SERVICE_ESCAPED}; do
>   case "${service}" in
> - *@*)
> + *)
>   systemctl ${OPTS} enable "${service}"
>   ;;
>   esac

Not much point in leaving the case statement if it only has a 
capture all case. I.e., the above simplifies to:

if [ "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
for service in ${SYSTEMD_SERVICE_ESCAPED}; do
systemctl ${OPTS} enable "$service"

(also note the change of "${service}" to "$service" to avoid using 
${...} for shell variables where not necessary as this causes them 
to unnecessarily end up in the bitbake hash for the function.)

//Peter

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


Re: [OE-core] [PATCH] devtool: nlohmann-fifo

2019-10-15 Thread Peter Kjellerstedt
This was sent to the wrong mailing list. Please send it to 
openembedded-de...@lists.openembedded.org instead (no idea why 
patchwork is not complaining). 

See further comments below.

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Aatir
> Sent: den 15 oktober 2019 15:06
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] devtool: nlohmann-fifo

Change the subject to something like this instead:

nlohmann-fifo: Add recipe

> 
> From: Tekkub 
> 
> Adding nlohmann-fifo, a c++ header library for fifo maps.
> 
> Signed-off-by: Aatir 
> 
>  Author:Aatir 

Remove the Author footer.

> ---
>  .../nlohmann-fifo/nlohmann-fifo_git.bb| 22 +++
>  1 file changed, 22 insertions(+)
>  create mode 100644 
> meta-oe/recipes-devtools/nlohmann-fifo/nlohmann-fifo_git.bb
> 
> diff --git a/meta-oe/recipes-devtools/nlohmann-fifo/nlohmann-fifo_git.bb 
> b/meta-oe/recipes-devtools/nlohmann-fifo/nlohmann-fifo_git.bb
> new file mode 100644
> index 0..afab2eac4
> --- /dev/null
> +++ b/meta-oe/recipes-devtools/nlohmann-fifo/nlohmann-fifo_git.bb
> @@ -0,0 +1,22 @@
> +SUMMARY = "fifo maps for c++"
> +HOMEPAGE = "/"

Change to:

HOMEPAGE = "https://github.com/nlohmann/fifo_map;

> +SECTION = "libs"
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://LICENSE.MIT;md5=b67209a1e36b682a8226de19d265b1e0"
> +
> +SRC_URI = "git://github.com/nlohmann/fifo_map.git"
> +
> +PV = "1.0.0+git${SRCPV}"
> +
> +SRCREV = "0dfbf5dacbb15a32c43f912a7e66a54aae39d0f9"
> +
> +S = "${WORKDIR}/git"
> +
> +RDEPENDS_${PN}-dev = ""
> +
> +BBCLASSEXTEND = "native nativesdk"
> +
> +do_install() {
> +install -d ${D}${includedir}
> +install -m 0644 ${S}/src/fifo_map.hpp ${D}${includedir}/fifo_map.hpp

Remove "/fifo_map.hpp" at the end since the target file name matches 
the source file name.

> +}
> --
> 2.17.1

//Peter

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


Re: [OE-core] [OE-Core][master][PATCH] devtool: Add --remove-work option for devtool reset command

2019-10-08 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Chandana Kalluri
> Sent: den 8 oktober 2019 04:14
> To: Paul Eggleton 
> Cc: Patches and discussions about the oe-core layer  c...@lists.openembedded.org>
> Subject: Re: [OE-core] [OE-Core][master][PATCH] devtool: Add --remove-
> work option for devtool reset command
> 
> Hi Paul,
> 
> Any thoughts on implementing this as a separate command  as suggested
> by Khem?

For what it's worth, I think the original suggested solution with a new 
option to the existing `devtool reset` and `devtool finish` commands is 
the better one.

> > -Original Message-
> > From: Khem Raj 
> > Sent: Monday, October 7, 2019 11:40 AM
> > To: Chandana Kalluri 
> > Cc: Patches and discussions about the oe-core layer  > c...@lists.openembedded.org>
> > Subject: Re: [OE-core] [OE-Core][master][PATCH] devtool: Add --
> remove-work
> > option for devtool reset command
> >
> > On Mon, Oct 7, 2019 at 11:36 AM Sai Hari Chandana Kalluri
> >  wrote:
> > >
> > > Enable --remove-work option for devtool reset command that allows
> user
> > > to clean up source directory within workspace.
> > >
> > > Currently devtool reset command only removes recipes and user is
> > > forced to manually remove the sources directory within the
> workspace
> > > before running devtool modify again.
> > >
> > > Using devtool reset -r or devtool reset --remove-work option, user
> can
> > > cleanup the sources directory along with the recipe instead of
> > > manually cleaning it.
> >
> > perhaps we can have another cmd like "reset-all" like cleanall ?
> > which would remove everything that devtool did external to bblayers
> for that
> > recipe.
> >
> > >
> > > syntax: devtool reset -r 
> > > Ex: devtool reset -r zip
> > >
> > > devtool finish -r  
> > > Ex: devtool finish -r zip meta-yocto-bsp
> > >
> > > Signed-off-by: Sai Hari Chandana Kalluri
> 
> > > ---
> > >  scripts/lib/devtool/standard.py | 26 +++---
> > >  1 file changed, 19 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/scripts/lib/devtool/standard.py
> > > b/scripts/lib/devtool/standard.py index 60c9a04..1c0cd8a 100644
> > > --- a/scripts/lib/devtool/standard.py
> > > +++ b/scripts/lib/devtool/standard.py
> > > @@ -1852,7 +1852,7 @@ def status(args, config, basepath,
> workspace):
> > >  return 0
> > >
> > >
> > > -def _reset(recipes, no_clean, config, basepath, workspace):
> > > +def _reset(recipes, no_clean, remove_work, config, basepath,
> workspace):
> > >  """Reset one or more recipes"""
> > >  import oe.path
> > >
> > > @@ -1930,10 +1930,15 @@ def _reset(recipes, no_clean, config,
> basepath,
> > workspace):
> > >  srctreebase = workspace[pn]['srctreebase']
> > >  if os.path.isdir(srctreebase):
> > >  if os.listdir(srctreebase):
> > > -# We don't want to risk wiping out any work in
> progress
> > > -logger.info('Leaving source tree %s as-is; if you
> no '
> > > -'longer need it then please delete it
> manually'
> > > -% srctreebase)
> > > +if remove_work:
> > > +logger.info('-r argument used on %s,
> removing source tree.'
> > > +' You will lose any unsaved
> work' %pn)
> > > +shutil.rmtree(srctreebase)
> > > +else:
> > > +# We don't want to risk wiping out any
> work in progress
> > > +logger.info('Leaving source tree %s as-is;
> if you no '
> > > +'longer need it then please
> delete it manually'
> > > +% srctreebase)
> > >  else:
> > >  # This is unlikely, but if it's empty we can just
> remove it
> > >  os.rmdir(srctreebase) @@ -1943,6 +1948,10 @@ def
> > > _reset(recipes, no_clean, config, basepath, workspace):
> > >  def reset(args, config, basepath, workspace):
> > >  """Entry point for the devtool 'reset' subcommand"""
> > >  import bb
> > > +import shutil
> > > +
> > > +recipes = ""
> > > +
> > >  if args.recipename:
> > >  if args.all:
> > >  raise DevtoolError("Recipe cannot be specified if
> > > -a/--all is used") @@ -1957,7 +1966,7 @@ def reset(args, config,
> basepath,
> > workspace):
> > >  else:
> > >  recipes = args.recipename
> > >
> > > -_reset(recipes, args.no_clean, config, basepath, workspace)
> > > +_reset(recipes, args.no_clean, args.remove_work, config,
> > > + basepath, workspace)
> > >
> > >  return 0
> > >
> > > @@ -2009,6 +2018,7 @@ def finish(args, config, basepath,
> workspace):
> > >  raise DevtoolError('Source tree is not
> > > clean:\n\n%s\nEnsure you have committed your changes or use -f/--
> 

[OE-core] [PATCH] lib/oe/lsb: Make sure the distro ID is always lowercased

2019-09-27 Thread Peter Kjellerstedt
In commit 8689e561 (lib/oe/lsb: attempt to ensure consistent distro id
regardless of source), the distro ID returned by
oe.lsb.distro_identifier() was lowercased, but only if a release
version is also present.

This changes the code to always lowercase the distro ID, including the
default distro ID "unknown", which is used if no other ID can be
identified.

Signed-off-by: Peter Kjellerstedt 
---
 meta/lib/oe/lsb.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/lsb.py b/meta/lib/oe/lsb.py
index 4f2b419edc..43e46380d7 100644
--- a/meta/lib/oe/lsb.py
+++ b/meta/lib/oe/lsb.py
@@ -110,12 +110,12 @@ def distro_identifier(adjust_hook=None):
 if adjust_hook:
 distro_id, release = adjust_hook(distro_id, release)
 if not distro_id:
-return "Unknown"
-# Filter out any non-alphanumerics
-distro_id = re.sub(r'\W', '', distro_id)
+return "unknown"
+# Filter out any non-alphanumerics and convert to lowercase
+distro_id = re.sub(r'\W', '', distro_id).lower()
 
 if release:
-id_str = '{0}-{1}'.format(distro_id.lower(), release)
+id_str = '{0}-{1}'.format(distro_id, release)
 else:
 id_str = distro_id
 return id_str.replace(' ','-').replace('/','-')
-- 
2.21.0

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


[OE-core] [PATCH 2/2] devtool: finish: Add suppport for the --no-clean option

2019-09-20 Thread Peter Kjellerstedt
This works just like the already existing --no-clean option to the
`devtool reset` command.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/lib/devtool/standard.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 64fa420bf1..60c9a046f9 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -2008,7 +2008,7 @@ def finish(args, config, basepath, workspace):
 else:
 raise DevtoolError('Source tree is not clean:\n\n%s\nEnsure you 
have committed your changes or use -f/--force if you are sure there\'s nothing 
that needs to be committed' % dirty)
 
-no_clean = False
+no_clean = args.no_clean
 tinfoil = setup_tinfoil(basepath=basepath, tracking=True)
 try:
 rd = parse_recipe(config, tinfoil, args.recipename, True)
@@ -2282,6 +2282,7 @@ def register_commands(subparsers, context):
 parser_finish.add_argument('--mode', '-m', choices=['patch', 'srcrev', 
'auto'], default='auto', help='Update mode (where %(metavar)s is %(choices)s; 
default is %(default)s)', metavar='MODE')
 parser_finish.add_argument('--initial-rev', help='Override starting 
revision for patches')
 parser_finish.add_argument('--force', '-f', action="store_true", 
help='Force continuing even if there are uncommitted changes in the source tree 
repository')
+parser_finish.add_argument('--no-clean', '-n', action="store_true", 
help='Don\'t clean the sysroot to remove recipe output')
 parser_finish.add_argument('--no-overrides', '-O', action="store_true", 
help='Do not handle other override branches (if they exist)')
 parser_finish.add_argument('--dry-run', '-N', action="store_true", 
help='Dry-run (just report changes instead of writing them)')
 parser_finish.add_argument('--force-patch-refresh', action="store_true", 
help='Update patches in the layer even if they have not been modified (useful 
for refreshing patch context)')
-- 
2.21.0

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


[OE-core] [PATCH 1/2] devtool: finish: Keep patches ordered when updating bbappend

2019-09-20 Thread Peter Kjellerstedt
From: Niclas Svensson 

The _get_patchset_revs() function returns the patches in an
OrderedDict to keep them ordered. However, this information was lost
when the patches were added to the bbappend file.

Signed-off-by: Niclas Svensson 
Signed-off-by: Peter Kjellerstedt 
---
 scripts/lib/devtool/standard.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 9eeaefb79c..64fa420bf1 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -1619,17 +1619,17 @@ def _update_recipe_patch(recipename, workspace, 
srctree, rd, appendlayerdir, wil
   patches_dir, changed_revs)
 logger.debug('Pre-filtering: update: %s, new: %s' % (dict(upd_p), 
dict(new_p)))
 if filter_patches:
-new_p = {}
-upd_p = {k:v for k,v in upd_p.items() if k in filter_patches}
+new_p = OrderedDict()
+upd_p = OrderedDict((k,v) for k,v in upd_p.items() if k in 
filter_patches)
 remove_files = [f for f in remove_files if f in filter_patches]
 updatefiles = False
 updaterecipe = False
 destpath = None
 srcuri = (rd.getVar('SRC_URI', False) or '').split()
 if appendlayerdir:
-files = dict((os.path.join(local_files_dir, key), val) for
+files = OrderedDict((os.path.join(local_files_dir, key), val) for
  key, val in list(upd_f.items()) + list(new_f.items()))
-files.update(dict((os.path.join(patches_dir, key), val) for
+files.update(OrderedDict((os.path.join(patches_dir, key), val) for
   key, val in list(upd_p.items()) + 
list(new_p.items(
 if files or remove_files:
 removevalues = None
-- 
2.21.0

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


[OE-core] [PATCH] systemd: Make it build with hwdb disabled

2019-09-20 Thread Peter Kjellerstedt
If hwdb is disabled, then systemd-hwdb-update.service does not exists.
Do not try to modify it in this case.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-core/systemd/systemd_243.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_243.bb 
b/meta/recipes-core/systemd/systemd_243.bb
index f0e8c569b8..d0f9d17dba 100644
--- a/meta/recipes-core/systemd/systemd_243.bb
+++ b/meta/recipes-core/systemd/systemd_243.bb
@@ -299,9 +299,10 @@ do_install() {
 }
 
 do_install_append () {
-   # Mips qemu is extremely slow, allow more time for the hwdb update
-   # This is a workaround until 
https://github.com/systemd/systemd/issues/13581 is resolved
-   sed -i -e s#TimeoutSec=90s#TimeoutSec=180s# 
${D}${systemd_unitdir}/system/systemd-hwdb-update.service
+   # Mips qemu is extremely slow, allow more time for the hwdb update
+   # This is a workaround until 
https://github.com/systemd/systemd/issues/13581 is resolved
+   [ ! -e ${D}${systemd_unitdir}/system/systemd-hwdb-update.service ] ||
+   sed -i -e s#TimeoutSec=90s#TimeoutSec=180s# 
${D}${systemd_unitdir}/system/systemd-hwdb-update.service
 }
 
 python populate_packages_prepend (){
-- 
2.21.0

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


[OE-core] [PATCH 2/2] tzdata: Correct the packaging of /etc/localtime and /etc/timezone

2019-09-19 Thread Peter Kjellerstedt
During restructuring of the packaging in 2af4d6eb (tzdata: Install
everything by default), these two files remained in the tzdata
package, which is supposed to be empty. Move them to tzdata-core where
they belong.

Also simplify the definition of CONFFILES_tzdata-core. As its value
only takes effect for files that actually exist, there is no need to
complicate its definition by checking if a file is created before
adding it to the list of configuration files.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-extended/timezone/tzdata.bb | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/timezone/tzdata.bb 
b/meta/recipes-extended/timezone/tzdata.bb
index 82fe369baa..1e2d9bd1b9 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -147,6 +147,8 @@ FILES_tzdata-misc += "${datadir}/zoneinfo/Cuba   \
 RPROVIDES_tzdata-misc = "tzdata-misc"
 
 FILES_tzdata-core += " \
+${sysconfdir}/localtime  \
+${sysconfdir}/timezone   \
 ${datadir}/zoneinfo/Pacific/Honolulu \
 ${datadir}/zoneinfo/America/Anchorage\
 ${datadir}/zoneinfo/America/Los_Angeles  \
@@ -202,8 +204,7 @@ FILES_tzdata-core += " \
 ${datadir}/zoneinfo/iso3166.tab  \
 ${datadir}/zoneinfo/Etc/*"
 
-CONFFILES_tzdata-core += "${@ "${sysconfdir}/timezone" if 
bb.utils.to_boolean(d.getVar('INSTALL_TIMEZONE_FILE')) else "" }"
-CONFFILES_tzdata-core += "${sysconfdir}/localtime"
+CONFFILES_tzdata-core = "${sysconfdir}/localtime ${sysconfdir}/timezone"
 
 ALLOW_EMPTY_${PN} = "1"
 RDEPENDS_${PN} = "${TZ_PACKAGES}"
-- 
2.21.0

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


[OE-core] [PATCH 1/2] package_rpm.bbclass: Remove a misleading bb.note()

2019-09-19 Thread Peter Kjellerstedt
It should have been removed in 3db9d865 (classes/package_rpm.bbclass:
Enhance diagnostic messages) when it was split in two new notes.

Also change the casing of two other notes to align them with the other
notes.

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/package_rpm.bbclass | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index a605a57ecc..9145717f98 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -409,7 +409,6 @@ python write_specfile () {
 if not file_list and localdata.getVar('ALLOW_EMPTY', False) != "1":
 bb.note("Not creating empty RPM package for %s" % splitname)
 else:
-bb.note("Creating RPM package for %s" % splitname)
 spec_files_top.append('%files')
 if extra_pkgdata:
 package_rpm_extra_pkgdata(splitname, spec_files_top, 
localdata)
@@ -418,7 +417,7 @@ python write_specfile () {
 bb.note("Creating RPM package for %s" % splitname)
 spec_files_top.extend(file_list)
 else:
-bb.note("Creating EMPTY RPM Package for %s" % splitname)
+bb.note("Creating empty RPM package for %s" % splitname)
 spec_files_top.append('')
 continue
 
@@ -510,7 +509,7 @@ python write_specfile () {
 bb.note("Creating RPM package for %s" % splitname)
 spec_files_bottom.extend(file_list)
 else:
-bb.note("Creating EMPTY RPM Package for %s" % splitname)
+bb.note("Creating empty RPM package for %s" % splitname)
 spec_files_bottom.append('')
 
 del localdata
-- 
2.21.0

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


[OE-core] [PATCH] glibc: Make it build without ldconfig in DISTRO_FEATURES

2019-09-16 Thread Peter Kjellerstedt
The removal of the supposedly empty /etc when ldconfig is not in
DISTRO_FEATURES seems to be a remnant from a long time ago when nothing
else was installed in /etc. However, that is no longer the case as,
e.g., nscd.conf is always installed to /etc now.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-core/glibc/glibc-package.inc | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 2e8f9f3e02..d7037c5cce 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -97,7 +97,7 @@ do_install_append () {
# The dynamic loader will have been installed into
# ${base_libdir}. However, if that isn't going to end up being
# available in the ABI-mandated location, then a symlink must
-# be created.
+   # be created.
 
if [ -n "${ARCH_DYNAMIC_LOADER}" -a ! -e 
"${D}${root_prefix}/lib/${ARCH_DYNAMIC_LOADER}" ]; then
install -d ${D}${root_prefix}/lib
@@ -111,8 +111,6 @@ do_install_append_class-target() {
# The distro doesn't want these files so let's not install them
rm -f ${D}${sysconfdir}/ld.so.conf
rm -f ${D}${base_sbindir}/ldconfig
-   # This directory will be empty now so remove it too.
-   rmdir ${D}${sysconfdir}
fi
if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', 
d)}; then
install -d ${D}${sysconfdir}/tmpfiles.d
-- 
2.21.0

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


Re: [OE-core] [PATCH] glibc-testsuite: SkipRecipe if libc is not glibc

2019-09-13 Thread Peter Kjellerstedt
> -Original Message-
> From: Khem Raj 
> Sent: den 13 september 2019 15:48
> To: Nathan Rossi 
> Cc: Patches and discussions about the oe-core layer  c...@lists.openembedded.org>; Peter Kjellerstedt
> 
> Subject: Re: [OE-core] [PATCH] glibc-testsuite: SkipRecipe if libc is
> not glibc
> 
> On Fri, Sep 13, 2019 at 12:49 AM Nathan Rossi 
> wrote:
> >
> > To prevent issues with parsing or dependencies, limit this recipe to
> use
> > only when the libc is glibc (and libc-locale is glibc-locale).
> >
> > Signed-off-by: Nathan Rossi 
> > ---
> >  meta/recipes-core/glibc/glibc-testsuite_2.30.bb | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/meta/recipes-core/glibc/glibc-testsuite_2.30.bb
> b/meta/recipes-core/glibc/glibc-testsuite_2.30.bb
> > index 64fa8d87df..657fd4dbc1 100644
> > --- a/meta/recipes-core/glibc/glibc-testsuite_2.30.bb
> > +++ b/meta/recipes-core/glibc/glibc-testsuite_2.30.bb
> > @@ -8,6 +8,13 @@ PROVIDES = ""
> >  # setup depends
> >  INHIBIT_DEFAULT_DEPS = ""
> >
> > +python () {
> > +libc = d.getVar("PREFERRED_PROVIDER_virtual/libc")
> > +libclocale = d.getVar("PREFERRED_PROVIDER_virtual/libc-locale")
> > +if libc != "glibc" or libclocale != "glibc-locale":
> > +raise bb.parse.SkipRecipe("glibc-testsuite requires that 
> > virtual/libc is glibc")
> > +}
> > +
> would something like below work
> 
> COMPATIBLE_HOST ?= "null"
> COMAPTIBLE_HOST_libc-glibc = "(*)"

No, that will not work. The glibc we use is still glibc, even if it is not 
the version from OE-Core. Thus the libc-glibc override is active also in 
our case.

> >  DEPENDS += "glibc-locale libgcc gcc-runtime"
> >
> >  # remove the initial depends
> > ---
> > 2.23.0

I'll be back when I have had time to test the suggested patch.

//Peter

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


Re: [OE-core] [PATCH] bitbake: cooker: Ensure bbappends are found in stable order

2019-09-11 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Wes Lindauer
> Sent: den 28 augusti 2019 23:38
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] bitbake: cooker: Ensure bbappends are found
> in stable order
> 
> Thanks to wildcards in bbappend filenames, it's possible to have
> multiple bbappends that apply to the same recipe in the same directory.
> In order to get sstate hits between different workspaces, we want to
> apply those bbappend files in a consistent order.  Since readdir()
> returns files in a non-deterministic order between workspaces (based on
> inode number and/or time of creation), we'll need to sort its result in
> order to have any consistency.
> 
> Signed-off-by: Wes Lindauer 
> ---
>  bitbake/lib/bb/cooker.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py
> index 0607fcc708..a9ee142aa5 100644
> --- a/bitbake/lib/bb/cooker.py
> +++ b/bitbake/lib/bb/cooker.py
> @@ -1869,6 +1869,7 @@ class CookerCollectFiles(object):
>  (bbappend, filename) = b
>  if (bbappend == f) or ('%' in bbappend and 
> bbappend.startswith(f[:bbappend.index('%')])):
>  filelist.append(filename)
> +filelist.sort()
>  return filelist
> 
>  def collection_priorities(self, pkgfns, d):
> --
> 2.14.5

I don't think this was a good idea at all. Before, bbappends were applied 
in the priority order of the layers, but this change throws the sorting 
based on priority out the window and might cause bbappend files for higher 
layers to be applied before lower layers' bbappend files.

Please revert this change, and rethink how to maintain a stable order for 
bbappend files from the same directory without affecting bbappend files 
from different layers.

//Peter

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


[OE-core] [PATCH] glibc-testsuite: Depend on virtual/libc-locale instead of glibc-locale

2019-09-11 Thread Peter Kjellerstedt
This avoids the following error when using some other toolchain than
the one provided by OE-Core:

  ERROR: Nothing PROVIDES 'glibc-locale' (but
  .../meta/recipes-core/glibc/glibc-testsuite_2.30.bb DEPENDS on or
  otherwise requires it)
  glibc-locale was skipped: PREFERRED_PROVIDER_virtual/libc-locale set
  to some-other-glibc-locale, not glibc-locale

Signed-off-by: Peter Kjellerstedt 
---

I doubt glibc-testsuite will work when another toolchain is used, but
with this change it does at least not fail the build anymore.

 meta/recipes-core/glibc/glibc-testsuite_2.30.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-testsuite_2.30.bb 
b/meta/recipes-core/glibc/glibc-testsuite_2.30.bb
index 64fa8d87df..170e865cb0 100644
--- a/meta/recipes-core/glibc/glibc-testsuite_2.30.bb
+++ b/meta/recipes-core/glibc/glibc-testsuite_2.30.bb
@@ -8,7 +8,7 @@ PROVIDES = ""
 # setup depends
 INHIBIT_DEFAULT_DEPS = ""
 
-DEPENDS += "glibc-locale libgcc gcc-runtime"
+DEPENDS += "virtual/libc-locale libgcc gcc-runtime"
 
 # remove the initial depends
 DEPENDS_remove = "libgcc-initial"
-- 
2.21.0

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


Re: [OE-core] [PATCH] mdadm: fix do_package failed when changed local.conf but not cleaned

2019-09-05 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of
> changqing...@windriver.com
> Sent: den 5 september 2019 13:19
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] mdadm: fix do_package failed when changed
> local.conf but not cleaned
> 
> From: Changqing Li 
> 
> reproduce steps:
> 1. add DISTRO_FEATURE_append = 'usrmerge' in local.conf
> 2. bitbake mdadm --success
> 3. remove DISTRO_FEATURE_append = 'usrmerge' from local.conf
> 4. bitbake mdadm  -- failed when do_package
> 
> it is not proper to change source Makefile during do_compile by sed,
> change to add patch for it.
> 
> [YOCTO: #13493]
> 
> Signed-off-by: Changqing Li 
> ---
>  .../mdadm/files/0001-mdadm-support-usrmerge.patch  | 46
> ++
>  meta/recipes-extended/mdadm/mdadm_4.1.bb   |  7 ++--
>  2 files changed, 50 insertions(+), 3 deletions(-)
>  create mode 100644 meta/recipes-extended/mdadm/files/0001-mdadm-
> support-usrmerge.patch
> 
> diff --git a/meta/recipes-extended/mdadm/files/0001-mdadm-support-
> usrmerge.patch b/meta/recipes-extended/mdadm/files/0001-mdadm-support-
> usrmerge.patch
> new file mode 100644
> index 000..f1aa119
> --- /dev/null
> +++ b/meta/recipes-extended/mdadm/files/0001-mdadm-support-
> usrmerge.patch
> @@ -0,0 +1,46 @@
> +From 2c7ccea05d7cf9dde48d735faa511d1b06c14878 Mon Sep 17 00:00:00 2001
> +From: Changqing Li 
> +Date: Thu, 5 Sep 2019 18:03:11 +0800
> +Subject: [PATCH] mdadm: support usrmerge
> +
> +Upstream-Status: Inappropriate[oe-specific]
> +
> +Signed-off-by: Changqing Li 
> +---
> + Makefile | 6 +++---
> + 1 file changed, 3 insertions(+), 3 deletions(-)
> +
> +diff --git a/Makefile b/Makefile
> +index 4839001..466e960 100644
> +--- a/Makefile
>  b/Makefile
> +@@ -88,7 +88,7 @@ MAP_PATH = $(MAP_DIR)/$(MAP_FILE)
> + MDMON_DIR = $(RUN_DIR)
> + # place for autoreplace cookies
> + FAILED_SLOTS_DIR = $(RUN_DIR)/failed-slots
> +-SYSTEMD_DIR=/lib/systemd/system
> ++SYSTEMD_DIR=${SYSTEMD_UNITDIR}/system
> + LIB_DIR=/usr/libexec/mdadm
> +
> + COROSYNC:=$(shell [ -f $(SYSROOT)/usr/include/corosync/cmap.h ] ||
> echo -DNO_COROSYNC)
> +@@ -120,7 +120,7 @@ LDLIBS=-ldl
> +
> + INSTALL = /usr/bin/install
> + DESTDIR =
> +-BINDIR  = /sbin
> ++BINDIR  = ${BASE_SBINDIR}
> + MANDIR  = /usr/share/man
> + MAN4DIR = $(MANDIR)/man4
> + MAN5DIR = $(MANDIR)/man5
> +@@ -128,7 +128,7 @@ MAN8DIR = $(MANDIR)/man8
> +
> + UDEVDIR := $(shell $(PKG_CONFIG) --variable=udevdir udev 2>/dev/null)
> + ifndef UDEVDIR
> +- UDEVDIR = /lib/udev
> ++ UDEVDIR = ${NONARCH_BASE_LIBDIR}/udev
> + endif
> +
> + ifeq (,$(findstring s,$(MAKEFLAGS)))
> +--
> +2.7.4
> +
> diff --git a/meta/recipes-extended/mdadm/mdadm_4.1.bb b/meta/recipes-
> extended/mdadm/mdadm_4.1.bb
> index 74c94f6..efeb09d 100644
> --- a/meta/recipes-extended/mdadm/mdadm_4.1.bb
> +++ b/meta/recipes-extended/mdadm/mdadm_4.1.bb
> @@ -22,6 +22,7 @@ SRC_URI =
> "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \
>  file://mdadm.init \
>  
> file://0001-mdadm-add-option-y-for-use-syslog-to-recive-event-re.patch \
> file://include_sysmacros.patch \
> +   
> ${@bb.utils.contains('DISTRO_FEATURES','usrmerge','file://0001-mdadm-support-usrmerge.patch','',d)}
>  \

Since the patch will work regardless of whether usrmerge is enabled 
or not, I think it is better to always apply it. The same goes for 
the corresponding path for bootchart2.

> "
>  SRC_URI[md5sum] = "51bf3651bd73a06c413a2f964f299598"
>  SRC_URI[sha256sum] = 
> "ab7688842908d3583a704d491956f31324c3a5fc9f6a04653cb75d19f1934f4a"
> @@ -41,13 +42,13 @@ CFLAGS_append_powerpc64 = ' -D__SANE_USERSPACE_TYPES__'
>  CFLAGS_append_mipsarchn64 = ' -D__SANE_USERSPACE_TYPES__'
>  CFLAGS_append_mipsarchn32 = ' -D__SANE_USERSPACE_TYPES__'
> 
> -EXTRA_OEMAKE = 'CHECK_RUN_DIR=0 CXFLAGS="${CFLAGS}"'
> +EXTRA_OEMAKE = 'CHECK_RUN_DIR=0 CXFLAGS="${CFLAGS}" 
> BASE_SBINDIR="${base_sbindir}" \
> +NONARCH_BASE_LIBDIR="${nonarch_base_libdir}" \
> +SYSTEMD_UNITDIR="${systemd_unitdir}"'
> 
>  DEBUG_OPTIMIZATION_append = " -Wno-error"
> 
>  do_compile() {
> - # Point to right sbindir
> - sed -i -e "s;BINDIR  = /sbin;BINDIR = $base_sbindir;" -e "s;UDEVDIR = 
> /lib;UDEVDIR = $nonarch_base_libdir;" -e 
> "s;SYSTEMD_DIR=/lib/systemd/system;SYSTEMD_DIR=${systemd_unitdir}/system;" 
> ${S}/Makefile
>   oe_runmake SYSROOT="${STAGING_DIR_TARGET}"
>  }
> 
> --
> 2.7.4

//Peter

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


Re: [OE-core] [PATCH 6/6] xz: Remove GPLv3 license checksum

2019-09-05 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Adrian Bunk
> Sent: den 4 september 2019 21:54
> To: Richard Purdie 
> Cc: Patches and discussions about the oe-core layer  c...@lists.openembedded.org>
> Subject: Re: [OE-core] [PATCH 6/6] xz: Remove GPLv3 license checksum
> 
> On Wed, Sep 04, 2019 at 07:50:35PM +0100, Richard Purdie wrote:
> > On Wed, 2019-09-04 at 08:07 -0400, Mark Hatle wrote:
> > > On 9/3/19 1:59 PM, Wes Lindauer wrote:
> > > > Mark,
> > > >
> > > > In reference to "It typically does NOT include the license of
> > > > things used to
> > > > build the software (such as makefiles, autoconf fragments, etc)".
> > > > Since the only file that is licensed under GPLv3 is a M4 macro,
> > > > does that mean
> > > > the current patch is still valid? Shouldn't the GPLv3 license be
> > > > removed from
> > > > this recipe?
> > >
> > > Unless the M4 file is generating/injecting code into the build(very
> > > few I've
> > > seen do this), then I would say it's not under GPLv3 at all.  (And
> I
> > > wouldn't
> > > have included GPLv3 in the LICENSE statement.)
> > >
> > > But we need more consensus then just me saying so.
> > >
> > > This may be a good question for the OE-TSC to ensure that we have
> > > clarification
> > > on this issue, and it's not just me saying I think one way or
> > > another.
> >
> > Not sure it needs to go to the TSC, we just need a patch which
> clearly
> > says why the LICENSE statement is incorrect. I don't think the
> original
> > patch in the series was clear about why GPLv3 didn't apply but if the
> > commit message is improved, its probably fine.
> 
> I am getting more and more confused about both the patch and the
> semantics of LICENSE.
> 
> The status quo in the recipe is:
> 
> <--  snip  ->
> 
> # The source includes bits of PD, GPLv2, GPLv3, LGPLv2.1+, but the only
> file
> # which is GPLv3 is an m4 macro which isn't shipped in any of our
> packages,
> # and the LGPL bits are under lib/, which appears to be used for
> libgnu, which
> # appears to be used for DOS builds. So we're left with GPLv2+ and PD.
> LICENSE = "GPLv2+ & GPL-3.0-with-autoconf-exception & LGPLv2.1+ & PD"
> LICENSE_${PN} = "GPLv2+"
> LICENSE_${PN}-dev = "GPLv2+"
> LICENSE_${PN}-staticdev = "GPLv2+"
> LICENSE_${PN}-doc = "GPLv2+"
> LICENSE_${PN}-dbg = "GPLv2+"
> LICENSE_${PN}-locale = "GPLv2+"
> LICENSE_liblzma = "PD"
> 
> LIC_FILES_CHKSUM = "file://COPYING;md5=97d554a32881fee0aa283d96e47cb24a \
> 
> file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
> 
> file://COPYING.GPLv3;md5=d32239bcb673463ab874e80d47fae504 \
> 
> file://COPYING.LGPLv2.1;md5=4fbd65380cdd255951079008b364516c \
> 
> file://lib/getopt.c;endline=23;md5=2069b0ee710572c03bb3114e4532cd84 \
> "
> 
> <--  snip  -->
> 
> My confusion about the patch is that it removes COPYING.GPLv3 from
> LIC_FILES_CHKSUM but keeps GPL-3.0-with-autoconf-exception in LICENSE.
> 
> My confusion about the semantics of LICENSE is that I fail to find a
> clear statement in the documentation that the legal meaning of LICENSE
> in OE is what Mark claims it would be. Is this just Marks personal
> opinion on what should be done, or is this undocumented tribal
> knowledge, or is the exact semantics of LICENSE documented
> somewhere in a language that lawyers understand?
> 
> My guess for the latter would be "undocumented tribal knowledge",
> and clarification is required what is actually correct or incorrect
> here. And I think this is also what Mark was asking for.
> 
> > Cheers,
> >
> > Richard
> 
> cu
> Adrian

Another thing that complicates this further is related to gathering and 
distributing the license information. E.g., if one uses COPY_LIC_DIR = "1" 
to automatically include all the license information for all packages 
installed in the image, this will include everything listed in 
LIC_FILES_CHKSUM regardless of which packages were installed. I.e., even 
if only liblzma (which is PD) is installed from xz, all of the GPL 
license texts will be installed in /usr/share/common-licenses/xz...

//Peter

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


Re: [OE-core] [PATCH] iputils: fix a usrmerge build issue

2019-09-03 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of liu.min...@gmail.com
> Sent: den 3 september 2019 11:02
> To: openembedded-core@lists.openembedded.org
> Cc: stefan.ag...@toradex.com; Ming Liu 
> Subject: [OE-core] [PATCH] iputils: fix a usrmerge build issue
> 
> From: Ming Liu 
> 
> Fix a following build issue when usrmerge is enabled:
> | WARNING: iputils-s20190709-r0 do_package: iputils: alternative target
> (/usr/bin/ping or /usr/bin/ping.iputils) does not exist, skipping...
> | WARNING: iputils-s20190709-r0 do_package: iputils: NOT adding
> alternative provide /usr/bin/ping: /usr/bin/ping.iputils does not exist
> | ERROR: iputils-s20190709-r0 do_package: QA Issue: iputils:
> Files/directories were installed but not shipped in any package:
> |  /bin/tracepath
> |  /bin/ping
> |  /bin/arping
> |  /bin/traceroute6
> |  /bin/tftpd
> |  /bin/clockdiff
> |  /sbin/rdisc
> |  /sbin/rarpd
> |  /sbin/ninfod
> 
> Signed-off-by: Ming Liu 
> ---
>  meta/recipes-extended/iputils/iputils_s20190709.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-extended/iputils/iputils_s20190709.bb
> b/meta/recipes-extended/iputils/iputils_s20190709.bb
> index 34a6c68..ea7e6e3 100644
> --- a/meta/recipes-extended/iputils/iputils_s20190709.bb
> +++ b/meta/recipes-extended/iputils/iputils_s20190709.bb
> @@ -28,7 +28,7 @@ PACKAGECONFIG[docs] = "-DBUILD_HTML_MANS=true -
> DBUILD_MANS=true,-DBUILD_HTML_MAN
> 
>  inherit meson update-alternatives
> 
> -EXTRA_OEMESON += "--prefix=/"
> +EXTRA_OEMESON += "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', '', 
> '--prefix=/', d)}"

This should be better:

EXTRA_OEMESON += "--prefix=${root_prefix}/"

(and yes, the / after ${root_prefix} is needed in this case or meson 
will complain about --prefix having to be an absolute path in case 
${root_prefix} is empty, which it is when usrmerge is not set.)

>  ALTERNATIVE_PRIORITY = "100"
> 
> --
> 2.7.4

//Peter

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


Re: [OE-core] [PATCH] base.bbclass: add dependency on pseudo from do_prepare_recipe_sysroot

2019-08-31 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 30 augusti 2019 18:50
> To: Mattias Hansson ; openembedded-
> c...@lists.openembedded.org
> Cc: Mattias Hansson 
> Subject: Re: [OE-core] [PATCH] base.bbclass: add dependency on pseudo
> from do_prepare_recipe_sysroot
> 
> On Fri, 2019-08-16 at 11:13 +0200, Mattias Hansson wrote:
> > do_prepare_recipe_sysroot may perform groupadd, which requires pseudo.
> > However, do_prepare_recipe_sysroot does not depend on pseudo explicitly,
> > which sometimes causes a build error when building a recipe that adds
> > groups.
> >
> > This issue only occurs when executing do_prepare_recipe_sysroot for a
> > recipe that adds groups before finishing a task that depends on pseudo
> > for a recipe that doesn't add groups.
> >
> > Signed-off-by: Mattias Hansson 
> > ---
> >  meta/classes/base.bbclass | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> > index 0c8a4b2862..0576b110c9 100644
> > --- a/meta/classes/base.bbclass
> > +++ b/meta/classes/base.bbclass
> > @@ -480,6 +480,7 @@ python () {
> >  # If we're building a target package we need to use fakeroot (pseudo)
> >  # in order to capture permissions, owners, groups and special files
> >  if not bb.data.inherits_class('native', d) and not 
> > bb.data.inherits_class('cross', d):
> > +d.setVarFlag('do_prepare_recipe_sysroot', 'fakeroot', '1')
> >  d.setVarFlag('do_unpack', 'umask', '022')
> >  d.setVarFlag('do_configure', 'umask', '022')
> >  d.setVarFlag('do_compile', 'umask', '022')
> 
> This basically forces all target recipes prepare-recipe sysroot to run
> under pseudo "just in case", with all the performance overhead that
> entails. prepare_recipe_sysroot does a lot of file accesses so this is
> significant. It will also increase the pseudo database sizes
> everywhere.
> 
> We'll need to find a better way to handle this I'm afraid.
> 
> Cheers,
> 
> Richard

What do you prefer then, that we add this to useradd.bbclass instead?

python () {
# This corresponds to similar code in base.bbclass, but is added here as it
# is only needed for recipes that add users/groups.
if not bb.data.inherits_class('native', d) and not 
bb.data.inherits_class('cross', d):
d.setVarFlag('do_prepare_recipe_sysroot', 'fakeroot', '1')}
}

That way it should only affect recipes that manipulate users/groups.

//Peter

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


Re: [OE-core] FETCHCMD drop breaks build when append is used (from patch b259bd31eb)

2019-08-31 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Andre McCurdy
> Sent: den 30 augusti 2019 16:41
> To: Andrey Zhizhikin 
> Cc: OE Core mailing list 
> Subject: Re: [OE-core] FETCHCMD drop breaks build when append is used
> (from patch b259bd31eb)
> 
> On Fri, Aug 30, 2019 at 3:08 AM Andrey Zhizhikin 
> wrote:
> >
> > Hello Andre,
> >
> > I've just pulled the master and experienced a build failure during
> > fetching of updated recipe's source tarballs.
> >
> > The reason for this being that defaults for FETCHCMD has been dropped
> > with your patch b259bd31eb from the series. Once defaults are removed
> > and appends are used - the FETCHCMD gets defined to the value listed
> > in append, which normally does not contain a command itself rather
> > than necessary additional parameters (like user/passwd if working
> with
> > local pre-mirror servers).
> 
> I think for the specific case of usernames and passwords the advice
> would be to put them in .netrc etc rather than trying to append to the
> fetcher command lines (but mainly for security reasons rather than
> this issue).
> 
> > This patch would also break several other recipes which are using
> > appends to FETCHCMD, for example for FETCHCMD_wget the libedit would
> > fail since it appends the wget to use different User-Agent.
> >
> > I've copied Raj here since he introduced this recipe in the form it
> is
> > and would definitely break.
> >
> > Can you please have a look at this and advise on how one can continue
> > to use the FETCHCMD appends for the future?
> 
> One answer could be that modifications of the fetcher command lines
> should be done by completely defining them rather than appending. I'm
> not sure how reasonable that is though.
> 
> In the end the approach to fixing this depends on whether appending to
> the default fetcher commands is considered valid usage or not... and I
> don't know the answer to that.
> 
> > For now, I've defined the FETCHCMD_wget in my local.conf but I do not
> > believe that this is the general way everyone should follow if they
> > would need to append fetcher commands...
> >
> > Thanks a lot!
> >
> > --
> > Regards,
> > Andrey.

Given that the libedit recipe in OE-Core does:

FETCHCMD_wget += "-U bitbake"

someone will probably have to do something about this...

One can also note that wget.py and npm.py will now use different arguments 
to wget after the default was removed from bitbake.conf (the difference 
being the added use of -nv in npm.py so nothing major, but still...)

//Peter

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


[OE-core] [PATCH] devtool: Avoid failure for recipes with S == WORKDIR and no local files

2019-08-29 Thread Peter Kjellerstedt
When extracting the sources for a recipe that has S == WORKDIR and no
local files in the SRC_URI (which, e.g., can happen for a recipe with
a URI that has the unpack=false attribute), the extraction fails with
the following backtrace:

  Traceback (most recent call last):
File ".../scripts/devtool", line 344, in 
  ret = main()
File ".../scripts/devtool", line 331, in main
  ret = args.func(args, config, basepath, workspace)
File ".../poky/scripts/lib/devtool/standard.py", line 762, in
modify
  initial_rev, _ = _extract_source(srctree, args.keep_temp,
  args.branch, False, config, basepath, workspace,
  args.fixed_setup, rd, tinfoil, no_overrides=args.no_overrides)
File ".../poky/scripts/lib/devtool/standard.py", line 647, in
_extract_source
  bb.process.run('git %s commit -a -m "Committing local file
  symlinks\n\n%s"' % (' '.join(useroptions),
  oe.patch.GitApplyTree.ignore_commit_prefix), cwd=srctree)
File ".../poky/bitbake/lib/bb/process.py", line 178, in run
  raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
  bb.process.ExecutionError: Execution of 'git commit -a -m
  "Committing local file symlinks

  %% ignore"' failed with exit code 1:
  On branch devtool
  nothing to commit, working tree clean

This is because no files were found in the oe-local-files directory
and consequently no symbolic links were added using `git add`, but the
`git commit` command was still executed.

Signed-off-by: Peter Kjellerstedt 
---
 scripts/lib/devtool/standard.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 96af488798..9eeaefb79c 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -482,9 +482,9 @@ def symlink_oelocal_files_srctree(rd,srctree):
 addfiles.append(os.path.join(relpth, fn))
 if addfiles:
 bb.process.run('git add %s' % ' '.join(addfiles), cwd=srctree)
-useroptions = []
-oe.patch.GitApplyTree.gitCommandUserOptions(useroptions, d=rd)
-bb.process.run('git %s commit -a -m "Committing local file 
symlinks\n\n%s"' % (' '.join(useroptions), 
oe.patch.GitApplyTree.ignore_commit_prefix), cwd=srctree)
+useroptions = []
+oe.patch.GitApplyTree.gitCommandUserOptions(useroptions, d=rd)
+bb.process.run('git %s commit -m "Committing local file 
symlinks\n\n%s"' % (' '.join(useroptions), 
oe.patch.GitApplyTree.ignore_commit_prefix), cwd=srctree)
 
 
 def _extract_source(srctree, keep_temp, devbranch, sync, config, basepath, 
workspace, fixed_setup, d, tinfoil, no_overrides=False):
-- 
2.21.0

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


[OE-core] [PATCHv2] libffi: Make it build for MIPS o32

2019-08-23 Thread Peter Kjellerstedt
This solves the following errors:

  src/mips/o32.S: Assembler messages:
  src/mips/o32.S:286: Error: opcode not supported on this processor:
mips32r2 (mips32r2) `s.d $f12,((16*4)-10*4)($fp)'
  src/mips/o32.S:287: Error: opcode not supported on this processor:
mips32r2 (mips32r2) `s.d $f14,((16*4)-8*4)($fp)'

Signed-off-by: Peter Kjellerstedt 
---

PATCHv2: Add Signed-off-by to the patch file.

 ...-missed-ifndef-for-__mips_soft_float.patch | 31 +++
 meta/recipes-support/libffi/libffi_3.3~rc0.bb |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 
meta/recipes-support/libffi/libffi/0001-Fixed-missed-ifndef-for-__mips_soft_float.patch

diff --git 
a/meta/recipes-support/libffi/libffi/0001-Fixed-missed-ifndef-for-__mips_soft_float.patch
 
b/meta/recipes-support/libffi/libffi/0001-Fixed-missed-ifndef-for-__mips_soft_float.patch
new file mode 100644
index 00..00a30a3554
--- /dev/null
+++ 
b/meta/recipes-support/libffi/libffi/0001-Fixed-missed-ifndef-for-__mips_soft_float.patch
@@ -0,0 +1,31 @@
+From 4149a7627a998731cc246d3f58a36808745d04c8 Mon Sep 17 00:00:00 2001
+From: Carl Hurd 
+Date: Wed, 18 Jul 2018 09:04:32 -0400
+Subject: [PATCH] Fixed missed #ifndef for __mips_soft_float
+
+Signed-off-by: Peter Kjellerstedt 
+---
+Upstream-Status: Submitted [https://github.com/libffi/libffi/pull/442]
+
+ src/mips/o32.S | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/mips/o32.S b/src/mips/o32.S
+index 44e74cb..799139b 100644
+--- a/src/mips/o32.S
 b/src/mips/o32.S
+@@ -282,9 +282,11 @@ $LCFI12:
+   li  $13, 1  # FFI_O32
+   bne $16, $13, 1f# Skip fp save if FFI_O32_SOFT_FLOAT
+   
++#ifndef __mips_soft_float
+   # Store all possible float/double registers.
+   s.d $f12, FA_0_0_OFF2($fp)
+   s.d $f14, FA_1_0_OFF2($fp)
++#endif
+ 1:
+   # prepare arguments for ffi_closure_mips_inner_O32
+   REG_L   a0, 4($15)   # cif 
+-- 
+2.21.0
+
diff --git a/meta/recipes-support/libffi/libffi_3.3~rc0.bb 
b/meta/recipes-support/libffi/libffi_3.3~rc0.bb
index dadde0b2a0..3e2845546e 100644
--- a/meta/recipes-support/libffi/libffi_3.3~rc0.bb
+++ b/meta/recipes-support/libffi/libffi_3.3~rc0.bb
@@ -12,6 +12,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=3610bb17683a0089ed64055416b2ae1b"
 
 SRC_URI = 
"https://github.com/libffi/libffi/releases/download/v3.3-rc0/libffi-3.3-rc0.tar.gz
 \
file://not-win32.patch \
+   file://0001-Fixed-missed-ifndef-for-__mips_soft_float.patch \
"
 SRC_URI[md5sum] = "8d2a82a78faf10a5e53c27d986e8f04e"
 SRC_URI[sha256sum] = 
"403d67aabf1c05157855ea2b1d9950263fb6316536c8c333f5b9ab1eb2f20ecf"
-- 
2.21.0

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


[OE-core] [PATCH] libffi: Make it build for MIPS o32

2019-08-23 Thread Peter Kjellerstedt
This solves the following errors:

  src/mips/o32.S: Assembler messages:
  src/mips/o32.S:286: Error: opcode not supported on this processor:
mips32r2 (mips32r2) `s.d $f12,((16*4)-10*4)($fp)'
  src/mips/o32.S:287: Error: opcode not supported on this processor:
mips32r2 (mips32r2) `s.d $f14,((16*4)-8*4)($fp)'

Signed-off-by: Peter Kjellerstedt 
---
 ...-missed-ifndef-for-__mips_soft_float.patch | 30 +++
 meta/recipes-support/libffi/libffi_3.3~rc0.bb |  1 +
 2 files changed, 31 insertions(+)
 create mode 100644 
meta/recipes-support/libffi/libffi/0001-Fixed-missed-ifndef-for-__mips_soft_float.patch

diff --git 
a/meta/recipes-support/libffi/libffi/0001-Fixed-missed-ifndef-for-__mips_soft_float.patch
 
b/meta/recipes-support/libffi/libffi/0001-Fixed-missed-ifndef-for-__mips_soft_float.patch
new file mode 100644
index 00..a20bc3f4ed
--- /dev/null
+++ 
b/meta/recipes-support/libffi/libffi/0001-Fixed-missed-ifndef-for-__mips_soft_float.patch
@@ -0,0 +1,30 @@
+From 4149a7627a998731cc246d3f58a36808745d04c8 Mon Sep 17 00:00:00 2001
+From: Carl Hurd 
+Date: Wed, 18 Jul 2018 09:04:32 -0400
+Subject: [PATCH] Fixed missed #ifndef for __mips_soft_float
+
+---
+Upstream-Status: Submitted [https://github.com/libffi/libffi/pull/442]
+
+ src/mips/o32.S | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/mips/o32.S b/src/mips/o32.S
+index 44e74cb..799139b 100644
+--- a/src/mips/o32.S
 b/src/mips/o32.S
+@@ -282,9 +282,11 @@ $LCFI12:
+   li  $13, 1  # FFI_O32
+   bne $16, $13, 1f# Skip fp save if FFI_O32_SOFT_FLOAT
+   
++#ifndef __mips_soft_float
+   # Store all possible float/double registers.
+   s.d $f12, FA_0_0_OFF2($fp)
+   s.d $f14, FA_1_0_OFF2($fp)
++#endif
+ 1:
+   # prepare arguments for ffi_closure_mips_inner_O32
+   REG_L   a0, 4($15)   # cif 
+-- 
+2.21.0
+
diff --git a/meta/recipes-support/libffi/libffi_3.3~rc0.bb 
b/meta/recipes-support/libffi/libffi_3.3~rc0.bb
index dadde0b2a0..3e2845546e 100644
--- a/meta/recipes-support/libffi/libffi_3.3~rc0.bb
+++ b/meta/recipes-support/libffi/libffi_3.3~rc0.bb
@@ -12,6 +12,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=3610bb17683a0089ed64055416b2ae1b"
 
 SRC_URI = 
"https://github.com/libffi/libffi/releases/download/v3.3-rc0/libffi-3.3-rc0.tar.gz
 \
file://not-win32.patch \
+   file://0001-Fixed-missed-ifndef-for-__mips_soft_float.patch \
"
 SRC_URI[md5sum] = "8d2a82a78faf10a5e53c27d986e8f04e"
 SRC_URI[sha256sum] = 
"403d67aabf1c05157855ea2b1d9950263fb6316536c8c333f5b9ab1eb2f20ecf"
-- 
2.21.0

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


Re: [OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-14 Thread Peter Kjellerstedt
> -Original Message-
> From: richard.pur...@linuxfoundation.org
> 
> Sent: den 14 augusti 2019 14:56
> To: Alexander Kanavin 
> Cc: Peter Kjellerstedt ; Khem Raj
> ; OE-core  c...@lists.openembedded.org>
> Subject: Re: [OE-core] Long delays with latest bitbake (was: [PATCH
> 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS
> recursively)
> 
> On Wed, 2019-08-14 at 14:08 +0200, Alexander Kanavin wrote:
> > On Wed, 14 Aug 2019 at 13:36, 
> > wrote:
> > > On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> > > > On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> > > > richard.pur...@linuxfoundation.org> wrote:
> > > > > I had a glance at the profile output from master-next and the
> > > > > problem
> > > > > wasn't where I thought it would be, it was in the scheduler
> > > code.
> > > > > That
> > > > > is good as those classes are effectively independent of the
> > > other
> > > > > changes and hence are a separate fix.
> > > > >
> > > > > I've put a patch in -next which takes the above test to 36s
> > > which
> > > > > is
> > > > > close to the older bitbake.
> > > > >
> > > > > Could be interesting to see how it looks for others and
> > > different
> > > > > workloads.
> > > >
> > > > I just tried the same test I did yesterday with
> > > > ab56d466452148e5fce330d279d13e2495eceb1f. Unfortunately it
> > > doesn't
> > > > seem to improve things much: bitbake is stuck at "NOTE: Executing
> > > > Tasks" for 15 minutes now.
> > >
> > > This might sound slightly crazy but can you try commenting out this
> > > line in runqueue.py:
> > >
> > > logger.debug(2, "Holding off tasks %s" %
> > > pprint.pformat(self.holdoff_tasks))
> > >
> > > ?
> >
> > Even crazier is the outcome: it helped!
> 
> Cool, I think I can explain it.
> 
> The holdoff_tasks list can contain a list of nearly all the tasks at
> some points in execution. Even though the debug messages aren't being
> printed on the console, they are being sent over the internal IPC bus
> between the cooker, UI and other event handlers. Obviously for small
> task lists its not a problem, for large ones its multiple 4k chunks
> over pipes which isn't going to be fast.
> 
> We have done a lot of optimisation in the past but its all too easy to
> trend on something like this and upset things :/.
> 
> > The whole thing completed after 15m49secons (with much of the time
> > going to the empty task spin), that's some 3 minutes slower, but
> > certainly it's usable again.
> 
> You followed up mentioning this wasn't with master-next. I think there
> is a patch in -next which will help with the empty task spin so both
> together might get us back to more normal numbers.
> 
> Cheers,
> 
> Richard

I can just confirm that removing the debug line removes almost all of 
the delays I was seeing. Here are some time statistics from my builds:

6c7c0cef: 02:50
7df31ff3: 06:13  (first attempt)
a0542ed3: 06:32  (master)
19a88c68: 43:19* (~yesterday's master-next)
b0a0e4a6: 06:55  (master-next)
no debug: 03:04  (master-next + removal of "Holding off tasks" debug)

* I aborted this build after about half of the 12540 tasks were done...

One thing I have noticed while I was doing the timings is that I do 
not seem to be able to kill the bitbake server with bitbake -m after 
the builds have completed, but have to resort to using kill -9 most 
of the time... 

//Peter

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


[OE-core] Long delays with latest bitbake (was: [PATCH 1/7] insane.bbclass: in file-rdeps do not look into RDEPENDS recursively)

2019-08-12 Thread Peter Kjellerstedt
I’m seeing similar results with our builds (Poky + some layers from 
OpenEmbedded + our own layers; no hash equivalency). Here are some examples of 
builds from today (with approximate timings added manually by me):

Initialising tasks: 100% |###| Time: 0:00:08
<1 minute without any output>
Checking sstate mirror object availability: 100% |###| Time: 0:00:23
Sstate summary: Wanted 4151 Found 0 Missed 4151 Current 943 (0% match, 18% 
complete)
NOTE: Executing Tasks
<3 minutes without any output>
NOTE: Setscene tasks completed
<9 minutes without any output>
No currently running tasks (512 of 12540)   4% |#  |

After that I aborted the build and removed the tmp directory. The next build 
started without any of the above delays. However, the display of the then 
executed setscene tasks by knotty is anything but useful now after the latest 
changes to bitbake (mostly showing nothing, and occasionally showing a few 
lines saying that it is running task 0 of 0 which are immediately removed 
again). Anyway, after that build had run for a couple of thousand tasks it 
failed with a build error. When I had fixed that and started the build again, I 
got these timings:

Initialising tasks: 100% |###| Time: 0:00:08
Checking sstate mirror object availability: 100% |###| Time: 0:00:18
<1.5 minutes without any output>
Sstate summary: Wanted 3870 Found 1 Missed 3869 Current 1224 (0% match, 24% 
complete)
NOTE: Executing Tasks
<2 minutes without any output>
NOTE: Setscene tasks completed

That build eventually completed normally. Finally, when I started the build 
again to basically do nothing, I got this:

Initialising tasks: 100% |###| Time: 0:00:08
<3 minutes without any output>
NOTE: Executing Tasks
NOTE: Setscene tasks completed

Comparing that build to a corresponding do-nothing build with Thud, the time 
difference matches those three minutes where I have no idea what bitbake is 
doing now that it didn’t need to do before…

Hopefully these time degradations can be solved, because the current state of 
bitbake is barely usable. We also need to look into possible ways to improve 
the cooker output when it is running the setscene tasks so it makes some kind 
of sense again.

//Peter

From: openembedded-core-boun...@lists.openembedded.org 
 On Behalf Of Alexander 
Kanavin
Sent: den 12 augusti 2019 21:50
To: Khem Raj 
Cc: OE-core 
Subject: Re: [OE-core] [PATCH 1/7] insane.bbclass: in file-rdeps do not look 
into RDEPENDS recursively

On Mon, 12 Aug 2019 at 21:01, Khem Raj 
mailto:raj.k...@gmail.com>> wrote:

Richard, another issue I saw was slowness in world builds when I had
this enabled
I was on master-next for both core and bitbake. It was spending a lot
of time in ensuring
the build is not needed so much that the build took almost same time
than the build with
out it where the build without it will build everything.

world builds seem to have regressed (preparation time wise) even without having 
hash equivalency. Just oe-core is bearable, but adding meta-oe layers makes it 
spent many minutes after initializing tasks but before any tasks actually begin.

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


Re: [OE-core] [PATCH v2] systemd: Add partial support of drop-in configuration files to systemd-systemctl-native

2019-07-26 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Frederic Ouellet
> Sent: den 25 juli 2019 21:59
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH v2] systemd: Add partial support of drop-in
> configuration files to systemd-systemctl-native
> 
> Support for serive-name.service.d/ folders containing .conf files

Change "serive-name.service.d/" to ".service.d/".

> It don't support all the partial folder names

Change "don't" to "doesn't".

> See https://www.freedesktop.org/software/systemd/man/systemd.unit.html
> 
> Signed-off-by: Frederic Ouellet 
> ---
>  meta/recipes-core/systemd/systemd-systemctl/systemctl | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd-systemctl/systemctl
> b/meta/recipes-core/systemd/systemd-systemctl/systemctl
> index 8d7b3ba..8837f54 100755
> --- a/meta/recipes-core/systemd/systemd-systemctl/systemctl
> +++ b/meta/recipes-core/systemd/systemd-systemctl/systemctl
> @@ -28,6 +28,10 @@ class SystemdFile():
>  def __init__(self, root, path):
>  self.sections = dict()
>  self._parse(root, path)
> +dirname = os.path.basename(path.name) + ".d"
> +for location in locations:
> +for path2 in sorted((root / location / "system" / 
> dirname).glob("*.conf")):
> +self._parse(root, path2)
> 
>  def _parse(self, root, path):
>  """Parse a systemd syntax configuration file
> @@ -56,8 +60,11 @@ class SystemdFile():
>  line = line.rstrip("\n")
>  m = section_re.match(line)
>  if m:
> -section = dict()
> -self.sections[m.group('section')] = section
> +if m.group('section') not in self.sections:
> +section = dict()
> +self.sections[m.group('section')] = section
> +else:
> +section = self.sections[m.group('section')]
>  continue
> 
>  while line.endswith("\\"):
> --
> 2.7.4

//Peter

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


[OE-core] [PATCH 1/2] meson.bbclass: Remove the MESON_*_ARGS variables

2019-07-15 Thread Peter Kjellerstedt
The options in ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} are already passed
via ${CC}/${CXX} and there is no reason to pass them a second time. Thus
we can remove MESON_TOOLCHAIN_ARGS. And when it is removed, the other
MESON_*_ARGS variables revert to the standard CFLAGS, CXXFLAGS and
LDFLAGS, so just use them directly instead.

Apart from the obvious improvement with not passing a lot of options
twice, this also solves a problem where -pie would be passed on the
command line in a way that it would prevent building any dynamic
libraries using meson if using a toolchain that is not built with
--enable-default-pie and if security_flags.inc is used.

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/meson.bbclass | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 0edbfc1815..70b3653738 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -30,11 +30,6 @@ MESONOPTS = " --prefix ${prefix} \
   -Dcpp_args='${BUILD_CPPFLAGS} ${BUILD_CXXFLAGS}' \
   -Dcpp_link_args='${BUILD_LDFLAGS}'"
 
-MESON_TOOLCHAIN_ARGS = "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
-MESON_C_ARGS = "${MESON_TOOLCHAIN_ARGS} ${CFLAGS}"
-MESON_CPP_ARGS = "${MESON_TOOLCHAIN_ARGS} ${CXXFLAGS}"
-MESON_LINK_ARGS = "${MESON_TOOLCHAIN_ARGS} ${LDFLAGS}"
-
 EXTRA_OEMESON_append = " ${PACKAGECONFIG_CONFARGS}"
 
 MESON_CROSS_FILE = ""
@@ -78,7 +73,7 @@ def meson_endian(prefix, d):
 bb.fatal("Cannot determine endianism for %s-%s" % (arch, os))
 
 addtask write_config before do_configure
-do_write_config[vardeps] += "MESON_C_ARGS MESON_CPP_ARGS MESON_LINK_ARGS CC 
CXX LD AR NM STRIP READELF"
+do_write_config[vardeps] += "CC CXX LD AR NM STRIP READELF CFLAGS CXXFLAGS 
LDFLAGS"
 do_write_config() {
 # This needs to be Py to split the args into single-element lists
 cat >${WORKDIR}/meson.cross <http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/2] nativesdk-meson: Remove some unused variables

2019-07-15 Thread Peter Kjellerstedt
Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-devtools/meson/nativesdk-meson_0.50.1.bb | 5 -
 1 file changed, 5 deletions(-)

diff --git a/meta/recipes-devtools/meson/nativesdk-meson_0.50.1.bb 
b/meta/recipes-devtools/meson/nativesdk-meson_0.50.1.bb
index 1549357a55..1756f342ce 100644
--- a/meta/recipes-devtools/meson/nativesdk-meson_0.50.1.bb
+++ b/meta/recipes-devtools/meson/nativesdk-meson_0.50.1.bb
@@ -16,11 +16,6 @@ def meson_endian(prefix, d):
 else:
 bb.fatal("Cannot determine endianism for %s-%s" % (arch, os))
 
-MESON_TOOLCHAIN_ARGS = "${BUILDSDK_CC_ARCH}${TOOLCHAIN_OPTIONS}"
-MESON_C_ARGS = "${MESON_TOOLCHAIN_ARGS} ${BUILDSDK_CFLAGS}"
-MESON_CPP_ARGS = "${MESON_TOOLCHAIN_ARGS} ${BUILDSDK_CXXFLAGS}"
-MESON_LINK_ARGS = "${MESON_TOOLCHAIN_ARGS} ${BUILDSDK_LDFLAGS}"
-
 # The cross file logic is similar but not identical to that in meson.bbclass,
 # since it's generating for an SDK rather than a cross-compile. Important
 # differences are:
-- 
2.21.0

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


[OE-core] sysstat no longer builds (was: [PATCH 0/1] sysstat: use service file from source codes)

2019-07-12 Thread Peter Kjellerstedt
[ I cannot find the actual patch in my mailbox, which is why I am 
  replying to the cover letter. ]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
>  On Behalf Of Chen Qi
> Sent: den 9 juli 2019 07:53
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 0/1] sysstat: use service file from source codes
> 
> *** BLURB HERE ***
> The following changes since commit 4a68a44f56c725914cfa721993a2ea8a3dc6ebd5:
> 
>   cve-update-db: Catch request.urlopen errors. (2019-07-05 12:00:20 +0100)
> 
> are available in the git repository at:
> 
>   git://git.pokylinux.org/poky-contrib ChenQi/sysstat-systemd
>   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/sysstat-systemd
> 
> Chen Qi (1):
>   sysstat: use service file from source codes
> 
>  meta/recipes-extended/sysstat/sysstat.inc |  8 ++--
>  meta/recipes-extended/sysstat/sysstat/sysstat.service | 12 
>  2 files changed, 2 insertions(+), 18 deletions(-)
>  delete mode 100644 meta/recipes-extended/sysstat/sysstat/sysstat.service
> 
> --
> 1.9.1

I do not know how this was tested, but it is no longer possible to build 
sysstat after this change was integrated. I now get the following when I 
build it:

  ERROR: sysstat-12.1.3-r0 do_package: SYSTEMD_SERVICE_sysstat value 
sysstat.service does not exist
  ERROR: sysstat-12.1.3-r0 do_package:
  ERROR: sysstat-12.1.3-r0 do_package: Function failed: 
systemd_populate_packages

This is due to that the upstream package only installs the sysstat.service 
file if cron support is enabled, which it isn't by default.

There was another patch by Haiqing Bai sent on July 2 that seemed to handle 
this properly.

//Peter

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


[OE-core] [PATCH] glibc-package.inc: Do not use bitbake variable syntax for shell variables

2019-07-12 Thread Peter Kjellerstedt
Using bitbake variable syntax (i.e., ${FOO}) for shell variables is
bad practice. First of all it is confusing, but more importantly it
can lead to weird problems if someone actually defines a bitbake
variable with the same name as the shell variable.

Also correct the indentation in stash_locale_cleanup().

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-core/glibc/glibc-package.inc | 48 +++
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 5cfb1b6ab9..b150a34378 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -161,34 +161,34 @@ bashscripts = "mtrace sotruss xtrace"
 
 do_stash_locale () {
dest=${LOCALESTASH}
-   install -d ${dest}${base_libdir} ${dest}${bindir} ${dest}${libdir} 
${dest}${datadir}
+   install -d $dest${base_libdir} $dest${bindir} $dest${libdir} 
$dest${datadir}
# Hide away the locale data from the deployment
if [ -e ${D}${bindir}/localedef ]; then
-   cp -a ${D}${bindir}/localedef ${dest}${bindir}
+   cp -a ${D}${bindir}/localedef $dest${bindir}
fi
if [ -e ${D}${libdir}/gconv ]; then
-   cp -a ${D}${libdir}/gconv ${dest}${libdir}
+   cp -a ${D}${libdir}/gconv $dest${libdir}
fi
if [ -e ${D}${datadir}/i18n ]; then
-   cp -a  ${D}${datadir}/i18n ${dest}${datadir}
+   cp -a  ${D}${datadir}/i18n $dest${datadir}
fi
 
# Make a copy of all the libraries into the locale stash
-   cp -fpPR ${D}${libdir}/* ${dest}${libdir}
+   cp -fpPR ${D}${libdir}/* $dest${libdir}
if [ "${base_libdir}" != "${libdir}" ]; then
-   cp -fpPR ${D}${base_libdir}/* ${dest}${base_libdir}
+   cp -fpPR ${D}${base_libdir}/* $dest${base_libdir}
fi
if [ -e ${D}${exec_prefix}/lib ]; then
if [ ${exec_prefix}/lib != ${base_libdir} ] && [ 
${exec_prefix}/lib != ${libdir} ]; then
-   cp -fpPR ${D}${exec_prefix}/lib ${dest}${exec_prefix}
+   cp -fpPR ${D}${exec_prefix}/lib $dest${exec_prefix}
fi
fi
 
-   cp -fpPR ${D}${datadir}/* ${dest}${datadir}
+   cp -fpPR ${D}${datadir}/* $dest${datadir}
rm -rf ${D}${datadir}/locale/
-   cp -fpPR ${WORKDIR}/SUPPORTED ${dest}
+   cp -fpPR ${WORKDIR}/SUPPORTED $dest
 
-   target=${dest}/scripts
+   target=$dest/scripts
mkdir -p $target
for i in ${bashscripts}; do
if [ -f ${D}${bindir}/$i ]; then
@@ -216,23 +216,23 @@ stash_locale_cleanup () {
cleanupdir=$1
# Remove all files which do_stash_locale() copies
for i in ${bashscripts}; do
-   rm -f ${cleanupdir}${bindir}/$i
+   rm -f $cleanupdir${bindir}/$i
done
-   rm -f ${cleanupdir}${bindir}/localedef
-   rm -rf ${cleanupdir}${datadir}/i18n
-   rm -rf ${cleanupdir}${libdir}/gconv
-   rm -rf ${cleanupdir}/${localedir}
-   rm -rf ${cleanupdir}${datadir}/locale
+   rm -f $cleanupdir${bindir}/localedef
+   rm -rf $cleanupdir${datadir}/i18n
+   rm -rf $cleanupdir${libdir}/gconv
+   rm -rf $cleanupdir${localedir}
+   rm -rf $cleanupdir${datadir}/locale
if [ "${libdir}" != "${exec_prefix}/lib" ] && [ "${root_prefix}/lib" != 
"${exec_prefix}/lib" ]; then
-   if [ -d "${cleanupdir}${exec_prefix}/lib" ]; then
-   if [ -z "${ARCH_DYNAMIC_LOADER}" -o \
-! -e 
"${cleanupdir}${exec_prefix}/lib/${ARCH_DYNAMIC_LOADER}" ]; then
-   # error out if directory isn't empty
-   # this dir should only contain locale dir
-   # which has been deleted in the previous step
-   rmdir ${cleanupdir}${exec_prefix}/lib
+   if [ -d "$cleanupdir${exec_prefix}/lib" ]; then
+   if [ -z "${ARCH_DYNAMIC_LOADER}" -o \
+! -e 
"$cleanupdir${exec_prefix}/lib/${ARCH_DYNAMIC_LOADER}" ]; then
+   # error out if directory isn't empty
+   # this dir should only contain locale dir
+   # which has been deleted in the previous step
+   rmdir $cleanupdir${exec_prefix}/lib
+   fi
fi
-   fi
fi
 }
 
-- 
2.21.0

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


Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix systemd_preset_all

2019-07-04 Thread Peter Kjellerstedt
> -Original Message-
> From: ChenQi 
> Sent: den 3 juli 2019 03:49
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix
> systemd_preset_all
> 
> On 07/03/2019 05:04 AM, Peter Kjellerstedt wrote:
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
>  >> core-boun...@lists.openembedded.org> On Behalf Of ChenQi
> >> Sent: den 2 juli 2019 03:39
> >> To: Peter Kjellerstedt ; openembedded-
> >> c...@lists.openembedded.org
> >> Subject: Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix
> >> systemd_preset_all
> >>
> >> On 07/02/2019 07:34 AM, Peter Kjellerstedt wrote:
> >>>> -Original Message-
> >>>> From: openembedded-core-boun...@lists.openembedded.org
> >>  >>>> core-boun...@lists.openembedded.org> On Behalf Of Chen Qi
> >>>> Sent: den 1 juli 2019 06:16
> >>>> To: openembedded-core@lists.openembedded.org
> >>>> Subject: [OE-core] [PATCH V2 1/1] image.bbclass: fix
> >> systemd_preset_all
> >>>> Check the existence of systemd before using systemctl to preset
> >> units.
> >>>> This is because even if 'systemd' is in DISTRO_FEATURES, it's
> >> possible
> >>>> that systemd is not even installed. e.g. container-test-image in
> >>>> meta-selftest layer.
> >>>>
> >>>> As systemd DEPENDS on systemd-systemctl-native, the existence of
> >> systemd
> >>>> also ensures the existence of systemd-systemctl-native.
> >>>>
> >>>> This would fix the following test case when using systemd as the
> >> init
> >>>> manager.
> >>>>
> >>>> containerimage.ContainerImageTests.test_expected_files
> >>>>
> >>>> Also remove the IMAGE_EXTRADEPENDS setting, as nothing references
> >> this
> >>>> variable.
> >>>>
> >>>> Signed-off-by: Chen Qi 
> >>>> ---
> >>>>meta/classes/image.bbclass | 5 +++--
> >>>>1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/meta/classes/image.bbclass
> b/meta/classes/image.bbclass
> >>>> index d2b2fb9..7daa97e 100644
> >>>> --- a/meta/classes/image.bbclass
> >>>> +++ b/meta/classes/image.bbclass
> >>>> @@ -666,10 +666,11 @@ reproducible_final_image_task () {
> >>>>}
> >>>>
> >>>>systemd_preset_all () {
> >>>> -systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only
> >> preset-all
> >>>> +if [ -e ${IMAGE_ROOTFS}${root_prefix}/lib/systemd/systemd ];
> >> then
> >>> ^^
> >>> That should be ${systemd_system_unitdir}, which will also use the
> >> correct path
> >>> (it is /lib/systemd/system, not /lib/systemd/systemd).
> >> I'm checking the systemd binary under ${root_prefix}/lib/systemd,
> not
> >> the directory holding units.
> > Right, my bad. Still, then the path above should be
> > "${IMAGE_ROOTFS}${systemd_unitdir}/systemd".
> 
> In current OE, ${systemd_unitdir} = ${root_prefix}/lib/systemd.
> And in systemd recipe, we have:
> [ ! -e ${D}/init ] && ln -s ${rootlibexecdir}/systemd/systemd ${D}/init
> It does not write as `ln -s ${systemd_unitdir}/systemd/systemd'.
> I don't want to use a directory whose name indicates 'unit' when
> checking a binary.

Well, the name of the systemd_unitdir variable is misleading, as it 
does not in fact refer to a unit directory. The corresponding name in 
the systemd.pc file is systemdutildir, which I guess would have been 
a better name for the variable too (albeit a bit late to change it now).

Anyway, it is not very likely that the path to the systemd binary will  
change, so if you prefer to use the ${root_prefix}/lib/systemd path 
instead of ${systemd_unitdir}, then go ahead. 

> Regards,
> Chen Qi
> 
> >> Regards,
> >> Chen Qi
> >>
> >>>> +systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only
> >> preset-all
> >>>> +fi
> >>>>}
> >>>>
> >>>> -IMAGE_EXTRADEPENDS += "${@ 'systemd-systemctl-native' if
> >> bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and
> not
> >> bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False,
> d)
> >> else ''}"
> >>>>IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_preset_all;'
> if
> >> bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and
> not
> >> bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False,
> d)
> >> else ''} reproducible_final_image_task; "
> >>>>CVE_PRODUCT = ""
> >>>> --
> >>>> 1.9.1
> >>> //Peter
> > //Peter

//Peter

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


Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix systemd_preset_all

2019-07-02 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of ChenQi
> Sent: den 2 juli 2019 03:39
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix
> systemd_preset_all
> 
> On 07/02/2019 07:34 AM, Peter Kjellerstedt wrote:
> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
>  >> core-boun...@lists.openembedded.org> On Behalf Of Chen Qi
> >> Sent: den 1 juli 2019 06:16
> >> To: openembedded-core@lists.openembedded.org
> >> Subject: [OE-core] [PATCH V2 1/1] image.bbclass: fix
> systemd_preset_all
> >>
> >> Check the existence of systemd before using systemctl to preset
> units.
> >> This is because even if 'systemd' is in DISTRO_FEATURES, it's
> possible
> >> that systemd is not even installed. e.g. container-test-image in
> >> meta-selftest layer.
> >>
> >> As systemd DEPENDS on systemd-systemctl-native, the existence of
> systemd
> >> also ensures the existence of systemd-systemctl-native.
> >>
> >> This would fix the following test case when using systemd as the
> init
> >> manager.
> >>
> >>containerimage.ContainerImageTests.test_expected_files
> >>
> >> Also remove the IMAGE_EXTRADEPENDS setting, as nothing references
> this
> >> variable.
> >>
> >> Signed-off-by: Chen Qi 
> >> ---
> >>   meta/classes/image.bbclass | 5 +++--
> >>   1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> >> index d2b2fb9..7daa97e 100644
> >> --- a/meta/classes/image.bbclass
> >> +++ b/meta/classes/image.bbclass
> >> @@ -666,10 +666,11 @@ reproducible_final_image_task () {
> >>   }
> >>
> >>   systemd_preset_all () {
> >> -systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only
> preset-all
> >> +if [ -e ${IMAGE_ROOTFS}${root_prefix}/lib/systemd/systemd ];
> then
> >^^
> > That should be ${systemd_system_unitdir}, which will also use the
> correct path
> > (it is /lib/systemd/system, not /lib/systemd/systemd).
> 
> I'm checking the systemd binary under ${root_prefix}/lib/systemd, not
> the directory holding units.

Right, my bad. Still, then the path above should be
"${IMAGE_ROOTFS}${systemd_unitdir}/systemd".

> Regards,
> Chen Qi
> 
> >> +  systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only
> preset-all
> >> +fi
> >>   }
> >>
> >> -IMAGE_EXTRADEPENDS += "${@ 'systemd-systemctl-native' if
> bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and not
> bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False, d)
> else ''}"
> >>   IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_preset_all;' if
> bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and not
> bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False, d)
> else ''} reproducible_final_image_task; "
> >>
> >>   CVE_PRODUCT = ""
> >> --
> >> 1.9.1
> > //Peter

//Peter

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


Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix systemd_preset_all

2019-07-01 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Chen Qi
> Sent: den 1 juli 2019 06:16
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH V2 1/1] image.bbclass: fix systemd_preset_all
> 
> Check the existence of systemd before using systemctl to preset units.
> This is because even if 'systemd' is in DISTRO_FEATURES, it's possible
> that systemd is not even installed. e.g. container-test-image in
> meta-selftest layer.
> 
> As systemd DEPENDS on systemd-systemctl-native, the existence of systemd
> also ensures the existence of systemd-systemctl-native.
> 
> This would fix the following test case when using systemd as the init
> manager.
> 
>   containerimage.ContainerImageTests.test_expected_files
> 
> Also remove the IMAGE_EXTRADEPENDS setting, as nothing references this
> variable.
> 
> Signed-off-by: Chen Qi 
> ---
>  meta/classes/image.bbclass | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index d2b2fb9..7daa97e 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -666,10 +666,11 @@ reproducible_final_image_task () {
>  }
> 
>  systemd_preset_all () {
> -systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only preset-all
> +if [ -e ${IMAGE_ROOTFS}${root_prefix}/lib/systemd/systemd ]; then
  ^^
That should be ${systemd_system_unitdir}, which will also use the correct path 
(it is /lib/systemd/system, not /lib/systemd/systemd).

> + systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only preset-all
> +fi
>  }
> 
> -IMAGE_EXTRADEPENDS += "${@ 'systemd-systemctl-native' if 
> bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and not 
> bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False, d) else 
> ''}"
>  IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_preset_all;' if 
> bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and not 
> bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False, d) else 
> ''} reproducible_final_image_task; "
> 
>  CVE_PRODUCT = ""
> --
> 1.9.1

//Peter

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


Re: [OE-core] [PATCH] glibc: Fix locale DEPENDS

2019-07-01 Thread Peter Kjellerstedt
Are you thinking of gettext-minimal-native? It is used by gettext.bbclass if 
USE_NLS is “no”.

//Peter

From: openembedded-core-boun...@lists.openembedded.org 
 On Behalf Of Khem Raj
Sent: den 28 juni 2019 18:37
To: Joshua Watt 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] glibc: Fix locale DEPENDS



On Thu, Jun 27, 2019 at 9:54 AM Joshua Watt 
mailto:jpewhac...@gmail.com>> wrote:
gettext is required to generate the glibc locales in do_compile. If not
present, glibc will skip the generation which isn't reproducible.

Signed-off-by: Joshua Watt mailto:jpewhac...@gmail.com>>
---
 meta/recipes-core/glibc/glibc_2.29.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc_2.29.bb 
b/meta/recipes-core/glibc/glibc_2.29.bb
index 073d1533e37..c400ee10b0f 100644
--- a/meta/recipes-core/glibc/glibc_2.29.bb
+++ b/meta/recipes-core/glibc/glibc_2.29.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSES;md5=cfc0ed77a9f62fa62eded042ebe31d72 \
   file://posix/rxspencer/COPYRIGHT;md5=dc5485bb394a13b2332ec1c785f5d83a \
   
file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c"

-DEPENDS += "gperf-native bison-native make-native"
+DEPENDS += "gperf-native bison-native make-native gettext-native"

I think we have had this dependency proposed in past and one think that worries 
me is that it will cause serialization a bit more and can affect bulls times 
wasn’t there a minimal gettext at some point and I wonder if that could satisfy 
needs here


 PV = "2.29"

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


Re: [OE-core] [PATCH 1/1] devtool: warn user about multiple layer having the same base name

2019-06-28 Thread Peter Kjellerstedt
I had not realized the layer name in the devtool finish command supports 
abbreviations/patterns (whichever it is). My expectation from running `devtool 
finish foo meta` would be to update the foo recipe in the meta layer,  not that 
it should go looking for every layer called meta-something.

How useful is that support compared to be able to specify the exact layer name? 
Normally in this situation, I would typically expect to use an extra option,  
e.g., --abbrev or --regexp, to enable support for using loose matching.

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


[OE-core] [PATCH] glib-2.0: Update to 2.60.4

2019-06-26 Thread Peter Kjellerstedt
* For changes, see:
  https://gitlab.gnome.org/GNOME/glib/blob/glib-2-60/NEWS
* Remove backported CVE-2019-12450.patch.

Signed-off-by: Peter Kjellerstedt 
---
 .../glib-2.0/glib-2.0/CVE-2019-12450.patch| 62 ---
 ...{glib-2.0_2.60.3.bb => glib-2.0_2.60.4.bb} |  5 +-
 2 files changed, 2 insertions(+), 65 deletions(-)
 delete mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-12450.patch
 rename meta/recipes-core/glib-2.0/{glib-2.0_2.60.3.bb => glib-2.0_2.60.4.bb} 
(85%)

diff --git a/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-12450.patch 
b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-12450.patch
deleted file mode 100644
index 59e49195cc..00
--- a/meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-12450.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-glib-2.0: fix CVE-2019-12450
-
-Not in release 2.61.1.
-
-CVE: CVE-2019-12450
-
-Upstream-Status: Backport [github.com/GNOME/glib.git]
-Signed-off-by: Joe Slater 

-From d8f8f4d637ce43f8699ba94c9b7648beda0ca174 Mon Sep 17 00:00:00 2001
-From: Ondrej Holy 
-Date: Thu, 23 May 2019 10:41:53 +0200
-Subject: [PATCH] gfile: Limit access to files when copying
-
-file_copy_fallback creates new files with default permissions and
-set the correct permissions after the operation is finished. This
-might cause that the files can be accessible by more users during
-the operation than expected. Use G_FILE_CREATE_PRIVATE for the new
-files to limit access to those files.

- gio/gfile.c | 11 ++-
- 1 file changed, 6 insertions(+), 5 deletions(-)
-
-diff --git a/gio/gfile.c b/gio/gfile.c
-index 24b136d80..74b58047c 100644
 a/gio/gfile.c
-+++ b/gio/gfile.c
-@@ -3284,12 +3284,12 @@ file_copy_fallback (GFile  *source,
- out = (GOutputStream*)_g_local_file_output_stream_replace 
(_g_local_file_get_filename (G_LOCAL_FILE (destination)),
-FALSE, 
NULL,
-flags & 
G_FILE_COPY_BACKUP,
--   
G_FILE_CREATE_REPLACE_DESTINATION,
--   info,
-+   
G_FILE_CREATE_REPLACE_DESTINATION |
-+   
G_FILE_CREATE_PRIVATE, info,
-
cancellable, error);
-   else
- out = (GOutputStream*)_g_local_file_output_stream_create 
(_g_local_file_get_filename (G_LOCAL_FILE (destination)),
--  FALSE, 0, 
info,
-+  FALSE, 
G_FILE_CREATE_PRIVATE, info,
-   
cancellable, error);
- }
-   else if (flags & G_FILE_COPY_OVERWRITE)
-@@ -3297,12 +3297,13 @@ file_copy_fallback (GFile  *source,
-   out = (GOutputStream *)g_file_replace (destination,
-  NULL,
-  flags & G_FILE_COPY_BACKUP,
-- 
G_FILE_CREATE_REPLACE_DESTINATION,
-+ 
G_FILE_CREATE_REPLACE_DESTINATION |
-+ G_FILE_CREATE_PRIVATE,
-  cancellable, error);
- }
-   else
- {
--  out = (GOutputStream *)g_file_create (destination, 0, cancellable, 
error);
-+  out = (GOutputStream *)g_file_create (destination, 
G_FILE_CREATE_PRIVATE, cancellable, error);
- }
- 
-   if (!out)
--- 
-2.17.1
-
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.60.3.bb 
b/meta/recipes-core/glib-2.0/glib-2.0_2.60.4.bb
similarity index 85%
rename from meta/recipes-core/glib-2.0/glib-2.0_2.60.3.bb
rename to meta/recipes-core/glib-2.0/glib-2.0_2.60.4.bb
index 5942241de5..f7280090bb 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0_2.60.3.bb
+++ b/meta/recipes-core/glib-2.0/glib-2.0_2.60.4.bb
@@ -16,11 +16,10 @@ SRC_URI = 
"${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz \
file://0001-Do-not-write-bindir-into-pkg-config-files.patch \

file://0001-meson.build-do-not-hardcode-linux-as-the-host-system.patch \

file://0001-meson-do-a-build-time-check-for-strlcpy-before-attem.patch \
-   file://CVE-2019-12450.patch \
"
 
 SRC_URI_append_class-native = " file://relocate-modules.patch"
 SRC_URI_append_class-target = " file://glib-meson.cross"
 
-SRC_URI[md5sum] = "112a850caa8d2c21e24d4c9844e8b1fe"
-SRC_URI[sha256sum] = 
"04ab0d560d45790d055f50db2d69974eab8b693a77390075462c56e652b760b9"
+SRC_URI[md5sum] = "87e2c4973470811dfed3d6746c961488"
+SRC_URI[s

Re: [OE-core] [Warrior][ 15/19] texinfo-dummy-native: A little clean up of template.py

2019-06-24 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 24 juni 2019 12:23
> To: Adrian Bunk ; Armin Kuster 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [Warrior][ 15/19] texinfo-dummy-native: A little
> clean up of template.py
> 
> On Mon, 2019-06-24 at 10:38 +0300, Adrian Bunk wrote:
> > On Sun, Jun 23, 2019 at 08:54:14PM -0700, Armin Kuster wrote:
> > > From: Peter Kjellerstedt 
> > >
> > > This is mainly whitespace clean up, plus using the with statement
> > > when
> > > writing files.
> > > ...
> >
> > This patch and the next two look more like cleanup patches to me,
> > not changes that should go into a stable series.

Yes, this patch is pure cleanup, however, it is preparation for the next 
patch, which is not cleanup. The next patch fixes a problem with one of 
our recipes that uses the texinfo bbclass if the build path happens to 
contain the letter "E"...

> FWIW the package.bbclass change is being requested to allow people to
> stop patching the class...

Exactly.

> Cheers,
> 
> Richard

//Peter

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


[OE-core] [warrior][PATCH 3/3] package.bbclass: Clean up writing of runtime pkgdata files

2019-06-19 Thread Peter Kjellerstedt
From: Peter Kjellerstedt 

This introduces a variable, PKGDATA_VARS, that contains the names of
the variables that are to be output in the runtime pkgdata files.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---
 
This is a backport from master.

 meta/classes/package.bbclass | 56 
 1 file changed, 18 insertions(+), 38 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 4c0a859536..eef1f7b945 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1343,6 +1343,8 @@ EXPORT_FUNCTIONS package_name_hook
 
 PKGDESTWORK = "${WORKDIR}/pkgdata"
 
+PKGDATA_VARS = "PN PE PV PR PKGE PKGV PKGR LICENSE DESCRIPTION SUMMARY 
RDEPENDS RPROVIDES RRECOMMENDS RSUGGESTS RREPLACES RCONFLICTS SECTION PKG 
ALLOW_EMPTY FILES CONFFILES FILES_INFO pkg_postinst pkg_postrm pkg_preinst 
pkg_prerm"
+
 python emit_pkgdata() {
 from glob import glob
 import json
@@ -1447,48 +1449,26 @@ fi
 total_size += fstat.st_size
 d.setVar('FILES_INFO', json.dumps(files, sort_keys=True))
 
-subdata_file = pkgdatadir + "/runtime/%s" % pkg
-sf = open(subdata_file, 'w')
-write_if_exists(sf, pkg, 'PN')
-write_if_exists(sf, pkg, 'PE')
-write_if_exists(sf, pkg, 'PV')
-write_if_exists(sf, pkg, 'PR')
-write_if_exists(sf, pkg, 'PKGE')
-write_if_exists(sf, pkg, 'PKGV')
-write_if_exists(sf, pkg, 'PKGR')
-write_if_exists(sf, pkg, 'LICENSE')
-write_if_exists(sf, pkg, 'DESCRIPTION')
-write_if_exists(sf, pkg, 'SUMMARY')
-write_if_exists(sf, pkg, 'RDEPENDS')
-rprov = write_if_exists(sf, pkg, 'RPROVIDES')
-write_if_exists(sf, pkg, 'RRECOMMENDS')
-write_if_exists(sf, pkg, 'RSUGGESTS')
-write_if_exists(sf, pkg, 'RREPLACES')
-write_if_exists(sf, pkg, 'RCONFLICTS')
-write_if_exists(sf, pkg, 'SECTION')
-write_if_exists(sf, pkg, 'PKG')
-write_if_exists(sf, pkg, 'ALLOW_EMPTY')
-write_if_exists(sf, pkg, 'FILES')
-write_if_exists(sf, pkg, 'CONFFILES')
 process_postinst_on_target(pkg, d.getVar("MLPREFIX"))
 add_set_e_to_scriptlets(pkg)
-write_if_exists(sf, pkg, 'pkg_postinst')
-write_if_exists(sf, pkg, 'pkg_postrm')
-write_if_exists(sf, pkg, 'pkg_preinst')
-write_if_exists(sf, pkg, 'pkg_prerm')
-write_if_exists(sf, pkg, 'FILERPROVIDESFLIST')
-write_if_exists(sf, pkg, 'FILES_INFO')
-for dfile in (d.getVar('FILERPROVIDESFLIST_' + pkg) or "").split():
-write_if_exists(sf, pkg, 'FILERPROVIDES_' + dfile)
-
-write_if_exists(sf, pkg, 'FILERDEPENDSFLIST')
-for dfile in (d.getVar('FILERDEPENDSFLIST_' + pkg) or "").split():
-write_if_exists(sf, pkg, 'FILERDEPENDS_' + dfile)
-
-sf.write('%s_%s: %d\n' % ('PKGSIZE', pkg, total_size))
-sf.close()
+
+subdata_file = pkgdatadir + "/runtime/%s" % pkg
+with open(subdata_file, 'w') as sf:
+for var in (d.getVar('PKGDATA_VARS') or "").split():
+val = write_if_exists(sf, pkg, var)
+
+write_if_exists(sf, pkg, 'FILERPROVIDESFLIST')
+for dfile in (d.getVar('FILERPROVIDESFLIST_' + pkg) or "").split():
+write_if_exists(sf, pkg, 'FILERPROVIDES_' + dfile)
+
+write_if_exists(sf, pkg, 'FILERDEPENDSFLIST')
+for dfile in (d.getVar('FILERDEPENDSFLIST_' + pkg) or "").split():
+write_if_exists(sf, pkg, 'FILERDEPENDS_' + dfile)
+
+sf.write('%s_%s: %d\n' % ('PKGSIZE', pkg, total_size))
 
 # Symlinks needed for rprovides lookup
+rprov = d.getVar('RPROVIDES_%s' % pkg) or d.getVar('RPROVIDES')
 if rprov:
 for p in rprov.strip().split():
 subdata_sym = pkgdatadir + "/runtime-rprovides/%s/%s" % (p, 
pkg)
-- 
2.21.0

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


[OE-core] [warrior][PATCH 2/3] texinfo-dummy-native: Rewrite template.py to use argparse

2019-06-19 Thread Peter Kjellerstedt
From: Peter Kjellerstedt 

The original version of template.py parses the arguments manually. This
fails when looking for the -E option if, e.g., an -I option is specified
without any space before its argument, and that argument contains the
letter 'E'.

A minor difference to the original version is that it parsed the
arguments in the order they were specified on the command line whereas
this version will always handle -E before -o.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---
 
This is a backport from master.

 .../texinfo-dummy/template.py | 55 ++-
 1 file changed, 18 insertions(+), 37 deletions(-)

diff --git 
a/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py 
b/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
index fcc28548af..86c7c1811a 100644
--- a/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
+++ b/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
@@ -28,10 +28,8 @@
 # of the executable from argv[0] and emulate the corresponding program, so
 # multiple copies of this script will exist under different names.
 
-import sys, os
+import sys, os, argparse
 
-olong = "--output="
-Elong = "--macro-expand="
 
 this_binary = sys.argv[0].split("/")[-1]
 
@@ -61,18 +59,9 @@ complex_binaries = "makeinfo texi2any".split()
 
 valid_binaries = simple_binaries + complex_binaries
 
-# For generating blank output files.
-def touch_file(path):
-with open(path, "w"):
-pass
-
 assert this_binary in valid_binaries, \
this_binary + " is not one of " + ', '.join(valid_binaries)
 
-if "--version" in sys.argv:
-print(version_str)
-sys.exit(0)
-
 # For debugging
 log_interceptions = False
 if log_interceptions:
@@ -81,35 +70,27 @@ if log_interceptions:
 
 # Look through the options and flags, and if necessary, touch any output
 # files.
-arg_idx = 1
-while arg_idx < len(sys.argv):
-arg = sys.argv [arg_idx]
-
-if arg == "--":
-break
+p = argparse.ArgumentParser()
+if this_binary in complex_binaries:
+p.add_argument('-E', '--macro-expand', metavar='FILE')
+p.add_argument('-o', '--output', metavar='DEST')
+p.add_argument('--version', action='store_true')
 
-# Something like -I . can result in a need for this (specifically the .)
-elif len(arg) < 2:
-pass
-
-# Check if -o or --output is specified. These can be used at most once.
-elif arg[0] == '-' and arg[1] != '-' and arg[len(arg) - 1] == 'o':
-touch_file(sys.argv[arg_idx + 1])
-sys.exit(0)
-elif arg.startswith(olong):
-touch_file(arg.split("=")[1])
-sys.exit(0)
+args, unknown = p.parse_known_args()
 
-# Check for functionality that isn't implemented yet.
-else:
-assert arg[0] != '-' or arg[1] == '-' or 'E' not in arg or \
-   this_binary in simple_binaries, \
-   "-E option not yet supported" + stub_msg
+if args.version:
+print(version_str)
+sys.exit(0)
 
-assert not arg.startswith(Elong), \
-   Elong[:-1] + " option not yet supported" + stub_msg
+# Check for functionality that isn't implemented yet.
+assert not getattr(args, 'macro_expand', None), \
+"-E/--macro-expand option not yet supported" + stub_msg
 
-arg_idx += 1
+# Check if -o or --output is specified.
+if args.output:
+with open(args.output, 'w'):
+pass
+sys.exit(0)
 
 # The -o/--output option overrides the default. For makeinfo and texi2any,
 # that default is to look for a @setfilename command in the input file.
-- 
2.21.0

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


[OE-core] [warrior][PATCH 1/3] texinfo-dummy-native: A little clean up of template.py

2019-06-19 Thread Peter Kjellerstedt
From: Peter Kjellerstedt 

This is mainly whitespace clean up, plus using the with statement when
writing files.

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie 
---

This is a backport from master.

 .../texinfo-dummy/template.py | 63 +--
 1 file changed, 30 insertions(+), 33 deletions(-)

diff --git 
a/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py 
b/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
index e369f74455..fcc28548af 100644
--- a/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
+++ b/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
@@ -33,21 +33,20 @@ import sys, os
 olong = "--output="
 Elong = "--macro-expand="
 
-
-this_binary = sys.argv[0].split ("/")[-1]
+this_binary = sys.argv[0].split("/")[-1]
 
 # To be outputted if functionality that hasn't been stubbed yet is invoked.
 stub_msg = """
-This stand-in version of %s is not yet fully capable of emulating the real
-version from the GNU texinfo suite. If you see this message, file a bug report
-with details on the recipe that failed.
+This stand-in version of %s is not yet fully capable of emulating
+the real version from the GNU texinfo suite. If you see this message, file a
+bug report with details on the recipe that failed.
 """ % this_binary
 
 # Autotools setups query the version, so this is actually necessary. Some of
 # them (lookin' at you, glibc) actually look for the substring "GNU texinfo,"
 # so we put that substring in there without actually telling a lie.
-version_str = """ %s (fake texinfo, emulating GNU texinfo) 5.2
- 
+version_str = """%s (fake texinfo, emulating GNU texinfo) 5.2
+
 Super amazing version which is totally not fake in any way whatsoever.
 Copyright (C) 2014 Intel Corp. Distributed under the terms of the MIT
 license.
@@ -55,62 +54,61 @@ license.
 
 simple_binaries = "pod2texi texi2dvi pdftexi2dvi texindex texi2pdf \
txixml2texi install-info ginstall-info \
-   update-info-dir".split ()
+   update-info-dir".split()
 
 # These utilities use a slightly different set of options and flags.
-complex_binaries = "makeinfo texi2any".split ()
+complex_binaries = "makeinfo texi2any".split()
 
 valid_binaries = simple_binaries + complex_binaries
 
 # For generating blank output files.
-def touch_file (path):
-f = open (path, "w")
-f.close ()
+def touch_file(path):
+with open(path, "w"):
+pass
 
 assert this_binary in valid_binaries, \
-   this_binary + " is not one of " + ', '.join (valid_binaries)
+   this_binary + " is not one of " + ', '.join(valid_binaries)
 
 if "--version" in sys.argv:
 print(version_str)
-sys.exit (0)
+sys.exit(0)
 
 # For debugging
 log_interceptions = False
 if log_interceptions:
-f = open ("/tmp/intercepted_" + this_binary, "a")
-f.write (' '.join ([this_binary] + sys.argv[1:]) + '\n')
-f.close ()
+with open("/tmp/intercepted_" + this_binary, "a") as f:
+f.write(' '.join([this_binary] + sys.argv[1:]) + '\n')
 
 # Look through the options and flags, and if necessary, touch any output
 # files.
 arg_idx = 1
-while arg_idx < len (sys.argv):
+while arg_idx < len(sys.argv):
 arg = sys.argv [arg_idx]
-
+
 if arg == "--":
 break
-
+
 # Something like -I . can result in a need for this (specifically the .)
-elif len (arg) < 2:
+elif len(arg) < 2:
 pass
-
+
 # Check if -o or --output is specified. These can be used at most once.
-elif arg[0] == '-' and arg[1] != '-' and arg[len (arg) - 1] == 'o':
-touch_file (sys.argv[arg_idx + 1])
-sys.exit (0)
-elif arg.startswith (olong):
-touch_file (arg.split ("=")[1])
-sys.exit (0)
-
+elif arg[0] == '-' and arg[1] != '-' and arg[len(arg) - 1] == 'o':
+touch_file(sys.argv[arg_idx + 1])
+sys.exit(0)
+elif arg.startswith(olong):
+touch_file(arg.split("=")[1])
+sys.exit(0)
+
 # Check for functionality that isn't implemented yet.
 else:
 assert arg[0] != '-' or arg[1] == '-' or 'E' not in arg or \
this_binary in simple_binaries, \
"-E option not yet supported" + stub_msg
-
-assert not arg.startswith (Elong), \
+
+assert not arg.startswith(Elong), \
Elong[:-1] + " option not yet supported" + stub_msg
-
+
 arg_idx += 1
 
 # The -o/--output option overrides the default. For makeinfo and texi2any,
@@ -119,4 +117,3 @@ while arg_idx < len (sys.argv):
 assert this_binary in simple_binaries, \
"Don't know how to get default output file name from input file!" + \
stub_msg
-
-- 
2.21.0

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


Re: [OE-core] [PATCH] package.bbclass: Clean up writing of runtime pkgdata files

2019-06-05 Thread Peter Kjellerstedt
> -Original Message-
> From: Richard Purdie 
> Sent: den 5 juni 2019 16:07
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] package.bbclass: Clean up writing of
> runtime pkgdata files
> 
> On Wed, 2019-06-05 at 16:01 +0200, Peter Kjellerstedt wrote:
> > This introduces a variable, PKGDATA_VARS, that contains the names of
> > the variables that are to be output in the runtime pkgdata files.
> 
> Its a good cleanup, I just know how people are going to use this
> variable to write out all kind of other data into pkgdata :(

This was of course triggered by Rob Walton's recent attempt at adding 
HOMEPAGE and my own earlier attempt at adding SRC_URI. But is it a 
problem (for OE-Core) that this possibility exists? As long as you do 
not accept the addition of those variables into OE-Core, then nothing 
has changed for you (except that the code is now a bit more tidy).

However, for us it means I can get rid of the horrible hack we have 
that adds SRC_URI to the pkgdata files, and instead replace it with a 
simple variable addition in our distro configuration.

> Cheers,
> 
> Richard

//Peter

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


[OE-core] [PATCH] package.bbclass: Clean up writing of runtime pkgdata files

2019-06-05 Thread Peter Kjellerstedt
This introduces a variable, PKGDATA_VARS, that contains the names of
the variables that are to be output in the runtime pkgdata files.

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/package.bbclass | 56 
 1 file changed, 18 insertions(+), 38 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 0694855504..20d72bba79 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1349,6 +1349,8 @@ EXPORT_FUNCTIONS package_name_hook
 
 PKGDESTWORK = "${WORKDIR}/pkgdata"
 
+PKGDATA_VARS = "PN PE PV PR PKGE PKGV PKGR LICENSE DESCRIPTION SUMMARY 
RDEPENDS RPROVIDES RRECOMMENDS RSUGGESTS RREPLACES RCONFLICTS SECTION PKG 
ALLOW_EMPTY FILES CONFFILES FILES_INFO pkg_postinst pkg_postrm pkg_preinst 
pkg_prerm"
+
 python emit_pkgdata() {
 from glob import glob
 import json
@@ -1453,48 +1455,26 @@ fi
 total_size += fstat.st_size
 d.setVar('FILES_INFO', json.dumps(files, sort_keys=True))
 
-subdata_file = pkgdatadir + "/runtime/%s" % pkg
-sf = open(subdata_file, 'w')
-write_if_exists(sf, pkg, 'PN')
-write_if_exists(sf, pkg, 'PE')
-write_if_exists(sf, pkg, 'PV')
-write_if_exists(sf, pkg, 'PR')
-write_if_exists(sf, pkg, 'PKGE')
-write_if_exists(sf, pkg, 'PKGV')
-write_if_exists(sf, pkg, 'PKGR')
-write_if_exists(sf, pkg, 'LICENSE')
-write_if_exists(sf, pkg, 'DESCRIPTION')
-write_if_exists(sf, pkg, 'SUMMARY')
-write_if_exists(sf, pkg, 'RDEPENDS')
-rprov = write_if_exists(sf, pkg, 'RPROVIDES')
-write_if_exists(sf, pkg, 'RRECOMMENDS')
-write_if_exists(sf, pkg, 'RSUGGESTS')
-write_if_exists(sf, pkg, 'RREPLACES')
-write_if_exists(sf, pkg, 'RCONFLICTS')
-write_if_exists(sf, pkg, 'SECTION')
-write_if_exists(sf, pkg, 'PKG')
-write_if_exists(sf, pkg, 'ALLOW_EMPTY')
-write_if_exists(sf, pkg, 'FILES')
-write_if_exists(sf, pkg, 'CONFFILES')
 process_postinst_on_target(pkg, d.getVar("MLPREFIX"))
 add_set_e_to_scriptlets(pkg)
-write_if_exists(sf, pkg, 'pkg_postinst')
-write_if_exists(sf, pkg, 'pkg_postrm')
-write_if_exists(sf, pkg, 'pkg_preinst')
-write_if_exists(sf, pkg, 'pkg_prerm')
-write_if_exists(sf, pkg, 'FILERPROVIDESFLIST')
-write_if_exists(sf, pkg, 'FILES_INFO')
-for dfile in (d.getVar('FILERPROVIDESFLIST_' + pkg) or "").split():
-write_if_exists(sf, pkg, 'FILERPROVIDES_' + dfile)
-
-write_if_exists(sf, pkg, 'FILERDEPENDSFLIST')
-for dfile in (d.getVar('FILERDEPENDSFLIST_' + pkg) or "").split():
-write_if_exists(sf, pkg, 'FILERDEPENDS_' + dfile)
-
-sf.write('%s_%s: %d\n' % ('PKGSIZE', pkg, total_size))
-sf.close()
+
+subdata_file = pkgdatadir + "/runtime/%s" % pkg
+with open(subdata_file, 'w') as sf:
+for var in (d.getVar('PKGDATA_VARS') or "").split():
+val = write_if_exists(sf, pkg, var)
+
+write_if_exists(sf, pkg, 'FILERPROVIDESFLIST')
+for dfile in (d.getVar('FILERPROVIDESFLIST_' + pkg) or "").split():
+write_if_exists(sf, pkg, 'FILERPROVIDES_' + dfile)
+
+write_if_exists(sf, pkg, 'FILERDEPENDSFLIST')
+for dfile in (d.getVar('FILERDEPENDSFLIST_' + pkg) or "").split():
+write_if_exists(sf, pkg, 'FILERDEPENDS_' + dfile)
+
+sf.write('%s_%s: %d\n' % ('PKGSIZE', pkg, total_size))
 
 # Symlinks needed for rprovides lookup
+rprov = d.getVar('RPROVIDES_%s' % pkg) or d.getVar('RPROVIDES')
 if rprov:
 for p in rprov.strip().split():
 subdata_sym = pkgdatadir + "/runtime-rprovides/%s/%s" % (p, 
pkg)
-- 
2.21.0

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


Re: [OE-core] [meta-poky][PATCH v6 1/2] poky.conf: make systemd as default init manager

2019-06-03 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
>  On Behalf Of 
> kai.k...@windriver.com
> Sent: den 2 juni 2019 16:55
> To: richard.pur...@linuxfoundation.org
> Cc: p...@yoctoproject.org; openembedded-core@lists.openembedded.org
> Subject: [OE-core] [meta-poky][PATCH v6 1/2] poky.conf: make systemd as 
> default init manager
> 
> From: Kai Kang 
> 
> Introduce a new variable POKY_INIT_MANAGER and create 4 .inc files to
> configure init manager settings. Var POKY_INIT_MANAGER accepts 4 values:
> sysvinit, systemd, systemd-compat and mdev-busybox. Set systemd by
> default for DISTRO poky.  And set mdev-busybox for DISTRO poky-tiny
> which doesn't change its init manger settings.
> 
> [YOCTO #13031]
> 
> Signed-off-by: Kai Kang 
> ---
>  .../conf/distro/include/init-template-mdev-busybox.inc| 7 +++
>  .../conf/distro/include/init-template-systemd-compat.inc  | 7 +++
>  meta-poky/conf/distro/include/init-template-systemd.inc   | 5 +
>  meta-poky/conf/distro/include/init-template-sysvinit.inc  | 6 ++
>  meta-poky/conf/distro/poky-tiny.conf  | 8 +---
>  meta-poky/conf/distro/poky.conf   | 6 ++
>  6 files changed, 32 insertions(+), 7 deletions(-)
>  create mode 100644 
> meta-poky/conf/distro/include/init-template-mdev-busybox.inc
>  create mode 100644 
> meta-poky/conf/distro/include/init-template-systemd-compat.inc
>  create mode 100644 meta-poky/conf/distro/include/init-template-systemd.inc
>  create mode 100644 meta-poky/conf/distro/include/init-template-sysvinit.inc
> 
> diff --git a/meta-poky/conf/distro/include/init-template-mdev-busybox.inc 
> b/meta-poky/conf/distro/include/init-template-mdev-busybox.inc
> new file mode 100644
> index 00..b07d9de5b4
> --- /dev/null
> +++ b/meta-poky/conf/distro/include/init-template-mdev-busybox.inc
> @@ -0,0 +1,7 @@
> +# enable mdev/busybox for init
> +DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " systemd sysvinit"
> +VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
> +VIRTUAL-RUNTIME_init_manager = "busybox"
> +VIRTUAL-RUNTIME_initscripts = "initscripts"
> +VIRTUAL-RUNTIME_keymaps = "keymaps"
> +VIRTUAL-RUNTIME_login_manager = "busybox"
> diff --git a/meta-poky/conf/distro/include/init-template-systemd-compat.inc 
> b/meta-poky/conf/distro/include/init-template-systemd-compat.inc
> new file mode 100644
> index 00..22151f8866
> --- /dev/null
> +++ b/meta-poky/conf/distro/include/init-template-systemd-compat.inc
> @@ -0,0 +1,7 @@
> +# Don't append sysvinit to DISTRO_FEATURES here because it has been set
> +# in DISTRO_FEATURES_BACKFILL. And then this .inc file could be used by
> +# init-template-systemd.inc
> +DISTRO_FEATURES_append = " systemd"
> +VIRTUAL-RUNTIME_init_manager = "systemd"
> +VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
> +VIRTUAL-RUNTIME_login_manager = "shadow-base"
> diff --git a/meta-poky/conf/distro/include/init-template-systemd.inc 
> b/meta-poky/conf/distro/include/init-template-systemd.inc
> new file mode 100644
> index 00..d04847028c
> --- /dev/null
> +++ b/meta-poky/conf/distro/include/init-template-systemd.inc
> @@ -0,0 +1,5 @@
> +# Use systemd for system initialization
> +
> +require init-template-systemd-compat.inc
> +
> +DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"
> diff --git a/meta-poky/conf/distro/include/init-template-sysvinit.inc 
> b/meta-poky/conf/distro/include/init-template-sysvinit.inc
> new file mode 100644
> index 00..7725b30e1e
> --- /dev/null
> +++ b/meta-poky/conf/distro/include/init-template-sysvinit.inc
> @@ -0,0 +1,6 @@
> +# Use sysvinit for system initialization
> +DISTRO_FEATURES_append = " sysvinit"
> +DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " systemd"
> +VIRTUAL-RUNTIME_init_manager = "sysvinit"
> +VIRTUAL-RUNTIME_initscripts = "initscripts"
> +VIRTUAL-RUNTIME_login_manager = "busybox"
> diff --git a/meta-poky/conf/distro/poky-tiny.conf 
> b/meta-poky/conf/distro/poky-tiny.conf
> index 1f8b6e8ff3..8ba0b9a4bb 100644
> --- a/meta-poky/conf/distro/poky-tiny.conf
> +++ b/meta-poky/conf/distro/poky-tiny.conf
> @@ -81,13 +81,7 @@ DISTRO_FEATURES_append_libc-musl = " largefile"
>  DISTRO_FEATURES_class-native = "${DISTRO_FEATURES_DEFAULT} 
> ${POKY_DEFAULT_DISTRO_FEATURES}"
>  DISTRO_FEATURES_class-nativesdk = "${DISTRO_FEATURES_DEFAULT} 
> ${POKY_DEFAULT_DISTRO_FEATURES}"
> 
> -# enable mdev/busybox for init
> -VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
> -VIRTUAL-RUNTIME_login_manager = "busybox"
> -VIRTUAL-RUNTIME_init_manager = "busybox"
> -VIRTUAL-RUNTIME_initscripts = "initscripts"
> -VIRTUAL-RUNTIME_keymaps = "keymaps"
> -DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
> +POKY_INIT_MANAGER ?= "mdev-busybox"
> 
>  # FIXME: Consider adding "modules" to MACHINE_FEATURES and using that in
>  # packagegroup-core-base to select modutils-initscripts or not. Similar with 
> "net" and
> diff --git a/meta-poky/conf/distro/poky.conf 

Re: [OE-core] [PATCH] ca-certificates: Fix openssl runtime dependency

2019-05-29 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
>  On Behalf Of Richard Purdie
> Sent: den 29 maj 2019 01:24
> To: Andrei Gherzan ; 
> openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] ca-certificates: Fix openssl runtime dependency
> 
> On Tue, 2019-05-28 at 15:30 +0100, Andrei Gherzan wrote:
> > Since yocto thud, and more specifically since poky switched to
> > openssl 1.1 line, the openssl binary is provided by 'openssl-bin'.
> >
> > Signed-off-by: Andrei Gherzan 
> > ---
> >  .../recipes-support/ca-certificates/ca-certificates_20190110.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git 
> > a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb 
> > b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
> > index 4c0425302f..bc69c55daa 100644
> > --- a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
> > +++ b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
> > @@ -82,6 +82,6 @@ do_install_append_class-native () {
> >  SYSROOT="${D}${base_prefix}" ${D}${sbindir}/update-ca-certificates
> >  }
> >
> > -RDEPENDS_${PN} += "openssl"
> > +RDEPENDS_${PN} += "openssl-bin"
> 
> Doesn't work for ca-certificates-native:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/39/builds/638
> [amongst many other failures]

I assume the above can be fixed by instead using:

RDEPENDS_${PN}_append_class-target = " openssl-bin"

However, has there been any attempts at rectifying the situation where 
runtime dependencies on packages are turned into recipe dependencies 
for the native version of a recipe, which obviously does not work when 
the package name does not match a recipe name?

> Cheers,
> 
> Richard

//Peter

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


Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as default init manager

2019-05-24 Thread Peter Kjellerstedt
> -Original Message-
> From: Khem Raj  
> Sent: den 23 maj 2019 22:59
> To: Peter Kjellerstedt 
> Cc: kai.k...@windriver.com; openembedded-core@lists.openembedded.org; 
> richard.pur...@linuxfoundation.org
> Subject: Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as 
> default init manager
> 
> On Thu, May 23, 2019 at 1:41 PM Peter Kjellerstedt 
> <mailto:peter.kjellerst...@axis.com> wrote:
> > -Original Message-
> > From: mailto:openembedded-core-boun...@lists.openembedded.org  > mailto:core-boun...@lists.openembedded.org> On Behalf Of
> > mailto:kai.k...@windriver.com
> > Sent: den 23 maj 2019 10:26
> > To: mailto:richard.pur...@linuxfoundation.org
> > Cc: mailto:openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as
> > default init manager
> > 
> > From: Kai Kang <mailto:kai.k...@windriver.com>
> > 
> > Move configurations from local.conf.sample.extended to local.conf.sample
> > to make systemd as default init manager for poky.
> 
> If we're going to change the default init manager to be systemd, wouldn't 
> it be more appropriate to change the real default values in bitbake.conf 
> and http://packagegroup-core-boot.bb? And then include an example in 
> local.conf.sample.extended to show how to configure sysvinit as init 
> manager?
> 
> That would change it for Oe-core and other distributions as well which 
> is not the intention 

Ok, then I'd say the change belongs in poky.conf. Doing this kind of changes 
in local.conf.sample seems very wrong to me. Why? Because if I have an 
existing build tree it will not be affected, but if I setup a new tree with 
oe-init-build-env it will all of a sudden behave differently from the old 
tree. In my mind, local.conf.sample should only be used for things the user 
are likely to want to configure to adapt the build for his/her environment, 
not to define the distribution (that's what poky.conf is for).

//Peter

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


Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as default init manager

2019-05-23 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of
> kai.k...@windriver.com
> Sent: den 23 maj 2019 10:26
> To: richard.pur...@linuxfoundation.org
> Cc: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as
> default init manager
> 
> From: Kai Kang 
> 
> Move configurations from local.conf.sample.extended to local.conf.sample
> to make systemd as default init manager for poky.

If we're going to change the default init manager to be systemd, wouldn't 
it be more appropriate to change the real default values in bitbake.conf 
and packagegroup-core-boot.bb? And then include an example in 
local.conf.sample.extended to show how to configure sysvinit as init manager?

> 
> [YOCTO #13031]
> 
> Signed-off-by: Kai Kang 
> ---
>  meta-poky/conf/local.conf.sample  | 9 +
>  meta-poky/conf/local.conf.sample.extended | 9 -
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/meta-poky/conf/local.conf.sample b/meta-
> poky/conf/local.conf.sample
> index 9068e567dc..3a07105e44 100644
> --- a/meta-poky/conf/local.conf.sample
> +++ b/meta-poky/conf/local.conf.sample
> @@ -249,3 +249,12 @@ PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
>  # track the version of this file when it was generated. This can
> safely be ignored if
>  # this doesn't mean anything to you.
>  CONF_VERSION = "1"
> +
> +#
> +# Use systemd for system initialization
> +#
> +DISTRO_FEATURES_append = " systemd"
> +DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
> +VIRTUAL-RUNTIME_login_manager = "shadow-base"
> +VIRTUAL-RUNTIME_init_manager = "systemd"
> +VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
> diff --git a/meta-poky/conf/local.conf.sample.extended b/meta-
> poky/conf/local.conf.sample.extended
> index 26603debe6..e20fc5dbf3 100644
> --- a/meta-poky/conf/local.conf.sample.extended
> +++ b/meta-poky/conf/local.conf.sample.extended
> @@ -377,12 +377,3 @@ DISTRO_FEATURES_remove = "x11"
>  #VIRTUAL-RUNTIME_initscripts = "initscripts"
>  #VIRTUAL-RUNTIME_keymaps = "keymaps"
>  #DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
> -
> -#
> -# Use systemd for system initialization
> -#
> -#DISTRO_FEATURES_append = " systemd"
> -#DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
> -#VIRTUAL-RUNTIME_login_manager = "shadow-base"
> -#VIRTUAL-RUNTIME_init_manager = "systemd"
> -#VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
> --
> 2.18.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/2] texinfo-dummy-native: Rewrite template.py to use argparse

2019-05-23 Thread Peter Kjellerstedt
The original version of template.py parses the arguments manually. This
fails when looking for the -E option if, e.g., an -I option is specified
without any space before its argument, and that argument contains the
letter 'E'.

A minor difference to the original version is that it parsed the
arguments in the order they were specified on the command line whereas
this version will always handle -E before -o.

Signed-off-by: Peter Kjellerstedt 
---
 .../texinfo-dummy/template.py | 55 ++-
 1 file changed, 18 insertions(+), 37 deletions(-)

diff --git 
a/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py 
b/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
index fcc28548af..86c7c1811a 100644
--- a/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
+++ b/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
@@ -28,10 +28,8 @@
 # of the executable from argv[0] and emulate the corresponding program, so
 # multiple copies of this script will exist under different names.
 
-import sys, os
+import sys, os, argparse
 
-olong = "--output="
-Elong = "--macro-expand="
 
 this_binary = sys.argv[0].split("/")[-1]
 
@@ -61,18 +59,9 @@ complex_binaries = "makeinfo texi2any".split()
 
 valid_binaries = simple_binaries + complex_binaries
 
-# For generating blank output files.
-def touch_file(path):
-with open(path, "w"):
-pass
-
 assert this_binary in valid_binaries, \
this_binary + " is not one of " + ', '.join(valid_binaries)
 
-if "--version" in sys.argv:
-print(version_str)
-sys.exit(0)
-
 # For debugging
 log_interceptions = False
 if log_interceptions:
@@ -81,35 +70,27 @@ if log_interceptions:
 
 # Look through the options and flags, and if necessary, touch any output
 # files.
-arg_idx = 1
-while arg_idx < len(sys.argv):
-arg = sys.argv [arg_idx]
-
-if arg == "--":
-break
+p = argparse.ArgumentParser()
+if this_binary in complex_binaries:
+p.add_argument('-E', '--macro-expand', metavar='FILE')
+p.add_argument('-o', '--output', metavar='DEST')
+p.add_argument('--version', action='store_true')
 
-# Something like -I . can result in a need for this (specifically the .)
-elif len(arg) < 2:
-pass
-
-# Check if -o or --output is specified. These can be used at most once.
-elif arg[0] == '-' and arg[1] != '-' and arg[len(arg) - 1] == 'o':
-touch_file(sys.argv[arg_idx + 1])
-sys.exit(0)
-elif arg.startswith(olong):
-touch_file(arg.split("=")[1])
-sys.exit(0)
+args, unknown = p.parse_known_args()
 
-# Check for functionality that isn't implemented yet.
-else:
-assert arg[0] != '-' or arg[1] == '-' or 'E' not in arg or \
-   this_binary in simple_binaries, \
-   "-E option not yet supported" + stub_msg
+if args.version:
+print(version_str)
+sys.exit(0)
 
-assert not arg.startswith(Elong), \
-   Elong[:-1] + " option not yet supported" + stub_msg
+# Check for functionality that isn't implemented yet.
+assert not getattr(args, 'macro_expand', None), \
+"-E/--macro-expand option not yet supported" + stub_msg
 
-arg_idx += 1
+# Check if -o or --output is specified.
+if args.output:
+with open(args.output, 'w'):
+pass
+sys.exit(0)
 
 # The -o/--output option overrides the default. For makeinfo and texi2any,
 # that default is to look for a @setfilename command in the input file.
-- 
2.21.0

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


[OE-core] [PATCH 1/2] texinfo-dummy-native: A little clean up of template.py

2019-05-23 Thread Peter Kjellerstedt
This is mainly whitespace clean up, plus using the with statement when
writing files.

Signed-off-by: Peter Kjellerstedt 
---
 .../texinfo-dummy/template.py | 63 +--
 1 file changed, 30 insertions(+), 33 deletions(-)

diff --git 
a/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py 
b/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
index e369f74455..fcc28548af 100644
--- a/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
+++ b/meta/recipes-extended/texinfo-dummy-native/texinfo-dummy/template.py
@@ -33,21 +33,20 @@ import sys, os
 olong = "--output="
 Elong = "--macro-expand="
 
-
-this_binary = sys.argv[0].split ("/")[-1]
+this_binary = sys.argv[0].split("/")[-1]
 
 # To be outputted if functionality that hasn't been stubbed yet is invoked.
 stub_msg = """
-This stand-in version of %s is not yet fully capable of emulating the real
-version from the GNU texinfo suite. If you see this message, file a bug report
-with details on the recipe that failed.
+This stand-in version of %s is not yet fully capable of emulating
+the real version from the GNU texinfo suite. If you see this message, file a
+bug report with details on the recipe that failed.
 """ % this_binary
 
 # Autotools setups query the version, so this is actually necessary. Some of
 # them (lookin' at you, glibc) actually look for the substring "GNU texinfo,"
 # so we put that substring in there without actually telling a lie.
-version_str = """ %s (fake texinfo, emulating GNU texinfo) 5.2
- 
+version_str = """%s (fake texinfo, emulating GNU texinfo) 5.2
+
 Super amazing version which is totally not fake in any way whatsoever.
 Copyright (C) 2014 Intel Corp. Distributed under the terms of the MIT
 license.
@@ -55,62 +54,61 @@ license.
 
 simple_binaries = "pod2texi texi2dvi pdftexi2dvi texindex texi2pdf \
txixml2texi install-info ginstall-info \
-   update-info-dir".split ()
+   update-info-dir".split()
 
 # These utilities use a slightly different set of options and flags.
-complex_binaries = "makeinfo texi2any".split ()
+complex_binaries = "makeinfo texi2any".split()
 
 valid_binaries = simple_binaries + complex_binaries
 
 # For generating blank output files.
-def touch_file (path):
-f = open (path, "w")
-f.close ()
+def touch_file(path):
+with open(path, "w"):
+pass
 
 assert this_binary in valid_binaries, \
-   this_binary + " is not one of " + ', '.join (valid_binaries)
+   this_binary + " is not one of " + ', '.join(valid_binaries)
 
 if "--version" in sys.argv:
 print(version_str)
-sys.exit (0)
+sys.exit(0)
 
 # For debugging
 log_interceptions = False
 if log_interceptions:
-f = open ("/tmp/intercepted_" + this_binary, "a")
-f.write (' '.join ([this_binary] + sys.argv[1:]) + '\n')
-f.close ()
+with open("/tmp/intercepted_" + this_binary, "a") as f:
+f.write(' '.join([this_binary] + sys.argv[1:]) + '\n')
 
 # Look through the options and flags, and if necessary, touch any output
 # files.
 arg_idx = 1
-while arg_idx < len (sys.argv):
+while arg_idx < len(sys.argv):
 arg = sys.argv [arg_idx]
-
+
 if arg == "--":
 break
-
+
 # Something like -I . can result in a need for this (specifically the .)
-elif len (arg) < 2:
+elif len(arg) < 2:
 pass
-
+
 # Check if -o or --output is specified. These can be used at most once.
-elif arg[0] == '-' and arg[1] != '-' and arg[len (arg) - 1] == 'o':
-touch_file (sys.argv[arg_idx + 1])
-sys.exit (0)
-elif arg.startswith (olong):
-touch_file (arg.split ("=")[1])
-sys.exit (0)
-
+elif arg[0] == '-' and arg[1] != '-' and arg[len(arg) - 1] == 'o':
+touch_file(sys.argv[arg_idx + 1])
+sys.exit(0)
+elif arg.startswith(olong):
+touch_file(arg.split("=")[1])
+sys.exit(0)
+
 # Check for functionality that isn't implemented yet.
 else:
 assert arg[0] != '-' or arg[1] == '-' or 'E' not in arg or \
this_binary in simple_binaries, \
"-E option not yet supported" + stub_msg
-
-assert not arg.startswith (Elong), \
+
+assert not arg.startswith(Elong), \
Elong[:-1] + " option not yet supported" + stub_msg
-
+
 arg_idx += 1
 
 # The -o/--output option overrides the default. For makeinfo and texi2any,
@@ -119,4 +117,3 @@ while arg_idx < len (sys.argv):
 assert this_binary in simple_binaries, \
"Don't know how to get default output file name from input file!" + \
stub_msg
-
-- 
2.21.0

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


Re: [OE-core] [PATCH 17/37] libpcre2: upgrade 10.32 -> 10.33

2019-05-17 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Alexander Kanavin
> Sent: den 17 maj 2019 20:12
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 17/37] libpcre2: upgrade 10.32 -> 10.33
> 
> Signed-off-by: Alexander Kanavin 
> ---
>  .../{libpcre2_10.32.bb => libpcre2_10.33.bb}  | 46 +--
>  1 file changed, 43 insertions(+), 3 deletions(-)
>  rename meta/recipes-support/libpcre/{libpcre2_10.32.bb =>
> libpcre2_10.33.bb} (61%)
> 
> diff --git a/meta/recipes-support/libpcre/libpcre2_10.32.bb
> b/meta/recipes-support/libpcre/libpcre2_10.33.bb
> similarity index 61%
> rename from meta/recipes-support/libpcre/libpcre2_10.32.bb
> rename to meta/recipes-support/libpcre/libpcre2_10.33.bb
> index 3a0aa53029f..604f81a8f33 100644
> --- a/meta/recipes-support/libpcre/libpcre2_10.32.bb
> +++ b/meta/recipes-support/libpcre/libpcre2_10.33.bb
> @@ -1,3 +1,43 @@

A bit too much automation here I guess. ;)
Replace the below with an appropriate:

License-Update: Copyright years updated

in the commit message.

> +# FIXME: the LIC_FILES_CHKSUM values have been updated by 'devtool upgrade'.
> +# The following is the difference between the old and the new license text.
> +# Please update the LICENSE value if needed, and summarize the changes in
> +# the commit message via 'License-Update:' tag.
> +# (example: 'License-Update: copyright years updated.')
> +#
> +# The changes:
> +#
> +# --- LICENCE
> +# +++ LICENCE
> +# @@ -26,7 +26,7 @@
> +#  University of Cambridge Computing Service,
> +#  Cambridge, England.
> +#
> +# -Copyright (c) 1997-2018 University of Cambridge
> +# +Copyright (c) 1997-2019 University of Cambridge
> +#  All rights reserved.
> +#
> +#
> +# @@ -37,7 +37,7 @@
> +#  Email local part: hzmester
> +#  Email domain: freemail.hu
> +#
> +# -Copyright(c) 2010-2018 Zoltan Herczeg
> +# +Copyright(c) 2010-2019 Zoltan Herczeg
> +#  All rights reserved.
> +#
> +#
> +# @@ -48,7 +48,7 @@
> +#  Email local part: hzmester
> +#  Email domain: freemail.hu
> +#
> +# -Copyright(c) 2009-2018 Zoltan Herczeg
> +# +Copyright(c) 2009-2019 Zoltan Herczeg
> +#  All rights reserved.
> +#
> +#
> +#
> +#
> +
>  DESCRIPTION = "There are two major versions of the PCRE library. The \
>  newest version is PCRE2, which is a re-working of the original PCRE \
>  library to provide an entirely new API. The original, very widely \
> @@ -8,14 +48,14 @@ SUMMARY = "Perl Compatible Regular Expressions version 2"
>  HOMEPAGE = "http://www.pcre.org;
>  SECTION = "devel"
>  LICENSE = "BSD"
> -LIC_FILES_CHKSUM = "file://LICENCE;md5=cf66d307bf03bae65d413eb7a8e603a0"
> +LIC_FILES_CHKSUM = "file://LICENCE;md5=b1588d3bb4cb0e1f5a597d908f8c5b37"
> 
>  SRC_URI = "https://ftp.pcre.org/pub/pcre/pcre2-${PV}.tar.bz2 \
> file://pcre-cross.patch \
>  "
> 
> -SRC_URI[md5sum] = "8a096287153fb994970df3570e90fcb5"
> -SRC_URI[sha256sum] = 
> "f29e89cc5de813f45786580101aaee3984a65818631d4ddbda7b32f699b87c2e"
> +SRC_URI[md5sum] = "80b355f2dce909a2e2424f5c79eddb44"
> +SRC_URI[sha256sum] = 
> "35514dff0ccdf02b55bd2e9fa586a1b9d01f62332c3356e379eabb75f789d8aa"
> 
>  CVE_PRODUCT = "pcre2"
> 
> --
> 2.17.1

//Peter

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


Re: [OE-core] [master][warrior][PATCH] systemd: Use PACKAGECONFIG definition to depend on libnss-myhostname

2019-05-08 Thread Peter Kjellerstedt
*ping*

//Peter

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Peter Kjellerstedt
> Sent: den 12 april 2019 18:15
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [master][warrior][PATCH] systemd: Use PACKAGECONFIG
> definition to depend on libnss-myhostname
> 
> Rather than adding the dependency on libnss-myhostname to
> RDEPENDS_${PN} if the myhostname PACKAGECONFIG is set, add the runtime
> dependency to myhostname's PACKAGECONFIG definition.
> 
> Signed-off-by: Peter Kjellerstedt 
> ---
> 
> This is just a clean up of the last commit to systemd.
> 
> meta/recipes-core/systemd/systemd_241.bb | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd_241.bb b/meta/recipes-
> core/systemd/systemd_241.bb
> index 3a58f44a3b..562cdc3316 100644
> --- a/meta/recipes-core/systemd/systemd_241.bb
> +++ b/meta/recipes-core/systemd/systemd_241.bb
> @@ -144,7 +144,7 @@ PACKAGECONFIG[lz4] = "-Dlz4=true,-Dlz4=false,lz4"
>  PACKAGECONFIG[machined] = "-Dmachined=true,-Dmachined=false"
>  PACKAGECONFIG[manpages] = "-Dman=true,-Dman=false,libxslt-native
> xmlto-native docbook-xml-dtd4-native docbook-xsl-stylesheets-native"
>  PACKAGECONFIG[microhttpd] = "-Dmicrohttpd=true,-
> Dmicrohttpd=false,libmicrohttpd"
> -PACKAGECONFIG[myhostname] = "-Dnss-myhostname=true,-Dnss-
> myhostname=false"
> +PACKAGECONFIG[myhostname] = "-Dnss-myhostname=true,-Dnss-
> myhostname=false,,libnss-myhostname"
>  PACKAGECONFIG[networkd] = "-Dnetworkd=true,-Dnetworkd=false"
>  PACKAGECONFIG[nss] = "-Dnss-systemd=true,-Dnss-systemd=false"
>  PACKAGECONFIG[nss-mymachines] = "-Dnss-mymachines=true,-Dnss-
> mymachines=false"
> @@ -547,7 +547,6 @@ FILES_${PN}-dev += "${base_libdir}/security/*.la
> ${datadir}/dbus-1/interfaces/ $
>  RDEPENDS_${PN} += "kmod dbus util-linux-mount util-linux-umount udev
> (= ${EXTENDPKGV}) util-linux-agetty util-linux-fsck"
>  RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'serial-
> getty-generator', '', 'systemd-serialgetty', d)}"
>  RDEPENDS_${PN} += "volatile-binds update-rc.d systemd-conf"
> -RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'myhostname',
> 'libnss-myhostname', '', d)}"
> 
>  RRECOMMENDS_${PN} += "systemd-extra-utils \
>systemd-compat-units udev-hwdb \
> --
> 2.12.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [OE-Core][PATCH] systemd: Default to non-stateless images

2019-05-06 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Jonas Bonn
> Sent: den 6 maj 2019 06:54
> To: Alex Kiernan ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [OE-Core][PATCH] systemd: Default to non-
> stateless images
> 
> Hi Alex,
> 
> The below is fine and looks good.  The one thing that bothers me about
> this is that "stateless" isn't really a property of the "distro",
> rather
> it's a property of the image/machine.  I suspect, in the same sense
> that
> we have readonly-rootfs, that we should probably have image features
> "stateless-rootfs" (no /etc, no /var) and "volatile-rootfs" (no /var).
> 
> Furthermore, if you want to boot with 'ro' on the command-line, I
> really
> think you need to build your image with the "readonly-rootfs" feature
> set.  The default should be writable+persistent /etc as that's the
> configuration used 99% of the time (currently).  "readonly-rootfs" does
> a bit more than just creating machine-id but it's all relevant to the
> 'ro' case where /etc isn't writable.
> 
> Just for clarification:
> 
> i)  volatile-rootfs:  means there's no point in prepopulating /var
> because it's on a tmpfs and needs to be populated at boot time

This doesn't really say anything about the state of the rootfs outside 
of /var, i.e., is it writable or read-only?

> ii)  stateless-rootfs:  means there's no point in prepopulating neither
> /etc nor /var because they are on a tmpfs and need to be populated at
> boot time

Same here.

> iii)  readonly-rootfs:  means that /etc is really not writable so it's
> important that: the systemd first-boot stuff needs to be done at build
> time:  machine-id, unit files set up, all tmpfiles.d snippets that
> touch /etc and /var need to be done in advance.
> 
> /Jonas

Maybe we need some more generic way of describing the intended 
structure of the image? E.g., what are the expected behavior of 
/etc, /var and the rest of the rootfs? For each they can typically 
be "read-only", "persistent" (writable and survives reboots) or 
"volatile" (writable, but doesn't survive a reboot).

//Peter

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


Re: [OE-core] [OE-Core][PATCH v6 0/6] systemd stateless configuration

2019-05-03 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Jonas Bonn
> Sent: den 3 maj 2019 14:55
> To: Alex Kiernan ; OE-core  c...@lists.openembedded.org>
> Subject: Re: [OE-core] [OE-Core][PATCH v6 0/6] systemd stateless
> configuration
> 
> Hi Alex,
> 
> On 03/05/2019 10:37, Alex Kiernan wrote:
> > On Thu, May 2, 2019 at 10:10 PM Alex Kiernan 
> > wrote:
> >>
> >> This patch set is largely Jonas Bonn's to move towards a "stateless"
> >> configuration:
> >>
> >>These patches make some modifications to systemd with the long-
> >>term goal of being able to run OE in systemd's "stateless" 
> >>configuration.  "Stateless" boils down to building an image 
> >>with empty /etc and /var directories so that volatile (tmpfs) 
> >>filesystems can be mounted there; this requires that the 
> >>system subsequently be able to populate these directories 
> >>dynamically, which systemd mostly takes care of if things are
> >>done right.
> >>
> >>In these patches:
> >>i)   Don't include machine-id in writable images so that 
> >> systemd can run its first-boot machinery
> >>ii)  Move systemd configuration files out of /etc
> >>iii) Allow systemd to dynamically enable services and 
> >> populate /etc/systemd/system via the presets mechanism
> >>
> >>There's a long way to go to get to a working "stateless"
> >>configuration.  Getting to a "volatile" system (just empty 
> >>/var) should be easier and I'll post patches moving things in 
> >>that direction shortly.
> >>
> >> However as a result of the systemd 242 upgrade, which includes
> >> 01d2041e41f4 ("meson: stop creating enablement symlinks in /etc 
> >> during installation"), services such as systemd-networkd are no 
> >> longer enabled in images.
> >>
> >> This patch set fixes this problem in addition to satisfying the 
> >> goal of moving towards "stateless" configurations.
> >>
> >> The issue with respect to image testing during CI was caused by
> >> systemd-time-wait-sync.service being enabled due to the lack of
> >> a default preset policy:
> >>
> >> https://www.freedesktop.org/wiki/Software/systemd/Preset/#howto
> >>
> >> Changes in v6:
> >> - switch configuration to simple overrides in /usr/lib/systemd/*.conf.d
> >> - make systemd RRECOMMENDS rather than RDEPENDS on systemd-conf
> >> - don't exit in postinst as when that executes we're actually a
> >>concatenation of all fragments
> >> - validate SYSTEMD_AUTO_ENABLE is `enable` or `disable`
> >> - rewrite systemctl-native in Python
> >> - moved systemctl preset-all to IMAGE_PREPROCESS so it runs after ROOTFS,
> >>run for all images, not just read-only
> >>
> >> Changes in v5:
> >> - rebased for systemd 242
> >> - install default preset distribution policy of "enable nothing"
> >>
> >> Alex Kiernan (3):
> >>systemd-conf: simplify creation of machine-specific configuration
> >>systemctl-native: Rewrite in Python supporting preset-all and mask
> >>image: call systemctl preset-all for images
> >>
> >> Jonas Bonn (3):
> >>systemd: don't build firstboot by default
> >>systemd: do not create machine-id
> >>systemd: create preset files instead of installing in image
> >>
> >>   meta/classes/image.bbclass|   9 +-
> >>   meta/classes/rootfs-postcommands.bbclass  |   6 +
> >>   meta/classes/systemd.bbclass  |  41 +-
> >>   .../systemd/systemd-conf/journald.conf|   3 +
> >>   .../systemd/systemd-conf/logind.conf  |   2 +
> >>   .../systemd/systemd-conf/system.conf  |   2 +
> >>   .../systemd/systemd-conf/system.conf-qemuall  |   3 +
> >>   meta/recipes-core/systemd/systemd-conf_242.bb |  61 +--
> >>   .../systemd/systemd-systemctl/systemctl   | 476 ++
> >>   .../systemd/systemd/99-default.preset |   1 +
> >>   meta/recipes-core/systemd/systemd_242.bb  |  26 +-
> >>   11 files changed, 360 insertions(+), 270 deletions(-)
> >>   create mode 100644 meta/recipes-core/systemd/systemd-conf/journald.conf
> >>   create mode 100644 meta/recipes-core/systemd/systemd-conf/logind.conf
> >>   create mode 100644 meta/recipes-core/systemd/systemd-conf/system.conf
> >>   create mode 100644 
> >> meta/recipes-core/systemd/systemd-conf/system.conf-qemuall
> >>   create mode 100644 meta/recipes-core/systemd/systemd/99-default.preset
> >
> > Sigh...
> >
> > this still has issues - if you boot with `ro` on the kernel command
> > line and without an initramfs, then / is read-only when systemd
> > starts and it basically refuses to do anything:
> >
> > [7.222134] systemd[1]: No hostname configured.
> > [7.227266] systemd[1]: Set hostname to .
> > [7.232622] systemd[1]: System cannot boot: Missing /etc/machine-id and 
> > /etc is mounted read-only.
> > [7.241750] systemd[1]: Booting up is supported only when:
> > [7.247362] systemd[1]: 1) 

Re: [OE-core] [PATCH v3] dnf: Enable nativesdk

2019-04-24 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Lei Maohui
> Sent: den 24 april 2019 05:38
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH v3] dnf: Enable nativesdk
> 
> Make dnf work on nativesdk environment.
> 
> Signed-off-by: Zheng Ruoqin 
> Signed-off-by: Lei Maohui 
> ---
>  meta/recipes-devtools/dnf/dnf_4.2.2.bb | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/dnf/dnf_4.2.2.bb b/meta/recipes-
> devtools/dnf/dnf_4.2.2.bb
> index 3970b41..159d7e9 100644
> --- a/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> +++ b/meta/recipes-devtools/dnf/dnf_4.2.2.bb
> @@ -26,7 +26,7 @@ EXTRA_OECMAKE = " -DWITH_MAN=0 -
> DPYTHON_INSTALL_DIR=${PYTHON_SITEPACKAGES_DIR} -
> 
>  BBCLASSEXTEND = "native nativesdk"
> 
> -RDEPENDS_${PN}_class-target += " \
> +RDEPENDS_${PN} += " \
>python3-core \
>python3-codecs \
>python3-netclient \
> @@ -49,6 +49,8 @@ RDEPENDS_${PN}_class-target += " \
>python3-gpg \
>"
> 
> +RDEPENDS_${PN}_class-native = ""
> +
>  RRECOMMENDS_${PN}_class-target += "gnupg"
> 
>  # Create a symlink called 'dnf' as 'make install' does not do it, but
> @@ -66,6 +68,11 @@ do_install_append_class-native() {
>  RPM_NO_CHROOT_FOR_SCRIPTS=1
>  }
> 
> +do_install_append_class-nativesdk() {
> +create_wrapper ${D}/${bindir}/dnf \
> +RPM_CONFIGDIR=${SDKPATHNATIVE}${libdir_nativesdk}/rpm \
> +RPM_NO_CHROOT_FOR_SCRIPTS=1 }

Move the "}" above to a line of its own.

> +
>  SYSTEMD_SERVICE_${PN} = "dnf-makecache.service dnf-makecache.timer \
>   dnf-automatic.service dnf-automatic.timer \
>   dnf-automatic-download.service dnf-automatic-
> download.timer \
> --
> 2.7.4

//Peter

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


Re: [OE-core] [PATCH] pseudo: Update to gain key bugfixes

2019-04-17 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of
> richard.pur...@linuxfoundation.org
> Sent: den 12 april 2019 10:18
> To: Seebs 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] pseudo: Update to gain key bugfixes
> 
> On Wed, 2019-04-10 at 18:59 -0500, Seebs wrote:
> > On Thu, 11 Apr 2019 00:12:54 +0100
> > Richard Purdie  wrote:
> >
> > > -SRCREV = "6294b344e5140f5467e6860f45a174440015304e"
> > > +SRCREV = "6ebc7d6bc8ab973d0ba949eeb363821811ce8dc5"
> >
> > I would sort of recommend one of the two commits since then -- one
> > may
> > fix the .NET startup failures, and the other fixes warnings that this
> > one introduced and I forgot to fix. But I'm also okay with this one.
> 
> That is good news. I've tested and updated to the later revision,
> thanks!
> 
> Cheers,
> 
> Richard

One of our developers, who has been especially affected by this 
problem, reported that he was still having problems building a 
couple of recipes even with the latest version of pseudo. After 
some debugging it was determined that the problem was due to the 
Debian version of coreutils that he was using. When he downgraded 
from 8.30-3 to 8.30-1 the problems he was seeing went away. The 
changelog for the reverted changes indicate that pseudo will 
need to be made aware about what they are doing:

,
| coreutils (8.30-3) unstable; urgency=medium
| 
|   * Fix renameat2 patch (Closes: #923420)
| 
|  -- Michael Stone   Thu, 28 Feb 2019 10:30:31 -0500
| 
| coreutils (8.30-2) unstable; urgency=medium
| 
|   * Use renameat2 glibc function that can be intercepted by fakechroot
| (Closes: #915559)
|   * Above requires autoreconf turned on again
| 
|  -- Michael Stone   Tue, 26 Feb 2019 07:15:19 -0500
`

//Peter

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


Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings

2019-04-17 Thread Peter Kjellerstedt
Yes, that definitely looks wrong. Fortunately for us, we are only using SoCs 
based on Cortex A53 so far so it is not something that has affected us (yet)…

Oh, and for some more messy fun, take a look at tune-cortexa32.inc. Cortex A32 
uses ARMv8 but only supports aarch32. However, the tune file says to use 
aarch64, which makes me believe that no one is actually using that tune file… I 
gave up trying to correct is as it is not currently possible to configure a 
tune to use ARMv8 without aarch64 and I don’t know if it is worth the effort 
until someone actually has a SoC based on Cortex A32 they want to build for.

//Peter

From: Martin Jansa 
Sent: den 17 april 2019 10:33
To: Andre McCurdy 
Cc: Adrian Bunk ; Peter Kjellerstedt 
; OE Core mailing list 

Subject: Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings

It's not caused by this change (not the previous one I believe), but today I've 
noticed that aarch64 tunes don't set TUNE_PKGARCH correctly.

e.g. with raspberrypi3-64 which since this commit:
https://github.com/agherzan/meta-raspberrypi/commit/9cc89cb7341d633b6fc3a92b937b5560d26257a1
uses conf/machine/include/tune-cortexa53.inc I was expecting it to use 
cortexa53 specific TUNE_PKGARCH (and stop messing with other MACHINEs which are 
using aarch64 package feed).

There is indeed:
DEFAULTTUNE="cortexa53"
and mcpu=cortex-a53+crc in CC:
export CC="aarch64-webos-linux-gcc  -mcpu=cortex-a53+crc 
--sysroot=/OE/build/luneos-warrior/webos-ports/tmp-glibc/work/aarch64-webos-linux/zlib/1.2.11-r0/recipe-sysroot"

But
ARMPKGARCH="cortexa53"

# $TUNE_PKGARCH_32
#   set 
/OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:29
# 
"${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
TUNE_PKGARCH_32="cortexa53"
#
# $TUNE_PKGARCH_64
#   set 
/OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:23
# "aarch64${ARMPKGSFX_ENDIAN_64}"
TUNE_PKGARCH_64="aarch64"

#   "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_PKGARCH_64}', 
'${TUNE_PKGARCH_32}' 
,d)}<mailto:$%7b@bb.utils.contains('TUNE_FEATURES',%20'aarch64',%20'$%7bTUNE_PKGARCH_64%7d',%20'$%7bTUNE_PKGARCH_32%7d'%20,d)%7d>"
TUNE_PKGARCH="aarch64"

so the packages built with -mcpu=cortex-a53+crc (and rpi overrides) end in the 
same TUNE_PKGARCH as other MACHINEs which include e.g.
conf/machine/include/arm/arch-arm64.inc and DEFAULTTUNE="aarch64" which 
surprisingly uses aarch64 in both TUNE_PKGARCH_32/64:

#   "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_PKGARCH_64}', 
'${TUNE_PKGARCH_32}' 
,d)}<mailto:$%7b@bb.utils.contains('TUNE_FEATURES',%20'aarch64',%20'$%7bTUNE_PKGARCH_64%7d',%20'$%7bTUNE_PKGARCH_32%7d'%20,d)%7d>"
TUNE_PKGARCH="aarch64"
#
# $TUNE_PKGARCH_32
#   set 
/OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:29
# 
"${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
TUNE_PKGARCH_32="aarch64"
#
# $TUNE_PKGARCH_64
#   set 
/OE/build/luneos-warrior/webos-ports/openembedded-core/meta/conf/machine/include/arm/arch-arm64.inc:23
# "aarch64${ARMPKGSFX_ENDIAN_64}"
TUNE_PKGARCH_64="aarch64"

Looks like aarch64 are even bigger mess than arm tunes already :/.

On Wed, Apr 3, 2019 at 10:48 PM Andre McCurdy 
mailto:armccu...@gmail.com>> wrote:
On Wed, Apr 3, 2019 at 1:24 PM Adrian Bunk 
mailto:b...@stusta.de>> wrote:
> On Wed, Apr 03, 2019 at 12:29:29PM -0700, Andre McCurdy wrote:
> > On Tue, Apr 2, 2019 at 11:23 PM Adrian Bunk 
> > mailto:b...@stusta.de>> wrote:
> > > On Tue, Apr 02, 2019 at 09:26:46PM +0100, Richard Purdie wrote:
> > > >...
> > > > "armv4t" is defined in the arm tune files to mean "add -march=armv4t"
> > > > which is the convention used throughout all the tune files.
> > > >...
> > >
> > > Unfortunately this is not true.
> > >
> > > OE has both armv7a and armv7at tunes.
> > >
> > > There is no armv7a without Thumb support,
> > > so no -march=armv7-at exists in gcc.
> > >
> > > Both armv7a and armv7at tunes pass the same march to gcc,
> > > but [1] is not true:
> > >   Default to using the Thumb-2 instruction set for armv7a and above.
> > >
> > > The hardware supports Thumb-2 in any case, the actual difference between
> > > the armv7a and armv7at OE tunes is whether OE tells the compiler to
> > > generate ARM or Thumb-2 code.
> > >
> > > OE has both armv6 and armv6t tunes.
> > >
> > > There is no armv6 without Th

Re: [OE-core] [PATCH] useradd.bbclass: Make sure users/groups exist for package_write_* tasks

2019-04-12 Thread Peter Kjellerstedt
> -Original Message-
> From: richard.pur...@linuxfoundation.org
> 
> Sent: den 12 april 2019 19:03
> To: Peter Kjellerstedt 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] useradd.bbclass: Make sure users/groups
> exist for package_write_* tasks
> 
> On Fri, 2019-04-12 at 15:51 +, Peter Kjellerstedt wrote:
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > >  > > core-boun...@lists.openembedded.org> On Behalf Of Peter
> > > Kjellerstedt
> > > Sent: den 4 april 2019 16:08
> > > To: Richard Purdie ;
> > > openembedded-
> > > c...@lists.openembedded.org
> > > Subject: Re: [OE-core] [PATCH] useradd.bbclass: Make sure
> > > users/groups
> > > exist for package_write_* tasks
> > >
> > > > -Original Message-
> > > > From: Richard Purdie 
> > > > Sent: den 3 april 2019 14:48
> > > > To: Peter Kjellerstedt ;
> > > > openembedded-
> > > > c...@lists.openembedded.org
> > > > Subject: Re: [OE-core] [PATCH] useradd.bbclass: Make sure
> > > > users/groups
> > > > exist for package_write_* tasks
> > > >
> > > > On Wed, 2019-04-03 at 14:26 +0200, Peter Kjellerstedt wrote:
> > > > > If the populate_lic task and any of the package_write_* tasks
> > > > > need to
> > > > > run, but the package task can be restored from the sstate
> > > > > cache, then
> > > > > the fetch task, which is a dependency of populate_lic, will
> > > > > wipe out
> > > > > the RSS including any users/groups that have been created. This
> > > > > results in that the package_write_* tasks are run without any
> > > > > user/group information, which causes them to fallback to either
> > > > > use
> > > > > the root user for any unknown users/groups (rpm) or to use the
> > > > > numeric
> > > > > UIDs/GIDs (deb/ipk). Neither solution will yield correct
> > > > > packages.
> > > > >
> > > > > Signed-off-by: Peter Kjellerstedt 
> > > > > ---
> > > > >  meta/classes/useradd.bbclass | 18 --
> > > > >  1 file changed, 12 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/meta/classes/useradd.bbclass
> > > > > b/meta/classes/useradd.bbclass
> > > > > index 124becd082..e32315a1af 100644
> > > > > --- a/meta/classes/useradd.bbclass
> > > > > +++ b/meta/classes/useradd.bbclass
> > > > > @@ -4,7 +4,7 @@ inherit useradd_base
> > > > >  # target sysroot, and shadow -native and -sysroot provide the
> > > > > utilities
> > > > >  # and support files needed to add and modify user and group
> > > > > accounts
> > > > >  DEPENDS_append_class-target = " base-files shadow-native
> > > > > shadow-sysroot shadow base-passwd"
> > > > > -PACKAGE_WRITE_DEPS += "shadow-native"
> > > > > +PACKAGE_WRITE_DEPS += "shadow-native shadow-sysroot base-
> > > > > passwd"
> > > > >
> > > > >  # This preinstall function can be run in four different
> > > > > contexts:
> > > > >  #
> > > > > @@ -144,7 +144,10 @@ python useradd_sysroot_sstate () {
> > > > >  task = d.getVar("BB_CURRENTTASK")
> > > > >  if task == "package_setscene":
> > > > >  bb.build.exec_func("useradd_sysroot", d)
> > > > > -elif task == "prepare_recipe_sysroot":
> > > > > +elif (task == "prepare_recipe_sysroot" or
> > > > > +  task == "package_write_deb" or
> > > > > +  task == "package_write_ipk" or
> > > > > +  task == "package_write_rpm"):
> > > > >  # Used to update this recipe's own sysroot so the
> > > > > user/groups are available to do_install
> > > > >  scriptfile =
> > > > > d.expand("${RECIPE_SYSROOT}${bindir}/postinst-useradd-${PN}")
> > > > >  bb.build.exec_func("useradd_sysroot", d)
> > > > > @@ -161,13 +164,16 @@ python useradd_sysroot_sstate () {
> > > > >  os.chmod(scriptfile, 0o755)

[OE-core] [master][warrior][PATCH] systemd: Use PACKAGECONFIG definition to depend on libnss-myhostname

2019-04-12 Thread Peter Kjellerstedt
Rather than adding the dependency on libnss-myhostname to
RDEPENDS_${PN} if the myhostname PACKAGECONFIG is set, add the runtime
dependency to myhostname's PACKAGECONFIG definition.

Signed-off-by: Peter Kjellerstedt 
---

This is just a clean up of the last commit to systemd.

meta/recipes-core/systemd/systemd_241.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_241.bb 
b/meta/recipes-core/systemd/systemd_241.bb
index 3a58f44a3b..562cdc3316 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -144,7 +144,7 @@ PACKAGECONFIG[lz4] = "-Dlz4=true,-Dlz4=false,lz4"
 PACKAGECONFIG[machined] = "-Dmachined=true,-Dmachined=false"
 PACKAGECONFIG[manpages] = "-Dman=true,-Dman=false,libxslt-native xmlto-native 
docbook-xml-dtd4-native docbook-xsl-stylesheets-native"
 PACKAGECONFIG[microhttpd] = 
"-Dmicrohttpd=true,-Dmicrohttpd=false,libmicrohttpd"
-PACKAGECONFIG[myhostname] = "-Dnss-myhostname=true,-Dnss-myhostname=false"
+PACKAGECONFIG[myhostname] = 
"-Dnss-myhostname=true,-Dnss-myhostname=false,,libnss-myhostname"
 PACKAGECONFIG[networkd] = "-Dnetworkd=true,-Dnetworkd=false"
 PACKAGECONFIG[nss] = "-Dnss-systemd=true,-Dnss-systemd=false"
 PACKAGECONFIG[nss-mymachines] = "-Dnss-mymachines=true,-Dnss-mymachines=false"
@@ -547,7 +547,6 @@ FILES_${PN}-dev += "${base_libdir}/security/*.la 
${datadir}/dbus-1/interfaces/ $
 RDEPENDS_${PN} += "kmod dbus util-linux-mount util-linux-umount udev (= 
${EXTENDPKGV}) util-linux-agetty util-linux-fsck"
 RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 
'serial-getty-generator', '', 'systemd-serialgetty', d)}"
 RDEPENDS_${PN} += "volatile-binds update-rc.d systemd-conf"
-RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'myhostname', 
'libnss-myhostname', '', d)}"
 
 RRECOMMENDS_${PN} += "systemd-extra-utils \
   systemd-compat-units udev-hwdb \
-- 
2.12.0

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


Re: [OE-core] [PATCH] useradd.bbclass: Make sure users/groups exist for package_write_* tasks

2019-04-12 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Peter Kjellerstedt
> Sent: den 4 april 2019 16:08
> To: Richard Purdie ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] useradd.bbclass: Make sure users/groups
> exist for package_write_* tasks
> 
> > -Original Message-
> > From: Richard Purdie 
> > Sent: den 3 april 2019 14:48
> > To: Peter Kjellerstedt ; openembedded-
> > c...@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH] useradd.bbclass: Make sure users/groups
> > exist for package_write_* tasks
> >
> > On Wed, 2019-04-03 at 14:26 +0200, Peter Kjellerstedt wrote:
> > > If the populate_lic task and any of the package_write_* tasks need to
> > > run, but the package task can be restored from the sstate cache, then
> > > the fetch task, which is a dependency of populate_lic, will wipe out
> > > the RSS including any users/groups that have been created. This
> > > results in that the package_write_* tasks are run without any
> > > user/group information, which causes them to fallback to either use
> > > the root user for any unknown users/groups (rpm) or to use the numeric
> > > UIDs/GIDs (deb/ipk). Neither solution will yield correct packages.
> > >
> > > Signed-off-by: Peter Kjellerstedt 
> > > ---
> > >  meta/classes/useradd.bbclass | 18 --
> > >  1 file changed, 12 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
> > > index 124becd082..e32315a1af 100644
> > > --- a/meta/classes/useradd.bbclass
> > > +++ b/meta/classes/useradd.bbclass
> > > @@ -4,7 +4,7 @@ inherit useradd_base
> > >  # target sysroot, and shadow -native and -sysroot provide the utilities
> > >  # and support files needed to add and modify user and group accounts
> > >  DEPENDS_append_class-target = " base-files shadow-native shadow-sysroot 
> > > shadow base-passwd"
> > > -PACKAGE_WRITE_DEPS += "shadow-native"
> > > +PACKAGE_WRITE_DEPS += "shadow-native shadow-sysroot base-passwd"
> > >
> > >  # This preinstall function can be run in four different contexts:
> > >  #
> > > @@ -144,7 +144,10 @@ python useradd_sysroot_sstate () {
> > >  task = d.getVar("BB_CURRENTTASK")
> > >  if task == "package_setscene":
> > >  bb.build.exec_func("useradd_sysroot", d)
> > > -elif task == "prepare_recipe_sysroot":
> > > +elif (task == "prepare_recipe_sysroot" or
> > > +  task == "package_write_deb" or
> > > +  task == "package_write_ipk" or
> > > +  task == "package_write_rpm"):
> > >  # Used to update this recipe's own sysroot so the user/groups 
> > > are available to do_install
> > >  scriptfile = 
> > > d.expand("${RECIPE_SYSROOT}${bindir}/postinst-useradd-${PN}")
> > >  bb.build.exec_func("useradd_sysroot", d)
> > > @@ -161,13 +164,16 @@ python useradd_sysroot_sstate () {
> > >  os.chmod(scriptfile, 0o755)
> > >  }
> > >
> > > -do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
> > > -SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
> > >  SYSROOTFUNC = ""
> > > +SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
> > >
> > > -SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
> > > +do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
> > > +do_package_write_deb[prefuncs] += "${SYSROOTFUNC}"
> > > +do_package_write_ipk[prefuncs] += "${SYSROOTFUNC}"
> > > +do_package_write_rpm[prefuncs] += "${SYSROOTFUNC}"
> > >
> > > -SSTATEPREINSTFUNCS_append_class-target = " useradd_sysroot_sstate"
> > > +SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
> > > +SSTATEPREINSTFUNCS += "${SYSROOTFUNC}"
> > >
> > >  do_package_setscene[depends] += "${USERADDSETSCENEDEPS}"
> > >  do_populate_sysroot_setscene[depends] += "${USERADDSETSCENEDEPS}"
> >
> > This may be a bigger problem that just package_write_*.
> >
> > This feels like a bad thing to do since there may be other tasks which
> > also rely on the user information being pres

Re: [OE-core] [PATCH] systemd: install libnss-myhostname.so when myhostname be enabled

2019-04-12 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Wenlin Kang
> Sent: den 10 april 2019 11:25
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] systemd: install libnss-myhostname.so when
> myhostname be enabled
> 
> This fixes the follow issue, the cause is that net-tools needs
> libnss-myhostname.so when run "hostname -s".
> 
> root@qemuarm64:~# hostname -s
> hostname: Unknown host
> 
> Signed-off-by: Wenlin Kang 
> ---
>  meta/recipes-core/systemd/systemd_241.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-core/systemd/systemd_241.bb 
> b/meta/recipes-core/systemd/systemd_241.bb
> index bfbfc81..251daaa 100644
> --- a/meta/recipes-core/systemd/systemd_241.bb
> +++ b/meta/recipes-core/systemd/systemd_241.bb
> @@ -547,6 +547,7 @@ FILES_${PN}-dev += "${base_libdir}/security/*.la 
> ${datadir}/dbus-1/interfaces/ $
>  RDEPENDS_${PN} += "kmod dbus util-linux-mount util-linux-umount udev (= 
> ${EXTENDPKGV}) util-linux-agetty util-linux-fsck"
>  RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 
> 'serial-getty-generator', '', 'systemd-serialgetty', d)}"
>  RDEPENDS_${PN} += "volatile-binds update-rc.d systemd-conf"
> +RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'myhostname', 
> 'libnss-myhostname', '', d)}"

Do this via the PACKAGECONFIG instead, i.e., change the existing 
PACKAGECONFIG for myhostname to:

PACKAGECONFIG[myhostname] = 
"-Dnss-myhostname=true,-Dnss-myhostname=false,,libnss-myhostname"

>  RRECOMMENDS_${PN} += "systemd-extra-utils \
>systemd-compat-units udev-hwdb \
> --
> 1.9.1

//Peter

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


Re: [OE-core] [PATCH] useradd.bbclass: Make sure users/groups exist for package_write_* tasks

2019-04-04 Thread Peter Kjellerstedt
> -Original Message-
> From: Richard Purdie 
> Sent: den 3 april 2019 14:48
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] useradd.bbclass: Make sure users/groups
> exist for package_write_* tasks
> 
> On Wed, 2019-04-03 at 14:26 +0200, Peter Kjellerstedt wrote:
> > If the populate_lic task and any of the package_write_* tasks need to
> > run, but the package task can be restored from the sstate cache, then
> > the fetch task, which is a dependency of populate_lic, will wipe out
> > the RSS including any users/groups that have been created. This
> > results in that the package_write_* tasks are run without any
> > user/group information, which causes them to fallback to either use
> > the root user for any unknown users/groups (rpm) or to use the numeric
> > UIDs/GIDs (deb/ipk). Neither solution will yield correct packages.
> >
> > Signed-off-by: Peter Kjellerstedt 
> > ---
> >  meta/classes/useradd.bbclass | 18 --
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
> > index 124becd082..e32315a1af 100644
> > --- a/meta/classes/useradd.bbclass
> > +++ b/meta/classes/useradd.bbclass
> > @@ -4,7 +4,7 @@ inherit useradd_base
> >  # target sysroot, and shadow -native and -sysroot provide the utilities
> >  # and support files needed to add and modify user and group accounts
> >  DEPENDS_append_class-target = " base-files shadow-native shadow-sysroot 
> > shadow base-passwd"
> > -PACKAGE_WRITE_DEPS += "shadow-native"
> > +PACKAGE_WRITE_DEPS += "shadow-native shadow-sysroot base-passwd"
> >
> >  # This preinstall function can be run in four different contexts:
> >  #
> > @@ -144,7 +144,10 @@ python useradd_sysroot_sstate () {
> >  task = d.getVar("BB_CURRENTTASK")
> >  if task == "package_setscene":
> >  bb.build.exec_func("useradd_sysroot", d)
> > -elif task == "prepare_recipe_sysroot":
> > +elif (task == "prepare_recipe_sysroot" or
> > +  task == "package_write_deb" or
> > +  task == "package_write_ipk" or
> > +  task == "package_write_rpm"):
> >  # Used to update this recipe's own sysroot so the user/groups are 
> > available to do_install
> >  scriptfile = 
> > d.expand("${RECIPE_SYSROOT}${bindir}/postinst-useradd-${PN}")
> >  bb.build.exec_func("useradd_sysroot", d)
> > @@ -161,13 +164,16 @@ python useradd_sysroot_sstate () {
> >  os.chmod(scriptfile, 0o755)
> >  }
> >
> > -do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
> > -SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
> >  SYSROOTFUNC = ""
> > +SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
> >
> > -SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
> > +do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
> > +do_package_write_deb[prefuncs] += "${SYSROOTFUNC}"
> > +do_package_write_ipk[prefuncs] += "${SYSROOTFUNC}"
> > +do_package_write_rpm[prefuncs] += "${SYSROOTFUNC}"
> >
> > -SSTATEPREINSTFUNCS_append_class-target = " useradd_sysroot_sstate"
> > +SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
> > +SSTATEPREINSTFUNCS += "${SYSROOTFUNC}"
> >
> >  do_package_setscene[depends] += "${USERADDSETSCENEDEPS}"
> >  do_populate_sysroot_setscene[depends] += "${USERADDSETSCENEDEPS}"
> 
> This may be a bigger problem that just package_write_*.
> 
> This feels like a bad thing to do since there may be other tasks which
> also rely on the user information being present. This probably only
> fixes one corner case but there are likey others :(.
> 
> Possible solutions might be:
> 
> a) To wipe out all sstate tasks if we're rerunning do_fetch

How to do that? With some pointers I hope I can whip up a patch 
to do this instead.

Is this rare or is it likely to cause a performance impact?
If it only happens in the cases where we are seeing problems due to 
the removed user/group info, then it should be reasonably rare.

> b) Preserve the user/group information around the cleaning of the
> sysroot

This sounds error prone at best...

> I think we may need to fix this generically...
> 
> Cheers,
> 
> Richard

//Peter

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


[OE-core] [PATCH] useradd.bbclass: Make sure users/groups exist for package_write_* tasks

2019-04-03 Thread Peter Kjellerstedt
If the populate_lic task and any of the package_write_* tasks need to
run, but the package task can be restored from the sstate cache, then
the fetch task, which is a dependency of populate_lic, will wipe out
the RSS including any users/groups that have been created. This
results in that the package_write_* tasks are run without any
user/group information, which causes them to fallback to either use
the root user for any unknown users/groups (rpm) or to use the numeric
UIDs/GIDs (deb/ipk). Neither solution will yield correct packages.

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/useradd.bbclass | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/meta/classes/useradd.bbclass b/meta/classes/useradd.bbclass
index 124becd082..e32315a1af 100644
--- a/meta/classes/useradd.bbclass
+++ b/meta/classes/useradd.bbclass
@@ -4,7 +4,7 @@ inherit useradd_base
 # target sysroot, and shadow -native and -sysroot provide the utilities
 # and support files needed to add and modify user and group accounts
 DEPENDS_append_class-target = " base-files shadow-native shadow-sysroot shadow 
base-passwd"
-PACKAGE_WRITE_DEPS += "shadow-native"
+PACKAGE_WRITE_DEPS += "shadow-native shadow-sysroot base-passwd"
 
 # This preinstall function can be run in four different contexts:
 #
@@ -144,7 +144,10 @@ python useradd_sysroot_sstate () {
 task = d.getVar("BB_CURRENTTASK")
 if task == "package_setscene":
 bb.build.exec_func("useradd_sysroot", d)
-elif task == "prepare_recipe_sysroot":
+elif (task == "prepare_recipe_sysroot" or
+  task == "package_write_deb" or
+  task == "package_write_ipk" or
+  task == "package_write_rpm"):
 # Used to update this recipe's own sysroot so the user/groups are 
available to do_install
 scriptfile = 
d.expand("${RECIPE_SYSROOT}${bindir}/postinst-useradd-${PN}")
 bb.build.exec_func("useradd_sysroot", d)
@@ -161,13 +164,16 @@ python useradd_sysroot_sstate () {
 os.chmod(scriptfile, 0o755)
 }
 
-do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
-SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
 SYSROOTFUNC = ""
+SYSROOTFUNC_class-target = "useradd_sysroot_sstate"
 
-SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
+do_prepare_recipe_sysroot[postfuncs] += "${SYSROOTFUNC}"
+do_package_write_deb[prefuncs] += "${SYSROOTFUNC}"
+do_package_write_ipk[prefuncs] += "${SYSROOTFUNC}"
+do_package_write_rpm[prefuncs] += "${SYSROOTFUNC}"
 
-SSTATEPREINSTFUNCS_append_class-target = " useradd_sysroot_sstate"
+SYSROOT_PREPROCESS_FUNCS += "${SYSROOTFUNC}"
+SSTATEPREINSTFUNCS += "${SYSROOTFUNC}"
 
 do_package_setscene[depends] += "${USERADDSETSCENEDEPS}"
 do_populate_sysroot_setscene[depends] += "${USERADDSETSCENEDEPS}"
-- 
2.12.0

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


Re: [OE-core] [PATCH 2/6] Revert "arch-armv5-dsp.inc: Check for dsp only to enable 'e' in package arches"

2019-04-02 Thread Peter Kjellerstedt
This revert (and the following) are there to allow my alternative 
solution to be applied.

//Peter

> -Original Message-
> From: akuster808 
> Sent: den 2 april 2019 22:53
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/6] Revert "arch-armv5-dsp.inc: Check
> for dsp only to enable 'e' in package arches"
> 
> Peter
> 
> On 4/2/19 12:31 PM, Peter Kjellerstedt wrote:
> > This reverts commit 1d6d5bb30a83f9136b7c33e297d48564ae61b50e.
> 
> What problem are you seeing that is being fixed by this revert?
> it may help decide if it need to be in warrior.
> 
> - armin
> >
> > Signed-off-by: Peter Kjellerstedt 
> > ---
> >  meta/conf/machine/include/arm/arch-armv5-dsp.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> > index d117af1520..1f16085fcd 100644
> > --- a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> > +++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
> > @@ -1,4 +1,4 @@
> > -ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'dsp' ],
> 'e', '', d)}"
> > +ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5',
> 'dsp' ], 'e', '', d)}"
> >  TUNEVALID[dsp] = "ARM DSP functionality"
> >
> >  require conf/machine/include/arm/arch-armv5.inc

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


Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings

2019-04-02 Thread Peter Kjellerstedt
> -Original Message-
> From: Richard Purdie 
> Sent: den 2 april 2019 22:27
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 0/6] Correct and improve the ARM tunings
> 
> On Tue, 2019-04-02 at 21:30 +0200, Peter Kjellerstedt wrote:
> > These patches are intended to improve the ARM tunings and came about
> > after I had to study the tune files a lot more than I first had
> > anticipated...
> >
> > The first patch (arch-armv8a.inc: Correct
> > PACKAGE_EXTRA_ARCHS_tune-armv8a-*) avoids odd architectures such as
> > "crc" and "crypto" to be included in PACKAGE_EXTRA_ARCHS.
> >
> > The following three patches (where i have sent the latter two to the
> > list before) restores the "armv*" features to TUNE_FEATURES for all
> > ARM based SoCs as it does not make sense to remove them from the SoC
> > specific tune files just to determine whether -mcpu or -march shall
> > be used. This is because the SoCs still support the armv* features
> > specified in their TUNE_FEATURES even if they also have more specific
> > SoC tunings.
> 
> It depends how you view TUNE_FEATURES and what the presence of things
> there is defined to mean.

The assumption I made was that the features listed in TUNE_FEATURES 
matches what features the compiler/linker will make use of when 
building the code and something that can be checked by, e.g., recipes 
to enable/disable functionality to match this. There are examples of 
this in the recipes in OE-Core, e.g., where TUNE_FEATURES is checked 
to determine what options to pass to configure.

E.g., with DEFAULTTUNE set to "arm926ejs", TUNE_FEATURES expands to 
"arm armv5 thumb dsp arm926ejs" (with Thud and older, or with my 
patches applied). To me this means that I can assume that I can use 
anything that is specific to either of those features when I decide 
what to build. And although arm926ejs implies armv5, having the 
latter as a separate feature makes it possible to write a generic 
test for armv5 without having to know the exact SoC and what it 
supports.

> "armv4t" is defined in the arm tune files to mean "add -march=armv4t"
> which is the convention used throughout all the tune files.

I fail to see where it says that the "armv*" features of TUNE_FEATUES 
are to be used to set -march and nothing else. That seems like a very 
odd implication of one of the many features specified in TUNE_FEATURES.

However, with my patches applied, the "armv*" features still says to 
set -march, unless there is also a more specific tune feature, e.g., 
"arm926ejs", which means -mcpu will be used instead. I don't think 
deciding between -mcpu and -march should be based on the existence or 
non-existence of a given feature in TUNE_FEATURES, but rather on the 
context. This also matches how the TUNE_FEATURES_tune-arm* variables 
are being defined with more specific variables such as 
TUNE_FEATURES_tune-arm926ejs being defined based on more generic 
variables (TUNE_FEATURES_tune-armv5te in this case) and then adding 
the more specific feature(s).

> I'm still not convinced this part of your changes improves the
> situation as it then breaks and confuses that situation.

According to my view there is less confusion now. TUNE_FEATURES yet 
again describes the features that are supported.

> I'm also worried you're wanting this as you have code elsewhere which
> is using "armvX" there to mean something else?

Actually we're not using any such tests. I did the initial rework 
based on the notion that the change that had gone into the tuning 
files felt wrong, tearing out the structure that was previously 
there in the definitions of the TUNE_FEATURES_tune-arm* variables, 
and how it had messed up my view of what the features in 
TUNE_FEATURES are supposed to mean. And after having studied those 
files a lot more, that initial notion still holds true for me.

> Cheers,
> 
> Richard

//Peter

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


[OE-core] [PATCH 4/6] arm-tunes: Prefer the -mcpu option over -march

2019-04-02 Thread Peter Kjellerstedt
Tune files that inherit the arch definitions already define
appropriate -mcpu options, which are equivalent of the correct -march
and -mtune combinations. This is preferred since gcc is getting
stricter and stricter with option check semantics and can now find
incompatible -march and -mcpu options better with every release. It
does an internal feature consistency check and if it finds any
discrepancies between what -mcpu would expand to as compared to
-march, it will flag the options to be incompatible. For the naked eye
it looks wrong, but gcc will translate -mcpu to a given -march
internally and it might not match what we set in these arch files.

The effects are quite subtle, where this can result in configure tests
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.

E.g., with GCC 9, which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ end up
disabled due to configure check failures, e.g., size_t size, ptrdiff_t
sizes, which in turn results in compiling libstdc++ with wanted
features disabled.

This is an alternative solution to the same problem originally
implemented by Khem Raj in commit ac83d22e, but this time only
affecting -mcpu and -march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/arm/arch-arm.inc   | 6 ++
 meta/conf/machine/include/arm/arch-armv4.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv5.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv6.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc| 2 +-
 meta/conf/machine/include/arm/arch-armv7ve.inc   | 2 +-
 meta/conf/machine/include/arm/arch-armv8a.inc| 6 +++---
 meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-
 meta/conf/machine/include/tune-arm920t.inc   | 2 +-
 meta/conf/machine/include/tune-arm926ejs.inc | 2 +-
 meta/conf/machine/include/tune-arm9tdmi.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa15.inc | 2 +-
 meta/conf/machine/include/tune-cortexa17.inc | 2 +-
 meta/conf/machine/include/tune-cortexa32.inc | 2 +-
 meta/conf/machine/include/tune-cortexa35.inc | 2 +-
 meta/conf/machine/include/tune-cortexa5.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa53.inc | 2 +-
 meta/conf/machine/include/tune-cortexa7.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa72.inc | 2 +-
 meta/conf/machine/include/tune-cortexa8.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa9.inc  | 2 +-
 meta/conf/machine/include/tune-ep9312.inc| 2 +-
 meta/conf/machine/include/tune-iwmmxt.inc| 2 +-
 meta/conf/machine/include/tune-strongarm1100.inc | 2 +-
 meta/conf/machine/include/tune-thunderx.inc  | 2 +-
 meta/conf/machine/include/tune-xscale.inc| 2 +-
 26 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-arm.inc 
b/meta/conf/machine/include/arm/arch-arm.inc
index 99625d8417..188cf8b473 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -11,6 +11,12 @@ ARMPKGSFX_THUMB ??= ""
 TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'armeb', 
'arm', d)}"
 TUNE_PKGARCH = 
"${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
 
+# Prefer -mcpu= over -arch=
+TUNE_CCARGS_MCPU ??= ""
+TUNE_CCARGS_MARCH ??= ""
+TUNE_CCARGS_FEATURES ??= ""
+TUNE_CCARGS .= "${@d.getVar('TUNE_CCARGS_MCPU') or 
d.getVar('TUNE_CCARGS_MARCH')}${TUNE_CCARGS_FEATURES}"
+
 ABIEXTENSION = "eabi"
 
 TARGET_FPU = "${@d.getVar('TUNE_CCARGS_MFLOAT') or 'soft'}"
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..dac791e308 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
+TUNE_CCARGS_MARCH .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it 
when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any 
checkvalues in value, now it does 
 # checkvalues.issubset(val) which cannot be used for negative test of foo 
neither bar in value
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc 
b/meta/conf/machine/include/arm/arch-armv5.inc
index f9068af9de..9c82015df2 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -2,7 +2,7 @@ DEFAUL

[OE-core] [PATCH 3/6] Revert "arm-tunes: Remove -march option if mcpu is already added"

2019-04-02 Thread Peter Kjellerstedt
This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.

This solution had unforeseen side effects, which, e.g., lead to the
following sanity error if trying to build with the arm926ejs default
tune:

Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
armv5 armv5t armv5e armv5te arm926ejste arm926ejse ) for DEFAULTTUNE (arm926ejs) does not contain
TUNE_PKGARCH (arm926ejst).

An alternative solution will follow, which only affects the -mcpu and
-march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  4 +---
 meta/conf/machine/include/tune-arm920t.inc   |  4 +---
 meta/conf/machine/include/tune-arm926ejs.inc |  4 +---
 meta/conf/machine/include/tune-arm9tdmi.inc  |  4 +---
 meta/conf/machine/include/tune-cortexa15.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa17.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa5.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa7.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa8.inc  | 19 +++-
 meta/conf/machine/include/tune-cortexa9.inc  | 28 ++--
 meta/conf/machine/include/tune-ep9312.inc|  1 -
 meta/conf/machine/include/tune-iwmmxt.inc|  3 +--
 meta/conf/machine/include/tune-strongarm1100.inc |  3 +--
 meta/conf/machine/include/tune-xscale.inc|  7 ++
 14 files changed, 76 insertions(+), 109 deletions(-)

diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc 
b/meta/conf/machine/include/tune-arm1136jf-s.inc
index d883eba7c9..c5de63e1cc 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv6.inc
 
 TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' 
-mcpu=arm1136jf-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', 
'armv6:', '' ,d)}"
 
 AVAILTUNES += "arm1136jfs"
 ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
-# mcpu is used so don't use armv6 as we don't want march
-TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs"
+TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
 PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6} 
arm1136jfs-vfp"
diff --git a/meta/conf/machine/include/tune-arm920t.inc 
b/meta/conf/machine/include/tune-arm920t.inc
index 42e8ed2b51..c6e74b6772 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' 
-mcpu=arm920t', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', 
'armv4:', '' ,d)}"
 
 AVAILTUNES += "arm920t"
 ARMPKGARCH_tune-arm920t = "arm920t"
-# mcpu is used so don't use armv4t as we don't want march
-TUNE_FEATURES_tune-arm920t = "arm thumb arm920t"
+TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
 PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} arm920t 
arm920tt"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc 
b/meta/conf/machine/include/tune-arm926ejs.inc
index 563d53bc4e..81bcda339b 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv5-dsp.inc
 
 TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' 
-mcpu=arm926ej-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', 
'armv5:', '' ,d)}"
 
 AVAILTUNES += "arm926ejs"
 ARMPKGARCH_tune-arm926ejs = "arm926ejs"
-# mcpu is used so don't use armv5te as we don't want march
-TUNE_FEATURES_tune-arm926ejs = "arm thumb dsp arm926ejs"
+TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
 PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} 
arm926ejste arm926ejse"
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc 
b/meta/conf/machine/include/tune-arm9tdmi.inc
index e03a8b86a0..e9c2b8fcf5 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
 TUNE_CCARGS .= "$

[OE-core] [PATCH 2/6] Revert "arch-armv5-dsp.inc: Check for dsp only to enable 'e' in package arches"

2019-04-02 Thread Peter Kjellerstedt
This reverts commit 1d6d5bb30a83f9136b7c33e297d48564ae61b50e.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/arm/arch-armv5-dsp.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/arm/arch-armv5-dsp.inc 
b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
index d117af1520..1f16085fcd 100644
--- a/meta/conf/machine/include/arm/arch-armv5-dsp.inc
+++ b/meta/conf/machine/include/arm/arch-armv5-dsp.inc
@@ -1,4 +1,4 @@
-ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'dsp' ], 'e', '', d)}"
+ARMPKGSFX_DSP = "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 
'e', '', d)}"
 TUNEVALID[dsp] = "ARM DSP functionality"
 
 require conf/machine/include/arm/arch-armv5.inc
-- 
2.12.0

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


[OE-core] [PATCH 0/6] Correct and improve the ARM tunings

2019-04-02 Thread Peter Kjellerstedt
These patches are intended to improve the ARM tunings and came about
after I had to study the tune files a lot more than I first had
anticipated...

The first patch (arch-armv8a.inc: Correct
PACKAGE_EXTRA_ARCHS_tune-armv8a-*) avoids odd architectures such as
"crc" and "crypto" to be included in PACKAGE_EXTRA_ARCHS.

The following three patches (where i have sent the latter two to the
list before) restores the "armv*" features to TUNE_FEATURES for all ARM
based SoCs as it does not make sense to remove them from the SoC
specific tune files just to determine whether -mcpu or -march shall be
used. This is because the SoCs still support the armv* features
specified in their TUNE_FEATURES even if they also have more specific
SoC tunings.

The next patch (arch-arm64.inc: Lower the priority of aarch64 in
MACHINEOVERRIDES) makes sure that ${SOC_FAMILY} (if present) and
${MACHINE} have higher override priorities than aarch64, as should be.

Finally, the last patch (arm-tunes: Add armv8a to TUNE_FEATURES as
appropriate) adds the "armv8a" feature to TUNE_FEATURES for the
Cortex-A32, Cortex-A35, Cortex-A53 and Cortex-A72 to match all the other
ARM tunings.

//Peter

The following changes since commit a397fd17e42d745e6a23dee86e82b887f3d25ccd:

  layer.conf: Update to warrior release name series (2019-04-02 15:24:50 +0100)

are available in the git repository at:

  git://push.yoctoproject.org/poky-contrib pkj/arm-tunings

Peter Kjellerstedt (6):
  arch-armv8a.inc: Correct PACKAGE_EXTRA_ARCHS_tune-armv8a-*
  Revert "arch-armv5-dsp.inc: Check for dsp only to enable 'e' in
package arches"
  Revert "arm-tunes: Remove -march option if mcpu is already added"
  arm-tunes: Prefer the -mcpu option over -march
  arch-arm64.inc: Lower the priority of aarch64 in MACHINEOVERRIDES
  arm-tunes: Add armv8a to TUNE_FEATURES as appropriate

 meta/conf/machine/include/arm/arch-arm.inc   |  6 +
 meta/conf/machine/include/arm/arch-arm64.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv4.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv5-dsp.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv5.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv6.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc|  2 +-
 meta/conf/machine/include/arm/arch-armv7ve.inc   |  2 +-
 meta/conf/machine/include/arm/arch-armv8a.inc| 12 +-
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  6 ++---
 meta/conf/machine/include/tune-arm920t.inc   |  6 ++---
 meta/conf/machine/include/tune-arm926ejs.inc |  6 ++---
 meta/conf/machine/include/tune-arm9tdmi.inc  |  6 ++---
 meta/conf/machine/include/tune-cortexa15.inc | 29 ++-
 meta/conf/machine/include/tune-cortexa17.inc | 29 ++-
 meta/conf/machine/include/tune-cortexa32.inc | 11 -
 meta/conf/machine/include/tune-cortexa35.inc |  6 ++---
 meta/conf/machine/include/tune-cortexa5.inc  | 29 ++-
 meta/conf/machine/include/tune-cortexa53.inc | 10 
 meta/conf/machine/include/tune-cortexa7.inc  | 29 ++-
 meta/conf/machine/include/tune-cortexa72.inc |  6 ++---
 meta/conf/machine/include/tune-cortexa8.inc  | 21 +++--
 meta/conf/machine/include/tune-cortexa9.inc  | 30 ++--
 meta/conf/machine/include/tune-ep9312.inc|  3 +--
 meta/conf/machine/include/tune-iwmmxt.inc|  3 +--
 meta/conf/machine/include/tune-strongarm1100.inc |  5 ++--
 meta/conf/machine/include/tune-thunderx.inc  |  2 +-
 meta/conf/machine/include/tune-xscale.inc|  9 +++
 28 files changed, 125 insertions(+), 153 deletions(-)

-- 
2.12.0

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


[OE-core] [PATCH 6/6] arm-tunes: Add armv8a to TUNE_FEATURES as appropriate

2019-04-02 Thread Peter Kjellerstedt
This adds the armv8a tuning for Cortex-A32, Cortex-A35, Cortex-A53 and
Cortex-A72. This matches the other ARM tunes.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/tune-cortexa32.inc | 9 -
 meta/conf/machine/include/tune-cortexa35.inc | 4 ++--
 meta/conf/machine/include/tune-cortexa53.inc | 8 
 meta/conf/machine/include/tune-cortexa72.inc | 4 ++--
 4 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa32.inc 
b/meta/conf/machine/include/tune-cortexa32.inc
index c50470203c..a150540845 100644
--- a/meta/conf/machine/include/tune-cortexa32.inc
+++ b/meta/conf/machine/include/tune-cortexa32.inc
@@ -1,6 +1,5 @@
 DEFAULTTUNE ?= "cortexa32"
 
-
 TUNEVALID[cortexa32] = "Enable Cortex-A32 specific processor optimizations"
 TUNE_CCARGS_MCPU .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa32', ' 
-mcpu=cortex-a32', '', d)}"
 
@@ -8,10 +7,10 @@ require conf/machine/include/arm/arch-armv8a.inc
 
 # Little Endian base configs
 AVAILTUNES += "cortexa32 cortexa32-crypto"
-ARMPKGARCH_tune-cortexa32 = "cortexa32"
-ARMPKGARCH_tune-cortexa32-crypto  = "cortexa32"
-TUNE_FEATURES_tune-cortexa32  = "aarch64 cortexa32 crc"
-TUNE_FEATURES_tune-cortexa32-crypto   = "aarch64 cortexa32 crc crypto"
+ARMPKGARCH_tune-cortexa32?= "cortexa32"
+ARMPKGARCH_tune-cortexa32-crypto ?= "cortexa32"
+TUNE_FEATURES_tune-cortexa32  = "${TUNE_FEATURES_tune-armv8a-crc} 
cortexa32"
+TUNE_FEATURES_tune-cortexa32-crypto   = 
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa32"
 PACKAGE_EXTRA_ARCHS_tune-cortexa32 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa32"
 PACKAGE_EXTRA_ARCHS_tune-cortexa32-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa32 cortexa32-crypto"
 BASE_LIB_tune-cortexa32   = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa35.inc 
b/meta/conf/machine/include/tune-cortexa35.inc
index 0b082ce259..f57b0bd6e9 100644
--- a/meta/conf/machine/include/tune-cortexa35.inc
+++ b/meta/conf/machine/include/tune-cortexa35.inc
@@ -9,8 +9,8 @@ require conf/machine/include/arm/arch-armv8a.inc
 AVAILTUNES += "cortexa35 cortexa35-crypto"
 ARMPKGARCH_tune-cortexa35 = "cortexa35"
 ARMPKGARCH_tune-cortexa35-crypto  = "cortexa35"
-TUNE_FEATURES_tune-cortexa35  = "aarch64 cortexa35 crc"
-TUNE_FEATURES_tune-cortexa35-crypto   = "aarch64 cortexa35 crc crypto"
+TUNE_FEATURES_tune-cortexa35  = "${TUNE_FEATURES_tune-armv8a-crc} 
cortexa35"
+TUNE_FEATURES_tune-cortexa35-crypto   = 
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa35"
 PACKAGE_EXTRA_ARCHS_tune-cortexa35 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa35"
 PACKAGE_EXTRA_ARCHS_tune-cortexa35-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa35 cortexa35-crypto"
 BASE_LIB_tune-cortexa35   = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa53.inc
index b3bd8bbc4e..48de368328 100644
--- a/meta/conf/machine/include/tune-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -7,10 +7,10 @@ require conf/machine/include/arm/arch-armv8a.inc
 
 # Little Endian base configs
 AVAILTUNES += "cortexa53 cortexa53-crypto"
-ARMPKGARCH_tune-cortexa53 = "cortexa53"
-ARMPKGARCH_tune-cortexa53-crypto  = "cortexa53"
-TUNE_FEATURES_tune-cortexa53  = "aarch64 cortexa53 crc"
-TUNE_FEATURES_tune-cortexa53-crypto   = "aarch64 cortexa53 crc crypto"
+ARMPKGARCH_tune-cortexa53?= "cortexa53"
+ARMPKGARCH_tune-cortexa53-crypto ?= "cortexa53"
+TUNE_FEATURES_tune-cortexa53  = "${TUNE_FEATURES_tune-armv8a-crc} 
cortexa53"
+TUNE_FEATURES_tune-cortexa53-crypto   = 
"${TUNE_FEATURES_tune-armv8a-crc-crypto}cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa53 cortexa53-crypto"
 BASE_LIB_tune-cortexa53   = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa72.inc 
b/meta/conf/machine/include/tune-cortexa72.inc
index 1ed456f1a9..b527c5abaf 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -7,7 +7,7 @@ require conf/machine/include/arm/arch-armv8a.inc
 
 # Little Endian base configs
 AVAILTUNES += "cortexa72"
-ARMPKGARCH_tune-cortexa72 = "cortexa72"
-TUNE_FEATURES_tune-cortexa72  = "aarch64 cortexa72 crc cry

[OE-core] [PATCH 5/6] arch-arm64.inc: Lower the priority of aarch64 in MACHINEOVERRIDES

2019-04-02 Thread Peter Kjellerstedt
This makes sure, e.g., ${SOC_FAMILY} and ${MACHINE} have higher
priorities than aarch64.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/arm/arch-arm64.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/arm/arch-arm64.inc 
b/meta/conf/machine/include/arm/arch-arm64.inc
index 5f90763f7f..53f4566815 100644
--- a/meta/conf/machine/include/arm/arch-arm64.inc
+++ b/meta/conf/machine/include/arm/arch-arm64.inc
@@ -4,7 +4,7 @@ require conf/machine/include/arm/arch-armv7ve.inc
 
 TUNEVALID[aarch64] = "Enable instructions for aarch64"
 
-MACHINEOVERRIDES .= "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 
':aarch64', '' ,d)}"
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 
'aarch64:', '' ,d)}"
 
 # Little Endian base configs
 AVAILTUNES += "aarch64 aarch64_be"
-- 
2.12.0

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


[OE-core] [PATCH 1/6] arch-armv8a.inc: Correct PACKAGE_EXTRA_ARCHS_tune-armv8a-*

2019-04-02 Thread Peter Kjellerstedt
The armv8a tune specific PACKAGE_EXTRA_ARCHS contained tune feature
names like "crc" and "crypto" rather than package architecture names
like "armv8a-crc" and "armv8a-crypto".

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/arm/arch-armv8a.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc 
b/meta/conf/machine/include/arm/arch-armv8a.inc
index 44d0ca4557..f810a1e8fc 100644
--- a/meta/conf/machine/include/arm/arch-armv8a.inc
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -21,9 +21,9 @@ TUNE_FEATURES_tune-armv8a-crc  = 
"${TUNE_FEATURES_tune-armv8a} crc"
 TUNE_FEATURES_tune-armv8a-crypto   = "${TUNE_FEATURES_tune-armv8a} 
crypto"
 TUNE_FEATURES_tune-armv8a-crc-crypto   = "${TUNE_FEATURES_tune-armv8a-crc} 
crypto"
 PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a"
-PACKAGE_EXTRA_ARCHS_tune-armv8a-crc= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
-PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
-PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crc= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} armv8a-crc"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} armv8a-crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} armv8a-crypto armv8a-crc-crypto"
 BASE_LIB_tune-armv8a   = "lib64"
 BASE_LIB_tune-armv8a-crc   = "lib64"
 BASE_LIB_tune-armv8a-crypto= "lib64"
-- 
2.12.0

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


[OE-core] [PATCHv2] base.bbclass, staging.bbclass: Move prepare_recipe_sysroot task dependency

2019-04-02 Thread Peter Kjellerstedt
Move prepare_recipe_sysroot's task dependency on populate_sysroot from
base.bbclass (where it was specified in the middle of do_configure's
definition) to staging.bbclass (where the rest of
do_prepare_recipe_sysroot is defined). This was a left-over from when
recipe specific sysroots were introduced in commit 809746f5 and the
task dependency on populate_sysroot was moved from do_configure to
do_prepare_recipe_sysroot.

Signed-off-by: Peter Kjellerstedt 
---

PATCHv2: Removed the Change-Id footer from the commit message.

 meta/classes/base.bbclass| 1 -
 meta/classes/staging.bbclass | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 8ece51fe42..d0b82d747d 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -310,7 +310,6 @@ CLEANBROKEN = "0"
 
 addtask configure after do_patch
 do_configure[dirs] = "${B}"
-do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"
 base_do_configure() {
if [ -n "${CONFIGURESTAMPFILE}" -a -e "${CONFIGURESTAMPFILE}" ]; then
if [ "`cat ${CONFIGURESTAMPFILE}`" != "${BB_TASKHASH}" ]; then
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index c9bcd745fe..062b2817c8 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -577,6 +577,7 @@ python extend_recipe_sysroot() {
 }
 extend_recipe_sysroot[vardepsexclude] += "MACHINE_ARCH PACKAGE_EXTRA_ARCHS 
SDK_ARCH BUILD_ARCH SDK_OS BB_TASKDEPDATA"
 
+do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"
 python do_prepare_recipe_sysroot () {
 bb.build.exec_func("extend_recipe_sysroot", d)
 }
-- 
2.12.0

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


[OE-core] [PATCH] base.bbclass, staging.bbclass: Move prepare_recipe_sysroot task dependency

2019-04-02 Thread Peter Kjellerstedt
Move prepare_recipe_sysroot's task dependency on populate_sysroot from
base.bbclass (where it was specified in the middle of do_configure's
definition) to staging.bbclass (where the rest of
do_prepare_recipe_sysroot is defined). This was a left-over from when
recipe specific sysroots were introduced in commit 809746f5 and the
task dependency on populate_sysroot was moved from do_configure to
do_prepare_recipe_sysroot.

Change-Id: I0512991e90d88a86852054062709e8b6aacc61af
Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/base.bbclass| 1 -
 meta/classes/staging.bbclass | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 8ece51fe42..d0b82d747d 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -310,7 +310,6 @@ CLEANBROKEN = "0"
 
 addtask configure after do_patch
 do_configure[dirs] = "${B}"
-do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"
 base_do_configure() {
if [ -n "${CONFIGURESTAMPFILE}" -a -e "${CONFIGURESTAMPFILE}" ]; then
if [ "`cat ${CONFIGURESTAMPFILE}`" != "${BB_TASKHASH}" ]; then
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index c9bcd745fe..062b2817c8 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -577,6 +577,7 @@ python extend_recipe_sysroot() {
 }
 extend_recipe_sysroot[vardepsexclude] += "MACHINE_ARCH PACKAGE_EXTRA_ARCHS 
SDK_ARCH BUILD_ARCH SDK_OS BB_TASKDEPDATA"
 
+do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"
 python do_prepare_recipe_sysroot () {
 bb.build.exec_func("extend_recipe_sysroot", d)
 }
-- 
2.12.0

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


Re: [OE-core] [PATCH 4/4] relocatable: add file existence checking in relocatable_native_pcfiles

2019-03-20 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Jiang Lu
> Sent: den 20 mars 2019 10:39
> To: lu.ji...@windriver.com; openembedded-core@lists.openembedded.org;
> richard.pur...@linuxfoundation.org
> Subject: [OE-core] [PATCH 4/4] relocatable: add file existence checking
> in relocatable_native_pcfiles
> 
> Some package may create a ${libdir}/pkgconfig directory in its sysroot
> without .pc file. It leads following error:
> sed: can't read ${sysroot}/${libdir}/pkgconfig/*.pc: No such file or
> directory
> 
> To avoid this, add a file existence checking in
> relocatable_native_pcfiles()
> before sed.
> 
> Signed-off-by: Jiang Lu 
> ---
>  meta/classes/relocatable.bbclass | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/classes/relocatable.bbclass
> b/meta/classes/relocatable.bbclass
> index 582812c1cf..eb9989d18c 100644
> --- a/meta/classes/relocatable.bbclass
> +++ b/meta/classes/relocatable.bbclass
> @@ -7,11 +7,13 @@ python relocatable_binaries_preprocess() {
>  }
> 
>  relocatable_native_pcfiles () {
> - if [ -d ${SYSROOT_DESTDIR}${libdir}/pkgconfig ]; then
> + filecnt=`ls -l ${SYSROOT_DESTDIR}${libdir}/pkgconfig/*.pc 2>/dev/null | 
> wc -l`
> + if [ $filecnt -gt 0 ]; then
>   rel=${@os.path.relpath(d.getVar('base_prefix'), 
> d.getVar('libdir') + "/pkgconfig")}
>   sed -i -e "s:${base_prefix}:\${pcfiledir}/$rel:g" 
> ${SYSROOT_DESTDIR}${libdir}/pkgconfig/*.pc
>   fi
> - if [ -d ${SYSROOT_DESTDIR}${datadir}/pkgconfig ]; then
> + filecnt=`ls -l ${SYSROOT_DESTDIR}${datadir}/pkgconfig/*.pc 2>/dev/null 
> | wc -l`
> + if [ $filecnt -gt 0 ]; then
>   rel=${@os.path.relpath(d.getVar('base_prefix'), 
> d.getVar('datadir') + "/pkgconfig")}
>   sed -i -e "s:${base_prefix}:\${pcfiledir}/$rel:g" 
> ${SYSROOT_DESTDIR}${datadir}/pkgconfig/*.pc
>   fi
> --
> 2.17.1

May I suggest the following instead:

relocatable_native_pcfiles () {
files=$(find ${SYSROOT_DESTDIR}${libdir}/pkgconfig -name '*.pc' 
2>/dev/null)
if [ "$files" ]; then
rel=${@os.path.relpath(d.getVar('base_prefix'), 
d.getVar('libdir') + "/pkgconfig")}
sed -i -e "s:${base_prefix}:\${pcfiledir}/$rel:g" $files
fi
files=$(find ${SYSROOT_DESTDIR}${datadir}/pkgconfig -name '*.pc' 
2>/dev/null)
if [ "$files" ]; then
rel=${@os.path.relpath(d.getVar('base_prefix'), 
d.getVar('datadir') + "/pkgconfig")}
sed -i -e "s:${base_prefix}:\${pcfiledir}/$rel:g" $files
fi
}

//Peter

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


Re: [OE-core] [PATCH v4 1/2] openssl: Remove the c_rehash shell re-implementation

2019-03-19 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Otavio Salvador
> Sent: den 19 mars 2019 14:57
> To: OpenEmbedded Core Mailing List  c...@lists.openembedded.org>
> Cc: Otavio Salvador 
> Subject: [OE-core] [PATCH v4 1/2] openssl: Remove the c_rehash shell
> re-implementation
> 
> We had a c_rehash shell re-implementation being used for the native
> package however the ca-certificates now uses the openssl rehash
> internal application so there is no use for the c_rehash anymore.
> 
> Signed-off-by: Otavio Salvador 
> ---
> 
> Changes in v4:
> - remove perlnative requirement
> 
> Changes in v3:
> - remove c_rehash completely
> - fix ca-certificates recipe comment
> 
> Changes in v2:
> - updated commit log
> 
>  .../openssl/openssl/openssl-c_rehash.sh   | 222 --
>  .../openssl/openssl_1.1.1a.bb |  15 +-
>  .../ca-certificates_20190110.bb   |   2 +-
>  3 files changed, 2 insertions(+), 237 deletions(-)
>  delete mode 100644 
> meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
> 
> diff --git a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh 
> b/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
> deleted file mode 100644
> index 6620fdcb53..00
> --- a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
> +++ /dev/null
> @@ -1,222 +0,0 @@

[cut]

> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb 
> b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> index 4a626a4fcd..c5900ad536 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> @@ -9,11 +9,8 @@ SECTION = "libs/network"
>  LICENSE = "openssl"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
> 
> -DEPENDS = "hostperl-runtime-native"
> -
>  SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
> file://run-ptest \
> -   file://openssl-c_rehash.sh \
> file://0001-skip-test_symbol_presence.patch \
> 
> file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
> file://afalg.patch \
> @@ -149,12 +146,6 @@ do_install_append_class-native () {
>   SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
>   SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
>   OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
> -
> - # Install a custom version of c_rehash that can handle sysroots 
> properly.
> - # This version is used for example when installing ca-certificates 
> during
> - # image creation.
> - install -Dm 0755 ${WORKDIR}/openssl-c_rehash.sh ${D}${bindir}/c_rehash
> - sed -i -e 's,/etc/openssl,${sysconfdir}/ssl,g' ${D}${bindir}/c_rehash
>  }
> 
>  do_install_append_class-nativesdk () {
> @@ -196,7 +187,7 @@ FILES_libcrypto = "${libdir}/libcrypto${SOLIBS}"
>  FILES_libssl = "${libdir}/libssl${SOLIBS}"
>  FILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
>  FILES_${PN}-engines = "${libdir}/engines-1.1"
> -FILES_${PN}-misc = "${libdir}/ssl-1.1/misc ${bindir}/c_rehash"
> +FILES_${PN}-misc = "${libdir}/ssl-1.1/misc"
>  FILES_${PN} =+ "${libdir}/ssl-1.1/*"
>  FILES_${PN}_append_class-nativesdk = " 
> ${SDKPATHNATIVE}/environment-setup.d/openssl.sh"
> 

You should remove the following line too:

RDEPENDS_${PN}-misc = "perl"

so we actually get rid of the perl dependency.

> @@ -211,7 +202,3 @@ RREPLACES_openssl-conf = "openssl10-conf"
>  RCONFLICTS_openssl-conf = "openssl10-conf"
> 
>  BBCLASSEXTEND = "native nativesdk"
> -
> -inherit multilib_script
> -
> -MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
> diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb 
> b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
> index b9f57900c8..4c0425302f 100644
> --- a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
> +++ b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
> @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
> "file://debian/copyright;md5=aeb420429b1659507e0a5a1b123e8308
>  DEPENDS = ""
>  DEPENDS_class-native = "openssl-native"
>  DEPENDS_class-nativesdk = "openssl-native"
> -# Need c_rehash from openssl and run-parts from debianutils
> +# Need rehash from openssl and run-parts from debianutils
>  PACKAGE_WRITE_DEPS += "openssl-native debianutils-native"
> 
>  SRCREV = "c28799b138b044c963d24c4a69659b6e5486e3be"
> --
> 2.21.0

//Peter

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


Re: [OE-core] [oe-core 2/2] glib-networking:enable glib-networking complie as native package

2019-03-19 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Jiang Lu
> Sent: den 19 mars 2019 08:55
> To: lu.ji...@windriver.com; openembedded-core@lists.openembedded.org
> Subject: [OE-core] [oe-core 2/2] glib-networking:enable glib-networking
> complie as native package
> 
> Enable glib-networking compile as a native package, for it is depended
> by
> libsoup.
> 
> Signed-off-by: Jiang Lu 
> ---
>  .../glib-networking/glib-networking_2.58.0.bb | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/meta/recipes-core/glib-networking/glib-
> networking_2.58.0.bb b/meta/recipes-core/glib-networking/glib-
> networking_2.58.0.bb
> index f3190e1cae..35b4a3fa76 100644
> --- a/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> +++ b/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> @@ -29,3 +29,34 @@ FILES_${PN} += "\
>  "
>  FILES_${PN}-dev += "${libdir}/gio/modules/libgio*.la"
>  FILES_${PN}-staticdev += "${libdir}/gio/modules/libgio*.a"
> +
> +# Make sure we compile with ca-certificates support enabled.
> +PACKAGECONFIG_append = " ca-certificates"
> +
> +DEPENDS += "ca-certificates"
> +RDEPENDS_${PN} += "ca-certificates"
> +
> +# We need native version for ostree-/flatpak-native.
> +BBCLASSEXTEND = "native"
> +# OE-core's relocatable.bbclass assumes that every package which
> +# ends up creating a ${libdir}/pkgconfig directory in its sysroot
> +# will always also install .pc-files there and tries to uncondi-
> +# tionally update paths in those files using globbing that fails
> +# if no such files are present. This presumption is not true for
> +# glib-networking which happens to create a directory by dereferencing
> +# a GIO pkgconfig variable which in turn is defined relative to
> +# the pkgconfig directory (${pcfiledir}/../...), causing pkgconfig
> +# to get created.

How about fixing relocatable_native_pcfiles() in relocatable.bbclass 
instead so that it ignores empty pkgconfig directories?

> +#
> +# Could be worked around in the upatream recipe but since that
> +# does not provide/create native versions of the package and since
> +# this problem is related to native packages, we work around it here.
> +#
> +do_install_append_class-native () {
> +for _pc in ${D}${libdir}/pkgconfig/*.pc; do
> +case $_pc in
> +*'*.pc') rm -fr ${D}${libdir}/pkgconfig;;
> +*.pc)break;;
> +esac
> +done

Why complicate things? Just remove the directory if it exists 
and is empty:

rmdir ${D}${libdir}/pkgconfig 2>/dev/null || :

> +}
> --
> 2.17.1

//Peter

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


[OE-core] Where are the mails from patchwork (was: RE: [PATCH] [PATCH] openssl:upgrade to 1.1.1b)

2019-03-18 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Alexander Kanavin
> Sent: den 18 mars 2019 09:52
> To: Hong Liu 
> Cc: OE-core 
> Subject: Re: [OE-core] [PATCH] [PATCH] openssl:upgrade to 1.1.1b
> 
> On Mon, 18 Mar 2019 at 02:20, Hong Liu 
> wrote:
> > -LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
> > +LIC_FILES_CHKSUM = "file://LICENSE;md5=d343e62fc9c833710bbbed25f27364c8"
> 
> You need to explain what changed (in the commit message).
> Try 'devtool upgrade openssl', it will make a diff of the two licenses
> for you.
> 
> Also, openssl10 needs a similar upgrade.
> 
> Alex

Whatever happened to the mails from patchwork that used to 
automatically complain about things like this with:

* Issue LIC_FILES_CHKSUM changed on target openssl but there is no 
"License-Update" tag in commit message 
[test_lic_files_chksum_modified_not_mentioned] 
  Suggested fixInclude "License-Update: " into the commit 
message with a brief description
  Current checksum file://LICENCE;md5=d57d511030c9d66ef5f5966bee5a7eff
  New checksum file://LICENCE;md5=d343e62fc9c833710bbbed25f27364c8

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


Re: [OE-core] Can't build product that uses DEFAULTTUNE="arm926ejs"

2019-03-16 Thread Peter Kjellerstedt
> -Original Message-
> From: Khem Raj 
> Sent: den 15 mars 2019 06:09
> To: Peter Kjellerstedt 
> Cc: OE Core (openembedded-core@lists.openembedded.org)  c...@lists.openembedded.org>
> Subject: Re: Can't build product that uses DEFAULTTUNE="arm926ejs"
> 
> On Mon, Mar 11, 2019 at 6:49 AM Peter Kjellerstedt
>  wrote:
> >
> > > -Original Message-
> > > From: Khem Raj 
> > > Sent: den 11 mars 2019 05:24
> > > To: Peter Kjellerstedt 
> > > Cc: OE Core (openembedded-core@lists.openembedded.org)
>  > > c...@lists.openembedded.org>
> > > Subject: Re: Can't build product that uses DEFAULTTUNE="arm926ejs"
> > >
> > > On Sun, Mar 10, 2019 at 9:20 PM Peter Kjellerstedt
> > >  wrote:
> > > >
> > > > I'm trying to build with master of OE-core and one of our
> products
> > > > now fails with:
> > > >
> > > > ERROR:  OE-core's config sanity checker detected a potential
> misconfiguration.
> > > > Either fix the cause of this error or at your own risk
> disable the checker
> > > > (see sanity.conf). Following is the list of potential
> problems / advisories:
> > > >
> > > > Error, the PACKAGE_ARCHS variable (all any noarch arm armv4
> armv4t armv5
> > > > armv5t armv5e armv5te arm926ejste arm926ejse  withheld>) for
> > > > DEFAULTTUNE (arm926ejs) does not contain TUNE_PKGARCH
> (arm926ejst).
> > > >
> > > > I believe this is due to commit ac83d22e (arm-tunes: Remove -
> march
> > > > option if mcpu is already added). If I build with Thud,
> TUNE_PKGARCH
> > > > is "arm926ejste". The  lack of the "e" at the end when building
> with
> > > > master seems to be due to the definition of ARMPKGSFX_DSP as
> > > > "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 'e',
> '', d)}"
> > > > and the fact that after commit ac83d22e, TUNE_FEATURES no longer
> > > > contains 'armv5'.
> > >
> > > right this should now check for armv5t
> >
> > There is no armv5t to check for.
> >
> > > armv5 has been removed from upstream gcc as well. So we only
> support
> > > armv5t variants.
> > >
> > > > //Peter
> >
> > I am by no means any expert on the tuning files (actually they mostly
> > seem like black magic), but I devised an alternative solution for
> > preferring -mcpu over -march that I think is less invasive and without
> > unwanted side effects. I will publish it shortly.
> 
> I saw you sent couple of patch to address this, however I think it can
> be addressed a bit differently and patch could be simple. I would be 
> keen if you try it out and see if that fixes your problem
> 
> https://patchwork.openembedded.org/patch/159591/
> 
> > //Peter

While I agree that your patch will solve the problem with arm926ejs, I 
believe there are advantages in applying my patches instead. In addition 
to fixing the problem with arm926ejs, my patches (patch set 4, not patch 
set 2 that is currently on master-next) also:

* make it so that there is no change to TUNE_FEATURES,
* make it explicit whether -mcpu or -march is used, and
* make the extra arguments added to -mcpu or -march for armv8 explicit.

That last point was something that confused me when I read the original 
tune files. I did not realize that those extra features were added to 
whatever -mcpu or -march happened to be added to TUNE_CCARGS before the 
arch-armv8a.inc file was included (especially as it was written to make 
it look as they were only added to the -march option).

//Peter

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


[OE-core] [PATCHv4 1/2] Revert "arm-tunes: Remove -march option if mcpu is already added"

2019-03-14 Thread Peter Kjellerstedt
This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.

This solution had unforeseen side effects, which, e.g., lead to the
following sanity error if trying to build with the arm926ejs default
tune:

Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
armv5 armv5t armv5e armv5te arm926ejste arm926ejse ) for DEFAULTTUNE (arm926ejs) does not contain
TUNE_PKGARCH (arm926ejst).

An alternative solution will follow, which only affects the -mcpu and
-march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  4 +---
 meta/conf/machine/include/tune-arm920t.inc   |  4 +---
 meta/conf/machine/include/tune-arm926ejs.inc |  4 +---
 meta/conf/machine/include/tune-arm9tdmi.inc  |  4 +---
 meta/conf/machine/include/tune-cortexa15.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa17.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa5.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa7.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa8.inc  | 19 +++-
 meta/conf/machine/include/tune-cortexa9.inc  | 28 ++--
 meta/conf/machine/include/tune-ep9312.inc|  1 -
 meta/conf/machine/include/tune-iwmmxt.inc|  3 +--
 meta/conf/machine/include/tune-strongarm1100.inc |  3 +--
 meta/conf/machine/include/tune-xscale.inc|  7 ++
 14 files changed, 76 insertions(+), 109 deletions(-)

diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc 
b/meta/conf/machine/include/tune-arm1136jf-s.inc
index d883eba7c9..c5de63e1cc 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv6.inc
 
 TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' 
-mcpu=arm1136jf-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', 
'armv6:', '' ,d)}"
 
 AVAILTUNES += "arm1136jfs"
 ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
-# mcpu is used so don't use armv6 as we don't want march
-TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs"
+TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
 PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6} 
arm1136jfs-vfp"
diff --git a/meta/conf/machine/include/tune-arm920t.inc 
b/meta/conf/machine/include/tune-arm920t.inc
index 42e8ed2b51..c6e74b6772 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' 
-mcpu=arm920t', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', 
'armv4:', '' ,d)}"
 
 AVAILTUNES += "arm920t"
 ARMPKGARCH_tune-arm920t = "arm920t"
-# mcpu is used so don't use armv4t as we don't want march
-TUNE_FEATURES_tune-arm920t = "arm thumb arm920t"
+TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
 PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} arm920t 
arm920tt"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc 
b/meta/conf/machine/include/tune-arm926ejs.inc
index 563d53bc4e..81bcda339b 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv5-dsp.inc
 
 TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' 
-mcpu=arm926ej-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', 
'armv5:', '' ,d)}"
 
 AVAILTUNES += "arm926ejs"
 ARMPKGARCH_tune-arm926ejs = "arm926ejs"
-# mcpu is used so don't use armv5te as we don't want march
-TUNE_FEATURES_tune-arm926ejs = "arm thumb dsp arm926ejs"
+TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
 PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} 
arm926ejste arm926ejse"
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc 
b/meta/conf/machine/include/tune-arm9tdmi.inc
index e03a8b86a0..e9c2b8fcf5 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
 TUNE_CCARGS .= "$

[OE-core] [PATCHv4 2/2] arm-tunes: Prefer the -mcpu option over -march

2019-03-14 Thread Peter Kjellerstedt
Tune files that inherit the arch definitions already define
appropriate -mcpu options, which are equivalent of the correct -march
and -mtune combinations. This is preferred since gcc is getting
stricter and stricter with option check semantics and can now find
incompatible -march and -mcpu options better with every release. It
does an internal feature consistency check and if it finds any
discrepancies between what -mcpu would expand to as compared to
-march, it will flag the options to be incompatible. For the naked eye
it looks wrong, but gcc will translate -mcpu to a given -march
internally and it might not match what we set in these arch files.

The effects are quite subtle, where this can result in configure tests
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.

E.g., with GCC 9, which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ end up
disabled due to configure check failures, e.g., size_t size, ptrdiff_t
sizes, which in turn results in compiling libstdc++ with wanted
features disabled.

This is an alternative solution to the same problem originally
implemented by Khem Raj in commit ac83d22e, but this time only
affecting -mcpu and -march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---

PATCHv2:
* Change all occurrences of TUNE_CCARGS into TUNE_MARCH in
  arch-armv8a.inc

PATCHv3:
* Renamed TUNE_MCPU and TUNE_MARCH to TUNE_CCARGS_MCPU and
  TUNE_CCARGS_MARCH to better match already existing variables, such
  as TUNE_CCARGS_MFPU.
* Added TUNE_CCARGS_FEATURES to handle the extra mcpu/march features
  specified for armv8a/aarch64.

PATCHv4:
* Renamed TUNE_CCARGS_FEATURES to TUNE_CCARGS_ARMV8A_FEATURES and use it
  together with each -mpu or -march that needs it. This should avoid any
  potential problems in case multiple tuning files are included. It also
  makes it explicit that these features are added to the -mcpu and
  -march options, which was only implicit before.

 meta/conf/machine/include/arm/arch-arm.inc   |  5 +
 meta/conf/machine/include/arm/arch-armv4.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv5.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv6.inc |  2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc|  2 +-
 meta/conf/machine/include/arm/arch-armv7ve.inc   |  2 +-
 meta/conf/machine/include/arm/arch-armv8a.inc| 13 +++--
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  2 +-
 meta/conf/machine/include/tune-arm920t.inc   |  2 +-
 meta/conf/machine/include/tune-arm926ejs.inc |  2 +-
 meta/conf/machine/include/tune-arm9tdmi.inc  |  2 +-
 meta/conf/machine/include/tune-cortexa15.inc |  2 +-
 meta/conf/machine/include/tune-cortexa17.inc |  2 +-
 meta/conf/machine/include/tune-cortexa32.inc |  2 +-
 meta/conf/machine/include/tune-cortexa35.inc |  2 +-
 meta/conf/machine/include/tune-cortexa5.inc  |  2 +-
 meta/conf/machine/include/tune-cortexa53.inc |  2 +-
 meta/conf/machine/include/tune-cortexa7.inc  |  2 +-
 meta/conf/machine/include/tune-cortexa72.inc |  2 +-
 meta/conf/machine/include/tune-cortexa8.inc  |  2 +-
 meta/conf/machine/include/tune-cortexa9.inc  |  2 +-
 meta/conf/machine/include/tune-ep9312.inc|  2 +-
 meta/conf/machine/include/tune-iwmmxt.inc|  2 +-
 meta/conf/machine/include/tune-strongarm1100.inc |  2 +-
 meta/conf/machine/include/tune-thunderx.inc  |  2 +-
 meta/conf/machine/include/tune-xscale.inc|  2 +-
 26 files changed, 36 insertions(+), 30 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-arm.inc 
b/meta/conf/machine/include/arm/arch-arm.inc
index 99625d8417..8144b5dd0d 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -11,6 +11,11 @@ ARMPKGSFX_THUMB ??= ""
 TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'armeb', 
'arm', d)}"
 TUNE_PKGARCH = 
"${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
 
+# Prefer -mcpu= over -arch=
+TUNE_CCARGS_MCPU ??= ""
+TUNE_CCARGS_MARCH ??= ""
+TUNE_CCARGS .= "${@d.getVar('TUNE_CCARGS_MCPU') or 
d.getVar('TUNE_CCARGS_MARCH')}"
+
 ABIEXTENSION = "eabi"
 
 TARGET_FPU = "${@d.getVar('TUNE_CCARGS_MFLOAT') or 'soft'}"
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..dac791e308 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
+TUNE_CCARGS_MARC

[OE-core] [PATCHv3 1/2] Revert "arm-tunes: Remove -march option if mcpu is already added"

2019-03-13 Thread Peter Kjellerstedt
This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.

This solution had unforeseen side effects, which, e.g., lead to the
following sanity error if trying to build with the arm926ejs default
tune:

Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
armv5 armv5t armv5e armv5te arm926ejste arm926ejse ) for DEFAULTTUNE (arm926ejs) does not contain
TUNE_PKGARCH (arm926ejst).

An alternative solution will follow, which only affects the -mcpu and
-march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  4 +---
 meta/conf/machine/include/tune-arm920t.inc   |  4 +---
 meta/conf/machine/include/tune-arm926ejs.inc |  4 +---
 meta/conf/machine/include/tune-arm9tdmi.inc  |  4 +---
 meta/conf/machine/include/tune-cortexa15.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa17.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa5.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa7.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa8.inc  | 19 +++-
 meta/conf/machine/include/tune-cortexa9.inc  | 28 ++--
 meta/conf/machine/include/tune-ep9312.inc|  1 -
 meta/conf/machine/include/tune-iwmmxt.inc|  3 +--
 meta/conf/machine/include/tune-strongarm1100.inc |  3 +--
 meta/conf/machine/include/tune-xscale.inc|  7 ++
 14 files changed, 76 insertions(+), 109 deletions(-)

diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc 
b/meta/conf/machine/include/tune-arm1136jf-s.inc
index d883eba7c9..c5de63e1cc 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv6.inc
 
 TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' 
-mcpu=arm1136jf-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', 
'armv6:', '' ,d)}"
 
 AVAILTUNES += "arm1136jfs"
 ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
-# mcpu is used so don't use armv6 as we don't want march
-TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs"
+TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
 PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6} 
arm1136jfs-vfp"
diff --git a/meta/conf/machine/include/tune-arm920t.inc 
b/meta/conf/machine/include/tune-arm920t.inc
index 42e8ed2b51..c6e74b6772 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' 
-mcpu=arm920t', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', 
'armv4:', '' ,d)}"
 
 AVAILTUNES += "arm920t"
 ARMPKGARCH_tune-arm920t = "arm920t"
-# mcpu is used so don't use armv4t as we don't want march
-TUNE_FEATURES_tune-arm920t = "arm thumb arm920t"
+TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
 PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} arm920t 
arm920tt"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc 
b/meta/conf/machine/include/tune-arm926ejs.inc
index 563d53bc4e..81bcda339b 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv5-dsp.inc
 
 TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' 
-mcpu=arm926ej-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', 
'armv5:', '' ,d)}"
 
 AVAILTUNES += "arm926ejs"
 ARMPKGARCH_tune-arm926ejs = "arm926ejs"
-# mcpu is used so don't use armv5te as we don't want march
-TUNE_FEATURES_tune-arm926ejs = "arm thumb dsp arm926ejs"
+TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
 PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} 
arm926ejste arm926ejse"
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc 
b/meta/conf/machine/include/tune-arm9tdmi.inc
index e03a8b86a0..e9c2b8fcf5 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
 TUNE_CCARGS .= "$

[OE-core] [PATCHv3 2/2] arm-tunes: Prefer the -mcpu option over -march

2019-03-13 Thread Peter Kjellerstedt
Tune files that inherit the arch definitions already define
appropriate -mcpu options, which are equivalent of the correct -march
and -mtune combinations. This is preferred since gcc is getting
stricter and stricter with option check semantics and can now find
incompatible -march and -mcpu options better with every release. It
does an internal feature consistency check and if it finds any
discrepancies between what -mcpu would expand to as compared to
-march, it will flag the options to be incompatible. For the naked eye
it looks wrong, but gcc will translate -mcpu to a given -march
internally and it might not match what we set in these arch files.

The effects are quite subtle, where this can result in configure tests
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.

E.g., with GCC 9, which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ end up
disabled due to configure check failures, e.g., size_t size, ptrdiff_t
sizes, which in turn results in compiling libstdc++ with wanted
features disabled.

This is an alternative solution to the same problem originally
implemented by Khem Raj in commit ac83d22e, but this time only
affecting -mcpu and -march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---

PATCHv2:
* Change all occurrences of TUNE_CCARGS into TUNE_MARCH in
  arch-armv8a.inc

PATCHv3:
* Renamed TUNE_MCPU and TUNE_MARCH to TUNE_CCARGS_MCPU and
  TUNE_CCARGS_MARCH to better match already existing variables, such
  as TUNE_CCARGS_MFPU.
* Added TUNE_CCARGS_FEATURES to handle the extra mcpu/march features
  specified for armv8a/aarch64.

 meta/conf/machine/include/arm/arch-arm.inc   | 6 ++
 meta/conf/machine/include/arm/arch-armv4.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv5.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv6.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc| 2 +-
 meta/conf/machine/include/arm/arch-armv7ve.inc   | 2 +-
 meta/conf/machine/include/arm/arch-armv8a.inc| 8 
 meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-
 meta/conf/machine/include/tune-arm920t.inc   | 2 +-
 meta/conf/machine/include/tune-arm926ejs.inc | 2 +-
 meta/conf/machine/include/tune-arm9tdmi.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa15.inc | 2 +-
 meta/conf/machine/include/tune-cortexa17.inc | 2 +-
 meta/conf/machine/include/tune-cortexa32.inc | 2 +-
 meta/conf/machine/include/tune-cortexa35.inc | 2 +-
 meta/conf/machine/include/tune-cortexa5.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa53.inc | 2 +-
 meta/conf/machine/include/tune-cortexa7.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa72.inc | 2 +-
 meta/conf/machine/include/tune-cortexa8.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa9.inc  | 2 +-
 meta/conf/machine/include/tune-ep9312.inc| 2 +-
 meta/conf/machine/include/tune-iwmmxt.inc| 2 +-
 meta/conf/machine/include/tune-strongarm1100.inc | 2 +-
 meta/conf/machine/include/tune-thunderx.inc  | 2 +-
 meta/conf/machine/include/tune-xscale.inc| 2 +-
 26 files changed, 34 insertions(+), 28 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-arm.inc 
b/meta/conf/machine/include/arm/arch-arm.inc
index 99625d8417..188cf8b473 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -11,6 +11,12 @@ ARMPKGSFX_THUMB ??= ""
 TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'armeb', 
'arm', d)}"
 TUNE_PKGARCH = 
"${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
 
+# Prefer -mcpu= over -arch=
+TUNE_CCARGS_MCPU ??= ""
+TUNE_CCARGS_MARCH ??= ""
+TUNE_CCARGS_FEATURES ??= ""
+TUNE_CCARGS .= "${@d.getVar('TUNE_CCARGS_MCPU') or 
d.getVar('TUNE_CCARGS_MARCH')}${TUNE_CCARGS_FEATURES}"
+
 ABIEXTENSION = "eabi"
 
 TARGET_FPU = "${@d.getVar('TUNE_CCARGS_MFLOAT') or 'soft'}"
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..dac791e308 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
+TUNE_CCARGS_MARCH .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it 
when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any 
checkvalues in value, now it does 
 # checkvalues

[OE-core] [PATCHv2 1/2] Revert "arm-tunes: Remove -march option if mcpu is already added"

2019-03-13 Thread Peter Kjellerstedt
This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.

This solution had unforeseen side effects, which, e.g., lead to the
following sanity error if trying to build with the arm926ejs default
tune:

Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
armv5 armv5t armv5e armv5te arm926ejste arm926ejse ) for DEFAULTTUNE (arm926ejs) does not contain
TUNE_PKGARCH (arm926ejst).

An alternative solution will follow, which only affects the -mcpu and
-march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  4 +---
 meta/conf/machine/include/tune-arm920t.inc   |  4 +---
 meta/conf/machine/include/tune-arm926ejs.inc |  4 +---
 meta/conf/machine/include/tune-arm9tdmi.inc  |  4 +---
 meta/conf/machine/include/tune-cortexa15.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa17.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa5.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa7.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa8.inc  | 19 +++-
 meta/conf/machine/include/tune-cortexa9.inc  | 28 ++--
 meta/conf/machine/include/tune-ep9312.inc|  1 -
 meta/conf/machine/include/tune-iwmmxt.inc|  3 +--
 meta/conf/machine/include/tune-strongarm1100.inc |  3 +--
 meta/conf/machine/include/tune-xscale.inc|  7 ++
 14 files changed, 76 insertions(+), 109 deletions(-)

diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc 
b/meta/conf/machine/include/tune-arm1136jf-s.inc
index d883eba7c9..c5de63e1cc 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv6.inc
 
 TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' 
-mcpu=arm1136jf-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', 
'armv6:', '' ,d)}"
 
 AVAILTUNES += "arm1136jfs"
 ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
-# mcpu is used so don't use armv6 as we don't want march
-TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs"
+TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
 PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6} 
arm1136jfs-vfp"
diff --git a/meta/conf/machine/include/tune-arm920t.inc 
b/meta/conf/machine/include/tune-arm920t.inc
index 42e8ed2b51..c6e74b6772 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' 
-mcpu=arm920t', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', 
'armv4:', '' ,d)}"
 
 AVAILTUNES += "arm920t"
 ARMPKGARCH_tune-arm920t = "arm920t"
-# mcpu is used so don't use armv4t as we don't want march
-TUNE_FEATURES_tune-arm920t = "arm thumb arm920t"
+TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
 PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} arm920t 
arm920tt"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc 
b/meta/conf/machine/include/tune-arm926ejs.inc
index 563d53bc4e..81bcda339b 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv5-dsp.inc
 
 TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' 
-mcpu=arm926ej-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', 
'armv5:', '' ,d)}"
 
 AVAILTUNES += "arm926ejs"
 ARMPKGARCH_tune-arm926ejs = "arm926ejs"
-# mcpu is used so don't use armv5te as we don't want march
-TUNE_FEATURES_tune-arm926ejs = "arm thumb dsp arm926ejs"
+TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
 PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} 
arm926ejste arm926ejse"
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc 
b/meta/conf/machine/include/tune-arm9tdmi.inc
index e03a8b86a0..e9c2b8fcf5 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
 TUNE_CCARGS .= "$

[OE-core] [PATCHv2 2/2] arm-tunes: Prefer the -mcpu option over -march

2019-03-13 Thread Peter Kjellerstedt
Tune files that inherit the arch definitions already define
appropriate -mcpu options, which are equivalent of the correct -march
and -mtune combinations. This is preferred since gcc is getting
stricter and stricter with option check semantics and can now find
incompatible -march and -mcpu options better with every release. It
does an internal feature consistency check and if it finds any
discrepancies between what -mcpu would expand to as compared to
-march, it will flag the options to be incompatible. For the naked eye
it looks wrong, but gcc will translate -mcpu to a given -march
internally and it might not match what we set in these arch files.

The effects are quite subtle, where this can result in configure tests
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.

E.g., with GCC 9, which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ end up
disabled due to configure check failures, e.g., size_t size, ptrdiff_t
sizes, which in turn results in compiling libstdc++ with wanted
features disabled.

This is an alternative solution to the same problem originally
implemented by Khem Raj in commit ac83d22e, but this time only
affecting -mcpu and -march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---

PATCHv2: Change all occurrences of TUNE_CCARGS into TUNE_MARCH in
arch-armv8a.inc

 meta/conf/machine/include/arm/arch-arm.inc   | 5 +
 meta/conf/machine/include/arm/arch-armv4.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv5.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv6.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc| 2 +-
 meta/conf/machine/include/arm/arch-armv7ve.inc   | 2 +-
 meta/conf/machine/include/arm/arch-armv8a.inc| 8 
 meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-
 meta/conf/machine/include/tune-arm920t.inc   | 2 +-
 meta/conf/machine/include/tune-arm926ejs.inc | 2 +-
 meta/conf/machine/include/tune-arm9tdmi.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa15.inc | 2 +-
 meta/conf/machine/include/tune-cortexa17.inc | 2 +-
 meta/conf/machine/include/tune-cortexa32.inc | 2 +-
 meta/conf/machine/include/tune-cortexa35.inc | 2 +-
 meta/conf/machine/include/tune-cortexa5.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa53.inc | 2 +-
 meta/conf/machine/include/tune-cortexa7.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa72.inc | 2 +-
 meta/conf/machine/include/tune-cortexa8.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa9.inc  | 2 +-
 meta/conf/machine/include/tune-ep9312.inc| 2 +-
 meta/conf/machine/include/tune-iwmmxt.inc| 2 +-
 meta/conf/machine/include/tune-strongarm1100.inc | 2 +-
 meta/conf/machine/include/tune-thunderx.inc  | 2 +-
 meta/conf/machine/include/tune-xscale.inc| 2 +-
 26 files changed, 33 insertions(+), 28 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-arm.inc 
b/meta/conf/machine/include/arm/arch-arm.inc
index 99625d8417..1482c3ad03 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -11,6 +11,11 @@ ARMPKGSFX_THUMB ??= ""
 TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'armeb', 
'arm', d)}"
 TUNE_PKGARCH = 
"${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
 
+# Prefer -mcpu= over -arch=
+TUNE_MCPU ??= ""
+TUNE_MARCH ??= ""
+TUNE_CCARGS .= "${@d.getVar('TUNE_MCPU') or d.getVar('TUNE_MARCH')}"
+
 ABIEXTENSION = "eabi"
 
 TARGET_FPU = "${@d.getVar('TUNE_CCARGS_MFLOAT') or 'soft'}"
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..4188ba0637 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
+TUNE_MARCH .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it 
when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any 
checkvalues in value, now it does 
 # checkvalues.issubset(val) which cannot be used for negative test of foo 
neither bar in value
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc 
b/meta/conf/machine/include/arm/arch-armv5.inc
index f9068af9de..ae8df32919 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= &

[OE-core] [PATCH 2/2] arm-tunes: Prefer the -mcpu option over -march

2019-03-11 Thread Peter Kjellerstedt
Tune files that inherit the arch definitions already define
appropriate -mcpu options, which are equivalent of the correct -march
and -mtune combinations. This is preferred since gcc is getting
stricter and stricter with option check semantics and can now find
incompatible -march and -mcpu options better with every release. It
does an internal feature consistency check and if it finds any
discrepancies between what -mcpu would expand to as compared to
-march, it will flag the options to be incompatible. For the naked eye
it looks wrong, but gcc will translate -mcpu to a given -march
internally and it might not match what we set in these arch files.

The effects are quite subtle, where this can result in configure tests
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.

E.g., with GCC 9, which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ end up
disabled due to configure check failures, e.g., size_t size, ptrdiff_t
sizes, which in turn results in compiling libstdc++ with wanted
features disabled.

This is an alternative solution to the same problem originally
implemented by Khem Raj in commit ac83d22e, but this time only
affecting -mcpu and -march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/arm/arch-arm.inc   | 5 +
 meta/conf/machine/include/arm/arch-armv4.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv5.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv6.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc| 2 +-
 meta/conf/machine/include/arm/arch-armv7ve.inc   | 2 +-
 meta/conf/machine/include/arm/arch-armv8a.inc| 2 +-
 meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-
 meta/conf/machine/include/tune-arm920t.inc   | 2 +-
 meta/conf/machine/include/tune-arm926ejs.inc | 2 +-
 meta/conf/machine/include/tune-arm9tdmi.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa15.inc | 2 +-
 meta/conf/machine/include/tune-cortexa17.inc | 2 +-
 meta/conf/machine/include/tune-cortexa32.inc | 2 +-
 meta/conf/machine/include/tune-cortexa35.inc | 2 +-
 meta/conf/machine/include/tune-cortexa5.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa53.inc | 2 +-
 meta/conf/machine/include/tune-cortexa7.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa72.inc | 2 +-
 meta/conf/machine/include/tune-cortexa8.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa9.inc  | 2 +-
 meta/conf/machine/include/tune-ep9312.inc| 2 +-
 meta/conf/machine/include/tune-iwmmxt.inc| 2 +-
 meta/conf/machine/include/tune-strongarm1100.inc | 2 +-
 meta/conf/machine/include/tune-thunderx.inc  | 2 +-
 meta/conf/machine/include/tune-xscale.inc| 2 +-
 26 files changed, 30 insertions(+), 25 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-arm.inc 
b/meta/conf/machine/include/arm/arch-arm.inc
index 99625d8417..1482c3ad03 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -11,6 +11,11 @@ ARMPKGSFX_THUMB ??= ""
 TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'armeb', 
'arm', d)}"
 TUNE_PKGARCH = 
"${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
 
+# Prefer -mcpu= over -arch=
+TUNE_MCPU ??= ""
+TUNE_MARCH ??= ""
+TUNE_CCARGS .= "${@d.getVar('TUNE_MCPU') or d.getVar('TUNE_MARCH')}"
+
 ABIEXTENSION = "eabi"
 
 TARGET_FPU = "${@d.getVar('TUNE_CCARGS_MFLOAT') or 'soft'}"
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..4188ba0637 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
+TUNE_MARCH .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it 
when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any 
checkvalues in value, now it does 
 # checkvalues.issubset(val) which cannot be used for negative test of foo 
neither bar in value
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc 
b/meta/conf/machine/include/arm/arch-armv5.inc
index f9068af9de..ae8df32919 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv5"
 
 TUNEVALID[armv5] = "Enable instructions for ARMv5"
 

[OE-core] [PATCH 1/2] Revert "arm-tunes: Remove -march option if mcpu is already added"

2019-03-11 Thread Peter Kjellerstedt
This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.

This solution had unforeseen side effects, which, e.g., lead to the
following sanity error if trying to build with the arm926ejs default
tune:

Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
armv5 armv5t armv5e armv5te arm926ejste arm926ejse ) for DEFAULTTUNE (arm926ejs) does not contain
TUNE_PKGARCH (arm926ejst).

An alternative solution will follow, which only affects the -mcpu and
-march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  4 +---
 meta/conf/machine/include/tune-arm920t.inc   |  4 +---
 meta/conf/machine/include/tune-arm926ejs.inc |  4 +---
 meta/conf/machine/include/tune-arm9tdmi.inc  |  4 +---
 meta/conf/machine/include/tune-cortexa15.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa17.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa5.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa7.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa8.inc  | 19 +++-
 meta/conf/machine/include/tune-cortexa9.inc  | 28 ++--
 meta/conf/machine/include/tune-ep9312.inc|  1 -
 meta/conf/machine/include/tune-iwmmxt.inc|  3 +--
 meta/conf/machine/include/tune-strongarm1100.inc |  3 +--
 meta/conf/machine/include/tune-xscale.inc|  7 ++
 14 files changed, 76 insertions(+), 109 deletions(-)

diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc 
b/meta/conf/machine/include/tune-arm1136jf-s.inc
index d883eba7c9..c5de63e1cc 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv6.inc
 
 TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' 
-mcpu=arm1136jf-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', 
'armv6:', '' ,d)}"
 
 AVAILTUNES += "arm1136jfs"
 ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
-# mcpu is used so don't use armv6 as we don't want march
-TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs"
+TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
 PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6} 
arm1136jfs-vfp"
diff --git a/meta/conf/machine/include/tune-arm920t.inc 
b/meta/conf/machine/include/tune-arm920t.inc
index 42e8ed2b51..c6e74b6772 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' 
-mcpu=arm920t', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', 
'armv4:', '' ,d)}"
 
 AVAILTUNES += "arm920t"
 ARMPKGARCH_tune-arm920t = "arm920t"
-# mcpu is used so don't use armv4t as we don't want march
-TUNE_FEATURES_tune-arm920t = "arm thumb arm920t"
+TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
 PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} arm920t 
arm920tt"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc 
b/meta/conf/machine/include/tune-arm926ejs.inc
index 563d53bc4e..81bcda339b 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv5-dsp.inc
 
 TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' 
-mcpu=arm926ej-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', 
'armv5:', '' ,d)}"
 
 AVAILTUNES += "arm926ejs"
 ARMPKGARCH_tune-arm926ejs = "arm926ejs"
-# mcpu is used so don't use armv5te as we don't want march
-TUNE_FEATURES_tune-arm926ejs = "arm thumb dsp arm926ejs"
+TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
 PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} 
arm926ejste arm926ejse"
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc 
b/meta/conf/machine/include/tune-arm9tdmi.inc
index e03a8b86a0..e9c2b8fcf5 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
 TUNE_CCARGS .= "$

Re: [OE-core] Can't build product that uses DEFAULTTUNE="arm926ejs"

2019-03-11 Thread Peter Kjellerstedt
> -Original Message-
> From: Khem Raj 
> Sent: den 11 mars 2019 05:24
> To: Peter Kjellerstedt 
> Cc: OE Core (openembedded-core@lists.openembedded.org)  c...@lists.openembedded.org>
> Subject: Re: Can't build product that uses DEFAULTTUNE="arm926ejs"
> 
> On Sun, Mar 10, 2019 at 9:20 PM Peter Kjellerstedt
>  wrote:
> >
> > I'm trying to build with master of OE-core and one of our products
> > now fails with:
> >
> > ERROR:  OE-core's config sanity checker detected a potential 
> > misconfiguration.
> > Either fix the cause of this error or at your own risk disable the 
> > checker
> > (see sanity.conf). Following is the list of potential problems / 
> > advisories:
> >
> > Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t armv5
> > armv5t armv5e armv5te arm926ejste arm926ejse ) for
> > DEFAULTTUNE (arm926ejs) does not contain TUNE_PKGARCH (arm926ejst).
> >
> > I believe this is due to commit ac83d22e (arm-tunes: Remove -march
> > option if mcpu is already added). If I build with Thud, TUNE_PKGARCH 
> > is "arm926ejste". The  lack of the "e" at the end when building with 
> > master seems to be due to the definition of ARMPKGSFX_DSP as
> > "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 'e', '', d)}" 
> > and the fact that after commit ac83d22e, TUNE_FEATURES no longer 
> > contains 'armv5'.
> 
> right this should now check for armv5t

There is no armv5t to check for.

> armv5 has been removed from upstream gcc as well. So we only support
> armv5t variants.
> 
> > //Peter

I am by no means any expert on the tuning files (actually they mostly 
seem like black magic), but I devised an alternative solution for 
preferring -mcpu over -march that I think is less invasive and without 
unwanted side effects. I will publish it shortly.

//Peter

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


[OE-core] Can't build product that uses DEFAULTTUNE="arm926ejs"

2019-03-10 Thread Peter Kjellerstedt
I'm trying to build with master of OE-core and one of our products now 
fails with:

ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
Either fix the cause of this error or at your own risk disable the checker 
(see sanity.conf). Following is the list of potential problems / advisories:

Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t armv5 
armv5t armv5e armv5te arm926ejste arm926ejse ) for 
DEFAULTTUNE (arm926ejs) does not contain TUNE_PKGARCH (arm926ejst).

I believe this is due to commit ac83d22e (arm-tunes: Remove -march option if 
mcpu is already added). If I build with Thud, TUNE_PKGARCH is "arm926ejste".
The  lack of the "e" at the end when building with master seems to be due to 
the definition of ARMPKGSFX_DSP as 
"${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 'e', '', d)}" and 
the fact that after commit ac83d22e, TUNE_FEATURES no longer contains 'armv5'.

//Peter

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


Re: [OE-core] [OE-Core][PATCH] openssl: move c_rehash pkg to avoid perl dep

2019-02-26 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Brad Bishop
> Sent: den 14 januari 2019 23:05
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [OE-Core][PATCH] openssl: move c_rehash pkg to avoid
> perl dep
> 
> Perl and its dependencies have a decent footprint impact.  On my
> xz compressed filesystem:
> 
> 634880: /usr/lib/libperl.so.5.24.4
> 
> Put c_rehash in the openssl-misc package so the dependency can be
> avoided where it isn't needed.
> 
> Change-Id: Iae9bccabfb1c8cfa1401ca6785abc39713d3fdf0
> Signed-off-by: Brad Bishop 
> ---
>  meta/recipes-connectivity/openssl/openssl_1.1.1a.bb | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> index 5c4e69cfb7..7d26654921 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> @@ -190,14 +190,13 @@ FILES_libcrypto = "${libdir}/libcrypto${SOLIBS}"
>  FILES_libssl = "${libdir}/libssl${SOLIBS}"
>  FILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
>  FILES_${PN}-engines = "${libdir}/engines-1.1"
> -FILES_${PN}-misc = "${libdir}/ssl-1.1/misc"
> +FILES_${PN}-misc = "${libdir}/ssl-1.1/misc ${bindir}/c_rehash"
>  FILES_${PN} =+ "${libdir}/ssl-1.1/*"
>  FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}/environment-
> setup.d/openssl.sh"
> 
>  CONFFILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
> 
>  RRECOMMENDS_libcrypto += "openssl-conf"
> -RDEPENDS_${PN}-bin = "perl"
>  RDEPENDS_${PN}-misc = "perl"
>  RDEPENDS_${PN}-ptest += "openssl-bin perl perl-modules bash python"

There is a line at the end of the recipe, which was recently 
added, that says:

MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"

I believe it should now be changed to:

MULTILIB_SCRIPTS = "${PN}-misc:${bindir}/c_rehash"

> --
> 2.20.1

//Peter

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


Re: [OE-core] [PATCH V3] default-distrovars: Drop DISTRO_FEATURES_LIBC

2019-02-26 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Khem Raj
> Sent: den 26 februari 2019 10:01
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH V3] default-distrovars: Drop
> DISTRO_FEATURES_LIBC
> 
> After eglibc was merged into glibc, Kconfig support was also dropped so
> these libc features therefore are not effective anymore and can be
> removed
> 
> Signed-off-by: Khem Raj 
> ---
> v2:
> - Add ipv4 and ipv6 to default distro features, they are not libc
>   specific anyway
> - Remove DISTRO_FEATURES_DEFAULT as this is redundant now
> 
> v3:
> - Remove the use of libc-* overrides in metadata
> 
>  meta/classes/image.bbclass   |  1 -
>  meta/classes/libc-package.bbclass|  5 +
>  meta/conf/bitbake.conf   |  4 ++--
>  meta/conf/distro/include/default-distrovars.inc  | 11 +--
>  meta/conf/distro/include/tclibc-glibc.inc|  5 +
>  meta/conf/local.conf.sample.extended | 16 ++--
>  meta/recipes-core/glib-2.0/glib.inc  |  2 --
>  meta/recipes-core/glibc/glibc_2.29.bb|  3 +--
>  meta/recipes-core/libxml/libxml2_2.9.8.bb|  2 --
>  meta/recipes-devtools/mtools/mtools_4.0.19.bb|  2 --
>  .../findutils/findutils_4.6.0.bb |  2 +-
>  meta/recipes-extended/shadow/shadow.inc  |  2 +-
>  meta/recipes-extended/shadow/shadow_4.6.bb   |  2 +-
>  13 files changed, 11 insertions(+), 46 deletions(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 11927f39f5..6baccb4bb5 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -177,7 +177,6 @@ IMAGE_LINGUAS ?= "de-de fr-fr en-gb"
>  LINGUAS_INSTALL ?= "${@" ".join(map(lambda s: "locale-base-%s" % s,
> d.getVar('IMAGE_LINGUAS').split()))}"
> 
>  python () {
> -if not bb.utils.contains('DISTRO_FEATURES', 'libc-charsets 
> libc-locale-code libc-locales', True, False, d):
>  d.setVar('IMAGE_LINGUAS', '')
>  }

Change the above anonymous Python block to:

IMAGE_LINGUAS = ""

> 
> diff --git a/meta/classes/libc-package.bbclass b/meta/classes/libc-
> package.bbclass
> index 34c9151ae9..06d4984081 100644
> --- a/meta/classes/libc-package.bbclass
> +++ b/meta/classes/libc-package.bbclass
> @@ -39,10 +39,7 @@ python __anonymous () {
>  break
> 
>  # try to fix disable charsets/locales/locale-code compile fail
> -if bb.utils.contains('DISTRO_FEATURES', 'libc-charsets libc-locales 
> libc-locale-code', True, False, d):
> -d.setVar('PACKAGE_NO_GCONV', '0')
> -else:
> -d.setVar('PACKAGE_NO_GCONV', '1')
> +d.setVar('PACKAGE_NO_GCONV', '0')

This can now be changed to a normal variable assignment outside the anonymous 
Python block:

PACKAGE_NO_GCONV = "0"

>  }
> 
>  OVERRIDES_append = ":${TARGET_ARCH}-${TARGET_OS}"
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 435646a946..1c5369ec98 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -123,7 +123,7 @@ TUNE_ASARGS ??= ""
>  TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
>  LIBCEXTENSION ??= ""
>  ABIEXTENSION ??= ""
> -USE_NLS ??= "${@bb.utils.contains('DISTRO_FEATURES', 'libc-locale-code', 
> 'yes', 'no', d)}"
> +USE_NLS ??= "yes"
>  SDKUSE_NLS ??= "yes"
> 
>  TARGET_ARCH = "${TUNE_ARCH}"
> @@ -820,7 +820,7 @@ IMAGE_FEATURES += "${EXTRA_IMAGE_FEATURES}"
>  # Native distro features (will always be used for -native, even if they
>  # are not enabled for target)
>  DISTRO_FEATURES_NATIVE ?= "x11 ipv6 xattr"
> -DISTRO_FEATURES_NATIVESDK ?= "x11 libc-charsets libc-locales 
> libc-locale-code"
> +DISTRO_FEATURES_NATIVESDK ?= "x11"
> 
>  # Normally target distro features will not be applied to native builds:
>  # Native distro features on this list will use the target feature value
> diff --git a/meta/conf/distro/include/default-distrovars.inc 
> b/meta/conf/distro/include/default-distrovars.inc
> index 76edff6480..d57329ec17 100644
> --- a/meta/conf/distro/include/default-distrovars.inc
> +++ b/meta/conf/distro/include/default-distrovars.inc
> @@ -10,16 +10,7 @@ LOCALE_UTF8_ONLY ?= "0"
>  LOCALE_UTF8_IS_DEFAULT ?= "1"
>  LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0"
> 
> -DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 irda largefile 
> pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11"
> -DISTRO_FEATURES_LIBC_DEFAULT ?= "ipv4 ipv6 libc-backtrace libc-big-macros 
> libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt \
> - libc-crypt-ufc libc-db-aliases 
> libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse \
> - libc-getlogin libc-idn libc-inet-anl 
> libc-libm libc-locales libc-locale-code \
> - libc-memusage libc-nsswitch libc-rcmd 
> libc-rtld-debug 

Re: [OE-core] [thud][PATCH 1/2] libaio: Extend to native

2019-02-25 Thread Peter Kjellerstedt
> -Original Message-
> From: akuster808 
> Sent: den 22 februari 2019 16:21
> To: Peter Kjellerstedt 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [thud][PATCH 1/2] libaio: Extend to native
> 
> On 2/22/19 3:00 AM, Peter Kjellerstedt wrote:
> > *ping*
> >
> > //Peter
> 
> you mean this?
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-
> extended/libaio?h=thud=40350b46d5c053b4336cc128922f44ce80e7da9a

No. That one extended the recipe to nativesdk, my patch extends it 
for native as well.

This is the one I want:

https://patchwork.openembedded.org/patch/157392/

//Peter

> >> -Original Message-
> >> From: openembedded-core-boun...@lists.openembedded.org
>  On Behalf Of Peter
> Kjellerstedt
> >> Sent: den 22 december 2018 23:13
> >> To: openembedded-core@lists.openembedded.org
> >> Subject: [OE-core] [thud][PATCH 1/2] libaio: Extend to native
> >>
> >> From: Peter Kjellerstedt 
> >>
> >> lvm2 currently requires libaio. So building lvm2-native will result
> in
> >> the following error.
> >>
> >>   ERROR: Required build target 'lvm2-native' has no buildable
> providers.
> >>   Missing or unbuildable dependency chain was: ['lvm2-native',
> 'libaio-native']
> >>
> >> Extend libaio to native to fix this issue.
> >>
> >> Signed-off-by: Peter Kjellerstedt 
> >> Signed-off-by: Richard Purdie 
> >> ---
> >>
> >> This is a backport from master.
> >>
> >>  meta/recipes-extended/libaio/libaio_0.3.111.bb | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/recipes-extended/libaio/libaio_0.3.111.bb
> b/meta/recipes-extended/libaio/libaio_0.3.111.bb
> >> index 04b50b61ec..8e1cd349a0 100644
> >> --- a/meta/recipes-extended/libaio/libaio_0.3.111.bb
> >> +++ b/meta/recipes-extended/libaio/libaio_0.3.111.bb
> >> @@ -20,4 +20,4 @@ do_install () {
> >>  oe_runmake install DESTDIR=${D}
> >>  }
> >>
> >> -BBCLASSEXTEND = "nativesdk"
> >> +BBCLASSEXTEND = "native nativesdk"
> >> --
> >> 2.12.0

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


Re: [OE-core] [thud][PATCH 1/2] libaio: Extend to native

2019-02-22 Thread Peter Kjellerstedt
*ping*

//Peter

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
>  On Behalf Of Peter 
> Kjellerstedt
> Sent: den 22 december 2018 23:13
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [thud][PATCH 1/2] libaio: Extend to native
> 
> From: Peter Kjellerstedt 
> 
> lvm2 currently requires libaio. So building lvm2-native will result in
> the following error.
> 
>   ERROR: Required build target 'lvm2-native' has no buildable providers.
>   Missing or unbuildable dependency chain was: ['lvm2-native', 
> 'libaio-native']
> 
> Extend libaio to native to fix this issue.
> 
> Signed-off-by: Peter Kjellerstedt 
> Signed-off-by: Richard Purdie 
> ---
> 
> This is a backport from master.
> 
>  meta/recipes-extended/libaio/libaio_0.3.111.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-extended/libaio/libaio_0.3.111.bb 
> b/meta/recipes-extended/libaio/libaio_0.3.111.bb
> index 04b50b61ec..8e1cd349a0 100644
> --- a/meta/recipes-extended/libaio/libaio_0.3.111.bb
> +++ b/meta/recipes-extended/libaio/libaio_0.3.111.bb
> @@ -20,4 +20,4 @@ do_install () {
>  oe_runmake install DESTDIR=${D}
>  }
> 
> -BBCLASSEXTEND = "nativesdk"
> +BBCLASSEXTEND = "native nativesdk"
> --
> 2.12.0

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


Re: [OE-core] [PATCH 2/2] glib-networking: upgrade 2.54.1 -> 2.58.0

2019-02-21 Thread Peter Kjellerstedt
This does not build any more if USE_NLS = "no" is used. Has anyone 
looked at making this work together with meson? Otherwise I guess 
there is trouble ahead now that more and more packages are being 
converted to use meson, since the code in gettext.bbclass currently 
only supports autotools. A quick look at meson's i18n.py module does 
not indicate that there is any easy way to disable the gettext 
support, corresponding to autotools' --disable-nls. Apparently it 
was discussed in https://github.com/mesonbuild/meson/issues/821, but 
it seems they only added detection of the gettext tools without 
adding support for disabling gettext and then closed the issue.

Looking at 1d6648102 (json-glib: fix native build), it seems Ross 
encountered a similar problem for json-glib and opted to workaround 
the problem by overriding USE_NLS. However, that does not seem like 
a long term solution...

//Peter

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Anuj Mittal
> Sent: den 20 februari 2019 08:13
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 2/2] glib-networking: upgrade 2.54.1 ->
> 2.58.0
> 
> * Autotools support has been removed upstream, so migrate recipe to
> meson. For changes, see:
> https://gitlab.gnome.org/GNOME/glib-networking/blob/glib-2-58/NEWS
> 
> * Remove unsupported configure options: pkcs11, ca-certificates. See:
> https://bugzilla.gnome.org/show_bug.cgi?id=793281
> https://bugzilla.gnome.org/show_bug.cgi?id=753260
> 
> License-Update: Change to LGPLv2.1
> 
> Signed-off-by: Anuj Mittal 
> ---
>  ...ng_2.54.1.bb => glib-networking_2.58.0.bb} | 26 ++-
>  1 file changed, 14 insertions(+), 12 deletions(-)
>  rename meta/recipes-core/glib-networking/{glib-networking_2.54.1.bb =>
> glib-networking_2.58.0.bb} (40%)
> 
> diff --git a/meta/recipes-core/glib-networking/glib-
> networking_2.54.1.bb b/meta/recipes-core/glib-networking/glib-
> networking_2.58.0.bb
> similarity index 40%
> rename from meta/recipes-core/glib-networking/glib-networking_2.54.1.bb
> rename to meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> index 5d17a824f0..f3190e1cae 100644
> --- a/meta/recipes-core/glib-networking/glib-networking_2.54.1.bb
> +++ b/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> @@ -3,27 +3,29 @@ DESCRIPTION = "glib-networking contains the
> implementations of certain GLib netw
>  HOMEPAGE = "https://gitlab.gnome.org/GNOME/glib-networking/;
>  BUGTRACKER = "http://bugzilla.gnome.org;
> 
> -LICENSE = "LGPLv2"
> -LIC_FILES_CHKSUM =
> "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"
> +LICENSE = "LGPLv2.1"
> +LIC_FILES_CHKSUM =
> "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
> 
>  SECTION = "libs"
>  DEPENDS = "glib-2.0"
> 
> -SRC_URI[archive.md5sum] = "99867463f182c2767bce0c74bc9cc981"
> -SRC_URI[archive.sha256sum] =
> "eaa787b653015a0de31c928e9a17eb57b4ce23c8cf6f277afaec0d685335012f"
> +SRC_URI[archive.md5sum] = "75b14b7e73a67753be9ce307751c661d"
> +SRC_URI[archive.sha256sum] =
> "bdfa0255e031b8ee003cc283002536b77ee76450105f1dc6ab066b9bf4330068"
> 
> -PACKAGECONFIG ??= "ca-certificates gnutls"
> +PACKAGECONFIG ??= "gnutls"
> 
> -# No explicit dependency as it works without ca-certificates installed
> -PACKAGECONFIG[ca-certificates] = "--with-ca-
> certificates=${sysconfdir}/ssl/certs/ca-certificates.crt,--without-ca-
> certificates"
> -PACKAGECONFIG[gnutls] = "--with-gnutls,--without-gnutls,gnutls"
> -PACKAGECONFIG[libproxy] = "--with-libproxy,--without-
> libproxy,libproxy"
> -PACKAGECONFIG[pkcs11] = "--with-pkcs11,--without-pkcs11,p11-kit"
> +PACKAGECONFIG[gnutls] = "-Dgnutls=true,-Dgnutls=false,gnutls"
> +PACKAGECONFIG[libproxy] = "-Dlibproxy_support=true,-
> Dlibproxy_support=false,libproxy"
> 
> -EXTRA_OECONF = "--without-gnome-proxy"
> +EXTRA_OEMESON = "-Dgnome_proxy_support=false"
> 
> +GNOMEBASEBUILDCLASS = "meson"
>  inherit gnomebase gettext upstream-version-is-even gio-module-cache
> 
> -FILES_${PN} += "${libdir}/gio/modules/libgio*.so ${datadir}/dbus-
> 1/services/"
> +FILES_${PN} += "\
> +${libdir}/gio/modules/libgio*.so \
> +${datadir}/dbus-1/services/ \
> +${systemd_user_unitdir} \
> +"
>  FILES_${PN}-dev += "${libdir}/gio/modules/libgio*.la"
>  FILES_${PN}-staticdev += "${libdir}/gio/modules/libgio*.a"
> --
> 2.17.1
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


  1   2   3   4   5   6   7   8   >