Re: [OE-core] [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig

2019-02-21 Thread Richard Purdie
On Thu, 2019-02-21 at 20:09 -0500, Rich Persaud wrote:
> > On Feb 21, 2019, at 18:51, Richard Purdie <
> > richard.pur...@linuxfoundation.org> wrote:
> > 
> > Multiconfig is meant to support this workflow. Unfortunately there
> > are
> > open bugs and people haven't the time to work on it so its stalled.
> > That said, the key pieces are already there.
> > 
> > A picture is worth a thousand words. I thought a demo might
> > interest
> > people and "prove" this can work.
> 
> Thank you for the patches and PoC.  We will test and are motivated to
> see this work.

I've been thinking about what Alejandro and I discussed and I think the
correct fix for the multiconfig code is to filter the BB_TASKDEPDATA at
source in bitbake to remove the multiconfig entries for other
multiconfigs. I'll try and work up a patch for that in the next day or
two as the hacks on my branch that do this are fragile right now.

> I will also be experimenting with the generation of "immutable
> infrastructure" from source code, to learn whether a single Packer.io
> template can be used to both:
> 
> (a) modify binary images, in the traditional Packer model, e.g. start
> a bitbake-generated image in a VM or container, make runtime
> configuration changes, then repack the machine image
> 
> (b) perform automated customization  of _inputs_ to bitbake recipes
> and package source code, such that a machine image built by bitbake +
> Packer template is equivalent to the image generated by Packer at
> runtime
> 
> If feasible, this would combine the agility of image customizations
> with the security of bitbake's reproducible builds and supply chain
> integrity.

(a) definitely sounds easier than (b). I've not used packer.io but I'd
be curious to see how that works out. People do find our image
customisation hard to get to grips with :(

Cheers,

Richard



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


Re: [OE-core] [PATCH v2 3/3] alsa-utils: 1.1.6 -> 1.1.8

2019-02-21 Thread Richard Purdie
On Thu, 2019-02-21 at 22:13 +0200, Tanu Kaskinen wrote:
> SRC_URI was changed to a more reliable source (at least currently the
> ftp server is flaky).
> 
> [...]
>  
> -SRC_URI = "
> ftp://ftp.alsa-project.org/pub/utils/alsa-utils-${PV}.tar.bz2 \
> -  "
> -
> -SRC_URI[md5sum] = "50ae75567459646b843bed78d916b002"
> -SRC_URI[sha256sum] =
> "155caecc40b2220f686f34ba3655a53e3bdbc0586adb1056733949feaaf7d36e"
> +SRC_URI = "
> https://www.alsa-project.org/files/pub/utils/${BP}.tar.bz2;
> +SRC_URI[md5sum] = "54d6f9b483144823d0fc0c26e8cea028"
> +SRC_URI[sha256sum] =
> "fd9bf528922b3829a91913b89a1858c58a0b24271a7b5f529923aa9ea12fa4cf"

Thanks for the upgrades, its much appreciated!

I have a small fixup queued in master-next for this, the SRC_URI uses
alsa-utils-${PV} because of the alsa-utils-scripts recipe. I'll squash
that in when merging if that is ok.

Cheers,

Richard



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


Re: [OE-core] [PATCH] bitbake.conf:update FETCHCMD_wget with --no-passive-ftp

2019-02-21 Thread Richard Purdie
On Fri, 2019-02-22 at 14:03 +0800, Liu Haitao wrote:
> When fetching the source of alsa it would trigger the following
> WARNING:
> 
> > WARNING: alsa-lib-1.1.6-r0 do_fetch: Failed to fetch URL
> > ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.6.tar.bz2,
> > attempting MIRRORS if
> > available
> 
> Bitbake would use wget with "--no-passive" to fetch the source.
> Behind most firewall and NAT
> configurations it could work well.However, in some rare firewall
> configurations,
> active FTP actually works when passive FTP doesn't.
> 
> So disable the use of the passive FTP transfer mode for wget.

As you say, its much more likely that passive ftp would work than
active ftp, so this change would make things worse for more people?

We're trying to get away from having ftp urls in oe-core at all so
hopefully this isn't a big deal.

Cheers,

Richard

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


[OE-core] [PATCH v2 2/2] kernel-fitimage.bbclass: Introduce a way to provide external dtb

2019-02-21 Thread Manjukumar Matha
Currently kernel-fitimage gets the dtb from KERNEL_DEVICETREE, however
there are instances when the DTB file can be generated using other
recipes, provide a way to include the DTB instead of inkernel device
tree.

Add support for external device tree during the creation of fitimage.  If
virtual/dtb is set using PREFERRED_PROVIDER_virtual/dtb = "devicetree", which
inherits the devicetree.bbclass then use the path provided in
EXTERNAL_KERNEL_DEVICETREE else use KERNEL_DEVICETREE during fitimage process

Signed-off-by: Manjukumar Matha 
---
Changelog v2:
Update commit message to indicate PREFERRED_PROVIDER_virtual/dtb = "devicetree"
to set external devicetree recipe

 meta/classes/kernel-fitimage.bbclass | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 8ebd3dd..3adb1c9 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -30,6 +30,13 @@ python __anonymous () {
 if image:
 d.appendVarFlag('do_assemble_fitimage_initramfs', 'depends', ' 
${INITRAMFS_IMAGE}:do_image_complete')
 
+   #check if there are any dtb providers
+providerdtb = d.getVar("PREFERRED_PROVIDER_virtual/dtb")
+if providerdtb:
+d.appendVarFlag('do_assemble_fitimage', 'depends', ' 
virtual/dtb:do_populate_sysroot')
+d.appendVarFlag('do_assemble_fitimage_initramfs', 'depends', ' 
virtual/dtb:do_populate_sysroot')
+d.setVar('EXTERNAL_KERNEL_DEVICETREE', 
"${RECIPE_SYSROOT}/boot/devicetree")
+
 # Verified boot will sign the fitImage and append the public key to
 # U-Boot dtb. We ensure the U-Boot dtb is deployed before assembling
 # the fitImage:
@@ -373,7 +380,8 @@ fitimage_assemble() {
#
# Step 2: Prepare a DTB image section
#
-   if [ -n "${KERNEL_DEVICETREE}" ]; then
+
+   if [ -z "${EXTERNAL_KERNEL_DEVICETREE}" ] && [ -n 
"${KERNEL_DEVICETREE}" ]; then
dtbcount=1
for DTB in ${KERNEL_DEVICETREE}; do
if echo ${DTB} | grep -q '/dts/'; then
@@ -391,6 +399,16 @@ fitimage_assemble() {
done
fi
 
+   if [ -n "${EXTERNAL_KERNEL_DEVICETREE}" ]; then
+   dtbcount=1
+   for DTBFILE in ${EXTERNAL_KERNEL_DEVICETREE}/*.dtb; do
+   DTB=`basename ${DTBFILE}`
+   DTB=$(echo "${DTB}" | tr '/' '_')
+   DTBS="${DTBS} ${DTB}"
+   fitimage_emit_section_dtb ${1} ${DTB} ${DTBFILE}
+   done
+   fi
+
#
# Step 3: Prepare a setup section. (For x86)
#
-- 
2.7.4

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


[OE-core] [PATCH] dpkg: 1.18.25 -> 1.19.4

2019-02-21 Thread kai.kang
From: Kai Kang 

Upgrade dpkg from 1.18.25 to 1.19.4:

* update SRC_URI which DEBIAN_MIRROR
* un-export PERL which causes script scripts/dpkg-architecture.pl fails
  to get cpu type and package arch
* add configure option '--disable-update-alternatives' which causes
  installed-vs-shipped issue
* add patch for dpkg-native to resolve host tar may not support
  options --owner=NAME:ID and --group=NAME:ID
* update context of patches
* drop dpkg-configure.service that apt provides a systemd timer to do it

Signed-off-by: Kai Kang 
---
 meta/recipes-devtools/dpkg/dpkg.inc   | 25 +++--
 ...s-expect-D-to-be-set-when-running-in.patch | 19 ++---
 .../0005-dpkg-compiler.m4-remove-Wvla.patch   | 16 ++-
 ...c-Remove-usage-of-clamp-mtime-in-tar.patch | 12 ++---
 .../dpkg/dpkg/dpkg-configure.service  | 17 
 .../dpkg/dpkg/glibc2.5-sync_file_range.patch  | 11 +---
 .../dpkg/tweak-options-require-tar-1.27.patch | 27 +++
 .../dpkg/{dpkg_1.18.25.bb => dpkg_1.19.4.bb}  | 11 
 8 files changed, 77 insertions(+), 61 deletions(-)
 delete mode 100644 meta/recipes-devtools/dpkg/dpkg/dpkg-configure.service
 create mode 100644 
meta/recipes-devtools/dpkg/dpkg/tweak-options-require-tar-1.27.patch
 rename meta/recipes-devtools/dpkg/{dpkg_1.18.25.bb => dpkg_1.19.4.bb} (73%)

diff --git a/meta/recipes-devtools/dpkg/dpkg.inc 
b/meta/recipes-devtools/dpkg/dpkg.inc
index fe4732d1db..fee7a75814 100644
--- a/meta/recipes-devtools/dpkg/dpkg.inc
+++ b/meta/recipes-devtools/dpkg/dpkg.inc
@@ -9,15 +9,8 @@ RDEPENDS_${PN}_class-native = ""
 
 UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/dpkg/"
 
-inherit autotools gettext perlnative pkgconfig systemd perl-version
+inherit autotools gettext perlnative pkgconfig perl-version
 
-python () {
-if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
-pn = d.getVar('PN')
-d.setVar('SYSTEMD_SERVICE_%s' % (pn), 'dpkg-configure.service')
-}
-
-export PERL = "${bindir}/perl"
 PERL_class-native = "${STAGING_BINDIR_NATIVE}/perl-native/perl"
 
 export PERL_LIBDIR = "${libdir}/perl/${@get_perl_version(d)}"
@@ -29,14 +22,14 @@ EXTRA_OECONF = "\
--with-libz \
--with-libbz2 \
--without-libselinux \
+   TAR=tar \
"
 
+EXTRA_OECONF_append_class-target = " --disable-update-alternatives 
DEB_HOST_ARCH=${DPKG_ARCH}"
+
 PACKAGECONFIG = "liblzma"
 PACKAGECONFIG[liblzma] = "--with-liblzma,--without-liblzma, xz"
 
-EXTRA_OECONF += "TAR=tar"
-EXTRA_OECONF_append_class-target = " DEB_HOST_ARCH=${DPKG_ARCH}"
-
 do_install_append () {
if [ "${PN}" = "dpkg-native" ]; then
# update-alternatives doesn't have an offline mode
@@ -45,16 +38,6 @@ do_install_append () {
else
sed -i -e 's|^#!.*${bindir}/perl-native.*/perl|#!/usr/bin/env 
perl|' ${D}${bindir}/dpkg-*
fi
-
-   if 
${@bb.utils.contains('DISTRO_FEATURES','sysvinit','false','true',d)};then
-   install -d ${D}${systemd_unitdir}/system
-   install -m 0644 ${WORKDIR}/dpkg-configure.service 
${D}${systemd_unitdir}/system/
-   sed -i -e 's,@BASE_BINDIR@,${base_bindir},g' \
-   -e 's,@SYSCONFDIR@,${sysconfdir},g' \
-   -e 's,@BINDIR@,${bindir},g' \
-   -e 's,@SYSTEMD_UNITDIR@,${systemd_unitdir},g' \
-   ${D}${systemd_unitdir}/system/dpkg-configure.service
-   fi
 }
 
 PROV = "virtual/update-alternatives"
diff --git 
a/meta/recipes-devtools/dpkg/dpkg/0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch
 
b/meta/recipes-devtools/dpkg/dpkg/0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch
index 93d870443c..b88be87490 100644
--- 
a/meta/recipes-devtools/dpkg/dpkg/0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch
+++ 
b/meta/recipes-devtools/dpkg/dpkg/0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch
@@ -10,15 +10,16 @@ Upstream-Status: Inappropriate [OE Specific]
 RP 2011/12/07
 ALIMON 2016/05/26
 ALIMON 2017/02/21
+KKang 2019/02/20
 ---
  src/script.c | 44 +++-
  1 file changed, 3 insertions(+), 41 deletions(-)
 
 diff --git a/src/script.c b/src/script.c
-index 2f252ae..768a9d1 100644
+index 0865b95..73ed35d 100644
 --- a/src/script.c
 +++ b/src/script.c
-@@ -97,48 +97,10 @@ setexecute(const char *path, struct stat *stab)
+@@ -96,58 +96,11 @@ setexecute(const char *path, struct stat *stab)
  static const char *
  maintscript_pre_exec(struct command *cmd)
  {
@@ -32,6 +33,8 @@ index 2f252ae..768a9d1 100644
 -  changedir = "/";
 -
 -  if (instdirlen > 0 && !fc_script_chrootless) {
+-  int rc;
+-
 -  if (strncmp(admindir, instdir, instdirlen) != 0)
 -  ohshit(_("admindir must be inside instdir for dpkg to 
work properly"));
 -  if 

[OE-core] [PATCH] bitbake.conf:update FETCHCMD_wget with --no-passive-ftp

2019-02-21 Thread Liu Haitao
When fetching the source of alsa it would trigger the following WARNING:

|WARNING: alsa-lib-1.1.6-r0 do_fetch: Failed to fetch URL
|ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.6.tar.bz2, attempting MIRRORS 
if
|available

Bitbake would use wget with "--no-passive" to fetch the source. Behind most 
firewall and NAT
configurations it could work well.However, in some rare firewall configurations,
active FTP actually works when passive FTP doesn't.

So disable the use of the passive FTP transfer mode for wget.

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

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 435646a946..357de41780 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -666,7 +666,7 @@ SRC_URI[vardepsexclude] += "\
 
 FETCHCMD_svn = "/usr/bin/env svn --non-interactive --trust-server-cert"
 FETCHCMD_cvs = "/usr/bin/env cvs"
-FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 --passive-ftp 
--no-check-certificate"
+FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 --no-passive-ftp 
--no-check-certificate"
 FETCHCMD_bzr = "/usr/bin/env bzr"
 FETCHCMD_hg = "/usr/bin/env hg"
 
-- 
2.17.1

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


Re: [OE-core] [PATCH] devtool: remove duplicate overrides

2019-02-21 Thread Paul Eggleton
As Peter mentions the underlying issue is already mitigated when we read the 
value of 
DEVTOOL_EXTRA_OVERRIDES; for clarity I'd say let's revert this 
(90f667db2219f04e6d61588cd61056d3d8da6d7d). My apologies, I wasn't
paying attention earlier.

Cheers,
Paul

On Wednesday, 23 January 2019 12:32:35 PM NZDT Peter Kjellerstedt wrote:
> This has already been merged, but see below.
> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org  > core-boun...@lists.openembedded.org> On Behalf Of Dan Dedrick
> > Sent: den 21 januari 2019 17:05
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH] devtool: remove duplicate overrides
> > 
> > DEVTOOL_EXTRA_OVERRIDES only needs one entry for each instance of
> > overrides. Previous to these changes it would find every override to
> > SRC_URI and add it to the list. This would duplicate instances where
> > SRC_URI is modified multiple times with the same override like:
> > SRC_URI_append_foo += "file://0001-foo.patch"
> > SRC_URI_append_foo += "file://0002-bar.patch"
> > 
> > A bbappend might also overwrite a SRC_URI override, which would also
> > cause multiple instances to occur.
> > 
> > When there are multiple instances of the same override in
> > DEVTOOL_EXTRA_OVERRIDES it causes devtool modify to fail when creating
> > override branches. The failure occurs when attempting to create the same
> > override branch a second time and looks like this:
> > 
> > The stack trace of python calls that resulted in this exception/failure was:
> > File: 'exec_python_func() autogenerated', lineno: 2, function: 
> >  0001:
> >  *** 0002:devtool_post_patch(d)
> >  0003:
> > File: '/build/poky/meta/classes/devtool-source.bbclass', lineno: 202, 
> > function: devtool_post_patch
> >  0198:
> >  0199:for override in extra_override_list:
> 
> The reference to extra_override_list above indicates that you developed 
> this patch for an older version of OE-Core, since that variable was 
> renamed on master of OE-Core in October when this problem was fixed (see 
> commit 95a92195). However, that fix was made to devtool-source.bbclass, 
> where it uses the value of DEVTOOL_EXTRA_OVERRIDES, instead of to 
> scripts/lib/devtool/standard.py where you made the change. This is 
> probably why you did not notice that the problem had already been fixed.
> 
> >  0200:localdata = bb.data.createCopy(d)
> >  0201:if override in default_overrides:
> >  *** 0202:bb.process.run('git branch devtool-override-%s 
> > %s' % (override, devbranch), cwd=srcsubdir)
> >  0203:else:
> >  0204:# Reset back to the initial commit on a new branch
> >  0205:bb.process.run('git checkout %s -b 
> > devtool-override-%s' % (initial_rev, override), cwd=srcsubdir)
> >  0206:# Run do_patch function with the override applied
> > File: '/build/poky/bitbake/lib/bb/process.py', lineno: 178, function: run
> >  0174:if not stderr is None:
> >  0175:stderr = stderr.decode("utf-8")
> >  0176:
> >  0177:if pipe.returncode != 0:
> >  *** 0178:raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
> >  0179:return stdout, stderr
> > Exception: bb.process.ExecutionError: Execution of 'git branch 
> > devtool-override-foo devtool' failed with exit code 128:
> > fatal: A branch named 'devtool-override-foo' already exists.
> > 
> > Signed-off-by: Dan Dedrick 
> > ---
> >  scripts/lib/devtool/standard.py | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/scripts/lib/devtool/standard.py 
> > b/scripts/lib/devtool/standard.py
> > index d14b7a6543..a45ad36812 100644
> > --- a/scripts/lib/devtool/standard.py
> > +++ b/scripts/lib/devtool/standard.py
> > @@ -509,6 +509,11 @@ def _extract_source(srctree, keep_temp, devbranch, 
> > sync, config, basepath, works
> >  if not 'flag' in event:
> >  if event['op'].startswith(('_append[', '_prepend[')):
> > 
> > extra_overrides.append(event['op'].split('[')[1].split(']')[0])
> > +# We want to remove duplicate overrides. If a recipe had multiple
> > +# SRC_URI_override += values it would cause mulitple instances of
> > +# overrides. This doesn't play nicely with things like creating a
> > +# branch for every instance of DEVTOOL_EXTRA_OVERRIDES.
> > +extra_overrides = list(set(extra_overrides))
> >  if extra_overrides:
> >  logger.info('SRC_URI contains some conditional 
> > appends/prepends - will create branches to represent these')
> > 
> > --
> > 2.20.1
> 
> //Peter
> 
> 


-- 

Paul Eggleton
Intel Open Source Technology Centre


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


Re: [OE-core] [PATCH] devtool: deploy-target: allow use of alternate ssh

2019-02-21 Thread Paul Eggleton
Looks good to me.

Acked-by: Paul Eggleton 

On Friday, 22 February 2019 2:10:45 AM NZDT Olaf Mandel wrote:
> Allow the use of an alternate SSH executable for deploy-target and
> undeploy-target. The command can be specified with -e / --ssh-exec.
> 
> Signed-off-by: Olaf Mandel 
> ---
>  scripts/lib/devtool/deploy.py | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py
> index 886004b5d0..f345f31b7b 100644
> --- a/scripts/lib/devtool/deploy.py
> +++ b/scripts/lib/devtool/deploy.py
> @@ -211,6 +211,11 @@ def deploy(args, config, basepath, workspace):
>  if not args.show_status:
>  extraoptions += ' -q'
>  
> +scp_sshexec = ''
> +ssh_sshexec = 'ssh'
> +if args.ssh_exec:
> +scp_sshexec = "-S %s" % args.ssh_exec
> +ssh_sshexec = args.ssh_exec
>  scp_port = ''
>  ssh_port = ''
>  if args.port:
> @@ -238,7 +243,7 @@ def deploy(args, config, basepath, workspace):
>  for fpath, fsize in filelist:
>  f.write('%s %d\n' % (fpath, fsize))
>  # Copy them to the target
> -ret = subprocess.call("scp %s %s %s/* %s:%s" % (scp_port, 
> extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), shell=True)
> +ret = subprocess.call("scp %s %s %s %s/* %s:%s" % (scp_sshexec, 
> scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), 
> shell=True)
>  if ret != 0:
>  raise DevtoolError('Failed to copy script to %s - rerun with 
> -s to '
>  'get a complete error message' % args.target)
> @@ -246,7 +251,7 @@ def deploy(args, config, basepath, workspace):
>  shutil.rmtree(tmpdir)
>  
>  # Now run the script
> -ret = exec_fakeroot(rd, 'tar cf - . | ssh  %s %s %s \'sh %s %s %s 
> %s\'' % (ssh_port, extraoptions, args.target, tmpscript, args.recipename, 
> destdir, tmpfilelist), cwd=recipe_outdir, shell=True)
> +ret = exec_fakeroot(rd, 'tar cf - . | %s  %s %s %s \'sh %s %s %s 
> %s\'' % (ssh_sshexec, ssh_port, extraoptions, args.target, tmpscript, 
> args.recipename, destdir, tmpfilelist), cwd=recipe_outdir, shell=True)
>  if ret != 0:
>  raise DevtoolError('Deploy failed - rerun with -s to get a 
> complete '
>  'error message')
> @@ -276,6 +281,11 @@ def undeploy(args, config, basepath, workspace):
>  if not args.show_status:
>  extraoptions += ' -q'
>  
> +scp_sshexec = ''
> +ssh_sshexec = 'ssh'
> +if args.ssh_exec:
> +scp_sshexec = "-S %s" % args.ssh_exec
> +ssh_sshexec = args.ssh_exec
>  scp_port = ''
>  ssh_port = ''
>  if args.port:
> @@ -292,7 +302,7 @@ def undeploy(args, config, basepath, workspace):
>  with open(os.path.join(tmpdir, os.path.basename(tmpscript)), 'w') as 
> f:
>  f.write(shellscript)
>  # Copy it to the target
> -ret = subprocess.call("scp %s %s %s/* %s:%s" % (scp_port, 
> extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), shell=True)
> +ret = subprocess.call("scp %s %s %s %s/* %s:%s" % (scp_sshexec, 
> scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), 
> shell=True)
>  if ret != 0:
>  raise DevtoolError('Failed to copy script to %s - rerun with -s 
> to '
>  'get a complete error message' % args.target)
> @@ -300,7 +310,7 @@ def undeploy(args, config, basepath, workspace):
>  shutil.rmtree(tmpdir)
>  
>  # Now run the script
> -ret = subprocess.call('ssh %s %s %s \'sh %s %s\'' % (ssh_port, 
> extraoptions, args.target, tmpscript, args.recipename), shell=True)
> +ret = subprocess.call('%s %s %s %s \'sh %s %s\'' % (ssh_sshexec, 
> ssh_port, extraoptions, args.target, tmpscript, args.recipename), shell=True)
>  if ret != 0:
>  raise DevtoolError('Undeploy failed - rerun with -s to get a 
> complete '
> 'error message')
> @@ -324,6 +334,7 @@ def register_commands(subparsers, context):
>  parser_deploy.add_argument('-n', '--dry-run', help='List files to be 
> deployed only', action='store_true')
>  parser_deploy.add_argument('-p', '--no-preserve', help='Do not preserve 
> existing files', action='store_true')
>  parser_deploy.add_argument('--no-check-space', help='Do not check for 
> available space before deploying', action='store_true')
> +parser_deploy.add_argument('-e', '--ssh-exec', help='Executable to use 
> in place of ssh')
>  parser_deploy.add_argument('-P', '--port', help='Specify port to use for 
> connection to the target')
>  
>  strip_opts = parser_deploy.add_mutually_exclusive_group(required=False)
> @@ -346,5 +357,6 @@ def register_commands(subparsers, context):
>  parser_undeploy.add_argument('-s', 

[OE-core] [PATCH] perl: fix incorrect symbolic link for libperl.so

2019-02-21 Thread Yi Zhao
The perl-cross uses PERL_API_VERSION but not PERL_VERSION to define
libperl soname: 
libperl.so.$PERL_API_REVISION.$PERL_API_VERSION.$PERL_API_SUBVERSION.
For perl stable releases, the PERL_API_SUBVERSION is always 0. Specify
the so version for libperl to make sure the libperl.so can be linked to
the correct library.

Signed-off-by: Yi Zhao 
---
 meta/recipes-devtools/perl-sanity/perl_5.28.1.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb 
b/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
index 71653fe..1cc5480 100644
--- a/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
+++ b/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb
@@ -34,6 +34,8 @@ inherit upstream-version-is-even
 
 DEPENDS += "db gdbm zlib virtual/crypt"
 
+PERL_LIB_VER = "${@'.'.join(d.getVar('PV').split('.')[0:2])}.0"
+
 do_unpack_append() {
 bb.build.exec_func('do_copy_perlcross', d)
 }
@@ -104,7 +106,7 @@ do_install() {
 
 # Fix up shared library
 rm ${D}/${libdir}/perl5/${PV}/${TARGET_ARCH}-linux/CORE/libperl.so
-ln -sf ../../../../libperl.so.${PV} 
${D}/${libdir}/perl5/${PV}/${TARGET_ARCH}-linux/CORE/libperl.so
+ln -sf ../../../../libperl.so.${PERL_LIB_VER} 
${D}/${libdir}/perl5/${PV}/${TARGET_ARCH}-linux/CORE/libperl.so
 }
 
 do_install_append_class-target() {
-- 
2.7.4

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


[OE-core] [PATCH] debianutils: update to 4.8.6.1

2019-02-21 Thread Yi Zhao
Signed-off-by: Yi Zhao 
---
 .../debianutils/{debianutils_4.8.6.bb => debianutils_4.8.6.1.bb}  | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)
 rename meta/recipes-support/debianutils/{debianutils_4.8.6.bb => 
debianutils_4.8.6.1.bb} (86%)

diff --git a/meta/recipes-support/debianutils/debianutils_4.8.6.bb 
b/meta/recipes-support/debianutils/debianutils_4.8.6.1.bb
similarity index 86%
rename from meta/recipes-support/debianutils/debianutils_4.8.6.bb
rename to meta/recipes-support/debianutils/debianutils_4.8.6.1.bb
index c37e842..7cc78a6 100644
--- a/meta/recipes-support/debianutils/debianutils_4.8.6.bb
+++ b/meta/recipes-support/debianutils/debianutils_4.8.6.1.bb
@@ -3,13 +3,15 @@ SECTION = "base"
 LICENSE = "GPLv2 & SMAIL_GPL"
 LIC_FILES_CHKSUM = 
"file://debian/copyright;md5=f01a5203d50512fc4830b4332b696a9f"
 
-SRC_URI = 
"http://snapshot.debian.org/archive/debian/20180626T205238Z/pool/main/d/${BPN}/${BPN}_${PV}.tar.xz;
+SRC_URI = 
"http://snapshot.debian.org/archive/debian/20190217T160716Z/pool/main/d/${BPN}/${BPN}_${PV}.tar.xz;
 # the package is taken from snapshots.debian.org; that source is static and 
goes stale
 # so we check the latest upstream from a directory that does get updated
 UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/${BPN}/"
 
-SRC_URI[md5sum] = "f0f1fa39383815fb7950dcee52be4361"
-SRC_URI[sha256sum] = 
"db09047144dadf6a35d0f28977fbef83b0dd60ca32e6c8512cce2444a6423f73"
+SRC_URI[md5sum] = "80e2e670d8f6c0036770e971237f1f5c"
+SRC_URI[sha256sum] = 
"099f1e8a7278b26145a2ba2dda84c4118403bfab38c8d7070a6235a7ffcb55ed"
+
+S = "${WORKDIR}/${BPN}"
 
 inherit autotools update-alternatives
 
-- 
2.7.4

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


Re: [OE-core] [PATCH] u-boot: Upgrade to 2019.01 release

2019-02-21 Thread Tom Rini
On Fri, Feb 22, 2019 at 12:56:18AM +0100, Marek Vasut wrote:

> This upgrades the U-Boot to latest 2019.01 release.
> 
> Signed-off-by: Marek Vasut 
> Cc: Otavio Salvador 
> Cc: Richard Purdie 
> Cc: Ross Burton 

Reviewed-by: Tom Rini 

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


[OE-core] [PATCH] populate_sdk_ext.bbclass: Fix the derivate sdk build error from an published eSDK

2019-02-21 Thread Manjukumar Matha
When you install the eSDK in publish mode and then try to build a
derivative sdk using devtool build-sdk, the following error happens

| NOTE: Generating sstate task list...
| NOTE: Generating sstate-cache...
| NOTE: Generating sstate-cache...
| DEBUG: Python function copy_buildsystem finished
| NOTE: Executing install_tools ...
| DEBUG: Executing shell function install_tools
| install: cannot stat /core/meta/files/ext-sdk-prepare.py':
No such file or directory

This patch will fix the error by installing ext-sdk-prepare.py in
publish mode, so that derivative sdk can be generated.

Signed-off-by: Manjukumar Matha 
---
 meta/classes/populate_sdk_ext.bbclass | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 40b0375..800e117 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -589,11 +589,8 @@ sdk_ext_preinst() {
exit 1
fi
SDK_EXTENSIBLE="1"
-   if [ "$publish" = "1" ] ; then
-   EXTRA_TAR_OPTIONS="$EXTRA_TAR_OPTIONS 
--exclude=ext-sdk-prepare.py"
-   if [ "${SDK_EXT_TYPE}" = "minimal" ] ; then
-   EXTRA_TAR_OPTIONS="$EXTRA_TAR_OPTIONS 
--exclude=sstate-cache"
-   fi
+   if [ "$publish" = "1" ] && [ "${SDK_EXT_TYPE}" = "minimal" ] ; then
+   EXTRA_TAR_OPTIONS="$EXTRA_TAR_OPTIONS --exclude=sstate-cache"
fi
 }
 SDK_PRE_INSTALL_COMMAND_task-populate-sdk-ext = "${sdk_ext_preinst}"
@@ -635,6 +632,8 @@ sdk_ext_postinst() {
# sourcing a script. That is why this has to look so ugly.
LOGFILE="$target_sdk_dir/preparing_build_system.log"
sh -c ". buildtools/environment-setup* > $LOGFILE && cd 
$target_sdk_dir/`dirname ${oe_init_build_env_path}` && set $target_sdk_dir && . 
$target_sdk_dir/${oe_init_build_env_path} $target_sdk_dir >> $LOGFILE && python 
$target_sdk_dir/ext-sdk-prepare.py $LOGFILE '${SDK_INSTALL_TARGETS}'" || { echo 
"printf 'ERROR: this SDK was not fully installed and needs reinstalling\n'" >> 
$env_setup_script ; exit 1 ; }
+   fi
+   if [ -e $target_sdk_dir/ext-sdk-prepare.py ]; then
rm $target_sdk_dir/ext-sdk-prepare.py
fi
echo done
-- 
2.7.4

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


[OE-core] [PATCH] u-boot: Upgrade to 2019.01 release

2019-02-21 Thread Marek Vasut
This upgrades the U-Boot to latest 2019.01 release.

Signed-off-by: Marek Vasut 
Cc: Otavio Salvador 
Cc: Richard Purdie 
Cc: Ross Burton 
---
 meta/recipes-bsp/u-boot/u-boot-common.inc   | 2 +-
 .../{u-boot-fw-utils_2018.11.bb => u-boot-fw-utils_2019.01.bb}  | 0
 .../u-boot/{u-boot-tools_2018.11.bb => u-boot-tools_2019.01.bb} | 0
 .../recipes-bsp/u-boot/{u-boot_2018.11.bb => u-boot_2019.01.bb} | 0
 4 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2018.11.bb => 
u-boot-fw-utils_2019.01.bb} (100%)
 rename meta/recipes-bsp/u-boot/{u-boot-tools_2018.11.bb => 
u-boot-tools_2019.01.bb} (100%)
 rename meta/recipes-bsp/u-boot/{u-boot_2018.11.bb => u-boot_2019.01.bb} (100%)

diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc 
b/meta/recipes-bsp/u-boot/u-boot-common.inc
index 6f4a10b7a4..dcfb9cc63f 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
@@ -8,7 +8,7 @@ PE = "1"
 
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = "0157013f4a4945bbdb70bb4d98d680e0845fd784"
+SRCREV = "d3689267f92c5956e09cc7d1baa4700141662bff"
 
 SRC_URI = "git://git.denx.de/u-boot.git"
 
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2018.11.bb 
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2019.01.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2018.11.bb
rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2019.01.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb 
b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb
rename to meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
diff --git a/meta/recipes-bsp/u-boot/u-boot_2018.11.bb 
b/meta/recipes-bsp/u-boot/u-boot_2019.01.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot_2018.11.bb
rename to meta/recipes-bsp/u-boot/u-boot_2019.01.bb
-- 
2.19.2

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


Re: [OE-core] [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig

2019-02-21 Thread Richard Purdie
Multiconfig is meant to support this workflow. Unfortunately there are
open bugs and people haven't the time to work on it so its stalled.
That said, the key pieces are already there.

A picture is worth a thousand words. I thought a demo might interest
people and "prove" this can work.

To make it work you need four patches:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=b896b2238c100d486e7c43992b49001150749d04

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=e5ef6b008e85f42b5e4ffd72fae7036dd68b2ea5

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=5d2bd43d14315ef3212e0d09a16446bd74305a2f

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=abdb83576b699448b76293294809aaa04b8e853b

The first two are fixes from Alejandro which haven't merged as they're
not right. The third patch was me hitting the fixes and bitbake to make
the demo work. That proves they're not right and hints at where we have
some problems in bitbake too. We can get those issues sorted fairly
easily and I'm going to block 2.7 M3 on them.

The final patch is the interesting one.

It adds a layer, meta-multiconfig-example layer with a README about how
to configure it. Basically you create two multiconfig configurations,
"musl" and "tiny".

The demo is to run "bitbake core-image-full-cmdline".

The result is a core-image-full-cmdline image with a tiny qemux86 image
and a musl based qemux86-64 image installed into /var/lib/machines/

The way it does this is creative, having a recipe called image-packer
which creates virtclass variants of itself which depend on the
appropriate multiconfig. It pulls in the images and creates a package
containing them which the bbappend to core-image-full-cmdline can then
install. It'd be very easy to turn this into a list driven piece of
code rather than the two values currently listed.

Its late here, some of the above code is horrible. I have rushed this
but hopefully it shows this is possible! :)

I've love to turn this into an oe-selftest, that is my ultimate 
intention for this code.

As things stand today you can't query one multiconfig from another. As
this demo shows, that doesn't need to stop you making interesting
things though. We will do something with such querying eventually to
make things easier but until then, much is still possible.

Cheers,

Richard


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


Re: [OE-core] [PATCH 2/2] 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


[OE-core] [PATCH] gtk+3: Fix build failure with gold linker

2019-02-21 Thread Khem Raj
Explicitly link in libfribidi

Signed-off-by: Khem Raj 
---
 .../gtk+/gtk+3/link_fribidi.patch | 19 +++
 meta/recipes-gnome/gtk+/gtk+3_3.24.5.bb   |  1 +
 2 files changed, 20 insertions(+)
 create mode 100644 meta/recipes-gnome/gtk+/gtk+3/link_fribidi.patch

diff --git a/meta/recipes-gnome/gtk+/gtk+3/link_fribidi.patch 
b/meta/recipes-gnome/gtk+/gtk+3/link_fribidi.patch
new file mode 100644
index 00..e4bbd799f1
--- /dev/null
+++ b/meta/recipes-gnome/gtk+/gtk+3/link_fribidi.patch
@@ -0,0 +1,19 @@
+Link with libfribidi, this is to avoid under linking where these functions are
+used but the library is not linked in, and they are marked undefined by BFD 
linker
+but gold linker refuses to link
+
+| ./.libs/libgdk-3.so: error: undefined reference to 'fribidi_get_bidi_type'
+
+Signed-off-by: Khem Raj 
+Upstream-Status: Pending
+
+--- a/gdk/Makefile.am
 b/gdk/Makefile.am
+@@ -55,6 +55,7 @@ LDADD =  \
+   -version-info $(LT_VERSION_INFO)\
+   -export-dynamic \
+   -rpath $(libdir)\
++  -lfribidi   \
+   $(no_undefined)
+ 
+ #
diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.24.5.bb 
b/meta/recipes-gnome/gtk+/gtk+3_3.24.5.bb
index 799cbd4707..92c9a3ebfb 100644
--- a/meta/recipes-gnome/gtk+/gtk+3_3.24.5.bb
+++ b/meta/recipes-gnome/gtk+/gtk+3_3.24.5.bb
@@ -6,6 +6,7 @@ SRC_URI = 
"http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar
file://0001-Hardcoded-libtool.patch \
file://0002-Do-not-try-to-initialize-GL-without-libGL.patch \
file://0003-Add-disable-opengl-configure-option.patch \
+   file://link_fribidi.patch \
   "
 SRC_URI[md5sum] = "32862355c08f6af3e7848c695cd4081b"
 SRC_URI[sha256sum] = 
"0be5fb0d302bc3de26ab58c32990d895831e2b7c7418d0ffea1206d6a3ddb02f"
-- 
2.20.1

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


Re: [OE-core] [PATCH v6 13/13] util-linux: final cleanup

2019-02-21 Thread Burton, Ross
Looks like the manpage cleanup didn't quite work:

WARNING: util-linux-2.32.1-r0 do_configure: QA Issue: util-linux:
invalid PACKAGECONFIG: manpages [invalid-packageconfig]

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


Re: [OE-core] [PATCH 2/2] kernel-fitimage.bbclass: Introduce a way to provide external dtb

2019-02-21 Thread Manjukumar Harthikote Matha
Hi Richard,

> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Wednesday, February 20, 2019 3:16 PM
> To: Manjukumar Harthikote Matha ; Philip Balister
> 
> Cc: openembedded-core 
> Subject: Re: [OE-core] [PATCH 2/2] kernel-fitimage.bbclass: Introduce a way to
> provide external dtb
> 
> On Tue, 2019-02-19 at 19:34 +, Manjukumar Harthikote Matha wrote:
> > Hi Philip,
> >
> > > -Original Message-
> > > From: Philip Balister [mailto:phi...@balister.org]
> > > Sent: Sunday, February 17, 2019 3:47 PM
> > > To: Manjukumar Harthikote Matha 
> > > Cc: openembedded-core 
> > > Subject: Re: [OE-core][PATCH 2/2] kernel-fitimage.bbclass:
> > > Introduce a way to
> > > provide external dtb
> > >
> > > With these patches, I made a fitImage that booted on the mini-zed.
> > > It would be nice
> > > to include a note on how to enable this. I took at few stabs at it
> > > and ended up with
> >
> > Thanks for testing it out on mini-zed
> >
> > > PREFERRED_PROVIDER_virtual/dtb = "devicetree"
> > >
> >
> > Yes, I should have added this in the commit message. I will update it
> > and re-send V2
> 
> What may also help a lot here would be some tests. This is currently a 
> blackhole in
> the tests :(
> 
Are there examples of having tests only for bbclass in OE-Core? 

We need a recipe or create-one to inherit this class and probably add that as a 
testcase. 
I am not sure how to proceed, any example would help to implement the same

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


Re: [OE-core] [PATCH v2 0/3] alsa recipe updates

2019-02-21 Thread Alexander Kanavin
On Thu, 21 Feb 2019 at 21:13, Tanu Kaskinen  wrote:
> Changes in v2:
>  - More reliable SRC_URIs.
>
>
> Tanu Kaskinen (3):
>   alsa-lib: 1.1.6 -> 1.1.8
>   alsa-plugins: 1.1.6 -> 1.1.8
>   alsa-utils: 1.1.6 -> 1.1.8
>
>  .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}  |  6 +-
>  ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 86 +--
>  ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} |  0
>  ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 14 ++-
>  .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb |  2 +-

I guess alsa-tools should also get an updated SRC_URI, even without a
version upgrade for now?

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


[OE-core] [PATCH v2 2/3] alsa-plugins: 1.1.6 -> 1.1.8

2019-02-21 Thread Tanu Kaskinen
Changelogs:
http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7
http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8

The --enable-avcodec configure option was renamed to --enable-libav, and
I renamed the respective packageconfig item too.

There's a new pcm plugin: aaf (AVTP Audio Format). I added a
packageconfig item for it, but I didn't test it, because libavtp doesn't
seem to be currently packaged for OpenEmbedded.

There are now configuration files for most of the plugins. I removed the
symlink creation for 50-pulseaudio.conf, because upstream now creates
the symlinks for us. 99-pulseaudio-default.conf is an exception, because
upstream ships it only as an example, and upstream doesn't install a
symlink for it (upstream actually installs it directly under /etc, but I
moved it back to /usr/share), so for that file we still have to create
the symlink ourselves.

The lavcrate plugin was converted to use libavresample (and renamed to
lavrate). Libavresample is provided by ffmpeg, but ffmpeg was by default
built with libavresample disabled. This patch now enables libavresample
by default in the ffmpeg recipe in order to not cause a regression in
alsa-plugins.

SRC_URI was changed to a more reliable source (at least currently the
ftp server is flaky).

Signed-off-by: Tanu Kaskinen 
---
 ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 89 +++
 .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb |  2 +-
 2 files changed, 75 insertions(+), 16 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => 
alsa-plugins_1.1.8.bb} (53%)

diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb
similarity index 53%
rename from meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
rename to meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb
index ee06191ea9..2d9cc06f58 100644
--- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
+++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb
@@ -20,9 +20,9 @@ LIC_FILES_CHKSUM = "\
 
file://rate/rate_samplerate.c;endline=35;md5=fd77bce85f4a338c0e8ab18430b69fae \
 "
 
-SRC_URI = "ftp://ftp.alsa-project.org/pub/plugins/${BP}.tar.bz2;
-SRC_URI[md5sum] = "8387279e99feeb2ecffaac5f293223d7"
-SRC_URI[sha256sum] = 
"6f1d31ebe3b1fa1cc8dade60b7bed1cb2583ac998167002d350dc0a5e3e40c13"
+SRC_URI = "https://www.alsa-project.org/files/pub/plugins/${BP}.tar.bz2;
+SRC_URI[md5sum] = "d0f87211d1560f2c07c8eae4297bc4f6"
+SRC_URI[sha256sum] = 
"7f77df171685ccec918268477623a39db4d9f32d5dc5e76874ef2467a2405994"
 
 DEPENDS += "alsa-lib"
 
@@ -33,8 +33,9 @@ PACKAGECONFIG ??= "\
 speexdsp \
 ${@bb.utils.filter('DISTRO_FEATURES', 'pulseaudio', d)} \
 "
-PACKAGECONFIG[avcodec] = "--enable-avcodec,--disable-avcodec,libav"
+PACKAGECONFIG[aaf] = "--enable-aaf,--disable-aaf,avtp"
 PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack"
+PACKAGECONFIG[libav] = "--enable-libav,--disable-libav,libav"
 PACKAGECONFIG[maemo-plugin] = "--enable-maemo-plugin,--disable-maemo-plugin"
 PACKAGECONFIG[maemo-resource-manager] = 
"--enable-maemo-resource-manager,--disable-maemo-resource-manager,dbus"
 PACKAGECONFIG[pulseaudio] = 
"--enable-pulseaudio,--disable-pulseaudio,pulseaudio"
@@ -54,15 +55,11 @@ do_install_append() {
rm ${D}${libdir}/alsa-lib/*.la
 
if [ "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'yes', 'no', 
d)}" = "yes" ]; then
-   # We use the example as is, so just drop the .example suffix.
-   mv 
${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf.example 
${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf
-
-   # The conf.d files are installed in datadir, but alsa-lib
-   # searches for conf.d files only in sysconfdir. Distributions
-   # are expected to create symlinks in sysconfdir, so that's what
-   # we do here.
-   mkdir -p ${D}${sysconfdir}/alsa/conf.d
-   ln -s ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf 
${D}${sysconfdir}/alsa/conf.d/50-pulseaudio.conf
+   # We use the example as is. Upstream installs the file under
+   # /etc, but we move it under /usr/share and add a symlink under
+   # /etc to be consistent with other installed configuration
+   # files.
+   mv 
${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf.example 
${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf
ln -s ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf 
${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf
fi
 }
@@ -73,6 +70,68 @@ python populate_packages_prepend() {
 d.setVar("RDEPENDS_alsa-plugins", packages)
 }
 
+# Many plugins have a configuration file (plus a symlink in /etc) associated
+# with them. We put the plugin and it's configuration usually in the same
+# package, but that's problematic when the configuration file is related to
+# 

[OE-core] [PATCH v2 0/3] alsa recipe updates

2019-02-21 Thread Tanu Kaskinen
The following changes since commit ff2c029b568f70aa9960dde04ddd207829812ea0:

  resulttool: Improvements to allow integration to the autobuilder (2019-02-21 
12:31:50 +)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib tanuk/updates
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates


The alsa-tools update is missing, because the recipe upgrade deadline is
near and the changes in alsa-tools look like a potential rabbit hole.
I'll send the alsa-tools update separately when it's ready. The main
change in alsa-tools is that the hwmixvolume program got ported from
PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone
actually is using that program, it's not even built by default.

Changes in v2:
 - More reliable SRC_URIs.


Tanu Kaskinen (3):
  alsa-lib: 1.1.6 -> 1.1.8
  alsa-plugins: 1.1.6 -> 1.1.8
  alsa-utils: 1.1.6 -> 1.1.8

 .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}  |  6 +-
 ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 86 +--
 ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} |  0
 ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 14 ++-
 .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb |  2 +-
 5 files changed, 88 insertions(+), 20 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} 
(83%)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => 
alsa-plugins_1.1.8.bb} (50%)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => 
alsa-utils-scripts_1.1.8.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => 
alsa-utils_1.1.8.bb} (90%)

-- 
2.20.1

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


[OE-core] [PATCH v2 1/3] alsa-lib: 1.1.6 -> 1.1.8

2019-02-21 Thread Tanu Kaskinen
Changelogs:
http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7
http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8

One significant change was that the search path of add-on configuration
files was changed from /usr/share/alsa/alsa.conf.d to /etc/alsa/conf.d.
Packages that install such files should still use the /usr/share
location, though. Symlinks need to be created from /etc to /usr/share.
The rationale for using /etc is that the system administrator can better
control the configuration that way, and the rationale for installing
files under /usr/share is that configuration snippets that are installed
by packages are not meant to be directly edited by the administrator.

alsa-plugins had to be modified to add symlinks for the configuration
snippets that it installs. I also added FILES_${PN} = "", because the
alsa-plugins package is supposed to be empty, but also because for some
reason that I don't understand the symlinks would otherwise go to the
alsa-plugins package rather than alsa-plugins-pulseaudio-conf.

SRC_URI was changed to a more reliable source (at least currently the
ftp server is flaky).

Signed-off-by: Tanu Kaskinen 
---
 .../alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}   |  6 +++---
 meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb  | 13 -
 2 files changed, 15 insertions(+), 4 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} 
(83%)

diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb
similarity index 83%
rename from meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb
rename to meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb
index 25e7a3c6b7..76cc9627e5 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb
@@ -7,9 +7,9 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=a916467b91076e631dd8edb7424769c7 \
 
file://src/socket.c;md5=dd1bc7f44872690224d89c1a9806e495;beginline=1;endline=26 
\
 "
 
-SRC_URI = "ftp://ftp.alsa-project.org/pub/lib/${BP}.tar.bz2;
-SRC_URI[md5sum] = "2f981a8f7897c59ec2ddc44916d33788"
-SRC_URI[sha256sum] = 
"5f2cd274b272cae0d0d111e8a9e363f08783329157e8dd68b3de0c096de6d724"
+SRC_URI = "https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2;
+SRC_URI[md5sum] = "0eec0d657a07927795809c8f87fb76ca"
+SRC_URI[sha256sum] = 
"3cdc3a93a6427a26d8efab4ada2152e64dd89140d981f6ffa003e85be707aedf"
 
 inherit autotools pkgconfig
 
diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
index 7ede8be98a..ee06191ea9 100644
--- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
+++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
@@ -47,14 +47,23 @@ PACKAGES_DYNAMIC = "^libasound-module-.*"
 
 # The alsa-plugins package doesn't itself contain anything, it just depends on
 # all built plugins.
+FILES_${PN} = ""
 ALLOW_EMPTY_${PN} = "1"
 
 do_install_append() {
rm ${D}${libdir}/alsa-lib/*.la
 
-   # We use the example as is, so just drop the .example suffix.
if [ "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'yes', 'no', 
d)}" = "yes" ]; then
+   # We use the example as is, so just drop the .example suffix.
mv 
${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf.example 
${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf
+
+   # The conf.d files are installed in datadir, but alsa-lib
+   # searches for conf.d files only in sysconfdir. Distributions
+   # are expected to create symlinks in sysconfdir, so that's what
+   # we do here.
+   mkdir -p ${D}${sysconfdir}/alsa/conf.d
+   ln -s ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf 
${D}${sysconfdir}/alsa/conf.d/50-pulseaudio.conf
+   ln -s ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf 
${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf
fi
 }
 
@@ -94,6 +103,8 @@ INSANE_SKIP_${MLPREFIX}libasound-module-rate-speexrate = 
"dev-so"
 FILES_${PN}-pulseaudio-conf += "\
 ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf \
 ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf \
+${sysconfdir}/alsa/conf.d/50-pulseaudio.conf \
+${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf \
 "
 
 RDEPENDS_${PN}-pulseaudio-conf += "\
-- 
2.20.1

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


[OE-core] [PATCH v2 3/3] alsa-utils: 1.1.6 -> 1.1.8

2019-02-21 Thread Tanu Kaskinen
Changelogs:
http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7
http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8

There's a new program, axfer, which is a reimplementation of aplay (and
arecord). The purpose of the rewrite is to have code that is easier to
maintain. For now both implementations exist, and I decided to put both
in the aplay package.

The new 89-alsa-ucm.rules udev file initializes the mixer settings for
certain hardware. It's needed for making the hardware usable at boot, in
case there's no higher level software (such as PulseAudio) managing the
mixer settings. Shipping hardware specific configuration in alsa-utils
seems wrong, but I don't know what else to do. I added it to the alsaucm
package, because it's kind of tied to the alsaucm utility (the udev
rules execute the alsaucm program, and the build system installs the
rules file only when alsaucm is enabled). Ideally the UCM configuration
in alsa-lib would define the default UCM verb for each hardware, then
the udev rules file could just enable the default verb, and there would
be no hardware specific configuration in alsa-utils. But that requires
upstream development effort.

SRC_URI was changed to a more reliable source (at least currently the
ftp server is flaky).

Signed-off-by: Tanu Kaskinen 
---
 ...cripts_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} |  0
 .../{alsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb}   | 14 ++
 2 files changed, 6 insertions(+), 8 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => 
alsa-utils-scripts_1.1.8.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => 
alsa-utils_1.1.8.bb} (90%)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.8.bb
similarity index 100%
rename from meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.6.bb
rename to meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.8.bb
diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb
similarity index 90%
rename from meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb
rename to meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb
index b8ba0cb22a..1e21022e95 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb
@@ -19,11 +19,9 @@ PACKAGECONFIG[bat] = "--enable-bat,--disable-bat,fftwf"
 PACKAGECONFIG[udev] = "--with-udev-rules-dir=`pkg-config --variable=udevdir 
udev`/rules.d,--with-udev-rules-dir=/unwanted/rules.d,udev"
 PACKAGECONFIG[manpages] = "--enable-xmlto, --disable-xmlto, xmlto-native 
docbook-xml-dtd4-native docbook-xsl-stylesheets-native"
 
-SRC_URI = "ftp://ftp.alsa-project.org/pub/utils/alsa-utils-${PV}.tar.bz2 \
-  "
-
-SRC_URI[md5sum] = "50ae75567459646b843bed78d916b002"
-SRC_URI[sha256sum] = 
"155caecc40b2220f686f34ba3655a53e3bdbc0586adb1056733949feaaf7d36e"
+SRC_URI = "https://www.alsa-project.org/files/pub/utils/${BP}.tar.bz2;
+SRC_URI[md5sum] = "54d6f9b483144823d0fc0c26e8cea028"
+SRC_URI[sha256sum] = 
"fd9bf528922b3829a91913b89a1858c58a0b24271a7b5f529923aa9ea12fa4cf"
 
 # On build machines with python-docutils (not python3-docutils !!) installed
 # rst2man (not rst2man.py) is detected and compile fails with
@@ -59,7 +57,7 @@ RDEPENDS_${PN} += "${ALSA_UTILS_PKGS}"
 FILES_${PN} = ""
 FILES_alsa-utils-alsabat = "${bindir}/alsabat"
 FILES_alsa-utils-alsatplg= "${bindir}/alsatplg"
-FILES_alsa-utils-aplay   = "${bindir}/aplay ${bindir}/arecord"
+FILES_alsa-utils-aplay   = "${bindir}/aplay ${bindir}/arecord 
${bindir}/axfer"
 FILES_alsa-utils-amixer  = "${bindir}/amixer"
 FILES_alsa-utils-alsamixer   = "${bindir}/alsamixer"
 FILES_alsa-utils-speakertest = "${bindir}/speaker-test ${datadir}/sounds/alsa/ 
${datadir}/alsa/speaker-test/"
@@ -67,10 +65,10 @@ FILES_alsa-utils-midi= "${bindir}/aplaymidi 
${bindir}/arecordmidi ${bind
 FILES_alsa-utils-aconnect= "${bindir}/aconnect"
 FILES_alsa-utils-aseqnet = "${bindir}/aseqnet"
 FILES_alsa-utils-iecset  = "${bindir}/iecset"
-FILES_alsa-utils-alsactl = "${sbindir}/alsactl */udev/rules.d 
*/*/udev/rules.d ${systemd_unitdir} ${localstatedir}/lib/alsa 
${datadir}/alsa/init/"
+FILES_alsa-utils-alsactl = "${sbindir}/alsactl 
*/udev/rules.d/90-alsa-restore.rules */*/udev/rules.d/90-alsa-restore.rules 
${systemd_unitdir} ${localstatedir}/lib/alsa ${datadir}/alsa/init/"
 FILES_alsa-utils-aseqdump= "${bindir}/aseqdump"
 FILES_alsa-utils-alsaloop= "${bindir}/alsaloop"
-FILES_alsa-utils-alsaucm = "${bindir}/alsaucm"
+FILES_alsa-utils-alsaucm = "${bindir}/alsaucm 
*/udev/rules.d/89-alsa-ucm.rules */*/udev/rules.d/89-alsa-ucm.rules"
 
 SUMMARY_alsa-utils-alsabat  = "Command-line sound tester for ALSA sound 
card driver"
 SUMMARY_alsa-utils-alsatplg = "Converts topology text files into binary 
format for kernel"
-- 
2.20.1

-- 

Re: [OE-core] [PATCH 1/3] alsa-lib: 1.1.6 -> 1.1.8

2019-02-21 Thread Tanu Kaskinen
On Thu, 2019-02-21 at 21:38 +0200, Tanu Kaskinen wrote:
> On Thu, 2019-02-21 at 10:43 -0800, Khem Raj wrote:
> > WARNING: alsa-lib-native-1.1.8-r0 do_fetch: Failed to fetch URL
> > ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.8.tar.bz2, attempting
> > MIRRORS if available
> > 
> > we might need a better source
> 
> I don't know what's going on with the alsa infrastructure, it has had
> various problems since last weekend. Sometimes the ftp server works,
> sometimes it doesn't. The ftp server is certainly the official source,
> since that's what was advertised in the release announcement.
> 
> In my testing I used Debian's archives, but I suppose it's not cool to
> cause server load on Debian.
> 
> Is github a good source? If I recall correctly, github has had some
> kind of problems in the past regarding checksum stability, has that
> improved? I see there are many recipes using github, so I suppose it's
> ok.
> 
> This link seems to work:
> https://github.com/alsa-project/alsa-lib/archive/v1.1.8.tar.gz
> ...but most github SRC_URIs have structure where the the tarball is
> under archive/download// and I wasn't able to figure out a
> working url for alsa-lib that would have that structure.

Never mind, I didn't notice that Alex already provided a good source.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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


Re: [OE-core] [PATCH 1/3] alsa-lib: 1.1.6 -> 1.1.8

2019-02-21 Thread Tanu Kaskinen
On Thu, 2019-02-21 at 10:43 -0800, Khem Raj wrote:
> WARNING: alsa-lib-native-1.1.8-r0 do_fetch: Failed to fetch URL
> ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.8.tar.bz2, attempting
> MIRRORS if available
> 
> we might need a better source

I don't know what's going on with the alsa infrastructure, it has had
various problems since last weekend. Sometimes the ftp server works,
sometimes it doesn't. The ftp server is certainly the official source,
since that's what was advertised in the release announcement.

In my testing I used Debian's archives, but I suppose it's not cool to
cause server load on Debian.

Is github a good source? If I recall correctly, github has had some
kind of problems in the past regarding checksum stability, has that
improved? I see there are many recipes using github, so I suppose it's
ok.

This link seems to work:
https://github.com/alsa-project/alsa-lib/archive/v1.1.8.tar.gz
...but most github SRC_URIs have structure where the the tarball is
under archive/download// and I wasn't able to figure out a
working url for alsa-lib that would have that structure.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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


Re: [OE-core] [PATCH 1/3] alsa-lib: 1.1.6 -> 1.1.8

2019-02-21 Thread Khem Raj
WARNING: alsa-lib-native-1.1.8-r0 do_fetch: Failed to fetch URL
ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.8.tar.bz2, attempting
MIRRORS if available

we might need a better source

On Thu, Feb 21, 2019 at 5:34 AM Tanu Kaskinen  wrote:
>
> Changelogs:
> http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7
> http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8
>
> One significant change was that the search path of add-on configuration
> files was changed from /usr/share/alsa/alsa.conf.d to /etc/alsa/conf.d.
> Packages that install such files should still use the /usr/share
> location, though. Symlinks need to be created from /etc to /usr/share.
> The rationale for using /etc is that the system administrator can better
> control the configuration that way, and the rationale for installing
> files under /usr/share is that configuration snippets that are installed
> by packages are not meant to be directly edited by the administrator.
>
> alsa-plugins had to be modified to add symlinks for the configuration
> snippets that it installs. I also added FILES_${PN} = "", because the
> alsa-plugins package is supposed to be empty, but also because for some
> reason that I don't understand the symlinks would otherwise go to the
> alsa-plugins package rather than alsa-plugins-pulseaudio-conf.
>
> Signed-off-by: Tanu Kaskinen 
> ---
>  .../alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}   |  4 ++--
>  meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb  | 13 -
>  2 files changed, 14 insertions(+), 3 deletions(-)
>  rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} 
> (88%)
>
> diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb 
> b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb
> similarity index 88%
> rename from meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb
> rename to meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb
> index 25e7a3c6b7..bb22acdd33 100644
> --- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb
> +++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb
> @@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=a916467b91076e631dd8edb7424769c7 \
>  "
>
>  SRC_URI = "ftp://ftp.alsa-project.org/pub/lib/${BP}.tar.bz2;
> -SRC_URI[md5sum] = "2f981a8f7897c59ec2ddc44916d33788"
> -SRC_URI[sha256sum] = 
> "5f2cd274b272cae0d0d111e8a9e363f08783329157e8dd68b3de0c096de6d724"
> +SRC_URI[md5sum] = "0eec0d657a07927795809c8f87fb76ca"
> +SRC_URI[sha256sum] = 
> "3cdc3a93a6427a26d8efab4ada2152e64dd89140d981f6ffa003e85be707aedf"
>
>  inherit autotools pkgconfig
>
> diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb 
> b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
> index 7ede8be98a..ee06191ea9 100644
> --- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
> +++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
> @@ -47,14 +47,23 @@ PACKAGES_DYNAMIC = "^libasound-module-.*"
>
>  # The alsa-plugins package doesn't itself contain anything, it just depends 
> on
>  # all built plugins.
> +FILES_${PN} = ""
>  ALLOW_EMPTY_${PN} = "1"
>
>  do_install_append() {
> rm ${D}${libdir}/alsa-lib/*.la
>
> -   # We use the example as is, so just drop the .example suffix.
> if [ "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'yes', 
> 'no', d)}" = "yes" ]; then
> +   # We use the example as is, so just drop the .example suffix.
> mv 
> ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf.example 
> ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf
> +
> +   # The conf.d files are installed in datadir, but alsa-lib
> +   # searches for conf.d files only in sysconfdir. Distributions
> +   # are expected to create symlinks in sysconfdir, so that's 
> what
> +   # we do here.
> +   mkdir -p ${D}${sysconfdir}/alsa/conf.d
> +   ln -s ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf 
> ${D}${sysconfdir}/alsa/conf.d/50-pulseaudio.conf
> +   ln -s ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf 
> ${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf
> fi
>  }
>
> @@ -94,6 +103,8 @@ INSANE_SKIP_${MLPREFIX}libasound-module-rate-speexrate = 
> "dev-so"
>  FILES_${PN}-pulseaudio-conf += "\
>  ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf \
>  ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf \
> +${sysconfdir}/alsa/conf.d/50-pulseaudio.conf \
> +${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf \
>  "
>
>  RDEPENDS_${PN}-pulseaudio-conf += "\
> --
> 2.20.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


Re: [OE-core] [PATCH 0/3] alsa recipe updates

2019-02-21 Thread Alexander Kanavin
ftp://ftp.alsa.org seems inaccessible or unstable:

https://autobuilder.yoctoproject.org/typhoon/#/builders/70/builds/317/steps/7/logs/step1b
(also can't open it on my local machine)
and generally we prefer http:// sources over ftp, if available.

Alsa does have one: https://www.alsa-project.org/files/

so can you please resend with SRC_URIs changed to use it? (also for
alsa-tools and everywhere where the ftp is currently used)

Alex

On Thu, 21 Feb 2019 at 19:09, Alexander Kanavin  wrote:
>
> Bah, and I often point out to people that they should read *my* cover letters 
> :)
> Thanks!
>
> Alex
>
> On Thu, 21 Feb 2019 at 17:41, Tanu Kaskinen  wrote:
> >
> > Richard already sent the update for sbc, so I left it out. As for alsa-
> > tools, if you read the cover letter in more detail, you'll find the
> > answer there :) (Spoiler: I'll send it, but it's not ready yet.)
> >
> > -- Tanu
> >
> > On Thu, 2019-02-21 at 15:57 +0100, Alexander Kanavin wrote:
> > > (Also sbc needs an update, I think)
> > >
> > > Alex
> > >
> > >
> > > On Thu, 21 Feb 2019 at 15:56, Alexander Kanavin  
> > > wrote:
> > > > Thanks! Will you be also sending an update to alsa-tools?
> > > >
> > > > Alex
> > > >
> > > > On Thu, 21 Feb 2019 at 14:34, Tanu Kaskinen  wrote:
> > > > > The following changes since commit 
> > > > > f15ceac287c094abdeda64b03628455d92e0ce74:
> > > > >
> > > > >   libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +)
> > > > >
> > > > > are available in the Git repository at:
> > > > >
> > > > >   git://git.openembedded.org/openembedded-core-contrib tanuk/updates
> > > > >   
> > > > > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates
> > > > >
> > > > >
> > > > > The alsa-tools update is missing, because the recipe upgrade deadline 
> > > > > is
> > > > > near and the changes in alsa-tools look like a potential rabbit hole.
> > > > > I'll send the alsa-tools update separately when it's ready. The main
> > > > > change in alsa-tools is that the hwmixvolume program got ported from
> > > > > PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone
> > > > > actually is using that program, it's not even built by default.
> > > > >
> > > > >
> > > > > Tanu Kaskinen (3):
> > > > >   alsa-lib: 1.1.6 -> 1.1.8
> > > > >   alsa-plugins: 1.1.6 -> 1.1.8
> > > > >   alsa-utils: 1.1.6 -> 1.1.8
> > > > >
> > > > >  .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}  |  4 +-
> > > > >  ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 
> > > > > +--
> > > > >  ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} |  0
> > > > >  ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +--
> > > > >  .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb |  2 +-
> > > > >  5 files changed, 85 insertions(+), 15 deletions(-)
> > > > >  rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => 
> > > > > alsa-lib_1.1.8.bb} (88%)
> > > > >  rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => 
> > > > > alsa-plugins_1.1.8.bb} (51%)
> > > > >  rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => 
> > > > > alsa-utils-scripts_1.1.8.bb} (100%)
> > > > >  rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => 
> > > > > alsa-utils_1.1.8.bb} (92%)
> > > > >
> > > > > --
> > > > > 2.20.1
> > > > >
> > > > > --
> > > > > ___
> > > > > Openembedded-core mailing list
> > > > > Openembedded-core@lists.openembedded.org
> > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > --
> > Tanu
> >
> > https://www.patreon.com/tanuk
> > https://liberapay.com/tanuk
> >
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig

2019-02-21 Thread Mark Hatle
On 2/21/19 9:44 AM, Burton, Ross wrote:
> So I'd like to use multiconfig for a fairly typical host/container use
> case.  I've a class which can be used to build packages from images in
> a fairly simple manner, essential just taking files from DEPLOY_DIR
> when creating a package:
> 
> core-image-minimal-package.bb:
> do_install[depends] += "core-image-minimal:do_image_complete
> virtual/kernel:do_deploy"
> do_install () {
> install -d ${D}/var/lib/machines/
> install ${DEPLOY_DIR_IMAGE}/core-image-minimal-${MACHINE}.ext4
> ${D}/var/lib/machines/core-image-minimal.ext4
> install ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}
> ${D}/var/lib/machines/${IMAGE_NAME}.${KERNEL_IMAGETYPE}
> }
> 
> This part works fine, but the problem is straddling multiconfig boundaries...
> 
> I can't just add "core-image-minimal-package" to IMAGE_INSTALL because
> it will build that for the current configuration.  I can't just add
> "multiconfig:uos:core-image-minimal-package" because that will look
> for a recipe with that name.  I've a rather ugly hack to call opkg
> directly in a post-rootfs hook which sort of works.  Linking in bits
> of the other configuration's deploy directory in a pre-rootfs hook and
> extending IMAGE_INSTALL there almost works, apart from the rootfs code
> then looks at the task dependencies to generate a pruned deploy dir,
> which is missing the pieces I linked in.
> 
> I suspect this is now breaking new ground: the multiconfiguration
> support lets you do builds but so far the artefact sharing hasn't
> really been explored.  Has anyone dug further into this?

I don't think anyone has.  But as we continue moving toward containers/micro
services environments -- this exactly type of thing is going to be more and more
needed.

One 'build', with various configurations that end up constructing a single
device image with a container runtime (booting OS), and a number of container
micro services should be able to be created with a single call to bitbake and (a
potentially complex) config.

I think the first question is, can one multiconfig require a dependency out of
another yet?  I thought this was still unimplemented.  Once this can be done,
then it should be much easier to have a 'configuration' whose job it is to
assemble the various components while waiting for everything to finish being 
built.

--Mark

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

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


[OE-core] [PATCH] ltp: Bump to 20190115

2019-02-21 Thread Daniel Díaz
This patch has been refreshed:
* 0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch

These patches have been dropped as they have been merged:
* 0001-netns_helper.sh-use-ping-6-when-ping6-is-not-avaliab.patch
* 0001-setrlimit05-Use-another-method-to-get-bad-address.patch
* 0001-sigwaitinfo01-recent-glibc-calls-syscall-directly.patch
* 0001-statx-fix-compile-errors.patch
* 0001-syscalls-fcntl-make-OFD-command-use-fcntl64-syscall-.patch
* 0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch

This patch has been added:
* define-sigrtmin-and-sigrtmax-for-musl.patch

Added these rdependencies:
* file: for ld01, file01 and logrotate
* quota: for quota_remount_test01

Signed-off-by: Daniel Díaz 
---
 ...getcpu-to-avoid-conflict-with-glibc-.patch |  57 --
 ...use-ping-6-when-ping6-is-not-avaliab.patch |  45 -
 ...suite-mmap24-2-Relax-condition-a-bit.patch |   6 +-
 ...se-another-method-to-get-bad-address.patch |  61 --
 ...-recent-glibc-calls-syscall-directly.patch |  75 ---
 .../ltp/0001-statx-fix-compile-errors.patch   |  35 
 ...ake-OFD-command-use-fcntl64-syscall-.patch | 184 -
 ...option-to-select-libc-implementation.patch |   3 +-
 ...E-undeclared-when-building-with-musl.patch |   2 +-
 ...BC_PREREQ-is-defined-before-using-it.patch | 190 +++---
 .../ltp/0035-fix-test_proc_kill-hang.patch|   2 +-
 ...1-Fix-for-test-in-deterministic-mode.patch |   2 +-
 ...efine-sigrtmin-and-sigrtmax-for-musl.patch | 114 +++
 .../ltp/{ltp_20180926.bb => ltp_20190115.bb}  |  11 +-
 14 files changed, 154 insertions(+), 633 deletions(-)
 delete mode 100644 
meta/recipes-extended/ltp/ltp/0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch
 delete mode 100644 
meta/recipes-extended/ltp/ltp/0001-netns_helper.sh-use-ping-6-when-ping6-is-not-avaliab.patch
 delete mode 100644 
meta/recipes-extended/ltp/ltp/0001-setrlimit05-Use-another-method-to-get-bad-address.patch
 delete mode 100644 
meta/recipes-extended/ltp/ltp/0001-sigwaitinfo01-recent-glibc-calls-syscall-directly.patch
 delete mode 100644 
meta/recipes-extended/ltp/ltp/0001-statx-fix-compile-errors.patch
 delete mode 100644 
meta/recipes-extended/ltp/ltp/0001-syscalls-fcntl-make-OFD-command-use-fcntl64-syscall-.patch
 create mode 100644 
meta/recipes-extended/ltp/ltp/define-sigrtmin-and-sigrtmax-for-musl.patch
 rename meta/recipes-extended/ltp/{ltp_20180926.bb => ltp_20190115.bb} (91%)

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch
 
b/meta/recipes-extended/ltp/ltp/0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch
deleted file mode 100644
index d0c847774d..00
--- 
a/meta/recipes-extended/ltp/ltp/0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch
+++ /dev/null
@@ -1,57 +0,0 @@
-From c9edb0eaaca83c18ac7b5ea3330faad8d47d3fd1 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Fri, 14 Dec 2018 06:44:02 -0800
-Subject: [PATCH] getcpu01: Rename getcpu to avoid conflict with glibc >= 2.29
-
-glibc has added getcpu() API starting with glibc 2.29 release, this
-makes the static function in conflict and signatures are not same as
-well.
-
-Renaming helps to keep ltp build going
-
-Upstream-Status: Submitted 
[http://lists.linux.it/pipermail/ltp/2018-December/010321.html]
-
-Signed-off-by: Khem Raj 

- testcases/kernel/syscalls/getcpu/getcpu01.c | 10 +-
- 1 file changed, 5 insertions(+), 5 deletions(-)
-
-diff --git a/testcases/kernel/syscalls/getcpu/getcpu01.c 
b/testcases/kernel/syscalls/getcpu/getcpu01.c
-index c927512ca..e850fe844 100644
 a/testcases/kernel/syscalls/getcpu/getcpu01.c
-+++ b/testcases/kernel/syscalls/getcpu/getcpu01.c
-@@ -82,7 +82,7 @@ int sys_support = 0;
- 
- void cleanup(void);
- void setup(void);
--static inline int getcpu(unsigned int *, unsigned int *, void *);
-+static inline int get_cpu(unsigned int *, unsigned int *, void *);
- unsigned int set_cpu_affinity(void);
- unsigned int get_nodeid(unsigned int);
- unsigned int max_cpuid(size_t, cpu_set_t *);
-@@ -124,7 +124,7 @@ int main(int ac, char **av)
- #ifdef __i386__
-   node_set = get_nodeid(cpu_set);
- #endif
--  TEST(getcpu(_id, _id, NULL));
-+  TEST(get_cpu(_id, _id, NULL));
-   if (TEST_RETURN == 0) {
-   if (cpu_id != cpu_set) {
-   tst_resm(TFAIL, "getcpu() returned wrong value"
-@@ -157,10 +157,10 @@ int main(int ac, char **av)
- }
- 
- /*
-- * getcpu() - calls the system call
-+ * get_cpu() - calls the system call
-  */
--static inline int getcpu(unsigned *cpu_id, unsigned *node_id,
--   void *cache_struct)
-+static inline int get_cpu(unsigned *cpu_id, unsigned *node_id,
-+void *cache_struct)
- {
- #if defined(__i386__)
-   return syscall(318, cpu_id, node_id, cache_struct);
--- 
-2.20.0
-
diff --git 

Re: [OE-core] [PATCH 0/3] alsa recipe updates

2019-02-21 Thread Alexander Kanavin
Bah, and I often point out to people that they should read *my* cover letters :)
Thanks!

Alex

On Thu, 21 Feb 2019 at 17:41, Tanu Kaskinen  wrote:
>
> Richard already sent the update for sbc, so I left it out. As for alsa-
> tools, if you read the cover letter in more detail, you'll find the
> answer there :) (Spoiler: I'll send it, but it's not ready yet.)
>
> -- Tanu
>
> On Thu, 2019-02-21 at 15:57 +0100, Alexander Kanavin wrote:
> > (Also sbc needs an update, I think)
> >
> > Alex
> >
> >
> > On Thu, 21 Feb 2019 at 15:56, Alexander Kanavin  
> > wrote:
> > > Thanks! Will you be also sending an update to alsa-tools?
> > >
> > > Alex
> > >
> > > On Thu, 21 Feb 2019 at 14:34, Tanu Kaskinen  wrote:
> > > > The following changes since commit 
> > > > f15ceac287c094abdeda64b03628455d92e0ce74:
> > > >
> > > >   libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >   git://git.openembedded.org/openembedded-core-contrib tanuk/updates
> > > >   
> > > > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates
> > > >
> > > >
> > > > The alsa-tools update is missing, because the recipe upgrade deadline is
> > > > near and the changes in alsa-tools look like a potential rabbit hole.
> > > > I'll send the alsa-tools update separately when it's ready. The main
> > > > change in alsa-tools is that the hwmixvolume program got ported from
> > > > PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone
> > > > actually is using that program, it's not even built by default.
> > > >
> > > >
> > > > Tanu Kaskinen (3):
> > > >   alsa-lib: 1.1.6 -> 1.1.8
> > > >   alsa-plugins: 1.1.6 -> 1.1.8
> > > >   alsa-utils: 1.1.6 -> 1.1.8
> > > >
> > > >  .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}  |  4 +-
> > > >  ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 +--
> > > >  ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} |  0
> > > >  ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +--
> > > >  .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb |  2 +-
> > > >  5 files changed, 85 insertions(+), 15 deletions(-)
> > > >  rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => 
> > > > alsa-lib_1.1.8.bb} (88%)
> > > >  rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => 
> > > > alsa-plugins_1.1.8.bb} (51%)
> > > >  rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => 
> > > > alsa-utils-scripts_1.1.8.bb} (100%)
> > > >  rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => 
> > > > alsa-utils_1.1.8.bb} (92%)
> > > >
> > > > --
> > > > 2.20.1
> > > >
> > > > --
> > > > ___
> > > > Openembedded-core mailing list
> > > > Openembedded-core@lists.openembedded.org
> > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> Tanu
>
> https://www.patreon.com/tanuk
> https://liberapay.com/tanuk
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 0/3] alsa recipe updates

2019-02-21 Thread Tanu Kaskinen
Richard already sent the update for sbc, so I left it out. As for alsa-
tools, if you read the cover letter in more detail, you'll find the
answer there :) (Spoiler: I'll send it, but it's not ready yet.)

-- Tanu

On Thu, 2019-02-21 at 15:57 +0100, Alexander Kanavin wrote:
> (Also sbc needs an update, I think)
> 
> Alex
> 
> 
> On Thu, 21 Feb 2019 at 15:56, Alexander Kanavin  
> wrote:
> > Thanks! Will you be also sending an update to alsa-tools?
> > 
> > Alex
> > 
> > On Thu, 21 Feb 2019 at 14:34, Tanu Kaskinen  wrote:
> > > The following changes since commit 
> > > f15ceac287c094abdeda64b03628455d92e0ce74:
> > > 
> > >   libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   git://git.openembedded.org/openembedded-core-contrib tanuk/updates
> > >   
> > > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates
> > > 
> > > 
> > > The alsa-tools update is missing, because the recipe upgrade deadline is
> > > near and the changes in alsa-tools look like a potential rabbit hole.
> > > I'll send the alsa-tools update separately when it's ready. The main
> > > change in alsa-tools is that the hwmixvolume program got ported from
> > > PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone
> > > actually is using that program, it's not even built by default.
> > > 
> > > 
> > > Tanu Kaskinen (3):
> > >   alsa-lib: 1.1.6 -> 1.1.8
> > >   alsa-plugins: 1.1.6 -> 1.1.8
> > >   alsa-utils: 1.1.6 -> 1.1.8
> > > 
> > >  .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}  |  4 +-
> > >  ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 +--
> > >  ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} |  0
> > >  ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +--
> > >  .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb |  2 +-
> > >  5 files changed, 85 insertions(+), 15 deletions(-)
> > >  rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => 
> > > alsa-lib_1.1.8.bb} (88%)
> > >  rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => 
> > > alsa-plugins_1.1.8.bb} (51%)
> > >  rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => 
> > > alsa-utils-scripts_1.1.8.bb} (100%)
> > >  rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => 
> > > alsa-utils_1.1.8.bb} (92%)
> > > 
> > > --
> > > 2.20.1
> > > 
> > > --
> > > ___
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk

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


[OE-core] Incorporating deploy artefacts from one multiconfig in another multiconfig

2019-02-21 Thread Burton, Ross
So I'd like to use multiconfig for a fairly typical host/container use
case.  I've a class which can be used to build packages from images in
a fairly simple manner, essential just taking files from DEPLOY_DIR
when creating a package:

core-image-minimal-package.bb:
do_install[depends] += "core-image-minimal:do_image_complete
virtual/kernel:do_deploy"
do_install () {
install -d ${D}/var/lib/machines/
install ${DEPLOY_DIR_IMAGE}/core-image-minimal-${MACHINE}.ext4
${D}/var/lib/machines/core-image-minimal.ext4
install ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}
${D}/var/lib/machines/${IMAGE_NAME}.${KERNEL_IMAGETYPE}
}

This part works fine, but the problem is straddling multiconfig boundaries...

I can't just add "core-image-minimal-package" to IMAGE_INSTALL because
it will build that for the current configuration.  I can't just add
"multiconfig:uos:core-image-minimal-package" because that will look
for a recipe with that name.  I've a rather ugly hack to call opkg
directly in a post-rootfs hook which sort of works.  Linking in bits
of the other configuration's deploy directory in a pre-rootfs hook and
extending IMAGE_INSTALL there almost works, apart from the rootfs code
then looks at the task dependencies to generate a pruned deploy dir,
which is missing the pieces I linked in.

I suspect this is now breaking new ground: the multiconfiguration
support lets you do builds but so far the artefact sharing hasn't
really been explored.  Has anyone dug further into this?

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


Re: [OE-core] [RFC][PATCH v3] mesa: Convert recipe to use meson build system

2019-02-21 Thread Khem Raj
On Wed, Feb 20, 2019 at 9:11 PM Khem Raj  wrote:
>
> still seeing errors when building for rpi3-64
>
> | checking for xrandr... no
> | configure: error: Package requirements (xrandr) were not met:
> |
> | No package 'xrandr' found
> |
> | Consider adjusting the PKG_CONFIG_PATH environment variable if you
> | installed software in a non-standard prefix.
>

This is fixed with latest commit so we can move on but there is new one
on aarch64/rpi

https://errors.yoctoproject.org/Errors/Details/229582/

seems to be due to this commit.

https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743

probably a revert of the above patch is what can get us further.

>
> On Wed, Feb 20, 2019 at 4:41 PM Mittal, Anuj  wrote:
> >
> > On Wed, 2019-02-20 at 18:10 -0300, Fabio Berton wrote:
> > > +PACKAGECONFIG[xvmc] = "-gallium-xvmc=true,-Dgallium-
> > > xvmc=false,libxvmc"
> >
> > This is missing a '-D' ... Was a problem with my original patch as
> > well.
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [RFC][PATCH v3] mesa: Convert recipe to use meson build system

2019-02-21 Thread Khem Raj
On Thu, Feb 21, 2019 at 7:04 AM Khem Raj  wrote:
>
> On Thu, Feb 21, 2019 at 7:01 AM Alexander Kanavin
>  wrote:
> >
> > On Thu, 21 Feb 2019 at 15:56, Khem Raj  wrote:
> > > > still seeing errors when building for rpi3-64
> > > >
> > > > | checking for xrandr... no
> > > > | configure: error: Package requirements (xrandr) were not met:
> > > > |
> > > > | No package 'xrandr' found
> > > > |
> > > > | Consider adjusting the PKG_CONFIG_PATH environment variable if you
> > > > | installed software in a non-standard prefix.
> > > >
> > >
> > > This is fixed with latest commit so we can move on but there is new one
> > > on aarch64/rpi
> > >
> > > https://errors.yoctoproject.org/Errors/Details/229582/
> > >
> > > seems to be due to this commit.
> > >
> > > https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743
> > >
> > > probably a revert of the above patch is what can get us further.
> >
> > Shouldn't we rather add a dependency on the component providing the
> > missing include?
>
> fredreno build uses its own copy of libdrm IIRC and this might end up
> in unexpected results
> so revert would be safest
>

infact upstream has reverted it too
https://gitlab.freedesktop.org/mesa/drm/commit/e09f327765902f3b7d31874ccf0f45b783299bc0
> >
> > Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [RFC][PATCH v3] mesa: Convert recipe to use meson build system

2019-02-21 Thread Khem Raj
On Thu, Feb 21, 2019 at 7:01 AM Alexander Kanavin
 wrote:
>
> On Thu, 21 Feb 2019 at 15:56, Khem Raj  wrote:
> > > still seeing errors when building for rpi3-64
> > >
> > > | checking for xrandr... no
> > > | configure: error: Package requirements (xrandr) were not met:
> > > |
> > > | No package 'xrandr' found
> > > |
> > > | Consider adjusting the PKG_CONFIG_PATH environment variable if you
> > > | installed software in a non-standard prefix.
> > >
> >
> > This is fixed with latest commit so we can move on but there is new one
> > on aarch64/rpi
> >
> > https://errors.yoctoproject.org/Errors/Details/229582/
> >
> > seems to be due to this commit.
> >
> > https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743
> >
> > probably a revert of the above patch is what can get us further.
>
> Shouldn't we rather add a dependency on the component providing the
> missing include?

fredreno build uses its own copy of libdrm IIRC and this might end up
in unexpected results
so revert would be safest

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


Re: [OE-core] [RFC][PATCH v3] mesa: Convert recipe to use meson build system

2019-02-21 Thread Alexander Kanavin
On Thu, 21 Feb 2019 at 15:56, Khem Raj  wrote:
> > still seeing errors when building for rpi3-64
> >
> > | checking for xrandr... no
> > | configure: error: Package requirements (xrandr) were not met:
> > |
> > | No package 'xrandr' found
> > |
> > | Consider adjusting the PKG_CONFIG_PATH environment variable if you
> > | installed software in a non-standard prefix.
> >
>
> This is fixed with latest commit so we can move on but there is new one
> on aarch64/rpi
>
> https://errors.yoctoproject.org/Errors/Details/229582/
>
> seems to be due to this commit.
>
> https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743
>
> probably a revert of the above patch is what can get us further.

Shouldn't we rather add a dependency on the component providing the
missing include?

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


Re: [OE-core] [PATCH 0/3] alsa recipe updates

2019-02-21 Thread Alexander Kanavin
(Also sbc needs an update, I think)

Alex


On Thu, 21 Feb 2019 at 15:56, Alexander Kanavin  wrote:
>
> Thanks! Will you be also sending an update to alsa-tools?
>
> Alex
>
> On Thu, 21 Feb 2019 at 14:34, Tanu Kaskinen  wrote:
> >
> > The following changes since commit f15ceac287c094abdeda64b03628455d92e0ce74:
> >
> >   libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +)
> >
> > are available in the Git repository at:
> >
> >   git://git.openembedded.org/openembedded-core-contrib tanuk/updates
> >   
> > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates
> >
> >
> > The alsa-tools update is missing, because the recipe upgrade deadline is
> > near and the changes in alsa-tools look like a potential rabbit hole.
> > I'll send the alsa-tools update separately when it's ready. The main
> > change in alsa-tools is that the hwmixvolume program got ported from
> > PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone
> > actually is using that program, it's not even built by default.
> >
> >
> > Tanu Kaskinen (3):
> >   alsa-lib: 1.1.6 -> 1.1.8
> >   alsa-plugins: 1.1.6 -> 1.1.8
> >   alsa-utils: 1.1.6 -> 1.1.8
> >
> >  .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}  |  4 +-
> >  ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 +--
> >  ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} |  0
> >  ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +--
> >  .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb |  2 +-
> >  5 files changed, 85 insertions(+), 15 deletions(-)
> >  rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => 
> > alsa-lib_1.1.8.bb} (88%)
> >  rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => 
> > alsa-plugins_1.1.8.bb} (51%)
> >  rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => 
> > alsa-utils-scripts_1.1.8.bb} (100%)
> >  rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => 
> > alsa-utils_1.1.8.bb} (92%)
> >
> > --
> > 2.20.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


Re: [OE-core] [meta-oe] [PATCH 2/2] gtkwave: add version 3.3.98

2019-02-21 Thread akuster808


On 2/20/19 11:33 PM, Hoang Anh Tuan wrote:
>
> Signed-off-by: Hoang Anh Tuan 

Wrong ML, please send to openembedded-de...@lists.openembedded.org
> ---
>  meta-oe/recipes-graphics/gtkwave/gtkwave_3.3.98.bb | 19
> +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 meta-oe/recipes-graphics/gtkwave/gtkwave_3.3.98.bb
>
> diff --git a/meta-oe/recipes-graphics/gtkwave/gtkwave_3.3.98.bb
> b/meta-oe/recipes-graphics/gtkwave/gtkwave_3.3.98.bb
> new file mode 100644
> index 000..6fd9392
> --- /dev/null
> +++ b/meta-oe/recipes-graphics/gtkwave/gtkwave_3.3.98.bb
> @@ -0,0 +1,19 @@
> +SUMMARY = "VCD (Value Change Dump) file waveform viewer"
> +DESCRIPTION = "gtkwave is a viewer for VCD (Value Change Dump) files
> which are usually created by digital circuit simulators. (These files
> have no connection to video CDs!) "
> +HOMEPAGE = "http://gtkwave.sourceforge.net/;
> +
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=75859989545e37968a99b631ef42722e"
> +
> +SRC_URI = "http://gtkwave.sourceforge.net/${PN}-${PV}.tar.gz;
> +
> +SRC_URI[md5sum] = "eac3073ef381e0c09da33590296ca37f"
> +SRC_URI[sha256sum] =
> "efa6bbbeb3bd54104425a69a2aa0d079bb5c3ecc1c420ba57dcaa1c97c5a22f6"
> +
> +inherit pkgconfig autotools gettext texinfo
> +DEPENDS = "tcl tk gperf-native bzip2 xz pango zlib gtk+ gdk-pixbuf
> glib-2.0"
> +RDEPENDS_${PN} = "tk-lib"
> +
> +EXTRA_OECONF = "--with-tcl=${STAGING_BINDIR_CROSS}
> --with-tk=${STAGING_BINDIR_CROSS}"
> +
> +FILES_${PN} = "${bindir} ${datadir}"

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


Re: [OE-core] [PATCH 0/3] alsa recipe updates

2019-02-21 Thread Alexander Kanavin
Thanks! Will you be also sending an update to alsa-tools?

Alex

On Thu, 21 Feb 2019 at 14:34, Tanu Kaskinen  wrote:
>
> The following changes since commit f15ceac287c094abdeda64b03628455d92e0ce74:
>
>   libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +)
>
> are available in the Git repository at:
>
>   git://git.openembedded.org/openembedded-core-contrib tanuk/updates
>   http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates
>
>
> The alsa-tools update is missing, because the recipe upgrade deadline is
> near and the changes in alsa-tools look like a potential rabbit hole.
> I'll send the alsa-tools update separately when it's ready. The main
> change in alsa-tools is that the hwmixvolume program got ported from
> PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone
> actually is using that program, it's not even built by default.
>
>
> Tanu Kaskinen (3):
>   alsa-lib: 1.1.6 -> 1.1.8
>   alsa-plugins: 1.1.6 -> 1.1.8
>   alsa-utils: 1.1.6 -> 1.1.8
>
>  .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}  |  4 +-
>  ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 +--
>  ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} |  0
>  ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +--
>  .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb |  2 +-
>  5 files changed, 85 insertions(+), 15 deletions(-)
>  rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} 
> (88%)
>  rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => 
> alsa-plugins_1.1.8.bb} (51%)
>  rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => 
> alsa-utils-scripts_1.1.8.bb} (100%)
>  rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => 
> alsa-utils_1.1.8.bb} (92%)
>
> --
> 2.20.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


Re: [OE-core] wic creates ext4 images that read really slow in u-boot

2019-02-21 Thread Tom Rini
On Wed, Feb 20, 2019 at 10:55:20AM +, Mike Looijmans wrote:

> >>> I am aware of two fixes for U-Boot. I will look them up, and reply again 
> >>> to this thread.
> 
> Browsing through u-boot commits, I found this gem that's disabled by default:
> 
> CONFIG_BLOCK_CACHE=y
> 
> The commit is this one:
> 
> commit e40cf34a29f1b248643731a11fb1c6f0520d016c
> Author: Eric Nelson 
> Date:   Mon Mar 28 10:05:44 2016 -0700
> 
>  drivers: block: add block device cache
> 
>  Add a block device cache to speed up repeated reads of block devices by
>  various filesystems.

For the record, it's not that it's disabled by default but rather to
enable it, you need to enable other "new" frameworks and so forth.  And
at least for "legacy" platforms, there's a certain level of pushback
against doing the work required to enable that (as to be honest, it is
more than just enable a few CONFIG options and re-test).  A
counter-pushback of "but it enables things that fix some bad performance
problems!" would be really helpful.

-- 
Tom


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


[OE-core] [PATCH 0/3] alsa recipe updates

2019-02-21 Thread Tanu Kaskinen
The following changes since commit f15ceac287c094abdeda64b03628455d92e0ce74:

  libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib tanuk/updates
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates


The alsa-tools update is missing, because the recipe upgrade deadline is
near and the changes in alsa-tools look like a potential rabbit hole.
I'll send the alsa-tools update separately when it's ready. The main
change in alsa-tools is that the hwmixvolume program got ported from
PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone
actually is using that program, it's not even built by default.


Tanu Kaskinen (3):
  alsa-lib: 1.1.6 -> 1.1.8
  alsa-plugins: 1.1.6 -> 1.1.8
  alsa-utils: 1.1.6 -> 1.1.8

 .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}  |  4 +-
 ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 +--
 ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} |  0
 ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +--
 .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb |  2 +-
 5 files changed, 85 insertions(+), 15 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} 
(88%)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => 
alsa-plugins_1.1.8.bb} (51%)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => 
alsa-utils-scripts_1.1.8.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => 
alsa-utils_1.1.8.bb} (92%)

-- 
2.20.1

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


[OE-core] [PATCH 1/3] alsa-lib: 1.1.6 -> 1.1.8

2019-02-21 Thread Tanu Kaskinen
Changelogs:
http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7
http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8

One significant change was that the search path of add-on configuration
files was changed from /usr/share/alsa/alsa.conf.d to /etc/alsa/conf.d.
Packages that install such files should still use the /usr/share
location, though. Symlinks need to be created from /etc to /usr/share.
The rationale for using /etc is that the system administrator can better
control the configuration that way, and the rationale for installing
files under /usr/share is that configuration snippets that are installed
by packages are not meant to be directly edited by the administrator.

alsa-plugins had to be modified to add symlinks for the configuration
snippets that it installs. I also added FILES_${PN} = "", because the
alsa-plugins package is supposed to be empty, but also because for some
reason that I don't understand the symlinks would otherwise go to the
alsa-plugins package rather than alsa-plugins-pulseaudio-conf.

Signed-off-by: Tanu Kaskinen 
---
 .../alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb}   |  4 ++--
 meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb  | 13 -
 2 files changed, 14 insertions(+), 3 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} 
(88%)

diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb
similarity index 88%
rename from meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb
rename to meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb
index 25e7a3c6b7..bb22acdd33 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb
@@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=a916467b91076e631dd8edb7424769c7 \
 "
 
 SRC_URI = "ftp://ftp.alsa-project.org/pub/lib/${BP}.tar.bz2;
-SRC_URI[md5sum] = "2f981a8f7897c59ec2ddc44916d33788"
-SRC_URI[sha256sum] = 
"5f2cd274b272cae0d0d111e8a9e363f08783329157e8dd68b3de0c096de6d724"
+SRC_URI[md5sum] = "0eec0d657a07927795809c8f87fb76ca"
+SRC_URI[sha256sum] = 
"3cdc3a93a6427a26d8efab4ada2152e64dd89140d981f6ffa003e85be707aedf"
 
 inherit autotools pkgconfig
 
diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
index 7ede8be98a..ee06191ea9 100644
--- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
+++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
@@ -47,14 +47,23 @@ PACKAGES_DYNAMIC = "^libasound-module-.*"
 
 # The alsa-plugins package doesn't itself contain anything, it just depends on
 # all built plugins.
+FILES_${PN} = ""
 ALLOW_EMPTY_${PN} = "1"
 
 do_install_append() {
rm ${D}${libdir}/alsa-lib/*.la
 
-   # We use the example as is, so just drop the .example suffix.
if [ "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'yes', 'no', 
d)}" = "yes" ]; then
+   # We use the example as is, so just drop the .example suffix.
mv 
${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf.example 
${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf
+
+   # The conf.d files are installed in datadir, but alsa-lib
+   # searches for conf.d files only in sysconfdir. Distributions
+   # are expected to create symlinks in sysconfdir, so that's what
+   # we do here.
+   mkdir -p ${D}${sysconfdir}/alsa/conf.d
+   ln -s ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf 
${D}${sysconfdir}/alsa/conf.d/50-pulseaudio.conf
+   ln -s ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf 
${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf
fi
 }
 
@@ -94,6 +103,8 @@ INSANE_SKIP_${MLPREFIX}libasound-module-rate-speexrate = 
"dev-so"
 FILES_${PN}-pulseaudio-conf += "\
 ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf \
 ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf \
+${sysconfdir}/alsa/conf.d/50-pulseaudio.conf \
+${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf \
 "
 
 RDEPENDS_${PN}-pulseaudio-conf += "\
-- 
2.20.1

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


[OE-core] [PATCH 3/3] alsa-utils: 1.1.6 -> 1.1.8

2019-02-21 Thread Tanu Kaskinen
Changelogs:
http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7
http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8

There's a new program, axfer, which is a reimplementation of aplay (and
arecord). The purpose of the rewrite is to have code that is easier to
maintain. For now both implementations exist, and I decided to put both
in the aplay package.

The new 89-alsa-ucm.rules udev file initializes the mixer settings for
certain hardware. It's needed for making the hardware usable at boot, in
case there's no higher level software (such as PulseAudio) managing the
mixer settings. Shipping hardware specific configuration in alsa-utils
seems wrong, but I don't know what else to do. I added it to the alsaucm
package, because it's kind of tied to the alsaucm utility (the udev
rules execute the alsaucm program, and the build system installs the
rules file only when alsaucm is enabled). Ideally the UCM configuration
in alsa-lib would define the default UCM verb for each hardware, then
the udev rules file could just enable the default verb, and there would
be no hardware specific configuration in alsa-utils. But that requires
upstream development effort.

Signed-off-by: Tanu Kaskinen 
---
 ...ls-scripts_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} |  0
 .../alsa/{alsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb}  | 10 +-
 2 files changed, 5 insertions(+), 5 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => 
alsa-utils-scripts_1.1.8.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => 
alsa-utils_1.1.8.bb} (92%)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.8.bb
similarity index 100%
rename from meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.6.bb
rename to meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.8.bb
diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb
similarity index 92%
rename from meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb
rename to meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb
index b8ba0cb22a..ab02169ac6 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb
@@ -22,8 +22,8 @@ PACKAGECONFIG[manpages] = "--enable-xmlto, --disable-xmlto, 
xmlto-native docbook
 SRC_URI = "ftp://ftp.alsa-project.org/pub/utils/alsa-utils-${PV}.tar.bz2 \
   "
 
-SRC_URI[md5sum] = "50ae75567459646b843bed78d916b002"
-SRC_URI[sha256sum] = 
"155caecc40b2220f686f34ba3655a53e3bdbc0586adb1056733949feaaf7d36e"
+SRC_URI[md5sum] = "54d6f9b483144823d0fc0c26e8cea028"
+SRC_URI[sha256sum] = 
"fd9bf528922b3829a91913b89a1858c58a0b24271a7b5f529923aa9ea12fa4cf"
 
 # On build machines with python-docutils (not python3-docutils !!) installed
 # rst2man (not rst2man.py) is detected and compile fails with
@@ -59,7 +59,7 @@ RDEPENDS_${PN} += "${ALSA_UTILS_PKGS}"
 FILES_${PN} = ""
 FILES_alsa-utils-alsabat = "${bindir}/alsabat"
 FILES_alsa-utils-alsatplg= "${bindir}/alsatplg"
-FILES_alsa-utils-aplay   = "${bindir}/aplay ${bindir}/arecord"
+FILES_alsa-utils-aplay   = "${bindir}/aplay ${bindir}/arecord 
${bindir}/axfer"
 FILES_alsa-utils-amixer  = "${bindir}/amixer"
 FILES_alsa-utils-alsamixer   = "${bindir}/alsamixer"
 FILES_alsa-utils-speakertest = "${bindir}/speaker-test ${datadir}/sounds/alsa/ 
${datadir}/alsa/speaker-test/"
@@ -67,10 +67,10 @@ FILES_alsa-utils-midi= "${bindir}/aplaymidi 
${bindir}/arecordmidi ${bind
 FILES_alsa-utils-aconnect= "${bindir}/aconnect"
 FILES_alsa-utils-aseqnet = "${bindir}/aseqnet"
 FILES_alsa-utils-iecset  = "${bindir}/iecset"
-FILES_alsa-utils-alsactl = "${sbindir}/alsactl */udev/rules.d 
*/*/udev/rules.d ${systemd_unitdir} ${localstatedir}/lib/alsa 
${datadir}/alsa/init/"
+FILES_alsa-utils-alsactl = "${sbindir}/alsactl 
*/udev/rules.d/90-alsa-restore.rules */*/udev/rules.d/90-alsa-restore.rules 
${systemd_unitdir} ${localstatedir}/lib/alsa ${datadir}/alsa/init/"
 FILES_alsa-utils-aseqdump= "${bindir}/aseqdump"
 FILES_alsa-utils-alsaloop= "${bindir}/alsaloop"
-FILES_alsa-utils-alsaucm = "${bindir}/alsaucm"
+FILES_alsa-utils-alsaucm = "${bindir}/alsaucm 
*/udev/rules.d/89-alsa-ucm.rules */*/udev/rules.d/89-alsa-ucm.rules"
 
 SUMMARY_alsa-utils-alsabat  = "Command-line sound tester for ALSA sound 
card driver"
 SUMMARY_alsa-utils-alsatplg = "Converts topology text files into binary 
format for kernel"
-- 
2.20.1

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


[OE-core] [PATCH 2/3] alsa-plugins: 1.1.6 -> 1.1.8

2019-02-21 Thread Tanu Kaskinen
Changelogs:
http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7
http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8

The --enable-avcodec configure option was renamed to --enable-libav, and
I renamed the respective packageconfig item too.

There's a new pcm plugin: aaf (AVTP Audio Format). I added a
packageconfig item for it, but I didn't test it, because libavtp doesn't
seem to be currently packaged for OpenEmbedded.

There are now configuration files for most of the plugins. I removed the
symlink creation for 50-pulseaudio.conf, because upstream now creates
the symlinks for us. 99-pulseaudio-default.conf is an exception, because
upstream ships it only as an example, and upstream doesn't install a
symlink for it (upstream actually installs it directly under /etc, but I
moved it back to /usr/share), so for that file we still have to create
the symlink ourselves.

The lavcrate plugin was converted to use libavresample (and renamed to
lavrate). Libavresample is provided by ffmpeg, but ffmpeg was by default
built with libavresample disabled. This patch now enables libavresample
by default in the ffmpeg recipe in order to not cause a regression in
alsa-plugins.

Signed-off-by: Tanu Kaskinen 
---
 ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 87 ---
 .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb |  2 +-
 2 files changed, 74 insertions(+), 15 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => 
alsa-plugins_1.1.8.bb} (54%)

diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb
similarity index 54%
rename from meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
rename to meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb
index ee06191ea9..3da2634e94 100644
--- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
+++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb
@@ -21,8 +21,8 @@ LIC_FILES_CHKSUM = "\
 "
 
 SRC_URI = "ftp://ftp.alsa-project.org/pub/plugins/${BP}.tar.bz2;
-SRC_URI[md5sum] = "8387279e99feeb2ecffaac5f293223d7"
-SRC_URI[sha256sum] = 
"6f1d31ebe3b1fa1cc8dade60b7bed1cb2583ac998167002d350dc0a5e3e40c13"
+SRC_URI[md5sum] = "d0f87211d1560f2c07c8eae4297bc4f6"
+SRC_URI[sha256sum] = 
"7f77df171685ccec918268477623a39db4d9f32d5dc5e76874ef2467a2405994"
 
 DEPENDS += "alsa-lib"
 
@@ -33,8 +33,9 @@ PACKAGECONFIG ??= "\
 speexdsp \
 ${@bb.utils.filter('DISTRO_FEATURES', 'pulseaudio', d)} \
 "
-PACKAGECONFIG[avcodec] = "--enable-avcodec,--disable-avcodec,libav"
+PACKAGECONFIG[aaf] = "--enable-aaf,--disable-aaf,avtp"
 PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack"
+PACKAGECONFIG[libav] = "--enable-libav,--disable-libav,libav"
 PACKAGECONFIG[maemo-plugin] = "--enable-maemo-plugin,--disable-maemo-plugin"
 PACKAGECONFIG[maemo-resource-manager] = 
"--enable-maemo-resource-manager,--disable-maemo-resource-manager,dbus"
 PACKAGECONFIG[pulseaudio] = 
"--enable-pulseaudio,--disable-pulseaudio,pulseaudio"
@@ -54,15 +55,11 @@ do_install_append() {
rm ${D}${libdir}/alsa-lib/*.la
 
if [ "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'yes', 'no', 
d)}" = "yes" ]; then
-   # We use the example as is, so just drop the .example suffix.
-   mv 
${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf.example 
${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf
-
-   # The conf.d files are installed in datadir, but alsa-lib
-   # searches for conf.d files only in sysconfdir. Distributions
-   # are expected to create symlinks in sysconfdir, so that's what
-   # we do here.
-   mkdir -p ${D}${sysconfdir}/alsa/conf.d
-   ln -s ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf 
${D}${sysconfdir}/alsa/conf.d/50-pulseaudio.conf
+   # We use the example as is. Upstream installs the file under
+   # /etc, but we move it under /usr/share and add a symlink under
+   # /etc to be consistent with other installed configuration
+   # files.
+   mv 
${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf.example 
${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf
ln -s ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf 
${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf
fi
 }
@@ -73,6 +70,68 @@ python populate_packages_prepend() {
 d.setVar("RDEPENDS_alsa-plugins", packages)
 }
 
+# Many plugins have a configuration file (plus a symlink in /etc) associated
+# with them. We put the plugin and it's configuration usually in the same
+# package, but that's problematic when the configuration file is related to
+# multiple plugins, as is the case with the pulse, oss and maemo plugins. In
+# case of the pulse plugins, we have a separate alsa-plugins-pulseaudio-conf
+# package that depends on all the pulse plugins, which ensures that all plugins
+# that the configuration 

Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation

2019-02-21 Thread Mike Crowe
On Thursday 21 February 2019 at 13:01:27 +, Richard Purdie wrote:
> On Wed, 2019-02-20 at 16:47 +, Mike Crowe wrote:
> > On Wednesday 23 January 2019 at 16:27:59 +, Mike Crowe wrote:
> > > 
> > > Does the lack of response mean that both approaches are horrendous?
> > > If so, do you have any better ideas?
> > 
> > There doesn't seem to be much interest in this one.
> > 
> > The only other idea I've had is to create the symlink at rootfs-creation
> > time. However, that seems to be detaching it too much from glibc, which
> > would cause confusion.
> > 
> > I can apply one of my fixes locally (we currently have some far uglier
> > hacks than these that I'd like to remove), but I'd really rather not have
> > to diverge from upstream this much.
> 
> Sorry for the lack of feedback.
> 
> I'm fairly strongly against a separate aarch64 only recipe for this.
> Realistically we therefore have to fix this in the existing
> class/code/recipe.
> 
> The changes you sent previously didn't look that horrific, did you find
> a working version of that?
> 
> I'm wondering if we can come up with something which works and
> hopefully we can spot some way to then clean it up to be a bit nicer...
> 
> The delay was that I was going to try and come up with something but
> that hasn't happened yet. If you have a horrific non-separate recipe
> version that is complete, we can see if we can do anything to improve
> it.

I had suspected that was the reason for the delay.

I shall knock my modifications to glibc-package.inc into shape and send a
tested patch. I've already improved it a little compared to the version I
sent previously.

Thanks for the response.

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


[OE-core] [PATCH] devtool: deploy-target: allow use of alternate ssh

2019-02-21 Thread Olaf Mandel
Allow the use of an alternate SSH executable for deploy-target and
undeploy-target. The command can be specified with -e / --ssh-exec.

Signed-off-by: Olaf Mandel 
---
 scripts/lib/devtool/deploy.py | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py
index 886004b5d0..f345f31b7b 100644
--- a/scripts/lib/devtool/deploy.py
+++ b/scripts/lib/devtool/deploy.py
@@ -211,6 +211,11 @@ def deploy(args, config, basepath, workspace):
 if not args.show_status:
 extraoptions += ' -q'
 
+scp_sshexec = ''
+ssh_sshexec = 'ssh'
+if args.ssh_exec:
+scp_sshexec = "-S %s" % args.ssh_exec
+ssh_sshexec = args.ssh_exec
 scp_port = ''
 ssh_port = ''
 if args.port:
@@ -238,7 +243,7 @@ def deploy(args, config, basepath, workspace):
 for fpath, fsize in filelist:
 f.write('%s %d\n' % (fpath, fsize))
 # Copy them to the target
-ret = subprocess.call("scp %s %s %s/* %s:%s" % (scp_port, 
extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), shell=True)
+ret = subprocess.call("scp %s %s %s %s/* %s:%s" % (scp_sshexec, 
scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), 
shell=True)
 if ret != 0:
 raise DevtoolError('Failed to copy script to %s - rerun with 
-s to '
 'get a complete error message' % args.target)
@@ -246,7 +251,7 @@ def deploy(args, config, basepath, workspace):
 shutil.rmtree(tmpdir)
 
 # Now run the script
-ret = exec_fakeroot(rd, 'tar cf - . | ssh  %s %s %s \'sh %s %s %s 
%s\'' % (ssh_port, extraoptions, args.target, tmpscript, args.recipename, 
destdir, tmpfilelist), cwd=recipe_outdir, shell=True)
+ret = exec_fakeroot(rd, 'tar cf - . | %s  %s %s %s \'sh %s %s %s %s\'' 
% (ssh_sshexec, ssh_port, extraoptions, args.target, tmpscript, 
args.recipename, destdir, tmpfilelist), cwd=recipe_outdir, shell=True)
 if ret != 0:
 raise DevtoolError('Deploy failed - rerun with -s to get a 
complete '
 'error message')
@@ -276,6 +281,11 @@ def undeploy(args, config, basepath, workspace):
 if not args.show_status:
 extraoptions += ' -q'
 
+scp_sshexec = ''
+ssh_sshexec = 'ssh'
+if args.ssh_exec:
+scp_sshexec = "-S %s" % args.ssh_exec
+ssh_sshexec = args.ssh_exec
 scp_port = ''
 ssh_port = ''
 if args.port:
@@ -292,7 +302,7 @@ def undeploy(args, config, basepath, workspace):
 with open(os.path.join(tmpdir, os.path.basename(tmpscript)), 'w') as f:
 f.write(shellscript)
 # Copy it to the target
-ret = subprocess.call("scp %s %s %s/* %s:%s" % (scp_port, 
extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), shell=True)
+ret = subprocess.call("scp %s %s %s %s/* %s:%s" % (scp_sshexec, 
scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), 
shell=True)
 if ret != 0:
 raise DevtoolError('Failed to copy script to %s - rerun with -s to 
'
 'get a complete error message' % args.target)
@@ -300,7 +310,7 @@ def undeploy(args, config, basepath, workspace):
 shutil.rmtree(tmpdir)
 
 # Now run the script
-ret = subprocess.call('ssh %s %s %s \'sh %s %s\'' % (ssh_port, 
extraoptions, args.target, tmpscript, args.recipename), shell=True)
+ret = subprocess.call('%s %s %s %s \'sh %s %s\'' % (ssh_sshexec, ssh_port, 
extraoptions, args.target, tmpscript, args.recipename), shell=True)
 if ret != 0:
 raise DevtoolError('Undeploy failed - rerun with -s to get a complete '
'error message')
@@ -324,6 +334,7 @@ def register_commands(subparsers, context):
 parser_deploy.add_argument('-n', '--dry-run', help='List files to be 
deployed only', action='store_true')
 parser_deploy.add_argument('-p', '--no-preserve', help='Do not preserve 
existing files', action='store_true')
 parser_deploy.add_argument('--no-check-space', help='Do not check for 
available space before deploying', action='store_true')
+parser_deploy.add_argument('-e', '--ssh-exec', help='Executable to use in 
place of ssh')
 parser_deploy.add_argument('-P', '--port', help='Specify port to use for 
connection to the target')
 
 strip_opts = parser_deploy.add_mutually_exclusive_group(required=False)
@@ -346,5 +357,6 @@ def register_commands(subparsers, context):
 parser_undeploy.add_argument('-s', '--show-status', help='Show 
progress/status output', action='store_true')
 parser_undeploy.add_argument('-a', '--all', help='Undeploy all recipes 
deployed on the target', action='store_true')
 parser_undeploy.add_argument('-n', '--dry-run', help='List files to be 
undeployed only', action='store_true')
+

Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation

2019-02-21 Thread Richard Purdie
On Wed, 2019-02-20 at 16:47 +, Mike Crowe wrote:
> On Wednesday 23 January 2019 at 16:27:59 +, Mike Crowe wrote:
> > 
> > Does the lack of response mean that both approaches are horrendous?
> > If so, do you have any better ideas?
> 
> There doesn't seem to be much interest in this one.
> 
> The only other idea I've had is to create the symlink at rootfs-creation
> time. However, that seems to be detaching it too much from glibc, which
> would cause confusion.
> 
> I can apply one of my fixes locally (we currently have some far uglier
> hacks than these that I'd like to remove), but I'd really rather not have
> to diverge from upstream this much.

Sorry for the lack of feedback.

I'm fairly strongly against a separate aarch64 only recipe for this.
Realistically we therefore have to fix this in the existing
class/code/recipe.

The changes you sent previously didn't look that horrific, did you find
a working version of that?

I'm wondering if we can come up with something which works and
hopefully we can spot some way to then clean it up to be a bit nicer...

The delay was that I was going to try and come up with something but
that hasn't happened yet. If you have a horrific non-separate recipe
version that is complete, we can see if we can do anything to improve
it.

Cheers,

Richard

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


[OE-core] [PATCH 08/14] netbase: upgrade 5.5 -> 5.6

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 ...netbase-add-rpcbind-as-an-alias-to-sunrpc.patch | 14 ++
 .../netbase/{netbase_5.5.bb => netbase_5.6.bb} |  4 ++--
 2 files changed, 8 insertions(+), 10 deletions(-)
 rename meta/recipes-core/netbase/{netbase_5.5.bb => netbase_5.6.bb} (83%)

diff --git 
a/meta/recipes-core/netbase/netbase/netbase-add-rpcbind-as-an-alias-to-sunrpc.patch
 
b/meta/recipes-core/netbase/netbase/netbase-add-rpcbind-as-an-alias-to-sunrpc.patch
index 56c8d5b5c21..27ba2f68a26 100644
--- 
a/meta/recipes-core/netbase/netbase/netbase-add-rpcbind-as-an-alias-to-sunrpc.patch
+++ 
b/meta/recipes-core/netbase/netbase/netbase-add-rpcbind-as-an-alias-to-sunrpc.patch
@@ -1,4 +1,4 @@
-From 76989205a1411f16d7ab09ff9d279539a73dc259 Mon Sep 17 00:00:00 2001
+From 52d46c4d1fbd4c88d69c2fcf7837b2f2ba7ef6f2 Mon Sep 17 00:00:00 2001
 From: "Maxin B. John" 
 Date: Thu, 12 Jan 2017 16:50:58 +0200
 Subject: [PATCH] netbase: add rpcbind as an alias to sunrpc
@@ -10,6 +10,7 @@ Upstream-Status: Pending
 
 Signed-off-by: Li Wang 
 Signed-off-by: Maxin B. John 
+
 ---
  etc-rpc  | 2 +-
  etc-services | 4 ++--
@@ -29,12 +30,12 @@ index 1b30625..9a9a81a 100644
  rusersd   12  rusers
  nfs   13  nfsprog
 diff --git a/etc-services b/etc-services
-index e3202ec..a039d7e 100644
+index fa7ae24..10ba2bc 100644
 --- a/etc-services
 +++ b/etc-services
-@@ -64,8 +64,8 @@ csnet-ns 105/udp cso-ns
- rtelnet   107/tcp # Remote Telnet
- rtelnet   107/udp
+@@ -51,8 +51,8 @@ kerberos 88/udp  kerberos5 krb5 kerberos-sec 
# Kerberos v5
+ iso-tsap  102/tcp tsap# part of ISODE
+ acr-nema  104/tcp dicom   # Digital Imag. & Comm. 300
  pop3  110/tcp pop-3   # POP version 3
 -sunrpc111/tcp portmapper  # RPC 4.0 portmapper
 -sunrpc111/udp portmapper
@@ -43,6 +44,3 @@ index e3202ec..a039d7e 100644
  auth  113/tcp authentication tap ident
  sftp  115/tcp
  nntp  119/tcp readnews untp   # USENET News Transfer Protocol
--- 
-2.4.0
-
diff --git a/meta/recipes-core/netbase/netbase_5.5.bb 
b/meta/recipes-core/netbase/netbase_5.6.bb
similarity index 83%
rename from meta/recipes-core/netbase/netbase_5.5.bb
rename to meta/recipes-core/netbase/netbase_5.6.bb
index eb53adda8d9..2aa49711cca 100644
--- a/meta/recipes-core/netbase/netbase_5.5.bb
+++ b/meta/recipes-core/netbase/netbase_5.6.bb
@@ -9,8 +9,8 @@ PE = "1"
 SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz \
file://netbase-add-rpcbind-as-an-alias-to-sunrpc.patch"
 
-SRC_URI[md5sum] = "15f2d9b3783802f7f48f6734b6540ac4"
-SRC_URI[sha256sum] = 
"309bddc69a43b98e5a450992b70cdfc0e3d1afb9107bc631d04b0714be98f88b"
+SRC_URI[md5sum] = "7ad156272c5a42f49c73386ff39c8624"
+SRC_URI[sha256sum] = 
"5d93a099deb28869b7306e914700fafbd293b55bdb5df05a5aa6effd0af5930c"
 
 UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/n/netbase/"
 do_install () {
-- 
2.20.1

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


[OE-core] [PATCH 10/14] readline: upgrade 7.0 -> 8.0

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 .../{readline-7.0 => readline-8.0}/configure-fix.patch | 0
 .../readline/{readline-7.0 => readline-8.0}/norpath.patch  | 0
 meta/recipes-core/readline/readline_7.0.bb | 7 ---
 meta/recipes-core/readline/readline_8.0.bb | 7 +++
 4 files changed, 7 insertions(+), 7 deletions(-)
 rename meta/recipes-core/readline/{readline-7.0 => 
readline-8.0}/configure-fix.patch (100%)
 rename meta/recipes-core/readline/{readline-7.0 => readline-8.0}/norpath.patch 
(100%)
 delete mode 100644 meta/recipes-core/readline/readline_7.0.bb
 create mode 100644 meta/recipes-core/readline/readline_8.0.bb

diff --git a/meta/recipes-core/readline/readline-7.0/configure-fix.patch 
b/meta/recipes-core/readline/readline-8.0/configure-fix.patch
similarity index 100%
rename from meta/recipes-core/readline/readline-7.0/configure-fix.patch
rename to meta/recipes-core/readline/readline-8.0/configure-fix.patch
diff --git a/meta/recipes-core/readline/readline-7.0/norpath.patch 
b/meta/recipes-core/readline/readline-8.0/norpath.patch
similarity index 100%
rename from meta/recipes-core/readline/readline-7.0/norpath.patch
rename to meta/recipes-core/readline/readline-8.0/norpath.patch
diff --git a/meta/recipes-core/readline/readline_7.0.bb 
b/meta/recipes-core/readline/readline_7.0.bb
deleted file mode 100644
index 85dfaa62948..000
--- a/meta/recipes-core/readline/readline_7.0.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-require readline.inc
-
-SRC_URI += "file://configure-fix.patch \
-file://norpath.patch"
-
-SRC_URI[archive.md5sum] = "205b03a87fc83dab653b628c59b9fc91"
-SRC_URI[archive.sha256sum] = 
"750d437185286f40a369e1e4f4764eda932b9459b5ec9a731628393dd3d32334"
diff --git a/meta/recipes-core/readline/readline_8.0.bb 
b/meta/recipes-core/readline/readline_8.0.bb
new file mode 100644
index 000..99d022a32f6
--- /dev/null
+++ b/meta/recipes-core/readline/readline_8.0.bb
@@ -0,0 +1,7 @@
+require readline.inc
+
+SRC_URI += "file://configure-fix.patch \
+file://norpath.patch"
+
+SRC_URI[archive.md5sum] = "7e6c1f16aee3244a69aba6e438295ca3"
+SRC_URI[archive.sha256sum] = 
"e339f51971478d369f8a053a330a190781acb9864cf4c541060f12078948e461"
-- 
2.20.1

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


[OE-core] [PATCH 07/14] libxau: upgrade 1.0.8 -> 1.0.9

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 .../xorg-lib/{libxau_1.0.8.bb => libxau_1.0.9.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-lib/{libxau_1.0.8.bb => libxau_1.0.9.bb} 
(76%)

diff --git a/meta/recipes-graphics/xorg-lib/libxau_1.0.8.bb 
b/meta/recipes-graphics/xorg-lib/libxau_1.0.9.bb
similarity index 76%
rename from meta/recipes-graphics/xorg-lib/libxau_1.0.8.bb
rename to meta/recipes-graphics/xorg-lib/libxau_1.0.9.bb
index 8c52475b855..dcfc66652a8 100644
--- a/meta/recipes-graphics/xorg-lib/libxau_1.0.8.bb
+++ b/meta/recipes-graphics/xorg-lib/libxau_1.0.9.bb
@@ -20,5 +20,5 @@ XORG_PN = "libXau"
 
 BBCLASSEXTEND = "native nativesdk"
 
-SRC_URI[md5sum] = "685f8abbffa6d145c0f930f00703b21b"
-SRC_URI[sha256sum] = 
"fdd477320aeb5cdd67272838722d6b7d544887dfe7de46e1e7cc0c27c2bea4f2"
+SRC_URI[md5sum] = "c5f16288f2da9f071b29111d68797480"
+SRC_URI[sha256sum] = 
"ccf8cbf0dbf676faa2ea0a6d64bcc3b6746064722b606c8c52917ed00dcb73ec"
-- 
2.20.1

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


[OE-core] [PATCH 05/14] less: upgrade 530 -> 549

2019-02-21 Thread Richard Purdie
The license checksum changed due to a change in copyright years.

Signed-off-by: Richard Purdie 
---
 meta/recipes-extended/less/{less_530.bb => less_549.bb} | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)
 rename meta/recipes-extended/less/{less_530.bb => less_549.bb} (82%)

diff --git a/meta/recipes-extended/less/less_530.bb 
b/meta/recipes-extended/less/less_549.bb
similarity index 82%
rename from meta/recipes-extended/less/less_530.bb
rename to meta/recipes-extended/less/less_549.bb
index c07b1217449..140c89fcb0b 100644
--- a/meta/recipes-extended/less/less_530.bb
+++ b/meta/recipes-extended/less/less_549.bb
@@ -21,14 +21,15 @@ SECTION = "console/utils"
 
 LICENSE = "GPLv3+ | BSD-2-Clause"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
-file://LICENSE;md5=2ef3e4b8dafc85612bc5254b8081e234"
+file://LICENSE;md5=ba01d0cab7f62f7f2204c7780ff6a87d \
+"
 DEPENDS = "ncurses"
 
 SRC_URI = "http://www.greenwoodsoftware.com/${BPN}/${BPN}-${PV}.tar.gz \
  "
 
-SRC_URI[md5sum] = "6a39bccf420c946b0fd7ffc64961315b"
-SRC_URI[sha256sum] = 
"503f91ab0af4846f34f0444ab71c4b286123f0044a4964f1ae781486c617f2e2"
+SRC_URI[md5sum] = "d12863d348077739a4d3bc67ad9b7f00"
+SRC_URI[sha256sum] = 
"eec42357903faabfb294ffcc41ff08cbb29db54db46568cd8d0ed15a0482e19d"
 
 UPSTREAM_CHECK_URI = "http://www.greenwoodsoftware.com/less/download.html;
 
-- 
2.20.1

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


[OE-core] [PATCH 04/14] gst-examples: upgrade to latest revision

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 meta/recipes-multimedia/gstreamer/gst-examples_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-examples_git.bb 
b/meta/recipes-multimedia/gstreamer/gst-examples_git.bb
index 1d87f24fe59..f8cef857b32 100644
--- a/meta/recipes-multimedia/gstreamer/gst-examples_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-examples_git.bb
@@ -8,7 +8,7 @@ SRC_URI = "git://anongit.freedesktop.org/gstreamer/gst-examples 
\
file://0001-Make-player-examples-installable.patch \
file://gst-player.desktop"
 
-SRCREV = "48247c6ab6807d6ae179cf653cbdc64714d3313c"
+SRCREV = "2b3fc175c252cd5a537e4b2864b572a8372473d6"
 PV = "0.0.1+git${SRCPV}"
 UPSTREAM_CHECK_COMMITS = "1"
 
-- 
2.20.1

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


[OE-core] [PATCH 06/14] libassuan: upgrade 2.5.2 -> 2.5.3

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 .../libassuan/{libassuan_2.5.2.bb => libassuan_2.5.3.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/libassuan/{libassuan_2.5.2.bb => 
libassuan_2.5.3.bb} (88%)

diff --git a/meta/recipes-support/libassuan/libassuan_2.5.2.bb 
b/meta/recipes-support/libassuan/libassuan_2.5.3.bb
similarity index 88%
rename from meta/recipes-support/libassuan/libassuan_2.5.2.bb
rename to meta/recipes-support/libassuan/libassuan_2.5.3.bb
index 515d60f7f65..6fb3d2f3a47 100644
--- a/meta/recipes-support/libassuan/libassuan_2.5.2.bb
+++ b/meta/recipes-support/libassuan/libassuan_2.5.3.bb
@@ -17,8 +17,8 @@ SRC_URI = "${GNUPG_MIRROR}/libassuan/libassuan-${PV}.tar.bz2 \
file://libassuan-add-pkgconfig-support.patch \
   "
 
-SRC_URI[md5sum] = "4d0d5738936bd8f4f0287e1dd80432b6"
-SRC_URI[sha256sum] = 
"986b1bf277e375f7a960450fbb8ffbd45294d06598916ad4ebf79aee0cb788e7"
+SRC_URI[md5sum] = "226c504ea78a232224bf3b6846b3adb9"
+SRC_URI[sha256sum] = 
"91bcb0403866b4e7c4bc1cc52ed4c364a9b5414b3994f718c70303f7f765e702"
 
 BINCONFIG = "${bindir}/libassuan-config"
 
-- 
2.20.1

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


[OE-core] [PATCH 13/14] xkeyboard-config: upgrade 2.25 -> 2.26

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 .../{xkeyboard-config_2.25.bb => xkeyboard-config_2.26.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-lib/{xkeyboard-config_2.25.bb => 
xkeyboard-config_2.26.bb} (87%)

diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.25.bb 
b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.26.bb
similarity index 87%
rename from meta/recipes-graphics/xorg-lib/xkeyboard-config_2.25.bb
rename to meta/recipes-graphics/xorg-lib/xkeyboard-config_2.26.bb
index b67dfa566ba..5c232884561 100644
--- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.25.bb
+++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.26.bb
@@ -14,8 +14,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=0e7f21ca7db975c63467d2e7624a12f9"
 
 SRC_URI = 
"${XORG_MIRROR}/individual/data/xkeyboard-config/${BPN}-${PV}.tar.bz2"
 
-SRC_URI[md5sum] = "a0238f95118f39f5f685dd28fbd9d24f"
-SRC_URI[sha256sum] = 
"fec6c25a8d3931bd9afca49a1653b0fa222c85610502d7b77699bb61262934b2"
+SRC_URI[md5sum] = "e2e980629bfeb9f40a7d44488b18ba12"
+SRC_URI[sha256sum] = 
"393718c7460cd06c4e8cb819d943ca54812ea476f32714c4d8975c77031a038e"
 
 SECTION = "x11/libs"
 DEPENDS = "intltool-native util-macros libxslt-native"
-- 
2.20.1

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


[OE-core] [PATCH 14/14] gnu-config: upgrade to 20181128 revision

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/gnu-config/gnu-config_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/gnu-config/gnu-config_git.bb 
b/meta/recipes-devtools/gnu-config/gnu-config_git.bb
index 4745f19ceee..e597ebedbc1 100644
--- a/meta/recipes-devtools/gnu-config/gnu-config_git.bb
+++ b/meta/recipes-devtools/gnu-config/gnu-config_git.bb
@@ -8,8 +8,8 @@ DEPENDS_class-native = "hostperl-runtime-native"
 
 INHIBIT_DEFAULT_DEPS = "1"
 
-SRCREV = "30d53fc428ea42af9d6f4d355db0022e3918a824"
-PV = "20180713+git${SRCPV}"
+SRCREV = "058639be227bbe8f03cc39f79f7ce84918012143"
+PV = "20181128+git${SRCPV}"
 
 SRC_URI = "git://git.savannah.gnu.org/config.git \
file://gnu-configize.in"
-- 
2.20.1

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


[OE-core] [PATCH 11/14] sbc: upgrade 1.3 -> 1.4

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 meta/recipes-multimedia/sbc/{sbc_1.3.bb => sbc_1.4.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-multimedia/sbc/{sbc_1.3.bb => sbc_1.4.bb} (84%)

diff --git a/meta/recipes-multimedia/sbc/sbc_1.3.bb 
b/meta/recipes-multimedia/sbc/sbc_1.4.bb
similarity index 84%
rename from meta/recipes-multimedia/sbc/sbc_1.3.bb
rename to meta/recipes-multimedia/sbc/sbc_1.4.bb
index 2bb895de980..674d77ef485 100644
--- a/meta/recipes-multimedia/sbc/sbc_1.3.bb
+++ b/meta/recipes-multimedia/sbc/sbc_1.4.bb
@@ -14,8 +14,8 @@ DEPENDS = "libsndfile1"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/${BP}.tar.xz"
 
-SRC_URI[md5sum] = "2d8b7841f2c11ab287718d562f2b981c"
-SRC_URI[sha256sum] = 
"e61022cf576f14190241e7071753fdacdce5d1dea89ffd704110fc50be689309"
+SRC_URI[md5sum] = "800fb0908899baa48dc216d8e156cc05"
+SRC_URI[sha256sum] = 
"518bf46e6bb3dc808a95e1eabad26fdebe8a099c1e781c27ed7fca6c2f4a54c9"
 
 inherit autotools pkgconfig
 
-- 
2.20.1

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


[OE-core] [PATCH 12/14] xf86-input-libinput: upgrade 0.28.1 -> 0.28.2

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 ...input-libinput_0.28.1.bb => xf86-input-libinput_0.28.2.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-driver/{xf86-input-libinput_0.28.1.bb => 
xf86-input-libinput_0.28.2.bb} (63%)

diff --git a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.1.bb 
b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.2.bb
similarity index 63%
rename from meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.1.bb
rename to meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.2.bb
index 0b77546d6f9..19123e06c91 100644
--- a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.1.bb
+++ b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.2.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=5e6b20ea2ef94a998145f0ea3f788ee0"
 
 DEPENDS += "libinput"
 
-SRC_URI[md5sum] = "9d2fb3d6b452d568a275908b856de0e2"
-SRC_URI[sha256sum] = 
"9ada448e076c0078a84b48e5298fa8ce317565f9b342b74c20429214a707d98b"
+SRC_URI[md5sum] = "b7548bc1d7e82d189205794ff86307af"
+SRC_URI[sha256sum] = 
"b8b346962c6b62b8069928c29c0db83b6f544863bf2fc6830f324de841de2820"
 
 FILES_${PN} += "${datadir}/X11/xorg.conf.d"
-- 
2.20.1

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


[OE-core] [PATCH 09/14] pkgconf: upgrade 1.5.3 -> 1.6.0

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 .../pkgconf/{pkgconf_1.5.3.bb => pkgconf_1.6.0.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/pkgconf/{pkgconf_1.5.3.bb => pkgconf_1.6.0.bb} 
(95%)

diff --git a/meta/recipes-devtools/pkgconf/pkgconf_1.5.3.bb 
b/meta/recipes-devtools/pkgconf/pkgconf_1.6.0.bb
similarity index 95%
rename from meta/recipes-devtools/pkgconf/pkgconf_1.5.3.bb
rename to meta/recipes-devtools/pkgconf/pkgconf_1.6.0.bb
index 415478d5cf9..1452875f5d8 100644
--- a/meta/recipes-devtools/pkgconf/pkgconf_1.5.3.bb
+++ b/meta/recipes-devtools/pkgconf/pkgconf_1.6.0.bb
@@ -21,8 +21,8 @@ SRC_URI = "\
 file://pkg-config-native.in \
 file://pkg-config-esdk.in \
 "
-SRC_URI[md5sum] = "c21743bca14c882c0f282746168a5edc"
-SRC_URI[sha256sum] = 
"d3468308553c94389dadfd10c4d1067269052b5364276a9d24a643c88485f715"
+SRC_URI[md5sum] = "0c93492d7f001e5175b0347b5472e86d"
+SRC_URI[sha256sum] = 
"6135a3abb576672ba54a899860442ba185063f0f90dae5892f64f7bae8e1ece5"
 
 inherit autotools
 
-- 
2.20.1

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


[OE-core] [PATCH 03/14] gnupg: upgrade 2.2.12 -> 2.2.13

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 ...configure.ac-use-a-custom-value-for-the-location-of-.patch | 2 +-
 meta/recipes-support/gnupg/gnupg/relocate.patch   | 2 +-
 .../gnupg/{gnupg_2.2.12.bb => gnupg_2.2.13.bb}| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-support/gnupg/{gnupg_2.2.12.bb => gnupg_2.2.13.bb} (93%)

diff --git 
a/meta/recipes-support/gnupg/gnupg/0001-configure.ac-use-a-custom-value-for-the-location-of-.patch
 
b/meta/recipes-support/gnupg/gnupg/0001-configure.ac-use-a-custom-value-for-the-location-of-.patch
index c43ecdf8616..2c204e02452 100644
--- 
a/meta/recipes-support/gnupg/gnupg/0001-configure.ac-use-a-custom-value-for-the-location-of-.patch
+++ 
b/meta/recipes-support/gnupg/gnupg/0001-configure.ac-use-a-custom-value-for-the-location-of-.patch
@@ -1,4 +1,4 @@
-From c69c3a49f3295179c247db5ceb3ef8952928a724 Mon Sep 17 00:00:00 2001
+From e7ad11cf54475e455fdb84d118e4782961698567 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Mon, 22 Jan 2018 18:00:21 +0200
 Subject: [PATCH] configure.ac: use a custom value for the location of
diff --git a/meta/recipes-support/gnupg/gnupg/relocate.patch 
b/meta/recipes-support/gnupg/gnupg/relocate.patch
index 1a5ea4aa2b7..e5a82aa76d5 100644
--- a/meta/recipes-support/gnupg/gnupg/relocate.patch
+++ b/meta/recipes-support/gnupg/gnupg/relocate.patch
@@ -1,4 +1,4 @@
-From 6d31b04d7a75f1d73c3518bf043b5b0a2dc40cb1 Mon Sep 17 00:00:00 2001
+From 59c077f32e81190955910cae02599c7a3edfa7fb Mon Sep 17 00:00:00 2001
 From: Ross Burton 
 Date: Wed, 19 Sep 2018 14:44:40 +0100
 Subject: [PATCH] Allow the environment to override where gnupg looks for its
diff --git a/meta/recipes-support/gnupg/gnupg_2.2.12.bb 
b/meta/recipes-support/gnupg/gnupg_2.2.13.bb
similarity index 93%
rename from meta/recipes-support/gnupg/gnupg_2.2.12.bb
rename to meta/recipes-support/gnupg/gnupg_2.2.13.bb
index a02c66a0c87..3ce2a38c0eb 100644
--- a/meta/recipes-support/gnupg/gnupg_2.2.12.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.2.13.bb
@@ -20,8 +20,8 @@ SRC_URI_append_class-native = " 
file://0001-configure.ac-use-a-custom-value-for-
 file://relocate.patch"
 
 
-SRC_URI[md5sum] = "421b17028878b253c5acfef056bc6141"
-SRC_URI[sha256sum] = 
"db030f8b4c98640e91300d36d516f1f4f8fe09514a94ea9fc7411ee1a34082cb"
+SRC_URI[md5sum] = "563b959d0c3856e34526e9ca51c80d7b"
+SRC_URI[sha256sum] = 
"76c787a955f9e6e0ead47c9be700bfb9d454f955a7b7c7e697aa719bac7b11d8"
 
 EXTRA_OECONF = "--disable-ldap \
--disable-ccid-driver \
-- 
2.20.1

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


[OE-core] [PATCH 02/14] curl: upgrade 7.63.0 -> 7.64.0

2019-02-21 Thread Richard Purdie
The license checksum changed as the copyright years changed.

Fixes:
 - CVE-2018-16890: NTLM type-2 out-of-bounds buffer read
 - CVE-2019-3822: NTLMv2 type-3 header stack buffer overflow
 - CVE-2019-3823: SMTP end-of-response out-of-bounds read

Signed-off-by: Richard Purdie 
---
 .../recipes-support/curl/{curl_7.63.0.bb => curl_7.64.0.bb} | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-support/curl/{curl_7.63.0.bb => curl_7.64.0.bb} (93%)

diff --git a/meta/recipes-support/curl/curl_7.63.0.bb 
b/meta/recipes-support/curl/curl_7.64.0.bb
similarity index 93%
rename from meta/recipes-support/curl/curl_7.63.0.bb
rename to meta/recipes-support/curl/curl_7.64.0.bb
index f7557a2f46d..a1b5e7d5797 100644
--- a/meta/recipes-support/curl/curl_7.63.0.bb
+++ b/meta/recipes-support/curl/curl_7.64.0.bb
@@ -3,14 +3,14 @@ HOMEPAGE = "http://curl.haxx.se/;
 BUGTRACKER = "http://curl.haxx.se/mail/list.cgi?list=curl-tracker;
 SECTION = "console/network"
 LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://COPYING;md5=ef889a37a5a874490ac7ce116396f29a"
+LIC_FILES_CHKSUM = "file://COPYING;md5=be5d9e1419c4363f4b32037a2d3b7ffa"
 
 SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
 "
 
-SRC_URI[md5sum] = "0a6c1e993bd5102bc52fc89900542644"
-SRC_URI[sha256sum] = 
"9bab7ed4ecff77020a312d84cc5fb7eb02d58419d218f267477a724a17fd8dd8"
+SRC_URI[md5sum] = "d0bcc586873cfef08b4b9594e5395a33"
+SRC_URI[sha256sum] = 
"d573ba1c2d1cf9d8533fadcce480d778417964e8d04ccddcc76e591d544cf2eb"
 
 CVE_PRODUCT = "curl libcurl"
 inherit autotools pkgconfig binconfig multilib_header
-- 
2.20.1

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


[OE-core] [PATCH 01/14] blktool: upgrade 4-7 -> 4-7.1

2019-02-21 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 .../blktool/{blktool_4-7.bb => blktool_4-7.1.bb}| 2 ++
 1 file changed, 2 insertions(+)
 rename meta/recipes-extended/blktool/{blktool_4-7.bb => blktool_4-7.1.bb} (90%)

diff --git a/meta/recipes-extended/blktool/blktool_4-7.bb 
b/meta/recipes-extended/blktool/blktool_4-7.1.bb
similarity index 90%
rename from meta/recipes-extended/blktool/blktool_4-7.bb
rename to meta/recipes-extended/blktool/blktool_4-7.1.bb
index 0e6f7ee6df1..468925e329b 100644
--- a/meta/recipes-extended/blktool/blktool_4-7.bb
+++ b/meta/recipes-extended/blktool/blktool_4-7.1.bb
@@ -9,6 +9,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
 
 DEPENDS = "glib-2.0"
 
+SRC_URI[sha256sum] = 
"b1e6d5912546d2a4b704ec65c2b9664aa3b4663e7d800e06803330335a2cb764"
+SRC_URI[md5sum] = "62edc09c9908107e69391c87f4f3fd40"
 SRC_URI = 
"http://snapshot.debian.org/archive/debian/20160728T043443Z/pool/main/b/${BPN}/${BPN}_4.orig.tar.gz;name=tarball
 \
file://0001-fix-typos-in-manpage.patch \
file://0002-fix-string-error.patch \
-- 
2.20.1

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


Re: [OE-core] wic creates ext4 images that read really slow in u-boot

2019-02-21 Thread Burton, Ross
On Thu, 21 Feb 2019 at 10:17, Mike Looijmans  wrote:
> That'd be best. One would expect that creating a filesystem "offline" would
> yield something optimal in terms of the way files are allocated, since
> everything about all files is already known when it's written.

But because we don't run image generation as root in a loopback mount,
we're limited to how clever e2fsprogs's debugfs is, *not* the kernel
driver.

Just a few weeks ago I fixed a bug in debugfs where it was only
writing the first 2^31 bits of a file...

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


Re: [OE-core] wic creates ext4 images that read really slow in u-boot

2019-02-21 Thread Mike Looijmans
On 19-02-19 21:45, Leon Woestenberg wrote:
> Hello all,
> 
> On Tue, Feb 19, 2019 at 8:28 PM Andre McCurdy  wrote:
>> On Tue, Feb 19, 2019 at 9:13 AM Leon Woestenberg  wrote:
>>>
>>> Hello Mike,
>>>
>>> sounds familiar.
>>>
>>> On Tue, 19 Feb 2019 at 17:55, Mike Looijmans  
>>> wrote:

 Took me a while to figure out why my board took 90 seconds to boot 
 suddenly.
 The issue turned out to be the ext4 partition created by wic.
>>>
>>> I suspect it's not WIC's fault.

 ZynqMP> load mmc 0:2 0x10 /lib/firmware/fpga.bin
 19311092 bytes read in 85529 ms (219.7 KiB/s)

 Now if I boot the board rename and copy that file onto itself, then it's
 suddenly normal again when I reboot the board:

 ZynqMP> load mmc 0:2 0x1
 I'm not knowledgeable on ext4, so any ideas what's being passed onto the 
 image
 creation tool that causes this?
>>>
>>> I suspect your version of U-Boot does not handle files spread across 
>>> multiple filesystems (allocation) extends efficiently.
>>>
>>> Copying the file makes the copy being layed out in one extend probably.
>>
>>
>> If WIC is generating filesystem images from scratch there's no excuse for 
>> files to be unnecessarily fragmented.
>>
>> Even if some of all of the boot time can be recovered by a patch to u-boot 
>> that won't help systems which have already been deployed and don't have a 
>> way to update the bootloader.
>>
> I am not sure if "fragmented" is the right term in terms of filesystem
> details. Filesystem allocation extents (not "extends" as I mistyped
> earlier) are different from heavy file fragmentation. However, I agree
> things can be made more optimal.
> 
> So, with adding the above, there are *two* issues at play here:
> 1) Most/older versions of U-Boot not able to efficiently load files
> from ext4 filesystems, that cross multiple extents. I am aware of two
> fixes, see below.
> 2) WIC uses mkext4fs in such a way that files can cross multiple
> (allocation) extents. This is sub-optimal and know to cause issues
> with many U-Boot versions (deployed on existing systems in the field).
> The problems shows "randomly" with large files being deployed to the
> ext4 filesystem. We (OE/Yocto) may want to fix this.

That'd be best. One would expect that creating a filesystem "offline" would 
yield something optimal in terms of the way files are allocated, since 
everything about all files is already known when it's written.

My current workaround is to just mount the device and unpack the rootfs tar 
onto that, which yields a filesystem that u-boot can read at normal speed.


>>> I am aware of two fixes for U-Boot. I will look them up, and reply again to 
>>> this thread.
> 
> Google for these two commits. I cherry-picked the first one for my
> project and can confirm it brings back the desired performance. (Still
> assuming this is the identical cause as for TO/Mike.)
> 
> commit 855b8e4f9f255415a7753819e392e4b5d984f35c
> Author: Matt Madison 
> Date:   Sat Aug 19 08:46:46 2017 -0700
> 
>  ext4: cache extent blocks during file reads
> 
>  A simpler and less-efficient approach to solving
>  the problem with extent index blocks than what
>  was in fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5,
>  but one that does not break write operations.
> 
>  Signed-off-by: Matt Madison 

I'll give it a try...

You mentioned "two" commits?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [thud][PATCH] ghostscript: Fix CVE-2019-6116

2019-02-21 Thread Ovidiu Panait
It was discovered that the ghostscript /invalidaccess checks fail under
certain conditions. An attacker could possibly exploit this to bypass
the -dSAFER protection and, for example, execute arbitrary shell commands
via a specially crafted PostScript document.

Reference:
https://www.openwall.com/lists/oss-security/2019/01/23/5

Upstream patches:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=13b0a36f8181db66a91bcc8cea139998b53a8996
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2db98f9c66135601efb103d8db7d020a672308db
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=99f13091a3f309bdc95d275ea9fec10bb9f42d9a
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=59d8f4deef90c1598ff50616519d5576756b4495
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2768d1a6dddb83f5c061207a7ed2813999c1b5c9
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=49c8092da88ef6bb0aa281fe294ae0925a44b5b9
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2ff600a3c4fc169e7c6c1e83874a6bf63a6fb42b

Signed-off-by: Ovidiu Panait 
---
 .../ghostscript/CVE-2019-6116-0001.patch  | 177 ++
 .../ghostscript/CVE-2019-6116-0002.patch  | 442 +
 .../ghostscript/CVE-2019-6116-0003.patch  |  32 +
 .../ghostscript/CVE-2019-6116-0004.patch  | 136 
 .../ghostscript/CVE-2019-6116-0005.patch  | 250 
 .../ghostscript/CVE-2019-6116-0006.patch  | 596 ++
 .../ghostscript/CVE-2019-6116-0007.patch  | 346 ++
 .../ghostscript/ghostscript_9.26.bb   |   7 +
 8 files changed, 1986 insertions(+)
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0001.patch
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0002.patch
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0003.patch
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0004.patch
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0005.patch
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0006.patch
 create mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0007.patch

diff --git 
a/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0001.patch 
b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0001.patch
new file mode 100644
index 00..b2c1ade4be
--- /dev/null
+++ b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0001.patch
@@ -0,0 +1,177 @@
+From c8c77690199b677f70093824382f0881e643e17b Mon Sep 17 00:00:00 2001
+From: Chris Liddell 
+Date: Wed, 5 Dec 2018 12:22:13 +
+Subject: [PATCH 1/7] Sanitize op stack for error conditions
+
+We save the stacks to an array and store the array for the error handler to
+access.
+
+For SAFER, we traverse the array, and deep copy any op arrays (procedures). As
+we make these copies, we check for operators that do *not* exist in systemdict,
+when we find one, we replace the operator with a name object (of the form
+"/--opname--").
+
+CVE: CVE-2019-6116
+Upstream-Status: Backport [git://git.ghostscript.com/ghostpdl.git]
+
+Signed-off-by: Ovidiu Panait 
+---
+ psi/int.mak  |  3 +-
+ psi/interp.c |  8 ++
+ psi/istack.c | 78 
+ psi/istack.h |  3 ++
+ 4 files changed, 91 insertions(+), 1 deletion(-)
+
+diff --git a/psi/int.mak b/psi/int.mak
+index 6ab5bf0..6b349cb 100644
+--- a/psi/int.mak
 b/psi/int.mak
+@@ -204,7 +204,8 @@ $(PSOBJ)iparam.$(OBJ) : $(PSSRC)iparam.c $(GH)\
+ $(PSOBJ)istack.$(OBJ) : $(PSSRC)istack.c $(GH) $(memory__h)\
+  $(ierrors_h) $(gsstruct_h) $(gsutil_h)\
+  $(ialloc_h) $(istack_h) $(istkparm_h) $(istruct_h) $(iutil_h) $(ivmspace_h)\
+- $(store_h) $(INT_MAK) $(MAKEDIRS)
++ $(store_h) $(icstate_h) $(iname_h) $(dstack_h) $(idict_h) \
++ $(INT_MAK) $(MAKEDIRS)
+   $(PSCC) $(PSO_)istack.$(OBJ) $(C_) $(PSSRC)istack.c
+ 
+ $(PSOBJ)iutil.$(OBJ) : $(PSSRC)iutil.c $(GH) $(math__h) $(memory__h) 
$(string__h)\
+diff --git a/psi/interp.c b/psi/interp.c
+index 6dc0dda..aa5779c 100644
+--- a/psi/interp.c
 b/psi/interp.c
+@@ -761,6 +761,7 @@ copy_stack(i_ctx_t *i_ctx_p, const ref_stack_t * pstack, 
int skip, ref * arr)
+ uint size = ref_stack_count(pstack) - skip;
+ uint save_space = ialloc_space(idmemory);
+ int code, i;
++ref *safety, *safe;
+ 
+ if (size > 65535)
+ size = 65535;
+@@ -778,6 +779,13 @@ copy_stack(i_ctx_t *i_ctx_p, const ref_stack_t * pstack, 
int skip, ref * arr)
+ make_null(>value.refs[i]);
+ }
+ }
++if (pstack == _stack && dict_find_string(systemdict, "SAFETY", ) 
> 0 &&
++dict_find_string(safety, "safe", ) > 0 && r_has_type(safe, 
t_boolean) &&
++safe->value.boolval == true) {
++code = ref_stack_array_sanitize(i_ctx_p, arr, arr);
++if (code < 0)
++return code;
++}
+ 

Re: [OE-core] wic creates ext4 images that read really slow in u-boot

2019-02-21 Thread Mike Looijmans
>>> I am aware of two fixes for U-Boot. I will look them up, and reply again to 
>>> this thread.

Browsing through u-boot commits, I found this gem that's disabled by default:

CONFIG_BLOCK_CACHE=y

The commit is this one:

commit e40cf34a29f1b248643731a11fb1c6f0520d016c
Author: Eric Nelson 
Date:   Mon Mar 28 10:05:44 2016 -0700

 drivers: block: add block device cache

 Add a block device cache to speed up repeated reads of block devices by
 various filesystems.

 This small amount of cache can dramatically speed up filesystem
 operations by skipping repeated reads of common areas of a block
 device (typically directory structures).

 This has shown to have some benefit on FAT filesystem operations of
 loading a kernel and RAM disk, but more dramatic benefits on ext4
 filesystems when the kernel and/or RAM disk are spread across
 multiple extent header structures as described in commit fc0fc50.
...

I'll be giving that a test drive soon...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 2/2] kernel-fitimage.bbclass: Introduce a way to provide external dtb

2019-02-21 Thread Richard Purdie
On Thu, 2019-02-21 at 03:53 +, Manjukumar Harthikote Matha wrote:
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> > On Tue, 2019-02-19 at 19:34 +, Manjukumar Harthikote Matha
> > 
> > > > PREFERRED_PROVIDER_virtual/dtb = "devicetree"
> > > > 
> > > 
> > > Yes, I should have added this in the commit message. I will
> > > update it
> > > and re-send V2
> > 
> > What may also help a lot here would be some tests. This is
> > currently a blackhole in
> > the tests :(
> > 
> Are there examples of having tests only for bbclass in OE-Core? 

There are. See meta/lib/oeqa/selftest/cases/wic.py

I appreciate wic is a tool, not a class but the examples there should
help. You can trigger them with oe-selftest -r wic.

Another example which is a bbclass is selftest/cases/archiver.py which
does use a class inherit.

> We need a recipe or create-one to inherit this class and probably add
> that as a testcase. 
> I am not sure how to proceed, any example would help to implement the
> same

See above, they show how to add small config fragments. If you do need
a full recipe, then the meta-selftest layer of OE-Core should be able
to help too.

If you have any other questions or run into issues please do ask!

Cheers,

Richard



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


[OE-core] [PATCH] lighttpd: Use the upstream lighttpd.service

2019-02-21 Thread Adrian Bunk
We shipped an old version that was missing several fixes.

A minor incompatibility is that this moves
/etc/lighttpd.conf -> /etc/lighttpd/lighttpd.conf

Signed-off-by: Adrian Bunk 
---
 meta/recipes-extended/lighttpd/lighttpd/lighttpd |  2 +-
 meta/recipes-extended/lighttpd/lighttpd/lighttpd.service | 12 
 meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb|  9 -
 3 files changed, 5 insertions(+), 18 deletions(-)
 delete mode 100644 meta/recipes-extended/lighttpd/lighttpd/lighttpd.service

diff --git a/meta/recipes-extended/lighttpd/lighttpd/lighttpd 
b/meta/recipes-extended/lighttpd/lighttpd/lighttpd
index bf89a60b7d..82fbaa523b 100644
--- a/meta/recipes-extended/lighttpd/lighttpd/lighttpd
+++ b/meta/recipes-extended/lighttpd/lighttpd/lighttpd
@@ -4,7 +4,7 @@ PATH=/sbin:/bin:/usr/sbin:/usr/bin
 DAEMON=/usr/sbin/lighttpd
 NAME=lighttpd
 DESC="Lighttpd Web Server"
-OPTS="-f /etc/lighttpd.conf"
+OPTS="-f /etc/lighttpd/lighttpd.conf"
 
 case "$1" in
   start)
diff --git a/meta/recipes-extended/lighttpd/lighttpd/lighttpd.service 
b/meta/recipes-extended/lighttpd/lighttpd/lighttpd.service
deleted file mode 100644
index 66a907aa17..00
--- a/meta/recipes-extended/lighttpd/lighttpd/lighttpd.service
+++ /dev/null
@@ -1,12 +0,0 @@
-[Unit]
-Description=Lightning Fast Webserver With Light System Requirements
-After=network.target
-
-[Service]
-ExecStartPre=@SBINDIR@/lighttpd -t -f @SYSCONFDIR@/lighttpd.conf
-ExecStart=@SBINDIR@/lighttpd -D -f @SYSCONFDIR@/lighttpd.conf
-ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID
-
-[Install]
-WantedBy=multi-user.target
-
diff --git a/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb 
b/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb
index a58faa17be..a0b350f358 100644
--- a/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb
+++ b/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb
@@ -16,7 +16,6 @@ SRC_URI = 
"http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-${PV}.t
 file://index.html.lighttpd \
 file://lighttpd.conf \
 file://lighttpd \
-file://lighttpd.service \
 file://0001-Use-pkg-config-for-pcre-dependency-instead-of-config.patch 
\
 "
 
@@ -57,13 +56,13 @@ INITSCRIPT_PARAMS = "defaults 70"
 SYSTEMD_SERVICE_${PN} = "lighttpd.service"
 
 do_install_append() {
-   install -d ${D}${sysconfdir}/init.d ${D}${sysconfdir}/lighttpd.d 
${D}/www/pages/dav
+   install -d ${D}${sysconfdir}/init.d ${D}${sysconfdir}/lighttpd 
${D}${sysconfdir}/lighttpd.d ${D}/www/pages/dav
install -m 0755 ${WORKDIR}/lighttpd ${D}${sysconfdir}/init.d
-   install -m 0644 ${WORKDIR}/lighttpd.conf ${D}${sysconfdir}
+   install -m 0644 ${WORKDIR}/lighttpd.conf ${D}${sysconfdir}/lighttpd
install -m 0644 ${WORKDIR}/index.html.lighttpd ${D}/www/pages/index.html
 
install -d ${D}${systemd_unitdir}/system
-   install -m 0644 ${WORKDIR}/lighttpd.service 
${D}${systemd_unitdir}/system
+   install -m 0644 ${S}/doc/systemd/lighttpd.service 
${D}${systemd_unitdir}/system
sed -i -e 's,@SBINDIR@,${sbindir},g' \
-e 's,@SYSCONFDIR@,${sysconfdir},g' \
-e 's,@BASE_BINDIR@,${base_bindir},g' \
@@ -75,7 +74,7 @@ do_install_append() {
 
 FILES_${PN} += "${sysconfdir} /www"
 
-CONFFILES_${PN} = "${sysconfdir}/lighttpd.conf"
+CONFFILES_${PN} = "${sysconfdir}/lighttpd/lighttpd.conf"
 
 PACKAGES_DYNAMIC += "^lighttpd-module-.*"
 
-- 
2.11.0

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


[OE-core] [PATCH] busybox: enable CONFIG_FLOAT_DURATION

2019-02-21 Thread Adrian Bunk
The 1.29.3 -> 1.30.1 upgrade lost support for sleep with
float values (e.g. "sleep 0.1") since this replacement for
CONFIG_FEATURE_FLOAT_SLEEP (enabled in thud) was missing.

Signed-off-by: Adrian Bunk 
---
 meta/recipes-core/busybox/busybox/defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/busybox/busybox/defconfig 
b/meta/recipes-core/busybox/busybox/defconfig
index a209eea5a1..493db28e86 100644
--- a/meta/recipes-core/busybox/busybox/defconfig
+++ b/meta/recipes-core/busybox/busybox/defconfig
@@ -83,7 +83,7 @@ CONFIG_NO_DEBUG_LIB=y
 # Library Tuning
 #
 # CONFIG_FEATURE_USE_BSS_TAIL is not set
-# CONFIG_FLOAT_DURATION is not set
+CONFIG_FLOAT_DURATION=y
 CONFIG_FEATURE_RTMINMAX=y
 # CONFIG_FEATURE_RTMINMAX_USE_LIBC_DEFINITIONS is not set
 CONFIG_FEATURE_BUFFERS_USE_MALLOC=y
-- 
2.11.0

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