Re: [OE-core] [PATCH 1/4] powertop: Include right headers for timval struct

On 25 September 2015 at 05:59, Khem Raj wrote: > +From 0856d8145d187a7e5a49625247abe43a13f95acc Mon Sep 17 00:00:00 2001 > +From: Khem Raj > +Date: Tue, 15 Sep 2015 19:36:28 + > +Subject: [PATCH] include rquired headers for typedefs > + > +timeval struct needs to include sys/time.h and sprin

Re: [OE-core] [PATCH 3/4] blktrace: Include

On 25 September 2015 at 05:59, Khem Raj wrote: > +Status: Submitted > We have tooling around this field, so please use Upstream-Status. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/

Re: [OE-core] [PATCH V2] busybox: Use CC instead of bare LD to be the Linker

On 25 September 2015 at 06:06, Khem Raj wrote: > this is a resend of the very same patch which was send 2-3 weeks ago > Sorry that must have slipped through the cracks. Can you rebase to current master as it doesn't apply anymore and re-send? Ross -- __

Re: [OE-core] [PATCH] gnutls: cleanup buildpaths from gnutls.pc

On 09/24/2015 07:55 PM, Burton, Ross wrote: On 24 September 2015 at 12:49, Jussi Kukkonen mailto:jussi.kukko...@intel.com>> wrote: I'm not seeing this problem and gnutls.pc.in file looks ok to me. Any idea how I could reproduce this? Also, just sedding them out o

Re: [OE-core] [PATCH] gstreamer1.0-plugins-bad: change glimagesink rank to marginal

On 09/24/2015 11:03 PM, Nicolas Dechesne wrote: fwiw... on my platforms (QCOM DragonBoard) I rely on glimagesink, and we have good OpenGL support.. but I understand that this isn't the norm for ARM, and more an exception.. I can manage that in my BSP layer, if that ever gets merged. Note we migh

Re: [OE-core] [PATCH] gnutls: cleanup buildpaths from gnutls.pc

On 25 September 2015 at 11:21, wenzong fan wrote: > I'll investigate more about that. Do you know where the difference from? > I'd immediately suspect the lib/lib64 path confusing pkg-config's logic on automatic library path removal. In the non-multilib case it generates a -L[long path] but det

Re: [OE-core] [PATCH] gcc-shared-source: Set empty SRC_URI

On 09/24/2015 12:33 AM, Richard Purdie wrote: gcc-source is the only gcc recipe meant to handle the fetch/unpack/patch tasks, the other gcc recipes then depend on this. This approach has been creating some confusion for tools like the archiver. The simplest way to signal to these processes that

[OE-core] [PATCH 0/2] connman: Always depend on xuser-account & fix D-Bus policy

Review on the policy change is appreciated: it looks clearly correct to me but maybe there's some context I've missed. Cheers, Jussi The following changes since commit 9f66aa1a11b5b45280aa41bf4517ec56ee5f2ab2: bitbake: toaster: start script warning text formatting small improvement (2015-

Re: [OE-core] [PATCH] gcc-shared-source: Set empty SRC_URI

On 09/25/2015 02:03 PM, Alexander Kanavin wrote: gcc-source is the only gcc recipe meant to handle the fetch/unpack/patch tasks, the other gcc recipes then depend on this. This approach has been creating some confusion for tools like the archiver. The simplest way to signal to these processes t

[OE-core] [PATCH 1/2] connman: Depend on xuser-account unconditionally

This means dragging in xuser-account even when it's not used but that's a lesser evil than the recipe depending on machine specific settings. This also prevents a warning on connman service startup when ROOTLESS_X is not set: Unknown username "xuser" in message bus [YOCTO #8005] Signed-off-by:

[OE-core] [PATCH 2/2] connman: Don't use a blanket "allow" D-Bus policy

There are already "allow" rules for root and conditionally xuser to send messages to connman: there should be no reason for a default allow policy. Also, conditionally add a policy to allow xuser to send to the connman vpn service (similar to main service). Signed-off-by: Jussi Kukkonen --- met

Re: [OE-core] [PATCH] pxz: Add recipe and use it for xz image type

On 2015-09-24 22:59, Khem Raj wrote: pxz results in significant time saving when generating xz filetypes for images due to parallelization support This adds another host tool dependency - on my Ubuntu (14.04) system, even if 'xz' is installed, 'pxz' is not and I'd have to add it. Since *.xz se

[OE-core] [PATCH] oeqa/parselogs: Updated log parser whitelist.

Added some fixes for meta-intel boards and moved some errors from specific images to common. Signed-off-by: Lucian Musat --- meta/lib/oeqa/runtime/parselogs.py | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/meta/lib/oeqa/runtime/parselogs.py b/meta/lib/oeqa/runti

[OE-core] [PATCH 2/2] recipeutils.py: don't hardcode the upstream version as 1.0 when SRC_URI is empty or absent

Instead, simply return the version of the recipe, so that the upstream version checker will declare that they match. Signed-off-by: Alexander Kanavin --- meta/lib/oe/recipeutils.py | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/

[OE-core] [PATCH 1/2] distrodata: handle recipes with empty or absent SRC_URI in checkpkg()

Signed-off-by: Alexander Kanavin --- meta/classes/distrodata.bbclass | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/meta/classes/distrodata.bbclass b/meta/classes/distrodata.bbclass index 4168e43..e6eb3f3 100644 --- a/meta/classes/distrodata.bbclass +++ b/meta/cl

Re: [OE-core] [PATCH] pxz: Add recipe and use it for xz image type

> On Sep 25, 2015, at 4:22 AM, Gary Thomas wrote: > > On 2015-09-24 22:59, Khem Raj wrote: >> pxz results in significant time saving when generating xz filetypes for >> images due to parallelization support > > This adds another host tool dependency - on my Ubuntu (14.04) system, even > if 'xz'

[OE-core] [PATCH 2/2] busybox: Use CC instead of bare LD to be the Linker

This patch was on mailing list, another patch to make sure -r is not passed directly but via -Wl switch is added. This was exposed when using clang and gold linker, clang does not have -r switch to do relocatable objects and problem happens specific to OE becuase we use LD = CC now what happens i

[OE-core] [PATCH 1/2] busybox: Use UTMPX instead of legacy UTMP

This makes busybox honor UTMPX feature if available in a libc [YOCTO #8243] Signed-off-by: Khem Raj --- .../busybox/0001-Switch-to-POSIX-utmpx-API.patch | 388 + meta/recipes-core/busybox/busybox_1.23.2.bb| 1 + 2 files changed, 389 insertions(+) create mode 100

Re: [OE-core] [PATCH] pxz: Add recipe and use it for xz image type

On 2015-09-25 07:25, Khem Raj wrote: On Sep 25, 2015, at 4:22 AM, Gary Thomas wrote: On 2015-09-24 22:59, Khem Raj wrote: pxz results in significant time saving when generating xz filetypes for images due to parallelization support This adds another host tool dependency - on my Ubuntu (14.

[OE-core] [PATCH] byacc: add missing patch header

Signed-off-by: Ross Burton --- meta/recipes-extended/byacc/byacc/byacc-open.patch | 12 1 file changed, 12 insertions(+) diff --git a/meta/recipes-extended/byacc/byacc/byacc-open.patch b/meta/recipes-extended/byacc/byacc/byacc-open.patch index 9160543..0058311 100644 --- a/meta/rec

[OE-core] [PATCH 1/1] qemurunner: Sanitize output from qemu and qemu pid

From: Mariano Lopez Currently the output from qemu could contain control or Unicode characters; having such characters in the log will cause an internal server error when sending the report to error reporting web. Control characters can be found in the command line used to run quemu too. This ch

Re: [OE-core] [PATCH] opkg: create opkg.lock in /run instead of /var/run

On 21/09/2015 10:16 PM, Anders Darander wrote: * Jonathan Liu [150921 13:08]: This avoids a "Could not unlink" warning when extracting a /var/run symbolic link pointing to /run from the base-files package as it is unable to unlink the /var/run directory when it contains opkg.lock. This also fi

[OE-core] Yocto Project Status WW39

Current Dev Position: YP 2.0 Final Next Deadline: 2.0 Cut off: Sept. 28, 2015 noon GMT SWAT team rotation: Paul -> Ross https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: * 'Random' build failures are continuing to cause issues, we're continuing to try and

Re: [OE-core] [PATCH 1/2] connman: Depend on xuser-account unconditionally

Hello Jussi, On 25.09.2015 13:14, Jussi Kukkonen wrote: > This means dragging in xuser-account even when it's not used but > that's a lesser evil than the recipe depending on machine specific > settings. that's quite ugly, sorry. It's true that machine specific variables shouldn't be used in thi

Re: [OE-core] [PATCH 2/2] connman: Don't use a blanket "allow" D-Bus policy

On 25.09.2015 13:14, Jussi Kukkonen wrote: > There are already "allow" rules for root and conditionally xuser to > send messages to connman: there should be no reason for a default > allow policy. > > Also, conditionally add a policy to allow xuser to send to the > connman vpn service (similar to

Re: [OE-core] [PATCH 1/2] connman: Depend on xuser-account unconditionally

On 25 September 2015 at 16:59, Andreas Oberritter wrote: > Whether to add user accounts or not should be a decision made by the > distro. If this setting is machine specific, which to be honest > surprised me, why don't you just let the machine specific xorg video > driver depend on xuser-account

Re: [OE-core] [PATCH 2/2] connman: Don't use a blanket "allow" D-Bus policy

On 25 September 2015 at 17:06, Andreas Oberritter wrote: > Here you can see that it really is poky's distro policy that slipped > into OE-Core. How about removing ROOTLESS_X and xuser from OE-Core and > putting it into a layer that actually sets the variable? > There's nothing about Poky here.

[OE-core] [PATCH] sstate: fix typo resulting in crazy directory creation

A transposed , and ) meant that a string was passed to a function instead of a list of strings, so bitbake ends up creating a directory for every character in the current working directory. Signed-off-by: Ross Burton --- meta/classes/sstate.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 delet

Re: [OE-core] [PATCH] sstate: fix typo resulting in crazy directory creation

On Fri, Sep 25, 2015 at 9:20 AM, Ross Burton wrote: > A transposed , and ) meant that a string was passed to a function instead > of a > list of strings, so bitbake ends up creating a directory for every > character in > the current working directory. > > Signed-off-by: Ross Burton > --- > meta

Re: [OE-core] [PATCH] sstate: fix typo resulting in crazy directory creation

On 25 September 2015 at 17:29, Christopher Larson wrote: > I think I'd have just passed a list instead of a tuple here :) Easier to > parse visually. > Yeah, agreed in hindsight. Also insert a groan about untyped languages. Ross -- ___ Openembedded-

Re: [OE-core] [PATCH] gdk-pixbuf: Avoid rebuild failures

On Thu, Sep 24, 2015 at 6:40 PM, Richard Purdie wrote: > On Thu, 2015-09-24 at 08:27 -0300, Otavio Salvador wrote: >> Thanks for hunting this bug, this was very annoying and hard to >> figure. It does seem to address the issue in our builder. > > Sadly, whilst I merged it and it does fix that prob

Re: [OE-core] [PATCH][dizzy] grep2.19: CVE-2015-1345

Sona, On 09/16/2015 07:31 AM, Sona Sarmadi wrote: > Fixes heap-based buffer overflow flaw in grep. > Affected versions are: grep 2.19 through 2.21 > > Removed THANKS.in changes from upstream patch since this > file does not exist in version 2.19. > Replaced tab with spaces in SRC_URI as well. th

Re: [OE-core] [PATCH] pxz: Add recipe and use it for xz image type

On Thu, Sep 24, 2015 at 9:59 PM, Khem Raj wrote: > pxz results in significant time saving when generating xz filetypes for > images due to parallelization support It looks like the version of xz utils already packaged in oe-core supports multiple threads via the -T option. See XZ_THREADS in image

Re: [OE-core] [PATCH] pxz: Add recipe and use it for xz image type

> On Sep 25, 2015, at 11:24 AM, Andre McCurdy wrote: > > On Thu, Sep 24, 2015 at 9:59 PM, Khem Raj wrote: >> pxz results in significant time saving when generating xz filetypes for >> images due to parallelization support > > It looks like the version of xz utils already packaged in oe-core >

Re: [OE-core] [PATCH] pxz: Add recipe and use it for xz image type

On Fri, Sep 25, 2015 at 11:34 AM, Khem Raj wrote: > >> On Sep 25, 2015, at 11:24 AM, Andre McCurdy wrote: >> >> On Thu, Sep 24, 2015 at 9:59 PM, Khem Raj wrote: >>> pxz results in significant time saving when generating xz filetypes for >>> images due to parallelization support >> >> It looks li

Re: [OE-core] [PATCH 1/3] oe.scriptutils: enable color in a more flexible way

On Wed, Sep 23, 2015 at 11:24 AM, Christopher Larson wrote: > From: Christopher Larson > > Rather than recreating handlers and forcing them, iterate over the handlers > and enable color on ones we can handle. This makes it easier to handle > color > properly when we introduce the bb.msg default

[OE-core] [PATCHv3] lsb: add lsbinitscripts and util-linux rdepends

Changes since v2: moved util-linux RDEPENDS to lsbinitscripts, while lsb still holds the lsbinitscritps dependency. It was suggested it may be better to split up util-linux. Individual utils like mountpoint in this case, could be added in a granular way instead of potentially causing bloat. This s

[OE-core] [PATCHv3] lsb: add lsbinitscripts and util-linux rdepends

Building a base image such as core-image-minimal with lsb and then attempting to source /lib/lsb/init-functions, then using the start _daemon function (to start a daemon, such as syslogd) fails, since /lib/lsb/init-functions use functions (incl. "daemon()") from file /etc/init.d/functions.lsbinitsc

[OE-core] OpenEmbedded e.V. Technical Steering Committee Elections

All, I'm sending this email to openembedded-devel and openembedded-core mailing lists to reach out to those OpenEmbedded e.V. members who might not be subscribed to the members-only mailing list and are not aware of ongoing elections to the Technical Steering Committee. If you are part of the

[OE-core] [PATCH 1/3] gdk-pixbuf: move gdk-pixbuf-pixdata to gdk-pixbuf-dev

This is a development tool, similar to gdk-pixbuf-csource, so move it to the -dev package. Signed-off-by: Ross Burton --- meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.30.8.bb

[OE-core] [PATCH 2/3] gdk-pixbuf: move gdk-pixbuf-query-loaders to $libdir for multilib safety

If for example gdk-pixbuf and lib32-gdk-pixbuf are in an image then only one ${bindir}/gdk-pixbuf-query-loaders will be installed, so only one variant will actually be usable. Solve this by moving gdk-pixbuf-query-loaders into ${libdir} as it's intimately tied to the library and rarely directly in

[OE-core] [PATCH 3/3] librsvg: tell configure where gdk-pixbuf-query-loaders is

Now that gdk-pixbuf-query-loaders isn't in the path, tell configure where to find it. Signed-off-by: Ross Burton --- meta/recipes-gnome/librsvg/librsvg_2.40.10.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/recipes-gnome/librsvg/librsvg_2.40.10.bb b/meta/recipes-gnome/librsvg/lib

[OE-core] [PATCH] gtk-icon-cache/pixbufcache: don't set GDK_PIXBUF_MODULEDIR

In normal use gdk-pixbuf knows where to find its own loaders and explicitly stating this will cause work in the future if the ABI version changes. Signed-off-by: Ross Burton --- meta/classes/gtk-icon-cache.bbclass | 2 +- meta/classes/pixbufcache.bbclass| 2 +- 2 files changed, 2 insertions(

[OE-core] [PATCH][V2] gtk-icon-cache/pixbufcache: don't set GDK_PIXBUF_MODULEDIR

In normal use gdk-pixbuf knows where to find its own loaders and explicitly stating this will cause work in the future if the ABI version changes. Signed-off-by: Ross Burton --- meta/classes/gtk-icon-cache.bbclass | 2 +- meta/classes/pixbufcache.bbclass| 2 +- 2 files changed, 2 insertions(

[OE-core] [PATCH] AB random failure: libpcre-native split_and_strip

Error handling: adding file-native as a dependency to libpre recipe should guarantee a consistent, and more importantly POSIX-compliant version of the "file" command is always used when checking the file "pcre-config" within the isELF function in staging.bbclass. Following the POSIX behavior, file

[OE-core] [meta-oe][PATCH v2] opkg: create opkg.lock in /run instead of /var/run

This avoids a "Could not unlink" warning when extracting a /var/run symbolic link pointing to /run from the base-files package as it is unable to unlink the /var/run directory when it contains opkg.lock. This also fixes an issue where /var/run is created as a directory instead of a symbolic link t

Re: [OE-core] [meta-oe][PATCH v2] opkg: create opkg.lock in /run instead of /var/run

On 26/09/2015 9:34 AM, Jonathan Liu wrote: This avoids a "Could not unlink" warning when extracting a /var/run symbolic link pointing to /run from the base-files package as it is unable to unlink the /var/run directory when it contains opkg.lock. This also fixes an issue where /var/run is create

[OE-core] [PATCH v2] opkg: create opkg.lock in /run instead of /var/run

This avoids a "Could not unlink" warning when extracting a /var/run symbolic link pointing to /run from the base-files package as it is unable to unlink the /var/run directory when it contains opkg.lock. This also fixes an issue where /var/run is created as a directory instead of a symbolic link t

Re: [OE-core] [PATCH] AB random failure: libpcre-native split_and_strip

On Fri, 2015-09-25 at 17:54 -0500, Alex Franco wrote: > Error handling: adding file-native as a dependency to libpre recipe > should guarantee a consistent, and more importantly POSIX-compliant > version of the "file" command is always used when checking the file > "pcre-config" within the isELF fu