Re: [OE-core] [PATCH] Make static lib builds (DISABLE_STATIC) configurable from local.conf

> On May 5, 2016, at 9:38 PM, ryan woodsmall wrote: > > The idea is to build an as-close-to-stock-as-possible Poky (or another) > distro, but include support for static linking natively in the installed OS. In this case, you will call it poky but it will be far from

Re: [OE-core] [PATCH] Make static lib builds (DISABLE_STATIC) configurable from local.conf

The idea is to build an as-close-to-stock-as-possible Poky (or another) distro, but include support for static linking natively in the installed OS. Some of the bits I build/ship, including standalone static cross and native toolchains, target Poky as the stable reference source OS. The poky-tiny

Re: [OE-core] [PATCH] Make static lib builds (DISABLE_STATIC) configurable from local.conf

On May 5, 2016 8:59 PM, "ryan woodsmall" wrote: > > Static libraries are mostly usable in very small embedded systems. > The addiiton of musl-libc support allows very small "single binary" systems, > and static linking allows no shared lib deps on these types of builds. > >

[OE-core] [PATCH] Make static lib builds (DISABLE_STATIC) configurable from local.conf

Static libraries are mostly usable in very small embedded systems. The addiiton of musl-libc support allows very small "single binary" systems, and static linking allows no shared lib deps on these types of builds. Signed-off-by: ryan woodsmall ---

[OE-core] [PATCH v3] mdadm: add systemd support

Add mdadm.service to support systemd systems and add configuration file. Signed-off-by: Li Xin --- meta/recipes-extended/mdadm/files/mdadm.service | 13 + meta/recipes-extended/mdadm/mdadm_3.4.bb| 14 +- 2 files changed, 26

Re: [OE-core] How to force BitBake to track dependency to METADATA_REVISION?

On Thu, May 5, 2016 at 11:48 AM, Kucharczyk, Bartlomiej (Nokia - PL/Wroclaw) wrote: > I am trying to use METADATA_REVISION variable (defined in > metadata_scm.bbclass) in my recipe, but BitBake does not rebuild the task > when git revision of the repository

[OE-core] [master][PATCHv2 2/3] mkelfimage: obey LDFLAGS, sort out HOST_ flags

From: Christopher Larson We weren't consistent in the HOST_ (aka BUILD_) and non-HOST_ flags, so we were using BUILD_CPPFLAGS to compile target stuff, for example. Sort that out, and make sure we obey LDFLAGS. Signed-off-by: Christopher Larson

Re: [OE-core] [master][PATCH 3/3] pong-clock: obey CFLAGS, LDFLAGS

> On May 5, 2016, at 12:30 PM, Christopher Larson wrote: > > From: Christopher Larson > > Signed-off-by: Christopher Larson > --- > meta/recipes-graphics/pong-clock/pong-clock_1.0.bb | 2 +- > 1 file changed, 1 insertion(+),

[OE-core] How to force BitBake to track dependency to METADATA_REVISION?

Hello! I am trying to use METADATA_REVISION variable (defined in metadata_scm.bbclass) in my recipe, but BitBake does not rebuild the task when git revision of the repository changes. Setting [vardeps] does not help. I suspect this may be related to the fact that METADATA_REVISION is defined

Re: [OE-core] [master][PATCH 2/3] mkelfimage: obey LDFLAGS, sort out HOST_ flags

On Thu, May 5, 2016 at 2:54 PM, Khem Raj wrote: > On Thu, May 5, 2016 at 12:30 PM, Christopher Larson > wrote: > > From: Christopher Larson > > > > We weren't consistent in the HOST_ (aka BUILD_) and non-HOST_ flags, so > we > >

Re: [OE-core] [master][PATCH 2/3] mkelfimage: obey LDFLAGS, sort out HOST_ flags

On Thu, May 5, 2016 at 12:30 PM, Christopher Larson wrote: > From: Christopher Larson > > We weren't consistent in the HOST_ (aka BUILD_) and non-HOST_ flags, so we > were using BUILD_CPPFLAGS to compile target stuff, for example. Sort that out, > and

[OE-core] [master][PATCH 1/3] ruby: obey LDFLAGS for the link of libruby

From: Christopher Larson Signed-off-by: Christopher Larson --- meta/recipes-devtools/ruby/ruby.inc| 3 ++- ...0002-Obey-LDFLAGS-for-the-link-of-libruby.patch | 28 ++ 2 files changed, 30 insertions(+), 1

[OE-core] [master][PATCH 2/3] mkelfimage: obey LDFLAGS, sort out HOST_ flags

From: Christopher Larson We weren't consistent in the HOST_ (aka BUILD_) and non-HOST_ flags, so we were using BUILD_CPPFLAGS to compile target stuff, for example. Sort that out, and make sure we obey LDFLAGS. Signed-off-by: Christopher Larson

[OE-core] [master][PATCH 3/3] pong-clock: obey CFLAGS, LDFLAGS

From: Christopher Larson Signed-off-by: Christopher Larson --- meta/recipes-graphics/pong-clock/pong-clock_1.0.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/pong-clock/pong-clock_1.0.bb

[OE-core] [master][PATCH 0/3] Fix a few recipes to obey LDFLAGS

From: Christopher Larson The following changes since commit 1a0e56630c5c27d8899dd0979ae0b86bbe227881: utils.bbclass: note for deprecated base_contains (2016-04-29 07:53:58 +0100) are available in the git repository at: git://github.com/kergoth/openembedded-core

Re: [OE-core] npm class usage

Yes, this patch fix this problem. Thanks! On Thu, May 5, 2016 at 3:13 PM, Paul Eggleton wrote: > Right, this is the problem Brendan was describing - I believe I sent a > patch > to fix this already: > > http://patchwork.openembedded.org/patch/121039/ > > Cheers,

[OE-core] [PATCH] systemd: support systemd-boot as a stand-alone EFI bootloader

Dear maintainers, This change is the primary step to enable EFI bootloader in systemd project. It is actually the gummiboot which has been included in systemd project. The gummiboot referred in OE recipes is dead. The intention is to enable it as a stand-alone bootloader without bothering too

[OE-core] [PATCH] systemd: support systemd-boot as a stand-alone EFI bootloader

The "systemd-boot" is gummiboot now included into systemd project. The old gummiboot project supported in OE is dead. Our intention is to get a gummiboot-like EFI bootloader without much dependency on systemd and its features. This work is largely derived from the existing bbclass and recipes of

Re: [OE-core] npm class usage

Right, this is the problem Brendan was describing - I believe I sent a patch to fix this already: http://patchwork.openembedded.org/patch/121039/ Cheers, Paul On Thu, 05 May 2016 09:51:53 Fabio Berton wrote: > Hi Paul, > > When running: > recipetool create

Re: [OE-core] [PATCH] image_types: Ensure rootfs dependencies cover DEBUGFS

On 5/5/16 10:47 AM, Martin Jansa wrote: > On Tue, Apr 19, 2016 at 05:47:07PM +0100, Richard Purdie wrote: >> If you configure a bz2 debugfs, pbzip2-native currently isn't built. >> This patch makes sure the dependencies are added. I thought this had been fixed. IMAGE_FSTYPES_DEBUGFS -should- be

Re: [OE-core] [PATCH] image_types: Ensure rootfs dependencies cover DEBUGFS

On Tue, Apr 19, 2016 at 05:47:07PM +0100, Richard Purdie wrote: > If you configure a bz2 debugfs, pbzip2-native currently isn't built. > This patch makes sure the dependencies are added. BTW: I've tried to enable IMAGE_GEN_DEBUGFS for first time as described in manual: Build sysroot paths are

Re: [OE-core] npm class usage

Hi Paul, When running: recipetool create "npm://registry.npmjs.org;name=grunt-cli;version=1.1.0" I get this error: NOTE: Unpacking abbrev-1.0.7.tgz to /tmp/recipetool-tXXZDi/npmpkg/node_modules/nopt/node_modules/abbrev/ Traceback (most recent call last): File

[OE-core] an rpm question: can i get an update/install history relative to a baseline?

i'm sure there's a trivial answer to this, but here's what i'm after. say i use OE to build an image for a target board, rpm-based, load it and start running it -- imagine i say this is "version 1.0". as time goes by, i occasionally update existing packages or install new packages for extra

Re: [OE-core] npm class usage

On Thu, May 05, 2016 at 07:10:43PM +1200, Paul Eggleton wrote: > Note also that devtool add / recipetool create are capable of creating pretty > complete recipes for npm packages where licenses are also correctly set per > package (so you get them in the image manifest). I'd strongly recommend

Re: [OE-core] npm class usage

Note also that devtool add / recipetool create are capable of creating pretty complete recipes for npm packages where licenses are also correctly set per package (so you get them in the image manifest). I'd strongly recommend using it for this; if you have any issues please let me know.

[OE-core] [meta-oe][PATCH] Revert "xinput-calibrator: fix XDG launch"

This reverts commit 6464bcd67d10ab9967ac83c27c413c1014be707e. If another GUI xdg/autostart app runs, the xinput-calibrator may be hidden. And touching the GUI app causes the wrong input data for calibration. So it is not save to run xinput-calibrator in xdg/autostart. ---