[OE-core] [PATCH 20/27] devtool: add: move important "recipe created" message to the end

If we end up printing a message about the build directory being the same as the source, we should print that first and then print the message about the recipe file possibly needing to be edited to the end so that it has slightly more impact. Signed-off-by: Paul Eggleton

[OE-core] [PATCH 26/27] devtool: add basic means of running runqemu within the extensible SDK

We ship the runqemu script and if we build QEMU itself within the extensible SDK, then it would be nice to be able to run it. This is a very thin wrapper around runqemu, supplying the machine and image name so the user doesn't need to. (This subcommand is only available within the extensible SDK

[OE-core] [PATCH 22/27] devtool: build-image: tell user where to find output files

If the user is running "devtool build-image" within the extensible SDK then they probably won't know where to find the resulting output files, so we should tell them explicitly. Signed-off-by: Paul Eggleton --- scripts/lib/devtool/build-image.py | 14

Re: [OE-core] [RFC][PATCH] sstate: run recipe-provided hooks outside of ${B}

On Tue, Sep 22, 2015 at 03:11:53PM +0100, Ross Burton wrote: > To avoid races between the sstate tasks/hooks using ${B} as the cwd, and other > tasks such as cmake_do_configure which deletes and re-creates ${B}, ensure > that > all sstate hooks are run in the right directory, and run the

[OE-core] [PATCH] hand the TEMPLATECONF local over to setup-builddir

--- oe-init-build-env | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/oe-init-build-env b/oe-init-build-env index 6fee5f7..b7e2918 100755 --- a/oe-init-build-env +++ b/oe-init-build-env @@ -45,7 +45,7 @@ fi OEROOT=`readlink -f "$OEROOT"` export OEROOT .

Re: [OE-core] Error building gdk-pixbuf-native

On Tue, Sep 22, 2015 at 3:14 PM, Gary Thomas wrote: > On 2015-09-22 12:05, Otavio Salvador wrote: >> >> On Tue, Sep 22, 2015 at 12:28 PM, Gary Thomas wrote: >>> >>> When building gdk-pixbuf-native, I got this error: >>> | DEBUG: Staging files from >>> >>>

Re: [OE-core] [PATCH] hand the TEMPLATECONF local over to setup-builddir

On Tue, Sep 22, 2015 at 12:44 PM, Marcus Müller wrote: > --- > oe-init-build-env | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/oe-init-build-env b/oe-init-build-env > index 6fee5f7..b7e2918 100755 > --- a/oe-init-build-env > +++

Re: [OE-core] [PATCH] hand the TEMPLATECONF local over to setup-builddir

Hello, > If I understand correctly it allows a user prepared $TEMPLATECONF > directory > to be used by oe-setup-builddir. Indeed; the point is that oe-setup-builddir was definitely meant to be used with a TEMPLATECONF set by the user; in bash, the TEMPLATECONF local variable is automatically

[OE-core] [PATCH 1/1] oeqa/utils/dump: Add default commands and directory

From: Mariano Lopez Currently if qemu fails when running a selftest and tries to run some commands on the host it will fail because some variables required by the Dumper class do not exist because testimage was not included. This change adds a default parent

Re: [OE-core] Error building gdk-pixbuf-native

On 2015-09-22 12:38, Otavio Salvador wrote: On Tue, Sep 22, 2015 at 3:14 PM, Gary Thomas wrote: On 2015-09-22 12:05, Otavio Salvador wrote: On Tue, Sep 22, 2015 at 12:28 PM, Gary Thomas wrote: When building gdk-pixbuf-native, I got this error: |

[OE-core] [PATCH 03/27] classes/populate_sdk_ext: allow custom configuration for extensible SDK

Provide the ability to define a function containing extra configuration values to be added to the local.conf file that goes into the SDK. For example, this could be used to set up SSTATE_MIRRORS within the SDK. Signed-off-by: Paul Eggleton ---

[OE-core] [PATCH 02/27] classes/populate_sdk_ext: fix missing environment settings if running installer with sh

If you ran the extensible SDK installer file with sh (instead of bash), then the additional call to buildtools environment setup, extension of PATH to support running devtool, and setting of OE_SKIP_SDK_CHECK weren't being added to the end of the script. This is because apparently bash is happy to

[OE-core] [PATCH 04/27] classes/populate_sdk_ext: drop work-config.inc

This is not actually used for anything - I thought that we would need to use it within devtool to set global configuration, but we're able to do everything we need within the bbappends it creates, which also saves on parse time. If we're not going to use work-config.inc let's just drop it

[OE-core] [PATCH 21/27] devtool: build-image: fix recipe/package terminology

We build recipes and include packages into the image, adjust the terminology used in code and messages accordingly. Also fix a few typos. Signed-off-by: Paul Eggleton --- scripts/lib/devtool/build-image.py | 45 -- 1 file

[OE-core] [PATCH 23/27] devtool: build-image: improve image recipe handling

* Make image optional for the extensible SDK (auto-determine it based on the targets the SDK was built for) * Check that specified recipe is in fact an image Signed-off-by: Paul Eggleton --- scripts/lib/devtool/build-image.py | 26 +++--- 1

Re: [OE-core] Error building gdk-pixbuf-native

On Tue, Sep 22, 2015 at 12:28 PM, Gary Thomas wrote: > When building gdk-pixbuf-native, I got this error: > | DEBUG: Staging files from >

[OE-core] [PATCH 08/27] lib/oe/patch: fix for git am not cleaning up after itself

Unfortunately it appears that under certain circumstances, a failed git am followed by git am --abort won't clean up any changes the patch might have made - this was seen when running "devtool extract" on the unzip recipe; unzip-6.0_overflow3.diff has a malformed date as far as git am is concerned

[OE-core] [PATCH 16/27] devtool: show proper error when extracting source for recipes with disabled unpack task

If you try to use "devtool modify -x" or "devtool extract" on a recipe where do_unpack has been set as noexec (e.g. glibc-locale), then we get an error because the expected source wasn't ever unpacked. Do a check up front for noexec being set on do_unpack and error out with a reasonable message if

[OE-core] [PATCH 18/27] devtool: better handling for recipes that don't unpack source

Some recipes don't extract any source (for example, opkg-keyrings). We were producing a traceback in this case because we weren't checking if the directory existed. Signed-off-by: Paul Eggleton --- scripts/lib/devtool/standard.py | 8 +--- 1 file changed, 5

[OE-core] [PATCH 06/27] classes/externalsrc: scale back warning to a plain note

It turns out that there are folks out there who use externalsrc in normal builds and don't really need to be warned; additionally within the extensible SDK or when using devtool, it shouldn't be a warning situation. Thus, scale it back to a note (we can't use bb.note() here since that wouldn't

[OE-core] [PATCH 00/27] Fixes for devtool and the extensible SDK

Here is a set of fixes and improvements for devtool, the extensible SDK, and related code. Included are fixes for devtool add / recipetool create, fixes for devtool build-image, a couple of new subcommands for searching and running QEMU within the extensible SDK, a stress testing script for

[OE-core] [PATCH 19/27] devtool: add: set up fetched source as a git repository by default

If the fetched source isn't already a git repository, initialise it as one and then branch and tag, just as we do with "devtool modify". This makes it easier to make changes, commit them and then use the "devtool update-recipe" command to turn those commits into patches on the recipe.

[OE-core] [PATCH 25/27] devtool / recipetool: add handling for binary-only packages

Add a means of creating recipes for package files or archives that contain a directory structure to be installed verbatim, for example an rpm file. (We mostly just re-use bin_package here and skip some of the normal build system checks.) This support is available in "recipetool create" and

[OE-core] [PATCH 1/2] oeqa/utils/qemurunner.py: Fix HIGH CPU usage on LoggingThread

LoggingThread is used for receive console output from QEMU over TCP, so add filter to only wake poll on read events, also change the event mask variable name to be more descriptive. This fixes HIGH CPU consume caused by wake on ready to write events. Signed-off-by: Aníbal Limón

[OE-core] [PATCH 2/2] oeqa/utils/qemurunner.py: Remove duplicate message on LoggingThread start

The Starting logging thread message is also executed on run() inside LoggingThread class. Signed-off-by: Aníbal Limón --- meta/lib/oeqa/utils/qemurunner.py | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/lib/oeqa/utils/qemurunner.py

Re: [OE-core] Error building gdk-pixbuf-native

On 2015-09-22 12:05, Otavio Salvador wrote: On Tue, Sep 22, 2015 at 12:28 PM, Gary Thomas wrote: When building gdk-pixbuf-native, I got this error: | DEBUG: Staging files from

Re: [OE-core] [RFC][PATCH] sstate: run recipe-provided hooks outside of ${B}

On 22 September 2015 at 18:30, Martin Jansa wrote: > No error in first 126 iterations of: > for i in `seq -w 1 1000`; do bitbake -c cleansstate perf; bitbake -c build > -f perf 2>&1 | tee log.perf.$i; done > > so it's good improvement, thanks! > > Please get this merged

Re: [OE-core] Error building gdk-pixbuf-native

Hello Gary, On Tue, Sep 22, 2015 at 4:13 PM, Gary Thomas wrote: > It seems to be a host [contamination?] issue. I get this error > on a build host that does not have libharfbuzz.so installed. On > a build host which does, there is no error. > > Note that it is only for the

Re: [OE-core] [PATCH] hand the TEMPLATECONF local over to setup-builddir

On Tue, Sep 22, 2015 at 1:45 PM, Marcus Müller wrote: > Hello, > > If I understand correctly it allows a user prepared $TEMPLATECONF > > directory > > to be used by oe-setup-builddir. > Indeed; the point is that oe-setup-builddir was definitely meant to be > used with a

Re: [OE-core] [PATCH] hand the TEMPLATECONF local over to setup-builddir

On 2015-09-22 14:25, Lee Nipper wrote: On Tue, Sep 22, 2015 at 1:45 PM, Marcus Müller > wrote: Hello, > If I understand correctly it allows a user prepared $TEMPLATECONF > directory > to be used by oe-setup-builddir.

[OE-core] [PATCH 1/1] pseudo_1.7.4.bb: fix f*open()

The 0600 modes were coming from fopen/freopen/etc., because those don't specify a filesystem mode (just an access mode like "r" or "w"). Use 0666 & ~umask. (And then the PSEUDO_FS_MODE macro masks in the 0600 bits we want to be sure are present.) Signed-off-by: Peter Seebach

[OE-core] [PATCH 0/1] pseudo 1.7.4 (bug #8282)

This fix (based on work by Ross Burton) should fix up the one remaining case where pseudo was generating files with 0600 filesystem modes when they weren't intended. The tarball has been submitted but may not be online yet; however, you can probably use the pseudo_git recipe to try it out in the

Re: [OE-core] Error building gdk-pixbuf-native

> On Sep 22, 2015, at 4:28 PM, Otavio Salvador > wrote: > > On Tue, Sep 22, 2015 at 8:23 PM, Khem Raj wrote: >> its normal for build to use libraries from build host for native tools. If >> we want to abstract that >> from host deps then

Re: [OE-core] First run postinst broken

Hi Andreas Am Sonntag, den 20.09.2015, 22:30 +0200 schrieb Andreas Müller: > On Sun, Sep 20, 2015 at 8:56 PM, Andreas Müller > wrote: > > On Sun, Sep 20, 2015 at 12:30 PM, Andreas Müller > > wrote: > >> Hi, > >> > >> on images build

Re: [OE-core] [PATCH 01/27] lib/oe/recipeutils: properly split unexpanded variable values

On Tue, Sep 22, 2015 at 9:21 AM, Paul Eggleton < paul.eggle...@linux.intel.com> wrote: > Variables such as SRC_URI which are space-separated may also contain > Python expressions (${@...}) which themselves contain spaces that > shouldn't be split when splitting the value into items. In order to >

Re: [OE-core] Error building gdk-pixbuf-native

> On Sep 22, 2015, at 12:13 PM, Gary Thomas wrote: > > On 2015-09-22 12:38, Otavio Salvador wrote: >> On Tue, Sep 22, 2015 at 3:14 PM, Gary Thomas wrote: >>> On 2015-09-22 12:05, Otavio Salvador wrote: On Tue, Sep 22, 2015 at 12:28 PM, Gary

Re: [OE-core] [PATCH] lsb: add lsbinitscripts and util-linux rdepends

Alex Franco writes: > Building a base image such as core-image-minimal with lsb and then > attempting to source /lib/lsb/init-functions, then using the start > _daemon function (to start a daemon, such as syslogd) fails, since > /lib/lsb/init-functions use

Re: [OE-core] Error building gdk-pixbuf-native

On Tue, Sep 22, 2015 at 8:30 PM, Khem Raj wrote: > >> On Sep 22, 2015, at 4:28 PM, Otavio Salvador >> wrote: >> >> On Tue, Sep 22, 2015 at 8:23 PM, Khem Raj wrote: >>> its normal for build to use libraries from build

Re: [OE-core] Error building gdk-pixbuf-native

On Tue, Sep 22, 2015 at 8:23 PM, Khem Raj wrote: > its normal for build to use libraries from build host for native tools. If we > want to abstract that > from host deps then creating a dependency on package-native is the way The point is this seems to be not deterministic.

[OE-core] [PATCH 10/27] devtool: check that source tree still exists

Sometimes, particularly if you extracted the source to /tmp which is on tmpfs, the external source tree that is being pointed to may no longer exist when you come to run "devtool build" or "devtool update-recipe" etc. Make all of the commands that need to check for a recipe being in the workspace

[OE-core] [PATCH 12/27] devtool / lib/oe/recipeutils: ensure we can parse without bbappends

These functions ostensibly allowed parsing a recipe without bbappends but this clearly hadn't been tested because a variable was unassigned in both of them in that case. Signed-off-by: Paul Eggleton --- meta/lib/oe/recipeutils.py | 2 ++

[OE-core] [PATCH 14/27] recipetool: create: fix creating empty shell functions

The shell considers empty functions to be a syntax error, so for template shell functions that contain only comments (or no lines at all) then add a : to act as a no-op which avoids the syntax error. Signed-off-by: Paul Eggleton ---

[OE-core] [PATCH 07/27] classes/externalsrc: fix setting of deps varflag as a string

The value of the deps varflag for tasks is (unusually) expected to be a list object rather than a space-separated string, hence we cannot use appendVarFlag() here. This fixes a traceback when parsing the gcc recipe with externalsrc enabled, for example. Signed-off-by: Paul Eggleton

[OE-core] [PATCH 15/27] recipetool: create: fix handling of URIs containing #

The # character in a URI denotes a fragment; we don't care about this since it is never supposed to be sent to the server, so remove it from the URI before actually trying to fetch it or use it in SRC_URI within the recipe. (This has come up because download links on pypi.python.org seem to have

[OE-core] [PATCH 01/27] lib/oe/recipeutils: properly split unexpanded variable values

Variables such as SRC_URI which are space-separated may also contain Python expressions (${@...}) which themselves contain spaces that shouldn't be split when splitting the value into items. In order to ensure this we need to use a custom splitting function instead of just string.split(). This

[OE-core] [PATCH 09/27] scripts/contrib: add devtool stress tester

Add a script to run "devtool modify" followed by a build on every target recipe in the environment (with the option to skip/resume from/only include specific recipes). This takes far too long to run as an oe-selftest test but is still something that is useful to be able to run. There's also a

[OE-core] [PATCH 05/27] toolchain-shar-extract.sh: show progress when extracting SDK

Tar has supported a --checkpoint option since version 1.15.91, so it should be safe to use here to print dots showing that it's still doing something (technically it's not really progress unless you know how many dots it's going to print, which even it doesn't know at the start, but it's better

[OE-core] [PATCH 13/27] devtool: add: properly handle separate build directory

When we were adding a recipe for software that would typically be built in the same directory as the source, we were always using a separate build directory unless the user explicitly specified not to, leading to errors for software that doesn't expect to be built that way (such as Python modules

[OE-core] [PATCH 11/27] devtool: add: ensure --color=never turns off recipetool colour output

Signed-off-by: Paul Eggleton --- scripts/lib/devtool/standard.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py index 018ef2a..ec21b3c 100644 ---

[OE-core] [PATCH 17/27] devtool: fix extracting source for work-shared recipes

Recipes that use work-shared (such as libgcc) are capable of unpacking the source, but it doesn't necessarily unpack to ${WORKDIR}/${BP}. Use the last part of the actual S value instead which is more likely to work. Signed-off-by: Paul Eggleton ---

[OE-core] [PATCH 27/27] devtool: add search command

Adds a subcommand to search to find the target recipe name providing some file or capability. This is implemented by searching on recipe name, package name, description, package contents (file names), and runtime file provides. For example: $ devtool search libGL mesa $ devtool search X11

[OE-core] [PATCH 24/27] devtool: build-image: delete bbappend at end of build

Upon further reflection, it seems to me that this bbappend ought to just be deleted at the end of the build. This keeps things simple; you never have to remember to delete any files to get back to where you were before with the image. This means we can also drop the slightly awkward message

Re: [OE-core] [RFC][PATCHv2] cmake.bbclass, perf: don't re-create ${B}

On Mon, 2015-09-21 at 22:33 +0200, Martin Jansa wrote: > * otherwise there is race-condition between do_configure rm+mkdir and > bitbake trying to use it as CWD for do_populate_lic task, which > results in errors like this: > > NOTE: recipe perf-1.0-r9: task do_configure: Started > NOTE:

[OE-core] [PATCH] cwautomacros: cleanup buildpath in autogen.sh

From: Jackie Huang CWAUTOMACROSPREFIX is ${D}${prefix} which is used as the prefix of install dir and used to replace the path placeholder in script autogen.sh, the former is correct but not for the later, we can fix the Makefile to use two variables for this, but I

Re: [OE-core] How to put a correct dependency with regards to gcc?

> The idea is quite simple. Rather than having a copy of the gcc source for > each recipe variant > (-cross-initial, -cross, -crosssdk-initial, -crosssdk, -cross-canadian etc.) > we have a single copy of the source. >We tried an older shared stamp scheme which was fragile and prone to weird

Re: [OE-core] How to put a correct dependency with regards to gcc?

On Tue, 2015-09-22 at 11:03 +, Reshetova, Elena wrote: > > The idea is quite simple. Rather than having a copy of the gcc source for > > each recipe variant > > (-cross-initial, -cross, -crosssdk-initial, -crosssdk, -cross-canadian > > etc.) > > we have a single copy of the source. > >

Re: [OE-core] How to put a correct dependency with regards to gcc?

On Tue, 2015-09-22 at 11:03 +, Reshetova, Elena wrote: > > The idea is quite simple. Rather than having a copy of the gcc > > source for each recipe variant (-cross-initial, -cross, > > -crosssdk-initial, -crosssdk, -cross-canadian etc.) we have a single > > copy of the source. > > >We tried

Re: [OE-core] [PATCH] webkitgtk: add REQUIRED_DISTRO_FEATURES

> Remove x11 from DISTRO_FEATURES ("I'm building a product that doesn't need > or use X") and build webkitgtk. webkitgtk depends on libxt which depends > on libx11 which then refuses to build because you explicitly said you > didn't want X. > > We're adding required_distro_feature annotations as

[OE-core] [PATCH 0/1] gmp: Use __gnu_inline__ attribute in 4.2.1 with gcc 5

gmp 4.2.1 doesn't build with gcc5 without a small patch. This didn't come up in testing because Yoctos "non-gpl3" builder still doesn't seem to pick up the right version (YOCTO #8158). The following changes since commit 7b86c771c80d0759c2ca0e57c46c4c966f89c49e: bitbake: bitbake:

[OE-core] [PATCH 1/1] gmp: Use __gnu_inline__ attribute in 4.2.1 with gcc 5

gcc 5 defaults to C11 rules about "extern inline": this breaks any code that includes gmp.h header from gmp 4.2.1 with 'multiple definition' errors. Backport a fix from 6.0.0. disable-stdc patch is no longer required because of this. Signed-off-by: Jussi Kukkonen ---

Re: [OE-core] [RFC][PATCHv2] cmake.bbclass, perf: don't re-create ${B}

On 22 September 2015 at 09:10, Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > The longer stack trace is actually really helpful. I believe the code > here should inherit the working directory of the current task rather > than rely on the default of ${B} which bitbake assigns if

[OE-core] [PATCH] devtool: upgrade: use shutil.move instead of os.rename

Rename fails over filesystem boundaries. Signed-off-by: Markus Lehtonen --- scripts/lib/devtool/upgrade.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/lib/devtool/upgrade.py b/scripts/lib/devtool/upgrade.py index e74e795..18e010c

[OE-core] [PATCH] oeqa/selftest/archiver: Test that archiver filters on recipe name

[YOCTO #6929] this test validates the feature introduced in bug 6929 Signed-off-by: Daniel Istrate --- meta/lib/oeqa/selftest/archiver.py | 50 ++ 1 file changed, 50 insertions(+) create mode 100644

Re: [OE-core] [PATCH] rt-tests: bump to v0.94

On 22 September 2015 at 13:24, Josh Cartwright wrote: > All of the rt-tests patches that OE has been carrying have been > upstreamed or superceded by changes in the v0.94 release. > Sorry but you just missed the M3 deadline so this will have to wait until 2.0 is released and

[OE-core] [RFC][PATCH] sstate: run recipe-provided hooks outside of ${B}

To avoid races between the sstate tasks/hooks using ${B} as the cwd, and other tasks such as cmake_do_configure which deletes and re-creates ${B}, ensure that all sstate hooks are run in the right directory, and run the prefunc/postfunc in WORKDIR. Signed-off-by: Ross Burton

[OE-core] [PATCH] rt-tests: bump to v0.94

All of the rt-tests patches that OE has been carrying have been upstreamed or superceded by changes in the v0.94 release. Adjust SRC_URI to point to canonical upstream git repo, instead of a development tree. There was a notable change upstream that required slight reworking of the recipe.

Re: [OE-core] [PATCH] devtool: upgrade: use shutil.move instead of os.rename

On Tuesday 22 September 2015 14:24:04 Markus Lehtonen wrote: > Rename fails over filesystem boundaries. > > Signed-off-by: Markus Lehtonen > --- > scripts/lib/devtool/upgrade.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [OE-core] [PATCH] webkitgtk: add REQUIRED_DISTRO_FEATURES

On Tue, Sep 22, 2015 at 02:12:36PM +0300, alexander.kana...@linux.intel.com wrote: > > Remove x11 from DISTRO_FEATURES ("I'm building a product that doesn't need > > or use X") and build webkitgtk. webkitgtk depends on libxt which depends > > on libx11 which then refuses to build because you

Re: [OE-core] [PATCH 1/4] gtk+/cairo: enable x11 or directfb

On 22 September 2015 at 03:40, Robert Yang wrote: > If I understand correctly, how about we add a sanity check when do world > build? Either X11 or directfb should be in DISTRO_FEATURES. But gtk+ is > the only one which requires this, others can be built without both

Re: [OE-core] [PATCH] webkitgtk: add REQUIRED_DISTRO_FEATURES

>> Why can't the tools figure out which recipes should be excluded from >> builds without explicit annotations? > > See discussion around this change on ML and please don't remove stuff > just because you don't know/remember why it was added without at least > using "git blame" to read commit

Re: [OE-core] [PATCH] rt-tests: bump to v0.94

On Tue, Sep 22, 2015 at 03:08:54PM +0100, Burton, Ross wrote: > On 22 September 2015 at 13:24, Josh Cartwright wrote: > > All of the rt-tests patches that OE has been carrying have been > > upstreamed or superceded by changes in the v0.94 release. > > > > Sorry but you just missed

[OE-core] Error building gdk-pixbuf-native

When building gdk-pixbuf-native, I got this error: | DEBUG: Staging files from /home/local/rpi2_2015-03-05/tmp/work/i686-linux/gdk-pixbuf-native/2.30.8-r0/sysroot-destdir/home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux to /home/local/rpi2_2015-03-05/tmp/sysroots/i686-linux | DEBUG: Executing