Re: [OE-core] [PATCH v2] pulseaudio: define -mfloat-abi=softfp for CC on armv5

2021-01-05 Thread Tanu Kaskinen
On Tue, 2021-01-05 at 12:37 +, Richard Purdie wrote:
> On Tue, 2021-01-05 at 11:37 +0800, Yu, Mingli wrote:
> From: Mingli Yu 
> 
> After pulseaudio upgrades from 13.0 to 14.0, it also switches from
> autotools
> to meson. In autotools, there is --disable-neon-opt option for
> disabling NEON
> optimizations, but there is no counterpart in meson.
> 
> And the meson build system adds -mfpu=neon at the end of the compiler
> command
> line which overrids any earlier -mfpu options and result below build
> failure
> on armv5:
> 
> > /prj/tmp-glibc/work/armv5e-wrs-linux-gnueabi/pulseaudio/14.0-
> > r0/recipe-sysroot-native/usr/lib/arm-wrs-linux-gnueabi/gcc/arm-wrs-
> > linux-gnueabi/10.2.0/include/arm_neon.h:31:2: error: #error "NEON
> > intrinsics not available with the soft-float ABI.  Please use -
> > mfloat-abi=softfp or -mfloat-abi=hard"
> >  31 | #error "NEON intrinsics not available with the soft-float ABI. 
> > Please use -mfloat-abi=softfp or -mfloat-abi=hard"
>   |  ^
> > ../pulseaudio-14.0/src/pulsecore/mix_neon.c: In function
> > 'pa_mix_ch2_s16ne_neon':
> > ../pulseaudio-14.0/src/pulsecore/mix_neon.c:38:9: error: unknown type
> > name 'int32x4_t'; did you mean 'int32_t'?
> >   38 | int32x4_t sum0, sum1;
> 
> Define -mfloat-abi=softfp for CC on armv5 to fix the above issue.
> 
> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> index e40b8c1c40..761e4f74dc 100644
> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> @@ -123,6 +123,11 @@ PACKAGECONFIG[ipv6] = "-Dipv6=true,-Dipv6=false,"
>  PACKAGECONFIG[manpages] = "-Dman=true,-Dman=false,"
>  
>  export TARGET_PFPU = "${TARGET_FPU}"
> +# workaround build failure on qemuarmv5 as the neon optimizations is
> +# enabled by default and no option to disable neon with meson build
> +# system
> +CC_append_armv5 = " -mfloat-abi=softfp"
> +export CC
>  
>  set_cfg_value () {
> sed -i -e "s/\(; *\)\?$2 =.*/$2 = $3/" "$1"
> 
> I really don't want to add things like this to the recipe, I think it
> will interfere with other parts of the compilation. In many ways I'd
> prefer an option added to meson. Do we know what upstream are thinking
> in relation to this?

I think Meson should be fixed, but it may be necessary to add a build
option to PulseAudio to disable the neon code while waiting for Meson
to get fixed.

I now filed a bug for Meson: 
https://github.com/mesonbuild/meson/issues/8156

and another for PulseAudio: 
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1088

so at least the relevant projects know about the issue now. I may work
on fixing these myself if nobody else does, but I don't expect that to
happen quickly.

-- 
Tanu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146410): 
https://lists.openembedded.org/g/openembedded-core/message/146410
Mute This Topic: https://lists.openembedded.org/mt/79443916/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH] pulseaudio: fix client.conf location

2020-12-21 Thread Tanu Kaskinen
The location of the generated client.conf changed when switching from
Autotools to Meson.

Fixes this error when enabling autospawn-for-root:

sed: can't read src/client.conf: No such file or directory

Signed-off-by: Tanu Kaskinen 
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index cf4be7ed40..e40b8c1c40 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -133,7 +133,7 @@ set_cfg_value () {
 
 do_compile_append () {
if ${@bb.utils.contains('PACKAGECONFIG', 'autospawn-for-root', 'true', 
'false', d)}; then
-   set_cfg_value src/client.conf allow-autospawn-for-root yes
+   set_cfg_value src/pulse/client.conf allow-autospawn-for-root yes
fi
 }
 
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146020): 
https://lists.openembedded.org/g/openembedded-core/message/146020
Mute This Topic: https://lists.openembedded.org/mt/79125572/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH] pulseaudio: Fix build with clang for non-x86 target

2020-12-21 Thread Tanu Kaskinen
On Sun, 2020-12-20 at 08:05 -0800, Khem Raj wrote:
> Signed-off-by: Khem Raj 
> Cc: Tanu Kaskinen 
> ---
>  .../0001-meson-Check-for-__get_cpuid.patch| 82 +++
>  .../pulseaudio/pulseaudio_14.0.bb |  1 +
>  2 files changed, 83 insertions(+)
>  create mode 100644 
> meta/recipes-multimedia/pulseaudio/pulseaudio/0001-meson-Check-for-__get_cpuid.patch
> 
> diff --git 
> a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-meson-Check-for-__get_cpuid.patch
>  
> b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-meson-Check-for-__get_cpuid.patch
> new file mode 100644
> index 00..c9d8abcbf2
> --- /dev/null
> +++ 
> b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-meson-Check-for-__get_cpuid.patch
> @@ -0,0 +1,82 @@
> +From 9d0dc8aedd08d77797f90fa6075a59613f18bf0d Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Sun, 20 Dec 2020 07:56:07 -0800
> +Subject: [PATCH] meson: Check for __get_cpuid
> +
> +checking for presence of cpuid.h header alone is not sufficient in some case 
> to use
> +cpuid related functions. e.g. when using clang which is built for
> +multiple targets will have cpuid.h header as part of compiler headers in
> +distribution but one maybe compiling pulseaudion for non-x86 target. The
> +current check in meson succeeds and then compile fails later because
> +cpuid.h is x86-specific header. Therefore checking for symbol that is
> +needed makes this robust, so even if header exist it will try to ensure
> +the given symbol can be used
> +
> +Fixes
> +src/pulsecore/core-util.c:113:
> +| 
> /mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/pulseaudio/14.0-r0/recipe-sysroot-native/usr/lib/clang/11.0.1/include/cpuid.h:11:2:
>  error: this header is for x86 only
> +| #error this header is for x86 only
> +|  ^
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Khem Raj 
> +Cc: Tanu Kaskinen 
> +---
> + meson.build   | 5 -
> + src/pulsecore/core-util.c | 2 +-
> + src/pulsecore/cpu-x86.c   | 2 +-
> + 3 files changed, 6 insertions(+), 3 deletions(-)
> +
> +diff --git a/meson.build b/meson.build
> +index 2589627..5f5127e 100644
> +--- a/meson.build
>  b/meson.build
> +@@ -185,7 +185,6 @@ endif
> + check_headers = [
> +   'arpa/inet.h',
> +   'byteswap.h',
> +-  'cpuid.h',
> +   'dlfcn.h',
> +   'execinfo.h',
> +   'grp.h',
> +@@ -243,6 +242,10 @@ if cc.has_header_symbol('pthread.h', 
> 'PTHREAD_PRIO_INHERIT')
> +   cdata.set('HAVE_PTHREAD_PRIO_INHERIT', 1)
> + endif
> + 
> ++if cc.has_header_symbol('cpuid.h', '__get_cpuid')
> ++  cdata.set('HAVE_GET_CPUID', 1)
> ++endif
> ++
> + # Functions
> + 
> + check_functions = [
> +diff --git a/src/pulsecore/core-util.c b/src/pulsecore/core-util.c
> +index 601b1d1..6f34e7c 100644
> +--- a/src/pulsecore/core-util.c
>  b/src/pulsecore/core-util.c
> +@@ -109,7 +109,7 @@
> + #include 
> + #endif
> + 
> +-#ifdef HAVE_CPUID_H
> ++#ifdef HAVE_GET_CPUID
> + #include 
> + #endif
> + 
> +diff --git a/src/pulsecore/cpu-x86.c b/src/pulsecore/cpu-x86.c
> +index 4e59e14..86595d4 100644
> +--- a/src/pulsecore/cpu-x86.c
>  b/src/pulsecore/cpu-x86.c
> +@@ -24,7 +24,7 @@
> + 
> + #include 
> + 
> +-#ifdef HAVE_CPUID_H
> ++#ifdef HAVE_GET_CPUID

There are more instances of HAVE_CPUID_H in core-util.c and cpu-x86.c,
they all need to be replaced with HAVE_GET_CPUID. Could you update the
patch?

When upstreaming, I think this change needs to be ported to the
Autotools build system too as long as it exists in PulseAudio, but I
can take care of that.

-- 
Tanu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146018): 
https://lists.openembedded.org/g/openembedded-core/message/146018
Mute This Topic: https://lists.openembedded.org/mt/79105751/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH 0/4] pulseaudio: Autotools to Meson

2020-12-21 Thread Tanu Kaskinen
On Mon, 2020-12-21 at 14:03 +0100, Andrey Zhizhikin wrote:
> Hello Tanu,
> 
> On Sun, Dec 20, 2020 at 5:09 PM Khem Raj  wrote:
> > On Sun, Dec 20, 2020 at 6:26 AM Tanu Kaskinen  wrote:
> > > On Sat, 2020-12-19 at 12:36 -0800, Khem Raj wrote:
> > > > On Sat, Dec 19, 2020 at 9:24 AM Khem Raj  wrote:
> > > > > On Thu, Dec 17, 2020 at 11:28 AM Tanu Kaskinen  wrote:
> > > > > > The PulseAudio project plans to drop Autotools support in 15.0, so 
> > > > > > let's
> > > > > > switch to Meson. The first patch removes OE_LT_RPATH_ALLOW, which is
> > > > > > some old cruft that sounds like it has something to do Libtool, so 
> > > > > > it's
> > > > > > perhaps relevant for the goal of dropping Autotools. The next two
> > > > > > patches disable features that aren't available with Meson. The last
> > > > > > patch does the build system switch.
> > > > > > 
> > > > > > Tanu Kaskinen (4):
> > > > > >   pulseaudio: Remove OE_LT_RPATH_ALLOW
> > > > > >   pulseaudio: disable EsounD support
> > > > > >   pulseaudio: disable GConf support
> > > > > >   pulseaudio: switch build system from Autotools to Meson
> 
> I'm seeing a build failure after this upgrade, thought you might
> advise here what could be wrong.
> 
> Following is produced at the end of do_compile taks:
> 
> > sed: can't read src/client.conf: No such file or directory
> > WARNING: exit code 2 from a shell command.
> > 
> ERROR: Task 
> (/development/yocto-master/yocto-build-appliance/meta/recipes-multimedia/pulseaudio/pulseaudio_14.0.bb:do_compile)
> failed with exit code '1'
> 
> Have you experienced the same error, and what can be missing here?

I can reproduce the error when enabling the autospawn-for-root
PACKAGECONFIG. client.conf is generated from client.conf.in, and the
generated file's location has changed. Replacing "src/client.conf" with
"src/pulse/client.conf" in pulseaudio.inc seems to fix this issue.

-- 
Tanu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#146016): 
https://lists.openembedded.org/g/openembedded-core/message/146016
Mute This Topic: https://lists.openembedded.org/mt/79044755/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [PATCH 0/4] pulseaudio: Autotools to Meson

2020-12-20 Thread Tanu Kaskinen
On Sat, 2020-12-19 at 12:36 -0800, Khem Raj wrote:
> On Sat, Dec 19, 2020 at 9:24 AM Khem Raj  wrote:
> > On Thu, Dec 17, 2020 at 11:28 AM Tanu Kaskinen  wrote:
> > > The PulseAudio project plans to drop Autotools support in 15.0, so let's
> > > switch to Meson. The first patch removes OE_LT_RPATH_ALLOW, which is
> > > some old cruft that sounds like it has something to do Libtool, so it's
> > > perhaps relevant for the goal of dropping Autotools. The next two
> > > patches disable features that aren't available with Meson. The last
> > > patch does the build system switch.
> > > 
> > > Tanu Kaskinen (4):
> > >   pulseaudio: Remove OE_LT_RPATH_ALLOW
> > >   pulseaudio: disable EsounD support
> > >   pulseaudio: disable GConf support
> > >   pulseaudio: switch build system from Autotools to Meson
> > 
> > I am seeing build failures with this patch series while using clang
> > for compiler see.
> > 
> > https://errors.yoctoproject.org/Errors/Details/539474/
> > 
> 
> It turns out that new meson checks are a bit different and if
> -Qunused-arguments is used with clang then the test for neon passes
> because its a simple compile time check in meson, So a workaround that
> I have done is to remove using -Qunused-arguments on clang
> cmdline and then it works ok.

Ok, so the Neon check in Meson is somehow too lax if it passes with
-Qunused-arguments. Thanks for the initial debugging! I can look into
the issue, but I can't promise to do it quickly. I see these patches
are in master already - should the last patch be reverted for now? Or
can your workaround be applied to master (or meta-clang, if that's
where clang workarounds belong)?

-- 
Tanu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145998): 
https://lists.openembedded.org/g/openembedded-core/message/145998
Mute This Topic: https://lists.openembedded.org/mt/79044755/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 4/4] pulseaudio: switch build system from Autotools to Meson

2020-12-17 Thread Tanu Kaskinen
Upstream is moving from Autotools to Meson, Autotools support will be
dropped in 15.0.

I dropped some configure options:
 * --enable-tcpwrap=no doesn't (currently) have a counterpart in Meson,
   TCP Wrappers support is always disabled.
 * --disable-esound doesn't have a counterpart in Meson, EsounD support
   is always disabled.
 * --disable-gconf doesn't have a counterpart in Meson, GConf support is
   always disabled.

I backported a patch that implements support for the -Dvalgrind=disabled
option.

I checked with buildhistory what the differences are before and after
this patch (with qemuarm with neon removed from TUNE_FEATURES, all
PACKAGECONFIGs enabled):
 * Obvious differences in DEPENDS: Autotools stuff removed and Meson
   stuff added. There wasn't anything strange here.
 * Packages have superfluous RDEPENDS removed from them. With Autotools
   something caused for example X11 libraries to be added to RDEPENDS of
   packages that don't have anything to do with X11.
 * The pulseaudio-src package had MMX and SSE related files removed and
   Neon related files added. I don't know why the ARM build previously
   had MMX and SSE files included, the addition of Neon files is
   explained by the fact that with Meson the Neon optimizations can't be
   disabled if the compiler supports Neon (see below).
 * libfoo.so symlinks changed to point to libfoo.so.X rather than
   directly to libfoo.so.X.Y.Z. To my understading that's fine, since
   libfoo.so.X is a symlink that points to libfoo.so.X.Y.Z.
 * There were various file size changes, which I didn't investigate.

Previously the recipe disabled ARM Neon optimizations when "neon" was
not in TUNE_FEATURES. That was originally added in commit
4e7b91b5a2613b957b08aefbee1aac28fdd19598 at a time when PulseAudio's
build system didn't check the availability of the arm_neon.h header,
causing compilation errors when the header wasn't available. That issue
was fixed a long time ago, so there was little need for the
TUNE_FEATURES check, although it was still possible to make the build
fail if non-neon -mfpu was passed in CFLAGS, so the TUNE_FEATURES check
still had some theoretical benefit (theoretical, because generally OE
passes -mfpu in CC instead of CFLAGS, so OE's -mfpu option appears very
early in the compiler command line, which doesn't trip up PulseAudio's
current Autotools build system).

With Meson there's no option for disabling Neon optimizations if the
compiler supports Neon. If -mfpu is set in CC or CFLAGS, it's ignored,
because the build system adds -mfpu=neon at the end of the compiler
command line, overriding any earlier -mfpu options. This shouldn't be
a problem, because PulseAudio detects at runtime whether the CPU
supports Neon instructions.

Signed-off-by: Tanu Kaskinen 
---
 .../pulseaudio/pulseaudio.inc | 64 --
 ...-option-for-enabling-disabling-Valgr.patch | 67 +++
 .../pulseaudio/pulseaudio_14.0.bb |  1 +
 3 files changed, 97 insertions(+), 35 deletions(-)
 create mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-build-sys-Add-an-option-for-enabling-disabling-Valgr.patch

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 48759bca62..cf4be7ed40 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -56,49 +56,47 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=0e5cd938de1a7a53ea5adac38cc10c39 \
 
file://src/pulsecore/filter/biquad.h;beginline=1;endline=4;md5=6d46d1365206528a20137355924233c1
 \
 "
 
+# libtool is needed for libltdl, used in module loading.
 DEPENDS = "libatomic-ops libsndfile1 libtool"
 # optional
 DEPENDS += "udev alsa-lib glib-2.0"
 DEPENDS += "speexdsp libxml-parser-perl-native libcap"
 
-inherit autotools bash-completion pkgconfig useradd gettext perlnative systemd 
manpages gsettings
+inherit bash-completion meson pkgconfig useradd gettext perlnative systemd 
manpages gsettings
 
 # *.desktop rules wont be generated during configure and build will fail
 # if using --disable-nls
 USE_NLS = "yes"
 
-EXTRA_OECONF = "\
-   --disable-hal-compat \
-   --disable-orc \
-   --enable-tcpwrap=no \
-   --with-access-group=audio \
-   --disable-openssl \
-   --with-database=simple \
-   --without-zsh-completion-dir \
-   --with-udev-rules-dir=`pkg-config --variable=udevdir 
udev`/rules.d \
-   ac_cv_header_valgrind_memcheck_h=no \
-   --disable-tests \
-   --disable-running-from-build-tree \
-   --disable-esound \
-   --disable-gconf \
+EXTRA_OEMESON = "\
+   -Dhal-compat=false \
+   -Dorc=disabled \
+   -Daccess_group=audio \

[OE-core] [PATCH 3/4] pulseaudio: disable GConf support

2020-12-17 Thread Tanu Kaskinen
The GConf module is only needed for older versions of paprefs, other
applications shouldn't be interacting with PulseAudio's GConf settings.
Paprefs isn't packaged in OpenEmbedded, so there probably aren't any
users of the GConf functionality.

My immediate motivation for doing this is that I'm converting the
pulseaudio recipe to use Meson, and the GConf module isn't supported by
the Meson build system. Adding support for it would be possible, but
pretty pointless.

The GConf module will be removed in PulseAudio 15.0.

Signed-off-by: Tanu Kaskinen 
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index ad059404f8..48759bca62 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -80,6 +80,7 @@ EXTRA_OECONF = "\
--disable-tests \
--disable-running-from-build-tree \
--disable-esound \
+   --disable-gconf \
 "
 
 # soxr (the SoX Resampler library) doesn't seem to be currently packaged in
@@ -108,7 +109,6 @@ PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 
'bluetooth', 'bluez5'
 
 PACKAGECONFIG[dbus] = "--enable-dbus,--disable-dbus,dbus"
 PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5 sbc"
-PACKAGECONFIG[gconf] = "--enable-gconf,--disable-gconf,gconf"
 PACKAGECONFIG[gsettings] = 
"--enable-gsettings,--disable-gsettings,glib-2.0-native glib-2.0"
 PACKAGECONFIG[ofono] = 
"--enable-bluez5-ofono-headset,--disable-bluez5-ofono-headset,ofono"
 PACKAGECONFIG[gtk] = "--enable-gtk3,--disable-gtk3,gtk+3"
@@ -265,7 +265,6 @@ RDEPENDS_pulseaudio-module-console-kit =+ 
"${@bb.utils.contains('DISTRO_FEATURES
 RDEPENDS_pulseaudio-misc += "pulseaudio-module-cli-protocol-unix"
 
 FILES_${PN}-module-alsa-card += "${datadir}/pulseaudio/alsa-mixer"
-FILES_${PN}-module-gconf += "${libexecdir}/pulse/gconf-helper"
 
 GSETTINGS_PACKAGE = "${@bb.utils.contains('PACKAGECONFIG', 'gsettings', 
'${PN}-module-gsettings', '', d)}"
 FILES_${PN}-module-gsettings += "${libexecdir}/pulse/gsettings-helper 
${datadir}/GConf/gsettings ${datadir}/glib-2.0/schemas"
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145826): 
https://lists.openembedded.org/g/openembedded-core/message/145826
Mute This Topic: https://lists.openembedded.org/mt/79044759/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 0/4] pulseaudio: Autotools to Meson

2020-12-17 Thread Tanu Kaskinen
The PulseAudio project plans to drop Autotools support in 15.0, so let's
switch to Meson. The first patch removes OE_LT_RPATH_ALLOW, which is
some old cruft that sounds like it has something to do Libtool, so it's
perhaps relevant for the goal of dropping Autotools. The next two
patches disable features that aren't available with Meson. The last
patch does the build system switch.

Tanu Kaskinen (4):
  pulseaudio: Remove OE_LT_RPATH_ALLOW
  pulseaudio: disable EsounD support
  pulseaudio: disable GConf support
  pulseaudio: switch build system from Autotools to Meson

 .../pulseaudio/pulseaudio.inc | 69 ---
 ...-option-for-enabling-disabling-Valgr.patch | 67 ++
 .../pulseaudio/pulseaudio_14.0.bb |  1 +
 3 files changed, 97 insertions(+), 40 deletions(-)
 create mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-build-sys-Add-an-option-for-enabling-disabling-Valgr.patch

-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145823): 
https://lists.openembedded.org/g/openembedded-core/message/145823
Mute This Topic: https://lists.openembedded.org/mt/79044755/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 2/4] pulseaudio: disable EsounD support

2020-12-17 Thread Tanu Kaskinen
This disables PulseAudio's EsounD emulation and the EsounD sink module.
EsounD has been obsolete for a long time, and doesn't seem to be
packaged for OpenEmbedded, so probably there are no applications around
that would need PulseAudio's EsounD support.

Signed-off-by: Tanu Kaskinen 
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 4aea8bc6aa..ad059404f8 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -79,6 +79,7 @@ EXTRA_OECONF = "\
ac_cv_header_valgrind_memcheck_h=no \
--disable-tests \
--disable-running-from-build-tree \
+   --disable-esound \
 "
 
 # soxr (the SoX Resampler library) doesn't seem to be currently packaged in
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145825): 
https://lists.openembedded.org/g/openembedded-core/message/145825
Mute This Topic: https://lists.openembedded.org/mt/79044757/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 1/4] pulseaudio: Remove OE_LT_RPATH_ALLOW

2020-12-17 Thread Tanu Kaskinen
I don't know what these variables were supposed to do, but there doesn't
seem to be anything that would use these variables, so removing them
should be safe. The PulseAudio recipe is the only place where these
appear in the repository.

These lines were included already in the original PulseAudio recipe that
was added in commit d9a4c588ef24e7e4019fbe5a2314addbcd3a6bb8 in 2007,
and already at that time there didn't seem to be anything using these
variables.

Signed-off-by: Tanu Kaskinen 
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 5 -
 1 file changed, 5 deletions(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 3a26cb59dd..4aea8bc6aa 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -129,11 +129,6 @@ EXTRA_OECONF_append_armeb = 
"${@bb.utils.contains("TUNE_FEATURES", "neon", "", "
 
 export TARGET_PFPU = "${TARGET_FPU}"
 
-# TODO: Use more fine granular version
-#OE_LT_RPATH_ALLOW=":${libdir}/pulse-0.9:"
-OE_LT_RPATH_ALLOW = "any"
-OE_LT_RPATH_ALLOW[export]="1"
-
 set_cfg_value () {
sed -i -e "s/\(; *\)\?$2 =.*/$2 = $3/" "$1"
if ! grep -q "^$2 = $3\$" "$1"; then
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145824): 
https://lists.openembedded.org/g/openembedded-core/message/145824
Mute This Topic: https://lists.openembedded.org/mt/79044756/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH] maintainers.inc: remove myself from maintainers

2020-12-14 Thread Tanu Kaskinen
---
 meta/conf/distro/include/maintainers.inc | 38 
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index e9c69b2e6e..8dffa2fc95 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -31,14 +31,14 @@ RECIPE_MAINTAINER_pn-acl = "Chen Qi "
 RECIPE_MAINTAINER_pn-acpica = "Ross Burton "
 RECIPE_MAINTAINER_pn-acpid = "Ross Burton "
 RECIPE_MAINTAINER_pn-adwaita-icon-theme = "Ross Burton "
-RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen "
-RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen "
-RECIPE_MAINTAINER_pn-alsa-state = "Tanu Kaskinen "
-RECIPE_MAINTAINER_pn-alsa-tools = "Tanu Kaskinen "
-RECIPE_MAINTAINER_pn-alsa-topology-conf = "Tanu Kaskinen "
-RECIPE_MAINTAINER_pn-alsa-ucm-conf = "Tanu Kaskinen "
-RECIPE_MAINTAINER_pn-alsa-utils = "Tanu Kaskinen "
-RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-alsa-lib = "Unassigned "
+RECIPE_MAINTAINER_pn-alsa-plugins = "Unassigned "
+RECIPE_MAINTAINER_pn-alsa-state = "Unassigned "
+RECIPE_MAINTAINER_pn-alsa-tools = "Unassigned "
+RECIPE_MAINTAINER_pn-alsa-topology-conf = "Unassigned 
"
+RECIPE_MAINTAINER_pn-alsa-ucm-conf = "Unassigned "
+RECIPE_MAINTAINER_pn-alsa-utils = "Unassigned "
+RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Unassigned 
"
 RECIPE_MAINTAINER_pn-apmd = "Anuj Mittal "
 RECIPE_MAINTAINER_pn-apr = "Hongxu Jia "
 RECIPE_MAINTAINER_pn-apr-util = "Hongxu Jia "
@@ -175,7 +175,7 @@ RECIPE_MAINTAINER_pn-expect = "Alexander Kanavin 
"
 RECIPE_MAINTAINER_pn-ffmpeg = "Alexander Kanavin "
 RECIPE_MAINTAINER_pn-file = "Yi Zhao "
 RECIPE_MAINTAINER_pn-findutils = "Chen Qi "
-RECIPE_MAINTAINER_pn-flac = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-flac = "Unassigned "
 RECIPE_MAINTAINER_pn-flex = "Chen Qi "
 RECIPE_MAINTAINER_pn-font-alias = "Armin Kuster "
 RECIPE_MAINTAINER_pn-font-util = "Armin Kuster "
@@ -297,10 +297,10 @@ RECIPE_MAINTAINER_pn-kmod = "Chen Qi 
"
 RECIPE_MAINTAINER_pn-kmod-native = "Chen Qi "
 RECIPE_MAINTAINER_pn-kmscube = "Carlos Rafael Giani "
 RECIPE_MAINTAINER_pn-l3afpad = "Anuj Mittal "
-RECIPE_MAINTAINER_pn-lame = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-lame = "Unassigned "
 RECIPE_MAINTAINER_pn-ldconfig-native = "Khem Raj "
 RECIPE_MAINTAINER_pn-less = "Yi Zhao "
-RECIPE_MAINTAINER_pn-liba52 = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-liba52 = "Unassigned "
 RECIPE_MAINTAINER_pn-libacpi = "Anuj Mittal "
 RECIPE_MAINTAINER_pn-libaio = "Alexander Kanavin "
 RECIPE_MAINTAINER_pn-libarchive = "Otavio Salvador 
"
@@ -343,7 +343,7 @@ RECIPE_MAINTAINER_pn-libgudev = "Ross Burton 
"
 RECIPE_MAINTAINER_pn-libhandy = "Alexander Kanavin "
 RECIPE_MAINTAINER_pn-libical = "Ross Burton "
 RECIPE_MAINTAINER_pn-libice = "Armin Kuster "
-RECIPE_MAINTAINER_pn-libid3tag = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-libid3tag = "Unassigned "
 RECIPE_MAINTAINER_pn-libidn2 = "Ross Burton "
 RECIPE_MAINTAINER_pn-libinput = "Ross Burton "
 RECIPE_MAINTAINER_pn-libjitterentropy = "Ross Burton "
@@ -374,11 +374,11 @@ RECIPE_MAINTAINER_pn-libpthread-stubs = "Alexander 
Kanavin "
 RECIPE_MAINTAINER_pn-psplash = "Yi Zhao "
 RECIPE_MAINTAINER_pn-ptest-runner = "Ross Burton "
-RECIPE_MAINTAINER_pn-pulseaudio = "Tanu Kaskinen "
-RECIPE_MAINTAINER_pn-pulseaudio-client-conf-sato = "Tanu Kaskinen 
"
+RECIPE_MAINTAINER_pn-pulseaudio = "Unassigned "
+RECIPE_MAINTAINER_pn-pulseaudio-client-conf-sato = "Unassigned 
"
 RECIPE_MAINTAINER_pn-puzzles = "Anuj Mittal "
 RECIPE_MAINTAINER_pn-python3 = "Oleksandr Kravchuk 
"
 RECIPE_MAINTAINER_pn-python3-async = "Oleksandr Kravchuk 
"
@@ -651,7 +651,7 @@ RECIPE_MAINTAINER_pn-ruby = "Ross Burton 
"
 RECIPE_MAINTAINER_pn-run-postinsts = "Ross Burton "
 RECIPE_MAINTAINER_pn-rxvt-unicode = "Armin Kuster "
 RECIPE_MAINTAINER_pn-sato-screenshot = "Ross Burton "
-RECIPE_MAINTAINER_pn-sbc = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-sbc = "Unassigned "
 RECIPE_MAINTAINER_pn-screen = "Anuj Mittal "
 RECIPE_MAINTAINER_pn-sed = "Chen Qi "
 RECIPE_MAINTAINER_pn-serf = "Anuj Mittal "
@@ -666,8 +666,8 @@ RECIPE_MAINTAINER_pn-shutdown-desktop = "Alexander Kanavin 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145617): 
https://lists.openembedded.org/g/openembedded-core/message/145617
Mute This Topic: https://lists.openembedded.org/mt/78959040/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] I wish to drop my recipe maintainer duties

2020-12-14 Thread Tanu Kaskinen
Hello,

I haven't lately had time to do OE work, or maybe the lack of time is
more rooted in lack of motivation since I don't objectively have a very
busy life, but in any case, I think it's time for me to step down as a
recipe maintainer. When in 2015 I transitioned from being paid for the
work to a volunteer, I had plans to use OE in hobby projects, but those
projects haven't materialized, so I don't really have any connection to
OE other than being a recipe maintainer. My experience of the community
has been very positive, it has always been nice to work with you, thank
you for that!

Should I post a maintainers.inc patch that changes all my recipes to to
unassigned, or should they or some of them be directly transferred to
someone else?

I will still post some patches for pulseaudio that convert the recipe
from autotools to meson. I've had them ready since the last feature
freeze, and I intended to submit them today, but I found out (as I read
the mailing list for the first time in three months) that the recipe
has had a major version update, so I'll have to redo some tests first.

-- 
Tanu


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145615): 
https://lists.openembedded.org/g/openembedded-core/message/145615
Mute This Topic: https://lists.openembedded.org/mt/78958714/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] Why disable NEON support in recipes if runtime detection works?

2020-08-23 Thread Tanu Kaskinen
On Wed, 2020-07-29 at 15:08 -0700, Andre McCurdy wrote:
> On Wed, Jul 29, 2020 at 6:46 AM Tanu Kaskinen  wrote:
> > On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote:
> > > On Sun, Jul 26, 2020 at 7:01 AM Khem Raj  wrote:
> > > > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen  wrote:
> > > > > On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote:
> > > > > > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote:
> > > > > > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen  
> > > > > > > wrote:
> > > > > > > > Hi!
> > > > > > > > 
> > > > > > > > If a recipe provides NEON optimizations, should those be 
> > > > > > > > explicitly
> > > > > > > > disabled when "neon" is not in TUNE_FEATUERS, even if the 
> > > > > > > > software is
> > > > > > > > able to detect NEON availability at runtime?
> > > > > > > > 
> > > > > > > > I'm currently converting the pulseaudio recipe from Autotools 
> > > > > > > > to Meson,
> > > > > > > > and the old Autotools build system supports disabling NEON
> > > > > > > > optimizations but the Meson build system doesn't. So I'm 
> > > > > > > > wondering if I
> > > > > > > > should add the missing feature to the Meson build system, or 
> > > > > > > > just let
> > > > > > > > the runtime detection do its work.
> > > > > > > > 
> > > > > > > > Is there ever need for disabling NEON optimizations if the CPU
> > > > > > > > indicates NEON support? I guess it could be useful for testing 
> > > > > > > > the "no
> > > > > > > > NEON" case (I today found out that dropping "neon" from 
> > > > > > > > TUNE_FEATURES
> > > > > > > > doesn't remove NEON support from the qemuarm machine), but 
> > > > > > > > otherwise it
> > > > > > > > seems unnecessary, unless there are CPUs that advertise NEON 
> > > > > > > > support
> > > > > > > > but don't actually support it.
> > > > > > > > 
> > > > > > > 
> > > > > > > I think the issue will result in a compiler error perhaps when 
> > > > > > > neon is
> > > > > > > disabled via
> > > > > > > compiler command line which would be the case when neon is not in 
> > > > > > > TUNE_FEATURES
> > > > > > > the compiler might warn or error out when it finds neon 
> > > > > > > instructions
> > > > > > > being compiled via inline
> > > > > > > assembly.  you just can try passing something like -mfpu=vfpv3d16 
> > > > > > > or
> > > > > > > some such and see if
> > > > > > > compiler/assembler complains during build, if not then perhaps 
> > > > > > > its fine.
> > > > > > 
> > > > > > If the last -mfpu is something else than neon, then including
> > > > > > arm_neon.h will succeed but compiling neon code will fail.
> > > > > > 
> > > > > > I did some experiments, and what I found was that when I remove neon
> > > > > > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's 
> > > > > > very
> > > > > > early in the compiler command line. PulseAudio adds -mfpu=neon to
> > > > > > CFLAGS when building neon code, and the last -mfpu wins, so the neon
> > > > > > code gets built without errors.
> > > > > > 
> > > > > > The configure check in PulseAudio only checks that the compiler 
> > > > > > accepts
> > > > > > -mfpu=neon and #include , it doesn't try to compile any
> > > > > > actual neon code. This means that if the user adds -mfpu=vfp (or 
> > > > > > other
> > > > > > non-neon) to CFLAGS rather than CC, configure will pass but building
> > > > > > will fail. Is this something to guard against? A default qemuarm 
> > > > > > build
> > > > > > doesn't do this, so I don't know if this ever happens in OE.
>

Re: [OE-core] Why disable NEON support in recipes if runtime detection works?

2020-07-29 Thread Tanu Kaskinen
On Mon, 2020-07-27 at 13:45 -0700, Andre McCurdy wrote:
> On Sun, Jul 26, 2020 at 7:01 AM Khem Raj  wrote:
> > On Sun, Jul 26, 2020 at 12:59 AM Tanu Kaskinen  wrote:
> > > On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote:
> > > > On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote:
> > > > > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen  wrote:
> > > > > > Hi!
> > > > > > 
> > > > > > If a recipe provides NEON optimizations, should those be explicitly
> > > > > > disabled when "neon" is not in TUNE_FEATUERS, even if the software 
> > > > > > is
> > > > > > able to detect NEON availability at runtime?
> > > > > > 
> > > > > > I'm currently converting the pulseaudio recipe from Autotools to 
> > > > > > Meson,
> > > > > > and the old Autotools build system supports disabling NEON
> > > > > > optimizations but the Meson build system doesn't. So I'm wondering 
> > > > > > if I
> > > > > > should add the missing feature to the Meson build system, or just 
> > > > > > let
> > > > > > the runtime detection do its work.
> > > > > > 
> > > > > > Is there ever need for disabling NEON optimizations if the CPU
> > > > > > indicates NEON support? I guess it could be useful for testing the 
> > > > > > "no
> > > > > > NEON" case (I today found out that dropping "neon" from 
> > > > > > TUNE_FEATURES
> > > > > > doesn't remove NEON support from the qemuarm machine), but 
> > > > > > otherwise it
> > > > > > seems unnecessary, unless there are CPUs that advertise NEON support
> > > > > > but don't actually support it.
> > > > > > 
> > > > > 
> > > > > I think the issue will result in a compiler error perhaps when neon is
> > > > > disabled via
> > > > > compiler command line which would be the case when neon is not in 
> > > > > TUNE_FEATURES
> > > > > the compiler might warn or error out when it finds neon instructions
> > > > > being compiled via inline
> > > > > assembly.  you just can try passing something like -mfpu=vfpv3d16 or
> > > > > some such and see if
> > > > > compiler/assembler complains during build, if not then perhaps its 
> > > > > fine.
> > > > 
> > > > If the last -mfpu is something else than neon, then including
> > > > arm_neon.h will succeed but compiling neon code will fail.
> > > > 
> > > > I did some experiments, and what I found was that when I remove neon
> > > > from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very
> > > > early in the compiler command line. PulseAudio adds -mfpu=neon to
> > > > CFLAGS when building neon code, and the last -mfpu wins, so the neon
> > > > code gets built without errors.
> > > > 
> > > > The configure check in PulseAudio only checks that the compiler accepts
> > > > -mfpu=neon and #include , it doesn't try to compile any
> > > > actual neon code. This means that if the user adds -mfpu=vfp (or other
> > > > non-neon) to CFLAGS rather than CC, configure will pass but building
> > > > will fail. Is this something to guard against? A default qemuarm build
> > > > doesn't do this, so I don't know if this ever happens in OE.
> > > > 
> > > > I don't know yet how Meson behaves, I'll continue testing...
> > > 
> > > I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC.
> > > Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I
> > > tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is
> > > enabled in any case.
> > > 
> > > So, Meson seems pretty safe, although I guess it would be nice not to
> > > override the user's -mfpu setting. I think this isn't a big problem is
> > > practice, since runtime detection works.
> > > 
> > > I haven't tested with a compiler that truly can't build Neon code,
> > > because I don't know how to do that.
> 
> Presumably set a -mcpu=XXX to something which can never support NEON?

No success so far...

I tried CFLAGS_append = " -mcpu=cortex-a9+nosimd" in the pulseaudio
recipe, but Neon got still enabled. GCC warned that -march=ar

Re: [OE-core] Why disable NEON support in recipes if runtime detection works?

2020-07-26 Thread Tanu Kaskinen
On Sun, 2020-07-26 at 09:27 +0300, Tanu Kaskinen wrote:
> On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote:
> > On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen  wrote:
> > > Hi!
> > > 
> > > If a recipe provides NEON optimizations, should those be explicitly
> > > disabled when "neon" is not in TUNE_FEATUERS, even if the software is
> > > able to detect NEON availability at runtime?
> > > 
> > > I'm currently converting the pulseaudio recipe from Autotools to Meson,
> > > and the old Autotools build system supports disabling NEON
> > > optimizations but the Meson build system doesn't. So I'm wondering if I
> > > should add the missing feature to the Meson build system, or just let
> > > the runtime detection do its work.
> > > 
> > > Is there ever need for disabling NEON optimizations if the CPU
> > > indicates NEON support? I guess it could be useful for testing the "no
> > > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES
> > > doesn't remove NEON support from the qemuarm machine), but otherwise it
> > > seems unnecessary, unless there are CPUs that advertise NEON support
> > > but don't actually support it.
> > > 
> > 
> > I think the issue will result in a compiler error perhaps when neon is
> > disabled via
> > compiler command line which would be the case when neon is not in 
> > TUNE_FEATURES
> > the compiler might warn or error out when it finds neon instructions
> > being compiled via inline
> > assembly.  you just can try passing something like -mfpu=vfpv3d16 or
> > some such and see if
> > compiler/assembler complains during build, if not then perhaps its fine.
> 
> If the last -mfpu is something else than neon, then including
> arm_neon.h will succeed but compiling neon code will fail.
> 
> I did some experiments, and what I found was that when I remove neon
> from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very
> early in the compiler command line. PulseAudio adds -mfpu=neon to
> CFLAGS when building neon code, and the last -mfpu wins, so the neon
> code gets built without errors.
> 
> The configure check in PulseAudio only checks that the compiler accepts
> -mfpu=neon and #include , it doesn't try to compile any
> actual neon code. This means that if the user adds -mfpu=vfp (or other
> non-neon) to CFLAGS rather than CC, configure will pass but building
> will fail. Is this something to guard against? A default qemuarm build
> doesn't do this, so I don't know if this ever happens in OE.
> 
> I don't know yet how Meson behaves, I'll continue testing...

I tested Meson now. Meson too enables Neon even if -mfpu=vfp is in CC.
Unlike Autotools, Meson doesn't fail if -mfpu=vfp is added to CFLAGS (I
tried CFLAGS_append = " -mfpu=vfp" in the pulseaudio recipe). Neon is
enabled in any case.

So, Meson seems pretty safe, although I guess it would be nice not to
override the user's -mfpu setting. I think this isn't a big problem is
practice, since runtime detection works.

I haven't tested with a compiler that truly can't build Neon code,
because I don't know how to do that.

-- 
Tanu

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140951): 
https://lists.openembedded.org/g/openembedded-core/message/140951
Mute This Topic: https://lists.openembedded.org/mt/75658822/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [OE-core] Why disable NEON support in recipes if runtime detection works?

2020-07-26 Thread Tanu Kaskinen
On Mon, 2020-07-20 at 15:26 -0700, Khem Raj wrote:
> On Sun, Jul 19, 2020 at 2:06 AM Tanu Kaskinen  wrote:
> > Hi!
> > 
> > If a recipe provides NEON optimizations, should those be explicitly
> > disabled when "neon" is not in TUNE_FEATUERS, even if the software is
> > able to detect NEON availability at runtime?
> > 
> > I'm currently converting the pulseaudio recipe from Autotools to Meson,
> > and the old Autotools build system supports disabling NEON
> > optimizations but the Meson build system doesn't. So I'm wondering if I
> > should add the missing feature to the Meson build system, or just let
> > the runtime detection do its work.
> > 
> > Is there ever need for disabling NEON optimizations if the CPU
> > indicates NEON support? I guess it could be useful for testing the "no
> > NEON" case (I today found out that dropping "neon" from TUNE_FEATURES
> > doesn't remove NEON support from the qemuarm machine), but otherwise it
> > seems unnecessary, unless there are CPUs that advertise NEON support
> > but don't actually support it.
> > 
> 
> I think the issue will result in a compiler error perhaps when neon is
> disabled via
> compiler command line which would be the case when neon is not in 
> TUNE_FEATURES
> the compiler might warn or error out when it finds neon instructions
> being compiled via inline
> assembly.  you just can try passing something like -mfpu=vfpv3d16 or
> some such and see if
> compiler/assembler complains during build, if not then perhaps its fine.

If the last -mfpu is something else than neon, then including
arm_neon.h will succeed but compiling neon code will fail.

I did some experiments, and what I found was that when I remove neon
from TUNE_FEATURES, OE adds -mfpu=vfp to CC, not CFLAGS, so it's very
early in the compiler command line. PulseAudio adds -mfpu=neon to
CFLAGS when building neon code, and the last -mfpu wins, so the neon
code gets built without errors.

The configure check in PulseAudio only checks that the compiler accepts
-mfpu=neon and #include , it doesn't try to compile any
actual neon code. This means that if the user adds -mfpu=vfp (or other
non-neon) to CFLAGS rather than CC, configure will pass but building
will fail. Is this something to guard against? A default qemuarm build
doesn't do this, so I don't know if this ever happens in OE.

I don't know yet how Meson behaves, I'll continue testing...

-- 
Tanu

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140950): 
https://lists.openembedded.org/g/openembedded-core/message/140950
Mute This Topic: https://lists.openembedded.org/mt/75658822/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [OE-core] Why disable NEON support in recipes if runtime detection works?

2020-07-19 Thread Tanu Kaskinen
On Sun, 2020-07-19 at 12:30 +0300, Adrian Bunk wrote:
> On Sun, Jul 19, 2020 at 12:06:15PM +0300, Tanu Kaskinen wrote:
> > ...
> > I'm currently converting the pulseaudio recipe from Autotools to Meson,
> > and the old Autotools build system supports disabling NEON
> > optimizations but the Meson build system doesn't. So I'm wondering if I
> > should add the missing feature to the Meson build system, or just let
> > the runtime detection do its work.
> > ...
> 
> Looking at the git history it seems this was added as a workaround at a 
> time when the autodetection was buggy and caused build breakage.
> 
> Debian also backported commit 0af05213 (build: make ARM NEON check in 
> configure.ac more strict) to PulseAudio 4.0, which was included in
> PulseAudio 5.0.

Thanks for the archeology work! I'll go ahead and drop the
TUNE_FEATURES check then.

-- 
Tanu

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140795): 
https://lists.openembedded.org/g/openembedded-core/message/140795
Mute This Topic: https://lists.openembedded.org/mt/75658822/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[OE-core] Why disable NEON support in recipes if runtime detection works?

2020-07-19 Thread Tanu Kaskinen
Hi!

If a recipe provides NEON optimizations, should those be explicitly
disabled when "neon" is not in TUNE_FEATUERS, even if the software is
able to detect NEON availability at runtime?

I'm currently converting the pulseaudio recipe from Autotools to Meson,
and the old Autotools build system supports disabling NEON
optimizations but the Meson build system doesn't. So I'm wondering if I
should add the missing feature to the Meson build system, or just let
the runtime detection do its work.

Is there ever need for disabling NEON optimizations if the CPU
indicates NEON support? I guess it could be useful for testing the "no
NEON" case (I today found out that dropping "neon" from TUNE_FEATURES
doesn't remove NEON support from the qemuarm machine), but otherwise it
seems unnecessary, unless there are CPUs that advertise NEON support
but don't actually support it.

PulseAudio doesn't have a similar configure switch for the x86
optimizations, so in the name of consistency I would like to rely only
on the runtime CPU detection also for the NEON optimizations.

-- 
Tanu

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140793): 
https://lists.openembedded.org/g/openembedded-core/message/140793
Mute This Topic: https://lists.openembedded.org/mt/75658822/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[OE-core] [PATCH v2] pulseaudio: improve the Thumb frame pointer fix

2020-07-17 Thread Tanu Kaskinen
By changing the register that PulseAudio uses in its asm code makes it
unnecessary to care whether frame pointers are enabled or not.

This fix was suggested by Andre McCurdy.

Signed-off-by: Tanu Kaskinen 
---

v2: Fixed the Upstream-Status line.

 .../pulseaudio/pulseaudio.inc |  8 
 ..._neon-use-register-r12-instead-of-r7.patch | 48 +++
 .../pulseaudio/pulseaudio_13.0.bb |  1 +
 3 files changed, 49 insertions(+), 8 deletions(-)
 create mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap_neon-use-register-r12-instead-of-r7.patch

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index c7f3e67022..4e32b27087 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -63,14 +63,6 @@ DEPENDS += "speexdsp libxml-parser-perl-native libcap"
 
 inherit autotools bash-completion pkgconfig useradd gettext perlnative systemd 
manpages gsettings
 
-# When compiling for Thumb or Thumb2, frame pointers _must_ be disabled since 
the
-# Thumb frame pointer in r7 clashes with pulseaudio's use of inline asm to 
make syscalls
-# (where r7 is used for the syscall NR). In most cases, frame pointers will be
-# disabled automatically due to the optimisation level, but append an explicit
-# -fomit-frame-pointer to handle cases where optimisation is set to -O0 or 
frame
-# pointers have been enabled by -fno-omit-frame-pointer earlier in CFLAGS, etc.
-CFLAGS_append_arm = " ${@bb.utils.contains('TUNE_CCARGS', '-mthumb', 
'-fomit-frame-pointer', '', d)}"
-
 # *.desktop rules wont be generated during configure and build will fail
 # if using --disable-nls
 USE_NLS = "yes"
diff --git 
a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap_neon-use-register-r12-instead-of-r7.patch
 
b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap_neon-use-register-r12-instead-of-r7.patch
new file mode 100644
index 00..aaa162f9b0
--- /dev/null
+++ 
b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap_neon-use-register-r12-instead-of-r7.patch
@@ -0,0 +1,48 @@
+From 4a1668f341f0228904105f77fe5871b9d59b2663 Mon Sep 17 00:00:00 2001
+From: Tanu Kaskinen 
+Date: Mon, 13 Jul 2020 12:42:14 +0300
+Subject: [PATCH] remap_neon: use register r12 instead of r7
+
+When the Thumb instructions set is used and frame pointers are enabled
+(-fno-omit-frame-pointer), r7 can't be used, because it's used for the
+frame pointer. Trying to use r7 caused the compilation to fail.
+
+Thanks to Andre McCurdy for suggesting[1] this fix, all I had to do was to
+test that it works. The code builds now, and cpu-remap-test also
+succeeds.
+
+[1] https://lists.openembedded.org/g/openembedded-core/message/136786
+
+Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/324]
+
+Signed-off-by: Tanu Kaskinen 
+---
+ src/pulsecore/remap_neon.c | 10 +++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/src/pulsecore/remap_neon.c b/src/pulsecore/remap_neon.c
+index ca3b95b48..6f71345f8 100644
+--- a/src/pulsecore/remap_neon.c
 b/src/pulsecore/remap_neon.c
+@@ -52,11 +52,15 @@ static void 
remap_mono_to_stereo_float32ne_generic_arm(pa_remap_t *m, float *dst
+ __asm__ __volatile__ (
+ "ldm%[src]!, {r4,r6}\n\t"
+ "movr5, r4  \n\t"
+-"movr7, r6  \n\t"
+-"stm%[dst]!, {r4-r7}\n\t"
++
++/* We use r12 instead of r7 here, because r7 is reserved for the
++ * frame pointer when using Thumb. */
++"movr12, r6 \n\t"
++
++"stm%[dst]!, {r4-r6,r12}\n\t"
+ : [dst] "+r" (dst), [src] "+r" (src) /* output operands */
+ : /* input operands */
+-: "memory", "r4", "r5", "r6", "r7" /* clobber list */
++: "memory", "r4", "r5", "r6", "r12" /* clobber list */
+ );
+ }
+ 
+-- 
+2.20.1
+
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb 
b/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb
index d2f201d06e..53e9a2357d 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb
@@ -4,6 +4,7 @@ SRC_URI = 
"http://freedesktop.org/software/pulseaudio/releases/${BP}.tar.xz \
file://0001-client-conf-Add-allow-autospawn-for-root.patch \

file://0002-do-not-display-CLFAGS-to-improve-reproducibility-bui.patch \
file://0001-remap-arm-Adjust-inline-asm-constraints.patch \
+   file://0001-remap_neon-use-register-r12-instead-

[OE-core] [PATCH] pulseaudio: improve the Thumb frame pointer fix

2020-07-17 Thread Tanu Kaskinen
By changing the register that PulseAudio uses in its asm code makes it
unnecessary to care whether frame pointers are enabled or not.

This fix was suggested by Andre McCurdy.

Signed-off-by: Tanu Kaskinen 
---
 .../pulseaudio/pulseaudio.inc |  8 ---
 ..._neon-use-register-r12-instead-of-r7.patch | 49 +++
 .../pulseaudio/pulseaudio_13.0.bb |  1 +
 3 files changed, 50 insertions(+), 8 deletions(-)
 create mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap_neon-use-register-r12-instead-of-r7.patch

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index c7f3e67022..4e32b27087 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -63,14 +63,6 @@ DEPENDS += "speexdsp libxml-parser-perl-native libcap"
 
 inherit autotools bash-completion pkgconfig useradd gettext perlnative systemd 
manpages gsettings
 
-# When compiling for Thumb or Thumb2, frame pointers _must_ be disabled since 
the
-# Thumb frame pointer in r7 clashes with pulseaudio's use of inline asm to 
make syscalls
-# (where r7 is used for the syscall NR). In most cases, frame pointers will be
-# disabled automatically due to the optimisation level, but append an explicit
-# -fomit-frame-pointer to handle cases where optimisation is set to -O0 or 
frame
-# pointers have been enabled by -fno-omit-frame-pointer earlier in CFLAGS, etc.
-CFLAGS_append_arm = " ${@bb.utils.contains('TUNE_CCARGS', '-mthumb', 
'-fomit-frame-pointer', '', d)}"
-
 # *.desktop rules wont be generated during configure and build will fail
 # if using --disable-nls
 USE_NLS = "yes"
diff --git 
a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap_neon-use-register-r12-instead-of-r7.patch
 
b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap_neon-use-register-r12-instead-of-r7.patch
new file mode 100644
index 00..53a765a4c8
--- /dev/null
+++ 
b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-remap_neon-use-register-r12-instead-of-r7.patch
@@ -0,0 +1,49 @@
+From 4a1668f341f0228904105f77fe5871b9d59b2663 Mon Sep 17 00:00:00 2001
+From: Tanu Kaskinen 
+Date: Mon, 13 Jul 2020 12:42:14 +0300
+Subject: [PATCH] remap_neon: use register r12 instead of r7
+
+When the Thumb instructions set is used and frame pointers are enabled
+(-fno-omit-frame-pointer), r7 can't be used, because it's used for the
+frame pointer. Trying to use r7 caused the compilation to fail.
+
+Thanks to Andre McCurdy for suggesting[1] this fix, all I had to do was to
+test that it works. The code builds now, and cpu-remap-test also
+succeeds.
+
+[1] https://lists.openembedded.org/g/openembedded-core/message/136786
+
+Upstream-Status: Submitted
+[https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/324]
+
+Signed-off-by: Tanu Kaskinen 
+---
+ src/pulsecore/remap_neon.c | 10 +++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/src/pulsecore/remap_neon.c b/src/pulsecore/remap_neon.c
+index ca3b95b48..6f71345f8 100644
+--- a/src/pulsecore/remap_neon.c
 b/src/pulsecore/remap_neon.c
+@@ -52,11 +52,15 @@ static void 
remap_mono_to_stereo_float32ne_generic_arm(pa_remap_t *m, float *dst
+ __asm__ __volatile__ (
+ "ldm%[src]!, {r4,r6}\n\t"
+ "movr5, r4  \n\t"
+-"movr7, r6  \n\t"
+-"stm%[dst]!, {r4-r7}\n\t"
++
++/* We use r12 instead of r7 here, because r7 is reserved for the
++ * frame pointer when using Thumb. */
++"movr12, r6 \n\t"
++
++"stm%[dst]!, {r4-r6,r12}\n\t"
+ : [dst] "+r" (dst), [src] "+r" (src) /* output operands */
+ : /* input operands */
+-: "memory", "r4", "r5", "r6", "r7" /* clobber list */
++: "memory", "r4", "r5", "r6", "r12" /* clobber list */
+ );
+ }
+ 
+-- 
+2.20.1
+
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb 
b/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb
index d2f201d06e..53e9a2357d 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb
@@ -4,6 +4,7 @@ SRC_URI = 
"http://freedesktop.org/software/pulseaudio/releases/${BP}.tar.xz \
file://0001-client-conf-Add-allow-autospawn-for-root.patch \

file://0002-do-not-display-CLFAGS-to-improve-reproducibility-bui.patch \
file://0001-remap-arm-Adjust-inline-asm-constraints.patch \
+   file://0001-remap_neon-use-register-r12-instead-of-r7.patch \
file:

Re: [OE-core] [PATCH] pulseaudio: fix for ARM thumb + frame pointers compilation error

2020-07-17 Thread Tanu Kaskinen
On Fri, 2020-07-17 at 12:19 -0700, Andre McCurdy wrote:
> On Fri, Jul 17, 2020 at 3:09 AM Tanu Kaskinen  wrote:
> > On Thu, 2020-03-26 at 14:23 -0700, Andre McCurdy wrote:
> > > On Thu, Mar 26, 2020 at 1:26 PM Adrian Bunk  wrote:
> > > > On Thu, Mar 26, 2020 at 12:53:08PM -0700, Andre McCurdy wrote:
> > > > > On Thu, Mar 26, 2020 at 12:16 PM Adrian Bunk  wrote:
> > > > > > On Thu, Mar 26, 2020 at 05:26:29PM +0200, Stefan Ghinea wrote:
> > > > > > > ...
> > > > > > > When compiling for Thumb or Thumb2, frame pointers _must_ be 
> > > > > > > disabled
> > > > > > > since the Thumb frame pointer in r7
> > > > > > > ...
> > > > > > 
> > > > > > How are you reproducing the problem in pulseaudio?
> > > > > > 
> > > > > > This sounds like a workaround for a bug in musl that was fixed 2 
> > > > > > years ago.
> > > > > 
> > > > > The problem can show up anywhere that inline asm is trying to use r7.
> > > > > In this case it looks like:
> > > > > 
> > > > >   
> > > > > https://github.com/pulseaudio/pulseaudio/blob/master/src/pulsecore/remap_neon.c#L50
> > > > > ...
> > > > 
> > > > After looking at the pulseaudio code I suspected the patch description
> > > > claiming pulseaudio syscall code would be the problem was rubbish, and
> > > > that this NEON code was the problem.
> > > 
> > > Yes, the comment looks like it was copied and pasted and doesn't
> > > really apply in this case (since pulseaudio isn't making syscalls).
> > > That should be updated.
> > > 
> > > > But when I tried to reproduce the problem it built for me with both
> > > > glibc and musl in master (the patch didn't mention that this was a
> > > > musl-only problem).
> > > > 
> > > > Then I saw that this was fixed in musl upstream 2 years ago:
> > > > https://git.musl-libc.org/cgit/musl/commit/?id=e3c682ab5257aaa6739ef242a9676d897370e78e
> > > 
> > > Right, it's not related to musl or glibc. I suspect it can be
> > > reproduced by building for an ARM target which supports NEON, ensuring
> > > that DEFAULTTUNE doesn't forcefully disable Thumb (e.g. it should be
> > > armv7vethf-neon, not armv7vehf-neon), setting ARM_INSTRUCTION_SET to
> > > thumb and then compiling with frame pointers enabled (e.g. by adding
> > > -fno-omit-frame-pointer to CFLAGS).
> > > 
> > > In terms of a fix, then changing the code to use r12 instead of r7 is
> > > probably the best solution (assuming it works), but would need careful
> > > testing. Appending -fomit-frame-pointer to CFLAGS for ARM machines
> > > building for Thumb is safe and should fix the issue too. Presumably
> > > limiting the -fomit-frame-pointer workaround to ARM machines which
> > > support NEON building for Thumb would be an even more targeted
> > > solution.
> > 
> > I finally found time to test fixing the assembly code to use r12
> > instead of r7. Seems to work fine (I was first baffled by incorrect
> > behaviour, because I changed "{r4-r7}" to "{r4-r12}" without realizing
> > that "r4-r12" meant a range of all registers from r4 to r12).
> > 
> > Can you enlighten me: why did you choose r12 instead of r8? Why did the
> > original author use registers r4-r7 instead of r0-r3? Is it somehow
> > advisable to avoid registers r0-r3 and r8-r11? The code seems to work
> > fine with any set of registers, except r7.
> 
> The compiler will work around whichever set of registers you want to
> use (apart from r7 in some cases) so it's expected that other
> combinations will work fine. Some combinations will be more efficient
> than others (ie the compiler will need to do less shuffling values
> between registers or saving register values to the stack in order to
> make registers you specify available to you). Using r12 instead of r8
> is just an educated guess about the combination will allow the
> compiler to generate the most efficient code.
> 
> Registers r0-r3 and r12 can be used within a function without needing
> to preserve their previous contents, so if a function needs registers
> it's more efficient to use these registers first. Other registers need
> to be preserved (ie saved to the stack) before use.
> 
> Registers r0-r3 are also used to pass non-floating point arguments to
> a function

Re: [OE-core] [PATCH] pulseaudio: fix for ARM thumb + frame pointers compilation error

2020-07-17 Thread Tanu Kaskinen
On Thu, 2020-03-26 at 14:23 -0700, Andre McCurdy wrote:
> On Thu, Mar 26, 2020 at 1:26 PM Adrian Bunk  wrote:
> > On Thu, Mar 26, 2020 at 12:53:08PM -0700, Andre McCurdy wrote:
> > > On Thu, Mar 26, 2020 at 12:16 PM Adrian Bunk  wrote:
> > > > On Thu, Mar 26, 2020 at 05:26:29PM +0200, Stefan Ghinea wrote:
> > > > > ...
> > > > > When compiling for Thumb or Thumb2, frame pointers _must_ be disabled
> > > > > since the Thumb frame pointer in r7
> > > > > ...
> > > > 
> > > > How are you reproducing the problem in pulseaudio?
> > > > 
> > > > This sounds like a workaround for a bug in musl that was fixed 2 years 
> > > > ago.
> > > 
> > > The problem can show up anywhere that inline asm is trying to use r7.
> > > In this case it looks like:
> > > 
> > >   
> > > https://github.com/pulseaudio/pulseaudio/blob/master/src/pulsecore/remap_neon.c#L50
> > > ...
> > 
> > After looking at the pulseaudio code I suspected the patch description
> > claiming pulseaudio syscall code would be the problem was rubbish, and
> > that this NEON code was the problem.
> 
> Yes, the comment looks like it was copied and pasted and doesn't
> really apply in this case (since pulseaudio isn't making syscalls).
> That should be updated.
> 
> > But when I tried to reproduce the problem it built for me with both
> > glibc and musl in master (the patch didn't mention that this was a
> > musl-only problem).
> > 
> > Then I saw that this was fixed in musl upstream 2 years ago:
> > https://git.musl-libc.org/cgit/musl/commit/?id=e3c682ab5257aaa6739ef242a9676d897370e78e
> 
> Right, it's not related to musl or glibc. I suspect it can be
> reproduced by building for an ARM target which supports NEON, ensuring
> that DEFAULTTUNE doesn't forcefully disable Thumb (e.g. it should be
> armv7vethf-neon, not armv7vehf-neon), setting ARM_INSTRUCTION_SET to
> thumb and then compiling with frame pointers enabled (e.g. by adding
> -fno-omit-frame-pointer to CFLAGS).
> 
> In terms of a fix, then changing the code to use r12 instead of r7 is
> probably the best solution (assuming it works), but would need careful
> testing. Appending -fomit-frame-pointer to CFLAGS for ARM machines
> building for Thumb is safe and should fix the issue too. Presumably
> limiting the -fomit-frame-pointer workaround to ARM machines which
> support NEON building for Thumb would be an even more targeted
> solution.

I finally found time to test fixing the assembly code to use r12
instead of r7. Seems to work fine (I was first baffled by incorrect
behaviour, because I changed "{r4-r7}" to "{r4-r12}" without realizing
that "r4-r12" meant a range of all registers from r4 to r12).

Can you enlighten me: why did you choose r12 instead of r8? Why did the
original author use registers r4-r7 instead of r0-r3? Is it somehow
advisable to avoid registers r0-r3 and r8-r11? The code seems to work
fine with any set of registers, except r7.

-- 
Tanu

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140750): 
https://lists.openembedded.org/g/openembedded-core/message/140750
Mute This Topic: https://lists.openembedded.org/mt/72566057/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


[OE-core] [PATCH] alsa-lib: upgrade 1.2.3.1 -> 1.2.3.2

2020-07-11 Thread Tanu Kaskinen
Changelog:
https://www.alsa-project.org/wiki/Changes_v1.2.3.1_v1.2.3.2

Signed-off-by: Tanu Kaskinen 
---
 .../alsa/{alsa-lib_1.2.3.1.bb => alsa-lib_1.2.3.2.bb}   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.2.3.1.bb => 
alsa-lib_1.2.3.2.bb} (93%)

diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.2.3.1.bb 
b/meta/recipes-multimedia/alsa/alsa-lib_1.2.3.2.bb
similarity index 93%
rename from meta/recipes-multimedia/alsa/alsa-lib_1.2.3.1.bb
rename to meta/recipes-multimedia/alsa/alsa-lib_1.2.3.2.bb
index 1eb56f4053..1ed1a7b9a3 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.2.3.1.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.2.3.2.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=a916467b91076e631dd8edb7424769c7 \
 "
 
 SRC_URI = "https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2;
-SRC_URI[sha256sum] = 
"1244585515fbebce7d0e53656c1fb614f99accb8413115ce3efb9a9309c4c892"
+SRC_URI[sha256sum] = 
"e81fc5b7afcaee8c9fd7f64a1e3043e88d62e9ad2c4cff55f578df6b0a9abe15"
 
 inherit autotools pkgconfig
 
-- 
2.20.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140566): 
https://lists.openembedded.org/g/openembedded-core/message/140566
Mute This Topic: https://lists.openembedded.org/mt/75452089/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [OE-core] [PATCH] pulseaudio: fix for ARM thumb + frame pointers compilation error

2020-03-30 Thread Tanu Kaskinen
On Mon, 2020-03-30 at 19:29 +0300, Tanu Kaskinen wrote:
> On Thu, 2020-03-26 at 17:26 +0200, Stefan Ghinea wrote:
> > From: Catalin Enache 
> > 
> > When compiling for Thumb or Thumb2, frame pointers _must_ be disabled
> > since the Thumb frame pointer in r7 clashes with pulseaudio's use of inline
> > asm to make syscalls (where r7 is used for the syscall NR).
> 
> Do you have a pointer to the asm code that does syscalls? I'm an
> upstream maintainer of PulseAudio, and to me it sounds a bit strange
> that there would be inline asm that does syscalls.
> 
> It would be great to fix this problem in upstream (either by applying
> this fix/workaround in the build system, or by modifying the asm code
> so that the problem goes away).

I forgot to check if others had already commented on this... So the
real problem is that src/pulsecore/remap_neon.c uses the r7 register in
a few places. Andre McCurdy said: "In terms of a fix, then changing the
code to use r12 instead of r7 is probably the best solution (assuming
it works), but would need careful testing." I'll try this.

-- 
Tanu

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#136864): 
https://lists.openembedded.org/g/openembedded-core/message/136864
Mute This Topic: https://lists.openembedded.org/mt/72566057/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [OE-core] [PATCH] pulseaudio: fix for ARM thumb + frame pointers compilation error

2020-03-30 Thread Tanu Kaskinen
On Thu, 2020-03-26 at 17:26 +0200, Stefan Ghinea wrote:
> From: Catalin Enache 
> 
> When compiling for Thumb or Thumb2, frame pointers _must_ be disabled
> since the Thumb frame pointer in r7 clashes with pulseaudio's use of inline
> asm to make syscalls (where r7 is used for the syscall NR).

Do you have a pointer to the asm code that does syscalls? I'm an
upstream maintainer of PulseAudio, and to me it sounds a bit strange
that there would be inline asm that does syscalls.

It would be great to fix this problem in upstream (either by applying
this fix/workaround in the build system, or by modifying the asm code
so that the problem goes away).

-- 
Tanu

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#136860): 
https://lists.openembedded.org/g/openembedded-core/message/136860
Mute This Topic: https://lists.openembedded.org/mt/72566057/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [OE-core] [PATCH V3] alsa-utils: upgrade 1.2.1 -> 1.2.2

2020-03-05 Thread Tanu Kaskinen
On Sun, 2020-02-23 at 13:11 +, Richard Purdie wrote:
> On Sun, 2020-02-23 at 18:26 +0530, Praveen Muthusamy wrote:
> > From: Praveen Muthusamy 
> > 
> > Changelog: https://alsa-project.org/wiki/Changes_v1.2.1.2_v1.2.2
> > 
> > Signed-off-by: Praveen Muthusamy 
> > ---
> >  ...lsa-utils-scripts_1.2.1.bb => alsa-utils-scripts_1.2.2.bb} | 0
> >  .../alsa/{alsa-utils_1.2.1.bb => alsa-utils_1.2.2.bb} | 4 ++--
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >  rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.2.1.bb => 
> > alsa-utils-scripts_1.2.2.bb} (100%)
> >  rename meta/recipes-multimedia/alsa/{alsa-utils_1.2.1.bb => 
> > alsa-utils_1.2.2.bb} (97%)
> 
> Thanks, does this address the previous testing failure though?

alsa-utils 1.2.2 seems to depend on alsa-lib 1.2.2 (specifically,
alsatplg uses a new function in libatopology), so alsa-utils can't be
updated before alsa-lib.

-- 
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] [PATCH] pulseaudio: remove unnecessary libltdl copying

2020-02-15 Thread Tanu Kaskinen
This was added in 5df6deaa32e4f6d0a8985403970a137270491991. I don't know
what problem it solved at that time (2009-04-21), but it seems that
nowadays PulseAudio builds fine without copying the libltdl stuff.

Signed-off-by: Tanu Kaskinen 
---
 meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb | 5 -
 1 file changed, 5 deletions(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb 
b/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb
index 7f8ebc2090..1bd4d9083e 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_13.0.bb
@@ -7,8 +7,3 @@ SRC_URI = 
"http://freedesktop.org/software/pulseaudio/releases/${BP}.tar.xz \
"
 SRC_URI[md5sum] = "e41d606f90254ed45c90520faf83d95c"
 SRC_URI[sha256sum] = 
"961b23ca1acfd28f2bc87414c27bb40e12436efcf2158d29721b1e89f3f28057"
-
-do_compile_prepend() {
-mkdir -p ${S}/libltdl
-cp ${STAGING_LIBDIR}/libltdl* ${S}/libltdl
-}
-- 
2.20.1

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


Re: [OE-core] [PATCH v2 2/5] alsa-ucm-conf: new recipe, version 1.2.1.2

2020-02-01 Thread Tanu Kaskinen
On Thu, 2020-01-30 at 15:01 +0100, Nicolas Dechesne wrote:
> hey,
> 
> On Mon, Jan 6, 2020 at 10:18 AM Tanu Kaskinen  wrote:
> > The UCM configuration files were moved from the alsa-lib repository to a
> > new alsa-ucm-conf repository. The move was accompanied by a license
> > change from LGPL2.1 to BSD-3-Clause.
> > 
> > Signed-off-by: Tanu Kaskinen 
> > ---
> >  meta/conf/distro/include/maintainers.inc  |  1 +
> >  .../alsa/alsa-lib_1.2.1.2.bb  |  2 +-
> >  .../alsa/alsa-ucm-conf_1.2.1.2.bb | 23 +++
> >  3 files changed, 25 insertions(+), 1 deletion(-)
> >  create mode 100644 meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
> > 
> > diff --git a/meta/conf/distro/include/maintainers.inc 
> > b/meta/conf/distro/include/maintainers.inc
> > index 39eee9475c..c9fb373f52 100644
> > --- a/meta/conf/distro/include/maintainers.inc
> > +++ b/meta/conf/distro/include/maintainers.inc
> > @@ -35,6 +35,7 @@ RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen 
> > "
> >  RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen "
> >  RECIPE_MAINTAINER_pn-alsa-state = "Tanu Kaskinen "
> >  RECIPE_MAINTAINER_pn-alsa-tools = "Tanu Kaskinen "
> > +RECIPE_MAINTAINER_pn-alsa-ucm-conf = "Tanu Kaskinen "
> >  RECIPE_MAINTAINER_pn-alsa-utils = "Tanu Kaskinen "
> >  RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Tanu Kaskinen "
> >  RECIPE_MAINTAINER_pn-apmd = "Anuj Mittal "
> > diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb 
> > b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
> > index 9565ad1b20..7bc78b8523 100644
> > --- a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
> > +++ b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
> > @@ -33,7 +33,7 @@ FILES_alsa-server = "${bindir}/*"
> >  FILES_alsa-conf = "${datadir}/alsa/"
> >  FILES_libatopology = "${libdir}/libatopology.so.*"
> > 
> > -RDEPENDS_${PN}_class-target = "alsa-conf"
> > +RDEPENDS_${PN}_class-target = "alsa-conf alsa-ucm-conf"
> > 
> >  # upgrade path
> >  RPROVIDES_${PN} = "libasound"
> > diff --git a/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb 
> > b/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
> > new file mode 100644
> > index 00..469d1f7a95
> > --- /dev/null
> > +++ b/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
> > @@ -0,0 +1,23 @@
> > +SUMMARY = "ALSA Use Case Manager configuration"
> > +HOMEPAGE = "https://alsa-project.org;
> > +BUGTRACKER = "https://alsa-project.org/wiki/Bug_Tracking;
> > +LICENSE = "BSD-3-Clause"
> > +LIC_FILES_CHKSUM = "file://LICENSE;md5=20d74d74db9741697903372ad001d3b4"
> > +
> > +# The tarball doesn't have any toplevel directory. The subdir option tells
> > +# Bitbake to unpack the archive to the correct place.
> > +SRC_URI = 
> > "https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2;subdir=${BP};
> > +SRC_URI[md5sum] = "b7fa43cfd79df978184a6333766d2a50"
> > +SRC_URI[sha256sum] = 
> > "ea8a86875f4cf430d49a662a04a6d6c606c5c9d67e54cb944c4d77b24554062f"
> > +
> > +inherit allarch
> 
> it's a bit late into the game.. but I have some questions about this
> patch. now that the alsa-ucm-conf are allarch, how do we expect a BSP
> layer to provide its own UCM config files? if i add a .bbappend file,
> I can't change PACKAGE_ARCH to be 'machine' specific. If i create a
> new recipe for my custom UCM files, then it's not obvious when I
> should install them, since we need them only if alsa-ucm-conf is
> installed in the first place..
> 
> I was thinking about adding an empty alsa-ucm-machine-conf recipe that
> BSP could append,  like gpsd, e.g.:
> http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-navigation/gpsd/gpsd-machine-conf_1.0.bb
> 
> Is that a good idea?

I was hoping someone else would answer this, since I have no experience
with BSPs or .bbappend files... Since I don't know how this *should* be
done, I'm not against creating alsa-ucm-machine-conf. However, my
intuition would be that the BSP installs its configuration as a
separate recipe whenever the BSP is used. I don't see the need to have
conditions such as "install only if alsa-ucm-conf is installed". Is it
just to save disk space? alsa-ucm-conf anyway installs a bunch of files
that aren't relevant to most machines, so if you're worried about UCM
disk consumption, the alsa-ucm-conf recipe would need work to somehow
install only those files 

Re: [OE-core] [PATCH] pulseaudio: 12.2 -> 13.0

2020-01-07 Thread Tanu Kaskinen
On Thu, 2020-01-02 at 21:32 +, Ross Burton wrote:
> On 21/11/2019 14:06, Tanu Kaskinen wrote:
> > Release notes:
> > https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/13.0/
> 
> I note that this release adds a meson.build so if anyone is interested 
> in porting another recipe to meson...

I'm starting to look into this.

-- 
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] [PATCH] speexdsp: 1.2rc3 -> 1.2.0

2020-01-06 Thread Tanu Kaskinen
Removed backported patch
0001-Don-t-rely-on-HAVE_STDINT_H-et-al.-being-defined.patch

Enabling NEON on aarch64 doesn't break the build any more.

Signed-off-by: Tanu Kaskinen 
---
 ...n-HAVE_STDINT_H-et-al.-being-defined.patch | 63 ---
 .../{speexdsp_1.2rc3.bb => speexdsp_1.2.0.bb} | 20 +-
 2 files changed, 3 insertions(+), 80 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/speex/speexdsp/0001-Don-t-rely-on-HAVE_STDINT_H-et-al.-being-defined.patch
 rename meta/recipes-multimedia/speex/{speexdsp_1.2rc3.bb => speexdsp_1.2.0.bb} 
(51%)

diff --git 
a/meta/recipes-multimedia/speex/speexdsp/0001-Don-t-rely-on-HAVE_STDINT_H-et-al.-being-defined.patch
 
b/meta/recipes-multimedia/speex/speexdsp/0001-Don-t-rely-on-HAVE_STDINT_H-et-al.-being-defined.patch
deleted file mode 100644
index c7067daaa0..00
--- 
a/meta/recipes-multimedia/speex/speexdsp/0001-Don-t-rely-on-HAVE_STDINT_H-et-al.-being-defined.patch
+++ /dev/null
@@ -1,63 +0,0 @@
-From c73370ceafd138becee8ca3c688ba75756830bfe Mon Sep 17 00:00:00 2001
-From: Tanu Kaskinen 
-Date: Sun, 5 Jul 2015 17:48:16 +0300
-Subject: [PATCH] Don't rely on HAVE_STDINT_H et al. being defined
-
-Not everyone who includes speexdsp_config_types.h will have a test
-which defines those, and if we've chosen to use the stdint types at
-configure time then we know exactly which header(s) are available, so
-just choose the best one then and generate the header to use it.
-
-This patch, including the above text, is copied from a commit in the
-speex repository[1]. The original commit for speex was made by Ron
-.
-
-[1] 
https://git.xiph.org/?p=speex.git;a=commitdiff;h=774c87d6cb7dd8dabdd17677fc6da753ecf4aa87
-
-Upstream-Status: Backport
-
-Signed-off-by: Tanu Kaskinen 

- configure.ac | 6 ++
- include/speex/speexdsp_config_types.h.in | 8 +---
- 2 files changed, 7 insertions(+), 7 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 2cd2d1e..1de0c23 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -334,6 +334,12 @@ AC_SUBST([USIZE16])
- AC_SUBST([SIZE32])
- AC_SUBST([USIZE32])
- 
-+AS_IF([test "$ac_cv_header_stdint_h" = "yes"],[INCLUDE_STDINT="#include 
"],
-+  [test "$ac_cv_header_inttypes_h" = "yes"],  [INCLUDE_STDINT="#include 
"],
-+  [test "$ac_cv_header_sys_types_h" = "yes"], [INCLUDE_STDINT="#include 
"])
-+
-+AC_SUBST([INCLUDE_STDINT])
-+
- AC_CONFIG_FILES([
-Makefile libspeexdsp/Makefile doc/Makefile SpeexDSP.spec
-include/Makefile include/speex/Makefile speexdsp.pc
-diff --git a/include/speex/speexdsp_config_types.h.in 
b/include/speex/speexdsp_config_types.h.in
-index 02b82fd..5ea7b55 100644
 a/include/speex/speexdsp_config_types.h.in
-+++ b/include/speex/speexdsp_config_types.h.in
-@@ -1,13 +1,7 @@
- #ifndef __SPEEX_TYPES_H__
- #define __SPEEX_TYPES_H__
- 
--#if defined HAVE_STDINT_H
--#  include 
--#elif defined HAVE_INTTYPES_H
--#  include 
--#elif defined HAVE_SYS_TYPES_H
--#  include 
--#endif
-+@INCLUDE_STDINT@
- 
- typedef @SIZE16@ spx_int16_t;
- typedef @USIZE16@ spx_uint16_t;
--- 
-1.9.3
-
diff --git a/meta/recipes-multimedia/speex/speexdsp_1.2rc3.bb 
b/meta/recipes-multimedia/speex/speexdsp_1.2.0.bb
similarity index 51%
rename from meta/recipes-multimedia/speex/speexdsp_1.2rc3.bb
rename to meta/recipes-multimedia/speex/speexdsp_1.2.0.bb
index 03c949be22..2f934ebe3a 100644
--- a/meta/recipes-multimedia/speex/speexdsp_1.2rc3.bb
+++ b/meta/recipes-multimedia/speex/speexdsp_1.2.0.bb
@@ -5,11 +5,10 @@ SECTION = "libs"
 LICENSE = "BSD-3-Clause"
 LIC_FILES_CHKSUM = "file://COPYING;md5=314649d8ba9dd7045dfb6683f298d0a8"
 
-SRC_URI = "http://downloads.xiph.org/releases/speex/speexdsp-${PV}.tar.gz \
-   file://0001-Don-t-rely-on-HAVE_STDINT_H-et-al.-being-defined.patch"
+SRC_URI = "http://downloads.xiph.org/releases/speex/speexdsp-${PV}.tar.gz;
 
-SRC_URI[md5sum] = "70d9d31184f7eb761192fd1ef0b7"
-SRC_URI[sha256sum] = 
"4ae688600039f5d224bdf2e222d2fbde65608447e4c2f681585e4dca6df692f1"
+SRC_URI[md5sum] = "b722df341576dc185d897131321008fc"
+SRC_URI[sha256sum] = 
"682042fc6f9bee6294ec453f470dadc26c6ff29b9c9e9ad2ffc1f4312fd64771"
 
 inherit autotools pkgconfig
 
@@ -18,19 +17,6 @@ EXTRA_OECONF = "\
 ${@bb.utils.contains('TARGET_FPU', 'soft', '--enable-fixed-point 
--disable-float-api', '', d)} \
 "
 
-# Workaround for a build failure when building with MACHINE=qemuarm64. I think
-# aarch64 is supposed to support NEON just fine, but building for qemuarm64
-# fails in NEON code:
-#
-# .../speexdsp-1.2rc3/libspeexdsp/resample_neon.h:148:5: error: impossible 
constraint in 'asm'
-#  asm volatile ("  cmp %[len], #0\n"
-#  ^
-#
-# I sent an email about the issue to speex-dev. At the time of writing there
-# are no responses yet:
-# ht

[OE-core] [PATCH v2 2/5] alsa-ucm-conf: new recipe, version 1.2.1.2

2020-01-06 Thread Tanu Kaskinen
The UCM configuration files were moved from the alsa-lib repository to a
new alsa-ucm-conf repository. The move was accompanied by a license
change from LGPL2.1 to BSD-3-Clause.

Signed-off-by: Tanu Kaskinen 
---
 meta/conf/distro/include/maintainers.inc  |  1 +
 .../alsa/alsa-lib_1.2.1.2.bb  |  2 +-
 .../alsa/alsa-ucm-conf_1.2.1.2.bb | 23 +++
 3 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 39eee9475c..c9fb373f52 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -35,6 +35,7 @@ RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-state = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-tools = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-alsa-ucm-conf = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-utils = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-apmd = "Anuj Mittal "
diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb 
b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
index 9565ad1b20..7bc78b8523 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
@@ -33,7 +33,7 @@ FILES_alsa-server = "${bindir}/*"
 FILES_alsa-conf = "${datadir}/alsa/"
 FILES_libatopology = "${libdir}/libatopology.so.*"
 
-RDEPENDS_${PN}_class-target = "alsa-conf"
+RDEPENDS_${PN}_class-target = "alsa-conf alsa-ucm-conf"
 
 # upgrade path
 RPROVIDES_${PN} = "libasound"
diff --git a/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb 
b/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
new file mode 100644
index 00..469d1f7a95
--- /dev/null
+++ b/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
@@ -0,0 +1,23 @@
+SUMMARY = "ALSA Use Case Manager configuration"
+HOMEPAGE = "https://alsa-project.org;
+BUGTRACKER = "https://alsa-project.org/wiki/Bug_Tracking;
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=20d74d74db9741697903372ad001d3b4"
+
+# The tarball doesn't have any toplevel directory. The subdir option tells
+# Bitbake to unpack the archive to the correct place.
+SRC_URI = 
"https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2;subdir=${BP};
+SRC_URI[md5sum] = "b7fa43cfd79df978184a6333766d2a50"
+SRC_URI[sha256sum] = 
"ea8a86875f4cf430d49a662a04a6d6c606c5c9d67e54cb944c4d77b24554062f"
+
+inherit allarch
+
+do_install() {
+install -d ${D}/usr/share/alsa
+cp -r ${S}/ucm ${D}/usr/share/alsa
+cp -r ${S}/ucm2 ${D}/usr/share/alsa
+}
+
+PACKAGES = "${PN}"
+
+FILES_${PN} = "*"
-- 
2.20.1

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


[OE-core] [PATCH v2 5/5] alsa-plugins: 1.1.9 -> 1.2.1

2020-01-06 Thread Tanu Kaskinen
Signed-off-by: Tanu Kaskinen 
---
 .../alsa/{alsa-plugins_1.1.9.bb => alsa-plugins_1.2.1.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.9.bb => 
alsa-plugins_1.2.1.bb} (98%)

diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.9.bb 
b/meta/recipes-multimedia/alsa/alsa-plugins_1.2.1.bb
similarity index 98%
rename from meta/recipes-multimedia/alsa/alsa-plugins_1.1.9.bb
rename to meta/recipes-multimedia/alsa/alsa-plugins_1.2.1.bb
index b94fc5cee3..9882e12763 100644
--- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.9.bb
+++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.2.1.bb
@@ -21,8 +21,8 @@ LIC_FILES_CHKSUM = "\
 "
 
 SRC_URI = "https://www.alsa-project.org/files/pub/plugins/${BP}.tar.bz2;
-SRC_URI[md5sum] = "e0caffbd849c51ed81751378f56cb563"
-SRC_URI[sha256sum] = 
"161772303da521abbbf1d91f63b470c4791392d5728f2192a42d71292078f907"
+SRC_URI[md5sum] = "5b11cd3ec92e5f9190ec378565b529e8"
+SRC_URI[sha256sum] = 
"4d94de7ad41734b8604a652521200bb6554fcf0c2c00fdbd302b1710d76548da"
 
 DEPENDS += "alsa-lib"
 
-- 
2.20.1

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


[OE-core] [PATCH v2 4/5] alsa-utils: 1.1.9 -> 1.2.1

2020-01-06 Thread Tanu Kaskinen
I moved the ALLOW_EMPTY line next to the line that sets FILES to "".
That makes it easier to see that the package is not only allowed to be
empty, but forced to be empty.

Signed-off-by: Tanu Kaskinen 
---
 ...-utils-scripts_1.1.9.bb => alsa-utils-scripts_1.2.1.bb} | 0
 .../alsa/{alsa-utils_1.1.9.bb => alsa-utils_1.2.1.bb}  | 7 +++
 2 files changed, 3 insertions(+), 4 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.9.bb => 
alsa-utils-scripts_1.2.1.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.9.bb => 
alsa-utils_1.2.1.bb} (97%)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.9.bb 
b/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.2.1.bb
similarity index 100%
rename from meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.9.bb
rename to meta/recipes-multimedia/alsa/alsa-utils-scripts_1.2.1.bb
diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.2.1.bb
similarity index 97%
rename from meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb
rename to meta/recipes-multimedia/alsa/alsa-utils_1.2.1.bb
index c443d3594d..9144af628a 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.2.1.bb
@@ -21,8 +21,8 @@ PACKAGECONFIG[manpages] = "--enable-xmlto, --disable-xmlto, 
xmlto-native docbook
 
 # alsa-utils specified in SRC_URI due to alsa-utils-scripts recipe
 SRC_URI = 
"https://www.alsa-project.org/files/pub/utils/alsa-utils-${PV}.tar.bz2;
-SRC_URI[md5sum] = "5ed21c3e296c06046cc986e732f625f6"
-SRC_URI[sha256sum] = 
"5ddf2cbddb4bd1a4a2a6492a09c25898b08c3ad64893c3655be14194cf0a213a"
+SRC_URI[md5sum] = "c4628bae7632937eac2de4cf2a3de82e"
+SRC_URI[sha256sum] = 
"0b110ba71ef41d3009db1bc4dcae0cf79efb99cb5426fa19d0312470560a2c0d"
 
 # On build machines with python-docutils (not python3-docutils !!) installed
 # rst2man (not rst2man.py) is detected and compile fails with
@@ -56,6 +56,7 @@ PACKAGES += "${ALSA_UTILS_PKGS}"
 RDEPENDS_${PN} += "${ALSA_UTILS_PKGS}"
 
 FILES_${PN} = ""
+ALLOW_EMPTY_alsa-utils = "1"
 FILES_alsa-utils-alsabat = "${bindir}/alsabat"
 FILES_alsa-utils-alsatplg= "${bindir}/alsatplg"
 FILES_alsa-utils-aplay   = "${bindir}/aplay ${bindir}/arecord 
${bindir}/axfer"
@@ -88,8 +89,6 @@ SUMMARY_alsa-utils-alsaucm  = "ALSA Use Case Manager"
 
 RRECOMMENDS_alsa-utils-alsactl = "alsa-states"
 
-ALLOW_EMPTY_alsa-utils = "1"
-
 do_install() {
autotools_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 v2 3/5] alsa-topology-conf: new recipe, version 1.2.1

2020-01-06 Thread Tanu Kaskinen
The topology configuration files were moved from the alsa-lib repository
to a new alsa-topology-conf repository. The move was accompanied by
a license change from LGPL2.1 to BSD-3-Clause.

Signed-off-by: Tanu Kaskinen 
---
 meta/conf/distro/include/maintainers.inc  |  1 +
 .../alsa/alsa-lib_1.2.1.2.bb  |  1 +
 .../alsa/alsa-topology-conf_1.2.1.bb  | 22 +++
 3 files changed, 24 insertions(+)
 create mode 100644 meta/recipes-multimedia/alsa/alsa-topology-conf_1.2.1.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index c9fb373f52..3c07804ce0 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -35,6 +35,7 @@ RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-state = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-tools = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-alsa-topology-conf = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-ucm-conf = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-utils = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Tanu Kaskinen "
diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb 
b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
index 7bc78b8523..e2bc61fbe9 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
@@ -34,6 +34,7 @@ FILES_alsa-conf = "${datadir}/alsa/"
 FILES_libatopology = "${libdir}/libatopology.so.*"
 
 RDEPENDS_${PN}_class-target = "alsa-conf alsa-ucm-conf"
+RDEPENDS_libatopology_class-target = "alsa-topology-conf"
 
 # upgrade path
 RPROVIDES_${PN} = "libasound"
diff --git a/meta/recipes-multimedia/alsa/alsa-topology-conf_1.2.1.bb 
b/meta/recipes-multimedia/alsa/alsa-topology-conf_1.2.1.bb
new file mode 100644
index 00..add1f309ec
--- /dev/null
+++ b/meta/recipes-multimedia/alsa/alsa-topology-conf_1.2.1.bb
@@ -0,0 +1,22 @@
+SUMMARY = "ALSA topology configuration files"
+HOMEPAGE = "https://alsa-project.org;
+BUGTRACKER = "https://alsa-project.org/wiki/Bug_Tracking;
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=20d74d74db9741697903372ad001d3b4"
+
+# The tarball doesn't have any toplevel directory. The subdir option tells
+# Bitbake to unpack the archive to the correct place.
+SRC_URI = 
"https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2;subdir=${BP};
+SRC_URI[md5sum] = "7fdf5fff3f1e0603456e719f6033e922"
+SRC_URI[sha256sum] = 
"354a43f4031c98bef1349ac722d83b2603ef439f81a1ab1eba8814c28243a9b2"
+
+inherit allarch
+
+do_install() {
+install -d ${D}/usr/share/alsa
+cp -r ${S}/topology ${D}/usr/share/alsa
+}
+
+PACKAGES = "${PN}"
+
+FILES_${PN} = "*"
-- 
2.20.1

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


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

2020-01-06 Thread Tanu Kaskinen
v2: rebased on current master

Tanu Kaskinen (5):
  alsa-lib: 1.1.9 -> 1.2.1.2
  alsa-ucm-conf: new recipe, version 1.2.1.2
  alsa-topology-conf: new recipe, version 1.2.1
  alsa-utils: 1.1.9 -> 1.2.1
  alsa-plugins: 1.1.9 -> 1.2.1

 meta/conf/distro/include/maintainers.inc  |2 +
 ...-alsa-sound-.h-for-external-programs.patch | 7104 +
 ...ac-remove-an-unnecessary-libtool-fix.patch |   50 +
 ...api-Move-typedefs-from-uapi-to-sound.patch |  137 +
 ...ncmp-to-avoid-access-out-of-boundary.patch |   41 +
 ...s-at-least-NULL-if-no-list-is-availa.patch |   45 +
 ...0003-namehint-correct-the-args-check.patch |   34 +
 ...-the-previous-patch-check-the-return.patch |   31 +
 ...to-parse-configs-on-cards-with-an-em.patch |   86 +
 ...{alsa-lib_1.1.9.bb => alsa-lib_1.2.1.2.bb} |   21 +-
 ...plugins_1.1.9.bb => alsa-plugins_1.2.1.bb} |4 +-
 .../alsa/alsa-topology-conf_1.2.1.bb  |   22 +
 .../alsa/alsa-ucm-conf_1.2.1.2.bb |   23 +
 ...s_1.1.9.bb => alsa-utils-scripts_1.2.1.bb} |0
 ...lsa-utils_1.1.9.bb => alsa-utils_1.2.1.bb} |7 +-
 15 files changed, 7596 insertions(+), 11 deletions(-)
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0001-Fix-alsa-sound-.h-for-external-programs.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0001-configure.ac-remove-an-unnecessary-libtool-fix.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0001-uapi-Move-typedefs-from-uapi-to-sound.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0001-ucm-Use-strncmp-to-avoid-access-out-of-boundary.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0002-ucm-return-always-at-least-NULL-if-no-list-is-availa.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0003-namehint-correct-the-args-check.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0004-namehint-improve-the-previous-patch-check-the-return.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0005-ucm-Do-not-fail-to-parse-configs-on-cards-with-an-em.patch
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.9.bb => alsa-lib_1.2.1.2.bb} 
(51%)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.9.bb => 
alsa-plugins_1.2.1.bb} (98%)
 create mode 100644 meta/recipes-multimedia/alsa/alsa-topology-conf_1.2.1.bb
 create mode 100644 meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.9.bb => 
alsa-utils-scripts_1.2.1.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.9.bb => 
alsa-utils_1.2.1.bb} (97%)

-- 
2.20.1

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


[OE-core] [PATCH 4/5] alsa-utils: 1.1.9 -> 1.2.1

2020-01-06 Thread Tanu Kaskinen
I moved the ALLOW_EMPTY line next to the line that sets FILES to "".
That makes it easier to see that the package is not only allowed to be
empty, but forced to be empty.

Signed-off-by: Tanu Kaskinen 
---
 ...-utils-scripts_1.1.9.bb => alsa-utils-scripts_1.2.1.bb} | 0
 .../alsa/{alsa-utils_1.1.9.bb => alsa-utils_1.2.1.bb}  | 7 +++
 2 files changed, 3 insertions(+), 4 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.9.bb => 
alsa-utils-scripts_1.2.1.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.9.bb => 
alsa-utils_1.2.1.bb} (97%)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.9.bb 
b/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.2.1.bb
similarity index 100%
rename from meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.9.bb
rename to meta/recipes-multimedia/alsa/alsa-utils-scripts_1.2.1.bb
diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.2.1.bb
similarity index 97%
rename from meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb
rename to meta/recipes-multimedia/alsa/alsa-utils_1.2.1.bb
index 03b5c8de30..81b1154de9 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.9.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.2.1.bb
@@ -21,8 +21,8 @@ PACKAGECONFIG[manpages] = "--enable-xmlto, --disable-xmlto, 
xmlto-native docbook
 
 # alsa-utils specified in SRC_URI due to alsa-utils-scripts recipe
 SRC_URI = 
"https://www.alsa-project.org/files/pub/utils/alsa-utils-${PV}.tar.bz2;
-SRC_URI[md5sum] = "5ed21c3e296c06046cc986e732f625f6"
-SRC_URI[sha256sum] = 
"5ddf2cbddb4bd1a4a2a6492a09c25898b08c3ad64893c3655be14194cf0a213a"
+SRC_URI[md5sum] = "c4628bae7632937eac2de4cf2a3de82e"
+SRC_URI[sha256sum] = 
"0b110ba71ef41d3009db1bc4dcae0cf79efb99cb5426fa19d0312470560a2c0d"
 
 # On build machines with python-docutils (not python3-docutils !!) installed
 # rst2man (not rst2man.py) is detected and compile fails with
@@ -56,6 +56,7 @@ PACKAGES += "${ALSA_UTILS_PKGS}"
 RDEPENDS_${PN} += "${ALSA_UTILS_PKGS}"
 
 FILES_${PN} = ""
+ALLOW_EMPTY_alsa-utils = "1"
 FILES_alsa-utils-alsabat = "${bindir}/alsabat"
 FILES_alsa-utils-alsatplg= "${bindir}/alsatplg"
 FILES_alsa-utils-aplay   = "${bindir}/aplay ${bindir}/arecord 
${bindir}/axfer"
@@ -88,8 +89,6 @@ SUMMARY_alsa-utils-alsaucm  = "ALSA Use Case Manager"
 
 RRECOMMENDS_alsa-utils-alsactl = "alsa-states"
 
-ALLOW_EMPTY_alsa-utils = "1"
-
 do_install() {
autotools_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 0/5] alsa recipe updates

2020-01-06 Thread Tanu Kaskinen
Tanu Kaskinen (5):
  alsa-lib: 1.1.9 -> 1.2.1.2
  alsa-ucm-conf: new recipe, version 1.2.1.2
  alsa-topology-conf: new recipe, version 1.2.1
  alsa-utils: 1.1.9 -> 1.2.1
  alsa-plugins: 1.1.9 -> 1.2.1

 meta/conf/distro/include/maintainers.inc  |2 +
 ...-alsa-sound-.h-for-external-programs.patch | 7104 +
 ...ac-remove-an-unnecessary-libtool-fix.patch |   50 +
 ...api-Move-typedefs-from-uapi-to-sound.patch |  137 +
 ...ncmp-to-avoid-access-out-of-boundary.patch |   41 +
 ...s-at-least-NULL-if-no-list-is-availa.patch |   45 +
 ...0003-namehint-correct-the-args-check.patch |   34 +
 ...-the-previous-patch-check-the-return.patch |   31 +
 ...to-parse-configs-on-cards-with-an-em.patch |   86 +
 ...{alsa-lib_1.1.9.bb => alsa-lib_1.2.1.2.bb} |   21 +-
 ...plugins_1.1.9.bb => alsa-plugins_1.2.1.bb} |4 +-
 .../alsa/alsa-topology-conf_1.2.1.bb  |   22 +
 .../alsa/alsa-ucm-conf_1.2.1.2.bb |   23 +
 ...s_1.1.9.bb => alsa-utils-scripts_1.2.1.bb} |0
 ...lsa-utils_1.1.9.bb => alsa-utils_1.2.1.bb} |7 +-
 15 files changed, 7596 insertions(+), 11 deletions(-)
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0001-Fix-alsa-sound-.h-for-external-programs.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0001-configure.ac-remove-an-unnecessary-libtool-fix.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0001-uapi-Move-typedefs-from-uapi-to-sound.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0001-ucm-Use-strncmp-to-avoid-access-out-of-boundary.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0002-ucm-return-always-at-least-NULL-if-no-list-is-availa.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0003-namehint-correct-the-args-check.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0004-namehint-improve-the-previous-patch-check-the-return.patch
 create mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0005-ucm-Do-not-fail-to-parse-configs-on-cards-with-an-em.patch
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.9.bb => alsa-lib_1.2.1.2.bb} 
(51%)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.9.bb => 
alsa-plugins_1.2.1.bb} (98%)
 create mode 100644 meta/recipes-multimedia/alsa/alsa-topology-conf_1.2.1.bb
 create mode 100644 meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.9.bb => 
alsa-utils-scripts_1.2.1.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.9.bb => 
alsa-utils_1.2.1.bb} (97%)

-- 
2.20.1

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


[OE-core] [PATCH 2/5] alsa-ucm-conf: new recipe, version 1.2.1.2

2020-01-06 Thread Tanu Kaskinen
The UCM configuration files were moved from the alsa-lib repository to a
new alsa-ucm-conf repository. The move was accompanied by a license
change from LGPL2.1 to BSD-3-Clause.

Signed-off-by: Tanu Kaskinen 
---
 meta/conf/distro/include/maintainers.inc  |  1 +
 .../alsa/alsa-lib_1.2.1.2.bb  |  2 +-
 .../alsa/alsa-ucm-conf_1.2.1.2.bb | 23 +++
 3 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 79404dfbdb..ad9b8776dd 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -35,6 +35,7 @@ RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-state = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-tools = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-alsa-ucm-conf = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-utils = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-apmd = "Anuj Mittal "
diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb 
b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
index 59f23cdb06..c6c4ce420b 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
@@ -33,7 +33,7 @@ FILES_alsa-server = "${bindir}/*"
 FILES_alsa-conf = "${datadir}/alsa/"
 FILES_libatopology = "${libdir}/libatopology.so.*"
 
-RDEPENDS_${PN}_class-target = "alsa-conf"
+RDEPENDS_${PN}_class-target = "alsa-conf alsa-ucm-conf"
 
 # upgrade path
 RPROVIDES_${PN} = "libasound"
diff --git a/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb 
b/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
new file mode 100644
index 00..469d1f7a95
--- /dev/null
+++ b/meta/recipes-multimedia/alsa/alsa-ucm-conf_1.2.1.2.bb
@@ -0,0 +1,23 @@
+SUMMARY = "ALSA Use Case Manager configuration"
+HOMEPAGE = "https://alsa-project.org;
+BUGTRACKER = "https://alsa-project.org/wiki/Bug_Tracking;
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=20d74d74db9741697903372ad001d3b4"
+
+# The tarball doesn't have any toplevel directory. The subdir option tells
+# Bitbake to unpack the archive to the correct place.
+SRC_URI = 
"https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2;subdir=${BP};
+SRC_URI[md5sum] = "b7fa43cfd79df978184a6333766d2a50"
+SRC_URI[sha256sum] = 
"ea8a86875f4cf430d49a662a04a6d6c606c5c9d67e54cb944c4d77b24554062f"
+
+inherit allarch
+
+do_install() {
+install -d ${D}/usr/share/alsa
+cp -r ${S}/ucm ${D}/usr/share/alsa
+cp -r ${S}/ucm2 ${D}/usr/share/alsa
+}
+
+PACKAGES = "${PN}"
+
+FILES_${PN} = "*"
-- 
2.20.1

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


[OE-core] [PATCH 3/5] alsa-topology-conf: new recipe, version 1.2.1

2020-01-06 Thread Tanu Kaskinen
The topology configuration files were moved from the alsa-lib repository
to a new alsa-topology-conf repository. The move was accompanied by
a license change from LGPL2.1 to BSD-3-Clause.

Signed-off-by: Tanu Kaskinen 
---
 meta/conf/distro/include/maintainers.inc  |  1 +
 .../alsa/alsa-lib_1.2.1.2.bb  |  1 +
 .../alsa/alsa-topology-conf_1.2.1.bb  | 22 +++
 3 files changed, 24 insertions(+)
 create mode 100644 meta/recipes-multimedia/alsa/alsa-topology-conf_1.2.1.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index ad9b8776dd..36becec62c 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -35,6 +35,7 @@ RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-state = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-tools = "Tanu Kaskinen "
+RECIPE_MAINTAINER_pn-alsa-topology-conf = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-ucm-conf = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-utils = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Tanu Kaskinen "
diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb 
b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
index c6c4ce420b..2b15e21359 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.2.bb
@@ -34,6 +34,7 @@ FILES_alsa-conf = "${datadir}/alsa/"
 FILES_libatopology = "${libdir}/libatopology.so.*"
 
 RDEPENDS_${PN}_class-target = "alsa-conf alsa-ucm-conf"
+RDEPENDS_libatopology_class-target = "alsa-topology-conf"
 
 # upgrade path
 RPROVIDES_${PN} = "libasound"
diff --git a/meta/recipes-multimedia/alsa/alsa-topology-conf_1.2.1.bb 
b/meta/recipes-multimedia/alsa/alsa-topology-conf_1.2.1.bb
new file mode 100644
index 00..add1f309ec
--- /dev/null
+++ b/meta/recipes-multimedia/alsa/alsa-topology-conf_1.2.1.bb
@@ -0,0 +1,22 @@
+SUMMARY = "ALSA topology configuration files"
+HOMEPAGE = "https://alsa-project.org;
+BUGTRACKER = "https://alsa-project.org/wiki/Bug_Tracking;
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=20d74d74db9741697903372ad001d3b4"
+
+# The tarball doesn't have any toplevel directory. The subdir option tells
+# Bitbake to unpack the archive to the correct place.
+SRC_URI = 
"https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2;subdir=${BP};
+SRC_URI[md5sum] = "7fdf5fff3f1e0603456e719f6033e922"
+SRC_URI[sha256sum] = 
"354a43f4031c98bef1349ac722d83b2603ef439f81a1ab1eba8814c28243a9b2"
+
+inherit allarch
+
+do_install() {
+install -d ${D}/usr/share/alsa
+cp -r ${S}/topology ${D}/usr/share/alsa
+}
+
+PACKAGES = "${PN}"
+
+FILES_${PN} = "*"
-- 
2.20.1

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


[OE-core] [PATCH 5/5] alsa-plugins: 1.1.9 -> 1.2.1

2020-01-06 Thread Tanu Kaskinen
Signed-off-by: Tanu Kaskinen 
---
 .../alsa/{alsa-plugins_1.1.9.bb => alsa-plugins_1.2.1.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.9.bb => 
alsa-plugins_1.2.1.bb} (98%)

diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.9.bb 
b/meta/recipes-multimedia/alsa/alsa-plugins_1.2.1.bb
similarity index 98%
rename from meta/recipes-multimedia/alsa/alsa-plugins_1.1.9.bb
rename to meta/recipes-multimedia/alsa/alsa-plugins_1.2.1.bb
index b94fc5cee3..9882e12763 100644
--- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.9.bb
+++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.2.1.bb
@@ -21,8 +21,8 @@ LIC_FILES_CHKSUM = "\
 "
 
 SRC_URI = "https://www.alsa-project.org/files/pub/plugins/${BP}.tar.bz2;
-SRC_URI[md5sum] = "e0caffbd849c51ed81751378f56cb563"
-SRC_URI[sha256sum] = 
"161772303da521abbbf1d91f63b470c4791392d5728f2192a42d71292078f907"
+SRC_URI[md5sum] = "5b11cd3ec92e5f9190ec378565b529e8"
+SRC_URI[sha256sum] = 
"4d94de7ad41734b8604a652521200bb6554fcf0c2c00fdbd302b1710d76548da"
 
 DEPENDS += "alsa-lib"
 
-- 
2.20.1

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


Re: [OE-core] [PATCH] alsa-lib:upgrade 1.1.9 -> 1.2.1.1

2019-12-04 Thread Tanu Kaskinen
On Wed, 2019-11-20 at 12:16 +0100, Alexander Kanavin wrote:
> On Wed, 20 Nov 2019 at 06:17, Zang Ruochen 
> wrote:
> 
> > +From f419276a716daf8d98846b3df50995e5ac030134 Mon Sep 17 00:00:00 2001
> > +From: Zang Ruochen 
> > +Date: Wed, 20 Nov 2019 11:24:17 +0800
> > +Subject: [PATCH] Fix problem with libtool not found
> > +
> > +Upstream-Status: Inappropriate
> > 
> 
> Why inappropriate? To me this seems like a real problem and should be
> submitted upstream.

I planned to submit this patch to upstream on behalf of Zang, but while
investigating what the root cause for the failure really is, I found
that this really is OE specific.

Upstream for some reason (not documented in the commit message, and the
main point of the commit was something else entirely[1]) added this to
the end of configure.ac:

dnl Taken from https://wiki.debian.org/RpathIssue
case $host in
   *-*-linux-gnu)
   AC_MSG_RESULT([Fixing libtool for -rpath problems.])
   sed < libtool > libtool-2 \
 's/^hardcode_libdir_flag_spec.*$'/'hardcode_libdir_flag_spec=" 
-D__LIBTOOL_IS_A_FOOL__ "/'
   mv libtool-2 libtool
   chmod 755 libtool
 ;;
esac

If I understand the referenced Debian wiki page correctly, this is only
useful if the tarball ships libtool older than 1.5.2 (released 2004-01-
05). That is, this addition seems completely useless to me. Probably
I'm missing something.

The configure script fails, because it tries to modify the libtool
script in the build directory, but the libtool script doesn't exist.
And it doesn't exist, because OE renames it to ${host_alias}-libtool
(e.g. x86_64-oe-linux-libtool).

I'm not sure where the libtool script in the build directory comes
from. Is it copied from the tarball's libtool script, or does it come
from the libtool package? (Bitbake seems to run autoreconf and
libtoolize, if that's relevant.) If the script comes from the libtool
package, then modifying the script in the source directory (like Zang's
patch does) is useless, since that script isn't used at all. If the
tarball's libtool script is used, then Zang's patch still doesn't do
what it's expected to do, because the script modification is the very
last thing the configure script does, and the build directory's libtool
script has already been created by then, so modifying the source
directory's libtool script happens too late.

I'll have to ask upstream if the strange configure.ac addition could be
just removed. If it for some reason won't be removed, then an OE
specific patch is needed. Either configure.ac needs to be modified to
operate on ${host_alias}-libtool, or I can simply remove the libtool
modification part, because OE hasn't needed that in the past, and I
can't see how it would be needed now.

[1] 
https://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=75d393a563efb578c79364a277087c6326267f52;hp=1f37ba2a2b1c07c04de1c368cd4943f712cccfa5

-- 
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] [PATCH] pulseaudio: 12.2 -> 13.0

2019-11-21 Thread Tanu Kaskinen
Release notes:
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/13.0/

Dropped intltool-native from DEPENDS. The .desktop file translations
don't need intltool any more, gettext is enough.

Dropped upstreamed patches:
0001-alsa-Fix-inclusion-of-use-case.h.patch
0001-introduce-a-special-build-flag-to-explicitly-disable.patch

Added a new package: pulseaudio-pa-info. It contains the new pa-info
script.

BlueZ 4 support was removed in this version. That's not visible in the
recipe, but I noticed that the BlueZ 4 modules were still being built in
12.2, since they hadn't been explicitly disabled in the recipe.

Signed-off-by: Tanu Kaskinen 
---
 .../pulseaudio/pulseaudio.inc |  27 ++-
 ...001-alsa-Fix-inclusion-of-use-case.h.patch |  46 -
 ...ial-build-flag-to-explicitly-disable.patch | 161 --
 ...{pulseaudio_12.2.bb => pulseaudio_13.0.bb} |   6 +-
 4 files changed, 26 insertions(+), 214 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-alsa-Fix-inclusion-of-use-case.h.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-introduce-a-special-build-flag-to-explicitly-disable.patch
 rename meta/recipes-multimedia/pulseaudio/{pulseaudio_12.2.bb => 
pulseaudio_13.0.bb} (58%)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index ec51d8b279..4e32b27087 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -56,7 +56,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=0e5cd938de1a7a53ea5adac38cc10c39 \
 
file://src/pulsecore/filter/biquad.h;beginline=1;endline=4;md5=6d46d1365206528a20137355924233c1
 \
 "
 
-DEPENDS = "libatomic-ops libsndfile1 libtool intltool-native"
+DEPENDS = "libatomic-ops libsndfile1 libtool"
 # optional
 DEPENDS += "udev alsa-lib glib-2.0"
 DEPENDS += "speexdsp libxml-parser-perl-native libcap"
@@ -158,12 +158,22 @@ USERADD_PARAM_pulseaudio-server = "--system --home 
/var/run/pulse \
   --no-create-home --shell /bin/false \
   --groups audio,pulse --gid pulse pulse"
 
+PACKAGES =+ "\
+ libpulse \
+ libpulse-mainloop-glib \
+ libpulse-simple \
+ libpulsecommon \
+ libpulsecore \
+ ${PN}-pa-info \
+ ${PN}-server \
+ ${PN}-misc \
+ "
+
 # The console-kit module is included here explicitly so bitbake can map to the
 # RDEPENDS we define for it in this recipe, and thereby ensure that when
 # adding the console-kit module to an image, we also get the necessary
 # consolekit package produced.
-PACKAGES =+ "libpulsecore libpulsecommon libpulse libpulse-simple 
libpulse-mainloop-glib \
- pulseaudio-server pulseaudio-misc 
${@bb.utils.contains('PACKAGECONFIG', 'dbus', 'pulseaudio-module-console-kit', 
'', d)}"
+PACKAGES =+ "${@bb.utils.contains('PACKAGECONFIG', 'dbus', 
'pulseaudio-module-console-kit', '', d)}"
 
 #upgrade path:
 RREPLACES_pulseaudio-server = "libpulse-bin libpulse-conf"
@@ -183,6 +193,7 @@ FILES_libpulse-mainloop-glib = 
"${libdir}/libpulse-mainloop-glib.so.*"
 FILES_${PN}-dev += "${libdir}/pulse-${PV}/modules/*.la ${datadir}/vala 
${libdir}/cmake"   
 FILES_${PN}-conf = "${sysconfdir}"
 FILES_${PN}-bin += "${sysconfdir}/default/volatiles/volatiles.04_pulse"
+FILES_${PN}-pa-info = "${bindir}/pa-info"
 FILES_${PN}-server = "${bindir}/pulseaudio ${bindir}/start-* ${sysconfdir} 
${bindir}/pactl */udev/rules.d/*.rules */*/udev/rules.d/*.rules 
${systemd_user_unitdir}/*"
 
 #SYSTEMD_PACKAGES = "${PN}-server"
@@ -214,6 +225,16 @@ python populate_packages_prepend() {
 do_split_packages(d, plugindir, r'^lib(.*)\.so$', '${PN}-lib-%s', 
'PulseAudio library for %s', extra_depends='', prepend=True)
 }
 
+# pa-info is a bash script that collects information about the audio setup.
+# It's primarily useful for attaching an information dump when reporting bugs.
+RDEPENDS_${PN}-pa-info = "\
+  alsa-utils-amixer \
+  alsa-utils-aplay \
+  alsa-utils-scripts \
+  bash \
+  ${PN}-server \
+  "
+
 RDEPENDS_pulseaudio-server = " \
 pulseaudio-module-filter-apply \
 pulseaudio-module-filter-heuristics \
diff --git 
a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-alsa-Fix-inclusion-of-use-case.h.patch
 
b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-alsa-Fix-inclusion-of-use-case.h.patch
deleted file mode 100644
index 15026a2f83..00
--- 
a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-alsa-Fix-inclusion-of-use-case.h.patch

Re: [OE-core] [PATCH] alsa-lib:upgrade 1.1.9 -> 1.2.1.1

2019-11-20 Thread Tanu Kaskinen
Hi, I'm still around. Yes, the moved UCM conf files need to be
packaged. (And no doubt the topology files too, although that's an area
I understand less well).

-- Tanu


On Wed, 2019-11-20 at 13:10 +0100, Alexander Kanavin wrote:
> If Tanu is still around, he should probably chime in.
> 
> Alex
> 
> On Wed, 20 Nov 2019 at 12:55, Mittal, Anuj  wrote:
> 
> > This version has moved ucm and topology conf files to separate
> > repositories. We should also probably fetch and package those.
> > 
> > 
> > https://github.com/alsa-project/alsa-lib/commit/1f37ba2a2b1c07c04de1c368cd4943f712cccfa5
> > 
> > 
> > https://github.com/alsa-project/alsa-lib/commit/cdc8aacbb57c82a81e3b398f2ede6440d49334a5
> > 
> > Thanks,
> > 
> > Anuj
> > 
> > On Wed, 2019-11-20 at 13:17 +0800, Zang Ruochen wrote:
> > > The following error occurred during the steps of do-configure:
> > > > Fixing libtool for -rpath problems.
> > > > ../alsa-lib-1.2.1.1/configure: line 16567: libtool: No such file or
> > > > directory
> > > > mv: cannot stat 'libtool-2': No such file or directory
> > > > chmod: cannot access 'libtool': No such file or directory
> > > 
> > > add alsa-lib/0001-Fix-problem-with-libtool-not-found.patch to fix it.
> > > 
> > > Signed-off-by: Zang Ruochen 
> > > ---
> > >  ...1-Fix-problem-with-libtool-not-found.patch | 31
> > > +++
> > >  ...{alsa-lib_1.1.9.bb => alsa-lib_1.2.1.1.bb} |  8 +++--
> > >  2 files changed, 36 insertions(+), 3 deletions(-)
> > >  create mode 100644 meta/recipes-multimedia/alsa/alsa-lib/0001-Fix-
> > > problem-with-libtool-not-found.patch
> > >  rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.9.bb => alsa-
> > > lib_1.2.1.1.bb} (83%)
> > > 
> > > diff --git a/meta/recipes-multimedia/alsa/alsa-lib/0001-Fix-problem-
> > > with-libtool-not-found.patch b/meta/recipes-multimedia/alsa/alsa-
> > > lib/0001-Fix-problem-with-libtool-not-found.patch
> > > new file mode 100644
> > > index 00..5fb84cd6f8
> > > --- /dev/null
> > > +++ b/meta/recipes-multimedia/alsa/alsa-lib/0001-Fix-problem-with-
> > > libtool-not-found.patch
> > > @@ -0,0 +1,31 @@
> > > +From f419276a716daf8d98846b3df50995e5ac030134 Mon Sep 17 00:00:00
> > > 2001
> > > +From: Zang Ruochen 
> > > +Date: Wed, 20 Nov 2019 11:24:17 +0800
> > > +Subject: [PATCH] Fix problem with libtool not found
> > > +
> > > +Upstream-Status: Inappropriate
> > > +Signed-off-by: Zang Ruochen 
> > > +---
> > > + configure.ac | 6 +++---
> > > + 1 file changed, 3 insertions(+), 3 deletions(-)
> > > +
> > > +diff --git a/configure.ac b/configure.ac
> > > +index 35eb315..548b9ea 100644
> > > +--- a/configure.ac
> > >  b/configure.ac
> > > +@@ -769,9 +769,9 @@ dnl Taken from
> > > https://wiki.debian.org/RpathIssue
> > > + case $host in
> > > +*-*-linux-gnu)
> > > +AC_MSG_RESULT([Fixing libtool for -rpath problems.])
> > > +-   sed < libtool > libtool-2 \
> > > ++   sed < "$srcdir"/libtool > "$srcdir"/libtool-2 \
> > > +  's/^hardcode_libdir_flag_spec.*$'/'hardcode_libdir_flag_spec="
> > > -D__LIBTOOL_IS_A_FOOL__ "/'
> > > +-   mv libtool-2 libtool
> > > +-   chmod 755 libtool
> > > ++   mv "$srcdir"/libtool-2 "$srcdir"/libtool
> > > ++   chmod 755 "$srcdir"/libtool
> > > +  ;;
> > > + esac
> > > +--
> > > +2.20.1
> > > +
> > > diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.9.bb
> > > b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.1.bb
> > > similarity index 83%
> > > rename from meta/recipes-multimedia/alsa/alsa-lib_1.1.9.bb
> > > rename to meta/recipes-multimedia/alsa/alsa-lib_1.2.1.1.bb
> > > index 2c63ee7522..56544b0d45 100644
> > > --- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.9.bb
> > > +++ b/meta/recipes-multimedia/alsa/alsa-lib_1.2.1.1.bb
> > > @@ -7,9 +7,11 @@ LIC_FILES_CHKSUM = "
> > > file://COPYING;md5=a916467b91076e631dd8edb7424769c7 \
> > >  file://src/socket.c;md5=dd1bc7f44872690224d89c1a
> > > 9806e495;beginline=1;endline=26 \
> > >  "
> > > 
> > > -SRC_URI = "https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2;
> > > -SRC_URI[md5sum] = "e6d429dbdcfaa0f034d907fa6dc3735e"
> > > -SRC_URI[sha256sum] =
> > > "488373aef5396682f3a411a6d064ae0ad196b9c96269d0bb912fbdeec94b994b"
> > > +SRC_URI = "https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2
> > > \
> > > +   file://0001-Fix-problem-with-libtool-not-found.patch \
> > > +  "
> > > +SRC_URI[md5sum] = "1d428f46d6160f5e4bbdd64a2ff34f45"
> > > +SRC_URI[sha256sum] =
> > > "c95ac63c0aad43a6ac457d960569096b0b2ef72dc4e3737e77e3e2de87022cec"
> > > 
> > >  inherit autotools pkgconfig
> > > 
> > > --
> > > 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

Re: [OE-core] [PATCH] pulseaudio: don't include consolekit when systemd is enabled

2019-08-13 Thread Tanu Kaskinen
On Tue, 2019-08-13 at 16:11 +0300, Tanu Kaskinen wrote:
> On Fri, 2019-07-26 at 23:03 +0800, Anuj Mittal wrote:
> > When using systemd, make sure that pulseaudio-server RDEPENDS on
> > module-systemd-login instead of module-console-kit both of which provide
> > the same functionality but for different init systems [1][2].
> > 
> > Even though both modules can co-exist, this helps avoid including
> > consolekit (which has been deprecated) in the images using systemd.
> > 
> > [1] 
> > https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index51h3
> > [2] 
> > https://github.com/pulseaudio/pulseaudio/commit/860d1cf3a76701ade38784822abb24285176227c
> > 
> > Signed-off-by: Anuj Mittal 
> 
> Acked-by: Tanu Kaskinen 

Never mind, this is already in master (I didn't find it initially,
which is why I sent that mail as a ping).

-- 
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] pulseaudio: don't include consolekit when systemd is enabled

2019-08-13 Thread Tanu Kaskinen
On Fri, 2019-07-26 at 23:03 +0800, Anuj Mittal wrote:
> When using systemd, make sure that pulseaudio-server RDEPENDS on
> module-systemd-login instead of module-console-kit both of which provide
> the same functionality but for different init systems [1][2].
> 
> Even though both modules can co-exist, this helps avoid including
> consolekit (which has been deprecated) in the images using systemd.
> 
> [1] 
> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index51h3
> [2] 
> https://github.com/pulseaudio/pulseaudio/commit/860d1cf3a76701ade38784822abb24285176227c
> 
> Signed-off-by: Anuj Mittal 

Acked-by: Tanu Kaskinen 

> ---
>  meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
> b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> index e245be7..ec51d8b 100644
> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> @@ -259,9 +259,12 @@ FILES_${PN}-module-gsettings += 
> "${libexecdir}/pulse/gsettings-helper ${datadir}
>  # modules must be installed when X11 is enabled.
>  RDEPENDS_pulseaudio-server += "\
>  ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '\
> -pulseaudio-module-console-kit \
>  pulseaudio-module-device-manager \
>  pulseaudio-module-x11-cork-request \
>  pulseaudio-module-x11-publish \
>  pulseaudio-module-x11-xsmp \
>  ', '', d)}"
> +
> +RDEPENDS_pulseaudio-server += "${@bb.utils.contains('DISTRO_FEATURES', 
> 'x11', \
> +  bb.utils.contains('DISTRO_FEATURES', 
> 'systemd', 'pulseaudio-module-systemd-login', 
> 'pulseaudio-module-console-kit', d), \
> +  '', d)}"
> -- 
> 2.7.4
> 
-- 
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 V2] alsa-utils: fix multilib names

2019-05-25 Thread Tanu Kaskinen
On Sat, 2019-05-25 at 17:04 +0100, Burton, Ross wrote:
> In related news I've been meaning to gut the alsa-utils recipe as
> that's the last recipe that actually depends on gtk2.

You mean alsa-tools, not alsa-utils, right? I won't object removing
alsa-tools from OE 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 V2] alsa-utils: fix multilib names

2019-05-24 Thread Tanu Kaskinen
On Fri, 2019-05-24 at 18:18 +0100, Richard Purdie wrote:
> On Fri, 2019-05-24 at 15:19 +0200, Ming Liu wrote:
> > Wouldn't that break the alsa-utils-scripts? Since ALSA_UTILS_PKGS is
> > being depended by both alsa-utils and alsa-utils-scripts.
> > 
> > I did that in V1, but as Richard Purdie pointed out, it will break
> > the alsa-utils-scripts build.
> 
> I was about to say we should refactor these recipes and create a common
> inc file.
> 
> Looking at the justification in alsa-utils (avoid a bash dependency),
> that is a runtime issue, not a build time one. We should merge these
> recipes and ensure the packaging remains the same.
> 
> We can then avoid some of these problems, use PN and have a simpler
> recipe. These changes should be done in multiple commits, one per
> change as usual.
> 
> Is there any reason I'm missing not to do this?

I'm not sure if you already found the original commit[1] that
introduced this split. The commit message is:

alsa-utils: Move alsaconf to its own recipe

18575b082a4042376fd1575465e69562dea04ddc added bash as a dependency of
alsa-utils-alsaconf so that the script interpreter will be available at
run time.  However, this has the undesirable side effect of making bash
be a build dependency for alsa-utils and, for those folks who don't need
alsaconf but do want some other part of alsa-utils, this cure is worse
than the original disease.

Fix this by moving alsaconf to a separate recipe so that the bash
dependency only applies when alsaconf is specifically requested.

Signed-off-by: Phil Blundell 
Signed-off-by: Saul Wold 

I can't really judge if that justification makes sense. If the
justification is valid, maybe there's a better solution for avoiding
the build dependency on bash for those people who don't need the
scripts?

[1] 
http://cgit.openembedded.org/openembedded-core/commit/?id=7317c8055cf3af8912a66badb3074f0a60f75ec2

-- 
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 2/3] pulseaudio: disable PIE flags when hardened flags are enabled

2019-04-26 Thread Tanu Kaskinen
On Mon, 2019-04-22 at 14:28 -0600, Khem Raj wrote:
> On Mon, Apr 22, 2019 at 6:33 AM Tanu Kaskinen  wrote:
> 
> > On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote:
> > > On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen  wrote:
> > > > On Fri, 2017-06-09 at 13:07 +, Khem Raj wrote:
> > > > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross 
> > wrote:
> > > > > > On 9 June 2017 at 04:41, Khem Raj  wrote:
> > > > > > 
> > > > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
> > > > > > > 
> > > > > > 
> > > > > > These tend to go into security-flags.inc, not the recipe.
> > > > > > 
> > > > > 
> > > > > I know that's been the case but I think having a global file is
> > error prone
> > > > > its better to have it in recipe context since it can get attention at
> > > > > upgrade time to test if this has been fixed in new release etc
> > > > 
> > > > Do you mean that there's some bug in pulseaudio, and this is a
> > > > workaround for it? Is the bug that there are textrels? Ross saw
> > > > textrels in pulseaudio before (see the discussion starting at [1]), but
> > > > I was unable to reproduce that. If you give instructions for
> > > > reproducing the problem, I'll see if I can fix pulseaudio (until then
> > > > I'm fine with having a workaround).
> > > > 
> > > 
> > > yes there is a bug lurking when compiling with hardening flags are
> > turned on
> > > so you can do something like
> > > 
> > > in local.conf
> > > 
> > > require conf/distro/include/security_flags.inc
> > > 
> > > then
> > > 
> > > MACHINE=qemux86 bitbake pulseaudio
> > > 
> > > it also happens on arm so qemuarm will reproduce it too.
> > > 
> > > some assembly code is probably missing using GOT relative accesses
> > 
> > Resurrecting this ancient thread... I finally tried to reproduce this
> > problem with the given instructions. No success. Have you still been
> > running into this issue?
> 
> I don’t know for sure if this still exists but we did disable assembly in
> few packages which addresses this issue since in assembly PIC has to be
> respected
> In hand written code
> 
> You might have to check if we did something similar for pulseaudio

There seem to be no such changes to the pulseaudio recipe. Some
upstream fix seems unlikely as well. The only possibly relevant change
that I could find was removing a buggy implementation of reading the
cpuid register (the removed code was replaced with the __get_cpuid()
macro that compilers provide in cpuid.h).

Oh well, if the problem reappears, let me know.

-- 
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 2/3] pulseaudio: disable PIE flags when hardened flags are enabled

2019-04-22 Thread Tanu Kaskinen
On Fri, 2017-06-09 at 10:10 -0700, Khem Raj wrote:
> On Fri, Jun 9, 2017 at 9:38 AM, Tanu Kaskinen  wrote:
> > On Fri, 2017-06-09 at 13:07 +, Khem Raj wrote:
> > > On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross  wrote:
> > > 
> > > > On 9 June 2017 at 04:41, Khem Raj  wrote:
> > > > 
> > > > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
> > > > > 
> > > > 
> > > > These tend to go into security-flags.inc, not the recipe.
> > > > 
> > > 
> > > I know that's been the case but I think having a global file is error 
> > > prone
> > > its better to have it in recipe context since it can get attention at
> > > upgrade time to test if this has been fixed in new release etc
> > 
> > Do you mean that there's some bug in pulseaudio, and this is a
> > workaround for it? Is the bug that there are textrels? Ross saw
> > textrels in pulseaudio before (see the discussion starting at [1]), but
> > I was unable to reproduce that. If you give instructions for
> > reproducing the problem, I'll see if I can fix pulseaudio (until then
> > I'm fine with having a workaround).
> > 
> 
> yes there is a bug lurking when compiling with hardening flags are turned on
> so you can do something like
> 
> in local.conf
> 
> require conf/distro/include/security_flags.inc
> 
> then
> 
> MACHINE=qemux86 bitbake pulseaudio
> 
> it also happens on arm so qemuarm will reproduce it too.
> 
> some assembly code is probably missing using GOT relative accesses

Resurrecting this ancient thread... I finally tried to reproduce this
problem with the given instructions. No success. Have you still been
running into this issue?

-- 
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] [PATCH] alsa-tools: 1.1.6 -> 1.1.7

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

The two patches have now been upstreamed. Apart from those changes, the
only thing that changed was the hwmixvolume tool, which got ported from
PyGTK to PyGObject, and from GTK 2 to GTK 3.

When testing hwmixvolume, I found that it depends on pyalsa, which has
not been packaged for OE. I believe hwmixvolume has never worked on OE.
It certainly didn't work before this patch, trying to build it failed
due to python-pygtk not being available. Even if python-pygtk was
available at some point in the past, hwmixvolume has always used pyalsa,
but the alsa-tools recipe has never had that dependency declared.

Signed-off-by: Tanu Kaskinen 
---
 ...served-user-defined-literal-warnings.patch | 34 --
 .../alsa/alsa-tools/musl.patch| 47 ---
 ...lsa-tools_1.1.6.bb => alsa-tools_1.1.7.bb} | 14 +++---
 3 files changed, 7 insertions(+), 88 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
 delete mode 100644 meta/recipes-multimedia/alsa/alsa-tools/musl.patch
 rename meta/recipes-multimedia/alsa/{alsa-tools_1.1.6.bb => 
alsa-tools_1.1.7.bb} (90%)

diff --git 
a/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
 
b/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
deleted file mode 100644
index c137bc8a28..00
--- 
a/meta/recipes-multimedia/alsa/alsa-tools/0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-Upstream-Status: Backport
-Signed-off-by: Khem Raj 
-
-From a861bdabf02cd9bfb3ec7c0571c563c0fa14adfb Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Tue, 24 Apr 2018 12:24:32 -0700
-Subject: [PATCH] us428control: Fix clang -Wreserved-user-defined-literal
- warnings
-
-| us428control.cc:66:18: error: invalid suffix on literal; C++11 requires a 
space between literal and identifier [-Wreserved-user-defined-literal]
-| printf("usage: "PROGNAME" [-v verbosity_level 0..2] [-c card] [-D 
device] [-u usb-device] [-m mode]\n");
-| ^
-
-Signed-off-by: Khem Raj 
-Signed-off-by: Takashi Iwai 

- us428control/us428control.cc | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/us428control/us428control.cc b/us428control/us428control.cc
-index e839bf4..8cb3c42 100644
 a/us428control/us428control.cc
-+++ b/us428control/us428control.cc
-@@ -63,7 +63,7 @@ static void usage(void)
- {
-   printf("Tascam US-428 Control\n");
-   printf("version %s\n", VERSION);
--  printf("usage: "PROGNAME" [-v verbosity_level 0..2] [-c card] [-D 
device] [-u usb-device] [-m mode]\n");
-+  printf("usage: " PROGNAME " [-v verbosity_level 0..2] [-c card] [-D 
device] [-u usb-device] [-m mode]\n");
-   printf("mode is one of (us224, us428, mixxx)\n");
- }
- /*
--- 
-1.7.11.7
diff --git a/meta/recipes-multimedia/alsa/alsa-tools/musl.patch 
b/meta/recipes-multimedia/alsa/alsa-tools/musl.patch
deleted file mode 100644
index 9eb129c379..00
--- a/meta/recipes-multimedia/alsa/alsa-tools/musl.patch
+++ /dev/null
@@ -1,47 +0,0 @@
-Upstream-Status: Backport
-Signed-off-by: Ross Burton 
-
-From 235d9c5e8381518b0a8661786e7e0cbdd1bbcd01 Mon Sep 17 00:00:00 2001
-From: Ross Burton 
-Date: Tue, 12 Jun 2018 13:24:34 +0100
-Subject: [PATCH] ld10k1: define _GNU_SOURCE and use sighandler_t
-
-__sighandler_t is a glibc internal type which doesn't exist in musl.  By using
-AC_USE_SYSTEM_EXTENSIONS to get _GNU_SOURCE defined, both glibc and musl
-then expose sighandler_t.
-
-Signed-off-by: Ross Burton 
-Signed-off-by: Takashi Iwai 

- ld10k1/configure.ac  | 1 +
- ld10k1/src/ld10k1_fnc1.c | 2 +-
- 2 files changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/ld10k1/configure.ac b/ld10k1/configure.ac
-index 276b24e..f48ca31 100644
 a/ld10k1/configure.ac
-+++ b/ld10k1/configure.ac
-@@ -4,6 +4,7 @@ AC_CONFIG_MACRO_DIR([m4])
- AM_MAINTAINER_MODE([enable])
- 
- AC_CONFIG_HEADERS(config.h)
-+AC_USE_SYSTEM_EXTENSIONS
- AC_PROG_CC
- AC_PROG_LD
- AC_PROG_INSTALL
-diff --git a/ld10k1/src/ld10k1_fnc1.c b/ld10k1/src/ld10k1_fnc1.c
-index 343584c..ddc43c6 100644
 a/ld10k1/src/ld10k1_fnc1.c
-+++ b/ld10k1/src/ld10k1_fnc1.c
-@@ -179,7 +179,7 @@ int main_loop(comm_param *param, int audigy, const char 
*card_id, int tram_size,
- {
-   fd_set active_fd_set/*, read_fd_set*/;
-   int i, j, res = 0;
--  __sighandler_t old_sig_pipe;
-+  sighandler_t old_sig_pipe;
- 
-   int main_sock = 0;
-   int data_sock = 0;
--- 
-2.11.0
-
diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-tools_1.1.7.bb
similarity index 90%
rename from meta/recipes-multimedia/alsa/alsa-tools_1.1.6.bb
rename to meta/re

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

2019-02-22 Thread Tanu Kaskinen
On Fri, 2019-02-22 at 07:01 -0800, Khem Raj wrote:
> On Thu, Feb 21, 2019 at 10:33 AM Alexander Kanavin
>  wrote:
> > 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
> 
> seeing this fetch issue building alsa-utils-scripts
> 
> ERROR: Fetcher failure for URL:
> 'https://www.alsa-project.org/files/pub/utils/alsa-utils-scripts-1.1.8.tar.bz2'.
> Unable to fetch URL from any source.

Fixed in master-next:
http://cgit.openembedded.org/openembedded-core/commit/?h=master-next=865147cdfff8dd2762aa9ccf4672aacec0a8040f

-- 
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 v2 0/3] alsa recipe updates

2019-02-22 Thread Tanu Kaskinen
On Thu, 2019-02-21 at 21:28 +0100, Alexander Kanavin wrote:
> 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?

Yes, you're right. I didn't get your point the first time you requested
this, sorry...

-- 
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] [PATCH] alsa-tools: use a better SRC_URI

2019-02-22 Thread Tanu Kaskinen
The ftp server has been flaky recently.

Signed-off-by: Tanu Kaskinen 
---
 meta/recipes-multimedia/alsa/alsa-tools_1.1.6.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.1.6.bb 
b/meta/recipes-multimedia/alsa/alsa-tools_1.1.6.bb
index 90e54dbb14..0662b5a78d 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.1.6.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.1.6.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = 
"file://hdsploader/COPYING;md5=59530bdf33659b29e73d4adb9f9f65
 
file://ld10k1/COPYING.LIB;md5=a916467b91076e631dd8edb7424769c7 \
 "
 
-SRC_URI = "ftp://ftp.alsa-project.org/pub/tools/${BP}.tar.bz2 \
+SRC_URI = "https://www.alsa-project.org/files/pub/tools/${BP}.tar.bz2 \
file://0002-Fix-clang-Wreserved-user-defined-literal-warnings.patch 
\
file://musl.patch \
"
-- 
2.20.1

-- 
___
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 fil

[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}/a

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 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] [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
+# 

Re: [OE-core] [PATCH 1/2] pulseaudio: improve reproducibility

2018-12-05 Thread Tanu Kaskinen
On Wed, 2018-12-05 at 10:11 +0800, Hongxu Jia wrote:
> Remove build host paths from generated binaries, the modification
> is harmless for build time compiling and runtime executing.
> 
> [YOCTO #12638]
> 
> Signed-off-by: Hongxu Jia 
> ---
>  .../pulseaudio/0001-improve-reproducibility.patch  | 50 
> ++
>  .../pulseaudio/pulseaudio_12.2.bb  |  1 +
>  2 files changed, 51 insertions(+)
>  create mode 100644 
> meta/recipes-multimedia/pulseaudio/pulseaudio/0001-improve-reproducibility.patch
> 
> diff --git 
> a/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-improve-reproducibility.patch
>  
> b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-improve-reproducibility.patch
> new file mode 100644
> index 000..b13adb2
> --- /dev/null
> +++ 
> b/meta/recipes-multimedia/pulseaudio/pulseaudio/0001-improve-reproducibility.patch
> @@ -0,0 +1,50 @@
> +From e03d1d77471ee16c149590dd97085cf54be1e261 Mon Sep 17 00:00:00 2001
> +From: Hongxu Jia 
> +Date: Tue, 4 Dec 2018 16:29:18 +0800
> +Subject: [PATCH] improve reproducibility
> +
> +- Do not define PA_CFLAGS with $CFLAGS which contains build host path,
> +  macro PA_CFLAGS is used for debug log, the modification is harmless;
> +
> +- Tweak definition of PA_BUILDDIR and PA_SRCDIR with relative directory,
> +  it is also harmless;

I believe changing PA_BUILDDIR and PA_SRCDIR to relative directories
actually breaks the things that use those definitions. PA_BUILDDIR is
compared to the /proc/self/exe symlink target, which is an absolute
path. The definitions are needed when running PulseAudio from the
source tree without installing, so the breakage doesn't really matter
in OE, but it would be better to set them to values that clearly don't
work rather than something that looks like is intended to work but
actually doesn't.

-- 
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] [PATCH] pulseaudio: 11.1 -> 12.2

2018-08-27 Thread Tanu Kaskinen
Release notes for 12.0:
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/12.0/

12.1 contains a few regression fixes:
https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030259.html

12.2 is just a fixup for the configure script brokenness in the 12.1 tarball.

qpaeq changed license from AGPL to LGPL, so now there's no AGPL licensed
code any more. This removes the excuse to not enable fftw support (i.e.
module-equalizer-sink and qpaeq). I'll enable fftw in a separate patch.

There's a new gsettings module that should be enabled, but I'll do
that in a separate patch. It's not particularly important, because the
module is only used by the paprefs GUI application that doesn't seem to
be packaged for OE at the moment.

Removed upstreamed patches:
0001-padsp-Make-it-compile-on-musl.patch
0001-memfd-wrappers-only-define-memfd_create-if-not-alrea.patch

License-Update: qpaeq changed license from AGPL to LGPL:
https://gitlab.freedesktop.org/pulseaudio/pulseaudio/commit/61217528a1cb5043ca3fa1051a73ad3268cfb3d8

Signed-off-by: Tanu Kaskinen 
---

According to the Yocto project status emails, YP 2.6 M3 Build Target is
today. If I recall correctly, that's the cutoff point for version
upgrades, so this patch may be late. If so, I apologize for dropping the
ball as a recipe maintainer. I can resend after 2.6 is out.

 .../pulseaudio/pulseaudio.inc | 15 ++--
 ...nly-define-memfd_create-if-not-alrea.patch | 66 -
 .../0001-padsp-Make-it-compile-on-musl.patch  | 70 ---
 ...{pulseaudio_11.1.bb => pulseaudio_12.2.bb} |  6 +-
 4 files changed, 7 insertions(+), 150 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-memfd-wrappers-only-define-memfd_create-if-not-alrea.patch
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/0001-padsp-Make-it-compile-on-musl.patch
 rename meta/recipes-multimedia/pulseaudio/{pulseaudio_11.1.bb => 
pulseaudio_12.2.bb} (53%)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 8189a569e1..f526690390 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -16,9 +16,6 @@ SECTION = "libs/multimedia"
 # The src/pulsecore/filter/ directory contains code under the 3-clause BSD
 # license.
 #
-# src/utils/qpaeq is licensed under AGPL. qpaeq is not installed by this
-# recipe, however, which is why AGPL is not mentioned in LICENSE.
-#
 # People who distribute PulseAudio binaries need to also consider that there
 # are some dependencies to GPL libraries. LGPL code that depends on GPL
 # libraries probably becomes effectively GPL-licensed (at compile-time? or at
@@ -47,16 +44,14 @@ SECTION = "libs/multimedia"
 # section 3, and therefore libdbus's GPL license doesn't affect PulseAudio.
 LICENSE = "LGPLv2.1+ & MIT & BSD-3-Clause"
 
-LIC_FILES_CHKSUM = "file://LICENSE;md5=a848e8d03f04976778eab2348b59ed2b \
+LIC_FILES_CHKSUM = "file://LICENSE;md5=0e5cd938de1a7a53ea5adac38cc10c39 \
 file://GPL;md5=4325afd396febcb659c36b49533135d4 \
 file://LGPL;md5=2d5025d4aa3495befef8f17206a5b0a1 \
-file://AGPL;md5=73f1eb20517c55bf9493b7dd6e480788 \
 
file://src/modules/echo-cancel/adrian-license.txt;md5=abbab006a561fbffccedf1c3531f34ab
 \
 
file://src/pulsecore/filter/LICENSE.WEBKIT;md5=49defbaffddf8c51faf606ff7fc3b1f7 
\
 
file://src/pulsecore/resampler.h;beginline=4;endline=21;md5=09794012ae16912c0270f3280cc8ff84
 \
 
file://src/modules/reserve.h;beginline=6;endline=28;md5=0e23094760367d51b6609750e9b31fbb
 \
 
file://src/pulsecore/rtkit.h;beginline=6;endline=29;md5=3f00ff966716ae0817c31576d1473528
 \
-
file://src/utils/qpaeq;beginline=2;endline=16;md5=7f62515a4762f0c3fc3d4201858bb964
 \
 
file://src/modules/echo-cancel/adrian-aec.h;beginline=3;endline=12;md5=d3ed4fad1c073f8b06f37495dc5d1026
 \
 
file://src/pulsecore/filter/biquad.h;beginline=1;endline=4;md5=6d46d1365206528a20137355924233c1
 \
 "
@@ -93,10 +88,6 @@ EXTRA_OECONF += "--without-soxr"
 # ddbd713293 without explaining why it was not made a PACKAGECONFIG item
 # instead. Oh well, let's keep it disabled until someone expresses some
 # interest in having it enabled.
-#
-# One nice thing about disabling this is that it also prevents qpaeq from
-# being installed, so we avoid adding AGPL to the list of licenses (nothing
-# else in PulseAudio is licensed under AGPL).
 EXTRA_OECONF += "--without-fftw"
 
 # The "adrian" echo canceller implementation has a non-standard license
@@ -106,6 +97,10 @@ EXTRA_OECONF += "--without-fftw"
 # very good anyway, better alternatives exist (such as the webrtc canceller

Re: [OE-core] [PATCH] alsa-lib: Allow empty alsa-lib package for SDK

2018-08-03 Thread Tanu Kaskinen
On Thu, 2018-08-02 at 16:22 -0500, Joshua Watt wrote:
> Without ALLOW_EMPTY, the empty alsa-lib package (which gets culled)
> makes it fairly difficult to create an image that has libasound, then
> create an SDK from that image that has the proper development files.
> 
> If there is no alsa-lib package, the only way to get libasound on a
> target image is to do:
> 
>  IMAGE_INSTALL += "libasound"
> 
> This however causes a problem because all of the development files that
> would be desired in the SDK are located in alsa-lib-dev, which won't be
> included (because alsa-lib wasn't included). Without ALLOW_EMPTY_${PN},
> it is not possible to do:
> 
>  IMAGE_INSTALL += "alsa-lib"
> 
> because the package is empty and gets culled. Adding the ALLOW_EMPTY and
> then making alsa-lib RDEPEND on libasound solves this problem and allows
> alsa-lib to be installed on the target and have the correct development
> files in the SDK
> 
> Signed-off-by: Joshua Watt 
> ---
>  meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb 
> b/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb
> index 6364e9eafaa..581655c5349 100644
> --- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb
> +++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb
> @@ -24,6 +24,13 @@ FILES_libasound = "${libdir}/libasound.so.*"
>  FILES_alsa-server = "${bindir}/*"
>  FILES_alsa-conf = "${datadir}/alsa/"
>  
> +# Create an alsa-lib package even though it is empty and make it RDEPEND on
> +# libasound for target builds. This makes it possible to sanely create a 
> image
> +# that has libasound and then generate an SDK from that image that has
> +# alsa-lib-dev
> +ALLOW_EMPTY_${PN} = "1"
> +RDEPENDS_${PN}_class-target = "libasound"
> +
>  RDEPENDS_libasound = "alsa-conf"
>  
>  # alsa-lib gets automatically added to alsa-lib-dev dependencies, but the

Looks fine to me, although renaming alsa-lib-dev to libasound-dev would
seem like a sensible option too.

-- 
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] [PATCH 3/3] alsa-utils: 1.1.5 -> 1.1.6

2018-05-22 Thread Tanu Kaskinen
Dropped 0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch,
because an equivalent patch is included in the new release.

License-Update: FSF address updated

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 ...s_1.1.5.bb => alsa-utils-scripts_1.1.6.bb} |  0
 ...t-systemd-unit-restore-the-volume-wh.patch | 56 ---
 ...lsa-utils_1.1.5.bb => alsa-utils_1.1.6.bb} |  7 +--
 3 files changed, 3 insertions(+), 60 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.5.bb => 
alsa-utils-scripts_1.1.6.bb} (100%)
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-utils/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.5.bb => 
alsa-utils_1.1.6.bb} (94%)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.5.bb 
b/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.6.bb
similarity index 100%
rename from meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.5.bb
rename to meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.6.bb
diff --git 
a/meta/recipes-multimedia/alsa/alsa-utils/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
 
b/meta/recipes-multimedia/alsa/alsa-utils/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
deleted file mode 100644
index 907ca5ce0e..00
--- 
a/meta/recipes-multimedia/alsa/alsa-utils/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From b9d41b784657152a4c5683a9458dffab557f0689 Mon Sep 17 00:00:00 2001
-From: Koen Kooi <k...@dominion.thruhere.net>
-Date: Fri, 29 Aug 2014 18:58:56 +0300
-Subject: [PATCH] alsactl: don't let systemd unit restore the volume when
- asound.state is missing
-
-This avoids an error on bootup
-
-Filed as https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5459
-
-Upstream-Status: Pending
-
-Signed-off-by: Koen Kooi <k...@dominion.thruhere.net>
-Signed-off-by: Cristian Iorga <cristian.io...@intel.com>
-
-Rebased on 1.1.0.
-
-Signed-off-by: Tanu Kaskinen <ta...@iki.fi>

- alsactl/Makefile.am | 7 ---
- alsactl/alsa-restore.service.in | 1 +
- 2 files changed, 5 insertions(+), 3 deletions(-)
-
-diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am
-index 90fab9d..190525a 100644
 a/alsactl/Makefile.am
-+++ b/alsactl/Makefile.am
-@@ -38,9 +38,10 @@ install-data-hook:
- endif
- 
- edit = \
--  $(SED) -r -e 's,@sbindir\@,$(sbindir),g' \
---e 's,@mydatadir\@,$(mydatadir),g' \
---e 's,@daemonswitch\@,$(ALSACTL_DAEMONSWITCH),g' \
-+  $(SED) -e 's,@localstatedir\@,$(localstatedir),g' \
-+ -e 's,@sbindir\@,$(sbindir),g' \
-+ -e 's,@mydatadir\@,$(mydatadir),g' \
-+ -e 's,@daemonswitch\@,$(ALSACTL_DAEMONSWITCH),g' \
-   < $< > $@ || rm $@
- 
- alsa-state.service: alsa-state.service.in
-diff --git a/alsactl/alsa-restore.service.in b/alsactl/alsa-restore.service.in
-index 80fd5fd..6beb36d 100644
 a/alsactl/alsa-restore.service.in
-+++ b/alsactl/alsa-restore.service.in
-@@ -7,6 +7,7 @@
- Description=Save/Restore Sound Card State
- ConditionPathExists=!@daemonswitch@
- ConditionPathExistsGlob=/dev/snd/control*
-+ConditionPathExists=@localstatedir@/lib/alsa/asound.state
- 
- [Service]
- Type=oneshot
--- 
-2.14.2
-
diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.5.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb
similarity index 94%
rename from meta/recipes-multimedia/alsa/alsa-utils_1.1.5.bb
rename to meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb
index 33215bf159..b8ba0cb22a 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.5.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb
@@ -4,7 +4,7 @@ BUGTRACKER = 
"http://alsa-project.org/main/index.php/Bug_Tracking;
 SECTION = "console/utils"
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
-
file://alsactl/utils.c;beginline=1;endline=20;md5=fe9526b055e246b5558809a5ae25c0b9"
+
file://alsactl/utils.c;beginline=1;endline=20;md5=2ce7f7b6739487fb72c689d46521f958"
 DEPENDS = "alsa-lib ncurses libsamplerate0"
 
 PACKAGECONFIG ??= "udev"
@@ -20,11 +20,10 @@ PACKAGECONFIG[udev] = "--with-udev-rules-dir=`pkg-config 
--variable=udevdir 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 \
-   
file://0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch \
   "
 
-SRC_URI[md5sum] = "dfe6ea147a5e07a056919591c2f5dac3"
-SRC_URI[sha256sum] = 
"320bd285e91db6e7fd7db3c9ec6f55b02f35449ff273c7844780ac6a5a3de2e8"
+SRC_URI[md5sum] = "50ae75

[OE-core] [PATCH 0/3] libvorbis and alsa recipe upgrades

2018-05-22 Thread Tanu Kaskinen
Tanu Kaskinen (3):
  libvorbis: 1.3.5 -> 1.3.6
  alsa-plugins: 1.1.5 -> 1.1.6
  alsa-utils: 1.1.5 -> 1.1.6

 ...plugins_1.1.5.bb => alsa-plugins_1.1.6.bb} |   8 +-
 ...s_1.1.5.bb => alsa-utils-scripts_1.1.6.bb} |   0
 ...t-systemd-unit-restore-the-volume-wh.patch |  56 --
 ...lsa-utils_1.1.5.bb => alsa-utils_1.1.6.bb} |   7 +-
 .../0001-configure-Check-for-clang.patch  |  20 ++--
 .../libvorbis/libvorbis/CVE-2017-14632.patch  |  62 ---
 .../libvorbis/libvorbis/CVE-2017-14633.patch  |  42 
 .../libvorbis/libvorbis/CVE-2018-5146.patch   | 100 --
 ...{libvorbis_1.3.5.bb => libvorbis_1.3.6.bb} |   9 +-
 9 files changed, 20 insertions(+), 284 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.5.bb => 
alsa-plugins_1.1.6.bb} (94%)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.5.bb => 
alsa-utils-scripts_1.1.6.bb} (100%)
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-utils/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.5.bb => 
alsa-utils_1.1.6.bb} (94%)
 delete mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
 delete mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
 delete mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch
 rename meta/recipes-multimedia/libvorbis/{libvorbis_1.3.5.bb => 
libvorbis_1.3.6.bb} (64%)

-- 
2.17.0

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


[OE-core] [PATCH 1/3] libvorbis: 1.3.5 -> 1.3.6

2018-05-22 Thread Tanu Kaskinen
Rebased 0001-configure-Check-for-clang.patch.

Removed the backported CVE patches.

License-Update: copyright years refreshed

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../0001-configure-Check-for-clang.patch  |  20 ++--
 .../libvorbis/libvorbis/CVE-2017-14632.patch  |  62 ---
 .../libvorbis/libvorbis/CVE-2017-14633.patch  |  42 
 .../libvorbis/libvorbis/CVE-2018-5146.patch   | 100 --
 ...{libvorbis_1.3.5.bb => libvorbis_1.3.6.bb} |   9 +-
 5 files changed, 13 insertions(+), 220 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
 delete mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
 delete mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch
 rename meta/recipes-multimedia/libvorbis/{libvorbis_1.3.5.bb => 
libvorbis_1.3.6.bb} (64%)

diff --git 
a/meta/recipes-multimedia/libvorbis/libvorbis/0001-configure-Check-for-clang.patch
 
b/meta/recipes-multimedia/libvorbis/libvorbis/0001-configure-Check-for-clang.patch
index 7dad0cd8a5..b06029b98b 100644
--- 
a/meta/recipes-multimedia/libvorbis/libvorbis/0001-configure-Check-for-clang.patch
+++ 
b/meta/recipes-multimedia/libvorbis/libvorbis/0001-configure-Check-for-clang.patch
@@ -1,4 +1,4 @@
-From 44b4511784f9b51c514dff4ceb3cbeaf9c374d08 Mon Sep 17 00:00:00 2001
+From d619ccf6c11ab574466914c57994a82fb99401af Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.k...@gmail.com>
 Date: Wed, 22 Mar 2017 16:06:55 +
 Subject: [PATCH] configure: Check for clang
@@ -13,12 +13,12 @@ Upstream-Status: Pending
  1 file changed, 17 insertions(+), 2 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index eddd02d..00ecba5 100644
+index 28b0a14..2d4e984 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -93,6 +93,16 @@ AC_ARG_ENABLE(examples,
-   
- AM_CONDITIONAL(BUILD_EXAMPLES, [test "x$enable_examples" = xyes]) 
+@@ -98,6 +98,16 @@ AC_ARG_ENABLE(examples,
+ 
+ AM_CONDITIONAL(BUILD_EXAMPLES, [test "x$enable_examples" = xyes])
  
 +AC_MSG_CHECKING([whether C compiler is clang])
 +$CC -x c /dev/null -dM -E > conftest.txt 2>&1
@@ -33,9 +33,9 @@ index eddd02d..00ecba5 100644
  dnl --
  dnl Set build flags based on environment
  dnl --
-@@ -127,10 +137,15 @@ else
+@@ -132,10 +142,15 @@ else
AC_MSG_RESULT([$GCC_VERSION])
-   case $host in 
+   case $host in
*86-*-linux*)
 +  if test "$CC_CLANG" = "1"; then
 +  ieeefp=""
@@ -43,8 +43,8 @@ index eddd02d..00ecba5 100644
 +  ieefp="-mno-ieee-fp"
 +  fi
DEBUG="-g -Wall -Wextra -D_REENTRANT -D__NO_MATH_INLINES 
-fsigned-char"
--  CFLAGS="-O3 -ffast-math -mno-ieee-fp -D_REENTRANT -fsigned-char"
-+  CFLAGS="-O3 -ffast-math -D_REENTRANT -fsigned-char ${ieefp}"
+-  CFLAGS="-O3 -Wall -Wextra -ffast-math -mno-ieee-fp -D_REENTRANT 
-fsigned-char"
++  CFLAGS="-O3 -Wall -Wextra -ffast-math -D_REENTRANT 
-fsigned-char ${ieefp}"
  # PROFILE="-Wall -Wextra -pg -g -O3 -ffast-math 
-D_REENTRANT -fsigned-char -fno-inline -static"
 -  PROFILE="-Wall -Wextra -pg -g -O3 -ffast-math -mno-ieee-fp 
-D_REENTRANT -fsigned-char -fno-inline"
 +  PROFILE="-Wall -Wextra -pg -g -O3 -ffast-math ${ieefp} 
-D_REENTRANT -fsigned-char -fno-inline"
@@ -52,5 +52,5 @@ index eddd02d..00ecba5 100644
# glibc < 2.1.3 has a serious FP bug in the math inline header
# that will cripple Vorbis.  Look to see if the magic FP stack
 -- 
-1.8.3.1
+2.17.0
 
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
deleted file mode 100644
index 4036b966fe..00
--- a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-From 39704ce16835e5c019bb03f6a94dc1f0677406c5 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Guido=20G=C3=BCnther?= <a...@sigxcpu.org>
-Date: Wed, 15 Nov 2017 18:22:59 +0100
-Subject: [PATCH] CVE-2017-14632: vorbis_analysis_header_out: Don't clear opb
- if not initialized
-
-If the number of channels is not within the allowed range
-we call oggback_writeclear altough it's not initialized yet.
-
-This fixes
-
-=23371== Invalid free() / delete / delete[] / realloc()
-==23371==at 0x4C2CE1B: free (vg_replace_malloc.c:530)
-==23371==by 0x829CA31: oggpack_writeclear (in 
/usr/lib/x86_64-linux-gnu/libogg.so.0.8.2)
-==23371==by 0x84B96EE: vorbis_analysis_headerout (info.c:652)
-==23371==by 0x9FBCBCC: ??? (in 
/usr/lib/x86_64-linux-gnu/sox/libsox_fmt_vorbis.so)

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

2018-05-22 Thread Tanu Kaskinen
License-Update: FSF address updated

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../alsa/{alsa-plugins_1.1.5.bb => alsa-plugins_1.1.6.bb} | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.5.bb => 
alsa-plugins_1.1.6.bb} (94%)

diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.5.bb 
b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
similarity index 94%
rename from meta/recipes-multimedia/alsa/alsa-plugins_1.1.5.bb
rename to meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
index 4bd0acc54f..17c1879f95 100644
--- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.5.bb
+++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb
@@ -14,15 +14,15 @@ SECTION = "multimedia"
 # of LGPLv2.1 like the rest of the plugins.
 LICENSE = "LGPLv2.1 & GPLv2+"
 LIC_FILES_CHKSUM = "\
-file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34 \
-file://COPYING.GPL;md5=94d55d512a9ba36caa9b7df079bae19f \
+file://COPYING;md5=a916467b91076e631dd8edb7424769c7 \
+file://COPYING.GPL;md5=59530bdf33659b29e73d4adb9f9f6552 \
 
file://m4/attributes.m4;endline=33;md5=b25958da44c02231e3641f1bccef53eb \
 
file://rate/rate_samplerate.c;endline=35;md5=fd77bce85f4a338c0e8ab18430b69fae \
 "
 
 SRC_URI = "ftp://ftp.alsa-project.org/pub/plugins/${BP}.tar.bz2;
-SRC_URI[md5sum] = "f898b0e6e8acf3f6f82bc2a0f0c84a97"
-SRC_URI[sha256sum] = 
"797da5f8f53379fbea28817bc466de16affd2c07849e84f1af8d5e22f7bb7f1c"
+SRC_URI[md5sum] = "8387279e99feeb2ecffaac5f293223d7"
+SRC_URI[sha256sum] = 
"6f1d31ebe3b1fa1cc8dade60b7bed1cb2583ac998167002d350dc0a5e3e40c13"
 
 DEPENDS += "alsa-lib"
 
-- 
2.17.0

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


Re: [OE-core] [PATCH] alsa-utils: Fix error when removing unwanted udev rules

2018-05-01 Thread Tanu Kaskinen
On Tue, 2018-05-01 at 12:36 +0100, Mike Crowe wrote:
> If alsa-utils configure is not passed a --with-udev-rules-dir option then
> it defaults to using /lib/udev/rules.d. This meant that the hard-coded use
> of ${D}/lib in do_install in 262e69c9c7acf0beb7bb6b96299e3c993c906434
> worked correctly to remove the unwanted rules.
> 
> Subsequently, 0a4372705a030ca54ed420cdfec33d46ab93499c changed do_install
> to use ${nonarch_base_libdir}, claiming to fix this in the usrmerge case.
> 
> This means that if udev is not present in PACKAGECONFIG and usrmerge is
> present in DISTRO_FEATURES then the alsa-utils build system will install
> the rules in ${D}/lib/udev/rules.d but do_install will attempt to remove
> ${D}/usr/lib, resulting in something like:
> 
>  rmdir: failed to remove 
> '.../tmp-glibc/work/i586-oe-linux/alsa-utils/1.1.5-r0/image/usr/lib': No such 
> file or directory
> 
> To fix this, let's just tell configure to install the rules in a specific
> known location when udev is disabled. This location can then easily be
> cleaned up in do_install.
> 
> Tested both with and without usrmerge in DISTRO_FEATURES.
> 
> Signed-off-by: Mike Crowe 
> Cc: Phil Blundell 
> Cc: Peter Kjellerstedt 
> ---
>  meta/recipes-multimedia/alsa/alsa-utils_1.1.5.bb | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Looks good to me.

-- 
Tanu

https://liberapay.com/tanuk
https://www.patreon.com/tanuk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [morty][PATCH 3/3] libvorbis: CVE-2018-5146

2018-03-30 Thread Tanu Kaskinen
Prevent out-of-bounds write in codebook decoding. The bug could allow
code execution from a specially crafted Ogg Vorbis file.

References:
https://www.debian.org/security/2018/dsa-4140
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../libvorbis/libvorbis/CVE-2018-5146.patch| 100 +
 .../libvorbis/libvorbis_1.3.5.bb   |   1 +
 2 files changed, 101 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch

diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch
new file mode 100644
index 00..6d4052a872
--- /dev/null
+++ b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch
@@ -0,0 +1,100 @@
+From 3a017f591457bf6e80231b563bf83ee583fdbca8 Mon Sep 17 00:00:00 2001
+From: Thomas Daede <daede...@umn.edu>
+Date: Thu, 15 Mar 2018 14:15:31 -0700
+Subject: [PATCH] CVE-2018-5146: Prevent out-of-bounds write in codebook
+ decoding.
+
+Codebooks that are not an exact divisor of the partition size are now
+truncated to fit within the partition.
+
+Upstream-Status: Backport
+CVE: CVE-2018-5146
+
+Reference to upstream patch:
+https://git.xiph.org/?p=vorbis.git;a=commitdiff;h=667ceb4aab60c1f74060143bb24e5f427b3cce5f
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ lib/codebook.c | 48 ++--
+ 1 file changed, 10 insertions(+), 38 deletions(-)
+
+diff --git a/lib/codebook.c b/lib/codebook.c
+index 8b766e8..7022fd2 100644
+--- a/lib/codebook.c
 b/lib/codebook.c
+@@ -387,7 +387,7 @@ long vorbis_book_decodevs_add(codebook *book,float 
*a,oggpack_buffer *b,int n){
+   t[i] = book->valuelist+entry[i]*book->dim;
+ }
+ for(i=0,o=0;idim;i++,o+=step)
+-  for (j=0;j<step;j++)
++  for (j=0;o+jdim>8){
+-  for(i=0;i<n;){
+-entry = decode_packed_entry_number(book,b);
+-if(entry==-1)return(-1);
+-t = book->valuelist+entry*book->dim;
+-for (j=0;jdim;)
+-  a[i++]+=t[j++];
+-  }
+-}else{
+-  for(i=0;i<n;){
+-entry = decode_packed_entry_number(book,b);
+-if(entry==-1)return(-1);
+-t = book->valuelist+entry*book->dim;
+-j=0;
+-switch((int)book->dim){
+-case 8:
+-  a[i++]+=t[j++];
+-case 7:
+-  a[i++]+=t[j++];
+-case 6:
+-  a[i++]+=t[j++];
+-case 5:
+-  a[i++]+=t[j++];
+-case 4:
+-  a[i++]+=t[j++];
+-case 3:
+-  a[i++]+=t[j++];
+-case 2:
+-  a[i++]+=t[j++];
+-case 1:
+-  a[i++]+=t[j++];
+-case 0:
+-  break;
+-}
+-  }
++for(i=0;i<n;){
++  entry = decode_packed_entry_number(book,b);
++  if(entry==-1)return(-1);
++  t = book->valuelist+entry*book->dim;
++  for(j=0;idim;)
++a[i++]+=t[j++];
+ }
+   }
+   return(0);
+@@ -471,12 +442,13 @@ long vorbis_book_decodevv_add(codebook *book,float 
**a,long offset,int ch,
+   long i,j,entry;
+   int chptr=0;
+   if(book->used_entries>0){
+-for(i=offset/ch;i<(offset+n)/ch;){
++int m=(offset+n)/ch;
++for(i=offset/ch;i<m;){
+   entry = decode_packed_entry_number(book,b);
+   if(entry==-1)return(-1);
+   {
+ const float *t = book->valuelist+entry*book->dim;
+-for (j=0;jdim;j++){
++for (j=0;idim;j++){
+   a[chptr++][i]+=t[j];
+   if(chptr==ch){
+ chptr=0;
+-- 
+2.16.2
+
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb 
b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
index 11e1de7223..bd2321f1d6 100644
--- a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
+++ b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
@@ -13,6 +13,7 @@ DEPENDS = "libogg"
 SRC_URI = "http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz \
file://CVE-2017-14633.patch \
file://CVE-2017-14632.patch \
+   file://CVE-2018-5146.patch \
   "
 SRC_URI[md5sum] = "28cb28097c07a735d6af56e598e1c90f"
 SRC_URI[sha256sum] = 
"54f94a9527ff0a88477be0a71c0bab09a4c3febe0ed878b24824906cd4b0e1d1"
-- 
2.16.2

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


[OE-core] [morty][PATCH 0/3] libvorbis security fixes

2018-03-30 Thread Tanu Kaskinen
Here are some libvorbis CVE fixes cherry-picked from master. The bugs
affect at least rocko, pyro and morty, I haven't checked older stable
branches. I don't know in which libvorbis version the bugs were
introduced.

These patches apply to morty. I have sent the rocko and pyro patches
separately.

Tanu Kaskinen (3):
  libvorbis: CVE-2017-14633
  libvorbis: CVE-2017-14632
  libvorbis: CVE-2018-5146

 .../libvorbis/libvorbis/CVE-2017-14632.patch   |  62 +
 .../libvorbis/libvorbis/CVE-2017-14633.patch   |  42 +
 .../libvorbis/libvorbis/CVE-2018-5146.patch| 100 +
 .../libvorbis/libvorbis_1.3.5.bb   |   6 +-
 4 files changed, 209 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch

-- 
2.16.2

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


[OE-core] [morty][PATCH 2/3] libvorbis: CVE-2017-14632

2018-03-30 Thread Tanu Kaskinen
Xiph.Org libvorbis 1.3.5 allows Remote Code Execution upon freeing
uninitialized memory in the function vorbis_analysis_headerout() in
info.c when vi->channels<=0, a similar issue to Mozilla bug 550184.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14632

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../libvorbis/libvorbis/CVE-2017-14632.patch   | 62 ++
 .../libvorbis/libvorbis_1.3.5.bb   |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch

diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
new file mode 100644
index 00..4036b966fe
--- /dev/null
+++ b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
@@ -0,0 +1,62 @@
+From 39704ce16835e5c019bb03f6a94dc1f0677406c5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Guido=20G=C3=BCnther?= <a...@sigxcpu.org>
+Date: Wed, 15 Nov 2017 18:22:59 +0100
+Subject: [PATCH] CVE-2017-14632: vorbis_analysis_header_out: Don't clear opb
+ if not initialized
+
+If the number of channels is not within the allowed range
+we call oggback_writeclear altough it's not initialized yet.
+
+This fixes
+
+=23371== Invalid free() / delete / delete[] / realloc()
+==23371==at 0x4C2CE1B: free (vg_replace_malloc.c:530)
+==23371==by 0x829CA31: oggpack_writeclear (in 
/usr/lib/x86_64-linux-gnu/libogg.so.0.8.2)
+==23371==by 0x84B96EE: vorbis_analysis_headerout (info.c:652)
+==23371==by 0x9FBCBCC: ??? (in 
/usr/lib/x86_64-linux-gnu/sox/libsox_fmt_vorbis.so)
+==23371==by 0x4E524F1: ??? (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x4E52CCA: sox_open_write (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x10D82A: open_output_file (sox.c:1556)
+==23371==by 0x10D82A: process (sox.c:1753)
+==23371==by 0x10D82A: main (sox.c:3012)
+==23371==  Address 0x68768c8 is 488 bytes inside a block of size 880 
alloc'd
+==23371==at 0x4C2BB1F: malloc (vg_replace_malloc.c:298)
+==23371==by 0x4C2DE9F: realloc (vg_replace_malloc.c:785)
+==23371==by 0x4E545C2: lsx_realloc (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x9FBC9A0: ??? (in 
/usr/lib/x86_64-linux-gnu/sox/libsox_fmt_vorbis.so)
+==23371==by 0x4E524F1: ??? (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x4E52CCA: sox_open_write (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x10D82A: open_output_file (sox.c:1556)
+==23371==by 0x10D82A: process (sox.c:1753)
+==23371==by 0x10D82A: main (sox.c:3012)
+
+as seen when using the testcase from CVE-2017-11333 with
+008d23b782be09c8d75ba8190b1794abd66c7121 applied. However the error was
+there before.
+
+Upstream-Status: Backport
+CVE: CVE-2017-14632
+
+Reference to upstream patch:
+https://git.xiph.org/?p=vorbis.git;a=commitdiff;h=c1c2831fc7306d5fbd7bc800324efd12b28d327f
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ lib/info.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/lib/info.c b/lib/info.c
+index 81b7557..4d82568 100644
+--- a/lib/info.c
 b/lib/info.c
+@@ -584,6 +584,7 @@ int vorbis_analysis_headerout(vorbis_dsp_state *v,
+   private_state *b=v->backend_state;
+ 
+   if(!b||vi->channels<=0||vi->channels>256){
++b = NULL;
+ ret=OV_EFAULT;
+ goto err_out;
+   }
+-- 
+2.16.2
+
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb 
b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
index 75c2038800..11e1de7223 100644
--- a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
+++ b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
@@ -12,6 +12,7 @@ DEPENDS = "libogg"
 
 SRC_URI = "http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz \
file://CVE-2017-14633.patch \
+   file://CVE-2017-14632.patch \
   "
 SRC_URI[md5sum] = "28cb28097c07a735d6af56e598e1c90f"
 SRC_URI[sha256sum] = 
"54f94a9527ff0a88477be0a71c0bab09a4c3febe0ed878b24824906cd4b0e1d1"
-- 
2.16.2

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


[OE-core] [morty][PATCH 1/3] libvorbis: CVE-2017-14633

2018-03-30 Thread Tanu Kaskinen
In Xiph.Org libvorbis 1.3.5, an out-of-bounds array read vulnerability
exists in the function mapping0_forward() in mapping0.c, which may lead
to DoS when operating on a crafted audio file with vorbis_analysis().

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14633

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../libvorbis/libvorbis/CVE-2017-14633.patch   | 42 ++
 .../libvorbis/libvorbis_1.3.5.bb   |  4 ++-
 2 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch

diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
new file mode 100644
index 00..9c9e688d43
--- /dev/null
+++ b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
@@ -0,0 +1,42 @@
+From 07eda55f336e5c44dfc0e4a1e21628faed7255fa Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Guido=20G=C3=BCnther?= <a...@sigxcpu.org>
+Date: Tue, 31 Oct 2017 18:32:46 +0100
+Subject: [PATCH] CVE-2017-14633: Don't allow for more than 256 channels
+
+Otherwise
+
+ for(i=0;ichannels;i++){
+  /* the encoder setup assumes that all the modes used by any
+ specific bitrate tweaking use the same floor */
+  int submap=info->chmuxlist[i];
+
+overreads later in mapping0_forward since chmuxlist is a fixed array of
+256 elements max.
+
+Upstream-Status: Backport
+CVE: CVE-2017-14633
+
+Reference to upstream patch:
+https://git.xiph.org/?p=vorbis.git;a=commitdiff;h=667ceb4aab60c1f74060143bb24e5f427b3cce5f
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ lib/info.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/info.c b/lib/info.c
+index e447a0c..81b7557 100644
+--- a/lib/info.c
 b/lib/info.c
+@@ -583,7 +583,7 @@ int vorbis_analysis_headerout(vorbis_dsp_state *v,
+   oggpack_buffer opb;
+   private_state *b=v->backend_state;
+ 
+-  if(!b||vi->channels<=0){
++  if(!b||vi->channels<=0||vi->channels>256){
+ ret=OV_EFAULT;
+ goto err_out;
+   }
+-- 
+2.16.2
+
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb 
b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
index 636e0f307b..75c2038800 100644
--- a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
+++ b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
@@ -10,7 +10,9 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=7d2c487d2fc7dd3e3c7c465a5b7f6217 \
 
file://include/vorbis/vorbisenc.h;beginline=1;endline=11;md5=d1c1d138863d6315131193d4046d81cb"
 DEPENDS = "libogg"
 
-SRC_URI = "http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz;
+SRC_URI = "http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz \
+   file://CVE-2017-14633.patch \
+  "
 SRC_URI[md5sum] = "28cb28097c07a735d6af56e598e1c90f"
 SRC_URI[sha256sum] = 
"54f94a9527ff0a88477be0a71c0bab09a4c3febe0ed878b24824906cd4b0e1d1"
 
-- 
2.16.2

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


[OE-core] [rocko][pyro][PATCH 3/3] libvorbis: CVE-2018-5146

2018-03-30 Thread Tanu Kaskinen
Prevent out-of-bounds write in codebook decoding. The bug could allow
code execution from a specially crafted Ogg Vorbis file.

References:
https://www.debian.org/security/2018/dsa-4140
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../libvorbis/libvorbis/CVE-2018-5146.patch| 100 +
 .../libvorbis/libvorbis_1.3.5.bb   |   1 +
 2 files changed, 101 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch

diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch
new file mode 100644
index 00..6d4052a872
--- /dev/null
+++ b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch
@@ -0,0 +1,100 @@
+From 3a017f591457bf6e80231b563bf83ee583fdbca8 Mon Sep 17 00:00:00 2001
+From: Thomas Daede <daede...@umn.edu>
+Date: Thu, 15 Mar 2018 14:15:31 -0700
+Subject: [PATCH] CVE-2018-5146: Prevent out-of-bounds write in codebook
+ decoding.
+
+Codebooks that are not an exact divisor of the partition size are now
+truncated to fit within the partition.
+
+Upstream-Status: Backport
+CVE: CVE-2018-5146
+
+Reference to upstream patch:
+https://git.xiph.org/?p=vorbis.git;a=commitdiff;h=667ceb4aab60c1f74060143bb24e5f427b3cce5f
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ lib/codebook.c | 48 ++--
+ 1 file changed, 10 insertions(+), 38 deletions(-)
+
+diff --git a/lib/codebook.c b/lib/codebook.c
+index 8b766e8..7022fd2 100644
+--- a/lib/codebook.c
 b/lib/codebook.c
+@@ -387,7 +387,7 @@ long vorbis_book_decodevs_add(codebook *book,float 
*a,oggpack_buffer *b,int n){
+   t[i] = book->valuelist+entry[i]*book->dim;
+ }
+ for(i=0,o=0;idim;i++,o+=step)
+-  for (j=0;j<step;j++)
++  for (j=0;o+jdim>8){
+-  for(i=0;i<n;){
+-entry = decode_packed_entry_number(book,b);
+-if(entry==-1)return(-1);
+-t = book->valuelist+entry*book->dim;
+-for (j=0;jdim;)
+-  a[i++]+=t[j++];
+-  }
+-}else{
+-  for(i=0;i<n;){
+-entry = decode_packed_entry_number(book,b);
+-if(entry==-1)return(-1);
+-t = book->valuelist+entry*book->dim;
+-j=0;
+-switch((int)book->dim){
+-case 8:
+-  a[i++]+=t[j++];
+-case 7:
+-  a[i++]+=t[j++];
+-case 6:
+-  a[i++]+=t[j++];
+-case 5:
+-  a[i++]+=t[j++];
+-case 4:
+-  a[i++]+=t[j++];
+-case 3:
+-  a[i++]+=t[j++];
+-case 2:
+-  a[i++]+=t[j++];
+-case 1:
+-  a[i++]+=t[j++];
+-case 0:
+-  break;
+-}
+-  }
++for(i=0;i<n;){
++  entry = decode_packed_entry_number(book,b);
++  if(entry==-1)return(-1);
++  t = book->valuelist+entry*book->dim;
++  for(j=0;idim;)
++a[i++]+=t[j++];
+ }
+   }
+   return(0);
+@@ -471,12 +442,13 @@ long vorbis_book_decodevv_add(codebook *book,float 
**a,long offset,int ch,
+   long i,j,entry;
+   int chptr=0;
+   if(book->used_entries>0){
+-for(i=offset/ch;i<(offset+n)/ch;){
++int m=(offset+n)/ch;
++for(i=offset/ch;i<m;){
+   entry = decode_packed_entry_number(book,b);
+   if(entry==-1)return(-1);
+   {
+ const float *t = book->valuelist+entry*book->dim;
+-for (j=0;jdim;j++){
++for (j=0;idim;j++){
+   a[chptr++][i]+=t[j];
+   if(chptr==ch){
+ chptr=0;
+-- 
+2.16.2
+
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb 
b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
index 32e92f009a..20f887c252 100644
--- a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
+++ b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
@@ -14,6 +14,7 @@ SRC_URI = 
"http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz \
file://0001-configure-Check-for-clang.patch \
file://CVE-2017-14633.patch \
file://CVE-2017-14632.patch \
+   file://CVE-2018-5146.patch \
   "
 SRC_URI[md5sum] = "28cb28097c07a735d6af56e598e1c90f"
 SRC_URI[sha256sum] = 
"54f94a9527ff0a88477be0a71c0bab09a4c3febe0ed878b24824906cd4b0e1d1"
-- 
2.16.2

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


[OE-core] [rocko][pyro][PATCH 1/3] libvorbis: CVE-2017-14633

2018-03-30 Thread Tanu Kaskinen
In Xiph.Org libvorbis 1.3.5, an out-of-bounds array read vulnerability
exists in the function mapping0_forward() in mapping0.c, which may lead
to DoS when operating on a crafted audio file with vorbis_analysis().

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14633

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../libvorbis/libvorbis/CVE-2017-14633.patch   | 42 ++
 .../libvorbis/libvorbis_1.3.5.bb   |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch

diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
new file mode 100644
index 00..9c9e688d43
--- /dev/null
+++ b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
@@ -0,0 +1,42 @@
+From 07eda55f336e5c44dfc0e4a1e21628faed7255fa Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Guido=20G=C3=BCnther?= <a...@sigxcpu.org>
+Date: Tue, 31 Oct 2017 18:32:46 +0100
+Subject: [PATCH] CVE-2017-14633: Don't allow for more than 256 channels
+
+Otherwise
+
+ for(i=0;ichannels;i++){
+  /* the encoder setup assumes that all the modes used by any
+ specific bitrate tweaking use the same floor */
+  int submap=info->chmuxlist[i];
+
+overreads later in mapping0_forward since chmuxlist is a fixed array of
+256 elements max.
+
+Upstream-Status: Backport
+CVE: CVE-2017-14633
+
+Reference to upstream patch:
+https://git.xiph.org/?p=vorbis.git;a=commitdiff;h=667ceb4aab60c1f74060143bb24e5f427b3cce5f
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ lib/info.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/info.c b/lib/info.c
+index e447a0c..81b7557 100644
+--- a/lib/info.c
 b/lib/info.c
+@@ -583,7 +583,7 @@ int vorbis_analysis_headerout(vorbis_dsp_state *v,
+   oggpack_buffer opb;
+   private_state *b=v->backend_state;
+ 
+-  if(!b||vi->channels<=0){
++  if(!b||vi->channels<=0||vi->channels>256){
+ ret=OV_EFAULT;
+ goto err_out;
+   }
+-- 
+2.16.2
+
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb 
b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
index 56c5b0a9cb..73f9d1af2c 100644
--- a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
+++ b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
@@ -12,6 +12,7 @@ DEPENDS = "libogg"
 
 SRC_URI = "http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz \
file://0001-configure-Check-for-clang.patch \
+   file://CVE-2017-14633.patch \
   "
 SRC_URI[md5sum] = "28cb28097c07a735d6af56e598e1c90f"
 SRC_URI[sha256sum] = 
"54f94a9527ff0a88477be0a71c0bab09a4c3febe0ed878b24824906cd4b0e1d1"
-- 
2.16.2

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


[OE-core] [rocko][pyro][PATCH 2/3] libvorbis: CVE-2017-14632

2018-03-30 Thread Tanu Kaskinen
Xiph.Org libvorbis 1.3.5 allows Remote Code Execution upon freeing
uninitialized memory in the function vorbis_analysis_headerout() in
info.c when vi->channels<=0, a similar issue to Mozilla bug 550184.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14632

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../libvorbis/libvorbis/CVE-2017-14632.patch   | 62 ++
 .../libvorbis/libvorbis_1.3.5.bb   |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch

diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
new file mode 100644
index 00..4036b966fe
--- /dev/null
+++ b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
@@ -0,0 +1,62 @@
+From 39704ce16835e5c019bb03f6a94dc1f0677406c5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Guido=20G=C3=BCnther?= <a...@sigxcpu.org>
+Date: Wed, 15 Nov 2017 18:22:59 +0100
+Subject: [PATCH] CVE-2017-14632: vorbis_analysis_header_out: Don't clear opb
+ if not initialized
+
+If the number of channels is not within the allowed range
+we call oggback_writeclear altough it's not initialized yet.
+
+This fixes
+
+=23371== Invalid free() / delete / delete[] / realloc()
+==23371==at 0x4C2CE1B: free (vg_replace_malloc.c:530)
+==23371==by 0x829CA31: oggpack_writeclear (in 
/usr/lib/x86_64-linux-gnu/libogg.so.0.8.2)
+==23371==by 0x84B96EE: vorbis_analysis_headerout (info.c:652)
+==23371==by 0x9FBCBCC: ??? (in 
/usr/lib/x86_64-linux-gnu/sox/libsox_fmt_vorbis.so)
+==23371==by 0x4E524F1: ??? (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x4E52CCA: sox_open_write (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x10D82A: open_output_file (sox.c:1556)
+==23371==by 0x10D82A: process (sox.c:1753)
+==23371==by 0x10D82A: main (sox.c:3012)
+==23371==  Address 0x68768c8 is 488 bytes inside a block of size 880 
alloc'd
+==23371==at 0x4C2BB1F: malloc (vg_replace_malloc.c:298)
+==23371==by 0x4C2DE9F: realloc (vg_replace_malloc.c:785)
+==23371==by 0x4E545C2: lsx_realloc (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x9FBC9A0: ??? (in 
/usr/lib/x86_64-linux-gnu/sox/libsox_fmt_vorbis.so)
+==23371==by 0x4E524F1: ??? (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x4E52CCA: sox_open_write (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x10D82A: open_output_file (sox.c:1556)
+==23371==by 0x10D82A: process (sox.c:1753)
+==23371==by 0x10D82A: main (sox.c:3012)
+
+as seen when using the testcase from CVE-2017-11333 with
+008d23b782be09c8d75ba8190b1794abd66c7121 applied. However the error was
+there before.
+
+Upstream-Status: Backport
+CVE: CVE-2017-14632
+
+Reference to upstream patch:
+https://git.xiph.org/?p=vorbis.git;a=commitdiff;h=c1c2831fc7306d5fbd7bc800324efd12b28d327f
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ lib/info.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/lib/info.c b/lib/info.c
+index 81b7557..4d82568 100644
+--- a/lib/info.c
 b/lib/info.c
+@@ -584,6 +584,7 @@ int vorbis_analysis_headerout(vorbis_dsp_state *v,
+   private_state *b=v->backend_state;
+ 
+   if(!b||vi->channels<=0||vi->channels>256){
++b = NULL;
+ ret=OV_EFAULT;
+ goto err_out;
+   }
+-- 
+2.16.2
+
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb 
b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
index 73f9d1af2c..32e92f009a 100644
--- a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
+++ b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
@@ -13,6 +13,7 @@ DEPENDS = "libogg"
 SRC_URI = "http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz \
file://0001-configure-Check-for-clang.patch \
file://CVE-2017-14633.patch \
+   file://CVE-2017-14632.patch \
   "
 SRC_URI[md5sum] = "28cb28097c07a735d6af56e598e1c90f"
 SRC_URI[sha256sum] = 
"54f94a9527ff0a88477be0a71c0bab09a4c3febe0ed878b24824906cd4b0e1d1"
-- 
2.16.2

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


[OE-core] [rocko][pyro][PATCH 0/3] libvorbis security fixes

2018-03-30 Thread Tanu Kaskinen
Here are some libvorbis CVE fixes cherry-picked from master. The bugs
affect at least rocko, pyro and morty, I haven't checked older stable
branches. I don't know in which libvorbis version the bugs were
introduced.

These patches apply to rocko and pyro. The patches don't apply cleanly
to morty, so I'll send the morty patches separately.

Tanu Kaskinen (3):
  libvorbis: CVE-2017-14633
  libvorbis: CVE-2017-14632
  libvorbis: CVE-2018-5146

 .../libvorbis/libvorbis/CVE-2017-14632.patch   |  62 +
 .../libvorbis/libvorbis/CVE-2017-14633.patch   |  42 +
 .../libvorbis/libvorbis/CVE-2018-5146.patch| 100 +
 .../libvorbis/libvorbis_1.3.5.bb   |   3 +
 4 files changed, 207 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch

-- 
2.16.2

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


[OE-core] [morty][PATCH] e2fsprogs: fix compatibility with glibc 2.27

2018-03-21 Thread Tanu Kaskinen
glibc 2.27 added function copy_file_range(), and e2fsprogs happens to
have a different function with the same name. The conflict made
e2fsprogs-native build fail.

Here's a backport of a fix from upstream, the fix was released in
e2fsprogs 1.43.8.

The master branch doesn't need this fix, since it has new enough
e2fsprogs version. At least rocko, pyro and morty need this, I haven't
checked older stable branches. Apparently the problematic function was
introduced in e2fsprogs version 1.43.

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 ...rename-copy_file_range-to-copy_file_chunk.patch | 62 ++
 meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.bb  |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 
meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch

diff --git 
a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch
 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch
new file mode 100644
index 00..276432c1a3
--- /dev/null
+++ 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch
@@ -0,0 +1,62 @@
+From 10e2247f7b4692e80d185bb65ea641585bdc6b4d Mon Sep 17 00:00:00 2001
+From: Palmer Dabbelt <pal...@dabbelt.com>
+Date: Fri, 29 Dec 2017 10:19:51 -0800
+Subject: [PATCH] misc: rename copy_file_range to copy_file_chunk
+
+As of 2.27, glibc will have a copy_file_range library call to wrap the
+new copy_file_range system call.  This conflicts with the function in
+misc/create_inode.c, which this patch renames _copy_file_range.
+
+Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
+Signed-off-by: Theodore Ts'o <ty...@mit.edu>
+
+Upstream-Status: Backport
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ misc/create_inode.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/misc/create_inode.c b/misc/create_inode.c
+index c879a3ec..6acf0e20 100644
+--- a/misc/create_inode.c
 b/misc/create_inode.c
+@@ -392,7 +392,7 @@ static ssize_t my_pread(int fd, void *buf, size_t count, 
off_t offset)
+ }
+ #endif /* !defined HAVE_PREAD64 && !defined HAVE_PREAD */
+ 
+-static errcode_t copy_file_range(ext2_filsys fs, int fd, ext2_file_t e2_file,
++static errcode_t copy_file_chunk(ext2_filsys fs, int fd, ext2_file_t e2_file,
+off_t start, off_t end, char *buf,
+char *zerobuf)
+ {
+@@ -466,7 +466,7 @@ static errcode_t try_lseek_copy(ext2_filsys fs, int fd, 
struct stat *statbuf,
+ 
+   data_blk = data & ~(fs->blocksize - 1);
+   hole_blk = (hole + (fs->blocksize - 1)) & ~(fs->blocksize - 1);
+-  err = copy_file_range(fs, fd, e2_file, data_blk, hole_blk, buf,
++  err = copy_file_chunk(fs, fd, e2_file, data_blk, hole_blk, buf,
+ zerobuf);
+   if (err)
+   return err;
+@@ -518,7 +518,7 @@ static errcode_t try_fiemap_copy(ext2_filsys fs, int fd, 
ext2_file_t e2_file,
+   }
+   for (i = 0, ext = ext_buf; i < fiemap_buf->fm_mapped_extents;
+i++, ext++) {
+-  err = copy_file_range(fs, fd, e2_file, ext->fe_logical,
++  err = copy_file_chunk(fs, fd, e2_file, ext->fe_logical,
+ ext->fe_logical + ext->fe_length,
+ buf, zerobuf);
+   if (err)
+@@ -569,7 +569,7 @@ static errcode_t copy_file(ext2_filsys fs, int fd, struct 
stat *statbuf,
+   if (err != EXT2_ET_UNIMPLEMENTED)
+   goto out;
+ 
+-  err = copy_file_range(fs, fd, e2_file, 0, statbuf->st_size, buf,
++  err = copy_file_chunk(fs, fd, e2_file, 0, statbuf->st_size, buf,
+ zerobuf);
+ out:
+   ext2fs_free_mem();
+-- 
+2.16.2
+
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.bb 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.bb
index dcfb564a4b..4eadc3eab4 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.bb
@@ -11,6 +11,7 @@ SRC_URI += "file://acinclude.m4 \
 file://Revert-mke2fs-enable-the-metadata_csum-and-64bit-fea.patch \
 file://mkdir_p.patch \
 
file://0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch \
+file://0001-misc-rename-copy_file_range-to-copy_file_chunk.patch \
 "
 
 SRC_URI_append_class-native = " 
file://e2fsprogs-fix-missing-check-for-permission-denied.patch"
-- 
2.16.2

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


[OE-core] [pyro][PATCH] e2fsprogs: fix compatibility with glibc 2.27

2018-03-21 Thread Tanu Kaskinen
glibc 2.27 added function copy_file_range(), and e2fsprogs happens to
have a different function with the same name. The conflict made
e2fsprogs-native build fail.

Here's a backport of a fix from upstream, the fix was released in
e2fsprogs 1.43.8.

The master branch doesn't need this fix, since it has new enough
e2fsprogs version. At least rocko, pyro and morty need this, I haven't
checked older stable branches. Apparently the problematic function was
introduced in e2fsprogs version 1.43.

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 ...rename-copy_file_range-to-copy_file_chunk.patch | 62 ++
 .../recipes-devtools/e2fsprogs/e2fsprogs_1.43.4.bb |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 
meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch

diff --git 
a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch
 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch
new file mode 100644
index 00..3b1d7fe02d
--- /dev/null
+++ 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch
@@ -0,0 +1,62 @@
+From ad8078ca2ef35c91bedad61c9e2a6c01bf13a605 Mon Sep 17 00:00:00 2001
+From: Palmer Dabbelt <pal...@dabbelt.com>
+Date: Fri, 29 Dec 2017 10:19:51 -0800
+Subject: [PATCH] misc: rename copy_file_range to copy_file_chunk
+
+As of 2.27, glibc will have a copy_file_range library call to wrap the
+new copy_file_range system call.  This conflicts with the function in
+misc/create_inode.c, which this patch renames _copy_file_range.
+
+Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
+Signed-off-by: Theodore Ts'o <ty...@mit.edu>
+
+Upstream-Status: Backport
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ misc/create_inode.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/misc/create_inode.c b/misc/create_inode.c
+index ae22ff6f..ea6fa7e7 100644
+--- a/misc/create_inode.c
 b/misc/create_inode.c
+@@ -392,7 +392,7 @@ static ssize_t my_pread(int fd, void *buf, size_t count, 
off_t offset)
+ }
+ #endif /* !defined HAVE_PREAD64 && !defined HAVE_PREAD */
+ 
+-static errcode_t copy_file_range(ext2_filsys fs, int fd, ext2_file_t e2_file,
++static errcode_t copy_file_chunk(ext2_filsys fs, int fd, ext2_file_t e2_file,
+off_t start, off_t end, char *buf,
+char *zerobuf)
+ {
+@@ -466,7 +466,7 @@ static errcode_t try_lseek_copy(ext2_filsys fs, int fd, 
struct stat *statbuf,
+ 
+   data_blk = data & ~(fs->blocksize - 1);
+   hole_blk = (hole + (fs->blocksize - 1)) & ~(fs->blocksize - 1);
+-  err = copy_file_range(fs, fd, e2_file, data_blk, hole_blk, buf,
++  err = copy_file_chunk(fs, fd, e2_file, data_blk, hole_blk, buf,
+ zerobuf);
+   if (err)
+   return err;
+@@ -517,7 +517,7 @@ static errcode_t try_fiemap_copy(ext2_filsys fs, int fd, 
ext2_file_t e2_file,
+   goto out;
+   for (i = 0, ext = ext_buf; i < fiemap_buf->fm_mapped_extents;
+i++, ext++) {
+-  err = copy_file_range(fs, fd, e2_file, ext->fe_logical,
++  err = copy_file_chunk(fs, fd, e2_file, ext->fe_logical,
+ ext->fe_logical + ext->fe_length,
+ buf, zerobuf);
+   if (err)
+@@ -570,7 +570,7 @@ static errcode_t copy_file(ext2_filsys fs, int fd, struct 
stat *statbuf,
+   goto out;
+ #endif
+ 
+-  err = copy_file_range(fs, fd, e2_file, 0, statbuf->st_size, buf,
++  err = copy_file_chunk(fs, fd, e2_file, 0, statbuf->st_size, buf,
+ zerobuf);
+ out:
+   ext2fs_free_mem();
+-- 
+2.16.2
+
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.4.bb 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.4.bb
index 5216c7027c..7aa73a15ed 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.4.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.4.bb
@@ -10,6 +10,7 @@ SRC_URI += "file://acinclude.m4 \
 file://e2fsprogs-1.43-sysmacros.patch \
 file://mkdir_p.patch \
 
file://0001-e2fsck-exit-with-exit-status-0-if-no-errors-were-fix.patch \
+file://0001-misc-rename-copy_file_range-to-copy_file_chunk.patch \
 "
 
 SRC_URI_append_class-native = " 
file://e2fsprogs-fix-missing-check-for-permission-denied.patch"
-- 
2.16.2

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


[OE-core] [rocko][PATCH] e2fsprogs: fix compatibility with glibc 2.27

2018-03-21 Thread Tanu Kaskinen
glibc 2.27 added function copy_file_range(), and e2fsprogs happens to
have a different function with the same name. The conflict made
e2fsprogs-native build fail.

Here's a backport of a fix from upstream, the fix was released in
e2fsprogs 1.43.8.

The master branch doesn't need this fix, since it has new enough
e2fsprogs version. At least rocko, pyro and morty need this, I haven't
checked older stable branches. Apparently the problematic function was
introduced in e2fsprogs version 1.43.

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 ...rename-copy_file_range-to-copy_file_chunk.patch | 62 ++
 .../recipes-devtools/e2fsprogs/e2fsprogs_1.43.5.bb |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 
meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch

diff --git 
a/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch
 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch
new file mode 100644
index 00..308fe0e292
--- /dev/null
+++ 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/0001-misc-rename-copy_file_range-to-copy_file_chunk.patch
@@ -0,0 +1,62 @@
+From 647353f7c3fd29e1ffd468d7ff56d9643047ab35 Mon Sep 17 00:00:00 2001
+From: Palmer Dabbelt <pal...@dabbelt.com>
+Date: Fri, 29 Dec 2017 10:19:51 -0800
+Subject: [PATCH] misc: rename copy_file_range to copy_file_chunk
+
+As of 2.27, glibc will have a copy_file_range library call to wrap the
+new copy_file_range system call.  This conflicts with the function in
+misc/create_inode.c, which this patch renames _copy_file_range.
+
+Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
+Signed-off-by: Theodore Ts'o <ty...@mit.edu>
+
+Upstream-Status: Backport
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ misc/create_inode.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/misc/create_inode.c b/misc/create_inode.c
+index 8ce3fafa..cd89146f 100644
+--- a/misc/create_inode.c
 b/misc/create_inode.c
+@@ -396,7 +396,7 @@ static ssize_t my_pread(int fd, void *buf, size_t count, 
off_t offset)
+ }
+ #endif /* !defined HAVE_PREAD64 && !defined HAVE_PREAD */
+ 
+-static errcode_t copy_file_range(ext2_filsys fs, int fd, ext2_file_t e2_file,
++static errcode_t copy_file_chunk(ext2_filsys fs, int fd, ext2_file_t e2_file,
+off_t start, off_t end, char *buf,
+char *zerobuf)
+ {
+@@ -470,7 +470,7 @@ static errcode_t try_lseek_copy(ext2_filsys fs, int fd, 
struct stat *statbuf,
+ 
+   data_blk = data & ~(fs->blocksize - 1);
+   hole_blk = (hole + (fs->blocksize - 1)) & ~(fs->blocksize - 1);
+-  err = copy_file_range(fs, fd, e2_file, data_blk, hole_blk, buf,
++  err = copy_file_chunk(fs, fd, e2_file, data_blk, hole_blk, buf,
+ zerobuf);
+   if (err)
+   return err;
+@@ -521,7 +521,7 @@ static errcode_t try_fiemap_copy(ext2_filsys fs, int fd, 
ext2_file_t e2_file,
+   goto out;
+   for (i = 0, ext = ext_buf; i < fiemap_buf->fm_mapped_extents;
+i++, ext++) {
+-  err = copy_file_range(fs, fd, e2_file, ext->fe_logical,
++  err = copy_file_chunk(fs, fd, e2_file, ext->fe_logical,
+ ext->fe_logical + ext->fe_length,
+ buf, zerobuf);
+   if (err)
+@@ -574,7 +574,7 @@ static errcode_t copy_file(ext2_filsys fs, int fd, struct 
stat *statbuf,
+   goto out;
+ #endif
+ 
+-  err = copy_file_range(fs, fd, e2_file, 0, statbuf->st_size, buf,
++  err = copy_file_chunk(fs, fd, e2_file, 0, statbuf->st_size, buf,
+ zerobuf);
+ out:
+   ext2fs_free_mem();
+-- 
+2.16.2
+
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.5.bb 
b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.5.bb
index 00093cc20c..f1d7c08209 100644
--- a/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.5.bb
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.5.bb
@@ -10,6 +10,7 @@ SRC_URI += "file://acinclude.m4 \
 file://mkdir_p.patch \
 file://reproducible-doc.patch \
 file://0001-misc-create_inode.c-set-dir-s-mode-correctly.patch \
+file://0001-misc-rename-copy_file_range-to-copy_file_chunk.patch \
 "
 
 SRC_URI_append_class-native = " 
file://e2fsprogs-fix-missing-check-for-permission-denied.patch"
-- 
2.16.2

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


[OE-core] [PATCH 3/3] libvorbis: CVE-2018-5146

2018-03-20 Thread Tanu Kaskinen
Prevent out-of-bounds write in codebook decoding. The bug could allow
code execution from a specially crafted Ogg Vorbis file.

References:
https://www.debian.org/security/2018/dsa-4140
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5146

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../libvorbis/libvorbis/CVE-2018-5146.patch| 100 +
 .../libvorbis/libvorbis_1.3.5.bb   |   1 +
 2 files changed, 101 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch

diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch
new file mode 100644
index 00..6d4052a872
--- /dev/null
+++ b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch
@@ -0,0 +1,100 @@
+From 3a017f591457bf6e80231b563bf83ee583fdbca8 Mon Sep 17 00:00:00 2001
+From: Thomas Daede <daede...@umn.edu>
+Date: Thu, 15 Mar 2018 14:15:31 -0700
+Subject: [PATCH] CVE-2018-5146: Prevent out-of-bounds write in codebook
+ decoding.
+
+Codebooks that are not an exact divisor of the partition size are now
+truncated to fit within the partition.
+
+Upstream-Status: Backport
+CVE: CVE-2018-5146
+
+Reference to upstream patch:
+https://git.xiph.org/?p=vorbis.git;a=commitdiff;h=667ceb4aab60c1f74060143bb24e5f427b3cce5f
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ lib/codebook.c | 48 ++--
+ 1 file changed, 10 insertions(+), 38 deletions(-)
+
+diff --git a/lib/codebook.c b/lib/codebook.c
+index 8b766e8..7022fd2 100644
+--- a/lib/codebook.c
 b/lib/codebook.c
+@@ -387,7 +387,7 @@ long vorbis_book_decodevs_add(codebook *book,float 
*a,oggpack_buffer *b,int n){
+   t[i] = book->valuelist+entry[i]*book->dim;
+ }
+ for(i=0,o=0;idim;i++,o+=step)
+-  for (j=0;j<step;j++)
++  for (j=0;o+jdim>8){
+-  for(i=0;i<n;){
+-entry = decode_packed_entry_number(book,b);
+-if(entry==-1)return(-1);
+-t = book->valuelist+entry*book->dim;
+-for (j=0;jdim;)
+-  a[i++]+=t[j++];
+-  }
+-}else{
+-  for(i=0;i<n;){
+-entry = decode_packed_entry_number(book,b);
+-if(entry==-1)return(-1);
+-t = book->valuelist+entry*book->dim;
+-j=0;
+-switch((int)book->dim){
+-case 8:
+-  a[i++]+=t[j++];
+-case 7:
+-  a[i++]+=t[j++];
+-case 6:
+-  a[i++]+=t[j++];
+-case 5:
+-  a[i++]+=t[j++];
+-case 4:
+-  a[i++]+=t[j++];
+-case 3:
+-  a[i++]+=t[j++];
+-case 2:
+-  a[i++]+=t[j++];
+-case 1:
+-  a[i++]+=t[j++];
+-case 0:
+-  break;
+-}
+-  }
++for(i=0;i<n;){
++  entry = decode_packed_entry_number(book,b);
++  if(entry==-1)return(-1);
++  t = book->valuelist+entry*book->dim;
++  for(j=0;idim;)
++a[i++]+=t[j++];
+ }
+   }
+   return(0);
+@@ -471,12 +442,13 @@ long vorbis_book_decodevv_add(codebook *book,float 
**a,long offset,int ch,
+   long i,j,entry;
+   int chptr=0;
+   if(book->used_entries>0){
+-for(i=offset/ch;i<(offset+n)/ch;){
++int m=(offset+n)/ch;
++for(i=offset/ch;i<m;){
+   entry = decode_packed_entry_number(book,b);
+   if(entry==-1)return(-1);
+   {
+ const float *t = book->valuelist+entry*book->dim;
+-for (j=0;jdim;j++){
++for (j=0;idim;j++){
+   a[chptr++][i]+=t[j];
+   if(chptr==ch){
+ chptr=0;
+-- 
+2.16.2
+
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb 
b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
index 32e92f009a..20f887c252 100644
--- a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
+++ b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
@@ -14,6 +14,7 @@ SRC_URI = 
"http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz \
file://0001-configure-Check-for-clang.patch \
file://CVE-2017-14633.patch \
file://CVE-2017-14632.patch \
+   file://CVE-2018-5146.patch \
   "
 SRC_URI[md5sum] = "28cb28097c07a735d6af56e598e1c90f"
 SRC_URI[sha256sum] = 
"54f94a9527ff0a88477be0a71c0bab09a4c3febe0ed878b24824906cd4b0e1d1"
-- 
2.16.2

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


[OE-core] [PATCH 2/3] libvorbis: CVE-2017-14632

2018-03-20 Thread Tanu Kaskinen
Xiph.Org libvorbis 1.3.5 allows Remote Code Execution upon freeing
uninitialized memory in the function vorbis_analysis_headerout() in
info.c when vi->channels<=0, a similar issue to Mozilla bug 550184.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14632

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../libvorbis/libvorbis/CVE-2017-14632.patch   | 62 ++
 .../libvorbis/libvorbis_1.3.5.bb   |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch

diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
new file mode 100644
index 00..4036b966fe
--- /dev/null
+++ b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
@@ -0,0 +1,62 @@
+From 39704ce16835e5c019bb03f6a94dc1f0677406c5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Guido=20G=C3=BCnther?= <a...@sigxcpu.org>
+Date: Wed, 15 Nov 2017 18:22:59 +0100
+Subject: [PATCH] CVE-2017-14632: vorbis_analysis_header_out: Don't clear opb
+ if not initialized
+
+If the number of channels is not within the allowed range
+we call oggback_writeclear altough it's not initialized yet.
+
+This fixes
+
+=23371== Invalid free() / delete / delete[] / realloc()
+==23371==at 0x4C2CE1B: free (vg_replace_malloc.c:530)
+==23371==by 0x829CA31: oggpack_writeclear (in 
/usr/lib/x86_64-linux-gnu/libogg.so.0.8.2)
+==23371==by 0x84B96EE: vorbis_analysis_headerout (info.c:652)
+==23371==by 0x9FBCBCC: ??? (in 
/usr/lib/x86_64-linux-gnu/sox/libsox_fmt_vorbis.so)
+==23371==by 0x4E524F1: ??? (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x4E52CCA: sox_open_write (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x10D82A: open_output_file (sox.c:1556)
+==23371==by 0x10D82A: process (sox.c:1753)
+==23371==by 0x10D82A: main (sox.c:3012)
+==23371==  Address 0x68768c8 is 488 bytes inside a block of size 880 
alloc'd
+==23371==at 0x4C2BB1F: malloc (vg_replace_malloc.c:298)
+==23371==by 0x4C2DE9F: realloc (vg_replace_malloc.c:785)
+==23371==by 0x4E545C2: lsx_realloc (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x9FBC9A0: ??? (in 
/usr/lib/x86_64-linux-gnu/sox/libsox_fmt_vorbis.so)
+==23371==by 0x4E524F1: ??? (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x4E52CCA: sox_open_write (in 
/usr/lib/x86_64-linux-gnu/libsox.so.2.0.1)
+==23371==by 0x10D82A: open_output_file (sox.c:1556)
+==23371==by 0x10D82A: process (sox.c:1753)
+==23371==by 0x10D82A: main (sox.c:3012)
+
+as seen when using the testcase from CVE-2017-11333 with
+008d23b782be09c8d75ba8190b1794abd66c7121 applied. However the error was
+there before.
+
+Upstream-Status: Backport
+CVE: CVE-2017-14632
+
+Reference to upstream patch:
+https://git.xiph.org/?p=vorbis.git;a=commitdiff;h=c1c2831fc7306d5fbd7bc800324efd12b28d327f
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ lib/info.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/lib/info.c b/lib/info.c
+index 81b7557..4d82568 100644
+--- a/lib/info.c
 b/lib/info.c
+@@ -584,6 +584,7 @@ int vorbis_analysis_headerout(vorbis_dsp_state *v,
+   private_state *b=v->backend_state;
+ 
+   if(!b||vi->channels<=0||vi->channels>256){
++b = NULL;
+ ret=OV_EFAULT;
+ goto err_out;
+   }
+-- 
+2.16.2
+
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb 
b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
index 73f9d1af2c..32e92f009a 100644
--- a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
+++ b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
@@ -13,6 +13,7 @@ DEPENDS = "libogg"
 SRC_URI = "http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz \
file://0001-configure-Check-for-clang.patch \
file://CVE-2017-14633.patch \
+   file://CVE-2017-14632.patch \
   "
 SRC_URI[md5sum] = "28cb28097c07a735d6af56e598e1c90f"
 SRC_URI[sha256sum] = 
"54f94a9527ff0a88477be0a71c0bab09a4c3febe0ed878b24824906cd4b0e1d1"
-- 
2.16.2

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


[OE-core] [PATCH 1/3] libvorbis: CVE-2017-14633

2018-03-20 Thread Tanu Kaskinen
In Xiph.Org libvorbis 1.3.5, an out-of-bounds array read vulnerability
exists in the function mapping0_forward() in mapping0.c, which may lead
to DoS when operating on a crafted audio file with vorbis_analysis().

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14633

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../libvorbis/libvorbis/CVE-2017-14633.patch   | 42 ++
 .../libvorbis/libvorbis_1.3.5.bb   |  1 +
 2 files changed, 43 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch

diff --git a/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch 
b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
new file mode 100644
index 00..9c9e688d43
--- /dev/null
+++ b/meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
@@ -0,0 +1,42 @@
+From 07eda55f336e5c44dfc0e4a1e21628faed7255fa Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Guido=20G=C3=BCnther?= <a...@sigxcpu.org>
+Date: Tue, 31 Oct 2017 18:32:46 +0100
+Subject: [PATCH] CVE-2017-14633: Don't allow for more than 256 channels
+
+Otherwise
+
+ for(i=0;ichannels;i++){
+  /* the encoder setup assumes that all the modes used by any
+ specific bitrate tweaking use the same floor */
+  int submap=info->chmuxlist[i];
+
+overreads later in mapping0_forward since chmuxlist is a fixed array of
+256 elements max.
+
+Upstream-Status: Backport
+CVE: CVE-2017-14633
+
+Reference to upstream patch:
+https://git.xiph.org/?p=vorbis.git;a=commitdiff;h=667ceb4aab60c1f74060143bb24e5f427b3cce5f
+
+Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
+---
+ lib/info.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/info.c b/lib/info.c
+index e447a0c..81b7557 100644
+--- a/lib/info.c
 b/lib/info.c
+@@ -583,7 +583,7 @@ int vorbis_analysis_headerout(vorbis_dsp_state *v,
+   oggpack_buffer opb;
+   private_state *b=v->backend_state;
+ 
+-  if(!b||vi->channels<=0){
++  if(!b||vi->channels<=0||vi->channels>256){
+ ret=OV_EFAULT;
+ goto err_out;
+   }
+-- 
+2.16.2
+
diff --git a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb 
b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
index 56c5b0a9cb..73f9d1af2c 100644
--- a/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
+++ b/meta/recipes-multimedia/libvorbis/libvorbis_1.3.5.bb
@@ -12,6 +12,7 @@ DEPENDS = "libogg"
 
 SRC_URI = "http://downloads.xiph.org/releases/vorbis/${BP}.tar.xz \
file://0001-configure-Check-for-clang.patch \
+   file://CVE-2017-14633.patch \
   "
 SRC_URI[md5sum] = "28cb28097c07a735d6af56e598e1c90f"
 SRC_URI[sha256sum] = 
"54f94a9527ff0a88477be0a71c0bab09a4c3febe0ed878b24824906cd4b0e1d1"
-- 
2.16.2

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


[OE-core] [PATCH 0/3] libvorbis security fixes

2018-03-20 Thread Tanu Kaskinen
libvorbis 1.3.6 was recently released, and contains fixes for some CVEs.
Since the deadline for version upgrades is past, I'm only submitting the
CVE fixes.

Tanu Kaskinen (3):
  libvorbis: CVE-2017-14633
  libvorbis: CVE-2017-14632
  libvorbis: CVE-2018-5146

 .../libvorbis/libvorbis/CVE-2017-14632.patch   |  62 +
 .../libvorbis/libvorbis/CVE-2017-14633.patch   |  42 +
 .../libvorbis/libvorbis/CVE-2018-5146.patch| 100 +
 .../libvorbis/libvorbis_1.3.5.bb   |   3 +
 4 files changed, 207 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14632.patch
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2017-14633.patch
 create mode 100644 
meta/recipes-multimedia/libvorbis/libvorbis/CVE-2018-5146.patch

-- 
2.16.2

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


[OE-core] [PATCH 5/6] alsa-tools: 1.1.3 -> 1.1.5

2017-11-27 Thread Tanu Kaskinen
Changes:
http://www.alsa-project.org/main/index.php/Changes_v1.1.4_v1.1.5

Rebased autotools.patch and makefile_no_gtk.patch.

Dropped 0001-as10k1-Make-output_tram_line-static-inline.patch with the
assumption that it's not needed any more. The patch added a "static"
qualifier to a function. According to the commit message, this was done
to improve optimization. Upstream removed the "inline" qualifier from
that same function, because it caused some trouble with clang. My guess
is that the patch author actually ran into the same clang problem as
upstream, but came up with a different fix. It doesn't seem like a
function whose optimization anyone would really be interested in.

Cc: Khem Raj <raj.k...@gmail.com>
Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---

Khem, I added you to Cc in case you don't want the as10k1 patch to be
removed.

 ...s10k1-Make-output_tram_line-static-inline.patch | 31 --
 .../alsa/alsa-tools/autotools.patch|  2 +-
 .../alsa/alsa-tools/makefile_no_gtk.patch  |  2 +-
 .../{alsa-tools_1.1.3.bb => alsa-tools_1.1.5.bb}   |  5 ++--
 4 files changed, 4 insertions(+), 36 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-tools/0001-as10k1-Make-output_tram_line-static-inline.patch
 rename meta/recipes-multimedia/alsa/{alsa-tools_1.1.3.bb => 
alsa-tools_1.1.5.bb} (87%)

diff --git 
a/meta/recipes-multimedia/alsa/alsa-tools/0001-as10k1-Make-output_tram_line-static-inline.patch
 
b/meta/recipes-multimedia/alsa/alsa-tools/0001-as10k1-Make-output_tram_line-static-inline.patch
deleted file mode 100644
index d049a30d2c..00
--- 
a/meta/recipes-multimedia/alsa/alsa-tools/0001-as10k1-Make-output_tram_line-static-inline.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From 1e5926df74a35fe2cd90bc59f5264a8715c94048 Mon Sep 17 00:00:00 2001
-From: Khem Raj <raj.k...@gmail.com>
-Date: Mon, 7 Sep 2015 08:16:59 +
-Subject: [PATCH] as10k1: Make output_tram_line() static inline
-
-The function is not used in any other file, its better to make it static
-inline so compiler has a better chance of optimizing here
-
-Signed-off-by: Khem Raj <raj.k...@gmail.com>

-Upstream-Status: Pending
-
- as10k1/as10k1.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/as10k1/as10k1.c b/as10k1/as10k1.c
-index 96af0c3..d0766fd 100644
 a/as10k1/as10k1.c
-+++ b/as10k1/as10k1.c
-@@ -366,7 +366,7 @@ void as_exit(const char *message)
-   exit(1);
- }
- 
--inline void output_tram_line( struct list_head *line_head, int type){
-+static inline void output_tram_line( struct list_head *line_head, int type){
- 
- struct tram *tram_sym;
- struct list_head *entry;
--- 
-2.5.1
-
diff --git a/meta/recipes-multimedia/alsa/alsa-tools/autotools.patch 
b/meta/recipes-multimedia/alsa/alsa-tools/autotools.patch
index 319f25d27a..2e74963c89 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools/autotools.patch
+++ b/meta/recipes-multimedia/alsa/alsa-tools/autotools.patch
@@ -20,7 +20,7 @@ diff -ruN alsa-tools-1.0.24.1-orig//Makefile 
alsa-tools-1.0.24.1/Makefile
 --- alsa-tools-1.0.24.1-orig//Makefile 2011-07-06 11:27:40.207665000 +0800
 +++ alsa-tools-1.0.24.1/Makefile   2011-07-14 15:08:08.877665009 +0800
 @@ -1,8 +1,8 @@
- VERSION = 1.1.0
+ VERSION = 1.1.5
  TOP = .
 -SUBDIRS = as10k1 envy24control hdsploader hdspconf hdspmixer \
 +SUBDIRS = as10k1 envy24control \
diff --git a/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch 
b/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
index 9bd6848eda..54373d1a8f 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
+++ b/meta/recipes-multimedia/alsa/alsa-tools/makefile_no_gtk.patch
@@ -14,7 +14,7 @@ index 2457a1c..72346d9 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -1,9 +1,9 @@
- VERSION = 1.1.0
+ VERSION = 1.1.5
  TOP = .
 -SUBDIRS = as10k1 envy24control \
 -mixartloader pcxhrloader rmedigicontrol sb16_csp seq sscape_ctl \
diff --git a/meta/recipes-multimedia/alsa/alsa-tools_1.1.3.bb 
b/meta/recipes-multimedia/alsa/alsa-tools_1.1.5.bb
similarity index 87%
rename from meta/recipes-multimedia/alsa/alsa-tools_1.1.3.bb
rename to meta/recipes-multimedia/alsa/alsa-tools_1.1.5.bb
index 9e97c0e969..1be43aa6e7 100644
--- a/meta/recipes-multimedia/alsa/alsa-tools_1.1.3.bb
+++ b/meta/recipes-multimedia/alsa/alsa-tools_1.1.5.bb
@@ -12,11 +12,10 @@ SRC_URI = 
"ftp://ftp.alsa-project.org/pub/tools/${BP}.tar.bz2 \
file://autotools.patch \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', 
'file://makefile_no_gtk.patch', d)} \
file://gitcompile_hdajacksensetest \
-   file://0001-as10k1-Make-output_tram_line-static-inline.patch \
"
 
-SRC_URI[md5sum] = "b23eaae687d55410b92587c2053b301f"
-SRC_URI[sha256sum] = 
"d88f1dcd6872121383eded5fa24e328e68c54e527db4547e1435d5eabc2b670

[OE-core] [PATCH 4/6] alsa-plugins: 1.1.4 -> 1.1.5

2017-11-27 Thread Tanu Kaskinen
Changes:
http://www.alsa-project.org/main/index.php/Changes_v1.1.4_v1.1.5

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../alsa/{alsa-plugins_1.1.4.bb => alsa-plugins_1.1.5.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.4.bb => 
alsa-plugins_1.1.5.bb} (96%)

diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.4.bb 
b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.5.bb
similarity index 96%
rename from meta/recipes-multimedia/alsa/alsa-plugins_1.1.4.bb
rename to meta/recipes-multimedia/alsa/alsa-plugins_1.1.5.bb
index b7f79b7535..4bd0acc54f 100644
--- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.4.bb
+++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.5.bb
@@ -21,8 +21,8 @@ LIC_FILES_CHKSUM = "\
 "
 
 SRC_URI = "ftp://ftp.alsa-project.org/pub/plugins/${BP}.tar.bz2;
-SRC_URI[md5sum] = "de51130a7444b79b2dd3c25e28420754"
-SRC_URI[sha256sum] = 
"530d1c3bdaeb058f2a03607a33b9e16ee5369bfd30a96bc09bd2c69b4ddd1a8a"
+SRC_URI[md5sum] = "f898b0e6e8acf3f6f82bc2a0f0c84a97"
+SRC_URI[sha256sum] = 
"797da5f8f53379fbea28817bc466de16affd2c07849e84f1af8d5e22f7bb7f1c"
 
 DEPENDS += "alsa-lib"
 
-- 
2.14.2

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


[OE-core] [PATCH 2/6] lame: 3.99.5 -> 3.100

2017-11-27 Thread Tanu Kaskinen
Release notes:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html?revision=1.154

Dropped patches that are included in the release:
 - lame-3.99.5_fix_for_automake-1.12.x.patch
 - CVE-2017-13712.patch

The CACHED_CONFIGUREVARS thing to disable SSE code on x86 isn't needed
anymore. The build system now correctly detects when SSE isn't
available.

Note for stable branch maintainers: This release includes several fixes
for bugs that have a CVE number associated with them. The bugs (or at
least most of them) are crashes that seem to be considered "remote DoS"
vulnerabilities, probably because it's easy to imagine lame being used
with untrusted audio files from remote sources. If you want to backport
"all sercurity fixes" to the stable brances, that task seems pretty
difficult. The release notes explicitly mention three CVE numbers, but
there are more: for example, OE had a fix for CVE-2017-13712, which is
not mentioned in the release notes but is fixed in the release. The
commit log doesn't keep any track of CVE numbers either. Maybe it would
be best to just upgrade lame to 3.100 also in the stable branches.

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../lame/lame/CVE-2017-13712.patch | 309 -
 .../lame/lame-3.99.5_fix_for_automake-1.12.x.patch |  59 
 .../lame/{lame_3.99.5.bb => lame_3.100.bb} |   9 +-
 3 files changed, 2 insertions(+), 375 deletions(-)
 delete mode 100644 meta/recipes-multimedia/lame/lame/CVE-2017-13712.patch
 delete mode 100644 
meta/recipes-multimedia/lame/lame/lame-3.99.5_fix_for_automake-1.12.x.patch
 rename meta/recipes-multimedia/lame/{lame_3.99.5.bb => lame_3.100.bb} (69%)

diff --git a/meta/recipes-multimedia/lame/lame/CVE-2017-13712.patch 
b/meta/recipes-multimedia/lame/lame/CVE-2017-13712.patch
deleted file mode 100644
index f9ec7665ff..00
--- a/meta/recipes-multimedia/lame/lame/CVE-2017-13712.patch
+++ /dev/null
@@ -1,309 +0,0 @@
-Upstream-Status: Backport 
[http://lame.cvs.sourceforge.net/viewvc/lame/lame/libmp3lame/id3tag.c?r1=1.79=1.80]
-
-Backport patch to fix CVE-2017-13712 for lame.
-
-Signed-off-by: Kai Kang <kai.k...@windriver.com>

 a/libmp3lame/id3tag.c  2017/08/22 19:44:05 1.79
-+++ b/libmp3lame/id3tag.c  2017/08/28 15:39:51 1.80
-@@ -194,7 +194,11 @@
- }
- #endif
- 
--
-+static int
-+is_lame_internal_flags_null(lame_t gfp)
-+{
-+return (gfp && gfp->internal_flags) ? 0 : 1;
-+}
- 
- static int
- id3v2_add_ucs2_lng(lame_t gfp, uint32_t frame_id, unsigned short const *desc, 
unsigned short const *text);
-@@ -238,8 +242,7 @@
- static void
- id3v2AddAudioDuration(lame_t gfp, double ms)
- {
--lame_internal_flags *gfc = gfp != 0 ? gfp->internal_flags : 0;
--SessionConfig_t const *const cfg = >cfg;
-+SessionConfig_t const *const cfg = >internal_flags->cfg; /* caller 
checked pointers */
- charbuffer[1024];
- double const max_ulong = MAX_U_32_NUM;
- unsigned long playlength_ms;
-@@ -280,7 +283,12 @@
- void
- id3tag_init(lame_t gfp)
- {
--lame_internal_flags *gfc = gfp->internal_flags;
-+lame_internal_flags *gfc = 0;
-+
-+if (is_lame_internal_flags_null(gfp)) {
-+return;
-+}
-+gfc = gfp->internal_flags;
- free_id3tag(gfc);
- memset(>tag_spec, 0, sizeof gfc->tag_spec);
- gfc->tag_spec.genre_id3v1 = GENRE_NUM_UNKNOWN;
-@@ -293,7 +301,12 @@
- void
- id3tag_add_v2(lame_t gfp)
- {
--lame_internal_flags *gfc = gfp->internal_flags;
-+lame_internal_flags *gfc = 0;
-+
-+if (is_lame_internal_flags_null(gfp)) {
-+return;
-+}
-+gfc = gfp->internal_flags;
- gfc->tag_spec.flags &= ~V1_ONLY_FLAG;
- gfc->tag_spec.flags |= ADD_V2_FLAG;
- }
-@@ -301,7 +314,12 @@
- void
- id3tag_v1_only(lame_t gfp)
- {
--lame_internal_flags *gfc = gfp->internal_flags;
-+lame_internal_flags *gfc = 0;
-+
-+if (is_lame_internal_flags_null(gfp)) {
-+return;
-+}
-+gfc = gfp->internal_flags;
- gfc->tag_spec.flags &= ~(ADD_V2_FLAG | V2_ONLY_FLAG);
- gfc->tag_spec.flags |= V1_ONLY_FLAG;
- }
-@@ -309,7 +327,12 @@
- void
- id3tag_v2_only(lame_t gfp)
- {
--lame_internal_flags *gfc = gfp->internal_flags;
-+lame_internal_flags *gfc = 0;
-+
-+if (is_lame_internal_flags_null(gfp)) {
-+return;
-+}
-+gfc = gfp->internal_flags;
- gfc->tag_spec.flags &= ~V1_ONLY_FLAG;
- gfc->tag_spec.flags |= V2_ONLY_FLAG;
- }
-@@ -317,7 +340,12 @@
- void
- id3tag_space_v1(lame_t gfp)
- {
--lame_internal_flags *gfc = gfp->internal_flags;
-+lame_internal_flags *gfc = 0;
-+
-+if (is_lame_internal_flags_null(gfp)) {
-+return;
-+}
-+gfc = gfp->internal_flags;
- gfc->tag_spec.flags &= ~V2_ONLY_FLAG;
- gfc->tag_spec.flags |= SPACE_V1_FLAG;
- }
-@@ -331,7 +359,12 @

[OE-core] [PATCH 3/6] alsa-lib: 1.1.4.1 -> 1.1.5

2017-11-27 Thread Tanu Kaskinen
Changes:
http://www.alsa-project.org/main/index.php/Changes_v1.1.4_v1.1.5

Dropped all patches. The poll.h patch is included in the release, and
the wordexp patch is not needed any more, because the wordexp function
is replaced by an internal reimplementation.

It would still be possible to enable the use of wordexp with the
--with-wordexp configure option. The option exists, because the internal
reimplementation covers only part of what wordexp can do, so not using
wordexp can in theory cause regressions. However, it seems that
regressions are quite unlikely in practice. Here's some discussion about
the topic:
http://mailman.alsa-project.org/pipermail/alsa-devel/2017-July/122667.html

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../Check-if-wordexp-function-is-supported.patch   |  51 --
 .../avoid-including-sys-poll.h-directly.patch  | 183 -
 .../{alsa-lib_1.1.4.1.bb => alsa-lib_1.1.5.bb} |   9 +-
 3 files changed, 3 insertions(+), 240 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/Check-if-wordexp-function-is-supported.patch
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/avoid-including-sys-poll.h-directly.patch
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.4.1.bb => alsa-lib_1.1.5.bb} 
(77%)

diff --git 
a/meta/recipes-multimedia/alsa/alsa-lib/Check-if-wordexp-function-is-supported.patch
 
b/meta/recipes-multimedia/alsa/alsa-lib/Check-if-wordexp-function-is-supported.patch
deleted file mode 100644
index 795e48ab2e..00
--- 
a/meta/recipes-multimedia/alsa/alsa-lib/Check-if-wordexp-function-is-supported.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 3408f8e78776b12f131e433749721602f87e0a70 Mon Sep 17 00:00:00 2001
-From: "Hong H. Pham" <hong.p...@windriver.com>
-Date: Fri, 29 Aug 2014 17:13:55 +0300
-Subject: [PATCH] Check if wordexp function is supported
-
-eglibc could be configured to build without wordexp, so it is not enough
-to check if wordexp.h exists (the header file could be installed, but it's
-possible that the wordexp() function is not supported).  An additional
-check if wordexp() is supported by the system C library is needed.
-
-Upstream-Status: Inappropriate [configuration]
-
-Signed-off-by: Hong H. Pham <hong.p...@windriver.com>
-Signed-off-by: Cristian Iorga <cristian.io...@intel.com>

- configure.ac   | 5 -
- src/userfile.c | 2 +-
- 2 files changed, 5 insertions(+), 2 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 9490d39..b08a90a 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -295,7 +295,10 @@ fi
- AC_SUBST(ALSA_DEPLIBS)
- 
- dnl Check for headers
--AC_CHECK_HEADERS([wordexp.h endian.h sys/endian.h sys/shm.h])
-+AC_CHECK_HEADERS([wordexp.h endian.h sys/endian.h sys/shm.h],
-+  dnl Make sure wordexp is supported by the C library
-+  AC_CHECK_FUNCS([wordexp])
-+)
- 
- dnl Check for resmgr support...
- AC_MSG_CHECKING(for resmgr support)
-diff --git a/src/userfile.c b/src/userfile.c
-index 72779da..e9d13e6 100644
 a/src/userfile.c
-+++ b/src/userfile.c
-@@ -32,7 +32,7 @@
-  * stores the first matchine one.  The returned string is strdup'ed.
-  */
- 
--#ifdef HAVE_WORDEXP_H
-+#if (defined(HAVE_WORDEXP_H) && defined(HAVE_WORDEXP))
- #include 
- #include 
- int snd_user_file(const char *file, char **result)
--- 
-2.6.4
-
diff --git 
a/meta/recipes-multimedia/alsa/alsa-lib/avoid-including-sys-poll.h-directly.patch
 
b/meta/recipes-multimedia/alsa/alsa-lib/avoid-including-sys-poll.h-directly.patch
deleted file mode 100644
index 3d44585939..00
--- 
a/meta/recipes-multimedia/alsa/alsa-lib/avoid-including-sys-poll.h-directly.patch
+++ /dev/null
@@ -1,183 +0,0 @@
-From c2c13cf0c469862cd39b2a69862002331ab7c8cb Mon Sep 17 00:00:00 2001
-From: Andre McCurdy <armccu...@gmail.com>
-Date: Tue, 9 Feb 2016 14:01:18 -0800
-Subject: [PATCH] avoid including  directly
-
-Fixes compiler warnings when building with musl libc.
-
-Upstream-Status: Pending
-
-Signed-off-by: Andre McCurdy <armccu...@gmail.com>

- aserver/aserver.c | 2 +-
- include/asoundlib-head.h  | 2 +-
- include/asoundlib.h   | 2 +-
- include/local.h   | 2 +-
- src/control/control.c | 2 +-
- src/control/control_shm.c | 2 +-
- src/pcm/pcm_direct.c  | 2 +-
- src/pcm/pcm_mmap.c| 2 +-
- src/pcm/pcm_share.c   | 2 +-
- src/pcm/pcm_shm.c | 2 +-
- src/seq/seq.c | 2 +-
- src/shmarea.c | 2 +-
- 12 files changed, 12 insertions(+), 12 deletions(-)
-
-diff --git a/aserver/aserver.c b/aserver/aserver.c
-index ac20706..46f731a 100644
 a/aserver/aserver.c
-+++ b/aserver/aserver.c
-@@ -20,7 +20,7 @@
- 
- #include 
- #include 
--#include 
-+#include 
- #include 
- #include 
- #include 
-diff --git a/include/asoundlib-head.h b/include/asoundlib-head.h
-index 1ec611e..21e32c6 100644
 a/include/asoundlib-head.h
-+++ b/include/asoundlib-head.h
-@@ -35,6 +35,6 @@
- #include 
- #include 
- #include 

[OE-core] [PATCH 6/6] alsa-utils: 1.1.4 -> 1.1.5

2017-11-27 Thread Tanu Kaskinen
Changes:
http://www.alsa-project.org/main/index.php/Changes_v1.1.4_v1.1.5

Rebased 0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch.

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 ...sa-utils-scripts_1.1.4.bb => alsa-utils-scripts_1.1.5.bb} |  0
 ...lsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch | 12 ++--
 .../alsa/{alsa-utils_1.1.4.bb => alsa-utils_1.1.5.bb}|  4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.4.bb => 
alsa-utils-scripts_1.1.5.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.4.bb => 
alsa-utils_1.1.5.bb} (97%)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.4.bb 
b/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.5.bb
similarity index 100%
rename from meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.4.bb
rename to meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.5.bb
diff --git 
a/meta/recipes-multimedia/alsa/alsa-utils/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
 
b/meta/recipes-multimedia/alsa/alsa-utils/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
index e578dfe743..907ca5ce0e 100644
--- 
a/meta/recipes-multimedia/alsa/alsa-utils/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
+++ 
b/meta/recipes-multimedia/alsa/alsa-utils/0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch
@@ -1,4 +1,4 @@
-From 8c3e0ef9625066c2bb67ee3d2b8cd37fd44eadac Mon Sep 17 00:00:00 2001
+From b9d41b784657152a4c5683a9458dffab557f0689 Mon Sep 17 00:00:00 2001
 From: Koen Kooi <k...@dominion.thruhere.net>
 Date: Fri, 29 Aug 2014 18:58:56 +0300
 Subject: [PATCH] alsactl: don't let systemd unit restore the volume when
@@ -22,7 +22,7 @@ Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
  2 files changed, 5 insertions(+), 3 deletions(-)
 
 diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am
-index cac8094..ff865dc 100644
+index 90fab9d..190525a 100644
 --- a/alsactl/Makefile.am
 +++ b/alsactl/Makefile.am
 @@ -38,9 +38,10 @@ install-data-hook:
@@ -40,17 +40,17 @@ index cac8094..ff865dc 100644
  
  alsa-state.service: alsa-state.service.in
 diff --git a/alsactl/alsa-restore.service.in b/alsactl/alsa-restore.service.in
-index 2884098..bac3ccc 100644
+index 80fd5fd..6beb36d 100644
 --- a/alsactl/alsa-restore.service.in
 +++ b/alsactl/alsa-restore.service.in
-@@ -8,6 +8,7 @@ Description=Save/Restore Sound Card State
+@@ -7,6 +7,7 @@
+ Description=Save/Restore Sound Card State
  ConditionPathExists=!@daemonswitch@
  ConditionPathExistsGlob=/dev/snd/control*
- After=alsa-state.service
 +ConditionPathExists=@localstatedir@/lib/alsa/asound.state
  
  [Service]
  Type=oneshot
 -- 
-2.7.0.rc3
+2.14.2
 
diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.1.5.bb
similarity index 97%
rename from meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
rename to meta/recipes-multimedia/alsa/alsa-utils_1.1.5.bb
index c8f4b861bd..f2231f34f0 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.5.bb
@@ -23,8 +23,8 @@ SRC_URI = 
"ftp://ftp.alsa-project.org/pub/utils/alsa-utils-${PV}.tar.bz2 \

file://0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch \
   "
 
-SRC_URI[md5sum] = "01e3934ca5bd22a80c27289d1b0adcdc"
-SRC_URI[sha256sum] = 
"a7831044de92c5bf33bf3365a3f36e49397f4191e934df460ae1ca15138c9d9d"
+SRC_URI[md5sum] = "dfe6ea147a5e07a056919591c2f5dac3"
+SRC_URI[sha256sum] = 
"320bd285e91db6e7fd7db3c9ec6f55b02f35449ff273c7844780ac6a5a3de2e8"
 
 # On build machines with python-docutils (not python3-docutils !!) installed
 # rst2man (not rst2man.py) is detected and compile fails with
-- 
2.14.2

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


[OE-core] [PATCH 1/6] pulseaudio: 10.0 -> 11.1

2017-11-27 Thread Tanu Kaskinen
11.0 release notes:
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/11.0/

Additional changes in 11.1:
 * Fix a crash in filter modules related to flat volumes and volume
   sharing
 * Fix a crash when the bluetooth adapter reports weird MTU size
 * Disable bluetooth MTU autodetection by default
 * Add mixer handling back for hardware that doesn't have any alsa-lib
   configuration
 * Prioritize USB devices over built-in sound cards (11.0 was supposed
   to have this feature, but the implementation turned out to be
   incomplete)

Dropped backported patch:
pulseaudio-discuss-iochannel-don-t-use-variable-length-array-in-union.patch

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 ...-don-t-use-variable-length-array-in-union.patch | 59 --
 .../{pulseaudio_10.0.bb => pulseaudio_11.1.bb} |  5 +-
 2 files changed, 2 insertions(+), 62 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/pulseaudio-discuss-iochannel-don-t-use-variable-length-array-in-union.patch
 rename meta/recipes-multimedia/pulseaudio/{pulseaudio_10.0.bb => 
pulseaudio_11.1.bb} (61%)

diff --git 
a/meta/recipes-multimedia/pulseaudio/pulseaudio/pulseaudio-discuss-iochannel-don-t-use-variable-length-array-in-union.patch
 
b/meta/recipes-multimedia/pulseaudio/pulseaudio/pulseaudio-discuss-iochannel-don-t-use-variable-length-array-in-union.patch
deleted file mode 100644
index 11b56abd26..00
--- 
a/meta/recipes-multimedia/pulseaudio/pulseaudio/pulseaudio-discuss-iochannel-don-t-use-variable-length-array-in-union.patch
+++ /dev/null
@@ -1,59 +0,0 @@
-From patchwork Sat Feb  4 12:19:01 2017
-Content-Type: text/plain; charset="utf-8"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Subject: [pulseaudio-discuss] iochannel: don't use variable length array in
- union
-From: Tanu Kaskinen <ta...@iki.fi>
-X-Patchwork-Id: 136885
-Message-Id: <20170204121901.17428-1-ta...@iki.fi>
-To: pulseaudio-disc...@lists.freedesktop.org
-Date: Sat,  4 Feb 2017 14:19:01 +0200
-
-Clang didn't like the variable length array:
-
-pulsecore/iochannel.c:358:17: error: fields must have a constant size:
-'variable length array in structure' extension will never be supported
-uint8_t data[CMSG_SPACE(sizeof(int) * nfd)];
-^
-
-Commit 451d1d6762 introduced the variable length array in order to have
-the correct value in msg_controllen. This patch reverts that commit and
-uses a different way to achieve the same goal.
-
-BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=99458

-Upstream-Status: Backport
-Signed-off-by: Khem Raj <raj.k...@gmail.com>
-
- src/pulsecore/iochannel.c | 10 --
- 1 file changed, 8 insertions(+), 2 deletions(-)
-
-diff --git a/src/pulsecore/iochannel.c b/src/pulsecore/iochannel.c
-index 8ace297ff..897337522 100644
 a/src/pulsecore/iochannel.c
-+++ b/src/pulsecore/iochannel.c
-@@ -355,7 +355,7 @@ ssize_t pa_iochannel_write_with_fds(pa_iochannel*io, const 
void*data, size_t l,
- struct iovec iov;
- union {
- struct cmsghdr hdr;
--uint8_t data[CMSG_SPACE(sizeof(int) * nfd)];
-+uint8_t data[CMSG_SPACE(sizeof(int) * MAX_ANCIL_DATA_FDS)];
- } cmsg;
- 
- pa_assert(io);
-@@ -382,7 +382,13 @@ ssize_t pa_iochannel_write_with_fds(pa_iochannel*io, 
const void*data, size_t l,
- mh.msg_iov = 
- mh.msg_iovlen = 1;
- mh.msg_control = 
--mh.msg_controllen = sizeof(cmsg);
-+
-+/* If we followed the example on the cmsg man page, we'd use
-+ * sizeof(cmsg.data) here, but if nfd < MAX_ANCIL_DATA_FDS, then the data
-+ * buffer is larger than needed, and the kernel doesn't like it if we set
-+ * msg_controllen to a larger than necessary value. The commit message for
-+ * commit 451d1d6762 contains a longer explanation. */
-+mh.msg_controllen = CMSG_SPACE(sizeof(int) * nfd);
- 
- if ((r = sendmsg(io->ofd, , MSG_NOSIGNAL)) >= 0) {
- io->writable = io->hungup = false;
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb 
b/meta/recipes-multimedia/pulseaudio/pulseaudio_11.1.bb
similarity index 61%
rename from meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb
rename to meta/recipes-multimedia/pulseaudio/pulseaudio_11.1.bb
index 9a34afaa7e..a50b5a08ae 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_10.0.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_11.1.bb
@@ -3,11 +3,10 @@ require pulseaudio.inc
 SRC_URI = "http://freedesktop.org/software/pulseaudio/releases/${BP}.tar.xz \
file://0001-padsp-Make-it-compile-on-musl.patch \
file://0001-client-conf-Add-allow-autospawn-for-root.patch \
-   
file://pulseaudio-discuss-iochannel-don-t-use-variable-length-array-in-union.patch
 \
file://volatiles.04_pulse \
 "
-SRC_URI[md5sum] = "4950d2799bf55ab91f6b7f990b7f0971"
-SRC_URI[sha256sum] = 
"a3186824de9f0d2095ded5d0d0db0405dc7313

[OE-core] [PATCH 0/6] Audio recipe updates

2017-11-27 Thread Tanu Kaskinen
Tanu Kaskinen (6):
  pulseaudio: 10.0 -> 11.1
  lame: 3.99.5 -> 3.100
  alsa-lib: 1.1.4.1 -> 1.1.5
  alsa-plugins: 1.1.4 -> 1.1.5
  alsa-tools: 1.1.3 -> 1.1.5
  alsa-utils: 1.1.4 -> 1.1.5

 .../Check-if-wordexp-function-is-supported.patch   |  51 
 .../avoid-including-sys-poll.h-directly.patch  | 183 
 .../{alsa-lib_1.1.4.1.bb => alsa-lib_1.1.5.bb} |   9 +-
 ...alsa-plugins_1.1.4.bb => alsa-plugins_1.1.5.bb} |   4 +-
 ...s10k1-Make-output_tram_line-static-inline.patch |  31 ---
 .../alsa/alsa-tools/autotools.patch|   2 +-
 .../alsa/alsa-tools/makefile_no_gtk.patch  |   2 +-
 .../{alsa-tools_1.1.3.bb => alsa-tools_1.1.5.bb}   |   5 +-
 ...cripts_1.1.4.bb => alsa-utils-scripts_1.1.5.bb} |   0
 ...-t-let-systemd-unit-restore-the-volume-wh.patch |  12 +-
 .../{alsa-utils_1.1.4.bb => alsa-utils_1.1.5.bb}   |   4 +-
 .../lame/lame/CVE-2017-13712.patch | 309 -
 .../lame/lame-3.99.5_fix_for_automake-1.12.x.patch |  59 
 .../lame/{lame_3.99.5.bb => lame_3.100.bb} |   9 +-
 ...-don-t-use-variable-length-array-in-union.patch |  59 
 .../{pulseaudio_10.0.bb => pulseaudio_11.1.bb} |   5 +-
 16 files changed, 21 insertions(+), 723 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/Check-if-wordexp-function-is-supported.patch
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/avoid-including-sys-poll.h-directly.patch
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.4.1.bb => alsa-lib_1.1.5.bb} 
(77%)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.4.bb => 
alsa-plugins_1.1.5.bb} (96%)
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-tools/0001-as10k1-Make-output_tram_line-static-inline.patch
 rename meta/recipes-multimedia/alsa/{alsa-tools_1.1.3.bb => 
alsa-tools_1.1.5.bb} (87%)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.4.bb => 
alsa-utils-scripts_1.1.5.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.4.bb => 
alsa-utils_1.1.5.bb} (97%)
 delete mode 100644 meta/recipes-multimedia/lame/lame/CVE-2017-13712.patch
 delete mode 100644 
meta/recipes-multimedia/lame/lame/lame-3.99.5_fix_for_automake-1.12.x.patch
 rename meta/recipes-multimedia/lame/{lame_3.99.5.bb => lame_3.100.bb} (69%)
 delete mode 100644 
meta/recipes-multimedia/pulseaudio/pulseaudio/pulseaudio-discuss-iochannel-don-t-use-variable-length-array-in-union.patch
 rename meta/recipes-multimedia/pulseaudio/{pulseaudio_10.0.bb => 
pulseaudio_11.1.bb} (61%)

-- 
2.14.2

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


Re: [OE-core] [PATCH] alsa-utils: Install and delete from the same udev-rules-dir

2017-09-21 Thread Tanu Kaskinen
On Thu, 2017-09-21 at 16:56 +0200, Ola x Nilsson wrote:
> The --with-udev-rules-dir option used with udev is exactly what the
> configure script uses, so there is no need for it.
> On the other hand, if we do not have an udev.pc file we should tell
> alsa-utils where to install the rules so we know where they should be
> deleted from.
> 
> Signed-off-by: Ola x Nilsson 
> ---
>  meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb 
> b/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
> index c8f4b861bd..7fc6c29a61 100644
> --- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
> +++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
> @@ -9,14 +9,17 @@ DEPENDS = "alsa-lib ncurses libsamplerate0"
>  
>  PACKAGECONFIG ??= "udev"
>  
> +udevdir = "${nonarch_base_libdir}/udev"
> +
>  # alsabat can be built also without fftw support (with reduced 
> functionality).
>  # It would be better to always enable alsabat, but provide an option for
>  # enabling/disabling fftw. The configure script doesn't support that, however
>  # (at least in any obvious way), so for now we only support alsabat with fftw
>  # or no alsabat at all.
>  PACKAGECONFIG[bat] = "--enable-bat,--disable-bat,fftwf"
> -
> -PACKAGECONFIG[udev] = "--with-udev-rules-dir=`pkg-config --variable=udevdir 
> udev`/rules.d,,udev"
> +# The udev-rules dir is taken from udev.pc.  Set the dir explicitly
> +# when udev is not in our DEPENDS.
> +PACKAGECONFIG[udev] = ",--with-udev-rules-dir=${udevdir}/rules.d,udev"

I'll be reading this recipe every once in a while, and I feel this
comment won't be easy to understand after some time. My suggestion for
an alternative:

# If udev is not in PACKAGECONFIG, we will leave the udev rules
# unpackaged and remove them in do_install(). When removing the rules,
# we need to know where they were installed, which is why we set the
# udev-rules-dir variable here.

>  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 \
> @@ -101,9 +104,13 @@ do_install() {
>   rm ${D}${sbindir}/alsa-info.sh
>   rm -f ${D}${sbindir}/alsabat-test.sh
>  
> - if ${@bb.utils.contains('PACKAGECONFIG', 'udev', 'false', 'true', d)}; 
> then
> - # This is where alsa-utils will install its rules if we don't 
> tell it anything else.
> - rm -rf ${D}${nonarch_base_libdir}/udev
> - rmdir --ignore-fail-on-non-empty ${D}${nonarch_base_libdir}
> + if [ "${@bb.utils.filter('PACKAGECONFIG', 'udev', d)}" ]; then
> + # This is where alsa-utils installs if there is an udev.pc file
> + udevdir=$(pkg-config --variable=udevdir udev)
> + else
> + # This is where we told alsa-utils to install the rules
> + udevdir=${udevdir}
>   fi
> + rm -rf ${D}$udevdir
> + rmdir --ignore-fail-on-non-empty ${D}${udevdir%/*}

This will remove the udev rules also when udev is enabled. Previously
they were removed only when udev was disabled. I suppose this is a
mistake, since you didn't indicate this kind of change in the commit
message.

Some comment about what you're doing would be nice when using
${udevdir%/*}. At least I didn't understand what is happening here
without reading the bash manual.

-- 
Tanu

https://www.patreon.com/tanuk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 2/3] pulseaudio: disable PIE flags when hardened flags are enabled

2017-06-09 Thread Tanu Kaskinen
On Fri, 2017-06-09 at 13:07 +, Khem Raj wrote:
> On Fri, Jun 9, 2017 at 5:56 AM Burton, Ross  wrote:
> 
> > 
> > On 9 June 2017 at 04:41, Khem Raj  wrote:
> > 
> > > +SECURITY_CFLAGS = "${SECURITY_NO_PIE_CFLAGS}"
> > > 
> > 
> > These tend to go into security-flags.inc, not the recipe.
> > 
> 
> I know that's been the case but I think having a global file is error prone
> its better to have it in recipe context since it can get attention at
> upgrade time to test if this has been fixed in new release etc

Do you mean that there's some bug in pulseaudio, and this is a
workaround for it? Is the bug that there are textrels? Ross saw
textrels in pulseaudio before (see the discussion starting at [1]), but
I was unable to reproduce that. If you give instructions for
reproducing the problem, I'll see if I can fix pulseaudio (until then
I'm fine with having a workaround).

[1] 
http://lists.openembedded.org/pipermail/openembedded-core/2017-February/133215.html

-- 
Tanu

https://www.patreon.com/tanuk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/3] alsa-utils: 1.1.3 -> 1.1.4

2017-06-08 Thread Tanu Kaskinen
Changelog: http://alsa-project.org/main/index.php/Changes_v1.1.3_v1.1.4

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../alsa/{alsa-utils-scripts_1.1.3.bb => alsa-utils-scripts_1.1.4.bb} | 0
 .../alsa/{alsa-utils_1.1.3.bb => alsa-utils_1.1.4.bb} | 4 ++--
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.3.bb => 
alsa-utils-scripts_1.1.4.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.3.bb => 
alsa-utils_1.1.4.bb} (97%)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.3.bb 
b/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.4.bb
similarity index 100%
rename from meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.3.bb
rename to meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.4.bb
diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.3.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
similarity index 97%
rename from meta/recipes-multimedia/alsa/alsa-utils_1.1.3.bb
rename to meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
index e6dd5b0a87..c749f32120 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.3.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
@@ -23,8 +23,8 @@ SRC_URI = 
"ftp://ftp.alsa-project.org/pub/utils/alsa-utils-${PV}.tar.bz2 \

file://0001-alsactl-don-t-let-systemd-unit-restore-the-volume-wh.patch \
   "
 
-SRC_URI[md5sum] = "2bf94d3e3410dcc74bb0dae10d46a979"
-SRC_URI[sha256sum] = 
"127217a54eea0f9a49700a2f239a2d4f5384aa094d68df04a8eb80132eb6167c"
+SRC_URI[md5sum] = "01e3934ca5bd22a80c27289d1b0adcdc"
+SRC_URI[sha256sum] = 
"a7831044de92c5bf33bf3365a3f36e49397f4191e934df460ae1ca15138c9d9d"
 
 # On build machines with python-docutils (not python3-docutils !!) installed
 # rst2man (not rst2man.py) is detected and compile fails with
-- 
2.11.0

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


[OE-core] [PATCH 3/3] alsa-plugins: 1.1.1 -> 1.1.4

2017-06-08 Thread Tanu Kaskinen
Changelog: http://alsa-project.org/main/index.php/Changes_v1.1.3_v1.1.4

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../alsa/{alsa-plugins_1.1.1.bb => alsa-plugins_1.1.4.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.1.bb => 
alsa-plugins_1.1.4.bb} (96%)

diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.1.bb 
b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.4.bb
similarity index 96%
rename from meta/recipes-multimedia/alsa/alsa-plugins_1.1.1.bb
rename to meta/recipes-multimedia/alsa/alsa-plugins_1.1.4.bb
index 16686a0445..b7f79b7535 100644
--- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.1.bb
+++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.4.bb
@@ -21,8 +21,8 @@ LIC_FILES_CHKSUM = "\
 "
 
 SRC_URI = "ftp://ftp.alsa-project.org/pub/plugins/${BP}.tar.bz2;
-SRC_URI[md5sum] = "69f9f3e2de3c97fc71d496e91e271fe5"
-SRC_URI[sha256sum] = 
"8ea4d1e082c36528a896a2581e5eb62d4dc2683238e353050d0d624e65f901f1"
+SRC_URI[md5sum] = "de51130a7444b79b2dd3c25e28420754"
+SRC_URI[sha256sum] = 
"530d1c3bdaeb058f2a03607a33b9e16ee5369bfd30a96bc09bd2c69b4ddd1a8a"
 
 DEPENDS += "alsa-lib"
 
-- 
2.11.0

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


[OE-core] [PATCH 0/3] Update the alsa recipes

2017-06-08 Thread Tanu Kaskinen
The following changes since commit 186882ca62bf683b93cd7a250963921b89ba071f:

  buildhistory: skip tests if GitPython module is missing (2017-06-07 16:00:43 
+0100)

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

Tanu Kaskinen (3):
  alsa-lib: 1.1.3 -> 1.1.4.1
  alsa-utils: 1.1.3 -> 1.1.4
  alsa-plugins: 1.1.1 -> 1.1.4

 .../alsa-lib/0001-ucm-parser-needs-limits.h.patch  | 33 --
 .../{alsa-lib_1.1.3.bb => alsa-lib_1.1.4.1.bb} |  5 ++--
 ...alsa-plugins_1.1.1.bb => alsa-plugins_1.1.4.bb} |  4 +--
 ...cripts_1.1.3.bb => alsa-utils-scripts_1.1.4.bb} |  0
 .../{alsa-utils_1.1.3.bb => alsa-utils_1.1.4.bb}   |  4 +--
 5 files changed, 6 insertions(+), 40 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0001-ucm-parser-needs-limits.h.patch
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.3.bb => alsa-lib_1.1.4.1.bb} 
(87%)
 rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.1.bb => 
alsa-plugins_1.1.4.bb} (96%)
 rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.3.bb => 
alsa-utils-scripts_1.1.4.bb} (100%)
 rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.3.bb => 
alsa-utils_1.1.4.bb} (97%)

-- 
2.11.0

-- 
___
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.3 -> 1.1.4.1

2017-06-08 Thread Tanu Kaskinen
Changelogs:
http://alsa-project.org/main/index.php/Changes_v1.1.3_v1.1.4
http://alsa-project.org/main/index.php/Changes_v1.1.4_v1.1.4.1

Dropped backported patch 0001-ucm-parser-needs-limits.h.patch.

Signed-off-by: Tanu Kaskinen <ta...@iki.fi>
---
 .../alsa-lib/0001-ucm-parser-needs-limits.h.patch  | 33 --
 .../{alsa-lib_1.1.3.bb => alsa-lib_1.1.4.1.bb} |  5 ++--
 2 files changed, 2 insertions(+), 36 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/alsa/alsa-lib/0001-ucm-parser-needs-limits.h.patch
 rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.3.bb => alsa-lib_1.1.4.1.bb} 
(87%)

diff --git 
a/meta/recipes-multimedia/alsa/alsa-lib/0001-ucm-parser-needs-limits.h.patch 
b/meta/recipes-multimedia/alsa/alsa-lib/0001-ucm-parser-needs-limits.h.patch
deleted file mode 100644
index 4edaf4d961..00
--- a/meta/recipes-multimedia/alsa/alsa-lib/0001-ucm-parser-needs-limits.h.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From 005ac9d2fa000912c8fb8257020a0471b1c6176c Mon Sep 17 00:00:00 2001
-From: Gustavo Zacarias <gust...@zacarias.com.ar>
-Date: Wed, 21 Dec 2016 19:46:34 -0300
-Subject: [PATCH] ucm: parser needs limits.h
-
-It's using PATH_MAX which is defined there, otherwise the build fails on
-musl libc.
-
-Signed-off-by: Gustavo Zacarias <gust...@zacarias.com.ar>
-Signed-off-by: Takashi Iwai <ti...@suse.de>
-
-Upstream-Status: Accepted [expected in 1.1.4]
-
-Signed-off-by: Tanu Kaskinen <ta...@iki.fi>

- src/ucm/parser.c | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/src/ucm/parser.c b/src/ucm/parser.c
-index c98373a9..f520abc5 100644
 a/src/ucm/parser.c
-+++ b/src/ucm/parser.c
-@@ -32,6 +32,7 @@
- 
- #include "ucm_local.h"
- #include 
-+#include 
- 
- /** The name of the environment variable containing the UCM directory */
- #define ALSA_CONFIG_UCM_VAR "ALSA_CONFIG_UCM"
--- 
-2.11.0
-
diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.3.bb 
b/meta/recipes-multimedia/alsa/alsa-lib_1.1.4.1.bb
similarity index 87%
rename from meta/recipes-multimedia/alsa/alsa-lib_1.1.3.bb
rename to meta/recipes-multimedia/alsa/alsa-lib_1.1.4.1.bb
index 191a0367de..947f7d69e1 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.3.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.4.1.bb
@@ -11,10 +11,9 @@ BBCLASSEXTEND = "native nativesdk"
 SRC_URI = "ftp://ftp.alsa-project.org/pub/lib/${BP}.tar.bz2 \
file://Check-if-wordexp-function-is-supported.patch \
file://avoid-including-sys-poll.h-directly.patch \
-   file://0001-ucm-parser-needs-limits.h.patch \
 "
-SRC_URI[md5sum] = "eefe5992567ba00d6110a540657aaf5c"
-SRC_URI[sha256sum] = 
"71282502184c592c1a008e256c22ed0ba5728ca65e05273ceb480c70f515969c"
+SRC_URI[md5sum] = "29fa3e69122d3cf3e8f0e01a0cb1d183"
+SRC_URI[sha256sum] = 
"91bb870c14d1c7c269213285eeed874fa3d28112077db061a3af8010d0885b76"
 
 inherit autotools pkgconfig
 
-- 
2.11.0

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


  1   2   3   >