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

[Khem Raj]

> 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 either define your own distro config based on poky, it also helps you when 
you ask
questions on mailing list. If you say I am using poky and make such changes you 
will miss to inform and people will not be able to reproduce your
issues.

> 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 
> definition with musl exists, but doesn't quite cover what I need, and some 
> externals are built outside of bitbake, the SDK and packaging system, so 
> static compilation limits required libraries and gives me some confidence 
> that I'll run on Poky.

I think poky-tiny policy to let  use static libs can be considered and I would 
encourage you to submit patch for poky tiny to let do that.

> 
> It's not a big deal at all to do a custom Poky-based distro so I can head 
> down that path, but thought this might be useful. The default remains sane, 
> setting "--disable-static", but provides a knob to turn if the old feature is 
> needed. Apologies if I missed the point here!
> 
> On Thu, May 5, 2016 at 11:09 PM, Khem Raj  > wrote:
> 
> 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 woodsmall  > >
> > ---
> >  meta/conf/distro/include/no-static-libs.inc | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/conf/distro/include/no-static-libs.inc 
> > b/meta/conf/distro/include/no-static-libs.inc
> > index 13a7918..83472d5 100644
> > --- a/meta/conf/distro/include/no-static-libs.inc
> > +++ b/meta/conf/distro/include/no-static-libs.inc
> > @@ -1,4 +1,4 @@
> > -DISABLE_STATIC = " --disable-static"
> > +DISABLE_STATIC ?= " --disable-static"
> >
> 
> I think this defeats the essense of this inc file. Not including this file in 
> your distro as a policy is what you want
> 
> >  # qemu aborts on unrecognised option
> >  DISABLE_STATIC_pn-qemu = ""
> > @@ -32,4 +32,4 @@ DISABLE_STATIC_pn-libusb1-native = ""
> >
> >  EXTRA_OECONF_append = "${DISABLE_STATIC}"
> >
> > -EXTRA_OECMAKE_append_pn-libical = "-DSHARED_ONLY=True"
> > +EXTRA_OECMAKE_append_pn-libical ?= "-DSHARED_ONLY=True"
> > --
> > 2.6.4
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org 
> > 
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core 
> > 
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[ryan woodsmall]

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 definition with musl exists, but doesn't quite cover what I need,
and some externals are built outside of bitbake, the SDK and packaging
system, so static compilation limits required libraries and gives me some
confidence that I'll run on Poky.

It's not a big deal at all to do a custom Poky-based distro so I can head
down that path, but thought this might be useful. The default remains sane,
setting "--disable-static", but provides a knob to turn if the old feature
is needed. Apologies if I missed the point here!

On Thu, May 5, 2016 at 11:09 PM, Khem Raj  wrote:

>
> 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 woodsmall 
> > ---
> >  meta/conf/distro/include/no-static-libs.inc | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/conf/distro/include/no-static-libs.inc
> b/meta/conf/distro/include/no-static-libs.inc
> > index 13a7918..83472d5 100644
> > --- a/meta/conf/distro/include/no-static-libs.inc
> > +++ b/meta/conf/distro/include/no-static-libs.inc
> > @@ -1,4 +1,4 @@
> > -DISABLE_STATIC = " --disable-static"
> > +DISABLE_STATIC ?= " --disable-static"
> >
>
> I think this defeats the essense of this inc file. Not including this file
> in your distro as a policy is what you want
>
> >  # qemu aborts on unrecognised option
> >  DISABLE_STATIC_pn-qemu = ""
> > @@ -32,4 +32,4 @@ DISABLE_STATIC_pn-libusb1-native = ""
> >
> >  EXTRA_OECONF_append = "${DISABLE_STATIC}"
> >
> > -EXTRA_OECMAKE_append_pn-libical = "-DSHARED_ONLY=True"
> > +EXTRA_OECMAKE_append_pn-libical ?= "-DSHARED_ONLY=True"
> > --
> > 2.6.4
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Khem Raj]

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 woodsmall 
> ---
>  meta/conf/distro/include/no-static-libs.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/conf/distro/include/no-static-libs.inc
b/meta/conf/distro/include/no-static-libs.inc
> index 13a7918..83472d5 100644
> --- a/meta/conf/distro/include/no-static-libs.inc
> +++ b/meta/conf/distro/include/no-static-libs.inc
> @@ -1,4 +1,4 @@
> -DISABLE_STATIC = " --disable-static"
> +DISABLE_STATIC ?= " --disable-static"
>

I think this defeats the essense of this inc file. Not including this file
in your distro as a policy is what you want

>  # qemu aborts on unrecognised option
>  DISABLE_STATIC_pn-qemu = ""
> @@ -32,4 +32,4 @@ DISABLE_STATIC_pn-libusb1-native = ""
>
>  EXTRA_OECONF_append = "${DISABLE_STATIC}"
>
> -EXTRA_OECMAKE_append_pn-libical = "-DSHARED_ONLY=True"
> +EXTRA_OECMAKE_append_pn-libical ?= "-DSHARED_ONLY=True"
> --
> 2.6.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[ryan woodsmall]

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 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/distro/include/no-static-libs.inc 
b/meta/conf/distro/include/no-static-libs.inc
index 13a7918..83472d5 100644
--- a/meta/conf/distro/include/no-static-libs.inc
+++ b/meta/conf/distro/include/no-static-libs.inc
@@ -1,4 +1,4 @@
-DISABLE_STATIC = " --disable-static"
+DISABLE_STATIC ?= " --disable-static"
 
 # qemu aborts on unrecognised option
 DISABLE_STATIC_pn-qemu = ""
@@ -32,4 +32,4 @@ DISABLE_STATIC_pn-libusb1-native = ""
 
 EXTRA_OECONF_append = "${DISABLE_STATIC}"
 
-EXTRA_OECMAKE_append_pn-libical = "-DSHARED_ONLY=True"
+EXTRA_OECMAKE_append_pn-libical ?= "-DSHARED_ONLY=True"
-- 
2.6.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Li Xin]

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 mode 100644 meta/recipes-extended/mdadm/files/mdadm.service

diff --git a/meta/recipes-extended/mdadm/files/mdadm.service 
b/meta/recipes-extended/mdadm/files/mdadm.service
new file mode 100644
index 000..3664ceb
--- /dev/null
+++ b/meta/recipes-extended/mdadm/files/mdadm.service
@@ -0,0 +1,13 @@
+[Unit]
+Description=Software RAID monitoring and management
+After=syslog.target
+ConditionPathExists=@sysconfdir@/mdadm.conf
+
+[Service]
+Type=forking
+PIDFile=@localstatedir@/run/mdadm/mdadm.pid
+EnvironmentFile=-@sysconfdir@/sysconfig/mdmonitor
+ExecStart=@basesbindir@/mdadm --monitor --scan -f 
--pid-file=@localstatedir@/run/mdadm/mdadm.pid
+
+[Install]
+WantedBy=multi-user.target
diff --git a/meta/recipes-extended/mdadm/mdadm_3.4.bb 
b/meta/recipes-extended/mdadm/mdadm_3.4.bb
index 142dfdd..2e7b155 100644
--- a/meta/recipes-extended/mdadm/mdadm_3.4.bb
+++ b/meta/recipes-extended/mdadm/mdadm_3.4.bb
@@ -19,12 +19,13 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \
file://0001-Fix-some-type-comparison-problems.patch \

file://0001-Fix-the-path-of-corosync-and-dlm-header-files-check.patch \
file://run-ptest \
+   file://mdadm.service \
  "
 SRC_URI[md5sum] = "04b8b21f637540350f8517c7e68d3c63"
 SRC_URI[sha256sum] = 
"27d0be4627d38a12ddcd1c1c3721d649d4e89e1093914497e22b57245cda8808"
 
 CFLAGS += "-fno-strict-aliasing"
-inherit autotools-brokensep
+inherit autotools-brokensep systemd
 
 EXTRA_OEMAKE = 'CHECK_RUN_DIR=0 CXFLAGS="${CFLAGS}"'
 # PPC64 and MIPS64 uses long long for u64 in the kernel, but powerpc's 
asm/types.h
@@ -42,8 +43,19 @@ do_compile() {
 do_install() {
export STRIP=""
autotools_do_install
+   install -d ${D}/${sysconfdir}/
+   install -m 644 ${S}/mdadm.conf-example ${D}${sysconfdir}/
+   install -d ${D}${systemd_unitdir}/system
+   install -m 644 ${WORKDIR}/mdadm.service ${D}${systemd_system_unitdir}
+   sed -i -e 's,@basesbindir@,${base_sbindir},g' \
+   -e 's,@localstatedir@,${localstatedir},g' \
+   -e 's,@sysconfdir@,${sysconfdir},g' \
+   ${D}${systemd_system_unitdir}/mdadm.service
+
 }
 
+SYSTEMD_SERVICE_${PN} = "mdadm.service"
+
 FILES_${PN} += "${base_libdir}/udev/rules.d/*.rules"
 
 inherit ptest
-- 
1.8.4.2



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Christopher Larson]

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 help.
>
> I suspect this may be related to the fact that METADATA_REVISION is
> defined this way:
> METADATA_REVISION ?= "${@base_detect_revision(d)}"
> And BitBake does not expand this to the proper value, thus does not see
> any difference.
>
> Does anyone have any suggestion how to tackle this issue, and force
> BitBake to properly track dependency to METADATA_REVISION value?
>
> My original task is:
> Package feeds/SDK installers are versioned (git metadata revision). I am
> trying to create an opkg.conf file which will contain such versioned
> package feeds URL in SDK installer. For build reproducibility, and user
> convenience.
>

Bitbake tracks unexpanded forms of variables, not expanded. So it's
literally storing '${@base_detect_revision(d)}" in the checksum, not the
actual revision.

METADATA_REVISION[vardepvalue] = "${METADATA_REVISION}" in your recipe will
do it.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Christopher Larson]

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  | 86 +++---
 meta/recipes-devtools/mkelfimage/mkelfimage_git.bb |  4 +-
 2 files changed, 63 insertions(+), 27 deletions(-)

diff --git a/meta/recipes-devtools/mkelfimage/mkelfimage/cross-compile.patch 
b/meta/recipes-devtools/mkelfimage/mkelfimage/cross-compile.patch
index 7692709..2ae4b61 100644
--- a/meta/recipes-devtools/mkelfimage/mkelfimage/cross-compile.patch
+++ b/meta/recipes-devtools/mkelfimage/mkelfimage/cross-compile.patch
@@ -1,13 +1,43 @@
-make the tool to be cross compilable.
+From dc2712119d6832e24a9b7bed9ed4ce5ae03ce0a3 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Sat, 14 Jul 2012 14:14:07 -0700
+Subject: [PATCH] mkelfimage: Fix cross build
+
+Make the tool to be cross compilable, by separating the variables for build
+tools from those for the target. Also modified to obey LDFLAGS.
 
 Signed-off-by: Khem Raj 
+Signed-off-by: Christopher Larson 
+
 Upstream-Status: Pending
 
-Index: mkelfImage/configure.ac
-===
 mkelfImage.orig/configure.ac   2012-07-14 14:04:48.964898667 -0700
-+++ mkelfImage/configure.ac2012-07-14 14:10:47.800916083 -0700
-@@ -70,6 +70,9 @@
+---
+ util/mkelfImage/Makefile.conf.in| 3 +++
+ util/mkelfImage/configure.ac| 7 +--
+ util/mkelfImage/linux-i386/Makefile | 2 +-
+ util/mkelfImage/linux-ia64/Makefile | 2 +-
+ util/mkelfImage/main/Makefile   | 4 ++--
+ 5 files changed, 12 insertions(+), 6 deletions(-)
+
+diff --git a/util/mkelfImage/Makefile.conf.in 
b/util/mkelfImage/Makefile.conf.in
+index 4645e44..dcb6cf2 100644
+--- a/util/mkelfImage/Makefile.conf.in
 b/util/mkelfImage/Makefile.conf.in
+@@ -17,6 +17,9 @@ DEFS=@DEFS@
+ LIBS=@LIBS@
+ HOST_CC=@HOST_CC@
+ HOST_CFLAGS=@HOST_CFLAGS@  $(DEFS)
++CC=@CC@
++CFLAGS=@CFLAGS@ $(DEFS)
++LDFLAGS=@LDFLAGS@
+ 
+ I386_CC =@I386_CC@
+ I386_LD =@I386_LD@
+diff --git a/util/mkelfImage/configure.ac b/util/mkelfImage/configure.ac
+index 652b952..0f2ac72 100644
+--- a/util/mkelfImage/configure.ac
 b/util/mkelfImage/configure.ac
+@@ -70,6 +70,9 @@ if test "with_default" != no ; then
AC_MSG_ERROR([cc not found])
fi
eval "${with_default}_CC='$CC'"
@@ -17,19 +47,22 @@ Index: mkelfImage/configure.ac
AC_PROG_CPP
if test "$CPP" = no; then
AC_MSG_ERROR([cpp not found])
-@@ -172,7 +175,6 @@
+@@ -172,8 +175,8 @@ fi
  
  dnl ---Output variables...
  
 -HOST_CC=$CC
- HOST_CFLAGS="$HOST_CFLAGS -O2 -Wall \$(HOST_CPPFLAGS)"
+-HOST_CFLAGS="$HOST_CFLAGS -O2 -Wall \$(HOST_CPPFLAGS)"
++CFLAGS="${CFLAGS:--O2} -Wall \$(CPPFLAGS)"
++HOST_CFLAGS="${HOST_CFLAGS:--O2} -Wall \$(HOST_CPPFLAGS)"
  
  dnl TODO: figure out how to set these appropriately for compilers other than 
gcc
-Index: mkelfImage/linux-i386/Makefile
-===
 mkelfImage.orig/linux-i386/Makefile2012-07-14 14:04:48.964898667 
-0700
-+++ mkelfImage/linux-i386/Makefile 2012-07-14 14:04:49.032898671 -0700
-@@ -4,7 +4,7 @@
+ I386_CFLAGS="$I386_CFLAGS -Os -ffreestanding -Wall -W -Wno-format 
\$(I386_CPPFLAGS)"
+diff --git a/util/mkelfImage/linux-i386/Makefile 
b/util/mkelfImage/linux-i386/Makefile
+index 51531d6..7e8aa3c 100644
+--- a/util/mkelfImage/linux-i386/Makefile
 b/util/mkelfImage/linux-i386/Makefile
+@@ -4,7 +4,7 @@ LI386_DEP=Makefile Makefile.conf $(LI386_DIR)/Makefile
  
  $(LI386_OBJ)/mkelf-linux-i386.o: $(LI386_DIR)/mkelf-linux-i386.c 
$(LI386_DIR)/convert.bin.c $(LI386_DEP)
$(MKDIR) -p $(@D)
@@ -38,11 +71,11 @@ Index: mkelfImage/linux-i386/Makefile
  
  
  ifdef I386_CC
-Index: mkelfImage/linux-ia64/Makefile
-===
 mkelfImage.orig/linux-ia64/Makefile2012-07-14 14:04:48.964898667 
-0700
-+++ mkelfImage/linux-ia64/Makefile 2012-07-14 14:04:49.032898671 -0700
-@@ -4,7 +4,7 @@
+diff --git a/util/mkelfImage/linux-ia64/Makefile 
b/util/mkelfImage/linux-ia64/Makefile
+index 38f5d8c..5df8870 100644
+--- a/util/mkelfImage/linux-ia64/Makefile
 b/util/mkelfImage/linux-ia64/Makefile
+@@ -4,7 +4,7 @@ LIA64_DEP=Makefile Makefile.conf $(LIA64_DIR)/Makefile
  
  $(LIA64_OBJ)/mkelf-linux-ia64.o: $(LIA64_DIR)/mkelf-linux-ia64.c 
$(LIA64_DIR)/convert.bin.c $(LIA64_DEP)
$(MKDIR) -p $(@D)
@@ -51,21 +84,24 @@ Index: mkelfImage/linux-ia64/Makefile
  
  ifdef IA64_CC
  
-Index: mkelfImage/main/Makefile
-===
 mkelfImage.orig/main/Makefile  2012-07-14 

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

[Khem Raj]

> 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-clock_1.0.bb 
> b/meta/recipes-graphics/pong-clock/pong-clock_1.0.bb
> index 0e1a792..6c3bcd8 100644
> --- a/meta/recipes-graphics/pong-clock/pong-clock_1.0.bb
> +++ b/meta/recipes-graphics/pong-clock/pong-clock_1.0.bb
> @@ -13,7 +13,7 @@ LIC_FILES_CHKSUM = 
> "file://pong-clock-no-flicker.c;beginline=1;endline=23;md5=dd
> S = "${WORKDIR}"
> 
> do_compile () {
> - ${CC} -o pong-clock pong-clock-no-flicker.c `pkg-config --cflags --libs 
> x11 xau xdmcp`
> + ${CC} ${CFLAGS} ${LDFLAGS} -o pong-clock pong-clock-no-flicker.c 
> `pkg-config --cflags --libs x11 xau xdmcl`

This could be improved if compile and link steps are done separately and you 
see the effect what I was making a point
from user point of view the toolchain is integrated.

$CC hello.c

should produce a a.out which can be executed.

> }
> 
> do_install () {
> --
> 2.8.0
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Kucharczyk, Bartlomiej (Nokia - PL/Wroclaw)]

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 
this way:
METADATA_REVISION ?= "${@base_detect_revision(d)}"
And BitBake does not expand this to the proper value, thus does not see any 
difference.

Does anyone have any suggestion how to tackle this issue, and force BitBake to 
properly track dependency to METADATA_REVISION value?

My original task is:
Package feeds/SDK installers are versioned (git metadata revision). I am trying 
to create an opkg.conf file which will contain such versioned package feeds URL 
in SDK installer. For build reproducibility, and user convenience.

Thanks in advance!
Bartek
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Christopher Larson]

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. Sort
> that out,
> > and make sure we obey LDFLAGS.
> >
>
> may be you should fold it into cross_compile patch ?


Probably a good idea, since this builds on that. I'll send a v2, thanks.
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Khem Raj]

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 should fold it into cross_compile patch ?

> Signed-off-by: Christopher Larson 
> ---
>  ...HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch | 73 
> ++
>  meta/recipes-devtools/mkelfimage/mkelfimage_git.bb |  5 +-
>  2 files changed, 76 insertions(+), 2 deletions(-)
>  create mode 100644 
> meta/recipes-devtools/mkelfimage/mkelfimage/0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch
>
> diff --git 
> a/meta/recipes-devtools/mkelfimage/mkelfimage/0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch
>  
> b/meta/recipes-devtools/mkelfimage/mkelfimage/0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch
> new file mode 100644
> index 000..8139edc
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/mkelfimage/mkelfimage/0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch
> @@ -0,0 +1,73 @@
> +Upstream-Status: Pending
> +
> +From ef21bb404cb5dbfbaa95b693c9705da2fd7e7472 Mon Sep 17 00:00:00 2001
> +From: Christopher Larson 
> +Date: Thu, 5 May 2016 11:49:24 -0700
> +Subject: Sort out HOST_ vs non-HOST_ flags, and obey LDFLAGS
> +
> +Signed-off-by: Christopher Larson 
> +---
> + Makefile.conf.in | 3 +++
> + configure.ac | 6 +-
> + main/Makefile| 4 ++--
> + 3 files changed, 10 insertions(+), 3 deletions(-)
> +
> +diff --git a/Makefile.conf.in b/Makefile.conf.in
> +index 4645e44..dcb6cf2 100644
> +--- a/Makefile.conf.in
>  b/Makefile.conf.in
> +@@ -17,6 +17,9 @@ DEFS=@DEFS@
> + LIBS=@LIBS@
> + HOST_CC=@HOST_CC@
> + HOST_CFLAGS=@HOST_CFLAGS@  $(DEFS)
> ++CC=@CC@
> ++CFLAGS=@CFLAGS@ $(DEFS)
> ++LDFLAGS=@LDFLAGS@
> +
> + I386_CC =@I386_CC@
> + I386_LD =@I386_LD@
> +diff --git a/configure.ac b/configure.ac
> +index d8bd7aa..2962a4a 100644
> +--- a/configure.ac
>  b/configure.ac
> +@@ -175,7 +175,8 @@ fi
> +
> + dnl ---Output variables...
> +
> +-HOST_CFLAGS="$HOST_CFLAGS -O2 -Wall \$(HOST_CPPFLAGS)"
> ++CFLAGS="${CFLAGS:--O2} -Wall \$(CPPFLAGS)"
> ++HOST_CFLAGS="${HOST_CFLAGS:--O2} -Wall \$(HOST_CPPFLAGS)"
> +
> + dnl TODO: figure out how to set these appropriately for compilers other 
> than gcc
> + I386_CFLAGS="$I386_CFLAGS -Os -ffreestanding -Wall -W -Wno-format 
> \$(I386_CPPFLAGS)"
> +@@ -189,6 +190,9 @@ IA64_LDFLAGS='-static --warn-multiple-gp --warn-common'
> +
> + AC_SUBST([HOST_CC])
> + AC_SUBST([HOST_CFLAGS])
> ++AC_SUBST([CC])
> ++AC_SUBST([CFLAGS])
> ++AC_SUBST([LDFLAGS])
> +
> + AC_SUBST([I386_CC])
> + AC_SUBST([I386_LD])
> +diff --git a/main/Makefile b/main/Makefile
> +index d9fb1d8..cd53613 100644
> +--- a/main/Makefile
>  b/main/Makefile
> +@@ -4,11 +4,11 @@ MKELF_OBJS=$(OBJDIR)/main/mkelfImage.o \
> +
> + $(OBJDIR)/sbin/mkelfImage: $(MKELF_OBJS) $(DEPS)
> +   $(MKDIR) -p $(@D)
> +-  $(CC) $(HOST_CFLAGS) $(MKELF_OBJS) -o $@ $(LIBS)
> ++  $(CC) $(CFLAGS) $(LDFLAGS) $(MKELF_OBJS) -o $@ $(LIBS)
> +
> + $(OBJDIR)/main/mkelfImage.o: main/mkelfImage.c include/mkelfImage.h $(DEPS)
> +   $(MKDIR) -p $(@D)
> +-  $(CC) $(HOST_CFLAGS) -c $< -o $@
> ++  $(CC) $(CFLAGS) -c $< -o $@
> +
> + $(OBJDIR)/man/man8/mkelfImage.8: main/mkelfImage.man
> +   $(MKDIR) -p $(@D)
> +--
> +2.8.0
> +
> diff --git a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb 
> b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
> index 92435cd..9fcccb4 100644
> --- a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
> +++ b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
> @@ -13,8 +13,9 @@ 
> http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=34fc4ab80b507739e258
>  DEPENDS += "zlib"
>
>  SRC_URI = "git://review.coreboot.org/p/coreboot;protocol=http \
> -   file://cross-compile.patch   \
> -  "
> +   file://cross-compile.patch \
> +   
> file://0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch \
> +   "
>  SRC_URI_append_class-native = " \
> file://fix-makefile-to-find-libz.patch   \
>  "
> --
> 2.8.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Christopher Larson]

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/ruby/ruby/0002-Obey-LDFLAGS-for-the-link-of-libruby.patch

diff --git a/meta/recipes-devtools/ruby/ruby.inc 
b/meta/recipes-devtools/ruby/ruby.inc
index 313e752..fde67e9 100644
--- a/meta/recipes-devtools/ruby/ruby.inc
+++ b/meta/recipes-devtools/ruby/ruby.inc
@@ -20,7 +20,8 @@ DEPENDS_class-native = "openssl-native libyaml-native"
 SHRT_VER = "${@oe.utils.trim_version("${PV}", 2)}"
 SRC_URI = "http://cache.ruby-lang.org/pub/ruby/${SHRT_VER}/ruby-${PV}.tar.gz \
file://extmk.patch \
-"
+   file://0002-Obey-LDFLAGS-for-the-link-of-libruby.patch \
+   "
 
 inherit autotools
 
diff --git 
a/meta/recipes-devtools/ruby/ruby/0002-Obey-LDFLAGS-for-the-link-of-libruby.patch
 
b/meta/recipes-devtools/ruby/ruby/0002-Obey-LDFLAGS-for-the-link-of-libruby.patch
new file mode 100644
index 000..b0114ba
--- /dev/null
+++ 
b/meta/recipes-devtools/ruby/ruby/0002-Obey-LDFLAGS-for-the-link-of-libruby.patch
@@ -0,0 +1,28 @@
+Upstream-Status: Pending
+
+From 306e95a9818d39d3349075aac9609e062b0f19ce Mon Sep 17 00:00:00 2001
+From: Christopher Larson 
+Date: Thu, 5 May 2016 10:59:07 -0700
+Subject: [PATCH 2/2] Obey LDFLAGS for the link of libruby
+
+Signed-off-by: Christopher Larson 
+---
+ Makefile.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index 7da2488..5b4aea1 100644
+--- a/Makefile.in
 b/Makefile.in
+@@ -75,7 +75,7 @@ EXTLIBS =
+ LIBS = @LIBS@ $(EXTLIBS)
+ MISSING = @LIBOBJS@ @ALLOCA@
+ LDSHARED = @LIBRUBY_LDSHARED@
+-DLDFLAGS = @LIBRUBY_DLDFLAGS@ $(XLDFLAGS) $(ARCH_FLAG)
++DLDFLAGS = @LIBRUBY_DLDFLAGS@ @LDFLAGS@ $(XLDFLAGS) $(ARCH_FLAG)
+ SOLIBS = @SOLIBS@
+ MAINLIBS = @MAINLIBS@
+ ARCHMINIOBJS = @MINIOBJS@
+-- 
+2.8.0
+
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Christopher Larson]

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.patch | 73 ++
 meta/recipes-devtools/mkelfimage/mkelfimage_git.bb |  5 +-
 2 files changed, 76 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-devtools/mkelfimage/mkelfimage/0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch

diff --git 
a/meta/recipes-devtools/mkelfimage/mkelfimage/0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch
 
b/meta/recipes-devtools/mkelfimage/mkelfimage/0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch
new file mode 100644
index 000..8139edc
--- /dev/null
+++ 
b/meta/recipes-devtools/mkelfimage/mkelfimage/0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch
@@ -0,0 +1,73 @@
+Upstream-Status: Pending
+
+From ef21bb404cb5dbfbaa95b693c9705da2fd7e7472 Mon Sep 17 00:00:00 2001
+From: Christopher Larson 
+Date: Thu, 5 May 2016 11:49:24 -0700
+Subject: Sort out HOST_ vs non-HOST_ flags, and obey LDFLAGS
+
+Signed-off-by: Christopher Larson 
+---
+ Makefile.conf.in | 3 +++
+ configure.ac | 6 +-
+ main/Makefile| 4 ++--
+ 3 files changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/Makefile.conf.in b/Makefile.conf.in
+index 4645e44..dcb6cf2 100644
+--- a/Makefile.conf.in
 b/Makefile.conf.in
+@@ -17,6 +17,9 @@ DEFS=@DEFS@
+ LIBS=@LIBS@
+ HOST_CC=@HOST_CC@
+ HOST_CFLAGS=@HOST_CFLAGS@  $(DEFS)
++CC=@CC@
++CFLAGS=@CFLAGS@ $(DEFS)
++LDFLAGS=@LDFLAGS@
+ 
+ I386_CC =@I386_CC@
+ I386_LD =@I386_LD@
+diff --git a/configure.ac b/configure.ac
+index d8bd7aa..2962a4a 100644
+--- a/configure.ac
 b/configure.ac
+@@ -175,7 +175,8 @@ fi
+ 
+ dnl ---Output variables...
+ 
+-HOST_CFLAGS="$HOST_CFLAGS -O2 -Wall \$(HOST_CPPFLAGS)"
++CFLAGS="${CFLAGS:--O2} -Wall \$(CPPFLAGS)"
++HOST_CFLAGS="${HOST_CFLAGS:--O2} -Wall \$(HOST_CPPFLAGS)"
+ 
+ dnl TODO: figure out how to set these appropriately for compilers other than 
gcc
+ I386_CFLAGS="$I386_CFLAGS -Os -ffreestanding -Wall -W -Wno-format 
\$(I386_CPPFLAGS)"
+@@ -189,6 +190,9 @@ IA64_LDFLAGS='-static --warn-multiple-gp --warn-common'
+ 
+ AC_SUBST([HOST_CC])
+ AC_SUBST([HOST_CFLAGS])
++AC_SUBST([CC])
++AC_SUBST([CFLAGS])
++AC_SUBST([LDFLAGS])
+ 
+ AC_SUBST([I386_CC])
+ AC_SUBST([I386_LD])
+diff --git a/main/Makefile b/main/Makefile
+index d9fb1d8..cd53613 100644
+--- a/main/Makefile
 b/main/Makefile
+@@ -4,11 +4,11 @@ MKELF_OBJS=$(OBJDIR)/main/mkelfImage.o \
+ 
+ $(OBJDIR)/sbin/mkelfImage: $(MKELF_OBJS) $(DEPS)
+   $(MKDIR) -p $(@D)
+-  $(CC) $(HOST_CFLAGS) $(MKELF_OBJS) -o $@ $(LIBS)
++  $(CC) $(CFLAGS) $(LDFLAGS) $(MKELF_OBJS) -o $@ $(LIBS)
+ 
+ $(OBJDIR)/main/mkelfImage.o: main/mkelfImage.c include/mkelfImage.h $(DEPS)
+   $(MKDIR) -p $(@D)
+-  $(CC) $(HOST_CFLAGS) -c $< -o $@
++  $(CC) $(CFLAGS) -c $< -o $@
+ 
+ $(OBJDIR)/man/man8/mkelfImage.8: main/mkelfImage.man
+   $(MKDIR) -p $(@D)
+-- 
+2.8.0
+
diff --git a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb 
b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
index 92435cd..9fcccb4 100644
--- a/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
+++ b/meta/recipes-devtools/mkelfimage/mkelfimage_git.bb
@@ -13,8 +13,9 @@ 
http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=34fc4ab80b507739e258
 DEPENDS += "zlib"
 
 SRC_URI = "git://review.coreboot.org/p/coreboot;protocol=http \
-   file://cross-compile.patch   \
-  "
+   file://cross-compile.patch \
+   
file://0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch \
+   "
 SRC_URI_append_class-native = " \
file://fix-makefile-to-find-libz.patch   \
 "
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Christopher Larson]

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 0e1a792..6c3bcd8 100644
--- a/meta/recipes-graphics/pong-clock/pong-clock_1.0.bb
+++ b/meta/recipes-graphics/pong-clock/pong-clock_1.0.bb
@@ -13,7 +13,7 @@ LIC_FILES_CHKSUM = 
"file://pong-clock-no-flicker.c;beginline=1;endline=23;md5=dd
 S = "${WORKDIR}"
 
 do_compile () {
-   ${CC} -o pong-clock pong-clock-no-flicker.c `pkg-config --cflags --libs 
x11 xau xdmcp`
+   ${CC} ${CFLAGS} ${LDFLAGS} -o pong-clock pong-clock-no-flicker.c 
`pkg-config --cflags --libs x11 xau xdmcp`
 }
 
 do_install () {
-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Christopher Larson]

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://github.com/kergoth/openembedded-core/tree/more-ldflags-fixes

Christopher Larson (3):
  ruby: obey LDFLAGS for the link of libruby
  mkelfimage: obey LDFLAGS, sort out HOST_ flags
  pong-clock: obey CFLAGS, LDFLAGS

 ...HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch | 73 ++
 meta/recipes-devtools/mkelfimage/mkelfimage_git.bb |  5 +-
 meta/recipes-devtools/ruby/ruby.inc|  3 +-
 ...0002-Obey-LDFLAGS-for-the-link-of-libruby.patch | 28 +
 meta/recipes-graphics/pong-clock/pong-clock_1.0.bb |  2 +-
 5 files changed, 107 insertions(+), 4 deletions(-)
 create mode 100644 
meta/recipes-devtools/mkelfimage/mkelfimage/0002-Sort-out-HOST_-vs-non-HOST_-flags-and-obey-LDFLAGS.patch
 create mode 100644 
meta/recipes-devtools/ruby/ruby/0002-Obey-LDFLAGS-for-the-link-of-libruby.patch

-- 
2.8.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] npm class usage

[Fabio Berton]

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 09:51:53 Fabio Berton wrote:
> > 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/recipetool", line 116, in
> 
> > ret = main()
> >   File "sources/openembedded-core/scripts/recipetool", line 107, in main
> > ret = args.func(args)
> >   File "sources/openembedded-core/scripts/lib/recipetool/create.py", line
> > 561, in create_recipe
> > handler.process(srctree_use, classes, lines_before, lines_after,
> > handled, extravalues)
> >   File "sources/openembedded-core/scripts/lib/recipetool/create_npm.py",
> > line 133, in process
> > license = self._handle_license(pdata)
> >   File "sources/openembedded-core/scripts/lib/recipetool/create_npm.py",
> > line 44, in _handle_license
> > if 'license' in data:
> > TypeError: argument of type 'NoneType' is not iterable
> >
> >
> > On Thu, May 5, 2016 at 7:57 AM, Brendan Le Foll <
> brendan.le.f...@intel.com>
> >
> > wrote:
> > > 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
> > >
> > > using
> > >
> > > > it for this; if you have any issues please let me know.
> > >
> > > So actually it errors in this case because of a test package in the
> > > resolve module (this shows the issue quicker/easier) see:
> > > $ recipetool create "npm://registry.npmjs.org
> ;name=resolve;version=1.1.7"
> > >
> > > There's a node_modules dir inside test/ it gets taken as if npm had
> > > resolved/download a dep when in fact it hasn't. Since node packages
> > > can and do ship their own deps with them sometimes, I think the only
> > > fix would be in npm_split_package_dirs to walk 1 level of the ${PN}
> > > dir only so that:
> > >
> > > ${PN}/node_modules -> taken
> > > ${PN}/tests/node_modules -> ignored
> > > ${PN}/node_modules/${PN}/node_modules -> taken
> > >
> > > Cheers,
> > > Brendan
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Jianxun Zhang]

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 of the existing systemd. Usage is same as other supported EFI
bootloaders.

Considering there are many bits working with systemd in Yocto and we cannot
cover every corner in test prior to this submission, I suggest you have a
close look on the patch before merging it.

If no regerssion or significant bugs show in field, we will provide patches
to replace gummiboot with systemd-boot by:

() Add new oetest for systemd-boot
() Update documents for replacement
() Purge gummiboot in OE (may provide a dev-friendly message in gummiboot stuff
as a reminder in build)

Thanks

Jianxun Zhang (1):
  systemd: support systemd-boot as a stand-alone EFI bootloader

 meta/classes/systemd-boot.bbclass | 124 ++
 meta/recipes-bsp/systemd-boot/systemd-boot.bb |  35 
 meta/recipes-core/systemd/systemd.inc |  25 ++
 meta/recipes-core/systemd/systemd_229.bb  |  26 +-
 4 files changed, 186 insertions(+), 24 deletions(-)
 create mode 100644 meta/classes/systemd-boot.bbclass
 create mode 100644 meta/recipes-bsp/systemd-boot/systemd-boot.bb
 create mode 100644 meta/recipes-core/systemd/systemd.inc

-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Jianxun Zhang]

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 gummiboot and systemd.
(commit tip: ee25d0e3987d7732a2e46e1640693b4cf419a9fc)

Please refer to the history up to the tip for authorship and
credit information for the original works.

To enable the systemd-boot in build, add this line
EFI_PROVIDER = "systemd-boot" in your machine conf file.

Signed-off-by: Jianxun Zhang 
---
 meta/classes/systemd-boot.bbclass | 124 ++
 meta/recipes-bsp/systemd-boot/systemd-boot.bb |  35 
 meta/recipes-core/systemd/systemd.inc |  25 ++
 meta/recipes-core/systemd/systemd_229.bb  |  26 +-
 4 files changed, 186 insertions(+), 24 deletions(-)
 create mode 100644 meta/classes/systemd-boot.bbclass
 create mode 100644 meta/recipes-bsp/systemd-boot/systemd-boot.bb
 create mode 100644 meta/recipes-core/systemd/systemd.inc

diff --git a/meta/classes/systemd-boot.bbclass 
b/meta/classes/systemd-boot.bbclass
new file mode 100644
index 000..9e9398a
--- /dev/null
+++ b/meta/classes/systemd-boot.bbclass
@@ -0,0 +1,124 @@
+# Copyright (C) 2016 Intel Corporation
+#
+# Released under the MIT license (see COPYING.MIT)
+
+# systemd-boot.bbclass - The "systemd-boot" is essentially the gummiboot 
merged into systemd.
+#The original standalone gummiboot project is dead 
without any more
+#maintenance. As a start point, we replace all 
gummitboot occurrences
+#with systemd-boot in gummiboot.bbclass to have a base 
version of this
+#systemd-boot.bbclass.
+#
+# Set EFI_PROVIDER = "systemd-boot" to use systemd-boot on your live images 
instead of grub-efi
+# (images built by image-live.bbclass or image-vm.bbclass)
+
+do_bootimg[depends] += "${MLPREFIX}systemd-boot:do_deploy"
+do_bootdirectdisk[depends] += "${MLPREFIX}systemd-boot:do_deploy"
+
+EFIDIR = "/EFI/BOOT"
+
+SYSTEMD_BOOT_CFG ?= "${S}/loader.conf"
+SYSTEMD_BOOT_ENTRIES ?= ""
+SYSTEMD_BOOT_TIMEOUT ?= "10"
+
+# Need UUID utility code.
+inherit fs-uuid
+
+efi_populate() {
+DEST=$1
+
+EFI_IMAGE="systemd-bootia32.efi"
+DEST_EFI_IMAGE="bootia32.efi"
+if [ "${TARGET_ARCH}" = "x86_64" ]; then
+EFI_IMAGE="systemd-bootx64.efi"
+DEST_EFI_IMAGE="bootx64.efi"
+fi
+
+install -d ${DEST}${EFIDIR}
+# systemd-boot requires these paths for configuration files
+# they are not customizable so no point in new vars
+install -d ${DEST}/loader
+install -d ${DEST}/loader/entries
+install -m 0644 ${DEPLOY_DIR_IMAGE}/${EFI_IMAGE} 
${DEST}${EFIDIR}/${DEST_EFI_IMAGE}
+install -m 0644 ${SYSTEMD_BOOT_CFG} ${DEST}/loader/loader.conf
+for i in ${SYSTEMD_BOOT_ENTRIES}; do
+install -m 0644 ${i} ${DEST}/loader/entries
+done
+}
+
+efi_iso_populate() {
+iso_dir=$1
+efi_populate $iso_dir
+mkdir -p ${EFIIMGDIR}/${EFIDIR}
+cp $iso_dir/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
+cp $iso_dir/vmlinuz ${EFIIMGDIR}
+EFIPATH=$(echo "${EFIDIR}" | sed 's/\//\\/g')
+echo "fs0:${EFIPATH}\\${DEST_EFI_IMAGE}" > ${EFIIMGDIR}/startup.nsh
+if [ -f "$iso_dir/initrd" ] ; then
+cp $iso_dir/initrd ${EFIIMGDIR}
+fi
+}
+
+efi_hddimg_populate() {
+efi_populate $1
+}
+
+python build_efi_cfg() {
+s = d.getVar("S", True)
+labels = d.getVar('LABELS', True)
+if not labels:
+bb.debug(1, "LABELS not defined, nothing to do")
+return
+
+if labels == []:
+bb.debug(1, "No labels, nothing to do")
+return
+
+cfile = d.getVar('SYSTEMD_BOOT_CFG', True)
+try:
+ cfgfile = open(cfile, 'w')
+except OSError:
+raise bb.build.funcFailed('Unable to open %s' % (cfile))
+
+cfgfile.write('# Automatically created by OE\n')
+cfgfile.write('default %s\n' % (labels.split()[0]))
+timeout = d.getVar('SYSTEMD_BOOT_TIMEOUT', True)
+if timeout:
+cfgfile.write('timeout %s\n' % timeout)
+else:
+cfgfile.write('timeout 10\n')
+cfgfile.close()
+
+for label in labels.split():
+localdata = d.createCopy()
+
+overrides = localdata.getVar('OVERRIDES', True)
+if not overrides:
+raise bb.build.FuncFailed('OVERRIDES not defined')
+
+entryfile = "%s/%s.conf" % (s, label)
+d.appendVar("SYSTEMD_BOOT_ENTRIES", " " + entryfile)
+try:
+entrycfg = open(entryfile, "w")
+except OSError:
+raise bb.build.funcFailed('Unable to open %s' % (entryfile))
+localdata.setVar('OVERRIDES', label + ':' + overrides)
+

Re: [OE-core] npm class usage

[Paul Eggleton]

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-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/recipetool", line 116, in 
> ret = main()
>   File "sources/openembedded-core/scripts/recipetool", line 107, in main
> ret = args.func(args)
>   File "sources/openembedded-core/scripts/lib/recipetool/create.py", line
> 561, in create_recipe
> handler.process(srctree_use, classes, lines_before, lines_after,
> handled, extravalues)
>   File "sources/openembedded-core/scripts/lib/recipetool/create_npm.py",
> line 133, in process
> license = self._handle_license(pdata)
>   File "sources/openembedded-core/scripts/lib/recipetool/create_npm.py",
> line 44, in _handle_license
> if 'license' in data:
> TypeError: argument of type 'NoneType' is not iterable
> 
> 
> On Thu, May 5, 2016 at 7:57 AM, Brendan Le Foll 
> 
> wrote:
> > 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
> > 
> > using
> > 
> > > it for this; if you have any issues please let me know.
> > 
> > So actually it errors in this case because of a test package in the
> > resolve module (this shows the issue quicker/easier) see:
> > $ recipetool create "npm://registry.npmjs.org;name=resolve;version=1.1.7"
> > 
> > There's a node_modules dir inside test/ it gets taken as if npm had
> > resolved/download a dep when in fact it hasn't. Since node packages
> > can and do ship their own deps with them sometimes, I think the only
> > fix would be in npm_split_package_dirs to walk 1 level of the ${PN}
> > dir only so that:
> > 
> > ${PN}/node_modules -> taken
> > ${PN}/tests/node_modules -> ignored
> > ${PN}/node_modules/${PN}/node_modules -> taken
> > 
> > Cheers,
> > Brendan

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Mark Hatle]

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 set to default to:

IMAGE_FSTYPES_DEBUGFS ?= "${IMAGE_FSTYPES}"

I usually set it to "tar.gz" myself.

So this is a bug, and we definitely need to fix it.  :P

--Mark

> BTW: I've tried to enable IMAGE_GEN_DEBUGFS for first time as described in 
> manual:
>   Build sysroot paths are now removed from debug symbol files. Removing these 
> paths means that remote GDB using an unstripped build system sysroot will no 
> longer work (although this was never documented to work). The supported 
> method to accomplish something similar is to set IMAGE_GEN_DEBUGFS to "1", 
> which will generate a companion debug image containing unstripped binaries 
> and associated debug sources alongside the image.
> 
> and it fails with ugly exception, because IMAGE_FSTYPES_DEBUGFS isn't set by 
> default.
> 
> It should either be mentioned in the manual or there should be some sane 
> default for it.
> 
> meta/conf/local.conf.sample.extended shows example how to set it next to 
> IMAGE_GEN_DEBUGFS,
> people reading this sample may notice it, but the comment also says:
>   If IMAGE_FSTYPES_DEBUGFS is not defined, it defaults to IMAGE_FSTYPES.
> which isn't true for some reason in my setup, looking at the code I don't see 
> where it is supposed
> to default to IMAGE_FSTYPES
> 
> if d.getVar('IMAGE_GEN_DEBUGFS', True) == "1":
> debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS', True).split()
> for t in debugfs_fstypes:
> alltypes.append("debugfs_" + t)
> 
> Maybe the author meant that IMAGE_FSTYPES variable is set to 
> IMAGE_FSTYPES_DEBUGFS
> only when IMAGE_FSTYPES_DEBUGFS is set, but that still leaves that split()
> causing parse failure.
> 
> debugfs_image_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS', True)
> if debugfs_image_fstypes:
> d.setVar('IMAGE_FSTYPES', debugfs_image_fstypes)
> 
> ERROR: 
> /OE/build/wpb/webos-ports/meta-webos-ports/meta-luneos/recipes-core/images/luneos-image.bb:
>  Error executing a python function in :
> 
> The stack trace of python calls that resulted in this exception/failure was:
> File: '', lineno: 14, function: 
>  
> 0010:__anon_38__OE_build_wpb_webos_ports_openembedded_core_meta_classes_rootfs_ipk_bbclass(d)
>  
> 0011:__anon_113__OE_build_wpb_webos_ports_openembedded_core_meta_classes_image_bbclass(d)
>  
> 0012:__anon_176__OE_build_wpb_webos_ports_openembedded_core_meta_classes_image_bbclass(d)
>  
> 0013:__anon_146__OE_build_wpb_webos_ports_openembedded_core_meta_classes_siteinfo_bbclass(d)
>  *** 
> 0014:__anon_439__OE_build_wpb_webos_ports_openembedded_core_meta_classes_image_bbclass(d)
> File: 
> '/OE/build/wpb/webos-ports/openembedded-core/meta/classes/image.bbclass', 
> lineno: 322, function: 
> __anon_439__OE_build_wpb_webos_ports_openembedded_core_meta_classes_image_bbclass
>  0318:typedeps = {}
>  0319:
>  0320:if d.getVar('IMAGE_GEN_DEBUGFS', True) == "1":
>  0321:debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS', 
> True).split()
>  *** 0322:for t in debugfs_fstypes: 
>  0323:alltypes.append("debugfs_" + t)
>  0324:
>  0325:def _add_type(t):
>  0326:baset = _image_base_type(t)
> Exception: AttributeError: 'NoneType' object has no attribute 'split'
> 
> ERROR: Failed to parse recipe: 
> /OE/build/wpb/webos-ports/meta-webos-ports/meta-luneos/recipes-core/images/luneos-image.bb
> 
> Summary: There were 3 ERROR messages shown, returning a non-zero exit code.
> 
> 
>>
>> Signed-off-by: Richard Purdie 
>>
>> diff --git a/meta/classes/image_types.bbclass 
>> b/meta/classes/image_types.bbclass
>> index e2467bd..122e080 100644
>> --- a/meta/classes/image_types.bbclass
>> +++ b/meta/classes/image_types.bbclass
>> @@ -17,7 +17,9 @@ def imagetypes_getdepends(d):
>>  
>>  deps = []
>>  ctypes = d.getVar('COMPRESSIONTYPES', True).split()
>> -for type in (d.getVar('IMAGE_FSTYPES', True) or "").split():
>> +fstypes = set((d.getVar('IMAGE_FSTYPES', True) or "").split())
>> +fstypes |= set((d.getVar('IMAGE_FSTYPES_DEBUGFS', True) or "").split())
>> +for type in fstypes:
>>  if type in ["vmdk", "vdi", "qcow2", "hdddirect", "live", "iso", 
>> "hddimg"]:
>>  type = "ext4"
>>  basetype = type
>>
>>
>> -- 
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

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

[Martin Jansa]

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 now removed from debug symbol files. Removing these 
paths means that remote GDB using an unstripped build system sysroot will no 
longer work (although this was never documented to work). The supported method 
to accomplish something similar is to set IMAGE_GEN_DEBUGFS to "1", which will 
generate a companion debug image containing unstripped binaries and associated 
debug sources alongside the image.

and it fails with ugly exception, because IMAGE_FSTYPES_DEBUGFS isn't set by 
default.

It should either be mentioned in the manual or there should be some sane 
default for it.

meta/conf/local.conf.sample.extended shows example how to set it next to 
IMAGE_GEN_DEBUGFS,
people reading this sample may notice it, but the comment also says:
  If IMAGE_FSTYPES_DEBUGFS is not defined, it defaults to IMAGE_FSTYPES.
which isn't true for some reason in my setup, looking at the code I don't see 
where it is supposed
to default to IMAGE_FSTYPES

if d.getVar('IMAGE_GEN_DEBUGFS', True) == "1":
debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS', True).split()
for t in debugfs_fstypes:
alltypes.append("debugfs_" + t)

Maybe the author meant that IMAGE_FSTYPES variable is set to 
IMAGE_FSTYPES_DEBUGFS
only when IMAGE_FSTYPES_DEBUGFS is set, but that still leaves that split()
causing parse failure.

debugfs_image_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS', True)
if debugfs_image_fstypes:
d.setVar('IMAGE_FSTYPES', debugfs_image_fstypes)

ERROR: 
/OE/build/wpb/webos-ports/meta-webos-ports/meta-luneos/recipes-core/images/luneos-image.bb:
 Error executing a python function in :

The stack trace of python calls that resulted in this exception/failure was:
File: '', lineno: 14, function: 
 
0010:__anon_38__OE_build_wpb_webos_ports_openembedded_core_meta_classes_rootfs_ipk_bbclass(d)
 
0011:__anon_113__OE_build_wpb_webos_ports_openembedded_core_meta_classes_image_bbclass(d)
 
0012:__anon_176__OE_build_wpb_webos_ports_openembedded_core_meta_classes_image_bbclass(d)
 
0013:__anon_146__OE_build_wpb_webos_ports_openembedded_core_meta_classes_siteinfo_bbclass(d)
 *** 
0014:__anon_439__OE_build_wpb_webos_ports_openembedded_core_meta_classes_image_bbclass(d)
File: '/OE/build/wpb/webos-ports/openembedded-core/meta/classes/image.bbclass', 
lineno: 322, function: 
__anon_439__OE_build_wpb_webos_ports_openembedded_core_meta_classes_image_bbclass
 0318:typedeps = {}
 0319:
 0320:if d.getVar('IMAGE_GEN_DEBUGFS', True) == "1":
 0321:debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS', 
True).split()
 *** 0322:for t in debugfs_fstypes: 
 0323:alltypes.append("debugfs_" + t)
 0324:
 0325:def _add_type(t):
 0326:baset = _image_base_type(t)
Exception: AttributeError: 'NoneType' object has no attribute 'split'

ERROR: Failed to parse recipe: 
/OE/build/wpb/webos-ports/meta-webos-ports/meta-luneos/recipes-core/images/luneos-image.bb

Summary: There were 3 ERROR messages shown, returning a non-zero exit code.


> 
> Signed-off-by: Richard Purdie 
> 
> diff --git a/meta/classes/image_types.bbclass 
> b/meta/classes/image_types.bbclass
> index e2467bd..122e080 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -17,7 +17,9 @@ def imagetypes_getdepends(d):
>  
>  deps = []
>  ctypes = d.getVar('COMPRESSIONTYPES', True).split()
> -for type in (d.getVar('IMAGE_FSTYPES', True) or "").split():
> +fstypes = set((d.getVar('IMAGE_FSTYPES', True) or "").split())
> +fstypes |= set((d.getVar('IMAGE_FSTYPES_DEBUGFS', True) or "").split())
> +for type in fstypes:
>  if type in ["vmdk", "vdi", "qcow2", "hdddirect", "live", "iso", 
> "hddimg"]:
>  type = "ext4"
>  basetype = type
> 
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] npm class usage

[Fabio Berton]

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/recipetool", line 116, in 
ret = main()
  File "sources/openembedded-core/scripts/recipetool", line 107, in main
ret = args.func(args)
  File "sources/openembedded-core/scripts/lib/recipetool/create.py", line
561, in create_recipe
handler.process(srctree_use, classes, lines_before, lines_after,
handled, extravalues)
  File "sources/openembedded-core/scripts/lib/recipetool/create_npm.py",
line 133, in process
license = self._handle_license(pdata)
  File "sources/openembedded-core/scripts/lib/recipetool/create_npm.py",
line 44, in _handle_license
if 'license' in data:
TypeError: argument of type 'NoneType' is not iterable


On Thu, May 5, 2016 at 7:57 AM, Brendan Le Foll 
wrote:

> 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
> using
> > it for this; if you have any issues please let me know.
>
> So actually it errors in this case because of a test package in the
> resolve module (this shows the issue quicker/easier) see:
> $ recipetool create "npm://registry.npmjs.org;name=resolve;version=1.1.7"
>
> There's a node_modules dir inside test/ it gets taken as if npm had
> resolved/download a dep when in fact it hasn't. Since node packages
> can and do ship their own deps with them sometimes, I think the only
> fix would be in npm_split_package_dirs to walk 1 level of the ${PN}
> dir only so that:
>
> ${PN}/node_modules -> taken
> ${PN}/tests/node_modules -> ignored
> ${PN}/node_modules/${PN}/node_modules -> taken
>
> Cheers,
> Brendan
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Robert P. J. Day]

  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 functionality. at any time, i'd like to
generate a "change manifest" relative to the original installation;
IOW, just a changelog of what's happened *only* since the original
install. that should be simple, but wait, it gets better.

  eventually, a new release, say "1.1" comes out, and a full upgrade
to that new release is done. at that point, i want to reset the
baseline for the change manifest relative to 1.1, so the new change
manifest appears empty, and starts tracking changes from that new
version. and so on, and so on.

  or, now that i think about it, i guess i want the general ability to
query the change manifest relative to any "official" release, assuming
i can identify when an official release is applied to the system.

  is there a simple rpm command to do this? i can see a utility called
rpm-manifest:

  https://github.com/jumanjiman/rpm-manifest

that will at least tell me that *something* changed, but doesn't go
into detail.

  so what overlooked feature of rpm (or the smart package manager, if
need be) am i missing?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] npm class usage

[Brendan Le Foll]

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 using 
> it for this; if you have any issues please let me know.

So actually it errors in this case because of a test package in the
resolve module (this shows the issue quicker/easier) see:
$ recipetool create "npm://registry.npmjs.org;name=resolve;version=1.1.7"

There's a node_modules dir inside test/ it gets taken as if npm had
resolved/download a dep when in fact it hasn't. Since node packages
can and do ship their own deps with them sometimes, I think the only
fix would be in npm_split_package_dirs to walk 1 level of the ${PN}
dir only so that:

${PN}/node_modules -> taken
${PN}/tests/node_modules -> ignored
${PN}/node_modules/${PN}/node_modules -> taken

Cheers,
Brendan
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] npm class usage

[Paul Eggleton]

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,
Paul

On Wed, 04 May 2016 14:21:18 Fabio Berton wrote:
> I think that meta-brendan-nodepkgs link could be on npm.bbclass file as
> documentation and example of use, would be helpfully.
> 
> On Wed, May 4, 2016 at 2:06 PM, Brendan Le Foll 
> 
> wrote:
> > On Wed, May 04, 2016 at 02:01:40PM -0300, Fabio Berton wrote:
> > >Yes, it helps.
> > >Now I see my error... I need to use
> > >SRC_URI = "npm://[1]registry.npmjs.org;name=${PN};version=${PV}"
> > >My recipe it's getting sources from github and not from registry.
> > >Thanks!
> > 
> > No problem. FYI I have some examples here:
> > https://github.com/arfoll/meta-brendan-nodepkgs
> > 
> > They show usage of shrinkwrap and lockdown etc... It's not
> > particularly useful or used but really it's my test layer so feel free
> > to submit any other modules you think are helpful/useful.
> > 
> > Cheers,
> > Brendan

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Jun Zhu]

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.
---
 meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb 
b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
index a9de3d7..2812520 100644
--- a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
+++ b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb
@@ -27,11 +27,7 @@ do_install_append() {
 
 install -d ${D}${sysconfdir}/X11/Xsession.d/
 install -m 0755 ${WORKDIR}/30xinput_calibrate.sh 
${D}${sysconfdir}/X11/Xsession.d/
-
-install -d ${D}${sysconfdir}/xdg/autostart
-sed -e 's,^Exec=.*,Exec=${bindir}/xinput_calibrator_once.sh,' 
${S}/scripts/xinput_calibrator.desktop > 
${D}${sysconfdir}/xdg/autostart/xinput_calibrator.desktop
 }
 
-FILES_${PN} += "${sysconfdir}/xdg/autostart"
 RDEPENDS_${PN} = "xinput formfactor"
 RRECOMMENDS_${PN} = "pointercal-xinput"
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core