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.
Cheers,
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 us
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 func
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 "sources/openembedded-core/scripts
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 n
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 s
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 "npm://registry.npmjs.org;name=grunt-
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
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 much
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,
> Paul
>
> On Thu, 05 May 2016 0
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 more-ldflags-fixes
https:/
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
---
...HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.p
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
b/meta/recipes-graphics/pong-clock/pong-clock_1.0.bb
index 0e
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 deletion(-)
create mode 100644
meta/recipes-devtools
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 make sure we obey LDFLAGS.
>
may be you shou
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
> > were using BUILD_CPPFLAGS to compile target stuff, for example. So
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
t
> 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(+), 1 deletion(-)
>
> diff --git a/meta/recipes-graphics/pong-clock/pong
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
---
.../mkelfimage/mkelfimage/cross-compile.patch
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 changes.
> Setting [vardeps] does not h
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 insertions(+), 1 deletion(-)
create mod
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
---
meta/conf/distro/include/no-static-libs.inc | 4
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.
>
> Signed-off-by: ryan woo
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 d
> 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 poky. So its better
to eit
25 matches
Mail list logo
