With latest oe-core/master I get this exception when building my images:
ERROR: Error executing a python function in /OE/recipes-core/images/my-image.bb:
The stack trace of python calls that resulted in this exception/failure was:
File: 'do_rootfs', lineno: 17, function:
0013:# generate
On 14-02-18 09:40 PM, Khem Raj wrote:
On Feb 18, 2014, at 6:35 PM, Zhu Yanjun wrote:
+export BUILD_SYS
+export HOST_SYS
+export STAGING_LIBDIR
+export STAGING_INCDIR
+
why are these needed ?
Also, meta-security recipes are discussed on:
yo...@yoctoproject.org
not the oe-core list.
../R
Install libpcre test suite and run it as ptest.
Signed-off-by: Chong Lu
---
meta/recipes-support/libpcre/libpcre/Makefile | 183 +
meta/recipes-support/libpcre/libpcre/run-ptest | 3 +
meta/recipes-support/libpcre/libpcre_8.34.bb | 19 ++-
3 files changed, 203 inser
The following changes since commit 54562006c1327c5b99daa4cc05a3ba7e38412da1:
image_types.bbclass: Fix tar IMAGE_CMD to not change directories (2014-02-18
08:38:52 +)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib chonglu/libpcre
http://git.pokylinux.org/c
On Feb 18, 2014, at 6:35 PM, Zhu Yanjun wrote:
> +export BUILD_SYS
> +export HOST_SYS
> +export STAGING_LIBDIR
> +export STAGING_INCDIR
> +
why are these needed ?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists
---
recipes-security/nmap/nmap_6.25.bb |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/recipes-security/nmap/nmap_6.25.bb
b/recipes-security/nmap/nmap_6.25.bb
index aff5c63..8d7e853 100644
--- a/recipes-security/nmap/nmap_6.25.bb
+++ b/recipes-security/nmap/nmap_6.
On 02/18/2014 01:31 PM, Peter Seebach wrote:
On Tue, 18 Feb 2014 11:08:40 -0800
Saul Wold wrote:
There is no patch header here, also have you checked with Peter S on
this change?
The change originated with me, and is in my current 1.6 pseudo branch. The
backport was being submitted because I
The working directory is changed in a subshell when executing cpio to
preserve the working directory for any subsequent commands. This is to
keep the working directory consistent when generating multiple image
types.
Signed-off-by: Jonathan Liu
---
meta/classes/image_types.bbclass | 2 +-
1 file
On Tue, 18 Feb 2014 11:08:40 -0800
Saul Wold wrote:
> There is no patch header here, also have you checked with Peter S on
> this change?
The change originated with me, and is in my current 1.6 pseudo branch. The
backport was being submitted because I am on other projects actively enough
that I
On Tuesday 18 February 2014 at 13:01:31 -0800, Khem Raj wrote:
> On Tue, Feb 18, 2014 at 12:53 PM, Mike Crowe wrote:
> > or should users of this recipe be given a convenient ability to override
> > the compileflags, with perhaps something like:
> >
> > 'using gcc ; 4.3.1 : ${CXX} : "${CFLAGS}" "$
On Tue, Feb 18, 2014 at 5:27 AM, Martin Jansa wrote:
> Maybe we should change meta/classes/package.bbclass to
> fail when some filedeprunner call fails like this and fix
> filedeprunner to escape '()' and other possibly dangerous chars
> it's called like this:
> processed = list(pool.ima
On Tue, Feb 18, 2014 at 12:53 PM, Mike Crowe wrote:
> or should users of this recipe be given a convenient ability to override
> the compileflags, with perhaps something like:
>
> 'using gcc ; 4.3.1 : ${CXX} : "${CFLAGS}" "${CXXFLAGS}" ;'
this one. care to send a patch ?
boost.inc's do_boostconfig task contains:
# D2194:Fixing the failure of "error: duplicate initialization of gcc with the
following parameters" during compilation.
if ! grep -qe "^using gcc : 4.3.1" ${S}/tools/build/v2/user-config.jam
then
echo 'using gcc : 4.3.1 : ${CXX} : compileflags -DBO
On 18 February 2014 15:56:41 Khem Raj wrote:
On Tue, Feb 18, 2014 at 4:08 AM, Jonathan Liu wrote:
> }
> IMAGE_CMD_cpio () {
> ${CPIO_TOUCH_INIT}
> - cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc
>${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
> + (cd ${IMAGE_ROOTFS} &&
On Tue, Feb 18, 2014 at 4:07 PM, Khem Raj wrote:
> > Looking at the main library header
> (tools/designer/src/uitools/quiloader.h)
> > it mentions the Digia Commercial License, LGPL v2.1, LGPL Exception and
> > GPLv3.
>
> what would be the license of this given library is it all of above or
> som
On 02/17/2014 02:17 AM, Zhu Yanjun wrote:
From: "yanjun.zhu"
CQID:LIN5-17788
when install command sets the created directory mode, pseudo will change
the mode of the directory to 0700 incorrectly.
Signed-off-by: yanjun.zhu
---
.../pseudo-1.5.1-install-directory-mode.patch | 10 +
On Tue, Feb 18, 2014 at 10:55 AM, Diego Sueiro wrote:
> Khem,
>
> On Tue, Feb 18, 2014 at 2:51 PM, Khem Raj wrote:
>>
>> can you also figure out what is the licensing terms of these static .a
>> archives please ?
>> and make a note of it in commit message or somewhere
>
> Looking at the main libr
Khem,
On Tue, Feb 18, 2014 at 2:51 PM, Khem Raj wrote:
> can you also figure out what is the licensing terms of these static .a
> archives please ?
> and make a note of it in commit message or somewhere
>
Looking at the main library header (tools/designer/src/uitools/quiloader.h)
it mentions the
On 2/16/14, 13:40, "João Henrique Ferreira de Freitas"
wrote:
>diffconfig() is a new task that makes a diff between the
>old and new config files and writes to the fragment.cfg result file.
>menuconfig() always copy the original config file, so the user
>doesn't need to copy it.
>
>Signed-off-by:
On 2/16/14, 13:40, "João Henrique Ferreira de Freitas"
wrote:
>Instead of using 'diff' command between two kernel config files,
>the task diffconfig does the job creating the file
>$WORKDIR/fragment.cfg that user should review and use.
>
>[YOCTO #3862]
>
>Signed-off-by: João Henrique Ferreira de
On Tue, Feb 18, 2014 at 9:49 AM, Diego Sueiro wrote:
> libQtUiTools.a and libQtUiToolsE.a needs to be installed on meta-toolchain-qt
> and meta-toolchain-qte respectively.
> Whitout this static library, compiling qt apps which needs uitools will fail.
can you also figure out what is the licensing
libQtUiTools.a and libQtUiToolsE.a needs to be installed on meta-toolchain-qt
and meta-toolchain-qte respectively.
Whitout this static library, compiling qt apps which needs uitools will fail.
qt4[-embedded]-staticdev is the package that contains this library and is the
only file in it.
Signed-of
On 2/17/14, 2:48 AM, Ming Liu wrote:
A flaw was found in the way rpm generating arbitrary tags, which leads to a
incorrect query result, this issue is introduced by a incompatible endianess
when the generating process is executed on different architectures.
This patch resolves it by taking the b
Khem,
On Tue, Feb 18, 2014 at 1:53 PM, Khem Raj wrote:
> hmmm you just want this 1 static library not all. So lets first
> package the .a into a package of its own and then include that instead
>
libQtUiTools[E].a is the only file in the package.
Regards,
--
*dS
Diego Sueiro
Administrador do
On Tue, Feb 18, 2014 at 1:49 PM, Diego Sueiro wrote:
> libQtUiTools[E].a needs to be installed on toolchain.
> qt4[-embedded]-staticdev is the package which provides this library.
>
> Signed-off-by: Diego Sueiro
Please change the short description to have the packagegroup inc file
on it. And ple
On Tue, Feb 18, 2014 at 8:49 AM, Diego Sueiro wrote:
> libQtUiTools[E].a needs to be installed on toolchain.
> qt4[-embedded]-staticdev is the package which provides this library.
>
> Signed-off-by: Diego Sueiro
> ---
> meta/recipes-qt/packagegroups/packagegroup-qt-toolchain-target.inc |1 +
libQtUiTools[E].a needs to be installed on toolchain.
qt4[-embedded]-staticdev is the package which provides this library.
Signed-off-by: Diego Sueiro
---
meta/recipes-qt/packagegroups/packagegroup-qt-toolchain-target.inc |1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-qt/pac
On Tue, Feb 18, 2014 at 7:56 AM, Diego Sueiro wrote:
>
> On Fri, Feb 14, 2014 at 9:58 PM, Diego Sueiro
> wrote:
>>>
>>> then package the needed static library in -dev package. Now its not
>>> recommended practice however sometimes
>>> exceptions are made but I would recommend to check first if it
On Fri, Feb 14, 2014 at 9:58 PM, Diego Sueiro wrote:
> then package the needed static library in -dev package. Now its not
>> recommended practice however sometimes
>> exceptions are made but I would recommend to check first if its an
>> oversight/bug in QT5 to not generate a .so
>> for the given
On Tue, Feb 18, 2014 at 05:42:28PM +0800, Hongxu Jia wrote:
> The _multilib_sanity_test installs multilib packages in a temporary
> root fs, and compare with the current image to figure out duplicated
> file that comes from different packages.
>
> While incremental image generation enabled and the
On Tue, Feb 18, 2014 at 05:42:27PM +0800, Hongxu Jia wrote:
> While incremental image generation enabled and the previous image existed,
> if BAD_RECOMMENDATIONS is changed, the operation on the existed image is
> complicated, so remove the existed image in this situation.
>
> The same with PACKAG
On Tue, Feb 18, 2014 at 4:08 AM, Jonathan Liu wrote:
> }
> IMAGE_CMD_cpio () {
> ${CPIO_TOUCH_INIT}
> - cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc
> >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
> + (cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc
> >${DEPLOY_DIR_IMA
On Tue, Feb 18, 2014 at 05:42:24PM +0800, Hongxu Jia wrote:
> While incremental image generation enabled, 'load_old_install_solution'
> is used to determine what we've got in the previous (existed) image and
> 'dump_install_solution' to determine what we need to install in the
> current image.
>
>
On Tue, Feb 18, 2014 at 12:48 AM, Richard Purdie
wrote:
> On Tue, 2014-02-18 at 10:37 +0200, Laurentiu Palcu wrote:
>> Hi Khem,
>>
>> On Mon, Feb 17, 2014 at 11:34:15AM -0800, Khem Raj wrote:
>> > We override LDCONFIGDEPEND to be empty string for uclibc
>> > however the current check is for it bei
The following dependencies were manually added in the image creation
code. However, in order to have an image dependency mechanism in place,
use a new variable, IMAGE_TYPEDEP, to declare that an image type depends
on another being already created.
The following dependencies are added by this commi
The image creation is done now in parallel. However, we didn't have any
dependency handling in place since the old code did that serial. This patchset
adds such dependency mechanism and all images types are split in groups,
according to dependency, which can be done in parallel.
The users, however
This commit adds a dependency mechanism to image creation, so that we can
split the images creation execution in groups, that can be executed in
parallel, having the dependencies satisfied in the same time. The old
code didn't need this since everything was serialized.
Technically, it adds a depen
* I've noticed errors like this in log.do_package:
DEBUG: Executing python function package_do_filedeps
sh: 1: Syntax error: "(" unexpected
sh: 1: Syntax error: "(" unexpected
DEBUG: Python function package_do_filedeps finished
which are actually caused by some filenames included in pac
Linux < 3.9 doesn't have the SO_REUSEPORT option so instead of failing to start
when built with >=3.9 kernel headers but booted on <3.9 kernels, continue as if
SO_REUSEPORT wasn't available.
Signed-off-by: Ross Burton
---
meta/recipes-connectivity/avahi/avahi.inc |1 +
.../avahi/fil
The working directory is changed in a subshell when executing cpio to
preserve the working directory for any subsequent commands. This is to
keep the working directory consistent when generating multiple image
types.
Signed-off-by: Jonathan Liu
---
meta/classes/image_types.bbclass | 2 +-
1 file
tested on qemux86, genericx86 for core-image-sato
and core-image-weston.
Signed-off-by: Valentin Popa
---
.../mesa/{mesa-gl_9.2.2.bb => mesa-gl_9.2.5.bb} | 0
meta/recipes-graphics/mesa/{mesa_9.2.2.bb => mesa_9.2.5.bb} | 12 ++--
meta/recipes-graphics/mesa/mesa_git.bb
* allow to explicitly disable x11 with --disable-x11, otherwise
do_configure fails for DISTROs without x11 in DISTRO_FEATURES:
| No package 'xcb-xkb' found
| configure:18763: $? = 1
| configure:18777: result: no
| No package 'xcb' found
| No package 'xcb-xkb' found
| configure:18793:
On 02/17/2014 08:38 PM, Saul Wold wrote:
On 02/12/2014 09:27 AM, Valentin Popa wrote:
tested on qemux86, genericx86 for core-image-sato
and core-image-weston.
Signed-off-by: Valentin Popa
---
.../mesa/{mesa-gl_9.2.2.bb => mesa-gl_9.2.5.bb}| 0
meta/recipes-graphics/mesa/{me
On Tue, 2014-02-18 at 20:11 +1100, Jonathan Liu wrote:
> On 18/02/2014 7:55 PM, Jonathan Liu wrote:
> > On 18/02/2014 7:41 PM, Richard Purdie wrote:
> >> On Mon, 2014-02-17 at 21:46 +1100, Jonathan Liu wrote:
> >>> The working directory needs to be changed before the image creation
> >>> commands i
While incremental image generation enabled, 'load_old_install_solution'
is used to determine what we've got in the previous (existed) image and
'dump_install_solution' to determine what we need to install in the
current image.
The 'backup_packaging_data' is used to back up the current opkg databas
While incremental image generation enabled, if previous image existed,
it restores the opkg database. Based on the previous image, it gets what
need to remove for the current and remove them.
The newly added and upgraded packages will be done since opkg install
invoked.
[YOCTO #1894]
Signed-off-
Test Cases
-
Case 1: Rebuild in place
1. Edit local.conf, enable multilib and ipk incremental image generation
...
46 MACHINE ?= "qemux86-64"
254 require conf/multilib.conf
255 MULTILIBS = "multilib:lib32"
256 DEFAULTTUNE_virtclass-multilib-lib32 = "x86
The _multilib_sanity_test installs multilib packages in a temporary
root fs, and compare with the current image to figure out duplicated
file that comes from different packages.
While incremental image generation enabled and the previous image
existed, there was a Multilib check error:
...
ERROR:
Let opkg_dir be configurable in handle_bad_recommendations,
so it could work on other root fs.
Invoke handle_bad_recommendations in dump_install_solution
which simulates package install on other root fs.
[YOCTO #1894]
Signed-off-by: Hongxu Jia
---
meta/lib/oe/package_manager.py | 18 +++
While incremental image generation enabled and the previous image existed,
if BAD_RECOMMENDATIONS is changed, the operation on the existed image is
complicated, so remove the existed image in this situation.
The same with PACKAGE_EXCLUDE and NO_RECOMMENDATIONS.
[YOCTO #1894]
Signed-off-by: Hongxu
On 18/02/2014 7:55 PM, Jonathan Liu wrote:
On 18/02/2014 7:41 PM, Richard Purdie wrote:
On Mon, 2014-02-17 at 21:46 +1100, Jonathan Liu wrote:
The working directory needs to be changed before the image creation
commands instead of afterwards.
Signed-off-by: Jonathan Liu
---
meta/lib/oe/imag
On 18/02/2014 7:41 PM, Richard Purdie wrote:
On Mon, 2014-02-17 at 21:46 +1100, Jonathan Liu wrote:
The working directory needs to be changed before the image creation
commands instead of afterwards.
Signed-off-by: Jonathan Liu
---
meta/lib/oe/image.py | 2 +-
1 file changed, 1 insertion(+)
On Tue, 2014-02-18 at 10:37 +0200, Laurentiu Palcu wrote:
> Hi Khem,
>
> On Mon, Feb 17, 2014 at 11:34:15AM -0800, Khem Raj wrote:
> > We override LDCONFIGDEPEND to be empty string for uclibc
> > however the current check is for it being None as a result
> > the function is still executed but ldco
On Mon, 2014-02-17 at 21:46 +1100, Jonathan Liu wrote:
> The working directory needs to be changed before the image creation
> commands instead of afterwards.
>
> Signed-off-by: Jonathan Liu
> ---
> meta/lib/oe/image.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/me
Hi Khem,
On Mon, Feb 17, 2014 at 11:34:15AM -0800, Khem Raj wrote:
> We override LDCONFIGDEPEND to be empty string for uclibc
> however the current check is for it being None as a result
> the function is still executed but ldconfig-native is not
> built as dependency for rootfs when building with
Hi,
Reverting commit
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3f49597225a58965124503ca5f3cc4011b04b3c0
Has the effect of fixing the build at do_rootfs stage.
Also, the commit in question looks strange to my eyes...
Appends should not be easily switchable without side-effects...
Us
56 matches
Mail list logo
