Re: [OE-core] [PATCH] libchamplain: Add support for building libchamplain

2020-02-01 Thread Tim Orling
On Sat, Feb 1, 2020 at 6:11 PM Alistair Francis 
wrote:

Maybe some explanation of what is for and why we want it in core would be
helpful here.

Signed-off-by: Alistair Francis 
> ---
>  .../libchamplain/libchamplain_0.12.20.bb | 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 meta/recipes-gnome/libchamplain/
> libchamplain_0.12.20.bb
>
> diff --git a/meta/recipes-gnome/libchamplain/libchamplain_0.12.20.bb
> b/meta/recipes-gnome/libchamplain/libchamplain_0.12.20.bb
> new file mode 100644
> index 00..90e5533015
> --- /dev/null
> +++ b/meta/recipes-gnome/libchamplain/libchamplain_0.12.20.bb
> @@ -0,0 +1,12 @@
> +SUMMARY = "libchamplain is a Gtk widget displaying zoomable and pannable
> maps"
> +LICENSE = "LGPLv2.1"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1"
> +DEPENDS = "glib-2.0 gtk+3 gdk-pixbuf clutter-1.0 clutter-gtk-1.0
> libsoup-2.4"
> +
> +inherit meson gobject-introspection
> +
> +SRCREV = "145e417f32e507b63c21ad4e915b808a6174099e"
> +SRC_URI = "git://github.com/gnome/libchamplain.git"
> +
> +S = "${WORKDIR}/git"
> +
> --
> 2.25.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] libchamplain: Add support for building libchamplain

2020-02-01 Thread Alistair Francis
Signed-off-by: Alistair Francis 
---
 .../libchamplain/libchamplain_0.12.20.bb | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 meta/recipes-gnome/libchamplain/libchamplain_0.12.20.bb

diff --git a/meta/recipes-gnome/libchamplain/libchamplain_0.12.20.bb 
b/meta/recipes-gnome/libchamplain/libchamplain_0.12.20.bb
new file mode 100644
index 00..90e5533015
--- /dev/null
+++ b/meta/recipes-gnome/libchamplain/libchamplain_0.12.20.bb
@@ -0,0 +1,12 @@
+SUMMARY = "libchamplain is a Gtk widget displaying zoomable and pannable maps"
+LICENSE = "LGPLv2.1"
+LIC_FILES_CHKSUM = "file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1"
+DEPENDS = "glib-2.0 gtk+3 gdk-pixbuf clutter-1.0 clutter-gtk-1.0 libsoup-2.4"
+
+inherit meson gobject-introspection
+
+SRCREV = "145e417f32e507b63c21ad4e915b808a6174099e"
+SRC_URI = "git://github.com/gnome/libchamplain.git"
+
+S = "${WORKDIR}/git"
+
-- 
2.25.0

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


Re: [OE-core] [PATCH] gstreamer1.0-plugins-bad: resolve opencv pkg-config in meson build

2020-02-01 Thread Richard Purdie
On Sat, 2020-02-01 at 19:48 +0100, Andrey Zhizhikin wrote:
> A one gentle ping here.

Sorry, autobuilder results are a complete wreak at the moment which is
making review/testing of patches 'problematic'. Mailing list issues,
lack of the SWAT team and a ton of other tangential issues are also not
helping.

There is a backlog building up and I'm quite depressed about it. Tests
failed today, I see if I can do something more tomorrow to get things
unblocked.

Richard

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


Re: [OE-core] [PATCH 0/3][RFT]: kernel-yocto: v5.4 LTS kernel

2020-02-01 Thread Bruce Ashfield
On Fri, Jan 31, 2020 at 1:25 PM Khem Raj  wrote:
>
> On 1/29/20 4:48 AM, Bruce Ashfield wrote:
> > On Wed, Jan 29, 2020 at 2:31 AM Alexander Kanavin
> >  wrote:
> >>
> >> Can these issues be bisected? That's how the two kernel regressions (both 
> >> found last year via ptests) were tracked down to specific commits.
> >>
> >
> > mips64 was already bisected, and reported upstream, not much help
> > there .. I've already reached out to some more hardcore mips folks for
> > more help, so hopefully that works :D
> >
> can you point to link where this thread is

It was on the mips-kernel mailing list, but thanks to our friends at
Cisco, I have a patch in hand for this issue now. They'll follow up to
the original thread on the kernel mailing list with the detailed
findings (also watch for it on the linux-yocto mailing list).

>
> > The musl one didn't bisect in my attempt(s), but in that config it is
> > an easy issue to trigger. I'm out of time to debug it for the next two
> > weeks, hence why I'm broadcasting to see if others want to take a
> > look.
> >
>
> As I saw, I do not see this with latest master-next

ok, cool. I'll queue the mips fix and re-test. Hopefully it has been
sorted out through the latest version bumps.

Bruce

>
> > Bruce
> >
> >> Alex
> >>
> >> On Tue, 28 Jan 2020 at 23:14,  wrote:
> >>>
> >>> From: Bruce Ashfield 
> >>>
> >>> Hi all,
> >>>
> >>> I just wanted to send these to the list, so everyone could see the
> >>> reference kernel that we are planning for the upcoming release.
> >>>
> >>> I have other patches to drop 4.19, 5.2 and make this the default
> >>> kernel for the various reference platforms as well, but I'm not
> >>> sending them, since we still have two outstanding issues:
> >>>
> >>> 1) mips64 init is segfaulting after / during some self tests.
> >>>
> >>> 
> >>> https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/1520/steps/8/logs/step6c
> >>>
> >>> 2) x86 musl is getting a gpf on many commands:
> >>>
> >>> 
> >>> https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1501/steps/8/logs/step1c
> >>>
> >>> I've looked into both, and don't have any great ideas on how to debug
> >>> or fix them.
> >>>
> >>> So if anyone has ideas, or wants to poke at these, feel free to follow up.
> >>> But as of now, we still can't merge the v5.4 kernel as the reference due
> >>> to these remaining problems.
> >>>
> >>> Bruce
> >>>
> >>>
> >>> The following changes since commit 
> >>> ca3993cc4b13d4e661228cee6fb9448adfd0a4ba:
> >>>
> >>>bitbake: tests/fetch: Allow wget upgrade tests to run against a local 
> >>> server (2020-01-22 15:56:39 +)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>>git://git.pokylinux.org/poky-contrib zedd/kernel-oe
> >>>http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-oe
> >>>
> >>> Bruce Ashfield (3):
> >>>linux-yocto: introduce 5.4 recipes
> >>>kern-tools: update Kconfiglib to latest (for 5.4+ kernel)
> >>>kernel-devsrc: update to v5.4+
> >>>
> >>>   .../kern-tools/kern-tools-native_git.bb   |  2 +-
> >>>   meta/recipes-kernel/linux/kernel-devsrc.bb|  8 +--
> >>>   .../linux/linux-yocto-rt_5.4.bb   | 44 +++
> >>>   .../linux/linux-yocto-tiny_5.4.bb | 32 +++
> >>>   meta/recipes-kernel/linux/linux-yocto_5.4.bb  | 54 +++
> >>>   5 files changed, 136 insertions(+), 4 deletions(-)
> >>>   create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_5.4.bb
> >>>   create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_5.4.bb
> >>>   create mode 100644 meta/recipes-kernel/linux/linux-yocto_5.4.bb
> >>>
> >>> --
> >>> 2.19.1
> >>>
> >>> --
> >>> ___
> >>> Openembedded-core mailing list
> >>> Openembedded-core@lists.openembedded.org
> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >
>


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


Re: [OE-core] [PATCH] gstreamer1.0-plugins-bad: resolve opencv pkg-config in meson build

2020-02-01 Thread Andrey Zhizhikin
A one gentle ping here.

On Mon, Jan 27, 2020 at 11:45 AM Andrey Zhizhikin  wrote:
>
> From: Andrey Zhizhikin 
>
> When opencv is picked in PACKAGECONFIG, plugin fails to locate data
> dirs. This is due to meson.build file uses 'test' utility to verify that
> the data dirs path is present and not taking sysroot into prefix.
>
> Introduce additional patch, which picks up PKG_CONFIG_SYSROOT_DIR as
> prefix for 'test' utility to verify the data dir is actually present.
>
> Signed-off-by: Andrey Zhizhikin 
> ---
>  ...issing-opencv-data-dir-in-yocto-buil.patch | 49 +++
>  .../gstreamer1.0-plugins-bad_1.16.1.bb|  1 +
>  2 files changed, 50 insertions(+)
>  create mode 100644 
> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/opencv-resolve-missing-opencv-data-dir-in-yocto-buil.patch
>
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/opencv-resolve-missing-opencv-data-dir-in-yocto-buil.patch
>  
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/opencv-resolve-missing-opencv-data-dir-in-yocto-buil.patch
> new file mode 100644
> index 00..4b6591c0d8
> --- /dev/null
> +++ 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/opencv-resolve-missing-opencv-data-dir-in-yocto-buil.patch
> @@ -0,0 +1,49 @@
> +From f41caae14b618ab815ede3c408e7482b00316e3e Mon Sep 17 00:00:00 2001
> +From: Andrey Zhizhikin 
> +Date: Mon, 27 Jan 2020 10:22:35 +
> +Subject: [PATCH] opencv: resolve missing opencv data dir in yocto build
> +
> +When Yocto build is performed, opencv searches for data dir using simple
> +'test' command, this fails because pkg-config provides an absolute
> +path on the target which needs to be prepended by PKG_CONFIG_SYSROOT_DIR
> +in order for the 'test' utility to pick up the absolute path.
> +
> +Upstream-Status: Inappropriate [OE-specific]
> +
> +Signed-off-by: Andrey Zhizhikin 
> +---
> + ext/opencv/meson.build | 7 ---
> + 1 file changed, 4 insertions(+), 3 deletions(-)
> +
> +diff --git a/ext/opencv/meson.build b/ext/opencv/meson.build
> +index f38b55dfe..a26403482 100644
> +--- a/ext/opencv/meson.build
>  b/ext/opencv/meson.build
> +@@ -78,20 +78,21 @@ else
> + endif
> +
> + if opencv_found
> ++  pkgconf_sysroot = run_command(python3, '-c', 'import os; 
> print(os.environ.get("PKG_CONFIG_SYSROOT_DIR"))').stdout().strip()
> +   opencv_prefix = opencv_dep.get_pkgconfig_variable('prefix')
> +   gstopencv_cargs += ['-DOPENCV_PREFIX="' + opencv_prefix + '"']
> +
> +   # Check the data dir used by opencv for its xml data files
> +   # Use prefix from pkg-config to be compatible with cross-compilation
> +-  r = run_command('test', '-d', opencv_prefix + '/share/opencv')
> ++  r = run_command('test', '-d', pkgconf_sysroot + opencv_prefix + 
> '/share/opencv')
> +   if r.returncode() == 0
> + gstopencv_cargs += '-DOPENCV_PATH_NAME="opencv"'
> +   else
> +-r = run_command('test', '-d', opencv_prefix + '/share/OpenCV')
> ++r = run_command('test', '-d', pkgconf_sysroot + opencv_prefix + 
> '/share/OpenCV')
> + if r.returncode() == 0
> +   gstopencv_cargs += '-DOPENCV_PATH_NAME="OpenCV"'
> + else
> +-  r = run_command('test', '-d', opencv_prefix + '/share/opencv4')
> ++  r = run_command('test', '-d', pkgconf_sysroot + opencv_prefix + 
> '/share/opencv4')
> +   if r.returncode() == 0
> + gstopencv_cargs += '-DOPENCV_PATH_NAME="opencv4"'
> +   else
> +--
> +2.17.1
> +
> diff --git 
> a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.1.bb 
> b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.1.bb
> index 56ae7a179e..024277eeb1 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.1.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.16.1.bb
> @@ -6,6 +6,7 @@ SRC_URI = " \
>  file://fix-maybe-uninitialized-warnings-when-compiling-with-Os.patch \
>  file://avoid-including-sys-poll.h-directly.patch \
>  file://ensure-valid-sentinels-for-gst_structure_get-etc.patch \
> +file://opencv-resolve-missing-opencv-data-dir-in-yocto-buil.patch \
>  "
>  SRC_URI[md5sum] = "24d4d30ecc67d5cbc77c0475bcea1210"
>  SRC_URI[sha256sum] = 
> "56481c95339b8985af13bac19b18bc8da7118c2a7d9440ed70e7dcd799c2adb5"
> --
> 2.17.1
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/2] glibc: Update to final 2.31 release

2020-02-01 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 meta/conf/distro/include/tcmode-default.inc | 2 +-
 meta/recipes-core/glibc/glibc-common.inc| 2 +-
 meta/recipes-core/glibc/glibc-version.inc   | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index aba2baaaba..936db5ae16 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -20,7 +20,7 @@ GCCVERSION ?= "9.%"
 SDKGCCVERSION ?= "${GCCVERSION}"
 BINUVERSION ?= "2.33%"
 GDBVERSION ?= "8.3%"
-GLIBCVERSION ?= "2.30%"
+GLIBCVERSION ?= "2.31"
 LINUXLIBCVERSION ?= "5.4%"
 QEMUVERSION ?= "4.1%"
 GOVERSION ?= "1.13%"
diff --git a/meta/recipes-core/glibc/glibc-common.inc 
b/meta/recipes-core/glibc/glibc-common.inc
index 27534d999f..8d412cc857 100644
--- a/meta/recipes-core/glibc/glibc-common.inc
+++ b/meta/recipes-core/glibc/glibc-common.inc
@@ -22,4 +22,4 @@ ARM_INSTRUCTION_SET_armv6 = "arm"
 #
 COMPATIBLE_HOST_libc-musl_class-target = "null"
 
-PV = "2.30.9000"
+PV = "2.31"
diff --git a/meta/recipes-core/glibc/glibc-version.inc 
b/meta/recipes-core/glibc/glibc-version.inc
index c2cfb7e2f1..f489650f70 100644
--- a/meta/recipes-core/glibc/glibc-version.inc
+++ b/meta/recipes-core/glibc/glibc-version.inc
@@ -1,6 +1,6 @@
-SRCBRANCH ?= "master"
-PV = "2.30.9000"
-SRCREV_glibc ?= "352bb99754ae7c83ff1b974f9c52244e974c9410"
+SRCBRANCH ?= "release/2.31/master"
+PV = "2.31"
+SRCREV_glibc ?= "9ea3686266dca3f004ba874745a4087a89682617"
 SRCREV_localedef ?= "cd9f958c4c94a638fa7b2b4e21627364f1a1a655"
 
 GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git"
-- 
2.25.0

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


[OE-core] [PATCH 1/2] uninative: Recognise ppc64 host ldso

2020-02-01 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 meta/classes/uninative.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 9f8645a36a..70799bbf6d 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -1,4 +1,4 @@
-UNINATIVE_LOADER ?= 
"${UNINATIVE_STAGING_DIR}-uninative/${BUILD_ARCH}-linux/lib/${@bb.utils.contains('BUILD_ARCH',
 'x86_64', 'ld-linux-x86-64.so.2', '', d)}${@bb.utils.contains('BUILD_ARCH', 
'i686', 'ld-linux.so.2', '', d)}${@bb.utils.contains('BUILD_ARCH', 'aarch64', 
'ld-linux-aarch64.so.1', '', d)}"
+UNINATIVE_LOADER ?= 
"${UNINATIVE_STAGING_DIR}-uninative/${BUILD_ARCH}-linux/lib/${@bb.utils.contains('BUILD_ARCH',
 'x86_64', 'ld-linux-x86-64.so.2', '', d)}${@bb.utils.contains('BUILD_ARCH', 
'i686', 'ld-linux.so.2', '', d)}${@bb.utils.contains('BUILD_ARCH', 'aarch64', 
'ld-linux-aarch64.so.1', '', d)}${@bb.utils.contains('BUILD_ARCH', 'ppc64le', 
'ld64.so.2', '', d)}"
 UNINATIVE_STAGING_DIR ?= "${STAGING_DIR}"
 
 UNINATIVE_URL ?= "unset"
-- 
2.25.0

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


[OE-core] [PATCH 0/2] Update to final glibc 2.31

2020-02-01 Thread Khem Raj
recognise ppc64le build host for uninative

The following changes since commit 18b6b2ae819cbf0ef3858944b4cd02ab74df6607:

  Adding memoriam to scottrif (2020-01-31 08:03:08 +)

are available in the Git repository at:

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

Khem Raj (2):
  uninative: Recognise ppc64 host ldso
  glibc: Update to final 2.31 release

 meta/classes/uninative.bbclass  | 2 +-
 meta/conf/distro/include/tcmode-default.inc | 2 +-
 meta/recipes-core/glibc/glibc-common.inc| 2 +-
 meta/recipes-core/glibc/glibc-version.inc   | 6 +++---
 4 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.25.0

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


[OE-core] [PATCH] icu: update SRC_URI

2020-02-01 Thread Alexander Kanavin
New releases of ICU are published on github.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-support/icu/icu_64.2.bb | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-support/icu/icu_64.2.bb 
b/meta/recipes-support/icu/icu_64.2.bb
index 10bac7aac08..44caa437bf7 100644
--- a/meta/recipes-support/icu/icu_64.2.bb
+++ b/meta/recipes-support/icu/icu_64.2.bb
@@ -6,13 +6,18 @@ def icu_download_version(d):
 pvsplit = d.getVar('PV').split('.')
 return pvsplit[0] + "_" + pvsplit[1]
 
+def icu_download_folder(d):
+pvsplit = d.getVar('PV').split('.')
+return pvsplit[0] + "-" + pvsplit[1]
+
 ICU_PV = "${@icu_download_version(d)}"
+ICU_FOLDER = "${@icu_download_folder(d)}"
 
 # http://errors.yoctoproject.org/Errors/Details/20486/
 ARM_INSTRUCTION_SET_armv4 = "arm"
 ARM_INSTRUCTION_SET_armv5 = "arm"
 
-BASE_SRC_URI = 
"http://download.icu-project.org/files/icu4c/${PV}/icu4c-${ICU_PV}-src.tgz";
+BASE_SRC_URI = 
"https://github.com/unicode-org/icu/releases/download/release-${ICU_FOLDER}/icu4c-${ICU_PV}-src.tgz";
 SRC_URI = "${BASE_SRC_URI} \
file://icu-pkgdata-large-cmd.patch \
file://fix-install-manx.patch \
@@ -26,5 +31,5 @@ SRC_URI_append_class-target = "\
 SRC_URI[md5sum] = "a3d18213beec454e3cdec9a3116d6b05"
 SRC_URI[sha256sum] = 
"627d5d8478e6d96fc8c90fed4851239079a561a6a8b9e48b0892f24e82d31d6c"
 
-UPSTREAM_CHECK_REGEX = "(?P\d+(\.\d+)+)/"
-UPSTREAM_CHECK_URI = "http://download.icu-project.org/files/icu4c/";
+UPSTREAM_CHECK_REGEX = "icu4c-(?P\d+(_\d+)+)-src"
+UPSTREAM_CHECK_URI = "https://github.com/unicode-org/icu/releases";
-- 
2.25.0

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


Re: [OE-core] [PATCH 1/5] stress-ng: upgrade 0.10.15 -> 0.10.16

2020-02-01 Thread Alexander Kanavin
I think the patches are in Ross's queue (ross/mut)? Hopefully it's not
forgotten :)

Alex

On Fri, 31 Jan 2020 at 10:32, Mittal, Anuj  wrote:

> Ping
>
> On Wed, 2020-01-22 at 13:46 +0800, Anuj Mittal wrote:
> > Signed-off-by: Anuj Mittal 
> > ---
> >  .../stress-ng/{stress-ng_0.10.15.bb => stress-ng_0.10.16.bb}  | 4
> > ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >  rename meta/recipes-extended/stress-ng/{stress-ng_0.10.15.bb =>
> > stress-ng_0.10.16.bb} (83%)
> >
> > diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.10.15.bb
> > b/meta/recipes-extended/stress-ng/stress-ng_0.10.16.bb
> > similarity index 83%
> > rename from meta/recipes-extended/stress-ng/stress-ng_0.10.15.bb
> > rename to meta/recipes-extended/stress-ng/stress-ng_0.10.16.bb
> > index 5402130fda..e67b82a527 100644
> > --- a/meta/recipes-extended/stress-ng/stress-ng_0.10.15.bb
> > +++ b/meta/recipes-extended/stress-ng/stress-ng_0.10.16.bb
> > @@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = "
> > file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> >  SRC_URI = "
> > https://kernel.ubuntu.com/~cking/tarballs/${BPN}/${BP}.tar.xz \
> > file://0001-Do-not-preserve-ownership-when-installing-
> > example-jo.patch \
> > "
> > -SRC_URI[md5sum] = "303a7276e3a9e3dd03be6cabc9e84a75"
> > -SRC_URI[sha256sum] =
> > "1d0ca8a2f287e13c2d36c01e874d16d67bcb368d8d26563324c9aaf0ddb100c1"
> > +SRC_URI[md5sum] = "a337cd5b1412c53c580e95ee2a9fc77b"
> > +SRC_URI[sha256sum] =
> > "eabfffcffcf53e67765181280456c204ad00214339cfdb3ee2769d58b4a7e304"
> >
> >  DEPENDS = "coreutils-native"
> >
> > --
> > 2.21.1
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


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

2020-02-01 Thread Martin Jansa
In LuneOS we have .bbappend in distro layer adding the UCM files for
MACHINEs we support.

It's not nice, but before this recipe we were adding the same in alsa-lib
bbappend, so it's not worse than before for sure.

BSP layer with .bbappend is a bit worse, because including BSP layer
shouldn't change anything for other MACHINEs. For UCM it's on edge, because
if the files are added correctly, then there won't be any change in
behavior for other MACHINEs in practise, but still people won't be happy
from even alsa-ucm-conf being rebuilt just by adding BSP layer to
bblayers.conf. (In theory distro layers shouldn't influence anything when
their supported DISTRO isn't selected as well, but this rule is much less
enforced, because often it doesn't make much sense to include the distro
layer without using that DISTRO - unlike BSP where multiple BSP layers will
be included just to sequentially build the images for various MACHINEs in
the same build directory).

Maybe nobody replied, because there isn't really good way how to handle
this :/.

On Sat, Feb 1, 2020 at 9:21 AM Tanu Kaskinen  wrote:

> 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 <
> ta...@iki.fi>"
> > >  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 <
> ta...@iki.fi>"
> > >  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 som

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 that are needed by the current machine.

Another approach that would make sense to me (even more than creating a
separate recipe) is to submit your UCM config to ALSA upstream. While
waiting for the change to get accepted to upstream and then later
incorporated in the main alsa-ucm-conf recipe, you could use .bbappend
to add the configuration to the alsa-ucm-conf recipe as a patch.

-- 
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/openembedde