[OE-core] [PATCH v2 0/1] multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIR

Realized that http://lists.openembedded.org/pipermail/openembedded-core/2016-December/130003.html change set never was merged, trying this again. (Rebased to handle '3c59b1b meta: remove True option to getVarFlag calls') The following changes since commit

[OE-core] [PATCH v2 1/1] multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIR

Due to the problem fixed in '56c677a multilib: Move redefinition of STAGING_DIR_KERNEL' STAGING_KERNEL_DIR must be redefined for lib32 in multilib.bbclass. However this redefinition expanded STAGING_KERNEL_DIR to an absolute path. This unconsciously added the TMPDIR path in the sstate object,

[OE-core] [PATCH] libnewt: 0.52.19 -> 0.52.20

Upgrade libnewt from 0.52.19 to 0.52.20. Signed-off-by: Huang Qiyu --- .../newt/{libnewt-python_0.52.19.bb => libnewt-python_0.52.20.bb} | 0 meta/recipes-extended/newt/{libnewt_0.52.19.bb => libnewt_0.52.20.bb} | 4 ++-- 2 files changed, 2 insertions(+), 2

[OE-core] ✗ patchtest: failure for libnl: 3.2.29 -> 3.3.0 (rev2)

== Series Details == Series: libnl: 3.2.29 -> 3.3.0 (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/6632/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the

[OE-core] [PATCH v2] libnl: 3.2.29 -> 3.3.0

1) Upgrade libnl from 3.2.29 to 3.3.0. 2) Delete patch "fix-pktloc_syntax_h-race.patch", since it is integrated upstream. 3) Add patch "musl-header-conflict.patch" to fix musl compile error. Signed-off-by: Huang Qiyu ---

[OE-core] [PATCH 2/2] recipetool: create: extract name of package from a repository

For git repositories in the absence of any other indicator, it's not an unreasonable assumption that the name of the repository is the name of the software package it contains, so use that as PN if we don't have anything else. Signed-off-by: Paul Eggleton ---

[OE-core] [PATCH 1/2] recipetool: create: skip values extracted from spec files containing macros

If a value we extract from a spec file contains an unexpanded macro (e.g. %{macroname}) then we should discard it since we're not seeing the actual value and we don't have an easy way of expanding it at the moment. This fixes for example getting %{name} as the recipe name when running the

[OE-core] [PATCH 0/2] Minor recipetool create fixes

The following changes since commit c59fa3bd71b42410bf032846ee8fdb6e6eb1b95c: python*-git: Upgrade to version 2.1.3 (2017-05-12 08:49:30 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/recipetool-fixes8

[OE-core] [PATCH 00/49] for morty next

Please consider these changes for the next Morty release 2.2.2. Clean AB build The following changes since commit 924e576b8930fd2268d85f0b151e5f68a3c2afce: bitbake: lib/bs4: Fix imports from html5lib >= 0.999/1.0b8 (2017-03-26 13:19:51 +0100) are available in the git repository at:

Re: [OE-core] [PATCH RFC] module.bbclass: Fix potential do_compile/do_make_scripts race condition

On Tuesday 15 December 2015 at 14:04:34 +, Paul Barker wrote: > > On Sun, 6 Dec 2015 11:26:33 + > > Paul Barker wrote: > > > > > I ran into a race condition building multiple external modules against a > > > 3.10.y > > > series kernel using the dylan branch