Re: [OE-core] [v2 PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling

2013-09-27 Thread Andrea Adami 
On Sat, Aug 24, 2013 at 7:15 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 On Thu, 2013-08-22 at 18:04 -0500, Jason Wessel wrote:
 This patch aims to fix the following two cases for the INITRAMFS generation.
   1) Allow an image recipe to specify a paired INITRAMFS recipe such
  as core-image-minimal-initramfs.  This allows building a base
  image which always generates the needed initramfs image in one step
   2) Allow building a single binary which contains a kernel and
  the initramfs.

 A key requirement of the initramfs is to be able to add kernel
 modules.  The current implementation of the INITRAMFS_IMAGE variable
 has a circular dependency when using kernel modules in the initramfs
 image.bb file that is caused by kernel.bbclass trying to build the
 initramfs before the kernel's do_install rule.

 The solution for this problem is to have the kernel's
 do_bundle_initramfs_image task depend on the do_rootfs from the
 INITRAMFS_IMAGE and not some intermediate point.  The image.bbclass
 will also sets up dependencies to make the initramfs creation task run
 last.

 The code to bundle the kernel and initramfs together has been added.
 At a high level, all it is doing is invoking a second compilation of
 the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
 to the generated initramfs from the image recipe.

 [YOCTO #4072]

 Signed-off-by: Jason Wessel jason.wes...@windriver.com
 Acked-by: Bruce Ashfield bruce.ashfi...@windriver.com

 I have a couple of things I'd really like to see get resolved here. One
 is below, the other is I'm worried about the packaged output differences
 since we can package the kernel into a package file and now its going to
 be different.

 I appreciate its a hard problem to solve but not impossible. Basically
 we move the package generation for that single package into a separate
 recipe and have it depend on the bundling task if/as/when needed. The
 bundle task stashes the kernel in the sysroot, the other recipe simply
 packages it. Its a little bit of a dance but should ensure we get
 everything consistent.


 ---
  meta/classes/image.bbclass  |   12 ++
  meta/classes/kernel.bbclass |   96 
 +--
  meta/conf/local.conf.sample |   20 +
  3 files changed, 116 insertions(+), 12 deletions(-)

 diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
 index 909702a..23967ec 100644
 --- a/meta/classes/image.bbclass
 +++ b/meta/classes/image.bbclass
 @@ -130,6 +130,10 @@ python () {
  d.setVar('MULTILIB_VENDORS', ml_vendor_list)

  check_image_features(d)
 +initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or 
 +if initramfs_image != :
 +d.appendVarFlag('do_build', 'depends',  %s:do_bundle_initramfs %  
 d.getVar('PN', True))
 +d.appendVarFlag('do_bundle_initramfs', 'depends',  %s:do_rootfs % 
 initramfs_image)
  }

  #
 @@ -629,3 +633,11 @@ do_package_write_deb[noexec] = 1
  do_package_write_rpm[noexec] = 1

  addtask rootfs before do_build
 +# Allow the kernel to be repacked with the initramfs and boot image file as 
 a single file
 +do_bundle_initramfs[depends] += virtual/kernel:do_bundle_initramfs
 +do_bundle_initramfs[nostamp] = 1
 +do_bundle_initramfs[noexec] = 1
 +do_bundle_initramfs () {
 + :
 +}
 +addtask bundle_initramfs after do_rootfs
 diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
 index e039dfc..8cf66ce 100644
 --- a/meta/classes/kernel.bbclass
 +++ b/meta/classes/kernel.bbclass
 @@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = 1
  KERNEL_IMAGETYPE ?= zImage
  INITRAMFS_IMAGE ?= 
  INITRAMFS_TASK ?= 
 +INITRAMFS_IMAGE_BUNDLE ?= 

  python __anonymous () {
  kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
 @@ -19,7 +20,15 @@ python __anonymous () {

  image = d.getVar('INITRAMFS_IMAGE', True)
  if image:
 -d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
 +d.appendVarFlag('do_bundle_initramfs', 'depends', ' 
 ${INITRAMFS_IMAGE}:do_rootfs')
 +
 +# NOTE: setting INITRAMFS_TASK is for backward compatibility
 +#   The preferred method is to set INITRAMFS_IMAGE, because
 +#   this INITRAMFS_TASK has circular dependency problems
 +#   if the initramfs requires kernel modules
 +image_task = d.getVar('INITRAMFS_TASK', True)
 +if image_task:
 +d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
  }

  inherit kernel-arch deploy
 @@ -72,9 +81,82 @@ KERNEL_SRC_PATH = /usr/src/kernel

  KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:] == .gz else 
 s)(d.getVar('KERNEL_IMAGETYPE', True))}

 +copy_initramfs() {
 + echo Copying initramfs into ./usr ...
 + # Find and use the first initramfs image archive type we find
 + rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
 + for img in cpio.gz cpio.lzo cpio.lzma cpio.xz; do
 + if [ -e 
 ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.$img ];

[OE-core] [PATCH] nativesdk-packagegroup-sdk-host: Add nativesdk-makedevs

2013-09-27 Thread David Nyström 
Add makedevs to SDK, to allow simple /dev/ population.

Signed-off-by: David Nyström david.nyst...@enea.com
---
 meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb 
b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
index 95f98c8..e298ff4 100644
--- a/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
+++ b/meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb
@@ -21,6 +21,7 @@ RDEPENDS_${PN} = \
 nativesdk-autoconf \
 nativesdk-automake \
 nativesdk-shadow \
+nativesdk-makedevs \
 
 
 RDEPENDS_${PN}_darwin = \
-- 
1.8.3.2

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

Re: [OE-core] [v2 PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling

2013-09-27 Thread Richard Purdie 
On Fri, 2013-09-27 at 10:07 +0200, Andrea Adami wrote:
 On Sat, Aug 24, 2013 at 7:15 PM, Richard Purdie
 richard.pur...@linuxfoundation.org wrote:
  On Thu, 2013-08-22 at 18:04 -0500, Jason Wessel wrote:
  This patch aims to fix the following two cases for the INITRAMFS 
  generation.
1) Allow an image recipe to specify a paired INITRAMFS recipe such
   as core-image-minimal-initramfs.  This allows building a base
   image which always generates the needed initramfs image in one step
2) Allow building a single binary which contains a kernel and
   the initramfs.
 
  A key requirement of the initramfs is to be able to add kernel
  modules.  The current implementation of the INITRAMFS_IMAGE variable
  has a circular dependency when using kernel modules in the initramfs
  image.bb file that is caused by kernel.bbclass trying to build the
  initramfs before the kernel's do_install rule.
 
  The solution for this problem is to have the kernel's
  do_bundle_initramfs_image task depend on the do_rootfs from the
  INITRAMFS_IMAGE and not some intermediate point.  The image.bbclass
  will also sets up dependencies to make the initramfs creation task run
  last.
 
  The code to bundle the kernel and initramfs together has been added.
  At a high level, all it is doing is invoking a second compilation of
  the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
  to the generated initramfs from the image recipe.
 
  [YOCTO #4072]
 
  Signed-off-by: Jason Wessel jason.wes...@windriver.com
  Acked-by: Bruce Ashfield bruce.ashfi...@windriver.com
 
  I have a couple of things I'd really like to see get resolved here. One
  is below, the other is I'm worried about the packaged output differences
  since we can package the kernel into a package file and now its going to
  be different.
 
  I appreciate its a hard problem to solve but not impossible. Basically
  we move the package generation for that single package into a separate
  recipe and have it depend on the bundling task if/as/when needed. The
  bundle task stashes the kernel in the sysroot, the other recipe simply
  packages it. Its a little bit of a dance but should ensure we get
  everything consistent.
 
 
  ---
   meta/classes/image.bbclass  |   12 ++
   meta/classes/kernel.bbclass |   96 
  +--
   meta/conf/local.conf.sample |   20 +
   3 files changed, 116 insertions(+), 12 deletions(-)
 
  diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
  index 909702a..23967ec 100644
  --- a/meta/classes/image.bbclass
  +++ b/meta/classes/image.bbclass
  @@ -130,6 +130,10 @@ python () {
   d.setVar('MULTILIB_VENDORS', ml_vendor_list)
 
   check_image_features(d)
  +initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or 
  +if initramfs_image != :
  +d.appendVarFlag('do_build', 'depends',  %s:do_bundle_initramfs 
  %  d.getVar('PN', True))
  +d.appendVarFlag('do_bundle_initramfs', 'depends',  %s:do_rootfs 
  % initramfs_image)
   }
 
   #
  @@ -629,3 +633,11 @@ do_package_write_deb[noexec] = 1
   do_package_write_rpm[noexec] = 1
 
   addtask rootfs before do_build
  +# Allow the kernel to be repacked with the initramfs and boot image file 
  as a single file
  +do_bundle_initramfs[depends] += virtual/kernel:do_bundle_initramfs
  +do_bundle_initramfs[nostamp] = 1
  +do_bundle_initramfs[noexec] = 1
  +do_bundle_initramfs () {
  + :
  +}
  +addtask bundle_initramfs after do_rootfs
  diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
  index e039dfc..8cf66ce 100644
  --- a/meta/classes/kernel.bbclass
  +++ b/meta/classes/kernel.bbclass
  @@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = 1
   KERNEL_IMAGETYPE ?= zImage
   INITRAMFS_IMAGE ?= 
   INITRAMFS_TASK ?= 
  +INITRAMFS_IMAGE_BUNDLE ?= 
 
   python __anonymous () {
   kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
  @@ -19,7 +20,15 @@ python __anonymous () {
 
   image = d.getVar('INITRAMFS_IMAGE', True)
   if image:
  -d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
  +d.appendVarFlag('do_bundle_initramfs', 'depends', ' 
  ${INITRAMFS_IMAGE}:do_rootfs')
  +
  +# NOTE: setting INITRAMFS_TASK is for backward compatibility
  +#   The preferred method is to set INITRAMFS_IMAGE, because
  +#   this INITRAMFS_TASK has circular dependency problems
  +#   if the initramfs requires kernel modules
  +image_task = d.getVar('INITRAMFS_TASK', True)
  +if image_task:
  +d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
   }
 
   inherit kernel-arch deploy
  @@ -72,9 +81,82 @@ KERNEL_SRC_PATH = /usr/src/kernel
 
   KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:] == .gz else 
  s)(d.getVar('KERNEL_IMAGETYPE', True))}
 
  +copy_initramfs() {
  + echo Copying initramfs into ./usr ...
  + # Find and use the first initramfs image archive type we find
  + rm -f

Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED

2013-09-27 Thread Richard Purdie 
On Thu, 2013-09-26 at 18:40 -0400, Denys Dmytriyenko wrote:
 On Tue, Feb 12, 2013 at 01:36:44PM -0600, Jason Wessel wrote:
  If you never use sstate and always build everything from scratch you
  will never see this problem.  However, if you use sstate and build
  directories that last a long time eventually you can end up with the
  scenario where libtool gets a hard coded path in it for sed, and sed
  may not exist.  The reason you don't see this problem to often if you
  generally build from scratch is that libtool builds before sed and
  will pickup the host's /bin/sed.
  
  The way to reproduce the issue is:
  
  bitbake some_image
  bitbake -c cleansstate libtool-native
  bitbake sed-native
  bitbake libtool-native
  bitbake -c clean sed-native
  bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE
  
  In my case I used modphp, which doesn't exist in the oe-core. You will
  end up with a strange looking error like:
  
  | make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
  | 
  /opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
   line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: No 
  such file or directory
 
 Sorry for bringing up this old thread. I'm seeing these and similar errors 
 now 
 (nothing really changed in my setup, but some race got them exposed).
 
 I do see that the proposed patch got merged all the way back in February. But 
 looks like it wasn't enough.
 
 I've just seen this error about missing sysroots/x86_64-linux//bin/sed coming 
 from nativesdk-gettext compilation while calling i686-linux-libtool, i.e. the 
 nativesdk version of libtool. Should be easy to duplicate the below patch for 
 libtool from native to nativesdk recipe.
 
 And another error was from sysroots/x86_64-linux/usr/bin/opkg-build during 
 do_package_write of some other package. Should opkg-utils-native be patched 
 the same?

Was this in master with
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=32edeb391f2107bb66b361cdcd4b8d4447731c33
 applied?

Cheers,

Richard

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

[OE-core] [PATCH] native: Use a native site file and ensure the correct sed is used

2013-09-27 Thread Richard Purdie 
native recipes were not using the site files. There are some things we need
to correct such as not using the path to sed-native. This allows us
to deploy settings globally for all recipes rather than hacking around
then in individual recipes as libtool-native used to for sed.

This fixes a regression introduced by
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=32edeb391f2107bb66b361cdcd4b8d4447731c33

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 102dfb8..6704e66 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -54,7 +54,7 @@ DEPENDS_GETTEXT = gettext-native
 PTEST_ENABLED = 0
 
 # Don't use site files for native builds
-export CONFIG_SITE = 
+export CONFIG_SITE = ${COREBASE}/meta/site/native
 
 # set the compiler as well. It could have been set to something else
 export CC = ${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}
diff --git a/meta/site/native b/meta/site/native
new file mode 100644
index 000..7dfb1cb
--- /dev/null
+++ b/meta/site/native
@@ -0,0 +1 @@
+ac_cv_path_SED=sed


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

[OE-core] [PATCH] libtool: Don't patch generated files

2013-09-27 Thread Richard Purdie 
We wipe out and regenerate all configure files so there is no point in
patching them.

Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
diff --git a/meta/recipes-devtools/libtool/libtool/rename-with-sysroot.patch 
b/meta/recipes-devtools/libtool/libtool/rename-with-sysroot.patch
index 438c639..c3e3e86 100644
--- a/meta/recipes-devtools/libtool/libtool/rename-with-sysroot.patch
+++ b/meta/recipes-devtools/libtool/libtool/rename-with-sysroot.patch
@@ -10,126 +10,6 @@ 
http://lists.gnu.org/archive/html/libtool/2010-10/msg00048.html
 
 -Khem Raj raj.k...@gmail.com
 
-Index: libtool-2.4.2/configure
-===
 libtool-2.4.2.orig/configure
-+++ libtool-2.4.2/configure
-@@ -795,7 +795,7 @@ enable_static
- with_pic
- enable_fast_install
- with_gnu_ld
--with_sysroot
-+with_libtool_sysroot
- enable_libtool_lock
- '
-   ac_precious_vars='build_alias
-@@ -1451,7 +1451,7 @@ Optional Packages:
-   --with-pic[=PKGS]   try to use only PIC/non-PIC objects [default=use
-   both]
-   --with-gnu-ld   assume the C compiler uses GNU ld [default=no]
--  --with-sysroot=DIR Search for dependent libraries within DIR
-+  --with-libtool-sysroot=DIR Search for dependent libraries within DIR
- (or the compiler's sysroot if not specified).
- 
- Some influential environment variables:
-@@ -6804,29 +6804,29 @@ fi
- { $as_echo $as_me:${as_lineno-$LINENO}: checking for sysroot 5
- $as_echo_n checking for sysroot...  6; }
- 
--# Check whether --with-sysroot was given.
--if test ${with_sysroot+set} = set; then :
--  withval=$with_sysroot;
-+# Check whether --with-libtool-sysroot was given.
-+if test ${with_libtool_sysroot+set} = set; then :
-+  withval=$with_libtool_sysroot;
- else
--  with_sysroot=no
-+  with_libtool_sysroot=no
- fi
- 
- 
- lt_sysroot=
--case ${with_sysroot} in #(
-+case ${with_libtool_sysroot} in #(
-  yes)
-if test $GCC = yes; then
-  lt_sysroot=`$CC --print-sysroot 2/dev/null`
-fi
-;; #(
-  /*)
--   lt_sysroot=`echo $with_sysroot | sed -e $sed_quote_subst`
-+   lt_sysroot=`echo $with_libtool_sysroot | sed -e $sed_quote_subst`
-;; #(
-  no|'')
-;; #(
-  *)
--   { $as_echo $as_me:${as_lineno-$LINENO}: result: ${with_sysroot} 5
--$as_echo ${with_sysroot} 6; }
-+   { $as_echo $as_me:${as_lineno-$LINENO}: result: ${with_libtool_sysroot} 
5
-+$as_echo ${with_libtool_sysroot} 6; }
-as_fn_error $? The sysroot must be an absolute path. $LINENO 5
-;;
- esac
-Index: libtool-2.4.2/libltdl/configure
-===
 libtool-2.4.2.orig/libltdl/configure
-+++ libtool-2.4.2/libltdl/configure
-@@ -747,7 +747,7 @@ with_pic
- enable_fast_install
- enable_dependency_tracking
- with_gnu_ld
--with_sysroot
-+with_libtool_sysroot
- enable_libtool_lock
- enable_ltdl_install
- '
-@@ -1395,7 +1395,7 @@ Optional Packages:
-   --with-pic[=PKGS]   try to use only PIC/non-PIC objects [default=use
-   both]
-   --with-gnu-ld   assume the C compiler uses GNU ld [default=no]
--  --with-sysroot=DIR Search for dependent libraries within DIR
-+  --with-libtool-sysroot=DIR Search for dependent libraries within DIR
- (or the compiler's sysroot if not specified).
- 
- Some influential environment variables:
-@@ -6017,29 +6017,29 @@ fi
- { $as_echo $as_me:${as_lineno-$LINENO}: checking for sysroot 5
- $as_echo_n checking for sysroot...  6; }
- 
--# Check whether --with-sysroot was given.
--if test ${with_sysroot+set} = set; then :
--  withval=$with_sysroot;
-+# Check whether --with-libtool-sysroot was given.
-+if test ${with_libtool_sysroot+set} = set; then :
-+  withval=$with_libtool_sysroot;
- else
--  with_sysroot=no
-+  with_libtool_sysroot=no
- fi
- 
- 
- lt_sysroot=
--case ${with_sysroot} in #(
-+case ${with_libtool_sysroot} in #(
-  yes)
-if test $GCC = yes; then
-  lt_sysroot=`$CC --print-sysroot 2/dev/null`
-fi
-;; #(
-  /*)
--   lt_sysroot=`echo $with_sysroot | sed -e $sed_quote_subst`
-+   lt_sysroot=`echo $with_libtool_sysroot | sed -e $sed_quote_subst`
-;; #(
-  no|'')
-;; #(
-  *)
--   { $as_echo $as_me:${as_lineno-$LINENO}: result: ${with_sysroot} 5
--$as_echo ${with_sysroot} 6; }
-+   { $as_echo $as_me:${as_lineno-$LINENO}: result: ${with_libtool_sysroot} 
5
-+$as_echo ${with_libtool_sysroot} 6; }
-as_fn_error $? The sysroot must be an absolute path. $LINENO 5
-;;
- esac
 Index: libtool-2.4.2/libltdl/m4/libtool.m4
 ===
 --- libtool-2.4.2.orig/libltdl/m4/libtool.m4
@@ -168,486 +48,6 @@ Index: libtool-2.4.2/libltdl/m4/libtool.m4
 AC_MSG_ERROR([The sysroot must be an absolute path.])
 ;;
  esac
-Index: libtool-2.4.2/tests/cdemo/configure
-===
 libtool-2.4.2.orig/tests/cdemo/configure
-+++

Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED

2013-09-27 Thread Richard Purdie 
On Fri, 2013-09-27 at 10:20 +0100, Richard Purdie wrote:
 On Thu, 2013-09-26 at 18:40 -0400, Denys Dmytriyenko wrote:
  On Tue, Feb 12, 2013 at 01:36:44PM -0600, Jason Wessel wrote:
   If you never use sstate and always build everything from scratch you
   will never see this problem.  However, if you use sstate and build
   directories that last a long time eventually you can end up with the
   scenario where libtool gets a hard coded path in it for sed, and sed
   may not exist.  The reason you don't see this problem to often if you
   generally build from scratch is that libtool builds before sed and
   will pickup the host's /bin/sed.
   
   The way to reproduce the issue is:
   
   bitbake some_image
   bitbake -c cleansstate libtool-native
   bitbake sed-native
   bitbake libtool-native
   bitbake -c clean sed-native
   bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE
   
   In my case I used modphp, which doesn't exist in the oe-core. You will
   end up with a strange looking error like:
   
   | make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
   | 
   /opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: 
   No such file or directory
  
  Sorry for bringing up this old thread. I'm seeing these and similar errors 
  now 
  (nothing really changed in my setup, but some race got them exposed).
  
  I do see that the proposed patch got merged all the way back in February. 
  But 
  looks like it wasn't enough.
  
  I've just seen this error about missing sysroots/x86_64-linux//bin/sed 
  coming 
  from nativesdk-gettext compilation while calling i686-linux-libtool, i.e. 
  the 
  nativesdk version of libtool. Should be easy to duplicate the below patch 
  for 
  libtool from native to nativesdk recipe.
  
  And another error was from sysroots/x86_64-linux/usr/bin/opkg-build during 
  do_package_write of some other package. Should opkg-utils-native be patched 
  the same?
 
 Was this in master with
 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=32edeb391f2107bb66b361cdcd4b8d4447731c33
  applied?

To answer my own question, the above introduced a bug since I'd
forgotten native doesn't use the site files. It probably should use at
least a minimal one so I've sent out a patch for that.

Cheers,

Richard

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

Re: [OE-core] [v2 PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling

2013-09-27 Thread Andrea Adami 
On Fri, Sep 27, 2013 at 11:05 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
 On Fri, 2013-09-27 at 10:07 +0200, Andrea Adami wrote:
 On Sat, Aug 24, 2013 at 7:15 PM, Richard Purdie
 richard.pur...@linuxfoundation.org wrote:
  On Thu, 2013-08-22 at 18:04 -0500, Jason Wessel wrote:
  This patch aims to fix the following two cases for the INITRAMFS 
  generation.
1) Allow an image recipe to specify a paired INITRAMFS recipe such
   as core-image-minimal-initramfs.  This allows building a base
   image which always generates the needed initramfs image in one step
2) Allow building a single binary which contains a kernel and
   the initramfs.
 
  A key requirement of the initramfs is to be able to add kernel
  modules.  The current implementation of the INITRAMFS_IMAGE variable
  has a circular dependency when using kernel modules in the initramfs
  image.bb file that is caused by kernel.bbclass trying to build the
  initramfs before the kernel's do_install rule.
 
  The solution for this problem is to have the kernel's
  do_bundle_initramfs_image task depend on the do_rootfs from the
  INITRAMFS_IMAGE and not some intermediate point.  The image.bbclass
  will also sets up dependencies to make the initramfs creation task run
  last.
 
  The code to bundle the kernel and initramfs together has been added.
  At a high level, all it is doing is invoking a second compilation of
  the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
  to the generated initramfs from the image recipe.
 
  [YOCTO #4072]
 
  Signed-off-by: Jason Wessel jason.wes...@windriver.com
  Acked-by: Bruce Ashfield bruce.ashfi...@windriver.com
 
  I have a couple of things I'd really like to see get resolved here. One
  is below, the other is I'm worried about the packaged output differences
  since we can package the kernel into a package file and now its going to
  be different.
 
  I appreciate its a hard problem to solve but not impossible. Basically
  we move the package generation for that single package into a separate
  recipe and have it depend on the bundling task if/as/when needed. The
  bundle task stashes the kernel in the sysroot, the other recipe simply
  packages it. Its a little bit of a dance but should ensure we get
  everything consistent.
 
 
  ---
   meta/classes/image.bbclass  |   12 ++
   meta/classes/kernel.bbclass |   96 
  +--
   meta/conf/local.conf.sample |   20 +
   3 files changed, 116 insertions(+), 12 deletions(-)
 
  diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
  index 909702a..23967ec 100644
  --- a/meta/classes/image.bbclass
  +++ b/meta/classes/image.bbclass
  @@ -130,6 +130,10 @@ python () {
   d.setVar('MULTILIB_VENDORS', ml_vendor_list)
 
   check_image_features(d)
  +initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or 
  +if initramfs_image != :
  +d.appendVarFlag('do_build', 'depends',  %s:do_bundle_initramfs 
  %  d.getVar('PN', True))
  +d.appendVarFlag('do_bundle_initramfs', 'depends',  
  %s:do_rootfs % initramfs_image)
   }
 
   #
  @@ -629,3 +633,11 @@ do_package_write_deb[noexec] = 1
   do_package_write_rpm[noexec] = 1
 
   addtask rootfs before do_build
  +# Allow the kernel to be repacked with the initramfs and boot image file 
  as a single file
  +do_bundle_initramfs[depends] += virtual/kernel:do_bundle_initramfs
  +do_bundle_initramfs[nostamp] = 1
  +do_bundle_initramfs[noexec] = 1
  +do_bundle_initramfs () {
  + :
  +}
  +addtask bundle_initramfs after do_rootfs
  diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
  index e039dfc..8cf66ce 100644
  --- a/meta/classes/kernel.bbclass
  +++ b/meta/classes/kernel.bbclass
  @@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = 1
   KERNEL_IMAGETYPE ?= zImage
   INITRAMFS_IMAGE ?= 
   INITRAMFS_TASK ?= 
  +INITRAMFS_IMAGE_BUNDLE ?= 
 
   python __anonymous () {
   kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
  @@ -19,7 +20,15 @@ python __anonymous () {
 
   image = d.getVar('INITRAMFS_IMAGE', True)
   if image:
  -d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
  +d.appendVarFlag('do_bundle_initramfs', 'depends', ' 
  ${INITRAMFS_IMAGE}:do_rootfs')
  +
  +# NOTE: setting INITRAMFS_TASK is for backward compatibility
  +#   The preferred method is to set INITRAMFS_IMAGE, because
  +#   this INITRAMFS_TASK has circular dependency problems
  +#   if the initramfs requires kernel modules
  +image_task = d.getVar('INITRAMFS_TASK', True)
  +if image_task:
  +d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
   }
 
   inherit kernel-arch deploy
  @@ -72,9 +81,82 @@ KERNEL_SRC_PATH = /usr/src/kernel
 
   KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:] == .gz 
  else s)(d.getVar('KERNEL_IMAGETYPE', True))}
 
  +copy_initramfs() {
  + echo Copying initramfs into ./usr

Re: [OE-core] [PATCH] systemd-compat-units: do not create runlevel command

2013-09-27 Thread Burton, Ross 
On 27 September 2013 06:52,  rongqing...@windriver.com wrote:
 It seems strange that runlevel always returns 1, The comment says it is
 related to sysvinit, but if we enable systemd, sysvinit will not be
 installed. and we have created a link for runlevel to systemctl if
 systemd is installed.

Whoops, meant to fix that ages ago!

Acked-By: Ross Burton ross.bur...@intel.com.

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

[OE-core] [PATCH_V6] image types: split live into iso and hddimg

2013-09-27 Thread Valentin Popa 
Changes to split live into iso and hddimg without
adding a new image type class.
This patch has only a visible effect on HOB and solves
part 2 of #3197

[YOCTO #3197]

Signed-off-by: Valentin Popa valentin.p...@intel.com
---
 meta/classes/image.bbclass   | 12 +++-
 meta/classes/image_types.bbclass | 13 +
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 7650594..422a826 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -90,7 +90,17 @@ do_rootfs[depends] += makedevs-native:do_populate_sysroot 
virtual/fakeroot-nati
 do_rootfs[depends] += virtual/update-alternatives-native:do_populate_sysroot 
update-rc.d-native:do_populate_sysroot
 do_rootfs[recrdeptask] += do_packagedata
 
-IMAGE_TYPE_live = '${@base_contains(IMAGE_FSTYPES, live, live, empty, 
d)}'
+def build_live(d):
+if base_contains(IMAGE_FSTYPES, live, live, 0, d) == 0: # live 
is not set but hob might set iso or hddimg
+d.setVar('NOISO', base_contains('IMAGE_FSTYPES', iso, 0, 1, d))
+d.setVar('NOHDD', base_contains('IMAGE_FSTYPES', hddimg, 0, 1, 
d))
+if d.getVar('NOISO', True) == 0 or d.getVar('NOHDD', True) == 0:
+return live
+return empty
+return live
+
+IMAGE_TYPE_live = ${@build_live(d)}
+
 inherit image-${IMAGE_TYPE_live}
 IMAGE_TYPE_vmdk = '${@base_contains(IMAGE_FSTYPES, vmdk, vmdk, empty, 
d)}'
 inherit image-${IMAGE_TYPE_vmdk}
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 8c49169..9ead059 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -43,12 +43,17 @@ def get_imagecmds(d):
 if ext3 not in alltypes:
 alltypes.append(ext3)
 types.remove(vmdk)
-if live in types:
+if live in types or iso in types or hddimg in types:
 if ext3 not in types:
 types.append(ext3)
 if ext3 not in alltypes:
 alltypes.append(ext3)
-types.remove(live)
+if live in types:
+types.remove(live)
+if iso in types:
+types.remove(iso)
+if hddimg in types:
+types.remove(hddimg)
 
 if d.getVar('IMAGE_LINK_NAME', True):
 if d.getVar('RM_OLD_IMAGE', True) == 1:
@@ -115,7 +120,7 @@ def imagetypes_getdepends(d):
 deps = []
 ctypes = d.getVar('COMPRESSIONTYPES', True).split()
 for type in (d.getVar('IMAGE_FSTYPES', True) or ).split():
-if type == vmdk or type == live:
+if type == vmdk or type == live or type == iso or type == 
hddimg:
 type = ext3
 basetype = type
 for ctype in ctypes:
@@ -230,7 +235,7 @@ IMAGE_DEPENDS_ubi = mtd-utils-native
 IMAGE_DEPENDS_ubifs = mtd-utils-native
 
 # This variable is available to request which values are suitable for 
IMAGE_FSTYPES
-IMAGE_TYPES = jffs2 sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 ext3.gz 
ext2.lzma btrfs live squashfs squashfs-xz ubi ubifs tar tar.gz tar.bz2 tar.xz 
cpio cpio.gz cpio.xz cpio.lzma vmdk elf
+IMAGE_TYPES = jffs2 sum.jffs2 cramfs ext2 ext2.gz ext2.bz2 ext3 ext3.gz 
ext2.lzma btrfs iso hddimg squashfs squashfs-xz ubi ubifs tar tar.gz tar.bz2 
tar.xz cpio cpio.gz cpio.xz cpio.lzma vmdk elf
 
 COMPRESSIONTYPES = gz bz2 lzma xz
 COMPRESS_CMD_lzma = lzma -k -f -7 ${IMAGE_NAME}.rootfs.${type}
-- 
1.8.1.2

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

Re: [OE-core] [v2 PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling

2013-09-27 Thread Bruce Ashfield 

On 13-09-27 07:59 AM, Andrea Adami wrote:

On Fri, Sep 27, 2013 at 11:05 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:

On Fri, 2013-09-27 at 10:07 +0200, Andrea Adami wrote:

On Sat, Aug 24, 2013 at 7:15 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:

On Thu, 2013-08-22 at 18:04 -0500, Jason Wessel wrote:

This patch aims to fix the following two cases for the INITRAMFS generation.
   1) Allow an image recipe to specify a paired INITRAMFS recipe such
  as core-image-minimal-initramfs.  This allows building a base
  image which always generates the needed initramfs image in one step
   2) Allow building a single binary which contains a kernel and
  the initramfs.

A key requirement of the initramfs is to be able to add kernel
modules.  The current implementation of the INITRAMFS_IMAGE variable
has a circular dependency when using kernel modules in the initramfs
image.bb file that is caused by kernel.bbclass trying to build the
initramfs before the kernel's do_install rule.

The solution for this problem is to have the kernel's
do_bundle_initramfs_image task depend on the do_rootfs from the
INITRAMFS_IMAGE and not some intermediate point.  The image.bbclass
will also sets up dependencies to make the initramfs creation task run
last.

The code to bundle the kernel and initramfs together has been added.
At a high level, all it is doing is invoking a second compilation of
the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
to the generated initramfs from the image recipe.

[YOCTO #4072]

Signed-off-by: Jason Wessel jason.wes...@windriver.com
Acked-by: Bruce Ashfield bruce.ashfi...@windriver.com


I have a couple of things I'd really like to see get resolved here. One
is below, the other is I'm worried about the packaged output differences
since we can package the kernel into a package file and now its going to
be different.

I appreciate its a hard problem to solve but not impossible. Basically
we move the package generation for that single package into a separate
recipe and have it depend on the bundling task if/as/when needed. The
bundle task stashes the kernel in the sysroot, the other recipe simply
packages it. Its a little bit of a dance but should ensure we get
everything consistent.



---
  meta/classes/image.bbclass  |   12 ++
  meta/classes/kernel.bbclass |   96 +--
  meta/conf/local.conf.sample |   20 +
  3 files changed, 116 insertions(+), 12 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 909702a..23967ec 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -130,6 +130,10 @@ python () {
  d.setVar('MULTILIB_VENDORS', ml_vendor_list)

  check_image_features(d)
+initramfs_image = d.getVar('INITRAMFS_IMAGE', True) or 
+if initramfs_image != :
+d.appendVarFlag('do_build', 'depends',  %s:do_bundle_initramfs %  
d.getVar('PN', True))
+d.appendVarFlag('do_bundle_initramfs', 'depends',  %s:do_rootfs % 
initramfs_image)
  }

  #
@@ -629,3 +633,11 @@ do_package_write_deb[noexec] = 1
  do_package_write_rpm[noexec] = 1

  addtask rootfs before do_build
+# Allow the kernel to be repacked with the initramfs and boot image file as a 
single file
+do_bundle_initramfs[depends] += virtual/kernel:do_bundle_initramfs
+do_bundle_initramfs[nostamp] = 1
+do_bundle_initramfs[noexec] = 1
+do_bundle_initramfs () {
+ :
+}
+addtask bundle_initramfs after do_rootfs
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index e039dfc..8cf66ce 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -9,6 +9,7 @@ INHIBIT_DEFAULT_DEPS = 1
  KERNEL_IMAGETYPE ?= zImage
  INITRAMFS_IMAGE ?= 
  INITRAMFS_TASK ?= 
+INITRAMFS_IMAGE_BUNDLE ?= 

  python __anonymous () {
  kerneltype = d.getVar('KERNEL_IMAGETYPE', True) or ''
@@ -19,7 +20,15 @@ python __anonymous () {

  image = d.getVar('INITRAMFS_IMAGE', True)
  if image:
-d.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs')
+d.appendVarFlag('do_bundle_initramfs', 'depends', ' 
${INITRAMFS_IMAGE}:do_rootfs')
+
+# NOTE: setting INITRAMFS_TASK is for backward compatibility
+#   The preferred method is to set INITRAMFS_IMAGE, because
+#   this INITRAMFS_TASK has circular dependency problems
+#   if the initramfs requires kernel modules
+image_task = d.getVar('INITRAMFS_TASK', True)
+if image_task:
+d.appendVarFlag('do_configure', 'depends', ' ${INITRAMFS_TASK}')
  }

  inherit kernel-arch deploy
@@ -72,9 +81,82 @@ KERNEL_SRC_PATH = /usr/src/kernel

  KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:] == .gz else 
s)(d.getVar('KERNEL_IMAGETYPE', True))}

+copy_initramfs() {
+ echo Copying initramfs into ./usr ...
+ # Find and use the first initramfs image archive type we find
+ rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+ for img in

Re: [OE-core] [PATCH 1/3] wic: Initial code for wic (OpenEmbedded Image Creator)

2013-09-27 Thread Otavio Salvador 
Hello Tom,

On Thu, Sep 26, 2013 at 11:17 PM, Tom Zanussi
tom.zanu...@linux.intel.com wrote:
 Initial implementation of the 'wic' command.

 The 'wic' command generates partitioned images from existing
 OpenEmbedded build artifacts.  Image generation is driven by
 partitioning commands contained in an 'Openembedded kickstart' (.wks)
 file specified either directly on the command-line or as one of a
 selection of canned .wks files (see 'wic list images').  When applied
 to a given set of build artifacts, the result is an image or set of
 images that can be directly written onto media and used on a
 particular system.

 'wic' is based loosely on the 'mic' (Meego Image Creator) framework,
 but heavily modified to make direct use of OpenEmbedded build
 artifacts instead of package installation and configuration, things
 already incorporated int the OE artifacts.

 The name 'wic' comes from 'oeic' with the 'oe' diphthong promoted to
 the letter 'w', because 'oeic' is impossible to remember or pronounce.

 This covers the mechanics of invoking and providing help for the
 command and sub-commands; it contains hooks for future commits to
 connect with the actual functionality, once implemented.

 Help is integrated into the 'wic' command - see that for details on
 usage.

 Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com

Could you please elaborate why to make a new command instead of using
the class system?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] wic: Initial code for wic (OpenEmbedded Image Creator)

2013-09-27 Thread Tom Zanussi 
Hi Otavio,

On Fri, 2013-09-27 at 11:01 -0300, Otavio Salvador wrote:
 Hello Tom,
 
 On Thu, Sep 26, 2013 at 11:17 PM, Tom Zanussi
 tom.zanu...@linux.intel.com wrote:
  Initial implementation of the 'wic' command.
 
  The 'wic' command generates partitioned images from existing
  OpenEmbedded build artifacts.  Image generation is driven by
  partitioning commands contained in an 'Openembedded kickstart' (.wks)
  file specified either directly on the command-line or as one of a
  selection of canned .wks files (see 'wic list images').  When applied
  to a given set of build artifacts, the result is an image or set of
  images that can be directly written onto media and used on a
  particular system.
 
  'wic' is based loosely on the 'mic' (Meego Image Creator) framework,
  but heavily modified to make direct use of OpenEmbedded build
  artifacts instead of package installation and configuration, things
  already incorporated int the OE artifacts.
 
  The name 'wic' comes from 'oeic' with the 'oe' diphthong promoted to
  the letter 'w', because 'oeic' is impossible to remember or pronounce.
 
  This covers the mechanics of invoking and providing help for the
  command and sub-commands; it contains hooks for future commits to
  connect with the actual functionality, once implemented.
 
  Help is integrated into the 'wic' command - see that for details on
  usage.
 
  Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com
 
 Could you please elaborate why to make a new command instead of using
 the class system?
 

This isn't an either/or thing - the initial requirements were that the
overall deployment effort end up being something that would be usable
both from an external tool as well as from within the class system.

This just happens to be the initial (easier) part of that, the external
tool, and I expect in 1.6 to be doing a lot of the harder part,
integration with the build system.

The most important part, I think, is that this provides a high-level
user-oriented 'language' (the kickstart files) that users can use to
define custom images, rather than having to muck around in class files
or variable settings, or write specialized scripts such as mkefidisk.sh
for example.

Making that available from a standalone tool such as 'wic' is
straightforward, doing the same from within the build system will
require more thought and work, but that's what I'm hoping to do in
1.6...

Tom




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

Re: [OE-core] [v2][PATCH 1/1] vala.bbclass: add dependency on vala

2013-09-27 Thread Mark Hatle 

On 9/26/13 7:13 PM, Randy MacLeod wrote:

On 13-09-26 02:52 PM, Joe Slater wrote:

This class points the inheritor, if it is a target,
to directories in the target sysroot, so we want to
be sure the .vapi files are there.

Signed-off-by: Joe Slater jsla...@windriver.com
---
   meta/classes/vala.bbclass |8 +---
   1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/classes/vala.bbclass b/meta/classes/vala.bbclass
index c7db08c..3b70a04 100644
--- a/meta/classes/vala.bbclass
+++ b/meta/classes/vala.bbclass
@@ -1,9 +1,11 @@
   # Vala has problems with multiple concurrent invocations
   PARALLEL_MAKE = 

-# Vala needs vala-native
-DEPENDS += vala-native
-DEPENDS_virtclass-native += vala-native
+# Everyone needs vala-native and targets need vala, too,
+# because that is where target builds look for .vapi files.
+#
+VALADEPENDS_class-target = vala
+DEPENDS_append =  vala-native ${VALADEPENDS}

   # Our patched version of Vala looks in STAGING_DATADIR for .vapi files
   export STAGING_DATADIR




In response to your previous patch, Richard P said:

In class code this is a really bad idea. Why? Imagine a recipe which
does:

DEPENDS =+ x
DEPENDS_class-native = y

The += on the class-native above will not do what you think.

I'd recommend something like:

VALADEPENDS = vala vala-native
VALADEPENDS_class-native = vala-native
DEPENDS += ${VALADEPENDS}

Most other classes actually use _append on DEPENDS to ensure consistent
behaviour.


so send it to oe-core and see what they say.
Mark H any comments?


Good catch, I had missed this.

Ya the overrides (class-native) run -after- the rest of the system.  So:

DEPENDS = foobar
DEPENDS =+ x
DEPENDS_class-native =+ y

For normal it' would be x foobar
For native it would be y

This is because that system evals and gets:

DEPENDS = foobar  (DEPENDS = foobar)
DEPENDS =+ x  (DEPENDS = x foobar)
DEPENDS_class-native =+ y  (DEPENDS_class-native = y)

invoke 'class-native' override,  DEPENDS = y

--Mark


// Randy



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

[OE-core] [PATCH] kernel.bbclass: Allow INITRAMFS_TASK to trigger copy initramfs code

2013-09-27 Thread Jason Wessel 
Activating the INITRAMFS_TASK can cause circular dependencies, but
that is up to the end user to resolve in recipes.  The INITRAMFS_TASK
should also trigger immediate linking of the cpio task in the first
compile pass.  This was a subtle regression introduced by: 609d5a9ab
(kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency
and bundling).

This patch restores the previous behavior and only affects the
INITRAMFS_TASK which is not set by any of the default build profiles
in oe-core.

Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 meta/classes/kernel.bbclass |6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8cf66ce..73c525f 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -156,6 +156,12 @@ kernel_do_compile() {
# different initramfs image.  The way to do that in the kernel
# is to specify:
# make ...args... CONFIG_INITRAMFS_SOURCE=some_other_initramfs.cpio
+   if [ $use_alternate_initrd =  ]  [ ${INITRAMFS_TASK} !=  ] ; 
then
+   # The old style way of copying an prebuilt image and building it
+   # is turned on via INTIRAMFS_TASK != 
+   copy_initramfs
+   
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+   fi
oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} 
CC=${KERNEL_CC} LD=${KERNEL_LD} ${KERNEL_EXTRA_ARGS} $use_alternate_initrd
if test ${KERNEL_IMAGETYPE_FOR_MAKE}.gz = ${KERNEL_IMAGETYPE}; then
gzip -9c  ${KERNEL_IMAGETYPE_FOR_MAKE}  ${KERNEL_OUTPUT}
-- 
1.7.9.5

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

Re: [OE-core] [v2 PATCH] kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency and bundling

2013-09-27 Thread Jason Wessel 
On 09/27/2013 04:05 AM, Richard Purdie wrote:
 On Fri, 2013-09-27 at 10:07 +0200, Andrea Adami wrote:
 On Sat, Aug 24, 2013 at 7:15 PM, Richard Purdie
 richard.pur...@linuxfoundation.org wrote:
 With 1.5 approaching I'd like to have the issue solved as soon as possible.
 Richard, when is deadline for core-patches?
 
 Basically ASAP. The next release build is the start of next week but any
 patches going into that need to have been run through an autobuilder
 cycle first.
 
 This is the first I've heard of the problem, other than some comments
 about possible problems on irc. Can someone please open up a bug for
 this and clearly describe what used to work and now doesn't and what the
 possible fixes or workarounds are?
 
 I don't think anyone likes regressions however if we don't have the open
 bug, its very hard to track.
 
 You say you've talked to Bruce/Jason but why didn't the discussion
 happen on the mailing list? That way others may have been able to help
 and now I could read back the list and see for myself what the issue is.
 As it is, I simply don't know other than the need to set a new variable
 which is hinted at above...
 


What was needed most was a defect detailing the configuration setup.  The 
reason I have not hit this problem nor any of the other autobuilders was that 
it required a very specific way to setup the recipes to depend on each other, 
but not circularly.

Andrea sent full details to Bruce, who sent them to me and I built it this 
morning.  It took very little time to isolate the problem but it was one of 
those oh so subtle issues (patch is sent to oe-core).  Perhaps in the future we 
can just get a Bugzilla opened right away.  I don't like regressions either. :-)

Andrea replied to me in IRC, I'll test the new patch soon. 

Cheers,
Jason.

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

[OE-core] [PATCH 2/2] sato-icon-theme: add more compatibility symlinks

2013-09-27 Thread Ross Burton 
libfm uses preferences-desktop, so link it to the close-enough
preferences-sytem.

x11vnc uses computer, link it to terminal.

pcmanfm uses system-file-manager, link it to file-manager.

[ YOCTO #4062 ]

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb |6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb 
b/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
index cb3b68c..cf23aeb 100644
--- a/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
+++ b/meta/recipes-sato/sato-icon-theme/sato-icon-theme_0.4.1.bb
@@ -23,6 +23,12 @@ FILES_${PN} += ${datadir}
 
 EXTRA_OECONF += --with-iconmap=${@d.getVar('STAGING_LIBEXECDIR_NATIVE', 
True).replace('sato-icon-theme', 'icon-naming-utils')}/icon-name-mapping
 
+do_install_append() {
+   find ${D}${datadir}/icons/Sato/ -maxdepth 1 -type d -exec ln -s 
preferences-system.png {}/apps/preferences-desktop.png \;
+   find ${D}${datadir}/icons/Sato/ -maxdepth 1 -type d -exec ln -s 
file-manager.png {}/apps/system-file-manager.png \;
+   find ${D}${datadir}/icons/Sato/ -maxdepth 1 -type d -exec ln -s 
../apps/terminal.png {}/places/computer.png \;
+}
+
 # Explictly setting Sato as the default icon theme to avoid flickering from
 # the desktop and settings daemon racing.  This shouldn't be done here but in 
the sato image
 pkg_postinst_${PN} () {
-- 
1.7.10.4

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

[OE-core] [PATCH 1/2] pcmanfm: hide the desktop preferences

2013-09-27 Thread Ross Burton 
Sato doesn't use the pcmanfm desktop, so hide the desktop preferences launcher.

Signed-off-by: Ross Burton ross.bur...@intel.com
---
 meta/recipes-sato/pcmanfm/files/no-desktop.patch |   15 +++
 meta/recipes-sato/pcmanfm/pcmanfm_1.1.0.bb   |3 ++-
 2 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-sato/pcmanfm/files/no-desktop.patch

diff --git a/meta/recipes-sato/pcmanfm/files/no-desktop.patch 
b/meta/recipes-sato/pcmanfm/files/no-desktop.patch
new file mode 100644
index 000..cb4cae0
--- /dev/null
+++ b/meta/recipes-sato/pcmanfm/files/no-desktop.patch
@@ -0,0 +1,15 @@
+Disable the desktop preferences launcher as we don't use the pcmanfm desktop in
+Sato.
+
+Upstream-Status: Inappropriate
+Signed-off-by: Ross Burton ross.bur...@intel.com
+
+diff --git a/data/pcmanfm-desktop-pref.desktop 
b/data/pcmanfm-desktop-pref.desktop
+index ccf8abb..3f6fc1c 100644
+--- a/data/pcmanfm-desktop-pref.desktop
 b/data/pcmanfm-desktop-pref.desktop
+@@ -97,3 +97,4 @@ Exec=pcmanfm --desktop-pref
+ StartupNotify=true
+ Terminal=false
+ NotShowIn=GNOME;XFCE;KDE;
++NoDisplay=true
diff --git a/meta/recipes-sato/pcmanfm/pcmanfm_1.1.0.bb 
b/meta/recipes-sato/pcmanfm/pcmanfm_1.1.0.bb
index bcfc9db..9a038fe 100644
--- a/meta/recipes-sato/pcmanfm/pcmanfm_1.1.0.bb
+++ b/meta/recipes-sato/pcmanfm/pcmanfm_1.1.0.bb
@@ -20,7 +20,8 @@ SRC_URI = ${SOURCEFORGE_MIRROR}/pcmanfm/pcmanfm-${PV}.tar.gz 
\
   file://gnome-fs-regular.png \
   file://gnome-mime-text-plain.png \
   file://emblem-symbolic-link.png \
-  file://cross-compile-fix.patch
+  file://cross-compile-fix.patch \
+  file://no-desktop.patch
 
 SRC_URI[md5sum] = af0cff78690e658f3c06ceabf27bc71a
 SRC_URI[sha256sum] = 
1f6301f330ad648f3322708ec6c0f680a8695a9453932fe19653bab6731e5582
-- 
1.7.10.4

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

Re: [OE-core] [PATCH] libtool-native_2.4.2.bb: Always use /bin/sed for SED

2013-09-27 Thread Denys Dmytriyenko 
On Fri, Sep 27, 2013 at 11:06:42AM +0100, Richard Purdie wrote:
 On Fri, 2013-09-27 at 10:20 +0100, Richard Purdie wrote:
  On Thu, 2013-09-26 at 18:40 -0400, Denys Dmytriyenko wrote:
   On Tue, Feb 12, 2013 at 01:36:44PM -0600, Jason Wessel wrote:
If you never use sstate and always build everything from scratch you
will never see this problem.  However, if you use sstate and build
directories that last a long time eventually you can end up with the
scenario where libtool gets a hard coded path in it for sed, and sed
may not exist.  The reason you don't see this problem to often if you
generally build from scratch is that libtool builds before sed and
will pickup the host's /bin/sed.

The way to reproduce the issue is:

bitbake some_image
bitbake -c cleansstate libtool-native
bitbake sed-native
bitbake libtool-native
bitbake -c clean sed-native
bitbake ANY_PACKAGE_THAT_USES_LIBTOOL_NATIVE

In my case I used modphp, which doesn't exist in the oe-core. You will
end up with a strange looking error like:

| make[1]: *** [buckets/apr_buckets_alloc.lo] Error 1
| 
/opt/build/bitbake_build/tmp/sysroots/x86_64-linux/usr/bin/x86_64-linux-libtool:
 line 981: /opt/build/bitbake_build/tmp/sysroots/x86_64-linux//bin/sed: 
No such file or directory
   
   Sorry for bringing up this old thread. I'm seeing these and similar 
   errors now 
   (nothing really changed in my setup, but some race got them exposed).
   
   I do see that the proposed patch got merged all the way back in February. 
   But 
   looks like it wasn't enough.
   
   I've just seen this error about missing sysroots/x86_64-linux//bin/sed 
   coming 
   from nativesdk-gettext compilation while calling i686-linux-libtool, i.e. 
   the 
   nativesdk version of libtool. Should be easy to duplicate the below patch 
   for 
   libtool from native to nativesdk recipe.
   
   And another error was from sysroots/x86_64-linux/usr/bin/opkg-build 
   during 
   do_package_write of some other package. Should opkg-utils-native be 
   patched 
   the same?
  
  Was this in master with
  http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=32edeb391f2107bb66b361cdcd4b8d4447731c33
   applied?
 
 To answer my own question, the above introduced a bug since I'd
 forgotten native doesn't use the site files. It probably should use at
 least a minimal one so I've sent out a patch for that.

Richard,

I was getting that on dylan and master, but the above patch was not in yet. 
I'll give this one and the new native site config patch a try. Thanks!

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

[OE-core] [PATCH] opkg: Use systemd service for first boot configuration

2013-09-27 Thread Shakeel, Muhammad 
From: Muhammad Shakeel muhammad_shak...@mentor.com

Currently opkg uses a script to configure packages during first time boot.
This script is present in rcS.d and when 'sysvinit' is disabled this
script doesn't execute. For systemd only distros this newly added service
will run the opkg configure during first boot only.

Signed-off-by: Muhammad Shakeel muhammad_shak...@mentor.com
---
 meta/recipes-devtools/opkg/opkg.inc|   21 ++--
 .../opkg/opkg/opkg-configure.service   |   17 
 meta/recipes-devtools/opkg/opkg_svn.bb |1 +
 3 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/opkg/opkg.inc 
b/meta/recipes-devtools/opkg/opkg.inc
index afe6cb0..3d56886 100644
--- a/meta/recipes-devtools/opkg/opkg.inc
+++ b/meta/recipes-devtools/opkg/opkg.inc
@@ -16,7 +16,13 @@ do_configure_prepend() {
sed -i -e s:-Werror::g ${S}/libopkg/Makefile.am
 }
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig systemd
+
+python () {
+if 'sysvinit' not in d.getVar(DISTRO_FEATURES, True).split():
+pn = d.getVar('PN', True)
+d.setVar('SYSTEMD_SERVICE_%s' % (pn), 'opkg-configure.service')
+}
 
 target_localstatedir := ${localstatedir}
 OPKGLIBDIR = ${target_localstatedir}/lib
@@ -49,6 +55,16 @@ FILES_libopkg = ${libdir}/*.so.* ${OPKGLIBDIR}/opkg/
 do_install_append() {
# We need to create the lock directory
install -d ${D}${OPKGLIBDIR}/opkg
+
+   if ${@base_contains('DISTRO_FEATURES','sysvinit','false','true',d)};then
+   install -d ${D}${systemd_unitdir}/system
+   install -m 0644 ${WORKDIR}/opkg-configure.service 
${D}${systemd_unitdir}/system/
+   sed -i -e 's,@BASE_BINDIR@,${base_bindir},g' \
+   -e 's,@SYSCONFDIR@,${sysconfdir},g' \
+   -e 's,@BINDIR@,${bindir},g' \
+   -e 's,@SYSTEMD_UNITDIR@,${systemd_unitdir},g' \
+   ${D}${systemd_unitdir}/system/opkg-configure.service
+   fi
 }
 
 do_install_append_class-native() {
@@ -59,7 +75,8 @@ do_install_append_class-native() {
 
 pkg_postinst_${PN} () {
 #!/bin/sh
-if [ x$D != x ]  [ -f $D${OPKGLIBDIR}/opkg/status ]; then
+if ${@base_contains('DISTRO_FEATURES','sysvinit','true','false',d)}  \
+   [ x$D != x ]  [ -f $D${OPKGLIBDIR}/opkg/status ]; then
install -d $D${sysconfdir}/rcS.d
 
# this happens at S98 where our good 'ole packages script used to run
diff --git a/meta/recipes-devtools/opkg/opkg/opkg-configure.service 
b/meta/recipes-devtools/opkg/opkg/opkg-configure.service
new file mode 100644
index 000..a1c3a31
--- /dev/null
+++ b/meta/recipes-devtools/opkg/opkg/opkg-configure.service
@@ -0,0 +1,17 @@
+[Unit]
+Description=Opkg first boot configure
+DefaultDependencies=no
+After=systemd-remount-fs.service systemd-tmpfiles-setup.service tmp.mount
+Before=sysinit.target
+
+[Service]
+Type=oneshot
+EnvironmentFile=-@SYSCONFDIR@/default/postinst
+ExecStart=@BASE_BINDIR@/sh -c  if [ $POSTINST_LOGGING = '1' ]; then 
@BINDIR@/opkg-cl configure  $LOGFILE 21; else @BINDIR@/opkg-cl configure; fi
+ExecStartPost=@BASE_BINDIR@/systemctl disable opkg-configure.service
+StandardOutput=syslog
+RemainAfterExit=No
+
+[Install]
+WantedBy=basic.target
+WantedBy=sysinit.target
diff --git a/meta/recipes-devtools/opkg/opkg_svn.bb 
b/meta/recipes-devtools/opkg/opkg_svn.bb
index bc10491..cd0485f 100644
--- a/meta/recipes-devtools/opkg/opkg_svn.bb
+++ b/meta/recipes-devtools/opkg/opkg_svn.bb
@@ -3,6 +3,7 @@ require opkg.inc
 SRC_URI = svn://opkg.googlecode.com/svn;module=trunk;protocol=http \
file://no-install-recommends.patch \
file://add-exclude.patch \
+   file://opkg-configure.service \
 
 
 S = ${WORKDIR}/trunk
-- 
1.7.9.5

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

Re: [OE-core] [PATCH] kernel.bbclass: Allow INITRAMFS_TASK to trigger copy initramfs code

2013-09-27 Thread Andrea Adami 
Jason,

there is one more problem here:

| DEBUG: Executing shell function do_compile
| Copying initramfs into ./usr ...
| cp: cannot create regular file
'/oe/oe-core/build/tmp-eglibc/work/poodle-oe-linux-gnueabi/linux-yocto-tiny-kexecboot/3.10.11+gitAUTOINC+dad2b7e1ce_e1aa804148-r0/linux-poodle-tiny-build/usr/.':
No such file or directory

I'm solving it this way:

copy_initramfs() {
echo Covpying initramfs into ./usr ...
+mkdir -p ${B}/usr
# Find and use the first initramfs image archive type we find


Please take care of this.
Thanks

Andrea




On Fri, Sep 27, 2013 at 6:23 PM, Jason Wessel
jason.wes...@windriver.com wrote:
 Activating the INITRAMFS_TASK can cause circular dependencies, but
 that is up to the end user to resolve in recipes.  The INITRAMFS_TASK
 should also trigger immediate linking of the cpio task in the first
 compile pass.  This was a subtle regression introduced by: 609d5a9ab
 (kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency
 and bundling).

 This patch restores the previous behavior and only affects the
 INITRAMFS_TASK which is not set by any of the default build profiles
 in oe-core.

 Signed-off-by: Jason Wessel jason.wes...@windriver.com
 ---
  meta/classes/kernel.bbclass |6 ++
  1 file changed, 6 insertions(+)

 diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
 index 8cf66ce..73c525f 100644
 --- a/meta/classes/kernel.bbclass
 +++ b/meta/classes/kernel.bbclass
 @@ -156,6 +156,12 @@ kernel_do_compile() {
 # different initramfs image.  The way to do that in the kernel
 # is to specify:
 # make ...args... CONFIG_INITRAMFS_SOURCE=some_other_initramfs.cpio
 +   if [ $use_alternate_initrd =  ]  [ ${INITRAMFS_TASK} !=  ] 
 ; then
 +   # The old style way of copying an prebuilt image and building 
 it
 +   # is turned on via INTIRAMFS_TASK != 
 +   copy_initramfs
 +   
 use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
 +   fi
 oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} 
 CC=${KERNEL_CC} LD=${KERNEL_LD} ${KERNEL_EXTRA_ARGS} $use_alternate_initrd
 if test ${KERNEL_IMAGETYPE_FOR_MAKE}.gz = ${KERNEL_IMAGETYPE}; 
 then
 gzip -9c  ${KERNEL_IMAGETYPE_FOR_MAKE}  ${KERNEL_OUTPUT}
 --
 1.7.9.5

 ___
 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] kernel.bbclass: Allow INITRAMFS_TASK to trigger copy initramfs code

2013-09-27 Thread Jason Wessel 
On 09/27/2013 04:06 PM, Andrea Adami wrote:
 | DEBUG: Executing shell function do_compile
 | Copying initramfs into ./usr ...
 | cp: cannot create regular file
 '/oe/oe-core/build/tmp-eglibc/work/poodle-oe-linux-gnueabi/linux-yocto-tiny-kexecboot/3.10.11+gitAUTOINC+dad2b7e1ce_e1aa804148-r0/linux-poodle-tiny-build/usr/.':


I suppose that one makes sense given that the compile directory might not 
exist.  My testing did not show this problem because my working env was dirty.

Thanks for the report, your fix is perfectly fine.  I'll send a v2.

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

[OE-core] [v2 PATCH] kernel.bbclass: Allow INITRAMFS_TASK to trigger copy initramfs code

2013-09-27 Thread Jason Wessel 
Activating the INITRAMFS_TASK can cause circular dependencies, but
that is up to the end user to resolve in recipes.  The INITRAMFS_TASK
should also trigger immediate linking of the cpio task in the first
compile pass.  This was a subtle regression introduced by: 609d5a9ab
(kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency
and bundling).

This patch restores the previous behavior and only affects the
INITRAMFS_TASK which is not set by any of the default build profiles
in oe-core.

Reviewed-by: Andrea Adami andrea.ad...@gmail.com
Signed-off-by: Jason Wessel jason.wes...@windriver.com
---
 meta/classes/kernel.bbclass |8 
 1 file changed, 8 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 8cf66ce..4acfb7e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -83,6 +83,8 @@ KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:] 
== .gz else s)(d.g
 
 copy_initramfs() {
echo Copying initramfs into ./usr ...
+   # In case the directory is not created yet from the first pass compile:
+   mkdir -p ${B}/usr
# Find and use the first initramfs image archive type we find
rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
for img in cpio.gz cpio.lzo cpio.lzma cpio.xz; do
@@ -156,6 +158,12 @@ kernel_do_compile() {
# different initramfs image.  The way to do that in the kernel
# is to specify:
# make ...args... CONFIG_INITRAMFS_SOURCE=some_other_initramfs.cpio
+   if [ $use_alternate_initrd =  ]  [ ${INITRAMFS_TASK} !=  ] ; 
then
+   # The old style way of copying an prebuilt image and building it
+   # is turned on via INTIRAMFS_TASK != 
+   copy_initramfs
+   
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
+   fi
oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} 
CC=${KERNEL_CC} LD=${KERNEL_LD} ${KERNEL_EXTRA_ARGS} $use_alternate_initrd
if test ${KERNEL_IMAGETYPE_FOR_MAKE}.gz = ${KERNEL_IMAGETYPE}; then
gzip -9c  ${KERNEL_IMAGETYPE_FOR_MAKE}  ${KERNEL_OUTPUT}
-- 
1.7.9.5

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

Re: [OE-core] [v2 PATCH] kernel.bbclass: Allow INITRAMFS_TASK to trigger copy initramfs code

2013-09-27 Thread Andrea Adami 
On Fri, Sep 27, 2013 at 11:32 PM, Jason Wessel
jason.wes...@windriver.com wrote:
 Activating the INITRAMFS_TASK can cause circular dependencies, but
 that is up to the end user to resolve in recipes.  The INITRAMFS_TASK
 should also trigger immediate linking of the cpio task in the first
 compile pass.  This was a subtle regression introduced by: 609d5a9ab
 (kernel.bbclass, image.bbclass: Implement kernel INITRAMFS dependency
 and bundling).

 This patch restores the previous behavior and only affects the
 INITRAMFS_TASK which is not set by any of the default build profiles
 in oe-core.

 Reviewed-by: Andrea Adami andrea.ad...@gmail.com
 Signed-off-by: Jason Wessel jason.wes...@windriver.com
 ---
  meta/classes/kernel.bbclass |8 
  1 file changed, 8 insertions(+)

 diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
 index 8cf66ce..4acfb7e 100644
 --- a/meta/classes/kernel.bbclass
 +++ b/meta/classes/kernel.bbclass
 @@ -83,6 +83,8 @@ KERNEL_IMAGETYPE_FOR_MAKE = ${@(lambda s: s[:-3] if s[-3:] 
 == .gz else s)(d.g

  copy_initramfs() {
 echo Copying initramfs into ./usr ...
 +   # In case the directory is not created yet from the first pass 
 compile:
 +   mkdir -p ${B}/usr
 # Find and use the first initramfs image archive type we find
 rm -f ${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
 for img in cpio.gz cpio.lzo cpio.lzma cpio.xz; do
 @@ -156,6 +158,12 @@ kernel_do_compile() {
 # different initramfs image.  The way to do that in the kernel
 # is to specify:
 # make ...args... CONFIG_INITRAMFS_SOURCE=some_other_initramfs.cpio
 +   if [ $use_alternate_initrd =  ]  [ ${INITRAMFS_TASK} !=  ] 
 ; then
 +   # The old style way of copying an prebuilt image and building 
 it
 +   # is turned on via INTIRAMFS_TASK != 
 +   copy_initramfs
 +   
 use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE}-${MACHINE}.cpio
 +   fi
 oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} 
 CC=${KERNEL_CC} LD=${KERNEL_LD} ${KERNEL_EXTRA_ARGS} $use_alternate_initrd
 if test ${KERNEL_IMAGETYPE_FOR_MAKE}.gz = ${KERNEL_IMAGETYPE}; 
 then
 gzip -9c  ${KERNEL_IMAGETYPE_FOR_MAKE}  ${KERNEL_OUTPUT}
 --
 1.7.9.5

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

Thanks

Tested by: Andrea Adami andrea.ad...@gmail.com
Acked by: Andrea Adami andrea.ad...@gmail.com
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core