from:"stefan"

From: Stefan Lendl 

---
 meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb 
b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
index c25b804..38149a3 100644
--- a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
+++ b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
@@ -6,12 +6,8 @@ HOMEDIR = "https://cisofy.com/;
 LICENSE = "GPL-3.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=3edd6782854304fd11da4975ab9799c1"
 
-SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz;
-
-SRC_URI[md5sum] = "5b9da89c616344bbc73cbc5688a4a0bd"
-SRC_URI[sha256sum] = 
"7a09c6fc71c65d572ca702df7b4394d71f9037484062ef71b76f59a2c498b029"
-
-S = "${WORKDIR}/${BPN}"
+SRC_URI = "git://github.com/CISOfy/Lynis.git;protocol=https;tag=${PV}"
+S = "${WORKDIR}/git"
 
 inherit autotools-brokensep
 
-- 
2.14.5

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

[yocto] [meta-security][PATCH][sumo] Use git fetcher for lynis to fetch older versions

---
 meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb 
b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
index c25b804..38149a3 100644
--- a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
+++ b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
@@ -6,12 +6,8 @@ HOMEDIR = "https://cisofy.com/;
 LICENSE = "GPL-3.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=3edd6782854304fd11da4975ab9799c1"
 
-SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz;
-
-SRC_URI[md5sum] = "5b9da89c616344bbc73cbc5688a4a0bd"
-SRC_URI[sha256sum] = 
"7a09c6fc71c65d572ca702df7b4394d71f9037484062ef71b76f59a2c498b029"
-
-S = "${WORKDIR}/${BPN}"
+SRC_URI = "git://github.com/CISOfy/Lynis.git;protocol=https;tag=${PV}"
+S = "${WORKDIR}/git"
 
 inherit autotools-brokensep
 
-- 
2.14.5

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

[yocto] [PATCH] Use lynis download link from github releases

Unlike the official download page, it also works for older releases

Signed-off-by: Stefan Lendl 
---
 meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb 
b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
index c25b804..1ee71ef 100644
--- a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
+++ b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
@@ -6,12 +6,12 @@ HOMEDIR = "https://cisofy.com/;
 LICENSE = "GPL-3.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=3edd6782854304fd11da4975ab9799c1"
 
-SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz;
+SRC_URI = "https://github.com/CISOfy/lynis/archive/${PV}.tar.gz;
 
-SRC_URI[md5sum] = "5b9da89c616344bbc73cbc5688a4a0bd"
-SRC_URI[sha256sum] = 
"7a09c6fc71c65d572ca702df7b4394d71f9037484062ef71b76f59a2c498b029"
+SRC_URI[md5sum] = "f91840acc0801b77844363fc55c5d688"
+SRC_URI[sha256sum] = 
"e143eaefec3222f98a0f74dd6dcb3818aa348dea3d0379bd3a45455911b6ee2a"
 
-S = "${WORKDIR}/${BPN}"
+S = "${WORKDIR}/${BPN}-${PV}"
 
 inherit autotools-brokensep
 
-- 
2.14.5

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

[yocto] [PATCH] Use lynis download link from github releases

Unlike the official download page, it also works for older releases

Signed-off-by: Stefan Lendl 
---
 meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb 
b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
index c25b804..1ee71ef 100644
--- a/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
+++ b/meta-security-compliance/recipes-auditors/lynis/lynis_2.5.1.bb
@@ -6,12 +6,12 @@ HOMEDIR = "https://cisofy.com/;
 LICENSE = "GPL-3.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=3edd6782854304fd11da4975ab9799c1"
 
-SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz;
+SRC_URI = "https://github.com/CISOfy/lynis/archive/${PV}.tar.gz;
 
-SRC_URI[md5sum] = "5b9da89c616344bbc73cbc5688a4a0bd"
-SRC_URI[sha256sum] = 
"7a09c6fc71c65d572ca702df7b4394d71f9037484062ef71b76f59a2c498b029"
+SRC_URI[md5sum] = "f91840acc0801b77844363fc55c5d688"
+SRC_URI[sha256sum] = 
"e143eaefec3222f98a0f74dd6dcb3818aa348dea3d0379bd3a45455911b6ee2a"
 
-S = "${WORKDIR}/${BPN}"
+S = "${WORKDIR}/${BPN}-${PV}"
 
 inherit autotools-brokensep
 
-- 
2.14.5

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

Re: [yocto] [opkg-devel] [opkg-utils PATCH] opkg-make-index: use ctime instead of mtime

2018-11-07 Thread Stefan Agner

Hi Alejandro,

On 22.10.2018 16:45, Alejandro Del Castillo wrote:
> makes sense, sounds like this is going to fix a bunch of nasty 
> intermittent failures, thanks!
> 
> merged

Thanks for merging!

With the merge in opkg-utils this is not yet actively used in OE of
course. So my question: Is there a new release of opkg-utils planned
anytime soon? Or should that be added as a patch in the OE recipe for
now?

--
Stefan

> 
> On 10/19/18 10:38 AM, Stefan Agner wrote:
>> From: Stefan Agner 
>>
>> When using sstate, two parallel builds can produce two packages
>> with the same mtime but different checksums. When later one of
>> those two builds fetches the others ipk, the package index does
>> not get udpated properly (since mtime matches). This ends up with
>> messages such as:
>>Downloading file:/../tmp/work/../image/...ipk.
>>Removing corrupt package file 
>> /../sysroot/../var/cache/opkg/volatile/...ipk
>>
>> However, in that case, ctime is different. Use ctime instead of
>> mtime to prevent failures like this.
>>
>> Suggested-by: Khem Raj 
>> Signed-off-by: Stefan Agner 
>> ---
>> This addresses the issue discussed here:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openembedded.org_pipermail_openembedded-2Dcore_2018-2DOctober_156348.html=DwIBaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ=Innit37H69hUyZPGuuhwO6R5CbUNNTfXQwxbqsEA2NE=oFvqASrFTgasDqZ901HeIBFSsf6Cn4FcBieOOBU4MdI=
>>
>>   opkg-make-index | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/opkg-make-index b/opkg-make-index
>> index 3227fc0..db7bf64 100755
>> --- a/opkg-make-index
>> +++ b/opkg-make-index
>> @@ -115,12 +115,12 @@ for abspath in files:
>>pkg = None
>>fnameStat = os.stat(abspath)
>>if filename in old_pkg_hash:
>> -  if filename in pkgsStamps and int(fnameStat.st_mtime) == 
>> pkgsStamps[filename]:
>> +  if filename in pkgsStamps and int(fnameStat.st_ctime) == 
>> pkgsStamps[filename]:
>>   if (verbose):
>>  sys.stderr.write("Found %s in Packages\n" % (filename,))
>>   pkg = old_pkg_hash[filename]
>> else:
>> -   sys.stderr.write("Found %s in Packages, but mtime differs - 
>> re-reading\n" % (filename,))
>> +   sys.stderr.write("Found %s in Packages, but ctime differs - 
>> re-reading\n" % (filename,))
>>
>>if not pkg:
>> if (verbose):
>> @@ -137,7 +137,7 @@ for abspath in files:
>>else:
>> old_filename = ""
>>s = packages.add_package(pkg, opt_a)
>> - pkgsStamps[filename] = fnameStat.st_mtime
>> + pkgsStamps[filename] = fnameStat.st_ctime
>>if s == 0:
>> if old_filename:
>>  # old package was displaced by newer
>>
> 
> -- 
> Cheers,
> 
> Alejandro
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] opkg-make-index: use ctime instead of mtime

2018-10-19 Thread Stefan Agner

From: Stefan Agner 

When using sstate, two parallel builds can produce two packages
with the same mtime but different checksums. When later one of
those two builds fetches the others ipk, the package index does
not get udpated properly (since mtime matches). This ends up with
messages such as:
  Downloading file:/../tmp/work/../image/...ipk.
  Removing corrupt package file /../sysroot/../var/cache/opkg/volatile/...ipk

However, in that case, ctime is different. Use ctime instead of
mtime to prevent failures like this.

Suggested-by: Khem Raj 
Signed-off-by: Stefan Agner 
---
This addresses the issue discussed here:
http://lists.openembedded.org/pipermail/openembedded-core/2018-October/156348.html

 opkg-make-index | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/opkg-make-index b/opkg-make-index
index 3227fc0..db7bf64 100755
--- a/opkg-make-index
+++ b/opkg-make-index
@@ -115,12 +115,12 @@ for abspath in files:
  pkg = None
  fnameStat = os.stat(abspath)
  if filename in old_pkg_hash:
-  if filename in pkgsStamps and int(fnameStat.st_mtime) == 
pkgsStamps[filename]:
+  if filename in pkgsStamps and int(fnameStat.st_ctime) == 
pkgsStamps[filename]:
 if (verbose):
sys.stderr.write("Found %s in Packages\n" % (filename,))
 pkg = old_pkg_hash[filename]
   else:
-   sys.stderr.write("Found %s in Packages, but mtime differs - 
re-reading\n" % (filename,))
+   sys.stderr.write("Found %s in Packages, but ctime differs - 
re-reading\n" % (filename,))
 
  if not pkg:
   if (verbose):
@@ -137,7 +137,7 @@ for abspath in files:
  else:
   old_filename = ""
  s = packages.add_package(pkg, opt_a)
- pkgsStamps[filename] = fnameStat.st_mtime
+ pkgsStamps[filename] = fnameStat.st_ctime
  if s == 0:
   if old_filename:
# old package was displaced by newer
-- 
2.13.6

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

Re: [yocto] Getting the version of Yocto that is being used.

2018-04-13 Thread Stefan Müller-Klieser

Hello Richard,

some of us are also around on the list.

You should find all documentation on the product page. Specifically, the
git tag of the release is "2.2.1-phy3" which indicates that the release
bundles poky morty 2.2.1. In future we will also have LAYERSERIES_COMPAT
set.

If the documentation leaves some open questions, you can also write us
directly.

Regards, Stefan

On 13.04.2018 09:59, Richard Collins wrote:
> Thanks for the help. :)
> 
> Yes they are Phytec boards. I have inherited the project from a 3rd party
> and so in the mids of chasing up the support contacts and our account
> details for their site. I'm sure you've all played the "Q) What are the
> support / login details? A) I don't know, ask X, ask Y, ask Z.,
> ask" development game. ;)
> 
> On 12 April 2018 at 19:45, Josef Holzmayr <holzm...@rsi-elektrotechnik.de>
> wrote:
> 
>> On Thu, Apr 12, 2018 at 01:11:17PM +0100, Richard Collins wrote:
>>> I get the following for DISTRO.
>>>
>>> DISTRO= "yogurt"
>>> DISTRO_VERSION= "BSP-Yocto-RK3288-PD17.1.1"
>>>
>>
>> For further reference by anyone who is reading this in the archive: the
>> supplier is Phytec, and the distro layer is here:
>> https://git.phytec.de/meta-yogurt/
>>
>> Greetz
>> --
>> ———
>> Josef Holzmayr
>> Software Developer Embedded Systems
>>
>> Tel: +49 8444 9204-48
>> Fax: +49 8444 9204-50
>>
>> R-S-I Elektrotechnik GmbH & Co. KG
>> Woelkestrasse 11
>> D-85301 Schweitenkirchen
>> www.rsi-elektrotechnik.de
>> ———
>> Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
>> Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
>> Ust-IdNr: DE 128592548
>>
>> _
>> Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
>> Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
>> USt-IdNr.: DE 128592548
>>
>>
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] php extensions

2018-01-31 Thread Stefan Müller-Klieser

Hi everyone,

I am trying to get to run the php redis extension with current master
and php 7.1.9 from meta-oe. There are no other php extensions in
openembedded yet.
I am using the default php.ini and just add the redis.so. Everything
seems to work fine except that php does not load any extension. php -m
shows a lot of php modules, those seem to be compiled in. Running php-cli
with strace shows that there is no access at all to the extension directory.
Has anyone a hint where to look?

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

Re: [yocto] Solved : Re: Problems building U-Boot for x86_64

2017-11-30 Thread Stefan Roese

 and
modify the recipe to use that?



My conclusion: I have some bb variable set to the wrong value or I
need to get multilib installed into //sysroots/x86_64-linux/lib.

So how to do that?


sysroots/lib32-edison/usr/lib/i686-pokymllib32-linux/6.2.0/
sysroots/lib32-edison-tcbootstrap/usr/lib/i686-pokymllib32-

linux/6.2.0/

sysroots/edison/usr/lib64/x86_64-poky-linux/6.2.0/
sysroots/edison-tcbootstrap/usr/lib64/x86_64-poky-linux/6.2.0/

How compile log shows:
NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux-
CC=x86_64-poky-linux-gcc --sysroot=//sysroots/edison V=1
HOSTCC=gcc -isystem//sysroots/x86_64-linux/usr/include -O2
-pipe -L//sysroots/x86_64-linux/usr/lib
-L//sysroots/x86_64-linux/lib
-Wl,-rpath-link,//sysroots/x86_64-linux/usr/lib
-Wl,-rpath-link,//sysroots/x86_64-linux/lib
-Wl,-rpath,//sysroots/x86_64-linux/usr/lib
-Wl,-rpath,//sysroots/x86_64-linux/lib -Wl,-O1 -C
//out/linux64/build/tmp/work/edison-poky-linux/u-boot/edison-
v2017.03-r0/git
O=//out/linux64/build/tmp/work/edison-poky-linux/u-
boot/edison-v2017.03-r0/build edison_defconfig

( my edits to shorten the uninteresting part of the path)

I would think: --sysroot points to /edison dir which actually
contains libgcc.a, but -i, _l and -W1 options point to host dirs
that don't have the lib.



I attempted to add multilib, but although that immediately
exposed bugs in other recipes but actually adds libgcc.a, it
does that for the target sysroot only.

And for some reason, U-Boot is built with the native gcc
(x86_64-linux),
and multilib does not add libgcc.a to that sysroot.

So, how do I add multilib to -native sysroot, preferably only to
-native and not to the target, as the target has not further use
for it?

Strangest thing is in u-boot.inc there is:
EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX}
CC="${TARGET_PREFIX}gcc ${TOOLCHAIN_OPTIONS}" V=1'
EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS}
${BUILD_LDFLAGS}"'

But when I check my log file:
NOTE: make -j8 CROSS_COMPILE=x86_64-poky-linux-
CC=x86_64-poky-linux- gcc  ..

So TARGET_PREFIX resolves to x86_64-poky-linux, but I think my
target is core2_64 (or something like that). Is that normal for
U-Boot?


thats ok.



I am a little lost, so any help would be greatly appreciated


I added multilib to the meta0intel-edison-bsp machine conf:
#multilib
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
IMAGE_INSTALL_append = " lib32-libgcc"

This exposes a lot recipy bugs in other places that needed to be fixed
first.

Then I changed IMAGE_INSTALL += "u-boot" to "lib32_u-boot". Now it builds
without error.

Now I changed IMAGE_INSTALL tot EXTRA_IMAGEDEPENDS. I believe that will
prevent u-boot and the otherwise unecessary multilib to be installed on
the image. Not sure if that really works out as I hope.

All of this now causes populate_sdk to fail, but I will post that
seperately.

Thanks all for the usefull comments.


Just a quick update on this. I recently sent a patch to the U-Boot list,
fixing this x86 toolchain dependency in mainline U-Boot:

https://patchwork.ozlabs.org/patch/842613/

This patch will be included in the upcoming release (2018.01).

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

[yocto] [meta-yocto-bsp][PATCH] machine: mpc8315e-rdb: change kernel provider assignment to default

2017-08-24 Thread Stefan Müller-Klieser

To be able to configure the kernel provider at other locations, we need
a default assignment here.

Signed-off-by: Stefan Müller-Klieser <s.mueller-klie...@phytec.de>
---
 meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf 
b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
index ce5015256a23..b6cb49b58358 100644
--- a/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
+++ b/meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf
@@ -15,7 +15,7 @@ SERIAL_CONSOLE = "115200 ttyS0"
 MACHINE_FEATURES = "keyboard pci ext2 ext3 serial"
 
 PREFERRED_VERSION_linux-yocto ?= "4.10%"
-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 
 PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 XSERVER ?= "xserver-xorg \
-- 
1.9.1

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

[yocto] [meta-qt4][PATCH] qt4: add patch which fixes 24-bit color depth

2016-10-25 Thread Stefan Agner

From: Stefan Agner <stefan.ag...@toradex.com>

Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
---
 recipes-qt4/qt4/qt4-4.8.7.inc  |  1 +
 .../0001-QWS-fix-24-bit-RGB-BGR-handling.patch | 36 ++
 2 files changed, 37 insertions(+)
 create mode 100644 
recipes-qt4/qt4/qt4-4.8.7/0001-QWS-fix-24-bit-RGB-BGR-handling.patch

diff --git a/recipes-qt4/qt4/qt4-4.8.7.inc b/recipes-qt4/qt4/qt4-4.8.7.inc
index 5ecf7fd..16b22a8 100644
--- a/recipes-qt4/qt4/qt4-4.8.7.inc
+++ b/recipes-qt4/qt4/qt4-4.8.7.inc
@@ -30,6 +30,7 @@ SRC_URI = 
"http://download.qt-project.org/official_releases/qt/4.8/${PV}/qt-ever
file://gcc-6.patch \
file://Fix-QWSLock-invalid-argument-logs.patch \
file://add_check_for_aarch64_32.patch \
+   file://0001-QWS-fix-24-bit-RGB-BGR-handling.patch \
file://g++.conf \
file://linux.conf \
file://fix-for-mips-n32.patch \
diff --git 
a/recipes-qt4/qt4/qt4-4.8.7/0001-QWS-fix-24-bit-RGB-BGR-handling.patch 
b/recipes-qt4/qt4/qt4-4.8.7/0001-QWS-fix-24-bit-RGB-BGR-handling.patch
new file mode 100644
index 000..45856b0
--- /dev/null
+++ b/recipes-qt4/qt4/qt4-4.8.7/0001-QWS-fix-24-bit-RGB-BGR-handling.patch
@@ -0,0 +1,36 @@
+From 9722a85dd2b4a7210af66e2a135fe7aded5075c7 Mon Sep 17 00:00:00 2001
+From: Stefan Agner <stefan.ag...@toradex.com>
+Date: Tue, 25 Oct 2016 14:37:02 -0700
+Subject: [PATCH] QWS: fix 24 bit RGB/BGR handling
+
+Use blit_24 for default 24-bit RGB case. This makes sure Qt works
+well with frame buffer using [23:0] R:G:B (little endian) pixel
+format. See also:
+https://bugreports.qt.io/browse/QTBUG-56740
+
+Upstream-Status: Submitted
+
+Signed-off-by: Stefan Agner <stefan.ag...@toradex.com>
+---
+ src/gui/embedded/qscreen_qws.cpp | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/gui/embedded/qscreen_qws.cpp 
b/src/gui/embedded/qscreen_qws.cpp
+index 407366c..a4ece07 100644
+--- a/src/gui/embedded/qscreen_qws.cpp
 b/src/gui/embedded/qscreen_qws.cpp
+@@ -1208,9 +1208,9 @@ void qt_blit_setup(QScreen *screen, const QImage ,
+ #ifdef QT_QWS_DEPTH_24
+ case 24:
+ if (screen->pixelType() == QScreen::NormalPixel)
+-screen->d_ptr->blit = blit_qrgb888;
+-else
+ screen->d_ptr->blit = blit_24;
++else
++screen->d_ptr->blit = blit_qrgb888;
+ break;
+ #endif
+ #ifdef QT_QWS_DEPTH_18
+-- 
+2.10.0
+
-- 
1.9.1

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

Re: [yocto] QA python3 runtime dependency

2016-09-16 Thread Stefan Müller-Klieser

On 16.09.2016 13:45, Chris Trobridge wrote:
> My top-level python3 scripts have "#!/usr/bin/python3" and the recipe 
> RDEDENDS on python3.

I guess this is what you need:

RDEPENDS_${PN} = "python3-core"

As the interpreter is in the -core package.

Regards, Stefan

> There's no problem in the final system as python3 is present in /usr/bin as 
> expected.
> What I do not understand is why I am getting a QA warning : "requires 
> /usr/bin/python3, but no providers found in RDEPENDS? [file-rdeps]".
> Any ideas why this is happening?
> Thanks,Chris
> 
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] problem with nativesdk host tools

2015-10-24 Thread Stefan Müller-Klieser


Dear community,

my problem: I want to provide a populate_sdk based toolchain for e.g. 
compiling a kernel. When using this sdk on a machine missing the 
ncurses-dev package, you can run "make menuconfig" through bitbake but 
not with the sdk. The sdk seems to ignore host dependencies and there 
are some bug tracker entries related to this. It does not seem to help 
to create:

recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bbappend
RDEPENDS_${PN} += "\
nativesdk-ncurses \
nativesdk-ncurses-dev \
"
as the corresponding changes to the include and library search path are 
not handled correctly. In meta-qt5 there is some larger effort 
undertaken resolving similar issues.
Can someone please clarify what the status concerning the host 
dependencies and the nativesdk is? Am I missing something? Is this a use 
case for the extensible sdk?


Thanks in advance!
Yours, Stefan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Busybox sh link

2014-11-19 Thread Stefan Eichenberger


On 11/19/2014 07:00 AM, ChenQi wrote:

On 11/19/2014 12:34 AM, Stefan Eichenberger wrote:

On 11/18/2014 04:07 AM, ChenQi wrote:

On 11/17/2014 10:07 PM, Stefan Eichenberger wrote:

Hello all

I have a question regarding busybox and sh. If I want to install 
bash together with busybox ash, yocto does not consider the 
ALTERNATIVE_PRIORITY in each case (e.g. if bash is installed before 
busybox). The problem is that do_install of busybox creates a link 
to busybox.nosuid. Is there a reason for that? Shouldn't 
update-alternatives create that link for us? There is already a 
patch available that targets this problem 
(467b19efbaa9c0cb04d2665e8cd9a0919849a5ed ) but it only works if 
ash is completely disabled in the busybox config.


So the main question is, wouldn't it be possible to remove this 
lines completely?


Regards,
Stefan




I can confirm that this is indeed a problem. And we need to fix this.
I think the reason for this line is mainly to make 'busybox' provide 
'/bin/sh' so that do_rootfs would succeed.


Regards,
Chen Qi


Probably I miss something but I don't understand why do_rootfs fails 
if the link is not provided? Isn't the link created anyhow during 
package installation in the postinstall script with 
update-alternatives if necessary?


For testing I removed the link creation temporary from the recipe and 
built the core-image-minimal for qemux86, it was creating the link 
correctly in this case.


Regards,
Stefan




Hi Stefan,

I did some testing, and could not reproduce the problem.
I then realized that as the sh link is managed by ALTERNATIVES 
mechanism, it will always point to bash instead of busybox.


I tested it by the following steps:
1. build core-image-minimal with bash installed
2. reinstall bash
3. reinstall busybox

So I think the current code is right.

I'm not sure if I missed something. If so, could you please provide 
more information?


Best Regards,
Chen Qi


Hi Chen,

You are right, sorry! I think I figured out what I've missed. On an 
image I have disabled busybox ash completely, therefore I didn't saw the 
update-alternative running for sh. Because it was an older version of 
yocto without the above patch, I've got an invalid image. I then tough 
the same problem would appear if I enable busybox ash again, but in this 
case update-alternative would run, so the problem wouldn't appear.


Sorry for the false alarm!

Regards,
Stefan



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

Re: [yocto] Busybox sh link

2014-11-18 Thread Stefan Eichenberger


On 11/18/2014 04:07 AM, ChenQi wrote:

On 11/17/2014 10:07 PM, Stefan Eichenberger wrote:

Hello all

I have a question regarding busybox and sh. If I want to install bash 
together with busybox ash, yocto does not consider the 
ALTERNATIVE_PRIORITY in each case (e.g. if bash is installed before 
busybox). The problem is that do_install of busybox creates a link to 
busybox.nosuid. Is there a reason for that? Shouldn't 
update-alternatives create that link for us? There is already a patch 
available that targets this problem 
(467b19efbaa9c0cb04d2665e8cd9a0919849a5ed ) but it only works if ash 
is completely disabled in the busybox config.


So the main question is, wouldn't it be possible to remove this lines 
completely?


Regards,
Stefan




I can confirm that this is indeed a problem. And we need to fix this.
I think the reason for this line is mainly to make 'busybox' provide 
'/bin/sh' so that do_rootfs would succeed.


Regards,
Chen Qi


Probably I miss something but I don't understand why do_rootfs fails if 
the link is not provided? Isn't the link created anyhow during package 
installation in the postinstall script with update-alternatives if 
necessary?


For testing I removed the link creation temporary from the recipe and 
built the core-image-minimal for qemux86, it was creating the link 
correctly in this case.


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

[yocto] Busybox sh link

2014-11-17 Thread Stefan Eichenberger

Hello all

I have a question regarding busybox and sh. If I want to install bash together 
with busybox ash, yocto does not consider the ALTERNATIVE_PRIORITY in each case 
(e.g. if bash is installed before busybox). The problem is that do_install of 
busybox creates a link to busybox.nosuid. Is there a reason for that? Shouldn't 
update-alternatives create that link for us? There is already a patch available 
that targets this problem (467b19efbaa9c0cb04d2665e8cd9a0919849a5ed ) but it 
only works if ash is completely disabled in the busybox config.

So the main question is, wouldn't it be possible to remove this lines 
completely?

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

[yocto] How to access the sysroot from CMake

2014-07-17 Thread Stefan Hofmann

Hi !

I have a package, which installs a VAPI-file in /usr/share/${PN}/${PN}.vapi. 
These files are required by the Vala-compiler (C#-like language for GObject) to 
interface with C-Code. However I cannot access it from a dependent package. 
What is the correct way to access files installed by other packages ? I cannot 
find anything in the documentation. Is it possible to do that from CMake too ?

Thank you very much  best regards
Stefan

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

Re: [yocto] Understanding Package groups

2014-07-09 Thread Stefan Hofmann

Hi Rudolf,

thank you for your explanation. bash has not been installed, but HOB did some 
changes on the configuration files and I modified the distribution. I deleted 
everything and created my own image receipe. It works fine now.

Regards,
Stefan

Am 01.07.2014 um 22:34 schrieb Rudolf Streif rstr...@linuxfoundation.org:

 Hi Stefan,
 
 You probably have found the explanation on package groups in the reference 
 manual [1].
 
 Package groups are recipes with the sole purpose to create dependencies to 
 simplify image creation. A package group recipe bundles multiple packages 
 together and then instead of having to explicitly specify each package in the 
 IMAGE_INSTALL variable you can simply specify the package group name.
 
 Package group recipes look like this (from the manual):
 
 DESCRIPTION = My Custom Package Groups
 
  inherit packagegroup
 
  PACKAGES = \
  packagegroup-custom-apps \
  packagegroup-custom-tools \
  
 
  RDEPENDS_packagegroup-custom-apps = \
  dropbear \
  portmap \
  psplash
 
  RDEPENDS_packagegroup-custom-tools = \
  oprofile \
  oprofileui-server \
  lttng-control \
  lttng-viewer
 
  RRECOMMENDS_packagegroup-custom-tools = \
  kernel-module-oprofile
 
 
 Like any recipe they have a description. They inherit the 
 packagegroup.bbclass. A package group recipe can define multiple package 
 groups in the PACKAGES variable. For each package group listed in PACKAGES 
 you will then need to specify the packages that actually go into them with 
 conditional RDEPENDS_packagegroupname variables.
 
 Package groups are only relevant for the YP build system. They do not create 
 package grouping for the package manager that you are using for your target. 
 However, if you select a package group from HOB then all of the packages 
 specified in that group should be installed in your target's rootfs by YP.
 
 Rudi
 
 
 
 [1] 
 http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#usingpoky-extend-customimage-customtasks
 
 
 On Tue, Jul 1, 2014 at 10:05 AM, Stefan Hofmann stefan.hofm...@mobserve.de 
 wrote:
 Hi,
 
 I made my first steps with yocto and everything worked fine so far. But now I 
 am struggling with package groups. What I basically want, is a image for a 
 base system, which allows me to install additional packages over the air with 
 opkg. In my imagination package groups are something like preselected 
 packages, which need to be installed at once similar like it is handled in 
 Debian for X11-support for example. Is this right ? I have built 
 core-image-base for testing purposes and tried to figure out the dependencies 
 by using the Hob tool. It says that bash will be installed and the group 
 base/shell is responsible for that. However it is not installed, only ash 
 and I cannot find a package group package-group-base-shell in the receipes. 
 It does however exist in the work directory. So now I am somewhat confused.
 
 Regards,
 Stefan
 
 -- 
 
 
 
 --
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto
 
 
 
 
 

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

[yocto] Understanding Package groups

2014-07-01 Thread Stefan Hofmann


Hi,

I made my first steps with yocto and everything worked fine so far. But 
now I am struggling with package groups. What I basically want, is a 
image for a base system, which allows me to install additional packages 
over the air with opkg. In my imagination package groups are something 
like preselected packages, which need to be installed at once similar 
like it is handled in Debian for X11-support for example. Is this right 
? I have built core-image-base for testing purposes and tried to figure 
out the dependencies by using the Hob tool. It says that bash will be 
installed and the group base/shell is responsible for that. However it 
is not installed, only ash and I cannot find a package group 
package-group-base-shell in the receipes. It does however exist in the 
work directory. So now I am somewhat confused.


Regards,
Stefan

--




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mingw] build error

2014-05-22 Thread Stefan Seefeld

On 2014-05-22 02:10, Richard Purdie wrote:
 On Wed, 2014-05-21 at 16:45 -0400, Stefan Seefeld wrote:
 Hello,

 I started experimenting with the meta-mingw layer today, using the
 'daisy' branch for both, poky as well as meta-mingw.

 Running `bitbake meta-toolchain`, the build process failed in one of the
 last steps (1003 of 1005) with:

 ERROR: nativesdk-packagegroup-sdk-host not found in the base feeds
 (x86_64-nativesdk-mingw32 noarch any all).

 Any idea what I may be missing ? I'm using

 MACHINE ??= qemux86
 SDKMACHINE ?= x86_64-mingw32
 
 Which pacxkage backend were you using? If you didn't use ipk, I'd
 suggest trying it. In theory others should work but its ipk I've been
 using when working with those layers.

OK, I was using rpm (the default), but now switched to ipk. That results
in a different error in meta/lib/oe/sdk.py:55, where do_populate() tries
to link ld.so.cache into a non-existent directory.
I have attempted a fix with the attached patch.

With that, things now appear to be working. (I think things should also
work with 'rpm' as package backend, though, right ? Should I file a bug
report somewhere to put that on record ?)

Thanks,
Stefan


-- 
Stefan Seefeld
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software/
diff --git a/meta/lib/oe/sdk.py b/meta/lib/oe/sdk.py
index 5643199..4a03e96 100644
--- a/meta/lib/oe/sdk.py
+++ b/meta/lib/oe/sdk.py
@@ -50,8 +50,9 @@ class Sdk(object):
  *.la))
 
 # Link the ld.so.cache file into the hosts filesystem
-link_name = os.path.join(self.sdk_output, self.sdk_native_path,
- self.sysconfdir, ld.so.cache)
+sysconfdir = os.path.join(self.sdk_output, self.sdk_native_path, self.sysconfdir)
+bb.utils.mkdirhier(sysconfdir)
+link_name = os.path.join(sysconfdir, ld.so.cache)
 os.symlink(/etc/ld.so.cache, link_name)
 
 execute_pre_post_process(self.d, self.d.getVar('SDK_POSTPROCESS_COMMAND', True))
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mingw] build error

2014-05-21 Thread Stefan Seefeld

Hello,

I started experimenting with the meta-mingw layer today, using the
'daisy' branch for both, poky as well as meta-mingw.

Running `bitbake meta-toolchain`, the build process failed in one of the
last steps (1003 of 1005) with:

ERROR: nativesdk-packagegroup-sdk-host not found in the base feeds
(x86_64-nativesdk-mingw32 noarch any all).

Any idea what I may be missing ? I'm using

MACHINE ??= qemux86
SDKMACHINE ?= x86_64-mingw32

Thanks,

Stefan


-- 
Stefan Seefeld
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-mono core-image-mono failing

2014-05-21 Thread Stefan Stanacar

On Wed, May 21, 2014 at 11:15 PM, Alex J Lennon
ajlen...@dynamicdevices.co.uk wrote:

 On 21/05/2014 20:07, Chris Morgan wrote:
 On Wed, May 21, 2014 at 2:57 PM, Gary Thomas g...@mlbassoc.com wrote:
 On 2014-05-21 12:25, Chris Morgan wrote:
 Hello.

 I'm trying to build core-image-mono for the bbb. Layers configuration:

 Build Configuration:
 BB_VERSION= 1.23.1
 BUILD_SYS = x86_64-linux
 NATIVELSBSTRING   = Fedora-20
 TARGET_SYS= arm-poky-linux-gnueabi
 MACHINE   = beaglebone
 DISTRO= poky
 DISTRO_VERSION= 1.6+snapshot-20140521
 TUNE_FEATURES = arm armv7a vfp neon
 TARGET_FPU= vfp-neon
 meta  = master:8293f564685d0f587ab63a107285625dc4f98f1c
 meta-bbb  = master:8318556523a747b7e9c97326bef14922a154e8a2
 common-bsp=
 (detachedfrome7dc54e):e7dc54e66f4b5c2982a30bef5c67d734e9c759f5
 meta-yocto
 meta-yocto-bsp= master:8293f564685d0f587ab63a107285625dc4f98f1c
 meta-mono = master:e2d2b8a518403a255822022c9e15f116c91b5dd1

 This is basically master of Poky and meta-mono.


 | DEBUG: Executing shell function do_configure
 | grep: configure.in: No such file or directory
 |
 /home/cmorgan/projects/yocto_poky/build/tmp/work/x86_64-linux/mono-native/3.4.0-r0/mono-3.4.0/autogen.sh:
 line 125: mono/mini/Makefile.am: No such file or directory
 |
 /home/cmorgan/projects/yocto_poky/build/tmp/work/x86_64-linux/mono-native/3.4.0-r0/mono-3.4.0/autogen.sh:
 line 126: mono/metadata/Makefile.am: No such file or directory
 | Running aclocal -I m4 -I .  ...
 | aclocal: error: 'configure.ac' is required
 |
 | **Error**: aclocal failed. This may mean that you have not
 | installed all of the packages you need, or you may need to
 | set ACLOCAL_FLAGS to include -I $prefix/share/aclocal
 | for the prefix where you installed the packages whose
 | macros were not found
 | NOTE: mono-native failed to autogen.sh
 | sed: can't read acinclude.m4: No such file or directory
 | WARNING:
 /home/cmorgan/projects/yocto_poky/build/tmp/work/x86_64-linux/mono-native/3.4.0-r0/temp/run.do_configure.24402:1
 exit 2 from
 |   sed -e s|slash\}libtool|slash\}x86_64-linux-libtool| -i acinclude.m4
 | ERROR: Function failed: do_configure (log file is located at

 /home/cmorgan/projects/yocto_poky/build/tmp/work/x86_64-linux/mono-native/3.4.0-r0/temp/log.do_configure.24402)
 ERROR: Task 687

 (/home/cmorgan/projects/yocto_poky/meta-mono/recipes-mono/mono/mono-native_3.4.0.bb,
 do_configure) failed with exit code '1'


 It looks like the issue is due to autogen.sh assuming several files
 are located in the current working directory, for instance on lines
 102, 129 and 130 of autogen.sh there is no use of the $srcdir variable
 before files like configure.in or mono/metadata/Makefile.am.in etc.

 Not sure if something has changed on the yocto side to change this
 assumption about where autogen.sh is being run from.

 Look at your recipe(s).  The simple way to fix this is to change
 'inherit autotools' to 'inherit autotools-brokensep'

 You could also look at the recipe more deeply and figure out
 where it assumes that ${S} == ${B} because of a recent change
 in OE-core, this is no longer true when you inherit autotools.

 Testing now with autotools-brokensep in mono-3.4.0.inc.

 I did look a bit and it looked like there were several places where
 source and build were assumed but I'm not confident that it would be
 easy to figure out what to fix and then create a patch for it but I
 could look at that and feeding it back to the mono guys. Let me do
 that and see how I make out.

 Chris

 Strange. I've been building pretty regularly recently with daisy on
 Ubuntu 12.04 without problems.

 There have been issues with Linux Mint, x64 hosts, and host
 installations of Mono, but I thought I had finally addressed those. It's
 starting to feel a little like a game of whack-a-mole.

 Can you provide me your local.conf and I'll have a look at what happens
 here with your hashes for  bbb on a Fedora box.



The reason you don't see this is because you are building on daisy,
but Chris is building on master. I doubt it it has something to do
with the host distro.
Specifically master enables separate build dir by default in
autotools.bbclass whereas daisy doesn't.

Daisy has these:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=daisyid=bf33e93f162c9fbba079b4de01c35dcb367c0577
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=daisyid=069de520ec864fc78084e8f1ddfb20edaab55f5e

which enable only the core recipes and then marks the broken ones, but
master has one more:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=69b6eaca3d9b635e8a61a0fdbd814b558e91901d


which breaks other layers with recipes that don't work with B!=S and
they should either get fixed or use autotools-brokensep, so I guess
Chris's patch is the way to go for now...

Cheers,
Stefan


 Thanks,

 Alex

 --
 ___
 yocto mailing list
 yocto

Re: [yocto] [yocto-autobuilder][PATCH v1 4/4] GetDeployDir.py/PublishArtifacts.py: get deploy dir from bitbake

2014-05-17 Thread Stefan Agner

Hi Beth,

Am 2014-05-16 19:11, schrieb Flanagan, Elizabeth:
 Ok, so looking at this a bit more and I think we need to look at how
 we set up the deploydir in PublishArtifacts a bit more.
 
 I think what we can do here is pull the functionality that we have in
 getDeployNames out, and put it into GetDeployDir (layerversion here
 matters as the default deploy for oe-core changes at LAYERVERSION_core
 =3) . So, yeah, if you could resubmit that I think we can pull the
 last patch in. The other three are under test right now.

Sounds reasonable, I agree. Note that, I will be in vacation for the
next three weeks, hence it will be June until I will be able to resubmit
that... 


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

Re: [yocto] [yocto-autobuilder][PATCH v1 0/4] fixes for use with Angstrom

2014-05-17 Thread Stefan Agner

Hi Beth,

Am 2014-05-15 17:32, schrieb Flanagan, Elizabeth:
Today I had troubles with our builder. After removing the whole source
directory and restart the build, the autobuilder somehow checked out and
resetted the autobuilder git! (the dora branch was checked out, which I
tried to checkout from a source branch). So far I could not reconstruct
what exactly happend, but the builder must have been in the wrong
directory when issuing some commands... Ugly. Calls for sandboxes :-)

Ah. Please switch to master. There was a VERY VERY nasty bug that is
probably still in dora caused by the yoctogit fetcher. I'll look at
dora today and backport the patch.

Actually I was running master of Autobuilder. However, somehow
Autobuilder checked the branch dora out (its the branch I tried to
build, hence all my layers had dora as branch name).

Anyway, I lost my custom master.cfg since git restored the version from
the dora branch (always remember to backup!)...

Yeah, when I was debugging it, I ended up scripting my setup just to
figure out what was wrong.

Inbetween I figured out what happened: A git repository (fsl-arm-extra)
was somehow broken in my download folder. Hence the clone from the
download folder to the source directory failed. However, the git fetch
was done anyway, but since the clone failed that folder was not a valid
git repository. But since the yocto-slave lives under the Yocto
Autobuilder repository, git checked out the dora branch of the Yocto
Autobuilder repository...

Its crucial to check the return status of the git clone command and
don't call further commands if clone fails. If those two commands would
be two BuildBot steps, wouldn't it do this automatically?

First command:

git clone -s -n
/tmp/yocto-autobuilder/git/mirror/git.yoctoproject.org/meta-fsl-arm/ .
in dir
/build/linuxdev/yocto-autobuilder/yocto-slave/toradex/source/git://git.yoctoproject.org/meta-fsl-arm
(timeout 10 secs)
watching logfiles {}
argv: ['git', 'clone', '-s', '-n',
'/tmp/yocto-autobuilder/git/mirror/git.yoctoproject.org/meta-fsl-arm/',
'.']

Output:
Cloning into '.'...
error: refs/heads/master does not point to a valid object!
error: refs/remotes/origin/1.4_M3 does not point to a valid object!
error: refs/remotes/origin/1.4_M5 does not point to a valid object!
error: refs/remotes/origin/danny does not point to a valid object!
error: refs/remotes/origin/danny-next does not point to a valid object!
error: refs/remotes/origin/denzil does not point to a valid object!
error: refs/remotes/origin/dora does not point to a valid object!
error: refs/remotes/origin/dora-next does not point to a valid object!
error: refs/remotes/origin/dylan does not point to a valid object!
error: refs/remotes/origin/dylan-next does not point to a valid object!
error: refs/tags/1.2 does not point to a valid object!
error: refs/tags/1.2-rc1 does not point to a valid object!
error: refs/tags/1.3 does not point to a valid object!
error: refs/tags/1.4 does not point to a valid object!
error: refs/tags/1.5 does not point to a valid object!
done.
error: Trying to write ref HEAD with nonexistent object
c91ef2d2a12cd51af20011a4de8d9438e2d4890e
fatal: Cannot update the ref 'HEAD'.
fatal: The remote end hung up unexpectedly

Then, the second command:
git fetch -t --prune git://git.yoctoproject.org/meta-fsl-arm
+refs/heads/dora:refs/remotes/dora
in dir
/build/linuxdev/yocto-autobuilder/yocto-slave/toradex/source/git://git.yoctoproject.org/meta-fsl-arm
(timeout 10 secs)
watching logfiles {}
argv: ['git', 'fetch', '-t', '--prune',
'git://git.yoctoproject.org/meta-fsl-arm',
'+refs/heads/dora:refs/remotes/dora']
...

This resetted my head of the Yocto Autobuilder to dora...

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

Re: [yocto] [yocto-autobuilder][PATCH v1 0/4] fixes for use with Angstrom

2014-05-15 Thread Stefan Agner

Am 2014-05-08 18:44, schrieb ste...@agner.ch:
 From: Stefan Agner ste...@agner.ch
 
 Hi folks,
 
 We plan to make use of the Yocto Autobuilder at Toradex. I successfully
 deployed an installation, however since we distribute an Anstrom based
 BSP I had to adjust some files. With those patches and a custom layer
 configuration (not included since quite ugly) I'm able to build our BSP.
 
 Would be good to have those changes upstream. Especially the new way to
 preserve the order of builders is more generic, however maybe not yet
 perfect. I needed this especially since I build some other stuff using
 POBBC (plain old build bot configuration :-)).
 
 Just as a general question: What is planned with the autobuilder in 
 general? Is there an integration planned with Toaster? As far as I can
 see, since the build directory is recreated each time, this is not
 really possible right now. It would need adjustment to the autobuilder
 to start the toaster web interface for each builder, and clean/restart
 builds in a way that doesn't interfere with Toaster. Any thoughts on
 this?

Any thoughts on this Patchset?

Today I had troubles with our builder. After removing the whole source
directory and restart the build, the autobuilder somehow checked out and
resetted the autobuilder git! (the dora branch was checked out, which I
tried to checkout from a source branch). So far I could not reconstruct
what exactly happend, but the builder must have been in the wrong
directory when issuing some commands... Ugly. Calls for sandboxes :-)

Anyway, I lost my custom master.cfg since git restored the version from
the dora branch (always remember to backup!)...
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder][PATCH v1 0/4] fixes for use with Angstrom

2014-05-09 Thread stefan

From: Stefan Agner ste...@agner.ch

Hi folks,

We plan to make use of the Yocto Autobuilder at Toradex. I successfully
deployed an installation, however since we distribute an Anstrom based
BSP I had to adjust some files. With those patches and a custom layer
configuration (not included since quite ugly) I'm able to build our BSP.

Would be good to have those changes upstream. Especially the new way to
preserve the order of builders is more generic, however maybe not yet
perfect. I needed this especially since I build some other stuff using
POBBC (plain old build bot configuration :-)).

Just as a general question: What is planned with the autobuilder in 
general? Is there an integration planned with Toaster? As far as I can
see, since the build directory is recreated each time, this is not
really possible right now. It would need adjustment to the autobuilder
to start the toaster web interface for each builder, and clean/restart
builds in a way that doesn't interfere with Toaster. Any thoughts on
this?

--
Stefan

Stefan Agner (4):
  GetDistroVersion.py support for Angstrom distro version
  README: add high level overview, fix build slave description
  master.py/botmaster.py: use builders list for builders order
  GetDeployDir.py/PublishArtifacts.py: get deploy dir from bitbake

 README |  8 ++--
 README-NEW-AUTOBUILDER | 11 +
 .../site-packages/autobuilder/Autobuilder.py   | 17 
 .../autobuilder/buildsteps/GetDeployDir.py | 47 +
 .../autobuilder/buildsteps/GetDistroVersion.py |  7 +++-
 .../autobuilder/buildsteps/PublishArtifacts.py | 48 --
 .../buildbot/process/botmaster.py  |  3 +-
 .../buildbot/status/master.py  | 12 +-
 8 files changed, 106 insertions(+), 47 deletions(-)
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/GetDeployDir.py

-- 
1.9.0

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

[yocto] [yocto-autobuilder][PATCH v1 2/4] README: add high level overview, fix build slave description

2014-05-09 Thread stefan

From: Stefan Agner ste...@agner.ch

Replace builders with build slaves, since this are different things
in BuildBot world. Also add a section with some high level view
what Autobuilder actually is.

Signed-off-by: Stefan Agner ste...@agner.ch
---
 README |  8 
 README-NEW-AUTOBUILDER | 11 +++
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/README b/README
index c7c9acf..3b418fd 100644
--- a/README
+++ b/README
@@ -26,7 +26,7 @@ Setup
connection that I haven't figured out yet. Manually connecting seems to 
set up the session correctly.)
 
-2. Adding additional builders
+2. Adding additional build slaves
 
 The production yocto autobuilder uses a cluster of build slaves, all 
sharing
 the same SSTATE_DIR and DL_DIR via an NFS4 mounted NAS. The main nightly 
@@ -36,7 +36,7 @@ Setup
 In theory you could also run your build slaves with NO_NETWORK to enforce 
a 
 single point of populating DL_DIR.
 
-Running multiple builders is fairly simple, but does require some setup.
+Running multiple build slaves is fairly simple, but does require some 
setup.
 
 1. Ensure the autobuilder.conf for each build slave is appropriate. As
certain variables are set within this file that are local to each 
builder
@@ -45,7 +45,7 @@ Setup
 2. Within yocto-master/master.cfg make the following changes substituing 
PASS for your debug password and  max_builds for the number of builds 
you wish to run on each builder. Your main builder that will run the 
-   nightly trigger buildset should have at least 2 builders running.
+   nightly trigger buildset should have at least 2 build slaves running.
 
 
 c['slaves'] = [BuildSlave(builder1, PASS, max_builds=3),
@@ -53,7 +53,7 @@ c['slaves'] = [BuildSlave(builder1, PASS, max_builds=3),
BuildSlave(builder3, PASS, max_builds=3),
BuildSlave(builder4, PASS, max_builds=3)]
 
-3. For each buildslave change yocto-slave/buildbot.tac to point to the 
+3. For each build slave change yocto-slave/buildbot.tac to point to the 
correct build master and port. The default setup points to local host.
 
 buildmaster_host = 'builder1.myproject.org'
diff --git a/README-NEW-AUTOBUILDER b/README-NEW-AUTOBUILDER
index 1e46f5b..acb5387 100644
--- a/README-NEW-AUTOBUILDER
+++ b/README-NEW-AUTOBUILDER
@@ -23,6 +23,17 @@ TODO
 - deploy stuff
 - killing triggers. this has been a long standing issue. look into
 
+What is it
+
+Yocto Autobuilder is essentially some extension to the vanilla build bot.
+This extension mainly addresses configuration file handling and Yocto specific
+build steps.
+For better maintainability, the Autobuilder (see Autobuilder.py located at
+lib/python2.7/site-packages/autobuilder/), handles configuration from multiple
+files.
+Additional build steps such as CheckOutLayers.py or CreateBBLayersConf are
+Yocto specific and simplify the bulders configuration.
+
 Setup
 
 Nothing here has changed much. 
-- 
1.9.0

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

[yocto] [yocto-autobuilder][PATCH v1 3/4] master.py/botmaster.py: use builders list for builders order

2014-05-09 Thread stefan

From: Stefan Agner ste...@agner.ch

This patch uses the order of the list builderNames when requesting
builder names. This order is relevant for the Waterfall order.

However, the order of builderNames is not meaningful by default,
hence the change in botmaster.py makes sure the builderNames is
taken form the configuration files list of builder.

Hence we can get rid of the environment work around (which also
did not honor non Autobuilder builders).

Signed-off-by: Stefan Agner ste...@agner.ch
---
 lib/python2.7/site-packages/autobuilder/Autobuilder.py  | 17 +
 .../buildbot/process/botmaster.py   |  3 ++-
 .../buildbot-0.8.8-py2.7.egg/buildbot/status/master.py  | 12 ++--
 3 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/lib/python2.7/site-packages/autobuilder/Autobuilder.py 
b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
index 4c33489..cf8672f 100644
--- a/lib/python2.7/site-packages/autobuilder/Autobuilder.py
+++ b/lib/python2.7/site-packages/autobuilder/Autobuilder.py
@@ -38,20 +38,21 @@ class Autobuilder:
 self.cfile = ./buildset-config/yoctoAB.conf
 
 def createBuildsets(self):
-beenHere=[]
+buildersSorted=[]
 sort = True
 if self.config.has_option('BuildSets', 'order'):
 sort = False
 for set in ast.literal_eval(self.config.get('BuildSets', 'order')):
-beenHere.append(set)
+buildersSorted.append(set)
+
 for key in self.configdict:
-if key not in beenHere and key != BuildSets:
-beenHere.append(key)
+if key not in buildersSorted and key != BuildSets:
+buildersSorted.append(key)
+
 if sort:
-beenHere.sort()
-# REALLY crappy way to do this, but better than setting globals.
-os.environ[YOCTO_SORTED_BUILDERS]= str(beenHere)
-for buildset in beenHere:
+util.naturalSort(buildersSorted)
+
+for buildset in buildersSorted:
 self.schedprops = []
 self.checkoutprops={}
 self.set_props = {}
diff --git 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/process/botmaster.py
 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/process/botmaster.py
index d5597f7..f2c3b9f 100644
--- 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/process/botmaster.py
+++ 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/process/botmaster.py
@@ -262,7 +262,8 @@ class BotMaster(config.ReconfigurableServiceMixin, 
service.MultiService):
 builder.master = self.master
 builder.setServiceParent(self)
 
-self.builderNames = self.builders.keys()
+# Use order according to configuration files builders list
+self.builderNames = list([ (bc.name) for bc in new_config.builders ])
 
 metrics.MetricCountEvent.log(num_builders,
 len(self.builders), absolute=True)
diff --git 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/master.py
 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/master.py
index b5fe741..df122b4 100644
--- 
a/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/master.py
+++ 
b/lib/python2.7/site-packages/buildbot-0.8.8-py2.7.egg/buildbot/status/master.py
@@ -221,16 +221,8 @@ class Status(config.ReconfigurableServiceMixin, 
service.MultiService):
 
 def getBuilderNames(self, categories=None):
 if categories == None:
-#YOCTO PROJECT ADDITION
-import os
-import ast
-sortbuilders=
-
sortbuilders=ast.literal_eval(os.environ.get('YOCTO_SORTED_BUILDERS'))
-#I hate the way this is sorted. This is the laziest way to get this
-#in the format I want.
-return sortbuilders
-#YOCTO PROJECT ADDITION
-#return util.naturalSort(self.botmaster.builderNames) # don't let 
them break it
+# assume this is already sorted...
+return self.botmaster.builderNames
 
 l = []
 # respect addition order
-- 
1.9.0

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

[yocto] [yocto-autobuilder][PATCH v1 4/4] GetDeployDir.py/PublishArtifacts.py: get deploy dir from bitbake

2014-05-09 Thread stefan

From: Stefan Agner ste...@agner.ch

Since the deploy dir is configureable (also through TMPDIR), we
need to have a more generic variant to get that path. Also the
Ångstrom distribution adds -eglibc to the TMPDIR. Hence, the
safest way to get the deployment dir is to parse buildbots
environment.

Signed-off-by: Stefan Agner ste...@agner.ch
---
 .../autobuilder/buildsteps/GetDeployDir.py | 47 +
 .../autobuilder/buildsteps/PublishArtifacts.py | 48 --
 2 files changed, 73 insertions(+), 22 deletions(-)
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/GetDeployDir.py

diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/GetDeployDir.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/GetDeployDir.py
new file mode 100644
index 000..944fcf0
--- /dev/null
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/GetDeployDir.py
@@ -0,0 +1,47 @@
+'''
+Created on Mai 8, 2014
+
+__author__ = Stefan Agner
+__copyright__ = Copyright 2014, Toradex AG
+__credits__ = [Stefan Agner]
+__license__ = GPL
+__version__ = 2.0
+__maintainer__ = Stefan Agner
+__email__ = ste...@agner.ch
+'''
+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 GetDeployDir(ShellCommand):
+haltOnFailure = False
+flunkOnFailure = True
+name = GetDeployDir
+def __init__(self, factory, argdict=None, **kwargs):
+for k, v in argdict.iteritems():
+setattr(self, k, v)
+self.description = Get Deploy Directory
+self.deploydir = None
+ShellCommand.__init__(self, **kwargs)
+
+def start(self):
+cmd = '. ./oe-init-build-env; bitbake -e | grep ^DEPLOY_DIR='
+self.command = cmd
+ShellCommand.start(self)
+
+def commandComplete(self, cmd):
+if cmd.didFail():
+return
+result = cmd.logs['stdio'].getText()
+if = not in result:
+self.finished(FAILURE)
+param, value = result.split(=)
+deploydir = value.replace('', '').strip()
+self.setProperty('deploydir', deploydir, Setting Deploy Directory)
+self.finished(SUCCESS)
+
+def getText(self, cmd, results):
+return ShellCommand.getText(self, cmd, results)
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
index ebc761f..303df36 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishArtifacts.py
@@ -19,10 +19,10 @@ class PublishArtifacts(ShellCommand):
 
 haltOnFailure = False
 flunkOnFailure = True
-name = Publishing Artifacts
+name = PublishArtifacts
+description = Publishing Artifacts
 def __init__(self, factory, argdict=None, **kwargs):
 self.factory = factory
-self.description = Publishing Artifacts
 self.slavedir=os.path.join(os.path.join(YOCTO_ABBASE, yocto-slave))
 for k, v in argdict.iteritems():
 if type(v) is bool:
@@ -42,10 +42,14 @@ class PublishArtifacts(ShellCommand):
 self.layerversion_yoctobsp = self.getProperty(layerversion_yoctobsp)
 self.layerversion_yocto = self.getProperty(layerversion_yocto)
 self.layerversion_core = self.getProperty(layerversion_core)
+self.deploydir = self.getProperty(deploydir)
 log.msg(layerversion_yoctobsp)
-self.basedir=os.path.join(os.path.join(
-self.slavedir, buildername),
-build/build/)
+self.basedir = os.path.join(self.slavedir, buildername, build/build/)
+
+# Deploydir might not be set in case the step did not run, fallback to 
default
+if self.deploydir is None:
+self.deploydir = os.path.join(self.basedir, tmp/deploy/)
+
 command=
 DATESTAMP=datetime.datetime.now().strftime(%Y%m%d)
 if str(os.environ.get('PUBLISH_BUILDS')) == True:
@@ -70,17 +74,17 @@ class PublishArtifacts(ShellCommand):
 if artifact == adt-installer:
 command=command+mkdir -p  + os.path.join(DEST, 
ADT_INST_PUBLISH_DIR) + ;
 command=command+cp -R --no-dereference --preserve=links  
+ \
-os.path.join(self.basedir, 
tmp/deploy/sdk/) + \
+os.path.join(self.deploydir, sdk/) + \
 *adt*  + os.path.join(DEST, 
ADT_INST_PUBLISH_DIR) + ;
 elif artifact == adt-installer-QA:
 command=command+mkdir -p  + os.path.join(DEST, 
ADTQA_INST_PUBLISH_DIR) + ;
 command

Re: [yocto] Missing kernel, modules and dtb for beaglebone on core-image-minimal

2014-04-29 Thread Stefan Stanacar

That's not a bug :), it's intended. The README.hardware clearly states that
for deploying a core-image-minimal you need to unpack the modules and copy
the dtbs over.

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/README.hardware#n244

There is a reason for that, mainly beacause the way core-image-minimal
recipe works.
 A BSP usually adds kernel-modules and other stuff to
MACHINE_EXTRA_RDEPENDS but not all images respect that (they need to
inherit core-image.bbclass and not overwrite IMAGE_INSTALL).

HTH,
Stefan


On Tue, Apr 29, 2014 at 5:17 PM, Diego Sueiro diego.sue...@gmail.comwrote:

 Folks,

 I'm using daisy branch of yocto and I realized that kernel and dtb files
 were not present on /boot and there were no modules installed on
 /lib/modules/3.14.0-yocto-standard.



 Regards,

 --
 *dS
 Diego Sueiro

 Administrador do Embarcados
 www.embarcados.com.brhttp://www.embarcados.com.br/?utm_source=assinatura_diegoutm_medium=e-mailutm_campaign=Assinatura%20Email%20Diego

 /*long live rock 'n roll*/

 --
 ___
 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] Missing kernel, modules and dtb for beaglebone on core-image-minimal

2014-04-29 Thread Stefan Stanacar

On Tue, Apr 29, 2014 at 5:35 PM, Diego Sueiro diego.sue...@gmail.com wrote:

 Stefan,

 On Tue, Apr 29, 2014 at 11:32 AM, Stefan Stanacar sst...@gmail.com wrote:

 That's not a bug :), it's intended. The README.hardware clearly states that 
 for deploying a core-image-minimal you need to unpack the modules and copy 
 the dtbs over.

 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/README.hardware#n244

 There is a reason for that, mainly beacause the way core-image-minimal 
 recipe works.
  A BSP usually adds kernel-modules and other stuff to MACHINE_EXTRA_RDEPENDS 
 but not all images respect that (they need to inherit core-image.bbclass and 
 not overwrite IMAGE_INSTALL).


 Thanks. Got it.
 Why I never RTFM or at least the README file?



No problem, you're welcome.

FWIW the beaglebone machine defintion does:

MACHINE_EXTRA_RRECOMMENDS =  kernel-modules kernel-devicetree

which ultimately get pulled in packagegroup-base.

Cheers,
Stefan



 Regards,

 --
 *dS
 Diego Sueiro

 Administrador do Embarcados
 www.embarcados.com.br

 /*long live rock 'n roll*/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

2014-04-16 Thread Stefan Stanacar

https://bugzilla.yoctoproject.org/show_bug.cgi?id=6165

Link to the two kernels at the end of the first comment.
On Apr 16, 2014 6:57 PM, William Mills wmi...@ti.com wrote:


 On 04/15/2014 11:31 PM, Khem Raj wrote:

 On Tue, Apr 15, 2014 at 6:20 PM, Denys Dmytriyenko de...@denix.org
 wrote:

 On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:

 On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:

 On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:

 I don't yet know what is going on, but building in the same directory
 with
 sources (B = S) makes it work regarless of the path length:

 /OE/RAM/poky-11
 
 111/22
 22/33
 33/tmp/work/beaglebone-poky-linux-
 gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

 So, I just commented out setting kernel-specific B in linux-yocto.inc
 and any
 kernel now boots with long path:

 #B = ${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build

 I'm copying Richard and Bruce directly to see if they may have a
 quick insight
 and/or accept it as a workaround for the release. I'll keep digging
 further,
 but if anyone cares to verify the above workaround works for them, I
 would
 appreciate. Thanks!


 I'm travelling and don't have hardware so I'm limited in what I can
 look
 at right now. I suspect this workaround works because it makes the
 beaglebone-standard-build extra characters on the path. I have a
 feeling your -111 test above may have reused sstate or something
 like that and given misleading results. I'd be interested in the
 vmlinux
 file from the build above to see if the poky-11 pathnames are in
 there (they get stripped out when you create the zImage).


 Nope, I was fooled by sstate once, so this time I tested with
 cleansstate and
 compared timestamps of the kernel when it boots - it is definitely the
 new
 one. And to make sure 'beaglebone-standard-build' extra suffix doesn't
 affect
 it, I increased the path length even further - that extra level with
 333 is
 there to over-compensate, as it was failing before even with just 111
 and 222
 levels only... Looks like Gary was also able to verify it.

 But, you are right about vmlinux - it doesn't have those paths in there
 any
 more! I've seen them there when building with B != S, but they are gone
 when
 building with B = S. Wondering why. You can check it for yourself:

 http://arago-project.org/files/short-term/misc/vmlinux-
 3.14.0-yocto-standard


 And, as a follow up, all those long paths in vmlinux when built with B
 != S
 point to sources. Here are few examples:

 B != S strings:

 /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/
 linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
 earlycon
 4Malformed early option '%s'
 3Starting init: %s exists but couldn't execute it (error %d)
 ...
 6Trying to unpack rootfs image as initramfs...
 /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/
 linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/
 linux/init/initramfs.c
 6rootfs image is not initramfs (%s); looks like an initrd
 TRAILER!!!
 ...
 %lu.%02lu BogoMIPS (lpj=%lu)
 /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/
 linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/
 linux/arch/arm/vfp/vfpmodule.c
 6VFP support v0.3:


 B = S same strings:

 init/main.c
 earlycon
 4Malformed early option '%s'
 3Starting init: %s exists but couldn't execute it (error %d)
 ...
 6Trying to unpack rootfs image as initramfs...
 init/initramfs.c
 6rootfs image is not initramfs (%s); looks like an initrd
 TRAILER!!!
 ...
 %lu.%02lu BogoMIPS (lpj=%lu)
 arch/arm/vfp/vfpmodule.c
 6VFP support v0.3:


 So, that explains why B = S works regardless of the location, as it
 doesn't
 embed full path to source files...


 seemingly there could be rodata segment overflow issue. Can you do the
 kernel build with say linker from dora build
 and see if it still fails.


 It would be interesting to see if the rodata segment (or segment it
 contributes to) between working and non-working versions were crossing
 some magic power of 2 value.

 Are there two images published from the same build machines with just
 the path difference?  I would like to see one that was just under the
 wire and one just a bit too long.  Denys, you have that?
 --
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto

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

[yocto] [yocto-autobuilder][PATCH] nightly-multilib: don't build lsb image

2014-04-01 Thread Stefan Stanacar

We shouldn't build an lsb image here as this isn't a
poky-lsb build.
There is a pending patch on oe-core that will break this
build if we don't remove it and it doesn't buys us too much test
coverage anyway.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config.master/nightly-multilib.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/buildset-config.master/nightly-multilib.conf 
b/buildset-config.master/nightly-multilib.conf
index b5dfec3..49e6ea7 100644
--- a/buildset-config.master/nightly-multilib.conf
+++ b/buildset-config.master/nightly-multilib.conf
@@ -25,4 +25,4 @@ steps: [{'SetDest':{}},
 {'BuildImages': {'images': 'core-image-sato'}},
 {'RunSanityTests': {'images': 'core-image-sato', 'suites' : 'ping ssh 
connman xorg multilib dmesg auto'}},
 {'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686', 
'multilib': 'lib64', 'distro': 'poky'}},
-{'BuildImages': {'images': 'lib64-core-image-sato 
lib64-core-image-sato-sdk lib64-core-image-lsb-sdk'}}]
+{'BuildImages': {'images': 'lib64-core-image-sato 
lib64-core-image-sato-sdk'}}]
-- 
1.9.0

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

[yocto] [yocto-autobuilder][PATCH] CreateAutoConf: strict checking for multilib

2014-04-01 Thread Stefan Stanacar

So we don't create multilib configs unless True or lib32 or lib64,
and doesn't add the inherit multilib.conf for False.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
index ec69355..59a88c4 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
@@ -95,12 +95,13 @@ class CreateAutoConf(ShellCommand):
 if self.pvr == True:
 fout = fout + 'LICENSE_FLAGS_WHITELIST += 
license_cdv-pvr-driver \n'
 fout = fout + 'PVR_LICENSE = yes \n'
-if self.multilib:
-fout = fout + 'require conf/multilib.conf \n'
+if self.multilib and self.multilib != False:
 if self.multilib == True or self.multilib == lib32:
+fout = fout + 'require conf/multilib.conf \n'
 fout = fout + 'MULTILIBS = multilib:lib32 \n'
 fout = fout + 'DEFAULTTUNE_virtclass-multilib-lib32 = 
x86 \n'
 elif self.multilib == lib64:
+fout = fout + 'require conf/multilib.conf \n'
 fout = fout + 'MULTILIBS = multilib:lib64 \n'
 fout = fout + 'DEFAULTTUNE_virtclass-multilib-lib64 = 
x86-64 \n'
 if not self.nosstate:
-- 
1.9.0

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

[yocto] [yocto-autobuilder][PATCH] nightly-ipk/deb: drop some test suites for sato-sdk

2014-04-01 Thread Stefan Stanacar

We don't have these on dora and I'd prefer not to check
for each valid test in RunSanity.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config.master/nightly-deb.conf | 2 +-
 buildset-config.master/nightly-ipk.conf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/buildset-config.master/nightly-deb.conf 
b/buildset-config.master/nightly-deb.conf
index d58772d..c4cc872 100644
--- a/buildset-config.master/nightly-deb.conf
+++ b/buildset-config.master/nightly-deb.conf
@@ -16,4 +16,4 @@ steps: [{'SetDest':{}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
 {'RunSanityTests': {'images': 'core-image-minimal'}},
 {'RunSanityTests': {'images' : 'core-image-sato', 'suites' : 'ping ssh 
auto'}},
-{'RunSanityTests': {'images' : 'core-image-sato-sdk', 'suites' : 'ping 
ssh df connman syslog xorg scp vnc date perl ldd gcc kernelmodule dmesg 
python'}}]
+{'RunSanityTests': {'images' : 'core-image-sato-sdk', 'suites' : 'ping 
ssh df connman syslog xorg scp vnc date perl ldd gcc dmesg'}}]
diff --git a/buildset-config.master/nightly-ipk.conf 
b/buildset-config.master/nightly-ipk.conf
index 974596f..c6455bc 100644
--- a/buildset-config.master/nightly-ipk.conf
+++ b/buildset-config.master/nightly-ipk.conf
@@ -16,4 +16,4 @@ steps: [{'SetDest':{}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
 {'RunSanityTests': {'images' : 'core-image-minimal'}},
 {'RunSanityTests': {'images' : 'core-image-sato', 'suites' : 'ping ssh 
auto'}},
-{'RunSanityTests': {'images' : 'core-image-sato-sdk', 'suites' : 'ping 
ssh df connman syslog xorg scp vnc date perl ldd gcc kernelmodule dmesg 
python'}}]
+{'RunSanityTests': {'images' : 'core-image-sato-sdk', 'suites' : 'ping 
ssh df connman syslog xorg scp vnc date perl ldd gcc dmesg'}}]
-- 
1.9.0

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

[yocto] [yocto-autobuilder][PATCH] nightly-deb/ipk: don't use the default tests

2014-03-27 Thread Stefan Stanacar

We can't use RunSanityTests as it is because the default
test suites (which are defined in testimage.bbclass) include rpm and smart.
Anything included in TEST_SUITES is a mandatory test and will be a fail in this
buildset as obviously this images don't have rpm/smart.
Also we can't use 'ping auto' either (which will run all the tests suitable for 
the image),
because for core-image-sato-sdk that will run cvs/iptables/sudoku build tests 
which
take a long time (and we have another buildset nightly-qa-targetbuild for that) 
so we need
to hardcode the list of tests - the same as the defaults for a rpm 
core-image-sato-sdk,
minus rpm and smart (and without smart this RunSanity will take half of the 
time)

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config.master/nightly-deb.conf | 6 +-
 buildset-config.master/nightly-ipk.conf | 6 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/buildset-config.master/nightly-deb.conf 
b/buildset-config.master/nightly-deb.conf
index 648401b..7ed5eed 100644
--- a/buildset-config.master/nightly-deb.conf
+++ b/buildset-config.master/nightly-deb.conf
@@ -15,5 +15,9 @@ steps: [{'SetDest':{}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'SyncPersistDB' : {'distro' : 'poky'}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
-{'RunSanityTests': {'images': 'core-image-minimal core-image-sato 
core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-minimal'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'buildhistory' : True, 'packages': 'ipk'}},
+{'RunSanityTests': {'images' 'core-image-sato', 'suites' : 'ping ssh 
auto'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'buildhistory' : True, 'packages': 'ipk'}},
+{'RunSanityTests': {'images' : 'core-image-sato-sdk', 'suites' : 'ping 
ssh df connman syslog xorg scp vnc date perl ldd gcc kernelmodule dmesg 
python'}},
 {'SyncPersistDB' : {'commit' : True, 'distro':'poky'}}]
diff --git a/buildset-config.master/nightly-ipk.conf 
b/buildset-config.master/nightly-ipk.conf
index bf7c613..c96d098 100644
--- a/buildset-config.master/nightly-ipk.conf
+++ b/buildset-config.master/nightly-ipk.conf
@@ -15,5 +15,9 @@ steps: [{'SetDest':{}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'SyncPersistDB' : {'distro' : 'poky'}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
-{'RunSanityTests': {'images': 'core-image-minimal core-image-sato 
core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-minimal'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'buildhistory' : True, 'packages': 'ipk'}},
+{'RunSanityTests': {'images' 'core-image-sato', 'suites' : 'ping ssh 
auto'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'buildhistory' : True, 'packages': 'ipk'}},
+{'RunSanityTests': {'images' : 'core-image-sato-sdk', 'suites' : 'ping 
ssh df connman syslog xorg scp vnc date perl ldd gcc kernelmodule dmesg 
python'}},
 {'SyncPersistDB' : {'commit' : True, 'distro':'poky'}}]
-- 
1.8.5.3

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

[yocto] [yocto-autobuilder][PATCH] buildsets: nightly-qa-targetbuilds: remove the mips build

2014-03-27 Thread Stefan Stanacar

The build tests for iptables/cvs/sudoku take too much time on qemumips
and usually buildbot ends up killing the step as it hits the timeout,
so we should drop them.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config.master/nightly-qa-targetbuilds.conf | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/buildset-config.master/nightly-qa-targetbuilds.conf 
b/buildset-config.master/nightly-qa-targetbuilds.conf
index a95db78..96ec7f8 100644
--- a/buildset-config.master/nightly-qa-targetbuilds.conf
+++ b/buildset-config.master/nightly-qa-targetbuilds.conf
@@ -20,7 +20,4 @@ steps: [{'SetDest':{}},
 {'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}},
 {'CreateAutoConf': {'machine': 'qemuppc', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
 {'BuildImages': {'images': 'core-image-sato-sdk'}},
-{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}},
-{'CreateAutoConf': {'machine': 'qemumips', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
-{'BuildImages': {'images': 'core-image-sato-sdk'}},
 {'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}}]
-- 
1.8.5.3

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

[linux-yocto] [PATCH 3/3] meta: move the newly added CONFIG_EFIVAR_FS to the default efi config fragment

2014-03-12 Thread Stefan Stanacar

I see CONFIG_EFIVAR_FS as very useful thing and I'd like to have it
enabled by default.
For example for gummiboot you can use the LoaderEntryOneShot to tell
it the entry identifier to select at the next and only the next bootup,
and I plan to use that in automated testing.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 meta/cfg/kernel-cache/cfg/efi-ext.cfg | 1 -
 meta/cfg/kernel-cache/cfg/efi.cfg | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/cfg/kernel-cache/cfg/efi-ext.cfg 
b/meta/cfg/kernel-cache/cfg/efi-ext.cfg
index edceb75..ec2b0d5 100644
--- a/meta/cfg/kernel-cache/cfg/efi-ext.cfg
+++ b/meta/cfg/kernel-cache/cfg/efi-ext.cfg
@@ -10,5 +10,4 @@ CONFIG_PARTITION_ADVANCED=y
 # Add support for optional EFI features
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FB_EFI=y
-CONFIG_EFIVAR_FS=y
 CONFIG_EFI_PARTITION=y
diff --git a/meta/cfg/kernel-cache/cfg/efi.cfg 
b/meta/cfg/kernel-cache/cfg/efi.cfg
index e2ecc18..ff5d680 100644
--- a/meta/cfg/kernel-cache/cfg/efi.cfg
+++ b/meta/cfg/kernel-cache/cfg/efi.cfg
@@ -7,3 +7,4 @@ CONFIG_ACPI=y
 # Enable basic EFI support
 CONFIG_EFI=y
 CONFIG_EFI_STUB=y
+CONFIG_EFIVAR_FS=y
-- 
1.8.5.3

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

[linux-yocto] [PATCH 2/3] meta: efi-ext.cfg: replace EFI_VARS with EFIVAR_FS

2014-03-12 Thread Stefan Stanacar

Linux kernel exposes EFI variables data to userspace via 2 interfaces:
- old sysfs-efivars interface (CONFIG_EFI_VARS), populated at 
/sys/firmware/efi/vars,
1024 byte maximum per-variable data size limitation, no UEFI Secure Boot 
variables support
and not recommended anymore.
- new efivarfs interface (CONFIG_EFIVAR_FS), typically mounted like this:
mount -t efivarfs efivarfs /sys/firmware/efi/efivar
It was added in 3.8 intended as a replacement for the sysfs-efivars interface,
has no maximum per-variable size limitation and supports UEFI Secure Boot 
variables.
It also allows creating new vars easily, a very useful trick:
printf \x07\x00\x00\x00\x00  
/sys/firmware/efi/efivar/myvar-12345678-1234-1234-1234-123456789abc

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 meta/cfg/kernel-cache/cfg/efi-ext.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/cfg/kernel-cache/cfg/efi-ext.cfg 
b/meta/cfg/kernel-cache/cfg/efi-ext.cfg
index 6371da2..edceb75 100644
--- a/meta/cfg/kernel-cache/cfg/efi-ext.cfg
+++ b/meta/cfg/kernel-cache/cfg/efi-ext.cfg
@@ -10,5 +10,5 @@ CONFIG_PARTITION_ADVANCED=y
 # Add support for optional EFI features
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FB_EFI=y
-CONFIG_EFI_VARS=y
+CONFIG_EFIVAR_FS=y
 CONFIG_EFI_PARTITION=y
-- 
1.8.5.3

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

[yocto] [yocto-autobuilder][PATCH] buildsets: add a new buildset to run builds on target

2014-02-20 Thread Stefan Stanacar

Builds core-image-sato-sdk for each qemu arch and
runs tests building sudoku/cvs/iptables.
These do take a while, so they shouldn't be added to nightly!

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 .../nightly-qa-targetbuilds.conf   | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 buildset-config.master/nightly-qa-targetbuilds.conf

diff --git a/buildset-config.master/nightly-qa-targetbuilds.conf 
b/buildset-config.master/nightly-qa-targetbuilds.conf
new file mode 100644
index 000..a95db78
--- /dev/null
+++ b/buildset-config.master/nightly-qa-targetbuilds.conf
@@ -0,0 +1,26 @@
+[nightly-qa-targetbuilds]
+builders: 'builder1'
+repos: [{'poky':
+{'repourl':'git://git.yoctoproject.org/poky',
+ 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp'},
+ 'branch':'master'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'BuildImages': {'images': 'core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'BuildImages': {'images': 'core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}},
+{'CreateAutoConf': {'machine': 'qemuarm', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'BuildImages': {'images': 'core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}},
+{'CreateAutoConf': {'machine': 'qemuppc', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'BuildImages': {'images': 'core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}},
+{'CreateAutoConf': {'machine': 'qemumips', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'BuildImages': {'images': 'core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}}]
-- 
1.8.5.3

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

[yocto] [yocto-autobuilder][PATCH] Add buildstep and buildset for oe-selftest script

2014-02-20 Thread Stefan Stanacar

This will run the oe-selftest script which has been
available in master for a while. The scripts run a series
of bitbake tests and takes care of it's own config.
Because some of the tests mess up with sstate we
want to use the default sstate dir, so a nosstate option
was added to CreateAutoConf.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config.master/nightly-oe-selftest.conf| 15 +
 .../autobuilder/buildsteps/CreateAutoConf.py   |  7 --
 .../autobuilder/buildsteps/RunOeSelftest.py| 26 ++
 3 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 buildset-config.master/nightly-oe-selftest.conf
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py

diff --git a/buildset-config.master/nightly-oe-selftest.conf 
b/buildset-config.master/nightly-oe-selftest.conf
new file mode 100644
index 000..42bccde
--- /dev/null
+++ b/buildset-config.master/nightly-oe-selftest.conf
@@ -0,0 +1,15 @@
+[nightly-oe-selftest]
+builders: 'builder1'
+repos: [{'poky':
+{'repourl':'git://git.yoctoproject.org/poky',
+ 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp'},
+ 'branch':'master'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky', 'nosstate': True, 'packages': 'rpm'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'BuildImages': {'images': 'core-image-minimal'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto', 'layerdirs': 
['meta-selftest']}},
+{'RunOeSelftest': {}}]
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
index 116ee14..bec221a 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
@@ -38,6 +38,7 @@ class CreateAutoConf(ShellCommand):
 self.factory = factory
 self.buildappsrcrev = ${AUTOREV}
 self.initmgr=None
+self.nosstate=False
 self.kwargs = kwargs
 for k, v in argdict.iteritems():
 if type(v) is bool:
@@ -100,9 +101,11 @@ class CreateAutoConf(ShellCommand):
 elif self.multilib == lib64:
 fout = fout + 'MULTILIBS = multilib:lib64 \n'
 fout = fout + 'DEFAULTTUNE_virtclass-multilib-lib64 = 
x86-64 \n'
-fout = fout + 'SSTATE_DIR ?= ' + os.environ.get(SSTATE_DIR) 
+ '/multilib \n'
+if not self.nosstate:
+fout = fout + 'SSTATE_DIR ?= ' + 
os.environ.get(SSTATE_DIR) + '/multilib \n'
 else:
-fout = fout + 'SSTATE_DIR ?= ' + os.environ.get(SSTATE_DIR) 
+ '/ \n'
+if not self.nosstate:
+fout = fout + 'SSTATE_DIR ?= ' + 
os.environ.get(SSTATE_DIR) + '/ \n'
 if self.gplv3 == False:
 fout = fout + 'INCOMPATIBLE_LICENSE = GPLv3 \n'
 if self.x32 == True:
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py
new file mode 100644
index 000..0efddd7
--- /dev/null
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py
@@ -0,0 +1,26 @@
+'''
+__author__ = Stefan Stanacar
+__copyright__ = Copyright 2014 Intel Corporation
+__credits__ = [Stefan Stanacar]
+__license__ = GPL
+__version__ = 2.0
+__maintainer__ = Stefan Stanacar
+__email__ = stefanx.stana...@intel.com
+'''
+
+
+from buildbot.steps.shell import ShellCommand
+
+class RunOeSelftest(ShellCommand):
+haltOnFailure = False
+flunkOnFailure = True
+name = Running oe-selftest
+def __init__(self, factory, argdict=None, **kwargs):
+self.factory = factory
+for k, v in argdict.iteritems():
+setattr(self, k, v)
+self.description = Running oe-selftest
+self.timeout = 10
+kwargs['timeout']=self.timeout
+self.command = if [ -d meta-selftest ]; then . ./oe-init-build-env; 
oe-selftest; else echo 'Skipping step - no meta-selftest layer here'; fi
+ShellCommand.__init__(self, **kwargs)
-- 
1.8.5.3

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

[yocto] [yocto-autobuilder][PATCH] Add buildstep and buildset for oe-selftest script

2014-02-07 Thread Stefan Stanacar

This will run the oe-selftest script which has been
available in master for a while. The scripts run a series
of bitbake tests and takes care of it's own config.
Because some of the tests mess up with sstate we
want to use the default sstate dir, so a nosstate option
was added to CreateAutoConf.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config.master/nightly-oe-selftest.conf| 15 +
 .../autobuilder/buildsteps/CreateAutoConf.py   |  7 --
 .../autobuilder/buildsteps/RunOeSelftest.py| 26 ++
 3 files changed, 46 insertions(+), 2 deletions(-)
 create mode 100644 buildset-config.master/nightly-oe-selftest.conf
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py

diff --git a/buildset-config.master/nightly-oe-selftest.conf 
b/buildset-config.master/nightly-oe-selftest.conf
new file mode 100644
index 000..42bccde
--- /dev/null
+++ b/buildset-config.master/nightly-oe-selftest.conf
@@ -0,0 +1,15 @@
+[nightly-oe-selftest]
+builders: 'builder1'
+repos: [{'poky':
+{'repourl':'git://git.yoctoproject.org/poky',
+ 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp'},
+ 'branch':'master'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky', 'nosstate': True, 'packages': 'rpm'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'BuildImages': {'images': 'core-image-minimal'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto', 'layerdirs': 
['meta-selftest']}},
+{'RunOeSelftest': {}}]
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
index 116ee14..bec221a 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
@@ -38,6 +38,7 @@ class CreateAutoConf(ShellCommand):
 self.factory = factory
 self.buildappsrcrev = ${AUTOREV}
 self.initmgr=None
+self.nosstate=False
 self.kwargs = kwargs
 for k, v in argdict.iteritems():
 if type(v) is bool:
@@ -100,9 +101,11 @@ class CreateAutoConf(ShellCommand):
 elif self.multilib == lib64:
 fout = fout + 'MULTILIBS = multilib:lib64 \n'
 fout = fout + 'DEFAULTTUNE_virtclass-multilib-lib64 = 
x86-64 \n'
-fout = fout + 'SSTATE_DIR ?= ' + os.environ.get(SSTATE_DIR) 
+ '/multilib \n'
+if not self.nosstate:
+fout = fout + 'SSTATE_DIR ?= ' + 
os.environ.get(SSTATE_DIR) + '/multilib \n'
 else:
-fout = fout + 'SSTATE_DIR ?= ' + os.environ.get(SSTATE_DIR) 
+ '/ \n'
+if not self.nosstate:
+fout = fout + 'SSTATE_DIR ?= ' + 
os.environ.get(SSTATE_DIR) + '/ \n'
 if self.gplv3 == False:
 fout = fout + 'INCOMPATIBLE_LICENSE = GPLv3 \n'
 if self.x32 == True:
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py
new file mode 100644
index 000..0efddd7
--- /dev/null
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py
@@ -0,0 +1,26 @@
+'''
+__author__ = Stefan Stanacar
+__copyright__ = Copyright 2014 Intel Corporation
+__credits__ = [Stefan Stanacar]
+__license__ = GPL
+__version__ = 2.0
+__maintainer__ = Stefan Stanacar
+__email__ = stefanx.stana...@intel.com
+'''
+
+
+from buildbot.steps.shell import ShellCommand
+
+class RunOeSelftest(ShellCommand):
+haltOnFailure = False
+flunkOnFailure = True
+name = Running oe-selftest
+def __init__(self, factory, argdict=None, **kwargs):
+self.factory = factory
+for k, v in argdict.iteritems():
+setattr(self, k, v)
+self.description = Running oe-selftest
+self.timeout = 10
+kwargs['timeout']=self.timeout
+self.command = if [ -d meta-selftest ]; then . ./oe-init-build-env; 
oe-selftest; else echo 'Skipping step - no meta-selftest layer here'; fi
+ShellCommand.__init__(self, **kwargs)
-- 
1.8.5.3

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

[yocto] [yocto-autobuilder][PATCH] buildsets: add a new buildset to run builds on target

2014-02-07 Thread Stefan Stanacar

Builds core-image-sato-sdk for each qemu arch and
runs tests building sudoku/cvs/iptables.
These do take a while, so they shouldn't be added to nightly!

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 .../nightly-qa-targetbuilds.conf   | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 buildset-config.master/nightly-qa-targetbuilds.conf

diff --git a/buildset-config.master/nightly-qa-targetbuilds.conf 
b/buildset-config.master/nightly-qa-targetbuilds.conf
new file mode 100644
index 000..a95db78
--- /dev/null
+++ b/buildset-config.master/nightly-qa-targetbuilds.conf
@@ -0,0 +1,26 @@
+[nightly-qa-targetbuilds]
+builders: 'builder1'
+repos: [{'poky':
+{'repourl':'git://git.yoctoproject.org/poky',
+ 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp'},
+ 'branch':'master'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'BuildImages': {'images': 'core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'BuildImages': {'images': 'core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}},
+{'CreateAutoConf': {'machine': 'qemuarm', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'BuildImages': {'images': 'core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}},
+{'CreateAutoConf': {'machine': 'qemuppc', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'BuildImages': {'images': 'core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}},
+{'CreateAutoConf': {'machine': 'qemumips', 'SDKMACHINE' : 'x86_64', 
'distro': 'poky'}},
+{'BuildImages': {'images': 'core-image-sato-sdk'}},
+{'RunSanityTests': {'images': 'core-image-sato-sdk', 'suites' : 'ping 
ssh buildsudoku buildcvs buildiptables'}}]
-- 
1.8.5.3

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

Re: [yocto] u-boot 2013.10 LIC_FILES_CHKSUM points to an invalid file

2013-12-24 Thread Stefan Herbrechtsmeier


Am 23.12.2013 21:56, schrieb Paul Eggleton:

Hi Robert,

On Monday 23 December 2013 22:47:00 Robert Berger wrote:

I try to build instead of u-boot v2013.07 [1] the latest and greatest
released version i.e. v2013.10[2].

... which does not build because LIC_FILES_CHKSUM points to an invalid
file ...

... and yes it does, since the COPYING file is gone ...

The licencense info is contained in the source code itself as
SPDX-License-Identifiers.

Hmm, I'm not sure upstream should really have removed it, but I guess it's up
to them...
The project switch to the Software Package Data Exchange (SPDX) and move 
the license information in a Licenses directory.


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

[yocto] Board specific bbappend file

2013-12-05 Thread Stefan Roese

Dear List!

I'm trying to add a board specific *.bbappend file to a recipe. To add
board specific informations/settings to this recipe but without changing
the common (generic) recipe (*.bb) file. Something like this:

recipe:
linux-xyz_3.12.bb

board-specific append file:
linux-xyz-board-foo_3.12.bbappend

From the documentation I read:

Append files must have the same root names as their corresponding
recipes. For example, the append file someapp_1.5.1.bbappend must apply
to someapp_1.5.1.bb.


So it seems impossible to encrypt the board name into the bbappend
file name. Or am I missing something?

If not, is there another way to add such board-specific stuff to a
recipe without changing the generic recipe?

Thanks,
Stefan
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Board specific bbappend file

2013-12-05 Thread Stefan Roese

Hi Bruce,

On 05.12.2013 17:09, Bruce Ashfield wrote:
 I'm trying to add a board specific *.bbappend file to a recipe. To add
 board specific informations/settings to this recipe but without changing
 the common (generic) recipe (*.bb) file. Something like this:

 recipe:
 linux-xyz_3.12.bb

 board-specific append file:
 linux-xyz-board-foo_3.12.bbappend

  From the documentation I read:
 
 Append files must have the same root names as their corresponding
 recipes. For example, the append file someapp_1.5.1.bbappend must apply
 to someapp_1.5.1.bb.
 

 So it seems impossible to encrypt the board name into the bbappend
 file name. Or am I missing something?

 If not, is there another way to add such board-specific stuff to a
 recipe without changing the generic recipe?
 
 What exactly are you tried to change on a per-board basis ? Assuming
 it is variables, you can use the standard OVERRIDES mechanism to
 have a version specific bbappend, that changes variables on a per
 board basis.
 
 i.e.
 
   FOO_machine name = bar
   FOO_another machine name = bar2
 
 Assuming the generic recipe uses these variables appropriately, you'll
 be fine.

Specifically its the SRC_URI / SRC_URI_append variable (e.g. for a linux
kernel and u-boot etc). And since this one is used in many recipes, I
can't just put those settings in the machine conf file.

Do you have any recommendations how to change this variable (per recipe)
without touching the generic bb file?

Thanks,
Stefan

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

Re: [yocto] Board specific bbappend file

2013-12-05 Thread Stefan Roese

On 05.12.2013 17:33, Bruce Ashfield wrote:
 What exactly are you tried to change on a per-board basis ? Assuming
 it is variables, you can use the standard OVERRIDES mechanism to
 have a version specific bbappend, that changes variables on a per
 board basis.

 i.e.

FOO_machine name = bar
FOO_another machine name = bar2

 Assuming the generic recipe uses these variables appropriately, you'll
 be fine.

 Specifically its the SRC_URI / SRC_URI_append variable (e.g. for a linux
 kernel and u-boot etc). And since this one is used in many recipes, I
 can't just put those settings in the machine conf file.

 Do you have any recommendations how to change this variable (per recipe)
 without touching the generic bb file?
 
 You can absolutely change the SRC_URI on a per-board basis. Just use
 the technique that I showed above, and do it in a bbappend to your
 linux recipe.
 
 i.e. something like: SRC_URI_qemux86 += file://myfancypatch.patch

Yes, right. But this would mean doing it in a generic bbappend file? E.g.

recipe:
linux-xyz_3.12.bb

and its generic append file:
linux-xyz_3.12.bbappend

And thinking about for example 20 boards, this would mean to add 20
SRC_URI_fooabc defines to this bbappend file. Just shifting the
changes from the bb file to the common bbappend file.

What I was looking for is more a way to do this on a one-file-per-board
basis. Is this possible somehow?

Thanks,
Stefan

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

[yocto] Problem with RAM partitioning

2013-12-02 Thread Stefan Kostial

Hello everyone,

Im sorry if this is not the 100% right place for my problem, but all other ways havent lead to a solution.

Im working with an Altera Cyclone V FPGA which has a hardprocessor system with (poky-) linux running on it.
There is also a 1GB DDR3 RAM connected to the system.

My target is to devide the available 1GB into 3 partitions:
Partition 1: used only by Linux
Partition 2: used only by the FPGA
Partition 3: swap partition for exchanging data between the FPGA and Linux

For this purpose there is a controller on the FPGA called SDRAM controller subsystem in which registers
you can define up to 20 rules for memory access protection - I think this is exactly what I need... but I cant get it running.

My first problem is that I dont know __when__ to set this registers. Someone recommended setting this registers in linux,
but this doesnt work and has no effect (after setting the registers, linux everytime has full access to the whole RAM and after rebooting all registers are set back.)
I think that setting the registers must be done __before__ the linux boots, e.g. in the preloader or the bootloader (U-Boot)?!

Im searching for 2 weeks for a solution - no example projects are provided by Altera, and the documentation is very rare.

Please, does anyone has a hint for me?!
Slowly Im going nuts on this topic.

Many thanks in advance!!!

Cheers
Stefan Kostial

P.S.: If wished, I can provide more detailed info - at this moment Im just searching for someone who has some experience...

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

[yocto] [yocto-autobuilder][PATCH] buildsteps/CheckOutLayers: use a commit object for git rev-parse

2013-10-10 Thread Stefan Stanacar

When the object passed to git rev-parse is a tag, we need to dereference
the tag until a commit id is found or the object cannot be dereferenced
anymore hence add ^0. (rev^0 is a short-hand for rev^{commit})

This avoids confusing tarballs like
http://autobuilder.yoctoproject.org/pub/releases/dora-10.0.0/poky-319e24a8b1e100e950b07bbcad5fc81c42396845.tar.bz2
which have the SHA-1 hash of the tag instead of the commit.
It was first mentioned here
https://lists.yoctoproject.org/pipermail/yocto/2013-October/018607.html

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 lib/python2.7/site-packages/autobuilder/buildsteps/CheckOutLayers.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckOutLayers.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckOutLayers.py
index f7b7d6e..46f9b25 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckOutLayers.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckOutLayers.py
@@ -128,7 +128,7 @@ class CheckOutLayers(Git):
 
 @defer.inlineCallbacks
 def parseGotRevision(self, _=None):
-stdout = yield self._dovccmd(['rev-parse', self.commit], 
collectStdout=True)
+stdout = yield self._dovccmd(['rev-parse', self.commit + ^0], 
collectStdout=True)
 revision = stdout.strip()
 if len(revision) != 40:
 raise buildstep.BuildStepFailed()
-- 
1.8.3.1

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

[yocto] [yocto-autobuilder][PATCH] buildset-config/nightly-qa-extras: make it simpler and usable

2013-09-13 Thread Stefan Stanacar

This target was missing from the nightly target for some reason.
Also, it wasn't up to date with latest changes. I've simplified it a bit,
so it has only two builds of core-image-minimal with features that are known to 
work.
And these being core-image-minimal the sanity tests are just boot+ping.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-qa-extras.conf | 12 ++--
 buildset-config/nightly.conf   |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/buildset-config/nightly-qa-extras.conf 
b/buildset-config/nightly-qa-extras.conf
index 8fddbc6..3239fda 100644
--- a/buildset-config/nightly-qa-extras.conf
+++ b/buildset-config/nightly-qa-extras.conf
@@ -8,10 +8,10 @@ steps: [{'SetDest':{}},
 {'CheckOutLayers': {}},
 {'RunPreamble': {}},
 {'GetDistroVersion' : {'distro': 'poky'}},
-{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'atextappend' : '\nROOT_HOME = /root\nIMAGE_FSTYPES = 
btrfs\nKERNEL_FEATURES_append =  cfg/fs/btrfs\n'}},
-{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
-{'BuildImages': {'images': 'core-image-sato'}},
-{'RunSanityTests': {'images': 'core-image-sato', 'timeout' : 2400}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'atextappend' : '\nIMAGE_FEATURES_append =  
read-only-rootfs\n'}},
-{'BuildImages': {'images': 'core-image-sato'}},
-{'RunSanityTests': {'images': 'core-image-sato', 'scene' : 
'sanity:boot sanity:ssh'}}]
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'BuildImages': {'images': 'core-image-minimal'}},
+{'RunSanityTests': {'images': 'core-image-minimal'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'atextappend' : '\nROOT_HOME = /root\n'}},
+{'BuildImages': {'images': 'core-image-minimal'}},
+{'RunSanityTests': {'images': 'core-image-minimal'}}]
diff --git a/buildset-config/nightly.conf b/buildset-config/nightly.conf
index 0c6615a..5641772 100644
--- a/buildset-config/nightly.conf
+++ b/buildset-config/nightly.conf
@@ -71,7 +71,7 @@ steps: [{'SetDest':{}},
   'nightly-x86-64': {}, 'nightly-x86-64-lsb': {},
   'nightly-x86': {}, 'nightly-x86-lsb': {},
   'poky-tiny': {}, 'buildtools': {},
-  'nightly-qa-systemd': {,
+  'nightly-qa-systemd': {}, 'nightly-qa-extras': 
{,
 {'PrepPkgIndex' : {}},
 {'BuildImages': {'images': 'package-index'}},
 {'CreateAutoConf': {'machine': 'atom-pc', 'SDKMACHINE' : 'x86_64', 
-- 
1.8.1.4

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

[yocto] [meta-security][PATCH] meta-security: add a basic runtime test for scanelf

2013-09-05 Thread Stefan Stanacar

Now that the testimage class from core has the ability to run tests from other
layers it makes sens to add a basic runtime test here.
This uses scanelf from the pax-utils package and scans the binaries in PATH
for TEXTREL and RPATH information.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 lib/oeqa/runtime/__init__.py |  0
 lib/oeqa/runtime/scanelf.py  | 26 ++
 2 files changed, 26 insertions(+)
 create mode 100644 lib/oeqa/runtime/__init__.py
 create mode 100644 lib/oeqa/runtime/scanelf.py

diff --git a/lib/oeqa/runtime/__init__.py b/lib/oeqa/runtime/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/lib/oeqa/runtime/scanelf.py b/lib/oeqa/runtime/scanelf.py
new file mode 100644
index 000..b9abf24
--- /dev/null
+++ b/lib/oeqa/runtime/scanelf.py
@@ -0,0 +1,26 @@
+import unittest
+from oeqa.oetest import oeRuntimeTest, skipModule
+from oeqa.utils.decorators import *
+
+def setUpModule():
+if not oeRuntimeTest.hasPackage(pax-utils):
+skipModule(pax-utils package not installed)
+
+class ScanelfTest(oeRuntimeTest):
+
+def setUp(self):
+self.scancmd = 'scanelf --quiet --recursive --mount --ldpath --path'
+
+@skipUnlessPassed('test_ssh')
+def test_scanelf_textrel(self):
+# print TEXTREL information
+self.scancmd +=  --textrel
+(status, output) = self.target.run(self.scancmd)
+self.assertEqual(output.strip(), , \n.join([self.scancmd, output]))
+
+@skipUnlessPassed('test_ssh')
+def test_scanelf_rpath(self):
+# print RPATH information
+self.scancmd +=  --rpath
+(status, output) = self.target.run(self.scancmd)
+self.assertEqual(output.strip(), , \n.join([self.scancmd, output]))
-- 
1.8.3.1

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

[yocto] [meta-security][PATCH] Add runtime test for some scripts in redhat-security package

2013-09-05 Thread Stefan Stanacar

Now that the testimage class from core has the ability to run tests from other
layers it makes sens to add a basic runtime test here.
This runs some basic scripts from the redhat-security package that this layer 
provides.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 lib/oeqa/runtime/__init__.py|  0
 lib/oeqa/runtime/securityscripts.py | 27 +++
 2 files changed, 27 insertions(+)
 create mode 100644 lib/oeqa/runtime/__init__.py
 create mode 100644 lib/oeqa/runtime/securityscripts.py

diff --git a/lib/oeqa/runtime/__init__.py b/lib/oeqa/runtime/__init__.py
new file mode 100644
index 000..e69de29
diff --git a/lib/oeqa/runtime/securityscripts.py 
b/lib/oeqa/runtime/securityscripts.py
new file mode 100644
index 000..f78c28d
--- /dev/null
+++ b/lib/oeqa/runtime/securityscripts.py
@@ -0,0 +1,27 @@
+# Runs on target some of the scripts found in redhat-security package
+# The target image should be an rpm one as the scripts themselves call rpm.
+import unittest
+from oeqa.oetest import oeRuntimeTest, skipModule
+from oeqa.utils.decorators import *
+
+def setUpModule():
+skipModuleUnless(oeRuntimeTest.hasPackage(redhat-security), 
redhat-security package not installed)
+skipModuleUnless(oeRuntimeTest.hasFeature(package-management), target 
doesn't have package-management in IMAGE_FEATURES)
+skipModuleUnless(package_rpm == 
oeRuntimeTest.tc.d.getVar(PACKAGE_CLASSES, True).split()[0], target doesn't 
have rpm as primary package manager)
+
+class SecurityScriptsTest(oeRuntimeTest):
+
+@skipUnlessPassed('test_ssh')
+def test_find_chroot(self):
+(status, output) = self.target.run('find-chroot.sh', 1200)
+self.assertEqual(status, 0, msg=find-chroot output:\n%s % output)
+
+@skipUnlessPassed('test_ssh')
+def test_find_nodrop_groups(self):
+(status, output) = self.target.run('find-nodrop-groups.sh', 1200)
+self.assertEqual(status, 0, msg=find-nodrop-gropus output:\n%s % 
output)
+
+@skipUnlessPassed('test_ssh')
+def test_find_execstack(self):
+(status, output) = self.target.run('find-execstack.sh', 1200)
+self.assertEqual(status, 0, msg=find-execstack output:\n%s % output)
-- 
1.8.3.1

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

[yocto] [PATCH][yocto-autobuilder] nightly-x32.conf: make use of new test

2013-08-30 Thread Stefan Stanacar

Needs to be added only to sato, no ssh in minimal.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-x32.conf | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/buildset-config/nightly-x32.conf b/buildset-config/nightly-x32.conf
index f4dcbca..cd43a88 100644
--- a/buildset-config/nightly-x32.conf
+++ b/buildset-config/nightly-x32.conf
@@ -15,4 +15,6 @@ steps: [{'SetDest':{}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'PublishLayerTarballs':{}},
 {'BuildImages': {'images': 'core-image-minimal core-image-sato'}},
-{'RunSanityTests': {'images': 'core-image-minimal core-image-sato'}}]
+{'RunSanityTests': {'images': 'core-image-minimal'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'x32': True, 'distro': 'poky'}},
+{'RunSanityTests': {'images': 'core-image-sato', 'suitesappend' : 
'x32lib'}}]
-- 
1.8.1.4

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

[yocto] [PATCH][yocto-autobuilder] buildsteps/RunSanityTests: use boot timeout option for testimage

2013-08-30 Thread Stefan Stanacar

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
index a27cdcb..209fb2a 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
@@ -49,6 +49,7 @@ class RunSanityTests(ShellCommand):
 command = command + 'if [ $? -ne 0 ]; then echo Starting a VNC server 
on :1; vncserver :1; else echo Will use a VNC server already running on :1; 
fi;'
 if layerversion and int(layerversion)  1:
 command = command + echo 'INHERIT += \testimage\'  
./conf/auto.conf;
+command = command + echo 'TEST_QEMUBOOT_TIMEOUT = \1500\'  
./conf/auto.conf;
 if self.suites:
 command = command + echo 'TEST_SUITES = \ + self.suites + 
\' +   ./conf/auto.conf;
 if self.suitesappend:
-- 
1.8.1.4

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

Re: [yocto] bitbake with cmake recipe

2013-08-26 Thread Stefan Herbrechtsmeier


Am 26.08.2013 14:42, schrieb Zafrullah Syed:

Hi Stefan, Hi all,

My build was successful with CMake. I made some changes to my recipe:

DESCRIPTION = cameracapture application
SECTION = examples
LICENSE = CLOSED
PR = r0

DEPENDS = opencv

SRC_URI = git://github.com/zafrullahsyed/cameracapture.git 
http://github.com/zafrullahsyed/cameracapture.git;protocol=https;tag=v0.1


S = ${WORKDIR}/git

inherit pkgconfig cmake

do_install() {
install -d ${D}${bindir}
install -m 0755 cameracapture ${D}${bindir}
}

I didn't specify do_install, which caused the errors.

You shouldn't need a do_install as cmake install the binary.


On Sun, Aug 25, 2013 at 8:10 PM, Stefan Herbrechtsmeier 
ste...@herbrechtsmeier.net mailto:ste...@herbrechtsmeier.net wrote:


Am 25.08.2013 17:03, schrieb Zafrullah Syed:

Hi Stefan,

I updated my recipe:

DESCRIPTION = cameracapture application
SECTION = examples
LICENSE = CLOSED
PR = r0

DEPENDS = opencv

SRC_URI = git://github.com/zafrullahsyed/cameracapture.git
http://github.com/zafrullahsyed/cameracapture.git;protocol=https;tag=v0.1

S = ${WORKDIR}/git
inherit pkgconfig cmake

I have my source file and CMakeLists.txt as tar on github. tar is
not getting downloaded.

The tar should be in the ${WORKDIR}/git directory but it will
not work as you don't tell bitbake to unpack it.

You repository with tag v0.1 contains only a README.md!

The common use case is to put all sources into the git repository.
Why you want to save a tar in a git repository?




-- If I remove tar and keep just source file and CMakeLists.txt,
then also it is not getting downloaded.

Have you check the content of the

/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/git
directory?



I am getting

CMake Error: The source directory

/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/cameracapture-0.1
does not appear to contain CMakeLists.txt.

^^^
Are you sure you have change the S variable? The error still
reference the common directory (${WORKDIR}/${PN}-${PV}).


-- I copied my CMakeLists.txt file in ${WORKDIR}/git and tried
the build, got this following error:

ERROR: Function failed: do_configure (see

/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/temp/log.do_configure.10784
for further information)
ERROR: Logfile of failure stored in:

/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/temp/log.do_configure.10784
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
'common']
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing shell function do_configure
| CMake Error at

/home/siguser/yocto/build/tmp/sysroots/x86_64-linux/usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:95
(MESSAGE):
|   Could not find toolchain file:
|

/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/toolchain.cmake

It looks as something went wrong. Please clear the old package and
try again or increment the PR number.
bitbake -c cleansstate cameracapture  bitbake cameracapture



| Call Stack (most recent call first):
|   CMakeLists.txt:2 (project)
|
|
| CMake Error: Error required internal CMake variable not set,
cmake may be not be built correctly.
| Missing variable is:
| CMAKE_C_COMPILER_ENV_VAR
| CMake Error: Error required internal CMake variable not set,
cmake may be not be built correctly.
| Missing variable is:
| CMAKE_C_COMPILER
| CMake Error: Could not find cmake module

file:/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/git/CMakeFiles/CMakeCCompiler.cmake
| CMake Error: Error required internal CMake variable not set,
cmake may be not be built correctly.
| Missing variable is:
| CMAKE_CXX_COMPILER_ENV_VAR
| CMake Error: Error required internal CMake variable not set,
cmake may be not be built correctly.
| Missing variable is:
| CMAKE_CXX_COMPILER
| CMake Error: Could not find cmake module

file:/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/git/CMakeFiles/CMakeCXXCompiler.cmake
| CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
| CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
| -- Configuring incomplete, errors occurred!
| ERROR: Function failed: do_configure (see

/home/siguser

Re: [yocto] bitbake with cmake recipe

2013-08-25 Thread Stefan Herbrechtsmeier


Am 25.08.2013 17:03, schrieb Zafrullah Syed:

Hi Stefan,

I updated my recipe:

DESCRIPTION = cameracapture application
SECTION = examples
LICENSE = CLOSED
PR = r0

DEPENDS = opencv

SRC_URI = git://github.com/zafrullahsyed/cameracapture.git 
http://github.com/zafrullahsyed/cameracapture.git;protocol=https;tag=v0.1


S = ${WORKDIR}/git
inherit pkgconfig cmake

I have my source file and CMakeLists.txt as tar on github. tar is not 
getting downloaded.
The tar should be in the ${WORKDIR}/git directory but it will not work 
as you don't tell bitbake to unpack it.


You repository with tag v0.1 contains only a README.md!

The common use case is to put all sources into the git repository. Why 
you want to save a tar in a git repository?




-- If I remove tar and keep just source file and CMakeLists.txt, then 
also it is not getting downloaded.
Have you check the content of the 
/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/git 
directory?



I am getting

CMake Error: The source directory 
/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/cameracapture-0.1 
does not appear to contain CMakeLists.txt.

^^^
Are you sure you have change the S variable? The error still reference 
the common directory (${WORKDIR}/${PN}-${PV}).


-- I copied my CMakeLists.txt file in ${WORKDIR}/git and tried the 
build, got this following error:


ERROR: Function failed: do_configure (see 
/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/temp/log.do_configure.10784 
for further information)
ERROR: Logfile of failure stored in: 
/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/temp/log.do_configure.10784

Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 
'common']

| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing shell function do_configure
| CMake Error at 
/home/siguser/yocto/build/tmp/sysroots/x86_64-linux/usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:95 
(MESSAGE):

|   Could not find toolchain file:
| 
/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/toolchain.cmake
It looks as something went wrong. Please clear the old package and try 
again or increment the PR number.

bitbake -c cleansstate cameracapture  bitbake cameracapture


| Call Stack (most recent call first):
|   CMakeLists.txt:2 (project)
|
|
| CMake Error: Error required internal CMake variable not set, cmake 
may be not be built correctly.

| Missing variable is:
| CMAKE_C_COMPILER_ENV_VAR
| CMake Error: Error required internal CMake variable not set, cmake 
may be not be built correctly.

| Missing variable is:
| CMAKE_C_COMPILER
| CMake Error: Could not find cmake module 
file:/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/git/CMakeFiles/CMakeCCompiler.cmake
| CMake Error: Error required internal CMake variable not set, cmake 
may be not be built correctly.

| Missing variable is:
| CMAKE_CXX_COMPILER_ENV_VAR
| CMake Error: Error required internal CMake variable not set, cmake 
may be not be built correctly.

| Missing variable is:
| CMAKE_CXX_COMPILER
| CMake Error: Could not find cmake module 
file:/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/git/CMakeFiles/CMakeCXXCompiler.cmake

| CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
| CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
| -- Configuring incomplete, errors occurred!
| ERROR: Function failed: do_configure (see 
/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/temp/log.do_configure.10784 
for further information)
ERROR: Task 6 
(/home/siguser/yocto/poky/meta-bebot/recipes-bebot/cameracapture/cameracapture_0.1.bb 
http://cameracapture_0.1.bb, do_configure) failed with exit code '1'


Do I need to set CXX Compiler in my CMakeLists.txt?

No, this are subsequent errors of the missing toolchain.cmake.


My CmakeLists.txt file:

cmake_minimum_required(VERSION 2.8)
project(cameracapture)
find_package( OpenCV REQUIRED )
add_executable( cameracapture cameracapture.cpp )
target_link_libraries( cameracapture ${OpenCV_LIBS} )

This looks okay.

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

Re: [yocto] bitbake with cmake recipe

2013-08-23 Thread Stefan Herbrechtsmeier


Am 22.08.2013 20:13, schrieb Zafrullah Syed:

Hi all,

I am newbie and I am learning stuff.

I have a c++ code and CMakeLists.txt on Github which needs to be run 
with Cmake. I am trying to get that code embed into my build using my 
own recipe. This is my first experience with Cmake. I have no clue 
what should I write in my recipe.


My recipe is as follows:

DESCRIPTION = cameracapture application
SECTION = examples
LICENSE = CLOSED
PR = r0

DEPENDS += opencv
inherit cmake pkgconfig

SRC_URI = 
git://github.com/zafrullahsyed/cameracapture.git;protocol=https;tag=v0.1 
http://github.com/zafrullahsyed/cameracapture.git;protocol=https;tag=v0.1


do_configure() {
${BUILD_CXX} cameracapture.cpp -o cameracapture
}

Why you want to compile something during configure? Remove this function.



EXTRA_OECMAKE=
You don't need this if you don't need to pass additional definitions to 
cmake.




I know this recipe is wrong, I looked up many other recipes that use Cmake
http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-connectivity/gnuradio/gnuradio_git.bb

each of them have their own parameters and functions.

Everytime I build my system I get this error:

ERROR: Function failed: do_configure (see 
/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/temp/log.do_configure.1410 
for further information)
ERROR: Logfile of failure stored in: 
/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/temp/log.do_configure.1410

Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 
'common']

| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing shell function do_configure
| CMake Error: The source directory 
/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/cameracapture-0.1 
does not appear to contain CMakeLists.txt.
Are you sure this directory exists and contain the CMakeLists.txt file? 
Maybe you have to adjust the S variable to point to the directory of 
your source code.



| Specify --help for usage, or press the help button on the CMake GUI.
| ERROR: Function failed: do_configure (see 
/home/siguser/yocto/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/cameracapture-0.1-r0/temp/log.do_configure.1410 
for further information)
ERROR: Task 579 
(/home/siguser/yocto/poky/meta-bebot/recipes-bebot/cameracapture/cameracapture_0.1.bb 
http://cameracapture_0.1.bb, do_configure) failed with exit code '1'


I have no clue what I should write in my recipe file. Yocto doesn't 
have any tutorial for this.


Can anyone give some hints where I am doing wrong or what should be 
included in my recipe?

You can take a look at one of my simple recipes:
http://opensource.cit-ec.de/projects/meta-openrobotix/repository/revisions/master/entry/recipes-connectivity/rsb/rsb_git.bb

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

[yocto] [yocto-autobuilder][PATCH] buildset-config: update remaining targets to layerversion

2013-07-19 Thread Stefan Stanacar

Update remaining targets to use the new layerversion check,
otherwise the old qemuimagetest will be used for RunSanityTests.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-multilib.conf   | 2 +-
 buildset-config/nightly-qa-extras.conf  | 2 +-
 buildset-config/nightly-qa-systemd.conf | 2 +-
 buildset-config/nightly-x32.conf| 3 +--
 4 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/buildset-config/nightly-multilib.conf 
b/buildset-config/nightly-multilib.conf
index cc01797..bf045a7 100644
--- a/buildset-config/nightly-multilib.conf
+++ b/buildset-config/nightly-multilib.conf
@@ -2,7 +2,7 @@
 builders: 'builder1'
 repos: [{'poky': 
 {'repourl':'git://git.yoctoproject.org/poky', 
- 'bbpriority':'1', 
+ 'layerversion':'core',
  'branch':'master'}}, 
 {'meta-qt3': 
 {'repourl':'git://git.yoctoproject.org/meta-qt3', 
diff --git a/buildset-config/nightly-qa-extras.conf 
b/buildset-config/nightly-qa-extras.conf
index 23c955c..943d010 100644
--- a/buildset-config/nightly-qa-extras.conf
+++ b/buildset-config/nightly-qa-extras.conf
@@ -2,7 +2,7 @@
 builders: 'builder1'
 repos: [{'poky':
 {'repourl':'git://git.yoctoproject.org/poky',
- 'bbpriority':'1',
+ 'layerversion':'core',
  'branch':'master'}}]
 steps: [{'SetDest':{}},
 {'CheckOutLayers': {}},
diff --git a/buildset-config/nightly-qa-systemd.conf 
b/buildset-config/nightly-qa-systemd.conf
index 0467040..97f8a4a 100644
--- a/buildset-config/nightly-qa-systemd.conf
+++ b/buildset-config/nightly-qa-systemd.conf
@@ -2,7 +2,7 @@
 builders: 'builder1'
 repos: [{'poky':
 {'repourl':'git://git.yoctoproject.org/poky',
- 'bbpriority':'1',
+ 'layerversion':'core',
  'branch':'master'}}]
 steps: [{'SetDest':{}},
 {'CheckOutLayers': {}},
diff --git a/buildset-config/nightly-x32.conf b/buildset-config/nightly-x32.conf
index 636b1c3..2943ef6 100644
--- a/buildset-config/nightly-x32.conf
+++ b/buildset-config/nightly-x32.conf
@@ -2,11 +2,10 @@
 builders: 'builder1'
 repos: [{'poky': 
 {'repourl':'git://git.yoctoproject.org/poky', 
- 'bbpriority':'1', 
+ 'layerversion':'core',
  'branch':'master'}}, 
 {'meta-qt3': 
 {'repourl':'git://git.yoctoproject.org/meta-qt3', 
- 'bbpriority':'2', 
  'branch':'master'}}] 
 steps: [{'SetDest':{}}, 
 {'CheckOutLayers': {}}, 
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 1/3] RunSanityTests: add support for the new testimage class

Now that the new qemu testimage class has been merged in master,
we should use it instead of the old one.
We use suites keyword to overwrite the default tests (which are
defined in the class) and suitesappend to append to the default list
for special cases (like systemd images)

[YOCTO #4838]

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 .../autobuilder/buildsteps/RunSanityTests.py   | 27 --
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
index 82fb044..a8948d7 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
@@ -24,23 +24,36 @@ class RunSanityTests(ShellCommand):
 self.factory = factory
 self.images=
 self.scene=None
+self.suites=None
+self.suitesappend=None
 # the default of 1200 seconds is enough for running sanity tests in 
most cases
 self.timeout = 1200
 for k, v in argdict.iteritems():
 setattr(self, k, v)
 self.description = Running Sanity Tests
+kwargs['timeout']=self.timeout
+ShellCommand.__init__(self, **kwargs)
+
+def start(self):
+branch = self.getProperty(branch_poky)
 command = 
 command = command + . ./oe-init-build-env; 
 command = command + (echo  /dev/tcp/localhost/5901) 2 /dev/null;
 command = command + 'if [ $? -ne 0 ]; then echo Starting a VNC server 
on :1; vncserver :1; else echo Will use a VNC server already running on :1; 
fi;'
-command = command + echo 'IMAGETEST = \qemu\'  ./conf/auto.conf;
-if self.scene:
-command = command + echo 'TEST_SCEN = \ + self.scene + \' + 
  ./conf/auto.conf;
-command = command + DISPLAY=localhost:1 bitbake  + self.images +  
-c qemuimagetest_standalone
-# Timeout needs to be passed to LoggingBuildStep as a kwarg
-kwargs['timeout']=self.timeout
+if danny not in branch and dylan not in branch:
+command = command + echo 'INHERIT += \testimage\'  
./conf/auto.conf;
+if self.suites:
+command = command + echo 'TEST_SUITES = \ + self.suites + 
\' +   ./conf/auto.conf;
+if self.suitesappend:
+command = command + echo 'TEST_SUITES_append = \  + 
self.suitesappend + \' +   ./conf/auto.conf;
+command = command + DISPLAY=:1 bitbake  + self.images +  -c 
testimage
+else:
+command = command + echo 'IMAGETEST = \qemu\'  
./conf/auto.conf;
+if self.scene:
+command = command + echo 'TEST_SCEN = \ + self.scene + 
\' +   ./conf/auto.conf;
+command = command + DISPLAY=localhost:1 bitbake  + self.images + 
 -c qemuimagetest_standalone
 self.command = command
-ShellCommand.__init__(self, **kwargs)
+ShellCommand.start(self)
 
 def describe(self, done=False):
 description = ShellCommand.describe(self,done)
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 3/3] buildsets: run sanity tests for core-image-sato-sdk images

We build sato-sdk images in these nightly targets
(and now we have a gcc test in the new testimage class),
so for a few more minutes added we should test these images too.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-arm.conf| 2 +-
 buildset-config/nightly-mips.conf   | 2 +-
 buildset-config/nightly-ppc.conf| 2 +-
 buildset-config/nightly-x86-64.conf | 2 +-
 buildset-config/nightly-x86.conf| 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/buildset-config/nightly-arm.conf b/buildset-config/nightly-arm.conf
index 90e5332..1168596 100644
--- a/buildset-config/nightly-arm.conf
+++ b/buildset-config/nightly-arm.conf
@@ -16,7 +16,7 @@ steps: [{'SetDest':{}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'SyncPersistDB' : {'distro' : 'poky'}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
-{'RunSanityTests': {'images': 'core-image-minimal core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-minimal core-image-sato 
core-image-sato-sdk'}},
 {'CreateAutoConf': {'machine': 'beagleboard', 'SDKMACHINE' : 'i686', 
'distro': 'poky'}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
 {'CreateAutoConf': {'machine': 'qemuarm', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'buildhistory' : False}},
diff --git a/buildset-config/nightly-mips.conf 
b/buildset-config/nightly-mips.conf
index c5c24d3..14c2c7c 100644
--- a/buildset-config/nightly-mips.conf
+++ b/buildset-config/nightly-mips.conf
@@ -16,7 +16,7 @@ steps: [{'SetDest':{}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'SyncPersistDB' : {'distro' : 'poky'}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
-{'RunSanityTests': {'images': 'core-image-minimal core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-minimal core-image-sato 
core-image-sato-sdk'}},
 {'CreateAutoConf': {'machine': 'routerstationpro', 'SDKMACHINE' : 
'i686', 'distro': 'poky'}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
 {'CreateAutoConf': {'machine': 'qemumips', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'buildhistory' : False}},
diff --git a/buildset-config/nightly-ppc.conf b/buildset-config/nightly-ppc.conf
index c446b30..3b2dd73 100644
--- a/buildset-config/nightly-ppc.conf
+++ b/buildset-config/nightly-ppc.conf
@@ -16,7 +16,7 @@ steps: [{'SetDest':{}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'SyncPersistDB' : {'distro' : 'poky'}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
-{'RunSanityTests': {'images': 'core-image-minimal core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-minimal core-image-sato 
core-image-sato-sdk'}},
 {'CreateAutoConf': {'machine': 'mpc8315e-rdb', 'SDKMACHINE' : 'i686', 
'distro': 'poky'}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
 {'CreateAutoConf': {'machine': 'qemuppc', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'buildhistory' : False}},
diff --git a/buildset-config/nightly-x86-64.conf 
b/buildset-config/nightly-x86-64.conf
index ab25610..92868f4 100644
--- a/buildset-config/nightly-x86-64.conf
+++ b/buildset-config/nightly-x86-64.conf
@@ -16,7 +16,7 @@ steps: [{'SetDest':{}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'SyncPersistDB' : {'distro' : 'poky'}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
-{'RunSanityTests': {'images': 'core-image-minimal core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-minimal core-image-sato 
core-image-sato-sdk'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'buildhistory' : False}},
 {'BuildImages': {'images': 'meta-toolchain-gmae'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86-64', 
'distro': 'poky', 'buildhistory' : False}},
diff --git a/buildset-config/nightly-x86.conf b/buildset-config/nightly-x86.conf
index 6920cad..f83e995 100644
--- a/buildset-config/nightly-x86.conf
+++ b/buildset-config/nightly-x86.conf
@@ -16,7 +16,7 @@ steps: [{'SetDest':{}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'SyncPersistDB' : {'distro' : 'poky'}},
 {'BuildImages': {'images': 'core-image-sato core-image-sato-dev 
core-image-sato-sdk

[yocto] [yocto-autobuilder][PATCH 2/3] nightly-multilib, qa-systemd.conf: enable specific tests with the new class

Enable specific tests for some builds (like systemd and multilib which aren't
by default enabled in the testimage class)
Also because one of the multilib builds is an ipk build and the default suite
contains rpm and smart we need to overwrite the suite.

[YOCTO #4838]

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-multilib.conf   | 8 
 buildset-config/nightly-qa-systemd.conf | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/buildset-config/nightly-multilib.conf 
b/buildset-config/nightly-multilib.conf
index bdb0193..cc01797 100644
--- a/buildset-config/nightly-multilib.conf
+++ b/buildset-config/nightly-multilib.conf
@@ -15,15 +15,15 @@ steps: [{'SetDest':{}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'multilib': True, 'distro': 'poky'}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'BuildImages': {'images': 'lib32-core-image-minimal'}},
-{'RunSanityTests': {'images': 'lib32-core-image-minimal', 'scene' : 
'sanity:boot'}},
+{'RunSanityTests': {'images': 'lib32-core-image-minimal', 'scene' : 
'sanity:boot', 'suites' : 'ping'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'multilib': True, 'distro': 'poky', 'packages' : 'ipk'}},
 {'BuildImages': {'images': 'lib32-core-image-minimal'}},
-{'RunSanityTests': {'images': 'lib32-core-image-minimal', 'scene' : 
'sanity:boot'}},
+{'RunSanityTests': {'images': 'lib32-core-image-minimal', 'scene' : 
'sanity:boot', 'suites' : 'ping'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'multilib': 'lib32', 'distro': 'poky', 'atextappend' : '\nIMAGE_INSTALL_append 
=  lib32-connman-gnome\n'}},
 {'BuildImages': {'images': 'core-image-sato'}},
-{'RunSanityTests': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato', 'suitesappend' : 
'multilib'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'multilib': 'lib32', 'distro': 'poky', 'packages' : 'ipk', 'atextappend' : 
'\nIMAGE_INSTALL_append =  lib32-connman-gnome\n'}},
 {'BuildImages': {'images': 'core-image-sato'}},
-{'RunSanityTests': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato', 'suites' : 'ping ssh 
connman xorg multilib dmesg auto'}},
 {'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686', 
'multilib': 'lib64', 'distro': 'poky'}},
 {'BuildImages': {'images': 'lib64-core-image-sato 
lib64-core-image-sato-sdk lib64-core-image-lsb-sdk'}}]
diff --git a/buildset-config/nightly-qa-systemd.conf 
b/buildset-config/nightly-qa-systemd.conf
index e35e6b1..0467040 100644
--- a/buildset-config/nightly-qa-systemd.conf
+++ b/buildset-config/nightly-qa-systemd.conf
@@ -11,10 +11,10 @@ steps: [{'SetDest':{}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'initmgr' : 'systemd sysvinit'}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'BuildImages': {'images': 'core-image-sato'}},
-{'RunSanityTests': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato', 'suitesappend' : 
'systemd'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'initmgr' : 'sysvinit systemd'}},
 {'BuildImages': {'images': 'core-image-sato'}},
 {'RunSanityTests': {'images': 'core-image-sato'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'initmgr' : 'systemd'}},
 {'BuildImages': {'images': 'core-image-sato'}},
-{'RunSanityTests': {'images': 'core-image-sato'}}]
+{'RunSanityTests': {'images': 'core-image-sato', 'suitesappend' : 
'systemd'}}]
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 0/3] Enabling of the new testimage class for sanity tests

Hi Beth,

The first two patches enable the new testimage class that has just been merged 
in master,
and it needs a real AB shakedown ;). 

On my local AB one of the problems I've had were timeouts
for qemu booting (when the machine was really loaded), and I've sent a patch to 
increase the timeout, but
this might need a little more tweaking for the Yocto AB. Also, one more setup 
issue could be DISPLAY / vnc server. 
I've had some trouble with DISPLAY=localhost:1 that's why you'll notice
I've used DISPLAY=:1, that fixed the problem out on my machine. It has 
something to do with how the new class starts the runqemu script
and the enviroment.


The last patch has nothing to do with enabling, I just thought that we should 
run the sanity tests
for the sdk images too given that the new class has a gcc test. It adds a few 
minutes to the builds, 
keep this one out if that's problem.

Cheers,
Stefan

The following changes since commit b26b257e16fddb7730d3b2a0c55c4b43a48ae54c:

  Revert buildset-config: build core-image-sato SDK (2013-07-02 17:10:05 
-0700)

are available in the git repository at:

  git://mirror.rb.intel.com/git.yoctoproject.org/poky-contrib 
stefans/yab-newsanity3

for you to fetch changes up to e15d6185251e4c6f163577c7263239936d76e5b3:

  buildsets: run sanity tests for core-image-sato-sdk images (2013-07-10 
19:07:27 +0300)


Stefan Stanacar (3):
  RunSanityTests: add support for the new testimage class
  nightly-multilib,qa-systemd.conf: enable specific tests with the new class
  buildsets: run sanity tests for core-image-sato-sdk images

 buildset-config/nightly-arm.conf   |  2 +-
 buildset-config/nightly-mips.conf  |  2 +-
 buildset-config/nightly-multilib.conf  |  8 +++
 buildset-config/nightly-ppc.conf   |  2 +-
 buildset-config/nightly-qa-systemd.conf|  4 ++--
 buildset-config/nightly-x86-64.conf|  2 +-
 buildset-config/nightly-x86.conf   |  2 +-
 .../autobuilder/buildsteps/RunSanityTests.py   | 27 --
 8 files changed, 31 insertions(+), 18 deletions(-)

Stefan Stanacar (3):
  RunSanityTests: add support for the new testimage class
  nightly-multilib,qa-systemd.conf: enable specific tests with the new
class
  buildsets: run sanity tests for core-image-sato-sdk images

 buildset-config/nightly-arm.conf   |  2 +-
 buildset-config/nightly-mips.conf  |  2 +-
 buildset-config/nightly-multilib.conf  |  8 +++
 buildset-config/nightly-ppc.conf   |  2 +-
 buildset-config/nightly-qa-systemd.conf|  4 ++--
 buildset-config/nightly-x86-64.conf|  2 +-
 buildset-config/nightly-x86.conf   |  2 +-
 .../autobuilder/buildsteps/RunSanityTests.py   | 27 --
 8 files changed, 31 insertions(+), 18 deletions(-)

-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH] nightly-qa-extras: fix timeout arg

2013-06-03 Thread Stefan Stanacar

This needs to be an integer, not a string.
Fixes:
http://autobuilder.yoctoproject.org:8011/builders/nightly-qa-extras/builds/32/steps/Running%20Sanity%20Tests/logs/stdio

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-qa-extras.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/buildset-config/nightly-qa-extras.conf 
b/buildset-config/nightly-qa-extras.conf
index 1bdb0f0..23c955c 100644
--- a/buildset-config/nightly-qa-extras.conf
+++ b/buildset-config/nightly-qa-extras.conf
@@ -11,7 +11,7 @@ steps: [{'SetDest':{}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'atextappend' : '\nROOT_HOME = /root\nIMAGE_FSTYPES = 
btrfs\nKERNEL_FEATURES_append =  cfg/fs/btrfs\n'}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'BuildImages': {'images': 'core-image-sato'}},
-{'RunSanityTests': {'images': 'core-image-sato', 'timeout' : '2400'}},
+{'RunSanityTests': {'images': 'core-image-sato', 'timeout' : 2400}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'atextappend' : '\nIMAGE_FEATURES_append =  
read-only-rootfs\n'}},
 {'BuildImages': {'images': 'core-image-sato'}},
 {'RunSanityTests': {'images': 'core-image-sato', 'scene' : 
'sanity:boot sanity:ssh'}}]
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH] buildsteps: fix passing timeout arg for two steps

2013-05-24 Thread Stefan Stanacar

RunSanityTests and RunPreamble weren't passing kwargs to
ShellCommand so timeout was ignored.
For RunSanityTests I've changed the default to 1200 which should be
enough in most cases, but I've updated one build where
two images are actually tested (btrfs and ext4)

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-qa-extras.conf   | 2 +-
 lib/python2.7/site-packages/autobuilder/buildsteps/RunPreamble.py| 2 +-
 lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py | 5 +++--
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/buildset-config/nightly-qa-extras.conf 
b/buildset-config/nightly-qa-extras.conf
index 1846764..1bdb0f0 100644
--- a/buildset-config/nightly-qa-extras.conf
+++ b/buildset-config/nightly-qa-extras.conf
@@ -11,7 +11,7 @@ steps: [{'SetDest':{}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'atextappend' : '\nROOT_HOME = /root\nIMAGE_FSTYPES = 
btrfs\nKERNEL_FEATURES_append =  cfg/fs/btrfs\n'}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'BuildImages': {'images': 'core-image-sato'}},
-{'RunSanityTests': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato', 'timeout' : '2400'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'atextappend' : '\nIMAGE_FEATURES_append =  
read-only-rootfs\n'}},
 {'BuildImages': {'images': 'core-image-sato'}},
 {'RunSanityTests': {'images': 'core-image-sato', 'scene' : 
'sanity:boot sanity:ssh'}}]
diff --git a/lib/python2.7/site-packages/autobuilder/buildsteps/RunPreamble.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunPreamble.py
index d6476d6..5df2a7c 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunPreamble.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunPreamble.py
@@ -30,7 +30,7 @@ class RunPreamble(ShellCommand):
 # Timeout needs to be passed to LoggingBuildStep as a kwarg
 self.timeout = 10
 kwargs['timeout']=self.timeout
-ShellCommand.__init__(self)
+ShellCommand.__init__(self, **kwargs)
 
 def describe(self, done=False):
 description = ShellCommand.describe(self,done)
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
index 1a428be..82fb044 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
@@ -24,6 +24,8 @@ class RunSanityTests(ShellCommand):
 self.factory = factory
 self.images=
 self.scene=None
+# the default of 1200 seconds is enough for running sanity tests in 
most cases
+self.timeout = 1200
 for k, v in argdict.iteritems():
 setattr(self, k, v)
 self.description = Running Sanity Tests
@@ -36,10 +38,9 @@ class RunSanityTests(ShellCommand):
 command = command + echo 'TEST_SCEN = \ + self.scene + \' + 
  ./conf/auto.conf;
 command = command + DISPLAY=localhost:1 bitbake  + self.images +  
-c qemuimagetest_standalone
 # Timeout needs to be passed to LoggingBuildStep as a kwarg
-self.timeout = 10
 kwargs['timeout']=self.timeout
 self.command = command
-ShellCommand.__init__(self)
+ShellCommand.__init__(self, **kwargs)
 
 def describe(self, done=False):
 description = ShellCommand.describe(self,done)
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH] buildsteps, nightly: run bitbake-selftest

2013-05-13 Thread Stefan Stanacar

Added a new buildstep which calls bitbake-selftest.

[YOCTO #4433]

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly.conf   |  1 +
 .../autobuilder/buildsteps/RunBitbakeSelftest.py   | 28 ++
 2 files changed, 29 insertions(+)
 create mode 100644 
lib/python2.7/site-packages/autobuilder/buildsteps/RunBitbakeSelftest.py

diff --git a/buildset-config/nightly.conf b/buildset-config/nightly.conf
index ffbc271..80173a5 100644
--- a/buildset-config/nightly.conf
+++ b/buildset-config/nightly.conf
@@ -51,6 +51,7 @@ steps: [{'SetDest':{}},
 {'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'x86_64', 
 'distro': 'poky'}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'RunBitbakeSelftest': {}},
 {'BuildImages': {'images': 'universe -c fetch'}},
 {'TriggerBuilds': {'schedulerNames':
  {'build-appliance': {'waitForFinish': 'False'},
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunBitbakeSelftest.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunBitbakeSelftest.py
new file mode 100644
index 000..7d1874f
--- /dev/null
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunBitbakeSelftest.py
@@ -0,0 +1,28 @@
+'''
+Created on May 13, 2013
+
+__author__ = Stefan Stanacar
+__copyright__ = Copyright 2013, Intel Corp.
+__credits__ = [Stefan Stanacar]
+__license__ = GPL
+__version__ = 2.0
+__maintainer__ = Stefan Stanacar
+__email__ = stefanx.stana...@intel.com
+'''
+
+
+from buildbot.steps.shell import ShellCommand
+
+class RunBitbakeSelftest(ShellCommand):
+haltOnFailure = False
+flunkOnFailure = True
+name = Running bitbake-selftest
+def __init__(self, factory, argdict=None, **kwargs):
+self.factory = factory
+for k, v in argdict.iteritems():
+setattr(self, k, v)
+self.description = Running bitbake-selftest
+self.timeout = 10
+kwargs['timeout']=self.timeout
+self.command = . ./oe-init-build-env; bitbake-selftest
+ShellCommand.__init__(self, **kwargs)
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 0/4] Some builds (ipk, multilib) and one fix

The following changes since commit fd74be794035a2c73b206c3ca4dd4c45005037a5:

  CreateAutoConf.py (2013-05-07 09:00:49 -0700)

are available in the git repository at:

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

Stefan Stanacar (4):
  buildsets: add some more builds
  nightly-multilib: remove Publish steps
  PublishLayerTarballs.py: fix command overwrite
  PublishLayerTarballs.py: Cleanup spacing

 buildset-config/nightly-multilib.conf| 13 +
 buildset-config/nightly-qa-extras.conf   |  3 ++-
 buildset-config/nightly-x32.conf |  4 ++--
 .../autobuilder/buildsteps/PublishLayerTarballs.py   | 20 ++--
 4 files changed, 23 insertions(+), 17 deletions(-)

-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 2/4] nightly-multilib: remove Publish steps

Save some space by removing Publish steps, I think
nobody downloads the multilib images from AB.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-multilib.conf | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/buildset-config/nightly-multilib.conf 
b/buildset-config/nightly-multilib.conf
index 79d0011..bdb0193 100644
--- a/buildset-config/nightly-multilib.conf
+++ b/buildset-config/nightly-multilib.conf
@@ -26,6 +26,4 @@ steps: [{'SetDest':{}},
 {'BuildImages': {'images': 'core-image-sato'}},
 {'RunSanityTests': {'images': 'core-image-sato'}},
 {'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686', 
'multilib': 'lib64', 'distro': 'poky'}},
-{'BuildImages': {'images': 'lib64-core-image-sato 
lib64-core-image-sato-sdk lib64-core-image-lsb-sdk'}},
-{'PublishLayerTarballs':{}},
-{'PublishArtifacts': {'artifacts': ['qemux86-64']}}]
+{'BuildImages': {'images': 'lib64-core-image-sato 
lib64-core-image-sato-sdk lib64-core-image-lsb-sdk'}}]
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 3/4] PublishLayerTarballs.py: fix command overwrite

command was overwritten, so the gzip archive was missing.
Also add a trailing slash to the second git archive prefix
otherwise we end up with dirs like poky-revscripts instead of poky-rev/scripts.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 .../site-packages/autobuilder/buildsteps/PublishLayerTarballs.py  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishLayerTarballs.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishLayerTarballs.py
index 2930d28..6f676be 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishLayerTarballs.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishLayerTarballs.py
@@ -44,8 +44,8 @@ class PublishLayerTarballs(ShellCommand):
 command =  git archive --format=tar HEAD 
 command = command + --prefix= + self.layername + - + revision + /
 command = command  +| gzip   + self.layername + - + revision + 
.tar.gz;  
-command =  git archive --format=tar HEAD 
-command = command + --prefix= + self.layername + - + revision 
+command = command +  git archive --format=tar HEAD 
+command = command + --prefix= + self.layername + - + revision + /
 command = command  +| bzip2 -c   + self.layername + - + revision 
+ .tar.bz2;  
 command = command  +md5sum  + self.layername + - + revision + 
.tar.bz2  
 command = command  + self.layername + - + revision + 
.tar.bz2.md5sum; 
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 1/4] buildsets: add some more builds

Let's put to good use the new packages option, by adding
some ipk builds to multilib target. Also let's enable sanity
tests for more images.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-multilib.conf  | 9 -
 buildset-config/nightly-qa-extras.conf | 3 ++-
 buildset-config/nightly-x32.conf   | 4 ++--
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/buildset-config/nightly-multilib.conf 
b/buildset-config/nightly-multilib.conf
index f9ae8b7..79d0011 100644
--- a/buildset-config/nightly-multilib.conf
+++ b/buildset-config/nightly-multilib.conf
@@ -15,10 +15,17 @@ steps: [{'SetDest':{}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'multilib': True, 'distro': 'poky'}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'BuildImages': {'images': 'lib32-core-image-minimal'}},
+{'RunSanityTests': {'images': 'lib32-core-image-minimal', 'scene' : 
'sanity:boot'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'multilib': True, 'distro': 'poky', 'packages' : 'ipk'}},
+{'BuildImages': {'images': 'lib32-core-image-minimal'}},
+{'RunSanityTests': {'images': 'lib32-core-image-minimal', 'scene' : 
'sanity:boot'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'multilib': 'lib32', 'distro': 'poky', 'atextappend' : '\nIMAGE_INSTALL_append 
=  lib32-connman-gnome\n'}},
 {'BuildImages': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'multilib': 'lib32', 'distro': 'poky', 'packages' : 'ipk', 'atextappend' : 
'\nIMAGE_INSTALL_append =  lib32-connman-gnome\n'}},
+{'BuildImages': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato'}},
 {'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686', 
'multilib': 'lib64', 'distro': 'poky'}},
 {'BuildImages': {'images': 'lib64-core-image-sato 
lib64-core-image-sato-sdk lib64-core-image-lsb-sdk'}},
 {'PublishLayerTarballs':{}},
 {'PublishArtifacts': {'artifacts': ['qemux86-64']}}]
-
diff --git a/buildset-config/nightly-qa-extras.conf 
b/buildset-config/nightly-qa-extras.conf
index 4098f53..c3af24c 100644
--- a/buildset-config/nightly-qa-extras.conf
+++ b/buildset-config/nightly-qa-extras.conf
@@ -13,4 +13,5 @@ steps: [{'SetDest':{}},
 {'BuildImages': {'images': 'core-image-sato'}},
 {'RunSanityTests': {'images': 'core-image-sato'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'atextappend' : '\nEXTRA_IMAGE_FEATURES = debug-tweaks 
read-only-rootfs\n'}},
-{'BuildImages': {'images': 'core-image-sato'}}]
+{'BuildImages': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato', 'scene' : 
'sanity:boot sanity:ssh sanity:dmesg'}}]
diff --git a/buildset-config/nightly-x32.conf b/buildset-config/nightly-x32.conf
index b0b5b4f..636b1c3 100644
--- a/buildset-config/nightly-x32.conf
+++ b/buildset-config/nightly-x32.conf
@@ -15,5 +15,5 @@ steps: [{'SetDest':{}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64', 
'x32': True, 'distro': 'poky'}},
 {'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
 {'PublishLayerTarballs':{}},
-{'BuildImages': {'images': 'core-image-minimal core-image-sato'}}]
-
+{'BuildImages': {'images': 'core-image-minimal core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-minimal core-image-sato'}}]
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 4/4] PublishLayerTarballs.py: Cleanup spacing

No changes, just formating/spacing.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 .../autobuilder/buildsteps/PublishLayerTarballs.py   | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishLayerTarballs.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishLayerTarballs.py
index 6f676be..4a94b67 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/PublishLayerTarballs.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/PublishLayerTarballs.py
@@ -43,15 +43,15 @@ class PublishLayerTarballs(ShellCommand):
 self.slavedir, buildername), self.workdir))
 command =  git archive --format=tar HEAD 
 command = command + --prefix= + self.layername + - + revision + /
-command = command  +| gzip   + self.layername + - + revision + 
.tar.gz;  
+command = command +  | gzip   + self.layername + - + revision + 
.tar.gz; 
 command = command +  git archive --format=tar HEAD 
 command = command + --prefix= + self.layername + - + revision + /
-command = command  +| bzip2 -c   + self.layername + - + revision 
+ .tar.bz2;  
-command = command  +md5sum  + self.layername + - + revision + 
.tar.bz2  
-command = command  + self.layername + - + revision + 
.tar.bz2.md5sum; 
-command = command  +md5sum  + self.layername + - + revision + 
.tar.gz  
-command = command  + self.layername + - + revision + 
.tar.gz.md5sum;  
-command=command + mkdir -p  + DEST + ; rsync -av  
-command=command + self.layername + - + revision +.tar.*  + DEST
+command = command +  | bzip2 -c   + self.layername + - + revision 
+ .tar.bz2; 
+command = command + md5sum  + self.layername + - + revision + 
.tar.bz2  
+command = command + self.layername + - + revision + 
.tar.bz2.md5sum; 
+command = command + md5sum  + self.layername + - + revision + 
.tar.gz  
+command = command + self.layername + - + revision + .tar.gz.md5sum; 

+command = command + mkdir -p  + DEST + ; rsync -av 
+command = command + self.layername + - + revision +.tar.*  + DEST
 self.command=command
 ShellCommand.start(self)
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 0/6] New buildsets and options for 1.5

Hello Beth,

Here are the new changes, I've fixed that small issue, hope it looks good now.
After some more tests, I'll follow up with some builds for ipk only images :),
but I'm getting ahead of myelf now.

Regards,
Stefan


The following changes since commit 0178163efc6670c9acb982dd579671396cb24290:

  PublishLayerTarballs.py: bad redirect. (2013-04-22 22:56:58 -0700)

are available in the git repository at:

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

Stefan Stanacar (6):
  nightly-qa-extras.conf: add new buildset config
  CreateAutoConf.py: add initmgr option
  buildset-config/nightly-qa-systemd.conf: add a new target for systemd
images
  nightly.conf, yoctoAB.conf: enable the new buildsets
  buildsteps/RunSanityTests.py: add suport for custom steps
  CreateAutoConf.py: add option for package types

 buildset-config/nightly-qa-extras.conf | 16 
 buildset-config/nightly-qa-systemd.conf| 20 
 buildset-config/nightly.conf   |  3 ++-
 buildset-config/yoctoAB.conf   |  3 ++-
 .../autobuilder/buildsteps/CreateAutoConf.py   | 22 --
 .../autobuilder/buildsteps/RunSanityTests.py   |  3 +++
 6 files changed, 63 insertions(+), 4 deletions(-)
 create mode 100644 buildset-config/nightly-qa-extras.conf
 create mode 100644 buildset-config/nightly-qa-systemd.conf

-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 1/6] nightly-qa-extras.conf: add new buildset config

This buildset is for extra images which don't really fit in other buildsets.
For now it includes builds for two images: one with btrfs and diffrent root
home dir and a sato image with read-only rootfs.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-qa-extras.conf | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 buildset-config/nightly-qa-extras.conf

diff --git a/buildset-config/nightly-qa-extras.conf 
b/buildset-config/nightly-qa-extras.conf
new file mode 100644
index 000..4098f53
--- /dev/null
+++ b/buildset-config/nightly-qa-extras.conf
@@ -0,0 +1,16 @@
+[nightly-qa-extras]
+builders: 'builder1'
+repos: [{'poky':
+{'repourl':'git://git.yoctoproject.org/poky',
+ 'bbpriority':'1',
+ 'branch':'master'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'atextappend' : '\nROOT_HOME = /root\nIMAGE_FSTYPES = 
btrfs\nKERNEL_FEATURES_append =  cfg/fs/btrfs\n'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'BuildImages': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'atextappend' : '\nEXTRA_IMAGE_FEATURES = debug-tweaks 
read-only-rootfs\n'}},
+{'BuildImages': {'images': 'core-image-sato'}}]
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 4/6] nightly.conf, yoctoAB.conf: enable the new buildsets

Add the new nightly-qa-extras and nightly-qa-systemd
buildsets to the nightly target.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly.conf | 3 ++-
 buildset-config/yoctoAB.conf | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/buildset-config/nightly.conf b/buildset-config/nightly.conf
index 58a8531..ffbc271 100644
--- a/buildset-config/nightly.conf
+++ b/buildset-config/nightly.conf
@@ -67,7 +67,8 @@ steps: [{'SetDest':{}},
   'nightly-x32': {},
   'nightly-x86-64': {}, 'nightly-x86-64-lsb': {},
   'nightly-x86': {}, 'nightly-x86-lsb': {},
-  'poky-tiny': {,
+  'poky-tiny': {},
+  'nightly-qa-extras': {}, 'nightly-qa-systemd': 
{,
 {'PrepPkgIndex' : {}},
 {'BuildImages': {'images': 'package-index'}},
 {'CreateAutoConf': {'machine': 'atom-pc', 'SDKMACHINE' : 'x86_64', 
diff --git a/buildset-config/yoctoAB.conf b/buildset-config/yoctoAB.conf
index 5f29400..2f22767 100644
--- a/buildset-config/yoctoAB.conf
+++ b/buildset-config/yoctoAB.conf
@@ -4,4 +4,5 @@ order: ['nightly', 'eclipse-plugin', 'nightly-arm', 
'nightly-arm-lsb', 'nightly-
 'nightly-x86-64', 'nightly-x86-64-lsb', 'nightly-x86',
 'nightly-x86-lsb', 'nightly-x32', 'nightly-multilib',
 'nightly-world', 'nightly-non-gpl3', 'nightly-oecore',
-'nightly-intel-gpl', 'poky-tiny', 'build-appliance']
+'nightly-intel-gpl', 'poky-tiny', 'build-appliance',
+'nightly-qa-extras', 'nightly-qa-systemd']
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 5/6] buildsteps/RunSanityTests.py: add suport for custom steps

Add an option so we can pass custom qemuimage tests,
by appending TEST_SCEN to local.conf.

This isn't used by any buildsets right now.

It could be used when we want to run only certain sanity tests (i.e don't run
all the tests in the image scenario but run only sanity:boot and sanity:dmesg
by appending TEST_SCENE = sanity:boot sanity:dmesg)

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
index a352de5..1a428be 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
@@ -23,6 +23,7 @@ class RunSanityTests(ShellCommand):
 def __init__(self, factory, argdict=None, **kwargs):
 self.factory = factory
 self.images=
+self.scene=None
 for k, v in argdict.iteritems():
 setattr(self, k, v)
 self.description = Running Sanity Tests
@@ -31,6 +32,8 @@ class RunSanityTests(ShellCommand):
 command = command + (echo  /dev/tcp/localhost/5901) 2 /dev/null;
 command = command + 'if [ $? -ne 0 ]; then echo Starting a VNC server 
on :1; vncserver :1; else echo Will use a VNC server already running on :1; 
fi;'
 command = command + echo 'IMAGETEST = \qemu\'  ./conf/auto.conf;
+if self.scene:
+command = command + echo 'TEST_SCEN = \ + self.scene + \' + 
  ./conf/auto.conf;
 command = command + DISPLAY=localhost:1 bitbake  + self.images +  
-c qemuimagetest_standalone
 # Timeout needs to be passed to LoggingBuildStep as a kwarg
 self.timeout = 10
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 6/6] CreateAutoConf.py: add option for package types

Using this option we'll be able to select only certain packages
to be built and because the order is important we determine the
image type too. E.g 'packages' : 'deb rpm' will build deb and rpm
packages but the image will use deb as package manager.

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 .../site-packages/autobuilder/buildsteps/CreateAutoConf.py | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
index fd73a3d..8fbef3e 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CreateAutoConf.py
@@ -22,6 +22,7 @@ class CreateAutoConf(ShellCommand):
 self.machine=
 self.buildapp=
 self.distro=poky
+self.packages=None
 self.buildhistory=False
 self.gplv3=True
 self.multilib=False
@@ -59,7 +60,11 @@ class CreateAutoConf(ShellCommand):
 else:
 if self.distro != oecore:
 fout = fout + 'DISTRO = ' + self.distro + '\n'
-fout = fout + 'PACKAGE_CLASSES = package_rpm package_deb 
package_ipk\n'
+if self.packages:
+self.classes = [ package_%s % p for p in 
self.packages.split() ]
+fout = fout + 'PACKAGE_CLASSES = ' +  .join(self.classes) + 
'\n'
+else:
+fout = fout + 'PACKAGE_CLASSES = package_rpm package_deb 
package_ipk\n'
 fout = fout + 'BB_NUMBER_THREADS = ' + 
os.environ.get('BB_NUMBER_THREADS') + '\n'
 fout = fout + 'PARALLEL_MAKE = -j ' + 
os.environ.get('PARALLEL_MAKE') + '\n'
 fout = fout + 'SDKMACHINE ?= ' + self.SDKMACHINE + '\n'
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 3/6] buildset-config/nightly-qa-systemd.conf: add a new target for systemd images

Build systemd images in different configurations: systemd only,
systemd+sysvinit and sysvinit+systemd (the order means which is the primary 
init system).

Signed-off-by: Stefan Stanacar stefanx.stana...@intel.com
---
 buildset-config/nightly-qa-systemd.conf | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 buildset-config/nightly-qa-systemd.conf

diff --git a/buildset-config/nightly-qa-systemd.conf 
b/buildset-config/nightly-qa-systemd.conf
new file mode 100644
index 000..e35e6b1
--- /dev/null
+++ b/buildset-config/nightly-qa-systemd.conf
@@ -0,0 +1,20 @@
+[nightly-qa-systemd]
+builders: 'builder1'
+repos: [{'poky':
+{'repourl':'git://git.yoctoproject.org/poky',
+ 'bbpriority':'1',
+ 'branch':'master'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'initmgr' : 'systemd sysvinit'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'BuildImages': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'initmgr' : 'sysvinit systemd'}},
+{'BuildImages': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato'}},
+{'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'i686', 
'distro': 'poky', 'initmgr' : 'systemd'}},
+{'BuildImages': {'images': 'core-image-sato'}},
+{'RunSanityTests': {'images': 'core-image-sato'}}]
-- 
1.8.1.4

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

[yocto] [yocto-autobuilder][PATCH 2/6] CreateAutoConf.py: add initmgr option