Re: [OE-core] [PATCH v2] mesa: Upgrade to 17.2.1 release
On Thu, 2017-09-21 at 21:43 -0300, Otavio Salvador wrote: > Hello Richard, > > On Thu, Sep 21, 2017 at 7:34 PM, Richard Purdie > wrote: > > > > On Thu, 2017-09-21 at 11:08 -0300, Otavio Salvador wrote: > > > > > > Upgrade to a new stable release and drop patches applied on > > > upstream. > > > > > > For a full release notes, please see: > > > https://mesa3d.org/relnotes/17.2.0.html > > > https://mesa3d.org/relnotes/17.2.1.html > > > > > > Signed-off-by: Fabio Berton > > > Signed-off-by: Otavio Salvador > > > --- > > > > > > Changes in v2: > > > - update to 17.2.1 > > The trouble is this isn't just a "stable release", I didn't check > > the > > patch fully enough initially but now I see this was a 17.1.X -> > > 17.2.X > > change. > The commit log mentions the two release notes. The 17.1 is at 17.1.9 > release but should not receive more fixes. It is advised to move to > 17.2.1 as it is the current release but it is up to you if we will > take this one or 17.1.9. Its not clear from the commit message that we're on 17.1.7, that 17.1.9 (and maybe .8?) exist and that in going to 17.2.X, we're actually changing stable series. Release notes for 17.1.X are not mentioned. Every upstream out there will advise moving to their latest version but that doesn't mean it will work. In fact here it doesn't. > > When I tried building it locally I get: > > > > > > > > checking for x11 xext xdamage >= 1.1 xfixes x11-xcb xcb xcb-glx > > > >= 1.8.1 xcb-dri2 >= 1.8 xxf86vm... yes > > > checking for wayland-scanner... > > > /media/build1/poky/build/tmp/work/core2-64-poky- > > > linux/mesa/2_17.2.1-r0/recipe-sysroot-native/usr/bin/wayland- > > > scanner > > > checking for wayland-client >= 1.11 wayland-server >= 1.11... yes > > > configure: error: wayland-protocols >= 1.8 is needed to compile > > > the wayland platform > > > NOTE: The following config.log files may provide further > > > information. > > and basically I just wiped out a round of autobuilder testing of a > > larger patchset due to this. > That's the reason for autobuilder, right? I do not spawn all > configurations here as I don't own such build monster ... The autobuilder is a last final sanity check so we can test the proposed changes, Ross and I are not here just to queue and test and report back on people's patches. In this case *any* poky build of mesa is failing. That is likely because poky has wayland in distro features and your local configuration does not. > > If people want us to be more flexible about taking "point version" > > changes later into the release cycle, we really need to start > > getting > > better about how these things get tested and how we refer to them > > in > > the commit messages. > See the commit log above. You are frustrated, and I get that, but > commit log mentions BOTH! The commit message implies we're upgrading along a stable release path. Now, I agree had I thought more carefully I'd have realised that to mention release notes of a .0, we must not be. You do call it a stable update though and it really isn't. > > [and yes, the fix is trivial and included below, that isn't really > > the > > point though] > Do you want a v3? or a 17.1.9? Let me know what I can help. I left it building locally overnight and the first fix I mentioned isn't enough, it eventually fails with: | make[4]: *** No rule to make target '/usr/share/wayland-protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml', needed by 'drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h'. Stop. so a v3 would need to figure out and fix that. Who knows what else might then fail. I suspect we might have more success with 17.1.9 but it sounds like I'll be the one who you want to test this... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] lame: fix CVE-2017-13712
From: Kai Kang
Backport patch to fix CVE-2017-13712 for lame.
Signed-off-by: Kai Kang
---
.../lame/lame/CVE-2017-13712.patch | 309 +
meta/recipes-multimedia/lame/lame_3.99.5.bb| 4 +-
2 files changed, 312 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-multimedia/lame/lame/CVE-2017-13712.patch
diff --git a/meta/recipes-multimedia/lame/lame/CVE-2017-13712.patch
b/meta/recipes-multimedia/lame/lame/CVE-2017-13712.patch
new file mode 100644
index 00..f9ec7665ff
--- /dev/null
+++ b/meta/recipes-multimedia/lame/lame/CVE-2017-13712.patch
@@ -0,0 +1,309 @@
+Upstream-Status: Backport
[http://lame.cvs.sourceforge.net/viewvc/lame/lame/libmp3lame/id3tag.c?r1=1.79&r2=1.80]
+
+Backport patch to fix CVE-2017-13712 for lame.
+
+Signed-off-by: Kai Kang
+---
+--- 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 = &gfc->cfg;
++SessionConfig_t const *const cfg = &gfp->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(&gfc->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 @@
+ void
+ id3tag_set_pad(lame_t gfp, size_t n)
+ {
+-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 |= PAD_V2_FLAG;
+ gfc->tag_spec.flags |= ADD_V2_FLAG;
+@@ -583,22 +616,29 @@
+ int
+ id3tag_set_albumart(lame_t gfp, const char *image, size_t size)
+ {
+-int mimetype = 0;
+-unsigned char const *data = (unsigned char const *) image;
+-lame_internal_flags *gfc = gfp->internal_flags;
+-
+-/* determine MIME type from the actual image data */
+-if (2 < size && data[0] == 0xFF && data[1] == 0xD8) {
+-mimetype = MIMETYPE_JPEG;
+-}
+-else if (4 < size && data[0] == 0x89 && strncmp((const char *) &data[1],
"PNG", 3) == 0) {
+-mimetype = MIMETYPE_PNG;
+-}
+-else if (4 < size && strncmp((const char *) data, "GIF8", 4) == 0) {
+-mimetype = MIMETYPE_GIF;
++int mimetype = MIMETYPE_NONE;
++lame_internal_flags *gfc = 0;
++
++if (is_lame_internal_flags_null(gfp)) {
++return 0;
+ }
+-else {
+-return -1;
++gfc = gfp->internal_flags;
++
++if (image != 0) {
++unsigned char const *data = (unsigned char const *) image;
++/* determine MIME type from the actual image data */
++if (2 < size && data[0] == 0xFF && data[1] == 0xD8) {
++mimetype = MIMETYPE_JPEG;
[OE-core] [PATCH 0/1] lame: backport patch to fix CVE-2017-13712
From: Kai Kang The following changes since commit eac8a5cf4212feaf8baf230e9ae991939732141d: oe-build-perf-report-email.py: add cc and bcc options (2017-09-21 23:16:55 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib kangkai/lame http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/lame Kai Kang (1): lame: fix CVE-2017-13712 .../lame/lame/CVE-2017-13712.patch | 309 + meta/recipes-multimedia/lame/lame_3.99.5.bb| 4 +- 2 files changed, 312 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-multimedia/lame/lame/CVE-2017-13712.patch -- 2.14.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] go: Remove mips32r2 from march to get cgo working
On Thu, 2017-09-21 at 10:42 -0700, Khem Raj wrote: > on mips, cgo used mips32r1 and that conflicts with mips32r2 > lets remove it for now and work go upstream to make it work > for golang as well > > Fixes > > > > # runtime/cgo > > cc1: error: '-mips32r2' conflicts with the other architecture > > options, which specify a mips32 processor > Fixes [YOCTO #12108] > > Signed-off-by: Khem Raj > --- > meta/recipes-devtools/go/go-common.inc | 4 > meta/recipes-devtools/go/go_1.9.bb | 2 -- > 2 files changed, 4 insertions(+), 2 deletions(-) I think this causes: https://autobuilder.yocto.io/builders/nightly-world-lsb/builds/486/steps/BuildImages/logs/stdio | # /tmp/go-build282041009/libstd.so | /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world-lsb/build/build/tmp/work/i586-poky-linux/go-runtime/1.9-r0/go/pkg/tool/linux_amd64/link: running i586-poky-linux-gcc failed: exit status 1 | /tmp/go-link-130351246/go.o:(.data.rel.ro+0x36bfcc): undefined reference to `main.init' | /tmp/go-link-130351246/go.o:(.data.rel.ro+0x36bfd0): undefined reference to `main.main' | collect2: error: ld returned 1 exit status | | WARNING: exit code 2 from a shell command. | ERROR: Function failed: do_compile (log file is located at /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world-lsb/build/build/tmp/work/i586-poky-linux/go-runtime/1.9-r0/temp/log.do_compile.29509) NOTE: recipe go-runtime-1.9-r0: task do_compile: Failed ERROR: Task (/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world-lsb/build/meta/recipes-devtools/go/go-runtime_1.9.bb:do_compile) failed with exit code '1' Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] go-dep: Fix build with hardening flags
Signed-off-by: Khem Raj
---
meta/recipes-devtools/go/go-dep_0.3.0.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-devtools/go/go-dep_0.3.0.bb
b/meta/recipes-devtools/go/go-dep_0.3.0.bb
index abfeb48370..20ea792c52 100644
--- a/meta/recipes-devtools/go/go-dep_0.3.0.bb
+++ b/meta/recipes-devtools/go/go-dep_0.3.0.bb
@@ -11,6 +11,10 @@ SRCREV = "7a91b794bbfbf1f3b8b79823799316451127801b"
inherit go
+TUNE_CCARGS_remove = "-march=mips32r2"
+SECURITY_CFLAGS = "${SECURITY_NOPIE_CFLAGS}"
+SECURITY_LDFLAGS = ""
+
GO_INSTALL = "${GO_IMPORT}/cmd/dep"
RDEPENDS_${PN}-dev += "bash"
--
2.14.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [pyro][PATCH] image.bbclass: Sorted ctypes to avoid basehash error
From: Gerson Fernando Budke
When selected multiple subimages a similar error could happend:
Variable do_image_cpio[subimages] value changed \
from 'cpio.gz.u-boot cpio.gz' to 'cpio.gz cpio.gz.u-boot'
To avoid this, 'ctypes' should be sorted at 'gen_conversion_cmds'.
This garantee that 'CONVERSION_CMD_xxx' are always written in tha same
order and consequently 'do_image_cpio' have the same hash.
(From OE-Core rev: 271f1a5f65b8685a1e3645026876251122ef3974)
Signed-off-by: Gerson Fernando Budke
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
---
meta/classes/image.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index ef2b38aeaf..9c9f14a99a 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -453,7 +453,7 @@ python () {
rm_tmp_images = set()
def gen_conversion_cmds(bt):
-for ctype in ctypes:
+for ctype in sorted(ctypes):
if bt.endswith("." + ctype):
type = bt[0:-len(ctype) - 1]
if type.startswith("debugfs_"):
--
2.14.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] linux-firmware: package qat-firmware
On 09/20/2017 12:50 AM, Burton, Ross wrote:
> On 5 September 2017 at 10:27, Liwei Song wrote:
>
>> + ${PN}-qat-license ${PN}-qat_895xcc ${PN}-qat_895xcc_mmp
>> ${PN}-qat_c3xxx ${PN}-qat_c3xxx_mmp ${PN}-qat_c62x ${PN}-qat_c62x_mmp
>> ${PN}-qat_mmp \
>>
>
> *** Error: Package name contains illegal characters, (other than
> [a-z0-9.+-])
>
> You can't use _ in packages, please just use -.
Got it, Thanks, I will resend a V2, please ignore this one.
Thanks,
Liwei.
>
> Ross
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] AUTOREV, tags...
I think it would be nicer if recipes that currently require network access to check repo version info warned, but did not fail to parse. I actually think that allowing AUTOREV at all should be conditional, because it subverts reproducible builds. I'd also guess that if tags change that is not a good sign, so is it really good to check for that? Joe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] mesa: Upgrade to 17.2.1 release
Hello Richard, On Thu, Sep 21, 2017 at 7:34 PM, Richard Purdie wrote: > On Thu, 2017-09-21 at 11:08 -0300, Otavio Salvador wrote: >> Upgrade to a new stable release and drop patches applied on upstream. >> >> For a full release notes, please see: >> https://mesa3d.org/relnotes/17.2.0.html >> https://mesa3d.org/relnotes/17.2.1.html >> >> Signed-off-by: Fabio Berton >> Signed-off-by: Otavio Salvador >> --- >> >> Changes in v2: >> - update to 17.2.1 > > The trouble is this isn't just a "stable release", I didn't check the > patch fully enough initially but now I see this was a 17.1.X -> 17.2.X > change. The commit log mentions the two release notes. The 17.1 is at 17.1.9 release but should not receive more fixes. It is advised to move to 17.2.1 as it is the current release but it is up to you if we will take this one or 17.1.9. > When I tried building it locally I get: > > | checking for x11 xext xdamage >= 1.1 xfixes x11-xcb xcb xcb-glx >= 1.8.1 > xcb-dri2 >= 1.8 xxf86vm... yes > | checking for wayland-scanner... > /media/build1/poky/build/tmp/work/core2-64-poky-linux/mesa/2_17.2.1-r0/recipe-sysroot-native/usr/bin/wayland-scanner > | checking for wayland-client >= 1.11 wayland-server >= 1.11... yes > | configure: error: wayland-protocols >= 1.8 is needed to compile the wayland > platform > | NOTE: The following config.log files may provide further information. > > and basically I just wiped out a round of autobuilder testing of a > larger patchset due to this. That's the reason for autobuilder, right? I do not spawn all configurations here as I don't own such build monster ... > If people want us to be more flexible about taking "point version" > changes later into the release cycle, we really need to start getting > better about how these things get tested and how we refer to them in > the commit messages. See the commit log above. You are frustrated, and I get that, but commit log mentions BOTH! > [and yes, the fix is trivial and included below, that isn't really the > point though] Do you want a v3? or a 17.1.9? Let me know what I can help. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2] llvm: Use the SRCREV past final 5.0 release
Signed-off-by: Khem Raj
---
Changes in V2: Bump patch version to 1
meta/recipes-devtools/llvm/llvm_git.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/llvm/llvm_git.bb
b/meta/recipes-devtools/llvm/llvm_git.bb
index 632178fd77..884e2ae0fb 100644
--- a/meta/recipes-devtools/llvm/llvm_git.bb
+++ b/meta/recipes-devtools/llvm/llvm_git.bb
@@ -19,9 +19,9 @@ PROVIDES += "llvm${PV}"
LLVM_RELEASE = "${PV}"
LLVM_DIR = "llvm${LLVM_RELEASE}"
-SRCREV = "9a5c88cbb54a0ce3a67c4f539f5e590a089b"
+SRCREV = "81029f142231bde8e119becda112a2173f1459c9"
PV = "5.0"
-PATCH_VERSION = "0"
+PATCH_VERSION = "1"
SRC_URI =
"git://github.com/llvm-mirror/llvm.git;branch=release_50;protocol=http \
file://0001-llvm-TargetLibraryInfo-Undefine-libc-functions-if-th.patch \
file://0002-llvm-allow-env-override-of-exe-path.patch \
--
2.14.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] mesa: Upgrade to 17.2.1 release
On Thu, 2017-09-21 at 11:08 -0300, Otavio Salvador wrote:
> Upgrade to a new stable release and drop patches applied on upstream.
>
> For a full release notes, please see:
> https://mesa3d.org/relnotes/17.2.0.html
> https://mesa3d.org/relnotes/17.2.1.html
>
> Signed-off-by: Fabio Berton
> Signed-off-by: Otavio Salvador
> ---
>
> Changes in v2:
> - update to 17.2.1
The trouble is this isn't just a "stable release", I didn't check the
patch fully enough initially but now I see this was a 17.1.X -> 17.2.X
change.
When I tried building it locally I get:
| checking for x11 xext xdamage >= 1.1 xfixes x11-xcb xcb xcb-glx >= 1.8.1
xcb-dri2 >= 1.8 xxf86vm... yes
| checking for wayland-scanner...
/media/build1/poky/build/tmp/work/core2-64-poky-linux/mesa/2_17.2.1-r0/recipe-sysroot-native/usr/bin/wayland-scanner
| checking for wayland-client >= 1.11 wayland-server >= 1.11... yes
| configure: error: wayland-protocols >= 1.8 is needed to compile the wayland
platform
| NOTE: The following config.log files may provide further information.
and basically I just wiped out a round of autobuilder testing of a
larger patchset due to this.
If people want us to be more flexible about taking "point version"
changes later into the release cycle, we really need to start getting
better about how these things get tested and how we refer to them in
the commit messages.
[and yes, the fix is trivial and included below, that isn't really the
point though]
Cheers,
Richard
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 4f31ed255c3..cab8e4bfe73 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -45,7 +45,7 @@ X11_DEPS = "xf86driproto glproto virtual/libx11 libxext
libxxf86vm libxdamage li
# "x11" requires "opengl"
PACKAGECONFIG[x11] = "--enable-glx-tls,--disable-glx,${X11_DEPS}"
PACKAGECONFIG[xvmc] = "--enable-xvmc,--disable-xvmc,libxvmc"
-PACKAGECONFIG[wayland] = ",,wayland-native wayland libdrm"
+PACKAGECONFIG[wayland] = ",,wayland-native wayland libdrm wayland-protocols"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] llvm: Use the SRCREV past final 5.0 release
Signed-off-by: Khem Raj
---
meta/recipes-devtools/llvm/llvm_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/llvm/llvm_git.bb
b/meta/recipes-devtools/llvm/llvm_git.bb
index 632178fd77..5ea7033ec7 100644
--- a/meta/recipes-devtools/llvm/llvm_git.bb
+++ b/meta/recipes-devtools/llvm/llvm_git.bb
@@ -19,7 +19,7 @@ PROVIDES += "llvm${PV}"
LLVM_RELEASE = "${PV}"
LLVM_DIR = "llvm${LLVM_RELEASE}"
-SRCREV = "9a5c88cbb54a0ce3a67c4f539f5e590a089b"
+SRCREV = "81029f142231bde8e119becda112a2173f1459c9"
PV = "5.0"
PATCH_VERSION = "0"
SRC_URI =
"git://github.com/llvm-mirror/llvm.git;branch=release_50;protocol=http \
--
2.14.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [U-Boot] [PATCH] u-boot: Upgrade to 2017.09
On 09/19/2017 04:15 AM, Marek Vasut wrote: > On 09/18/2017 06:06 PM, Tom Rini wrote: >> On Mon, Sep 18, 2017 at 04:51:31PM +0100, Burton, Ross wrote: >>> On 18 September 2017 at 16:46, Otavio Salvador < >>> otavio.salva...@ossystems.com.br> wrote: >>> What is the policy on doing u-boot version upgrades this late in the release cycle? SHouldn't this wait until after the release? Why? It is just another recipe and we are upgrading to the final release. As Martin said, it was already broken. I'll take the responsibility to fix it. But as other packages, upgrades has risk and we have more than enough time to proper fix it. >>> >>> Why? Because it was merged to master after the freeze. >>> >>> Personally I'm of the opinion that u-boot is one of those special recipes >>> that if an upgrade appears just after freeze, we consider it. If we don't >>> keep it up to date BSPs won't use the recipe, and we'll be back to every >>> BSP layer containing its own special copy of the u-boot recipe. >> >> Also please note that U-Boot has a rather regular and public release >> schedule: http://www.denx.de/wiki/U-Boot/ReleaseCycle so you can have a >> good idea beforehand if you want to grab something for a release or not. >> >> Personally, I would like to see this in. But the security issue that's >> been disclosed now is "resolved" just by not enabling functionality that >> no one was enabling in mainline, and will be removed in the next >> release, so don't feel you need to pull it in on those grounds. > > I agree that the 2017.09 upgrade is a good idea. > OK, I just wanted to make sure everyone was on the same page about timing of the update. We certainly don't want very many recipes to decide they are special and take version bumps right up to release. Philip -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
On Thu, Sep 21, 2017 at 04:20:30PM -0500, Mark Hatle wrote: > On 9/21/17 4:15 PM, Otavio Salvador wrote: > > On Thu, Sep 21, 2017 at 2:46 PM, Tom Rini wrote: > >> When we have been told to use the UUID we should also update the fstab > >> to make use of PARTUUID instead of hard-coding the device in question. > >> This will make the resulting image much more portable. > >> > >> Signed-off-by: Tom Rini > > > > Adding more features which changes the fstab goes to the opposite > > direction of reproducible builds; is it desirable? > > There should be a corresponding way to specify the UUID for a generated > partition. This would allow someone to pre-allocate the UUID and use it for > their generated image, and thus the reproducible build. WIC does not today, but the underlying tools do, allow you to specify the UUID to use, yes. -- Tom signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
On 9/21/17 4:15 PM, Otavio Salvador wrote: > On Thu, Sep 21, 2017 at 2:46 PM, Tom Rini wrote: >> When we have been told to use the UUID we should also update the fstab >> to make use of PARTUUID instead of hard-coding the device in question. >> This will make the resulting image much more portable. >> >> Signed-off-by: Tom Rini > > Adding more features which changes the fstab goes to the opposite > direction of reproducible builds; is it desirable? > > There should be a corresponding way to specify the UUID for a generated partition. This would allow someone to pre-allocate the UUID and use it for their generated image, and thus the reproducible build. --Mark -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
On Thu, Sep 21, 2017 at 06:15:56PM -0300, Otavio Salvador wrote: > On Thu, Sep 21, 2017 at 2:46 PM, Tom Rini wrote: > > When we have been told to use the UUID we should also update the fstab > > to make use of PARTUUID instead of hard-coding the device in question. > > This will make the resulting image much more portable. > > > > Signed-off-by: Tom Rini > > Adding more features which changes the fstab goes to the opposite > direction of reproducible builds; is it desirable? UUIDs are already something that would be different every time. It's also (at least with just this patch) opt-in. The second patch shows that it's quite useful (and there's real-world examples, ie Minnow SD card vs USB/SATA, various ARM systems where mmcblkX can change depending on regulators. -- Tom signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
On Thu, Sep 21, 2017 at 2:46 PM, Tom Rini wrote: > When we have been told to use the UUID we should also update the fstab > to make use of PARTUUID instead of hard-coding the device in question. > This will make the resulting image much more portable. > > Signed-off-by: Tom Rini Adding more features which changes the fstab goes to the opposite direction of reproducible builds; is it desirable? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OpenEmbedded Developer Meeting Oct 22, 2017 in Prague (before ELCE)
On 09/21/2017 02:32 PM, akuster808 wrote: > > > On 09/21/2017 01:27 PM, Philip Balister wrote: >> On 09/20/2017 01:50 AM, Mike Looijmans wrote: >>> On 18-09-17 18:25, Trevor Woerner wrote: Hi Mike, On Mon, Sep 18, 2017 at 8:45 AM, Mike Looijmans wrote: > I can probably bring some work (e.g. Zynq MPSoC board) and fun > (settop box) > hardware along to demonstrate what I'm using OE for. Any chance you could set something up that could be on display at the Yocto booth during the conference? >>> Depends on what I'll be able tug along in my luggage on the airplane, >>> but whatever I can bring is probably suited for public display. A few >>> circuit boards will certainly fit, so if the stand could provide a HDMI >>> monitor (or TV) to connect them to that'd be awesome. >> I'd love to see some different things on the stand. Make sure you help >> explain to people why the Yocto Porject and OpenEmbedded are important >> to you and your product. > Philip, > > Since you are the OE rep to the Yocto Project, can you make sure this is > OK with them. There could be space or limitations at their booth. I mentioned it to Jefro, I'm also making a guess he has something based on a Xilinx product, who are members. Philip > > Thanks, > - Armin >> >> Philip >> >> >> >>> M. >>> >>> >>> Kind regards, >>> >>> Mike Looijmans >>> System Expert >>> >>> TOPIC Products >>> Materiaalweg 4, NL-5681 RJ Best >>> Postbus 440, NL-5680 AK Best >>> Telefoon: +31 (0) 499 33 69 79 >>> E-mail: mike.looijm...@topicproducts.com >>> Website: www.topicproducts.com >>> >>> Please consider the environment before printing this e-mail >>> >>> >>> Visit us at the Space Tech Expo Europe (Stand E-71) >>> > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OpenEmbedded Developer Meeting Oct 22, 2017 in Prague (before ELCE)
On 09/21/2017 01:27 PM, Philip Balister wrote: > On 09/20/2017 01:50 AM, Mike Looijmans wrote: >> On 18-09-17 18:25, Trevor Woerner wrote: >>> Hi Mike, >>> >>> On Mon, Sep 18, 2017 at 8:45 AM, Mike Looijmans >>> wrote: I can probably bring some work (e.g. Zynq MPSoC board) and fun (settop box) hardware along to demonstrate what I'm using OE for. >>> Any chance you could set something up that could be on display at the >>> Yocto booth during the conference? >> Depends on what I'll be able tug along in my luggage on the airplane, >> but whatever I can bring is probably suited for public display. A few >> circuit boards will certainly fit, so if the stand could provide a HDMI >> monitor (or TV) to connect them to that'd be awesome. > I'd love to see some different things on the stand. Make sure you help > explain to people why the Yocto Porject and OpenEmbedded are important > to you and your product. Philip, Since you are the OE rep to the Yocto Project, can you make sure this is OK with them. There could be space or limitations at their booth. Thanks, - Armin > > Philip > > > >> M. >> >> >> Kind regards, >> >> Mike Looijmans >> System Expert >> >> TOPIC Products >> Materiaalweg 4, NL-5681 RJ Best >> Postbus 440, NL-5680 AK Best >> Telefoon: +31 (0) 499 33 69 79 >> E-mail: mike.looijm...@topicproducts.com >> Website: www.topicproducts.com >> >> Please consider the environment before printing this e-mail >> >> >> Visit us at the Space Tech Expo Europe (Stand E-71) >> -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] OpenEmbedded Developer Meeting Oct 22, 2017 in Prague (before ELCE)
On 09/20/2017 01:50 AM, Mike Looijmans wrote: > On 18-09-17 18:25, Trevor Woerner wrote: >> Hi Mike, >> >> On Mon, Sep 18, 2017 at 8:45 AM, Mike Looijmans >> wrote: >>> I can probably bring some work (e.g. Zynq MPSoC board) and fun >>> (settop box) >>> hardware along to demonstrate what I'm using OE for. >> >> Any chance you could set something up that could be on display at the >> Yocto booth during the conference? > > Depends on what I'll be able tug along in my luggage on the airplane, > but whatever I can bring is probably suited for public display. A few > circuit boards will certainly fit, so if the stand could provide a HDMI > monitor (or TV) to connect them to that'd be awesome. I'd love to see some different things on the stand. Make sure you help explain to people why the Yocto Porject and OpenEmbedded are important to you and your product. Philip > > M. > > > Kind regards, > > Mike Looijmans > System Expert > > TOPIC Products > Materiaalweg 4, NL-5681 RJ Best > Postbus 440, NL-5680 AK Best > Telefoon: +31 (0) 499 33 69 79 > E-mail: mike.looijm...@topicproducts.com > Website: www.topicproducts.com > > Please consider the environment before printing this e-mail > > > Visit us at the Space Tech Expo Europe (Stand E-71) > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] wic: Update canned-wks for systemd to use UUID everywhere
With systemd, the mounting of the swap partition is handled via systemd and will mount it, regardless of if PARTUUID is parsed or not. systemd has a runtime dependency on util-linux-mount so PARTUUID for regular mount points will be handled correctly. Make all partitions that we add to the image make use of UUIDs for maximum portability. Signed-off-by: Tom Rini --- Note that while systemd will automatically mount swap for you, busybox swapon/swapoff do not understand PARTUUID syntax. util-linux-swaponoff is required for swapon -a / swapoff -a to work as expected from the command line. --- scripts/lib/wic/canned-wks/systemd-bootdisk.wks | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/lib/wic/canned-wks/systemd-bootdisk.wks b/scripts/lib/wic/canned-wks/systemd-bootdisk.wks index 4bd9d6a65fd7..95d7b97a6063 100644 --- a/scripts/lib/wic/canned-wks/systemd-bootdisk.wks +++ b/scripts/lib/wic/canned-wks/systemd-bootdisk.wks @@ -2,10 +2,10 @@ # long-description: Creates a partitioned EFI disk image that the user # can directly dd to boot media. The selected bootloader is systemd-boot. -part /boot --source bootimg-efi --sourceparams="loader=systemd-boot" --ondisk sda --label msdos --active --align 1024 +part /boot --source bootimg-efi --sourceparams="loader=systemd-boot" --ondisk sda --label msdos --active --align 1024 --use-uuid part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align 1024 --use-uuid -part swap --ondisk sda --size 44 --label swap1 --fstype=swap +part swap --ondisk sda --size 44 --label swap1 --fstype=swap --use-uuid bootloader --ptable gpt --timeout=5 --append="rootwait rootfstype=ext4 console=ttyS0,115200 console=tty0" -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
When we have been told to use the UUID we should also update the fstab
to make use of PARTUUID instead of hard-coding the device in question.
This will make the resulting image much more portable.
Signed-off-by: Tom Rini
---
scripts/lib/wic/plugins/imager/direct.py | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/scripts/lib/wic/plugins/imager/direct.py
b/scripts/lib/wic/plugins/imager/direct.py
index a6abc3d09ef0..b0da54511b77 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -139,9 +139,12 @@ class DirectPlugin(ImagerPlugin):
or part.mountpoint == "/":
continue
-# mmc device partitions are named mmcblk0p1, mmcblk0p2..
-prefix = 'p' if part.disk.startswith('mmcblk') else ''
-device_name = "/dev/%s%s%d" % (part.disk, prefix, part.realnum)
+if part.use_uuid:
+device_name = "PARTUUID=%s" % part.uuid
+else:
+# mmc device partitions are named mmcblk0p1, mmcblk0p2..
+prefix = 'p' if part.disk.startswith('mmcblk') else ''
+device_name = "/dev/%s%s%d" % (part.disk, prefix, part.realnum)
opts = part.fsopts if part.fsopts else "defaults"
line = "\t".join([device_name, part.mountpoint, part.fstype,
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] gstreamer1.0-libav: Fix build on mips
Signed-off-by: Khem Raj
---
...a.c-Fix-build-by-Including-libavcodec-hev.patch | 33 ++
.../gstreamer/gstreamer1.0-libav_1.12.2.bb | 1 +
2 files changed, 34 insertions(+)
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/0001-hevcpred_msa.c-Fix-build-by-Including-libavcodec-hev.patch
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/0001-hevcpred_msa.c-Fix-build-by-Including-libavcodec-hev.patch
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/0001-hevcpred_msa.c-Fix-build-by-Including-libavcodec-hev.patch
new file mode 100644
index 00..afbfc84db5
--- /dev/null
+++
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/0001-hevcpred_msa.c-Fix-build-by-Including-libavcodec-hev.patch
@@ -0,0 +1,33 @@
+From b5226c096a0b7049874858e94a59d43e10ba3fd2 Mon Sep 17 00:00:00 2001
+From: Khem Raj
+Date: Thu, 21 Sep 2017 10:22:56 -0700
+Subject: [PATCH] hevcpred_msa.c: Fix build by Including libavcodec/hevcdec.h
+
+src/libavcodec/mips/hevcpred_msa.c:1913:32: error: unknown type name
'HEVCContext'; did you mean 'HEVCPredContext'?
+ void ff_intra_pred_8_16x16_msa(HEVCContext *s, int x0, int y0, int c_idx)
+^~~
+HEVCPredContext
+
+Signed-off-by: Khem Raj
+---
+Upstream-Status: Pending
+
+ gst-libs/ext/libav/libavcodec/mips/hevcpred_msa.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gst-libs/ext/libav/libavcodec/mips/hevcpred_msa.c
b/gst-libs/ext/libav/libavcodec/mips/hevcpred_msa.c
+index 6a3b281..963c64c 100644
+--- a/gst-libs/ext/libav/libavcodec/mips/hevcpred_msa.c
b/gst-libs/ext/libav/libavcodec/mips/hevcpred_msa.c
+@@ -18,7 +18,7 @@
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+
+-#include "libavcodec/hevc.h"
++#include "libavcodec/hevcdec.h"
+ #include "libavutil/mips/generic_macros_msa.h"
+ #include "hevcpred_mips.h"
+
+--
+2.14.1
+
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.12.2.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.12.2.bb
index 6c5f779ebf..3b5bbd1507 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.12.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.12.2.bb
@@ -13,6 +13,7 @@ SRC_URI =
"http://gstreamer.freedesktop.org/src/gst-libav/gst-libav-${PV}.tar.xz
file://workaround-to-build-gst-libav-for-i586-with-gcc.patch \
file://mips64_cpu_detection.patch \
file://0001-configure-check-for-armv7ve-variant.patch \
+
file://0001-hevcpred_msa.c-Fix-build-by-Including-libavcodec-hev.patch \
"
SRC_URI[md5sum] = "8788aecc032a287227b4bd239d1b998a"
SRC_URI[sha256sum] =
"5bb735b9bb218b652ae4071ea6f6be8eaae55e9d3233aec2f36b882a27542db3"
--
2.14.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] go: Remove mips32r2 from march to get cgo working
on mips, cgo used mips32r1 and that conflicts with mips32r2
lets remove it for now and work go upstream to make it work
for golang as well
Fixes
| # runtime/cgo
| cc1: error: '-mips32r2' conflicts with the other architecture options, which
specify a mips32 processor
Fixes [YOCTO #12108]
Signed-off-by: Khem Raj
---
meta/recipes-devtools/go/go-common.inc | 4
meta/recipes-devtools/go/go_1.9.bb | 2 --
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/go/go-common.inc
b/meta/recipes-devtools/go/go-common.inc
index ce1eb86812..41f661bc4e 100644
--- a/meta/recipes-devtools/go/go-common.inc
+++ b/meta/recipes-devtools/go/go-common.inc
@@ -20,3 +20,7 @@ B = "${S}"
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
SSTATE_SCAN_CMD = "true"
+
+TUNE_CCARGS_remove = "-march=mips32r2"
+SECURITY_CFLAGS = "${SECURITY_NOPIE_CFLAGS}"
+SECURITY_LDFLAGS = ""
diff --git a/meta/recipes-devtools/go/go_1.9.bb
b/meta/recipes-devtools/go/go_1.9.bb
index 08ab793f86..c67e2cb050 100644
--- a/meta/recipes-devtools/go/go_1.9.bb
+++ b/meta/recipes-devtools/go/go_1.9.bb
@@ -1,4 +1,2 @@
require go-${PV}.inc
require go-target.inc
-TUNE_CCARGS_remove = "-march=mips32r2"
-SECURITY_PIE_CFLAGS_remove = "-fPIE -pie"
--
2.14.1
--
___
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
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
[OE-core] [PATCH] alsa-utils: Install and delete from the same udev-rules-dir
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"
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%/*}
}
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v9] kernel-devicetree.bbclass: Add support to generate append to kernel
On Thu, Sep 21, 2017 at 11:50 AM, Tom Rini wrote:
> On Thu, Sep 21, 2017 at 11:48:39AM -0300, Otavio Salvador wrote:
>> On Thu, Sep 21, 2017 at 11:37 AM, Tom Rini wrote:
>> > On Thu, Sep 21, 2017 at 10:58:33AM -0300, Otavio Salvador wrote:
>> >
>> >> The are use cases where the Device Tree appended to the kernel is
>> >> convinient, so we generate the bundle concatenating the kernel (and
>> >> potentionally the initramfs) and the Device Tree binaries.
>> >>
>> >> To enable it, set KERNEL_DEVICETREE_BUNDLE variable to '1'
>> >>
>> >> Signed-off-by: Otavio Salvador
>> > [snip]
>> >> diff --git a/meta/classes/kernel-devicetree.bbclass
>> >> b/meta/classes/kernel-devicetree.bbclass
>> >> index 72814ca224..6e08be4b70 100644
>> >> --- a/meta/classes/kernel-devicetree.bbclass
>> >> +++ b/meta/classes/kernel-devicetree.bbclass
>> >> @@ -1,6 +1,13 @@
>> >> # Support for device tree generation
>> >> -PACKAGES_append = " kernel-devicetree"
>> >> +PACKAGES_append = " \
>> >> +kernel-devicetree \
>> >> +${@['kernel-image-zimage-bundle',
>> >> ''][d.getVar('KERNEL_DEVICETREE_BUNDLE') != '1']} \
>> >> +"
>> >> FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb
>> >> /${KERNEL_IMAGEDEST}/*.dtbo"
>> >> +FILES_kernel-image-zimage-bundle =
>> >> "/${KERNEL_IMAGEDEST}/zImage-*.dtb.bin"
>> >
>> > Frankly, the most common use case today for still needing to concat the
>> > dtb to the zImage is for very legacy U-Boot where 'bootz' doesn't exist,
>> > so we need uImage (which is in turn why we need to patch the kernel
>> > build process, or manually run mkimage, it must be (zImage + dtb) +
>> > uImage-header).
>>
>> There is also the use case of a single binary to boot. We use it in a
>> customer project and we found it quite useful.
>
> That's what FIT is for.
Without U-Boot.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v9] kernel-devicetree.bbclass: Add support to generate append to kernel
On Thu, Sep 21, 2017 at 11:48:39AM -0300, Otavio Salvador wrote:
> On Thu, Sep 21, 2017 at 11:37 AM, Tom Rini wrote:
> > On Thu, Sep 21, 2017 at 10:58:33AM -0300, Otavio Salvador wrote:
> >
> >> The are use cases where the Device Tree appended to the kernel is
> >> convinient, so we generate the bundle concatenating the kernel (and
> >> potentionally the initramfs) and the Device Tree binaries.
> >>
> >> To enable it, set KERNEL_DEVICETREE_BUNDLE variable to '1'
> >>
> >> Signed-off-by: Otavio Salvador
> > [snip]
> >> diff --git a/meta/classes/kernel-devicetree.bbclass
> >> b/meta/classes/kernel-devicetree.bbclass
> >> index 72814ca224..6e08be4b70 100644
> >> --- a/meta/classes/kernel-devicetree.bbclass
> >> +++ b/meta/classes/kernel-devicetree.bbclass
> >> @@ -1,6 +1,13 @@
> >> # Support for device tree generation
> >> -PACKAGES_append = " kernel-devicetree"
> >> +PACKAGES_append = " \
> >> +kernel-devicetree \
> >> +${@['kernel-image-zimage-bundle',
> >> ''][d.getVar('KERNEL_DEVICETREE_BUNDLE') != '1']} \
> >> +"
> >> FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb
> >> /${KERNEL_IMAGEDEST}/*.dtbo"
> >> +FILES_kernel-image-zimage-bundle = "/${KERNEL_IMAGEDEST}/zImage-*.dtb.bin"
> >
> > Frankly, the most common use case today for still needing to concat the
> > dtb to the zImage is for very legacy U-Boot where 'bootz' doesn't exist,
> > so we need uImage (which is in turn why we need to patch the kernel
> > build process, or manually run mkimage, it must be (zImage + dtb) +
> > uImage-header).
>
> There is also the use case of a single binary to boot. We use it in a
> customer project and we found it quite useful.
That's what FIT is for.
--
Tom
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v9] kernel-devicetree.bbclass: Add support to generate append to kernel
On Thu, Sep 21, 2017 at 11:37 AM, Tom Rini wrote:
> On Thu, Sep 21, 2017 at 10:58:33AM -0300, Otavio Salvador wrote:
>
>> The are use cases where the Device Tree appended to the kernel is
>> convinient, so we generate the bundle concatenating the kernel (and
>> potentionally the initramfs) and the Device Tree binaries.
>>
>> To enable it, set KERNEL_DEVICETREE_BUNDLE variable to '1'
>>
>> Signed-off-by: Otavio Salvador
> [snip]
>> diff --git a/meta/classes/kernel-devicetree.bbclass
>> b/meta/classes/kernel-devicetree.bbclass
>> index 72814ca224..6e08be4b70 100644
>> --- a/meta/classes/kernel-devicetree.bbclass
>> +++ b/meta/classes/kernel-devicetree.bbclass
>> @@ -1,6 +1,13 @@
>> # Support for device tree generation
>> -PACKAGES_append = " kernel-devicetree"
>> +PACKAGES_append = " \
>> +kernel-devicetree \
>> +${@['kernel-image-zimage-bundle',
>> ''][d.getVar('KERNEL_DEVICETREE_BUNDLE') != '1']} \
>> +"
>> FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb
>> /${KERNEL_IMAGEDEST}/*.dtbo"
>> +FILES_kernel-image-zimage-bundle = "/${KERNEL_IMAGEDEST}/zImage-*.dtb.bin"
>
> Frankly, the most common use case today for still needing to concat the
> dtb to the zImage is for very legacy U-Boot where 'bootz' doesn't exist,
> so we need uImage (which is in turn why we need to patch the kernel
> build process, or manually run mkimage, it must be (zImage + dtb) +
> uImage-header).
There is also the use case of a single binary to boot. We use it in a
customer project and we found it quite useful.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v9] kernel-devicetree.bbclass: Add support to generate append to kernel
On Thu, Sep 21, 2017 at 10:58:33AM -0300, Otavio Salvador wrote:
> The are use cases where the Device Tree appended to the kernel is
> convinient, so we generate the bundle concatenating the kernel (and
> potentionally the initramfs) and the Device Tree binaries.
>
> To enable it, set KERNEL_DEVICETREE_BUNDLE variable to '1'
>
> Signed-off-by: Otavio Salvador
[snip]
> diff --git a/meta/classes/kernel-devicetree.bbclass
> b/meta/classes/kernel-devicetree.bbclass
> index 72814ca224..6e08be4b70 100644
> --- a/meta/classes/kernel-devicetree.bbclass
> +++ b/meta/classes/kernel-devicetree.bbclass
> @@ -1,6 +1,13 @@
> # Support for device tree generation
> -PACKAGES_append = " kernel-devicetree"
> +PACKAGES_append = " \
> +kernel-devicetree \
> +${@['kernel-image-zimage-bundle',
> ''][d.getVar('KERNEL_DEVICETREE_BUNDLE') != '1']} \
> +"
> FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb
> /${KERNEL_IMAGEDEST}/*.dtbo"
> +FILES_kernel-image-zimage-bundle = "/${KERNEL_IMAGEDEST}/zImage-*.dtb.bin"
Frankly, the most common use case today for still needing to concat the
dtb to the zImage is for very legacy U-Boot where 'bootz' doesn't exist,
so we need uImage (which is in turn why we need to patch the kernel
build process, or manually run mkimage, it must be (zImage + dtb) +
uImage-header).
--
Tom
signature.asc
Description: Digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/52] Pyro-next pull request
Please consider this for pyro. Have clean AB build. Contains kernel security fixes, bsp kernel updates and build fixes The following changes since commit 072430b9b3a78b318b66371c36e2986d2ed5cba4: bitbake.conf: add bzr to HOSTTOOLS_NONFATAL (2017-09-13 22:13:00 +0100) are available in the git repository at: http://git.yoctoproject.org/git/poky-contrib akuster/pyro-next http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akuster/pyro-next Alejandro Hernandez (17): linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.1 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.4 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.9 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.10 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.4 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.9 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.10 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.1 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.4 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.9 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.4 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.9 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.10 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.4 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.10 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.9 linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.1 Alexander Kanavin (2): package_rpm.bbclass: use multithreaded xz compression package_rpm.bbclass: disable generation of .build-id links Armin Kuster (3): linuux-yocto/4.1: update to 4.1.43 plus bluetooth CVE-2017-1000251 meta-yocto-bsp: bump 4.1 to latest linux stable kernel for the non-x86 BSPs linux-yocto/4.1: generix86* bsp fix perf issue with gcc >=7 Awais Belal (1): bitbake: toaster: Order column in Tasks selectable Bruce Ashfield (5): linux-yocto/4.4: update to v4.4.87 linux-yocto/4.9: update to v4.9.49 linux-yocto/4.10: bluetooth: CVE-2017-1000251 linux-yocto/4.4: bluetooth: CVE-2017-1000251 linux-yocto/4.9: bluetooth: CVE-2017-1000251 David Reyna (3): bitbake: toaster: display error when the fstype select is empty bitbake: toaster: edit column list not sorted bitbake: toaster: recipe links broken for default layers Jose Alarcon (2): rootfs-postcommands: remove empty line rootfs-postcommands: add test for unsatisfied RRECOMMENDS Juro Bystricky (1): gcc-6.3.inc: Use ucontext_t not struct ucontext. Kevin Hao (5): meta-yocto-bsp: bump to the latest linux stable kernel for the non-x86 BSPs meta-yocto-bsp: bump to the latest linux stable kernel for the non-x86 BSPs meta-yocto-bsp: bump to the latest linux stable kernel for the non-x86 BSPs meta-yocto-bsp: bump to the latest linux stable kernel for the non-x86 BSPs meta-yocto-bsp: bump to the latest linux stable kernel for the non-x86 BSPs Khem Raj (1): rootfs-postcommands.bbclass: Filter out dangling symlinks in ssh_allow_empty_password() Leonardo Sandoval (1): waffle: fix REQUIRED_DISTRO_FEATURES and PACKAGECONFIG virtual/libgl dependencies Mark Hatle (1): bitbake: cooker.py: Fix layer priority processing Ng Wei Tee (1): rpm: allow arch-dependent binaries in noarch packages Olaf Mandel (3): bitbake: toaster: debug message for lists layers missing separators bitbake: toaster: set default pokydirname if no external layers (PRE)MIRRORS: fix pattern for npm:// without slash Paul Eggleton (3): bitbake: cooker: add BB_CMDLINE to enable access to UI command line with memres bitbake: cooker: fix watching empty directories bitbake: cooker: ensure monkey-patching in collect_bbfiles() gets undone on error Peter Kjellerstedt (1): alsa-utils: Do not hardcode path to /lib/udev Richard Purdie (1): bitbake: cooker: Track directories searched for bbappend/bb files Ross Burton (1): libproxy: use stable download URL bitbake/lib/bb/command.py | 3 +- bitbake/lib/bb/cooker.py | 84 - bitbake/lib/bb/cookerdata.py | 2 +- .../toaster/bldcontrol/localhostbecontroller.py| 6 +- bitbake/lib/toaster/orm/fixtures/oe-core.xml | 3 + bitbake/lib/toaster/orm/fixtures/poky.xml | 9 ++ .../toaster/orm/management/commands/lsupdates.py | 2 + bitbake/lib/toaster/toastergui/buildtables.py | 3 + bitbake/lib/toaster/toastergui/static/js/table.js | 11 +- .../toaster/toastergui/templates/projectconf.html | 3 + meta-yocto-bsp/conf/machine/beaglebone.conf| 2 +- meta-yocto-bsp/conf/machine/edgerouter.conf| 2 +- meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +- .../recipes-kernel/linux/linux-yocto_4.1.bbappend | 20 +-- .../recipes-kernel/linux/linux-yocto_4.10.bbappend | 20 +-- .../recipes-
Re: [OE-core] [PATCH 2/3] wic: remove systemd-boot for x32
On Tue, Sep 19, 2017 at 11:27 AM, Saul Wold wrote:
> Currently systemd-boot actually incorporates libgcc, since the
> systemd-boot needs to be built with 64bit instructions it can not
> use the x32 based libgcc.
>
> Use the new override to ensure it gets overriden, linux-gnux32 could
> not be used because x86-64 has higher priority.
>
> Signed-off-by: Saul Wold
> ---
> meta/classes/image_types_wic.bbclass | 1 +
> meta/recipes-core/meta/wic-tools.bb | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/meta/classes/image_types_wic.bbclass
> b/meta/classes/image_types_wic.bbclass
> index b825b47ce5..b9503c69c5 100644
> --- a/meta/classes/image_types_wic.bbclass
> +++ b/meta/classes/image_types_wic.bbclass
> @@ -45,6 +45,7 @@ WKS_FILE_DEPENDS_DEFAULT = "syslinux-native
> bmap-tools-native cdrtools-native bt
> WKS_FILE_DEPENDS_BOOTLOADERS = ""
> WKS_FILE_DEPENDS_BOOTLOADERS_x86 = "syslinux grub-efi systemd-boot"
> WKS_FILE_DEPENDS_BOOTLOADERS_x86-64 = "syslinux grub-efi systemd-boot"
> +WKS_FILE_DEPENDS_BOOTLOADERS_x86_x32 = "syslinux grub-efi"
this will confuse with x86 ovrride. shouldnt this be x86-32 ?
>
> WKS_FILE_DEPENDS ??= "${WKS_FILE_DEPENDS_DEFAULT}
> ${WKS_FILE_DEPENDS_BOOTLOADERS}"
>
> diff --git a/meta/recipes-core/meta/wic-tools.bb
> b/meta/recipes-core/meta/wic-tools.bb
> index 57dd37a440..09eb409e87 100644
> --- a/meta/recipes-core/meta/wic-tools.bb
> +++ b/meta/recipes-core/meta/wic-tools.bb
> @@ -10,6 +10,7 @@ DEPENDS = "\
> "
> DEPENDS_append_x86 = " syslinux grub-efi systemd-boot"
> DEPENDS_append_x86-64 = " syslinux grub-efi systemd-boot"
> +DEPENDS_append_x86-x32 = " syslinux grub-efi"
>
> INHIBIT_DEFAULT_DEPS = "1"
>
> --
> 2.11.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/10] gstreamer1.0: upgrade to 1.12.3
On Thu, Sep 21, 2017 at 2:21 AM, Nicolas Dechesne
wrote:
> A boring upgrade from 1.12.2 to 1.12.3. This is a bugfixes only release,
> a couple of patches removed as they made it upstream in the mean time.
>
> Nicolas Dechesne (10):
> gstreamer1.0: upgrade to version 1.12.3
> gstreamer1.0-plugins-base: upgrade to version 1.12.3
> gstreamer1.0-plugins-good: upgrade to version 1.12.3
> gstreamer1.0-plugins-bad: upgrade to version 1.12.3
> gstreamer1.0-plugins-ugly: upgrade to version 1.12.3
> gstreamer1.0-rtsp-server: upgrade to version 1.12.3
> gstreamer1.0-omx: upgrade to version 1.12.3
> gstreamer1.0-libav: upgrade to version 1.12.3
> gstreamer1.0-vaapi: upgrade to version 1.12.3
> gstreamer1.0-python: upgrade to version 1.12.3
>
this series seems good to me,
> ...ibav_1.12.2.bb => gstreamer1.0-libav_1.12.3.bb} | 4 +-
> 0-omx_1.12.2.bb => gstreamer1.0-omx_1.12.3.bb} | 4 +-
> 12.2.bb => gstreamer1.0-plugins-bad_1.12.3.bb} | 4 +-
> ...12.2.bb => gstreamer1.0-plugins-base_1.12.3.bb} | 4 +-
> .../0001-v4l2-Fix-4K-colorimetry.patch | 48 ---
> ...12.2.bb => gstreamer1.0-plugins-good_1.12.3.bb} | 5 +-
> ...12.2.bb => gstreamer1.0-plugins-ugly_1.12.3.bb} | 4 +-
> .../gstreamer/gstreamer1.0-python.inc | 2 -
> ...hon_1.12.2.bb => gstreamer1.0-python_1.12.3.bb} | 4 +-
> .../gstreamer/gstreamer1.0-rtsp-server_1.12.2.bb | 6 --
> .../gstreamer/gstreamer1.0-rtsp-server_1.12.3.bb | 6 ++
> .../gstreamer/gstreamer1.0-vaapi_1.12.2.bb | 5 --
> .../gstreamer/gstreamer1.0-vaapi_1.12.3.bb | 5 ++
> ...dd-switches-for-enabling-disabling-libdw-.patch | 70
> --
> ...treamer1.0_1.12.2.bb => gstreamer1.0_1.12.3.bb} | 5 +-
> 15 files changed, 27 insertions(+), 149 deletions(-)
> rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-libav_1.12.2.bb =>
> gstreamer1.0-libav_1.12.3.bb} (88%)
> rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-omx_1.12.2.bb =>
> gstreamer1.0-omx_1.12.3.bb} (69%)
> rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-bad_1.12.2.bb
> => gstreamer1.0-plugins-bad_1.12.3.bb} (88%)
> rename
> meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-base_1.12.2.bb =>
> gstreamer1.0-plugins-base_1.12.3.bb} (84%)
> delete mode 100644
> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch
> rename
> meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-good_1.12.2.bb =>
> gstreamer1.0-plugins-good_1.12.3.bb} (82%)
> rename
> meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-ugly_1.12.2.bb =>
> gstreamer1.0-plugins-ugly_1.12.3.bb} (76%)
> rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-python_1.12.2.bb =>
> gstreamer1.0-python_1.12.3.bb} (57%)
> delete mode 100644
> meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.2.bb
> create mode 100644
> meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.3.bb
> delete mode 100644
> meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb
> create mode 100644
> meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.3.bb
> delete mode 100644
> meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-configure-Add-switches-for-enabling-disabling-libdw-.patch
> rename meta/recipes-multimedia/gstreamer/{gstreamer1.0_1.12.2.bb =>
> gstreamer1.0_1.12.3.bb} (59%)
>
> --
> 2.11.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 v2] mesa: Upgrade to 17.2.1 release
Upgrade to a new stable release and drop patches applied on upstream.
For a full release notes, please see:
https://mesa3d.org/relnotes/17.2.0.html
https://mesa3d.org/relnotes/17.2.1.html
Signed-off-by: Fabio Berton
Signed-off-by: Otavio Salvador
---
Changes in v2:
- update to 17.2.1
...1-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch | 40 --
...allivm-Fix-build-against-LLVM-SVN-r302589.patch | 49 --
.../mesa/{mesa-gl_17.1.7.bb => mesa-gl_17.2.1.bb} | 0
.../mesa/{mesa_17.1.7.bb => mesa_17.2.1.bb}| 7 ++--
4 files changed, 3 insertions(+), 93 deletions(-)
delete mode 100644
meta/recipes-graphics/mesa/files/0001-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch
delete mode 100644
meta/recipes-graphics/mesa/files/0002-gallivm-Fix-build-against-LLVM-SVN-r302589.patch
rename meta/recipes-graphics/mesa/{mesa-gl_17.1.7.bb => mesa-gl_17.2.1.bb}
(100%)
rename meta/recipes-graphics/mesa/{mesa_17.1.7.bb => mesa_17.2.1.bb} (77%)
diff --git
a/meta/recipes-graphics/mesa/files/0001-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch
b/meta/recipes-graphics/mesa/files/0001-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch
deleted file mode 100644
index b27a3bc8e4..00
---
a/meta/recipes-graphics/mesa/files/0001-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From 9861437e58fdd0de01193a102608d34e5952953f Mon Sep 17 00:00:00 2001
-From: Christoph Haag
-Date: Thu, 20 Apr 2017 10:34:18 +0200
-Subject: [PATCH 1/2] ac: fix build after LLVM 5.0 SVN r300718
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-v2: previously getWithDereferenceableBytes() exists, but addAttr() doesn't
take that type
-
-Signed-off-by: Christoph Haag
-Reviewed-by: Nicolai Hähnle
-Tested-and-reviewed-by: Mike Lothian
-Upstream-Status: Backport
-
- src/amd/common/ac_llvm_helper.cpp | 4
- 1 file changed, 4 insertions(+)
-
-diff --git a/src/amd/common/ac_llvm_helper.cpp
b/src/amd/common/ac_llvm_helper.cpp
-index d9ea4b1..11fa809 100644
a/src/amd/common/ac_llvm_helper.cpp
-+++ b/src/amd/common/ac_llvm_helper.cpp
-@@ -44,9 +44,13 @@ typedef AttributeSet AttributeList;
- void ac_add_attr_dereferenceable(LLVMValueRef val, uint64_t bytes)
- {
-llvm::Argument *A = llvm::unwrap(val);
-+#if HAVE_LLVM < 0x0500
-llvm::AttrBuilder B;
-B.addDereferenceableAttr(bytes);
-A->addAttr(llvm::AttributeList::get(A->getContext(), A->getArgNo() + 1,
B));
-+#else
-+ A->addAttr(llvm::Attribute::getWithDereferenceableBytes(A->getContext(),
bytes));
-+#endif
- }
-
- bool ac_is_sgpr_param(LLVMValueRef arg)
---
-2.13.3
-
diff --git
a/meta/recipes-graphics/mesa/files/0002-gallivm-Fix-build-against-LLVM-SVN-r302589.patch
b/meta/recipes-graphics/mesa/files/0002-gallivm-Fix-build-against-LLVM-SVN-r302589.patch
deleted file mode 100644
index ac8caec74d..00
---
a/meta/recipes-graphics/mesa/files/0002-gallivm-Fix-build-against-LLVM-SVN-r302589.patch
+++ /dev/null
@@ -1,49 +0,0 @@
-From a02a0dfda2712d30ad62b8f0421ec7b8244ba2cb Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
-Date: Wed, 10 May 2017 17:26:07 +0900
-Subject: [PATCH 2/2] gallivm: Fix build against LLVM SVN >= r302589
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-deregisterEHFrames doesn't take any parameters anymore.
-
-Reviewed-by: Vedran Miletić
-Reviewed-by: Marek Olšák
-Upstream-Status: Backport
-
- src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 12 +---
- 1 file changed, 9 insertions(+), 3 deletions(-)
-
-diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
-index 2a388cb..0e4a531 100644
a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
-+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
-@@ -342,14 +342,20 @@ class DelegatingJITMemoryManager : public
BaseMemoryManager {
- virtual void registerEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t
Size) {
- mgr()->registerEHFrames(Addr, LoadAddr, Size);
- }
-- virtual void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr,
size_t Size) {
-- mgr()->deregisterEHFrames(Addr, LoadAddr, Size);
-- }
- #else
- virtual void registerEHFrames(llvm::StringRef SectionData) {
- mgr()->registerEHFrames(SectionData);
- }
- #endif
-+#if HAVE_LLVM >= 0x0500
-+ virtual void deregisterEHFrames() {
-+ mgr()->deregisterEHFrames();
-+ }
-+#elif HAVE_LLVM >= 0x0304
-+ virtual void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr,
size_t Size) {
-+ mgr()->deregisterEHFrames(Addr, LoadAddr, Size);
-+ }
-+#endif
- virtual void *getPointerToNamedFunction(const std::string &Name,
- bool AbortOnFailure=true) {
- return mgr()->getPointerToNamedFunction(Name, AbortOnFailure);
---
-2.13.3
-
diff --git a/meta/recipes-g
[OE-core] [PATCH v9] kernel-devicetree.bbclass: Add support to generate append to kernel
The are use cases where the Device Tree appended to the kernel is
convinient, so we generate the bundle concatenating the kernel (and
potentionally the initramfs) and the Device Tree binaries.
To enable it, set KERNEL_DEVICETREE_BUNDLE variable to '1'
Signed-off-by: Otavio Salvador
---
Changes in v9:
- Rework to not use tasks
- Keep MIPS support addition for later
Changes in v8:
- rework append support to support ARM and MIPS (obi)
Changes in v7:
- simplified code
- rename bundle to use .bin extension
Changes in v5:
- add support for initramfs bundle
Changes in v4:
- new patch
meta/classes/kernel-devicetree.bbclass | 52 +-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel-devicetree.bbclass
b/meta/classes/kernel-devicetree.bbclass
index 72814ca224..6e08be4b70 100644
--- a/meta/classes/kernel-devicetree.bbclass
+++ b/meta/classes/kernel-devicetree.bbclass
@@ -1,6 +1,13 @@
# Support for device tree generation
-PACKAGES_append = " kernel-devicetree"
+PACKAGES_append = " \
+kernel-devicetree \
+${@['kernel-image-zimage-bundle', ''][d.getVar('KERNEL_DEVICETREE_BUNDLE')
!= '1']} \
+"
FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb
/${KERNEL_IMAGEDEST}/*.dtbo"
+FILES_kernel-image-zimage-bundle = "/${KERNEL_IMAGEDEST}/zImage-*.dtb.bin"
+
+# Generate kernel+devicetree bundle
+KERNEL_DEVICETREE_BUNDLE ?= "0"
normalize_dtb () {
DTB="$1"
@@ -20,6 +27,28 @@ get_real_dtb_path_in_kernel () {
echo "${DTB_PATH}"
}
+do_configure_append() {
+ if [ "${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+ if echo ${KERNEL_IMAGETYPE_FOR_MAKE} | grep -q 'zImage'; then
+ case "${ARCH}" in
+ "arm")
+ config="${B}/.config"
+ if ! grep -q 'CONFIG_ARM_APPENDED_DTB=y'
$config; then
+ bbwarn 'CONFIG_ARM_APPENDED_DTB is NOT
enabled in the kernel. Enabling it to allow the kernel to boot with the Device
Tree appended!'
+ sed -i "/CONFIG_ARM_APPENDED_DTB[ =]/d"
$config
+ echo "CONFIG_ARM_APPENDED_DTB=y" >>
$config
+ echo "# CONFIG_ARM_ATAG_DTB_COMPAT is
not set" >> $config
+ fi
+ ;;
+ *)
+ bberror "KERNEL_DEVICETREE_BUNDLE is not
supported for ${ARCH}. Currently it is only supported for 'ARM'."
+ esac
+ else
+ bberror 'The KERNEL_DEVICETREE_BUNDLE requires the
KERNEL_IMAGETYPE to contain zImage.'
+ fi
+ fi
+}
+
do_compile_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
@@ -38,6 +67,12 @@ do_install_append() {
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
ln -sf ${DTB_BASE_NAME}.${DTB_EXT}
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
+
+ if [ "$type" = "zImage" ] && [
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+ cat ${D}/${KERNEL_IMAGEDEST}/$type \
+
${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} \
+ >
${D}/${KERNEL_IMAGEDEST}/$type-${DTB_BASE_NAME}.${DTB_EXT}.bin
+ fi
done
done
}
@@ -57,6 +92,21 @@ do_deploy_append() {
install -m 0644 ${DTB_PATH}
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
ln -sf ${DTB_NAME}.${DTB_EXT}
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
ln -sf ${DTB_NAME}.${DTB_EXT}
${DEPLOYDIR}/${DTB_BASE_NAME}.${DTB_EXT}
+
+ if [ "$type" = "zImage" ] && [
"${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
+ cat ${DEPLOYDIR}/$type \
+ ${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT} \
+ >
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}.bin
+ ln -sf ${DTB_NAME}.${DTB_EXT}.bin
${DEPLOYDIR}/$type-${DTB_BASE_NAME}.${DTB_EXT}.bin
+
+ if [ -e
"${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
+ cat
${KERNEL_OUTPUT_DIR}/${type}.initramfs \
+
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT} \
+ >
${DEPLOYDIR}/${type}-${INITRAMFS_BASE_NAME}-${DTB_BASE_NAME}.${DTB_EXT}.bin
+ ln -sf
${type}-${INITRAMFS_BASE_NAME}-${DTB_BASE_NAME}.${DTB_EXT}.bin \
+
Re: [OE-core] [PATCH] useradd-staticids: don't create username-group if gid is specified
> -Original Message- > From: André Draszik [mailto:g...@andred.net] > Sent: den 21 september 2017 10:24 > To: Peter Kjellerstedt ; openembedded- > c...@lists.openembedded.org > Subject: Re: [OE-core] [PATCH] useradd-staticids: don't create > username-group if gid is specified > > On Wed, 2017-09-20 at 14:20 +, Peter Kjellerstedt wrote: > > > -Original Message- > > > From: André Draszik [mailto:g...@andred.net] > > > Sent: den 20 september 2017 11:29 > > > To: Peter Kjellerstedt ; openembedded- > > > c...@lists.openembedded.org > > > Subject: Re: [OE-core] [PATCH] useradd-staticids: don't create > > > username-group if gid is specified > > > > > > ping > > > > Sorry, I forgot to reply to this. > > > > > On Tue, 2017-09-05 at 08:40 +0100, André Draszik wrote: > > > > On Mon, 2017-09-04 at 10:22 +, Peter Kjellerstedt wrote: > > > > > > > > > > > > > > [...] > > > > > > diff --git a/meta/classes/useradd-staticids.bbclass > > > > > > b/meta/classes/useradd-staticids.bbclass > > > > > > index ce4ac62ab5..1b61a8bf9b 100644 > > > > > > --- a/meta/classes/useradd-staticids.bbclass > > > > > > +++ b/meta/classes/useradd-staticids.bbclass > > > > > > @@ -102,7 +102,7 @@ def update_useradd_static_config(d): > > > > > > # So if the implicit username-group creation is > on, > > > > > > then the implicit groupname (LOGIN) > > > > > > # is used, and we disable the user_group option. > > > > > > # > > > > > > -user_group = uaargs.user_group is None or > > > > > > uaargs.user_group is True > > > > > > +user_group = uaargs.gid is None or > uaargs.user_group > > > > > > is True > > > > > > > > > > Hmm, I believe that should be: > > > > > > > > > > user_group = uaargs.gid is None and > uaargs.user_group is > > > > > None or uaargs.user_group is True > > > > > > > > > > I.e., if neither --gid nor --user-group is specified, then it > should > > > > > treat it as if --user-group was specified. > > > > > > > > Hm, isn't this still the same as > > > > > > > > user_group = uaargs.gid is None or uaargs.user_group is True > > > > No, because uaargs.user_group may be False if --no-user-group is > > specified (which I of course should have mentioned in my previous > > reply). With your version, you would still get a user group even > > if --no-user-group is specified. > > OK, this is how useradd behaves: > > useradd --system --home /dev/null --no-create-home --no-user-group > distcc > -> will add the new user to the group 'users' (as per GROUP from > /etc/default/useradd) > > useradd --system --home /dev/null --no-create-home --gid foo --user- > group distcc > -> --gid and --user-group together conflict > > useradd --system --home /dev/null --no-create-home --user-group distcc > useradd --system --home /dev/null --no-create-home distcc > -> in both cases distcc user and group are created > > > Sp, what about this instead: > > if uaargs.gid: > uaargs.groupname = uaargs.gid > uaargs.groupid = field[3] or uaargs.gid > elif uaargs.user_group is not False: > uaargs.groupname = uaargs.LOGIN > uaargs.groupid = field[3] or uaargs.LOGIN > else: > uaargs.groupname = 'users' > uaargs.groupid = field[3] or 'users' Looks correct. However, you can simplify it to: if uaargs.gid: uaargs.groupname = uaargs.gid elif uaargs.user_group is not False: uaargs.groupname = uaargs.LOGIN else: uaargs.groupname = 'users' uaargs.groupid = field[3] or uaargs.groupname > Cheers, > Andre' > > > > > ? If neither --gid nor --user-group is specified, then gid is > None, so > > > > it > > > > will do what you want already. IOW, unless the group name (gid) > is > > > > specified, a username-group is being created. > > > > > > > > > > > > Cheers, > > > > Andre' > > > > //Peter //Peter -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] image.bbclass: Sorted ctypes to avoid basehash error
On Thu, Sep 21, 2017 at 07:15:01AM +0200, Martin Hundebøll wrote: > > > On 2017-09-19 19:15, Gerson Fernando Budke wrote: > >When selected multiple subimages a similar error could happend: > > Variable do_image_cpio[subimages] value changed \ > > from 'cpio.gz.u-boot cpio.gz' to 'cpio.gz cpio.gz.u-boot' > >To avoid this, 'ctypes' should be sorted at 'gen_conversion_cmds'. > > > >This garantee that 'CONVERSION_CMD_xxx' are always written in tha same > >order and consequently 'do_image_cpio' have the same hash. > > > >Signed-off-by: Gerson Fernando Budke > > Tested-by: Martin Hundebøll Reviewed-by: Tom Rini -- Tom -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] uboot-extlinux: fix extlinux creation race (take 2)
Hi,
On Thu, 2017-09-21 at 12:29 +0100, André Draszik wrote:
> From: André Draszik
>
> Alternative solution to original commit
> 60c90398580998b2379bb438f0f75b29285135a5 ("u-boot: fix extlinux
> creation race")
>
> (Untested)
I am not in a position to test this patch, but I believe that it should
work...
Cheers,
Andre'
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] uboot-extlinux: fix extlinux creation race (take 2)
From: André Draszik
Alternative solution to original commit
60c90398580998b2379bb438f0f75b29285135a5 ("u-boot: fix extlinux
creation race")
(Untested)
Signed-off-by: André Draszik
---
v2: also execute before do_deploy
---
meta/classes/uboot-extlinux-config.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/uboot-extlinux-config.bbclass
b/meta/classes/uboot-extlinux-config.bbclass
index 8447a047ee..61dff14b7c 100644
--- a/meta/classes/uboot-extlinux-config.bbclass
+++ b/meta/classes/uboot-extlinux-config.bbclass
@@ -68,7 +68,7 @@ UBOOT_EXTLINUX_MENU_DESCRIPTION_linux ??= "${DISTRO_NAME}"
UBOOT_EXTLINUX_CONFIG = "${B}/extlinux.conf"
-python create_extlinux_config() {
+python do_create_extlinux_config() {
if d.getVar("UBOOT_EXTLINUX") != "1":
return
@@ -149,4 +149,4 @@ python create_extlinux_config() {
bb.fatal('Unable to open %s' % (cfile))
}
-do_install[prefuncs] += "create_extlinux_config"
+addtask create_extlinux_config before do_install do_deploy after do_compile
--
2.14.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] uboot-extlinux: fix extlinux creation race (take 2)
From: André Draszik
Alternative solution to original commit
60c90398580998b2379bb438f0f75b29285135a5 ("u-boot: fix extlinux
creation race")
(Untested)
Signed-off-by: André Draszik
---
meta/classes/uboot-extlinux-config.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/uboot-extlinux-config.bbclass
b/meta/classes/uboot-extlinux-config.bbclass
index 8447a047ee..d60f8c6ae2 100644
--- a/meta/classes/uboot-extlinux-config.bbclass
+++ b/meta/classes/uboot-extlinux-config.bbclass
@@ -68,7 +68,7 @@ UBOOT_EXTLINUX_MENU_DESCRIPTION_linux ??= "${DISTRO_NAME}"
UBOOT_EXTLINUX_CONFIG = "${B}/extlinux.conf"
-python create_extlinux_config() {
+python do_create_extlinux_config() {
if d.getVar("UBOOT_EXTLINUX") != "1":
return
@@ -149,4 +149,4 @@ python create_extlinux_config() {
bb.fatal('Unable to open %s' % (cfile))
}
-do_install[prefuncs] += "create_extlinux_config"
+addtask create_extlinux_config before do_install after do_compile
--
2.14.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] Revert "u-boot: fix extlinux creation race"
From: André Draszik
This reverts commit 60c90398580998b2379bb438f0f75b29285135a5.
This causes circular dependencies when UBOOT_SIGN_ENABLE is active.
These are usually caused by circular dependencies and any circular dependency
chains found will be printed below. Increase the debug level to see a list of
unbuildable tasks.
Identifying dependency loops (this may take a short while)...
ERROR:
Dependency loop #1 found:
Task u-boot.bb:do_concat_dtb (dependent Tasks
['kernel.bb:do_assemble_fitimage'])
Task u-boot.bb:do_install (dependent Tasks ['u-boot.bb:do_concat_dtb',
'pseudo_1.8.2.bb:do_populate_sysroot', 'u-boot.bb:do_compile'])
Task u-boot.bb:do_deploy (dependent Tasks ['u-boot.bb:do_deploy_dtb',
'u-boot.bb:do_install'])
Task .../recipes-kernel/linux/kernel.bb:do_assemble_fitimage (dependent Tasks
['kernel.bb:do_compile', 'u-boot.bb:do_deploy'])
Signed-off-by: André Draszik
---
meta/recipes-bsp/u-boot/u-boot.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
b/meta/recipes-bsp/u-boot/u-boot.inc
index aa21c0e556..c2bcf99840 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -304,4 +304,4 @@ do_deploy () {
fi
}
-addtask deploy before do_build after do_install
+addtask deploy before do_build after do_compile
--
2.14.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oe-build-perf-report-email.py: add cc and bcc options
Enable carbon copy and blind carbon copy recipients for the performance
report emails.
Signed-off-by: Joshua Lock
---
scripts/contrib/oe-build-perf-report-email.py | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/scripts/contrib/oe-build-perf-report-email.py
b/scripts/contrib/oe-build-perf-report-email.py
index 261ca514e5a..64e85c26add 100755
--- a/scripts/contrib/oe-build-perf-report-email.py
+++ b/scripts/contrib/oe-build-perf-report-email.py
@@ -71,6 +71,10 @@ def parse_args(argv):
help="Only print errors")
parser.add_argument('--to', action='append',
help="Recipients of the email")
+parser.add_argument('--cc', action='append',
+help="Carbon copy recipients of the email")
+parser.add_argument('--bcc', action='append',
+help="Blind carbon copy recipients of the email")
parser.add_argument('--subject', default="Yocto build perf test report",
help="Email subject")
parser.add_argument('--outdir', '-o',
@@ -188,7 +192,7 @@ def scrape_html_report(report, outdir,
phantomjs_extra_args=None):
finally:
shutil.rmtree(tmpdir)
-def send_email(text_fn, html_fn, subject, recipients):
+def send_email(text_fn, html_fn, subject, recipients, copy=[], blind_copy=[]):
"""Send email"""
# Generate email message
text_msg = html_msg = None
@@ -217,6 +221,10 @@ def send_email(text_fn, html_fn, subject, recipients):
'{}@{}'.format(pw_data.pw_name, socket.getfqdn()))
msg['From'] = "{} <{}>".format(full_name, email)
msg['To'] = ', '.join(recipients)
+if copy:
+msg['Cc'] = ', '.join(copy)
+if blind_copy:
+msg['Bcc'] = ', '.join(blind_copy)
msg['Subject'] = subject
# Send email
@@ -250,7 +258,12 @@ def main(argv=None):
if args.to:
log.info("Sending email to %s", ', '.join(args.to))
-send_email(args.text, html_report, args.subject, args.to)
+if args.cc:
+log.info("Copying to %s", ', '.join(args.cc))
+if args.bcc:
+log.info("Blind copying to %s", ', '.join(args.bcc))
+send_email(args.text, html_report, args.subject,
+ args.to, args.cc, args.bcc)
except subprocess.CalledProcessError as err:
log.error("%s, with output:\n%s", str(err), err.output.decode())
return 1
--
2.13.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 07/10] gstreamer1.0-omx: upgrade to version 1.12.3
Bugfixes only release.
Signed-off-by: Nicolas Dechesne
---
.../{gstreamer1.0-omx_1.12.2.bb => gstreamer1.0-omx_1.12.3.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-omx_1.12.2.bb =>
gstreamer1.0-omx_1.12.3.bb} (69%)
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.12.2.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.12.3.bb
similarity index 69%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.12.2.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.12.3.bb
index a1d4576402..15837d3dc5 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.12.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.12.3.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=4fbd65380cdd255951079008b364516c \
SRC_URI = "http://gstreamer.freedesktop.org/src/gst-omx/gst-omx-${PV}.tar.xz";
-SRC_URI[md5sum] = "4a1404a20b72e4ab6e826500218ec308"
-SRC_URI[sha256sum] =
"1b22398f45a027e977d2b5309625ec91cdcaf0da8751cbc7f596d639a45ba298"
+SRC_URI[md5sum] = "53d2ca9739f9189d9c1924d4af71e8a4"
+SRC_URI[sha256sum] =
"eef5de8bab1bb495bfbc9d16af9837d7f55b47cb6b97819b3152c5899c85843c"
S = "${WORKDIR}/gst-omx-${PV}"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 04/10] gstreamer1.0-plugins-bad: upgrade to version 1.12.3
Bugfixes only release.
Signed-off-by: Nicolas Dechesne
---
...er1.0-plugins-bad_1.12.2.bb => gstreamer1.0-plugins-bad_1.12.3.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-bad_1.12.2.bb
=> gstreamer1.0-plugins-bad_1.12.3.bb} (88%)
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.2.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.3.bb
similarity index 88%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.2.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.3.bb
index 8321da0c27..90f7f24b21 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.3.bb
@@ -17,8 +17,8 @@ SRC_URI = " \
file://0001-vkdisplay-Use-ifdef-for-platform-specific-defines.patch \
file://0002-vulkan-Use-the-generated-version-of-vkconfig.h.patch \
"
-SRC_URI[md5sum] = "5683f0ea91f9e1e0613b0f6f729980a7"
-SRC_URI[sha256sum] =
"9c2c7edde4f59d74eb414e0701c55131f562e5c605a3ce9b091754f106c09e37"
+SRC_URI[md5sum] = "594a818b13fa89960b6e7c414340db38"
+SRC_URI[sha256sum] =
"36d059761852bed0f1a7fcd3ef64a8aeecab95d2bca53cd6aa0f08054b1cbfec"
S = "${WORKDIR}/gst-plugins-bad-${PV}"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 10/10] gstreamer1.0-python: upgrade to version 1.12.3
* Bugfixes only release.
* Removed SRC_URI from .inc file since it was duplicated in .bb file as well.
Signed-off-by: Nicolas Dechesne
---
meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc | 2 --
.../{gstreamer1.0-python_1.12.2.bb => gstreamer1.0-python_1.12.3.bb} | 4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-python_1.12.2.bb =>
gstreamer1.0-python_1.12.3.bb} (57%)
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
index 961b93017e..361f0bca41 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python.inc
@@ -8,8 +8,6 @@ RDEPENDS_${PN} += "gstreamer1.0 python3-pygobject"
PNREAL = "gst-python"
-SRC_URI =
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz";
-
S = "${WORKDIR}/${PNREAL}-${PV}"
inherit autotools pkgconfig distutils3-base upstream-version-is-even
gobject-introspection
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.12.2.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.12.3.bb
similarity index 57%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.12.2.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.12.3.bb
index b2dc05bbec..3978b9d563 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.12.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.12.3.bb
@@ -1,7 +1,7 @@
require gstreamer1.0-python.inc
SRC_URI =
"http://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz";
-SRC_URI[md5sum] = "da5c9fa42290bc3006661c869e076ffe"
-SRC_URI[sha256sum] =
"f4cc32ad46a653e1ae2f27ac2a16078b00075c9106b2784a1a8d1f31c5069e47"
+SRC_URI[md5sum] = "622125816c52a51205660d210f8e7b8b"
+SRC_URI[sha256sum] =
"c3f529dec1294633132690806703b80bad5752eff482eaf81f209c2aba012ba7"
LIC_FILES_CHKSUM = "file://COPYING;md5=c34deae4e395ca07e725ab0076a5f740"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 09/10] gstreamer1.0-vaapi: upgrade to version 1.12.3
Bugfixes only release. Signed-off-by: Nicolas Dechesne --- meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb | 5 - meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.3.bb | 5 + 2 files changed, 5 insertions(+), 5 deletions(-) delete mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.3.bb diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb deleted file mode 100644 index fbd9f8675f..00 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb +++ /dev/null @@ -1,5 +0,0 @@ -require gstreamer1.0-vaapi.inc -SRC_URI[md5sum] = "bea015f33696a15ad9575fb71af862ed" -SRC_URI[sha256sum] = "23c714e0474b3c7ae6ff8884aebf8503a1bc3ded335fa2d2b2ac31788466163a" - -DEPENDS += "gstreamer1.0 gstreamer1.0-plugins-base gstreamer1.0-plugins-bad" diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.3.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.3.bb new file mode 100644 index 00..7a82cdd91d --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.3.bb @@ -0,0 +1,5 @@ +require gstreamer1.0-vaapi.inc +SRC_URI[md5sum] = "aa9ea10623f34680a39b32e243add26d" +SRC_URI[sha256sum] = "f4cdafd8fd9606a490917c8b67336e835df1219580d55421c70480fd0913744d" + +DEPENDS += "gstreamer1.0 gstreamer1.0-plugins-base gstreamer1.0-plugins-bad" -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 06/10] gstreamer1.0-rtsp-server: upgrade to version 1.12.3
Bugfixes release only. Signed-off-by: Nicolas Dechesne --- .../recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.2.bb | 6 -- .../recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.3.bb | 6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) delete mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.2.bb create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.3.bb diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.2.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.2.bb deleted file mode 100644 index 2426cca6c9..00 --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.2.bb +++ /dev/null @@ -1,6 +0,0 @@ -require gstreamer1.0-rtsp-server.inc - -SRC_URI[md5sum] = "022757cab183f5b970086e9101c60a98" -SRC_URI[sha256sum] = "d8ba9264e8ae6e440293328e759e40456f161aa66077b3143dd07581136190b3" - -LIC_FILES_CHKSUM = "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d" diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.3.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.3.bb new file mode 100644 index 00..387628470a --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.3.bb @@ -0,0 +1,6 @@ +require gstreamer1.0-rtsp-server.inc + +SRC_URI[md5sum] = "83ae8adda3b9c6164cd2fba1efdde87e" +SRC_URI[sha256sum] = "67255971bb16029a01de66b9f9687f20d8dbf3d3bd75feb48605d0723a7c74ec" + +LIC_FILES_CHKSUM = "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d" -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 05/10] gstreamer1.0-plugins-ugly: upgrade to version 1.12.3
Bugfixes only release.
Signed-off-by: Nicolas Dechesne
---
...1.0-plugins-ugly_1.12.2.bb => gstreamer1.0-plugins-ugly_1.12.3.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-ugly_1.12.2.bb
=> gstreamer1.0-plugins-ugly_1.12.3.bb} (76%)
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.12.2.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.12.3.bb
similarity index 76%
rename from
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.12.2.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.12.3.bb
index 6956c85be6..5a5fccfb81 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.12.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.12.3.bb
@@ -7,7 +7,7 @@ SRC_URI = " \
http://gstreamer.freedesktop.org/src/gst-plugins-ugly/gst-plugins-ugly-${PV}.tar.xz
\
file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
"
-SRC_URI[md5sum] = "eb639021905a32cf3013ca5bac1b694d"
-SRC_URI[sha256sum] =
"1cc3942bbf3ea87da3e35437d4e014e991b103db22a6174f62a98c89c3f5f466"
+SRC_URI[md5sum] = "8a0ba8141b1548ee094eb97e7cf5471f"
+SRC_URI[sha256sum] =
"e88ca584c94ea78eeecbf3af00ef7f134b66bdee7408aa4aa6c547235e060052"
S = "${WORKDIR}/gst-plugins-ugly-${PV}"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 08/10] gstreamer1.0-libav: upgrade to version 1.12.3
Bugfixes only release.
Signed-off-by: Nicolas Dechesne
---
.../{gstreamer1.0-libav_1.12.2.bb => gstreamer1.0-libav_1.12.3.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-libav_1.12.2.bb =>
gstreamer1.0-libav_1.12.3.bb} (88%)
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.12.2.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.12.3.bb
similarity index 88%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.12.2.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.12.3.bb
index 6c5f779ebf..d24ef86530 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.12.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.12.3.bb
@@ -14,7 +14,7 @@ SRC_URI =
"http://gstreamer.freedesktop.org/src/gst-libav/gst-libav-${PV}.tar.xz
file://mips64_cpu_detection.patch \
file://0001-configure-check-for-armv7ve-variant.patch \
"
-SRC_URI[md5sum] = "8788aecc032a287227b4bd239d1b998a"
-SRC_URI[sha256sum] =
"5bb735b9bb218b652ae4071ea6f6be8eaae55e9d3233aec2f36b882a27542db3"
+SRC_URI[md5sum] = "81f62d58279108698b321209fc6696ce"
+SRC_URI[sha256sum] =
"015ef8cab6f7fb87c8fb42642486423eff3b6e6a6bccdcd6a189f436a3619650"
S = "${WORKDIR}/gst-libav-${PV}"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 02/10] gstreamer1.0-plugins-base: upgrade to version 1.12.3
Bugfixes release only.
Signed-off-by: Nicolas Dechesne
---
...1.0-plugins-base_1.12.2.bb => gstreamer1.0-plugins-base_1.12.3.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-base_1.12.2.bb
=> gstreamer1.0-plugins-base_1.12.3.bb} (84%)
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.12.2.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.12.3.bb
similarity index 84%
rename from
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.12.2.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.12.3.bb
index 5de0b8b50c..04abe8cc6e 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.12.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.12.3.bb
@@ -12,7 +12,7 @@ SRC_URI = " \
file://make-gio_unix_2_0-dependency-configurable.patch \
file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
"
-SRC_URI[md5sum] = "77f5379c4ca677616b415e3b3ff95578"
-SRC_URI[sha256sum] =
"5067dce3afe197a9536fea0107c77213fab536dff4a213b07fc60378d5510675"
+SRC_URI[md5sum] = "e69d41472a9b08eaf9659cde5dc0a4a4"
+SRC_URI[sha256sum] =
"d3d37b8489d37fa0018973d850bd2067b98af335fef2fa543ee7d40359e3cea5"
S = "${WORKDIR}/gst-plugins-base-${PV}"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 03/10] gstreamer1.0-plugins-good: upgrade to version 1.12.3
Patch removed since it is already upstream now.
Bugfixes release only.
Signed-off-by: Nicolas Dechesne
---
.../0001-v4l2-Fix-4K-colorimetry.patch | 48 --
...12.2.bb => gstreamer1.0-plugins-good_1.12.3.bb} | 5 +--
2 files changed, 2 insertions(+), 51 deletions(-)
delete mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-good_1.12.2.bb
=> gstreamer1.0-plugins-good_1.12.3.bb} (82%)
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch
deleted file mode 100644
index f78818aa17..00
---
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch
+++ /dev/null
@@ -1,48 +0,0 @@
-From 545646cccba243236e10362fe7325f89be57da1f Mon Sep 17 00:00:00 2001
-From: Nicolas Dufresne
-Date: Tue, 18 Jul 2017 11:28:37 -0400
-Subject: [PATCH] v4l2: Fix 4K colorimetry
-
-Since 1.6, the transfer function for BT2020 has been changed from BT709
-to BT2020_12. It's the same function, but with more precision. As a side
-effect, the V4L2 colorpsace didn't match GStreamer colorspace. When
-GStreamer ended up making a guess, it would not match anything supported
-by V4L2 anymore. This this by using BT2020_12 for BT2020 colorspace and
-BT2020 transfer function in replacement of BT709 whenever a 4K
-resolution is detected.
-
-Upstream-Status: Backport
-Signed-off-by: Nicolas Dechesne
-
- sys/v4l2/gstv4l2object.c | 7 +--
- 1 file changed, 5 insertions(+), 2 deletions(-)
-
-diff --git a/sys/v4l2/gstv4l2object.c b/sys/v4l2/gstv4l2object.c
-index 61244455f..aae2c55e7 100644
a/sys/v4l2/gstv4l2object.c
-+++ b/sys/v4l2/gstv4l2object.c
-@@ -1960,7 +1960,7 @@ gst_v4l2_object_get_colorspace (struct v4l2_format *fmt,
- case V4L2_COLORSPACE_BT2020:
- cinfo->range = GST_VIDEO_COLOR_RANGE_16_235;
- cinfo->matrix = GST_VIDEO_COLOR_MATRIX_BT2020;
-- cinfo->transfer = GST_VIDEO_TRANSFER_BT709;
-+ cinfo->transfer = GST_VIDEO_TRANSFER_BT2020_12;
- cinfo->primaries = GST_VIDEO_COLOR_PRIMARIES_BT2020;
- break;
- case V4L2_COLORSPACE_SMPTE240M:
-@@ -2062,7 +2062,10 @@ gst_v4l2_object_get_colorspace (struct v4l2_format *fmt,
-
- switch (transfer) {
- case V4L2_XFER_FUNC_709:
-- cinfo->transfer = GST_VIDEO_TRANSFER_BT709;
-+ if (fmt->fmt.pix.height > 2160)
-+cinfo->transfer = GST_VIDEO_TRANSFER_BT2020_12;
-+ else
-+cinfo->transfer = GST_VIDEO_TRANSFER_BT709;
- break;
- case V4L2_XFER_FUNC_SRGB:
- cinfo->transfer = GST_VIDEO_TRANSFER_SRGB;
---
-2.14.1
-
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.2.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.3.bb
similarity index 82%
rename from
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.2.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.3.bb
index f9593c99aa..afcb333cb7 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.3.bb
@@ -10,10 +10,9 @@ SRC_URI = " \
file://avoid-including-sys-poll.h-directly.patch \
file://ensure-valid-sentinel-for-gst_structure_get.patch \
file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
-file://0001-v4l2-Fix-4K-colorimetry.patch \
"
-SRC_URI[md5sum] = "20254217d9805484532e08ff1c3aa296"
-SRC_URI[sha256sum] =
"5591ee7208ab30289a30658a82b76bf87169c927572d9b794f3a41ed48e1ee96"
+SRC_URI[md5sum] = "6b56a7cc6c5fd031a9596ec123b2f285"
+SRC_URI[sha256sum] =
"13e7f479296891fef5a686438f20ba7d534680becf2269ecc5ee24aa83b45f03"
S = "${WORKDIR}/gst-plugins-good-${PV}"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 01/10] gstreamer1.0: upgrade to version 1.12.3
Bugfixes release only. Removed local patch which was merged upstream.
Signed-off-by: Nicolas Dechesne
---
...dd-switches-for-enabling-disabling-libdw-.patch | 70 --
...treamer1.0_1.12.2.bb => gstreamer1.0_1.12.3.bb} | 5 +-
2 files changed, 2 insertions(+), 73 deletions(-)
delete mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-configure-Add-switches-for-enabling-disabling-libdw-.patch
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0_1.12.2.bb =>
gstreamer1.0_1.12.3.bb} (59%)
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-configure-Add-switches-for-enabling-disabling-libdw-.patch
b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-configure-Add-switches-for-enabling-disabling-libdw-.patch
deleted file mode 100644
index 1132fd5a48..00
---
a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-configure-Add-switches-for-enabling-disabling-libdw-.patch
+++ /dev/null
@@ -1,70 +0,0 @@
-From a0cb41ba72913eda06049d266ec43ea8f52b5bee Mon Sep 17 00:00:00 2001
-From: Carlos Rafael Giani
-Date: Fri, 11 Aug 2017 21:21:36 +0200
-Subject: [PATCH] configure: Add switches for enabling/disabling libdw and
- libunwind
-
-[Original patch modified to be applicable to 1.12.2]
-
-Upstream-Status: Submitted [https://bugzilla.gnome.org/show_bug.cgi?id=778193]
-
-Signed-off-by: Carlos Rafael Giani
- configure.ac | 38 --
- 1 file changed, 32 insertions(+), 6 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index b6b2923..32dd827 100644
a/configure.ac
-+++ b/configure.ac
-@@ -821,15 +821,41 @@ fi
- AM_CONDITIONAL(HAVE_GTK, test "x$HAVE_GTK" = "xyes")
-
- dnl libunwind is optionally used by the leaks tracer
--PKG_CHECK_MODULES(UNWIND, libunwind, HAVE_UNWIND=yes, HAVE_UNWIND=no)
--if test "x$HAVE_UNWIND" = "xyes"; then
-- AC_DEFINE(HAVE_UNWIND, 1, [libunwind available])
-+AC_ARG_WITH([unwind],[AS_HELP_STRING([--with-unwind=yes|no|auto],[use
libunwind])],
-+[], [with_unwind=auto])
-+if [ test "x${with_unwind}" != "xno" ]; then
-+ PKG_CHECK_MODULES(UNWIND, [libunwind],
-+ [
-+HAVE_UNWIND=yes
-+AC_DEFINE(HAVE_UNWIND, 1, [libunwind available])
-+ ],
-+ [
-+HAVE_UNWIND=no
-+if [ test "x${with_unwind}" = "xyes" ]; then
-+ AC_MSG_ERROR([could not find libunwind])
-+fi
-+ ])
-+else
-+ HAVE_UNWIND=no
- fi
-
- dnl libdw is optionally used to add source lines and numbers to backtraces
--PKG_CHECK_MODULES(DW, libdw, HAVE_DW=yes, HAVE_DW=no)
--if test "x$HAVE_DW" = "xyes"; then
-- AC_DEFINE(HAVE_DW, 1, [libdw available])
-+AC_ARG_WITH([dw],[AS_HELP_STRING([--with-dw=yes|no|auto],[use libdw])],
-+[], [with_dw=auto])
-+if [ test "x${with_dw}" != "xno" ]; then
-+ PKG_CHECK_MODULES(DW, [libdw],
-+ [
-+HAVE_DW=yes
-+AC_DEFINE(HAVE_DW, 1, [libdw available])
-+ ],
-+ [
-+HAVE_DW=no
-+if [ test "x${with_dw}" = "xyes" ]; then
-+ AC_MSG_ERROR([could not find libdw])
-+fi
-+ ])
-+else
-+ HAVE_DW=no
- fi
-
- dnl Check for backtrace() from libc
---
-2.7.4
-
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.2.bb
b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.3.bb
similarity index 59%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.2.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.3.bb
index 8d41a59d91..98928c9466 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.12.3.bb
@@ -5,9 +5,8 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=6762ed442b3822387a51c92d928ead0d \
SRC_URI = " \
http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.xz \
-file://0001-configure-Add-switches-for-enabling-disabling-libdw-.patch \
"
-SRC_URI[md5sum] = "4748860621607ffd96244fb79c86c238"
-SRC_URI[sha256sum] =
"9fde3f39a2ea984f9e07ce09250285ce91f6e3619d186889f75b5154ecf994ba"
+SRC_URI[md5sum] = "33dfcb690304fccdaff178440de13334"
+SRC_URI[sha256sum] =
"d388f492440897f02b01eebb033ca2d41078a3d85c0eddc030cdea5a337a216e"
S = "${WORKDIR}/gstreamer-${PV}"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/10] gstreamer1.0: upgrade to 1.12.3
A boring upgrade from 1.12.2 to 1.12.3. This is a bugfixes only release,
a couple of patches removed as they made it upstream in the mean time.
Nicolas Dechesne (10):
gstreamer1.0: upgrade to version 1.12.3
gstreamer1.0-plugins-base: upgrade to version 1.12.3
gstreamer1.0-plugins-good: upgrade to version 1.12.3
gstreamer1.0-plugins-bad: upgrade to version 1.12.3
gstreamer1.0-plugins-ugly: upgrade to version 1.12.3
gstreamer1.0-rtsp-server: upgrade to version 1.12.3
gstreamer1.0-omx: upgrade to version 1.12.3
gstreamer1.0-libav: upgrade to version 1.12.3
gstreamer1.0-vaapi: upgrade to version 1.12.3
gstreamer1.0-python: upgrade to version 1.12.3
...ibav_1.12.2.bb => gstreamer1.0-libav_1.12.3.bb} | 4 +-
0-omx_1.12.2.bb => gstreamer1.0-omx_1.12.3.bb} | 4 +-
12.2.bb => gstreamer1.0-plugins-bad_1.12.3.bb} | 4 +-
...12.2.bb => gstreamer1.0-plugins-base_1.12.3.bb} | 4 +-
.../0001-v4l2-Fix-4K-colorimetry.patch | 48 ---
...12.2.bb => gstreamer1.0-plugins-good_1.12.3.bb} | 5 +-
...12.2.bb => gstreamer1.0-plugins-ugly_1.12.3.bb} | 4 +-
.../gstreamer/gstreamer1.0-python.inc | 2 -
...hon_1.12.2.bb => gstreamer1.0-python_1.12.3.bb} | 4 +-
.../gstreamer/gstreamer1.0-rtsp-server_1.12.2.bb | 6 --
.../gstreamer/gstreamer1.0-rtsp-server_1.12.3.bb | 6 ++
.../gstreamer/gstreamer1.0-vaapi_1.12.2.bb | 5 --
.../gstreamer/gstreamer1.0-vaapi_1.12.3.bb | 5 ++
...dd-switches-for-enabling-disabling-libdw-.patch | 70 --
...treamer1.0_1.12.2.bb => gstreamer1.0_1.12.3.bb} | 5 +-
15 files changed, 27 insertions(+), 149 deletions(-)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-libav_1.12.2.bb =>
gstreamer1.0-libav_1.12.3.bb} (88%)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-omx_1.12.2.bb =>
gstreamer1.0-omx_1.12.3.bb} (69%)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-bad_1.12.2.bb
=> gstreamer1.0-plugins-bad_1.12.3.bb} (88%)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-base_1.12.2.bb
=> gstreamer1.0-plugins-base_1.12.3.bb} (84%)
delete mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-good_1.12.2.bb
=> gstreamer1.0-plugins-good_1.12.3.bb} (82%)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-ugly_1.12.2.bb
=> gstreamer1.0-plugins-ugly_1.12.3.bb} (76%)
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-python_1.12.2.bb =>
gstreamer1.0-python_1.12.3.bb} (57%)
delete mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.2.bb
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.12.3.bb
delete mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.3.bb
delete mode 100644
meta/recipes-multimedia/gstreamer/gstreamer1.0/0001-configure-Add-switches-for-enabling-disabling-libdw-.patch
rename meta/recipes-multimedia/gstreamer/{gstreamer1.0_1.12.2.bb =>
gstreamer1.0_1.12.3.bb} (59%)
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] useradd-staticids: don't create username-group if gid is specified
On Wed, 2017-09-20 at 14:20 +, Peter Kjellerstedt wrote: > > -Original Message- > > From: André Draszik [mailto:g...@andred.net] > > Sent: den 20 september 2017 11:29 > > To: Peter Kjellerstedt ; openembedded- > > c...@lists.openembedded.org > > Subject: Re: [OE-core] [PATCH] useradd-staticids: don't create > > username-group if gid is specified > > > > ping > > Sorry, I forgot to reply to this. > > > On Tue, 2017-09-05 at 08:40 +0100, André Draszik wrote: > > > On Mon, 2017-09-04 at 10:22 +, Peter Kjellerstedt wrote: > > > > > > > > > > > [...] > > > > > diff --git a/meta/classes/useradd-staticids.bbclass > > > > > b/meta/classes/useradd-staticids.bbclass > > > > > index ce4ac62ab5..1b61a8bf9b 100644 > > > > > --- a/meta/classes/useradd-staticids.bbclass > > > > > +++ b/meta/classes/useradd-staticids.bbclass > > > > > @@ -102,7 +102,7 @@ def update_useradd_static_config(d): > > > > > # So if the implicit username-group creation is on, > > > > > then the implicit groupname (LOGIN) > > > > > # is used, and we disable the user_group option. > > > > > # > > > > > -user_group = uaargs.user_group is None or > > > > > uaargs.user_group is True > > > > > +user_group = uaargs.gid is None or uaargs.user_group > > > > > is True > > > > > > > > Hmm, I believe that should be: > > > > > > > > user_group = uaargs.gid is None and uaargs.user_group is > > > > None or uaargs.user_group is True > > > > > > > > I.e., if neither --gid nor --user-group is specified, then it should > > > > treat it as if --user-group was specified. > > > > > > Hm, isn't this still the same as > > > > > > user_group = uaargs.gid is None or uaargs.user_group is True > > No, because uaargs.user_group may be False if --no-user-group is > specified (which I of course should have mentioned in my previous > reply). With your version, you would still get a user group even > if --no-user-group is specified. OK, this is how useradd behaves: useradd --system --home /dev/null --no-create-home --no-user-group distcc -> will add the new user to the group 'users' (as per GROUP from /etc/default/useradd) useradd --system --home /dev/null --no-create-home --gid foo --user-group distcc -> --gid and --user-group together conflict useradd --system --home /dev/null --no-create-home --user-group distcc useradd --system --home /dev/null --no-create-home distcc -> in both cases distcc user and group are created Sp, what about this instead: if uaargs.gid: uaargs.groupname = uaargs.gid uaargs.groupid = field[3] or uaargs.gid elif uaargs.user_group is not False: uaargs.groupname = uaargs.LOGIN uaargs.groupid = field[3] or uaargs.LOGIN else: uaargs.groupname = 'users' uaargs.groupid = field[3] or 'users' Cheers, Andre' > > > ? If neither --gid nor --user-group is specified, then gid is None, so > > > it > > > will do what you want already. IOW, unless the group name (gid) is > > > specified, a username-group is being created. > > > > > > > > > Cheers, > > > Andre' > > //Peter > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3] wic: remove systemd-boot for x32
On Tue, 2017-09-19 at 11:27 -0700, Saul Wold wrote: > Currently systemd-boot actually incorporates libgcc, since the > systemd-boot needs to be built with 64bit instructions it can not > use the x32 based libgcc. I'm a little confused by this since the point of x32 is that it uses all the 64 bit instructions with a 32 bit address space? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] arch-x86: Add x86-x32 to MACHINEOVERRIDES
On Tue, 2017-09-19 at 11:27 -0700, Saul Wold wrote:
> This is needed as an x32 more generic x32 override later in the
> OVERRIDES, currently linux-gnux32 is the first override, but we
> need a stronger (later in the list) x32 override to deal with some
> needed x32 dependency overrides.
>
> Signed-off-by: Saul Wold
> ---
> meta/conf/machine/include/x86/arch-x86.inc | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/meta/conf/machine/include/x86/arch-x86.inc
> b/meta/conf/machine/include/x86/arch-x86.inc
> index e51d595f74..31d30b3304 100644
> --- a/meta/conf/machine/include/x86/arch-x86.inc
> +++ b/meta/conf/machine/include/x86/arch-x86.inc
> @@ -26,6 +26,7 @@ TUNE_LDARGS += "${@bb.utils.contains('TUNE_FEATURES',
> 'mx32', '-m elf32_x86_64',
> TUNE_ASARGS += "${@bb.utils.contains('TUNE_FEATURES', 'mx32', '-x32', '',
> d)}"
> # user mode qemu doesn't support x32
> MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
> ${@bb.utils.contains('TUNE_FEATURES', 'mx32', 'qemu-usermode', '', d)}"
> +MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'mx32',
> 'x86_x32:', '' ,d)}"
>
> # ELF64 ABI
> TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
I was ok with this until I realised the patch does not do what it says
in the commit message, it adds "x86_x32", not "x86-x32". Since "_" is
the override modifier, I worry about how this reacts with the rest of
the system and I suspect its a bad idea. Is there a reason you didn't
use "x86-x32" (following the example of x86-64)?
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ltp: fix hanging issue for gdb01 case
If gdb01 testcase runs as background process, gdb can receive SIGTTOU
and then the case gets stuck. Replace stdin with /dev/null to fix this
issue. The patch is backported from upstream.
Signed-off-by: Yi Zhao
---
...ommands-gdb01-replace-stdin-with-dev-null.patch | 34 ++
meta/recipes-extended/ltp/ltp_20170516.bb | 1 +
2 files changed, 35 insertions(+)
create mode 100644
meta/recipes-extended/ltp/ltp/0038-commands-gdb01-replace-stdin-with-dev-null.patch
diff --git
a/meta/recipes-extended/ltp/ltp/0038-commands-gdb01-replace-stdin-with-dev-null.patch
b/meta/recipes-extended/ltp/ltp/0038-commands-gdb01-replace-stdin-with-dev-null.patch
new file mode 100644
index 000..f7c0a4b
--- /dev/null
+++
b/meta/recipes-extended/ltp/ltp/0038-commands-gdb01-replace-stdin-with-dev-null.patch
@@ -0,0 +1,34 @@
+From 2f6ab8f694b26b7f2566624f6d1f23788d6ab8a0 Mon Sep 17 00:00:00 2001
+From: Jan Stancek
+Date: Mon, 11 Sep 2017 12:57:58 +0200
+Subject: [PATCH] commands/gdb01: replace stdin with /dev/null
+
+If this testcase runs as background process, gdb can receive
+SIGTTOU and then testcase gets stuck.
+
+Signed-off-by: Jan Stancek
+
+Upstream-Status: Backport
+[https://github.com/linux-test-project/ltp/commit/2f6ab8f694b26b7f2566624f6d1f23788d6ab8a0]
+
+Signed-off-by: Yi Zhao
+---
+ testcases/commands/gdb/gdb01.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/testcases/commands/gdb/gdb01.sh b/testcases/commands/gdb/gdb01.sh
+index 07ae36f..e3a5b51 100755
+--- a/testcases/commands/gdb/gdb01.sh
b/testcases/commands/gdb/gdb01.sh
+@@ -29,7 +29,7 @@ TST_NEEDS_CMDS="gdb /bin/cat"
+
+ simple_test()
+ {
+- gdb /bin/cat -ex "run /etc/passwd" -ex quit
++ gdb /bin/cat -ex "run /etc/passwd" -ex quit < /dev/null
+ RC=$?
+ if [ $RC -eq 0 ] ; then
+ tst_res TPASS "gdb attached to process and completed run"
+--
+2.7.4
+
diff --git a/meta/recipes-extended/ltp/ltp_20170516.bb
b/meta/recipes-extended/ltp/ltp_20170516.bb
index 1d0cc1a..653cbfd 100644
--- a/meta/recipes-extended/ltp/ltp_20170516.bb
+++ b/meta/recipes-extended/ltp/ltp_20170516.bb
@@ -49,6 +49,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
file://0035-fix-test_proc_kill-hang.patch \
file://0036-testcases-network-nfsv4-acl-acl1.c-Security-fix-on-s.patch \
file://0037-ltp-fix-PAGE_SIZE-redefinition-and-O_CREAT-undeclear.patch \
+ file://0038-commands-gdb01-replace-stdin-with-dev-null.patch \
"
S = "${WORKDIR}/git"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] dbus: 1.10.20 -> 1.10.22
Upgrade dbus from 1.10.20 to 1.10.22
Signed-off-by: fan@jp.fujitsu.com
---
meta/recipes-core/dbus/dbus_1.10.20.bb | 180 -
meta/recipes-core/dbus/dbus_1.10.22.bb | 180 +
2 files changed, 180 insertions(+), 180 deletions(-)
delete mode 100644 meta/recipes-core/dbus/dbus_1.10.20.bb
create mode 100644 meta/recipes-core/dbus/dbus_1.10.22.bb
diff --git a/meta/recipes-core/dbus/dbus_1.10.20.bb
b/meta/recipes-core/dbus/dbus_1.10.20.bb
deleted file mode 100644
index 9ddedc1..000
--- a/meta/recipes-core/dbus/dbus_1.10.20.bb
+++ /dev/null
@@ -1,180 +0,0 @@
-SUMMARY = "D-Bus message bus"
-DESCRIPTION = "D-Bus is a message bus system, a simple way for applications to
talk to one another. In addition to interprocess communication, D-Bus helps
coordinate process lifecycle; it makes it simple and reliable to code a
\"single instance\" application or daemon, and to launch applications and
daemons on demand when their services are needed."
-HOMEPAGE = "http://dbus.freedesktop.org";
-SECTION = "base"
-LICENSE = "AFL-2 | GPLv2+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
-
file://dbus/dbus.h;beginline=6;endline=20;md5=7755c9d7abccd5dbd25a6a974538bb3c"
-DEPENDS = "expat virtual/libintl"
-RDEPENDS_dbus_class-native = ""
-RDEPENDS_dbus_class-nativesdk = ""
-PACKAGES += "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '${PN}-ptest',
'', d)}"
-ALLOW_EMPTY_dbus-ptest = "1"
-RDEPENDS_dbus-ptest_class-target = "dbus-test-ptest"
-
-SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
- file://tmpdir.patch \
- file://dbus-1.init \
- file://os-test.patch \
- file://clear-guid_from_server-if-send_negotiate_unix_f.patch \
- file://0001-configure.ac-explicitely-check-stdint.h.patch \
-"
-
-SRC_URI[md5sum] = "94c991e763d4f9f13690416b2dcd9411"
-SRC_URI[sha256sum] =
"e574b9780b5425fde4d973bb596e7ea0f09e00fe2edd662da9016e976c460b48"
-
-inherit useradd autotools pkgconfig gettext update-rc.d
upstream-version-is-even
-
-INITSCRIPT_NAME = "dbus-1"
-INITSCRIPT_PARAMS = "start 02 5 3 2 . stop 20 0 1 6 ."
-
-python __anonymous() {
-if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
-d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
-}
-
-USERADD_PACKAGES = "${PN}"
-GROUPADD_PARAM_${PN} = "-r netdev"
-USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \
- --no-create-home --shell /bin/false \
- --user-group messagebus"
-
-CONFFILES_${PN} = "${sysconfdir}/dbus-1/system.conf
${sysconfdir}/dbus-1/session.conf"
-
-DEBIANNAME_${PN} = "dbus-1"
-
-PACKAGES =+ "${PN}-lib"
-
-OLDPKGNAME = "dbus-x11"
-OLDPKGNAME_class-nativesdk = ""
-
-# for compatibility
-RPROVIDES_${PN} = "${OLDPKGNAME}"
-RREPLACES_${PN} += "${OLDPKGNAME}"
-
-FILES_${PN} = "${bindir}/dbus-daemon* \
- ${bindir}/dbus-uuidgen \
- ${bindir}/dbus-cleanup-sockets \
- ${bindir}/dbus-send \
- ${bindir}/dbus-monitor \
- ${bindir}/dbus-launch \
- ${bindir}/dbus-run-session \
- ${bindir}/dbus-update-activation-environment \
- ${libexecdir}/dbus* \
- ${sysconfdir} \
- ${localstatedir} \
- ${datadir}/dbus-1/services \
- ${datadir}/dbus-1/system-services \
- ${datadir}/dbus-1/session.d \
- ${datadir}/dbus-1/session.conf \
- ${datadir}/dbus-1/system.d \
- ${datadir}/dbus-1/system.conf \
- ${systemd_system_unitdir} \
- ${systemd_user_unitdir} \
-"
-FILES_${PN}-lib = "${libdir}/lib*.so.*"
-RRECOMMENDS_${PN}-lib = "${PN}"
-FILES_${PN}-dev += "${libdir}/dbus-1.0/include ${bindir}/dbus-test-tool"
-
-PACKAGE_WRITE_DEPS += "${@bb.utils.contains('DISTRO_FEATURES','systemd
sysvinit','systemd-systemctl-native','',d)}"
-pkg_postinst_dbus() {
- # If both systemd and sysvinit are enabled, mask the dbus-1 init script
-if ${@bb.utils.contains('DISTRO_FEATURES','systemd
sysvinit','true','false',d)}; then
- if [ -n "$D" ]; then
- OPTS="--root=$D"
- fi
- systemctl $OPTS mask dbus-1.service
- fi
-
- if [ -z "$D" ] && [ -e /etc/init.d/populate-volatile.sh ] ; then
- /etc/init.d/populate-volatile.sh update
- fi
-}
-
-EXTRA_OECONF = "--disable-tests \
---disable-xml-docs \
---disable-doxygen-docs \
---disable-libaudit \
---enable-largefile \
-"
-
-EXTRA_OECONF_append_class-target = " SYSTEMCTL=${base_bindir}/systemctl"
-EXTRA_OECONF_append_class-native = " --disable-selinux"
-
-PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'systemd x11', d)}"
-PACKAGECONFIG_class-native = ""
-PACKAGECONFIG_c
