date:20160531

Re: [OE-core] [PATCH 01/42] gcc: Add gcc6 recipes

2016-05-31 Thread Paul Eggleton

On Wed, 01 Jun 2016 10:20:23 Paul Eggleton wrote:
> On Tue, 31 May 2016 11:12:21 Jussi Kukkonen wrote:
> > On 11 May 2016 at 20:35, Khem Raj  wrote:
> > > +#BASEURI ?= "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
> > > +BASEURI ?= "git://
> > > github.com/gcc-mirror/gcc;branch=gcc-6-branch;protocol=git"
> > 
> > I guess this is where git2_github.com.gcc-mirror.gcc.tar.gz download comes
> > from? It increased the size of my downloads-directory by >30% -- and I
> > must
> > have quite a bit of old junk in that directory already.
> > 
> > Is there no other solution to this than a 2.5G git copy (honest question,
> > I
> > don't know gcc)?
> 
> We went down this road before and it wasn't great for users. There is at
> least a tarball for 6.1, we'd presumably need some patches on top of that
> (~43 if we were to simply take what's in the gcc-6-branch between 6.1 and
> bd9a826, minus the "daily bumps").

Perhaps that was a little unclear - when I say "we went down this road before" 
I'm agreeing with Jussi - we pointed to a git branch in a previous release 
with the same resulting huge download for everyone, something I think we 
should avoid if at all possible.

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 01/42] gcc: Add gcc6 recipes

2016-05-31 Thread Paul Eggleton

On Tue, 31 May 2016 11:12:21 Jussi Kukkonen wrote:
> On 11 May 2016 at 20:35, Khem Raj  wrote:
> > +#BASEURI ?= "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
> > +BASEURI ?= "git://
> > github.com/gcc-mirror/gcc;branch=gcc-6-branch;protocol=git"
> 
> I guess this is where git2_github.com.gcc-mirror.gcc.tar.gz download comes
> from? It increased the size of my downloads-directory by >30% -- and I must
> have quite a bit of old junk in that directory already.
> 
> Is there no other solution to this than a 2.5G git copy (honest question, I
> don't know gcc)?

We went down this road before and it wasn't great for users. There is at least 
a tarball for 6.1, we'd presumably need some patches on top of that (~43 if we 
were to simply take what's in the gcc-6-branch between 6.1 and bd9a826, minus 
the "daily bumps").

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 1/1] tcl: Only set BINCONFIG_GLOB for target builds

2016-05-31 Thread Andreas Müller

On Tue, May 31, 2016 at 11:51 AM, Peter Kjellerstedt
 wrote:
> The recent change of how ${bindir_crossscripts} is installed to the
> sysroot had the unforeseen effect that tclConfig.sh in the sysroot
> contained invalid paths, which caused postgresql to fail to build.
> The change in the contents of tclConfig.sh was due to that it was
> previously installed to the sysroot after binconfig had done its work,
> and was thus unaffected by it.
>
> This change makes sure the contents of tclConfig.sh is the same as
> before, both in the sysroots and on target. This will make postgresql
> build again.
>
> This also changes the BINCONFIG_GLOB to only match tclConfig.sh.
> Before it would also match itclConfig.sh, tclooConfig.sh and
> tdbcConfig.sh, which were consequently installed to the sysroots.
> However, that seems to have been accidentally introduced with the use
> of binconfig (based on what is installed in do_install()).
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta/recipes-devtools/tcltk/tcl_8.6.4.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-devtools/tcltk/tcl_8.6.4.bb 
> b/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
> index 61be81d..3a3fd83 100644
> --- a/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
> +++ b/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
> @@ -93,7 +93,7 @@ do_install_ptest() {
>  }
>
>  # Fix some paths that might be used by Tcl extensions
> -BINCONFIG_GLOB = "*Config.sh"
> +BINCONFIG_GLOB_class-target = "tclConfig.sh"
>
>  # Fix the path in sstate
>  SSTATE_SCAN_FILES += "*Config.sh"
> --
> 2.1.0
>
> --
For me tclConfig.sh still contains absolute paths and postgresql still
fails. I did ccleansstate for tcl and postgresql, applied this patch
and tried to build postgresql.

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

[OE-core] [PATCHv3] systemd: allow add users as a rootfs postprocess cmd

2016-05-31 Thread Stephano Cetola

Adding all the users / groups to systemd is only available for readonly
file systems. This change allows users to add them to read / write file
systems as well by specifying:

ROOTFS_POSTPROCESS_COMMAND += "systemd_create_users"

Also, add "--shell /sbin/nologin" to each user's add params.

[ YOCTO #9497 ]

Signed-off-by: Stephano Cetola 
---
 meta/classes/rootfs-postcommands.bbclass | 43 +++-
 1 file changed, 20 insertions(+), 23 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index 95d28af..db8b551 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -21,7 +21,7 @@ ROOTFS_POSTUNINSTALL_COMMAND =+ "write_image_manifest ; "
 POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
 # Set default target for systemd images
 SYSTEMD_DEFAULT_TARGET ?= '${@bb.utils.contains("IMAGE_FEATURES", "x11-base", 
"graphical.target", "multi-user.target", d)}'
-ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", "set_systemd_default_target; ", "", d)}'
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", "set_systemd_default_target; systemd_create_users;", "", d)}'
 
 ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 
@@ -30,7 +30,25 @@ ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
 ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}"
 
-
+systemd_create_users () {
+   for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
+   [ -e $conffile ] || continue
+   grep -v "^#" $conffile | sed -e '/^$/d' | while read type name 
id comment; do
+   if [ "$type" = "u" ]; then
+   useradd_params="--shell /sbin/nologin"
+   [ "$id" != "-" ] && useradd_params="$useradd_params 
--uid $id"
+   [ "$comment" != "-" ] && 
useradd_params="$useradd_params --comment $comment"
+   useradd_params="$useradd_params --system $name"
+   eval useradd --root ${IMAGE_ROOTFS} $useradd_params || 
true
+   elif [ "$type" = "g" ]; then
+   groupadd_params=""
+   [ "$id" != "-" ] && groupadd_params="$groupadd_params 
--gid $id"
+   groupadd_params="$groupadd_params --system $name"
+   eval groupadd --root ${IMAGE_ROOTFS} $groupadd_params 
|| true
+   fi
+   done
+   done
+}
 
 #
 # A hook function to support read-only-rootfs IMAGE_FEATURES
@@ -73,27 +91,6 @@ read_only_rootfs_hook () {
${IMAGE_ROOTFS}/etc/init.d/populate-volatile.sh
fi
fi
-
-   if ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true", "false", 
d)}; then
-   # Update user database files so that services don't fail for a 
read-only systemd system
-   for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
-   [ -e $conffile ] || continue
-   grep -v "^#" $conffile | sed -e '/^$/d' | while read type name 
id comment; do
-   if [ "$type" = "u" ]; then
-   useradd_params=""
-   [ "$id" != "-" ] && useradd_params="$useradd_params 
--uid $id"
-   [ "$comment" != "-" ] && 
useradd_params="$useradd_params --comment $comment"
-   useradd_params="$useradd_params --system $name"
-   eval useradd --root ${IMAGE_ROOTFS} $useradd_params || 
true
-   elif [ "$type" = "g" ]; then
-   groupadd_params=""
-   [ "$id" != "-" ] && groupadd_params="$groupadd_params 
--gid $id"
-   groupadd_params="$groupadd_params --system $name"
-   eval groupadd --root ${IMAGE_ROOTFS} $groupadd_params 
|| true
-   fi
-   done
-   done
-   fi
 }
 
 #
-- 
2.8.2

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

[OE-core] [PATCHv3] systemd: allow add users as a rootfs postprocess cmd

2016-05-31 Thread Stephano Cetola

Changes since last revision:
remove bbwarn

Stephano Cetola (1):
  systemd: allow add users as a rootfs postprocess cmd

 meta/classes/rootfs-postcommands.bbclass | 43 +++-
 1 file changed, 20 insertions(+), 23 deletions(-)

-- 
2.8.2

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

[OE-core] [PATCHv2] systemd: allow add users as a rootfs postprocess cmd

2016-05-31 Thread Stephano Cetola

 Adding all the users / groups to systemd is only available for readonly
 file systems. This change allows users to add them to read / write file
 systems as well by specifying:

 ROOTFS_POSTPROCESS_COMMAND += "systemd_create_users"

 Also, add "--shell /sbin/nologin" to each user's add params.

 [ YOCTO #9497 ]

Signed-off-by: Stephano Cetola 
---
 meta/classes/rootfs-postcommands.bbclass | 44 +++-
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index 95d28af..fe4cba7 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -21,7 +21,7 @@ ROOTFS_POSTUNINSTALL_COMMAND =+ "write_image_manifest ; "
 POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
 # Set default target for systemd images
 SYSTEMD_DEFAULT_TARGET ?= '${@bb.utils.contains("IMAGE_FEATURES", "x11-base", 
"graphical.target", "multi-user.target", d)}'
-ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", "set_systemd_default_target; ", "", d)}'
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", "set_systemd_default_target; systemd_create_users;", "", d)}'
 
 ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 
@@ -30,7 +30,26 @@ ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
 ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}"
 
-
+systemd_create_users () {
+   bbwarn "creating systemd users"
+   for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
+   [ -e $conffile ] || continue
+   grep -v "^#" $conffile | sed -e '/^$/d' | while read type name 
id comment; do
+   if [ "$type" = "u" ]; then
+   useradd_params="--shell /sbin/nologin"
+   [ "$id" != "-" ] && useradd_params="$useradd_params 
--uid $id"
+   [ "$comment" != "-" ] && 
useradd_params="$useradd_params --comment $comment"
+   useradd_params="$useradd_params --system $name"
+   eval useradd --root ${IMAGE_ROOTFS} $useradd_params || 
true
+   elif [ "$type" = "g" ]; then
+   groupadd_params=""
+   [ "$id" != "-" ] && groupadd_params="$groupadd_params 
--gid $id"
+   groupadd_params="$groupadd_params --system $name"
+   eval groupadd --root ${IMAGE_ROOTFS} $groupadd_params 
|| true
+   fi
+   done
+   done
+}
 
 #
 # A hook function to support read-only-rootfs IMAGE_FEATURES
@@ -73,27 +92,6 @@ read_only_rootfs_hook () {
${IMAGE_ROOTFS}/etc/init.d/populate-volatile.sh
fi
fi
-
-   if ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true", "false", 
d)}; then
-   # Update user database files so that services don't fail for a 
read-only systemd system
-   for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
-   [ -e $conffile ] || continue
-   grep -v "^#" $conffile | sed -e '/^$/d' | while read type name 
id comment; do
-   if [ "$type" = "u" ]; then
-   useradd_params=""
-   [ "$id" != "-" ] && useradd_params="$useradd_params 
--uid $id"
-   [ "$comment" != "-" ] && 
useradd_params="$useradd_params --comment $comment"
-   useradd_params="$useradd_params --system $name"
-   eval useradd --root ${IMAGE_ROOTFS} $useradd_params || 
true
-   elif [ "$type" = "g" ]; then
-   groupadd_params=""
-   [ "$id" != "-" ] && groupadd_params="$groupadd_params 
--gid $id"
-   groupadd_params="$groupadd_params --system $name"
-   eval groupadd --root ${IMAGE_ROOTFS} $groupadd_params 
|| true
-   fi
-   done
-   done
-   fi
 }
 
 #
-- 
2.8.2

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

[OE-core] [PATCHv2] systemd: allow add users as a rootfs postprocess cmd

2016-05-31 Thread Stephano Cetola

Changed since last version:
Removed some unnecessary code.

Stephano Cetola (1):
  systemd: allow add users as a rootfs postprocess cmd

 meta/classes/rootfs-postcommands.bbclass | 44 +++-
 1 file changed, 21 insertions(+), 23 deletions(-)

-- 
2.8.2

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

[OE-core] [PATCH] systemd: allow add users as a rootfs postprocess cmd

2016-05-31 Thread Stephano Cetola

Adding all the users / groups to systemd is only available for readonly
file systems. This change allows users to add them to read / write file
systems as well by specifying:

ROOTFS_POSTPROCESS_COMMAND += "systemd_create_users"

Also, add "--shell /sbin/nologin" to each user's add params.

[ YOCTO #9497 ]

Signed-off-by: Stephano Cetola 
---
 meta/classes/rootfs-postcommands.bbclass | 41 
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index 95d28af..a6c3a6d 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -21,7 +21,7 @@ ROOTFS_POSTUNINSTALL_COMMAND =+ "write_image_manifest ; "
 POSTINST_LOGFILE ?= "${localstatedir}/log/postinstall.log"
 # Set default target for systemd images
 SYSTEMD_DEFAULT_TARGET ?= '${@bb.utils.contains("IMAGE_FEATURES", "x11-base", 
"graphical.target", "multi-user.target", d)}'
-ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", "set_systemd_default_target; ", "", d)}'
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", "set_systemd_default_target; systemd_create_users;", "", d)}'
 
 ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 
@@ -30,7 +30,26 @@ ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
 ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}"
 
-
+systemd_create_users () {
+   bbwarn "creating systemd users"
+   for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
+   [ -e $conffile ] || continue
+   grep -v "^#" $conffile | sed -e '/^$/d' | while read type name 
id comment; do
+   if [ "$type" = "u" ]; then
+   useradd_params="--shell /sbin/nologin"
+   [ "$id" != "-" ] && useradd_params="$useradd_params 
--uid $id"
+   [ "$comment" != "-" ] && 
useradd_params="$useradd_params --comment $comment"
+   useradd_params="$useradd_params --system $name"
+   eval useradd --root ${IMAGE_ROOTFS} $useradd_params || 
true
+   elif [ "$type" = "g" ]; then
+   groupadd_params=""
+   [ "$id" != "-" ] && groupadd_params="$groupadd_params 
--gid $id"
+   groupadd_params="$groupadd_params --system $name"
+   eval groupadd --root ${IMAGE_ROOTFS} $groupadd_params 
|| true
+   fi
+   done
+   done
+}
 
 #
 # A hook function to support read-only-rootfs IMAGE_FEATURES
@@ -75,24 +94,6 @@ read_only_rootfs_hook () {
fi
 
if ${@bb.utils.contains("DISTRO_FEATURES", "systemd", "true", "false", 
d)}; then
-   # Update user database files so that services don't fail for a 
read-only systemd system
-   for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
-   [ -e $conffile ] || continue
-   grep -v "^#" $conffile | sed -e '/^$/d' | while read type name 
id comment; do
-   if [ "$type" = "u" ]; then
-   useradd_params=""
-   [ "$id" != "-" ] && useradd_params="$useradd_params 
--uid $id"
-   [ "$comment" != "-" ] && 
useradd_params="$useradd_params --comment $comment"
-   useradd_params="$useradd_params --system $name"
-   eval useradd --root ${IMAGE_ROOTFS} $useradd_params || 
true
-   elif [ "$type" = "g" ]; then
-   groupadd_params=""
-   [ "$id" != "-" ] && groupadd_params="$groupadd_params 
--gid $id"
-   groupadd_params="$groupadd_params --system $name"
-   eval groupadd --root ${IMAGE_ROOTFS} $groupadd_params 
|| true
-   fi
-   done
-   done
fi
 }
 
-- 
2.8.2

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

Re: [OE-core] Wic and "live" images

2016-05-31 Thread Christopher Larson

On Tue, May 31, 2016 at 8:31 AM, Ian Geiser  wrote:

>   On Wed, 25 May 2016 16:04:50 -0400 Christopher Larson <
> clar...@kergoth.com> wrote 
>  >
>  > On Wed, May 25, 2016 at 4:35 AM, Ed Bartosh 
> wrote:
>  >
>  > It's debatable. As long as we keep the logic separated, such that
> anything bsp specific is in the machine or bsp layer, so the images are
> independent of any bsp, then we're fine. If we need to keep certain aspects
> of rootfs / image preparation outside of wic, then we'd need the machines
> which need such setup to use a hook to ensure it's applied to all images,
> i.e. an IMAGE_POSTPROCESS_COMMAND, and we'd need to document that.
>
> If I follow in wic the logic is in the plugins.  So its up to the bsp to
> implement those.  Currently though we have tight coupling with efi and mbr
> in the oe-core libraries.  I guess this leads me into a false sense that
> wic is machine/bsp specific.
>

I'd agree with that, yes, it's the specific plugins that are bound to bsp,
and a number of the defaults are clearly for specific use cases by specific
bsps, which of course is why the wks is machine specific and in the bsp's
realm of responsibility.

>  > That might be doable, but we definitely need to give careful thought to
> what pieces of information about the image creation process come from
> where. Certain aspects are clearly distro, i.e. extra image space, and
> possibly other partitioning like splitting up the rootfs into multiple
> partitions, but others are clearly bsp, i.e. setup of a boot partition if
> the bootloader expects it, and image recipes need to work regardless of
> what distro or machine are selected.
>
> This is what I get at by saying needing a "robust" library of common
> plugins that can be reused by the bsp authors.  I think this would allow
> the wks files to be more consistent and more reusable.
>

I'd agree with that to a certain extent. Many of the current plugins encode
a lot of hardcoded logic and configuration and aren't very flexible. More
small plugins that we can mix and match with more options to configure them
would be nicer, but I'm assuming we just haven't had a lot of people
contributing to wic in that way yet. There aren't currently many ways for
the distro or image to affect what wic does, right now.

Ed wants the image recipe to be responsible for breaking up the rootfs or
otherwise prepping the partition input for use by wic, but if we do that,
we're injecting machine-specific logic into the image recipe. I think it
should either be done by a wic plugin or plugins (either in the wic core,
or as you suggest, new plugins in the bsp), not the image recipe, or the
image/rootfs classes and python package need more hooks for the
machine/distro configuration to opt-in to that sort of preparation without
hardcoding it into the image recipe itself. I don't feel too strongly
either way, I just want to make sure we follow the project philosophy and
don't tightly intertwine the distro, machine, and image recipe.

Lastly, in the current vernacular am I confusing the terms "image" and
> "rootfs"?  In my mind "image" is the physical bits that will get burned
> into ROM/SSD/etc.   "rootfs" is the filesystem component that is injected
> somehow into the image.  Is this correct?
>

It depends on context, actually, which gives the term some ambiguity. The
image *recipe* is of course a yocto construct, and its output might be just
hte rootfs or might be a disk image, depending on the configuration of
IMAGE_FSTYPES. It's this recipe notion of an image that needs the
orthogonality -- no machine or distro specifics in the image recipe.

On the other hand, wic's output is an image, that being a disk image which
gets flashed to media using the rootfs and other files as input.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Wic and "live" images

2016-05-31 Thread Ian Geiser

  On Wed, 25 May 2016 16:04:50 -0400 Christopher Larson 
 wrote  
 > 
 > On Wed, May 25, 2016 at 4:35 AM, Ed Bartosh  
 > wrote:
 > 
 > It's debatable. As long as we keep the logic separated, such that anything 
 > bsp specific is in the machine or bsp layer, so the images are independent 
 > of any bsp, then we're fine. If we need to keep certain aspects of rootfs / 
 > image preparation outside of wic, then we'd need the machines which need 
 > such setup to use a hook to ensure it's applied to all images, i.e. an 
 > IMAGE_POSTPROCESS_COMMAND, and we'd need to document that.

If I follow in wic the logic is in the plugins.  So its up to the bsp to 
implement those.  Currently though we have tight coupling with efi and mbr in 
the oe-core libraries.  I guess this leads me into a false sense that wic is 
machine/bsp specific.

 > That might be doable, but we definitely need to give careful thought to what 
 > pieces of information about the image creation process come from where. 
 > Certain aspects are clearly distro, i.e. extra image space, and possibly 
 > other partitioning like splitting up the rootfs into multiple partitions, 
 > but others are clearly bsp, i.e. setup of a boot partition if the bootloader 
 > expects it, and image recipes need to work regardless of what distro or 
 > machine are selected.

This is what I get at by saying needing a "robust" library of common plugins 
that can be reused by the bsp authors.  I think this would allow the wks files 
to be more consistent and more reusable.   

Lastly, in the current vernacular am I confusing the terms "image" and 
"rootfs"?  In my mind "image" is the physical bits that will get burned into 
ROM/SSD/etc.   "rootfs" is the filesystem component that is injected somehow 
into the image.  Is this correct?

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

[OE-core] [PATCH] openssl: fix the dangling libcrypto.a symlink

2016-05-31 Thread Maxin B. John

Update libcrypto.a symlink to the proper location.

[YOCTO #9523]

Signed-off-by: Maxin B. John 
---
 meta/recipes-connectivity/openssl/openssl.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl.inc 
b/meta/recipes-connectivity/openssl/openssl.inc
index 3412c66..1a0031e 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -195,7 +195,7 @@ do_install_ptest () {
cp -r -L Makefile.org Makefile test ${D}${PTEST_PATH}
cp Configure config e_os.h ${D}${PTEST_PATH}
cp -r -L include ${D}${PTEST_PATH}
-   ln -sf ${base_libdir}/libcrypto.a ${D}${PTEST_PATH}
+   ln -sf ${libdir}/libcrypto.a ${D}${PTEST_PATH}
ln -sf ${libdir}/libssl.a ${D}${PTEST_PATH}
mkdir -p ${D}${PTEST_PATH}/crypto
cp crypto/constant_time_locl.h ${D}${PTEST_PATH}/crypto
-- 
2.4.0

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

Re: [OE-core] Wic and "live" images

2016-05-31 Thread Ian Geiser

  On Tue, 24 May 2016 15:56:39 -0400 Christopher Larson 
 wrote  
 > 
 > On Tue, May 24, 2016 at 12:51 PM, Ed Bartosh  
 > wrote:
 > 
 > The thing is, it's likely the machine/bsp setting the WKS_FILE, yet in 
 > OE/yocto we prefer machine/distro/image to be orthogonal. If you're 
 > injecting machine specific logic into an image, that image isn't going to be 
 > generally useful for all machines, and so violates our philosophy.

Isn't the physical disk image the place that machine/distro/image all intersect 
though?  Maybe this is some philosophy I have always not gotten because it 
seems every time I make an image for a machine I am fighting the current.  
Really I think at the core what I want is a partition layout that I can put a 
payload in.  wic seems exactly that, but I am not sure how to get from my 
rootfs, initramfs and kernel to there.  Thanks!

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

Re: [OE-core] Wic and "live" images

2016-05-31 Thread Ian Geiser

  On Tue, 24 May 2016 15:51:45 -0400 Ed Bartosh 
 wrote  
 > On Mon, May 23, 2016 at 08:13:28AM -0400, Ian Geiser wrote: 
 > >  > On Thu, May 19, 2016 at 05:52:45AM -0400, Ian Geiser wrote:  

[...snip...]

 > How about creating recipe to prepare content or your boot partition and then 
 > using --source rootfs --rootfs-dir= ? 
 > This is much more generic way of creating partitioned images from my 
 > point of view. Image recipes should take care of content and wic takes care 
 > of 
 > putting that content into partitions according to the partitioning 
 > scheme described in .wks 
 >  
 > Does it make sense for you? 

I am at a loss how to do this because it is a efi system partition.  Really all 
it needs is the kernel, initramfs and bootx64.  I see how to do the kernel and 
the bootx64 in the existing plugin.  What I get turned around with is the 
initramfs.  It seems like there is no way to put that in, or use a kernel with 
the initramfs appended.  Is this a limitation that is fixed by "send a patch" 
or am I missing something there.

 >  
 > >  
 > >  > You can probably do the same by using wic plugins, but I'd not suggest  
 > >  > to go this way. Using wic image type is simpler, more consistent, 
 > > easier to do and provides higher level of automation.  
 > >  
 > > Is using the wic image type and a plugin mutually exclusive? 
 > No, not at all. However, I personally found the way I described above 
 > more consistent, flexible and easy to implement and maintain. 

I am not groking this concept because it seems without a robust library of 
plugins the wks files become very hard to implement.  Is this true, or am I 
again missing something obvious.

Thanks for your patience. 

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

Re: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

2016-05-31 Thread Herve Jourdain

Hi,

OK, it seems I've found a patch for meta-raspberrypi. I'll be submitting it
to the Yocto mailing list.
Sorry for the noise.

Herve

-Original Message-
From: Herve Jourdain [mailto:herve.jourd...@neuf.fr] 
Sent: mardi 31 mai 2016 13:37
To: 'zhe...@windriver.com' ;
'richard.pur...@linuxfoundation.org' ;
'openembedded-core@lists.openembedded.org'

Subject: RE: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build
multi types kernel at one time

Hi,

I've just found out that this breaks the kernel builds on raspberrypi,
because do_rpiboot_mkimage() uses ${KERNEL_OUTPUT}, and this patch removes
it...
(sorry to find that only now, but I only today switched to a new environment
for some tests) I'm trying to find a patch to that one, but in the meantime,
people might need to revert it if they meet that kind of problems.

Herve

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
zhe...@windriver.com
Sent: mercredi 25 mai 2016 10:47
To: richard.pur...@linuxfoundation.org;
openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build
multi types kernel at one time

From: He Zhe 

Add KERNEL_IMAGETYPES to support building packaging and installing multi
types of kernel images, such as zImage uImage, at one time.

KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE work as before.

Signed-off-by: He Zhe 
---
 meta/classes/kernel-fitimage.bbclass|  20 ++--
 meta/classes/kernel-grub.bbclass|  44 +---
 meta/classes/kernel-uimage.bbclass  |  10 +-
 meta/classes/kernel.bbclass | 174
+++-
 meta/conf/documentation.conf|   1 +
 meta/recipes-kernel/linux/linux-dtb.inc |  49 +
 6 files changed, 202 insertions(+), 96 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 298eda2..9a3caf5 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -1,8 +1,8 @@
 inherit kernel-uboot uboot-sign
 
 python __anonymous () {
-kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
-if kerneltype == 'fitImage':
+kerneltypes = d.getVar('KERNEL_IMAGETYPES', True) or ""
+if 'fitImage' in kerneltypes.split():
 depends = d.getVar("DEPENDS", True)
 depends = "%s u-boot-mkimage-native dtc-native" % depends
 d.setVar("DEPENDS", depends)
@@ -10,7 +10,9 @@ python __anonymous () {
# Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
# to kernel.bbclass . We have to override it, since we pack zImage
# (at least for now) into the fitImage .
-d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", "zImage")
+typeformake = d.getVar("KERNEL_IMAGETYPE_FOR_MAKE", True) or ""
+if 'fitImage' in typeformake.split():
+d.setVar('KERNEL_IMAGETYPE_FOR_MAKE',
+ typeformake.replace('fitImage', 'zImage'))
 
 image = d.getVar('INITRAMFS_IMAGE', True)
 if image:
@@ -187,7 +189,7 @@ EOF
 }
 
 do_assemble_fitimage() {
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
kernelcount=1
dtbcount=""
rm -f fit-image.its arch/${ARCH}/boot/fitImage @@ -265,14
+267,14 @@ addtask assemble_fitimage before do_install after do_compile
kernel_do_deploy[vardepsexclude] = "DATETIME"
 kernel_do_deploy_append() {
# Update deploy directory
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
cd ${B}
echo "Copying fit-image.its source file..."
-
its_base_name="${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
-   its_symlink_name=${KERNEL_IMAGETYPE}-its-${MACHINE}
+
its_base_name="fitImage-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   its_symlink_name=fitImage-its-${MACHINE}
install -m 0644 fit-image.its
${DEPLOYDIR}/${its_base_name}.its
-
linux_bin_base_name="${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${
DATETIME}"
-
linux_bin_symlink_name=${KERNEL_IMAGETYPE}-linux.bin-${MACHINE}
+
linux_bin_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
install -m 0644 linux.bin
${DEPLOYDIR}/${linux_bin_base_name}.bin
 
cd ${DEPLOYDIR}
diff --git a/meta/classes/kernel-grub.bbclass
b/meta/classes/kernel-grub.bbclass
index a63f482..f7dcc07 100644
--- a/meta/classes/kernel-grub.bbclass
+++ b/meta/classes/kernel-grub.bbclass
@@ -10,41 +10,44 @@
 #   updates the new kernel as the boot priority.
 #
 
-pkg_preinst_kernel-image_append

Re: [OE-core] [PATCH] perl-ptest.inc: fix tar call to prevent objcopy failure

2016-05-31 Thread Renato Caldas

Hi Enrico,

Sorry for the late reply, I missed this e-mail... Your suggestions are
very valid, although not strictly needed to fix this particular bug.

My suggestion is that you submit a new patch with those improvements
on top of the quick fix I made. I suggest you also add quotes to the
--exclude options per tar's man page.

You might also want to simplify the commit message a bit. I'm fairly
new to yocto (and my view may be wrong), but this is how I would do
it:
- change the component name from "perl-ptest.inc:" to "perl:"
- use the commit title to describe the change you made, not exactly
what bug it fixed. Example: "fix tar call according to its man page"
(or something like that)
- describe the change in simpler terms. Taking what you wrote, I would
rewrite it like this:

"The existing tar call on do_install_ptest() did not match the man
page, but worked with older tar versions. The new 1.29 version of tar
has stricter argument handling, and future versions may be even
stricter. Failure to use it according to its manual may result in
arguments being silently ignored and breaking the build."


So while changing the position of the "*" fixed it for tar 1.29, your
proposed changes are important to future-proof the perl recipe for
newer tar versions. As such, please do submit a new patch.

Cheers,
  Renato

2016-05-30 14:04 GMT+01:00 Enrico Jorns :
> With tar version 1.29, the tar call used to copy the ptest files will
> not work anymore. While the call did not match the man page (but worked)
> before, anyway, the latest update of tar seems to have a more strict argument
> handling.
>
> With the current version of the tar call, the copying of files still
> works with latest tar version, but the excludes will not be handled
> properly anymore.
> This results in having binaries compiled with host GCC in the package.
> When doing the strip_and_split files in do_package() with the target
> objcopy, bitbake will fail with this error:
>
>   ERROR: objcopy failed with exit code 256 (cmd was [...])
>   [...]
>   File format not recognized
>
> Thus, the current argument issues and required changes are:
>
>  * Options must be placed _before_ the pathnames.
>
>  * --exclude must be followd by a '=' in order to work properly
>
>  * 'f' options is for providing an archive file, which is unnecessary in
>this case
>
> Note that this could also be a candidate for backporting.
>
> Signed-off-by: Enrico Jorns 
> ---
>
>
> I just wanted to send my patch when I saw you had already send it. Will send
> this one instead as I added some more changes that might be useful. Maybe we
> can squash this into yours if its found to be useful, too.
>
> Best regards, Enrico
>
>
>  meta/recipes-devtools/perl/perl-ptest.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/perl/perl-ptest.inc 
> b/meta/recipes-devtools/perl/perl-ptest.inc
> index 948ea7c..5f0989f 100644
> --- a/meta/recipes-devtools/perl/perl-ptest.inc
> +++ b/meta/recipes-devtools/perl/perl-ptest.inc
> @@ -7,8 +7,8 @@ do_install_ptest () {
> mkdir -p ${D}${PTEST_PATH}
> sed -e "s:\/opt:\/usr:" -i Porting/add-package.pl
> sed -e "s:\/local\/gnu\/:\/:" -i hints/cxux.sh
> -   tar -cf - * --exclude \*.o --exclude libperl.so --exclude Makefile 
> --exclude makefile --exclude hostperl \
> -   --exclude miniperl --exclude generate_uudmap --exclude 
> patches | ( cd ${D}${PTEST_PATH} && tar -xf - )
> +   tar -c --exclude=\*.o --exclude=libperl.so --exclude=Makefile 
> --exclude=makefile --exclude=hostperl \
> +   --exclude=miniperl --exclude=generate_uudmap 
> --exclude=patches * | ( cd ${D}${PTEST_PATH} && tar -x )
>
> sed -i -e "s,${D},,g" \
>-e "s,--sysroot=${STAGING_DIR_HOST},,g" \
> --
> 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 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

2016-05-31 Thread Herve Jourdain

Hi,

I've just found out that this breaks the kernel builds on raspberrypi,
because do_rpiboot_mkimage() uses ${KERNEL_OUTPUT}, and this patch removes
it...
(sorry to find that only now, but I only today switched to a new environment
for some tests)
I'm trying to find a patch to that one, but in the meantime, people might
need to revert it if they meet that kind of problems.

Herve

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
zhe...@windriver.com
Sent: mercredi 25 mai 2016 10:47
To: richard.pur...@linuxfoundation.org;
openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build
multi types kernel at one time

From: He Zhe 

Add KERNEL_IMAGETYPES to support building packaging and installing multi
types of kernel images, such as zImage uImage, at one time.

KERNEL_IMAGETYPE and KERNEL_ALT_IMAGETYPE work as before.

Signed-off-by: He Zhe 
---
 meta/classes/kernel-fitimage.bbclass|  20 ++--
 meta/classes/kernel-grub.bbclass|  44 +---
 meta/classes/kernel-uimage.bbclass  |  10 +-
 meta/classes/kernel.bbclass | 174
+++-
 meta/conf/documentation.conf|   1 +
 meta/recipes-kernel/linux/linux-dtb.inc |  49 +
 6 files changed, 202 insertions(+), 96 deletions(-)

diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index 298eda2..9a3caf5 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -1,8 +1,8 @@
 inherit kernel-uboot uboot-sign
 
 python __anonymous () {
-kerneltype = d.getVar('KERNEL_IMAGETYPE', True)
-if kerneltype == 'fitImage':
+kerneltypes = d.getVar('KERNEL_IMAGETYPES', True) or ""
+if 'fitImage' in kerneltypes.split():
 depends = d.getVar("DEPENDS", True)
 depends = "%s u-boot-mkimage-native dtc-native" % depends
 d.setVar("DEPENDS", depends)
@@ -10,7 +10,9 @@ python __anonymous () {
# Override KERNEL_IMAGETYPE_FOR_MAKE variable, which is internal
# to kernel.bbclass . We have to override it, since we pack zImage
# (at least for now) into the fitImage .
-d.setVar("KERNEL_IMAGETYPE_FOR_MAKE", "zImage")
+typeformake = d.getVar("KERNEL_IMAGETYPE_FOR_MAKE", True) or ""
+if 'fitImage' in typeformake.split():
+d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', 
+ typeformake.replace('fitImage', 'zImage'))
 
 image = d.getVar('INITRAMFS_IMAGE', True)
 if image:
@@ -187,7 +189,7 @@ EOF
 }
 
 do_assemble_fitimage() {
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
kernelcount=1
dtbcount=""
rm -f fit-image.its arch/${ARCH}/boot/fitImage @@ -265,14
+267,14 @@ addtask assemble_fitimage before do_install after do_compile
kernel_do_deploy[vardepsexclude] = "DATETIME"
 kernel_do_deploy_append() {
# Update deploy directory
-   if test "x${KERNEL_IMAGETYPE}" = "xfitImage" ; then
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
cd ${B}
echo "Copying fit-image.its source file..."
-
its_base_name="${KERNEL_IMAGETYPE}-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
-   its_symlink_name=${KERNEL_IMAGETYPE}-its-${MACHINE}
+
its_base_name="fitImage-its-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   its_symlink_name=fitImage-its-${MACHINE}
install -m 0644 fit-image.its
${DEPLOYDIR}/${its_base_name}.its
-
linux_bin_base_name="${KERNEL_IMAGETYPE}-linux.bin-${PV}-${PR}-${MACHINE}-${
DATETIME}"
-
linux_bin_symlink_name=${KERNEL_IMAGETYPE}-linux.bin-${MACHINE}
+
linux_bin_base_name="fitImage-linux.bin-${PV}-${PR}-${MACHINE}-${DATETIME}"
+   linux_bin_symlink_name=fitImage-linux.bin-${MACHINE}
install -m 0644 linux.bin
${DEPLOYDIR}/${linux_bin_base_name}.bin
 
cd ${DEPLOYDIR}
diff --git a/meta/classes/kernel-grub.bbclass
b/meta/classes/kernel-grub.bbclass
index a63f482..f7dcc07 100644
--- a/meta/classes/kernel-grub.bbclass
+++ b/meta/classes/kernel-grub.bbclass
@@ -10,41 +10,44 @@
 #   updates the new kernel as the boot priority.
 #
 
-pkg_preinst_kernel-image_append () {
+python __anonymous () {
+import re
+
+preinst = '''
# Parsing confliction
[ -f "$D/boot/grub/menu.list" ] && grubcfg="$D/boot/grub/menu.list"
[ -f "$D/boot/grub/grub.cfg" ] && grubcfg="$D/boot/grub/grub.cfg"
if [ -n "$grubcfg" ]; then
# Dereference symlink to avoid confliction with new kernel
name.
-   if grep -q "/${KERNEL_IMAGETYPE} \+root=" $grubcfg; then
-   if [ -L "$D/boot/${KERNEL_IMAGETYPE}" ]; then
-   kimage=`realpath

Re: [OE-core] [jethro][PATCH] perl: reorder tar arguments in do_install_ptest()

2016-05-31 Thread Renato Caldas

Hi,

I just received a request to submit this patch to jethro, as some
people are still dependent on that version of yocto.

Cheers,
  Renato

2016-05-31 11:50 GMT+01:00 Renato Caldas :
> On some distributions tar requires the FILE argument to be the last, and
> the existing order was causing the subsequent --exclude options to be dropped.
>
> Fixes [YOCTO #9673].
>
> Signed-off-by: Renato Caldas 
> ---
>  meta/recipes-devtools/perl/perl-ptest.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/perl/perl-ptest.inc 
> b/meta/recipes-devtools/perl/perl-ptest.inc
> index 948ea7c..66c5355 100644
> --- a/meta/recipes-devtools/perl/perl-ptest.inc
> +++ b/meta/recipes-devtools/perl/perl-ptest.inc
> @@ -7,8 +7,8 @@ do_install_ptest () {
> mkdir -p ${D}${PTEST_PATH}
> sed -e "s:\/opt:\/usr:" -i Porting/add-package.pl
> sed -e "s:\/local\/gnu\/:\/:" -i hints/cxux.sh
> -   tar -cf - * --exclude \*.o --exclude libperl.so --exclude Makefile 
> --exclude makefile --exclude hostperl \
> -   --exclude miniperl --exclude generate_uudmap --exclude 
> patches | ( cd ${D}${PTEST_PATH} && tar -xf - )
> +   tar -cf - --exclude \*.o --exclude libperl.so --exclude Makefile 
> --exclude makefile --exclude hostperl \
> +   --exclude miniperl --exclude generate_uudmap --exclude 
> patches * | ( cd ${D}${PTEST_PATH} && tar -xf - )
>
> sed -i -e "s,${D},,g" \
>-e "s,--sysroot=${STAGING_DIR_HOST},,g" \
> --
> 2.8.3
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [jethro][PATCH] perl: reorder tar arguments in do_install_ptest()

2016-05-31 Thread Renato Caldas

On some distributions tar requires the FILE argument to be the last, and
the existing order was causing the subsequent --exclude options to be dropped.

Fixes [YOCTO #9673].

Signed-off-by: Renato Caldas 
---
 meta/recipes-devtools/perl/perl-ptest.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/perl/perl-ptest.inc 
b/meta/recipes-devtools/perl/perl-ptest.inc
index 948ea7c..66c5355 100644
--- a/meta/recipes-devtools/perl/perl-ptest.inc
+++ b/meta/recipes-devtools/perl/perl-ptest.inc
@@ -7,8 +7,8 @@ do_install_ptest () {
mkdir -p ${D}${PTEST_PATH}
sed -e "s:\/opt:\/usr:" -i Porting/add-package.pl
sed -e "s:\/local\/gnu\/:\/:" -i hints/cxux.sh
-   tar -cf - * --exclude \*.o --exclude libperl.so --exclude Makefile 
--exclude makefile --exclude hostperl \
-   --exclude miniperl --exclude generate_uudmap --exclude patches 
| ( cd ${D}${PTEST_PATH} && tar -xf - )
+   tar -cf - --exclude \*.o --exclude libperl.so --exclude Makefile 
--exclude makefile --exclude hostperl \
+   --exclude miniperl --exclude generate_uudmap --exclude patches 
* | ( cd ${D}${PTEST_PATH} && tar -xf - )
 
sed -i -e "s,${D},,g" \
   -e "s,--sysroot=${STAGING_DIR_HOST},,g" \
-- 
2.8.3

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

Re: [OE-core] [PATCH 2/2] bluez5: update to 5.40

2016-05-31 Thread Maxin B. John

Hi,

On Tue, May 31, 2016 at 08:37:36AM +0100, Richard Purdie wrote:
> On Mon, 2016-05-30 at 18:20 +0300, Maxin B. John wrote:
> > 5.39 -> 5.40
> > 
> > Signed-off-by: Maxin B. John 
> > ---
> >  meta/recipes-connectivity/bluez5/{bluez5_5.39.bb => bluez5_5.40.bb}
> > | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >  rename meta/recipes-connectivity/bluez5/{bluez5_5.39.bb =>
> > bluez5_5.40.bb} (89%)
> 
> I had this in master-next and suspect it caused:
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-mips64/build
> s/448/steps/BuildImages/logs/stdio
> 
> https://autobuilder.yoctoproject.org/main/builders/nightly-qa-pam/build
> s/800/steps/BuildImages/logs/stdio
> 
> and the world targets also showed some issues. There were other changes
> mixed in (particularly python3) and some builds succeeded so it could
> also be some kind of dependency race.

Please ignore that patch then. As you have mentioned, it could be some
kind of dependency race (couldnt re-create the failure in the local build)

I will send the bluez5 upgrade along with ofono after python(2->3) work.

> Cheers, 
> Richard

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

[OE-core] [PATCH 1/1] tcl: Only set BINCONFIG_GLOB for target builds

2016-05-31 Thread Peter Kjellerstedt

The recent change of how ${bindir_crossscripts} is installed to the
sysroot had the unforeseen effect that tclConfig.sh in the sysroot
contained invalid paths, which caused postgresql to fail to build.
The change in the contents of tclConfig.sh was due to that it was
previously installed to the sysroot after binconfig had done its work,
and was thus unaffected by it.

This change makes sure the contents of tclConfig.sh is the same as
before, both in the sysroots and on target. This will make postgresql
build again.

This also changes the BINCONFIG_GLOB to only match tclConfig.sh.
Before it would also match itclConfig.sh, tclooConfig.sh and
tdbcConfig.sh, which were consequently installed to the sysroots.
However, that seems to have been accidentally introduced with the use
of binconfig (based on what is installed in do_install()).

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-devtools/tcltk/tcl_8.6.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/tcltk/tcl_8.6.4.bb 
b/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
index 61be81d..3a3fd83 100644
--- a/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
+++ b/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
@@ -93,7 +93,7 @@ do_install_ptest() {
 }
 
 # Fix some paths that might be used by Tcl extensions
-BINCONFIG_GLOB = "*Config.sh"
+BINCONFIG_GLOB_class-target = "tclConfig.sh"
 
 # Fix the path in sstate
 SSTATE_SCAN_FILES += "*Config.sh"
-- 
2.1.0

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

[OE-core] [PATCH 0/1] Correct tclConfig.sh in the sysroots

2016-05-31 Thread Peter Kjellerstedt

Restore the contents of tclConfig.sh in the sysroots so that
postgresql can build again.

//Peter

The following changes since commit fcc2c3c4b3ca08528722442c90acd27e89291405:

  yocto-bsps: Update to 4.1 to include musb fixes (2016-05-30 15:58:16 +0100)

are available in the git repository at:

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

Peter Kjellerstedt (1):
  tcl: Only set BINCONFIG_GLOB for target builds

 meta/recipes-devtools/tcltk/tcl_8.6.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.1.0

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

Re: [OE-core] [PATCHv2 05/16] tcl: Use SYSROOT_DIRS to add dirs to stage in sysroot

2016-05-31 Thread Peter Kjellerstedt

> -Original Message-
> From: Andreas Müller [mailto:schnitzelt...@googlemail.com]
> Sent: den 28 maj 2016 15:42
> To: Peter Kjellerstedt
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCHv2 05/16] tcl: Use SYSROOT_DIRS to add
> dirs to stage in sysroot
> 
> On Thu, May 26, 2016 at 10:14 PM, Andreas Müller
>  wrote:
> > On Thu, May 26, 2016 at 3:41 PM, Peter Kjellerstedt
> >  wrote:
> >>> -Original Message-
> >>> From: Andreas Müller [mailto:schnitzelt...@googlemail.com]
> >>> Sent: den 26 maj 2016 14:00
> >>> To: Peter Kjellerstedt
> >>> Cc: Patches and discussions about the oe-core layer
> >>> Subject: Re: [OE-core] [PATCHv2 05/16] tcl: Use SYSROOT_DIRS to add
> >>> dirs to stage in sysroot
> >>>
> >>> On Thu, May 12, 2016 at 10:37 AM, Peter Kjellerstedt
> >>>  wrote:
> >>> > ---
> >>> >  meta/recipes-devtools/tcltk/tcl_8.6.4.bb | 5 +
> >>> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >>> >
> >>> > diff --git a/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
> b/meta/recipes-
> >>> devtools/tcltk/tcl_8.6.4.bb
> >>> > index 8e92b3e..61be81d 100644
> >>> > --- a/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
> >>> > +++ b/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
> >>> > @@ -68,10 +68,7 @@ do_install() {
> >>> > done
> >>> >  }
> >>> >
> >>> > -SYSROOT_PREPROCESS_FUNCS += "tcl_sysroot_preprocess"
> >>> > -tcl_sysroot_preprocess () {
> >>> > -   sysroot_stage_dir ${D}${bindir_crossscripts}
> ${SYSROOT_DESTDIR}${bindir_crossscripts}
> >>> > -}
> >>> > +SYSROOT_DIRS += "${bindir_crossscripts}"
> >>> >
> >>> >  PACKAGES =+ "tcl-lib"
> >>> >  FILES_tcl-lib = "${libdir}/libtcl8.6.so.*"
> >>> > --
> >>> > 2.1.0
> >>> >
> >>> This one breaks meta-oe's postgresql.
> >>>
> >>> Andreas
> >>
> >> Breaks it how?
> >>
> >> //Peter
> >>
> > Yes I agree I cannot see what's wrong with this patch - together with
> > modifications of staging.bbclass it should do same as before. For
> test
> > I reverted this patch and postgresql builds fine again. Have no idea
> > what's causing postgresql failure
> >
> > Some typo I don't see?
> >
> To get more infomation I
> 
> * build with patch reverted
> * put  sysroot under git control
> * remove revert again
> 
> Don't know why but now we see absolute paths in tclConfig.sh:
> 
> --- a/usr/bin/crossscripts/tclConfig.sh
> +++ b/usr/bin/crossscripts/tclConfig.sh
> @@ -57,7 +57,7 @@ TCL_SHLIB_CFLAGS='-fPIC'
>  TCL_CFLAGS_WARNING='-Wall'
> 
>  # Extra flags to pass to cc:
> -TCL_EXTRA_CFLAGS=' -O2 -pipe -g -feliminate-unused-debug-types
> -fdebug-prefix-map=/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberrypi2/usr/include=/usr/src/debug/tcl/8.6.4-r0
> -fdebug-prefix-map=/home/superandy/tmp/oe-core-glibc/sysroots/x86_64-
> linux=
> -fdebug-prefix-map=/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberrypi2=
>  -pipe '
> +TCL_EXTRA_CFLAGS=' -O2 -pipe -g -feliminate-unused-debug-types
> -fdebug-prefix-map=/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberrypi2/usr/include=/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberrypi2/usr/src/debug/tcl/8.6.4-r0
> -fdebug-prefix-map=/home/superandy/tmp/oe-core-glibc/sysroots/x86_64-
> linux=
> -fdebug-prefix-map=/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberrypi2=
>  -pipe '
> 
>  # Base command to use for combining object files into a shared
> library:
>  TCL_SHLIB_LD='${CC} -shared ${CFLAGS} ${LDFLAGS}'
> @@ -104,11 +104,11 @@
> TCL_BUILD_LIB_SPEC='-L/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberrypi2/us
> 
>  # String to pass to linker to pick up the Tcl library from its
>  # installed directory.
> -TCL_LIB_SPEC='-L=/usr/lib -ltcl8.6'
> +TCL_LIB_SPEC='-L=/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberrypi2/usr/lib
> -ltcl8.6'
> 
>  # String to pass to the compiler so that an extension can
>  # find installed Tcl headers.
> -TCL_INCLUDE_SPEC='-I=/usr/include/tcl8.6'
> +TCL_INCLUDE_SPEC='-I=/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberrypi2/usr/include/tcl8.6'
> 
>  # Indicates whether a version numbers should be used in -l switches
>  # ("ok" means it's safe to use switches like -ltcl7.5;  "nodots" means
> @@ -157,7 +157,7 @@
> TCL_BUILD_STUB_LIB_SPEC='-L/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberryp
> 
>  # String to pass to linker to pick up the Tcl stub library from its
>  # installed directory.
> -TCL_STUB_LIB_SPEC='-L=/usr/lib -ltclstub8.6'
> +TCL_STUB_LIB_SPEC='-L=/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberrypi2/usr/lib
> -ltclstub8.6'
> 
>  # Path to the Tcl stub library in the build directory.
>  TCL_BUILD_STUB_LIB_PATH='/home/superandy/tmp/oe-core-
> glibc/sysroots/raspberrypi2/usr/include/build/libtclstub8.6.a'
> 
> This is the symptom but what is it caused by?
> 
> Andreas

It seems to be an intricate history. The difference stems from the 
the order things are executed in SYSROOT_PREPROCESS_FUNCS, the fact 
that the tcl recipe

[OE-core] [PATCH] pango_1.40.1.bb: Fix compilation error

2016-05-31 Thread Dmitry Rozhkov

On a build host not having libglib-2.0 installed compiling pango
fails with the error message

./gen-all-unicode: error while loading shared libraries: libglib-2.0.so.0: 
cannot open shared object file: No such file or directory

The executable doesn't have RPATH set to the library installed in
the native sysroot.

The fix sets RPATH.

Signed-off-by: Dmitry Rozhkov 
---
 meta/recipes-graphics/pango/pango_1.40.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/pango/pango_1.40.1.bb 
b/meta/recipes-graphics/pango/pango_1.40.1.bb
index 6e1e6c9..60288a1 100644
--- a/meta/recipes-graphics/pango/pango_1.40.1.bb
+++ b/meta/recipes-graphics/pango/pango_1.40.1.bb
@@ -36,7 +36,7 @@ LIBV = "1.8.0"
 # This binary needs to be compiled for the host architecture.  This isn't 
pretty!
 do_compile_prepend_class-target () {
if ${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 'true', 'false', 
d)}; then
-   make CC="${BUILD_CC}" CFLAGS="" LDFLAGS="" 
AM_CPPFLAGS="$(pkg-config-native --cflags glib-2.0)" 
gen_all_unicode_LDADD="$(pkg-config-native --libs glib-2.0)" -C ${B}/tests 
gen-all-unicode
+   make CC="${BUILD_CC}" CFLAGS="" LDFLAGS="${BUILD_LDFLAGS}" 
AM_CPPFLAGS="$(pkg-config-native --cflags glib-2.0)" 
gen_all_unicode_LDADD="$(pkg-config-native --libs glib-2.0)" -C ${B}/tests 
gen-all-unicode
fi
 }
 
-- 
2.5.5

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

Re: [OE-core] [PATCH 01/42] gcc: Add gcc6 recipes

2016-05-31 Thread Jussi Kukkonen

On 11 May 2016 at 20:35, Khem Raj  wrote:

> +#BASEURI ?= "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2"
> +BASEURI ?= "git://
> github.com/gcc-mirror/gcc;branch=gcc-6-branch;protocol=git"
>

I guess this is where git2_github.com.gcc-mirror.gcc.tar.gz download comes
from? It increased the size of my downloads-directory by >30% -- and I must
have quite a bit of old junk in that directory already.

Is there no other solution to this than a 2.5G git copy (honest question, I
don't know gcc)?

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

[OE-core] [PATCH v3] linux-dtb.inc: Support for .dtbo files for dtb overlays

2016-05-31 Thread Herve Jourdain

Signed-off-by: Herve Jourdain 
---
 meta/recipes-kernel/linux/linux-dtb.inc | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-dtb.inc 
b/meta/recipes-kernel/linux/linux-dtb.inc
index 74f5ef8..8528d64 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -33,12 +33,13 @@ do_compile_append() {
 do_install_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
-   DTB_BASE_NAME=`basename ${DTB} .dtb`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
-   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -46,7 +47,8 @@ do_install_append() {
 do_deploy_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
-   DTB_BASE_NAME=`basename ${DTB} .dtb`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
base_name=${type}"-"${KERNEL_IMAGE_BASE_NAME}
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
@@ -54,8 +56,8 @@ do_deploy_append() {
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
install -d ${DEPLOYDIR}
-   install -m 0644 ${DTB_PATH} ${DEPLOYDIR}/${DTB_NAME}.dtb
-   ln -sf ${DTB_NAME}.dtb 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.dtb
+   install -m 0644 ${DTB_PATH} 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -65,9 +67,10 @@ pkg_postinst_kernel-devicetree () {
for DTB in ${KERNEL_DEVICETREE}; do
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_EXT=${DTB##*.}
DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print 
$1}'`
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   update-alternatives --install 
/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.dtb ${DTB_BASE_NAME}.dtb 
/boot/devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+   update-alternatives --install 
/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} ${DTB_BASE_NAME}.${DTB_EXT} 
/boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} ${KERNEL_PRIORITY} || true
done
done
 }
@@ -77,9 +80,10 @@ pkg_postrm_kernel-devicetree () {
for DTB in ${KERNEL_DEVICETREE}; do
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_EXT=${DTB##*.}
DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print 
$1}'`
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   update-alternatives --remove ${DTB_BASE_NAME}.dtb 
/boot/devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+   update-alternatives --remove 
${DTB_BASE_NAME}.${DTB_EXT} /boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} 
${KERNEL_PRIORITY} || true
done
done
 }
-- 
2.7.4

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

[OE-core] [PATCH v3] Support for .dtbo files for dtb overlays

2016-05-31 Thread Herve Jourdain

Sorry, sent to the wrong list initially, then with wrong header, so updating 
header...

v3: rebased

Recent kernels tend to use .dtbo files for device tree overlays, instead of 
.dtb before.
.dtb are still used, but only for the "real" device trees (not the overlays).

On some platforms (meta-raspberrypi for instance), recent firmware only loads 
.dtbo files for overlays.

This patch tries to address this issue, while not breaking support for .dtb 
overlays.
It allows the installation/deployment of both .dtb and .dtbo files, for device 
trees and overlays.

This is in line with the behavior of kernels 4.4.6+

Herve Jourdain (1):
  linux-dtb.inc: Support for .dtbo files for dtb overlays

 meta/recipes-kernel/linux/linux-dtb.inc | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

-- 
2.7.4

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

[OE-core] [yocto][PATCH v3] Support for .dtbo files for dtb overlays

2016-05-31 Thread Herve Jourdain

v3: rebased
Recent kernels tend to use .dtbo files for device tree overlays, instead of 
.dtb before.
.dtb are still used, but only for the "real" device trees (not the overlays).

On some platforms (meta-raspberrypi for instance), recent firmware only loads 
.dtbo files for overlays.

This patch tries to address this issue, while not breaking support for .dtb 
overlays.
It allows the installation/deployment of both .dtb and .dtbo files, for device 
trees and overlays.

This is in line with the behavior of kernels 4.4.6+

Herve Jourdain (1):
  linux-dtb.inc: Support for .dtbo files for dtb overlays

 meta/recipes-kernel/linux/linux-dtb.inc | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

-- 
2.7.4

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

[OE-core] [yocto][PATCH v3] linux-dtb.inc: Support for .dtbo files for dtb overlays

2016-05-31 Thread Herve Jourdain

Signed-off-by: Herve Jourdain 
---
 meta/recipes-kernel/linux/linux-dtb.inc | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-dtb.inc 
b/meta/recipes-kernel/linux/linux-dtb.inc
index 74f5ef8..8528d64 100644
--- a/meta/recipes-kernel/linux/linux-dtb.inc
+++ b/meta/recipes-kernel/linux/linux-dtb.inc
@@ -33,12 +33,13 @@ do_compile_append() {
 do_install_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
-   DTB_BASE_NAME=`basename ${DTB} .dtb`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
-   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.dtb
+   install -m 0644 ${DTB_PATH} 
${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -46,7 +47,8 @@ do_install_append() {
 do_deploy_append() {
for DTB in ${KERNEL_DEVICETREE}; do
DTB=`normalize_dtb "${DTB}"`
-   DTB_BASE_NAME=`basename ${DTB} .dtb`
+   DTB_EXT=${DTB##*.}
+   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
base_name=${type}"-"${KERNEL_IMAGE_BASE_NAME}
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
@@ -54,8 +56,8 @@ do_deploy_append() {
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
install -d ${DEPLOYDIR}
-   install -m 0644 ${DTB_PATH} ${DEPLOYDIR}/${DTB_NAME}.dtb
-   ln -sf ${DTB_NAME}.dtb 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.dtb
+   install -m 0644 ${DTB_PATH} 
${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
+   ln -sf ${DTB_NAME}.${DTB_EXT} 
${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
done
done
 }
@@ -65,9 +67,10 @@ pkg_postinst_kernel-devicetree () {
for DTB in ${KERNEL_DEVICETREE}; do
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_EXT=${DTB##*.}
DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print 
$1}'`
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   update-alternatives --install 
/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.dtb ${DTB_BASE_NAME}.dtb 
/boot/devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+   update-alternatives --install 
/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} ${DTB_BASE_NAME}.${DTB_EXT} 
/boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} ${KERNEL_PRIORITY} || true
done
done
 }
@@ -77,9 +80,10 @@ pkg_postrm_kernel-devicetree () {
for DTB in ${KERNEL_DEVICETREE}; do
for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
+   DTB_EXT=${DTB##*.}
DTB_BASE_NAME=`basename ${DTB} | awk -F "." '{print 
$1}'`
DTB_SYMLINK_NAME=`echo ${symlink_name} | sed 
"s/${MACHINE}/${DTB_BASE_NAME}/g"`
-   update-alternatives --remove ${DTB_BASE_NAME}.dtb 
/boot/devicetree-${DTB_SYMLINK_NAME}.dtb ${KERNEL_PRIORITY} || true
+   update-alternatives --remove 
${DTB_BASE_NAME}.${DTB_EXT} /boot/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT} 
${KERNEL_PRIORITY} || true
done
done
 }
-- 
2.7.4

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

Re: [OE-core] [PATCH 00/45] Move recipes to use Python 3 whenever possible

2016-05-31 Thread Richard Purdie

On Tue, 2016-05-24 at 14:53 +0300, Alexander Kanavin wrote:
> This patchset updates recipes to use Python 3 whenever possible. A
> few items
> cannot be moved at the moment for various reasons, here they are:

I put this through a round of testing on the autobuilder overnight.

I just replied to Maxin about the gst-plugins-bad/bluez issue, the
world build also is a bit of a mess:

https://autobuilder.yoctoproject.org/main/builders/nightly-world-lsb/bu
ilds/528/steps/BuildImages/logs/stdio

python3-numpy looks like it can't find various symbols it thinks it
should be able to.

There are more gdbus-codegen issues - perhaps that isn't bluez but
something else causing them? (triggered gtk3+ and libsecret to fail
too) Since various pieces did build is this a dependency issue?

python3-dbus doesn't build on x32:

https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/7
98/steps/BuildImages/logs/stdio

Cheers,

Richard

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

Re: [OE-core] [PATCH 2/2] bluez5: update to 5.40

2016-05-31 Thread Richard Purdie

On Mon, 2016-05-30 at 18:20 +0300, Maxin B. John wrote:
> 5.39 -> 5.40
> 
> Signed-off-by: Maxin B. John 
> ---
>  meta/recipes-connectivity/bluez5/{bluez5_5.39.bb => bluez5_5.40.bb}
> | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-connectivity/bluez5/{bluez5_5.39.bb =>
> bluez5_5.40.bb} (89%)

I had this in master-next and suspect it caused:

https://autobuilder.yoctoproject.org/main/builders/nightly-mips64/build
s/448/steps/BuildImages/logs/stdio

https://autobuilder.yoctoproject.org/main/builders/nightly-qa-pam/build
s/800/steps/BuildImages/logs/stdio

and the world targets also showed some issues. There were other changes
mixed in (particularly python3) and some builds succeeded so it could
also be some kind of dependency race.

Cheers,

Richard

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

[OE-core] [PATCH] distro_check.py: Don't mix tabs and spaces

2016-05-31 Thread Jussi Kukkonen

Signed-off-by: Jussi Kukkonen 
---

This is needed by python3, applies to both master and python3 branches.


 meta/lib/oe/distro_check.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/distro_check.py b/meta/lib/oe/distro_check.py
index 8655a6f..3d4a59b 100644
--- a/meta/lib/oe/distro_check.py
+++ b/meta/lib/oe/distro_check.py
@@ -357,8 +357,8 @@ def compare_in_distro_packages_list(distro_check_dir, d):
 
 
 if tmp != None:
-   list = tmp.split(' ')
-   for item in list:
+list = tmp.split(' ')
+for item in list:
 matching_distros.append(item)
 bb.note("Matching: %s" % matching_distros)
 return matching_distros
-- 
2.1.4

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

Re: [OE-core] [PATCH v2 1/1] linux-firmware: remove hard-coded paths

2016-05-31 Thread Ian Ray

On Fri, Jan 08, 2016 at 09:28:51AM +0200, Ian Ray wrote:
> The recipe uses hard-coded paths (specifically /lib) in do_install
> and in FILES, however on a merged /usr system this directory might
> not exist.  Prefer nonarch_base_libdir.

There were no comments on this?

There was quite a lot of discussion in the v1 patch thread, but
this patch was revised based on Phil's comments[*] and as such
it seems like a good first step.

[*] 
http://lists.openembedded.org/pipermail/openembedded-core/2016-January/114861.html

Thanks,
Ian

> Signed-off-by: Ian Ray 
> ---
>  .../linux-firmware/linux-firmware_git.bb   | 134 
> ++---
>  1 file changed, 67 insertions(+), 67 deletions(-)
> 
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
> b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> index 0878ab1..a61d894 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
> @@ -141,24 +141,24 @@ do_compile() {
>  }
>  
>  do_install() {
> - install -d  ${D}/lib/firmware/
> - cp -r * ${D}/lib/firmware/
> + install -d  ${D}${nonarch_base_libdir}/firmware/
> + cp -r * ${D}${nonarch_base_libdir}/firmware/
>  
>   # Avoid Makefile to be deployed
> - rm ${D}/lib/firmware/Makefile
> + rm ${D}${nonarch_base_libdir}/firmware/Makefile
>  
>   # Remove unbuild firmware which needs cmake and bash
> - rm ${D}/lib/firmware/carl9170fw -rf
> + rm ${D}${nonarch_base_libdir}/firmware/carl9170fw -rf
>  
>   # Remove pointless bash script
> - rm ${D}/lib/firmware/configure
> + rm ${D}${nonarch_base_libdir}/firmware/configure
>  
>   # Libertas sd8686
> - ln -sf libertas/sd8686_v9.bin ${D}/lib/firmware/sd8686.bin
> - ln -sf libertas/sd8686_v9_helper.bin ${D}/lib/firmware/sd8686_helper.bin
> + ln -sf libertas/sd8686_v9.bin 
> ${D}${nonarch_base_libdir}/firmware/sd8686.bin
> + ln -sf libertas/sd8686_v9_helper.bin 
> ${D}${nonarch_base_libdir}/firmware/sd8686_helper.bin
>  
>   # fixup wl12xx location, after 2.6.37 the kernel searches a different 
> location for it
> - ( cd ${D}/lib/firmware ; ln -sf ti-connectivity/* . )
> + ( cd ${D}${nonarch_base_libdir}/firmware ; ln -sf ti-connectivity/* . )
>  }
>  
>  
> @@ -188,21 +188,21 @@ LICENSE_${PN}-ar3k = "Firmware-atheros_firmware"
>  LICENSE_${PN}-ath6k = "Firmware-atheros_firmware"
>  LICENSE_${PN}-ath9k = "Firmware-atheros_firmware"
>  
> -FILES_${PN}-atheros-license = "/lib/firmware/LICENCE.atheros_firmware"
> +FILES_${PN}-atheros-license = 
> "${nonarch_base_libdir}/firmware/LICENCE.atheros_firmware"
>  FILES_${PN}-ar9170 = " \
> -  /lib/firmware/ar9170*.fw \
> +  ${nonarch_base_libdir}/firmware/ar9170*.fw \
>  "
>  FILES_${PN}-ar3k = " \
> -  /lib/firmware/ar3k \
> +  ${nonarch_base_libdir}/firmware/ar3k \
>  "
>  FILES_${PN}-ath6k = " \
> -  /lib/firmware/ath6k \
> +  ${nonarch_base_libdir}/firmware/ath6k \
>  "
>  FILES_${PN}-ath9k = " \
> -  /lib/firmware/ar9271.fw \
> -  /lib/firmware/ar7010*.fw \
> -  /lib/firmware/htc_9271.fw \
> -  /lib/firmware/htc_7010.fw \
> +  ${nonarch_base_libdir}/firmware/ar9271.fw \
> +  ${nonarch_base_libdir}/firmware/ar7010*.fw \
> +  ${nonarch_base_libdir}/firmware/htc_9271.fw \
> +  ${nonarch_base_libdir}/firmware/htc_7010.fw \
>  "
>  
>  RDEPENDS_${PN}-ar9170 += "${PN}-atheros-license"
> @@ -213,9 +213,9 @@ RDEPENDS_${PN}-ath9k += "${PN}-atheros-license"
>  # For ralink
>  LICENSE_${PN}-ralink = "Firmware-ralink-firmware"
>  
> -FILES_${PN}-ralink-license = "/lib/firmware/LICENCE.ralink-firmware.txt"
> +FILES_${PN}-ralink-license = 
> "${nonarch_base_libdir}/firmware/LICENCE.ralink-firmware.txt"
>  FILES_${PN}-ralink = " \
> -  /lib/firmware/rt*.bin \
> +  ${nonarch_base_libdir}/firmware/rt*.bin \
>  "
>  
>  RDEPENDS_${PN}-ralink += "${PN}-ralink-license"
> @@ -223,9 +223,9 @@ RDEPENDS_${PN}-ralink += "${PN}-ralink-license"
>  # For radeon
>  LICENSE_${PN}-radeon = "Firmware-radeon"
>  
> -FILES_${PN}-radeon-license = "/lib/firmware/LICENSE.radeon"
> +FILES_${PN}-radeon-license = "${nonarch_base_libdir}/firmware/LICENSE.radeon"
>  FILES_${PN}-radeon = " \
> -  /lib/firmware/radeon \
> +  ${nonarch_base_libdir}/firmware/radeon \
>  "
>  
>  RDEPENDS_${PN}-radeon += "${PN}-radeon-license"
> @@ -235,16 +235,16 @@ LICENSE_${PN}-sd8686 = "Firmware-Marvell"
>  LICENSE_${PN}-sd8787 = "Firmware-Marvell"
>  LICENSE_${PN}-sd8797 = "Firmware-Marvell"
>  
> -FILES_${PN}-marvell-license = "/lib/firmware/LICENCE.Marvell"
> +FILES_${PN}-marvell-license = 
> "${nonarch_base_libdir}/firmware/LICENCE.Marvell"
>  FILES_${PN}-sd8686 = " \
> -  /lib/firmware/libertas/sd8686_v9* \
> -  /lib/firmware/sd8686* \
> +  ${nonarch_base_libdir}/firmware/libertas/sd8686_v9* \
> +  ${nonarch_base_libdir}/firmware/sd8686* \
>  "
>  FILES_${PN}-sd8787 = " \
> -  /lib/firmware/mrvl/sd8787_uapsta.bin \
> +

Re: [OE-core] [PATCH 01/42] gcc: Add gcc6 recipes

Re: [OE-core] [PATCH 01/42] gcc: Add gcc6 recipes

Re: [OE-core] [PATCH 1/1] tcl: Only set BINCONFIG_GLOB for target builds

[OE-core] [PATCHv3] systemd: allow add users as a rootfs postprocess cmd

[OE-core] [PATCHv3] systemd: allow add users as a rootfs postprocess cmd

[OE-core] [PATCHv2] systemd: allow add users as a rootfs postprocess cmd

[OE-core] [PATCHv2] systemd: allow add users as a rootfs postprocess cmd

[OE-core] [PATCH] systemd: allow add users as a rootfs postprocess cmd

Re: [OE-core] Wic and "live" images

Re: [OE-core] Wic and "live" images

[OE-core] [PATCH] openssl: fix the dangling libcrypto.a symlink

Re: [OE-core] Wic and "live" images

Re: [OE-core] Wic and "live" images

Re: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

Re: [OE-core] [PATCH] perl-ptest.inc: fix tar call to prevent objcopy failure

Re: [OE-core] [PATCH 1/2 v4] kernel: Add KERNEL_IMAGETYPES to build multi types kernel at one time

Re: [OE-core] [jethro][PATCH] perl: reorder tar arguments in do_install_ptest()

[OE-core] [jethro][PATCH] perl: reorder tar arguments in do_install_ptest()

Re: [OE-core] [PATCH 2/2] bluez5: update to 5.40

[OE-core] [PATCH 1/1] tcl: Only set BINCONFIG_GLOB for target builds

[OE-core] [PATCH 0/1] Correct tclConfig.sh in the sysroots

Re: [OE-core] [PATCHv2 05/16] tcl: Use SYSROOT_DIRS to add dirs to stage in sysroot

[OE-core] [PATCH] pango_1.40.1.bb: Fix compilation error

Re: [OE-core] [PATCH 01/42] gcc: Add gcc6 recipes

[OE-core] [PATCH v3] linux-dtb.inc: Support for .dtbo files for dtb overlays

[OE-core] [PATCH v3] Support for .dtbo files for dtb overlays

[OE-core] [yocto][PATCH v3] Support for .dtbo files for dtb overlays

[OE-core] [yocto][PATCH v3] linux-dtb.inc: Support for .dtbo files for dtb overlays

Re: [OE-core] [PATCH 00/45] Move recipes to use Python 3 whenever possible

Re: [OE-core] [PATCH 2/2] bluez5: update to 5.40

[OE-core] [PATCH] distro_check.py: Don't mix tabs and spaces

Re: [OE-core] [PATCH v2 1/1] linux-firmware: remove hard-coded paths

32 matches

Site Navigation

Mail list logo

Footer information