Re: [yocto] Problem recipe build with package debian

2015-01-21 Thread Cleiton Bueno 
Is already configured with package_deb.
I'll check the EXTRA_IMAGE_FEATURES and test.
Even if I do not use do_install () it is to install the package?





2015-01-21 20:38 GMT-02:00 Aníbal Limón :

>  Hi Cleiton,
>
> If you want to build deb packages you need to set in your local.conf,
>
> PACKAGE_CLASSES ?= "package_deb"
>
> Also if you want package-management support in the TARGET_IMAGE you need
> to add package-management to
> EXTRA_IMAGE_FEATURES.
>
> Regards
>
> alimon
>
> On 21/01/15 15:43, Cleiton Bueno wrote:
>
> I have a deb package with several scripts and configurations that I want
> to use the BBB.
> I created a recipe, as well as other modules and packages to install.
>
>
> The recipe I'm using is equal below, (removed some details, is just the
> example base)
>
>
>
> SUMMARY = ""
> DESCRIPTION = ""
> HOMEPAGE = ""
>
>
>
> LIC_FILES_CHKSUM = "file://LICENSE;md5=1726e2117494ba3e13e1c3d93f795360"
>
> SRC_URI = "file://my_pkg.deb"
>
> SRC_URI[md5sum] = ""
> SRC_URI[sha256sum] = ""
>
> S = "${WORKDIR}/my_pkg-${PV}"
>
> inherit package_deb
>
>
> do_install_append() {
> install -m 755 -D ${WORKDIR}/my_pkg.deb
> }
>
>
>
>
> Has anyone created recipe to install deb packages?
>
>
>
>
>  My bibake process build...
>
>
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Package pkgAll is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> W: Unable to read /home/bueno/yocto/poky/projTest/tmp/work/qemux86-
> poky-linux/projTest/1.0-r0/apt/preferences.d/ - DirectoryExists (2: No
> such file or directory)
> E: Package 'pkgAll' has no installation candidate
>
> ERROR: Function failed: do_rootfs
> ERROR: Logfile of failure stored in: /home/bueno/yocto/poky/
> projTest/tmp/work/qemux86-poky-linux/projTest/1.0-r0/
> temp/log.do_rootfs.27791
> ERROR: Task 7 (/home/bueno/yocto/poky/projTest//../meta-pkgAll/
> recipes-core/images/projTest.bb, do_rootfs) failed with exit code '1'
>
>
>
> Now, my recipe the package deb:
>
> SUMMARY = "XX"
> DESCRIPTION = "XX"
>
> LICENSE = "CLOSED"
>
>
> SRC_URI = "file://projTest_1.0.deb"
>
> SRC_URI[md5sum] = "32d0c2b332440a47dd370eXX"
> SRC_URI[sha256sum] = "42ebcf856aa626aa6d021173f4d931
> e0c84a0a27808d147db89942XX"
>
>
>
> inherit bin_package pkgconfig
>
>
> install_deb() {
>
> ${STAGING_BINDIR_NATIVE}/dpkg --root=${IMAGE_ROOTFS}/
> --admindir=${IMAGE_ROOTFS}/var/lib/dpkg/ -i file://projTest_1.0.deb
> }
>
> ROOTFS_POSTPROCESS_COMMAND += "install_deb; "
>
>
>
>
>  --
>
> *Att, Cleiton Bueno*
>
>
>
>
>


-- 

*Att,Cleiton Bueno*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [autobuilder][PATCH 2/2] BuildImages.py: Make -w flag depend on bitbake version check

2015-01-21 Thread Saul Wold 


Brendan,

Just a heads up, these AB patches will be reviewed when Beth comes back 
in just over 3 weeks, you should be able to fix your local AB instance 
for now.


Thanks for your patience

Sau!


On 01/21/2015 03:08 AM, brendan.le.f...@intel.com wrote:

From: Brendan Le Foll 

Because bitbake -w flag does not exist in verisons of bitbake prior to 1.25
BuildImages.py is broken for anything older like daisy, adding this check means
that -w will only be applied if the GetBitbakeVersion step has been run.

Signed-off-by: Brendan Le Foll 
---
  lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py
index 31a29a8..bf1ac5e 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py
@@ -13,6 +13,7 @@ __email__ = "elizabeth.flana...@intel.com"

  from buildbot.steps.shell import ShellCommand
  from buildbot.process.buildstep import LogLineObserver
+from distutils.version import StrictVersion
  import os

  class BuildImages(ShellCommand):
@@ -47,7 +48,11 @@ class BuildImages(ShellCommand):
  if self.layerversion_yoctobsp is not None and int(self.layerversion_yoctobsp) < 
2 and self.machine is not None and self.machine == "genericx86-64":
  self.command = "echo 'Skipping Step.'"
  else:
-self.command = ". ./oe-init-build-env; bitbake -w -k " + 
self.images
+bitbakeflags = "-k "
+# -w only exists in bitbake 1.25 and newer, use distroversion string 
and make sure we're on poky >1.7
+if self.getProperty('bitbakeversion') and 
StrictVersion(self.getProperty('bitbakeversion')) >= StrictVersion("1.25"):
+bitbakeflags += "-w "
+self.command = ". ./oe-init-build-env; bitbake " + bitbakeflags + 
self.images
  self.description = ["Building " + str(self.images)]
  ShellCommand.start(self)



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problem recipe build with package debian

2015-01-21 Thread Aníbal Limón 

Hi Cleiton,

If you want to build deb packages you need to set in your local.conf,

PACKAGE_CLASSES ?= "package_deb"

Also if you want package-management support in the TARGET_IMAGE you need 
to add package-management to

EXTRA_IMAGE_FEATURES.

Regards

alimon

On 21/01/15 15:43, Cleiton Bueno wrote:
I have a deb package with several scripts and configurations that I 
want to use the BBB.

I created a recipe, as well as other modules and packages to install.


The recipe I'm using is equal below, (removed some details, is just 
the example base)




SUMMARY = ""
DESCRIPTION = ""
HOMEPAGE = ""



LIC_FILES_CHKSUM = "file://LICENSE;md5=1726e2117494ba3e13e1c3d93f795360"

SRC_URI = "file://my_pkg.deb"

SRC_URI[md5sum] = ""
SRC_URI[sha256sum] = ""

S = "${WORKDIR}/my_pkg-${PV}"

inherit package_deb


do_install_append() {
install -m 755 -D ${WORKDIR}/my_pkg.deb
}




Has anyone created recipe to install deb packages?




My bibake process build...


Reading package lists...
Building dependency tree...
Reading state information...
Package pkgAll is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

W: Unable to read 
/home/bueno/yocto/poky/projTest/tmp/work/qemux86-poky-linux/projTest/1.0-r0/apt/preferences.d/ 
- DirectoryExists (2: No such file or directory)

E: Package 'pkgAll' has no installation candidate

ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/home/bueno/yocto/poky/projTest/tmp/work/qemux86-poky-linux/projTest/1.0-r0/temp/log.do_rootfs.27791
ERROR: Task 7 
(/home/bueno/yocto/poky/projTest//../meta-pkgAll/recipes-core/images/projTest.bb, 
do_rootfs) failed with exit code '1'




Now, my recipe the package deb:

SUMMARY = "XX"
DESCRIPTION = "XX"

LICENSE = "CLOSED"


SRC_URI = "file://projTest_1.0.deb"

SRC_URI[md5sum] = "32d0c2b332440a47dd370eXX"
SRC_URI[sha256sum] = 
"42ebcf856aa626aa6d021173f4d931e0c84a0a27808d147db89942XX"




inherit bin_package pkgconfig


install_deb() {
${STAGING_BINDIR_NATIVE}/dpkg --root=${IMAGE_ROOTFS}/ 
--admindir=${IMAGE_ROOTFS}/var/lib/dpkg/ -i file://projTest_1.0.deb

}
ROOTFS_POSTPROCESS_COMMAND += "install_deb; "




--
/*Att,
Cleiton Bueno*/





-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Difference between target, cross, native and nativesdk.

2015-01-21 Thread Denys Dmytriyenko 
On Wed, Jan 21, 2015 at 09:23:35PM +, Richard Purdie wrote:
> On Wed, 2015-01-21 at 14:27 -0500, Denys Dmytriyenko wrote:
> > On Wed, Jan 21, 2015 at 11:23:38AM -0200, Raphael Philipe wrote:
> > > I was explained about the difference in a different way.
> > > 
> > > cross generates binary for the host architecture. But the way this
> > > binary is generated depends of the target architecture. Native
> > > generated binaries that do not depend of the target architecture.
> > 
> > Pretty much.
> > 
> > But another big difference is that -native packages do not generate IPK, 
> > RPM 
> > or DEB, while -nativesdk, -cross, -crosssdk and -cross-canadian do.
> 
> -cross and -crosssdk do not generate packages.

Yeah, I thought so initially, but then I found depmodwrapper-cross and 
qemuwrapper-cross packages in my deploy/ipk, which got me confused... They 
seem to be special cases and only have scripts and not binaries. I wonder if 
the name is misleading...


> Another way to think of this is:
> 
> "native" build once
> 
> "cross" build once per target, run on native, output code for target
> 
> "crosssdk" build once per sdk, run on native, output code for sdk
> 
> "cross-canadian" build once per sdk, run on sdk, output code for target
> 
> Whilst native.bbclass and nativesdk.bbclass are useful generally,
> cross.bbclass is only useful for GNU tool projects like
> binutils/gcc/gdb.
> 
> Cheers,
> 
> Richard
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Difference between target, cross, native and nativesdk.

2015-01-21 Thread Richard Purdie 
On Wed, 2015-01-21 at 16:31 -0500, Denys Dmytriyenko wrote:
> On Wed, Jan 21, 2015 at 09:23:35PM +, Richard Purdie wrote:
> > On Wed, 2015-01-21 at 14:27 -0500, Denys Dmytriyenko wrote:
> > > On Wed, Jan 21, 2015 at 11:23:38AM -0200, Raphael Philipe wrote:
> > > > I was explained about the difference in a different way.
> > > > 
> > > > cross generates binary for the host architecture. But the way this
> > > > binary is generated depends of the target architecture. Native
> > > > generated binaries that do not depend of the target architecture.
> > > 
> > > Pretty much.
> > > 
> > > But another big difference is that -native packages do not generate IPK, 
> > > RPM 
> > > or DEB, while -nativesdk, -cross, -crosssdk and -cross-canadian do.
> > 
> > -cross and -crosssdk do not generate packages.
> 
> Yeah, I thought so initially, but then I found depmodwrapper-cross and 
> qemuwrapper-cross packages in my deploy/ipk, which got me confused... They 
> seem to be special cases and only have scripts and not binaries. I wonder if 
> the name is misleading...

More like they shouldn't be getting packaged...

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Problem recipe build with package debian

2015-01-21 Thread Cleiton Bueno 
I have a deb package with several scripts and configurations that I want to
use the BBB.
I created a recipe, as well as other modules and packages to install.


The recipe I'm using is equal below, (removed some details, is just the
example base)



SUMMARY = ""
DESCRIPTION = ""
HOMEPAGE = ""



LIC_FILES_CHKSUM = "file://LICENSE;md5=1726e2117494ba3e13e1c3d93f795360"

SRC_URI = "file://my_pkg.deb"

SRC_URI[md5sum] = ""
SRC_URI[sha256sum] = ""

S = "${WORKDIR}/my_pkg-${PV}"

inherit package_deb


do_install_append() {
install -m 755 -D ${WORKDIR}/my_pkg.deb
}




Has anyone created recipe to install deb packages?




My bibake process build...


Reading package lists...
Building dependency tree...
Reading state information...
Package pkgAll is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

W: Unable to read /home/bueno/yocto/poky/projTest/tmp/work/qemux86-
poky-linux/projTest/1.0-r0/apt/preferences.d/ - DirectoryExists (2: No such
file or directory)
E: Package 'pkgAll' has no installation candidate

ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/bueno/yocto/poky/
projTest/tmp/work/qemux86-poky-linux/projTest/1.0-r0/
temp/log.do_rootfs.27791
ERROR: Task 7 (/home/bueno/yocto/poky/projTest//../meta-pkgAll/
recipes-core/images/projTest.bb, do_rootfs) failed with exit code '1'



Now, my recipe the package deb:

SUMMARY = "XX"
DESCRIPTION = "XX"

LICENSE = "CLOSED"


SRC_URI = "file://projTest_1.0.deb"

SRC_URI[md5sum] = "32d0c2b332440a47dd370eXX"
SRC_URI[sha256sum] = "42ebcf856aa626aa6d021173f4d931
e0c84a0a27808d147db89942XX"



inherit bin_package pkgconfig


install_deb() {

${STAGING_BINDIR_NATIVE}/dpkg --root=${IMAGE_ROOTFS}/
--admindir=${IMAGE_ROOTFS}/var/lib/dpkg/ -i file://projTest_1.0.deb
}

ROOTFS_POSTPROCESS_COMMAND += "install_deb; "




-- 

*Att,Cleiton Bueno*
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Difference between target, cross, native and nativesdk.

2015-01-21 Thread Richard Purdie 
On Wed, 2015-01-21 at 14:27 -0500, Denys Dmytriyenko wrote:
> On Wed, Jan 21, 2015 at 11:23:38AM -0200, Raphael Philipe wrote:
> > I was explained about the difference in a different way.
> > 
> > cross generates binary for the host architecture. But the way this
> > binary is generated depends of the target architecture. Native
> > generated binaries that do not depend of the target architecture.
> 
> Pretty much.
> 
> But another big difference is that -native packages do not generate IPK, RPM 
> or DEB, while -nativesdk, -cross, -crosssdk and -cross-canadian do.

-cross and -crosssdk do not generate packages.

Another way to think of this is:

"native" build once

"cross" build once per target, run on native, output code for target

"crosssdk" build once per sdk, run on native, output code for sdk

"cross-canadian" build once per sdk, run on sdk, output code for target

Whilst native.bbclass and nativesdk.bbclass are useful generally,
cross.bbclass is only useful for GNU tool projects like
binutils/gcc/gdb.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Difference between target, cross, native and nativesdk.

2015-01-21 Thread Denys Dmytriyenko 
On Wed, Jan 21, 2015 at 11:23:38AM -0200, Raphael Philipe wrote:
> I was explained about the difference in a different way.
> 
> cross generates binary for the host architecture. But the way this
> binary is generated depends of the target architecture. Native
> generated binaries that do not depend of the target architecture.

Pretty much.

But another big difference is that -native packages do not generate IPK, RPM 
or DEB, while -nativesdk, -cross, -crosssdk and -cross-canadian do.

-- 
Denys


> On Tue, Jan 20, 2015 at 12:44 PM, Paul Eggleton
>  wrote:
> > On Tuesday 20 January 2015 12:39:16 Raphael Philipe wrote:
> >> On Tue, Jan 20, 2015 at 10:23 AM, Paul Eggleton
> >>  wrote:
> >> > On Tuesday 20 January 2015 09:17:49 Raphael Philipe wrote:
> >> >> I'm working on a set of recipes that must be configurable to be baked
> >> >> in native, nativesdk, cross and target.
> >> >>
> >> >> I have a bunch of questions concerning this terms. I searched the
> >> >> documentation and wasn't able to find a definitive explanation for
> >> >> these terms.
> >> >>
> >> >> I will write some statements bellow about my understanding on these
> >> >> terms, and I will ask you to please correct me if I'm wrong or add any
> >> >> additional information:
> >> >>
> >> >> - By default, recipes bake binaries for the target architecture that
> >> >> is described in the MACHINE variable in the local.conf
> >> >
> >> > Correct.
> >> >
> >> >> - One can use BBCLASSEXTEND = "native nativesdk" to bake binaries for
> >> >> the host architecture (native) and for target sdk architecture. The
> >> >> target sdk architecture is described in the SDKMACHINE variable and
> >> >> the host architecture is the architecture of the machine executing
> >> >> bitbake. BBCLASSEXTEND = "native nativesdk" will alow you to bake
> >> >> recipes that are "virtual" using the suffix native ( so ${PN}-native)
> >> >> and the prefix nativesdk (so nativesdk-${PN}).
> >> >
> >> > Correct. FYI alternatively you can also "inherit native" or "inherit
> >> > nativesdk" to make a recipe specific to either of those classes (in which
> >> > case the recipe itself should be named -native or nativesdk-
> >> > ), however BBCLASSEXTEND is preferred these days.
> >> >
> >> >> - Recipes that are cross need to inherit cross.bbclass. They are used 
> >> >> for
> >> >> 
> >> >
> >> > Cross tools, i.e. tools that need to run in the native context and 
> >> > produce
> >> > some binary output for the target.
> >>
> >> For u-boot-fw-utils-cross, the binary that you refer is the enviroment
> >> variables file of u-boot? In this case, the difference between cross
> >> and native is not clear for me.
> >
> > I'm not sure of the details for this recipe specifically. Perhaps one of the
> > people on CC can answer.
> >
> > Cheers,
> > Paul
> >
> > --
> >
> > Paul Eggleton
> > Intel Open Source Technology Centre
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] CMake in populate_sdk

2015-01-21 Thread Philip Balister 
On 01/21/2015 02:26 PM, Benjamin Fleming wrote:
> 
> 
>> -Original Message-
>> From: Philip Balister [mailto:phi...@balister.org]
>> Sent: Tuesday, January 20, 2015 5:29 PM
>> To: Benjamin Fleming; yocto@yoctoproject.org
>> Subject: Re: [yocto] CMake in populate_sdk
>>
>> On 01/20/2015 02:42 PM, Benjamin Fleming wrote:
>>> How do I add packages to the populate_sdk option?
>> Something like this:
>>
>> https://github.com/balister/meta-sdr/blob/master/recipes-
>> images/images/native-sdk.inc
>>
> Ok, adding TOOLCHAIN_HOST_TASK_append = " nativesdk-cmake" seems to work; it 
> adds cmake to the SDK.
> One more question; when building using the SDK, my cmake-based project fails 
> to find required libraries; presumably it needs a toolchain.cmake file. Is 
> there some way for the populate_sdk task to generate the toolchain.cmake 
> files also? (I see that it generates something for autotools)

We added this to gnuradio:

https://github.com/gnuradio/gnuradio/blob/master/cmake/Toolchains/oe-sdk_cross.cmake

I wonder if we could generalize this.

Philip


> 
> Thanks, Ben 
> 
>> Philip
>>
>>>
>>> -Ben Fleming
>>>
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] CMake in populate_sdk

2015-01-21 Thread Benjamin Fleming 


> -Original Message-
> From: Philip Balister [mailto:phi...@balister.org]
> Sent: Tuesday, January 20, 2015 5:29 PM
> To: Benjamin Fleming; yocto@yoctoproject.org
> Subject: Re: [yocto] CMake in populate_sdk
> 
> On 01/20/2015 02:42 PM, Benjamin Fleming wrote:
> > How do I add packages to the populate_sdk option?
> Something like this:
> 
> https://github.com/balister/meta-sdr/blob/master/recipes-
> images/images/native-sdk.inc
> 
Ok, adding TOOLCHAIN_HOST_TASK_append = " nativesdk-cmake" seems to work; it 
adds cmake to the SDK.
One more question; when building using the SDK, my cmake-based project fails to 
find required libraries; presumably it needs a toolchain.cmake file. Is there 
some way for the populate_sdk task to generate the toolchain.cmake files also? 
(I see that it generates something for autotools)

Thanks, Ben 

> Philip
> 
> >
> > -Ben Fleming
> >
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel build woes

2015-01-21 Thread Gary Thomas 

On 2015-01-21 09:08, Bruce Ashfield wrote:

On 15-01-21 11:02 AM, Gary Thomas wrote:

Since the recent changes in how the kernel is built, some useful
workflows have been broken.  In particular when working on a
kernel, I use this sequence quite a lot:
   $ bitbake virtual/kernel
   $ bitbake virtual/kernel -c devshell
   ... make some tweaks, add a test patch, etc
   $ bitbake virtual/kernel -C compile

Trying this with a quite recent master
(4e20211090d2b193250edaa64f84e355a1c31fe5)
I get this error on the compile step:

ERROR: Function failed: do_compile (log file is located at
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/log.do_compile.29205)

ERROR: Logfile of failure stored in:
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/log.do_compile.29205

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4 zImage CC=arm-poky-linux-gnueabi-gcc
-mno-thumb-interwork -marm LD=arm-poky-linux-gnueabi-ld.bfd
|   CHK include/config/kernel.release
|   Using
/home/local/qemuarm_2015-01-09/tmp/sysroots/qemuarm/usr/src/kernel as
source for kernel
|   /home/local/qemuarm_2015-01-09/tmp/sysroots/qemuarm/usr/src/kernel
is not clean, please run 'make mrproper'
|   in the
'/home/local/qemuarm_2015-01-09/tmp/sysroots/qemuarm/usr/src/kernel'
directory.
| make[2]: *** [prepare3] Error 1
| make[1]: *** [sub-make] Error 2
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| WARNING:
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/run.do_compile.29205:1
exit 1 from
|   exit 1
| ERROR: Function failed: do_compile (log file is located at
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/log.do_compile.29205)

ERROR: Task 10
(/home/local/poky-cutting-edge/meta/recipes-kernel/linux/linux-yocto_3.14.bb,
do_compile) failed with exit code '1'

Note: this is not unique to the linux-yocto recipe, I've seen
the same error when using some kernel recipes from meta-fsl-arm*,
e.g. linux-boundary, as well as some local recipes which inherit
kernel.bbclass

Should I file this as a bug?


This has already been addressed in master as of Monday. The kernel is
in tmp/build/work-shared/, and can handle this sort of workflow.

Bruce



Indeed, it works again after updating to the latest master.

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel build woes

2015-01-21 Thread Bruce Ashfield 

On 15-01-21 11:02 AM, Gary Thomas wrote:

Since the recent changes in how the kernel is built, some useful
workflows have been broken.  In particular when working on a
kernel, I use this sequence quite a lot:
   $ bitbake virtual/kernel
   $ bitbake virtual/kernel -c devshell
   ... make some tweaks, add a test patch, etc
   $ bitbake virtual/kernel -C compile

Trying this with a quite recent master
(4e20211090d2b193250edaa64f84e355a1c31fe5)
I get this error on the compile step:

ERROR: Function failed: do_compile (log file is located at
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/log.do_compile.29205)

ERROR: Logfile of failure stored in:
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/log.do_compile.29205

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4 zImage CC=arm-poky-linux-gnueabi-gcc
-mno-thumb-interwork -marm LD=arm-poky-linux-gnueabi-ld.bfd
|   CHK include/config/kernel.release
|   Using
/home/local/qemuarm_2015-01-09/tmp/sysroots/qemuarm/usr/src/kernel as
source for kernel
|   /home/local/qemuarm_2015-01-09/tmp/sysroots/qemuarm/usr/src/kernel
is not clean, please run 'make mrproper'
|   in the
'/home/local/qemuarm_2015-01-09/tmp/sysroots/qemuarm/usr/src/kernel'
directory.
| make[2]: *** [prepare3] Error 1
| make[1]: *** [sub-make] Error 2
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| WARNING:
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/run.do_compile.29205:1
exit 1 from
|   exit 1
| ERROR: Function failed: do_compile (log file is located at
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/log.do_compile.29205)

ERROR: Task 10
(/home/local/poky-cutting-edge/meta/recipes-kernel/linux/linux-yocto_3.14.bb,
do_compile) failed with exit code '1'

Note: this is not unique to the linux-yocto recipe, I've seen
the same error when using some kernel recipes from meta-fsl-arm*,
e.g. linux-boundary, as well as some local recipes which inherit
kernel.bbclass

Should I file this as a bug?


This has already been addressed in master as of Monday. The kernel is
in tmp/build/work-shared/, and can handle this sort of workflow.

Bruce





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Kernel build woes

2015-01-21 Thread Gary Thomas 

Since the recent changes in how the kernel is built, some useful
workflows have been broken.  In particular when working on a
kernel, I use this sequence quite a lot:
  $ bitbake virtual/kernel
  $ bitbake virtual/kernel -c devshell
  ... make some tweaks, add a test patch, etc
  $ bitbake virtual/kernel -C compile

Trying this with a quite recent master 
(4e20211090d2b193250edaa64f84e355a1c31fe5)
I get this error on the compile step:

ERROR: Function failed: do_compile (log file is located at 
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/log.do_compile.29205)
ERROR: Logfile of failure stored in: 
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/log.do_compile.29205

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4 zImage CC=arm-poky-linux-gnueabi-gcc  -mno-thumb-interwork 
-marm LD=arm-poky-linux-gnueabi-ld.bfd
|   CHK include/config/kernel.release
|   Using /home/local/qemuarm_2015-01-09/tmp/sysroots/qemuarm/usr/src/kernel as 
source for kernel
|   /home/local/qemuarm_2015-01-09/tmp/sysroots/qemuarm/usr/src/kernel is not 
clean, please run 'make mrproper'
|   in the '/home/local/qemuarm_2015-01-09/tmp/sysroots/qemuarm/usr/src/kernel' 
directory.
| make[2]: *** [prepare3] Error 1
| make[1]: *** [sub-make] Error 2
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| WARNING: 
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/run.do_compile.29205:1
 exit 1 from
|   exit 1
| ERROR: Function failed: do_compile (log file is located at 
/home/local/qemuarm_2015-01-09/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0/temp/log.do_compile.29205)

ERROR: Task 10 
(/home/local/poky-cutting-edge/meta/recipes-kernel/linux/linux-yocto_3.14.bb, 
do_compile) failed with exit code '1'

Note: this is not unique to the linux-yocto recipe, I've seen
the same error when using some kernel recipes from meta-fsl-arm*,
e.g. linux-boundary, as well as some local recipes which inherit
kernel.bbclass

Should I file this as a bug?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Difference between target, cross, native and nativesdk.

2015-01-21 Thread Otavio Salvador 
On Wed, Jan 21, 2015 at 11:23 AM, Raphael Philipe  wrote:
> I was explained about the difference in a different way.
>
> cross generates binary for the host architecture. But the way this
> binary is generated depends of the target architecture. Native
> generated binaries that do not depend of the target architecture.

Yes; basically:

cross: generates a binary to run in the host system but dependant of
the target (e.g: binutils)
crosssdk: generates a binary to run in SDK host system but dependant
of the target (e.g: binutils)

native: generates a binary to run in the host system and has no direct
dependant information of the target
nativesdk: generates a binary to run in SDK host system and has no
direct dependant information of the target

The cross use is not very common because most of stuff fits in native
or target cases. However some specific utilities ends on this group.

The fw tools inside of U-Boot qualifies for both target and cross use
cases. When used in cross or crosssdk, it can be used to change things
in the generated image (sdcard for example) while in the target case
it can be used in the runtime system.

I hope it is clear now. If someone can add more info here, please do.

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

Re: [yocto] Difference between target, cross, native and nativesdk.

2015-01-21 Thread Raphael Philipe 
I was explained about the difference in a different way.

cross generates binary for the host architecture. But the way this
binary is generated depends of the target architecture. Native
generated binaries that do not depend of the target architecture.

Regards,



On Tue, Jan 20, 2015 at 12:44 PM, Paul Eggleton
 wrote:
> On Tuesday 20 January 2015 12:39:16 Raphael Philipe wrote:
>> On Tue, Jan 20, 2015 at 10:23 AM, Paul Eggleton
>>  wrote:
>> > On Tuesday 20 January 2015 09:17:49 Raphael Philipe wrote:
>> >> I'm working on a set of recipes that must be configurable to be baked
>> >> in native, nativesdk, cross and target.
>> >>
>> >> I have a bunch of questions concerning this terms. I searched the
>> >> documentation and wasn't able to find a definitive explanation for
>> >> these terms.
>> >>
>> >> I will write some statements bellow about my understanding on these
>> >> terms, and I will ask you to please correct me if I'm wrong or add any
>> >> additional information:
>> >>
>> >> - By default, recipes bake binaries for the target architecture that
>> >> is described in the MACHINE variable in the local.conf
>> >
>> > Correct.
>> >
>> >> - One can use BBCLASSEXTEND = "native nativesdk" to bake binaries for
>> >> the host architecture (native) and for target sdk architecture. The
>> >> target sdk architecture is described in the SDKMACHINE variable and
>> >> the host architecture is the architecture of the machine executing
>> >> bitbake. BBCLASSEXTEND = "native nativesdk" will alow you to bake
>> >> recipes that are "virtual" using the suffix native ( so ${PN}-native)
>> >> and the prefix nativesdk (so nativesdk-${PN}).
>> >
>> > Correct. FYI alternatively you can also "inherit native" or "inherit
>> > nativesdk" to make a recipe specific to either of those classes (in which
>> > case the recipe itself should be named -native or nativesdk-
>> > ), however BBCLASSEXTEND is preferred these days.
>> >
>> >> - Recipes that are cross need to inherit cross.bbclass. They are used for
>> >> 
>> >
>> > Cross tools, i.e. tools that need to run in the native context and produce
>> > some binary output for the target.
>>
>> For u-boot-fw-utils-cross, the binary that you refer is the enviroment
>> variables file of u-boot? In this case, the difference between cross
>> and native is not clear for me.
>
> I'm not sure of the details for this recipe specifically. Perhaps one of the
> people on CC can answer.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Ls1021a how i include nfs-utils correcty

2015-01-21 Thread Hänel-Baas , Alexander 
Hi

I work with the Layerscape 1021a ,that comes with yocto, i can create the 
image, dtb und rootfs and start my target.
But I cannot mount a nfs directory via "mount -t nfs".

The Error message say:
"mount: wrong fs type, bad option, bad superblock on 
172.16.17.63:/home/sm/myExport,
   missing codepage or helper program, or other error
   (for several filesystems (e.g. nfs, cifs) you might
   need a /sbin/mount. helper program)
   In some cases useful info is found in syslog - try
   dmesg | tail or so."

And right in /sbin are no nfs helper.

So i start yocto select my machine (ls1021atwr), the image recipes 
(lsl-image-core) press the "edit image recipe" button, the "All recipes" button
And search for nfs and then I included the nfs-utils manually by activate the 
checkbox. Then I press the "Build packages" button.
Then yocto print "Building packages..." then shows "Step 2 of 2"
and I'm wondering because in the Included Packages  nfs-utils are not shown!!!

So I go to the "all package tab" an include the nfs-utils again.
And finally I build the image.
Yocto creates a new image, that can boot, but it has no changes. No nfs-utils 
are included!

The I press the edit recipes button and look under includet recipies/all 
recipies and my before selected nfs-utils are NOT included.


My question are:
What is going wrong?
How I added the nfs-utils correctly?

Best regards
Alexander

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [autobuilder][PATCH 1/2] GetBitbakeVersion.py: add buildstep to get the version of bitbake

2015-01-21 Thread brendan . le . foll 
From: Brendan Le Foll 

This step allows people to use the property 'bitbakeversion' in their
buildsteps which is useful before running bitbake to check what flags will be
supported.

Signed-off-by: Brendan Le Foll 
---
 docs/YoctoAutobuilderDevelopersDocument.html   | 11 +
 .../autobuilder/buildsteps/GetBitbakeVersion.py| 49 ++
 2 files changed, 60 insertions(+)
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/GetBitbakeVersion.py

diff --git a/docs/YoctoAutobuilderDevelopersDocument.html 
b/docs/YoctoAutobuilderDevelopersDocument.html
index 8a2747b..e583dea 100644
--- a/docs/YoctoAutobuilderDevelopersDocument.html
+++ b/docs/YoctoAutobuilderDevelopersDocument.html
@@ -1500,6 +1500,17 @@
 
 
 
+GetBitbakeVersion
+
+
+Gets the version of 
bitbake being used. This is used by BuildImages.
+
+
+"bitbakeversion": string
+
+
+
+
 GetDistroVersion
 
 
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/GetBitbakeVersion.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/GetBitbakeVersion.py
new file mode 100644
index 000..dc6c25b
--- /dev/null
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/GetBitbakeVersion.py
@@ -0,0 +1,49 @@
+'''
+Created on January 20th, 2015
+
+__author__ = "Brendan Le Foll"
+__copyright__ = "Copyright 2015, Intel Corp."
+__credits__ = ["Brendan Le Foll"]
+__license__ = "GPL"
+__version__ = "2.0"
+__maintainer__ = "Elizabeth Flanagan"
+__email__ = "elizabeth.flanagan at intel.com"
+'''
+from buildbot.steps.shell import ShellCommand
+from buildbot.status import progress
+from buildbot.status.results import SUCCESS, FAILURE, WARNINGS
+from buildbot.process.properties import WithProperties
+from twisted.python import log
+from autobuilder.config import *
+
+class GetBitbakeVersion(ShellCommand):
+haltOnFailure = False
+flunkOnFailure = False
+name = "GetBitbakeVersion"
+def __init__(self, factory, argdict=None, **kwargs):
+for k, v in argdict.iteritems():
+setattr(self, k, v)
+self.description = "Get Bitbake Version"
+self.workerworkdir=os.path.join(os.path.join(YOCTO_ABBASE, 
"yocto-worker"))
+for k, v in argdict.iteritems():
+setattr(self, k, v)
+ShellCommand.__init__(self, **kwargs)
+
+def start(self):
+buildername=self.getProperty("buildername")
+
+self.command = '. ./oe-init-build-env; bitbake --version'
+ShellCommand.start(self)
+
+def commandComplete(self, cmd):
+result = cmd.logs['stdio'].getText()
+
+bitbakev= result.split()[-1]
+log.msg("Bitbake version: " + bitbakev)
+if cmd.didFail():
+   bitbakev = "1"
+self.setProperty('bitbakeversion', bitbakev, "Setting Bitbake Version")
+self.finished(SUCCESS)
+
+def getText(self, cmd, results):
+return ShellCommand.getText(self, cmd, results)
-- 
2.2.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [autobuilder][PATCH 2/2] BuildImages.py: Make -w flag depend on bitbake version check

2015-01-21 Thread brendan . le . foll 
From: Brendan Le Foll 

Because bitbake -w flag does not exist in verisons of bitbake prior to 1.25
BuildImages.py is broken for anything older like daisy, adding this check means
that -w will only be applied if the GetBitbakeVersion step has been run.

Signed-off-by: Brendan Le Foll 
---
 lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py
index 31a29a8..bf1ac5e 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/BuildImages.py
@@ -13,6 +13,7 @@ __email__ = "elizabeth.flana...@intel.com"
 
 from buildbot.steps.shell import ShellCommand
 from buildbot.process.buildstep import LogLineObserver
+from distutils.version import StrictVersion
 import os
 
 class BuildImages(ShellCommand):
@@ -47,7 +48,11 @@ class BuildImages(ShellCommand):
 if self.layerversion_yoctobsp is not None and 
int(self.layerversion_yoctobsp) < 2 and self.machine is not None and 
self.machine == "genericx86-64":
 self.command = "echo 'Skipping Step.'"
 else:
-self.command = ". ./oe-init-build-env; bitbake -w -k " + 
self.images
+bitbakeflags = "-k "
+# -w only exists in bitbake 1.25 and newer, use distroversion 
string and make sure we're on poky >1.7
+if self.getProperty('bitbakeversion') and 
StrictVersion(self.getProperty('bitbakeversion')) >= StrictVersion("1.25"):
+bitbakeflags += "-w "
+self.command = ". ./oe-init-build-env; bitbake " + bitbakeflags + 
self.images
 self.description = ["Building " + str(self.images)]
 ShellCommand.start(self)
 
-- 
2.2.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][meta-selinux] lxc: inherit enable-selinux

2015-01-21 Thread rongqing.li 
From: Roy Li 

inherit enable-selinux to kill the warning that lxc rdepends on libselinux,
but it isn't a build dependency

Signed-off-by: Roy Li 
---
 recipes-containers/lxc/lxc_%.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 recipes-containers/lxc/lxc_%.bbappend

diff --git a/recipes-containers/lxc/lxc_%.bbappend 
b/recipes-containers/lxc/lxc_%.bbappend
new file mode 100644
index 000..8c11cac
--- /dev/null
+++ b/recipes-containers/lxc/lxc_%.bbappend
@@ -0,0 +1 @@
+inherit enable-selinux
-- 
2.1.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cannot build the core-image-directfb for

2015-01-21 Thread Yong Li 
Thanks for your quick reply.

YES! Adding a leading space between the " and directfb, the build works, it
is building now!

Thanks again!
Yong LI
2015-01-21 16:07 GMT+08:00 Moore, Thomas (FtWorth) :

>  Try adding a space between the quotation mark and directfb:
>
> DISTRO_FEATURES_append = " directfb sysvinit"
>
> Thomas
>  --
> From: Yong Li 
> Sent: ‎1/‎21/‎2015 9:53 AM
> To: yocto@yoctoproject.org
> Cc: Yong Li 
> Subject: [yocto] Cannot build the core-image-directfb for
>
>   I can build the core-minimal or X11 image,  but I cannot build the
> directfb image, below is the error message, any suggestions?
>
>  bitbake core-image-directfb -v
> Loading cache: 100%
> |#|
> ETA:  00:00:00
> Loaded 1313 entries from dependency cache.
> Parsing recipes: 100%
> |###|
> Time: 00:00:00
> Parsing of 915 .bb files complete (914 cached, 1 parsed). 1313 targets,
> 112 skipped, 0 masked, 0 errors.
> ERROR: Nothing PROVIDES 'core-image-directfb'
> ERROR: core-image-directfb was skipped: missing required distro feature
> 'directfb' (not in DISTRO_FEATURES)
>
>  I have modified the conf/local.conf file as below:
>  DISTRO_FEATURES_append = "directfb sysvinit"
> DISTRO_FEATURES_remove = "x11 wayland"
>
>  MACHINE ??= "intel-corei7-64"
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cannot build the core-image-directfb for

2015-01-21 Thread Moore, Thomas (FtWorth) 
Try adding a space between the quotation mark and directfb:

DISTRO_FEATURES_append = " directfb sysvinit"

Thomas

From: Yong Li
Sent: ‎1/‎21/‎2015 9:53 AM
To: yocto@yoctoproject.org
Cc: Yong Li
Subject: [yocto] Cannot build the core-image-directfb for

I can build the core-minimal or X11 image,  but I cannot build the directfb 
image, below is the error message, any suggestions?

bitbake core-image-directfb -v
Loading cache: 100% 
|#|
 ETA:  00:00:00
Loaded 1313 entries from dependency cache.
Parsing recipes: 100% 
|###|
 Time: 00:00:00
Parsing of 915 .bb files complete (914 cached, 1 parsed). 1313 targets, 112 
skipped, 0 masked, 0 errors.
ERROR: Nothing PROVIDES 'core-image-directfb'
ERROR: core-image-directfb was skipped: missing required distro feature 
'directfb' (not in DISTRO_FEATURES)

I have modified the conf/local.conf file as below:
DISTRO_FEATURES_append = "directfb sysvinit"
DISTRO_FEATURES_remove = "x11 wayland"

MACHINE ??= "intel-corei7-64"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cannot build the core-image-directfb for

2015-01-21 Thread Nicolas Dechesne 
On Wed, Jan 21, 2015 at 8:51 AM, Yong Li  wrote:
> DISTRO_FEATURES_append = "directfb sysvinit"
> DISTRO_FEATURES_remove = "x11 wayland"

i think you are missing a leading space char, it's needed with
_append, or _remove. as such directfb gets concatenated with the
previous word in the variable.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto