Re: [OE-core] [PATCH v2 1/2] classes/uboot-extlinux-config: Add class

2016-10-03 Thread Ulf Magnusson
On Tue, Oct 4, 2016 at 12:24 AM, Ulf Magnusson  wrote:
> On Tue, Oct 4, 2016 at 12:08 AM, Ulf Magnusson  wrote:
>> Hello,
>>
>> On Mon, Oct 3, 2016 at 2:17 PM, Fabio Berton
>>  wrote:
>>> This class allow the extlinux.conf generation for U-Boot use.
>>> The U-Boot support for it is given to allow the Generic Distribution
>>> Configuration specification use by OpenEmbedded-based products.
>>>
>>> This class can be inherited by u-boot recipes to create extlinux.conf
>>> and boot using menu options.
>>>
>>> U-boot with extlinux support is machine dependent, so to use this class
>>> you need to set UBOOT_EXTLINUX to 1 in machine configuration file and
>>> also set root= kernel cmdline UBOOT_EXTLINUX_ROOT. This variable is used
>>> to pass root kernel cmdline, e.g:
>>>
>>> UBOOT_EXTLINUX_ROOT = "root=/dev/mmcblk2p2"
>>>
>>> Signed-off-by: Fabio Berton 
>>> Signed-off-by: Otavio Salvador 
>>> ---
>>>  meta/classes/uboot-extlinux-config.bbclass | 130 
>>> +
>>>  1 file changed, 130 insertions(+)
>>>  create mode 100644 meta/classes/uboot-extlinux-config.bbclass
>>>
>>> diff --git a/meta/classes/uboot-extlinux-config.bbclass 
>>> b/meta/classes/uboot-extlinux-config.bbclass
>>> new file mode 100644
>>> index 000..a4dc0c0
>>> --- /dev/null
>>> +++ b/meta/classes/uboot-extlinux-config.bbclass
>>> @@ -0,0 +1,130 @@
>>> +# uboot-extlinux-config.bbclass
>>> +#
>>> +# This class allow the extlinux.conf generation for U-Boot use. The
>>> +# U-Boot support for it is given to allow the Generic Distribution
>>> +# Configuration specification use by OpenEmbedded-based products.
>>> +#
>>> +# External variables:
>>> +#
>>> +# UBOOT_EXTLINUX_CONFIG- Configuration file default set to 
>>> source dir.
>>> +# UBOOT_EXTLINUX_CONSOLE   - Set to "console=ttyX" to change 
>>> kernel boot
>>> +#default console.
>>> +# UBOOT_EXTLINUX_LABELS- A list of targets for the automatic 
>>> config.
>>> +# UBOOT_EXTLINUX_KERNEL_ARGS   - Add additional kernel arguments.
>>> +# UBOOT_EXTLINUX_KERNEL_IMAGE  - Kernel image name.
>>> +# UBOOT_EXTLINUX_FDTDIR- Device tree directory.
>>> +# UBOOT_EXTLINUX_INITRD- Indicates a list of filesystem images 
>>> to
>>> +#concatenate and use as an initrd 
>>> (optional).
>>> +# UBOOT_EXTLINUX_MENU_DESCRIPTION  - Name to use as description.
>>> +# UBOOT_EXTLINUX_ROOT  - Root kernel cmdline.
>>> +#
>>> +# If there's only one label system will boot automatically and menu won't 
>>> be
>>> +# created. If you want to use more than one labels, e.g linux and 
>>> alternate,
>>> +# use overrides to set menu description, console and others variables.
>>> +#
>>> +# Ex:
>>> +#
>>> +# UBOOT_EXTLINUX_LABELS ??= "default fallback"
>>> +#
>>> +# UBOOT_EXTLINUX_KERNEL_IMAGE_default ??= "../zImage"
>>> +# UBOOT_EXTLINUX_MENU_DESCRIPTION_default ??= "Linux Default"
>>> +#
>>> +# UBOOT_EXTLINUX_KERNEL_IMAGE_fallback ??= "../zImage-fallback"
>>> +# UBOOT_EXTLINUX_MENU_DESCRIPTION_fallback ??= "Linux Fallback"
>>> +#
>>> +# Results:
>>> +#
>>> +# menu title Select the boot mode
>>> +# LABEL Linux Default
>>> +#   KERNEL ../zImage
>>> +#   FDTDIR ../
>>> +#   APPEND root=/dev/mmcblk2p2 rootwait rw console=${console}
>>> +# LABEL Linux Fallback
>>> +#   KERNEL ../zImage-fallback
>>> +#   FDTDIR ../
>>> +#   APPEND root=/dev/mmcblk2p2 rootwait rw console=${console}
>>> +#
>>> +# Copyright (C) 2016, O.S. Systems Software LTDA.  All Rights Reserved
>>> +# Released under the MIT license (see packages/COPYING)
>>> +#
>>> +# The kernel has an internal default console, which you can override with
>>> +# a console=...some_tty...
>>> +UBOOT_EXTLINUX_CONSOLE ??= "console=${console}"
>>> +UBOOT_EXTLINUX_CONFIG ??= "${S}/extlinux.conf"
>>> +UBOOT_EXTLINUX_LABELS ??= "linux"
>>> +UBOOT_EXTLINUX_FDTDIR ??= "../"
>>> +UBOOT_EXTLINUX_KERNEL_IMAGE ??= "../${KERNEL_IMAGETYPE}"
>>> +UBOOT_EXTLINUX_KERNEL_ARGS ??= "rootwait rw"
>>> +UBOOT_EXTLINUX_MENU_DESCRIPTION_linux ??= "${DISTRO_NAME}"
>>> +
>>> +python create_extlinux_config() {
>>> +if d.getVar("UBOOT_EXTLINUX", False) == "1":
>>
>> Is there a reason why False is passed here? Passing True would make
>> the code more general, as the value of the flag could come from
>> another variable, e.g.
>>
>>   UBOOT_EXTLINUX = "${SOME_FLAG_HELPER_VAR}"
>>
>> , or from a function, e.g.
>>
>>   UBOOT_EXTLINUX = "${@needs_uboot_extlinux()}"
>>
>> As a minor style note, the indentation of the function could be
>> decreased by doing
>>
>>   if d.getVar("UBOOT_EXTLINUX", True) != "1":
>>   return
>>   ...
>>
>> That might avoid excessive indentation if you use 'with' as mentioned below.
>>
>>> +workdir = d.getVar('WORKDIR', True)
>>> +if not workdir:
>>> +bb.error("WORKDIR 

[OE-core] [PATCH V3] devtool: modify command fails to ignore source files

2016-10-03 Thread Stephano Cetola
With recent changes to recipeutils, the list of local files returned
by get_recipe_local_files could possibly include source files. This
only happens when the recipe contains a SRC_URI using subdir= to put
files in the source tree. These files should be ignored when
populating the list of local files for oe-local-files directory.

[YOCTO #10326]

introduced in
OE-Core revision 9069fef5dad5a873c8a8f720f7bcbc7625556309

Signed-off-by: Stephano Cetola 
---
 scripts/lib/devtool/standard.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 8319145..48b0a5e 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -568,8 +568,13 @@ def _extract_source(srctree, keep_temp, devbranch, sync, 
d):
 recipe_patches = [os.path.basename(patch) for patch in
   oe.recipeutils.get_recipe_patches(crd)]
 local_files = oe.recipeutils.get_recipe_local_files(crd)
+
+# Ignore local files with subdir={BP}
+srcabspath = os.path.abspath(srcsubdir)
 local_files = [fname for fname in local_files if
-   os.path.exists(os.path.join(workdir, fname))]
+   os.path.exists(os.path.join(workdir, fname)) and
+   not os.path.join(workdir, fname).startswith(srcabspath +
+   os.sep)]
 if local_files:
 for fname in local_files:
 _move_file(os.path.join(workdir, fname),
-- 
2.10.0

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


[OE-core] [PATCH V3] devtool: modify command fails to ignore source files

2016-10-03 Thread Stephano Cetola
Changes since V2:
Added os.sep to path name for decreased chance of false positive matches.

Stephano Cetola (1):
  devtool: modify command fails to ignore source files

 scripts/lib/devtool/standard.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
2.10.0

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


Re: [OE-core] [PATCH V2] devtool: modify command fails to ignore source files

2016-10-03 Thread Stephano Cetola
On 10/04, Paul Eggleton wrote:
> On Sun, 02 Oct 2016 16:58:24 Stephano Cetola wrote:
> > With recent changes to recipeutils, the list of local files returned
> > by get_recipe_local_files could possibly include source files. This
> > only happens when the recipe contains a SRC_URI using subdir= to put
> > files in the source tree. These files should be ignored when
> > populating the list of local files for oe-local-files directory.
> > 
> > [YOCTO #10326]
> > 
> > introduced in
> > OE-Core revision 9069fef5dad5a873c8a8f720f7bcbc7625556309
> > 
> > Signed-off-by: Stephano Cetola 
> > ---
> >  scripts/lib/devtool/standard.py | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/scripts/lib/devtool/standard.py
> > b/scripts/lib/devtool/standard.py index 8319145..b6f9e12 100644
> > --- a/scripts/lib/devtool/standard.py
> > +++ b/scripts/lib/devtool/standard.py
> > @@ -568,8 +568,12 @@ def _extract_source(srctree, keep_temp, devbranch,
> > sync, d): recipe_patches = [os.path.basename(patch) for patch in
> >oe.recipeutils.get_recipe_patches(crd)]
> >  local_files = oe.recipeutils.get_recipe_local_files(crd)
> > +
> > +# Ignore local files with subdir={BP}
> > +srcabspath = os.path.abspath(srcsubdir)
> >  local_files = [fname for fname in local_files if
> > -   os.path.exists(os.path.join(workdir, fname))]
> > +   os.path.exists(os.path.join(workdir, fname)) and
> > +   not os.path.join(workdir,
> > fname).startswith(srcabspath)] if local_files:
> >  for fname in local_files:
> >  _move_file(os.path.join(workdir, fname),
> 
> OK - this looks better. One minor tweak I'd suggest though is to add os.sep 
> on 
> the end of srcabspath so we can be sure we're matching that directory and not 
> one whose name starts with the same string.

Good point. I'll add this in and resubmit.

> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH V2] devtool: modify command fails to ignore source files

2016-10-03 Thread Paul Eggleton
On Sun, 02 Oct 2016 16:58:24 Stephano Cetola wrote:
> With recent changes to recipeutils, the list of local files returned
> by get_recipe_local_files could possibly include source files. This
> only happens when the recipe contains a SRC_URI using subdir= to put
> files in the source tree. These files should be ignored when
> populating the list of local files for oe-local-files directory.
> 
> [YOCTO #10326]
> 
> introduced in
> OE-Core revision 9069fef5dad5a873c8a8f720f7bcbc7625556309
> 
> Signed-off-by: Stephano Cetola 
> ---
>  scripts/lib/devtool/standard.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/lib/devtool/standard.py
> b/scripts/lib/devtool/standard.py index 8319145..b6f9e12 100644
> --- a/scripts/lib/devtool/standard.py
> +++ b/scripts/lib/devtool/standard.py
> @@ -568,8 +568,12 @@ def _extract_source(srctree, keep_temp, devbranch,
> sync, d): recipe_patches = [os.path.basename(patch) for patch in
>oe.recipeutils.get_recipe_patches(crd)]
>  local_files = oe.recipeutils.get_recipe_local_files(crd)
> +
> +# Ignore local files with subdir={BP}
> +srcabspath = os.path.abspath(srcsubdir)
>  local_files = [fname for fname in local_files if
> -   os.path.exists(os.path.join(workdir, fname))]
> +   os.path.exists(os.path.join(workdir, fname)) and
> +   not os.path.join(workdir,
> fname).startswith(srcabspath)] if local_files:
>  for fname in local_files:
>  _move_file(os.path.join(workdir, fname),

OK - this looks better. One minor tweak I'd suggest though is to add os.sep on 
the end of srcabspath so we can be sure we're matching that directory and not 
one whose name starts with the same string.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] linux-libc-headers: if_tunnel: remove include of if/ip/in6.h

2016-10-03 Thread Bruce Ashfield
On Mon, Oct 3, 2016 at 3:55 PM, Khem Raj  wrote:

> What Repercussion does this have wrt APIs headers for future. Provided
> this is a local patch. I think removing header includes like this can cause
> issues.
>


It's something we could drop in the future, but these are mods that have
been done since -rc4, and could very well be undone if they start breaking
things like this.

The alternative is to try and fix the userspace applications, but I
currently don't see a fast way to do that (and I'm now officially on
vacation).

Cheers,

Bruce


>
> On Oct 3, 2016 9:55 AM, "Bruce Ashfield" 
> wrote:
>
> commit 1fe8e0f074c [include/uapi/linux/if_tunnel.h: include linux/if.h,
> linux/ip.h and linux/in6.h]
> breaks the builds of net-tools.
>
> We remove the new includes until such a time that userspace can adapt to
> the
> new kernel headers.
>
> Signed-off-by: Bruce Ashfield 
> ---
>  ...1-if_tunnel-remove-include-of-if-ip-in6.h.patch | 33
> ++
>  .../linux-libc-headers/linux-libc-headers_4.8.bb   |  1 +
>  2 files changed, 34 insertions(+)
>  create mode 100644 meta/recipes-kernel/linux-libc
> -headers/linux-libc-headers/0001-if_tunnel-remove-include-
> of-if-ip-in6.h.patch
>
> diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/
> 0001-if_tunnel-remove-include-of-if-ip-in6.h.patch
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/
> 0001-if_tunnel-remove-include-of-if-ip-in6.h.patch
> new file mode 100644
> index ..f2011880dccb
> --- /dev/null
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/
> 0001-if_tunnel-remove-include-of-if-ip-in6.h.patch
> @@ -0,0 +1,33 @@
> +From 017ae5929312685c4c044765445bfd4d2a4abb5c Mon Sep 17 00:00:00 2001
> +From: Bruce Ashfield 
> +Date: Mon, 3 Oct 2016 12:27:57 -0400
> +Subject: [PATCH] if_tunnel: remove include of if/ip/in6.h
> +
> +commit 1fe8e0f074c [include/uapi/linux/if_tunnel.h: include linux/if.h,
> linux/ip.h and linux/in6.h]
> +breaks the builds of net-tools.
> +
> +We remove the new includes until such a time that userspace can adapt to
> the
> +new kernel headers.
> +
> +Signed-off-by: Bruce Ashfield 
> +---
> + include/uapi/linux/if_tunnel.h | 3 ---
> + 1 file changed, 3 deletions(-)
> +
> +diff --git a/include/uapi/linux/if_tunnel.h
> b/include/uapi/linux/if_tunnel.h
> +index 777b6cd..1046f55 100644
> +--- a/include/uapi/linux/if_tunnel.h
>  b/include/uapi/linux/if_tunnel.h
> +@@ -2,9 +2,6 @@
> + #define _UAPI_IF_TUNNEL_H_
> +
> + #include 
> +-#include 
> +-#include 
> +-#include 
> + #include 
> +
> +
> +--
> +2.7.4
> +
> diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_
> 4.8.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb
> index 778f0b6e6443..ee2d8293450e 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb
> @@ -10,6 +10,7 @@ SRC_URI_append_libc-musl = "\
>
>  SRC_URI_append = "\
>  file://0001-ppp-fix-in-if.h-includes.patch \
> +file://0001-if_tunnel-remove-include-of-if-ip-in6.h.patch \
>  "
>
>  SRC_URI[md5sum] = "c1af0afbd3df35c1ccdc7a5118cd2d07"
> --
> 2.5.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
>
>


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


Re: [OE-core] [PATCH] makedevs: don't restrict device node paths to 40 characters

2016-10-03 Thread Khem Raj

> On Oct 2, 2016, at 11:41 PM, Andre McCurdy  wrote:
> 
> On Sun, Oct 2, 2016 at 1:37 PM, Khem Raj  wrote:
>> 
>>> On Sep 12, 2016, at 1:14 PM, Andre McCurdy  wrote:
>>> 
>>> 40 character paths work OK for device nodes in /dev but not for
>>> device nodes created in a chroot, LXC container, etc.
>>> 
>>> Since the 'path' array is already a 4k buffer, the sscanf 40
>>> character limit seems to be a typo or historical mis-merge. Update
>>> the sscanf limit and bring the code in sync with the Buildroot
>>> version:
>>> 
>>> https://git.buildroot.net/buildroot/commit/?id=8876b6751e0bc19a3754290061808f0f8420708e
>> 
>> what is upstream worthiness of this patch ? it seems it could be
>> a good change
> 
> Where is the upstream?

mtd-utils, but in this case it seems its a back port so we are fine.

> 
>>> 
>>> Signed-off-by: Andre McCurdy 
>>> ---
>>> meta/recipes-devtools/makedevs/makedevs/makedevs.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/meta/recipes-devtools/makedevs/makedevs/makedevs.c 
>>> b/meta/recipes-devtools/makedevs/makedevs/makedevs.c
>>> index 7471f3f..cba7681 100644
>>> --- a/meta/recipes-devtools/makedevs/makedevs/makedevs.c
>>> +++ b/meta/recipes-devtools/makedevs/makedevs/makedevs.c
>>> @@ -360,7 +360,7 @@ static int interpret_table_entry(char *line)
>>>  unsigned long mode = 0755, uid = 0, gid = 0, major = 0, minor = 0;
>>>  unsigned long start = 0, increment = 1, count = 0;
>>> 
>>> - if (0 > sscanf(line, "%40s %c %lo %40s %40s %lu %lu %lu %lu %lu", 
>>> path,
>>> + if (0 > sscanf(line, "%4095s %c %lo %40s %40s %lu %lu %lu %lu %lu", 
>>> path,
>>>  , , usr_buf, grp_buf, , , ,
>>>  , ))
>>>  {
>>> --
>>> 1.9.1
>>> 
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH V3] utils.bbclass: add function to check for git config user

2016-10-03 Thread Stephano Cetola
If attempting to patch a git repo without a proper git config setup,
an error will occur saying user.name/user.email are needed by git
am/apply. After some code was removed from kernel-yocto, it was
simple enough to reproduce this error by creating a kernel patch and
using a container to build.

This patch abstracts out functionality that existed in buildhistory
for use in other classes. It also adds a call to this functionality
to the kernel-yocto class.

Fixes [YOCTO #10346]

introduced in OE-core revision
0f698dfd1c8bbc0d53ae7977e26685a7a3df52a3

Signed-off-by: Stephano Cetola 
---
 meta/classes/buildhistory.bbclass | 15 ++-
 meta/classes/kernel-yocto.bbclass |  3 +++
 meta/classes/utils.bbclass| 10 ++
 3 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index 6e5de0e..3a5bc2c 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -57,6 +57,9 @@ SSTATEPOSTINSTFUNCS[vardepvalueexclude] .= "| 
buildhistory_emit_pkghistory"
 # class.
 BUILDHISTORY_PRESERVE = "latest latest_srcrev"
 
+PATCH_GIT_USER_EMAIL ?= "buildhistory@oe"
+PATCH_GIT_USER_NAME ?= "OpenEmbedded"
+
 #
 # Write out metadata about this package for comparison when writing future 
packages
 #
@@ -708,15 +711,9 @@ END
git tag -f build-minus-2 build-minus-1 > /dev/null 2>&1 
|| true
git tag -f build-minus-1 > /dev/null 2>&1 || true
fi
-   # If the user hasn't set up their name/email, set some defaults
-   # just for this repo (otherwise the commit will fail with older
-   # versions of git)
-   if ! git config user.email > /dev/null ; then
-   git config --local user.email "buildhistory@${DISTRO}"
-   fi
-   if ! git config user.name > /dev/null ; then
-   git config --local user.name "buildhistory"
-   fi
+
+   check_git_config
+
# Check if there are new/changed files to commit (other than 
metadata-revs)
repostatus=`git status --porcelain | grep -v " metadata-revs$"`
HOSTNAME=`hostname 2>/dev/null || echo unknown`
diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 53659f2..6160a29 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -1,5 +1,7 @@
 # remove tasks that modify the source tree in case externalsrc is inherited
 SRCTREECOVEREDTASKS += "do_kernel_configme do_validate_branches 
do_kernel_configcheck do_kernel_checkout do_fetch do_unpack do_patch"
+PATCH_GIT_USER_EMAIL ?= "kernel-yocto@oe"
+PATCH_GIT_USER_NAME ?= "OpenEmbedded"
 
 # returns local (absolute) path names for all valid patches in the
 # src_uri
@@ -159,6 +161,7 @@ do_kernel_metadata() {
 do_patch() {
cd ${S}
 
+   check_git_config
meta_dir=$(kgit --meta)
(cd ${meta_dir}; ln -sf patch.queue series)
if [ -f "${meta_dir}/series" ]; then
diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
index 800b565..dbb5e4c 100644
--- a/meta/classes/utils.bbclass
+++ b/meta/classes/utils.bbclass
@@ -419,3 +419,13 @@ def all_multilib_tune_list(vars, d):
 values[v].append(localdata.getVar(v, True))
 values['ml'].append(item)
 return values
+
+# If the user hasn't set up their name/email, set some defaults
+check_git_config() {
+   if ! git config user.email > /dev/null ; then
+   git config --local user.email "${PATCH_GIT_USER_EMAIL}"
+   fi
+   if ! git config user.name > /dev/null ; then
+   git config --local user.name "${PATCH_GIT_USER_NAME}"
+   fi
+}
-- 
2.10.0

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


[OE-core] [PATCH V3] add function to check for git config user

2016-10-03 Thread Stephano Cetola
Chnages since V2:
moved functionality from sanity to utils
utilize existing name / email variables 

Stephano Cetola (1):
  utils.bbclass: add function to check for git config user

 meta/classes/buildhistory.bbclass | 15 ++-
 meta/classes/kernel-yocto.bbclass |  3 +++
 meta/classes/utils.bbclass| 10 ++
 3 files changed, 19 insertions(+), 9 deletions(-)

-- 
2.10.0

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


Re: [OE-core] [PATCH v2 1/2] classes/uboot-extlinux-config: Add class

2016-10-03 Thread Ulf Magnusson
On Tue, Oct 4, 2016 at 12:08 AM, Ulf Magnusson  wrote:
> Hello,
>
> On Mon, Oct 3, 2016 at 2:17 PM, Fabio Berton
>  wrote:
>> This class allow the extlinux.conf generation for U-Boot use.
>> The U-Boot support for it is given to allow the Generic Distribution
>> Configuration specification use by OpenEmbedded-based products.
>>
>> This class can be inherited by u-boot recipes to create extlinux.conf
>> and boot using menu options.
>>
>> U-boot with extlinux support is machine dependent, so to use this class
>> you need to set UBOOT_EXTLINUX to 1 in machine configuration file and
>> also set root= kernel cmdline UBOOT_EXTLINUX_ROOT. This variable is used
>> to pass root kernel cmdline, e.g:
>>
>> UBOOT_EXTLINUX_ROOT = "root=/dev/mmcblk2p2"
>>
>> Signed-off-by: Fabio Berton 
>> Signed-off-by: Otavio Salvador 
>> ---
>>  meta/classes/uboot-extlinux-config.bbclass | 130 
>> +
>>  1 file changed, 130 insertions(+)
>>  create mode 100644 meta/classes/uboot-extlinux-config.bbclass
>>
>> diff --git a/meta/classes/uboot-extlinux-config.bbclass 
>> b/meta/classes/uboot-extlinux-config.bbclass
>> new file mode 100644
>> index 000..a4dc0c0
>> --- /dev/null
>> +++ b/meta/classes/uboot-extlinux-config.bbclass
>> @@ -0,0 +1,130 @@
>> +# uboot-extlinux-config.bbclass
>> +#
>> +# This class allow the extlinux.conf generation for U-Boot use. The
>> +# U-Boot support for it is given to allow the Generic Distribution
>> +# Configuration specification use by OpenEmbedded-based products.
>> +#
>> +# External variables:
>> +#
>> +# UBOOT_EXTLINUX_CONFIG- Configuration file default set to 
>> source dir.
>> +# UBOOT_EXTLINUX_CONSOLE   - Set to "console=ttyX" to change kernel 
>> boot
>> +#default console.
>> +# UBOOT_EXTLINUX_LABELS- A list of targets for the automatic 
>> config.
>> +# UBOOT_EXTLINUX_KERNEL_ARGS   - Add additional kernel arguments.
>> +# UBOOT_EXTLINUX_KERNEL_IMAGE  - Kernel image name.
>> +# UBOOT_EXTLINUX_FDTDIR- Device tree directory.
>> +# UBOOT_EXTLINUX_INITRD- Indicates a list of filesystem images 
>> to
>> +#concatenate and use as an initrd 
>> (optional).
>> +# UBOOT_EXTLINUX_MENU_DESCRIPTION  - Name to use as description.
>> +# UBOOT_EXTLINUX_ROOT  - Root kernel cmdline.
>> +#
>> +# If there's only one label system will boot automatically and menu won't be
>> +# created. If you want to use more than one labels, e.g linux and alternate,
>> +# use overrides to set menu description, console and others variables.
>> +#
>> +# Ex:
>> +#
>> +# UBOOT_EXTLINUX_LABELS ??= "default fallback"
>> +#
>> +# UBOOT_EXTLINUX_KERNEL_IMAGE_default ??= "../zImage"
>> +# UBOOT_EXTLINUX_MENU_DESCRIPTION_default ??= "Linux Default"
>> +#
>> +# UBOOT_EXTLINUX_KERNEL_IMAGE_fallback ??= "../zImage-fallback"
>> +# UBOOT_EXTLINUX_MENU_DESCRIPTION_fallback ??= "Linux Fallback"
>> +#
>> +# Results:
>> +#
>> +# menu title Select the boot mode
>> +# LABEL Linux Default
>> +#   KERNEL ../zImage
>> +#   FDTDIR ../
>> +#   APPEND root=/dev/mmcblk2p2 rootwait rw console=${console}
>> +# LABEL Linux Fallback
>> +#   KERNEL ../zImage-fallback
>> +#   FDTDIR ../
>> +#   APPEND root=/dev/mmcblk2p2 rootwait rw console=${console}
>> +#
>> +# Copyright (C) 2016, O.S. Systems Software LTDA.  All Rights Reserved
>> +# Released under the MIT license (see packages/COPYING)
>> +#
>> +# The kernel has an internal default console, which you can override with
>> +# a console=...some_tty...
>> +UBOOT_EXTLINUX_CONSOLE ??= "console=${console}"
>> +UBOOT_EXTLINUX_CONFIG ??= "${S}/extlinux.conf"
>> +UBOOT_EXTLINUX_LABELS ??= "linux"
>> +UBOOT_EXTLINUX_FDTDIR ??= "../"
>> +UBOOT_EXTLINUX_KERNEL_IMAGE ??= "../${KERNEL_IMAGETYPE}"
>> +UBOOT_EXTLINUX_KERNEL_ARGS ??= "rootwait rw"
>> +UBOOT_EXTLINUX_MENU_DESCRIPTION_linux ??= "${DISTRO_NAME}"
>> +
>> +python create_extlinux_config() {
>> +if d.getVar("UBOOT_EXTLINUX", False) == "1":
>
> Is there a reason why False is passed here? Passing True would make
> the code more general, as the value of the flag could come from
> another variable, e.g.
>
>   UBOOT_EXTLINUX = "${SOME_FLAG_HELPER_VAR}"
>
> , or from a function, e.g.
>
>   UBOOT_EXTLINUX = "${@needs_uboot_extlinux()}"
>
> As a minor style note, the indentation of the function could be
> decreased by doing
>
>   if d.getVar("UBOOT_EXTLINUX", True) != "1":
>   return
>   ...
>
> That might avoid excessive indentation if you use 'with' as mentioned below.
>
>> +workdir = d.getVar('WORKDIR', True)
>> +if not workdir:
>> +bb.error("WORKDIR not defined, unable to package")
>> +return
>
> Could be simplified to the following to make it clear that 'workdir'
> is never referenced afterwards (I know there's some existing code like
> the 

Re: [OE-core] [PATCH V2] sanity: add function to check for git config user

2016-10-03 Thread Richard Purdie
On Sun, 2016-10-02 at 17:43 -0700, Stephano Cetola wrote:
> If attempting to patch a git repo without a proper git config setup,
> an error will occur saying user.name/user.email are needed by git
> am/apply. After some code was removed from kernel-yocto, it was
> simple enough to reproduce this error by creating a kernel patch and
> using a container to build.
> 
> This patch abstracts out functionality that existed in buildhistory
> for use in other classes. It also adds a call to this functionality
> to the kernel-yocto class.
> 
> Fixes [YOCTO #10346]
> 
> introduced in
> OE-core revision 0f698dfd1c8bbc0d53ae7977e26685a7a3df52a3
> 
> Signed-off-by: Stephano Cetola 
> ---
>  meta/classes/buildhistory.bbclass | 13 -
>  meta/classes/kernel-yocto.bbclass |  2 ++
>  meta/classes/sanity.bbclass   | 15 +++
>  3 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/meta/classes/buildhistory.bbclass
> b/meta/classes/buildhistory.bbclass
> index 6e5de0e..ed79029 100644
> --- a/meta/classes/buildhistory.bbclass
> +++ b/meta/classes/buildhistory.bbclass
> @@ -688,6 +688,7 @@ END
>   rm $commitmsgfile
>  }
>  
> +inherit sanity
>  buildhistory_commit() {
>   if [ ! -d ${BUILDHISTORY_DIR} ] ; then
>   # Code above that creates this dir never executed,
> so there can't be anything to commit
> @@ -708,15 +709,9 @@ END
>   git tag -f build-minus-2 build-minus-1 >
> /dev/null 2>&1 || true
>   git tag -f build-minus-1 > /dev/null 2>&1 ||
> true
>   fi
> - # If the user hasn't set up their name/email, set
> some defaults
> - # just for this repo (otherwise the commit will fail
> with older
> - # versions of git)
> - if ! git config user.email > /dev/null ; then
> - git config --local user.email
> "buildhistory@${DISTRO}"
> - fi
> - if ! git config user.name > /dev/null ; then
> - git config --local user.name "buildhistory"
> - fi
> +
> + check_git_config "buildhistory"
> +
>   # Check if there are new/changed files to commit
> (other than metadata-revs)
>   repostatus=`git status --porcelain | grep -v "
> metadata-revs$"`
>   HOSTNAME=`hostname 2>/dev/null || echo unknown`
> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-
> yocto.bbclass
> index 53659f2..035edeb 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -156,9 +156,11 @@ do_kernel_metadata() {
>   fi
>  }
>  
> +inherit sanity
>  do_patch() {
>   cd ${S}
>  
> + check_git_config "kernel-yocto"
>   meta_dir=$(kgit --meta)
>   (cd ${meta_dir}; ln -sf patch.queue series)
>   if [ -f "${meta_dir}/series" ]; then
> diff --git a/meta/classes/sanity.bbclass
> b/meta/classes/sanity.bbclass
> index 7682ffb..40033ab 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -1023,3 +1023,18 @@ python check_sanity_eventhandler() {
>  
>  return
>  }
> +
> +# If the user hasn't set up their name/email, set some defaults
> +check_git_config() {
> + if [ -z "$1" ]; then
> + name="OE"
> + else
> + name="$1"
> + fi
> + if ! git config user.email > /dev/null ; then
> + git config --local user.email "${name}@${DISTRO}"
> + fi
> + if ! git config user.name > /dev/null ; then
> + git config --local user.name "${name}"
> + fi
> +}

I worry you're causing a load of the classes to end up cross linked
here which is bad from a usability standpoint. Nobody can easily
disable the sanity checks after this patch.

If we're keeping this as a shell function this function would probably
go to utils.bbclass. Adding something to lib/oe is probably ultimately
the way to go but I appreciate its harder to write the above in a
python lib, so perhaps utils.bbclass is good enough for now? We can
assume utils is inherited globally.

Cheers,

Richard


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


Re: [OE-core] [PATCH 0/7] linux-yocto: consolidated (and hopefully final) pull request

2016-10-03 Thread Richard Purdie
On Mon, 2016-10-03 at 12:55 -0400, Bruce Ashfield wrote:
> 
> 
> On Mon, Oct 3, 2016 at 12:07 PM, Bruce Ashfield  .com> wrote:
> > 
> > 
> > On Mon, Oct 3, 2016 at 12:03 PM, Burton, Ross  > m> wrote:
> > > 
> > > On 3 October 2016 at 16:57, Bruce Ashfield  > > com> wrote:
> > > > Out of curiosity, what image type is this ?  built core-image-
> > > > sato, kernel-dev for
> > > > x86-64 and they all worked.
> > > > 
> > > net-tools (via core-image-full-cmdline -c populate_sdk) for
> > > intel-corei7-64.
> > > 
> > 
> > ok. I've reproduced the failure by building just that package, with
> > any luck I can spin
> > something for it in the next few minutes and then launch a full
> > build of that image.
> > 
> > 
> patch sent. I can now build net-tools, and I launched a full build of
> core-image-full-cmdline.
> The clock is ticking on me now .. but I'll be around for another hour
> to monitor things.=

I've been running builds and it seems things are looking much greener
now FWIW!

Cheers,

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


Re: [OE-core] [PATCH v2 1/2] classes/uboot-extlinux-config: Add class

2016-10-03 Thread Ulf Magnusson
Hello,

On Mon, Oct 3, 2016 at 2:17 PM, Fabio Berton
 wrote:
> This class allow the extlinux.conf generation for U-Boot use.
> The U-Boot support for it is given to allow the Generic Distribution
> Configuration specification use by OpenEmbedded-based products.
>
> This class can be inherited by u-boot recipes to create extlinux.conf
> and boot using menu options.
>
> U-boot with extlinux support is machine dependent, so to use this class
> you need to set UBOOT_EXTLINUX to 1 in machine configuration file and
> also set root= kernel cmdline UBOOT_EXTLINUX_ROOT. This variable is used
> to pass root kernel cmdline, e.g:
>
> UBOOT_EXTLINUX_ROOT = "root=/dev/mmcblk2p2"
>
> Signed-off-by: Fabio Berton 
> Signed-off-by: Otavio Salvador 
> ---
>  meta/classes/uboot-extlinux-config.bbclass | 130 
> +
>  1 file changed, 130 insertions(+)
>  create mode 100644 meta/classes/uboot-extlinux-config.bbclass
>
> diff --git a/meta/classes/uboot-extlinux-config.bbclass 
> b/meta/classes/uboot-extlinux-config.bbclass
> new file mode 100644
> index 000..a4dc0c0
> --- /dev/null
> +++ b/meta/classes/uboot-extlinux-config.bbclass
> @@ -0,0 +1,130 @@
> +# uboot-extlinux-config.bbclass
> +#
> +# This class allow the extlinux.conf generation for U-Boot use. The
> +# U-Boot support for it is given to allow the Generic Distribution
> +# Configuration specification use by OpenEmbedded-based products.
> +#
> +# External variables:
> +#
> +# UBOOT_EXTLINUX_CONFIG- Configuration file default set to 
> source dir.
> +# UBOOT_EXTLINUX_CONSOLE   - Set to "console=ttyX" to change kernel 
> boot
> +#default console.
> +# UBOOT_EXTLINUX_LABELS- A list of targets for the automatic 
> config.
> +# UBOOT_EXTLINUX_KERNEL_ARGS   - Add additional kernel arguments.
> +# UBOOT_EXTLINUX_KERNEL_IMAGE  - Kernel image name.
> +# UBOOT_EXTLINUX_FDTDIR- Device tree directory.
> +# UBOOT_EXTLINUX_INITRD- Indicates a list of filesystem images to
> +#concatenate and use as an initrd 
> (optional).
> +# UBOOT_EXTLINUX_MENU_DESCRIPTION  - Name to use as description.
> +# UBOOT_EXTLINUX_ROOT  - Root kernel cmdline.
> +#
> +# If there's only one label system will boot automatically and menu won't be
> +# created. If you want to use more than one labels, e.g linux and alternate,
> +# use overrides to set menu description, console and others variables.
> +#
> +# Ex:
> +#
> +# UBOOT_EXTLINUX_LABELS ??= "default fallback"
> +#
> +# UBOOT_EXTLINUX_KERNEL_IMAGE_default ??= "../zImage"
> +# UBOOT_EXTLINUX_MENU_DESCRIPTION_default ??= "Linux Default"
> +#
> +# UBOOT_EXTLINUX_KERNEL_IMAGE_fallback ??= "../zImage-fallback"
> +# UBOOT_EXTLINUX_MENU_DESCRIPTION_fallback ??= "Linux Fallback"
> +#
> +# Results:
> +#
> +# menu title Select the boot mode
> +# LABEL Linux Default
> +#   KERNEL ../zImage
> +#   FDTDIR ../
> +#   APPEND root=/dev/mmcblk2p2 rootwait rw console=${console}
> +# LABEL Linux Fallback
> +#   KERNEL ../zImage-fallback
> +#   FDTDIR ../
> +#   APPEND root=/dev/mmcblk2p2 rootwait rw console=${console}
> +#
> +# Copyright (C) 2016, O.S. Systems Software LTDA.  All Rights Reserved
> +# Released under the MIT license (see packages/COPYING)
> +#
> +# The kernel has an internal default console, which you can override with
> +# a console=...some_tty...
> +UBOOT_EXTLINUX_CONSOLE ??= "console=${console}"
> +UBOOT_EXTLINUX_CONFIG ??= "${S}/extlinux.conf"
> +UBOOT_EXTLINUX_LABELS ??= "linux"
> +UBOOT_EXTLINUX_FDTDIR ??= "../"
> +UBOOT_EXTLINUX_KERNEL_IMAGE ??= "../${KERNEL_IMAGETYPE}"
> +UBOOT_EXTLINUX_KERNEL_ARGS ??= "rootwait rw"
> +UBOOT_EXTLINUX_MENU_DESCRIPTION_linux ??= "${DISTRO_NAME}"
> +
> +python create_extlinux_config() {
> +if d.getVar("UBOOT_EXTLINUX", False) == "1":

Is there a reason why False is passed here? Passing True would make
the code more general, as the value of the flag could come from
another variable, e.g.

  UBOOT_EXTLINUX = "${SOME_FLAG_HELPER_VAR}"

, or from a function, e.g.

  UBOOT_EXTLINUX = "${@needs_uboot_extlinux()}"

As a minor style note, the indentation of the function could be
decreased by doing

  if d.getVar("UBOOT_EXTLINUX", True) != "1":
  return
  ...

That might avoid excessive indentation if you use 'with' as mentioned below.

> +workdir = d.getVar('WORKDIR', True)
> +if not workdir:
> +bb.error("WORKDIR not defined, unable to package")
> +return

Could be simplified to the following to make it clear that 'workdir'
is never referenced afterwards (I know there's some existing code like
the above though):

  if not d.getVar('WORKDIR', True):
  ...

> +
> +labels = d.getVar('UBOOT_EXTLINUX_LABELS', True)
> +if not labels:
> +bb.fatal(1, "UBOOT_EXTLINUX_LABELS not defined, nothing to 

Re: [OE-core] [PATCH] linux-libc-headers: if_tunnel: remove include of if/ip/in6.h

2016-10-03 Thread Khem Raj
What Repercussion does this have wrt APIs headers for future. Provided this
is a local patch. I think removing header includes like this can cause
issues.

On Oct 3, 2016 9:55 AM, "Bruce Ashfield" 
wrote:

commit 1fe8e0f074c [include/uapi/linux/if_tunnel.h: include linux/if.h,
linux/ip.h and linux/in6.h]
breaks the builds of net-tools.

We remove the new includes until such a time that userspace can adapt to the
new kernel headers.

Signed-off-by: Bruce Ashfield 
---
 ...1-if_tunnel-remove-include-of-if-ip-in6.h.patch | 33
++
 .../linux-libc-headers/linux-libc-headers_4.8.bb   |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-
headers/0001-if_tunnel-remove-include-of-if-ip-in6.h.patch

diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-
headers/0001-if_tunnel-remove-include-of-if-ip-in6.h.patch
b/meta/recipes-kernel/linux-libc-headers/linux-libc-
headers/0001-if_tunnel-remove-include-of-if-ip-in6.h.patch
new file mode 100644
index ..f2011880dccb
--- /dev/null
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-
headers/0001-if_tunnel-remove-include-of-if-ip-in6.h.patch
@@ -0,0 +1,33 @@
+From 017ae5929312685c4c044765445bfd4d2a4abb5c Mon Sep 17 00:00:00 2001
+From: Bruce Ashfield 
+Date: Mon, 3 Oct 2016 12:27:57 -0400
+Subject: [PATCH] if_tunnel: remove include of if/ip/in6.h
+
+commit 1fe8e0f074c [include/uapi/linux/if_tunnel.h: include linux/if.h,
linux/ip.h and linux/in6.h]
+breaks the builds of net-tools.
+
+We remove the new includes until such a time that userspace can adapt to
the
+new kernel headers.
+
+Signed-off-by: Bruce Ashfield 
+---
+ include/uapi/linux/if_tunnel.h | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_
tunnel.h
+index 777b6cd..1046f55 100644
+--- a/include/uapi/linux/if_tunnel.h
 b/include/uapi/linux/if_tunnel.h
+@@ -2,9 +2,6 @@
+ #define _UAPI_IF_TUNNEL_H_
+
+ #include 
+-#include 
+-#include 
+-#include 
+ #include 
+
+
+--
+2.7.4
+
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-
headers_4.8.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-
headers_4.8.bb
index 778f0b6e6443..ee2d8293450e 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb
@@ -10,6 +10,7 @@ SRC_URI_append_libc-musl = "\

 SRC_URI_append = "\
 file://0001-ppp-fix-in-if.h-includes.patch \
+file://0001-if_tunnel-remove-include-of-if-ip-in6.h.patch \
 "

 SRC_URI[md5sum] = "c1af0afbd3df35c1ccdc7a5118cd2d07"
--
2.5.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] db: Remove unneeded PR

2016-10-03 Thread Paul Eggleton
On Mon, 03 Oct 2016 14:30:15 Aníbal Limón wrote:
> On 10/03/2016 02:25 PM, Paul Eggleton wrote:
> > On Mon, 03 Oct 2016 14:17:27 Aníbal Limón wrote:
> >> The PR is not need so remove it after upgrade to 6.0.35.
> >> 
> >> Signed-off-by: Aníbal Limón 
> >> ---
> >> 
> >>  meta/recipes-support/db/db_6.0.35.bb | 2 --
> >>  1 file changed, 2 deletions(-)
> >> 
> >> diff --git a/meta/recipes-support/db/db_6.0.35.bb
> >> b/meta/recipes-support/db/db_6.0.35.bb index 32afbe8..ecb1bee 100644
> >> --- a/meta/recipes-support/db/db_6.0.35.bb
> >> +++ b/meta/recipes-support/db/db_6.0.35.bb
> >> @@ -15,8 +15,6 @@ LICENSE = "AGPL-3.0"
> >> 
> >>  VIRTUAL_NAME ?= "virtual/db"
> >>  RCONFLICTS_${PN} = "db3"
> >> 
> >> -PR = "r1"
> >> -
> >> 
> >>  # Note, when upgraded to 6.1.x, a patch in RPM will need to be removed
> >>  to
> >> 
> >> activate db 6.1 support. SRC_URI =
> >> "http://distfiles.gentoo.org/distfiles/db-${PV}.tar.gz \
> >> file://arm-thumb-mutex_db5.patch \
> > 
> > I think it's too late to do this unfortunately - it needs to be done at
> > the
> > same time as the upgrade.
> 
> I sent a PATCHv3 [1] removing the PR but unfortunately was not integrated.
> 
> [1]
> http://lists.openembedded.org/pipermail/openembedded-core/2016-September/127
> 027.html

Understood - for most other changes we'd want to have a follow-up patch to 
apply what's missing, but for PR it's still too late - the r1 value is already 
merged and packages could have been built from it. Decreasing PR now will make 
the version number go backwards which we want to avoid.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] db: Remove unneeded PR

2016-10-03 Thread Aníbal Limón


On 10/03/2016 02:25 PM, Paul Eggleton wrote:
> On Mon, 03 Oct 2016 14:17:27 Aníbal Limón wrote:
>> The PR is not need so remove it after upgrade to 6.0.35.
>>
>> Signed-off-by: Aníbal Limón 
>> ---
>>  meta/recipes-support/db/db_6.0.35.bb | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/meta/recipes-support/db/db_6.0.35.bb
>> b/meta/recipes-support/db/db_6.0.35.bb index 32afbe8..ecb1bee 100644
>> --- a/meta/recipes-support/db/db_6.0.35.bb
>> +++ b/meta/recipes-support/db/db_6.0.35.bb
>> @@ -15,8 +15,6 @@ LICENSE = "AGPL-3.0"
>>  VIRTUAL_NAME ?= "virtual/db"
>>  RCONFLICTS_${PN} = "db3"
>>
>> -PR = "r1"
>> -
>>  # Note, when upgraded to 6.1.x, a patch in RPM will need to be removed to
>> activate db 6.1 support. SRC_URI =
>> "http://distfiles.gentoo.org/distfiles/db-${PV}.tar.gz \
>> file://arm-thumb-mutex_db5.patch \
> 
> I think it's too late to do this unfortunately - it needs to be done at the 
> same time as the upgrade.

I sent a PATCHv3 [1] removing the PR but unfortunately was not integrated.

[1]
http://lists.openembedded.org/pipermail/openembedded-core/2016-September/127027.html

Cheers,
alimon

> 
> Cheers,
> Paul
> 



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


Re: [OE-core] [PATCH] db: Remove unneeded PR

2016-10-03 Thread Paul Eggleton
On Mon, 03 Oct 2016 14:17:27 Aníbal Limón wrote:
> The PR is not need so remove it after upgrade to 6.0.35.
> 
> Signed-off-by: Aníbal Limón 
> ---
>  meta/recipes-support/db/db_6.0.35.bb | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/meta/recipes-support/db/db_6.0.35.bb
> b/meta/recipes-support/db/db_6.0.35.bb index 32afbe8..ecb1bee 100644
> --- a/meta/recipes-support/db/db_6.0.35.bb
> +++ b/meta/recipes-support/db/db_6.0.35.bb
> @@ -15,8 +15,6 @@ LICENSE = "AGPL-3.0"
>  VIRTUAL_NAME ?= "virtual/db"
>  RCONFLICTS_${PN} = "db3"
> 
> -PR = "r1"
> -
>  # Note, when upgraded to 6.1.x, a patch in RPM will need to be removed to
> activate db 6.1 support. SRC_URI =
> "http://distfiles.gentoo.org/distfiles/db-${PV}.tar.gz \
> file://arm-thumb-mutex_db5.patch \

I think it's too late to do this unfortunately - it needs to be done at the 
same time as the upgrade.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] db: Remove unneeded PR

2016-10-03 Thread Aníbal Limón
The PR is not need so remove it after upgrade to 6.0.35.

Signed-off-by: Aníbal Limón 
---
 meta/recipes-support/db/db_6.0.35.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-support/db/db_6.0.35.bb 
b/meta/recipes-support/db/db_6.0.35.bb
index 32afbe8..ecb1bee 100644
--- a/meta/recipes-support/db/db_6.0.35.bb
+++ b/meta/recipes-support/db/db_6.0.35.bb
@@ -15,8 +15,6 @@ LICENSE = "AGPL-3.0"
 VIRTUAL_NAME ?= "virtual/db"
 RCONFLICTS_${PN} = "db3"
 
-PR = "r1"
-
 # Note, when upgraded to 6.1.x, a patch in RPM will need to be removed to 
activate db 6.1 support.
 SRC_URI = "http://distfiles.gentoo.org/distfiles/db-${PV}.tar.gz \
file://arm-thumb-mutex_db5.patch \
-- 
2.1.4

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


Re: [OE-core] [RFC] iptables: add systemd helper unit to load/restore rules

2016-10-03 Thread Pau Espin Pedrol
Hi,

can you please use ${systemd_system_unitdir} instead of
${systemd_unitdir}/system?
Pau Espin Pedrol


2016-09-08 13:29 GMT+02:00 Jack Mitchell :
> From: Jack Mitchell 
>
> there is currently no way to automatically load iptable rules
> in OE. Add a systemd unit file to automatically load rules on
> network connection. This is cribbed from the way ArchLinux
> handles iptables with some minor modifications for OE. New rules
> can be generated using 'iptables-save > iptables.rules'
> ---
>  .../iptables/iptables/iptables.rules |  0
>  .../iptables/iptables/iptables.service   | 13 +
>  meta/recipes-extended/iptables/iptables_1.6.0.bb | 20 
> ++--
>  3 files changed, 31 insertions(+), 2 deletions(-)
>  create mode 100644 meta/recipes-extended/iptables/iptables/iptables.rules
>  create mode 100644 meta/recipes-extended/iptables/iptables/iptables.service
>
> diff --git a/meta/recipes-extended/iptables/iptables/iptables.rules 
> b/meta/recipes-extended/iptables/iptables/iptables.rules
> new file mode 100644
> index 000..e69de29
> diff --git a/meta/recipes-extended/iptables/iptables/iptables.service 
> b/meta/recipes-extended/iptables/iptables/iptables.service
> new file mode 100644
> index 000..041316e
> --- /dev/null
> +++ b/meta/recipes-extended/iptables/iptables/iptables.service
> @@ -0,0 +1,13 @@
> +[Unit]
> +Description=Packet Filtering Framework
> +Before=network-pre.target
> +Wants=network-pre.target
> +
> +[Service]
> +Type=oneshot
> +ExecStart=@SBINDIR@/iptables-restore /etc/iptables/iptables.rules
> +ExecReload=@SBINDIR@/iptables-restore /etc/iptables/iptables.rules
> +RemainAfterExit=yes
> +
> +[Install]
> +WantedBy=multi-user.target
> diff --git a/meta/recipes-extended/iptables/iptables_1.6.0.bb 
> b/meta/recipes-extended/iptables/iptables_1.6.0.bb
> index fbbe418..65430a1 100644
> --- a/meta/recipes-extended/iptables/iptables_1.6.0.bb
> +++ b/meta/recipes-extended/iptables/iptables_1.6.0.bb
> @@ -22,13 +22,16 @@ SRC_URI = 
> "http://netfilter.org/projects/iptables/files/iptables-${PV}.tar.bz2 \
> file://types.h-add-defines-that-are-required-for-if_packet.patch \
> 
> file://0001-configure-Add-option-to-enable-disable-libnfnetlink.patch \
> 
> file://0002-configure.ac-only-check-conntrack-when-libnfnetlink-enabled.patch 
> \
> -  "
> +   file://iptables.service \
> +   file://iptables.rules \
> +"
> +
>  SRC_URI_append_libc-musl = " file://0001-fix-build-with-musl.patch"
>
>  SRC_URI[md5sum] = "27ba3451cb622467fc9267a176f19a31"
>  SRC_URI[sha256sum] = 
> "4bb72a0a0b18b5a9e79e87631ddc4084528e5df236bc7624472dcaa8480f1c60"
>
> -inherit autotools pkgconfig
> +inherit autotools pkgconfig systemd
>
>  EXTRA_OECONF = "--with-kernel=${STAGING_INCDIR} \
> "
> @@ -48,3 +51,16 @@ do_configure_prepend() {
> # Keep ax_check_linker_flags.m4 which belongs to autoconf-archive.
> rm -f libtool.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4
>  }
> +
> +do_install_append() {
> +
> +install -d ${D}${sysconfdir}/iptables
> +install -m 0644 ${WORKDIR}/iptables.rules ${D}${sysconfdir}/iptables
> +
> +install -d ${D}${systemd_unitdir}/system
> +install -m 0644 ${WORKDIR}/iptables.service 
> ${D}${systemd_unitdir}/system
> +
> +   sed -i -e 's,@SBINDIR@,${sbindir},g' 
> ${D}${systemd_unitdir}/system/iptables.service
> +}
> +
> +SYSTEMD_SERVICE_${PN} = "iptables.service"
> --
> 2.9.3
>
> --
> ___
> 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] Crazy display

2016-10-03 Thread Stephen Arnold
I do mostly remote screen sessions (on gentoo host, sometimes
ubuntu/debian vm) and occasional local terminal (xfce term but remote
could be console only).  The fact that I have not seen this once is
just *weird* (and I'm pretty damn good about hitting the annoying
bits).

Steve

On Mon, Oct 3, 2016 at 10:05 AM, Paul Eggleton
 wrote:
> On Fri, 16 Sep 2016 10:00:12 Paul Eggleton wrote:
>> On Thu, 15 Sep 2016 22:51:47 Richard Purdie wrote:
>> > On Fri, 2016-09-16 at 08:41 +1200, Paul Eggleton wrote:
>> > > On Thu, 15 Sep 2016 22:26:09 Gary Thomas wrote:
>> > > > On 2016-09-15 22:12, Burton, Ross wrote:
>> > > > > On 15 September 2016 at 21:03, Paul Eggleton
>> > >
>> > > 
>> > >
>> > > > wrote:
>> > > > > Are you guys perhaps using the same terminal application?
>> > > > >
>> > > > > Using screen
>> > > > >
>> > > > > / tmux / anything similar? (I'm using screen here and haven't
>> > > > > experienced problems though.)
>> > > > >
>> > > > > I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No
>> > > > > screen/tmux/etc.
>> > > >
>> > > > Pretty much the same for me - just SSH in an xterm window.
>> > >
>> > > Hmm, I'm still no closer then.
>> > >
>> > > Does it just start happening at some point in the middle of a build?
>> > > Or right
>> > > from the start?
>> >
>> > Seems to happen at various points during the build. Looks like bad
>> > timing of console updates so can happen at any point, I'd see evidence
>> > its happened multiple times in a given build.
>>
>> This is bizarre. Clearly something is different between your systems and
>> mine :/
>
> I just wanted to check particularly with Gary and Ross - since the following
> pseudo fix went in, are you still seeing this problem?
>
>  
> http://cgit.openembedded.org/openembedded-core/commit/?id=efd0b0f604f9f498b9c20bc9a25708c493aa4f4a
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> ___
> 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] systemtap: add dependency on boost

2016-10-03 Thread Martin Jansa
* otherwise the build may fail with:
| ERROR: oe_runmake failed
| In file included from ../../git/staprun/../util.h:44:0,
|  from ../../git/staprun/../util.cxx:17:
| ../../git/staprun/../stringtable.h:17:29: fatal error: boost/version.hpp: No 
such file or directory
|  #include 
|  ^
| compilation terminated.
| In file included from ../../git/staprun/../util.h:44:0,
|  from ../../git/staprun/../privilege.cxx:23:
| ../../git/staprun/../stringtable.h:17:29: fatal error: boost/version.hpp: No 
such file or directory
|  #include 
|  ^
| compilation terminated.
| rm -f libstrfloctime.a

Signed-off-by: Martin Jansa 
---
 meta/recipes-kernel/systemtap/systemtap_git.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb 
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index da30fa5..15f0d4e 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.bb
+++ b/meta/recipes-kernel/systemtap/systemtap_git.bb
@@ -2,9 +2,9 @@ SUMMARY = "Script-directed dynamic tracing and performance 
analysis tool for Lin
 
 require systemtap_git.inc
 
-DEPENDS = "elfutils sqlite3 systemtap-native ncurses json-c"
-DEPENDS_class-native = "elfutils-native sqlite3-native gettext-native"
-DEPENDS_class-nativesdk = "nativesdk-elfutils nativesdk-sqlite3 
nativesdk-gettext"
+DEPENDS = "elfutils sqlite3 systemtap-native ncurses json-c boost"
+DEPENDS_class-native = "elfutils-native sqlite3-native gettext-native 
boost-native"
+DEPENDS_class-nativesdk = "nativesdk-elfutils nativesdk-sqlite3 
nativesdk-gettext nativesdk-boost"
 
 RDEPENDS_${PN} += "python3-core bash"
 
-- 
2.10.0

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


Re: [OE-core] Crazy display

2016-10-03 Thread Paul Eggleton
On Fri, 16 Sep 2016 10:00:12 Paul Eggleton wrote:
> On Thu, 15 Sep 2016 22:51:47 Richard Purdie wrote:
> > On Fri, 2016-09-16 at 08:41 +1200, Paul Eggleton wrote:
> > > On Thu, 15 Sep 2016 22:26:09 Gary Thomas wrote:
> > > > On 2016-09-15 22:12, Burton, Ross wrote:
> > > > > On 15 September 2016 at 21:03, Paul Eggleton
> > > 
> > > 
> > > 
> > > > wrote:
> > > > > Are you guys perhaps using the same terminal application?
> > > > > 
> > > > > Using screen
> > > > > 
> > > > > / tmux / anything similar? (I'm using screen here and haven't
> > > > > experienced problems though.)
> > > > > 
> > > > > I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No
> > > > > screen/tmux/etc.
> > > > 
> > > > Pretty much the same for me - just SSH in an xterm window.
> > > 
> > > Hmm, I'm still no closer then.
> > > 
> > > Does it just start happening at some point in the middle of a build?
> > > Or right
> > > from the start?
> > 
> > Seems to happen at various points during the build. Looks like bad
> > timing of console updates so can happen at any point, I'd see evidence
> > its happened multiple times in a given build.
> 
> This is bizarre. Clearly something is different between your systems and
> mine :/

I just wanted to check particularly with Gary and Ross - since the following
pseudo fix went in, are you still seeing this problem?

 
http://cgit.openembedded.org/openembedded-core/commit/?id=efd0b0f604f9f498b9c20bc9a25708c493aa4f4a

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 0/7] linux-yocto: consolidated (and hopefully final) pull request

2016-10-03 Thread Bruce Ashfield
On Mon, Oct 3, 2016 at 12:07 PM, Bruce Ashfield 
wrote:

>
>
> On Mon, Oct 3, 2016 at 12:03 PM, Burton, Ross 
> wrote:
>
>>
>> On 3 October 2016 at 16:57, Bruce Ashfield 
>> wrote:
>>
>>> Out of curiosity, what image type is this ?  built core-image-sato,
>>> kernel-dev for
>>> x86-64 and they all worked.
>>>
>>
>> net-tools (via core-image-full-cmdline -c populate_sdk) for
>> intel-corei7-64.
>>
>
>
> ok. I've reproduced the failure by building just that package, with any
> luck I can spin
> something for it in the next few minutes and then launch a full build of
> that image.
>
>
patch sent. I can now build net-tools, and I launched a full build of
core-image-full-cmdline.
The clock is ticking on me now .. but I'll be around for another hour to
monitor things.=

Bruce


> Bruce
>
>
>>
>> Ross
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
>



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


[OE-core] [PATCH] linux-libc-headers: if_tunnel: remove include of if/ip/in6.h

2016-10-03 Thread Bruce Ashfield
commit 1fe8e0f074c [include/uapi/linux/if_tunnel.h: include linux/if.h, 
linux/ip.h and linux/in6.h]
breaks the builds of net-tools.

We remove the new includes until such a time that userspace can adapt to the
new kernel headers.

Signed-off-by: Bruce Ashfield 
---
 ...1-if_tunnel-remove-include-of-if-ip-in6.h.patch | 33 ++
 .../linux-libc-headers/linux-libc-headers_4.8.bb   |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-if_tunnel-remove-include-of-if-ip-in6.h.patch

diff --git 
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-if_tunnel-remove-include-of-if-ip-in6.h.patch
 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-if_tunnel-remove-include-of-if-ip-in6.h.patch
new file mode 100644
index ..f2011880dccb
--- /dev/null
+++ 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-if_tunnel-remove-include-of-if-ip-in6.h.patch
@@ -0,0 +1,33 @@
+From 017ae5929312685c4c044765445bfd4d2a4abb5c Mon Sep 17 00:00:00 2001
+From: Bruce Ashfield 
+Date: Mon, 3 Oct 2016 12:27:57 -0400
+Subject: [PATCH] if_tunnel: remove include of if/ip/in6.h
+
+commit 1fe8e0f074c [include/uapi/linux/if_tunnel.h: include linux/if.h, 
linux/ip.h and linux/in6.h]
+breaks the builds of net-tools.
+
+We remove the new includes until such a time that userspace can adapt to the
+new kernel headers.
+
+Signed-off-by: Bruce Ashfield 
+---
+ include/uapi/linux/if_tunnel.h | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
+index 777b6cd..1046f55 100644
+--- a/include/uapi/linux/if_tunnel.h
 b/include/uapi/linux/if_tunnel.h
+@@ -2,9 +2,6 @@
+ #define _UAPI_IF_TUNNEL_H_
+ 
+ #include 
+-#include 
+-#include 
+-#include 
+ #include 
+ 
+ 
+-- 
+2.7.4
+
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb
index 778f0b6e6443..ee2d8293450e 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.8.bb
@@ -10,6 +10,7 @@ SRC_URI_append_libc-musl = "\
 
 SRC_URI_append = "\
 file://0001-ppp-fix-in-if.h-includes.patch \
+file://0001-if_tunnel-remove-include-of-if-ip-in6.h.patch \
 "
 
 SRC_URI[md5sum] = "c1af0afbd3df35c1ccdc7a5118cd2d07"
-- 
2.5.0

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


Re: [OE-core] [PATCH 4/4] binutils: apply RPATH fixes from our libtool patches

2016-10-03 Thread Khem Raj
This looks fine

On Oct 3, 2016 7:17 AM, "Ross Burton"  wrote:

> We don't autoreconf/libtoolize binutils as it has very strict
> requirements, so
> extend our patching of the stock libtool to include two fixes to RPATH
> behaviour, as part of the solution to ensure that native binaries don't
> have
> RPATHs pointing at the host system's /usr/lib.
>
> This generally doesn't cause a problem but it can cause some binaries
> (such as
> ar) to abort on startup:
>
> ./x86_64-pokysdk-linux-ar: relocation error: /usr/lib/libc.so.6: symbol
> _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2
> with
> link time reference
>
> The situation here is that ar is built and as it links to the host
> libc/loader
> has an RPATH for /usr/lib.  If tmp is wiped and then binutils is installed
> from
> sstate relocation occurs and the loader changed to the sysroot, but there
> remains a RPATH for /usr/lib.  This means that the sysroot loader is used
> with
> the host libc, which can be incompatible.  By telling libtool that the host
> library paths are in the default search path, and ensuring that all default
> search paths are not added as RPATHs by libtool, the result is a binary
> that
> links to what it should be linking to and nothing else.
>
> [ YOCTO #9287 ]
>
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-devtools/binutils/binutils-2.27.inc   |   1 +
>  .../binutils/0014-libtool-remove-rpath.patch   | 100
> +
>  2 files changed, 101 insertions(+)
>  create mode 100644 meta/recipes-devtools/binutils/binutils/0014-
> libtool-remove-rpath.patch
>
> diff --git a/meta/recipes-devtools/binutils/binutils-2.27.inc
> b/meta/recipes-devtools/binutils/binutils-2.27.inc
> index 9cc57fc..03b7bed 100644
> --- a/meta/recipes-devtools/binutils/binutils-2.27.inc
> +++ b/meta/recipes-devtools/binutils/binutils-2.27.inc
> @@ -33,6 +33,7 @@ SRC_URI = "\
>   file://0011-Change-default-emulation-for-mips64-linux.patch \
>   file://0012-Add-support-for-Netlogic-XLP.patch \
>   file://0013-fix-the-incorrect-assembling-for-ppc-wait-mnemonic.patch
> \
> + file://0014-libtool-remove-rpath.patch \
>  "
>  S  = "${WORKDIR}/git"
>
> diff --git 
> a/meta/recipes-devtools/binutils/binutils/0014-libtool-remove-rpath.patch
> b/meta/recipes-devtools/binutils/binutils/0014-libtool-remove-rpath.patch
> new file mode 100644
> index 000..d56948f
> --- /dev/null
> +++ b/meta/recipes-devtools/binutils/binutils/0014-
> libtool-remove-rpath.patch
> @@ -0,0 +1,100 @@
> +Apply these patches from our libtool patches as not only are redundant
> RPATHs a
> +waste of space but they can cause incorrect linking when native packages
> are
> +restored from sstate.
> +
> +fix-rpath.patch:
> +We don't want to add RPATHS which match default linker
> +search paths, they're a waste of space. This patch
> +filters libtools list and removes the ones we don't need.
> +
> +norm-rpath.patch:
> +Libtool may be passed link paths of the form "/usr/lib/../lib", which
> +fool its detection code into thinking it should be included as an
> +RPATH in the generated binary.  Normalize before comparision.
> +
> +Upstream-Status: Inappropriate
> +Signed-off-by: Ross Burton 
> +
> +diff --git a/ltmain.sh b/ltmain.sh
> +index 683317c..860a16a 100644
> +--- a/ltmain.sh
>  b/ltmain.sh
> +@@ -8053,8 +8053,14 @@ EOF
> + esac
> +   fi
> + else
> +-  eval flag=\"$hardcode_libdir_flag_spec\"
> +-  func_append dep_rpath " $flag"
> ++# We only want to hardcode in an rpath if it isn't in the
> ++# default dlsearch path.
> ++  case " $sys_lib_dlsearch_path " in
> ++  *" $libdir "*) ;;
> ++  *) eval flag=\"$hardcode_libdir_flag_spec\"
> ++   func_append dep_rpath " $flag"
> ++   ;;
> ++  esac
> + fi
> +   elif test -n "$runpath_var"; then
> + case "$perm_rpath " in
> +@@ -8790,8 +8796,14 @@ EOF
> + esac
> +   fi
> + else
> +-  eval flag=\"$hardcode_libdir_flag_spec\"
> +-  func_append rpath " $flag"
> ++# We only want to hardcode in an rpath if it isn't in the
> ++# default dlsearch path.
> ++  case " $sys_lib_dlsearch_path " in
> ++  *" $libdir "*) ;;
> ++  *) eval flag=\"$hardcode_libdir_flag_spec\"
> ++   rpath+=" $flag"
> ++   ;;
> ++  esac
> + fi
> +   elif test -n "$runpath_var"; then
> + case "$perm_rpath " in
> +@@ -8841,8 +8853,14 @@ EOF
> + esac
> +   fi
> + else
> +-  eval flag=\"$hardcode_libdir_flag_spec\"
> +-  func_append rpath " $flag"
> ++# We only want to hardcode in an rpath if it isn't in the
> ++# default dlsearch path.
> ++  

Re: [OE-core] [PATCH 3/4] binutils: fix typo in libtool patch

2016-10-03 Thread Khem Raj
Good catch

On Oct 3, 2016 7:17 AM, "Ross Burton"  wrote:

> There was a clear typo in a function name, correct it.
>
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-devtools/binutils/binutils/0006-Use-libtool-2.4.patch | 3
> +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git 
> a/meta/recipes-devtools/binutils/binutils/0006-Use-libtool-2.4.patch
> b/meta/recipes-devtools/binutils/binutils/0006-Use-libtool-2.4.patch
> index f2411c4..f0fdf46 100644
> --- a/meta/recipes-devtools/binutils/binutils/0006-Use-libtool-2.4.patch
> +++ b/meta/recipes-devtools/binutils/binutils/0006-Use-libtool-2.4.patch
> @@ -16352,7 +16352,7 @@ index 9503ec8..70e856e 100644
>   case "$perm_rpath " in
>   *" $libdir "*) ;;
>  -*) perm_rpath="$perm_rpath $libdir" ;;
> -+*) func_apped perm_rpath " $libdir" ;;
> ++*) func_append perm_rpath " $libdir" ;;
>   esac
> fi
>   done
> @@ -21175,4 +21175,3 @@ index bba9fd2..25a2dae 100755
>
>  --
>  2.9.0
> -
> --
> 2.8.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 0/7] linux-yocto: consolidated (and hopefully final) pull request

2016-10-03 Thread Burton, Ross
On 3 October 2016 at 16:57, Bruce Ashfield  wrote:

> Out of curiosity, what image type is this ?  built core-image-sato,
> kernel-dev for
> x86-64 and they all worked.
>

net-tools (via core-image-full-cmdline -c populate_sdk) for intel-corei7-64.

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


Re: [OE-core] [PATCH V2] sanity: add function to check for git config user

2016-10-03 Thread Stephano Cetola
On 10/03, Burton, Ross wrote:
> On 3 October 2016 at 01:43, Stephano Cetola  > wrote:
> 
> > +# If the user hasn't set up their name/email, set some defaults
> > +check_git_config() {
> > +   if [ -z "$1" ]; then
> > +   name="OE"
> > +   else
> > +   name="$1"
> > +   fi
> > +   if ! git config user.email > /dev/null ; then
> > +   git config --local user.email "${name}@${DISTRO}"
> > +   fi
> > +   if ! git config user.name > /dev/null ; then
> > +   git config --local user.name "${name}"
> > +   fi
> > +}
> >
> 
> Instead of embedding this into sanity.bbclass, could it just go into
> meta/lib/oe/ somewhere?
> 
> Ross


Yeah, I saw /meta/lib/oe/patch when Paul mentioned it. It looks like
things should be moving in this direction log-term anyhow. I could
move this to patch.py for now, and then submit a bug to move
functionality as well, if that's the direction we'd want to go.

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


Re: [OE-core] [PATCH 0/7] linux-yocto: consolidated (and hopefully final) pull request

2016-10-03 Thread Bruce Ashfield
On Mon, Oct 3, 2016 at 12:03 PM, Burton, Ross  wrote:

>
> On 3 October 2016 at 16:57, Bruce Ashfield 
> wrote:
>
>> Out of curiosity, what image type is this ?  built core-image-sato,
>> kernel-dev for
>> x86-64 and they all worked.
>>
>
> net-tools (via core-image-full-cmdline -c populate_sdk) for
> intel-corei7-64.
>


ok. I've reproduced the failure by building just that package, with any
luck I can spin
something for it in the next few minutes and then launch a full build of
that image.

Bruce


>
> Ross
>



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


Re: [OE-core] [PATCH 0/7] linux-yocto: consolidated (and hopefully final) pull request

2016-10-03 Thread Bruce Ashfield
On Mon, Oct 3, 2016 at 11:57 AM, Bruce Ashfield 
wrote:

>
>
> On Mon, Oct 3, 2016 at 11:51 AM, Bruce Ashfield <
> bruce.ashfi...@windriver.com> wrote:
>
>> On 2016-10-03 11:45 AM, Burton, Ross wrote:
>>
>>>
>>> On 3 October 2016 at 06:54, Bruce Ashfield >> > wrote:
>>>
>>> The big thing to note about this update .. is that the libc-headers
>>> bump
>>> to the 4.8 final tarball picked up some uapi headers that broke the
>>> build
>>> of ppp. I never would have thought it was possible, but it happened.
>>>
>>>
>>> | In file included from
>>> /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/inc
>>> lude/linux/if_tunnel.h:6:0,
>>> |  from iptunnel.c:39:
>>> |
>>> /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/inc
>>> lude/linux/ip.h:85:8:
>>> error: redefinition of 'struct iphdr'
>>> |  struct iphdr {
>>> | ^
>>> | In file included from iptunnel.c:29:0:
>>> |
>>> /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/inc
>>> lude/netinet/ip.h:44:8:
>>> note: originally defined here
>>> |  struct iphdr
>>> | ^
>>> | : recipe for target 'iptunnel.o' failed
>>> | make: *** [iptunnel.o] Error 1
>>> | ERROR: Function failed: do_compile (log file is located at
>>> /data/poky-master/tmp-glibc/work/corei7-64-poky-linux/net-to
>>> ols/1.60-26-r0/temp/log.do_compile.27643)
>>>
>>> Looks like net-tools is broken by something else too.
>>>
>>
>> I'm out of the office in about one hour. So someone else is
>> going to have to pick up the libc-headers fix.
>>
>
>
> Switching to my gmail, so I can follow along.
>
> I do have about a half hour now, I'll check the net uapi code in the
> kernel and see
> if there's another fixup I can do.
>
> These errors have been lurking for about the last year, the answer from
> the kernel
> folks is typically "change the order of your includes".
>
> So there are two routes to fix it. See if there's a newer userspace with
> the includes
> changed, or do what I did, take the change out of libc-headers.
>

Yep. Same criminals, it is very likely this. I started a build, if it
breaks, I'll test a removal
of this:

---

commit 1fe8e0f074c77aa41aaa579345a9e675acbebfa9

Author: Mikko Rapeli 

Date:   Mon Aug 22 20:32:39 2016 +0200


include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and
linux/in6.h



Fixes userspace compilation errors like:



error: field <80><98>iph<80><99> has incomplete type

error: field <80><98>prefix<80><99> has incomplete type



Signed-off-by: Mikko Rapeli 

Signed-off-by: David S. Miller 


:100644 100644 1046f5515174... 777b6cdb1b7b... M
include/uapi/linux/if_tunnel.h




>
> I'll check to see if I can do the latter here.
>
> Out of curiosity, what image type is this ?  built core-image-sato,
> kernel-dev for
> x86-64 and they all worked.
>
> Bruce
>
>
>>
>> Cheers,
>>
>> Bruce
>>
>>
>>> Ross
>>>
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
>



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


Re: [OE-core] [PATCH 0/7] linux-yocto: consolidated (and hopefully final) pull request

2016-10-03 Thread Bruce Ashfield
On Mon, Oct 3, 2016 at 11:51 AM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> On 2016-10-03 11:45 AM, Burton, Ross wrote:
>
>>
>> On 3 October 2016 at 06:54, Bruce Ashfield > > wrote:
>>
>> The big thing to note about this update .. is that the libc-headers
>> bump
>> to the 4.8 final tarball picked up some uapi headers that broke the
>> build
>> of ppp. I never would have thought it was possible, but it happened.
>>
>>
>> | In file included from
>> /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/inc
>> lude/linux/if_tunnel.h:6:0,
>> |  from iptunnel.c:39:
>> |
>> /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/inc
>> lude/linux/ip.h:85:8:
>> error: redefinition of 'struct iphdr'
>> |  struct iphdr {
>> | ^
>> | In file included from iptunnel.c:29:0:
>> |
>> /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/inc
>> lude/netinet/ip.h:44:8:
>> note: originally defined here
>> |  struct iphdr
>> | ^
>> | : recipe for target 'iptunnel.o' failed
>> | make: *** [iptunnel.o] Error 1
>> | ERROR: Function failed: do_compile (log file is located at
>> /data/poky-master/tmp-glibc/work/corei7-64-poky-linux/net-to
>> ols/1.60-26-r0/temp/log.do_compile.27643)
>>
>> Looks like net-tools is broken by something else too.
>>
>
> I'm out of the office in about one hour. So someone else is
> going to have to pick up the libc-headers fix.
>


Switching to my gmail, so I can follow along.

I do have about a half hour now, I'll check the net uapi code in the kernel
and see
if there's another fixup I can do.

These errors have been lurking for about the last year, the answer from the
kernel
folks is typically "change the order of your includes".

So there are two routes to fix it. See if there's a newer userspace with
the includes
changed, or do what I did, take the change out of libc-headers.

I'll check to see if I can do the latter here.

Out of curiosity, what image type is this ?  built core-image-sato,
kernel-dev for
x86-64 and they all worked.

Bruce


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



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


Re: [OE-core] [PATCH 0/7] linux-yocto: consolidated (and hopefully final) pull request

2016-10-03 Thread Bruce Ashfield

On 2016-10-03 11:45 AM, Burton, Ross wrote:


On 3 October 2016 at 06:54, Bruce Ashfield > wrote:

The big thing to note about this update .. is that the libc-headers bump
to the 4.8 final tarball picked up some uapi headers that broke the
build
of ppp. I never would have thought it was possible, but it happened.


| In file included from
/data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/linux/if_tunnel.h:6:0,
|  from iptunnel.c:39:
|
/data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/linux/ip.h:85:8:
error: redefinition of 'struct iphdr'
|  struct iphdr {
| ^
| In file included from iptunnel.c:29:0:
|
/data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/netinet/ip.h:44:8:
note: originally defined here
|  struct iphdr
| ^
| : recipe for target 'iptunnel.o' failed
| make: *** [iptunnel.o] Error 1
| ERROR: Function failed: do_compile (log file is located at
/data/poky-master/tmp-glibc/work/corei7-64-poky-linux/net-tools/1.60-26-r0/temp/log.do_compile.27643)

Looks like net-tools is broken by something else too.


I'm out of the office in about one hour. So someone else is
going to have to pick up the libc-headers fix.

Cheers,

Bruce



Ross


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


Re: [OE-core] [PATCH 0/7] linux-yocto: consolidated (and hopefully final) pull request

2016-10-03 Thread Burton, Ross
On 3 October 2016 at 06:54, Bruce Ashfield 
wrote:

> The big thing to note about this update .. is that the libc-headers bump
> to the 4.8 final tarball picked up some uapi headers that broke the build
> of ppp. I never would have thought it was possible, but it happened.
>

| In file included from
/data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/linux/if_tunnel.h:6:0,
|  from iptunnel.c:39:
|
/data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/linux/ip.h:85:8:
error: redefinition of 'struct iphdr'
|  struct iphdr {
| ^
| In file included from iptunnel.c:29:0:
|
/data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/netinet/ip.h:44:8:
note: originally defined here
|  struct iphdr
| ^
| : recipe for target 'iptunnel.o' failed
| make: *** [iptunnel.o] Error 1
| ERROR: Function failed: do_compile (log file is located at
/data/poky-master/tmp-glibc/work/corei7-64-poky-linux/net-tools/1.60-26-r0/temp/log.do_compile.27643)

Looks like net-tools is broken by something else too.

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


Re: [OE-core] [PATCH V2] sanity: add function to check for git config user

2016-10-03 Thread Burton, Ross
On 3 October 2016 at 01:43, Stephano Cetola  wrote:

> +# If the user hasn't set up their name/email, set some defaults
> +check_git_config() {
> +   if [ -z "$1" ]; then
> +   name="OE"
> +   else
> +   name="$1"
> +   fi
> +   if ! git config user.email > /dev/null ; then
> +   git config --local user.email "${name}@${DISTRO}"
> +   fi
> +   if ! git config user.name > /dev/null ; then
> +   git config --local user.name "${name}"
> +   fi
> +}
>

Instead of embedding this into sanity.bbclass, could it just go into
meta/lib/oe/ somewhere?

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


[OE-core] [PATCH] oeqa/sshcontrol: Handle interrupted system call error

2016-10-03 Thread Richard Purdie
Deal with an interrupted system call gracefully:

|   File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-systemd/build/meta/lib/oeqa/utils/sshcontrol.py",
 line 55, in _run
| if select.select([self.process.stdout], [], [], 5)[0] != []:
| InterruptedError: [Errno 4] Interrupted system call

Signed-off-by: Richard Purdie 

diff --git a/meta/lib/oeqa/utils/sshcontrol.py 
b/meta/lib/oeqa/utils/sshcontrol.py
index da485ee..05d6502 100644
--- a/meta/lib/oeqa/utils/sshcontrol.py
+++ b/meta/lib/oeqa/utils/sshcontrol.py
@@ -52,17 +52,19 @@ class SSHProcess(object):
 endtime = self.starttime + timeout
 eof = False
 while time.time() < endtime and not eof:
-if select.select([self.process.stdout], [], [], 5)[0] != []:
-data = os.read(self.process.stdout.fileno(), 1024)
-if not data:
-self.process.stdout.close()
-eof = True
-else:
-data = data.decode("utf-8")
-output += data
-self.log(data)
-endtime = time.time() + timeout
-
+try:
+if select.select([self.process.stdout], [], [], 5)[0] != 
[]:
+data = os.read(self.process.stdout.fileno(), 1024)
+if not data:
+self.process.stdout.close()
+eof = True
+else:
+data = data.decode("utf-8")
+output += data
+self.log(data)
+endtime = time.time() + timeout
+except InterruptedError:
+continue
 
 # process hasn't returned yet
 if not eof:


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


Re: [OE-core] [PATCH] gmock: fixed installing pkgconfig file and libraries on x86_64 architecture

2016-10-03 Thread Mateusz Nowakowski
ok, done :)
On Fri, 2016-09-30 at 22:42 +0100, Burton, Ross wrote:
> 
> On 30 September 2016 at 23:18, Mateusz Nowakowski  s...@gmail.com> wrote:
> > Signed-off-by: Mateusz Nowakowski 
> > 
> 
> As this is for meta-oe, the patch should go to openembedded-devel@lis
> ts.openembedded.org.
> 
> Thanks,
> Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/4] classes/cross: set lt_cv_sys_lib_dlsearch_path_spec

2016-10-03 Thread Ross Burton
This variable is used by libtool to know what paths are on the default loader
search path.  As we have modified loader paths, cross.bbclass can tell libtool
that both the sysroot libdir and the host library paths are searched, so no
RPATHs for those will be generated.

Signed-off-by: Ross Burton 
---
 meta/classes/cross.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index 8d1e779..01b0933 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -17,6 +17,8 @@ HOST_CC_ARCH = "${BUILD_CC_ARCH}"
 HOST_LD_ARCH = "${BUILD_LD_ARCH}"
 HOST_AS_ARCH = "${BUILD_AS_ARCH}"
 
+export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} ${base_libdir} /lib 
/lib64 /usr/lib /usr/lib64"
+
 STAGING_DIR_HOST = "${STAGING_DIR}/${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"
 
 PACKAGE_ARCH = "${BUILD_ARCH}"
-- 
2.8.1

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


[OE-core] [PATCH 3/4] binutils: fix typo in libtool patch

2016-10-03 Thread Ross Burton
There was a clear typo in a function name, correct it.

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/binutils/binutils/0006-Use-libtool-2.4.patch | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/binutils/binutils/0006-Use-libtool-2.4.patch 
b/meta/recipes-devtools/binutils/binutils/0006-Use-libtool-2.4.patch
index f2411c4..f0fdf46 100644
--- a/meta/recipes-devtools/binutils/binutils/0006-Use-libtool-2.4.patch
+++ b/meta/recipes-devtools/binutils/binutils/0006-Use-libtool-2.4.patch
@@ -16352,7 +16352,7 @@ index 9503ec8..70e856e 100644
  case "$perm_rpath " in
  *" $libdir "*) ;;
 -*) perm_rpath="$perm_rpath $libdir" ;;
-+*) func_apped perm_rpath " $libdir" ;;
++*) func_append perm_rpath " $libdir" ;;
  esac
fi
  done
@@ -21175,4 +21175,3 @@ index bba9fd2..25a2dae 100755
  
 -- 
 2.9.0
-
-- 
2.8.1

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


[OE-core] [PATCH 2/4] classes/native: set lt_cv_sys_lib_dlsearch_path_spec

2016-10-03 Thread Ross Burton
This variable is used by libtool to know what paths are on the default loader
search path.  As we have modified loader paths, native.bbclass can tell libtool
that both the sysroot libdir and the host library paths are searched, so no
RPATHs for those will be generated.

Signed-off-by: Ross Burton 
---
 meta/classes/native.bbclass | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index f67ef00..143f8a9 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -87,8 +87,7 @@ datadir = "${STAGING_DATADIR_NATIVE}"
 
 baselib = "lib"
 
-# Libtool's default paths are correct for the native machine
-lt_cv_sys_lib_dlsearch_path_spec[unexport] = "1"
+export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} ${base_libdir} /lib 
/lib64 /usr/lib /usr/lib64"
 
 NATIVE_PACKAGE_PATH_SUFFIX ?= ""
 bindir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
-- 
2.8.1

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


[OE-core] [PATCH 4/4] binutils: apply RPATH fixes from our libtool patches

2016-10-03 Thread Ross Burton
We don't autoreconf/libtoolize binutils as it has very strict requirements, so
extend our patching of the stock libtool to include two fixes to RPATH
behaviour, as part of the solution to ensure that native binaries don't have
RPATHs pointing at the host system's /usr/lib.

This generally doesn't cause a problem but it can cause some binaries (such as
ar) to abort on startup:

./x86_64-pokysdk-linux-ar: relocation error: /usr/lib/libc.so.6: symbol
_dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with
link time reference

The situation here is that ar is built and as it links to the host libc/loader
has an RPATH for /usr/lib.  If tmp is wiped and then binutils is installed from
sstate relocation occurs and the loader changed to the sysroot, but there
remains a RPATH for /usr/lib.  This means that the sysroot loader is used with
the host libc, which can be incompatible.  By telling libtool that the host
library paths are in the default search path, and ensuring that all default
search paths are not added as RPATHs by libtool, the result is a binary that
links to what it should be linking to and nothing else.

[ YOCTO #9287 ]

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/binutils/binutils-2.27.inc   |   1 +
 .../binutils/0014-libtool-remove-rpath.patch   | 100 +
 2 files changed, 101 insertions(+)
 create mode 100644 
meta/recipes-devtools/binutils/binutils/0014-libtool-remove-rpath.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.27.inc 
b/meta/recipes-devtools/binutils/binutils-2.27.inc
index 9cc57fc..03b7bed 100644
--- a/meta/recipes-devtools/binutils/binutils-2.27.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.27.inc
@@ -33,6 +33,7 @@ SRC_URI = "\
  file://0011-Change-default-emulation-for-mips64-linux.patch \
  file://0012-Add-support-for-Netlogic-XLP.patch \
  file://0013-fix-the-incorrect-assembling-for-ppc-wait-mnemonic.patch \
+ file://0014-libtool-remove-rpath.patch \
 "
 S  = "${WORKDIR}/git"
 
diff --git 
a/meta/recipes-devtools/binutils/binutils/0014-libtool-remove-rpath.patch 
b/meta/recipes-devtools/binutils/binutils/0014-libtool-remove-rpath.patch
new file mode 100644
index 000..d56948f
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/0014-libtool-remove-rpath.patch
@@ -0,0 +1,100 @@
+Apply these patches from our libtool patches as not only are redundant RPATHs a
+waste of space but they can cause incorrect linking when native packages are
+restored from sstate.
+
+fix-rpath.patch:
+We don't want to add RPATHS which match default linker
+search paths, they're a waste of space. This patch
+filters libtools list and removes the ones we don't need.
+
+norm-rpath.patch:
+Libtool may be passed link paths of the form "/usr/lib/../lib", which
+fool its detection code into thinking it should be included as an
+RPATH in the generated binary.  Normalize before comparision.
+
+Upstream-Status: Inappropriate
+Signed-off-by: Ross Burton 
+
+diff --git a/ltmain.sh b/ltmain.sh
+index 683317c..860a16a 100644
+--- a/ltmain.sh
 b/ltmain.sh
+@@ -8053,8 +8053,14 @@ EOF
+ esac
+   fi
+ else
+-  eval flag=\"$hardcode_libdir_flag_spec\"
+-  func_append dep_rpath " $flag"
++# We only want to hardcode in an rpath if it isn't in the
++# default dlsearch path.
++  case " $sys_lib_dlsearch_path " in
++  *" $libdir "*) ;;
++  *) eval flag=\"$hardcode_libdir_flag_spec\"
++   func_append dep_rpath " $flag"
++   ;;
++  esac
+ fi
+   elif test -n "$runpath_var"; then
+ case "$perm_rpath " in
+@@ -8790,8 +8796,14 @@ EOF
+ esac
+   fi
+ else
+-  eval flag=\"$hardcode_libdir_flag_spec\"
+-  func_append rpath " $flag"
++# We only want to hardcode in an rpath if it isn't in the
++# default dlsearch path.
++  case " $sys_lib_dlsearch_path " in
++  *" $libdir "*) ;;
++  *) eval flag=\"$hardcode_libdir_flag_spec\"
++   rpath+=" $flag"
++   ;;
++  esac
+ fi
+   elif test -n "$runpath_var"; then
+ case "$perm_rpath " in
+@@ -8841,8 +8853,14 @@ EOF
+ esac
+   fi
+ else
+-  eval flag=\"$hardcode_libdir_flag_spec\"
+-  func_append rpath " $flag"
++# We only want to hardcode in an rpath if it isn't in the
++# default dlsearch path.
++  case " $sys_lib_dlsearch_path " in
++  *" $libdir "*) ;;
++  *) eval flag=\"$hardcode_libdir_flag_spec\"
++   func_append rpath " $flag"
++   ;;
++  esac
+ fi
+   elif test -n "$runpath_var"; then
+ case "$finalize_perm_rpath " in
+diff --git a/ltmain.sh b/ltmain.sh

[OE-core] [PATCH v2 2/2] u-boot: Add support to use uboot-extlinux-config class

2016-10-03 Thread Fabio Berton
Use uboot-extlinux-config class to create extlinux.conf file and then
install inside /boot/extlinux directory and also put file to deploy
dir. This file will be only create if UBOOT_EXTLINUX is set to 1.

You can use DEPLOYDIR/extlinux.conf file to install into final image
using wic setting:

IMAGE_BOOT_FILES_append = " extlinux.conf;extlinux/extlinux.conf"

Signed-off-by: Fabio Berton 
Signed-off-by: Otavio Salvador 
---
 meta/recipes-bsp/u-boot/u-boot.inc | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 2a94d26..252aae9 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -13,7 +13,7 @@ B = "${WORKDIR}/build"
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 
-inherit uboot-config uboot-sign deploy
+inherit uboot-config uboot-extlinux-config uboot-sign deploy
 
 EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc 
${TOOLCHAIN_OPTIONS}" V=1'
 EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"'
@@ -65,6 +65,12 @@ UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
 UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
 UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
 
+# U-Boot EXTLINUX variables. U-Boot searches for /boot/extlinux/extlinux.conf
+# to find EXTLINUX conf file.
+UBOOT_EXTLINUX_INSTALL_DIR ?= "/boot/extlinux"
+UBOOT_EXTLINUX_CONF_NAME ?= "extlinux.conf"
+UBOOT_EXTLINUX_SYMLINK ?= "${UBOOT_EXTLINUX_CONF_NAME}-${MACHINE}-${PR}"
+
 do_compile () {
if [ "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 
'ld-is-gold', '', d)}" = "ld-is-gold" ] ; then
sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' 
${S}/config.mk
@@ -192,6 +198,12 @@ do_install () {
 install -m 644 ${WORKDIR}/${UBOOT_ENV_BINARY} 
${D}/boot/${UBOOT_ENV_IMAGE}
 ln -sf ${UBOOT_ENV_IMAGE} ${D}/boot/${UBOOT_ENV_BINARY}
 fi
+
+if [ "${UBOOT_EXTLINUX}" = "1" ]
+then
+install -Dm 0644 ${UBOOT_EXTLINUX_CONFIG} 
${D}/${UBOOT_EXTLINUX_INSTALL_DIR}/${UBOOT_EXTLINUX_CONF_NAME}
+fi
+
 }
 
 FILES_${PN} = "/boot ${sysconfdir}"
@@ -291,6 +303,13 @@ do_deploy () {
 ln -sf ${UBOOT_ENV_IMAGE} ${DEPLOYDIR}/${UBOOT_ENV_BINARY}
 ln -sf ${UBOOT_ENV_IMAGE} ${DEPLOYDIR}/${UBOOT_ENV_SYMLINK}
 fi
+
+if [ "${UBOOT_EXTLINUX}" = "1" ]
+then
+install -m 644 ${UBOOT_EXTLINUX_CONFIG} 
${DEPLOYDIR}/${UBOOT_EXTLINUX_SYMLINK}
+ln -sf ${UBOOT_EXTLINUX_SYMLINK} 
${DEPLOYDIR}/${UBOOT_EXTLINUX_CONF_NAME}-${MACHINE}
+ln -sf ${UBOOT_EXTLINUX_SYMLINK} 
${DEPLOYDIR}/${UBOOT_EXTLINUX_CONF_NAME}
+fi
 }
 
 addtask deploy before do_build after do_compile
-- 
2.1.4

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


[OE-core] [PATCH v2 1/2] classes/uboot-extlinux-config: Add class

2016-10-03 Thread Fabio Berton
This class allow the extlinux.conf generation for U-Boot use.
The U-Boot support for it is given to allow the Generic Distribution
Configuration specification use by OpenEmbedded-based products.

This class can be inherited by u-boot recipes to create extlinux.conf
and boot using menu options.

U-boot with extlinux support is machine dependent, so to use this class
you need to set UBOOT_EXTLINUX to 1 in machine configuration file and
also set root= kernel cmdline UBOOT_EXTLINUX_ROOT. This variable is used
to pass root kernel cmdline, e.g:

UBOOT_EXTLINUX_ROOT = "root=/dev/mmcblk2p2"

Signed-off-by: Fabio Berton 
Signed-off-by: Otavio Salvador 
---
 meta/classes/uboot-extlinux-config.bbclass | 130 +
 1 file changed, 130 insertions(+)
 create mode 100644 meta/classes/uboot-extlinux-config.bbclass

diff --git a/meta/classes/uboot-extlinux-config.bbclass 
b/meta/classes/uboot-extlinux-config.bbclass
new file mode 100644
index 000..a4dc0c0
--- /dev/null
+++ b/meta/classes/uboot-extlinux-config.bbclass
@@ -0,0 +1,130 @@
+# uboot-extlinux-config.bbclass
+#
+# This class allow the extlinux.conf generation for U-Boot use. The
+# U-Boot support for it is given to allow the Generic Distribution
+# Configuration specification use by OpenEmbedded-based products.
+#
+# External variables:
+#
+# UBOOT_EXTLINUX_CONFIG- Configuration file default set to source 
dir.
+# UBOOT_EXTLINUX_CONSOLE   - Set to "console=ttyX" to change kernel 
boot
+#default console.
+# UBOOT_EXTLINUX_LABELS- A list of targets for the automatic 
config.
+# UBOOT_EXTLINUX_KERNEL_ARGS   - Add additional kernel arguments.
+# UBOOT_EXTLINUX_KERNEL_IMAGE  - Kernel image name.
+# UBOOT_EXTLINUX_FDTDIR- Device tree directory.
+# UBOOT_EXTLINUX_INITRD- Indicates a list of filesystem images to
+#concatenate and use as an initrd 
(optional).
+# UBOOT_EXTLINUX_MENU_DESCRIPTION  - Name to use as description.
+# UBOOT_EXTLINUX_ROOT  - Root kernel cmdline.
+#
+# If there's only one label system will boot automatically and menu won't be
+# created. If you want to use more than one labels, e.g linux and alternate,
+# use overrides to set menu description, console and others variables.
+#
+# Ex:
+#
+# UBOOT_EXTLINUX_LABELS ??= "default fallback"
+#
+# UBOOT_EXTLINUX_KERNEL_IMAGE_default ??= "../zImage"
+# UBOOT_EXTLINUX_MENU_DESCRIPTION_default ??= "Linux Default"
+#
+# UBOOT_EXTLINUX_KERNEL_IMAGE_fallback ??= "../zImage-fallback"
+# UBOOT_EXTLINUX_MENU_DESCRIPTION_fallback ??= "Linux Fallback"
+#
+# Results:
+#
+# menu title Select the boot mode
+# LABEL Linux Default
+#   KERNEL ../zImage
+#   FDTDIR ../
+#   APPEND root=/dev/mmcblk2p2 rootwait rw console=${console}
+# LABEL Linux Fallback
+#   KERNEL ../zImage-fallback
+#   FDTDIR ../
+#   APPEND root=/dev/mmcblk2p2 rootwait rw console=${console}
+#
+# Copyright (C) 2016, O.S. Systems Software LTDA.  All Rights Reserved
+# Released under the MIT license (see packages/COPYING)
+#
+# The kernel has an internal default console, which you can override with
+# a console=...some_tty...
+UBOOT_EXTLINUX_CONSOLE ??= "console=${console}"
+UBOOT_EXTLINUX_CONFIG ??= "${S}/extlinux.conf"
+UBOOT_EXTLINUX_LABELS ??= "linux"
+UBOOT_EXTLINUX_FDTDIR ??= "../"
+UBOOT_EXTLINUX_KERNEL_IMAGE ??= "../${KERNEL_IMAGETYPE}"
+UBOOT_EXTLINUX_KERNEL_ARGS ??= "rootwait rw"
+UBOOT_EXTLINUX_MENU_DESCRIPTION_linux ??= "${DISTRO_NAME}"
+
+python create_extlinux_config() {
+if d.getVar("UBOOT_EXTLINUX", False) == "1":
+workdir = d.getVar('WORKDIR', True)
+if not workdir:
+bb.error("WORKDIR not defined, unable to package")
+return
+
+labels = d.getVar('UBOOT_EXTLINUX_LABELS', True)
+if not labels:
+bb.fatal(1, "UBOOT_EXTLINUX_LABELS not defined, nothing to do")
+return
+
+if labels == []:
+bb.fatal(1, "No labels, nothing to do")
+return
+
+cfile = d.getVar('UBOOT_EXTLINUX_CONFIG', True)
+if not cfile:
+bb.fatal('Unable to read UBOOT_EXTLINUX_CONFIG')
+
+try:
+cfgfile = open(cfile, 'w')
+except OSError:
+bb.fatal('Unable to open %s' % (cfile))
+
+cfgfile.write('# Generic Distro Configuration file generated by 
OpenEmbedded\n')
+
+if len(labels.split()) > 1:
+cfgfile.write('menu title Select the boot mode\n')
+
+for label in labels.split():
+localdata = bb.data.createCopy(d)
+
+overrides = localdata.getVar('OVERRIDES', True)
+if not overrides:
+bb.fatal('OVERRIDES not defined')
+
+localdata.setVar('OVERRIDES', label + ':' + overrides)
+bb.data.update_data(localdata)
+
+extlinux_console = 

Re: [OE-core] [PATCH 1/2] classes/uboot-extlinux-config: Add class

2016-10-03 Thread Fabio Berton
Hi Ulf,

Thanks for review.

I agree and I'll change code and use bb.fatal() instead of FuncFailed and
send a v2.

Fabio

On Fri, Sep 30, 2016 at 8:07 PM, Ulf Magnusson  wrote:

> On Sat, Oct 1, 2016 at 12:54 AM, Ulf Magnusson 
> wrote:
> > On Fri, Sep 30, 2016 at 10:33 PM, Fabio Berton
> >  wrote:
> >> This class allow the extlinux.conf generation for U-Boot use.
> >> The U-Boot support for it is given to allow the Generic Distribution
> >> Configuration specification use by OpenEmbedded-based products.
> >>
> >> This class can be inherited by u-boot recipes to create extlinux.conf
> >> and boot using menu options.
> >>
> >> U-boot with extlinux support is machine dependent, so to use this class
> >> you need to set UBOOT_EXTLINUX to 1 in machine configuration file and
> >> also set root= kernel cmdline UBOOT_EXTLINUX_ROOT. This variable is used
> >> to pass root kernel cmdline, e.g:
> >>
> >> UBOOT_EXTLINUX_ROOT = "root=/dev/mmcblk2p2"
> >>
> >> Signed-off-by: Fabio Berton 
> >> Signed-off-by: Otavio Salvador 
> >> ---
> >>  meta/classes/uboot-extlinux-config.bbclass | 130
> +
> >>  1 file changed, 130 insertions(+)
> >>  create mode 100644 meta/classes/uboot-extlinux-config.bbclass
> >>
> >> diff --git a/meta/classes/uboot-extlinux-config.bbclass
> b/meta/classes/uboot-extlinux-config.bbclass
> >> new file mode 100644
> >> index 000..3480dd6
> >> --- /dev/null
> >> +++ b/meta/classes/uboot-extlinux-config.bbclass
> >> @@ -0,0 +1,130 @@
> >> +# uboot-extlinux-config.bbclass
> >> +#
> >> +# This class allow the extlinux.conf generation for U-Boot use. The
> >> +# U-Boot support for it is given to allow the Generic Distribution
> >> +# Configuration specification use by OpenEmbedded-based products.
> >> +#
> >> +# External variables:
> >> +#
> >> +# UBOOT_EXTLINUX_CONFIG- Configuration file default set to
> source dir.
> >> +# UBOOT_EXTLINUX_CONSOLE   - Set to "console=ttyX" to change
> kernel boot
> >> +#default console.
> >> +# UBOOT_EXTLINUX_LABELS- A list of targets for the
> automatic config.
> >> +# UBOOT_EXTLINUX_KERNEL_ARGS   - Add additional kernel arguments.
> >> +# UBOOT_EXTLINUX_KERNEL_IMAGE  - Kernel image name.
> >> +# UBOOT_EXTLINUX_FDTDIR- Device tree directory.
> >> +# UBOOT_EXTLINUX_INITRD- Indicates a list of filesystem
> images to
> >> +#concatenate and use as an initrd
> (optional).
> >> +# UBOOT_EXTLINUX_MENU_DESCRIPTION  - Name to use as description.
> >> +# UBOOT_EXTLINUX_ROOT  - Root kernel cmdline.
> >> +#
> >> +# If there's only one label system will boot automatically and menu
> won't be
> >> +# created. If you want to use more than one labels, e.g linux and
> alternate,
> >> +# use overrides to set menu description, console and others variables.
> >> +#
> >> +# Ex:
> >> +#
> >> +# UBOOT_EXTLINUX_LABELS ??= "default fallback"
> >> +#
> >> +# UBOOT_EXTLINUX_KERNEL_IMAGE_default ??= "../zImage"
> >> +# UBOOT_EXTLINUX_MENU_DESCRIPTION_default ??= "Linux Default"
> >> +#
> >> +# UBOOT_EXTLINUX_KERNEL_IMAGE_fallback ??= "../zImage-fallback"
> >> +# UBOOT_EXTLINUX_MENU_DESCRIPTION_fallback ??= "Linux Fallback"
> >> +#
> >> +# Results:
> >> +#
> >> +# menu title Select the boot mode
> >> +# LABEL Linux Default
> >> +#   KERNEL ../zImage
> >> +#   FDTDIR ../
> >> +#   APPEND root=/dev/mmcblk2p2 rootwait rw console=${console}
> >> +# LABEL Linux Fallback
> >> +#   KERNEL ../zImage-fallback
> >> +#   FDTDIR ../
> >> +#   APPEND root=/dev/mmcblk2p2 rootwait rw console=${console}
> >> +#
> >> +# Copyright (C) 2016, O.S. Systems Software LTDA.  All Rights Reserved
> >> +# Released under the MIT license (see packages/COPYING)
> >> +#
> >> +# The kernel has an internal default console, which you can override
> with
> >> +# a console=...some_tty...
> >> +UBOOT_EXTLINUX_CONSOLE ??= "console=${console}"
> >> +UBOOT_EXTLINUX_CONFIG ??= "${S}/extlinux.conf"
> >> +UBOOT_EXTLINUX_LABELS ??= "linux"
> >> +UBOOT_EXTLINUX_FDTDIR ??= "../"
> >> +UBOOT_EXTLINUX_KERNEL_IMAGE ??= "../${KERNEL_IMAGETYPE}"
> >> +UBOOT_EXTLINUX_KERNEL_ARGS ??= "rootwait rw"
> >> +UBOOT_EXTLINUX_MENU_DESCRIPTION_linux ??= "${DISTRO_NAME}"
> >> +
> >> +python create_extlinux_config() {
> >> +if d.getVar("UBOOT_EXTLINUX", False) == "1":
> >> +workdir = d.getVar('WORKDIR', True)
> >> +if not workdir:
> >> +bb.error("WORKDIR not defined, unable to package")
> >> +return
> >> +
> >> +labels = d.getVar('UBOOT_EXTLINUX_LABELS', True)
> >> +if not labels:
> >> +bb.debug(1, "UBOOT_EXTLINUX_LABELS not defined, nothing to
> do")
> >> +return
> >> +
> >> +if labels == []:
> >> +bb.debug(1, "No labels, nothing to do")
> >> +   

[OE-core] [PATCH 1/1] xf86-video-intel: Upgrade to recent git

2016-10-03 Thread Jussi Kukkonen
Upgrade from the latest snapshot to a recent git revision.
Without this xvideo does not work on skylake: Backporting the
specific fixes turned out to be too complex.

Remove patches that are in upstream already, rebase
disable-x11-dri3.patch.

Fixes [YOCTO #10041]

Signed-off-by: Jussi Kukkonen 
---
 .../0001-gen8-Fix-the-YUV-RGB-shader.patch | 65 
 ...-call-to-PixmapSyncDirtyHelper-broken-by-.patch | 30 --
 .../xf86-video-intel/disable-x11-dri3.patch|  6 +-
 ...-against-ABI-breakage-in-recent-versions-.patch | 70 --
 .../xorg-driver/xf86-video-intel/udev-fstat.patch  | 59 --
 ...o-intel_2.99.917.bb => xf86-video-intel_git.bb} | 13 ++--
 6 files changed, 10 insertions(+), 233 deletions(-)
 delete mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-gen8-Fix-the-YUV-RGB-shader.patch
 delete mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-uxa-fix-the-call-to-PixmapSyncDirtyHelper-broken-by-.patch
 delete mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-intel/sna-Protect-against-ABI-breakage-in-recent-versions-.patch
 delete mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-intel/udev-fstat.patch
 rename meta/recipes-graphics/xorg-driver/{xf86-video-intel_2.99.917.bb => 
xf86-video-intel_git.bb} (81%)

diff --git 
a/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-gen8-Fix-the-YUV-RGB-shader.patch
 
b/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-gen8-Fix-the-YUV-RGB-shader.patch
deleted file mode 100644
index 3576219..000
--- 
a/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-gen8-Fix-the-YUV-RGB-shader.patch
+++ /dev/null
@@ -1,65 +0,0 @@
-From c43617b739e358064396912c7a7a8028ca91d201 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= 
-Date: Thu, 16 Apr 2015 20:40:39 +0300
-Subject: [PATCH] gen8: Fix the YUV->RGB shader
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Use the correct register (Yn_01) with first half of the
-Y samples instead of using the register (Yn_23) with the
-second half twice when computing the green channel.
-
-Also use the Yn_01 register name instead of Yn for the red
-channel as well, just for a bit of extra consistency.
-
-Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89807
-Signed-off-by: Ville Syrjälä 
-Tested-by: Chris Wilson 
-
-Upstream-Status: Backport
-Signed-off-by: Saul Wold 
-

- src/render_program/exa_wm_yuv_rgb.g8a | 4 ++--
- src/render_program/exa_wm_yuv_rgb.g8b | 2 +-
- 2 files changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/src/render_program/exa_wm_yuv_rgb.g8a 
b/src/render_program/exa_wm_yuv_rgb.g8a
-index 7def093..34973ba 100644
 a/src/render_program/exa_wm_yuv_rgb.g8a
-+++ b/src/render_program/exa_wm_yuv_rgb.g8a
-@@ -76,7 +76,7 @@ add (16)Cbn<1>F  Cb<8,8,1>F  -0.501961F  { 
compr align1 };
- /* 
-  * R = Y + Cr * 1.596
-  */
--mov (8)acc0<1>F   Yn<8,8,1>F  { compr align1 };
-+mov (8)acc0<1>F   Yn_01<8,8,1>F   { compr align1 };
- mac.sat(8) src_sample_r_01<1>FCrn_01<8,8,1>F  1.596F  { compr 
align1 };
-  
- mov (8)acc0<1>F   Yn_23<8,8,1>F   { compr align1 };
-@@ -84,7 +84,7 @@ mac.sat(8) src_sample_r_23<1>F   Crn_23<8,8,1>F  1.596F  
{ compr align1 };
- /*
-  * G = Crn * -0.813 + Cbn * -0.392 + Y
-  */
--mov (8)acc0<1>F   Yn_23<8,8,1>F   { compr align1 };
-+mov (8)acc0<1>F   Yn_01<8,8,1>F   { compr align1 };
- mac (8)acc0<1>F   Crn_01<8,8,1>F  -0.813F { compr 
align1 };
- mac.sat(8) src_sample_g_01<1>FCbn_01<8,8,1>F  -0.392F { 
compr align1 };
- 
-diff --git a/src/render_program/exa_wm_yuv_rgb.g8b 
b/src/render_program/exa_wm_yuv_rgb.g8b
-index 4494953..2cd6fc4 100644
 a/src/render_program/exa_wm_yuv_rgb.g8b
-+++ b/src/render_program/exa_wm_yuv_rgb.g8b
-@@ -6,7 +6,7 @@
-{ 0x80600048, 0x21c03ae8, 0x3e8d02c0, 0x3fcc49ba },
-{ 0x0061, 0x24003ae0, 0x008d0320, 0x },
-{ 0x80600048, 0x21e03ae8, 0x3e8d02e0, 0x3fcc49ba },
--   { 0x0061, 0x24003ae0, 0x008d0320, 0x },
-+   { 0x0061, 0x24003ae0, 0x008d0300, 0x },
-{ 0x00600048, 0x24003ae0, 0x3e8d02c0, 0xbf5020c5 },
-{ 0x80600048, 0x22003ae8, 0x3e8d0340, 0xbec8b439 },
-{ 0x0061, 0x24003ae0, 0x008d0320, 0x },
--- 
-2.5.0
-
diff --git 
a/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-uxa-fix-the-call-to-PixmapSyncDirtyHelper-broken-by-.patch
 
b/meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-uxa-fix-the-call-to-PixmapSyncDirtyHelper-broken-by-.patch
deleted file mode 100644
index 29924bb..000
--- 

[OE-core] [PATCH 0/1] xf86-video-intel: Upgrade to recent git

2016-10-03 Thread Jussi Kukkonen
Currently xvideo is broken on skylake because our xf86-video-intel
is way too old (it's the last snapshot but that was 21 months ago).
The problem can be reproduced with gtk-play (select goom visualization
from context menu) or testxvideo from xvideo-tests.

Most distros have moved to a recent git commit already (many have also
started using the modesetting driver instead of xf86-video-intel for
modern intel hardware). Unfortunately we did not do the same earlier
in this release.

I'm not happy to send a change like this at this point of the release
but backporting the xvideo fix alone does not seem feasible. I've done
my usual smoke testing for graphics changes but this of course affects
all Intel graphics hardware, most of which I can't test with.

Thanks,
  Jussi


The following changes since commit 3a73fe0efcb7aeefcca7011bba887caad03d4d03:

  beaglebone.conf: produce wic images for Beaglebone (2016-10-01 21:45:57 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib jku/xf86-video-intel
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jku/xf86-video-intel

Jussi Kukkonen (1):
  xf86-video-intel: Upgrade to recent git

 .../0001-gen8-Fix-the-YUV-RGB-shader.patch | 65 
 ...-call-to-PixmapSyncDirtyHelper-broken-by-.patch | 30 --
 .../xf86-video-intel/disable-x11-dri3.patch|  6 +-
 ...-against-ABI-breakage-in-recent-versions-.patch | 70 --
 .../xorg-driver/xf86-video-intel/udev-fstat.patch  | 59 --
 ...o-intel_2.99.917.bb => xf86-video-intel_git.bb} | 13 ++--
 6 files changed, 10 insertions(+), 233 deletions(-)
 delete mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-gen8-Fix-the-YUV-RGB-shader.patch
 delete mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-intel/0001-uxa-fix-the-call-to-PixmapSyncDirtyHelper-broken-by-.patch
 delete mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-intel/sna-Protect-against-ABI-breakage-in-recent-versions-.patch
 delete mode 100644 
meta/recipes-graphics/xorg-driver/xf86-video-intel/udev-fstat.patch
 rename meta/recipes-graphics/xorg-driver/{xf86-video-intel_2.99.917.bb => 
xf86-video-intel_git.bb} (81%)

-- 
2.1.4

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


Re: [OE-core] Psplash on Systemd with progress bar

2016-10-03 Thread Burton, Ross
On 3 October 2016 at 10:47, srikanth krishnakar 
wrote:

> Thanks for your response. You are right about the splash support in
> splash.. but at least I wanted to eliminate the progress bar that is anyway
> non-functional. I masked the psplash_draw_progress and its associated
> psplash_fb_draw_image functions but the progress bar border still shows up
> leading to a less preferred splash image.
>

IIRC, the border is part of the image, so you should check this and if so
edit the splash image.

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


Re: [OE-core] [PATCH v2] scripts: add new script 'native'

2016-10-03 Thread Ed Bartosh
On Sun, Oct 02, 2016 at 04:30:58PM +0200, Ulf Magnusson wrote:
> On Sun, Oct 2, 2016 at 4:15 PM, Jérémy Rosen  wrote:
> > "native" might be a bit too generic...
> >
> > could I suggest oe_native-run or bitbake-native ?
> >
> > something that says it's yocto-galaxy specific and can be autocompleted with
> > a reasonable prefix...
> >
> >
> > Jérémy Rosen
> 
> I think overly namespacing things that aren't likely to clash in
> practice gets annoying. I would've gone for "run-native" (more
> descriptive and English-like, less generic), but how about something
> simple and easy to type like "oe-native" or "oe-run-native" if a
> prefix is added? That's consistent with the naming scheme used for
> many other scripts in scripts/ too.
> 

I'm ok to rename it. I agree that 'native' may look too generic, but
I don't know about any existing tool with this name.

Anyway, let me know which name I should rename it to. Feel free to send a
patch too. I personally like 'oe-native' more than other proposals.

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


Re: [OE-core] [PATCH 0/1] Avoid unnecessary dependency on awk in devtool deploy-target

2016-10-03 Thread Peter Kjellerstedt
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: den 3 oktober 2016 01:47
> To: Peter Kjellerstedt
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 0/1] Avoid unnecessary dependency on awk
> in devtool deploy-target
> 
> > On Sep 30, 2016, at 12:53 PM, Peter Kjellerstedt
> >  wrote:
> >
> > After updating to Krogoth, our developers were faced with the
> > following error message when using devtool deploy-target:
> >
> > /tmp/devtool_deploy.sh: line 23: awk: not found
> >
> > This is of course due to the fact that we do not have awk installed
> > in our products. However, the use of awk in devtool deploy-target is
> > completely unnecessary. It is already using sed, and sed is fully
> > capable of extracting the information that awk was used for.
> 
> sed or awk both are individual packages, some other user may complain
> they don't have sed installed. it would be good to know if we document 
> this dependency for using devtool.
> 
> > //Peter

I find it much less likely to have a system without sed than awk, but 
you are right that the dependencies should be documented somewhere, 
unless they already are... After my fix, devtool deploy requires the 
following commands: cat (can be replaced by letting sed read the file 
itself), df, dirname (can be replaced with a parameter expansion), find, 
head (can be replaced with sed), mkdir, mv, rm, rmdir, sed, sh and tar.

//Peter

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


Re: [OE-core] Psplash on Systemd with progress bar

2016-10-03 Thread srikanth krishnakar
Hello Khem,

Thanks for your response. You are right about the splash support in
splash.. but at least I wanted to eliminate the progress bar that is anyway
non-functional. I masked the psplash_draw_progress and its associated
psplash_fb_draw_image functions but the progress bar border still shows up
leading to a less preferred splash image.

Thanks!

On Mon, Oct 3, 2016 at 5:07 AM, Khem Raj  wrote:

>
> On Sep 28, 2016, at 10:38 PM, srikanth krishnakar 
> wrote:
>
> Hi All,
>
> Yocto version: yocto-2.1
> Target: ARM imx6
> Graphics: X11 (core-image-sato)
>
> I am trying to use psplash with systemd and have come across the service
> files prepared by Eric:
>
> http://lists.busybox.net/pipermail/buildroot/2014-May/097233.html
>
> Although the splash comes up for a split second and vanishes on my imx6
> target it never stays till desktop appears nor it displays any progress
> bar. I read Eric mention about patch to systemd (src/core/manager.c) to
> write progress data to psplash socket but I couldn't find the patch. Can
> anyone point me to the patch for systemd that writes progress data to
> psplash socket so that I can see progress bar and while keeping splash
> alive till desktop shows up ?
>
>
> systemd is not integrated with psplash as systemV is. system has other
> graphic systems e.g. dietsplash which work better.
>
>
> Thanks in Advance!!
> --
> ___
> 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] makedevs: don't restrict device node paths to 40 characters

2016-10-03 Thread Andre McCurdy
On Sun, Oct 2, 2016 at 1:37 PM, Khem Raj  wrote:
>
>> On Sep 12, 2016, at 1:14 PM, Andre McCurdy  wrote:
>>
>> 40 character paths work OK for device nodes in /dev but not for
>> device nodes created in a chroot, LXC container, etc.
>>
>> Since the 'path' array is already a 4k buffer, the sscanf 40
>> character limit seems to be a typo or historical mis-merge. Update
>> the sscanf limit and bring the code in sync with the Buildroot
>> version:
>>
>>  
>> https://git.buildroot.net/buildroot/commit/?id=8876b6751e0bc19a3754290061808f0f8420708e
>
> what is upstream worthiness of this patch ? it seems it could be
> a good change

Where is the upstream?

>>
>> Signed-off-by: Andre McCurdy 
>> ---
>> meta/recipes-devtools/makedevs/makedevs/makedevs.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-devtools/makedevs/makedevs/makedevs.c 
>> b/meta/recipes-devtools/makedevs/makedevs/makedevs.c
>> index 7471f3f..cba7681 100644
>> --- a/meta/recipes-devtools/makedevs/makedevs/makedevs.c
>> +++ b/meta/recipes-devtools/makedevs/makedevs/makedevs.c
>> @@ -360,7 +360,7 @@ static int interpret_table_entry(char *line)
>>   unsigned long mode = 0755, uid = 0, gid = 0, major = 0, minor = 0;
>>   unsigned long start = 0, increment = 1, count = 0;
>>
>> - if (0 > sscanf(line, "%40s %c %lo %40s %40s %lu %lu %lu %lu %lu", path,
>> + if (0 > sscanf(line, "%4095s %c %lo %40s %40s %lu %lu %lu %lu %lu", 
>> path,
>>   , , usr_buf, grp_buf, , , ,
>>   , ))
>>   {
>> --
>> 1.9.1
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core